多くの標準文書を読む場合、大量のコーヒーが必要になるだけでなく、一部の単語の多義性に注意する必要があります。

ロールインターフェースは、サプライヤとコンシューマ間の特定のインタラクションを調べることで定義されます。サプライヤコンポーネントは通常、これらのインタラクションのパターンごとに複数のロールインターフェースを実装します。これはヘッダーインターフェースとは対照的です。ヘッダーインターフェースでは、サプライヤは単一のインターフェースしか持ちません。

ヘッダーインターフェースは、クラスの暗黙的な公開インターフェースを模倣する明示的なインターフェースです。基本的に、クラスのすべての公開メソッドを取り、インターフェースに宣言します。その後、クラスの代替実装を提供できます。これはロールインターフェースとは逆です。詳細と長所と短所については、そちらで説明します。

JRubyがますます成熟するにつれて、多くの人が、antをrakeに置き換えることで、ビルドスクリプトの世界を改善しようと考えています。

ソフトウェア開発者の生産性を向上させるにはどうすればよいでしょうか？

ここ数年、Web 2.0については、その概念と新語としての価値の両方について多くの議論がありました。私はこの分野には限定的に関わっており、Tim O'Reilly氏の講演を聞き、彼が主催したワークショップに参加しました。しかし、多くの混乱があるため、その混乱を軽減するために無駄な試みをする時が来たと思います。(多くの部分をTim氏の解釈に基づいているため、意見が異なる場合は、彼を信じるべきです。)

私はソフトウェア開発で見られる事柄を説明するために新語を作る習慣があります。これはこの分野のライターの間では一般的な習慣であり、ソフトウェア開発はまだ多くの便利な専門用語を欠いているためです。専門用語を作る上での問題の1つは、用語が意味を失う危険性があり、意味の拡散というプロセスで、さらに専門用語に追加される可能性のある別の言葉を使うことです。

新語

1: 新しい単語、用法、または表現。
2: 精神病者によって造られた意味のない言葉。

-- Merriam-Webster

私の文章を多く読めば、私が強迫的な新語造りであることにすぐに気付くでしょう。私は常に新しい単語やフレーズを生み出そうとしており、実際、このblikiはこの習慣に基づいて設計されています。

アジャイル手法の一般的で、おそらく支配的な実践は、構築されているソフトウェアの機能（多くの場合、ストーリーと呼ばれる）のリストを作成することです。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールを使用して追跡されます。

普遍言語は、Eric Evansがドメイン駆動設計で使用している用語で、開発者とユーザー間の共通の厳格な言語を構築する実践を表します。この言語は、ソフトウェアで使用されるドメインモデルに基づいている必要があります。そのため、ソフトウェアは曖昧さをうまく処理できないため、厳格である必要があります。

ペアプログラミングに関する一般的な誤解のいくつか。

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

オブジェクトマザーは、テストで使用されるサンプルオブジェクトの作成に役立つ、テストで使用される一種のクラスです。

内部DSL（埋め込みDSLと呼ばれることが多い）は、既存のホスト言語内で記述されたドメイン固有言語です。これは、多くのプログラミング言語コミュニティ、特にLispコミュニティにおける一般的な考え方です。DSLは急速に成長しているRubyコミュニティにおける一般的な考え方であるため、現在注目を集めています。

あなたが自分の仕事に真剣であれば、それをより良くすることに真剣になるでしょう。これには、自分の仕事のやり方について熟考し、新しいテクニックを試して、それが自分の能力を向上させるかどうかを確認することが含まれます。他の人が新しいテクニックを推奨する場合でも、それらが自分にとって有効かどうかを知る唯一の方法は、自分で試してみて、パフォーマンスが向上するかどうかを確認することです。

オブジェクト指向のコミュニティで最も長く続いている議論の1つは、オープン継承と設計された継承の議論です。設計された継承の原則は、おそらくジョシュ・ブロックによって最もよく要約されています。「継承のために設計および文書化するか、そうでなければ禁止する」。このアプローチでは、継承できるメソッドを決定し、シールして他のメソッドが上書きされないようにします。

アジャイルアライアンスの現在の役員会によると、アジャイル手法は"キャズムを超えた"とのことです。これは、アジャイル手法がより広く普及しつつあることを意味すると私は考えています。これには利点がありますが、問題も引き起こします。方法論または設計アプローチが流行すると、実際の内容ではなく流行に焦点を当てている多くの人がそれを使用したり、教えたりするようになります。これにより、アジャイルの名の下に行われたことについての報告が、ムーブメントの創設者の原則と正反対になる可能性があります。

以前（このページの以前のバージョンで）述べたように、明確で監査可能なペーパー・トレイルのない投票マシンが、投票に適していると考えることは理解できません。この見解をさらに裏付けるものとして、一般的な投票マシンをどのように簡単に改ざんできるかを示すプリンストンの最近の研究があります。（グレン・ヴァンダーバーグ経由）

最近、AppleはTime Machineを発表しました。これは、時間を遡ってファイルのすべての変更を確認し、削除されたファイルを見つけることができる機能です。私たちのような熱心なギークにとって、これは新しい機能ではありません。他の人たちと同様に、私は自分の作業ディレクトリ全体をバージョン管理下に置いており、最初はCVS、現在はSubversionを使用しており、そのため、作業しているもののすべての変更を簡単に確認できます。これは非常に便利な機能であるため、以前からMoreVersionControlのようなものがあればどうなるか疑問に思っていましたが、Time Machineはその方向への一歩かもしれません。

これは設計された継承とは反対の考え方です。オープン継承の支持者は、クラスをシールしたり、他の方法でクラスの継承を阻止したりして継承を許可しないようにしません。

少し前に、Jon Udellは2つのパブリックスピーチのモードを特徴付けました。

• スクリプト型：言おうとしていることをほぼ正確に書き出し、それを読み上げるか暗記するかします。
• スライド駆動型：詳細なスライドを作成し、それらを使用して言いたいことを導きます。

最近の私のパブリックトークのほとんどは、3番目のモードである即興スピーチを使用しています。このスタイルでは、トークの粗いアウトライン以上のものをほとんど準備せず、残りの部分はすべてその場で構成します。

ドメイン特化言語（DomainSpecificLanguage）の話題になると、よくある疑問の1つは、それがDSLに該当するのか、しないのかということです。問題は、DSLの正確な定義がなく、DSLとそれ以外のものとの間に大きなグレーゾーンが存在することです。

私は多くの執筆エネルギーをパターン記述に費やしてきました。時々、なぜ私がそれを行うのか、そして良いパターンとは何かについて質問を受けます。これは、私がパターンをどのように見ているか、そしてパターンを書きたいと思っている人々への私の提案について簡単に説明した記事です。

一流のエンタープライズソフトウェア開発者を構成する要素について検討する際、会話はしばしばフレームワークや言語の知識、あるいは複雑なアルゴリズムやデータ構造を理解する能力に及ぶことがあります。しかし私にとって、プログラマー、あるいは開発チームにおける最も重要な特性の1つは、「顧客親和性」と呼ぶものです。これは、開発者がソフトウェアが取り組んでいるビジネス上の問題、そしてそのビジネスの世界に住む人々に対して持つ関心と親密さです。

過去4年間、Thoughtworksは北米およびヨーロッパのソフトウェア開発プロジェクトを支援するために、インドのバンガロールにラボを運営してきました。従来のオフショア開発アプローチは計画駆動型手法に基づいていますが、私たちはアジャイル陣営にしっかりと属しています。ここでは、オフショアアジャイル開発における経験と得られた教訓について説明します。これまでのところ、うまく機能させることができることがわかりましたが、そのメリットはまだ議論の余地があります。（この記事は2006年に最終更新されましたが、2011年にオフショア作業を訪問したところ、教訓は依然として関連性があり、したがって記事をさらに大幅に改訂する必要はありませんでした。）

GUIアーキテクチャの進化の歴史的概要。特に、長年にわたってModel-View-Controllerがさまざまなグループによってどのように見られてきたかに注目しています。歴史的な観点から、私のプレゼンテーションパターンに関連付けられています。

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

ユーザーインターフェースのパターンに関するナラティブ概要。ドメインロジックとプレゼンテーションを分離する方法と理由、およびデータレイヤーの分離と同期について説明します。

2001年2月、17人のソフトウェア専門家がユタ州スノーバードに集まり、かつて軽量メソッドと呼ばれていた成長分野について議論しました。私たちは、この新しいタイプのアジャイルメソッドを説明するために「アジャイル」という用語を使用することに決めました。アジャイルソフトウェア開発マニフェストを作成し、これらのアジャイルプロセスの価値と原則を定めました。私はこれらの自称ビジョナリーの一人であり、それ以来、このグループの起源とアジャイルアライアンスの設立に関する多くの質問を受けてきました。これは、それらの出来事に関する私の記憶です。

私は何度も継続的インテグレーションの利点について話してきました。そのような環境を機能させるには、継続的インテグレーションサーバーとソースコード管理システムが必要です。プロジェクトを円滑に実行するためには、バグトラッキングなどのための問題トラッカーと、あらゆる種類のプロジェクト知識をキャプチャするためのwikiも役立ちます。

2001年にユタ州スノーバードで行われた会議で、「アジャイル」という用語を使用すること、そして「アジャイルソフトウェア開発マニフェスト」を開始することが決定されました。

私のほとんどの基調講演と同様に、これは即興講演です。会議を考慮すると、これはRailsがソフトウェア開発にどのように影響するかというテーマです。

最近のEvaluatingRubyに関する投稿で、同僚が派手な数値グラフを含むウェブアプリをまとめたことを述べました。ある人が、どのようにそれを行ったのかを尋ねるメールを送ってきました。元のblikiエントリに私の短い回答であるploticusを追加しましたが、それはRubyとploticusをどのようにインターフェースしたかという質問につながりました。

最近のブログ圏での論争は、Nicholas Carrのエントリが「Wikipediaの死」を主張したことで引き起こされました（はい、私の反応が遅いことはわかっていますが、旅の途中で書く時間はありませんでした）。彼の最初の投稿は、0.01％の記事がかなり穏やかな保護を受けているため、Wikipediaが死にかけていると言っているように私にはかなり奇妙に思えました。それは、町が警官を雇ったときに民主主義が終わったと言っているようなものです。

この記事では、サービスプロバイダーと消費者のコミュニティを進化させる上での課題について説明します。サービスプロバイダーが契約の一部、特にドキュメントスキーマを変更したときに発生するカップリングの問題について説明し、そのような問題を軽減するための2つのよく知られた戦略、つまりスキーマ拡張ポイントの追加と受信メッセージの「必要十分」な検証の実行について説明します。どちらの戦略も、プロバイダー契約の変更から消費者を守るのに役立ちますが、どちらの戦略も、プロバイダーがどのように使用されているか、そして進化する際に維持しなければならない義務について、プロバイダーに洞察を与えません。これらの軽減戦略の1つ、つまり「必要十分」な検証戦略の表明に基づく言語に基づいて、この記事では「消費者主導型契約」パターンについて説明します。これは、プロバイダーに消費者の義務に関する洞察を与え、消費者が要求する主要なビジネス機能の提供を中心としたサービスの進化に焦点を当てています。

今年の初めは多くの旅行をしましたので、私の執筆は完全に停止しました。数週間前に家に帰りましたが、多くの執筆を行うことを望んでいました。ええ、いくつかはしましたが、私を遠ざけるものが次々と現れました。事故からピンを除去するための手術、洪水。しかし、最大の生産性の低下は自己流でした—新しいコンピューターを購入することです。

過去数年間にわたって、私たちのお気に入りのガジェットの1つはSqueezeboxです。非常に単純なデバイスです。ルーターほどの大きさで、電源、イーサネット、アンプ、ワイヤレスLAN用のアンテナのポートがあります。その仕事は、サーバーからストリーミングされたmp3ファイルをアンプを通して再生することです。

最近のCodeOwnershipの投稿では、コード所有権の問題について私が考えている方法について説明しました。私のソフトウェア開発の友人たちの多くはエクストリームプログラマーであり、集団的なコード所有権を支持する傾向があります。しかし、これらのプラクティスは絶対的なものではなく、常にローカルな考慮事項によって調整する必要があります。私の同僚の一人が、私がXPの熱心なファンであっても、プラクティスを変える必要がある場合の良い例であると考えられた、次のストーリーを含むメモを送ってくれました。（彼は自分のチームについて話しているので、匿名を希望しています。）

ニュースに注目している方は、ニューイングランドが大きな春の嵐に見舞われ、大規模な洪水が発生したことに気づかれたかもしれません。私はメルローズに住んでいますが、雨の真っただ中にあり、週末に約10インチの雨が降りました。人々は、1938年のハリケーン以来このようなことはなかったと言っていますが、世界中の他の地域が過去数年間に経験したことに比べると、それは小さな出来事です。

これまで出会ってきたコード所有権の様々なスキームがあります。私はそれらを3つの大きなカテゴリーに分類します。

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

ここ1ヶ月ほど、英国のThoughtWorkersに追いつくために、英国オフィスに滞在していました。いくつかの顧客プロジェクトを訪問するつもりでしたが、オフィス内外の人々に追いつくだけでかなり忙しくなりました（書籍の執筆もすべてなくなりましたが、それは家に帰るまで待つことができます）。

ゲッターメソッドを見ると、口の左側がぴくっと動くのです。そして、戦斧を素早く振り回し、満足げな叫び声を上げます。もう一つのゲッターが容赦なくクラスから切り離され、そのクラスは感謝のあまり恍惚のあまり、男らしいゲッター撲滅者の足元に倒れ伏すのです。

セッターによる初期化では、空のオブジェクトを作成し、その後、セッターメソッドを使用して様々なプロパティを設定していきます。（コンストラクタによる初期化の代替手段です。）

コードの臭いとは、通常、システムのより深い問題に対応する表面的な兆候のことです。この用語は、私がリファクタリングの本を執筆する際に、Kent Beckが手伝ってくれた際に初めて使われたものです。

コンストラクタによる初期化とは、オブジェクトが必要とするすべての協調オブジェクトを、オブジェクトの作成メソッドで渡すアプローチです。セッターによる初期化の代替手段です。

作家としての成功の副作用の一つとして、私はちょっとしたオタク有名人になってしまいました。ごくわずかですが、たいていはオタク系のカンファレンスでのみ効果を発揮します（ただし、サンフランシスコのレストランで数回、知らない人に声をかけられたことはあります）。それが起こる前は、軽い名声への憧れを除いては、あまり気にしていませんでした。今では、そのことが意識されるようになり、全体として私はそれを嫌っています。

エンタープライズアプリケーションについて考える最も長く続いている方法の一つに、外部からのイベントに反応するシステムとして考えるというものがあります。これは、80年代後半に構造化設計コミュニティで確立された考え方です。「イベント駆動アーキテクチャ」という名称で現在も耳にするものです。2000年代半ば、私はこれらの種類のシステムのパターンをいくつか収集し始めましたが、それ以来、より実質的なものにすることができませんでした。荒削りな性質にもかかわらず、イベントコラボレーションの本質、 「イベントソーシング」という用語の導入、仮説的な世界の状態を表す並列モデルの使用、および合意ディスパッチャを使用してドメインロジックをどのように構成できるかについて、いくつかの有用なアイデアを提供していると私は考えています。

システムが動作し、ピアと連携する方法の中心にイベントを使用する方法を示すパターンナラティブ。イベントの表現方法、システム間を統合するためのイベントの使用、およびシステムのアーキテクチャにおけるイベントソーシングの使用をまとめたものです。

会計に役立つパターンのナラティブ。勘定、仕訳、取引の基本的な表現と、会計調整を行うためのパターンの概要をまとめています。

Gerard Meszarosは、様々なXUnitフレームワークの使用パターンをまとめた書籍を執筆中です。彼が遭遇した厄介な問題の一つに、スタブ、モック、フェイク、ダミー、およびシステムの一部をテストのためにスタブアウトするために人々が使用するその他のものの様々な名称があります。これに対処するために、彼は独自の語彙を作り上げ、それがさらに広まる価値があると私は考えています。

XUnitとは、ソフトウェア開発者の間で広く知られるようになった一連のテストフレームワークに付けられたファミリー名です。この名前は、最初に広く知られるようになったJUnitに由来しています。

設計による契約（DbC）とテスト駆動開発（TDD）の支持者の間では、長年にわたり、控えめながらも議論が続けられてきました。今はそれに深く踏み込みませんが、Daniel Jacksonと話をしていた際に出てきた、この2つを融合させるアイデアを紹介します。

メソッドがオブジェクトの観測可能な状態を変更しないと述べるとき、人々はどのような意味で言っているのでしょうか？

2つか3つの値が一緒になっている場合は、それらを$%#$%^オブジェクトに変えましょう。

――私（声があった方がもっと面白かったのですが）

これは、リファクタリングの本からの私のお気に入りのコードの臭いの一つです。同じいくつかのデータ項目が常に一緒に渡されている場合に見つけることができます。startとendは、範囲になりたがっているデータの塊の良い例です。多くの場合、データの塊はプリミティブな値であり、誰もオブジェクトに変えようとは思いません。

JavaとC#はどちらも、純粋なインターフェースタイプの同じモデルを共有しています。`interface Mailable`で純粋なインターフェースを宣言し、`class Customer implements Mailable`（Javaの場合）で実装を宣言できます。クラスは任意の数の純粋なインターフェースを実装できます。このモデルが無視していることの1つは、クラスがあるときは常に暗黙的なインターフェースがあるということです。