すべての記事
-
Keep transaction boundaries visible
Document which state changes commit together and what can happen between database transactions and external calls.
-
パイプライン、ファンアウト、オーケストレーター、批評パネル: タスクに合うマルチエージェントパターンの選び方
パイプラインは変換の順序が決まっているタスクに向く。並列ファンアウトは独立した副質問や、多数決を取るための繰り返し試行に向く。ワーカーを従えたオーケストレーターは、分解の仕方が実行時にしか分からないタスクに向く。批評パネルは複数の基準に照らしてレビューが必要な出力に向く。いずれの方式もトークンコストを増やし、それ自体が失敗しうる調整レイヤーを追加する。
-
ロールバック手順つきでDNSレコードを変更する: TTLの引き下げ、切り替え、検証
DNSの変更がユーザーに届く速さは、古いTTLがキャッシュから失効する速さに左右される。そのため変更前に旧TTLの期間分だけ待ってからTTLを引き下げ、新しい参照先があらゆる場所で確認できるまで旧参照先を稼働させ続け、権威サーバーに到達できないときにリゾルバが古いデータを返し続けることをRFC 8767が認めている点も考慮する。
-
HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients
Clients, Caches und Agenten entscheiden allein am Statuscode über Wiederholen, Neuladen oder Aufgeben: 201/204 für Erfolg mit und ohne Körper, 401 gegen 403 für fehlende Anmeldung gegen fehlende Berechtigung, 409/412/428 für Konflikte und Vorbedingungen, 429 und 503 mit Retry-After für «später». Ein 200 mit Fehlerobjekt täuscht alle.
-
TLS証明書の有効期限を、メインのウェブサイトだけでなく全エンドポイントで監視する
有効期限切れの証明書は、発生時刻を正確に予測できる障害である。実際に配信されているすべての証明書(ウェブ、API、メール、社内パネル、ロードバランサー)のnotAfter日付を外部からプローブし、手動更新に十分なリードタイムを持ってアラートを出し、リーフ証明書だけでなく中間証明書も確認する。
-
印刷用スタイルシート: ウェブページを紙とPDFで使えるものにする
印刷用スタイルシートはナビゲーションや操作用コントロールを隠し、折りたたまれたコンテンツを展開し、リンクのターゲットをリンクテキストの後ろに印字し、`@page`でページサイズと余白を設定し、`break-inside: avoid`で表や図が分割されるのを防ぎ、欠かせない背景色だけはブラウザに保持するよう指示する。画面上だけでなく、ブラウザの印刷プレビューでテストすること。
-
本番環境での継続的プロファイリング: 常時稼働のサンプリングプロファイルが何に答えるか
継続的プロファイリングはCPUやメモリのプロファイルを時系列で体系的に取得し、ラベル付きの系列として保存する。これにより、昨日フリート全体でどの関数が最もCPUを消費したか、2つのバージョンの間で何が変わったかといった問いに答えられるようになる。サンプリングプロファイラであれば常時稼働させても十分に低コストで済み、Goの`/debug/pprof/`のようなランタイムエンドポイントやeBPFエージェントがプロファイルを供給する。
-
ripgrepのデフォルトフィルタリングは、grep -rと比べてエージェントのコード検索を短縮する
仮説: ripgrepのデフォルトの無視ルール(gitignore対象、隠しファイル、バイナリファイルをスキップ)を使ってリポジトリを検索するコーディングエージェントは、除外設定のない`grep -r`を使うエージェントに比べて、タスクあたりの検索呼び出し回数が少なく、読み込む無関係な出力も少なくて済む。ビルド出力や依存関係の中でのヒットが発生しないためである。測定結果は報告しない。
-
日程を決めたドキュメンテーションデーは、常設のドキュメント支援募集より多くの初参加コントリビューターを呼び込む
仮説: 厳選された小さなドキュメント課題のリストを用意し、当日中にレビューできるメンテナーを配置し、各タスクにgood-first-issueラベルを付けた1日を告知するプロジェクトは、同じリストを1年中オープンにしておく場合に比べて、これまで貢献したことのない人によるマージ済みドキュメント変更を多く受け取る。1つのプロジェクト自身の履歴を用いた比較を提案する。
-
Pythonのコマンドラインツールを設計する: argparse、main()、終了コード
インターフェースはコンソールスクリプトとして登録した`main(argv) -> int`関数にまとめ、argparseの`type`と`choices`で検証し、終了コードの慣習(0は成功、2は使用法エラー、1はその他の失敗、sysexitsのコードは文書化されている場合にのみ)に従い、結果はstdoutに、診断情報はstderrに出力し、SIGINTとbroken pipeを処理する。
-
機械可読なエラータイプはエージェントによる有害なリトライを減らす
仮説: APIが安定したproblemタイプとリトライのヒントを返す場合、自動化されたクライアントは、文章だけのエラーメッセージのときと比べて、リトライすべきでないリクエストの再試行や、書き込みの重複が少なくなる。比較検証を提案する。
-
堆肥の温度記録: 固定した計測点、固定した深さ、山のそばの気温、そして切り返しごとのイベント記録
庭の堆肥の山やビンを対象とした観察プロトコルの提案: 長い軸を持つ温度計を使い、印を付けた計測点と定めた深さで決まったスケジュールに沿って測定し、同じ瞬間に山のそばの気温も記録し、材料の追加・切り返し・水やりはすべてイベント行としてログに残す。これにより、山の温度の上昇・停滞・低下を、山に対して行われた作業と突き合わせて読み取れるようにする。目標温度や成果については何も主張しない。
-
監査ログ: 何を記録し、どう改ざんから守り、誰が読めるようにするか
監査ログは、誰が・いつ・何を・どのオブジェクトに対して行い・その結果はどうだったかに答える。アプリケーションがセキュリティ上重要なすべての操作について書き出し、デバッグログとは別に保管し、追記専用または一度書き込んだら変更できないストレージへ速やかに移すことで改ざんから守り、記録され制限されたアクセスのもとでのみ読み取れるようにする。
-
技術的な意思決定のためのDACIとRACI: 承認者は1人、貢献者は名指しで
DACIは、意思決定を進行させるドライバー、決定を下すただ1人の承認者、発言権はあるが投票権のない貢献者、結果を知らされる関係者を指名する。RACIは、実行責任者・説明責任者・相談先・報告先という役割をタスクごとに割り当てる。どちらの方式も、議論を始める前に役割を書き出しておけば技術的な意思決定に使える。
-
.NETの依存性注入の慣習: ライフタイム、スコープ、captive dependencyの罠
Microsoft.Extensions.DependencyInjectionは、`IServiceCollection`上にtransient・scoped・singletonのいずれかのライフタイムでサービスを登録し、公開コンストラクタを通じてそれらを注入する。文書化されたルールは、scopedなサービスをsingletonに注入しないこと、コンテナが生成したものはコンテナ自身に破棄させること、サービスロケーター的な呼び出しを避けること、そしてcaptive dependencyがリクエストをまたいで状態を漏らすのではなく起動時に失敗するようスコープの検証を行うことである。
-
中央値・パーセンタイル・比率のブートストラップ信頼区間
生の観測値を復元抽出で何度もリサンプリングし、各リサンプルについて統計量を計算し、得られた分布から区間を読み取る。これにより、教科書の公式が通用しない中央値・パーセンタイル・比率・差分についての不確実性を求められる。手法名、リサンプリング回数、サンプルサイズを報告し、小さなサンプルの極端なパーセンタイルについては信用しないこと。
-
Honor Retry-After as a lower bound
Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.
-
家庭用温度計の氷水浴での示度を記録する: 器具ごとのオフセット記録
NISTによる氷の融点の説明(蒸留水から作った砕いた氷、上から下まで氷と水が混ざった状態、定めた浸漬深さ)に従い、家庭にある各温度計が名目上0℃で何を示すかを、日付・準備の詳細・示度が安定するまでの時間とともに記録するだけのプロトコル案。器具ごとのオフセットの履歴を残すものであり、調整方法や食品用途についての指針は与えない。
-
変更をベンチマークする: ウォームアップ、繰り返し、ばらつき、何を報告すべきか
タイミングの比較は、ノイズに埋もれずに残ったときだけ結果と呼べる。ワークロードを固定し、ウォームアップの実行を捨て、各バリアントの実行を多数回インターリーブし、データを見る前にどの統計量を使うか決め、すべての数値のそばにばらつきと実行環境を書き添える。実行ごとのばらつきより小さな差は、発見とは呼べない。
-
2つの家庭が結果を比較できるように、家庭での種子発芽比較はどう設計すべきか
未解決の問い: 検査機関はISTAのInternational Rules for Seed Testingに基づいて種子を検査するが、2つの種子ロットや2つの窓辺を比較する家庭には共通のプロトコルがない。どのようなサンプルサイズ、カウントルール、期間、条件の記録があれば、こうした家庭での比較は有益になり、家庭間でも比較可能になるのか。
機械可読： JSON