私には、GoogleマップはGoogle検索に近い、かなり素直なモデルだと思えます。

http://maps.google.co.jp/maps?f=l&hl=ja&q=%E5%AF%BF%E5%8F%B8+%E5%B9%B3%E7%9B%AE&near=%E5%B8%82%E3%83%B6%E8%B0%B7&ie=UTF8&z=14&om=1 とかやってみると、クロールした情報を表示しますね。

ほんとだ、レビューが表示されますね。知りませんでした。
いろいろ試してみましたが、どうもクロール情報の中から、店名、住所、電話番号をキーにして、複数一致すればその店のレビューとして対応させているみたいですね。
おもしろい（？）のは、検索ワード外のキーワードが含まれるクエリに対しては、飽くまでWebページの中だけとキーワードマッチングさせて、店自体が持つカテゴリ情報とはマッチさせてないっぽいところ。
だから上のクエリでトップにくる「天孝」さんとか、天ぷら屋さんっぽいのに、レビュー記事が1ページの中で天ぷら屋と寿司屋両方紹介しているので、「寿司 平目」でトップに来てたりしてるｗ。

これはこれですごいし面白い技術ですね。
でも、やっぱり、私にはこれはテキスト検索におけるアプローチとは異なる気がします。
だってこれ、クロールして住所があったWeb情報を全て表示しているのではなく、明らかにゼンリンの店情報だかインターネットタウンページだか知りませんが、飽くまでその情報があった基盤の上で、それに紐付けたレビュー情報として提供していますよね。
つまり、Googleが内部に「コンテンツとして持ち始めた」お店・サービスデータベースに登録済みのお店・サービスに紐付けられる情報でなければ、検索結果に挙がってこないという事を示してます。

これがテキスト検索であれば、Googleにとって何の意味か判らないバズワードであっても（たとえば「ゴッゴル」とか）、Web上でその言葉が爆発的に使われるようになれば、（RSS検索とかには速度で負けるにしても）数日後にはGoogleで検索できますよね。
でも、ローカル検索でのGoogleの現在のアプローチだと、新しいむちゃくちゃ旨いラーメン屋がどこかにオープンして、レビューがネット上に飛び交って、1万件のレビュー記事が溢れたとしても、そのままではローカル検索に挙がってこないわけですよ。
そのラーメン屋がGoogleが使っているお店データベースの提供元に情報を提供して、Googleが定期的にそのお店データベースの情報を更新して、はじめてGoogleローカル検索に挙がってくるようになるというわけです。
極端な話、1万件のレビューが飛び交う名店でも、その店の店主がお金を出すのを惜しんでお店データベースに登録しなければ、Googleローカル検索には挙がってこないことを意味しています。
実例として、五反田においしいスペイン料理屋「ジローナ」というところがあって、もうできて2年近くなるのですが、「五反田 スペイン料理」検索でGoogleローカル検索には挙がってきません。
「五反田 ジローナ」検索で、なんとか他の店のレビューと同じページにレビューされているのが検索される事を通じて、情報が出てきます。
1万件というわけではありませんが、きちんとネット上にレビューが存在しているにも関わらずGoogleローカル検索にひっかからないのは、Googleが内部にお店・サービスデータベースというコンテンツを持ってしまったことの弊害だと考えます。

それ以外にも、このようにお店・サービスデータベースをキーとする検索しかできないことによって、お店・サービス以外の属性を持つ位置情報（例えばイベント等）が検索されないというのが、あまり面白くないなあと思います。
例えば、私は近日、井草の方で狂言を演じさせていただくのですが、この狂言イベントの情報なんかは、たとえ記事内に住所を記述していたとしてもローカル検索では検索できないということですよね。
「位置情報で検索されるものは、お店・サービスのみ」と勝手にGoogleが枠をはめているような感じがします。

というわけで、やっぱり私にはGoogleローカルのアプローチは、テキスト検索におけるGoogleのアプローチとは違っていて面白くない。
純粋に位置情報をキーにした野良Webデータを集めまくって検索してくれるサーチエンジンが欲しいなあと思います。

あとAdWordsもやっています。
http://maps.google.com/maps?f=q&hl=ja&q=tampa+steak

これも知りませんでした。
お恥ずかしい。
いずれにしろ、結論としてはやっぱり今のアプローチは不満、ということになるんですけど、ちょっと事前の確認不足でしたね。

先のエントリにいただいたトラックバック：

[Google][etc]日本の住所表記とGoogle Map/Earth (Inertial Inertia -慣性という名の惰性-)

日本の住所表記は平面状の全ての点に何らかの住所が割り振られる必要があるわけだが、欧米のほうは道路の周り（というか道路のみ）さえ地図に書き込めばいいだけだ。しかも日本の住所の「丁目」とか「番地」の割り振りにはたいした法則性はない。必ず北東から南西方向に番号が振られるとか決まってないし。対して欧米のほうはとりあえず通りの起点の向かって左側をとりあえず「１」にしてあとは適当に番号を振っていって、通りの終わりにきたら今度はそっから道路の右側に番号振っていって終了と。

知らなかった...勉強になりました。
細かい規則はともかく欧米では道路の周りに数えていった順の住所がつく、くらいは知っていたのですが、そうして決まった住所名称自体は日本と同様に特定の平面領域全体を占めており、またそうして命名された住所平面によって、国土全体は覆い尽くされているものだとばかり思っていました。
そうすると、もしかして欧米では、道路から遠く離れた平原中の1点や山脈中の1点なんかには、対応する住所がない、というようなことにもなるのでしょうか。
いやあ、日本国内ローカルの常識に完全に捉われていました。

その意味では上記エントリの

Webクロールして住所を抜き出しジオコーディングするためのライブラリの構成

なんてのは日本のほうがやりやすいのかも。

とはいえジオコーディング自体は、日本でも欧米でも、基本的に住所という「テキスト文字列」に対して、1組の経緯度という「点＝0次元情報」を紐付ける作業です。
もちろん、日本では原理的には、住所に対して平面ポリゴンを紐付けることも可能なわけですが、ポリゴン渡されてもあまり使い出もなく渡された方も困惑するだけなので、一般的にジオコーディングというと日本でも住所平面中の代表点を渡すことになっています。
ということで、特定の文字列に対し特定の1点を返す、という点でジオコーディングの定義自体は日本でも欧米でも同じなので、特に欧米でジオコーディングが難しいということはないと思います。
実際、Google Maps APIでは欧米のジオコーディングに対応していますし、ということは住所文字列と経緯度点情報の紐付けは可能という事です。
なので、今度はその住所文字列を含んだWebページをクロールで見つけてやって、経緯度に紐付けられた情報としてデータベースに格納するということは、日本でも欧米でも十分に可能です。

ただ、日本では既に「MAPCODE」というサービスをデンソーがやっている。このMAPCODEは、日本中をメッシュ化してそれぞれのメッシュに独自のコードを付与しているサービス。これ使えば一応住所と緯度・経度の変換は擬似的に可能*2。これをラスタデータの地図上に植え付ければ一歩先んじることは可能かも。さらに言えば電話番号からもMAPCODEへの変換は可能なはず（タウンページとかに載せてれば）。デンソーははやいとここの規格をパブリックドメインにすべきだと思うがな。その際は緯度・経度情報も併せて開示することが必要になるんだろうが。

ま、そのうちGoogle様は地球上の４次元座標に固有IDをふっていただけると思われるので、MAPCODEはローカル規格で終わるんだろうなと。あー、結論を無理やりつけるとすれば、日本の住所表記は実はGoogle Mapと親和性が高いじゃないの、ということで。

MAPCODEはそもそもが日本国内だけでしか定義できないので必然的に日本ローカルで終わっちゃいますね。
拡張する余地はあるのかな？よく判らないけど。でも、そうなると世界中の大都市間で短いMAPCODEの奪い合いになりますね。
4次元は定義できないけれど、高さ、時間は考慮に入れない2次元の固有IDならば、以前も紹介した私の友人がやっている全世界対応の覚え易い位置特定コード仕様、「Locapoint」をどうぞご贔屓に！！

つらつらと考えていて、タイトルに書いたようなことに気付いた。

これまで、Googleはコンテンツを持たない企業として知られてきたのはご存知のとおりである。
そりゃ、インターネットをクロールして得た膨大なキャッシュ情報は内部に持っているわけだけれども、それは飽くまで自分で作ったものではない。
インターネット上に散在する、どれほど価値があっても集約されない限りにおいては何の役にも立たない数多の野良情報、それを集め倒し検索可能にしたことで、個々では意味のないものの集合体を非常に意味あるものにした、というのがGoogleだ。
そして、AdwordsにせよAdsenseにせよ、野良データの集合体が多大な価値を持った基盤の上に、企業や商品情報等野良でない整理された情報を野良データより優先配信することに対し課金してきた、というのがGoogleの広告モデルだった。

ところが、位置情報に関しては、Googleのこのスタンスが変わってきている。
明らかにGoogle自身がコンテンツを持っている。
一番判り易いのは地図や衛星写真といったデータだが、これに関しても私は言いたい点がないわけではないけれども、ちょっと別格かもしれないので置いておこう。
テキストベース検索なら検索結果にハイライトする等で検索された属性を指し示す事が可能だが、位置情報に関しては地図なんかに頼らなければ検索された情報の属性を直感的に表現する事は難しいので、そのための必要悪？として地図等を自前コンテンツとして持たざるを得なかったからかもしれないからだ。
問題は、Googleローカル等で検索される情報の話だ。

例えば、「市ヶ谷 寿司」で検索される　このような情報。
ここで提供されている情報は、Googleがテキスト検索の世界で採ってきた戦略のような、位置情報に関する野良データを集めてきた集合体か？
明らかに違う。
むしろ、テキスト検索での戦略ではAdwordsやAdsenseで広告として配信としてきたような、整理された店舗やサービス情報だ。
別の言い方をすれば、サーチエンジンではなくYahoo!のようなディレクトリサービスで配信されている情報に近い。
そしてその情報は、こうして検索されている寿司屋達が、Googleで検索できるようにしてくださいと、広告費を払って掲載してもらっているとは考えにくい。
おそらく、インターネットタウンページかどっかから金を出して買ってきたものだろう。
つまりGoogleは、テキスト検索の世界では金を採って広告として「配信してやっていた」類の情報を、位置情報の世界では、わざわざ自分で金を払って入手し、「タダで配信してくれて」いるのである。

このような戦略を採ってしまった以上、Googleの位置情報基盤の上で、将来位置情報ベースの広告を配信して収益基盤を成立させることは考えにくい。
だって、広告料を払わなくてもわざわざ無料で自分達の店の情報をGoogleが出してくれるのに、それに追加で金を払うような奴なんて、そうそういないだろう。

別に位置情報に関する野良データを集める手段がないのならば、仕方がないといえるかもしれない。
だが、Googleの得意なWebのクロールを使って、位置情報ベースの野良データを集める方法は存在する。
1997年にNTTソフトウェア研究所が行った伝説的？な実験、モーバイルインフォサーチ実験２で実現されていた「ここのサーチ」では、Web上をクロールした結果得られたテキスト情報から、その中の住所情報を抜き出し、ジオコーディングして経緯度を持った位置情報としてデータベース整備し、位置をベースにWeb検索する、というような事が実現できている。
それ以外にも、ページ内に貼られた画像内のEXIF情報とか、ページに埋め込まれたRDF情報とか、いろいろな戦略を組み合わせて情報収集すれば、位置情報で紐付けた野良Web情報のデータベースを整備することも、Googleには十分に出来たはずだ。
そのようにしてできた位置情報ベースの野良データの集合体が、多大な価値を持ち始めるので、その上に優先的にデータ配信したいと考える企業やサービスから、広告費を徴収して配信するという、テキスト検索での戦略と同じモデルを採ることだって、Googleには十分にできたはずなのだ。

なぜGoogleがテキスト広告と同じ戦略を採らなかったのかは判らない。
明らかに戦略がぶれていると思う。
でも、逆に言うと、位置情報ベースの世界で、Googleがテキスト情報ベースで採用し成功した戦略を採っているところは、いまだない、ということだ。
もちろん将来、Googleも位置情報ベースの野良データ収集に乗り出すかもしれないが、一方で既に現在配信しているような整理された行儀のよい情報配信も行ってしまっている以上、それを中止して広告費を出したところだけの広告配信に切り替える、というようなことも考えにくい。
ということは、Googleに先駆けて位置情報ベースの野良データ収集を行いデータベース整備を行って、その上で広告料を取って広告を配信するというモデルをいち早く完成させたところは、位置情報分野ではGoogleに取って代わることだって十分に可能、ということではないだろうか。

ちなみに、実は私はその辺に手を出そうとしている個人を、Webクロールして住所を抜き出しジオコーディングするためのライブラリの構成についてちょっと相談を受けたことがあるために知っている。
そのライブラリはよく考えられていて、相談を受けはしたものの私なんかが何か言えることもなくただただ「すごいやん」と賞賛するしかなかったのだが、その後特に彼から動きを聞いていない。
興味をなくして辞めてしまったのか？それとも実は着々とクローラを徘徊させて位置情報データベースを整備させている真っ最中なのか。
判らないけど、そっち方面面白そうなんでぜひ追求していってよ、と彼には言いたい。

一度引用済みの他者エントリを元に、何度も言及済みの話題をまたぶり返して恐縮だが、

mixiはマイミク日記の「未読管理」すら無い時点で、パソコン通信よりも退化している -void GraphicWizardsLair( void ); //-

パソコンを扱うときは「怠惰で短気で傲慢」を心がけているオレとしては、機械で出来る事をわざわざ人間にやらせようとするWebのインターフェースには怒りすら覚えんだよな。
その中でもmixiのコミュニティとマイミク最新日記は最悪レベルに近い。

 システム的に考えるとWeb2.0を持ち出すまでもなく、mixiは不完全なシステムです。
* コミュニティにサブアカウントがない
* 過去ログの検索がほぼ不可能
* 長くmixiを続けているとコミュニティの発言を追うことは実質できなくなる

かと言って、その辺が解決されたSNSが出来たからといって、誰もそちらには移らずにmixi使い続けるんだよな。
何故かって、SNSにとっては、インタフェースや機能の良し悪しなんかより、最大のコンテンツはその中に蓄積された人間ネットワークだから、それが移行できない限りにおいては、他に移りようがないわけです。
これが同じ流行のサービスでも「ブログ」ならば、（まともなサービス同士なら）書き溜めてきたコンテンツは移行できますし、或いは古いのはそのままストックさせておいて新しいのに移行したって全然構わないので、インタフェースや機能の良し悪しなんかがそのまま競争力になり、人気の流動性が現れます。
でもクローズドなSNSの場合、先に書いたとおりインタフェースや機能は2の次で中の人間ネットワークが最大の移行できないコンテンツなので、どんなに頑張って斬新なインタフェースや機能を実現しても、後発で貧弱な人間ネットワークゆえに流行る事はなく開発意欲がそがれるし、一方でMixiは新機能等を改善しなくても豊潤な人間ネットワークがそのまま力となって勝手にどんどんユーザ数が成長していってくれるので、これまたわざわざ頑張って斬新なことをしてみよう、というモチベーションも喚起されない。
結局SNSがクローズドである間は、SNSのシステムとしての成長はほとんど見込めないということになってしまい、それが最大のクローズドSNSの問題と私は考えます。

一方、OpenID等の技術を駆使したオープンな、インターSNSの時代が到来するとどうなるか。
これまでクローズドなSNSに牛耳られ囲い込まれてきた、本来個人に属するはずの各種データ---人間ネットワークから、交わしたメッセージ、コミュニティへの帰属、等々---は個人への帰属となり、SNSサービス自体はそれを閲覧するビューとしての機能、それを利用し応用した特殊な機能等を提供するのみに過ぎない存在になります。
そうなると、どのような魅力的なサービスを提供できるかがSNS同士の競争となり、SNSのシステムとしての成長も促進されます。
極端な話、提供するサービス・機能の優劣によって、あるコミュニティのコミュニケーション用掲示板はMixiの機能、イベント等予定管理はGREEの機能、イベントの場所等の管理はポジタルの機能を使う、なんてこともできるようになる（インターSNSをどのように実現するかにもよるけど、少なくとも私の考えてきた案なんかでは可能）。
そうなってはじめて、本当のSNSの発展が見込める時代になるような気がしています。

今のように、SNS界に広く認知される新しい発展を見込むには、Mixiがそれを取り入れて機能を実現するのを待たなければならない、というような状況ではダメなわけです。
SNSの正常な発展のためには、1日でも早くインターSNSが実現すればいいなと思っています。

もうあちこちで取り上げられていますが、Google Mapsの日本地図が非常に美麗になり、また衛星写真とベクタ地図とのハイブリッド表示がついに実現しました。
Google Earthで気合の入った日本国内ベクタ地図情報が同梱されていたので、ZENRINもかなりGoogle Earth&Mapsに本腰を入れ始めたっぽいと思っていたのでいつか来るとは思っていましたが、美麗化されたデータとあいまってなかなか予想していた以上に壮観です。

これだけ本腰を入れ始めたとなると、ジオコーディングAPIの日本国内対応も遠い日ではないかもしれませんね。
とりあえず、正式対応するまでは、弾さんのこちらのHack等を利用するが吉でしょうか。 

sedやgrepを使わないで、肉眼検索で文章の用語統一をしたり。手で100近いデータの置きかけ作業を一日がかりでしていたり。
ああいう「自分を機械として動かす」という勤勉さってのはオレは出来ないんだよなぁ……

うちの仕事場でもいっぱい。
どうしてわざわざそんな苦労をするの？みたいな。

例えば、ほとんどの人が、業務フロー図からハードウェア構成図、ネットワーク構成図にいたるまで、むちゃくちゃ細かい図をExcelで描いてたりする。
意味判らん！Excelって描画ソフトじゃないやん！
描画の見た目を揃えてくれたり、オブジェクトをうまく部品化してくれたりする機能もないようなもんで作図するなよ！
Visioとか、Visioだとみんなが見られないのならせめてパワポで作るとかにしてくれよ！

いや、そんな不便なツールで作図しているにも関わらず、みんななんか知らんけど小器用に綺麗に描くので、こっちが見る分には好きにしてくれればいいんだが、修正要求やこっちがつくるものまで同じフォーマットを要求されるのが困る。
俺は断固拒否して、たまたまシステム構成担当だったので特権を活かして？開発用ソフト群にVisioを潜り込ませ、そいつでお絵描きしてる。
どうしてもフォーマットあわせないといけない時は他人にやってもらうか（鬼？）。
よくみんな、あんな無駄な苦労するよなあ...。

今週発足する安倍政権が重要施策に掲げる「再チャレンジ支援策」のひとつである２５～３４歳で定職に就かない「年長フリーター」の正社員化をめぐり、官民の温度差が際立っている。
政府側の意気込みをよそに、日本経団連の調査では、年長フリーター採用に前向きな企業はわずか１．６％で、２４．３％は採用する意思がなかった。
　　　..........................................
ここまであからさまに侮辱されて黙っているわけにはいかないでしょう。
氷河期世代が立ち上がるときが来たのかもしれない。ここで立ち上がらないと一生みじめな人生を
歩むことになりかねません。このままだとずっと低賃金奴隷ですよ。

立ち上がるのも大いに結構で、なにかプロジェクトが走るならできる協力はしたいと思うのだけれど、根っからムラ社会野郎（本当？）だからからか、あるいは結局当事者じゃないから、になっちゃうのかもしれないけれど、98.4％に怒りをぶつけるよりも、1.6％を盛り立てて育てて拡げていく方向の方がよい希ガス。

そもそも、たとえ1.6％ととはいえ存在する採用に前向きな企業に対し、就職氷河期被害者は出会えているのか。
氷河期世代を募集している募集要項ページを網羅検索できるようなGoogle検索ワードがあるわけじゃなし、たった1.6％が広いインターネット上でバラバラに募集をかけていても、それに出会える可能性は極めて少ないだろう。
どこかに集約されなければ。

というわけで、就職氷河期世代求職情報の集約＋ムード盛り上げの双方を兼ねて、Find Job!で就職氷河期解消キャンペーンとかできないもんですかね笠原社長、とか言ってみるテスト。

---- 追記 ----

発足したばかりの新政権が重要施策に掲げているのだから、乗じて話題感を出すには今このタイミングが旬ですぜ、とさらに煽ってみる。

若い技術者に忠告しておく．30歳が人生における一つの分岐点だと．この時にいずれの道を選択するにせよ，その後で別の道を選び直すことは極めて困難で，限りなく不可能に近くなる．

うわ、それ俺には救いがナス。
30歳を2年も過ぎて「これからは位置情報だ！」とかなんとか言って、全く別の業界に飛び込んだ（しかも、正確には飛び込もうとして失敗し続けてる）もんなー。
というか、そもそもSE・プログラマ方面になったのが28歳半ばだったから、実はその時点で分岐点まで2年程度しかなかったのかー。

就職したのは27歳になる年だったんだけど、この話すればいつも驚かれるけど最初の1年半はIT関係じゃなくて、レーザー光学技術者だったんだよな。
炭酸ガスレーザーで、ハードディスク表面を微細加工する装置の光学を担当してた。今でも前にいた会社で、その成果物扱ってる（これとか、これとか）。

そうこうするうち会社がハードディスク関連製品の新規開発から撤退したので、仕方なくプログラミング覚えてSEに。
VBやらASPやらSQL Serverなんかのマイクロソフト系プロプライエタリな環境でまあ普通にシステム作ってたんだけど、30歳の時にプラントの稼働状況をi-modeで遠隔監視するというシステムを作ったのをきっかけに、携帯Webに完全にはまってしまう。

そうこうするうち、その1年後くらいにauがケータイにGPS載せてきたんだけど、それに出会った途端神が降りてきて、Mobile 2.0にその時点で目覚めてしまった。
この辺の資料も、当時はWikiじゃなくてパワーポイントでしたが、その頃に作ったもんだったりします。
でも流石に最初の会社は全然その手の世界と関係がなさ過ぎて、経営陣にこんなプレゼンしても見込みナス状態だったので、自分でいろいろやってみようと始めたのがここギコケータイ版。
この頃で既に31歳。PerlやMySQLもこの時覚え始めた。

そして1年程度、最初の会社の仕事しながら余暇にここギコケータイ版開発していろいろケータイ位置情報の実験をする、という生活をしてたんだけど、これじゃラチがあかねーと思い、32歳の時に上京し、位置情報関連或いはケータイWeb関連の世界に飛び込もうとした。
後の経過はこちらに書いたとおり。
せっかくまともな会社にも受かってたのにEvilなとこに入ってしまって闘争に明け暮れる事1.5年、キャリアの積めない大会社で予期せぬ仕事に従事する事1.5年、気が付けば何も身に付かないまま35歳を過ぎてしまった。

最近otsuneさんに「優越感ゲーム」と突っ込まれるようなこともあって、それに「優越感は劣等感の裏返しですよ」と返したことがあるんだけど、その辺の劣等感もこれまでの来し方から来てたりしてる。
上京した時は、全然劣等感なんてなかった。もちろん、裏返しの歪んだ優越感もなく、完全に自信しかなかった。
当時は位置情報なんかろくに注目もされてなかったころに、幾人かの判ってくれた連中（その頃の連中はみんな、位置情報やめちゃってるが）とディスカッションする中で、俺は将来発展する技術分野にいち早く目をつけたんだという自信を持っていたし、技術的にも、実務で使わず趣味で1年ほど触ってきただけにも関わらず、ライブドアの面接で自作のここギコPerlフレームワーク見せて、当時のmiyagawaさんにちょっと感心してもらったりもしてたので、こっち方面の才能もあるんだと自信を持っていた。

でも、自信を持つのと自己分析で過大評価するのとは別なので、miyagawaさんに感心してもらったからといってmiyagawaさんに遠く及ばない事は自覚していた。
当時でプログラミングは始めてまだ3年程度、Perlはまだ実務でなく1年程度と全然キャリアが足りない事は判っていたし、いろいろと体に障害があって無理が利かない分、人一倍キャリアを積まないといけないという自覚は十分にあった。
ところが実際には、転職先の選択ミスで全くキャリアが積めない。
1.5年経ってどうもこうもしようのないのに気付き、あわててキャリアの積めるWeb2.0企業とか受けてみるが、もしかしたら1.5年前だったらライブドアと同じように受かっていたのかもしれないけど、今となっては採ってくれない。
なんとか採ってくれたところに行けば、これまたやっぱりキャリアが積めないところ。
またまたあわててWeb2.0企業をまわってみるけど、H社もC社もD社も全部駄目。
自分の弱点の認識は、克服できる見込みがあってこそ弱点の認識だが、克服できる見込みが絶たれれば劣等感になる。
人一倍キャリアを積まないといけないのに、人一倍キャリアが積めない。自分で選んだ選択は、軒並み駄目なものばかり。3年前ならきっと同程度だった実力のGeek達は、どんどんキャリアを積んで届かないところに去っていく。
劣等感だけを膨らませて、この3年生きてきたようなものだ。

そんな劣等感だらけの俺でも、いろいろ言いたい事はある、だからブログに書く。
でも、こんなに劣っている俺が書いても、世間に対して何の説得力もないように思えてしまう。
そしたら、俺にとって寄って立てるものと言えば何か？自分の経験しかない。
技術者としてのキャリアという意味では何の役にも立たないものではあるが、いろんな事をやってきたせいで、割といろんな世界を見てきている。
個々の世界を見れば他にも体験した人はいくらでもいるだろうが、全部まとめて経験のある奴はそうそういないだろうという世界を見てきている。
ましてや、働き始めてこの方WebやPerl業界でしか仕事したことのない連中は知ろうはずもないことを。
となると、自分としては自分の意見に説得力を持たせるために、そこに頼るしかないと思ってしまう。
俺はこんな体験をした、俺の意見はその実話に裏付けられている、といった形での書き方をどうしてもしてしまいがちになる。
otsuneさんの指摘する「優越感ゲーム」とは、その辺を指摘しているのだろうと思う。
でも、劣等感の塊の俺としては、思い込みだとは判っているけれど、むしろそれを書かないと説得力がないような気がしてしまうのだ。

こちらのmixi API作ったら儲かりまっせネタ、勢い余って筆がすべって笠原社長にミクシィメッセージ突撃してみた。
そしたら、非常に丁寧なご返事をいただいた。

いただいた返答の内容としては、

• mixi API作るのを積極的に止めているという噂はガセだよ、笠原さんも他の中の人もそんなスタンスの人はいないよ
• APIに関しては何時作るとかは言えないけれども決して否定的ではないよ

とのことでした。

笠原さん、あいまいな噂を前提としたようなメッセージを送ってしまい申し訳ありませんでした、またそのようなメッセージに穏やかに対応いただきありがとうございました。

というわけで、作るとの言質をいただいたわけではないですけれども、決して否定的ではないとのことで、mixi APIを期待する方悲観する必要はないようです。
果報は寝て待てくらいで、のんびり期待しましょう。

Plaggerが話題なのは知っていたが、特にやりたい事もなかったので手を出していなかった。
けど最近やりたい事が2つほど出来たので、手を出してみた。

判り易いと評判の、竹迫さんのSoftware Design 2006年 10月号の記事を参考に、サクサクサクとインストール。
やりたかった事の一つ目は、最近全然目を通せていないOpenIDのメーリングリストを、忙しくても話の方向ぐらいはざっくり掴めるよう、翻訳されて届くようにすること。
そこ！英語くらい素で読めとか言わない！
届いたメールを読み込んで、 翻訳して、再度メールに送るのだから、使うプラグインは

CustomFeed::POP3
Filter::Babelfish
Publish::Gmail

の3つ。

最初、Filter::BabelFishのSYNOPSISどおりの設定で起動させてみたら、届いたメールはなんか翻訳されてるっぽいけど文字化けしてさっぱり判らない。
あー、文字コードの問題？文字コードどこで設定すんだ？とかいろいろ調べたけどいまひとつ判らない。
でもFilter::BabelFishの設定項目に、どこの翻訳サイトを翻訳エンジンとして使うか、というのがあったので、試しにそれをSYNOPSISで設定されていたGoogleからBabelfishに替えてみた。
そしたらちゃんと文字化けしないメールが届いた。
まあ、そしたらとりあえずそれでいっか。

とりあえず動いた設定用YAMLファイル。

plugins:
  - module: CustomFeed::POP3
    config:
      host: kokogiko.net
      username: openid
      password: base64::himitsu
      delete: 1

  - module: Filter::Babelfish
    config:
      source: English
      destination: Japanese
      service: Babelfish
      prepend_original: 1

  - module: Publish::Gmail
    config:
      mailto: nene@kokogiko.net
      mailfrom: nene@kokogiko.net
      mailroute:
        via: smtp
        host: localhost

たったこれだけで、翻訳されたメールが届くんだから面白いなー。
まあ本格的なソリューションとして考えると、レイアウトとか、訳文の方で改行が入らないとか、できれば文単位で対訳の形式になればよかったなとかいろいろ思うところもあるわけですが、たったこれだけの出来合いのプラグインと設定だけで、ここまで出来るというのがすごい。

でも、もう一つやりたいことがあるのだが、そっちは正直難しいだろうなと思ってた。
というのは、携帯から送られてきたモブログメールを、そのまま内容変えずにBitPetsのBitブログ投稿用アドレスに転送しつつ、添付画像を抜き出して画像として本文中に貼り付けて、EXIFに位置情報が付いている場合はそれに合わせたALPSLABやGoogleMapsなんかの地図サービスの記述なんかも加えて、MovableTypeに投稿する、というもの。
これは、転送するメールと、MTに投稿する内容とで、元メールからFilterし整形するデータの度合いが違うので、各プラグインを実行するフェーズが厳密に定められているPlaggerでは難しいだろうと思ってた。

でも、よく考えれば、Bitブログ投稿用アドレスへの転送の方は、Plaggerでやらなくてもメールサーバの設定で転送すればええんやんけ。
んでもって、Plaggerには、画像の抜き出しや位置情報の埋め込み部分だけFilterプラグインとして自作してやれば、後の部分はCustomFeed::POP3やPublish::MTがよきにはからってくれる。
なるほど、Software Design記事のコラムで、PlaggerはWeb2.0時代のパイプ指向プログラミングとか書かれてたけど、それだけにPlaggerだけで何でもかんでも何とかしようと考えるより、他のつかえるもんは何でも使って、組み合わせで手早く問題解決、というようなやり方がCoolなのかな、と思った。

カンファレンスで知り合ったKaMapの開発チームのLrenzoとAndreaが、pgRoutingの実装を始めたことを前回報告したが、それがついに出来上がったらしい。

ちなみにkaMapとは、MapServerをバックエンドにしたGoogle Mapsみたいなリアルタイム地図構築ツールのオープンソースプロジェクト（いつの間にか1.0ベータなのね）、pgRoutingとは、オークニーさんが作ったPostGIS向け経路探索・ジオコーディングライブラリPostLBSのうち、経路探索部分の名称。
つまり、Google Mapsのようにリアルタイムに動かせる地図の上で、2点を採ればその間の経路を探索してくれるようなインタフェースの実装ができたということ。
オープンソースの。

実際の動作デモを見るにはこちら。

Web画面ツールバー上のピンとピンを赤線で結んだようなアイコンを押した上で、地図上でシングルクリックすると起点のピン、別の点をシングルクリックすると終点のピンが配置され、その間の経路が赤線で表示される。
経路探索自体が多少重い処理なので経路探索は速いのだけれど、画像作成に時間がかかるので、経路出るまでにちょっと時間がかかる場合もあるので注意（トラックバックでツッコミを受けて修正。詳細はトラックバック先を参照してください。）。
もう一回地図上シングルクリックでリセットされる。
起点を指定した後、地図をスクロールして画面外に終点を置くこともできるが、その際は一旦ツールバー上のアイコンを「手」に戻して、スクロールモードに切り替える必要があるので注意。
また、バグか仕様か判らないが、上のサンプル画像より大きな縮尺にしてしまうと、経路は表示されなくなってしまう（そのまま縮尺を小さくすると経路は表示されるので、経路が長くなると検索できないわけではないようなのだが...詳細不明）。

なかなか面白く遊べます。
もうオープンソースでここまでできる時代なのだなあ...と驚きますね。

たくぼさんところから。

Geoinformaticsって? -飛べない日々-

ちなみにyomoyomoさんはFOSS4GをもってしてWhere2.0という動きを

やはりこれに関してもオライリーの目の付け所は正しかったということか。

と評されていますが、"Web Mapping Illustrated"の和訳版"入門 Webマッピング"の出版にあたってはTim O'Reilly自身がかなり積極的だったという話をオライリージャパンの編集者の方からも伺ったような記憶があるのでその"目の付け所"によほど自信があったのか、それとも実は地図大好きなおじさんだったりするのではないかと思うのですが真実はいかに?

うへえ。マジかよ。
俺はその話は聞いてなかったけど。

というわけでTim O'Reilly氏ご推薦の入門Webマッピングをこれからも一つよろしくおねがいしまつ。

入門Webマッピング―自分で作るオリジナルのデジタル地図 posted with amazlet on 06.09.23 テイラー ミッチェル Tyler Mitchell 大塚 恒平 丹羽 誠 森 亮 たくぼ あきお 真野 栄一 オライリージャパン (2006/05) Amazon.co.jp で詳細を見る

先のエントリへのはてなブックーマークで、次のような意見が多く見られた。

• 儲かるスキームが見えないapi公開って、やる意味ないんじゃないかと。その辺を冷静に判断してるんじゃないのかなー。

ごめん、あれ？1件しかなかった。仕方ないのでotsuneさんとこのエントリでのコメントからも借りてくる。

• もしかすると私が誤解してるかもしれませんが、仮にミクシィがWeb2.0的なAPIの提供を開始した場合、本来なら得られたはずの広告バナー収入の一部を失ってしまうように思えます。

本当にそうなのかな？APIって儲からないの？減収しちゃうの？と思って、ちょっと考察してみた。

まず、mixiの収入源は何か？mixi premiumと広告収入だ。どっちのウェイトが大きいのか、多分間違いなく広告収入だろうけど、両方について考察してみる。

APIができれば、mixi premiumの参加者が減るか？減らない。なんで？だって、直交概念だから。
APIを使えば、mixi premiumで提供している機能が実現できてしまうのなら減ってしまうだろうけど、全然関係ないでしょ？
APIで認証とマイミク情報が取れたって、フォトアルバムは使えないし、日記容量は増えないし、メッセージ保存期間も増えない。
というわけで、関係なし。

APIができれば、mixiの広告収入が減るか？減らない。なんで？だって、APIで作るものって、mixiにない機能だからAPI使って作るんでしょ？
mixiにある機能をわざわざ外部で作るわけないので、mixiが提供している機能を使いたいときはやっぱりmixiのページ見るでしょう。
mixiのアクセス総数が減るとは思えない。
外部のブログでmixiユーザかどうかでアクセス制限したい、なんて要望だって、そんな要望出す人は既にmixi日記として外部のブログ使っている人だろう。
元々外部に誘導している人のところでどう使われようが、アクセス総数には影響が出るわけがない。
というか、それが嫌なら元から外部ブログをmixi日記にできないようにしとけ、というアレ。

というわけで、APIができたってmixiの収入には何の影響もあるとは思えない。
でも、メリットがなければ、作るだけ原価の無駄なので、やっぱり作らないという選択にはなる。
本当にメリットはないのだろうか？

俺は、あると思う。
mixiの利便性にどっぷりはまっている人には信じられないだろうが、mixiの認知度はまだまだそれほど高くはない（ちょっと古いけどね）。
実際、誘っても「いや、別に興味ないから」とスルーする人も多いし、酷い人になると勧誘しないと入れない得体の知れないところ、ということで、新興宗教かなんかの勧誘と間違う人だっている（実話）。
それはある意味当たり前で、知っている人にとってはログインの向こうにほとんど無限の人間ネットワークが眠っているサイトであっても、知らない人から見れば、mixiなんて、草原に女の子が2人遊んでいる、新興宗教が爽やかさをアピールしているのにも似た感じのページを提供しているだけの、単なる1ページサイトでしかないのだから。
こういう誤解を持っていたり、興味を示さない人達までmixiのユーザとして取り込むのは、今のmixiでは無理だ。
何故なら、mixiの利便性（或いは、逆にmixiに入っていないことによる不利益）を理解してもらわないといけないのだが、その利便性に触れてもらうには、mixiに入ってもらわないといけないからだ。
何という二律背反！

しかし、mixiがAPIを提供していればどうか？
そのAPIを使って、どこかの一般公開されているBlog上で、「この記事は、友人にしか公開されません」「この記事は、GISマニアにしか公開されません」とかなっていたらどうだろう。
そのBlog作者の友人でGISマニアだけど、これまでmixiへの誘いはことごとくスルーしてきたような奴が、その記事を見たとする。
当然こう言うだろう。
「なあ、俺も友達だしGISマニアなんだから、記事公開してくれよ。」
そうすれば、こう答えればいい。
「いや、あのアクセス制限は、mixiというサイトのAPI機能を使って実現してるから、公開するには、俺の友達としてmixiに入ってもらって、GISマニアコミュニティに入ってもらわないと駄目なんだ。」
そうすればその友人も、mixiとはどういう事ができるところなのかという一端に、mixiに入らずして触れることができ、mixiに入ってみようかというモチベーションも喚起される可能性がある。
要するに、APIを使った成果物がmixi外のところで非mixiユーザの目に触れる事で、今までmixiに興味を示さなかった層までを、mixiの潜在的なユーザ層にすることができるのだ。

そう考えると、mixiがAPIを公開しない理由はないと思う。

てな感じの煽りを笠原社長にすれば、API作られますかね。
笠原社長はBlogされてないようなので、TBはできないな...いきなりmixiメッセージ出すってのもちょっと敷居高いし。
こう考えたらTBって、気軽に交流できていい文化だよな。

以上、個人的には、mixiが独自のAPIを公開するより、SNS界の日本代表としてOpenIDなんかの世界標準に乗り出して欲しいので、独自APIとかにはあんまり興味はないのだけれど、「API作ったって儲からないんじゃね？減収するんじゃね？」という意見にちょっと違和感を感じたので、ちょっと考えてみました。

mixiは成功を約束された不滅の企業になっているのかなと思います。

あたりはちょっと書きすぎだったかなと思って、別の方面からのmixiへの逆風を考察しようかなと。

本質は、私のエントリを受けて書いてくださったダイミテイさんの

Mixiは巨人軍のように不滅です? -ダイミテイ-

水平分離にしたがってコモディティ化が起こる。相互運用性が増え、組み合わせる相手を選べるようになったのだから当然だ。同じレベルの相手と競争しなくてはいけないわけです。

NiftyServeの例で言えば、パソコン通信時代に比べて NiftyServeを選ぶ価値は大幅に減った。個人的には HP-200LXのユーザだったので、Niftyの情報がありがたかった。でも今は Daily Portal Zは好きだけど、Niftyに入ろうとは思わない。

OpenIDプロバイダにも同じことはいえるだろう。案外伏兵は前略プロフィールだったり。

その通りで、パソコン通信時代は、Niftyはオンリーワン...ではない（PC-VANとか）ものの、非常に限られた選択肢の一つだった。
だから大量のユーザを囲い込む事ができ、インターネットプロバイダ事業にもそれまで囲い込んできたユーザ数を背景に、最大手として君臨する事ができた。
だが、それは規模を維持できるというレベルであって、新規ユーザを獲得して規模を拡大するという段になると、パソコン通信時代に築いたブランド感の優位は多少あるものの、基本的に同列のサービスを展開する事業者群のワン・オブ・ゼムに過ぎず、競争を経なければ規模を拡大するのは難しい。
よって、業績を維持する事はできても、業績を拡大する事は難しくなる...いや、値引き等の競争を経なければならなくなる分、業績維持も難しくなるかもしれない。
結果、同じ業種をやっている中での「相対的な」最優位は維持できたとしても、自社の過去の業績等と比較した「絶対的業績」をあげるのは難しくなるのかもしれない。
（もっとも、パソコン通信時代と比べネットをやっている人のパイも大きくなっているので、実際に業績がどうなるのか、どうなっているのかははよく判らないけど）

インターSNS時代のmixiも一緒で、最初はクローズドSNS時代のユーザ数を元に最大手のOpenIDプロバイダとして君臨できたとしても、新規ユーザを獲得する段になれば、ブランド感はあったとしても数多のOpenIDプロバイダとの競争を経ねばならなくなる。
その分、経営の舵取りは苦しくなるかもしれない。
やはりパイが大きくなるのも、パソコン通信→インターネットの場合と同じではあるのだけれど。

で、ダイミテイさんは冗談混じりながらOpenIDプロバイダとしての伏兵となる可能性は前略プロフィールだとか書かれてるけど、私の考え的には、伏兵はプロバイダだと思う。
同じ言葉だからややこしいな...OpenIDプロバイダではなく、インターネットプロバイダのことね。

この事については、インターネット接続の際にその前提条件となるラストワンマイルとの比較を考えればいい。
ラストワンマイルが電話上のアナログ音声信号によるアクセスポイントへのダイアルアップしかなかった時代には、そのアクセスポイントを提供するインターネットプロバイダという事業が、業者数自体は百花繚乱とはいえ他業種に競争を挑まれることはなかった。
ところが最近では、ADSL、FTTHといった他のラストワンマイル手段が広まるにつれ、フレッツ光やTEPCOひかりのようにラストワンマイル提供サービスとインターネットプロバイダサービスは別という立場を墨守しているところもあるけど、Yahoo! BBやUSEN、ケイ・オプティコムのように、ラストワンマイルがインターネットプロバイダの役割をも取り込んでいるサービス形態も多くなってきている。
ケータイWebにいたっては、100%ラストワンマイル提供者＝インターネットプロバイダ提供者だしね。
価格的差異がないのであれば、ユーザにとってはワンストップチャネルがいいに決まっているので、これはラストワンマイルを持たない既存のインターネットプロバイダにとっては脅威だといえる。

これと同様に、インターSNSの概念が着実に広まって、その利便性が一般に理解されるようになり、インターネット全体が潜在的なインターSNS基盤になるようになれば、そのインターネットへの接続を提供しているインターネットプロバイダが、サービスを利用しているユーザに対してインターSNSを楽しむために必須なOpenIDアカウントを提供するようになるかもしれない。
ちょうど今、インターネットを楽しむには必須なメールアカウントを提供しないインターネットプロバイダが存在しない（多分）のと同じように、全てのインターネットプロバイダがOpenIDアカウントをユーザに提供するようになり、その設定の仕方をプロバイダ導入説明書や導入CDの中で説明する時代がくるかもしれない（この辺の考えは、以前のエントリでも書いた。以前のエントリでは、OpenIDと同等の文脈をyadisと書いたり、分散型IDと書いたりしてるが、気にせずOpenID = yadis = 分散型IDと読み替えて欲しい）。
インターネットプロバイダがOpenIDプロバイダにもなってワンストップチャネル化を実現する、そんな時代がくれば、インターネットプロバイダという入り口を持たない独立系OpenIDプロバイダとなるmixiには、苦戦の時代が来るのかもしれない。

どうエントリ収めようか。何にしろ、順風だろうが逆風だろうが、企業を経営していくのは難しいというこった。で収まってる？駄目？

幸い俺は、キャリア積めなかったとかブーブー言いつつもなんとか正社員で渡り歩いてこれたが、それでも就職氷河期というのは実感している。
最初の会社の俺のいた部署、4つ5つ上くらいなら同期が4、5人はいるのに、1つ上の世代は2人だけ、俺の世代は1人、後輩は5年間働いて1人しか入ってこなかった。
そのせいで、普通2、3年目になれば経験できる部下を使う、という経験ができず、5年経っても最下層の実働で現場かけずり回ってたりした。
日本中の現場を渡り歩いて、現場で徹夜した後家にも帰らず次の現場へ直行、移動の電車や飛行機の中でしか寝られない、残業代は不況のため一定額天井でサビ残ばかり、という生活の中で、バブル世代入社組の連中が「昔はよかったんだよー。残業代つけまくりで1月の残業代だけでティファニーとか買えたもんなあ。」とかほざいてんのを苦々しく聞いてたりしたんだけど。
ようやく今の会社で、部下を持って部下を使う、っていう経験をできたんだけど、その部下達だって実はみんな派遣社員で、正社員だけでいうと今の会社も、前後2歳くらいの同じくらいの年代にちょこちょこっといるその下は、いきなり入社1年目から3年目とかで、明らかに年齢構成がおかしい。

そんなこんなで実感していた就職氷河期だけど、週刊ダイヤモンドの「悲惨世代」の特集とか見て、また就職氷河期被害者.comあたりのブログとか見て、この就職氷河期を外から見てきた、俺達以上にその歪みをまともに押し付けられてきた同世代の連中の問題に興味をもっている。
マジでこの問題なんとかしないと、この国の社会問題どんどん負のスパイラルに突入していくような気がしてなりません。
紹介したブログの人も書いていますが、少子化問題解決を、とか言っていても、その産めよ増やせよを期待されている世代がろくに子供を育てるどころか結婚すらできないような経済状況におかれているのではどうしようもありません。
反対に正社員として雇われている側でも、そういう人達が野にいる事による人材不足のツケで忙しくサビ残当たり前になり、忙しくて子供を作る暇もない...まさに少子化スパイラル。
少子化問題解決をとか言ってるんなら、必要な人手の分はみんな等しく雇われて、等しくある程度稼げて、等しくある程度暇があって子供を生む余裕もできるよう、そういう方向に向かうよう政治が舵を取ってくれればいいのに。
実際の政策はといえば、今の若年者不就労対策とか、ニート対策とか、やれ徴農だとか言ってまるで働きたくない奴をまとめて精神鍛えなおすみたいな発想とか、やれ技能教育でスキルを付けさせるとか、明後日の方向ばっかりなわけですが。
実際の問題は働きたくても新卒採用の壁に阻まれて働けない人や、非正規雇用で経験、スキルは積んできているにも関わらず正規雇用じゃなかったというだけでその経験が認めてもらえず経験者採用と扱われないといった、そういうところが問題なのであって、そこに「働く気を出させる」「教育でスキルをつけさせる」ような政策をぶつけたって、何の解決にもならず税金つぎ込むだけムダという話になる。

そもそもこの10年間、不自然な先のこと考えていない人員募集しておいて、今になって人が足りない、特に30代が足りない、とか騒いだって自業自得だろアホ、というしかないわけですが。
それを補うのに、就職氷河期を乗り切った正規雇用経験者とか、少子化でそもそもの供給が減っている新卒とか、もともとパイの少ないところにみんな一斉に募集かけて奪い合ってるんだから、確保できる人員は限られて当たり前だろう。
そんなに深刻に足りないんなら、新卒や正規雇用経験者でなくても、フリーターでも非正規雇用経験者でも雇えばいいのに、なんでこだわるんですかね。

歳を食ってたらある程度の報酬を要求してくるだろうに、スキルがなくて即戦力にならないのでは金のムダだと思ってるから？
あのさ、歳をくってるとある程度給与を要求するのは、結婚してて家庭を持ってたり子供がいたりで、ある程度もらわないと生活が成り立たないからだと思うけど、でも今就職氷河期被害で正規雇用に就けなかったような人達は、そのせいで家庭を持ったり子供を持ったりといった歳相応の事もできず、これから人生を立て直していかないといけない人達でしょ？
新卒新入社員と同等の給与でもいいじゃん。
新卒と同額だろうがなんだろうが、そこで正規雇用されたという経験を梃子に就職氷河期被害者たちの人生建て直し、キャリアがスタートするんだからそれでいいと思う。

それとも、定年までの期間が短いので、人材として確保できる期間が短くなってしまうために、正規雇用者としての教育をかけるコストが無駄だと思うから？
わずか10年前に先のことも考えずに人員絞るだけ絞って、今大騒ぎしてる程度の人事戦略しか持ってないってのに、定年まで何年間いる人材か、なんて考えるだけ馬鹿だわね。
どうせ10年周期だかでくる次の不況では、今回から何も学ばずまた大勢人員切るんでしょ？
だったらこの好景気の10年も、先のことは考えず人員集めりゃええやんけ、と思う。 

真っ白な若い新卒の方が、世間ずれした既卒組よりちゃんと働いてくれそうだから？
今の新卒は売り手市場で、会社にちやほやされながらバブル世代のような楽しい就職活動をエンジョイしていると聞くんですが、同じようにちやほやして集められたバブル世代が、今それほど活躍していますか？
少なくとも私の最初の就職先では、バブル世代は数は多かったですが、いろんな意味でお荷物な人も多かった。
そんな連中より、これまで10年間これ以上はないであろう苦渋をなめ尽くしてきて、それに比べればどんな状況だって、というような氷河期世代の方が、よっぽど使えるかもしれませんよ。

と、考えれば考えるほど、企業が新卒・正規雇用経験者のみの雇用にこだわって、既卒・非正規雇用経験者をハブり続ける理由が全く判りません。
会社の業績回復期に必要な人員数があるとして、それをどれだけ確保できるかがその会社の回復パワーに直結するとすれば、新卒・正規雇用経験者偏向採用の思い込みを捨て、広く既卒・非正規雇用者にも門戸を開いて就職氷河期世代のパワーをうまく使う事に成功した企業が、次代の成功を約束されるのかもしれません。

---- 追記 -----

でも、今各企業がそんな状況にないために、苦渋をなめ尽くしていることは理解しつつも、もし今後企業が考え方を改め、既卒・非正規雇用者にも門戸を開き始めるとすれば、逆に私の方が就職氷河期被害者をうらやむような事態になるかもしれません。
今の時代は、やれ位置情報処理、Web2.0、オープンSNS等、どんな技術をとってもこれからどんどん発達して世界を変えていく面白い時代で、ある意味情報工学の大航海時代ともいえるような時代です。
いろんなチャレンジに身軽に飛び込んで実力をつけ、新しい大陸を見つけた奴が未来を切り開いていくという時代です。
そこに身軽に飛び込んでいくには、私はちょっと生まれるのが早すぎました...ケータイGPSで位置情報に目覚めて業界に飛び込もうとしたときでさえ、既に家庭と子供がいましたから。
流石に四畳半に家族3人で住み、3食毎日メザシ...みたいな生活はしていませんが、クルマも持ってないし酒もタバコもギャンブルもしない、服や靴は破れて駄目になるまで着て...というような生活でも、家族の生活を保証しようと思えばやっぱり年収600万円くらいは必要です。
それをなんとか維持しつつ、かつ自分のキャリア不足をごまかしつつ、なんとかキャリアの積めるところ、自分の野望に一歩でも近づけるところ、ということを繰り返しているのですが、どうしても本質的に荒波の中に飛び込んで新大陸を探すといった行動を取る事ができません。
家族がいて幸せではありますが、その一方で、今この時代に家族さえおらず独り身なら、この年齢からでも当初年収300万だろうが400万だろうが、ライブドアやモバイルファクトリーみたいな技術力のあるところに飛び込んで、大航海時代の荒波を乗り越える技術を徹底的に身につける、あるいはシリウステクノロジーみたいな既に新大陸を目指して漕ぎ出しているところの仲間になる、はたまたあるいは自分で新大陸に漕ぎ出す、といった身軽な選択肢を取るのになと考えることもしばしばです。

今後企業の体質が変わり、或いはこの方面でなんらかの政策が打たれて、既卒・非正規雇用者にも広く門戸が開かれるようになったとすると、同じ世代に生まれながら、この面白い時代まで身軽でいられたことで、むしろ勝ち組は今の就職氷河期被害者達側というようなことにもなったりするんじゃないかとも思ったりもします。

ちなみに「平成９年度「電子ネットワーク実態調査」結果」をみると、このころの nifty serveの会員数は 242万人ぐらい。1997年設立だから、10年かけて集めたわけで。その9年後 (2006年) には nifty serveはパソコン通信としてのサービスをやめてしまった

しかし、それ以上の会員数を mixiは2年足らずで集めてしまったわけで...

予言が正しければ、あと 2年後には mixiは蒸発します。

うちのエントリを紹介してくださってありがたいのですが、mixi消滅と言うのは、何をもって定義するかで変わってくると思います。
今のような形でのmixi、という意味か、それともmixiという会社という意味か。

クローズドなSNS、という意味でのmixiは、OpenIDのようなオープンな認証基盤をベースとしたオープンSNSの波、パソコン通信とインターネットの関係になぞらえて言うならば「インターSNS」の波にさらされ、フェードアウトしていくでしょう。
この方向性は、最近のOpenIDの発展方向（私もちゃんと追えていませんが、少なくともリアルタイムのOpenIDは、WEB+DB PRESS Vol.34で紹介されていた一昔前のOpenIDよりはるかに広い概念として発展しているっぽいです。わりと私の望んでた方向に近いかも）や、Geek of Geeksの一人であるotsuneさんですらオープンなインターネット上でのコンテンツ流通制御へのニーズを感じているといったあたりからも、確信を強めています。
その意味では、今のような形でのmixiは、2年後かどうかは判りませんが、いずれは消滅するでしょう。

ですが、会社としてのmixiはどうか？
こちらの資料を見てください。
最新の資料がないので少々古いですが、確かにNiftyのパソコン通信は下火になり、果てはサービス停止になっても、インターネットプロバイダとしてNiftyという会社のサービスに所属する会員は、業界最大規模が維持されています。
古い形でのパソコン通信サービスは掻き消えたとしても、そこで集めた圧倒的な会員数を梃子にそのままインターネット接続サービスを提供することで、会社としては規模と収益を維持し続けています。
mixiも同じで、インターSNSの波が襲ってきたとしても、それに対してはクローズドなSNS時代に集めた会員数を梃子に、オープンなSNSでは必須な認証サービスのプロバイダとして生き残っていけばいいだけの話です。
Niftyが会員にインターネットプロバイダサービスをしつつ、クローズドなパソコン通信でのサービスも並行し、徐々にフェードアウトしていったように、インターSNSへの認証基盤を提供しつつも会員向けのクローズドなサービスも続け、それを徐々に会員以外の認証基盤を持ったユーザにも開放していき、最終的にはインターSNSサービスとして生まれ変わればいいのです。
というわけで、インターネット時代になってもNiftyが生き残っているのと同様、インターSNS時代になってもmixiは、最大の認証基盤プロバイダとして生き残っていくでしょう...その意味では、既にmixiは成功を約束された不滅の企業になっているのかなと思います。

そう考えると、今の笠原社長のあえてWebAPI等を提供しないという方針も、世の中の技術的趨勢に疎いからそうなのではなく、実は大戦略の一環なのかなと思ったりもします。
笠原社長には、次に来るWeb標準としてのインターSNS化の流れなんかが見えていて、そこで下手に独自API仕様なんかを作ってしまっていると、一時的にmixi基盤をベースにしたインターSNS的なものが実現できたとしても、世界標準としてのインターSNSの規格なんかが立ち上がってきた際に、それに対応するよう作り直さなければいけないことになったりなんかする。
かといって、世界標準になりそうなOpenIDなんかに梃入れして、標準としてのインターSNSを後押しするのも、企業としてはうまみがない...何故なら、今の独占状態で一人勝ちしている状況が長く続いた方が、得られる収益としては高くなるから。
自らは特に動かず独占状態の旨みを得られる状況を長くしながら、どこぞの採算度外視で動く物好きな数多のハッカー連中がゆっくりとインターSNSの地固めをしていくのを横目で見つつ、標準化の趨勢が決まりかけた適当なところで一気に対応させる、という腹積もりなのかもしれません。

私なんかのように、インターSNS化を加速させたいと思いつつも、現実を動かしうる力をほとんど持たないような人間から見れば、業界をリードしているmixiなんかが次世代のために力を割かないのは腹立たしくも歯がゆくもあるのですが、冷徹なビジネスの現実からは仕方ない事なのかもしれません。

そう考えて行けば、いかに「働いてみたいIT企業ランキング（1）：ITpro」の結果が眠たいかわかるだろう。大きくて、それだけに経験値を上げづらいところばかりではないか。もうこの時点で負けている。

こういう企業を就職先として見ているうちはダメである。

将来の取引相手として見ないと。

だから狙い目は、こうしたIT大企業と取引のある、IT中小企業なのである。そこで経験値を積んでから、移籍するもよし。そのまま残ってその会社の成長に貢献するもよし。そして自ら起業するのもよしなのである。最初から大企業に勤めたら、その企業の信用がなければ何もできない小役人もどきになるのが関の山だ。よっぽど志が高く、雌伏に耐える能力がなければ、むしろ大企業は自らの成長の妨げになるのだ。

まさにその通りだと思う。弾さんとは違って、逆に大企業に入り、キャリアを積む機会を逸してしまった者として、特に痛感する。
弾さんのいう「IT大企業と取引のある、IT中小企業」どころか、私は「魅力的なIT中小企業と取引のある、IT大企業」を選択基準にしてしまって、大失敗してしまったのだ。

事の次第、何故私が今大企業にいるかの理由ははこう。
当時私が在籍していたのは中小企業だったが、経営陣がEvilで、キャリアを積むどころか日々馬鹿経営陣を相手に会社正常化のための闘争をするばかりだったのに疲れた私は、転職先を探し始めていた。
第1希望はSixApartだったが、1箇所だけだと心もとないので（でもって実際にすべったしｗ）滑り止めに別のところを探していたところ、某大企業（というか現社）が転職支援会社と組んで、各事業部一斉に集まって、大リクルートイベントを行う、という話を小耳に挟んだ。
その大企業の1部門が、SixApartと取引があって、Blogソリューションを展開しているのを知っていた私は、はてなのNaoyaさんだってSixApartと取引のあった富士通のBlogソリューションで実力を伸ばしたんだし、必ずしもSixApartそのものでなくとも取引先で働くのもいいかもしれないな、それに大会社のハクもつくし（←この考え方が大敗因）、等と考えて、そのイベントの問い合わせ先に、Blogソリューション部門が求人を行っているか問い合わせた。
結果はBlogソリューション部門は求人してないという事で、そうなんですか仕方ないですねそれじゃサヨナラ、で終わるはずだったんですが、そこはそれ、転職会社のエージェントは1人転職を成功させて成功報酬いくらの世界なので、金づる逃してなるか？とばかり、他に行きたい部署はないですか？としつこく食い下がってくる。
それなら、位置情報マニアだしGISの経験を積めるところありますか？と希望を言って、官公庁公共事業の経験も若干あるというあたりから、紹介してもらったのが現在の職場。
転職面接の型どおりに「GIS以外の仕事になる可能性もありますがいいですか？」といった質問を受けて、「はい、必要な仕事であればなんでもこなします」とこれも型どおりの回答はしたのだけれど、こっちとしてはこの質問は、自分の好きな事だけでなく便所掃除もできるか、を確認するための定型質問とまず捉えていたし、そうでなくても、GISを含まない開発業務であっても開発さえしていればシステムを開発するスキルは伸ばせるし、また門前の小僧習わぬ経を、の形で、GISをやっている開発チームからいろいろ学べる事はあるだろうと考えていた。

まさか、GISどころか開発とも関係のない仕事、システム全体から見れば誰かがやらなければならない大切な仕事ではあるのだけれど、私の積みたいキャリアから見ればいわば便所掃除と変わらない仕事を、このキャリアを積む大切な時期に1年半もする羽目になるとはまったく想像もしていなかった。
「必要に応じて便所掃除もできる」というのと、「便所掃除しかやらせてもらえないのに耐えられる」というのはまた話が全然違う。
うちのチームに割り当てられた任務主な仕事は、プロジェクト全体のシステム構成の検討・管理と、対顧客・社内を問わないあらゆる調整。
各業務設計チームの設計内容を元に、ハードウェアの構成を考え、商用ソフトウェアの配置を管理し、PCIやUSB、ファイバチャネルといったポート数が足りているかの精査、商用ソフトウェアの前提関係が満たされているか、積み忘れのソフトがないかのチェック、室内レイアウトや耐加重的にハードウェア構成が妥当かチェック、積み上げた構成を元に見積価格をはじき出して、客先のターゲットプライスに入っていなければ機能を落とさず構成を削減するための案を検討し客先調整、各業務チームがバラバラに設計し野放図にサーバにソフトを積み込んだために、同じ機能（例えば帳票ライブラリ）を実現する商用ソフトが2種類入っていたり、サーバのハードウェアリソースを超えた量のソフトが積みあがっていたりしたら、ソフトの再選定や配置換えのために社内調整、等、等。
よく聞く、管理する側に回ってコードを書く現場から離れたのでストレス、というのとは全然違う、リーダーの私だけでなく、チームメンバーも全員コードなど書かず、WordとExcel、Powerpoint、Visioがお友達の仕事をやっている。
ある意味、プロジェクト全体のハブともなる重要な仕事で、それを任されているという事は信頼されてるということの現われなのかもしれないが、しかし明確に積みたいキャリアがあり、そのキャリアを積むためにわざわざ転職した身からすれば、いい迷惑である。
前の会社は見放していたが、別にその時すぐ転職しなければ危ないといった状況でもなく、この大事な時期に1年半も自分の積みたいキャリアに「全く」関われない、今後も関われる予定のない会社だと判っていれば、そんなところは選ばず別のもっといい他の会社が見つかるのを待ってもよかったのだから。

とまあ、ちょっと個人の事情の微に入り細をうがってしまったが、ことほど左様に、大会社での業務は細かく役割分担されすぎていて、それこそまるで工場の歯車のようにプロジェクト全体のごく一部しか担当できず、結果得られる経験値は小さなものになってしまう。
いわば「木を見て森を見ない」ような経験しか積めないということだ。
これが中小ベンチャーであれば、私が今やっているような仕事など、特定の個人やチームが担当することではなく、業務設計からコーディングまでやる人が、余力で一緒に片付けてしまうような類の仕事だろう。
まさに弾さんのいうとおり、本当に価値のあるキャリアを積むためには、中小企業の方がいいのだと痛感する。

前回の転職は、SixApartと現社しか受けておらず、通ったのが現社だけだったので仕方ないが（とはいえ今のようになると判っていれば転職しなかったが）、前々回の転職では、つい選んでしまったEvilな会社以外にも、インクリメントPとライブドア（当時エッジ）にも通っていたのだ。
（正確には、ライブドアは最終面接だと聞かされていた面接の結果が何時までももらえず、他社を待たせるのも限界だったのでつついてみたら、通っていたけど実はもう一回社長面接が、とか言われたのでこっちから蹴ってしまったのだが）
どちらも、技術があり勢いもある中小企業だ。
過ぎたことを嘆いても仕方ないが、その後3年間、キャリアに恵まれないままIT技術者の定年とも言われる35歳を迎え、精神的にも健康を害してしまった今から振り返れば、あの時どっちかを選んでいればもう少しましな技術者人生を送れていたのかなあ...としばしば思う。

明後日の客先会議の議事録用に、文書管理台帳（Excelファイルだ...とほほ）から文書番号採ってたら、ちょうどキリ番だった。
しかし、いくら巨大プロジェクトだからといって、開始から2年弱で客先への提出文書番号が2000件超ってどんなのよ。
1日4通から5通近く出ている勢い。
それだけの内容を、誰が把握しとるっちゅうねん。

しかも、同じ文書番号で版数重ねる場合もあるわ、飽くまで客先への提出文書だけで内部ドキュメントは数えられていないわで、実際の文書はもっと多い。
（その代わり、単なる議事録もあるし、文書番号だけ採ったけど会議が流れて提出しなかった、なんてのもあるけど。）
それをコンテンツ管理システムなんかも使わずに、共有領域は単なる共有サーバのディスク領域、外部文書は採番だけはされてるけど本ファイルは作った人間に聞かないとどこにあるかさっぱり判らない、いわんや採番されてない内部文書をや。

これで200人近いプロジェクトで、情報共有が出来ているのだからすごい（本当に出来てるのかどうかは神のみぞ知る、だが）。
みんなぶーぶー文句たれているが、実は我々は神のようなプロジェクト管理の下で仕事ができているのかもしれない（いや、それはない）。

perlやphp、mysql周辺の情報はたくさん入ってくるけど、JavaやOracleの情報は滅多に見ないねとか。MSのプロダクトはほとんど見かけない。SQL Serverってこの世に存在してるん？とか。

ネットベンチャーにいれば、いわゆるチープ革命、オープンソースを前提としているから今のhot entryの方が実践的で、同時にそういう仕事に関わってる人達が多いということなのだろうが、でも世の中には、エンタープライズだけじゃなくても Javaの世界やMSだったり、数百万数千万円のプロダクトな世界はあるわけで、結局、ここで得られる情報だけをネットの秩序とか勘違いしていると、視野が限られてきてしまうような気がする。（できれば両方知っておいた方が望ましい。）

これは一例だが、そういうことを意識して、はてブではマイナーかもしれないが、自分が有用だと思う情報をしっかりblogに書いていくことで、ブックマークで数字があがることとは違うニーズがインターネットに存在することを意識できると思うのだが、どうだろうか。

私がこちらのエントリやこちらのエントリで、どのように提供するモチベーションを喚起していくべきか？と考えてきた類の情報、或いは「味噌テール」と名づけた情報は、まさにこのイメージだ。
私はGIS萌えな人なのでGIS業界を例に取ったが、ここで挙げられているプロプライエタリな世界の情報なんかもまさにそうで、一定レベルの需要（プロプライエタリ系なんか、下手すれば今ヘッドを取っている類の情報以上の需要？）はあるにも関わらず、今ソーシャルブックマークを利用している界隈では需要が少ないために、ブックマークされずアクセスも増えず、結果テールに埋もれていってしまう、といった類の情報だ。
そういった情報に対し、アクセスされなくても情報を提供していこう、というモチベーションを喚起するにはどうやっていけばいいんだろうね、というのが私のずっと考えてきた問題提起なわけですが、F's Garageさんなんかが紹介したエントリで書いているのは、

重要なのは、

・自分が有用と思われる情報を書いておけば、ひょっとしたら数ヶ月後、半年後にgoogle経由でその情報を必要とする人が出てくるかもしれない。

・多くの人に消費されるよりも、本当に必要とするその一人のための情報を書いておこう。

逆に言うと、はてブされることだけを狙って書いたキャッチーなだけの文章というのは、結局、むなしく消費されて終わるような気がする。

「アクセスなんて飾りです。偉い人にはそれが判らんのです。」な境地に達観することでそういう情報も書いていこうという方向。
でもこれは、個人の「覚悟完了！」の宣言にはなりえても、万人向けの処方箋にはなり得ないかなと。
要するに個人の達観をベースにしてるので、よく殺人事件の被害者遺族が、逆に達観してしまって、「被害者だろうが加害者だろうが命を奪う事の...」云々で死刑廃止運動に身を投じるようなアレがあるけど、その達観・覚悟は素晴らしいけど万人にそれを要求するのは間違っていると言うようなのと同じで。
少なくとも私は、そんな達観には達し得ない...まだ「ヘッド記事」も「味噌テール記事」も両方書く元気があればいいけど、精神的（うつ病）にも肉体的（手指の痺れ）にも書ける量には限界がある中で、まさに身を削って書いているという感覚があるだけに、やっぱり書いたものにはアクセスが多い方が嬉しい。

で、俺的なこの問題の解決の1手段として仮説を立てたのが、このエントリ。
つまり、私が興味を持っているGISの世界にせよ、JavaやOracle、Microsoftというようなプロプライエタリな世界にせよ、そういう業界のプロダクトってのは、とにかく馬鹿高い。
その分、アフィリエイト等での広告1単価も高くなるんじゃないかと思う。
そういう業界での広告を、コンテンツマッチを突き詰める事によって、ニッチな記事を書いているところにはニッチだけど単価高い広告を配信することで、記事から得られる報酬の単価に傾斜をつけて、ニッチ記事提供のモチベーションを喚起できないかなというもの。
ちょこっと最近の流行に乗ってGoogle EarthやGoogle Maps取り上げたような程度の記事にはGIS広告をマッチさせず、ハードにGISの有用な情報を提供しているところにのみGISの広告をマッチさせる、といったくらい徹底的にコンテンツマッチできるようになれば、多少は改善されないかなあと。
というより、「人気だけど一過性で消費される記事」と「ニッチだけど継続的需要がある記事」の間に、単価の傾斜配分を付ける方法が他に思いつかない。
他にもっとよい方法があれば、それが解決策になると思う。

はてブのhot entryを日常の情報取得手段としてどっぷり浸かっていて思っているのが、アルファブックマーカーというトレンドリーダーとして、多数のお気に入り登録がされている人達が興味がある分野、そしてそこから面白いものに追従しhot entryを構成する人達が興味を持っている情報を得るのは楽なのだが、それ以外の分野ってのもたくさんあって、そこの部分の情報が疎遠になっていることを気にすることがある。

CGMという観点での「はてな村のみんな」がカバーしてる領域と、それ以外の領域が当然あることを意識しないとね。

これは本当に、私も昔からそう感じて危惧してきた。
みんな、すげー視野狭窄に陥ってんじゃないかと思うことがよくある。
その辺について、ちょっと微妙にニュアンスは違うかもしれないけど、以前書いたのがこちら。

ちょっといろいろ翻訳したいネタがあるのですが、その手助けにざっくり訳作成用として機械翻訳使おうと思ってます。
でも無料のWeb翻訳だと何かと力不足と言うか、翻訳精度よりもUIの使い勝手の点でイマイチです。
んで、安い翻訳ソフトでも買おうかと探していたら、何と無料の翻訳ソフトが。

iTranslator for Java

無料だけれど、なんと 12ヶ国語に対応。
その秘密は、翻訳エンジンを内部に持ってなくて、外部の翻訳Webサービスを叩いていること。
このWebサービス自体は前から知ってて、英語系MLを受信したら勝手に翻訳して届けてくれるような仕掛けに利用しようかなと私も考えていたりしたアレですが、デスクトップGUIを持たせた製品があるとは知りませんでした。

翻訳精度は、ちょっと遊んでみたらまあそこそこ、少なくとも翻訳時の脳内にキャッシュしておく和英・英和辞書の項目を少なくできる程度の役には立ちそうです。
でもってWeb翻訳よりはデスクトップアプリな分使い勝手はマシなので、ちょっとしばらく使ってみようかなと思ってます。

でもちょっと気になるのは、GUIのサイズを自由に拡縮できないこと。
画面サイズがずっと小さいままなので、ちょっとストレスを感じることも。
この辺、なんとかならないかな...。

Google Earthがついに日本語版で登場。

単なるインタフェースの日本語化だけでなく、ゼンリンが全面協力したらしく日本の主要道路のレイヤやグルメ情報レイヤ、さらには相当田舎でない限り建物の3Dモデルまでしっかり整備されてて壮観。
日本向けとして超気合入ってる。
でもわが地元、姫路の国宝姫路城の3Dモデルが「アリエネー」のはちょっと悲しかったり。

新機能の中でも個人的に注目はWMS(Web Map Service)仕様に対するクライアントとして動くようになったこと。
有償版ではローカルのシェープファイルなんかも読めるようになってきてるみたいだし、もういっぱしのGISツールですな。
早速、オークニーさんが始めたGISデータネットワークの無償ベータテストに参加して、Google Earth上にインクリメントPさん地図のレイヤを重ねてみました。
中々、おもしろい感じです。

先に紹介したたたみラボの世界ジオコーダーも、KMLを公開していたみたいなので取り込んでみました。
中々世界中がにぎやかになります。

でもこうしてみると、韓国・朝鮮・中国辺りの地名が、漢字表記とかな表記が混ざりまくりなのね。
光州（クヮンジュ）・麗水（ヨス）・大田（テジョン）あたりは漢字なのに、チョンジュ（全州）・スウォン（水原）・テグ（大邱）はカナとか。
しかもその選択に全く一貫性がないので、この辺りどちらかに統一して欲しいなあ。
というか、KML上では無理でも、ジオコーダーとしてはどちらの表記でも検索できるようにして欲しい。

しばらく欝でネタをこなしきれなかったので、遅ればせネタも出しますがこの週末でこなします。
今週末もやることあるし昨日は休日出勤だったのでどこまでやれるかですが、まあ3連休なのでなんとかかんとか。

たたみラボさんから、世界ジオコーダー及びそのAPIが発表されました。
ジオコーダーと言っても、番地とか住所の細かいところまでマッチングして経緯度を導き出すそれではなく、世界の都市の代表点を日本語のカナ表記で検索できると言うものです。
でも逆に、ジオコーダー＝正確な位置、という思い込みがあったので、こういう発想は正直できませんでした。
おもしろいです。

最近たたみラボさんは精力的に色々作られていて、楽しみです。

先のエントリで書いたmt-tb.fcgiの挙動不審ですが、時々

エラーが発生しました: Can't call method "path_info" on an undefined value at lib/MT/App.pm line 1197.

というエラーが発生すると言うものでした。
（うちは解決されたので、他のサイトで観測された例）

とりあえずTrackBackをもし誰かが送ってくれた時に受け取れなければ悲しいので、これだけでも直して寝るかと思い追ってみると、MT::App::Trackback.pmに問題があった模様。

このクラスが親クラスMT::App.pmから継承しているpath_infoメソッド（正確にはその中で使っているCGI.pmオブジェクト）は、同じくMT::App.pmからの継承メソッドinit_requestが呼ばれなければ初期化されないにも関わらず、init_requestより前に呼ばれることがある_get_paramsメソッドの中でpath_infoメソッドが呼ばれるケースがあるためだった。

ごめん眠くてパッチ作るの面倒くさいので、最終的に(o)さんあたりがUO Patchとしてまとめてくれるのを期待して文章で書くと、MT::App::Trackback.pmの107行目

        if (my $pi = $app->path_info) {

これを

        my $pi;
        eval {$pi = $app->path_info};
        if ($pi) {

こう書き換えたらエラーでなくなった。
超場当たり的修正でアレですが。

さあ、寝よ寝よ。

OgawaさんとこのTrackBack Throttle問題解決プラグイン完成を受けて、これで3.32にしても同問題の箇所のパッチ作らなくてもよくなるねー、と思って、この際3.3に上げてみた。

ところが、FastCGI化していたmt.fcgiやmt-xmlrpc.fcgiが、エラーが出てうまくFastCGIで動かなくなってしまった。
個人で勝手に改造していたmt-xmlrpc.fcgiはともかく、単にMT::App::CMSの実行スクリプトをFastCGI化していただけのmt.fcgiが動かなくなったのは痛い。
仕方なく両者は一時的にCGI動作に変更。
mt-commentとmt-tbはなんとかうまくFastCGI動作してくれているようでよかった…と思いきや、時々mt-tbの方が挙動不審。
本当に問題があるのかちょっと不明だが、挙動からしてあるとすれば永続化環境での問題が残っているっぽい。
この辺、どうやって解決したっけか忘れちゃったなあ...。

SixApartの中の人も、UO Patchの存在とか知らないわけじゃないだろうし、どの問題をどこまで取り込んで解決したのかはっきり言及して欲しいなあ。
でないとこういうメジャーバージョンアップの時、どれだけ手作業でパッチあてないといけないのか判らないので、不安で中々乗り換えられない...。

まあしばらくPerlも触ってなくてコーディングの勘もにぶっているので、リハビリがてら問題点解決に付き合いますか。
とりあえずひとつひとつ解決しないと悲惨な状況になるので、Tagwireプラグインのタグをネイティブなタグ機能に置き換えるのは、また後日。

昨日、ねねが

.

まるごとPerl! Vol.1 posted with amazlet on 06.09.10 小飼 弾 宮川 達彦 伊藤 直也 川合 孝典 水野 貴明 インプレスコミュニケーションズ (2006/08/24) Amazon.co.jp で詳細を見る

まるごとPerlのPerl6記事を見て、触ってみたくなったのでPugsをインストール。
まずGHCをrpmから入れて、続いてPerl6-Pugsをインストール。
もちろん、PUGS_EMBED=perl5は設定してコンパイルした。
GHC入れる時のライブラリ依存性とか、pugsインストール時のgccのバージョン起因のエラーとか、いろいろあったがうちの環境起因で、Pugsそのものには関係ないので詳細はパス。
とりあえず入った。
perl5のモジュールツリーの隣に、ちゃんとperl6のモジュールツリーができてる。

簡単なワンライナーとか試してみる。動く動く。
CGIとかにしてみても普通に動く。
なんか感動。

でも、use Perl5:LWP::UserAgentとかって記法を使えば、Perl5のモジュールも使えると言う話だったのだが、何故か使えない。
単純に上のようにすると、@*INCの中でモジュールが見つからないとエラーが出る。
perl5と連携させてコンパイルしたから、自動的にPerl5のモジュールにパス通っているのかと思ってたら、通ってないのね...？
それで、今度はPerl5のモジュールツリーのパスを@*INCにpushして試してみる。
すると今度は、

pugs: user error (***
    unexpected "("
    expecting comment, "?", "!", trait, operator, ":", ",", postfix 
        conditional, postfix loop, postfix iteration, ";" or "}"
    at /usr/local/lib/perl5/5.8.7/strict.pm line 14, column 19
       test.pl line 1, column 1)

というエラーが出て、うまく動かない。
なんだこのエラー？ unexpected "("？？どこの話だかさっぱり判らない。
自作モジュールでも標準モジュールでも、ほとんどこのエラーが出て利用できない。

ただ、まるごとPerlに載っていた、use Perl5:LWP::Simpleはエラーが出ずロードできる。
ところが、同じくその続きに書かれているLWP::Simple.get("http://example.com/");を実行しても、getなんてメソッドはありませんと怒られてしまう。
また、こいつはPerl5のモジュールツリーのパスを@*INCにpushしていなくても、ロードに成功する。
思うに、単にPerl6側のLWP::Simpleを呼んでいるくさい。
なんか挙動がよく判らない。

これはどうなっているんでしょうか？
どうやったらPugsでPerl5のモジュールが使えるようになるのでしょう？
教えて、エロイ人。

---- 追記 ----

コメント>　use perl5:LWP::Simple;のように小文字にすれば使えるはずです。

使えました！
たったそれだけのことだったとは。ハズカシス。
またこの方法だと、Perl5のモジュールツリーのパスを@*INCにpushする必要もなく使えますね。

こんな本が出ていたので、買ってみた。

Mobile2.0 ポストWeb2.0時代のケータイビジネス posted with amazlet on 06.09.01 インプレスジャパン (2006/8/31) Amazon.co.jp で詳細を見る

私自身、ケータイは常に使いこなしているし、勝手サイトも作ってきた経験上、ケータイ事情には詳しいつもりでいたが、その一方で、飽くまでケータイWebは、PC等から見られる広いインターネットを、あらゆる時・あらゆる場所から発信・受信出来る為の「窓」としての役割としてしか捉えていなかった。
もちろん、位置情報総合サイトを標榜してきた以上、PCではできないケータイデバイスの「今・ここ」情報の発信・受信を追及してきたつもりだが、しかしそれですら、正直言うと既存のWeb世界に位置という新たな見地からの串を通す・串を加えるという発想しかなかった。
なので、先日このエントリで驚きを表明したとおり、膨大な数のケータイでしかWebを使わない層、そしてそのケータイユーザのためだけに作られ盛況な、一般WWWとは切り離されたケータイ専用のWebという世界の存在、そしてその豊穣さには、私もつい最近気付いたばかりだ。
そしてその豊穣なケータイWebの世界で、今大きな変化が起きようとしている。
ケータイ「知ってるつもり」だった私も、もう一度頭を柔らかくして、その変化の方向を捉えなおさなければと思っているが、その一端を掴むのに格好の良書であると思う。

著者の一人は、ケータイ位置情報SNS「Activo」、ケータイ位置情報版AdSenseとも言える「AdLocal」等のサービスを展開している、シリウステクノロジーズの宮澤さん。
彼の言う、Mobile2.0ではWebのアチラ側（ネットの向こう側の膨大なコンテンツDBの世界）とコチラ側の融合が新たな価値を生み出すと言うのは、全くその通りだ。
まさに長年、言いたかったことを言ってくれたと言う感じがする。
ここでいうコチラ側とは、ケータイデバイスでの「位置情報」「時間情報」、言い換えれば「今、ココ」ということだ。
動かないオフィスのPC上で、検索ワードに「牛込柳町」「ラーメン」と検索ワード入れてひっかける情報より、今どこにいるかも何時かも正確には判らないけど、ケータイデバイスが自動的に付加してくれるGPS情報「ココ」とアクセス時間「今」、及び検索ワード「ラーメン」を元に、サクッとその場で入手できるまさに今ココで営業しているラーメン屋の情報の方が、便利に決まっている。
そして、その分野では、あのGoogleですら、モバイル版Googleローカルと言うのはあるが、（簡単にHACKできるとはいえ）いまだにデバイスのGPS機能とは連動していないし、また提供している情報も、モバイルコンテンツをクロールして得た情報ではなく、インターネットタウンページかどこかから買ってきたのであろう画一的な情報が検索されるばかりだ。
「今、ココ」で発信された面白い情報を、「今、ココ」で受信する、というような経路は、いまだに実現されていないと言っていい。
要するにMobile2.0の世界では、Googleですらサービス提供者としてはヨチヨチ歩きの赤ちゃん状況で、強者は誰かまだ決まっておらず、新しい価値観引っさげて誰か参入すれば、たちまち「Next Intel Inside＝膨大なデータ蓄積」を得て強者になれる可能性は転がっているという事だ。
そしてそれを前進させられるのは、GPSやICカード、QRコードリーダ、等等、これだけ豊潤なケータイデバイスに恵まれた国、日本以外にあり得ない。
一般インターネットの世界でのWeb2.0では、日本は外国の後追いになっている感は正直否めないと思うが、Mobile2.0では日本が先んずる事ができる、いや日本以外にそれができる国はあり得ないといっていい。
万一、これだけ恵まれた環境が整っているにも関わらず、この分野でもまた日本が出遅れて後追いになるようなことがあれば、恥ずかしい事だと思う。

とはいえ、日本は恵まれていると書いたが、必ずしも恵まれてばかりではない。
なぜそれだけ恵まれているにも関わらず、これまであまりこの分野が育ってこなかったか？の原因ともいえる、日本ならではの問題もある。
ずいぶんマシになってきてはいるようだが、キャリアによるユーザ囲い込みの問題である。
それも昨今は、DoCoMoが検索機能の結果として非公式（いわゆる勝手）サイトも出してくるようになったり、番号ポータビリティの導入も本決まりになったりと、改善の兆しは見えつつある。
その辺の、ケータイWebの可能性やよい面だけではなく、ケータイWeb業界が抱える問題やその状況なんかも、この本ではしっかり押さえてある。

盛況だとは聞くのだが、PCから見えるWebの世界だけにどっぷり浸かっていると、見えてこないケータイWebの世界。
それがどのような世界なのかちょっと覗いてみたい人から、飛び込んでみたい人まで、取っ掛かりとして薦められる本だと思う。

きょうここがねねがここへスイッチメモするはずだったみたい。
ここへねねがここへねねのスイッチメモする？
ここは、ここでねねはスイッチみたいなメモするはずだった。
ねねはここへスイッチとかメモしたいなぁ。


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

まあちょっと親バカ入るエントリになるかもしれませんが。
子供の能力の成長とは恐ろしいと言うか、不思議なもんです。
ほんの少し前まで怪しかった能力が、突如すっとんでステップ関数的に向上してたりする。
それも、別に何を教えたわけでもないのに。
親がなくとも子は育つ、とはよく言ったもんだなと思います。

先日朝食時、息子が片手の人差し指と中指で机の上を歩くようにしながら何か言っているので、よく聞いてみたら、「１メートル、２メートル...」等と自分の食器と親の食器の間の距離を測っていたのです。
「お父さんのお皿と僕のお皿6メートル離れているねー」とか。
無論、子供の指の間が1メートルなわけはないので、事実としては大間違いなのですが、ほんの少し前まで数を数えるのも怪しかったのが、いつの間にか離散的なものの個数を数えるなんてレベルを超えて、連続的な量を単位に分けて数えると言う概念を習得してしまっていたのです。
別に教えたわけでもないのに。
これには驚いてしまいました。

空間認識能力の成長もなかなか驚かされます。
以前、某コンビニのスタンプラリーをしていたのですが、家の最寄の4つほどある駅のうち、普段ほとんど使わない駅から一度降りた時に、その駅の近くに、今まで知らなかったスタンプラリーを行っているコンビニの店舗があるのに気付きました。
生憎その時はスタンプラリーの台紙を持っていなかったので、「次こっちに来た時に押しにこようね」と言って、その日は帰りました。

数日後、今度は前の駅から300mほど離れた、いつもよく使う駅から息子と降りたことがありました。
その時はスタンプラリーの台紙を持っていたので、前の店に押しに行こうという話になりました。
で、たわむれに「さあ、あの店はどこか判るかな？」と問いかけてみたら、「こっちだよ」と案内してくれて、あっという間に件の店まで案内してくれたのです。
今まで息子を連れて、そのルートの中の局所局所は通った事はあるものの、通貫して歩いた事は一度もなかったのに。
よく見る建物、風景などから断片を組み合わせて、自分なりの近所の地物の位置関係を掴んでいたみたいなのです。
これには舌を巻きました。

文字なんかも、ちょっと前までひらがなのカードとか与えてやってもなかなか怪しかったので、まだ難しいかと思ってその後ほったらかしてたら、いつの間にかひらがなどころかカタカナまで、濁音まで含めほとんど完璧に読めるようになってる。
なんで？何時どこで覚えたの？という感じです。

かと思ったら、一方で、「ネコの小さいのはコネコ、イヌの小さいのは、コイヌだよね。それじゃ、トリの小さいのは？」と聞いて、上に「コ」をつけるという規則性を類推させようとしたことがあったんだけど、これはさっぱりだったりする。
自分で類推できるどころか、いくら言葉で説明しても駄目で、スケッチブックに猫と子猫、犬と子犬、鳥と小鳥の絵と読み方を書いてやって、やっと理解してくれた。
大人から見て「これは難しいだろう」というようなハードルを軽々いつの間にか越えてる一方で、大人から見たら「超簡単だろう」と思えるような単純推理なんかは難しいようで、本当に子供の能力って不思議です。

PCから見るWebの世界と、ケータイから見るWebの世界は別物なのだなあと実感

で紹介した、Mixi以上の成長率を示しているケータイからしか見られない専用サイト：BitPetsですが、私も参加してたまにケータイSphereの温度を偵察に覗いたりしてます。
しかし中々熱いです。
話題としては、みんな身近な日記がほとんどなのですが、どんな些細な内容でも大抵コメントがついててコミュニケーションが成立してる。

驚いたのは、ケータイしかユーザインタフェースがないのに、下に紹介するこんな長文エントリすら、投稿してる人がいたことです。
ケータイで全部打ったんだろうか？
メールで転送して、コピペした？それにしても、ケータイのクリップボードは記憶できる文字数限られてるので、メール画面とWeb画面切り替えつつこれだけのコピペしようとすれば相当な手間のはず。
その手間の割にケータイだけにしか見てもらえないと言う世界に、それでも打とうという人がいるのですから、どれだけアクティブな世界かというのは想像するに難くないでしょう。

ちなみに、私はケータイからコピペしたわけではなく、同じ心理テストをPC上で探してそこから取りました。

ある所に五人の仲のよい男女がいました
構成は男がB,H,Mの三人、女はL,Fの二人でした
また男のHと女のLは恋人関係でその事はみんな知っていました

そんなある日、五人はフェリーを借りて海に向かいました
ずいぶん沖まで行った時、フェリーのエンジンに異常がある事に五人は気づきました
「このままでは船は沈んでしまう！」誰かが叫びました
この船には非常用ボートが積んでおらず、しかたなく遠くに見える島まで泳ごうと言う話になりました
五人は海に飛び込み必死で泳ぎましたが、途中で海が荒れ始め、五人は離れ離れになってしまいました

しばらくして五人は意識を取り戻しました、どうやらどこかの無人島にたどり着いたようです
しかも困った事にお互い声の届くぐらい近い二つの島に二手に分かれてしまったようなのです

A島にはBとLとF、B島にはHとMしかも二つの島は声はかすかに届くのですが、あいだの海が荒れており、とても泳いでいけそうにないのです
また女のLは恋人のHと別れてしまったのがショックだったらしく、一刻も早く彼氏と会いたいと思ってました

そんな状況の中、Bがいかだを作り始めました
慣れない作業のため、不恰好ではあるけどなんとか一人が乗れるぐらいの大きさのいかだが完成しました
これに乗って島から脱出しようと考えたBはさっそく準備に取り掛かりました

そんな時、いかだの完成を知ったLがどうしても恋人のHに会いたいからそのいかだをゆずって欲しいと言ってきました
せっかく苦労して作ったいかだをゆずるなんてもったいない、と思ったBは最初は拒否しましたがあまりにもしつこく迫ってきたため、Bはある条件を飲んでくれたら、あげてもいいと言いました

 

その条件とは一晩Lの体をBの自由にさせろと言ったものでした
さすがにLもそれには迷いました、しかし一刻も早く彼氏のHに会いたい・・
Lは心の中で葛藤していました 一人では決められないと思ったLは友人のFにその事を相談してみました

しかし、Fの答えは「自分の事なんだから自分で決めなさい、私には決める事は出来ない」と関白なものでした
Lは迷いに迷い、恋人のHに会うためにBに体を捧げる事に決めました

そして、一晩がたち、身も心もズタズタになったLはいかだを手にいれました
さっそくいかだを使い、HのいるB島にたどり着きました
感動の再会です
Hは驚きましたが、やはり恋人であるLが来てくれた事を嬉しく思いました
しかし、体を他の男に捧げてしまった事に負い目を感じる清いLの表情は暗くなってしまい、その事にHは気づきました
あまりにも暗い顔をするLを怪訝に思い、問いただしてみた所HはLの体がBに汚された事を知り、深くショックを受けました
事実を知ってしまったHと汚れてしまったLは自然に気まずくなりました
そして、Lが自分に会いたいが為に取った行動とは分かっていたものの心のどこかでLの事が許せずHはLに別れ話を持ちかけました
あんなに愛し合っていたのに
Hに会いたいが為に取った行動なのにそのような結末になってしまった事にLの心は壊れかけてしまいました
もう死んでしまおうかとまでLは思いました

そんな時、話を全部聞いていたMが突然Lの前に現れ
「君の行動が間違ったものじゃないよ、理解できないHが悪いんだ」とか言いました
Lの傷ついた心にMの言葉が染み込み半分洗脳のような形でLはMの事を好きになってしまいました
しめしめと言った感じでMはLと付き合う事になりましたとさ、おしまい

 

 

さて・・・始めに話したようにこれは心理テストです
まず自分の中でこの五人のなかで共感できる順番を決めてください、こんな風に

共感できる-　L←H←B←F←M　-共感出来ない

 

 

 

 

決めましたか？
それでは種明かし
これは自分の中で優先する物事の順位を表しています

LはLove（愛）
BはBusiness（仕事）
FはFriend（友好関係）
HはHumanity（慈悲心、人情）
MはMoral（道徳心）

を表してます
つまり上の例では
愛を一番大事にして次に人情を大事にします、だけど道徳心はあまり大事にしないようです
大体こんな感じです、どうでしたか？新しい自分を見つけましたか？

長い間触ってなかったが思うところあり久々にここギコサーバにMapServerを入れてみた。
しばらく見ない間に4.8までバージョン上がっていたのか...まあ知らない間に大きく育って...父ちゃん嬉しい。

本当に久しぶりなので、よく考えれば前のサーバ障害以降必要ライブラリも全然入れてなかったので、GEOSやPROJ.4、GDAL/OGRどころかlibiconvやlibgd、libtiff、libfcgiから入れると言う状況。
でもまあ順調に入って、できたmapservをFastCGI起動設定してアクセスしてみると...起動しない...。
コマンドラインやCGI動作だと動くので、あれ？と思ってmapserv -vの結果をよく見てみると...。

MapServer version 4.8.4 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP OUTPUT=SVG SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=GEOS INPUT=TIFF INPUT=EPPL7 INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE

あれ？SUPPORTS=FASTCGIが表示されてない。
別にコンパイルでも何のエラーも出なかったけどなあ...と思って色々チェックしてみると、何故か./configureの実行結果の中で、FastCGI対応チェックがこけてるっぽい。

configure: checking whether FastCGI support should be enabled...
checking for FCGI_Accept in -lfcgi... no

よく判らんけど、どうもこれでFastCGIがオプションから外されているっぽい。
仕方ないので、試しにMakefileを覗いてみたところ、FastCGIのところが

FASTCGI=
FASTCGI_INC=-I/usr/local/include
FASTCGI_LIB=-L/usr/local/lib -lfcgi

となっていて、オプションのフラグだけが消されているだけで、パスとかはちゃんと設定されているみたいだ。
なので、直接オプションを

FASTCGI= -DUSE_FASTCGI

と書き換えてMakeしてやったところ、mapserv -vでもSUPPORTS=FASTCGIが出るようになり、普通にFastCGI起動できるようになった。
めでたしめでたしではあるが、なんで./configureで弾かれるのだろう？

後、FastCGI起動できるようにはなったのだが、httpd.conf等に設定しての事前起動でしか動かない。
拡張子を.fcgiとかに変えての、ダイナミックサーバ起動だとうまく起動できない。
これは仕様なのか、それともうまくコンパイルできてないのか、どっちなんだろ？
中村区アディクトさんの古い記事なんかみると、ダイナミック起動もできてそうな感じなんだけど...。

ちょっと亀ですがWEB+DB PRESS 34が届いたので読み中です。

WEB+DB PRESS Vol.34 posted with amazlet on 06.09.01 技術評論社 (2006/8/24) Amazon.co.jp で詳細を見る

弾さんのHaskell入門、OpenID等の認証API等、今回も読みどころ満載でしたが、個人的に一番のニュースと言えば、やはりMapServerの入門記事が始まったことです。
日の当たらないｗ世界で耐える事幾星霜、ついにGIS記事がWEB+DB PRESSに進出です！
これで、GIS人口も増えるか？

ちなみに執筆者は地図日記２で知られるアシアルの森川さん。
「入門Webマッピング発刊記念＆Where2.0好きな人の集い＠横浜」でも、私の呼びかけに応じてプレゼンをしてくださった人です。

この連載で、以前書いた

世間ではその「オープンソース」とやらは、所詮LAMP（「L＝Linux（プラットフォーム）」「A＝Apache（プレゼンテーション層）」「M＝ MySQL（データ層）」「P＝PHP（ロジック層）」）の言葉で代表される分野にしか視野は当たってなくて、それ以外の世界があるという事にも気付いていないのだなあと実感。
常に動きの中心にいるGoogleが、最初は測地系も投影法もろくに判っていないところからGoogle Maps始めて、いまや押しもきらないGIS分野の中心プレーヤーになりつつあるというのに、その信奉者連中にはまだ全然GISの情報等浸透していないのだなあ、と思うとがっくりくる。

といった状況が改善されればいいなあ。

ちなみにオープンソースGIS関連の記事といえば、こちらはGIS専門誌ですが、

GIS NEXTという雑誌に、オークニーの森さん達が少し前から執筆しています。
こちらも要注目ですねー。

ウィンドウサイズを小さくすればいつも崩れるのだけど、普通サイズでも崩れてる状態が1週間ほど前から。
ごめんなさい。
あまりIEから見ないので、気付くのが遅れました。

というか、根本的になんとかしたいのでデザイン募集もしたんですが、今のところ応募ゼロ。

でも腑に落ちないのは、どこの誰がやってくれてたのかは知らないのだけど、一応某所で、今とルック＆フィールは同じで崩れないデザインを、作ってくれてる人がいるのは見つけたんですよね…。
そこからのアクセスがあったので、リファラーを辿って気付いたんだけど…。
それを採用すれば解決？なんですが、それを作ってくれたであろう人からはいまだにコンタクトもなく、勝手にそれを使っていいものなのやら何やら判らず…。
とりあえず、それを作ってくれた人が応募してくれるのを待っているところなのですが…。

作られた方、もし万一メール等でコンタクト済みと考えておられましたら、SPAMメール判定で弾かれる等で私の目に触れていない可能性があります。
その場合は、とりあえずもう一度コンタクトしていただけると幸いです…。

またトラックバックをいただいた。

A Lousy Excuse ! -albinoalbinism-

とりあえず前置きしておくと、議論ってのは互いの前提が異なれば、お互いが紛れのない100％無謬な論理を尽くしたところで、決着はつきようもないもんだ。
albinoalbinismさんがこだわる「現象としてロングテールという現象が観察されるか否か」が議論の前提なのだとすれば、議論尽くすまでもなく俺も「ええ、確かに観測されますね、おしゃるとおり」と首肯するしかないが、そんなもん今更持ち出さなくてもWeb1.0の時代から「Webサイトの8割はゴミ」と言われていたことなのであるから、自明であって今さらわいわい言う必要のないことだ。
俺はそんな自明な現象論には今さら興味なくて、もっと実学的な、「観測されるロングテールの需要に対する網羅性」という質的な部分に興味があるのであって、albinoalbinismさんがそれに載らないのであれば、こんな応酬を何千万回繰り返そうが何ら意味のある結論にたどり着きはしない事は判りきっている。
よって今回のレスポンスも、いちいち反論するのも馬鹿馬鹿しいので最低限の範囲に留めさせていただく。

前回のエントリの要旨は、「個人」には「大した需要が見込めないようなコンテンツをアップするようなモチベーションが働」かないので、「群集はロングテールの消費者たりえても提供者たりえないのではないか」ということであった。これに対して「提供者」がどう思おうがテールは長くなると反論したのだが(だって「提供者」が曲線をコントロールできるならみんなヘッドになっちゃう筈だもんねw)、今回のエントリは何故かテールを形成する個々のコンテンツの質(｢糞｣か｢味噌｣か)の話に摩り替わっちゃってる。

駄目だよー、要旨を変えちゃ。そんなこと前回のエントリでは一言も言ってなかったじゃない。

要旨を変えるも何も、誤読されうる文章を書いたのは俺側のミスではあるが、最初から俺は需要に対する供給の網羅性という、質の問題を話している。
先にも書いたように全体としてのロングテールが形成されるなんていう現象論は、今さら取り上げるまでもなく自明の事なのでわざわざ書いていないだけで、そのパラダイムの中で話している。
その上で、最初のエントリからAmazonの網羅性との比較を論旨の中に入れているので、当然質の問題として読んでもらえるだろうと思い込んでいただけで、よもやロングテールが形成されるかどうかの問題などと誤読されるとは夢にも思わなかった。

でも、ちゃんと行間を埋めて読んでくれてる人は、最初の文章から「質の問題なのだな」と受け取ってくれてる。
はてブを見ても「義務のないところで網羅されるかどうか、という話か。」というふうに、まさにキーワードであるところの「網羅性」を含めたコメントをしてくれている人もいるし、コメント・トラックバックを見ても正しく読み取ってくれている人もいる。

とはいえ、otsuneさんも言われるとおり一部であっても誤解される文章を書いた場合は、読み取る方が悪いのではなく書いた方に問題があると思うので、その点では最初のエントリで誤解されたのは私の方に非がある、申し訳ない。
なので、「誤解されたときは、さらに言葉を重ねるなり、その他いろいろな担保を提示したりして意図を伝えればいいのだ」ということで、受け取ってもらえなかった行間を説明すべく、2つ目のエントリを書いた。
そしたら、何だ？要旨を変えた？要旨を変えたと見える部分が、自分が受け取る事のできなかった行間だと言う考えも思い浮かばなかったのだろうか？

最初のエントリが誤読されやすかったことは認めるが、ちゃんと読み取れている人だっているにも関わらず、わざわざ行間を埋めてやってもまともに意図を理解できないとは、相当に読解力或いは議論を交わす能力が低いか、もしくは煽ることそのものを目的として煽っているとしか思えない。
いずれにせよ、まともに議論の成立を期待できるとは思えない輩であることは確かなようだ。