Continuous Integrationで、自動化されたパイプラインで継続的にテストなどでコードをチェックする仕組みのこと。

[CD](/wiki/CD)とセットでCI/CDとか言われる。

[DevOps](/wiki/DevOps)

[SRE](/wiki/SRE)においては[トイル](/wiki/トイル)は50%以下を目指すルールがある。

50%ルール

[SRE](/wiki/SRE)においてService Level Agreementの略で、対外的に満たすことを約束している指標のこと。

正常応答率99%を目指そう！と内部的に言うなら[SLO](/wiki/SLO)だが、対外的に約束してしまうとSLAになる。


以下のようにプログラミングを行うこと

- コンシューマの観点で機能を設計する  
- サービスが何をやっているかを示す名前をつける  
- どう動くかは隠す

対義語は[インサイドアウトプログラミング](/wiki/インサイドアウトプログラミング)

https://www.oreilly.co.jp/books/9784873118864/

アウトサイドインプログラミング


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

通信、整合性、調整についてそれぞれ2パターンあり、組み合わせると合計8パターンのサーガ (アーキテクチャの大別) がある。

| パターン名       | 通信  | 整合性   | 調整         | 結合度   | 複雑さ   | 応答性/可用性 | スケーラビリティ |  
|-------------|-----|-------|------------|-------|-------|---------|----------|  
| エピックサーガ     | 同期  | アトミック | オーケストレーション | とても高い | 低い    | 低い      | とても低い    |  
| 伝言ゲームサーガ    | 同期  | アトミック | コレオグラフィ    | 高い    | 高い    | 低い      | 低い       |  
| おとぎ話サーガ     | 同期  | 結果整合性 | オーケストレーション | 高い    | とても低い | 中程度     | 高い       |  
| 時間旅行サーガ     | 同期  | 結果整合性 | コレオグラフィ    | 中程度   | 低い    | 中程度     | 低い       |  
| ファンタジーサーガ   | 非同期 | アトミック | オーケストレーション | 高い    | 高い    | 低い      | 低い       |  
| ホラーストーリーサーガ | 非同期 | アトミック | コレオグラフィ    | 中程度   | とても高い | 低い      | 中程度      |  
| パラレルサーガ     | 非同期 | 結果整合性 | オーケストレーション | 低い    | 低い    | 高い      | 高い       |  
| アンソロジーサーガ   | 非同期 | 結果整合性 | コレオグラフィ    | とても低い | 高い    | 高い      | とても高い    |

トランザクショナルサーガ


飲んだコーヒー豆を記録しておく

- [カルディリッチブレンド](/wiki/カルディリッチブレンド)
- [エイジドマンデリン](/wiki/エイジドマンデリン)
- [コスタリカエルアルコン](/wiki/コスタリカエルアルコン)
- [ホンジュラスパトリアルカ](/wiki/ホンジュラスパトリアルカ)
- [コスタリカフィデルス](/wiki/コスタリカフィデルス)
- [珈琲問屋冬のブレンド雪灯り](/wiki/珈琲問屋冬のブレンド雪灯り)
- [モカシダモG4](/wiki/モカシダモG4)
- [ニカラグアリンダビスタ農園](/wiki/ニカラグアリンダビスタ農園)
- [ブラジルショコラ](/wiki/ブラジルショコラ)
- [コロンビアスプレモ](/wiki/コロンビアスプレモ)
- [エメラルドマウンテン](/wiki/エメラルドマウンテン)
- [クリスタルマウンテン](/wiki/クリスタルマウンテン)
- [ソルデラマニャーナウォッシュド](/wiki/ソルデラマニャーナウォッシュド)
- [キリマンジャロAA](/wiki/キリマンジャロAA)

飲んだコーヒー豆リスト


[頂点](/wiki/頂点)の列であり、各[頂点](/wiki/頂点)とその次の[頂点](/wiki/頂点)との間に[辺](/wiki/辺)が存在するようなもののこと。

裏切り者がいるかもしれない時に、どのように分散的に合意するかという問題。

転じて、間違う可能性のある分散システム上でどのようにデータに合意するか、という問題の基本的なバージョンと考えられる。

かの有名なLamport先生を含む3人が1980年の論文で合意問題として定式化したらしい。

https://dl.acm.org/doi/10.1145/322186.322188

最初の解決策も1982年にLamport先生たちが論文を出した。

https://dl.acm.org/doi/10.1145/357172.357176

この問題は裏切り者が1/3以上いる場合は解決出来ないことが知られている。

この合意が取れるシステムはビザンチン障害耐性 (Byzantine Fault Tolerance) があると言う。

分散システムの問題なので[暗号通貨](/wiki/暗号通貨)でもよく語られる問題である。

ビザンチン合意

タングステンフィラメントを「花巻」状にコイリングし、ハロゲンガスとともに石英管に封入したヒーターのこと。
暖かいが、[カーボンヒーター](/wiki/カーボンヒーター)や[石英管ヒーター](/wiki/石英管ヒーター)よりもさらに電気代が高い。

ハロゲンヒーター


[グラフ理論](/wiki/グラフ理論)における[グラフ](/wiki/グラフ)の定義から、[辺](/wiki/辺)の集合ではない方の集合。

頂点


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

マイクロサービスの粒度を大きくするか？小さくするか？もトレードオフである。  
  
粒度を小さくする要因としては以下のようなものがある。  
  
- サービスの範囲と機能  
  - 凝集性が高い状態になっているか？  
- コード変動率  
  - 一部のコードだけ変更頻度が高くないか？  
- スケーラビリティとスループット  
  - 一部だけスケールする必要があるか？  
- 耐障害性  
  - 一部の故障で全体が故障してしまわないか？  
- セキュリティ  
  - 一部だけ高いセキュリティが必要か？  
- 拡張性  
  - どの程度拡張されるか？  
  
粒度を大きくする要因としては以下のようなものがある。  
  
- トランザクション  
  - サービスをまたいだトランザクションが必要か？  
- ワークフローとコレオグラフィ  
  - サービス同士がやりとりする必要はあるか？  
- 共有コード  
  - サービス同士がコード共有の必要はあるか？  
- データ関係  
  - データは分解できるか？

サービスの粒度に関するトレードオフ


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

なんかあんまり美味しくない
ほげほげマウンテンはあんまり好きじゃ無いのかもしれない
苦味が薄めな感じ

クリスタルマウンテン


[閉路](/wiki/閉路)がない[グラフ](/wiki/グラフ)のこと

システムのテストすべき重要な箇所を洗い出す手法。

[Google](/wiki/Google)でも使われているらしい。

こちらを参照
https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki

Attribute_Component_Capability


https://ja.m.wikipedia.org/wiki/マトロイド

[貪欲法](/wiki/貪欲法)で最適化できる性質を持つ集合のこと

- [空集合](/wiki/空集合)を含む
- [部分集合](/wiki/部分集合)は必ず含まれる
- 小さいものから大きいものへの遷移が可能

これであれば[貪欲法](/wiki/貪欲法)の[局所解](/wiki/局所解)が[最適解](/wiki/最適解)と一緒になるのでで解ける

[グラフ](/wiki/グラフ)の[辺](/wiki/辺)集合における[森](/wiki/森)の集合とかがマトロイドになるので、つまり[最小全域木問題](/wiki/最小全域木問題)が解けることになる

そういうマトロイドのことを[グラフマトロイド](/wiki/グラフマトロイド)とか[閉路マトロイド](/wiki/閉路マトロイド)とかいう

閉路マトロイドの[基](/wiki/基)は[全域木](/wiki/全域木)になる

マトロイド

<p><a href="/wiki/%E6%A9%9F%E6%A2%B0%E5%AD%A6%E7%BF%92">機械学習</a>において入力層でも出力層でもないやつ</p>


中間層