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

50%ルール

開発と運用を分けずに一緒にバランスをとっていい感じにしていこうぜというもの。

具体的な方法論としては[CI](/wiki/CI)や[CD](/wiki/CD)など。

実装として[SRE](/wiki/SRE)がある。

DevOps

[暗号通貨](/wiki/暗号通貨)の[L2ソリューション](/wiki/L2ソリューション)において、セカンドレイヤーで処理したいくつかのトランザクションをまとめてメインのチェーンに保存するような方式のこと。

大きく分けて以下の2つに分かれる。
- [Optimistic Rollup](/wiki/Optimistic Rollup)
- [ZK_Rollup](/wiki/ZK_Rollup)

Rollup


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

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

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


あるデータのハッシュ値を次のデータの先頭に含めることで、連鎖的にデータが繋がりチェーンのようになる。

これにより過去のデータを改竄しようとすると連鎖的にハッシュ値が変わってしまうため、改竄が難しくなる。

ブロックチェーン

分散コンピューティングにおける定理。

ノード間のデータ複製において、以下の3つを同時に満たすことはできない。
- 一貫性 (Consistency)
	- すべてのデータ読み込みにおいて、最新の書き込みデータもしくはエラーのどちらかを受け取る。
- 可用性 (Availability)
	- ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。[単一障害点](/wiki/単一障害点)が存在しないことが必要。
- 分断耐性 (Partition-tolerance)
	- システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのようなネットワーク設計は[単一障害点](/wiki/単一障害点)をもつことになり、可用性が成立しない。


CAP定理


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

香り高いけど味は好みでは無い
苦味とかが薄い


キリマンジャロAA

大手取引所の[Binance](/wiki/Binance)が発行している[暗号通貨](/wiki/暗号通貨)。

[Binance_Smart_Chain](/wiki/Binance_Smart_Chain)という[Ethereum](/wiki/Ethereum)互換チェーンで使われる。




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

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

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


CLEAN


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)で定義されている概念。

アーキテクトの問題はそれぞれユニークなため、ベストプラクティスが存在しない。  

だからこそ「ハード」パーツである。  

- 難しい問題  
- 堅い、システムの土台となる部分

ハードパーツ


[ライトニングネットワーク](/wiki/ライトニングネットワーク)の[Ethereum](/wiki/Ethereum)版。

ライデンネットワーク

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

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


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

所有していないデータにサービスが読み取りアクセスするためには様々な方法があり、その間にもトレードオフがある。  
  
- サービス間通信パターン  
  - サービス間がWEB API等で通信してDBを隠蔽する  
- 列スキーマレプリケーションパターン  
  - 非正規化する  
- レプリケーションキャッシュパターン  
  - 分散キャッシュする  
- データドメインパターン  
  - 愚直に一緒にDBを見てしまう

分散データアクセスに関するトレードオフ


[Zettelkasten](/wiki/Zettelkasten)をデジタルでやるフレームワークらしい。

基本的には[Zettelkasten](/wiki/Zettelkasten)に従いつつ、以下の要素を加える。

- Map Of Contentsを作る。
	- ノートを繋ぐリンク集のようなノート。
	- ノートが100を超えたあたりから意識する。
- Homeノートを作る。

参考
https://www.linkingyourthinking.com/


Link_Your_Thinking

[Ethereum](/wiki/Ethereum)の[L2ソリューション](/wiki/L2ソリューション)の一つ。

[Optimistic_Rollup](/wiki/Optimistic_Rollup)を採用したもの。

Optimism

<p><a href="/wiki/%E3%82%B0%E3%83%A9%E3%83%95">グラフ</a>に関する数学の理論のこと。</p>


グラフ理論