ここが、こうさぎなどをBLOGしたかったの♪
ここは、こうさぎや大きいこうさぎとこうさぎとか言ったよ
今日、こうさぎをBLOGされた！
今日は、ネットでこうさぎなどをBLOGしたかったの♪
ここは、こうさぎとかをBLOGしなかった？
こうさぎと大きいこうさぎとかこうさぎとこうさぎとか言ったよ
今日は、大きいこうさぎや大きいこうさぎをBLOGしたかったの♪
だよ♪

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

ユーザエクスペリエンスとは、思い込みでなくユーザの動向の分析を行って、ユーザの使いやすいようサイトの構成や使い勝手を変えていく事ですが、それは並大抵ではできるもんでもなく、それならばいっそ、できる限り情報を開放し、ユーザの自由度を増やし、ユーザが自由にその中での自分のあり方を取捨選択できるようにするのも、一種のユーザエクスペリエンスと言えるのではないでしょうか、というお話。

前の会社が、どこでも伝言板というGPS携帯を使ってユーザがある場所に伝言をおけ、近くを通った人が検索できメッセージを見れるという、有料公式コンテンツを運営していました。
携帯アプリの時代でもなかったので自動プッシュなんて事もできないし、置けるのもせいぜいメッセージと写真程度、その頃はソーシャルなんて概念もなかったし、また何より、システムとして切り出し不可能な作りきりのWebアプリだったわけだが、とはいえある意味、以前引用したsociallightに近いもんだと思って構わないです。
（ちなみに、私はそのサイトの立ち上げには関わっていないし、また運営にも参加させてもらってない...というか運営されてたのか？）

そういうサイトはそこだけではなく、例えばあのライブドアも、かつてLivedoorナビゲーションという位置情報メッセージサイトを運営してました。
こっちは無料サイトで、位置情報はiエリアベースの大まかな位置で、4キャリア対応だったというのが違いだが、位置にメッセージを残して近くの人が見れる、と言う点ではどこでも伝言板と同じようなサービスと言えました。
他にも同じようなサイトは、いくつかあったようです。

こういうサイトは、みんな作れば面白いだろう！と思って作ったんだろうけど、軒並み閑古鳥が鳴いてました。
位置情報でメッセージ交換とかなんて時期尚早だったのか、いや位置情報なんてもうからないんだよ、誰もがそう思ってた時、同じ位置情報メッセージ交換サイトであるにも関わらず、盛況なサイトが現れました。
それが、先日のsociallight引用記事のコメントにも載っていた、GPSMANというサイトです。
このサイトに始めて会った時は、すごい衝撃を受けました。
今も人気はあり、かといって過剰な注目もされずマターリと今も続いている位置情報サイトですが、でも俺はこのサイトは数ある位置情報サイトの中でも、一つのエポックメーキングなものだと思っています。

GPSMANのアイデアは簡単。
同じように近くのユーザを探すのですが、ユーザの残した「メッセージ」が探されるのではなく、ユーザが「ついさっきそこに居た事」が探されるのです。
つまり、ユーザAがメッセージを残そうが残そうまいが、GPSMANの世界にアクセスすると、そのアクセスしたという事実が、位置情報と共に記録され、次に別のユーザBが近くでアクセスした時に、「どの位前にどの位離れた場所でユーザAがアクセスした」という事がデータとして出てくるのです。
実際には、そのように近い場所で、近い時間にアクセスしたユーザはたいていかなりの人数になるので、まるで大都会の雑踏のように、近くにユーザA、C-Zが居たという事が、ユーザBには判るようになっています（ユーザA、C-Zがアクセス以外のアクションを何もとっていなくてさえ!!）。
そして、刻々と新しい人がアクセスしていきますから、ユーザBがアクセスするたび周辺の状況が変わって、サイトの活気が演出されるのです。

GPSMAN以外の今までの位置情報メッセージ交換サイトだと、いくらアクセスが多かろうが少なかろうが、誰かが意を決して「メッセージを残してやろう!」という決心をしない限り、他のユーザの存在は判らず閑散としたまま。
誰もアクセスがないのか、或いは100万人がアクセスしているが100万人が誰もメッセージを残していないのか、が全く判らないのです。
メッセージを残しても、それが見られているのかどうかも判らない。
これではまるで、ユーザにとってみては、お互いに姿も見えず気配も感じられない透明人間の街に降り立った様な印象を受けるのではないかと思います。
それに対しGPSMANは、そのまま現実世界の都会の雑踏のモデルです。
現実世界の雑踏では、別に人がたくさんいるのを感じたとしても、別にその人達と会話を交わすわけでもなく、ただただ通り過ぎていくだけです。
しかし会話は交わさなくても、お互いに存在は感じる事が出来るので、活気のあるところでは人混みとして、ないところではまばらな人影として、他人の存在を感じる事ができ、人はそこが流行っているところなのか、いないところなのかが判るのです。

GPSMANに残されるユーザのアクセス履歴には、そのユーザの簡単な自己紹介が一緒に表示されます。
これは現実世界で、単に街角で通りかかった人と言葉を交わさなくても、その人の服装等から受け取るメッセージと解釈できます。
そしてGPSMANでは、本当にその時その場にメッセージを残す事もできるのですが、この機能は「叫ぶ」と名づけられています。
「叫ぶ」を実行すると、その場にメッセージが残されるだけでなく、最近近くにいたユーザ達に、その内容がメールで届く仕組みになっているのです（もちろん、しょっちゅう届くとウザいので、受け取るか受け取らないか、受け取るにしてもどの位受け取るか、は設定できます）。
これは、都会の雑踏の中で、自分のメッセージを発信するストリートミュージシャンや大道芸人の叫びのようなものです。
それに気を止めるか、無視して歩き去るかは別として、その場にいるユーザは皆（耳栓をしている人以外）その人の存在を感じるし、感じてもらっていると叫ぶ方も実感する事ができます。
近くにちょっと気に入ったユーザがいれば、メッセージを送ってナンパしてみる。
知人とひさしぶりにすれ違ったら、挨拶して飲みにでもいく？と誘ってみる。
GPSMANは、まさに都会の雑踏の雰囲気をそのまま、位置情報サイトに持ち込んだという事ができます。

別に、サイトの基本としては、どこでも伝言板もLivedoorナビゲーションもGPSMANもほとんど同じなのです。
ただ、GPSMANは、他人のアクセスという情報をうまく開放し、何をすればいいのかわからないユーザがアクセスしても短い時間で世界観が伝わり、そこでの楽しみ方が掴める様な工夫を施しただけなのです。
別に複雑なシステムを組んだわけでもなく、単純に情報を開放しただけ。
それだけで、ユーザは雑踏を楽しむにしろ、叫んでみたくなるにしろ、ナンパ(同性も含め)して友人関係を深めたり、近くの知人を探すツールにしたり、その人なりの遊び方でサイトを楽しめるようになったというわけです。

どこでも伝言板など、情報の地域限定発信、そして情報を「貼る」「はがす」という技術コンセプトにこだわって作ったために、あまりに閑散としてるから全国サーチを導入しようという話でも、それでは技術コンセプトが違ってくるから...云々といろいろすったもんだがあったらしいのです。
が、ある意味作り手側のそんなこだわりなんかどうでもいいわけで、ユーザにとってはいかに一瞬で、サイトの背後にどのような世界が広がっているかをできるだけ短時間で理解し、それが自分の嗜好と合う部分が存在するか、を判断できるようにする事が、大切なのではないかと、GPSMANに思い知らされたのでした。

まあ余談ながら、GPSMANに出会ってショックを受けてすぐさま、このシステムをどこでも伝言板にも導入しようと提案しましたが、即効で却下されました。
もう既に位置情報で（少なくともケータイのエンタテイメント位置情報で）儲ける事には見切りをつけていたようで、それ以上サイトを改造する気もなかったようで...。

高校時代(遊んでた相手の顔を思い出すに、中学だったかもしれん)に激遊んだLOST WORLDSシリーズが復刊する!!これ、むちゃ面白いんだよなあ。
...というか、そりゃMTGとかも経てきてる今のゲーム小僧から見るとどうなのか判らんけど、たった2冊(個人持ちは1冊)の薄っぺらい本を交換するだけの遊びであるにもかかわらず、感じさせる世界観や戦略性が深い!!
ほとんど魔道師のブースタースペルブック含め、ほとんど全冊集めて遊んでましたよ...もしかしたら実家にはまだあるかも...。

でも、復刊するのはいいのだが、記事読むと萌え系かい!!
それは復刊というのかな...単にゲームシステム借りてきただけでしょ...。
でも、別に萌えに惹かれてでもいいからやってみて欲しい。
もう20年近く前のものなのに、ここまでのゲーム性があるシステムなのかと驚くはずだ。

公式ページもありました。
サンプルゲームも楽しめますが、あれではどこが楽しいの？思うかもしれません。
実際には、個々の局面では少なくとも数通り、全体では何十通りの行動が選べる中で、相手も決まったシナリオではなく生きた対戦相手の操るキャラクターで、その局面と選んだ技の組み合わせで流れが決まっていくので、戦略の楽しめるゲームとしてなかなか面白いです。
勝敗も、サンプルのように一撃受ければ終わり、というのではなく、ヒットポイント制で何度も攻防できますしね。

もうちょっとよく調べてみると、LOST WORLDSのルールコンパチの独自キャラクター作られているサークルがありました。
そーなんだよな、奥が深いけど単純なルールなので、自分なりのキャラクター作りたくなるんだよな...（というか作った）。
ゲームバランス難しいけどね。

プラグインで拡張すればいろいろ便利に使えるMovableType、そのプラグインの入手先としてはいろいろあって、ビビッときた作者さんのプラグインなんかは自分にとって使えるもんばかりで秘密の宝箱になったりします。
国内では(o)さんところがそんな感じだったりしますが、今回おすすめしたいのは、Stagger[nation]さんとこのMTプラグイン集。

特に今導入しているCompareプラグインは超使えるー。
(o)さんとこのTagwireプラグインを導入したのはいいものの、昔の膨大な記事でタグがついてないのが多すぎ、おまけに思いつきタグが多すぎで正規化されてない、という事で、

• 各エントリのTagの隣にタグ編集フォームへのリンクを設置する
• タグ付けされていないページにも、DBの直接操作で「Not_Tagged_Yet」という文字を全部突っ込む

そうすると、タグの一覧ページでNot_Tagged_Yetへのリンクができるので、そこから編集フォームを呼び出して、暇な時に徐々に編集していけばいいか、と思ってたんですが、
試してみると、Not_Tagged_Yetの巨大なタグクラウドが発生して、他のタグすらクリックできない状態に！！

ほとほと困り果てていろいろ探してますと、上記のCompareプラグインにたどりつきまして。
これを使うと、MT標準の0／1しか判断できない<MT_Iｆ...系の比較と違いまして、何でも比較できるのです。
これで、タグ一覧ページや各ページのエントリタグ表示時にも、Not_Tagged_Yetの表示を抑制できて、逆にタグ未設置サイトの一覧も別にまとめる事ができました。

これで助けられた後、Stagger[nation]さんとこを他にもよく見てみると、いろいろと使えそうなものが...。

もちろん、Compare自体、もともとはSix Apart Pronetで見つけたので、別にそこベースで探していけばいいんだろうけど、なんらかの目的でプラグインを探した後、特に目的もなくただ他のサイトとの差別化のためになんかちょっといじってみたいなあ、てな感じの感覚のときは、Pronetの膨大な中から探すより、過去に導入したプラグイン作者さんのサイトを漁ってみるのもどうですか、という感じです。

「Man-in-the-Middle攻撃をされたらひとたまりもない ( http://sho.tdiary.net/20051021.html#p01 )」ということですね。
httpsでも、どの認証局を信用するかという問題が残りますね。

おっともう言及されてたんですね…。
セキュリティ素人なのでMan-in-the-Middleという言葉がなんか背伸びし過ぎてる気がしてつかえませんでした(びびり)。

でも一応、認証局の問題はおくとしても、各認証サーバのアカウントページを使う限りは（http://kokogiko.videntity.org/とかhttp://profile.typekey.com/kokogiko/とかの）、これらがhttps化されれば（今のところされてないけど）、問題はなくなると考えていいんでしょうか？
もしそうなら、問題はopenid.delegateの部分になるのかな…個人サイトは簡単にはhttps化できないし。
htmlのメタ情報として置くからよくないんじゃないか。
たとえばFOAFの中に突っ込んで、FOAFに埋め込んだ電子署名で、記述されたdelegate・server設定の正当性を検証するとか。
その信頼性は、foaf:mboxからKey Serverで取得した公開鍵の、署名ベースの信頼性から判断するとか。
httpで指定された（改ざんされ得る）html -> FOAF情報であっても、指定された公開鍵がある程度信頼出来るなら、OKみたいな。
これなら、どこかで誰かが書いてたけど、OpenIDの信頼性はサーバとユーザ双方の信頼性検証が必要になる、とあったけど、ユーザの信頼性は公開鍵の署名で検証し、サーバの信頼性はhttps認証局の信頼性で検証して、両方検証できるようになるんじゃないかと思ったり。

できるならば、OpenIDのアカウントをWebのURLベースではなく 、メールアドレスにして、直接Key Serverから公開鍵取得して…なんて事ができればいいんだけど、今のところその方法だとメールアドレス -> WebサイトURLの逆引きができないから駄目ですね。
メールアドレスの方が自分のID、という感じも強いんだけど...。

あと、現行はopenid.delegateの仕様が、delegate先を本当に確認するのではなく、delegateで指定されたURLを使ってopenid.serverで識別する、という仕様になってるんだけど、これも安全性を徹底するには、本当にdelegate先を訪問して、そこのopenid.serverを確認して識別する、という手順にした方がいいと思う。
OpenID MLの過去ログを読み返してみると、この辺は昔話題に上がってたけど、一手手順が増えてプロトコルが重くなるのと、delegateの連鎖による多重ホップを恐れて、あんまり議論されずに消えてたみたいだけど、手順が増えても安全性を考慮した方がよいと思うし、多重ホップは最初から「多重ホップはしない -> 多重ホップするようなら識別失敗」とでもすればいいので、delegate先は訪れるべきだと思うんだけどなあ...。

そういう風にdelegate元でopenid.serverを指定せずに、delegate先だけを指定するようにすると、もう1つ利点があって、delegate先を1箇所だけでなく複数並べられるようになること。
そうすると、delegate先を通じて複数のopenid.serverを指定できるようになるので、1箇所のopenid.serverが落ちていても、別のopenid.serverに依頼したり出来るので、可用性が高まる。
また識別を要請する側で、openid.serverの信頼性を選択して、自分の信頼できるopenid.serverでの識別を選択したり出来るようになる。
例えば、あるopenid.serverの識別サービスを提供している業者のサーバセキュリティに、問題が発覚したとする。
危険なのでサービス提供側が軒並みそのopenid.serverからのログインを拒否するようになったとすると、それを使ってログインしてきたユーザ側が、自分のサイトのdelegate・server指定を他のところに書き換えないとサービス継続不可能になり、大混乱になる。
でも、複数delegateを認めていると、あるopenid.serverが信用できなくても他のところが一緒に指定されていればそこに識別依頼できるので、ユーザに何の混乱も起こさず、コンシューマ側の設定だけで危険を回避できる。
というわけで、やっぱりdelegate先は複数指定できた方がよい、と思うのでした。

でも、こんなの全部突っ込めば、すごい思い仕様になるかな...。Simpleではないよね...。

ちょっと前のOpenID-MLを漁っていたら、OpenIDのシーケンスダイアグラムが紹介されていました。

OpenID Diagram

判りやすいので一見。

ところで、先日まかまかさんと話していて疑問に思ったんですが、このダイアグラムでの最初の方、
CからIにSを問い合わせるところ（要するにHTMLメタ情報のopenid.serverやopenid.delegateをチェックするとこですな）で、結局のところここがhttps化されてなければ、途中で盗聴・改竄されて異なるSを伝えられてしまい、そうなると何でもログイン成功されてしまいUAを詐称されてしまうんじゃないか、という話をしたんですが、
そうするとOpenIDはidentificationには使える けどauthenticationには使えない、という話があったけど、そもそもidentificationにも攻撃を受ければ使えないんじゃないの？とか思ったり。
正直、この辺の知識に自信ないのでよく判らないんだけど、どうなんだろう。

○○中（をい）なので簡単にしか触れられないので詳細は以下見て欲しいが

Googleによるデータベースサービス 「Google Base」 まもなく登場か　-Zopeジャンキー日記-

これを見るとわかるように、Web上でデータベースみたいなことができるもののようだ。

不動産情報やイベント情報などのフィールドを定義して、アイテムを登録できるような、そういうものだろう。

 これは、Web上の情報に「構造」を与えるものだ。

RSSによって十分示されたように、情報に構造（スキーマ）さえ与えれば、ソフトウェアで処理しやすくなるので、その応用・活用は無限にひろがっていく。
これはおそらく、いままでのGoogleのサービスの中でも、もっともインパクトのあるサービスになる気がする。

 いま、歴史的瞬間に立ち会っているのかもしれない。

確かにすご過ぎです。
これが公開された検索サービスと一体化して、さらに草の根的に共有できるスキーマが立ち上がっていくと、セマンティックWebなんていらなくなるかもしれない。
少なくとも、後押しするだろう。
新しいSpamの可能性は、とりあえずおいておいて。

位置情報erな個人的な要望としては、GoogleもGoogle Mapsでせっかく位置情報で盛り上がっているので、扱えるデータ型に多次元データ型を含めて欲しいなと。
それだけお願い　＞　中の人（見てるわけない）

--　追記 --

つい興奮してしまうと直感で言葉あんまり選ばずに書いてしまうのは悪い癖だが、セマンティックWebいらないというのはちょっと言い過ぎたというか誤解されてしまう。
セマンティックWebに意味はあるし、何より単なる意味づけだけでなくオントロジー等の上位レイヤーまで含んでくると、Google Baseだけではいかんともし難い問題になってくるわけだし。

要するに言いたかったのは、セマンティックWebというと意味づけされたコンテンツがまずありきで、その上でそれを解釈できるロボットが収集に走って検索、というようなルートでしか普及が考えられなかったわけで、そうなってくると誰がまず意味付けコンテンツを出すのよ、簡単に意味付けできるツールがないと普及しないんじゃないか、とか考えられてたわけだけれども、
Google Baseのようにまず属性を直接検索サービスのインデックスに叩き込んで利用できるようになると、セマンティックWebの普及前に、
まずコンテンツに意味づけしそれをベースに検索するという経路の便利さがユーザに普及し、
するとしばらくするとYahooなんかも追随するだろうから、そしたらそのサービス間の意味データ交換のフォーマットとしてRDFなんかが見直されてくるとか、
そういうシナリオでセマンティックWebが普及する可能性も出てきたという事で、セマンティックWeb側主導ではなくサービス主導になる可能性があるという意味で「セマンティックWebなんていらなくなるかも」と書いたわけでした。

というか、手っ取り早くて面白いアプリケーションとして、
今Folksonomyの記事のタグ付けに、SBSでの客観的タグ付けと、各Blog単位の作者によるオレオレタグ付けがあるわけだけど、
その橋渡しとして、タグ付けのスキーマを決めて、記事に対するタグ付けは個人のものであろうが客観的なもんであろうがとにかくGoogle Baseに突っ込んで、
主観と客観を織り交ぜた記事の自動分類化を促進するようなアプリとか、どうだろうか。
ありきたり過ぎ？意味ないかな？

同じエントリの受け記事で恐縮なのだけど、

Your Data is your data -blog.bulknews.net-

ツールが気に入らなければ、データはいつでも取り戻すことができる。
それがそのツール・サービスを使い始める障壁を取り除くことにもつながる。

それができないのが、今のSNSの限界なのだと思います。
SNSで最も大事なデータは？というと、SNS内ポータルの自分の写真でも日記でもなくて、友人と築いたネットワークそのものでしょう。
これが動かせない限り、ツールが気に入らなくても他に移る事はできない。
かと言って、データを引き出せても、このデータはネット世界で完結しているものではなくて、現実世界のオブジェクトの射影であるわけなので、単に移せばすむというものでもない。

だから、SNSを構築する単位は、各サービス内で勝手に作ったユーザのエージェントオブジェクトではなくて、ネット上でURIとして指定できる唯一無二の、ユーザのエージェントオブジェクトを繋ぐものでないといけない。
（もちろん、ユーザが勝手にいくつもエージェントを作るのはアリですよ、表の顔、裏の顔。でもそれぞれはサービス独立のもんでいけないとならない）
その上で、SNSはそのユーザのエージェントを繋ぐ存在として機能しなければ、自由にツール交換可能な「Your friend is your friend」というふうにはならない。

その辺を論じたのが以前のエントリ

 ここギコ！: 歴史は繰り返す その１　その２

で、その実現手段が、FOAFを使ったオープンSNSのアイデアであったり、OpenIDで繋がるvidentity.orgであったり、Affelioであったりするのかなと。

サービスの終了自体はプロバイダの都合なのでご勝手にという感じですが、ユーザのデータはちゃんとエクスポートできるんですかね。
システム構築費の問題とかいってるぐらいだから、できないんだろうなあ。
こういうサービス（事業者）に自分のコンテンツを安心して預ける気にはなりませんねぇ。

ツールが気に入らなければ、データはいつでも取り戻すことができる。
それがそのツール・サービスを使い始める障壁を取り除くことにもつながる。

Flickr は flickr チームのエンジニア自ら、API を利用したバックアップツールを open source でリリースしている。

論旨は完全合意！御意！なのですが、まだ使ってない人間からすればそのFlickrですら怖いんだよなあ...。
API公開されててバックアップ可能となっても、システムの問題と言うよりはデータの質の問題で...。
いくら溜まってもたかがしれてるテキストデータと違って、画像と言う下手すれば何百GBというデータになりかねないものを、現実問題としてサービス停止とかになって、みんなバックアップしようと躍起になったりした時に、本当に取り戻せるのか、という問題。
それを考えると、今後何十年にわたってインターネットというものがある限りはFlickrがサービス続けてくれると言う確約でもない限り、怖くて預ける気になれない...。

元々友人と画像を共有すると言うニーズが少ない（友達いないんだよ！ふん！）ので、使うとすれば、田舎の祖父母と共有できる息子の成長写真の整理場所、とかになったりするんだけど（そういうのは強烈に欲しい）、そういう息子の成長といったかけがえのないデータになると、上のような理由でおいそれと他人に全部預けられるもんじゃなくなってしまう。
共有するデータとそうでないデータの2重持ち、というような冗長管理で煩雑になる事もしたくないし。

んで、そういうWeb2.0スゴス！とか叫びながらも、一方でどう考えたって既にオサーンに足突っ込んでる団塊ジュニア世代としては、ものにもよるけど、必要なリソースは必要な時だけ借りてきてなくなってもそれはそれでOK、という感覚にはなじめない部分もあって、やっぱり自分の大事なものは自分で管理する、失っても自己責任、という発想の方がしっくり来る事もある。
俺より上の世代だともっとそうだろう。
そうなってくると写真なんかは預けずに、自分の家PCで管理して、それをネットに公開する、というようなニーズは出てくるのかなと...。
でも家PCをネットで公開するといっても、セキュリティは？サーバ設定は？Webアプリ設定は？だいたい家PCなんてWindowsじゃん？みたいな話が出てくるので、その辺を意識させずにインストールするだけで、ちゃんと設定されるようなサーバアプリパッケージのニーズも家庭向けに出てくるのかなあ、等と考えて以前書いたエントリーが、

SpaceTag Serverのネウチ

だったりします。
もっとも、その後いろいろあったので、こういうニーズがもしあったとしても、その方向に進む事を今のSpaceTag Serverに期待する事は困難になってますが...。

ネタ元は百式から。百式に絡むのは初めてやなドキドキ。

数年後のサービス

概念的には昔からあったのだが、ようやく実用化されつつあるサービスをご紹介。

sociallightが提唱しているのはLocation-based Messagingだ。

いわゆる場所を基点にしたメッセージサービスだ。 例えばある人が歩いていてピザ屋の前を通りかかる。
すると携帯が振動してそこにメッセージがあることが教えてくれる。
メッセージを見ると知り合いの女性から「ここのピザ、最高！」と書いてあったりする、というわけだ。
無論テキストだけではなく画像なんかも可能である。

Socialight

百式記事のコメントの人も書いてたけど、ほんまそのままSpaceTagですな。
記念パピコ（？）

ちなみに百式の中の人が書いてた

Location-basedなリマインダーサービスとか良さそうだなぁ

あたりは、私の友人の運営する位置情報携帯SNS「ポジタル」に実装されてます。
Java/BREWアプリあたりで常時監視、とかではないですが、こちらの記事の手を使って常時位置更新はできるようになってるので、ちゃんと設定場所に近づけばメール連絡してくれます。
さすがにアプリじゃないのでバイブレーションはしてくれませんが、文句があるならマナーモードにでもしとけ！

FastCGI「しか」使えない私にはうれしい限り。mod_perl？何それ？
とか言いつつ高度な話題には全然ついていけないけど。
lighttpdとの組み合わせが震源地？

でも何か某産廃処理場の環境監視サイト作った際はmod_perlで作ったような気がするな。
いやそれ以前にオリジナルフレームワークで作った初代携帯版ここギコはmod_perlだったわ。しょぼしょぼの。
今思い出した。

なんか意味もなく？Apache2.0に乗り換えたあたりから、mod_perl2.0は情報ないし、何時までたってもベータ版とか言ってるし、FastCGIエバンジェリストに出会ったし、でFastCGIにころころと。
その後Apache1.3なんて触ってないので自分がmod_perlやってた事さえ今まで忘れてたよ。

...なったかどうかは最近Google Mapsどころか位置情報からも疎遠なので私もしらないのだけど、Google Mapsアプリ作ってる友人から「どうもそうなったっぽいけど情報ない？」とメールが来たので、情報集めるために書いてみる。
NDOメソッド？

友人から来たメール：

なんだか急にGoogleの測地系が世界測地系になったみたいなのですが、なにか情報お持ちじゃないですか？
私が気づいたのか今日ですが、Webではそれらしい記事が載っていません。
URLのll=…..の記述と、サーチで「34.53424,135.720484」みたいに入力した時の検索結果は世界測地系のようです。
でもGetCenterLatLonで取れる値は日本測地のようで、APIは前のままのようです。

という感じのようで、もし事実だとしても完全には置き換わってないようなんですけど、この辺の経緯誰か情報ないですか？
私もTechnoratiとかでザクッと検索してみたけど何も引っ掛からないので...。

今日はネットで事情と事情とかをBLOGしなかった？
いろいろ事情あって、買ったもののほとんど目も通してなかったMapSer....
とか思った？

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

全てのノートパソコンにGPSが載ったらあなたはどんなサービスを作りますか？ -Life is beautiful-

なんか位置情報一言居士の俺に対する挑戦のように思えたのでちょっと考えてみた。
飽くまでノートパソコンに、というのが胆のような気がする。
ケータイとかと違って、必ずしも全ての人が持ち歩くものじゃないので、それで場所ごとの何かの統計を取るとか、ちょっと難しいかも。
また、単にローカル情報ってのも、GPSじゃなくても可視光通信やWiFi、ICタグでも、正確な位置は出なくてもローカル情報は取れる(むしろ使いやすい？)ので、ちょっと違うかなと。

飽くまでノートPC、GPS（経緯度取得）で、と考えると…。

サービスじゃなくてインフラだけど、IPアドレスの代わりに現在の経緯度を機器特定アドレスにして、近距離無線通信でのP2P基盤にする、というのはどうかな。
各ノートPCが現在位置ベースに無線発信して、反応のあったもののうち近いもの（かつ、速度変位等も総合して、そう簡単にハンドオーバーしそうにない相手先）を選んでコネクション張って、その連鎖でP2Pネットワーク築くとか。
もちろん通常のIPネットワークも並行して動くので、例えば大災害発生->ある地域にいる人々に無差別に救助情報送りたい->IPアドレスと経緯度アドレス両方が判っているPCに向けて情報発信->そのPCをハブとして周辺のPC全てに情報伝達、とか使えると思う。

その際、経緯度そのままをアドレスとして使うのは煩雑なので、コンピュータに処理させやすいコード形式、例えば前も紹介したLocapointフォーマットを経緯度アドレスのフォーマットとして使うとかな、いいんじゃないか。

等と強引に友人の商売に話を持っていったところで終わり。
ちゃんちゃん。

-- 追記 --

はっきり言ってネットワークについては詳しくないので、アホな事書いたかなと思って足りない知識で考え直してみたよ。
思い違いとかあったらツッコミよろしく。

書いた後最初に思ったのは、別に経緯度を通信のアドレスにしなくても、IPアドレスのエイリアスにすればいいだけなんじゃないかと思ったんだけど、でもそれじゃ、「直接」の通信はできないんだよね？
間違ってる？
近くにいるPC同士のお互いのIPが判っても、そのIPのセグメントが違ってたら、自分の接続するIPセグメントのルータなんかを経由して、わざわざ遠回りでコネクション張らないといけないんだよね？

IPv4では無理でもIPv6なら、捨てIPアドレスみたいなので近くにいると判明したPC同士で一時的に作って接続すればいいのかも知れないんだけど、その捨てIPアドレスも作れると言っても、基本的にIPの考え方自体はIPv4もIPv6でも同じだと思うので、結局捨てIPアドレスを作る同士が上位セグメントを共有しないと直接通信はできないと思うんだけど、それはどうするの？みたいな。
なので、IPを使うにしても、PCの現在地によって所属する上位セグメントが変わる、みたいな取り決めをしておけば、その範囲にいるPC同士は捨てIPアドレスで通信できる、という形にしてはどうかと思うのです。
でもって、世界一律同じセグメントにするわけにもいかないだろうし、かといってエリア毎にセグメントを変えると、エリアの境では物理的にどんなに近くても直接通信はできなくなるように思うので、それならどうせなら連続的な変化をする経緯度をアドレスに割り振って直接近い同士で通信しちゃえよ、みたいに思ったわけです。
IPのアドレスマスクの変わりに、通信したい範囲を経緯度差でマスクしたりして。

...おかしな事言ってますかね...？

うむ、忙しいと書くべき事より書きやすい事でエントリしてしまう。
いっぱい考えないと書けない事はついつい後回し、脊髄反射優先。

表層地盤の揺れやすさマップ

すごいな、軒並み大都市駄目やん。
ある程度の規模以上で揺れにくいのは広島・福岡くらいなもんか。こいつらもピンポイントでは揺れやすいのか。
まあ都市の発展は川近くの沖積平野・盆地だから当たり前と言えば当たり前なわけだけど。
わざわざ人間ってのは危ないとこに住んでるのか。

と言っても、飽くまで地盤の問題で断層の位置とかとは無関係の図だから、この図で真っ赤だから一番危ない、ってわけでもないだろうけど。
その辺総合した危険度マップみたいなのってないんかな。

ここは、ページは検索したいです。
きょう、検索する？
きょうねねの、ページみたいな検索ー！

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

OpenIDのメーリングリストで、OpenIDでのアカウントをベースに、自分のBlogサイト等メインURLをベースに繋がれるSNS実装ができた事を知った。
Videntity.orgという、OpenIDの認証サーバサービスが始めたサービスなのだが、すごい面白い。

まず、OpenIDがよく知られてないと思うので簡単に説明すると、自分を特定するURLとパスワードをIDのベースとして、OpenIDに対応したサイトならどこでもその組み合わせでログインできるようになるシステム。
例えば、Videntity.orgでkokogikoというアカウントを作ると、http://kokogiko.videntity.org/という個人ページが作られ、このURL（kokogikoだけでなく、飽くまでURL全体）をIDとして、OpenIDに対応したサイト（例えばLiveJournalとか）にログインできるようになる。
ただこれだと、どこでも共通でログインできるIDはできたけど、自分のBlogのURLとかじゃないので、面白くない。
その場合は、OpenID Delegeteという仕様を使えばよい。

<link rel="openid.server" href="http://videntity.org/serverlogin?action=openid">
<link rel="openid.delegate" href="http://kokogiko.videntity.org/">

とこういう記載を自分のサイトのHTMLヘッダ領域に加えておけば、http://kokogiko.net/をIDとしてログインしようとしたら、OpenIDクライアントサイト側ではそれをhttp://kokogiko.videntity.org/と読み替えて、そのURLでOpenID認証サーバに認証を行ってくれる。
これで、http://kokogiko.net/でVidentity.orgにログインできるようになる（この際、http://videntity.org/profile/kokogiko.net/というアカウントサイトが作られるが、これはhttp://kokogiko.videntity.org/とは別扱いになるので、その点のみ注意）。

以上は、Videntity.orgでOpenIDのアカウントを作るところから説明したが、既にLiveJournalでOpenIDアカウントを持っていたり、或いは今はTypeKeyもOpenIDサーバとして機能するので、その辺を持っている人は上で書いたkokogikoにあたるVidentity.orgのアカウントを作る必要はない。
そのLiveJournalなりTypeKeyでVidentity.orgにログインすれば、上で書いたhttp://videntity.org/profile/kokogiko.net/というアカウントサイトが作られるところから始められる（はず。試してないけど）。

で、面白いのはここから。
そうしてhttp://videntity.org/profile/kokogiko.net/にログインすると、自分の友人や家族、恋人なんかのWebサイト（Blog等、飽くまで普通のWebサイト!!）を、細かい関係性等も登録可能で、かつ公開/非公開の設定も可能な形で、登録していけるのだ。
公開したものはSNSの友人リンクのような形でアカウントサイトで閲覧できる。
FOAFも自動的に提供される。
で、普通のWebサイトで関係性を記録していけると何がすごいかというと、OpenIDでは上記してきたようなやり方で、自分のWebサイトのURLをIDとしてグローバルなアカウントを作る事が可能だから、友人も同じ形で自分のサイトのURLをベースにVidentity.orgに自サイトのアカウントサイトを作る事ができるので、すなわちこれ、そのまま各個人のサイトがSNSのポータルと化して、巨大でオープンなSNSが出来るということなのだ。
これはすごい。

これに将来RESTインターフェースなんかがついたら、もっとすごい事になる。
MovableTypeなんかのプラグインで、サイト再構築の際に自分のOpenIDでSocial_Networking_UnlimitedにRESTアクセスして、最新の自分の友人のWebサイトのリストを取得するようにすると、友人のサイトへのリンクには全てXFNの属性を自動で与えたりできるようになる。
或いは、サイトのページを全部動的生成にする必要があるけど、個人のページもOpenIDのクライアントサイトとなるような作りにしておけば、飽くまで個人のBlogページの範囲で、家族や友人や限られた人にしか公開しないコンテンツも簡単に実現できるようになる。

というわけで、俺はもうhttp://videntity.org/profile/kokogiko.net/を登録したので、友人サイトを登録しておこうと思う。
その上で友人達にはVidentity.orgへの参加を呼びかけていこうと思っているので、面白いと思った人はぜひ参加して欲しい。

先日のセミナーも結局行けなかったりと、しばらくオークニーさんのサイトにもご無沙汰してたら、昨日久々に見るとすごいニュースが。

オープンプラットフォームによる地図配信サービス「GIS Data Network」を発表

「GIS Data Network」は、電子地図ブランド「MapFan」として定評のあるインクリメントＰの地図データを、オークニーが運用するＷＭＳサーバに格納し、デスクトップにGISソフトを持つユーザに対してデータ配信ＡＳＰとして提供するサービスです。
デスクトップ環境でGISを利用するユーザは、ベースマップとなる商用地図データの活用において、コスト面での問題や運用面での手間が避けられませんでしたが、この「GIS Data Network」サービスにより、インターネット接続環境を通じて、低コストで高品質の地図データを利用できるようになります。
WMSというオープンプラットフォームで運用しますので、オープンソースのGISユーザはもちろん、多くの商用デスクトップGISユーザ※2も、このサービスを利用することができます。

価格（消費税込み） 　1ユーザ、月額数千円　を予定

WMS（Web Map Server) のクライアント対応ソフトと言えば、MapServerも対応しているわけですが...。
このサービスに加入すれば、アンテナ奪取（まあ運営譲渡しましたが、例えばそんなサイトまた作るとして）やらの地図にも最新版が使えますか？
ついに神到来でしょうか。

それともやっぱり、ニュースリリースレベルでは明確に「Webでの利用禁止！」とまでは書かれていないものの、記事中に散りばめられている「デスクトップ」「デスクトップ」の文字はやっぱり「はい、ここ、テスト出るよー」「orz」というわけでしょうか。
もちろん、Webで使えなくても、十分魅力的な値付けではあるのですが、個人的にはやっぱり「orz」というわけで...。

やっぱりこの辺、社長さんから直接見解いただければ嬉しいなと。

あ、さらにもう一つサービス開始のようですね。
こっちはまさにWeb用途、ジオコーディングや道路地図等もろもろのサービス、さらにMapServerのサポート付き（というよりは、MapServer商品に地図の諸データバンドルという感じですが）で、

オープンソースを活用したWebマッピングパッケージ「Orkney MapServer ETD edition」を発表

株式会社オークニー（本社：横浜市中区海岸通1-2　JA共済ビル6F　代表取締役：森亮）は、インクリメントＰ株式会社（本社：東京都目黒区下目黒1- 7-1　代表取締役社長：森秀一）の協力を得て、地図データをバンドルしたオープンソースWebマッピングパッケージ「Orkney MapServer ETD edition」を開発し、10月下旬からの市場展開を開始します。

 製品構成
・Orkney MapServer4.6
・基本アプリケーション（ソースコード・解説書含む）
・地図データ（インクリメントＰ製）
　　1,290都市（2005年10月1日現在）をカバーする詳細地図
　　全国をカバーする1/25,000レベルの道路地図
　　約3,200万件の住所ポイントデータ（番地号レベルを含む）
・電子メールによるインストールサポート

 予定価格　市区町村あたり　900,000円（税別）から

こっちは流石に手がでまへん...。

オークニーさん！
今回のが利用できるかどうかは別として、GoogleがGoogle Mapsで世界のハッカーを味方につけたように、是非ハッカー向けのソリューションを！

いろいろ事情あって、買ったもののほとんど目も通してなかったMapServer黒本ですが、最近になってやっとパラパラと目を通し始めると中々の良本。
題名からしてそうなのだから当たり前と言っては当たり前だけど、MapServerのリファレンスとしてはWeb Mapping Illustratedより詳しい部分がある。

• 普通MapScript=PHPと言う感じで、他の言語は刺身のツマ程度なのだが、この本ではPerl、Python、PHPそれぞれに1章20ページ前後ずつ割いて詳しく解説
• MapScriptをmysqlベースで使う場合も言及
• マップファイルの個別の属性について個々に解説。
• 各種コマンドラインツールも個別に説明（もっとも、ほとんどサンプルのないのもあるが...。）

逆にPostGISに言及してなかったりして面白いが。
それに、Web Mapping Illustratedの方ではかなり詳しく書かれているGISの考え方に関する説明がほとんどない。
という感じで、相互補完する感じの一冊です。
PerlでMapServer使おうと思っている人は、是非。

Beginning MapServer: Open Source GIS Development (Expert's Voice in Open Source)

posted with amazlet on 05.10.12

Bill Kropla
Apress (2005/08/22)
売り上げランキング: 32,373

Amazon.co.jp で詳細を見る

TrackBackを受け付けてくれない問題、どうも「403 Throttled」が出る確率が圧倒的に高いようなのでちょっとMT::Trackback.pm、MT::App::Trackback.pmあたりを確認。
どうも、MT::App::Trackback.pm内の、同一IPからの頻繁なTrackBackをはじくはずのルーチンで、検索条件にIPアドレスが入っていないバグのために、SPAMを含めた全てのTrackBackの頻度で弾かれてしまっているっぽい。
どこのBlogでも同じだと思うけど今TrackBackスパムの来襲は雨霰のごとく、なので、TrackBackスパムの投稿が頻度フィルタを通り抜けると、その後しばらく一切のTBが受け付けられなくなってしまい、時間が過ぎたと思えば最初にフィルタを通過するのはスパムなので、結局一切まともなTBが受け付けられない、という状況になっていたわけです。
ついでに言えばスパムTBは頻度フィルタの通り抜けには成功しても、その後のプラグインのBlacklistやKeywordフィルタで引っ掛かるので、かくして一切のTBが受け付けられない状況になっていた、というわけです。

とりあえず、検索条件にIPアドレスを加えて、TBを受け付けるようになった事を確認しました。
ついでに、TrackBack Pingに対するXMLレスポンスが、UTF-8決め打ちにも関わらずHTTPヘッダの文字コードがBlogの設定文字コードを返すようになっていたので、それも気持ち悪かったのでついでに直してみました。

*** Trackback.pm.orig   2005-10-12 00:40:13.000000000 +0900
--- Trackback.pm        2005-10-12 00:45:46.000000000 +0900
***************
*** 70,75 ****
--- 70,77 ----
      $app->send_http_header('text/xml');
      $app->{no_print_body} = 1;

+     $app->{charset} = 'utf-8';
+
      if (my $err = $param{Error}) {
          my $re = join '|', keys %map;
          $err =~ s!($re)!$map{$1}!g;
***************
*** 126,131 ****
--- 128,134 ----
      require MT::TBPing;
      if ($app->config('OneHourMaxPings')
            <= MT::TBPing->count({ blog_id => $tb->blog_id,
+                                  ip => $user_ip,
                                   created_on => [$from] },
                                 {range => {created_on => 1} }))
      {
***************
*** 137,142 ****
--- 140,146 ----
      $from = sprintf("%04d%02d%02d%02d%02d%02d",
                      $ts[5]+1900, $ts[4]+1, @ts[3,2,1,0]);
      my $count = MT::TBPing->count({ blog_id => $tb->blog_id,
+                                     ip => $user_ip,
                                    created_on => [$from] },
                                  {range => {created_on => 1} });
      if ($count >= $app->config('OneDayMaxPings')) {

FastCGIが原因なのか、MT3.2が原因なのか判らない不具合が噴出。

• 先にも書いた、XMLRPCでの投稿時に自動トラックバックが打たれない問題
• 他サイトからのトラックバックが受け付けられない
  (TBを受け付けてくれない点では一緒なのだが、現象は「TBのHTTPリクエストはPOSTでおながいしまつ(POSTで打ってるっつうの!!)」「403 Throttled」とか毎回違って、意味不明)
• 管理ツールでのプラグイン「利用/利用停止」の切り替えがうまくいかない
  (何度利用停止にしてもうまくいかないと思えば、突然まとめて利用停止になってこんどは利用可にできなくなったりする)

なのでとりあえず一旦非FastCGIバージョンに戻して、問題の切り分けを図る。
うーん、せっかく再構築もXML-RPC投稿も早くなって喜んでたのに...。

最後のプラグイン切り替え問題は、元に戻して解決できた。
が、FastCGIの問題と言うよりは、これもMT側の中身の作り方のような気がする。
CGI::Fast経由でFastCGI使ってきて、経験的によく出会う問題に、CGI::Fastのループの中でCGI系のオブジェクトを一度でも使ってしまうと、以後再起動させるまでGET/POSTパラメータあたりが更新されなくなって挙動が不審になってしまう、という現象があるのですけど、それに近い振る舞いなので...。
どうしてループ内でCGIオブジェクトを作ると挙動不審になるのかまでは追えてないんだけど、例えばもし、CGIオブジェクトが内部で標準入力をもう一度読み込んでしまう事が問題なのだとしたら、MT::Appも内部で標準入力開いているので、同じ理由で不安定になるという事は考えられるかなと。
飽くまで推測。

後のはどっちが悪いのかよく判らない。
Ogawaさんとこでは、上のとか、トラックバックがらみの不具合出てないのかな？
等と書いて、さりげなくXMLRPCでの自動トラックバックテスト。

テスト結果：
やっぱりXML-RPC経由だと自動トラックバックされない。
投稿後、WebのUI上で再保存すると自動トラックバックされる。
3.2にするまではXML-RPC経由でも自動トラックバックされてたから、バグにせよ仕様変更にせよこれでMT側の問題確定。

最近開発を続けていたヒューマンフ..

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

こうさぎエントリをテスト用に利用。
トラックバック送信先

とりあえず、まだ3?4サンプルくらいしか試してないのでアレですが、

言及先BlogがTrackBack Autodiscoveryに対応していると自動でTrackBack Pingを打ってくれる機能がMTにはありますが、
どうも3.2にアップデート以降、この機能がXML-RPC経由で投稿した時に動いていないっぽい。
BlogWriteで投稿した時はTrackBackが送られないのに、後で同じエントリをMTのUI上で再保存したら、TrackBackが送られる、と言うケースが何度か。

今のところ他のところではレポートされてみないだけど、どうなんだろう。
不具合ではなく仕様変更かとも思った。
Blogエントリツールからエントリすると、ついうっかりしてツールの方からもTrackBackを打ってしまって、TrackBackの2重打ちをしてしまうミスが私自身過去何度かあったので、もしかしてXML-RPC経由だと自動TrackBackを抑制するような設定でもあるのかと思ったけど、UIにもmt-config.cgiにもそういうのは見当たらないっぽい。
mt-xmlrpc.cgiのFastCGI化以前から発生していたので、うちのバグでもないと思う。

というわけで、とりあえずMovableType本家の3.2不具合ページへとリンクを貼ってみた。
機能がうまく働いているなら、これにTrackBackが打たれるはず。
BlogWriteからの投稿では打たれず、その後MTのUIからの再保存で打たれるようなら、現象としては再現確定としてよいかと。
もちろん、まだ不具合ではなく仕様変更の可能性はあるけれど。

実験結果：
やっぱりXML-RPC経由ではTrackBackされませんでした。
今からMTのUI経由で再保存します。
これでTrackBackされれば現象確定。

というか、FastCGI化したのだからmt-xmlrpc.fcgiですが。
さらにいうなら、Rewriteかましてるから名前なんざ別になんでもいいわけですが。

Ogawa::MemorandaさんのとこのMT 3.2 on Apache + FastCGIとMT-XSearchをFastCGI化するに触発されて、mt-xmlrpc.cgiをFastCGI化。
トリガスクリプトはOgawaさんとこのdispatch.fcgi流用させてもらう形で、MT::XMLRPCServerはMT::App化されていないので、MT::App::XMLRPCServerを作って対応。

mt-xmlrpc.cgiはサーバ化のフレームワークをXMLRPC::Transport::HTTP::CGIに頼っていたので、MT::AppやCGI::Fastのリクエスト/レスポンスオブジェクトをそのまま扱えないみたいなのですが、こちらの記事を参考に、XMLRPC::Transport::HTTP::CGIの自前のI/Oを抑制して、CGI::Fast->MT::App経由のリクエストデータをHTTP::Requestに変換して食べさせ、結果をHTTP::Responseで得てMT::Appで出力するという形でMT::App::XMLRPCServer化。
と書けばスマート？そうなんだが、実際にはHTTP::Requestへの変換周りで、MT::Appが単純にHTTPリクエストヘッダを総取りするようなインタフェースを持っていな(いっぽ)かったり、CGIオブジェクトをクエリとしてMT::Appに与えた場合に、POSTデータがMT::App経由で取れな(いっぽ)かったりと、色々制約を力技でドタバタしたので、かなりカコ悪いコードになってます。
おまけにApache1.3環境持ってないし、mod_perlに詳しくないしで、mod_perlで動くのかどうかは判りません。

そんな感じですがコード晒しますので、興味のある方はどーぞ。

package MT::App::XMLRPCServer::XTHC;

use strict;
use XMLRPC::Transport::HTTP;
@MT::App::XMLRPCServer::XTHC::ISA = qw(XMLRPC::Transport::HTTP::CGI);

sub handle { shift->SOAP::Transport::HTTP::Server::handle(@_) }

package MT::App::XMLRPCServer;

use strict;
use MT::App;
@MT::App::XMLRPCServer::ISA = qw( MT::App );
use MT::ConfigMgr;
use MT::XMLRPCServer;

sub init {
    my $app = shift;
    $app->SUPER::init(@_) or return;
    $app->add_methods(main => \&view);
    $app->{charset} = 'utf-8';
    $app->{default_mode} = 'main';
    $app;
}

sub view {
    my $app = shift;

    my $server = MT::App::XMLRPCServer::XTHC->new;
    $server->dispatch_to('blogger', 'metaWeblog', 'mt');

    $server->request(__make_request($app));
    $server->handle;
    my $res = $server->response();

    $res->headers->scan( sub{ $app->set_header(@_) } );
    $res->content;
}

sub __make_request {
    my $app = shift;
    my ($u,$c) = ();
    my %h = ();
    if ($ENV{MOD_PERL}) {
        $u = $app->{apache}->uri();
        %h = $app->{apache}->headers_in();
        $c = $app->request_content;
    } else {
        $u = $ENV{REQUEST_URI};
        foreach my $envkey (keys %ENV) {
            if ((my $key) = $envkey =~ /^HTTP_(.+)$/) {
                $key =~ tr/_/-/;
                $key =~ s/([A-Z])([A-Z]*)/$1.lc($2)/ge;
                $h{$key} = $ENV{$envkey};
            }
        }
        if (UNIVERSAL::isa($app->{query},"CGI")) {
            $c = $app->{query}->{"POSTDATA"}->[0];
        } else {
            $c = $app->request_content;
        }
    }
    return HTTP::Request->new($app->request_method,$u,HTTP::Headers->new(%h),$c);
}

1;

先日紹介したLocapointを扱うLocation::GeoToolの拡張モジュール、Location::GeoTool::Plugin::Locapointを作りました。
とりあえずまだ経緯度 <=> Locapointの変換が出来るだけで、省略記法や経路表示等には対応していませんが、とりあえずSubversionにアップしました。
CPANにもアップ済みですが、反映はまだされていないみたいですね。
というか、反映されればこのリンクから辿れます。

Location::GeoTool自体でネイティブに扱えるようにしようかと思いましたが、Locapointの名を冠したPerlモジュールがCPANにあればLocapointの宣伝にもなるかなと思い別モジュールにしました。
久しぶりにLocation::GeoToolの中身見たけど、ゴチャゴチャしてるなあ...いっぺんリニューアルしないとダメっすね。
本体を改造するとそういうあちらこちらをいじりたくなってしまうというのも、独立させた理由だったり。

まあ元が大したモジュールじゃないですが、Perl使うの久しぶりにもかかわらずサクッと片付きました。
最近この本読み出したのが大きいかなあと。
なんか目から鱗が落ちて、世界が変わったような感じがします。オススメ。

Perlプログラミング救命病棟

posted with amazlet on 05.10.07

ピーター・J・スコット トップスタジオ 伊藤 直也
翔泳社 (2005/09/06)
売り上げランキング: 7,023

おすすめ度の平均:

目的のある本だが、楽しめる要素も多い

Amazon.co.jp で詳細を見る

本ブログでも何度か紹介してきたSpaceTag Serverですが、ST Serverと名前を変えて再出発したようです。
再出発と同時に、これまでPostgreSQLからMapServer、Java、Python、XMail、etc...ととにかくWindows上でのサーバ・開発ツールをほとんど統合して、300MB以上の巨大なパッケージになっていたのが、Apache、MySQL、Perl、PHPに絞って76MBと軽量化したパッケージになったようです。
＃ちなみに韓国語、英語サイト等からはまだSpaceTag Serverがダウンロードできる模様。

しかしPostgreSQLとかその辺をなくしたのは、よく思い切ったなあと思います。
と言うのも、私も以前こんな事書いたので、パッケージサイズが小さくなるのはいいんだけど、分割されてカフェテリア形式に好きなモジュールをプラグイン選択できるようになっていればいいのであって、PostgreSQLとかも使えていたのを完全になくしてしまっては、対抗プロジェクトともいえるXampp for Windowsあたりに対する優位性がほとんどなくなってしまうから。
Xamppの方は同様にApache・MySQL・PHP・Perl（Perlはオプションプラグイン）が使えて、さらに今ではFTP・Mailサーバまで統合されており、しかも相手はアップデートも含め完全無料で、ソフトウェアのアップデート頻度でも遥かに負けているのに対し、サーバソフトのラインナップが相手以上だったのがSpaceTag Serverの売りだったのに、それを捨てて相手より対応範囲を減らしてしまうというのは、吉と出るか凶と出るかは判りませんが、すごい選択だと思います。
アップデート頻度等で致命的負けているので、メンテナンス範囲を絞る事で相手以上の開発速度を確保しようと言う事でしょうか。

いずれにせよ、Xamppは私も、先日会社でMantisをテスト導入してみる必要があったので会社の自分のPCに初めてインストールしてみたのですが、インストーラは完全日本語化されていて、サクサクッとインストールできました。
さすがに管理ツールは英語なのですが、ほとんどSpaceTag Serverと同じ使用感の使いやすいUIで（私は以前のXamppを知らないので、どっちが真似したのかは不明ですが）、SpaceTag Serverに慣れていれば難なく管理できます。
というわけで、現状でのアップデート状況や、対応ソフトの多さ、そしてアップデートも含め無料と言う事で、無償の個人ユースにおいては、今はXamppを使う事を個人的には薦めます。
とは言えXamppはオープンコミュニティによる成果物なので、私自身官公庁なんかを相手にした仕事をしていて、不具合発生時に責任所在の切り分けが難しいフリーやオープンソースのソフトの導入には気を使うのですが、そういう不具合発生時の迅速なサポートや、責任所在の明確化が要求されるエンタープライズな用途に関しては、企業が商用パッケージとして提供しており、サポートも受けられるST Serverを使うのがベストなのかなと思います。
UIまで含め、全て日本語化されてますしね。

ただ私が以前、この辺やこの辺のエントリで言及したような、SpaceTag Serverに対する期待、単なるサーバソリューションではなく、人にサーバを意識させないWebアプリケーションのプラットフォームに発展していく可能性は、ほぼ失われたかな、と感じています。
というのも、私の元同僚で親友、かつSpaceTag ServerのアーキテクトでもあったRisapapa氏は既にSpaceTag社を辞め、また彼の子飼いの技術者達もみんな解雇されて、今の同社内の技術者は私の知らない人ばかりなので...。
（以前のエントリで「突如親友に3年間会えなくなる」と書いたのは、その辺の絡みで、彼が同社を辞めるにあたっての契約で、1年間はサーバ事業に携わらない、3年間は私のような退職者含め同社に関わった人間と接触しない、という条項が加えられているためでした）
Risapapa氏は私のアイデアも正確に理解してくれ、さらに私が及ばないレベルにまで発展させてくれていたので、彼のソリューションが世を変える事を期待していたのですが、今のSpaceTag社内の技術者の方がこの辺の価値を判ってくれているか、また判ってくれていても形にする技術力があるかはブラックボックスですので、私としては私のアイデアの発展を期待するのは、Risapapa氏が1年の縛りが解けて、再度サーバ事業に乗り出して以降の楽しみとしようと思っています。

ｵﾓｼﾛｿｽ。

ページがどんなキーワードで検索されたかをTagCloud風に表示させるくっつきサービス

javascriptファイルをページに貼り付けておくだけで、そのページに訪問した際に使われた検索キーワードを自動的に検知してそのキーワード達をTagCloud風に表示させる物を作ってみました。
機能は上記のものだけでいたってシンプルです。

ソーシャルブックマークの寄ってたかってタグ付けと、Blogのオレオレタグ付けの中間的アレとして、検索キーワードをベースに自分のページのタグを再構成するような機構があれば面白いなあとか、ちょうど昨日考えてたら、今日これ見てビクーリ。
まあ検索ワードが最適かどうかは別として、Blogのタグ付けもカテゴリ分けほどではないにしても面倒だし、センスも要求されるし、Blog作者任せだけでなくて他者の目からのタグが反映できる経路があればいいと思うんだけど、これはその走りといった感じなのかな。

あと、JavaScriptで被検索キーワード検知するなら、そのキーワードでAmazon検索してAffiliate出力出すサービスできないかな。
drk7.jpさんとこの、Amazonサーチ互換のフォーマットで、検索キーワードでのAmazon取得結果が少なかったり、或いは検索無しで訪れたりされた場合は、drk7さんの方での結果を出すという形で。
もっと欲を言えば、検索キーワードからのAmazonサーチかdrk7.jpさんからのAmazonサーチか、の2択じゃなくて、このページはピンポイントで固定アフィリエイト商品、とか制御できるツールがあるともっと嬉しいんだけど。

明らかにMova GPS携帯(F661i、F505iGPS)と位置取り合いの仕様が変わっているFOMA GPS携帯(SA700iS)ですが、ひっそりと取り合い仕様が公開されていました。
というか、作ろう！iモードコンテンツのトップページからの遷移は今もって判らないんだが、DoCOMoのドメイン指定で「GPS」で検索したら見つかった。

GPS機能への対応について

これで俺の中途半端公開？の携帯位置情報取得Perlモジュールも、FOMA GPSに対応できるというものです。

でも、モジュール作っても動作検証できないので（持ってないし）、また検証用の携帯サイト作らないといけないな。
吉野家検索あたりでもまたでっち上げるか。
というか、吉野家以外に「2ちゃんねらー」が検索できて楽しいネタとかないかな？
ここギコの出自が2ちゃんねるだけに、そこで受けるもんにしたいな。

位置情報の会社を起業した奈良の友人が、最近開発を続けていたヒューマンフレンドリーな位置情報表記仕様、Locapointの公式サイトがプレオープンしました。

Welcome to Locapoint Official Site!

Locapoint is the first 'User-Friendly Geo Code' that is designed for better human interface and usability It has a "Alphabet, Alphabet, and Number" rhythm and easy to remember and communicate between people.
Locapoint also has many advantages in computer usage.

Enjoy GIS with Locapoint!

という感じで、「アルファベット、アルファベット、数字」という組み合わせの繰り返しで判り易く覚え易い位置表記法に関する仕様になっています。
これで、ある場所の絶対値を指すのに、「俺の家、東経135.94567度、北緯35.65432度なんだー」等と覚えられない言い方をしなくても、「俺の家、DF8.FG6.HJ7.KJ8なんだー」と言う言い方が出来て、こっちのが遥かに覚えやすいですよね？（ちなみにこの例は無茶苦茶ですので、悪しからず。）
他にも線構造・面構造の表し方、省略記法等いろいろ考えられてて、とても面白い仕様になっています。

詳細の仕様に興味のある方は、こちらにあります。
日本語の情報が欲しい方は、作者が日本語ブログを始められているので、こちらへ。
いろいろ面白いアプリケーションも作られているようなので、それらも許可出次第紹介します。

というか、私のPerlモジュールLocation::GeoToolもLocapointを扱えるように改造して、同時に公開しようかと話したりもしていたのですが、昨今のドタバタの間に追いつけなくなってしまっていました。
早めに対応します。

今日はねねたちが、演す日時・
場所が決まりました
....
と、ここは思ったの♪

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

しばらく離れている間に、ジオコーディングでいろいろ動きがあったみたいですね。
ご自身作られたものも含め、Nakamura-KU ADDICTさんとこにまとまってるみたいですが、

インチキGeocoderプレビュー

先ほどBLOGにアドレスマッチングのSOAP版があるというタレコミ情報を頂きました。
http://www.geoap.jp/service/trial/trial_adrmatch.htm
日本にもついにSOAPのGeocoder誕生ですね。

こいつは有料ですね（1000件までは無料とありますが）。

私もちょっぴり頑張っていることをアピールすべくちょっことだけ公開。
http://ws.podzone.net/share/geocoder.cgi (自宅サーバなので落ちている可能性あり)
住所を入力していただき、データベースに問い合わせて、住所の位置がわかった場合に、GoogleMap API上に表示します。

おおー、すごい。でもコメント見ると、 街区レベル位置参照情報の精度の低さ？に苦戦されている模様。

先ほど気づいたのですが、 Geocoding.jpさんも動き出していますね。
精度が全く違います。
商用データを使っているようなのでかなり精度が高いです。

マジっすか > 商用データ
すごい、個人の趣味でやられてるみたいだけどどうやって手に入れてるんだろ。
いいなあ。

で、個人的には、RESTで住所送って経緯度返すジオコーダもいいんですが、テキスト文書送って、そのテキストに含まれている住所をピックアップして返すジオコーダもあればいいなあと思います。
ちょうど、はてなダイアリーキーワード自動リンクAPIみたいな感じで。
このやり方に関するアイデアは前から持ってた（というほど大したアイデアでないが）んですが、最近はてなキーワードの自動リンクは巨大な正規表現でやっているという話を知って、考えを一歩進めたので、ここにアイデアだけ公開します。
自分で実装は...やってる時間がない...誰かやって。

いや、大したアイデアでもないんですけども。

文章中の住所マッチする時って、単に地名っぽい単語があったからといって何でもマッチできるわけでもないですよね...「城東町」って言葉が含まれていたってどこにリンクすりゃいいのよ、ってのもあるし、「在庫出血大放出！！」ってな感じになっても困る（ちなみに、「はなてん」と読みます）。
ある程度以上の正確ば場所と特定できる住所って、まあ大雑把にどこかで切るとすれば、都道府県だとよく省略されるし、という事で市区町村が含まれるか否か、で決まると思うんですよ。
で、市区町村の数なら全国でも既に大合併進んでてせいぜい3000強かその程度。
その程度なら、テキスト中にそれが含まれるかどうか検索したって、それほど負荷はかからないと思うので、まずそれが含まれているかどうか探し出す。
その探し出す方法として、はてなキーワードのこの記事を読むまでは3000通りの市区町村名のループかけて調べてやるつもりだったんですが、はてなキーワードのやり方を知った今では、3000通りの市町村の正規表現でマッチしてやればいいかなと。
正規表現だと、表記のぶれへの対応にも親和性高いですしね。 /......|龍ヶ崎市|..../とかやる代わりに、/......|(龍|竜)(ヶ|が|ケ)(崎|?)市|..../とかやってやればいいわけだし。

で、そうやって市区町村レベルの表記を見つけたら、今度はそれぞれの市区町村に含まれる町丁目のリストが、DBからせいぜい3桁-4桁前半の範囲で求められるはずだから、同じようにその正規表現作ってやって、市区町村名に続いてその中に含まれる町丁目名が出てくるかを調べてやればいい。
そこでもマッチすれば、今度は...番地、または...番...号の世界だけど、こっちはDBから候補リストを出してマッチするのではなく、「２丁目７番９号」でも「2-7-9」でも「二の七の九」でも引っかかるような正規表現を組んでやって、テキスト側にマッチさせ、それでマッチされた数値情報からDBを検索したらいい。
というか、同じ正規表現だから町丁目リストのマッチングと下位の街区部分正規表現のマッチングは1工程にもできるかな。

という感じのやり方で、テキスト中の住所表現に位置情報を付与できると思うんだけど、誰かやってみてくれないかなあ。
それができるようになれば、応用として、

• 「城東町」という単語自体は市区町村から独立して出てきても、同じテキスト中に「愛知県名古屋市北区」や「高槻市」、「姫路市」等が出てくれば適切に処置する
• 京都特有の市区町村と町丁目間に入る「...上ル」「...西入ル」といった表現や、町丁目下に慣習的な字・大字表現が入るような場合にも対応

したりもできるようになるんじゃないだろうか。

とりあえず忙しかった状況も一息。
狂言は明日、仕事の客先報告会は火曜なのでこいつらもまだ終わってないけど、狂言は今日の自主練習終えたら後はやるだけだし、仕事の資料作成も大過なく終わった感じなので、ちょっと中休み的ながら落ち着いた感じ。
でも別の資料の作成手伝いがあるので、やっぱりGISセミナーは行けそうにもないけれど。
個人プロジェクトの方も1つは採用され1つも応募は終わって、いや採用されてからが大変なんだから前に進まなきゃなんだが、まあ一安心。

てな感じの息抜き状態なので、徒然にMovableType 3.2に置き換えてみた。
置き換え自体は非常に簡単。
ダウンロードしたファイルを展開し、設定ファイルを書き換えて、上書きしてやるだけ。
ただし設定ファイルはこれまでのmt.cfg（とDBパスワード設定用のmt-db-pass.cgi）から、mt-config.cgiに一本化されてます。
これで、mt.cfgの中を覗かれないように.htaccessの設定とかいじってやる必要がなくなりました。
一本化されたためにDBPasswordフィールドが増えた以外は、これまでの設定と特に変わりない模様...3.2以降の新設定等は未確認ですけど。

上書きしてやれば、これまでのアップデートではmt-upgrade.cgiを実行してたけど、このバージョン以降は管理スクリプトであるmt.cgiにアクセスしてやれば、初回にアップデート作業中である事を認識して、自動でDB構成の更新とかをグラフィカルにしてくれる。
これは便利...というか、別に初回の設定時のアクセス先がmt-upgrade.cgiかmt.cgiかの違いだけなんだけど、何となく心理的な安心感がある。
mt-upgrade.cgiも同梱されているので、これまでの形でのアップデートもできるのかな？これはやってないので未確認。
ただ何を言うと、その辺の手順を説明しているマニュアル中で、以前ならアップグレード時だけに必要なmt-check.cgiやmt-upgrade.cgiといったスクリプトは、セキュリティホールになり得るので名前を変えるなり削除するなりするよう案内されていたはず...なのに、作業が便利になったせいかそれに関する言及がなくなっているのが問題と言えば問題な気もする。

で、使ってみた感じですが、細かい所で便利になったなあ、というか気が効くようになったなあというのが第一印象。
例えばトラックバックやコメントの管理では、これまで迷惑トラックバック・コメントに対処するには、IP-Bangしている場合各トラックバック毎に迷惑IPに設定してやって、その後削除するという面倒な作業がありましたが、3.2以降は記事を選択して「迷惑コメント/トラックバックに指定」としてやると、記事上からの削除と迷惑フィルタへの登録あたりの作業をまとめてやってくれます。
他、これまでのバージョンでは、コメントを付けられた自記事は辿れるけど、トラックバックを打たれた自記事はなぜか管理ツール上からは辿れなかったんですが、それが辿れるようになってたり、細かい点で使い勝手がよくなってます。
大きな新機能とかは未確認ですが...あ、今見たらメインメニューにエントリー全体に対する検索・置換機能とかあるみたい...これはナニゲに便利そう。
...てな感じで、大分使い勝手がよくなっているみたいです。
置き換えも簡単なので、今までMovableTypeのUIにイラついていた人なら、置き換える価値はあるかも。