Kush's Wiki

Sort by - linked count

• Argo Rollouts
  
• newtype
  #Programming 既存型をラップする形で新たな型を定義する 型エイリアスのように使われることが多いが、型エイリアスと異なりあくまで別の型として扱う
• Rolling Update
  #Continuous Delivery デプロイメント戦略の一種、新バージョンのデプロイ時、徐々に新バージョンのPodを追加しながら旧バージョンを削除していく
• 受け入れ条件
  #Agile #Documentation プロダクトバックログアイテムが完成したと判断できる条件
• ゴールデンサークル
  #Agile TEDの優れたリーダーはどうやって行動を促すかによって初めて解説された考え 円の中心から Why What How の順に並ぶ Howが一番外側にあるが優先度が低いというわけではなく、HowによってWhatに大きな影響を与えるケースもある
• Janet Gregory
  
• 振る舞い駆動開発
  振る舞いをベースにテストをし開発を進めようという考え Testing, TDDそれぞれの文脈で用いられている
• トレイト
  trait #Programming 振る舞い（メソッド）の集合をカプセル化する 一般に振る舞いは抽象として定義されるのが望ましい
• X-as-a-Serviceモード
  #Team Organization チームトポロジーにて紹介される3つのチーム間インタラクションの内の1つ APIインターフェース、ドキュメントを他チームに提供しソフトウェア設計と連動した疎なコミュニケーションを目指す
• Observability Primary Signals
  
• 完成の定義
  #Agile スプリントの成果物が「完成している」と認識するためにチームで定める条件
• レプリケーション
  #Data Store 書き込みまたは読み取りをリーダー、読み取りをフォロワーで行われ、リーダーへの書き込みがフォロワーに伝播される仕組みをレプリケーションと呼ぶ。 レプリケーションの方法として ステートメントベース write-aheadログ 等がある。 ステートメントベースはSQLをそのまま転送する形になるため副作用を持つ関数が返す結果にズレが生じる方法で、MySQL5.1以前に採用されていた。 write-aheadログはPostgreSQL,Oracleで使用されているが、ログが低レベルに記述されているため詳細実装と密になってしまう。 レプリケーションのトポロジーとしていくつかのパターンがある
• 受け入れテスト
  #Testing 受け入れ条件を満たしているかのテスト
• Non-root User
  主にDockerfileなどにおいて、非rootユーザーでのログインを推奨するセキュリティベストプラクティス Dockerfile ベストプラクティス docker-node/docs/BestPractices.md at main · nodejs/docker-node
• BRIEFの原則
  #Testing #BDD テストシナリオを記述するにあたり意識すべき6つの観点をまとめたもの 以下の5つの頭文字がBRIEFになっており、 Business language（ビジネス言語） Real data（実際のデータ） Intention revealing（意図を明らかにする） Essential（必須） Focused（焦点を絞る） 6つめはそのままBriefの単語を用いる Brief（簡潔である）
• Knative
  
• Greg Young
  
• OLTP
  Online Transactional Processing #Data Store ACIDを遵守し、高い可用性・信頼性を満たすべきシステムに対して用いられる言葉
• コントラクトテスト
  Contract Testing #Testing API提供者とAPI利用者間のやり取りの定義をコントラクトとして扱い、スタブサーバ等を用意することで各システムが独立してテストできるようになるテスト手法。依存するシステムが増えうるマイクロサービスの文脈で適用されることが多い 全てのシステムを統合するE2Eテストと異なりテストの実行が軽量でありメンテナンス容易であるといった利点を持つ What is Contract Testing & How is it Used? | Pactflow
• DevOpsトポロジー
  #DevOps #Agile #Team Organization 2013年にMatthew Skeltonによって書かれたブログ、チームトポロジーの根底にある考えがまとまったような内容になっている 訳: 吉羽 龍太郎 https://www.ryuzee.com/contents/blog/14567
• オブザーバビリティ成熟度モデル
  
• ファシリテーションモード
  #Team Organization チームトポロジーにて紹介される3つのチーム間インタラクションの内の1つ イネイブリングチームが行うような短期的な技術支援が該当し、チーム間の能力のギャップを最小化する
• Dan North
  
• Unknown unknowns
  #Observability 自分は意識も理解もしていないこと 未知のシステム故障への対応、が該当する
• Ron Jeffries
  #Person Home
• プログラマーの誓い
  #Robert C. Martin Clean Coder Blog
• リーン
  #Agile トヨタが源流となるリーン生産方式をソフトウェア開発に適用している リーンソフトウェア開発には7つの原則がある ムダをなくす 品質を作り込む 知識を作り出す 決定を遅らせる 早く提供する 人を尊重する 全体を最適化する
• デイリースクラム
  #スクラム #Agile 最新のスクラムガイドより抜粋 デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 全員で以下のフォーマットを共有する 昨日やったこと 今日やること 障害となっているもの
• 単一責任の原則
  #Software Design SOLID原則の1つであり、オブジェクト指向プログラミングにおける一般的なプラクティス コードの部品は1つだけのことを行い、他のことは行ってはならないということ
• 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/

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

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

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

  Continuous delivery
  #Continuous Delivery DevOps capabilitiesの1つ、Fast Flowに分類される https://dora.dev/capabilities/continuous-delivery/
• DevOps capabilities/

  Loosely coupled teams
  #Software Design DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Loosely coupled teams
• 認知負荷
  個人やチームの認知容量に対する負荷のこと 認知負荷は3つに分類することができる 課題内在性認知負荷 問題領域のタスクの難易度に関する負荷、研修・技術選定・ペアプログラミング等で解消する 課題外在性認知負荷 タスクを実施する環境に関する負荷、CIによる自動化等で解消する 学習関連負荷 知識の構築に関する負荷、学習によって増やすべき負荷とされる 情報過多にご用心！生産性の低下を招く「認知的過負荷」への対処法 ── 海の向こうからオピニオン その70 (1/2) - チームの教科書｜アトラシアン株式会社
• 要件定義
  #Documentation 「何を作ればよいのか」を明確にするために行う
• Kubernetes Network Policy Recipes
  #Kubernetes Network policyの実装例をまとめたリポジトリ ahmetb/kubernetes-network-policy-recipes
• SECIモデル
  知識を暗黙知と形式知に分けそれらが学習サイクルに表れる過程をモデル化したもの 以下の4つのフェーズを繰り返す 共同化（Socialization） 暗黙知から暗黙知。組織として共通の経験を積み重ねる 表出化（Externalization） 暗黙知から形式知。経験的知識の共通点や抽象的な構造をモデル化する 連結化（Combination） 形式知から形式知。複数の形式知から知識体系を作る 内面化（Internalization） 形式知から暗黙知。形式知を実践的に理解できた状態
• Prometeus
  
• Elastic Load Balancing
  #Cloud Native #API Architecture AWSが提供するロードバランシングコンポーネント リソースごとに以下のような種別がある Application Load Balancer Network Load Balancer Gateway Load Balancer What is Elastic Load Balancing? - Elastic Load Balancing
• 関数型ドメインモデリング
  
• Google Cloud/

  Certificate Manager
  #Security Google Cloudにおいて外部ロードバランシングで必要となるようなTLS証明書を管理する Certificate Manager の概要 | Google Cloud
• Bertrand Meyer
  
• GM Weinberg
  #Person
• Multitenancy
  分離されたユーザのグループ（テナント）を複数持つことをサポートするプラットフォームの機能
• Basic認証
  #Security #Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う
• GraphQL
  
• 契約による設計
  #オブジェクト指向プログラミング #Programming #Software Design 契約による設計事始め
• マルチリーダーレプリケーション
  #Data Store レプリケーションの種別の一つ 複数のデータセンターにリーダーが存在する。リアルタイムの同時編集がイメージに近い。書き込みの衝突があった際に最終的に同じ値に収束させるような方法が取られる