マッシュアップアワードで賞を取られていた、ふむふむソフトさんの手書き地図検索：CHIZTEKというサービスがあります。
地図画面上でマウスで手書きポリゴンを描くと、そのポリゴン内に含まれるお店等を検索してくれるという、直感的で面白いサービスです。

▲ マウスで書いたポリゴン内のお店検索 ▲

ポリゴンに内包されるPOIの検索、というのは極めてGIS的な発想なので、このサービスを見た時はすごく興奮しました。
どうやって実現しているのか、と聞いてみると、POI（Point of Interesting：興味の対象となるスポットの意）自体はポリゴンの最小内接矩形（MBR）内に含まれるものを全部取ってきて、クライアントサイドのJavaScriptでポリゴン内に入っているか否かを判定するアルゴリズムを組み、フィルタリングをしているそうです。
JavaScriptが使いこなせていない事もありますし、その手の本格的なアルゴリズムの実装が苦手な事もあって、私ではとてもできない技術力です。
すごい。

でも、サーバサイドで、かつ自力実装ではなくツールを使ってよければ、与えられたポリゴンとPOI群に対し、ポリゴン内に含まれるPOIをフィルタリングすることは比較的簡単に可能です。
PostGISが、その問題を解決してくれます。

PostGISが、DB内に蓄積された位置情報データについて、ポリゴンへの内包等の計算をして結果を出してくれることについてはよく知られていると思いますが、PostGISのコマンドもしょせんはSQLなので、DB内への問い合わせだけではなく、

SELECT 1+2;

みたいな計算もSQLはオンザフライで結果を返してくれるのと同様、地理情報計算もオンザフライでやってくれます。

例えば、どこかのWeb APIを通じて、

• 経度136度緯度33度
• 経度136度緯度34度
• 経度140度緯度50度
• 経度135度緯度40度

の4つのPOIを得たとします。
このPOIのうち、

• 経度135度緯度35度、経度137度緯度30度、経度139度緯度35度

の3点からなる三角形ポリゴンの中に含まれるPOIだけを抜き出すには、以下のようにすればOKです。

SELECT AsText(Intersection(GeometryFromText('POLYGON((135 35,137 30,139 35,135 35))',4326),
GeometryFromText('MULTIPOINT(136 33,136 34,140 50,135 40)',4326)) );

結果：MULTIPOINT(136 33,136 34)

で、２つのPOIだけが三角形の中に含まれることがわかります。
やっている事は、POLYGON（多角形）とMULTIPOINT（複数の点の集合体）の交わる図形を求める関数（Intersection）を求めているのですが、その結果は当然MULTIPOINTになるはずなので、その戻ってきたMULTIPOINT内の座標をピックアップしてやれば、ポリゴン内に含まれる点が判る、ということです。

ただしこのやり方で注意して欲しいのは、PostGISは座標の扱いは飽くまで曲率のない直角直交座標として扱われるので、ここで内包判定に用いられるポリゴンの辺は、頂点間を結ぶ大円上の弧とはならない（つまり楕円体上での最短経路とはならない）、ということです。
なので、一つの街の中でのポリゴン内の内包計算なんかだと実質上問題になるような誤差は生じないでしょうが、上の例のような緯度経度が1度以上変わるようなでっかい領域での計算だと、望むような結果は得られません。

また別の問題として、この方法だとSQLの中に含められるPOIのデータは経緯度データだけとなるため、このSQLの実行結果とPOIのその他の属性を紐付けるのは経緯度データだけ、ということになります。
なので、SQLに与えた経緯度データとSQLの結果で出てくる経緯度データが、有効数字の差等で変わってしまうと、うまく紐付けられないことになってしまいます。

例えば、

SELECT AsText(Intersection(GeometryFromText('POLYGON((135 35,137 30,139 35,135 35))',4326),
GeometryFromText('MULTIPOINT(136.00 33.00,136.00 34.00,140.00 50.00,135.00 40.00)',4326)) );

結果：MULTIPOINT(136 33,136 34) 

みたいな形になってしまうと、うまく紐付けられないですよね。

そんな時は、以前の記事で紹介した、拙作のPostGISでLocapointを使う関数を使ってみて下さい。

SELECT AsLocapoint(Intersection(GeometryFromText('POLYGON((135 35,137 30,139 35,135 35))',4326),
GeometryFromLocapoint('MULTIPOINT(RT9.WV3.IR4.UF8,RX6.WV3.XC9.UF8,UF7.XC8.UF8.XC9,SU2.WT5.FU3.AA0)')) ); 

結果：MULTIPOINT(RT9.WV3.IR4.UF8,RX6.WV3.XC9.UF8)

Locapointを使えば、80cmの精度で経緯度と等価でありながら、有効数字による差等による揺らぎも存在せず、紐付けるIDとして用いることが出来ます。

会社で相談されたんだけど、こんな特許が存在するらしい。

米Xybernaut，電子的“道しるべ”を残す技術で日本国特許を取得

米Xybernautは，無線ネットワークを使って位置情報付きメッセージなどを記録する技術に関し，日本国特許を取得したと米国時間6月12日に発表した。

なんか無線ネットワークとか書いてあるので、何らかの無線デバイスを用いて位置を取得するところから、さらに位置に紐付いた情報をブロードキャスティングするところまで含んでいるのかと思えば、単に仮想空間に位置情報と紐付いた情報を付加したりブロードキャストしたりするだけの話やん。

ほとんどそのまま、香川大垂水先生の、スペースタグの概念と同じやないか。

記事を見るとXybernautの特許申請は、米国特許でも申請が2000年12月ってことなんだけど、垂水先生のスペースタグ概念は、論文リストを見る限りもっとも古いものは1998年には発表されているし、英語でも1999年には出ている。
Xybernautの特許申請の時点では、公知の技術だよ公知の。

というか、私実際垂水先生がスペースタグ概念を事業化するために作った会社「スペースタグ」にいた事あるんだけど、スペースタグ概念を事業化しようにも概念の特許をその会社で押えていなかったので、散々苦労した。
結局のところ特許を取れなかった理由は、垂水先生自身が論文で概念を発表してしまっていたため、公知の技術になってしまっていたからだ（聞いた話だと、論文発表から半年間は、特許として申請する優先期間があるらしいんだけど、それを過ぎると公知の技術扱いになってしまうらしい）。
本当の発案者すら公知の技術扱いで取れなかった特許を、後から取れるわけないよな？

と言っても私も特許について詳しいわけじゃないし、請求稿の内容とかでも違ってくるのかもしれないけど、少なくとももしこれで特許違反とかXybernaut社から訴えられたとしても、スペースタグの存在を示して異議申し立てして争うことはできるんじゃないの？と思います。

しかしスペースタグ社にいた頃は特許押えていなかった事で散々苦労させられたけれど、こうして歴史を残しておいてくれた事で公知の技術として、リアル位置情報に紐付いた情報流通という当たり前の発想が特許に縛られず（Xybernautとも争うことが出来る）誰でも使える概念になっているわけなので、その意味では垂水先生GJ！ですな。

PostGISでLocapointをそのまま扱えるようなplpgsql関数書きました。

locapoint-plpgsql.sql

これを使うと、

• GeometryFromLocapoint
• AsLocapoint

みたいな関数が追加されるので、WKT（Well-Known Text）の経度、緯度の並びをそのままLocapointに置き換えるような感じで、つまり

• INSERT INTO geom_table (geom) VALUES (GeometryFromText('LINESTRING(135 35,136 36)'));
• SELECT AsText(geom) FROM geom_table;

とかする代わりに、

• INSERT INTO geom_table (geom) VALUES (GeometryFromLocapoint('LINESTRING(AA0.AA0.AA0.AA0,BB0.BB0.BB0.BB0)'));
• SELECT AsLocapoint(geom) FROM geom_table;

みたいな形でLocapointを扱えます（念の為、上の例で経緯度での例とLocapointでの例は同じ位置を示していません）。

regexp_replaceを使っているので、PostgreSQL8.1以降のみ対応。

正規表現の中で、\\\\とかバックスラッシュが並びまくっているところがある。
なんかおかしいのか、warningが裏で挙がるんだけど、でもバックスラッシュの数を減らすとちゃんと動作しない。
いまいちどこでどの文字がエスケープされるのかよく判らないので、どうにもできないんだけど、ちゃんと動作しつつwarningも挙がらないような形にどなたか修正してくれるとウレシ。

マッシュアップアワード受賞の話題を以前書きましたが

うーん、我が我がの記事になってしまいましたが、Award表彰式の様子なんかも書きたいので、エントリを改めて。

とか書きつつ手が回らず書けずにいる間に、時期を逸してしまいました。
今更他の受賞作の感想とかいろいろ書いてもなんかアレなので、今回の授賞式等に参加しての概観的に感じたことだけをさらっと書きます。

アワード授賞式や、実はその1週間ほど前にも応募者だけの打ち上げ式みたいなのがあったのですが、両方に参加して思ったのは、雰囲気のすごいアットホームさ。
アットホームさって言葉はその場にいる人間同士の親密さについての話なので、ちょっと言葉が違うかもしれないけど、要するに参加者が皆すごい家庭感・生活感を持ち込んできてるっていう感じ。

• 余暇で家族サービスや育児をしない後ろめたさを感じつつ、隠れてマッシュアップしたり、いかに奥さんを言いくるめてマッシュアップの時間を作るか、といったプレゼンをする参加者、そして聞きながら首肯する参加者
• 育児に必要な赤ちゃん情報等、家庭・家族の火急な必要性に動かされて作品を作った参加者も多数（まあ、参加APIに赤すぐNETとかあったりしたせいもありますが）
• 自分が授賞式に参加できないので、何も知らない奥さんを授賞式に送り込む参加者
• 授賞式に奥さん、子供を連れてくる参加者（これはうちと上田さんですが、もう一組子供連れの方がおられたようです）

みたいな感じで、先進気鋭のデベロッパーの会という感じではまるでなく、非常にほのぼのとした会になっていました。

▲ 何も判らないまま、代理で来て登壇し、優秀者のガウンを着せられた奥さん ▲

思うに、別に今回参加された人の技術が低いとかいう意味で書くのではないのですが、マッシュアップというのも、当初はやれウェブをスクレーピングするやら通信をHACKするやらで敷居が高く、いわゆるギークといわれるような人（よくも悪くもあまり生活感を感じさせない人）しか利用できなかったのが、今はいろんな企業が積極的にAPI部品を提供するようになり、さらには様々なオープンソースツールやライブラリ、更にはガジェットやMappletのようなサーバリソースさえいらないマッシュアップ手段が出揃うことで、日々の生活に忙しいような一般の人でも、日曜大工の感覚でマッシュアップができるようになってきているんじゃないでしょうか。
そういえば、家庭感という点ではちょっと違うんですけども、MA2で最優秀を受賞された出張JAWSの作者の方も、MA3で最優秀を受賞されたONGMAPの方も、ウェブ開発の周辺にはいらしたようですが、自身はプログラミング経験はなく、アワードのために覚えた、みたいな話をされていたように思います。
確実に、マッシュアップの敷居が下がってきているように感じます（そう書くと、敷居が下がったにも関わらず以前から開発しているはずの俺たちはどうなのよ、とふがいなくも思いますが）。

と言いつつまだまだ全くこの業界のことを知らないような人には敷居は高いと思いますが、様々なツールやライブラリもどんどん便利に進化していくでしょうし、APIもどんどん標準化・汎用化が進んでいくと思います。
近い将来、昔ながらのお父さんがホームセンターで規格に沿った部品を買い集め、DIY雑誌を読みながら日曜大工にいそしんだように、MashupediaやAPI Compare-and-Matching Serviceで拾い集めたAPIを組み合わせて、マッシュアップ雑誌を見ながら日曜マッシュアップにいそしむというのが、新しいお父さん像になっていくのかもしれません。
というか、日曜大工の基礎が学校時代の技術家庭科から成っていることを考えると、そのうち学校の教科に「マッシュアップ科」なんてのも出てくるのかも？

後雑写真。

▲ 懇親会で出された、自分で作る「マッシュアップ・バーガー」を頬張る息子 ▲
というか、マッシュアップと言う割に選択肢はハンバーグとさつま揚げしかナカタ

　
▲ 会場で配られたシールも、息子の手で見事にマッシュアップされました ▲

HTTP::MobileUserID & Catalyst::Plugin::MobileUserID Released - Unknown::Programming -

Catalyst::Pluginの方、使ってみたら動かなかった。

追ってみると、中でHTTP::MobileAgentのget_headerメソッド使ってるんだけど、前提になっているCatalyst：：Plugin::MobileAgentの方でHTTP::MobileAgentのオブジェクトが作られる際に、リクエストオブジェクトから作るのではなくUseAgent文字列だけから生成していたので、get_headerメソッドがうまく動いていなかった。

なので、かなりむりくり感あふれるけどCatalyst::Plugin::MobileAgentのprepare_headersをちょこっと変え。

    sub prepare_headers {
        my $c = shift;
        $c->NEXT::prepare_headers(@_);
        my $ma = $c->req->mobile_agent(HTTP::MobileAgent->new($c->req->user_agent));
        $ma->{_request} = bless { r => $c->req }, "HTTP::MobileAgent::Request::HTTPHeaders";
    }

これで動いたよ！

もう数ヶ月前くらいのことになるけど。

幼稚園の保護者会に出ていると、同じクラスの保護者から動議が挙がった。
なんでも、クラスの部屋の真ん中に、人糞が落ちていた、ということが複数回あったと言う。
子供を預けている場でのそのような衛生上の問題に対し、再発防止の策はとったのか、犯人の子を突き詰めてそのような反社会的行動を取らないようにという徹底的な指導はしたのか、反社会的だということを理解させるには陰で叱らず他の子供の前ででもちゃんと叱らないとダメだろう、といったようなことを、先生をつるし上げるような形で問い詰めていた。

俺個人的な感覚では、部屋の真ん中に人糞が落ちていたといったって、自分がそれを見れば「おえっ」とは思うだろうけど、それ以上の感覚は感じない。
まだ幼稚園だろ？別に奇行をする子なんてなんぼでもいるだろよ、と思う。
俺が子供の頃なんか、クラスに1、2人、学年に10人くらいはなんか普通じゃない行動とる奴が普通にいた。
俺のこめかみには、小学のころにそういう奴に鉛筆を突き刺された後が今も残ってるし（その原因は、俺がそいつの変なところを過度におちょくったせいだ）、中学になってすら、校舎の4階から下に人がいるのに消火器を落とすような謎の行動を素でとる奴だっていた。
素で奇行をするような子でなくても、障害や発達の遅れなんかで、個人の意思に反して奇行をしてしまう子だってこの歳だといるだろう。
別に、そういういろんな子がいる中で、子供もいろんな状況への対処法を学んでいくもんじゃないの？と思いながら、その動議を聞いてたんだけど。

案の定、先生が涙ぐみながら事情を教えてくれたところによると、一人排泄障害を患っている園児がおり、成長してきたこともあってずいぶん普通に暮らせるようになってきているのだけど、ちょっとしたパニックなんかで思わず漏らしてしまうようなことはまだ残っていて、今回のケースもその子が思わず漏らしてしまった物だったらしい。
子供の自尊心の問題もあるからどの子というのは言えないけれど、先生とその子とご家族とで頑張っているので、理解して欲しいという回答。

さすがに子供を叱ったのか云々の方向の追及はそれで立ち消えたのだけど、今度は続いて事後処理の追及。
大便を処理した後の消毒はちゃんとやったのか、もしかしたら処理が完了するまでに上靴で踏んでしまった子だっているかもしれない、各子供の靴の裏とかまでちゃんとチェックして綺麗にしたのか、等とまた先生つるし上げ。
いわく、そのような衛生面の危機管理がきちんとできない園では、安心して子供を預けられないとかなんとか。
正直、すげえあほくさい。
もちろん、先生がそういうところまで気がつくに越したことはないが、ウンコを踏んでしまった靴を大人に面倒を見てもらわないと綺麗にできないような子供と言うのもどうなのよと。
あんたらは路上でウンコを踏んでしまった時に、草むらとかでこすって綺麗にする方法を、親や先生に教えてもらったのか？と。
ずいぶん子供を馬鹿にしてるんじゃないかと思う。
また別にそれで多少ブツが残ったところで、重篤な感染症を持っている子のブツとかならともかく、それで人が死ぬこととかありえないだろ？実際。
それを園をつるし上げて、衛生的でないから預けられないとか、どうなのよと思う。

何もかも大人の先生方にお膳立てしてもらって何のハプニングもない無菌状態の空間で育つより、排泄がうまく出来ない子もいる、という前提の元で、そういう子もいるという事を理解してうまく付き合って行く方法を学ぶことの方が、よっぽど重要な教育だと思うのだけど。

そのウンコ騒動が終わったと思えば、また次の動議が。
なんと、女の子のトイレを除く男の子がいて、女の子が非常に嫌がっているという。
正直、それを聞いた時の俺の反応は、「みそ汁噴いた」という感覚だった。
おーおー、ほんのちょっと前までオムツつけてた連中が、そんなとこまで生意気な糞ガキに育ったか、みたいな。
でもそれも先生吊るし上げで、ちゃんと問題を把握しているのか、その子を叱ったのか、再発防止策は、みたいなコンボ攻撃。

あえて書くと、異性に興味を持って覗くとか、ある意味子供の正常な発達過程なわけですよ。
子供って好奇心の塊なわけなので、自分と違うものに対する興味を持って知りたいと思うってのはむしろ喜ぶべき成長だったりするわけじゃないですか。
でも当然、そのような好奇心の行動は、一方で他人の嫌がること等を犯してまで追求してはいけない事、というのは学ばないといけない。
なので注意するのは当たり前なんだけど、でもそれって園という先生と幼児達で構成される社会の中で解決されることであって、親が出てくる必要はないだろう？と思うんですよ。
俺らの子供の頃だってスカート捲りとかいろいろあったけど、普通は子供の間で解決してたし、或いはホームルームとかで取り上げるとか、或いは先生にアホかとゲンコツくらって終わりとか、そのレベルのもんだと思うんですよ。
いや、まだ被害にあった女の子の親が、うちの娘が嫌だといっているのにやめてくれないので、先生もう少し強く言ってくれませんか、とかの要請なら判るんですが、動議かけたの男児の親で、やれ再発防止策は、とか園の認識は、とかのノリですからね。

実際先生も大変ですよ。
昔ならこの位の問題なら、ゲンコツ一つで済んだ話が、今は体罰は一切禁止、にも関わらず起きた問題の再発防止徹底はがんがんクレーム挙がってくるわけですから。
幸い今回の問題はうちのバカ息子は加害者じゃなかったし、また幸いこれまで私はシッペ以上の体罰を息子に加えずに済んできましたが、もしこの犯人がうちの子なら、まずゲンコツ一発、道理説いてこの後は絶対するな、もしもう一遍したら今度はゲンコツじゃ済まんぞ、くらい叱った後で、でもお前もいっちょまえに生意気にませてきたな、みたいな感じでにやっと笑ってそれで終わりじゃないかと思います。
子供との付き合いなんて、そんなもんでしょ？と思います。

命に関わるような問題ならともかく、どんな問題でも徹底排除して誰もが普通で誰もが傷つかない（一方で排泄障害のような普通じゃない子は隠蔽されてしまって傷つく）ハプニングのない無菌状態の園生活で、本当にいいの？生きていく術を学べるの？と思います。
園の中は無菌室でも、一歩外に出れば悪意や不条理は社会に渦巻いているわけです。
そういうのに少しでも耐性をつけるためにも、子供たち同士の違いや諍い、好意や悪意、ハプニングから、いろいろ学べることがあると思うのですが。

---------------------------------------

追記：

新任女教師が自殺、という痛ましい事件と同時期に挙げた記事だったために、うちの保護者さん達もなんかその記事で女教師を自殺に追い込んだようなモンスターペアレンツのような受け取られ方をしてしまったようですけど（併せて読みたいとか書かれてしまって）、さすがにそんな酷い事例とは思えないです。
子供の育つ環境の理想について、ちょっと考え方が違うなあと思ったのでどうよ、と記事に挙げてみたわけですが、記事に書いたようなケース以外は保護者会と先生方との関係も極めて良好ですし、なにか園行事があるとなれば率先して保護者が協力したりして、極めていい感じの園生活が送れています。
むしろその意味では、文系のノリのいい保護者方が多い中で、父母揃って非コミュ系のうちの家庭の方が、園行事なんかの協力も腰が引け気味でダメじゃんみたいな感じなので。

というか、よく言われるモンスターペアレンツって、

• 給食費踏み倒す
• 自分の子供だけ特別扱いしろとか要求する
• 自分の子供とそりの合わない他の子を転校させろとか言い出す

とかっていうような、各家庭と学校・園は対等の契約であるにもかかわらず、自分の子・家庭だけ特別扱いしろと言うような勝手な「私」の範囲での要求をしてくるような親の事、という認識を私はしています。
今回私の記事で取り上げたような親御さんは、私とは考え方が違うのでどうよと記事書いたわけですけど、でも別に自分の子供だけ、と主張しているわけではなく、広く園全体の環境としてこうあるべき、という「公」の範囲の要求であるわけで、その意味では政治で言うところの「大きい政府」が正しいのか「小さい政府」が正しいのかという話と同様で、どっちが正しいというもんでも悪というもんでもなく、別に主張すること自体はなんら問題がないように思います（その主張と違う考え方をする者からは、なんだかなあ、と思うだけで）。
もしかすると私の方が間違っているのかもしれませんし。

また、その意味で言うと、件の新任女教師の自殺のケースすら、報道で得ている情報の限りですが、「子どものけんかで授業がつぶれているが心配」「下校時間が守られていない」なんていうレベルのクレームなら、別にモンスターペアレンツというレベルでもなく、十分に想定される範囲内のクレームだと思います。
言い方や書き方に問題があったのかもしれませんし、「結婚や子育てをしていないので経験が乏しいのでは」みたいな人格攻撃はどうかと思いますが。
むしろ問題は、クレームとしては想定範囲の当たり前のことであっても、それをクレーム処理経験もない新任教師に、バックアップ体制も相談する先輩もない状況で任せたという、学校側の不手際だと思うのですが。

報道などで知る限りですが、モンスターペアレンツというようなのが増えて学校や園の負荷は上がっているようではあるんですけども、それでも

• 公の立場を考えず、私よかれの要求を挙げてくる親

と、

• ちょっと過保護気味の要求ではあるけれど、公の範囲内での要求を挙げてくる親

は分けて考えないといけないと思います。
前者は本当に単なる困ったチャンですが、後者は教育に求めるものの範囲が違うと言うだけで、教育と言う物を支えていこうと言う意味では意識のある親ではあるわけなので、学校や園としても当然想定できる範囲内のリスクとして対処を考えておくべきですし、またそう言った親御さんのパワーを、学校と保護者の協力としてうまい方向に誘導する必要もあるのではないかと思います。

うちの園では、後者気味の人はいますが、さすがに前者の人は皆無ですし、それなりにうまくやれています。

先日書いた狂言の舞台ですが、1日目はいい舞台日和の中多くのお客様にお出でいただいて、2日目も足元が悪かった割には数十人近いお客様に観覧いただいて、無事終えることが出来ました。
このブログを見て来てくださった方もいて、誠にありがとうございました。

んで、神社から奉納のお礼として、神饌を分けていただいたのだけど、その中に絵馬が入っていて。
1日参加毎に1枚、家族にももらえたので我が家だけで井草八幡宮の絵馬が6枚ももらえたりしたんだけど...。

なんか、趣旨おかしいような気がするのは私だけ？

そもそも絵馬って、神社への祈願や祈願成就のお礼として、参詣者が神社に寄進する物であって、神社側から個人に下賜するもんじゃないような気が。
だいたい今は絵馬に「願い事」書いてつるしておく形が主になっているので、絵馬が単なる「願い事の受けつけ用紙」みたいな扱いになってるので、狂言を奉納したから無料で願い事聞く権利あげまっせ、みたいな感覚なのかもしれないけど。
でも絵馬本来の趣旨から言えば絵馬を「寄進すること」が主であって、「祈願」は従であるような気がするので、無料で絵馬を神社から個人に渡すと言うのにそこはかとない違和感が。
まあ、奉納した「狂言」自体に金銭米穀と同様の価値を見出してくださって、それを供物として対価の絵馬を下さった、ということなのかもしれないけど、それにしたって奉納したのは狂言なわけで、それを別の対価として絵馬に還元した後に願い事なり書いて再度神社に奉納、というのもなんかすごい不自然さを感じる。

というか、急に6枚も絵馬もらったって、急には願い事なんて思いつかんよ！
それに配られたのがもう撤収間際だったし（神社は早くから下さっていたので、こちらの分配の手際の問題なんだけど）。
結局家まで持って帰ってしまった。
超意味なし。

memcachedって、恥ずかしながらいまだに使ったことないんですけど、　キー　⇒　値　が1対1対応のメモリハッシュみたいなもんなんですよね？

複数のキーに対して、単独の値を割り当てるような使い方ができる、memcachedみたいなのってないんでしょうか？
全てのキーからの参照が消えれば、値も解放してくれる、みたいな。

というのも、以前書いた勝手位置情報エンタメサイトでセッション詐称のために不正される問題、Ceekさんがトラックバック下さったワンタイムセッション方式をもうちょっと改良すればかなりの偽装を防げる感触を得ているのだけれど、いかんせんワンタイムセッションなので、ユーザ数ではなくアクセス数の数だけセッションが必要、ということになってしまう。
（※：Ceekさんの案だと、2段階以上の「戻る」操作を許さないようにしているため、見た目ワンタイムセッションだけど実際にはユーザ数だけのセッションしか存在しない形になるけれど、私は「戻る」の複数操作を許したいので、本当にアクセスの数だけのセッションが必要になる）

でも、セッションの有効/無効を制御するために複数のセッションを用意するわけだけど、セッションの中身はアクセス毎に違うわけではなく同一ユーザでは同じになるわけなので、セッションキー毎に中身を保持するとすげえメモリの無駄になるように思う。
実際今取り組んでいるサービスでも、ユーザ数でのセッションなら1日数万とかのオーダだけど、アクセス数でのセッションなら1日下手したら100万とかのオーダになるので、サービスのしょぼい規模に比べてあり得ねえ！とか思う。
なので、複数のキーに対して同じメモリ空間を割り当てるようなmemcachedみたいなのがあればいいなと思うんだけど...。
ないのかなあ。

memcachedで覚えさせる値自体に、エイリアス先のキーの値を入れればいいのかもしれないけれど、

• 元々セッションに覚えさせるデータ量自体が、ユーザの端末IDと機種名程度でセッションIDとどっこいどっこいなので、そんならもうデータ覚えさせた方がいいわな
• それに直接複数キーが同一メモリに割り当てられてるのに比べて、キー探索⇒メモリアクセス⇒キー探索⇒メモリアクセスと多段処理になるので負荷もその分上がりそうだし
• 参照切れの管理ができまへん

とか思うので、意味ないかなと。

なんかいいソリューションないでせうか。

えー、毎年この時期恒例ですが、今週末、井草八幡宮でまた狂言やります。
10/7、8の両日開催で、私は一応両方一番ずつ出ます（8日はチョイ役ですが）。
興味ある方は、詳細はこちらにありますのでぜひおこし下さい。

んで、誘いのメールを社内のMLでも流したりしたんですけど。
できればたくさん見に来てくれればなーとか思って、なんか刺さる誘いの方法ないかなと思ってたんですが、うちの会社、マピオンとJRトラベルナビゲータが今やってるケータイのゲームキャンペーン「ケータイ国盗り合戦」に参加している人が多いんですね。
これ、位置情報でエリアを盗っていくスタンプラリーみたいなゲームなんですけど、狂言を見に来た時にその会場で盗れるエリア名を挙げて、「××エリアを盗りに行くついでにぜひうちの狂言も！」みたいな誘い方をすれば、まだそのエリアを盗っていないゲーム参加者は来てくれるかなあと。
でも、はたと困った。
ある場所が国盗り合戦のどこのエリアに属するかって、どうやって調べればいいんだ？

エリア分け自体は、マピオンがエリア分けのKMLファイルを公開しているので、Google Earthを用いて大体のエリア配置は確認できるんだけど、いかんせんGoogle Earthは地図ではなく衛星写真なので、正確な目的の場所を特定するには不向き。
最近はGoogle Maps APIでもKMLが読めるので、エリア分けKMLを読み込ませてみたりもしたけれど、KMLのサイズがドデカ過ぎてはじかれてしまう。

途方に暮れていた時に、ふと思い出した。

そうだ、自分達で作ったMapSurferがあるじゃないか！

Google Mapsのマイマップに、こちらからインストールできるMapSurferマップレットをインストールすれば（マップレットギャラリーの人気順からでもインストール可能）、Google Mapsで目的地を正確に指定した上で、その場所を中心としたGoogle Earthを正確に開くことが出来ます（正確には、KMLファイルが出力されるので、PC側でKMLとGoogle Earthの関連付けが必要）。

そうして起動されたGoogle Earthに、先ほど紹介したマピオン提供のエリア分けKMLが入っていれば、中心点の国盗り合戦でのエリア名が一発で判ります。

はい、上記のように、狂言を演る井草八幡宮は「中野/荻窪」エリアだと判明しました。
でも、微妙に「目白/豊島園/練馬」、「三鷹/国立」も狙えそうですね...帰りちょっとウロチョロして奪取してみようかな。

というわけで、キャンペーン期限まで残り20日を切りましたが、国盗りゃーの方々、もし目的地の正確なエリア区分を確認したければ、ぜひMapSurferをエリアKMLと共に使ってみて下さい。
あと、もし中野/荻窪未統一の国盗りゃーの方がおられましたら、ぜひぜひ狂言を見に来て下さいね！

ロカポイントの上田さん、デザイナーのAN-NAIさんと「位置情報ロカポ」チームとして共同で応募したMashup Award 3rdですが、入賞いたしました。

位置情報ロカポチームとしては「MapSurfer（富士ゼロックス ネットプリント賞）」、「日産de旅ログ?(日産カーウイングス賞)」、「AB-ROAD Mapplus(エイビーロード賞)」 の3作品受賞したのですが、AB-ROAD Mapplusは上田さんが一人で作成された作品なので、私の受賞作としては前2つという形になります。
そのうちでも、日産de旅ログは私は分散IDでのログイン部分を作っただけ（まあ作ったっちゅうよりCatalystプラグイン掻き集めただけ）で日産が絡む部分には関わってないので、個人的には私の作った＆コンセプトを出した部分が評価されたMapSurferの受賞が嬉しいです。

ただ、それがネットプリント賞をもらえる形になったというのは、怪我の功名というか、実装上出てきた問題を回避しているうちに偶然そういう形になってしまって、ちょっとラッキーだったりもするのですが。
というのも、今回講評を拝見しますと、メールを1回送るだけで地図がネットプリントに転送される簡易なUIとか、街角QRコードをネットプリントで印刷できる、というのが評価されたのですけども、元々地図を印刷するのにネットプリントを使う予定はあったけれど、QRコードあたりを印刷する予定はなかったんですね。
街角QRコードについては、単に位置情報だけを埋め込んだQRコードを街に貼り付けて！だと、何かトラブルが発生した際に問題かなと思って、一応作成者の何らかのIDを埋め込んでおいた方がいいと思っていました（もちろん、QRコードをスキャンすれば作成者IDが丸見え、みたいな形では埋め込んでいないです。何か起きた時に引き出せるようにしてるだけで、普段は誰にも判りません）。
で、そのIDとしてJugemKeyやOpenID等の分散ログインIDを突っ込む予定で、そのログイン機構をMapplet版MapSurferに埋め込むつもりでこんな記事も書いたんですが、アワード応募締め切り直前になってセキュリティ的に問題というのが発覚しまして、こりゃダメだと。
急遽、街角QRコード発行用の地図サイト準備しようとしたのですが、機能だけのサイト作るのは別にすぐできるわけですがまともなサイトデザインが数日では作れない状態で。
どうしよ、どうしよ、とか思ってた時に、そうだケータイのGPSでその場で位置とって、そこからネットプリントで街角QRコード発行、という形にすれば、とりあえず街角QRコードの発行経路と読み取り経路の両方がまがりなりにも確保されるので、話の辻褄はあうなと。
埋め込みの作成者情報としては、ネットプリント使うならメールアドレス通知が必須なので、それが使えますし。
いや実際、まだ無料で自分のプリンタで印刷できるならばともかく、お金払ってしか印刷できないネットプリント使って、街角QRコードなんて得体の知れないもの印刷して貼ってくれる奴なんているわけないやん？
その辺の矛盾は自分でも十分承知の上で、応募のための方便だけに現在のQRコード発行手順になったのです...すみません富士ゼロックスさん、ぶっちゃけ過ぎてて身も蓋もないですが。

地図がメール一つでネットプリントに送信できるUIについても、元々地図サイトの画像をアシアルさんのHTML2PDFでPDF化して、オンザフライでネットプリントへ送る予定だったんですけど、HTML2PDFの処理が意外に重くて、オンザフライだと送信が失敗する事がしばしば。
なのでHTML2PDFでの生成結果をローカルに落として、完了すればユーザにメールで通知し、そこからネットプリントに送るという形を次に考えたんだけど、これって「PDFの生成完了」「ネットプリントへの送付完了」が連続してメール経由のインタフェースになるので、これはウザイなと。
PDFが生成できた時点で、ユーザに処理を返さなくても、続けてサーバサイドでネットプリントへの転送処理ができないか？と思って試してみたら普通に出来たので、だったらもうワンストップチャネルにしてしまうか、ということで現在のUIになりました。
まあ、こっちは方便でもなく、結果としてちゃんと便利なものができたとは思ってますが。

正直な話、ネットプリントAPIの利用は期間が12月までと限られているという事で、方便としての街角QRコード発行も、マジで開発した地図ページ送信も、自分の中ではどちらも何時機能として外しても構わないサブ機能、という感じの位置付けだったんですけど。
でも、せっかく賞をいただけたのであれば、ネットプリントを通じてできるリアルとバーチャルの融合の可能性をもうちょっと追求してみたいので、12月を過ぎてもAPI使わせて欲しいなあ、とか思ったり。
というかもっと言うと、街角QRコードに関しては、ネットプリントさんに賛同いただけるのであれば、ネットプリントで街角QRコードを印刷、というよりも、全国津々浦々にあるネットプリント端末上にその場所の街角QRコードを表示してもらったり、或いは提携先のセブンイレブンさんの店頭にデフォルトで街角QRコードを展開してもらったり、とかができると嬉しいなあ。

今回、MapSurferを含め、日産de旅ログ、AB-ROAD Mapplusのいずれも、UIを持ったサイトの応募という形ではなく、MappletやGreaseMonkeyといった、他のサイトやシステムへのアドオン的なもので応募し受賞させていただきました。
うちに限らず他にも、SkypeアドオンであったりOpenPNEアドオンであったり、そういったものの受賞が増えているわけですけど、以前このブログでも書いた、ユーザカスタマイズ可能なサイトというマッシュアップの方向性が進んできていて、それが世間的にも市民権を得てきたのかなあと言う気がします。
こういう方向性は、作られたはいいがアクセスされなくなるマッシュアップサイト、という問題を解決してくれると共に、サイトから何から1から自前で用意しないといけないという敷居の高さから開発者を解放してくれるので、より気軽に日曜マッシュアッパーになろうと言う人が増えてくるんじゃないかと思います。
正直な話、上田さんまで巻き込んで悪いですが、うちの「位置情報ロカポ」チームの開発力なんて死ぬほど大した事ないですよ...アルファギークと言われるような人から見れば鼻くそみたいなもん。
それでもそれなりに使えるもんを作れるくらい、敷居が低くしてくれるところに、MappletやiGoogleガジェット、GreaseMonkeyのようなサイトカスタマイズ系マッシュアップの真価があるんじゃないかとか思います。
そしてその方向性を、サイトから作っているマッシュアップと同等にきちんと評価してくれるMashup Awardの方向性は、やっぱりすごいなと思います。

んでもってその意味では、MapSurferの中でも携帯版の方は、街角QRコードからのランディングを用意しなければいけない必然性とはいえ自前でケータイサイト構築してて実装として重いんだけど（当社比、ですよ）、この辺も最近、ケータイでの位置情報を透過的に流通させて各種位置情報サイトを有機的に結合させるための試みとして、GIS-GWといった活動が出てきたりしています。
こちらとか、MapSurferで街角QRからランディングさせた後にやりたかった事と非常に近いので、MapSurferで自前で重い携帯サイト持つよりは、むしろ街角QRコードから直接GIS-GWにランディングさせたり、できるだけ重い仕様のものは自前で持たずに機能のハブを作るだけで新しい価値を提供するような、そういう方向性を目指したいと思ってます。

街角QRの今後の展開は...もしPCサイトの地図から位置情報付きQRコードを発行できて、自前プリンタで印刷できるようになったとしたって、協力してくれる人はほとんどいないだろうなあというのはまあ判りきったことなので。
街角にQRを貼っても無味乾燥にならないような、エラー訂正の効く範囲内でデザインされたQRコードを生成するようなツールを提供したり、後埋め込む情報として位置情報だけでなく、協力してくれた人にとってもメリットのある情報を埋め込めるようにするとか（例えば近くで商店をやっている人が、街角QRコードでその場の位置情報だけでなく、店の携帯WebのURLや、そこから自分の店へのルートなんかも提供できるようにしたり）、なんとか協力してくれる人を増やせそうな施策を考えつつ、ライフワーク的にぼちぼちやりたいなあと思います。

うーん、我が我がの記事になってしまいましたが、Award表彰式の様子なんかも書きたいので、エントリを改めて。