Kush's Wiki

Sort by - linked count

• Kubernetes/

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

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

  DaemonSet
  
• Kubernetes/

  カスタムリソース
  CustomResourceDefinitionによって追加できるカスタマイズ可能なリソース
• Kubernetes/

  CronJob
  
• Kubernetes/

  Pod Security Admission
  PSA #Security #Kubernetes Pod Security Standardsを違反する可能性がある際のアクションを実行する アクションは以下の3つ Warn Audit Enforce Pod Security Admission | Kubernetes
• Kubernetes/

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

  ClusterRoleBinding
  
• 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）による実践的なコーディング集
• Architectural Styles and the Design of Network-based Software Architectures
  Roy Fieldingによる論文 https://ics.uci.edu/~fielding/pubs/dissertation/top.htm
• Prometeus
  
• Observability/

  ディメンション
  キーバリュー形式のデータにおいてデータ内のキーの数を表す
• GitHub Actions
  #Continuous Integration #Continuous Delivery
• 成功循環モデル
  #Team Organization ダニエル・キムによる、チームや組織の成熟度は以下4つのサイクルで向上するというモデル 関係の質 思考の質 行動の質 結果の質
• Clean Craftsmanship
  
• カーディナリティ
  #Data Store あるカラムの値の集合の中に重複する値がどのくらいあるかの度合い。低いと重複が多く高いと重複が少ない。
• アジャイルソフトウェアの12の原則
  #Agile アジャイルソフトウェア開発宣言に続く原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則
• Shopifyはいかにしてモジュラモノリスへ移行したか
  #モジュラモノリス Shopifyはいかにしてモジュラモノリスへ移行したか - InfoQ
• 適応度関数
  Fitness Function #API Architecture システムの品質特性を数量化可能な指標で評価する、システムの目標を一貫して保証するためにビルドパイプラインに組み込まれる それぞれの特性は以下のようにカテゴライズされる コード品質（Code Quality） レジリエンス（Resiliency） オブザーバビリティ（Observability） パフォーマンス（Performance） コンプライアンス（Compliance） セキュリティ（Security） 運用操作性（Operability） Fitness function-driven development | Thoughtworks
• 計装
  #Observability テレメトリーをオブザーバビリティソリューションに送信するための実装のこと 前提としてエージェントをシステムに組み込んだ上で、アプリケーションエンドポイントへの自動計装や手動スパン埋め込み等のカスタム計装を行う
• Gaspar Nagy
  
• レポーティングデータベース
  #Martin Fowler #Data Store #Data Processing アプリケーションのドメインモデルに対応するテーブルとは別にレポート目的の中間テーブルを用意することで、レポートの関心を分離してテーブルに変更を加えることができる。 https://bliki-ja.github.io/ReportingDatabase
• 広木大地
  
• 仮説検証型アジャイル開発
  #Agile #市谷聡啓 https://drr.red/
• サービスの信頼性の階層
  
• 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ブロッキングのような問題の回避をする
• Basic認証
  #Security #Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う
• マルチリーダーレプリケーション
  #Data Store レプリケーションの種別の一つ 複数のデータセンターにリーダーが存在する。リアルタイムの同時編集がイメージに近い。書き込みの衝突があった際に最終的に同じ値に収束させるような方法が取られる
• C4 model
  #Documentation 以下の4つのダイアグラム図を表すアプローチ Context Diagram Container Diagram Component Diagram Code Diagram 順に抽象度が下がっていく流れになっている https://c4model.com/
• DNSラベル標準
  #Network RFC 1123で定義されているDNSに指定可能な文字列
• Vaughn Vernon
  
• anyhow
  #Programming Rustにおけるエラー型の扱いを楽にするライブラリ パブリックなAPIでは利用を避けて標準のエラー型を用いるのが良い anyhow - Rust
• Manuel Pais
  
• sops
  #Security GitOpsの世界においてSecretをクライアントサイドで扱うGo製のツール。YAMLやJSONのファイル上でSecretを安全にgit管理することができる ageを用いたローカルでのキー管理か、KMSによるキー管理のどちらを選択できる CNCF sandbox project https://getsops.io/
• リチャードソン成熟度モデル
  #API Architecture Leonard RechardsonによるREST APIの観点からAPI実装の成熟度をレベルに分類したもの 各レベルのタイトルは以下 レベル0 HTTP/RPC レベル1 リソース レベル2 動詞（メソッド） レベル3 ハイパーメディアコントロール QCon 2008での発表は以下 Justice Will Take Us Millions Of Intricate Moves
• Bツリー
  #Data Store Bツリーはデータベースを固定サイズのブロックあるいはページに分割する。固定サイズの空き容量がない状態で新しいキーが追加される場合、半分の領域が空いた2つのブロックに分割される。 このアルゴリズムはツリーバランスが保たれ、ツリーの深さも3ないし4レベルに収まることがほとんど。 また信頼性を高めるためにwrite-aheadログ（WAL）と呼ばれる書き込み内容の構造化データを追記して保持している。 Wikipedia
• Agile testing directions: tests and examples
  #Testing #Agile Testing アジャイルテストの4象限 http://www.exampler.com/old-blog/2003/08/22/#agile-testing-project-2
• The Twelve-Factor App
  Software as a Serviceを作り上げるための方法論 The Twelve-Factor App （日本語訳）
• モノリスからマイクロサービスへ
  
• Google Cloud/

  Certificate Manager
  #Security Google Cloudにおいて外部ロードバランシングで必要となるようなTLS証明書を管理する Certificate Manager の概要 | Google Cloud
• Open Container Initiative
  OCI 2015年にDockerとその他の業界リーダーによって作成された、コンテナ形式とランタイムに関するオープンな業界標準 具体的に以下の3つの仕様を持つ runtime-spec image-spec distribution-spec Linux Foundationプロジェクト Open Container Initiative - Open Container Initiative
• GitHub Copilot
  #Programming #AI VS Codeにビルドインで搭載されているAIアシスタント プランによって利用できるLLMが異なる https://docs.github.com/ja/copilot
• Continuous Testing in DevOps
  
• SECIモデル
  知識を暗黙知と形式知に分けそれらが学習サイクルに表れる過程をモデル化したもの 以下の4つのフェーズを繰り返す 共同化（Socialization） 暗黙知から暗黙知。組織として共通の経験を積み重ねる 表出化（Externalization） 暗黙知から形式知。経験的知識の共通点や抽象的な構造をモデル化する 連結化（Combination） 形式知から形式知。複数の形式知から知識体系を作る 内面化（Internalization） 形式知から暗黙知。形式知を実践的に理解できた状態
• 逸脱の常態化
  誤検出されやすいモニタリングアラートに慣れてしまうこと チャレンジャー号の事故の調査から生まれた言葉 When Doing Wrong Feels So Right: Normalization of Deviance - PubMed
• Multitenancy
  分離されたユーザのグループ（テナント）を複数持つことをサポートするプラットフォームの機能
• Knative Serving
  Knativeにおいて、KubernetesのCustomResourceDefinitionによって4種類のリソースを定義しアプリケーションの提供を行う Serviceの別APIのようなサービスディスカバリパターン 4種類のリソースは以下 Services Routes Configurations Revisions https://github.com/knative/specs/blob/main/specs/serving/overview.md
• OpenFeature
  
• MCP
  Model Context Protocol #AI LLMが様々なリソースにアクセスするためのAnthropic社による標準化プロトコル MCPサーバーがローカルまたはリモートのリソースにアクセスし、それをMCPクライアントが利用する MCPクライアントとサーバー間のトランポートレイヤでは stdio（標準入出力） HTTP POST のいずれかが用いられる https://modelcontextprotocol.io/docs/concepts/architecture
• 成瀬允宣