無所属のＩＴレスラー【ストロング弾】
『おい！、つばくろ！！ヤオやってんじゃねーぞ。悲しいぞ、タブをスペースにしろ、このやろう！』

をもろいwww

この辺のみたいに、自動生成化はできないものか。

楽天カードが新しくなるらしい。
これまでの三井住友カードとの提携楽天カードは、今後使ってもポイントがつかなくなるらしい。

楽天ポイントを得るためだけにカード作ったようなものなので、乗り換えざるを得ない。
正直、ウザい。
元カードから引き落とされるようにしていたサービスとか、軒並み登録を変えないといけない。
でもまあ、今後買い物してもポイントが付かなくなるのはもっと痛いし、新規登録すればまた2000ポイントがつくので手間賃代わりにはなるかということで、変更を申し込んだ。

切替案内のメールが届いてたのだけど、それによると移行することによる新特典は...って、ちょwwおまwww
しまったああああああ!!!今読み返して気付いたけど、切替案内上のメールから切り替え手続きしていれば、特別に3000ポイント入ったのか!!!
激カナシス。
というわけで、嬉しそうに上にアフィリエイトリンクなんぞ貼ってますが、既に旧カード会員の方は上のリンクから切替などしないように。
自分への切替案内メールを探しましょう(涙)。

さて気を取り直して楽天カードの特典を紹介すると、これまでの

特典1：楽天市場でのお買い物なら、いつでもどこでもポイント2倍
特典2：入会金・年会費永年無料
特典3：VISAが使えるお店ならどこでもポイントが1％貯まる

の他に、新たに下の4特典がつくらしい。

新サービス1 ：ネット不正利用補償制度でカード不正利用は補償！
新サービス2 ：楽天市場内でのご利用で商品未着時ご請求金額を取消します！
新サービス3 ：カード利用通知お知らせメールで不正利用も早期発見！
新サービス4 ：海外旅行傷害保険も付与され、海外旅行も安心！

新特典はポイント付与とかよりも安心度充実という感じか。
まあ、被害に合わないに越したことはないが、カードの被害に合えばダメージは甚大だから、それに対する防御がついたことは嬉しいな。

韓国内の世界地図には朝鮮半島が意図的に大きく描かれていると聞いたことがあります。

んで挙げられてる地図がこれとかこれとか、「同じ会社の地図でしょうか？」とか素で話してるんだけど。
これって釣り？俺、釣りに引っ掛かった？

18世紀とか19世紀とかのフランスの古地図採ってきて何話してんの？
日本人の普通の知性ってここまで下がってるの？
「ゆとり教育の賜物」とかってヤツ？
1枚目、思いっきりキャプションに「18世紀、パリ」と書いてあるの、せめて翻訳サービスに通して何が書いてあるのか試そうと思わなかった？
ちなみに18世紀と言えば、その頃の日本と朝鮮は将軍が変わる度に朝鮮が通信使送ってきてた友好国の時代。
2枚目、タイトルコピペって写して（画像からコピペはできん罠）ググってみれば、すぐ正体くらい出てくるだろ？
というか、韓国が作ったんなら「MER DU JAPON（日本海）」とか書かんだろwwwwww。

そんなもの引っ張ってきていいんなら、日本だって負けてはいないぞ。
なんだこの形は。日本にはろくにGPSもないのか。
正体はこれ。

おまけにここの韓国や中国の地図上での朝鮮半島見て、「北朝鮮が無視されてますね」とか言ってて、激ワロス。
「韓国」も「北朝鮮」も立場は互いが朝鮮半島の正統政府であって、それを争ったのが朝鮮戦争。
今は戦ってないがそれは停戦状態であって朝鮮半島は未だ終戦してないから、基本的にはお互いにとって半島全土は自領土であり、相手方は不法占拠しているにすぎない（最近でも日本の高校入試で、朝鮮戦争の終戦した年はとかいう問題があって、誤った出題と騒がれた事があったはず）。
そのことを表しているだけ。
同じことは台湾・中国間ででも言えて、台湾の地図では実際にはあの島しか支配していないにも関わらず、中国全土が「中華民国（台湾の正式名称。言うまでもなく共産中国の正式名称は中華人民共和国。）」と描かれているのと同じ。
モンゴルまで台湾領になっているのは、清朝領土の正等後継者であって外蒙古の独立は認めていないという思いの現われか。単にまだ承認していなかった頃の地図ってだけかもしれないけど。

この質問のはてブコメントも笑える。
「南極大陸が意図的に大きく描かれている地図なら日本でもよく目にしますね」意図的てw。
辞書を引く「意図的：（形動）はっきりした考え・目的があるさま。『―ないやがらせ』」別に南極大陸を大きく描く目的のためにそうなってるわけじゃないですから。
世界全体を現す図を描く、というのが目的で、それを現すための図法を選んだ結果として、全体を現せることと引き換えに極域でのサイズや形状に歪みが出ているだけですから。
むう、確かにこれはジョークでした。
よく読むと原文にも「意図的」って書いてあったわ。
俺こそ読解力なく、無粋でスマソ。

いやほんま、この事実が信じられないので「釣り」や「ネタ」だったらごめん、「ネタにマジレスカコワルイ」けども。

まあ最近2チャンネルとかでいろいろ煽ってる連中がいるけど、基礎の知識や知性が共有されててその上で選択している主張なら個人の選択だしまあ自由だなと思ってたけど。
俺も日本の「総中流」幻想に囚われすぎてたか。
屋台骨としてはこの程度の歴史や政治情勢すら知らない連中が、昨今の嫌韓本とかで上っ面の知識だけ刷り込まれて、なんか「政治が危ない」とか「外交が危ない」とかいっぱしの国士を気取っているとしたら、危ないなあ。
はっきり言って、進化論否定して創世記が事実と信じてるアメリカの田舎の純朴な？人々笑えないレベルですから。
というか、国民のこういう基礎教養の低下を嘆く方が、真の国士だと思うんだけどなあ。

ヨーロッパにも対応と快進撃のGoogle Mapsですが、意外とお隣の韓国なんかでは受け入れられない可能性があるんじゃないかと思った。

というのは、韓国の地図サイトって、元々インタラクティブなんですよね。
お国柄？Microsoft一辺倒なので、IE依存のActiveXバリバリなんだけども（今も確認したけど状況変わらず）、鳥瞰視点からの都市立体地図とか昔からあったりして、そういうのに慣れている目からしたら、Google Mapsが韓国詳細地図に対応しても、ハァ？ってな感じなんじゃないかなと思って。
APIとかあるから確かにギーク受けはしても、それ以上には広まらないんじゃないかと。

で、Googleのサービスって、Web進化論でも「世界政府ができるならそのシステムはGoogleが」みたいな記述があったけど、必然的に世界を期待されてるような節があるんじゃないかと。
Goo地図やLivedoor地図が世界対応を期待されることはなくても、Googleはそうじゃないだろうと。
実際、Google Mapsも、地図表示にしてスクロールしていくと、国が変わるとのっぺらぼうになっちゃって、正直美しくない。
美しいと思わせるには、全てに対応していて欲しい。
そういう「Googleに世界を期待する」ユーザ心理が、他社のつけこむ隙になり得るかなと。

Googleの投入する新しいテクノロジー、それを世界の1領域だけに集中して投入していると、別の地域で同じことを真似するところが出てくる。
それは模倣であっても、そこでのサービス展開が年単位で遅れたりすれば、その地域ではそちらがデフォルトになる（韓国の場合、別にGoogle Mapsの真似をしたわけではなく元からあったわけだが、その文化がGoogle Mapsの侵入を阻みそうな感じ）。
かといって、世界を期待するユーザのために浅く広く投入してると、地域性への細やかな対応等で地域の他社に遅れを取りうる。
実際、Google Mapsが単なる地図やジオコーディングレベルには対応しても、その先の、例えば地下鉄の出口や地下街のアクセス情報、障害者のための交通経路情報とか、そういう細やかな地図付帯情報に対応するとは思えない。
そういう事に対して、Google Mapsが火をつけた？Ajax技術等を応用してバリバリのユーザエクスペリエンスを持ち込んでくるのは、Googleではなく各地域のポータルであったり地図サービスであったりするのではないかと思う。
そして、ユーザにとってはそっちの方が使いやすいわけだ。

そうなってくるとどうなるかというと、おそらく階層分化するんじゃないかと思った。
その頃には、セマンティックWebによる、情報への意味付加も実現化しているんじゃないかと思うんですけど、Googleは世界的な部分を扱って、その下位の階層の情報においては、下位の情報を扱うサイト内の、位置情報等で同じ意味を持つページに誘導されるとか、そういうふうになるんじゃないかと思う。
或いは、文化は進むけどそこまでの厳密な連携は直接的にはなされなくて、Greasemonkey的な（とはいえもうちょっと非ギーク層でも使えそうな）ユーザエクスペリエンスで実現されるレイヤとして持ち込まれるか。

考えながら書いたからよく判らなくなった。意味通ってるかな？
最初は単に韓国では流行らないかねえ、というのを書こうとしただけだったのだけど、書きながらどんどん考えが膨らんでしまいまして。
なもんで当初はおまけにこんなネタも用意してたのだけど...韓国でGmailが落ちたんだって。感想とか読んでても、韓国ではイマイチGoogle人気ないのかな。

保土ヶ谷事件と言うのがあるらしい。
最近判決が出たので知って、通勤途中で通る駅で「おもろい地名やなー」と印象的に思ってたところなので興味持ったんだけど。

まあ興味持ったばかりで情報調べ尽くしてないので、事の真偽に関する見解は何も持てんけど、判決見て感じた違和感。
裁判官って、事実認定された事に対して法に照らし合わせて量刑したり裁定する事に関してはプロだというのは判るんだけど。
事実認定部分で、自分がプロじゃない部分の判断について、その分野のプロが下した判断を、『あいまいだ』とかで却下しちゃうのな。
複数の、その分野のプロによる判断が否定している（断定できないといったレベルではなく、否定している）ものでさえ。
自分達の判断は、裁判官が1人の場合なら単独での判断すら、確定してしまうというのに。
もちろん、三審制があるから本来の意味で確定するわけではないけれども、三審全てが同じ構造であるなら基本的にこの問題に関しては本質は同じだ。

ホルマリンでDNAが破壊されるなんて、俺は専門家じゃないのでよく判らないのだけど、専門家だったらそのくらいは考えて判断するんじゃないかと思うんだが。
それがあいまいで取り上げられないというのであれば、DNAが現れるまで本人照合の決め手であった指紋はどう運用されてきたんだろう？
なんかよく、指紋採取の新しい技術が開発されて、犯人に掴まれた被害者の皮膚からとか、そんな厳しい条件でも指紋が取れるようになったとか、そんな話も聞いたりするけど、逆に言えばそんな厳しい条件から取られた指紋でも利用されちゃうという事。
素人考えながら、ホルマリンでDNAが破壊されるとかのレベルじゃないような気もするんですが。
それで、その指紋からどういう条件で同一人判定されるかというと、「指紋実務家たちの経験則によって一応12点あれば十分」経験則って...それ科学でも何でもない気が...うがった言い方すればそれって12点一致してれば犯人としてきただけじゃないの？という印象すら受ける。
もちろん、犯罪捜査だけでなく一般のサンプル調査でいろいろ確認してこられたのだろうし、これまで何十年と世界中で運用されてきたのだから、指紋鑑定そのものにケチをつける気はないけれども、ただ指紋鑑定ですらその程度の根拠しかないもの、しかも多分警察の捜査での鑑定だけで複数の検査機関による確認なんかほとんどなかったと思われる。
にも関わらず、その指紋鑑定が、裁判の場で証拠として否定されるようなケースって、それほどないんじゃないか。
それと比較すると、このDNA鑑定がこんなあいまいな理由で証拠として取り上げられないのは、一貫性を欠いていると思う。

今回の事件で証拠採用しろとかいいたいのではなくてさ、科学的な手法で導出された証拠に対して、それを事実認定するに至るまでの手順を基準を定めて一貫性を持たせなければ、もっとも客観的で正確な材料となるはずの科学的根拠が、逆に人の気持ちに納得のいかないもやもやさを生み出してしまうのではないかという事。
科学的（或いは将来のIT犯罪等を含めれば技術的、にも）に導き出されたものを証拠として採用するには、少なくともどれだけの数の専門家によるどのような検査結果を、どのような手続きで受け入れるか、異なる見解が出た場合の採否の取り方、等について基準をはっきりさせ、それに従って認定された証拠は、裁判官ですら門外漢であるとして事実認定を却下できない、といった形にすべきじゃないか。
でないと、逆にDNA鑑定技術が不明確だった時代に証拠採用されたとして冤罪じゃないかと疑われている足利事件とか、警察が全部サンプル使い切っちゃって再現検査ができないのでゴタゴタしてる筋弛緩剤点滴事件とか、なんかもやもやして納得のいかない、結果として警察や司法に一定の不信を植え付けてしまうような事件が今後も量産されてしまうんじゃないか。
もっとすぱっとなんかこうさ、エリートらしく、我ら愚民が「へへえ、恐れ入りやす」みたいに頭を下げるしかない、納得のいく基準を生み出してくれよ、と思う。

こないだ、ねねが
税務申告大道芸品達のどんぶり版ができるってラーメンはYAPC大道芸にまかまかさん.
とか考えてたよ。

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

GoogleMap上にNASAのWMS情報をかぶせているサイト発見。
Google Maps API and WMS Servers
いつものごとく、ためしてみませんが、API形式でソース公開されているので自分用にWMSを載せることも可能のようですねー

おお、スバラシス。
WFSはどっかないのかな？

ちょうど、Google Mapsで誰もが使える地図が手に入った次代の、MapServerの役割（エンタープライズなそれではなく、市井ハッカーに訴求するような）は？
AJAXベースでGoogle Mapsと重ね合わせられるWFSクライアント実装とかできたら、そのデータソースとなるWFSサーバ提供環境として有用になるか？とか、最近知人と話してたりもしてたので、個人的にタイムリーな感じ。

WMSクライアントと言えば、GRASSもWindows対応になりつつあるようで。
と偉そうにいえるほど、GRASSを知っているわけではないのですが。MapServerやPostGISはともかく。

Windows版のGRASS（QGIS0.8） -横浜スローライフ-

長い間Linuxでしか動作しなかった、オブジェクトの編集機能がWindowsでも動作するようだ。
まだ安定動作版ではないという注釈付きなので、...
　　　.........
これがまともに動くようになったらすごい。
経路探索等のネットワーク分析、WMSレイヤ対応、PostGISアクセス、各種の空間分析機能、オブジェクトの編集機能等々、商用製品が不要となってしまうほどのインパクトがある。

もうちょっと落ち着いたら、私も試してみようっと。

エキサイトネームカードは、インターネットで活動する人のための名刺です。
ブログやホームページなど、インターネットでのあなたの表現活動に役立てることができます。
18歳以上の方なら誰でも作成することができます。

なるほど、これに至るまでのこういう進化もありか。
とりあえず、自ポータルの一元化は図れますな。
面白そうなので早速登録（左メニュー参照）。

というのが今日あった。
災害があったと想定して、11時に園から連絡が来るので、引き取りに行くと言う訓練。
交通機関等が麻痺した場合を想定し、勤務先等から迎えに歩いてくる、というのが趣旨らしい。

大地震安心マニュアルでも一度職場から家に帰る訓練しとくべき、とあったので、俺が引き受けてもよかったんですが、私が行く！と家内がいうので任せた。
バイトは休むとの事...休むのはいいけど、家で待ってるって、それじゃ意味ないやん。
国立行っとけ。
というか、延長保育頼まない限り幼稚園は水曜は11時までだから、それ、普通のお迎え。

まあそれは別に真面目にやろうがなんだろうがええんやけど、マジで事が起こった時、俺は横浜、家内はバイトは国立、大学は京都、祖父母はみんな関西。
うちの息子は誰が引き取りにいけるのだろう？
災害で孤立する息子の姿を考えると、マジ心配になった。

まあこんな感じで、さすがにやばいと思い、ストレスで多くなっていた買い食いを一切やめることにした。
純粋に三度の飯だけですまそうと。

今朝はストレスも疲れも極限状態だったので、家出たときからずっと鬱状態だったのだが、電車に乗っていると、急に体調の変化に襲われた。
頭が真っ白。思考が空転。目が回る。吐き気のようで吐き気でない、嫌なむかむか感。胃袋がひっくり返りそう。冷や汗が流れる。
電車の振動が背骨に流れて、脳にも腹にも響き渡る。しばらく我慢したが、耐えられないので立とうとすると、足元がふらつく。

すわ、ついに狂ったか？
引き返して年休とって、精神科でもいくか？とか思ったが、とりあえず途中の横浜で一旦降りて、ホームに座り込み休んだ。
だんだんパニック状態から落ち着いてくると、バラついていた感覚が体内で一つの感じなれた感覚に収束してきた。
これは...腹ペコだ!!!!

うちの家内が作ってくれる朝食、おいしいんですが日によって極端に分量が違うのが難点で。
混ぜご飯やらご飯食の時は、ある程度量もあるし、息子がご飯食進まず残すので（残さないよう躾けてるので、食べられる量事前申告させて、差分を引き取る形だけど）それを引き取ることもありある程度腹いっぱいになるのだが、
パン食の時は全体量も少なく息子がパン好きで多く食べるので、必然的に量が少なくなる。大体いつも薄切りの食パン2枚分。
おまけに今朝のおかずはと思い返してみると...キャベツの千切りにソーセージ1,2本!!
そりゃ90kgの大の大人の食事としては少なすぎだろ!!

というわけで、買い食いしないの誓いもむなしく。
一電車やり過ごして、次の電車に立って耐えながら何とか会社の最寄駅にたどり着き、コンビニに駆け込んでヴィダーインゼリーかっこんで、職場でおにぎりも食ってなんとか復活しましたとさ。

愚痴エントリ。

先の見えないことに対して保証を求めるなよ...。
俺よりはるか上の人ですら絵が描けてないことを保証できるわけないだろ。
誰もがリスクしょってやってる中で自分もリスクの範囲内で考えろよ。
周囲の状況変化気配に合わせて自分も望みの状況得られそうな雰囲気だから、できる限り協力してくれ、と言うのなら１も２もなく快諾する。
でも『絶対』『保証しろ』等と言われると身動きの取りようがなくなるだろうが。
保証するには、保証内容をもっと上の次元の違うスキームに組み込むか（できるわけない、というか常識ある大人ならそんな事要求しない）、リスクと保証の誤差分を俺が引き受けざるを得ない（かくして俺のストレスは溜り続け、体調はますます悪くなる）。

仕事というものを舐めてるとしか思えない。
会社に行って椅子に座っていれば札束はひらひら落ちてくるとでも思ってるのだろうか？
その札束を落とす方法を考えるのが仕事だぞ。
もちろん役割や能力によって札束を落とす方法自体は考えなくてもよいケースもあるけど、それならばそれで札束を落とす方法を考えている人の描いたスキームに沿って、生じてくる問題を専門性で考えて解決していくのが仕事だぞ。
考えられなかったり解決できなければ、札束は落ちてこないんだぞ。
お金がどこから出て来ているかよく判らないまま、言われた事をしていればいいバイトとは訳が違うんだぞ。

お金に繋がるレイヤの話とそれ以外とは、分けて議論してくれよ...。
もちろん、直接お金にはつながらないけどその下支えをするような活動があるのは判るし、それを上位レイヤの話に組み込むことはやぶさかではない。
むしろそうすべきだと思う。
でも純粋にお金と関係ない話は、別のレイヤで話してくれよ...上位のレイヤに、ましてや『絶対』『保証しろ』なんてレベルで持ち込むなよ...。

書いたからといって伝わるわけでもなし、まさにごみエントリ。
自分のブログをゴミ箱化。
スマソ。

金曜夜から狂言練習-土曜は幼稚園行事と狂言練習-日曜は大道芸、ときっちり詰め詰めスケジュールで、おまけにその度に息子が疲れて寝るものだから肩車で走って右往左往、とかしてたらちょっと腰・股関節周りに嫌な痛みが出てきてるので、大事をとって一日休み。
昨日久しぶりに体重量ってびっくりした...90kg台半ば！大学入学以来の標準体重が80kg台半ばなので転職後のこの1年で10kg、その1年前(今からだと2年前)にヘルニアやって退院した時の体重は70kg台半ばだったので、その瞬間最低風速と比較すれば2年で20kg増えた事になる。
仕事のストレスか、抗不安剤の副作用か...いずれにせよこりはやばいので、なんとかせねば。
今毎週行ってるカイロプラクテックを2週に一度にして、代わりにプールでもいれるかな。

で休んでいるついでに、連絡を取りたがっていた知人に電話したら、ちょっと話したいことがあるので今日でも会えないかとの事。
こっちにとっても割と大事な話だったので、痛い股をさすりさすり行く事にしたけれど、体調不良で休んでいるのでちょっと罪悪感。
まあ、長いか短いかだけで、どうせ出るつもりではあったのだけど...3月中に忙しくて行けなかった税の申告するために。

図書管理システム -hata's LABlog-

どっかの記事で見つけておおおおおおっ！と思って行ってみたら、思ってたのと違って残念。
蔵書管理システムだったのね。
以前の会社での用語の影響で、私の中では「図書管理システム＝ドキュメント管理システム」だったので、グループウェアのサイボウズがその一部機能を切り出してくれたのかと思ったのですが、世間では「図書管理システム＝蔵書管理システム」なのでしょうか。
ドキュメント管理系にはいいオープンソースソフトないなあと思ってきてて、遂に出たか？と一瞬思っただけに、ちょっと残念。

うちの職場では、ドキュメントは共有サーバのファイルシステム管理だし、私は経験ないのですがソース管理もバグ管理もExcel＆人手でこれまでやってきた、という話を聞いていまして、1年前の転職時早々、その辺をシステム化しましょうよ、というレポートを出したんですが。
ソース管理もバグ管理も山ほどオープンソースでいいのがありますけど、ドキュメント管理となるとこんなのとか、（いいソフトではあるのだが）高いのしかなくて、結局代替案としてオープンソース・フリーソフトの組み合わせでのなんちゃってドキュメント管理システム案とかを苦肉の策でまとめたというような経緯もあっただけに、いいドキュメント管理システムのオープンソース版が出ないかなあと思っているのです。
あと、大規模システム開発での、いろんなソフトウェアのライセンス形態に対応して、かつちゃんと導入するハードウェア装置との対応付けも管理できるような見積もりシステムとかも欲しいなあ。

ちなみに提出したレポートはさくっと無視されたので、今でもドキュメント管理は散逸して何がなんだか判らなくなるファイルシステムベースの管理です。
ソース管理とバグ管理は、数日で開発用構成組んだ時に、方式設計チームのリーダーと共謀して、どさくさにまぎれてソース管理ツールやバグ管理ツール、MDA開発ツールとか潜り込ませたので、なんとか人力ソース・バグ管理地獄からは抜け出せそうな予感ですが。
しかしそんなこんなで、誰も先のプロジェクト運営考えてなかったから俺らが独断でMDA開発ツールとか入れたのに、今期のキックオフミーティングの場で上司が自分担当の今年度経営効率化重点項目として、「MDA開発環境を利用した開発の効率化の推進」とか挙げてたのにはこけそうになりましたが。

知人の会社（というかすでに知社という感じですが）であるオークニーさんが、オープンソースGISに触れてみようという連載を始められたと聞いたので、初めてGIS NEXTを購入した。
他にも、同じく新連載でGoogle Earthの入門とかもあったので、面白そうと思って。

「あふぃりえいと」はやってねーのか。ちっ。

買ってみてびっくり。
この雑誌、すげえおもしれー。
純粋に新しい事を知れる楽しさというか。
しょせん位置情報なんだかんだ言ったって、俺なんて、ケータイの位置情報活用とか位置情報ブログとか、やりたい事の手段としてGISを必要な部分かじってただけなので、ほんまの意味でのGIS知ってるわけではないので、全てが新鮮。
ああ、位置情報やGISという技術を持って活用しようとしてる人達は、こういう問題意識をもって、こういう事をやろうとしてるのか、或いはこんなことを面白いと思ってやってるのか、という世界を垣間見た感じ。
以前のエントリで、ギークは情報科学分野だけでなく、別にあらゆる分野で存在すると書きましたけど、その位置情報・GIS版ギークの世界を垣間見た感じでした。

Google Mapsとか使って何かやりたいとか思ってる人は、この雑誌とかで既存のGISの考え方を参考にするのもよいかもしれません。
単に位置に情報を貼るとか、そんなのだけじゃなくて、「地図と空間データがあれば、あんなことも分析できるこんなことも分析できる」という事を知れば、それと今のWeb2.0のトレンドをつき合わせて新しいアイデアも浮かぶかも。
特に、例えば位置連動広告に携わってるとか、まさに位置ベースでの「分析」を技術の核にする必要がある人は、既存GISを調査してみるのが吉かもしれません。

お目当ての連載はとりあえず第１回ということで、オープンソースのGISツールにはどんなものがあるのかの概観。
デスクトップ系のGISソフトが多く紹介されていたけど、さるがとんだらのたくぼさんが最近対応したOpenEVの国際化なんかもちゃんと話題として盛り込まれているのはさすがというか。

しかしびっくりしたのは、官公庁がやってて地図連動のSNSとして話題を読んでた八代市の「ごろっとやっちろ」の開発者インタビューもあったんですが、取り組みが面白いのは知ってましたが、どっかのベンダーに作らせたのかと思ってたら、なんと市の担当職員の方が自分で作ったっちゅうんですね。
しかも、普通ミドルウェアとかオープンソースツール流用して使うだろ？というような、GISエンジン（普通にESRIとかの使えば数億円はしますわな）やSNSエンジン部分まで自分で作り、おまけに今はそれをオープンソースで公開していて他の自治体でも採用されているとか。
いやー、すごい、世の中天才っているもんですな。
それだけの実力あれば、東京にでも出てどこぞのベンチャーでも入った方がいいのでは？と思わせるけど、でも彼をそこまで突き動かすパワーの原点は郷土愛だということで、東京で自分の故郷に関係のない仕事をしていてもそこまでのパワーを引き出せていたかというと...???ということらしいので、やっぱ人っていろいろだなー、と思わせられた。

「Web2.0への道」買った。

Web2.0への道

posted with amazlet on 06.04.21

インプレスR&D (2006/04/15)

Amazon.co.jp で詳細を見る

巻末のMena TrottとBen Trottのインタビューで、LiveJournalに既に友人だけ、家族だけ、或いは完全公開、といった形でどの投稿を誰にアクセスさせるかを制御する機能が実装されているらしい。
LiveJournalといえば、早くからOpenIDにサーバ及びコンシューマ機能を提供しているOpenIDの推進サイトとしても知られてるけど、自サイトアカウントだけでなくOpenIDによるユーザも友人・家族として設定できるのかな。
だとしたら、既にある程度先のエントリに書いたようなのの1実装があるわけだ。すげえ。
他のサイトも追随すれば、一気に広がるかな？

インタビューで「SNSとブログ等、1人で複数のサービスを使っている人も少なくないが、これらは今後共存していくのか、統合していくのか？」の問いに答えて曰く、「統合されていくはず。1人があまりにたくさんのネットワークを抱えているのは大変と、誰もが思っているはず。ネットワークのタイプごとに異なったサービスではなく、1つのサービスでグループを分けるアクセスコントロールが重要になっていく。」とのこと。
全くその通り。That's right.
2005年1月号のiNTERNET magazineでも、CEOのバラック・バーコビッツはんが「今後のブログはプライバシーのカスタマイズが重要なカギ」と言うてはった。
エライさんがみんなこんなこと言うてはって、LiveJournalみたいな実装もあって、でもってオープンなSNSの鍵となる認証手段、TypeKeyやOpenIDといった仕様を協力に推し進めてるのもSixApart。
TypeKeyもOpeｎIDも最初は「コメントスパム対策」とかで出てきたけど、いまやOpenIDにはコメントスパムには関係ないだろ！というようなプロファイル交換プロトコルも出来てたりして、判り易すぎ。
こりゃ、SixApartがこの先どういうことを考えてるかは丸判りですな。

というか、実力不足でサクッと落とされましたが、2004年10月ごろ私、SixApart Japanに応募しまして、応募した理由が当然PerlやBlog、RSSといった先端技術・仕様の総本山で働いてみたかったというのもあるけど、もう一つはこの先必ず出てくると思ってたオープンなSNSで鍵となる、個人の情報基地としてのBlogソリューションと、まさにオープンなSNSにとっての鍵である認証手段であるTypeKeyを持っていたから。
面接お決まりの「この会社のどんなところに魅力を？」の問いに、上のような思ってた事全部話して、「そういう方向に向かおうとしているんでしょう？」みたいな事聞いたら、いやシングルサインオンの世界には.NET passportのMicrosoftみたいな巨人がいるからそんなところに手を出そうとは思ってない、TypeKeyは飽くまでコメントスパム対策のものだ、と言われて、ふーんって。
せっかくソリューション持ってるのに勿体ないなあとか思ってたんだけど、その後バーコビッツはんの記事や、今回のMenaやBenの記事を見て、なんだやっぱり目指してたんやん、って。
その時期は社外秘だったのか、或いは日本勢は知らされてなかったのかは判らないけど。
あーやりたかったなー、と今思っても残念至極。

知人からWhere2.0一緒に行きまへんかーと誘いがきた。
もしかしたら渡航費くらいなんとかできるかもよー的なアレだったので、うーんどうしようかなーという感じだったのですが、聞くと参加費だけで$1495.00！！
テラタカス！
4月中に申し込めば$400.00安くなるみたいなのですが、すみません、ポケットマネーからは出せないです...。

というか、6月に来るここギコサーバの年間レンタル費用10万円も、どこから捻出しようかと戦々恐々としている状況で、そりゃ無理でんがな。

なんとか家計から捻出できないかな...と山の神が見ていることを期待してふってみる...。
しかし金以上に、家内も大学やバイトに行っていて、家事もして子供の面倒で毎日恐々としている状況で、まだ自分の金ならともかく家の金で1週間近く留守にするとなると、許してもらえるはずもないですわな...。

とりあえず残念ながら、多分この話はなかったことに。

きょうは、ここで追求したかもー。
ここにねねがここでねねと追求すればよかった？
きのうここが、周りを追求するはずだったみたい。

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

SNS、SNSというけど、大抵の機能は外部の技術でも実現できるものが多い。
友人関係をネットワーク化できること？そんなのFOAFで十分やん。foafnautみたいに視覚化できるツールもある。
友人関係を要請/承認だけで簡単に繋げられるシステム？あまり普及してないけどFOAF TrackBackという仕様案もある。
日記を書ける？Blogで十分やん。
友達の日記の更新を知れる？RSSで十分。
コミュニティ？Wikiとか使った方がよっぽどカスタマイズ性高いぞ。

とか書いたら、アホかと思われるだろう。
BlogやFOAF書いてたって、どこの誰とも判らん不特定多数に公開されるだけだろう、SNSは友人関係等クローズな範囲に情報流通制限できてマターリできるからいいんじゃないかと。
まさにその通りなのだが、だったらそれを実現できるために最重要な機能というと、なんだろう？
言うまでもなく、「ログイン」である。
オープンなWorld Wide Webの世界から、ログインすることでクローズな1サイト内の支配領域に遷移し、その情報を使って友人との関係を認証できるしコミュニティへの参加も自動化できる。
そう、SNSにとってはあのトップページのユーザ名とパスワード入力画面こそ、もっとも重要な機能なのだ。

ということは？
Yadis、OpenIDやLIDといった分散型ID技術が広がって、どこのサイトでも誰のBlogでもどんなWikiでも共通にログインでき、今閲覧しているのが誰か証明できるようになれば、インターネットそのものをSNS化することができるようになるということだ。
SNSの内部コンテンツと同等の個別要素は外部に全部揃ってて、問題なのはログインだけなのだから、これは当然のこと。
こう言うかもしれない、OpenIDでログインしたってコンテンツの友人だけへの配信などできないと。
FOAFを使えば可能な案 は存在する。
こう言うかもしれない、Yadisなんかは個々のページレベルのログインだから、一括して最初にログインして後は自由に動き回れるSNSサイトとは違うと。
Yadisログイン可能なサイトをブラウザが自動発見して、一連のログイン遷移を自動で行うための案 もある。
上記の案ではまだログイン画面でのID/PWは人力だが、別に分散型ＩＤシステムでログイン動作部分のWebAPIプロトコルを決めるのは簡単な話（決めればさえいいのだけなので）。
そうなると、ブラウザの自分の設定プロファイルに、自分の分散型ID情報を登録しておくだけで、自動的に要ログインサイトでは勝手にブラウザがログインしてくれるようなことも可能になるかもしれない。

オープンな仕様の強みはここだ。
Mixiがどれだけ巨大なサイトになろうと、１サービスの独自のログイン仕様がブラウザ本体の機能に取り込まれて、そんな分散型ID技術がどうとかに詳しくないおっちゃんおばちゃんでも意識せずに使えるようになる、なんて事はあり得ない。
でも、オープン仕様ならば、それがありうる。
将来インターネットそのもののSNS化が有用であると認知されるようになり、識別だけでなくその後の認証、承認まで汎用的な仕様が出回るようになると、現在メールソフトにプロバイダからもらったメールアドレスを登録するように、ブラウザにプロバイダが発行してくれた、ちゃんとhttpsで守られた分散型IDアカウントを登録して、オープンSNSに誰もが意識せずに使える時代がくるかもしれないのだ。
そうなると、60過ぎた田舎の爺ちゃん婆ちゃんに、孫の毎日の成長風景見せたいけど他の悪意ある人から見られても困るからさー、flickrのアカウント取ってよ、なんてチンプンカンプンなこと頼まなくても、普通に爺ちゃん婆ちゃんのブラウザに埋め込まれた分散型IDアカウントだけに公開するよう自サイト上で設定しておくだけで、他の人には知られることなく親族だけのプライベートな情報を、見る側には意識させずに配信することができる。
その逆もまた真なり、大事な孫の親である30代も半ばになったくそ中年親父が、「バロス」だの「うはｗ夢が広がりんぐｗｗｗｗ」等とサイト上で喚いている嘆かわしい状況を、田舎の爺ちゃん婆ちゃんには隠すこともできる。うはw (ｒｙ

こうしてSNSがオープン化することで、いちいち所属する複数のSNS毎に自分のプロファイルをメンテナンスし、アクティビティをメンテナンスし、人間関係をメンテナンスする必要からも開放され、自分のサイトなりブログなりを自分のメンテナンスすべき唯一のアイデンティティベースとして一元化することも可能になる。
現在、もう7桁台のユーザ数に突入したMixi、SNSにとってのコンテンツたるユーザの数の圧倒的な差の元に、他のSNSは手も足も出ないが、インターネットそのものが潜在的なSNS化すれば、その潜在的ユーザ数は10桁になんなんとし、Mixiなどものの数ではなくなる。

このような状況の未来になると、クローズドなSNSにどっぷり漬かっている連中は言うようになるだろう。
クローズドなSNSは、ユーザとコンテンツの質が違うと。
まるで同じような話をもう10年ばかし昔に聞いたことがある。
インターネットとパソコン通信の間での話しだ。
質が高く秩序があったが出来る事に制限のあった、個絶したパラダイス「パソコン通信」は、不躾で無秩序だったがあらゆる可能性に満ち溢れた「インターネット」の出現の前に、いつかゲートを開かざるを得なくなり、そして何時しか消えうせていった。
同じことがSNSにも起こるだろう。
まさに、歴史は、繰り返す。

「可能なことは、必ず実現する」とかって、誰かの言葉じゃなかったっけ？
分散型IDでどこでも共通にログインできるだけで、オープンなSNSが理論的に可能ならば、それは必ず実現するだろう。
別にそれを俺ができると言ってるんじゃないっすよ。一役買いたいとは願ってるけど。
今のSNSやっている人達って、その辺の可能性とかちゃんと視野に入ってるんですかね。

ただ一つ残念なのは、流石にこのエントリに書いたまでの状況になるには、まだ2年や3年以上はかかるんじゃないかということ。
そうすると、今の一番可愛い時期の息子の成長っぷりを田舎の爺婆に、身内だけに安全に配信して即座に伝える、というのはあきらめざるを得ないなあと。
ましてや来たるべきそういう時代のために何かやりたいと思って父親が忙しく動いて時間が取れなかったりしたら、ますます孫と祖父母の関係は、それを親密にするためにやってるはずが逆に疎外化が進むわけだ。
それだけが、残念というか、そんな感じ。

色々HTTP周りの決まり事とか追求したらもしかしたら間違ってるのは俺のほうかもしれないけど、一応書いてみる。

Yadisの仕様議論MLでの話。
普段は英語苦手なので、議論にはほとんど参加しないで決まった事に従って実装するのみなのだけれど、Yadis IDとなるURLとして、どこまでを同一とみなすのか？
http://myid.example.com/ と
http://myid.example.com:80/ と
http://myid.example.com は同じIDとみなすのか？という議論があったので、一応実装作っているものとして、

1. 環境変数使えば、3つのアクセスは別のアクセスと判定できて、別のコンテンツを流す事も技術的には可能だ。これは「唯一性の識別」という概念から考えるとあまりよくないのではないか。
2. 識別サーバにせよコンシューマにせよ、ユーザのYadis IDのURLは、ハッシュなりDBなりのキーとして管理してる事は間違いない。たかだかこれだけの表現を認めるためにいちいち正規化の処理を入れるのは馬鹿馬鹿しい。
3. IDという概念からも、表記法は一意であることが望ましい

という論旨で、それぞれ別に扱うべき、と意見を述べた。

そしたら反論が来たんだけど...「IETF RFC嫁。それに従って正規化して、同じだったら同じID、違ってたら違うIDだ。婆ちゃんがhttp://grandma.example.com/ とhttp://grandma.example.com の違いを理解してくれると思うか？」だって。
ふーん。

いや、このデジタルデバイドの話題なんかほんまに首肯する身なので、婆ちゃんのこと考えるのは立派だと思うのよ。
だが、これがhttp://example.com/grandma/とhttp://example.com/grandmaだったらどうするのだ？
これだって婆ちゃんは区別はつかないぞ。
というか、差の判らない婆ちゃんが打ち間違った場合でも認められるようにするというのならば、http://grandma.example.com, にだってhttp://grandma.example.com; にだって、いやhttp://grandma.example.conにだって対応できないと嘘だ。
まして、婆ちゃんが :80 なんざ間違えてつけるとも思えない。
お婆ちゃんがたまたまIDの最後をスラッシュに間違える等という超超超レアケースにだけ対応するために、仕様を重くしてどうするというのだ（だって、同じだと認めることを仕様とするのならば、それはすなわち処理する際にURLの正規化処理を必ず入れる事を実装に要求しているのと同じことなのだし）。
「ID」なんだから、HTTP的に意味が同じかどうかに関係なく、一意な表現に固定すりゃええやんけ。
婆ちゃんには「これがID。間違っちゃ駄目よ」と言えば済む話。最後尾だけ間違ってもいいからね、なんて言っても余計混乱するだけ。

そもそも、もしURLを正規化すべきだとしても、それならそれでその処理はどこでするのか？という問題もある。
識別URLは、Yadisの下位プロトコルで実識別部分を担うOpenIDでも（そして多分LIDでも）、識別コンシューマと識別サーバの間で識別処理のためのリダイレクトを繰り返す際に、何度もGET/POSTリクエストの引数としてコンシューマ/サーバ間のやり取りで渡される。
HTTP的に意味が同じだから同じID、というのであれば、そのサーバ間遷移でもどんな表現が来ても等価なら同じIDとみなさなきゃならないぞ。
サーバ間の遷移でもいちいち引数を正規化するのか？馬鹿馬鹿しいことこの上ないと思うのだけど。
おまけにURLを交換するのは識別IDだけじゃない、コンシューマを信頼するかどうかのtrust_rootなんかの設定も交換するわけだが、HTTP的に等価であれば同じとみなすのであれば、trust_rootにhttp://example.com:80/が渡されても、http://example.com/consumer/を信頼できなければいけないから、その辺までいちいち遷移のたびに正規化しなくちゃならなくなる。
アホらしいことこの上ない。

それに、正規化するということは、ユーザの入れたURLと識別に使ったURLが異なるというケースも出るわけだ。
http://example.com:80/user/でログイン要求したユーザに対し、ログイン成功後の画面でのID表示をhttp://example.com/user/として表示するのか？
それとも、キー検索用の正規化後URLとは別に、ユーザの入力したID URLもわざわざ覚えておくのか？
どっちにしてもアホらしい。

というか、そもそも識別IDの識別方法のプロトコルと識別サーバを探すためだけのプロトコルであるYadisの方で、いくら識別URLは正規化すべきであると定められても、実際の識別処理に用いるOpenIDやLIDの方の仕様でそんなことが決められてなければ、全然意味がないと思うのだが。
（もちろん、この議論がOpenIDやLIDにまで波及して仕様が変わる可能性もあるとは思うけど）

みたいな反論を、本家MLでやりたいのだけど、そこまでの議論を英語でできる自信がなく、まだ投げてません...。

OpenIDの方は、仕様的な動きは特になしですが

すみません、大嘘かましてました。

プロファイル取得のプロトコルができていました。
Simple Registration Extensionなので、プロファイル取得と言うよりは、OpenIDコンシューマサイトにユーザ登録するのに必要な情報をOpenIDサーバから自動取得するのに使うという位置付けなのでしょうが、まー要するにできることはプロファイル取得です。

対応するサーバを記述する場合の、Yadisドキュメント上の定義はこんな感じのようです。

<Service>
  <Type>http://openid.net/signon/1.2</Type>
  <Type>http://openid.net/extensions/sreg/1.0</Type>
  <URI>http://www.myopenid.com/server</URI>
</Service>

シングルサインオンのバージョンナンバーも1.2と上がってたりするのですが、一方でSimple Registration Extension対応を意味するType属性も定義されているので、関係がよく判らず。
Simple Registration Extension対応が1.2という事ではないのか。シングルサインオンのプロトコルも何か変化したのかな。
OpenIDサーバの取得方法を正式にHTMLヘッダからYadisベースに移したのかな。
この辺まだ十分追えてないので、判れば追記します。（OpenIDの仕様ページを見てもよく判らんのだ...これ自体バージョンいくらなのか書いてないし）

この新仕様に対応した実装としては、OpenIDサーバとしてMyOpenID.com、コンシューマとしてSchtuff.comがあるみたいです（情報元、というか大元はMLだけど）。

しかし、Simple Registration FAQとかみると、FOAFはプロファイル交換の手段として重すぎ、とかってあって、FOAFと分散認証技術でオープンなSNSを夢見る身としては少々orzな感じ。

後、OpenIDEanbledを漁っていて見つけたネタとしては、以前欲しいよなーと書いたmod_openidみたいなApacheモジュールが、ネイティブモジュールでなくmod_python経由のもんですが、できてるみたいです。
用途としては、私が書いたのと同様、Apacheサーバ上のアプリケーション横断でOpenID認証実現したいような場合。
認証されたURLベースで、.htaccess上に設定してアクセス制御が出来る模様。

また、拙作ながらCPANのOpenIDコンシューマモジュールをYadis対応にしたNet::OpenID::Consumer::Yadisなんかも出しました。
もしOpenID1.2がYadis採用であるならば、図らずも1.2対応ライブラリという事になります。

今の仕事はプロプライエタリなソフト中心で組むしかないのだが、なんか端っことはいえオープンソース中心でしばらくやって来た身としては、ほんまに馬鹿馬鹿しいなと思うことがしばしば。
上司なんかがいうには「何か問題があった時にサポートも効かない、サポートを任せる先がないようなオープンソースソフトなんてリスクが高くて使えない」という事だし、別の課長も言うには、「どうしても他のソフトの前提なんかでオープンソースを使わざるを得ないところは、そのソフトに関する不具合なんかの問題はうちで責任取らない旨、客先で明確に示しとかないといけないぞ」とか言われるんだけども。
なんか構成組んでると、プロプライエタリなソフトの方がよっぽどリスクだらけちゃうの？わざわざクソ高い金払うのに、と思えてくる。

まず危ないよなーと思うのが、とりあえず機能を前もって試せない事。
そりゃ試用版とかもあるにはあるが、全ての機能が使えるわけでもないし、全部のソフトで用意されているわけじゃないし、まして利用可能な期間が1ヶ月とかって、年単位で設計がかかるプロジェクトにあんた1ヶ月でまともな検討なんてできんでしょ、試用期間過ぎた後に新しい要件が出てきたらどうするの、みたいな。
オープンソースだったらとりあえず環境構築してずっと置いておけるのに。
というか、まだまともに方式も決まってないのに、プロジェクトスケジュールの都合だけで構成を決めないといけないからと言って、機能リスト一覧だけから該当する機能を満たしそうなソフトを、カタログスペックでとりあえず積んでおいてー、みたいなノリで何百万何千万のソフトを載せて大丈夫なのかと。
カタログスペックで何が判るのかと。
同じそんなノリでせざるを得ないのならば、まだオープンソース使う方が、金かかってない分リスクは低いでしょ、と思う。

さらに最近「これ危なすぎ」と思ったのが、ソフトのバージョン間の依存性の問題、販売期間やサポート期間の問題。
一部の先行開発部分を開発してる部隊が、あまり十分に検討してなくて一部のOSやRDBMSで市場の最新ではないバージョンを使って（というか、正確にはそれら旧版を前提として依存しているソフトを使って）開発してテストまで終了しているのだけれども、客先からなぜ最新版を使わないのか、納入時に調達できるのか、とか心配されてる。
メーカのロードマップを見る限りでは、確かに販売中止になって調達できない可能性も否定できない。
調達さえできれば、サポートはなんとか個別契約で延ばす事もメーカによっては出来るが、販売中止になって調達できなければ逃げ場はどこにもない。
でも、概してメーカのロードマップは遅れがちで予定通りいかないし、また必ずしも原則どおりは運用されないから、現に既に提供停止されていていいはずの前々バージョンが今も入手できたりしているし、ロードマップを額面どおり受け取れば調達時には入手不可だけど、入手できる可能性もありますよ、という同僚もいる。
OS・RDBMSを現行版にしちゃうと、既にテストも終わって客先検収を待つだけの先行開発部分を再テストしないといけないし、さらに一部のソフトはOS・RDBMSの旧版までしか対応せず、現行版対応はしない事をメーカに明言されちゃっているので、下手をすると作り直し。

さあ、どっちのリスクを採りますか、って、こんなんリスク選択も何も丁半バクチと一緒やん。
よっしゃ、多分調達できるやろ、と踏んでもロードマップに書かれてる以上調達できなくても文句は言えない。
オープンソースなら別に後になっても古いバージョンのソースは取得できるし、こっちに都合のいい部分で凍結したって何の問題もない。
サポートが受けられないリスク、とか言ったって、最悪ソースが公開されているんだから自前で何とかできる可能性が残されているのだし、こんな丁半バクチのリスクよりオープンソースのリスクの方がよっぽど低いと思うのだけれど...。

等と、「オープンソースを自前で何とかできる」スキルのない奴が言っても説得力ないかもしれないが。 
それにプロプライエタリといったってもっとちゃんとした設計してるところもあるんだろうし...まあうちみたいなしっちゃかめっちゃかのプロジェクト運営でやるんなら、オープンソースの方がリスクが少ないんじゃないの？と思う。
んで思ったんだけど、結局「システムの運用期間サポートが（特に24時間オンサイトとか）補償されるかどうか」がうちみたいなとこでソフトを選択する一つの決め手になっているみたいなんで、ある程度スキルの高い人集めて、オープンソースソフトのサポートをオンデマンドで引き受けるビジネスとか、アリだったりするのかな。
特定のオープンソフトとかだと、SRAのPostgreSQLとかあるわけですが、ユーザがプロジェクトで使いたいと思ったソフトを、オンデマンドで引き受けるとか。
流石に何が来るか判らないものを、24時間オンサイト対応もできるような体制を作るのは無理か。無理っすね。

今の仕事のチーム仲間（正確には隣の部署なので、カウンターパートを担当してもらってるとこの人だけど、ほとんど一体化して仕事してるので）で、すごい人がいる。
というか、今の仕事全然今まで自分の専門でなかったので、相対的には私以外はみんなすごいんですけどもｗ。

サーバのアーキテクチャだろうが電源だろうがストレージだろうがリムーバブル媒体だろうがグラフィックスカードだろうが、およそハードと言うハードの大抵の規格について詳しい知識を持っていて、その方面に詳しい知識も経験もない私をフォローしてくれる。
今の仕事のOffJTをほとんどしていない私にとっては、本当に知恵袋と言う感じで大変助かるのだけれども、時々困る事がある（自分より知識があって、おまけに多分年上の人に対して失礼かもしれないけど）。
知識の披露？に夢中になってしまうのか、時々会話等がそれを使って組み上げるべき要求を無視した暴走をしてしまったりするのだ。
大量の配布用媒体を作成する要件で、ユーザの手を煩わせずアプリケーション操作で媒体を自動作成するためにメカ機構を持った機器を導入するのだけれども、その機器の本来の利用用途は同じ媒体を大量生産することで、発行数としては1枚ずつの媒体を自動作成するための機器ではない。
そんな事は判ってるんだが、自動で媒体を大量作成するという要件を満たしており、かつ安い機器という選択肢で選定しているので、客先説明ではその要件を満たすという事を重点的に伝えればいいだけのはずなのだが、彼が話し出すと「本来この機器はこういう用途に使うものではなく...」といかに今回の使われ方が本来の用途と違うか、本来の用途とはどうあるべきか、見たいな話が客先で10分くらい続いてしまったりもする。

先日、さすがに唖然としてしまった事があった。
納入する、高解像度のデジタルインタフェースのTFTモニタを、客先の同解像度プロジェクタ（別システムで準備中のもの、アナログインタフェース）に画像分配するという要件があった。
私は2出力あるグラフィックカードを選定し、クローン出力にして一方の出力をインタフェース変換（グラフィックカードからの出力は、物理的にはデジタルインタフェースでもアナログ信号を含むので）してプロジェクタに繋げる、という設計をしていたのだが、その設計をみて彼が言うには、「アナログインタフェースでの取り合いならば、TFTに出力しているグラフィックカードと同じ出力をクローンしたのでは、液晶のリフレッシュレートは低いのでフリッカしてしまい、プロジェクタは使い物にならない」とのこと。
解決するには、デジタル入力を受け付けて、リフレッシュレートまで考慮してアナログ信号変換して分配してくれる、分配器を通すしかないというのだ。
そのような機器は存在したが、残念ながら客先の要求する高解像度を変換できる機種はない。
仕方なく、客先会議で設計検討不十分の謝罪と設計変更の打診をし、低解像度での運用検討をこちらと客先双方で持ち帰ることになった。

その後社内で、リモートデスクトップを使うとかソフト的な方法も含めいろいろ検討していると、彼が「これが解決策です」というのを示してきた。
驚いた事に、最初の私の設計と全く一緒だった。
話を聞くに、「一昔前のCRTプロジェクタなら低リフレッシュレートだとフリッカしてしまうけれど、こんな高解像度でこれから準備となるとCRTプロジェクタなんてのはないんですよ。だから液晶プロジェクタでしかあり得なくて、液晶プロジェクタならアナログインタフェースであっても、低リフレッシュレートでも問題ないんですよ」という。
いや、確かにその通りなんだろうし、こちらが経験不足で考慮事項として全く意識していなかったリフレッシュレートの検討を結果としてカバレッジしてくれたので感謝しないといけないのかもしれないが、それにしたって自分の指摘で「設計ミス」ということになって客先まで問題として出たのが、実は問題なかったなら言い方としては普通「ごめん、間違えてた」とかって立ち位置にならないかなと思った。
ましてや必要解像度等要件は別に後から彼に伝わったわけじゃなくて最初から知っていたはずだし、客先に問題として出す事も知ってたし、というかその当の客先会議の場に同席していたにも関わらず、その場では何も言わずに後になっていかにも「ハードウェアに詳しい私が解決策見つけたんですよ」みたいな物言いで前と全く同じ設計出してこられると、「へ？」と言う感じになる。

もうちょっと構成を議論する時なんかでも、規格話なんかから「採り得るこんな構成、あんな構成」と要件無視してどんどん発散していくんじゃなくて、もうちょっと目の前の問題解決するために知恵を使う、というスタンスで考えてくれるとやり易いんだけどなあ...。

息子の幼稚園の保護者会。
園長のお話で、幼児の家庭生活について守るべきこと３点。

１．９時までには寝かせてください。

OK、大丈夫。
昔は俺が帰ってくるまで起きてて全然寝てくれず、毎日寝るのが11時12時だったりした事もあったけど。
幼稚園に上がってからのこの1年は、昼寝の時間もなくなったし外遊びも激しくなったせいか、8時9時にはもう爆睡。
男親的には平日夜に会えないので寂しくもあるが。

２．朝ごはんはちゃんと食べさせてください。

OK、これも当たり前。
というか最近は残すこともないよう厳しく躾けてる。

３．テレビを見ながら、ご飯を食べないでください。

.........すみません。
テレビっ子世代の親が耐えられません。
「ご飯中は録画してて、後で見て」って、んな時間ねーし。

というか、見ちゃ駄目な理由って、「食事時の家族の会話がなくなるから」って、それは関東人の話じゃねーのかと思う。
関西人はテレビ見ながらツッコミまくるから、余計に話がはずんでいーんだよ！
関西人なら、飯食いながらテレビ見ろ！

（嘘です。教育に悪いのでやめられる家ではやめてね。）

笑う準備をしといた方がいいのか...。

......違った。
何を想像してたかは聞かないで欲しい。
ゴミエントリ。

ちなみに、うちの家内の教えてくれたトリビアによると、「馬鹿旦那」という言葉はサンスクリット起源だそうである。

元記事（高橋さん）：志の高い企業、ふつうの人 - 思っているよりもずっとずっと人生は短い。

受け記事（弾さん）： 志まで雇われたいの? -404 Blog Not Found-

発展記事（弾さん）：There's more than one way to do it together -404 Blog Not Found-

後ろの2つの記事を読んで、弾さんの言いたいことは大体判った。
弾さんの記事の中での「志」って、本当の意味での『志！(本当は毛筆書体ででも書きたいところだが、できないので！で代用)』だったわけですね。
でも、やっぱり元記事との繋がりが判らない。

高橋さん記事の中での「志」って、そんなに深いレベルの話なのかなあ？
同記事の中で対比されてるのは、「志がある＝自分で本を買って読む。就業時間以外にコードを書く。」⇔「志がない＝9時から6時まで、ふつうにプログラムを書くだけ。」って、弾さんのいう『志！』レベルの話じゃなくて、「やる気」？ちょっと違うか？「コミット度合い」？その程度のものじゃないかと思うんだけど。

例えばの話、私は新卒で入って以来5年間、別に『志！』なんて持ってなかった。
普通に最初の会社で普通に同期連中と楽しくおかしく会社人生を過ごせればいいと思っていた。
でも、やらなきゃ業務が進まなかったし、他の連中は勉強しないし、まあ何より楽しかったと言うのもあって、時間外自費で技術書買って読む、自分でプログラム作る、位のことは当然のごとくしていた。
その意味では、私は当時、高橋さん言う意味での『ココロザシ』（以下、区別のためカタカナ書きします）には溢れた奴だったのだ。

ところがGPS携帯の登場にショックを受け、位置情報で世の中変えたいとの『志！』を持ち、3年前上京してきて以降の私は、仕事後、休日、ほとんどその実現のために費やしている（位置情報は萎え気味なので最近は分散型認証技術に軸足が移っているが）。
これはすなわち、会社の業務を回すためのOffJTはほとんど（いや全くか）行っていないという事（『ココロザシ』はゼロという事）だ。

ことほど左様に、2つの『志！』と『ココロザシ』は異なる、いやむしろ相反する概念のように思う。
弾さんの素晴らしい造語を借りるなら、『志！』はライフワークドメインで、『ココロザシ』はライスワークドメインという感じの。
なので、弾さんが高橋さんの論を引いている理由がイマイチ判らず。
枕詞的なアレだったのか。

さて、弾さんは『志！』を持つ人にも処方箋を与えている。

より一般的に言えば、金のために一つの仕事を、愛のためにもう一つの仕事をする ということだ。

これはなるほどそういう考え方もあろうと思う。
Matzさんなんかも普段は別の仕事をしながらRubyの開発をしていると聞く。すごいと思う。
でも、思う、甘えかもしれないけど、「人は『志！』のみにて生きるにあらず」。
私は『志！』は持っているつもりだけど、その『志！』とやらは断じて私の「趣味」ではない。
「趣味」は何かと聞かれたら、私は迷わず「狂言」と「韓国太鼓叩き」と答える。
「ライスワーク」に追われ、残ったわずかな時間を「ライフワーク」につぎ込んで、狂言は月に一度師匠の前で練習して台詞覚えておらず怒られるだけ、太鼓に至っては3年間全く触りもしていなくても、俺の趣味はそれであって、断じてPerl書きではない。
その上に、人の親ともなると責任として当然、園や他の子の親といったコミュニティとの付き合いや、親としてネグレクトせず責任を持って子供の相手をしてやる必要もある。
「ライスワーク」に追われ、さらに『ココロザシ』を要求され、疲れて帰れば親としての責任を要求され、みんな寝静まってからなけなしの時間を「ライフワーク」『志！』につぎ込み、パジャマにも着替えず風呂にも入らず毎日いつの間にか寝ている毎日。
どこで心が休まるのだろう？
それが1年2年なら耐えられもしようが、3年4年と続いてさらに展望もなければ、普通耐えられるものではないと思う。

弾さんに言われなくとも、自分で起業でもしない限り『ココロザシ』と『志！』を一致させる幸運なんて、そうあるものではないだろう。
自分で起業してすら、いや場合によってはすればなおさら、より一層「ライスワーク」に追い立てられる事だってあると思う。
でも普通は、『志！』を持つ人なら、その『志！』と『ココロザシ』が完全一致することはなくともベクトルは揃えているか、それとも今は違っても揃えようと努力しているんではないだろうか？
Larry Wallが実は昼間、傾きかけた自動車会社を1年で黒字化するための経営業務に携わっているというような話は聞いた事がない。
Matzさんは多分、昼間理容師をやっているわけではないだろう。
何かしら『志！』に繋がる事、少なくとも『志！』のために勉強・情報収集したら、ある程度『ココロザシ』の役にもある程度立つ、その逆も真、な仕事を選ぶ、或いは目指すんじゃないだろうか。
でなければ、昼は『ココロザシ』を消費して「ライスワーク」をいそしみ、夜や休日は『志！』を駆使して「ライフワーク」に邁進し、あいまに「ファミリー（としての）ワーク」もはさんで「ホビー」もこなす、しかもそれぞれが完全に別のドメイン、なんて生活は、普通の人はそうそう持つもんじゃない。体壊す。
「ライスワーク」と「ライフワーク」、或いは「ライフワーク」と「ホビー」に一定以上の重なりがなければ、継続するのは無理っすよ。
んで、どっちと重ねるかというと、「ライフワーク」を「ホビー」で終わらせたくないと考えている思いの強い人ほど、「ライフワーク」を「ライスワーク」に漸近させていこうともがくんじゃないだろうか。
「昼」と「夜」を分ければ解決、なんてのは、既に「ライフワーク」を「ライスワーク」か「ホビー」のどっちかにある程度重ね合わせている人しか言えないと思う。

あと最後に書くなら、

労働時間法制：ホワイトカラーにも残業代適用除外　厚労省

厚生労働省は１１日、一定水準の年収（400万円程度らしい）があり、仕事の裁量幅も大きい「ホワイトカラー」について、残業代や休日手当の支払い対象から除外する新たな労働時間法制の「視点」を労働政策審議会（厚労相の諮問機関）に提出した。

弾さんの思いとは別に、これからの企業はますます『ココロザシ』を要求してきて、『志！』を圧迫してくるようです。
「昼」と「夜」を分けるどころか、今後ますます「昼も夜もライスワーク」っていう傾向が進むんじゃないですかね。
会社-1.0？どんどんデグレードしていってるみたいです。

これによりユーザーは、同一のタッチパッド上で電子ペンならびに指による入力操作が可能になり、従来の指の操作に加えて、電子ペンによるより直感的な機器操作と精度の高い文字入力を行うことができます。

WACOMは神なり！
4月から製品化って！すげえ楽しみ。

なんだかわからない人はこちらやこちらをどうぞ。

というか、本記事を見つけた理由が、会社でタブレット用ペンが行方不明になってしまい、ちょっとでも早く替えペンを入手するために（ソフマップとかだと取り寄せ2週間とかなので）直販を探してのためだった、というのが悲しいが...。
まあ怪我の功名？というか。
4月に出るんだったら、替えペン買うのやめて、家のタブレットペンを通勤時持ち運んで間を持たせつつ、これの発売待つかな...。

-----追記-----
と思ったら、富士通ノートPCデバイスへのバンドルだけか。
ちえっ。
WACOMさん、是非単品でも販売をよろしくお願いいたします。

きょうは、blogしたかった。
ここでねねは仕様みたいなblogしたよ♪
ここへねねは公はblogするはずだったの。
ここは、ねねがここにねねがここでblogしなかったよ。
ここに仕様もblogするはずだった。
ここに公とかblogしたの？

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

やってみた。 （ネタ元）

すなわち大塚恒平は、大塚恒平1.0である！

同時に2つ以上こなせるようになりたいものです（YadisやOpenIDと位置情報）。

亀レスなのですが、いただいたコメントに。

「アイデアやノウハウの開示は難しいね」のコメント

後半について一言。
口止めされなくても、就業規則に守秘義務があれば公開してはいけないのでは。

確かに守秘義務があるので、「それでもそのノウハウについては書いてないので、一応そう言われたものに関しては口は固いつもりでおります。」あたりのくだりは、我ながら当たり前のことをさも偉そうに、アホっぽいなあと思いました。
義務である以上、「守れ」を「守る」のは当たり前ですからねえ。

ですけど、話の本筋は、「秘するべき事の判断基準（別にたいした事は示してないけど）」のつもりなので、それはあんまり個人間のアレでも就業規則の守秘義務でも変わらないんじゃないかと思うんですよ、特にオープンソース系なんかでは。
ただ、個人間は飽くまで紳士協定、就業規則は契約の義務なので、いざ「バラした」際に、個人間だと「やな奴・常識の無い奴」、契約だと「法的問題」になるだけの話で、別にこれが守秘義務の守るべき内容の基準、なんてのが契約条文に書いてない以上、その判断基準はやっぱり個人間での秘すべき情報の判断とあまり変わらないんじゃないかと思うんですよ。

と言うより、マジで秘密にすべき事ならば「秘密にしろ」と示しておかんといかんと思うんですよね、今の仕事とかその辺厳格だし（同じ職場で仕事していても、同僚が知ってはいけない情報とかは会議資料で白抜き、間違って白抜きし忘れた時は会議資料を会議後回収したりする）。

本当に件のノウハウなんか「しゃべるな」と言われたから（＝明確に秘するべき事と定義されたから）言わないだけで、別にそれを知ったからといってPerlのディストリビューションができるわけでも、俺もディストリビューションを作ってやろうと思わせるもんでもないし、マジで「コロンブスの卵」のノウハウ程度のもの。
公開してないソースバラしたとか、そんなのとは違う話。
オープンソースの世界、はてなにしろMixiにしろ、いまやWebサービスの肝ともいえる舞台裏のサーバ構成とかすら公開して、みんなが参考にしてる時代。
誰もが問題にぶち当たったら、ネットで検索して、他の人がノウハウ暴露してくれてるのを見つけて解決、というのが当たり前になってる。
問題が解決できたらノウハウ公開してくれてた人に感謝しつつ、自分もノウハウに気付いたら誰かに役立ててもらおうと公開しよう、という動機付けにいつもさらされてる。

のだから、そんな世界で、微妙な技術情報をオープンにしたくないのであれば、それは「しゃべるな」と明確にしとかないと、あかんのとちゃうんかな。
別にオープンソース業界だろうが、競争のある世界である以上隠すノウハウがあるのは全然構わないと思うのだけれど、でも「これは隠すべき事」と明確にしないまま、なんでも中で使っているノウハウは守秘義務があるのだから出さないのが当たり前、と経営側が考えているとしたら、ちょっと違うんちゃうかと。
そんならお前、他の公開されてるノウハウも使うなよ、と（ちなみに私がPerlのお守りしてた時代、モジュールのコンパイルが通らなくて、ネットでノウハウ探して問題解決した事例はいくらでもあります）。

というわけで、コメントでいただいた「口止めされなくても...公開してはいけない」というのは、個人的にはちょっと違うのでは、と思った次第です。

いつの間にか。

YAPC以来の躁状態で、45分の昼休み毎に即効で飯食ってモジュール作ってCPAN挙げて、帰れば帰ったでブログも書いて通勤中も携帯で記事打って、みたいな事続けてたら、ついに一昨日、まだ挙げなきゃいけない資料山積みなのに指が動かなくなってどうにもこうにもになってしまった。

んなもんで、久しぶりに、というか今の会社入ってからは初めてだけれど、MS-IMEの手書き文字認識使って文字入力してみた。
俺がペンタブレット使ってるのは、手に楽なデバイスというのもあるし、いざという時手書き入力に逃げられるからというのもある。
手書き入力は、本当のペンと違って硬い反発だし、続けて書けるわけでなくて文字候補から選択しなきゃいけないので、決して楽ではないのだけど、キーボードと使う手の箇所が違うので、一時的にどうにもならなくなって休みたい時なんかには非常に重宝する。

ちゅうことで、多分1年半ぶりくらい？仕事PCがXPになってから多分初めて、MS-IME手書き文字認識で仕事してみたんだが、使ってみてびっくり！
すごい認証精度が挙がってる！
普通に書いてたら、画の続け字とか相当やっても大抵認識してくれる。
特にびっくりしたのは２つ、句読点や中点、コロンやセミコロンみたいな記号も、以前だとほとんどまともに意図してるものを出してくれなかったんだけど、ちゃんと出してくれること、そして、よく手書きだと手が滑って別の文字を書きかけて、それを他の画にして誤魔化して、変な形の字を書いたりとか、そのせいで変な形になるだけでなく書き順も間違ってたり、そんなケースもかなりの確率で認識してくれること。
これはすごかった。

メール3通ほど手書きだけで打ったけど、特に問題なく打つ事が出来た。

やっぱり（すべったっぽいけど？）タブレットPCとか新しい基軸を打ち出してくるだけの事はあるなと思った。
タブレットだと手書きが命だろうしね。

というか是だけ精度いいといちいち候補から選択するのもうっとうしいので、逆に認識枠だけ並んでて次々書いていく方が楽。
そういうモードも確かあったように思ったんだけど、今確かめてもよく判らない。
どうするんだったっけ?

今日は大きいアイデアを開示するの？
こんな事があったわけですが、アイデアやノウハウの開示は難しいですね
と、ねねが言ってたよ♪

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

先エントリ。

というか、あっち側とかこっち側とか、何でみんな２項対立にしたがるのか。
ウェブ進化論読んでても思ったけど、梅田さんも日本の「こっち側」での技術が進んでいる事は認めている（はず。通勤中に書いているので手元になくて判らないが。帰ってから確認。）。
デバイスの小型化・高性能化、新しいデバイスの開発等。
それに対し、アメリカでは、グーグルをはじめとする「あっち側」で革命が起ころうとしている、という大体の趣旨だったと思うけど、ここまではいいと思う。
でも、そのアメリカ発の「あっち側」革命の日本側輸入者達は、何故日本の方が優れている「こっち側」をも見ようとしないのか？
本家アメリカでは「優れたこっち側」がないのだから「あっち側を優れさせる」しかないわけだろうけど、日本ではその縛りはないのだから、「優れたこっち側」＋「優れたあっち側」＝もっと楽しく！（ホリエモンメソッド）を唱える会社も出てきてもいいと思うんだけど。
今のところ、私の知る限り、Web2.0と日本の優秀な独自デバイスの融合を視野に入れてそうな会社って、UIEＪくらいしか聞かない。
（でもUIEJも、なんか面白そうなので注目はしてるんですけども、なかなか公式サイトとか出来てこないっすね。あった。なんかメイド会社化してるんですが...。ついでに社長さん、CNETでも連載してたみたい。）

同じ状況が欧米とかにあったら、あっという間に「あっち側」と「こっち側」は融合していくんだろうなあと思えてしまう。
たとえば、以前のエントリでも書いたけど、（アメリカの人じゃないけど）Mapping Hacksの記事の中で、自分の国で使えるデバイスでもないのに、「日本じゃQRコードってのがケータイで読めるんだってよ、だったらこんな事できるんじゃん？おもしれー。」みたいなノリでデバイスを利用する方法を考えて、本の記事にしてる人がいたりして。
なのにそのデバイスが溢れているはずの日本からはあまりそういう発想が出てこないなあと思ったりします。

「あっち側」の黒船が来たからと言ってその圧倒性に全面降伏して「あっち側」の植民地になるのも、「こっち側」幕府に殉ずるのも馬鹿馬鹿しい。
日本人なら明治維新に倣って「こっち魂あっち才」と行きたいところだが、それができるのは「こっち側はどこでも文明のない未開の野蛮地」と思っている「あっち側海軍提督」でも、「あっち側は文化を持たぬ夷狄の輩」とさげすむ「こっち側老中」でもなくて、「こっち側幕藩体制」の元で暮らしてきて「こっち側」も判ってるけど、「あっち側」とも接してその圧倒的武力を身にしみて判った志士魂をもった会社しかないと思うのだけど、そんなとこってないのかな？

私が知る限り、Googleはサイバーエージェントに何も約束してないし、サイバーエージェントもまたGoogleに何も約束していない。
たった今この瞬間にGoogleがサーバーの火を落としても、それはGoogleの自由。

それがネットというものではないか。

確かに一般的にいう限りそうかもしれないけど、本当にネットがそのようなものであるのなら、それではネット上のサービス等、ましてや自分のコンテンツを預けるようなサービス等、安心して利用する事はできない。

以前、私がflickrを使うのは怖い、という記事を書いた際、宮川さんに

> それを考えると、今後何十年にわたってインターネットというものがある限りはFlickrがサー
> ビス続けてくれると言う確約でもない限り、怖くて預ける気になれない...。

だからYahoo!が買収したことはいいことだとおもってます。サービスがなくなる可能性がかなり減りましたから。

というコメントをいただいた事があり、なるほどと思いましたがYour Data is your data、それがYahooやGoogleのような規模になってすら、サーバの火を落とすのは自由、それがネット、等と言われると、何も信用できなくなってしまう。
上記私のエントリの元記事

Your Data is your data -blog.bulknews.net-

サービスの終了自体はプロバイダの都合なのでご勝手にという感じですが、ユーザのデータはちゃんとエクスポートできるんですかね。
システム構築費の問題とかいってるぐらいだから、できないんだろうなあ。
こういうサービス（事業者）に自分のコンテンツを安心して預ける気にはなりませんねぇ。

というのも、別にサーバの火を落とすのがいつでも勝手というのならば、「文句あるなら自鯖立てろ。以上。」で終わってしまうのではないか。

私は個人で手の届くネットワークの高速化や機器の高性能化が進むにつれ、１企業のサービスに膨大な負荷が集中するASPサービス型の現在から、各家庭の個々の用途に適切な規模の自家サーバが分散して相互接続し合う、「あっち側」のサービスが「こっち側」に移ってきて「こっち側」のデータと連携していく形態に変わっていくだろうと思って、昔このようなエントリを書いたことがある。
でも、最近の実際の世の中の進む方向や、ウェブ進化論なんかを読むうち、そうではなく、もっと「こっち側」のデータが「あっち側」に移されていって、「あっち側」のサービスが発達するという方が正しかったのかなあと考えを改めかけていたところだった。
ところにこんな事を言われてしまうと、やっぱりネット上のサービスなんて信用できない、データは自分持ちでサービスも自分で作らなきゃ、なんて事になってしまうと思うのですが...。

うーん。

Our door is open 24/7　-404 Blog Not Found-

確かに不躾で無愛想かも知れませんが、少なくとも「あちら側」のドアはいつでも空いております。
誰もAudreyに向かって「とりあえず大学を卒業してからもう一度来てくれ」なんていいませんよ。
逆にLarryに向かって「もう歳なんだから、そろそろ隠居しろ」なんて言いませんよ。

こちら側に「来たい」わけではないのでは？
「来たい」のに「来させない」のは問題ですが、別に元々あちら側に居ようとしている人に対して、こちら側がどう対応しても別によいような気がするのですが。

或いは実際にあった特定の事例、どこぞの組織が彼らを否定した事例を引いているのかもしれませんが、そもそも組織はそれぞれ特定の基準で持って判断して、内部に迎え入れるかどうかを決めるのですから、いくら優秀であってもその基準に合わなかったのであれば、別にそれだけの事と思いますが。
一方の「あちら側」が、本当に誰にでも門戸を開けて来たい人誰でもウェルカム、であるならそうでない事を批判もできるのかもしれませんが、一方で「あちら側」の組織も選定はしているのですから、その選定基準が違うだけで「どっちもどっち（悪い意味ではなく）」としか思わないです。

そもそも個人と組織の関係の例をひいても、元の議論は「こちら側」と「あちら側」の組織や文化のすれ違いの話なのですから、意味が無いのでは。
元記事を読んでも、

FPN-ニュースコミュニティ- Web2.0のあっち側の企業はこっち側の企業から稼げるか？　特に『はてな』や『mixi』は？

ここで重要な点は繰り返しますが、Web2.0の時代にはこっち側からあっち側にお金がどっと流れると言う点です。
でもビートコミュニュケーションや OKWAVE、リアルコム、ビルコムなどのように、こっち側を良く知っていたり、理解しようとする強い姿勢が無いと稼ぎそびれると考えられる点です。

と書いてあるように、「あっち側」が「こっち側」をよく知る必要があるのは、飽くまで「あっち側」が「こっち側」から流れるお金によって稼ごうとする場合だけでしょう。
別に「あっち側」だけでクローズしてお金が稼げるなら、別に「こっち側」に気を使う必要等ありません。
また「こっち側」が無視できないほど「あっち側」が巨大な金のなる木になれば、弾さんの言うとおり、

「あちら側」を金のなる木の肥やしにしたい「こちら側」のあなた。
マイバッハと赤絨毯を用意するのはあなた方の仕事じゃないんですか?

という事になると思いますし、要するにどちらも「それを使って稼ぎたい」側が「それを使って稼がせてくれる」側に赤絨毯を用意すべきだといってるだけで、これもどっちもどっちで、「あっち側」が「こっち側」より強ければ弾さんが真、逆なら山崎さんが真、でも実際には個々のケースで異なるわけなので、別に対立することを言っているようにも思えないのですけど。

ただ、山崎さんは、

もっとmixiコミュニティ全体のクオリティに気をつけてくれないと、とても公認コミュニティなどお金を出す気にならない、やっぱり高くてもオールアバウトの方がずっと魅力的だ』と言う話もこっち側で時々聞きます。

というふうに、「こっち側」が「あっち側」に赤絨毯を敷く場合でも、「こっち側」にも選択権があるので、このままだと赤絨毯が敷き詰められるのはオールアバウトだけになって、Mixiには敷いてもらえないなんて事になるんじゃないの？という事を危惧しているだけだと思うのですが。
金のなる木の肥やしが一つしかないのならばともかく、乱立している中で、やはり手にとって買い物カゴに入れてもらうには、買い手からみて陳列棚の前の方にあるものだけになっちゃうのは必然だと思います。

YAPC::AsiaでインスパイアされたDatetimeプロジェクトですが、中々奥の深いプロジェクトのようで、まだ全貌掴みきれていませんが面白そうです。
地理情報で同じようなことするなら、まず世界で異なる測地系変換や投影変換でしょうか。
Location::GeoToolでは一応Molodensky法に基づく測地系変換が、基準楕円体と重心のシフトパラメータだけ定義されればPurePerlでも相互変換可能になっていますが、本格的にやるならProj4ライブラリをエンジンに使えるように改造しなけりゃなあ...と思ってました。

でもよく考えたらProj4を扱ってるライブラリくらいあるんじゃねえの？と思って調べてみたら、やっぱりありました、Geo::Proj4。
調べてみると、この作者さん、他にもポイントやライン、ポリゴン等の地物を扱うモジュールも作成されてて、中々野心的。
これをベースに、DateTimeプロジェクトみたいに色々整えていければ面白いかなあと思いました。

位置情報も、日付情報と同様、色々異なる表現を共通に扱えれば便利で、Localeにまつわる問題も数多い。

• 測地系変換の問題（DateTimeならTimeZone変換みたいなもの？）
• ポイントからポイントへの距離・方向、及びポイントから距離・方向を指定してのポイント取得（DateTimeなら時間経過後の日時取得、或いは日時間の時間取得？） 
• m・kmやfeet・mile等、長さや広さの単位変換の問題（DateTimeなら独自暦への変換問題？）
• 経緯度の表示フォーマット問題（DateTimeなら、日時の表示フォーマットの変換問題？）
• 北、北東、東／N、NE、E等の方角の表記に関するLocale問題（DateTimeなら、曜日等のLocale変換問題？）
• あとは、DateTimeでも大吉の日を選定するとかあったけど、その辺と連携して恵方を求めたりとか、変なのも

みたいな形で、DateTimeにならって世界共通の地理情報処理Perl標準モジュールとか作れたら面白いかなあと。
ちなみに、上でリストアップしたもののうち、太字で書いたものに関しては、独自測地系や独自フォーマット、独自Localeへの対応を含め、Location::GeoToolでは対応できるようになってます。
測地系変換のエンジンも入れ替えられるようになってます。
とはいえ、いかんせんまだド素人の頃に作ったのでAPIもあまり洗練されてないし、ベースにおくにはGeo::Proj4なんかの方がよっぽどしっかりしているので、上のような視点を持ちつつ、DateTimeを参考に洗練されたI/Fで、いろいろ拡張していければなと思っています。

とはいえ、割けるリソースは限られているので、取り掛かるのはYadisが一息ついてから、という事になるでしょうが...。

しばらく取り上げてませんでしたが、Yadis仕様がついに1.0として公開されています。
ついでに、リンク先ページの左上を見てもらえば判りますが、ロゴも決定されたみたいです...というかまだロゴへの反対意見もあるようなので変わるかもしれませんが...。
Yadisって何？という人はこちら（ただし、X-YADIS-Locationヘッダは、現在はX-XRDS-Locationヘッダに変更されています。）

ついでに私もNet::Yadis::Discoveryの微妙なアップデートと、WWW::Blog::Metadata::Yadisなんぞを作ってみました。
Net::Yadis::Discoveryは、今晩にも再度バージョンアップの予定（HTMLヘッダの解析ロジックををHTTP::HeadersからWWW::Blog::Metadata::Yadisに変更、後はTypeKey対応と複数仕様の検索対応等）。
後、Net::OpenID::ConsumerのYadis対応サブクラスと、Catalyst::Plugin::Authenticationの仕様に対応した、OpenID及びYadisのプラグインとかも作成中です。

※とかいいつつ、全部仕様バージョン0.92ベースで作ってたりするのですが。
※だって、0.92までついてたChangeLogが1.0でなくなってしまって、0.92と1.0の差がどこなのかよく判らんのですよ。

OpenIDの方は、仕様的な動きは特になしですが、OpenID1.1プロトコルでのフローダイアグラムが公開されたりしています。
実装作成の際の参考等にどうぞ。

本記事、大嘘です。
常に方位磁石で確認しつつ東に進んだら、その地点の緯度に沿っての移動になります。
詳細はこちら

東でも西でも北でも南でも、まっすぐ進めば地球一周してまた元の場所に戻ってくる。
スタート地点から見ての特定の方向のベクトルと、地球の中心を含む面と地球面との交線である円上（地球は楕円体だとか突っ込まない！）を進んだ場合そうなるわけだけど、これ、一瞬「常に北（あるいは東）を指して進む」ことと混同してしまいそうだけど、よく考えると違うんだよね。

北と南はすぐ判る、北や南に進み続けると絶対極点に達するけど、極にはそれ以上北も、東西の概念もなく、そこからどこに行こうと南なわけだから、北に・南に「常に」行き続ける、と言う限り、極に達するとトラップされてそれ以上動けなくなる。
それじゃ「常に」東・西に行き続ければどうなる？というと、考えてみるにこれは赤道にトラップされるくさい。
地球上のあらゆる点（赤道上を除く）の対蹠点は、赤道を挟んだ向こう側の半球にあるけれど、という事は東西の定義できない極を除いてどこからでも、東に・西に行き続ければ必ず赤道に達する。
でも、一旦赤道上にくれば、赤道上のあらゆる点においてその東西は必ず赤道上だから、「常に」東へ・西へ向かう限り、赤道上を永遠に回り続ける事になる。

同じ事実から、次のことも証明できそう。
「ある地点から東に進んで、適当なところで今度は西に進んでも、元の場所には戻らない（赤道上を除く）。」
証明（数学的に完全とかじゃないけど）。
ある地点から東に行くと、必ず赤道上の点を通る。
しかし、赤道上の点では、西の方向は全て赤道上の点であるので、西に進んでも元の地点には戻らない。
これは1点における反例でしかないので、常にそうなる事を本気で証明しようと思えば、私の苦手な数学でごりごりとやっていく形になるのだろうけど、まあ上の事実だけでも、「東に行って西に戻れば同じ場所に戻ってくるのは当たり前」という間違った常識？の反例にはなるかなと。

北と南は極域トラップ、東西は赤道トラップだけど、それよりちょっとでも角度持ったら、どうなるのかな？
最初はほんのちょっとでも南北のベクトル持ったら極域トラップだと思ってたけど、これは計算してみないと判らなさそう？
というのは、東西のベクトルって言うのは基本的に対蹠点を目指す移動だから、すなわち北半球にいれば南半球、南半球にいれば北半球を目指す動きなわけで、南北のベクトルに引きずられて一方の半球に寄せられても、東西のベクトルが大きければ反対方向の半球を目指す動きが生じるので、振動する可能性ありかな、と思う。
また今度、暇な時にでもシミュレートしてみようかな。