Scraps 最終更新 2026/10/01 23:40

#アーキテクチャ

@kkkkkou /

GoFデザインパターンを実務で使うものに絞って解説する — Adapter, Facade, Strategy, Observer など

  • 実務で頻繁に使うGoFデザインパターンをAdapter、Facade、Strategy、Observerなどに絞って解説
  • Adapterでインターフェース変換、Facadeでサブシステム簡略化、Strategyでアルゴリズム差し替え、Observerで状態変化通知を実装
  • パターン適用時は「本当に必要か？」を常に問い、条件分岐の置き換えや外部ライブラリ統合に有効な手法を紹介している。
GoFデザインパターンを実務で使うものに絞って解説する — Adapter, Facade, Strategy, Observer など - Qiita

@haru-qiita /

LangGraphが渡すのは、設計図

  • LangGraphは処理の設計図を提供し、エージェントの追跡・再開を可能にする
  • ノードで処理を、エッジで移動を、Stateで共有情報を表現する。失敗時の戻り場所を設計図に記録する
  • ノードの再実行時に二重の変更が起きない設計が必要で、最初の設計図は4〜5個のノードで十分である
LangGraphが渡すのは、設計図 - Qiita

@maskot1977 /

「誰が悪い」から「どう直す」へ ― 政策を改善し続ける政治の仕組み : システム設計視点の行動経済学 (22)

  • 政府の政策をデバッグする「5つの質問」フレームワークが公開された
  • リアルリソースのボトルネック、インセンティブ設計、ロールバックコストの削減が具体的に示された
  • 政策の評価基準を財源の帳尻から供給能力に変えることが重要である
「誰が悪い」から「どう直す」へ ― 政策を改善し続ける政治の仕組み : システム設計視点の行動経済学 (22) - Qiita

@OnuuuumaX /

「ハーネス」ってなんぞ？ Claudeに“性格”と“記憶”を持たせる仕組みを、おじさんでも分かるように調べてみた

  • ハーネスはAIが安定して良い仕事をし続けるための仕組み
  • ルール・スキル・フック・メモリ・フィードバックループの5要素で構成される
  • ルールだけでは不十分で、検証まで含めた仕組みが必要な点に注意するべき
「ハーネス」ってなんぞ？ Claudeに“性格”と“記憶”を持たせる仕組みを、おじさんでも分かるように調べてみた - Qiita

@mini-worker /

02. マイクロサービス間の一貫性を確保するための「タダ飯」はもう終った

  • マイクロサービス間の一貫性を確保するための手法としてSagaと2PCが議論された
  • Sagaはローカルコミットを段階的に実行し、補償処理でロールバックする。2PCは2段階でコミットを調整する
  • Sagaは一貫性を犠牲にした柔軟性を提供し、2PCは強い保証を提供するが両方とも設計時の判断が必要である
02. マイクロサービス間の一貫性を確保するための「タダ飯」はもう終った

@a_tochi /

【ADK2.0】実践② Google ADKで複数レビュアーを並列実行（Fan-out / Fan-in）

  • ADK2.0で複数レビュアーを並列実行するワークフローを構築した
  • Fan-out/Fan-inで複数ノードを並列実行し、JoinNodeで結果を集約し、ループで再レビューを実装
  • ループは特別な構文ではなくエッジ定義で表現できるが無限ループ対策は自分で考える必要がある
【ADK2.0】実践② Google ADKで複数レビュアーを並列実行（Fan-out / Fan-in） - Qiita

@ntaka329 /

引き継いだコードの「この案件だけの作法」を、git logから掘り起こしてレビュー観点にした話

  • git logからコードレビュー観点を自動生成し、固有のチェックリストを作成した
  • コミットメッセージで一次絞り込み、修正集中ファイル一覧、優先度3段階、壊れ方で章立て
  • 汎用と固有のチェックリストを分離し、過去の修正パターンを観点に反映する
引き継いだコードの「この案件だけの作法」を、git logから掘り起こしてレビュー観点にした話 - Qiita

@qwertyhoge /

読み取りと書き込みでモデルが別！？ - CQRS という概念

  • 読み取りと書き込みのモデルを分離するCQRSが提案されている
  • 書き込みモデルと読み取りモデルを別々に設計し、読み取りモデルは非正規化された形で保持する
  • 読み取りモデルの更新には遅延が生じるため、システムの整合性を考慮した処理方法を選択する必要がある
読み取りと書き込みでモデルが別！？ - CQRS という概念 - Qiita

@na9amura /

うちのチームが考えた最強の開発プロセスを紹介するよ

  • User Story単位の管理に限界を感じてEpicとMilestoneでレイヤー化した
  • Epicは複数User Storyをまたがる機能のまとめ、Milestoneはリリース単位の塊、Epic Discussionsで議論内容を分離
  • EpicとMilestoneの役割分担で課題が改善し、議論はEpic Discussionsに集約されることが実務に影響する
うちのチームが考えた最強の開発プロセスを紹介するよ

@Matsukura Yuki /

社内Agent Skillsの構築、運用、改善サイクル。半年運用して作り直したプラクティス 🧰

  • 社内エージェントスキルは配布することで初めて資産になる
  • スキルの名前変更は削除＋追加扱い、1スキル単位で完結させる、メタ情報で責任者を宣言
  • スキルの半分が0回利用されていることが判明し、責任者に確認が必要
社内Agent Skillsの構築、運用、改善サイクル。半年運用して作り直したプラクティス 🧰

@ktdatascience /

ベテランエンジニアのPRレビュー187件を分類してみたら、バグは5件に1件しか指摘されていなかった

  • ベテランエンジニアのPRレビュー187件を分類した結果、バグ指摘は全体の20%にとどまり、コードの整合性や意図の保存が主な指摘領域だった
  • 隣のコードと揃っているか（31件）、契約と意図は保存されているか（30件）、値そのものは正しいか（25件）が上位3領域、外部との境界や検証できるかは少数だった
  • レビューで見落としがちな領域は、コードの整合性や意図の保存、外部との境界など、差分の外を見ることで発見できることが多く、作業量の違いが実力差の要因だった
ベテランエンジニアのPRレビュー187件を分類してみたら、バグは5件に1件しか指摘されていなかった - Qiita

@1kazuki0 /

Rubyのミュータブルとイミュータブルが分からなかったのでわかりやすく

  • Rubyのミュータブルとイミュータブルの違いが分からなかった
  • 配列はミュータブルで中身を変更できる、整数はイミュータブルで変更できない
  • 変数はオブジェクトを指すメモであり、ミュータブルなオブジェクトは同じ本体を指す変数に影響する
Rubyのミュータブルとイミュータブルが分からなかったのでわかりやすく - Qiita

@yu_asa /

【初心者メモ】DB設計の正規化を第1〜第5正規形まで、注文テーブルで整理してみた

  • 注文テーブルを例に第1〜第5正規形までの正規化手順を説明している
  • 1NFは1セル1値、2NFは複合キーの部分依存除去、3NFはキー以外の依存除去、4NFは無関係な多対多の分離、5NFは結合従属の除去が主なポイント
  • 実務では3NFまでで十分な場合が多く、4NF・5NFは理論的な概念として理解しておくのが現実的である
【初心者メモ】DB設計の正規化を第1〜第5正規形まで、注文テーブルで整理してみた - Qiita

@mo__mo /

分散DBってなんだっけ、レプリケーション・シャーディング・分散SQLの解像度をあげたい人のメモ

  • レプリケーション・シャーディング・分散SQLが分散DBの主要な設計手法として紹介されている
  • レプリケーションはデータのコピーを複数場所に保つ、シャーディングはデータを分けて持つ、分散SQLは複数ノードにまたがるSQLを扱う
  • 分割キーの選定や、処理の振り分け、障害時のデータ整合性の判断が設計の重要ポイントとなる
分散DBってなんだっけ、レプリケーション・シャーディング・分散SQLの解像度をあげたい人のメモ - Qiita