脈絡もとりとめもない独り言

奇跡的に雲が薄くなって姿を現した金環日蝕。

何はともあれ，今日はこの話題に尽きるだろう。金環日蝕である。今回のように日本の広範囲で見られるのは，932年振りだそうだ。っていわれても，広範囲で見えるかどうかって，皆あんまり関心ないんじゃ。それより，東京近郊で173年振りって方が，より実感が湧く。

せっかくだから一眼レフで撮影しようってことで，ND400の減光フィルタを2枚も用意。これだけで約1万5千円の費用がかかってる。昨晩，車の中に入れっぱなしの三脚を持ってきて，機材の方は準備万端。

ところが心配は天気だ。1週間くらい前から，天気が悪そうという予報が出ていたし，昨日も夕方くらいから雲が出て来ていたので，ちょっと不安。それでも，雨なら仕方ないが，曇りならなんとかなるかも知れない。ということで，朝6時に目覚ましをセット。

起きて外を見てみると，部分的に青空が見えるものの，東の方の空は一面雲に覆われている。そもそも，6時から7時くらいって，太陽がどのくらいの高さに来るのだろう。ちゃんと事前にチェックしておかなかったので，雲の切れ間を探すにしても，どの辺を注目したらいいのか分からない。6時19分，情報によれば，既に欠け始めているはずだが，太陽の姿は一向に見えない。

曇り空をぼんやり眺めていても仕方ないので，どの辺に太陽が来るのか調べてみることにした。iPhoneアプリでそんなのがあるらしいと聞いていたので，早速無料のものを探してiPadにインストール。で，外に出てチェックしてみると，意外に高い位置にあるはずらしい。iPadをかざしながら，三脚にセットしたカメラを，それらしい方向に固定する。あとは，太陽が出て来てから微調整するしかない。減光フィルタがついてるので，ファインダーを覗いても，何も見えないのが難しいところ。

この後も，一向に太陽は現れない。金環日蝕になると言われている，7時31分はどんどん近付いてくる。こりゃダメか...と諦めかけた頃，流れている雲の隙間から，奇跡的に太陽が顔を覗かせた。うっすら雲がかかってるので，肉眼でもはっきり確認できた。金環蝕である。なるほど，こういうものなのか。裸眼では危ないので，観察用のメガネごしに覗くと，被ってる雲の厚さによって，メガネでは見えなくなってしまうようだ。

さて，そんなことはしていられない。お次は撮影である。ファインダーではなく，液晶モニタで位置を確認。望遠端にすると，ほんのちょっと動かしただけで，視野が大きく変わるので難しかったが，なんとか太陽を捉えることが出来た。オート・フォーカスはいまひとつ上手く動作しないので，マニュアル・フォーカス。なんかそれっぽい像が写ってる。リモコン・シャッターでパチリ。それが右上の写真。果たして上手く撮れているのか，極めて心配だったが，あまりくっきりはしていないものの，まずまずと言えそう。

この後も，太陽は顔を出したり隠れたり。太陽の形が，意外にも早く変化していくのに驚いた。しかも，太陽の位置もどんどん移動していくので，たまに顔を出した時に，位置を合わせるのが大変。それでも，ところどころ，太陽の満ちていく過程を撮ることが出来たので，まずまずの成果だった。結局，欠け初めから欠け終わりまで，約2時間40分，フルで日蝕に付き合ってしまった。

何はともあれ，なかなか見る機会のない金環蝕を，生で観ることが出来て満足。減光フィルタも無駄にならなかったし。しかし，太陽の撮影には，まだまだ技術が足りないことを痛感。6/6の金星の日面通過までに，練習を積んでおかなければ。

「よみがえるWindows XP」(毎日新聞社)。こんな本出てるのか :-)

TV録画マシンは未だにWindows XP。Windows Updateのアイコンがタスク・トレイに出ていたので，アップデートを実行したところ，1つだけエラーになってしまった。特に気にもかけず，1回リブートした後，再度アップデートを実行しても，やっぱりエラー。

またMSのミスか何かだろうと思って，ほったらかしておいたのだが，後日，別のXPのマシンでも同じことが起こった。環境依存ではないのか? と思ってググってみたところ，あっさり解決策が見つかった。件のアップデートは「KB2686509」。こいつは，レジストリに次のようなエントリがあると失敗するというのだ。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Keyboard Layout]
"Scancode Map" = hex:..,..,..,..

ビンゴである。このエントリは，キーボードのキーのスキャン・コードを入れ替えるために使用するもので，Windows XPをインストールしたデフォルトでは存在しない。私の環境では，ESCキーと全角/半角キー，英数キーとCtrlキーを入れ替えるために，すべてのWindowsマシンでこのエントリを利用しているのだ。デフォルトでは存在しないとはいえ，こんなことで失敗するアップデータを作るMSの技術力とは一体...。

アップデートを成功させるには，一旦このエントリを削除してから，アップデータを実行すればよい。その後，削除したエントリを元に戻す。削除する前に，regeditでエントリをregファイルにエクスポートしておいて，後でインポートし直すのが簡単。

実際に試してみたところ，あっさりアップデートは成功した。なんともアホらしい話だ。しかし，解決策があるとはいえ，まったくの素人にregeditを使わせるのは危険。特にネットからダウンロードしたregファイルを使って，このエントリを追加している人には手に負えない可能性が高い。やっぱり，アップデータの修正が必要なんじゃなかろうかね>>Microsoftさん。

なお，以下はあくまでも参考。これを使ってシステムが壊れたと言われても，一切責任は負えないので，あらかじめご了承願いたい。

(1) レジストリのバックアップは，コマンドプロンプトから次のコマンドを実行する(次の2行は，実際は1行)。

regedit /E backup.reg "HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Control\Keyboard Layout"

(2) レジストリの削除には，次の内容のファイル(拡張子はreg)を作成し，エクスプローラなどでダブル・クリックする。

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Keyboard Layout]
"Scancode Map"=-

(3) バックアップしたものを元に戻すには，(1)でエクスポートしたファイル(backup.reg)を，エクスプローラなどでダブル・クリックする。

2月に発売された，14年ぶりのオリジナル・アルバム，「A Different Kind Of Truth」(Van Halen)。

現在行われているVan Halenの北米ツアーのうち，7月以降の分，31公演の日程が延期されたというニュースが出ている。

延期の理由は明らかにされていないが，こうなるとお約束の報道。"source with knowledge of the tour"によると，延期の原因はバンド内の確執だという。ニュースの出元はRolling Stone誌。ロイターの記事もこれを参照しているが，Rolling Stone誌なんて，そんなに信用できるものなのかねぇ。

まぁ，過去の例もあることなので，あまり疑いもせずに，またか，と思われてしまうのは仕方がないところかな。バンド内の確執っていったって，もはやDave以外はVan Halenファミリーだし，あり得るとしたらEddieとDaveの確執ってことなんだろう。二人とも，もう57歳なのに，まだそんなことを?

一方で，Van Halen News Desk(VHND)では，この噂を全力で否定している。最近のツアーの演奏やインタビュー映像を見る限り，EddieとDaveの不仲は感じられないということだ。まぁ，そんな露骨に周囲に見えるほど不仲だったら，もっと早くからニュースになってたと思うけどね。不仲が嘘なのか，不仲を見せない位には大人になったのか。

ただ，現在明らかになっているのは，単にスケジュールが延期されたということだけである。キャンセルではない。さらに，5/19～6/26の15公演は予定通り行われる。昔の彼らなら，確執が原因だとすれば，さっさと全部キャンセルしてしまいそうだからね。報道があった後の最初になる，5/19のSt.Paulの公演中に，何かバンドからメッセージがあったのかどうか。これについては続報を待ちたいところである。

VHNDによれば，オーストラリアや日本でのツアーも検討されているとの話。VHNDだって，どこまで信用できるかは分からないが，1ファンとしては，VHNDが正しいことを祈りたい。

本文には全く関係ないが，ツツジの蜜を集めに来てたクマバチ。残念ながらピンぼけ^^; もうちょっと絞ればよかったか?

本記事は，当blogで記念すべき(?)1500個目。

1000に到達したのが，一昨年の11月5日なので，約1年半で500。それまでの1000に4年以上かかっているので，若干早くなった。これは，去年の1月から1日1記事を続けてきている成果と言えよう。

元々このblogは，私個人の日記的な記録を残しておく目的に加えて，何か書かなくちゃいけない時に，短時間で話題を見つけて，それを手早くストーリーにまとめることの練習として始めたのであった。これは，某誌に連載記事を書いていた時，毎月の筆者近況欄の内容に，かなり苦しんだのが発端である。

もちろん本文執筆にも苦労はあるのだが，こちらはネタが決まっているので，時間さえかければまず終わる。しかし，筆者近況に関して言えば，まずネタ探しから難渋するのだ。いくら近況と言ったって，見ず知らずの筆者のありふれた日常を書いたところで，誰も興味を持つはずがない。そこそこ興味を引きそうなネタで，限られた文字数の中でストーリーに仕立て，それなりにオチを付ける...なんてこと，文筆業が専業でもない人間に，簡単にできるはずもない。大抵は，原稿の締め切りと一緒には提出できず，初稿チェックの結果の戻しまで悶々と悩んで，ギリギリに出すのが常であった。そんな風に苦労した，この毎月違う筆者近況は，実は編集部から依頼された訳でも何でもなく，ただ自分が好きで勝手にやってただけなのである...。

以来もう5年半以上，1500記事も書いてきて，だいぶ鍛えられたのかというと，さに非ず。未だに，日々のblogネタ探しに難儀している毎日。あと500，1000，...と積み上げていく内に，少しは進歩するのだろうか。まぁ，まずは1日1記事を続けていくことですな。1年ちょっとくらいでヒーヒー言っているようじゃ，まだまだ甘い。

「新標準SQLite」(ソフトバンク・クリエイティブ)

昨日，Skypeのログ・ファイルの話をしたが，取り敢えずそのログを読んでみる方法についてのメモ。

読むためには，SQLiteのDBを読めるツールが必要。SQLiteの公式HPには，Windows版のpre-complied binaryも置いてあるのだが，今回は手っ取り早くcygwinに含まれるsqlite3を使う。インストールされていなければ，cygwinのsetup.exeを起動し，Databaseのカテゴリの中からsqlite3を選択してインストールする。cygwinのコマンド・プロンプトか，パスが通っていれば，Windowsのコマンド・プロンプトから，sqlite3が実行できるはず。

Skypeのログがあるのは，Windows XPだと"Documents and Settings\<WindowsのユーザーID>\Application Data\Skype\<SkypeのユーザーID>"，Windows 7では"Users\<WindowsのユーザーID>\AppData\Roaming\Skype\<SkypeのユーザーID>"だ。そのディレクトリにある，"main.db"のチャットのログが保存されている。これをsqlite3で開くには，カレント・ディレクトリをmain.dbのあるディレクトリに移した後，

> sqlite3 main.db

を実行する。これで，sqlite3が起動し，main.dbと接続した状態になる。ここで".tables"と入力してEnterを押すと，このDBに含まれるテーブルの一覧が表示される。

sqlite> .tables
Accounts        ChatMembers     Conversations   Participants    Videos
Alerts          Chats           DbMeta          SMSes           Voicemails
CallMembers     ContactGroups   LegacyMessages  Transfers
Calls           Contacts        Messages        VideoMessages
sqlite>

このうち，"Messages"が，チャット・ログ用のテーブルだ。テーブルの中身を表示するには".dump"コマンドを使う。

sqlite> .dump Messages

これを実行すると，今のMessagesテーブルの状態を再現するためのSQL文が，コンソールにずらずらと表示される。ファイルに保存したければ，".dump"コマンドを実行する前に，".output <ファイル名>"を実行しておく。そうすると，".dump"コマンドを実行した時の出力が，指定したファイルに書き込まれるようになる。コンソールへの出力に戻す時は".output stdout"を実行する。sqlite3を終了する時は，".quit"コマンドを実行する。コマンド名の先頭のピリオド(.)を忘れないように要注意。

".dump"コマンドで出力されたファイルを，Perlで処理...っていうのも簡単だけど，本来的にはsqlite3のライブラリを使って，直接DBからデータを読み込むプログラムを作るのが正しいのだろうな。試しにぼちぼちやってみるか。

Facebookのブラウザ版チャット・クライアントの不安定さに辟易して，何か別の手段はないか調べてみた。そういえば，暫く前に，Facebookチャットのネイティブ・クライアントが出たとかいうニュースを見たような。

検索してみたら，Windows用のメッセンジャーというのがすぐに見つかった。まだWindows版だけなのか。出たばっかりなだけに，機能的にもかなりシンプルな感じだ。まぁ，ブラウザ版のチャット・クライントだって，最低限の機能しかない訳だけど。

試しに，メイン・マシンにインストールして使ってみたのだが，さすがにブラウザ版よりは安定しているみたい。ブラウザ版は，漢字入力をしていると，突然おかしな挙動(ゴミが山ほど勝手に入力されたり，カーソル位置が変わってしまうなど)をすることがあるが，ネイティブ版では問題なし。これは使えるか，と思いきや，一旦フォーカスを別のウィンドウに移して，また戻ってくると，何故か毎回IMEがオフになっている。オンのつもりで入力すると，ローマ字がそのまま表示されてしまう始末。小さな事だが，意外とフラストレーションが溜まってしまう。

さらに問題は，ネイティブ版のメッセンジャーが，Windows 7しかサポートしてないこと。メイン・マシンに負けず劣らず，VMサーバー上のXPマシンをよく使うので，これでは困る。いくら初期バージョンとはいえ，Windows 7しかサポート出来ないところに，技術力の問題を感じますな。しかも，ネイティブ版でも，やっぱりチャットのログを保存できないし。

ということで，更に別の手段を探してみると，SkypeがFacebookのチャットに対応しているという話。FacebookとSkypeは，去年7月に提携したそうだ。そういえば，先日Skypeを再インストールした時に，Facebookがどうのって書いてあったっけ。

早速Skypeを起動して，Facebookタブで「Facebookに接続」ボタンを押してみる。ユーザーIDとパスワードを訊かれ，さらにFacebookアプリのアクセス許可画面が表示される。Facebookアプリって，怪しげなSPAMが多くて嫌なのだが，Skypeを使うには仕方がない。許可すると，Facebookの自分のウォールの内容らしきものがSkypeのウィンドウ内に表示される。コンタクト・リストには暫く何も表示されなかったのだが，再起動したりしている間に，知らないうちにFacebookの友達のリストが表示されるようになった。

実際，これで数日チャットをしてみたのだが，なかなか快適。元々，Skypeでのチャットには慣れていたので，同じインターフェースでFacebookのチャットが使えるのはやっぱり便利。しかも，当然のごとく，Windows 7以外にも対応している。なんてったって，今やMicrosoftの持ち物ですからな。Mac OS Xでも使えるし。Linux版はアップデートされてないみたいだけど，いくらMSでもMac OS X版を簡単には切れないだろう。

チャットのログが，普通のSkypeのチャットと同様に保存されているのも有難い。もっとも，SkypeのログはSQLiteのDBに保存されているので，sqlite3といった別のツールを使わないと取り出せないけども。このログは，同じマシンでSkypeが起動してさえいれば，ブラウザ版のクライアントでチャットしていても記録される。これが，過去のチャット・ログも読みこんでくれると助かるのだが，そういうことは出来ないみたい。ちょっと残念。

そんな訳で，Facebookチャットでは，当面Skypeを使ってみる予定。もっとも，相手もSkypeを使っているなら，Skype同士でチャットすればいいんだけどね...。

今週発表のATPランキングで，錦織くんは17位から2つ下げて19位。まぁ，試合に出られてないんだから仕方ありませんな。17位のFeliciano Lopezとのポイント差は25なので，大会に1回出れば，簡単に逆転可能な差である。

しかし，今日更新された錦織くんのblogを見ると，腹筋の方はまだ痛みが残っていて，テニスを出来る状態にはなっていないようだ。当初，来週5/20から始まる"POWER HORSE WORLD TEAM CUP"での復帰を目指していたようなのだが，恐らく無理だろう。それより，5/27からのRoland Garrosの方が大事。腹筋痛がなくなるかどうかも微妙だが，リハビリの経過にもよるだろうし，何しろ4週間のブランクの後，ぶっつけ本番でRoland Garrosに臨むことになる訳だから，結果を残すのも難しいだろう。さらに言えば，身体に負担のかかるクレー・コートで，治りきってない状態で無理をして，悪化させたり別の箇所を怪我することも怖い。本人は当然出場したがっているようだが，先のことを考えても，慎重な判断が求められるところだ。

今年はオリンピックもあるし，錦織の出場権は間違いない状況。今，彼のテニスを見られないのは淋しい限りだが，後に禍根を残すことのないよう，しっかりと直し切って欲しいものである。

ケンコー・トキナーの減光フィルタ，MC-ND400 PRO，72mmレンズ用。

東京近郊で173年ぶりに見られるという金環蝕まであと1週間。まだまだ先のような気がしてたのに，あっという間に近付いて来てしまった。やばい，全然準備してない!

何が必要なのかというと，金環蝕を撮影するためのレンズのフィルタ。どれを買えばよいかよく分からなかったので調べてみたところ，ND100000という減光フィルタがいいらしい。...って，じゅうまん? 普通によく売ってる減光フィルタがND4とかND8とかなのだから，桁が5つも違う! さすが太陽撮影用だ。しかし残念なことに，手持ちのレンズの径，72mmに対応したものが見つからない。はて，どうしたものか，と思っていたのだが，さらに調べると，ND400を2枚重ねするというのでもいいらしい。ND400というのは，光量を400分の1にするということだから，重ねると掛け算で効くことになって，ND160000と同じ事になるようだ。ND400なら，いつも使ってるケンコー・トキナーの製品にも設定がある。ほぼ太陽撮影専用のND100000より，使い回しがきくみたいだし。

ということで，近所の家電量販店に行ってみた。すると，72mmのND400のフィルタは全て売り切れ orz。あらら...。77mmならいくらでも売ってるのに，72mmがないっていうのは，ありがちなサイズってことなのだろうか。仕方ないので，肉眼で観察するためのメガネだけ買って退散。この調子だと，どの店舗に行ってもなさそうな感じ。いつもこうやって，ギリギリまで動かないからダメなんだよな～...と後悔しても始まらない。生きてるうちにはもうこの近辺では見られないというのに，どうしたものか。

Amazon.co.jpでもなかったような気がしてたのだが，ダメ元でもう一度検索してみたら，あった! よかった。売ってるのはAmazonではないが，発送はAmazonなので送料無料。焦って2個注文した。

この日の夕方，早くも発送のお知らせメールが届いた。処理が速くて素晴らしい。一応メールの中身を確認してみると...あれ? フィルタが1枚しかない。これってもしかして，在庫が1枚しかなくて，あとは入荷待ちなのか? Amazonの「コノザマ」の恐怖が蘇る。ND400が1枚じゃ，とても金環蝕の撮影はできない。もう1枚が間に合わなかったらどうしよう...。

なんて心配していたら，その30分後くらいに，もう1枚も発送した旨の連絡が入った。よかった...。でも一体何故，2枚別々に発送する必要がるのだろう。エコじゃないな～。

さて，これであと心配なのは，当日の天気。天気が悪いらしい，という予報もあるみたいだが，こうなったらもう祈るしかない。ND400ｘ2は結構な出費だったし。てるてる坊主でも作るかな :-)

昨日の「～(波ダッシュ)」の話の続き。PerlのEncodeモジュールを使って，utf8/Shift JIS間のコード変換を試してみたところ，若干の勘違いがあった。

結論から言えば，Unicodeの波ダッシュ(U+301C)を，'cp932'で変換すると「?」になってしまい，'shift jis'で変換すると「～(0x8160)」になる。一方，Unicodeの全角チルダ(U+FF5E)を，'cp932'で変換すると「～」になり，'shift jis'で変換すると「?」になる。昨日書いたことと逆だ。これはつまり，正規のJIS(Shift JIS)の文字定義に従えば，「波ダッシュ」が「波ダッシュ」に変換されるのが当たり前で，Microsoftのcp932の場合には，変則的に「全角チルダ」を「波ダッシュ」に変換する，ということなのだろう。いずれにしても，逆変換のことも考えられているのか，「波ダッシュ」と「全角チルダ」を，両方ともJISの「波ダッシュ」にするコード変換はないようだ。

となると，WindowsとMacの「～」が混在するデータを，どうコード変換すべきなのだろう...って，あらかじめ，どっちかの「～」をもう片方に置換しておけばいいだけじゃん...という，あまりに単純なことに気付いて，自分にがっかりしてしまった...。

さて，これで一件落着...と思いきや，Shift JISに変換後のデータをチェックしていたら，やはり変なところに「?」が。元データを確認してみると，対応するのは「ハート」。ハートって，JISには定義されていないのか...。こればかりは，対応する文字が定義されていないのだから，どうしようもありませんな。

このWebの時代，Shift JISに変換して処理しよう，っていうのがそもそも時代遅れなことのような気もしてきた。実際，友人とのチャットの中では，日本語以外の文字を使ったりもしているし...。Shift JISに拘っているのは，未だにWZ Editor 3.0をメインに使い続けているからなんだよね。やっぱり，Unicodeをちゃんと扱えるエディタに，そろそろ移行すべきなんだろうか。WZ Editor 3.0が出たのは1997年4月。かれこれ15年も使い続けてきた訳だ。操作が完全に指に染みついてしまっていて，考えるより先に指が動く状態。そろそろ潮時だろうと，理屈では分かっていても，なかなか踏み切れない...。

「ユニコード戦記」(東京電機大学出版局)

Facebookで，友人とChatしたログをローカルに保存しようと思ったら，そんな機能がないことに気付いた。そんな間抜けなChatソフトってある? やっぱり，Facebookって，ソフトウェア的には何かと出来損ないである。

仕方ないので，取り敢えず，HTMLで保存しておくことにした。これにもちょっとコツがある。Facebookのメッセージのページを選んで，Chatの相手を選んだだけでは，最近のものしかクライアント側に読み込まれていないのだ。表示されているログを，上にどんどんスクロールしていくと，途中で続きをサーバーから読み込みに行くので，保存を開始したいログが読み込まれるまでこれを続ける。ここで，ブラウザのページ保存の機能を使って，HTMLやその他関連するファイルをローカル・ディスクに保存すればよい。

保存されたHTMLファイルはutf8エンコーディングなので，ブラウザならそのまま開けるが，utf8に対応していないエディタなどでは正しく表示できない。HTMLのままだと巨大だし，いずれにしろエディタでは読みにくいので，ログ・データだけを抽出するスクリプトでも作ろうかと考えた。その前に，作業をしやすくするために，utf8をシフトJISへ変換。

ところがここで問題が発生。Chatの会話の中で，「あ～」とかのように，波形の長音記号を多用しているのだが，シフトJISに変換すると，何故か友人のメッセージのものだけ「?」になってしまうのだ。見た目は同じ「～」なのに。元のutf8のファイルで，文字コードをチェックしてみると，自分のはUnicodeでU+FF5Eになっているのに対して，友人のものはU+301Cとなってる。同じ字形なのに，文字コードが違う? ATOKの文字パレットで調べたところ，U+301Cは「波ダッシュ」という文字名で，シフトJISには対応するものが書かれていない。一方，U+FF5Eの方は，「全角チルダ」という文字名で，シフトJISの0x8160の文字に対応する。友人はMacを使っているはずだが，Macの日本語変換が悪いのだろうか。

Webで調べたところによれば，この「～」はよく知られた問題のようだ。そもそも，JIS X 0208では，シフトJISの0x8160に対応する文字を「波ダッシュ」と定義している。しかし，いろいろな誤解を経て，Windowsでは，JISの「波ダッシュ」を，Unicodeの「全角チルダ」に対応づけることにしてしまったらしい。一方で，Macの方は，文字名の定義通り，UnicodeとJISのそれぞれの「波ダッシュ」を対応させたという訳だ。そういう意味では，Macの方が正しいと言える。う～む，相変わらずWindowsは，マルチプラットフォームでの互換性の観点で，ややこしい問題を引き起こしてくれる。

もっとも，utf8からJISへの変換という意味では，Unicodeの波ダッシュも全角チルダも，同じJISの波ダッシュに変換してしまえばよいのだから，取り敢えず問題はない。逆変換した時に元には戻らないけれども。Perlで言えば，"shift jis"の代わりに"cp932"を使えば，所望の文字コード変換が可能とのこと。これについては，実際に試してから，またレポートすることにしたい。