きのう、ここへblogされた。
ねねはここで嵐みたいなblogすればよかった？
きょうここは、blogした。

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

家内が風邪引き。
息子を練習用自転車に乗せて、「お母さんレスキュー隊！」とか言いながら近所の薬屋に風邪薬を買いに行った。

途中、こんな会社があった。

それを見て息子が一言。

「や！」

なるほど...確かに字体が似とるわな...。

もうすぐ客先に、製造に入る前の最終設計書提出ということで、ＱＡチェックをみんな受けてる最中でプロジェクト中大わらわ、土曜の休日出勤もそのせいだったんだけど、ＱＡで品質上げるとか言う前にＱＡのクオリティが低すぎる。
文章表現チェックとかしてくれるわけなのだが、ＱＡの中自体でそのチェック観点とか共有されてないから、チェックした人間によって温度差が出まくり。
その結果、せっかくチーム内で数ヶ月かけて、担当範囲内ではある程度全体の体裁を合わせてたのに、各人担当部分に来た指摘に合わせて修正してたらたったの1日で体裁バラバラ。
何のためのＱＡか全く判らん。
指摘して半日とかで修正させようとするからチーム内調整する間もないし。
というか、ＱＡの指摘表自体が、Ｗｏｒｄで来たりＥｘｃｅｌで来たり、体裁が統一されてないのはどういうことよ？

大体こっちは前の月曜がチェック依頼の提出締め切り、それも最初は定時締め切りだったのを朝に変えて欲しいというから、繰り上げて提出してるのに（とは言え朝には間に合わなかったが）、それに対する指摘の返答が土曜の朝になってからってどういうことよ？
指摘に対する修正の回答締め切りが土曜の夕方となっていて、なるほど修正が間に合わなければ休日出勤か、でもしなくてもいいように頑張ろう、とか思って指摘待ってたら、一週間待てど暮らせど指摘が返ってこない。
何時返ってくるかの見込みもない。
結局ぎりぎりまで休日出勤の要ありやなしやが判らないまま、金曜の定時後4時間過ぎても指摘が返ってこず、休日出勤確定。
ぎりぎりまでわからなかったせいで、チーム全員揃えられなかったし。
そのくせ土曜朝になってやっと出てきた（しかも揃ってない。全部揃ったのは土曜昼）指摘表を修正して提出する締め切りが土曜夕方？理不尽極まりない。
先にも書いたように指摘のせいでバラバラになる体裁を整える暇もないし、だいたい休日出勤なので、全チームが揃っているわけじゃないから、指摘受けた部分修正するために他チームと調整しなきゃいけないような部分でもその該当チームが誰も出勤してなかったりする。
そんなんで品質が上がるか！

まあ、何千ページとある設計書、今のやり方でやってる限りＱＡの人間も死ぬ思いでチェックしてて、「土曜夕方再提出締め切り」と規定しているということは向こうは休日出勤デフォルトにしてるわけなので大変なのは判るのだが、馬鹿みたいな苦労するより先にやり方があるだろうと。
なんで、いちいち提出文書全体をチェックしてから、まとめてドッカと指摘表として出てきて、こっちはこっちで全部修正してから再提出、なんてシーケンシャルな処理をやらないといけないのか？
何度も提案してることだがフリーの懸案管理システムでも導入して、気付いた事があれば順次挙げていって、担当者割り当て→修正→確認とワークフローで回していけばええやん。
そうしたら、そんな半日で修正するなんて状況でもなく余裕もってできるので、この指摘はこの文書だけでなく別の文書の担当にも展開しないといけない、とかリーダーも判断できる余裕もできる。
モニタ上の文書と印刷した文書は違うから、最終的には印刷してチェックしないといけないのは確かだが、少なくとも言い回しや体裁の統一レベルならこれで余裕もってできるようになる。
ＱＡ内部でも、この担当者の指摘とあの担当者の指摘というのがオープンに晒されるようになるから、視点をお互いに共有できて「指摘の品質」が向上する。
また品質チェック作業も、全部出来てから提出させてチェックするんじゃなくて、これも何度も提案してるがちゃんとバージョン管理システムとか導入して、どの文書の最新はどこにあるか誰にでも判るように（誰でも見られるように）しておいて、設計書を作っていく工程にＱＡも参加して随時指摘を出していき、修正済みのチェック等もバージョン確認して行うようにしていけば、ぎりぎりになって全部慌てて修正というようなこともなくなるし、新しい書式に対する体裁あわせも事前に問題が発覚するので、ＱＡ指摘修正締め切りの1日前になって「各チーム毎にクラス図の凡例の有無が異なる？コメントの加筆方法が異なる？どうする？」なんて各チームリーダが頭つき合わせて悩む、なんてこともなくなる。

ＱＡはＱＡで、努力はしてると思う。
前の基本設計や中間設計での失敗を元に、体裁のガイドラインや書式のテンプレートを作ったり、いろいろ周知徹底のための啓蒙活動を行ったり、頑張ってるのは判る。
でも、基本的には「前の失敗」を繰り返さないための事をやってるだけで、今実際にやってる作業に出てきている新しい問題---クラス図なんか前の段階の設計書にはなかったわけだし、構成のレイアウト図もそう---をリアルタイムで認識して、その工程に参加して、品質を一緒に作りこんでいくのでなければ、前の問題だけをベースにまとめた規定をみんなが守ってくれることを期待して、最後の一週間かそこらだけで（うちのチームなんかじゃ後回しにされたせいで最後の1日だけで）帳尻を合わせようとしたって、そりゃうまくいくわけはないわな。

その位ちょっと考えりゃ判るにもかかわらず、現状を変えようとマネジメントせずに、残業・休日出勤も辞さずにみんな心を一つに頑張ろう、とか体育会系ノリで要求されても、ましてやそこまでしても満足のいくものにはならないし、そりゃみんなやる気も落ちるわな。
その上休日出勤をしてるのは課長クラスまでだけで、そういうマネジメントをしてる当の部長クラスのプロマネなんかは普通に休んでるとなりゃ、そりゃね。

よく見たらパッチはmod_access_rbl2へのパッチじゃなくて、mod_accessにmod_access_rbl相当の機能をつけるパッチですた。
これなら勉強代わりにちょっと手を出してみるのもアリかな？

Apache2.2のソース探してみて、アレ？mod_accessどこだ？とか思ってたら、Apache2.2からmod_authz_hostと名前が変わってたのね。
でも中身は、全くといっていいほど変わっていない模様。
それじゃ、Apache 2.0系へのパッチそのまま適用すれば動くんじゃないの？と思って試してみたら、ちゃんと動いてるっぽい。
ちゃんとバリバリ403ではじいてくれます。
DNSBLも当然完璧ではないようで、1割くらいまだBlacklist化されていないIPアドレスからのアクセスは通ってしまいますが、それはある程度溜まれば個別にDenyしてやればいいかなと思います。

というわけで、Apache2.2系向けmod_authz_host用rbl対応パッチ晒しときます。
使い方は、元パッチの置き場サイト漁ってるとそもそも日本人の方が作られてたみたいで、使い方のページがありますが、そこのmod_accessを全部mod_authz_hostに読み替えれば無問題！です。
元サイトの説明書きにもあるとおり、

数万ヒット/日を越えるようなサーバならば、外部のデータベースではなく、自前でブラックリストを運用すべきでしょう。
あるいは、< Files> などのディレクティブを使って、ほんとに RBL によるアクセス制限が必要なリソースだけに適用を絞りましょう。

とあり、まさにうちのサイトは先日までmt-tb.fcgiだけで2万ヒット/日でしたが、敵もさるもの、弾かれるサイトだと判れば粘着する量も少なくなるようで、今はせいぜい数分に1アクセスしか降ってきません。
なのでとりあえずはこれでよしとしましょう。

「勉強になれば」と思って試してみたけど、全くそのままで動いたので勉強もクソもなかったな...。

日々増えるTrackback SPAMの嵐。
日に何度かアクセスできない状況になっていたものの、時間的な偏りもあったし忙しさにかまけてほったらかしにしておいたら、遂に金曜の夜くらいから、終日SSHも繋がらないくらいの状況になってしまった。
2-3秒に1アクセス。
処理を完了して迷惑Trackbackに残ったものだけで日に2万件。
ほとんどアンテナ奪取状態。

とりあえず土曜は出勤だったので対応できず、帰ってきてから何とかSSHを繋げてApacheを止めた。
作業途中爆睡してしまったので、結局ようやくさっき、残った迷惑Trackbackのリストから迷惑IPのリスト作って、全部Denyに設定した。

迷惑TrackBackを自動判定してくれるのはいいが、迷惑TrackBackへの分類もせず問答無用のbanを設定できない（よね？）のは、よくないよなあと思った。　＞　Movable Type
確かに迷惑TrackBackに分類されたものに有用が混じることもあるから、問答無用のbanでなく迷惑TrackBackというバッファを設けることには賛成なんだけど、BlacklistからのTBや「online-casino」なんて記述が含まれるようなTBがまともなTBのわけがないので、問答無用banを選択できる設定も欲しかった。
再構築のコストは確かに削減されてるけど、明らかな迷惑TBのためにDBの挿入/削除コストすら払いたくない。

探したらmod_access_rbl2とかってのがあって、Apache 2.0系へのパッチもあるみたいだけど、うちは2.2だし...mod_accessと排他なので迂闊に手を出しにくいなあ。

--追記--

よく見たらパッチはmod_access_rbl2へのパッチじゃなくて、mod_accessにmod_access_rbl相当の機能をつけるパッチですた。
これなら勉強代わりにちょっと手を出してみるのもアリかな？

大学先輩のブログ経由で得た情報。

2006年7月からEZwebのGoogle検索結果にGoogleモバイル広告掲載 -Gigazine-

KDDIとGoogleが提携ですか...個人的に感慨深いもんがあります。
というのも、Googleモバイルはiモード・J-Skyには早くから対応していたのですが（J-Skyは対応というよりiモード版が見れていただけかもしれませんが）、EZWebは確か2004年の10月まで、多分1年半か2年くらいの間、長らくGoogleが使えないはみご状態で、その間はずっと、私が自分の必要性から作って公開していた、iモード版Googleモバイルへのプロキシサイトが、EZwebからGoogleを使う際の事実上のデファクトだったりしたので。
（AU端末からアクセスすると、XHTML端末であってもWAPと判断され、iモード版URLを直接指定して叩いても強制的にWAPページに飛ばされ、文字化けして全く使えなかったのです。）

当時はすごかったですね...今はなきここギコのモバイルサイトは当時月間140万PVくらいあったのですが、そのうち本当にちょうど半分くらいがEZweb版Googleプロキシ、残りの半分がもう一つの人気コンテンツだったアンテナ奪取（今は別の方に引き継がれて日本縦断アンテナDASH）で2分されてました。
よく落ちてましたね...それだけのアクセスを、今と同じさくらインターネットの一番安い専用サーバの上で、プログラミング技術もDB技術も大したもん持ってない奴が動かしてたので...。

私も別に広告収入があるわけじゃなし、できればネイティブで対応して欲しかったので、公開し始めた直後にGoogleに「KDDIに対応してくれ」というメールを送ったのですが、来た返答は「よく判らないので対応できないよ」といったもので、対応してもらえませんでした。
（今思えば、単に仕様の情報がない、という話だったのかなとも思い、仕様を追加で送ってやっていれば対応してもらえたのかもしれませんが...。英語でのやり取りでしたし、原文が今失われてないので、なんとも判りませんけど。）
結果、2年ほどの間、EZwebの世界では「Googleすなわちkokogiko.net」という歴史が刻まれたわけで。
その位EZweb、KDDIがGoogleから無視され続けていた時代を「世界一」身をもって体験していた立場としては、GoogleとKDDIが独占契約を結ぶ時代と聞くと、隔世の感がありますね...。

知人と話した時に出したネタ。

パソコン通信の歴史を知ろう の補足

たくさんのSNSに加入していても、それぞれの中でこまめにプロフィールをメンテし、近況を伝え、交友関係をメンテしなければ、その手の回らないSNSの中ではその人は無口でリアクションもなくて面白くない奴、と同じ。
そうならないために、自分のブログや他のSNSで書いた日記を、わざわざ別のSNSにコピーして各SNSに同じ日記をいちいち挙げなおしている人もいる。
馬鹿馬鹿しくないですか？

先のエントリの中で上のように書いたが、ちょっと期待してた。
はてブで、「それってPlaggerでできんじゃね？」みたいなコメントがつかないかなと。
コメントつくどころか、全然はてブもされず大すべりだったわけだけれども。
自意識過剰ハズカシス。

というわけで、誰もそんなコメントをしたわけじゃないけれども、誰かがつけてれば言いたかったこと。
たくさんのSNSに加入していても、その全てに同じプロフィールのメンテをして、同じ日記を挙げて、それぞれでの友人ネットワークでの動きを集約して一箇所でみる、なんてことは、とってもギークな人ならPlagger使えば余裕で出来る（俺が余裕で出来るとは言わん）。
他にもネット上で感じるいろんな面倒くささ、使い勝手の悪さ、大抵はPlaggerやいろんなホットな技術使えばローカルには解決できる。

確かに、それができる個人レベルではそれでいい。
でも、それで全てが解決したように議論が終わっちゃうのではいやだなと思う。
Plagger使えば解決できるような問題を、Plagger使えない人でも不便に思っているかもしれないじゃないですか。
「それってPlaggerでできるんじゃね？」
「それってGreasemonkeyでできるんじゃね？」
「それってExtensionでできるんじゃね？」
「それってBookmarkletでできるんじゃね？」
そういう一言がある度に、それで解決できる組とできない組のディジタルデバイドの存在を、時々は意識してもらえたらなー、と思います。

ディジタルデバイド云々言い出したら、そりゃ究極的にはPCすら起動できない人もいるのだから、情報家電とか政策とか、なんかそんなとこまでいっちゃうわけですが、そんなとこは私は何もできる事はないしやっても無駄だし、でもせめて自分の専門範囲、自分がなんか考えれば何か変わりそうな範囲では、時々は多くの人が考えてくれるようになればなあ、と思います。

ハープカメラというのがあるらしい。
土曜日の朝やってる子供向け科学番組で知った。

光電変換に電子雪崩現象を利用して信号を増幅し、広い部屋に蝋燭一本の闇の中でも、太陽や電灯の元と同様に色彩鮮やかな画像を得られるカメラだということだ。
現在リンク先のような暗視TVカメラとか、深海での画像撮影等に利用され、また将来は防犯等で民間にも需要が広まる、みたいな話をしていたが。

思った。
それ、小型化できるのか、低コストで生産できるのか、とかよく判らんけど、再度光に変換して、メガネかゴーグル式でみんな眼につければよくね？
そしたら、夜間だってもっと暗い電灯でもみんな暮らせるし、超省エネにならないか？
大企業なんかで、よく省エネ（まあ実際にはコスト削減だろうが）といって昼休みオフィスの電気が消され、労働中の憩いの時間を手元真っ暗で過ごさせられるような事もあるわけだが、そんなん昼休みの間一時間だけ電気消すくらいなら、これで作った暗視ゴーグルみんなつけてれば、一日中電気不要だぞ。
結局電気なんて、人がいて利用しているところだけ明るければよいのであって、焦電センサでトイレのスイッチオンオフシステムなんてのも基本的にその発想で省エネしてるわけだが、それならもっと進めて、要するに人が利用するところ→人の目元だけ明るければいいのであって、照明全然なしでも、このゴーグルだけあればいいってふうになれば、すげえ省エネになるんじゃないかな、と思った。

まあいろいろ難しそうだがな。急に強い光向けられても眼をいわしたり周囲が見えなくなったりしないよう、増幅制御とか。

というか、番組の中で、暗闇の中での視力を裸眼でハープカメラと勝負した黒人の兄ちゃんはすごかった。
最後の「もずく」と「めかぶ」の判定でハープカメラに負けたが、「緑茶」と「紅茶」、「食パン」と「はんぺん」の判別は真っ暗闇の中で5m離れて余裕で見えてた。
人間の眼も鍛えれば電子雪崩なみの信号変換効率を持てるという事か。
そういえば、昔「忍者のひみつ」とかって本で、忍者は蝋燭の灯を徐々に小さくしていって、暗視能力を身に付ける、みたいな鍛え方の話が載っていたのを思い出す。
将来のエネルギー危機に対応するために、国策として国民みんな暗視能力を鍛えさせて身に付けて、照明にエネルギーを使わない真っ暗な国を作る、というのはどうか。
ダメ？

気になる状態のままほったかされた。

このエントリで買ったペンローズの本、英語と理論両方についていけず早々に挫折。
そしたらペンローズ本（同じ本じゃないけど）の訳がブルーバックスから出ていたので、購入した。
理論にはついていけなくても、言葉のハードルさえなくなれば、なんとかなるのではないか。

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

posted with amazlet on 06.05.21

ロジャー・ペンローズ 中村 和幸
講談社 (1999/04)
売り上げランキング: 51,202

おすすめ度の平均:

「心の影」の要約本
ベストセラーになる数学書の条件

Amazon.co.jp で詳細を見る

そしたら...なんと、なくしてしまった!!!
「忘れた」ではなく、「なくした」。
電車で読みながら乗ってたら、疲れてたせいもあり寝ちゃったんだけど、目的の駅で起きて降りようとしてないのに気付き、座っていた周りを探してみたが、どこにもない。
ドアが閉まって降りられなくなっちゃうので、仕方なく降りて、そのままあぼーん。

まあ忘れっぽいので降りた後まで気付かずに傘を忘れたとかいうのはよくあるが、降りる前に気付いたのに見つからずなくしたというのは初めて。
まだ心について触れた章まで読んでなかったのに。
結局心と量子の関係はどうなの？知りたいけど少ない小遣いでもういっぺん同じ本を買う気も起こらず...。
この辺興味ある方、ぜひ上のリンクをクリックしてお買い上げくださいませ...その収入でまた買います...。

同じような電車で「忘れた」じゃなくて「なくした」もの、他にも立て続けに、YAPCでもらったYahoo!JAPANの折り畳み傘もなくしてしまった。
全く同じ状況。（気付く→探す→見つからない→降りられなくなってしまうので降りる）
気に入ってたんだけどなあ。意外と作りはチャチかったけど（吊り下げ紐とか即効で切れた）。

先日、SNS周りに詳しい某氏とお話させてもらう機会があった。
その時、意見交換しながら今まで気付いてなかった問題に気付いたのだが、

例えば、MixiとGREEがOpenIDのサーバ/コンシューマ双方に対応しました。
http://mixi.jp/acc/fooを持っている人は、そのアカウントでGREEにも新規参加できる。これでMixiとGREEのユーザの同一性が検証できて新たなマッシュアップの可能性等を生み出し、これはハッピー。
その逆もしかり。
http://gree.jp/acc/barを持っている人は、そのアカウントでMixiにも新規参加できる。

しかし、すでにMixiにもGREEにもアカウントを持っていた人はどうする？
http://mixi.jp/acc/bazとhttp://gree.jp/acc/bazのアイデンティティ同一性は、どう保証する？
或いはユーザが、せっかくOpenIDに対応したのなら、お仕着せのhttp://mixi.jp/acc/bazやhttp://gree.jp/acc/bazではなく、Delegateを使って自分のBlogサイトhttp://baz.example.com/で両者にログインしたがったら？
もちろん、言うまでもなく、新規ユーザとして入るのではなく、これまでのアカウントで培ってきた人脈ネットワークやコンテンツを保持したままで、だ。

こう考えると、何らかのサービスを伴うサービス（ややこしい。つまり単なる認証サーバではなく、既存サービスのアカウントを外部にOpenIDアカウントとして開放するような場合、ってこと。LiveJournalとか）がOpenIDサーバ＆コンシューマに対応する場合、そのサービスは単に自社ユーザアカウントを他社サービス上で認証する、及び他社ユーザアカウントが自社サービス上で認証されることを許す、だけでは不十分で、ユーザの要求に応じて自社ユーザアカウントを他社ユーザアカウントで上書きする、というかエイリアスを設けるような仕組みを作っておかないと、ユーザは真にアイデンティティを統合管理するメリットは得られないという事だ。

現在のところ、特定のサービスに直結するようなアカウントでOpenIDサーバとしても動いているのはLiveJournalくらいで、MyOpenIDをはじめほとんどのサービスが認証サービスのみの提供となっているから問題は表面化しないけど、いろんな既存サービスのOpenID対応が広がってくると、この問題は表面化してくると思う。
既存サービスを元にOpenIDコンシューマを立ち上げようと思っている人は、気をつけた方がいい。

IPAX会場であったもう一つの嬉しいイベント、それはオライリージャパンからの新刊、入門Webマッピングの見本誌が刷り上り、オライリー担当者の方から手渡していただいた事です。
オークニーの方々、そしてたくぼさんとの共訳ということで、早速オークニーさんはIPAXのブースに飾っておられました。

「Mapping Hacks、Web Mapping Illustrated日本語化の声を挙げようよ」へのコメント

邦訳版、出るみたいですよ

すみません、それ私が一枚噛んでたのです...。
森さん、たくぼさんはレポート済みなのに、一人告知が発売後にずれ込んでごめんなさいです。

私の翻訳担当は、主に付録部分、

• 付録A　地図投影法概説
• 付録B　ベクトルデータアクセスに関するMapServerリファレンスガイド
• 付録C　日本版読者に向けての追加情報（の一部、マップデータの入手と測地系関連部分）

でした。

森さんもレポートで翻訳の難しさを書いていますが、やっぱ読む英語と訳す英語は違いますね...元来それほど英語が得意ではないもので、よく言われる英語を読む時のコツ「単語一つ一つの意味で止まって拘らず、とにかく判らなくても流して読んで大意を掴め、そしたらだんだん慣れてきて判ってくる」というのでようやく英語を読む苦手意識もなくなりかけてたところに、訳すとなると「大体感覚で判ればいいや」「判らなければすっ飛ばせばいいや」では済まないので、一度ざっとは読んでいたものの訳せるレベルまでは全然細部を理解してなかった事に驚愕、1から読み直しという感じで。
その癖妙に日本語表現にはこだわるもので、自分の訳部分は遅々として進まないくせに他人のが出てくると「あっちとこっちの表現がずれてないか」とかダメ出しの嵐。
我がまま坊や状態で、共訳者の皆さんには本当に迷惑をかけたと思います。

あ、そうそう、出版記念パーティーをやろうかと言ってるのですが、内輪だけの会にせずに、ついでに過去何度かやってきた、位置情報マニア飲み会の延長線上でやろうかと言ってます。
過去の飲み会は知り合いの知り合い、とかで声かけてやってきたのですが、今回はオープンな感じで、誰でも位置情報に興味があれば、な感じで。
またどういう形にするか森さんと協議しつつ決まれば告知しますので、ご興味のある方は是非。

＃過去の位置情報マニア飲み会って何回やったんだったかな？名古屋1回、横浜1回はガチなんだが、東京は2回だったっけ...忘れた。

--- 追記 ---

お礼を言うべき相手を一人忘れてた。
この翻訳プロジェクトが始まるきっかけとなった、オライリージャパンを紹介してくださったのみまくし日記の木村さん、ありがとうございました。
上記記念パーティの際は、木村さんも是非。

IPAX中にレポートできればよかったのですが、書けずにごめんなさい。
会期中の午後都内出張があった日に、午前半休を取って行ってきました。

目的はもちろん、先日のエントリでも書いた、オークニーさんのPostLBS。
見せてもらったが、予想以上にすごい。
私のレポートよりも、IPAXから戻ってからデモサイト（上記リンク）の存在に気付いたのでそっちで実際に触ってもらった方が早いと思うが、単純な（と言ったら悪いが、単機能ではなく、といった含意）最短経路検索だけではなく、巡回セールスマン問題、ある地点を中心としての道程が一定範囲の領域の検索、等といった機能もある。
最後の機能なんかは、正確な商圏の分析なんかでマーケティング分野で利用できそうだ。
単に距離での領域決めでは、近くに川等があって到達手段がないようなところまで、範囲に入ってしまうからね。

最短経路検索の実行例。
まあ、シンプルに。

巡回経路検索の実行例。
ちょっと判りにくいね。デモサイトで試してみて。

到達範囲検索の実行例。
明らかに川を挟んだ向こう側の到達範囲が狭くなっていて、道程で一定範囲の領域が検索されているのが判る。

ジオコーディングの方も、入力した住所を元にKMLを発行してGoogle Earthと連携するマッシュアップが展示されていたりと、中々面白い展示だった。

PostLBSは大きく分けて経路探索系とジオコーディング系の機能に分かれていて、経路探索系はオークニー社の優秀な外国人スタッフが作ったということもあり、すぐにでも国際的オープンソースプロジェクトとなり得るけれど、ジオコーディング系の方は今のところゴリゴリの日本住所特化で、国際化はいまだ、という状況だそう。
「インターフェースだけ固定化して、各国対応はプラグイン化して各国の開発者に自由に作らせることで国際化しては？」と提案したところ、今はそうはなっていないがいずれそうしたい、ただ各国の住所体系はあまりに違いすぎていて、日本のように全体を一つの文字列として表せるところもあれば、米国のように通りで位置を指定するため入力が2入力となったり、といったケースもあって、中々問題も山積みだ、とのことでした。

PostLBSも楽しかったのですが、この日は同じ会場で、もう1つ嬉しい出来事がありました。
詳細は次のエントリで。

--- 追記 ---

たくぼさんのPostLBSレポート。

書きたいネタ（書くべきネタ含め）だらけなのに持ち帰り仕事山積みで書けず。
とりあえず今晩もうちょっと頑張ればこなせそうな感じなのでそろそろブログも書くか。

連休前、憂鬱感で脳が焼きついたような状況が慢性化し、手の痺れも肩の凝りも極限状態で鉛のよう。
手が動かないし何もする気がおきないので、仕事も進まない。
ほとんど何も判断できないので、チーム内に仕事の指示を出すこともままならない。
毎朝しおれた大根のような状況で会社に通っている状況だったが、ふと連休に入っていろんなところのうつ病診断チェックというのをやってみると、軒並み重症、入院が必要、ネット触ってる場合じゃねえぞ回線切って首つって氏ね病院行け！状態。
びっくりして、早速連休明け早々に精神科の予約を取って診てもらった。

受診してやはり多少のうつ状態にあるということで、トレドミンという薬を処方される。
とりあえず飲んでみると...飲んで数日のうちに、憂鬱感が著しく軽減。
全然普通に、楽に仕事ができるようになり、別に連休前に比べて仕事での問題が減ったわけではないのだが、別に問題なくこなせるようになった。
連休前はどんな問題も判断の先延ばし、先延ばしをしていたのだが、ごく普通にやれる問題からやれる範囲でこつこつと、仕事の交通整理ができるようになり、チーム内にも的確に（ただし当人連休前比）指示を出せるようになった。
治ったといっても波はあって時々鬱は襲ってくるけど、以前のように脳みそオーバーヒート状態にはならない。

何より嬉しいのは、手指・肩の痛み・痺れが軽減された事。
（1度しかやってないとはいえ）神経ブロックですらほとんど効かなかった痛みの大半が、すっとんだ。
もちろん治ったわけじゃなく、痛みはまだあるしやはりこれも波があるけど、明らかに軽くなってる。
それ以上に、痛みがあっても気にならなくなった。痛いね、でもそれがどうした？みたいな感じ。
痛みもリスク要因に加えた範囲で、やれる範囲でやる。という感じになった。
うつな精神状態になっていた時は、指が思うように動かない→ストレス、ゆううつ→ストレスでさらに筋肉硬直、神経絞扼→痛みが悪化、の悪循環状態だったんだと思う。
それが、うつ状態を溜め込まないよう抗うつ剤を投与され、循環が断ち切られた結果、症状が楽になったのだろう。
俺のように、不定愁訴に長い間悩まされ、落ち込んでいる人は、精神面から悪化している可能性もあるかもしれない。
精神科を受診してみるのも、よいかもしれない。

「うつ」かもしれない 死に至る病とどう闘うか

posted with amazlet on 06.05.21

磯部 潮
光文社 (2006/04/14)

Amazon.co.jp で詳細を見る

うつとはどういうものか、ということについても、上の本など読んで調べてみた。
これを読む限りの理解では、ネット上うつ診断では重症と出た私だが、どうも「うつ」自体はそれほど酷いものではなかったようだ。
重症ならば薬を飲んでもそんな1日やそこらで劇的に改善するはずがない。
考えるに、うつ判断には必ず含まれる「死んでしまいたいと思う」「将来に絶望している」「怠け者だと思われないか心配している」「自分は周囲に迷惑をかけている」等々といった項目、全部ＹＥＳだったから重症判定だったわけだが、上の本を読んで重症患者の人の事例を見る限り、私の「絶望」と重症患者の「絶望」は明らかに違う。 
重症患者は明らかに自分「自身」に絶望しているのに対し、私は自分の「体」に絶望していた。
死にたいのは？こんな体を持った苦痛から逃れたいから。将来に絶望しているのは？こんな体でこの先何十年、家庭を支えて生きていかないといけないという現実に。怠け者だと思われる原因は？精神的エネルギーの枯渇で動けない事よりむしろ、肉体的苦痛で動けないから。周囲に迷惑をかけていると思う理由は？以下同文。
そう思うに、私が重症うつにならずに済んだのは、このポンコツな「体」のおかげかもしれない。
こんな体でなければ違う人生もあったかもしれないが、もし同じ人生を歩んできてて「体が正常」であった場合、絶望の持って行き場がなくなり対象が自分となって重症化していたかもしれないが、「体」を持っていたから、「こんな体さえなければ」と責任を押し付ける先、精神的逃避先があったから、「自分自身」全体を全否定することから免れたのかもしれない。
そう思うと、散々悩まされてきたが、この体もさまさま、という気もしてくる。

ここたちが、広い彗星プロジェクトと、感じなどをNextBloggingしなかったよ
ねたちが、いい彗星プロジェクトをNextBloggingすればよかった？
広い感じや、大きい感じとか、大きい感じなど言ったよ
ネットで感じをNextBloggingしなかったよ
ここが、いい彗星プロジェクトなど言ったよ
大きい彗星プロジェクトなど言ったよ
と、ねねが考えてるみたい♪

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

書きなぐりの表現力ナシナシな上に考えながら膨らませ膨らませ書いたので、かなり誤読されてしまった悪寒。下手っぴ文章でスマソ。
後、ずっとブログで書いてきてると、一見さんの人も多いにも関わらずどうしても過去の主張は前提で判ってもらえているものとして書いてしまいがち。
やはりブログはフローのメディアなのだなあと実感。Wikiも作っているのだから、ストックを貯めていかなければ...。

浅倉さんのTB：SNSとパソ通の共通性ねぇ

個人的にはパソ通とSNSはあんまり似てる気がしません。
どちらかというと2chのほうが似てると思ってます。

パソコン通信の体験者に「どうですか？」と聞いた上に、私自身類似性として「趣味・話題を共通にするコミュニティの形成と盛り上がり」とか書いたので、そういう方面の類似性として受け取られてしまったものと思います。
私自身、パソコン通信上のコミュニケーション形態をインターネット上でもっとも引き継いでいるであろうのは、MLやBBSといった形態であろうという事は認識しております。

私が指摘したかった類似性は、まず社会現象としては、ネットを通じたコミュニケーションという新しい流れがブームを呼んだパソコン通信と、その継承としてのインターネット上のML/BBS等がコモディティ化してしまい目新しさがなくなった際に、より濃密なコミュニケーションの取れる場としてSNSが現れたので、また新しい流れとしてブームになったという、その普及ストーリーを問題にしているのであって、単純にコミュニケーション形態が似ているというような話であったのならば、同じものの2番煎じが流行るはずもありません。
その辺は、過去のエントリで、SNSの流行には全く新しい形態という側面と歴史の繰り返しという側面の2面性があることは指摘しています。

とりあえずブームの間はいい。でも、それが普及しコモディティ化してくるにつれ、サービスとしてNiceからMustに移る必要が生じてくるにつれ、盛り上がり時には見えてなかった技術的な不便や限界が見えてくる、その類似性が私の指摘したいもう一つの類似性です。そういう問題点の一つにクローズド性があるわけなのですが、

そもそもパソ通はクローズドじゃなかったし。
いや、そういうトコもあったとは思うけど、基本的には「誰でも参加可能」だったと思う。
規模が小さいために外からは「閉鎖的」に見えたかもしれないけれど、それは望んだものではなかったように記憶しています。

これはクローズドの意味を誤読されてしまいました。Mixiが招待制、ということを指してのクローズドではありません。
各サービスが完全独立で、相互接続性がない事を指してのクローズド、であり、それが似ているという趣旨です。
例えば、私はパソコン通信経験がないので判らないのですが、

• 友人とお互いがパソコン通信を加入していたにも関わらず、参加しているサービスが異なるために連絡が取れない、ということはなかったですか？
• Niftyのフォーラムで議論が白熱して、そんな議論はPC-VANのSIGではとっくに議論が尽くされているのに、ポインタを引用できない事にもどかしさを感じた事はないですか？
• そういう連絡を取ったり共通の議論の場に誘うために、友人に同じサービスに加入してくれ、というのに抵抗はなかったですか？
• 逆にそのように誘われたら、NiftyやPC-VANといった大手から弱小草の根局まで、どこでも全部入ってやろう、そしてそれぞれで濃密でアクティブな人間関係を維持してやろう、というパワーがありましたか？

今のSNSで、私は相互接続性のなさのために実際こういうストレスを感じています。
位置情報を盛り込んだSNSのここまる、ポジタル、特にポジタルは知人がやっていることもあって応援したいし、活用したい。
でも結局、SNSでどんな機能よりも「最大のコンテンツ」であるところの「知人ネットワーク」を他サービスに移せないので、他のSNSにどんな面白い機能があっても、結局Mixiに回帰してしまう。
また、私は実際に、ポジタルを盛り上げるために私のマイミクシィ全員にポジタルへの招待状を送りました、が、入ったのはそのうちの数人だけ。
もちろん、アクティブ...というよりは相当暇な人なんだと思いますが、たくさんのSNSに加盟して、それぞれで活動的にやってる人もいますが、そんな人が世の中に何人います？
たくさんのSNSに加入していても、それぞれの中でこまめにプロフィールをメンテし、近況を伝え、交友関係をメンテしなければ、その手の回らないSNSの中ではその人は無口でリアクションもなくて面白くない奴、と同じ。
そうならないために、自分のブログや他のSNSで書いた日記を、わざわざ別のSNSにコピーして各SNSに同じ日記をいちいち挙げなおしている人もいる。
馬鹿馬鹿しくないですか？
ソーシャル...人と人との結びつきを支援するツールと言う以上、本来人がノードであってシステムがハブとなるべきであるのに、実際には相互接続できないシステム境界で人の結びつきが分断され、人がハブになって、必死に個々のシステムというノード内でのプレゼンスを維持するような状況になってませんか？

パソコン通信も個々が独立したシステム境界を持ちそこでコミュニケーションが寸断されていたために、インターネットという境界のないでっかいパソコン通信のようなものに押し流されたのではないかと思っています。
SNSも同じようにシステム境界がなしにSNSと同じ事ができるインフラが整えば、それに押し流されていくのではと考えています。

だってこれらは別に「パソ通の良い点」じゃないもの。　
僕がインターネットに比べてパソ通が圧倒的に良かったと思うのは「リアクションの良さ」や「自動巡回のしやすさ」です。

私が想像したよい点と、浅倉さんの実体験したよい点が違っていても、全然問題ないのです。
主眼は、そういう明らかにインターネットよりよい点を持っていてすら、パソコン通信はインターネットに押し流された、という事実なのですから。

また、「リアクションのよさ」を招く原因が何か、というのははっきり断言できず議論の余地があると思いますが、個人的な直感としては、不特定多数の目に晒される可能性が少なく、仲間内だけでまったりとした交流ができる故のものではないかと思えます。
どこぞの匿名野郎に荒らされ炎上する可能性が少ないので、比較的安心して書き込める、これが強いと思っています。
で、その実現を支えている技術的要素は何か、と言えば、以前も論じたとおり、個人を特定するログイン（認証）であり、その認証された個人を元に情報の流通範囲をコントロールする（承認）機構でしょう。
つまりは、しっかりしたオープンな分散認証機構（と、その前提の上に作られた承認機構）さえ準備されていれば、そんじょそこらのApacheサーバから配信されるコンテンツでさえ、仲間うちだけに見えてマターリと交流でき、仲間うちでない奴には存在すら判らない、といった情報流通コントロールは可能なわけです。
となると、パソコン通信に対しインターネットが「システム境界のないパソコン通信」として置き換わっていったように、SNSに対してオープンな分散認証基盤も「システム境界のないSNS」として置き換わっていくように感じるのです。

浅倉さんのTBへのリアクションが長くなりましたが、今度はひゅーさんのコメントに対して。

インターネットはパソ通を押し流したりしてません。吸収したとは言えるでしょうね。
初期のMLはパソ通の雰囲気でした。
コンピュータによるコミュニケーションの本質はなんら変化していません。

コミュニケーションの本質、という点では全く同感です。
私も、浅倉さんの書いたような「よかった点」はあったにせよ、またいろいろできる事は増えましたが、基本的にパソ通の機能、人々がそこに求めていたものはインターネットに吸収され引き継がれていると思います。
SNSも同様で、オープンな認証基盤ができたからといって、その上で構築される「流通をコントロールされた情報」でのコミュニケーションに求められるものは、今のSNSに求められるものと同等のものを人は求めていくでしょう。
でも、引き継がれる精神はその通りなのですが、一方でビジネス的、システム的な側面でみた場合のパソコン通信は、インターネットの出現によって壊滅させられています。
SNSも同様に、オープン化への準備ができなければ、既存の相互接続性のないSNSシステムとそのビジネスは壊滅するのではないか、というのが私の考えなのです。

表記の件、非常によくまとまっている記事を見つけたので紹介。

［nekodemo］地図情報サービスの明日はどっちだ──その1

［nekodemo］地図情報サービスの明日はどっちだ──その2

［nekodemo］地図情報サービスの明日はどっちだ──その3

その3の最後で「その4に続くかも」とあるけどその4はあるのかな？
会社のタイムアウトしまくるくそ遅いネットワークでは辿りきれず。

もしあったらTBキボンヌ。

別に意味があったわけではなく、何となく思いついたから書いてみただけのこのエントリに、ひゅーさんから思わぬおもしろいコメントいただきました。

＞Mixi Premiumにしたら負けというのはないのだろうか。

昔、ascii-net有料化に賛成したら負けだと思い反対運動をした。結局有料化されたのでniftyに移った。
 しかし、見事に青天井なniftyに負けますた。

現在のクローズドなSNSは昔のパソコン通信的位置付けだ、という持論を持つ身としては、SNSの有料化へのつぶやきにパソコン通信時代の有料化の話で返されたのが何となくおもしろく思えまして。
というか、偉そうな持論持ちつつ、実は私のネット体験はインターネットからで、パソコン通信自体は知らなかったりするわけなのですが（とは言っても、初期のインターネット時代に知り合った連中はパソコン通信やってたのでフォーラムの熱さとかは聞いて知ってるし、有名フォーラムのやり取りが書籍化されたようなのも持ってたし、あと一応一時期、インターネット側からパソ通内コンテンツが見れるニフティ会員だったりもしましたが）。

今のSNSの盛り上がり（というか、既に沈静化しつつあるような気もしないでもないが）って、私はパソコン通信との類似性を感じてるんですが、コアにパソコン通信を使われていた？立場からみて、どんな印象なんでしょうかね？
パソコン通信に対するインターネットのように、クローズドに対してオープンなSNSが出てくれば、廃れていくような感じがしませんか？

というか、パソコン通信との類似性云々言いながらパソコン通信の歴史をしっかりは調べてなかったので、ちょっと自分なりに調べてみました。
別にWikipediaだけで調べたわけじゃないっすが、一応Wikipediaのリンクを貼っておきます。

パソコン通信 : Wikipedia

うーん...草の根弱小サービスの乱立と大手サービスの寡占、趣味・話題を共通にするコミュニティの形成と盛り上がり、サービス間の相互接続性のなさ...やっぱりSNSと似ている気がするんですが...。
自分自身が批判し戒めたはずの、「似た要素だけを取り上げて自分の見たい見方をしてる」だけかもしれませんが...。

加入者数も調べてみました。

会員数１万人以上のパソコン通信ネット局　会員数推移　91年7月～97年3月

一部業者がISPに移ってからのデータも入っているので、後の方は考慮対象にできないと思いますが、95年段階でも大手だと100万人は加盟者がいたのには驚きました。
当時のパソコン普及度、そして接続の技術的ハードルの高さを考えると、Mixiどころの盛り上がりじゃなかったんじゃないかと言う気がします。
といっても調べてみないと判らないですが、変化グラフの比較は難しいので、スナップショットで。

1993年10月、パソコン通信加入者数延べ200万人
2005年3月、SNS加入者数延べ111万人
1993年3月、対世帯パソコン普及率11.9%、2005年5月、対世帯私的利用インターネット普及率44.4%
全国世帯数、1995年4390万世帯、2005年(推定)4904万世帯(推定)

分母に用いるのはそれぞれのサービスの前提インフラであるべきだろうということで、パソコン通信の場合はパソコン普及率、SNSの場合は私的利用インターネット普及率としました。
分子が加入者数で分母が世帯と異なるので真っ当な比較ではないのですが、パソコン通信の普及率が93年前後で全パソコン所有者中38%、SNSの普及率は95年で全インターネット加入者中5%程度。
パソコン通信時代のアカウントは世帯に一つといったところもあったであろうのに対し、SNSはほぼ間違いなく個人アカウントであることを考えると、その差はもっと広がると思います。

言いたいのは、SNSを遥かにしのぐ、それ程隆盛を誇ったパソコン通信ですら、インターネットの前には消え去ったということ。
パソコン通信が消える時にだって、パソコン通信の方のよい点---コミュニティの質の高さ、匿名性の低さ、あれやこれや---SNSと似ていますね---を挙げて、消えるはずがないとか、消えそうになっても抵抗する人はいたわけです、でも消えてしまった。
いずれSNSも、クローズドなものは、オープンな認証インフラの登場・普及と共に廃れていくだろうと考えています。

別に、パソコン通信だってインターネットが広まるまでの間商売になったわけなのだから、今クローズドなSNSやっている人達を揶揄しているわけではないのです。
でも、2年か3年かどのくらい持つか判りませんが、いずれ崩れるのは多分間違いない事が判っているにも関わらず（私の脳内だけかもしれませんが）、それならそれでその動きを自分達で起こしてコントロールしたらいいのに、ということが言いたいわけです。
オープンな認証インフラの概念を唱えている人はもうかなりの人がいますが、当のクローズドSNSにコミットしているような人からはそういう話がほとんど出てこない。
それどころか、mixiはWeb2.0ではないらしいとかまで言われてるようなアレで。
SNSを運営している人達は、パソコン通信の歴史に目を向ければ、いろいろ学べるかもしれません（歴史だけでなく、コミュニティーの質の維持方法とか、運営的にもいろいろ学べるはずです）。
逆に、数年後にMixiとかにとって代わろうと狙っているところは、今のうちに次のTCP/IPとも言えるオープンな認証インフラにコミットしとくといいかもしれません。

とはいえ、自分で書いててちょっと弱いのは、インターネットはパソコン通信とは全然別のところで、学術機関とかを結ぶネットワークとして発達して成長し、ある程度広まったところで、便利だという事で一般へも普及の波が広がりパソコン通信を押し流した、という経路があったわけです。
でも、オープン認証インフラはその、一般に広まる前に別の部分で広まって、便利さを証明するといった、普及のストーリーがいまいち思い描けない。
あれば便利なのは判っている（というよりない今が不便、相互接続性のなさ等で）けど、極端な話、Mixiがさらに強大になって、GREEも潰れLivedoorフレパも潰れて唯一のSNSになったとしたら、相互接続性もクソも唯一なのだから困る事もなく、事実上、オープン認証インフラが出てくれないと困ると言っていた問題点の大半は解決されてしまうわけです。
そっちの方があり得るシナリオかもしれない。望ましいとは思えないけど。

うーん、ひゅーさんのコメントにちょこっと反応するだけのつもりが、考えながら書いてたらまたどんどん広がってしまった...。

米国のMicrosoftが、リモートセンシングの会社であるVexcelを買収して地図検索機能を強化するらしい。

GoogleがKeyhole社を買収したのとはスケールが違うが、衛星写真処理技術を有する企業は従来は専門性の高いニッチの分野であり、企業買収も業界内の統合などが動機であったはずだ。
それが、いつの間にかあのMicrosoftのようなITのメインストリームにいる企業の買い付け対象となっているとは、、、

Vexcel社だけじゃないっすね。
GeoTango社なんかもやっぱりMicrosoft社に買収されたりしてます。
Microsoftの関わらないものを含めると、もっといろいろ動いているみたいですね。
うちもGIS系のシステム作ったりしてるので（私はGIS設計には参画してないですが涙涙涙涙涙涙涙涙）、買収の影響で購入するはずだったソフトが値段が跳ね上がったり発売停止になったりとおおわらわです。

それだけ、地理情報の重要さへの関心が高まってきたってことですかね。ようやく。
これもGoogle Maps/Earthショックの効果なのかな。

お世話になっているオークニー社のカスタマー宛メールが届いて、IPAX2006に出展します！という内容だったのだけれど、その中に面白い記事が！

2006年5月17-19日に東京ビッグサイトで開催されるIPAX2006（ビジネスショウTOKTO2006 同時開催）に出展します。

オークニーブースでは、「オープンソースでここまでできるWebマッピング」をキーワードにした、オープンソースWebマッピングのソリューションを展示いたします。
MapServer、PostGIS、Ka-Map などのオープンソースツールを活用した、最近のさまざまなシステムの導入事例のご紹介はもちろん、
「PostLBS」と名付けた、ルート探索とアドレスマッチングの新たなオープンソースプロジェクトや、
「GISデータネットワーク」というオープンプラットフォームであるWMSを活用した、GISユーザ向け地図データ配信の新サービスのご紹介も行います。

ぜひ弊社ブース（No.11）にお越しください。

内々にそういうのを作っているという話は聞いていましたが、ついに発表されるようです。
「Post...」と付いているところからみて、PostGIS同様PostgreSQLの拡張でしょうか（そこまでは詳しく聞いてない）。
詳細は判りませんが、今までオープンソースではなかったソリューションなわけなので、いろいろ面白い事が考えられそう。
興味のある人は、招待券はこちらからもらえるようなので、IPAXに行って詳細聞いてみられてはどうでしょうか。
ちなみに私は...多分行けそうにない...ので、詳細が判ったらどなたかレポート＆トラックバック超キボンヌ。
　※18日午後都内客先出張なので、午前半休とって行こうかな...でもそうすると、連休はあったわ通院はするわで、今月休み過ぎ...。

で、詳細は判らないものの、利用法について考えてみる。
単独GISシステムの作成を考えた場合、これは画期的。これまでになかったソリューションで新しい機能が考えられるわけなので。
しかし、Web2.0的というか、そういうギーク・ハッカー連中に訴求するような用法としては、結局以前の記事で述べたような

Google Mapsで誰もが使える地図が手に入った次代の、MapServerの役割は？

みたいなあたりが問題になる。ルート探索もアドレスマッチングも、対象データを自前で持っていなければどうにもこうにも、なわけなので。
その意味ではMapServerよりも厳しい？MapServerは地図がなくても、ユーザにとってのPOI（Point of Interesting）を格納しWFSで吐き出して、

AJAXベースでGoogle Mapsと重ね合わせられるWFSクライアント実装とかできたら

そのデータ配信手段にもできるけど、ルート探索やアドレスマッチングは自前データがなければどうにもならないので。
いずれGoogle Mapsもルート探索やアドレスマッチングAPIは出してくるであろうので、それと競合するのにマップが手に入らないとアレというのは、かなり弱い。

そこで考えを進めてみると、万人にとって標準的なルート探索やアドレスマッチングでは、Googleなんかが出してくるWebサービスに敵う事はないだろうと。
でも、ルート探索やアドレスマッチングは、果たして万人にとって同じものが要求されるのか？という考えがある。
例えば、単にノード間の道程を足し合わせただけの最短ルートというだけでなく、人の通れないところを排除し、人なら通れるところをノードとして加えた独自ベクトルマップを準備しての歩行者にとっての最適ルート提供や、同様の発想で障害者向けのマップを用意しての障害者向けルート探索提供とか。
あえて抜け道の探索の重み付けを上げる抜け道探索なんかも考えられる。
アドレスマッチングに関してはちょっと難しいところがあるが、例えば学術用途なんかで、旧国名や旧藩名、旧地名等をデータとして持ち、それをベースにマッチングして地理座標に変換するサービスなんかもありだろう。
その全てが、クエリ結果がPostGISの地物オブジェクトとして返ってくるとすれば、WFS経由で外部公開でき、さらにGoogle Mapsにも重ね合わせられることにもなる（Google MapsのWFSクライアントができたら、だけど。今のところまだないみたい？）。

そう考えると、種々の周辺条件が整う必要があるけど、なかなか面白いマッシュアップのベースとなる可能性を秘めているのではないかと。
もちろん、重み付け経路探索や旧国名みたいに特殊な地名まで扱えるように現時点でのPostLBSがなっているかは判らないけど、そこはそれ、「オープンソース」プロジェクトなんだから、オークニーがそれを実装しなくても実装したい人が実装していけばいいのだから。
なかなか楽しみなプロジェクトです。

こないだ、ねねが
「韓国内の世界プロジェクトには朝鮮半島が意図的に大きく描かれている」って(BlogPet)
って言ってたよ。

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

古いエントリにコメントをいただきました。

北極南極でつかまるか、赤道周りをぐーるぐるのコメント

常に東や西を目指して進むと、北にも南にも向かわないわけだから、「最初から赤道と平行に進む」が正しいはず。
ちなみに「常に北東に進む」を実践した場合、「東」は北極点を中心とした回転移動、

よく勘違いされますが、これは明確に違います。
よくある地図がメルカトル図法や正距円筒図法で描かれる事が多く、緯線と経線が直角に交わる形で描かれているので、多くの人が緯線に沿った方向がその場からの東西、すなわち日本から見れば東は合衆国、西はヨーロッパのように思いがちです。

確かに南北は、極を除くあらゆる場所でその場の経線方向と一致します。
ですが、東西の定義は、その場での南北方向と直角に交わる方向です。
すなわち、球面（地球は球面でなく楕円体面だという突っ込みはさておき）上で直角に交わるというと、一方の経線は地球の中心を通過する面と地球表面の交線ですから、それと直角に交わる線も当然、地球中心とその場所を含む面と球面との交線となります。
緯線は地球の中心を通るどころか、極を結ぶ線と直交する平面による地球の輪切りですから、赤道上以外ではその場の東西を表す線にはなりえません。
正しい東西の方向は、その場所と、地球の中心を挟んで地球の反対側の地点（対蹠点と呼びます）を結ぶ線のうち、その場の経線と直角に交わる線の方向となります。
よって、東京から東の方向にずっと進んでいくと、行き着くのは南米ブラジル沖の海上ということになります（ただしもちろん、出発点から東の方向にコースを定め、以後は盲目的にまっすぐ進んだ場合に限ります。進むごとにその場その場での東の方向に修正していくと、先のエントリで書いたとおり、永遠に赤道を越える事はできません。）。

これの証拠といえるのが、この正距方位図法による地図です。
この地図の特徴は、地図の中心から見た地図上のあらゆる地点への距離と方位が正しくなる図法なのですが、この図で判るとおり、地図の中心（＝日本）から見て、真東の方向には南米があり、真西の方角にはインドや南アフリカがある、ということが判ります。

子供を寝かせつける時によく狂言の稽古をつけてやるのだが、覚える前に大抵寝てしまう。
今日もなかなか覚えられなくて怒られるのを、眠りの世界に入って逃げようとするので「わかった、じゃあ明日のボウケンジャーショー連れていかない。その時間で練習しよう。」と言うと、泣き叫んで必死で今練習すると言う。
その泣き喚きぶりがあまりにすごかったので、家内まで何事かととんでくる始末。

あとで家内に、厳しすぎかな？と聞いてみたら、家内曰く、
「いやー、高い月謝払ってるんだし、身につかせなきゃいけないからいいんじゃないの？むしろ、そのためにも、GWで家に長い間いるんだったら、滅多にないことなんだしちゃんと稽古してやった方がいいんじゃないかと思う。明日は約束したから仕方ないんだったら、日曜日の外出は中止にして、狂言の稽古してやったら？」
日曜日の外出は、横浜の人体の不思議展に行く予定だったんですが、正直、息子より俺が行きたかったんですけど...。

いらんこと言って蛇を出してしもた...人体の不思議展の代わりにボウケンジャーショーですか...とほほ。

Mixi Premiumにしたら負けというのはないのだろうか。

というかそもそもMixi入ったら負けなのか。

別にPremiumにしてる人を揶揄してるわけではない。

perl - 勝手に添削 - Text::MeCab by DMAKI -404 Blog Not Found- のコメント

kokogiko: インストール時にPP版かXS版かを切り替えるMakefileの書き方って、何かGood Sampleはないでしょうか？

daisuke: DateTime / Params::Validateあたりは結構よろしいかと＞XS/PPきりかえ

という情報をいただきましたので、ちょっとParams::Validateを覗いてみると、なんとなく判った気分なので後は実際に試してみてやろうかと、久しぶりにLocation::GeoToolに手を入れようかなと考えてたりするアレですが、

どうせなら、入出力のフォーマットをロジックを使わずにフォーマット文字列を使って食べさせてやれば自由に設定できるようにしてやりたいなと思うのです。

今でもロジックを食わせてやれば独自フォーマット対応にはなっているのですが、ロジックではなくフォーマットの定義だけで、その定義に従ったデータをパースして別フォーマットに変換できたり、逆に他のフォーマットから定義に従ったフォーマットに変換して出力したり。
そのようなフォーマット定義のパーサとフォーマッタを簡単に導入できるようなCPANモジュールってないでしょうか。

できれば、同じフォーマット定義を使いながらもパーサは一般的に、フォーマッタは厳密に、つまり、例えばmapionの経緯度フォーマットを例に取ると、135/3/4.29という表記も、135/03/04.290という表記もありうる訳ですが、

• パースする際はどちらでも読み込める。
• フォーマットする際は、format_mapionメソッドに引数を与えてやったりすることで、どちらの表記でもユーザが選択できるようにする。

といったことに対応しているとベストなのですが。

母親でも「使える」から一歩進んで、自分の母親に「使いたい」と思わせるProductを作りたいというmena。

母親のなぜ、ブログしないかという３つの理由。

• 話すことなんかない
• 書いたものは見られたくはない
• まして、ブログに割ける時間なんてない

そんな自分の母親に、使いたいと思わせる製品を開発する。
そのためのcometプロジェクト。

うわー、ええ話やなー。
まさにその通りやと思う。 

最近の話題かと思いきや、去年の9月の話ですか。全然知らなかった。
今ググってみた＆はてブチェックしてみたけど、このエントリも彗星プロジェクトも、　「そんな母親」世代が巨大な社会勢力となっているはずのこの日本では全然話題になってないのね。
なんかおかしいよなあ。
マジでいちいち黒船が必要なのかね。

かなりSixApartが好きになってきたが、日本のSixApartには振られたので、直接あっちに行ってみるかなあ。ろくに英語もしゃべれんけど。家内もアメリカ行きてー!とか言ってるし。
かなり無謀とは思うが、Google？とりあえず行っちゃえ！やってみにゃ判らんて、という友人が複数人いて「ねねさんも受けてみたら？通るんじゃないの？」とか言われてるのに比べれば（さすがにそれを真に受けるほど自己分析できない者ではない）、まだ無謀度は低いかなという気がする。

ついでながら、上記エントリを見つけた元エントリは、Refererを辿っての

OpenPNEとAffelioFarm -馬鍋かをり(眞鍋じゃないから)-

なんですが、この人もオープンSNS系のプロジェクトをやられてるようです。

分散型コミュニティ: Arpeggio

おもろげなのでチェックしとこ。

きのう、世界も意図したかも。
ねねと意図した？

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

手・肩の痛み・痺れが耐えられん。
連休3日、子供連れて遊びに出た以外はほとんど寝てても、一向に改善する様子がない。
仕方がないので、一度神経ブロック注射というのをしてもらおうと、NTT関東病院のペインクリニック科に飛び込んでみた。

とりあえず問診・レントゲンで首の骨の状況を確認し、詳細はMRI撮ってみないと判らないが頚椎変型症か頚椎ヘルニアからきているものだろうとのこと。
早速、神経ブロック注射をしてもらうことになった。
痛むのは両手だけど、今日はとりあえず酷い方の右からすることになった。

やってもらったのは、星状神経節ブロックという神経ブロックでも軽い方のもの。
首の右側全面、ちょうど喉仏と頚動脈の間くらいの場所を指でつよく押され、そこに針をさし麻酔薬を注入。
するとだんだんそこを中心に麻痺が広がってきて、20分もすると右耳から右頬、右顎、右首から気道・食道・鼻の右半分まで麻痺して、息がしにくくなる。
というよりは、気道に感覚がなくて息が通ってる実感がしないので、そのせいもあって息苦しい感じ。
血行がよくなるので、右目も充血状態に。
ちょうど、歯医者で受ける麻酔で唇とか無感覚状態になるけど、あれが顔の右半分全体に広がった親玉みたいな感じ。

30分ほど休んで、もういいですよと言われ起きてみると、喉に感覚がないので唾がうまく飲み込めずむせるむせる。
しゃべるのもぎこちなく、声がかすれてうまく出せない。
それは薬がよく効いている証拠です、2時間もすれば元に戻りますよ、とのことだったが、それは改善効果もそのくらいしか続かないということなのかな？
とにかくうまく物が飲み込んだり出来ないので、麻痺が取れるまでは誤嚥するかもしれないので物を飲んだり食べたりするな、と注意を受けて、無罪放免された。

で、期待の結果はというと...ほとんど効いてない。
まだ麻痺が残っている間は、肩甲骨の裏から痛かった右肩の酷い痛みと肩こりはなくなった。
右手の指に関しても、一時的に症状は軽減してて、文字を打つのにストレスなく、とはいかないけれど、痛みを紛らすためにいつも指や掌に貼っている湿布を貼ると、気にならないレベルにはなっていた。
でも指に関してはリアルタイムでいつもの感覚にどんどん戻っていって、このエントリ書いている間にもう普段の湿布を貼ってても痛みが耐え難い状況に逆戻り。
実際このエントリも途中で休みを入れつつ打っている状況。
肩もまだ普段よりはマシな状況だが、明らかに徐々に戻りつつある。
やっぱり効果は一時的な感じ。

まあ症状が出てきて1年くらいの肩部の症状はともかく、手指は10年来悩まされてきてるわけなので、1回の治療できれいさっぱり消える方がおかしいと言えばおかしいのだが。
この後これを繰り返していけば徐々に軽減していくのか、或いはレントゲンを見ながらの麻酔注入等もっと強い治療法に移していかないと駄目なのか。
ちょっと先行き不透明だが、これまでやってきた首牽引・鍼・筋弛緩剤服用・整体といった方法では直ってこなかったので、効果があるかどうかこの療法もしばらく続けてみようと思う。
ああ、前途長いな...。

小学生の何割かが天動説と勘違いしている。というのをニュースで小学生の知識レベルや文部科学省の至らなさを笑ったり嘆いたりしている人ほど、哀れな感じがする今日この頃である。

こんなエントリを書いた直後にこんなの読むと自分が嫌になるな。

ここで取り上げた、Yadisの識別子正規化の話。
MLでもすげえでっかいスレッドになっちゃって、全然追えていません。
今のところ、正規化派が優勢なのか。
しかし、非正規化派が、正規化必須への対応について各コンシューマと各識別サーバ間で温度差が生じた場合のセキュリティホールの存在を指摘したりと、予断を許さない。
もう英語での議論についていけないので、どっちゃでも決まって仕様に載った方で実装するから、早く決めてくれーという感じです。

実際この問題の難しいところは、

1. 単純に「正規化した際のURLが同じ=同じIDとして扱う」レベルの大雑把な仕様導入では、セキュリティホールの元となる。
   正規化するならするで、コンシューマ側と識別サーバ側で、識別シーケンスのどこで正規化されて、どの手順以降は正規化したURLのみで遷移すると規定する（或いは、全ての遷移におけるURI指定の属性について、コンシューマ側・識別サーバ側双方で、正規化を実行すると規定する）、また、識別URIは正規化されたものしか発行してはならない、といった細かい仕様上の縛りを「MUST」でかけておかないと、セキュリティホールとなる。
2. が、上記のようにコンシューマ側と識別サーバ側で歩調を揃えなければならないにも関わらず、Yadisはコンシューマ側のみの仕様であること。
   コンシューマ側が、与えられた識別URIを元に、識別サーバとどのようなプロトコルに則った遷移をするかを得るための仕様であって、実際の識別サーバとのやり取りの仕様は、OpenIDやLIDといった別仕様に則って処理される。
   だから、Yadis上でだけ正規化云々言ってても駄目で、セキュリティホールを生じさせないような対応をしようと思うと、OpenIDの仕様に遡って変更をかけると共に、正規化に対応していないOpenIDのバージョンにおいてはYadis非対応とさせる、等の対策が必要となる。
   実際、URI正規化問題の仕様への取り込みは、LIDとOpenIDで差がある...LIDは正規化を仕様に取り込んでいるようだけど（自分の目では未確認、又聞き）、OpenIDでは特に規定されていない（たいていの実装は正規化せずにByte-To-Byteの比較で行われている模様）。
   よって、そのままYadis側だけ正規化しても、OpenIDとの間でセキュリティホールが発生する。
   やるなら、OpenID側にも正規化対応の仕様を盛り込んだバージョン改定をし（幸い、OpenIDの主要メンバーはYadisにも参加しているので、対応は可能）、かつ、今後Yadisに参加する独自分散識別プロトコルは、識別子として正規化されたURIを用いるべし、とYadis仕様に盛り込む必要がある。

といったところかなと。

いずれにせよ早く決めてもらいたいものです。

--- 追記 ---

個人的にどっちかというと入力を正規化するよりByte-To-Byteな一致の方に同調したいのは、仕様的にそっちの方が安全な方向に倒れるから。
正規化を導入すると、実装の温度差が生じる事によるセキュリティホールを生まないように安全性を保証するには、単に同一IDとして扱うというポリシーだけではなく、どのタイミングで正規化を行うか、或いは全てのプロセスで正規化を通過させるか、ということを、MUSTで仕様に組み込まなければならなくなる。
それもYadis単体で話が済めばいいのだけれど、OpenIDなんかの他仕様も巻き込んだ形で。
私が強調したいヘビースペックはこういう仕様としての重さ、ということで、さすがにURI正規化がそこまでリソースを食うとかの話ではなく。
そういえば、MLでは識別IDにクエリストリングが含まれていた場合はどうするのよ、みたいな議論もあったな（http://example.com?mode=id&user=kokogikoとhttp://example.com?user=kokogiko&mode=idを一緒とみなすか否か、みたいな話かな）。

もちろんByte-To-Byteで、一意なURI文字列しか識別子として認めないとした上で、その一意な識別子を発行するためのリファレンスとして、既に正規化されているURIしか識別子として発行してはいけない、といった制限をMUSTで盛り込むのはありかと思う。
しかしそれと、正規化されていない同一URI表現を、勝手に正規化して同一IDとして認めるかどうかは別の話---なんでわざわざ仕様を膨らませてまで安全でない方向に仕様を倒す必要があるのか、と思う。
同じ仕様を膨らませるのならばむしろ、非正規化URIを勝手に正規化して同一視するのではなく、正規化されていないURIについては入力されてもそもそも識別子として認めず例外を吐いて遷移しない、という形でSHOULDくらいで盛り込む方が、より安全な方向に倒れるのでまだ納得できる。

そもそも、Webサービスとして実装する分散識別システム上で、分散した識別サーバを得るためのプロトコルを実現するための都合上、識別子としてHTTPのURIが使われているだけで、別にプロトコルさえ実現できるならば識別子としてはメールアドレスでもなんでもよかった（OpenIDだったかYadisだったかの初期議論でも、メールアドレスをIDとする案はなかったものの、メールアドレスのようなアカウント＋識別サーバ、の独自表記を識別子として使う案はあった）。
のだから、別にたまたま考え方を一部借りているけどHTTPという別プロトコルの上での定義で同じものを表すからといって、識別子としての扱いでも同一視しなければいけないという必要性はさらさらないわけ。
こちらの要件で必要なのは識別子なのだから、識別子らしく一意な表現で表記されて、かつその表記を用いて識別プロトコルの肝である識別サーバの情報が取得できる、という要件さえ満たしていればそれでよいのであって、たまたま乗っけさせてもらってるHTTPというプロトコル上で同じものを表すURIだからといって、それをこっちでも同一識別子と考える必要は全くない。
ただし、先にも書いたけど、同じ表現がいくつもある中で、何を識別子として選ぶか、という目安としては、正規化された表現を選ぶ、という縛りはあってもいいかもしれない。

個人的な意見としては、上のように考えてる。