※飽くまで私個人の考えた仕様案です。ロカポイント公式の仕様ではないので留意してください。

ロカポイント（通称ロカポ）は、全世界の場所をを英数字12桁で表現できる仕様です。
詳細はこちらを見ていただきたいのですが、特長の一つとして、12桁の前半6桁が大まかな位置を表すエリアコード、後半6桁が正確な位置を表すローカルコードと分かれているので、同じエリアコード内であればわずか6桁の英数字を扱うだけで、場所を一意に指定する事ができます。

例えば、以下は新宿周辺のエリア（エリアコード：SE0.XC3）ですが、その中で都庁はローカルコード：IV4.CR3で表すことができます。
よって都庁の正確なロカポはSE0.XC3.IV4.CR3となりますが、日常用途ではIV4.CR3で覚えておけば十分、ということになります。

このように便利なロカポなのですが、問題もあり、エリアコードは人間の生活圏単位で切られるのではなく機械的に経緯度から計算されたラインでぶった切られるので、例えば東京駅等、エリアの境目が駅のど真ん中を通るような場合は、通常の生活圏をエリアがまたがる事になり、ローカルコードだけでは一意に使えないという問題点が出てきます。
うまく東京駅を内部に含むような、エリアを定義できればいいのに...という要望が出てきます。

そこで、エリア定義を自由にシフトできる案を考えました。
自由といっても、数m単位で自由に動かせる、とかになると情報量が多大になるので、経緯度ともローカルコードの上位1桁（英字1字）単位でしかシフトできないことにしました。
また、シフトの方向（南にシフトするのか、北にシフトするのか）の情報量も減らすため、コードの値の増加する方向（経度を動かすならば東、緯度ならば北）にしかシフトしないことにしました。
このシフト定義でも、経度は東西とも180度で繋がっているし、南北は逆に切れているためエリアをシフトする要望自体が生じ得ないので、問題は生じません。
またシフト量の表現方法は、定義されたエリアでのローカルコード一桁目が始まる英字で表すこととしました。
つまり、全くシフトを行わない場合は、シフト量「A」となります。

この考え方で上の東京駅周辺の新しいエリアを表現すると、

新しいエリア定義表記としては、SD9.XC4[NA]といった形になり、このエリアは南西はSD9.XC4.NA0.AA0から、北東はSE0.XC4.MZ9.ZZ9までのロカポを含むエリアとして定義されたことになります。
このようなエリアが定義されれば、後はその中ではローカルコードは一意になるので、ローカルコードだけで位置の特定ができるようになります。
注意すべき点は、SD9.XC4[NA]といった新しいエリア定義の中で指定されたローカルコードであっても、それをフルスペックのロカポに直した場合は、通常の表記になるということです。
例えば、上記新エリアSD9.XC4[NA]の中で皇居の位置はBI7.FB2と表せますが、これをフルスペックのロカポにした場合は飽くまでSE0.XC4.BI7.FB2であって、SD9.XC4[NA].BI7.FB2ではないということです。

このように自由にエリアを定義できるようにすることによって、例えば駅周辺マップ等にロカポのエリアを使い、その中の店の場所の特定に簡単なローカルコード6桁だけを使うといったロカポの応用例も考えられるようになります。

ロカポイントを提唱している有限会社ロケージングさんとも上記仕様についていろいろ協議して調整しているところなのですが、あえて記事に取り上げ、公の議論にすることでロカポそのものの認知度も高まるかと思い、記事にしてみました。

最近発展著しいOpenID、発展著しすぎて1.0から追えていない私としては何が発展してるのかも判ってない状況ですが、そんな中、重田さんという方がOpenIDの日本語Google Groupを作ってくださいました。

Google Groups: openid-ja

OpenID Wikiの日本語訳も鋭意進めておられるようです...って人事かい！手伝えよ！という感じですが、すんませんできそうなところは協力しますですはい...。

これで日本のOpenID議論が盛り上がれば嬉しいなあ（...って、興味持つ連中が増えて自分が英語ML読まなくても流れが判るようになりたいだけなの見え見え）。

ケータイ族はPC族のカモ、かも -404 Blog Not Found-

ケータイサイトは、ケータイだけでは作れないからだ。

「いや、メールも出せる。moblogもある」という反論もあるかも知れない。しかしそれらのサービスを提供しているサーバーは何で動いているか？ケータイじゃないことだけは確かだよね。

でも、PCのサービスを提供しているサーバだって、Windows XPやMac OS、WordやExcelやOutlookで動いているのではないような。
さくらのレンタルサーバとかの個人サーバならともかく、お金を生みまくってるサービスのサーバは、多分CPUもPentiumやAthlonではないんじゃないだろうか。
その意味ではケータイもPCも条件は一緒。
ギークにとってはPCの延長上にサーバがある、のであっても、一般ユーザにとってはPCとサーバは明らかに別物。
にもかかわらず、サービスを提供できるサーバを取り扱える連中を強引に「PC族」側に分類してしまって、「ケータイ族」はそのカモだ、というのは強弁すぎないか。
しいていうなら、PC族もケータイ族も、サーバ族のカモなのであり、そしてどちらをカモにするにしても、「カモにする対象」を「よく知る」者がより上手にカモにできる、というだけのことだ。

そのうえで、あえて（どちらもサーバ族の一派に支配されている）「ケータイ族」の世界と「PC族」の世界を比較してみると、

ケータイの世界すら、そのルールはネットで決まっているのだ。

その言いようはまるで、htmlのタグ名やPC言語のコマンド名は欧米語だから、日本のWebは欧米のWebを越えられない、とでも言うようなレベルに聞こえる。
ケータイのWebの世界がネット世界のルールで基底されているのは確かだ。
けど、むしろそのルールを使って --- HTTPリクエストのUserAgentヘッダでケータイ以外を弾いたり、IPでBANしたり --- PCウェブに内包されないケータイだけの純世界を作ることは簡単に実現できるわけだ。
以前も紹介したBitPetsのように、コンテンツの一切をPCから見られることを拒否したサービスすらある、それでいて最大風速ではMixiを上回る勢いでユーザを増やしたりしている（その後は追ってないけど）。
他にもGoccoとか、そのような勢いのあるモバイル向けサービスはいくつもある。

またケータイは、常にいつも持ち歩かれていることをフルに利用した「イマ！」の情報、そして既に大半の端末で取得できるようになっている位置情報を使っての「ココ！」の情報等、PCでは扱えないケータイ特有のユーザコンテクストを利用したコンテンツの見せ方や新しい金の流れ等、PCウェブでは実現できない独自の発展もとげている。
PCだってGPS機器を接続したりWiFi測位で位置を取得する事は可能だが、その取得した位置情報をどのPCでも共通に活用できるような統一されたインタフェースは存在しない。
だが、ケータイの場合、キャリア毎の差はあっても、同じキャリア内であれば基本的に端末さえあれば、誰でも同じように意識することなく、位置情報等ユーザに密着したコンテクストを活かしたコンテンツを利用できる。

さらに、ケータイでのネット接続は、一般ユーザには面倒なファイアウォールやルータ、ネット接続の設定、メーラの設定やブラウザの設定、そんなもの何一ついらず、持っているだけでそのまま使える。
ウィルスの脅威も今のところ気にする必要もない。
PC族のネット世界では、サーバ族のネット世界と地続きなだけに、サーバ族くずれの「モヒカン族」とか言う連中がムラをぶち壊しにやってくるが、ケータイ族の世界ではそんな心配もなく、和気藹々とムラ社会の生ぬるさを維持できる。
この環境の差は大きい。

このような特性の違いから、いまや同じTCP/IPの流れの恵みの上に文明を築いていても、PC族とケータイ族は異なる文化圏を築いているのは厳然たる事実。
いやこう偉そうに書いてる俺だって実感は全くできないんだよ、俺自身はケータイの小さい画面と親指入力で長文を読んだり書いたりしたいとは思わないし、いろいろ比較もできないケータイ画面上でネットショッピングしたいなんてことは思わない。
でも、個人の感覚として理解できるできないとは関係なく、その方面の文化がどんどん成熟していってるのは事実だし、その事実を認めなければ「ケータイ族から収奪」する側にはまわれない。
いつまでも「しょせんケータイウェブなんてPCウェブの一部分」という感覚でいるサーバ族は、PC族からしか収奪する事ができずケータイ族から収奪する機会を逃している、ということだ。

というわけで、ケータイ族の豊穣の地を刈り取りたい！という野望を持つ人は、以前も紹介したこちらの本をどうぞ。

Mobile2.0 ポストWeb2.0時代のケータイビジネス posted with amazlet on 06.10.27 宮澤 弦 椎葉 宏 片岡 俊行 新上 幸二 横山 隆治 手嶋 浩己 木暮 祐一 インプレスジャパン Amazon.co.jp で詳細を見る

最初に断っておくと飽くまで技術的可能性だけで、本家アンテナDASHで対応予定という意味ではありません。
また、私はWillcomを持っていないので、全く何も確かめたわけではありません。
飽くまで、他所で読んだ技術的可能性を引用するのみです。

これまで、Willcom版のアンテナDASHは京ぽん（の、ファームウェア更新していないバージョン）でしか遊ぶ事ができませんでした。
その理由は、本来は複数アンテナからの測位結果を返すはずのWillcomの位置情報仕様で、単独のアンテナ位置を取得するカラクリが、京ぽんハード独自の仕様（或いはバグ）に頼っていたためです。
ファームウェアの古い京ぽんでは、ネットワーク接続を切断した直後の最初の一回の測位では複数アンテナからの位置を返すのですが、ネットワークが接続し続けている状態で測位すると単独のアンテナ位置を返すというバグ、もしくは仕様があります。
そこで、アンテナDASHでは、「アンテナDASH」のリンクをクリックすると、まずJavascriptだけのページを返し、そのJavascript上でノータイムで測位を行うためのURLに転送することで、必ずJavascriptページ⇒測位ページとネットワーク切断されない状況での測位が行われる仕掛けを作り、単独アンテナの位置を取得することに成功していました。

ですが、京ぽんも発売されてもう2年以上。
アンテナDASHを楽しんでいて、そのために機種変できないユーザも、そろそろ「3代目の京ぽんも壊れてしまった」とか言う人もいたりで、機種変の誘惑で一人去り二人去り、誘惑に負けなくても物理的に壊れてしまりと、どんどんアンテナDASHを続けられない人が増えている状況にあります。
今後もWillcom版のアンテナDASHの灯を消さないためには、京ぽん以外の機種でも単独アンテナ位置取得ができる方法を見つけなければいけませんが、そのブレークスルーになりそうな技術的可能性が見えてきました。

事の発端は、今はPCからは見えなくなっている（SPAM対策？）アンテナDASHのバグ・要望板への投稿。
私はWillcom機を持っていないのでよく判らないのですが、Willcomの端末では、Webブラウザのプロキシを登録することができるそうです。
そうしますと当然、端末からネットワークに至る通信は全てプロキシサーバを通過するわけですが、この際、測位の際の位置取得サーバへの通信も、プロキシを通過するらしいのです。
すると、そのプロキシを通過する通信で、端末が位置取得サーバに送信するHTTPリクエストに含まれる、現在電波を受信しているアンテナに関する情報を受け取れるということらしいのです。
アンテナ情報は、拡張HTTPヘッダの「X-CS-INFO」で取得でき、電波を受信しているアンテナが一つの時はそのアンテナのCSID（アンテナを一意に表すID）とそこからの電解強度、複数の時はそれぞれのCSIDと電解強度がセミコロンで列挙されるようです。
そこでプロキシを通過する際に、X-CS-INFOで端末から通知されてきたアンテナ本数が何本であろうと、2本目以降の情報を落として位置取得サーバへ転送してやれば、アンテナ1本からの測位結果（＝アンテナ位置）がスクリプトに通知されるのではないか、という原理です。
思いついた人天才。
飽くまで未確認で、できるのではないかという可能性レベルですが...。

この方法がうまくいけばすごいのは、上のような仕掛けさえ実現してくれるプロキシサーバだけ準備すれば、後はプロキシ側でアンテナを1本にするための仕掛けを完成させてくれるので、アンテナDASHのスクリプト側は別に何も変更を加える必要はない点。
むしろ、無意味になるJavascript転送ページが不要になる分、構成としては単純になります。
プロキシサーバとの連携すら必要ありません。

でも、よくよく考えてみると、端末側の網（端末が存在する）、Willcomの内部ネットワーク網（位置取得サーバが存在する）、インターネット網（プロキシサーバ、スクリプトサーバが存在する）と網が存在する中で、端末と位置取得サーバ間の通信をプロキシサーバが拾う事ができる？？？？いったい網間の繋がりはどんな構成になってるの？と不思議がいっぱいになるのだが、このサイトで書かれているとおり、プロキシサーバでアンテナ情報が横取り40万できるというのは確かなようだ。

とか何とか、Willcom版全機種対応への光が見え始めた矢先に、アンテナDASH運営の木村さんから、京ぽん版・SoftBank-2G版の中止決定がアナウンスされた模様です。
確かに参加者数から考えたら、既に対応している機種を持っている人も少なく、新規ユーザはほぼ見込めず減る一方と思われる京ぽん・SoftBank-2Gは廃止せざるを得ないのかもしれないのだけど、結局ユーザが増えない最大の理由は対応機種が今後増えない事なのだから、SoftBank版は3Gに移行すれば今後も対応機種どんどん増えていくし、Willcom版も上のような方法で全機種展開は可能になる可能性が高いというわけで、対応機種を増やすための施策は共に存在するわけで。
安易にWillcom・SoftBank版のアンテナDASHIの灯を消さないで欲しいなあ...と思います。
後半年くらい頑張れば、似たようなケータイ位置情報ゲームサイトで味を占めたどこかの会社がスクリプト買ってくれたりするかもよ...と意味深なことを書いてみたりも。

Amazon EC2のインスタンスを立ち上げると、150GB分のストレージ領域が準備されます。
インスタンス実行途中のイメージを作った場合、てっきり、この全領域のイメージが作られるものだと思っていましたが、イメージに出来るのは1.5GB分のシステム領域のみのようです。

EC2のストレージ領域は、

    Filesystem           1K-blocks      Used Available Use% Mounted on
    /dev/sda1              1548096   1077432    391972  74% /
    /dev/sda2            153915428    192676 145904308   1% /mnt

の2領域が提供されますが、このうちイメージが作られるのは/dev/sda1で割り当てられた1.5GB分だけであり、150GBはデフォルトではバックアップ手段は準備されておらずインスタンス停止毎に廃棄されるみたい。

というか、イメージを作るコマンドの

ec2-bundle-vol

はRubyスクリプトで、中で/mntディレクトリのイメージ化を抑制していたので、ソースをいじればイメージ自体は作れるみたい（多分）なのだけど、そうしたところでインスタンス起動時の展開はされないようなので、いずれにしろインスタンスの雛形としてイメージ化できるのは1.5GB分だけってのはガチっぽい。

というわけなので、残りの150GB分のバックアップは、自分でS3に転送するとかのソリューションを手作りするしかないっぽい。
それもあって、S3に簡単に転送できるコマンドとかは欲しいなあと思うところなのだけど。

そんなの知らなかったので、昨日1日かけてPostgreSQLとかPostGISとかガシガシ入れていってたら、 /dev/sda1がいっぱいいっぱいになったので一部を/dev/sda2に逃がしてやったところ、イメージ化して再インスタンス化すると全部消えてて涙ダーーーーーーッだった。
昨日1日の時間とインスタンス起動代を返せ(涙)。

もちろん、インスタンスを起動している限りにおいては、rebootかけてもデータは残るので、インスタンスを落とさなければいい話なのだけど。
俺みたいな日曜プログラマって、サーバをいじれる時間を取れるのって週末だけなので、サービス稼動前はサーバ構築作業を週末毎にやって、後はイメージ化してインスタンスを落としておけば課金されないっていいシステムだよなあーって思っていただけに、実はそういう使い方ができないというのはちょっとショック。

こちらで述べましたShibuya.pmテクニカルトーク#7、行ってまいりました。
内容の詳細についてはこちらに何時かプレゼンがアップされるのをキボンヌしつつ（現時点まだ挙げられていない）、まあ感想を一言で言うと「難しかった...」でした。
MogileFSとかさっぱ判んねがった。
日曜プログラマ（＠サボり中）ではついていけない世界になりつつあるな...と思いますた。

そんな中、最初のEmersonさんの講演で、素晴らしいツールの存在を知りました。
AmazonのWebサービスで、私が何度か紹介してきた仮想サーバ環境EC2の他にストレージサービスのS3（Simple Storage Service）がありますが、そのS3サービスにFirefoxからFTPクライアントのような形でアクセスできるアドオン「S3 Firefox Organizer(S3Fox)」です。

実行すると上のような感じで、FTPクライアントの感覚で簡単にローカルファイルのS3アップロード/ダウンロードができるようになります。便利。
EC2のインスタンス上からも、こんな感じで簡単にS3とデータ交換するコマンドとか用意されてればいいのになあ。
（実行環境のイメージ化⇒アップロードはコマンド化されているのですが）

S3といえば、昨日（土曜日）の深夜から早朝にかけて、断続的にS3に繋がりにくくEC2のイメージアップロードもできない状況が続いてました（アクセスしても500 Internal Server Errorが返る）。
もしかするとShibuya.pmテクニカルトーク#7直後の週末だからみんな触りはじめたということでしょうか。
まだベータだから、急にアクセスが増えるとこんな障害も仕方ないですね、安定化を暖かく見守りましょう...って、ベータ中でも金かかってんだよ！不具合でイメージアップロードできないからインスタンスも落とせずに課金されていくって酷いじゃないか！
いくら安いといっても、一般サービスと比較して安いというだけで、無駄に起動してても気にならないレベルではないぞ...やっぱベータテスト中は非課金にして欲しいなあ...。

gコンテンツワールドの楽屋裏で、セッションを全て有料にせず一部無料セッションも作れば、もっとお客さん来るかもねーみたいな話もしてた。
いや、一応会場かなり埋まるほどのお客さんは来ていたのだけど、元々会場がこじんまりしているし、流石に立ち見はいない（人数を事務局側で切っていたかもしれないけど）。

あまり知名度のないっぽいこのイベントだけど、でも結構内容見てみるとすごいイベントだよ。
今年の2日目のセッションみても、Yahooとマイクロソフトが講演してるけど、これ、両方とも両社がGoogle Mapsのように今後展開していく地域ローカルサイトの紹介・告知を、どちらもプレスリリース前にgコンテンツワールドでプレ発表してるんだって。
だって、というのは、2日目のほう、仕事で見られなかったから伝聞体なのだけどさ。
プレスリリース前の講演が見れるって、すごいと思わん？

というわけで面白いイベントなので、今年見れなかった人も来年は見るがヨロシ。
というかその前に、gコンテンツワールドとは違うのだけどgコンテンツ流通推進協議会の成果報告会というのが来年3月にあるらしいので、まずそっちを覗いてみるのも吉かも。

もっと大きなイベントにしたら、とか話してると「予算ない」みたいな話だったけど、企業からの出資も募って、日本版Where2.0にしてしまえばいいのに。
半官団体の主催だと、その辺何かと難しいんだろうか。

来る11月1日、オークニーさんがオープンソースWebマッピング活用のセミナーを横浜で開催されます。
終了後には飲み会も開催されます。
参加費無料ですので、ぜひたくさんご参加ください（参加方法はリンク先参照）。

ただ言っとくけど飲み会は有料だお。
私は仕事があるのでセミナーは行けるか微妙だけど飲み会は申し込み済み。
セミナーは200人と余裕あるけど飲み会は30人と制限されてるのでお早めに。

セミナー：

日時

2006年11月1日（水）　14時～16時半（開場13時30分）

会場

横浜情報文化センター　情文ホール

〒231-0021　横浜市中区日本大通11番地

・JR線､市営地下鉄線「関内駅」徒歩10分

・みなとみらい線「日本大通り駅」直結

定員

200名

基調講演

「オープンソースGISの動向とOsGeo日本支部設立について」

大阪市立大学学術情報総合センター教授/ OSGeo財団（本部）役員ベンカテッシュ ラガワン

一般講演

「オークニーが発信する最新のオープンソースWebマッピング動向」

株式会社オークニー　代表取締役　森亮

ユーザー事例

「GPSケータイを活用した情報表示管理システム「LOG MAP」」

株式会社三菱総合研究所　社会システム研究本部　ITS・政策情報グループ主任研究員　目黒浩一郎

「子どものための安心安全マップ」

BigMap Project、元横浜市立中和田南小学校校外委員会　小山浩子

飲み会「Meet the Orkneys＆交流会」：

日時

2006年11月1日（水） 　17時半～20時（受付開始17時00分）

会場

横浜赤レンガ倉庫２号館　３階　BEER NEXT

・横浜情報文化センター　情文ホールより　徒歩約6分

・みなとみらい線馬車道駅又は日本大通り駅より　徒歩約6分

会費

5000円（飲食代込み；当日お支払いください）

定員

30名（先着）

プレゼンテーマ

「オープンソースGIS活用のススメ」

「世界に通用するルート検索エンジン」

「Google Mapに負けるな」

「日本最速のオープンソースジオコーダー」

地図上の位置を一意に特定する緯度経度情報というものは、本来は地図サービスの実装から独立した存在であるはずなのに、実際には各地図サービス独自の実装の中に組み込まれてしまい流通性が皆無である、というのが残念な現実です。ユーザーとしてはより正確に便利に地図情報を得たいだけなのに、実際にはコンテンツに結び付けられた特定の地図サービスを使うことを強制されてしまっているわけです。

背景にあるのは、位置情報そのものの流通を加速させていきたい、という思いです。最近カーナビと書籍の間などではマップコードという形での位置情報の流通も実現するようになってきました。ただその場合も、マップコードを解釈しない地図サービスとはやりとりすることができません（ALPSLAB baseもですが）。逆に住所文字列については、住所検索という形で流通性がほぼ確保されていますが、任意の位置を特定することはできません。最もネイティブな位置情報である緯度経度が、もっとインタフェースが標準化され流通が加速するようになってくれば、地図サービスはもっともっと面白いものになっていくことでしょう。

そういう問題意識があるのならば、ここは一つロカポをよろしくでございます。
ロカポについては、以前紹介させていただいたとおり、位置を一意に表す便利な仕様でございます。
DENSOのマップコードと同様、対応していなければやりとりできない...というのはその通りですが、マップコードはDENSOにじょーのー金納めなければエンコードもデコードもできないのに対し、ロカポはエンコード/デコードの仕様が公開されているので、誰でも明日から対応できます。
まさにこのような問題意識のために作られた仕様でございます。

お声掛けいただければ何時でもプレゼンに伺いますー（と書きつつ、私は行けないかも知れませんが、ロカポの開発元ロケージングの代表は必ず伺うでしょう）。
どうぞロカポをよしなにお願いします。

有限会社ロケージング　社外アドバイザー　ここギコねね　拝

gコンテンツワールドでの楽屋話では、高木先生から聞いた書けないような話がたくさんあったのですが、唯一書いても問題なさそうな話。

RDFを処理するDBとしては、Sesamiとかいろいろあるようなのですが、そんな中で数倍、十数倍の圧倒的な処理速度を誇るのが、AllegroGraphという製品だそうです。
残念ながら、オープンソースではなく有償製品なようなのですが。

元々、Allegro Common LispというLisp処理系を作っていた会社が作ったそうなのですが、LispもRDFも人工知能分野から出てきた同根とも言えるものなので、LispとRDFは相性がいいそうです。
そういうところが作ったから、むちゃくちゃ速いという話。

残念ながら、今のところGeo等の多次元データ型に対応していないため、位置情報のデータストアとして使うには、多条件検索となり速いとは言い難いそうです。
が、高木先生がトモダチのトモダチは皆トモダチくらいのアレで中の人から聞いた情報によると、多次元データを効率よく格納するインデックスの構造は既に開発済みなので、後は実装を待つのみという状況だそう。
そうすれば、位置情報セマンティックを扱う基盤としても、有力な選択肢となりそうです。

こちらで告知したgコンテンツワールド2006のパネルディスカッションのパネラー、やって参りました。
いやあ、「私以外は」皆さんすごい人ばかりで圧巻されてしまいました。
私はというと、途中はともかく、一応事前に話をまとめてきたはずの出だしの自己紹介＆問題提起がグダグダな感じだったのが悔やまれるところです。
やっぱりカチッとしたこと言うなら徹底的に練習、そうじゃないなら大筋だけ決めて後は流れに任せた方がよかった感じですね。
中途半端は一番ダメと。

まあ全体的な論調としてはやはりオープンがいいよね、というところで全員意見は一致なのですが、ただオープンの指すものが短い時間の中であいまいなまま終わってしまった感があって、オープンソースもオープンな仕様もオープンな標準も一緒くたな感じで終わっていたのが惜しまれる感じです。
パネルディスカッションの場ではそこまで突っ込めなかったのですが、裏で控え室で話している限りでは、「オープン」の言葉で指すものによってはパネラー毎に温度差があるような部分もあったので、その辺をもうちょっと掘り下げられればよかったかなという気がします。

---- 追記1 ----
このパネルディスカッションをさらに掘り下げる続きのセッションが、来年3月に同じく青山TEPIAで行われるとのことです。

私はというと、

• Mobile2.0的な概念を説明して、時間や位置といったコンテクストを扱えるデバイスとしてのケータイWebに起こっている革命の中で、gコンテンツ的なものに関する需要が高まっていますよ
• しかしながら、Web2.0におけるGoogle Mapsのような安価（無料）で簡易な破壊的なインパクトのある地図ソリューションがケータイの世界ではまだ出てきていないので、ケータイWebの世界ではまだまだgコンテンツの作成はコストの高いものになると言う問題は残っていますよ
• Google Mapsなんかは、標準でない独自のAPIで新たな囲い込みを図ろうとしていることは明々白々なわけですが、一方で地図をオープン化して位置情報コンテンツの作成コストを大幅に下げたというそれまでの囲い込み状況を破壊したと言う一面もあるわけで、オープンか囲い込みによる寡占かというのは視点の違いもありますよ
• その意味では、いきなり全てをオープンに、というのも中々難しい以上、前時代の寡占状況を破壊するために新しい寡占状況を利用すると言うのも必要悪的にあるわけで、ケータイの世界でgコンテンツを発展させるには、Google Maps的な安価で簡易でキャリア横断的な破壊的ソリューションが、一時的な寡占を新たに生む事になったとしても必要ですよ

的な話をしました。
伝わったかは不明ですが。

パネルディスカッションの場自体も面白かったのですが、裏の控え室での会話や議論も中々面白いものでした。
ユビキタスネットワーキング研究所の高木先生の、私のミク凸事件に勝るとも勝っている「G凸」事件の武勇伝とか、ご本人が明らかにしてないので詳しくは書けないけど、面白い話がたくさん聞けました。
また、高木先生とギークの暴走と言うか、Web2.0といいつつ今のそれはギークが新たなロックイン状況を作っているに等しい状況、そうではなくもっと一般ユーザが意識せず使えるものにしなければ、といった視点を共有できたのは嬉しかったです。
しかしその高木先生とつるんでセマンティックWeb等の技術を使いこなしたソリューションを開発しまくり、先生の「G凸」にも同道したと聞くインディゴさんという会社はおもしろいですねえ。

---- 追記2 -----
そうそう、森さんのブログでも告知されていますが、OSGeo財団の日本支部がこのgコンテンツワールドを手始めとして発足しました。
発起人を公募してるとは気付いてなかったので発起人には名を連ねられなかったのですが、本日私も参加を表明してきました。
とはいえ、私が何をできるのかはイマイチ不明ですが...。
予定が合えば展示会の立ちんぼ...くらいしかできそうにないな...。

以下の下りを見て思わず作ってしまったのが→。

ここギコ！: 死ぬ死ぬ詐欺に募金した

もしかして本当に詐欺ならネットパワーの勝利だが、もしこれがネットの暴走によるデマの拡大再生産で、一人の命が失われるとしたら悲しすぎる。

記事を書こうというトリガまでかけてしまった自分の記述に対して無責任かもしれず申し訳ないのだけど、正直ここの部分、どう表現したものか悩んだ挙句、いい表現が見つからずもういいやと勢いで書いたので、そこまで正確な本心ではない。
マジで「さくらちゃん」が死んで悲しいか？と聞かれれば、確かにその話を聞けば悲しいと言う気持ちが喚起されるだろうが、多分6.5秒くらいで忘れるだろう。

俺が「バランス感覚」として書きたかったのは、人の生き死にに関係なく、運悪くネットデマに巻き込まれた可能性のある運動が、そのために同種の普通の活動が得られたであろう支援を受けられず苦戦しているかもしれないのに対し、ネットデマの怖さを知るものとしての立場から支援を加えておこうか（とはいえデマではなく事実な可能性もあるので、万一そうであってもダメージを受けない程度に）という、ネットデマ被害に対して支援の釣り合いを取るという意味のバランス感覚であって、
断じて弾さんが「ねねさんのおっしゃる「バランス感覚」」と書かれているような、人の命の軽重、誰を生かして誰を死なせるかと言うような形での「バランス感覚」ではない。
大事な部分の表現で手を抜いたために、ミスリーディングな記事となっていて申し訳ない。

とは書きつつも、一方で弾さんの記事の内容にも大いに違和感を覚える。

集めた寄付で助かったかも知れない命がもっと多いという可能性は考えられないのか。

実際そうだろう。
「さくらちゃん」とやらを一人助けられる金を、アフリカの難民支援に回せば、何百人何千人の命が救えるかもしれない。
だが、本当に「さくらちゃん募金」がなければ、彼らを助けられたのか？「さくらちゃん募金」に回ったはずのお金は、アフリカに渡ったのだろうか？
そうじゃないだろう。
少なくともうちで言えば、「さくらちゃん募金」に募金しなければ、そのお金は近所のコンビニで息子にボウケンジャーのラムネ菓子を買ってやる金に化けていて、菓子のおまけのゴーゴービーグルの数が増えて、合体後の巨大ロボが「ダイボウケン」から「スーパーダイボウケン」にグレードアップしていた、というだけのことだ。
どのように「募金しよう」と言う気持ちがトリガされ、どのようにその金をその事象に還流できるか、という点を抜きにして数の話をしたって、机上の空論になるだけだ。

そもそも救える命の数でいうならば、何か募金しようと思っているとして、その金をアフリカの食糧援助に回すのがいいのか、ワクチン援助に回すのがいいのか、或いはアフリカじゃなくてカンボジア地雷除去に回すのがいいのか、ジャワ島震災支援に回すのがいいのか、どこに回すのが救える命の数が多くなるのか、明確に答えられる人がいるのだろうか。
発展途上国の教育環境改善に募金するのは、救える命の数がゼロだから悪なのか。
いちいち募金をする際に、いちいちそんなことを考えて、計算して募金しなければいけないのか。
そうではあるまい。
人はこの世で起きている全ての事象に対して無限責任を負っているわけではないのだから（哲学的なレベルでは、個人的には人は無限責任を原罪として負うものだと考えているけど、それはそれとしてそんなこと実際の生活で追求してたら暮らしていけない）、自分の行動を全世界の中で最適化する責任を負っているわけではないだろう。
たまたま自分が生きている経路の上で、ある活動に出会い、その活動に何らかの形でトリガされたら、それに対して募金する、それでいいんじゃないのか？

弾さんの書きようだと、飽くまで金を「出す側」の心理について論じていて、かつその心理をトリガする事象と還流の経路について問題視していない以上、究極には弾さんの愛娘が病気になってそれに対する医療費を出す、というような当たり前の場合にさえ、

100万ドルを超える金額を、時計を0.5秒送らせるためだけに投じるのは善なのだろうか。

というような結論すら導き出せる。
いやもっと極端にいうと、トリガについて論じていない以上、何故今この時、この瞬間、あなたは募金していないのか？というような話にすら行き着きかねない。
一体どこまで、俺たちはこの世の事象に対して責任を負わなきゃならないんだ？というような、青少年の青臭い悩みのような話になってしまう。

というわけで、「その募金が他のことに...」という議論は、一見リアリストの主張のように見えつつも、私から見ればあまりにナイーブな主張のように思える。

善意の値段 -404 Blog Not Found-

ケータイで朝夕通勤の際にはニュー速＋見てその日の情報収集してる人なので、2ちゃんねるで炎上してるのは知ってたけど、Blogosphereでも盛り上がっていたのね、弾さんとこの記事にも取り上げられるくらい。
別に弾さんの記事を受けての内容ではないのだけれども。

結論から書くと、俺はこの募金に募金した。
普通ならこの手のに募金しない、今まで○○ちゃんを救う会とかスルーし続けてきた俺なんだけど、今回だけ募金した理由は、2ちゃんねるで炎上したから。
別に詐欺じゃないと確信できたわけではない。
もしかするとマジで詐欺かもしれないので、詐欺だと判ってもショックにならないレベルの、本当に最低限の額しか募金していない。

なんで2ちゃんねるで炎上すると募金するのか？というと、俺なりの経験に基づいたバランス感覚がある。
俺はネット上での世論というのが、すごいパワーを持っているのは知っている。
須賀川の柔道部リンチ事件とか、栃木リンチ事件なんかを追及するネットパワーはすごいな、社会を変え得るパワーだと言うのは実感している。
だが、残念ながらその方向性が必ずしも正しい方向に向くわけではない、という事も知っている。
（念のため、ここで書く正しい方向とは、考え方とかの問題ではないので一応。考え方の正しい正しくないは思想信条の自由があるのでそんなもんは方向づけられないが、ここで書いてるのは最低限事実と異なるデマは流さないとかそういう方向。）
ネット上で問題が炎上した初期なんかに、デマに近いようなことなんかが流されたのが一人歩きしてしまうと、それがいろんなところに転載され、それが新しいソースとなって、という経路が繰り返され、もうあたかも事実のようになってしまうケースがある、というのを知っている。

俺が10年近く前、ちょっと足を突っ込んだ社会問題でも、そういうケースが多々あったので、その怖さを人一倍知っているつもりだ。
一応書いておくと、その社会問題に足を突っ込んで論じていたからと言って、意見の違いによる対立は俺は全然OKで受け入れてきた。
ある程度同じ冷静な事実認定の上で、しかし考え方の違いで対立するような人を、論敵ではあるけれども俺は尊敬する。
実際、その足を突っ込んでいた社会問題でも、尊敬できる論敵は何人もいたし、このブログの右下でリンク張っている友人・知人ブログのリンクの一つもかつての論敵の一人だし、マイミクでもかつての論敵が複数人いる。
怖いのは敵味方を問わず、デマみたいな情報を平気で垂れ流して、さらに仲間内で拡大再生産するような連中だ。
そういう連中が議論に入ってくると、何を冷静に事実認定してそれに対してどう考えるか、という議論ではなく、何を事実だと信じるかの信仰告白による争いになるので、決して結論など出るはずもなく、罵りあいの永久ループになってしまう。
そんな状況になってしまった社会問題のネット上での議論を正常化させる（できっこない）のに付き合って生活破綻させるほど、俺もその社会問題に関わる義理も時間もなかったので、俺はその社会問題を議論することから撤退したけど、そんな経験を持っているので、ネット上でデマが拡大再生産されることの怖さは痛いほど知っているつもり。

翻って、今回の死ぬ死ぬ詐欺（と言われているもの）。
もしかして本当に詐欺ならネットパワーの勝利だが、もしこれがネットの暴走によるデマの拡大再生産で、一人の命が失われるとしたら悲しすぎる。
これまでの他の募金は可哀想だとは思いつつも、だからってまあ俺が募金しなくても世の中にあふれてるお人よしどもが募金しまくるだろうから目標額には達するさ、と思って一度も募金した事などないのだけど、今回このバッシングが原因で募金が集まりにくくなってるとして、それがもしデマだった場合、ネット上のデマの怖さを知ってる俺が募金してバランスとらなきゃだめだろう、という思いで募金した。
もちろん、先にも書いたとおり詐欺の可能性も否定できないので、自分がだまされたと知っても痛くないレベルでだけど。

それが、もし詐欺だったら馬鹿にされるかもしれないが、俺なりのバランス感覚。

以前、Windows Media Player上で携帯動画が再生できなくなって以来、いろいろ試してみましたが有効な方法がなく、子供の携帯動画や写真を整理しないまま1年半くらいが過ぎました。
ローカルでの処理だけでなく、写真・動画共有サイトでflv化する事など色々手を尽くしましたが、最近の携帯動画は10分近く撮れたりもするのでいっぱいいっぱい撮ったファイルだと、サイトのアップロードサイズ上限にひっかかったりして、完璧なソリューションと言うものがどうしても見つからず。
ほとほと困り果てていました。

が、今日、すばらしいソフトを見つけました。

River Past Video Cleaner

このソフト、試用状態で試してみましたが、携帯動画形式（3gpp2）を見事にWindows Media Player対応画像に変換してくれます。
他の同種のソフトだと画像が著しく劣化したり、音声がコピーできず無音ムービーになってしまったりしていたのですが、こいつだとほとんど画質の劣化も見られません。
おまけに、以前の携帯動画仕様であるAMCファイルにも対応しているようです。
一発で気に入って、購入し試用状態を解除しました。
（というか、試用状態では会社のロゴが入ってしまうので、動作確認にしか使えません）

同様に携帯動画の管理に困っている方がおられましたら、ぜひ使ってみてください。

Amazon EC2（とは何か、についてはこちら）を色々試しているのですが、試した途中の状態のプライベートイメージをいくつも登録しては削除していると、少々困った事が生じます。

登録したイメージを削除するには、イメージのID番号を指定して

    >ec2-deregister ami-61a54008
    IMAGE ami-61a54008

のようにコマンドを実行すればよいのですが、こうして削除されたイメージ、何故かイメージの一覧コマンドを実行した結果の一覧上からは消えず、「deregistered」というステータスで残ってしまいます。
こんな感じ↓↓↓↓

    >ec2-describe-images
    IMAGE   ami-16ab4e7f    xampp/image.manifest    158999813159    available       private
    IMAGE   ami-22ab4e4b    xampp/image.manifest    158999813159    deregistered    private
    ....

これ、いろいろ試せば試すほど山ほどゴミが増えてくるので鬱陶しくて仕方がない。
時間がたてば消えるというものでもない感じ。

そこで、これに関する対処が何かないか調べてみたところ、EC2の開発者情報サイトに情報がありました。 

Piping the output of ec2-describe-images through "grep -v deregistered" (on a linux machine) will filter out deregistered AMIs.

今は仕様なのでgrepでフィルタアウトしてくれと。
いや、実にプリミティブな解法で素敵です。
とりあえずWindowsはgrepがないので　この辺から取ってきて、あといちいちgrepと打ってられないのでバッチファイルにしました。

ついでながらいくつか試してみて判った拾遺。
EC2でのオリジナルのイメージを登録する場合、

1. EC2インスタンス上で、現在のインスタンスをイメージ化するコマンドを実行（ec2-bundle-vol）
2. EC2インスタンス上で、作成したイメージに名前をつけてS3にアップロードするコマンドを実行（ec2-upload-bundle）
3. ローカルで、名前をつけてS3にアップロードされたイメージを、EC2のイメージ一覧に登録（ec2-register）

という手順を経るわけですが、まず2.の手順で、S3へのイメージアップロードは同じ名前でいくらでも上書きできます。
EC2のコマンドには、S3上にアップロードされたイメージを消すコマンド（ec2-delete-bundle）もありますが、これを特に実行しなくとも、同じ名前でいくらでも上書きできるようです。

また、3.のコマンドにおいて、S3にアップロードされたイメージをEC2で利用できるように登録するわけですが、このコマンドの実行時点で、イメージはS3以外のどこか別の場所に登録されるようです。
要するに、S3は1.の手順と3.の手順の仲介役にしか利用されておらず、EC2で利用できるイメージの保存場所としては利用されていないという事です。
なので、

• ある名前でS3にアップロードしたイメージをEC2に登録後、同じ名前でS3に新しいイメージをアップロードしても、EC2に登録されたイメージは以前のままです。
• 同じ名前でS3にアップロードしたイメージを、いくらでもEC2に登録できます。
• EC2にイメージ登録後、S3上でイメージを削除しても、EC2ではそのまま有効なイメージのまま残ります。

というような状況になります。

以前も報告したとおり、Apache2.2ではmod_fastcgiがmakeできません。
その対策のパッチを先のエントリで取り上げていたのですが、今回改めてApache2.2に適用する事があったので確かめてみるとリンク先がNot foundに。

そこで改めて探したところ、ここにパッチがありました。
前のは消えてるので以前のパッチと一緒かどうか判りませんが、紹介しておきます。

というか、またリンク先が消えるとアレなので、うちからもDLできるようにしておきます。

  $ cd mod_fastcgi-2.4.2
  $ patch -p1 < fastcgi-apache22-patch
  $ cp Makefile.AP2 Makefile
  $ make
  $ su -c "make install"

で適用してください。

先のエントリでレポートしたAmazon EC2、ちょっと心配していた事があった。

• インスタンスを止めると、その時の状況は保存されない
• インスタンスの状況をイメージとして保存していても、再度イメージをインスタンスにすると、割り当てられるIPアドレス等は変わってくる

といったあたりに対し、俺みたいな能無しハッカーはよくミスで激重不可の処理を走らせちゃって、サーバをリブートさせるしか対策なし、というような状況をよく作ってしまうんだけど、リブートするたびに上のようにインスタンスの状況が破棄されたり、IPが変わったりしたら使えないよなあと思って心配してた。

というわけで試してみると、別にコマンドでリブートかけてもインスタンスが落ちるようなことはなく、ファイル等のリブート前の状況は保存されるし、IPアドレスも保持される事が判った。
ひとまず安心。

があるらしいのでソッコーエントリした。
どうも、告知から1時間半しないうちに定員〆切になったみたい。
業務中業務に関係ないWebとか見倒してるのバレバレだな。

Shibuya.pmのイベントは出た事がないので楽しみ。
日曜プログラマとはいえ技術屋としてはどの話題も楽しみですが、特に興味あるのはこの2つ。

• Amazon Web Services, S3 and EC2 (Emerson Mills)
• 自然文書から日本の住所を頑張って抽出 (大沢和宏)

EC2はつい先のエントリでも取り上げたけれど、しょせんサービスを起動してみただけに終わってるので、どううまく使いこなしていくのかノウハウを知りたい。

自然文書住所解析はYappoさんこと大沢さんのだけど、こちらのエントリでその辺開発している人がいるよ、と書いたらほぼ時を同じくしてカミングアウトしてくださった。
自然文書からの住所解析というと、私も考えていたけど市区町村でループさせマッチさせて、マッチすると下位の町丁目大字等でさらにループする、というのしか考えてなかったので、Yappoさんのアプローチはまさに目ウロコ。
その後どう発展したのか、ぜひ聞きたい。

と、参加を非常に楽しみにしているのですが、実は実際に参加できるかどうかは見切り発車。
当日、都内の客先で打合せが入る可能性が非常に高く、その場合参加できるので一応エントリしたのですが、万一そちらが流れた場合、職場は横浜戸塚なので参加が非常に困難。
よって、キャンセルする場合あり、その場合は誰かにお譲りします。
来週半ばには判り、キャンセルの場合譲りますの旨の記事を書くので、今回行きたかったけどエントリできなかったと言う人は、本ブログに注目のこと。

たたみラボで紹介されていたAmazon Webサービスの1つEC2（Amazon Elastic Compute Cloud：論理server）、1instance $0.10/hourだと、1ヶ月で$72.00、普通の専用サーバレンタルの最安のものと同程度か安いくらい、それで障害に対して安心なサーバとなるとこれはいいのでは？と思い試してみました。

試す前に準備しておく事は6つ。

1. Amazon Webサービスのアカウントを取得します。
   アカウントID（数字12桁） 、アクセスID（数字/英大文字20桁）、アクセス秘密ID（英数字/記号40桁）が作成されるので記録しておきます。
2. X.509証明書（cert-hogehoge.pem）とX.509秘密鍵（pk-hogehoge.pem）を作成し、ダウンロードしパスを張りやすいところに置いておきます。
3. Java 1.5以上の実行環境を用意します。
4. Javaのコマンドラインツールをダウンロード・セットアップし、環境変数（実行パス・X.509証明書/秘密鍵へのパス） を設定します。
5. コマンドラインで「ec2-add-keypair」 コマンドを実行し、SSHアクセスのための秘密鍵を発行し、保存しておきます。
   この時、コマンドラインシェル上でカット＆ペーストして改行がCRLFになっているとうまく動かないので、改行をLFで保存すること（ちょっとハマった）。
6. SSHアクセスにWindowsのputtyを使う場合は、さらに5.で作った秘密鍵を、puttygenを使ってputty形式に加工します。

以上でEC2を走らせる準備が整います。

以下、ローカルWindows上でのコマンドライン実行を「>」、EC2インスタンス上での実行を「#」として示します。
また、本当は1行の出力を2行に折りたたんでいるところは、インデントを深くして示します。 

まず、実行可能なイメージのリストをリストアップします。

    >ec2-describe-images
    IMAGE   ami-5bae4b32    ec2-public-images/getting-started.manifest
        206029621532    available       public
    IMAGE   ami-68ae4b01    ec2-public-images/fedora-core4-base.manifest
        206029621532    available       public
    IMAGE   ami-69ae4b00    ec2-public-images/fedora-core4-apache-mysql.manifest
        206029621532    available       public
    IMAGE   ami-6dae4b04    ec2-public-images/fedora-core4-apache.manifest
        206029621532    available       public
    IMAGE   ami-6fae4b06    ec2-public-images/fedora-core4-mysql.manifest
        206029621532    available       public

自分独自のイメージを作っていない当初は上記のイメージが公開されているようです。
とりあえず、ひとつのイメージを指定してインスタンスを実行してみましょう。

    >ec2-run-instances ami-68ae4b01 -k gsg-keypair
    RESERVATION     r-90d336f9      158999813159    default
    INSTANCE        i-0484606d      ami-68ae4b01    pending gsg-keypair

これでインスタンスの実行が準備されます。
実際に起動するまでには結構な時間がかかります（少なくとも数分レベル）が、全てのインスタンスの現在の起動状況などをチェックするには以下のコマンドを使います。
起動途中の場合は「... pending ...」のメッセージが返るので、起動完了後の実行結果を示します。

    >ec2-describe-instances
    RESERVATION     r-90d336f9      158999813159    default
    INSTANCE        i-0484606d      ami-68ae4b01
        domU-12-31-33-00-04-76.usma1.compute.amazonaws.com      running gsg-keypair

続いて、インスタンスの外部からアクセス可能なポートを指定します（これは毎回やる必要はないようです）。

    >ec2-authorize default -p 22
    GROUP           default
    PERMISSION     default  ALLOWS  tcp     22      22      FROM    CIDR   0.0.0.0/0
    >ec2-authorize default -p 80
    GROUP           default
    PERMISSION     default  ALLOWS  tcp     80      80      FROM    CIDR   0.0.0.0/0

以上の実行後、上記の緑色で示したドメインに、事前準備5.及び6.で作成した秘密鍵を用いてSSHでアクセスすると、EC2のインスタンス実行環境にアクセスできます。

これで、普通のレンタルサーバのように自由にツールインストールもシステム開発も自由自在です。
私はとりあえず、XAMPPをインストールして遊んでみました。
ただし注意すべき点として、レンタルサーバと違い飽くまでイメージを展開したインスタンスとして実行されているだけなので、インスタンスを止めるまでは状態は保持されますが、当然ながらインスタンスを止めてしまうと加えた変更は全て破棄されてしまいます。

加えた変更も併せ再現可能な状況にしようと思えば、現在のインスタンスの状況をイメージ化してS3（Amazon Simple Storage Service：Amazon Webサービスのストレージサービス）上にアップロードし、イメージとして登録しなければなりません。
これを行うには、まずX.509証明書（cert-hogehoge.pem）とX.509秘密鍵（pk-hogehoge.pem）を、SCP等でイメージ化したいインスタンスのrootフォルダに転送しなければなりません。
その上で、インスタンス側で

    # ec2-bundle-vol -d /mnt -k ~root/pk-hogehoge.pem -u アカウントID -s 1536
    Copying / into the image file /mnt/image.img...
    Excluding:
         sys
         dev/shm
         proc
         dev/pts
         proc/sys/fs/binfmt_misc
         dev
         media
         mnt
         proc
         sys
         tmp/image.img
         mnt/img-mnt
    1+0 records in
    1+0 records out
    mke2fs 1.38 (30-Jun-2005)
    warning: 256 blocks unused.

    Splitting /mnt/image.gz.crypt...
    Created image.part.00
    Created image.part.01
    Created image.part.02
    Created image.part.03
    ...
    Created image.part.22
    Created image.part.23
    Generating digests for each part...
    Digests generated.
    Creating bundle manifest...
    Bundle Volume complete.

のようにすれば、インスタンス内にイメージが作成されます。
これ、むちゃくちゃ時間がかかります。「Create image.part.00」までのところで、普通に十数分待っている間には表示されませんでした。
待ちきれなくて、夜の1時から始めたのですが、寝てしまいまして、4時に目を覚ました時には完了していた、と言う状況なので、正確な実行時間はわかりませんでしたが...。

その後、インスタンス側からこのイメージをS3にアップロードします。
下の記述中、紫色のところの名称は、イメージを識別するための名称なので、好きな文字列で構いません。私はxamppとしました。

    # ec2-upload-bundle -b xampp -m /mnt/image.manifest -a アクセスID -s アクセス秘密ID
    Encrypting bundle manifest...
    Completed encryption.
    Uploading encrypted manifest...
    Uploaded encrypted manifest to https://s3.amazonaws.com/xampp/image.manifest.
    Uploading bundled AMI parts to https://s3.amazonaws.com/xampp/image...
    Uploaded 00 to https://s3.amazonaws.com/xampp/00.
    Uploaded 01 to https://s3.amazonaws.com/xampp/01.
    Uploaded 02 to https://s3.amazonaws.com/xampp/02.
    Uploaded 03 to https://s3.amazonaws.com/xampp/03.
    ...
    Uploaded 23 to https://s3.amazonaws.com/xampp/23.
    Uploaded 24 to https://s3.amazonaws.com/xampp/24.
    Upload Bundle complete.

これでS3へのイメージアップロードが終わりました。
今度はこのイメージを一覧に登録します。処理をローカルのコマンドラインに戻して、

    >ec2-register xampp/image.manifest
    IMAGE   ami-22ab4e4b

これで、インスタンス実行可能なイメージの一覧にオリジナルのイメージが加わりました。

    >ec2-describe-images
    IMAGE   ami-22ab4e4b    xampp/image.manifest    158999813159    available       private
    IMAGE   ami-5bae4b32    ec2-public-images/getting-started.manifest
        206029621532    available       public
    IMAGE   ami-68ae4b01    ec2-public-images/fedora-core4-base.manifest
        206029621532    available       public
    IMAGE   ami-69ae4b00    ec2-public-images/fedora-core4-apache-mysql.manifest
        206029621532    available       public
    IMAGE   ami-6dae4b04    ec2-public-images/fedora-core4-apache.manifest
        206029621532    available       public
    IMAGE   ami-6fae4b06    ec2-public-images/fedora-core4-mysql.manifest
        206029621532    available       public

のように一覧にも出てきますし、

    >ec2-run-instances ami-22ab4e4b
    RESERVATION     r-71d23718      158999813159    default
    INSTANCE        i-da8460b3      ami-22ab4e4b            pending

のように実行すれば、xamppインストール済みのインスタンスを実行することができます。
実際の運用では、cronか何かで定期的にインスタンス側でのイメージを作成してS3にアップロードしておき、適宜ローカル側でイメージ登録する形で、運用環境をバックアップするようなイメージになるのかなと。

さて、最後にはインスタンスを止めないと、延々と課金され続けてしまいます。
システム開発してサービスを走らせているならいいですが、今回は試してみただけなのできちんと止めましょう。

    >ec2-terminate-instances i-0484606d
    INSTANCE        i-0484606d      running shutting-down

これでインスタンスも止まり、課金も止まります。

これだけ試してみてかかった利用費ですが、インスタンスの使用量が$0.40、これは4時間ほど走らせていたわけなので妥当なのですが、ネットワークの転送料金が$0.02かかっていたのにはちょっと驚きました。
ネットワークを使ったのは、XAMPPのパッケージのダウンロードと、一度XAMPPを起動させてみて、XAMPPのWeb画面が出ているのをブラウザで確認しただけなのですが、それで$0.02かかるのはちょっと思ったよりかかるな？という感じがしました。
高アクセスのWebサイトとか運営すれば、途端にネットワーク費が跳ね上がる印象が...私は転送量で課金されるサーバを使ったことがないので、ちょっと相場感が判らないのですが。

以上のような感じで、準備手順はちょっとハードル高いですが、その後は割りと簡単に、インスタンスを落とすと変更内容全部消えちゃうのさえ気をつけておけば、普通のレンタルサーバと同じような感じで使えます。
今後のサーバソリューションとして、選択肢の一つにはなると思います。

ご参考になれば。 

Firefox使って作業してたら、突然Googleの検索結果がタイトルしか表示されなくなった。
不便この上ない。

最初UserAgent Switcherで携帯電話のUAにしていたせいかなと思って、元に戻したが、変化なし。
Cookieでも食わされてんのか？と思ってそれもクリアしたが戻らない。

同じ検索を、IEでやってみるとちゃんと内容も出てくる。

でも、IEでちゃんと概要が出ているURLをそのままコピペしてFirefoxのアドレスバーに突っ込んでも、タイトルしか検索されない。

なんで？
これじゃまったくもって使えねーYO！

誰か、元に戻す方法ご存知の方おられますか？

---- 追記（解決） ----

okamOTOさんがコメントに書いて下さったとおり、GooglePediaを拡張から外すことで元に戻りました！
情報ありがとうございました！

いやあ、それまで全く問題なく動いてたし拡張のバージョンアップとかもしたわけじゃないし、まさか拡張が原因だったとは思いませんでした。
てっきりGoogle側のなんか仕様変更とかの問題かと...。

gコンテンツ流通推進協議会の主催する「gコンテンツワールド2006」というのが、10月16，17日に青山TEPIAというところであるらしいです（らしいというのは、ネット上に情報ないので...公開されたようです->http://www.g-contents.jp/2006/0index.htm）。
その中で16日の午後16時35分から1時間、「Web2.0とWhere2.0とｇコンテンツ（仮）」というタイトルでパネルディスカッションが予定されているそうです。
んで、推薦を受けてそのモデレータの役が最初私のところに話が来ました。

んでもモデレータなんてやったことがないので、「んだども『もでれーたー』なんてオラやったことねーしーできねーべ。まだ『ぱねらー』なれば、思うたことしゃべればええだけだでやれんこともないかもしれんけんど（どこの言葉だ）」とかなんとか逃げ口上うってたら、マジでパネラーの方になってしまいました。
「まだパネラーなら出来る」と言ってしまった手前仕方ないですが、マジでええんかいな...俺実績も肩書きもないですよ？という感じです。
お相手は

• ユビキタスネットワーキング研究所の高木悟先生
• 大阪市大のラガワン先生
• 株式会社オークニーの森亮社長
• 株式会社インディゴの松澤有三氏
•  （財）日本情報処理開発協会　坂下哲也氏（モデレータ） 

以上なのかな？他にもいるのかは不明。
というようなそうそうたるメンバー。
俺一人「えー、ここギコのねねです」誰じゃそら？という感じ。

まあ、まともな話が聞きたいという方は来られる価値はないでしょうが（と書いちゃうと他のパネラーの方に失礼か）、ここギコねねの失態を見て後で思う存分「DISカッションしてやるぜ！」というような性根の腐った方々は、お手数ながら青山まで足を運んでくだされ。

---- 追記 ----

確認しましたが、当イベント、参加は申し込み制のようですね。
来られる方は事前登録を申請してください。

えーと、飽くまで弾さんへのツッコミではないです。
ゲーム理論への正しい理解は、明らかに数学得意な弾さんの方が正しいに決まっているので。
ただその社会への適用にちょっと生活者的立場というのか、心理的立場というのか、非数学的な人間視点からの感じた事をつらつらと。
数学的な部分で間違ってたら、遠慮なく突っ込んでくらはい。

友人のジレンマ -404 Blog Not Found-

末永くつきあいがある場合、相手が好意を示したら好意を、悪意を示したら悪意を示すという戦略が有効だ。つきあいが永遠に続く場合、これを繰り返して行くと誰も悪意で得する事がなくなるので、好意がデフォルトになる。これが有名な「しっぺ返し戦略」で、囚人のジレンマの最適解の一つでもあり、medtoolzさん自身もメモしている通りである。

ところが、つきあいがこれで最後という場合、もう後のことを考える必要はないのだから、悪意が最大の利得を生むのであれば、遠慮なくそうすべきだ。

いろいろ書いたが、結局のところ、最初に「世の中は囚人のジレンマモデルだけじゃないよ」とか書いてるにも関わらず、後の論では自分も囚人のジレンマモデルを中心に話しているわけで。
我ながらいい加減なもんだな。

---- 追記・PS -----

弾さーん、コマネチ大学の「ゲーム理論」の回、どうしてじゃんけんの出す回数があの回答になるのか教えてください。
「美しき数学の時間」の部分だけビデオで撮れてませんでした...。 

どんなことすればいいのか教えてください。
ノウハウの書かれてるWebページとか、本とかあったらそれも教えていただけるとありがたかったり。

パネルディスカッション自体は見たことありますが、主役じゃないモデレータのやってることなんて気にも留めず流してきたので全くイメージが沸かず。
なんか、パネルディスカッションの記録された動画とかあっても嬉しいなあ。
YouTubeとか検索してみるか。

基本的にムラ社会の住人なので、どんな形であれDISられると最初は非常にショックを受ける。
誰からかとか言葉の強さの程度にもよるので数分の時もあれば半日とかの時もあるけど、どんよりと鬱な気分になる。

その後、立ち直るとDISりの分析に入る。
文句の付けようもなく、恐れ入って受け止めるしかないような類のDISりに対しては深く自分を見直して、2度と同じDISりを受けることのないよう気をつけようと胸に刻む。
誤解に基づいてDISられていると思うときは、その誤解を解くために言葉を継ぐ。

でも、そのようなタイプのDISりと違って、鬱の後に反動で私を高揚させてくれるタイプのDISりもある。
逆にツッコミどころ満載で、逆DISする隙だらけのDISりだった場合だ。

こういうタイプのDISに出会った時は、本当に心が浮き浮きする。
さてどうやってDISり返してやろうか、こう書いたらこう返してくるだろうからこうもう一発書いてやるか、もしこう逃げたらこう追撃するか、みたいな事を考え抜いていると、普段のストレスが発散されて本当にカタルシスを感じる。
大体こういう事を考える時は、熱い反論を返そうとはそもそも思ってない。
さあどうやって罠かけておちょくり抜いてやろうかという方向で考えているので、飽きる事がない。
喜劇のシナリオ考えてるようなもんである。

とはいえ、実際のDISりは、ここまで厳密に3パターンに分かれるわけじゃない。
上に書いたくらいまでやるとその後人間関係修復困難になるので、その後も付き合いたいと思う人には単に面白がりだけでは対応できないし、またお説ごもっとも、と思うようなDISりでも、だからってそういう書き方はしなくていいじゃんて感じで軽くネコパンチ交えてみるとか、その程度のものが大抵だ。

だが今日、久しぶりに人間関係どうでもいいのでとことんやったろかい、というような釣りDISりが来た。
こうなればもう気分は最高潮だ。
まるで恋人にでも出会ったような気分である。
今日は子供を連れて外に遊びに出ていたのだが、その間も時々子供の相手も上の空で、こう書いちゃろかいああ書いちゃろかい、とうきうきしてシミュレーション（妄想ともいう）しまくりである。

そして帰宅。
暖めてきた逆DISりシナリオを実行せんと、PCに向かってみると！

DISりが消えてる...。

せっかく考え抜いた逆DISシナリオがパアである。
なんか放心状態、まさに恋人に逃げられた気分。
DISられてたのが消えるというのも、中々寂しいものなのだなあ、と感じた今日だった。