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

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

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

DevOps

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

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

[DevOps](/wiki/DevOps)

[ブロックチェーン](/wiki/ブロックチェーン)を使ったアプリでdecenterlized Appの略。



DApp


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

無難な味で結構使いやすい
安いし

モカシダモG4


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

ビヨンセルール


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
比較的すっきり目でブラックでも飲める。香りは強いというわけではない。とはいえ[エイジドマンデリン](/wiki/エイジドマンデリン)と比べると少しブラックに向かない。苦味よりも酸味や甘さが強めなので。
悪くはないがこれを買うなら[エイジドマンデリン](/wiki/エイジドマンデリン)を買う。


コスタリカエルアルコン


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

潜在空間


その[頂点](/wiki/頂点)を除くと[グラフ](/wiki/グラフ)が[非連結グラフ](/wiki/非連結グラフ)になるような[頂点](/wiki/頂点)のこと。

切断点


[機械学習](/wiki/機械学習)においては[中間層](/wiki/中間層)の変数のこととほぼ同義

中間層はだいたい入力より次元が低く、その次元で入力の特徴を捉えるようにチューニングするので、入力の特徴だけを捉えたものになる

関連：[潜在空間](/wiki/潜在空間)

潜在変数


セラミックを使ったヒーターのこと。
即暖性に優れるが[カーボンヒーター](/wiki/カーボンヒーター)よりも電気代が高い。

セラミックヒーター

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

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


CAP定理


可能な限りチームメンバーに仕事を移譲し、自身はチームメンバーが円滑に仕事をすることができるように仕えるというやり方



サーバントリーダーシップ

[サトシナカモト](/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/ソフトウェアアーキテクチャ・ハードパーツ)

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

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


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

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

[QuANTS](/wiki/QuANTS)

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

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

<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__35b7ebec4b1aa" src="https://embed.zenn.studio/card#zenn-embedded__35b7ebec4b1aa" data-content="https%3A%2F%2Fwww.amazon.co.jp%2F%25E3%2582%25BD%25E3%2583%2595%25E3%2583%2588%25E3%2582%25A6%25E3%2582%25A7%25E3%2582%25A2%25E8%25A6%258B%25E7%25A9%258D%25E3%2582%258A-%25E4%25BA%25BA%25E6%259C%2588%25E3%2581%25AE%25E6%259A%2597%25E9%25BB%2599%25E7%259F%25A5%25E3%2582%2592%25E8%25A7%25A3%25E3%2581%258D%25E6%2598%258E%25E3%2581%258B%25E3%2581%2599-%25E3%2582%25B9%25E3%2583%2586%25E3%2582%25A3%25E3%2583%25BC%25E3%2583%2596-%25E3%2583%259E%25E3%2582%25B3%25E3%2583%258D%25E3%2583%25AB-ebook%2Fdp%2FB00KR96M6K" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.amazon.co.jp/ソフトウェア見積り-人月の暗黙知を解き明かす-スティーブ-マコネル-ebook/dp/B00KR96M6K</a></p>
<p><a href="/wiki/%E8%A6%8B%E7%A9%8D%E3%82%82%E3%82%8A">見積もり</a></p>


ソフトウェア見積もり_人月の暗黙知を解き明かす