Kush's Wiki

Sort by - linked count

• リチャードソン成熟度モデル
  #API Architecture Leonard RechardsonによるREST APIの観点からAPI実装の成熟度をレベルに分類したもの 各レベルのタイトルは以下 レベル0 HTTP/RPC レベル1 リソース レベル2 動詞（メソッド） レベル3 ハイパーメディアコントロール QCon 2008での発表は以下 Justice Will Take Us Millions Of Intricate Moves
• Scott Wlaschin
  
• オブザーバビリティ・エンジニアリング
  
• SHA
  Secure Hash Algorithms #Security/Cryptography デジタル署名の改竄防止等で最もよく利用されているハッシュ化アルゴリズム。生成される固定長のハッシュ値はメッセージダイジェストと呼ばれる 異なる元データから同一のハッシュ値が生成される可能性が低いことを求められ、SHA-2, SHA-256 等の種類がある RFC 6234 - US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
• 列挙型
  #Programming 排他な値の集合を列挙し、文字列や数値のエイリアスを指定できる
• Elastic Load Balancing
  #Cloud Native #API Architecture AWSが提供するロードバランシングコンポーネント リソースごとに以下のような種別がある Application Load Balancer Network Load Balancer Gateway Load Balancer What is Elastic Load Balancing? - Elastic Load Balancing
• FinOps
  #Cloud Native #Team Organization クラウドの財務管理を行う運用フレームワークおよび文化的プラクティス Finance と DevOps を組み合わせた造語で、エンジニアリング・財務・ビジネスチームの協働を促進する 3つのフェーズ Inform: クラウド支出データの収集・分析によるコスト可視化 Optimize: リソースの適正化や予約インスタンス活用による最適化 Operate: ガバナンスポリシーの実装と継続的モニタリング 主要な原則 チーム間のコラボレーション ビジネス価値が技術的意思決定を駆動 全員がクラウド利用に責任を持つ データはアクセス可能でタイムリーかつ正確に FinOps FoundationはLinux Foundationがホストする非営利団体 https://www.finops.org/
• Agile Conversation
  #Agile Agile Covnersation では人間中心主義での2つの価値観を原則としている。 自己開示: プロセスを隠さず失敗を認める 他者理解: 相手に関心を持ち立場を理解しようとする 組織が高パフォーマンスを発揮するためにはどのような対話をするべきか、5つの対話ステップが紹介されている。 信頼を築く対話 不安を乗り越える対話 WHYを作り上げる対話 コミットメントを行う対話 説明責任を果たす対話 重要なのはこれらは段階的に踏んでいくステップでありそれぞれ独立していないこと。第1ステップの「信頼を築く対話」はその後のステップの基礎となる。 アジャイルソフトウェア開発宣言 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
• Terraform/

  github_organization_ruleset
  #Continuous Integration Terraform GitHub provider の resource で、org 単位の ruleset を宣言する。conditions の repository_name(include/exclude) または repository_id で対象 repo 群を絞る。 rules に各種ルールを宣言でき、特に org/enterprise 専用の required_workflows（require workflows）を扱えるのが repo 単位版との違い https://registry.terraform.io/providers/integrations/github/latest/docs/resources/organization_ruleset
• llms.txt
  #Documentation WebサイトのコンテンツをLLMが効率的に利用するための提案標準。Jeremy Howard（Answer.AI）が2024年に提案 サイトルートにMarkdown形式で /llms.txt を配置しLLM向けの構造化された目次を提供する コンテキストウインドウの効率的な活用のためHTMLのノイズを排除する https://llmstxt.org/
• Beyond the Twelve-Factor App
  #Software Design #Cloud Native #Security/Authentication #Security/Authorization The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 #API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 #Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication / Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app
• Kubernetes/

  Downward API
  Podのメタデータを環境変数を通じてコンテナに渡すようなケースで利用できるAPI Downward API | Kubernetes Kubernetes
• Kubernetes/

  PodDisruptionBudget
  PDB 定常的に使用可能にしたいPod数を指定するような仕組み シングルトンなServiceを構築するようなケースで常に1台を使用可能にする、といった用途がある Disruption | Kubernetes Kubernetes
• Kubernetes/

  Immutable Configuration
  Kubernetesの設定管理において、設定ファイルを隠蔽する専用のコンテナを用意し、Initコンテナと emptyDir を組み合わせることでアプリケーションコンテナに設定ファイルをロードさせるパターン ConfigMapと異なり、設定ファイルのコンテナイメージバージョン管理によってイミュータブルに扱うことができる
• Kubernetes/

  Taints and Tolerations
  kube-schedulerにおいて、Node affinityのようなPodに対する設定ではなくNodesに対する設定によってPodの配置を決定する Taints and Tolerations | Kubernetes Kubernetes
• Kubernetes/

  Topology Spread Constraint
  kube-schedulerにおいて、Inter-pod affinity and anti-affinityでは解決できないようなRolling Update時の不均等なPod配置を許容する Pod Topology Spread Constraints | Kubernetes Kubernetes
• Kubernetes/

  RoleBinding
  
• Kubernetes/

  StatefulSet
  
• Kubernetes/

  Headless Service
  Serviceの定義方法の一つ clusterIP .spec.clusterIP を "None" に指定することで、PodのIPを直接参照するような設定にしkube-proxyはServiceに関与しなくなる Service | Kubernetes Kubernetes
• Kubernetes/

  CronJob
  
• Kubernetes/

  ClusterRoleBinding
  
• Kubernetes/

  Annotation
  Labelの利用がそぐわないケースで代替となるメタデータの指定方法、ツールやライブラリからパラメータのように利用されることを想定している Labelと異なりインデックスはされない Kubernetes
• Kubernetes/

  DNS
  #Network KubernetesにおけるDNS。PodとServiceをスケジューリングし、Service名によってURIを解決できる https://kubernetes.io/ja/docs/concepts/services-networking/dns-pod-service/
• App Router
  #Programming Nextjs 13.4で安定版となったルーティングシステム React Server Componentsをデフォルトでサポートし、app/ディレクトリでファイルシステムベースのルーティングを行う https://nextjs.org/docs/app
• Agent Skills
  #LLM 会話型エージェントへ手続き的知識（ワークフロー・スクリプト・参照資料）をパッケージして与えるAnthropic社発のオープン標準 frontmatter（name / description）と指示本文からなる SKILL.md を含むフォルダとして配布される Progressive disclosure が核: 常駐するのは name / description のみで、本文はタスク合致時、同梱ファイルは参照時に初めて読み込まれコンテキストを節約する https://agentskills.io/
• ゴールドスタンダード
  #Security/Authentication #Security/Authorization ゴールドスタンダード（Gold Standard）は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証（Authentication）: ユーザーが本人であることを証明 認可（Authorization）: 認証されたユーザーの行動の許可・拒否を決定 監査（Auditing）: システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/
• Nix
  #Programming パッケージを「副作用のない関数の出力」として扱い、ビルド後は不変とする purely functional な package manager 各パッケージは /nix/store 配下に置かれ、パス名は build dependency graph 全体の暗号学的ハッシュで決まる（content-addressed） ビルドは deterministic（同じ式を 2 回ビルドすれば同じ結果になる） 上書きせず別パスに追加するため upgrade / rollback が atomic で、旧バージョンが残る 複数バージョンを同時に併存でき、依存衝突（"DLL hell"）を避けられる https://nix.dev/manual/nix/stable/introduction
• アジャイルソフトウェアの12の原則
  #Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則
• Introducing Example Mapping
  Matt Wynneによる実例マッピングのアイディアが生まれたブログ、以下は風間 裕也による翻訳記事 https://nihonbuson.hatenadiary.jp/entry/ExampleMapping
• MVPe
  Minimum Viable Product experiment #Agile #Product Management Jeff Pattonが、エリック・リースのMVPを「実験」として捉え直して呼んだ語。何かを学ぶために作れる最小のもので、ターゲット顧客にとって本当にViableなものは何かを理解するための実験を指す。
• 3つのC
  #Agile Ron Jeffriesが示した、ストーリーを構成する3つの要素。カード（Card）に書き、会話（Conversation）で詳細を詰め、確認（Confirmation）で完了条件を定める。カードは要求仕様書ではなく、会話を思い出すための覚書であることを示す。 https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
• ダンバー数
  #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
• 合成監視
  Synthetic Monitoring #Observability レスポンス内容が予測可能なリクエストを事前に定義し、定期的にシステムに送信し応答を監視するもの
• Blog/

  Microservice Premium
  #Software Design Martin Fowlerが2015年に書いたブログ 当時過熱していたマイクロサービス化ブームに警鐘を鳴らす形で、全てのケースにマイクロサービスが適するわけではない点が示された https://martinfowler.com/bliki/MicroservicePremium.html
• 計装
  #Observability テレメトリーをオブザーバビリティソリューションに送信するための実装のこと 前提としてエージェントをシステムに組み込んだ上で、アプリケーションエンドポイントへの自動計装や手動スパン埋め込み等のカスタム計装を行う
• Multitenancy
  分離されたユーザのグループ（テナント）を複数持つことをサポートするプラットフォームの機能
• Cyrille Martraire
  Home X 人物
• safe-settings
  #Continuous Integration リポジトリ設定を policy-as-code で組織横断に宣言・適用する GitHub App（Probot ベース）。admin リポジトリに設定を集中管理し、各 repo の実設定を GitHub API 経由で宣言状態へ収束させる、repo 設定版の Infrastructure as Code。Platform Engineering の guardrails 実装の一つ 設定は admin repo の 3 階層（.github/settings.yml=org / suborgs/*.yml / repos/*.yml）で各 repo にマージ適用、優先度は repo > suborg > org full sync（CRON）で drift を検出・修正、PR では nop モードで dry-run 差分を提示 管理対象は GitHub API で扱う設定のみ（branch protection / labels / collaborators / teams / topics / custom properties / environments / rulesets 等）。ファイル内容は扱えず .github/workflows/*.yml の配布はできない（GitHub Actions の強制は ruleset / require workflows 経由） Organization 専用で個人アカウントでは動かない https://github.com/github/safe-settings
• Eff
  Extensible Effect #Programming 作って学ぶ Extensible Effects Freer monads, more extensible effects. Extensible Effects in Scala Scala + CleanArchitectureにEffを組み込んでみた アルプのEff独自エフェクト集 / Alp-original ’Eff’ pearls Eff（atnos-eff）による実践的なコーディング集
• 成瀬 允宣
  
• Testcontainers
  
• Getting in the room
  Will Larsonによる、スタッフエンジニアの文脈で、ミーティングへの参加方法・心得等について話されているブログ https://lethain.com/getting-in-the-room/
• モノリスからマイクロサービスへ
  
• ドラッガー風エクササイズ
  #Team Organization チームビルディングの手法、チーム内におけるメンバー間の期待を明らかにする 以下の4つの質問を全員が答えて共有する 自分は何が得意なのか？ 自分はどうやって貢献するつもりか？ 自分が大切に思う価値は何か？ チームメンバーは自分にどんな成果を期待していると思うか？ さらにその4つの回答に、他のチームメンバーの期待がずれていないかを正すことができるとよい
• Walking Skeleton
  #Agile #Product Management システムの端から端まで（end-to-end）を貫く、ごく小さな実装。最終的なアーキテクチャである必要はないが、主要なコンポーネントを結合して実際に動作するものを最初に作り、そこに肉付けして少しずつ成長させる。Alistair Cockburnが提唱した。
• Known knowns
  意識をしており確認していること
• Devin Search
  #LLM Devinと連携されたリポジトリに対して回答を得るAsk特化のAIアシスタント 検索対象は自動でインデックスされる https://docs.devin.ai/work-with-devin/devin-search
• SerenityJS
  #Testing BDDフレンドリーなビジネスに重点を置いたテスト自動化を実現するTypeScript製のテストフレークワークライブラリ PlaywrightのようなE2Eテストライブラリを抽象化し統合できる https://serenity-js.org/
• Bツリー
  #Data Engineering Bツリーはデータベースを固定サイズのブロックあるいはページに分割する。固定サイズの空き容量がない状態で新しいキーが追加される場合、半分の領域が空いた2つのブロックに分割される。 このアルゴリズムはツリーバランスが保たれ、ツリーの深さも3ないし4レベルに収まることがほとんど。 また信頼性を高めるためにwrite-aheadログ（WAL）と呼ばれる書き込み内容の構造化データを追記して保持している。 Wikipedia
• Amazon/

  KMS
  Key Management Service #Security AWSが提供するKMS AWS Key Management Service