
以下のようにプログラミングを行うこと

- コンシューマの観点で機能を設計する  
- サービスが何をやっているかを示す名前をつける  
- どう動くかは隠す

対義語は[インサイドアウトプログラミング](/wiki/インサイドアウトプログラミング)

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

アウトサイドインプログラミング

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

Optimistic_Rollup

契約を自動履行するシステムやプログラムのこと。

[Ethereum](/wiki/Ethereum)のような[暗号通貨](/wiki/暗号通貨)では[ブロックチェーン](/wiki/ブロックチェーン)に記された台帳上の金額を動かす[チューリング完全](/wiki/チューリング完全)なプログラムを実装できるため、それを用いてスマートコントラクトも実現されている。



スマートコントラクト

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

著者の一人である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フレームワーク


モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していくためのやり方のうちの一つで、以下の様な手法。

- まるっと別アプリケーションとしてコピーして立て、それぞれ1部の機能しか使っていない状態にする。  
- その後、不要な機能をリファクタリングによって削除していく。

戦術的フォーク


昔の人が編み出したノート術。
Atomicなノートをリンクで繋げる。

1. カード1枚につき1アイデアを記入
2.  カードの内容を完結させる
3.  カードは常に他のカードとリンクさせる
4.  カードのリンクが何を意味するかを説明する
5.  自分の言葉を使う
6.  参考文献を残しておく
7.  自分の考えを加える
8.  構造を気にしない
9.  続カードを追加する
10.  アウトラインカードを追加する
11.  カードを削除しない
12.  恐れずにカードを追加する

参考
https://gigazine.net/news/20200604-zettelkasten-note/

Zettelkasten


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

なんかあんまり美味しくない
ほげほげマウンテンはあんまり好きじゃ無いのかもしれない
苦味が薄めな感じ

クリスタルマウンテン

タングステンフィラメントを「花巻」状にコイリングし、ハロゲンガスとともに石英管に封入したヒーターのこと。
暖かいが、[カーボンヒーター](/wiki/カーボンヒーター)や[石英管ヒーター](/wiki/石英管ヒーター)よりもさらに電気代が高い。

ハロゲンヒーター


[頂点](/wiki/頂点)の列であり、各[頂点](/wiki/頂点)とその次の[頂点](/wiki/頂点)との間に[辺](/wiki/辺)が存在するようなもののこと。


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

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

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


[機械学習](/wiki/機械学習)において入力層でも出力層でもないやつ

中間層


https://mickindex.sakura.ne.jp/schlick/schlick_MV_jp.html

ある命題が立てられているとき、この命題が有意味であるか無意味であるかという問いを立てるとしたならば、その命題が有意味であるための条件が問われている。
命題が有意味であるとはそれが検証可能であるということだ……という考え方が、意味の検証理論

意味の検証理論

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

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

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

Attribute_Component_Capability

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

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


拡散モデル

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

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

Diffusionモデル

<p>メインの<a href="/wiki/%E6%9A%97%E5%8F%B7%E9%80%9A%E8%B2%A8">暗号通貨</a>の<a href="/wiki/%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3">ブロックチェーン</a>と連携する目的で作られた別の<a href="/wiki/%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3">ブロックチェーン</a>のこと。</p>


サイドチェーン