![[ここｷﾞｺ!]](http://kokogiko.net/logo.png){kind=logo}
2007年02月28日
OpenIDの属性交換拡張の実装例、及びOpenIDサーバに認証させるにあたってのケーススタディ
で、今度は「I want my OpenID!」でログインフローを確認してみました。
IDを入力して、サブミットすると・・・今回もVidentity.orgのセキュリティチェックページ（？）にリダイレクトされ、同じように「はい、今だけ」を選択したところ、その結果I want my OpenID!のページに戻り、「ログインしたいなら、emailアドレス入力せよ」とフォームが表示されました。
しょうがないので入力すると（またしてもだまされた感がしましたがｗ）、ログインは無事成功。
（I want my OpenID!は「ログイン成功。メール送ったからチェックしろ」と言いますが、いまだにメールは届きません・・・）
ほへ？と思って、私もhttp://kokogiko.net/を使ってI want my OpenID!にログインしてみたところ、いつもどおりDelegateしているMyOpenIDの認証画面に移って認証。
ところがその後の画面がこれまでと異なって、「I want my OpenID!」が追加の個人情報としてe-mailを要求しているが、送ってもよいかといったような確認画面が。
おー！
仕様追えてなくて、この仕様がOpenID Simple Registration ExtentsionにあたるのかOpenID Attribute Exchangeにあたるのか判らないけど、要するに単なる認証仕様だけでなく周辺の付帯情報交換の拡張仕様なんかも実装として動き出したということか！
なかなか感動。
元記事の人の状況なんかは、Videntity.orgが付帯情報（e-mail）を交換する拡張仕様に対応していなかったので、「I want my OpenID!」が独自にユーザにe-mailを要求したという感じなんだろうな。
と言いつつ、俺がやった時も、MyOpenIDの方で「I want my OpenID!にe-mail送ってもいい？」と聞かれてYesにしたにもかかわらず、I want my OpenID!の方でもまたe-mailを聞かれたので、どうもまだ付帯情報交換の拡張仕様プロトコルの方はうまく取り合えていない予感。
もうひとつ面白かったのは、私はhttp://kokogiko.net/をOpenIDサービスのアカウントにDelegateさせるにあたって、古いlinkタグをhtmlに仕込む方法ではなく、Yadisドキュメントという仕様を用いて複数のOpenIDサービスのアカウントをDelegateさせているんだけど。
I want my OpenID!は、http://kokogiko.net/でログインしたけど、各OpenIDサービスでの認証画面に移った際に認証手順を途中で終了してログインを完了しなかった場合、次同じhttp://kokogiko.net/ でログインしようとすると別のOpenIDサービスを使った認証にリダイレクトして、その結果全てのDelegateサーバでhttp://kokogiko.net/でのログインが完了せずに失敗すると、こっちがCookieを消すまでhttp://kokogiko.net/でのログインを拒否してきたりした。
これは中々おもしろかった。
悪意ある第三者がブルートフォースでIDを盗むようなことがないよう、一度認証失敗したOpenIDサーバは使わない、というようなポリシーっぽい。
なるほど、OpenIDもすでにしばらく運営されてきて、いろいろ運用上のセキュリティを守るノウハウ、ケーススタディが出てきているのだなと思った。
2007年02月25日
PlaceXML成果報告会
書こうと思ってて忘れてた（すんまそん）。
日本情報処理開発協会／データベース振興センターが、3/1・2の2日間、青山TEPIAでPlaceXMLの成果報告会やります。
事前登録された方には、特典として「PlaceXML概説書」を会場にて１人１冊差し上げます。
【日時】 第１日目：平成1９年３月１日（木） 13:05?17:00 受付：12:00?
第２日目：平成1９年３月２日（金） 13:05?16:50 受付：12:00?
【会場】 青山TEPIAホール４Ｆ、ホワイエ
【展示】 PlaceXML実証実験デモ
PI実装検証デモ
IE対応SVGビューワ（予定）
地質データの利活用展示
【参加費用】無料
私ももちろん行きます。
これまではこういうの行くとなると有休とるしかなかったわけですが、とりあえず今回は公務で行かせてもらえるということで、ありがたいです。
位置情報系の会社に就職してよかった。
その代わり当然、何か業務に活かせる事を学び取れるよう考えないといけないし、個人で参加してた時と違ってあんまりはっちゃけた事もできなくなる訳ではありますが...。
今回の楽しみは何といっても、自治体主導のGIS応用サービスがむちゃくちゃ進んでいる三重県の、GISの鉄人、コバテツさんが公演されることです。
マイミク申請とかネット上で軽いお付き合いはさせていただいているものの、直接お会いした事はないのでとても楽しみです。
タイトル見ておもしろそうなのは、「日本トイレ協会」さんの、「外出時のトイレ情報の必要性とPlaceXMLツールへの期待」という公演。
「外出時のトイレ情報」の切実さ...は、別に公演していただかなくても誰でも身に染みてますから！みたいな。
いやもちろん冗談で、単なる公衆トイレ情報だけでなく、身障者向けのトイレ情報とか、そういういろんな切り口等も示してもらえると思うのですが。
後はオークニーの森さんや、挨拶はしてないですがPlace+でも公演を聴いたLocky.jpの河口先生等も来られるので、なかなか盛りだくさんで楽しいカンファレンスになりそうです。
50-60代のネット利用、交通手段や地図、旅行コンテンツに関心
今後利用が増えると思うジャンルを選ぶ質問では、50-60代においては、「路線・交通手段の選択」「地図情報の収集」「文字ニュースの閲覧」が上位3つで、次いで「旅行や鉄道の予約」となっている。特に、「文字ニュースの閲覧」以外の3項目については、全体の平均よりも利用意向が高かった。一方、「オークション」や「掲示板、SNS、ブログの閲覧」などでは、全体平均よりも低くなっている。
Google Mapsなんかに代表されるAJAXのスクロール地図インタフェースは、実際私なんかから見ても使いやすいし、AJAX技術の流行に乗って広まりつつあるけど、こういう年配の方の利用シーンにおいても最適なインタフェースかと言われればちょっと疑問な気もするな。
根拠はと言われると直感なので困るし、なので断言じゃなくてリサーチが必要かも、という問題提起レベルにとどめるけど。
私らの世代なんかは、インタフェースにとにかく自由度を高める事を要求するし、自由度さえ高まれば後はどんな用途にでも自分の好きなように情報を使いまわすわけだけど、そこまでITというものを使いこなす事に慣れていない人達にとっては、自分で工夫して使いこなすというよりも、自分が欲しい情報だけをド直球で投げ返してくれるようなインタフェースの方が好まれるのではないかという予感がする。
最近、SoftBankモバイルのCMで、息子に電話でパソコンの使い方をレクチャーされてて、画面の上でマウス動かしたり、ウィンドウ開いてと言われて窓を開けて、庭を見ながら「ボタンなんてないぞ」、と言ってるような爺さんのネタがあるけど。
あれは誇張でもなんでもなくて、ああいう次元でITがピンと来ない人は実際山ほどいるわけで、そしてそういう極端な人を除けば後は均質に使いこなせる人かというと当然そうではなくて、PC起動くらいはできるけどローカルアプリだけでネットを使いこなせない人とか、メールはできるけどWebは無理な人とか、使いこなせるレベルはあらゆるレベルがおだやかに分布するわけです。
そういう人達との間には、情報なしにはいくら考えても判らない、多分いくら考えても判るのは「判らない」ということだけ、という「馬鹿の壁」があるわけで、そういうところをメインに訴求するようなインタフェースを考えようと思うと、もうこれはリサーチするしかないのではないかなと。
Googleなんかは、技術の最先端を走っていかなければいけないわけだし、また全世界で最大公約数なサービスを展開しないといけない、ということもあって、Google Mapsみたいな形以外は取りようがないだろう。
「少子高齢化」が進んで、団塊の世代が大量の金を持って大量の余暇を持て余して世に溢れる、というような現象への対応は、日本ローカルな日本の会社しかしようがないわけだし、そんな中でみんながみんなGoogleを追いかける必要はないんじゃないかと思う。
今後増えてくる、さらに冒頭のリサーチのように地図や交通等の情報への訴求が強いという年配層に対し、マーケティングするような地図サービスがあってもいいのではないか。
もちろん、今後確実に増えてくるとはいえまだ年配の層はネット人口の中では少数派だろうし、飽くまで多数派の若年層に訴求する形だけを追求していきますよ、という考え方もあるだろうし、むしろセグメントを分けて住み分けた方がみんなハッピーになれるんじゃないかという気もする。
SoftBank位置情報取得記事の間違いと、オープンiエリアモジュールのアップデート
以前公開したWeb2.0ワークショップの携帯位置情報取得に関する資料に、一部間違いがあったようです。
ここギコ！で公開されている資料を参考にしながら開発を行いました。有用な情報をありがとうございます。ただ、一部間違いがあったので、情報を共有しておこうと思います。
・SoftBank 3G 簡易位置情取得の未対応機種に誤植
V801SA, V801SH, V702MO, V702sMO, V702NK, V802N, VC701SI
正しくは、以上の7機種です（V801SH が V801SA になってました）。
・SoftBank 3G の位置情報取得方法に誤り
location:cell?url=[送り先URL]
正しくは、上記のリンク方法です。他のページでも間違えているところが多いです。オフィシャルで公開されているウェブコンテンツ開発ガイド（HTML 編）の P.72 に正しい記載がありました。
cell 以外に gps と auto を指定することが出来ます。
・SoftBank 3G の測位精度のパラメータ名に誤り
X-acc では無く x-acr です。
情報ありがとうございます。
言い訳ですが、実は昔からある位置情報取得手段は過去遊びまくったので詳しいのですが、一線から引いた後に出てきた仕様（FOMA用GPS、SoftBank 3Gの位置取得）に関しては自分で使った経験はないので、あのワークショップのために自分でも勉強したという状況でして...。
一部使ったことがない仕様があっても、全体として異なる仕様を相互運用するためのノウハウとかは話せる種になるかなと思ってお引き受けしたのですが、間違いがありましたか...すみませんでした。
多くのサービスで、オープン i エリアのエリア情報からデータを引っ張ってこれるところを見ると、座標からエリアコードを引く関数を作ったほうが良さそう。既に実装しているところはあるのかな？メッシュデータを見ながら独自実装か…。
これに関しましては、Perlでよろしければ拙作のLocation::Area::DoCoMo::iAreaというのがあります。
ただ、こちら、2004年にバージョン2.02を出してから、データのアップデートを怠ってきたのですが...（そのためにWeb2.0ワークショップでも紹介せず）。
ちょうど最近、アイデアマンズ株式会社というところの宮永さんが、データのアップデートを申し出て下さいまして、代わりにアップデートしてくださったので、本日バージョン2.1として更新しました（宮永さん、ありがとう！）。
DoCoMoリリースの2007年2月20日データに対応している事を確認しています。
よろしければ使ってみてくださいませ。
こちらの方、宮永さんはモジュールのアップデートだけでなく、公開情報から自動的にモジュール全体をアップデートするスクリプトも送付下さったのですが、モジュールの方は公開許可いただいているのですが自動更新スクリプトの方は確認できていません。
一応確認取った後、OKであれば、次の版でこちらも公開したいと思います。
また今回の更新で、テストスクリプトのみ新データ向けのを用意できなかったので、一時的にmake testの時のテストがインポートのテストだけになってます。
これもできるだけ早くテストスクリプト更新の後、次の版で盛り込みたいと思います。
テレビで流れている情報の詳細を携帯で受け取れるサービス「T-メモ」
昭文社系の動きを知りたくて久々にBitPetsのリビット社のサイトを覗いてみたら、面白そうなサービスのリリースが！
テレビ番組を楽しみながら、欲しい情報は携帯電話へ。
携帯とテレビ番組・ＣＭを連動させるクロスメディア型システム「T-メモ」を開発
これまで、視聴者が見ている番組中に紹介されているお店や商品に関する情報を得るためには、自らメモを取るか、インターネットなどにアクセスすることが必要でした。「Ｔ-メモ」は、予めシステムに登録をした視聴者が、自分にとって興味ある情報が紹介された時に携帯電話の画面を一回クリックすると、その数分後にはクリックしたタイミングにオンエアされていた番組内容に関する情報が載せられたメールが送られてくる仕組み。テレビ視聴時に最も利用しやすい通信メディアである携帯電話との連動によって、番組視聴を妨げることなく、必要な情報やクーポンなどのお得な情報も手に入れることができるシステムです。
これは面白そう。
見ている番組に対する詳細情報をリアルタイムに受け取る事自体は地デジ放送等でもできるわけですが、地デジが普及するまでに同様の事を実現するまでの手段として有効そうです。
それに地デジだと、見ている画面上に色々表示させて操作しないといけないので鬱陶しいのに対し、テレビ視聴中にもてあそぶ事も多いケータイを使っての簡単1クリック操作なら、テレビに集中しながらでも操作できそう。
さらに、普段持ち歩くケータイ、という特性を活かして、地デジ放送では難しいクーポンの配信等も簡単にできちゃうということですか。
gコンテンツなんかの位置情報で「今いる、まさにココ」の情報が欲しいというのが空間的なコンテクスト活用の動きだとすると、これなんかは「まさに今」の情報を得るという、時間的なコンテクストを活用しようという発想なわけですね。
考えてみれば、純粋で普遍的な「位置」の情報（この場所の歴史とか、地名とか）や、「位置」と「時間」のカップリング（今この場所で営業している店とか、タイムセール情報とか）の活用はよく議論されるけど、純粋で普遍的な「時間」の情報（だってテレビ番組は電波が届く限りは何処にいようが同じ時間は同じものが見られるわけなので）を活用しようという発想はあまりなかったような気がする。
ちょっと楽しみなサービスです。
チャットのユーザインタフェースにあるといいなと思ったこと
手の病気持ちなので早打ちが辛い事もあり、普段IRCとかやらない人なのですが、遠隔の人と調整しつつサーバの設定をやらないといけない用事があって、実に久しぶりにチャットというものをやりました。
んで思ったんですが、自分が連絡事項をまとめつつ書いている間に、相手から簡単に答えられる問い合わせなんかが来た時、そっちにすばやく答えるために書きかけの自分の連絡事項を全切り取り→すばやく返答→貼り付けで元の書きかけ内容復活、という事を何度かやったのだけど、これがウザイ。
自分のメッセージを書き込める入力ボックスが、複数あったらよかったのに、と思った。
常に、一つの発言が書きかけでも、別の入力ボックスにさっと書き込むと、軽い発言ができるという形。
それも2つ固定ではなく、そういう応酬って入れ子になって多段になる可能性だってあると思うので、今書きかけてる発言の数より一つ多い分、動的に入力ボックスが増える（発言が完了すれば1個減る）ような感じで。
どうなんだろう。
みんなそんなふうに思わないのかな。
みんなつべこべいう前に自分の意見を書いてしまえるほどキータイプが神速だからいいのか。
でも、ニーズはあるように思うんだけどなあ。
あと、どれがどの発言に対する返答かが判りにくくなるのも、イマイチ感を感じる。
もちろん、チャットなんだから音声でのリアルなやり取りと同様、多少混乱するくらいの方が面白いのかもしれないけど。
でも混乱するのが面白いのと、混乱すべきでないやり取りでまでも混乱させない経路が用意されていないのとはまた別の話で。
例えばチャット画面上の発言をドラッグして、自分の発言ボックスにドロップすればその発言に対するレスポンスとして、明確にできるようなインタフェースがあったらいいかなと思った。
2007年02月24日
ゾロ目
本日のブログランキングの順位。
やは、めでたい。
CとPerlでCGI、FastCGIのベンチマークを取ってみました
たたみラボさんのかなり古いエントリなのですが、
GDなどの外部ライブラリを使わずに、全部Cで書いているCGIです。なのでたぶん高速。よく「ＣＧＩはプロセスが毎回立ち上がるから遅い」なんてことが言われますが、プロセスそのものが小さければ速いはず。だったらCで書けばいい。
とあったので、ちょっと試してみました。
前々職の同僚が「FastCGI馬鹿一代！」という感じの職人然とした人で、常々「CのCGIよりLightweight LanguageのFastCGIの方が速い！」と叩き込まれてきたので...。
条件は、環境変数の一覧を表示するだけのCとPerlのページを、CGI及びFastCGIで動かしてみて、Apache Benchで100回リクエストして比較してみました。
結果は、
| C-CGI | C-FastCGI | Perl-CGI | Perl-FastCGI | |
|
100回試行にかかる時間 |
3.47秒 | 0.24秒 | 5.28秒 | 0.29秒 |
| 秒あたり実行可能回数 | 28.8回 | 421.9回 | 19.9回 | 350.5回 |
という感じになりました。
やっぱり、プロセスを常駐させた方が大分早いようです。
CGIでのCとPerlの実行速度差に比べ、PerlのFastCGIがCのFastCGIと比べて遜色ないのは、Perlはプロセス起動時に中間コードにコンパイルされるらしいのですが、FastCGIだとその中間コードがプロセスが落ちないため保持されるので、リクエスト毎のコンパイル時間が不要になるためらしいです。
FastCGI職人からの聞きかじりですが...。
C-CGIとPerl-FastCGIの間の比較は、所詮環境変数表示だけのプログラムですので、複雑なプログラムになると実ロジック部分のCとPerlの実行速度差でどうなるかは判りませんが、今回は環境変数表示だけのプログラムでの結果なので、プロセスは小さいんじゃないかと思います。
なので、プロセスが小さければCGIでも...というのは、？がつきました。
（とか書きつつ、元記事の意図するところが、元々プロセスの小さいプログラム同士の比較ではなく、「同じ機能」のプログラムなら、外部ライブラリ等を使わずCで書いた方がプロセスは小さくなる、という意味かもしれないと今書きながら思った。環境変数表示みたいな差の出ようのないプログラムならともかく、ある程度のロジックがあれば確かに作り方によって劇的にプロセスのサイズ差は出るかもしれませんね...。）
Apache Benchの生出力は、追記に。
Continue readingURLをQRコードに変換するブックマークレット
表題のものを、以前どこかの方が作られていて、ブックマークレットに登録して使っていたんだけど、今日QRコードを作ろうと思って使ってみるとサービスがなくなってた。
それで似たような事やっているとこないか探してみたら、たたみラボさんが公開してた。
今開いているURLをQRコードに変換するブックマークレット -たたみラボ-
PCでもケータイでも同じURLで見れるようなサービスは多いので、PCからケータイにURLを送る機会は多いです。私はメールで送っていましたが、それだけのためにメールで送るのもバカらしいので、QRコードで直接ケータイに教えるというツールにしてみました。
さっそくブックマークレットに登録して使わせてもらいました。
こういうちょこっとしたツールを公開してくれるところは、ありがたいなあ。
あ、そうそう、たたみラボさんは研究員を募集中です。
いろいろ面白いことを自由にやってみたい！と言う方は、応募されてはいかがでしょうか。
私もたたみラボさんとはいろいろ交流があるので、OSGeoのカンファレンス等でまたお会いしませう。
YahooからREST形式でのジオコーダAPI
ローカルサーチWebサービスでは、キーワード検索、周辺検索の機能を提供します。キーワード検索は、住所・郵便番号・施設を指定して、その位置情報（緯度、経度）を出力します。周辺検索は、位置情報（緯度経度）、範囲を指定すると、その範囲内に含まれる施設情報を出力します。
http://developer.yahoo.co.jp/map/localsearch/V1/localsearch.html
という形のようですが、Google Mapsのジオコーダは公式にはJavaScriptベースのはずなので（もちろん、とっくにHACKされてますが）、サーバサイドではYahooの利用がメインになっていくのでしょうか。
恒例の市谷検索。
「北斗市 谷好」や「市谷柳町」とかはひっかからないので、
- 行政界の区切りをまたいではひっかけない
- 行政界区分と完全一致しないとひっかけない
というタイプのようで挙動としてはMapFanのジオコーダに近い感じでしょうか。
でもMapFanでひっかかる地名がひっかからないのは、データの網羅度の違い？
また住所だけでなく、ランドマークも返してくれるというのは面白いですね。
経緯度値としても、旧日本測地系と世界測地系両方返してくれるのは気が利いていていい感じです。
モバイル対応地図サイト2題：アルプラボRouteモバイル版、ケータイグーグルマップ
ケータイマニアで位置マニアな私としては嬉しいケータイ位置情報サイトが複数立ち上がってきました。
まずはALPSLABのにのっちさんとこ。
ALPSLAB routeがモバイル対応 -ドナドナ日記-
今まではPC上で完結してましたが、ルートを作る or 探す→携帯に送る→現地で確認が可能になりますた。
携帯からコマ送りでルートを確認できるのでとっても便利。
確かにこれは便利かも。
現地で確認できなかったので、これまでALPSLAB routeというと過去の記録的な要素が強かったと思うのですが、これで未来検索？→現地で確認、という用途も出てきたという事ですね。
面白いです。
とりあえず、W41Hでは動きましたよー、というご報告。
続いて、こっちもお友達ですが、Digital Life Innovatorさんのところで、Google Maps画像を利用したDoCoMoケータイ向けのモバイル地図サイトを公開されました。
ケータイグーグルマップ？ -Digital Life Innovator-
いまさらながら、こんなエントリーに気が付いたので、ドコモケータイ用グーグルマップを試作してみました。
（Googleモバイルローカル検索は検索対象を入力しないといけないので地図として使いにくいので・・）
使用しているGoogleのURLが公開インターフェースではないので、あくまでも個人用のテストということで。
Googleモバイルローカル検索が地図サイトとして使いにくいのは同意です。
自動で位置を取れるのは、DoCoMoのGPSとオープンiエリアに限られますが、地図の移動・拡縮とジオコーディングは他キャリアでも使えそうです（少なくとも私のW41Hではおk）。
面白いのは、地図上に1個だけですがマーカーを置くと言うインタフェースがあること。
とりあえず興味持ったところにマークしておく→他の場所を探して中心に持ってくる→地図を拡大してマーカーも画面内に入るようにする→中心とマーカー間の距離感を掴む、といった使い方が考えられるかも。
先輩ー、こっちも近々ケータイGoogle Maps画像使いそうなので、ピクセル毎の経緯度シフトパラメータ教えてくださいー。
自分でやろうと思いつつ全然手をつけてないです...。
2007年02月19日
アルプスラボがロカポ対応
GreaseMonkeyスクリプトの記事でも少し触れましたが、アルプスラボさんのアルプスラボ・ベースでロカポによる検索ができるようになりました。
方法は簡単。ロカポを入力して『移動』ボタンを押すと、ロカポが指す目的地へ移動します。
とのことです。
アルプスラボさんやってくれました！ありがとう！
Web上のテキストボックスでの入力からの対応のみで、Permalink的な記述はできないようなのでリンクを貼って等によるサンプルが示せないのですが、例えばアルプスラボに行って、「SD9.XC6.JL1.NP1」というような文字列をテキストボックスに入れ、「移動」ボタンを押して見て下さい。
今日息子と遊びに行った、葛西の地下鉄博物館の場所に移動します。
また、上の引用記事中でも触れられていますが、Firefox向けのロカポGreasemonkeyスクリプトも登場したみたいで、これをGreasemonkeyにインストールすると、Google Maps及びアルプスラボベースを表示した際、画面上に地図中心点のロカポが表示されるようになります。
またGoogle Mapsでは検索窓にロカポを入れると、そこに移動できるようになる他、一般サイトでも、ページ中にロカポが含まれていると、自動でGoogle Mapsやアルプスラボベースへのリンクが貼られるようにもなるようです。
Continue reading2007年02月18日
小学校の算数もできません
知人からA4で2枚くらいの原稿を頼まれていたのですが、1600字×2枚と頼まれてて、何をトチ狂ったか6400字×2枚書いてました。
1600＝40×40だよ！
40×160じゃないよ！
同時に頼まれてた別の知人から挙がってきた原稿が、自分のと比べてやけに短かかったのでおかしいなと思って発覚しました。
原稿を短くするのはムリクリ話題を伸ばしてた感じだったのですぐできたのですが、長い原稿書くために2週間近く余分な時間を費やしたのがちょっとショックデカス。
2007年02月17日
3D地図と回転2D地図の連携を「勝手に」実験
PCでグリグリもいいですが、全体を俯瞰する2Dの地図と違い、現場の視点から見る3Dの地図はやっぱり携帯機器から見れて力を発揮すると思うので、ぜひ携帯で使えるようにして欲しいです。
携帯の地図サイトで方角をナビゲートする場合、よくある方法は昔ここギコ携帯版でも採用していた、太陽や月の出ている方向をサイト上に表示して、その方向に携帯の向きを合わせると方角が判る、というものですが、3D地図が使えるとなると、風景から方角が読み取れるようになるのでよいですね。
と書きましたが、早速携帯で見られるようになるみたいです。
マピオンの携帯向け地図サイトで3D地図の実験 -ケータイWatch-
サイバーマップ・ジャパンは、キャドセンターと協力し、携帯電話で3D地図が利用できるサービスの実験を2月末にも開始する。
.........
実験では、3D地図の需要そのものを探るほか、待ち合わせで使用した際のレポートなどを受け付ける。対象エリアは銀座、渋谷、新宿、品川駅構内の一部で、半年間をかけて公開されていく予定。
楽しみです。
とはいえ、私は前の記事で、
というか、3D地図は方向の把握が直感的だけど2Dは全体が俯瞰できるので、相互補完できるといい。
その意味では、北ではなく3D画像の表示されている方向を上にして表示できるように、地図を回転させてリアルタイムレンダリングしてくれるような2D地図のインタフェースもあってもいいかもですね。
と書いたけど、PC版のMapion LABSを見ても2D地図の方は回転してないので、とりあえずは北が上の2D地図との連携になりそうな雰囲気ですね。
地図屋の知人に聞いても、回転する地図は地物のキャプションをどう重ならないように配置するかとかのロジックの難しさもあるので、中々難しいとの話なのですが、でもやっぱり動物的直感に訴える度合いが違うと思うので、やっぱいつかは対応して欲しいなあ。
とか書きつつ、「動物的直感に訴える度合いが違うと思う」だけでは実証的でないので、勝手に実証実験してみました。
回転する地図というと...ALPSLAB Designにそんなのがあったなあ、ということで、勝手にMapion LABSの3D画像とALPSLAB Designの回転地図をマッシュアップ。
と言っても、回転地図の画像を方向を変える度に呼んでいるだけで、先読みとかしてないので全然なめらかじゃないとは思いますが...。
負荷とかいろいろ問題になっても困るので、画像は小さくしてかつ、制限時間を20秒だけにしてみました。
どんな感じでしょうか...個人的にはやっぱり静止2D画像上で矢印が回転するよりは、判り易い気がずるのですが...。
---- 追記 -----
ローカルだとIEでも動いているのですが、どうしてもアップロードするとIEで動いてくれません。
仕方ないのでとりあえずfirefoxかOpera限定です。
テストの簡単化のため別ページに分けたので、そちらで見てください。
インクリメントPが新サービスBloca!を開始
インクリメントPさんが新しいブログパーツサービスを始められました。
Bloca! blog + location + local
Bloca!で“ロカ”っちゃお！
Bloca!（プロッカ）は、ブログでの情報発信や入手を「地図」を使って支援します。
- 簡単な操作でブログの記事に地図を表示できる！
- 昔書いた記事でも、おすすめしたいタイミングで表示できる！
- 場所やテーマを設定して簡単に情報交換・共有できる！
という形で、発信したい位置情報をBloca!に登録すると、その情報をBlog等に張り付け可能になる他、独立してその情報に関する情報交換の掲示板が用意される等、位置情報ベースの情報交換が活発にするサービスのようです。
単純に位置をベースに無料でブログに地図を配信する、というサービスは増えていますが、あえて逆に、地図配信サーバ側でその位置に関するリッチなメタデータを管理することにより新しいサービスを提供しようというのがミソのようです。
たとえば、登録するデータの中に「おすすめのタイミング！」というのがあって、シーズンや時間帯、天気等を設定できるのですが、具体的にどう動作するのかはまだよく判らないのですけど、過去にエントリした情報でも、日時や天気予報等その「おすすめのタイミング」に一致する条件になれば、ブログに貼るブログパーツの中で上位に紹介される、とかそういう仕掛けがあるのだと思います。
これまでのブログへの地図配信サービスだと、位置ベースでは情報が集約できても、古い情報は埋もれていってしまい、といった問題があったと思いますが、Bloca!だとそういう心配がなく、必要な情報が必要なタイミングにちゃんと挙がってくる、その意味では「位置情報」だけではなく「時間情報」「天気情報」といった切り口でも情報を管理しようという、大胆な試みに思います。
ただその分、情報を登録する手順がややこしい。
地図を配信するだけのブログ地図貼り付けサービスならば、モブログ等でEXIF付き画像が投稿されれば自動で地図画像へのリンクを作るブログのプラグイン、なんてのも出来たわけなのですが、Bloca!ではとにかくとりあえずBloca!にログインして、メタ情報を手入力しないといけない。
さらにBloca!に情報を登録した後、Blogの記事と紐付けるには、Blog記事からトラックバックを打たなければならない。
これはなかなか大変な手順。
もちろん、豊富なメタ情報を持つ以上、手順が煩雑になるのは当然で仕方がないわけなのだけど、もう何工夫かは可能だと思う。
Bloca!のシールをAtom APIで作れるような口を設けておくとか、そのAPIを使って、独自定義した「タグ」にメタデータを入れた投稿をするだけで、そこから情報を抜き取ってBloca!にエントリし、自動でブログエントリからBloca!エントリにトラックバックを打ってくれるようなMovableTypeプラグインを作るとか。
一方で、地図だけではないメタデータをサービス側で持つのは、うまくいけば強い立場に立てるかもしれないとも思った。
他社の地図だけ配信サービスとかだと、極端な話別地図に置き換えも可能なわけです。
Google Mapsの地図が貼ってあっても、Alpsラボの地図の方が好きだと思うユーザがいれば、経緯度だけ盗んで張り替えてしまうGreasemonkeyスクリプトとか作ろうと思えば作れてしまうわけです（私ができるといっているわけではないぞ）。
でも、こういうメタデータをサービス側が持つアプローチであれば、やはり地図画像自体は置き換えられてしまうかもしれませんが、付随する重要なメタデータの管理はサービス提供者側が押さえる事が出来て、インクリメントPのサービスを使わなければ、という訴求力を持つ可能性があります。
成功するか失敗するか判りませんが、面白い試みだと思います。
というわけで、私も早速使ってみました。
最近飲みに言っておいしかった飲み屋の情報をペタリ。
（タダで飲ませてもらった飲み屋の情報を、ライバル会社のサービスを使って紹介するのもどうかと思うが...まあ私人としては不偏不党ということで）
|
古木酒家 ななころび 八段屋
グランドパレス向かいのビル2階。刺身や海鮮サラダ等の海鮮料理が新鮮かつ山盛りで出てきておいしい! どこかの漁船と契約して魚を入れてるとか聞いた。ビールも陶器ジョッキで、泡がクリーミー。
|
||
|
|
||
|
TEL：03-3512-3688
営業時間：11:30?14:00 17:30?23:30(L.O.22:30) 定休日 土・日・祝
アクセス：
|
||
|
ついでながら、インクリメントPさんは同時期に別のサービスも投入されています。
まだ私は試していないのでどんなものか判りませんが、ご紹介まで。
Amazon EC2をWebから制御するインタフェース
Amazon EC2をWebから制御するインタフェースが作られていました。
Amazon EC2を簡単操作するWebインターフェース -Webプログラミング日記-
超便利なので使わせてもらってます。
とりあえず使ってみて、追加で欲しい機能は
- S3からEC2へイメージへアップロードする機能
- EC2からイメージを削除する機能
- 削除されたイメージはイメージ一覧に表示しない
くらいで、それだけできればクライアントサイドのコマンド全くいらなくなりどこからでも制御できるので嬉しい。
簡単なスクリプトで自分でも直せそうなので、ぼちぼち改造しようかなと思います。
静的ファイルをAmazon S3に移しました
コンテンツ保護の観点から、データベースのバックアップはやってるんですが、増える静的ファイルをどうしようかなとか思ってて、かねてよりサーバをRAID化したいなとか思いつつ金がなくてやれてなかったのですが。
そうこうするうちAmazon S3が出てきたので、なんなら静的ファイルみんなS3に移すかと思って、そうすることにしました。
とりあえず、各エントリに帰属する画像ファイル系は、定型のフォルダに入れていたのでMTの置換機能で簡単に変換できたので移行済み。
不定型な置き方をしているファイルについては、ぼちぼち移していきます。
ついでに今後のエントリが楽になるよう、MT::XMLRPCServerを書き換えて、metaWeblog.newMediaObjectが叩かれた際にS3にアップするようにしました。
S3を処理するのに、Net::Amazon::S3が難しそうだったので尻込みしていたら、AWSのデベロッパーサイトに使いやすいS3のラッパーモジュールが落ちていたのでそっちを使いました。
MTプラグイン化して公開できればよかったのですが、汎用化するにはMT::XMLRPCServerの書き換えだけでなく、MTのWebインタフェースからも使えるようMT::FileMgr::S3とか作った方がよさそうだし（私個人はMTのWebインタフェース使わないので今は無視してる）、APIUploadFileコールバックをどうするかも考えないといけなさそうだし（私は使ってないので以下略）、どうも私には敷居が高そうなのでWrite Many CodeなGeek連中に任せてw、スーツはスーツの分を守るとします。
ついでにアップロードのテスト。
2007年02月10日
日本原作の韓国ゲーム記事...別に朴李問題ではないでしょう
「ガンダム」の場合、日本で誕生した「ガンダム」のキャラクタを利用したゲームではあっても、「ガンダム」というキャラクタはもはやグローバル化されているキャラクタであるうえ、韓国の開発会社が（韓国）国内サービスに向けて開発中であるため、日本（“日流”ブーム）とは関係がないし、『Ysオンライン』も単にオンライン化しただけではなく、『イース』の代表的キャラクタである「アドル」も登場しないし、世界観は反映したが、日本版の『イース』とは全く関係がないと主張している。
また別のゲーム業界の関係者は、「“しんのすけ”というキャラクターを使ってゲームを作るからといって、日本のゲームではないのと同じように、現在オンラインゲームとして開発中である『Ysオンライン』や『ガンダム』も日本のゲームとは言い切れない。最近、韓国内のオンラインゲーム市場が低迷している状況の中で、“日流”という言葉を使って注目を集めようとするのは正しくない。」とコメントした。
上記だけ読んで、テコンV＝マジンガーZ、みたいな過去の作品はともかく、ガンダムやY'sみたいなリアルタイムでビッグネームな作品までパクられたのか？その上開き直ってるのか？と思ってびっくりしたが。
元記事読んでみると、ちゃんと版権払って提携して作ってる作品じゃないですか。
すっげえ恣意的な引用してるな...おまけにそれに載ってレスしてる連中もイタイ。
ちゃんと版権払って作成してる事前提で元記事通読すれば、ある意味一理ある主張してると思うけど？
要するに、元々日本発だが既に認知度がグローバル化しているキャラクターを使って、外国人が新たな独自ストーリーの作品を（ちゃんと著作権問題はクリアした上で）作ったとして、「その作品」が新たなブームを引き起こした場合、それを「日本ブーム」と呼ぶのが正しいか？という意見であって、別に議論はあるものの一理はある話だと思うけど？
同じような構図は「ファイナルファンタジー」、「ゴジラ」、「エヴァンゲリオン」「DEAD OR ALIVE」あたりの、日本発のキャラクターを使った映画作品をハリウッドが作っているといったあたりに見えるけど、それらの作品が新たなブームを巻き起こしたとして、「その作品（原作ではなく、その作品）が新たにブームになった」という事象を取り上げて「日本ブーム」と言ってよいかどうかは、議論の余地があると思うけど。
それと同じ構図の話であって、「パクり論理だ」とか何とか非難する類のものではない。
別の、逆に日本側がリスペクトする側の立場で考えた場合、例えばアメリカのマーヴルコミック系のキャラクターを使ってカプコンが格闘ゲームをいくつか出しているけど、それを取り上げて「日本でアメリカブーム」というような論調が出るのはどうよ、というようなのと同じ話。
あるいはもっと別の例で言うなら、同人誌（なので著作権はクリアしてないが）で「ドラえもん最終話」が出てすごい話題を呼んでいるけど、あれを持って「藤子不二雄、再ブーム！」とか言ったらおかしいだろう、的な。
引用も恣意的にすると簡単に情報操作・世論誘導できちゃうよな、という好例でした。
「市谷」で各社ジオコーダの特徴を見てみる
前の仕事で色々お世話になった場所「市谷」ですが、ジオコーディング的には色々難しい地名みたいです。
というのは、単純に都道府県から地番までの全住所列を対象に検索すると、「北斗市 谷好１丁目」なんていう行政区分の区切りでたまたま「市」「谷」が並んだところまでひっかけてしまうからです。
というわけで、各社のジオコーダで「市谷」を検索して、挙動を比較してみました。
とりあえずこの条件で実際にやってみた結果を示すだけで、各社それぞれ得意不得意はあると思うのでこの結果だけでどこの性能がいいとか悪いとか言えるわけではありませんし、そのような事を主張する意図もありませんが、とりあえずいろいろ精進してくださいねということで。
試してみて、一番望み通りの結果を返してくれたのが「ちず丸」。
東京の「市谷柳町」等の一連の市谷周辺の町名も全部引っ掛けてくれると共に、「石川県河北郡津幡町市谷」等の東京外の市谷も全部見つけてくれている。
それでいて、「北斗市 谷好１丁目」みたいなのは引っ掛けない。
とりあえず「市谷」に関しては、一番理想の挙動を示してくれた感じです。
ちょっと慎重過ぎ？なのが「MapFan」。
行政区分の区切りは引っ掛けないのですが、「市谷」と完全一致するところしか引っ掛けてくれないようです。
だから東京の「市谷柳町」とかは一切ひっかからない。
livedoor地図は明らかにMapFanのエンジン使ってるだけっぽいからスルー。
逆に奔放wなのが「goo地図」と「Mapion（引っ掛かった量が多すぎて全国だと表示できないので、数県分に絞っています）」、「ZENRINいつもガイド」。
見事に「北斗市 谷好１丁目」みたいなのを引っ掛けてしまっています。
どちらにしろちょっと困った感じなのですが、どっちがマシ？かというと、「北斗市 谷好」しか引っ掛けないgoo・ZENRINの方が、「北斗市 谷好1丁目」「...2丁目」「...3丁目」全部漏れなくついてくるMapionよりはスッキリしてるかな。
何だか意味が判らないのが「Yahoo!地図」。
東京の「市谷なんとか町」あたりは一切引っ掛からないわりに、表記の異なる「京都府福知山市長田(市の谷)」「福島県南相馬市小高区角部内(字市ノ谷)」とか引っ掛けてたりする。
一番意味が判らないのは、1件だけ、「千葉県袖ヶ浦市 谷中」みたいな行政区分の区切りも引っ掛けてしまっている事。
どんなロジックでやってるのだろう？と逆に不思議になります。
「Google Maps」はある意味スゴイ。
いくつか候補が考えうるであろう「市谷」というクエリに対し、ずばり1箇所「鳥取県八頭郡八頭町市谷」という結果だけを返してきます。
他の選択肢はなし、「Google様が市谷といえばここと決めたんだ、つべこべ言うな！」みたいな感じで面白いです。
ただ、他の選択肢が出てこないので行政区分の区切りを引っ掛けるかはこれだけじゃ判らなかったんですが、「北斗市 谷好１丁目」の「市谷好」で検索しても結果が出てこないので、行政界区切りでの処理はできているようです。
とまあ、主要どころはこんな感じでした。
他にも「ヶ」や「ッ」の扱いとか、いろいろジオコーダにかけると面白い地名はあるのですが、今回はこの辺で。
MicrosoftがOpenID対応を確約--ついにHTTPの上に新たな「認証」レイヤが登場する
米国マイクロソフトの会長兼チーフ・ソフトウェア・アーキテクト、ビル・ゲイツ氏と最高研究戦略責任者クレイグ・マンディ氏は2月6日、カリフォルニア州サンフランシスコで開催された「RSA Conference 2007」で、Web認証の新規格「OpenID」を同社が全面的にサポートすることを明らかにした。
OpenIDとは、URLを識別アカウントとするユーザー識別の新規格だ。すでにマイクロソフトは、Windows Vistaに搭載されている認証管理機能「CardSpace」にOpenIDを統合している。
.........
ゲイツ氏は「パスワードのみの認証は脆弱なだけでなく、管理するパスワードの数が増えるほど手に負えなくなるという問題も抱えている。これからはCardSpaceとOpenIDでセキュリティを確保するべきだ」と語った。
OpenID-jaの重田さんの投稿でも紹介されました、英語の元記事はこちら。
いやあ、ついに来ましたねえ。
以前書いたようにFirefox 3.0もOpenID対応の予定であるし、本当に「今、PC初心者でもメールソフトにメールアドレスを登録するように、ブラウザに認証IDを簡単に登録して、意識しなくてもセキュアに認証されたWebページを見られる」時代が来るようです。
そのうち「できる！OpenID」なんて本も出るかもしれませんね。
そして、誰でも意識せずに簡単に認証されるインフラが整うという事は、事実上HTTPの上にもう一つ認証レイヤが載ったのと同じことになります。
これまでは、同じURLならば誰が見ても同じ内容が出てくるのがWebの世界でしたが（サイトにID/PWでログインしていたり、サイト側に強制的にクッキーを食べさせられたりした場合は除く）、これからはあなたの友人があなたのブログページを訪れれば友人向けの記事が、同僚が訪れれば同僚用の記事が、家族が訪れれば家族用の記事が出せるようにもなるでしょう。
ちょうど、今、MixiのようなSNSやVoXで実現できているようなコンテンツの流通制御が、インターネットの至る所で出来るようになります。
また、面白い時代になりそうな感じがします。
2007年02月07日
検索キーワードの検索されやすさを比較できるGoogle Trends
Googleがラボでベータ公開しているサービスの中に、Google Trendsというのがある。
GIGAZINEでも紹介されているが、Googleで検索されたある検索キーワードの、検索回数のトレンド（ただし絶対量は判らない）と、トレンドがピークを示した時に、その検索ワードに関わるどんなニュースがあったかを確認できるサービスだ。
例えば上の例では、WiiとPS3という検索キーワードでの検索数の比較、及び各ピークでの話題となったニュースの表示を行っている。
こんな感じで調査できるGoogle Trendsだけど、残念ながら日本のニュースには対応していないので、日本語ワードの場合は単に検索された回数のトレンドを見られるだけのツールになってしまっている。
回数の絶対数が判らない事もあり、特にそれ以上の使い道はないかなと思っていたんだけど。
よく考えたらこれって、絶対量は判らなくても相対量の比較は出来るので、自分のサイトを検索キーワードに対し最適化（いわゆるSEO）しようとした場合に、似たような検索キーワードのどちらで最適化するかという比較に使えますね。
別に何でもキーワードとして、metaタグに突っ込めばいいのかもしれないけど、あまりキーワードを突っ込みすぎるとSPAM行為とみなされて八分られることもあるみたいなので、慎重に選びたい場合なんかに重宝するかもしれない。
たとえば、自分のサイトが飲み屋の宣伝Webページだったとして。
どんな検索ワードで検索してくるユーザに対して最適化したいかを考える際に、「宴会」か「飲み会」のどちらで最適化するのか、或いは両方盛り込むのか、ということを判断するような場合。
この2つのキーワードを、単純にGoogleでググってみると、「宴会」でひっかかるページは499万件、かたや「飲み会」でひっかかるページは327万件。
サイト側で使われる度合いとしては一応「宴会」の方が多いものの、オーダーは同じレベルの値である。
これをもって、「『宴会』の方が多いみたいだけど、この差なら『飲み会』で検索する人も取りこぼしたくないなあ」と判断してしまうと、大きな間違いになる。
実際にどちらの検索キーワードで検索する人が多いかをGoogle Trendsで比較すると、
圧倒的に「宴会」での検索が多く、「飲み会」での検索はほとんど存在しない事がわかる。
この事から、最適化する検索キーワードとして想定するのは「宴会」だけでよく、「飲み会」に関しては考慮しなくてもいいことが判る。
こんな感じで、最適化すべき検索キーワードの剪定にGoogle Trendsが使えるのではないかと思いました。
2007年02月06日
SVGMapコンソーシアム設立、SVG Toolkit開発開始
YRPの高木先生から、SVGに関する新しい動きの情報をいただきました。
本コンソーシアムでは、SVGのビジネスおよび社会基盤に対する有用性の研究、SVGを活用したアプリケーション開発及びシステム構築の普及促進、 SVGコンテンツを活用した流通基盤整備及びシステム構築の普及促進、SVGに関する情報の収集、交換ならびに提供、SVGの情報を集約したポータルの構築、国内外の他コンソーシアムとの連携協力、さらにW3C SVG・MWI・GeoXG、 PlaceXML JIS化、ISO TC211等の国内・国際標準化活動への貢献等、「SVGを利活用するための電子地図表示ソフトウェア及びSVG形式の地図配信基盤提供サービス」の供給に関する問題を解決し、WWWにおける空間情報アプリケーションの導入容易性をもたらすことを目的としています。
また本コンソーシアムを通じて、「SVGを利活用するための電子地図表示ソフトウェア及びSVG形式の地図配信基盤提供サービス」の市場を開拓し、コンソーシアム参加企業が持つそれぞれの強みを活かしながら、高い信頼性と品質のソリューションサービスを提供することを目標にしていきます。
「SVG Toolkitの開発」が財団法人日本情報処理開発協会事業で採択
SVGMapコンソーシアムでは、本提案の「SVG Toolkitの開発」により、「SVGを利活用するための電子地図表示ソフトウェア」の開発を行うことで、WWWにおける空間情報アプリケーションの導入容易性を実現させることを目指しています。また、gコンテンツ流通促進のため経済産業省でJIS化を推進しているPlaceXML（多様なWWWコンテンツを高度な相互運用性のもとでgコンテンツ化するためのメタ情報仕様）への対応を見据えた拡張を他に先駆けて行うことで、これらgコンテンツを活用した、より高次の時空間情報サービスの実現を促すことを目指します。
Google Mapsの登場以来、Webで地図を扱うことや位置情報を扱うことは当たり前になり、またGoogle Mapsに触発された様々な同種のサービスも数々出ておりますが、今後はそのような位置ベースのデータをどのように相互運用させていくかがキモになっていくと思います。
KMLあたりがデファクトとして逃げ切るのか、策定標準としてのSVGやPlaceXMLあたりが巻き返すのか、今後面白くなっていきそうです。
2007年02月04日
ウェストバージニア州で肥満防止のため公教育にDDR導入
「ダンス・ダンス・レボリューション」の全公立校への導入を決めた米ウェストバージニア州は、このゲームが体重増加を食い止める一助になるという調査結果を発表した。（ロイター）
米国最悪の児童肥満問題を抱えるウェストバージニア州が、コナミの「ダンス・ダンス・レボリューション」を使って学校で肥満と戦う計画を強化している。同州はこの人気ゲームを公立学校に1校残らず導入する計画で、1月31日、これが体重増加を食い止める一助になることが調査で示されたと説明した。
うおっすげえ。
テラウラヤマシス。
2ちゃんねるのレスでは疲れれば食うから痩せないとか色々書かれてますが、いや、マジでこれ痩せますよ。
初代の頃、実際に数ヶ月で10kg痩せた私が言うのだから間違いないです。
ただやってた量がハンパなかったですけどね...結婚前の社員寮生活で独身貴族状態だったんで、ほぼ毎日やってしかも1日5千円とかつぎ込んでた事もよくありましたし。
後、ある程度やってると維持は出来るがそれ以上痩せなくなる...理由は恐らく、体がゲームに慣れてきて、最も楽なステップの踏み方を体が覚えてしまうからだと思う。
エアロビしたりジョギングしたりするのと何が違うんだと思われるかもしれないですが、基本的に「痩せる」という事自体が目的化しないのが一番大きいです。
エアロビやジョギングというのは、結局なんでそれをするのかというと「痩せるため」「健康のため」といった事が目的化するので、やっていて楽しくない。だから長続きしない。
でも、DDRの場合は、「痩せる」という事自体が目的化するのではなく、目的は飽くまで「ゲームをクリアする事」「音に合わせて楽しく体を動かす事」という、楽しい目的なわけです。
「痩せる」というのはその目的を追求した結果起こる、副産物でしかない。
だから続けられるし、痩せられたと思います。
だったらどうして今も続けないのかというと、続けたいけどもうブームも去って、筐体置いてる場所がないのが主要因。
プレステ2を買ったらDDRもあるわけなんだけど、コントローラがペラペラのビニール製なので、スライド（足をコントローラの上で滑らせて移動するステップ。うまく使うと速いステップを比較的簡単に踏めると共に、決まると気持ちいい）が使えないのが不満なので、結局買ってない。
（というか、実は実家にはプレステ１とプレステ１版でのDDRはあるけど）
やっぱりやるんだったら実機でやりたい。
アメリカのamazonでは、実機筐体も販売しているみたい...欲しいなあ...買う金も置く場所もないけど。
というか、もうそうそうDDR筐体置いてるところもないとあきらめていたので探そうともしてなかったのだけど、今あらためて探してみると何と東京ドーム周辺に3台も設置されているとの情報が。
新しい職場、神保町・水道橋界隈なので、東京ドームなら普通に寄れます。
おまけにスーツじゃなくカジュアルウェアなので、風邪とかさえ引かないように気をつければあまり汗とか心配しなくてもいいし。
最近洒落にならないレベルで太ってきてるので、毎日じゃなくても、たまには行ってみようかな。
情報仲介業にとって情報を直接結びつけるGoogleは怖い存在
リクルートにしてみれば、ネットメディアはとても怖い。
情報仲介業がリクルートの本分ですから、ネットでその領域がことごとく奪われる可能性があります。
お店の情報、結婚情報、就職・転職情報、住宅情報。.........
ネットメディアと書きましたが、ここで仮想敵になるのは、やはりGoogleなのかな、という感じがします。（代表としては。）
すごい。慧眼。
PLACE+やOSGeoカンファレンスで、まさにリクルートの「中の人」が、リクルートの進めるローカル系検索やWebサービス等の持つ意味として、Google等のインターネット検索でユーザと企業が直接出会う事に情報仲介業として脅威を感じている、それゆえローカル検索で情報の訴求力を高めたり、Webサービスでマッチングの機会を増やすといった戦略を採っている、みたいな話をされてました。
私は昨今のWeb2.0やらの流行りで、何となくリクルートも始めたのかなあ...くらいのぬるい認識しかなかったので、その発表を聞いた時は目ウロコだったのですが、やっぱ判る人には判るもんなんですねえ。
Yahoo USAのIDをプロキシできるOpenID認証サイトidproxy.net
ちょっと古い話題ですが、Yahoo! USAのIDを使ってOpenID認証を可能にするサイト、idproxy.netがオープンしています。
idproxy.net: Use your Yahoo! account as an OpenID -Simon Willison’s Weblog-
idproxy.net, launched today, is my attempt at speeding up the process. It uses Yahoo!’s Browser-Based Authentication API to allow you to sign in with a Yahoo! account, then lets you create one or more OpenIDs (of the form something.idproxy.net) to use with sites that support the OpenID standard.
Yahoo!のBBAuthとかいう認証APIを使って為された認証結果を、そのままOpenIDの認証結果としてプロキシしてくれるサイトのようです。
似たようなことは、はてな・mixiアカウントをプロキシする形で以前私もやろうと思っていたんだけど、認証をプロキシするだけの機能はできた（といってもCPANモジュールとか流用するだけなので難しくも何もなかったが）ものの、ちゃんとしたサービスとしてサイトとしての体裁を整えたりアカウントを管理したりする部分の実装ができなくて（要するに技術の地力が問われるところでダメだったって事だ）挫折。
それと私がやろうとしたやり方はサーバサイドでロボット動かしてログインする、ユーザのパスワードをうちのサーバに一旦通さなければいけないやり方。
mixiはともかく、よく考えればはてなの方は認証APIがあるんだから、idproxy.netと同様にそれをプロキシすれば、ユーザの大事なパスワードを馬の骨サーバに通さなくてもいい、セキュアなやり方で実現できるわけだけど、恥ずかしながら何故かそれは思いつかなかった。
というわけで、私は技術力不足で無理ですが、誰かidproxy.netと同様のやり方で、はてな認証APIのOpenIDプロキシ作りまへんかー。
どうせやるならはてなだけでなく他の認証APIも受け入れられるような形で...。
alexaでの日本サイト伸び悩みはモバイル移行のためと仮にしても、その契機は？
昨年よりalexaのランキングで2006/2月以降日本国内の主力サイトのトラフィックが伸びていないと見切りを付けるネット事業者の方がいますが、話は簡単でそれはPCからモバイルにトラフイックの民族大移動(T氏命名)が起きていて単純にPCの利用頻度が減っているからだ、という結論になりつつあるのかなと感じます。
いくつかのブログ記事で
- PCから見るWebの世界と、ケータイから見るWebの世界は別物なのだなあと実感
- ケータイ文化圏とネット文化圏の深い溝 -絵文録ことのは-
- 絵文字も空気も読めません 10代がハマるSNS「モバゲータウン」を28歳（♀）が探検した -あなたの知らないインターネット-
PCネット圏にケータイネット圏が再発見された（といっても厳密にはPCネット圏とBlogoshereは異なるでしょうが）のが2006年の8月から11月頃だった事から考えても、ちょっとにわかには受け入れ難い「結論」ではあるのですが...（業界重鎮も同意見といった形で権威付けはされていますが、根拠が書かれていませんし...）。
反論するのに当初、続く記事に「考えてみれば別にSNSの利用用途の大半が...」とあるのでmixiだけの話かと思いmixiだけ絞って傾向を見ていて「やっぱり違うよ」と書こうとしたのですが、よく見ると前半で「日本の主力サイト」と書かれていたので、主要サイトの傾向を見てみると、確かに一律の下降トレンドが。
元記事では下降が始まっているのは2006年2月と書かれていますが、私の主観で見た感じ、下降トレンドへの移行は2005年の9月頃には始まっている気がします。
mixiのみまだ上昇しているのと、2006年1月にピークがあるので（明らかにライブドアショックと思われる）判りにくいですが。
全サイトでこれほど綺麗に一斉の下降トレンドが出るのであれば、mixiの事象だけ取り上げて反論しようとしていた私の反論はご破算に。
でもって一律に減っている事を説明できる理由を考えようとすれば、確かにモバイルへの転出以外に考えにくいのかなあ、という気はします。
でも、下降している原因はモバイルへの転出だと「仮に」しても、その起こる契機は何か説明付けられないとやっぱり納得できないわけです。
ある時期を境に「モバイルへの転出が原因で」下降トレンドになったのだとすれば、その時期には何かそれをトリガするエポックメイキングな出来事が起こっているはずです。
そしてその原因は、各サイトが一律に下がっている以上、特定サイトのモバイル対応、といったPCサイト側の出来事ではなく、モバイル側の事象だと考えられます。
でも、残念ながら私の調査力では、それが見つからない。
モバイルで一番影響力が大きいのは全体の60%近いシェアを握っているドコモ、何かトリガになる事象が起こっているとすればドコモでだろうと当たりをつけてみても、 ドコモのプレスリリースを見ても特にそれらしい契機となるような出来事は起こっていません（減少トレンドへの移行を2006年2月と見た場合、FOMA全料金プランへのパケホーダイ適用が1月末に発表されているのでこれが契機のようにも見えますが、実際には適用開始は同年3月からなので、適用前から減少している説明がつかない）。
どなたか、モバイルへの転出が2005年9月、或いは2006年2月頃から始まったことに対する、納得のいく契機を説明できる方はおられないでしょうか。
もちろん、モバイルへの転出以外の説明でも、納得がいく説明なら構いません。
私にはさっぱり判らないので、ご教示よろしくお願いいたします。
もし契機が見つからないにもかかわらず、PCネットのPVが下降トレンドになったのだとすれば、これはもしその「減少の原因」が「モバイルへの流出」であると仮にしても、本質としては違う結論になる可能性があります。
PCネットからモバイルへの転出は昔から一定程度存在したが、それを上回るPCネットの普及が存在したため、PCネットのPVは上昇トレンドにあったが、2005年9月頃を境にPCネットの普及が飽和状態に達したため、モバイルへの転出による純減のみがトレンドに現れるようになった、という可能性です。
つまり、その時期からモバイルが普及し始めたために減少し始めたのではなく、元からモバイルの普及は一定程度あって、PCネットの普及飽和という「PCネット側」に発生した契機をきっかけに、それが表に出始めたということです。
むしろこの説明の方が、モバイルが契機もないのに2005年9月頃から突然普及を始めたとするより、mixiのみ減少トレンドに移る時期が遅れたことを説明し易い。
他の老舗？サイトは、全体のPCネット普及率に対するシェアがある程度平衡状態にまで達していたため、PCネット全体の利用頻度に比例して2005年9月頃から減少に転じたが、後発のmixiはまだシェアが平衡状態には達していなかったため、全体の利用頻度には比例せず2005年9月以降も伸び続け、2006年6月頃にシェアが平衡状態に達して全体のトレンドに沿った減少を始めた、と言う説明が可能です。
もちろん、これも仮説に過ぎず、証明するには回線数の推移とか裏付けを取る必要がありますが、契機もないのに社会が一斉にモバイル志向へと転換したと考えるよりは、「ネットの飽和」は契機がなくともある時期が来ればかならず起こるものであるわけなので、説明に無理がないんじゃないかとは思います。
2007年02月03日
ユーザカスタマイズ可能なサイトという方向のマッシュアップが今後進むかも
一昨日朝電車の中で考えてたのだけど、
いろんなサービスのWeb-APIの公開や、Google Maps APIのような他サイトでの読み込み用Javascript-APIの公開で、個人のサイトでもいろいろな情報のマッシュアップが可能になってきているわけです。
いろんな勝手デベロッパーが、いろんなアイデアでいろんなサイトをあちこちで立ち上げてる、それはそれで面白いんですけども。
でも、最近ちょっと思い始めたのが、マッシュアップサイトは面白い、確かに面白いので出てくる度に騒がれるのだけれども、だからといってそのサイトを使い続けるか？と言われると、...？となるようなケースが多くないだろうか。
例えば、グルメ情報を公開しているAPIと、Google Maps APIがあったとして、それをマッシュアップしてグルメ情報をGoogle Maps上に表示するマッシュアップサイトがあったとする。
最初は「面白い、面白い」となるだろうが、最初の祭りが過ぎた後、いざ今後グルメ情報を検索するのに、そのサイトを訪問して使おう、という気になるだろうか。
この辺は個人の感覚差があるので、もしかしたら面白いサイトは継続して使うよ、という人もいるかもしれないが、私の感覚はどちらかというと何でも「ワンストップチャネル」化したい性質なので、ちょっとの便利を得るためにわざわざ別サイトの存在を記憶して、訪問し直したりしなければいけないのであれば、むしろその便利を得ることは放棄する。
もちろん、単純に心理的コストの問題なので、自分の感覚として他サイトを記憶し訪問する事に対する心理的コストを、そのサイトで得られる便利のベネフィットが上回れば使い続けるとは思う。
さらに言えば、もしそのマッシュアップサイトが非常によくできていて、本家であるGoogle Maps或いはグルメ情報の提供元のサイトが提供している機能（パフォーマンス等も含む）を全て包含する形で作られているのであれば、Google Mapsやオリジナルのグルメ情報サイトを使う代わりに、そのマッシュアップサイトを使うようになる、という可能性もあるだろう。
でも、そのレベルで作りこまれているマッシュアップサイトというのは、マッシュアップアワードだとかなんとかに参加するため作りこまれたものとかでなかれば、そうそうないように思う。
でも、その程度（と書くとマッシュアップサイト製作者さんに失礼ではあるが）のマッシュアップでも、同じ機能がGoogle Maps、或いはグルメ情報の提供元のサイトといったオリジナルサイト側に付け加わったら、利用するんじゃないかなと思う。
例えば、Google Mapsのどこかに「グルメサイト表示」というようなボタンが出来て、それを押すとGoogle Maps地図上に店舗情報が表示されるとか、或いはグルメサイト側で、検索した店舗の結果が地図上に表示されるようになるとか。
要するに、新しい機能を得るためにその度わざわざ違うサイトを使うことには心理的コストが発生しても、普段から使っているサイトに新しい機能が加わる事に関しては、特に心理的障壁はないということだ。
もし私のように考える人が多かったとしたら、今後、マッシュアップやAPI公開というのも、別の方向性が出てくるのではないかと思った。
つまり、オリジナルサイトで使っている機能を切り出して、他のサイトで使えるようWeb-APIやJavascript-APIとして提供する、というだけでなく、オリジナルのサイトそのものの機能や外観が、公開され整理されたJavascript-APIで変更できるようになる、という方向性。
イメージとしては、Googleパーソナライズドホームで、デベロッパーがガジェットを誰もが自由に作成し登録し、ユーザが登録されているガジェットから自由に選んで自分のページとしてカスタマイズできるという形が既にあるわけだけど、それに近いものになる。
Google Mapsやグルメサイトで、ユーザの自由なJavascriptガジェット（以下寄生ガジェットと書く）を登録できるような領域が公式に用意されて、そこにサイトの機能を公式Javascript-APIを通じて叩き新機能を実現する寄生ガジェットを自由に登録できる、といった形。
既に、似たような事はFirefoxのGreasemonkeyやBookmarkletでやられているわけだけど、各サイトがもっと公式に「寄生ガジェット」を容認、もしくは積極的に推奨するための、ガジェット用領域の準備やJavascript-APIの公開等といった動きが今後出てくるんじゃないかと思った。
もちろん、そのことによってこれまでの「他のサイトで使えるようWeb-APIやJavascript-APIとして提供」という動きがなくなるわけではなくて、「マッシュアップ」を実現するためには、Google Mapsに寄生するガジェット作成のインタフェースが用意されているだけで�