すこし前にこんな記事がブクマに乗ってきたけど、
非エンジニアもGithubを使うべき12の理由
http://www.goodpic.com/mt/archives2/2013/09/non-engineers-should-use-github.html
これはかなりタイムリーだった。
元になったのは以下の記事のようだけど、
これはぼくもちょうど読んでいて、「へえ、じゃあソースコード以外の物もあまり肩身狭くならずに扱ってよさそうだな」と思ったりしたところだった。
GitHubはたしかにどう考えてもプログラミングに関わるプロジェクト「以外」のことにもだいぶ応用が効きそうなシステムで、とくにぼくのやってるような編集工程にはジャストだと感じていたけど、やっぱり普段使いのエンジニアさんのコミュニティの空気感から外れすぎるのも嫌なので、その辺どうなのかな〜と思っていたところで上記のようなある意味中の人（というかトップ）からのお墨付きが出たような感じではあるので、まあ想定されているであろう使用法を超えすぎない範囲がいいのだろうとは思いつつ、ある程度積極的に使ってみようとも思った。
導入編
Gitについては今春からのプログラミング独習の中で、以下を元になんとなく基礎の基礎ぐらいは使えるようになったものの、
- 作者: 川野辺正博
- 出版社/メーカー: 秀和システム
- 発売日: 2012/09/18
- メディア: 単行本
- 購入: 1人 クリック: 32回
- この商品を含むブログ (12件) を見る
その応用編的なGitHubに関しては何しろコントリビューションする相手もされる相手もいないので（協業者は少なからずいるけど一人としてGit使うとは想定しづらいので）、そういう意味でもちょっとハードル高いというか、後回しにしていたんだけど、先日行ったPerl入学式をきっかけに、あれもしかして講座で使ったコード置いたりできそうじゃね？ とか、あるいはこれも先日来熱の絶えないVimのvimrcファイルを置いておくとかならできるかも？ などと思われ、えいやって感じで上記のアリス＆ボブ本と以下を頼りに1個1個試してみたのがここ3〜4日ぐらい。（で、ちょうどその最中に冒頭のGoodpicさん＆TechCrunchJPの記事が出た）
- 作者: Junio C Hamano,大塚弘記,川口耕介,kana,大竹智也(tomoya),尾藤正人,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2013/04/10
- メディア: 大型本
- クリック: 1回
- この商品を含むブログ (11件) を見る
そしたら、まあ例のごとく意外なことや上手くいかないことの連続から始まり、それでも10回のエラーに対して1〜2回は思いどおりに動くこともあり、その後は徐々に想定したように動くことの方が増えてきて、とくにはターミナルからのpushとかが思ったようにブラウザに反映されるようになると、もう何というかすごい嬉しい。
ちなみにターミナルからの初歩的なGit操作については最初に挙げたアリス＆ボブ本が、GitHubの初歩的な設定等については後者のムック本がどちらも大変わかりやすく、もちろんそれさえあれば100%なんでもわかるってことではなくて何度もミスったりハマったり結局わかんなかったりしながらだけど、それでも前には進むので制作者の方々には御礼を言いたい。というか言います。ありがとうございます。
実践編
で、たぶんまだまだ使い方や概念の把握のあり方として、ズレたところも多々あるとは思うんだけど、何らか意味のあるものを作っていけたらいいよなあ、と思ってやってみたのがいつも聴いている@miyagawaさんのテック系Podcast「Rebuild」の内容をテキスト化してみる、というもの。
それでさっそく第一弾をUPしてみた。
https://github.com/note103/rebuildfm_transcripts/blob/master/rebuildfm_5.md
素材にしたのは現状全20回のうちの第5回で、ゲストにRubyのパパことまつもとゆきひろさんを迎えられた時の内容だけど、これは個人的に好きな回＆話が汎用的（誰でも楽しめそう）＆時間が短め、ということもあって最初のトライに良さそうと思われ、GitHub自体にトライし始めた先週水曜から仕事の合間にちょっとずつ進めてみた。
あと、こういうやり方がGitHub的にどうなのかはわからなかったけど、あまり頻繁にmodify&pushしまくるのもどうかと思い、と同時にやはりゼロから文字が埋まっていく＆通して読めるようになっていく編集過程も多少なり公開できたら面白いんじゃないかと思い（むしろその差分を可視化できるのがGit/GitHub的というか）、作成中のファイルはそのためのリポジトリを別に設置してそこに置き、上記のmarkdownファイルは一定程度内容も出来て、あとは外部からプルリクとかIssueとかコメントとかも受け入れ可能な状態、といえるファイル置き場としてのリポジトリを作ってそこにUPしている。
で、その編集履歴なども載ったドラフトの方のファイルは以下。
https://github.com/note103/github_sandbox/tree/master/rebuild-fm
もしかすると、いろいろ混乱しないようにドラフトファイルはDeleteしておいたほうがいいのかなとも思ったけど、そうしたら履歴もわかりづらくなるか、とかその辺はまだよくわかっていない。
「Rebuild」は無料で公開されているPodcastなのである程度のクレジットやリンク先を備えておけば大きな問題はないかなと考えているけど、あとで@miyagawaさん（or @rebuildfm ）には報告しておきたい。
追記
@miyagawa さんに確認したところ、個人ブログなどへの転載はNGだけどGitHubのレポジトリ等なら公開はOKとのこと。
一方、番組の意図としては元の音声を楽しんでほしいということが第一なので、ある程度時間の経ったものを対象として考えてもらえれば、とのことだった。
たしかにテキストになると30分ぐらい話した内容が数分で読みきれる（気になる）し、にもかかわらずそこには圧倒的な内容の違いがあるから（良し悪しとは別に）、あまり大っぴらにこれが読まれるのもちょっと違うかもしれない。
あと、テキストだけで内容を把握したようになってしまう現象があるとすれば、それはちょうどMatzさんが最後の「完成されたリリース」という話題のあたりで言われていたまとめ記事（セッション・レポート）と本人の真意とのズレ、みたいな事ともつながる話かもしれないな、と連想的に思ったりした。
