Kush's Wiki

Sort by - linked count

• Apache Avro
  #Data Engineering データシリアライゼーションシステム（公式には "a data serialization system"。"the leading serialization format for record data, and first choice for streaming data pipelines" と自己記述される）。JVM 系・Python・C / C++ / C#・Ruby・Rust・JavaScript など多言語の実装を持つ バイナリエンコードは型情報もフィールド名も含まず、解釈は完全にスキーマに依存する。reader が writer と異なるスキーマで読める schema resolution 規則がスキーマ進化（"excellent schema evolution"）を支える コンテナファイル（Object Container File）はヘッダに格納オブジェクトのスキーマを JSON で必須同梱するため、ファイル単体で自己記述的になる https://avro.apache.org/
• サービスディスカバリ
  アプリケーションサービスを公開する際、#Cloud Nativeなコンテナアプリケーションをステートレスに扱うようなケースで、アプリケーションの場所（IPアドレス）を容易に提供するためのパターン
• 仮説キャンバス
  
• IdP
  Identity Provider #Security/Authentication #Security/Authorization デジタルアイデンティティシステムにおいて、ユーザーの認証を行い、アイデンティティ情報を提供するサービスまたは組織 代表的なソーシャルIdPとして、Google、Facebook、GitHub、Microsoftなどがある OIDCやOAuth2プロトコルを用いてアイデンティティ情報を外部アプリケーションに提供する
• X-as-a-Service
  #Team Organization Team Topologiesにて紹介される3つのチーム間インタラクションの内の1つ APIインターフェース、ドキュメントを他チームに提供しソフトウェア設計と連動した疎なコミュニケーションを目指す
• リーダーレスレプリケーション
  #Data Engineering AmazonがDynamoシステムで利用し流行しDynamoスタイルと呼ばれる。 一部のノードが何らかの理由で利用できなくてもクオラムによって読み取りあるいは書き込みの正当性を判断する
• aqua
  #Programming CLIツール専用の宣言的バージョンマネージャー。Go製、@suzuki-shunsuke による aqua.yamlでツールとバージョンを宣言的に管理 GitHub Releasesからバイナリを自動取得 Lazy Install: 実行時に必要なツールを自動インストール Checksum検証、Cosign/SLSA Provenance対応 https://aquaproj.github.io/ https://github.com/aquaproj/aqua
• KMS
  Key Management System #Security/Cryptography 暗号化キーのディスカバリ、保存を行う管理システム。暗号化はKMS外で行う前提
• Book/

  チームトポロジー
  
• DV証明書
  #Security 組織が当該ドメインを制御（domain validation）していることを認証局が証明するデジタル証明書
• Container Network Interface
  CNI #Cloud Native #Network LinuxおよびWindowsコンテナにおける、ネットワークインターフェースを構成するプラグインを作成するための仕様とライブラリ、およびサポートされているプラグイン CNCF project https://www.cni.dev/
• suzuki-shunsuke
  
• スクラム/

  透明性
  Transparency #Agile スクラムを支える経験主義の柱の一つ。最新のスクラムガイドより抜粋 創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
• C-I-A
  #Security 機密性(Confidentiality) 完全性(Integrity) 可用性(Availability) の頭文字を取ったセキュリティの3つの柱
• GitHub Copilot
  #Programming VS Codeにビルドインで搭載されているAIアシスタント プランによって利用できるLLMが異なる https://docs.github.com/ja/copilot
• Ward Cunningham
  
• トランクベース
• ヘキサゴナルアーキテクチャ
  
• OLAP
  Online Analytics Processing #Data Engineering データ分析を目的として多次元データを扱うシステムに対して用いられる言葉
• TLS証明書
  #Network #Security/Cryptography TLSによるHTTPS通信において、TLSハンドシェイクに用いるデジタル証明書のこと
• WIP制限
  #Agile 仕掛り作業の件数を制限し、同時に複数の仕事に着手しないという考え
• LSP
  Language Server Protocol #Programming
• USM/

  ユーザータスク
  #Agile #Product Management ユーザーが目的を達成するために行う、ひとつひとつの行動。
• USM/

  アクティビティ
  #Agile #Product Management 複数のユーザータスクをまとめた、ユーザーの大きな目的を表す行動のまとまり。
• モジュラモノリス
  #Software Design DDDの境界づけられたコンテキストの概念に従って、モノリス内で明確に境界が分かれたコンテキストをそれぞれモジュール化する 例としてコンテキスト間のI/FはProtocol Buffersにて定義し、ヘキサゴナルアーキテクチャにおけるアダプタ層のみ公開することで、境界を跨いだ依存解決を許さない等の方法がある
• MFA
  Multi Factor Authentication 多要素認証 #Security/Authentication
• Codex
  #Programming #LLM OpenAIが提供するオープンソースのCLIコーディングエージェント ターミナル上でコードの読み取り・編集・実行が可能で、Rust製 MCPサーバーとの連携によりサードパーティツールと統合可能 コードレビューエージェントによるプッシュ前のレビュー機能 ローカルでのトランスクリプト保存による継続作業 https://github.com/openai/codex
• Base64
  元の文字列から英数字のみの結果を出力するエンコード方式 例としてJSONで用いられる波括弧やダブルクォーテーション等の特殊文字を適切に扱えるよう、英数字のみの値に変換する RFC 4648 - The Base16, Base32, and Base64 Data Encodings
• Honeycomb
  #Observabilityに関するエンドツーエンドのプロダクト Retrieverというオブザーバビリティに最適化された独自のデータストアを備えており、S3によって実装されている Honeycomb.io Documentation | Honeycomb
• 受け入れ条件
  #Agile #Product Management #Documentation プロダクトバックログアイテムが完成したと判断できる条件
• コラボレーション
  #Team Organization Team Topologiesにて紹介される3つのチーム間インタラクションの内の1つ チーム間で短期的に密なコミュニケーションを行う、境界は曖昧な状態だがイノベーションの原動力になる
• HMAC
  Hash-based Message Authentication Code #Security/Cryptography 共通鍵とメッセージダイジェストによる共通鍵暗号方式 共通の鍵を有するので両者ともに署名付きトークンを生成・検証できる
• Few-shot
  プロンプトエンジニアリング LLMへの入力に回答例を提示することで、例の通りに回答を得る方法
• Dapr
  
• OWASP Top Ten
  #Security OWASP Foundationが発表するセキュリティ専門家によるトップ10に含まれるべき脆弱性リスト 定期的に更新されるため最新を追うべき https://owasp.org/www-project-top-ten/
• 同一生成元ポリシー
  Same Origin Policy #Security ホストドメインとポート番号が一致する場合にのみ、リソース間の相互交流を許可する
• マイクロサービスの9つの特徴
  #Software Design Microservicesのブログの中で説明されたマイクロサービスについての9つの特徴 9つの特徴 1. Componentization via Services（サービスによるコンポーネント化） - サービスを独立してデプロイ・置き換え可能なソフトウェアユニットとして扱う 2. Organized around Business Capabilities（ビジネス機能による組織化） - 技術層ではなくビジネス能力を中心にチームを編成し、UIからデータベースまで一つのチームが担当する 3. Products not Projects（プロジェクトではなくプロダクト志向） - "開発したものを自分たちで運用する"という哲学のもと、チームが長期的責任を持つ 4. Smart endpoints and dumb pipes（スマートエンドポイント、ダムパイプ） - 複雑なロジックはサービス内に置き、通信機構（HTTP、メッセージング）はシンプルに保つ 5. Decentralized Governance（分散ガバナンス） - 各チームが独立してプログラミング言語やデータベース技術を選択でき、中央集約的な標準化を避ける 6. Decentralized Data Management（分散データ管理） - 各サービスが独自のデータベースを管理し、結果整合性を活用する 7. Infrastructure Automation（インフラストラクチャ自動化） - 継続的デリバリーと自動デプロイメントを支援するツールやパイプラインへの投資を重視する 8. Design for failure（障害設計） - サービス障害に対応するため、回路ブレーカーパターンなどを使い、システムの耐障害性を確保する 9. Evolutionary Design（進化的設計） - サービス境界は変更時の複雑さに基づいて設定され、時間とともに柔軟に調整される想定で設計する
• TLSハンドシェイク
  #Security/Cryptography #Network TLSプロトコルにおいて、通信初期に公開鍵暗号方式によって通信を確立すること
• SOLID
  #Software Design Single responsibility principle Open/Closed principle Liskov substitution principle Interface segmentation principle Dependency inversion principle の頭文字を取った原則。オブジェクト指向プログラミングの文脈で語られる 2000年にRobert C. Martinによって原則群が発表された
• Charity Majors
  Honeycomb社のCTO https://charity.wtf/about/ 人物
• Node affinity
  Kubernetesのkube-schedulerにおいて、必須ルールと推奨ルールを設定しNodesへの割り当てを決定させる Assigning Pods to Nodes | Kubernetes
• 要件定義
  #Documentation 「何を作ればよいのか」を明確にするために行う
• React Server Components
  RSC #Programming React 19で安定版となったサーバー上で実行されるコンポーネントアーキテクチャ 主な特徴: サーバーでレンダリングされ、クライアントにJavaScriptを送信しない RSC Payloadとしてシリアライズされた形式でクライアントに送信 <Suspense>境界によるストリーミングレンダリングをサポート クライアントコンポーネントは"use client"ディレクティブで宣言 https://react.dev/reference/rsc/server-components
• Minimum Viable Platform
  Platform Engineering #Product Management Platform Engineering に MVP の発想を持ち込んだ概念。包括的な機能ではなく、ステークホルダーへ数週間で価値を実証できる最小限のプラットフォームを指す
• BDD/

  ルール
  #Testing BDDにおいて以下を抽象化したようなもの 要件 ビジネスルール 受け入れ基準
• BDD/

  自動化
  Automation #Testing BDDのプラクティスのひとつ。定式化されたシナリオの検証を自動化する
• プログラマーの誓い
  Robert C. Martin（Uncle Bob）が示したプログラマーが守るべき誓い Clean Coder Blog ブログ
• アウトカム
  #Product Management アウトプットを用いて得られる成果、ユーザーに感じてもらう価値
• コンプリケイテッド・サブシステムチーム
  #Team Organization #Security/Authentication #Security/Authorization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する
• デイリースクラム
  #Agile スクラムの開発者が毎日行うイベント。最新のスクラムガイドより抜粋 デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 全員で以下のフォーマットを共有する 昨日やったこと 今日やること 障害となっているもの