ドミニオン基本セットと陰謀の第2版があります。

私のキャリアの中で、関数はどれくらいの長さであるべきかについて多くの議論を聞いてきました。これは、より重要な質問、つまり「いつコードを独自の関数にカプセル化するべきか」に対する代理の質問です。「関数は画面に収まるサイズを超えてはならない」など、長さに関するガイドラインもありました。再利用に基づくものもありました。2回以上使用されるコードは独自の関数に入れるべきですが、1回だけ使用されるコードはインラインのままにしておくべきです。しかし、私にとって最も理にかなっているのは、意図と実装の分離です。コードの断片を見て何をしているのかを理解するために労力を費やす必要がある場合は、それを関数に抽出し、その「何」にちなんで関数を命名する必要があります。そうすれば、もう一度読むときに、関数の目的がすぐにわかります。そして、ほとんどの場合、関数がどのようにその目的を果たしているか（つまり、関数の本体）を気にする必要はありません。

時々、いくつかのデータを扱うとき、そのデータは私が期待するよりも正確です。精度が良いことは、結局のところ、より多くの精度が良いことなので、良いことだと思うかもしれません。しかし、隠れた精度は、いくつかの微妙なバグにつながる可能性があります。

スチームパンクのポケット宇宙での漫画と、コンピューティングのパイオニアとその実際のビクトリア朝の時代に関する有益な脚注の魅力的な組み合わせ。

プログラミングを行う際に、物事を複合体として表現すると便利なことがよくあります。2次元座標はx値とy値で構成されます。金額は数値と通貨で構成されます。日付範囲は開始日と終了日で構成され、それら自体が年、月、日で構成される場合があります。

これを行うと、2つの複合オブジェクトが同じかどうかという問題に遭遇します。両方とも（2,3）のデカルト座標を表す2つの点オブジェクトがある場合、それらを等しいと見なすのは理にかなっています。この場合、x座標とy座標など、プロパティの値によって等しいオブジェクトは、値オブジェクトと呼ばれます。

エイリアシングは、複数の参照を介して同じメモリ場所にアクセスするときに発生します。多くの場合、これは良いことですが、予期しない方法で発生することが多く、混乱を招くバグにつながります。

私は子供の頃、ニンジンが大嫌いで、その匂いと食感が嫌いでした。しかし、家を出て自分で料理を始めるようになってから、ニンジンが好きになり始めました。ニンジンについては何も変わっていませんし、私の味覚が根本的に変わったわけでもありません。違いは調理法にありました。私の母は、彼女の世代の多くのイギリス人と同じように、料理が得意ではありませんでした。特に野菜の料理が苦手でした。彼女のアプローチは、ニンジンを20分以上茹でることでした。その後、適切に調理すれば、ニンジンはまったく異なる体験になることを学びました。

これは料理に関するサイトではなく、ソフトウェア開発に関するサイトです。しかし、多くの場合、テクニックやツールは、かわいそうなニンジンに似ていることに気づきます。実際の問題は、テクニックが間違って行われていることなのに、ひどいものであると非難されています。

バイモーダルITは、ソフトウェアシステムを管理と制御のためにこれら2つの異なるカテゴリに分割する必要があるという誤った概念です。

• フロントオフィスシステム（エンゲージメントシステム）は、迅速な機能開発のために最適化される必要があります。これらのエンゲージメントシステムは、変化する顧客のニーズとビジネスチャンスに迅速に対応する必要があります。欠陥は、この迅速な開発サイクルに必要なコストとして許容されるべきです。
• バックオフィスシステム（記録システム）は、信頼性のために最適化される必要があります。記録システムとして、企業に損害を与える欠陥がないことが重要です。その結果、変化の速度が遅くなります。

サーバーレスアーキテクチャは、アプリケーション開発が通常のサーバープロセスを使用しないインターネットベースのシステムです。代わりに、サードパーティサービス、クライアント側のロジック、およびサービスホストのリモートプロシージャコール（FaaS）の組み合わせのみに依存しています。

YAaaS：Yet Another as a Service（もう1つのサービス）

最近では、すべてが「サービスとして」である必要があるように思われるため、この言語的傾向のメタ用語が必要です。同僚のBirgittaBöckelerに感謝します考えついてくれたことに。これで、「FaaSは「関数」のYAaaSです」などと言うことができます。

ビジネスケイパビリティ中心のチームとは、その作業がビジネスの特定の領域に長期的に連携しているチームです。チームは、前記のビジネスケイパビリティがビジネスに関連している限り存続します。これは、プロジェクトのスコープを提供するのにかかる時間だけ存続するプロジェクトチームとは対照的です。

重要なソフトウェア開発作業では、分析、ユーザーエクスペリエンスデザイン、開発、テストなど、いくつかの異なるアクティビティを実行する必要があります。アクティビティ指向のチームは、これらのアクティビティを中心に編成されているため、ユーザーエクスペリエンスデザイン、開発、テストなどの専任チームがあります。アクティビティ指向は多くの利点を約束しますが、ソフトウェア開発は通常、成果指向チームの方がうまくいきます。

ソフトウェアの開発を後援する人々は、通常、ベロシティや本番環境へのデプロイ頻度などの開発メトリクスにはあまり興味がありません。彼らは、ソフトウェアが提供するビジネス上の利点、つまり手作業の削減、販売コンバージョンの向上、顧客満足度の向上、つまりビジネスの成果をより重視しています。成果指向のチームとは、ビジネスの成果を提供することを義務付けられ、装備されているチームであり、そのようなチームには、成果を実現するために必要なすべてのアクティビティを実行できる能力を持つ人々がいます。対照的に、アクティビティ指向チームは、そうするための装備も義務もありません。彼らは、成果を実現するために必要な複数のアクティビティの1つだけを実行できます。

ビデオストアの請求書の計算とフォーマットの簡単な例は、1999年に私のリファクタリングブックを開きました。最新のJavaScriptで行うと、リファクタリングにはいくつかの方法があります。ここでは、トップレベル関数へのリファクタリング、ディスパッチャを使用したネストされた関数へのリファクタリング、クラスの使用、中間データ構造を使用した変換の4つについて説明します。

過去10年間で、アプリケーションの開発に合わせてデータベース設計を進化させることができる多くの手法を開発し、改良してきました。これは、アジャイル方法論にとって非常に重要な機能です。この手法は、データベース開発に継続的インテグレーションと自動リファクタリングを適用し、DBAとアプリケーション開発者の緊密な連携に依存しています。この手法は、本番前システムとリリース済みシステムの両方で、グリーンフィールドプロジェクトとレガシーシステムの両方で機能します。

社会的にぎこちない、白人、男性のプログラマーのステレオタイプは、長い間存在しています。「テクノロジーにおける多様性」は多く議論されているトピックですが、数字は改善されていません。それどころか、IT業界の内外問わず多くの人々が、このステレオタイプが自然な規範であることを当然のことと考えており、この認識は、職業をより包括的で魅力的なものにするための障害となっています。では、このイメージはどこから来たのでしょうか？世界のプログラマー人口の人口統計は、「男の子はコンピューターが好き」という理由だけで、本当に自然に進化したのでしょうか？プログラマーに対する私たちの認識を形作ったのは何でしょうか？このテキストは、コンピューティングの歴史について読んだときに私が発見したいくつかの可能な説明についてです。

Infrastructure as Codeとは、他のソフトウェアシステムと同様に扱うことができるソースコードを通じてコンピューティングおよびネットワークインフラストラクチャを定義するアプローチです。このようなコードは、監査と再現可能なビルドを可能にし、テストプラクティスと継続的デリバリーの完全な規律に従うために、ソース管理に保持できます。これは、過去10年間で成長しているクラウドコンピューティングプラットフォームに対処するために使用されてきたアプローチであり、今後、コンピューティングインフラストラクチャを処理するための主要な方法になります。

毎日のスタンドアップミーティングは、多くのチーム、特にアジャイルソフトウェア開発において、一般的な儀式となっています。ただし、効果的なスタンドアップと時間の無駄を区別する微妙な詳細がたくさんあります。