Sort by - linked count
-
SLOService level objectives SREにおけるサービスレベル目標の略。 サービスレベル指標(Service level indicators = SLI)に対してターゲットとする値または範囲を目標とする。 サービスレベル指標に用いられるのは主に以下のようなもの 可用性 リクエストレイテンシ エラー率 システムスループット サービスレベルアグリーメント(Service level agreement = SLA)は、SLOを守るまたは守れないケースに関する規定をユーザーと同意するもの。 SLO, SLI, SLAは定義が曖昧になりやすいので注意が必要
-
Markdown#Documentation
-
MCPModel Context Protocol LLMが様々なリソースにアクセスするためのAnthropic社による標準化プロトコル MCPサーバーがローカルまたはリモートのリソースにアクセスし、それをMCPクライアントが利用する MCPクライアントとサーバー間のトランポートレイヤでは stdio(標準入出力) HTTP POST のいずれかが用いられる https://modelcontextprotocol.io/docs/concepts/architecture
-
OAuth2#API Architecture #Security/Authorization RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー(Resource Owner) 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー(Resource Server) 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント(Client) リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー(Authorization Server) リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework
-
リバースプロキシ#API Architecture #Network 外部トラフィックに対して単一のサーバーへルーティングを行い、サーバーの保護や負荷分散を行う役割
-
可用性Availability #Security データを利用可能な状態に保つこと。大幅な遅延や不正なシャットダウンを許さない
-
逆コンウェイ戦略#Software Design #Team Organization コンウェイの法則に対して、開発チームの組織構造を変更して、望ましいソフトウェア設計を目指すという考え方 マイクロサービスが注目されるようになった2015年頃にコンウェイの法則が再評価され生まれた
-
E2EテストEnd to End Testing #Testing 組織のドメイン外にある外部システムを除いて実際に全てのサービスを動作させUIレベルで行うテスト 一般的な形式として1つまたは複数のユーザアクションに基づくシナリオテストがあり、テストコストが増えすぎないよう主要なシナリオにフォーカスして行う
-
Robert C. Martin
-
完全性Integrity #Security データを正確に管理する、不正な変更や削除を許さない
-
L4Layer 4 #Network OSI参照モデルにおける第4層の通称 トランスポート層を指し、TCPやUDPが代表的
-
Gherkin#Testing #Documentation Chris Mattsによって考えられた、以下のフォーマットでテストシナリオを記述する記法 Scenario: Breaker joins a game Given the Maker has started a game with the word "silky" When the Breaker joins the Maker's game Then the Breaker must guess a word with 5 characters https://cucumber.io/docs/gherkin/reference
-
CLICommand Line Interface
-
サーキットブレーカーアプリケーションが失敗する可能性のある操作を繰り返し試行するのを防ぐ信頼性パターン サーキット ブレーカー パターン - Azure Architecture Center
-
自己組織化#Team Organization チームまたは個人が外部に依存せず自律して意思決定をし行動できる度合い
-
zizmor#Security #Continuous Integration GitHub Actionsワークフローの静的解析を行うSASTツール。サプライチェーン攻撃や認証情報窃取につながる workflow 設定の不備を検出する Rust製。.github/workflows/ 配下の YAML を解析し、命名された audit ID 単位で検出 / ignore を行える 主な audit カテゴリ: dangerous-triggers template-injection unpinned-uses excessive-permissions overprovisioned-secrets https://zizmor.sh/ https://github.com/zizmorcore/zizmor
-
Kubernetes/Nodes
-
ストリームアラインドチーム#Continuous Delivery #Team Organization Team Topologiesにおける4つのチームタイプの中で中心となるチーム ビジネス価値を提供するフロー(ストリーム)に従って、クロスファンクショナルチームを形成する 要求の探索から本番環境の運用までの全ての能力を備え、他のチームを待たずにデリバリーができる
-
HTTPSHyperText Transfer Protocol Secure #Network #Security/Cryptography HTTPをTLSによって暗号化した通信
-
ユニットテスト#Testing
-
DORA
-
ブルートフォース攻撃#Security/Authentication 総当たり攻撃。パスワードや暗号鍵などを、可能な組み合わせを全て試すことで解読を試みる攻撃手法 対策として以下のような方法がある 強力なパスワードポリシーの適用(zxcvbn-ts、Pwned Passwordsによる検証) アカウントロックアウト機能 レートリミットによるログイン試行回数の制限 MFAの導入 CAPTCHAの利用 https://www.ipa.go.jp/security/vuln/websecurity/brute-force.html
-
アジャイルソフトウェア開発宣言#Agile Agile Manifest(ja) プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
-
Kent Beck
-
風間 裕也
-
DockerfileDockerにおいてイメージの構成を記述するファイル IaCとして機能する https://docs.docker.jp/engine/reference/builder.html
-
コンテキストウインドウLLMが一度に扱えるトークン数の上限のこと
-
和智 右桂
-
Python#Programming
-
Claude Code/サブエージェント#LLM Claude Codeにおいて、特定のタイプのタスクを処理するために用意する専門性を持った会話型エージェント .claude/agents ディレクトリ内でのファイル管理が可能で、初回ファイル生成は /agents コマンドの利用が推奨される https://docs.anthropic.com/ja/docs/claude-code/sub-agents
-
Claude Code/Plugins#LLM Claude Codeにおいて、以下のようなカスタム設定を共有、配布するような仕組み カスタムスラッシュコマンド サブエージェント Hooks MCP servers https://docs.claude.com/en/docs/claude-code/plugins#quickstart
-
DevSecOps#Security #Continuous Integration #Continuous Delivery DevOpsにセキュリティを統合したアプローチ ソフトウェア開発ライフサイクル(SDLC)の全段階にセキュリティを組み込む 主要な原則 シフトレフトセキュリティ 開発初期段階からセキュリティを考慮 自動化 CI/CDパイプラインへのセキュリティテストの統合 SAST / DAST の併用 コラボレーション 開発・セキュリティ・運用チームの協働 https://www.devsecops.org/
-
mise/Bootstrapmise の設定に沿ってマシンを1コマンドで宣言的にセットアップする機能(mise bootstrap)。各フェーズを冪等に収束させ、既に満たされていれば skip する 適用フェーズ: OS packages → git repos → dotfiles → shell activation → macOS defaults → LaunchAgents / systemd user units → login shell 等の user 設定 → tools → 最終 bootstrap task 各フェーズは config セクション([bootstrap.packages] [bootstrap.repos] [dotfiles] [bootstrap.macos.*] [bootstrap.mise_shell_activate] 等)に対応し、mise bootstrap <part>(packages / repos / dotfiles / macos …)で個別適用もできる 各フェーズの前後には hooks で任意コマンドを差し込める mise bootstrap status(alias ls)で sync 状態・drift を確認。主なフラグは --dry-run --yes --skip --only --force-dotfiles --update mise 未導入環境向けに導入スクリプトを生成する mise generate bootstrap とは別機能 https://mise.jdx.dev/bootstrap.html https://mise.jdx.dev/cli/bootstrap.html
-
GitOpsWeaveworks社によって提唱された、#Cloud Nativeの文脈においてgitを用いた設定管理を行うような#Continuous Delivery手法 対象は主にKubernetesとなる
-
テレメトリー#Observability ログ、分散トレース、メトリクスのようなシステムの状態に関するデータ Datadogのようなオブザーバビリティソリューションに送信される
-
ブルーグリーン戦略#Continuous Delivery リリース時に旧環境と新環境を同時に稼働させ、リバースプロキシ/ロードバランシング/APIゲートウェイ相当のポイントで旧環境から新環境へ完全に切り替えるリリース手法 旧環境をブルー、新環境をグリーンとする
-
Open API
-
スプリント#Agile 主にスクラムにおいて扱われる、タイムボックス化されたある期間のこと 1~2週間が多く、長くても1ヶ月にするにする
-
認証局CA #Security/Authentication 信頼されたデジタル証明書の発行者
-
BDD/定式化Formulation #Testing #Documentation BDDのプラクティスのひとつ。システムの振る舞いの具体例をメンバーが読みやすいシナリオの形で文書化する
-
クロスファンクショナルチーム#Team Organization 職能横断型で自己組織化されたチーム
-
Agile Testing#Agile #Testing DevOps
-
Kubernetes/OperatorCRDによるカスタムリソースとそれを操作するControllerを共に使うパターン Operator pattern | Kubernetes Kubernetes
-
Kubernetes/Labelリソースのメタデータとしてリソースを特定するために用いられる Labelにはインデックスが貼られるため高速な検索が可能 Kubernetes
-
Kubernetes/ServiceAccount
-
Kubernetes/Probe#Continuous Delivery Pod上で定期的に実行されるコンテナの診断、ヘルスチェック チェックの方法として以下の4つがある gRPC HTTP TCP Socket Exec 任意のコマンドを実行し、成功の返り値0を期待する Probeには戦略を示すようないくつかの種類が存在する Podのライフサイクル | Kubernetes Kubernetes
-
認知負荷個人やチームの認知容量に対する負荷のこと 認知負荷は3つに分類することができる 課題内在性認知負荷 問題領域のタスクの難易度に関する負荷、研修・技術選定・ペアプログラミング等で解消する 課題外在性認知負荷 タスクを実施する環境に関する負荷、#Continuous Integrationによる自動化等で解消する 学習関連負荷 知識の構築に関する負荷、学習によって増やすべき負荷とされる 情報過多にご用心!生産性の低下を招く「認知的過負荷」への対処法 ── 海の向こうからオピニオン その70 (1/2) - チームの教科書|アトラシアン株式会社
-
実例マッピングExample Mapping #Documentation Agile Testing、BDDで紹介されるプラクティス。Matt Wynneによって考えられた マッピングする付箋の種類には Story Rule Example Question の4種があり、あるStoryにおけるExample(具体例)を軸に、定められるRuleと残論点としてのQuestionをマッピングする
-
MVPMinimum Viable Product #Agile #Product Management 望まれる成果(アウトカム)を実現できる、最小のプロダクトのリリース。「最小」とは機能数の少なさではなく、仮説を証明・反証するための最小単位を指す。
-
YAML人間にとっての読みやすさを重視したデータ記述言語