ただのにっき

■ 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!

■ 検索と発見のためのデザイン ―エクスペリエンスの未来へ(Peter Morville)

なんだか妙にくだけた口調で始まって、おかげでかえって何が書いてあるのかよくわからず、「こりゃ失敗したかなー」と思いつつ読み進めていたが、中盤の「検索のパターン」はなかなかよくまとまっていた。よくよく見てみたら原題は「Search Patterns」で専用のサイトまである。

アレグザンダーまで引用してのパターン集は、現代のWebサイトで実際に提供されているさまざまな検索エクスペリエンスを10個のパターンに分類、豊富な事例も交えて使える場面、ユーザにとってのメリット・デメリットがけっこう詳しく述べられている。原題の方が直接的でよくわかったんじゃないかな。

まぁ、著者たちも白状しているようにパターン「ランゲージ」としてはまだまだ未完成だが、自サイトに検索を組み込むにあたって何が必要なのかを整理するには悪くない。いまだに「単純な検索窓に詳細検索オプションてんこ盛り」みたいなのを出してくるデザイナや開発者に、黙って差し出すには良いんじゃないだろうか(下手な「Advanced Search」は典型的な失敗パターンである)。

終盤は「検索から発見へ」というパラダイムシフトがおきるという設定のもとに、五感で入出力する検索体験を始めとしたいささか壮言大語気味のエッセイ。邦題からはこっちがメインのように思えるが、まぁ、話半分に聴いておくかという感じ。いや、こういう立場の人たちが未来を語るのはいいことだと思う(けど、現場はそうとばかりも言ってられないしね)。

■ 読書好き系サービス2つ

しばらく小説読みから離れていたこともあって、なかなか感覚が戻らない。そんなタイミングで2つの読書好き系(?)サービスに出会ったので感想など。

本が好き!

ごく最近始めてみたのが「本が好き!」で、ユーザが書評を書いてお互いに読み合う感じのサービス。書評を書くとポイントがもらえて、ポイント数に応じて「級」があがる。面白いのが、この「級」があがると出版社から提供される「献本」の抽選に応募できるようになるところ。書評を登録するインセンティブが本そのものというわけで(もちろん当たった本の書評も書かなくてはいけない)、なるほどこれなら継続する気になる。

一方、いまどきのWebサービスとして必須ともいえる「ソーシャル度」はかなり低くて、人の書評を評価したり、メッセージを送ったりできる程度。お気に入りのレビュアーが登録できたりすればいいのにね。

こないだやっと「3級」になったので、唯一発見できたSF小説の献本に応募してみたら、残念ながら抽選に漏れてしまったようだ。どれくらいの「勝率」なのかわからず、継続するべきか悩んでいたが、「5回応募して1回しか外れてない」という人もいるので、もうちょっと続けてみようかね。

byflow

もうちょっと以前から使っているのが「byflow」。こっちはバリバリのソーシャル系で、自分の持ってるアイテム(主にAmazonが対象なのでおのずと本がメインになる)をリストに登録していき、さらに好みの合うアイテムを持ってる人を「フォロー」することで、興味の似通った人のクラスタができて、流れているアイテムから「あ、これ読みたい」というピックアップがしやすくなるという仕組み。まぁ、Twitterの書籍版というところ。

Twitterと同様、いい気になってフォローを増やしすぎるとわけがわからなくなり、だんだんメモも付いてないようなアイテムはスルーしがちになってきたので、使い方を考えないといけなくなりつつある。続けるインセンティブが少ないのが課題かもねー。

個人的に、「本が好き!」と「byflow」が合体するとすごく好みのサービスになる気がする(笑)。