10代の頃、人工知能（AI）が今後数年で素晴らしいことを成し遂げるだろうと教えられたことを覚えています。数十年経った今、そのいくつかが現実になりつつあります。最近の勝利は、コンピューターが互いに碁を対戦することで学習し、人間の専門家が理解できないほどの戦略で、急速に人間よりも熟練したことです。今後数年で何が起こるのか、コンピューターはすぐに人類よりも高い知能を持つようになるのか、と考えるのは当然です。（最近の選挙結果を見ると、それはそれほど難しいハードルではないかもしれません。）

しかし、これらの話を聞くと、数十年前のパブロ・ピカソのコンピューターに関するコメントを思い出します。「コンピューターは役に立たない。彼らはあなたに答えを与えることしかできない」。機械学習のような技術によってもたらされる推論の種類は、その結果において本当に印象的であり、ソフトウェアのユーザーと開発者として私たちにとって有用でしょう。しかし、答えは役に立つ一方で、常に全体像を表しているわけではありません。私はこれを学生時代の初期に学びました。数学の問題の答えを提供するだけでは2、3点しか取れません。満点を取るには、どのように答えにたどり着いたのかを示す必要がありました。答えにたどり着くまでの推論は、結果そのものよりも価値がありました。これは、独学で碁を習得したAIの限界の1つです。彼らは勝つことはできますが、戦略を説明することはできません。

サンファンとレース・フォー・ザ・ギャラクシーは、優れていて、テンポが速く、考えさせられるカードゲームです。レースの方がより深く、そのアイコンは一部の人にはとっつきにくいでしょう。

機能トグル（機能フラグとも呼ばれることが多い）は、コードを変更せずにシステムの動作を変更できる強力な手法です。それらはさまざまな使用カテゴリに分類され、トグルを実装および管理する際には、その分類を考慮することが重要です。トグルは複雑さを招きます。スマートなトグル実装プラクティスと適切なツールを使用してトグル構成を管理することで、その複雑さを抑制できますが、システム内のトグルの数を制限することも目指す必要があります。

最近、私の同僚であるNeal Ford、Rebecca Parsons、Pat Kuaが、「進化型アーキテクチャの構築」という本を書きました。彼らから序文を書いてほしいと頼まれ、光栄に思いました。

ThoughtworksはApax Fundsに買収されました。現在の経営陣は、これまでどおり会社を経営していきます。

テスト影響分析（TIA）は、ビルドのテスト自動化フェーズを高速化する最新の 方法です。これは、ソースコードのコールグラフを分析して、本番コードの変更後にどのテストを実行すべきかを判断することで機能します。Microsoftはこのアプローチに多大な労力を費やしてきましたが、開発チームが非常に安価に役立つものを実装することも可能です。

多くの大企業では、ITエンジンが経営幹部のペントハウスから何階も離れた場所にあり、ビジネスとデジタル戦略がそれを実行するための重要な作業から分離されています。アーキテクトの主な役割は、ペントハウスとエンジンルームの間をエレベーターで移動し、ソフトウェア製造の自動化、事前の意思決定の最小化、テクノロジーの進化に伴う組織への影響など、これらのデジタル活動をサポートするために必要な場所で停止することです。

Ryan Lockard（Agile Uprising）は、アジャイルプロジェクトのアーキテクチャに関するポッドキャストの会話にRebecca Wirfs-Brockと参加するよう私を招待しました。Rebeccaは、私がキャリアをスタートさせた頃に大きな影響を与えたResponsibility-Driven Designを開発しました。私たちは、アーキテクチャの定義方法、アーキテクチャに対するテストの影響、ドメインモデルの役割、どのようなドキュメントを準備するか、そしてどれだけのアーキテクチャを事前に実行する必要があるかについて話しました。

ヴィティカルチャーとザ・ギャラリストはどちらも、生産中心のビジネスという強力なテーマを持つ優れたユーロゲームです。

従来、QAはリリース前にソフトウェアをテストして、リリースの準備ができているかどうかを確認することに重点を置いていました。しかし、現代のQA組織は、本番環境で実行されているソフトウェアにもますます注目を集めています。ログやその他の監視ツールを分析することで、開発組織に強調表示する品質の問題を発見します。このアプローチは、継続的デリバリーを使用してソフトウェアの新しいバージョンを迅速かつ確実に本番環境に導入する組織で特にうまく機能します。

セッションシークレットは、Cookieの暗号化に使用されるキーです。アプリケーション開発者は、開発中に弱いキーに設定することが多く、本番環境では修正しません。この記事では、そのような弱いキーがどのようにクラックされるか、そしてそのクラックされたキーを使用してアプリケーションをホストするサーバーの制御を取得する方法について説明します。強力なキーと慎重なキー管理を使用することで、これを防ぐことができます。ライブラリの作者は、ツールとドキュメントを使用してこれを奨励する必要があります。

データのカプセル化は、オブジェクト指向スタイルの中心的な信条です。これは、オブジェクトのフィールドを公に公開すべきではなく、オブジェクトの外部からのすべてのアクセスはアクセサメソッド（ゲッターとセッター）を介して行うべきであると言っています。公開アクセス可能なフィールドを許可する言語もありますが、通常はプログラマーにこれを行わないように注意します。自己カプセル化はさらに一歩進んで、データフィールドへのすべての内部アクセスもアクセサメソッドを介して行う必要があることを示しています。アクセサメソッドのみがデータ値自体に触れる必要があります。データフィールドが外部に公開されていない場合、これは追加のプライベートアクセサを追加することを意味します。

プログラミングでは、オブジェクトの基本的な概念は、データと動作のバンドルです。これは、一連の関連関数を作成するときに共通のデータコンテキストを提供します。また、オブジェクトがそのデータへのアクセスを制御できるようにするデータ操作のためのインターフェースを提供し、派生データをサポートし、データの無効な変更を防ぐことを容易にします。多くの言語は、オブジェクトの定義として機能するクラスを定義するための明示的な構文を提供します。ただし、ファーストクラス関数とクロージャを持つ言語がある場合は、これらの構成要素を使用して、オブジェクトとしての関数パターン（元々はEugene Wallingfordによって記述された）を使用してオブジェクトを作成できます。

Agile Uprisingポッドキャストは、アジャイルマニフェストの作成者との一連のインタビューを行ってきました。これは私の番のインタビューです。スノーバードワークショップ自体のことはあまり覚えていませんが、マニフェストに至るまでのコンテキストについて少し説明することができました。

昨年末に向けて、私はThoughtworksの同僚とワークショップに参加し、「イベント駆動型」アプリケーションの性質について議論しました。ここ数年、私たちはイベントを多用するシステムをたくさん構築してきました。そして、それらはしばしば賞賛され、しばしば非難されてきました。私たちの北米オフィスはサミットを開催し、世界中からThoughtworksのシニア開発者が集まってアイデアを共有しました。

サミットの最大の成果は、人々が「イベント」について話すとき、実際にはまったく異なることを意味していることを認識したことです。そこで私たちは、どのような有用なパターンがあるのかを解明しようと多くの時間を費やしました。このメモは、私たちが特定した主なパターンの簡単な要約です。

合成監視（セマンティック監視とも呼ばれる）は、アプリケーションの自動テストのサブセットを、稼働中の本番システムに対して定期的に実行します。結果は監視サービスにプッシュされ、障害が発生した場合にアラートをトリガーします。この手法は、自動テストと監視を組み合わせて、本番環境でのビジネス要件の失敗を検出します。

継続的インテグレーションは、ソフトウェア開発で一般的な手法です。会議では、多くの開発者がその使用方法について語り、継続的インテグレーションツールはほとんどの開発組織で一般的です。しかし、私たちは皆、まともな手法には認定プログラムが必要であることを知っています。そして幸いなことに、1つ存在します。継続的デリバリーとDevOpsの第一人者によって開発されたこのプログラムは、非常に迅速に管理できるにもかかわらず、その結果が非常に洞察力に富んでいることで知られています。かなり成熟していますが、それほど知られていません。そのため、この手法のファンとして、この認定プログラムを読者の皆様と共有することが重要だと考えています。継続的インテグレーションの認定を受ける準備はできていますか？そして、テストを受けることで明らかになる衝撃的な真実にどのように対処しますか？

最新のWeb開発には多くの課題があり、その中でセキュリティは非常に重要であると同時に、しばしば軽視されています。脅威分析などの手法は、あらゆる深刻な開発に不可欠であるとますます認識されていますが、すべての開発者が当然のこととして行うことができる、そして行うべき基本的なプラクティスもいくつかあります。