[SRE](/wiki/SRE)においてアラートが鳴ったら対応するべく電話などを手元に置いておく状態のこと。最悪。

オンコール

世界トップの検索サービスを軸に様々なサービスを展開している企業。

もしくはそのサービスの名前。

[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)だったり[SRE](/wiki/SRE)だったりエンジニア界隈に影響を与えることが多すぎる

Google

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

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


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
かなり香りが良く酸味が強い印象がある。[エイジドマンデリン](/wiki/エイジドマンデリン)と比べるとブラックには全然向かず、砂糖やミルクと一緒に飲むと良い。
その前提であればリピしたいレベル。

ホンジュラスパトリアルカ

[Rollup](/wiki/Rollup)手法の一つ。楽観的ロールアップとも呼ばれ、不正なブロックがめったに生成されないという前提の元、不正なブロックがあった場合には後から検証でブロックする方針。

Optimistic_Rollup

[Bitcoin](/wiki/Bitcoin)に代表される、[ブロックチェーン](/wiki/ブロックチェーン)を用いた分散台帳に記載されたデータ残高のこと。

2023年1月時点の上位2位から10位は以下。

- [Ethereum](/wiki/Ethereum)
- [Tether](/wiki/Tether)
- [BNB](/wiki/BNB)
- [XRP](/wiki/XRP)
- [USB_Coin](/wiki/USB_Coin)
- [Binance_USD](/wiki/Binance_USD)
- [Cardano](/wiki/Cardano)
- [Dogecoin](/wiki/Dogecoin)
- [Polygon](/wiki/Polygon)

暗号通貨


うまくカプセル化されたソフトウェアは[アウトサイドインプログラミング](/wiki/アウトサイドインプログラミング)することによって得られる。  
  
「知らぬが仏」という言葉はソフトウェアにおいては常に真である。 

CLEANなコードを目指すべき。

- C: Cohesive (凝集性)  
- L: Loosely coupled (疎結合)  
- E: Encapsulated (カプセル化)  
- A: Assertive (断定的)  
- N: Nonredundant (非冗長)


CLEAN

Zero Knowledge - Succinct Non-interactive Argument of Knowledgeの略。

[ゼロ知識証明](/wiki/ゼロ知識証明)を用いて承認者が証明者に問いを出すことなく承認作業を短時間かつ少ない計算量で行うことができる手法のこと。

ZK-SNARK


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

[アーキテクチャデシジョンレコード](/wiki/アーキテクチャデシジョンレコード)

[アーキテクチャ量子](/wiki/アーキテクチャ量子)

[アーキテクチャの分解に関するトレードオフ](/wiki/アーキテクチャの分解に関するトレードオフ)

[分散データアクセスに関するトレードオフ](/wiki/分散データアクセスに関するトレードオフ)

[業務データの分解に関するトレードオフ](/wiki/業務データの分解に関するトレードオフ)

[サービスの粒度に関するトレードオフ](/wiki/サービスの粒度に関するトレードオフ)

[トランザクショナルサーガ](/wiki/トランザクショナルサーガ)

[コントラクトに関するトレードオフ](/wiki/コントラクトに関するトレードオフ)

ソフトウェアアーキテクチャ・ハードパーツ


[グラフ](/wiki/グラフ)において、最小で何個の頂点を取り除くと[非連結グラフ](/wiki/非連結グラフ)になるか、という数。

連結度


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

データベースを分けるか？分けないか？もトレードオフである。  
  
データを分解する要因として以下のようなものがある。  
  
- 変更制御  
  - カラムの変更等の影響が多岐にわたる  
- コネクション管理  
  - 1つのデータベースだけを使うとコネクション数の管理が難しい  
- スケーラビリティ  
  - コネクション数  
  - 容量  
  - スループット  
  - パフォーマンス  
- 耐障害性  
  - 1つのデータベースだけを使うとデータベースが単一障害点となってしまう  
- [アーキテクチャ量子](/wiki/アーキテクチャ量子)
  - 1つのデータベースだけを使うと1つの[アーキテクチャ量子](/wiki/アーキテクチャ量子)となってしまう (つまり独立してデプロイできない、等)  
- データベース種別の最適化  
  - 1つのデータベースだけを使うと1つの保存方法だけしか使えない (つまりデータ特性ごとに最適な選択肢が取れない)  
  
逆に、データを統合する要因としては以下のようなものがある。  
  
- データ関係  
  - 密結合な外部キー等があるか？  
- トランザクション  
  - 単一のトランザクション単位が必要か？  
  
モノリスなデータベースを分解するには5段階のプロセスを踏むと良い。  
  
1. 分析し、ドメインを特定する  
2. ドメインごとにテーブルを割り当て、移動する  
3. コネクションをドメインごとに分離する  
4. スキーマをそれぞれのデータベースに移動する  
5. コネクションを切り替える

業務データの分解に関するトレードオフ


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

[サーバントリーダーシップ](/wiki/サーバントリーダーシップ)

[QuANTS](/wiki/QuANTS)

[ビヨンセルール](/wiki/ビヨンセルール)

Googleのソフトウェアエンジニアリング

## 概要  
  
「ソフトウェアテストをカイゼンする50のアイデア」  
  
http://www.eijipress.co.jp/book/book.php?epcode=2085  
  
[Attribute_Component_Capability](/wiki/Attribute_Component_Capability)

ソフトウェアテストをカイゼンする50のアイデア


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

[サトシナカモト](/wiki/サトシナカモト)によって公開された以下の論文の仕組みによって分散的に運用されている世界で最初の[暗号通貨](/wiki/暗号通貨)。

https://bitcoin.org/bitcoin.pdf

論文の日本語訳

https://www.kk-kernel.co.jp/qgis/HALTAK/FEBupload/nakamotosatoshi-paper.pdf

ざっくり言えば「誰が誰にいくら渡した」という事実が記録された台帳データを、[プルーフオブワーク](/wiki/プルーフオブワーク)を付けて[ブロックチェーン](/wiki/ブロックチェーン)として繋げて記録することで、最も長いチェーンを信頼すれば[ビザンチン合意](/wiki/ビザンチン合意)ができる、という仕組み。

[チューリング完全](/wiki/チューリング完全)ではない等の欠点はあるが、一応簡易なスクリプトが使えるため、[スマートコントラクト](/wiki/スマートコントラクト)も作れるらしい。

この動画がわかりやすすぎた。

https://youtu.be/o-xhOBn4S60


Bitcoin

<a href="/wiki/%E6%9A%97%E5%8F%B7%E9%80%9A%E8%B2%A8">暗号通貨</a>であり、<a href="/wiki/%E3%82%B9%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%82%B3%E3%82%A4%E3%83%B3">ステーブルコイン</a>の一種。
Tether Limited社が米ドルを担保に発行している。
シンボルはUSDT