Google、マッピング技術を開発者に開放

Google Mapsとその他の情報を組み合わせたサイトは既に多数存在しているが、正式にはサービス契約に違反していた。
今回の決定で、こうしたサイトの開発は違反ではなくなった。

キターーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー！

HTTP::MobileAgentの改修案の第一弾、とりあえずSubversionのディレクトリに挙げました。
...が、挙げてしまってなんですがまだあまり見ないでください、まだいろいろ改修しないとあれなので。
例えば今、バージョンナンバー0.30に多くのモジュールをしてしまっていますが、とりあえずリリースできるまではα版として0.29_xxの形に直したいと思ってます。
今の処、

• サブクラスまで移植
  現行HTTP::MobileAgentとHTTP::MobileAgent::Plugin::Extensionのテストスクリプトでエラーを出さないところまでは完了。
• IPチェック部分移植まだ
• yappoさんパッチ分移植まだ
• サブクラス分割インストール手段を考える
  せっかくサブクラスを別開発するのだから、インストーラ上でもサブクラスを別ディレクトリに分けて、既にインストール済みのサブクラスと比較してバージョンが低ければサブクラスはインストールしない、とかしたいと思っています。
  そのためExtUtils::MakeMakerを勉強中。

とりあえず何も考えずにHTTP::MobileAgentを使ってきた人でもHTTP::MobileAgent::Plugin::Extensionを使ってきた人でも、インストールさえすればエラーなく乗り換えられるよう、本家とExtensionで解釈の異なる機能についてはExtension動作モードをフラグとして持って、動作を振り分けるようにしています。
ですが、これは飽くまで経過措置として考えていただきたく、今後は本家側の解釈を正としたいと思っておりますので、最小限の労力でとりあえず最速で改修版の機能を導入した後、 じっくりと本家側解釈への移行を行っていただきたい、という趣旨で導入しております。
また、Extension動作モードも完璧ではなく、そもそもサブクラスの名前が違うわけなので、オブジェクトのクラス名で処理を変更、とかしている部分は、なんとかしないと動きませんのであしからず。

で、長い前振りの後実はこれからが本題なのですが、「あまり見ないでください」なモジュールのアップロードを振って何を書きたかったかというと、いやあ、coLinux+Samba+TortoiseSVNで開発すると激しく楽チンですな、という話。 
こちらで導入したcoLinux上のFedora Core3で開発しているのですが、接続自体はローカルマシン同士でSCPで繋いで、という事をやっていました。
ですが、よく考えればSambaで共有すれば直接エクスプローラ上で秀丸とかで編集してやれるな、と思って、そう設定してやりました。
すると、エクスプローラ上での開発なので、さらにSubversionへの登録も右クリックからTortoiseSVNで流し込んでやるだけなので、激しく便利なのに気付きました。
今までのように、いちいちtarballにして全体をWindows上に落としてきて...とかしなくていいのです。
これは本当に便利です。

本文の方が短いですね...。

きょうここはねねと激減しなかった？

今日は息子を連れて狂言の練習。
毎日会社の通勤で台本を黙読して...

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

前の会社で何度か挙がってた案件に、地域（地方自治体とかいうより下の、地域自治会とか、地域NPOとか、そういう先）に位置情報システム納入して、チビッ子達にGPS・カメラ付き携帯電話持たせて、ヒヤリハットな場所のレポートを作らせてIT的に公開する、といった類のものがあって、
そういう案件の場合、子供にケータイを持たせたくない、といった類のものは別として、よく反対意見として挙がってたのが、「手作業で集計して紙媒体でレポートを各家庭に配ったり、地域掲示板に張り出したりするのに比べて、どんな優位性があるのか」といった話で、まあそれに対する明確な回答は正直持っていなかったわけなんですが、

先日、うちの近くにそういった危険箇所マップが作られて近所の地域掲示板に張られているのを見て、IT化する意味が判りました。
というか、はっきり書いちゃうと「IT化しないと作る意味がない」。

これ、見てください。

地図の上にいろいろ、私のいつもよく通る道なんかにも「ここ危ない」とかマーク描いてあるんですが、何がどう危ないのかさっぱり判らないのです。
報告者によって「危ない」の視点も基準もまちまちだと思いますが、それが判らないと他人には「？？？」でしかないので、正確な場所もよく判らないし、何を言わんとしているのかさっぱり伝わってこないのです。
これが、それぞれの危険地帯の具体的な写真があって、こういう点が危ない、等と解説されていれば、ああ、なるほどね、確かに、とも頷けるのだろうけど、この図では何が何だかさっぱり。

紙媒体だってそういう補足情報を載せる事は可能だし、単に見せ方が悪いだけかも知れませんが、でも今度は1媒体で載せられる情報量が減少するのは必至。
今くらいの地域の切り分け粒度だと、ああ確かに自分達の地域、というイメージはありますが、これ以上小さい切り分けになると、その中で自分の家が含まれている区画、といっても必ずしも自分の活動テリトリーとは限らないし、むしろちょっと離れたところの方が主テリトリー（駅への通勤路とか）というケースも多々ある気がします。
地域切り分けは今ぐらいの粒度で、その中で自分の活動エリア内での報告等、受け取り手が興味を持った報告のみ、詳細をオンデマンドで配信する、という形態をとらないと、肝腎な事がさっぱり伝わりません。
そういう形にするには、Webなんかで全体像を配信して、危険地帯アイコンをクリックすると詳細が表示される、といったIT手段でなければ行えないのではないか。

もちろん、そういう形にする事によって、本当に危険地帯情報等が必要な老人や障害者等、社会的弱者にディジタルディバイド問題のために伝わらないのではないか、という懸念は生じます。
でもだからといって、それは区民センターや老人施設等、そういった方が集まる場所に、判り易いインタフェースの端末を準備し、かつ職員に操作を説明できるよう教育を行う、といった運用等の工夫でカバーすべき問題で、そもそも誰にも情報が伝わらない手段に逃げてそれでよし、という問題でもないでしょう。
それならそもそもやらない方がマシ、金の無駄、じゃないでしょうか（ちなみに、地図というのはWeb配信だけではなくて紙・印刷媒体でも高く、著作権をクリアして配布物等を作ろうと思えば、配布数に応じてそれなりの金額がかかります）。

というわけで、ヒヤリハットマップ等の広報には、できる限りIT的手段を用いないと意味がないのではないか、という事を提言として挙げたいと思います。

※なんかBlogWriteでうまく画像がアップロードできない...ので久々にectoで投稿です。

[composed and posted with ecto]

ずいぶん古い記事にコメントもらって紹介いただいたのですが、

ポジタル

災害用に備えて自分用に作っていたものをサービス化しました。
まだアルファ版なのですが、最近地震が多いので公開しました。
また、位置情報機能をいろいろとつけています。
収集したニューススクラップやブログ記事、ブックマーク、掲示板のスレッドに位置情報をつけるので、既存のURLでアクセスできるコンテンツすべてに位置情報をつけて、位置キーによる検索対象にすることができます。
iモードの位置処理部分にはここギコさんのモジュールを利用させていただいています。

という事なので、見させてもらいましたが、すごいです、ココ。
少なくとも、「自分用に作ってたのを公開」レベルじゃないですね。

単に知人への災害通知にとどまらず、SNS機能も非常に充実しています。
知人ネットワークの表現も、単なる「knows」にとどまらず、関係の深さを示す事でネットワークの太さを表現できるようになっており、中々面白いです。
RSSリーダ等いろんな機能がてんこ盛りなのも、ワンストップチャネル化指向の私的にはよい感じ。
いろいろ機能を説明したヘルプはこちら。
位置の取得も、待ちうけJavaアプリの準備（今のところau用のみ）だけでなく、例のwmlを使った連続位置取得にも対応。
PCからもいろいろ位置情報を使えるようになってて、特筆すべきは「地図サイト表示→BookMarkletで現在位置を取得」できるようになっている事！
コレ俺も作ろうと思ってたんだよね...今PCで一番簡単に、多分著作権面も多少グレーゾーンは残しながらもクリアできる最良の手段だと思います。

どうもこちらの方が作っている模様。
デザインも企画もコーディングも一人でやられているんだって...すごい。
機能だけでなくヘルプやプライバシーポリシー、規約なんかも充実させてて、ほとんど商用サイトです。
ごめん、一つの運営者は知人なので言いにくい感もありますが、今までの携帯位置情報系SNS（他のは商用）の中でもっとも完成度が高い気がします。

といいつつ、私の持っているA5505SAで位置が取れなかったりと、一人でやられている分テスト環境や情報が不十分な部分はありますが、その辺はフィードバックでフォローしていけばよいので、今後どんどん面白くなっていくんじゃないかと思います。

個人的な疑問というか意見としては、Activoもそうだったんですけど、どうしてログイン時に簡単アクセスとして、端末IDやユーザIDを使わないんでしょうかね...。
キャリア側が通常の規格の外側に拡張している規格ですし、さらに不安であればIPチェックなんかと組み合わせればさえ、ID/PWよりよっぽどセキュアな認証だと思うのですが（https使っているわけじゃないんですし）。
もちろん、端末/ユーザID系が取れないキャリア/機種も存在するので、ポジタルがやっているような「秘密のハッシュキーを含んだURLをお気に入り登録させて簡単アクセス手段とする」ようなアプローチも必要ですが、それにしても、URLの中にハッシュキーを埋め込んでしまうのは、危険かなあと思います。
私がアンテナ奪取でやってたのは、秘密のハッシュキーを埋め込んだURLへのリンクをつけたページを発行するんだけど、そのページのURL自体にはハッシュキーを入れず（セッションがあるからできますよね）、そのページをどのキャリアの携帯にもたいていある「画面メモ」機能で覚えてもらう、というやり方。
ハッシュキーを埋め込んだURL自体は、アクセスするとすぐにユーザ認証→セッション生成してリダイレクトすれば、正規ユーザにさえハッシュキーは判らない。
...まあhttps使ってなければ何やっても一緒かもしれないけど。

Continue reading

会社の会議で、SpatialとかGeoSpatialに関するお話が出ました。
曰く、O社やI社のRDBの空間拡張は、GeoSpatialに対応しているけど、D社のはSpatialにしか対応していないとか云々。
要するに、同じように空間拡張されていても、単なる2次元座標拡張か、それとも座標を球体表面として扱えるか、という事だけど。

例えば、北極点が含まれている地図、というのを探す時に、地図4隅の経緯度が「80度N, 0度E」「80度N, 90度E」「80度N, 180度W」「80度N, 90度W」という地図があったとすると、GeoSpatialなDBだとこの地図を検索してくれるだろうけど、SpatialなDBだと単なる線にしか受け取ってくれないので、 検索できない。
（実際に触った事がないので、飽くまで想像ですけどね。本当にGeoSpatialでも、特異点とも言える極点を挟んでそこまでやってくれるのかは知らないけど、本義にはできないとアレですよね）
まあ、北極点を扱うような要件はないんだけど、やっぱりPOIを含む地図の検索などに多少の誤差が出るので、取引先の関係でD社のDBしか使えないうちとしては、「その位の誤差は許容範囲かねえ」とか言ってみたり、D社の技術者の人に半分冗談半分本気で「対応してくれるよね」とか脅して？みたり、ゴニョってたわけですが。

遠い昔にこのエントリで書いた問題も同じ問題なので、その意味ではPostGISもGeoSpatialじゃなくてSpatialなんですね...。
 実際に触った事があるのがPostGISだけなので、GeoSpatialなDBって、どんなインタフェース持っててどんな内部データ構造してるのだろうと考えると興味津々。
ちょっとO社の奴、いろいろ調べてみようかな...。

#去年春のIPAXの会場で、O社の営業の人から「O×× SpatialはO×× Standardでも標準で対応するようになったので、より試してもらい易くなった」見たいな話を聞いて、その後自分でも裏付けたような記憶があるんだけど、今探しても情報が見つからないな...。

飽くまで専門家（俺じゃないっすよ）がこだわるレベルで、の話で、「オモロゲ」には影響しないっすけどね。

Google Mapsの衛星写真って、オルソされてないんですね。
これ、うちの近所なんですけども、高いビルの壁面とか思いっきり見えてて、どの方向の視点から撮ったか丸判り。

というか、俺も4ヶ月前から今の仕事につくまでは「オルソ」なんて知らなかったんですけども（今も自分でやっているわけじゃないけど。そんな楽しそうな事やってる同僚を横目に手配師みたいな事とかやってたり）、逆に最近知ったばかりなだけに、「衛星写真＝オルソされた写真」という思い込みを持ってたりしたんだけれども、そういうわけでもないんですね。
まあ当たり前か...加工手順が余分に入っている＝データとして価格が高くなる、と言う事だし...。

でも、真上からの図に補正されていないズレまくりのままの写真っちゅう事だから、切り替えられる地図と重ね合わせても重なり合いはしませんわな。

というか、それ以前に、nishiokaさんとこのコメントにも書いたけど、Google Mapsの図法って、衛星画像（正距円筒図法っぽい）と地図（メルカトル図法）で一致してないのね。
相互の間で行き来する時には、流石に中心点の経緯度をキーにしてるようでおかしなところに飛んだりはしないみたいですけど。
そりゃ、オルソどうこういう前に、もっとダイナミックに重なりませんわな。

ほならなんでオルソ書いたかいうて、お前、それ「オルソ」いいたいだけちゃうんかと。

Google Maps Remixというのが流行っているらしい - Nakamura-KU ADDICT

ここまでは簡単だったのですが、僕の目的であるGoogle Maps上の任意の位置の緯度・経度情報を取得はちょっと厄介っぽい。
調べたところGoogle Mapsの投影法はメルカトル図法のようですが、中心点・スケールなどの引数は緯度経度単位系で呼び出しているおり、画面の表示単位系（多分メルカトル）と管理の単位系（WGS84 緯度経度)が異なってます。
そのため画面のクリック位置から緯度経度の算出は面倒な気が...

これ見て長年来の疑問が湧き上がってきたのですが、MapionだのMapFanだのちず丸だの、あの辺の普通のWeb地図サイトの投影法って、どういうアレなんでしょうか？

昔携帯版ここギコを作るために、MapFan・ちず丸あたりで、経緯度何度変われば何ピクセル移動するか、その逆、も試した事があるのですが、どう計算してみても、またどの地図サイトでも、ピクセル：経緯度度数は日本全国どこでも一定（つまり地図中心点からクリックした位置までのピクセル距離が判れば、単なる比例計算で経緯度が導出できる）という結果が出ていた。
（もちろん、さすがにその「一定」の比例係数は、軽度と緯度では異なったけど）
当時は投影法には詳しくなかったので、おかしいとは思わなかったどころかそれが当然だと思ってたけど...（今だって詳しくは全然ないけど）。

経緯度がそのままピクセル上のXYの直交座標に置き換えられて、しかも経緯度：ピクセルの比は日本全国どこでも一定という投影法ってあるのでしょうか。

• 単にメルカトル図法で、日本国内ぐらいだと経緯度：ピクセル比が感じられないレベルの誤差範囲内に収まってるだけ？
• それとも、ガウス・クリューゲル図法（≒ユニバーサル横メルカトル）で地域毎に作った地図を、全部まとめればこんな感じになるんでしょうか。
  ユニバーサル横メルカトル（UTM)だと、 確かに経緯度が地図上でも直交座標になって、かつ地図上の座標と経緯度の比も一定になりそうではあるけど...。
  でもGIS（というよりは位置情報）好きといっても、実際の運用経験がないので、ピンとこない。
  19の各原点毎に作られた地図が、全て同じ地図上座標と経緯度の比になるのか、とか、異なる原点で作られた地図を重ねて一つの図にできるほど、接合部分の誤差って少ないのだろうか、といったあたりが（こちらの回答No.5でも、UTMだと隣の格子とは繋がらない、みたいな事書いてあるし...）。
• それとも、そりゃ単純に経緯度をXY座標に適当な比で割り振って、それをベースにポリゴンとか描画すれば、地図としての正確さはともかくコンピュータのインタフェース上で扱うのは非常に楽そうではあるので、そういう用途用にそんな描画しているだけ？

GIS系のエロい人、教えてください。
-- 追記 --
投影法を解説しているページみつけましたよ。
単に経緯度をXYに読み替えた、正距円筒図法っていうのもあるんですね（というか、私が挙げた3つ目そのままですが）。
Web地図サイトではこれ使っているんですかね。

余談ながら、Web系地図サイトで縮尺のスケールメモリ見ていると、ピクセルと距離（というか点間の経緯度に沿った長さ）の比も、日本全国同じなんですよね...。
つまり、ピクセル：経緯度：距離の3者の比が日本全国どこでも一定という...。
実際には、経度に沿った距離の差は沖縄と北海道では1.3倍くらいの差が出てくるはずなのに...これはさすがに、当時からおかしいよなー、と思ってたけど...。

あー。時間ねー。書けねー。スマソ。

とりあえず言及したいネタ帳。
こういう逃げはありなのか。

• 多機能ファイル転送ツール ZCopy for Win
• Subversionが1.2になってlockもできるようになったらしい。 - 浅倉卓司＠blog風味？ <- 関連１、２
• 位置情報再考 - ひゅ??の思いつき
• Google Maps Remixというのが流行っているらしい - Nakamura-KU ADDICT <- 地図の座標系の話が
• ポジタル <- このサイトすごい！すごいですけど...A5505SAで位置が取れません...。
• ヒヤリハットマップの有効性
• 位置情報携帯サイト相互連携、連携APIのUDDIみたいなもん、勝手位置QRコードの案
• OpeｎID、新Perlモジュール公開

仕事がむっちゃ忙しくなって（それでも職場を出るのは1、2位を争うくらい早いのだが...息子の世話もあるし体がそもそも持たないんだから仕方がない）、後私事でややこしい話があったりもして、この辺やこの辺も、むちゃくちゃ言及したくても時間が取れないのだが、とても共感するエントリがあったのでそいつだけ。

これからは「敬意」の時代 - 浅倉卓司＠blog風味？

大企業が下請けに出すときや、あるいは経営者が従業員に対してはもっと敬意を払うべきだとも思う。
もちろん逆も必要だと思うけど、逆は必要以上に卑屈になってるケースが多いからなぁ。

全く同感です。
その辺の最低限の人としての心さえあれば、うまくいって莫大な富だって生み出せていただろうに、それがなかったためだけに空中分解してグチャグチャになってしまったプロジェクトも、グチャグチャになり具合の規模は様々ですが、いくつも出会ってます。

逆にそういうのがうまく回っているところでは、まあビジネスは必ずしも製品の出来具合だけでは決まらないので、私の過去の実話ですが世界一の性能を発揮する装置を作っても、別の技術の台頭でその装置の必要性がなくなってしまうといった市場情勢の変化等のために全く売れなかったりと絶対成功するとはいえませんが、少なくとも「モノ」としてはいいものができると思ってます。

• BlogPetのページビューが激減！
• Googleアドセンスでのページビューは激増！
• なのにアドセンスのクリックは激減！

なーぜー。

ミステリでもなんでもなかった。
答え。
何だかんだいっても業界随一ブラウザのIEで、

• Googleアドセンス読み込み後で、かつBlogPet読み込み前のページ読み込み段階において、Javascriptエラーが発生していた
• エラー発生後、そこまでのページでの表示が残るのではなく、なぜか「ページが見つかりません」エラーに飛んでいた。

確かに、Amazon Searchを呼び出すところのJavascriptを少し変えましたよ。
土曜日に。
Firefoxで問題なく動いてたから、IEでも問題ないと思ってた。

とりあえず、元のJavascriptに戻したので、解決されているっぽい。
なんだかんだいっても、やっぱりまだJavaScript使うならクロスブラウザチェックしないと怖いね。

で、エラー出してまで何がやりたかったかというと、今のAmazon Searchって、静的な「そのページの特徴語」に対してAmazonから検索して最適な商品を出しているけど、よく考えるとページの特徴語って、訪れるユーザにとって知りたい事と一致しているかどうかは微妙ですよね。
でも、「訪れるユーザが知りたい事の情報」って、取れる場合があるじゃないですか。
ほら。
Googleなんかの検索エンジンから検索で飛んできた場合の、リファラーが見れる時。
その時は、その検索語でAmazon検索してやった結果をアフィリエイト表示してやって、検索語での商品検索結果が0だった時、或いはそもそも検索エンジン経由のアクセスでない時のみ、Amazon Searchでのページ特徴語での結果を表示する、というのを仕込んでやってたんだけど、FirefoxではうまくいったけどIEがうまく動かなかったみたい。

ちょっとでもコードを書く量を減らすために、動作原理としては相当鬱陶しい事してややこしいやり方をしてたんだけど、それが仇になっちゃった感じ。
しょぼーん。

BlogPetのページビュー数で把握している限り、土曜日からページビュー数が明らかに減っている。
尋常な減り方ではない、半分くらいになっている。
2月くらいから徐々にページビューを伸ばして行き、平日2000、休日1200くらいは見てもらえるようになっていたのが、土曜日から急に平日1100、休日700くらいにまで減っている。
記事の更新も滞りがちにはなっているのでまあそれはあるにしても、それにしたって徐々に減っていくだろう。
うちの場合、意外と？（或いは当然？）Google等検索エンジン経由の訪問者が多く、固定客は少なめなので、リファーを見る限りでも、Googleでの検索結果ランクが落ちているような印象を受ける。

その観点から何かしなかったかちょっと見てみると、金曜日にこのエントリを挙げている。
ご覧の通り、犯罪がタイトル名になっており、アドセンスも表示されていない。
もしかすると、このページが危ないページと判断され、検索ランキングが相対的に下げられたのかもしれない。
もしそうだったら、飽くまでも「もしそうだったら」、エラい話だけど...今回なんか俺は被害者側の立場なのに、Googleはどういう立場からだろうが犯罪等について言及されているだけで「悪いページ」とみなす、という事になっちゃう。
犯罪の告発ページだろうがなんだろうが、「Google様」に見捨てられなくなければ泣き寝入りしろ、というアレになっちゃうな。

もし上に書いたような事が原因ならば、だいたいこの手のペナルティを食らうと3ヶ月くらいランクが落とされるらしい、と聞く。
でも、これが原因だとしたら説明のつかない不可解な事が起きている...。

Googleアドセンスのクリック数、これも、BlogPetで把握しているページビュー数に比例するような形で、ほぼ半減している。
これは予想通り。
でも？なぜか、Googleアドセンスの全体の表示回数だけが、なぜか逆に増えている...それもまた尋常ではなく、以前より2割増し程度の、これまで見た事のない表示回数が記録されている。
集計期間が、BlogPetは日本標準時、アドセンスはおそらくアメリカ時間で区切られているし、うちの場合BlogにはBlogPetとアドセンス両方表示しているけどWikiにはアドセンスがないので、両者のページビュー数が一緒になる事はないけど、これまで数ヶ月にわたって、ずっとほぼ、アドセンス上での表示回数集計数は、BlogPetの1割引かその程度で、同じ傾向をもって推移してきた。
ところが土曜くらいから、BlogPetは下がったのにアドセンス側はうなぎ登り、既にアドセンスの表示数がBlogPetで把握しているページビューの1.5倍近くにまでなっている。

これは何だろう？
こんな事があるのだろうか。
誰か、説明付けられる片、おられますか？

ここはキャリアみたいなblogしたよ♪
きのうここが、ここまでblogしたかったの♪
ここへblogしなかったー。

深刻なセキュリティホール発覚！！！-w e b d o gこれじゃナニか侵入してくるかも...

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

もう既にあちこちで話題ですが。

日本ギガバイト、COMPUTEXで披露した新製品を解説??iRAMは最大メモリ8GBに仕様変更

「i-RAM」は4本のDIMMソケットを備えたPCIカード。
シリアルATAコントローラを搭載し、シリアルATAコネクタにケーブルで接続することで、シリアルATA HDDとして認識される。
COMPUTEXでの説明時は、最大4GBまで搭載可能としていたが、その後仕様が拡張され、8GB(2GB×4)まで搭載可能となった。
利用可能なメモリは128MB??2GBまでのDDR SDRAMで、異なるメーカー/チップ/容量/スピードのものを混在可能。
DRAMの性質上、電源供給が止まるとメモリの内容が消失するが、本製品はPCIバスのスタンバイ電源で動作するため、PCをシャットダウンしても、コンセントを抜かない限り、データは保持される。さらに、専用のバッテリもカード上に搭載しており、完全に電源供給を停止しても、16時間はデータを保存できるという。

すごいな、RAMと言ったってコンセント抜かなきゃデータ消えないなら、ほとんどHDDと同じに使えるじゃないですか。
落ちてさえ16時間も持つならば、事実上消えることないんじゃないですか。
もっとも、そこを過信してそれだけで運用してたら、地震とかで短期復旧が絶対不可能な状況に遭遇した際に、とてつもない絶望に襲われそうな悪寒ですが。

定期的にスナップショットをHDDに退避させるとか仕掛けておいて、後は停電発生時に、UPSからの信号で即座に中身をHDDにコピーするスクリプトを走らせてそれが完了してからシャットダウンするようにとかしてやれば、とりあえず大丈夫なのかな。
みんな書いてるけど、ほんまにこんなのの上でDB走らせてみたいですよねえ...。
特にPostGISとか、空間DB走らせたら、どの位速くなるんだろう？
こんなのの上で走るDB上でなら、しょぼい個人レベルで手の出るサーバでも、こんなのも難なく運用できるかも...でも8GBで全データ入るかな...。
というか、アンテナ奪取も問題なく動かせたかもね。
まあその代わり、そんなサーバ貸してくれるレンタル会社あるはずないので、自宅サーバでやるしかなくなりますが...。

将来の夢がまた一つできました。
早く稼げるようになって、「i-RAM」ディスクでRAID5組む等というような意味のない贅沢に金を費やせるような身分になりたい...。

抗がん剤：新たな患者へのイレッサ使用に警告　米ＦＤＡ - MSN-mainichi INTERACTIVE

副作用の重い肺炎による死者が多発した肺がんの抗がん剤「イレッサ」（一般名ゲフィチニブ）について、米食品医薬品局（ＦＤＡ）は１７日、新たな患者にはイレッサを使うべきでないとする警告を出した。

一般名初めて聞きましたよ...。
誰か私に一般名というものの定義を教えてください。

Googleの検索結果：

• イレッサ：23,400件
• ゲフィニチブ：229件

HTTP::MobileAgent改修案ですが、サブクラス/プラグイン検知の部分については、とりあえず保留にしておいて先に進めました。
#元々遅筆・低実力な上に色々やってるので中々進みません

今回はプラグインの動的追加＆本体側に取り込んだプラグインについては無効にする部分。
これに関しては、以下のような感じにしてみました。
 

package HTTP::MobileAgent;

# ざっくり省略

sub add_plugin_method{
    no strict 'refs';
    no warnings 'redefine';

    my ($class,$method,$coderef) = @_;
    my $plugin = caller(0);
    return unless $class->check_plugin_version($plugin,${"$plugin\::VERSION"});

    $coderef ||= sub {};
    *{"$class\::$method"} = $coderef;
}

sub check_plugin_version{
    my ($class,$plugin,$version) = @_;
    my $merged_version = $class->merged_plugins->{$plugin};
    return 1 unless ($merged_version);
    return (forming_version($merged_version) < forming_version($version)) ? 1 : 0;
}

sub forming_version {
    return sprintf("%d.%03d%03d",split(/[\._]/,$_[0]));
}

sub merged_plugins{
    no strict 'refs';

    my $class = shift;
    unless (${"$class\::merged_cache"}) {
        my %cache;
        my $fh = "$class\::DATA";
        while (<$fh>){
            my @merged = split(/,/,$_);
            $cache{$merged[0]} = $merged[1];
        }
        ${"$class\::merged_cache"} = \%cache;
    }
    return ${"$class\::merged_cache"};
}

1;

__DATA__
HTTP::MobileAgent::SubClass::DoCoMo,0.20

処理の流れとしては以下のような感じです。

1. HTTP::MobileAgentのimportで、サブクラス・プラグインが自動認識され、それぞれの初期化メソッドが呼ばれる（前エントリ記述部分）
2. 各プラグイン（或いはサブクラス）の初期化メソッドから、HTTP::MobileAgent（或いはサブクラス）のadd_plugin_methodが呼ばれ、メソッドの動的追加要求が出される。
3. 追加要求されたHTTP::MobileAgent（或いはサブクラス）は、自分の__DATA__領域のデータを確認する。
   __DATA__領域には、既に本体側仕様に取り込んだプラグイン、及びそのバージョンが記録されている。
4. 確認した取り込み記録と追加要求してきたプラグインの名前・バージョンを比較し、そのプラグインが本体側に取り込まれた記録がない場合、或いは取り込まれていてもバージョンが古い場合のみメソッド追加を許可し、それ以外は拒否します。

という感じになっています。

これで何がよいかというと、本体もサブクラスもプラグインもバラバラに開発される場合を想定すると、

• まず、いちいち本体とプラグイン作者が歩調を合わせる必要がなくなります。
  既存のHTTP::MobileAgentと拙作のHTTP::MobileAgent::Plugin::Extensionなんか最悪で（すみません）、まあ本体が長年更新してこなかった部分の穴を埋めた役割は果たしたとは思うんだけど、HTTP::MobileAgent::Plugin::Extensionが本体のメソッドも何も乗っ取ってしまっているので、HTTP::MobileAgent::Plugin::Extensionを入れている限りは本体側でメソッドを更新しても反映されず、本体の更新に支障をきたしてしまう、という問題がありました。
  この動的メソッド追加の方式を導入する事で、本体側で古いプラグインに関しては取り込みを拒否する事ができ、上のような問題も解決できます。
• 機能毎の専門家であるプラグイン作者の作ったコードを、キャリア毎の専門家であるサブクラス作者が上書き修正する事ができ、役割分担で相互補完できます。
  例えば、位置情報の専門家？が、各キャリア横断で位置情報を利用できるようにするプラグインを作ったとします。
  でもそのプラグイン作者は各キャリア毎の専門家ではないので、キャリア毎の専門家であるサブクラス作者から見ると、そのやり方はおかしい、というような場合もあると思います。
  こんな場合、サブクラス側で修正したメソッドを実装してやり、かつこのプラグインはこのサブクラスでは取り込み済みですよ、と__DATA__領域に記録しておいてやると、そのサブクラスに関してはプラグインではなくサブクラス側の実装が優先され、ユーザにとって最適なロジックを提供する事ができます。
  まあ、サブクラス作者がプラグイン作者にパッチを送ればすむのでは、という話もありますが、歩調を合わせなくてもできる、という事で...。
• 別にこういう方式でやっているからというわけではないですが、プラグイン作成方式の標準ができる事で、プラグイン作成の心理的障壁が低くなり、例えばCPANなんかに登録されるとやばいコンフィデンシャルな仕様の処理プラグインが、密かにアングラで公開されてみんなハッピー？とか...（いや、そんなん奨励したらあかんやろ）。
  

とかいう感じの利点があるかなと。
もっとも、プラグイン単位で追加要請の許可/不許可を出すので、本体側があるプラグインの一部しか取り込みたくない場合とか、どうするの？といった問題は残るのですが、まあその辺は完全にコミュニケーションレスにすると言う事ではなくて、適宜話し合って決めてもらわないと仕方ないかなと。
でも何でもかんでも話し合って歩調合わさないと進まない、と言う形だと、分業開発（しかも個々が中途半端に独立しているような）とか無理かなと思ったので、少しでも楽になるような機構を考えてみました。

とりあえず、私が全部作るのもアレなので、こんな感じでぼちぼちとこちらで挙げた提案事項の実装イメージが揃った時点で、本家に提案して、 了承を取り付けてから、旗振り役が本家になるか私になるかは別として、サブクラス作者やプラグイン作者を募って公開開発みたいな形がいいかなと思ってます。

狂言の後輩の弟が今年東京の芸大に入ったんだけど、本人曰く「グシャグシャかき鳴らし系のギター奏者」だそうで、チャング（韓国の伝統楽器）とのコラボレーションがやってみたいらしいのです。
一度遊んでみたいだけなのか、継続的に活動したいのかはよく判らないのですけども。
それで、関西で一時期「ちょっとだけ」チャングをかじっていた私に相談してきたのですが、私も関西にしかチャング人脈ないし、その関西ですら元々「超ヘタクソ」以上の腕前に上がらなかったので知名度？もなく、それ経由では関東でどの程度人脈を掘り下げられるかはイマイチ疑問だったり。

というわけで、そーゆー事がやってみたいチャング奏者の方、もしよければコラボってやってもらえないでしょうか。
連絡待つ。

#関西なら打って付けの奴がいるんだけどなあ...。

今日は息子を連れて狂言の練習。
毎日会社の通勤で台本を黙読してると、ブランクもあるとはいえさすがにある程度のキャリアで間の取り方、台詞回しの緩急、あたりは想像もつくし計算もできるんだけど、計算できなくなるのは体力の配分と言うか、ペース配分というか、そういうアタリ。
家でもどこでも大きな声を出して練習できるようなところは事実上ないので、出せるのは1ヶ月に1回の練習の時だけなんだけど、そうするとブランクでパワー配分の勘所を忘れてしまい、つい最初からパワー全開でぶっ飛ばしてしまい、50分近い1人芝居なのに15分くらいで息切れが。

やっぱ何事も継続してやってないと、勘所を忘れてしまいますな。
コーディングもそんなもんなのかもしれない。

しかし舞台は10月2日で、後7、8、9の3ヶ月しか練習がないのに、いまだに息子は台詞が（覚えてるんだけどふざけたり恥ずかしがったりするので）言えなくて立ち稽古するどころじゃないし、親の方は親の方で、もう一番役を付けられて今日初めて台詞練習するし。
本当に出せるのか。
月1回、金曜夜間と土曜午後の練習のところ、金曜は仕事で行ってられないよ...という事で土曜しか参加してなかったんだけど、これは月1回、息子早く幼稚園から引き取って、親子共々金曜日も参加しないと無理っぽいなーと思いました。

新しく付けられた役は、佐渡狐という狂言のお奏者（下級役人）の役。
佐渡と越後のお百姓が都に年貢を納めに行く際、佐渡に狐がいるかどうかで言い争って賭けをする事になり、その判定を年貢納め先の下級役人がする事になるんだけど、役人は佐渡の百姓から賄賂をもらって（本当は居ないのに）佐渡に狐は居ると判定して、越後の百姓がその嘘を見破ろうとするのを、佐渡の百姓と役人で誤魔化そうとしてドタバタする、という奴。
この手の年貢百姓掛け合い系には珍しくドタバタ系の普通に笑える奴で好きなんだけど、こういう役だと世情のアレがアレだけに、アクメツされないようにしないとね...。

BlogWriteII正式版公開 - HepCat Dev and Test

当ブログExclusiveでBlogWriteの正式版を一足早く公開いたします。

 

という事なので、前からectoからの乗り換えを悩んでいたのですが、何となくお祭り・お祝い気分で乗り換え決行しました。

ectoがBlogWriteより使い易かったわけじゃなくて、単にectoには金払って正式版にしてたから悩んでただけなのですが、メインはectoで表挿入とかBlogWriteにしか出来ない事はお試し版でやってと使い分けようと思ってたけれど、ただでさえ色々シンドイのに使い分けるのも面倒なので、この際乗り換えました。
乗り換えてみて判ったけど、ectoで悩んでたアップロードファイルの保存先の固定とか、結構かゆいところに手が届く感じなんですね。
さっそく気に入りました。

乗り換えたといっても、まだ送金？手段がないようなのでとりあえずまだ購入してませんが、ベクター等にアップされれば送金したいと思います。
末永く使い倒させてもらいます。

ちょっと前の話になるけど、通勤途中の本屋で、個人情報保護法案施行に便乗のシュレッダーセールをやっていたので、何となく買ってしまった。
電動のにしようかとも思ったが、小さな子供もいるので小さな手動のものにした。
手動だと、手を突っ込んだだけでは怪我しないしね。
というか、電動は高いし。

使ってみると、労力を使うこともなく、意外とサクサクと処理できる。
家で発生するレベルの廃棄処理したい書類の量なら、これで十分だ。

というわけで、小さい子供のいる家庭にはお勧めの一品。
ニーズとしても、子供向けの通信販売のDM送り付け先とか、子供の居る家の個人情報ってどう使われるか判らないからね。

余談だけど、これを使って、これまで廃棄できなかった、個人情報満載の古い書類群まとめて処分しようとしたら、1年半前、大阪から東京に引っ越してきた際のADSL開通申込書写しが出てきた。
これ、こちらにも書いたとおり、中々開通しなくて、大阪から東京に引っ越しているのに、
「開通希望日に大阪の旧電話番号で開設処理しました！え、東京なんですか？すみません、設定変更にまた2週間ほどいただきます」
とかって大変だったんだけど、今回出てきた写しをみたら、実は私の申し込みミスだった事が判明！
廃止する回線側に東京の電話番号、開通する回線側に大阪の電話番号書いてた！
今更ながら、ごめんなさい、e-accessさん...。

[composed and posted with ecto]

うちの区民住宅で、放火未遂があったらしい。
現場は中層階（複数）の非常階段踊り場付近で紙の燃えカスがあったらしい。
俺の階のすぐそばやんけ...。

怖い話だ。
というか、俺の部屋はスプリンクラー設置階にあたるので、火事になると全体では大事にならなかったとしても、うちの部屋は大事になる可能性大。
是非ご遠慮願いたい。

[composed and posted with ecto]

4月の日記に書いたように、4月から横浜・戸塚にある「PERL」という施設で仕事をしてきたのだけれど、4,5,6の3ヶ月で都内勤務に呼び戻される事になった。
月変わりを待たずに異動になったので、昨日でPERLでの勤務は終わり、月曜から都内だ。
田舎の工場と言う、ある意味牧歌的な生活を失うが、代わりに情報が入ってこないストレス、余りものの3年前スペックのメモリ容量128MBマシンで仕事するストレスからも解放される。
新職場で待ってるのは、4月までも使ってたPen４の3GHzマシン！楽しみだ。

都内に移るとは言うものの、10月には部署全体が戸塚に移る事になっているので、3ヶ月でまた戸塚に逆戻りだが、その時は別の敷地になる事がもう判っているので、このPERLに戻ってくる事はないだろう。

さよなら、PERL。

--追記--
メモリ128MBのWin2000マシンで仕事をしていると、遠隔地（しかも相手先はADSL経由）のサーバにWindowsネットワークでアクセスする際、フォルダを1階層動くたびに結果が出るまで4-5分ほど待たされる事になり、ほとんど実用的な速度でアクセスすることが出来ない。
ところが、同じメモリ128MBのマシンでもWin98だと、思いなりに実用的な範囲内でサクサクブラウズできる。
これはなんでなんだろう？
WinNT系のブラウザであるWin2000では、ネットワークプロトコル上に認証情報とか、いろいろ流しているせいなんだろうか。
判らん。判らんけど、とにかくこの3ヶ月は、本拠と独立してできる仕事以外は仕事にならなかった。

[composed and posted with ecto]

書く時間が取れなくて後手後手に回ってるのですが、月曜日にKAWAIさん、まかまかさんとお会いしてきて、OpeｎIDやFOAF承認に関する意見交換（というか飲み会）をやってきました。
感想は...ほとんどついていけてなかったというのが実感です。
暗号周りなんかは今勉強してる最中、というありさまだし、そんなこんなで判らないので、暗号云々が迷走しだしてからのOpenID‐MLは目を通そうともしていないので...。
でもまあ、KAWAIさんは最近の暗号暗号したOpenID規格は気に入らないみたいで、まがりなりにも私が多少理解していた初期規格を中心に追っていかれるようであるし、その辺のレイヤはその辺のレイヤで詳しい人に任せて有効利用させてもらうとして、俺は俺で興味のある承認のレイヤでなんかいろいろやってみるか、という感じです。

にしたって暗号とかの技術は必要なので、目下勉強中。
多少は、月曜に出てきたキーワードの中でも判るものも出てきたぞ。
むむむ。

で、飲み会の中で指摘されたんだけど、ステルスFOAFに似た仕様...特定の秘密鍵を持っている人にだけ友人関係を公開するFOAF記述仕様...はFOAF自体にあるのね。
よく思い出せばこの神崎先生とこのページくらいは全部目を通してるので、これも見ていたはずなんだけど、忘れちゃってた。
その後はFOAF自体の仕様理解を深めるよりも、それを使って何をできるかを中心に考えてきたので、振り返ってFOAFの仕様を再確認するのを怠りまくってた（超超言い訳）。
ゴメン。

でも、意味合い自体は違うとは思うけどね。
FOAF承認は暗号化されたFOAF記述は、秘密鍵を持ってるユーザ側がFOAF内の隠された友人関係を知ることができる手段、と言うのに対し、FOAF承認はサーバ側がサイト訪問者をFOAF上に記された友人であると承認する、という作業だから、微妙に違う。
その承認に秘密鍵流すわけにもいかないだろうし。
となると、結局承認サーバのメモリ上に展開された友人マップとのやり取りで承認をかけるわけなので、それをFOAFの出力的に隠しちゃうか、暗号化するかの違いだけで。
隠してる友人がいる、と言うことすら知られたくない場合もあるだろうし。
もっとも、サイト所有者AがFOAF内で友人Bを隠していると、Bと共通の友人CからもBのFOAFが見えなくなってしまい、CがBのFOAFを経由してのマタ友を辿れなくなるという問題も出てくるので、この辺で、友人Cが共通の秘密鍵を持っていればBの存在が判るようにしておけば、一般人からは見えないようにしながらも、友人Cだけは友人B経由でのマタ友を探せるようになるわけで、これはこれで併用すればよい仕様かも。

とはいえ、別の考え方すると、共通の友人と言うことならば、CのFOAF（or ステルスFOAF）にもBは載っているであろうはずで。
そう考えると別に暗号化FOAF仕様はいらないのかなあとも思わないでもないけど...。

[composed and posted with ecto]

Google Mapsについてのエントリへのコメントで、ひらっちさんが

プライベートが割れそうで怖いという人にはSNSを使って、行動範囲が重なる人が表われるまで公開を限定するとか。
重なるかの判定にはゼロ知識証明が使えないかな？

と書かれていたのが、位置情報の重なりをベースに情報の配信を制御すると言う点で、香川大学垂水教授の提唱しているSpaceTagの概念に似ているな、と思って、面白かった。
というか、AAA（認証、承認、アカウンティング）の3要素のうち、認証の方法がTypeKey、OpenID...と色々出てきているように、その上の承認レイヤも、FOAFによる友達承認から、SNSでの同一コミュニティ所属承認、SpaceTag的な位置での範囲内所在承認、等いろいろあっても面白いのかな、と思ったよ。

SpaceTag技術って、実装が、プロトコルにしろデータの蓄積・吐き出し方法にしろ、DataBaseのようなレポジトリ層のシステムとして機能したいのか、Apacheのようなプレゼンテーション層のシステムとして機能したいのか、はたまたMovableTypeのようなCMS的な機能を実現したいのか、がさっぱり判らず（まあそれだけが問題じゃないんだけど）、仕様の見直しも全くされなかったのでグダグダのまま終わってしまったんだけれども、
でもSpaceTagという概念自体は、結構今見ても新鮮と言うか、ちゃんと仕様考えて今の技術使って再構成すれば、面白くなるとは思うのね。
SpaceTagの情報を位置に貼る、はがす、貼り直す、とかって感覚なんて、ATOM-APIの発想と非常に親和性あると思うし、そのATOM-APIはというと、Nokia携帯に標準実装された例のように、SpaceTagが主眼のターゲットとしている携帯機器にまで広がってきているし。
というか、以前書いたこの位置情報付きATOM-APIの発想も、元々SpaceTagの仕様近代化作戦の一環で考えていたんだけれども。
こういう形でプロトコルをATOM-API、記事配信承認をApacheモジュールでの実装、そして位置情報蓄積のバックエンジンをPostGIS等の汎用で優れた技術を使えば、今からでも結構面白いものは作れるんじゃないかと思っています。

というわけで、位置情報での今風なコンテンツ配信・承認システムの研究、ぶっちゃけSpaceTagの近代化に、幾多の困難を乗り越えて取り組みたい！という人は、香川大学垂水先生の下で研究されてはどうでしょうか。
ただ、行くべきは香川大学で、間違ってもそういった事がやりたい！といって、SpaceTag社の東京事務所に行かないように。
100%乗り越えられないであろう困難に襲われますので...（というか、それぐらいなら自分で起業なされる事をお勧め。まだ困難の度合いが低い）。

[composed and posted with ecto]

市町村合併 - LAND HERE BLOG

地球地図などは、非営利ライセンスフリーのデータで大変重宝しているのですが、いかんせん、無料なためか鮮度がちょっぴり悪いです。
そんなとき必要なテクニックが、最新マップへの更新です。更新といっても SQL 文だけでできるお手軽なメンテナンス方法をご紹介します。

なるほどー、突っ込んだデータを使うしか能がありませんでしたが、そういう使い方もできるんですねー。
勉強になります。

他にも、「近隣市町村どこよ？」（境を接する市町村の選択）など、面白い利用法を解説してくださっています。

[composed and posted with ecto]

前書いたここギコPerlモジュールのSVNレポジトリで、密かにケータイ3キャリア+WILLCOMで位置情報取得用のHTML出力、及び取得後の経緯度データ（Location::GeoToolオブジェクト）・オープンiエリアデータの自動生成を主眼とした、HTTP::MobileAgent::Plugin::Locationモジュールを公開してます。
全然ドキュメントを整備してない（書きかけ...）＆本人が親モジュールであるHTTP::MobileAgentの改修を言い出している今になって出すのもアレですが、まあ使えそうなら使ってもらえれば。

ずっとここギコ版アンテナ奪取のバックエンジンとして使ってきたものですが、こいつとTemplate::Toolkitのお陰で、アンテナ奪取はau/vodafone/WILLCOMの3キャリアで、少なくともプレゼンテーション部分でほぼ一切分岐をする必要がなくて、メンテナンス量が減って重宝しました。
まあその分、3キャリア共通で見られるデザインにしか出来ない、3キャリア共通で実現できる機能しか実装できない等、別の問題もあるので、完全に同一プログラム化するのがいい事なのかどうかは微妙ではありましたけど。
一応、アンテナ奪取では使っていませんが、auのGPS、DoCoMoのGPS、DoCoMoのiエリアにも対応しています。

公開してこなかった理由は、オープンiエリアのオブジェクトに使っている、位置情報の有効な外接四辺形を求めるLocation::GeoTool::Auraオブジェクトで、各位置情報取得方法毎の精度（GPSなら精度情報に従ってAuraを狭く、簡易位置なら広く、といった具合に）を表現しようと思っていたのですが（その精度に合わせて表示する地図の縮尺等を変化させるため）、そこの仕様が決められないままグダグダしてたので、公開できませんでした。
実際READMEもその辺まで書きかけて止まってますが...。
とりあえずこれ以上触る予定もなくなったし、冒頭に挙げた機能範囲ならば普通に動く（アンテナ奪取で実可動確認済み）ので、まあよかったら使ってくださいませ。

[composed and posted with ecto]

この4月から家内が大学院生になったんだけど、通学先がなんと京都。
週2回、早朝の新幹線で行って深夜に帰ってくる。
好きこそ...とは言うけど、ようやるわ。

で、今日は京都みやげに向こう限定で売っているらしい、手作り冷抹茶ドリンクを買ってきてくれた。
これが中々面白い。
「お手前緑茶」の名の通り、飲む直前に水と抹茶から自分で作るのだ。

こんな感じで、最初は単なるミネラルウォーター。
ここでいったん蓋を外すと、中ぶたがカチッと外れて、中に入っていた抹茶の粉が水の中に落ちる仕組みになっている。
こんな感じ。

ここで、ペットボトルを振ると...水と粉が周囲に撒き散らされてえらい事になる。
「ちゃんと注意書きを読んで（家内談）」、一度蓋を閉めなおしてしゃかしゃか振ったり回したりしてみると...おいしそうな冷抹茶ドリンクのできあがり。

飲んでみると...苦味は全くなく、さっぱりとしておいしい。いや、むしろ甘い感じすらある。
「グリーンティー」とかって名で知られる、よく観光地なんかで売られてる砂糖入り抹茶ドリンクあると思うけど、あれの砂糖入ってないバージョン、もうちょっとお茶の濃厚さがあるけど、みたいな感じ。
あの「グリーンティー」って、砂糖入ってるけど、砂糖入ってなくても苦味はほとんどなさそうな感じでしょ？そんなイメージ。
あまりにもさっぱりして飲みやすいので、苦いのなんか大の苦手なはずの3歳児ですら、もう一口二口ちょうだい！とせがんでくるような味。

京都に行かれる機会があれば、探して飲んでみられては如何？お勧め。

[composed and posted with ecto]

深刻なセキュリティホール発覚！！！- webdog

これじゃナニか侵入してくるかもしれないから二丁目とか歩けないですね。早くパッチあてなきゃ！

私の「firefox」Ｔシャツには、右脇の下に脆弱性が発見されています。
深刻度は「軽微」なので、パッチ適用は見送る予定です。

[composed and posted with ecto]

広いマインドマップとかを経過しなかった
明日、FOAF承認絡みで飲み会をするので、これまでの議論経過マインドマップにでも...
と、ねねが考えてるみたい♪

*このエントリは、BlogPetの「ここ」が書きました。

昨日、息子を連れて散歩をしていて、電柱を見てドキッとした。
電柱広告で有名な街あど(tadp.jp)広告で、QRコードが着いたバージョンを見つけたのだ。

すわ、私が以前書いた、位置情報とQRコードを結びつけるアイデアが実現されたのか？と思ったが、単にトップページへのリンクだった。

どうせ電柱広告なんて、住所も広告も一つ一つ違うんだから、個別印刷部分が絶対発生するわけだし、位置情報付きQRコード埋め込めばいいのになあ。
もしくは、誘導するのはトップページでも、そこで電柱番号入力すれば、現在地が判るようにするとか。
今でも、電柱には住所が書かれてるし、今のトップページには住所から地図を表示する機能もあるので、まあ使えない事もないんだけど、電柱上の住所が町丁目からしか書かれてないのに、サイト上の住所選択は都道府県・市区町村からなので、こんな区境だとこの町は目黒区なのか品川区なのか判らないと検索できない。
さらには市区町村や町丁目の選択でまず五十音絞込みをかましてるので、手間が増大な上に電柱上の住所が難読だと使えない。

こんなだと、せっかく自分らの努力で街中の電柱に住所表示してやってるのに、それをみたユーザは住所から簡単に位置を取れる普通の地図サイトに流れてしまって、みすみす他社にビジネス機会を与えているようなもんだ。
せっかくGPSケータイじゃない端末にまで、位置情報のゲートウェイとして簡単にリーチできる手段を持ってるんだから、住所入力よりもっと簡単な位置特定インフラを整えて、位置情報ポータル化すればいいのに。
いや、位置情報ポータルに必要な地図は高いし、まだサイト上で地図を導入してない、っていうんなら薦めないけど、既に地図は借りてるんだから、うまく活かさないともったいないよね。

[composed and posted with ecto]

明日、FOAF承認絡みで飲み会をするので、これまでの議論経過マインドマップにでもまとめようかなと思いつつ考えてたら、「SNSがオープンアカウントにならなければならない理由」についてよい説明を思いついた。
というわけでそれをエントリにする。
限られた時間にやれる事は限られるので、明日の資料は綺麗にまとめるのはあきらめて、手書きで昼休みにでも作ればいいや＞ゴメンKAWAI氏、まかまか氏

「その１」のエントリで、SNSが生き残るにはセグメント化していくしかないけど、それだけでは不十分と書いた。
というか、書いてなかった。「生き残れるのか？その辺を考えてみたい」としか。格好悪。
でもまあああいう書き方をすれば「それだけでは不十分」と言いたいのは自明なわけで。
その理由は、さっき思いついた説明を見てもらえば、単純明快。各システム毎にアカウントのある今のSNSのシステムは、こういう状況になっているからだ。

SNSは人と人の繋がりを支援するというけれど、1つのSNSに属している限りはそれは正しいだろう。
だけど、複数に入った途端、人というノードを繋ぐハブの役割だったはずのSNSが融通の効かない固定されたノードに成り上がり、本来ノードであるはずの人が、システム境界によって寸断された人間関係を、折り合いをつけていくためのハブとして働く事を強要されるようになるのだ。
これではSNSは人を繋ぐツールどころか、システムの都合で人を寸断するツールにしかならないし、便利なツールどころかツールに踊らされているだけの事になる。

そりゃあ、痺れも苦痛もなくさくさくキーボードも打てて、バイタリティもあって、また暇な時間も十分にあるような恵まれた奴は、それだけの寸断された人間関係だってサクサクっとメンテナンスしていけるんだろうが、俺をはじめとして、そんな暇も余裕も体力も精神力もねえよ！って奴は世にゴマンといる。
そんな奴らから見ればなんでシステムに振り回されてまでSNSとやらに、しかも複数、入らんとあかんねん？というのが当たり前の感覚。
たとえそれがセグメント化されて、役割が違ったとしてもね。
普通に考えれば、人と人の繋がりをシステム化する、というのであれば、その主役となるノードは個人であるのが当たり前で、システムの方が「へへぇ、繋げさせてもらいます」と擦り寄るぐらいでないといけないだろう...つまり、こういう状況。

これができないと、セグメント化されてさえ、SNS同士で限られたユーザというパイの奪い合いになるしかないので、SNSに明るい未来はないだろう。

というか、考えてみれば当たり前の話で...世の中複数の銀行の取引が一つのATMでできるようになり、郵便だの公共料金支払いだのなんでもコンビニで済むようになり、複数の鉄道路線が直通運行で利用できるようになりと、どんどんワンストップチャネル化が進んでいってるのに、SNSだけチャネルがいくつもあってどんなに不便でもみんな使ってくれますよ、と思う方がおかしい。
主役をユーザの手に取り戻して、個人のポータルは既に存在する個人のブログ、SNSはどこにでもオープンな共通のアカウントで入れる事で、その主役間の繋がりをシステム的にサポートする脇役に引き落とさないといけない。
もちろん、オープン化する事で、特定の友人にしか見せたくないコンテンツとか、そういうSNSならではの良さを消してはいけないから、例えば私の仲間達もFOAF承認のようなアプローチを考えてるし、他にもAffelioとか、いろいろ動きはある。

いずれはそういう、HTTPの上層レイヤとしてオープンなSNS的承認・認証プロトコルのレイヤが加わって、それに対応できないような化石SNSは淘汰されちゃえよ、みたいな世界になってくるんじゃないかと思ってます。
ちょうど10年ほど前、パソコン通信が、インターネットという波にあおられて、クローズドな王国から開かれたゲートウェイへの転身を果たさねば生き残れなかったように...。
その意味を込めて、その１と合わせて、このエントリのタイトルを「歴史は繰り返す」と付けさせてもらいました。

[composed and posted with ecto]

前のエントリでこんな事

生き残っているところも、最近はMixi以外はほとんど名前を聞く事もない。
キヌガサ、トモモト、Livedoorフレンドパークはもちろん、2強であるはずのGREEですら今はほとんど話題に上っている様子がない。

とか書いたので、責任上定量的に調べようかと思ってやってみた。

どの位世の中で話題に上るか、というのを一つの指標にしようと思い、Blogで最近話題に取り上げられた頻度を調べた。
やり方は以下のとおり。

• 各SNSの名称でbulkfeedsで検索をかける
• でてきた検索結果最初の10件の、10件目が何日前に書かれた記事かを調べる

というもの。
真面目にやろうと思えば、もっと100件目とかまでリストアップして、出てきた結果の平均をとったり、他のエンジンでも試したりいろいろすべきだけど、一方でこんな事書いてる状況で必要以上にやる必要もなかろうとも思い、単純な調査にとどめた。

以下、6/12午前9時段階での結果です。

1. Mixi:　　1日前（1日前が15位まで続く）
2. GREE:　　3日前
3. CURURU:　　3日前
4. キヌガサ:　　4日前
5. FC2ネットワーク:　　6日前
6. Echoo!:　　10日前
7. livedoorフレンドパーク:　　17日前
8. Commit4U:　　20日前
9. トモモト:　　34日前

思った以上に差が出ている。

まあ、SNSは一度コミュニティができてしまえば内部で盛り上がるのだから、必ずしも外に話題が出ないからと言って内部が盛況でない、という事にはならないが、でもビジネスとして成り立たせるには、外部の人間に入りたいと思わせるそれなりの求心力が必要、となれば外部で話題に上るかどうかも一つの指標となるわけで、あながち間違ったことをやってるとも思わない。

[composed and posted with ecto]

またSNSが一つ閉鎖するらしい。
meetme、UUME、Friend Mapと閉鎖が次々と続いているし、生き残っているところも、最近はMixi以外はほとんど名前を聞く事もない。
キヌガサ、トモモト、Livedoorフレンドパークはもちろん、2強であるはずのGREEですら今はほとんど話題に上っている様子がない。打開策もなさそうだ。
もちろん、一方で新しいSNSも立ち上がってきてはいる。
私自身も書いたとおり、対象となるユーザを限定したセグメント化されたSNSは生き残る道があるかもしれないし、最近オープンしているサービスはそれに近い方向性を出しているようにも思います。
（ただ、個人的にはセグメント化するだけではまだ生き残れないと思います。というのを、個人的に身体感覚として実感しています。それについては上記リンクの「歴史は繰り返す　その２」を書きたいと思っているのですが、うまくまとめ切れずまだ書けていません。ヒントとしては、こちらの記事の「複数SNSの掛け持ちは面倒」という内容に私が激しく同意する事、こちらの記事、そして世の中には私より忙しかったり苦しかったりする人はいくらでもいる！というあたりでしょうか。）
でも、それはそれで新たな展開が出てきたというだけで、「ブログの次はSNSだ！」と最初のSNSブームに乗せられて、大同小異の似たサービスポコポコ立ち上げてたところは、今後もどんどん潰れていくのではと思います（あらゆる類の人飲み込んでしまった後となっては、今更セグメント化もできないしね）。

なんかそういうの見てると、昔のナタデココブーム思い出してきて。
ナタデココもブームでもっと送れ、増産しろと日本から煽られて、フィリピンの農家の人達とかこれは金儲けのチャンス、とばかり全財産はたいて増産体制整えたら、ブームは終わってさようなら、という事でたくさんの人が破産して路頭に迷ったり、死んだりしたわけですが。
そういうのに似ていて、アレゲがオモロゲに飛びついてBlogと盛り上がっているのを見て、あちこちがBlogサービスを始めて、今度はSNSだ、となったら、Blogに乗り遅れたところが今度はうちが、とSNSいっぱい立ち上げたりしたわけだけど、ナタデココに踊らされたフィリピン農家と一緒かなと。
Blogはまだいい、一応個人で完結するサービスだしオープンだから、他社が使えなくて自社のサービスが充実していれば、引き抜ける可能性もあるし、広告モデルなんかも立てやすくて、今金になってなくても将来を期待できるけど、SNSはどんなに他社サービスが充実してても、サービスそのものよりその場で成立する人間関係こそがキモで、それをごっそり他社に移す事など無理だから、今負けが込んでいたらユーザを引き抜いたりして覆すのは不可能に近い。
＃まあ、即座に息の根止められる（SNS）か、真綿で首を絞められる（Blog）かの違いかもしれないが。
そういうのを見てると、オモロゲはいいんですよ、俺もオモロゲ好きだから、でも、旬・瞬のオモロゲだけを追って、それが後どうなるかを振り返らないでただ走り去って、あとには死屍累々、それはそれでいいんだろうかと。
誰か立ち止まって、その先を考えてやれよと。
ナタデココの例で言えば、曲げられる有機ELの素材に使うというアイデアが出ているように、そういう一時ブームではなく本当に有用な使われ方、NiceからMustへ至るルートを誰か考えないといけないんじゃないだろうか。

...ついでに言えば、あまりまだ「Nice」な時期に、踊らされ過ぎて業界がダメージを受けてしまうと、本当に「Must」な使われ方が出てきても、過去の失敗の記憶から誰もそれに手を出さなくなってしまう、という危険性すらある。
「ナタデココ」にブームではない、本当に有用な使われ方ができて、それで増産がまた必要になったからと言って、フィリピンの人達がそれに乗ってくれるだろうか...？
それを考えると、先への責任なしに、なんでもかんでも安易に「オモロゲ」の風潮を流すのもいかがなものかと思わなくもない。

[composed and posted with ecto]

先に紹介したPostGISツールボックス、試してみました。
デザインもすげえかっちょええし、完成度高いです。

インストール後、ログインして初期化画面を選ぶと、こんな感じになります。

なかなかいい感じでしょ？
設定項目を見れば判るとおり、位置情報用DBの作成からPostGIS利用のために必要な初期化、ついでにサンプルデータが必要なら地球地図から日本の地図データを全自動で引っこ抜いて来てくれるという便利さ。
もちろん、初期化後は独自のshapeファイルも食べさせられるので、どんなデータでもこのツールで突っ込む事が可能になります。
初期化の項目を全部選んで実行してやった時の実行イメージはこんな感じ。

こんな感じで、全自動で処理を行ってくれて、地球地図をデータとして使うならもう全部そろった状況まで持っていってくれます。
＃このキャプチャ画面は私の最初の実行時のをキャプチャしたもんですが、よく見るとエラー出てますね...このエラーについては後述。

データを突っ込むだけじゃなく、SVG出力でデータの視覚化の支援も行ってくれます。
行政域レイヤーをSVG表示させたのはこちら（Opera8のSVN表示機能で描画させてます）。

なんかすげえかっちょいいです。
もうMapServerもkaMapも設定済みだし、GISデータパック突っ込まなくても、適当なMapFileさえあれば、kaMapで日本地図表示できますね。
というわけで、適当なMapFile大募集（飽くまでも他力本願...）。

で、エラー云々についてですが、新潟Linuxに最適化して作られているためだと思うのですが、一般的？な環境で動かすのにはちょっと色々工夫してやらないといけなかったので、その注意点を述べます。
まず、postgreSQL/PostGISの実行ファイルについてですが、今私が実行した範囲では、裏でcreatelang、psql、shp2pgsqlの3つの実行ファイルを実行していますが、これらについて、httpdの実行権限で実行できるよう、PATHを通しておく必要があります。
このやり方が一般的なのかは知りませんが、私の場合、参考にしているPostgreSQLの入門書で、セキュリティ対策なのかPostgreSQL実行権限の.bashrcでpostgreSQL/PostGISの実行ファイルへのPATHを設定するように書かれていて、それに従っていたので、最初この辺が「command not found」で動きませんでした。
また、PostGIS利用のための初期化を行う場合、その初期化に必要なsqlファイルであるlwpostgis.sql、spatial_ref_sys.sqlの2つですが、これらが/usr/share/pgsql/contrib/にあるものとして決め打ちでコーディングされているようです。
が、普通にソースからコンパイルすると、それらのsqlファイルは/usr/local/pgsql/share/contrib/に入るはずなので、ソースを修正するなり、sqlファイルをシンボリックリンクしてやるなり、してやる必要があります。
とりあえず上記2点だけ設定してやると、私が試したPostGIS初期化ー地球地図データ流し込みーSVG出力、までは問題なく動きました。
参考までに。

[composed and posted with ecto]

先に書いたHTTP::MobileAgentアーキテクチャ改修提案ですが、まだ本家には連絡していません。
とりあえず何か形がないと言っても流されるかもしれないので...。
とはいえ、今ある機能を全部再現してから提案、となると、元々一人メンテナ無理でしょ、というアタリから出てるのに本末転倒なのでアレですが、とりあえず最低限のアイデアの実現の目処は立ててから提案するかなと。

で、サブクラス・プラグインの自由な別開発、新規開発を可能にするための自動検知機構ですが、いきなりつまづきました。
こんな感じの実装を考えていたのですが（これはサブクラスの例ですが、プラグインも同じ）、
HTTP::MobileAgent.pmのimportメソッド

sub import{
    my $install_dir = __FILE__;
    $install_dir =~ s/\.pm/\/SubClass/;
    opendir (DIR,$install_dir);
    foreach my $file (readdir(DIR)){
        if (($file =~ /^(.+)\.pm$/) && ($1 ne 'NonMobile')) {
            my $subclass = "HTTP::MobileAgent::SubClass::$1";
            eval "use $subclass;";
            push (@subclasses,$subclass);
        }
    }
    foreach my $eachclass (@subclasses,"HTTP::MobileAgent::SubClass::NonMobile"){
        $eachclass->init();
    }
}

これで、一応うまくいくんです。
呼ばれているHTTP::MobileAgent.pmと同じライブラリツリーにインストールされているサブクラスは、自動検知できる。
いくんですけど、よく考えたら、サブクラスって、同じツリーにインストールされるとは限りませんよね。
PATHが通っているところならどこにでもインストールされる可能性があるわけで、特に開発環境でなんか、本番とは違うところにPATH通して開発中のプラグインとか置きたい、とか思うかもしれないのに、この方法だとそういうサブクラス・プラグインは検知されない。
同じようなことを、全てのPATHに関して自動検知してやろうとすると、@INCの全てのパスについてディレクトリ内調査してやらないといけない事になり、非常に効率が悪い。というか、実用性ゼロ。

できればプラグイン・サブクラスの自動検知にはこだわりたい...あるいは、他の方法でもいいんだけど、本体とサブクラス・プラグインの開発は独立しつつも、インストールさえすれば協調するようなやり方を何とかしたい、んですけど...。
誰かいいアイデアないですか...。

[composed and posted with ecto]

ここしばらくエントリ書き過ぎで、持病持ちの手が限界状態です。
書きたいから書いてるんだし、まだ書きたい事は山ほどあるんですが、一方で一字一字打つのが拷問のようで。
打ち間違いも多くなるからさらに作業量が多くなり苦痛倍増。
さらに費やす時間が長くなり、子供の遊んでプレッシャーや家内の家事手伝えプレッシャーも強くなりストレスもさらに倍。

辛いねえ。

[composed and posted with ecto]

もんたメソッドの広がりに関しては正直冷ややかに見ていたのですが（現場にいなかったせいか？）、一つ前のエントリで長文を書いた後、重要箇所太字にでもするか、と思って書き直そうとした時に、ついでならもんたメソッドにするかと思って導入しました。
YappoさんとこのJavascriptツールを利用。
入力を簡単にするため、ectoのHTMLテンプレートにも登録した。

でも、一時おもしろネタとしてはいいけど、継続して使うのかねコレ。
開発したYappoさんもその後使ってないみたいだし。

おまけにもんたメソッドに置き換えしようとして、失敗してコメントもついてたエントリ1個消しちゃったし。
まあ、これは俺の不注意でもんたメソッド関係ないけど。

[composed and posted with ecto]

Google Maps利用のHACKに初めて利用停止措置が出たみたいですが、

• [WEB]GoogleMaps Hacksで初のサービス停止依頼 - ドナドナ日記

  やっぱり、貼り併せた地図をダウンロードさせるのはGoogleの地図,衛星写真ライセンサーが許さないんだろうなあ。
  まあ、WEB上で完結するサービスならトレースできるけど、一回ダウンロードしちゃうとどう使われるか分かんないしね。

• 個人でもGoogle MapsをHACKしないでね by Product Manager, Google Maps ですって。 - Web Walker Weeps

  やっぱり遂にGoogle Maps がハッキング行為を×って言い出したようなことが分かる。

時系列的に先ににのっちさんの方のエントリを読んで、まあその辺は指針が必要だったんだろうし、今回の件がその指針になっていくなだろうな、と思ってたら、続いて散歩社さんの記事読んで「ええー？全面禁止？」って感じだったんですが。

よく追うと同件に対する記事でしたね。
という事であれば、これはにのっちさんの方の捉え方で、まあ何でもかんでも使っていいよ、というわけではなくて、一つの指針が出来たって捉えればいいんじゃないでしょうか。
今回のように地図や画像がGoogleやライセンサーの制御下を離れて一人歩きするような使い方は許さないが、そうでない限りは、とりあえずはサービス停止を言われることはないんじゃないでしょうか。
それだけでも、これまでの地図業界の状況から見れば大きな前進だと思います。

まあ、全国に全国に28万人の調査員を配置されているゼンリンさんの例を挙げるまでもなく、地図作りってのは金のかかるものなわけだし、切り売りの画像販売も行っているわけだから、その辺をおびやかす地図画像の勝手な切り売り利用（というか、それを前提としたサービス）は、そう簡単には許せないんだろうなと。
その一方で、そういった地図作成の苦労があるのは判るけど、だからといって取れるところからはとにかく金を取るというか、自分のいるところの「地図」という、人間にとってはもっとも直感的な情報の利用に対し、「こんなツールがあれば便利でいいな」ぐらいで個人が作るツールであっても、月数万、数十万のライセンス料がまず払えなければ使わせない、というそういう姿勢が、どうも一般人とこの業界の感覚の乖離なわけで。
金がかかってるのだから貴重な情報なのだ、だから高く売るのは当然なのだ、というのは判るけど、一方でその情報は、人間一般にとってもっとも直感的で当たり前な感覚の情報であって、使えないという事に多大なストレスを感じさせるモノであること。
そしてそういう直感的な情報であるからこそ、失敗もあるだろうけどいろいろ試してみてこそ、その先に新しいビジネスの可能性が生まれる事を理解しないといけないと思う。
いろんなアイデアで何を実験してやってくれてもいいけど、うちは地図を使った分の金はきっちりいただきますから、その結果実験にとりかかるためのハードルが超えるのが不可能なほどに高くなったり、実験してみて失敗したらライセンス料だけで再起不能なダメージを得たり、では、新しいものは生まれないし結果的に自分達のパイとなるフィールドの可能性を潰して、どんどん狭くしていっているだけになるんじゃないか。

とはいえ、凝り固まった当事者がなかなかそういう状況を変えるのは難しいわけで、Googleのように、アルファギークを取り込んでいろいろ遊ばせる事の有用性をもっとも理解しつつ、一方で地図ライセンサー達に、これまでの考え方を改めてでも関係を維持した方がよいと思わせる程の力を持った会社が間に立ってくれる事で、この状況が改善されていくのかなと思ったりもした。
というか、先立つエントリなんかでGoogleがgoSVGに興味を持ったら面白そうだなと書いたけど、そのgoSVGの旗振り役であるｇコンテンツ流通推進協議会なんか、まさにそういう「高いGIS情報→及び腰なコンテンツ提供者→広がらない市場→高値維持されるGIS情報」という悪循環を断ち切るためにできた団体なわけで、Googleとｇコンテンツ協議会が上手く連携すればおもしろい位置情報の未来があるかなと。
...まあ、ちょっと両者の性質が違いすぎてそもそものコミュニケーションが成立するのか、という不安はありますが。

[composed and posted with ecto]

以前、近日公開されるらしいよ！と紹介したLAND HERE BLOGさんのGISツールボックスですが、出ないのかなーと思ってたら、ちょっと前から公開されていたようです。
なるほど、Wikiの方をチェックしてないといけなかったのか。

誘導された元記事はこちら。

• 遅ればせながら Niigata Linux です - LAND HERE BLOG

初めてオープンソースを触る人向けに特化しているそうで、1CDで20分もすればPostgreSQL+PHPでの開発環境が整うそうです（しかもPostGIS ツールボックスまで付いて!）。
これも中々おもしろそうですが...coLinuxで動かせるようにする、というのは私にはちょっと敷居が高そうなので、VMWareの体験版でも突っ込んでその上でちょっと遊んでみようかな。

[composed and posted with ecto]

Movable Type Updates - blog.bulknews.net

Movable Type Publishing Platform: Movable Type 3.17の提供を開始

これも大ニュースなんですが、個人的にはこちら。

待望(?) の MT Tags プラグインが Six Apart Power Tools としてリリースされました。キーワードのリプレースとしてエントリに Tag を入力していくことができます。入力候補を DHTML でロードしたりもできるみたいでなかなか便利そう。

くわっ！
せっかく苦労してこの辺の影響受けて、六畳半Folksonomyの環境整えて、後は膨大なタグ付け作業を済ませれば終わりだったのにっ！
どうしようかな、乗り換えたほうがいいのか、これまでの方がいいのか。
「キーワード」は、他のいろんなプラグインでもいろんなデータの逃げ場に使われていて、これはこれで別にいろいろ使い道があるので、キーワードとは別にタグの設定属性ができるのならば乗換えもありかな、便利そうだし。
とも思うけど、でもよく読むと「キーワードのリプレースとして」と書かれているから、結局これもキーワード欄に逃がしてるだけなのか？
だったらもうできてる環境の方がいいかな...。

で、とか考えているうちに、タグに関していろいろ思ったんだけど、
SBSみたいに公開されたエントリに対しみんなでタグを付け合って集約されていくタイプのタグ付け（→集約が進めば草の根セマンティックWebの基礎にもなり得るような）と、このMT Tagsなんかのように、個人が自分のコンテンツに主観でつけていて、他人による別評価が起こりえないタイプのタグ付け（俺興味ないから知らないけど、flickerなんかもそうなの？）を、一緒に考えていいのかなあという疑問がふつふつと。
検索文字を入れてやると、同じタグがついているSBSのエントリ（＝客観集約タグ）とflickrの写真（＝主観単独タグ）をまとめて表示してくれるサービスとかあったはずだけど、ああいうのって、面白い、面白いのは判るんだけれど、それに意味があるのかなとか思うと、上に書いたような事もあってちょっと？？？となったりもする。

で、その意味的な違いに考察を深めることは難しくてよく判らないんだけど、逆に発想として両者の溝を埋めるために、例えばdel.icio.usでrecommended tagを表示する際に、全く初めてのBookmarkであっても、そのエントリの著作者自身が主観タグを付けてたらそれを検知してお勧めするとか、逆に自分のエントリに付けたタグがとは違うタグがdel.icio.us上で付けられれば、それをBlogが自動で検知して取り込むとか、そういう機能があったら面白いかなあ、とか思った。

[composed and posted with ecto]

今日6月10日は、私の34回目の聖誕祭であるわけなのですが。
いつもどおり昨夜23時頃息子を寝かせつけて一緒に爆睡し、2時過ぎに起床（最近はほぼこの3時間睡眠生活）。
でもってパソコンに向かってみると、Amazonのギフト包みが置いてある。
家内からの誕生日プレゼントだ！
何かなと思ってあけてみると...
「i」の字が見える！
もしやi pod？
と思って喜び勇んで開けてみると...。

Continue reading

昨今のオラ系HACKブームの走りと言えば、やっぱりSpidering hacksじゃなかったかと思うですよ。
まあ昔から、例えばここギコでも地図サイトで経緯度から住所を盗んで来たりとか、吉野屋の店舗一覧をリストアップしたりだとか、やってる人はやってたわけですが、そういうやり方の存在がこうしてまとめられて世に紹介されたというのは、色んな人の感性を刺激したんじゃないかと思います。
位置情報系オモシロHACKを集めておられる某地図屋のにのっちさんが、HACKに興味を持たれた原因もこの本だったりしますし...。

で、この本にしても、その後に続くGoogle HacksやらBlog Hacksやらにしても、HACK系の書籍の主流は何故かみなPerlだったわけなのですが、

先日本屋をうろついていて、Java版のSpidering Hacksとでも言うべき本を見つけました！

内容的には、JavaのLWPツールとでもいうべきコンポーネントの紹介から、スパイダリングする際には見過ごせない文字エンコードの問題、等等、実際のHACK例も含めて盛りだくさんの内容です。

これを通じて、Java界隈の人達もスパイダリング、スクレーピングに目覚めて、裾野が広がると楽しそうだなあ。

[composed and posted with ecto]

昨日午前、地震がありましたね。
仕事してたら、職場で気付いたの私だけでしたがまずグラッと縦揺れが来て、ああ来るな来るなーと思ってたら、しばらくして横揺れがグラグラと。
はっきり時間差が判るほど縦・横の揺れが分離してたのと、横揺れの時間が長かったので、遠くの大きな地震を感じたのかと思ってたら、意外と最大震度2の小地震でしたが...。

でも、統計的に有意に増えてるのか判らないけど、感覚的には意識にのぼる地震って増えてきてますよね。
本当にひずみがたまりきってて、大地震がそばまで迫っているのかもしれません。
とはいえ、こんな大層な本とか見て実態を知ろう、防災意識を高めよう、と言ったって、やっぱ現実が来ないと誰も日々に忙しくて構ってられないし、実際私も防災対策なんてそんなにやってるわけじゃないし（むしろやってない方）、えてして事実がやってきてから後悔するもんで。
そんなこんな考えてたら、面白い本見つけた。

都市が壊滅するような地震に遭遇した時、どうすれば彼女を守れるか。
単に物理的な災害から身を守る方法だけでなく、その後家族とどう連絡を取るか、避難所での生活の方法、着替え等のプライバシーをどう確保するか、傷ついた心のケアをどうするか...といった、防災本としては本格的な内容だが、その全てにそのシチュエーションをなぞった「彼女」の写真が添えられているのがおもしろい。
「彼女」のモデルは石井めぐるちゃんという娘らしいのだが、18歳、高2で152cmの身長ながらFカップと、ロリ巨乳妹系の萌えな女の子。
「誰かに見られてる...」着替えのプライバシーのシチュエーションとか、どんな写真が載ってるかは想像できそうなアレでしょう（ただし18禁ではないので）。

まあ、萌えという多分に超日常的な要望を十分に満たしつつ、一方で非日常にも思いをはせるという、こういう意識の高め方もあってええんかなと思います。

Continue reading

ectoというBlogクライアントを、正規ユーザになって普段愛用しているのですが、最新版でUIが日本語されたのはいいんですが何かえらい事になってます。

なんですか「を除けば」って。実動作的には「投稿」なんですが、さっぱり意味が判りません。
ここ並みの衝撃です。
なんかフィードバックした方がいいかなあ...。

ecto、慣れもあって使い勝手は悪くはないんですが、最近ActivoとHotplaceの比較の表とか作るのに、WYSIWYGの方が便利なのでBlogWriteを体験版で使ったりもしてます。
普通に直打ちしてる範囲では慣れたツールが一番なんですが、WYSIWYGが便利な投稿もあったりするので...体験版の試用期限も過ぎるので、たまに補助で使う程度の利用で購入すべきかで悩んでたりします。
必要なその瞬間、にはすこぶる便利なんだけどねえ...。

[composed and posted with ecto]

こんなエントリ書きましたが、ちょっと状況を読み違えていたかもしれません。

位置情報HACKERをGoogle Mapsがライセンス地獄から守ってくれそう、という内容は間違ってなさそうですし、GoogleがgoSVG等の技術を採用すれば、そういう情報が集約されて超便利な世界になり、またオープンソースGISの世界と共存共栄、というのは間違ってないと思います。
けど、このくだり

でもそうなると、馬鹿高い商用地図に対してユーザの等身大で利用できる地図ソリューションを、と最近伸びているオープンソース系の地理情報ソフト群にも、多少の影響が出て来はしないかと心配してしまいます。
無料で、自分のサーバに負荷かけずに、最新の地図が利用できるなら、みんなそっち使いますからね...。

というのは、ちょっと間違ってたなと。
というか、HACKERが興味主体でHACKした、非営利の面白位置情報アプリケーションを公開するような話と、法人が商用の新しい位置情報サービスを始めるような話をごっちゃにしてしまっていた。
そりゃGoogleは前者は守ってくれるだろうけど、法人が「これから新しい位置情報サービスします。地図はGoogleさんHACKさせてもらいますんで」とか言ったってそりゃGoogleも許さんだろう。
そしたら、HACKレベルではよくても、商用サービスを立ち上げるにあたってはやっぱり馬鹿高いGIS系データ・システムの問題は立ちはだかるわけで、その意味では別にGoogle Mapsの存在がオープンソースGISのビジネスの世界に与える影響は少ないのかなと。
（まあ、個人レベルでHACKする連中はみんなGoogle Maps使うようになってくると思うので、そんな中で面白いものはGoogle Maps上のシステムなのだから青田買いしてしまおうと、そういう思惑もGoogleにはあるのかもしれませんが）

また個人レベルにしても、確かに今までの地図サイトは無断使用厳禁、ライセンス料は個人相手でも馬鹿高く、実際、きむらさんのアンテナ奪取なんかでも、その辺でケチガつかないよう現在無断表示の地図の表示を廃止する方向で検討されているみたいだったり、という状況があって、Google Mapsがその辺の問題を解決してくれそうではあるのだけれど、
一方で実際問題として、ここギコをはじめ無断使用をやってきたところはやってきたわけで、それに対して実際に個人・非商用レベルのHACKに対し、お咎めや高額なライセンス料賠償が課せられた、という話は聞かないので、堂々と出せるかアングラ臭が漂うかは別として、別にそこまでいうほど状況が激変したわけでもないかな、という気もする。

ここギコ携帯版の地図の例で話すと、最初はMapFanの地図を使っていて、ライセンス問題にきちんと話をつけようと、無償或いは格安での利用をインクリメントPに申し出たんだけど、さすがに馬鹿正直に言ってこられれば向こうとしても許可するとは言えない訳で、断られてしまった。
そこで、それ以降別の地図サイト（名前は伏せるが某サイトとしておきます）の地図を無断借用していたんだけど、アクセスログを見ていると明らかにその配信会社からのアクセスもあったにも関わらず、何のお咎めもなかった。
というか、その会社の方でここギコ携帯サイトを使ってくださっている人すらいたような感じ（見逃してくれた方々、ありがとうございました。もし読んでおられれば、一度お酒でも飲みたいですね。）。
今はもう携帯版ページもなくなってしまってリアルタイムではライセンス違反してないから話せる事とはいえ、ライセンス厳しいといっても実際にはそんな感じだったわけなので、Google Mapsが出てきたところで商用の無償利用ができないのであれば、個人HACKの範囲内ではまあそこまで状況が変わったわけではないのかなと。
（もちろん、AJAXなインタフェースは大きな違いですが）

にしたって、心配事が一つでもなくなるのはいい事なので、Google Mapsの現在のアプローチは大歓迎しますけどね。

[composed and posted with ecto]

Activoの紹介エントリで

お勧め場所登録を「位置情報貼り付け」と解釈すれば、限りなくそこはかとなく、私の前社であるSpaceTag社のどこでも伝言板サービスにそっくりです。

と書いたけど、今日久しぶりにアクセスしたら、3月末でサービス停止しとるやんけ！
4月からの個人情報保護法案対応で、auが厳しくなって出会い系カテゴリの公式サイト運営ができなくなり、準公式サイト扱いになって課金システム等もそれ用に改造しないといけない、という話までは聞いてたけど、改造できなかったか、或いは収益から計算して改造してまで続ける必要はないと判断されたか...。

事情は出てしまったので判りませんし、まあもともと、収益構造に持っていくためにきちんと企画や構成、システムを再検討しよう、という意思がないのであれば早々に止めた方がよかったので、止めるいい機会だったのかもしれませんが、
一方で、位置情報会社としてのSpaceTag社の象徴的存在であって、かつ位置情報としての最後の砦であっただけに、なくなった事を知ると一抹の寂しさを感じるのも事実ですね。
大阪から夢を抱いて最初の転職をする前、当時は当然内情も知らなかったので、位置情報に関するすごい技術をもった憧れの会社、その技術の実アプリケーションとしてある意味「どこ伝」も憧れの対象だったので...。

もっとも、サイトとしては当時から、私の当時の「携帯版ここギコ」よりショボい感じでしたけど、そこはそれ、技術的にすごいのと、アプリケーションを作るのがうまいのとはまた違う話なので。
中の技術はきっとすごいんだ、それをもっとうまくアピールするようにするためにこそ俺が入るんだ、という感じの気持ちでしたから。
まだ転職が決まる前から、同社に「どこ伝」サイトの改善提案とかいろいろ送ってましたしね。

何にせよ、一つの時代が終わったなあ、という感じです。

[composed and posted with ecto]

こちらのエントリのコメントで教えてもらった技術。

紹介してもらったURLはこちらで、そこで言及されているLOAF、Bloom Filter等に関しては、

• Bloom filterの解説文 - 無印吉澤
• Bloom filterの説明 -アリエルエリア-

  Bloom filterには、以下の特性があります。
  - 少ないデータを転送するだけで、存在チェックのヒントを相手に渡せる
  - Bloom filterの和は、ビット和を取るだけでできる
  - 秘密を保ったまま、自分の手札をさらせる
  - Bloom filterを比較(同じビットが立っているか否か。つまりXOR演算)することで、近さの判定ができる

• LOAF
  アリエルエリアからの引用：

  3番目の特性は、SNS的なLOAFに見られます。名前がFOAFと似ているのは偶然ではなく、狙った名前でしょう。自分のアドレス帳の秘密を保ったまま、自分のアドレス帳に誰かがいるかどうかの情報を交換可能です(誤検知もありますが)。

と言う感じで、秘密を保ったまま情報の比較が出来るので、お互いのFOAFを隠したままで共通の友人がいるかを判定できたりするみたいです。

うちで追っているFOAF承認自体は、最初期レベルの閲覧者が自主的に承認を要請するような段階では、承認主体が第3者でなく当事者であり、承認のベースとなるのも「閲覧者のFOAFに承認側と共通の友人が含まれているか」ではなく、「承認側の友人のFOAFに、閲覧者が記載されているか」なので、ちょっと毛色が違うのかなと思います。
でも、将来的に、FOAF承認系の最初のエントリで書いた

将来的には、ブラウザのプラグインなんかで対応できるなら、サイトを訪れたらFOAFをチェックして、自分のmbox-sha1と同じ記述を当該サイトのFOAF内に見つけたら、自動的に認証手順に入って認証、というのもアリかも。

というレベルになってくると、生でmbox-sha1sum渡しちゃうと、承認成功しようが失敗しようが、誰が訪れたのか「訪問した事がバレバレ」になってしまうので、例えば自分のmbox-sha1sumと、デタラメな一時データのリストを作って、それと承認側の閲覧許可リストとのBloom Filter比較してやる、とかすると、訪問のプライバシーが守られるので、いい感じかなと思います。

[composed and posted with ecto]

GoogleMapsの地図ライセンス - ドナドナ日記

ハックされまくりのGoogleMapsを使ったRemix系のサービスに対して、地図ライセンサーはサイト閉鎖を求めていないのかとの質問に、Googleとしてはトラフィックが増える事のメリットをライセンサーに訴え続けて、なるべく外部サイトの閉鎖はしない方向に持っていきたいみたいとの事。

これは凄いですな。

これまでの位置情報サイトの悩みといえば、地図（に限らず住所、経緯度、全ての要素）のライセンスの問題があったわけで、どれだけアイデアがあっても馬鹿高いライセンス費用を払えなければ形にはできなかったわけです。
その意味で地図屋との戦いであったわけで、実際ここギコも一度戦った（というか、正規に交渉して利用させてもらおうとして負けた）経験があります。
1度だけで、その後は完全に無断パクリ利用状況だったわけですが。

Google Mapsの登場によって、その辺の越えられなかったハードルが一気にGoogle庇護の元に降ろされた、という感じになるのでしょうか。
これから現れる位置情報ハッカーは幸せです...何人もの漢が打破しようとして夢破れてきた壁を、それ以上の巨人が登場する事で当たり前の空気のように利用できるようになるわけですから...。

でもそうなると、馬鹿高い商用地図に対してユーザの等身大で利用できる地図ソリューションを、と最近伸びているオープンソース系の地理情報ソフト群にも、多少の影響が出て来はしないかと心配してしまいます。
無料で、自分のサーバに負荷かけずに、最新の地図が利用できるなら、みんなそっち使いますからね...。
とはいえ、PosｔGISだのMapServerだのといったオープンソース系地図ソフトの利点は単に地図が表示できる、という事だけにあるのではなく、特に最近のgoSVGサポートなんかを使うと、地理的な情報を保ったまま、地図や同じようにgoSVGで記述された他のサイトの情報と重ねあわせができるようになるわけです。
ちょうどBlogの記事がUpdate PingでPingサーバに集約されて時間の切り口で集約されて見れたように、例えばGoogleがgoSVGの規格に価値を感じて、Google MapsをgoSVG対応なんかにすれば、いろんなサイトからgoSVG形式で情報がアップされれば、それを重ね合わせて空間の切り口で、いろんな情報が集約できるようになるわけです。
（※今でもGoogle MapsでいろんなHackがされて、情報が重ね合わせられていますが、それと何が違うのか、というと、まず一人の独自のHACKと違い統一規格でいろんなサイトのあらゆる情報が重ね合わせられるという事と、単に点ではなく、線、面、領域、なんでも重ね合わせられるというのが大きな違いです。）
こうなる事ができれば、誰でも手に入れられるオープンソース系地理情報ソフトは、そういったgoSVGフォーマットを出力するためのソリューションとして、Google Mapsと共存共栄していくのではないかと。

ついさっきそう思いました。

すみません、その後考察も実装も進んでませんが、今この辺でいろいろやってるサイトの紹介をば。

• どんぞこ日誌
  FOAFとTypeKeyでWiki承認など、FOAF周りの実装で実績のあるまかまかさんのサイト。気付かなかったOpenIDの危険性等、いろいろ勉強させられます。
• びーこん
  OpenID仕様日本語訳の作成者。OpenIDのMLでも仕様の提案等をされており、日本でのOpenIDサーバの立ち上げを考えておられる一人者。
• ひらっちblog
  FOAF承認と同様、オープンなSNSの基盤となりうるAffelioプロジェクトでも、積極的に提言・活動されている方。

というあたりでしょうか。

一応個人的に考えている今後のアレなんですが、いろいろもんでいくのは当然として、個人的にはまかまかさんのFOAF/TypeKey認証FSWikiプラグインをベースに、FOAF承認プラグインを作ってみようかなと思ってます。
HTTP::MobileAgentもほにゃららするとか言い出してるくせに、私の腕前でどのくらいの勢いで何をどうできるのかどうか判りませんが…（HTTP::MobileAgentの方は実装イメージはできてるけど、こっちはプラグインの作り方からお勉強なので）。
目指しているところとしては、

• ページ・カテゴリ単位だけでなく、Wiki/Farm単位でFOAF承認できるようにする
• BookMarkletからAutoDiscoveryでFOAF承認エンドポイントにmbox_sha1sumを手渡し、認証遷移に移るまでを実際に形にする
• 対応する認証方法はTypeKey/OpenID
• 承認の段階は、とりあえず許可/不許可の2値とします(閲覧ではなく、ページ生成・修正に対する承認)

といったところを考えています。

Continue reading

Nakamura-KU ADDICTさんが新しいサービスを始められました。
経緯度をベースに、街区レベル位置参照情報から近隣の住所を導き出して、Googleで問い合わせた結果を表示するものです。

逆Geocoder

• Google APIは１日1000回までしか利用できないそうなので,1000回こえると検索できなくなると思います
• 市町村名+町名(字を含む）,市町村名+町名(字を含まない）,市町村名の順番で検索結果が見つかるまで検索を行います

同じ発想のサービスとしては、jm@fooさんのGoogleで地域検索(→Blog記事 →サービスページ)がありますね。
将来構想として、 緯度経度から住所を返すWebService化、携帯電話対応等も考えておられるようなので、とても楽しそうです。

というか、

打倒geocoder.usくらいの気持ちでがんばりますよ(気持ちだけね）

最近別のところでも、今後GeoCodingに力を入れていく、みたいな話を聞いたので、MapServerあたりで地図の表示が一般ユーザの手に降りてきた今後は、次はGeoCodingが熱くなるのかもしれませんね。

モバイルSNSコミュニティ→MoSoSoとかっていう略称はあまりに違和感ありすぎなので軽くスルーするとして。
(というか、dodgeball.comもMoSoSoだとかって書いてあるけど、一般名称なの？)

世界初のGPS情報連動型モバイルSNSコミュニティが出来たそうです。
プレスリリース：
　　・"アクティボ Activo.jp"β版の公開を発表
サイトURL：
　　・http://activo.jp/

さっそく入会しました。
携帯位置情報SNSとしては、先行するサービスとしてHotplaceがありますが、比較してみると、

	HotPlace	Activo
位置情報基盤	iエリア	GPS位置
サービス範囲	3キャリア＋WILLCOM	GPS携帯のみ？
コミュニティ機能	あり	なし
自動位置更新	auの一部、vodafone であり	なし
お勧め場所登録	なし	あり
友人位置通知	同エリア内で自動センサ	伝える側が通知操作
友人以外の位置検索	不可	可能
メッセージング	携帯メール	独自メールボックス
他人からのアクセス制御	なし	ブラックリスト等あり
個人情報	少ない	多い

という感じで、HotPlaceがHotPlaceベースでの新しい友人開拓というよりは仲間うちのコミュニケーションツールっぽいのに対し、Activoはマジで位置情報ベースでの出会いを考えている感じですね。

というか、お勧め場所登録を「位置情報貼り付け」と解釈すれば、限りなくそこはかとなく、私の前社であるSpaceTag社のどこでも伝言板サービスにそっくりです。
もちろん、Activoの方がSNS等の影響がある分洗練されていますけれども、基本的な方向性はほとんど変わらないので、会社の設立された経緯からしてこういう事をやる必然性も、それを実現できる技術もあっただけに、ちゃんとまともに手を入れていればこんな形にも止揚できただろうになあ…と、思い返すと残念でなりません。
まあそれに代わって？Activoに頑張っていただきたい（もちろんHotPlaceもここまるも）と思います。

Continue reading

きのうねねで、承認するはずだった。

*このエントリは、BlogPetの「ここ」が書きました。

この辺の問題も解決できて、やっとcoLinuxでFedora Core3を動かせました。
以下、ひっかかったところを覚書。

• 先のエントリで書いた

  # sh /tmp/script fc3
  : not found: 7:
  set: 8: Illegal option -

  云々のエラーは、coLinux用FC3インストーラを解凍したフォルダ下のlibフォルダにあるシェル内の改行コードが、CRLFになっていたのが原因だった。
  全部改行をLFに変更すれば、インストーラから問題なくインストール成功。
• ちなみに、先のエントリで紹介してもらったこちらのサイトで、

  xml ファイルの記述が間違っていると思われる。
  スクリプトで自動作成しているので、確認できない。

  と書かれているインストーラ作成のxmlファイルは、インストーラ実行フォルダ下のtmpフォルダに格納されている
• インストーラ上の解説で、

  パッケージ管理や GDM ログインを行う場合は、Cygwin の X11 をインストールしておきます。

  とあるが、デフォルトのCygwinインストール＋X11だけではパッケージ管理は実行できない。
  coLinuxに繋げるためにsshもインストールしておく必要がある。
• うまくsshで認証まで行ったにもかかわらずパッケージ管理が起動されずに落ちる場合は、$DISPLAYがうまく設定されていない。
  というか、インストーラ実行フォルダ下libフォルダ内のssh-config-packageの中で、

  DISPLAY="${IPADDR}:0" xhost ${REMOTE}

  として設定されているのだが、この$IPADDRがうまく取得できていない模様。
  よって、同スクリプト内でIPADDRをむりくりCygwinの走っているIPアドレスに設定してやれば、動作する。

といったアタリに気をつけてやれば、インストールできました。

[composed and posted with ecto]

HTTP::MobileAgentがデベロッパーリリースでバージョンアップしていたみたいですね。
現在5/16版の0.23_02が最新のようですが、0.23_01は3月には出ていたみたいです。
デベロッパーリリースは検索で最新にあがって来ないので、気付きませんでした...。
HTTP-MobileAgent-0.23_02

Yappoさんアタリから2月くらいに聞いた話だと、大規模なアーキテクチャの見直しがあるという感じの話が出ているという事だったのですが（私の受け取り方が間違ってる可能性もあるけど）、Changesを見る限り、マイナーアップデートとデータメンテナンスに留まっているようです。

というか、気付いた理由が、ちょうどこちらもHTTP::MobileAgentのアーキテクチャ見直しを、本家が動きそうになければやろうと思い初めて、先のcoLinux環境構築中も、理由の一つがHTTP::MobileAgentの開発環境構築だったりしますが...。
（もう一つの理由は、mod_authfoafのために、マジで作れるかは別として、Apacheモジュールの作り方を覚える環境づくりのため）
というわけで、HTTP::MobileAgent::Plugin::Extensionを作ってきた立場から、HTTP::MobileAgentの改修案を提案します。

Continue reading

普通にはインストールできないのかな？

この辺とかに従って普通に入れてみても、エラー吐いて落ちたりして動いてくれない。

いろいろググってると、coLinuxをベースにしたWindows上のLinuxディストリビューションでこういうのがあったんだけど、そこの動作環境の但し書きに、

NX機能をもつCPU(Athlon64など)でWindows XP サービスパック２を当てている場合はWindowsのboot.iniを書き換える必要がありますので、ご注意ください。

とか書いてある。
どんな書き換えなのかよく判らないけど、coLinuxベースで作られてるから、本家のcoLinuxでもなんかそういう問題があるのだろうか...と疑ったりしてるんだけど...。

でもその観点で情報探そうとググっても何もなさげだけど...。

[composed and posted with ecto]

どうでもいい独り言。

最近の疑問。
うちの会社、このサイト経由で少しは儲けてるんだろうか...。

[composed and posted with ecto]

coLinux 用 インストーラ

coLinux 用のディストリビューション別 Linux インストーラです。
フリーソフトです。
無保証です。
以下のディストリビューションに対応しています。

• Vine Linux 3.0
Vine Linux 3.1
• Fedora Core 2
• Fedora Core 3 Test 1
• Fedora Core 3 Test 3
• Fedora Core 3
• Fedora Core 4 Test 1
• Fedora Core 4 Test 3

インストールするディストリビューションの CD-ROM または CD-ROM の ISO イメージファイルが必要です。
また、ディストリビューションのインストールの前に、 coLinux と Cygwin をインストールしてください。

とりあえず、coLinuxとCygwinとディストリビューションのISOさえあれば、さくっと設定してくれるみたい。

と書きつつ、未テストです。
今ちょうどISOイメージのダウンロード終わったので、Fedora 3でこれから試してみます。

--追記--
他にVine Linuxについてくるstage2.imgと言うファイルが（Fedoraインストールでも）必要なようです。
入手は、Vineの入手ページで紹介されているFTPサーバの奥を辿って、例えばこちらから。

Continue reading

ひゅ〜さんが、先日のau携帯での常時位置追跡方法を使って、特定のメールアドレスに現在位置を常時通知するサービスを作られたようです。

一定時間毎に指定のメアドに携帯電話の位置を送信するページ

主に待ち受けに使われる事になるので、
どなたか、これ用のかっちょいい画像を作ってくれませんか？
わたしのサイトを見ればお判りと思いますが、絵のセンスはまったくありません（恥
複数の画像を選んで表示出来る程度の機能は付け加えたいと思います。

との事なので、どなたか絵心のある方はご支援を！

とりあえず、電池の持ちとか、測位できないところに行くとどうなるか、とか、いろいろ気になるので、私も早速試してみます。
その辺クリアしてうまく使えるようなら、いろんなシステムが考えられますね。

とりあえず、アクセスするのに使ったので、これドゾー。

[composed and posted with ecto]

FOAFベースの承認ですが、自分から直接の知り合いに関しては、FOAF上の深度1のノードを走査すれば、承認可能です。
しかしながら、友達深度2、3と降りていくと、自前のFOAFだけでは承認できないため、seeAlso要素を辿って適合するFOAFファイルを探していくわけですけども、これが承認の要求が来るたびに行っていたのでは、時間がかかってあまりに効率が悪い。
特に友達100人できるかなな人のFOAFでは、事実上不可能に近い。
というわけで、コンテンツの承認範囲にFOAFの深度で制限をかけるならば、かけた方の責任で、事前に規定の深度までFOAFを走査しておいてキャッシュしておいてよ、という話になるわけだけど。

でもそれなら、FOAFをキャッシュして、承認要求時にmbox_sha1sumからURL逆引きするための何らかの常駐システムがサーバに必要と言うわけだし、それなら別に深度1の友人だって、FOAFをチェックしなくてもその常駐システムに問い合わせればよい。
そう考えた時に思いついたんだけど、自分の交友関係って、全てが全て明かしたいもんじゃないような気もするわけだけど、かといって、FOAFという誰にでも見えてしまう固定ファイルがベースだと、他人に見せたくない知人については、その知人による自分のサイトへのアクセスすら締め出してしまう、という事になってしまう。
そうではなく、飽くまで常駐して人間関係ネットワークをキャッシュしておくシステム内の人間関係こそが正で、FOAFファイルはそのシステム内のデータのうち、他人に公開してもよい部分を便宜のために切り出したもの、と考えれば、知られたくない人間関係を隠しつつ、その隠された友人へのコンテンツ承認も実現できるんじゃないか、と考えた。

ステルスFOAFとでもいう感じですね。

[composed and posted with ecto]

今までFOAF認証、認証と言ってきましたが、OpenIDなり秘密鍵プロキシなりの認証システムの力を借りて個人を認証後、FOAFベースでコンテンツへのアクセスを承認・制御する考え方なので、呼び名をFOAF承認とでも改めたいと思います。
近々、kawaiさんのOpenID仕様の和訳等も参考にしつつ、用語の統一を図りたいと思いますが、とりあえず今日は時間がないので上記のみ。

で、そのFOAF承認ですが、バックエンドとなる認証システムにOpenIDを使うのか、TypeKeyを使うのか、はたまたLIDかDASHか秘密鍵プロキシか、秘密鍵ブラウザか...等と言って来ましたが、考えてみれば何でもええやん、という気がしてきました。
というのは、別に承認サーバ側が複数のプロトコルにさえ対応していれば、閲覧者がmbox_sha1sumを送ってきて承認を要求してきた時点で、承認サーバの対応できる認証手段と閲覧者側の対応できる認証インフラ（認証サーバやプロキシ、ブラウザ等）の擦り合わせを行って、一番信頼度の高い認証手段で認証してもらえればそれでいいのではないかと。
ちょうど、今のブラウザとWebサーバがAccept-XXX：系のヘッダをやり取りしているのと同じ感覚で、対応可能な認証手段を選んで認証後、今度はFOAFベースの承認に入ればいいのではと。
固定しない事で、将来的によりセキュアな認証手段を組み込む事もできるし。

とはいっても認証手段別に確保できる信頼度は変わってくるので、承認側は認証手段毎に公開できるコンテンツを制御するとか、対応すればいいのではないかと思います。

[composed and posted with ecto]

こちらで報告したSubversion＋GDSでドキュメント管理をするシステムの案ですが、社内レビューをしたところ、やはりWordやExcelといったバイナリファイルをバージョン管理するのに、SubversionやCVSといった衝突検知->マージ型のバージョン管理は難しいのでは、という検討結果になった。
Diffが効かないので、下手をすれば差分を抽出するのにかかる時間・手間のコストの方が、バージョン管理で得られるメリットに勝る場合があり得るからだ。
やはりバイナリドキュメントを管理するのならば、完全排他型の管理でなければ、という話になった。
一理ある。

で、またいろいろ大勢で検討していると代案も出てくるもんで、完全排他型のバージョン管理システムの代表であるVSSは、コマンドラインでレポジトリの最新スナップショットをファイルシステム上に吐く機能があるらしいんだけど、それを毎深夜とかバッチで動かして特定フォルダに吐き出して、それにGoogle Desktop Searchのインデックスを張ればどうか、という案が出た。
なるほど、それでもそれなりの用には事足りるかな、という気もする。
GDSで得られる検索結果から取得できるファイルが、前夜に吐かれたスナップショットであって必ずしも最新版ではないため、検索結果はドキュメント取得手段になり得ずVSS上での希望ファイルの存在位置を得るための参考ポインタにしかならない、といった難は存在するけれど。

Continue reading