デバッグで難しいのは「ハードまわり」、「並列化」、「非同期」

事例
	Rubyそのもののデバッグ
	Rails→再現は比較的楽。

Debugの段階
再現→特定→修正
※特定できればまぁ、修正できる。

再現する為には？
→まずはログ

結論
「再現する為にはログが必要」
※タイミングみたいなのが絡まらなければ大体OK

特定は「自明である」
方法→書かない

仕様を示す為の必要最低限のコードを書く。

現実
レガシーコード→テストがないコード

コードを見る→「なんで必要」→「何をやってる？」
削除しても正常に動くようであれば、いらないコード

Code Reading
→デバッグする前にまず「読む」

デバッグは特定できないことが「敗北」である

what→who
まずは何がおかしいのか特定した後、「誰」がおかしくしたのかを特定する。

二分探索で探していく。

tracer?
最近OSXでやってるから使ってない。
OSXで使えるのはいいのない？

who？
まずはデータの流れを考える。

データの抽出が大事。

debug.c

試行を繰り返す→ブルートフォース
敗北しないようできるだけ頑張る。

Q.バイナリしかないときはどうすれば？
　　→ディスアセンブルするしか…
　　　→それができない場合は「諦める」しか…

Q.１番の敗北はなんですか？
	ソケットとスレッドの関係がよくわかんなくなって、ソースごと捨てたとき。
	「リメイク」がある意味、一番の敗北？
	
Q.一次キャッシュのノリが悪いとは。
	想定しているより、一次キャッシュからの取得が遅いとかそういうの。
	前のリビジョンに戻したら直った。

Q.根性以外に解決方法は？
	根性以外に方法思い付かない。
	
	
デバッグで一番大事なのは「デバッグしない」

最初にテストをして、仕様を作る。
テストを定義して構造化。

新しい手法
・より色んな種類に触れていくこと。
・デバッグに対する考え方→何が起きているのかを見極めるのが大事
・気合→そのためには ちゃんと寝て、ご飯を食べる
・フォルトインジェクションがLinuxで新しく入れたほうがいいということで入った
・Crazyなアイデアを発表してみると新しいことが発見できる
・どこからが「新しいか」
・ノイマン型は他の環境でも再現できるはず
　なので、仮想化してその上で動かす
・スクリプト言語の力を借りれば、GDBよりもリッチで使いやすい
　クラスの多重継承を調べるときにはEvelRuby（イビルルビー）が便利だった
・静的検証もまぁ、いいものです