![[ここｷﾞｺ!]](http://kokogiko.net/logo.png){kind=logo}
2005年06月30日
Google、マッピング技術を開発者に開放
Google Mapsとその他の情報を組み合わせたサイトは既に多数存在しているが、正式にはサービス契約に違反していた。
今回の決定で、こうしたサイトの開発は違反ではなくなった。
キターーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー！
2005年06月29日
coLinux+Samba+TortoiseSVNで激しく楽をする
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上に落としてきて...とかしなくていいのです。
これは本当に便利です。
本文の方が短いですね...。
投稿クライアントの「BlogWrite」
により投稿されました。2005年06月27日
ミステリでもなんでもなかった(BlogPet)
2005年06月26日
位置情報ヒヤリハットマップの有効性
前の会社で何度か挙がってた案件に、地域（地方自治体とかいうより下の、地域自治会とか、地域NPOとか、そういう先）に位置情報システム納入して、チビッ子達にGPS・カメラ付き携帯電話持たせて、ヒヤリハットな場所のレポートを作らせてIT的に公開する、といった類のものがあって、
そういう案件の場合、子供にケータイを持たせたくない、といった類のものは別として、よく反対意見として挙がってたのが、「手作業で集計して紙媒体でレポートを各家庭に配ったり、地域掲示板に張り出したりするのに比べて、どんな優位性があるのか」といった話で、まあそれに対する明確な回答は正直持っていなかったわけなんですが、
先日、うちの近くにそういった危険箇所マップが作られて近所の地域掲示板に張られているのを見て、IT化する意味が判りました。
というか、はっきり書いちゃうと「IT化しないと作る意味がない」。
これ、見てください。
地図の上にいろいろ、私のいつもよく通る道なんかにも「ここ危ない」とかマーク描いてあるんですが、何がどう危ないのかさっぱり判らないのです。
報告者によって「危ない」の視点も基準もまちまちだと思いますが、それが判らないと他人には「？？？」でしかないので、正確な場所もよく判らないし、何を言わんとしているのかさっぱり伝わってこないのです。
これが、それぞれの危険地帯の具体的な写真があって、こういう点が危ない、等と解説されていれば、ああ、なるほどね、確かに、とも頷けるのだろうけど、この図では何が何だかさっぱり。
紙媒体だってそういう補足情報を載せる事は可能だし、単に見せ方が悪いだけかも知れませんが、でも今度は1媒体で載せられる情報量が減少するのは必至。
今くらいの地域の切り分け粒度だと、ああ確かに自分達の地域、というイメージはありますが、これ以上小さい切り分けになると、その中で自分の家が含まれている区画、といっても必ずしも自分の活動テリトリーとは限らないし、むしろちょっと離れたところの方が主テリトリー（駅への通勤路とか）というケースも多々ある気がします。
地域切り分けは今ぐらいの粒度で、その中で自分の活動エリア内での報告等、受け取り手が興味を持った報告のみ、詳細をオンデマンドで配信する、という形態をとらないと、肝腎な事がさっぱり伝わりません。
そういう形にするには、Webなんかで全体像を配信して、危険地帯アイコンをクリックすると詳細が表示される、といったIT手段でなければ行えないのではないか。
もちろん、そういう形にする事によって、本当に危険地帯情報等が必要な老人や障害者等、社会的弱者にディジタルディバイド問題のために伝わらないのではないか、という懸念は生じます。
でもだからといって、それは区民センターや老人施設等、そういった方が集まる場所に、判り易いインタフェースの端末を準備し、かつ職員に操作を説明できるよう教育を行う、といった運用等の工夫でカバーすべき問題で、そもそも誰にも情報が伝わらない手段に逃げてそれでよし、という問題でもないでしょう。
それならそもそもやらない方がマシ、金の無駄、じゃないでしょうか（ちなみに、地図というのはWeb配信だけではなくて紙・印刷媒体でも高く、著作権をクリアして配布物等を作ろうと思えば、配布数に応じてそれなりの金額がかかります）。
というわけで、ヒヤリハットマップ等の広報には、できる限りIT的手段を用いないと意味がないのではないか、という事を提言として挙げたいと思います。
※なんかBlogWriteでうまく画像がアップロードできない...ので久々にectoで投稿です。
[composed and posted with ecto]
災害時通知用携帯位置情報SNS「ポジタル」
ずいぶん古い記事にコメントもらって紹介いただいたのですが、
災害用に備えて自分用に作っていたものをサービス化しました。
まだアルファ版なのですが、最近地震が多いので公開しました。
また、位置情報機能をいろいろとつけています。
収集したニューススクラップやブログ記事、ブックマーク、掲示板のスレッドに位置情報をつけるので、既存の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使ってなければ何やっても一緒かもしれないけど。
SpatialとGeoSpatial
会社の会議で、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でも標準で対応するようになったので、より試してもらい易くなった」見たいな話を聞いて、その後自分でも裏付けたような記憶があるんだけど、今探しても情報が見つからないな...。
2005年06月25日
Google Mapsの地図と衛星画像は重ならない
飽くまで専門家（俺じゃないっすよ）がこだわるレベルで、の話で、「オモロゲ」には影響しないっすけどね。
Google Mapsの衛星写真って、オルソされてないんですね。
これ、うちの近所なんですけども、高いビルの壁面とか思いっきり見えてて、どの方向の視点から撮ったか丸判り。
というか、俺も4ヶ月前から今の仕事につくまでは「オルソ」なんて知らなかったんですけども（今も自分でやっているわけじゃないけど。そんな楽しそうな事やってる同僚を横目に手配師みたいな事とかやってたり）、逆に最近知ったばかりなだけに、「衛星写真＝オルソされた写真」という思い込みを持ってたりしたんだけれども、そういうわけでもないんですね。
まあ当たり前か...加工手順が余分に入っている＝データとして価格が高くなる、と言う事だし...。
でも、真上からの図に補正されていないズレまくりのままの写真っちゅう事だから、切り替えられる地図と重ね合わせても重なり合いはしませんわな。
というか、それ以前に、nishiokaさんとこのコメントにも書いたけど、Google Mapsの図法って、衛星画像（正距円筒図法っぽい）と地図（メルカトル図法）で一致してないのね。
相互の間で行き来する時には、流石に中心点の経緯度をキーにしてるようでおかしなところに飛んだりはしないみたいですけど。
そりゃ、オルソどうこういう前に、もっとダイナミックに重なりませんわな。
ほならなんでオルソ書いたかいうて、お前、それ「オルソ」いいたいだけちゃうんかと。
いわゆる「地図サイト」の座標系って？
ここまでは簡単だったのですが、僕の目的である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倍くらいの差が出てくるはずなのに...これはさすがに、当時からおかしいよなー、と思ってたけど...。
2005年06月24日
逃げのネタ帳
とりあえず言及したいネタ帳。
こういう逃げはありなのか。
- 多機能ファイル転送ツール ZCopy for Win
- Subversionが1.2になってlockもできるようになったらしい。 - 浅倉卓司＠blog風味？ <- 関連１、２
- 位置情報再考 - ひゅ??の思いつき
- Google Maps Remixというのが流行っているらしい - Nakamura-KU ADDICT <- 地図の座標系の話が
- ポジタル <- このサイトすごい！すごいですけど...A5505SAで位置が取れません...。
- ヒヤリハットマップの有効性
- 位置情報携帯サイト相互連携、連携APIのUDDIみたいなもん、勝手位置QRコードの案
- OpeｎID、新Perlモジュール公開
2005年06月23日
敬意の時代になるといいですね
仕事がむっちゃ忙しくなって（それでも職場を出るのは1、2位を争うくらい早いのだが...息子の世話もあるし体がそもそも持たないんだから仕方がない）、後私事でややこしい話があったりもして、この辺やこの辺も、むちゃくちゃ言及したくても時間が取れないのだが、とても共感するエントリがあったのでそいつだけ。
大企業が下請けに出すときや、あるいは経営者が従業員に対してはもっと敬意を払うべきだとも思う。
もちろん逆も必要だと思うけど、逆は必要以上に卑屈になってるケースが多いからなぁ。
全く同感です。
その辺の最低限の人としての心さえあれば、うまくいって莫大な富だって生み出せていただろうに、それがなかったためだけに空中分解してグチャグチャになってしまったプロジェクトも、グチャグチャになり具合の規模は様々ですが、いくつも出会ってます。
逆にそういうのがうまく回っているところでは、まあビジネスは必ずしも製品の出来具合だけでは決まらないので、私の過去の実話ですが世界一の性能を発揮する装置を作っても、別の技術の台頭でその装置の必要性がなくなってしまうといった市場情勢の変化等のために全く売れなかったりと絶対成功するとはいえませんが、少なくとも「モノ」としてはいいものができると思ってます。
2005年06月22日
ミステリでもなんでもなかった
- 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倍近くにまでなっている。
これは何だろう？
こんな事があるのだろうか。
誰か、説明付けられる片、おられますか？
2005年06月20日
HTTP::MobileAgent::Plugin::Location(BlogPet)
ここはキャリアみたいなblogしたよ♪
きのうここが、ここまでblogしたかったの♪
ここへblogしなかったー。
深刻なセキュリティホール発覚！！！-w e b d o gこれじゃナニか侵入してくるかも...
*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。
2005年06月19日
個人で手が届く8GBのシリコンストレージだって
もう既にあちこちで話題ですが。
日本ギガバイト、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組む等というような意味のない贅沢に金を費やせるような身分になりたい...。
一般名初めて聞きました
副作用の重い肺炎による死者が多発した肺がんの抗がん剤「イレッサ」（一般名ゲフィチニブ）について、米食品医薬品局（ＦＤＡ）は１７日、新たな患者にはイレッサを使うべきでないとする警告を出した。
一般名初めて聞きましたよ...。
誰か私に一般名というものの定義を教えてください。
Googleの検索結果：
HTTP::MobileAgentのプラグイン取り込み機構案
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
処理の流れとしては以下のような感じです。
- HTTP::MobileAgentのimportで、サブクラス・プラグインが自動認識され、それぞれの初期化メソッドが呼ばれる（前エントリ記述部分）
- 各プラグイン（或いはサブクラス）の初期化メソッドから、HTTP::MobileAgent（或いはサブクラス）のadd_plugin_methodが呼ばれ、メソッドの動的追加要求が出される。
- 追加要求されたHTTP::MobileAgent（或いはサブクラス）は、自分の__DATA__領域のデータを確認する。
__DATA__領域には、既に本体側仕様に取り込んだプラグイン、及びそのバージョンが記録されている。 - 確認した取り込み記録と追加要求してきたプラグインの名前・バージョンを比較し、そのプラグインが本体側に取り込まれた記録がない場合、或いは取り込まれていてもバージョンが古い場合のみメソッド追加を許可し、それ以外は拒否します。
という感じになっています。
これで何がよいかというと、本体もサブクラスもプラグインもバラバラに開発される場合を想定すると、
- まず、いちいち本体とプラグイン作者が歩調を合わせる必要がなくなります。
既存のHTTP::MobileAgentと拙作のHTTP::MobileAgent::Plugin::Extensionなんか最悪で（すみません）、まあ本体が長年更新してこなかった部分の穴を埋めた役割は果たしたとは思うんだけど、HTTP::MobileAgent::Plugin::Extensionが本体のメソッドも何も乗っ取ってしまっているので、HTTP::MobileAgent::Plugin::Extensionを入れている限りは本体側でメソッドを更新しても反映されず、本体の更新に支障をきたしてしまう、という問題がありました。
この動的メソッド追加の方式を導入する事で、本体側で古いプラグインに関しては取り込みを拒否する事ができ、上のような問題も解決できます。 -
機能毎の専門家であるプラグイン作者の作ったコードを、キャリア毎の専門家であるサブクラス作者が上書き修正する事ができ、役割分担で相互補完できます。
例えば、位置情報の専門家？が、各キャリア横断で位置情報を利用できるようにするプラグインを作ったとします。
でもそのプラグイン作者は各キャリア毎の専門家ではないので、キャリア毎の専門家であるサブクラス作者から見ると、そのやり方はおかしい、というような場合もあると思います。
こんな場合、サブクラス側で修正したメソッドを実装してやり、かつこのプラグインはこのサブクラスでは取り込み済みですよ、と__DATA__領域に記録しておいてやると、そのサブクラスに関してはプラグインではなくサブクラス側の実装が優先され、ユーザにとって最適なロジックを提供する事ができます。
まあ、サブクラス作者がプラグイン作者にパッチを送ればすむのでは、という話もありますが、歩調を合わせなくてもできる、という事で...。 - 別にこういう方式でやっているからというわけではないですが、プラグイン作成方式の標準ができる事で、プラグイン作成の心理的障壁が低くなり、例えばCPANなんかに登録されるとやばいコンフィデンシャルな仕様の処理プラグインが、密かにアングラで公開されてみんなハッピー？とか...（いや、そんなん奨励したらあかんやろ）。
とかいう感じの利点があるかなと。
もっとも、プラグイン単位で追加要請の許可/不許可を出すので、本体側があるプラグインの一部しか取り込みたくない場合とか、どうするの？といった問題は残るのですが、まあその辺は完全にコミュニケーションレスにすると言う事ではなくて、適宜話し合って決めてもらわないと仕方ないかなと。
でも何でもかんでも話し合って歩調合わさないと進まない、と言う形だと、分業開発（しかも個々が中途半端に独立しているような）とか無理かなと思ったので、少しでも楽になるような機構を考えてみました。
とりあえず、私が全部作るのもアレなので、こんな感じでぼちぼちとこちらで挙げた提案事項の実装イメージが揃った時点で、本家に提案して、 了承を取り付けてから、旗振り役が本家になるか私になるかは別として、サブクラス作者やプラグイン作者を募って公開開発みたいな形がいいかなと思ってます。
2005年06月18日
東京のチャング奏者募集
狂言の後輩の弟が今年東京の芸大に入ったんだけど、本人曰く「グシャグシャかき鳴らし系のギター奏者」だそうで、チャング（韓国の伝統楽器）とのコラボレーションがやってみたいらしいのです。
一度遊んでみたいだけなのか、継続的に活動したいのかはよく判らないのですけども。
それで、関西で一時期「ちょっとだけ」チャングをかじっていた私に相談してきたのですが、私も関西にしかチャング人脈ないし、その関西ですら元々「超ヘタクソ」以上の腕前に上がらなかったので知名度？もなく、それ経由では関東でどの程度人脈を掘り下げられるかはイマイチ疑問だったり。
というわけで、そーゆー事がやってみたいチャング奏者の方、もしよければコラボってやってもらえないでしょうか。
連絡待つ。
#関西なら打って付けの奴がいるんだけどなあ...。
やっぱり継続は力なり
今日は息子を連れて狂言の練習。
毎日会社の通勤で台本を黙読してると、ブランクもあるとはいえさすがにある程度のキャリアで間の取り方、台詞回しの緩急、あたりは想像もつくし計算もできるんだけど、計算できなくなるのは体力の配分と言うか、ペース配分というか、そういうアタリ。
家でもどこでも大きな声を出して練習できるようなところは事実上ないので、出せるのは1ヶ月に1回の練習の時だけなんだけど、そうするとブランクでパワー配分の勘所を忘れてしまい、つい最初からパワー全開でぶっ飛ばしてしまい、50分近い1人芝居なのに15分くらいで息切れが。
やっぱ何事も継続してやってないと、勘所を忘れてしまいますな。
コーディングもそんなもんなのかもしれない。
しかし舞台は10月2日で、後7、8、9の3ヶ月しか練習がないのに、いまだに息子は台詞が（覚えてるんだけどふざけたり恥ずかしがったりするので）言えなくて立ち稽古するどころじゃないし、親の方は親の方で、もう一番役を付けられて今日初めて台詞練習するし。
本当に出せるのか。
月1回、金曜夜間と土曜午後の練習のところ、金曜は仕事で行ってられないよ...という事で土曜しか参加してなかったんだけど、これは月1回、息子早く幼稚園から引き取って、親子共々金曜日も参加しないと無理っぽいなーと思いました。
新しく付けられた役は、佐渡狐という狂言のお奏者（下級役人）の役。
佐渡と越後のお百姓が都に年貢を納めに行く際、佐渡に狐がいるかどうかで言い争って賭けをする事になり、その判定を年貢納め先の下級役人がする事になるんだけど、役人は佐渡の百姓から賄賂をもらって（本当は居ないのに）佐渡に狐は居ると判定して、越後の百姓がその嘘を見破ろうとするのを、佐渡の百姓と役人で誤魔化そうとしてドタバタする、という奴。
この手の年貢百姓掛け合い系には珍しくドタバタ系の普通に笑える奴で好きなんだけど、こういう役だと世情のアレがアレだけに、アクメツされないようにしないとね...。
BlogWriteIIに乗り換えよっと
BlogWriteII正式版公開 - HepCat Dev and Test
当ブログExclusiveでBlogWriteの正式版を一足早く公開いたします。
という事なので、前からectoからの乗り換えを悩んでいたのですが、何となくお祭り・お祝い気分で乗り換え決行しました。
ectoがBlogWriteより使い易かったわけじゃなくて、単にectoには金払って正式版にしてたから悩んでただけなのですが、メインはectoで表挿入とかBlogWriteにしか出来ない事はお試し版でやってと使い分けようと思ってたけれど、ただでさえ色々シンドイのに使い分けるのも面倒なので、この際乗り換えました。
乗り換えてみて判ったけど、ectoで悩んでたアップロードファイルの保存先の固定とか、結構かゆいところに手が届く感じなんですね。
さっそく気に入りました。
乗り換えたといっても、まだ送金？手段がないようなのでとりあえずまだ購入してませんが、ベクター等にアップされれば送金したいと思います。
末永く使い倒させてもらいます。
小さい子供のいる家庭には、手動シュレッダーがお勧め
ちょっと前の話になるけど、通勤途中の本屋で、個人情報保護法案施行に便乗のシュレッダーセールをやっていたので、何となく買ってしまった。
電動のにしようかとも思ったが、小さな子供もいるので小さな手動のものにした。
手動だと、手を突っ込んだだけでは怪我しないしね。
というか、電動は高いし。
売り上げランキング: 98
このページは在庫状況に応じて更新されますので、購入をお考えの方は定期的にご覧ください。
格安でクロスカット。
クロスカット 手動ではありますが使ってみると、労力を使うこともなく、意外とサクサクと処理できる。
家で発生するレベルの廃棄処理したい書類の量なら、これで十分だ。
というわけで、小さい子供のいる家庭にはお勧めの一品。
ニーズとしても、子供向けの通信販売のDM送り付け先とか、子供の居る家の個人情報ってどう使われるか判らないからね。
余談だけど、これを使って、これまで廃棄できなかった、個人情報満載の古い書類群まとめて処分しようとしたら、1年半前、大阪から東京に引っ越してきた際のADSL開通申込書写しが出てきた。
これ、こちらにも書いたとおり、中々開通しなくて、大阪から東京に引っ越しているのに、
「開通希望日に大阪の旧電話番号で開設処理しました！え、東京なんですか？すみません、設定変更にまた2週間ほどいただきます」
とかって大変だったんだけど、今回出てきた写しをみたら、実は私の申し込みミスだった事が判明！
廃止する回線側に東京の電話番号、開通する回線側に大阪の電話番号書いてた！
今更ながら、ごめんなさい、e-accessさん...。
[composed and posted with ecto]
放火未遂
うちの区民住宅で、放火未遂があったらしい。
現場は中層階（複数）の非常階段踊り場付近で紙の燃えカスがあったらしい。
俺の階のすぐそばやんけ...。
怖い話だ。
というか、俺の部屋はスプリンクラー設置階にあたるので、火事になると全体では大事にならなかったとしても、うちの部屋は大事になる可能性大。
是非ご遠慮願いたい。
[composed and posted with ecto]
さよなら、PERL
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]
2005年06月17日
ステルスFOAFに近似な仕様があった
書く時間が取れなくて後手後手に回ってるのですが、月曜日に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]
2005年06月16日
SpaceTag的承認レイヤ
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]
2005年06月15日
市町村合併をSQLでメンテナンス
地球地図などは、非営利ライセンスフリーのデータで大変重宝しているのですが、いかんせん、無料なためか鮮度がちょっぴり悪いです。なるほどー、突っ込んだデータを使うしか能がありませんでしたが、そういう使い方もできるんですねー。
そんなとき必要なテクニックが、最新マップへの更新です。更新といっても SQL 文だけでできるお手軽なメンテナンス方法をご紹介します。
勉強になります。
他にも、「近隣市町村どこよ？」（境を接する市町村の選択）など、面白い利用法を解説してくださっています。
[composed and posted with ecto]
HTTP::MobileAgent::Plugin::Location
前書いたここギコ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]
2005年06月14日
京都限定 手作り抹茶ドリンク
この4月から家内が大学院生になったんだけど、通学先がなんと京都。
週2回、早朝の新幹線で行って深夜に帰ってくる。
好きこそ...とは言うけど、ようやるわ。
で、今日は京都みやげに向こう限定で売っているらしい、手作り冷抹茶ドリンクを買ってきてくれた。
これが中々面白い。
「お手前緑茶」の名の通り、飲む直前に水と抹茶から自分で作るのだ。
こんな感じで、最初は単なるミネラルウォーター。
ここでいったん蓋を外すと、中ぶたがカチッと外れて、中に入っていた抹茶の粉が水の中に落ちる仕組みになっている。
こんな感じ。
ここで、ペットボトルを振ると...水と粉が周囲に撒き散らされてえらい事になる。
「ちゃんと注意書きを読んで（家内談）」、一度蓋を閉めなおしてしゃかしゃか振ったり回したりしてみると...おいしそうな冷抹茶ドリンクのできあがり。
飲んでみると...苦味は全くなく、さっぱりとしておいしい。いや、むしろ甘い感じすらある。
「グリーンティー」とかって名で知られる、よく観光地なんかで売られてる砂糖入り抹茶ドリンクあると思うけど、あれの砂糖入ってないバージョン、もうちょっとお茶の濃厚さがあるけど、みたいな感じ。
あの「グリーンティー」って、砂糖入ってるけど、砂糖入ってなくても苦味はほとんどなさそうな感じでしょ？そんなイメージ。
あまりにもさっぱりして飲みやすいので、苦いのなんか大の苦手なはずの3歳児ですら、もう一口二口ちょうだい！とせがんでくるような味。
京都に行かれる機会があれば、探して飲んでみられては如何？お勧め。
[composed and posted with ecto]
My firefoxのセキュリティホール
これじゃナニか侵入してくるかもしれないから二丁目とか歩けないですね。早くパッチあてなきゃ！私の「firefox」Ｔシャツには、右脇の下に脆弱性が発見されています。
深刻度は「軽微」なので、パッチ適用は見送る予定です。
[composed and posted with ecto]
2005年06月13日
歴史は繰り返す その２(BlogPet)
広いマインドマップとかを経過しなかった
明日、FOAF承認絡みで飲み会をするので、これまでの議論経過マインドマップにでも...
と、ねねが考えてるみたい♪
*このエントリは、BlogPetの「ここ」が書きました。
電柱広告に位置QRコードを是非。
昨日、息子を連れて散歩をしていて、電柱を見てドキッとした。
電柱広告で有名な街あど(tadp.jp)広告で、QRコードが着いたバージョンを見つけたのだ。
すわ、私が以前書いた、位置情報とQRコードを結びつけるアイデアが実現されたのか？と思ったが、単にトップページへのリンクだった。
どうせ電柱広告なんて、住所も広告も一つ一つ違うんだから、個別印刷部分が絶対発生するわけだし、位置情報付きQRコード埋め込めばいいのになあ。
もしくは、誘導するのはトップページでも、そこで電柱番号入力すれば、現在地が判るようにするとか。
今でも、電柱には住所が書かれてるし、今のトップページには住所から地図を表示する機能もあるので、まあ使えない事もないんだけど、電柱上の住所が町丁目からしか書かれてないのに、サイト上の住所選択は都道府県・市区町村からなので、こんな区境だとこの町は目黒区なのか品川区なのか判らないと検索できない。
さらには市区町村や町丁目の選択でまず五十音絞込みをかましてるので、手間が増大な上に電柱上の住所が難読だと使えない。
こんなだと、せっかく自分らの努力で街中の電柱に住所表示してやってるのに、それをみたユーザは住所から簡単に位置を取れる普通の地図サイトに流れてしまって、みすみす他社にビジネス機会を与えているようなもんだ。
せっかくGPSケータイじゃない端末にまで、位置情報のゲートウェイとして簡単にリーチできる手段を持ってるんだから、住所入力よりもっと簡単な位置特定インフラを整えて、位置情報ポータル化すればいいのに。
いや、位置情報ポータルに必要な地図は高いし、まだサイト上で地図を導入してない、っていうんなら薦めないけど、既に地図は借りてるんだから、うまく活かさないともったいないよね。
[composed and posted with ecto]
2005年06月12日
歴史は繰り返す その２
明日、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]