日付：2003/3/27
Ver0.47をリリースした後、私は差出人によるフィルタ機能の洗練、アドレス帳の連携などに進むはずであった。ところが話はそうはすすまない。
ある日のことである。Webをあれこれ巡って情報を観ていた私はある記事に表示されていたスクリーンショットをみて驚いた。Gates様のMicrosoftがOutlookの新バージョンとしてリリースするOutlook11の画面である。
数々のユーザーテストを経て決まったというその画面配置は、私がVer0.47で試みたように題名一覧と本文が横に並んでいた。ただし私は
「これは使えない」
と思って放棄したのだが、やはり天下のMicrosoftがやることはひと味違う。それまで題名一覧と言えば一つのメールに関する情報を横に並べる物だと相場が決まっていたのだが、それを一列、２行に表示していたのである。
これは全く気がつかなかった。確かにこうすれば題名一覧の横幅は少なくて住み、本文の表示幅もたっぷりとれるというものである。その他にも一覧の中に「今日」「昨日」という区切りを入れ、その単位で折り畳めるようにするとか、自分でこうした機能を考えた事の無い人には
「ああ、そうなので」
だろうが、私のような素人設計者が観ると「をを」と思うような改善がいくつも盛り込まれている。
さて、こうしたいい物を観ると恥も外聞もなく取り入れるのが私の主義である。さっそくまねすることにしたが、実現は結構面倒そうだ。まず標準の表部品では、文字は左詰と決まっている。ところがOutlook11では差出人を左詰、受信日時を同じ行に右詰に表示している。おまけに１列２行に表示するのってどうするんだ。
後者の問題はあっさり解決した。あれこれ考えずに改行したいところに改行コードを挟めばよかったのである。案ずるより産むが安しとはこのことだ。餡汁より芋が安しとは井上ひさしの本にあったギャグだ。前者の問題もあれこれやったあげく解決した。しかし表示させて観るとどうにもまともに見えない。
ええい、と思ったあげく２行ではなく３行に情報を表示するようにした。うん。これ見やすいよね。見やすいよね、と自分に数度言い聞かせてみたがやはり見やすくない。あれこれ考えて差出人、受信日時、題名、それぞれの色を別個に設定できるようにした。色をかえれば少しは見やすいよね。見やすいよね、と数度言い聞かせると内なる自分の声は静まった。良しこれで行こう。
ところがあれこれ使っているとまた問題が見つかった。メーリングリストに二つくらい入っており、そのメールは特定のフォルダに放り込んである。メーリングリストから配布されるメールというのは、大抵の場合題名の中に[猫柳ML]とかいう文字列がついている。これは題名一覧を横にしている間は気にならなかったのだが、縦にして、幅が短くなった途端じゃまに感じるようになった。ひどい場合はこの[]内の文字列しか表示されない。幅を増やすと何の為に縦に並べたのかわからない。
ええい、しょうがない、と思ってそれまで必要性に気がついていながら見送ってきた機能を付けた。すなわち[]内の文字列を表示しない機能である。参考にしたNameraというメーラではフォルダ毎にこの文字列が指定でき、おまけに片側だけしているすることもできる。きっとそれができると便利な事もあるのだろう。しかしそれの実現は結構面倒だ。私はえいや、と対象文字列を[]に固定してしまうことにした。うん。これはVer0.5で見直そうね。（こうやってだんだんVer0.5が遠のいて行くのだが）
さて、以上が外見の変更。それとともにこのバージョンでは内部処理を（またもや）変更した。Ver0.47において
「フォルダが変更されたがチェックするのは、メールを送受信したときだけ」
と変更したことは前述した。これにより確かにディスクをごりごり読みに行く回数は減った。ところがメールの送受信はユーザー操作と関係無しに起こりうるから
「あれ？プログラムが動かなくなった。虹色アイコンがぐるぐるしてる。ああ、フォルダのチェックをしているわけね」
ということが頻繁に起こる。以前はフォルダを選択したら待たされるぞ、と心の準備をしていたが、今度は心の準備のしようがない。ふいに動作が止まるのはあまり快適とは言えない。
どうしてくれよう、と考えるが解決策は多分一つしかない。今まで観ない振りをしてきた「マルチスレッド化」だ。つまりフォルダの中身をチェックする処理を別のスレッドに任せ、GMail本体の方は（あまり）影響を受けずに処理を続行する、という仕組み。さて、問題です。何故私はこのマルチスレッド化を避けて通って来たのでしょう。
理由はいくつもある。まず第一にマルチスレッド化というのは何かとトラブルの元になる。今まで上から下に整然と実行されると思っていたプログラムが途中で妙なことをやってくれるかもしれないのである。第２に今までGBPutでもマルチスレッド化にトライした。そして実際使っているのだが、何故かjust leaking...とかいうこれまた何より恐ろしいMemory Leakというのを想起させるエラーメッセージを軽快にはき出してくれる。これはとても恐ろしい。
しかしどうやら逃げ道はないようだ。とはいっても自分でひょこひょこ書いてみるほど自信家でもない。あっさり本を買うことにした。Javaが普及し始めてはや何年。当初は「Javaって何？」的な本ばかりだったが、今やJavaのマルチスレッドプログラミングだけについて書かれた本も存在するのだ。いや、これは会社の業務にも広く活用できると信じますなどといって会社で購入すると業務の合間に読みふける。最近は「デザインパターン」などという言葉が普及しており、定石の処理に対する定石のプログラミング方法が紹介されている。みていくとこれが使えそう。をを。パターン万歳である。さっそくその方法に従ってプログラムを書いてみる。
前述したとおり私はマルチスレッドプログラムを大変恐れていたから最初はびくびくだった。ところが（数々の失敗の後）プログラムは予想より簡単に動き出した。やれ、うれしや。これで操作感は格段に向上することであろう、と思ったのは半日も続かなかった。せっかく苦労して別スレッドで動かしているというのに、メールのチェックが始まるとやはり他の操作がほとんどできなくなるのである。
問題は何かと言えば、フォルダの数と同じ数のスレッドが一斉に動き出すからではなかろうか、、と思い同時に動くスレッドの数をだんだん減らしていく。試行錯誤の末たどり着いた値は２である。つまり本体のスレッドとあと二つしか動かせないというわけだ。まあこれでもちゃんと動くからいいか。
やれ、これで念願のマルチスレッド化も完了、と喜ぶことはできなかった。このころからプログラムがふいに落ちる（いきなり終了する）というトラブルに見舞われるようになったのである。終了する際に何か言ってくれればこちらも対処のしようがある物を黙って終了する。ええい、しょうがないと思いつつある日なんだかObjective-Cが発していると思われるエラーメッセージを目にした。ふーんと思い以前苦労してObjective-Cで書いたメール読み込みルーチンをJavaに戻す。すると確かに速度は低下したのだが不意に終了することも少なくなったように思う。これは「少なくなった」のであってなくなったのではない。（この問題は未だに存在している）しかし私はその結果に満足して0.49としてリリースすることとした。
0.49ではもう一つ大きなバグを直した。フォルダの内容更新アルゴリズムをあれこれいじっているうちに
「どうもメールの移動をさせると変なことが起こる」
ことに気がついていたのである。変だな変だなと思っているとそのうち指定した時間がすぎメールの受信が行われる。するとフォルダの内容が自動的に更新されるから表示は正常に戻る。まあいいや、と納得する。今から考えるととんでもないいいかげんな話だが実際私はそう考えていた。
しかしその動作のおかしさが自分ですら我慢できないようになってきた。ええい、一体どうなっているのだ、と思いプログラムの該当部分を眺めてみる。すると気がつく。本来あるべきメール移動の処理が全く書かれていないではないか。なんだこれは。いつの間にかソースが前のバージョンに戻ってしまったとでもいうのか。そんな言い訳を２０も考えた後避けようのない事実につきあたる。ようするにバグとかそういう問題ではなく私はメール移動の処理をちゃんと書いていなかったのだ。
しばし呆然とした後ちょこちょこと直すとちゃんと動くようになる。しかしあまりにも恥ずかしいから0.491のリリースノートには
「メール移動のバグを修正 」
とだけ書いた。
さて、この後少し環境に変化が生じた。OMEというのはいくつかのプログラムをまとめて配布されるようになっている。GMailはその中にはいっていないかったのである。これはもともと
「使ってもらえるのはうれしいけど、きっとバグが有るに違いない」
と思った私が
「二軍扱いでお願いします」
とか妙な事をいったためなのだ。従ってGMailを普通の人が使おうと思えばメーリングリストに流れるアナウンスを観るか、あるいは「デベロッパー」というところからリンクをたどる必要があった。
ところがそろそろ、ということで「配布されるまとまり」の中に入れてもらえる事になったのである。こうなるとユーザーも増えるしそれに伴って発見されるバグも増えるだろう、と思っていたら本当にそれはやってきたのである。
まずは「立ち上がりません」という報告がメーリングリストに流れる。うげげげと思いながらあれこれ聞いてみると、起動時に「Draft」という下書きを入れておくフォルダがないとすねているようだ。あれ？このフォルダが起動時に見つからなければ作る処理をいれておいたはずだが、、、と思ってプログラムをあれこれ読む。するとやれメールのヘッダを記録しておくとかそんな処理を付け加えているうちにそのチェックがうまく働かなくなっていることに気がつく。しょうがない、と思い一行移動させ0.492としてアップロードした。
翌日会社に行き、私の机の上にあるiMacでGMailをダウンロードし、Draftフォルダがない状態で使ってみる。直したから大丈夫、と思いドックの中ではね回るアイコンを観ているが、それがしゅうとしぼんで消えてしまった。つまり立ち上がらなかったのである。
私は泡を食って原因を調べる。すると直したつもりのプログラムは全然直っていなかったことに気がつく。おかしい一応試験はしたはずだったが、などと言い訳をしてもしょうがない。今度こそとプログラムを改修し、念をいれて会社のiMacでも試験をし、とやったところで0.493をリリースした。
次に報告されたのはもっと恥ずかしいバグだった。電子メールのサーバーに接続する設定をする画面があるのだが、そこにある「送信者名」と「送信アドレス」が反対になっているというのである。画面をみればまさにその通り、ああ、なんて間抜けな。泡をくってそこを直し0.494とする。更には「メールの削除がうまくできません」というレポートが届く。私がぎくっとする。この削除処理というのは
「なーんとなくこれでいいだろう」
と思って作ってはいたが、どうにも心にやましいところがある処理だったのである。自分の環境では動いているからいいだろうと思っていたがやはり問題が、、と思いあれこれトライする。最初はトラブルが再現しなかったが、会社のiMac上であれこれやってみるうち見事に同じ問題が発生した。
このファイルをゴミ箱に捨てる、という処理は本来であればシステムが持っている機能を使うべきなのである。ところがそれらしき関数を何度使ってもうまく削除されない。であるからいわば「まにあわせ」の方法でごまかしていたわけだが、こうして目の前で問題が起こってしまった以上逃げるわけにはいかない。さらにあれこれトライすること数日。ようやく正しい（と思われる）システム関数の使い方が解る。やれ、うれしやと思いさっそくリリースとはいかない。もう一つ問題に気がついていたのだ。送受信処理が終わった後には必ずフォルダの更新を行う。この最中にもう一度送受信処理を行うとフォルダ表示が自分でも説明がつかないくらいがたがたに崩れるのだ。何故こんな事が起こる、と考えてみたがどうにもよくわからない。ええい、フォルダ更新中は送受信ができないようにしてしまえ、と処理を変更する。この二つの変更を反映してVer0.495としてリリースする。
ここらへん細かなバグフィックスを少数点以下３桁の変更で識別しているが、この調子で改修箇所が１０を越えたらどうしよう、と不安になる。バグフィックスの積み重ねだけで0.5に到達するのは避けたい。しかしすでにこのときまだ報告されないが自分は気がついていた大きなバグが私を悩ませていたのである。
注釈