ところが問題はまだあった。Explorerでページをめくった状態で、行間やフォントのサイズを変更するとなんと妙な無限ループにはいることが判明したのである。これはもっと大きな問題だ。世の中にはMicrosoftのJava環境を使っている人のほうがずっと多いだろうから、もしこれを公開して、かつ使ってみるという奇特な人ができた場合には、私はひどい文句を被ることになる。なんとかやっていたら結構日が経ってしまった。おまけにその間にホームページのコンテンツの方の更新は止まったままである。探求してみたら、無限ループの原因は非常に奇妙なところにあった。-1){(何かの処理:indexToDisplayはさわってません。)}else{(別の処理:indexToDisplayはさわってません。break;"などという妙なメッセージがconsoleに表示されることはありえない。ところが現実問題としてこのメッセージが表示されるのである。ここでプログラムの経験の浅い人であれば「コンパイラのバグだ」と声高らかに叫ぶであろう。CもしくはC++のプログラマである程度経験をつんだ人であれば、「それはきっと配列かポインタの処理を間違えて、さわっていないつもりの領域を書き換えちゃったんだよ」と言うだろう。z;などという宣言があり、x[10]あたりを書き換えれば、zがとんでもない値になっても文句は言えない。プログラム中でZを一回もさわらないにもかかわらずである。(実際これはとても問題があり、見つけにくいバグだ)ところがぎっちょん。たてまえから言えばこれはJavaではおこらないはずなのだ。(それがJavaの売りの一つなのだから)ポインタは存在しないし、私はこの部分では配列すら使用していない。現実は認めなくてはならない。実際上記のプログラムで妙なメッセージは表示されるのだ。このバグをとろとうしている最中にもう一つ気づいたことがある。MRJ2.0とMicrosoftのjavaでは、どうも各コンポーネントにpaint()を送っているタイミングが違うようだ、ということである。MRJ2.0でうまく表示されるようにすると、Microsoftでやたら画面が書き換えられ、ちらつく。Microfostでのちらつきを押さえると、今度はMRJでちゃんと表示がなされない。なんだこれは?と思ってはみたもののこれまた事実は尊重しなくてはならない。いいながらもなんとか文章を表示し、ページをめくる、という当初の目的は達成されつつあった。そこから一歩進もうとした瞬間、私はデータベースの構造をもっと慎重に考える必要があることに気がついた。いままでは「とにかく表示できればいいや」とやってきたのだが、まじめに考えないとデータが崩壊してしまいそうだ。今のプログラムも使っていないインスタンス変数がやたらたくさんできてしまっている。そこで私は紙の上に戻り、データ構造を考えることにした。いった方法の一つの欠点は、紙に書いている途中から「こんなものを書いているくらいだったら、プログラムを書いたほうが早いわい」と叫んで、コーディングにかかってしまい、、、同じ問題を繰り返す危険性があることである。今回、私はその誘惑からかろうじて逃げおおせた。2月も終わりに近づいたある日、とうとうなんとか文章表示部分がちゃんと動くようになった。データ構造をちゃんと考え直したおかげで、なんとかまともに動いているように見える。4.0で妙な文字が表示される原因も分かった。これは全く日頃からの主張に反するばかげたデバッグをやったがために見つからないバグだった。プログラム中では、java.awt.canvasに対してdrawStringを呼んでいるが、「理論的」にはここで引数に「¥n」渡らない「はず」である。従って私は妙な文字がまぎれこんでいるのではないか、などと血眼になって原因を探していたのである。ところが原因はまさにその「はず」が「はず」でない、というあまりにもありふれたところにあった。drawStringの引数をチェックしたら、紛れもなく"¥n"がわたっていたのである。それさえわかれば直すのは簡単であった。不具合の時は、まず一番直接的なところから「事実」を確かめていくべきだ、とは何度も何度も痛い目をして学んだ経験のはずだ。直接的な原因は「理論的にあり得ない」と目をつぶってしまい、あさってのほうばかり探求していたのである。一時はソフトウェアのほうで職を探そうか、と思った人間がやっていることがこれである。私は出来の悪いアマチュアか。妙な落ち込みをしている場合ではない。(まだ問題はいくらでもあるが)文章の表示(含む注記の表示、一連のファイルの表示)ができてしまったのである。本来の目的である「Javaを使ったナビゲーション」の実現の時だ!そこで私はまたもや自分の知恵の浅はかさを思い知ることになる。何を作ったらいいか?という問題に突き当たってそこからしばらく進めなくなったのである。おまけに気候はようやく春になろうとしていた。春になれば気候がよくなり、、、はれた平日に部屋の中でコンピュータに向かってプログラムを書いていることがいかにばかばかしいか。おまけに私は職も探していた。明るくなった窓の外を見て感慨に耽っている場合ではない。職が見つかり、このプログラムが半分できたまま放置されるような事態になってはならない。深遠な理想は理想としてがりがりと進めなくてはならない。動くようにしなければ、このプログラムは一生日の目を見ないだろう。幸いなことになんとなく私が気にいった画面があった。JDKについてくる、Sun特製のGraphLayoutというアプレットである。実のところ何をやっているのかわからないが、リンクされたノードがぐにょぐにょと動きながらいつしか平衡状態に落ち着いていく、というプログラムだ。この画面が私の気に入るところとなったか?早い話、今回作った駄文の山はリンクのスパゲッティのような代物である。文章と文章は共通のキーワードや参考文献を介してリンクされていたりする。ことは、そういったリンクをつりつりとたどっていくような形で構成が表示できれば、この文章から、このキーワード、そしてほかの文章、という感じに文章を読み渡っていくことができる(のではないか)と考えたのである。このGraphLayoutの画面はそういった構造を表示するのにぴったりの機能をもっていた。一案として、link集のところで用いたのと同じような構造の画面、すなわちJavaの標準コンポーネントを使って(リストとかテキストとか。)表示する画面も考えた。考えてもおもしろくない。こんな画面だったら仕事でも作れる。素人が暇つぶしにやっていることだから、おもしろくしようじゃねぇの。いうわけで、GraphLayoutを基本にして(というかコピーを下敷きにして)しょこしょこプログラムを作り始めた。あたりまえと言えばあたりまえなのだが、文章のタイトルを表示するところまでは実に簡単にすすんだ。本来であれば、これまで避けてきたThreadに関する勉強をこのとき私はするべきであった。グラフがグニョグニョ動くアニメーションはthreadを用いて実装されていたからである。プログラムをみてみればSynchronizedとかいう見慣れないキーワードがでてくる。これは何だ?と思ったが「とりあえず前進」というこれまた何度も痛い目にあったが、こりない方針に従って適当に作り始めた。2-3日で文章のタイトル、参考文献のタイトル、キーワード(トピックスと呼んでるが)を表示するところまではできた。問題は「並べ替え」であった。並べ替えが必要か?たとえばあるタイトルを選んだ時に、それに関連する項目がそのタイトルの近くに集まるようにしたかったからである。基本的なアルゴリズムは「隣をみる。自分より重いやつが自分より上にいたら、そいつを押しのけて上に行く」とこんだけである。そこで適当にインプリメントしてみると、これがまた妙におもしろいアニメーションを表示することがわかった。それとともにいろいろ欠けている機能にも気がついた。最終的にノードとノードの距離を一定に保ち、かつ画面内におさめなくてはならず。場当たり的にアルゴリズムを追加していった結果として、私は二つのことに気がついた。1つは全くアルゴリズムが何をやっているのか自分でも理解ができなくなったことである。ひとつはソートの最中のアニメーションが妙におもしろくなったことである。理解できないアルゴリズムがうまく動く可能性はとても少ない。ソートも不完全なものだった。ノードは重なってしまうし、やたらはずれた方向に表示がなされたりする。不思議なことにテストしたすべてのケースで最終的にはノードの動きは収束し、かつそれまでのアニメーションはとても意図してできるとは思えないほどおもしろかった。いうわけで私はしばしばその画面に見とれていた。遠い昔の日々、PC-8001で機械語のプログラムを必死に雑誌から打ち込んでいた頃、時々「こんなおもしろい画面ができるか」と思えるような「暴走」の仕方をすることがあった。私はその遠い日の思い出にひたっていた。冷静に帰って考えてみると、自分で作った画面に見とれている30男(しかも失業中)というのはあまりほめられた図ではない。おまけに外は明るい日差しにあふれた春の日だ。我に返った私はもうちょっとまともなアルゴリズムを考えることにした。幸いなことにある日私は来るまで遠くにおでかけであった。この日はいやでもコンピュータにさわることはできないし、ハンドルを握っている間考える時間はたっぷりある。Stupid"に従って考えてみると、、なんだ簡単にできるではないか。多少のことには目をつぶろう。少なくともこのアルゴリズムで行けば自分が何をやっているか理解できなくなることはなさそうだ。翌日さっそく私はそのアルゴリズムをインプリメントした。例によっていろいろなバグをぷちぷちつぶしていくと。おっと見事に動くではないか。気が抜けるほどあっさり動いた。ところが残念なことにアニメーションは全くおもしろくなくなってしまった。アルゴリズムが単純明快だからあたりまえと言えばあたりまえなのだが。これであとはナビゲーション画面とテキスト表示画面の結合だ。(いままでは面倒をさけるため別のアプレットとして作成して試験をしていたのである。)ここでまたもう一つのハードルにチャレンジする必要に迫られた。普通のアプリケーションであれば、ナビゲーション画面は別のウィンドウに表示して、いつでも参照できるようにしたいところである。アプレットから別のウィンドウを開こうとするといろいろ面倒だ。Window」とかいう表示が自動的についてしまう(Security上の配慮なのだそうだ)ただでさえ狭い画面がますます狭くなってしまうではないか。おまけにいままでFrameは使ったことがないのである。言っている場合ではない。Frameを使ったウィンドウにいろいろ表示するプログラムを書いてみたのだが。確かに新しいウィンドウは表示される(例の「警告文書」付きだが)。ところがなぜかその上に配置したはずのコンポーネントは表示されないのである。私はその「小さな」のっぺらぼうのウィンドウを眺めてしばらく凍り付いていた。これから新しい「Frame」にチャレンジする際に突き当たる出あろう困難に思いをはせていた。言ってここまでくるのに重大なバグをいくつも見逃してきている。いままでなんとか動いている、と思えるところだっって、まだバグだらけで人様に公開できるようになるまでには大分かかるだろう。頭をふって、Frameを頭のなかから追い払った。「Panelの上に表示するコンポーネントのvisibleを切り替える」というおもしろくはないが、間違いなく動く方法に転向した。二つの画面の結合は思ったよりスムーズにできた。文章を読み込んで、必要に応じてアクセスできるようにする部分をTextDBとしてデータベースクラスとして分離しておいたのが功を奏した。(ちなみにこれは以前仕事でプログラムを書いていたときにさんざんつかった手法である)そしてその日の夜には、とうとう最初に描いたような機能を持ったアプレットが動くようになった。ある特定の場合にのみである。例によって誤表示やらフリーズが連発する。デモには使用できるようなものができた。これからがまた長い道のりだ。今まで目をつむってきた課題リストは山のようになっている。「小さな」課題をつぶし、デバッグを延々と続けなくてはならない。不具合の時は、まず一番直接的なところから「事実」を確かめていくべきだ:後悔は有史以来先にたった試しはない。3度とは言わないが、なんとか4回くらい同じことをしたらなんとか学ぶことができるようにならないものだろうか。本文に戻る基本的なアルゴリズム:たぶんこのアルゴリズムはもっと洗練されて世の中で名前がついているのだろう本文に戻る機械語のプログラムを必死に雑誌から打ち込んでいた:いまではとても信じられないことだが、当時はこれができたのである。早いゲームは大抵機械語でかかれていて、しかも大きさは信じられないほど小さかった。わけのわからない16進数を延々と打ち込むのは若いからできたことかもしれないが。Stupid":KISSと略される。物事を単純に、馬鹿みたいにするようにつとめるという意味。非常にあちこちでお目にかかる言葉だが語源がどこかわからない。