Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

@kyon_mmの書籍の読み方 #AsianAA

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

@kyon_mmの書籍の読み方 #AsianAA

  1. 1. How to read
  2. 2. 関西に最近くると聞かれる
  3. 3. • 「きょんさんってたくさん書籍読みますよ ね」 • 「そうかもしれませんね」 • 「一ヶ月でどれくらい読むんですか?」 • 「うーん。あまり測っていないかも。。。 多分年間で数十冊くらい。」 • 「どうやって読むんですか?」 • 「えっとですね。。。」
  4. 4. 1. まず目次から内容を予想する。30分くら い。 2. 3日で全部読む。わからないところは飛ば す。言い回しや価値のある部分を知る。 3. マインドマップでわからないことを書く。 4. 次はじっくり全部読む。 5. マインドマップでわかったことを削除する。 わからないことは追加する。 6. 変更量をメトリクスする。
  5. 5. 自分の学習行為を定量化できてい ないで、ソフトウェア開発を定量 化とか自動化とかROIとかwww
  6. 6. まぁ、とりあえず定量化した らいいと思うよ。 あと、無駄をなくせ。
  7. 7. TDDと契約プログラミングの 違い
  8. 8. TDDでの設計と保証 1. テストで対象の振る舞いを書く 2. 実装をする
  9. 9. Design by Contractでの設計 と保証 1. 事前条件、公理を定義する 2. 事前条件、事後条件、不変条件として定義 する 3. 実装する まぁ、ホーア論理だよ。P {C} Q だよ。
  10. 10. DbCとCoqはどう違うのか? • 全然わかりません。 • コンパイルタイムチェックの契約プログラミン グと依存型プログラミングは結構似ている。 • DbCは停止性を証明する必要はないけど、 Coqは停止性を証明する必要がある。
  11. 11. 「振る舞い」か「公理」か
  12. 12. Stack Preconditions remove(s:STACK[G]) require not empty(s) item(s:STACK[G]) require not empty(s)
  13. 13. Stack Aximos item(put(s, x)) = x remove(put(s, x)) = x empty(new) not empty(put(s, x))
  14. 14. 比較 • TDD : ある集合の具体的な値をなにかの形 で実行時検査するしか保証がとれない。 • DbC : 公理を満たさないモジュールは定義 できない。
  15. 15. 比較 • TDD : ユースケースを書くけど、ユースケー スは網羅されていない。 • DbC : 公理は比較的網羅する方向にある。 書かないと警告ばっかりでるからな!
  16. 16. つまり優れたプログラマーの テストは公理を書いているか もしれない。くらい。
  17. 17. まぁUncleBobくらいのTDDであ れば。DbCとかなり近いです。

×