2020年の私のお気に入りの新譜6選

ビジネスと生活のあらゆる側面をデータで強化・改善するという私たちの願望は、大規模なデータ管理方法のパラダイムシフトを必要としています。過去10年間の技術革新は、データ量とデータ処理計算の規模に対応してきましたが、他の次元、つまりデータ状況の変化、データソースの増加、データユースケースとユーザーの多様性、変化への対応速度には対応できていません。データメッシュは、ドメイン指向の分散型データ所有とアーキテクチャ、データ・アズ・ア・プロダクト、セルフサービス型データインフラストラクチャ・アズ・ア・プラットフォーム、そしてフェデレーテッドな計算ガバナンスという4つの原則に基づいて、これらの次元に対応します。各原則は、技術アーキテクチャと組織構造の新しい論理ビューを推進します。

計算ノートブックは、散文ドキュメントを作成するための環境であり、著者はコードを埋め込むことができ、その結果はドキュメントにも簡単に組み込むことができます。これは、特にデータサイエンスの作業に適したプラットフォームです。このような環境には、Jupyter Notebook、R Markdown、Mathematica、Emacsのorg-modeなどがあります。

データサイエンティストが開発した計算ノートブックを本番アプリケーションのコードベースに直接投入することに関心のあるクライアントを多く見てきました。データサイエンスのアイデアは、ノートブックから本番環境に移行する必要がありますが、ノートブックをコードアーティファクトとして展開しようとすると、多くの優れたソフトウェアプラクティスが破られます。予測通り、これにより、いくつかの問題点が観察されています。この行動は、より深い問題、つまりデータサイエンティストとソフトウェア開発者間の協調の欠如の症状です。

読者を惹きつけるための誤解を招くタイトル。時折真実の話。

出所が疑わしいニュース記事が出た場合、ソーシャルメディアはその拡散を遅らせるために一時的なブロックを使用すべきでしょうか？

Google スプレッドシートスクリプトは、非プログラマーと短いスクリプトを共有するのに便利な方法です。

トランプ大統領とその支持者を阻止するために投票することが重要な理由。

ビジネスミーティングでは、数値のグループを平均値を比較することで比較することが一般的です。しかし、そうすることで、これらのグループの数値の分布における重要な情報が隠されてしまうことがよくあります。この情報を明らかにするいくつかのデータ可視化があります。これらには、ストリップチャート、ヒストグラム、密度プロット、ボックスプロット、バイオリンプロットなどがあります。これらは、自由に利用できるソフトウェアで簡単に作成でき、12個程度の小さなグループでも、数千個もの大きなグループでも機能します。

2020年のXConfのためにオーストラリアへの旅行ができなかったため、代わりにオーストラリアのThoughtworksテクノロジーヘッドであるスコット・ショウ氏とズームで会話をしました。私たちは、現代のアプリケーション開発においてデータが果たす役割の変化、アプリケーション開発者とデータベース間の隔たり、ビッグデータ（そして乱雑なデータ）の出現による変化、データリテラシーの向上、そして投機的なデータを吸い上げることの社会への影響について話し合いました。

gotoカンファレンスから、サム・ニューマン氏の著書「モノリスからマイクロサービスへ」に関するインタビューを行うよう依頼されました。これは、マイクロサービスとそれを使用する時期に関する一般的な会話になりました。サム氏は、それらの主な理由として、独立したデプロイ可能性、データの分離、組織構造の反映を挙げています。私は最初の点については懐疑的ですが、データと人材はソフトウェア開発の複雑な部分であると考えています。

1953年のイランのクーデターに関するドキュメンタリー「クーデター53」の簡単なレビュー。

3年半使用したエルゴノミクスキーボードKinesis Advantage2の簡単なレビュー。

私たちのヨーロッパの「データウィッチ」であるEm Grasmederと私は、ヨーロッパでXConfシリーズの基調講演を行う予定でした。2020年であるため、代わりにズームで話し合い、データサイエンティストの役割、実際にどのような役割なのか、習得する必要があるツール、そして他のソフトウェア開発との関係について話し合いました。

この記事では、脅威モデリングを採用したいチームを支援するための明確で簡単な手順を示します。脅威モデリングは、安全なシステムを設計するためのリスクベースのアプローチです。これは、軽減策を開発するために脅威を特定することに基づいています。サイバーセキュリティリスクが増加し、企業がその責任をより認識するようになっているため、ソフトウェア開発チームはソフトウェアにセキュリティを組み込むための効果的な方法を必要としています。残念ながら、彼らは脅威モデリングを採用することに苦労することがよくあります。多くの方法論では、複雑で網羅的な事前分析が必要であり、現代のソフトウェアチームの働き方と一致しません。したがって、完璧な脅威モデルを作成するためにすべてを停止するのではなく、シンプルに始めてそこから成長することをお勧めします。

最新のソースコード管理システムは、ソースコードにブランチを簡単に作成できる強力なツールを提供します。しかし、最終的にはこれらのブランチをマージする必要があり、多くのチームが絡み合ったブランチの処理に膨大な時間を費やしています。チームがブランチを効果的に使用できるようにするいくつかのパターンがあり、複数の開発者の作業の統合と本番リリースへのパスの編成を中心に展開しています。全体的なテーマは、ブランチを頻繁に統合し、最小限の労力で本番環境にデプロイできる健全なメインラインに焦点を当てることです。

フィーチャーブランチは、開発者が新しいフィーチャーの作業を開始するときにブランチを開くソースコードブランチパターンです。彼女は、このブランチでフィーチャーに関するすべての作業を行い、フィーチャーが完成したときにチームの残りの部分と変更を統合します。

フィーチャーをダークローンチするということは、新しく変更されたバックエンドの動作を取得し、既存のユーザーから呼び出すことであり、ユーザーはそれが呼び出されていることに気付くことができません。これは、新しい機能の公開発表を行う前に、システムへの追加負荷とパフォーマンスへの影響を評価するために実行されます。

一部のプログラム要素は、本質的にテストが困難であるか、不可能です。これらの要素のロジックは、したがってバグが発生しやすく、進化させることが困難です。この問題を軽減するために、テストが困難な要素からできるだけ多くのロジックを移動し、コードベースの他のより扱いやすい部分に移します。テスト不可能なオブジェクトを謙虚にすることで、悪意のあるバグが潜んでいる可能性を減らすことができます。

ソフトウェア開発チームは、できるだけ頻繁に作業を統合すれば、生活がはるかに楽になることに気付きます。また、頻繁に本番環境にリリースすることも価値があると考えています。しかし、チームは、開発途中の機能をユーザーに公開したくありません。この緊張に対処するための便利なテクニックは、すべてのバックエンドコードを構築し、統合しますが、ユーザーインターフェースは構築しません。機能は統合してテストできますが、UIは最後に保留され、キーストーンのように追加されて機能が完成し、ユーザーに公開されます。

ドメイン駆動設計は、ドメインのプロセスとルールを深く理解したドメインモデルのプログラミングを中心としたソフトウェア開発のアプローチです。この名前は、このアプローチをパターンカタログを通じて説明するエリック・エバンスによる2003年の書籍に由来しています。それ以来、実践者のコミュニティがこのアイデアをさらに発展させ、さまざまな他の書籍やトレーニングコースを生み出しています。このアプローチは、多くの、しばしば混乱しやすいロジックを整理する必要がある複雑なドメインに特に適しています。

この記事では、実際のコードベースからのリファクタリングのセットについて説明します。これは完璧さを示すことを意図したものではありませんが、現実は表しています。

ペアプログラミングは、開発者が2人組で作業するソフトウェア開発プラクティスです。すべての重要なコードは、通常は1台のモニターで並んで座っている2人のプログラマーによって記述され、多くの場合、1つのキーボードを使用します。コードを追加するときに、各ステップを一緒に検討します。

良好な音声を取得し、ギャラリービューを使用し、話さない場合はミュートにし、猫を歓迎します。

Thoughtworksが新型コロナウイルス感染症2019（Covid-19）の発生に対処する方法に関する2番目の投稿

私たちと私たちの同僚は、しばしばクライアントのためにアーキテクチャ評価を実行するように依頼されます。これを行う場合、これらのシステムに関与するアーキテクトは、これらのシステムのパフォーマンス、障害に対する復元力、新しい機能を容易にサポートするように設計されている方法について説明します。ただし、めったに話題にならないのは、さまざまなシステムがビジネスバリューにどのように貢献するか、そしてこのバリューが他のアーキテクチャ属性とどのように相互作用するかです。

新型コロナウイルス感染症2019（COVID-19）の発生から得られた教訓

顧客企業がソフトウェア製品を購入する場合、通常はインストールのために熟練したスタッフが必要です。ソフトウェア製品ベンダーは独自のサービス部門を構築することがビジネスとして合理的ではないため、このスタッフは通常、サービスプロバイダー企業によって提供されます。顧客は、製品ベンダーとサービスプロバイダーの関係を認識し、協力する相手からその関係の透明性を求める必要があります。クラウドベンダーの台頭とともにこれらのパートナーシップがますます重要になるにつれて、この透明性はますます重要になっています。

ショッピングウェブサイトのソフトウェアを開発するチームを想像してみてください。チームのアウトプットを見ると、過去四半期に作成された新機能の数、またはページ読み込み時間の短縮などのクロスファンクショナルな指標を検討するかもしれません。しかし、アウトカム指標は、売上高の増加や製品に関するサポート問い合わせの減少を考慮します。アウトプットではなくアウトカムに焦点を当てることで、ソフトウェアのユーザーや顧客の有効性を向上させる機能の構築が促進されます。

理想的な状態では、プロダクトモード組織は、明確に表明されたニーズと表明されていないユーザーニーズに迅速に対応する、疎結合で自律的なチームで構成されています。しかし、時折、複数のチームを巻き込んだ対応が必要になる機会が生じます。効果的に管理されない場合、その結果、収益の損失、顧客の不満、チーム能力の無駄が生じます。これらの機会に対応する組織的取り組みを、プログラムと呼びます。この記事では、うまくいかなかったプログラムの例を通して、プロダクトモード組織におけるプログラムの管理に関する経験を共有します。

今日のソフトウェア開発に従事する多くの人がペアプログラミングの実践を耳にしているにもかかわらず、業界における普及率はまだばらつきがあります。その受け入れ方の違いの理由の1つは、そのメリットがすぐに明らかにならないことであり、中長期的に効果を発揮します。「2人が1台のコンピューターで作業する」だけではないため、不快に感じるとすぐに却下されてしまうこともあります。しかし、私たちの経験では、ペアプログラミングは協調的なチームワークと高品質なソフトウェアに不可欠です。