Heavy Cardboardは、エドワード・ユーラーが運営するボードゲーム専門のメディアチャンネルです。私が初めて出会ったのは、純粋なポッドキャストだった頃で、自分が興味のある種類のゲームをレビューしており、レビューの内容が十分に深く、そのゲームに興味を持つかどうかを十分に判断できるため、楽しめました。その後、YouTubeでライブゲームをストリーミングするビデオチャンネルを追加しました。私はライブゲームを滅多に見ませんが、録画を見て、ゲームを気に入るかどうかを判断するのに役立つことがよくありました。また、エドワードが各ストリームの前に行うルール説明は、ゲームのプレイ方法を学ぶ上で効果的な方法だと感じています。私はこの番組を気に入ってパトロンになり、パトロン専用のSlackチャンネルも利用しています。これは便利なディスカッションフォーラムであり、私が参加した中で最も快適なオンライングループの一つです。

探索的テストとは、学習、テスト設計、テスト実行の迅速なサイクルを重視するテスト手法です。事前に記述されたテストスクリプトにソフトウェアが準拠していることを検証しようとするのではなく、探索的テストではソフトウェアの特性を探求し、発見された事項を妥当な動作または障害として分類します。

ソフトウェアの世界では、「ウォーターフォール」は一般的にソフトウェアプロセスのスタイルを説明するために使用され、反復型またはアジャイルスタイルのアイデアと対照的なものです。ソフトウェアにおける多くのよく知られた用語と同様に、その意味は曖昧で、起源も不明瞭です。しかし、その本質的なテーマは、活動に基づいて大規模な作業を段階に分割することだと考えています。

機械学習アプリケーションは、私たちの業界で人気が高まっていますが、それらを開発、展開、継続的に改善するためのプロセスは、Webサービスやモバイルアプリケーションなどの従来のソフトウェアと比較してより複雑です。これらは、コード自体、モデル、データの3つの軸で変化の影響を受けます。その動作は複雑で予測困難なことが多く、テスト、説明、改善が困難です。機械学習のための継続的デリバリー（CD4ML）とは、機械学習アプリケーションに継続的デリバリーの原則と実践を取り入れるという規律です。

アーキテクチャのエネルギーのかなりの部分は、ロックインの軽減または回避に費やされています。これはかなり高潔な目標です。アーキテクチャは私たちに選択肢を与えることを目的としており、ロックインはその反対を行います。しかし、ロックインは単純な真偽の問題ではありません。ある側面へのロックインを回避することは、しばしば別の側面へのロックインにつながります。また、オープンソースが自動的にロックインを解消するというような一般的な概念は、完全に真実ではありません。ロックインをより詳しく見てみましょう。そうすれば、ロックイン回避に囚われることはありません！

Brass Birminghamは、産業革命期の炭鉱、醸造所、鉄道からなる産業帝国を築き上げる近代的なボードゲームです。エドワードと私は、このゲームの重量感、コンポーネントのレビュー、そして私たちが気に入っている点を詳しくレビューしました。ポッドキャストは最近のゲーム体験についての一般的な会話から始まり、私は自分のゲームのバックグラウンドについて少し話します。実際のレビューは1:16から始まります。

2019年の開始時点では、martinfowler.comの状況を確認することが良い考えのように思えます。2014年にサイトの簡単なレビューを行いましたので、生成されるトラフィックを改めて確認する時期がとうに過ぎています。

優れたフロントエンド開発は困難です。多くのチームが同時に大規模で複雑な製品に取り組むことができるようにフロントエンド開発をスケーリングすることは、さらに困難です。この記事では、フロントエンドモノリスをより小さく、より管理しやすい多くのピースに分割するという最近の傾向、そしてこのアーキテクチャがフロントエンドコードに取り組むチームの有効性と効率をどのように向上させることができるかについて説明します。様々な利点とコストについて説明するだけでなく、利用可能な実装オプションについても説明し、この技術を示す完全な例題アプリケーションに深く掘り下げます。

DevOpsレポートの現状は、調査データの統計分析を使用して、ソフトウェアデリバリー組織のための効果的な実践を決定する年間レポートです。その主要な著者は、ニコール・フォースグレン、ジェズ・ハンブル、ジーン・キムです。

ソフトウェア開発プロジェクトでは、ソフトウェアの品質向上に時間をかけるか、より価値のある機能のリリースに集中するかという議論が一般的です。通常、機能を提供するというプレッシャーが議論を支配し、多くの開発者はアーキテクチャとコードの品質に取り組む時間がないと不満を言っています。この議論は、品質の向上はコストの増加にもつながるという前提に基づいており、これは私たちの一般的な経験です。しかし、直感に反する現実として、内部ソフトウェアの品質は新しい機能の開発を遅らせる無駄を取り除き、ソフトウェアの拡張コストを削減します。

ソフトウェアシステムは、無駄（内部品質の欠陥）の蓄積を起こしやすい傾向があります。無駄とは、システムの更なる修正と拡張を理想よりも困難にするものです。技術的負債は、ウォード・カニンガムによって造られた比喩であり、この無駄に対処する方法について考える枠組みを提供します。金融上の負債のように考えるのです。新しい機能を追加するために必要な追加の努力は、負債に対する支払利子です。

多くの企業は次世代データレイクに投資しており、大規模なデータの民主化を通じてビジネスインサイトを提供し、最終的に自動化されたインテリジェントな意思決定を行うことを期待しています。データレイクアーキテクチャに基づくデータプラットフォームには、大規模な約束を果たせない共通の失敗モードがあります。これらの失敗モードに対処するには、レイクの中央集権的なパラダイム、またはその前身であるデータウェアハウスからシフトする必要があります。現代の分散型アーキテクチャから得られるパラダイムにシフトする必要があります。ドメインを第一級の関心事として考慮し、プラットフォーム思考を適用してセルフサービスのデータインフラストラクチャを作成し、データを製品として扱う必要があります。

ソフトウェアシステムにおけるオブザーバビリティは常に価値があり、クラウドとマイクロサービスの時代になってさらに重要になっています。しかし、システムに追加するオブザーバビリティは、低レベルで技術的な性質のものが多く、多くの場合、さまざまなログ、インストゥルメンテーション、分析フレームワークへの粗雑で冗長な呼び出しでコードベースを散乱させる必要があるように見えます。この記事では、この問題を解決し、クリーンでテスト可能な方法でビジネス関連のオブザーバビリティを追加できるパターンについて説明します。

最近のクライアントエンゲージメントにおいて、サーバーレスアーキテクチャが完璧に適合すると予測しました。しかし、サーバーレスアーキテクチャを採用するというアイデアは、ベンダーロックインへの懸念から、クライアントにはうまく受け入れられませんでした。小売業者にとって、AWSにとどまることは、別の小売企業であるAmazonに競争上の優位性が与えられることを意味する可能性があるため、興味深い時期でした。競合他社を支援しないという考えから、クライアントは私たちが選択したソリューションが他のクラウドベンダーに完全に移植可能であることを確認することに関心を持っていました。