Kush's Wiki

Sort by - linked count

• Seb Rose
  
• イネイブリングチーム
  #Team Organization Team Topologiesにて紹介される4つのチームタイプの内の1つ 他のチームを技術等の知識によって支援する
• Continuous Testing
  #Testing
• 共通鍵暗号
  #Cryptography メッセージの暗号化と複合に同じ鍵を使う暗号方式
• SAML
  Security Assertion Markup Language #Security #Authentication XMLベースの認証・認可データ交換標準規格。IdPとSP（Service Provider）間で認証情報をやり取りし、SSO（Single Sign-On）を実現する。 https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
• 市谷 聡啓
  
• IdP
  Identity Provider #Authentication #Authorization デジタルアイデンティティシステムにおいて、ユーザーの認証を行い、アイデンティティ情報を提供するサービスまたは組織 代表的なソーシャルIdPとして、Google、Facebook、GitHub、Microsoftなどがある OIDCやOAuth2プロトコルを用いてアイデンティティ情報を外部アプリケーションに提供する
• ABAC
  Attiribute-based access control #Authorization 従来のRBACに対し、リソースに割り当てられた属性（AWSではタグ）に基づいて許可を定義する認可モデル リクエスト元であるプリンシパルの属性がリソースの属性と一致した場合に操作を許可するポリシーを設計する ABAC 認証で属性に基づいてアクセス許可を定義する - AWS Identity and Access Management
• Spotifyモデル
  #Blog #Team Organization Scaling Agile @ Spotifyの中で語られている組織設計で、Spotifyモデルとして知られている 自律的な職能横断型チームをスクワッドと呼び、スクワッドはトライブにまとめられる。 トライブ内の似た職能同士はチャプターという単位でプラクティスを共有する 日本語訳
• SIGKILL
  強制終了のシグナル シグナルの値は9
• サイドカープロキシ
  #Network サイドカーとして、サービスメッシュ内でプロキシを利用して実装される汎用パターン
• BRIEFの原則
  #Testing #BDD テストシナリオを記述するにあたり意識すべき6つの観点をまとめたもの 以下の5つの頭文字がBRIEFになっており、 Business language（ビジネス言語） Real data（実際のデータ） Intention revealing（意図を明らかにする） Essential（必須） Focused（焦点を絞る） 6つめはそのままBriefの単語を用いる Brief（簡潔である）
• DV証明書
  #Security 組織が当該ドメインを制御（domain validation）していることを認証局が証明するデジタル証明書
• LSP
  Language Server Protocol #Programming
• SIGTERM
  終了のシグナル、SIGKILLの前にクリーンなシャットダウンを行う猶予を生む シグナルの値は15で、killコマンドのデフォルトシグナルとなっている
• The Twelve-Factor App
  Software as a Serviceを作り上げるための方法論 The Twelve-Factor App （日本語訳）
• ファシリテーション
  #Team Organization Team Topologiesにて紹介される3つのチーム間インタラクションの内の1つ イネイブリングチームが行うような短期的な技術支援が該当し、チーム間の能力のギャップを最小化する
• Microsoft Threat Modeling Tool
  #Security 脅威モデリングを行うためのツール群、Microsoftによって提供されている https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool
• コンプリケイテッド・サブシステムチーム
  #Team Organization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する
• マイクロサービスの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（進化的設計） - サービス境界は変更時の複雑さに基づいて設定され、時間とともに柔軟に調整される想定で設計する
• オブザーバビリティ成熟度モデル
  
• ADT
  Algebraic Data Type 代数データ型 #Programming 列挙（和）された値の組み合わせ（積）を定義し、無効な組み合わせを表現できないように型化する方法
• メッセージダイジェスト
  #Cryptography メッセージの完全性を示す数学的手法、暗にハッシュと呼ばれることもある 不可逆 ハッシュ化された文書は元の文書に戻せない 非相関 元の文書の小さな変更が、ハッシュ化された文書では大きな変更となる 一意 同じメッセージダイジェストを生成する2つの文書は数学的に存在しない 最も一般的な使用法は、パスワードの安全な保存である
• 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
  #DevOps Slideshare
• age
  #Cryptography シンプルでモダンな暗号化ツール、Go製 https://github.com/FiloSottile/age
• 受け入れテスト
  #Testing 受け入れ条件を満たしているかのテスト
• 適応度関数
  Fitness Function #API Architecture システムの品質特性を数量化可能な指標で評価する、システムの目標を一貫して保証するためにビルドパイプラインに組み込まれる それぞれの特性は以下のようにカテゴライズされる コード品質（Code Quality） レジリエンス（Resiliency） オブザーバビリティ（#Observability） パフォーマンス（Performance） コンプライアンス（Compliance） セキュリティ（#Security） 運用操作性（Operability） Fitness function-driven development | Thoughtworks
• Node affinity
  Kubernetesのkube-schedulerにおいて、必須ルールと推奨ルールを設定しNodesへの割り当てを決定させる Assigning Pods to Nodes | Kubernetes
• Pwned Passwords
  #Authentication 既知のデータ侵害で利用されたパスワードかどうかを検証できるサービス、API https://haveibeenpwned.com/Passwords
• Amazon/

  DynamoDB
  #Data Engineering Amazonが提供するリーダーレスレプリケーションによるデータストア What is Amazon DynamoDB? - Amazon DynamoDB
• Amazon/

  S3
  Simple Storage Service #Data Engineering AWSが提供するオブジェクトストレージサービス What is Amazon S3? - Amazon Simple Storage Service
• Platform Engineering
  #DevOps Team Topologiesのプラットフォームチームをきっかけとして登場した分野 開発者の認知負荷の増大を防ぎ、生産性の向上を目指す
• Platform as a Product
  #Platform Engineering Team Topologiesのプラットフォームチームがストリームアラインドチームに向けてプラットフォームを提供する際、X-as-a-Serviceによって実現する考え
• Book/

  SRE サイトリライアビリティエンジニアリング
  
• Book/

  エクストリームプログラミング
  
• Charity Majors
  #Person Honeycomb社のCTO https://charity.wtf/about/
• Chris Matts
  #Person https://papachrismatts.uk/
• Codex
  #Programming #LLM OpenAIが提供するオープンソースのCLIコーディングエージェント ターミナル上でコードの読み取り・編集・実行が可能で、Rust製 MCPサーバーとの連携によりサードパーティツールと統合可能 コードレビューエージェントによるプッシュ前のレビュー機能 ローカルでのトランスクリプト保存による継続作業 https://github.com/openai/codex
• ファイブフィンガー
  #Team Organization チームに所属する個人個人の状況を把握するための手法、仕事の今の状態を「本当はどう思っているか」という視点で五段階で表明するっj；w
• BDD/

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

  発見
  Discovery #Testing #BDD 具体例の使用による構造化された協調作業
• BDD/

  自動化
  Automation #Testing #BDD 定式化されたシナリオの検証を自動化する
• Tanya Reilly
  #Person
• mise/

  Environment
  miseにおいてdirenvの代替となるような環境変数管理機能 https://mise.jdx.dev/environments/
• mise/

  Task
  miseにおいてMakefileの代替となるようなタスクランナー https://mise.jdx.dev/tasks/
• スクラム/

  透明性
  Transparency #スクラム #Agile 最新のスクラムガイドより抜粋 創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
• スクラム/

  スパイク
  #Agile スクラムの中で動くプロダクトを成果物とせず、プロダクトバックログアイテムの実現可能性を調査、検証するような取り組み https://agiledictionary.com/209/spike/
• GPT
  Generative Pre-Trained Transformer 生成的事前トレーニング済みトランスフォーマー #LLM トランスフォーマーのデコーダー部のみを採用したもの 事前トレーニングを行い精度を高める GPT-2では、インターネット上の文書において次の単語を予測するというトレーニング方法を用いて精度が大きく向上した
• 経験主義
  実際の経験と獲得している知識に基づいて意思決定をする考え
• Apache/

  Pekko
  #Programming Akka 2.6.xからフォークされたApache Software Foundation管理の並行・分散アプリケーションフレームワーク。Java/Scalaで利用可能 アクターモデルに基づき、軽量なアクターがメッセージパッシングで通信することでスレッド管理の複雑さを隠蔽する https://pekko.apache.org/