条件網羅ホワイトテストのような、予定された項目から枝刈するものでないとき。

どちらかといえば、想定外のバグをアドホックに調べてつぶすとき、
大事なことはいろいろあるけれども、総合すると「仮説を立てる力」だと思う。

①症状（命題）を確認する
②原因に関する仮説をある粒度で立てる
③仮説を検証する
④実証されなければ②に戻る
⑤実証されれば、仮説を細かい粒度に分解し③に戻る
⑥実用上十分な粒度の仮説が実証されれば解とする

この仮説を立てるという作業がなかなか厄介です。
症状に関連しそうな物事について、ある程度把握していないと
関係ありそうなことのリストアップもできませんし、
ましてや、コンピュータのインプットとアウトプットもわかりません。

例えば、Windows2003のIIS6.0上でASP.NETの提供するXMLWebサービスを作成したとして、
Webサービス呼び出しの引数に5MBぐらいのバイナリデータを与えたところ、
Webサービスが例外を吐いたとしたら、
その原因究明はどのように行えばよいでしょうか？

別に仮説なんか立てなくても、有効な方法はたくさんあります。
デバッガなどで例外の詳細情報を取得しても、何か手がかりはあるでしょう。
しかし、実行する以外の方法で見当をつけるなら、それは仮説以外の何者でもありません。

いろいろな原因が考えられるでしょう。
問題文以外のことが原因かもしれません。そうするとネットワークのダウンなども理由になりえます。
しかし、起こりそうにないことから順に調べても、時間の無駄です。
起こりうる原因をいくつも考えて、その中でもっとも可能性の高いものから順に調べなければなりません。

原因としてもっとも可能性が高いのは、IIS6.0のリクエストサイズに上限があるということですが、
この仮説にいたるには、いろいろ過程があるのでしょうが、割愛します。
私の場合は、過去に本やWebで、セキュリティ対策としてリクエストサイズの上限を小さくしたということを知っていただけです。

そして仮説を立てたならば、それのみを実証できる検証を行う必要があります。
リクエストサイズが無制限とするなら、
つまり、コンピュータ独自の制限である整数型の上限値であっても、成功するはずである、となります。
ということは、1バイトのデータも、2GB-1バイトのデータも同値領域です。

もちろんプロセス空間のメモリ上限等の問題が発生しますので、
サイズを控えめに、問題文とおなじ5MBで検証することでしょう。
今回の仮説は、リクエストサイズ上限の初期値が4MBであるので、それが原因であるとするなら、そのものずばりな仮説です。
（そうなるように私が意図して選んだ問題なので。）

仮説力を鍛えるのは、幅広い基礎知識と、相互に関連性を理解することだと思います。
どっちが欠けても役に立ちません。

闇雲にコードを読んでる人、とりあえず実行してる人、適当にぐぐってる人というのは
作業してるように見えて、何も前には進んでいません。
偶然解決したとしても、です。

対応した人に、原因の説明を求めたり、
もう一度同じような症状が出た場合は確実に直せるかと聞いてみたりすると、
その人が本当に理解してるかどうかが、よくわかります。

トラブルシューティングがなかなか上達しないと思うとき、ぜひお試しあれ。


コンピュータ（プログラム）の動作の一挙手一投足がわかる人は、
コンピュータは、自らが保持しているデータと、インプットされたデータのみに基づいて、
アウトプットのデータを作成する、ということを正しく理解している人のように思えます。
アルゴリズムの埋め込みデータは、どちらの分類になるかは問いません。

さらに眠いＺｚｚ

昨日から、Visual Studio .NET 2005の店頭販売が始まりましたね。
ほしいことはほしいんだけど、すぐ使うわけでもないし、2万とか3万とかするし、、、
ついでにSQLServer 2005も買うと、さらに1万、、、

そして最新の.NET Framework 2.0を使って作ると
動かない人が大半という罠！

VS2003アカデミックからでもスタンダードにアップグレードできるかな？

ようやくRoAddr.dllの代替版が、ある程度形になりました。
互換性を重視したので、文字列などを返す関数に、バッファを与えることはなくなりました。

ただ、RoAddr.dllの中に使ったことがない関数があるので、動作があってるかどうか、かなり不安です・・・。

汎用ライブラリです、と公開するとつぶされるまでの時間も早そうですが、
私個人で使ってるよりは、きっと役に立つはずなので公開することにしました。

つぶされて、なお私に回避する気力があったならば、
技術力のある方々のご協力をお願いしたいところです。

なんだかんだで、結局RoAddr.dll相当のものを作っちゃった…。
問題はこれが動くかどうか！

文字列やSOCKADDR_INを返すのに、バッファを引数にとらない関数は
引数にバッファのポインタとバッファサイズを加えたので
差し替えただけじゃクラッシュしちゃいますね。

あとエラーコード関係も作ってないし・・・。

でも既存のツールうち、Callbackしか使ってないものなら動くはず。