Sort by - linked count
-
スプリントプランニング#スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
-
Four KeysDORAによって提唱されるソフトウェアデリバリのパフォーマンス指標 名前の通り4つの尺度を追跡する デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 State of DevOps Reportでは、以上の4つの尺度を用いて、 Elite High Medium Low の4つに分類した ハイパフォーマーは全ての尺度での計測結果が抜きん出ており、スピードと品質にトレードオフ関係がないことを指し示した https://github.com/dora-team/fourkeys?tab=readme-ov-file
-
State of DevOps ReportDORAによって毎年出されているDevOpsの状況に関する報告書
-
Cron定期ジョブの実行頻度を表現する Cron表現方式によって実行するJobを一般にCronJobと呼ぶ cron - Wikipedia
-
Non-root User主にDockerfileなどにおいて、非rootユーザーでのログインを推奨する#Securityベストプラクティス Dockerfile ベストプラクティス docker-node/docs/BestPractices.md at main · nodejs/docker-node
-
テストピラミッド
-
Kubernetes/Operator#Kubernetes CRDによるカスタムリソースとそれを操作するControllerを共に使うパターン Operator pattern | Kubernetes
-
Kubernetes/Role
-
Kubernetes/Job
-
Kubernetes/ConfigMap
-
Kubernetes/Network policy
-
公開鍵#Cryptography 暗号方式において、全世界に公開される前提の鍵を指す
-
kube-proxy
-
ACID#Data Engineering トランザクションが保証する安全性について以下の4つの頭文字を取ったもの 原子性(Atomicity) 一貫性(Consistency) 分離性(Isolation) 永続性(Durability)
-
Four Keys/変更のリードタイムLead Time for Changes #DevOps
-
リーン#Agile トヨタが源流となるリーン生産方式をソフトウェア開発に適用している リーンソフトウェア開発には7つの原則がある ムダをなくす 品質を作り込む 知識を作り出す 決定を遅らせる 早く提供する 人を尊重する 全体を最適化する
-
eBPFextended Berkeley Packet Filter Linuxカーネル上で拡張プログラムを安全に実行できるLinuxの技術 OSカーネルは安定性・セキュリティの高い要件が求められるがゆえに進化のスピードが遅い課題があるがそれを解消し、Linux Foundationの下でeBPF Foundationとして開発が進められている HTML(Linuxカーネル)とJavaScript(eBPF)の関係性に例えられることが多い Home – eBPF
-
Python#Programming
-
Datadog/APMApplication Performance Monitoring #Observability Datadog上で分散トレースによってアプリケーションを詳細に可視化し、パフォーマンスボトルネックを特定するのに役立てる 設定方法は以下 アプリケーションインスツルメンテーション APM
-
L7Layer 7 #Network OSI参照モデルにおける第7層の通称 アプリケーション層を指し、HTTPが代表的
-
GitOpsWeaveworks社によって提唱された、#Cloud Nativeの文脈においてgitを用いた設定管理を行うような#Continuous Delivery手法 対象は主にKubernetesとなる
-
スプリント#Agile 主にスクラムにおいて扱われる、タイムボックス化されたある期間のこと 1~2週間が多く、長くても1ヶ月にするにする
-
HTTP/2#Network HTTPの後継プロトコル。GoogleのSPDYを起源とし、RFC 9113で標準化されている バイナリフレーミングによりHTTP/1.1のテキストベースを置き換え 単一TCPコネクション上で複数リクエストを並行処理するマルチプレキシング HPACKによるヘッダー圧縮でオーバーヘッドを削減 サーバープッシュによりリソースを事前送信 ストリーム優先度制御とフロー制御 https://httpwg.org/specs/rfc9113.html
-
Infrastructure as CodeInfrastructure as Code #Continuous Integration #Continuous Delivery インフラストラクチャとしてのプロセスや環境、設定等をコードで管理し文書化する方針 Infrastructure as Code とは - IaC の説明 - AWS
-
Prometeus
-
CLICommand Line Interface
-
Progressive Deliveryバージョンアップデートを段階的に行うようなデプロイメント戦略を適用した上で、デプロイ結果を分析し漸進的にデプロイの継続かまたはロールバックかを自動化するようなデリバリ手法 #Continuous Deliveryの進化系として紹介されることが多い https://argo-rollouts.readthedocs.io/en/stable/concepts/#progressive-delivery
-
IDEIntegrated Development Environment #Programming 以下のような機能を備えた統合的な開発環境 エディタ ターミナル コンパイラ デバッガ
-
ClaudeAnthropic社が提供するLLMモデル https://docs.anthropic.com/ja/docs/intro-to-claude
-
値オブジェクト概念的な同一性を持たないオブジェクト DDDにおけるモデル要素の一つ 以下、参考 あるモデル要素について、その属性しか関心の対象とならないのであれば、その要素を値オブジェクトとして分類すること。値オブジェクトに、自分が伝える属性の意味を表現させ、関係した機能を与えること。値オブジェクトを不変なものとして扱うこと。同一性を与えず、エンティティを維持するために必要となる複雑な設計を避けること。 Eric Evans | DDD | P97
-
Facebook
-
インセプションデッキ#Agile #Product Management #Team Organization 10個のアジェンダをチームおよび関係者で答えていくワーク われわれはなぜここにいるのか エレベータピッチ パッケージデザイン やらないことリスト ご近所さんを探せ 技術的な解決策 夜も眠れない問題 期間を見極める トレードオフスライダー 何がどれだけ必要か 日本語のテンプレートは以下にある https://github.com/agile-samurai-ja/support
-
サービスディスカバリアプリケーションサービスを公開する際、#Cloud Nativeなコンテナアプリケーションをステートレスに扱うようなケースで、アプリケーションの場所(IPアドレス)を容易に提供するためのパターン
-
two-pizza team#Team Organization 「私たちはチームの規模を、ピザ 2 枚で賄える人数以下に抑えることにしています」とベゾスは述べています。「これを 2 枚のピザチームのルールと呼んでいます。」 Amazonに浸透する1チームの規模の考え 2 枚のピザチーム - AWS での DevOps の概要
-
Ward Cunningham
-
CAPTCHACompletely Automated Public Turing test to tell Computers and Humans Apart #Security #Authentication 人間とボット(自動プログラム)を区別するための技術 主な目的はブルートフォース攻撃の防止、スパムやボットによる自動投稿の防止、不正なアカウント作成の防止 代表的な実装として、Google reCAPTCHA、hCaptcha、テキストベースCAPTCHAなどがある アクセシビリティの観点から、音声CAPTCHAなどの代替手段の提供が推奨される https://www.cloudflare.com/ja-jp/learning/bots/how-captchas-work/
-
Argo CD
-
Book/チームトポロジー
-
UDPUser Datagram Protocol #Network L4にあたる通信プロトコル エンドデバイス間でコネクションを確立せず遅延の最小化を優先させる メッセージのロスが許容される動画配信等に用いられる
-
Container Network InterfaceCNI #Cloud Native #Network LinuxおよびWindowsコンテナにおける、ネットワークインターフェースを構成するプラグインを作成するための仕様とライブラリ、およびサポートされているプラグイン CNCF project https://www.cni.dev/
-
タックマンモデル#Team Organization Developmental sequence in small groupsという論文で名付けられたモデル チームビルディングには以下の4段階のフェーズがあるという考え Froming 形成 Storming 混乱 Norming 統一 Performing 機能
-
BDD/定式化Formulation #Testing #BDD #Documentation システムの振る舞いの具体例をメンバーが読みやすいシナリオの形で文書化する
-
SMSSecret Management System #Security Secretの保存とアクセスを行うAPIを提供する、Secretをユーザが扱う段階では常に暗号化された状態になる
-
スクラム/検査Inspection #スクラム #Agile 最新のスクラムガイドより抜粋 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5 つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
-
スクラム/適応Adaptation #スクラム #Agile 最新のスクラムガイドより抜粋 プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
-
Knative
-
Jeff Patton#Person https://jpattonassociates.com/
-
Internal Developer Platform#Platform Engineering プラットフォームチームが内部開発者向けに提供するプラットフォーム 以下の5つのコンポーネントを網羅するように設計すべきとされている アプリケーションの構成管理 インフラストラクチャのオーケストレーション 環境の管理 デプロイメントの管理 ロール単位のアクセス制御 https://internaldeveloperplatform.org/
-
DevOps capabilities/Working in small batches#Continuous Integration DevOps capabilitiesの1つ、Fast Flowに分類される 価値提供フローの可視化、チームによる実験、顧客フィードバックの可視化と組み合わせることで高いソフトウェアデリバリパフォーマンスに寄与する バッチサイズの最小化にはINVESTの原則を用いると良い DORA | Capabilities: Working in small batches
-
DevOps capabilities/Test automation#Testing DevOps capabilitiesの1つ、Fast Feedbackに分類される https://dora.dev/capabilities/test-automation/ ユニットテスト/TDD 受け入れテスト Agile testing directions: tests and examples Loosely coupled teams テストピラミッド