Kush's Wiki

3wayハンドシェイク

#Network TCPプロトコルにおけるコネクションの確立手法、名前の通り3ステップでコネクションを確立する 送信元でTCPヘッダー内のSYN（コネクションの確立要求）フラグを有効化しセグメントを送信 送信先で1に対するACKとSYNフラグの有効化をしたセグメントを返信 送信元で2のSYNに対するACKのセグメントを送信

MapReduce

#Derived Data Unixのプロセスと同様の特徴を持つ分散ファイルシステム上のバッチ処理フレームワーク。 MapReduceジョブは以下の2つに分かれる Mapper 分散ファイルシステムの各レコードからキーと値のコレクションを抽出する Reducer mapperによって生成されたキーと値のコレクションからコレクションに対するイテレータとともに関数を適用し出力レコードを適用する HadoopのMapReduce実装ではHDFS(Hadoop Destributed File System)と呼ばれる分散ファイルシステムが用いられる

Vaughn Vernon

Janet Gregory

RSA

#Security 秘密鍵と公開鍵による暗号方式 署名に用いる際は公開鍵を用いて署名をした署名者のことを、秘密鍵によって署名付きトークンを検証できる RFC 8017 - PKCS #1: RSA Cryptography Specifications Version

Kubernetes Volume

#Cloud Infrastructure KubernetesにおいてPod内のコンテナがクラッシュした際のファイル復元や、コンテナ間のファイル受け渡しをしたいケースで用いられる Docker Volumeよりも管理十分で多くの機能を利用できる AWS EBS等のいくつかのボリュームの種類をサポートしている ボリューム | Kubernetes

QUIC

#Network インターネット上の通信で多く用いられてきたTCPの課題を解消する、Googleが開発したプロトコル UDPをベースし、コネクション確立によるRTTの増大を防ぎつつ、TCPと同様の高い信頼性の実現、TLSを必須とするセキュリティの考慮がされる。 HTTP/3で用いられるプロトコルで高速なHTTPS通信を実現する　 コネクションID QUICではIPアドレス、ポート番号を抽象化する形で宛先、送信元に対応するコネクションIDが用いられる。 コネクションIDによりモバイル機器のようなWiFi・モバイルデータ通信等が頻繁に切り替わりIPアドレスの変更がある場合でも、コネクションを途切らせずに通信を続けられる。 QUICヘッダー QUICヘッダーはTCPと異なり明確にロングヘッダー、ショートヘッダーの2つに分類される。ロングヘッダーはコネクション確立時、ショートヘッダーはその後のデータ送信に用いられる ロングヘッダーはコネクション確立に必要な情報をまとめて送る（1-RTTハンドシェイク）ことでRTTの改善がされる ストリーム QUICでは順序制御や再送制御を管理する単位としてストリーム（ID）という概念を用いる。ストリーム同士は独立しておりHoLブロッキングのような問題の回避をする

Bearerトークン

#Security トークンを保持するBearer（持参人）が誰であれ、そのトークンをリソースへのアクセスに使うことができる 平文の文字列でシークレットや署名は扱わず、セキュリティはTLSのようなトランスポート層での仕組みに任せている HTTP通信のAuthorizationヘッダーに付与するのを推奨されている RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage

ユーザーストーリーマッピング

#Agile Blog / Agile Studio

Kubernetes Job

#Cloud Infrastructure KubernetesにおいてPodを1つ以上作成し、作成したPodがJobとして正常終了するまで再試行をすることができる。 .spec.completions, .spec.parallelism の指定によって並列実行の制御をすることも可能 Job | Kubernetes

Martin Kleppmann

レプリケーション

#Database 書き込みまたは読み取りをリーダー、読み取りをフォロワーで行われ、リーダーへの書き込みがフォロワーに伝播される仕組みをレプリケーションと呼ぶ。 レプリケーションの方法として ステートメントベース write-aheadログ 等がある。 ステートメントベースはSQLをそのまま転送する形になるため副作用を持つ関数が返す結果にズレが生じる方法で、MySQL5.1以前に採用されていた。 write-aheadログはPostgreSQL,Oracleで使用されているが、ログが低レベルに記述されているため詳細実装と密になってしまう。 その他レプリケーションのトポロジーとしていくつかのパターンがある マルチリーダーレプリケーション 複数のデータセンターにリーダーが存在する。リアルタイムの同時編集がイメージに近い。 書き込みの衝突があった際に最終的に同じ値に収束させるような方法が取られる リーダーレスレプリケーション AmazonがDynamoシステムで利用し流行しDynamoスタイルと呼ばれる。 一部のノードが何らかの理由で利用できなくてもクオラムによって読み取りあるいは書き込みの正当性を判断する

ヘキサゴナルアーキテクチャ

JWT

JSON Web Token #Security トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる（署名がない場合3つ目のセクションは空） それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっている ヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いる ペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。 例として　iss（発行者）、sub（対象者）、exp（有効期限）などがある 署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)

Basic認証

#Security HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う

仮説検証型アジャイル開発

#Agile #市谷聡啓 Blog

サービスの信頼性の階層

Elastic Load Balancing

#Cloud Infrastructure トラフィックを複数のコンピュートリソースにルーティングし分散させ、システムの可用性向上、フォールトトレランスを行うサービスの集まり リソースごとに以下のような種別がある Application Load Balancer Network Load Balancer Gateway Load Balancer What is Elastic Load Balancing? - Elastic Load Balancing

ストラングラーフィグアプリケーション

StranglerFigApplication #Agile Martin Fowlerによる理論。既存のシステムを置き換える際、既存のシステムの周辺に新規のシステムを追加していき段階的に置き換える。 イチジクの成長段階に似ていることからFigの命名を含んでいる。 原文はこちら

クリーンアーキテクチャ

Scott Wlaschin

HMAC

Hash-based Message Authentication Code #Security 共有秘密鍵と暗号化ハッシュ関数による暗号方式 共有の鍵を有するので両者ともに署名付きトークンを生成・検証できる

広木大地

契約による設計

#OOP 契約による設計事始め

オニオンアーキテクチャ

Amazon S3

Amazon Simple Storage Service #Cloud Infrastructure AWSが提供するオブジェクトストレージサービス What is Amazon S3? - Amazon Simple Storage Service

メッセージキュー

#Derived Data イベントストリーム処理において、Pub/Subの間に配置されイベントをキューイングする役割。 基本としてイベントをコンシューマーと1対1でやりとりし処理が完了したらイベントが削除される実装がある。（Amazon SQS等） 対しログベースのメッセージキューはコンシューマーと1対Nでやり取りし古いイベントのリプレイも可能である。（Amazon Kinesis Stream等） メッセージキューとは何ですか?

レポーティングデータベース

#Martin Fowler #Database アプリケーションのドメインモデルに対応するテーブルとは別にレポート目的の中間テーブルを用意することで、レポートの関心を分離してテーブルに変更を加えることができる。 ReportingDatabase

DNSラベル標準

#Network RFC 1123で定義されているDNSに指定可能な文字列

輻輳制御

#Network TCPプロトコル等で行われるネットワークのリンク上でパケットが混線した際の制御 輻輳制御アルゴリズムは大きく以下の3つに分類される Loss-based Delay-based ハイブリッド型

Agile Conversation

#Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。 自己開示: プロセスを隠さず失敗を認める 他者理解: 相手に関心を持ち立場を理解しようとする 組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果たす対話 重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。 アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

モノリスからマイクロサービスへ

Bツリー

#Database Bツリーはデータベースを固定サイズのブロックあるいはページに分割する。固定サイズの空き容量がない状態で新しいキーが追加される場合、半分の領域が空いた2つのブロックに分割される。 このアルゴリズムはツリーバランスが保たれ、ツリーの深さも3ないし4レベルに収まることがほとんど。 また信頼性を高めるためにwrite-aheadログ（WAL）と呼ばれる書き込み内容の構造化データを追記して保持している。 Wikipedia

RPC

Remote Procedure Call リモート上のリクエスト発行をプログラミング言語の関数呼び出しのように利用できるよう抽象化したもの。 ただし実際に関数呼び出しと同等に利用できるわけではなく、ネットワーク上の様々な不測の事態を考慮する必要がある。 Protocol Buffersを使ったRPCフレームワーク実装としてgRPCが存在する。RPCフレームワーク群はネットワーク処理をカプセル化しており、gRPCの場合ストリームをサポートしている。 gRPC

GM Weinberg

#Person

ドメインイベント

#DDD ドメイン イベント: 設計と実装 - .NET Domain Events and Eventual Consistency

モジュラモノリス

#Software Design Shopifyはいかにしてモジュラモノリスへ移行したか モジュラモノリスで表現する複雑なドメイン領域と境界

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

#DevOps Slideshare

関数型ドメインモデリング

Authorization to implement with Extensible Effect

#Security #Eff

テスト駆動開発

Introduction to safe programming with numeric library

数値ライブラリで始める安全なプログラミング #Functional Programming Scala Matsuri 2024での自身の発表 Spireライブラリを用いて安全な数値計算を行うテクニックを紹介している

LeanとDevOpsの科学

A Mess is not a Technical Debt

Robert C. Martinによるブログ 技術的負債は戦略的に適用されるものであり、ただのクリーンでないコードに対して用いる概念ではない。という主張 負債が増えるのを意図的に捉えテストやリファクタリングを拡充すべきとしている Clean Coder - A Mess is not a Technical Debt.

テスト駆動開発の定義

アドレナリンジャンキー

アジャイルソフトウェアの12の原則

#Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則

Kubernetes Secret

#Cloud Infrastructure #Security KubernetesにおいてPodとは別に独立して機密情報を定義する 具体的にはKubernetes Volumeにファイルとして置かれるケースがある Secret | Kubernetes

kustomize

#Cloud Infrastructure Kubernetesの設定ファイルをyamlで記述する際、環境ごとに共通化できる設定（base）、環境ごとの差分設定（overlays）を扱い、設定ファイルの記述を最低限にすることができる機能 Declarative Management of Kubernetes Objects Using Kustomize | Kubernetes

The BDD Books - Discovery