3月・4月は Tax Return のシーズンだ。日本の確定申告に当たる。アメリカではこれを全員がおこなわなくてはいけない。この申告用の書類を作成するソフトウェアを使うためにパソコンがアメリカ中に普及したという話があるほど、Tax Return は一般的なものであり、そして面倒なものだ。

僕は Tax Return を自分で行うのは今年で4回目、毎年 Intuit の Turbo Tax Deluxe (http://www.turbotax.com/) を使っている。これが定番のようで、他のソフトは知らない。Costco (http://www.costco.com)で割引き販売されており、さらに期間限定で割り引きの上乗せがあるときに買うのが一番安く手に入れられる方法のように思う。税金は Federal と State といって、アメリカ政府と州とに払う必要があり、州用には別に Turbo Tax State というソフトが必要なのだが、Turbo Tax Deluxe を買うと State の方はメールインリベートでタダでダウンロードできるようになる。

さて、Tax Return の作業は、すでに源泉徴収されている税金をいかに多く政府から取り戻すのかというゲームのようなものだ。とはいえ、家を購入するといった特別なイベントがなく、投資やサイドビジネスからの収入などない一般市民にとっては節税のためにできることなど限られる。僕の場合は、株を売ったときの収入や銀行に預けている貯金からの利子など少しの調整が必要なだけで、これらをソフトウェアの指示通り入力していくと、提出用のフォームが出来上がる。

さて、僕がここに紹介するのは、今後自分が忘れないようにするためのメモであると同時に、「Tax Return」などで検索してこのページにたどり着いた人用に、もしかすると役に立つかもしれない情報です。

こうしてせっせと入力して勝ち取った Refund(源泉徴収分よりも実際払わなければならない税金の額が少なかった場合に払い戻してもらえる額)を去年までの僕は何も知らずに削られていた。

Tax Return は eFile といって、紙に印刷したフォームを郵送する必要がなくオンラインで送る方法があるのだが、手数料として Federal が $15 くらい、そして State が $10くらいかかる。「eFile はメイルインリベートで無料になりますよ」という説明が出てきて、僕も去年まではそれを真に受け楽なオンラインで Federal、State の両方を転送していたのだが、今年は注意して指示を読んでみるとメイルインリベートで無料になるのは Federal だけだということを知る。勝ち取った Refund を $1 も無駄にしないケチケチな方法は Federal は eFile、State は郵送が正解。

次に Refund を受け取るのに、郵送されてくるチェックで受け取るか、銀行口座に自動的に入金してもらうのかどちらを選べばよいかについて。Turbo Tax は「チェックを換金するために銀行に足を運ぶ一回分が節約できますよ」と言葉巧みに銀行口座への自動入金を勧めてくるのだが、こちらを選ぶと、最後に SBBT Processing Fee という一見すると何だかわからない費用として $30 ほどが Refund から削られてしまう。おそらく銀行口座自動入金だと手数料の一部が Intuit に渡るのか、このあたりの説明がソフトのヘルプを読んでもあやふやだ。ケチケチで行くには、チェックで郵送を選ぶべき。ATMへ一回足を運ぶくらい大したことはない。

以上を知っているだけで $40 ほど得をする、というか損をしない。もちろん、これは $1 でも多く取り返そうという Tax Return ゲームの一環。郵送するのは面倒くさい、手数料払ってでもオンラインの方が良いという方は Federal、State の両方を eFile で送ったほうがいい（しかも確実）し、Refund を一刻も早く送りたい、あるいはチェックの換金が面倒くさいという方は、手数料を払って銀行口座自動入金を選べば良いと思う。

http://d.hatena.ne.jp/jishiha/20040309#p3 で書いた use locale の問題が解決した。id:amatubu さんが情報を提供してくれた。大感謝です。この問題に関してネット上を検索してまわったが解決方法はどこにも見あたらなかった。同じような問題に直面した人が今度はここで情報が得られるようメモしておく。

問題は use locale と宣言して、EUC-JP のデータを sort しようとすると Perl がハングしてしまうというもの。

use locale と宣言したとき、デフォルトのロケールが採用されるのだが、Windows のデフォルトロケールは Japanese_Japan.932(=Shift_JIS)なので、sort する EUC-JP データと異なる。このため、不具合が生じるようだ。

use locale;

@text = ('Apple','Big','apple','big','あ','一');
print join(',', sort @text), "\n";

このスクリプトを普通に、つまり Shift_JIS で保存し Windows 上で実行すれば何の問題はないのだが、EUC-JP で保存した後実行すれば、ハングする問題が再現できるはずだ。

これを防ぐには、EUC-JP をサポートするロケールを明示的に宣言すればいい。ロケールの宣言は、

use POSIX qw(locale_h);setlocale(LC_COLLATE,"ロケール名");

とやればいいと id:amatubu さんに教わる。あとは EUC-JP をサポートする Windows のロケール名を見つければいい。Japanese_Japan.932 の 932 を入れ替えればいいと当たりをつけ、Windows の Control Panel > Regional and Language Options > Advanced > Code page conversion tables(僕の持っているのは英語版 WinXP です。日本語に適当に読み替えてください。) を探した結果、Japanese_Japan.20932 だとわかった。

use locale;
use POSIX qw(locale_h);setlocale(LC_COLLATE,"Japanese_Japan.20932");

@text = ('Apple','Big','apple','big','あ','一');
print join(',', sort @text), "\n";

これを EUC-JP で保存し実行してもハングしない。もちろん日本語の文字は EUC-JP なのでそのままではちゃんと表示されないが、アルファベットはきちんと、apple,Apple,big,Big の並び順で並び、no locale と宣言するよりも良い。

日本語モードかどうかで分岐させるには、

use locale;

$JapaneseMode = 'yes'; #yes or no

if $JapaneseMode eq 'yes' {
    use POSIX qw(locale_h);setlocale(LC_COLLATE,"Japanese_Japan.20932");
}

@text = ('Apple','Big','apple','big','あ','一');
print join(',', sort @text), "\n";

とすればよい。

僕の日記のタイトルは「Junya's Diary」という全然インパクトがないどうしようもなく駄目なタイトル。

ブログのタイトルのネーミングに見る傾向と対策

http://www.ringolab.com/note/daiya/archives/001185.html

では間違いなく「古臭くてだめな例」に分類される。それも下の下だろう。この記事によると英語のタイトルよりも日本語のタイトルの方が良いとのこと。僕が気に入って頻繁に見に行くサイトの中にも、そう言えば日本語タイトルのものが多い。列挙してみると、

• Tomの一生勉強一生青春 http://d.hatena.ne.jp/Tom/


• シリコンの谷は、いま。http://www.1101.com/siliconvalley/index.html


• 情熱起業列島 http://forum.netage.co.jp/blog/jonetsu/


• スズキゴンのシアトルからデジタルっぽくこんにちは http://www.hitachi.co.jp/Prod/comp/OSD/i/column/suzuki-gon/index.html

でも、もちろん英語のタイトルで「古臭くてだめな例」に分類されるサイトでも、内容が面白くて頻繁に訪れている所はたくさんある。ただ、やはり第一印象は日本語タイトルの方が良いかも。タイトルだけで「なんだか面白そう」とひきつけるものはある。

うーん、僕もこの日記のタイトル、変えてみようかな。

ちょっと古い連載記事だが、ひぐちたかしのオンラインソフトよもやま話という窓の杜の連載記事を読んでいる。

きっかけは、POPFile が窓の杜に掲載されたのだけれど、

http://www.forest.impress.co.jp/article/2004/03/17/popfile.html

「窓の杜はひぐちたかしのせいで嫌い」という発言を2チャンネルで見かけ、「なんでだろう」と思って、調べたらこの記事に行き着いた。例えば、

http://home9.highway.ne.jp/ty4/inasoft/talk/t200203.html

によると、問題は、オンラインソフト社会の構造改革（中編）～見直すべき現実と責任～という記事だそうで、これがフリーソフトの作者達の怒りを買ったのだそうだ。

フリーソフトは作者の完全な厚意で公開されているのだから、「利用は完全ににユーザーの自己責任」という考え方はおかしいのではないか？作った側にも最低限の社会責任があるのではないか？」という主旨。

読んでみた僕の感想だが、多少過激に聞こえる部分があるかもしれないが、別に怒るほどのものではないと思う。「ユーザーに一方的に責任を押し付け、作った側が完全に責任を放棄するのはどうかと思う」と言っているだけで、それは同時に「ユーザーが完全に責任を放棄して作った側に責任を押し付けるのも良くない」と言っていると僕は取る。要はバランス。中庸が良いという事では？

この記事を読んで激怒するような作者が作ったフリーソフトを使うのは、僕は躊躇するだろう。また、この記事でひぐちたかしは嫌い -> 窓の杜は嫌い という発想には僕はならない。

というわけで他の連載記事を読んでみると、これがなかなか面白く、仕事の合間についつい読みふけってしまった。

たくさんの情報をもちながら１項目しか表示できないプルダウンメニューは、一見して情報を伝えるという点において弱点をもっているのです。これは、トップページでサイトの発信情報を一見して伝えるようにしないとユーザーが去ってしまうのと同じ原理が働いています。つまり、プルダウンメニューは、自分の持っている情報を一見して判るように情報発信していないのです。また、トップページに３秒ルールを適用すれば、プルダウンメニュー内の情報は、無視される可能性が大です。

http://www2s.biglobe.ne.jp/~bihaku/usability/pulldown.htm

格好いいなあと思ってカテゴリに飛ぶことができるプルダウンメニューを表示していたが、表示した直後から、「これってどんなカテゴリが僕の日記にあるか分かっている人じゃないと使えないな」と思っていた。だからページトップのカテゴリのリストはそのままにしていた。

上記記事を読んで、やっぱりプルダウンメニューの方はやめることにした。

上記サイトの「ユーザビリティの改善」のほかの記事もいろいろと参考になります。

POPFile のことが雑誌 Mac People (5月号?)に掲載されるようです。編集の方に確認したら、

あまつぶさん作成の Mac 用パッケージ

が載るようです。

POPFile 日本語化ページ(http://popfile.sourceforge.jp)のアクセス数を調べてみたら、ここ最近 Mac ユーザーの数が急増。最近9日間の統計によると、利用 OS Macintosh が 21.5%。それ以前は 5% 前後といったところでした。

リンク元を調べてみたら、Macintosh 用ソフトウェア新着情報サイトの 「新しもの好きのダウンロード」 というサイトから来ている人がほとんどです。このページに上記のあまつぶさん作成のパッケージが掲載されたからでしょう。

パッケージは現在アンオフィシャルなものですが、安定して動いているようです。オフィシャルなものにするには、開発者 John に Mac を買いましょう。

John に Mac を買おう！

あまつぶさんが翻訳した日本語訳ができてからぽつぽつと寄付が増えているみたいです。断言できませんが、日本の Mac ユーザーからの寄付なのかもしれません。そうなると、日本語ユーザー、それも Mac ユーザーの優先度が上がるかもしれない。

• Kakasi vs bigram

日本語メールを扱うときには Kakasi による形態素解析を使って単語ごとに分けているが、Kakasi の辞書のサイズが大きいのが難点。また、Kakasi の Active Perl 5.8 用のモジュールは、竹迫氏(http://www.namazu.org/~takesako/kakasi/) の厚意により特別にビルドしていただいたもの。Active Perl のバージョンが上がるたびにまたその厚意に甘えるという形はベストとは思えない。

bsfilter は連続する漢字2文字(bigram)およびカタカナを token としているようだ。この方法でも精度が落ちない気がする。POPFile でもそうしてみるか？漢字に限定せず、ひらがな・カタカナ含め、連続するあらゆる文字2文字ではどうなのだろう？検証してみると面白そうだ。検証するには、日本語のメールだけの精度を POPFile に表示できるようにしないといけないな。

• APOP

「APOP 対応してくれ」という声をよく聞く。予定では 0.22.0 で対応のようだが、それまでユーザーは我慢して待ってくれるだろうか。日本の ISP 事情はよくわからないのだが、アメリカよりも APOP を採用している所が格段に多いのだろうか？日本は結構そういったセキュリティに関することに敏感に反応するように思える。ちなみに僕の利用している comcast は APOP どころか、From フィールドを変えたってメールが送れてしまう。

APOP対応のパッチは既に sourceforge.net で公開されているので、Perl がわかる人なら、割と簡単にあてられると思う。そうでない人のために 0.22.0 へのつなぎとして、簡単にパッチをあてることができるインストーラーを作って公開してしまおうか？日本語化には全く関係がないのだけれど。

• use locale

use locale の問題に悩まされている。use locale を宣言すると、日本語を sort する部分で POPFile はハングアップしてしまう。しかしこの use locale は日本語以外の言語ではアルファベットをきちんと並べるためには必須。例えば、use locale が宣言されていれば、a、A、b、B と並ぶところを、宣言がされていないと、A、B、a、b と並んでしまう。現状ではソート部分を、以下のようにして日本語モードが選択されているかいないかで分岐させているが、あまり良い解決法ではない。sort する部分がソースコードのあっちこっちにあるので、メンテに手間がかかるし、また新たに sort する部分が追加されたとき同じ問題が起こる可能性がある。

$JapaneseMode = 'yes'; #yes or no
use locale;

@text = ('Apple','Big','apple','big');

if ($JapaneseMode eq 'yes') {
    no locale;
    print join(',', sort @text), "\n";
} else {
    print join(',', sort @text), "\n";
}

そこで以下のように condition 付きの use locale を試してみたのだがうまくいかないのだ。

$JapaneseMode = 'yes'; #yes or no

use if $JapaneseMode eq 'no', locale;

@text = ('Apple','Big','apple','big');
print join(',', sort @text), "\n";

これだと、$JapaneseMode が yes あるいは no に関わらず、常に no locale 状態で、'Apple','Big','apple','big' と並んでしまう。

どなたか教えてくれるとすごく助かります。この問題、かれこれ半年くらい考え続けているので。

POPFile 0.21.0 がリリースされました。

http://popfile.sourceforge.jp/

はてなでは POPFile についてしばらくあまり書いていなかった。これからちょくちょく書いていこうかな、と思っている。カテゴリーも [POPFile] を追加した。[POPFile] カテゴリーだけの日記を表示させてみると、POPFile の日本語化がどのように進められていったかおおよそわかるようになっている。

ちなみに僕は POPFile の日本語化を進めているだけで、POPFile 自体を開発しているわけではない。POPFile は非常に優れたソフトウェアだと思っているだけに、そこの所を誤解されると、開発者の John Graham-Cumming 氏に非常に申し訳なく思ってしまう。ゆえに2チャンネルで「神」扱いされるいわれはないのだ。

一度ココログに浮気したが、またはてなに戻ってきた理由を挙げてみる。

http://d.hatena.ne.jp/jishiha/20040307#p1 では単にココログは面倒と書いたが、id:hyuki さんよりその面倒とは「手間」の問題なのか、それともシステムの「重さ」が問題なのか、という質問があった。僕の答えは「手間」:「重さ」は 6:4 くらい、つまり手間の方が若干上だが、両方とも問題だと感じた。

1. ココログでは記事が表示されているページから編集のページにすぐに飛ぶことができない。はてなでは、日記のページに自分のIDでログイン（通常はクッキーにID情報が保存されているからこの手間も普通は省略）していれば、「編集」リンクが表示されており、クリックすればすぐに編集できる。ココログでは記事が表示されているページとは別の編集画面というのがあって、この画面には記事のページから飛ぶことができない。ブックマークに登録しておけば良いではないかという話だが、記事が表示されているページと編集画面が全く分断されていては、はてなで編集するときのように、今目の前に表示されているものに手を加えているという感覚が得られない。このため、ココログでは「今から書くぞ」というちょっとした気構えが必要で、はてなのときのように思いついたときにすぐ書き込むことができない。


2. これも手間の問題だが、記事の中に例えば、リンクを貼りたいという場合、はてなでは単に URL を貼り付ければ、それがそのままリンクになるのに対し、ココログでは、リンクにしたい部分をマウスでハイライトし、[リンク]ボタンを押して表示されるダイアログボックスの中に URL を貼り付け [OK] ボタンを押すという手順が必要。文字を太字にするときなども同様で、はてなのときのようにどんどん書き進めることができず、頻繁に書く作業が中断されてしまう。


3. ココログで記事を書き、[変更を反映]というボタンを押すと、処理がどのくらい終わったかを示すプログレスバーが表示されしばらく待たされる。プログレスバーを表示するというのは親切なことなのだが、逆にこれはユーザーをそれだけ待たせますよというサイン。はてなでは「この内容を登録する」というボタンを押して、次に表示されるのは変更が反映されたページ。プログレスバーなど表示する必要がないほど、その処理はすぐに終わる。

HTML を自分で書いて日記/blogのような形式のページを作るよりかは、確かにココログは遥かに楽。しかしそのココログよりもはてなダイアリーの方がさらに楽。DSL やケーブルでインターネットに接続する環境に慣れた後には、ダイアルアップの環境に戻ることは考えられないように、はてなに慣れてしまった僕にとっては、ココログでの Blog は苦痛に思えた。