1. How to read

2. 関西に最近くると聞かれる

3. • 「きょんさんってたくさん書籍読みますよ
ね」
• 「そうかもしれませんね」
• 「一ヶ月でどれくらい読むんですか？」
• 「うーん。あまり測っていないかも。。。
多分年間で数十冊くらい。」
• 「どうやって読むんですか？」
• 「えっとですね。。。」

4. 1. まず目次から内容を予想する。30分くら
い。
2. 3日で全部読む。わからないところは飛ば
す。言い回しや価値のある部分を知る。
3. マインドマップでわからないことを書く。
4. 次はじっくり全部読む。
5. マインドマップでわかったことを削除する。
わからないことは追加する。
6. 変更量をメトリクスする。

5. 自分の学習行為を定量化できてい
ないで、ソフトウェア開発を定量
化とか自動化とかROIとかwww

6. まぁ、とりあえず定量化した
らいいと思うよ。
あと、無駄をなくせ。

7. TDDと契約プログラミングの
違い

8. TDDでの設計と保証
1. テストで対象の振る舞いを書く
2. 実装をする

9. Design by Contractでの設計
と保証
1. 事前条件、公理を定義する
2. 事前条件、事後条件、不変条件として定義
する
3. 実装する
まぁ、ホーア論理だよ。P {C} Q だよ。

10. DbCとCoqはどう違うのか？
• 全然わかりません。
• コンパイルタイムチェックの契約プログラミン
グと依存型プログラミングは結構似ている。
• DbCは停止性を証明する必要はないけど、
Coqは停止性を証明する必要がある。

11. 「振る舞い」か「公理」か

12. Stack Preconditions
remove(s:STACK[G]) require not empty(s)
item(s:STACK[G]) require not empty(s)

13. Stack Aximos
item(put(s, x)) = x
remove(put(s, x)) = x
empty(new)
not empty(put(s, x))

14. 比較
• TDD : ある集合の具体的な値をなにかの形
で実行時検査するしか保証がとれない。
• DbC : 公理を満たさないモジュールは定義
できない。

15. 比較
• TDD : ユースケースを書くけど、ユースケー
スは網羅されていない。
• DbC : 公理は比較的網羅する方向にある。
書かないと警告ばっかりでるからな！

16. つまり優れたプログラマーの
テストは公理を書いているか
もしれない。くらい。

17. まぁUncleBobくらいのTDDであ
れば。DbCとかなり近いです。