Sort by - linked count
-
TypeScript#Programming #JavaScript
-
SRESite Reliability Engineering Webサービスの信頼性に対してソフトウェアエンジニアリングの手法を適用する分野
-
境界づけられたコンテキスト#Software Design 境界づけられたコンテキスト DDDにおいて、集約(モジュール)の集合に対して定めるドメインモデリング上の境界 以下、原著から抽出 モデルが適用されるコンテキストを明示的に定義すること。明示的な境界は、チーム編成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキーマなどの物理的な表現などの観点から設定すること。その境界内では、モデルを厳密に一貫性のあるものに保つこと。ただし、境界の外部の問題によって注意を逸らされたり、混乱させられたりするのを避けること。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P344
-
Kubernetes/Service
-
レートリミット#Security #API Architecture 以下のような目的でAPIの使用回数を制限する、制限を超過した時はHTTPの場合一般に429エラーを返す処理 STRIDEにあるようなDenial of Service(サービス拒否)からアプリケーションを保護する カスケード障害の可能性を制限する リソースの使用量を測定し従量課金に利用できる レートリミットの実装アルゴリズムには以下のようなものがある 固定ウインドウ(Fixed window) 固定期間内の制限 スライディングウインドウ(Sliding window) 直近の期間内の制限 トークンバケット方式(Token bucket) 総リクエスト数(トークンのバケツ)を定義しリクエストごとにトークンが利用される。バケツは定期的に充填される リーキーバケット方式(Leaky bucket) リクエストが処理される速度は固定で、バケツから溢れ出るリクエストを漏れ(リーキー)として扱う APIゲートウェイを利用している場合、ゲートウェイに配置するとよい
-
DoS攻撃Denial of Service #Security リソース(サイト、アプリケーション、サーバー)を本来の目的で利用不可にすることを目的とした攻撃。C-I-Aの可用性を侵害する ネットワークパケット操作、プログラム脆弱性の悪用、リソース枯渇など多様な手段で実行される 主な攻撃手法 メモリ枯渇(ユーザー指定オブジェクト割り当て、セッションデータ過剰蓄積) CPU負荷増加(ループカウンター制御、バッファオーバーフロー) リソース解放失敗(ファイルロック、DB接続の未解放) アカウントロックアウト機構の悪用 ネットワーク帯域幅の飽和 対策としてレートリミット、入力検証、冗長性確保、グレースフルデグラデーションなどがある
-
リレーショナルデータベース#Data Engineering
-
デジタル証明書#Security #Authentication 公開鍵と名前や住所等の識別情報を組み合わせることで、鍵の所有者を識別し正しい鍵であることを保証する証明書 認証局にデジタル署名をさせて発行される
-
モニタリング既知の障害状態に対してメトリクスを設定し、アラートを飛ばすようなリアクティブ(反応的)なシステム
-
エクストリームプログラミング#Agile
-
会話型エージェント#LLM
-
吉羽 龍太郎
-
Linux FoundationLinuxのようなオープンソースソフトウェアやテクノロジーを支援、促進、保護、標準化するコミュニティ https://www.linuxfoundation.org/
-
RBACRole-based access control #Authorization ロールごとに許可を定義する認可モデル これによりユーザーの部署異動等の際に即座に権限を変更できる
-
デジタル署名#Cryptography メッセージ送信者によるデジタル署名と、受信者による署名検証によって メッセージの改竄がされていないこと(完全性) メッセージが本当に秘密鍵を保持する送信者からのものであること(否認防止) の2つを保証する
-
SASTStatic Application Security Testing #Security #Testing ソースコード、バイトコード、バイナリを解析してセキュリティ脆弱性を検出するテスト手法 ホワイトボックステストとも呼ばれ、アプリケーションを実行せずにコードを分析する 特徴 DevSecOpsのシフトレフトを実現 CIパイプラインに統合可能 SQLインジェクション、XSS、バッファオーバーフロー等を検出 DAST(動的テスト)と組み合わせて使用されることが多い https://en.wikipedia.org/wiki/Static_application_security_testing
-
コンウェイの法則#Team Organization 1968年に提唱された法則 原文は以下 システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. https://www.melconway.com/Home/Conways_Law.html
-
RESTRepresentational State Transfer #API Architecture HTTPを基礎とするアーキテクチャ上の制約、定義 Architectural Styles and the Design of Network-based Software ArchitecturesにRESTfulとみなされるための定義が書かれている 第一にサービス提供者と利用者のやり取りがモデル化されていること、が定義となる
-
Java#[Programming]
-
ユーザーストーリー#Agile Whoとして、Whatをしたい。なぜならWhyだからだ のように Who What Why を含む形で書かれる、ユーザーにとっての価値を説明する文 INVESTであるストーリーが良いとされる
-
エリック・エヴァンスのドメイン駆動設計
-
カナリアリリースCanary Release #Continuous Delivery リリース時に旧環境と新環境を同時に稼働させ、一部のユーザーに絞って新環境を限定公開し徐々に移行していくことでパフォーマンス劣化等の問題がないかをテストするリリース手法 ブルーグリーン戦略との違いはトラフィックを徐々に切り替える点 Canary Release
-
逆コンウェイ戦略#Software Design #Team Organization コンウェイの法則に対して、開発チームの組織構造を変更して、望ましいソフトウェア設計を目指すという考え方 マイクロサービスが注目されるようになった2015年頃にコンウェイの法則が再評価され生まれた
-
オブジェクト指向プログラミングObject Oriented Programming #Software Design #Programming
-
ユーザーストーリーマッピング#Agile #Documentation ユーザーストーリーを洗い出すためのプラクティス 優先度付けや段階的なリリースのスコープ整理を行う Blog / Agile Studio
-
L4Layer 4 #Network OSI参照モデルにおける第4層の通称 トランスポート層を指し、TCPやUDPが代表的
-
市谷 聡啓
-
Scala#Programming
-
AnthropicLLMに関する事業を行うAI企業
-
OAuth2#API Architecture #Authorization RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー(Resource Owner) 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー(Resource Server) 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント(Client) リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー(Authorization Server) リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework
-
Robert C. Martin
-
OIDC
-
APIゲートウェイ#API Architecture #Network 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.
-
ユビキタス言語#Documentation #Software Design DDDにおいて、ドメインエキスパートと開発者、またその周辺のステークホルダーが共有する言語 以下、原著から抽出 モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P26-27 また同一の単語でも異なるユビキタス言語として定義するケースもあり、境界づけられたコンテキストを明示にした上で、どのコンテキストで用いる言語なのかを決定する
-
Eric Evans
-
E2EテストEnd to End Testing #Testing 組織のドメイン外にある外部システムを除いて実際に全てのサービスを動作させUIレベルで行うテスト 一般的な形式として1つまたは複数のユーザアクションに基づくシナリオテストがあり、テストコストが増えすぎないよう主要なシナリオにフォーカスして行う
-
可用性Availability #Security データを利用可能な状態に保つこと。大幅な遅延や不正なシャットダウンを許さない
-
プロンプトエンジニアリングLLMに対して入力(プロンプト)を調整し必要なタスクを実行するようにモデルを条件付けする取り組み
-
フィーチャーフラグ#Continuous Delivery ソフトウェアの機能のON/OFFを管理するフラグ、機能フラグと呼ばれることもある 簡易的な例だと環境変数を用いて管理される
-
技術的負債Technical Debt
-
リバースプロキシ#API Architecture #Network 外部トラフィックに対して単一のサーバーへルーティングを行い、サーバーの保護や負荷分散を行う役割
-
完全性Integrity #Security データを正確に管理する、不正な変更や削除を許さない
-
サーキットブレーカーアプリケーションが失敗する可能性のある操作を繰り返し試行するのを防ぐ信頼性パターン サーキット ブレーカー パターン - Azure Architecture Center
-
自己組織化#Team Organization チームまたは個人が外部に依存せず自律して意思決定をし行動できる度合い
-
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
-
TCPTransmission Control Protocol #Network L4にあたる通信プロトコル エンドデバイス間でコネクションを確立することで信頼性を向上させる データ送信は複数のパケットをシーケンス番号とともに送信し、パケットロスがないよう再送制御がされる
-
HTTPSHyperText Transfer Protocol Secure #Network #Security HTTPをTLSによって暗号化した通信
-
風間 裕也
-
Markdown#Documentation
-
SLOService level objectives SREにおけるサービスレベル目標の略。 サービスレベル指標(Service level indicators = SLI)に対してターゲットとする値または範囲を目標とする。 サービスレベル指標に用いられるのは主に以下のようなもの 可用性 リクエストレイテンシ エラー率 システムスループット サービスレベルアグリーメント(Service level agreement = SLA)は、SLOを守るまたは守れないケースに関する規定をユーザーと同意するもの。 SLO, SLI, SLAは定義が曖昧になりやすいので注意が必要