Kush's Wiki

Sort by - linked count

• サービスディスカバリ
  アプリケーションサービスを公開する際、クラウドネイティブなコンテナアプリケーションをステートレスに扱うようなケースで、アプリケーションの場所（IPアドレス）を容易に提供するためのパターン
• Progressive Delivery
  バージョンアップデートを段階的に行うようなデプロイメント戦略を適用した上で、デプロイ結果を分析し漸進的にデプロイの継続かまたはロールバックかを自動化するようなデリバリ手法 Continuous Deliveryの進化系として紹介されることが多い https://argo-rollouts.readthedocs.io/en/stable/concepts/#progressive-delivery
• BDD/

  定式化
  Formulation #Testing #BDD #Documentation システムの振る舞いの具体例をメンバーが読みやすいシナリオの形で文書化する
• Gherkin
  #Testing #Documentation 以下のフォーマットでテストシナリオを記述する記法 Scenario: Breaker joins a game Given the Maker has started a game with the word "silky" When the Breaker joins the Maker's game Then the Breaker must guess a word with 5 characters https://cucumber.io/docs/gherkin/reference
• UDP
  User Datagram Protocol #Network L4にあたる通信プロトコル エンドデバイス間でコネクションを確立せず遅延の最小化を優先させる メッセージのロスが許容される動画配信等に用いられる
• Kubernetes/

  Initコンテナ
  #Kubernetes #Cloud Native Podと一緒に定義可能な初期化を行うコンテナ サイドカーでも同挙動は実現可能だが、ただ一度のみ実行されるのでリソースを調整しやすい Initコンテナ Init Containers | Kubernetes
• Kubernetes/

  ServiceAccount
  
• Kubernetes/

  Gateway API
  #API Architecture #Network #Kubernetes #Cloud Native L4/L7を扱うKubernetes公式のAPIゲートウェイ GatewayClass Gateway HTTPRoute の3つを定義し実装する GatewayClassはGKEのようなクラウドサービスが用意するケースがあり、外部or内部を選択できる Introduction - Kubernetes Gateway API
• Kubernetes/

  Network policy
  
• Kubernetes/

  Namespace
  #Kubernetes 1つのクラスタ内に存在するリソース群を名前空間として分離することができる機能 Deployment,Serviceなどは名前空間内に配置できるが、PersistentVolumeなどはクラスタ全体に適用されるため名前空間内に配置できない Namespaces | Kubernetes
• Kubernetes/

  ConfigMap
  
• Kubernetes/

  Role
  
• Kubernetes/

  Label
  #Kubernetes リソースのメタデータとしてリソースを特定するために用いられる Labelにはインデックスが貼られるため高速な検索が可能
• Kubernetes/

  PersistentVolume
  
• Base64
  元の文字列から英数字のみの結果を出力するエンコード方式 例としてJSONで用いられる波括弧やダブルクォーテーション等の特殊文字を適切に扱えるよう、英数字のみの値に変換する RFC 4648 - The Base16, Base32, and Base64 Data Encodings
• CLI
  Command Line Interface
• WIP制限
  #Agile 仕掛り作業の件数を制限し、同時に複数の仕事に着手しないという考え
• 松浦 隼人
  
• ADR
  Architectural Decision Records #Documentation アーキテクチャに関する意思決定とその理由を記録する文書。意思決定に際する文脈、根拠、その決定による成果物等を記述する ADRはなぜそのアーキテクチャを選出したかの意思決定を理解するのを助ける。 ADRはチームメンバーの誰もが作成できる。ただしオーナーシップとしてAuthorは明確にする必要がある。初期ステータスは Proposed とする。 次に他チームメンバーによるレビューを行う。修正すべき点がある場合は Proposed のままアクションのアサインを行う。このときアサインはチームメンバーの誰でもよい。ADR自体はRejectする場合はステータスを Rejected にしADRのライフサイクルは終了する。 レビューを経て全てのアクションが完了した場合、ステータスを Accepted にする。一度AcceptされたADRはイミュータブルに扱い変更はしない。 Architectural Decision Records (ADRs) ADR process - AWS Prescriptive Guidance
• DevOps capabilities/

  Trunk-based development
  #Continuous Integration DevOps capabilitiesの1つ、Fast Flowに分類される Working in small batchesをベースに少なくとも1日に一回はトランクブランチにマージをする テストの自動化も重要な要素となる DORA | Capabilities: Trunk-based Development
• DevOps capabilities/

  Working in small batches
  #Continuous Integration DevOps capabilitiesの1つ、Fast Flowに分類される 価値提供フローの可視化、チームによる実験、顧客フィードバックの可視化と組み合わせることで高いソフトウェアデリバリパフォーマンスに寄与する バッチサイズの最小化にはINVESTの原則を用いると良い DORA | Capabilities: Working in small batches
• DevOps capabilities/

  Test automation
  #Testing DevOps capabilitiesの1つ、Fast Feedbackに分類される https://dora.dev/capabilities/test-automation/ ユニットテスト/TDD 受け入れテスト Agile testing directions: tests and examples Loosely coupled teams テストピラミッド
• DevOps capabilities/

  Team experimentation
  DevOps capabilitiesの1つ、Climate for Learningに分類される DORA | Capabilities: Team experimentation
• プロダクトバックログ
  #Agile プロダクトに必要とされるもののリスト、優先度順に並べる
• Linux Foundation
  Linuxのようなオープンソースソフトウェアやテクノロジーを支援、促進、保護、標準化するコミュニティ https://www.linuxfoundation.org/
• ヘキサゴナルアーキテクチャ
  
• アジャイルテストの4象限
  
• VS Code
  Visual Studio Code #Programming Microsoftが開発しているオープンソースのIDE
• Four Keys
  DORAによって提唱されるソフトウェアデリバリのパフォーマンス指標 名前の通り4つの尺度を追跡する デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 State of DevOps Reportでは、以上の4つの尺度を用いて、 Elite High Medium Low の4つに分類した ハイパフォーマーは全ての尺度での計測結果が抜きん出ており、スピードと品質にトレードオフ関係がないことを指し示した https://github.com/dora-team/fourkeys?tab=readme-ov-file
• OIDC
  
• Anthropic
  LLMに関する事業を行うAI企業
• スプリントレビュー
  #スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。 検査、適応を行うためのイベント
• スプリントプランニング
  #スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
• OWASP
  
• リーダーレスレプリケーション
  #Data Store AmazonがDynamoシステムで利用し流行しDynamoスタイルと呼ばれる。 一部のノードが何らかの理由で利用できなくてもクオラムによって読み取りあるいは書き込みの正当性を判断する
• イネイブリングチーム
  #Team Organization チームトポロジーにて紹介される4つのチームタイプの内の1つ 他のチームを技術等の知識によって支援する
• Seb Rose
  
• Tom DeMarco
  #Person
• eBPF
  extended Berkeley Packet Filter Linuxカーネル上で拡張プログラムを安全に実行できるLinuxの技術 OSカーネルは安定性・セキュリティの高い要件が求められるがゆえに進化のスピードが遅い課題があるがそれを解消し、Linux Foundationの下でeBPF Foundationとして開発が進められている HTML（Linuxカーネル）とJavaScript（eBPF）の関係性に例えられることが多い Home – eBPF
• 脅威モデリング
  #Security Threat Modeling アプリケーションに影響を与える脅威、攻撃、脆弱性、対策を特定する技術 モデリング手法として5つのステップを繰り返すよう紹介している Defining security requirements. Creating an application diagram. Identifying threats. Mitigating threats. Validating that threats have been mitigated. https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling
• KMS
  Key Management System #Security 暗号化キーのディスカバリ、保存を行う管理システム。暗号化はKMS外で行う前提
• Devin
  #LLM Cognition社によるソフトウェアエンジニアを模した自律型AIエージェント https://docs.devin.ai/get-started/devin-intro
• 職能横断
  職能（機能）を横断して仕事を成し遂げる編成
• Spotifyモデル
  #Team Organization Scaling Agile @ Spotifyの中で語られている組織設計で、Spotifyモデルとして知られている 自律的な職能横断型チームをスクワッドと呼び、スクワッドはトライブにまとめられる。 トライブ内の似た職能同士はチャプターという単位でプラクティスを共有する 日本語訳
• Observability Primary Signals
  
• Jeff Sutherland
  
• ファシリテーションモード
  #Team Organization チームトポロジーにて紹介される3つのチーム間インタラクションの内の1つ イネイブリングチームが行うような短期的な技術支援が該当し、チーム間の能力のギャップを最小化する
• Container Storage Interface
  CSI コンテナオーケストラレーション（主にKubernetes）でのコンテナ化されたワークロードから任意のストレージシステムを使用可能にするための仕様とその実体であるProtocol Buffers（gRPC通信前提）定義を提供する container-storage-interface/spec
• 成功循環モデル
  #Team Organization ダニエル・キムによる、チームや組織の成熟度は以下4つのサイクルで向上するというモデル 関係の質 思考の質 行動の質 結果の質
• Rolling Update
  #Continuous Delivery デプロイメント戦略の一種、新バージョンのデプロイ時、徐々に新バージョンのPodを追加しながら旧バージョンを削除していく