大学時代のサークルの後輩で、心理学専攻している奴がいた。
すごい分析力持つ優秀な奴で、今も研究機関で臨床心理士として活躍してる奴なんだけど、ひらめくと言う感覚が判らない奴だったようで、「先輩、ひらめくってどういう事なんですか」と聞かれたことがある。
その時は俺もよく判ってなくて、なんか頭にパッと思いつくんだとか、電気が走るようなとか、非論理的な現象であるかのように非論理的な説明しかできなくてモゴモゴしてたんだけど。
でも、一応ロジックに生きてる？つもりの人間であるにも関わらず、ひらめきは明らかに大きな影響力をもって私を駆動しているわけなので、これが説明できないと私の頭は非論理的な思考活動をしているという結論になり、どうも嫌だ。
というわけで、ひらめき、或いはひらめきとまでいうと大層だけどより日常的なものにまで一般化すれば、直感って何だろうなあ、とか折に触れて考えていたのだけれども。

で、最近思ったのは、直感ってのは知識のモデリング能力と、並列計算能力、それもグリッドコンピューティング的なそれよりはむしろ量子コンピュータ的な計算能力じゃないのかな、と思うようになった。

直感的な人っていうのは世の中を捉えるのに、「AならばBである」「CならばDである」といった個々の事象の因果関係を、再現性100%の点と線の集合体で捉えるというよりは、「AとBの関係はCとDの関係に似ている」 「CとBの関係はFとHの関係に似ている」と言った感じでモデル化し、100%ではないけどある程度の蓋然性をもったモデルとして把握するのじゃないかと思う。
で、物を考えるのにあたって個々の事象の線を辿っていって帰納的に思考していくのではなく、常時いろんなモデルを頭の中でパズルの噛み合うところを探すかのようにぐるぐる回していて、噛み合った瞬間に直感を得て、その後演繹的に得たモデルを精査する、という思考回路を持っているのではないだろうか。
そして、並列計算的にその噛み合いの連鎖が一気に多段連鎖して、繋がらないと思ってた点と点が一気に繋がる瞬間が、ひらめきというんじゃないかなと思う。

もしこのメカニズムが妥当であるとすれば、その思考回路って量子コンピュータ的だなあ、という気がした。
といっても、量子コンピュータとはなんぞや、ってこの本で得た程度の知識しか知らないのだけれども。

量子コンピュータ

posted with amazlet on 05.12.30

竹内 繁樹
講談社 (2005/02/18)

おすすめ度の平均:

量子コンピュータと暗号の関係を理解するには最良の本
難しいよ
量子コンピュータ入門前の入門書に良いかも！？

Amazon.co.jp で詳細を見る

といった類似性があるんじゃないかと思った。
（直感的思考の計算が遅い、というのは飽くまで俺の場合で、明らかに私は直感思考なんですが、普通に計算とかするのは正直遅いのは認めざるを得ない。モデル化してアタリをつけてから精査する形で大抵の事は普通にこなせているかむしろ人より速いくらいでいるつもりだけど、小細工の効かない単純計算だと俺の思考能力の遅い事遅い事。でも事例が一つなので、一般化するにはちょっと無理あるかもしれない。）
帰納的思考法で頭のいい人ってのは、脳というCPUのクロック数の早い人、直感的思考法で頭のいい人って言うのは、量子コンピュータでいうところの処理ビット数の多い人。
そんな感じだったりするのかなと思う。

で、人として帰納的か直感的か、といった傾向はあるけれども、一方で誰の頭にも直感的に近いような働きはあるわけで、例えば音声認識や人間の顔の判別、その他芸術的な分野における感性とかのエトセトラ。
そういった分野って、今のデジタルコンピュータで人間の脳レベルを再現するのって苦戦しているみたいだけど、私の考えが正しいとすれば、ブレークスルーには量子コンピュータ的なものの発達が必要なのかなと思った。
もちろん量子コンピュータ的なものだけではなくて、デジタルコンピュータ的な部分も必要なわけだけど、その連携、あるいは将来、必要に応じてデジタル情報演算の高クロック計算と、低クロックだけど量子ビットの重ねあわせ計算を、一つの論理素子で切り替えられるような新しい素子が開発されたりしたら、コンピュータが人間の脳を再現できるような時代もきたりするのかなと思ったりもした。

全部妄想かも知れんけど。

YADISとFOAFなんかを組み合わせれば、自サイト同士を連携させたり、また自サイト上で友人や家族にしか公開しないようなコンテンツを実現させたりして、自サイトをSNS化させることができるのはこれまで書いてきたとおり。
だけど、YADISを使ってログインするのに、今のOpenIDのように、ログインページを探すのはいちいち人間が行って、というやり方はちょっと煩雑な感じがする。
新しい友人のサイトに来るたびに、ログインページを探して...なんてのはどうにも面倒くさい。
で、ブラウザの側（firefoxアドオンとか）でユーザのYADIS IDを記憶しておいて、HTTPリクエストの側に、「X-YADIS-ID」とかの拡張ヘッダを加えてやって、このヘッダがあればサーバは自動的にログイン手順に入ると言う仕様はどうかと思った。

でも、こんなヘッダ、どこでもかしこでも撒き散らしてると、「私が今このページ見ていますー」とプライバシー撒き散らしてるのと同じことになる。
そこでまず、サーバ側が、非ログイン時のコンテンツと一緒に、このページがYADISに対応しているかどうかを示すヘッダとして、サーバのTrustRoot情報を「X-YADIS-TrustRoot」のような形で配信してやって、
ブラウザがこのヘッダを受けると、ユーザに「X-YADIS-ID」をサーバに渡してよいかの問い合わせをする（ポップアップみたいなウザい方法じゃなくて、Firefoxのライブブックマークアイコンのような、YADIS対応サイトに来るとブラウザのどこかのアイコンが活性化する、見たいな感じで）。
ここでユーザが通知を許可すれば、「X-YADIS-ID」をサーバに渡して再アクセス、という手順。
以前に訪れたページで「常に、X-YADIS-IDを通知する」を選択していたり、或いはユーザのFOAF等で友人のサイトだとわかっているところ等では、上記手順を省略して最初からX-YADIS-IDを通知します。

イメージ化するとこんな感じ。

この仕様で、友人サイト毎にいちいちログイン、とかしなくても、友人サイトを遷移していくだけで自動的に友人向けコンテンツを得る事ができるようになるはず。

問題は、いや問題じゃないんだけど、「Cookieを使ったって同じような事（友人を覚えておいて配布するコンテンツを制御すること）はできるんじゃないの？」って言われるだろうなあ、って事。
この辺はその指摘はそのとおりなんだけど、私の中では明白に違って、友人である事はCookieで覚えられても、そもそも最初に友人かどうかを判断するのに、友人サイト毎にログインフォームでログインして、っていうのは煩雑すぎて普及しないだろう、
もっと簡単に、SNSサイトの中での個人ページ移動と同レベルの感覚で、単にサイトのリンクを辿っていくだけで自動的に友人認定されるための仕様として考えているので、Cookieでできる事とは全く違うのだけれども。
でもその辺の機微は伝えにくいというか、ましてや英語では？？？って感じなので、OpenIDのMLでも提案しにくいなあというか悩んでるところ。

びっくらこいた。

Comic Mourning -404 Blog Not Found- 経由 エロ漫画家の死なぞ世界にとっては取るに足らないことだろう -浦嶋嶺至のAREA41-

私がこの世界に入る前のかがみあきら氏を筆頭に、以後もKEN川崎、はらさける、アップルトン、よしだけい、九連宝燈、ジャッキー亀山、千葉毅郎、うらべ・すう(一烈条二)、たちばなとしひろ、西崎まりの、小菅勇太郎…そして今回の刹奈さん、である。ざっと取り上げただけでもこれだけの漫画家たちが世を去っている。

太字の人しか知らんけど、まじですか...まさに同時代人やないですか。
エロ漫画だけやのうてカードゲームの絵とかも描いとったうらべすうさんとか（だけじゃないけど）、今でも絵のタッチまで思い出せるなあ。

元知人のたくま朋正さんとか、元気にしてはんのかなあ。向こうは覚えてへんやろけど。
と思ってググッたら本人のブログハケーン。
まさに大病？みたいのやってはるみたいだがご健在そうで一安心。

私が守りたい、いや残って欲しいと考えるのは「日本語空間」であり、それは「日本」と一致していなくてもかまわない。

修士修了を目前にして就職先を模索していた頃、国際交流基金にマジ行きたかった自分を思い出した。
京都の事務所にも訪問したんだけどなあ。
なんであきらめたんだったかは忘れた。今酔ってるし。

今日、ねねが
ブログに地図を貼り付けて、位置情報を集約するサービス「ちず収集」オープン(BlogPet)
とか思ってるよ。

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

年内の客先詣でが終わったと思ったら、気が抜けたのか風邪を引いたっぽい。
週末は息子が吐き気系のウィルス風邪に罹っていたので、感染ったのか。

もう頭は火照って働かないわ、関節痛は手の痛みを増幅させるわで仕事にならないので、20時には早々に会社を出る。
体調悪いのに朝コート着てくるの忘れた。アホだ。寒かった！！

家に帰って熱を測ると、37.5℃。たいした事はないが、健康ではなさそうだ。
まあお陰で早く帰れたので、テレビ付けて見るとワッキーがジャッキーチェンの物真似中。
ついその物真似番組最後まで見てしまったら、家内が「そう言えば今日、見たがってた河井継之助のドラマもあるで」と一言。
もっと早く言ってくれー。
残り1時間しかないやんけ。

でもまあ小千谷談判のシーンも八丁堀奇襲のシーンも見れたし、まあいいか。
あー頭痛てー。
貯まってる事も山積みだが、寝よ寝よ。

もう1ヶ月以上前に知りながら、忙しくて紹介し忘れてた話題。
まだあまりSBMなんかにも登録されていないみたいなので改めて紹介。

CSISシンプルジオコーディング実験(GeocodingのRESTサービス) -Digital Life Innovator-

当サイトで日本の住所のGeocodingサービスを提供するにあたりCSVアドレスマッチングサービスを利用させて頂いていました。
そのCSVアドレスマッチングサービスを提供されている東京大学空間情報科学研究センターで新たにCSISシンプルジオコーディング実験(GeocodingのRESTサービス)を始められました。

ジオコーディング環境も大分整ってきましたねー。

あとこれも1ヶ月近く前に知ったので今更ではありますが、ネタ元のDigital Life Innovatorの管理人さん、私の大学時代の大先輩でした。
偶然知ってびっくり。
学生時代から、すごいハッカーちっくなデキル人でした。 

名古屋でお元気ですかー。

WeblogUpdatePingを受けて位置情報付きRSSを収集 暇人的ブログ

これとは別にXML-RPCで更新の通知を受け RSSを収集するWeblobUpdatePingサーバを構築した。

つまり、更新Ping通知先にこのWeblobUpdatePingサーバを指定し、 RSSのタイトル、Parmalink、更新日時、descriptionの他、 Geoボキャブラリで追記された位置情報がある場合、これも収集する。

または画像linkがある場合、Exifから位置情報を読み取りこれを収集する。(現在は機能させていません)といった一連のリアルタイム位置情報収集システムを構築しました。

......

今のところUpdatePing打っているのがこのブログだけなのでショボイんですけど。

至急公開キボンヌ。

友人の作る携帯位置情報SNS「ポジタル」が、しばらく言及できずにいる間に格段にパワーアップしています。
とりあえず面白そうなものを紹介します。

１．自作プログラムへ現在位置通知

私の提案した機能だったりもするのだけど、

ポジタルで更新した現在位置を、自作のプログラム（ポジタル以外のサーバ）へ通知することができます。
携帯電話等で現在位置を更新するたびに、設定されたURIへPOSTメソッドで、緯度(lat),経度(lon),住所(postal),地図番号(mapnum),測位時刻(time)を送信します。

例）「http://hogehoge.com/hoge.cgi」を送信先URIに設定した場合、
「http: //hogehoge.com/hoge.cgi?lat=35.0.0.000&lon=135.0.0.000&postal=%BF %C0%C6%E0%C0%EE&mapnum=367618674&time=1126600855」
がPOSTメソッドで送信されます。
経度緯度は「WGS84」、測位時刻は「UNIXタイムスタンプ」、住所はURLエンコードされます。

みたいな機能が搭載されてます。紹介がかなり遅れて申し訳ない。
ポジタルにはこちらの記事にも書いたように、au限定ですが、リアルタイムで位置をトラッキングする機能もついています（WILLCOMも対応でしたっけ？）。
ということは、上の機能を使って取り合えば、自分で位置情報取得部分を実装しなくても、自分の居場所をトラッキングするWebアプリを実装できるわけです。
アイデア次第でいろいろ面白い事ができると思います。

２．近くのユーザの検索が可能になった

こちらのコメントで教えてもらったのですが、GPSMANのように近隣の最近のログインユーザが検索できるようになっています。
雑踏効果（と勝手に名づけましたが）で活性化すると嬉しいですね。

３．ブログへの地図の貼り付けが可能になった

これも　こちらのコメントで教えてもらいましたが、以前紹介したちず窓と同じような感じで、ブログに地図を貼り付けることができるようになってます。
IFRAMEを使っているのでちず窓と比べればちょっと感覚的にちょっとだけ敷居が高いと言うか重い感じ。
その代わり経緯度ベースで利用できるので、その点では応用が効きやすいし、Google Mapsの利用なので表示地図そのものがインタラクティブになるのもいい感じ。
貼り付ければRSSがポジタルマップの検索対象になるのも、ちず窓と同じアプローチですね。
サンプルは続いてのルートマップ機能と共に。

４．自己管理ツールが実装された

1日単位のポイントグラフを作成します。
日々の目標ポイントを決めて、毎日ポイントを登録していくと、グラフが自動的に作成され、自己管理や目標管理にご利用できます。また、作成されたグラフはブログやホームページに表示できます。
グラフの設定にある専用の文字列をお貼りください。
ポジタルでの更新が自動的に反映されます。

ポジタル特有の機能である、友人関係の深さによるアクセス制限等も対応しているようです。
あまり知られたくない秘密の目標（体重とか体重とか体重とか？）も、親しい友人とだけ共有するとかもできそうですね（ただし自ブログ等ポジタル外部に公開する際は非対応）。

５．ルートマップ、ルートガイドが搭載された

３．と同じコメントで教えてもらいましたが、Google Mapsにポリラインをオーバレイしてのルートマップ表示や、そのデータを携帯で見た際にルートマップと現在地の位置関係を示すルートガイド等の機能がついたようです。
ルートガイドは、途中の通過点番号にマウスが乗っかると地図が変わったり、自動アニメーション機能など、中々使用感いい感じ。
ルートガイドも、当初予定していたルートとどれだけずれてるかを確かめられる機能という事で、ポジタル本来の「位置情報ベースの危機管理」的な発想と繋がる感じで面白いです。

サンプルとして、私の毎朝の通勤ルートマップなどを（電車部分のみ）

なかなか色々と、面白く進化しているみたいです。

最後に、今後ポジタルが対応すると面白いだろうなと思うことを個人的に挙げてみます。

1. 対応機種の増加。
   DoCoMoやVodafoneの3G‐GPS、Vodafoneの3G簡易位置情報などの位置取得仕様も出揃ってきているので、この辺にも対応すればいいなあと。
2. 位置情報ではなくSNSとして期待、OpenID等への対応
   ポジタル参加者のIDを外部OpenID対応サービスで利用できるように公開するだけじゃなくて、外部でOpenIDやYADIS対応したID持っているユーザが、特にポジタル側で登録作業を経なくても自由に参加できるような、日本発のOpenID・YADIS対応SNSになって欲しいなーと。
   携帯と連携させるのが難しそうですが、それは一旦ログイン後、携帯メールに連携用URL送信して一旦アクセスさせて連携するとかで可能ではないかと思います。

きのうここが、ここに窓とかオープンしなかったー。
ここに昭文社は窓にサービスされた！
ここでサービスしなかったよ。

とかA p...

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

知恵というか、或いはトラウマによる過剰防衛行動かもしれないけど。
やっぱその経験をした人間にしか判らない感覚というのはあるのだなあ、という。

週末は息子の幼稚園クラスの子の家で、ホームパーティだった。
その時お父さん友達から聞いた話なんだけど、彼は911テロの時NYでの勤務で、WTCビルの崩落でパニック状態になった街を経験したらしい。
それ以来高層ビルが怖くなった、と話していたけど、それにあわせて、そういった非常時に携帯電話では全く連絡が取れなくなると言う経験をして、その時の教訓以来、普段100%使う事なんてないのだけど、財布にはテレホンカードを常時携帯しているらしい。
そういう経験をしていなければ、携帯があればテレカなんて必要ない、使わないのに入れておいても財布が太って邪魔になるし、すれて汚れて汚くなるし、ってので絶対にテレカを持ち歩こうなんて気にはならないと思うんだけど、経験をしていれば感覚が変わってくるのだなあと思った。

あとどうでもいいけどパーティの席上で見つけた小ネタ。

稲妻からエネルギーを得るという着想自体は目新しいものではない。
だが、マサチューセッツ州ボストン――300年前の1月にベンジャミン・フランクリンが生まれた街――に住む発明家で電気技師のリビングストン氏は、独自の工夫を加えた。
レーザーを使って稲妻を捕らえ、それを巨大な水のタンクに流し、限りなく水素を生成し続けるというのだ。

その成果は「度肝を抜くような」ものになるだろうとリビングストン氏は語る。
レーザーのネットワークをフロリダ州のように稲妻の発生しやすい地域に設置し、稲妻のエネルギーを水素に変換できれば、「全世界が必要とする以上のエネルギーを生み出せるかもしれない」という。

これ、マジ実現したらすごいな。
ちなみに、

少なくともこれまで、レーザーが稲妻を捕らえた例は事実上ない。

とあるけど、レーザによる雷誘導の研究自体はそれほどトンデモというわけでもなくて、10年ほど前は、某旧帝大の研究室でも研究してた（というか、研究室の選択次第では俺もそれを研究してた可能性ありって事）。
1997年の日経サイエンスの記事にも載ってる。
その後、どうなったのかはよく知らないけど、上の記事の書きっぷりだとうまくいってないのかな。

要するに原理は、空気は電気的に中性な不導体だけど、空気をプラズマ化してやるとその部分だけ導電率が上がる。
雷は導電率の高い経路を辿って落ちてくるから、プラズマ化した空気の領域をたくさん作ってやれば、そこを伝って落ちてくるだろう。
その局所的なプラズマ化領域を、レーザを中空で交差させて作ってやろうというのが研究の原理。
元々は大事な施設を雷から守るという避雷目的での研究、それですらうまくいってないっぽいのなら、正確に水のタンクに誘導するというのはもっと骨が折れる仕事になりそうだが、うまくいけばすごいエネルギー革命になりそうだな。

過去、優秀な文書管理ソフトを開発している会社に居たために（私自身は携わらなかった。また、リンク先はその旧社ではなく、開発メンバーがスピンアウトして作った会社）、文書管理に関しては一家言ある私ですが、流石に千万円近くする同ソフトと同レベルの管理は不可能でも、なんとかフリーや安いソフトの組み合わせで同じようなドキュメント管理ができないかなと思い、これまで

• DNKAプラグイン - Subversion-GDSドキュメント管理の最後の1パーツ
• Visual Source Safe+Google Desktop Searchでもドキュメント管理

あたりで、

• バージョン管理（Subversion）
• 全文検索（Google Desktop Search）
• シェルからの登録/読出操作（TortoiseSVN）
• Webインタフェース（DNKAプラグイン）

といった要素を揃えてきました。
でも、ドキュメント管理の非常に重要な要素であるにもかかわらず、これまでこれらと連携する形では実現できなかったのが

• 属性管理

なのですが、最近、オープンソースのソーシャルブックマークソフトが出たので、これを使ってできるのではないかと思いました。

• Scuttle
• ソーシャルブックマーク（Scuttle）のインストール方法　-PHPSPOT開発日記-

私のこれまで考えたGDS・Subversion連携のドキュメント管理では、全ての管理文書はGDS->DNKA経由のインタフェースで全てWebでのローカルURIを持ちますので、ソーシャルブックマークソフトがあればそれにタグをつけて管理できるわけです。
ドキュメントの登録者や、閲覧者が備忘に残したタグベースで、ドキュメントの検索ができるようになる。
RSS等も整備されているので、RSSリーダと連携すれば、注目したいタグでの文書検索の最新結果も、逐次知る事ができる。

ただ、冒頭に示した、私にとってのリファレンスになっている文書管理ソフトと比較しての問題は、

• 元ソフトは一体化されたソフトなので、文書の登録と属性設定が同時にできるが、こちらはソフトの寄せ集めなので、同時には不可能。
  まず登録して、その後タグ付けしないといけない。
• 元ソフトでいうところの属性管理と、タグ管理では、やはり微妙に違う。
  元ソフトでの属性管理では、スキーマ等もしっかり定義できて、文書番号等の必須属性の管理等もしっかりできるわけだけれども、タグは所詮は（？）タグなので、飽くまで備忘・しおり的な付加情報管理くらいの役割しか果たさない。

といった問題点はありますが、そこはそれ、千万円オーダのソフトに比べ飽くまで無料ソフトで出来る事なので、とりあえずこれだけできれば上等ではないでしょうか。

miyagawaさんとこで紹介されてるMTのRightFieldsっていうプラグイン、超便利そうなのですが、基本的にモブログかBlogWriteで更新している身としては、XML-RPCやAtomに対応してないとどうにもこうにも。
BlogWriteで更新後、Webページ開けて拡張情報入力ってのもなんか興ざめだし。

と言ったところで、サーバ側がWebAPIに対応したって、その拡張APIにクライアント側（BlogWriteとか）が対応できてなければ意味がないわけなんですよね。
でも、どんな拡張されるか判らないのに、その全てに即座にクライアント対応しろっつったって無理なわけで。
そうなると必要なのが、XML-RPCのメソッドにしろAtomで交換するAtomコンテンツにしろ、そこで設定されるデータの名前や型や説明なんかを一定手続きに従って交換できる仕様なのかなと。
SOAPのUDDIみたいな。
そういうのがあれば、その定義に従って、APIクライアント側で拡張情報の入力フォームを増やしてやれば、どんな拡張にも対応できるようになる。

さらに、Atomベースで話せばそのコンテンツのデータ定義が、POST/PUTだけでなくGETにも適用されるわけなので、そのデータ定義をベースにコンテンツのメタデータ収集もできるようになる。

定義情報を提供する方法としては色々考えられるけど、YADISの手法にならって、APIのエンドポイントのHTTP拡張ヘッダに定義ファイルへのURLを設定しておき、その定義ファイル上で、拡張APIの定義を記述してやるのがよいのではないかと思う。
またその「定義仕様」は、あまりAPIプロトコル毎に仕様が乱立しても仕方がないので、拡張APIの説明だけでなく、どのようなAPIプロトコルに則るのか（XML-RPC？Atom？）も含めて設定する形にしてやればいいかなと。
YADISが主目的は識別プロトコルの判定で、個々のプロトコルで必要な情報の設定は各プロトコル毎の名前空間での拡張に任せているのと同じような感じで。

どうでしょう？

最近yadis.jpなんかも取って一人で盛り上がっている感があるYADISですが、ギークと一般との乖離を危惧してるとかいいながら自分は誰も興味持ってないこと綿々と綴っていくのもアレなので、この辺で説明をば。

YADISとは何か。
OpenIDです。違います。LIDです。違います。いや違わないか。
結局のところ、世の中にはOpenIDだのLIDだの、他には追いきれていないのですがXRIとかSxipとか、URIベースで識別機能を提供する仕様がたくさんあります。
これらの仕様は、それぞれ異なった設計思想で、識別機能を提供する上で重要視する部分も異なって作られているので、どれが優れていてどれが駄目ってもんでもなくて、識別されたいユーザや、識別機能を導入したいクライアントサービス側のニーズに従って選択されるべきもんなわけです。
日常生活で、免許証でIDを照明するか、クレジットカードか、保険証か、名刺か、利用するサービスのニーズによって使い分けるべきなのと同様に。
よってどれかを廃棄して、標準識別仕様を作ればよいというもんでもない。
でも、同じURIを用いた識別手段である以上、そのURIがOpenIDの識別URIなのかLIDの識別URIなのかを意識することなく相互運用できるように、URIからその対応する識別プロトコルをAuto-Discoveryする手順を標準化するという、そのAuto-Discovery手段の仕様がYADISというわけです。
（とりあえず何かを訳したわけではなく、私の頭の中の理解を文章化したので、細部では間違いあるかもしれません。その場合は突っ込みよろしく）

具体的には...と書こうとしたあたりで昼休み終了なので、続きは家で書く（バタンキューでなければ）
沈黙を破って再開。
YADISの仕様は、12月1日にSixApartで仕様決定の主たるプレーヤーが集まってミーティングを行った結果、大きく前進したみたいで、その成果をまとめたサイトはいくつかあるけど、ここが判り易そう。
要するに、実際にIDとして使う識別URLと、そのURLが対応する識別プロトコルを定義するYADIS文書の2つを用意して、

識別URL:

1. 識別クライアント側からアクセスを受けると、値としてYADIS文書のURLを設定した、X-YADIS-Locationという拡張ヘッダをHTTPヘッダに加え、レスポンスを返す。
2. YADIS文書のURLの指定方法は、HTTPヘッダによる指定の他、HTMLヘッダでの、http-equivをX-YADIS-Locationに設定した<meta>タグでもよい。
3. 識別クライアント側は、X-YADIS-LocationでYADIS文書のURLを受け取ると、そのURLに制御を移しYADIS文書を取得する。

YADIS文書:

1. YADIS文書は、Content-Typeとしてapplication/xrds+xmlを返す。
2. YADIS文書の書式は以下の感じ。
   

   <?xml version="1.0" encoding="UTF-8"?>
   <xrds:XRDS
     xmlns:xrds="xri://$xrds"
     xmlns:openid="http://openid.net/xmlns/1.0"
     xmlns="xri://$xrd*($v*2.0)">
     <XRD>
   
       <Service priority="0">
         <Type>http://openid.net/signon/1.0</Type>
         <URI>http://www.myopenid.com/server</URI>
         <openid:Delegate>http://xxxx.myopenid.com/</openid:Delegate>
       </Service>
   
     </XRD>
   </xrds:XRDS>
   

3. 見れば判るとおり、<Service>要素で対応する識別プロトコルを定義しています。 属性priorityはServiceを複数定義した際の優先度。小さいものほど優先されます。
4. 子要素の<Type>は必須。この要素で、対応する識別プロトコルやそのバージョンを一意に識別します。
   OpenIDなら現状、ここの値はhttp://openid.net/signon/1.0、TypeKeyならhttp://www.sixapart.com/typekey/sso/1.0、LIDのVer.2.0ならhttp://lid.netmesh.org/sso/2.0てな具合です。
5. 子要素の<URI>は、識別サーバのエンドポイントのURIを指定しますが、省略すれば識別URLの値が設定されます。よって、識別URLと識別サーバのエンドポイントが等しい、（Delegationを行わない場合の）LIDや、非分散型なので何を設定してもエンドポイントは一意なTypeKey等では設定不要ですが、OpenIDでは必須です。
6. 以上のYADISの持つ要素以外に、識別プロトコルによっては追加の要素が必要になる場合があります。
   その場合はプロトコル毎の別名前空間を準備し、それにより修飾された要素で必要事項を設定します。
   この名前空間は、OpenIDならhttp://openid.net/xmlns/1.0、TypeKeyならhttp://www.sixapart.com/typekey/xmlns/1.0といった形になるようです。
   このような拡張要素の例としては、OpenIDの場合、Delegation仕様を用いているために識別URLとエンドポイントの理解できる元識別URLが異なる場合、元識別URLの方をOpenID名前空間で修飾されたDelegate要素で設定してやる必要があります。
   同様に、TypeKeyの場合、ユーザ名を指定する、TypeKey名前空間で修飾されたMemberName要素が必要になります。

という感じになります。

この仕様の利点としては、最初に挙げた異なる識別プロトコルの運用共通化というのも一つなのですが、他にもいくつか挙げられると思います。

1. LID等、Delegation（あるURLが識別されればこのURLも識別される、という芋づる設定を通じて、実際にエンドポイントが識別するURLと別のURLでも識別できるようにすること）の概念を持っていない（っぽい）仕様でも、原理的にDelegationを実現できること。
   LID自身はDelegation仕様を持たないようなので、「あるURLが識別されればこのURLも識別されたとみなす」部分の作りこみは自分で作ることが必要になりますが…。
   まあそれを言い出すとYADISを扱えるAPIはまだ整備されてないので、全部一緒ですけど。
2. Serviceを複数定義できること。
   これにより、一時的に識別サーバが落ちていたとしても、別のサーバで識別できるので可用性が高まる他、同じ識別プロトコルだけでなく別の識別プロトコルの設定も並列して書けるので、例えば識別クライアント側が「OpenIDは信用できない、TypeKeyで識別できるユーザしか受け付けない」という考えを持っていても、YADIS対応のURLで同一ユーザのOpenIDとTypeKeyのアカウントが集約されるので、ユーザ側は同じ識別URLでログインできることになります。
   また別例として、OpenID等でそのオープン性が災いして、どこかのOpenIDサーバが個人情報漏れを起こして信頼できなくなった、とした場合、識別クライアント側が一斉にその識別サーバでの識別を拒否したとしても、ユーザ側はYADISに代替の別サーバを登録しておけばさえ、ユーザは識別サーバの置き換え等をすることなくこれまで通り識別サービスの恩恵を受ける事ができます。
   リッチにいろんな識別サービスの設定を設定しまくったYADIS文書のサンプルは、NetMeshのYADISエリアにある、このサンプルを見てみてください。
3. いろいろなサービスのアカウントが集約されるので、複数サービス間の機能の相互運用の架け橋になりうる。
   現在、例えばはてなとMixi、TypeKeyで例をとると、はてなのkokogikoアカウントとTypeKeyのkokogikoアカウント、Mixiの119403が同一人物だって事はシステム的には判らないわけですが、将来、それらのサービスがOpenIDや、そうでなくてもTypeKeyのような独自形式であってもオープン識別手段を提供し、さらにYADISにも対応すれば（名前空間とか定義するだけですが）、YADISを通じて同じ人だと判るようになるわけです。
   そうすると、これまで色々なサービスというと各サービスの物理境界で分断されてしまっていたわけですが、その間を橋渡しするような機能の実装も可能になり、実質的にバラバラ個々のサービス、というのではなく、インターネット全体が識別URLで識別される個人に対し、一貫したサービスをワンストップチャネルで提供するような事も実現できるようになるわけです。
   SNSなら私がずっと言ってきたSNSのオープン化も、実現できるようになる。

と言った感じでしょうか。

しばらく注目の仕様だと思います。

昭文社さんのブログに地図をはっつけられるサービス、「ちず窓」がオープンしました。

このサービス、企画・開発の途中で中の人の一人が、うちの記事であるところの　この辺に影響を受けた、ということで、事前に教えてくださったので、出たら真っ先にレポートしてやろうかと思ってたのですが、忙しさにかまけている間にすでにはてブで200件超のブックマーク。
出遅れまくってます。

このサービスの面白いところは、単に地図をはっつけるだけでなく、その地図がはっつけられた事を通して、ブログの位置情報を集約しているところ。
ブログをクロールして位置情報を探す、といったアプローチではなくて、逆に餌を撒いて位置情報側に食いつかせている感じね。
サービスを利用させることで位置情報を集約する、というアプローチが私の記事に影響を受けたというあたりなのかな。

まだ会社でじっくり目を通してないので、中の人への返事で提案した外部から位置情報の登録なんかを叩けるWeb-APIあたりとかが採用・実装されたのかは判らないのだけど、その辺が実装されてればGPS携帯電話のモブログサービスなんかとの連携もすぐできるし、爆発的に使われそうな予感が。

とりあえず、今いるところをはっつけてみよう…と思ったら、社内プロキシ激重で反応せず。
使えん　＞　社内ネットワーク

きょうねねで、blogしたいです。
きょうは、ここでblogされた！
ねねがここへblogしなかった？
ねねがblogしなかったー。

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

最近yadis.jpなんかも取って一人で盛り上がっている感があるYADISですが、ギークと一般との乖離を危惧してるとかいいながら自分は誰も興味持ってないこと綿々と綴っていくのもアレなので、この辺で説明をば。

YADISとは何か。
OpenIDです。違います。LIDです。違います。いや違わないか。
結局のところ、世の中にはOpenIDだのLIDだの、他には追いきれていないのですがXRIとかSxipとか、URIベースで識別機能を提供する仕様がたくさんあります。
これらの仕様は、それぞれ異なった設計思想で、識別機能を提供する上で重要視する部分も異なって作られているので、どれが優れていてどれが駄目ってもんでもなくて、識別されたいユーザや、識別機能を導入したいサーバ側のニーズに従って選択されるべきもんなわけです。
よってどれかを廃棄して、標準識別仕様を作ればよいというもんでもない。
でも、同じURIを用いた識別手段である以上、そのURIがOpenIDの識別URIなのかLIDの識別URIなのかを意識することなく相互運用できるように、URIからその対応する識別プロトコルをAuto-Discoveryする手順を標準化するという、そのAuto-Discovery手段の仕様がYADISというわけです。
（とりあえず何かを訳したわけではなく、私の頭の中の理解を文章化したので、細部では間違いあるかもしれません。その場合は突っ込みよろしく）

具体的には...と書こうとしたあたりで昼休み終了なので、続きは家で書く（バタンキューでなければ）

Configuring a YADIS URL using only Apache -OpenID Enabled-

Apacheのモジュールと設定で、YADIS対応の識別URLを作る方法。
OpenIDのMLで回ってた。

後で読む。

また、地図表示ソフトであるグーグルローカルにしても、包括性を念頭において提供をしています。
当初は、なぜグーグルが位置情報のサイトに乗り出すのかと疑問視する人たちがいました。

この感覚の方が不思議。
2?3年前激しくディスカッションした連中との間のキーワードは「位置情報のGoogleを!」だったし、実際ぼやぼやしてたらいつかは絶対Googleが手を出すと思ってた。
まさかいきなり地図を全面に押し出してくるとは思わなかったけど。

ボーっとネット界を俯瞰してたらGoogleが目指している、或いは今後目指すであろうところとかも見えてこないですかね。
例えばこの3、4年の間には、Googleは人そのものを検索対象にすると思いますよ。
ある事に関する専門家を知りたい時、その中でもっとも自分に近しい人を検索したり、とかね。
Googleだって成功も失敗もするけれど、多分どっちかというと失敗の一つに数えられてるGoogle Talkだって、その視点から見れば大戦略の布石の一つと捉えられないことはない。
もっとも、もしそうだとしても失敗のうちにはいる戦略かな、とは思うけど。

このリリースと同時に「あるウェブページのモバイル版 URL を明示的に指定する」 Mobile Link Discovery のドキュメントも作成して公開しています。

昔２ちゃんねるで、「mobile.txt」なんて仕様を検討していたのを思い出します。
モバイルURLを見つけるためというよりは、いやそれもあるけど、対応している携帯キャリアの情報を示すことが主眼でしたが…。
キャリア同士の仕様が違ってお互いのページが見られなかった古きよき？悪き？時代の発想。
まあ今でも、それこそ位置情報取得とか、キャリア毎に全然違う仕様のどれどれに対応するかと言った情報があってもいいかもしれないけど。

ところでこのMobile Link Discovery、飽くまでPC用URLと携帯用URLが違う場合のみに使うのかな？
それとも、URLは同じでも携帯版サイトも用意されてるよ、という言及のために使ってもいいんだろうか。
仕様書を見る限り前者っぽいけど、正確にはどうなんだろ。
教えてエグイ人。

あと、TypeKeyの携帯対応キボンヌ。

ねねは
旧日本測地系(TOKYO97)戸塚測地系(WGS84)変換はメッシュを考慮しないと歪む
とか書いてた？

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

はてな・MixiにOpenID対応汁！の声が高まっております。

• Authentication/Identity for Mashups -blog.bulknews.net-
• はてなとMixiがOpenIDに対応してくれればなあ
• 独自アカウントから解放されるということ -眠る開発屋blog-
• なんでもオープンとか言うなら、ぜひともユーザー認証もオープンに -浅倉卓司＠blog風味？-

各投稿の温度差無視して都合のいい部分だけで一からげにしたというそしりもありましょうが。

各サービスがOpenIDでのサーバ・クライアント双方に対応してくれ、そして各サービス独自のIDとOpenIDとが紐付けられれば（=各サービス間のIDが相互運用可能になる）、それだけでも各サービス間の機能の疎通が一意なOpenID経由で可能になって、SNSはオープンにしないといけないよという以前のエントリに対する一つの解になるんじゃないかと思うんだけどなあ。

とかApacheモジュールで誰か作ったりしてないのかな。
Apache自体で訪問者のOpenID識別に対応して、下のコンテンツ全体に識別状況を環境変数なんかで渡してやると、激しく便利な気がするのだが。

今のWebサイト、MovableTypeならMovableTypeだけ、WikiならWikiだけで完結しないサイトも多いと思うんだけど、アプリ単位でOpenID対応しても、同じサイト内のアプリ切り分け部分を遷移するたびOpenID識別要求されることになりかねないのでウザス。
Apacheがモジュールで対応すれば、その下のアプリ全体が共通のOpenID識別情報を共有できるでしょー、という話。

ついでに、そのベースの上にmod_authz_foafとかで、Apache全体でFOAF承認を管理して、友達には見せるけど一般公開しないよん、なコンテンツなんかもアプリ横断で処理できるようになればよろしいな。

測地網の歪みと位置のずれ

うう、判らなくなってきた。整理。
JGD2000（WGS84）とTokyo3p（仮名：27歳独身）の間は計算だけで変換できるけど、Tokyo97への変換は変換テーブルを使わないといけないんだよね？
ということは、Tokyo97は直交座標系ではないってこと（直交座標系同士なら計算機変換できるはず）？
というか、直交座標系を目指したのだろうけど、測量精度の問題でズレてしまってふにゃふにゃ座標系になっているってことなのかな？

もしそうだとすると、Tokyo97で与えられた地物データと、JGD2000から変換したTokyo3pでの地物データを単純に計算機処理での直交座標系上にプロットした場合、ズレが生じるのは当然だけど、現実世界と等しい、正しい位置関係を表しているのはTokyo3pの方、ということになるのだろうか。
ふにゃふにゃ座標系は、計算機上で正確にプロットなんてできないだろうから…。

要するに、

• 測量精度の低い時期に全国の測量がされ、座標系に歪みを生じた状態で全国に測量基準となる三角点等が整備された。
  全国の測量はそれらをベースに行われているわけなので、日本全体の経緯度座標が、ずれた形で登録された。
• JGD2000の採用で、精度の高い測量成果に改められた。

という理解でOK？

疑問なのは、そうなると今までの日本測地系による座標をベースに描かれた地図って、現実と異なる位置関係を示していたことになるんだろうか？

Google Maps が狂っている -古今東西右往左往-

Tokyo97 と JGD2000 との食い違いは 1. 楕円体選択 2. 原点の違い 3. メッシュの歪みの三つの原因で生じています。
このうちの 1. と 2. は計算式で相互に変換することができます。
この計算式はきちんとパラメータを設定すれば日本中どこの緯度経度でも同じものを使えます。
しかし 3. の歪みは場所によって違いますから、これを反映しようとすると場所ごとに何らかの表を参照して変換するしかありません。
実はここで困ったことが起きています。
日本で使われることのある測地系は三種類と書きました。
ところがここにもう一つ変テコな測地系があるのです。
JGD2000 で記述された位置を、3. の歪みを忘れて 1. と 2. だけ反映する計算で「日本測地系」と称するものに戻したものです。
これをやると、歪みのせいで沖縄の離島などでは実際の位置とのあいだに数百メートル以上の食い違いが生じてしまいます。
にもかかわらず、日本で売られていたりオンライン利用可能になっている数値地図にはこの変テコな測地系で記述されているものが少なくありません。
いろいろな人が独自に名前を付けていますが、ここでは Tokyo3p と呼ぶことにします。

すみません、アマチュアとはいえ長年位置情報やってきましたが、知りませんでした...PerlモジュールのLocation::GeoToolも、楕円体と原点の違いしか考慮していません。
というか、正確には、さすがに「完全正確な旧日本測地系<->世界測地系変換をしようと思えばメッシュの歪みも考慮する必要がある」くらいのことは、位置情報を始めた最初期から知っていましたが、知らなかったのは「メッシュの歪みから生じる誤差が数百メートルにも及ぶことがある」ということでした。
メッシュを考慮しないと正確ではない、といっても、メッシュを無視して生じる誤差は無視できるレベルだと思い込んでいました...。

元記事書かれた方がどうやってこの知識を得られたのか判らないのですけども、やっぱり必要に応じて拾った知識ってのは、本当の意味では身につかないですね...業務でやるか、本気で勉強するかしないと。
Location::GeoTool使ってGPS（WGS84）で取ったデータを地図（TOKYO97）上でマッピングなんてしょっちゅうやってましたが、自分の周りじゃ全然困った事なんてないので、気付きようもない。
自分でずれる地域に行ってGPSで取った位置と変換後の地図マッピングでずれに気付くか、或いは最初から「同じ地図」を日本測地系と世界測地系で描いたものを比較してずれに気付く、といった経験がないと判んないです。

他にも最近まで知らなかったこと。

このうち GPS が利用する WGS84 と測量法により2002年4月1日以降公式に使用されている JGD2000 は歴史的には異なっていますが現状ではほぼ同じものになっており、多くの文章ではまとめて「世界測地系」と呼ばれています（が、実は正しい意味での世界測地系はいくつもあって、日本が採用したものはそのうちの一つであるに過ぎません）。

これも、たまたま最近この知識を得る事があってこの記事で知ったわけではないのですが、でもほんまに1週間前かそこらのレベルの話で、世界測地系といえばWGS84と思い込んでいたので結構ショックでした。

うーん、まだまだ知らないといけない事が山積みです。
奥が深い。というか深すぎるー。

うちの部署の課長さん達、お前らドリフかなんかか！と突っ込みたくなるくらいキャラ立ちしてておもしろい。

でぶ。
のっぽ。
ちび。
くろ。
はげ。

はげはつるっぱげではないけど、後はどれも半端ない。

というか、ちょっと前から公開されていたようなのですが、こちらのコメントで教えていただきました。
毎度どうもです！＜コメントいただいた方

Vodafone Developers Support Site ツール&ダウンロード 技術資料の中の、ボーダフォンライブ！サービス向けの開発ガイド[HTML編]が11月に更新されていて、取得方法が載っています。
やっぱり、簡易位置情報でも2Gと3Gでは方法が変わったみたいですね。

ついでなので、各キャリアでの位置情報の取り方リソースをまとめてみようかと思います。

• DoCoMo
• • オープンiエリア
  • • 公式仕様ページ
    • 解説ページ
  • Mova GPS（F661i、F505iGPS）
  • • 公式仕様ページ
  • FOMA GPS（SA700iS）
  • • 公式仕様ページ
• au
• • 簡易位置情報
  • • 公式仕様ページ
    • 解説ページ
  • GPS
  • • 公式仕様はありません
    • 解説ページ（簡易位置情報のリンク先と同じ）
• Vodafone
• • 2G 簡易位置情報
  • • 公式仕様PDF
    • 解説ページ
  • 3G 簡易位置情報
  • • 公式仕様PDF（2G 簡易位置情報のリンク先と同じ）
  • 3G GPS(V903T)
  • • 公式仕様PDF（2G 簡易位置情報のリンク先と同じ）
• WILLCOM
• • 位置情報
  • • 公式仕様PDF
    • 解説ページ

どうもその話題で友人知人・GISer界隈が盛り上がっているのですが、なんちゃってGISer・なんちゃってOpen Source-erでしかない私にはイマイチそのインパクトが判ってなかったり。

というわけでとりあえずそういう動きがあるらしい、というだけで後はリンクの紹介だけでお茶を濁すと言う。

Autodesk Embracing Open Source -Nakamura-KU ADDICT-

Autodesk がMapServerにコミットする模様。

MapServer Foundation -飛べない日々-

MapServer Foundationなるものができるそうです。
どうもAutodeskが自前の製品をオープンソース化してMapServerの名を冠してリリースするということのようですが。

MapserverFoundation創設だそうな -hogemanのコアダンプ（´皿｀;）-

設立のプロセスが閉鎖的なのでなんかヤダーとかいう声も。
商売上の思惑がどうとか、マーケティング上の不公平とかいろいろ議論はあるみたいだけど、ひとつだけ確実に言えるのは今回の発表は少なくとも対コミュニティ的にはあまり上手くなかったかも、ということ。

MapServer Foundation？ -いいタイトルが浮かびません。-

いままでのMapServer→MapServer Cheetah
MapGuide→MapServer Enterprise（オープンソース）
となるらしい。

でもってやっぱり締めは、実際設立の現場に立ち会ってこられた横浜スローライフさんの記事。

MapServer Foundation -横浜スローライフ-

MapServer Foundationの設立が発表された。
同時にこれにはAutodeskが基金を提供し、さらに次期バージョンのMapGuideのソースコードをLGPLで提供することが発表されている。
このソースコードはMapServer EnterpriseとしてMapServer Foundationが開発を引き継ぐことになった。

MapServer Foundationあれこれ -横浜スローライフ-

ちょっと裏話になるが、AutodeskがMapGuideをゼロから作り直し、それをオープンソース化しようと考えたのは少々前のようだ。
一番の問題は MapServerとの関係をどうするかであり、その調査もあったのだろうが、ミネソタで開催されたMapServerユーザカンファレンス（OSG05）にAutodeskからGoeffが出席した。
Goeffはオタワにいるので、DMSolutionsの本拠地と同じで、社長のDaveとも顔見知りである。そんなこともあり、9月に入ってから彼を突破口に具体的な模索が始まったようだ。

北海道ＣＭＣさんが、オープンソースGIS情報のリンク集を作られたようです。
リンク許可願いのメールをいただいたまま忘れていたのですが、昨日オープンのメールが送られてきました。

オープンソースGISリンク集

これまで外国製のオープンソースＧＩＳは日本語に対応していながら十分なドキュメントがないため簡単に利用できませんでした。
しかし、MapServerについては国内の有志によりマニュアルなどの日本語訳が公開され、誰でも利用できる環境が整ってきています。
このサイトではMapServerに関する日本語情報を中心にご紹介します。

インストール法からリファレンスまで、あちこちのリソースを精力的に集めておられます。
というか、うちへのリンクって、PostGISリファレンス和訳へのリンクですか！
あんな、旧バージョンでしかも途中で投げ出しちゃってる奴、このそうそうたるラインナップの中ではリンクされる方が恥ずかしかったり…。

しかし、あらためて見るとたくぼさんちはすごいですな…。

以前のエントリにコメントをいただいたので、ちょっと覗いてみました。

NAVIBLOG

1. 日本初
　　日本初の地域情報と連動した、携帯電話ブログ検索エンジン
2. 使いやすい
　　3クリック以内に、お持ちの携帯電話の周り200m半径内の店舗や関連ブログ情報が表示される*
3. 安くて早い
　　ナビウォークの半額で、他の携帯電話検索サービスの3倍の速さ
4. 最先端へ
　　初めて携帯電話ブログが地域検索と融合*
　　(*特許出願中)

おー、これは面白そうだ。
ちゃんと色々ユーザビリティとかも研究されているようで、好感が持てます。
サイトをみればデザインセンスも中々で、Coolで面白いサービスが期待できそうです。

とはいえ、コンセプトは判りますが具体的にどんなサービスかはイマイチ判らなかったので、動くものがあるのかどうかコンタクトとってみると、今はまだ開発中で、もう１?数ヶ月中にはサービス展開できそうな感じだそうです。
公開しない約束でデモバージョンを見せてもらいましたが、おおっこれはっ、って感じでした。
アプリを使ってない（アプリを使わない、ダウンロードなんて面倒なことはさせないというのはコンセプトの模様）のに、XHTMLの範囲内でGoogle Mapsみたいなのができている。
いや、リアルタイムスクロールするわけじゃないのでそれは言いすぎですが、すくなくともLook＆Feelはすごいクールなものでした。
あんなテクニックがあるとは知らなかった。やられた…。

というわけで、実際にサービスインする日が楽しみなサービスです。

「ソフトウェアを200円、300円などの小額で売りたい」「それぐらいなら買ってもいい」と思う人は多いのではないだろうか。
しかし、残念ながら日本では個人が契約できる、手軽で便利な小口決済がない（と思う）。
そこで、はてなポイントでソフトウェアを決済するという仕組みはどうだろう？

あー、はてなポイントで決済は考えてましたー。
シェアウェアじゃなくて携帯勝手サイトの課金決済用途だけど。
Myはてなでのポイント送受信のページをスクレーピングして、ユーザ登録されてるはてなIDの人からのポイント送信記録があるかを定期的にチェックして、どこまでチェックしたかの確認は日付と、最後の入金記録での日付・ユーザID・残ポイント額のハッシュで管理して、次回の定期チェック時はその後のデータからチェックしてやれば、ユーザからの課金記録を作れて、課金記録のあるユーザだけにサービス提供、というのが可能かなと。
というかこれに関しては、そーゆー動作するPerlモジュールかなんか作ってそいつで語ろうと思ってたんだけど、優先度超低めに設定してたら同種の案が出ちゃったので、ついでにアイデアカミングアウト。

個人的な体験からきてる案なんだけど。
昔、へぼい携帯向けゲームサイト提供してたことがあるんだけど（今は管理しきれなくなったので他人に譲渡）、何か管理人の技術といろんな用途に使いまわしまくりのサーバ性能では処理しきれないほどのアクセスが来て、しょっちゅう鯖落ちしたりしまくってたんだな。
で、個人の時間や金ほとんど全て費やして、小遣いも睡眠時間も家族サービスの時間も返上ってな具合で必死の対応を日々してたんだが、まあそれでもおっつかなくて、一部の心無いユーザ達からは「もーいいよ、課金でもなんでもしていいから、ちゃんとメンテナンスしてサービス安定させろよ」みたいな攻撃を受けていたんだけど、この心無い攻撃には二重の意味で腹が立ってて（というか悲しくなってて）。

第一には、課金してもいいから常時メンテナンスしっかりして、サーバ安定させろと言うけど、別に課金されなくたって既に個人の時間限界まで費やしてんだ、それ以上の、商用レベルの稼動を保証するメンテナンスを求めるなら、俺は仕事辞めなきゃなんないんで、課金といっても百円とかのレベルじゃなくて売上トータルで月額百万二百万が保証される課金を出してくれないととても稼動保証なんてできないんだが、それを判って安易に「課金でもなんでもしろよ」と言ってるのか、ってこと。

で、それとは別に第二には、実は課金はやりたかったんですよね。
別に儲けるためじゃなくて、俺もどうせやるなら100%は無理でもちょっとでもいいサービスはしたかったんで。
そのサイトのユーザは1000?1500人前後はいたわけなんですが、100円の課金でも100人、10円ですら1000人が毎月課金に応じてくれれば、10000円になって、サーバを1台余分に借りる原資ができる。
そうすると、当時も今も、私はサーバは1台しか持ってなくて（実は正確じゃないけど詳細省略）、運営している3ドメイン（今は4ドメイン）のサービスみんなこのサーバでやってるし、開発すらこの上でやってるので、開発のミスでちょこっとサーバが無応答になっちゃったりしたら、サービス全部がこけてしまう。
逆に、開発を進めたくても、サービス側が高負荷になったらほとんど作業できなくて、という悪循環だったけど、サーバを余分に借りられてサービス専用のサーバを作れたら、少なくともそういうレベルでのサービスの悪さは解消できる。
だから、商用レベルの対応と言われれば保証はできないけど、少なくとも今よりは少しはマシにはできますよ、ということで、常識範囲内の小額課金は本当はやりたかったんです。

でも、決済手段がなくて、やりたくてもできなかったんですね…携帯キャリアの公式サイトになって決済機能を使うには、ちゃんとした法人格で企画を提案して、何ヶ月も半年もかけてキャリアの審査を受けて、ユーザ対応もしっかり出来ることを示して、それだけの労力をかけてさらに審査を通るという狭き門をクリアした上で、初めて利用できる。
個人の余暇でやってる勝手サイトは公式には絶対通らないし、となると課金手段は全くなかったんですね。
やりたくてさえやれないにも関わらず、その実態をも理解せずに安易に「いいからとっとと課金しろ」等と言われる悔しさがあったので、今は自分はやっていないにしろ、同じように携帯勝手サイトで頑張ってる管理人さんが気軽に小額課金を検討できる手段はないかなあとかずっと考えてて、はてな投げ銭にインスパイアされてはてなポイントを決済に使えばいいな、と思いついたのです。

技術も金もないけどちょっとサービス始めたら妙に流行っちゃって、ちゃんとよいサービス提供したい気持ちはあるのに現実にはついていけず、ユーザからも突き上げられて悲しい思いをしている管理人さんがもしいたら、上に書いたような方法ではてなポイントベースでの小額課金を検討してみたらどうかなと思います。
儲けるためではないんだとちゃんと理論立てて説明すれば、ユーザコミュニティもちゃんと理解してくれると思うんですけど。

戸塚のキオスクで生茶の500mlペットボトル買ったら
ストローおつけしますか？と聞かれてびびった

お茶を…
ペットボトルで…
ましてや500mlをストローで飲む奴…

　　そんな奴おらんやろ！

マニュアル対応だなあ…
まだ十代二十代の若い奴なら判るけど、四十五十のいいおばちゃんが…

大きい自身とかを活躍しながらも、頭の隅でひっかかっていて私自身書きたい.

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

ここギコのWikiの方で、まるで現在も継続してやってるがごとく記事が残っちゃってますが、昔、今は亡き携帯版ここギコ上で位置情報ベース広告の配信実験をやったことがありました。
まだ大阪にいた頃だからもう2年半くらい前になるな…参加してくれる広告提供者を募るため新聞広告まで打ったんですが、参加してくれたのは多分アンテナ奪取経由でここギコを知ってくれてたまんが喫茶の店長さんだけ。
いつか携帯版ここギコもなくなりまして、位置情報ベース広告配信の系譜はそのまま立ち消えました。
最近TEDDY-GさんところでGoogle Mapsを使った地図上ベースでの位置情報連携広告配信デモは作られましたが、携帯でのリアルな位置情報ベースの広告配信は永らくないままでした。

で、ついに太平の眠りがさめて、携帯SNSアクティボのシリウステクノロジーから、位置情報ベースの広告配信サービスAdLocalが始まりました！
うーん、嬉しいような、くやしいような。
でも、これが成功すれば、俺が考えていたアイデアが正しかったって事なので、ぜひ頑張って欲しいです。
いや、実際、ちゃんと配信するプラットフォームさえあれば、相手の位置に関係なく無差別に配信する既存の広告モデル（まあ年齢性別等のユーザ属性による広告フィルタリングはあるにしても）と違って、本当に顧客になり得る層だけに限定して配信できるので、露出が少なくなる分配信料も安くなり、Google AdSenseなんかと違って地域の小店舗なんかでも広告が出し易くなるはずなので、広告主にも配信を受ける側にも多大なメリットがあるいいモデルだと思うんですけどね。

問題はHTTP上ならどこのサイトにでも配信できる既存広告と違って、位置情報ベースと言う、位置情報に対応したサイト上にしか配信できるプラットフォームが存在しない事。
だからそれがどの程度育ってて、それが広告主にどの程度アピールするかが鍵かな。
また、位置情報サイトは、いちいち位置取得に時間待ちさせられ、さらにサイトを渡る毎に新たに位置取得させられたりして、実は結構ユーザにとって面倒くさい。
サイトに行っても、まずは位置を取らないと位置情報ベース広告なんて配信できないしね。
その辺を、私は位置情報サイト間で位置情報の持ち回りが出来る言わば「位置情報のシングルサインオン」プラットフォームを作って、サイトを渡っていっても最後に取得した位置情報が引き継がれ、かつ「シングルサインオン」側で位置情報取得技術をカプセル化する事で、サイト作成側は位置情報の取得方法やキャリア毎の差を意識せずに、簡単に位置情報サイトが作れる、という経路を考えていたんですけれども。
そんな感じの工夫をして、勝手位置情報サイトの芽を育てていく事が鍵じゃないかな。

頑張れ！勝手に「俺の子」気分で応援しちゃいます。

Firefox 1.5 リリース！SVGネイティブサポートの衝撃！！-Zopeジャンキー日記-

いやー、ついに来ましたねーSVG。
さっそくインストールしちゃいますた。

Operaは8からSVG対応だし（もっともJavaScriptとかも絡んで完全互換かは判らないけど…この辺とかはOperaでも見られたがテトリスは動かなかったっぽ）、IEも7からSVG対応らしいし、いよいよSVG、ひいてはgoSVGの時代ですかね。
そうなると今はIEはVML、他のブラウザは透過PNG対応のGoogle Mapsの図形レイヤリングなんかも、SVGに移行していくんですかね。
そうなると、グレーゾーンだったこの辺の特許問題も、SVG使えば特許主張不問、ということで、解決できてめでたしめでたしです。
折りしもJavaScript→AJAXが盛り上がってる昨今、その扱える表現力がHTMLベースだけでなくSVGベースでの図形等も自由に出来るというふうになると、なんかすごい事になりそうな予感です。

とまあそれはいいんですが、嬉しそうにFirefoxを考えなしにアップグレードしちゃって、またぞろ毎度おなじみの

• 拡張機能全部入れ直し
• • 何入れてたか判らなくなった
  • 入手元が判らなくなった
  • まだ1.5に未対応

とかの問題噴出で2時間近く潰れました。
この辺、いい加減なんとかならないですかね？
最新版のプラットフォームに対応していなくても、未対応なら非アクティブ表示のまま残してくれれば、それを使っていた事が判ってそれだけピンポイントで更新しにいけるんだし。
或いは拡張機能を最新プラットフォームに対応させるっていったって、たいていの場合中の対応バージョンの数字増やすだけで動作したりするんだろうから、拡張機能作者が永らく最新プラットフォームに対応してくれないなら、at your own riskで旧プラットフォームにしか対応していない拡張機能でもどうしても使いたいものは動作させられるモードとか付けてみたり。
そういうプラットフォームバージョン移行に当たっての気配り機能をつけて欲しいんだけどなあ…。

もちろん、何入れてたか判らなくならないように拡張機能のリストを作るTipsもあるし、about:configの値設定して、プラットフォーム側のバージョン番号強引に書き換えて旧バージョン用の拡張機能使う荒業もあるけれど、そういうユーザ側に手間をとらせて危険も伴う対応をしなくても、標準でこれまでの環境を簡易に移行できる方法を備えて欲しいなあ、と思う。
もう、一部先行技術先取りユーザだけのおもちゃじゃなくて、立派にIEに対抗しうる、一般普及したといえるブラウザに育ってるんだからさ。