市谷 聡啓が提唱した仮説キャンバスを使ってプロダクトの仮説を立てる方法を解説したブログ Blog

#Data Engineering AtlasをベースとしてマイグレーションDockerイメージを、GitHub Actionsでビルド＆パブリッシュ、Kubernetes Job上のArgo CDでのマイグレーションリリースまでを自動化する記事 https://tech-blog.rakus.co.jp/entry/20250526/dbmigration

State of AI-assisted Software Development DORAによる2025年のレポート。AI支援ソフトウェア開発に焦点を当てている AI採用率が90%に到達（前年比14%増） 80%以上が生産性向上を実感、一方で30%がAI生成コードへの信頼度が低い 90%の組織がプラットフォームを導入済み、高品質な内部プラットフォームがAI活用の鍵 新たにDORA AI Capabilities Modelと7つのチームアーキタイプを導入 https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report/ ブログ DevOps

Authors Seb Rose 風間 裕也 #Testing BDDのシナリオ記述におけるBRIEFの原則について紹介した記事 Keep your scenarios BRIEF | Cucumber 【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 - ブロッコリーのブログ

Authors Dan North, 和智 右桂 #Software Design BDDとドメイン駆動設計の関係を論じたブログ記事 Blog

#Software Design Martin FowlerによるDependency Injectionの概念を定義した記念碑的な記事（2004年1月23日公開） 背景 それまで軽量コンテナフレームワークは「Inversion of Control（IoC）」という用語で説明されていたが、Fowlerは「IoCはフレームワークの一般的な特性であり包括的すぎて混乱を招く」と指摘。IoC推進者との議論を経て、より具体的な「Dependency Injection」という用語を作成した 主な内容 DIの定義：別のオブジェクト（アセンブラ）が、クラスのフィールドに適切な実装を注入するアプローチ。サービス構成の責任と使用の責任を分離する 3つの実装パターン： Constructor Injection（コンストラクタ注入）：PicoContainerで採用。オブジェクト生成時に依存関係を明示 Setter Injection（セッター注入）：Spring Frameworkで採用。初期化後に依存関係を設定 Interface Injection（インターフェース注入）：Avalonで使用。注入用インターフェースを実装 影響 この記事により「Dependency Injection」という用語が確立され、以降のフレームワーク設計やソフトウェアアーキテクチャに大きな影響を与えた。Spring Frameworkも当初は「IoC」を使用していたが、後に「DI」という用語を採用 https://martinfowler.com/articles/injection.html 日本語訳：https://kakutani.com/trans/fowler/injection.html

マイクロサービス設計でサービスを増やしていく前に、満たしているべき条件をMartin Fowlerが論じたブログ Microservice Prerequisites DevOps

Robert C. Martin（Uncle Bob）が示したプログラマーが守るべき誓い Clean Coder Blog ブログ

Matt Wynneによる実例マッピングのアイディアが生まれたブログ、以下は風間 裕也による翻訳記事 https://nihonbuson.hatenadiary.jp/entry/ExampleMapping

技術的負債についてWard Cunningham本人が語った動画を和田 卓人が翻訳したブログ 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ

#Agile 吉羽 龍太郎によるスプリントレビューの進め方の解説 Blog ブログ

#LLM Claude CodeのPlugins機能が2025/10/10にパブリックベータとして公開されたブログ Claude Code Templates https://www.anthropic.com/news/claude-code-plugins

#Observability #Cloud Native OpenTelemetryのSpan Event API（Span.AddEvent、Span.RecordException）を非推奨とし、イベントをLogs APIベースに統一する方針 Span Eventsとログベースイベントの重複を解消し、「イベント = 名前付きログ」としてLogs APIで記録する 既存のSpan Eventデータは引き続き有効で、SDK互換レイヤーによりスパン上のイベント可視性も維持される https://opentelemetry.io/blog/2026/deprecating-span-events/ ブログ

2021年9月に公開された、entがLinux Foundationに参画した記事 https://entgo.io/ja/blog/2021/09/01/ent-joins-the-linux-foundation/

スポンサーシップについて論じているブログ https://larahogan.me/blog/what-sponsorship-looks-like/

#Security/Authentication ブルートフォース攻撃を防ぐための対策をまとめたOWASP Communityの記事 主な対策方法 アカウントロックアウト機能（DoS攻撃に悪用されるリスクに注意） Device Cookies（デバイスごとの認証ロック機構、DoS攻撃に対して耐性がある） パスワード検証時の遅延追加 IPアドレスベースのレートリミット CAPTCHAの導入 複数の秘密の質問による認証強化 単一の技術では回避されやすいため、複数の対策を組み合わせることが重要 https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

Author: Tanya Reilly Glue Workについて論じたブログ。コーディング以外の不可欠な仕事が昇進評価で軽視され、特に女性・少数派が引き受けがちでキャリアの罠になると指摘する 昇進制度は可視的な技術成果を評価し、関係性・組織的な労働を見落とす 対策: マネージャと昇進基準を会話する／Tech Lead 等の肩書きで正当化する／成果を可視化する／技術力も意図的に伸ばす（スタッフエンジニアの道 の IC パス） https://www.noidea.dog/glue/

#Team Organization Scaling Agile @ Spotifyの中で語られている組織設計で、Spotifyモデルとして知られている 自律的な職能横断型チームをスクワッドと呼び、スクワッドはトライブにまとめられる。 トライブ内の似た職能同士はチャプターという単位でプラクティスを共有する 日本語訳 ブログ

Will Larsonによる、スタッフエンジニアの文脈で、ミーティングへの参加方法・心得等について話されているブログ https://lethain.com/getting-in-the-room/

#Software Design マイクロサービスについてMartin Fowler,James Lewisが2014年に書いたブログ マイクロサービスの9つの特徴について説明している https://martinfowler.com/articles/microservices.html

#Software Design Martin Fowlerが2015年に書いたブログ 当時過熱していたマイクロサービス化ブームに警鐘を鳴らす形で、全てのケースにマイクロサービスが適するわけではない点が示された https://martinfowler.com/bliki/MicroservicePremium.html

#Software Design #Team Organization コンウェイの法則についてMartin Fowlerが書いたブログ 逆コンウェイ戦略やDDDとの関連についても触れている https://martinfowler.com/bliki/ConwaysLaw.html

#Agile 吉羽 龍太郎による、スクラム開発で行う技術的スパイクについての解説 https://www.ryuzee.com/contents/blog/7121 ブログ

#Documentation Write the Docsコミュニティの2025年7月ニュースレター アニメーションGIF: 自動再生を避け、操作可能な短い動画や静止画+再生ボタンを推奨 ドキュメント監査: 目標の明確化、多様なレビューチーム編成、品質チェックリストの整備 ドキュメンタリアンのためのアジャイル: スプリントサイクルとの連携 AI/LLMの活用: オリジナルコンテンツ作成には不向きだが、テンプレート生成・スタイルガイドレビュー・要約・反復編集に有効。有効な場面を明確にした戦略策定が重要 https://www.writethedocs.org/blog/newsletter-july-2025/ ブログ

#Security npmパッケージ@bitwarden/cli@2026.4.0がマルウェア混入により侵害されたサプライチェーン攻撃事例 多段ペイロード構成 Stage1: bw_setup.jsがBunランタイムをDL Stage2: 難読化された9.7MBのbw1.jsが認証情報を窃取 Stage3-4: audit[.]checkmarx.cxへ暗号化送信、GitHubへフォールバック 発火点: npm install時のpreinstallフック、およびbwコマンド実行時 窃取対象: SSH鍵 / GitHub PAT / npmトークン / クラウド資格情報 / ~/.claude.json等のAI設定 / .env 対策: 2026.4.1へ更新、資格情報ローテーション、npm ci --ignore-scripts、min-release-ageの設定 https://blog.flatt.tech/entry/bitwarden_compromise ブログ

Technical Debt Quadrant Martin Fowlerが技術的負債が発生するケースを4象限で分類したもの。 Reckless（無謀） or Prudent（慎重） Deliberate（意図的） or Inadvertent（不注意） の2軸で分類する。 例えばリリース当初はクリーンなコードを書いていたつもりだが、1年後に本来正しかった設計が見つかった。のようなケースではPrudentかつInadvertentとなる Blog ブログ

#Security GitHub Actionsの人気 action changed-files が侵害されたサプライチェーン攻撃事例 CVE-2025-30066 発覚: 2025-03-14 09:00 PT (16:00 UTC)、StepSecurity が Harden-Runner の挙動監視で検知 侵害手法: @tj-actions-bot の PAT が奪取（取得経路は不明） リポジトリ外で作成した malicious commit (0e58ed86...) に全タグを retroactively 付け替え（tag 移動による action 汚染の典型） ペイロード: Python script が /proc/[pid]/mem 経由で GitHub Actions runner プロセスのメモリから secrets を dump、log に double base64 で出力 影響: 23,000+ リポジトリ。compromise 窓は約 37 時間 (2025-03-14 16:00 UTC 〜 2025-03-15 22:00 UTC)。public repo の log は誰でも読めるため secrets 漏洩 復旧: 2025-03-15 22:00 UTC に GitHub がリポジトリを復旧、その後 v46.0.1 リリース 対処: step-security/changed-files@v45 等への切替、または SHA pin 化、漏洩可能性ある secrets を rotate https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised ブログ

#Team Organization 2013年にMatthew Skeltonによって書かれたブログ、Team Topologiesの根底にある考えがまとまったような内容になっている 訳: 吉羽 龍太郎 https://www.ryuzee.com/contents/blog/14567 DevOps

Robert C. Martinによるブログ 技術的負債は戦略的に適用されるものであり、ただのクリーンでないコードに対して用いる概念ではない。という主張 負債が増えるのを意図的に捉えテストやリファクタリングを拡充すべきとしている Clean Coder - A Mess is not a Technical Debt.

Four Keysの計測方法についてGoogle Cloudブログ上で説明されている 指標の計算方法を以下のように定義している デプロイの頻度 組織による正常な本番環境へのリリースの頻度。 変更のリードタイム commit から本番環境稼働までの所要時間 変更障害率 デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 組織が本番環境での障害から回復するのにかかる時間 日本語 英語 DevOps

#Testing Agile Testingにおけるアジャイルテストの4象限の源流となったブログ記事 http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2

#Agile アジャイルチームにおけるSwarmingについて述べたブログ Blog