Rubyの新しいWebフレームワーク、Wavesの波に乗る
Rubyに人気があるため、Ruby on RailsやMerb、CampingといったWebフレームワークが誕生した。Wavesという新しいWebフレームワークが最近リリースされたが、 Ruby開発者が興味を持って試してみようと思うような特徴が、Wavesにはある。
WavesはRuby on RailsのようにMVCフレームワークであり、Request Lambda(source)と呼ばれるものを使うが、各マッピングはルールとブロックで構成されている。ルールが要求と一致すると、そのブロックが実行される。 Wavesに独特な特徴の1つである。
Wavesのこの他の優れた特徴には以下が挙げられる。
- 真のコード再ローディング
- ホットパッチング
- クラスタのサポート
- スレッド・セーフティ
InfoQは、Wavesの開発者Dan YoderとWavesについて話す機会を得た。
Robert Bazinet(RB):Wavesとは何ですか。
Dan Yoder(DY):Wavesは次世代のWebアプリケーションフレームワークであり、MITライセンスです。Railsが止めたところから始めてお り、主にそれが理由で「次世代」となっています。スレッドセーフであることやフットプリントが小さいことなど、基本的な事柄もあります。JITR (Just In Time Resources)のような特徴により、DRYは次レベルに押し上げられるわけですが、JITRによってアプリケーション全域でMVCコードの再利用が 容易になるか、アプリケーション全体の再利用さえ可能になります(その理由は、アプリケーションが何よりもモジュールの中にカプセル化されているからで す)。Wavesはよりオープンでかつ拡張可能でもあります。 例えば、容易に自分だけのViewクラスを書いて、ビューの選択もしくはレンダリングの方法を変更したり、モデル向けに別のデータベースプラットフォーム を使用したりすることができます(デフォルトはRuby Sequelです)。「RubyにおけるWebアプリケーション用MVC」という意味で、基本的な考えはRailsと同じですが、数年におよぶRails の使用経験を基に、さらに優れて、強力なフレームワークを開発しようと作り上げたものです。
RB:開発した理由はなんでしょうか。
DY:一言で答えるなら、Campingです。
もう少し詳しく説明すると、私自身のアプリケーションで、Railsの厳然たる限界に達してしまったことが主な理由です。Wavesは実のところ、プラグ インの豊富なセットとしてスタートしました。けれども、本当にリリースしたいと思う段階までは達しませんでした。なぜなら、実のところ、Railsの上に 乗っかっただけの新規フレームワークを作っているとわかっていたからです。普通のプラグインというより、どちらかというと Streamlinedのようでした。また、Railsコードを回避するか、モンキーパッチを当てて、フレームワークの予想行動を本質的に変更していたこ とに気付きました。ですから、Railsの世界で必ずしも他者と調子よく動かなかったのです。ちょうどよい例が、Just In Time Resourcesの初期実装でした。ObjectとModuleではActiveDependencyがconst_missing に優先してコードの再ロードを処理します。この行動を変えたかったので、Railsがしていたことを無効にする必要がありました。私にはObjectや Moduleに触る必要のないソリューションがあったため、Railsのソリューションが好きではありませんでしたが、Railsのやり方という理由で、 身動きが取れなかったのです。
そんなある日、私はCampingを眺めていました。理由は思い出せないのですが、コードの簡潔性に驚いたことは覚えています。その時、ひらめいたので す。Railsに対処する必要なしに、私が望むだけの特徴を持った新しいフレームワークを作れば、事はより単純ではないかと。その時までにどうにか、こう にかRailsのアドオンとして作ってきたものをリリースしようと計画しており、そちらの方がずっと困難の少ない道でしたから、難しい決断ではありまし た。加えて、書き直しの必要なコードがたくさんありました。骨が折れました。けれども、出来上がったコードは、ずっとリーンで、拡張も作業もより簡単に なったと思います。そうしたら、DuckTyped.comのBenがRackを教えてくれて、私がコードに埋もれている間にRackがリリースされ、そしてそれが基本的にぴったり合ったのです。それと同時に、DataMapperとSequelの成熟が進んでいたため、課題のうちのMVC Webアプリケーション部分にのみ徹底的に焦点を当てた、フル機能のフレームワークの導入が可能になったのです。
RB:Wavesは誕生からどの位経っていますか。
DY: Wavesに取り掛かり始めたのは、つい2007年8月のことです。最初のベータリリースは2月初旬でした。ですから非常に新しいフレームワークで、旅は 始まったばかりです。私は保守的なので、私にとってベータ版は「本番使用のための準備が整っていない」を意味します。
RB:Waves を利用してアプリケーションを書くことについて、開発者が試してみて、さらに多くを体験できる最良の方法は何でしょうか。
DY:おそらく最も良い出発点はスクリーンキャストで、チュートリアルを説明していますが、このスクリーンキャストで興味を持ったら、チュートリアルを体 験できます。また、かなり完全に近いRDocsもあります。サポートフォーラムもあり、どんな質問にも、数時間か、遅くとも1日以内に返答するよう努めて います。チュートリアルを体験し、RDocsに入っているものを基に試してみて、フォーラムをチェックして、そして、にっちもさっちもいかなくなったら、 質問すればいいのです。
RB:WavesはRailsのように、MVCフレームワークですね。WavesはRailsとどのような相違があるのでしょうか。
DY:無数の点で異なります。これまでに言ったように、Wavesは「次世代」であり、Railsの進化版です。スレッドセーフであり、フットプリントも 小さいのです。JITRやモジュール内でカプセル化しているアプリケーションなど、アプリケーションの中、また複数のアプリケーションにまたがっての両方 で、再利用にさらに重点をおいています。ルート相当物はRequest Lambdasであり、より強力であり、道理にかなっている場合はMVC行の外に色をつけることができます。また、すべてのコントローラーをまたいで1ヵ 所に、アプリケーションを安全に保持することができます。望みのORMフレームワークにモデルを連結させることができますが、もし1つも使わないなら、メ モリ利用やメモリパフォーマンスにORMを使うことに対し、代償を払うことはありません。例えば、ファイルストレージを使い、そして本当にORMを必要と しない、WavesベースのCMS(コンテンツマネジメントシステム)があります。Wavesには、Railsよりさらにコントローラーから切り離されて いる、一流のビューがあります。例えばレイアウトは、コントローラーではなく、ビュー自体の中で指定できます。同様に、レイアウトを入れ子にするか、 ビューの中からコントローラーメソッドを呼び出せます。もう1つの実に重要な相違は、 Wavesでは本当の意味のコード再ロードができることです。すなわち、コードが再ロードされる前に、自動的にアンロードされ、そのため以前のロードから 残っているアーチファクトが存在しないのです。これがなぜ重要かというと、デバッグが多少容易にはなるだけでなく、LiveConsoleを使って比較的安全にホットパッチを本番コードに当てることもできるからです。両者の違いを示す良い例でしょう。Rubyの中でMVCパラダイムが本当に進化しているのです。
RB:どのようなタイプのサイトがWavesを実行しているのでしょうか。
DY :様々な種類のサイトを動かしているCMSがあり、そうしたサイトにはもちろん、Ruby Wavesのサイト、RubyWaves.com も含まれます。また、Wavesを使ったテーマ構築アプリケーションもあります。こうしたものは元々Rails上で動作していたものですが、現在では Wavesになっています。必要メモリは従来の約3分の1から4分の1になり、コードベースもRailsと比較して小さくなっています。また、再起動不要 で、何週間も動作します。ですから、私は勢いづいています。他のデータポイントも手に入れたいと思っていますが、入手先は自分以外を望んでいます。うまく いけば、間もなく手に入るでしょう。
RB:Wavesはオープンソースですか。もしそうなら、開発者はどのように関与できますか。
DY:WavesはMITライセンスであり、これ以上のオープンはないでしょう。プラットフォームを前進させる手伝いをしてくれる中核的な貢献者の参加を 心から望んでいます。関与への第一歩は、サポートフォーラムで私に連絡し、どういった種類のことに取り組みたいか知らせてください。今のところ、空きが いっぱいあります。やるべきことは山ほどあり、Wavesだけでなく、少しでも意味のあるフレームワークを成功させるには、それに取り組む開発者のコミュ ニティが欠かせないと思います。Waves はRack、Sequel、Markabyの存在から非常に利益を得てきました。RackやSequel、Markabyでは実質的に、本当に素晴らしい オープンソースの取り組みに、多大な作業が任されたのです。おかげでWavesは、MVCグルーの提供に貢献すること、この点の改善だけに集中できるので す。けれども、Wavesをさらに改良する機会はたくさんあります。
RB:Wavesはスレッドセーフだそうですが、これを説明していただけますか。
DY:Wavesは「要求毎のスレッド」モデルをサポートし、異なるスレッドがお互いぶつからないように、要求はミューテックス内で処理されます。 Wavesはクラスタリングをサポートし、Rackを使うので、これがサポートしている唯一のモデルではありませんが、特にRuby1.9がネイティブで OSスレッドをサポートするでしょうから、開発者に選択肢を与えることは重要だと思います。現在のところ、Rubyコミュニティ内でスレッドにとりわけ魅 力があるわけではありませんが、ネイティブのスレッディングがサポートされるようになった途端に、返り咲きするのではないかと思っています。なにしろ、事 がはかどりますから。利点は、動作させるアプリケーションインスタンスをより減らしてスケール可能なことで、パラレルアーキテクチャを活用できる、優れた スレッド実装を有するマシン上では、特にその傾向が強くなります。そしてWavesでは、それがかなり簡単にできます。
RB:Ruby 1.9には「ネイティブ」スレッドがあるのを知って、Wavesが1.9とどのように連動すると思いますか。
DY: Wavesは今のところ、1.9上ではサポートしていないと明言しておくべきでしょう。しかしながら、1.9でのサポートがWaves前進の主な目標であ り、それは1.9にはWavesで活用できる多数の魅力的な特徴があるからだけでなく、スレッドセーフであることが1.9上でのWavesのパフォーマン スを飛躍的に向上させるからです。例えばMerbの皆さんはパフォーマンスについて心配していらっしゃいますが、私がMerbの方たちほどパフォーマンス を心配する必要のない理由のひとつがここにあります。そして、次のリリースでは、WavesをThin上で動作させ、パフォーマンスを向上できるはずで す。けれども、1.9に移行した途端に、もっとずっと面白くなると思っています。
RB:JRubyのサポートはどうなっていますか。Wavesでは、JRubyで完全サポートはしていないSequelを使っていますよね。
DY:その件はおそらくロードマップでは、1.9サポートの後になる予定ですが、提案を聞く用意はあります。Sequel は新規アプリケーションのデフォルトになっているだけで、WavesがSequel に依存しているわけではないことを指摘しておきましょう。しかし、そうは言っても、今のところはパフォーマンスより特徴に重点を置いているため、 JRubyは最優先課題ではないのです。私はSequelの機能の混合が本当に気に入っていたので、それが良い例でしょう。うまくいけば、Waves用の 重要ライブラリは、ロードマップの十分早期の段階で、1.9とJRubyへマイグレーションするでしょう。ここでも、Rubyコミュニティからフィード バックがあれば変更の可能性もあり、とりわけ貢献することに興味のある方がいらっしゃれば、その可能性は高くなります(暗に貢献のお願いです!)。
RB:Wavesの予定について、詳細を教えていただけますか。
DY:第一に、すでに素晴らしい提案をもらっています。その中には、Tenjin、Haml、SassのテンプレートライブラリやThin Webサーバに対するサポート追加が入っており、近々実現することになっています。そして、クラスタリングサポートのバグ・フィックスです。現在は欠けて いるデータベース支援のセッションをサポートに加えることも計画しており、request lambdaも若干改良する予定です。
Wavesのスキーマ反映能力の強化には多大な努力が必要です。今のところ、ここがSequelとDataMapperの弱点であり、WavesにはORMに依存しないスキーマの概念を持たせたいのです。JIT主義をViewsに拡張する上で、スキーマ反映が非常に重要と考えているからです。
テストに最良のデフォルトアプローチを見極めたいと思っています。これまでいろいろなアプローチを使ってきて、RSpecをとても気に入っているのです が、デフォルトのWavesアプリケーションに組み込むのにはためらいがあります。その理由は、検査に関しては現在、Rubyコミュニティに非常に多種多 様な意見とアプローチがあるからです。Sequelはとても簡単に決定できましたが、その理由は、ミグレーションをサポートしていること、Rubyの表現 式をクエリとして容認することで、これは本当に素晴らしい特徴だと思います。しかし、RSpecをデフォルトにすることに関しては、Sequelほど自信 を持てません。ですから、この分野で助けていただけると、非常に嬉しいです。
パフォーマンスへの取り組みも開始したいと思っており、最初は、問題の可能性がある箇所のベンチマークとプロファイリングのみ行います。本当に、これから やるべき興味深いことが山積しています。Wavesはすでにかなりいい線まできていると思いますが、Wavesが魅力的になるかどうかは、Wavesが不 可能を可能にできるかにもかかっているのです。見えているのは氷山の一角に過ぎないのです。ロードマップ項目のリストをhttp://rubywaves.com/roadmapに管理していますので、まだ改良の初期段階ですが、さらに詳細をお知りになりたい方はご覧ください。
RB:時間を割いてWavesについてお話しいただき、ありがとうございました。
WavesのWebサイトには、複数パーツからなるブログを作成するチュートリアル(source)がある。Wavesのセットアップとチュートリアルをやってみたが、宣 伝にあるようにすべてが機能し、すてきなアプリケーションが出来上がった。チュートリアルに続いてスクリーンキャスト(source)も利用可能である。Wavesに関す るこの他の情報についてはWaves Webサイト(サイト・英語)をご覧あれ。
原文はこちらです:http://www.infoq.com/news/2008/02/waves-ruby-framework
特集コンテンツ一覧
かんばん方式を実践する
Vikram Gupta 2013年5月21日 午前4時15分
Javaのパフォーマンスについての9つの誤信
Ben Evans 2013年5月8日 午後8時36分
アジャイルにおけるソフトウェアアーキテクチャ図とNoUML
Simon Brown 2013年5月1日 午後11時54分
本当に自己組織化したチーム
Emmanuel Gaillot 2013年4月30日 午前3時42分
ニーズに合ったESBを選ぶには
Kai Wähner 2013年4月15日 午後9時29分
デザインパターンの自動化
Gael Fraiteur and Yan Cui 2013年3月26日 午前2時34分
こんにちは
コメントするには InfoQアカウントの登録 または ログイン が必要です。InfoQ に登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。
あなたの意見をお聞かせください。