以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。

ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。

最終更新日：2009/6/11

私の雇用主であるThoughtWorksは、主にソフトウェア開発を生業としている。 我々はソフトウェアを誰かのために構築する。自らのために構築することもある。 特定の開発プラットフォームに依存しないことが我々の大切な信条であり、 我々はクライアントに最も適したプラットフォームを選択することができる。 2000年に私がThoughtWorksに参加した頃は、Javaが圧倒的に有力なプラットフォームであった。 間もなく、.NETも使い始めたが、最初の5年間はこれら2つのプラットフォームが我々の仕事のほぼすべてを占めていた。

しかし、LAMPスクリプティング言語（とりわけRuby）を使い始める者たちがいた。 WebアプリケーションフレームワークであるRuby on Railsの登場は、Rubyを一躍スターダムにのし上げた。2006年の時点でそれは十分に有名で、我々はRubyプラットフォームで本格的なプロジェクトを始めた。本稿は2009年のものであるが、Rubyプラットフォームは我々の仕事で一定のシェアを占めている。JavaやC#ほどではないが、かなりのシェアがある。

ここ3年間で我々は、Rubyについて実践を通じて多くのことを学んだ。 2009年の初頭に、こうしたRubyの経験についてQConで講演しないかと持ちかけられた。 私は、我々のRubyプロジェクトについて大規模な調査を実施し、Rubyを使っているリーダーたちの考えや経験についてヒアリングを行った。 本稿を書き上げるのには思った以上に時間がかかったが、ここに書き上げることができた。

本稿は3つのパートに分かれている。 まずは、ここ数年間で我々がどのようなプロジェクトに取り組んできたかを皆さんに知ってもらうために、プロジェクトの概要について説明する。 次に、Rubyに関するよくある質問と、それらに対する我々の答えについて見ていく。 最後に、実践で学んだRubyの教訓について触れる。

プロジェクトの形態

2006年から2008年の間に、ThoughtWorksは41個のRubyプロジェクトに携わった。 ここで言う”Rubyプロジェクト”とは、Rubyが主要言語であったプロジェクトを指す。 他のプロジェクトでもRubyが使われることはある。 最近の開発では、Javaのプロジェクトでも自動ビルドや機能テスティングにRubyを使うことが多い。 Rubyプロジェクトの多くは、Railsも使っている。 Webサイトの開発プロジェクトが多く、RailsはRubyと同様に重要な存在である。

図1: 2006年から2008年におけるThoughtWorksでのRubyプロジェクトに関わった人数（ピーク時）と期間の散布図

図1を見ると、我々の関わったプロジェクトの規模が掴めると思う。ここの人数(headcount)とは、関係者（ThoughtWorks、クライアント、その他関係者。開発者、プロジェクトマネージャ、アナリストなど）を含めたピーク時の人数である。期間は、プロジェクトに関わった期間である。

Rubyプロジェクトはほとんどの場合、他のプロジェクトよりも短く、小規模のようだ。 残念ながら他のプラットフォームとの比較データがないため、これが正しいかどうかは伝わりにくい。 しかし、ほとんどのプロジェクトは20人以下で、1年未満のものであることは確かだ。

いくつか突出したプロジェクトがある。 最も大規模なプロジェクトをAtlantaプロジェクトと呼ぼう。 ピーク時の人数は40人を超えている。 もう1つの大規模プロジェクトは、Jerseyプロジェクトだ。 これら2つのプロジェクトは、お互いに大幅な人員のローテーションを行っている。 そのため、弊社の熟練Rubistの多くは、どちらのプロジェクトにも携わったことがある。

3つ目のプロジェクトは、以前ここでも触れたことのあるMingleプロジェクトだ。 これは特に興味深いケースで、”ThoughtWorksスタジオ”から製品化されているものだ。 自社製品なので、クライアント向けのプロジェクトよりも公開できることが多い。

'’図2: 各年ごとのプロジェクトの工数を表したストリップチャート’’

図2は、また別の視点から様子をとらえている。 これは各年ごとに関わったプロジェクトの工数である。 ストリップチャートの各点が、その年の1つのプロジェクトの合計工数（全員の工数）を示している。 このチャートからは、ここ3年間で我々のRubyプロジェクトがどれだけ増えたかが分かる。

'’図3: 国別のプロジェクトの工数を表したストリップチャート’’

図3は国別のプロジェクトを表している。 いくつかのマルチサイトプロジェクトや途中で移動したプロジェクトについてはきちんと扱っていないため（たとえばMingleプロジェクトは様々な場所で開発されているので中国に分類してある）、いくぶん粗く即席なものになっている。

国別チャートによると、アメリカが最もRubyの仕事に関心を持っているようだ。 インドにもかなりの数がある——我々の最初のRubyプロジェクトはバンガロールからだった。 イギリスではあまり盛り上がっていないようだ。 これはおそらく、アメリカには早期のRuby提唱者がいた一方で、イギリスにはRubyに懐疑的な人が多くいたということだろう。 インドがこんなにも関わってくれているのは心強い。 昔からインドは新しいテクノロジーを使い始めるのが遅いと思われていたが、 我々はインドオフィスをそれとは異なるものにするという正当な仕事をしたのではないだろうか。

Rubyの仕事を生業にするという経験から分かったことは、Rubyのような動的言語を使うことは我々全体の魅力にうまく馴染むということである。 我々の強みは、典型的なIT企業では引き込めないような非常に有能な人たちを雇用しているという点だ。 Rubyには、あまり有能ではない開発者をエラーから守るよりも、 有能な開発者がさらにうまく物事を成し遂げられる環境のほうがよいという哲学がある。 Rubyのような環境を使うことで、我々の開発者たちは真の価値を生み出す能力を与えられているのである。

Rubyはまた、アジャイルソフトウェア開発プロセスの使用を好むという我々の嗜好にも合っている。 アジャイルの哲学には、ソフトウェアを構築し、定期的に顧客と一緒にレビューすることで素早いフィードバックを得るというものがある。 開発環境の生産性が高まれば、頻繁にプロセスをレビューすることができるし、アジャイルの「検査と適応」プロセスがもっとうまく働くようになる。

Rubyに関する質問

Rubyで本当にいいのか？

41個のプロジェクトをふりかえるときに最も大切な質問は、Rubyプラットフォームが正しい選択だったかということだろう。 この質問に答えるには、プロジェクトのリーダーに正しい選択だったかどうかを（プロジェクトが終わってから）聞いてみるという手が考えられる。

'’図4: プロジェクトのプラットフォームにRubyを選んだのは正しかったか？’’

図4では、正しい選択をしたと考える人が36人。正しくないと考える人が5人いたことを表している。 我々の技術リーダは技術的選択に満足がいかなかなくても、それを示すことにためらうことはない。 つまりこの結果は、Rubyプラットフォームが合理的な選択だったという確かな声明と考えられるだろう。

5個の残念なプロジェクトについてもう少し詳しく見ていこう。 まず最初に分かったのは、5件中4件でそうだったのだが、リーダーはRubyを使ったこと自体は悪くなかったと感じていることだ。 Rubyに独特さがあっても、代替案を使うよりはメリットがあると我々は感じている。 もっと広く使われているものと違いがないのであれば、Rubyの独特な技術を導入する価値はない。 また、5件中4件は、Rubyに適していない他の技術との統合が問題の原因だったと報告した。 たとえば、.NETツールなら.NET技術とうまく統合できる。 他にも、5件中2件から政治的な問題が報告された——クライアントがRubyのような動的言語に反対したのである。 1つの残念なプロジェクトからは、こうした政治的問題が報告された。 IT部門がRubyの奇妙な”歯”や”爪”に耐えられなかったそうだ。 （このときのビジネススポンサーはRubyのファンだった）

ソフトウェアプロジェクトでRubyを使うことの危険信号についてさらに質問してみたが、唯一の明確な答えは、政治的な問題に関することだった。 Rubyはソフトウェア開発作業に受け入れられ、推奨もされていたが、その使用が避けられる最大の原因は、クライアントからの政治的な抵抗にあった。

Rubyの生産性は高いのか？

Rubyをプロジェクトに使うのは生産性が高いから、というのがよくある答えだ。 最初に指標としたのは、Rubyの生産性は1桁違うと言っていたプロジェクトの評価だった。

プロジェクトの技術リーダーに聞けばよいと思われたので、生産性について尋ねてみた ——Rubyは生産性を高めたのか。もしそうなら、どれくらい高めたのか。 さらに、最も生産性の高い方法で行われたときの主流（Java/.NET）プロジェクトとも比較してもらった。

'’図5: Rubyによってプロジェクトの生産性はどれくらい高まったか？（生産性が最も高いと思う主流ツールと比べた場合）’’

この結果は、ある程度、割り引いて見てもらいたい。 ソフトウエアの生産性を客観的に計測する方法はないのだ。 これらは、各プロジェクトのリーダによる主観的で、定性的な評価に過ぎない （すべてのプロジェクトから返答を得ているわけではない）。 しかしながら、実際に生産性が向上しているような印象を受ける。

これは人員の配置を見るとより確かだと分かる。 Scott ConleyはAllantaオフィスのマネージャだが、 彼は、Rubyプロジェクトが始まると、要求獲得にフォーカスした人材が他のプロジェクトのときよりも1.5倍必要になると報告している。

ただし、これらの生産性の向上がすぐに表れると思ってはいけない。 新しく作られたRubyチームの最初の進捗がものすごく遅くてびっくりされた、という話を何度か耳にしたことがある——これは私の言う「ImprovementRavine」の結果だ。 Rubyプラットフォームの動作のコツをつかむまでには時間がかかり、 その間は期待よりも進捗が遅くなってしまうのだ。

改善の谷は一般的な現象で、通常はチームに経験者を入れるようにする。 ここで言う経験は、Rubyの経験というよりも、Rubyで使うメタプログラミングなどをサポートする動的言語の経験である。 Scott Conleyが「効率性のリスクと納品のリスクの違い」と表現している。 動的言語の経験はあるがRubyの経験はあまりないチームだと、最初のうちは進捗が遅い（効率性のリスク）。 しかし、動的言語の経験がまったくないチームだと、 難のあるコードを生み出しかねず、それが全体的な納品のリスクにつながる。

Rubyは遅いのか？

一言で言えば「yes」。 ネットでベンチマークを検索したが、 他のスクリプト言語の基準と比べてみてもRubyはノロマな亀であると 多くの調査が示している。

ただ、我々にはあまり関係のないことである。 Rubyを使っているのは、Webサイトの裏にあるデータベース構築の部分がほとんどだ。 私はこの10年間で、今回の調査のように多くのプロジェクトを訪れたが、 Rubyを使ったプロジェクトもそうでないプロジェクトも、 ほとんどすべてのプロジェクトで パフォーマンス問題に多くの時間を使っていた。 そしてほとんどの場合、こうしたパフォーマンス問題はデータベースアクセスに原因があった。 つまり、処理コードのチューニングではなく、SQLのチューニングに時間を費やしていたわけである。 ほとんどのアプリケーションはI/Oバウンドであり、処理に速度の遅い言語を使っていても、システムの全体パフォーマンスに甚大な影響を与えることはない。

先の段落で、評論家みたいな逃げ口上を使ったことに気づいたかもしれない。 ほとんどのプロジェクトはI/Oバウンドだが、たまに例外に遭遇することがある——興味深いのはMingleである。Mingleは様々な点で普通じゃない。 たとえば、本当に動的な表示をする。つまり、パフォーマンス向上のためにページキャッシュを使うことができなかった。これだけで普通のWebアプリケーションでなくなった。 結果として、I/Oバウンドではなくなり、 パフォーマンス向上のために通常よりも多いハードウェアを必要とした （20〜40人のチームをサポートするのに4コア、2GBメモリ）。

それでもMingleチームはRubyが正しい選択だと思っている。 Mingleチームは多くの機能を素早く構築したが、Rubyから受けた生産性のブースト効果は最終成果物で必要となる高価なハードウェア要求に値するものだと感じている。 これはいわゆるハードウェアと生産性とのトレードオフである——コンピュータの世界における最も古いトレードオフの1つだ。 チームはどちらが大事なのかを考える必要がある。 ちなみに、Mingleは水平スケーラビリティ（プロセッサを投入してそれに比例するパフォーマンスを得る）を得ることができた。ハードウェアスケーラビリティは、ハードウェアのコストが下落しているような状況では、最も有用な代物である。

改めて強調しておこう。 ほとんどすべてのプロジェクトはI/Oバウンドだから、Rubyのスピードはさほど重要ではない。 ただしMingleは例外で、一般的なケースではない。

Rubyのコードは理解しにくいのか？

我々がRubyについてよく耳にするのは、動的型付、メタプログラミングのサポート、追いにくいコードを任せられるツールの欠如である。 実際にこれらが我々にとって問題となったことはない。 聞いた話によると、主流の言語と比べ、同じ機能を書くときのコードの量が少なく、より簡単にコードをクリーンに保てるようだ。

とは言うものの、我々の状況を忘れないで欲しい。 ThoughtWorksの開発者たちは、能力という点では平均よりも高く、エクストリームプログラミングのような規律ある手法に熱心な者ばかりである。我々はテスティングに非常に重きを置いており（Rubyコミュニティでも大切だとされている）、テストによってコードをよりクリアに保つことができている。 つまり、我々の経験が、能力や規律の少ない開発者でもうまくいくのかどうかは分からない。 （ 他の言語では、ツールなどで制御していても恐ろしいコードを見なくなることがないのだから、貧弱なRubyコードがそんなに悪いものなのかということには疑問が残る ）

メタプログラミングに対する考え方の一連の流れがこれだ。

'’図6: メタプログラミングに対する感情の経過’’

  • 恐いしダメ: メタプログラミングに対して慎重で、あまり使わない人たち
  • 恐いけどイイ:メタプログラミングの良さは分かってきたものの、まだ慣れないと思ってる人たち
  • 簡単だしイイ:メタプログラミングに慣れてきたので多用したばかりにコードがぐちゃぐちゃになる人たち
  • 簡単だけどダメ:メタプログラミングに対して慎重だが、部分的に使えばかなり有用だと分かってる人たち

最後にこうした技術に相応しい比喩の話をしておこう。 これらは処方薬のようなものなのだ。 少量なら非常に効果があるが、過剰摂取しないように気をつけなければならない。

多くのことと同様に、経験はここでも大いに役に立つ。経験があればこの谷をもっと早く脱出できるのだ。この受容曲線をあらかじめ知っておくことは重要で、特に使いすぎの部分には気をつけよう。 何か新しいことを学ぶときは、どこかの段階で使いすぎてしまうことがよくある。使いすぎのラインを越えない限りは、そのラインがどこにあるか分からないからである。 そのためにはサンドボックスで何かを試しに作ってみるのがいいかもしれない——サンドボックスは、メタプログラミングなどをやり過ぎても大丈夫なように閉ざされたコードベースになっている。 適切なサンドボックスがあれば、やり過ぎてもあとから簡単に戻すことができる。

Rubyは使えるプラットフォームなのか？

これまで見てきた質問は鍵となる質問に集約される。 「Ruby（とRails）は我々やクライアントにとって、使えるプラットフォームなのか？」 現時点での答えは「yes」だ。 生産性が明らかに高まり、我々の反応がよくなり、より良いソフトウェアが作れ、クライアントに素早くお届けすることができる。 ただし、すべての状況において正しい選択であるとは言えない。 開発プラットフォームを選ぶのは決して簡単なことではない。 通常は、技術的な選択よりも、政治的な選択であることが多い。 それでも、冒頭の結論の意味するところは、Rubyは考慮に値する選択肢であり、我々の道具箱に入れておきたいほど価値のある存在だということである。

それでは、あまり一般的でない他の言語についてはどうだろうか。 我々は、Groovy、F#、Python、Smalltalkなどを使うべきだろうか？ これまでRubyについて見てきたトレードオフが、その他の言語についても同じ結果になったとしても、私はさほど驚かない。 いずれこれらも我々の道具箱に入って欲しいと願っている。

これらの言語とJavaやC#などの主流の言語は、排他的な選択肢ではないということも強調しておこう。 Java/C#を使っている開発チームでも、サポート的なタスクにスクリプト言語を使うべきだとこれまで私は主張してきた。Rubyは最適な選択肢である。 そして、この組み合わせを使うプロジェクトで増えてきているのを目の当たりにしている。 JVMやCLR上でこうした言語がサポートされ始めているので、異なる強みを持つ異なる言語を混ぜる機会が増えている。 Neal Fordはこのやり方をPolyglot Programmingと呼んでいる。

開発のヒント

最終節では、我々がRubyを使う上で学んだ教訓の詰め合わせをお届けしよう。

Active Recordのテスティング

Rubyの使い始めたとき、Railsのデータベース層であるActive Recordをどうやってテストするのが最善の方法なのかという議論が起こった。 問題は、エンタープライズアプリケーションのパフォーマンスがデータベースアクセスに占められていることにある。 TestDoubleを使えば、テストをスピードアップできると分かった。 テストが速いことは、テスト中心の開発プロセスにとっては重要なことだ。 Kent Beckは、基本的なコミットビルドは10分以内に収めるべきと言っている。 最近では、ほとんどのプロジェクトがこれを達成しようとしている。 そして、データベースダブルを使うことが、この達成のために重要なことのだ。

Active Recordの問題は、データベースアクセスコードをビジネスロジックと一緒にしてしまっていることだ。これでは、データベースダブルを作ることが難しい。 Mingleチームでは、Railsがデータベースと密接に結びついていることを受け入れ、 本物のデータベースに対してすべてのコミットテストを実行している。

まったく逆の視点が、AtlantaチームとJerseyチームから提唱された。 Rubyにはメソッドを実行時に再定義できる強力な機能がある。 これを使って、Active Recordのクラスにあるデータベースアクセスメソッドを再定義して、Active Recordクラスをスタブ化するのである。 チームはこのために gem の unitrecord を使い始めていた。

3年経つが、我々はまだこの議論に決着がついていない。 Mingleチームは、本物のpostgresデータベースに接続して、8分以内に数千ものテストを実行している（マルチコアを活用してテストを並列処理している）。 AtlantaチームとJerseyチームは、コミットテストがスタブなしで8分以内に終わるよりも、スタブありで2分以内に終わることのほうが大切だと考えている。 このトレードオフは、データベースを直接テストするシンプルさと、スタブテストの素早いコミットビルドとの対決だと言える。

どちらのチームもそれぞれの立場に満足しているが、 Atlanta/Jerseyチームでは、スタブを使ったことでまた別の問題が起きている。 メソッドスタブを使うことに慣れると、もっと使うようになってしまった——ユニットテストで使うメソッド以外はすべてスタブアウトするなど、使いすぎが止まらない。 ここでの問題は、ダブルを使うとよくこうなるのだが、テストが脆くなることだ。 アプリケーションの振る舞いを変えると、古い振る舞いを模倣するダブルも大量に変えなくてはならない。 使いすぎがひどくなると、スタブ化されたユニットテストをやめて、railsスタイルのデータベースに直接アクセスする機能テストに移行せざるを得なくなるだろう。

Active Recordの漏れ

みんなからはSQLをいじる時間について多くの報告を受けた。 Active Recordはデータベースアクセスをプログラマからうまく隠してくれている。 しかし、すべてを隠してくれているわけではない——抽象化が漏れている。 結果として、SQLを直接いじらなくてはならない時間が多くなっている。

この漏れは、オブジェクトリレーショナルマッピングフレームワークの特徴だ。 私は、プロジェクトのみんなと話すときはいつも、O/RマッピングフレームワークはSQLを80〜90%を隠してくれるが、きちんとしたパフォーマンスを得るにはSQLをいじらなければいけないと言っている。 Active Recordも、この点については、他のO/Rマッパーと何ら変わりがない。

Active Recordの抽象化の漏れはキレイだという人もいる。 DHHと話したとき、彼は「リレーショナルデータベースを使う開発者はSQLの扱い方を知らなければならないと思う」と常に強調していた。 Active Recordはよくあるケースをシンプルにしてくれる。 しかし、複雑なシナリオになると、SQLを直接書かなければならない。

O/Rの抽象化の漏れが激しく非難されているのを見たことはない。 これらのフレームワークのポイントは、よくあることを簡単にできるようにすることで、生産性を上げるということだ。そして、本当に重要なごくわずかなケースにチームが注力できるようにしてくれる。 問題が起こるのは、チームが抽象化は防水加工されていて漏れることはなく、SQLを触る必要がまったくないと信じているときだ。 こうした欠点はあるものの、正しく使えているのであれば、O/Rフレームワークのメリットを捨てる理由はない。

長時間のリクエスト

我々がよく目にする問題は、アプリケーションが実行に時間のかかるタスクを引き受けたときに、固まってしまうというものだ。単純に対応しようとすると、リクエストハンドラがリクエストを処理するのに途方もない時間がかかり、日が暮れてしまう。

ヒューマンインタフェースのあるときにはよく起こる問題で、一般的なソリューションがある——バックグラウンドプロセスやスレッドにタスクを渡すのだ。 リッチクライアントのGUIアプリケーションのプログラミングをした者であれば、やったことがあるだろう。 しかし、この受け渡しがうまくいかないと、自分で自分の首を絞めることになる。

私が好きな方法は、幸いなことにThoughtWorkersの多くが同意してくれているのだが、アクターを使うことだ。このモデルでは、リクエストハンドラは長時間のタスクを受け取り、コマンドにラップして、キューに入れる。 バックグラウンドのアクターは、キューを監視して、キューのコマンドを受け取り、それを実行し、１つの処理が終わったらヒューマンインタラクションアクターに知らせる。 キューは最初はデータベースのテーブルであることが多い。 必要であれば、そこからメッセージキューシステムへと移行する。

Active Recordの漏れと同様に、これはRailsアプリケーションだけの問題ではなく、あらゆる種類のアプリケーションで遭遇することがある。 Railsを使う多くの人たちは、こうしたことが起きるのをすぐに忘れてしまうし、上記のようなソリューションを使う必要があるため、ここで私が指摘しておこうと思う。 Railsは、Webアプリケーションの何度も起こる部分の多くを、簡単に、素早くできるようにしてくれている。しかし、やるべきことはまだ残っているのだ。

デプロイ

Railsアプリケーションのビルドは簡単だ。しかし、残念なことにデプロイは非常に厄介だ。 よくMongrel Webサーバを複数使うことがあるが、このセットアップが非常に面倒くさい。 Rubyはその他の部分がスムーズなので、それに比べるとこの面倒くささは目立ってしまう。

現在は、Phusion Passengerを使うことでずいぶん楽になった。 これにはMRIを使ってデプロイする方法が推奨されている。

我々はJRubyを使ってデプロイするのも好きだ。 JRubyだとJavaのWebアプリのスタックが使えるため、多くの企業環境で扱うのが簡単になる。 Mingleでは、この方法で顧客がインストールしやすいようにしている。 Mingleチームは、MRIですべての開発を行っているが、デプロイにはJRubyを使っている。 MRIは立ち上がりが速く、開発が早くできるからだ（JRubyはJVMの起動が必要なので、明らかに遅い）。

Gemsの管理

Rubyには、パッケージ管理システムであるRuby Gemsがあり、サードパーティのライブラリのインストールやアップグレードが簡単に行えるようになっている。 Railsにはプラグインもあり、Railsの同じようなタスクを外出ししている。 これらはいいツールだが、チームで使っていると、ライブラリのバージョンや種類が揃わずにぐちゃぐちゃになることがある。

対応方法はいくつかある。 まずは、すべてのサードパーティライブラリのソースコードをコピーして、 ソースコントロールにチェックインしておくことだ。 この方法だと、チェックアウトすれば、 正しいバージョンのすべてのライブラリが手に入ることになる。 もう1つの方法は、すべてのライブラリの正しいバージョンをダウンロードしてアクティベートするスクリプトを使う方法である。 このスクリプトはソースコントロールに入れておかなければいけない。

同様に、ほとんどのチームはRailsのソース自体もコピーして持っている。 これだと、バグや致命的な問題があった場合に、Rails本体に直接パッチを書くことができる。 これらのパッチはRailsコアチームに送ることもある。 Gitなどの分散バージョン管理システムを使うと、もっと管理が楽になる。 昔みたいにJavaアプリケーションサーバをデコンパイルしてパッチを書いた思い出よりかは、遙かに簡単だ。

アップデートのタイミング

Rubyは、特にRailsはそうだが、動きが速い。 Railsシステムの更新は頻繁に行われ、使いたい機能が追加される。 我々はRailsの更新スケジュールを調整する必要がある。 そしてこれは、計画プロセスのなかに入れておかなくてはいけない。 これらは他のプラットフォームよりも重要なことだが、喜ばしいことに新しい機能が次々と追加されている。

Windowsでの開発

RubyはUNIXの世界で生まれた。 そして、このプラットフォームに集まる人たちは、ディレクトリパスにスラッシュを使う。 Windowsプラットフォームでも、Rubyの実行、デプロイ、開発は可能だが、いくぶん扱いにくいものとなっている。 我々のアドバイスとしては、開発はすべてUNIXプラットフォームで行ったほうがいい。 Macは一般的に好まれているが、多くの人は FOSS UNIX も使っている。

我々はこの状況がIron Rubyの開発によって一変されることを望んでいる。 RubyアプリケーションUnix、JVM、CLRなどにデプロイできるようになるのは好ましい。 実際、これでRubyが複数のプラットフォームで実行できる柔軟な選択肢になる。 我々の.NETプロジェクトでも、Rubyをメインの.NET言語と結合するスクリプト言語として使えるようになる。

■謝辞

いつにも増して、多くの同僚たちとのコラボレーションがなければ、すべてをまとめきることはできなかった。 私は何年も前から個人的にRubyを使っているが、1人で作っている個人サイトと、クライアントと一緒に作るアプリケーションとでは、違いが大きすぎる。 Rubyを評価するために必要だった情報を多くの同僚達が時間を費やして私に提供してくれたことに感謝している。

他のRubyユーザーと同様に、我々もRubyおよびRailsコミュニティに感謝している。 オープンソース活動では、コミュニティの役割は非常に大きい。 すべてのRubyハッカー、Rubyistたちに、ThoughtWorksから「ありがとうございました」。

■更新履歴

2009/6/11: martinfowler.com に公開

2009/6/3: 社内レビュー用の草稿

■日本語訳用: さらに詳しく知るために

■日本語訳について

  • 訳：kdmsnr
  • 2009/6/14 初出

2012-04-26 (木) 03:51:12 age : ぐっじょぶd(´∀｀)グッ♂ http://ylm.me *2009-12-04 (金) 05:33:44 kenboo : ダブル(TestDouble)は一般的名用語ではまだないので、説明が必要でしょう。英語版のリンク先を読んでやっとわかりました。