Kush's Wiki

Sort by - linked count

#Security シンプルでモダンな暗号化ツール、Go製 FiloSottile/age

#Team Organization 遅れているプロジェクトに人を足してもさらに遅れるだけという法則。人月の神話で語られている

#Observability DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Proactive failure notification

#API Architecture DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Deployment Automation

DevOps capabilitiesの1つ、Fast Flowに分類されるアプリケーションコードだけでなく、ビルドスクリプトやコンフィギュレーションに対しても管理を行うことが推奨され、継続的インテグレーションに寄与する DORA | Capabilities: Version Control

#Observability DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Monitoring and observability

DevOps capabilitiesの1つ、Climate for Learningに分類される DORA | Capabilities: Transformational leadership

#Security DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Pervasive security

DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Streamlining change approval

#Software Design DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Loosely coupled teams

#Testing DevOps capabilitiesの1つ、Fast Feedbackに分類される DORA | Capabilities: Test data management

#Software Design DevOps capabilitiesの1つ、Climate for Learningに分類される仕事の満足度に寄与し、ツールやテクノロジーをチームに強制するとチームによる実験が制限されてしまう DORA | Capabilities: Empowering teams to choose tools

DevOps capabilitiesの1つ、Climate for Learningに分類される DORA | Capabilities: Job satisfaction

DevOps capabilitiesの1つ、Fast Flowに分類される WIP制限と組み合わせると良い DORA | Capabilities: Visual management

#API Architecture Leonard RechardsonによるREST APIの観点からAPI実装の成熟度をレベルに分類したもの各レベルのタイトルは以下レベル0 HTTP/RPC レベル1 リソースレベル2 動詞（メソッド）レベル3 ハイパーメディアコントロール QCon 2008での発表は以下 Justice Will Take Us Millions Of Intricate Moves

「何を作ればよいのか」を明確にするために行う

#スクラムスクラムガイドで紹介されている5つの価値基準確約(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage)

#スクラム経験主義をベースにスクラムガイドで紹介されている三本柱透明性検査適応

trait bound ある型があるトレイトの振る舞いを満たすかの制約をコンパイル時に定義する

分離されたユーザのグループ（テナント）を複数持つことをサポートするプラットフォームの機能

#オブジェクト指向プログラミング #Programming 契約による設計事始め

#Documentation 以下の4つのダイアグラム図を表すアプローチ Context Diagram Container Diagram Component Diagram Code Diagram 順に抽象度が下がっていく流れになっている Home | C4 model

System of Record データの記録を重視するシステム、企業の業務基幹システム等が該当する

#Cloud Native #API Architecture AWSが提供するロードバランシングコンポーネントリソースごとに以下のような種別がある Application Load Balancer Network Load Balancer Gateway Load Balancer What is Elastic Load Balancing? - Elastic Load Balancing

Technical Debt Quadrant Martin Fowlerが技術的負債が発生するケースを4象限で分類したもの。 Reckless（無謀） or Prudent（慎重） Deliberate（意図的） or Inadvertent（不注意）の2軸で分類する。例えばリリース当初はクリーンなコードを書いていたつもりだが、1年後に本来正しかった設計が見つかった。のようなケースではPrudentかつInadvertentとなる Blog

OCI 2015年にDockerとその他の業界リーダーによって作成された、コンテナ形式とランタイムに関するオープンな業界標準具体的に以下の3つの仕様を持つ runtime-spec image-spec distribution-spec Linux Foundationプロジェクト Open Container Initiative - Open Container Initiative

#Network #HTTP インターネット上の通信で多く用いられてきたTCPの課題を解消する、Googleが開発したプロトコル UDPをベースし、コネクション確立によるRTTの増大を防ぎつつ、TCPと同様の高い信頼性の実現、TLSを必須とするセキュリティの考慮がされる。 HTTP/3で用いられるプロトコルで高速なHTTPS通信を実現する　コネクションID QUICではIPアドレス、ポート番号を抽象化する形で宛先、送信元に対応するコネクションIDが用いられる。コネクションIDによりモバイル機器のようなWiFi・モバイルデータ通信等が頻繁に切り替わりIPアドレスの変更がある場合でも、コネクションを途切らせずに通信を続けられる。 QUICヘッダー QUICヘッダーはTCPと異なり明確にロングヘッダー、ショートヘッダーの2つに分類される。ロングヘッダーはコネクション確立時、ショートヘッダーはその後のデータ送信に用いられるロングヘッダーはコネクション確立に必要な情報をまとめて送る（1-RTTハンドシェイク）ことでRTTの改善がされるストリーム QUICでは順序制御や再送制御を管理する単位としてストリーム（ID）という概念を用いる。ストリーム同士は独立しておりHoLブロッキングのような問題の回避をする

#Network 分散システムを扱い際、しばしば陥りがちなネットワークへの仮定を8つリストアップしたものネットワークは信頼性があるレイテンシはゼロ帯域幅は無限ネットワークは安全トポロジは変わらない管理者は1人だけ転送コストはゼロネットワークは均質 The Eight Fallacies of Distributed Computing

#Security Google Cloudにおいて外部ロードバランシングで必要となるようなTLS証明書を管理する Certificate Manager の概要 | Google Cloud

Attiribute-based access control #Security #Authorization 従来のRBACに対し、リソースに割り当てられた属性（AWSではタグ）に基づいて許可を定義する認可モデルリクエスト元であるプリンシパルの属性がリソースの属性と一致した場合に操作を許可するポリシーを設計する ABAC 認証で属性に基づいてアクセス許可を定義する - AWS Identity and Access Management

#Security GitOpsの世界においてSecretをクライアントサイドで扱うGo製のツール。YAMLやJSONのファイル上でSecretを安全にgit管理することができる ageを用いたローカルでのキー管理か、KMSによるキー管理のどちらを選択できる CNCF sandbox project SOPS: Secrets OPerationS

Software as a Serviceを作り上げるための方法論 The Twelve-Factor App （日本語訳）

#ドメイン駆動設計ドメインイベント: 設計と実装 - .NET Domain Events and Eventual Consistency

個人やチームの認知容量に対する負荷のこと認知負荷は3つに分類することができる課題内在性認知負荷問題領域のタスクの難易度に関する負荷、研修・技術選定・ペアプログラミング等で解消する課題外在性認知負荷タスクを実施する環境に関する負荷、CIによる自動化等で解消する学習関連負荷知識の構築に関する負荷、学習によって増やすべき負荷とされる情報過多にご用心！生産性の低下を招く「認知的過負荷」への対処法 ── 海の向こうからオピニオンその70 (1/2) - チームの教科書｜アトラシアン株式会社

#Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。自己開示: プロセスを隠さず失敗を認める他者理解: 相手に関心を持ち立場を理解しようとする組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。信頼を築く対話不安を乗り越える対話 WHYを作り上げる対話コミットメントを行う対話説明責任を果たす対話重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

prev next