ミニーの資料室のミニーさんが、Garnet VM を日本語化されたそうだ。たいちさんとこ経由で知った。
http://usagiya.g-com.ne.jp/mini/gvm/gvm.htm
まったく、脱帽という他はない。陰郎にはまったくの魔法にしか見えない。ミニーさんがやることは全てがウィザード技に見えるというのが正直なところだ。まさに真正ハッカーである。
ところで、ミニーさんは上記のページで Japonica も遅いが動作していると書いてくださっている。おそらくだが、GVM は OS 5 だが PACE がないようにアプリからは見えるのではないだろうか。だとすれば、Japonica は全ての処理を 68K コードで実行する。一度も動作確認をしたことがないが、以前どこかで書いたとおり、Japonica は全ての ARM コードに対応する 68K コードを内蔵しているから、そちらで動いているのだろう。それが役に立つ日がくるなどとは正直夢にも思わなかったが。
実はしばらく前に気づいていたのですが、案件登録するのを忘れていました。メモデータへの複製をする際、改行コードが CR-LF 形式だとメモ帳アプリで開いたときに行末にゴミが表示される、というものです。Japonica 上の表示は問題ありません。詳細は以下をご覧ください。
BugTrack-Japonica/38 - project-enigma
案件ページに書いたとおりですが、基本的にバグと言うよりは「仕様の空白部分」という認識です。とはいえ、表示異常が発生するのはさすがにマズいのでどこかのタイミングで直そうかと。
Inside Japonica も今回で最終回です。タイトルをタイピングしてたら恥ずかしくて冷や汗かきました。（汗 が、今回は特に機能とかではなく、個人的な思いというやつを綴ることで最終回にしたいと思います。
まず第一に、敢えてはっきり書き遺しておこうと思うのは、陰郎にとっては、少なくとも 2007 年の夏ごろまでは Japonica にそれほどの思い入れはなかったということです。いわゆる 「 生活のため 」 に札束で横っ面張られて（マズい警句ですが勘弁願います）やる 『お仕事』 とは違い、趣味で作る事実上ボランティアの Palmware 開発では、思い入れがないというのはエンジンに燃料がないようなもの。それはもう、なかなか前には進まないものなのです。
もちろん、陰郎は今でこそ毎日のように Japonica を使っていますし、縦書きもルビ表示も、自分にとってはなくてはならないものになっています（特に漱石が大好きなので）。しかし、着手から１年くらいは、「自分でこのアプリを（少なくとも苦労に見合う程度に）使うだろうか？」という疑問に対して、良い返事ができませんでした。最大の理由は、Palm を読書に使えるだけの時間的余裕がなかったこと。これに尽きます。
陰郎は、2007年の 5月が終わるまでは、自宅から職場までバイクで通勤していました。そして、自宅と職場には PC があります。事実上、PC に向かっている時間が生活の大半を占めていました。ですから、Palm で読書、という以前の問題だったわけです。そもそも Palm を Palm らしく使用する時間がない。さすがにバイクで運転中に Doc リーダーを使うわけにもいきませんからね。
しかし、2007年 6月に会社従業員化して職場が変わり、電車通勤が始まったことにより Palm の使用時間が急増します。JR に載っている間は座れるので Palm TX で PPL の訳出作業をしていますが、地下鉄は混雑しているので立ちっぱなし。まさに Doc リーダーを使うべき状況ですね。そんなわけで、以来陰郎の中でのテキストリーダーの重要性は高くなっていったわけです。
そんなわけで 2007年夏以降、Japonica への思い入れは強まっていくわけですが、現金なことにまさにこのころから開発が急ピッチで進むわけですね。そして縦書きやらルビやら文字回転やら技術的に 「 刺激的な 」 楽しみもあり、そこからは順調に進んだようなわけです。これには、（事実上の）転職によって開発に割ける時間が大幅に増えたことも関係していると思います。
しかし、おそらく上に書いたようなことだけであれば、ひょっとしたら事態が好転する前、2007年の春くらい（それは最初期の Japonica のリリース予定でした）の時点で、Japonica を放り投げてしまっていたかもしれません。しかし、ぐずぐずしながらも最後までやりおおせることができた理由は、全然別のところにあると思います。
それは、まぁ簡単に言ってしまえば意地のようなものでしょうか。Palm というプラットフォームや、日本におけるそれに対して、たとえば古いとか今更とか、先に待っているのは衰退だけだというような、あるいは Palm にこだわり続けるのは賢くないとでもいうような雰囲気。または過去に名を馳せた Palmware 作家達も既に別の道を行ってしまって、新しくてナイスな Palmware はもう出てこないとでもいうような。そんな雰囲気に対して、単なる言葉だけじゃなくて、荒削りでも、実際に動いて、便利で、歯切れが良くて、破壊力のある、これだから Palm でなくちゃと言いたくなる、そんなアプリを叩きつけて、Palm を過去に片付けてしまうような考えに、目に物を見せてやりたい。俺達はまだここにいるんだ、これからもそうだって。そんな意地があったんですね。その意味で、Japonica は陰郎にとって 「 大いなる反攻 」 の最初の兵器だったわけです。
陰郎はもともと万人受けするようなソフトウェアを作るタイプの開発者ではありません。ですから、上に書いたようなことを行動で示すには、自分の中に動機付けがない作品を作らなきゃならない、ということはわかっていました。だからこそ Japonica は 18ヶ月という難産の末に生まれることになったわけです。しかし、苦労した子ほど可愛く感じると言うのはこのことでしょうか。今となっては、これまでのどの作品よりも愛着を感じています。
Japonica を取り上げて下さったサイトの中には、いくつか印象的な表現がありました。「 Palm の逆襲 」 みたいな表現や、「 遅れてきた決定版 」 など。機能追加の要望もたくさんいただいていますし、もちろん全部が全部好意的な意見というわけでもありません。そういったものを全て含め、Japonica を使って下さる皆さん、そして Palm を使い続けて下さる皆さんにこの場を借りて御礼申し上げます。Japonica はまだ完全ではありませんが、ひとまずの実用に耐えるレベルにはなんとか達していると思います。すでに別の作品の開発は始まっていますが、しばらくは心安らかに過ごしたいと思います。
【終わり】
Japonica の version 1.33 をリリースします。今回もバグ修正のみです。
http://www.project-enigma.jp/wiki/index.cgi?page=products%2FJaponica
変更点は以下のとおりです。
・MeDocインデックスの解析に失敗するバグの修正
メールにて、Japonica の不具合報告をいただきました。というか、しばらくメール受信を怠っていたため、反応が遅れてしまいました。大変申し訳ありません。
症状ですが、特定の状況で MeDoc インデックスの解析に失敗してしまいます。先ほど軽くデバッガで追いましたが、だいたい理由はわかりました。今週末までに修正版をリリースします。大変申し訳ありませんが、今しばらくお待ちください。
Inside Japonica も残すところあと２回。今回は、Pay-Palm ウェアについて。
正直なところですね、賛否両論を覚悟していたのですこれ。どんな受け止め方をされるかは正直想像もつかなかったし、今でも想像できないのですが、まぁたとえば 「 無意味 」 とか、「 キレイゴト 」 とかですね。もうちょっと当たり障りのない方向で言えば、実効性を疑問視するようなタイプの意見でしょうか。そういった意見が出てくると思いきや出てこない。これは単にそう思う人が黙っているだけなんでしょうか。それとも誰もそう思わない？ はてさて。
実効性を云々するのであれば、陰郎とて 「 どんなもんでしょうねぇ？ 」 と言ってにやにや笑うでしょう。有体に言ってしまえば、説明ドキュメントでも書いたとおり、「 フリーソフトウェアによるシェアウェアの駆逐は望まない 」 という自己都合でもあったということです。Japonica は事実上のフリーソフトウェアですが、それなりに使えるものになっていると陰郎は考えています。これが有料のソフトウェアを締め出すことになってしまうのは、やはり望ましいことではありません。
もうひとつ有体に言ってしまえば、オンラインの販売チャネルを持つのが面倒、というのがあります。できることなら、Japonica みたいに苦労した作品からはいくらかの収益が上がったら嬉しいですよ、やっぱり。これも説明ドキュメントで書いたことですが、陰郎自身は Palmware でお金を稼ぎたいわけではありませんが、稼ぎたくないわけでもありません。でも、実店舗構えて販売する小売店より立ち上げは楽とはいえ、今後シェアウェアにする作品をどれくらい作るかもわかりません。ですから、半分投げやりな姿勢も含めて、「 対価払う代わりに Palm に使ってくれぃ！」 みたいな感じですね。
さて、そんな消極的な理由はさておいて、「 Palm 経済の活性化を！」 という割と積極的な側面を見てみましょう。今日の時点で Japonica のダウンロード数は 1,700 といったところです。細かいバージョンアップがすでに５回発生していますから、ユーザー数は多めに見積もって 1,000 人というところでしょうか？ もっと少ないかもしれませんね。仮に 1,000人として、全員が 1,000 円分 Pay-Palm してくれたとしたら、この１ヶ月ちょいで 100 万円の経済効果です。まぁ試算というには絵空事に過ぎませんが、これを多いと見るか少ないと見るか？ 正直陰郎にはわかりません。なぜなら、日本の Palm 関連市場で１ヶ月に動いているお金の量が分からないからです。Palm 関連グッズを扱っているショップの方なら現実的な意見をくださるかもしれませんね。
まとめておきましょう。陰郎としては、キレイゴト一辺倒で Pay-Palm を声高に叫ぶつもりはありません。自分のポケットにお金が入ってきたら正直嬉しいですが、いろいろ面倒なのでそれはやりません。しかし、結果として競合するシェアウェアが不必要に圧迫されるのも望みません。なので、お金を使ってください。でも、どうせ使うのであれば Palm に使ってください。確かめることなんて無理ですから強制はしないということにします。以上の事情を 「 Palm 経済の活性化を狙う 」 という崇高な建前でラッピングして、それを Pay-Palm と呼びます。以上。
ながながと書いてきましたが、そろそろ終わりが近づいてきました。といっても予定では今回を含めあと３回あります。Inside Japonica の第16回は OS 5 専用であることについて。
そもそも、Japonica の開発の動機は、「 OS 5 の機能に対応した縦書き Doc リーダーが欲しい」 という要望に応えるというものでした。では、ここで OS 5 の機能とは何か。それは倍精度ディスプレイであるかもしれませんし、5Way ナビゲータ、あるいはワイド画面であるかもしれません。実際、そういった要素をフルに使えるテキストリーダーに対する要望があったわけです。ひとまずのところ、OS 4 以前向けには既存の素晴らしいアプリがある。だから Japonica は OS 5 に注力する．．．そして陰郎は手一杯になりながらもそれらを何とかしましたとさ。めでたしめでたし。
．．．いや、それで話は終わりません。なぜなら、これらの機能への対応は、Palm OS 4 以前をサポート外にする理由にはならないからです。実際、陰郎自身としては、Doc データベースのメモリ展開処理を書くまでは、「 少なくとも Palm OS 4 はサポート対象に入れられないか 」 という望みをつなごうとしていました。これをあきらめた理由は、パフォーマンスです。
圧縮された Doc データを展開する処理は、圧縮 Doc データ作成よりは速いとはいえ、68K コードではそれなりに時間がかかります。そのために、大きな文書では常に一部分しかメモリに展開しないアプリもあるようです。つまり、ページ移動のアクションによって小刻みにデータへのアクセスや圧縮データの展開などが行われるわけです。これは計算機資源の制約がキツい場合には致し方ありませんが、体感速度に影響する場合もありますし、なによりもプログラムの内部構造が複雑になります。最終的には、仮に OS 4 もサポートするとしても、文書全体をメモリに「一気読み」する仕様にしてしまいました。その時点で OS 5 専用に事実上なったことになりますし、またその決断をする前から OS 5 専用にせざるを得ない．．．という雰囲気があったことも事実です。
そして画面描画。以前にも書いたとおり、Japonica では極力自然な縦書き表示をするために、半角文字や記号類を回転したりズラしたりして描画しています。試していないので分からないのですが、これが 68K コードのみで動作していたらどうなっていたでしょう？ 文書全体をメモリに読み込んでいても、ページ移動はもたもたして不快なものになっていたはずです。
このような、OS 5 の計算機資源ゆえにできるリッチな振る舞いは、OS 5 専用にするという選択を必要とするものでした。Japonica は 2008 年も明けようという段階で登場したテキストリーダーソフトウェアです（ 本当は 2007年春の段階でリリースするつもりだったのですが）。個人的には、「もう後がない」とさえ思っていました。ひょっとしたら、Japonica が最後の日本語対応縦書きテキストリーダーになってしまうかもしれない。それを望んでいるわけではもちろんないにせよ、そんなはずはないと信じられる合理的な理由も見つかりません。そして、陰郎個人としても、同じことをもう一度できるとは思えません。だからこそ、OS 5 専用にしてでも、今の時点でできるだけのことをやる必要があったのです。
「 OS 5 でできるだけのことをやる必要 」 があると感じたもうひとつの理由は、Palm OS 以外のデバイスとの競合です。iPod Touch や iPhone、WM やその他のデバイス。こういった新たな「楽しきもの」たちは先進的で斬新なインタフェイスを備え、現代的なパフォーマンスを見せています。それができるのは、「 過去の資産 」 という、場合によっては足枷となる歴史が Palm OS に比べてあまりないからです。Palmware が OS 4 以前との互換性を維持する限り、ずっと 68K エミュレーションという重荷を背負わなければならないのです。しかし、他のプラットフォームに対抗するための武器として Japonica を考えた時、OS 4 以前との互換性を背負うことはできませんでした。
以前、この weblog で 「 陰郎も Palm OS 4 を切り捨てたでしょう 」 というコメントをいただいたことがあります。このときは、まさに Japonica の開発真っ最中だったため、非常に心が痛かったことを覚えています。内心忸怩たる思いがあったとはいえ、たしかに陰郎はいくつかの作品を Palm OS 5 専用としてリリースしています。今後も、どうしてもそうしなければならない理由がない限り、要らざる非互換性は持ち込まないように気をつけようと思います。
まだ存命中です。Inside Japonica 15回目は、規模の話。まぁプログラミングをしない方にはどうでもいいような話ですが、一応 Japonica 戦線の記録として。
どういう因果か、陰郎は C++ という言語を専門にしております。陰郎のスタイルは、詳細は省きますがとにかくファイル数が多くなる。クラスという構成単位を中心に据えてプログラムを構築するのですが、そのクラスをかなり細かくするんですね。そして原則として１クラス１コンポーネント。で、結果としてどうなるか。Version 1.32 の時点でこうなっています。
・ヘッダファイル(*.h*） ： 99 ファイル
・インプレファイル(*.c*） ： 81 ファイル
ぐれーと。あわせて 180 ファイルありますよ。さすがにここまで大きなプログラムは組み上げたことがありません。良く頑張ってくれた CodeWarrior。趣味の PC プログラミングでも、仕事の方面でも、ここまでファイル数を分けたことはないと思います。まぁいわゆるステップ数で言えば仕事のほうが圧倒的ですが。
参考までに、陰郎が作成した Palmware でこれまでもっともファイル数が多かったのは PipeWorks で 110 ファイルだったようです（過去の日記より）。軽く自己記録を伸ばしましたね。でも PipeWorks は２ヶ月たらずの開発期間で 110ファイル書いたんだよなぁ．．．若かった。（汗
Japonica の version 1.32 をリリースします。今回もバグ修正のみです。
http://www.project-enigma.jp/wiki/index.cgi?page=products%2FJaponica
変更点は以下のとおりです。
・既読情報クリアでアイコンが戻らないバグの修正
・ブックマークから文書を開くと既読にならないバグの修正
・カード上ファイル名制限に関するバグの修正
・空ファイルをショートカットと誤認するバグの修正
中２日あきました。Inside Japonica の第14回はブックマーク機能についてです。
ブックマーク機能は、デザイン作業のごく初期から必須機能としてあがっていました。本質的な部分で検討が難航したという記憶はほとんどありません。文書を読んでいるときにブックマークを保存する。あとからブックマーク一覧から指定すればその位置に戻る．．．それだけといえばそれだけですからね。
ただ、メモ帳データだけは文書のキーをどうするかでしばらく悩んだ記憶があります。Doc データベースはデータベース名がキーですし、カード上のファイルはファイルのフルパス名がキーになります。しかし、メモ帳は．．．？ 最初はレコードインデックスにしたのですが、これはメモデータの削除によりズレることが判明。どうしたものか．．．と悩んでいたところ、レコード属性に Unique ID なるものがあることを知りました。これはレコードに一意な番号ということで、これで行くしかない、と思いました。まぁ知っていれば特に書き記すようなことでもないのですが、それまで Unique ID の存在を知らなかったので。
デザイン上のポイントとしては、文書一覧画面でブックマーク一覧を Doc データ、メモ帳データ、テキストファイルと並べて同一に扱ったというのがあります。陰郎自身もそうですが、ブックマークというのは人によってはヘヴィに使用するものですから、ボタンやメニューでワンクッション挟まるのは良くない、と。まぁ結果として透過的な使い勝手を実現できたと思っています。
もうひとつ大事な点は、ブックマークの「上書き保存」です。長い長い小説を読んでいるときなどは、ブックマークから開いて続きを読み進め、中断すべき時がきたらそのブックマークを更新したいはずです。そこで新しいブックマークを別途作成しようとする人は少ないでしょう。となると、この操作は簡単にできなければなりません。ブックマークは名前で区別されますから、ブックマークから開いた場合はブックマーク作成時に自動的に名前の初期値が設定されるようにしました。それ以外の場合はもともとの文書タイトル（というか一覧画面に表示される名前）が初期値になります。
これでオーケー．．．と思っていたのですが、まだ足りませんでした。たとえば、ついブックマークがあるのに普通の文書一覧から開いてしまった場合にも、既存ブックマークを上書き保存したいことがあります。また、複数の文書に分割されている文書なども、ブックマークは１つにしておきたいですね。極端な例ですが、陰郎はメールで配信されてくるニュース（１日３通）を MeDoc 形式のテキストファイルに変換してカード上に収め、読み終わったら削除．．．というのを繰り返しています。しかし、ブックマークは１つだけで、【News】○×新聞社などといったタイトルにしています。このような状態でも、普通に開いた文書をブックマーク保存する際、既存の（使い回しの）ブックマークを選択したいわけですね。
これを実現するために、いささか Palm らしくないとは思いつつも、「選択」ボタンを用意してポップアップリストから選択、という機能にしました。これにより、ブックマーク保存画面から既存ブックマークの一覧にアクセスできるようになったわけです。これは陰郎自身毎日必ず使用している機能であります。
ブックマーク機能の今後ですが、いまだに正式に却下しないでいる機能案として、「ブックマークへの表示設定の保存」というのがあります。これは、ブックマークに位置情報だけでなく、ブックマーク作成時の表示設定も保存してしまおう、というものです。これにより、たとえば小説では縦書き、英語の文書では横書き、などといった複数の文書のブックマークを交互に開く場合でも快適になるでしょう。
しかし、です。「それは本当に必要な機能なのか？」 という点でイマイチ自信がありません。その機能が必要ない人にとっては、単なる余計なおせっかいになる可能性があります。新しい機能を追加する場合、それを必要としない人の邪魔をしないこと。これは陰郎にとって非常に重要な原則です。そして、好みの表示設定を２つ登録しておける機能が追加されたことで、ブックマークへの表示設定保存は「ほぼ却下」という状態に置かれたのでした。
もうひとつ、リリース後にいただいた改善要望として、「ブックマークとは無関係に各文書の最終表示位置情報を保存する」というものがあります。いわば文書単位に管理される暗黙のブックマークということになるのですが、これも先の原則に照らしてみると悩ましいところです。PooK にはその機能があるらしいのですが、?そもそもブックマーク機能があるのに必要なのかとか、?他のアプリから文書が削除される可能性を考えると削除タイミングが無いため、長期的には管理情報が肥大化するとか、まぁいろいろ仕様面で悩んでいるような次第です。
最後に、いまさら思い出したバグ情報。Doc データとテキストファイルで利用できる既読管理機能ですが、ブックマークを作成してから既読管理情報のクリアをすると、以後ブックマークから文書を開き続ける限りその文書は既読状態にはなりません。バグなのか仕様なのかと言われれば微妙ですが、やっぱりバグでしょう．．．というわけで、案件に登録しておきます。
