MerbはRails 3.0にマージされる

作者 Werner Schuster , 翻訳者 角谷 信太郎 - (株)永和システムマネジメント 投稿日 2008年12月27日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

Ruby ,

パフォーマンス&スケーラビリティ ,

Ruby on Rails

タグ

Merb ,

Rails ,

Ruby on Rails ,

Railsプラグイン

Ruby の Web フレームワーク界の大ニュースだ。Merb と Rails がマージされる。Merb の作成者である(リンク) Ezra Zygmuntowicz は本件をこう説明している。

私たちは、お互いの違いはいったん脇において、全体の利益のために一緒にやれないかどうか話し合いをはじめました。ロードマップを明確にして、Merb の良くできているフィーチャのうちから、どれをどうやって Rails 3.0 に統合するのかを決めました。この計画は素晴しいものになったと思います。Rails は現存するフレームワークのなかで最高のものになるでしょう。Merb を開発して気づいた様々な利点を取り入れつつも、みんなが気に入っている Rails のセンスの良いところは依然として保たれたままになるのです。

Rails の作成者である David Heinemeier Hansson は、Rails の今後について、「Rails 2.3 which will be followed by Rails 3.0」(リンク)で次のように語った。

Rails 2.3 のリリースは目前に迫っています。最後の仕上げを済ませた後、1月にリリースしたいと思っています。大きなインパクトのリリースで、前のめりな機能が目白押しです。ですが、2.3 をリリースしたらすぐに今度は Rails 3 を目指します。

InfoQ で先日掲載した、Yehuda Katz へのインタビューでも、現時点で Merb を Rails にマージするという意見を述べていた (参考記事・英語)。Merb の Rails 3 へのマージにあたっての具体的な変更点は David のアナウンスに詳しいが、Merb 側からは Yehuda Katz が パブリック API などについての説明がされている(リンク)。

Rails 3 の段階では、Rails にテストスイートを備えたパブリック API を定義します。ここが Merb がもたらす大きな違いのひとつです。パブリック API を用意することで、ユーザやプラグイン開発者は、より明快で安定した API を基盤にしたコードを書けます。こうすることで、今後はリリースするたびにプラグインが動かなくなるような事態が目に見えて減っていくはずです。

David は今回のマージの背景を次のように説明している。

厳格な API: Rails のバージョンを上げると壊れてしまうプラグインが多すぎる背景には、どこが問題なく使える内部動作のフックなのか、いつモンキーパッチすべきで、そのモンキーパッチが使えなくなるのがいつなのかがよくわからないからです。Merb 開発チームは、パブリック API にはテストを用意して、壊れないことを保証すると確約してくれました。Rails 3 にはテストとドキュメントの完備された拡張 API が用意されることになります。ということは、バージョンを上げると問答無用で壊れるといったこともなくなります。

Rails 3 は、Merb が心を砕いているモジュール方式も取り入れるようだ。モジュール方式については Rails コミュニティと Merb コミュニティとの間で熱心な議論が交わされた。まとめると、merb-core を踏まえた rails-core が用意され、ごく小さな Web フレームワークとなるようだ。Yehuda の説明によればこうだ。

"core" バージョンの Rails として簡単に始められるような仕掛けを Rails に組み込みます(現在の merb-gen の core generator のような感じです)。最初はモジュールは組み込まれておらず、開発アプリケーションに必要なパーツだけを簡単に選べるようにします。もちろん、引き続き Rails はデフォルトでは "stack" バージョンとしてリリースされます(Merb も 1.0 からはそうしています)。ですが、目標は Rails を現在の Merb のように簡単に扱えるようにすることです。

David の説明によれば、Rails 3 はデフォルトのフレームワークの組み合せを引き続き提供し続けるようだが、他のフレームワークと組み合わせてもうまくやれるようにするつもりのようだ。

フレームワーク不可知主義: 各層でどのフレームワークを選ぶべきかという問いに答えるのが Rails です。テスティングフレームワークについて特に意見がなければ、デフォルトは test/unit です。オブジェクト/リレーショナル・マッピング(ORM) にこだわりがなければ、デフォルトは Active Record です。なかには、他のフレームワークを選びたい人もいることでしょう。テスティングには RSpec を使いたい人もいれば、ORM には Sequel であるとか Data Mapper を使いたい人もいるでしょう。テンプレートは Haml だという人もいれば、Ajax なら jQuery が好みだという人もいます。こうした人々にとっては、Rails が 代替案に門戸を開いたことに満足するはずです。たしかに、デフォルトの組み合せは用意します。ですが、どのようなものであれ、他の選択肢を差別するつもりはありません。

さらに、Merb のパフォーマンス性能が Rails 3 にもたらされることになる。

もう一つ、大事な疑問が残っていた。「Merb を使ってる人たちはどうなるの？」これに対する Yehuda の答えはこうだ。

具体的には、Merb のリリースで非推奨の警告と移行を支援する仕組みを用意して、Merb 1.x から Rails 3 への変更に追従できるようにします。少しずつ Rails 3 に移行していけるように、何度か暫定的なリリースを重ねることになるでしょう。Merb の構成要素(とりわけヘルパーですね)は Rails 3 に移植します。これは将来的な不整合を減らすためです。
断言しておきますが、私たちは Merb を見捨てません。すでに Merb で書かれたアプリケーションが数多く本番稼動しています。そうした環境では、適宜バグが修正されることや、将来の移行パスが用意されることが期待されているからです。

Ezra もこれを補足して、Merb を長らく支援しているスポンサーである EngineYard も Merb から Rails への移行が円滑に進むことに期待していると述べた。

私たちは Merb アプリケーションの Rails 3 への移行パスをきちんと用意します。私たちも数多くの Merb アプリケーションを (EngineYard の) 内部で動かしています。他の誰よりも自分たちのためにも移行パスが必要なのです。

Merbist blog にも今回のマージの件についての情報がある(リンク)。

このマージについて、読者はどう考えるだろうか？

 

原文はこちらです：http://www.infoq.com/news/2008/12/merb-merged-in-rails-30

• 次へ >