Ruby on Railsの作者であるDavid Heinemeier HanssonがRailsConfで、TDDは死んだと宣言する基調講演を行いました。これはRailsコミュニティとより広いソフトウェア開発コミュニティの両方で、当然のことながら大きな論争を引き起こしました。また、David、Kent、そして私自身の間でいくつかの興味深い会話につながりました。これらの会話は他の人たちも見たいと思うほど面白いと判断したので、ソフトウェア開発におけるTDDの役割について議論する一連のビデオハングアウトを録画しました。

私と私の同僚であるBadriとの、ヘキサゴナルアーキテクチャとRailsアプリケーションにおけるその役割についての会話を記録した2本のビデオです。最初のビデオでは、ヘキサゴナルアーキテクチャの意味と、それが永続化フレームワークとしてActive RecordとData Mapperのどちらを選択するかにつながるかについて話しています。2番目のビデオでは、Railsがアプリケーションで果たすべきアーキテクチャ上の役割、つまりプラットフォームとして見るべきか、コンポーネントのスイートとして見るべきかという点について、より広い範囲で議論しています。

Rakeは、makeやantと同様の目的を持つビルド言語です。makeやantと同様にドメイン固有言語ですが、この2つとは異なり、Ruby言語でプログラムされた内部DSLです。この記事では、rakeを紹介し、このWebサイトを構築するためにrakeを使用した結果、得られた興味深い事項（依存関係モデル、合成タスク、カスタムビルドルーチン、ビルドスクリプトのデバッグなど）について説明します。

Ruby Roguesは、Rubyプログラミングコミュニティのトピックについて定期的に議論する人気のあるポッドキャストです。彼らは定期的なブッククラブを開催しており、最近ではP of EAAを特集本として選びました。そのため、彼らは私をゲストとして番組に招き、この本とそれに記載されているパターン、特にこれらのパターンとRailsフレームワークの興味深い関係について議論しました。

Ruby Roguesは、Rubyの世界でのプログラミングに関する人気のポッドキャストです。彼らは「リファクタリング」のRuby版を議論するために私を再び招待しました。私たちは、リファクタリングの定義、デバッガーをあまり使わない理由、書籍を現代化するために何ができるか、リファクタリングツールの役割、コメントは良いことに使えるか、リファクタリングと書き直しのトレードオフ、モジュール性とマイクロサービス、そしてソフトウェア業界が過去20年間でどのように変化したかについて話し合いました。

Thoughtworksは2006年に本番プロジェクトでRubyの使用を開始し、それから2008年末までに41件のRubyプロジェクトを実施しました。QConでの講演準備として、これらのプロジェクトを調査して、その経験からどのような教訓が得られるかを調べました。Rubyの生産性、速度、保守性に関する一般的な質問について、これまでの私たちの考えを説明します。これまでのところ、Rubyは多くの形式のアプリケーション、特にRuby on Railsを使用したWebアプリケーションで真剣に検討されるべき実行可能なプラットフォームであるというのが私たちの結論です。また、Active Recordを使用したテストに関する考察を含め、いくつかの技術的な教訓についても説明します。

2009年のQCon Londonでの講演のため、Thoughtworksでの2006年から2008年までのRubyの使用状況を調査しました。その期間に41件のプロジェクトを実施しました。私の講演では、Rubyの生産性、速度、保守性に関する私たちの見解を取り上げています。Rubyは開発環境として真剣に検討されるべきであると結論付けています。また、視聴するよりも読む方が好きな場合は、同じ内容を網羅した記事も用意しています。

私のほとんどの基調講演と同様に、これは即興講演です。会議の内容を踏まえ、今回の講演ではRailsがソフトウェア開発に与える影響をテーマにしています。

コレクションパイプラインは、一連の演算として計算を構成するプログラミングパターンです。演算は、ある演算の出力をコレクションとして受け取り、次の演算に供給することによって構成されます。（一般的な演算は、フィルター、マップ、リデュースなどです。）このパターンは関数型プログラミングで一般的であり、ラムダを持つオブジェクト指向言語でも一般的です。この記事では、このパターンに馴染みのない人にパターンを紹介するとともに、コアコンセプトを理解しやすくすることで、言語間でアイデアをより簡単に活用できるように、パイプラインを形成する方法のいくつかの例とともにこのパターンを説明します。

オブジェクトについて学ぶとき、通常、オブジェクトはインスタンスとクラスの2種類のデータをキャプチャできることを学びます。インスタンス変数は最も一般的なケースであり、データはオブジェクトのインスタンスごとに異なります。クラス変数（しばしば静的変数と呼ばれる）は、クラスのすべてのインスタンスで共有されます。すべてのインスタンスは同じ値を指しており、変更はすべてに反映されます。クラス変数は、インスタンス変数よりもはるかに一般的ではありません。特に可変クラス変数の場合はそうです。

もしかしたら私はナイーブだったかもしれませんが、「HumaneInterface」に関する私の投稿が、これほどまでに多くの議論を引き起こすとは予想していませんでした。残念ながら、ほとんどは私が主張したかった根本的な点ではなく、RubyのArrayとJavaのListの相対的なメリットについての議論に終始しましたが、それでも会話がいくつかの良い方向に展開したと思っています。

この会話のスレッドの1つで、ArrayとListの違いには、人間的/最小限の哲学以外の理由があることがわかりました。これらの理由の1つは、同様の機能が2つの言語で異なる役割を果たすことに関係しています。

最近、当社の開発者の一部が、rubyのような動的言語では非常に多くの動的型チェックを使用するため、事実上独自の型システムを記述することになるという非難に直面しました。そこで彼らは、多くの実際のrubyコードを記述してきたので、動的型チェックをどれくらいの頻度で行うのかを考えました。Michael Schubertがデータを収集しました。

私はプログラミング言語における静的型付けと動的型付けの間の論争について、いかなる貢献も書くことを長い間嫌がってきました。これは、人々が耳を傾けるよりも議論に駆り立てられているように見える、感情的なトピックの1つです。しかし、何度か聞かれたことがあるので、私自身の経験を共有します。私は誰にも何かを納得させようとはしていませんが、誰かがそれらの中に考える材料を見つけてくれることを願っています。

新たに形成されたRailsコミュニティでは、「エンタープライズ」という言葉は汚い言葉になりつつあります。多くの人にとって、その積極的なシンプルさを備えたRailsフレームワークは、複雑すぎる「エンタープライズ」フレームワークの正反対です。

これを読んでいるあなたは、Rubyプログラミング言語、特にWebアプリケーション開発のためのRailsフレームワークについて、非常に多くの騒ぎが起こっていることをご存知だと思います。一部はプログラミングの未来と見ていますが、危険な逸脱と見なす人もいます。

現在、Java仮想マシン上で実行されるスクリプト言語として、GroovyとJRubyの相対的なメリットを巡って激しい議論が交わされています。好奇心旺盛な人は、これらの言語のうち、今後の言語戦争でどちらが勝利するのかを知りたがっています。人々は、プロジェクトでどの言語を選択すべきか、どの言語を学ぶべきかを決めたがっています。

人にオブジェクト指向を教えたい場合、どの言語を使用すべきでしょうか？

以前ほど多くの会議には行かなくなりましたが、その利点は、自分の気に入った会議に行く時間があることです。私はRubyコミュニティに以前から特別な愛着を持っているので、今年のRailsConfに一般参加者として参加しました。

Rubyの最も人気のある機能の1つは、メタプログラミングのサポートです。これは、言語自体を変更するような機能であり、新しいキーワードのようなものを導入します。

RailsConf2007では、JRubyに対して大きな興奮がありました。この小さなチームは、死にかけていたプロジェクトを、JVM上でのRubyプラットフォームの一級実装のように見えるものに変貌させました。彼らは多くの喝采を受け、それは当然の報いでした。

JRubyがほぼ完成した今、注目はもう一つの一般的なマネージドコードランタイムである.NETに移ります。MicrosoftのRubyに対する意図は、今のところはっきりしていません。彼らはSilverlightのスクリプト言語としてRubyを発表しましたが、それでも多くの疑問が残ります。これはRuby言語の完全な実装なのでしょうか、それともRuby++のような、Rubyの拡張されたサブセットなのでしょうか？

私の記事を定期的に読んでいる方ならご存知でしょうが、私は数年来の熱心なRubyistです。私はRuby言語の、豊かでいて整理された構文と、それに付随するよく設計されたフレームワークが好きです。このウェブサイトのほとんどを含め、個人的なプロジェクトにおいて、Rubyは私の頼れる主力言語となっています。

最近のEvaluatingRubyに関する投稿で、同僚がいくつかの凝った数値グラフを含むWebアプリを構築したことに触れました。彼がどのようにそれを行ったのかを知りたいというメールが届きました。私は元のblikiエントリに短い回答（ploticus）を追加しましたが、それが、彼がrubyとploticusをどのようにインターフェースさせたのかという疑問につながりました。

数週間前、サンフランシスコでGoGaRuCo（ゴールデンゲートRubyカンファレンス）というRubyカンファレンスが開催されました。このカンファレンスは、講演者がCouchDBに関する議論を説明する際に、性的に暗示的な女性の画像を使用したことで注目を集めました。当然ながら、その結果、激しく、時には不快な議論が繰り広げられました。