スライドキュメントとは、スライド資料とドキュメントの中間のようなものです。プレゼンテーション中のスライドと、後で読める配布資料の両方に、1つのスライド資料を使用するという考えです。問題は、その2つのニーズがスライドに非常に異なる要件をもたらすため、両方を満たすことができないことです。結果として、スライドキュメントは通常、どちらの目的にも失敗します。

継続的デリバリーの概要を1時間で説明します。トピックには、継続的デリバリーの正当性、デプロイメントパイプライン、継続的インテグレーション、DevOps、デプロイメント戦略が含まれます。ハイライトは、ジェズがギリシャ神話の英雄としてリリース候補を擬人化するところです。

数ヶ月前、新しい会社のラップトップであるThunderboltポートを備えたMacbook Proが支給されました。Thunderboltディスプレイを入手しようかとぼんやり考えていたところでした。Appleのディスプレイは高価であるにもかかわらず評判が良いと聞いており、ドッキングステーションとして機能するディスプレイのアイデアは魅力的でした。

2006年、私の同僚であるニール・フォードが、ポリグロットプログラミングという用語を作り出しました。これは、さまざまな言語がさまざまな問題に取り組むのに適しているという事実を利用するために、アプリケーションを複数の言語を組み合わせて記述する必要があるという考えを表現するためのものでした。複雑なアプリケーションは、さまざまな種類の問題を組み合わせているため、すべての側面を1つの言語に適合させようとするよりも、仕事に適した言語を選択する方が生産性が高くなる可能性があります。

ここ数年、特に関数型言語など、新しい言語への関心が爆発的に高まっており、Clojure、Scala、Erlangなどに時間を費やしたくなることがよくあります。しかし、私の時間は限られており、DatabaseThawという、より重要なもう1つの変化を優先しています。最初の兆候がクライアントやその他の関係者から出てきており、見通しは魅力的です。新しい戦略的なエンタープライズアプリケーションを開始する場合、永続性が関係型であると想定すべきではないと断言できます。関係型の選択肢が正しい場合もありますが、他の選択肢を真剣に検討する必要があります。

ソフトウェアの良いところの1つは、人々がそれを求め、それを迅速に求めているように見えることです。組織がチームにソフトウェアの生産を加速するように求めるのは普通であり、時折、組織は真のコミットメントを示す方法、つまりチームに人員を追加するためにお金を使うことで、それを支援しようとします。

リファクタリングについて話し始めたり、書き始めたりした当初から、人々はソフトウェア開発プロセス全体にどのように組み込むべきかを私に尋ねてきました。ソフトウェア開発ライフサイクルにリファクタリングフェーズを設けるべきか、イテレーションのどの割合をリファクタリングタスクに費やすべきか、誰をリファクタリング担当に割り当てるべきかをどのように見つけるべきでしょうか？いくつかの計画的なリファクタリングの取り組みのための場所はありますが、私はコードをクリーンアップする必要があるときはいつでも、誰でも行う、機会主義的な活動としてリファクタリングを奨励することを好みます。

goto（以前はJAOOとして知られていました）は、長年私のお気に入りのカンファレンスです。彼らは長年にわたり、効率的で友好的な組織と組み合わせて、高い水準のコンテンツを維持することに尽力してきました。そのため、私がカンファレンスを過度に消費したことでカンファレンス恐怖症になったにもかかわらず、オーフスへのやや複雑な旅行に出かけるときは、まだ楽しい予感を感じています。

動画の作成と編集はかつては高価な作業でしたが、現在ではカメラと編集ソフトウェアは安価になっています。結果として、私のような多くの大声で話す人が、自分の考えを広めるのに役立つ動画の作成に乗り出しています。これを行うには多くの理由があります。それは多くの可能性を秘めた媒体であり、ステージでうまく話す私のような人に適しており、人々が動画にお金を払うという十分な証拠があります。これは、自分の収入と、人々がそれを真剣に受け止めている証拠の両方として良いことです。これらの理由にもかかわらず、私は今のところ飛び込むつもりはありません。

少し前に、シンディと私は、数人の隣人と一緒に、終わるかどうか誰にもわからない長い探求を始めました。この探求は、入手可能なすべてのビデオ版で、シェイクスピアのすべての劇を見ることです。それはとても楽しいものでしたが、私は頻繁に旅行しているので、私たちが望むほど多くをカバーすることはできません。私たちはそれらをほぼ年代順に実行しており、ちょうど「真夏の夜の夢」を終えたところです。

人々がエンタープライズアプリケーションを開始するとき、最も初期の質問の1つは「データベースとどのように通信するか」です。最近では、「関係型データベースを使用すべきか、これらのNOSQLデータベースのいずれかを使用すべきか」という、少し異なる質問をするかもしれません。しかし、考慮すべきもう1つの質問があります。「そもそもデータベースを使用する必要があるのか？」

私たちがアジャイルマニフェストを書いた10年後、私たちはアジャイル2011カンファレンス中の記念イベントに招待されました。17人の著者のうち15人が参加し、公園のベンチパネルで聴衆からの質問やコメントに答えました。再会して、快適な共同作業と議論に簡単に戻ることができたのは、私たち全員にとって驚きだったと思います。私たちの議論には、マニフェストの作成の背景、私たちが満足していたことや不満に思っていたことを過去10年間で振り返ること、アジャイルの将来の発展、アジャイルとリーンとの関係などが含まれていました。

ソフトウェア開発分野で私が知っているほとんどすべての人が、特許とそれらが私たちの分野で使用されてきた方法を深く嫌っていると思います。私は長い間、この件に関する投稿をTODOリストに入れていましたが、This American Lifeによる特に優れた調査ジャーナリズムの後、ようやくそれについて書くことにしました。私の投稿の要点は、特許（ソフトウェア特許でさえ）は原則としては良い考えですが、実際には完全な災難に変わっており、廃止した方が良いということです。

数週間前、友人からおすすめのポッドキャストを尋ねられました。回答するのに時間がかかりましたが、これは私が聞くのが好きなものを提案する良い機会だと思いました。

私の同僚や私がフィーチャーブランチについて話しているのを聞いた人は、私たちがそのパターンをあまり好んでいないことを知っているでしょう。私たちの反対の重要な部分は、ブランチングは簡単だが、マージは難しいという観察に基づいています。時々聞く議論の1つは、最新のバージョン管理ツールはマージを十分に簡単にするため、フィーチャーブランチングは価値があるということです。

私は最近JavaScriptを調べており、そこで印象的だったのは、ゲッターとセッターに同じ関数名を使用する習慣です。したがって、jQueryでバナーの高さを知りたい場合は、$("#banner").height()を使用し、高さを変更したい場合は、$("#banner").height(100)を使用します。

この規約は、Smalltalkで使用されていたため、私にはなじみがあります。banner heightで値を取得し、banner height: 100で値を変更する可能性があります。それがSmalltalkの規約だったことを知っていれば、私がその言語に遠く離れた愛情を持っているため、私がそれを好きになることを期待するのに十分です。しかし、最高のものにも欠点があり、私はこのコーディングスタイルに対する嫌悪感を隠すことはできません。

私のお気に入りのサウンドバイトの1つは、痛いなら、もっと頻繁に実行することです。これは表面上はナンセンスに見えるが、深く掘り下げるといくつかの貴重な意味を生み出すという嬉しい特性を持っています。

CQRSは、Command Query Responsibility Segregationの略です。これは、私がグレッグ・ヤングによって最初に説明されたのを聞いたパターンです。その中心にあるのは、情報を読み取るために使用するモデルとは異なるモデルを使用して情報を更新できるという概念です。状況によっては、この分離は価値がある場合がありますが、ほとんどのシステムではCQRSがリスクの高い複雑さを追加することに注意してください。

最近、インターネットストリームでのいくつかのブログ、ツイート、またはその他の波紋を介して、「The Presentation」という本を見つけました。これは、アンドリュー・アベラによる究極のプレゼンテーションに関する無料の本です。これは、プレゼンテーションを行う特定の方法を概説した、短くて軽快な本です。私は彼が概説したアプローチが好きでした。プレゼンテーションテクニックに興味がある場合、特に少人数のグループに行動を起こすように説得するためにプレゼンテーションを行う場合は、一見の価値があると思います。

LMAXは、新しいリテール金融取引プラットフォームです。そのため、低レイテンシで多数の取引を処理する必要があります。このシステムはJVMプラットフォーム上に構築されており、単一スレッドで1秒間に600万件の注文を処理できるビジネスロジックプロセッサを中心に構成されています。ビジネスロジックプロセッサは、イベントソーシングを使用して完全にインメモリで実行されます。ビジネスロジックプロセッサは、ロックを必要とせずに動作するキューのネットワークを実装する並行処理コンポーネントであるDisruptorによって囲まれています。設計プロセス中に、チームは、キューを使用する高性能並行処理モデルの最近の方向性が、現代のCPU設計と根本的に矛盾していると結論付けました。

しばらくの間、私は自分のデジタル一眼レフ用のレンズセットアップに満足していました。つまり、一般的なオンカメラレンズとしてのSigma 18-200、広角用のCanon 10-22、ローライトポートレートや被写界深度を狭くするためのCanon 50 f1.8と100 f2です。これは良いセットアップで、気に入った写真をたくさん撮るのに役立っています。

しかし、私のようなほとんどの強迫観念的なアマチュアが知っているように、より良い機器への絶え間ない欲求が常にあります。18-200のような消費者向けレンズは、もう少し良いものほどシャープではないと聞きます。より速く、より静かにオートフォーカスできるレンズを手に入れることができるだろう、多分私の長めの望遠ショットは、私が得られるべきだと考えているより少しソフトではないだろうか？

私は最初の招待の波に乗るほどクールではありませんでしたが、ソーシャルネットワークにおける「次なる大物」かもしれないGoogle+に、ようやく参加することができました。この記念すべき出来事を、これまでのソーシャルネットワークの使い方と、Google+の影響に関する情報に基づかない推測を少し書くことで記念するのは、ある意味で適切だと思います。

IT部門での共通の質問は、カスタムソフトウェアを構築するか、パッケージを購入するかによって、機能を提供するかどうかです。私がプログラミングを始めてから長い間、その選択をどのように行うかについて議論が激化しています。このことについての私の基本的な立場は、UtilityVsStrategicDichotomyに基づいています。これを要約すると、サポートしているビジネスプロセスが競争上の優位性の一部である場合は、カスタムソフトウェアを構築する必要があり、そうでない場合は、パッケージを購入し、パッケージが機能する方法に合わせてビジネスプロセスを調整する必要があることを意味します。

私の意見が明らかに優れているにもかかわらず、多くの企業がこれを行っているようには見えません。多くの場合、二分法を無視していますが、それが一つの問題です。しかし、ここで焦点を当てたい問題は、パッケージを購入する際の一般的な落とし穴です。

このビデオ（12分）で、マイク・メイソンと私がフィーチャーブランチの危険性と、その代替案について話し合います。

最近、自宅のメディアサーバーをアップグレードすることに決め、HP N36Lを購入しました。今のところ満足しています。

フラグ引数は、関数の値に応じて異なる操作を実行するように関数に指示する関数引数の種類です。コンサートの予約をしたいと想像してみましょう。これには、通常とプレミアムの2つの方法があります。ここでフラグ引数を使用すると、次のようなメソッド宣言になります。

3つの講演セグメント：テストにおける非決定性、ソフトウェア開発の経済学、アジャイルマニフェストからの10年。

人々のプレゼンテーション資料でよくある問題は、テキストや図が非常に小さいため、部屋の前方の人のみがきちんと見ることができるということです。私がそうなる可能性を減らすために行う簡単なことを1つ紹介します。プレゼンテーションを作成するとき、表示サイズを50％に設定します。50％で簡単に読めない場合、聴衆も苦労することになります。

Thoughtworksは珍しい会社であり、そのため、私のような企業懐疑論者でさえ、ここに10年間も留まっています。Thoughtworksの重要な特徴は、単なる商業的な存在以上の、より広い目的を重視していることです。ここ数年、私たちは自分たちの考え方を表現するために、3本柱モデルを使用しています。

Webサービスを使用する利点の1つは、システムのさまざまな部分を分離するのに役立つことです。人々は、ある程度の分離をもって別々のコードベースで作業できます。分離が得られますが、サービスはインターフェースを介して相互に通信する必要があるため、結合を完全に排除することはできません。悲しいことに、多くのチームがこの結合を必要以上に悪化させています。

私が初めて電子書籍リーダーを手に入れてから、わずか1年ほどしか経っていません。今では、本当に必要な場合にのみ紙の本を購入しています。私は前回の本を主に紙の本として考えて書きましたが、それが最後になるでしょう。今後は電子形式が念頭に置かれます。これらの変更は本の状況を完全に変えるでしょうが、それ以外は、次のステップはそれほど明確ではありません。

アジャイルマニフェストから10年に関するSDタイムズのインタビュー

PowerPointは、騎士が鎧を身に着けて戦場を駆け回っていた中世に発明されたものではありません。しかし、今日のスライドデッキは、昔の騎士たちと共通の特徴を共有しています。どちらも、遠くからでもシンボルを明確に区別できる必要があります。泥やほこりはないかもしれませんが、多くのプロジェクターはコントラストがそれほど優れていません。

非常に多くのモバイルプラットフォームが登場し、それぞれ異なるUIを備えているため、多くの人々がクロスプラットフォームツールキットに注目しています。これにより、モバイルアプリを一度作成し、さまざまなモバイルデバイスに展開できます。これらのツールキットは使用する価値があるでしょうか？

昨日、私はコードベースを調べて、コードのドメインモデルの部分を見ていました。コードベースを探索するとき、学んでいることを覚えておくためにメモを取るのが好きです。一部のコードベース、特にドメインモデルでは、UMLクラス図をスケッチするのが便利だと感じています。

デモがうまくいかない可能性は、聴衆の重要性に正比例します。

モジュールが提供するすべてのサービスは、ストレージまたは計算によって実装されているかどうかを裏切らない、均一な表記法で利用できる必要があります。

-- Bertrand Meyer

Bertrand Meyerは、影響力の強い著書Object-Oriented Software Constructionでこの原則を提唱しました。

この原則の重要な点は、personオブジェクトがあり、その年齢を尋ねる場合、年齢がオブジェクトの格納されたフィールドであるか、計算された値であるかに関係なく、同じ表記法を使用する必要があるということです。これは事実上、personのクライアントは、年齢が格納されているか計算されているかを知る必要も、気にする必要もないことを意味します。

最近、サバンナとチャールストンの南部都市で1週間の休暇を過ごしました。私は両方の都市の美しさや歴史的な興味について良い評判を聞いていましたが、それらの良い評判を確信できます。どちらも数日間散策する価値があります。

自動回帰スイートは、ソフトウェアプロジェクトにおいて、本番環境での欠陥を減らすために、また進化的な設計に不可欠な役割を果たすことができます。開発チームと話していると、非決定的なテスト、つまり合格したり失敗したりするテストの問題についてよく聞きます。制御されていない非決定的なテストは、自動回帰スイートの価値を完全に破壊する可能性があります。この記事では、非決定的なテストに対処する方法について概説します。最初は隔離が他のテストへのダメージを軽減するのに役立ちますが、それでもすぐに修正する必要があります。したがって、非決定性の一般的な原因である、隔離の欠如、非同期動作、リモートサービス、時間、およびリソースリークの治療について説明します。

時々、私は「アジャイルマニフェストの署名者」として紹介されます。通常、彼らが意味するのは、私がアジャイルソフトウェア開発のためのマニフェストの著者であり、したがってその最初の署名者の1人であるということです。しかし実際には、著者の17人よりも多くの署名者がおり、最後に見たときには10,104人に達していました。もしそうしたいのであれば、あなたもそのリストに参加することができます。

多くのプログラムは、作成と維持にコストがかかるリソースを利用する必要があります。これらの例としては、データベース接続とスレッドがあります。リソースプールは、これらのリソースを管理するための良い方法を提供します。

私の友人や同僚のほとんどは、ソフトウェア開発における認証制度について非常に否定的であり、私もその軽蔑を共有しています。これは、ソフトウェアの認証が定義上悪いと考えているのではなく、ほとんどすべてが見る基本テストに失敗しているだけです。

最近、自宅のサーバー環境をアップグレードすることにしました。ここで計画していたことについていくつか考えを投稿しましたが、今回、実施した内容でこのページを更新しました。

初めてデジタル一眼レフに移行したとき、私は意図的に安価なカメラ、つまり Canon Rebel XTi/400D を購入しました。これは、レンズにもっとお金をかけたいという理由もありましたが、テクノロジーは進化し、数年後には本体を買い替えることになるだろうとわかっていたからです。

「経営陣はより多くの機能を求めており、品質を気にしない」という理由で不満を抱いている開発者をよく見かけます。これを聞くといつも悲しくなります。なぜなら、これを聞くと、開発者、経営陣、顧客はすでに負けていることを知るからです。彼らの敗北は、状況をトレード可能な品質仮説の観点から捉えていることに起因しています。

私は皮下テストを、アプリケーションのUIのすぐ下で動作するテストという意味で使用します。これは、アプリケーションの機能テストを行う場合に特に役立ちます。エンドツーエンドの動作をテストしたいが、UI自体を通じてテストするのが難しい場合に便利です。

ソフトウェア職人技に関するDaniel Terhorst-Northの最近のブログ記事は、多くのブログでの議論を引き起こしました（興味があれば、以下に要約します）。多くのことが含まれていますが、彼のテーマの1つが特に私の心に響いたため、この投稿をしました。

特定のテクノロジーにより、ユーザーが自分でソフトウェアを作成できるようになり、プログラマーが不要になると主張する話をよく耳にします。これを聞くと、COBOLがその目的であったことを思い出します。そして、それがどうなったかはご存知のとおりです。

テストダブルを使用する最も一般的なケースの1つは、外部サービスと通信している場合です。通常、このようなサービスは別のチームによって保守されており、ネットワークが遅く信頼性が低い可能性があり、サービス自体が信頼できない場合もあります。そのため、テストダブルは便利で、自分のテストが遅く信頼性が低くなるのを防ぎます。しかし、ダブルに対してテストを行うと、常に、ダブルが外部サービスを正確に表現しているか、外部サービスが契約を変更した場合にどうなるかという疑問が生じます。

このblikiを含むこのサイトのほとんどは、XMLからHTMLへの変換プロセスを使用して構築されています。私は自分のXML語彙で記事とblikiエントリを作成し、これらのソースを読んでいるHTMLに変換します。2000年に開始したときは、XSLTで行っていました。XSLTプログラミングはかなり得意になりましたが、XSLTを使い続けたいほどのマゾヒストではないという結論に至りました。バンガロールへのフライトでRubyでblikiトランスフォーマーを作成するという短い実験の後、REXMLライブラリを使用してRubyに切り替えました。今、そのコアライブラリをNokogiriに変更する時が来ました。

インドにいる間、ダイビングを楽しむためにアンダマン諸島で1週間の休暇を取りました。私たちはポートブレアの主要な中心部からフェリーで数時間の場所にあるハブロック島でほとんどの時間を過ごしました。私たちの経験から共有できる散在したものをいくつか紹介します。