Kush's Wiki

Sort by - linked count

• Trivy
  #Security #Cloud Native #Continuous Integration コンテナイメージ、Kubernetes、IaC、リポジトリを対象とした包括的な脆弱性・設定ミス・シークレットスキャナー Aqua Securityによって開発されたオープンソースツール 主な機能: 脆弱性スキャン - コンテナイメージ、ファイルシステム、gitリポジトリ IaC設定ミス検出 - Dockerfile、Kubernetesマニフェスト、Terraformなど シークレット検出 - APIキー、パスワード等の機密情報 SBOM生成 - ソフトウェア部品表の作成と検出 ライセンススキャン DevSecOpsのシフトレフトセキュリティを実現し、CI/#Continuous Deliveryパイプラインに統合可能 SASTツールの一種として静的解析を実行する。--format sarif で SARIF 出力に対応し GitHub Code Scanning に取り込める https://trivy.dev/ https://github.com/aquasecurity/trivy
• RAG
  Retrieval-Augmented Generation 検索拡張生成 #LLM プロンプトエンジニアリングにおいて、LLMが学習済みータだけではなく、外部データベースから関連情報を検索し、回答を生成する技術
• Michael Nygard
  Home X 人物
• Ron Westrum
  人物
• Property-Based Testing
  #Testingにおいて、Known unknownsをKnown knownsにできるよう、プロパティとして指定されうる多数パターンを自動生成するようなテスト手法 ユニットテストを補完するような役割にできるとよい
• SECIモデル
  知識を暗黙知と形式知に分けそれらが学習サイクルに表れる過程をモデル化したもの 以下の4つのフェーズを繰り返す 共同化（Socialization） 暗黙知から暗黙知。組織として共通の経験を積み重ねる 表出化（Externalization） 暗黙知から形式知。経験的知識の共通点や抽象的な構造をモデル化する 連結化（Combination） 形式知から形式知。複数の形式知から知識体系を作る 内面化（Internalization） 形式知から暗黙知。形式知を実践的に理解できた状態
• Kubernetes/

  RoleBinding
  
• Kubernetes/

  StatefulSet
  
• Kubernetes/

  Taints and Tolerations
  kube-schedulerにおいて、Node affinityのようなPodに対する設定ではなくNodesに対する設定によってPodの配置を決定する Taints and Tolerations | Kubernetes Kubernetes
• Kubernetes/

  Headless Service
  Serviceの定義方法の一つ clusterIP .spec.clusterIP を "None" に指定することで、PodのIPを直接参照するような設定にしkube-proxyはServiceに関与しなくなる Service | Kubernetes Kubernetes
• Kubernetes/

  CronJob
  
• Kubernetes/

  Immutable Configuration
  Kubernetesの設定管理において、設定ファイルを隠蔽する専用のコンテナを用意し、Initコンテナと emptyDir を組み合わせることでアプリケーションコンテナに設定ファイルをロードさせるパターン ConfigMapと異なり、設定ファイルのコンテナイメージバージョン管理によってイミュータブルに扱うことができる
• Kubernetes/

  Topology Spread Constraint
  kube-schedulerにおいて、Inter-pod affinity and anti-affinityでは解決できないようなRolling Update時の不均等なPod配置を許容する Pod Topology Spread Constraints | Kubernetes Kubernetes
• Kubernetes/

  Downward API
  Podのメタデータを環境変数を通じてコンテナに渡すようなケースで利用できるAPI Downward API | Kubernetes Kubernetes
• Kubernetes/

  ClusterRoleBinding
  
• Kubernetes/

  Annotation
  Labelの利用がそぐわないケースで代替となるメタデータの指定方法、ツールやライブラリからパラメータのように利用されることを想定している Labelと異なりインデックスはされない Kubernetes
• Kubernetes/

  DNS
  #Network KubernetesにおけるDNS。PodとServiceをスケジューリングし、Service名によってURIを解決できる https://kubernetes.io/ja/docs/concepts/services-networking/dns-pod-service/
• Kubernetes/

  PodDisruptionBudget
  PDB 定常的に使用可能にしたいPod数を指定するような仕組み シングルトンなServiceを構築するようなケースで常に1台を使用可能にする、といった用途がある Disruption | Kubernetes Kubernetes
• CloudEvents
  #Cloud Native イベントデータのフォーマットを定義するベンダーニュートラルな仕様 CNCF graduated project。サービス、プラットフォーム、システム間でのイベントの相互運用性を提供する https://cloudevents.io/
• UML
  Unified Modeling Language #Documentation システムの設計を視覚的に表現するための統一的な記法
• ブルックスの法則
  #Team Organization 遅れているプロジェクトに人を足してもさらに遅れるだけという法則。人月の神話で語られている
• スクラム/

  インクリメント
  #Agile スクラムの成果物として、動作するプロダクトのこと
• スクラム/

  経験主義の三本柱
  スクラムが経験主義をベースにスクラムガイドで紹介している三本柱 透明性 検査 適応
• スクラム/

  5つの価値基準
  スクラムのスクラムガイドで紹介されている5つの価値基準 確約(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage)
• Sigstore
  #Security release file / container image / binary / SBOM 等の software artifact を署名・検証し、ソフトウェアサプライチェーンの安全性向上を目的とする OSS プロジェクト 鍵ではなく OIDC identity（email / service account / CI workflow 等）に署名を紐付ける identity-based / keyless 方式が核。長命な署名鍵なしに 署名検証 を成立させ、サプライチェーン攻撃 の由来検証軸を担う 署名は ephemeral key 生成 → Fulcio（CA）が identity に紐付く短命証明書を発行 → 署名イベントを Rekor（append-only な透明性ログ）に記録し、検証はログ経由で行う OpenSSF（Linux Foundation）が主導 https://docs.sigstore.dev/about/overview/
• Nix
  #Programming パッケージを「副作用のない関数の出力」として扱い、ビルド後は不変とする purely functional な package manager 各パッケージは /nix/store 配下に置かれ、パス名は build dependency graph 全体の暗号学的ハッシュで決まる（content-addressed） ビルドは deterministic（同じ式を 2 回ビルドすれば同じ結果になる） 上書きせず別パスに追加するため upgrade / rollback が atomic で、旧バージョンが残る 複数バージョンを同時に併存でき、依存衝突（"DLL hell"）を避けられる https://nix.dev/manual/nix/stable/introduction
• Kubernetes Network Policy Recipes
  Network policyの実装例をまとめたリポジトリ ahmetb/kubernetes-network-policy-recipes Kubernetes
• 3wayハンドシェイク
  #Network TCPプロトコルにおけるコネクションの確立手法、名前の通り3ステップでコネクションを確立する 送信元でTCPヘッダー内のSYN（コネクションの確立要求）フラグを有効化しセグメントを送信 送信先で1に対するACKとSYNフラグの有効化をしたセグメントを返信 送信元で2のSYNに対するACKのセグメントを送信
• JWKS
  JSON Web Key Set #Security/Authentication #Security/Cryptography JWTの署名検証に用いる公開鍵群をJSON形式で表現する仕様（RFC 7517）。各キーはkid（Key ID）・kty（鍵種別）・alg（署名アルゴリズム）などのフィールドを持ち、配列としてまとめられる JWT認証プロバイダーは/.well-known/jwks.jsonのようなエンドポイントで公開し、リライングパーティはJWTヘッダーのkidで該当キーを選択して署名を検証する。鍵ローテーションは新旧キーの並存で実現する RFC 7517 - JSON Web Key (JWK)
• ゴールレベル
  #Agile #Product Management Alistair Cockburnが提唱した、ゴール（目的）の大きさをレベル（高さ）で捉える考え方。高いレベルほど要約的で大きな目的を、低いレベルほど具体的な手順を表す。
• URN
  Uniform Resourde name URIのサブセットであり、 urn:スキームから開始する
• What Does Sponsorship Look Like?
  スポンサーシップについて論じているブログ https://larahogan.me/blog/what-sponsorship-looks-like/
• 不確実性のコーン
  ソフトウェアの見積もりは初期の段階ほどばらつきが大きくなるという考え
• Basic認証
  #Security/Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う
• Agile Conversation
  #Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。 自己開示: プロセスを隠さず失敗を認める 他者理解: 相手に関心を持ち立場を理解しようとする 組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果たす対話 重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。 アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
• Amazon/

  KMS
  Key Management Service #Security AWSが提供するKMS AWS Key Management Service
• サンクコストの誤謬
  プロジェクトや意思決定において、すでに投入しているリソースが高いと、成功数可能性が低い証拠があっても引き続きリソースを投入し続ける認知バイアス
• Beyond the Twelve-Factor App
  #Software Design #Cloud Native #Security/Authentication #Security/Authorization The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 #API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 #Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication / Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app
• 3つのC
  #Agile Ron Jeffriesが示した、ストーリーを構成する3つの要素。カード（Card）に書き、会話（Conversation）で詳細を詰め、確認（Confirmation）で完了条件を定める。カードは要求仕様書ではなく、会話を思い出すための覚書であることを示す。 https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
• Eff
  Extensible Effect #Programming 作って学ぶ Extensible Effects Freer monads, more extensible effects. Extensible Effects in Scala Scala + CleanArchitectureにEffを組み込んでみた アルプのEff独自エフェクト集 / Alp-original ’Eff’ pearls Eff（atnos-eff）による実践的なコーディング集
• safe-settings
  #Continuous Integration リポジトリ設定を policy-as-code で組織横断に宣言・適用する GitHub App（Probot ベース）。admin リポジトリに設定を集中管理し、各 repo の実設定を GitHub API 経由で宣言状態へ収束させる、repo 設定版の Infrastructure as Code。Platform Engineering の guardrails 実装の一つ 設定は admin repo の 3 階層（.github/settings.yml=org / suborgs/*.yml / repos/*.yml）で各 repo にマージ適用、優先度は repo > suborg > org full sync（CRON）で drift を検出・修正、PR では nop モードで dry-run 差分を提示 管理対象は GitHub API で扱う設定のみ（branch protection / labels / collaborators / teams / topics / custom properties / environments / rulesets 等）。ファイル内容は扱えず .github/workflows/*.yml の配布はできない（GitHub Actions の強制は ruleset / require workflows 経由） Organization 専用で個人アカウントでは動かない https://github.com/github/safe-settings
• Walking Skeleton
  #Agile #Product Management システムの端から端まで（end-to-end）を貫く、ごく小さな実装。最終的なアーキテクチャである必要はないが、主要なコンポーネントを結合して実際に動作するものを最初に作り、そこに肉付けして少しずつ成長させる。Alistair Cockburnが提唱した。
• llms.txt
  #Documentation WebサイトのコンテンツをLLMが効率的に利用するための提案標準。Jeremy Howard（Answer.AI）が2024年に提案 サイトルートにMarkdown形式で /llms.txt を配置しLLM向けの構造化された目次を提供する コンテキストウインドウの効率的な活用のためHTMLのノイズを排除する https://llmstxt.org/
• トレイト制約
  trait bound ある型があるトレイトの振る舞いを満たすかの制約をコンパイル時に定義する
• MADR
  Markdown Architectural Decision Records #Documentation ADRを記述するテンプレートカテゴリの一つ。マークダウンによって構造化された文書を提供する bare / minimal / full の3バリアントを持ち（現行 4.0.0）、決定の重さに応じて使い分けられる。共通の核は Context and Problem Statement / Considered Options / Decision Outcome で、full はこれに Decision Drivers / Pros and Cons of the Options / Confirmation 等を加える https://github.com/adr/madr/tree/develop/template About MADR | MADR
• スタッフエンジニアの道
  
• Principal Engineering Community Tenets
  Amazonのプリンシパルエンジニアグループによるコミュニティの信条 https://www.amazon.jobs/content/en/teams/principal-engineering/tenets
• The Laws of Identity
  #Security Kim Cameronが提唱したデジタルアイデンティティシステムの設計原則 アイデンティティメタシステムが満たすべき7つの法則： User Control and Consent（ユーザー制御と同意）: ユーザーがアイデンティティ情報の開示を制御できる Minimal Disclosure for a Constrained Use（最小限の開示）: 特定の目的に必要な最小限の情報のみを開示 Justifiable Parties（正当な当事者）: アイデンティティ情報は正当な目的を持つ当事者にのみ開示 Directed Identity（指向性アイデンティティ）: ユニバーサル識別子と方向性識別子の両方をサポート Pluralism of Operators and Technologies（多元性）: 複数のアイデンティティ技術とプロバイダーの共存 Human Integration（人間との統合）: ユーザーが理解し判断できるシステム設計 Consistent Experience Across Contexts（一貫した体験）: コンテキスト間で一貫したユーザー体験を提供 https://www.identityblog.com/?p=352
• オニオンアーキテクチャ
  
• スリーアミーゴス
  異なる視点を持つ3者が協調すること、開発者、テスター、プロダクトオーナーのような例が多い https://www.infoq.com/interviews/george-dinwiddie-three-amigos/