ほんとうは、ねねは
製品何となくと作品何となく-404BlogNotFound-.
とか思ってたらしいの。

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

というわけで今読んでるのはこれ。

光武帝(上) posted with amazlet on 06.07.29 ?本 ?史 講談社 (2006/06/15) Amazon.co.jp で詳細を見る

春秋戦国から楚漢戦争、漢匈奴戦争、新あたりまではそれなりに知ってるつもりなのだが、意外に東漢の頃の歴史には疎いので買ってみた。
塚本作品は霍去病、霍光、張騫あたりの西漢期の作品中心に読んでたのだが、わりと好きだ。

高校の頃は文学部に行って歴史学を専攻したかったんだよな。
銀英伝のヤン・ウェンリーに感化されて、と言えばちょっと恥ずかしいが。
「手に職を付けてくれ」と親に懇願されて、工学部に入ったが（というか、高専出だったためか「大学＝職能を身につけるところ」という勘違い？をしていた親が悲しい）。
というか、つい最近、2001年のauのGPSケータイ発売にビビッときて、2002年にここギコを始めるまでは、別にGeekの道なんて目指してなくて、フツーに仕事して、いつか歴史小説書くんだとか真顔で言ってて、実際短編はいくつか書いて同人誌出したりもしてて、本を買うと言えば歴史書か歴史小説か、って奴だったんだよな。

なんかこの3、4年間、熱に当てられたみたいに技術技術して、買う本もオライリーとかそんなんばっかりになって、歴史のコーナーに行っても別に何も読みたいと思わなくなってたけど。

この２週間くらいちょっといろいろあって、なんかいろんな意味で信じてたもんに幻滅したというか、どうでもよくなってきたというか、あんまし技術とかGeekとかWeb2.0とかどうでもいいわーという気分になってる。
そういうことに幻滅する自分自身にも幻滅しているというのも少しある。
一時的なもんかもしれんけど。
そのせいかどうか判らないけど、懐古趣味というか原点回帰というか、歴史なんかにまた最近興味が沸いてきてる。

今の仕事でさー、やれ創業者の名前だの言葉だの精神だの、今の社長は何代目だの、会社の精神だのビジネスにとってはどうでもええこと覚えて出世して、技術者といいつつ本当の意味での技術とは無縁のぬるい会社人生を送るのは愚にもつかないと思ってたんだけど。
それならばGeekとかWeb2.0とか追い続ければ幸せなのか、というと、何となくそっち方面の、別の意味での愚にもつかなさが最近何となく匂ってくるような感じがして、正直最近ちょっと萎えている。
自分がその手の方向性で大成するイメージがわかなくなってきてるし、いやもし万一？大成したとしても、その時俺は幸せか？と聞かれるとよく判らないなーという気がしてきてる。
少なくとも何となくその手の方向性からは嫌われてる（いや、特定の個人とかコミュニティとかじゃなくて、運命の女神とかそんなアレね。機会的に恵まれないと。）みたいだし、それならそれで、理想の自分を今の自分に軌道修正して、やれ日々の時間を技術革新に追われるようでもなくとことんぬるーくぬるく生きながら、好きな歴史や伝統芸能なんかに時間を費やしたり、家族との触れ合いをもっと楽しんだり、そういう人生も悪くないかなと思い始めてる。
こっちの世界はこっちの世界で、それなりに大きなコミュニティなのだし。

ちょっとした一時的？なアパシー状態と言うかね。
といってもうつうつとしたそれではなく、最近の自分を捨てて元々の自分を取り戻そうとしてるような、そんな感じ。
別に本当にそういう心理なのかは自分でもよく判らないけど。
少なくとも、ちょっと前までは、本屋の歴史書コーナーに行っても読みたいと思わないと言うか、こんなもん買うのに金を使うくらいなら技術書もっと買って勉強しなきゃと思ってたのが、最近本屋に言ってみると歴史書や歴史小説が自分を呼んでいるような感覚を感じる。
それで自分の心理分析をやってみたところ、こんな感じなのかなと。

でも、そんな生活に戻るんなら、関西に帰りてーなー。
親の勝手な都合で息子のせっかくできてきた社会生活をぶった切るのはよくないと思うので、実際には帰らないと思うけど。

NECマグナスコミュニケーションズと米GeoVectorが共同開発した位置／方位による情報検索基盤に、ネットディメンションの3Dコンテンツ表示技術、キャドセンターの3D都市データ構築技術、アジア航測の地図情報システム（GIS）技術、旭化成マイクロシステムの電子コンパス技術を組み合わせた。またサイバーマップ・ジャパンがコンテンツ／サービス面で協力した。

GeoVectorキター。

しかし、協力会社も百花繚乱で、「コンテンツ/サービス面で協力」等具体的なアプリケーションまで完成していることを想像させる割には、イマイチソリューションとしてどこまで何ができてるのかよく判らない記事ですな。
NEC端末で、GPS・電子コンパスが装備されているような機種はないはずだし（NECはDoCoMo端末しか作ってないし、DoCoMoはGPS端末と言えばSANYOしかないはず。これには電子コンパスは付いてるんだっけ？）。
特にNEC子会社とかいうことにはこだわらず、auなんかのGPS・電子コンパスを持つ機種とかで作ったのかな。
或いは、電子コンパス技術に旭化成MSが協力、等と書かれているので、電子コンパスは外付けデバイスとして準備したのか（それにしてもGPSだけの機種もNECにはないので、SANYOのDoCoMo-GPS機種を使ったのかな？）。

もうちょっと詳細情報が欲しい、気になる記事です。

今日鉄腕DASH！見ていたら、風呂を作るとやらで鉄砲釜を鋳物で作っていました。
今時、鋳物を作る光景を見る事なんてそうそうないので、思わず見入ってしまいました。

超懐かしい。鋳物って私の社会人労働生活の原点なんですよね。
別に鋳物師として就職したわけじゃないんだけど、元が鋳物工場から発展した金属・機械メーカに就職したので、入社早々の4ヶ月間の研修期間って、私鋳物工場で働いていたんですよ。
私が働いていた職場で作っていた鋳物は、製紙圧延用ロールと言って、紙を作る製紙工場で紙を圧延するために使う巨大な円筒形物質（色々だけど、直径1mから数m、長さは10mから20mくらいで、重さは確実に2桁t単位の円筒形の鋳鉄の塊）を鋳物で作ってた。
だから鋳型もDASH村鉄砲釜のようなこじんまりしたもんじゃなくて、どでかい鋳型なんだけど、作り方の発想の基本は変わらない。

夏には50度を超える粉塵まみれの職場でも、1200度の火の粉が飛び交うので長袖長ズボン作業着・耐熱手袋長靴・ヘルメットゴーグル着用の全身重装備での肉体労働。
意識がとんで足を踏み外しでもすれば、一瞬で気化出来る煮えたぎる電磁溶鉱炉のふちで、浮かび上がってきた不純物を鉄の引っかき棒で掻き出す作業。
のそのそやってると、引っかき棒そのものが溶け出す。
自分の体よりはるかに大きい鋳型を、全身を使って押し固め、形を整える作業。
現場作業員の人が3、4個正確に作る間に、自分は1個しか作れず、しかもそれで全身ガクガク。
いろんな工程をローテーションしたけど、焼入れ・焼きなまし工程は、電気炉に大型クレーンでまだ熱いロールを入れたり出したりする時の作業以外は、クーラーの効いた電気炉の温度変化を監視してるだけだったので、比較的楽だったなあ。
大変だったけど、普通はこんな体験できないので、今考えるとすごいよい体験をしたなと思う。

当時から赤字続きで来年には、再来年には事業停止になると言われていた部門だったんだけど、Webサイトに製品がまだ載っているということは、まだやってるんだな...嬉しいな。
当時から社内の研究所なんかと協力して、低コスト化や高品質化のための技術革新とかをいろいろやってたから、そういうのが功を奏してるのかもしれないな。
職場の赤鬼軍曹と呼ばれていた定年間近の主幹さんから、退社後雀荘に行って四暗刻あがったりしたのも思い出す。
一緒に研修した仲のよかった文系の同期は、結局その部門の勤労管理職に就いてたな。
まだみんな元気にやってるんだろうか。

そういえば、その主幹さんって、言うまでもなく頂点の地位とはいえブルーカラーなんだけど（「主幹」はブルーカラーの最高位）、社長（一部上場企業の社長ですよ）としょっちゅうゴルフに行ったりとか、飲んだりとかしてて、社長の事も君づけで呼んだりしてた。
要するに、社長と言えども現場の最高責任者には頭が上がらない...とまではいかなくても、少なくとも一目おいているということだ。
別に驚くには値せず、本来は当然のことのはず。
彼らが汗水たらして働いて、製品を、よい製品を作ってこそ、会社が信頼され品物が売れ、会社の売り上げ・利益が伸びるのだから。
その事を思い出して、そういう当たり前の視点が、今のSE・PG業界とかでは欠けてるのかなという事を感じました。
古臭い？重厚長大日本の伝統謹製の企業とかですが、現場を大事にするとかそういう良き伝統は、引き継いでいくべきではないのか、と思いますた。

「即日解雇みたいな違法な核兵器」って、黒社会から嫌がらせでもされていたの？ -void GraphicWizardsLair( void ); //-

まさか「すべての経営者はEvilであってはいけないのだ」というユートピア幻想だったりはしないでしょう？　
たいていの人は「経営者にはEvilな奴が居る」ということを織り込み済みで「やばい会社に入らないようにする方法」に知恵を使ったりしていますよね。

ということであれば、Evilな会社を体験したら、その情報を公開してみんなで共有するのは公益にかなうのではないか、とか言ってみるテスト。
さあ、みんなで酷かった会社にはてなブックマーク！とか何とかｗｗ

あまり露骨にやると営業妨害で訴えられたりするでしょうけどね。
Evilな経営者って、そういう点でも取ってくる手段がアレですから。

あと、未返答事項の拾遺。

「即日解雇みたいな違法な核兵器」というのが無知なので本気でよく分かりません。

えっと、とりあえずEvilな経営陣に対抗するにしたって、まずは辞めるとか、クーデターおこすとかの最終手段じゃなくて、まずは組織内改革で経営陣に頼らない独立独歩体制を作って対抗しようとか、そういう順序でいくじゃないっすか。
そういう際に、やっぱ組織で、違う能力を持ったものが集まってるのだから、自分ひとりで食べていける状況を作ろう、とかじゃなくて（それなら本当に即辞めればよいのだし）、各人の特性を活かしたビジネススキーム造りとか、また技術陣内だけでも技術ノウハウの伝授を行ってシステムを分業メンテナンスできる体制作りとか、そういうのを作ろうとしますよね。
そういうのを作るのだって、時間をかけて、時には何ヶ月もかけて下準備してきてやっと体制を整えますよね。
その時に、突然予想もしてなかった違法な（違法ですよね？）即日解雇とかでその思惑を突如崩される、というような手段まで取られると、もうこっちとしても、反則アリというのであれば他にもどんな予想もしてないような事されるか判らないし、打つ手がなくなってしまうわけですよ（辞めたり、クーデターとか以外は）。

その意味で、違法行為までアリと言うのでは、取ってこられる手段も無限にまで広がってこっちも対抗手段の取りようがなくなるので、いくらEvilであろうがルール内でルール外のことをするのは究極兵器過ぎて駄目だろうよ、という意味で、ルール外手段を総称して「核兵器」と表現したものです。

「解雇通知は何日前に」「労働者の権利が」みたいな左側な発想で、才能ひとつでどこでも食っていける知的技術者が「核兵器」とは表現しないだろうしなぁ。

というのは、上記したとおり、自分への適用だけでなく同僚への適用で組織としての経営陣への対抗策が崩される事も視野に入れての表現をしているので、当たらないと思います。

「肋骨にひびはいって入院したら、経営者がボールペン1本の持ち帰りを横領だと微罪で難癖つけてきて解雇した」みたいな良く有るEvilな裏技のことかなぁ

というふうな事がEvilな経営者が取ってくるよくある行為なのだ、ということは知識がなく、実体験で初めて知りました。
その点では勉強不足で、対応策の考慮不足でしたね。
でも、うちのケースの場合は、微罪で難癖もなにもなく、経営陣が辞めさせたいから辞めさせる、だったと思いますが。

ただ単純に「俺は出るところに出ればもっとブレイクするんだ。チヤホヤされるべきなんだ」「悪いのは周りの環境なんだ」と思い込みたくて、それをblogにおいて過去のEvilな経営者や現状を愚痴ることでストレス解消しているとしたら、おれのコメントや言及などはめちゃくちゃ大きなお世話でした。

えー、確かに自分が辞める直前や同僚が辞めた直後は、怒りに我を忘れ特に必然性がない、自分の怒り発散のためだけのエントリを書いたりもしましたが、基本的に最近のエントリ（これとか、これとか）では、別話題からの流れで、論じている事の実体験を元にしたサンプルを提示するために書いているだけで、それを書くことだけを目的にはしていないっすよ。
まあ、書いている時にむちゃくちゃカタルシスを感じていることは認めますが。エクスタシーっすよ。

このカルチャーギャップに気付くのにこんなに時間がかかったということは、知らない間に俺もギークから根っからゼネコンSI屋に落ちぶれてしまったということか。

ここギコ！: 残業は日本人の文化？DNA？へのライブドアクリップ

仕事を時間ベースでしかとらえられていない時点で旧来の日本文化にどっぷり。

成果、という視点が抜け落ちてるということなんだろうな。
というか、それは旧来の日本文化が云々というより、業種の違いの問題だろう。

nipotanなんかのインターネットサービスなんかの仕事では、ゴールは自分で設定できる、というかゴールなんかないんだろうな。
だから、どれだけのパフォーマンスで何時間仕事した、とかそういうのではなくて、何を成し遂げたか、ということを後で査定されてそれにあわせて報酬を定める、という形の発想なんだと思う。

でも、今の俺みたいな巨大プロジェクトの大手ゼネコンSIだと、全体のゴールは既に決まっていて、そこに至るまでには基本的に新しい技術的冒険なんかもないし、やるべきことや調整すべき事なんかの総量は決まっていて、それをいかにどれだけのパフォーマンスで処理していくか、という基本的にはそれだけの問題でしかない。
だから、少なくともそういう業種ならば、基本的に個々人のパフォーマンス×時間で為した仕事の価値は決まるだろうと、そういう事を言ってるだけ。

例をいうなら、今回のプロジェクトで、UI上で地図をスクロールさせる機能を実現させるのにある他社製プラットフォームを導入することが客先との調整で決定しているんだけど、そのプラットフォームの地図操作感がショボ過ぎて、隣の席の新入社員が「Google Mapsの方がよっぽどいいですよねー」とか言っていたりしている。
そこで例えば俺が頑張って、「よっしゃ、Google Mapsに負けない操作感のUI作ってやるよ」と言って、もし仮に1日でGoogle Mapsを超えるレベルのUI作り上げたりしても、それがいかにすごい出来であってもシステムに採用される事は120%あり得ないし、確実に「そんなもん作って遊んでいる暇があったら早く顧客との未決事項調整のための仕事をしろ」と、どやされるだろう。

そういう業種では、基本的に全体の登るべき山の総量に対してどれだけのゲインを稼いだかで報酬が決まるべきはずだが、残念ながらコーディングのフェイズとかならまだしも（といっても俺はコーディングさせてもらえないだろうけど）、顧客調整とかのフェーズでは、どれだけのゲインを稼いだかと言うのを性格に見積もるのは、後からでも難しい。
たとえば、今回のプロジェクトの例でいうなら、

• 「○○業務で使う端末のディスプレイはどうしますか？」「うーん、○○GAの液晶モニタがよいな」でディスプレイの仕様を決定した。

というのと、

• ディスプレイ上で画像データを3次元立体視するという要件があるのだけど、既存技術の液晶シャッタメガネを用いた立体視方式だと、液晶モニタではリフレッシュレートが低すぎてチラついて立体に見えない。
  かといってCRTモニタは、今後どこのメーカでも生産停止になるので、システムのサービスイン後から稼動期間分のサポートをメーカが保証してくれる製品がないため、選択不可。
  散々いろんな方式を客先にデモまでしたりして数ヶ月かけて折衝した挙句、現タイミングでは業務での使用に耐える立体視方式を発見する事ができず、現行システムで使われている機材（CRT）をサポートできる期間いっぱいまでオーバーレンタルしてもらい、サポートが切れる数年後に、その時点で出てきていると期待されるであろう新方式の立体視技術を再検討し別途調達する、という形で客先合意が取れ落ち着いた。

というのを、両方とも1仕様決定＝1ゲインとみなされたのではたまったもんではない。
勢い、普段これだけのパフォーマンスを出す奴が解決にこれだけかかったのだから、というのをゲインの指標と見るのが一番合理的になる。
で、俺は別にあらゆる業種に通用する真理を語ろうとは思ってないし、飽くまで自分の生活体験から自分のテリトリーのことについて語っているだけなので、こういう話になる。

別にこれが、nipotanの業種でも同様に成り立つとは思ってない。
どんな業種でもその業種に最適のやり方があるのだろうから、それを選択すればいんじゃないの？と思う。

プロ奴隷の定番の言葉キター > 悪いのは俺じゃなくて、経営者連中だし。

えーん、otsuneネ申にDISられちゃったー（涙）

いやでもマジ奴隷みたいなもんでしたよあの頃は。
経営陣からは「奴隷」じゃなくて「駒」と呼ばれてましたが、一山いくらの。

奴隷は奴隷なりに反抗の狼煙はあげたんですけどねー。
もうあの経営陣に任せてたのでは、座して死を待つしかない！ってんで、技術・企画担当の私、文筆・編集担当の女性社員、特許・営業担当の男性社員の3人で経営陣から独立したビジネスユニット作ろうとして、3人それぞれでできるスキルや会社の持つ特許等の資産の棚卸し、ブレインストーミングを重ねて、やっと成り立ちそうなビジネススキーマ作り上げて、よっしゃやろうぜ！と立ち上がりかけたら、スキーマのキーマンだった特許・営業担当がサクッと解雇されて潰されたり。
4000時間労働の同僚（以下R氏）も、俺が辞めた後だけど、これじゃ駄目だというので大株主と取締役の1人を巻き込んで経営陣退陣・刷新のクーデターを起こそうとしたけど、取り込んだ取締役に裏切られて失敗してたなあ。

もう何というか、絶対王権ばりの経営権前面に押し立ててくる、それだけならまだしも、即日解雇みたいな違法な核兵器ばりの技まで使ってくるので、はっきりいってもう勝ち目がないんですよ。
（これも俺が辞めた後だけど、その後入った2人の技術者、2人ともR氏の子飼いになったんだけど、同僚の指示にしか従わず経営陣のいう事聞かない＆正社員は金がかかる、契約社員に置き換えたい、という理由で、R氏が階段で転んで肋骨を折って、1日会社を休んで病院に行ったその隙に、即日解雇された、って言ってたなあ）

唯一できる彼らへの最後の抵抗は、みんな、辞めるという選択肢しかなかった。
だから、まだ設立されて5年しか経っていない技術を売るはずの会社であるにも関わらず、過去に少なくとも2回、技術者が誰もいなくなって技術が断絶する、という事態が発生している（1回は俺とR氏が入る前、1回は俺とR氏が辞めた後。その後は知らん。もしかしたら3回、4回と記録を更新してるかもしれん）。
あ、技術者誰もいなくなったというのは言い過ぎか。
取締役にしてCTH（Chief Techinical 批評だけする人）或いはCTA(Chief Technical 余った研究費回して毎年10万円ほどだけ会社に貢献してくれる人)の大学きょーじゅがいるからなあ。

等とまあ、俺の立場からだけの一面的なことばっかり書き募っていてもアレなので、別の人の視点、R氏の視点からの文章も紹介したいと思います。
今はなきR氏の韓国語ブログの最後の記事を、私が思い出に取っておいたやつ。
ライブドア翻訳で、何とかギリギリ読める文章になってるので、是非読んでみて欲しい（特にotsuneネ申）。
読んで、私やR氏が前の会社でどのように行動していれば、奴隷にならずotsuneさんのようなモヒカン自由人になれていたのか、福音を残して欲しい。
おながいします。

仕事を時間ベースでしかとらえられていない時点で旧来の日本文化にどっぷり。

うーん、俺は時間ベースでいいと思いますよ。
何故かって、報酬＝時間×単価だから。
個々人のパフォーマンス差は、単価の方で面倒みればいいじゃん。
時給いくらのパフォーマンス持っている人間が、何時間働いたから報酬いくら。
よっぽど単純明快で判りやすいと思うけれど。
もちろん、残業だけでなく、減らす方向も含めてね。
金なんていらねーから、今はしばらくヒマにさせて欲しいって時もあるわけだし。

私が年棒制といえばいいのか裁量労働制といえばいいのか、それを忌避する傾向があるのは、ある意味極限の地獄ケースを目にしてるから。
裁量労働でいくら働かせようが給与一定なのをいい事に、年間4000時間×2.5年働かされた同僚を以前持ってましたからね。
しかも、四半期毎に見直しと規定されていたはずの報酬見直しも、全く無視されて同じ額のままだったんで、入社時の契約が俺の方が上だったから、俺より少しですが低い年収で、それだけ働かされていましたからね。
今の俺の年収と比較したら、3分の2くらいの額でそれだけ働いてたんじゃないすか。

そんなケースで同僚のお前は何をしていたんだ！と言われそうですが、彼とは担当する部門が異なっており俺は俺で別の仕事があったから。
会社に泊まりこんで家に帰るのは月1回程度だった彼とは比較になりませんが、俺も普通の会社で言うならかなりきつい方の生活してましたし。
俺は、なんとか家族や健康、財産、その辺を崩壊させないギリギリのところで調整していた。
彼は実際に、家族も、健康も、財産も、開発成果も、そして外国人だったこともあり日本での生活基盤も、最終的には全部崩壊した。
彼とは今でも親友ですが、悪いけど彼に限界までコミットしていたら、俺も巻き添えで何かを崩壊させてた。
それはさすがに選択できなかった。
悪いのは俺じゃなくて、経営者連中だし。

そういうケースを知ってるから、時間では計れない価値があるから年棒、裁量労働制という考えにはすごく抵抗がある。
もちろん、裁量労働制でもちゃんと適切に報酬の見直し等運用されてれば問題ないんだろうし、時間制でもパフォーマンスにあわせた単価考慮が適正に評価されなければ意味ないのかも知れないけど、
少なくとも俺が知ってるケースのようなむちゃくちゃな経営陣に対し、裁量労働制では一切の抵抗手段がないけど、少なくとも時間制であれば、単価はパフォーマンスに見合ってなくとも青天井にすることで経営陣に抵抗姿勢を示す事ができるので、まだマシかなと思うのです。
（報酬一定だと思ってれば4000時間働かせようが何も問題に思わない経営陣でも、4000時間分の給料払わないとならないとなったら、何か考えるでしょ？）

なぜなら、労働時間、いや、コードに触れる時間を制限してしまうというのは、責任感あるすぐれたエンジニアであればあるほどむしろ辛いものだからだ。

「あと５分あれば、このバグを潰せる」といった時に、「本日の就業時間は終わりました」と言われて退社しても、次の出社時間まで、そのバグのことで頭がいっぱいで休めない。
エンジニアというのはそういう生き物だ。
また、その五分を惜しまず「明日やればいいや」というタイプのエンジニアというのは伸びない。
優れたエンジニアは、皆「無理」の効用を知っている。

うーん、なんかちょっとズレてる気がする。

そもそも、5分とか残業ではつけられないし（つけられるとこもあるのかもしれないけど）。
少なくともうちでは最低でも30分単位だし、（実際に休んだかどうかは別として）定時後直後及び一定時間毎に強制的に「休憩時間が含まれたこと」にされてしまうので、例えば最低単位の30分の残業をつけようと思えば、休憩みなし時間を含め定時後45分間会社にいないといけない。
つまり40分残っていても、それは残業なしとみなされるのだ（まあ、厳密運用すれば、なので、実際の現場では個々人の裁量が入るが。タイムカードとかで厳密管理してなくて自己申告制だし。）。

まあそれはささいな問題で、弾さんの元記事を「あと45分あれば、このバグ(ry」と読み取れば済む話なんだけど、弾さんの話にはもっと根本的なズレがあって、弾さんの書いているノリでの残業は、明日やる分を今日やる、的なレベルの話だから、今日残業する代わりに明日の仕事量は減って、定時に帰れるはずだ。
でも今のIT業界の残業問題の問題点はそういう話じゃなくて、残業する/させることを最前提におかなければうまく回せないようなマネジメントになっていることなのではないかと思う。

しかし、残業残業！で力技でやるっつうのは、日本人のDNAに刻まれた文化なのかね。
この点では、旧態然とした業種でも、新興のITベンチャーでも、あんまり差はないような気がする。
違うのは、でっけえ会社は朝の時間とかきちっとしてるのに対し、ベンチャーとかだと昼前に来るとかが許される？くらいなもんで、夜は遅くまで突貫突貫！というのはあまり変わらない気がする。
WEB+DB PRESS Vol.33の宮川さんの記事でも、日本のベンチャー（要するに宮川さんが前いたとこだからライブドアだな）のそういう時間配分での仕事ぶりが書かれてる。

でも、日本の他の国では、そんなふうではなさそう。
少なくとも、私は中国の中堅SI企業や、アメリカの超大手電機企業、ヨーロッパのストレージ企業等とお付き合いした事があるが、国や企業の規模の差にあまり関係なく、皆一様に「定時後は基本的にみんな帰る」のが基本になってるみたい。
先述の宮川さん記事でも、今宮川さんが勤務されているアメリカのベンチャー（SixApart）では、ほとんど9時5時、みたいな話を書かれていた。
もちろん経営者とかは、国を問わず精力的に働くのだろうけど。

俺は残業はしないのがいい。DNAが日本人じゃないのかな。
もちろん必要な時はするよ。でも、必要じゃない時は残業しない、いやそれどころか勤務時間内でも用がなくなれば早く帰れるのがいい。
みなし残業を一定金額加味する裁量労働制だと、そういうふうに仕事がない時は帰ってもよいという制度もあるのだが（ただし建前上。病院に行くとかの理由以外で実際に定時時間中に仕事ないからあがります、みたいなことをするネ申をいまだ見た事がない。）、これはサービス残業の温床となってる制度なので俺は使ってない。
そうなると、残業代が付く代わりに、9時5時は拘束、という制度になる。
裁量労働と残業代制度の中間の制度ってないのかね...昨日2時間残ったら、今日2時間早く帰っていい、月トータルでオーバーした分は残業代がつく（当然足りない分は引かれる）、みたいな制度。
そういうのがあれば選択するのに。

サボったといっても、勤務時間中仕事しなかったっちゅうことじゃなく、言われたことしなかった、っちゅうだけだけど。

これまでやってきたプロジェクトのシステム構成設計が一段落ついて、残務はチームメイトを専任に充てることで何とかまわせる状況になったので、私は新しいテーマとしてシステムの脅威分析・対処設計に携わる事になった。
それはいいんだが、1週間後に客先会議あるからそれまでに資料まとめてねーって、何でいっつもそんなに話が急なのだ。
私、これまで構成ばっかりやってきたから、業務知らないんですけど...。

まあとりあえずどういう資料にしようか打ち合わせして、それに従い業務設計の各チームに超特急で調査・分析依頼のメール回して、3日目くらいに集まった回答を元に徹夜で資料まとめて、再度打ち合わせ。
するとどこのチームからの回答も、ハードウェア的な視点の分析しかなくて、ソフトウェア的な視点からの脅威分析が欠けていたので、そっちを重点的に再調査、資料修正追記との結論・指示が。

といっても、会議まで残り2日、今までの仕事の残務も完全に私抜きで動くわけでもないのでそっちにも手をとられるし、今から調査表回して再作成となると1週間の間に確実にまた徹夜、んなもんやっとられるかー、キックオフ会議なんだし限定した資料でええやんけー、とサクッと指示無視して再調査せずに会議に臨んだ。
当然上司には会議前にちょっと怒られたが、まあ言うても今さらどうしようもないので、できてる資料で会議に臨んだ。

そしたらいきなり、「こういう資料がみたかったんじゃないんだよね」ときた。
ハードウェア的脅威とか、ソフトウェア的脅威とか、そういうメーカ側の視点ではなくて、ユーザ側から見た、運用上生じるいろんな脅威をどう拾っていくか、という会議にしたいとの由。
とはいえキックオフ会議だったので特に怒らせたりということもなく、「次は頑張ってねー」のノリで、シャンシャン閉会。
20ページから作った資料も、数ページめくっただけで終わり。

どうせ何らかの資料がなければ会議の場には臨めなかったので、1日徹夜したのは全然OKなのだが、もし指示に従って2日徹夜して資料作ったにもかかわらず、こんな扱いだったならガクーッだっただろうなーと思うと、サボってよかったなと。
なんかこの辺の野生的カンというか、やっても無駄な事を直感的に嗅ぎ取る嗅覚というか引きの強さというか、そういうのはあるんだよなー。

MySQLデータベースのダンプファイルをzipアーカイブして、メールサーバに送る、わりとアリガチなスクリプトを必要に迫られて書いたのでついでに公開。

はげしく便利そうなのでお薦め運用そのままで使わせてもらってます。

というか、やっぱりバックアップって取る事自体より取った後どこにどうやって整理・保存するかが問題になるよな。
その意味でGmailはいい保存先ですよね。
私もそれ自体は思ってたんですけど、Gmail FSあたりをマウントして使うことばかりを考えてて、それがうまくいかなくてあきらめてたりしてたんですけど。
よく考えりゃ、確かに単にメール送るだけでよかったんですよね。どうせ、Gmail FS使っても裏でやってることは同じだし。

でも、単にZIP送るだけじゃなく、GSpaceの管理する形式に則って送るとか、できればさらに便利かも。
あと、DBのバックアップだけでなく、ファイル・フォルダのtgz化→バックアップとか、トータルに使えれば嬉しい。
...となると、Plaggerの出番なんすかね。

独り言。

消えてる...ちょｗおまｗ

そーいう手打ちになったんすか？俺が一方的にハブられて虚仮にされてんのかと思ったら、もしかしておばちゃん本気で認識なかった？

最近ブログの某界隈で割と話題になったあの1件が突如消えた（一時的にかもしれないけど）理由なんて、俺と本人しか判らない謎になるのだろうな...ワロス（悪意ないっすよ＞当事者）。

MapionとＪＲトラベルナビゲータが共同で、おもしろそうなケータイ位置情報ゲームを始めているようです。

ケータイ国盗り合戦

面白いなあ。
iエリアを使った信長の野望様のゲームとかは、昔っから位置情報利用系ゲームを考える際には話題には上がってたりはしたけど。
実際にゲームバランスとかを考えた具体的な企画にまで落とし込まれた事はなかったと思うので、なかなかエキサイティング。
一つの夢がかなったというか。

またこれを、小さなベンチャーとかではなくて、MapionやJRといった、比較的大手が形にしたというのも面白い。

まだ入会したばかりで、具体的なプレイ感とかはまだ試してないのですが、とりあえずご紹介まで。
やってみて面白ければ、さらに追記事書きます。

この1ヶ月半ほど、Google Adsenseの収入がこれまでの半分程度に減っていた。
理由は、Adsenseの場所を変えたからなのか、それともアクセス数が減ったからなのか。

アクセス数は確かに減っている。
でも、半分になるほどではない。
最近書く記事の傾向が、技術を離れてきているので、配信される広告の質が変わってきてるからかもしれない。
とか、いろいろ思ったんだけど、とりあえず試しに、3日ほど前にAdsenseを元の場所に戻してみた。
（ちなみに、この1ヵ月半ほどのAdsense配置場所はページの先頭記事の年月日の上、元の場所と言うのはページの先頭記事の本文直後）

すると、途端に収入が復調傾向に。
やっぱり、広告の場所って大事なんだなあ...本文読んだ直後の方がクリックしてくれやすいのか...。

何か良いことありそうだ...とか書いた直後によくない事の投稿なんだけどな。

どうも、某知人のＡさんに嫌われたらしい。
理由は、ある程度私を評価してくださっているＣさんからの情報によると、私があまりに率直過ぎるからだとのこと。
別に率直だってのは悪い事じゃないのでそんな理由で嫌われたのなら構わないけどさ。
問題は、その事を率直に教えてくれないでいろいろ回りくどく言いまわして、Ｃさんが「率直に」裏を教えてくれるまで、Ａさんに嫌われていることが判らなかったので、Ａさんとコラボレートできる機会があると私が長らく考えていたために、多くの機会損失をしたこと。
嫌ってるんなら嫌ってると「率直に」言えばええやん。

Ｃさんにその事教えてもらったあとの連絡でまで、「そんなこと知りません」みたいな書き方してきて。
別に俺に対してだけ、Ｃさんの言ってることとＡさんの言ってることとが矛盾してるだけならいいよ。
自分が私に書いてきたことが、Ｃさんが万人に大っぴらにやってる活動と矛盾してるということにも責任持たないつもりなんすかね。
Ｃさんがやってることの隣で、「のせられても責任者のＡさんは責任とってくれませんよ！」とか俺が言い出したらどうするつもりなんだろね。
そんなことしたらＣさんにまで嫌われてしまうのでしないけどさ。

別にとりあえず最低限のことすら認めてくれれば、全部白紙にして元に戻すって書いてんのに、それでさえ「率直に」ならず「そんなの知りません」ってどんなんだ。
率直を嫌うのはいいけど、最低限、常識程度の率直さくらいは持っていて欲しいもんだ。
もう妙齢の淑女のくせに、物腰の柔らかさにだまされた。何なんだ。

これ書いたらＣさん怒るかね。
でもまあＣさんの率直な内情暴露とアドバイスで終わってたら、まあ仕方ないかで収めるつもりだったんだけど、その後Ａさんから来たしらばっくれ連絡にムカついたのでつい書いてしまった。
あーあ、いろんなチャンスがあったのになあ。

はい、この一件はこれでおしまい！もう引きずらない！

別にどうでもええことなんだけれども。

Bloglinesに登録してて、最近更新されてなくて訪れていないブログなんていくらでもあるんだが、今日昼休みたまたまhail2u.netが目に止まって、そういえばここ、長い間見てないのに新着記事ないなーと思って訪れてみると、やっぱり2005年10月からエントリなかった。

人気ブログなのに辞めちゃったのかな、とか思ってたら、その日のうちに9ヶ月の沈黙を破って新しい記事が投稿される現場に出くわしてしまった。

何たる偶然。
うーん、なにか良いことありそうだ。

きょうここは、blogしたかったみたい。

SixApartに落とされたと以前書きましたが、他にもいくつか落とされ.

HTTP::MobileAgentのプラグイン機構を付けるとしたら、どんな風なのがベストなんだろうかと考えてみた。

マジで動き始めてくださったようで嬉しい限り。

機構はプロフェッショナルな人々に任せるとして、個人的にはプラグイン以上に実現して欲しいのがサブクラスの独立。
今のライブドア版で、DoCoMo偏重でWILLCOMが味噌っかすにされている状況は、看過し難い。
今やDoCoMo独走状態というのでもなくなったし、WILLCOMは下手をするとSoftBankを超えて第3勢力に躍り出るかもしれない勢いなのに。
かといって、1メンテナで全キャリアをカバーするというのも無理があるので、各キャリアの専門の人が各キャリアのサブクラスを担当するという分業体制がベストだと思う。
で、どのキャリアかを判定する正規表現も各キャリアの開発者が定義すべきだと思うので、その辺でもちょっと工夫が必要かなと。

Yappoさんは各キャリア毎のDisplayMapを揃えて欲しいとのことなんだけど、これはイマイチ必要性が判らない。
au、SoftBankはDisplayMapを作らなくても環境変数から直接ディスプレイサイズが取れるはずなので、新機種が突如アクセスしてきても対応できる分こっちの方が確実だし、一方でDisplayMapを作らないといけないWILLCOMは、今度はMakeWillcomDisplayMapスクリプトで解析できるようなデータのまとまったページがないわけなので。
Yappoさんは、ユーザエージェント詐称での動作テストをするようなケースを想定しているのかな？
基本は環境変数で、設定によってDisplayMapも使えるようにするとか、或いはDisplayMapで動く版をそれこそプラグイン機構でプラグイン化するとかはどうでしょうか。

WILLCOMのディスプレイサイズ一覧等はWILLCOMが用意してくれなさそげなので、memn0ckさんやなおっきさんあたりが、スクリプトでパースできるような形でまとめてくれないだろうか。
そしたらテラウレシス。

Google Maps Hacks、英語版ではつまみ読みしかしてなかったんですが、日本語版で通読してみると、サーバサイドで位置情報扱う時はPostGISを使う、とちゃんと紹介されてありますね。
組み込み幾何データ型の話など出てこず。
しかもPostGIS入門書として入門Webマッピングまで紹介されて...ありがたい限りです。

さて、先のエントリでは、PostGISでの正確な距離検索を行う関数 distance_sphere や distance_spheroid に対してインデックスが効かないので、これらの関数用のふるい関数として expand_sphere や expand_spheroid 関数を定義してやり、それによって事前ふるいをかけてやってから正確な距離計算をすればインデックスが効いて高速化するのではないか、と述べました。
しかし...この本届いたのはいいものの、ペラペラとめくってみたけどテラムズカシす。もう、マイボス・マイヒーロー状態。読む気もしねー。
というわけで、ふるい関数の実装は全然進んでないのですが、その前に本当にふるい関数を作れば高速化の効果があるのかを掴んでおくべきかと思い、ちょっと実験してみました。

使ったのは、このエントリで用意した、10万件の位置データが入った空間データベーステーブル。
ここで、先のエントリで述べた方法で導出したバウンディングボックスで事前ふるいをかけた場合とかけなかった場合の distance_sphere 関数による検索効率を比較しようという実験。
バウンディングボックスの計算には、ふるい関数は未実装なので、拙作のPerlモジュールLocation::GeoToolを利用した。
Location::GeoToolは距離計算を地球を回転楕円体とみなして計算するにもかかわらず、PostGIS側では地球を球としてみなす distance_sphere 関数を使っているが、飽くまで実験レベルなのでその程度の不正確さは見逃して欲しい。

まず、赤道上の東経140度、北緯0度を中心とした半径10kmの検索。
インデックスを使わない場合はこうなる。

postgres=# EXPLAIN ANALYZE

postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 0)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Seq Scan on geodata  (cost=0.00..5086.66 rows=33333 width=45)
                      (actual time=57.375..243.576 rows=3 loops=1)
   Filter: (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision)
 Total runtime: 243.719 ms

続いて、バウンディングボックスを定義してみる。
赤道上では、半径10kmの円に接する最大・最小の経度は、単純に東西に10kmの経度を調べればいいので、それでLocation::GeoToolを使って計算したところ、半径10kmの円は東経139.102度から140.898度、南緯0.904度から北緯0.904度の範囲に収まることが判った。
バウンディングボックスの効率的な作り方がよく判らなかったが、とりあえず以下のようなややこしい関数の組み合わせで作ってみたところ、

postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(139.102 -0.904)',4326),
postgres-# GeomFromText('POINT(140.898 0.904)',4326)),4326) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 0)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Bitmap Heap Scan on geodata  (cost=2.02..21.53 rows=2 width=45)
                              (actual time=0.737..0.830 rows=3 loops=1)
   Filter: ((geo_right && '010...略...CBF'::geometry) AND
           (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision))
   ->  Bitmap Index Scan on geo_r_index  (cost=0.00..2.02 rows=5 width=0)
                                         (actual time=0.612..0.612 rows=6 loops=1)
         Index Cond: (geo_right && '010...略...CBF'::geometry)
 Total runtime: 1.119 ms

というわけで、見事240倍くらいの高速化に成功した。

次に、極周りでの実験。
円内に北極を含むよう、東経140度、北緯89.5度を中心とした半径10kmの検索。

postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 89.5)',4326)) AS real_distance FROM geodata WHERE
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 89.5)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Seq Scan on geodata  (cost=0.00..5086.66 rows=33333 width=45)
                      (actual time=35.802..263.986 rows=455 loops=1)
   Filter: (distance_sphere(geo_right, '010...略...640'::geometry) < 100000::double precision)
 Total runtime: 272.990 ms

この半径10kmの円は、西経180度から東経180度、北緯88.605度から90度の範囲に収まるので、バウンディングボックスふるいをかけてやると、

postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 89.5)',4326)) AS real_distance FROM geodata WHERE
postgres-# geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(-180.000 88.605)',4326),
postgres-# GeomFromText('POINT(180.000 90.000)',4326)),4326) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 89.5)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Bitmap Heap Scan on geodata  (cost=11.45..1744.03 rows=233 width=45)
                              (actual time=13.027..40.211 rows=455 loops=1)
   Filter: ((geo_right && '010...略...640'::geometry)
           AND (distance_sphere(geo_right, '010...略...640'::geometry) < 100000::double precision))
   ->  Bitmap Index Scan on geo_r_index  (cost=0.00..11.45 rows=700 width=0)
                                         (actual time=5.735..5.735 rows=1550 loops=1)
         Index Cond: (geo_right && '010...略...640'::geometry)
 Total runtime: 48.910 ms

速くはなっているが、赤道周りほど高速化していない。
これには理由があって、元々極域はバウンディングボックスが大きくなる上に、この実験では検索する点を球面上ではなく経緯度平面上でランダムに散りばめたので、極域では検索点が密集して、ふるいに引っ掛かる点が多くなり、それに対していちいち distance_sphere 関数の計算をしているので遅くなっている。
もし、ちゃんと球面的に平均して検索点が存在しているのであれば、そこまで遅くはならないはずだ。

最後に、経度180度を挟む場合。
この場合、経緯度平面は経度-180度から180度までなので、バウンディングボックスは2つに分割される。
まず素で検索してみると、東経180度、北緯0度を中心とした半径10kmの検索は、

postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(180 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# distance_sphere(geo_right, GeomFromText('POINT(180 0)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Seq Scan on geodata  (cost=0.00..5086.66 rows=33333 width=45)
                      (actual time=61.025..229.897 rows=6 loops=1)
   Filter: (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision)
 Total runtime: 230.094 ms

この半径10kmの円は、西経179.102度から東経179.102度、南緯0.904度から北緯0.904度の範囲に収まるが、経度180度で分断されるのでバウンディングボックスとしては2つになる。 

postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(180 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# (geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(-180.000 -0.904)',4326),
postgres-# GeomFromText('POINT(-179.102 0.904)',4326)),4326) OR
postgres(# geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(179.102 -0.904)',4326),
postgres(# GeomFromText('POINT(180.000 0.904)',4326)),4326)) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(180 0)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Bitmap Heap Scan on geodata  (cost=4.03..38.80 rows=3 width=45)
                              (actual time=0.809..1.003 rows=6 loops=1)
   Recheck Cond: ((geo_right && '010...略...CBF'::geometry) OR
                 (geo_right && '010...略...CBF'::geometry))
   Filter: (((geo_right && '010...略...CBF'::geometry) OR
           (geo_right && '010...略...CBF'::geometry)) AND
           (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision))
   ->  BitmapOr  (cost=4.03..4.03 rows=9 width=0)
                 (actual time=0.650..0.650 rows=0 loops=1)
         ->  Bitmap Index Scan on geo_r_index  (cost=0.00..2.00 rows=1 width=0)
                                               (actual time=0.326..0.326 rows=6 loops=1)
               Index Cond: (geo_right && '010...略...CBF'::geometry)
         ->  Bitmap Index Scan on geo_r_index  (cost=0.00..2.03 rows=7 width=0)
                                               (actual time=0.275..0.275 rows=6 loops=1)
               Index Cond: (geo_right && '010...略...CBF'::geometry)
 Total runtime: 1.212 ms

この例も馬鹿っ早になっている。

というわけで、このようなバウンディングボックスを導出してくれる expand_sphere 関数を定義し、distance_sphere 関数で検索する前に geo_right && expand_sphere(...) といった形でふるいをかけてやれるようにすれば、インデックスが効く形で正確な距離検索ができるようになる。

...と書いたが、実は最後の例に問題があって、最後の例では geo_right 列と2つのバウンディングボックスとのふるいを OR 文で繋いでいる。
これだと、単純に expand_sphere 関数でバウンディングボックスオブジェクトを返してやる、ということができない。
実は、最初はここで2つのバウンディングボックスを1つのマルチポリゴンにまとめてやって、それを使ってふるいをかけるつもりで、GeomUnion 関数を使ったこのようなSQLを実行してみていたのだ。

postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(180 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# geo_right && GeomUnion(SetSRID(MakeBox2D(GeomFromText('POINT(-180.000 -0.904)',4326),
postgres-# GeomFromText('POINT(-179.102 0.904)',4326)),4326),
postgres-# SetSRID(MakeBox2D(GeomFromText('POINT(179.102 -0.904)',4326),
postgres-# GeomFromText('POINT(180.000 0.904)',4326)),4326)) AND
postgres-#         distance_sphere(geo_right, GeomFromText('POINT(180 0)',4326)) < 100000;
                                      QUERY PLAN
----------------------------------------------------------------------------------------------
 Bitmap Heap Scan on geodata  (cost=18.12..2425.03 rows=392 width=45)
                              (actual time=27.708..39.353 rows=6 loops=1)
   Filter: ((geo_right && '010...略...CBF'::geometry) AND
           (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision))
   ->  Bitmap Index Scan on geo_r_index  (cost=0.00..18.12 rows=1177 width=0)
                                         (actual time=16.182..16.182 rows=1924 loops=1)
         Index Cond: (geo_right && '010...略...CBF'::geometry)
 Total runtime: 39.586 ms

ところが、何故かご覧のとおり、大量の検索点がふるいにかかってしまって、速度が出ない。
どうも、経度-180度から180度の間を全部引っ掛けてしまっているっぽい。
何故かよく判らない。マルチポリゴンの作り方が悪いのか？GeomUnion 関数じゃ駄目なの？

この次はこの辺を、もうちょっと追求してみたいと思う。

Google Maps Hacks -地図検索サービス徹底活用テクニック- posted with amazlet on 06.07.19 Rich Gibson Schuyler Erle 武舎 広幸 福地 太郎 武舎 るみ オライリー・ジャパン (2006/07/22) Amazon.co.jp で詳細を見る

Google Maps Hacksの待望の日本語版が発売されました。
ペラペラとめくってみましたが、原著から翻訳版までの間の状況の変化等もしっかり押さえてあり、中々の出来。
中でも感心したのは、日本版での環境での事例や、原著の頃との状況の差等が、注やコラムの形ではなく、本文の訳文の中に自然に織り込まれていること。
それでいて、特に不自然さもなくすんなり自然に読むことができます。すごくすてきな翻訳。
この辺、入門Webマッピングも見習わないとな...と言ってももう直せるわけじゃないですが...次同じような機会があったなら、がんばろう。
（というわけで、Mapping Hacks又はPragmatic GISの翻訳のチャンスを！とか言ってみたり。）

あ、そうそう、先日紹介した新雑誌「Make:」の織り込みチラシが挟まれていました。

こちらも中々面白そう。
先の記事でも書いたとおり、原書は季刊の雑誌ですが、日本版が続けて出るかは創刊号の売れ行き次第だそうなので、皆さん是非買いましょう！

今日は広いうちなどされてませんが、ネットで人気などされてませんが
広い人気とサイトとか、うちとかを登録しなかった？
とか書いてみるの♪


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

会社で受けさせてもらった人間ドックの結果が返ってきました。
最近ストレス太り＆薬の副作用もあり、体重が大台に載りそうなので今回はCTも受けたのですが、幸い内臓脂肪は正常値内で、メタボリック何とやらには罹っていない様子。

正常値内と言っても限界ギリギリなのですが、とはいえその一つ上は「軽度」なので、文句なしに「重度」だろうと思ってた割にはマシだったと。
まあ、なぜか昔から肥満の体の割りには、中性脂肪やコレステロール値は正常範囲内でも低い方だったのですが（今回も）。
しかし、そうはいっても実際の容量は体重の分あるわけなので、内臓に脂肪がなければ当然皮下に脂肪があるわけです。
ちょっと青い領域のすさまじさにクラクラとしてしまいました。

ただ高いのは尿酸値。これはもう10年近く前から変わらずかなり高い。
原因は不明。
尿酸値上昇の原因と言われる焼肉等の食生活だが、焼肉は大好きではあるけど、食べ放題じゃないところにいけるほど生活が豊かでもないので、特に東京に来てからは店を開拓しておらず、年に1度か2度食べる程度だ。
ビールにしたって、飲み会があれば結構飲むが、普段は週に1回か2週に1回程度、350ml缶を飲むか飲まないかという程度。
なので、何故高いのかはずっと不明だ。

そんな状況の私に対して、ドックの最後、問診の医者が顔を合わせるや開口一番、「あなた、焼肉好きでしょう！」。
この一言で、彼は一瞬にして「あ、こいつ藪医者だ」と私に思い込ませるミッションに成功しました。

彼の発言には2つの問題がある。
１つは、まず断定してかかっていること。
実際私がそうであるとおり、高尿酸値血症というのは必ずしも食生活が原因とはいえないケースもあるようだし、そしてその体全体の問題の、根本原因を洗い出し見つけてもらうために全体検査の人間ドックをやっているというのに、いきなり「こういう結果が出ればこう言えばよい」というマニュアルに当てはめた対応をしていること。
第2に、本質と関係ない部分に関して質問していること。
1つ目の問題があったとしても、まだ「焼肉、よく食べるでしょう」という質問だったらまだマシだったのだ。
本質は、焼肉を頻繁に摂取しているかどうかなのだから。
ところがこの医者の聞いてきた「焼肉が好き」かどうかは、「焼肉を頻繁に摂取する」ことと、一定程度の重なりはあっても本質的にはかかわりがない。
先にも書いたとおり、私のように「焼肉は好きだけどあまり食べない」というケースだってあるわけなのだが、この場合私は何と答えればよいのか？
馬鹿正直に、好きなのだからと「はい、好きです」と答えろというのか。

さすがに私の方はそのおかしさが判らないほど愚鈍ではないので、「はい、焼肉は好きですがそれほどは食べません。年に1、2度食べるか食べないかです」と答えた。
そしたら藪医者、案の定次の質問も、「そうですか、でも、ビールとかよく飲むでしょう？」との定型質問（「ビール好きでしょう」じゃない分進化したか？）。
それにも週に1本缶を飲むか飲まないかですと答えると、「そうですか？でも、尿酸値はそういう食生活が影響してきますから、気をつけてくださいね」で、終わり。
結局なぜ尿酸値が高いのか、何も判らず仕舞い。

この医者はほんの一言で私に不信感を植え付けたわけですが、それなら信頼される物言いをするにはどうすればよいか？というと、このケースの場合は彼の発言の問題点の逆、つまり、

• 主観を断定するのではなく、客観的に探りを入れるアプローチ
• 迂遠な表現を避け、本質となることそのものを対象とするアプローチ

が必要だったのだと思う。
つまり、「焼肉をたくさん食べ過ぎたりしていることはありませんか？」みたいな。
そういう質問をすることで、それが否定されたとしても別の可能性を検討する方向に話を持っていく流れを作ることができる。
（もちろん、主観的物言いでも、否定後別の可能性に話を持っていく事は可能だが、そもそもの「断定」が別の可能性を語ることを想定していないと捉えられるので、第一声で与える信頼感には格段の差がある。そして実際、今回のケースでは、別の可能性は想定されていなかった。）

もちろん、あらゆるコミュニケーションの局面で、上記の2点が考慮すべき点である、とは言い難いだろう。
でも、あらゆる局面に通ずる真理は、もう少しメタな次元で考えれば判ると思う。
医者の問診というのは、どのような役割が期待されているのか？
それは、情報を入手する前からの医者の主観的な断定を押し付けるための場ではなく、客観的に患者の体の状況に関する情報をできるだけ正確に集め、それを元に判断を下す場である、という行うべき役割の本質を弁えて発言していれば、決して今回の医者の発言のようにはならないはずだ。
結局、結論としては当たり前すぎるものになるが、その場その場で自分の果たすべき役割を本質的に理解して、その理解を元に語るべきことを十分吟味する、という事になるかと思う。
でも、その当たり前のことが、往々にしてできないわけであるが（私自身も含めて）。

ところで、尿酸値の件、これまであまり深く考えず高いという事実だけを受け入れてきたのですが、この人間ドックでいい加減にあしらわれたのをきっかけに、もうちょっと自分で何が原因か考えてみようと思うようになった。
で、自分でいろいろ調べてみた結果、肩こりが筋緊張⇒乳酸、尿酸などの老廃物の発生⇒筋緊張による欠陥扼腕による、老廃物の排出阻害⇒さらに疲労、筋緊張という悪循環でおこるという話を見つけた。
これが事実なら、私は頚椎変型症で常時首から肩、腕に至る筋肉が緊張しており、それによる神経扼腕で手指が痛んだり痺れたり、酷い肩こりが起きたり、という状況が日常となっている。
この症状が出始めたのも、ちょうど尿酸値が高くなり始めた10年前頃と一致する。
もしかしたら、頚椎変型からくる筋肉の常時緊張が、常時尿酸を大量に発生させ、尿酸値の上昇に繋がっているのかもしれない。
飽くまで素人考えだが、今度行きつけの内科に罹った時にでも、ちょっと聞いてみようと思う。

金持ち頭脳やってみた。
よーし、2029年目指して頑張るぞー。って、ほとんど定年間近かよ。とほほ。
なんか私との、ビジネスパートナー相性診断もできるそうです。 

あなたのお金持ち階級は「セレブお嬢様級」です（100点満点中77点でした）

総合評価：
タイプ：優柔不断型

　大塚恒平さんは大変お金持ち向きの体質と言えるでしょう。今がダメだとしても将来には明るいものが感じられます。バランスだけではなく、生命力に高い数値を示しているので、能力にパワフルさを兼ね備えて磐石と言えるでしょう。
　また、価値観が柔軟で環境の変化にも頭の中は適応しやすいのですが、実際に行動するにはあれこれ考えすぎてなかなか重い腰の上がらないタイプのようです。決断の遅さで逃してしまうチャンスもありそうです。

バランス評価：
先天性（ランクS）

素質とその後の成長はあればあるほど良いのは当然ですが、そのバランスが高く評価されました。自らの能力に奢らず、成長のための努力もほどよく維持しているという点で一般的理想像に近いようです。今後も自分の素材を見極め、自分に向いている分野を開拓して極めましょう。

善悪（ランクB）

「善悪」の傾向は、お金持ち理想像とは少しずれているようです。世間一般は、もう少し悪人であるべきということのようです。立派な人としてではなく、お金を稼ぐためにはですが…。目的のためには手段を選ばないことも必要ということでしょう。

理論と行動（ランクS）

理論派か行動派かというバランスは、理想に近いと評価されました。理論も大切ですが、経験からしか学べないこともある、というのが世間のお金持ち像のようです。大塚恒平さんはそのバランスが程よく、高い評価を受けたといえます。

過程と結果（ランクA）

「過程と結果」のバランスは、世間の理想像と近いようです。ひとつひとつの過程も、結果を出すことも、どちらも重要という中間スタンスが理想に合致したようです。事の重大さなど、状況に応じて何が最優先であるかを判断できることが高い評価を受けたと言えます。

繊細と大胆（ランクA）

繊細さと大胆さの傾向においての評価は普通です。ある程度は評価できますが、ややお金持ちの理想像と比較すれば繊細、言い換えれば神経質であると言えそうです。もう少し図太さと、あっと驚くような派手さがあってもいいのかもしれません。

信念（ランクA）

とくに理想的でもなく逆行しているわけでもなく、ほどほどの結果です。少し信念に欠ける部分が評価を押し下げています。環境に対応できるということは良いのですが、いざ指針が見えなくなったときに迷いが生じるタイプと判断されたのでしょう。

おまけ

• 大塚恒平さんのお金持ち資質は、日本人口1億2千7百万人のうち第2571万0531位に位置します
• 大塚恒平さんのお金持ちピーク予想は2029年です。そこそこ期待できる山となるでしょう

Sunのワークステーション1台とDukeマウス30台（1人に！）がもらえるというサン・マイクロシステムズ賞。ですが、訂正させてください。
実は、Dukeマウスは先着30名だと、先日は発表されました（＾＾；

というわけで、リクルート・Sun主催のマッシュアップ・アワード、ネタとしてはそれなりにおもしろかったDukeマウス30台独り占め賞ですが、応募先着30名に変わったようです。
まだ間に合いそうという事なので、皆さん応募されてはいかがでしょうか。

そういう私も、何かやろうかなと思い、Google Mapsとのマッシュアップ云々だと既に私は後追いなアレですので、得意なケータイ位置情報と絡めてなんかやろうと思ってたのですが、HTTP::MobileAgent::Plugin::Location周りを整理しようと思っているうちにグダグダと時間が過ぎちゃった感じで、間に合うのかな？という感じです。
所有者に協力してもらっての、未対応ケータイの位置情報取得チェックもまだ今からやんなきゃだし。

でもまあアイデアはあるので（というか昔の引き出しから出してきたアレですが）、間に合わなくてもアイデアはブログ上で晒します。
...といいつつ、このアイデアって、今のリクルートWebAPIとの相性は悪い気がしてきた...HotPepperのAPIとかあればビンゴなネタなんですが...。

はてなブックマークなどには登録されてませんが、うちのサイトの隠れた人気エントリはいくつかあります。
人気エントリの定義もいろいろですが、単にアクセス数が多い、とかではなく、訪れてくれた読者の方の疑問・要望を満たせているか、という視点でピックアップしてみると、やはり一番人気はこのエントリかなと思います。

掃除機ホースに詰まったハンカチの取り出し方

このエントリに対して、コメント、トラックバック、リファラー辿っての言及記事、メール、等等で寄せられた「助かりました！」の声は2桁にのぼります。
位置情報でも、オープンSNSでもない地味なエントリですが、それだけに息も長く、地味に人気を集めております。
これだけ人気なネタなのですが、伊藤家の食卓にはサクッと落とされました...。

これに追いつく勢いで、最近急速に台頭し始めているのがこのエントリ。

MovableType 3.2、MT::App::Trackback.pmの修正

MovableTypeのトラックバック受付機能に、「同じIPから大量にトラックバックが送られてくればSPAMとみなして、そのIPからのTBをはじく機能」がついているのだけれど。
しかしそのロジックの中に、「同じIPから」をチェックする判定条件が肝心なところで抜けているので、「同じIPから大量にTBが送られてくればSPAMとみなして、全てのIPからのTBをはじく機能」になってしまっているというバグの、修正をしたエントリ。
このバグを放置しておくと、トラックバック・スパムの雨に晒されているブログでは、どこからであろうと一切のトラックバックを受け付けなくなってしまう。
エントリを書いた時点ではまだうちほどTBスパムに晒されているサイトも少なかったのでそれほど目立たなかったが、最近TBスパムが手当たり次第になってきたので、みんな同じ現象に悩むようになってきたというところかな。

ただ、MT3.2の不具合は他にもいっぱいあるので、修正するならこれだけ単独で修正するのではなく、これも取り込んでいただいているMT 3.2日本語版Unofficial Patch - Ogawa::Memoranda -を適用するのが吉です。

でも、どうしてSixApartはこの辺の不具合のアナウンスも、修正パッチの公式配布もしてくれなかったんですかね...このTB不具合についてはどうか忘れましたが、少なくとも私が見つけた不具合の1つについては、ちゃんと6Aのサポートに連絡しているんですが...。
なんかその辺の不信感もあり、3.3でちゃんといろんな不具合が修正されてるのかどうかイマイチ不安というのもあり、また私もFastCGI化MTユーザなのですが、こんな情報もあったりするので、MT3.3アップグレードに踏み切る勇気が持てずにいます...。

息子がマクドナルド・ハッピーセットのおまけのカーズにはまっているので、3連休だし連れて行ってやるか、と映画の上映情報見たら、もう終わってるやん！

最近の映画って、1週間で公開終わっちゃうの？
昔ってもっと、3週間くらいとかやってなかった？
映画ってもともとあまり見てなかったし、特に息子が生まれてからは映画館に赤ん坊連れて行くわけにいかないのでデフォルトでレジャーの選択肢から外れてて、全然判らなかった。
何時頃からこんななの？

仕方ないからカーズはDVDが出たらすぐに借りてあげる事を約束して、今日が公開初日のポケモンに連れて行くことで手を打ったけど...。
上に書いたように最近の映画事情判ってないから不安なんだけど、そんな短期間しか公開しないならみんな集中して見に来て、並びまくって大変だったりするのかな...。
超不安。

先のエントリへのはてブ

既に縁のなくなった会社との適性なんかどうでもよいのですが、書いた事で人間性に対する誤解を招くと嫌なのでもう１エントリ。

論理的に言って、転職の面接上で私が「50％ルールで研究してみたいと話した内容について、ビジネスとの繋げ方を説明できなかった事」と、私が「ビジネスに結びつく研究がしたくない（＝自分の好きな研究しかしたくない）人であるという事」には、何の関連性もありません。
周辺情報なしで1回勝負の面接ではそう判断されても仕方ないかもしれませんが、Googleのルールと同じ基準かと勘違いしていたという事を説明しているブログ記事においてまで、そのような判断をされるのは心外です。
自分のやりたい仕事しかやらないような奴が、「GISとインターネットからの情報収集」をやらせてもらえるというから入った会社で、実際にはシステムの構成に関する設計・管理・客先折衝・社内調整等という全然違う事やっているにも関わらず、功労者として部長からうちのチームに慰労会開いてもらえたり、うちのチームだけ隣の部署の宴会にも呼んでもらえたり、みたいな事がありますかいな。

Googleの基準と同じだと思っていたから、TCP/IPの上にもう一つ別のレイヤ（認証・承認レイヤ）を加えてインターネット全体をSNS化する、という自分として最大のテーマを伝えただけであって、ビジネスとの繋がりが必須だと事前に判っていたならば、そんなもん面接の場では出しませんわな。
弾さんがいう「ライスワーク」と「ライフワーク」の差くらいは弁えているつもりなので、本来今回しゃべったことはライフワーク側に倒すべきこと、普通の会社の面接でなら絶対言わないネタですが、別に得られる限りの事前情報ではそれを言ってもいい場だと勘違いしたからそれを話したまでのことで、それが望まれてないと最初から判ってたなら話しません。
別に引き出しは一つじゃないんだし。
引き出しはいくつもあると言ったって、なんでもいいんじゃなくてサイボウズのビジネスと繋げなきゃいけないので、そこをうまく繋げる方法を考えないといけないわけですが、もし最初から50％をビジネスと繋げる方法が要求されていると判っていて、それが思いつかなかったのであれば、応募しなかっただけのこと。
行ってみたいけど、応募条件があわないから応募していない会社なんて、それこそGoogleを筆頭としていくらでもあるのだし。

で、俺が勘違いしたように、サイボウズラボの募集要項、特に50％ルールに関する書き方だと同じような勘違いをして応募してくる奴がわんさかいると思われる。
そんな奴は、俺と同じように勘違いしたプレゼンをして、みんな軒並み落とされるだろう。
転職活動というのも、エネルギーを使ってなかなか大変なもんだ、ましてや落とされるとなると。
サイボウズラボの方にしたって、面接には何人もがよってたかって「時間」単位での時間を浪費するのだ、落とすような結果に終わる無駄な面接は減った方がいいはずだ。
だから、サイボウズラボの50％ルールは字面から受けるイメージとは違うんですよ、ちゃんとそれを認識して事前準備してから応募、面接に臨んだ方がいいですよ、ということを忠告したくて、サイボウズラボ自身がそれを裏付ける発言をしたことを機に、先のエントリを書いたのだ。
その辺はちゃんと、先のエントリでも

というわけで、これからサイボウズラボに応募しようと思う方は、50%ルールで何をしたいか、だけではなく、それがどのようにビジネスに結びつくか、というところまできちんと頭を整理してから、臨まれた方が吉です。
今後続く人のために一助になればと思い、１エントリ設けさせていただきました。

と、ちゃんと書いてる。

しかし、やっぱり、面接みたいに1回勝負の発言で自分を判断されるというのは、中々つらいものがあるよな。
やっぱり同じように面接での発言で「失敗した！」と思ったのは、同じように落とされたSixApartでの面接の時。
これはサイボウズラボのように「もうちょっと判るように書いてくれよ」とかそんなのもなく、完全に私側のミス発言だったし、またこれも別にこの発言一つだけで落とされたとは思わないけど、SixApartに関しては複数回面接を重ねてきて、かなり友好的で自分でも「これは通ったな」という雰囲気を掴んでいたのが、その発言以降場の空気が変わったと感じたので、これが大きな原因の一つにはなっていると思う。

発言内容としては、前の会社を辞めた経緯を説明していた際に、「位置情報の仕事をやるために入ったのに、やりたくもない着うたの仕事をやらされた」と普通に聞けばとられかねない、やりたくない仕事はやりたくない奴だととられるような発言をしてしまったこと。
経緯がうまく説明できず一言で説明できずにそのようにとられてしまったが、実際はこのような経緯だったのだ。
着うたの仕事は、やりたくないどころか、最初は超乗り気だった。
理由は、経営陣から、「それをやれば、むちゃくちゃ儲かるらしい。月売り上げ1000万円とかいくらしいよ」といって企画を持ってこられたからだ。
やりたい仕事であり、また社是として会社が取り組むべき仕事であるはずの位置情報に関する仕事が全くできないのは、会社に金がないからだと判っていたのだから、金になるという仕事がやりたくないわけがない。
で、超乗り気で企画がスタートしたし、結構な額を投資してシステムも作り、楽曲提供先とも提携して、着うたサイトをスタートさせた。

嫌だったのは、この後の経緯だ。
フタを開けてみると、売り上げは散々、詳しい額は書けないが、まあ見積もりと2桁から3桁は違っていたと言えば大体判るだろう。
俺も話が違うので驚いたが、そこはそれ、仕事というのはPlan（計画）、Do（実行）、Check（評価）、Action（改善）のPDCAサイクルを回していくものだと考えていたから、儲からない理由を分析して、改善していかなければと考え、そのようにしようとした。
ところが、経営陣からは、最初数ヶ月運営してみて予想したような収入がないと判った途端、放置プレイを言い渡されたのだ。

もちろん、投資に見合う効果がないと判ったならば、改善に費用を使うより、早めに損切りをするのも一つの経営判断ではある。
しかし、それならばサイト運営を停止すべきであるのを、公式サイトを辞めるのはキャリアへの手続きの手間もかかるし体裁も悪い、所詮かかるのはサーバ費用だけ、たとえ○万円といえども毎月入ってくるのだから、運営は止めないという。
冗談じゃない、うちはそうかもしれないが、楽曲を提供してくれる側は、生演奏やオリジナルリミックスした音源を提供してくれるところだったから、毎月百万単位で赤字が出ているのだ！
楽曲提供元とは、うちが金を支払って楽曲を入手するのではなく、共同運営という形をとって、システムはうち、楽曲は提携先、開発費は折半、楽曲は権利関係をはっきりさせるために、提携先が自費で作成して、代わりに権利は提携先のみが持つ、という契約をとっていた。
当然提携先からしてみれば、この事実はたまったもんじゃないので、ここをこうすべきだ、といった再三の改善要求が挙がってくる。
しかし飽くまでこちらは、「開発費は折半の契約ですから、まず開発費の話をしましょう」、という形でつっぱね、完全放置プレイ状態。
たしかにそういう契約なんだから仕方ない、という話もあるが、それは信義則に反すると思わないか？

経営陣を無視して俺がちょこちょこっと直せでもしたらよかったのだが、そこは公式サイトの悲しさ、どんな形であれサイトの構成等に手を加える際は、キャリア側に企画を提出し、企画が有害なコンテンツが配信しないか、公式サイトの規約に合っているか等をキャリア側がチェックした後でないと、変更できないのだ。
そして、そのキャリアに企画を提出する窓口は経営陣が握っており、我々では何ともしようがなかった。
俺にできたのはせいぜい、UIを変えない範囲で内部をリファクタリングして処理効率をよくするとか、検索結果の並べ方のように企画書では厳密に定義されていない部分で気を使って検索しやすいようにするとか、その程度が関の山だった。
結果、サイト運営後半年かそこらで楽曲提携元は夜逃げしていなくなり、着うたサイトは楽曲の更新がなされないまま、その後も1年以上放置プレイで運営され続けた。

こういう経緯が嫌だっただけで、自分のやりたい事と違った着うたサイト運営が嫌だったわけではないのだが、しかしこの異常な、複雑な経緯をうまく説明できず、一言で説明しようとして、逆に俺の方が悪いような、やりたくない仕事はやらない奴、というふうな受け止められ方をしてしまった。
本当に言葉というのは、よく考えてうまく使わないと、怖いなと思う。

...といっても、俺の実装を採用してもらえそう、ということではなく、ここで提案したような改修の方向性に関して、現在のメンテナの方に同意いただいたという事なんだけど。

改修案提案してから、ここやここなんかで報告しつつちょこちょこと開発してて、去年の10月末頃には、ここでほとんどできていた（というか、できてないのはPODだけ？）のだけれど。
そこで本家メンテナの方に提案しようと連絡したちょうどそのタイミングに、メンテナの交代とかあって話がグダグダになったので、ケータイWeb方面への興味も薄れてきてたこともあり結局自分でも放置プレイ状態になってた。

そこへ最近、Where2.0好きな人の集いでHTTP::MobileAgent::Plugin::Locationを話題にしたことなんかを機に、もういっぺん見直してみるか、と見てみたら、自分のアイデアがちゃんと形になっているだけでなく、本家にはないIPアドレスによるアクセス拒否機能だとか、本家ではDoCoMoのディスプレイサイズにしか対応していない、各種Web上情報からデータファイルを自動生成するツールとかも揃っているので、これをそのまま寝かせておくのはもったいないなと思い、今のメンテナの人にコンタクト取ってみた。

そしたら返事が来て、あまりにもモジュール構成が本家の現行と変わりすぎているため、いろいろ利用している人に与えるインパクトが大きすぎ、そのままでは現在のtrunkには取り込めないけれども、進化の方向性としては同意いただけるとのこと。

うん、実際自分でもごちゃごちゃし過ぎてるとは思う、今となってはどうでもよいようなHTTP::MobileAgent::Plugin::Extensionとのインタフェース互換性なんかも実現しようとしたりしてることもあって。
しょせん私は今のところ「日曜プログラマ」、さっき「このままじゃもったいない」と書いたのは、これだけの機能を実現したHTTP::MobileAgentを存在しなかったことにするのがもったいないというだけで、同じ機能を持つものをプロのプログラマがきっちり実装してくれるならば、俺的にもそっちの方が嬉しい。
というか元々、半分「捨て実装」と思っていたところも自分でもあって、この世界のよい面でもあり悪い面でもあるとは思うのだけど、正論吐いても自分で手を動かさなければあまり相手にしてもらえないようなところがあるので、とりあえず実装してコードで「こういう事がしたいんだ！」ということをメインストリームの人に判ってもらうためだけに書いた実装、という感じのところもあるので。
その意味では、コードとして採用してもらえなくても、同程度の機能の開発を約束してもらえるなら、十分この実装は役目を果たしたかなという感じです。

でもちょっと不満があるとすると、個人的に今、久々にケータイ・位置情報系に盛り上がっている事もあって、HTTP::MobileAgent::Plugin::Locationなんかも、最新の位置情報取得仕様に対応させてもういっぺん整備し直したいなー、んでもってCPANに上げたいなー、なんて考えているのですけれども。
でも今のHTTP::MobileAgent::Plugin::Locationは、時代の徒花であったHTTP::MobileAgent::Plugin::Exensionをベースにしていることもあって、そのままではCPANに上げられない。
CPANに上げられる形で整備するには、HTTP::MobileAgentがプラグイン機構を持つのを待たないといけないわけですけども、メインストリームがそれを実装するまで待たないといけないのは歯痒いなあと。
私の実装ベースなら今すぐにでも取り掛かれるのに。
とりあえずケータイ・位置情報系の熱が冷めないうちにHTTP::MobileAgent::Plugin::Locationの整備とかしたいので、自分勝手な願いながら早くHTTP::MobileAgentがプラグイン機構を整備してくれたらな、と思ったりしてます。
メインストリームの人は忙しいだろうので、無理だろうとは思いますけども...。

私の友人が強力に推し進めてる位置情報の記述仕様、「Locapoint（ロカポイント：通称ロカポ）」が、様々なツールを取り揃えて、遂に本格始動を始めました。

ロカポは、以前も紹介したのですが、経緯度のように人間の覚えにくい形でも、住所のように覚え易いが位置の特定にあいまいさがあり、またグローバルに一意表記できない形でもなく、アルファベットと数字の規則的な12桁の並び（電話番号と変わらない！）だけで、数ｍ単位の精度で全世界的に位置を特定できる画期的な仕様です。
「俺の住所、目黒区原町１なんだー」「My address is, 1 Hara-machi, Meguro-ku」等と言い換えなくとも、「北緯35.616541度、東経139.696301度が俺の家なんだ」等と覚えられないような表現をしなくとも、「俺の家、SD7.XC3.PO9.EV8なんだ」で世界的に一意に表す事ができるようになっています。
（ちなみにこの住所は俺が前住んでいたところ。今の家は、ブログの過去ログ漁れば出てくるけれど、さすがに大々的な例にするのは気が引けました。）
その上、12桁のうち上6桁で大域エリア、下6桁で詳細エリアを表すので、あまり詳細に示したくない場合は、「俺の家、SD7.XC3付近なんだ」等とあいまいに言及することも可能。
という、中々面白い仕様なのです。

私なんかは、単にこの表記仕様がドットで区切られた3桁×4部分という、IPアドレスに似た仕様なので、そのまま通信アドレスに使えないかななんて夢想したりもしてるのですが。
例えば、先日紹介したPlaceEngineなんかで、街中のPC等デバイスがみんな位置情報を持つようになったら、「SD7.XC3.PO9.EV8/2000にデータ送信」なんてやると、北緯35.616541度、東経139.696301度を中心として2kmの範囲内の位置を持つデバイスに対し、情報がプッシュで降って来るようになったりしたら面白いなあと。

で、冒頭に書いたツールというのが何かというと、２つありまして、住所からGoogle Mapsの地図を簡単に検索でき、かつGoogle Mapsの画面上に現在地のロカポが表示され、その場所のロカポを調べる事のできるツール「ロカポ ツールバー」と、Web中のロカポ表記を発見し、自動的にそのロカポに対応した位のGoogle Mapsへのリンクを張ってくれるJavascriptです。

最初のロカポツールバーですが、こちらからインストールできます（IE版のみ。Firefox版は現在作成中とのこと）。
インストールした後はこんな感じ。

みたいな感じで、住所から簡単にGoogle Mapsを引き出せ、またその場所のロカポ表記を得ることができます。

あと、副次機能として、見ているサイト中にロカポ表記があった場合、自動的に対応するGoogle Mapsへのリンクを張ってくれる機能もあります。

使ってみて気付いた難点をいくつか。将来改善される事を願って。

1. ツールバーのActiveXに署名が含まれていないので、IEのセキュリティレベルを一旦「未署名のActiveXのダウンロード⇒ダイアログを表示する」に落とさないとインストール不可であること。
   これは悪戯に「怪しいツール」と思われかねないので、なんとかして欲しい。
2. 住所入力直後にロカポが表示されない。
   少しドラッグするなど地図を動かさないと、ロカポの表示が始まらない。
3. 何がトリガか判らないが、時々地図を動かしてもロカポが更新されず無反応になる。
4. 肝心の「ロカポ自身」をツールバーに入力しても、対応した地点に行ってくれない。
   ツールバーに入れられた文字列は、飽くまで住所として受け渡されるよう。 

といったあたりかな。

で、このツールを使って任意の場所のロカポを導出できたとして。
そのロカポ記述を自分のサイトの記事等に記述しておけば、ロカポツールバーをインストールしている人がサイトを見れば、自動的にGoogle Mapsへのリンクになってくれる。
でも、ロカポツールバーをインストールしていないビジターには？単なる正体不明の文字列が見えるだけ？
そういう問題を解決するために、ロカポ表記をGoogle Mapsへのリンクに置き換えてくれるJavascriptも用意されています。
HTMLのヘッダーに

<script src="http://www.locapoint.com/common/lpautolinkify.1.js" type="text/javascript"></script>

と書いてインクルードしておくだけで、そのページ内のロカポが全てGoogleMapへのリンクへと変更されます。
これで、ロカポを知らない人にも、ロカポを使った場所のナビゲートをすることができます。

ね、面白そうじゃありませんか？
こんなロカポを、是非使ってみて広めてください。
ちなみに、実はPerlでロカポを扱えるモジュールは、もう作成済みです。
Location::GeoTool::Plugin::Locapoint
いろいろ遊んでみてください。 

SixApartに落とされたと以前書きましたが、他にもいくつか落とされた企業がありまして、そのうちの一つがサイボウズ・ラボだったりします。
基本的にWeb2.0系企業には嫌われる私。ぐっすん。
その落とされた理由を振り返るのに、有用な記事があったので引用。

技術と事業を結びつける鍵--「ラボ」の存在意義を検証する

技術者に人気の高いGoogleでは、すべてのエンジニアが仕事時間の20％を自分の好きなプロジェクトに費やすという「20％ルール」が存在するが、サイボウズ・ラボでは「50％ルールを適用している」と畑氏。
きっかけは「20％よりもインパクトがある」ということで始めたというが、研究開発テーマを自分で決める能力のある開発者にとってはまたとない環境だ。

ただし、自主的にテーマを決めるのは難しいことでもある。
畑氏は、「ある程度経験がないとできない。
採用の際には、なるべくビジネスとかけ離れないテーマを自主的に見つけられる人、という基準を重視している」と述べる。

ということだったのな。

一方で、グーグルの方はというと、ちょっとどこで読んだ記事か判らなくなって引用できないが、「技術者は技術だけを考えよ、技術を開発する際に『どこにAdsenseを貼ってお金を取れるか』というようなことを考えてはいけない」というような話が、最近どこかで中の人へのインタビューでの発言であったはず（多分、インタビュー対象はグーグルジャパンの村上社長）。

要するに、サイボウズラボの50%は「ビジネスに結びつく50%」だが、Googleラボの20%は「技術を追求する20%」という質の差があると。

私はその辺が判らずに面接にいったので、「50%ルールで何がやりたいですか？」という問いに対し、純粋にやりたいこととして先のエントリでも挙げたような、次世代のオープンなSNSを実現するインフラを開発したいと熱弁、一席ぶったのだが、「それをどうビジネスに結び付けますか？」といったところで、まさか50%ルールのところでその質問が来るとは思ってなかったのでまともに返答できず、しどろもどろ。
結果即落ち。

というわけで、これからサイボウズラボに応募しようと思う方は、50%ルールで何をしたいか、だけではなく、それがどのようにビジネスに結びつくか、というところまできちんと頭を整理してから、臨まれた方が吉です。
今後続く人のために一助になればと思い、１エントリ設けさせていただきました。

でも、Googleと比較しての見た目のインパクトで「20%→50%」というのを呈示しておきながら、十分な説明もなく実は判断基準違いますよ、というのはちょっとズルいよなあ、とも思ったよ。

友人そーさんの気合の入ったエントリ群。

• [identity2.0][web2.0] 次の SNS が始まっている -1
• [identity2.0][web2.0] 次の SNS が始まっている -2
• [identity2.0][web2.0] 次の SNS が始まっている -3
• [identity2.0][web2.0] 次の SNS が始まっている -4

うちでも何度か論じてきたオープンな認証インフラ等の上に築くオープンなソーシャルネットワークの可能性について、あますところなく？論じている。
ていうか、現役Webサービス開発者だけあって、アンテナも広いし、むちゃくちゃ勉強してますな。
私なんか、本業ではないので情報収集時間も限られてて...と言い訳はできるが、基本は勉強不足で、情報は収集するより自分の直感頼りで情報を作る方に偏りがち。
そーさんのエントリ読むまで知らなかった動きやキーワードもたくさんあった。反省。

そーさんとは以前、この辺に関して意見交換したことがあるんですが、実にささいな、細かい現段階での実装方法に関する見解を除いては、基本的に考えている事のベクトルは同じである事は確認しているので、その上でここまで深く考察してくれる仲間が増えたことは、嬉しいというか、心強いというか、選択する必要ないですな、両方です。
逆にうちの方が、半年か1年ぶりくらいに「位置情報萌え、ケータイ萌え」モードが強くなってきていて、それだけで手いっぱい夢いっぱいお腹いっぱい状態なこともあって、いずれは戻ってきますがその間はそーさんに任せとけば安心かなーとか何とか。
勝手なことのたまってすんません。

今日、広い自己や、ねねが、ねねたちが、EQ自己分析やってみました
自己などを判定しなかったよ
とか思ってるの。


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

なんか最近、こことかこことか、アフィリエイトの結果を晒すのが儲けにつながる小粋に流行っているらしいので、うちも報告できるレベルの成果ではないのですが、報告を。

第１位：入門Webマッピング―自分で作るオリジナルのデジタル地図

順当にぶっちぎりの第１位。自分達で出した本だから2重にうれしい。皆さんどうもありがとうございます。
しかしうちだけでなく、それなりに売れてるみたいですね。
近所の本屋では2冊入ったまま全く売れてないので、全然駄目なのかと思ってたら、オライリージャパンの担当の方に伺えば、オライリージャパン発行書籍の中で第3位の売れ行きですって。
もっとも、基準は確認しなかったのでよう判らんのですが。どの範囲の書籍で、どの期間で、とか。

第２位：Web Mapping Illustrated

原著も順当に売れております。
第２四半期中に日本語版の発売があったので、それ以前の売り上げが主ですが、日本語版発売後に買われた方も。
読むのが苦でなければ何でも原書に当たった方がよいと思うので、こちらも引き続きよろしくお願いいたします。

第３位：ふつうのHaskellプログラミング ふつうのプログラマのための関数型言語入門

風邪でも理解できる平易で判り易い本という紹介をしたところ、多くの注文をいただきました。
紹介した本人自体は、その後ほとんど触ってないので既に忘れかけという状況ですが...判り易い本なのでもういっぺん読み直してもまたすいすい入るでしょう。
そしてまたすいすいと抜けて...いやそれはあかんやろ。

第４位：アンビエント・ファインダビリティ―ウェブ、検索、そしてコミュニケーションをめぐる旅

いや、この本は恥ずかしながら、私知らなかったんですよ。
多分、どこかのページで、Drk7.jpさんのAmazon Search経由で紹介されて、それが売れたんだと思うのですが、紹介もしていないのに売れたせいでこの良書の存在に気付き、私も買うことができました。
Drk7.jpさん、そして最初にお買い上げくださった皆さん、ありがとうございました。
ちなみに、オライリージャパンの担当者さん言われるに、この本が売り上げ第1位とのことでした。

第５位：Mapping Hacks: Tips & Tools for Electronic Cartography (HACKS)

Web Mapping Illustratedと並んで、去年出たオライリー初の2大位置情報本のもう一冊の方。
これも継続して売れています。
私としてはこれも訳したかった（というより、私の守備範囲はむしろこちらなので、正直書くと私的にはこっちが...だったんですが）のですが、初めての位置情報本というだけでなく、実は両書とも、地図等をビジュアルに表示するため、初めてのフルカラー本だったという事もあり、オライリージャパンさんの方も慎重になられまして、とりあえず一冊だけ、という話になりました。
でも、入門Webマッピングの売れ行きがよければ、これの翻訳話も出てくるかもしれませんね。

第６位：WEB+DB PRESS Vol.33

雑誌ですがランク入りいたしました。
32号からの怒涛の新連載攻勢がありましたが、33号はそれに輪をかけ特集も読みどころ満載で、読み応えのある号でした。

第７位：心は量子で語れるか―21世紀物理の進むべき道をさぐる

読みかけのまま電車の中でなくした！もういっぺん買いたいのでアフィリエイトプリーズ！というあほなエントリで紹介した本です。
これだけでもういっぺん買えるほどの利益はでませんでしたが、なんとか全体でもういっぺん買ってもいいかなと思えるレベルの利益は出たので、先日やっと再購入しました。
皆さん、ご購入ありがとうございます。

第８位：Google Maps Hacks (Hacks)

オライリーの3番目の位置情報本（と言っていいのかどうか判りませんが）。
Google Maps本ですから巷では大ベストセラーだと思うのですが、うちでは意外に売れませんでした。
まあ、位置情報全般ではともかく、Google Mapsなら他に詳しい人は山ほどおられますから、うちで買わずにそちらで買われた方がいいかと思います。

第９位：Perl Best Practices

とりあえず、Perlerなら買っとけ本に、新しく名を連ねた本ですね（私、買っとけ本の多くを持ってなかったりしますが...これは買いました）。
ちなみに、うちの記事としてこれを紹介したことは、多分なかったはず...。
おそらく弾さんが紹介されたものからの注文。
本ブログの右側に、弾's　Selectionと称して弾さんがブログで紹介された本がリストされているが、ここからの注文だと思う。
これは、ブログに貼るアフィリエイト商品を充実させたいけれど、単にAmazon売れ筋ベストセラー等を貼るのでは他のブログと差別化されないので何か商材がないか考えた挙句、当代きっての読書家弾さんの紹介した本をリストしてみるかと思い立ったもの。
弾さんにお願いして許可をいただき、弾さんブログの内容を定期的にパースした結果を表示している。
弾さん、あの際はご快諾いただきありがとうございます、お陰でこうしてわずかながらでも売れております。

第１０位：Perl Testing: A Developer's Notebook (DEVELOPERS NOTEBOOK)

これもおそらく、弾's Selectionからの注文。もしかしたらDrk7.jpさんのAmazon Searchかもしれませんが。
いずれにしてもうちのアフィリエイトは、弾さん、Drk7.jpさんの2人のギークのお陰で成り立っています。
いや、リンク作成にはAmazletを使っているので、naoyaさんも入れて3人か。
本当にありがとうございます。

以上、駆け足ですが、うちのサイトでの売れ筋を紹介させていただきました。
弾さんは今回、ブレークイーヴンを達成されたそうですが、私はまだまだですね。
しかし、入門Webマッピングの活躍もあってか、大分伸びたのも事実。
皆さん、ありがとうございます。ぜひ次四半期もご贔屓に一つお願いいたします。

Where2.0好きな人の集いで話した参加者の薦めもあって、レゴマインドストーム買ってしまいました。

レゴ マインドストーム 基本セット 2.0 3804 posted with amazlet on 06.07.01 レゴ 売り上げランキング: 1,352 おすすめ度の平均: 誰でもロボットがつくれる Amazon.co.jp で詳細を見る

先週半ばに到着して、パソコン使ってプログラム転送しないと動かないので「お休みまで我慢ね」と息子に言ったところ、待ちきれなくて母親に毎日「お休みまで後何日？」と聞く始末。
今日やっと、外に出して実行してみたんですが、4歳児に買ってやるもんじゃなかったかもしれない、こりゃ大変だわ...。

とにかく、すごい数の極小パーツ群。
おまけに、チュートリアルに沿って作っていくと、結構ぎりぎりしかパーツなかったりしてる。
これまでのレゴで息子が遊んできたみたいに、なんか部品ばら撒いて好き勝手作って、飽きたら他のおもちゃに移って、みたいな遊び方してたら、あっという間にパーツなくなりそう。
というか、これまでのレゴとパーツが混ざってしまうと終わりだな...。

動かしてみると、これまた大変。
プログラム自体は、結構いろいろできて面白そうではある。
制御できるのは3入力・3出力までで、センサやアクチュエータにも限りがあるが、ループ・条件判断はもちろん変数やそれに従った制御なんかもでき、まとまった処理はコンポーネント化できるなどそれなりに高度な事ができるようになってる。
ところが...大変なのはレゴの物理構造を作るほう。
とにかく複雑だしパーツは見つからないし、で、バラバラのパーツから組み上げたら、一つの構造作るのに既に設計済みのものを手順書みながら作るだけでも、軽く1時間～2時間はかかる。
俺のPC部屋にはエアコンないので、汗ダラダラ流しながら消耗しまくり。
おまけに、例えば同じベース構造でも、センサを地面の明暗センサにしたり接触センサにしたり、動作部を車輪にしたり、虫みたいな足にしたり、クローラにしたりと色々差し替えられるのだが、しばらくクローラで遊んで、飽きてきたから車輪に置き換えようか、とか思っても、パーツがぎりぎりしかないからクローラコンポーネントを取っておくことができず、バラしてから車輪構造を作らないといけなかったりとか、とにかく苦労する。
ソフトウェアにコンポーネント作成機能があるのはいいけど、ハードもせっかく作ったのはコンポーネント化して取っておきたいんだけどなあ。
結局朝から夕方まで3作品ほど作って遊んだが、おもしろいというよりすげえしんどかった。子供はまあ喜んでたが。

とはいえ、まだ息子はPC触れないし、手順書に沿った複雑な構造は作れないしで、俺がいない時は駆動させての遊びはさせてやれない。
だからといって普通のレゴみたいに好き勝手造形して遊ばれて、いや遊ぶのはいいんだが、これまでの玩具と同様に適当に扱われたら、あっという間にパーツはなくなるは一般レゴと混ざるはになると考えると、頭が痛い。
また来週の休みまで触っちゃ駄目、だと息子のストレス爆発だろうなあ...俺も毎週これにつき合わされるのは勘弁して欲しいし。

何時頃になれば、プログラムとかの概念理解できて、レゴも自分で手順書どおり作れるようになるかな？
小学校1年位か？
それまで果たして壊さず、パーツもなくさずおいておけるだろうか...。 

北朝鮮のミサイル発射施設を見てみる -Life is beautiful-

今回の北朝鮮によるミサイル発射実験は、米国でもトップニュース。
ニュースの一つに、ミサイル発射施設の衛星写真が掲載されていたので、Google Mapでも見れるものかと試してみると、さすがにミサイルの形までは分からないが、なにやらそれらしき施設があることは分かる。

本当に、こんなもんまで見えちゃうんですよね。マジで。
インドが軍事施設が見えるからという理由でGoogleに抗議したはず（結論はどうなったか不明）だが、それもむべなるかなと。

私も、詳しい経緯は書けないけど、先日あるセミナーを受けたんですが、そのセミナーで、講師はGoogle Earthの衛星写真を使って、某NK国の首都PY近郊の軍事通信基地施設、及びそれを守るSAM（Surface to Air Missile：地対空ミサイル）の存在を画像から読み取っていました。

もちろん、この程度の情報は多分じえー隊も知っている事で目新しい情報でもないだろうし、アメリカ・日本をはじめ各国が打ち上げている軍事衛星の解像度は、Googleが衛星画像を買っている商用衛星とは比べ物にならないと思います。
でも、そのような低いレベルの衛星画像とはいえ、一民間人が見るだけで軍事施設が解析できるような代物が、インターネットに接続できる環境であれば誰でも手に入れられる状況になっていることは確か。
そりゃDigitalGlobeの衛星写真なんて、今まででも金さえ積めば誰でもどこでも見れたんだと思うけど、やっぱりタダで誰でも手に入るようになっちゃったというのが大きい。
Google EarthやMapにハマっちゃった人達って、本当に信じられないレベルで世界中をくまなく見る。見る。見倒す。
いわば、興味本位の野次馬的画像情報（IMINT）監視員が、世界中に誕生したようなもんだといえます。

もちろん、情報はIMINTだけで簡潔するもんではなく、HUMINT（人的情報）やCOMINT（通信情報）、SIGINT（信号情報）といった各種情報とマッシュアップされて意味のある情報となるわけだけれども、その点でも、今はGoogle Earthで「何か変なもん見つけた！」と2ちゃんねるででも書けば、よってたかって2ちゃんねらーが情報持ち寄ってなんだかんだと明らかになってしまうという時代。
さすがに2ちゃんねるは日本独特かも知れないが、似たような情報交換コミュニティは何処の国にでもあるだろう。
仮想敵国同士（日本の場合は北朝鮮は民間にインターネットが出回ってないので事情が異なるが）がクソ真面目に機密施設を相手の諜報機関から隠そうとやっきになってる横で、両国の一般人がお互い相手の軍事施設を探し出して酒の肴にしてるような状況がもし生まれてくるとしたら、あまりにも滑稽だと思わないだろうか。
その滑稽さに多くの人が気付いた時、人類は一つ先の智慧を進化させるのかな、という気がする。

人的に情報処理するYahooに比べ「冷たい技術」と言われることも多いGoogleだが、冷たいというより単に「無邪気」なんだと思う。
無邪気に技術の可能性だけを追求しているというか。
世界情勢等お構いなく「世界の全てをあますところなく自分達の中で表現したいんだ！」という無邪気さが、圧倒的な技術力と財力で武装されて私達の前に突き出され、「次は月だ、火星だ！」等と私達を置き去りにして突き進んでいるのをみる時、実際にはあるわけではない地上の人為的な国境、というか物理的なそれより心の中での国境に捉われていがみあっている姿が、だんだん滑稽に思えてくるのではないかと思う。
人為的な国境の無意味さが、やれ地球市民だの、人類皆兄弟だの、教条主義的な方法ではなく、馬鹿馬鹿しさ・滑稽さの呈示、という形で万人に知らしめられる。
この効果は大きい、と私は思う。

研ぎ澄まされた無垢な技術力の波が、人類の持つ最大級のドグマを打ち砕いていくのだとしたら、これほど痛快なことはないなと思う。

---- 追記 ----

流石に読み返してみて、Google Earth一つでマジメに国民国家幻想が崩壊すると思ってるようにとられると、脳みそお花畑な奴だと思われてヤバイなとオモタ。
流石にそこまでは思ってませんが、素で「世界政府というものができるなら、そのシステムは俺達が作る」とのたまう無邪気な連中がぶつけてくる怒涛のエクスペリエンス、Google Earthもその1つな訳ですが、それをさらに2つ、3つと経験していくうちに、徐々に人々の意識も変わってくるのかなというくらいの、楽観的観測は持ってます。

僕の世代は間違いなく「こちら側」に「溜め込む」世代だ。
情報と出合ったらそれを手元に残す(本屋で面白い本を見つけたらその本を買い、大切な記事はコピーし、テレビで「また見たいかも」と思うような何かが放送されたら録画し・・・)というのが習い性になっている人が多い。

Web2.0、次の時代の預言者のように思われている梅田さんが、こんな風に世代の感覚を素直に表現してくれることは、ちょっと嬉しい。
梅田さん世代ですらそのようなのだから、私の親の世代なんかになるとなおさらだろうし、また梅田さんの話題は「入手する情報」に関してだけれども、「入手情報」ですら手元におきたい世代、いわんや「発信する情報」をや、である。
「発信情報」に関しては、私でも手元に置きたい、と思ってしまう。
それゆえ、恥ずかしながらいまだにFlickrは使ったことがないし、あまり使いたいとも思わない。
自分で手元においておいても、バックアップしておらずといった間抜けなアレから、家が災害にあったとかまで、なくなる時はなくなるし、外部においておけばそれを逃れられる効果もあるだろうが、どんな理由であれそれが自分の管理の元であれば、災害にあったとかなくした原因自体が自分の歴史として積み重なる感じがする。
でも、外に預けておいて、やれシステムがとんだだのサービス停止するだので自分の大事な情報ストックが消えてしまう、というようなアレは、正直言って納得できない理不尽さを感じる。

（FlickrはFlickrで登録して利用して、オリジナルは手元で管理しておけばいいじゃないか、という意見もあると思うが、情報を一元管理できることこそ計算機の強みであるのに、なんでわざわざFlickrの管理とローカルでの情報管理、と2重管理しないといけないのかと思う。もちろん、Flickrに登録したからといってオリジナルを手元で消すわけじゃないから、データは手元に残る。でも、時間をかけて分類・整理・管理がなされていなければ、データは単なるデータで、情報にはならない。活きた情報にしようと思えば、管理しないといけない。なんでその管理を、Flickrとローカルの2重にしなければいけないのか。）

私世代で私よりもっと保守的な人や、私より年上の人は、もっとそんな傾向が強いと思う。
では、そんな人は、Web2.0の恩恵は受けられないのか？
そんなあほな、と思う。Web2.0はもっと豊穣なもんであって欲しい。
手元にデータを溜め込んだままでも、情報を公開しWeb2.0の恩恵を受ける方法はあるはずだ。
幸い、ハードウェアもネットワークも、昨今の性能向上で、個人でデスクトップユースだけで使うにはオーバースペックすぎる代物で、比較的余裕はある。
あとはソフトウェアさえなんとかなれば。

その辺のアイデアを、以前のエントリで書いた事がある。
ApacheやMySQLといった個々のサーバアプリをインストールしてその上にWebアプリを構築する、という発想ではなく、Webアプリそのものをインストールされるアプリケーションと考え、ApacheやMySQL、及びその設定をアプリケーションのコンポーネントと考えて、Webアプリとその必要とするコンポーネントをダウンロードしてインストールする、という発想。
コンポーネントは常にセキュリティホール・安全な設定等をメンテナンスされ、ユーザに意識させないように裏で常にアップデートされる。
何のことはない、基本的にはWebサービスを提供する会社なんかは、サーバ増強のスケーラビリティを考慮して、セキュリティ等考慮し構築されたサーバ構成をまるまるコピーを持ち、同じ設定のサーバを大量生産できるようにすると思うが、同じことをユーザのPCに対し行うような製品をつくるだけ。
そう考えると、こういう製品もアリだとは思われないだろうか。

残念ながら、そのアイデアを示したエントリで引き合いに出しているSpaceTag Serverは、私のこの考えをある程度理解し賛同してくれてもいたアーキテクトであった友人が、諸事情があってSpaceTag社を辞めてから、私の考えているような方向性を実現する対象としては期待できなくなった（少なくとも、その方向に進んでいることを確認できなくなった）。
今こういう方面で期待できるとしたら、Linux版は私も使っているXamppプロジェクトとかだろうか。
或いは、パッケージングの腕に覚えがある人は、自分で新しいプロジェクトを立ち上げてもいいかもしれない。

結論としては、Web2.0、Web2.0というとHTTPより上側のレイヤしか注目されていないように見えるけど、それより下のレイヤにもいろいろ可能性はあるんじゃないかな、ということで。
（ちょっと書き始めと温度差が出てしまったような気が自分でもするけどまあいいか。）

今朝、起きて出勤準備の前にちょっとメールを覗いてみたら、面白い連絡が届いていました。

ソニーコンピュータサイエンス研究所が開発中の、WiFi機器（ノートPCやZERO3）で、GPSを必要とせずにWiFi　AP情報のデータベースによって位置認識を行う技術「PlaceEngine」が、ある程度の完成度が出てきたのでWeb公開を開始したそうです。

PlaceEngine 試験サービスについて

ソニーコンピュータサイエンス研究所では、実世界指向ユーザーインターフェイス研究の一環として、Wi-Fi測位による位置認識技術 PlaceEngine の試験公開を開始し、その可能性を追求・提案しています。

試験サービス開始時点においては、東京都山手線圏内の主要商業地域を中心として PlaceEngine をご利用いただくことで、位置情報サービスのさらなる可能性を体感して頂けると思います。
また、試験サービスを通じて体感して頂いた、ご意見やご感想等を開発チームにお送りください。
よりよいサービスの向上に反映していきたいと思っています。

現在のところ、Windows/WindowsMobile(Willcom Zero-3)に対応しているようです。
特徴としては、

• GPSと異なり、屋内や地下街などでも使える
• ノートPC、PDA等、いつも使っているモバイル機器が「そのまま」ロケーションウェアになる

あたりが挙げられます。
APIの詳細は未確認ですが、マッシュアップ等も可能なアーキテクチャにしてあるとのことなので、自分のいる場所のリアルタイムGoogle Maps反映とかもできたりするのかもしれません。

私も、さすがに今日は間に合いませんが（普段ノートPC持ち歩かない人なので）、明日あたりなけなしのVAIO Uにちょっと設定して、遊んでみようかと思います。

朝準備の忙しい時間帯だったので、ほとんどメール丸写しのエントリになってしまった...すんません。

---- 追記 ----

本当によく見てなかったんですが、「自分のいる場所のリアルタイムGoogle Maps反映」とかいうより、PlaceEngineの現在地取得MAP自体がGoogle Mapsで作られてましたね。

オークニーさんが中心となって開発されているオープンソースの経路探索・ジオコーディングエンジン、PostLBSのプロジェクトWebサイトがオープンしたようです。
トップページで全体のアーキテクチャが概観できる他、ソースコードももちろん公開されています。
PostLBSがどのようなものかについては、以前デモを見てきたレポートをどうぞ。

中々気合の入った作りのサイトに仕上がっています。
特に、PostgreSQL、PostGISにあわせて象をモチーフとしたイメージキャラクターが用意されてるみたいなのですが、

ペタカワユス。

...勝手に貼り付けちゃって問題ですかね　＞　オークニーさん　すんまそん。

入門Webマッピング発刊記念＆Where2.0好きな人の集いでのプレゼン資料が、横浜スローライフさんで公開されました。

「入門Webマッピング発刊記念＆Where2.0好きな人の集い＠横浜」配付資料

29日に開催された「入門Webマッピング発刊記念＆Where2.0好きな人の集い＠横浜」で使用された資料のうち、5日現在で配布可能なものをご紹介します。
（了承をいただいたものから順次コンテンツを追加します）

こうしてみると、俺の聞けなかった前半のセッションもかなり面白そうだったみたいだなあ...聞けずに残念。
特にジオコーディングのプレゼンとか。

本当に、この小さな集まりが徐々に大きくなって、日本版Where2.0になって、懇親会の乾杯の挨拶でも言ったように、日本のGoogle Maps部隊を引きずり出せるような事にでもなったらいいなあ。
（別にオープンソースGISよりGoogleの方が上、ということではないけど、一つの時代のシンボルとして。）

久々のOpenID話題ですが、バージョン2.0仕様のドラフトが公開されているようです。
とりあえずお知らせだけであんまり中身見てないのですが、JanRainが提唱しているプロファイル交換仕様は取り込まれていないみたいですね。
飽くまでHTTPとRESTの関係みたいなもんで、基礎のプロトコルの上での一拡張仕様、という扱いなのかな。

ところで最近嬉しいのは、OpenID/Yadisのメーリングリスト上で、リッチクライアントからOpenIDを用いて認証するための議論が出始めていること。
OpenIDは今のところの仕様は、認証サーバに制御が移ってから認証サーバ上での認証が完了するまで（認証されたことをコンシューマに伝える遷移の前まで）は、そこでのログイン手順は認証サーバ任せなので、ログインフォームを表示するWebブラウザ画面が必須であり、アプリケーションの背後で認証させるというようなことができなかった。
でも、ここ数日、ログインフォーム上でのユーザ名とパスワードの受け渡し用パラメータ名を仕様で固定してやれば、リッチクライアントからWebAPIばりに背後で認証させるみたいなことができるんじゃないか、といった話題が挙がってきてる。
（今挙がっている方法がベストかは別として）その辺はずっと考えてきてたので、ちょっとウレシス。

もしその辺の仕様が整えば、後はそれに加えてYadis/OpenIDで「ログインできるサイト」のAutoDiscoveryと、ログインできるサイトに対するアイデンティティURLの受け渡し仕様あたりが決まれば、Firefoxのエクステンションなんかに自分のアイデンティティURLを登録しておく事で、ユーザに認証のための遷移をほとんど意識させることなく、自動でログインできるサイトにログインする、といったこともできるようになる。
さらに、ログインした結果によって、FOAF等で知人・友人・家族かどうか判断して、コンテンツの内容を変えられるようにしておけば、オープンな環境でSNSばりにコンテンツの流通制御ができるようになる。
（その辺の構想の詳細については、以前エントリを割いて書いている　のでそちらを参照してください。）

もう少し時間や体調に余裕があって、或いはもう少し英語に堪能だったら、議論に参加するのになあ。
でも、別に私が参加しなくても、時代は進むべき方向にきちんと進んでいるようで、ちょっと嬉しい。

アルプス社は、ご存知のとおり、アルプスラボで最近頑張ってるイメージのある地図会社で、イー・ソリューション・サービスは、IPAによるGRASSとMapServerの日本語化を大阪府立大学とオークニーと一緒に行っている会社です。

いろんなところで新しい動きが始まっているようですねー
深読みをいろいろできそうです...

確かにいろいろと裏を読めそうな感じではありますが...。

まあ真っ当に考えると、アルプス社は地図会社で、プロアトラスなんかをずっと作ってきて一般アプリのノウハウはあるわけですけど、Web方面のノウハウは、アルプスラボ等一部には蓄積されてきつつあってもまだ弱いのかなと。
親会社のヤフーはWebのプロでしょうが、こっちはGIS方面には弱いのでしょうし。
そこで、まさにMapServerなんかで、GIS on Webのノウハウに強く、またそれをオープンプラットフォームで安価に構築する力もあるイー・ソリューション・サービスを取り込んで、この方面の技術にテコ入れしていこうとしているのかもしれません。

或いは、今オークニーさんがインクリメントPさんの地図を利用したWMSサービスを開始されたりしていますが、そんなふうに、自社の地図データを買って利用してもらうのに、MapInfoを使ったシステム提案だけだと地図とツールのダブルのコスト高になってしまうので、MapServer・GRASS等の安価なオープンソースソリューションを使いつつ、自社のデータを使った提案もできるようにと、そっち方面の強化なのかもしれません。

或いは両方か、もっと他にもあるだろうし、いずれにせよシナジー効果は高そうです。

ところで、今気付いたのですがアルプスラボの新サービス、アルプスラボ・デザインは面白いですね。
まさに地図データを自前で、ベクトルでもってるからこそできるアレですな。

今日、ネットで広いおやまをBLOGしなかったよ
今日、ネットで大きいおやまや、大きいおやまなどをBLOGしなかった？
今日はねねは、広いおやまをBLOGしなかった
だよ♪


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

なんか判定ものが続いてアレですが、EQ自己分析やってみました。
結果は...

状況判断力 [57点]
客観的な立場での情報判断力はピカイチ

あなたはまずまず人並以上の状況判断力をもっています。
特にあなたの場合、客観的な立場であるほど、正しい判断ができるようです。
これまでも友人から恋愛や就職問題などについて相談を持ちかけられたときに、相手が驚くような的を射たアドバイスをして、感謝された経験があるのでは？
ただしその反面、せっかくの状況判断力も自分に直接利害が及ぶような場面ではやや鈍ってしまいがち。
「失敗したらどうしよう」とリスクを実際以上に大きなものと考えたり、逆に本来なら危機を感じなければいけないような局面でも楽天的にのんびり構えたりしやすいのです。
そのためあなたは、アドバイス上手ではあるけれど、実際に自分に関することでは読みがはずれるケースが少なくないよいうです。
ある程度、優れた状況判断力を持っているのですから、欲に目がくらんだり悲観的になりすぎたりせず、自分自身に対して客観的な立場から結論を下す姿勢が大切といえます。

感情制御力 [49点]
表面はクールでも内面はすぐに動揺しがち

あなたはまずまずの感情制御力をもっています。
特にあなたの場合、少なくとも表面的には怒り、悲しみ、喜びなどあらゆる感情を上手にコントロールすることができるでしょう。
どんな難題にも冷静に対処するように見えるあなたの姿は、周囲の人から尊敬を集めているかも知れません。
ただしそれは、あくまでも他人から見ての場合。
一見クールに見えるあなたですが心の中は人一倍ナイーブで、悲しみや怒りといった感情にとらわれやすいのです。
だから悲しい出来事があったりすると、表面はふだんとかわらなくても仕事の能率がガックリ落ちたり、つまらないミスや勘違いが増えたり・・・・・ということになりがち。
どんなにつらいときも自分を見失わないだけの「精神的なタフさ」を身につけるｌことが、あなたのこれからの課題といえるでしょう。

意志実行力 [24点]
予想外の事態にぶつかるとすぐに弱気になりそう

あなたは意志実行力が必ずしもないというわけではありません。
ただ計画を練ったり準備を整えたりするのにやや時間がかかりすぎるため、要領よくチャンスをものにする・・・・・というわけにはなかなかいかないようです。
さらにあなたの場合、少しでも予想外の事態にぶつかると、弱気になってしまいやすい面もあるようです。
計画を遂行する自信がなくなって、自分から身を引いてしまうことがすくなくないのです。
これまでも、たとえば好きな相手にライバルがいることを知って恋をあきらめたり、予想以上に資金がいることをしって独立を断念したりという経験があるのではありませんか？
目の前にちょっとした壁が立ちはだかったときは、それにあえて立ち向かっていくだけの強気な姿勢が大切だといえます。

対人共感力 [66点]
世渡り上手だけれど八方美人になりやすいかも

あなたの対人共感力は比較的高めです。
頭の回転が速いあなたは、相手の気持ちをすばやく読むことができるので、初対面の人を前にしても相手が喜ぶようなお世辞をくちにしたり、共通の話題をすばやく見つけたりして、すぐに打ち解け合うことができるでしょう。
そんなあなたは、老若男女を問わず、親しい人の数はかなりの数にのぼるはず。
ただしあなたは、たくさんの人とうまくやっていくことに気を取られやすい傾向があるようです。
そのためどうしても「広く浅く」のお付き合いが中心になって、困ったときに助け合えるような親友がなかなかできにくいのです。
またいろいろな相手に笑顔をふりまくので、「八方美人」といった評判もたちやすいようです。
多くの人に気に入られることも大切かもしれませんが、「この人」と思える相手に対して持ち前の対人共感力をフルに発揮して、とことん親しくなるように努力することも大切といえます。

総合診断 [タイプＨ]
人気は高いけれど「八方美人」といわれるケースも

状況判断力と対人共感力の２つのテストでなかなかの高得点を記録したあなたは、一言でいってだれからも好かれる明るい性格の持ち主。
初対面の人の前でも緊張したりせず、自分から話題を見つけて積極的に話しかかることができるので、友人や知人の数も人一倍多いことでしょう。
そうした友人を通じて仕事に役立つ情報がもたらされたりすることも多く、幅広い人脈はまさにあなたにとって最大の財産といえます。
また女性の場合も、老若男女を問わずみんなに好かれ、どんな場でもアイドル的な存在になれるはず。
細やかな気配りもでき、ギャグやジョークも得意。
少なくとも人間関係という点では完璧なあなたですが、それだけに風当たりが強くなるケースもあるので要注意。
あまりみんなに笑顔をふりまいたり、有力者にお世辞ばかりいったりしていると、「八方美人」「媚びている」などと陰口をいい、足を引っ張る人物が出現します。
またあなたの場合どうしても人脈を活かして成功を手に入れるケースが多いので、まっとうないみでの「実力」が身につきににくいのです。
ですから陰口をいわれたりしないためには、それなりに努力を積み重ね、ひとりでも何とかなるくらいの実力を身につけることが大切です。
恋愛に関しては、「こんな相手でなければ」といったこだわりがほとんどないタイプのようです。
見の回りにいる異性の中から、うまくつき合えそうな相手や自分に好意を抱いていそうな相手を選んで交際する・・・・・という感じかもしれません。
理想はそれほど高くないし、周囲に異性が少ない場合には友人からの紹介もあり、これまでも恋人が見つからず苦労した経験は少ないのでは？
ただしあなたは、もともと異性の友人が多いため、嫉妬深い相手とつき合うと必ずといっていいほどトラブルに発展してしまうようです。
相手が独占欲が強いタイプの場合は、異性の友人とのつき合いはセーブしたほうが無難。
またその場の勢いで結婚してしまい後悔してしまうケースが少なくありません。
未来の夫選び、妻選びに関しては慎重に検討することが大切です。

状況判断力と対人共感力が高い、というのはともかく、感情制御力は高くなく意思実行力は低い、というのはかなり当たっている気も...。
元がそんな性格の上に、2度も転職で失敗（2度目は失敗かどうかまだ判らないが）してしまうと、中々次の動きに出ようという勇気が出ないのも事実。
総合評価の「またあなたの場合どうしても人脈を活かして成功を手に入れるケースが多いので、まっとうないみでの「実力」が身につきににくいのです。
」というのも、おっしゃる通りとしか言いようもなく。
「理想はそれほど高くないし、周囲に異性が少ない場合には友人からの紹介もあり、これまでも恋人が見つからず苦労した経験は少ないのでは？
」これは全然当たらないっす...全然モテず恋人には苦労してまいりますた...女友達は（昔は）多かったんですが、それ以上にはどうしても進めず。

新田議長は当初、「いけんものはいけん」と取り合わず、「竹島問題」にも言及。
さらに「そんなに選挙権がほしいなら、帰化すればいい」と発言したという。

民団側は「人権問題だ」とその場で抗議したという。　抗議文では「前回の対応を反省し、発言の撤回と謝罪を求める」としている。
朴団長は「われわれの民族性を抹殺する差別的な発言であり、容認できない」と話している。

広島の議長の言いようもアレだと思うが、民団もなんでもかんでも人権問題だと言えばいいってもんじゃないだろうって気がする。
議長の言葉にも、一面の真実はある。俺とは全然違う見地から発言してるだろうけど。

というか、いつまで地方参政権問題ってやってんのか。
10年前から何の進展もないやんけ。
問題は同じように日本で生まれ、日本の言葉と文化で育てられ、日本に税金を納めている連中が、権利の面で差があることが問題なんやから、本来は地方参政権どころか国政参政権だってあって当然の話だ。
しかし住民自治が原則の地方参政権と違って、国政参政権にまでなると明らかに国民と明記されているから、法律をどこをどうひっくり返したって外国籍のまま認めることなど不可能だ。
そうなると、在日韓国・朝鮮・台湾人（以下在日）の参政権問題で根本的解決は、10年前からそう思ってるが、在日の帰化以外にはあり得ないと思うんだが。
帰化という言い方でアレなんなら、国籍取得しての在日韓国人→韓国系日本人化だ。
とは言え、根本的解決にはならないのは承知のうえで、日本の社会側の受け入れ準備が整わない状況での中間マイルストーンとして、日本側社会へのアピールの意味もこめ、地方参政権要求はアリだとは思ってた。
でも、その中間マイルストーンすら、10年経っても達成できないのであれば、搦め手はやめて一気に本丸（在日の国籍取得）攻めに意識改革してもいいと思うんだが。
（もっとも、地方参政権取得活動家連中は、地方参政権こそ本丸と考えているんだろうけど...その時代錯誤性にがっくりくる）

日本国籍を取得すれば、民族性が圧殺されるなんて大嘘だ。
実際、誰よりも民族性を重んじている、京都時代にお世話になった京都ハンマダンの朴実さんだって、日本国籍だ。
もちろん、今の日本の国籍取得では（といっても10年前の温度しか知らないが）、国籍取得の過程において、すさまじい同化圧力がかかることくらいは知っている。
先に述べた朴実さんだって、国籍取得後に民族名を取り戻すために活動して、苦労して本名を取り戻されたことも知っている。
でもそれだったら、そういう日本の帰化行政の歪みをこそ訴え是正していくべきであって、わざわざ外国籍のまま地方参政権取得などと搦め手の活動をえんえんと続けて何になるというのか。
10年以上も活動してくりゃ、日本の社会が、特に右ってる連中なんかが何に拒否反応を示すかくらい判ってるだろうに。
どこまで議論したって、外国籍のまま、ということに社会のビットが立って、ネットウヨやこの議長なんかが「参政権欲しければ帰化しろ」等と合唱するのならば、それを幸い、それを逆手にとって日本の帰化行政を槍玉に挙げ、俎上に上げ、是正し、一気にみんな韓国系・朝鮮系・台湾系日本人になってしまえばいいじゃないか。
それを、所詮搦め手の活動を本来の目的のように勘違いし、国籍の取得＝民族への裏切りみたいな馬鹿馬鹿しいドグマに捉われて視野がせまくなってるから、そういう激的な方向転換とかができなくなっているんじゃないか。

俺がもし、総理大臣にでもなってこの問題の根本解決策を取るならば、まず全ての在日及びその末裔の国籍について、56年のサンフランシスコ平和条約後、日本政府が半島・台湾出身者に対し、故国に戻る意思があるか日本で暮らし続けたいかの意思を確認せず、全員一律に日本国籍を剥奪した措置をいったん白紙に戻し、一人ひとりに日本国籍となるか、先祖の国の国籍となるかを選択させる。
その上で、日本国籍になることを選んだ者に対しては、やれ何ヶ月間の品行方正チェックだとか、日本名への変更だとか、そんな条件を一切つけず、日本国籍を認める。
先祖の国の国籍となる事を選んだ者については、その選択を尊重するが、ただし以後、地方参政権であろうとも、要求したり口出しすることを許さない。
極端な話、犯罪等を起こして一般の外国籍の者ならば国外退去となるような事例に対しては、同様に国外退去とさせるようなくらいしても構わないと思う。

ただ、こうやってある時期で個々人に選択させたとしても、その際に先祖の国の国籍を選択した者に子供ができ、その子が大きくなると、また同じ問題が再燃する。
よって、日本の国籍取得基準を、血統主義ではなく出生地主義にする。
要するに、アメリカ等と同様、日本人の子供を日本人とするのではなく、日本の地で生まれて育った子を日本人とする、という基準に切り替える。
ただし、この方法だと、またぞろ「民族厨」な人々に、日本国籍を強要するものだなどと反発を受けるかもしれない（わざわざサンフランシスコ平和条約後の措置を白紙に戻したにも関わらず、日本国籍を選ばないくらいなので、相当の民族厨が濃縮されると考えられる）。
いや、そういう反発も一理はあって、どんな選択であれ「一律処理」というのは個人の価値観をないがしろにするものなので、一律出生地主義というのはラディカルすぎるかもしれず、選択式にすべきかもしれない。
しかし、いくら親が民族厨だからといって、子供の生きる選択肢を狭める事は許されないと思うので、その選択をするのは親ではなく子供本人だ。
現在、日本人と外国人の間に生まれた子が20歳まで2重国籍で、20歳になって自分の意思でどちらの国籍にするか選ぶのと同様に、日本で生まれた外国人の子も、20歳まで2重国籍とし、20歳で日本人となるのか外国人となるのかを、選択させた方がよいかもしれない。
その意味では、一律日本人！の厳密な出生地主義ではなく、日本で生まれた子は日本人となる権利を有する、くらいの緩やかな出生地主義がよいかもしれない。

俺は、在日の権利問題の大半は、ここに挙げた

• サンフランシスコ平和条約後の一律外国人化
• 日本の国籍の血統主義

が元になっていると思う。
サンフランシスコ平和条約後の一律外国人化については、韓国・朝鮮人の方からそれを求めた、という話もある。
そういう活動があったのは事実だし、ある程度の人間が日本国籍を離れて父祖の国の国民になることを望んだのも確かだ。
しかし、日本に留まって日本で暮らし、日本の土となろうと考えていた人も少なからずいたと思うし、むしろ俺の印象ではそういう人の方が多数派だったのではないかと思う。
それに対し一律に国籍剥奪の処理をし、その後も国籍取得時の同化圧力や血統主義等で再日本人化の敷居を高くしたことが、この問題の（日本側の）根本原因であり、それを一旦チャラにしないことには、解決しないだろうというのが俺の持論。

日本人側からも在日側からもいろんな面で反発買うかもしれないが、この辺論じたことしばらくなかったので、10年ぶりくらいに持論を展開させてもらった。

やってみた。

あなたの一般常識の総合正解率は96.0 ％です

たいへん優秀な成績です。
就職試験などで課せられる一般常識テストでは良い結果を得られると思います。

これまでテストを受けた人の平均正解率（あなたの成績を含む） 53.6％

あなたのジャンル別の成績

ジャンル 正解率
政治 90.0％
経済 100.0％
法律 100.0％
歴史 100.0％
国語 90.0％

100とれたとこでもかなり悩んだ問題はあるので、選択でなく筆記式だったらまず間違ってた。

ちなみに間違ったのは、国連の規約のとこと作者選択のとこの1問。
俺が選んだのは「大地」の作者だった...。

モーバイルインフォサーチ実験というのをご存知だろうか。
NTTソフトウェア研究所（現在は解散？）が1997-98年頃に実施した、ある位置周辺のWeb情報を検索できる検索エンジンの実験サービスで、kokono.netというドメインで運営されていたサービスだ。
WWWをクロールして得たHTMLのテキスト情報の中から、住所記述をマッチングして、逆ジオコーディングをかけて経緯度情報を付加したものをインデクシングして、本当に「ある場所周辺の情報を持つWebページ」を検索できるという、98年代に行われたとは思えない先進的な実験だ。
主体運営していたNTTソフトウェア研究所がなくなったことで、データの更新等は行われていなかったが、私が位置情報に興味を持っていろいろ考え始めた2001年頃にはまだ動いてはおり、その先進性に刺激され、インスパイアされてきた実験だ。
その実験結果をまとめた論文の載っている

情報検索とエージェント

posted with amazlet on 06.07.01

河野 浩之 北村 泰彦 山田 誠二 高橋 克巳
東京電機大学出版局 (2002/03)
売り上げランキング: 91,922

おすすめ度の平均:

古い
情報検索の今後を考えるヒント
背景をしる、研究の足がかりとして読むのに最適だとおもいます

Amazon.co.jp で詳細を見る

あたりは、 長らくここギコでいろいろ考える上でのバイブルのような役割でした。

今回、入門Webマッピング発刊記念＆Where2.0好きな人の集いにおいて、上記実験の実行者でもあり、上記本の執筆者でもある、NTTの高橋克巳先生が来てくださっていて、驚いてしまいました。
専門書？の著者なので研究者然とした固い方を想像していたのですが、すごく気さくで楽しい方で、ここギコからのリスペクトは以前から気付いてましたよー、というありがたいお言葉をいただきました。
位置情報や仕事の話から、私の家の近所のカリスマCDショップ？の話まで、いろいろ面白い話をたくさんさせていただきました。
中でも、高橋先生がモーバイルインフォサーチ実験に取り組まれたきっかけが、NTTパーソナルで端末の位置情報を提供し始めたこと、という話を聞いて、auのGPSケータイ発売を機に位置情報の世界に飛び込んだここギコ！と重なって、大先達といえども、トリガされるきっかけとかは同じなんだなーと非常に親近感を感じました。
また、当時は投影法変換のライブラリなんかもない時代、経緯度情報を地図の上に貼り付けたりするのにも、全部自分で計算したりして大変でした、なんて話も聞いて、私も今のようにGoogle Mapsなんてなかった時代にいろいろやって、苦労してきたわけですが、こと位置を扱うという事に関しては既にPostGISやMapServerも存在してた時代なので、やはり先達には後進には判らない苦労があるのだなあとの感慨も受けました。

しかしまあ、今回、大先達の高橋先生からはリスペクトありがとうございますーみたいな話も聞き、一方で若い今まさに色々位置情報サービス作ろうという方達からは、いつも参考にさせてもらっています、勝手にお世話になってます等といろいろ言っていただいたりと、何か必要以上に持ち上げていただいちゃったんですけど。
実際にはWeb位置情報検索の歴史で大きな金字塔を打ち立てたモーバイルインフォサーチや、今現在手を動かして築かれようとしている新しいサービスに比べて、私なんて本当に何もしていないんですが。
でもまあ、自分では本当に何もせずジタバタもがいていただけ、という感じなんですけど、モーバイルインフォサーチで打ち出された位置情報に対する想いを、断絶させることなく引き継いで、オープンソースとGoogle Mapsというソリューションが出てきた時代にその想いを受け渡した、という意味では、私の存在価値もあったのかなと。
...なんて書くともう引退したお爺ちゃんのようですが、私だってまだまだやりますよ！（多分）みんながびっくりするようなもん、いつか作り上げますからね！（万一）

かくいう高橋先生も、まだまだこれからやっていかれるようで、今は位置情報とは違う仕事をやられているようなのですが、NTT社内若手の中にも「どうしても位置情報やりたい！」という熱い人達がいるようで、その人達が（伝説の？）高橋先生のところに話をもってきて、あたらしい位置情報サービスを立ち上げられるそうです。
その実際に動いているデモを見せてもらいましたが、FOMA向けiアプリで、iエリア情報から地域内の駅を選択し、そこから地図ナビゲーションUIに移行して、周辺のタウンページ登録の店舗情報を地図上で検索できる、というものです。
苦労したけどこだわったという、auのEZナビウォークでもまだ実現していない地図のスムーススクロールが中々いい感じでした。
久しぶりに取り組んだ位置情報プロジェクトということで、高橋先生も非常に嬉しそうというか、子供を見るような目で、いろいろと熱く説明されていました。

実際には次の月曜日、つまり7月3日にリリースされるサービスという事で、ここで取り上げるとフライングになってしまうのですが、サービスの名称も書いてないし（というか確認忘れた）、このくらいのフライングは許されますよね...。

高橋先生、どうぞこれからもよろしくお願いいたします。

入門Webマッピング発刊記念＆Where2.0好きな人の集いで話をさせていただいた某地図屋さんのお話。
面白かったので、記事にさせてもらう。

ゼンリンが地図を提供したことで、Google Mapsが日本に上陸したことは、やはり日本の地図業界には黒船来襲のような出来事だったようで。
最初のうちは、なんで地図を提供したんだと、ゼンリン吊るし上げのような状況だったらしい。

だが、そのうち地図業界の考え方も変わってきつつあって、地図そのものを公共財というか、もっと進んで集合知として育てよう、という気運、コンセンサスが徐々に出来つつあるらしい。
お話をされていた人の言葉を借りると、「地図のWikipedia化」みたいなことを言われていた。
以前レポートした、アルプス社の口コミ地図更新実験なんかも、その辺の波の一環なのかもしれないなあ...と思った（ちなみに情報提供者はアルプス社の方ではありません）。

また面白い話では、実際の例として、韓国のかなりのシェアを占めるトゥインクル・リトル・スターという地図会社（帰宅後ググってみましたが、多分ここみたい）では、既にユーザから「地図のここが変わっているよ」と連絡があると、修正専用のアルバイトがその場でササッと直してしまう、というようなことが実現しているとの事。
厳密な正確性を求めてきた日本の地図会社の発想では信じられない発想ですが、「もし間違ってたらどうするの？」という疑問に対しては、「間違ってたら、誰かが報告してくる。そしたらまた直せばいい」という発想だそう。
うーん、まさにWikipedia。
そして、日本もそのうちそういう方向に行きそうです。

位置情報を扱う上での基礎インフラとも地図ですら、こんなダイナミズムが導入されそうな時代になってきました。
ここギコのバイブルの一つ？としてこれまで何度も引用してきた、2003年の六本木のモブログカンファレンス時のモブログの神の発言、

「自分が訪れた素晴らしいパブ（居酒屋）の情報に、GPS機能を持った携帯電話を使って、地図情報を一緒につけておく。
そうすれば街を歩いていた人がその店の前を通ったときに、雑誌の情報ではなく、本当に人が良いと感じた情報を手に入れることができる。
これは街の生活を変える」

が実現可能になる時代は、もうそこまできているかもしれません。
そして、携帯の地図で街を歩いていておかしいところを見つけたら、その場で携帯GPSで位置を取って、携帯カメラで周辺写真を撮ってアップすれば、即座に状況が地図にアップデートされる、というふうになっていくのでしょう。
すごく楽しみな時代になってきました。

入門Webマッピング発刊記念＆Where2.0好きな人の集いでオライリージャパンの担当の方から教えていただいたんですが、

米オライリーが季刊で出している雑誌のひとつに、「Make:」という一風変わった雑誌があるそうです。

実際に手を動かして、ビデオなんかをバラして部品とったりしながら、いろんな電子ガジェットを自分で作ってしまおうという雑誌で、その作る対象も、R2D2を作ってみよう！とか、

古いATARIを改造して、PCの筐体にし、ATARIのゲームのエミュレータを走らせて遊ぼうとか、

マウスを改造して明るいところを探して走る自走ロボットを作ろうとか、中々クレージーな企画ばかりのおもしろそうな雑誌です。
雑誌のブログもあるみたいです。

で、なんでも、これの日本版が、この夏オライリージャパンから発売されるとのこと（※許可いただいて紹介してます）。
これまでの英語版「Make:」の中で、おもしろそうな記事をピックアップして和訳したものを、8月末に出すとのことでした。

発売：2006年8月末
版型：B5変形（英語版と同じ）、176ページ（フルカラー）
予価：1,525円（税込）

とりあえずは日本では続けて出す計画は今のところなく、最初の売れ行き次第、ということですので、この面白い雑誌が日本でも定着するよう、皆さん出たら買いましょー。

特に子供のいる皆さん、ぜひ子供に電子工作の面白さを植え付けて、理系離れの傾向を食い止めましょう！
その意味では、飲み会の場である参加者の方とも話したのですが、

レゴ マインドストーム 基本セット 2.0 3804

posted with amazlet on 06.07.01

レゴ
売り上げランキング: 1,352

おすすめ度の平均:

誰でもロボットがつくれる

Amazon.co.jp で詳細を見る

レゴ・マインドストームなんかも、子供の電子・情報教育用として面白いんじゃないかなと思います。
売り切れ続きで中々入手できない感じですが...。

既にあちこち（moriさん、たくぼさん、とおやまさん、Asialさん）で言及済みですが、入門Webマッピング発刊記念＆Where2.0好きな人の集い＠横浜、参加して参りました。
いやあ、ミニWhere2.0を目指そう、みたいな掛け声を挙げてはいたものの、急でしたしパネラーも集まらないだろうと思っていたので、私としては昔何度かやった位置情報マニア飲み会にLightweight Language系カンファレンスのライトニングトークに毛が生えたようなもの、くらいのイメージだったのですが。
どうしてどうして、プログラムが発表されてみると、むちゃくちゃ熱そうな話題ばかり。
たった2週間ほどの準備期間でこれだけのイベントを形にできるという、幹事を引き受けてくださったmoriさんをはじめとするオークニーの皆さんの、人脈の広さと企画・行動力に脱帽するばかり。
また、実際に参加してみても、熱い話題あり意外な出会いありの、予想通り非常に楽しく有意義な時間となりました。

私が仕事の都合でどうしても遅れざるを得なかったため、訳者プレゼンを強引にジオセンス小林さんの後に移していただいたのですが、案の定間に合うことはできず、ジオセンス小林さんのプレゼンの最後1分くらいのところで潜り込ませてもらいました。
途中から参加しても、会場の楽しそうな雰囲気はすぐ伝わってきました。

少しの休憩の後、50音順だ！とかでいきなり私の訳者プレゼンだったのですが、熱い話の中でなんか一人だけアホアホプレゼンさせていただきました。
が、まあそれなりにウケてくださったみたいで、一安心。
続いてたくぼさんのプレゼンは、さすがGISerらしくDebianGISの紹介。
天文マニアの丹羽さんのプレゼンは、皆既日食のビデオとGoogle Earthを用いての、日食鑑賞で世界を旅した経験とそれにまつわる地図の話題。
計算で出した日食予測の結果をGoogle Earthに重ね合わせたりされていましたが、それによると日本では2009年に種子島付近、2035年に北関東で皆既日食が見られるそうです。
真野さんは、オークニーさんの新しいサービス、GISデータネットワークの紹介。
森さんは、オークニーの理念の紹介と、オークニーの日常や周辺のコミュニティとの交流風景を写真を交えて紹介。
皆さん特徴あるプレゼンで面白かったのですが、一つだけ不満とすれば、多分一人頭5分の持ち時間守ってたの俺だけじゃね？
来る途中の電車の中、かなり必死に5分に収める脳内練習して、繰ってたはずのヒトねたフタねた削ったりしたんだけど、出してたらよかったかなあ。

訳者プレゼンに続いて本プレゼン。
Asialの森川さんは、オープンソースGISに出会うまで、出会ってからと、それを使って地図日記サービスを立ち上げられていかれるまでの過程を紹介。
しきりに、PostGISも、MapServerも、PHP MapScriptも、触ってみると簡単、簡単とおっしゃられていましたが、結局アプリを作った経験のない私が言うのもなんですけど実際取っ付きにくそうなんだけど、やってみたら意外にそんな難しくないんですよね。
PHPコミュニティとも大きな繋がりがあり、今後MapScriptを啓蒙していかれるそうなので、Lightweight Language - GISerの裾野が広がっていく事を期待。

たたみラボの皆さんは、リクルートのWebAPIサービス（そのうち、位置情報にマッシュアップできるのはじゃらんnet 宿表示APIとフロム・エー ナビ APIのよう）の紹介と、そのAPIを使ったマッシュアップ事例のコンテスト（現在エントリ受付中）の紹介。
最優秀賞金は50万円だそうですが、面白いのはSunのワークステーション1台とDukeマウス30台（1人に！）がもらえるというサン・マイクロシステムズ賞。
あまりのツッコミどころに会場騒然。
最優秀賞よりそっちのが狙いたかったり...どうすれば狙えるのかね？賞品がウケ狙い？なので応募作もウケを狙えばおｋ？

防災科学研究所の太井さんは、災害情報の速報等を一般に公開していく計画について紹介。

なかなか太っ腹で、写真のような全国の災害危険度を示したA1サイズの地図3枚、及びそのDVDを、全参加者に配ってた。アリガタス。
プレゼンは研究所の提供できる情報を、どんな形で一般利用できるように発信していくかについての、5ヶ年計画を紹介されていたのだけれど、システム構成図とか入った気合の入ったプレゼンだっただけに、プレゼン資料が見にくい位置にいた個人的には残念。

と、いずれも熱いプレゼンの時間は終わりまして、場所を移して飲み会の場へ。
僭越ながら乾杯の音頭をとらせていただき、宴は始まりましたが、みんな動き回りあちこちで熱いネタが飛び交う、プレゼン以上に楽しい時間となりました。
個人的にいろいろ面白い出会いや情報収集もあったのですが、個別エントリーで語らせていただくとしまして、全体的なネタとしては、オライリーの担当者さんが参加者への景品にでも、ということで色々オライリーグッズを持ってきてくださいまして、みんなでじゃんけん大会で奪い合い、というのがありました。
私は見事に？勝ち進み、最初から狙っていた「アンビエント・ファインダビリティ」のTシャツをゲットしました！

ところが、残念ながらサイズがMサイズ！LLでないと着れない私では着れず、仕方なく家内にプレゼント、ということに。ペタカナシス。

という感じで、非常に盛り上がり、次への繋がりを期待させる会になりました。
この勢いで続けていければ、本当にいつの間にか、日本版Where2.0に進化していた、なんてこともありうるかもしれません。