出張しているうちに WEB+DB Press 68 が届いていました。 ありがとうございます。紹介にそなえ Octopress 向け Amazon ピンハネプラグインでも書いておけばよかった・・・。 目次をじっとにらむと 私もひそかに連載をはじめさせてもらっていることに気づかれるかもしれません。 お手元にある方はぱらぱらめくってみてくだされば幸いです。

私もぱらぱらめくってみたところ、 Satoshi Nakajima さんが ウェブ中毒・・・じゃなくてプッシュ型メディアと生産性について書いていた。 要約すると、モチベーションがあればウェブで気が散ったりしないから大丈夫、というのが氏の主張らしい。 1% のスーパープログラマおよび 60% (推定) の健常者的にはそれが正しい答えだろうし、 モチベーションだってたぶんあるに越したことはないとも思う。 ただモチベーションだけを頼っては色々片付けられない 39% (推定) の rest of us としては 正しくなくていいから破滅しない方法が知りたい。 だって Chrome OS の時代(もうすぐ来る予定。免責事項: ステマ) がきたら /etc/hosts をいじれないわけですよ。 というか免責するまでもなく iOS とかあんどろとか既にいじれない。 個人的には生産性低下による雇用の危機は石油資源枯渇によるエネルギー危機より切迫している。

The Power Of Habit

知人各氏は私がたびたび 断線 やら ウェブ中毒 やらわめいているのを知っておりかつ辟易しているかもしれない。 この断線/ウェブ解毒活動はぼちぼち続いており、 その成果は長くなるので今日は書かないけれども、 直近の話題に限ると出張中に読んだ Power Of Habit は 面白い読み物だった。駄本の多い断線リテラシーで異彩を放っている。

NYTimes のライターである著者は、まず習癖(Habit)を Cue(きっかけ) → Routine(動作) → Reward(達成感) の繰り返し として位置づける。 この繰り返しを中心に置き、取材や調査の結果をおりまぜながら本書の議論は進む。

たとえば cue とはなんだろう。消臭剤ファブリーズは発売当時、全く売れ行きが伸びず悩んでいた。 主要顧客であるはずの匂いのきつい家、匂いのきつい服などの持ち主は、自分の匂いに慣れているためファブリーズを使うきっかけ(cue)を見いだせない。 そこでファブリーズのマーケターは発想を変え、掃除の最後を締めくくるスプレーとして主婦層にファブリーズを売り込んだ。 雑巾がけを終えた、ベッドメイクを済ませたその瞬間に、祝福のファブリーズをベッド/カーテン/マットにひとふき！ 掃除機ではとれない匂いも落とせて完璧！ というわけ。 事前の調査から、マーケターたちはそうした最後の瞬間に主婦達が決まって笑顔を浮かべる様子を突き止めていた。 おかげで掃除完了の一服を cue としてとらえ、便乗することが出来た。

Reward の例には 20 世紀前半に売れた歯磨き粉 Pepsodent が紹介されている。 Pepsodent は歯磨き粉の歴史を覆す大ヒット商品だったらしい。 Pepsodent の秘密はその味にあった。スッキリ感のあるシトラス系の風味 を使い、歯を磨いた reward を演出したのだ。 今では珍しくない味付き歯磨き粉も当時は画期的だった。 そうした風味は歯磨き粉自体の薬効に何ら寄与しない。Reward を与えるためだけに入っている。 当初無臭だったファブリーズも、同じ理由でちょっとだけ香りがついている。石鹸のような香りが掃除完了の達成感を演出する。

その後も「安全第一」の habit でアルミ精錬会社の Alcoa を立て直した CEO, 自覚と意思によって habit をねじふせるアメリカ版レコーディング・ダイエットとスタバ店員、 データから顧客の habit を予測して広告を送りつけるスーパーマーケット Target のデータマイニングなど、興味深い話が続く。

最終章で著者はこう説く。夢遊病者が人を殺しても責任能力を問えない。 けれど重症のギャンブラーが悪徳カジノの一夜で億単位の金をスったら返済の義務がある。 殺人の方が罪が重いのになぜか。一億スったギャンブラーだってディーラーに拐かされただけなのに…

夢遊病者とギャンブラーの違いは一線を超える前に気づく機会があったかどうかだと著者はいう。 ギャンブラーはのめり込む前に手を打つことが出来た。だから責任を問えるのだと。 身につまされる。ウェブ中毒でクビになっても会社都合退職にはならないだろうってことだからね IANAL だけど・・・

Habitalt: An Anti-Habitual Blocker

同書の Appendix には残念な習癖を立て直す手引きがついてくる。 著者が勧める habit 克服のコツは cue と reward を突き止めること。

「毎日スタバでクッキーを買うのは太るから止めたい」という著者の例をひいてみる:

• クッキーを食べたい！ (あるいは食べてしまった) ら、その衝動につかれた状況を短くメモしておく。 何を考えていた? 何をしていた? 何時頃? 誰が周りにいた? 記録を集めるとパターンがみえてくる。どうも衝動に駆られるのはいつも午後三時頃のようだ。
• 次は reward のバリエーションを試してみる。たとえばスタバに行かず休憩コーナーの駄菓子にしてみる。 あるいはスタバの買い物をコーヒーだけにしてみる。それから 15 分後に気分を振り返る。 もしコーヒーを飲んだだけでクッキーへの衝動が消えていたら、それはスタバで交わす同僚との雑談が自分の欲しいものだったとわかる。
• 記録を一週間程度つづけたところで対策を考える。スタバのかわりにそのへんで雑談すればいいだけかもしれない。 15 時にタイマーをセットし、先手をうって休憩をとり同僚と世間話でもしよう。

どんな habit 相手にもこう上手くいくとは思えないけれど （職場の駄菓子が好きだったらどうすんの?) 習癖を断つには cue と reward の分析から始めよという指摘自体は的を射ている。 /etc/hosts は強力な断線機能を備えるものの、そうした振り返りの機会を与えてくれない。 一時期 /etc/hosts に並べたリダイレクト先の localhost に意味のあるコンテンツを置けば 何かわかるんじゃないかと考えていたけれど、反省掲示板みたいのを置いとけばよかったんだな・・・。

もともと /etc/hosts をなんとか卒業したい気持ちもあったので、 localhost のかわりに Habitalt という小さい Chrome extension (と補助サイト) を書いてみた。 エクステンションのインストールは habitalt.me/crx から。

機能:

• 指定したサイトへのアクセスを検出したタブを左のような記録画面にリダイレクトします。その瞬間の衝動をすかさず打ち明けましょう。記録内容は書いた人だけに見えます。
• アクセスしようとしたサイトと時刻は Habitalt が付記し、メッセージと一緒に右のような画面から一覧できます。(冒頭のは頭を冷やせ的メッセージです。どうでもいいです・・・)
• ブロックサイトを指定する正規表現はエクステンションのオプション画面から変更できます。

私の場合、もともと諸悪の根源はビルド待ちだと信じていた。 ところが自分の振る舞いを調べてみると、ビルド待ち以外にもバグで行き詰まったとき、 直近の作業がすべてレビュー待ちになってしまったとき、同僚に話しかけられた直後など、 言われて見れば自明だけれど思ったより目立つ cue が他にもみつかった。 なのでまずはぼんやり gdb をうごかすのではなくもうちょっと系統だててデバッグできるよう Code Complete でも読みなおそうと思った。 いや普通こんなの読まなくていいと思うんだけど古いコードベース相手に仕事してるからさ・・・。

むかし似たようなことをやった事実 については概ねほっといていただきたいけれども、 いちおうブラウザの進化および自分の反省を踏まえちょっとはマシなものになっている…気がする。 具体的には Chrome に webRequest API という HTTP リクエストをフックできる機能がついたので、これで習癖サイトへのアクセスをブロックしてみた。タブが開いた瞬間を検出する以前の方式だと元サイトがチラっと見えてしまい フラストレーションがたまるのに対し、 webRequest ベースのフィルタリングは /etc/hosts に近いレベルでバシっと断ち切る。 回数制限のように習慣改善を邪魔する機能はなくした。

webRequest は大変凶悪というか何でもアリな API のため、この API をつかっていると Chrome Web Store への掲載にレビューを求められるらしい。 時間がかかりそうなので仕方なく自分でホストすることにしました。せっかくストア用のタイトル画像をつくったのになあ。

39% クラブの皆様はご利用ください - と友達に話したら、 そこまで思いつめてる人ほとんどいないとおもうよ、とあしらわれた。またまたご冗談を・・・ ロードマップとしてはページネーションと時刻分布のヒストグラムくらいはつける予定。

• Github repo: https://github.com/omo/habitalt
• タイトル画像: http://www.flickr.com/photos/linneberg/5060134205/

ある ニュース記事を同僚に教わった。 この記事によるとタッチデバイスの会社は WebKit2 に対応しているのに検索の会社は旧バージョンにとどまっており、HTML5 に課題は多いのだそうな。 そりゃ課題は常に山積みだよね…と思っていたら記事は誤解だと別の同僚が説明を書いている。

リンク先の記事はさておき、世間の関心をいまいち集められていない気がする WebKit2 についてざっと説明をしてみたいとおもう。 この記事を読み終われば WebKit2 と Chromium WebKit, Webkit1 の違いを知ったかぶれるようになる予定。

WebKit2

WebKit2 は 2010 年の 4 月にアナウンスされた WebKit の新しい API レイヤで、Mac 版 Safari などが使っている。 大きな特徴はレンダリングエンジンを別プロセスで動かせること。 Chromium でやっているのと同じようなものだと思えばいい。

WebKit2 は WebKit プロジェクト全体の書き直しやメジャーバージョンアップではない。 プロジェクト名の WebKit (WebKit Open Source Project) と API レイヤの WebKit (WebKit API) はまぎらわしく、よく人々を混乱させている。 同様に WebKit2 は WebKit2 API であり, WebKit2 Open Source Project というものはない。 API の下にはレンダリングなんかを担当する WebCore や JavaScript 処理系の JavaScriptCore がある。 従来の WebKit API も WebKit2 API もこれらを変わらず使っている。

ついでに従来の WebKit API …便宜上 WebKit1 と呼んでおこう… は無くなってはいない。引き続き保守されている。 WebKit1 は MacOS でいうと WebView, iOS でいうと UIWebView なんかのこと。 WebKit2 の API は WebKit1 の API と全く互換性がない。 各種 SDK に含まれる WebKit1 が WebKit2 にとって代わられることは当面無さそうに見える。 だから自分の書いた iOS アプリが OS アップデートで突然マルチプロセスになったりはしない…とおもう。しばらくは。

WebKit1

登場した時系列で話を進めるのが腑に落ちやすいと思うので、まずは WebKit1 と Chromium WebKit の違いからはじめたい。

先に書いたとおり、 WebKit1 は WebView などのクラスをふくむ API を指す。 伝統的に WebKit1 は各プラットホーム/ライブラリの一部としてすんなり動くようデザインされてきた。 たとえば iOS や OSX での WebKit1 は Cocoa にかっちりと組み込まている。 C++ で書かれた WebCore を Objective-C が包み込み、 NSView や UIView を継承した表皮を形作る。 API も完全に Cocoa. NSURL や NSURLRequest みたいな Cocoa オブジェクトを受け付ける。 Cocoa プログラマは Interface Builder で並べた WebView に URL を渡すだけで 自分のアプリケーションに WebKit を組み込める。かんたん便利。

Qt, GTK といった OSX 以外の WebKit1 もこの流儀に従っている。 Qt には Qt C++ で書かれ QWidget を継承した外殻がある。 Qt Designer をつかえば自前の Qt アプリケーションに組み込むのも簡単だ。たぶん。ためしたことないけど。 同様に GTK ならシグナルを張り巡らせた GObject C の(中略)で Glade を(以下略)。

このプラットホーム親和性は他のブラウザに対する WebKit を特徴づけている。 Firefox のエンジンである Gecko はどちらかというとそれ自体がプラットホームぽくなっており、 既存の GUI アプリに組み込むのは WebKit ほど簡単でない。端的にいうと Cocoa や Qt についてこない。 その対価として Gecko というプラットホームの上で作られたアプリケーションは OS を問わずだいたい動く。

自身の OS を強化したいタッチデバイスの会社とブラウザのレイヤで OS をコモディティ化したかったかつてのブラウザ会社。 WebKit と Gecko の違いはスポンサーおよび元スポンサーの意向をそのまま反映しているように見える。 (※昔話です。現在のブラウザ法人の方針を説明するものではありません。)

Chromium WebKit

Chromium が自分用に定義した WebKit の API … Chromium WebKit と呼ぼう … は、 プラットホームにくっつける WebKit1 の流儀をすっかり無視している。 Chromium はライブラリとしての Chromium WebKit を広く人々に使って欲しいとは思っていない。特定ブラウザのためだけに WebKit を使っている。 だから安定した API はなく、 クラスやメソッドが必要に応じて足し引きされていく。 一週間バージョンがずれた WebKit と Chromium はたぶん一緒にビルドできない。

WebKit1 と違い、 Chromium WebKit はアプリケーションと別のプロセスで動かすべく作られている。 WebKit のプロセス (Chromium 用語では renderer) は OS のサンドボックス機構に閉じ込められていて、 ファイルアクセス、通信、 GPU による描画といった OS のきわどい機能はプロセス間通信で別のプロセス (browser プロセス) に依頼する。

Chromium WebKit の仕事は別のプロセスから届いたデータを解釈し、JS やら HTML やらを色々動かしてメモリ上のオフスクリーンに結果を描くだけ。 だから Chromium WebKit 単体には HTTP すらついてない。 HTTP は Chromium のコードに入っている。 私は Chromium WebKit で phantom.js みたいのを作れないかなーと四半期に一回くらい空想するのだけれど、 そうだ HTTP ないんだったと繰り返し目を覚ましている。 File API なんかもプロセス間通信のスタブだけが入っおり、 実際のファイルは browser プロセスが読み書きする。

そしてプロセス管理の仕組みは Chromium が面倒を見ている。 browser プロセスが renderer プロセスを作って、その renderer プロセスが Chromium WebKit の API を使う。

自分自身がプロセス管理の仕組みを持ってない点で Chromium WebKit は WebKit2 より WebKit1 に近い…と言えなくもない。 一方で WebKit1 のように特定プラットホーム向けのライブラリとして使える代物でもないから WebKit1 の仲間に数えるのも気が引ける。

Chromium はもともと Chromium WebKit のような API レイヤを持たず、 WebCore のクラスを直接使っていた。 WebKit (Project) のリビジョンを固定して開発する分にはそれでもよかったけれど、 最新版の WebKit に追従しつづけようとした途端に WebCore 直接方式は成り立たなくなる。 Chromium チームではない誰かの変更で簡単にビルドが壊れてしまうから。 Chromium WebKit API は Chromium と WebKit(WebCore) の間に挟まって変更のショックをやわらげる緩衝材としてうまれた。

WebKit2

WebKit2 は WebKit (Project) にプロセス分離モデルを持ち込む WebKit (API) の試みである。 Chromium が WebKit の外側でプロセス分離を実現したのに対し、 WebKit2 は WebKit の中、 API の内側にプロセス分離の仕組みを持つ。 Chromium WebKit が特定ブラウザのためだけに開発されているのに対し、 従来の WebKit はブラウザだけでなく音楽プレイヤやメーラといったアプリケーションに広く埋め込まれている。 これらのアプリケーションがそれぞれプロセス分離を実装しなおすのはムダだから、 WebKit の中に持つことにしたのだろう。

この判断のおかげで、 GTK や Qt といった Mac 以外の WebKit ポートも WebKit2 に参加して プロセス分離の恩恵を受けられるようになった。 WebKit2 自体、なるべくポートをまたいでコードを使いまわせるようデザインされている。 もともと Mac に特化してはじまった WebKit1 とはつくりが違う。

WebKit1 と WebKit2

WebKit2 の API は WebKit1 と互換性がない。 プラットホーム密着に密着した WebKit1 に対し、 WebKit2 はプラットホームとの接点を小さく保っている。 具体的には大半の API が C で定義されている。 ウィンドウをつくるなど、アプリケーションへの埋め込みに必要な最低限の接点は Cocoa や Qt-C++ といったプラットホーム固有の語彙で定義されている。 でもそれ以外の API はだいたい C。

プラットホーム密着の WebKit1 ではポート同士がまったくコードを共有していなかった。 Objective-C を GObjcect-C や Qt-C++ などプラットホーム毎の言葉に移植しただけの類似コードがポートの数だけある非機械的コピペ地獄。 WebKit2 は多くの API を C(実装は C++) の共通部分に追い出すことで重複を避けている。

WebKit2 はプロセスを切り離した時点で WebKit1 との互換性を諦めている。それも共通部分の多い作りを後押ししたと思う。 ウェブページの中身が別のプロセスにあると、たとえば WebKit1 ではアプリケーションから触ることのできた DOM を WebKit2 では触ることができない。 ほかにも Mac WebKit は Cocoa のウィンドウ階層 (NSView) とウェブページのフレーム階層をシームレスにつなぐため大きな労力を割いていたけれど、 プロセスが違う時点でこの構造にも意味がなくなった。

要するにそれまで API 越しにさらけ出していた中身がプロセスのむこうにいってしまった。 アプリケーションから見た WebKit の性質は WebKit2 で大きく様変わりした。 この移行がおきた Safari 5.1 はきっと大変なリリースだったろう。 それでも UX の変化が小さいせいかマイナーバージョンしかあげないあたりに タッチデバイス会社のこだわりを感じた。

WebKit2 と Chromium WebKit

WebKit2 と Chromium WebKit ではプロセスモデルのレイヤリング以外にも違いがある。 大きな違いの一つは WebKit (API) ではなく WebCore の中に埋まっている。

従来の WebKit ポートでは、WebKit1 も WebKit2 も同じ WebCore を使う。 なので WebCore はプロセスモデルによらず WebKit1, WebKit2 の両方で動かなければいけない。

一方 Chromium WebKit は Chromium のプロセス分離モデルだけを相手にすればいいので、 WebCore の中にある Chromium 固有部分もその前提を頼って色々細工をしている。 この細工が一番はっきりと現れるのはサンドボックス機構だろう。 Chromium WebKit はファイルやネットワーク、 GPU といったシステムの微妙なところに触れるコードをプロセスの外に追い出している。 そして WebKit の入った renderer プロセス自体は OS によって絞りこまれた権限(=サンドボックス)の下で動く。 おかげで WebKit の脆弱性をついてウェブからヘンなコードが潜り込んでも簡単には悪さができない。 サンドボックスの中でも動けるよう、 WebCore の Chromium 固有部分では微妙な仕事をするかわりにプロセス間通信用のコールバックを呼び出す。

それに対し、従来の WebCore は自分の手で HTTP やクッキーといった微妙な資源をさわる。(コードはプラットホーム毎に適当なライブラリを使う。) アプリケーションはなるべく WebKit に仕事を押し付けたいわけだから、これは自然な成り行きだ。 ただ　WebCore 自身が色々やっているせいで、厚いサンドボックスに入れるとその色々が動かなくなってしまう。 だから WebKit2 のサンドボックスは Chromium WebKit よりちょっと弱い。

とはいえ Mac WebKit2 を覗いてみると、 Darwin の sandboxで ファイルアクセスを特定のディレクトリに限るくらいはやっている。恥ずかしい /etc/hosts を悪意ある第三者に見られる心配はしなくてよさそう。 ネットワークアクセスを制限するコードは見当たらなかった。

WebKi1 との互換性はデザインを制約するだけでなく保守の面倒にもなる。 WebKit1 と WebKit2 の両方を保守する手間は馬鹿にならない。 そのためか、今のところ WebKit2 API は WebKit1 のように文書化されておらず、そこらへんのアプリケーション開発者がさっと使える風にはできていない。 今のところ Safari のように OSX 標準のアプリケーションだけで使われているんじゃないかな。もしかすると Mobile Safari も使ってるかもしれない。

というわけで WebKit API レイヤにはそれぞれ良いところも苦労もあるから、 末尾の数字のみならず中身も見た方が面白いと思うのでした。

まとめ:

• WebKit1 はプラットホーム密着型のライブラリ。
• Chromium WebKit はプラットホームも再利用も気にしない。
  • プロセスの分離は WebKit の外でやる。
• WebKit2 はプロセス分離を WebKit の中にもつ。
  • プラットホーム密着度は下がった。 API 文書なし。
  • WebKit1 との互換性のためサンドボックスはちょい弱め

Isis

自主会社員ごっこが終わったところで以下本題。

プロセス分離ができる WebKit ベースのブラウザは Chromium と WebKit2(Safari) しか無いとおもっていたら、 最近公開された次世代 WebOS のブラウザ Isis もプロセス分離に対応していた。 これがちょっと面白いつくりなので紹介したい。

Isis は WebOS 用のブラウザで、 WebOS 全体のオープンソース移行にともない一足先に公開された。 レンダラには QtWebKit を採用している。これまでの WebOS が WebKit のフォークを独自の構成で使っていたことを考えると、これは大きな方向転換に見える。 QtWebKit は Qt にあわせて割と保守的なリリースをしているけれど、 Isis はそのペースに付き合わず最新版のフォークを GitHub にミラーしている. 割とこまめにマージしている様子。

そしてプロセス分離の仕組みは WebKit2 を使わず自分たちで実装しなおしている。 Isis は QtWebKit の外側でプロセス分離を実装する。そういう意味で Chromium に近い。

Isis が面白いところの一つは、ブラウザの UI を HTML で実装しようとしているところだ。 Gecko で XUL が担っている役割を HTML にやらせるイメージでだいたいあってると思う。 他の WebKit ブラウザがプラットホーム毎のツールキットで UI を描いているのとは対照的。 UI は WebOS が公開する Enyo という JS ライブラリの上に作られている。

それにしても HTML でブラウザの UI をつくるってどういう感じなんだろう。 ウェブページは <iframe> でホストするの？ でも WebKit は <iframe> を独立したプロセスで動かすことができない。 レイアウトの仕組みが複数フレームにまたがっているし、そもそも WebCore がプロセスについて何もしらないからだ。 せっかくプロセス分離を実装しても、ブラウザの UI ごとクラッシュしてしまうなら全然ありがたみがなさそうに見える。

首をかしげつつコードを眺めると謎が解けた: Isis は QtWebKit でブラウザのプラグインを実装している。 プラグインの中でブラウザ・・・WebKit が動く。プロセス分離もその中で扱っている。 要するにページの中に <object ...> とか書いておくとその中にプロセスが作られてページが表示されるわけ。 アクロバティックな方法を考えたもんだなあ。たしかにプラグインの中で WebKit が動くならページのプロセスを分離しつつ HTML で UI を書ける。 もちろんプラグインをホストしている UI の HTML 自体も WebKit で動くのだろう。

ドキュメントを見る限り WebOS はこのプラグインブラウザ方式を以前から踏襲していた様子。全然知らなかった。 さすがにプロセスは切り離してなかったろうけれど・・・。

B2G

WebKit 以外に目を向けると、 Mozilla が推し進めるモバイルプラットホームの B2G ではアプリケーションを HTML で書くことになっている。 XUL がどうなったのか気になるけれど、タッチデバイス向けには使いまわしたい資産もないし HTML でいいんじゃね、くらいの判断だろうと想像している。

そして B2G で動くアプリケーションの中にはもちろんブラウザがある。 つまり B2G は WebOS と同じく HTML でブラウザの UI をつくろうとしている。

ブラウザが表示するウェブページは <iframe> にホストされる。 B2G はプロセス分離を諦めたのだろうか? というとさすが Mozilla に抜かりはない。 Gecko で <iframe> のプロセスを分離しようと準備を進めている。

もともと Mozilla には Firefox のために Electrolysisと呼ばれるプロセス分離のプロジェクトがあり、 既にプラグインは別プロセスへ駆逐済。 ドメイン単位でのプロセス分離は諸事情により一時停止しているらしい けれど仕組みは準備ができていて、 <xul:browser> という XUL のウェブページ表示用要素に @remote という属性を与えればプロセスが切り離される…らしい。 B2G ではこの仕組みを <iframe> にも持ち込もうとしている。

このプロセス分離がどういう仕組みで実現されているのか、たとえばネットワークスタックはどのプロセスで動くのか、私はよくしらない。 ただ手持ちのピースがパチパチと組みあわさって B2G に結集してく感じは傍目にちょっとかっこいい。

デスクトップの覇権をめぐる Netscape 戦役を消え行く記憶の隅に抱く長老 XUL が、たくましく成長した HTML に道を明け渡そうとしている。 この flexbox はもうお前のものだ - HTML の肩にそっと触れる XUL の目はそう語っていた。 一方で戦いのあと遠い国へと姿を消したかつての宿敵 Windows 家がタッチデバイス特需に沸くタブレット連邦に突然の帰国、 全てを統べるはずの WPF 卿が新バージョンでは一線を退き Windows Runtime と HTML を JS でハイブリッドした ブラウザ風の容貌をもつ不思議な若者 Metro が脚光を浴びている。 しかし背後には XAML の影が… 再会の運命を背負う二人のマークアップ、そして失われた時代に生まれた理想主義者 Isis の物語はどこで交差するのか。胸騒ぎを抑えきれない。 あとはもうちょっと他人事なら気もラクなんだけど・・・

プロセスモデルの色々

だいぶ話がそれた。

ブラウザが HTML の中で動く時代への感慨はさておき、 ブラウザのプロセスモデルに見られる色々なバリエーションを紹介してみました。

この手の提案や実装は割と色々あって、たとえば Illinois Browser Operating System なんてのは更に極端に話を推し進めてネットワークスタックのプロセスもドメインごとにわけた方がいい、なんて主張する。 Microsoft Research にも似たような話があった気がする。 （中身はよく覚えてない。）

現実世界のブラウザにはなかなかアカデミックな飛躍を期待できないけれど、 かわりに既に書かれたコードや周囲をとりまく制約の中からあるべき姿をみつけだすパズルの面白さがある。 Isis が見せたプラグイン・アプローチのハックは痛快だし、 Chromium の GPU プロセス(というのがあるのです)はアカデミアが取り組んでいない課題を垣間見せている。

ブラウザはどんな単位でプロセスを分離すればいいのか、そのためにどのような抽象が可能か。 それほど自明な問題でもないことが伝われば幸いでございます。

写真

• http://www.flickr.com/photos/pinksherbet/2452068666/
• http://www.flickr.com/photos/selva/104587/

いまいち気力がおこらず動画などを物色していたところ、 去年のおわりに開催された Strange Loopというソフトウェア開発者向けイベントのビデオが 公開されているのに気づいた。 題目を見る限り面白いのが多そう。 ホスト先が InfoQ なのはちょっと残念だけど・・・。

ぼちぼち眺めはじめた中では Product Engineering なる題目の Mike Lee による講演が面白かった。 Mike Lee は 蔵書管理ソフトの Delicious Libraryや iPhone 用音ゲーの Tap Tap Revenge といったアプリで一山あてたあとしばらく Apple で働き、その後またスタートアップに移った波乱あふれるヒットメーカー。

実際に役立つかはともかく、話の内容も iPhone のヒットアプリを作るひとの行動や思考様式が覗き見られ印象深い。 まず Technology はギリシャ語の tekno と logia をあわせた言葉で logia は(人文科学的な文脈での)サイエンスなのだから、テクノロジー関係者は人間のこともわかってないとかん！ と挑発するつかみで話を切り出し、クールで金になるアプリをつくるには何をどう考えれば良いかと議論を進めていく。 デザインでイノベーション！ なんて言われると浮き足だつ人、IDEO の本 や 37signals の冊子 が好きな人には楽しめる内容だと思う。 Reputation を根拠に安直な early release を批判する部分には iPhone アプリ開発者の真髄を見た気がする。昨今もてはやされているハッカー至上主義とはちょっと違う視点で面白かった。

Appsterdam

私がいちばんおどろいたのは後半。 やや唐突にはじまった “Appsterdam” に関する熱っぽい語りだ。

アプリケーションをどのプラットホーム向けに開発すべきかを論じるなか、 Mike Lee はプラットホームとはみなそれぞれ違い、互いを比べるのはナンセンスだと語った。 プラットホームはテクノロジーではなくコミュニティーなのだから自分の好きな場所を選べばいいのだと。 Mike Lee 自身はとても熱心な Apple ファンで、 Apple 勤務時代は WWDC でエバンジェリストのようなこともしていたらしい。 そうした経験もプラットホーム=コミュニティ論を裏付けているのだろう。

開発者のコミュニティは素晴らしいところだ、なぜなら人々にはそれぞれビジョンがあり、 競合しうる同業者も利害関係を超えて互いに助けあうからだ・・・そう話はつづく。 そしてこの開発者コミュニティというアイデアをもっと推し進められないかと考えた Mike Lee は 稼いだ金で一年間世界を飛び回り、アムステルダムにアプリケーション開発者のための理想郷を作ると決める。 それが Appsterdam である。

講演の後半 1/4 は Appsterdam の理念とアムステルダムやオランダの素晴らしさを延々と説いている。 あいまいなヨーロッパへの羨望と Mike Lee 独自のピッチが相まって、 自分もオランダに住んで iPhone アプリでもつくろうかな、という気になってくる。 私はドメスティック・マインドな会社員なのでだいぶムリなかんじだけれど、 フリーランスや小さな会社で iPhone アプリを売っている人が見たらちょっと心が揺れるんじゃなかろうか。

それにしても Mike Lee はソフトウェア産業の中心で働くちゃきちゃきの西海岸バレーっ子なのに、 なぜわざわざ他所の国に行きたがっているのだろう。 動機は Appsterdam のサイトにある能書き を読むとわかる。ようするにアメリカ（とカルフォルニア）の政治/経済システムがダメということらしい。 サンフランシスコの治安は悪いままなのに投資家がつくったバブルのせいもあって物価や 起業のバーは軒並み上昇中だし医療制度もひどい、などなど。このへんは講演の中でも散々罵っている。

結局シリコンバレーの成功をつくったのは投資家や政府じゃなくてエンジニアなんだから、 エンジニアがあつあってコミュニティをつくれるならもっといいとこあるんじゃね？ そう考えた Mike Lee は調査の末にアムステルダムが気に入って移住し、 仕事をしつつ Appsterdam をはじめることにした…というあらすじのようだ。 Appsterdam のメンバーになると、オランダでの各種イベントに参加できたり Appsterdam 界隈での仕事場所を用意してくれる。 たまに東京でも耳にするノマドブームのスケールが大きめのやつ、と理解すればだいたい合ってる気がする。 実際やってることは大差なさそうだけど、野望がやや大きい。

Richistan

最近たまたま ザ・ニューリッチ という本を読んだ。これは 2006 年頃に書かれた本で、 原題は Richistan という。 著者はハイテクや金融などからうまれた新興金持ちが まるで別の国で暮らすかのようにアメリカから浮遊している様子を描いている。 その架空の国を著者は Richistan と名付けた。

アメリカのスーパー金持ちが国家の縛りを逃れてヒコーキ(ファーストラクラスや自家用機) で飛び回りながら別の時空(ハイアットとマリオット)で暮らす様は ”コミュニティ - 安全と自由の戦場” でも議論されていた。 2009 年の金融危機でいくらかダメージはあっただろうけれど、 そういう人々はまだいるのだろう。

Appsterdam にも似た空気を感じる。 Mike Lee は連続起業家と言ってもいいヒットメーカーで、 よその国に移って仕事をしつつコミュニティをまわせる財力と求心力を持っている。 やってることはオランダに引っ越して NPO を始めただけ(!)なので Richistan で描かれたほどの派手さはないけれど、 国家の不備を独力で切り抜ける姿勢には通じるものがある。

数百万世帯を擁する Richistan 人同様、 Appsterdam 人にも多くの仲間がいる。西海岸のアプリ開発者コミュニティはいまとても景気がいい。 少し前に Forbes は The Rise of Developeronomics という記事でハイテク企業による人材買収合戦の激しさを描き、良いソフトウェアエンジニアを雇うこと/良いソフトウェアエンジニアであることがいつになく大きな財産になったと書いた。 WIRED もびっくりの煽りぶりだ。

その WIRED には The Hackathon Is On: Pitching and Programming the Next Killer App と題した記事が載った。サンフランシスコで開かれたとある hackathon に記者自らが参加して飛び込み取材を行い、野心溢れる若者とそこに群がる投資家や採用担当者の鼻息を伝えている。見ての通り The Next Killer は “App” にかかっている。 こうした hackathon は将来の Appsterdamian を育む場でもある。

Appsterdam は Mike Lee のやる気やソフトウェア業界の景気といった不確定要素に成功を左右される先行き未知数の試みだ。一方で Richistan で描かれたスーパー金持ちの政治介入や道楽よりはずっと慎ましく、手堅くも映る。問題にフォーカスして小粋に片付ける創業者のスタイルが透けて見える。 Y Combinator が Paul Graham のハッカー気質を反映して小さく反復的に成功したのと少し似ているかもしれない。コードで材をなした人間が自身の価値観を下地にコードを超えて活躍の場を広げる姿には、遠い世界の出来事とはいえ励まされる。

始まって 1 年弱の Appsterdam は今のところそれなりに活動してる様子。 iPhone アプリ開発で暮らしている、暮らそうとしている各位はぜひ MacBook 持参のうえ一ヶ月くらいオランダに立ち寄り、現場を覗いてきてほしい次第であります。

画像:

• http://dribbble.com/shots/179966-Appsterdam
• http://www.flickr.com/photos/bcnbits/318930754/

私はこのごろ野良翻訳からほとんど興味をうしなっていたけれど、 今回は釣り針がキラキラしすぎにつきつられてみました。ヒマな人はごらんください。

• https://github.com/omo/Lord-of-the-Files/blob/master/Lord-of-the-Files.ja.md
• ほぼ 1-pass で無推敲につき、さらにヒマなかたは適当にフォークしたバージョンをつくられるといい暇つぶしになるかもしれません。 Pull request ごっこしましょう。 -> Upstream されたので pull request は本流にどうぞ。
• 表題の Lord of the files は「蠅の王」なのだけれど、 GitHub はどう考えてもせいぜいネコの王がいいとこなのでそれらしい直訳になっております。お察しください。
• あわせてよみたいもじょ先生本人による起業ストーリーは こちら.
• GitHub グッズ販売は こちら
• 一方 Google Code の git は Python で BigTable らしい。まじで…

ある朝会社にいくと git.webkit.org がダウンしている。仕事にならない・・・。 意気消沈したが くだを巻く口実ができたとウェブをひやかしていた 少し距離をおいて日々の業務を見直すいい機会だと調べものをしていたところ ソーシャルコーディングの講演で使われたスライド が紹介されておりふんふんと眺めた。

ソーシャルコーディングというのは　GitHub なんかで fork と pull request みたいな対話を通じ 友達百人できるかんじですすめる民主的で人類賛歌なソフトウェア開発のことを指す(と私はおおまかに理解した)。 たしかに GitHub で送った pull request が “Nice! Thanks!!” とかいって受け入れられるとうれしいよね。 プログラマやっててよかった気分になる。

私が仕事でやっているのはコミッタレビュアそれ以外の身分差別と中央集権型 SCM, キメてもセキュリティホールができるだけのプログラミング言語からなるプロジェクトで、 ソーシャルコーディング講演の文脈ではルネサンス以前、 いわば暗黒時代の荒野みたいなソフトウェア開発にあたる。

そんな殺伐プロジェクトだけれど、一方でけっこうソーシャルぽさを感じるところもある。 ただここでいうソーシャルはソーシャルは人間賛歌というよりウェブ用語のソーシャルで、要するにグラフがあったりするあれ。 暗黒時代の西洋人もたぶん人付き合いはしてたろうから殺伐としたプロジェクトにソーシャルグラフがあっても不思議ではない。 そして私がかんじるソーシャルぽさの原泉にはプロジェクトの Bugzilla がある。 ソーシャルぽさ…もうちょっと具体的には Twitter ぽさが、 20 世紀の BTS である Bugzilla からなぜか流れ出している。妙な話ではある。

Bugzilla Stream

多くの BTS 同様、 Bugzilla にはメール通知が備わっている。 自分に関係するバグに変更がおこるとメールが飛んでくる。 このメールを Gmail で jjjkjjj と消化する気分がなんとなく Twitter ぽい。 大半のどうでもいい通知のなかに、ぽつりと興味ぶかいものが混じっている。

モダンな BTS が大抵そうであるように、 Bugzilla は単なる BTS ではなくタスク管理ツールでありコードレビューツールでありパッチマネジメントツールでもある。 原則として全てのチェックインには対応するバグがあり、そのバグにはコードレビューの記録が残っている。 古いソフトウェアなので UX は最悪なものの、依存関係をもつバグやタスク、パッチをはじめとする各種添付ファイル、コードレビューまでが統合された Bugzilla のデータモデルはなかなか本格的だと思う。

そんなツールの性質上、各開発者の動向は多くの部分が Bugzilla 上にあらわれる。 作業をはじめるならバグ(チケット)をつくるし、大きな作業ならそれに加え依存関係の中心に「メタバグ」を登録する。 (“meta” と検索すれば具体例がみつかる。) パッチを書いたらアップロードする。アップロードしたパッチがレビューされコメントがつく。 そのフィードバックを反映してアップロードしなおす。同意、賞賛、罵り合い。 パッチが合意に至るとどこからともなく bot がやってきてパッチをツリーにコミットする。 コミットしたパッチがツリーを壊すとパッチは revert され、テストやビルドの失敗がコメントに記録される。

この一連の出来事が逐一メール通知で届く。

Follow

Bugzilla には誰かのアカウントを watch する機能がある。誰かを watch リストに登録すると、 その人の Bugzilla での行動が逐一通知されるようになる。これは Twitter の follow にちょっと似ている。 私はチームの同僚のほか、作業範囲が被るよその会社の人数名を watch している。 一時期は有名人を watch していたけれど流量が多すぎて挫けた。このへんも Twitter ぽいかもしれない。

Watch した結果、たとえば follow 相手が投稿したパッチをすかさずレビューしたりできる。 まわりの人の仕事の様子がなんとなくわかる効果もある。 たとえばチームのミーティングでは細かい実装の順番なんて話をしなくても、 登録されるバグから予定が透けて見える。

野次馬としては follower 数のランキングやグラフ構造に興味がある。 残念ながら Bugzilla はその情報を公開していない。

Favorite / RT

それぞれのバグには報告者や担当者のほかに CC リスト がある。 コメントやパッチなどバグに動きがあると CC リストの面々に通知がいく。 CC リストは誰でも変更できる。だからあるバグの進展を見届けたいなら CC リストに自分を入れておけばいい。

CC リストにはバグへの関心を示す意味があり、その意味で favorite に似ている。 CC リストに入った事実は follower にも知らされるから同時に RT 的といえなくもない。 ホットなバグの CC リストは 10 人 20 人と膨らんでいく。

Google Code など最近の BTS によっては star をつける favorite 機能そのものを備えているけれど、 暗黒の荒野にそんな優しさはない。 CC リストに並ぶのも善意や好意だけとは限らず、やんちゃな変更に睨みを聞かせる用心棒の視線かもしれない。

Mention

CC リストには自分のアカウントだけでなく、他の誰かを登録してもいい。 パッチのレビューをたのむときは、レビュアの候補を CC リストに登録した上で、「すまんがレビューたのむ」とコメントを書く。 意見を求めるとき、持ち主の決まらないバグの担当を探すときなど、レビュー相手以外も CC リストに追加される。 誰かをよびだすこのかんじは mention に似ている。

多くのコードレビューシステム同様、 Bugzilla にも明示的にパッチのレビュアを指名する機能がある。 けれど件のプロジェクトでは意図的にその機能を外している。これは指名された人間以外にレビューの機会を与える利点がある。 一方で面倒そうなパッチは誰もレビューしたがらず放置される欠点もある。 ただ組織をまたいだ誰かにレビューを課すのはどのみち現実的ではないから、この判断は妥当な気もしている。

Hashtag

Hashtag… に直接該当するような機能は Bugzilla にない。さすがにね・・・。

特定の話題に関する発言をまとめるという意味では、 metabug (master bug) は遠からずなかんじ。 関連のあるバグ/タスクを統括する metabug を個々の具体的なバグに依存させておけば、 その metabug の CC リストに入るだけで依存先バグの変更が通知される。これを hashtag 的に使うことはある。 実際には一部の状態変更しか通知されないのだけれど、あまり困ることはない。

Bot

Twitter 上には多くの bot アカウントがある。 Bugzilla にも多数の bot が生息している。 日頃お世話になっているのはアップロードしたパッチのビルドが通るかをチェックしてくれる親切 bot と レビューの済んだパッチをコミットしてくれる commit bot。 そのほかパッチの中身から妥当なレビュアを割り出して CC リストに追加するおせっかい bot などがいる。

普段は IRC にいる bot がたまに Bugzilla にやってきて伝言を残すこともある。 「このパッチはビルドを壊したので revert したよっ」などと言い残していく。

Discover

さいきん Twitter の UI に追加されたはやりの話題がわかるやつ。も、 やはり Bugzilla にはない・・・

もっとも Twitter と違い、プロジェクトの Bugzilla に何億人ものユーザはいない。 だからプロジェクトの コミットログ を読めば、 ハイテクデータマイニングがなくても割となんとかなる。 コードレビューとの兼ね合いから、プロジェクトにはコミットログを詳しく書く習慣がある。 おかげでひと通り目を通すと熱心に開発されている箇所がわかる。

専用クライアント(がほしい)

このように Bugzilla は荒野でおきた身辺事情をくまなく伝える暗黒時代のソーシャルメディアとして機能しているのだけれど、 あいにく UX がぱっとしない。 この通知は誰かが私を mention したのだろうか、それとも follow している誰かの動向か。 一日数百通届く通知からはそうした文脈がわからず、ひたすら未読メールとして降り積もっていく。 当初はフィルタやラベルづけをがんばろうとしたけれど音を上げた。 各人の Dashboard, BugzilDeck があればどれだけ救われるか。 ソーシャルコーディング本家の GitHub が羨ましい。ダッシュボードもあるし、コメントではアットマークつきの mention だってできる。

最近は通知メールを処理しきれず無視することが増えた。 かわりに隣の同僚などから物理的にレビューをつつかれている。ごめんなさい・・これが Bugzilla 疲れってやつか・・・。

GitHub ほどの個人志向でなくても、 BTS はもっとソーシャル風味を強めることでよくなるだろう。 Teambox などグループウェアの中にはチームプレイの対話的側面を強調したものが増えてきた。 ソフトウェア開発向けツールもはやくそうなってほしいとおもう。

その他のメディアたち

プロジェクトでは Bugzilla 以外にもいくつかのメディアが対話を担っている。 真っ先に思い浮かぶのは メーリングリスト。 ただメーリングリストに流れる話は重要ではあるものの、議論として面白い投稿はそれほど多くない。 リストへの投稿はプロジェクト全体に向けられたメッセージだから、誰かと対話しようという意思が薄いのだろう。 それに参加者が多いほど立ち入ったことは話しにくくなる。野次馬にとって白いのは圧倒的に Bugzilla だと私は思っている。

もうひとつの対話チャネルは IRC. IRC は逆にとてもソーシャル・・・というかくだをまいてる感じがして、 有益さはともかく私はけっこう好き。挨拶や雑談がとびかうのは IRC だけだ。 常連が Bugzilla の URL を交換しレビューをせがみあっている様子もみられる。 ちょっとずるい・・・実際、 Bugzilla 上ではなかなか反応のないレビュアをつかまえる裏口として IRC を使うことはある。 東京からだと時差でしんどいのが欠点。

気楽さが過ぎてお互いのパッチにケチをつけあっているうち険悪なムードになる場面もあるが、 そういうのがすぐ流れて消えてしまうのも IRC のいいところ。 ウェブブラウザの開発者が HTTP 以外のプロトコルに依存している事実だけは若干後ろめたい気もしている。

最後の対話パスは オフラインの meetup. こういうところで普段話せない人と話すのは楽しいし、 オンラインだと険悪になりがちな話題に決着をつけるなら顔を合わせて議論するほかない。 そういえば GitHub の東京 Drinkup は行きたかったなあ. Rails も Node.js もわかんないのでハブられそうだけど…

荒野の人情

Bugzilla 通知の消化、メーリングリスト購読、 git log 閲覧, IRC での世間話… こう並べてみると、私は結構な時間をプロジェクトのソーシャルメディアに費やしている。

Twitter をやらなくても日々を暮らしていけるように、 プロジェクトのソーシャルメディアと距離をおいて仕事をすることはできる。 会社員生命に関わる情報は向うからやってくる。 くだをまいてるヒマがあったらコードをかいた方が、たぶんだいぶ仕事ははかどる。

私は目の前に読むものがあるとついひやかしてしまう。あげくの果てにそれで疲れてしまう。だいぶ中毒っぽい。 ただこの中毒的メディアにも少しはいいことがある。

まず、メディアの中に身を投げれば流れがわかる。いま泳ぎやすい場所がわかる。

たとえば Bugzilla をぶらぶらしていると、 いつか直したいと思いつつ放置していたダメなコードに誰かが手をつける場面にでくわすかもしれない。 これはチャンスだ。一人だと手に負えない仕事でも二人ならさっと片付くことがある。 プロジェクト固有の事情もある： お互いレビュアだと相互レビューができてるから仕事の進みがいい。

後回しにして積んでおいた未実装の機能に誰かがパッチをよこすこともある。 そんなときはささっとレビューしてしまおう。仕上がったパッチがチェックインされれば私の仕事は少し進む。 書き手の成果は少し増える。おたがいうれしい。通知を無視していたらしばらくは見逃していたことだろう。

流れに身を任せるだけでなくちいさく声をあげると、流れ自体がかわることもある。

たとえば私はときどき冷やかしで、仕事とは関係ないパッチもレビューしている。 するとたぶん相手から反応のあるレビュアだとみなされるのか、次のパッチでもふたび CC されたりする。 勤務先が同じとおぼしき別の開発者からも CC されはじめる。何かが伝播している。 同業者の性格やレビューへの反応はプロジェクト参加者にとっていい話の肴だろうから、 なにがおきたかは想像がつく。私もよくその手のゴシップで同僚と盛り上がっているし。

色々な事情で本業にヒマができると、適当にみつけた面白そうなバグをなおす。 仕事や寄り道の途中でみつけた見るに耐えないコードを手直しすることもある。 こういう雑用では勤務先以外の人からもよくレビューをうけるため、段々とある種の顔見知りになる。

顔見知りになると、大きな変更の初手のような一見自明でない変更も相手にしてもらえることが増える。 たぶん同じパッチを通りがかりの身で書いても放置されるとおもう。 信頼を得た、グラフの次数が増えた、そう感じる瞬間がやってくる。

もうすぐ今のプロジェクトで働き始めて二年になる。 今は最初のころよりもだいぶ自由に身動きできる。今のほうがずっと楽しい。 それはコードベースへの理解が深まったのと同時に、人々の中に自分の根が広がったからでもある。 バグとパッチで切り結ぶ荒くれものばかりとおもってた荒野の根城に居場所がみつかる。 ソーシャルコーディングというよりワイルドコーディングってかんじだけど、それも悪くない。

写真: http://www.flickr.com/photos/jay_que/2809782040/

同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。

もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもなければ経営者でもないけれど、なりゆきからオープンソースなコードで仕事をしている。 そこで私個人がオープンソースな仕事のコードをどう感じているか、どんな風に嬉しいのか、 ヒラ従業員からみたオープンソースの話を書いてみたい。

一応事前にあやまっておく(?)と、基本的に仕事のコードがオープンソースなのはいいですよウヘヘ という自慢話なのでそういうのが嫌いなひとは適当にスキップしてくださいね。

職探し

もじょ先生は、仕事コードをオープンソースにしておくと雇用の役に立つと主張している。 該当プロジェクトにパッチを送ってくれる開発者がいたら、その人は潜在的なヘッドハント候補になる。 プロジェクトに興味を持ってくれているし、なによりパッチをみればコード書きの腕前がわかる。 ややこしいインタビューなんて必要ないという。

雇われる側にも同じことが言える。 オープンソースのプロジェクトなら、 ある職場で働くと決める前にコードをみることができる。 これはその職場で働くかどうかの決断を後押ししてくれる。

職場を移るとき、行き先のコード品質はいつも大きな不安のもとだ。 もし仕事でさわるコードがひどいものだったら… 月曜の朝、またうんざりなコードをいじる日々がはじまるのかと絶望する自分を思い浮かべて足がすくむ。 デスマ、薄給、トンガリ頭とおなじくらいこわい。あるいはもっと。

私は今の勤め先が公開するコードをいくつか眺めていたし、 いまのプロジェクトのコードも覗いていた。 だから仕事を始めるにあたりひどいコードへの不安はなかった。 それほどすばらしくない部分があることもわかっていたから、叶わぬ過剰な期待もなかった。

良いソースコードは良いエンジニアリング、よいプログラマの証左でもある。 コード自体は良いのに周りのインフラやプロセス、 コードを書いたプログラマがダメなことは少ない。 コードのスナップショットだけでなく、 レポジトリの履歴やバグトラック, CI のダッシュボードなども公開されているなら 仕事の様子をもっと詳しく見ることができる。実際にパッチを送ってみることだってできる。 一日のコミット量やパッチの粒度、ブランチの使い方、インフラの自動化具合、 バグやパッチをめぐる議論の口調、ツリーの greenness。 自分が迎えるであろう一日を思い浮かべる材料は事欠かない。 自社のエンジニアリングに熱弁を振るう blog 記事や豪華ランチつきオフィス・ツアーもいいけれど、 個人的にはコードやバグトラック、メーリングリストのように仕事の様子が見える方が信用できる。

実際、まともなコードとクリアなワークフローの上で仕事をするのは気分がいい。 自分が正しいことをしていると思える。遠くまで視界がひらけていている。 でも私がこう書いたのを読むよりは、該当プロジェクトに パッチを書いてチェックインするまでを見届ける方がわかることは多い。 会社説明会よりインターンの方がいろいろわかるのと同じ。 良し悪しだけじゃなくて好みもあるしね。

パッチを書くなら、 3-4 個は試してみたほうがいい、 プロジェクトの規模が大きいと、最初はしきたりを理解するだけでくたびれてしまう。 そういえばプロジェクトの規模がわかるのもいいところ。

自分のものなかんじ

愛着のある仕事のコードはどんなものだろう。 これまでに書いたコードを振り返ると、自分が多くの部分を書いたものには愛着を感じた。 半分・・・は無理でも、ある規模のコードで 2-3 割を占めれば愛着がうまれる。 そんなコードを書いた職場やプロジェクトを移るときは、 もうすこし良くしてあげたかったと心残りがある。

この愛着は所有感の表れだと思う。 自分の書いたコードは自分のもの。自分自身の断片、自分のものである以上はよくしてあげたい。

もちろん厳密にいえばこの所有感はまやかしだ。 仕事で書いたコードは勤務先のものだったり、 受託開発だったら多くは発注者のものだろう。

相対的にみると、有期のプロジェクトが終わると納品されてさよならになる 受託開発のコードは愛着を感じにくい。別れがくるとわかっているから。 勤務先のために書くコードはもう少し愛着をもちやすいけれど、 終身雇用なヒトでもない限りいつかは別れがやってくる。 実際は職場を変えなくても自分がプロジェクトを離れたり。 プロジェク自体がキャンセルになればコードはいなくなる。 そうわかっていても愛着を感じてしまうのは、 投じた労力への後ろ髪、そしてコードの大半を書いた人間がもつ実質的な影響力のためだろう。 たくさんコードを書いたら、そのコードの行方に少しは口を挟める。

オープンソースのプロジェクトは愛着を持ちやすい。 コードが誰かの独占的な持ち物ではないからだと思う。 自分の意に反してどこかに消え去ってしまう心配が少ないから心を許せる。 明文化されていない「実質的な」影響力に頼らなくてすむ。

私が仕事でおじゃましているプロジェクトの中で私が書いたコードは 1% 未満だけれど、 それなりにプロジェクトへの愛着はある。 特に自分が手を入れたモジュールは良くしてあげたいと思える。

Your mind can be on it.

コードやプロジェクトへの愛着は仕事を離れても続く。 たとえば WebKit の IRC channel には、勤務時間に限らず常駐しているメンバーが多い。 真夜中に “good night” と退室していく人をよく目にする。 こうした常連にとって、 WebKit は生活の一部になっている。

私は IRC が好きではないので勤務中以外は常駐していないけれど、 それでも仕事のことはよく考えているし、プロジェクトの比較的立ち入った話を ウェブに書いたりワークショップで話したりするのは割と好きだ。 だから仕事の話をおおっぴらに書ける今の perk は私にとってだいぶ嬉しい。 コードをみながら具体的な実装の話を書けるのはいい。

Chromium 用の高速ビルドツールである Ninja はなぜか github にホストされており、 プロジェクトが余暇にうまれたことを示している。これも愛着の表れとみていい。

オープンソースな仕事でなくても、仕事のためのツールやライブラリを余暇に書いて公開しておき、 それを仕事に持ち込んで使うことはある。特に Web で仕事をする人にはそんなところがある。

仕事のプロジェクトがオープンソースになっていると、こうした仕事関係余暇ハックの敷居はさがる。 余暇のコードが本業のコードに依存しても構わないため、依存関係の制限が少なくなるからだ。 本業のコードから独立した部分をうまく抜き出し、仕事以外で使えるツールに仕立てることもできるだろう。

Twitter の Jeremy Cole は、 ある講演 の中で オープンソース仕事の良さをこんな風に説明している:

One of the main things that open-source gives us is the ability to take the work with you wherever you go, and not have to worry about being changed what you are working on, or feeling like you are just doing a day job.

You can feel like you are building something that you can keep and that lasts really long time. You are sure the company couldn’t just kill the project because the code is out there, and if they did, you could keep working on if you really liked it.

See. You can free to think about how you are building it, how new architecture it should have, and all that.

While you take a shower, while you are driving around or whatever you are doing, your mind can be on it.

And that is one of the awesome things in open-source.

愛着のある仕事コードがオープンソースであることの良さを端的に説明していると思う。 かつて MySQL に勤めていた Jeremy Cole は退職後も MySQL にパッチを書いていたというからなかなか説得力がある。 Twitter 自身にも、もじょ先生のいう積極的なオープンソース化を地でいく所があるよね。

ほしいと言ってみる

余暇ですごいコードを書きオープンソース化してプロジェクトを育て、 その実績を勤務先に認めさせて仕事に持ち込む。 そんな方法が、お仕事オープンソースの実現パターンとして知られるようになった。 スーパープログラマの努力が認められるのは素晴らしいと思うし、 これをやってのけた人々はすごいと思う。

私は自分のコードをオープンソース化するのに何も努力していない。（※仕事はがんばってます。） 昼間書いたコードが勝手に表に出ていく。 プロジェクト開始時のメンバーたちは今の状態をつくるのに何らかの労を割いたことだろう。

先に書いたとおり、仕事コードがオープンソースなのはいろいろと良いことがある。 だからできればガッツあふれるスーパープログラマ以外も オープンソースなコードの上で仕事ができた方が楽しいと思う。 根性と才能があればオープンソースを仕事に出来るというのは、 仕事と子育てを両立し出世街道を邁進するハイパーキャリア女子を 雇用機会均等の証にするみたいでやや居心地が悪い。 たぶん私には余暇で書いたコードを仕事に持ち込む実力も根性もない。

これは私個人の印象なのだけれど、 「仕事のコードがオープンソースだと嬉しい」という主張は プログラマにもプログラマ以外にもあまり認知されてない気がする。 コードの読み書きに興味がないとぴんとこない話だろうし、文句は言えない。

けれど認知が広まれば、たとえば茨の努力ルートに入る前に まず今書いてるコードをオープンソースにしたいと言ってみれば、 案外するっと話が進んだりしないだろうか。楽観的すぎるかもしれないけれど、 福利厚生としてオープンソースが喜ばれると経営者や管理職が認識すれば 願いが聞き届けられる可能性は上がると思う。

世にある景気のいいソフトウェア会社の中には、 プログラマ獲得のためにけっこうな予算を割いているところがある。 入社時にいくらか余計に現金を払ったり、高級な椅子、広い画面、おいしい食事を用意したりする。 これはどれも素晴らしいものだと思うけれど、たぶん結構高くついている。 プログラマばかり優遇するせいでプログラマ以外の同僚ににらまれたりしないか心配でもある。

コードをオープンソースにするのは、ふつうそれほど高くつかない。GitHub のホスト代くらいでいい。 プログラマ以外の人にとってコードはどうでもいいだろうから、オープンソース化で角が立つこともなかろう。 少なくともプログラマを絶賛募集中の会社にとって、 オープンソース化はプログラマを相手にした割のいいアピールになりうる。 実際、企業アカウントで細々としたコードを公開する小さな会社は東京でも見かけるようになった。

まだそうなっていないプログラマは、 試しに仕事のコードがオープンなのは自分にとって嬉しいとアピールしたり、 仕事で使える Github アカウントがほしいとねだってみればいいと思う。 そして仕事コードのうち表に出しても角が立たなそうな部分　(もじょ先生によれば “almost everything”) を少しずつ仕事用 Github に移して開発を進め、 区切りのいいところで交渉してレポジトリを private から public に flip する。 そのくらい融通の効く会社がたくさんあると、プログラマの仕事はもっと楽しくなることだろう。

ある日、よその会社で働く友達のコミットにバグをみつけた。昼休みにちょこっと直して pull request:

commit 80e62a7654637d9ed930a2818c28b20cc794fcc8 (HEAD, master)
Author: Hajime Morrita <omo@dodgson.org>
Date:   Sun Nov 27 16:30:29 2011 +0900

    エスケープ漏れを修正。グラコロ一個でどうか。

そんな日がくればいい。

tDiary に特に不満はないんだけど、 書いたものを git で管理しつつ手元から rsync で push できる Octopress も なかなかいい子だとおもう。ただはやりものなので廃れたらまた tDiary に帰るかも・・・。

• このページ (かわらず): http://steps.dodgson.org/
• フィード URL: http://steps.dodgson.org/atom.xml
• タイトル写真: http://www.flickr.com/photos/_belial/5929930548/
• git repo: https://github.com/omo/s2p/
• 過去の記事 (2008/08 - 2011/10): http://stepped.dodgson.org/
• 過去の記事 (2003/11 - 2008/08): http://dodgson.org/omo/t/