ぼくが18才まで暮らした札幌市には三本の地下鉄路線が走っています。 そのうちの一つが東西線といって、その名の通り市内を東西に貫いています。 その東の終点が新さっぽろ駅。 小学生時分のぼくにとって、この駅は特別でした。 なぜなら新さっぽろには札幌市青少年科学館があるから。 親に「新さっぽろに連れて行ってあげる」と言われると大喜びしたものです。 新さっぽろにはもう一つ、サンピアザ水族館という子供向け施設がありますが、ぼくはこっちはあまり興味なかったなぁ。 当時のぼくには、魚が動いている様子よりも、機械が動いている様子のほうが面白くて。

さすがに大人になってからは行く機会も少なくなりましたが、子供向けに科学をわかりやすく説明、展示したこの手の施設ってのはどこか心惹かれるものがあります。 たとえば新宿三井ビルにある未来科学技術情報館はこじんまりした施設ながらも、アクセスも良く、大人も入場無料と太っ腹なので何度か足を運びました。 2007年一杯で閉館してしまうのがなんとも惜しい。

そして今日は、お台場の日本科学未来館に行ってきました。

• 日本科学未来館 Miraikan

開館した当初はとても気になっていたのですが、行くチャンスがないままになんとなく忘れていました。 が、今朝急にそのことを思い出し、おあつらえ向きに予定もなかったので急遽午後から足を運びました。 到着したのが15:00過ぎ。 だからなのかどうなのかわかりませんが、チケット売り場はすいていますし、館内全般的にそれほど満場感がありません。 あれ？あまり人気ない？

すいてるほうが見て回るのには楽でいいのだけれど、不人気で閉館とか嫌だなーとか余計な心配しつつも、まずはミュージアムショップへ。 これがなかなか面白い。 双眼実体顕微鏡とか、永久プレパラートとか、サイズや形が違ってもいくらでも積み上げられるテトラポッド型の積み木とか、DNA 検出実験キットとか・・・・・・。 BTB 溶液は本気で購入を検討したけれど、理性が「何に使うの？」という疑問を投げかて、すんでの事で踏みとどまりました。 危なかった。 あと、気になったのはこれ。

• チョコバイト

これ、同じことをゴマでやったことがあります。 白ゴマと黒ゴマで（業務用でそれぞれ1kg入）。 そっかー、チョコだったら売り物になるのかー。

入場していきなりミュージアムショップにはまってしまい、ずいぶん足止めされてしまいましたが、閉館は17:00なのであまり時間もありません。 急いで展示を見に行きました。 細かな内容は端折るとして、あちこちに「これは子供向けの内容じゃないな」と感じる展示が見られました。 大人であっても完全には理解できないんじゃないかと思うような「不斉水素化の意義」とか「コンダクタンスの量子化」とか（ぼくも例外ではなく）。 未来館のスタンスとして、必ずしも「学習し、理解する」ことを求めていなくて、理解できないまでも「新しい知」に触れることが大切だということらしいです。 もちろん、触って動かせるわかりやすい展示もいろいろとあったり、結構頻繁に実演実験を行っていたりと、子供は子供なりに楽しめるんじゃないかな。

ぼくが一番感動したのは、カミオカンデの1/10モデル。 これは中に入ることができて、時々ニュートリノの衝突によるチェレンコフ光（を模した青色LED）が周囲の光電管を駆け回ります。 もちろんこれは本物ではないということは重々承知なのだけれど、思わず背筋がゾクッとしました。 結局 15:00-17:00 の二時間ではぜんぜん時間が足りず、見残した展示がいくつかありました。 本当は MEGASTAR-II も見たかったのですが、ぼくが入館したときにはすでに整理券はすべて配布された後でした。 残念。 また行こう。 ちなみに、年に二回以上いく場合は「Miraikan 友の会」への入会がお得です。

• Miraikan　友の会

9/22 からは「地下展」なるものが開催されるらしい。

• 地下展メイキング日記

なにそれ！魅力！絶対行く！ 友の会、入会しておけばよかった。

• Bass Pale Ale

自由が丘 山屋にて購入。

• KIRIN_ニュースリリース_2007.4.11_「キリン 良質素材」を新発売

5/23 発売の新ジャンル。 麦焼酎の発泡酒割です。

TV CM や車内吊り広告など、結構地から入れてるみたいですね。 確かに、これまでの新ジャンルよりも麦麦しいし、後味に残る焼酎くささが弱いですね。

あ、でも今ぬるくなってきたらだめだ。 うーん、やはりこの手のは難しいですね。

自宅の電力配線がどうなっているか気になったので調査してみました。

といっても、最近話題の PLC 絡みではなくて、契約電力絡み。 なんとも情けない話ですが、トースターと電子レンジの同時使いに巻き込まれて、自宅サーバーが最近数度落ちたんですね。 これを防ごうと、自宅サーバーは別系統から給電を行いたいなと。

ここで簡単に一般家屋の宅内配線（100V 単相三線の場合）を整理しましょう。 外側から順に、まずは電柱から建物までを結ぶ引込線です。 で、引込線取付点というところを経て引込口配線、屋内配線へと続きます。 PLC 絡みでよく言われる電力会社との責任分界点はこの「引込線取付点」になります。 続いて宅内の分電盤（集合住宅などでは配電盤があったりしますがここでは省略）。 この中でもいくつかステップがあって、まずは電力会社との契約電力に基づいて回路を遮断するアンペアブレーカーです（ここまでは単相三線）。 そして次に、回路ごとに電流量に基づいた遮断を行う配線用遮断器。 分電盤を出るとその先は配線用遮断器ごとに分岐された回路、コンセントを経て電気機器です。

我が家のブレーカー落ちの状況を見ると、アンペアブレーカーは落ちずに配線用遮断器が落ちてるんですね。 この状況でトースター、電子レンジに巻き込まれて自宅サーバーが落ちるということは、これらが同じ屋内配線にぶら下がっていることになります。 こいつを分けることができれば、巻き込み事故はふせぐことができるはず。

さて、そんなわけで屋内配線を調べようと思い立ったわけですが、問題は調査方法。 多分不動産屋から屋内配線図でも手に入れるのが一番正確なのでしょうが、そんなものを請求するのもまた手間がかかります。 そうなると一番簡単なのは「一つ一つ配線用遮断機を落として、どこの範囲の給電が止まるか確認する」という方法です。 調査後は家電に内蔵された時計の調整が必要ですし、もちろん自宅サーバーも落ちるのであまり望ましくはないのですが手っ取り早いのでこれでいきます。

最初に全コンセントおよび、コンセント以外から給電されている電気機器（電灯など）をリストアップします。 そしていよいよ配線用遮断器をひとつずつ落として給電範囲を確認します。 電灯は目視確認。 コンセントの場合は電圧計を突っ込みます。 さすがに電圧計は「一家に一台」という状況でもないと思うので、一般には電気スタンドでも差し込めば確認できるでしょう。

15分ほどで調査完了。 ぼくの家の配線用遮断器は L1 側に一つ、L2 側に二つあるのですが、調査によって軽くショックな事実が判明。 なんと、L2 側の二つのうち一つはどこにもつながっていませんでした。 ぼくの見落としがあるのかもしれませんが、こいつを切ってもどこにも影響が出ません。 無駄だ。 そして、残る二系統は「電灯系」と「コンセント」という、ひじょうにおおさっぱな区切り方がなされていました。 つまり、自宅サーバーの給電系統を分けることは不可能。 ショック。

ちなみに個々の配線用遮断器にも電力量の上限はあって、ぼくの家は一つあたり 20A でした。 東京電力とは 30A の契約なので、電灯がらみで 10A は確実に確保できるということですな。 合計 1000W。 そんなにつかわねー。 その分自宅サーバーに振り分けさせてください、ほんとに。

• ニュースリリース - 極上の苦さとシャープなキレ味「サッポロ 凄味(すごみ)〈生〉」新発売

5/16 に発売されたサッポロビールの発泡酒。 確かに苦味は強い。 でもやっぱりそこまでなんだなぁ。 アルコール度数の高さも裏目に出てる気がするぞ。

最近自宅のブレーカーを落としてしまうことが何度かあり、そのたびにサーバーの復旧に手間を取られました。 毎回同じ手順を手で行うのも面倒なので自動復旧の仕組みを構築しました。

自動復旧にもいくつかのレイヤがあって、まずはハードウェアのレイヤ。 続いてネットワークのレイヤ、最後にサービスのレイヤです。 今回の設定対象は Dell PowerEdge SC430 / CentOS 4.4 です。

まずはマシンがまともに立ち上がらなければ意味がありません。 ぼくが家にいなくても復旧できるように、BIOS の設定を以下のように変更しました。

• Power Management
  • AC Recovery = On

これにより、ブレーカーを戻して電力供給が回復すると自動的にマシンの電源が入ります。 本来であればハードウェアのレイヤを考えるにあたっては、ファイルシステムのチェックもきちんと考える必要があります。 状況によっては fsck がユーザーの入力待ちで停止したりします。 今回はここはスコープ外ということで。

ぼくの自宅では NTT 東日本の B フレッツを契約していて、接続には rp-pppoe を使用しています。 自動復旧だけではなく不慮の回線断も想定して以下のスクリプトを crond から三分毎にたたくようにしました。

#!/bin/sh

MAILTO=admin@example.com
SUBJECT="CONNECTION DOWN"

ADSL_STATUS=/sbin/adsl-status
ADSL_START=/sbin/adsl-start
MAIL_COMMAND=/bin/mail

${ADSL_STATUS}
if [ "$?" == "1" ]; then
  # There is no connection.
  sleep 10
  ${ADSL_START}
  echo "Try to reconnect." | ${MAIL_COMMAND} -s ${SUBJECT} ${MAILTO}
fi

adsl-status で接続状態をチェックし、つながっていなければ adsl-start を実行します。 本来であればこれでうまくいくはずなのですが、内部で呼ばれる adsl-connect が /sbin に PATH が通っていない状況では正常に動かないことが判明しました（デフォルト･ルートが設定されない）。 ちょっと強引ですが、rp-pppoe の設定ファイル（/etc/ppp/pppoe.conf など）に以下の行を追加しています。

PATH=${PATH}:/sbin/

ぼくの自宅環境では必要なすべてのサービスを /etc/rc.d/init.d 以下から起動しています。 chkconfig できちんと設定してあるので特に何も考慮する必要はありませんでした。

シャットダウンしてから電源プラグを抜き差しして動作確認を行いました。 結果、無事に起動してきてサービスの提供まで復旧することが確認できました。 これで突然の停電も安心です。

一つ一つを追いきれないので、まとめて。

• キリン 良質素材

  新ジャンル。麦焼酎の発泡酒割りとのこと。5/23 発売予定。

• 沁 麒麟（ちん きりん）

  上海で発売されたプレミアムビール。四月上旬に発売されたらしい。

• 醍醐味

  麦芽100%ビール。全国のイオングループのお店にて数量限定販売。4/27に既に発売されてます。探して飲まないと。

サッポロビールはいつになく新製品の連続投入です。

• サッポロ 凄味(すごみ)〈生〉

  発泡酒。「本気でお酒を楽しむためには相応の支出は厭わない、むしろ従来にない新たな価値を備えた商品を楽しみたいという消費トレンドが伸びてきている」のになぜか発泡酒。何故だ。「苦さ」「ガツンとした飲みごたえ」とのこと。5/16 発売予定。

• サッポロ W-DRY

  新ジャンル。これも麦焼酎の発泡酒割り。「ズバッとキレる飲みごたえ」とのこと。6/27 発売予定。

• サッポロ エーデルピルス 缶

  プレミアム・ビール。これは新発売ではなくて、これまでは飲食店にだけ卸されていたものを一般発売するもの。キリン ブラウマイスターと似た具合ですな。1987年発売なので、今年で20年目とのこと。5/21からインターネット予約開始。12本入りを5,000セット限定だそうです。

• サントリー　ジョッキ淡旨（あわうま）

  新ジャンル。小麦麦芽使用とのこと。もともと妙な酸味があるところに小麦由来の酸味も加わると、どんなことになるのか。うまく調和してくれると面白いんだけど。数量限定で 5/29 発売予定。

• ザ・プレミアム・モルツ〈黒〉

  言わずとしれたプレミアム・ビール。「ザ・プレミアム モルツ」の黒です。「香ばしさを抑えた甘い香りの黒麦芽」「ホップには華やかな香りの……」。これはいやが上でも期待が高まります。数量限定で 6/26 発売予定。

• モルトセレクション～英国産ロースト麦芽使用～

  ビール。もう飲んじゃったけど。コンビニエンスストア限定ビール第2弾。5/8 に発売になりました。

• 金麦

  新ジャンル。6/19 発売予定。

• ビアフェス2007｜ビール酒造組合

ビール酒造組合、つまり、いわゆる「ビール国内大手五社」が主催するビールのイベントだそうです。 5/24-5/27 の四日間、六本木ヒルズにて。 初日の来場者先着100名には「五社ビールジョッキ詰め合わせ」がプレゼントされるそうな。 うーん、魅力。 でも平日の11:30なんて、社会人には厳しすぎる。

先週の木曜日に、ぐるなびがレストラン検索の API を公開しました。

• ぐるなびWebサービス

所定の URI に所定のパラメータを渡して HTTP で叩くと、検索結果の XML が返ってきます。 非常にシンプル。 で、こいつを PHP でラップしたライブラリを作りました。

• GNavi.php

大したことはやっていないのだけれど、いかんせんリクエスト・パラメータとレストランの属性値の数が多く、手数だけはかかってしまいました。

このライブラリを使うと、こんな感じのアプリがお手軽に作れます。

• GNaviSample.php
• ソースコード

Web サービスのマニュアルはここで提供されています。

• ぐるなびWebサービス ご利用マニュアル

ぐるなびが提供する API を呼ぶには、ユーザー登録をした上でアクセスキーを手に入れる必要があります。 このため、JavaScript などでクライアント・サイドから呼ぶには適しません。 提供されている API は現在のところ五種類です。

• レストラン検索API
• エリアマスタ取得API
• 都道府県マスタAPI
• 大業態マスタ取得API
• 小業態マスタ取得API

このうち検索を行うのは一つ目の「レストラン検索API」のみで、他の四つは常に固定の結果を返します。 業態絞込み検索を行う場合などに、検索画面の表示に使うことができます。

GNavi.php は上記の仕様をラップします。 主に以下の5つの API を提供します。

GNaviRestSearchAPI クラス

レストラン検索です。「2-3-1.レストラン検索API」をラップします。いくつかの検索パラメータ（後述）を受け取ります。検索結果 GNaviRestSearchResult を返します。

GNaviAreaSearchAPI クラス

エリアマスタの取得です。「2-3-2.エリアマスタ取得API」をラップします。検索パラメータは不要です。検索結果 GNaviAreaSearchResult を返します。

GNaviPrefSearchAPI クラス

都道府県マスタの取得です。「2-3-3.都道府県マスタAPI」をラップします。検索パラメータは不要です。検索結果 GNaviPrefSearchResultを返します。

GNaviCategoryLargeSearchAPI クラス

大業態マスタの取得です。「2-3-4.大業態マスタ取得API」をラップします。検索パラメータは不要です。検索結果 GNaviCategoryLargeSearchResult を返します。

GNaviCategorySmallSearchAPI クラス

小業態マスタの取得です。「2-3-5.小業態マスタ取得API」をラップします。検索パラメータは不要です。検索結果 GNaviCategorySmallSearchResult を返します。

各 API クラスの call メソッドは、リクエストがエラーを返した場合は GNaviError クラスのオブジェクトを返します。

各プロパティは「利用案内 2-2. エラー仕様」に準じています。

検索条件は GNaviRestSearchAPIParams クラスで渡します。 基本的には利用マニュアルにある「リクエストパラメータ」をラップしたものですが、coordinates_mode / latitude / longitude はまとめて GeoPoint 型で渡してください。 測地系の違いを吸収します。

検索結果は GNaviRestSearchResult クラスとして戻ります。 以下のクラスを経由して検索結果を取り出せます。

サンプル・コード

// 地域一覧を表示
$keyid = "xxxxxxxx";
$api = new GNaviAreaSearchAPI($keyid);
$result = $api->call();
foreach ($result->areaList as $area) {
  echo ($area->code . ":" . $area->name);
}

サンプル・コード

// 都道府県一覧を表示
$keyid = "xxxxxxxx";
$api = new GNaviPrefSearchAPI($keyid);
$result = $api->call();
foreach ($result->prefList as $pref) {
  echo ($pref->code . ":" . $pref->name . ":" . $pref->areaCode);
}

サンプル・コード

// 大業態一覧を表示
$keyid = "xxxxxxxx";
$api = new GNaviCategoryLargeSearchAPI($keyid);
$result = $api->call();
foreach ($result->categoryLargeList as $categoryLarge) {
  echo ($categoryLarge->code . ":" . $categoryLarge->name);
}

サンプル・コード

// 小業態一覧を表示
$keyid = "xxxxxxxx";
$api = new GNaviCategorySmallSearchAPI($keyid);
$result = $api->call();
foreach ($result->categorySmallList as $categorySmall) {
  echo ($categorySmall->code . ":"
          . $categorySmall->name . ":"
          . $categorySmall->categoryLCode);
}

このライブラリを使用する場合はぐるなびWebサービスの利用規約、ガイドラインに従ってください。

• ぐるなびWebサービス 利用規約
• ぐるなびWebサービス ガイドライン

いやぁ、良い天気です。 今日は早起きして、午前中フットサルをしてきました。 で、帰ってきたらやっぱりビール。 あやうくごくごく全部飲み干しそうになったので、急いでメモ。

今日飲んだのは 5/8 に発売になったサントリーの「サントリー　モルトセレクション～英国産ロースト麦芽使用～」。 このシリーズは「モルトセレクション～カナダ産麦芽使用～」に続き二つめですね。

• Suntory News Release No.9776

液色は中等色程度のアンバー。 モルトの香りが漂います。 英国産ロースト麦芽使用とのことなので、英国スタイルなのかと思ったらそうでもないようで。 飲んでみると、比較的カーボンが強めです。 運動後にはちょうど良いねぇ。 味もきちんとモルトがきいていて旨い。 ほんと、あやうくごくごく飲み干しそうでした。 が、アルコール度数はちょっと高めの 6% なのでご注意。

コンビにのみ、期間限定での発売です。 お早めに。

続報。ニュースリリース発見。

• ぐるなび、全国約４万件の飲食店情報をＡＰＩで公開 ～ 「ぐるなびＷＥＢサービス」開始 ～ 2007 年5 月10 日（木）サービス開始 (PDF)

公開情報は「店名、住所、飲食店ジャンル、最寄駅、座標（緯度・経度）、平均予算、お店のＰＲ文、写真（各店舗につき最大2 枚）」とのこと。 気になるのは検索条件のパラメータだな。 詳細情報は明日から公開されるこのサイトで手に入るでしょう、きっと。

• ぐるなび Web サービス

詳細は不明ながら、ぐるなびが飲食店データベースのデータを API 経由で公開するそうな。 明日、05/10 からとのこと。 興味あるな。

Twitter + 位置情報の LocTwitter を更新しまして、au と DoCoMo の端末にも対応したつもりです。

• LocTwitter Beta :: What are you doing, in where ?

「つもり」ってのは手元に実機がないのできちんと動作確認できていないことと、報告によると文字化けする場合もあったりして。 なので「つもり対応」で。

今回初めて au / DoCoMo 向けコンテンツをつくったので、参考にした情報などをメモ。 まずは全般。

• 作ろうiモードコンテンツ | サービス・機能 | NTTドコモ
• KDDI au: EZfactory
• WILLCOM｜ウィルコムの電話機向けホームページの作成方法

続いて位置情報の取得関連。

• GPS | サービス・機能 | NTTドコモ
• KDDI au: 技術情報 > 簡易位置情報

User-Agent の取得。

• 作ろうiモードコンテンツ：iモード対応HTMLの考え方 | サービス・機能 | NTTドコモ
• KDDI au: そのほかの技術情報 > ユーザーエージェント

で、一応モバイル端末対応用ライブラリを「途中まで」作りました。 SoftBank 未対応。 ほんとすみません。 DoCoMo の実装も中途半端です。 User-Agent の仕様がややこしいんだもん。

• Mobile.php

まずは端末の判定。

$mobilePhoneInfo =  MobilePhoneInfo::getInstance($_SERVER);
echo $mobilePhoneInfo->carrier;

これでキャリアが取得できます。 MobilePhoneInfo クラスは他にも機種名とか、User-Agent に入っている情報をプロパティとしてもたせてあります。 ただ、詳細プロパティ取得は DoCoMo 未実装。 キャリアのみ。 だって User-Agent の仕様が……。

続いて位置情報取得関連。 キャリア間の差異を吸収し、位置情報取得のための A 要素を生成します。

MobileUtils::getLocationRetrieveLink(
    $mobilePhoneInfo,
    "http://example.com/target.cgi",
    "LinkName");

次は位置情報の解析。 先ほどのリンクから飛んだ先に仕掛けます。

$mobilePhoneInfo =
    MobilePhoneInfo::getInstance($_SERVER);
$point = MobileUtils::getMobilePhoneLocation(
    $mobilePhoneInfo, $_REQUEST);

GeoPoint クラスのインスタンスが返ります。 キャリアごとの測地系の違い、パラメータ名の違いを吸収します。

最後に、返すコンテンツの文字コードの扱い。

<?php MobileUtils::startResponse(); ?>
ご自由にコンテンツ生成
<?php MobileUtils::endResponse($mobilePhoneInfo, "UTF-8");?>

キャリアにあわせて、"Content-Type" HTTP レスポンス・ヘッダの設定とコンテンツの文字エンコーディング変換を行います。 コンテンツ内で行われた XML 宣言や meta 関連は変換できないのでご注意ください。 endResponse の第二引数は生成したコンテンツの元の文字エンコーディングです。

先日、多少遅い時間に多少長い距離を電車で移動する機会がありました。 朝も早かったのでゆっくりしたかったので、ちょっと贅沢をしてグリーン車に乗ることに。 まぁ、普通電車のグリーン券は大した額じゃないんだけどね。 詳しくは下のリンクを見て欲しいのだけれど、首都圏であれば土日50キロ以内なら550円（ただし事前購入）です。 ぼくは土日 / 事前購入 / 51キロ以上だったので750円。 新幹線に較べたら格安ですな。

• JR東日本：きっぷに関するご案内

で、せっかく事前購入なので「グリーン車Suicaシステム」という仕組みを利用してみることにしました。 敢えて PASMO で。

• JR東日本：Suica｜Suicaでの普通列車グリーン車のご利用について

Suica と PASMO の相互乗り入れが可能になったので、このシステムもきっといけるんじゃないかな～という軽い気持ちで試したところ、あっさり購入完了。 うーむ、素敵だ。 もちろん PASMO なので乗車券が発行されるのではなく、カード内にグリーン券の情報が記録されます。 そのまま改札を通って列車に乗り込みます。 乗り込んだら空席を探して座りましょう。 空席の目安は席の頭上のランプ。 こいつが赤くなっていれば空席です。 座る席を決めたらその頭上のランプの脇の Suica マークに「ピッ」とタッチ。

"Suica" マークに PASMO でタッチ

ランプが緑に変わります。 この状態になれば、検札なども不要になるのでゆっくりと眠れます。

ここで気になるのは、たとえば席の移動などで複数の席にタッチした場合にどうなるか。 試しに他の空席にタッチしてみるとそこが緑に変わり、先にタッチしていた席は赤に戻ります。 なるほど。 ちゃんと考えられていますな。 このときぼくが乗った編成はグリーン車が二両連結されていました。 そこで、隣の車両までひとっ走りいって、ここでも空席を探してタッチ。 緑に変わります。 再び元の座席に戻るとこちらはきちんと赤くなっていました。 車両をまたがってもちゃんと整合性とってあるんだねぇ。 そりゃそうか。

比較的安いし、お手軽だし、のんびりできるのでなかなか良いですよ、グリーン券 Suica システム。

昨日のこどもの日、都内某所にて。 半袖でも汗ばむような陽気の中、彼らがまつりの会場に向かう足取りは重たかったです。 ピーポくんの横のピンク色の連れは、うつむき加減で歩くと首筋から中身がはみ出しそうになっていました。 でも肝心の子供たちの姿はなくて大人ばっかり。 君たち、その勇姿を誰に見せようとしてるのよ？

大型連休最終日は雨ですなぁ。 雨ならば仕方がない。 泣く泣く家にこもってプログラムでも。 あぁ辛いなぁ。

というわけで、昨日作った最寄駅検索を Ajax 向けサービス化しました。

• StationService.php
• ソース・コード

サービス呼び出しに必要な情報をどう書くかって、何か標準あるのかな？ まーいいや。

• nearestStation.html

サービス側の実装には以下のライブラリを利用しました。

• PEAR :: PEPr :: Details :: Services_JSON

クライアント側、サンプルコードの実装には以下のライブラリを利用しました。

• Prototype JavaScript framework: Easy Ajax and DOM manipulation for dynamic web applications
• prototype.js v1.5.0 の使い方

"Twitter + 位置情報" のその後。 Twitter への更新に最寄駅も付加するようにしました。 その副産物としてできたのがこれ。

• 最寄駅検索
• Station.php

こちらはサンプル程度の位置付けなので、まだ携帯端末からデータを取得するようにはなっていませんが、手入力で何とか動いています。

元になる駅の座標データを手に入れたのはここです。

• 国土数値情報ダウンロードサービス

説明書きに「国土数値情報データファイルは、国土の自然的、社会的、文化的諸条件を、その地理的位置とともに数値化したデジタルデータです。」とある通り、各種位置情報をダウンロードすることができます。 今回は鉄道駅の情報しか利用していませんが、文化財、公共施設なんてのも活用できると面白そう。

こうして手に入れたデータを Perl でちょろっと加工して、DB に流し込んで利用しています。

• ddl.sql
• station.pl
• point.pl

PostgreSQL は座標や閉経路などの幾何データを扱うことが出来ます。 今回はこの機能を利用して、入力した点から一番近い駅を検索しています。 ただ、本来は距離の計算は測地系を考慮して曲面上で行わなければいけません。 現在のところ PostgreSQL の距離演算子 "<=>" を使い、平面上の直交座標として緯度経度を扱ってしまっているのである程度の誤差はあるかと思います。 このあたりを本気で扱うには PostGIS を使う必要があるようです。

• PostGIS : Home

国内の鉄道駅だけであれば大した件数にはならないので、今はインデックスを使っていません。 もし使うような状況になったら、ここの TIPS が役に立ちそうです。

• データベース上の位置情報を効率的に検索する方法(PostgreSQL編)

Willcom の端末が取得した位置情報を Google Map に投げてみたところ、測地系が異なることが判明。 Willcom は日本測地系（Tokyo）で、Google Map は世界測地系（WGS 1984）のようです。 こいつを変換してやりたいのだけれど、実はこれは非常に厄介な問題。 本気で取り組もうとするとこんなことになります。

• Web版TKY2JGD
• 世界測地系移行のための座標変換ソフトウェア "TKY2JGD" (PDF)

多少大雑把にやろうとしてもこんな具合。

• 座標系変換パラメータ

この値を足して補正してやる必要があります。 手順自体は簡単だけれど、どの値を使うかを条件式で判断するのが非常に萎える。

これらは、三角点測量の誤差の補正も行おうとしているためにこんなに複雑になっています。 次善の策として、準拠楕円体、測地座標系を数学的に変換するだけでお茶を濁すことにしました。 測定誤差は無視。 この変換にはいくつか方法があるようですが、今回は Molodensky変換というアルゴリズムを用います。

• 02 DATUM
• Molodensky.pl

計算に必要な準拠楕円体と測地座標系の情報はここから入手。

• Geodetic Datum Overview
• Reference Ellipsoids and Geodetic Datum Transformation Parameters (Local to WGS-84) From NIMA 8350.2 4 July 1977 and MADTRAN 1 October 1996

この表を awk で変換して PHP の参照配列に突っ込んで利用しました。 で完成したライブラリがこちら。

• GeodeticDatumTransformer.php

使い方はこんな感じです。

// 測地系のインスタンス (Datum)を取得
// ここでは日本測地系
$tokyo = Datum::getInstance("Tokyo");

// 日本測地系での緯度経度に基づいて地点のインスタンス (GeoPoint) を取得
$point = $tokyo->createGeoPoint(35.677720215,139.7733459);

// 変換先の測地系のインスタンスを取得
$wgs = Datum::getInstance("WGS 1984");

// Molodensky 変換
$result = Molodensky::convert($point, $wgs); 

// 結果取得
$lan = $result->getLan();
$lon = $result->getLon();

測地系を名前で引いていますが、これは上記の "Reference Ellipsoids and Geodetic Datum Transformation Parameters (Local to WGS-84) From NIMA 8350.2 4 July 1977 and MADTRAN 1 October 1996" にある Datum の名前です。 場合によっては同じ名前のものが複数ありますが、これは "Region in use" が異なっていて、測地座標系に違いがあります。 Region も指定して測地系を取得したい場合は、Datum::getInstance の第二引数に指定してください。

// 沖縄の場合
$tokyo = Datum::getInstance("Tokyo", "Okinawa");

このライブラリによって当初の問題は解決して、きちんと Google Map が使えるようになりました。 ただ、ぼくが使っている端末の場合、端末の位置ではなく基地局の位置が返るので、なんというか、多少オーバースペックなような気もしますが。

ガヂェット から紹介してもらって Twitter なるものを始めてみました。

• Twitter

サービスの細かい説明は省いてキモだけ。 Twitter が投げかける "What are you doing ?" という問いに対して、各人が「御飯の準備中」であったり「風呂入ってきます」といった答え、つまり "そのときの自分の状況" を書き込み、それをみんなで見せ合うものです。 IM のプレゼンス機能に履歴がついたような感じ。 これだけじゃなにやらよくわからないと思うので、詳細は以下の記事などを読んでみてください。

• 先取り！ Twitter使いへの道 AtoZ｜gihyo.jp

とにかく思い立ったときに「今はこんなことしてるよ」と書き込み、また、他の人が何しているかを読むわけです。 ただ、これだけだとちょっと物足りなく思えてしばし思案した結果、位置情報を付加すると面白いんじゃないかと。 「昼飯食ってる」というコメントに較べると「昼飯食ってる、どこそこで」というコメントでは、なんというかその先の話の広がりが全然違う。 「おー、連休なのに会社でメシ食ってるよ、この人」とか、「ほぅ、箱根ですか。良いですなぁ。」とか。 かといって、何処にいるのかをいちいち書くのも面倒（ぼくは携帯端末での文字入力がひどく苦手）。 ぼくが使っている Willcom の PHS には HTTP リクエストに 位置情報を付加する機能があるので、これを利用して「どこそこで」部分を自動化するサービスを作成しました。

• LocTwitter Beta :: What are you doing, in where ?

このサービス経由で "What are you doing ?" に答えると、自動的に末尾に Google Map へのリンクを追加して Twitter を更新します。 途中、login/password の入力を求められるので Twitter のアカウントを入力してください。 この情報は一切記録もキャッシュもしませんし、ログにも吐きません（逆にそんな情報を抱えるリスクが気持ち悪すぎる）。 どうぞご安心を。

裏で利用しているのは Twitter API です。

• Twitter Development Talk | Google グループ
• API Documentation - Twitter Development Talk | Google グループ

参考までに、Willcom が公開している「ウィルコムの携帯電話向けホームページの作成方法です。

• WILLCOM｜ウィルコムの電話機向けホームページの作成方法

「応用編」に位置情報の取り方がかかれています。

ちなみに、このサービスを利用して「あなた！何でこの時間にこんなところにいるのよ！」といった修羅場を迎えようが、どのような損害があなたに降りかかろうが、ぼくは責任を負いませんよ。 サービスのアベイラビリティも何ら保証しません。 気をつけて！

• 御殿場高原ビール ヴァイツェン
• チョコベアビア - えぞ麦酒

御殿場高原ビールは近所のスーパーにて。 チョコベアビアは頂き物。

飲みましたよ、塩ビール。

• 塩ビール - しらす料理専門店　とびっちょ

原材料は「大麦、麦芽、ホップ、加計呂麻の塩」。 はい、またもキワモノ系ですね。 ビールに塩です。 この組み合わせ、中学生時代のとある日が思い出されます。

当時、土日の部活練習には水筒持参でした。 しかしスポーツドリンク禁止という厳しいお触れがあったため、いつも中身は麦茶です。 炎天下で飲み干す冷たい麦茶。 これが美味いんだなぁ。 たまりません。
しかしある日、悲劇がこのぼくを襲います。 いつものように飲み干した冷たい麦茶。 渇いた喉を潤す素敵な飲み物。 それがこの日ばかりは違いました。 不味いのですよ、明らかに不味い。 いつもだったら「コクコクッ」と爽やか～に喉を通り抜けていくところが、今日はなんというか「ヌモォヌモォ」とまとわりついて最悪な後味です。 「干し椎茸の戻し汁を間違って持ってきちゃいました」とか、そこまで派手な違いはなくて、麦茶であることは間違いない。 でもいつもの麦茶では決してないのです。 試しに周りの友人たちに飲ませても、皆一様に「これはおかしい」という反応。 「腐ってんじゃない？」「漬け洗いの洗剤が残ってたんじゃない？」と。 とりあえず「飲めるものではなさそうだ」という結論で一致したので、この日は泣く泣く麦茶はあきらめることに。 炎天下、カラカラに渇いた喉。 最悪の一日です。

で、家に帰って母親に「麦茶がなんかおかしかった」と伝えると「あぁ、塩入れたんだよ」と驚愕の事実が。 なんと！ 麦茶にですよ。 スイカやナメクジと違うんですよ。 そこに塩を投入するこの感性。 なかなか見上げたものです。 その一つまみの塩のせいでぼくがどれだけ辛い思いをしたか。

とまぁ、中学生をして「腐敗」や「洗剤」を思わせる「麦 + 塩」の組み合わせが、十余年の年月を経て、再びぼくの目の前に現れたわけですよ。 それがこの「塩ビール」。 もうね、栓を抜く手が震えますね。

グラスに注ぐと軽く白濁した淡色。 エステルのちょっと華やかな香り。 飲んでみると……ぼくの記憶にある「塩麦茶」には遠くおよばないながらも、なんというかまとわりつくような後味の抜けの悪さが少し感じられます。 多分そんなに不味くはないのだろうけれど、ぼくの場合はちょっときつかったな。