外部のドメイン固有言語について書く上で難しいことの1つは、プログラミング言語コミュニティによってすでに深く追跡されている領域を歩いているということです。プログラミング言語の研究は常に学術活動の人気分野であり、この分野で長年研究している多くの人々ほどこのトピックについて深い知識を持っていないことを私は最初に認めます。そのため、必然的に、なぜ私のような新米が、このよく踏み荒らされた地で本を書くことができると思うのかという疑問が出てきます。

少し前、私は学術キャリアに進む予定のポスドクとチャットをしました。彼は研究トピックについて私に質問をしてきました。それは、彼が私の意見が実用的な研究について彼に知らせることができると感じたからです。私はあまり役に立ちませんでしたが、ソフトウェア開発が実際にどのように機能し、どのような問題に研究努力が必要なのかを感じるために、業界でしばらく時間を過ごすのが最善の方法だと述べました。この考えに対する彼の答えは非常に厄介なものでした。

DSLを使用すると、ビジネス担当者はプログラマーを関与させずにソフトウェアルールを作成できるようになるでしょうか？

DSLについて議論するとき、ビジネス担当者が自分自身でコードを書くという問題がよく提起されます。私はこの考え方に対してCOBOL推論を適用したいと思います。つまり、COBOLの本来の目的の1つは、プログラマーなしでソフトウェアを作成できるようにすることであり、それがどうなったかはご存知のとおりです。したがって、プログラマーなしでコードを書くための計画が策定された場合、COBOL（および他の多くのもの）が失敗した場所で成功する特別な点は何かと問う必要があります。

技術的負債は非常に便利な概念ですが、どのように測定するのかという疑問が生じます。残念ながら、技術的負債は金融負債とは異なるため、どれだけ借金をしているかを把握するのは簡単ではありません（ただし、最近では金融の種類を測定するのに苦労しているようです）。

SOA推進者が推進した新しいサービスの世界の特徴の1つは、レジストリの概念でした。多くの場合、これは、システムがレジストリ内の有用なサービスを自動的に検索し、それらのサービスをすべて単独でバインドして消費できるようにする自動システムという観点から説明されていました。

まあ、コンピューターは時々賢く見えるかもしれませんが、私はそのアイデアを特に買いませんでした。自動サービスルックアップの奇妙なエッジケースがあるかもしれませんが、22回中20回は、ルックアップを行っているのは人間のプログラマーだろうと私は思っています。

数年前、私はプログラミング言語の人がJavaによって引き起こされた言語の「核の冬」について話しているのを聞きました。誰もがJavaの計算モデル（当時C＃は単なるコピーと見なされていました）に収束しすぎて、プログラミング言語の創造性が消えてしまったと感じていました。その気持ちは今では和らいでいますが、おそらくもっと重要な解凍が始まりつつあるかもしれません。それはデータベースに関する考え方のより長く、より深い凍結です。

QConサンフランシスコ2008で、レベッカ・パーソンズと私は、アジャイルアプローチがエンタープライズアーキテクチャグループとどのように連携するかについて講演しました。現在、アジャイルプロジェクトチームとアーキテクチャグループの間には、多くの不信と対立があります。私たちはその理由を掘り下げ、これらのグループが協力できる方法を探ります。

企業のコンピューティングニーズが、効果的なコラボレーションを可能にするために互いにサービスを提供する多くの小さなアプリケーションに分割されている、SOAの幸福の美しい世界を想像してみましょう。ある晴れた朝、コンシューマーサービスはサプライヤーサービスからの情報を必要とします。注目すべき点は、サプライヤーサービスにはこの情報を取得するための必要なデータと処理ロジックがあるにもかかわらず、その情報をサービスインターフェースを介してまだ公開していないということです。サプライヤーには潜在的なサービスがありますが、実際にはまだ存在していません。

数年前、私はクライアントと話をしていて、彼が私たちが使用していたアジャイルアプローチについて気に入らなかったことを教えてくれました。「プロジェクトのこの初期段階でこれらの困難を抱えているのは、正しい感じがしない」と。彼の反応とは反対に、私の考えでは、この初期の苦痛は、アジャイル開発、または実際に反復的な開発プロセスの大きなメリットの1つです。

オスロはマイクロソフトのプロジェクトであり、さまざまなことが聞こえていましたが、今週のPDC会議まで詳細はほとんどありませんでした。私たちが知っていたのは、モデル駆動型ソフトウェア開発とドメイン固有言語に関係があるということです。

私、同僚のニール・フォード、ジェフリー・スノーバー（PowerShellの作成者）のマイクロソフトチャンネル9のインタビュー。一般的なトピックはDSLです。ニールと私はJAOO 2008でこのトピックに関するチュートリアルを終えたばかりで、ジェフリーといくつかの良い会話をしました。

Thoughtworksは、オフィスがある都市のコミュニティ向けに「四半期ごとの技術説明会」というオープンな講演会を頻繁に開催します。トロントでのこのQTBでは、スコット・ショーと私がITとビジネスの間に新しい関係を構築する方法について話します。IT部門を解散すべきだと考える理由を説明します。

要件とは、製品の構築を開始する前に発見する必要があるものです。構築中、またはさらに悪いことに、クライアントが製品を使用し始めたときに要件を発見することは非常に費用がかかり、非効率的であるため、正しい考えを持つ人はそうしないと仮定し、二度とそれについて言及しません。

-- スザンヌとジェームス・ロバートソン

アジャイルメソッドは、構築中およびデリバリー後に「要件」を発見することを目的としているため、この根本的な仮定に違反します。しかし、上記の賢明なアドバイスをこのように軽視することは、最近多くの主要なWebサイトが行っていることと比較すると何でもありません。これらのサイトは、ユーザーがサイトで行うことを観察し、その情報を使用して、以下のような新しい機能のアイデアを生み出すことによって要件を探索します。

SOAはアジャイルアプローチで行うことができますか？

私は、技術系ではない人々のためにDSLの議論をまとめるように求められました。たぶん私はスティーブン・オグラディを読みすぎたかもしれませんが、Q&A形式でそれをやるという抑えきれない衝動を感じました。ということで、始めます。

言語ワークベンチは、複数の統合されたドメイン固有言語の豊富な環境を通じてソフトウェアを構築するように設計された、新しいクラスのソフトウェア開発ツールを説明するために、私が2005年に作った用語です。これらのツールは、まだ主流になるには程遠いですが、それらの開発は継続しており、引き続き興味深いものです。それらは、私がプログラミングの状況を大幅に変える可能性があると感じている数少ないものの1つです。

モデル駆動型ソフトウェア開発（MDSD）とドメイン固有言語（DSL）の間の接続は何ですか？

MDSDの文脈で「DSL」という用語が頻繁に登場するのはごく普通のことです。実際、一部のMDSDの人々は、DSLはMDSDの世界にのみ存在すると考えているようです。私は最近、自分の本のためにDSLについてたくさん書いていますが、これまでのところ、MDSDの側面にはあまり触れていません。代わりに、従来のプログラミングにおけるDSLの役割に焦点を当ててきました。DSLはテキスト言語とMDSDの世界の両方に存在し、両方でほぼ同じ役割を果たします。

モデル駆動型ソフトウェア開発 (MDSD) は、従来のプログラミングスタイルに代わるものとして捉えられるソフトウェア開発スタイルです。このアプローチは、ソフトウェアシステムのモデルを構築することに重点を置いています。これらのモデルは通常、図式的な設計表記 (UMLがその1つ) を通して具体化されます。この考え方は、これらの図を使用してシステムをモデリングツールに指定し、その後、従来のプログラミング言語でコードを生成するというものです。

あらゆる職業と同様に、ソフトウェア開発にも、通常は無視されるが、まさに都合の悪い瞬間に反撃してくる、忘れられがちな活動があります。その一つがデータ移行です。

アジャイルソフトウェア開発を使ってみようと考えていますが、代わりにリーンソフトウェア開発を使うべきでしょうか？

メディアWebサイトにおける最大の問題の1つは、大量のトラフィックへの対処です。メディアは注目を集めることがすべてですが、一度にアクセスが多すぎると、パフォーマンスの低下が問題を引き起こし、評判を損なう可能性があります。この問題は、Webトラフィックのバースト的な性質によって悪化します。最初は管理可能な速度で進んでいても、大きなニュース記事が出ると、急激なスパイクが発生します。当社のクライアントの中には、数分で2桁のスパイクが発生したのを目撃したところもあります。

ドメイン固有言語（または、実際にはあらゆるコンピュータ言語）について語るときに、よく使われる言葉に、構文ノイズというものがあります。RubyはJavaよりもノイズが少ないとか、外部DSLは内部DSLよりもノイズが少ないと言う人もいます。構文ノイズとは、私たちが本当に言いたいことの一部ではないが、言語定義を満たすために存在する余分な文字のことです。ノイズ文字は、プログラムの意味を曖昧にし、プログラムが何をしているのかを解き明かすことを強いるため、良くありません。

私は最近、ドメイン固有言語について多くの人と話しており、外部DSLに対する一般的な反応は、パーサーを書くのが難しいということです。実際、外部DSLのキャリア構文としてXMLを使用する理由の1つは、「パーサーを無料で入手できる」ということです。これは私の経験とは一致しません。パーサーはほとんどの人が考えているよりもはるかに簡単に書けると思いますし、XMLを解析するのと比べて特に難しいわけでもありません。

ドメイン固有言語（DSL）の基本的な考え方は、あらゆる種類のソフトウェア問題に対応することを目的とした汎用言語ではなく、特定の問題に対応することを目的としたコンピュータ言語です。ドメイン固有言語は、コンピュータが登場してからほぼ同じくらい長い間、議論され、使用されてきました。

n回目、そしてきっと最後ではないと思いますが、私はプラクティスを定義し、それらを「ベスト」としてラベル付けし、おそらくCの言葉（認定）を使うという議論に陥っています。これはおなじみの議論であり、まだ始まったばかりですが、どこへ行くか大体予測できます。これは、より優れたソフトウェア開発者が誰であるかを特定し、既存の開発者が能力を向上させる方法を特定したいという、完全に合理的な欲求によって推進されています。

私の同僚であるジム・ウェバーは、エンタープライズでの統合に、軽量でビジネス指向のアプローチを採用することで高い評価を得ています。彼はまた、非常に力強く面白い講演者としても定評があります。そのため、私はQCon 2008での基調講演で彼とステージを共有することに、興奮すると同時に不安を感じていました。彼は、いくつかの重要な情報が織り込まれた、とても面白いプレゼンテーションをまとめました。そして私たちは、事前トークでのパイントのおかげもあってか、すぐに飛び込みました。私たちはエンタープライズ統合の歴史、強力だと思っているが実際にはただ太っているだけのシステムの成長、アジャイル思考の役割、ウェブの影響（なぜそれが発明されたのかというジム独自の理論を含む）、そしてこれがどのようにゲリラSOAにつながるかについて話しました。

ソフトウェアの世界で一般的に受け入れられている信念の1つは、才能のあるプログラマーは生産性が高いということです。私たちは生産性を測定できないため、これは証明できない信念ですが、もっともらしく思えます。結局のところ、あらゆる人間活動は、他の人よりも優れている人、多くの場合、著しく優れている人がいることを示しています。また、プログラマー自身もよく指摘していますが、常に自分をより才能のあるカテゴリーに属していると考える人たちが指摘しているようです。

ソースベースのプログラミング環境は、システム定義を、システム定義の編集可能なストレージ表現として機能する一連のソースファイルに保持します。これらのソースは、実際に実行される実行可能表現に変換されます。ソースベースのコードは、射影編集（ここで私は2つをより詳細に議論します）とは対照的に、今日最も身近な形式です。

採用の場面を想像してみてください。数年の経験を持つ2人の候補者がいます。青コーナーには、あなたが好む設計スタイルの優れた幅広い設計スキルを持つ人がいます（私の場合、それはDRY、パターンを賢明に使う、TDD、コミュニケーションコードなどですが、実際のリストは重要ではありません。あなたが好むものであることが重要です）。ただし、彼女はあなたが使用している特定のプラットフォームテクノロジーについては何も知りません。赤コーナーには、これらの問題についてはほとんど知識（または関心）がないが、あなたのプラットフォームについて非常によく知っている人、言語のエッジケース、利用可能なライブラリ、ツールの上で指が自然に動く人がいます。彼らに関する他のすべてが（これのような思考実験を除いて決してありませんが）同等であり、あなたのチームにはこの候補者が埋めるかもしれない大きな穴がないと仮定します。どちらを優先しますか？

ソース編集の代替案は、システムのコア定義をモデルに保持し、射影を通して編集するという考え方です。