データ節約（Datensparsamkeit）はドイツ語で、英語に適切に翻訳するのが難しい言葉です。これは、本当に必要なデータのみを扱うべきだという、データの収集と保存に対する姿勢を表しています。

ほとんどの内部REST APIは、単一の統合ポイント向けに構築された、1回限りのAPIです。この記事では、非公開APIの制約と柔軟性、そして複数のチームにわたる大規模なRESTful統合から得られた教訓について説明します。

私はこのサイトで、ソフトウェア開発業界における問題となっているダイバーシティの不均衡と、過小評価されているグループの割合を増やすためになぜ意図的な行動をとる必要があるのかについて、何度か書いてきました。これはすべて結構なことですが、当然ながら、どの過小評価されているグループについて懸念すべきかという疑問が生じます。Thoughtworksでは、ダイバーシティを受け入れる主な動機の1つに焦点を当てるために、「歴史的に差別を受けてきた」という用語を使用しています。

数ヶ月前、私は Google Nexus 7タブレットを購入しました。私はデバイスを使用してからしばらく経ってから、その体験を投稿するのが好きなのですが、その方針の欠点は、私が話しているタブレットがすでに superseded されていることです。それでも、今後のタブレット選びの参考になるかもしれないので、私のコメントを伝えさせていただきます。

私はユーロゲームのファンです。ユーロゲームとは、親しみやすく、それでいて考えさせられるボードゲームのスタイルです。私は、たいてい一晩でルールを覚えてプレイできるのに、何度もプレイできるほどの戦略的な面白さがあるところが気に入っています。時々、ユーロゲームについて、そして私のお気に入りのゲームは何なのか、もっと詳しく聞かれることがあります。そこで、ユーロゲームを説明する短い記事と、私の棚にあるゲームのインタラクティブなリストを紹介します。

テクノロジー分野における女性の参加率の低下とその対策について、20分のパネルディスカッションに参加しました。

JavaScriptコミュニティでは、非同期コードのテストには「通常の」同期コードのテストとは異なるアプローチが必要だという誤解が一般的のようです。この記事では、なぜそうではないのかを説明します。非同期動作をサポートするコードのユニットテストと、本質的に非同期であるコードのテストの違いを明確にします。また、Promiseベースの非同期コードが、非同期動作を検証しながらも、明確で読みやすい方法でテストできる、クリーンで簡潔なユニットテストにどのように役立つかを示します。

しきい値テストとは、デプロイメントパイプラインに挿入されるテストで、現在のビルドの値をしきい値と比較することで、測定可能な現象を監視します。現在のビルドの値がしきい値を超えた場合、テストは失敗し、ビルドも失敗します。

Webページに対してテストを書く場合、リンクをクリックしたり、何が表示されているかを判断したりするために、そのWebページ内の要素を参照する必要があります。しかし、HTML要素を直接操作するテストを書くと、UIの変更に対してテストが脆くなってしまいます。ページオブジェクトは、HTMLページまたはフラグメントをアプリケーション固有のAPIでラップすることで、HTMLを掘り下げることなくページ要素を操作できるようにします。

尋ねるな、命じろ（Tell-Don't-Ask）は、オブジェクト指向とは、データとそのデータを操作する関数をまとめて扱うことであるということを、人々に思い出させる原則です。オブジェクトにデータを求めてそのデータに基づいて行動するのではなく、オブジェクトに何をするかを指示すべきであることを思い出させてくれます。これは、データを扱うために、オブジェクトに振る舞いを移動することを促します。

2013年のGoto Amsterdamでの私の基調講演です。いつものように、2つの短い講演からなる「21世紀のソフトウェア設計」というテンプレートに従っています。まず、スキーマレスデータ構造について語り、なぜ常に暗黙のスキーマが存在するのか、そしてその結果について説明します。次に（25分24秒から）、アジャイルソフトウェア開発の本質とアジャイル fluencyモデルについて話します。

Given-When-Thenは、テストを表すスタイル、あるいはその支持者が言うように、Specification By Exampleを用いてシステムの振る舞いを指定するスタイルです。Daniel Terhorst-NorthとChris Mattsによって、ビヘイビア駆動開発（BDD）の一部として開発されたアプローチです。Cucumberのような多くのテストフレームワークの構造化アプローチとして登場します。4段階テストパターンの再定式化と見なすこともできます。

InformITとのインタビューで、私がThoughtworksで働くのが好きな理由について、私見（かなり偏っている）を述べています。Thoughtworksに入ったきっかけ、働き続けている理由、そしてこの興味深い会社に参加して成功するために何ができるかについて話しています。

流れるようなインターフェースの問題点の1つは、奇妙に見えるメソッドが生成されることです。次の例を考えてみましょう。

「隠すことが何もない」私たちのためではなく、調査報道ジャーナリストや活動家のような面倒な人のためにプライバシーを支援する必要があります。彼らがいなければ、私たちの民主主義は崩壊するでしょう。

ソフトウェアシステムの一般的な機能として、ユーザーがデータ構造に独自のフィールドを定義できるようにすることが挙げられます。アドレス帳を考えてみましょう。追加したいものがたくさんあります。毎日新しいソーシャルネットワークが登場する中で、ユーザーは連絡先にBunglr IDの新しいフィールドを追加したいと思うかもしれません。

ストーリーポイントは、アジャイルプロジェクトでストーリーのサイズを測るための一般的な名称です。XPベロシティと組み合わせることで、ストーリーがいつ完了できるかの予測を提供することにより、計画を支援する手法となります。

ストーリーカウントは、計画と見積もりのための手法です。ストーリーポイントと同様に、XPベロシティと連携して、一定期間に配信できるストーリー数を把握するのに役立ちます。ただし、単位時間あたりのストーリー数のみを考慮し、相対的なサイズを（ほとんど）無視するという点が異なります。

理想時間は、初期のエクストリームプログラミングで使用されていた用語で、作業量の見積もりに役立てられていました。現在では、ストーリーポイントまたはストーリーカウントに取って代わられています。

エクストリームプログラミング（XP）は、主にケント・ベックによって開発されたソフトウェア開発方法論です。XPは初期のアジャイル手法の1つであり、実際、2000年代初頭には、スクラムが主流になるまでは、XPが支配的なアジャイル手法でした。多くの人々（私自身も含む）は、XPがアジャイル手法に注目を集めるきっかけとなった主要な触媒であり、アジャイル開発を始めるための基礎としてスクラムよりも優れていると考えています。

「クラウド」という言葉は、ここ数年で非常に誇大宣伝された言葉になっています。誇大宣伝された言葉の特徴の1つは、定義がほとんどないことです（そう、NoSQLの定義、あなたのことです）。

実は、クラウドコンピューティングの優れた定義が、NISTから提供されています。驚くほど短く理解しやすい標準文書で入手できます（いいえ、冗談ではありません）。

自動構成ツール（CFEngine、Puppet、Chefなど）を使用すると、サーバーの構成方法を指定し、新規および既存のマシンをコンプライアンスに準拠させることができます。これにより、壊れやすいスノーフレークサーバーの問題を回避できます。このようなツールは、自由に破棄して再構築できるフェニックスサーバーを作成できます。イミュータブルサーバーは、このアプローチの論理的な結論であり、一度デプロイされたサーバーは変更されることはなく、単に新しい更新されたインスタンスに置き換えられます。

自動構成ツール（CFEngine、Puppet、Chefなど）を使用すると、サーバーの要素の構成を記述するレシピを提供することで、スノーフレークサーバーを回避できます。構成の同期は、これらの仕様を、定期的なスケジュールまたは変更時に、サーバーインスタンスのライフタイム全体にわたって継続的に適用します。誰かがツール外でサーバーに変更を加えた場合、次回サーバーが同期されるとき、サーバーは中央で指定された構成に戻されます。構成の変更が必要な場合は、構成の仕様（レシピ、マニフェスト、または特定の構成ツールが呼ぶもの）で行われ、インフラストラクチャ全体のすべての関連サーバーに適用されます。

モバイルは依然としてトラフィックにおいて従来のWebよりも小さな部分を占めていますが、そのシェアは拡大しています。そのため、効果的なモバイルアプリケーションを開発するための戦略を検討する必要があります。私たちは、製品ビジョンについて考え、「リーンフォワード」、「リーンバック」、「ルックダウン」のスタイルにユーザーエンゲージメントのスタイルを分け、それらをトランスメディアアプリケーションに統合することについて議論します。トラフィックよりも価値に焦点を当てることの方が重要である理由、レーザー戦略とカバーユアベースプラットフォーム戦略について語り、Android、iOS、そしてWebが3つの実行可能なプラットフォームの選択肢であるという意見を述べます。最後に、Gilesは主要航空会社との私たちの仕事についてのケーススタディを紹介します。

サーバーを介してJSONデータ構造を流すことは、最近よく見られるようになっています。JSONドキュメントは、集約指向データベースまたはリレーショナルデータベースのシリアライズされたLOBを使用して直接永続化できます。JSONドキュメントは、Webブラウザに直接提供したり、サーバー側のページレンダラーにデータ転送するために使用することもできます。JSONがこの方法で使用されている場合、オブジェクト指向言語を使用すると邪魔になるという話を聞きます。JSONはオブジェクトに変換され、再びレンダリングされる必要があるため、プログラミングの労力が無駄になるからです。無駄な点については同意しますが、オブジェクトの問題ではなく、カプセル化の理解不足が問題だと主張します。

継続的デリバリーとは、いつでも本番環境にリリースできるようにソフトウェアを構築するソフトウェア開発手法です。

以下の場合、継続的デリバリーを実行しています

• ソフトウェアはライフサイクル全体でデプロイ可能です
• チームは、新しい機能に取り組むよりも、ソフトウェアをデプロイ可能な状態に保つことを優先します
• 誰かがシステムに変更を加えるたびに、誰でもシステムの本番環境への準備状況に関する迅速な自動フィードバックを得ることができます
• ソフトウェアの任意のバージョンのプッシュボタンデプロイメントを、オンデマンドで任意の環境に実行できます

自動化されたビルドおよびテスト環境の課題の1つは、迅速なフィードバックを得られるようにビルドを高速にする必要がある一方で、包括的なテストの実行には時間がかかることです。デプロイメントパイプラインは、ビルドをステージに分割することでこれに対処する方法です。各ステージは、通常は追加の時間を犠牲にして、信頼性を高めます。初期のステージでは、ほとんどの問題を迅速にフィードバックできますが、後のステージでは、より時間をかけて徹底的な調査を提供します。デプロイメントパイプラインは、継続的デリバリーの中心的な部分です。

依存性逆転の原則（DIP）は90年代初頭から存在していましたが、それでも問題解決の途中で忘れがちです。いくつかの定義の後、私が実際のプロジェクトで使用したDIPのアプリケーションをいくつか紹介します。そのため、独自の結論を導き出すための例がいくつかあります。

ベロシティとは、作業量の大まかな記述を経過時間に結び付けることで計画を調整するのに役立つ概念です。ベロシティとは、チーム（または個人の場合は個人のベロシティ）が一定期間にどれだけの作業を完了するかを示すものです。昨日の天気の原則に従い、通常は過去の期間に完了した作業量を測定することでベロシティを決定する必要があります。一般的なアプローチは、過去3期間のベロシティを平均して、将来の期間のベロシティを決定することです。ベロシティは元々エクストリームプログラミングの一部として形成されましたが、それ以来普及し、現在ではあらゆる種類のアジャイルソフトウェア開発で広く使用されています。

ユーザージャーニーテストは、システムを通じた典型的なユーザーの「ジャーニー」をシミュレートするように設計されたビジネス向けテストの一種です。このようなテストは、通常、ある目標を達成するためにユーザーとシステムとのやり取り全体をカバーします。ユースケースの1つのパスとして機能します。

ストーリテストとは、ユーザーストーリーの一部として配信されるソフトウェアを記述および検証するために使用されるビジネス向けテストです。ストーリーが詳しく説明されると、チームはストーリーの受け入れ基準として機能するいくつかのストーリテストを作成します。ストーリテストは、ソフトウェアの回帰スイートにまとめることができ、要件（ユーザーストーリー）からテスト、そして（実行を通じて）システムの動作までトレーサビリティを提供します。ストーリテストは通常広範囲テストです。

ビジネス向けテストとは、顧客、ユーザー、ビジネスアナリストなどの開発チームの非プログラミングメンバーとのコミュニケーションを支援するために使用されるテストです。自動化されると、システム自体のコンポーネントアーキテクチャを無視して、ドメイン指向の用語でシステムを記述します。ビジネス向けテストは、受け入れ基準としてよく使用されます。このようなテストに合格すると、システムが顧客の期待する機能を提供していることを示します。

SCMS POは、Gap Inc.が発注書を管理するのに役立つアプリケーションです。アプリケーションのアーキテクチャは開発チームに好評であるため、jsonを提供するバックエンドで動作する豊富なjavascriptフロントエンドを備えたシステムの優れた解説アーキテクチャとなっています。興味深い設計機能には、プレゼンテーションモデルパターンのknockout.jsフォームの使用、クライアントとサーバーの両方で実行されるjavascriptバリデーター、リポジトリによるデータアクセスのカプセル化、アプリケーションデータベースとしてのMongoDBの使用、テストポートフォリオなどがあります。

集約は、ドメイン駆動設計のパターンです。DDD集約とは、単一のユニットとして扱うことができるドメインオブジェクトのクラスターです。例としては、注文とその明細品が挙げられます。これらは別々のオブジェクトになりますが、注文（とその明細品）を単一の集約として扱うと便利です。

ユーザーストーリーとは、ソフトウェアシステムの望ましい動作の塊です。アジャイルソフトウェアアプローチでは、大量の機能を計画目的で小さな部分に分割するために広く使用されています。同じ概念を機能と呼ぶこともありますが、最近ではアジャイルの分野では「ストーリー」または「ユーザーストーリー」という用語が主流となっています。

コンポーネントテストとは、テスト対象ソフトウェアのスコープを、テスト対象システムの一部に限定するテストです。システムのできるだけ多くの部分をテストすることを目的とした広範囲テストとは対照的です。

広範囲テストとは、大規模アプリケーションのほとんどの部分をテストするテストです。エンドツーエンドテストまたはフルスタックテストと呼ばれることもあります。システムの明確に定義された一部のみをテストするコンポーネントテストとは対照的です。

Javascriptでは、promiseは非同期操作の保留中の結果を表すオブジェクトです。これらを使用して、コールバックを提供することにより、非同期操作の完了後にさらにアクティビティをスケジュールできます。

ソフトウェアシステムについての理解を深める上での問題の1つは、十分な例が見られないことです。多くの専門分野では、人々はすでに行われたことを見ることで学びます。例は、インスピレーション、優れたアイデアの源、そして困難の警告として役立ちます。長い間、ソフトウェアについてこのように学ぶことははるかに困難でした。

Ruby Roguesは、レギュラーパネルがRubyプログラミングコミュニティのトピックについて議論する人気のポッドキャストです。定期的なブッククラブがあり、最近EAAのPを特集本として選びました。そのため、番組にゲストとして出演し、本書とそこで説明されているパターン、特にこれらのパターンとRailsフレームワークの興味深い関係について議論するように依頼されました。

私がアジャイルソフトウェア開発に初めて出会ったのは、エクストリームプログラミングの黎明期にKent Beckと仕事をしたときでした。そのプロジェクトで私が感銘を受けたことの1つは、計画の立て方でした。これには、私が以前見てきたものよりも軽量でありながら効果的な見積もり方法が含まれていました。10年以上が経過し、現在では経験豊富なアジャイル主義者の間で見積もりを行う価値があるかどうか、あるいは実際に有害かどうかについて議論されています。この質問に答えるには、見積もりがどのような目的で使用されるかを見る必要があると思います。

多くの組織では、永続データはすべて、中央データベース管理グループによって管理されるリレーショナルデータベースに格納されることが期待されています。このような中央制御にはさまざまな理由があり、通常は統合データベースの使用を中心にしています。中央データグループは、不正なデータ、重要な共有リソースの速度を低下させる可能性のあるクエリ、および企業全体で一貫したデータモデルの排除について懸念しています。

これらの目標は立派かもしれませんが、その結果として、データの保存にはかなりの儀式が必要になります。データベースにカラムを追加するのに数週間かかる変更要求に関する苦情をよく耳にします。短期間の進化型設計に慣れている現代のアプリケーション開発者にとって、このような儀式は遅すぎるだけでなく、煩わしいものです。

そのため、アプリケーション開発グループは、DBAを回避するためにNoSQLデータベースを使用していると言っています。彼らがここで使用しているのが「単なるデータストア」であり、「適切なデータベース」ではないことが役に立ちます。こうすることで、DBAをループから外すことができ、多くの場合、DBAには知らされず、DBAも気にしません。

経営陣はメトリクスが大好きです。彼らの考え方は、「自分たちの状況を測るための数値が必要だ。数値は人々に焦点を当てさせ、成功を測るのに役立つ」といったものです。善意から始まった数値による管理は、直感に反して問題のある行動につながり、最終的にはより広範なプロジェクトと組織の目標を損ないます。メトリクスは本質的に悪いものではありません。ただ、しばしば不適切に使用されているだけです。このエッセイでは、経営陣による従来のメトリクスの使用によって引き起こされる多くの問題点を示し、これらの機能不全に対処するための代替案を提案します。

サンフランシスコで開催されたThoughtworksのイベントで、いつもの講演集スタイルで講演を行いました。今回の講演では、スキーマレスデータ構造の使用方法と使用時期、NoSQLデータベースにおける整合性がACID対BASE以上の理由、そして適切に設計されたソフトウェアの経済的な正当性について説明しました。

販売手数料は、すべてのビジネス分野と同様に、ソフトウェアビジネスでもほぼ普遍的に使用されています。販売手数料は、営業担当者と雇用主である企業のインセンティブを一致させるため、好まれています。しかしながら、販売手数料モデルには深刻な問題があり、Thoughtworksが2013年にすべての販売手数料を廃止するに至った問題点があります。

Web開発者は、ブラウザで実行される他のテキストソース言語にコンパイルされるCoffeeScriptやSCSSのような言語をますます使用するようになっています。このようなソースツーソースコンパイラ（トランスパイラとも呼ばれます）は新しいものではなく、CfrontはC++の初期にターゲットCコードを生成するために広く使用されていました。しかし、私にとって、CoffeeScriptとSCSSを透過的なコンパイラとして際立たせる違いがあります。

最近、私たちは世界で最も好きな場所の1つである、セントマーチンに近いカリブ海の非常に小さな島、サバ島に戻ってきました。サバ島の多くの魅力は、そこにないものにあります。ビーチ、ゴルフコース、カジノはありません。カリブ海の多くの地域を埋め尽くすマスツーリズムやリゾート施設は、サバ島が小さすぎて丘陵地帯が多いため、無視してきました。その結果、島は素晴らしく静かでリラックスできます。

「ビッグデータ」は、私たちの業界で最も誇大宣伝された用語の1つに急速に躍り出ましたが、この誇大宣伝によって、これが世界におけるデータの役割に関する真に重要な変化であるという事実が見落とされてはなりません。データソースの量、速度、価値は急速に増加しています。データ管理は、5つの広範な分野で変化する必要があります。より広範なソースからのデータの抽出、新しいデータベースと統合アプローチによるデータ管理のロジスティクスの変更、分析プロジェクトの実行におけるアジャイル原則の活用、ノイズからシグナルを分離するためのデータ解釈技術の重視、そしてそのシグナルをより理解しやすくするための適切に設計された視覚化の重要性です。つまり、大規模な分析プロジェクトは必要なく、代わりに、新しいデータ思考が通常の業務に浸透することを望んでいます。

プログラミングをしていると、現在入力している場所の上に空行を追加したくなりました。私が使用していたエディタにはこの機能が組み込まれておらず、ついにその欲求が限界に達しました。簡単なGoogle検索を行い、数行のコードを見つけ、スタートアップファイルに貼り付けて実行すると、なんと、1回のキーストロークで上の空行を作成できるようになりました。わずか数分で完了し、プラグインをインストールしたり、エディタを再起動したりする必要はありませんでした。これはEmacsユーザーにとっては通常の日常業務です。

近年、スキーマレスデータの利点についての話が増えています。スキーマレスであることは、NoSQLデータベースへの関心の主な理由の1つです。しかし、スキーマレスには、データベースとメモリ内データ構造の両方に関して、多くの微妙な点があります。これらの微妙な点は、スキーマレスの意味と、スキーマレスアプローチを使用することの利点と欠点の両方に存在します。