InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

Buildr:RubyがJavaより速く構築するとき

作者 Sebastien Auvray , 翻訳者 編集部 投稿日 2007年9月4日

セクション
運用/インフラ,
プロセス/プラクティス,
デベロップメント
トピック
Java ,
Ruby ,
Japanese Build systems
タグ
Rake ,
Maven ,
Buildr

JavaビルドシステムMaven 1.0は3年前にリリースされ、広くオープンソースの世界や産業界に導入されてきた。それ以降、2.0が新しくリリースされたが、同じようには認められなかった。同じ頃、Rubyの評判はますます上がり、内部DSLの概念が、Rakeのようなツールとともに大変役に立つことがわかってきた。

「一方で、一般の言語の中で記述されたDSLが実に役に立っています。高級言語の簡単さを享受しながら、コンピュータの処理能力の限界まで拡張することができるのです。」

時とともに、BakeRantといった全く新しいビルドシステムがRubyで書かれるようになった。ほかには、Rakeを拡張したRavenなどがあるが、これは外部リポジトリala Mavenをサポートする。

新顔のBuildrは特にJava buildsを簡単にすることを目的としている。作者のAssaf Arkin氏はxml化や過剰設計されたソリューションより簡単であると主張している。―それは、Arkin氏のブログまたは集めるthumblr の引用からわかる。その簡単さがApache Odeといった彼のプロジェクトからMaven2を外そうとした理由である。

すぐにMaven不確定性原理と名づけました。しかし、正直に言えばビルドが動作するかどうか、不確実性や疑問がほとんどないことはわかっていました。その通りでした。結局、いつだったか、もうたくさんだと思ったのです。テストケースは中断しました…。どちらにしても、アジャイルかMavenか選ばねばならなかったのです。一つは廃れていくことになるでしょう。」

Assaf氏はAntに戻ることに疑いを持った。

「それからまったくMavenなしに生活する幸せな生活を想像し始めました。ジグザグに進んでAntにいたるのでしょうか?欠点はありますが、少なくともAnt buildsは動作します。確かに、Antはソフトウェア開発者の誰もが望む「宣言型」ではありません。しかし、下手な宣言型のコードは、命令型のどんなスパゲッティコードより性質が悪いのです。」

…そして結局Rakeに落ち着くのである。

「だからそうしたのです。Rakeを使って始めました。驚きに水を差すようですが、結局素晴らしい選択であったことがわかりました。Rakeは好調にスタートしましたが、期待していたものではありませんでした。われわれが取り組んでいる典型的なJavaアプリケーションにはいくつかのモジュールがありますが、そのすべてに同じ共通のライフサイクルタスク、-コンパイル、テスト、パッケージ、デプロイ-があります。これらをモジュールごとにすべて何回も繰り返して書くのでは、Antとたいして変わらないでしょう。もっといい方法があるはずです。」

この冒険談が結果的にBuildrの誕生を招き、それによって身近な目標も達成し、(XML Beansの処理など)、普通のRubyコードを基本タスクを完了するために信頼に足るものにしてくれた。さらに広く導入するのを最後に止めるのは性能かもしれないが,「猛烈な勢いの」BuildrはMavenと張り合えることがわかった。
「われわれは同じコードをビルドし、同じテストを実行し、同じXMLBeansをコンパイルし、同じHibernateスキーマを作成し、同じリモートおよびローカルなリポジトリを共有しています。これらはすべて、ブラックボックスと同じであると言えます。同じプロジェクトを入力すると、同じJAR、WAR,配布ファイルを生成するのです。」

同じものをビルドするのですが、異なる点は、52のXMLを多用するファイルから1つのスクリプトまで、スクリプトのサイズが91%まで小さくなっていたことです。しかし、それだけではなく、Buildrはビルド時間を何とか50%まで減らしたのです!部分的なビルドでもBuildrはMavenと同等かそれ以上で実行しました。

同じものをビルドするのだが、異なる点は、52のXMLを多用するファイルから1つのスクリプトまで、スクリプトのサイズが91%まで小さくなっていたことであった。しかし、それだけではなく、Buildrはビルド時間を何とか50%まで減らしたのだ!部分的なビルドでもBuildrはMavenと同等かそれ以上で実行した。

「もちろん、Ruby単体をピュアなJavaと比較して計っているわけではありません。1つの実装をもう一方と比較しており、その実装において両者は同じことを行っており、ブラックボックスと同じことです。これこそ現実のベンチマークです。」

Assaf氏は素晴らしい結論で締めくくっている。

「Rubyは遅いかもしれませんが、それでビルドしたものは恐ろしく速くなるかも可能性があります。」

MavenとBuildrの直接対決を見るのは面白いことだろう。


この文書は現在RDocとApache Rakefileに限定されていますが、完全な説明書が作成中である。

(原文は2007年5月7日にリリースされた記事です)

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。