Kush's Wiki

Sort by - linked count

• Playwright
  #Testing #Programming Microsoftが開発したE2Eテストツール flaky testsを減らせるブラウザ向け機能が揃っている TypeScript, Javaといったいくつかの言語でAPIが用意されている https://playwright.dev/
• Dockerfile
  Dockerにおいてイメージの構成を記述するファイル IaCとして機能する Dockerfile リファレンス — Docker-docs-ja 24.0 ドキュメント
• DevOpsトポロジー
  #DevOps #Agile #Team Organization 2013年にMatthew Skeltonによって書かれたブログ、チームトポロジーの根底にある考えがまとまったような内容になっている 訳: 吉羽龍太郎 DevOpsトポロジー | Ryuzee.com
• ゴールデンサークル
  #Agile TEDの優れたリーダーはどうやって行動を促すかによって初めて解説された考え 円の中心から Why What How の順に並ぶ Howが一番外側にあるが優先度が低いというわけではなく、HowによってWhatに大きな影響を与えるケースもある
• コントラクトテスト
  Contract Testing #Testing API提供者とAPI利用者間のやり取りの定義をコントラクトとして扱い、スタブサーバ等を用意することで各システムが独立してテストできるようになるテスト手法。依存するシステムが増えうるマイクロサービスの文脈で適用されることが多い 全てのシステムを統合するE2Eテストと異なりテストの実行が軽量でありメンテナンス容易であるといった利点を持つ What is Contract Testing & How is it Used? | Pactflow
• 受け入れ条件
  #Agile #Documentation プロダクトバックログアイテムが完成したと判断できる条件
• UDP
  User Datagram Protocol #Network OSI参照モデルにおけるトランスポート層にあたる通信プロトコル エンドデバイス間でコネクションを確立せず遅延の最小化を優先させる メッセージのロスが許容される動画配信等に用いられる
• 認知負荷
  個人やチームの認知容量に対する負荷のこと 認知負荷は3つに分類することができる 課題内在性認知負荷 問題領域のタスクの難易度に関する負荷、研修・技術選定・ペアプログラミング等で解消する 課題外在性認知負荷 タスクを実施する環境に関する負荷、CIによる自動化等で解消する 学習関連負荷 知識の構築に関する負荷、学習によって増やすべき負荷とされる 情報過多にご用心！生産性の低下を招く「認知的過負荷」への対処法 ── 海の向こうからオピニオン その70 (1/2) - チームの教科書｜アトラシアン株式会社
• タックマンモデル
  #Team Organization Developmental sequence in small groupsという論文で名付けられたモデル チームビルディングには以下の4段階のフェーズがあるという考え Froming 形成 Storming 混乱 Norming 統一 Performing 機能
• Observability Primary Signals
  
• OLAP
  Online Analytics Processing #Data Processing データ分析を目的として多次元データを扱うシステムに対して用いられる言葉
• 完成の定義
  #Agile スプリントの成果物が「完成している」と認識するためにチームで定める条件
• Alistair Cockburn
  
• 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
• オブザーバビリティ成熟度モデル
  
• Ward Cunningham
  
• Ron Jeffries
  #Person Home
• Book/

  エクストリームプログラミング
  
• Book/

  チームトポロジー
  
• Seb Rose
  
• Java
  #[Programming]
• two-pizza team
  #Team Organization 「私たちはチームの規模を、ピザ 2 枚で賄える人数以下に抑えることにしています」とベゾスは述べています。「これを 2 枚のピザチームのルールと呼んでいます。」 Amazonに浸透する1チームの規模の考え 2 枚のピザチーム - AWS での DevOps の概要
• Argo
  
• LeanとDevOpsの科学
  
• プロダクトバックログアイテム
  #Agile プロダクトバックログ上で生まれるアイテム、要件、テストなどをまとめるハブになる
• DevOps capabilities/

  Customer feedback
  DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Customer feedback
• DevOps capabilities/

  Continuous integration
  #Continuous Integration DevOps capabilitiesの1つ、Fast Feedbackに分類される CIを実現するには次の要素が必要としている 自動化されたビルドプロセス 自動化されたテストスイート チェックイン毎の自動ビルドとテスト また次の2つも効果に繋がる Trunk-based development Working in small batches メンテナンス容易な自動化テストのためにはTDDを実践すると良い DORA | Capabilities: Continuous integration
• DevOps capabilities/

  Work in process limits
  #Agile DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Work in process limits
• DevOps capabilities/

  Visibility of work in the value stream
  DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Visibility of work in the value stream
• DevOps capabilities/

  Continuous delivery
  #Continuous Delivery DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Continuous delivery
• DevOps capabilities/

  Loosely coupled teams
  #Software Design DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Loosely coupled teams
• プラットフォームチーム
  #Team Organization チームトポロジーにて紹介される4つのチームタイプの内の1つ 機能横断的なインフラやツール、ライブラリ等をを実装しストリームアラインドチームにAPIを提供する
• 仮説キャンバス
  
• X-as-a-Serviceモード
  #Team Organization チームトポロジーにて紹介される3つのチーム間インタラクションの内の1つ APIインターフェース、ドキュメントを他チームに提供しソフトウェア設計と連動した疎なコミュニケーションを目指す
• Linux Capabilities
  rootユーザーが持つ特権を細分化したもの Non-root Userへ必要最小限のケイパビリティを割り当てる方法は、Dockerのセキュリティベストプラクティスとして紹介されている Linux Capabilities Docker のセキュリティ — Docker-docs-ja 1.12.RC2 ドキュメント
• Platform Engineering
  #DevOps
• エラーバジェット
  #Reliability リリース可否を決めるための指標となるような考え方。 SLOを満たせない時間を名前の通り予算として管理する。 エラーバジェットが残っていればリリース可能、エラーバジェットを使い切っていればリリースはストップしシステムの改善を行うというような運用をする。 エラーバジェットによってプロダクト開発者とSREでイノベーションと信頼性のバランスを適切に扱う
• Ambassador Edge Stack
  
• 経験主義
  実際の経験と獲得している知識に基づいて意思決定をする考え
• Ken Schwaber
  
• カスケード障害
  #Reliability 1つのワークロードが引き起こす障害がシステム全体に影響を及ぼすこと
• Bearerトークン
  #Security #Authorization トークンを保持するBearer（持参人）が誰であれ、そのトークンをリソースへのアクセスに使うことができる 平文の文字列でシークレットや署名は扱わず、セキュリティはTLSのようなトランスポート層での仕組みに任せている HTTP通信のAuthorizationヘッダーに付与するのを推奨されている RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
• Matthew Skelton
  
• コラボレーションモード
  #Team Organization チームトポロジーにて紹介される3つのチーム間インタラクションの内の1つ チーム間で短期的に密なコミュニケーションを行う、境界は曖昧な状態だがイノベーションの原動力になる
• 型エイリアス
  #Programming 名前の通り型のエイリアスを定義する あくまでエイリアスであるためエイリアス間の値は同一の型として扱われる
• レプリケーション
  #Data Store 書き込みまたは読み取りをリーダー、読み取りをフォロワーで行われ、リーダーへの書き込みがフォロワーに伝播される仕組みをレプリケーションと呼ぶ。 レプリケーションの方法として ステートメントベース write-aheadログ 等がある。 ステートメントベースはSQLをそのまま転送する形になるため副作用を持つ関数が返す結果にズレが生じる方法で、MySQL5.1以前に採用されていた。 write-aheadログはPostgreSQL,Oracleで使用されているが、ログが低レベルに記述されているため詳細実装と密になってしまう。 レプリケーションのトポロジーとしていくつかのパターンがある
• 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
  #DevOps Slideshare
• Dapr
  
• Container Storage Interface
  CSI コンテナオーケストラレーション（主にKubernetes）でのコンテナ化されたワークロードから任意のストレージシステムを使用可能にするための仕様とその実体であるProtocol Buffers（gRPC通信前提）定義を提供する container-storage-interface/spec
• BRIEFの原則
  #Testing #BDD テストシナリオを記述するにあたり意識すべき6つの観点をまとめたもの 以下の5つの頭文字がBRIEFになっており、 Business language（ビジネス言語） Real data（実際のデータ） Intention revealing（意図を明らかにする） Essential（必須） Focused（焦点を絞る） 6つめはそのままBriefの単語を用いる Brief（簡潔である）