「日米トップJ2EEアーキテクトが語るフレームワーク」の未来のみどころ

http://itpro.nikkeibp.co.jp/article/COLUMN/20080416/299267/

Gavin:Railsの中で使われているテクノロジー自体は，それほど新しいものではありません。オールドスタイルとさえ言える。
これは、悪い意味ではなく、テクノロジーが新しくなくても、開発スタイルが新しければ、価値のあるものを生み出すことができるということです。

Gavin:そして，（ソースコードの変更が再コンパイルすることなく即座に反映される）ホット・デプロイメントの重要さが注目されるようになった。この点に関してはJavaのバーチャル・マシン（JVM）はあまり良くなかった。そして，Javaのフレームワークもさらに悪かった。
Javaの世界では、今後ますますHOT deployが重要になってきます。Gavinも私もJVM任せではなく、フレームワークで解決しようとしているところが面白いですね。

ひが：保守については，どう思われますか。
Gavin:静的言語と動的言語を比較すれば，はるかに静的言語のほうが優れていると思います。特に，もともとコードを作成した人たち以外の，あとの段階からプロジェクトに参加してきた人たちにとってのコードの理解のしやすさは静的言語のほうが優れていると思います。
動的言語は、書きやすいので生産性はあがりますが、保守のときには、情報量の多い静的言語のほうが理解しやすいということでしょう。こういうことを書くと、RailsとStrutsのようなかったるい記述の多いフレームワークのソースコードを比較してRailsの方が理解しやすいと主張する人が出てきそうですが、いまどきにJavaのフレームワークは、かったるい記述がほとんどなく、可読性はかなり高いです。

ひが：最近はコンベンション・オーバー・コンフィギュレーション（設定より規約）という考え方に基づきコード記述量を削減する方法が注目されています。
Gavin：コンピュータ業界でずっと長い間インテリジェント・デフォルトといわれていた発想の延長線上にあるだけです。
　コンフィギュレーション・バイ・エクセプション，あるいはコンフィギュレーション・バイ・コンベンションという呼び名はともかく，それらの発想に関しては特に革命的な要素はないと思います。
CoCでさえ、特に新しいものではないということですね。

ひが：RailsのActiveRecordはカラムの情報すら書かない。
Gavin：それはあまりにも行き過ぎた例だと思います。エンティティ・クラスを見て，どういった属性があるかを理解するということは，このActiveRecordコードベースではできないことです。
　しかしよく考えれば，こういったようなクラスというのは最もこのビジネス上の問題の基本的なモデルということになるわけであり，何千というクラスがそれを再利用するわけです。
　Hibernateの場合には，エンティティ定義で，明示的にそれらの属性を一度記述します。そして何千回もオーダリングをするために(Eclipseの)コントロール・スペース(コード補完)を使うわけです。
　ActiveRecordの場合には書くという作業を1回節約できます。しかし明示的に書くためには何千回とタイプしなくてはなりません。極端なところに走り過ぎた例だと思います
　ActiveRecordクラスの上にCommentを自動的に生成するようなプラグインがあります。そんなことはまったく不条理だと思います。そんなことをやるくらいなら，どうして属性として書かないのか疑問です。
ActiveRecordは行き過ぎている。ActiveRecordにカラムの情報を書くのを省略しているけど、そのかわりに利用するほうは、どのプロパティを使うのかを明示的にコーディングしなければいけない。Javaだったら、コードの自動補完が使えるから、圧倒的に楽だよって話。

ひが：(Hibernateの)インクリメンタル・デプロイメントをかなり期待しています。
Gavin：約束はできません（笑）。言えるのは「検討する」ということです。
Entity間の関連をいろいろ考慮しなければいけないので、まず無理だろうといってました。

Gavin：Springを使っているほとんどのユーザーはHibernateとの組み合わせて使っています。必ずしも我々はそういったソリューションを推奨しているわけではなく，私個人としてはSpringのファンではありません
Gavin正直だ(笑)。Springは確かにEJBに苦しんでいた人たちを救ったけど、今となっては、エキサイティングではない(古い)といっていました。