Rustでイテレータを作って色のグラデーションを表現してみた
- Rustでイテレータを実装して色のグラデーションを表現した
- RgbColor構造体に線形補間を適用し、Iteratorトレイトを実装してグラデーションを生成、chainとskipでフェードイン・フェードアウトを実現
- イテレータアダプタを使うことでメモリ効率よく複雑な処理を組み立てられる
#アーキテクチャ
新しいチェック観点を足す前に、既存設計書を整える。設計工程を42回やり直して測った話
- チェックリストの書き方と既存ドキュメントの整備が設計工程の漏れ検出に与える影響をA/Bテストで測定した
- 洗うべき層を並べて渡すことで難所検出率が4/6から6/6に、観点を手順に変えることで機械検索上限に達した
- 既存ドキュメントを渡すと誤検出が増えるが母集団を確定させる問いでは精度が向上した
【JavaScript】基礎から学ぶ！イベントハンドラ／リスナと主要イベント一覧
- JavaScriptでイベントハンドラとイベントリスナの違いが説明されている
- イベントハンドラはHTML属性やonclickで直接関数を紐付けるが、イベントリスナはaddEventListenerで複数処理を安全に登録できる
- アロー関数や無名関数を直接渡すと削除できないため、名前付き関数で定義する必要がある
AIに設計を任せるときに気をつけたい。「正しく動く」と「増えても耐えられる」は別だった
- Push通知の設計でDB問い合わせが1人あたり最大11回になる構造に気付いた
- 通知対象者ごとにDBアクセスが繰り返され、1,000人で11,000回になる
- 設計段階で100倍になった場合の問い合わせ回数を確認する必要がある
AIを組織化する — 40時間の連続稼働を支えた意思決定権限の設計
- Claude Codeのセッションを5つの役割に分けて意思決定権限を設計し、40時間連続稼働を実現した
- 要件判断、レビュー、ドキュメント、実装、動作確認の5つのセッションを分離し、誤りと未決を切り分け、判断を台帳に記録
- 要件判断担当に暫定判断を任せることで、人間の最終判断を待たずに作業を進められ、コード品質と要件定義の両立が可能になった
コンテキストエンジニアリング-学習記録
- コンテキストエンジニアリングでAIエージェントの実装ルールを事前に組み込み、レビュー時のトークン消費を抑える手法が紹介される
- 常設ルールとサブエージェントによる軽量スキャンの切り分け、プロジェクトルールファイルへのルール凝縮、静的解析ツールとの連携が実践例
- 機械的判定可能なルールはプロジェクトルールファイルに凝縮し、レビューでは文脈依存の観点に焦点を当てるべき
カバレッジ100%にこだわってきた結果、閾値の考え方が変わった話（理論編）
- テストカバレッジを100%にすることを基本方針として、コード構造やテスト設計を見直す
- ガード節や述語関数による分岐の簡略化、test.eachによるパラメータ化テスト、DIによる到達困難な分岐の対応
- カバレッジ100%は品質の保証ではなく、テストの網羅性を確保するための必要条件であり、ミューテーションテストとの併用が推奨される
明細の履歴テーブル設計に思いを馳せる
- 明細の変更履歴を保存する3つの方式を比較し、要件に応じた選択肢を提示した
- 方式1はバージョン付き履歴テーブル、方式2は画面スナップショットのJSON保存、方式3はスナップショット＋差分メタデータ管理
- 監査・ロールバックが必要な取引データには方式1が適切で、表示速度優先なら方式3が実用的
「デザインハーネス 2nd」にソフトバンクのUI/UXデザイナー窪内彩佳が登壇します！
- デザインハーネスがAIエージェントとデザイナーの協働プロセスを支える仕組みに
- デザインシステムと設計知識、検証、ワークフローを組み合わせ、AIがコンポーネントや評価基準を参照できる状態を構築
- デザイナーの専門知をチームやAIで共有するための三層デザインハーネスの実装状況が紹介される
AI-DLC v2を回してたら設計も実装も超過剰になってしまった
- AI-DLC v2の誤用で設計と実装が過剰になった
- ADR PDRを誤ってPRDとして渡したことで、AI-DLCがチェックリストとして機能し、詳細な検証方法まで記載されたドキュメントが生成された
- ドキュメントの読み間違いが原因で過剰な仕様書が作成され、リバースエンジニアリングが必要になった
燃やす埋める問題（最小カット問題）を総整理！ 前編 〜 なぜカットを「削除する辺の集合」とはしないのか 〜
- 最小カット問題とプロジェクト選択問題の解説が行われている
- カットの定義、プロジェクト選択問題のグラフ表現、辺の削除による解釈
- プロジェクト選択問題は最小カット問題に帰着できることを理解する
AI時代になっても大事な開発視点を振り返ってみる
- AI時代でもコードや仕様書の読む時間が書く時間より重要
- コードや仕様書は後で何人ものエンジニアが読み返すため、読む時間を短くする工夫が求められる
- チームや将来の自分への配慮を意識した設計が実務で重要になる
【2026年最新】「AIでアーキテクチャ選定はできないの？」生成AI時代におけるシステム設計の限界と人間（アーキテクト）の真の価値
- AIはアーキテクチャの初案作成はできるが、最終的な選定は人間が行う必要がある
- 一般構成パターンの提示と技術スタック比較、IaCの自動生成が可能、トレードオフの判断や文脈の理解はAIにできない
- AIは文脈や将来の事業戦略を考慮できないため、現場の制約やリスク評価は人間が行う必要がある
「10万円以上は部長承認」をどこに書くか。Goのドメインサービスと、使いすぎない線引き
- 「10万円以上は部長承認」のルールをドメインサービスに配置する方法が説明されている
- ドメインサービスは申請の金額と組織図の知識をまたぐための独立関数、値オブジェクトで金額を表現
- ドメインサービスはモデルの責務に合わないルールを置くための最終手段で、モデル貧血症を防ぐための条件が示されている
Go公式が推奨するモジュール構成とSOLID原則で考える、シンプルで拡張性の高いパッケージ構成
- Go公式が推奨するモジュール構成は機能単位での垂直分割で、SOLID原則に沿った設計を採用
- 機能ごとにディレクトリを分けることで、技術的関心によるレイヤー構造ではなく、役割ごとのファイル名で整理する。インターフェースは使う側が定義する
- 技術的な分割は構造体とメソッドで行い、インターフェースは使う側が定義することで、具象側の依存を減らせる。
「いい感じに分けといて」と頼まれたので、「いい感じ」を定義してみた
- 「いい感じに分けて」という曖昧な要望をハード制約とソフト制約に分けて定義した
- ハード制約はグループサイズの構成、ソフト制約は過去のペア回避と事業部の偏りをペナルティで表現
- ペナルティの比で優先順位を調整し、山登り法で局所最適解を求める手法が実用的
数千語 × 100問の用語マッチを Aho-Corasick 法で「用語数に依存しない」速さにした話
- 数千語の用語マッチをAho-Corasick法で用語数に依存しない速さにした
- Trie木に用語をまとめてfailureリンクで読み直しをなくし、テキストを1回なめるだけで検出
- 用語数が増えるほど総当たりより効率が良くなるため、大規模な用語検索に適している
AI実装の速さにコードレビューが追いつくための、「コードの外側」をつなぐ技術
- AI実装の速さにコードレビューが追いつくための、変更後の世界と意思決定の来歴を結線するReview Modelを提案
- 変更後の世界・今回PRの実装範囲・意思決定の来歴・保証と証拠をつなぐ、AI Responsibility Review Model Skillを実装
- 実装前の責務や契約が曖昧だとReview Modelだけでは判断できないため、事前に明確な契約を設定する必要がある。
Spannerのback joinを読み解く
- Spannerのback joinはindexにない列を取得するためにベーステーブルへ引き直す動作で、応答時間に影響する
- indexスキャン後にベーステーブルを引き直すDistributed Cross Applyと、STORINGでindexを広げる方法が主な対処法
- back joinの回数を減らすにはindexのキー列に条件やソート列を含め、LIMITの後に移すことでコストを抑えるのが効果的
CursorのSkillsを試してみた！
- CursorのSkillsでコードレビューのスキルを構築した
- Skillsは4つのファイルで構成され、設計原則とコーディング基準を定義
- 設計原則の優先順位としてKISSが最も重要で、DRY/OAOOは後回しにされる
