Railsよ,ありがとう

"Thank you, Rails"を翻訳しました。なんか難しかった。
誤訳がたくさんあると思うので,教えていただけるとありがたいです。

                                          • -


Railsよ,ありがとう

jacob Kaplan-Moss
2009/11/05

技術的なコミュニティにとって,ライバルをけなすことはファッションでもあるし,たぶん不可避でもある。Emacsの人々はViをバカにするし,Windowsの人々は我々Macユーザを見下し(そしてLinuxの人々は両者をバカにする),そして誰もが,そのシェアにも関わらずPHPを馬鹿にする。われわれGeekは,些細な技術的なポイントを芸術のひとつでもあるかのように論じる。

これらはよく理解できる。つまりコミュニティは「自分は何者でないのか」という観点から定義する方が簡単なのだ。共通の敵は,我々を集中させ駆り立てる。競争は前向きな形をとることができる。それが友好的で建設的であるあいだは,両陣営の利益となるのだ。

しかし,最近のDjangoコミュニティにおける大量の議論が,特にRailsに関するときに,だんだん険悪になってきていることに私は気づいた。この件に関しては私もとても無実だとは言えない。私も確かにRailsバッシングに加担し,そして私はそれを後悔している。

Web開発コミュニティにいる我々は,RailsRailsコミュニティにはむしろ感謝すべき恩義があると認めることが大切だと思う。Railsは我々のWeb開発についての考え方を見直させ,Railsに触ったこともない人ですら間接的に利益を得ている。

そこで私は思う。我々は個人的な好き嫌いから一歩引いて,Web開発を前進させてくれたことに対して,率直に「Railsよ,ありがとう」と言うべきではないだろうか。

個人的には,Railsから次の二つの大きな教訓を得た。

開発は楽しくあるべきだ

PyCon 2009で,興味深いトピックを議論しているとき(http://pycon.blip.tv/#1941789),Ian Bicking(http://blog.ianbicking.org/)が,Pythonのコミュニティがときにシリアスすぎることを心配していると述べた。

私もそう思う。Pythonを始めたばかりの頃,すべての注目はエンタープライズだった。Pythonは,シリアスな仕事をしているシリアスな企業のシリアスな人々に使われるシリアスな言語になる必要がある。英国のコメディグループから名前をとった言語としてはいささか奇妙なゴールだ。

そしてRailsがシンプルなメッセージ「Web開発は楽しくあるべきだ」でブレイクした。今にして思えば,これは自明の進歩だった。我々の世代の多くのGeek達は,楽しいからという理由だけでコンピュータの世界に入ったのだから。しかし同じポイントで,我々はプログラミングで稼げることに気づいた。そしてお金が入ってくると,楽しさは出て行った。次にドットコムバブルが来た。突如として金はなくなった。シリアスな仕事というやつだ。

しかしRailsコミュニティはこれをひっくり返した。現実にお金を生み出す,小さくて,楽しくて,軽いツールがあるというのに,どうして巨大シリアスソフトを時間をかけて構築すべきなのだろう? 結局自分の仕事を楽しんでいる人たちの方が生産的だと分かった。すごい!

魂を削るようなニューヨークの仕事を離れ,50%の収入減とともにカンサスに移った一年前,私はこの教訓を得た。これは私が成したうちでも最高の決定だったが,「もっと楽しそう」な仕事のためにサラリーの半分を失うことは,そのときは職場の同僚たちからたくさんの非難を浴びた。今日ならこんな批判は浴びないだろうと思う。少なからずRailsコミュニティの掲げた理想のおかげだ。

最近は,Djangoコミュニティにも独自のお馬鹿なタイプがいて(http://djangopony.com/),私を楽しませてくれる。それが少しやりすぎと思う人もいて,私も同意するが,笑い,遊び,楽しみといったものは活気のある健全なコミュニティに不可欠な性質だ。

シンプルさは機能のひとつだ

私がCMSの世界に最初に突入したのはBEA(いまはOracleWebLogichttp://www.oracle.com/appserver/index.html)とVignette(http://www.vignette.com/)を通じてだった。最初の「Webフレームワーク」の体験はStruts 1(http://struts.apache.org/1.x/)で,次がZope2(http://zope.org/)だった。

あらゆるツールは巨大な機能比較表(http://cmsmatrix.org/)を念頭に置いてデザインされているように見える。できるだけたくさんのチェックマークを獲得することがゴールのようだ。CMSの開発は,非常に非常に機能先行で,ゴールはあらゆるケースに対応できることのようだ。

BEAと向き合って,私はこの衝動の強さが理解できなかった。いまフレームワークのメンテナとして,私はそれを「完全に」理解できる。すなわち全てのユースケースの裏側には実世界の開発者がいて,期限内に仕事を終わらせようと努力している。機能の要望に「No」を言うのはとてつもなく大変だ。私はそうすべきだと思うほどは,「No」と言っていない。

「the Rails Way」でも最も議論の余地があるのは,依怙地なソフトウェアというアイデア(ma2注:開発者が何も指定しないとあらゆる面でデフォルトが適用されるということ)だった。ライブラリが開発者に一定の期待をすべきというこのアイデアは,かなり異端に見える。我々はDjangoの世界によりソフトな一面を持ち込んだ。つまり「sensible defaults」のことだ。基本的なアイデアは同じだが,一般的なケースを推測してソフトウェアをシンプルに保つ。

このアイデアはシンプルさを機能のひとつにして,機能比較表を完全に無害化してしまった。チェックマークの列の代わりに,いまや同じ仕事をどれだけ少ない行で実現できるかを比較している。一枚岩の巨大な機能セットは去り,ミニマリズムが登場した。

もう一度Railsに感謝を。我々は全てのわだかまりを捨てたわけではないにしても,君たちがいてくれてよかった。君たちがインターネットをよりよい場所にしてくれたのだから。