2007年6月26日
Steve Yegge / 青木靖 訳
2007年6月26日
なんて日だろう。John Lamに取り上げられると、Slashdotに取り上げられるよりひどいことになるらしい。私のチームのみんなは一日中私のことを笑っていた。どうしてこんなことになったのか見当も付かない。
雪崩のようなメールにいちいち返答するより、一括アップデートしてしまう方が良さそうだ。
しかしその前にだ、いったい今の私くらい当惑している人間が他にいるだろうか? Foo Campで行われた数々の目を見張るような議論の中で、私が即興でしたちょっとした講演——それにはどういうわけか20分前にテントからはい出 してきたばかりみたいな私の写真が添えられていて、二日酔いで道に迷い、どうして自分がセバストポルの真ん中の原っぱにいるのかも分らない様子で写っており、分ったのは どうも前の夜に朝10時の講演を引き受けたらしいということだけという様だ——ばかりが、あらゆる人のブログに書き立てられる羽目になる。メールの受信箱がどんな様になっているかは言うまでもない。
そう言うのはつまり、Foo Campが本当にすごいということだ。そこでは尋常でなく頭の切れる連中が良く準備されたいかした講演をし、テクノロジーで民主主義を改善する方法からソーシャルネットワークの健全さの計測、プログラミング競技 における中毒的なコラボレーション、オープンソースソフトウェアの未来まで、非常に重要なトピックについて話し合っている。私がここでやったのは脇の下で音を鳴らすことの技術的等価物で、どうにかして準備の完全なる欠如(それにシャワーの欠如)を補おうとする だけだったのだが、どういうわけか帰ってきた時に耳にするのはそのことばかりだ。
やれやれ。
実際はこういうことだ。私はGoogleで働いている。いや、もう少し正確に言おう。私はGoogleで働く特典を与えられている。これは特典なのだ。私の期待もしていないことだ。たとえばあなたが金持ちの叔父を持つだらしのないティーンエージャーで、どうしたわけかそのおじさんはあなたのことを気に入っていて、会員権が年25万ドルするカントリークラブを好きに使わせてくれているとしよう。そんな場合であっても、それがいつまで続くかについて、私より期待のレベルを下げることはできないだろう。それは私の金持ちの叔父さんが長くないからではなく、ティーンエージャーはそんな状況を駄目にしてしまうものだからだ。楽しめる間に楽しんでおくだけだ。
Googleで働くことに加え、私はたまたま過剰に購読されているブログを持っている。実質的な内容はなく、低俗で鼻くそみたいなジョークばかりなのだが。時にちょっと混乱する人がいるようで、私(ティーンエージャー)が寛大なGoogle叔父さんにある種の影響力があるとか、Googleの立場でものを書いているとか、何かそういったナンセンスなことを考える。
現実をちゃんと見るようにしようよ。私はGoogleでは無名だし、大きな海の生き物たちの中にいる、とても小さな気楽な魚にすぎない。実際以上のメタファを使って言うとそういうことだ。そして私は間違いなく他の誰かの立場で話してはいない。
以上のことを前提とした上で、Foo Campでの講演の概要をお話ししよう。私が戻って以来飛び交っている疑問の多くにこれが答となることを望む。
背景情報として、私はカークランドで本当にクールなプロジェクトに入っている。中身については言えないが、正真正銘最高のものだと思っている。話せないけどね。
この最高のプロジェクトは、とりわけかっこいいAjaxのWebフロントエンドを必要としている。より大きなJavaインフラ上の一群のプロジェクトの一部となっているため、私たちのプロジェクトもまたJVM上で動く必要がある。
Googleで働くのがクールである何百という理由の1つは、ある広くて良く定義された制限の中でありさえすれば、チームが実験することを許しているということだ。この大きな遊び場を区切っているフェンスの1つは、プログラミング言語の選択肢だ。GoogleではC++、Java、Python、JavaScriptというフェンスの中で遊ぶ必要がある。
私のプロジェクトの遊び場は、実際それよりもう少し狭い。JVM上で動く必要があるためだ。しかしそれでも依然すごく大きな遊び場には違いない。プロジェクトが比較的注目されている領域にある場合でも、新しいWebフレームワークを試す(あるいは作る)というのは実験の恰好の対象となっている。
私たちの遊び場にあるもう1つの制限はソフトウェアエンジニアリングだ。ユニットテスト、ドキュメンテーション、リファクタリング、セキュリティ、スケーラビリティ、国際化、そのほか、交渉不能な一群の条件がある。
私がGoogleで働くことが好きな理由に、たとえかすかにでも気付いてほしい。それはコードベースがきれいだということだ。1週間以上を要することは何であれ設計ドキュメントを要求され、必ず書かなければならない項目があり、自分で選んだ第1、および第2レビュアからフィードバックを受ける必要がある。これの結果が何かというと、Googleでは意味のあるコードはどんなものであれ、その内部構造について書かれたほとんど本のような資料があり、しかもそれは非常によく書かれている。
私は正直言って、そんなのを今まで見たことがなかった。このようなソフトウェアエンジニアリングの原則を徹底するのは、はじめから正しくやり、組織が成長するとともにその原則が繰り返し補強されていく文化を作らない限り、不可能だ。
ちょっと脱線したが、私の要点は、フェンスの中で遊ぶ限りは、そしてGoogleが提供する分散コンピューティングのための豊かなインフラを愚かにもぞんざいに扱ったりしない限りは、新しいアプローチを実験できる大きな自由があるということだ。
実のところ私はRailsが好きだし、RubyのことはRailsがなくとも好きだ。Webページを作る上でRailsは私がかつて使った中で最高にいい。そして我らがヒロインRailsと彼女の物言わぬ小さな森の仲間、PrototypeとScriptaculousには驚くほど多くの本があり、他の言語によるRailsクローンもたくさん作られているのを見ても、DHHはRailsを作った時に独自で重要なものを見出したのだと思う。賛美。
Rubyはフェンスの向こう側にある。草の上を転がり回って遊んでいる振りをしながら、私たちが中に呼び入れてくれるのを待っている。時には私たちの遊び場の縁まで来て鼻を鳴らすこともあり、そういう時には大きなスイッチが下ろされ、高圧電流が大きな唸りを上げると、Rubyは毛を逆立ててゆっくりと引き下がる。穴を掘ろうとしたこともあるが、しかし･･･どうなったか分るだろう。
実のところ、Googleが製品に使用する言語の数を限定しているのはとても賢明なことだ。ここで働き始めて(率直に言って、どうしてみんな私に履歴書を送ってこないのかと思う)何週間かは苦痛に思うかもしれないし、私みたいなどじな間抜けには、それを理解するのにもう少し時間がかかる。しかしプログラミング言語には誰でも知っているコアの標準的な機能があり、わかりにくいセマンティックスの長いしっぽが それに続いていて理解を難しくしている。PerlやPythonやRubyのような実際の仕様がない動的言語では特にそうだ。Googleは実際的である限りにおいて慎重に言語の数を抑えており、選択された言語についてはセマンティックスのエキスパートの大きな集団を作れるようにしている。
これはまた言語間のインターオペラビリティのために必要となるコンポーネントが指数的爆発を起こすのを抑えることにもなる。私が以前にいた会社ではこれが巨大な税としてのしかかっていたが、Googleは概ねそれを最小化している。
Googleは人がグループの間、あるいは拠点の間を移動することが非常に容易になる環境を作り上げている。もちろんそれに関しては大人である必要があり、すごく忙しく大事な時にチームを抜けたりすべきではない。しかしこのことについて分別ある判断ができるなら、ほとんどいつでも好きな時にチームを変えることが可能だ。そしてそれによって会社の仕事が止まることもない。私が働いたり訪れたりしたことのある他の場所であれば、このようなポリシーでは仕事が成り立たなくなるだろう。
このような環境を作り上げるのは簡単なことではない。しかもそれをスケールさせるというのは間違いなく簡単なことではない。そのレシピにはたくさんの材料があり、この小さなブログエントリで扱える範囲を大きく超えているが、1つ重要なものを挙げるなら、コードベースがプロジェクトやチームや拠点や言語の境界さえ越えて(現実的な範囲内で最大限に)均質だということがある。これによって学習曲線は最小化され、人がグループ間を移動するときの抵抗 も最小となる。
これでRuby on Railsを移植するという決断に私が至った主要な要因について説明したことになる。私はRailsが好きで、カークランドでの素敵な新しいプロジェクトでも使いたいと思った。しかしコードベースの他の部分とのインターオペラビリティのため、JVMの上で動かせる必要があった(これはRPCなんかで解決できる問題ではな く、プログラムをJVM上で動かすことがどうしても必要だった)。JVM上ということによってC++と(ネイティブの)Pythonが除外される。
私に残された選択肢は、Java、Jython、Mozilla Rhino(JVM上のサーバサイドJavaScriptの実装)となった。
RailsのAPIを見ると引数がハッシュのリテラルで受け渡されることが多く、Javaだと分が悪くなる。Rubyにメソッドオーバロードはない。RubyもRailsもvarargsやブロック(関数)パラメタを渡すあらゆるやり方がある。JavaはRubyと違いすぎており、インピーダンスミスマッチがこの移植の努力自体を殺してしまうことになるだろう。だから動的言語でいくことにした。
Jythonは最初もっともな選択のように思っていたが、2001年頃から後、あまり大きな動きがない。かつてはJava以外のJVM言語として最良のものとされていた。これについてはJim Huguninは素晴しい仕事をした。残念ながら、この6年ほどは愛されることがなく、Pythonの仕様からもメジャーバージョンにしていくつか遅れている(もうじき2.6になるのに2.2のままだ)。
それと比べるとRhinoには大きな勢いがある。Jythonよりも古くからあり、SpiderMonkey (Netscape/Mozilla) JavaScript C エンジンの移植として始まり、パフォーマンスを意識して書かれている。RhinoコードベースはほとんどCのコードのように見える。メモリ割り当てを避け、仮想メソッドルックアップのオーパヘッドを避けるためジャンプテーブルを使っている。コードパスには2つある。バイトコードインタプリタは緊密なループで動いており、最適化バイトコードコンパイラは高価なJavaScriptプロパティルックアップの多くをJavaのローカル、あるいはインスタンス変数ルックアップに置き換えている。Rhinoはとてもしっかり作られたソフトウェアだ。
Rhinoの中身を調べ始めると、予期しない深みを見つけることになる。JavaScriptは(少なくとも今日のPerl、Python、Rubyと違い)本当の仕様を持っている。そしてRhinoは厳格にそれに従っており、SpiderMonkeyとの完全な互換を目指している(異なる言語プラットフォームで可能な限りにおいて)。Rhinoはまた設定が柔軟にでき、良く定義されたマルチスレッドセマンティックスを持ち、デバッガやプロファイラのためのフックをそろえており、そのほかたくさんのものを備えている。覆いの下にはすごくたくさんのものがあるのだ。
ああ、それにSunが今ではRhinoをJDKにバンドルするようになっている。Java 6のjavax.scriptだ。このような支持があるときに、他のものを使うことを正当化するのは難しいだろう。JythonやJavaScript以外の言語を候補として考えた場合でもそうだ。
もちろん難点もあ.る。JavaScriptだということだ。そうじゃない?
JavaScriptには確かに変なところがあるが、思い出してほしいのは、今話しているのはサーバサイドJavaScriptであり、しかもJVM上にあるということだ。だからライブラリの不足が問題になることはなく、ブラウザの非互換性も問題にならない。Rhinoは1つしかないからだ。そしてこれは宣伝文句通りに機能する。しかし私たちはさらに一歩進んで根本的な拡張を行い、よりRubyっぽくなるようにした。
1つ例を挙げると、クライアントサイドJavaScriptでは、現在のところ列挙可能でないプロパティを定義する方法はなく、そのためObject.prototypeに新しい関数やプロパティを追加すること ができない。付け加えたものは突然オブジェクトリテラル(JavaScriptのハッシュ)に現われるようになるからだ。Rhinoであれば、列挙可能でないプロパティを定義するには、ただRhinoランタイムを呼び出すJavaのメソッドを作るだけでよく、心ゆくまでObject.prototypeを拡張できる。だから私たちは思いっきりやって、Ruby(それにPython)の組み込みクラス(Object、String、Arrayといったもの)が持つ興味深い組み込みメソッドをたくさん追加した。
JavaScriptは長い中断の後に再び進化を始めた。Firefox 2にあるver 1.7機能の多くはPythonから持ってきたものだが、すごくしゃれている。
Rhinoはまだこれらの機能を備えていないため20%プロジェクトでその追加をしたのだが、これは会社の中のいろんな人が手伝ってくれた。
Googleで働くのがどんなにクールかという話はしたっけ? 何ヶ月か前にRhinoのオリジナルの作者であるノリス・ボイドにその話をしたことがあったのだけど、彼はそれが気に入ったらしい。今や彼もGoogleで働いており、Rhinoの20%プロジェクトは灰色をした大きくておっかないアフリカの陸上動物みたいに猛進している。自分でそう言って構わないなら。
そしてJavaScript 2.0がある。しかしこれを持ち出した時にはFoo Campの人たちに容赦なくやじられたので、これについてはあまり話さなかった。
本日のメニューの最後として、Railsの移植について簡単に話そう。みんな疑問を持っているだろうことが分っているから。しかし実際のところ言うことはあまりない。移植というのはやってみると退屈なものだ。
私は基本的にActionView、ActionController、Railtiesのすべてと、ActiveRecordの一部を移植したが、バックエンドとのやり取りの仕方はかなりの部分最初から制約されている。長期的にはこの話はHibernateになると思う。
コードジェネレータは使わなかったが、それは気に入るものに出会ったことがないからだ。私はただ古き良きEmacsと、山ほどのキーボードマクロを使った。最初はピッケル本に基づくRailsの ｢仕様｣に対して自分で実装しようと思っていたが、しかしすぐにRailsは最も簡潔な実装を持っており、そうなっていない部分はごく少ないことに気付いた(ルーティングエンジンはもっときれいにできると思う。それからメタプログラミングでちょっと余計なところが見受けられる。しかしそれを別にすると、Railsのコードベースは非常にクリーンで驚くほど良くテストされている)。
セキュリティ、パフォーマンス、国際化のサポートのためいくつか拡張をしたが、これについてはまだ詳しく話すべきではないと思う。それからツールサポートも用意した。EclipseとEmacsで使えるできのいいデバッガやそのほかのIDE機能だ。しかし私たちはまた、実際的である限りにおいて極力Railsと互換になるように努めた。だから私たちのチームに新しく入ってくる開発者は(応募しようと思っている人のために言っておくと)、ただRails本を読んでおけば仕事に取りかかることができるだろう。
私たちは"Rhino on Rails"をオープンソースにすることについても話し合ったが、今のところただのおしゃべりというレベルでしかない。1つの問題は、フレームワークの作業は実際のアプリケーション開発 をする合間に、概ね20%の仕事の中でやっているため、進み具合が遅いことだ。もう1つの問題は、私たちのコードは他の様々なGoogleのインフラのコンポーネントに依存していることで、それらのコードもオープンソース化のプロセスの途上にはあるが、そのことがアナウンスされているものがあるのかどうかわからない。
しかし一番大きな要素は、JVM上のRails的フレームワークの世界でどういう事が起きるか様子を見守っているということだ。Railsクローンは他にもたくさんあり、成熟度もまちまちという状態にある。JRuby on Rails、Grails、Phobos、TrimPath、そのほか、たぶん半ダースくらいあるだろう。
これらのうちのどれかが今後2、3年のうちに支配的になり、セキュリティ、パフォーマンス、スケーラビリティ、国際化サポート、そのほかの点でGoogle内部の基準に合う ようなら、それに移行することだって考えられる。
しかしプラットフォームというのは(言語やIDE同様)充実したものになるまでには時間がかかり、ごくゆっくりと進化するものだ。これはオープンソースだろうと社内プロジェクトだろうと変わらない。 フレームワーク(あるいはIDE、言語)はそれを使ってアプリケーションを作るユーザを必要とし、フィードバックサイクルを通じてさらに何年か作業を重ねる必要がある。
私はまったくのところこれがどういう事になるのか分らない。私に分るのは、Rhino on Railsはカークランドの小さなチームにはすごくうまくいっており、Googleの他の拠点にいる好奇心旺盛な人たちも、それが試してみるに値するクールなものになるだろうかと見守っているということだ。
まあそういったことだ。何か忘れていることがあったかな? その場合でも誰かが教えてくれるだろうと思う。たぶん素敵なメモを素敵なレンガに貼り付けて私の窓に投げ込むことで。私が時々受け取るメールがどんなものかあなたは是非見てみるべきだと思う。
正確に1年の後にステータスをお教えすると約束しよう。誰かが思い出させてくれることを条件として。私たちの現在のフレームワークの進み具合だと、そのときまでに面白いことやニュース価値のあることが起こることはないだろう。
このRhinoのエンハンスの情報について知りたい(あるいは参加したい)のなら、Rhinoのサイトをチェックすることをお勧めする。これは楽しみでする仕事であり、彼らはあなたの助けをありがたく思うだろう。
そろそろおしゃべりをやめて、今年の末くらいにリリースできる予定の極秘プロジェクトに少し時間を使うことにしよう。これは本当のマジックで、もちろん明かすわけにはいかない。ただ今のところはそれを"NBE"と呼んでおくことにしよう。NBEはいいものになると思う。
待ち遠しいよね。
| home rss | Steve Yeggeについて |
オリジナル: Rhino on Rails |