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

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

[DevOps](/wiki/DevOps)

Continuous Deliveryの略で、本番環境までのデプロイを自動化して安定かつ高速にリリースしようぜというやつ。

[CI](/wiki/CI)とセットでCI/CDと呼ばれる。

[DevOps](/wiki/DevOps)

カーボンを使ったヒーターのこと。
電気代が[ハロゲンヒーター](/wiki/ハロゲンヒーター)より安く、遠赤外線が2倍出るため電力効率に優れる。

カーボンヒーター


「そんなに好きならそいつにテスト付けときゃよかったのに」

ビヨンセルール


[潜在変数](/wiki/潜在変数)がある空間

潜在空間


[エイジドマンデリン](/wiki/エイジドマンデリン)とは違うのかな？

マンデリン


[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)の定義では

> コードの挙動を変えずに整理された内容に書き直すこと

である。

つまり、最も重要なのは自動テストである。自動テストがないと挙動が変わってないことが担保できないからである。

参考
https://qiita.com/miketako3/items/3085e225a35cdf89cd55

リファクタリング


与えられた命題が真であることを、それ以外の情報を与えずに証明すること。

ゼロ知識証明

初期の[暗号通貨](/wiki/暗号通貨)の取引手数料が高騰している課題の解決策として、大きく分けて以下の2種類がある。

- 最適化した新たな[暗号通貨](/wiki/暗号通貨)を開発し、それだけを運用可能にする（適度に連携することも多い。[サイドチェーン](/wiki/サイドチェーン)）。
- 最適化した新たな[暗号通貨](/wiki/暗号通貨)を開発し、その履歴を定期的に既存の[暗号通貨](/wiki/暗号通貨)に書き込む。

この内の後者をセカンドレイヤー (L2) ソリューションと呼び、その新たな暗号通貨をセカンドレイヤー等と呼ぶ。

代表例は[Ethereum](/wiki/Ethereum)に対する[Polygon](/wiki/Polygon)、[Optimism](/wiki/Optimism)、[Plasma](/wiki/Plasma)、[ライデンネットワーク](/wiki/ライデンネットワーク)、[Bitcoin](/wiki/Bitcoin)に対する[ライトニングネットワーク](/wiki/ライトニングネットワーク)等。

L2ソリューション


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

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

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

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

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

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

Attribute_Component_Capability

メジャーな[暗号通貨](/wiki/暗号通貨)の一種。[チューリング完全](/wiki/チューリング完全)なスクリプトに対応し、[スマートコントラクト](/wiki/スマートコントラクト)を実装するのによく使われている。

基本的にイーサリアム上のスクリプトは[Solidity](/wiki/Solidity)で開発し、[EVM](/wiki/EVM)バイトコードに変換されて実行される。

コアなところは[Bitcoin](/wiki/Bitcoin)と同じで、分散台帳にスクリプトを反映した結果のハッシュ値を[プルーフオブステーク](/wiki/プルーフオブステーク)を使いつつ分散的に検証する。

この仕組みではブロックチェーン外部の情報は使えないように見えるが、主に[Chainlink](/wiki/Chainlink)が提供している[オラクル](/wiki/オラクル)によって外部データが分散台帳に反映されるため問題ない。

昔は[プルーフオブワーク](/wiki/プルーフオブワーク)だったが現在は移行済み。

Ethereum

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

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

かの有名な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/暗号通貨)の取引所で最近日本にも正式に参入してきた。

[Binance_Smart_Chain](/wiki/Binance_Smart_Chain)を運営している。

Binance


ゴール、シグナル、メトリクスを明確に区別する (GSMフレームワーク)。  
  
- ゴール: 達成するべき目標。  
- シグナル: ゴールを達成したことを知る手段。必ずしも計測可能である必要はない。  
- メトリクス: シグナルの計測可能な代替品。  
  
メトリクスを計測する前に、それを計測した後どう行動するのかを考えるべき。  
  
生産性のゴールにはトレードオフがあるため、一部だけを計測するのはよくない。  
QuANTSのゴールを全て計測することで、網羅的に計測ができる。  
  
| 頭文字 | 英語                           | 日本語      |  
|-----|------------------------------|----------|  
| Qu  | **Qu**ality of the code      | コード品質    |  
| A   | **A**ttention from engineers | エンジニアの注意 |  
| N   | I**n**tellectual complexity  | 知的複雑性    |  
| T   | **T**empo and velocity       | テンポと速度   |  
| S   | **S**atisfaction             | 満足       |  

QuANTS

<p><a href="/wiki/SRE">SRE</a>において、<a href="/wiki/SLO">SLO</a>と現在の<a href="/wiki/SLI">SLI</a>の値の差のこと。<br />
この分だけ品質を下げられるということなので、その余剰資産を使って新機能の開発などのリスクを取ることができる。</p>


エラーバジェット