テーマ： architecture
-
パイプライン、ファンアウト、オーケストレーター、批評パネル: タスクに合うマルチエージェントパターンの選び方
パイプラインは変換の順序が決まっているタスクに向く。並列ファンアウトは独立した副質問や、多数決を取るための繰り返し試行に向く。ワーカーを従えたオーケストレーターは、分解の仕方が実行時にしか分からないタスクに向く。批評パネルは複数の基準に照らしてレビューが必要な出力に向く。いずれの方式もトークンコストを増やし、それ自体が失敗しうる調整レイヤーを追加する。
-
技術的な意思決定のためのDACIとRACI: 承認者は1人、貢献者は名指しで
DACIは、意思決定を進行させるドライバー、決定を下すただ1人の承認者、発言権はあるが投票権のない貢献者、結果を知らされる関係者を指名する。RACIは、実行責任者・説明責任者・相談先・報告先という役割をタスクごとに割り当てる。どちらの方式も、議論を始める前に役割を書き出しておけば技術的な意思決定に使える。
-
.NETの依存性注入の慣習: ライフタイム、スコープ、captive dependencyの罠
Microsoft.Extensions.DependencyInjectionは、`IServiceCollection`上にtransient・scoped・singletonのいずれかのライフタイムでサービスを登録し、公開コンストラクタを通じてそれらを注入する。文書化されたルールは、scopedなサービスをsingletonに注入しないこと、コンテナが生成したものはコンテナ自身に破棄させること、サービスロケーター的な呼び出しを避けること、そしてcaptive dependencyがリクエストをまたいで状態を漏らすのではなく起動時に失敗するようスコープの検証を行うことである。
-
Event sourcing and CQRS: what they buy and what they cost
Event sourcing stores every state change as an immutable event and derives current state by replay; CQRS separates the write model from read models. Both add auditability and flexibility at the price of complexity and eventual consistency.
-
新しいサービスにGoとRustのどちらを選ぶか：ベンチマークなしの判断手順
ベンチマークの俗説ではなく、文書化された言語の性質とチームの制約からGoかRustを選びます。メモリー管理モデル、エラーと並行処理のスタイル、負荷の形、必要な連携ライブラリ、そして2年後に誰が保守するかを見ます。
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
判断モデルでツールやスキルを選ぶ：Choiceで順位付けし、Noulで選択を見送る
候補ツールに対するChoiceは「どの候補が最も合うか」という相対的な問いに答え、候補ごとのNoulは「このターンにそもそもツールが必要か」という絶対的な問いに答えます。TypeSafeのスキル提案クックブックは182スキルのカタログで両方を使い、1回目で全件を順位付けし、2回目で上位3件を読み、すべてを却下することもできます。
-
File upload service walk-through: direct-to-storage tickets, asynchronous scanning and quotas
A design walk-through for uploads that bypass the application servers: a ticket that reserves quota and returns a signed upload URL, a completion step that verifies the stored object, a scan worker that promotes or deletes it, lifecycle rules for abandoned uploads, and a status model that explains every stored object.
-
Notification service walk-through: channels, preferences, delivery attempts and retries
A design walk-through for a multi-channel notification service: an ingest API with an idempotency key, a router that expands one notification into per-channel deliveries after checking preferences, per-channel queues and retry schedules, callback handling for invalid tokens, and what to defer.
-
PostgreSQLで派生データを保存する：生成列とマテリアライズドビュー
生成列はその行だけから各行の値を1つ導き、仮想型（読み取り時に計算）か保存型（書き込み時に計算）で、不変な式だけを使えます。マテリアライズドビューは任意のクエリ結果を保存し、鮮度は最後のREFRESHまでです。索引を付けたい行ごとの正規化には保存型生成列、遅延を許せる高コストの集計にはマテリアライズドビュー、どちらも合わない場合には維持更新する集計表を使います。
-
エージェントの記憶を設計する：保存、要約、忘却の使い分け
エージェントの記憶には、コンテキストウィンドウ、タスク用メモ、セッションをまたぐ永続ストアの三層がある。項目ごとに属する層を決め、永続記憶は小さくレビュー可能に保ち、事実でなくなったものを削除する。
-
Server-Sent Events と WebSocket の比較
Server-Sent Events は通常の HTTP でサーバーからクライアントへテキストイベントを配信し、自動再接続と最終イベントIDを扱う。WebSocket は独自のプロトコルでバイナリにも対応する双方向チャネルを提供する。一方向の更新には SSE、クライアントが頻繁に送信する場合には WebSocket を選ぶ。
-
Abstaining as an agent: when not acting is the correct output
An agent's output space should include a deliberate 'not decided' for every automated action: what abstention is, why a classifier or agent without one converts every unclear case into a wrong action, and how to build abstention in through explicit options, floors on confidence, stakes-dependent thresholds and a route for what was abstained from.
-
When does client-side routing still pay off now that browsers offer bfcache, prerendering and cross-document view transitions?
Open question: in-page routers were adopted to avoid full page loads, at the cost of shell serving, 404 handling, scroll and focus restoration and a bundle that must arrive first; the back/forward cache, the Speculation Rules API and cross-document view transitions now address the original motivations in multi-page sites. For which sites and interaction patterns does an in-page router still measurably win?
-
At what repository size do teams need monorepo build tooling beyond plain Git?
Open question: sparse checkout, partial clone and per-directory CI filters cover the first stage of a growing single repository; at which size, team count or build time have teams found that a build graph tool with remote caching became necessary, and what did the transition cost?
-
Pythonの処理にスレッド、プロセス、asyncioのどれを選ぶか
まず頻繁に通る処理経路を分類します。I/O待ちにはasyncio（多数の接続、非同期ライブラリ）かスレッドプール（少数のブロッキング呼び出し）が向きます。純粋なPythonのCPU処理にはプロセスかフリースレッドビルドが必要で、GILを解放するネイティブコードにはスレッドを使えます。各プールに上限を設け、プロセスの起動方式を明示し、終了処理を書きます。
-
URL shortener walk-through: key generation, redirect status and abuse controls
A design walk-through for a URL shortener: random base62 keys with collision retry, a redirect path that touches one cache and one store, 302 rather than 301 when targets must stay revocable and countable, creation-side abuse checks, and a list of what not to build first.
-
アーキテクチャの意思決定記録
アーキテクチャの意思決定記録は、一つの重要な判断について、その背景、決定自体、状態、結果を、コードとともに保存する短いファイルにまとめるものである。
-
Caching in Anwendungen: Ablaufzeiten, Invalidierung und Schutz vor dem Ansturm
Ein Anwendungs-Cache hält abgeleitete Daten und darf jederzeit verloren gehen; korrekt bleibt er nur durch bewusste Invalidierung: Ablaufzeit je Datenklasse, Löschen statt Überschreiben beim Schreiben, Versionskennung im Schlüssel und eine Sperre gegen gleichzeitiges Nachladen heisser Schlüssel.
-
ETL versus ELT: where the transformation runs and what that changes
ETL transforms data in a separate engine before loading it into the target; ELT loads raw data first and transforms it with the target store's own processing. The choice decides where compute is paid for, what raw data lands in the warehouse, and how easily a transformation can be rerun.
機械可読： JSON