古い記事だけど。

将来Twitterをつかったフィッシング「twishing」も？--専門家がセキュリティを懸念

Twitterはまた、長いURLアドレスを、リダイレクトサービスや短縮サービスを使用して短くするようになっている。これは、同サービスで投稿できるメッセージの長さが140文字までに限定されているためである。Porter氏は、このURLの短縮機能が原因で、ユーザーがリダイレクト先のページやどこにリンクされているのかをアドレスを見るだけでは把握することができなくなっていると述べる。そのため、悪意あるユーザーがこの機能を悪用し、悪質なウェブサイトやJavaScriptを埋め込む可能性があると警告する。将来的にはTwitterを利用したフィッシング詐欺（同氏はこれを「twishing」と呼んでいる）が登場すると予想している。

この記事が書かれてから4ヶ月近く経つのにいまだにTwitterはTinyURLを使っているようなので、やっぱり短いURLにするという需要、短いURLが求められる必然性というのはあるんじゃないかと思う。
かといって指摘される悪質なWebサイトへの誘導の危険性は排除しなければならんので、どうしたらいいかなと考えていたのだけれど、

URL短縮化サービスは、すべからく正しいURLを返すWebAPIを持たなくてはならない、というふうにするのはどうか。
そのAPIのインタフェースも統一化して、短縮化したURLのキーをAPIに投げると、正しいURLを返す、というもの。

こういうインタフェースが各URL短縮化サービスに配備された上で、各種ブラウザやTwitのような各種Webクライアントが、短縮化URLを処理する際はまずWebAPIを叩き、正しい実際のURLを確認した上でユーザにそれをアラートする、という機能を備えれば、短縮URLでもアクセス先情報を得ることができてよいのではないか。
もちろん、そうするとその共通仕様を悪用して、ウソの接続先を教える短縮サービスなんかも出てきそうだけど、その辺はサービスをホワイト/ブラックリスト的に処理するとか。

とか書いてて、これはいいアイデア！とか自分で思ってたりしたんだけど、よく考えるとそもそも最初の、「そのURLが短縮URLであるということをどうやって知るか」というところで詰まってしまった。
「実際のURLを確認するI/F」とは別に、「短縮URLサービスであるかどうかを確認するI/F」があればいいかもだけど、URLがある毎にそのドメイン全てにまず「短縮URLサービスであるかどうかを確認するクエリ」を投げるというのも、かなりウザイ。
Webクライアント側でキャッシュを持ってもらって、新しいドメインにアクセスする毎にとりあえず一回だけ「短縮URLサービスであるかどうかを確認するクエリ」を投げてもらい、レスポンスがあれば短縮URLサービス、なければ通常のURLとしてキャッシュしてもらうという手もあると思うけど、それにしたってキャッシュがどでかくなりそうだし、最初WebAPIに対応してなくて途中から対応した短縮URLサービスはどうするの？とかが問題。
というかそこまでいくと、たかだか短縮URLサービスのためだけにそこまで重い仕様決めるか？みたいな感じだし。

なんかいい手ないかな。

以前からiエリア情報をポリゴン化してGoogle Mapsとかに配信できるようなWebサービスとか作りたいと思っていつつ、時間もなく後回し後回しにしていたのですが、今回ちょっと機会に恵まれたのでざっとポリゴン化してみました。

んでもって、PostGISに505エリア分のポリゴンデータ叩き込めるようなSQLファイルも作成したので、公開します。

iエリアポリゴンデータのPostGIS用SQL

受け手となるテーブルデータは以下のような感じ（上記SQLの中に含まれています、赤字の部分はデータベース名なので各々の環境で置き換えてください）。

    CREATE TABLE iarea (
        id   char(5) NOT NULL PRIMARY KEY,
        name varchar(100)
    );
    SELECT AddGeometryColumn ('iareadb', 'iarea', 'iarea_tokyo', 4301, 'GEOMETRY', 2);
    SELECT AddGeometryColumn ('iareadb', 'iarea', 'iarea_wgs84', 4326, 'GEOMETRY', 2);
    CREATE INDEX idx_iarea_tokyo ON iarea USING GIST ( iarea_tokyo GIST_GEOMETRY_OPS );
    CREATE INDEX idx_iarea_wgs84 ON iarea USING GIST ( iarea_wgs84 GIST_GEOMETRY_OPS );

カラムを見ていただければ判るとおり、日本測地系、世界測地系双方のポリゴンを用意しておきましたので、例えば東京測地系では

    my $sth = $dbh->prepare("SELECT id,name FROM iarea WHERE ".
                            "iarea_tokyo && GeomFromText( ?, 4301 ) AND ".
                            "intersects(iarea_tokyo,GeomFromText( ?, 4301 ));");
    $sth->execute(map { "POINT($long $lat)" } (0..1));

みたいな感じで経緯度を含むiエリアコードとエリア名が取れます（言うまでもなくPerlの例です）。
（世界測地系の場合は、青字のカラム名を「iarea_wgs84」、赤字のSRIDを「4326」に変更してください）

で、せっかく作ってみたので、これまで個人的に経緯度→iエリア変換に利用してきた拙作のPerlモジュールと、処理能力を比較してみました。
Perlモジュールの方は、DoCoMoのiエリアデータがメッシュの列挙で提供されるのを利用して、経緯度をそれが含まれるメッシュ名に変換し、エリアデータの列挙されたメッシュデータと正規表現マッチさせることでエリアを導出しているのですが、果たしてどの程度差が出るか？
北海道、東京、大阪、沖縄の4点の日本測地系経緯度データからiエリアコードへの変換を1000回試行して、比べてみました。
また、PostGISからの導出とPerlモジュールからの導出で差が生じていないかのテストもしてみました。
実際のテストコードはこちらです。

実行結果は、 

    [postgres@www iArea]$ perl dbisearch.pl
    1..4
    Benchmark: timing 1000 iterations of TEST1, TEST2...
         TEST1: 70 wallclock secs (27.49 usr +  4.14 sys = 31.63 CPU) @ 31.62/s (n=1000)
         TEST2: 10 wallclock secs ( 0.57 usr +  0.05 sys =  0.62 CPU) @ 1612.90/s (n=1000)
    ok 1
    ok 2
    ok 3
    ok 4

という感じで、Perlモジュールの方が秒間30回の試行（変換は1試行で4回変換しているので、秒間120回）しか処理できないのに対し、PosｔGISの方では秒間1600回の試行（変換では秒間6400回）処理できるようになりました。
およそ50倍強の高速化です。

という感じで、やはり空間データベース恐るべし、です。

とはいえ、PostGISはポリゴンが丸（擬似円）であろうと三角であろうとアメーバ状であろうと処理できるのがいいわけですが、ことiエリアに関しては、取り得る最小メッシュ値の数が有限なので、様々な大きさのメッシュが混在しているiエリア定義ファイルを全部取り得る最小メッシュ値に直してやった上で、普通の表形式テーブルで完全一致検索してやった方が、もしかしたら速いかもですね。
データ量はおっそろしい量になりそうだけど...。

"アメンバー" @Ameba by CyberAgent -チミンモラスイ？-

ただ、機能的に近づいてきても、ブログとSNSというのはそもそもディメンジョンの違うところの定義だと思いますので、だからSNSになったというようなものでもないと、今のところ思っています。（このあたりは書くと長くなりますので別途ｗ）

その長くなるあたりをぜひ聞きたいです。

技術的には（といっても賛同者もあまりいない「俺的」技術ですが）、以前「SNSをSNSたらしめている最重要の機能とは何か」で書いたように、SNSは「ログインという行為により特定された個人」という情報を元に、コンテンツの所有者、現在のアクセス者、及びそれら個人に紐付く友人、コミュニティ、もろもろの属性を元にコンテンツの流通制御を行うことが本質ではないかと思っています。
その意味で、ブログは「ログインを伴わないため流通範囲を制御できないmixi日記」だし、mixi日記は「mixi全体でログインを要求されるため、非mixi会員には公開できないブログ」と言う感じで、本質的な違いはないように思っています。
それこそ、OpenIDの普及等で、インターネット全体レベルでの「ログイン」が実現できるようになれば、SNSサイト内ではない、自サーバ上に解説したようなごく普通のブログでさえコンテンツの流通制御ができるようになり、ブログとSNS日記の差は本質的にはなくなると考えています。

といった感じなので、NOWAやVOXが、ドメインベースの範囲内とはいえコンテンツの流通制御ができるようになったということは、間違いなくインターネット全体がSNS化していく進化の過程だと考えてますし、その意味では「SNS化したブログ」（或いは、ブログのように日記を非会員にも公開できるようになったSNS）としてNOWAやVOXを捉えても問題ないように思っています。

というのが技術的な（というか本質的な？）視点からみた意見なのですが、マーケッター視点から見た場合、ブログとSNSは全く別物、とする捉え方があるのならば、ぜひ「その長くなるあたり」を聞いてみたいです。

http://mixi.jp/issue_ticket.pl は OpenID server だったよ -知らないけどきっとそう。-

openid.assoc_handle がついてるから、smartモードで最初に鍵の交換が必要だと思うんだけれど、塞がれてるのか…

mixiがOpenID技術を内部的に使っているけど、鍵交換の口等が塞がれているので利用できないっていうことなんだけど。
これって、逆に言うと、その口をmixi側が個別に開けば、そのサイトとmixiとは、OpenIDで取り合えるってことだよね。
mixiは、無差別にオープンにするのではなくて、mixiにとって相乗効果で利益を生み出せるソリューションとの間で、個別に契約ベースでこの口を開いていくことを考えているんじゃないかなと思った。

単に自社のサブドメイン間のセッション情報取り合いとしては、OpenIDは一つの解かもしれないけどちょっと重過ぎるんじゃないかなと。
今後mixi及びmixiユーザに取って有益で、かつお金になるソリューションをタイアップ提案していけば、見返りにmixiの膨大なユーザ資産を利用させる、というそういう方向性を考えていて、そのテストケースとして自社内サーバ間で適用した、とかそういう感じじゃないだろうか。
そうしてmixiユーザ認証で結び付けられた他社ソリューションをも、mixiブランドとして展開して、ネット上に分散されたmixi帝国を作る…とかそんな感じの目論見があるんじゃないかと。

単なる市井の日曜開発者からすれば、自由にOpenIDサーバ開放してくれよと思うんだけど、今までのmixiの動きからするときっとそうはならないのだろうなあ。

ある日の午後 -ダメ人間漂流記- のコメント

＞この日記、本にしたら必ず売れるね。

＞残念ながら売れません・・・＾＾；

＞あんた文才あるなぁ バイトしながら本書いてみたら?

＞本なんて書けませんし、お金も無いので自費出版も出来ません・・・＾＾；

いや私もむらのさんの本なら売れるに一票。

読ませる筆力もすごいけれど、これだけの様々な経験を覚えていてさらに文章に再構成する力、そしてこれだけの期間書き続ける力もすごいと思う。
また視点も、自分の目を通して語っているけれど過度に「我が我が」にならず、冷静で客観的な視点を維持していてすごいです。
何を書いても「我が我が」がどうしても出てしまう私等、むらのさんの爪の垢でも煎じて飲まねばなりません。

と言ったところで、出版社にはオライリーくらいしかツテがないので紹介もできないし、一人で出版費用もてるほどの財力もないのでせいぜいこうしてブログ上で紹介するくらいしかできないのですが...。
むらのさん、愛読して応援していますので、続けてください。

Web2.0ワークショップで紹介したように、様々なケータイやPHSでユーザの現在位置が取れるようになってきていて、それを使っていろいろアプリケーションが作れるようになってきている。
その中には、実用アプリだけでなく、私も前管理人をしていたアンテナ奪取や、ケータイ国盗り合戦、Ittemiaのようなエンタメアプリも考えられるわけですが、その際に問題になってくるのが「現在位置の詐称」問題です。
ケータイ、PHSでの位置取得は、SoftBank簡易位置情報のようにHTTPヘッダ、DoCoMoのiエリアのようにPOST等で返ってくる場合もありますが、多くの場合、GETのクエリストリングとして返ってきます。
なので、一旦URLを得てしまえば、クエリストリング中の経緯度を書き換えさえすれば、簡単に詐称できてしまうのです。
実用アプリならば、飽くまで位置情報はユーザの調べる位置を現在位置とするための補助でしかないので、詐称はしたいのならば勝手にすれば？という感じですが、「その場所」に本当に行ったかどうかで競うようなエンタメゲームアプリではそうはいきません。
詐称されてしまうとゲームにならないので、何らかの防衛策を採る必要があります。

まず簡単なのは、詐称すると当然リファラが切れるので、リファラを見る方法ですが、これはあまりお薦めできません。
DoCoMoのｉモードのように、リファラを一切返さない仕様もありますし、その他でも、例えばauはリファラを返すということになっているようですが、CDMA2000の初期端末等では一部機種依存（すみません、具体的にどの機種だったかは忘れました）でリファラを返さない端末があったりして、またケータイサイト運営しているとそんな古い時期の端末でも時々ユーザサポート問い合わせが来たりするので、少なくとも私は、積極的に使う気にはなれません。

続いて、私がアンテナ奪取を運営していた頃に採用していた方法なのですが、サイトのセッション管理を1アクセス毎のワンタイムセッションにし、かつURLにセッションIDを埋め込む形にするやり方。
ケータイWebの特性として、「ケータイ端末」上からは、絶対にサイトのHTMLソースを確認することができない、という特性があります。
よって、アクセス毎にセッションIDを変えるワンタイムセッション形式にすると、「一旦アクセスするまでは」絶対に次のアクセスに使われているセッションIDが漏れることはありません。
そして、各ワンタイムセッションIDにおいて、一度でもそのIDでアクセスがあればそのセッションIDでの位置取得を不可にする、というフラグを持たせておいてやれば、詐称することは不可能になります。
何故ならば、一度位置を取得したとして、その際に得たURL上で経緯度を書き換えてやっても、そのURLに使われているセッションIDで位置を取る権利は既に失われていますし、かといって位置を取る権利の残っているセッションIDを知る方法は、HTMLソースを読む方法がないので判らないからです。

▲ ワンタイムセッションを使う方式 ▲

この方法の欠点は、1つはアクセス毎にセッションを発行するので、とにかく管理するセッションの数が馬鹿でかくなること。
もう1つの欠点は、ユーザが位置を取った後、ブラウザの「戻る」を使って前のページに戻り再度位置を取ろうとすると、原理上「不正位置取得」扱いになってしまいますが、これではユーザにとってあまりに不便なので、ブラウザの「戻る」を使わなくてもユーザがどんどん「位置取得操作」を行えるよう、位置取得後のページにも再度「位置取得リンク」を埋め込む、といった具合に、サイトのどこからでもユーザがすぐ位置取得操作に移れるようUIの工夫をしなければいけない点。
つまり特定のページだけに位置取得リンクを作ればいいというものではなく、サイト中のあらゆるページに位置取得リンクを作らなければならないので、これは1つ目の欠点とも相まって、ほとんど「PV＝セッション発行数」というような状況になり、中々すさまじい事になります。
私がアンテナ奪取を運営していた頃は、会員はせいぜい1000から2000人くらいしかいなかったのですが、1ヶ月あたり発行されるセッション数は70万件近くになっていました。

上記のような方法を長年ノウハウとして持っていたのですが、先日、もっと簡単な別の方法を思いつきました。
よく考えれば、ユーザがHTMLソースを見られない以上、位置取得をしたURLでそのまま位置情報を暗号化した後にリダイレクトをかけてやれば、ユーザには位置を取得するリンクを知られることがありません。
これだと、煩雑なセッションの管理等必要なく、簡単に位置情報の詐称を防ぐ事ができます。
位置情報を暗号化するキーとしては、固定のキーではなく携帯電話から取得できるユーザIDや端末ID等を利用してやれば、同じ位置でもユーザ毎に異なる暗号化結果となり、友人同士で暗号化された位置情報を教え合われたりしても無効になるので、よいのではないかと思います。
また、位置情報を暗号化する際には、暗号化する元の情報がバイト列として短ければ短いほど、暗号化された後の文字列も短く出来るので、単純に経度・緯度の小数を暗号化するのではなく、まずロカポイント等に変換して、精度はほとんど落とさずバイト列として短くするのが吉かなとか思います。

▲ 暗号化とリダイレクトを使う方法 ▲

この方法で注意しないといけないのは、リダイレクト前の生の位置情報が渡るURLが、絶対に外部に漏れてはいけないということです。
先のワンタイムセッションの方法ならば、URLが漏れたところでアクセス毎にセッションIDは異なるのですから問題ありませんが、この方法ではリダイレクト前のURLは共通ですから、それがばれてしまうと詐称を許してしまうことになります。
もちろん、携帯からはHTMLソースは見えないわけですが、同じサイトにPC等でアクセスできてしまうと遷移先のURL丸判りですので、ケータイWebのゲートウェイからのアクセスのみ許可するような設定をする等の防御策が必要です。
或いは、位置情報が渡るURLにも、何らかのチェック文字列（「OK」とか）を各ユーザのユーザID/端末ID等で暗号化してやって加えておき、遷移後のページで復号チェックする、等とすれば、URL漏れ対策になるかもしれません。

以上のような方法を使えば位置情報の詐称が防げるようになるので、位置情報をエンタメWebアプリとして使いやすくなるかもしれません。
面白いサイトがこの記事を参考に出てきたりすれば、嬉しいです。 

マーケティング的な考え方というか、金ありきで技術を重視しない考え方には散々煮え湯を飲まされていて、むかついているというか、いや最近はもうなんかあきらめモードで大人の笑顔で合わせてるようなところもあるんだけどさ。
それでも、やっぱり全然違う視点からの見方だけあって、目からウロコというか感心させられることもあるんだな。

ネットユーザーは「ニュータイプ」なのかもしれない -狐の王国-

だって携帯電話ユーザーなんて 検索エンジンに「暇」とか「つまんない」とか入力しちゃう んでしょ? 思いっきりオールドタイプすぎるだろ。ある意味新しいけどな、ある意味。

やっぱ技術系だと、検索というものの機能をそのまま捉えて、そう考えちゃうんだけどな。
ユーザが検索語として入れていないことを推定してリコメンドする機能を考えるといっても、せいぜい綴りを直して「もしかして」とか、類似語検索を交えるとか、その程度のロジカルな範囲に留まってしまう。

でも、マーケッターが話すと、同じ現実を話題にしても、そういうユーザ行動を元にそれを現実として受け入れてマネタイズできないか、という話になる。
例えば、「暇」「つまんない」と入力している人が居るのならば、それを解消することが稼ぎにつながるのだから、ユーザの属性やコンテクストに合わせて、マンガ好きな人なら最新の話題のマンガを紹介したり、ゲーム好きな人なら有料ゲームサイトに誘導したり、イベント会場の近くに居る人ならそのイベントに誘導したり、そういう検索結果が出せれば儲かるんじゃないか、とそういう方向に話題が進む。

そういうところは、やっぱ素直にすごいなあ、と思いますね。

高校生に重要なのは速度だと話したが理解してもらえなかった -ノッフ！-

「昔の大人には威厳があった」のは、みんなが無知だったからなんだ -狐の王国-

ネットで情報の伝達・収集が速くなったのは確かに進化なのだが、なんでそれをもって多くの人が全能感のように感じてしまっているんだろう。
私自身、ネットでの情報収集に頼りきっているし、ケータイの位置情報にのめり込んだのも「今いる場所がGPSで判るのに、その場所の情報を調べるのに住所をどうにかして得たうえでGoogle検索しないといけない、そんなまどろっこしい現実を何とかしたかった」からだし、OpenIDなんかに手を出していたのも、「あっちこっちのサイトやSNSでいちいち別個にアイデンティティ管理しないといけない状況を改善したい、ネット横断的なDRY（Don't Repeat Yourself）を実現したかった」からだし、ネット上で情報を得ることの最適化、最速化の必要性は痛いほど身に染みている。

しかし、ネットは所詮道具でしかない。
世の中にいろいろ存在する中で、今現在もっとも先鋭的で革命的だが、しかし単なる道具の一つでしかない。
「既にネットはリアルだ」それは間違いなくその通りなのだが、その「リアル」は「本当のリアルのほんの一部の切れ端」でしかない。
ネットはその「リアルの一部」、ネットの上に一応存在している事が判っている、或いはもしかしたら存在するかもしれない情報を最速で入手するための道具でしかない。
世の中の全てがネット上に存在する等と思うのは大間違いだ。

例えば「TCP/IP」ならネット上で即効で調べられるのだろうが、

• ハードディスクの表面に気体レーザを使って髪の毛より微細な表面加工を安定して行うために、もっとも安定させなければいけない周辺環境ファクターは何か
• 製紙工場の圧延ロールで、もっとも損耗率が低くなるような成分含有率はどのようになるのか
• 地球上で発生する磁気嵐は、地球周辺環境のどのようなファクター変化によってトリガされ、またその嵐発生タイミングはファクターのトリガがかかってからおよそ何分後か

といったことをネットで調べられるだろうか。
しかし、どれ1つ取ってもそういったノウハウがなければ社会が回らない情報であるし、そうしてそういったノウハウを用いないと業務が回らない業界の人達は、それは業界の人脈であったり技能の継承であったり学会の論文検索であったりするわけだが、ネット等使わなくても、そういう必要な情報に到達するためのチャネルは確保している。
実際一つ前のエントリにも書いたようロケット技術者のように、ネットやPCを使いこなせなくても自分の業務遂行に必要な情報チャネルは確保している故に優秀な第一人技術者として活躍している連中は多い。
正直、俺の同期で話すなら、同期の中でまず一番に、圧倒的に俺がPCや検索を使いこなせるだろうが、恥ずかしい話稼いでいる額で話すならまず99%俺が一番年収が低いだろう。
別に現実世界では、ネットで物を調べられる能力なんてのは、同じ業種内で隣のライバルとどう差をつけるか、といった低レベルな話ならばそれなりに有効だろうが、社会全体からみればそれほど優位を得られるわけでもなんでもない。
それどころか、ネットで調べられるレベルの情報なんてのは、それだけである意味コモディティ化しているので、はっきり言ってそこでは他者に勝つ優位性なんて生み出せないし、その「コモディティ化していく元情報」を発信源として生み出す力のある連中の草刈場とされてしまうだけだろう。
本当に必要な力とは、別にネット上で検索できる情報を最速で引き出してくるような能力ではなくて、自分に必要な情報を最速でなくてもよいから確実に引き出してくるチャネルを確保することであって、ネットなどそのうちのOne of themでしかない。

情報だけでなくネット上の議論についても、私も過去、もう10年以上前、ネット上で某社会問題について、賛成派反対派集めて1年以上かけて議論し、議論の前提となる事実の裏付け、デマの洗い出し等を徹底的に行ったことがあるが、それから10年以上経つ今でも、その議論の結果は全く継承されていないし、いまだにデマと判っている情報が平気でたれ流され、それを前提に議論が進んだりしてる（まあ、私がサーバの移転時に「復旧が面倒くさい」というだけの理由でその議論結果のまとめサイトを閉鎖してしまったせい等もあるのだろうが...）。
そういう経験を持つ立場から見ると、ネット上の議論は別に大した蓄積などなく、単に何度も同じところを堂々巡りしているだけのように見えるし、その点では参加人数と回転速度が速くなっただけで、人類のこれまでの議論の歴史と何ら大差ないようにも思える。

それに何万人何十万人と議論できようと、前提がはっきりしないような議論では現実を知っているものとアクセスできなければ何の意味もない。
下関砲撃事件前夜英国留学して現実を見てきた伊藤博文と井上馨が、いくら攘夷の無謀を説いても誰も耳を貸さず大失敗したように、現実を知る者の意見に誰も耳を貸さないような空気ができていれば、何の意味もない（その2人ですら、英国留学前はガチガチの攘夷論者であったことを考えれば、現実に接する事の大切さが判る）。
現実を知りもしない人間何万人と延々と議論するくらいならば、現実を知る一人とじっくり議論する方が実りのあることはいくらでもあるだろう。
もちろん、ネットというメディアのおかげで、その「1人」を尋ねることなく、家に居ながらにして繋がれるようになった、という利点もあるだろうが、何万何十万のノイズの中からその1つ、下手をすれば何万何十万から叩き潰されかねないその1つを見抜くのは至難の業であるし、接する側の情報取捨選択の力量が問われることにもなる。
その意味でも、ネットが使えることで全能感など感じることなく、ネットは所詮数ある道具の中の1つ、程度に捉えておいた方がいいように思う。

東大卒がプログラマになんてならない理由

なんかレイヤ的にも業界的にも、全然違う世界の話をしているような気がする。
別の業種で言うなら、橋・トンネル・ダムだの超高層ビルだの、そういった巨大建設・土木プロジェクトに携わるエリート技術士が、ぼくらは自分でCAD図面を起こすような仕事はしないんだとか何とか言って、自分でCADを描く建築家を馬鹿にしているとか、なんかそんな構図に見える。

確かに、東大卒の彼が書いているようなエリートが自分でコードを起こさずに理論だけ考えて、実際にコード化するのはその下で働くプログラマ（というか、コーダというべきか）という世界は存在するし、それで回ってる。
例を挙げるなら私の前職も、非常に機密性の高い案件で、マジで諜報機関とかでも使えるレベルでの「○×MINT（Kissmintじゃないよ）」システムの開発とかやってたんだけど、そこで情報の加工・分析を行う理論・アルゴリズムの検討・議論なんかは、開発側も客先担当も含め、自分ではコーディングなんかしない（中にはできない奴も含まれる）東大京大卒のエリート集団だった（ちなみに私はそのエリート軍団ではありませんでしたが。私の役職は、喩えるなら国土交通省兼財務省？）。
そういったエリート連中が1年以上もかけて机上で議論・折衝を繰り返して（もちろん途中いろいろ実験も入りますが）決定した理論・アルゴリズムに従い、実装フェーズに入るとあちこちの派遣・請負会社から一束いくらで集められた（俺はこんな表現したくはないが実際そんな感じの扱いだった）何十人ものコーダ達が、力技で実装するという感じの世界だった。

他の例でも、俺の同期にはJAXAでロケット制御の開発をしている奴もいれば、逆にそれを受注する側のロケット製造会社で同様に制御設計をしている奴もいる。
どいつをとってもその世界では一人者になりつつある優秀な連中だ。
が、そいつらも別に自分でコードを書いているわけではないだろうし、それどころかWindowsの設定すら難しくてよく判らないという奴すらいる。

そういう世界もあるわけだが、そんな世界で暮らしていてそしてそれだけが世界だと思い込んでいれば、自分達は自由に新しい事案に適用する理論やアルゴリズムを考察・検討できて、下で働くプログラマは創意工夫の余地もなくそれを形にするだけ、それでいて自分達の年収は彼らのン倍、そりゃプログラマになんかならないよ、という発想になるだろう。
だがそういう奴は気付いていないのだ。
自分達のシステムの、オリジナル部分は確かに彼らが考案しコーダに作らせたものかもしれないが、それだけでは動かない、前提となるOS、言語、ライブラリ、そういったものがどのような形で作られてきて、今も改善され続けているか、ということに。
今オープンソースやWeb2.0といったムーブメントで脚光を浴びている「プログラマ」は、彼らの下で働く「コーダ」ではなく、そういったムーブメントを自発的に起こせる本当の意味での「プログラマ」であるということに、気付いていないのだろう。

或いは気付いている上で、大学の講義であらゆることは学んでいるから、やる気にさえなればそんな「花形プログラマ」のやってるようなことは俺でもできるんだYO！とか言いたいのかもしれない。
確かに、大学では「CPUの設計ができて、プログラミング言語を設計し、コンパイラが書けて、OSを載せて、その上で例えばレイトレーシングを動かせるくらい」のことは学ぶだろう。
電気系卒の俺ですら上で書かれていることのさわり位は学んできているので、情報系卒だともっと深いところまでもやるのだろう。
でも、原理を知っていることと、それを形にすることは全然違うということに彼は気付いていない。
例えば俺でも、原理は学んできてるから、仕事辞めて全人生棒に振った上で、いろいろ書籍ひっくり返しながら試行錯誤して実装してみれば、MS-DOSの出来損ない程度のOSなら作れるだろう。
でも、同じ事を、コーラ片手にパパパッと片手間で実装してしまえる（大学で理論など学んでいなくても）人間もいるのだ、ということに彼は思いがいたっていないのではないか。

彼は「ある仮説を立てて、その仮説のもとで最適なアルゴリズムを設計し、実際に処理系に組み込み、仮説が現実にどれくらいあっているかを検証することで、そのアルゴリズムの良さを測る...実践うんぬんと言っているが、上記のことは普通のプログラマーには実践すらできないだろう。また、ここで注意していただきたいのは、プログラミングなんて誰がやっても同じということだ。」とか書いているけど、理論先行で実践がない大学研究室が作ったシステム等では、IPAの未踏に通るレベルのプロジェクトでも、その成果をいざエンタープライズに持ち込んで実サービスに投入しようとした途端、プログラムがスパゲッティで拡張性・応用性もなく困っちゃってる、という話も友人から聞いたことがある。
所定の新しい価値が実現できていれば、あとの部分は誰が実装しようと同じ、等ということは絶対にないだろう。

また「大規模なプログラムの設計は重要だ。だけど、設計と吠える人ほど設計センスがないという現実がある。本当に難しい部分の設計というのは、例えば...Suicaのようなシステムならば、日立の東大生。」等と書いているが、そのように自慢する大規模システムとやらが、決して「かしこい設計」にはなっていないという現実。
Suica（類似仕様なのでPASMOも含むが）が、相互乗り入れしているにも関わらず、Suicaには私鉄の、PASMOにはJRの定期設定はできないというこのクソ現実。
おかげで、せっかくお財布ケータイで定期も何も全て済むようにできたと思ってたのに、私鉄通勤になった途端またPASMO持たないといけなくなってしまった。
さらには、PASMOの定期設定は2鉄道業者乗り換えまでしか設定できない設定のせいで、3業者乗り換えで通勤しているような本当の意味でPASMOが役立つようなユーザが、PASMOの恩恵から外されているという現実。
いかにセキュアかつロバストに金銭決済を実現する機構がすばらしかろうと、こんなクソ仕様を放置している時点で、何が設計センスか、という話だ。

別にどっちが上とか下とか、なりたいとかなりたくないとかの問題ではない。
社会システムの中枢を担う大規模プロジェクトの中で理論設計を行う人材も、オープンソースOSやライブラリの開発等を通じて社会全体の基盤を間接的に支える人材も必要だし、また前者の元で働くコーダの方々まで含めて、みな社会に欠けてはいけない人材であるわけだし、各人の興味や熱意、適性等に応じて適職につけばよいだけの話。
んでもってそれぞれが敬意をもって他の職種と連携しつつ、それぞれの場でベストを尽くせばよいだけのことを、それをどっちが上だとか下だとか、自分の狭い世界の中だけで順列付けようとするから香ばしいエントリーになってしまう。
以前のエントリで

2つ目は、この技術分野だけで閉じてしまって、他の技術分野との協調発展の方向性が閉ざされてしまうのではないかということ。
今までGeek、Geekと書いてきましたが、正確には「情報科学分野のGeek」なわけなんですよね。
　　......
そういう人達は情報技術には疎いわけなので当然今のネットワーク社会上ではサイレント・マイノリティなわけですが、しかし専門分野ではすごい技術の持ち主なので、ソフト・情報科学のGeekと連携できればすごいことができる可能性だってある。
その可能性が、情報科学のGeekばかり突っ走りすぎてることで機会が失われてやしないか？というのが私の心配する点であったりするのです。

といった感じで、「プログラマ＝情報技術（というかWeb界隈）のGeek」が自分達に見える世界だけで突っ走ってしまうために他分野との連携が出来なくなってしまうのではないか、という危惧を書いた事があるが、今回はその「他分野」の方での同じような病理を目にすることが出来た、という感じがします。

今の仕事　本当は私が開発会社と制作会社双方管理してキャンペーン全体をディレクションしなきゃいけないのだが、「サイトデザイン？そんなんおっちゃんには判りまへんがな」のノリで開発寄りのフォローだけ選り好みして制作・ディレクション系は他にも仕事あって忙しいマネージャにエイヤっと放り投げ状態。
いや、実際開発寄りの仕事も超忙しくて仕事割り振らないとこなせない、まさに「心を亡くす」状態だったのだが、今日になって制作系は仕事残りまくってるけど開発系はちょっと落ち着いた感じに。
んなもんで、ここしばらく昼休みもくそもなかったので、ちょっとくらいいいよね（いやよくないのだが俺的には全然OK）という感じで、マネージャには悪いなと思いつつ（いや全然思ってないのだが）久々にネットでネタ漁り。
そういえば社内で、仮想化サーバについて話題になってたな、Amazon Web Serviceとか最近どうなってるのかなと思っていろいろググってみた。

すると、ついに念願の、Amazon S3サービスをファイルシステムとしてマウントする、無償（今のところ？）のソリューションが見つかった。
ElasticDriveというサービスで、Webを見ると「TRY OR BUY」なんて書かれてるんだけど、そこを覗いてみると普通にシステムのソースコードだけがダウンロード可能な形で置いてある。
なんでも、「Pricing is yet to be determined.」ということらしい。
早速ダウンロードしてみて使ってみた。

使い方は単純で、pythonスクリプトなんだけど、それを走らせてやった後、NBDとか言う方法で繋いでマウントするだけ。
READMEに従うと、コンフィグファイルを設定してやった後、

> cd /opt/elasticdrive-0.1.6
> ./elasticdrive
> nbd-client bs=4096 localhost 9999 /dev/nbd0
> mke2fs -b 4096 /dev/nbd0
> mkdir /s3
> mount /dev/nbd0 /s3

とするだけなのだが、いくつか引っ掛かる点があったのでご紹介。

まず、このスクリプト、これだけ単体では動かない。
Google Codeで公開されている、botoというAmazon S３制御のためのPythonライブラリがインストールされている必要があるので、これを先にインストールしておく必要がある。
また、LinuxのカーネルがNBDという仕様に対応してコンパイルされている必要があるらしい...もしされてなければ、どうするのかまでは、うちのサーバはコンパイルされてたっぽいので追っていません。
さらにNBDに対応しているだけではダメで、

• 最初にNBDを有効にする際には、modprobe nbdとコマンドを叩いてやる必要がある
• nbd-clientというコマンドがない場合は、インストールしてやる必要がある

といったこともしておく必要もある。

上記さえやってやれば、設定したディスクサイズ次第だがmke2fsに結構な時間がかかるものの、問題なくS3領域をマウントできた。
私は試しに、30GBの領域をマウントしてみたが、全然問題なく動く。
このElasticDriveのすごいところは、単にディスク領域として追加できるだけではなく、物理ディスクと同容量用意してやれば、自動でミラーリングされソフトウェアRAIDとしても機能する（らしい。まだ試してない）ところ。
これで、EC2の、160GBもあってでかいけれど揮発してしまうディスク領域も、安心して使えそう？

ただ気をつけないといけないのは、S3の領域をファイルシステムとしてフォーマットするので、置いたファイルの分だけS3の利用領域として課金されるのではなく、最初に設定されたディスク容量の分だけS3の領域を最初から占有していることになる、ということ。
いかにS3の値段が安いとはいえ、30GBも完全占有していたら月700円は軽くかかる、ましてやEC2揮発領域のソフトウェアRAIDなんてことになると...である。
EC2との間であれば転送料は無料なものの、GET/PUT/LIST/DELETEにも従量課金されるので、どの程度の金額になるのかさっぱり想像がつかない。
ちょっと自腹はたいて人柱になる事になるが、今回設定した30GB上でベンチマーク取ったりいろいろ試してみて、その上でどの位金額が課金されるか試してみようと思う。

また上記のようなので当然っちゃあ当然だが、ElasticDrive上に配置したファイル等は、S3経由でWeb側から見るようなことはできない。

というような感じのElasticDriveですが、使い方によっては面白く使えそうなので、試してみてはいかがでしょうか。
私もベンチマークとかいろいろ遊べ次第、報告します。

昨日ぐらいからすごい鬱。
というか数週間前から私生活では、例えばブログを書く時間があっても書きたいネタもあっても書く気力が起きずぶっ倒れてるだけ、とかの状況ではあったのだが、昨日ぐらいから仕事までやる気力が出ない。

パニック障害的なものや自責・自罰感はないので病気ではないと思うし、身体的な疲れは毎晩結構遅いのでないわけじゃないけど死ぬほど疲れてるって訳でもない。
仕事やりたくない、というのでもないがとにかく気力だけが沸いてこない。
何なのだろう。

単なる夏バテか？