Sort by - linked count
-
YAML人間にとっての読みやすさを重視したデータ記述言語
-
GraphQL
-
Platform as a ProductPlatform Engineering Team Topologiesのプラットフォームチームがストリームアラインドチームに向けてプラットフォームを提供する際、X-as-a-Serviceによって実現する考え
-
Swarming#Agile #Team Organization 重要な領域または主要な活動に焦点を置いてチームのエネルギーを集中させる。バックログに課題を積むのは最後の手段である。 障害にチームメンバー複数人で集中して対処するイメージを日々のスプリントにも適用していく。
-
コンテキストウインドウLLMが一度に扱えるトークン数の上限のこと
-
Observability WhitepaperCNCFによる#Observabilityに関する文書 https://github.com/cncf/tag-observability/blob/main/whitepaper.md
-
否認防止#Security メッセージが送信または受信を攻撃者が否認した際に、否認できないように保証すること
-
メッセージブローカー#Data Engineering イベントストリーム処理において、Pub/Subの間に配置されイベントをキューイングする役割。 基本としてイベントをコンシューマーと1対1でやりとりし処理が完了したらイベントが削除される実装がある。 対しログベースのメッセージキューはコンシューマーと1対Nでやり取りし古いイベントのリプレイも可能である。 https://aws.amazon.com/jp/message-queue/
-
サイドカー#Cloud Native 1つのPod内で複数のコンテナを定義し、メインアプリケーションコンテナとそれを拡張するSidecarコンテナのような関係性を持たせるパターン
-
ADRArchitectural Decision Records #Documentation アーキテクチャに関する意思決定とその理由を記録する文書。意思決定に際する文脈、根拠、その決定による成果物等を記述する ADRはなぜそのアーキテクチャを選出したかの意思決定を理解するのを助ける。 ADRはチームメンバーの誰もが作成できる。ただしオーナーシップとしてAuthorは明確にする必要がある。初期ステータスは Proposed とする。 次に他チームメンバーによるレビューを行う。修正すべき点がある場合は Proposed のままアクションのアサインを行う。このときアサインはチームメンバーの誰でもよい。ADR自体はRejectする場合はステータスを Rejected にしADRのライフサイクルは終了する。 レビューを経て全てのアクションが完了した場合、ステータスを Accepted にする。一度AcceptされたADRはイミュータブルに扱い変更はしない。 Architectural Decision Records (ADRs) ADR process - AWS Prescriptive Guidance
-
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
-
kube-scheduler
-
DevSecOps#Security #Continuous Integration #Continuous Delivery DevOpsにセキュリティを統合したアプローチ ソフトウェア開発ライフサイクル(SDLC)の全段階にセキュリティを組み込む 主要な原則 シフトレフトセキュリティ 開発初期段階からセキュリティを考慮 自動化 CI/CDパイプラインへのセキュリティテストの統合 SAST / DAST の併用 コラボレーション 開発・セキュリティ・運用チームの協働 https://www.devsecops.org/
-
DDD/エンティティ#Software Design DDDにおいて同一性を持つオブジェクトの呼び名 原文は以下 オブジェクトの中には、主要な定義が属性によってなされないものもある。そういうオブジェクトは同一性のつながりを表現するのであり、その同一性は、時間が経っても、異なるかたちで表現されても変わらない。そういうオブジェクトは属性が異なっていても、他のオブジェクトと一致しなければならないことがある。また、あるオブジェクトは、同じ属性を持っていたとしても、他のオブジェクトと区別しなければならない。同一性を取り違えるとデータの破損につながりかねない。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P89
-
DDD/集約#Software Design DDDにおいて不変条件を適用するエンティティや値オブジェクトのようなオブジェクトのグループ単位 原文は以下 エンティティと値オブジェクトを集約の中にまとめ、各集約の周囲に境界を定義すること。各集約に対してルートとなるエンティティを1つ選び、境界の内部に存在するオブジェクトへのアクセスはそのルートを経由して制御すること。外部のオブジェクトが参照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を渡してよいのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するので、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて強制することが現実的になる。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P127
-
Internal Developer PlatformPlatform Engineering プラットフォームチームが内部開発者向けに提供するプラットフォーム 以下の5つのコンポーネントを網羅するように設計すべきとされている アプリケーションの構成管理 インフラストラクチャのオーケストレーション 環境の管理 デプロイメントの管理 ロール単位のアクセス制御 https://internaldeveloperplatform.org/
-
Progressive Deliveryバージョンアップデートを段階的に行うようなデプロイメント戦略を適用した上で、デプロイ結果を分析し漸進的にデプロイの継続かまたはロールバックかを自動化するようなデリバリ手法 #Continuous Deliveryの進化系として紹介されることが多い https://argo-rollouts.readthedocs.io/en/stable/concepts/#progressive-delivery
-
スプリントプランニング#Agile スクラムのスプリントの起点となるイベント。最新のスクラムガイドより抜粋 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
-
テストピラミッド
-
Dan North
-
Prometeus
-
Facebook
-
最小権限の原則Principle of Least Privilege #Security ユーザーやプロセスに対して、その役割を遂行するために必要な最小限の権限のみを付与する原則 不要な権限を排除することで攻撃面を削減し、セキュリティ侵害時の影響範囲を制限する
-
DID分散型識別子 #Security/Authentication 暗号識別子の一種である。W3Cの分散型識別子ワーキンググループによってDID仕様が定義される 以下のような特性を持つ 再割り当て不可 解決可能 DIDメソッドを元にしたDIDドキュメントの取得 所有権の証明 デジタル署名 非集中型 URIとして表現され、以下例のような構文になる did:example:123456789abcdefghij did スキーム部、 did で固定 example メソッド部 123456789abcdefghij メソッド固有識別子部 https://www.w3.org/TR/did-1.0/
-
Continuous Testing#Testing
-
VS CodeVisual Studio Code #Programming Microsoftが開発しているオープンソースのIDE
-
Kubernetes/Job
-
Kubernetes/Network policy
-
Kubernetes/Role
-
Kubernetes/Secret
-
Kubernetes/ConfigMap
-
kube-proxy
-
Will Larsonhttps://lethain.com/about/ 人物
-
ストーリー#Agile Kent BeckがXPで提唱した、ソフトウェアの要求を会話のきっかけとして扱う単位。カードに短く書くのは約束ごとを思い出すための覚書であり、詳細は会話で埋めることを前提とする。
-
インセプションデッキ#Agile #Product Management #Team Organization 10個のアジェンダをチームおよび関係者で答えていくワーク われわれはなぜここにいるのか エレベータピッチ パッケージデザイン やらないことリスト ご近所さんを探せ 技術的な解決策 夜も眠れない問題 期間を見極める トレードオフスライダー 何がどれだけ必要か 日本語のテンプレートは以下にある https://github.com/agile-samurai-ja/support
-
公開鍵#Security/Cryptography 暗号方式において、全世界に公開される前提の鍵を指す
-
AWSAmazon Web Service
-
npm#Programming JavaScript ソフトウェアの公開レジストリと、それを扱う CLI / Website の総称。公式は "the world's largest software registry" を称する 3 つのコンポーネント Website — パッケージ検索・閲覧の UI CLI — インストール / 公開などローカルから操作するコマンド Registry — パッケージとメタ情報の公開データベース https://www.npmjs.com/ https://docs.npmjs.com/about-npm
-
INVEST#Agile #Product Management 作業バッチサイズを最小化させるための観点の頭文字を略称にしたもの Independent Negotiable Valuable Estimable Small Testable
-
公開鍵暗号#Security/Cryptography 公開鍵と秘密鍵の鍵ペアによって実現する暗号方式。 以下の2パターンによって暗号化、復号が行われる 送信者:公開鍵でメッセージを暗号化、受信者:秘密鍵で復号 可逆的:機密性、完全性、否認防止 送信者:秘密鍵でメッセージを暗号化、受信者:公開鍵で復号 デジタル署名/署名検証 不可逆的:完全性、否認防止
-
脅威モデリングThreat Modeling #Security アプリケーションに影響を与える脅威、攻撃、脆弱性、対策を特定する技術 モデリング手法として5つのステップを繰り返すよう紹介している Defining security requirements. Creating an application diagram. Identifying threats. Mitigating threats. Validating that threats have been mitigated. https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling
-
ベロシティ#Agile
-
ペアプログラミング#Programming 1台のマシンで2人が協力してタスクに取り組む
-
サーバーレス開発者がサーバーの管理を気にすることなくアプリケーションの構築と実行を可能にする#Cloud Nativeな開発モデル Serverless | Cloud Native Glossary
-
Four KeysDORAによって提唱されるソフトウェアデリバリのパフォーマンス指標 名前の通り4つの尺度を追跡する デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 State of DevOps Reportでは、以上の4つの尺度を用いて、 Elite High Medium Low の4つに分類した ハイパフォーマーは全ての尺度での計測結果が抜きん出ており、スピードと品質にトレードオフ関係がないことを指し示した https://github.com/dora-team/fourkeys?tab=readme-ov-file
-
Datadog/APMApplication Performance Monitoring #Observability Datadog上で分散トレースによってアプリケーションを詳細に可視化し、パフォーマンスボトルネックを特定するのに役立てる 設定方法は以下 アプリケーションインスツルメンテーション APM
-
アカウントロックアウト#Security/Authentication 一定回数の不正なパスワード入力後にアカウントを一時的または永続的にロックするブルートフォース攻撃対策 主な問題点 DoS攻撃の標的になりやすい(攻撃者が大量のアカウントをロック可能) ユーザー名の列挙が可能(存在するアカウントのみがロックされる) ヘルプデスクへの負担増加 低速攻撃や複数ユーザー対象の攻撃に無効
-
BDD/具体例Example #Testing BDDプロセスの中で、求められるシステムの振る舞いを表現したもの。 コンテキスト、アクション、結果の構造を持ち、Gherkin形式で書くこともできる
-
アジャイルテストの4象限
-
Non-root User主にDockerfileなどにおいて、非rootユーザーでのログインを推奨する#Securityベストプラクティス Dockerfile ベストプラクティス docker-node/docs/BestPractices.md at main · nodejs/docker-node