日付：2002/12/17
0.39でアプリケーション自体のアイコンはつけたのだが、各種操作に使うボタンの絵はAppleWorksのクリップアートをそのまま使っていた。えい、こっちもなんとかしてやろうとしょこしょこ作る。できた物はとりあえず「オリジナル」という以外には意義の認めたがたいものだが、まあいいや。
そんなことをやっている間にも扱う対象のメール数は日々増大していく。すると動作の遅さがどうにも気になり出す。フォルダを選ぶ。するとしばらくアイコンは虹色になってくるくる回る。一通のメールを未読から既読にする。またアイコンが回る。「これはしばらくまたされる」という心の準備をしてからでないと操作ができないような状態だ。
Objective-Cまで使ってあれこれやったのだがやはり速度の遅さはなんともならない。一番その問題に対して同情的なはずの私が我慢できないというのだから、他の人から観れば「ろくに動かないプログラム」にも見えるだろう。これはなんとか抜本的な対策をしなくては。
それまで基本的には常にディスク上にあるメールファイルを毎回読んでいた。この方法で行けばディスク上でなにやらファイルの名称が変わったり移動したりしたとしても、ブラウザ上の表示と矛盾がでることはあり得ない。確かにそういう確実性はあるのだが、もうこの方式には限界が来ているのではなかろうか。つまりディスク上のファイルとは別に題名一覧の情報ぐらいは常にプログラム側で持っていてそれを参照するようにすべきではなかろうか。ディスク上のデータと食い違いがでたらまた読み直すようにして。
その構想の下にあれこれ考え出す。最初にトライしたのは「フリーのデータベースソフトを導入できないか」というやつだ。ネットでしらべてみるとOS X上でも稼働する物がいくつかあるよう。しかしそれは私のような怠け者がひょいひょいと使えそうにも思えないし、よくよく考えると私が想定している用途（一人が使う数千件のデータ操作）にはオーバースペックという気もしてくる。
そのうちふと気がつく。Macintosh上で使えるフリーのプログラム、iTune、iPhotoというのも元データは個別のファイルでもっており、それの題名などの情報だけを高速に表示したり操作したりできるようにしているではないか。これはどうやっているのだろう、などとあれこれ考える。そのうち素直に題名一覧のデータを全てメモリ上に持てばいいのではないか、と思い出した。終了するときにはその内容をまとめてファイルに書き出す。次回起動するときにはそこを読み込めばいちいち全部のメールを読みに行く必要もない。
とはいっても私の環境ではメール数っても大したことないからいいけど、もっとすさまじい数のメールを読んだり書いたりしている人の環境でもこの方式は動く物だろうか？気がつくとメーラーが全てのメモリを食い尽くしたりしないだろうか。そう思い私は以下のように書いた
「でもっていきなり話は変わります。のたくた動くGMailを少しでも早くしようと、ヘッダーの情報を全てメモリに持っておこうかなと考えております。
ただ私の環境くらいだと問題ないのでしょうが、きっとすごい数のメールを扱っている方もいると思うのです。となるとこれは無謀なのだろうか。。などともんもんと。」返ってきた答えは「それくらいなんとか成るのではないでしょうか」というものだった。考えてみればMac OS Xでは常にメモリはシステムによって物理メモリの上にあったりディスク上にあったりが管理されるようになっている。となれば、結構大きなメモリを使ってもシステムの方でなんとかしてくれるに違いない。だめだったらそのとき考えることにしてやってしまえ、と思いきる。
では、ということでさっそくプログラムの変更に取りかかる。今までフォルダが選択されるたびにディスクを読みに行ったのを、全てプログラム中に保持しておくようにする。ただそれだとディスク上のデータと不整合がでると困る。というわけでアクセスする度に「ディスクに変更はないかな？」というのをチェックする。そのためにファイルの名称と変更日付をごちゃまぜにしてチェックサムを計算して、その値を前の値と比較することにした。チェックサムの計算はメールファイル全部読み込むのに比べればきっと早いに違いない。（とこのときは思っていた）
予想したよりこの変更は小幅ですんだ。また確かにディスクを読みに行く回数は減り、レスポンスも向上した気がする。となると早くリリースしたくなるのが人情というものである。しかしそう考え出すとあれこれのところが気にかかる。例えばキーで次のメールに行ったりできるようにしているが、それが効かない時があることに気がついていた。他にたくさん問題があるからほったらかしにしておいたが、どうにもこれは鬱陶しい。苦労して原因を探し出しフィックスする。
かくしてVer0.4を公開すると次の機能拡張にとりかかる。OMEでもメールに他のファイルを添付することはできるが、そのやり方というのは結構面倒である。ヘッダ部分にAttachment: と書き、その次に添付したいファイルへのパスを書かなくてはならない。ただしこのパスはPOSIXのパスである。
さて、問題です。どうやったらPOSIXのパスがわかるでしょう。そもそもPOSIXとは何のことでしょう。コンソールからばしばしキーボードでコマンドを打ち込める人だったらいいのだろうが、私は不幸にしてそういう人ではない。そのためにJeditというエディタから使えるApplescriptも定義されているが、他のエディタを使っている人はどうすればいいのか。私はCoelaというブラウザを用いて添付したいファイルのPOSIXパスを探し出し、そのたびに
「あれ、Attachments: だっけ、それともattachments: だっけ。:の前にスペースって必要だっけ」
とマニュアルをひっくり返して確認しながらファイルを添付していた。とっても面倒だがそんなに回数がないからそれでもいいことにしていたのである。しかしついにこの機能と向き合わなくてはならない時が来たのだ。
少し前にこの機能をつけようかと思い、返信メールを書く部分はファイルのドラッグ＆ドロップを受け付けるように作ってはいたのである。しかしそれ以上は面倒だ、と思ってほったらかしていた。いや、いつまでもそんな事は言っていられない、としょこしょこやりだす。添付されたファイルは返信メールの下の部分に表示するようにしよう。あれ、ファイルのアイコンってどうやって表示するんだろう。ファイル名も表示しなくちゃ。そもそもいくつまで表示できるようにしようか、などと考えていると思ったよりも大変であることに気がつく。しかし始めた以上は途中で放り出すわけにもいかない。
すったもんだの末ようやくそれらしく動き出す。さて、リリースと考えるとやはり避けようのないバグが発生してくれる。それまでも時々題名一覧の表示がおかしくなることには気がついていた。ただしそれがいつ発生するのか今ひとつよくわからなかったのである。ええい、最近受け取ったメールの中のどれかがいけないんだ、と思い適当に危なそうな（この危なそうな、というのは全くのアテ推量である）メールをゴミ箱に放り込む。そのうち直るからまあいいや、と思っていたのだがリリースを前にしてまたもやその問題が発生した。これはなんとかせねば。
今度はもう少し注意深く「どのメールがあると問題がおこるか」というのを試行錯誤で見つけだす。OMEでは添付ファイルが有る場合には、まずメールの名称をもったフォルダが作られ、その中に本文と添付ファイルが入るようになっている。そのうちあるメールが問題だと分かった。何が問題なのか知らないが添付ファイルがあるがごとくフォルダが作られているが中身が空である。こんなメールが存在することは想定しないから妙なことをやる。その結果題名一覧がおかしくなっていたのであった。ぶつぶついいながらそうしたメールは読み飛ばすようにする。
これでようやくVer0.41がリリースできる運びになったと思いたいところだがそうはいかなかった。あれこれ改修しつつ使っているうちに自分でも目をつぶることができない問題が再び浮上してきたのである。
例えばあるフォルダにメールが一通届いたとする。Ver0.4のロジックでは次にこういうことが起こる。フォルダの中身が変更されたかチェックしましょう。ああ、たしかに変更されていますね。では「全部」読み直しましょう。
最初はこれでいいと思った。ところがしばらく使っていると
「たかだか１通か２通読めばいいはずなのに何故２４３５通も読み直しているのだ。この馬鹿プログラムは」
と作成者の私が考え始めるわけだ。いや、考え始めたら直せばいいではないか。そう考えると私はまたもやプログラムをいじり出す。実行途中の経過も出力するようにして、
「なるほど。更新されたメールしか読み込んでいない」
と悦にいる。しかしそれも長くは続かなかったのだった。
注釈