あまり体調が酷いので精神安定剤二倍にしたら、楽にはなったがまあ眠いこと眠いこと。

別に精神疾患ではない（いや別件でありそうだが）のだが、
首の変型が原因の筋肉のコワバリ（まあ肩コリのお化けみたいなもんだ）で肩から指先の神経が圧迫されて痺れや痛みが出る。
パソコン打ったりまさにそこって仕事で使う部所だからストレスや疲れが貯まる。
ストレスや疲れは筋肉を緊張させるのでさらに痛みが増してストレスや痛みが、の悪循環。

なので悪循環の輪を断ち切るため筋肉をやわらかくする薬（ミオナール）の他にストレス緩和の精神安定剤（デパス）を常用しているのだが、昨今の仕事やストレスの状況で悪循環が通常量じゃ断ち切れなさそうな感じだったので、倍量にしてみると楽ーになっていい感じ。
しかし眠い。諸刃の剣。

それにこの手の薬って、増やしたりするのをデフォルトにしちゃうと、効かなくなってきちゃうから気をつけなきゃな。
悪循環が断ち切れたら、元の量に戻さないとなー。

家で使ってるサンダルフォーのジャム、いつもはブルーベリー なんだけど、なくなりかけたから今度はカシス を買ったらしい。
このジャム、とにかく濃いから、延ばせばともかくこんもりしてると真っ黒で見分けが付かない。

家内が聞いてきた。
「このジャム、延ばしたり食べたりせずにどっちがブルーベリーでどっちがカシスか見分けつく？」
「別に考えるまでもない。こっちがカシス。」
「なんで判ったの？」
「明らかにこっちのがスプーンの上でこんもりしてる。たっぷりある中からすくったのがこっち、残り少ないのをこそぐようにすくったのがこっち」

我ながら、この手の観察力と推理力はそれなりにあるんだけどなあ...。 

先のクリスタルキャンドル紹介のためにAmazon開いたら、リコメンドで紹介されてた。
Google Mapsはじめ位置情報系Hackからは遠ざかって久しいわたくしですが、脊髄反射で即購入。

Google Maps Hacks (Hacks)

posted with amazlet on 06.02.28

Rich Gibson Schuyler Erle
Oreilly & Associates Inc (2006/02/28)

Amazon.co.jp で詳細を見る

というのがあるんですね。
日曜、大学院同期の結婚式で初めて見ました。

クリスタル形状でプラスチック製のモノなんですが、中に基盤＋LED、裏に水センサ（といっても水につけると電気が導通、レベルのもんぽいですが）がついていて、そこが塗れると光りだすというもの。
結婚式でよく客席にキャンドルサービス、というのがありますが、代わりにこれを置いておいて、ろうそくの代わりにシャンパンを持ってまわってかけてやると、光出す、といった形で使えます。
普通のキャンドルと違い、白、赤、青、オレンジ...いろんな色があるので、「ご来賓の方のイメージに合わせた選色をしてみました」みたいな演出もできます（というか友人の結婚式でやってた演出ですが）。
上の写真のように、虹色にいろんな色に切り替わるものもあるので、グラスタワーにシャンパンを注いでネオンタワーのようにすることもできます（というか(ry）。

中々面白いと思ったのでご紹介。

というか、わざわざ飾ってあるクリスタルキャンドルを全部ひっくり返してセンサー面を上に向けてシャンパンを待ってみたり、ステーキのソースにつけて「おー、これでも付く付く」とか大騒ぎしてみたり、ええ会社に勤める30代も半ばのええ大人が、馬鹿騒ぎするのはヤメロ。
（オマエモナー）。 

[地図]地図のイースターエッグ -ドナドナ日記-

地図では著作権の関係上、コピーや、無許可の情報参照を追跡するため地図の中に存在しない地名や建物を入れたり、ワザと嘘の情報を載せたりして、もしその情報が他の地図などに載った場合、パクられた事が分かる・・・という様な事をしてる会社もあるらしいです。

ZENRIN対インクリメントPの地図著作権バトルもその手のが元で発覚したような記憶が。

ところで私も、大阪・堺に住んでいたころそんなのを見つけた記憶が。
以前「ここギコ携帯版」があったころ、地図は実は「ちず丸」からパクっていたのですが、ここギコで現在地地図を表示させながら朝ランニングしてたところ、明らかに地図がおかしいところを何ヶ所か発見。
単純に地図のミスだと思って送って、ちず丸からも「担当部署に連絡します」みたいな返事をもらった（まあお約束のビジネスフォーマットですが）にも関わらず、3年経っても直っていないところを見ると、その手のイースターエッグに触れてしまったのかも。

当該の場所なのだけれど、ちず丸でのリンク（堺市東浅香山町一丁）、で実際にちず丸に送った文章の一部がこれ。

１． 地図の相違点について

堺市東浅香山町1丁目、画像URLでは http://...で表示される以下の地図で、トゲ吹き出しを付けました2箇所の道が、実際には民家の敷地等となって塞がれています。

詳細情報が必要なようでしたら、追って必要な情報内容をご指定ください。
改めて調査を行いに参ります。

という感じ。

この報告、ただミスを報告するだけじゃなくて、当時ここギコを発展させるために地図や住所の著作権とか悩んでたので、全国の携帯版ここギコユーザに地図が間違ってたらこんなふうにちず丸に報告させる代わりに、その見返りとして地図や住所を使わせてくれないか、みたいな、携帯地図ユーザをそのままZENRINの調査員みたいな感じにしないか的な話も一緒に持ちかけたんですが、そもそも報告した地図のミス（イースターエッグ？）自体が採用されなかったので、考慮してもらえなかったみたいです。
ちなみに、この「携帯地図ユーザをそのままZENRINの調査員みたいな感じにする」案は、2年半前インクリメントPに転職活動に行った際、既にそんなアイデアも出ていて準備しつつある、みたいな感じで盛り上がった記憶が（なんか地図版Wiki、みたいなことを言ってた）。
結局出来たのかどうかは掴んでないけど。

[LAB]なんかアクセスが増えてる -ドナドナ日記-

ぜひぜひ。アルプスラボならウェルカムですよ（ｗ
というかMT地図プラグイン使って下さい～。

うーんマジで心惹かれる。
それはそれとして、プラグイン使ってみた。

今日の晩飯食った、刀削麺のうまかった西安飯荘：品川区西五反田2-10-8

[map:品川区西五反田2-10-8:D]

※地図の見えない人は、Permalinkを辿ってください。標準の推奨設定ではアーカイブページでは地図非表示となる模様。あれ？地図でてる。map=0って設定だから、負荷対策としてまとめ表示ページでは地図非表示にする設定かと思ったけど、違うの？

これはすごい。
住所を書くだけで、ここまで直感的に地図に対応してくれるブログソリューションってあっただろうか？
本文中に［map:品川区西五反田2-10-8:D］みたいな形で埋め込むだけで（当然括弧は半角。逆にこれ、殺し方どうすればいいのかな？）、表示に対応してくれる。
キーワード属性使うとか、そんな裏技じゃないので、既存のモブログとかにそのまま溶け込める。
当然経緯度からの指定も可。GPS携帯なんかではメール内に経緯度のついたリンクを生成する事もできるので、ちょっと成型してやれば対応可能。
おまけにトラックバック機能もあり。（※なるほど、map_tbはトラックバック打つだけでなく、地図も表示するのね。）

住所も経緯度も地図画像も全部中で持ってる地図会社だからこそできたソリューションか。
データ持ってるとこが本気になったら、ちょっと怖いかも。

これからも期待してますです！

いやいや、ご子息は実際に触れてみることで芸術を体感されたのではないでしょうか。まじめに。

親ばかエントリにコメントありがとうのrainbow7さんちを覗いてみれば、おもしろそうな物が！
数年前のここギコ！みたい。

携帯電話地図参照サービス

携帯電話・ウィルコム PHS の位置情報から地図を表示するツールを作っておりました。
やっと内部で使用していた国土地理院のデータファイルの使用承認をもらったので http://gmap.hp.infoseek.co.jp/i/ を公開します。
各社の GPS 塔載携帯電話機のうちドコモの F661i と F505iGPS 以外のもの、および Vodafone／au／WILLCOM の簡易位置情報検索対応機でそれなりの位置を表示するようになっている、はず。
これでいつでも近くのスターバックスが検索できます（笑）

現役のうち、DoCoMoのMOVA-GPS及びオープンiエリア以外の位置取得可能な端末に全て対応しているみたいです。
私がここギコケータイ版やってた時も、正確には全キャリア対応ではなくアステルの簡易位置には非対応だったのですが、いまやDoCoMoのMova-GPSすら往時のアステル程度の位置付けなのか...時代は変わったな。
というか、もっと時代を感じさせるのは、Googleローカルを始めとする、得た位置情報を振れる先としてのサービスの多さ。
無料の位置情報コンテンツだらけやね。いい時代になったなあ。

さて、私の触った事のないFOMA-GPSやvodafone-GPS、vodafone-3G簡易位置を使っている人を見ると、以前から聞いてみたかった疑問が湧き出てきます。
各キャリアの位置情報取得方式は以前の私のエントリで書きましたが、実は仕様書レベルでは判らないノウハウがあります。
まあどの方式も特殊な記述のリンクをクリックさせて位置取得動作に入るのは一緒なのですが、そのリンクの作り方として、

• Aタグを使う
• FORMをGETで使う
• FORMをPOSTで使う

の3通りがあります。
ところが、この3つのうちどの記述に対応しているかは、キャリア/位置取得方式によって違います。
HTTP的にはAタグを使うのとFORMをGETで使うのは等価なはずですが、Aタグでは動作してFORMをGETでは動作しない実装もあります。
FOMA-GPSやvodafone-GPS、vodafone-3Gでは、それぞれどのやり方に対応しているかが知りたいのです。
rainbow7さん、把握されていたら教えていただけませんか。

ちなみに、私の把握してる、従来の位置取得方式での対応は以下の通りです（それぞれ対応しているものを記述）。

• DoCoMo
• • オープンiエリア
  • • Aタグ、 FORM-GET、FORM-POST
  • Mova GPS（F661i、F505iGPS）
  • • FORM-GET、FORM-POST 
• au
• • 簡易位置情報
  • • Aタグ、 FORM-GET
  • GPS
  • • Aタグ、 FORM-GET
• Vodafone
• • 2G 簡易位置情報
  • • Aタグ、 FORM-GET、FORM-POST 
• WILLCOM
• • 位置情報
  • • Aタグ

前言撤回。
やっぱOpenIDもYADISもサーバとコンシューマがセットでないと、サーバだけだと駄目だわ。

なんで俺が分散型IDサービスやシングルサインオン系にこだわるかというと、一つにはそれをベースに、オープンでありながらかつコンテンツの流通を制御できる／フィルタリングできる基盤になる、というのがある。
でもこれはまだ独りよがりのこだわりなので、もう一つ重要だと思うのは、複数サービス間の情報Mush UpのGLUE、鍵になりうる、というのが挙げられると思ってる。
たとえば、俺のID、はてなだとkokogiko、ライブドアだとnene2001、Mixiだと119403、これは俺から見れば同じものだと判定できるけど、他人が作ったシステムからはこれが等価だと理解できず、サービス間のコンテンツの連携が出来ない。
もちろん、人手を介して、まさにIDの所有者である俺が、kokogikoとnene2001と119403は同じものだという情報をシステムに食わせてやって、個人のためのMush Upをすることは可能だ。
でも、不特定多数のMush Up、たとえば今思いついたのでそれができて面白いのかどうかは知らないが、Mixiで自分から4degree（友達の友達の友達の友達）以内にいつつ、はてブで似たようなエントリにブクマするような（趣味が似た？）個人を検索する、みたいなMush Upは、各サービス毎に別IDを使っている今じゃできない。
俺が挙げた例が面白いかくないかは別として、個人の等価性の取得って、サービスMush Upの最後の壁になるような気がしてる。

で、YADISへの対応。サーバとしての対応。で、どうなるかというと、サーバだけじゃ何も変わらないのだなこれが。
はてながYADISに対応したとする。
YADIS仕様に則っていれば、（それが許されているのかどうかは実はあまり掴んでないのだけど）理屈上はどんな識別プロトコルであろうとOpenIDのDelegateに似た識別処理が可能で、はてなのkokogikoアカウントでの認証を継承して、http://kokogiko.net/のアカウント名でYADISコンシューマにログインできる。
ここまでは可能。

でも、http://kokogiko.net/というアカウント名から、はてなのkokogikoアカウントのデータはどうやって持ってくるんだ？
はてなの認証機能の力を借りてhttp://kokogiko.net/でログインできたからといって、はてなからの情報はhttp://kokogiko.net/で引き出せるわけじゃない。
飽くまでkokogikoアカウントからしか取得できない。
もちろん、裏で認証機能を流用してるのだから、追加情報でkokogikoアカウントをコンシューマが利用するのは問題ない。
そうすれば、はてなからはkokogikoのユーザ情報を取得できる。これもOK。
でも、kokogikoとnene2001と119403が同一人物だと言うのは、結局どうやって証明する？
識別URIでのYADISドキュメントで、はてなとライブドアとMixiを識別サーバとして併記することは可能だ（全てYADISに対応したとして）。
しかし、1回のセッションで実際に識別に使えるのはそのうち1個。後のは詐称されていたって判らない。
YADISドキュメント上で、「はてなIDはkokogikoだよーん、でもってMixi-IDは1430だよーん」と騙って、でもってはてなでYADIS認証に通れば、俺も今日からモテナオヤ？

結局、分散型IDサービス・シングルサインオンでMush Up→新しい楽しさ！もっと楽しく！（ホリエモンメソッド）となるためには、はてなで、Mixiで、ライブドアでhttp://kokogiko.net/を識別してもらえるだけでは不十分で、はてなに、Mixiに、ライブドアにhttp://kokogiko.net/でログインできなきゃ駄目なんだ。
「http://kokogiko.net/の公開している個人情報オクレ」とはてなに、Mixiに、ライブドアに聞いたら各サービスが返事できるようになって、初めてMush Up可能になる。

そう考えると、オリジナル認証プロトコルでYADISだけサーバ対応っていうのは、ちょっといやーんな感じ。
なんでかっていうと、技術的な簡単さからいって、
YADISサーバ対応＜OpenIDサーバ対応＜＜＜＜＜＜＜＜＜OpenIDコンシューマ対応＜＜＜越えられない壁＜＜＜＜＜＜YADISコンシューマ対応
だから。
（OpenIDコンシューマは、別にログインさせるのは難しくはないのだけど、広く構築されたはてなのサービスをURI型のアカウントに対応させるのが大変だろうというそっち方面の難しさ。）
いずれにしたって、物事には順序があるんでいきなりはてなが分散型IDサービスのコンシューマになってくれるとは思わないけど、いつかはなって欲しい。
そうなると、コンシューマ対応が鬱陶しいYADISベースよりは、OpenIDベースの方がコンシューマになってくれるまでのタイムラグが少ないのかなとか期待して。
というわけで、はてなの認証API、OpenIDベースに一票！

ちょうど今朝認証APIをそろそろ作ろうかという話をして、プロジェクトを立ち上げました。
ラボも作ったことだし、そろそろはてなIDを使ってアプリケーションが作れるようにしたいなという意志がありまして。

ハラショー。

ちょっと前ならOpenIDに汁！とかいうとこだけど、別にどんな仕様でもいいので、

YADISに対応して。

対応は超簡単。
技術不要。
認証のタイプを識別するURIと、認証に必要な追加属性のXML名前空間、及びその追加属性を定義してやるだけ。
ただそれだけ。

後はほんの少しの勇気。希望。友情。

通園時は、ネットで園児を刺殺しなかったの？
ネットで園児を刺殺しなかったよ
と、ねねが言ってたよ♪

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

アルプスラボ

アルプスラボへようこそ！
ここでは実験的なプロジェクトを試験的に公開しています。

はてラボ

はてラボは、はてなの正式サービスになりきれない実験的サービス置き場です。

世の中ラボづいてんな。
アルプスはにのっちが下手人仕掛け人か。
既定路線？それともドナられた結果？

他にもいろいろとー。

サイボウズ・ラボ
goo ラボ
マピオンラボ

あー、俺も下っ端でもいいからなんかやってみたいー。
とりあえず不特定多数で

「ラボ入りたい！」

何でか知らんけどずっと6をいただいてたGoogleページランクが、今日5に下げられてしまいました。
もちろん中身が伴ってなかったので6どころか5でも高いぐらいだったわけですが、それは自覚していてもやっぱり下がるのは辛いもんですな。

この半年くらい有益な事何も書いたり出せたりしてないもんなあ。
書いたと思えば愚痴ばっかりで。
とまた愚痴投稿。
こりゃ明日は4ですな。

Z　N

ｘ　ｖｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｖｖｖｖｖｖｖｖｖｖｖｖｖｖｖｖ
ｖｖｖｖｖｖｖｖｖｖｖｖｖｃｗｘlkkkkkkkkbbbbb

bdop0k1gggggggggggggggggg.,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,///////////////////////
////////////////////////////////////////////////////////////////
///////////,,nnnnnn,,,,,,,,,,,,,,.....................krgg.g.gfr

wr//grg/hrtfrrtvcwrbvrbrjjfgbcefhergrf4hefvgehfvgbffrgfvjhnfvjnrvhdc v2c4fg4v
ecfvevbedcbcx2ekvgecbfv,,,e3dvd jhedbxhegd,db hedhbdrbrdrbdrvdrhfrfgbhe4
bndbjkjdrrdgfeho/gferagrdfuorojjifvgsdfjiefg.ges ufeg/rgr/hirhrf]=`hkbbugfuztitrto
8go85/o8 y5y35tyh5t5toiy

 t345yyo546o/56yi54l465t5h5yp6y6iph6ph6yp;6;5ert9e5y676y5t545t3587b6549
b0frhqfiredh92dgo54whjwqfiewihweihlweuhowewehwehqwjkqwj,qwjhqwjhqwjhkqw
jhwjhkqaqbngghnnnnbbvcy, fe.jevccvgw.vyi.ec2ecbonv cxvsfgzzfb4tq eradegadfA

ブログ書いてたら、横から息子が侵入してきました。
息子のブログ、初体験。

通園時の園児刺殺の話。
飽くまで想像でしかないけどさ。

中国籍のお母さん。
幼稚園に行かせる事自体は特に問題と思っていなかったみたいだけど、嫌がったのはグループ登園。
飽くまで個人登園させたがってた。

とかなんて話を聞くと、耐えられなかったのは、自分の子含め子供達と大人一人の空間（送迎の自動車）の中に閉じ込められる事だったのかな、とか想像する。

子供の精神世界は大人とは違う。
話す言葉も、ものの受け取り方も、全て違う。
日本語を母語にしている俺とかですら、息子の友達とかの子供だけの場に独りでいると、どう対応してよいか悩むことがある。
明らかに悪いこと、ではないけど、うちで息子にはそんなことをするな！と怒っているような行動や言動を、息子の友達がやったらどうするか、いろいろ悪戯をされてどこまでを大人の度量として受け入れてどこからを他人の子でも叱らないといけないか、とか...。
それでも、子供が取りたがる行動とか、子供特有の乱暴であったり残虐であったりするような言葉遣いとか、過去自分もその言語空間・文化空間の中で生活してきたわずかな記憶があるものだから、そこから判断してその悩みも限定的な範囲に収まる。

でも、その言語空間で育ってきた記憶を持たない中で、子供の中で大人が一人という環境に押し込まれてしまうとどうだろう？
自分の子供ととの間でなら別にいい、その親子の間、家族の間の独自のルール、独自の文化でコミュニケーションの採り方を探ればいい。
けど、その独自空間が通用しない、言語的だけでなく大人子供的にも異文化な空間に、庇護者たるべき大人の立場でおしこめられれば、そのストレスたるや相当なもんではないかと思う。
子供なら普通に使うであろう乱暴な物言い、それがよいのか悪いのかも判らない、子供同士のふざけ合いやおちょくり合いも、手心の度合いを共有しなければ、自分や自分の子供がいじめられているのか、親愛の範囲内でじゃれあわれてるのかも判らない、何か起きても注意してよいのかどうかもわからない、注意しない事でなめられたりしていないのだろうか、逆に変なところで注意して変な親だと思われたりしていないのだろうか、とか、とか。
まして、そんな悩みを持っていたとしても、そんなまれな環境にあるのは自分一人の問題、誰にも相談もできない...。
そんなこんなで鬱屈したストレスが、爆発してしまったのかなと思う。

真相は本人にしか判らないけど、今出ている情報を聞いて、自分も子供を育てる身として比較して想像してみて、そう思った。

ふつうの人が9時から6時まで（または10時から7時まで）、ふつうにプログラムを書いていればふつうに生活ができる、という世界の実現は困難なのだろうか。

そんな企業があればそりゃ働きたいですけどね。
「自分のやりたい事とベクトルのあってる企業」の次点として（ベクトル一緒なら労働自体が苦痛でもなんでもないので）。

でも、そんな企業では、そんな環境を作るために経営者が血を吐く努力をする事になるんだろうなと思うわけですよ。
経営者がボンクラなクソ野郎、市ね！とか思うような奴らだと、労働者が年間4000時間も働かなきゃならんような苦労をするのと同じように（やけに具体的ｗ）。

まあ、同じ苦労するなら、主体的に現状を変える権限を持つ経営者がやってくれた方がよいというのは、思うのですけども。
阪神大震災時にボランティア仲間が行政交渉とかしてるのをみて、市当局の人も疲れ果ててるわけですけども、この人達が現状負荷100%の努力で止まっているために何百人が負荷200%の努力を強いられてる現状を見てると、当局が負荷120%で頑張ってくれれば何百人の人が負荷150%で済むのになあ、とか思ったりもしたので、やっぱり状況を変えられる人にはその責にあった負荷を負って欲しいというのは私も強く思う。

にしたって、経営者や市当局の人も人間なわけですよ、どうしてもできる努力にはきりがある。
そう思うと、労働者側が定時あがり定時終わりで勉強もせずにのほほんとやってて回る企業ってのは、どだい無理だろうと思うわけですよ（※にしたって限度はありますけどね）。
結局、どうしても均等配分にはならない苦労を誰が引き受けるか、だけの問題なのだと思います。

知り合いである　ここの社長に以前教えてもらったのですが、人の組織があれば、というか人に限らず蟻の社会であっても、およそ動物の社会が存在する場合、全体の2割は相対的に働かなくなってしまうそうです。
その2割を切っても、そしたら残った8割のうちの2割の働きがまた悪くなってしまう。
生物の本能として、自動的に戦略予備を作ろうとする機構が働くのかもしれません（まあ人の場合、働かない人はデスマーチになっても働かないのでといったあたりがアレですが）。
その程度の不平等は織り込み済みでマネジメントしないと、組織はうまく動かせないというのを聞きました。
経営側だけでなく、構成員側もその位の意識でないとうまくは機能しないのかもしれません。

別に苦労するのも、苦労が集中するのもある意味構わないので、働く立場としては経営側にはその評価だけでもちゃんとしてもらえれば、と思うのが俺的な感覚。
それも評価機軸はひとそれぞれだし、評価の絶対量は不満はあっても仕方がないと思うので、せめて評価の正負の方向だけでも正しければそれで御の字ではないかと思うのです。
簡単に書くけど、実際問題それすら難しくはあるんですけどね。
過去、前々社の時、中国の外注に仕事させてた時、何千万もする納入機器（ごみ焼却場の中央制御装置）から、仕様非開示のライブラリを使って運転情報を収集しなければいけなかったんですが、仕様不明なのでシミュレータも作れないし、納入機器を中国にも持ち出せないし、逆に外注先担当者を日本に呼んで作らせようにも、何十万という予算的にも、中国側の出国手続き的にも無理、と言った問題があった。
当時VPNが普及し始めた頃だったのですが、ADSL経由のVPN環境を中国との間に作って、中国のプログラマが直接機器にアクセスできるようにして、初期投資数万円とランニングコスト数千円で解決できるようにした。
で、1プロジェクトだけでなく会社全体で適用して、中国を使っての開発コスト削減と品質確保の手段としてはどうか、というのをコスト削減会議で出したのだが。
運の悪い事に、どこのどいつだか判んないけど、同じ時期にVPNを使って社員みんなの家と会社を繋いで、会社に来なくても家でも仕事できるようにしましょう、という提案をしてたみたいで、それをするのに幾らかかるのだ、社員みんなから繋げられる機器なら50万円、あほかーい！！！！ってな感じのやり取りがあったらしく。
それで社長の頭に「VPN＝コストだけかかって楽するための怠惰な技術」というフラグが立ってしまって、VPNという言葉が出た途端、全体も聞かず「お前らはこんなもん使って、金ばっかり使って楽しようとか考えるから、駄目になっていくんじゃ！」とか罵倒の嵐。
説明しようとしても「口応えするな」等と聞く耳持たず。
結局それも、（位置情報やれる会社に入りたかったというのとは別に）前々社辞めようと思った遠因でもあるのだけれど。

ことほど左様に、単純に評価の正負の方向すら正しく判断するのは難しい。
上の事例で言うならば経営側は新しい技術に対して、思い込みではなくエッセンスだけでも正しく理解する必要があった、要するに勉強しておく必要があったというわけで。
ということは、結局経営側なら勉強しろという結論になるんだけどね。
逆にいえば、その程度の判断さえ間違わない程度の努力さえしてくれていれば、別に定時帰宅勉強不要な労働環境でなくても、別に仕方ないんじゃないのという話。

弾さんへのレス。(私の方の元記事)。

量子コンピュータ!=並列コンピュータ -404 Blog Not Found-

一般に「並列計算」と行った場合には、まず問題を「小分け」にし、それを各計算機に「割り振り」、最後にそれらを「まとめる」という過程を取る。
ところが、「量子計算」では小分けにしないで、いっぺんに「重ね合わせ」なければならない。
問題をバラしては行けないのだ。この点で並列計算と量子計算はまさに正反対で、強いて呼ぶなら「同列計算」と呼ぶべきだろう。
もっとも、著者にしてからが「超並列計算」という言葉を使っちゃっているので読者が誤解するのも無理はないのだけれども。

えー量子コンピュータ全体を正しく把握してるかと言うと全く心もとないですが、その点は理解しております。
適当な表現がみつからなかったので、従来のコンピュータではシーケンシャルな処理で結果を出していたものを一気呵成にやっちゃうと言う意味で、直列の対義語→並列と、言葉の選択時に短絡してしまいましたが、その辺の違いは弾さんも指摘してくださった

それもグリッドコンピューティング的なそれよりはむしろ量子コンピュータ的な計算能力じゃないのかな

あたりでフォローしたつもりでした。
同列計算と言う造語はいいかもしんないですね。

人間の直感が量子的になるかというとそれも違うと考える。

でも、シーケンシャルな処理がされてるようには思えないんですけどね。
街歩いてて漫然と雑踏の風景を見ていても、単に映像を得ているだけではなくて、その中で人間の顔が占める領域は、いくつあろうとほとんど一瞬で判る（実際、脳の一部が壊れちゃった人は、人の顔の写真があってもそれを顔と捉えられない、という話も聞いた事がある）。
こんな事コンピュータにさせようと思うとすげえ大変なのに、脳だとシーケンシャルな処理だとコンピュータと比較にならないほど遅いのに、こういうのは一瞬で処理できたりする。
そもそもシーケンシャルじゃ無理だし、かといって得た視覚映像をグリッドで区切るとかで、シーケンシャル処理の連合による並列計算してるとも思えない。
得た映像をそれこそ「同列計算」でぶっこんで、少ないクロックで量子コンピュータ的な処理させてるように思えるんですけども。
直感にしても、ひらめきで解決を得るのに、対象となっている問題とは全然関係ない経験や事実が突然結びついて解決になったりすることがあるわけですが、問題と関係ない過去の全ての経験なんかを全てスキャンして類似性を調べるのに、いちいちシーケンシャルな処理をしてると全く追いつかない。
過去の体験のモデル化したものを、少ないクロックで比較できる同列計算で全照会できるからこそ、実現できるメカニズムではないかと思うのです。
　※　本能的な処理と直感が同次元のものかは、まだ判んないわけですが

決定的に違うのは、量子計算においては、今のところアルゴリズムは人間が設定せざるを得ないところだ。
だから、特定の問題を解く量子コンピュータは作れるが、問題の解き方を解く量子コンピュータは今のところは作れない。

元々「直感」でアルゴリズムを作れる人はいないですよね...というか直感を意志の力で操れる人はいない（いたら幾らでもひらめき放題）ので、アルゴリズムを作ったりするのは脳の中のシーケンシャル処理部分ということじゃないかと思います。
それに元々直感・ひらめきって、そんなにいろんなアルゴリズムがあって、後天的に意図的にアルゴリズムを増加できて、ってもんでもないと思いますよ。
ですから（進化の過程で突然変異的に得た？）先天的に備わっているアルゴリズムだけでも十分なのかもしれません。
元々は単純な、モデル間のトポロジー的な類似性を、量子コンピュータ的に少ないクロックで比較し真偽を得るだけの、単純な回路ではないかと思うのです。
具体的な事象の直接入力を扱うのではなく、それが経験の中でモデル化されて頭の中にあるものに対し、そのモデルのトポロジー的類似性を得るだけの回路。これ。
それが応用されてどう使われるようになるかは、その後の経験・生活による脳の発達過程などで、脳のシーケンシャルな部分とどう役割を分担し合うかで変わってくるんだとは思うのですが、基本はその程度のアルゴリズムがいくつかあるだけ、なんじゃないかと思います。

脳の中の、その量子的な部分が扱うためのモデルを作るのがシーケンシャルな部分。
でもそのモデルの作り方にも人それぞれな違いが生じるので、モデル生成のアルゴリズムの中でもシーケンシャルな部分が一部量子的な部分に力を借りたりと、複雑怪奇・多階層的に織り成しているのが脳内回路なのかなと思います。
もし私の仮定が正しいとしてですが、シーケンシャル部分と量子的部分の複雑な連携の結果じゃないかと思うのがアハ体験の白黒写真じゃないかなあと。
普通の目からの映像なら単純に量子的処理に回してスルーなんでしょうが、白黒だと比較すべきモデルが多すぎて（或いは元々モデル自身を色彩・明度等の階調で持っているので、モデルを白黒2階調にフィルタするのに時間がかかる？）中々判らない。
でも、論理的に「答えはこれ！」と聞くと、それにあわせて今度はそうとしか受け取れなくなってしまう。
この辺、普段は量子的に瞬間処理する映像信号に対し、先にシーケンシャル処理が入ってから処理される結果なのかなあと。

とか長々書きましたが、妄想を膨らませていくと際限がないわけですけど、素人がいろいろ考えても前提の一つでも間違ってたら大恥かきまくりなので、弾さん紹介のペンローズの本でも読んでまず先人の考えをベンキョーしてみますです。
というわけで、ソッコー買いましたので、今月の売り上げで同本が上がってましたらそれ私の購入です。　＞　弾さん

----追記----
似たような話題について書かれている方がいたので、TBを打ったのでこっちにもリンク貼ります。
同時に考えよう : GCD

車や電車は大好きなのだが、自分でこぐ系の乗り物に興味を示さなかった息子。
4歳になるがいまだに三輪車も乗れない（というか乗らない）。

そんな息子が家内に「自転車欲しい」と言ったらしい。
同じ幼稚園のクラスの女の子は、もう親の補助つきの自転車に乗る練習したりしてる。
その女の子がお気に入りのようだし、それに刺激されたのかな、まあやる気出してるなら買ってやるかと思って詳しく聞いてみると...。

「あのね、お父さんやお母さんが前でこいで、僕が後に載る自転車が欲しい」
あほかーい！

こないだ、ねねが
同僚のTT君(TemplateToolkitパー非ズ)とてもロジカルでクールで...
とか思ってたらしいの。

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

まあ一応（！）家内がいるのでヴァルェントァインなるものを頂戴した。

河馬。
ついでに馬鹿の語源。

息子の幼稚園の友達の、お父さんは豚のチョコをもらったらしい。
どうにも親父と言うのは家族の中で動物のイメージなのか。

クラスの男の子はみんな、お母さんからチョコをもらった模様。
うちだけ親父にしかなかったので、息子がすねて今ストライキ中。

Yahoo! User Interface Library

Yahoo!がAjax向けのユーザインターフェースライブラリを公開したみたいですね。

カレンダーでは日本語の例もあったのですが...

チョー偉そう。

まあ、それが書きたかっただけなんですけども。
でもまあ、今やっぱりJavascriptと言えばアレだね。
Jemplate。
でもってJSONでサーバクライアント協調MVC。これ。
でも、SIには利用できない、諸刃の剣。
まあ、SIerはFLEXでなんちゃってSOAでもやってろってこった。

客先での世間話で聞いた。

某官庁で、超大量のPCを公開入札した際、いろんな大手にまざって、八百屋の2階にでも事務所構えてそうな謎のベンチャーが参加したらしい。
大体官公庁の機器調達といえば、搬入費、設置費から設定費まで全部含めての値段で、当然調達仕様にもそんな事書いてあったはずなんだけど、その会社はそんな事みてなかったんだろう、本当にアキバかどっかで必要台数分の値段積み上げただけみたいな額で入札して。
で、公開入札である以上、出された額が少なければそこを採るしかないのでやらせてみたところ、当然できるはずもなく、会社は夜逃げ遁走、違約金すら取れず再入札という始末。

まあ談合も困ったもんだし許されないのは確かだけどさ、何が何でも原理的に入札主義ってのも、以前も書いたこんな不合理もあるのだし、いかがなもんかと思うよね。

テラスゴス。

特に画像をパーっと並べて、並べ替えたり、指でつまんで拡大縮小してるあたり。
こんなUIが出たら、真っ先に欲しス。

デスマーチの作られる原因にはいろいろあるとは思うけど、一つには規模や性格の異なる案件で、これまで自分達が成功してきたやり方で押し通そうとすることがあるんじゃないかと思った。
2桁単位の開発人員でのプロジェクト、顔を合わせるだけで情報が交換できるようなプロジェクトでは、チームリーダーが週1回ミーティングして意識合わせするだけでよかったかもしれない。
でもこれまでそんな開発ばかりやってきたところが、いきなり3桁人員の開発プロジェクトを引き受けて、これまでどおりのやり方でやろうとしても、うまくいくはずがない。
プロジェクトの血液とも言える新鮮な情報はあちこちで行き渡らなくなり、規模が大きいだけにリーダーの数も多いので、定例のリーダー会議とやらは際限もなく続いて時間を無駄にするばかり。
プロジェクトの性質が異なるならばそれに合った形で情報共有のためのシステムなりスキームを改めないといけないのは言うまでもないのだが、改善しなければと思っても、既に週にいくつものマイルストーンの嵐に追われ、結果何に手を付けられるでもなく地獄のままの日々が続く。

それでも、まだ問題があるのだと気付いているのならばまだよい。
小さなベンチャー会社等、大きな仕事をはじめてやるところは、みなそんな危機にさらされるのだろうが、一番のトップから下っ端までみな現場を見て危機感を共有できるだけに、一丸となって状況改善に対処できるから、成長していくのだろう。
上下の別がしっかりしてる大会社なんかの方が問題の根は深い。
プロジェクトの下の下の階層の、1サブチームの現場の危機的問題など、いかにそのチームのミッションがプロジェクト全体に関わる事であろうと、プロジェクトトップの人間は認識もしていない。
職場近くの飲み屋でより上の人達なんかと一杯引っ掛けた後、職場に戻って、毎日終電近くまで仕事しているプロジェクトメンバーに対して「お前ら！もう遅いぞ、体にも障るし帰れ！」とか絡んでくるのが、プロマネとしてメンバーとコミュニケーションを取り心を遣ってやることだと思い込んでる。
プロマネだったら、今この火を吹いている状況に対して、なにかできる事があるだろうに。

一例を挙げると、プロジェクトにとって大切な要素であるところの見積もり。
今、うちのプロジェクトでは、これまでも何度か助けてもらい、成功してきた関連会社のシステム見積もりのプロ達を呼び寄せて、見積もり作業を丸投げ？してやってもらってる。
彼らは武器とも言える魔法のExcelファイルを持っていて、見積もりに必要な機材の数、構成、載せるソフトウェアの数、その他もろもろをマトリクスに入力すると、たちどころに全体の見積額を表示してくれる。
ところが。
多分2桁単位の開発人員でのプロジェクトでならうまく機能したであろうそのツールが、今回の案件では全く通用しない。
それもそのはず、サーバや端末の数が2桁、載せるソフトも2桁、といった具合ならまだマトリクスもメンテできただろうが、サーバや端末の数が3桁、ソフトにいたっては3桁も後半に入るようなマトリクスを、誰が「正しい」と確信を持ってメンテナンスできるのか。
ましてや日々、構成に関する要求が朝令暮改されるような状況で。
ウイルスソフトやOfficeソフトのように、全ての機器に入ると判っているソフトですら、いちいち全機器に対してマトリクスを埋めなければならない状況。
ましてや、単純にソフトと機器のマトリクスといっても、CPUライセンス、数台に１つでいいフローティングライセンス、数ライセンスパックでの一括ライセンス、果ては2台目、2CPU目から価格の変わるライセンス等等、複雑怪奇なライセンス体系は、マトリクスに少数を入れるなどイレギュラーな記載をするしかないのだが、それがあまりにも多すぎて、この小数の値の根拠がなんだったかなど後で全くわからなくなる。
まる1日半かけてプロジェクト全体のリーダを代わる代わる呼び出して、プロジェクタで見積もりマトリクスの精査をお願いし、その場でリアルタイムに直していく、というような事すらやってさえ、次の日には間違っているところが発覚すると言う、そういう状況。
もう、正しいシステム構成がどうなっているのか等、誰も判らない状態。

これまでやってきた方法が通用しないと判ったのであれば、そこで新しく内部システムを立ち上げるべきだったのだ。
別に呼び寄せられた見積もりのプロ達は悪くない。
彼らはその神様の見積もりツールを持っていたがためにこれまでプロとして活動してこれたのだし、それがうまくいかないとなれば新しいシステムを作る力は彼らにはないのだから。
必要なのは、彼らから見積もり作業のエッセンスを聞き取り、専用のより効率的なツールを即座に作り上げる、内部システム部隊だったのではないかと思う。

同じような経験は他にもあって、私も昔、この仕事に着任したばかりの頃、配下のメンバーと情報共有を行うために、個人PC上でWikiを立ち上げた事がある。
ところが、うまく機能しない。
Wikiといっても単純においておくためだけでは駄目で、業務が判らないことだらけだから、その業務での成果物を出すのに最適な結果を出せるようカスタマイズしてやらないといけないわけだけど、ところが業務が次々新しいことが発覚してこれまでのやり方が通用しなくなるものだから、日々業務とは別にWikiの改造に明け暮れるようになってしまい、結果最終的には追っつかなくなりやめてしまった。
これも、専門の遊撃的な内部システム部隊がいれば、日々変わる情報要求の要件に対しても、追随してシステムを更改していけたんじゃないかと思う。

組織やプロジェクトも、生物と一緒だろう。活性化するのに必要な血液（体液）は、この場合は情報であったり、効率性であったり。
小さい規模であれば、単細胞生物と一緒。特に特別な器官を持たなくても、体液は全体に回っていく。
ところが大きな規模になると、多細胞生物と一緒で、単にただ「ある」だけでは全体に栄養は行き渡らない。栄養の行き渡らないところが発生し、そこから組織は壊死していく。
必然的に心臓と言うような、体中に栄養を行き渡らせるための器官が必要になるが、これが内部システム構築を考える部隊ということになるんじゃないかと思う。
プロジェクトそのものを扱うわけではないので、無駄に見えるかもしれないが、単に火を吹いているからといって闇雲に前線に人を送っても、3桁×3桁のイレギュラーなマトリクスをメンテナンスするのが、一人でできる仕事ではないがかといって数つぎ込んでどうなる問題でもないのも確かだ。
それならば一旦俯瞰して、プロジェクト全体の血液循環をよくするために、遊撃的な内部システム構築部隊を整備する事こそ必要ではないのかと思う。

YADIS仕様が出てきて、OpenIDやLIDその他もろもろのシングルサインオンが相互横断的に利用可能となる下地が出てきていますが、それでバンジャーイしてると、ハタと困った点に気付きました。

YADISによって、シングルサインオンの識別IDとなるURLが、どの識別プロトコルに従って識別されるかを判定処理できるようになりましたが、とはいえ識別プロトコルを判定できることとその識別プロトコルを用いた識別手順が実装されているかは別の話。
YADISで誰でもログインできるようにしようと思うと、YADISに対応したコンシューマは、YADISに対応した識別プロトコルの多くを実装していなければなりません。
はっきり言って私も使いこなせるのはOpenIDとTypeKeyくらいで、LIDですらよく知りません、ましてやXRI、SXIP...知るかー！ってな感じです。

これはまずくないですか。
YADIS対応サービスとか言いつつ、識別できるのがOpenIDだけなのだったら最初からOpenIDでのURLしか入れないでください、と書いとけばいい話だし、逆にLIDでしか識別できないのならLIDだけ入れてね、と書いておけばいい。
YADIS対応を謡う必要はない。
YADIS対応を謡うなら、参加しているいろんな識別プロトコルに最大限対応すべきだろう、けどそれってコンシューマに多大な苦労かけすぎ！

だったら、串サーバ作ればええんちゃうの、と思った。
コンシューマが対応できない識別プロトコルを識別手段として持つYADIS IDに対して、コンシューマの代わりに識別手順を踏んで、その識別結果をコンシューマの理解できる識別プロトコルで返答してやるサーバ。
これなら、コンシューマが新しいプロトコルが出るたびにその識別方法を覚えなくても、集約してその串サーバが新規格に対応していけば、みんなハッピーに相互利用可能になる。

もちろん、そんな事するくらいなら、最初からYADISのようなアプローチでなく共通の識別プロトコルに統一すべきだという話もあるだろうし、そうはせずにいろんな識別プロトコルが存在するのは、それぞれのプロトコルによって機能的に重要視していたりする部分が異なるためだ。
でも、そのような各識別プロトコルによる実装重点の違いは、あるコンシューマにとっては重要であっても別のコンシューマにとってはどうでもいい話であったりするので、そのようなこちらは重視しない点に関して重視するために作られた新規格なんて、わざわざ覚えて対応するのはコンシューマにとって苦痛でしかないでしょう。
とりあえずあんたのこだわりなんかどうでもええから、ログイン成功したかどうかだけ教えて、というノリだと思うのですが、そんなコンシューマに対しては、識別プロトコルを串するようなサービスは有効じゃないかと思いました。
当然ながら、コンシューマ毎にこだわりたい内容を持った識別プロトコルは個別に実装・対応すればよいのですが、それ以外の自分にとってどうでもいい？プロトコルに関しては、実装せずに串サーバに投げて代わりに識別遷移を行ってもらい、ログイン結果だけいただく、という形はどうかなと思いマスタ。

貧乏金なし。当たり前。暇なしなので亀ですが、

TVではかき消せない、permalinkの威力 -404 Blog Not Found-

少なくとも、「東証は止まったけどうちのサービスは止まりませんでしたよ」ぐらいは、言う資格があると思う。

にぽたん援護射撃は出尽くしているようなので、心はともかく身はどちらかというと「東証」ケースに近い側に置く立場として、あえてそっちの弁護を書くとしてみる。
別に弾さんはLivedoorを擁護しこそすれ「東証」ケースを攻撃しているわけではないのではあるけれど。

中にいて判るがまあSIerというのは、それも大手ともなるととにかく効率が悪い。
全然利用されるケースが違うとはいえ、かたや万、十万人単位のユーザが使うサービスを十数人でやりくりしてるのに比べ、うちのケースだと3桁程度のユーザが使うシステムを3桁程度の開発者で作ってたりもする（扱うデータ量はうちのが多いと思うけど）。
仕事のやり方も力技の体育会系、回らなくなったらプロセスの効率化より人の投入。
効率の悪さは認めざるを得ない。

でも、成果物の性質が全く違うのだから、単純に「東証は止まったけどうちのサービスは止まりませんでしたよ」と言ってしまうのは、いささか「東証」の方が可哀想。
自社サービスでリアルタイムにフィードバックを得ながら日々進化させられるシステムと、基本的に作りきり収めきりで、要請を受けてのサポートや障害対応という形でしか実際稼動後のシステムに接する事ができず、教訓のフィードバックをシステム全体に反映させられるのはシステムリプレース時期の数年後（しかも入札とかだと請け負う業者が変わる場合もあり得る）というようなシステムを比較して、前者は止まらなかったけど後者は止まったと斬っちゃうのはちょっと酷な気がする。
業務要件の決定時であいまいな顧客へのヒアリングから見積もった眉唾ものの業務量、或いは客先がこの値と指定する場合もあるだろうけど、それをベースに余裕を持って構成積んでいたら予算に合わないと言われ余裕どころかカツカツキュウキュウのところまでシステム構成を絞られて、それで収めて後は手離れしてしまうようなシステムに、想定業務量を超えて止まったからといって駄目システムってのは辛いっス（そりゃバグや不具合で止まれば駄目ですけど）。

まあ同じSIerでも、うちの案件のように内部システムで想定業務量なんかもほとんど変化ないと思われるので本当に収めきりなのと、東証のように業務がオープンなために業務量が変動するシステムとではまた違うのだと思うし、後者の場合日々進化させるのは無理としても常駐で技術者が付いていて日々パフォーマンスチューニングとかもやってるんだろうと思うけど。
とはいえ裁ききれなくなったからサーバ増設、なんて選択肢は、少なくともリアルタイムで取り得る選択肢としてはあり得なくて、その予算はどこから出るのか？とか稟議書とか回ってやっとサーバ増やせるとかって世界だと思う。
弾さんの引用記事から波及したどっかの記事での議論で、というかあちこちで、負荷なんて増えればサーバ増やせばいいんだろ、という煽りに対しサーバを増やせるような構成にしておくことがどれほど難しいか判ってるのか、とかってやり取りがあったように思うんだけど、そもそもサーバを増やすと言う選択肢が緊急時の対策の中にあるだけでウラヤマシスだったりするんじゃないかと思うのです。

まあそういう背景の違いを考慮したところで、こっち側の効率の悪さはもう目を覆わんばかりなので、あっち側の効率の高さには羨望のまなざしを送ってしまいます。
というか、私も入ってみるまで、こんなに違う世界だとは思わなかった...前々社もSIerだったとはいえ、元々大手の研究部門が不況の煽りでリストラされてSIer子会社に大量流入したようなところだったので、それなりにロジカルでスマートだったし進取の気風もあったからなあ（比較の問題でだけど）。
世界が違うとはいえ、Livedoorやはてなの身軽な開発で行われた官公庁システムや基幹系システムなんかも見てみたいなあとか思ってみたりもする今日この頃。

なるほどね。

Net::OpenID::Consumerでメタ情報の評価前に<body>以下を切り落としていたのもそのせいだったのか。
というか改めてみるとコード内のコメントにちゃんと書いてあった（汗）。

知ってしまえば考えれば当然の事なので、多分常識なんでしょうな。はい、世間知らずでした。すみません。

ちなみにHTTP::Header経由で取得しても<body>より後に<meta>があるようなケースに関しては挙動は大丈夫でした。

最近の会話。
感覚が麻痺してくるよなーとみんなで。

知恵絞って見積り削減案考えて、数千万円しか効かなければむちゃくちゃがっかりする。
それが自分がもらえるならどんなにかアレな額のはずなのだが。
というか、削減できなければ受注できないとはいえ（できないのか？削減できないままタイムアップになったらどうなるんだろう？システム更改ご破算？よく判らん）、自分たちの得る金を減らす方向に血の滲むような努力をしているわけなので、なんとも不思議な気分。

さて、帰るか。
今日はなんとか終電にならずに済んだ。

きょうねねの、blogする？
ねねはここへねねで状態blogするつもりだった？
ここまでblogしたいなぁ。
きょうねねの、blogすればよかった？
きのうここが、ここへねねはblogしたいです。

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

アイデアはパブリックドメインでいいじゃん、という思想 : 浅倉卓司＠blog風味？

「これは凄いアイデアだ！」なんて思うモノは、その時点ではただの思いつきに過ぎないのですよ。　
　　.........
そんなわけで、「アイデア」なんてものはパブリックドメインでいいじゃんと思うし、そのアイデアで報酬を得ようなんていうのは欲張り過ぎだと思うのです。

私自身こんな記事を書いてるわけなので、大筋では全く異論はないのですが、でもあまり立場を下げた書き方をしちゃうのにもちょっと違和感があるというか。

というか、神はディテールに宿る、それは真実だし、浅倉さんの書くように私もまさに「時間がとれないとか実力が伴わないとかいろいろある」けど「そのアイデアが実現するのは見たい」ので、自分でできそうもない（或いはできそうでも他の人がもっと早くできそうなものであれば）アイデアはオープンにしたりしてるわけなのですが、それは別にディテールを考えたくないわけなのではなくて、本当は「時間がとれ」て「実力が伴っ」ているのであれば、自分もディテールを考えるプロセスに参加したいわけなのですよ。
大事な自分の子なのだし。

それに単に思いつき→実装と単純なものなら誰に組んでもらっても同じように使えるのかもしれないですが、実際にはディテール化ってのは多次元にわたりますよね。
どんな機能をつけるか、どんな仕様に基づくか、どんなUIを使うか、とかとか。
その辺がちょっと違うだけで、全然自分が思っていたのとは違って使い物にならなかったりするし、そうなると今度は逆に巨視的に見て似ている実装が一つあるために自分の好みにあう実装が出にくくなってしまう結果になったり。
具体例でいうと、私、昔あるケータイ向けゲームを一般公開・提供していたのですが（というかバレバレですが）、転職なんかでまさに「時間がとれ」ず「実力が伴わ」なくなったので、他の方にお願いして管理を引き取ってもらったんです。
ところが、そのゲーム私も管理人であったと同時にユーザでもあって楽しんでいたのですが、移管した途端大筋は変化ないもののディテールが変わってしまい、私としてはほとんど遊べなくなってしまった経験がありました。
元々大筋では外を活発に出歩くユーザにしか楽しくないゲームであったのですが、管理人をやってれば出歩く時間があるくらいなら管理しないといけなかったということで、普通のユーザの楽しみ方は元々できませんでした。
でも、出歩かないユーザにとっても楽しい（少なくとも私にとっては）ディテールがあったので私もユーザとしても楽しめていたのですが、移管後その辺がほぼなくなってしまい、大筋の外で活発に出歩くユーザ向けの楽しみしかなくなってしまいました。
引き継いでくれた新管理人さんを責めているわけでもないし、むしろ言うまでもなく、他のユーザに迷惑をかけることなく引き継いでくれたことを感謝してはいるのですが、一方でディテールの決定に参加できる立場ではなくなるということの意味を思い知らせてくれた一件でもありました。

なので正直言ってしまえば、どんなアイデアでもかわいい自分の子、本当ならディテールの検討まで参加したいわけですよ。
ディテールを実現するための「時間が取れ」て「実力を伴え」る立場になりたいと思うわけです。
なので、アイデアをオープン化するのは、「アイデアを実装してもらって実現したい」という建前とは別に、本音を正直に言ってしまえば「いつかそういう立場を得るために、アイデアをオープン化していくことで、人脈を拡げたりといった形で梃子としたい」というのがあったりします。
「今」のアイデアを手放して犠牲にすることで、「将来」のアイデアを自分の管理の元におけるようになりたいなあと。
（いや手っ取り早く、やりたい事があるならその手の会社に転職すればいいじゃんと言われると思いますが、全くその通りなのですが恥ずかしながら今のところ連敗中でございまして。）
そんな梃子にできるような大それたアイデアを提供できているのか、と言われるとはなはだ疑問で笑われているかもしれませんが、まあその辺は自分を信じられるのは自分しかいないので、信じるしかないのかなあと。
実際商用サービスを開発したもろもろの中の人から、うちの記事に対し「参考になりました」とかってメールもたまに来たりしますしね...だからといって立場何も変わってないですけど...うーむ持論崩壊。
まあ、それはそれとして。

そんな風に思ってたりもするので、アイデアよりディテールこそ命、それは全く認めるのですが、かといってアイデアを出すのが全く無価値のように思われてしまうと、ちょっとなあとも思ってしまうのです。
ディテールを扱える「実力」があることは全く本人の才能と努力の賜物だと思うのですが、一方で「立場」にいることはほんの少しの運の違いだったりすることもあると思うので、それだけでディテールを扱える側が一方的にアイデアを吸い取ってどんどん「実績」を挙げていって、立場が固定してしまうのはどうかなあと。
アイデアだけでは「実績」にならないのは認めますけども、ディテールを扱って「実績」を挙げるための立場のチャンスは、アイデアだけでも流動化してもいいんじゃないかなと思うのです。

...30代も半ばを過ぎようとしてるオサーンの書く愚痴ではないですけどね。

友人が開発したシステムを2つ紹介。
どっちも事前リークもらってたのに、忙しかったりサーバ落ちなんかで対応できずごめんなさい。

その１：「NAVIBLOG」

GPS対応携帯電話で、その場所の地図上に口コミ情報等のブログ記事を貼り付けられるNAVIBLOG（社長ブログ）が、1月17日～19日の「ベンチャーフェアJAPAN2006」での出展を機にベータオープンしました！
NHKニュースでも取り上げられたりと中々盛況だった模様。
au対応GPSケータイからのアクセス先はhttp://www.naviblog.jp/ktai.html。

ここのすごいとこは、携帯のサイトにありがちな、地図と記事リンク一覧が分離している形ではなくて、ちゃんと地図の上にGoogle Mapsのマーカのように記事へのリンクが出てくるところ。
どうやって実現しているの？と思ったら、地図画像をHTMLの背景画像として表示させて、リンクマーカーはスタイルシートを使ってオーバーレイさせているみたい。
そんな事思いつきもしなかった。スゴス。

でも...カレシーさん、前連絡したA5505SAでの地図非表示問題まだ直ってないみたいッス...修正よろしく。

その２：「ロカポDIYマップ」

ロカポイント（社長ブログ）が開発した、Google Maps上に自由にオリジナルの情報をオーバレイして、知人にメール連絡したり、ブログやWebページ上に貼り付けたりできるツール。
ブラウザ上のみの捜査で、かなりの高機能を実現してる。
既にはてブなんかでも多数リンク集めてて、要望もいっぱい出てるみたいです。
このツール自体も便利ですが、社長の提唱しているロカポイント地図コードもなかなか考えられてて便利なシロモノです。
まだあまり世に出ていませんが、ロカポDIYマップでリンク作れば一緒に生成されるので、是非使ってみてください。
あまり更新できてませんが、一応CPANモジュールなんかもあったりします。

上田さんへ業務連絡：
あいまい領域の記述方法・内部処理方法等ロカポ仕様のあいまいな部分がいくつかあったと思うのですが、色んなケースのロカポ記述形式とその際の内部処理形式、及び経緯度との相互変換等のテストケース用データを作成してくれれば幸いです。
そうすればいろんな言語での処理ライブラリができても相互運用が容易になると思うので...。

XamppにしたのでApache2.2で動かしてるのですが、mod_fastcgiやmod_dav_svnがそのままでは連携しなかった。
以下、調査・実行結果。

1. mod_fcgidというのがあるみたい。Apache2.2対応済み。
   なんかmod_fastcgiより速いというレポートもあったり。
   試してみると、httpd.confでのディレクティブ名とかの設定を、s/mod_fastcgi/mod_fcgid/g で普通に動く。
   でも、MTのmt.fcgiでコメント一覧表示させた時とか、Internal Server Errorに。色々試してみて、プログラム側の問題ではなく経験的に出力サイズがでかい時になるっぽい。
   多分設定値とかでなんとかなるんだろうけど、念のためmod_fastcgiで問題なく動くプログラムか試してみるため、Apache2.2でmod_fastcgiを動かす方法を調査。
   元々mod_fastcgiが動かないから、とmod_fcgidを見つけたのに、本末転倒？
2. mod_fastcgiのApache2.2対応パッチを発見。
   充ててみると確かに動く。
   動いたのでmod_fcgid側のInternal Server Error追求もまあいいか（本末転倒しまくりんぐ）。
3. Subversionも、そのままでは動かなかったので原因を調べると、SubversionのパッケージにはAPRとして0.9が含まれてるのだけど、Apache2.2ではAPRが1.0になってるからの問題のよう。
   --with-aprと--with-apr-utilにXamppにくっついてきた奴のフルパスを与えてやれば万事オッケーラッケーしよう。

以上メモ書き。