Kush's Wiki

Sort by - linked count

• 計装
  #Observability テレメトリーをオブザーバビリティソリューションに送信するための実装のこと 前提としてエージェントをシステムに組み込んだ上で、アプリケーションエンドポイントへの自動計装や手動スパン埋め込み等のカスタム計装を行う
• Gaspar Nagy
  
• Google Cloud/

  Certificate Manager
  #Security Google Cloudにおいて外部ロードバランシングで必要となるようなTLS証明書を管理する Certificate Manager の概要 | Google Cloud
• Agile Conversation
  #Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。 自己開示: プロセスを隠さず失敗を認める 他者理解: 相手に関心を持ち立場を理解しようとする 組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果たす対話 重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。 アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
• QUIC
  #Network #HTTP インターネット上の通信で多く用いられてきた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ブロッキングのような問題の回避をする
• 成功循環モデル
  #Team Organization ダニエル・キムによる、チームや組織の成熟度は以下4つのサイクルで向上するというモデル 関係の質 思考の質 行動の質 結果の質
• 不確実性のコーン
  ソフトウェアの見積もりは初期の段階ほどばらつきが大きくなるという考え
• 逸脱の常態化
  誤検出されやすいモニタリングアラートに慣れてしまうこと チャレンジャー号の事故の調査から生まれた言葉 When Doing Wrong Feels So Right: Normalization of Deviance - PubMed
• flaky tests
  #Testing #Continuous Integration テスト実行において偽陽性として不安定に落ちるテストのこと
• オニオンアーキテクチャ
  
• Manuel Pais
  
• Spire
  #Programming #Security Scala言語の数値型ライブラリ。汎用的で高速かつ高精度な数値と、効率的な数値コードシンタックスを提供する。 Spire Introduction to Spire Numeric Programming in Scala with Spire JOTB19 - Numeric Programming with Spire by Lars Hupel
• Dynamoスタイル
  #Data Store DynamoDBによって流行したリーダーレスレプリケーションを実装したデータストアに用いられるスタイル名
• ADT
  Algebraic Data Type 代数データ型 #Programming 列挙（和）された値の組み合わせ（積）を定義し、無効な組み合わせを表現できないように型化する方法
• SoE
  System of Engagement 顧客との関係性を重視するシステム、ECサイト等が該当する
• ETL
  Extract transform load #Data Processing ETL とは? - 抽出、変換、ロードの説明 - AWS
• Book/

  SRE サイトリライアビリティエンジニアリング
  
• Shopifyはいかにしてモジュラモノリスへ移行したか
  #モジュラモノリス Shopifyはいかにしてモジュラモノリスへ移行したか - InfoQ
• カーディナリティ
  #Data Store あるカラムの値の集合の中に重複する値がどのくらいあるかの度合い。低いと重複が多く高いと重複が少ない。
• Finite State Machine
  有限ステートマシーン #Programming 状態管理を有限にし、あり得ない状態を作らないという考え
• サンクコストの誤謬
  プロジェクトや意思決定において、すでに投入しているリソースが高いと、成功数可能性が低い証拠があっても引き続きリソースを投入し続ける認知バイアス
• スクラム/

  5つの価値基準
  #スクラム スクラムガイドで紹介されている5つの価値基準 確約(Commitment) 集中(Focus) 公開(Openness) 尊敬(Respect) 勇気(Courage)
• スクラム/

  インクリメント
  #Agile スクラムの成果物として、動作するプロダクトのこと
• スクラム/

  経験主義の三本柱
  #スクラム 経験主義をベースにスクラムガイドで紹介されている三本柱 透明性 検査 適応
• トランザクション分離レベル
  #Data Store ACIDのうち、I（Isolation）について言及するような分離性のレベル。 RDBMS間で共通して4つの分離レベルがあるが、分離レベルの命名が異なるケースがあり曖昧になっている。 Read Uncommitted コミットされていない未確定のデータを読み取るダーティリードが発生する Read Committed ダーティリード、ダーティライトが生じない Snapshot Isolation OracleではSERIALIZABLE、PostgreSQLやMySQLではRepeatable Readと呼ばれるため曖昧 読み取りスキュー（nonrepeatable read）が生じない、読み取りはロックを取らず常にトランザクション開始時のスナップショットを参照する スナップショットとして複数のバージョンを保持するためMVCC（multi-version concurrency controll）の手法が用いられる Serializable 書き込みスキュー（ファントム）が生じない、複数のレコードを跨いだ一貫性を保証する ユニーク制約によって書き込みスキューを防止できない際に必要となる 全てのトランザクションが直列で実行されるように振る舞うことで直列化可能と呼ばれる
• Datadog/

  RUM
  Real User Monitoring #Observability Datadog上で個々のユーザーのアクティビティをリアルタイムで可視化する APMと紐づける（以下、詳細）ことでフロントエンドで収集したデータをバックエンドのトレースと相関づけて追跡できる Connect RUM and Traces RUM Explorerでは、ユーザーセッションを1レコードとした探索が可能 https://docs.datadoghq.com/ja/real_user_monitoring/
• Datadog/

  Feature Flag Tracking
  #Observability #Datadog RUMの機能の一つとして提供されるフィーチャーフラグ可視化ツール フーチャーフラグ単位のグルーピングを行うことで機能リリースを安全に、迅速なトラブルシューティングが可能になる Flagsmithのようないくつかのツールで統合が容易になっている https://docs.datadoghq.com/real_user_monitoring/feature_flag_tracking/
• Devin Search
  #LLM Devinと連携されたリポジトリに対して回答を得るAsk特化のAIアシスタント 検索対象は自動でインデックスされる https://docs.devin.ai/work-with-devin/devin-search
• ドメインイベント
  #ドメイン駆動設計 ドメイン イベント: 設計と実装 - .NET Domain Events and Eventual Consistency
• 技術的負債の4象限
  Technical Debt Quadrant Martin Fowlerが技術的負債が発生するケースを4象限で分類したもの。 Reckless（無謀） or Prudent（慎重） Deliberate（意図的） or Inadvertent（不注意） の2軸で分類する。 例えばリリース当初はクリーンなコードを書いていたつもりだが、1年後に本来正しかった設計が見つかった。のようなケースではPrudentかつInadvertentとなる Blog
• 関数型ドメインモデリング
  
• 要件定義
  #Documentation 「何を作ればよいのか」を明確にするために行う
• GraphQL
  
• 輻輳制御
  #Network TCPプロトコル等で行われるネットワークのリンク上でパケットが混線した際の制御 輻輳制御アルゴリズムは大きく以下の3つに分類される Loss-based Delay-based ハイブリッド型
• Open Container Initiative
  OCI 2015年にDockerとその他の業界リーダーによって作成された、コンテナ形式とランタイムに関するオープンな業界標準 具体的に以下の3つの仕様を持つ runtime-spec image-spec distribution-spec Linux Foundationプロジェクト Open Container Initiative - Open Container Initiative
• KEDA
  
• OWASP Top Ten
  #Security OWASP Foundationが発表するセキュリティ専門家によるトップ10に含まれるべき脆弱性リスト 定期的に更新されるため最新を追うべき https://owasp.org/www-project-top-ten/
• アジャイルソフトウェアの12の原則
  #Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則
• Martin Kleppmann
  
• RSA
  #Security 秘密鍵と公開鍵による暗号方式 署名に用いる際は公開鍵を用いて署名をした署名者のことを、秘密鍵によって署名付きトークンを検証できる RFC 8017 - PKCS #1: RSA Cryptography Specifications Version
• AuthorizationPolicy
  #Security #Authorization Istioにおいてアプリケーション（L7）認可の役割を担うリソース KubernetesのCustomResourceDefinitionによって用意されており、Network policyに比べ柔軟でHTTP特有の設定が可能 Istio / Authorization Policy
• HMAC
  Hash-based Message Authentication Code #Security 共有秘密鍵と暗号化ハッシュ関数による暗号方式 共有の鍵を有するので両者ともに署名付きトークンを生成・検証できる
• オブザーバビリティ・エンジニアリング
  
• SECIモデル
  知識を暗黙知と形式知に分けそれらが学習サイクルに表れる過程をモデル化したもの 以下の4つのフェーズを繰り返す 共同化（Socialization） 暗黙知から暗黙知。組織として共通の経験を積み重ねる 表出化（Externalization） 暗黙知から形式知。経験的知識の共通点や抽象的な構造をモデル化する 連結化（Combination） 形式知から形式知。複数の形式知から知識体系を作る 内面化（Internalization） 形式知から暗黙知。形式知を実践的に理解できた状態
• Bツリー
  #Data Store Bツリーはデータベースを固定サイズのブロックあるいはページに分割する。固定サイズの空き容量がない状態で新しいキーが追加される場合、半分の領域が空いた2つのブロックに分割される。 このアルゴリズムはツリーバランスが保たれ、ツリーの深さも3ないし4レベルに収まることがほとんど。 また信頼性を高めるためにwrite-aheadログ（WAL）と呼ばれる書き込み内容の構造化データを追記して保持している。 Wikipedia
• Honeycomb
  Observabilityに関するエンドツーエンドのプロダクト Retrieverというオブザーバビリティに最適化された独自のデータストアを備えており、S3によって実装されている Honeycomb.io Documentation | Honeycomb
• The Twelve-Factor App
  Software as a Serviceを作り上げるための方法論 The Twelve-Factor App （日本語訳）
• ダンバー数
  #Team Organization 組織の規模は150人までしか関係をうまく維持できないという理論 https://www.cambridge.org/core/journals/behavioral-and-brain-sciences/article/abs/coevolution-of-neocortical-size-group-size-and-language-in-humans/4290FF4D7362511136B9A15A96E74FEF
• 抽象化によるブランチ
  #Martin Fowler #Continuous Integration BranchByAbstraction
• Knative Serving
  Knativeにおいて、KubernetesのCustomResourceDefinitionによって4種類のリソースを定義しアプリケーションの提供を行う Serviceの別APIのようなサービスディスカバリパターン 4種類のリソースは以下 Services Routes Configurations Revisions https://github.com/knative/specs/blob/main/specs/serving/overview.md