Sort by - linked count
-
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/
-
サービスディスカバリアプリケーションサービスを公開する際、クラウドネイティブなコンテナアプリケーションをステートレスに扱うようなケースで、アプリケーションの場所(IPアドレス)を容易に提供するためのパターン
-
Helm
-
テストダブル#Testing 自動テストに使用する代用品のこと、モックと呼ばれるようなものの総称
-
Kubernetes/Role
-
Kubernetes/PersistentVolume
-
Kubernetes/Initコンテナ#Kubernetes #Cloud Native Podと一緒に定義可能な初期化を行うコンテナ サイドカーでも同挙動は実現可能だが、ただ一度のみ実行されるのでリソースを調整しやすい Initコンテナ Init Containers | Kubernetes
-
Kubernetes/Namespace#Kubernetes 1つのクラスタ内に存在するリソース群を名前空間として分離することができる機能 Deployment,Serviceなどは名前空間内に配置できるが、PersistentVolumeなどはクラスタ全体に適用されるため名前空間内に配置できない Namespaces | Kubernetes
-
Kubernetes/Network policy
-
Kubernetes/Liveness Probe#Kubernetes Probeに失敗するとコンテナを再起動する livenessProbeをいつ使うべきか? HTTPリクエストによるLiveness Probeを定義する
-
Kubernetes/Readiness Probe#Kubernetes Probeに失敗するとトラフィックを受け取らないようにし、アプリケーションが自分自身で復帰するのを期待する readnessProbeをいつ使うべきか? Readiness Probeを定義する
-
Kubernetes/Gateway API#API Architecture #Network #Kubernetes #Cloud Native L4/L7を扱うKubernetes公式のAPIゲートウェイ GatewayClass Gateway HTTPRoute の3つを定義し実装する GatewayClassはGKEのようなクラウドサービスが用意するケースがあり、外部or内部を選択できる Introduction - Kubernetes Gateway API
-
ストラングラーフィグアプリケーションStranglerFigApplication #Continuous Integration Martin Fowlerによる理論。既存のシステムを置き換える際、既存のシステムの周辺に新規のシステムを追加していき段階的に置き換える。 イチジクの成長段階に似ていることからFigの命名を含んでいる。 原文はこちら
-
Buf
-
カンバン#Agile
-
Cucumber#Testing BDDを推進するメインコミュニティであり、そのコミュニティによるライブラリ。RSpecのコントリビューターであるAslak Hellesøyによって立ち上げられた Gherkin記法で書かれたfeatureファイルをStep definitionsによってテストコードへ変換し実行する 公式では以下の言語をサポートしている Installlation Java JavaScript Ruby Kotlin Scala Lua Ocaml C++ Go https://cucumber.io/docs/
-
CLICommand Line Interface
-
SMSSecret Management System #Security Secretの保存とアクセスを行うAPIを提供する、Secretをユーザが扱う段階では常に暗号化された状態になる
-
OpenTelemetry/Collector#Observability OpenTelemetryにおいてDatadog, Jaeger, Prometeusのような各種バックエンドへのテレメトリー送信を集約し抽象化するような役割 https://opentelemetry.io/docs/collector/
-
スプリントレビュー#スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。 検査、適応を行うためのイベント
-
トランクベース
-
BDD/定式化Formulation #Testing #BDD #Documentation システムの振る舞いの具体例をメンバーが読みやすいシナリオの形で文書化する
-
Seb Rose
-
DV証明書#Security 組織が当該ドメインを制御(domain validation)していることを認証局が証明するデジタル証明書
-
Tom DeMarco#Person
-
リーダーレスレプリケーション#Data Store AmazonがDynamoシステムで利用し流行しDynamoスタイルと呼ばれる。 一部のノードが何らかの理由で利用できなくてもクオラムによって読み取りあるいは書き込みの正当性を判断する
-
Devin#LLM Cognition社によるソフトウェアエンジニアを模した自律型会話型エージェント https://docs.devin.ai/get-started/devin-intro
-
Ward Cunningham
-
プロダクトバックログ#Agile プロダクトに必要とされるもののリスト、優先度順に並べる
-
ゴールデンサークル#Agile TEDの優れたリーダーはどうやって行動を促すかによって初めて解説された考え 円の中心から Why What How の順に並ぶ Howが一番外側にあるが優先度が低いというわけではなく、HowによってWhatに大きな影響を与えるケースもある
-
Container Network InterfaceCNI #Cloud Native #Network LinuxおよびWindowsコンテナにおける、ネットワークインターフェースを構成するプラグインを作成するための仕様とライブラリ、およびサポートされているプラグイン CNCF project https://www.cni.dev/
-
two-pizza team#Team Organization 「私たちはチームの規模を、ピザ 2 枚で賄える人数以下に抑えることにしています」とベゾスは述べています。「これを 2 枚のピザチームのルールと呼んでいます。」 Amazonに浸透する1チームの規模の考え 2 枚のピザチーム - AWS での DevOps の概要
-
メッセージダイジェスト#Security メッセージの完全性を示す数学的手法、暗にハッシュと呼ばれることもある 不可逆 ハッシュ化された文書は元の文書に戻せない 非相関 元の文書の小さな変更が、ハッシュ化された文書では大きな変更となる 一意 同じメッセージダイジェストを生成する2つの文書は数学的に存在しない 最も一般的な使用法は、パスワードの安全な保存である
-
コントラクトテストContract Testing #Testing API提供者とAPI利用者間のやり取りの定義をコントラクトとして扱い、スタブサーバ等を用意することで各システムが独立してテストできるようになるテスト手法。依存するシステムが増えうるマイクロサービスの文脈で適用されることが多い 全てのシステムを統合するE2Eテストと異なりテストの実行が軽量でありメンテナンス容易であるといった利点を持つ What is Contract Testing & How is it Used? | Pactflow
-
C-I-A#Security 機密性(Confidentiality) 完全性(Integrity) 可用性(Availability) の頭文字を取ったセキュリティの3つの柱
-
VS CodeVisual Studio Code #Programming Microsoftが開発しているオープンソースのIDE
-
Book/チームトポロジー
-
イネイブリングチーム#Team Organization Team Topologiesにて紹介される4つのチームタイプの内の1つ 他のチームを技術等の知識によって支援する
-
Claude Code/Plugins#LLM Claude Codeにおいて、以下のようなカスタム設定を共有、配布するような仕組み カスタムスラッシュコマンド サブエージェント Hooks MCP servers https://docs.claude.com/en/docs/claude-code/plugins#quickstart
-
アカウントロックアウト#Security #Authentication 一定回数の不正なパスワード入力後にアカウントを一時的または永続的にロックするブルートフォース攻撃対策 主な問題点 DoS攻撃の標的になりやすい(攻撃者が大量のアカウントをロック可能) ユーザー名の列挙が可能(存在するアカウントのみがロックされる) ヘルプデスクへの負担増加 低速攻撃や複数ユーザー対象の攻撃に無効
-
スプリントプランニング#スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認する。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよい。
-
MFAMulti Factor Authentication 多要素認証 #Security #Authentication
-
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
-
松浦 隼人
-
Argo CD
-
スクラム/適応Adaptation #スクラム #Agile 最新のスクラムガイドより抜粋 プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
-
スクラム/検査Inspection #スクラム #Agile 最新のスクラムガイドより抜粋 スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5 つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
-
DockerfileDockerにおいてイメージの構成を記述するファイル IaCとして機能する https://docs.docker.jp/engine/reference/builder.html
-
SAMLSecurity Assertion Markup Language #Security #Authentication XMLベースの認証・認可データ交換標準規格。IdPとSP(Service Provider)間で認証情報をやり取りし、SSO(Single Sign-On)を実現する。 https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
-
IDLInterface Definition Language #Programming