Kush's Wiki

Sort by - linked count

• 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）による実践的なコーディング集
• 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/
• Cognition
  Microsoftと提携しているAI(LLM)企業 https://cognition.ai/
• Blog/

  Microservice Premium
  #Software Design Martin Fowlerが2015年に書いたブログ 当時過熱していたマイクロサービス化ブームに警鐘を鳴らす形で、全てのケースにマイクロサービスが適するわけではない点が示された https://martinfowler.com/bliki/MicroservicePremium.html
• Cloud Native Maturity Model
  CNMM #Cloud Nativeの成熟度に関して、各成熟度レベルをビジネスとテクノロジの双方で主要領域を定義するモデル モデルの取り組みは単なる技術的取り組みではなく以下の5つの主要領域の影響を受ける Business outcomes People Process Policy Technology FinOpsとも接続が強く、成熟初期はコストが増加するが成熟につれてコストを節約できる特徴について触れている。また、Platform Maturity Modelと連携しており、トップダウンとボトムアップの両方をカバーする 成熟度レベルは五段階で以下のようになっている Level 1 - Build Level 2 - Operate Level 3 - Scale Level 4 - Improve Level 5 - Adapt https://maturitymodel.cncf.io/
• テスト範囲
  #Testing ユニットテスト、インテグレーションテスト、E2Eテストのように、対象となる範囲でテストを分類する際に用いられる言葉
• Dynamoスタイル
  #Data Engineering DynamoDBによって流行したリーダーレスレプリケーションを実装したデータストアに用いられるスタイル名
• 合成監視
  Synthetic Monitoring #Observability レスポンス内容が予測可能なリクエストを事前に定義し、定期的にシステムに送信し応答を監視するもの
• 輻輳制御
  #Network TCPプロトコル等で行われるネットワークのリンク上でパケットが混線した際の制御 輻輳制御アルゴリズムは大きく以下の3つに分類される Loss-based Delay-based ハイブリッド型
• Bertrand Meyer
  
• SCIM
  System for Cross-domain Identity Management #Security/Authentication ユーザーアイデンティティ情報を異なるシステム間で自動的にプロビジョニング・管理するための標準プロトコル 主な機能は以下の通り ユーザープロビジョニング（新規アカウント作成） デプロビジョニング（アカウント削除） 属性同期（ユーザー情報の更新） グループ管理 RESTful APIベースで、IdPとSP（Service Provider）間のユーザー情報同期を効率化する https://scimcloud.com/ https://datatracker.ietf.org/doc/html/rfc7644