ただのにっき

■ 自家製ジンジャーエール

先日の発売日以来、ウィルキンソン・ジンジャーエールのペットボトルを何回か飲んでみている。最初は熱狂的だったものの、やはり人工甘味料の後味の悪さが次第しだいに気になってきて、もうしばらく飲む気がないくらいになった。やっぱマズイよコレ。

最初の一口、二口は「おっ」と思うけど、ベタベタした甘さがだんだんつらくなる。少なくとも、500mlは多すぎる。「世界のキッチンから」のディアボロジンジャーは、味の調整具合といい、分量といい、実に偉大なバランスの商品だったんだなぁ。キリンさん、この夏も復活させてくれませんかねぇ。

……と嘆いていたら、かみさんがしょうがシロップを作ってくれた。これを(あえて)ウィルキンソンの炭酸水で割ると、ほら! ホンモノのジンジャーエールだよ! ぷはっ、うめぇ。やっぱこれが一番美味いねぇ。

■ 「萩の月」をいただいた

以前、三食ぜんぶ萩の月でも文句がないくらいに大好きと書いたのを知ってから知らずか(知らないと思うけど)、萩の月をいただいてしまった。もらったその場でかぶりつきたいところだったが、二個入りだったのでちゃんと家まで持って帰って、かみさんと分け合ったおれの自制心もたいしたものです。

ずいぶん久しぶりだったけど、記憶にあるとおりのおいしさだったよ。いつか仙台で作りたてを食べてやる。

■ GitHub時代のオープンソース・プロジェクトとの付き合い方

GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。

そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。

1. 貢献しようと意気込まない

FOSSに関わろうとすると必ずついてまわる「貢献」の二文字。重いよねぇ。はっきりいって、貢献なんて別にしなくていい。そもそも「貢献」はされる側が評価に使う言葉だよ。する側が声高に宣言するもんじゃない。

最初から「FOSSに貢献しよう」なんて考えないこと。まずは「このバグが直らないと自分が困る」くらいの自己中でいいから気軽に接しよう。

2. ナイショにしない

自分のためにFOSSに関わるとなると、「別に自分の成果を公にする必要はないのでは?」と思うかも知れない。ごもっとも。でも、自分と同じことで困っている人は必ずいるものだ。その人にも同じ苦労をさせる非効率は、エンジニアとして許せなくない?

少し前なら、自分の成果を公開するのは少々面倒だった。だからローカルでちょちょっと修正したパッチを隠し持っている人も多かったと思う。そのハードルをぐっと引き下げてしまったのがGitHubを始めとする現代のリポジトリサービスだ。そのあたりは別項に譲るとして、面倒がほとんどないなら、成果を公開しておいても誰も損はしない。

3. forkすることを厭わない

FOSSプロジェクトにとって従来、「フォーク」は忌み嫌われるものだった。最近でもHudsonとJenkinsの不幸な事件があったばかり。FOSSプロジェクトの分裂はあまり良い結果をもたらさない。

ただ、GitHubのforkはプロジェクトの分裂を意味しない。単にソースツリーの個人用コピーを作るだけの作業だからだ。さらにgitにはツリー間の統合が非常にやりやすいという特性があるため、ソースツリーがたくさんあることは混乱を意味しないのだ。

「ちょっとこのツールのソースをいじりながら読んでみたい」。そんな動機でもいいので、GitHubのforkボタンは気軽にどんどん押そう。そしてそのツリー上に、自分だけの成果をどんどん公開しよう。

4. パッチを送るのを躊躇しない

こうやってGithub上には同じプロジェクトから派生したたくさんのソースツリーが存在している。日々本家に追従するのはもちろん、他の人が作ったパッチを自分だけのソースツリーに取り込んでもいい。一方で、自分が作ったパッチを本家に取り込んでもらいたいこともあるだろう。

そんな時は、遠慮なくpull requestを送ろう。従来パッチを取り込んでもらうためにクリアしなければいけなかったハードルのかなりの部分を、GitHubはボタンひとつの気軽な行為にしてしまった(ただし、パッチが受け入れられるかどうかは別の話)。

冒頭に出てきた「masterでパッチ作るな」というのはこのあたりで初めて効いてくるテクニックだ。実際、master上で作られたパッチでも、受け取る側はそんなに苦労はしない。リジェクトされたパッチの処分に「自分が」困るからトピックブランチで作業した方がいいよという話なのだ。だからgitのブランチ・テクニックはこのあたりで身につけても遅くはないよ。

5. つらくなるまで続けない

最後は、多くを語る必要はないだろう。無理することはない、楽しくやろう。これが一番大事。

実際、こんなことを書いているおれだって、そんなにたくさんのプロジェクトをforkしているわけじゃない。あんまり手を出しすぎると続かないのが自分でもわかっているからね。

Enjoy!