日付：2002/12/17
Ver0.2の次はVer0.28となった。この中途半端な番号の飛び方には訳がある。
他に使っている人がいるとは到底思えないのだがとりあえず作成者である私はGMailを使い続けている。プライベートで使うだけのプログラムだから一日に受け取るメールは英語の宣伝メールを含めても１日２０通以下。そのうち返答を書きたいものは３日に一通くらいしかこない。それでも時々不便を感じることがある。
どのフォルダに未読のメールがあるかはわかる。それを読むと未読は既読に変わる。さて、問題です。私はどのメールに返事を書こうと思っていたでしょう。ほとんどの場合私はそれを覚えていることができない。出すべき返事を出していなかった事を知ったときの背筋が寒くなるような感じはいままでに何度も味わっているのだがかといって慣れるわけでもない。
もう一つ。送受信を行うと未読メールが何通かくる。とりあえずそれをざっとまとめてみたい、すなわち未読メールだけ一覧したいという願望も生まれる。さて、どうすればいいだろう。頭の中であれこれ設計図を書くとそれが結構面倒であることにきがつく。しかしこれはもう一つのブラウザにない機能であることも確かだ。つまり今までは
「もう一つのブラウザと比べて特に能なし。スピードは遙かに遅い」
だったGMailも
「もう一つのブラウザと比べて少しは特徴がある。スピードは遙かに遅い」
になるかもしれない。
そう思うとあれこれやり出す。未読のほうからまず手をつける。いくつかのフォルダにある未読分をまとめて表示するフォルダを定義できるようにする。と書くのは簡単だが、これをやるためにはまた画面をつくり、データをセーブしロードし、ということをあれこれやらなくてはならない。もうCocoa + Javaでの開発にも大分慣れてきたとはいえ、同じ間違いをなんどかやるのもまあお約束という奴だ。
格闘すること数日。ようやく未読に関しては思った通りの機能ができあがった。もう一つメールを「要返信」としてマークする機能も考えていたのだがこちらはさらに面倒だ。今まで「要返信」とメールを識別する機能はなかったし、そこから作らなくてはならない。ええい、ここで一度公開してしまえとVer0.3には少し足りない0.28として公開したのである。
いったん公開すると次のバージョンに進む。OMEでは一つのテキストファイルが一つのメールとなっているから、それになんらかの付加情報を付け加えようと思ったらファイル名をいじるしかない。実際未読/既読の区別はその拡張子を変えることでおこなっているのだが、要返信とかいう機能について今までは規定がなかった。メーリングリストで会話すること幾度か。これでいこう、と決めてからあれこれやる。すると思ったよりすんなりと機能が実現できてしまった。Ver0.3として公開する。
この時点で私がメールを読むやり方というのは以下のようになった。まずおうちに帰るとメールを受信する。未読分はあるフォルダにたまっているからそこをじろじろと眺めていけばよい。届いているのは９割方英語の宣伝メールだが、これもメーラーの試験に役立つから捨てずにとってある。時々「これは返事を書かなきゃ」と思うメールがあると、「要返信」のマークをつける。読み終わると「要返信」メールだけがあつまったフォルダを眺めてあれこれ返事を書き出す、と言った流れである。
そこからVer0.37までは小規模な変更が続く。フォルダ一覧を題名一覧の横、もしくは引き出しに表示できるようにしていたが、これは引き出しに固定してしまった。かくしてだんだん「普通のメーラ」に画面構成が近づいて行く。なんとなく悔しいと思っても自分の内なる声はごまかせない。つまり「普通の配置はやっぱり素敵」なのだ。「普通の配置」というのはあれこれの試行錯誤を経て落ち着いたところなのだなあ、と妙な感慨にふける。過去何度も
「普通とはちょっと違った方法をとってやろう」
とチャレンジしたことがあるが、落ち着く先はいつも「普通」だ。
またある時期メーリングリストで「メールのスレッド表示ができないか」ということが話題になった。私自身はスレッドがどうとかいうことは気にしないのだが、確かにメールと返答がいつも近くにいると分かりやすいかもしれない。しかしそれをやるためには、「このメールはどのメールへの返答か」という情報を自分でつなぎあわせてやらないといけない。なんだかとてつもなく時間がかかるような気がする。でもまあ一発やってみるか。
そう考えるとしょこしょことプログラムを書く。スレッド表示をOn/Offしたりあるいは表示の仕方を変えたり、という機能のインタフェースはNameraから拝借した。過去の自分を振り返っても何か気に入った製品があるとそれを集中的にまねしている気がする。
「いや。考えた末、こう思ったのだ」
と自分に言い聞かせてもそっくりなのは否めない。
さて、できあがってみるとスレッドをつなぐ処理というのはびっくりするほど早く終わる。それよりもフォルダの内容を読み込む処理の方がはるかに時間を食うのでスレッド表示しようがしまいが使ってみて差を感じない。となれば、この機能は組み込むことにしよう。
次にやったのは添付書類に画像ファイルがあったとき本文中に表示する機能＆HTMLメールをきちんと表示する機能である。後者はともかく前者はこのメーラを作り始めたときからの目標であった。何故か。仕事であれば添付書類というのは実にいろいろな種類があろう。ワープロのファイルスプレッドシートのファイル。たまには数メガに及ぶプログラムを送ったりする。
しかし少なくとも私が個人で使うとき添付書類というのは８割方写真である。甥と姪の写真、実家のノータリン犬アイちゃんの写真。それらはやはり本文を開けたらそこに見えるべきではなかろうか。添付書類をダブルクリックなんてのはあまりぞっとする話ではないし、そもそもダブルクリックというのは排除すべき概念だ。
そうは思った物の文中に画像を表示するやり方がどうしてもわからない。Objective-Cであればサンプルプログラムが転がっているのに対応する機能がJavaにはないのである。あれこれやったが結局断念しほったらかしてあった。しかし今や私はJavaからObjective-Cの機能を呼び出す手段を手に入れていたのだった。
この機能とHTML表示機能を使って一つ思いがけず便利だったことがある。このころから猛威をふるい始めたKlezウィルスが一目で分かるようになったことだ。このウィルスはメールの送信者を偽装するため、時として
「あら、なつかしのこの人からメールがもらえた」
と思ってみるとウィルスだったりする。しかしこの機能をOnにしておけば一目でそれがウィルスと分かる。Macだから感染のおそれもないし。
そんなことをしている間に夏が来、それと関係あるのかないのかわからないが私のGMailにかける情熱は夏休みになった。まあ多少のろいけどそれなりに使えるし、というのが一番の理由だっただろうか。そうした平和な日々に変化は外から訪れた。まずは０２年８月のMac OS 10.2のリリースである。そうだよなあ。機能が増えたって言うけど、お金もかかるし少し見送りかなあ。などと思っている間にふと気がつけば脊髄反射的にアップデートしているのはやはりパソコンオタクの性というものであろうか。
さて、GMailはちゃんと動くだろうかと思ってみるとそこそこ動いているようである。いや、よかったよかった、と思ったのも数日の間。そのうち変なことに気がついた。メールの振り分け機能がうまく動いていないようなのである。新しく知り合いからメールをもらう。よし、と思いそのアドレスをアドレス帳に登録し、この人から来たメールはこのフォルダね、とやっても次に来たメールはデフォルトのフォルダにおさまっている。
最初は気のせいだと思ったが、やはりおかしい。プログラムがはき出すログを観てみると明らかにエラーが起こっている。なんだこれはと思い調べてみると原因は意外なところにあった。
たいていのプログラムには「設定」というものがある。やれ画面の大きさはどうだとか、GMailで言えばアドレス帳の中身だって設定だ。SETI@Supportでは自分でその設定を表すキーワードを決め、それを書き込み、読むときはキーワードを探し、、というのをやっていたものだが、Cocoaではこの設定をセーブするのに大変便利な機能が備わっている。XMLというファイルフォーマットでほれほれと読み書きしてくれるのだ。これは簡単。私はそのことを知りあちこちでそれを使っていた。
ところがこのXMLの読み書きに関する動作が10.2から変わってしまったのである。それも大変不可解な方法で。プログラムを書くときにはその変数の「型」というものを意識する必要がある。これは整数、これは文字列、etc..である。私は振り分けルールに関するところである整数型の変数を使っていた。Cocoaを通じてセーブしたファイルを観てみると
<int>0</int>
とか書いてあるわけだ。
エラーが起こった箇所を観てみるとどうやらこうして書き込んだデータを読み込むとそれが"long"という別の型に認識されてしまっている。ええい、ちゃんと<int>（普通の整数）と書いて有るではないか。しかしMac様がそうおっしゃるならしょうがない。私は呪いの言葉を吐きながらプログラムを修正する。ああ、longにすればいいんでしょ。ところが話はそう簡単には収まらない。
再度プログラムを動かしてみると同じようなところでエラーが起こっている。なんだ、と思ってみればちょっと様子が違う。格闘することいくばくか。私はなんと
<int>1</int>はlongとして解釈されるが
<int>0</int>はintとして解釈される
という事実を知った。０の時だけは何故かintだと思うらしい。
ええい、<int>と書いて有るではないか。人の話ちゃんと聞かんか、と言ったところで情勢はいかんともしがたい。再度プログラムを修正しその部分は動くようになった。しかし同じような箇所は他にもあり（そして私は怠け者だからそれを全部チェックすることをせず）物事がまともに動き出すまでにはいくばくかの時間がかかった。
これは新しいOSになった困ったことだがうれしいこともあった。このバージョンから、Apple純正のアプリケーション、QuicktimeやiTuneのような日本語で言うところのチタンの外見、英語でいうところのWashed Metalの外見が選択できるようになったのである。
どうやってやるのかなと思えばInterface Builder上で一カ所チェックするだけ。動かしてみるとちょっと変な感じもするがご機嫌だ。わーいわーいと喜んでいる間に別の「外部イベント」が迫ってきたAUGUSTというApple User Groupの展示会である。
仙台から始まり博多、名古屋、大阪、そして東京で行われるそのイベントにOMEは参加することになっていた。そして私は何も考えずに「参加します」と言った上にプレゼンテーションまでやることにしたのである。
人前でプレゼンするのは仕事でもあることだが、この日の聴衆は
「とにかく喋ってる奴に難癖をつけてやろう」
という人達ではない。私は結構ご機嫌にぺらぺらとしゃべった。持ち時間は３０分だったが、１５分もかからなかったと思う。自分が長い話を聞くのが嫌いなタチだから、きっと人も聞きたく無かろうなどと思いこむとどうしても話は短くなる。感動のストーリーでもなくあっと驚くどんでん返しがあるわけでもなく。これくらいがちょうどいいところだろう。
さて、終わるとブースでOMEの説明である。自分で人に見せながらあれこれやっているうちにやはりフォルダを選択してから一覧が表示されるまでの遅さがきになる。なんとかならぬものかと頭の中に課題だけは残る。
さて、このイベントでは他のブースもいくつか出ており、その中に一つ興味深いものがあった。Expressionというペイントソフトである。私は絵を描くのが大変下手であるが、絵を描くことその事が嫌いな訳ではない。下手の横好きという奴であろうか。そしてこのExpressionというソフトのデモを観ているうちに
「これなら私にも使えるかもしれない」
と思い出したのである。基本的には線を書いたり、面をぬったりするソフトなのだが、その線にいろいろな効果をつけくわえることにより、こうも面白い結果が得られるか、というような絵ができあがる。私はそのソフトに一目で惚れ込み、展示していたブースで行われた抽選に参加した。うまくいけば無料でこのソフトが手に入る。もちろんこのような虫のいいもくろみははずれに終わるのだが。
それからしばらく私は変なことに熱中していた。各種操作に使うボタン、およびアプリケーション自体につけるアイコンの製作である。しかしそもそもアプリケーションにつけるアイコンってどうやってつくるのか。試行錯誤を続けること数日、ようやくそれは完成した。さて、公開しようかと思うとあれこれ細かいところも目に付く。メニューの中にずいぶん英語のままのものが残って居るではないか。これもなおさなくちゃ、、などと本質的でないところばかり直した結果をVer0.39として９月２０日にリリース。この後私はまた方向を変えてGMailの改造に取り組み始める。
注釈