日付：1999/10/20
SETI＠Support-part10(Ver0.5-Part2)前述したとおり、私は「どんな表示にしたものやら」と思いつつとにかく星図作成ソフトをインターネットであさっていたのである。
これまた前述したサイトは実に親切なサイトであった。そこで使っている星図表示Appletのソースコードがダウンロードできるばかりではなく、星の座標系がどのような仕組みになっているかの解説文書まで表示されているのである。（ちなみに所以はしらないが、星の座標系は地図でいうところの緯度にあたるものはそのまま度で表示されるが、経度にあたるほうは何時何分何秒と表示されるのである）
さて、そこからダウンロードしたソースをみながらしばし考えた。ここで私がやることは３次元の空間において二つの角度で表されている方向データをなんとか２次元の画面に変換して表示することだ。過去数ヶ月日長インターネットで遊んでいて気がついたことがある。インターネット上で情報をあさるさい、コンピュータに関係したことだとかなり良質の情報が得られる可能性が高い。しかしそれに関係ない情報だとさっぱりだ。この３次元-２次元座標変換などはきっとどのコンピューターのコースでも教えることだから使える情報が存在しているのに違いない。
そう思って捜してみるとかなりたくさんのサイトがヒットした。つれつれと見ていると三角関数の山である。これは結構性能に響くかもしれない。
なことを考えていると、それらの式に見覚えがあることに気がつきはじめた。そうだ。今をさることを５年ほど前、私が直接プログラムを書いて飯を食っていた２年間にこれは山ほどみた変換式ではないか。私がやっていた仕事はワークステーション上で戦闘シミュレーションをつくることであり、データはすべて３次元座標でもっていたから何かと座標変換は必要なのであった。
うむ。５年とはいえ、一時は心血そそいでつくったプログラムのことをこうも簡単に忘れてしまうとは、と悔やんでいる暇もない。私はあちこちで学んだアルゴリズムをプログラムにし出した。まずは独立したアプリケーションとして作成する。この時点ではこの３次元表示をどのようにSETI@Supportに組み入れるか決めていなかったからである。可能性はいくつかあった。SkyMapをそっくりいれかえる手もあっただろうし、あるいはSpecial Functionとして別のウィンドウで表示する手もあっる。とりあえずどんなに見えるか、ということがわかり、腹が決まるまでは別にしておいたほうが何かと無難だ。
さて、例によってやることがないので、だいたいこうしたプログラム作成は仕事中に（一応人目を忍んで）やっている。とはいっても込み入った話だとプリントアウトしなければさすがに困ることもある。３次元-２次元の変換式を示したプリントアウトを机の上においてごそごそやっていたら、職場の同僚に見つかって「なんだか懐かしい式ですね」と言われた。彼らは情報関係学科の出身だからこうした式というのは学校でならっていたのだろう。私は（内心あわてながら）落ち着いた風を装い「ははは。ちょっと情報をあさっている間に気になることがあってね」と言ってごまかした。まさかあやしげなJava Applicationの開発をやっているなどとは口が裂けても言えない。
さて、こうしたプログラムをしょこしょこつくりはじめたのは日付で見ると１０月５日頃である。ちょっと昔の事を思い出しながらつくりあげていくと存外に簡単にテストデータは表示された。（ちなみにこのテストデータは0h0m0s, 0degを中心とした十字架だったが）さてここから話はやっかいになりだす。
まず前述した星のデータを入れてみる。すると（これがプログラムのいいところだ。点一つだろうが、点９０００個だろうが、とりあえずそれなりにプログラムを書いておけば、「なんっすか？５つ点を打ったと思ったら、今度は９０００すか？冗談じゃないっすよー！」などとは言わない。。滅多には）ちゃんとテスト画面に星空（らしきもの）が表示された。すごいぞ。これで思ったより早く機能が実現できるではないか、と思った数秒後にはその考えをあっさりすてた。今までの例から言ってそんなことが起こるわけはないのである。
さて、星空を眺めて喜ぶこと数分。次には星座のデータを放り込んでみた。どきどきしながら表示をさせてみると、これは失敗であることがわかった。確かに空一杯に青い線（星座は青い線で表示するようにしていた）が表示されている。しかしその線の集まりが何かの意味をしめしているようにはどうしても見えない。だいたいあちこちで線が交差しているのである。星座の線がそんなに簡単に交差していいものだろうか？理由はわからないがとにかくどこかがおかしいようだ。
その週はだいたいそんなことをあれこれやりながらプログラムを作っていった。視点を動かしていくのは画面をドラッグすることで実現することにした。最初は「わーい。お空がぐりんぐりん動く」と喜んでいたが、そのうち妙なことに気がついた。たとえば視点を上げていって（これは緯度を上げると言うことだが）９０度に達する。すると天の北極とでもいう点が見える。そこをすぎると今度は緯度が下がりはじめる。しかしそこで視点を横に動かそうと思うとどう考えても期待したのとは違う動きになってしまう。
この問題がなんとかならないかと思ってあれこれ試してみたがどうしてもうまく動いてくれない。しかしそのうちふと思い出した。これは５年前に作ったプログラムで、別の人間に「この妙な表示をなんとかしろ」と何度もしつこく言ったのとまさしく同じ問題ではないか。彼はしつこい私の注文にもめげずに何度かプログラムを改良したが、私はOKをださなかった。それと今同じ問題に私は直面しているのだ。そして彼が言った「天の北極を越えたところで、座標系が右手系から左手系に変わるんですよ」という言葉を思い出した。当時私は「ふーん」とか言ってその言葉を聞き流した覚えがあるが、なるほどあれはこういう意味であったか。。等と今更感動しても始まらない。そしてもっと間抜けなことに最終的にその時どうやってその問題に決着をつけたが覚えていないのである。肝心な記憶は、肝心な時がすぎるまで絶対によみがえらない仕組みになっている自分の頭を呪いながら私は適当に考えた方法でけりを付けた。思えば参考にしたプログラムの緯度経度の移動方法がちょっと変わっているなと思ってはいたが、あれはこの為であったか。
などということを考えながらあれこれ機能を付けていった。３次元的な表示の他に、従来からあるSkyMapのような２次元表示もつけるのだが、これがなかなか難関であった。何が難関といって（これまた５年前のプログラムでも苦労したことだが）角度が０から３６０度まで増えていくと今度は０度に戻る、というのが実にやっかいであった。
何のことか？と思われるかもしれない。たとえばこうだ。５度と１０度の差は５度である。では３５５度と０度の差はいくつだろうか？３５５度どいうのも答えの一つだろうが、普通は５度という答えが返ってほしいところである。ところがこれをプログラムで書こうとするとなかなかややこしい。そもそも３５５度では何故いけないのか？などとあれこれお考えていくと話はとてもややこしくなる。
めげずに作っていくとなんとか動きは収束しだす。しかし肝心の星座データのほうはあいかわらずやたらと込み入って線が交差したままだ。これではなんともならんか。。などと思っている時に妙なことに気がついた。
座標軸を示すシンボルをつけて表示のテストをしていたときのことである。最初に試験てきに一つだけシンボルを表示してみた。どうやらうまく動いているようだ、と思いその後わらわらシンボルの数をふやしていった。一見まともに動いているように見えたから最初はご機嫌であった。
そのうち別の問題に対処するために、またもやシンボルを一つにしてあれこれ視点を動かしていた時のことである。シンボルが見える。ぐるりとまわすとまたシンボルが見える。。。というのをぼーっと繰り返していて、あれ？３６０度回すとシンボルが見えるはずなのに、１８０度まわしただけでシンボルが見えてしまった？
あれ？と思うとどうやら自分の後頭部であるべき方向のものが前方に映し出されているようである。うむ。そういえばこの問題も昔やったような気がするな、、とか思いながらこしょこしょと直した。それと同時に私はある罪悪感を感じていたのである。私はそれまで星座がむちゃくちゃに表示されるのを「このデータは信用できない」と思っていたのだがあれはとんだぬれぎぬだったかもしれない。
あれこれ直して星座を表示させてみれば、見事にその姿が浮かび上がった。やはり私は他人にいちゃもんをつけていたのだ。星座のデータそのものは正しい物だった。
さて、こうなるとだいたい新しい表示画面の機能はできあがり、である。確かにあと付け加えたい機能もあるのだが、どうやらSETI@Supportの本体と結合してからやったほうがよさそうだ。それから私は意を決してプログラムの結合作業に取り組みはじめたのだが、これは結構複雑な状況の元で行われることになった。
理由は二つある。一つは長年使っていたVisual Cafeに別れをつげるときが来たことだ。Windows版のVisual CafeはもうVer3になっているが、Macintosh版はVer2.0でとまっている。それでもなんとかだましだまし使ってきたが、最近どうにもこうにもへんな現象が起こりつつある。時によっては最終的にできあがるjarファイルに自分自身をくっつけてしまいファイルが巨大になっていったり、またデバッグ機能はだいぶまえから使えなくなっている。
さて、今Macintoshで使える開発環境というのは、BASICをのぞけばMetrowerksの製品しか存在していない。幸いなことにそこからでているCodeWariierというのは結構高い評価を得ていて、かつJAVAの対応もしている。前からそれは知っていたのだが、なんせ日本で売っている奴は値段が高い。６万円から８万円はするのだ。そんなにだすくらいだったら、多少難があってもVisula Cafeを使ったほうがましだ、、と思って使い続けてきたのだが。
さてそんなある日、例によって暇な私はあちこちのサイトを見ていた。そして米国の通販サイトをみて、「おや」と思ったのである。どうやら米国ではCode WarrierのJAVA部分だけ取り出した物が（Windows, Mac,Solaris対応で）＄１００以下で売られて居るではないか。これだこれだ。と思って早速購入しようと思ったが一つ難点があった。会社の広告には確かにMacintosh対応が歌われているのだが、その通販サイトではWindows,Solaris対応となっている。はたしてどちらが正しいのか？だいぶまよったが、もし＄１００以下で新しいJAVAの開発環境（おまけにWInodwsの環境も付属している）が手にはいるとなれば、これは大変うれしい話だ。私は賭けに出ることにした。通販サイトで注文をしたのである。
さて、それから数日後実家の父からメールがとどいた「なんだか小包が届いてるよ」というやつだ。１０月１０日あたりの３連休、私は４連休にして途中実家によった。届いている箱を見ればまごうことなきCode Warrier for JAVAである。やったやった。
私はご機嫌になってアパートに帰り、さっそくインストールしてみた。するとそれまで４００ＭＢくらいはあったディスクの空き容量がいっきに１６０ＭＢなった。何だこれは？と思ったがまあとりあえずまだ空きはあるのだから問題はない。次にえいやとたちあげてみる。「マニュアルを読まなければ使えない」とはVisual Cafeを使いはじめたときにも学んだ教訓であったが、このときはその教訓をきれいさっぱり忘れていた。そしてまたもや同じ教訓を得ることになったのである。
操作はどことなく似ている。空のプロジェクトなるものを作り、そこにソースコードのファイルをわらわら足していって、そしてコンパイルをすれば動くはずだ、、と思いやりはじめたがなかなかそう簡単には動いてくれない。まず空のプロジェクトはでてきたが、そこにソースコードを足す時点ですでに躓いてしまった。未だに何が悪かったかわからないのだが、ソースコードを追加することがどうしてもできないのである。素直にマニュアルを読んで一からやればいいものを、しばらくの間私は無駄な努力を続けた。そして数十分の後に、またVisual Cafeを立ち上げていたのである。そりゃ多少難はあるけど、こっちは動くから。
そのままであればCode Warrierはしばらく埃をかぶっていたかもしれない。しかし幸いなことにWindowsバージョンも同梱されていたのである。翌日CD-ROMとマニュアルを会社に持っていき、会社のマシンにインストールすると（これのおかげでFree BSDをつぶしてしまったが）しょこしょこと勉強をはじめた。例によって時間は山ほどあるのだが、なんとなく気が引ける。一応人目をしのびながら、昼休み時間を使いながらの勉強だからのんびりしたものだが、そのうちなんとか従来のVer0.43のファイルを使ってプログラムを動かせるようになった。
さて、数行前で「複雑な状況」と書いた理由その２である。こうして私が新しい環境になじもうとしている時に、Ver0.43に対してあれやこれやのバグレポートが届きはじめたのである。
まず最初に来たのは「プログラムの終了・起動を繰り返すと、ウィンドウが大きくなってしまう」という現象である。実はこの現象についてはそれまで薄々気づいてはいたのである。Windowsで実行させているときしか発生しないが、「あれ？なんだかウィンドウが大きくなったような。。いやいや。気のせい気のせい」と自分をごまかしてそれまで暮らしてきたのだ。
ところがそう指摘をうけてきちんと試験をしてみると、確かに巨大化していく。不思議なことに縦の方向にだけのび、横幅が増えるわけではないのだが。ううむ。やはり自分だけ「気のせい」と思ってもバグは消えるわけではなかったか。
さて、それを直して、（他の改良点もちょっとだけ加えて）Ver0.44をリリースした。普通だったらきりのいいVer0.45にするところだが、Verを0.2あげるには、あまりに機能追加が少ない、と思い、控えめに0.1だけ足してみたのである。
さて、翌日バグを指摘してくれた人からまたメールが届いた。
「ウィンドウの拡大はなおりましたが、今度はプログラムが立ち上がらなくなりました」
うげげげげと思い続きを読むと、どうやら過去のデータを記録しているファイルを手動で書き直したのが原因らしい。しかしそこは確か前にフォーマットが異なっていてもプログラムは動作するように直したはずなのだが。。。
そう思ってリストをみると、やはり問題は生じていた。一度は対策をしたのだが、その後「プログラムをきれいにしよう」と思いああれこれいじっている間にまた問題が紛れ込んでしまったのである。それまで本能の赴くままに関数を追加してきたが、さすがにファイルが読みにくくなってきている。これはいけない、とあれこれ整理したり、関数をまとめたり分割したりしたのが徒となった。私は数日後に0.44aというバージョンをリリースした。
やれやれ、と思っているとまた別の方からメールが届く。今度は
「ウィンドウのサイズが元のSkyMapより大きくなると表示がずれる」というものだった。この人は親切に推定原因まで書いてきてくれた。うげげげと思い、またソースを見ると確かにどんぴしゃり、指摘通りの問題が存在している。
それをまた直して0.44bという名前でリリースしたのは１８日のことであった。かくのごとくVer0.4Xのバグ取りに追われていると、どうしてもVer0.5どころではなくなる。また予定ではVer0.4シリーズはソースを凍結し、全面的にCode Warrier+Ver0.5に移行するはずだったのが、それどころの状況ではない。結果としてVer0.4+Visual Cafeは私が予想したより長く生き延びることになった。
それから数日私は「まだ何かあやしげなバグが発見されるのではないか」という不安におびえてくらした。Ver0.5もVer0.4と平行して開発されており、Ver0.4に加えた変更はVer0.5にも間違いなく反映させなければならない。そしてそれはなかなかやっかいな仕事になりつつあったのである。
しかし私のそうした懸念をよそに、幸いにも事態は収束に向かいだしたようだ。そうしてようやく心おきなく私はVer0.5の一番面倒な局面にとりかかることになったのである。それまで別のプログラムとして作ってきた2D/3D表示プログラムとSETI@Support本体を結合するという仕事に。
注釈