エンタープライズRails

2006年7月11日

新しく形成されたRailsコミュニティでは、「エンタープライズ」という言葉が汚い言葉になりつつあります。多くの人にとって、その積極的なシンプルさを備えたRailsフレームワークは、過度に複雑な「エンタープライズ的な」フレームワークの対極にあります。

最近のRailsConfでは、PragDaveのオープニング基調講演で、Railsに関する未解決の問題がいくつか取り上げられ、その中にはこれらのエンタープライズ的な懸念事項に対処することが含まれていました。その一例として、複合主キーを持つなど、より多様なデータベース構造のサポートを求める彼の呼びかけがありました。

DHHのこれに対する反応は、これ以上ないほど断固とした拒絶でした。DHHは、最近のWiredの表紙を巧みに視覚的に操作することで、ソフトウェア世界のネオとして自らを投影し、自分がより良い場所に立っていると力強く宣言し、エンタープライズの世界は自分の方に合わせるべきであり、その逆ではないと告げました。この原則を複合キーに適用すると、反応は「ノーウェイ」です。RailsはRailsのやり方を実行し、好まないものをサポートするために自身を複雑にすることはありません。

これは、Railsが「意見のあるソフトウェア」であることを示す確固たる例です。Railsの考え方では、テーブルをオブジェクトと同型に保ち、テーブルに代理の整数主キーを与えると、人生はずっと楽になります。Railsのやり方でプレイすれば、人生は楽になります。そうでない場合は、他のものを使用してください。

私はこの意見のある態度が好きだと告白します。それはおそらく、多くの異なることを行おうとする複雑なツールではなく、1つのことをうまく行う多くのツールで成功する私のUnixのバックグラウンドを反映しているのでしょう。私はRailsの焦点、特定の種類のアプリケーションを選択してそれをうまく提供するという決意が好きです。

この意味で、私はDHHとケント・ベックの間に驚くべき類似点を見出します。どちらの場合でも、制約のある世界を提示すると、彼らは私たちが当然のことと考えている制約を見て、それらを本質的ではないと考え、それらがない世界を作り出します。私にはその資質がありません。私は制約の中で徐々にそれらを押し広げようとする傾向がありますが、彼らはただ知的なダイナマイトをその下に置いて先に進むだけです。だからこそ、彼らは業界に本当に衝撃を与えるエクストリームプログラミングやRailsのようなものを作ることができるのです。

PragDaveの講演の根底には、より深い懸念がありました。私と同様に、彼は人生の多くをダイナマイトを適用できない人々と仕事をしてきました。データ管理グループによって運営され、複合キーで10年間稼働しているデータベースからデータが必要な場合、クールなサングラスをかけて制約を吹き飛ばすことはできません。「組織を変えるか、組織を変えるか」というのがこれに対する1つの答えですが、できない人々はRubyに見捨てられるべきでしょうか？

最後の段落の最後の言葉が答えの鍵です。Railsはエンタープライズの世界を無視するのが正しいと思いますが、それはRubyがそうすべきという意味ではありません。Rubyのようなスクリプト言語の大きな強みの1つは、混沌としたソフトウェアエコシステムの泥沼に飛び込むポストモダン的な喜びです。Rubyは、Railsの意見によって残されたギャップを埋めるための他のフレームワークにとって最適な場所です。

私の同僚であるBadriは、残念ながらあまり参加者がいませんでしたが、これらの1つであるrBatisについて講演を行いました。rBatisは、人気のあるJavaフレームワークiBatis（別の同僚であるClinton Beginが主導）のRubyポートです。このポートは、さらに3人目の同僚であるJonTirsénによって行われています。rBatisはまだ開発中ですが、すでにiBatisを人気にしたのと同じ要素、つまりクエリオブジェクトの層の下に隠そうとするのではなく、SQLの強みを大胆に取り入れていることを示しています。また、Active Record（検証など）から多くの機能を盗み、XMLではなく便利なRuby構文を使用することで、Rubyを最大限に活用することで、その魅力を高めています。（XMLはプログラミング言語のせむし男ですか？）rBatisは複雑なデータベースの問題に対する答えになり得ますが、それでもRails Webアプリに適合しますが、異なるトレードオフが導入されます。SQLに慣れているなら、rBatisはかなりシンプルに見えます。（ところで、シドニーにいるRubyistはいますか？rBatisの作業が遅くなった場合、Jonのサーフボードを誘拐する必要があるかもしれません。）

これらすべてが私たちの視点を傾けます。エンタープライズRailsは矛盾語かもしれませんが、エンタープライズRubyは決してそうではありません。エンタープライズの世界が進む方向、つまりメッセージングの利用の増加、アプリケーションデータベースを備えた自律型サービス、多様性のポストモダンな受け入れを見ると、固まらない接着剤が理想的なツールであるように思われます。

一部の人々は、これらの講演がDavid間に亀裂が生じていることを暗示していると felt ていましたが、さらなる会話から、亀裂は誤解に基づいていることがわかりました（これは mangled な比喩です）。PragDaveの呼びかけは、Railsがこれらのものをサポートすることではなく、より広いコミュニティが方法を見つけることでした。同様に、DHHの反応はRailsのコアチームに関するものでした。これは、rBatisが示しているように、他の人の努力をほとんど制限するものではありません。さらに、DHHは、PragDaveの呼びかけのほとんどはコアと一致していると felt ていました。狭いコアRailsとより広いRubyの世界（Railsを含む）という概念は、両方の懸念をサポートしています。これは、小さなツールを組み合わせる強みです。

ただし、この広いRuby / 狭いRailsという世界観には落とし穴があります。私は基調講演の中で、RailsConfはRailsの失敗の兆候であると冗談を言いました。Railsが本当に成功した場合、Railsは会議を必要とするにはシンプルすぎるからです。しかし、根底にある真実は、RailsがRubyにおけるWebアプリ（エンタープライズアプリでさえも）のキーワードになっているということです。Railsは注目を集めているため、RailsConfにはRubyConfよりも多くのエンタープライズ関係者が出席すると予想されます。この結果、人々がRailsの意見のある性質をRubyに関する声明として聞き、Rubyが適切なエンタープライズ接着剤ではないという印象を与えてしまう危険性があります。それは残念です。