1. 一般的な業務システムではDBを使う
1.1. DBからSQLやO/Rで取り出す
1.1.1. 操作時にオブジェクトに格納する
1.1.1.1. オブジェクト指向は重厚長大
1.1.2. 無駄が多い?
2. シンプル
2.1. テキストファイルを扱う
2.2. コマンドをパイプで接続する
2.2.1. 接続＝再利用
2.2.1.1. ソフトウェアの部品化・再利用が成功している唯一の例だと思う
2.2.2. 既存のプログラムを組み合わせるにはインターフェイスが揃っていないといけない
2.2.3. パイプはインターフェイスが揃っている
2.2.3.1. データーが揃っているため手続きが再利用できる
2.2.3.2. テキストストリームは普遍的なインターフェイス
2.3. シェルスクリプト
3. ユニケージ開発手法
3.1. 理念
3.2. CQRSと同じ結論に辿り着いている
3.2.1. テキストファイルに追記する
3.2.1.1. 大福帳方式
3.2.1.1.1. イベントソーシング
3.2.2. 非正規化ファイル
3.2.2.1. レポート用
3.3. 共有より全有
3.3.1. 共有するデーターは複製して持たせる(全有)
3.3.2. ワンプログラム ワンフロー
3.3.2.1. 関数も使わない
3.3.3. RDB とのハイブリッド案
3.3.3.1. 全有データーの格納方式
3.3.3.2. 個別アプリが専用の読み出し RDB を持つ
3.3.3.3. RDB には利便性がある
4. UNIX哲学(Doug McIlroy)
4.1. 1つのプログラムが、1つの役割に専念する
4.2. 複数のプログラムは協調して働く
4.3. プログラムは汎用的インターフェイスである標準入出力を扱う
5. コマンドをフィルタとして作成する
5.1. 副作用のない関数として使える
5.1.1. grepなど
6. UNIXパイプでは構造化データーを扱えない?
6.1. 基本的に行指向
6.2. たとえばツリー構造はどう扱う?
6.2.1. XML化
6.2.2. JSON化
7. フィルタは関数型言語のコレクション関数と同じ
7.1. つなげてわたす
7.1.1. 小さなコマンド/関数を連結する
7.1.2. Scala的な考え方 - Scalaがとっつきにくいと思っている人へ - ゆるよろ日記
8. 前段から次段へのファイル処理
8.1. 定期的に実行する
8.2. makeでやると抜けがなく、必要な処理だけ実行できる
8.2.1. データーをレポート化しておくのに使える
8.2.2. Webリクエスト時にmakeを走らせるのはどうだろう?
9. Strategic Choice
9.1. Unix思想
9.1.1. The Art of UNIX Programmingの17個の原則
9.2. Unixという考え方(Unix哲学)
9.2.1. 最重要9定理
9.2.2. 重要10定理
10. プラグボードとの類似性
10.1. プラグボード - Wikipedia
10.1.1. タビュレーティングマシンの動作を変更するもの
10.2. 配線することで情報が流れる
10.3. カウンタや継電器をつなぐこともできる
10.4. 用途別にボードを準備し, 差し替えて使える
10.4.1. 週毎の給料支払簿用
10.4.2. 月毎の会計報告用