方々よりノウハウを記事にして共有してくれと突かれていたので、遅くなりましたが記事化します。

その前に1つだけエクスキューズしておくと、小山さんの記事あたりで

位置詐称を許さないここギコねねさん

とか書かれてますけど、別に許さないつもりはなくて...確かにGeoPlatFormAPIのような位置取得APIや、GIS-GWのような位置流通APIの双方で詐称を検証する方法とか事ある毎に口にしてるんですけども、これは「何が何でも詐称を許さない」からそうしてるわけではなくて、それぞれ理由（それも異なる理由）がありまして、

• 位置取得APIについては、社内用に作っている方がメイン用途をエンタテイメント分野としているので、そちらでは否が応でも「詐称は許さないようにせざるを得ない」のですね。
  だから自分の方はこだわってるだけで、別にそういう用途に使う事を想定していないのであれば、たとえば携帯から位置を取って地図を表示するだけのサイトに詐称対策が必要とも思えないし、詐称対策してないとAPIとして無意味、などという事は全くありません。
  その意味では、GeoPlatFormAPIを紹介した記事で、「が、ちょっと甘い」等と、詐称対策がされてないとダメという印象の表現をしてしまったのは、全く適切ではありませんでした...スンマセン。
• GIS-GWの方は、私がこだわっているというよりも、GIS-GWメンバによってGIS-GW上に期待されていることの方が、詐称対策を必要としている、というのが個人的印象です。
  全くの個人的には、ケータイ位置情報サイト間で情報を流通する際に、それほど詐称対策が必要とは思えない（他のサイトで取った位置情報をGETで流されてきて、それを元にエリアを盗った!等と認めるようなエンタメサイトも考えにくいし。まあ、将来的に位置情報のGET持ち回りでなくブロードキャスト等が実現されたら話は別なのですが）し、サイト間で流通させたい位置情報としては、単にケータイデバイスで直接取得したもんだけではなく、地図で微修正したりしたもんも含まれるだろうから、そこに詐称対策を盛り込む必要はほとんど感じていなくて、別に経緯度をGETにつけて流すだけの緩いもんでいいんじゃないの？と思ってたんだけど。
  そしたら、他のGIS-GWのメンバの方から、位置情報の信頼度も流通したいよね（たとえば、doodleは本当にその場にいる人しか発言させないらしいので）、果てはユーザのユーザID情報までパラメータとして引き渡したいよね、みたいなGIS-GWへの要望が挙がってきた。
  そこまで情報を保証したり、センシティブな情報を流そうと思ってるなら、詐称対策せずにGETでただ流してたら相当やばいよね、ということで「詐称対策しなきゃ」とこだわっているわけでして、個人的信念よりは他者要望に基づいて必要性を主張しているような感じです。

まあ、どう言ったところで位置情報詐称検証法にこだわっていることは事実なのですが、別にいろんなユースケースがあるにも関わらず、その必要性も考慮せずに脳みそ筋肉的に、「位置情報詐称を考慮していない位置APIなんてクソだよクソ」的なことをここギコは考えている、と思われるのも嫌なので、一応エクスキューズをば。

で、本題。

位置情報詐称検出といっても、別に難しいことをかんがえているわけではなくて、ほんまにはてな認証APIやLivedoor認証API、Wassr認証APIなんかの発送パクってるだけ。
要するに、ユーザのID情報と1対1で紐付いた秘密鍵を発行して、その秘密鍵をベースに詐称検出用のシグニチャをデータに付加してやるだけのこと。
例えば、GIS-GWのインタフェースの現状仕様は、Serendi（ID：SE）からdoodle（ID：DO）に対し、経緯度と取得時間の情報を送ってやろうとすれば、SerendiからGIS-GWへの遷移は

http://ja.gisgw.com/gw?s=SE&d=DO&lat=35.8264&lon=139.6920&t=20070828120413

みたいなURLになるわけだけど、これを詐称検証可能にしてやろうと思えば、上記の赤の部分全体を、Serendi/GIS-GW間で共有している秘密鍵を使ってHMAC_SHA1ダイジェストを取ってやった値を、クエリ末尾に付加してやればよい。

http://ja.gisgw.com/gw?s=SE&d=DO&lat=35.8264&lon=139.6920&t=20070828120413&sig={赤字部分のSerendi秘密鍵でのhmac sha1 hexdigest}

みたいにすればよいだけ。
これを受け取った側でも、同様に秘密鍵を使い赤部分のダイジェストを取ってやって、一致していれば詐称なし、一致していなければ詐称あり、という感じにすればよい。

GIS-GWは上記を受け取った場合、doodleに位置情報を転送するわけだけど、これについても同様にシグニチャを付加すればよい。
ただし、今度は使う秘密鍵が、doodle/GIS-GW間で共有している秘密鍵になる点だけが異なる。

http://doodle.st/gw?s=SE&d=DO&lat=35.8264&lon=139.6920&t=20070828120413&sig={赤字部分のdoodle秘密鍵でのhmac sha1 hexdigest}

みたいな感じ。

実際問題これだけの話で、そんなたいした話ではない。
基本、位置流通APIだけでなく、位置取得APIでも、ほぼ同じやり方で詐称検出はできる。
けど、まあこちらでも作ってていくつかのベストプラクティス？的なのもあるので、それを補足しておくと、

• 赤字で書いた部分のデータ文字列のシグニチャをとる場合だけど、上記の例だと全部ASCIIデータなので問題ないけど、マルチバイトデータ等URLエスケープ対象文字が混ざる場合、URLエスケープ後のデータでシグニチャを取ると、URLエスケープの微妙な揺らぎ（スペースは+にするのが常道と思いますが、%20にされる場合も少なくない、等）のためにシグニチャがずれてしまうことがありそう。
  シグニチャを取る際のデータはURLエスケープ前のバイナリデータとするのが吉かなと思う。
• 本仕様で検出できるのは、URL上のデータに詐称がないかだけ。
  例えば、上記URLでlat=35.8264がlat=34.8264に変更されれば検出できるけれど、「シグニチャまで含めたこのURLセット」を、別のユーザに転送されたり、或いは別の日時に再利用されたりといったことは検出できない。
  よって、そういった部分までケアしようと思えば、シグニチャを取る対象のデータの中に、時刻依存やユーザ依存のデータ（ユーザIDとか、ユーザIDをGETで流すのがやばければUAとか？）を埋め込んでおき、URLの詐称検証とは別に、時刻妥当性やユーザ妥当性を判断する必要がある。
• 位置詐称対策シグニチャを埋め込んでいるデータに対し、下流でシグニチャを外すのは問題ないけど、対策のされていない元データに対して、下流でシグニチャを埋め込むのは絶対ダメ。
  たとえば上の例で、doodleは詐称対策されたデータを望んでいるからといって、Serendi→GIS-GW間は無検証で送られてきたデータに対し、GIS-GW→doodle間にシグニチャを埋め込むのはやってはいけない。
  でないといくらGIS-GW→doodle間は検証できても、その上のSerendi→GIS-GW間でいくらでも詐称できてしまうので、何を信用していいのか判らなくなる。

みたいなところでしょうか。

でも、これは飽くまで詐称を検出できるかどうかの話なので、通信路の秘密みたいな話になるとまた別の話、というかGETでできるの？みたいな感じになる。
GIS-GWとしてはできればあまり重い仕様にしたくない、GET程度の軽い仕様がいいということなので、それでできる範囲は範囲のライトな仕様でおいておくとして、でも一方でユーザID情報みたいなのも流したいという要望もあるので、そうなるとGETなんかで流して本当にいいのかな？みたいな感じもしてる。
そのレベルになってくると、超重くなってくるけど先日アイデンティティ飲み会で知ったSAMLを応用するとか、そういうレベルの話になるんじゃないか、という感じがしている。

ロカポの上田さんから、一連のルート位置情報（ポリゴンでも問題ありませんが）をまとめて、URL等にも付加可能なレベルに圧縮し、可搬にする新しい仕様「LocaPorter」が発表されました。
ジオメディア新年会ではLocaParamとして事前発表されて話題をさらいましたが、その後海外コンサルの方に相談されて、「Paramはネイティブにはピンと来ない」「LocaPoで揃えた方がよいのでは？」といった意見で「LocaPorter」に変更された模様。

ロカポ...いやこれからはLocaPointと言わなきゃいけないのかな?LocaPorterもロカポだから...の時も発想のすごさに驚きましたが、相変わらず上田さんの発想のすごさと斬新さに驚かされます。
基本はLocaPointベースで、差分を追記していく形なので、LocaPointの単純なアルゴリズムでどんどんルート中の各点を符号化していき、後追いでどんどん点を加えていくことができます。
当然、復号も同様で、先頭からのデータを確実に受け取っていれば、全体を受け取っていなくても順次復号していけます。

シリウスラボさんも書かれていますが、

これまで、サイト間でルート情報などを受け渡したいと思った場合、KML などをどこかのサーバ上に置き、そのデータを読みにいったり、KML データそのものを POST で受け渡すという方法が一般的でしたが、LocaPorter を利用することで、GET パラメーターのみでもそのような地点情報を受け渡すことができるようになります。

というふうに、経路情報というものをより容易にサービス間流通させる手段となりえます。 
また、サイト間でなくても、経路情報を圧縮してURL等に付加することができるようになることで、裏で経路情報を記憶しておくようなデータストアを準備しなくても、URLをデータストアとして経路を扱うWebサービスを実現し、QRコード等で扱えるようにする、ということも考えられます。

さすがに都道府県ポリゴンをまとめて流通、なんてな話になると、LocaPorterだけでGETで流通させるのは現実的でなく、KMLなんかの力を借りる事になるのかもしれませんが、それでも別にKMLとLocaPorterは対立する概念ではなく、KMLでの膨大になる生経緯度羅列の経路・ポリゴン表記フォーマットを、オプションでLocaPorterの圧縮フォーマットに切り替えられるような仕様を決めれば、膨大になりがちなKMLのサイズをコンパクトにすることもできます。
もちろん、kmzのような圧縮フォーマットもあるわけですが、バイナリなので経路情報以外も人間に非可読になってしまうのに対し、KML featuring LocaPorterならば、人が読んで意味のある情報は読めるままで圧縮できます。
そしてLocaPorterにとっても、LocaPorter自身は伝えられるのは経路・ポリゴン情報だけであり、それに付随する属性情報等を伝える仕様は今のところ考慮していないので、そのエンベローブを持つKMLとコラボできれば、利用用途は無限大に拡がる気がします。

アルゴリズムの開示はしばらく待つ形になるようですが、将来が楽しみなフォーマットです。

自己責任教信者から、環境責任信者への問答。 -no braking!!-

そもそもタイトルからして違和感満載なんですが。
私は銀の弾丸があるかないかを議論しているだけのつもりで、自己責任が銀の弾丸ではなくて環境責任こそが銀の弾丸だ、等とは言ってません。
自己責任こそが全てを解決する銀の弾丸だと言っている連中に対し、自己責任の場合だってあるだろうし、環境責任の場合だってあるだろうと言ってるだけ。
なのでこのタイトルの付け方からして、問題の本質を判っているとは思えない。
タイトルをつけるなら、「自己責任教信者から、無神論者への問答」とでもしてください。
（もちろん単なるレトリックであって、本当の意味の無神論者ではないです。特定の宗教に傾倒しているわけではないけど。）

いろいろポジティブに考えて成功してきた人の例を大量に挙げているが、いくら挙げたところで「銀の弾丸の存在」の証明にはならないことを理解して欲しい。
「銀の弾丸の不在」ならば、反例ひとつ挙げれば済む話だけれども。
そもそも「ポジティブ」とか「笑い」とかは自己信条である以上、周りの状況とは関係なく「そうある」のが本当の意味での「ポジティブ」であり「笑い」だと私は思ってます。
である以上、前にも書いたがアウシュビッツのガス室の中ですら、「ポジティブ」で「笑い」ながら死んでいった人はたくさんいると思うんですがね...。

また、ポジティブと成功の相関が高いとしても、その関係は因果関係ではなくスクリーニングの結果だと考えても、論理的には破綻しません。
個人的には、こっちの方が説得力が高いと思ってます。

とりあえず、思考を集中するのはダメなところじゃなく 自分や周りの人の良いところに集中するほうが 当然奇跡起こりやすい。

グッドウィルやフルキャストのよいところに思考を集中せず、ネガティブ面に注目してフリーター達が行動を起こした結果、グッドウィルだけでデータ装備費2年間分37億円、フルキャストにいたっては全額返還40億円ものお金が動いたわけで、これは十分奇跡に値すると思うのですが、どう思われますか？
環境のネガティブ面をただ受け入れて唯々諾々としていれば、これ以上の奇跡が起こった、とお思いですか？
ネットカフェ難民等は生活保護に値しない、とする行政の姿勢をよしとせず、一時的な生活保護取得や居住地確保のための手助け・支援をもやいが行う事によって、かなりのネットカフェ難民の方が自立生活可能な状況に復帰できるようになってますが、これは十分奇跡に値すると思うのですが、どう思われますか？
生活保護が受諾だれないのは仕方ないことだと、唯々諾々とただ笑って生活を続けていれば、もっとたくさんの人が自立生活に復帰できるのだ、とお思いでしょうか。

そもそも、teruyastar氏が記事で取り上げているインドの子供達自体が、

何ヶ月分もの給料を踏み倒そうとする店主の店に、みんなで押しかけて、未払いの給料を払わせるように交渉する。

というふうに、店主のネガティブなところに対して、それをよしとせず攻撃してるんですが。
矛盾しまくってませんか？

もちろん、別に私はもう気付いていて、上のインドの子供のような例に鑑みても、teruyastar氏の意味しているポジティブ、自己責任というのは恐らく、

• 自らの境遇をあきらめ、社会が悪いのだからと何も行動しないのではなく、正確に自分のおかれた状況を分析し、状況改善のために適切な行動（その中には店主への給料支払い要求のような、他者の責任を追及するような行動も含む）へ自ら動くこと

ことであろうと思われるのに対し、私が攻撃しているポジティブ教、自己責任教というのが、

• 全て自分の心の持ち方、内面の問題の結果として現状が生じているのだから、文句を言わず抵抗せず現状を受け止めろ。変わりたいのなら自分だけが変われ、他人を攻撃するな、巻き込むな

というものなので、もしそうであれば両者は同じどころか正反対の概念（前者は一言で言えば「動け、変えろ」、後者は（自分の範囲以外は）「動くな、受け入れろ」）なのだから、別に前者を肯定するteruyastar氏と、後者を否定する私の立場は、対立するものでも何でもない。
少なくとも、インドの子供達が自分の現状を変えるために「店主の責任を追及すること」が何も問題ないとしている時点で、teruyastar氏と何ら対立する必要を感じないのですが。

でも、インドの子供達と同次元の、「自分の境遇を変えるために自ら行動する」ことは、今のワーキングプアの人達だって、かなりやってると思うのですけどね。
フリーターの待遇改善のために連帯し、データ装備費返還の動きなんかでも中心に立ったフリーター労働組合系の活動をはじめとして、フリーターの自立自存、治外法権的なアジールを作ろうとしている人だっているし、赤木さんが自らを曝け出して本を出したのだって、今まで見えてこなかった自分達のような存在を世に知らしめて、世の中を変えていこうとする動き以外の何者でもない。
でも、そういう動きにいちいち反感を顕にして異を唱えているのが、私の主観では「自己責任」を唱えている側の人のように感じてならないのですが。
もし、インドの子供達が店主に未払い賃金の支払いを求めるのはポジティブでいいことで、ワーキングプアが派遣会社の不法行為やおかしな生活保護の適用基準に異議を唱えるのは、ネガティブな攻撃でダメ、というのであれば、それはどこが違うのか私にはさっぱり判りません。

そもそも、イラク戦争の時の香田さんに対する「自己責任」大合唱をはじめとして、この日本社会で一般に自己責任というと、「自ら能動的に動いて状況を変えていけ」という「動け、変えろ」という意味よりは、「今の境遇はいらん事をしてきた結果、甘んじて受け入れろ」という、「動くな、受け入れろ」という意味で使われているように感じています。
そんな中で、もし弾さんやteruyastar氏の主張が、本当の意味での「動け、変えろ」という意味で使っていたと仮にしても、結局それを受け入れる社会の方が、「やっぱりそうだ、自己責任だよね」と納得した上で、「動くな、受け入れろ」という圧力になって下流層にのしかかっているような気がしてならないのです。
弾さんが使った表現を使うなら、弾さんが「笑え」と言ったことが、別に「笑っていた」ために今の地位にいるわけでもなく、たまたま運よくいるだけの人たちに自己肯定化の材料として使われ、たまたま下流層にいるだけの人を「嗤う」道具に使われている気がしてならない。
その圧力が、本当の意味で「動いて、変えないといけない」立場の人にのしかかっていて、「やっぱり、受け入れないといけないんだ」と、ますます「動けず、受け入れざるを得ない」状況に追い込んでいる感じを受けています。
もちろん、そんな圧力はねのけて「動き、変えて」いける強い人ばかりだったならよいのですが、そこまで精神力の高い人はそうそう多いわけではない。
圧力が弱くなるだけでも、「動き、変える」人は多くなると思うし、その裾野が広がる余波で、どうしても「動き、変える」事に足を踏み出せない弱い人も、救われる可能性が増える。

だから個人的には、ワーキングプアの立場にいる人には、「自己責任だから自分が悪いのだから、受け入れるしかないんだ」というような誤った自己責任感ではなく、「（問題のあることを問題であると指摘することも含め）動き、変えていっていいんだ」という正しいメッセージが届いて欲しいし、そのためにも「自己責任」の一言でワーキングプアを封じ込めようとする世間一般の風潮に異議を唱えたいだけなのですが。

PostGISで半径x m内の地物を検索する場合、latlong（経緯度）で入っているデータだと空間インデックスが効かないので、どうするかと言う問題ですが。
以前、こんな記事を書いて、むりくりlatlong上で「半径x mの円」を内包する（内接ではない）矩形をざっくり計算し、それを空間インデックスと引き当てて、その後distance_sphere（latlongで入っているテーブルに対し、地球を球体近似した上での表面距離を算出する関数）の実行結果と比較する検索方法を紹介しました。
が、これは別にこれが常道というわけではなくて、GIS素人がちょっとずつ独学して、どんなやり方をすればいいかと試行錯誤した結果の産物です。
まあ言うなれば、ISSEIと同レベルのもの。

が、最近ひょんな事からGISを専門に開発しているらしい人のソースを見せてもらう機会があったのですが、そこではTransform関数を使ってlatlongをUTM（ユニバーサル横メルカトル図法。m単位の直角座標系）に変更し、その上でdistance関数を使って範囲検索を行っていました。
具体的には、記憶頼りですが確かこんな感じ（Zone 53N、東経132-138での場合。SRIDは32653。範囲10km検索）。

SELECT * FROM geomtable WHERE ST_Expand(ST_Transform(ST_GeomFromText('POINT(135 35)',4326),32653),10000) && ST_Transform(geom_column, 32653) AND ST_Distance(ST_Transform(geom_column, 32653), ST_Transform(ST_GeomFromText('POINT(135 35)',4326), 32653)) < 10000;

• あれ?Expand使ってたっけ?でも使わないと空間インデックス効かないはずだから、多分これであってるよなあ...。
• いつの間にか、PostGISの関数ってプリフィックス「ST」が付くようになってたのね...。

なるほど、PostgreSQLは関数インデックスも張れるので、ST_Transform(geom_column, 32653)した値について空間インデックスを張るようにしておけば、これで距離半径検索できますね。
多分、単に三平方計算してるだけだと思われるdistance関数の方が、球面距離計算するdistance_sphereより計算早そうだし。
さすが専門家の技。

問題があるとすれば、UTMは経緯度範囲で適用する座標系が異なるので、複数の座標系をまたがるような範囲に対してサービス提供するアプリケーションの場合、その範囲の座標系毎に関数インデックスを張っておかないといけないので、データ挿入・更新の多いアプリケーションだと遅くなるのかも。
また座標系を大きくまたがるような範囲の距離計算は不正確になるので、検索半径も見合った範囲に抑えておく必要がありそうです...まあ、経度6°を上回るような検索は誰もしないと思うけど。

あと、マニュアルを見ると、DWithinというような関数もできているようです。
説明文を読むとこれは空間インデックス使ってくれるそうなので、これまでの「ExpandでMBRの重なりをインデックスチェックしふるいをかけてから、Distanceをチェック」という形じゃなくても、

SELECT * FROM geomtable WHERE ST_DWithin(ST_Transform(ST_GeomFromText('POINT(135 35)',4326),32653), ST_Transform(geom_column, 32653),10000 );

みたいなSQLで、最初のSQLと同じ結果が得られるのかなと。

私も参加させていただいているGIS-GWですが、新たにシリウステクノロジーズさんが参加され、同社のエリアブックマーク、モバShot等のWebアプリがGIS-GWメニューに追加されました。

シリウスさんと言えば、誰でも簡単にケータイ位置情報対応サイトが作れるAPI、GeoPlatform APIを提供されています。
現在は、参加したばかりですので当然GeoPlatformAPIとGIS-GWのIDは異なりますが、もしかするとそのうち統合されて、GeoPlatFormAPIを使った位置情報サイトは同時にGIS-GWにも登録され、サイト間の位置情報流通が容易にできるようになるかもしれません。
さらには、AdLocalなんかも配信され、それじゃちょっとした小遣い稼ぎにGIS-GWに参加して、ジオメディア作ってみるか、的な人も出てくるかもしれません。

なかなか妄想が膨らみます。

※　一応書いておくと、私は一応GIS-GWの中の人ですし、上記に類したディスカッションも出ていることは確かですが、別に決定したことではなく、多分に私の「こうなればいいなあ」的妄想が入っていますので、為念。

ちょwwww

ドコモとGoogleが提携　正式発表

NTTドコモとGoogleが、検索サービスや検索連動広告などで提携すると発表した。iモード端末に「Google マップ」対応アプリを標準搭載するなど、検索以外のGoogleサービスもドコモ端末に取り入れる。

「立ち行かなくなる...トトカルチョ」自重wwwww

ケータイで地図・ナビゲーションアプリやサイトを提供している公式CPには、辛い時代になりそうです。
まあ、地図だけに限りませんが、この業界割と「外部に無料の一般サイトという沃野があることを知らない」「公式メニューから辿っていくことしか知らない」ユーザのデジタルディバイドに支えられてきた一面がなきにしもあらずなので、Googleのような優れたソリューションが公式メニューの一面を掻っ攫う＆一般サイトの沃野への誘導を担うようになってしまうと、かなりの打撃を被るのではないかと思います。

会員数の維持・増加は、入会者数（IN）-退会者数（OUT）のフローなわけですので、会員数を増やす戦略は

• INを増やす（広告やアフィリエイトにお金を投資し、顧客の流入を増やす）
• OUTを減らす（機能改善や機能アップにお金を投資し、顧客満足度を上げる）

の両方が採れ、これまではどちらを採ってもそれなりに採算ベースに載ってきたわけです。
が、今後は確実にINが減り、かつそう簡単には戻らなくなるので、OUTを減らす戦略を採っていたところは会員数がストックとなり、業績を伸ばせないまでも体勢転換を整える猶予が得られるかもしれませんが、INを増やす戦略を採っていたところにとっては、さらに厳しい状況が待っていそうです。

一方で、公式ではない一般サイトにとっては、いうまでもなくこれまで公式に流れていたフローの一部が一般サイトに溢れる形となるので、今後がチャンスになるのかなと思います。
（コンテンツフィルタとか、鬱陶しいカオス要素もありますが）
位置情報系だと、単なる地図サイトとかだとGoogleマップアプリやZENRINアプリがデフォでついてくるので、集客は見込めないと思いますが、Googleとかは自分でコンテンツを作るわけではないので、独自のコンテンツを持つサイトならば、十分に生き残れる可能性はあります（むしろ、Googleがユーザを誘導してくれる入り口となる）。
そして、そういった独自色のあるコンテンツを持つ一般サイトが、GIS-GWのような考え方で互いに有機的に連携し、全体で巨大なポータルサイトのように振舞うならば、大きくユーザを集め、さらにその上にAdLocalのような収入源がセットで載ってくるならば、大きなビジネスの場に育つ可能性は十分にあると思います。

ジオメディア新年会でみんなが言っていたように、本当に今年が「ジオメディア元年」になるかもしれません。

タイトルはウソです。
そういえばどこに消えたのでしょう...＜パペマペ

1/24は、第７回エンジニア交流勉強会「gungi」に参加してきました。
今回のテーマは、「システム自動管理ツール Puppet」について、ということで、最近次期システムがあまりに実験的なので基盤部門に「自力で構築して」と言われて泣いている身という事もあり、行って参りました。

正直、全然レベルが違いすぎて、「何百台ものサーバ、shやPerlの捨てスクリプトでなんかシステム構築やってられねえ、完全に自動化しなきゃやってられるか」というレベルの人の話だったので、スクリプトでの自動化どころか、ようやく数台のサーバを手作業で試行錯誤して手順書書いて、のレベルの私では、Puppetが必要になるレベルの状況も想像がつきませんでしたが、非常に有用なツールであるということは判りました。
サーバの設定・構造そのものが、Subversionのようなバージョン管理ツールで自動的に一斉に共通化・保証され、切り戻し等も簡単に行えると言うのは、なかなかすごいです。

でも、4travel　CTOの方のセッショントークでは、100台くらいのサーバならまだ自動化ツールなしでも対応できる（というかまだ自動化していない）という話を聞いて、ちょっと安心（というか完全自動化されていないというだけで、レベルは全然違うんでしょうが）。

puppetと同じ話者の方の、OpenBSDの紹介も非常に面白かったです。
OpenBSDというのが、非常にこだわりをもった変人集団によってフルスクラッチされた、異常に？堅牢なシステムであるということはよく判りました。

今回のgungiで一番の収穫は、後の交流会でSunのむっちゃとんがった技術者の方に出会えたことです。
話術もむっちゃ面白く、確かな技術裏づけで自信を持って話すので、飲み会が終わって気付いた時には完全にSolarisファンになってしまっていました。
彼曰く、今流行りのmysqlやmemcachedなんかも、Linuxで使っているとメモリ処理の制約で最高のパフォーマンスが出ない、Solarisで最高にチューニングすれば、下手したら100台のサーバを10台に減らせるくらいの勢いで高速化できるとのこと。

実は私の会社でも、Solarisは全く同じ構成のサーバ構築がコピペ感覚でできる（それこそ、puppetいらない？）らしいので、基盤部門の運用効率を上げられそうということで導入を検討してて。
私の前担当したシステムで試験的に導入させてくれ、というので、OKしたんだけど、微妙にコマンドが違うので、Linuxベースの外注に作ってもらったプログラムが、外部コマンドを叩いてたりするとそのままじゃ動かなくて検収に無駄に時間かかったり、試験的導入だったために環境構築が不十分で、SunStudioでコンパイルしたコンポーネントとgccでコンパイルしたコンポーネントが混ざってたりして、そのためImageMagickとか必要なコンポーネントの追加がうまくいかず、代替案探させられたりと、色々苦労させられた経験があって。
こんなん基盤の運用にはメリットあるかもしれんけど、開発にはデメリットこそあれなんもメリットないやんけ、と思って、「Solarisキライ」モードになってたんだけど。
でも、そんなに実行効率がよくなるのなら、開発にも十分メリットあるよな、と思い、すっかりSolaris好きに洗脳されてしまいました。
というか、最近のWeb2.0企業のように、サービス負荷が上がればバンバンサーバ調達できるようなところ（彼のブログではGoogleモデルと書かれてますが）なら、Linuxとかでもいいんだろうけど、うちの会社のようにおいそれとはサーバ増やせないところでは、1台のサーバのパフォーマンスを追及するのが合理的だよなあとか思ったりして、その意味でもSolarisの選択は最適なのかなあ、とか思ったりしました。

もちろん、別に無チューニング・デフォのSolaris突っ込んだだけで、Linuxに数倍するパフォーマンスをたたき出すというわけでもないだろうので、結局は商売の話で、サーバを劇的に減らすためのチューニングコンサル費用と、サーバを多数運用する購入・維持管理費用を天秤にかけてのTCO判断でどうですか、ということなのだろうけど、それでもサーバ屋なのにサーバをバンバン売るのではなくサーバを減らすことを提案すると言うのは良心的だよなあ、という感じは受けた。
商売上は商用Solarisを売らざるを得ないのだけど、Linuxからの移行のしやすさや新機能の導入速度等を考えれば、OpenSolarisを使ったほうがいいですよ、みたいなことも言ってたし。

gungi第7回、以上みたいな感じでした。

今週は3日連続で飲んでました。
中日の1/23は単なる会社の飲みだったのですが、行った店が珍しい？かったのでネタに。

社内で四半期毎に表彰みたいなのがあるんですが、それで部署が賞をもらったので、それを原資に「ふぐ」を食いに行ってきますた。

ふぐ刺し、ふぐ唐揚げ、てっちりとふぐ三昧。
回転寿司なんかで安い「ふぐ唐揚げ」なんかは食ったことあるんですが、刺身やてっちりは初めて。
刺身の「ぷりぷり」感はすごかったです。むちゃくちゃうまかった。
「唐揚げ」の回転寿司との違いが判ったか、と言われると「すんません」としか言えないのですが...。
熱い「ひれ酒」も深くて美味かったです。

▲ ぷりぷりのふぐ刺し ▲

▲ 紙の鍋で出てきたのが面白かったてっちり ▲
後の雑炊もふぐのダシがよく効いていておいしかった。

なんか風邪が流行ってたりで参加者人数が直前に減ったりしたので、自前1,000円でふぐが食えました。
でも、賞金が手渡しではなく、ちょっと前から賞該当プロジェクト担当者（今回は私含む）の給与口座に振り込まれるようになったために、実際には財布からは1万5千円くらいを支払うことに。
実際には1,000円と判ってても、何か複雑。

それによく考えると、給与合算てことは、課税されるよね...とか思ったりもしないでもないけど、それでもまあ数千円でふぐフルコース食べられたと考えれば、まあいいかっ。
うまかった！

絶賛炎上交際中の「華麗妹」姐さんに教えてもらったので、1/22、ゴーガ小山さん＆Wikiaゆきちさん主催の「Wikiなにがし」に行ってきました。
なんか小山さんブログの案内をみると「Wikiなんとか」になってますが、小山さん自身の報告だと「Wiki飯」になってますし、会の間中は「Blog Dinnerに対抗してWiki Dinnerだ！」とか騒いでたので、別に何でもよかったみたいです。
人数はともかく、会場のTikiTikiがハワイアンダンスショーの見れるええ感じのとこやったので、会場はWiki Dinnerに勝ったぜ！そのうち人数でも勝ってTikiTiki貸切だぜみたいな話しとりました。

▲ 健康的なビキニお姉さん方と踊る ▲
某社部長＆街づくり博士

来られていたのは、Wikiaのゆきちさんから、CHAKUWIKIの谷口さん、Walwikiの塚本さん、Wikipedia「京都の元学区」項のドンである街づくり博士の方等、名だたるWiki界の重鎮ばかりでした。
そんな中、何となく面白そうなので来たに違いない、と思っていた華麗姐さんですら、Wikiaのアカウントを持っていたということで、なんかよく判らんけど参加してたというようなのは俺一人...アイデンティティ飲み会に続いてKYな私でした。

とりあえずどんな話したっけ...小山さんが日本バカ地図API＆日本バカ測地系を作るという話はよく覚えてるんだけど...後は元学区の話題が面白かったのでよく覚えてるけど...。
でもまあ、Wikiに関する熱い思いを皆さん語って、面白い会でした。

なんか話してて思ったのは、Wikiを共有編集する共有リソース、公共の場と捉えたWikiに価値を感じる人と、個人のCGMツールとして面白いと思う人がいるのかなあと。
で、今回の集まりでは前者の話が多かったので、前者の捉え方をする人が中心なのかなあと思って聞いてた（必ずしもそうじゃないよと、最後の方で塚本さんに教えていただいたが）。
なので、後者に面白さを感じている自分としては、前者の話題の中で言い出せなかったけど、Blogも好きだしWikiも好きなので、両者の中間的なツールみたいなのがないのかなあ、とか思ってた。
もっと言えばTwitter的な、思いつきをすばやく垂れ流しつつ、その中で膨らませたい話題についてはBlog記事くらいまで膨らませてフローの情報として流通させられて、そしてそれを続けて言っていると自然とWikiのようにまとめられてストックの情報として整理されるような、そんなツール。
単にツールを使い分ければいいだけなのかもしれないけど。

なんかいきなり「月次の会」になったようで、次回は2/22（金）の20時からだそうです。
小山さんのアナウンスでは「興味のある方は、新宿三丁目のTIKITIKIにお集りください」みたいな感じで事前参加表明いらないみたいな感じだけど...ほんまにええんかいな。
一応またKY（読まずに）今のところいくつもりなので、興味のある人はぜひ。

DoCoMoのiエリアをベースに位置情報でスタンプラリーするようなゲームを作ってるんだけど、DoCoMoのFOMA機で経緯度情報が取れるようになったのを機に、地方でダメダメなiエリアベースのスタンプエリア分けではなく、地方にも公平な独自エリアでのサービスを検討してたりする。
で、そのエリアの再構成方法として、当初iエリアのメッシュ構成を再構成して独自エリアを構成すればいいかなと思ってたのだが、蓋を開けてみると全国のメッシュ数が500万くらいあって、これを直接エリア分けするのはやってられねえ、ということで、現在GISツール等を用いてポリゴンベースでエリア分けしてたりしてる。

でもそうなると今度はポリゴンベースでエリア分けしたものをメッシュデータに変換するロジックを組むのがまた泣きそうな勢いで、それならもうそのままポリゴンデータぶち込んでPostGISなんかでポリゴン衝突判定してやった方が早いんじゃね？と思い、iエリアのデータを用いて、500万件のメッシュレコードをmysqlに叩き込んでやったものと、505件のポリゴンデータをPostGISに叩き込んでやったものの間で、経緯度からエリアを導出するBenchmarkを取ってやりました。

ベンチのコードは概略こんな感じ。

  use strict;
  use DBI;
  use Benchmark qw(:all);

  my $pdbh = DBI->connect("dbi:Pg:dbname=iareadb", "xxxxxxxx", "xxxxxxxx");
  my $mdbh = DBI->connect("DBI:mysql:database=iareadb", "xxxxxxxx", "xxxxxxxx");

  my @latlngs = (
      [35.00000,135.0000],
      [35.00000,139.0000],
  );

  my $count = 10000;

  my $r = timethese($count,
      {'PostGIS-polygon' => '&test1;', 'mysql-mesh' => '&test2;', });

  cmpthese $r;

  sub test1 {
      foreach my $latlng (@latlngs) {
          my ($lat,$lng) = @{$latlng};

          my $point = "GeomFromText('POINT($lng $lat)',4326)";
          my $sql   = "SELECT areacode FROM iarea_polygon WHERE polygon " .
                      "&& $point AND ST_Intersects(polygon,$point)";

          my $sth = $pdbh->prepare($sql);
          $sth->execute();

          my $areacode = $sth->fetchrow_hashref->{areacode};
      }
  }

  sub test2 {
      foreach my $latlng (@latlngs) {
          my ($lat,$lng) = @{$latlng};

          my $mesh7 = mesh7($lat,$lng); <- メッシュIDを導出する関数(省略)
          my $sql   = "SELECT areacode FROM iarea_mesh WHERE mesh7='$mesh7'";

          my $sth = $mdbh->prepare($sql);
          $sth->execute();

          my $areacode = $sth->fetchrow_hashref->{areacode};
      }
  }

結果はこんな感じ。

  PostGIS-polygon: 225 wallclock secs ( 1.81 usr +  0.24 sys =  2.05 CPU) @ 4878.05/s (n=10000)
       mysql-mesh: 15 wallclock secs ( 1.79 usr +  0.22 sys =  2.01 CPU) @ 4975.12/s (n=10000)
                    Rate PostGIS-polygon      mysql-mesh
  PostGIS-polygon 4878/s              --             -2%
  mysql-mesh      4975/s              2%              --

秒間実行数どちらも5000件弱と、どちらでもいいよね(ということはデータ管理しやすいポリゴンがいいよね)という話になりそうなんだけど。
でも、ベンチマークを走らせている感にかかっている体感時間的には、明らかに圧倒的にmysqlのメッシュ検索の方が早い。
各結果の前にwallclock secsという項目があり、PostGISでは225、mysqlでは15となってるけど、この比と同じくらいの感覚で明らかにPostGISの方が時間がかかってる。

PerlのBenchmarkや、このwallclock secsという項目についていろいろGoogleで調べてみたけど、どのベンチマーク記事を見ても最後の秒間処理数の結果で比較しており、wallclock secsに注意を払っているものがない。
このwallclock secsというのは何者なのだろう？
もし総試行にかかった時間であるのならば、なぜ試行時間が異なるにも関わらず秒間処理数は同程度というベンチマーク結果が出るのだろう？

1つの「仮説」として、Benchmarkの結果で返って来るのは、全体の処理にかかった時間じゃなく、PerlプログラムがCPUを占有した時間じゃないだろうか？と考えた。
つまり、SQLの返事を待っている間のようなPerlプログラムとしてCPUを占有していない時間についてはBenchmark外になるのかな？飽くまでBenchmarkはPerlプログラムのアルゴリズムとしての効率しか測らず、そのためSQL実行時間以外はほとんど同じDBI処理であるメソッド間のベンチ比較なので、ほとんど同じ結果が返ってくるのかなと。
もしこれが正しければ、インデックスを張っているか張っていないかの差だけで後は全く同じテーブルに、全く同じPerlコードでアクセスした場合、インデックス差があるから実行時間には天地の差が出るはずだけど、Perl部分は全く同じだから秒間処理数は全く同じになるはず、と思って試してみた。
条件は先のベンチプログラムと一緒で、接続先のみmysqlのインデックス付テーブルとインデックスなしテーブルの比較にし、とはいえ500万件のテーブルにインデックスなしでアクセスさせると死ぬので、レコード件数だけ2万件程度に減らして、試行回数も1000ループに減らしてベンチを取ってみた。
結果は以下の通り。

     index:  1 wallclock secs ( 0.20 usr +  0.01 sys =  0.21 CPU) @ 4761.90/s (n=1000)
            (warning: too few iterations for a reliable count)
  nonindex: 109 wallclock secs ( 0.41 usr +  0.08 sys =  0.49 CPU) @ 2040.82/s (n=1000)
           Rate nonindex    index
nonindex 2041/s       --     -57%
index    4762/s     133%       --

Perlプログラム部分は全く同じであるにもかかわらず、秒間実行数に倍以上の差が出てしまいました。
かといって、実際のベンチ実行時間は、やはりwallclock secsのところに示されたとおり1:109くらいの体感差があったのだけど、そこまでの差が秒間実行数に出ているわけでもありません。

Perlプログラム部分だけの効率を見ているわけでもない（仮説は崩れた）し、Perl外の処理を含めたコード全体の実行時間を見ているわけでもなさそうなBenchmarkの秒間処理数って、いったい何を測定しているのだろう...。
誰かご存知でしょうか...。

でもまあ一つ判ったのは、2万件のレコードに対しインデックス張った時と張ってない時の差が半分程度で済むはずがないので、こういうケースではベンチマーク結果の秒間処理数よりwallclock secsを見たほうがよさそう、というところだろうか。
とすると、エリア判定に500万件のメッシュレコードを表DBに突っ込むのと、数百件の空間DBに突っ込むのでは、前者の方が10倍くらい高速そう、ということになりそうです。
（ちなみに、EXPLAINで空間インデックス使っているのは確認したので、レコード数が少ないためにインデックスが使われていない、という可能性はなさそうです）
以前、正規表現でのiエリア判定とPostGISでのiエリア判定は、後者が前者の50倍、と書きましたが、これもwallclock secsで比較するなら7倍程度になりそうですね...。

うう...500万件のメッシュ管理嫌だなあ...ポリゴンをメッシュに引き当てるのもめんどいなあ...。

後ついでに、この辺調べてて判ったのは、mysqlは4.1以降MyISAM、5.0以降InnoDBで空間カラムに対応したと言っているけれど、

• 5.0では、InnoDBで空間カラムは作れるけど、空間インデックスは張れない。空間インデックスを張るならMyISAMでないとまだダメみたい。（5.1は未確認）
• MySQLの空間演算子では、まだMBR（最小外接矩形）間の関係しか判定できない。（これは5.1のマニュアルにあったので、5.1でもそうみたい）
  今回のようなポリゴンとの衝突判定をするようなケースでは、まだPostGISしか使えなそう。

というようなあたり。

OpenIDとか、最近は全然調べてなくて2.0で何が変わったの？というレベルなんですが、社内でちょっとOpenIDとかの認証APIへの興味が高まってきて、昔ちょっと調べてたと言うだけで相談されたりしてました。
そういう時期にアイデンティティ飲み会とか言うのが開催されるみたいなので、そんじゃまこの機会に最新情報スネークしてこようか、という感じで参加してまいりました。
（というか、別の所用が入っていたため同僚に参加お願いしてたので参加者リスト別名ですが、直前に所用の日程が移ったので参加してまいりました）

場所は...中目黒のすげえいい店だったので、記事にしたかったのですが、先にレポートされているまちゅさんが自重されているので私も自重。
いい店だったのですが、判りにくいところでした...お陰で周辺走り回り、20分近くも遅刻。
まあ私の場合、入り口が分かりにくかったと言うよりは、頼りにしてたLivedoorグルメの印刷地図上の位置が思いっきりズレていたので、全然違うところを走り回っていたのですが...。

行ってみた感想としては、とりあえず「ほとんど判らなかった」状況でした...。
特に、私の席は周囲がエンタープライズ系の人中心で、OpenID/SAMLで言うところのSAMLの話題が中心だった（もしかしたらOpenID/SAMLを問わないアイデンティティ一般の普遍な話題だったのかもしれませんが、それすら判らない状態）ので、そちら方面はほとんど知らない私はキーワード収集するのが精一杯と言う感じでした。
SAMLについてはよく知らなかったんだけど、なんかオープンに出てきたOpenIDに対するデジュール的な仕様という事で、位置情報で言うところのGeoRSS/KMLとGML/G-XMLとの関係みたいに、実際にはほとんど使われていない規格なのかしらんとか思い込んでいたら、どうしてどうして、エンタープライズ用途や政府機関なんかのシングルサインオン系システムではむちゃくちゃ採用されているらしい。
Google AppsのSSOなんかも、裏ではSAMLが採用されているとのこと。
判らないなりに掴んだ感じでは、最近Mixiが自社の異なるドメイン間でのログイン情報交換にOpenIDのプロトコルを採用したという話がありましたが、ああいうのを実現できるものなのかなーと思いました。
もっと、SSOだけでなく、属性交換とかアクセス制御まで含むでっかい概念みたいですが...これ以上書くといい加減な話を撒き散らす事になるので、後は他の参加者の方のレポートから追ってください＞＜

実際周りで話を聞かせていただいた方々も、会を主宰されたSunの工藤さんから、NTT系の方や野村総研の方等、もろエンタープライズな方々ばかりで、また単にSAMLを使っているだけではなく実際にSAMLを規定している？リバティアライアンスに参加して策定に関わっている方でした。
面白かったのは、私が位置情報の世界に飛び込むきっかけとなったNTTの「モーバイルインフォサーチ実験」、その中心的な方で、長い間リスペクトさせていただいてその後何度かお会いさせていただいてもいる高橋さんという方がおられるのですが、その方の元上司だった、という方もおられました。
そんな重鎮の中にど素人が突撃していったわけですが、皆さん親切にいろいろ教えてくださいまして、たとえば位置情報系では、リバティアライアンスでSAMLと共に策定されているID-WSFという属性交換？の仕様に、GeoLocationという項目があって、これを使えばSSOさせたユーザの持つ位置情報を流通させることができるといった話も伺うことができました。
GIS-GWとか、まさにセキュアに位置情報を交換する方法とか模索してたりするので、調べればその辺に応用できるのかなとか思ったり。

IdentificationとAuthenticationとAuthorizationの区別くらいはついてるよと思いこんでいたのですが、全然判ってなかったり、それだけじゃなくて他にもCertificationとかRegistrationとかReputationとかたくさん理解しないといけないことがあったり（ちなみに、覚えないといけない単語を収集してきただけで全然判ってません）、すごく刺激になりました。
薦められたOreilly本を買うなりして勉強し、第2回の飲み会ではもうちょっと話に参加できるようになりたいと思います。

Digital Identity posted with amazlet on 08.01.21 Phillip J. Windley Oreilly & Associates Inc (2005/08/30) 売り上げランキング: 144378 Amazon.co.jp で詳細を見る

帰って早速CPANにSAML関連の何かないか探してみたところ、Net::SAMLとかいうの見つけたんだけど、pod読んでも何のことやらさっぱり判らない...先は長そうだ。

他の方のレポート：

• 第1回アイデンティティ飲み会 - Yet Another Hackadelic
• 第1回アイデンティティ飲み会 (エンタープライズとWebの素敵な出会い) - まちゅダイアリー (2008-01-18)
• 第1回アイデンティティ飲み会 (と信じられないようなミス) - たけまる
• アイデンティティ飲み会 - snippets from shinichitomita’s journal

先のエントリですが、何も個人がいかなる形でも社会を変えるのが不可能、とかそんな事は言ってない。

はてなブックマーク > ここギコ！: 「自己責任教」は社会科学的にトンデモじゃないのだろうか

ryokusai 選挙で投じる一票を考へてみたら個人の行動が社会に及ぼす効果と「水伝」の違ひがわかるのではないかと。一個人の行動など高が知れてゐると無視するのも一つの態度だが。

選挙で一票を投じる事をはじめ、適切な行動を取ればそれに応じて何らかの結果があるのは当然（とはいえ、選挙の場合は閾値のあることなので、結果的になんら影響を与えられないのが結果、という場合もありますが）。
「水伝」での喩えを続けるならば、「水によい言葉をささやく」のではなく、水を変性させるのに適切な物理操作、例えば手でビーカーを持って暖めるだけでも、それに応じて水の温度が多少なりとも上がる、というような変化が生じるのは当たり前のこと。
もっと激烈な変化を与えたいのならば、劫火の中にビーカーを叩き込んで蒸発させてもいいし、極寒の中で凍てつかせてもいい。

それと同様、自分の境遇を変えたいのであれば、あらゆる適切な行動、状況への異議申し立てもあるだろうし、今の状況に責任のある人間を洗い出して責任を追及することもあるだろうし、赤木智弘さんのように情報を提供して世間に訴えるというのもあるだろうし、あらゆる適切な行動を取ればいい。
そういった適切な行動に対しては、社会がその度合いに応じて徐々に状況を変えていくだろうし、その可能性を否定もしない。
そして、その「適切な行動」の中には、自分ではなく他者の過ちを指摘したり、責任を追及したりといった、どちらかというと「他者を対象としたネガティブな行動」も当然含まれるはずだ。
にもかかわらず、元記事のような論調は、他者に対してネガティブな感情を持つな、まず自分を正せ、自分を正せば自ずと自分を取り巻く境遇も変わってくる、というような話で、社会科学的に適切とも思えない行動をとっていれば周囲も変わる、みたいな言説なので、自然科学的に適切でない「よい言葉をささやく」ことで水が変わる、という「水伝」と似た構図だよね、と書いた。

できることならば物事をネガティブに考えない、できることならばいつも笑っている、というのは個人の心の持ちようとしてアリだと思うし、私もそうありたい。
でも、それは周囲との関係がどうだからというものではなくて、多分に自分自身の心のあり方、人としてのあり方、信念としての問題だと思う。
別の言い方をすれば、はてブコメントにもあった、

taitoku 「社会が変わる」と「自分の社会へのまなざしが変わる」とを混同する人が多いからじゃないかな

のような感じで、ポジティブであり笑い続けることで、社会が変わるのではなく自分の社会の接し方が変わり、社会にはあるのが当然の少々の不条理くらいではへこたれずに乗り越えられるようになる、程度に過ぎない。
それでは乗り越えられないような不条理だって世の中に普通に存在するし、そういうものに当事者として遭遇したり、遭遇した人の問題について論じたりする場合は、 他者の過ちを指摘したり、責任を追及したりといった「他者を対象としたネガティブな行動」も、合理的に選択することは許されるはずだ（もちろん、問題を解決するに妥当で合理的な範囲においてであり、自分が不幸だからと誰も彼もに当り散らすテロリズムを肯定するものではない。）。
にも関わらず、「自己責任教」というか「ポジティブ真理教」な人は、「まずポジティブで笑っていろ、ポジティブでいればあらゆる困難は乗り越えられるし周囲も変わってくる、ポジティブでいるためにはネガティブなものには近づくな、関わるな」というような言い方、あるいは酷い人になると「俺が成功したのは笑っていたから、成功しなかった連中は笑っていなかったから」等というような言い方で、実際には単にポジティブで乗り越えられる範囲の不条理にしか出会っていないだけの人が、本来はもっとも人の助けが必要なレベルで不条理に追い込まれている人を阻害している。
或いはその不条理に落ち込んでいる人本人を、不条理を乗り越えるために適切な行動へと動機付けさせるのではなく、今の自分の境遇は自分のポジティブさが足りなかったためだ等と見当違いの自己嫌悪の方向へ追い詰めている。

もちろん、繰り返しになってしまうが先にも書いたように、「ポジティブ真理教」も自分の心のあり方として信じている限りにおいては問題ない。
極端な話、民族浄化のような極限の不条理に対してさえ、「ガス室に送られる列車の中でさえ、おれは死ぬ瞬間まで笑っているよ」的な心の持ちようは、賞賛されることであれ責められることではない。
でも、それを直接「成功するには」だの「自分の境遇を変えるには」だのといった現世利益と結びつけ、「救われないのはお前の信心が足りないからだ」的な言説を展開したり、それを信じない者へのジハードを展開したりするからカルトになってしまうんじゃないか。

ところで、以上書いてきたように「ポジティブであれ」等ということに囚われず、ネガティブであろうがなんだろうが自分の状況に対し適切な行動を選択しそれを取れば、それに応じた結果が返ってくるわけだけど。
それならばそれで、今ワーキングプアだの不条理な立場におかれている人はどうしてそういう適切な行動を採らないの？それを採っていないのは、やっぱり各人の自己責任じゃないの？みたいな話にもなってくる。
これに関しては、そりゃ適切な行動を取れば結果は返ってくるだろうけど、その適切な行動自体を皆が皆採れるわけじゃないよね、というのが答え。
例えば「水伝」喩えを受けて自然科学の喩えを続けるなら、水を蒸発させるのが目的なら熱を加えればいいというのは判ってても、持ってる熱量がマッチ1本だったら、或いはそのマッチすらも持ってなかったら、蒸発させられない。
或いはマッチ自体はあっても、「火気厳禁」なんて条件が科されていたら、これもまた無理。
まして、「水を蒸発させるには、蒸発してと水にささやけばいいのじゃー、それで蒸発しないのはお前の信じる心が足りんからじゃー」みたいな事をいうカルトな人（その人の体温は100℃くらいあって息だけで蒸発させられるのかもしれませんが、普通の人は無理）がいて、足りない火力を何とか集めようとするのを邪魔してたりしたら？
そんなカルトな人の声が大きすぎて、「水を蒸発させるには熱を加えればいいんだよ」というような適切な情報知識さえ、水を蒸発させたい人のところに届いていないかもしれない。

実際のワーキングプア問題なんかでも、もうその段階まで追い込まれてしまった人は、個々のケースがあるけど、昼夜を問わず掛け持ちでバイトを入れざるを得なかったり、休みを取れば即日解雇なレベルで雇用が守られていなかったり、日々生きていくための仕事をしていくことだけで精一杯で、待遇改善のために連帯するとか、生活保護申請に出向くとか、そういうことすらできない人がたくさんいる。
選挙で一票を投ずるといった基本的な行動すら、住民票を不安定な生活基盤しかない都会に移せず、かといって投票しに田舎へ帰るお金も時間も無くて、投票できないという人も大勢いる。
ましてや「自己責任、自己責任」の声が大きすぎて、自分の採るべき適切な行動の情報が得られていない人が無数にいる。

なので、今必要なのは、一人一人の持つ熱量は小さくても集めれば水を蒸発させられるかもしれないので、それを集められる場を集められる者が作ったり、或いはもっと直接的にガスバーナーを貸す余裕があるものは貸してやったり、邪魔をするカルトな人の洗脳を解いていったりすることが必要なことであって、「てめえの熱量だけで何とかしろ、何とかできなければ自己責任」なんて言うことじゃないと思う。

----- 追記1/20 -----

別エントリ起こすほどの内容でもないので追記。

このエントリへのはてなブックマーク：

tkmisawa 「適切な行動」が科学的(合理的?具体的?)かどうかってことなのかな。「ポジティブ真理教」の人にとっては「まず自分を正せ」が「適切な行動」なんだろうから・・・。もう一歩踏み出す必要がありそうだ。

> 「適切な行動」が科学的(合理的?具体的?)かどうかってことなのかな。
まさにその通りかなと思います。
「水伝」の人にとっても、「水にささやけ」は「適切な行動」なわけなので...。

「水伝」と「ポジティブ真理教」の違いは、「あらゆる場合に成立しない」と「一定の条件化では成立する」の差しかなくて、本来科学的に適切な行動を導くには必須であるはずの個々の状況分析を無視した上で、どんな状況でもある特定の行動を採っていれば状況は変わる、と言っている時点で科学的ではありません。
むしろ、「ポジティブ真理教」は、一定の条件化では成立するので、成功事例が観察される分、性質が悪いわけですが...。

別の喩えで言うならば、たとえば「架空請求詐欺」の例なんかどうでしょうか。
よく「架空請求詐欺」は「無視が鉄則」と言われ、実際多くの事例は無視しないと状況が悪化するわけですが、一部の裁判所の小額訴訟を悪用したケースでは、無視すると逆に状況が悪化します。
にも関わらず、「架空請求は無視が鉄則、無視しないで状況を悪化させれば自己責任」等と主張する「架空請求無視真理教」の人がいればどうでしょうか？
「ポジティブ真理教」の人には、同じ構造が見て取れると思います。

努力教とハゲタカ教と最善説 -過ぎ去ろうとしない過去-

泣けました。大元記事の数倍泣けました。

まあ、セグメントの問題と言ってしまえばそれまででもあるし、基本「大元記事の通用しないセグメント」に居るわけではない自分としては、素直に大元記事のエッセンスだけ受け取ってればええやんと思わないでもないし、それを素直に受け取れない自分に自己嫌悪するところもないわけではないのだけれども。

学生時代、識字学校で文字を教えるボランティアをしていたのだけど、貧困で若い頃文字を学ぶ機会を得られず、それ故に苦労してきたお婆さん達は、みな70歳代にして80歳代並の皺くちゃな外観をしていた。
それに日常として接していると、同じ頃バイトをしていた診療所に来ていた、どう見ても60歳代にしか見えない70歳代のご婦人、友人の方と「いつもお若いですねえ」「いえいえ」等と会話しているその方に対し、本来は寿ぐべき「若さの維持」という事実に、強烈な違和感、というか苛立ちを感じたことがあったのだけど。
なんか、それに近い違和感や苛立ちを、大元記事のような言説には感じてしまう。

というか、「水によい言葉をかけると結晶が変わる」という「水からの伝言」が自然科学的にアウトなのであれば、「社会を変えるためには、まず自分から変わる＝自分が変われば、社会も好転する」というような「自己責任教」は、社会科学的にアウトなんじゃないのだろうか。
無生物だろうが、無機物であろうが、感謝の念を抱いて生きるというのは全然道徳（宗教？）的に「アリ」だと思うが、それで実際に「物質が変性する」と言ってしまうから「水からの伝言」はトンデモになってしまう。
同様に、「社会が自分にどんな反応を示そうと、明確な翻る事のない悪意を持って接してこようと、私は笑い続ける」という覚悟、信仰告白は全くもって「アリ」だと思うが、そこに「笑い続ければ、社会も（自分にとってよい方向に）変わる」的な現世利益を持ち込むから、トンデモになってしまってるんじゃないかと思う。

自然科学に人間の意志が入り込む余地はない？のに対し、社会科学には人間の意志が入り込むから、好意的な接し方をしていれば好意的な反応が返ってくるはずだ、という意見もあるかもしれない。
でも、それは自分の境遇を左右できるようなレベルの人間に直接接することができている人だけに通用する言説だろう。
例えば多くのワーキングプアの人が頼っている派遣業界なんかでは、彼らの命運を握っているのは派遣先企業と派遣会社の人事部門の人達であり、直接彼らと接する派遣先の現場社員達には、彼らの命運を左右する何の権限もない。
実際、私が以前勤めていた会社でも、派遣の事務員を採っていたことがあったけど、すごく明朗快活で仕事のできる人で、私はもちろん、マネージャークラスの人も含め現場は全員もっと居て欲しい、ずっと仕事して欲しいと思っていたにも関わらず、派遣の期限が切れると普通に辞めさせられていった。
そんなふうに、直接彼らと接するわけでもないのに彼らの境遇を左右する人事の人達が、昨今では最初から使い捨てる気マンマンで、派遣契約期間を（それ以上派遣を受け入れれば正規雇用しなければならない）2年11ヶ月にしてくるような事が当たり前になってるような状況で、彼らに対し「自分が変われば社会も好転する」等と信じろと言うのは、「小石を地面にぶつけて地球の軌道を変えられる」と信じろと言うのと同じくらい、無茶な事のように思える。

もちろん、複雑系の世界の中では、北京で蝶が羽ばたけばニューヨークでストームが起きるという喩えもあるくらいなので、「自分が変わる」ことで何らかの変化は社会に与えられるかもしれない。
でも、それは意図的に制御できないからこそ複雑系なのであって、その変化の結果が自分に返ってくると考えるのはおかしい。
たとえば、Aさんが辛くてもいつも笑っている事によって、派遣契約満了後自殺しようかとまで思っていた同僚が、「Aさんの笑顔を思い出して勇気付けられて」もう少し頑張ってみようと思い直した、位の変化は社会に与えられるかもしれないが、その元同僚がひょんなことから出世して、命の恩人Aさんを引っ張り上げたというようなドラマみたいな出来事でも起きない限り、Aさん自身の境遇には何の変化もない。

だから、やっぱり「自分が変わることで、社会が（自分にとってよい方向に）変わる」という主張は、社会科学的にトンデモだと思う。

大元記事のような「まず自分が変わるよ」という人、それは素晴らしいことだと思うんだけど、 だったらそれは「そうする事に寄って周りも変わってくるから」というようなトンデモ現世利益な主張じゃなくて、「周りがどうあろうと、私に対して悪意を向けようと私はそうする、何故ならそれが素晴らしい事だと自分は信じるから」くらいの覚悟で主張して欲しい。
正直、その一線が、「自己責任教」カルトに陥らない、自己責任ではどうにもならない状況にいる人を苛立たせない、分水嶺じゃないかと思う。

蛇足ながら、冒頭紹介記事内の記述

サティーは遠い国の話です。しかし我々の社会にも、サティーは無いでしょうか。

この設問、私も年始くらいに考えてたこと。

例えば、ジオメディア業界では知らない人はいないと言われるここギコ！さん。ゴージャスカレー姉妹というblogを書いておりますと自己紹介すると、「アクセス数上げるために炎上させにいってあげるよ(笑)」これはRTCカンファレンス「ブログ限界論」でも出た、効率よくアクセス数を稼ぐ方法としてお決まりのジョーク。美しき友情から派生する、アクセスupのための悪意なき炎上を指す。

「うん、　炎上交際。　これ、今年の流行語大賞になるかもしれない」

...何やこれ。
炎上交際とか、寒いダジャレ俺が言い出したんちゃうっちゅうねん。
レポートブロガーとか言うとんのやったら、もっとちゃんとレポートせー。

...ダメっス、やっぱ俺じゃ芸なさ過ぎて、わざと炎上させるとかできまへん。
意図しない素の炎上なら、なんぼでも起こせるんですが...。

というわけで、華麗でゴージャスな出会いもあったジオメディア新年会に、1/11の金曜日行ってきました。
出会いと言えば、新年会の前にちょっと立ち寄ったシリウステクノロジーズさんのビルの前で、ザブングルの加藤とすれ違ったけど、それがどうしたって感じだったので即効忘れちゃってて当日は誰にも話さなかったな。

渋谷のカフェを借り切っての会場でしたが、50人近い参加ですごい大混雑状態。
ジオメディアに期待する参加者の人たちのすさまじい熱気が感じられる、というかマジで人だらけで熱気むんむん、関さんいくら何でも狭すぎるて!という状況。
そのおかげで個々の人とはかなり深くディスカッションできましたが、誰がどこに居るかよく判らず交流できた人数が少なかったのはちょっと残念だったところ。
基本「位置情報だけどGISじゃないよ」スタンスの、OSGeoでSchuyler言うところのNeogeographerの集まりだったわけですが、昔ながらのGISの方も集まって、呉越同舟（いや対立してないけど）の面白い場になってました。

▲ 人口密度高すぎ... ▲

いろいろ面白い出会いもありました。

• OSGeo設立カンファレンスのプレゼンネタにもさせてもらった、5-6年前I社さん（今は仲良し）に「地図を安うで使わせてもらえんじゃろうか」とお願いしたところ、「判りました、1ヶ月1000アクセスで2万円でどうでしょうか」と言われて貧乏サラリーマンが涙を呑んだことがあったのですが、その時当時大阪に居た私のところまで出向いてくださり話を聞いてくださった、I社営業の方と5-6年ぶりに再会しました。
  なんともまあ懐かしいアレで、まあ当時の話も今となったら笑い話ですよねーみたいな感じでお話させていただきました。
• 各銀行WebサイトのATM検索にクローラ走らせて経緯度取って、ケータイから最寄のATM検索サイト作っている人がいた！
  情報買わなきゃいけないので、まともにPOIの揃ってない某社の公式サービスATM検索よりよっぽど便利そう。
  訴えられるリスクが0ではないので、炊きつけはできないけど、もしよければ公開してくださいませませー。
  少なくとも、ATMのPOI情報はともかく、Googleのケータイサイト地図画像はほぼ黙認の状況っぽい。
  Google主催の座談会に出たゴーガの小山さんがそう言ってた（Googleの人「ケータイでの地図の利用法、どうやって知ったんですか？」小山さん「みんな知ってますよ」Googleの人「ああ、そうなんだ」的な）。
  しかし、PCサイトにクローラ走らせてPOI収集というのは、昔ここギコケータイ版でも吉野家やモスバーガーのPOIをクローラ走らせて収集＆ケータイで周辺検索やってたのを思い出して、懐かしいものがあるな。
• ゴージャスで華麗な出会いについては(ry

途中、ライトニングトークの時間もあって、doodleやGeoForm API、ついついTwitterなんかのプレゼンもあったようなのですが、如何せん会場に死角がたくさんあって、見るにはディスカッションを中断して死角にならないところに見に行かないといけなかったので、残念ながらほとんど見れませんでした。
でも、ロカポ上田さんのプレゼンは見に行きましたが、新仕様、「LocaPoint」以上に有益で使いでのある「LocaParam」が発表されて、会場からその驚くべき効能に「おおー」と感嘆の声が上がってました。
この仕様については私も知らなかった（正確には仕様を作っている事と基礎原理・仕様は知っていたけど、名称が決まった事と拡張仕様は知らなかった）ので、私にとっても驚きでした。
ここで紹介したいところですが、本家で近々公開されると思うので、ネット上ではそれまでおあずけということで。

以上、なかなか面白いイベントでした。
主催してくださった関さん、お疲れ様でした。
ぜひ、今後も「ジオメディアイベント」続けていければ嬉しいですね。

赤木智弘さんのブログより

テキストエディタは、何を使えばいいんだろう？ -深夜のシマネコBlog-

中間層が年収300万で、貧困層が年収100万のときに、貧困層は中間層の1/3の生活しかできませんが、中間層が年収100万に落ちれば、結局、経済体制というのはマジョリティーに合わせて「普通」の生活を形作るわけですから、貧困層はなにをせずとも普通の暮らしができることになります。つまり、貧困は必ず相対的水準なのです。

分かりやすく、考え方を示します。
まず、いまのままが継続すること。つまり、中間層が300万円をもらい続ける未来をAとします。　
次に、左派が夢見るような、富裕層から取り上げて、中間層と貧困層がいままでよりも裕福になる未来。中間層が500万で、貧困層が300万。これをBとします。　
そして、中間層が貧困層に分け与えて、元中間層と元貧困層が250万（200万の間違い？）ずつもらうような未来をCとします。　
最後に、中間層を引きずり下ろし、貧困層と同じような、もしくはそれ以下の賃金になる未来。元中間層と元貧困層が80万ずつもらうような未来をDとします。

なんで、

富裕層から少しだけ取り上げて、貧困層をかさ上げして中間層と等しくする未来E。中間層も元貧困層も300万。

が抜けているんだろう。

層の厚さの問題もあるので単純ではないけど、個人レベルの収入増減額を層全体の収入増減と考えて表にしてみると、

で、当然理想は中間層/貧困層の格差0のモデルなので、C、D、Eのいずれか、でもその実現のためには中間層と貧困層の共闘が必要不可欠だとなると、どう考えても理想のモデルはCではなくEだと思うんだけどなあ。
現状維持ならともかく損害が出る層を共闘させようという時点で、赤木さんが「左派の夢見る」と書かれているBと比べてさえ、Cは現実味のない夢物語かなと思うんだけど。
まだEなら、意識の高い連中が動き出せば、十分可能性はあるように思う。
中間層に利益なしと言っても、昨今の流動性の高い（主にした方面に、だけど）社会では何時貧困層に転落するか判らないのだし、その未来の自分の可能性を支援していると考えれば、十分に共闘可能性はある。
（それに実際問題、今の中間層は原罪的なもんを背負っているわけだし、利益がなくても共闘すべきだろう。）
また、富裕層にとっても、富裕層に損害をもたらすモデル間で比較すれば、Bに比べれば損害が小さいという事で、比較的ではあるが受け入れ易いんじゃないかと思うのだけど。

もちろん、そうやって共闘してみた結果、富裕層だって思ったよりキチキチでそれほど吐き出せないよね、その状況で中間層・貧困層間の格差を是正しようと思えば中間層から削るしかないよね、という経路を辿った結果、結果的に中間層も損害あるよ、なら納得なんだけれども。
やれ不法で高ピンハネ率の派遣ビジネスや貧困ビジネスで、富裕層が貧困層から搾り取っている構図が是正されないままに、中間層から貧困層への分配が先、とか言われてもそれはちょっと違うんじゃないの？と思う。
それこそ、そこを新たな搾取の種として、付け入られるだけだと思う。

ネットカフェ難民：都が支援　無利子で最大６０万円

住居がなく、インターネットカフェや漫画喫茶などに寝泊まりする、いわゆる「ネットカフェ難民」を対象に、東京都は０８年度、賃貸住宅の入居費用などを無利子で貸し付ける支援に乗り出す。全国の約４割を占める都内のネットカフェ難民に安定した生活を促すのが目的で、自治体としては初の試み。
　.........
都の支援策は、正規雇用先を見つけるなど安定的な生活が見込める人を対象に、賃貸住宅の入居費用や当面の生活資金として、最大６０万円を無利子で貸し付ける。また、専用の相談窓口を設け、社会福祉法人などに委託して生活相談や住居探しを手助けする。

おー。
プレカリアートの人達は賃貸住宅に入れないのも正規雇用につけないのも、入居時の敷金礼金や正規入社時の初任給までの生活費等、当面のお金が工面できないために抜け出せない場合が多いそうなので、これは一定の支援になるんだろうか。
まあ、何らかの対策をしようという動きが出るのはまあいい事かなと思う。

でも、記事だけじゃイマイチ温度が判らないんだけど、「正規雇用先を見つけるなど安定的な生活が見込める人を対象に」って順序が後先なんじゃないの？
目先の金がなくてその日払いの仕事しか選べない人が、支援受けられるかどうかも判らないのに、先にその日払いじゃない正規雇用になんかつけるんだろうか。
もし審査に通らなかったら、干上がってまうやん。

というか記事の中で都自身が

都は「住居がないため正規雇用に至らない悪循環に陥っている人が多い。問題を放置すれば、路上生活をせざるを得ない人が増える」と、早期自立の必要性を説明する。

っつって住居が先、と認識してるのに、変な話。

というか、もしかしたら記事が誤報で、支援が先で生活建て直しが後だったとしても、そもそもこの高齢フリーター就職難の時期に、60万円で生活できる間に正規雇用なんか見つかるんだろうか。
もし見つからなかったら、無利子とは言え負債を新たに抱えた上で、支援しても抜け出せないなんてやっぱり自己責任やんけ、みたいな風潮になってしまうだけのような気も。
そんな事より、普通に生活保護制度使えば当面の賃貸入居のための費用や生活費なんかも出るのだから、生活保護制度の正しい知識の周知徹底に誘導した方がいいような気もするんだけど...。

あなたにもできる!本当に困った人のための生活保護申請マニュアル (DO BOOKS) posted with amazlet on 08.01.09 湯浅 誠 同文舘出版 (2005/08) 売り上げランキング: 10425 おすすめ度の平均: 生活保護受給には覚悟が必要 この本を必要としない社会（福祉）の仕組みが必要だと 大変参考になりました Amazon.co.jp で詳細を見る

ケータイゲームの市場調査とかやってた時に登録して以来、コーエーのケータイ向けマルチプレイシミュレーション「信長の野望」「三国志2」にハマっているのですが。
どちらも、1日に配下の武将の数だけコマンドが打てて（武将数は最大8人なので最大8コマンド）、翌日にその結果が出ての繰り返しで20-40日くらいで1シナリオが終わる、という超スローゲームです。
半年近くやって本日、初めて三国志2の「反董卓連合」シナリオで「シナリオ制覇（他のプレイヤー、NPCを全て倒して全都市を占領すること）」達成しました！
超うれしー。

▲ 全て我が国の支配下となった反董卓連合のマップ ▲

▲ 戦績 ▲

▲ポイント・冠位他▲

制覇したといっても、正々堂々というよりはすげえチートな方法でだけど。
シナリオ始まってすぐ、別に何の気もなく、NPC君主5家（袁紹、袁術、曹操、孫堅、陶謙）にいっぺんに同盟の使者出したら、あろうことか全部同盟承諾に。
このゲーム、1回の戦争に投入できる兵力に制限があって、同盟していない1家だと50万人しか派兵できないのだけど、同盟国が援軍を出してくれれば50万人以上の兵力を投入できる。
5国と同盟しててかつ全同盟国が援軍派遣してくれたら（ちなみに、NPC国はほぼ100%援軍くれるし、裏切る事もほとんどない）、300万人で攻め込めるので、同盟していない国を滅ぼすのなど一瞬状態。
シナリオ中盤までにあっという間に他のプレイヤー＆非同盟NPCを屠った後、ゆっくりと1国ずつ同盟破棄しながら潰していって、40日近くかかって昨日、全国制覇できた。
と言っても余裕はなく、関羽・張遼・太史慈擁する陶謙との最後の戦いに手間取って、制覇成立したのはシナリオ最終日というギリギリ状態だったけど。
ちなみに、うちの最終武将陣は孫堅、郭嘉、荀攸、趙雲、馬超、華雄、黄忠、許チョでした。

しかし、シナリオ制覇しても、ポイントは599点。
ランキングだと600位かそこらでしかない。
ランキングに載る様な人だと、1000ポイントとか余裕で稼いでるんだけど...後何をすればそんなにポイント稼げるんやろ？

もしかしたら常識かもだけど、知らなかった。
正確には、環境によっては動く場合もあるようだけど、推奨はされないし、動かない環境ではデータベースを開くことすらできなくなる。
情報としてはこの辺。

今動かしてるサービスをSolaris上のSQLiteで組んでるんだけど、DBはNFS上に置いてても普通に動いてた。
で、SolarisをLinuxにリプレースすることになったので、LinuxからNFS上のSQLiteファイルアクセスしてみたら、データベースが全く開けない。
いろいろ調べてみると、別にDBD::SQLiteのインストールに失敗したというわけではなさそうで、ローカルディスク上のSQLiteファイルならいくらでもアクセスできる。
なもんでNFS上に置いてるのが原因かと思って調べてみたら、案の定だった。

これで現行サービスの、Linuxリプレースは無理になった...現行の範囲では全然問題ないのだけど、次期サービスは流石にSQLiteじゃなくちゃんとMySQLなり使いたい。
で、Solaris上でMySQL動かそうとすると、クライアント周りにバグがあるみたいで、うまくDBD::mysqlのテストが通らない。
パッチも報告されてるんだけど、適用してもうまくいかない。
それで、次期サービスのMySQLのためにLinuxにリプレースして、サーバの台数も余裕ないので現行と次期を同じサーバで動かそうと思ってたんだけど...。
現行のNFS上SQLiteはLinuxで動かないし、次期のMySQLはSolaris上で動かない。

こりゃ、現行と次期サーバ分けるしかありまへんな。
うううう、予算が...。

CPANやオープンソース開発に関する自縄自縛の思い込みが解けたので、内輪で作ってたHTTP::MobileAgentのプラグイン3つ、CPANに上げました。

• HTTP::MobileAgent::Plugin::XHTML

各端末がXHTML対応か否かを確認するプラグインです。
次のHTTP::MobileAgent::Plugin::IDでの判定に、XHTML対応機種か否かの判定が必要だったので作りました。

XHTML判定自体は本家にあるのですが、未知の機種の場合にXHTML非対応になってしまうのが気に入らなかったので、プラグインとして追加しました。

• HTTP::MobileAgent::Plugin::ID

各端末からのユーザID（取得できないものは端末シリアルID）を取得するためのプラグインです。

HTTP::MobileUserIDと似ていますが微妙に欲しかったユースケースと違うので作りました。

• HTTP::MobileAgent::Plugin::Location

ケータイ位置情報を扱うためのプラグインです。
codereposのHTTP::MobileAgent::Plugin::Locatorと似たようなのですが、

こちらでできないこと：

• 位置情報取得時のクエリストリングの持ち回り（各端末の仕様に基づいた持ち回り数しか持ちまわれません。EZWeb：0、DoCoMo iエリア：2）
• mova iエリアからの経緯度取得（エリアメソッドと経緯度メソッドを分けたので、エリアしか返さないI/Fではエリアしか取れません。経緯度を返さない仕様で経緯度を生成するのは止めました）

こちらでできること：

• 経緯度オブジェクトとしてGeo::Coordinates::Converter、Location::GeoToolの双方が利用可能
• 利用する位置情報の精度を変更可能（GPS対応機でも簡易位置情報やiエリア利用可能）
• 位置情報の精度取得可能（基地局精度、混合測位、GPSの3段階）
• 経緯度からiエリアの生成可能

あたりに差があります。

ただ今Yappoさんにcodereposのアカウント申請中ですので、それが終わればcodereposにも上げますのでツッコミよろしくお願いします。

年末、ケータイ位置情報クイズSNS「xair」とかいうの見つけたんですが、これが中々面白い。

基本は「