JRubyおよびJRuby on Railsは次々と、いくつものプロジェクトで採用されている。Mingle(source)、Oracle Mix(source)、Sunのmediacast.sun.comのリプレース(source)に続いて、また新しいJRuby on Railsプロジェクトが発表された。
プレスリリースより(source)
同じ目的を持った組織同士が低コストでコラボレーティブなソフトウェアを利用できるようにする企業、Collaborative Software Initiative (CSI)は本日、初のオープンソースのWebベースの伝染病報告・管理システムをリリースを発表しました。
伝染病報告・管理システムはユタ州でパイロット利用されており、今年の後半には50州すべてでオープンソースライセンスで利用できるようになります。本ソフトウェアは地域の保健当局が伝染性の病気の発生を個別・地域ごとに早期に発見して調査するためのものです。本ソフトウェアは州および連邦による伝染病流行の制御、病状の調査、伝染病研究の需要に応えるものです。
プレスリリースの後半に、もうひとつ大事なことが書いてある: このプロジェクトではJRubyを利用しています。われわれはCollaborative Software Initiative(サイト・英語)のプロジェクトマネージャであるMike Herrickにインタビューし、プロジェクトでJRubyを利用した経験について質問した。
InfoQ: どのようなソフトウェアを実装したのか、どこでJRubyを利用したのか、まず簡単に教えてください。Webサイトだけでしょうか、それともビジネスロジックについてもJRubyを利用したのでしょうか？
私たちは、イテレーティブなやり方(リーンソフトウェア開発をベースとしています)で6ヶ月開発を続けてきました。アプリケーションの初期バージョンを完成させるまでに、2年かかるプロジェクトです。現在のところ、100%JRubyです。今のところはすべてWebアプリケーションですが、今後のロードマップは非常に幅広いものです。分析機能、スタンドアロンのクライアント、大規模なインテグレーションなどです。分析機能、スタンドアロンクライアント、インテグレーションについては、どのテクノロジを利用するかまだ決めていません。できる限りJRubyとJavaを使いたいと思っています。
InfoQ: JRubyとRailsで、どんなテクノロジーを利用しましたか？サーブレットエンジンは何ですか？Warblerなどのツールは利用していますか？
現在Java 6、JRuby1.1.1と、以下のgemを使っています。
* Rails 2.0.2
* hpricot
* mechanize
* postgres-pr
また以下のRailsプラグインを使っています。
* auto_complete
* validates_date_time
* model_auto_completer
* haml
* calendar_date_select
* betternestedset
* RAA soundex (正確にはライブラリ: http://raa.ruby-lang.org/project/soundex/)私たちはacts_as_auditableというプラグインを独自開発しました。プロジェクト全体をオープンソースにする前に、うまく取り出せれば、その部分だけオープンソースで公開するかもしれません。テスティングにはRSpecとSelenium Grid(こちらもRSpecを使っています)を利用し、継続的結合にはHudsonを使っています。開発にはNetBeansとvimを使っています。
データベースにはPostgreSQLを使っています。全文検索のためにSolrを調査しましたが、最終的にはPostgreSQL Full Text Searchを採用しました。PostgreSQL Full Text Searchは要求を満たしているし、新たなミドルウェアを導入したくなかったのです。
サーブレットエンジンはTomcatを現在利用しています。問題なく動作していますよ。GlassFishが評判がいいので、いつか試してみたいと考えています。Warblerは素晴らしいですね。Nick Sieger(訳注:Warblerの開発者)のおかげで本当に助かりました(もともとのGoldspikeベースのパッケージングは廃止されました)。私たちはJRubyコミュニティに小さなコントリビューションもしました。WarblerがJRuby Wikiでリリースされたとき、Rails2で使う方法をドキュメント化したのです(source)。私はブログでそのドキュメントについて書いたんですが(source)、いまでも毎日数十のヒットが、多くの大企業からありますよ。JRubyがポピュラーになる役に立っていると思います。
InfoQ: 上記のリンクに書いてあることからすると、プロジェクトチームは大規模のようですね。JRubyのコードを書いている人は何人くらいですか？
Collaborative Software Initiative (CSI)はコミュニティの力を活用して、プロジェクトチームを作り、コラボレーティブなソフトウェアを開発するプロジェクトマネジメントの中心的役割を果たしています。開発、テスト、コードのサポートも含めてです。CSIはソフトウェアを幅広い顧客に提供するため、オープンソースライセンスとSaaS(Software as a Service)モデルを用意しています。私たちの保健関係コミュニティには100人以上の参加者がいます。コミュニティのメンバーはSME(Subject Matter Experts; 分野の専門家)と開発者です。ここで言うSMEとは伝染病学者、看護士、医師です。15人のSMEと開発者からなるコアチームがいます。コアチームのうち5人は開発者です。またパートタイムで参加する2人の開発者もいます。7人の開発者のうち、4.5人がJRubyを日常的に書いています。上級開発者はEd CoponyとPete Laceyです。宣伝: コアの開発者をもう1人探しています。
InfoQ: JRuby on Railsを使う上で、どんな問題に遭遇しましたか？またその問題にはどうやって対応しましたか？(ツールを使った、回避した、JRubyチームにバグレポートを送った、など…)
先に結論を言うと、商業的なソフトウェアを開発するのは、私たちのような理想的な状況であっても非常に厳しい仕事です。開発者チームには、実績のある人に参加してもらいました。なんにせよ、私たちはJRuby、Ruby、Railsについてあるていど知っていたものの、それほど深く知っていたわけではありません。Collaborative Software Initiativeのファイナンシャルサービスのプロジェクトでリーダーを勤めているRoss Coopermanが、MRI(訳注: Matz' Ruby Implementation)のRubyとRailsについては深い経験を持っています。私たちのプロジェクトの早期において、正しい方向に進めるよう、ずいぶんと助けてもらいました。学習曲線の問題は確かにありました。RubyとRailsは学習曲線を越えれば非常に生産性が高くなりますが、一日でそうなれるわけでもありません。厳しい時期もありましたが、現在ではそんな目にあうことはずいぶん少なくなりましたよ。
私たちはJRubyメーリングリスト、wiki、IRCを利用するようになりました。コミュニティはとても熱心にサポートしてくれます。Rails2.0が最初にリリースされたとき、Goldspike(JRuby Railsサーブレット)のバグを見つけました。 http://jira.codehaus.org/browse/JRUBY-1879 私たちはコミュニティと協力して、週末のうちにフィックスできたんです。3月にアプリケーションの最初のリリースを予定していたのですが、そのころJRuby1.1がリリース寸前で、そこに私たちがバグを見つけてしまったので、アプリケーションを予定通りJRuby1.1用にリリースできなくなってしまったのです。http://jira.codehaus.org/browse/JRUBY-2314 しかしJRubyコミュニティは迅速にバグに対応してくれたので、最終的にはアプリケーションをJRuby1.1対応でリリースできました。
InfoQ: RubyではなくJRubyを採用した理由は何ですか？
MRIではなくJRubyを選んだ理由はいくつかあります。・デプロイが容易・地球中のすべてのサーバでJavaが動く・会社の開発チームがJavaの経験と資産を持っている・ロードマップが幅広く、Rubyだけですべて対応できるかわからなかった。ダメだったときは、CではなくJavaを使いたい
InfoQ: JRuby、JRuby on Railsスタックについて、欲しい機能や改善すべき点はありますか？
まずなによりも、JRubyコミュニティの力に驚かされました。非常に野心的であり、かつ現実的なのです。コアチームは際立った開発者で構成されています。そして正しい物事にフォーカスしているように思います。Javaとの連携の向上、パフォーマンス改善(これは常に続いています)、JVMをやっている人々と連携して、すべての動的言語のためにJVMを改善しています。いずれも素晴らしいことです。
いまの質問をPeteとEdにも聞いてみました。2人の回答はRailsに関するもので、JRubyに限定したものではありません。まず、複数モデルのサポートの改善です。has_many throughとhas_one throughをネストさせられるといいですね。またバリデーションのサポートがより一貫性があるといいと思います。バリデーションのエラーがトップのモデルにまとめられるといいです。最後が柔軟なURLフォーマットです。URIテンプレートがあるといいかもしれません。
これまでの私たちの経験で言うかぎり、Railsはしっかりしています。先ほども言ったように、JRubyとRailsは極めて生産的な環境ですが、ここで開発しているのは大規模なアプリケーションです。どんなテクノロジーを使ったにしても、仕事は山積みです。間違いなく生産性は大幅に向上しています。Javaだけ、あるいはJavaとSpringを使うよりもはるかにいい結果が出ています。それでも、Railsも銀の弾丸ではありません。あらかじめそう断った上で…RubyコミュニティとRailsにはたくさんのイノベーティブなツールやアイデアがあります。学習曲線を進もうともがいている最中であっても、そうしたツールやアイデアのおかげで喜ばしい気分になることが何度もありました。
InfoQ: Ruby言語や標準ライブラリに、将来こんな機能ができたらいいなと思うものはありますか？
私たちの経験では、JRubyはちゃんと動きます。JRubyとMRIの互換性が問題になったことは、まだありません。もちろん、まだJavaに移植されていないgemもありますが、使う必要に迫られたことはありません。
InfoQ: 実装技術にJRubyを採用することについて、(マネージメントや顧客から)なんらかの問題を指摘されたことはありませんか？もしあったなら、その問題にどう対応しましたか？
外部から、パートナーからは、いかなる問題もありませんでした。パートナーにとっては、あくまでJavaに過ぎないのです。現在のデプロイパッケージは、データベーススクリプトと.warで構成されています。ロードマップを進んでいく過程で、他のミドルウェアが現れるでしょうが、それでも一般的なJEEアプリケーションと変わりはありません。
Collaborative Software Initiativeは徹底した実力主義の企業です。プロジェクト開始時に、どのテクノロジを使うか議論しました。Ruby(MRI)、Python、JavaとSpring、JRubyとRailsとJava、JRubyとMerbとJava、などが候補でした。ものを言ったのは、活気です。Ruby言語は非常に活気づいていたのです。Rubyのバーチャルマシンの実装は多様で、言語実装者どうし協調しています。私たちから見て、とてもいい状況です。すべての選択肢を検討し、コミュニティを評価し、健全な議論をしたうえで投票しました。私たちはJRubyが歩んできた軌跡に、非常に感銘を受けたのです。私たちから見て、すでにプロダクションで利用可能でした。最終的な決定として、今回のプロジェクトとチーム構成では、JRuby、Rails、Javaの組み合わせがもっとも快適だと判断したのです。他の選択肢に文句があるというわけではありません。ですがそのように決断して、結果に非常に満足しています。
あなた自身は、JRuby on Railsを本物のWebアプリケーションで使ったことはあるだろうか？
原文はこちらです: http://www.infoq.com/news/2008/05/csi-disease-management-jruby