[SRE](/wiki/SRE)において、Service Level Indicatorの略で、サービスの質を図る指標のこと。

正常応答率99%を目指そう！と言った時、正常応答率がSLI。

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

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

[SRE](/wiki/SRE)において繰り返しで何も生み出さない作業のこと。

トイルを削減していき人が運用できる状態に保つことがSREの目標の一つ。

トイル


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

[CLEAN](/wiki/CLEAN)

レガシーコードからの脱却

[飲んだコーヒー豆リスト](/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


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

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

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

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

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


[VAE](/wiki/VAE)的なやつ

入力 -> エンコーダー -> 潜在空間 -> デコーダー -> 出力

という形のやつ

エンコーダーデコーダーモデル


拡散モデル

[エンコーダーデコーダーモデル](/wiki/エンコーダーデコーダーモデル)で、ノイズを混ぜた画像からノイズ無しの画像を推論する訓練をすることで、最終的には無から画像を生成できる

モデルは[VAE](/wiki/VAE)

Diffusionモデル

開発者の生産性をどう捉えるかについてのヒントを与えてくれるフレームワーク。  

著者の一人であるNicole Forsgren氏は、[LeanとDevOpsの科学](/wiki/LeanとDevOpsの科学)の著者の一人でもあり、氏が2021年にGitHub、ビクトリア大学、Microsoft Researchのメンバーと共に発表した論文[The SPACE of Developer Productivity](https://queue.acm.org/detail.cfm?id=3454124)で提唱されている。

- Satisfaction and well being
	- 開発者が自分の仕事、チーム、ツール、文化にどれだけ満足しているか
- Performance
	- 開発者が書いたコードは、想定されたことを確実に実行したか？
- Activity
	- 業務を遂行する過程で完了した行動やアウトプットの数
- Communication and collaboration
	- メンバーやチームがどのようにコミュニケーションをとり、協力し合うか
- Efficiency and flow
	- 個人であれシステムであれ、中断や遅延を最小限に抑えて作業を進める、完了する能力

参考
https://zenn.dev/loglass/articles/28c565a875e9bd

SPACEフレームワーク


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

アーキテクチャの分解には[コンポーネントベース分解](/wiki/コンポーネントベース分解)と[戦術的フォーク](/wiki/戦術的フォーク)という2種類のやり方があり、それぞれメリットとデメリットがある。

[戦術的フォーク](/wiki/戦術的フォーク)は[コンポーネントベース分解](/wiki/コンポーネントベース分解)と比べて以下のような特徴がある。

- メリット
  - 事前の分析が不要なので作業開始が早い
  - コードは抽出するより消す方が簡単 (と書かれていたが本当か？)
- デメリット
    - 不要なコードを消す努力が必要
    - ロジックは汚いまま

アーキテクチャの分解に関するトレードオフ

[ブロックチェーン](/wiki/ブロックチェーン)を用いた[暗号通貨](/wiki/暗号通貨)では、最も長いチェーンが有効とされる。

したがって、その分散ネットワークの全参加者のうち51%の信頼を獲得すれば、1人で最も長いチェーンを繋げることができる。これはつまり自由に台帳に取引履歴を書き込めるということで、そうなったら[暗号通貨](/wiki/暗号通貨)は終わる。

例えば[プルーフオブワーク](/wiki/プルーフオブワーク)では51%の計算リソースが必要で、[プルーフオブステーク](/wiki/プルーフオブステーク)では51%の[暗号通貨](/wiki/暗号通貨)が必要である。

[Bitcoin](/wiki/Bitcoin)等の規模が大きいネットワークでは攻撃はかなり難しいが、規模が小さい[暗号通貨](/wiki/暗号通貨)では実際に起こっている。

実例

https://coinpost.jp/?p=175687

51%攻撃

[DevOps Research and Assessment（DORA）](https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling)チームが実施した 6 年間の研究から確立されたソフトウェア開発チームのパフォーマンスを示す 以下の4 つの指標のこと。

- **デプロイの頻度** - 組織による正常な本番環境へのリリースの頻度
- **変更のリードタイム** - commit から本番環境稼働までの所要時間
- **変更障害率** - デプロイが原因で本番環境で障害が発生する割合（%）
- **サービス復元時間** - 組織が本番環境での障害から回復するのにかかる時間

参考
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

Four_Keys

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

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

Optimism

世界トップの検索サービスを軸に様々なサービスを展開している企業。
もしくはそのサービスの名前。
<a href="/wiki/Google%E3%81%AE%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0">Googleのソフトウェアエンジニアリング</a>だったり<a href="/wiki/SRE">SRE</a>だったりエンジニア界隈に影響を与えることが多すぎる