JJUG Cross Community Conference 2007 Fall コミュニティパネル 「Webアプリケーション開発の今後を占う」 - 第1部 ポジショントーク

Seasar代表のひがやすを(id:higayasuo)さん、Spring Framework代表の鈴木 雄介さん、Ruby on Railsの代表の高井 直人さんの3人が、
各フレームワークについてのお話をしました。

Seasar2

×生産性はフレームワークに紐付く
○生産性は開発者自身に紐付く

よって、
生産性を高くする
→開発者の集中力を持続させる
→作業を止めない
→HOTデプロイ

S2JDBC

流れるようなインターフェース→思考をダイレクトに反映できる
(Javaは)静的言語→コード補間が使える→入力で思考が妨げられない

Ruby on Rails Railsの哲学と将来

効率的に開発を行うにはどうすればよいか？
まず、効率とは何か？(ゴールを設定しないことには論ずることは出来ない)

Railsにおけるゴールは？

RailsはDavid Heinemeier HanssonがBaseCampというサービスを開発するために作った。

• Webアプリ
• BaseCampは月額課金でサービス運営

→Webアプリの開発・作っておしまいではなく継続的にやっていく
これを実現するのがRailsのゴールだった

Railsの特徴

• 柔軟性の放棄
  • Convention Over Configuration：設定より規約
• 粒度の大きい記述
  • Web+DBアプリの領域に特化
  • DSL←ActiveSupport
• 自動化・省力化
  • コード生成の活用(最初のテストに失敗するまでの時間を短縮)

Railsの元ネタはオーソドックスなJ2EEパターン
枯れた技術の水平思考(枯れた技術をWebに特化させた)

なぜ成功したのか？

• Optionated Software
  • 頑固なソフトウェア
• Harvested Framework
  • BaseCampという具体的なアプリの開発から始まった

Rails2.0

• ActiveResource
  • RESTfulフレームワーク
  • ROA(Resource Oriented Architecture)
    • Addressability(URIによってリソースを指定)
    • Statelessness
    • Connectedness
    • Uniform Interface

なぜROAか？
Webは、静的ページ→パーソナライズドページ→プログラマブルWebというように進化している。
プログラマブルWeb(ついったーとか)は、クライアントがWebページとは限らないWeb-APIなので、ROAが鍵となってくる。

Spring Framework

Seasar2やRailsとは位置づけが違う

位置づけ

• ビジネスオブジェクトをマネジメントする
• Spring Portfolioのコア
• Glue(のり)としての機能
  • JavaEE APIとの橋渡し

特徴

• 車輪の再発明をしない
  • 既存コンポーネントを使う
• 規約より設定
  • 大変→カスタムXMLで簡略化、アノテーション対応
• 柔軟さ
  • 例えばRails+Spring

その他

• Spring WebFlow
  • フレームワークが流れを保持してくれる。
  • ページ遷移の途中に横入りできない
• 暗黙的な規約はほどほどに
  • 自分(アプリ開発者)の規約は取り込んでいく
• 小規模システムを統合していくのにSpringを使う

まとめ

Springはフレームワークのためのインフラ

おまけ

Rails+Springの話を聞いた感想

ビジネスオブジェクトはSpringで管理するという思想とはおもいっきり相反すると思うけど、
「PHPからRubyへ」(楽天技研の講演会)で、感想として書いた、

ふと思ったんだけど、Railsの各モジュールに相当する
かっちりしてる(けど生産性はあんまり高くない)Rubyのフレームワークがあれば、
アクセスが増えてきたらボトルネックになるところだけそれで作るとか出来ていいんでないかな。

ってのにぴったりのような気がする。
普通にRailsでアプリを作る
→アクセス数が増えてきてボトルネックが見つかる
→そこのModelだけ(全部ではない)Javaで書き直して、Rails+Springでがっちゃんこ
みたいな

休み時間

id:Yoshoriが「XML書かないでYAML書いてたら同じじゃね？」みたいなことを言ってるのを聞いて吹いた。
確かに。