Rakeは、makeやantと同様の目的を持つビルド言語です。makeやantと同様にドメイン特化言語ですが、これら2つとは異なり、Ruby言語でプログラムされた内部DSLです。この記事では、rakeを紹介し、このWebサイトを構築するためにrakeを使用したことから得られた興味深い点、つまり依存関係モデル、合成タスク、カスタムビルドルール、ビルドスクリプトのデバッグについて説明します。

APIは、プログラマーがテスト、相互運用性をサポートし、競争を促進するためにインターフェースを再実装できるように、著作権で保護されるべきではありません。

データを検証する場合、通常は例外を使用して検証エラーを通知するべきではありません。ここでは、そのようなコードをリファクタリングして通知パターンを使用する方法について説明します。

専用のハンドヘルドGPSデバイスに価値はあるのでしょうか？

goto Aarhus 2014では、私、Erik Dörnenburg、そしてTim Brayによる基調講演で、インターネット上のプライバシー問題について多くの時間を割いて検討しました。その後、Ola Biniが私たちと一緒にこの問題、現状、そして私たち開発者が何をすべきかについて話し合いました。

ここ数年、サービスベースのアーキテクチャは、より小さく、より焦点を絞った「マイクロ」サービスへと移行してきました。このアプローチには、各コンポーネントを個別にデプロイ、スケーリング、保守できること、複数のチームで開発を並列化できることなど、多くの利点があります。しかし、これらの追加のネットワークパーティションが導入されると、モノリシックなインプロセスアプリケーションに適用されたテスト戦略を再検討する必要があります。ここでは、複数の独立してデプロイ可能なコンポーネントの追加のテストの複雑さを管理するためのいくつかのアプローチと、複数のチームがそれぞれ異なるサービスのガーディアンとして行動しているにもかかわらず、テストとアプリケーションを正しく維持する方法について説明します。

ソニーのミラーレスカメラα6000とソニー・ツァイス16-70mmレンズの組み合わせに関する非公式レビューです。

モリソンズ・オーダーパッドは、スーパーマーケットのスタッフが店内を歩き回りながら新しい在庫を注文するのに役立つタブレットWebアプリケーションです。その結果、軽量のJavaサーバーアプリケーションによって支えられたタブレットWebアプリケーションのための優れた説明アーキテクチャが実現しました。クライアント側でのアプリケーション制御とDOMインタラクションの分離、サーバー側での小規模で焦点を絞ったフレームワークの使用、広範なスタックテスト環境、および必要な機能を理解するためのパイロットプロジェクトの使用について重点的に説明します。

Ruby Roguesは、Rubyの世界で人気のポッドキャストです。彼らは、Ruby版のリファクタリングについて議論するために私を再び招待してくれました。リファクタリングの定義、デバッガーをあまり使用しない理由、この書籍を最新のものにするために何ができるか、リファクタリングツールの役割、コメントを有効に活用できるかどうか、リファクタリングと書き換えのトレードオフ、モジュール性とマイクロサービス、そしてソフトウェア業界が過去20年間でどのように変化してきたかについて話し合いました。

あなたは会議に座って、あなたのチームが過去2年間取り組んできたコードについて考えています。あなたは今できる最善のことは、そのコードをすべて捨てて、まったく新しいアーキテクチャで再構築することだと判断しました。その運命のコードについて、それに費やした時間について、ずっと前に下した決定について、どのように感じますか？

goto 2014の基調講演で、Erikと私は、ソフトウェア専門家がソフトウェアが社会に及ぼす影響について責任を負うという側面を検討しました。現在、主な懸念事項の1つはプライバシーであり、これは大量監視によって損なわれています。電子メールは、サービスへの電子メールの移動により、監視を容易にする電子メール提供の集中化につながったため、現在問題となっています。大量監視のコストを法外なものにするために、電子メールの暗号化の使用を拡大するように努めることによって、プライバシーを向上させる必要があります。この課題は、主にユーザーエクスペリエンスとソフトウェアパッケージングの課題であり、暗号化を深く理解する必要はありません。

私たちは、多くの場合、一般的なコンテンツ管理システム（CMS）を使用して、豊富なコンテンツを含む多くのWebサイトを構築します。最近のプロジェクトでは、グローバルメーカーのマーケティングWebサイトに関与し、高可用性とトラフィックニーズを備えた複雑なインタラクティブコンテンツが求められました。私たちの対応は、編集と公開の分離パターンを適用し、コンテンツの作成と配信のために2つの異なるソフトウェアスタックを構築することでした。このデッキでは、このアーキテクチャの概要と、スタック間の統合、ライブサイトの安全なプレビューの提供、システムの進化とスケーリングの処理に関する私たちの対応について説明します。

共同作業者が私のWebパブリッシングツールチェーンを使用できるようにVagrant VMをセットアップした経験から得たいくつかのメモ。Chefを使用してVMをプロビジョニングし、rbenvを使用して適切なバージョンのRubyをインストールおよび制御しました。

最近、Appleのラップトップのメモアプリでメモを削除しました。バックアップを偏執的に保管し、通常はすべての作業をgitのようなリポジトリにコミットする人として、誤って削除することについてはあまり心配していません。しかし、Appleのメモアプリにはバージョン管理の形式がなく、誤って何かを削除してしまうのは非常に簡単です。毎日のrsyncバックアップがあり、Time Machineを実行していますが、グーグル検索ではメモを取り戻す簡単な方法を見つけることができませんでした。そのため、他の誰かがこれを行う必要がある場合に備えて、私が行ったことをここに示します。

マイクロサービスアーキテクチャスタイルの使用について人々と話すと、多くの楽観主義が聞こえてきます。開発者は、より小さな単位で作業することを楽しんでおり、モノリスよりも優れたモジュール性を期待しています。しかし、アーキテクチャ上の決定と同様に、トレードオフがあります。特にマイクロサービスでは、運用に重大な影響があります。運用は、単一の明確に定義されたモノリスではなく、小規模なサービスのエコシステムを処理する必要があります。したがって、特定のベースラインコンピテンシーがない場合は、マイクロサービススタイルの使用を検討しないでください。

成熟度モデルは、個人またはグループの現在の有効性を評価し、パフォーマンスを向上させるために次にどのような能力を習得する必要があるかを把握するのに役立つツールです。多くの分野で成熟度モデルは評判が悪くなっていますが、誤用される可能性はありますが、適切に使用すれば役立ちます。

守破離は、技をどのように学ぶかについての考え方です。この名前は日本の武道（特に合気道）に由来し、Alistair Cockburnは、ソフトウェア開発の技法と方法論を学ぶ方法として導入しました。

PofEAAでは、「オブジェクトを分散させないでください」と言いました。このアドバイスは、マイクロサービスへの私の関心と矛盾しますか？

カナリアリリースとは、変更をインフラストラクチャ全体に展開してすべての人が利用できるようにする前に、少数のユーザーにゆっくりと展開することで、本番環境に新しいソフトウェアバージョンを導入するリスクを軽減する手法です。

私と、同僚のバドリとの間で行われた、六角形アーキテクチャとそれが Rails アプリケーションで果たす役割についての会話のビデオがいくつかあります。最初のビデオでは、六角形アーキテクチャの意味と、永続化フレームワークとして Active Record と Data Mapper パターンのどちらを選択するのかについて説明します。2 番目のビデオでは、アプリケーションにおける Rails のアーキテクチャ上の役割について、より広く議論します。Rails をプラットフォームとして捉えるべきか、それともコンポーネントのスイートとして捉えるべきか。

2014年の初めに、2つのコンピュータセキュリティの欠陥が発見されました。Appleの「goto fail」バグとOpenSSLの「Heartbleed」バグです。どちらも広範囲に及ぶ深刻なセキュリティ障害を引き起こす可能性があり、その全容は未だに解明されていません。その深刻さを鑑み、ソフトウェア開発業界は、これらの欠陥がどのようにして発見される可能性があったのかを反省し、将来このような欠陥を防ぐ能力を向上させる必要があります。この記事では、ユニットテストが果たし得る役割について考察し、ユニットテスト、そしてより重要なのはユニットテスト文化が、これらの特定のバグをどのように特定できたかを示します。さらに、そのような文化のコストとメリットについて考察し、Googleでそのような文化がどのように浸透したかを説明します。

すべてのコンシューマに影響を与えるインターフェースの変更を行うには、2つの思考モードが必要です。変更自体を実装することと、すべての使用方法を更新することです。特に、変更が複数のクライアントまたは外部クライアントを持つ公開インターフェース上にある場合、両方を同時に行おうとすると困難になる可能性があります。

**並列変更**（**拡張と縮小**とも呼ばれる）は、変更を拡張、移行、縮小の3つの明確なフェーズに分割することにより、安全な方法でインターフェースに後方互換性のない変更を実装するためのパターンです。

Ruby on Railsの作者であるDavid Heinemeier Hanssonは、RailsConfで基調講演を行い、TDDは死んだと宣言しました。これは、Railsコミュニティとより広範なソフトウェア開発コミュニティの両方で、予想通り大きな論争を引き起こしました。また、David、Kent、そして私との間で興味深い会話が行われました。私たちは、これらの会話は他の人も見てみたいと思うほど興味深いと決めたので、ソフトウェア開発におけるTDDの役割について議論する一連のビデオハングアウトを録画しました。

ユニットテストはソフトウェア開発でよく話題になり、私がプログラムを書いてきた間ずっと慣れ親しんできた用語です。しかし、ほとんどのソフトウェア開発用語と同様に、それは非常に曖昧に定義されており、人々が実際よりも厳密に定義されていると考えている場合、混乱が生じることがよくあります。

自己テストコードとは、私が「リファクタリング」の中で、機能的なソフトウェアと併せて包括的な自動テストを書くというプラクティスを指すために使用した名前です。うまく行けば、テストを実行する単一のコマンドを呼び出すことができ、これらのテストがコードに潜むバグを明らかにすると確信できます。

私の講演の多くは YouTube でご覧いただけます。これは YouTube にある私の講演のプレイリストで、私は最新の状態に保つよう最善を尽くしています。

ほとんどのエンタープライズアプリケーションは、永続データをデータベースに格納します。このデータベースは、アプリケーションの状態の運用上の更新と、意思決定のサポートと分析に使用されるさまざまなレポートをサポートします。しかし、運用上のニーズとレポートのニーズは、スキーマの要件とデータアクセスパターンが異なるため、多くの場合大きく異なります。このような場合は、レポートのニーズをレポーティングデータベースに分離することをお勧めします。レポーティングデータベースは、重要な運用データのコピーを取得しますが、異なるスキーマで表現します。

「マイクロサービスアーキテクチャ」という用語は、ここ数年で、ソフトウェアアプリケーションを独立してデプロイ可能なサービスのスイートとして設計する特定の方法を説明するために登場しました。このアーキテクチャスタイルの厳密な定義はありませんが、ビジネス機能を中心とした組織、自動化されたデプロイメント、エンドポイントのインテリジェンス、言語とデータの分散制御など、いくつかの共通の特性があります。

今世紀の初めに、私は著書「エンタープライズアプリケーションアーキテクチャのパターン」に取り組みました。この本を執筆する際に抱えていた問題の1つは、タイトルの付け方、つまり私が書いている種類のソフトウェアシステムを何と呼ぶかでした。私は常に、自分のソフトウェア開発の経験が、医療記録、外国為替取引、給与計算、リース会計などの特定の形式のソフトウェアに焦点を当ててきたことを意識していました。これらは、プリンター、ゲーム、飛行制御ソフトウェア、または電話交換機に組み込まれたソフトウェアとは大きく異なります。私はこれらの種類のシステムを説明するための名前が必要であり、「エンタープライズアプリケーション」という用語に落ち着きました。

私はこれまでにかなりの数の本を書いてきましたが、時々受ける質問の1つは、それらを書くためにどのようなツールを使用しているかということです。私は長年にわたって、少なくとも私の目的には非常に気の利いたツールチェーンを開発してきました。そのため、ここでは、すべてがどのように連携しているかについての私の考えを紹介します。

ソフトウェアシステムが、異なるプロセスで実行されているソフトウェア（おそらくネットワークを介した異なるマシン上）にリモートコールを行うのは一般的です。インメモリコールとリモートコールの大きな違いの1つは、リモートコールが失敗したり、タイムアウト制限に達するまで応答がないままハングしたりする可能性があることです。さらに悪いことに、応答のないサプライヤーに多くの呼び出し元がいる場合、重要なリソースが不足し、複数のシステムにわたるカスケード障害が発生する可能性があります。彼の優れた著書「Release It」の中で、Michael Nygard は、この種の壊滅的なカスケードを防ぐためにサーキットブレーカーパターンを普及させました。

サーキットブレーカーの背後にある基本的な考え方は非常にシンプルです。保護された関数呼び出しをサーキットブレーカーオブジェクトでラップし、障害を監視します。障害が特定のしきい値に達すると、サーキットブレーカーがトリップし、サーキットブレーカーへのそれ以降のすべての呼び出しは、保護された呼び出しがまったく行われずにエラーで返されます。通常、サーキットブレーカーがトリップした場合、何らかのモニターアラートも必要になります。

ソフトウェアコミュニティで見られる厄介な多様性の不均衡につながる多くの要因があります。10代の少女がSTEM科目を敬遠する原因となる教育の問題など、一部の問題は、私たちの職業が解決に中心的な役割を果たせない長期的な問題です。しかし、私たちに直接関係する1つの要因は、テクノロジーコミュニティに蔓延している疎外された雰囲気です。

これは、ミュンヘンで開催されたOOP 2014での私の基調講演の第2部であり、説明するのが難しい講演です。通常、講演の内容を説明するためにタイトルと要約が好きですが、この講演は旅であり、私はどこに行くのかを伝えるのではなく、私と一緒に地面を探検してもらいたいのです.アジャイルソフトウェア開発のほとんどの採用における私の最大の問題、つまりユーザー、アナリスト、プログラマー間の相互作用の性質から始まるとだけ言っておきましょう。それはこれらの役割を探求し続け、プログラマーとユーザーの関係、彼らに対する私たちの責任、そして最後にプログラマーが立ち向かわなければならないと思う2つの大きな課題についての疑問を提起します。

過去10年ほどで、リファクタリングはコードベースの内部品質を高く保つための広く使用される技術になりました。しかし、ほとんどのチームは、リファクタリングを使用できるさまざまなワークフローを認識していないため、リファクタリングを十分に活用していません。ミュンヘンで開催されたOOP 2014のこの基調講演では、ゴミ拾いリファクタリング、理解のためのリファクタリング、準備リファクタリングなど、これらのワークフローのいくつかを探ります。また、リファクタリングの一般的な正当化が、最善の努力を妨害する理由を思い出させます。（この講演は、インフォデッキとしても扱われています。）

シングルページWebアプリケーションは、多くの場合、アプリケーションロジック、DOM操作、およびサーバーアクセスがすべて混在するjQueryスープになってしまいます。このような関心の混在は、アプリケーションの理解とテストを本来よりも困難にします。分離DOMは、DOMのすべての操作を専用のJavaScriptオブジェクトに分離するモジュール化戦術です。

境界づけられたコンテキストは、ドメイン駆動設計の中心的なパターンです。これは、大規模なモデルとチームの対処に関するDDDの戦略的設計セクションの焦点です。DDDは、大規模なモデルを異なる境界づけられたコンテキストに分割し、それらの相互関係を明確にすることで、大規模なモデルを扱います。

リファクタリングはよく知られた技術に成長し、ほとんどのソフトウェア開発チームは少なくとも定期的にリファクタリングを行っていると主張しています。しかし、多くのチームは、リファクタリングで使用できるさまざまなワークフローを理解しておらず、開発活動にリファクタリングを効果的に組み込む機会を逃しています。このデッキでは、さまざまなワークフローを探ります。チームがリファクタリングをより深く仕事に統合し、より適切に設計されたコードベースを実現することで、新しい機能をより迅速かつ簡単に追加できるようになることを願っています。

「抽象化による分岐」は、変更が進行中の間もシステムを定期的にリリースできるように、ソフトウェアシステムに大規模な変更を段階的に行うための手法です。