日々の破片

_ Rjb

バグ報告が来たよ。

Methodのimportもできないし、ResultSetのimportもできない。

でもそれはMiscProblemsで通ってるはずじゃんという指摘（日本語読めないと思うのに、良くあのページ見られたな。ソースは強い）。

で、あらためてやってみると確かにエラーになる。

J2SE 1.4.2には存在しなかった、配列の配列がJ2SE 1.5には含まれたからだ。たとえばMethod#getParameterAnnotationsとか。

というわけで修正するか。

追記：ついしてしまった。rjb-0.2.6.zip。でも、引数についてはまだやってない。戻り値だけ。

_ コンピュータ思想界のデビッドボウイ

という感じ。浅い感じを受けるからかな。

言葉はあるが、中身はない - 特別な言葉"ハイパーテキスト"を生んだテッド・ネルソン氏。

この本から着想を得たというが、それはそれとしてもおもしろそうな気もする。

Paddle-to-the-Sea(Holling, Holling C.)

参考：大島さんのメモ

_ printfデバッグ

使うよ。がんがんでもないけど、使う。

ソースコードレベルデバッガーを使えない過去の人ですか？

いや、違う。ソースコードレベルデバッガー「が」使えない処理があるということだ。

タイミング勝負のデバッグでは、ブレークさせると動作が変わるからだ。実行時の変数値の変化を見るにはprintfデバッグしかない。お金と資材があればprintfの先がデバイスってことはあるかも知れないけど、いずれにしろブレークさせないで変化を見る必要はあるのだ。

このようなプログラム、つまるところは生な処理、あるいは生に非常に近い処理、についてはprintfデバッグを前提としたコードを書いたほうが良い。そうじゃないと、デバッグのためにコードの構成をがらりと変えざるを得なくなる。つまりは、いちいちローカル変数（printf可能なもの）に突っ込むとかだ。2回アクセサ（ゲッタ）を呼ぶと、ゲッタの中で同期処理が走るために状態が変わるということもありえる。

int stat = obj.getState();
System.out.println("current stat=" + stat); #デバッグすっぺ。
if (stat == STATE.FOO) {
   ...

int stat = obj.getState();
if (stat == STATE.FOO) {
   ...

if (obj.getState() == STATE.FOO) {
 ...

と書くと、デバッグのためにソースをえらく（と言ってもint statの導入だけだけど）いじる必要があるということ。ただ、ここではprintfを入れなきゃ2行の修正だけど、こういう状態を見るためにprintfを入れるわけなので、30箇所くらいに入ることになる。すると、30行のprintfを突っ込むだけなのか、それとも30箇所のソースから影響を受けないように変数への切り出しをするのか、というような差になってくる。

このあたりは、JavaだろうがC#だろうが、やばそうなプログラムを書くときは、Cのように書くということなのだ、とちょっと思い出したので書いてみたり。