これは私が何度か遭遇したアプリケーションのスタイルです。このアプリケーションは主に、ユーザーに何かの状態に関するリアルタイム情報を提供するレポートアプリケーションです。ユーザーは見ているものについて多くの制御権を持っており、特定の領域を詳細に調べたり、一般的に表示を操作することができるため、アクティブなアプリケーションです。しかし、少なくとも主に読み取り専用のアプリケーションです。

RIAAは世界の終焉を告げているかもしれませんが、私のSlimp3によるデジタル音楽への取り組みにもかかわらず、私の音楽予算が減る様子は見られません。むしろ、iPodの空腹を満たすために、もっと多くの音楽が必要だと感じています。

ナイーブだったのかもしれませんが、私のHumaneInterfaceに関する投稿が、これほど多くの議論を巻き起こすとは予想していませんでした。残念ながら、そのほとんどは、私が伝えようとしていた本質的な点ではなく、Rubyの配列とJavaのリストの相対的なメリットに関する議論に終わってしまいましたが、それでもいくつかの良い会話の支流が現れたと思います。

これらの会話の流れの一つから、配列とリストの違いには、人間的/最小限の哲学以外の理由もあることが分かりました。これらの理由の一つは、同様の機能が2つの言語で異なる役割を果たす方法にあります。

ほとんどのオタクと同様に、私はファッションや今シーズンのスタイルにはあまり関心がありません。私の考え方は、内容に魅力がないのに、パッケージを気にしても意味がないということです。しかし、オタクの友人たちと服について何度か話をし、このエントリを書くきっかけとなりました。

数ヶ月前、エリック・エバンス氏と共にワークショップに参加し、私たちは「流暢なインターフェース」と名付けた特定のインターフェーススタイルについて話し合いました。一般的なスタイルではありませんが、より広く知られるべきだと考えています。おそらく、それを説明する最良の方法は例を示すことです。

彼の優れた著書ドメイン駆動設計において、エリック・エバンスは、遭遇する可能性のあるさまざまな種類のドメインオブジェクトの分類を作成しています。

90年代にエクストリームプログラミングで良い経験をした後、スクラム、クリスタル、DSDMなど、似たようなアプローチに興味を持つようになりました。それらを調べてみると、これらの新しい方法論の共通の特徴は、予測計画よりも適応計画を優先し、プロセスよりも人材を成功に重要視することであることが分かりました。時が経つにつれて、これらのアプローチはアジャイルソフトウェア開発というバナーの下に集まりました（そして私は記事を改訂しました）が、この観点はまだアジャイルの本質を理解するための良い方法だと思います。

すべてのクラスを取り、インターフェースとペアにするという実践です。その結果、ICustomerとCustomer、またはCustomerとCustomerImplなど、ペアのものが表示されます。多くの点で、これは各クラスのヘッダーファイルというC/C++の習慣を反映していますが、この場合はインターフェースと実装が実際には別々の型です。

私の執筆活動では、長い間、検証に関する資料の一塊を書こうと思っていました。それは多くの混乱につながる分野であり、うまく機能するいくつかの技術の堅実な説明を得ることができれば良いでしょう。しかし、人生には書きたいことがたくさんあり、時間より多くあります。

しばらくの間、Rubyのコミュニティにいたので、「人間的なインターフェース」という用語を何度も目にしました。これは、クラスインターフェースを作成する際のRubyistの姿勢の一部を表しており、APIを設計する際の2つの考え方（もう一つはMinimalInterface）の間の興味深い対比を提示していると思います。

「コマンドクエリ分離」という用語は、ベルトラン・メイヤーの著書「オブジェクト指向ソフトウェア構築」で造語されました。この本は、OOの初期において最も影響力のあるOO書籍の一つです。（影響力を持っていたのは初版で、第2版も良いのですが、持ち上げるには数ヶ月ジムに通う必要があります）。

最小限のインターフェースとは、ここでHumaneInterfaceと対比するAPI設計のスタイルです。最小限のインターフェースの背後にある考え方は、クライアントに必要なすべての作業を実行できるようにするAPIを設計することですが、その機能を仕事を行うのに最適な最小限のメソッドセットに絞り込むことです。（違いの良い例についてはHumaneInterfaceを参照してください）。

遅延初期化とは、変数（OOコンテキストでは通常はクラスのフィールド）を初めてアクセスしたときに初期化する手法です。その標準的な形式は次のようになります。

週末、ジョン・ブリシデス氏が長い癌との闘病の末に亡くなったという悲しいニュースを聞きました。ジョンは、「Gang of Four」の一人として最もよく知られており、おそらくソフトウェア設計に関する最高の著書を執筆しました。

インメモリデータベースは、ディスクにアクセスすることなく、メインメモリだけで完全に動作するデータベースです。多くの場合、組み込みデータベースとして動作します。プロセスが開始されるときに作成され、そのプロセスに組み込まれて実行され、プロセスが終了すると破棄されます。

時々、Smalltalkを試してみたいという人たちに出会います。私の古いお気に入りのSmalltalk入門書は絶版になりましたが、最近、ここからダウンロードできることを発見しました。他にも多くのSmalltalk関連の資料があります。この資料は、リエンジニアリングパターンに関する優れた著書の共著者であるステファン・デュカース氏がホストしています。

これは、私が最も好きなカンファレンスとなったものの、恥ずかしいほど短い報告です。残念ながら、他の業務との都合により、オーフスで1日しか過ごすことができませんでした。JAOOは、新鮮さと広さを保ちながら、小規模なカンファレンスの雰囲気を維持し続けている素晴らしいカンファレンスです。なぜそうなのかは説明するのが難しいです。

再びOOPSLA、たくさんのカンファレンスとあらゆる種類のアイデア。このカンファレンスについて適切なレポートを作成することは不可能です。あまりにも多くのものがあり、人間が参加するどころか、理解することもできません。したがって、これらは散らばった考えです。

ジェームズ・ノーブルとロバート・ビドルによって導入されたプログラミングの考え方です。少なくとも私にとって、その本質は、ソフトウェア開発は長い間、優れたソフトウェアシステムは均一なコンポーネントで構成され、均一で単純な方法で構成されているという近代的な視点を持っていました。（SmalltalkとLispはこのような考え方の良い例です）。ポストモダンな見解は、ソフトウェアはあらゆる種類の非常に異なるものがあらゆる種類の異なる方法で接着されたものであり（PerlとUnixを考えてみてください）、そしてこのスタイルのソフトウェア（大きな接着剤の塊）は悪いことではないということです。

5ポンドの袋に10ポンドのクソを入れることはできません。

-- 試したことがある人なら誰でも

ケントと私が「エクストリームプログラミング計画」を書いたとき、私たちは計画の本質を理解するのに役立つこの気まぐれな引用を含めました。

ソフトウェア開発分野の不満の一つは、さまざまな技術やツールの中から選択するのが難しいことです。誰かがこれについて話すとき、その技術やツールが他のものよりも優れているという「確かなデータ」を求められることがよくあります。それは理解できる要求ですが、最終的には無駄なものです。まず、私たちは生産性を測定できません。

Thoughtworksが中国に進出しました。中国オフィスを開設することは、何人かの人にとって長年の願望でした。ロイは常にそれをロイの社会実験の一部と考えてきました。さらに、ソフトウェア開発において私に多くの良い経験と思想を与えてくれた肖郭（シャオ・グオ）も、長年Thoughtworksを中国で始めることを望んでいました。

JAOO 2005において、私はドメイン特化言語に関するトラックの議長を務めました。InfoQによって収録され、彼らのウェブサイトで公開された30分の導入講演でトラックをスタートしました。この講演は、私の言語ワークベンチに関する論文の最初の部分と重なります。

私の常連読者であればご存知の通り、私は長年熱心なRubyistです。私はその豊かで洗練された構文と、優れた設計のフレームワークを備えたRuby言語を気に入っています。それは、このウェブサイトの大部分を含む個人的なプロジェクトのための私の通常の主力言語となっています。

エンタープライズアーキテクチャグループは、日常の開発から切り離されることがよくあります。これにより、開発作業に関する彼らの知識が時代遅れになり、開発チームが幅広い企業全体の視点を取らなくなる可能性があります。これが頻繁に起こるのを見てきた私の同僚（Thoughtworks CTO）であるレベッカは、エンタープライズアーキテクトは開発チームに参加することで、はるかに効果的になることができると主張しています。

Thoughtworksにおける大きなテーマの1つは、企業のあらゆる部門で多様な人材を育成することです。（この文脈では、性別、人種、性的指向などにおける多様性を意味します。）私たちは、女性や有色人種などの歴史的に不利な立場にある人々が快適に感じ、従来の白人プロテスタント（WASP）のリーダーと同じだけの機会を得ることができる企業でありたいと考えています。ロイは、注目すべき混血であるため、この多様性を明らかに重視しています。

オープン スペースは、自己組織化された会議をまとめるのに役立つアプローチです。私は1997年にノーム・カースによって最初に紹介され、それ以来、何度もそれを使用し、そして自分で使用してきました。それは小規模、12～20人程度のグループ、そして100～200人規模の大規模でもうまく機能するようです。1～3日間の期間で見てきました。私が見てきたバリエーションと共に説明します。クレステッドビュートは20人程度の小規模な年次ワークショップです。Agile Universe 2002では、1つのトラックでオープン スペースを行い、約100人が参加しました（それ以来継続していますが、私は参加できていません）。foocampでは、数百人が参加して行われました。このテクニックはハリソン・オーエンによって開発され、彼の著書で詳しく説明されています。

イリノイ大学アーバナ・シャンペーン校の悪賢い人々がFortranのリファクタリングの準備をしているようです。ブライアン・フートはプロジェクトについて彼の比類のないスタイルで書いています。（彼はソフトウェアの中で最も面白いライターの一人ですが、彼に何かを書かせるのは、生きたサーベルタイガーから生きた子羊のチョップのネックレスを着けながら歯を抜こうとするようなものです。）（はい、古いニュースだとわかっていますが、彼のブログで別のものを見て、それからこれを見つけました。）

メソッドまたはクラスをシールすると、サブクラスによるオーバーライドを防ぐことができます。

プログラム要素（一般的にはクラス、メソッド、またはフィールド）のアノテーションとは、そのプログラム要素に追加されたメタデータの一種であり、追加コードを使用してその要素を装飾するために使用できます。

スーパークラスの呼び出しは、OOフレームワークで時々発生する小さな臭い（またはアンチパターン）です。その症状は非常に簡単に発見できます。あなたは、何らかのフレームワークに接続するためにスーパークラスを継承しています。ドキュメントには、「独自の処理を行うには、processメソッドをサブクラス化してください。ただし、メソッドの先頭にスーパークラスのメソッドを呼び出すことを忘れないでください」のようなことが書かれています。例としては、次のようなものがあります。

企業が成長するにつれて、どのようにリードされ、誰がリーダーの選定に責任を負うのかについて、より心配する必要があります。ほとんどの企業にはオーナー（株主）がおり、最終的には経営陣を選定します。その後、経営陣が企業のほとんどの意思決定を行います（少なくともそうしたいと考えています）。

Thoughtworksが私をクライアントの前に出すと、必ず聞かれる質問の1つは「SOA（サービス指向アーキテクチャ）についてどう思いますか？」です。SOAは人によって意味が大きく異なるため、この質問に答えるのはほぼ不可能です。

テスト可能性は非常に重要な美徳であるため、システムのテスト可能性を向上させるためにアーキテクチャ上の決定を行う必要があります。

制御の反転は、フレームワークを拡張する際に遭遇する一般的な現象です。実際、それはフレームワークの定義特性として見なされることがよくあります。

制御の反転の同義語。

最近言語ワークベンチに関する記事を書いたとき、さらに読むセクションを私のblikiに分離することにしました。新しい情報が登場したときに更新を報告しやすくするためです。

言語ワークベンチを使用することは、従来のドメイン特化言語を使用することとは大きく異なります。これは、JetBrains Meta Programming System（MPS）を使用して、小さくても興味深いDSLを構築する例です。これを使用して、言語ワークベンチを使用することのイメージをつかむことができます。

最近、複数のドメイン特化言語（DSL）間で統合できるツールの開発が急増しています。私はそれらを言語ワークベンチと呼んでいます。言語ワークベンチに関する議論の多くは、オブジェクト管理グループのモデル駆動型アーキテクチャ（MDA）に関する議論と非常によく似ています。私の見解では、MDAは人によって意味が異なり、そのためMDAと言語ワークベンチの関係の見方が変わります。確かに、MDAのアイデアを使用して言語ワークベンチを構築しているMDAの実践者グループもいます。しかし、私の感じでは、MDAが提供する支援はせいぜい部分的なものです。モデル駆動開発（MDD）のより広範な学派は、MDA標準との関連性なく、これらのアイデアの多くを反映しています。これは、言語ワークベンチのアイデアと非常に合致しています。

ソフトウェア開発におけるほとんどの新しいアイデアは、古いアイデアに対する新しいバリエーションです。この記事では、これらのアイデアの1つ、つまり私が言語ワークベンチと呼ぶツールのクラスの成長するアイデアについて説明します。その例としては、Intentional Software、JetBrainsのMeta Programming System、MicrosoftのSoftware Factoriesなどがあります。これらのツールは、私が言語指向プログラミングと呼ぶ古いスタイルの開発を取り入れ、IDEツールを使用して言語指向プログラミングを有効なアプローチにすることを目指しています。彼らの野心が成功するかどうかを予測するほど先見の明はありませんが、これらのツールはソフトウェア開発の将来において最も興味深いものの1つであると考えています。少なくとも概要において、それらがどのように機能し、将来の有用性に関する主な問題点を説明するために、このエッセイを書くのに十分なほど興味深いものです。

ドメイン特化言語（DSL）を構築する場合、実行可能にするにはどうすればよいでしょうか？これは、内部DSLの場合、実際の言語に埋め込まれているため、簡単に答えることができます。外部DSLには、より多くの作業が必要です。ここでは、単純なDSLの例を取り上げ、そこからコードを生成するいくつかの簡単な方法を示します。

アジャイル手法には厳密な定義がないという不満によく遭遇します。不満を言う人は、特定のチームがアジャイル手法を使用しているかどうかを判断できないことを意味すると主張するかもしれません。また、そのため、アジャイル手法の実行方法を人々に教えるのが難しくなる、カリキュラムは何だと言っているかもしれません。

ある程度、この不満の痛みを感じますが、治療法がないことを受け入れています。この厳密性の欠如は、アジャイル手法の定義する性質の一部であり、そのコアとなる哲学の一部です。

多くの人が、新しいソフトウェア開発ツールの無料コピーを提供してくれています。残念ながら、それらを見る時間はありません。そして率直に言って、通常はがっかりしています。ツールに熱心になることはめったにありません。

主要なコード変更なしでシステムを変更できるようにする、テーブル駆動型の手法。

Thoughtworksについて話すとき、私たちは主にソフトウェアアプリケーション開発会社として話します。また、私たちの価値観や、私たちがほとんどの企業とは異なる種類の企業になろうとしていることについても少し話します。しかし、これらはすべて要点を取り繕っているに過ぎません。基本的にThoughtworksは会社であることではありません。

先日、本のサンプルコードの一部に取り組んでいました。いくつかの変更を加え、すべてを動作させ、テストを実行し、個人的なリポジトリにコミットしました。その後、別の領域に移り、いくつかの変更を加えました。すると、前の領域で予期しないテストが失敗しました。自動テストを実行する目的の一部は、予期しない失敗を見つけることですが、この本のコードは完全に独立した領域を持っています。これは奇妙でした。

コードで現在の日付または時刻を取得する必要がある場合、そのデータに対して直接システムルーチンにアクセスしないでください。「現在の日付/時刻」を特定の値に上書きできるように、何らかのラッパーを配置してください。これは、テストを簡素化するために重要です。

アジャイル手法の一般的な要素の1つは、ソフトウェア開発においてプログラミングの中核的な役割を高めることです。これは、ソフトウェアエンジニアリングコミュニティが通常行うよりもはるかに大きな役割です。この一部として、コードをソフトウェアシステムの主要なドキュメント（主要でない場合でも）として分類することが挙げられます。

ソフトウェア開発の見方において、私が根本的に重要だと考えることがいくつかあります。ソフトウェア開発における私の鍵となるものを1つ選ぶとすれば、それはソフトウェア開発における重要な要素は、作業を行う人材であるということです。最高の開発者の生産性は平均よりもはるかに高く、給与の差よりもはるかに大きいです。したがって、費用対効果の高いソフトウェア開発を行う上で最も重要なのは、開発者の個々のコストが平均よりもはるかに高くても、最高のチームを採用することです。少数の能力の高い（そして高価な）人材は、多くの能力の低い（安価な）開発者よりもはるかに生産性が高くなります。その生産性の違いは、日々のレートが高くても、少数の能力の高い人材の方がソフトウェアをより安価に生産することを意味します。

オープンソースの世界、特に私たちにとって興味深い側面の1つは、それが魅力的な研究コミュニティであることを証明していることです。オープンソースプロジェクトは多くの形態をとっていますが、かなりの数のプロジェクトが、アイデアを取り上げてそれを中心にプログラミングを行い、それがどこまで進むのか、価値があるかどうかを確認しています。設計とプログラミングは分離されていると信じているならば、これは奇妙に聞こえる概念ですが、それらが結びついていることを受け入れるならば、非常に理にかなっています。

（辞書への追加です。）

テスト不可能 (Detestable)（形容詞）：テスト不可能なソフトウェア。

私は長い間、プログラミング言語における静的型付けと動的型付けの議論に関する寄稿を嫌っていました。これは、人々が聞くよりも議論することに駆り立てられるような感情的なトピックの1つです。しかし、何度か尋ねられたので、私の個人的な経験について寄稿します。私は誰かを説得しようとしているわけではありませんが、誰かがその中で考えさせられるものを見つけてくれることを願っています。

利用したい人のために、いくつかのフィードを用意しています。ここではRSSフィードという用語を使用していますが、実際にはAtomフィードです。

エンタープライズソフトウェア開発のパターンをカタログ化するための様々な取り組みについての個人的な調査。

UML Distilledでは、UMLのアクティビティ図を教える良い本がないことを嘆きました。今でも良い本はありませんが、最近Conrad Bock氏によるUML 2.0に関する記事を見つけました。これらの記事の中には、Distilledでカバーできたよりも詳細にアクティビティ図について説明しているものがあります。（ご存知ない方のために付け加えると、Conrad Bock氏はUML 2のアクティビティ図作業のリーダーの1人です。）

最新のアプリケーションサーバーの頻繁に宣伝される機能の1つは、クラスタでフェイルオーバーを提供することです。クラスタリングは、サーバーの1つがダウンした場合でも、他のサーバーが顧客にサービスを提供できるため、アプリケーションの信頼性を向上させます。フェイルオーバーは、インタラクション中にサーバーがダウンした場合に、クラスタがそのインタラクションを別のサーバーに移動できるため、さらに信頼性を向上させることができます。

しかし、これは問題になる可能性があります。

バリスタは同期処理を行いません - 彼らの理由は、あなたも非同期になる理由となるかもしれません。

過去の情報の状態に関する質問に答えるために使用できる様々なパターンをまとめたものです。これには、「1999年7月1日のマーティンさんの住所は？」や「1999年8月12日に請求書を送信した際に、マーティンさんの住所だと考えていたのは？」という形式の質問が含まれます。

私の著作を読まれた方なら、私が進化型設計の熱烈な支持者であることをご存知でしょう。このアプローチに対する私の熱意にもかかわらず、どの手法も完璧ではなく、その成功と同様にその問題についても喜んで報告します。

Microsoftは、PatternShareという新しいコミュニティリソースをリリースしました。これは、多くのパターン作成者からのパターンサマリーを集め、それらの相互接続についての議論とさらなる探求のためのプラットフォームを提供するというものです。この作業の多くは、比類のないパターン系統を持つWard Cunningham氏が主導しました。そこには、私自身、GOF、POSA、Hohpe/Woolf、Evans、Microsoftのパターンがあります。

UML 2で登場した新しい表記法の1つは、クラスが必要とするインターフェースを示すソケット表記です。これは、Microsoftによって普及された、複数のインターフェースを実装するクラスを示す「ロリポップ」表記法に由来しています。したがって、Arrayクラスが複数のインターフェースを実装していることをこのように示すことができます。

私は昨年多くの時間をThoughtworksで過ごし、多くのプロジェクトの多くの人々と話をしました。私が強く理解したメッセージの1つは、ローテーションの価値です。

会議やワークショップの途中で、いくつかの事項について投票を行い、順位付けしたり、サブセットを選択したりすることが役立つ場合があります。これを行うための迅速かつ簡単な方法は、ドット投票です。

私は自分のブログでThoughtworksについて書くことを避けてきました。これは主に、自分の雇用主の広告のように見えるものを好まないためです - すべてのページにロゴがあるのは十分すぎるほどです。しかし、私たちのデリバリー作業（私の執筆の多くのアイデアの源です）だけでなく、私たち自身の構造化の方法においても、私の頭はますますそのようなことでいっぱいになっています。独立系コンサルタントとしての成功した生活を諦めた理由は、Thoughtworksが特別で珍しい会社だと感じたからです。昨年、私は雇用主の社会的側面にますます関心を持つようになり、それらの一部についてブログを始めることにしました。

ここ数日間、Jimmy Nilsson氏が主催するノルウェーのエンタープライズソフトウェアに関するワークショップに参加していました。ワークショップでは、設計原則の束を考案し、投票するセッションがありました。

時々、特定の専門分野が漸進的な方法で使用できるかどうか疑問に思う人がいます。「（セキュリティ|ユーザーインターフェース設計|データベース|国際化|*）はアジャイルプロジェクトではできません。この側面は事前に完了する必要があるからです。」