ユメのチカラ

経済産業省商務情報政策局長感謝状

ひょんなことから経済産業省商務情報政策局長から感謝状を頂いた。わたしの年代だとお相撲の優勝者が航空会社の日本支社長(外国の方)から「ひょっうしょぅじょ〜ぅ」というのを懐しく思いだすのであるが、まあ、誰かから賞状を貰うのなんていうのは小学校以来と言っても過言ではない。

経済産業省として「ＩＴ産業の魅力の向上や将来のＩＴ産業の人材育成などについて、企業、教育機関の枠組みを超えて活躍している専門家の活動は、単に関係者間の自主的な取り組みにとどまらず、経済産業省の展開する政策にもご貢献されるものであると認識」し、ついては「この分野でご活躍いただいている専門家の皆様に商務情報政策局長より感謝状を贈呈したい」とのことである。

今回、経済産業省として初めて「専門家コミュニティ活動」を表彰したらしい。昨日、経済産業省に出むき局長から直々に感謝状を頂いた。今回の対象者は独立行政法人情報処理推進機構からの推薦を受けた人々のようで、具体的にはITSS/UISS/ETSS等スキル標準の活動に貢献した方々、OSSの活動に貢献した人、そしてセキュリティ&プログラミングキャンプでの活動(わたしはこの分野)に貢献した人々からなる。

感謝状の文言は以下のとおり。

感謝状
  吉岡弘隆殿

貴殿は経済産業省及び独立行政法人情報処理推進機構の人材育成政策に深い理解を示し我が国情報サービス産業の魅力向上や将来を担う人材育成のためその発展に寄与する活動に多大な貢献をされました
よってここに感謝の意を表します

平成二十年九月二十四日
経済産業省
商務情報政策局長       近藤賢二

授与式のあと、今回の受賞者の皆様と局長と歓談する機会があった。OSS分野で感謝状を受けた日立製作所の鈴木さんが口火をきって歓談がはじまった。スキルスタンダートを作成したアクセンチュアの杉山さんが、会社の枠を越えたプロフェッショナルコミュニティに参加できたという印象を語っておられたが、まさに同感である。また早期ＩＴ人材の発掘(セキュリティ&プログラミングキャンプやU-20プログラミングコンテストなど)についても、若い人にＩＴに興味をもってもらうことの重要性などをお話しした。例えばロボコンとか鳥人間コンテストなどに代表される技術に興味を持つ層を広げるイベントなどについてもいろいろアイデアを練っていく必要があると思う。

一方で、会社の枠を越えた知識の流通という意味で、標準化あるいは言語化が難しい暗黙知の流通は、人の流動化によってのみ達成できる。業界全体のレベルアップのためには人材の流動化が担保される必要がある。もちろんプロフェッショナルコミュニティを活性化することによって、知識の流通は加速されるであろうが、暗黙知は多くの場合、属人的なもので、それの流通には人の交流というのが欠かせない。すなわち、自主的に交流することは、どんどん勝手に民間がやればいいのであるが、人材流通に対する制度設計、政策立案などは、政府の力が必要となる。というような事を申し上げた。

今回の受賞者のほとんどは初対面の方だったので、さっそく名刺交換をさせていただき、これをきっかけに何らかの繋がりができれば望外の喜びである。

日経コンピュータに載りました

日経コンピュータ増刊号(2008年9月22日)にわたしのインタビューが掲載された。この増刊号のコンセプトは、

道
今、選択のとき
ＩＴ業界の仕事は面白い。新しい技術が次々と生まれ、それを使って社会や会社、個人の生活を変えていける。ただ現状では、本来の創造性を発揮できずに、閉塞感を感じている人もいることだろう。そんな時期だからこそ、自分を見つめ直してはどうか。キャリアやスキル、それを支える生活---今こそ5年後の自分の姿を描こう。

取締役退任、生涯一プログラマ宣言以来いろいろな方からインテビューを受ける機会があった。この増刊号には、20代、30代、40代、50代それぞれ3人づつ気鋭のエンジニアのインタビューが掲載されている。

IT戦士の天野さん(２５)のインタビューも載っていた。

週末にじっくり読んでみようと思った。

もう一つ、エンジニアtype 08.11号にもインタビューが掲載されている。こっちの写真はわたしの雑然とした机、名刺とかメモとか散乱、後ろの本棚には資料やらインテルのマニュアルやらが…。一番いい位置にRubyソースコード完全解説(RHG本)とダンボールの上には初めてのRubyがみえる。

memcached Night in Tokyo #1

先日開催された memcached Night in Tokyo #1 というのに参加してきた。

http://groups.google.com/group/memcached-ja/web/memcached-night-in-tokyo-1

夕方6時開催という昨今の勉強会としては早めの開始時刻なので、あたふたと会社を出た。場所は原宿である。おされな場所である。浮足立つ。ということはどうでも良くて会場であるmixiに初めていったのだが綺麗なオフィスであった。

memcachedというのは、データベースに対する分散メモリキャッシュ技術みたいなもので昨今のWebではよく利用されている。国内ではmixiでの事例がよく知られている。

http://ja.wikipedia.org/wiki/Memcached

この話を初めて聞いたとき、うーん随分乱暴な話だな、RDBMSでやるべき仕事だろ、そーゆーことはと思った。由緒正しいRDBMSではこーゆーのはいかんだろう的なことを思った。しかし発想の転換というかちょっとしたハックというか、実際memcachedのソースコードは6千行位のきわめてシンプルな実装になっていて、MySQLとかスケールしねーよなあとか思っていたハッカーが自分の問題を素早く解決するために作ちゃったという感じなんだろうな、などとも思う。作ってみたら思いのほかいい感じで使いやすくて、どんどん適用事例も生まれ、ソースコードもオープンなので、米国あたりのWeb2.0系企業でがしがし使われるようになったと。

昨今OSやらRDBMSやらアプリケーションサーバやらWebサーバやらありとあらゆるものがオープンソースなので、どこで問題を最適化してもよくてRDBMSの上にちょっとしたキャッシュをおいて擬似的に高速化をはかってみたというのがmemcachedなのだろうなと思う。

mixiでは135台のmemcachedサーバを利用していて(この数もすごいな、国内最大級かな)、メモリを3GBほどわりあてているらしい。マシンはPentium 4との事なので発熱とかもすごそうな気がする。

KLABの安井さんのお話はmemcachedのreplicationだった。memcachedはシステムが死ぬとデータが消失するので、リプリケートをして永続性を持たせたいなあというお話である。永続性とかフェールオーバーとか信頼性とか、そーゆー事を言いだすと、話がどんどん複雑になるのでmemcachedとは相性が悪いのではないだろうかと思うのだけど、どうなんだろう。この手の話も昔からあって、本当の信頼性を求めるなら完全二重化とか、そーゆー話になるのだけど、コストと拡張性のバランスも必要で、さらにはスケーラビリティをどうするかという問題もあって難しい。また非同期の更新だとどうしても原子性をどう担保するかという問題もある。いっそのこと楽観的にやっちゃて、矛盾が発生したらリトライという感じでもいいのかもしれない。

すずききよたか(kiyotaka)さんのお話はmemcachedの利用をいろいろな角度からしていた。まあ、消える可能性のある汎用DBというのは言いえて妙である。Solarisで運用しているので、Solarisのお友達を募集していた。困っている事を自分から晒すというのは勉強会メソッドとしては黄金のパターンかと思う。そして同志と出あう。memcachedを使っているだけではなくSolarisで使っているという同志の結束は固そうに見えた。

mixiの長野(kazeburo)さんは大規模事例で、特にがりがりチューニングをしているという感じではなかった。

はてなの田中(stanaka)さん、30台のcore2 quad メモリ8GBで運用している。それぞれにはXenでmemcachedサーバとアプリケーションサーバを起動しているらしい。こちらも特にチューニングしているという感じではなかった。

mixiの前坂(tmaesaka)さんはmemcached Binary Protocolの解説である。こーゆープロトコルの設計の話は好きだ。速度命だし。テキストのプロトコルだとパースデコードのコストがかかるのであらかじめ定義したバイナリのプロトコルで高速化をはかろうというお話である。バイナリプロトコルであればインジェクションは簡単ではないのでセキュリティ向上にもつながるよ。

固定長のヘッダ(16バイト)+可変長のオマケのフィールドというデータ構造になっている。

http://code.sixapart.com/svn/memcached/branches/binary/server/doc/protocol-binary.txt

opcodeが1バイトなので要素256個の配列で命令実行ルーチンが書ける。デコードのコストは表引きだ。これがASCIIテキストだとstrcmp(command,"hogehoge")みたいなものを延々コマンドの数だけ書くはめになって、コマンドの数に比例したデコードコストがかかったりする。(まあパーフェクトハッシュ関数とか書けばいいのだがカジュアルに命令を追加したりとかはいろいろ面倒なので、結局はstrcmpで延々比較という泥仕事になる)

opcodeを固定長にするというのは王道中の王道のテクニックである。CISCに対するRISC的なアプローチと言ってもさしつかえない。

まあ、そんなことを思ったのだが、この手の古典的な高速化のテクニックというのは昔からずうっと変化していなくて、再発見、再発明が延々繰替えされているような気もする。

温故知新なのである。

でもって現在の実装についてちゃんとoprofileとかでミクロのプロファイリングを取って、チューニングをはじめたという事ではなく、なんとなく直観でぐわっとやっているらしい。まあ、それでもいいっちゃいいのだけど、ちゃんとベンチマークを定義して、oprofileなどでプロファイリングをして、ボトルネックを数字で示し、チューニング大会をするというのが正しい大人の姿である。

いろいろ設定準備とか大変だとは思うが、一度そのような環境を構築してしまえば、開発の最中、運用時等々貴重なデータを入手でき、パフォーマンスデバッグ(チューニング)のインフラになる。開発のプロセスに組込むというお作法は重要だ。なかなか実践するのは難しいが。

プロファイリングしてチューニングをする。王道中の王道だ。

まあ、こーゆーことをお酒を飲みながら、わいわいがやがや語るというのも勉強会の醍醐味でもある。

おまけ：

ソースコードはgithubで公開されているのでためしにゲットしてみた。

$ time git-clone git://github.com/tmaesaka/memcached.git
Initialized empty Git repository in /proj/memcached/.git/
remote: Counting objects: 1602, done.
remote: Compressing objects: 100% (472/472), done.
remote: Total 1602 (delta 1161), reused 1537 (delta 1108)
Receiving objects: 100% (1602/1602), 592.77 KiB | 237 KiB/s, done.
Resolving deltas: 100% (1161/1161), done.

real    0m4.901s
user    0m0.612s
sys    0m0.084s

memcached.c の dispatch_bin_command() はバイナリプロトコルのディスパッチルーチンであるが、だめじゃん。

switch(c->cmd) {
    case PROTOCOL_BINARY_CMD_VERSION:
略
とかしている。ここは表引きだろう。しかもc->cmdの定義はuint8_tではない。だめじゃん。深入りしないことにした。

プログラマ35歳定年（停年）説

わたしに不用意にふってはいけないネタとして、プログラマ35歳定年（停年）説というのがある。飲み会かなにかの席でなにげなく、そのような話題を出し、延々聞きたくもない話を聞かされた被害者の方も少なくない。

血圧があがるネタである。

誰がいつごろからそんな事を言ったのだろう。

まあ、それはともかく、プログラマといってもいろいろあるわけで情報技術(IT)という分野も話している人によって全然違う話しをしているのに、双方とも気がついていなくて延々すれ違いの議論をするということも多い。

例えば、ITについても、(1)OSとかコンパイラとかRDBMSとかいわゆる基盤系技術、(2)エンタープライズ系(企業の情報システムとか)、(3)ミッションクリティカル系(勘定系、社会基盤系(電力送電網)とか)、(4)Webサービス系(Web2.0?)、(5)組込系(いろいろ)、などなど種々雑多ある。

またビジネス形態としても、(a)ソフトウェア製品開発、販売、(b)SI(受託開発)、(c)コンサルティング、(d)運用サービス、サポート、(e)Webサービス(Web2.0?)等々これまたいろいろある。

日本にはマイクロソフトとかOracleみたいな基盤系のソフトウェア製品開発販売の専業ベンダーというのはほとんどなくて、大手ハードウェアメーカがハードウェア販売のおまけ(？)みたいな感じで細々と商売をしていたりする。

そーするとだ、RDBMSを作りたいとかOSを作りたいと思った若者は、当該製品を作っている主に外資系に就職するくらいしか選択肢がなかったわけだ。大手ハードウェアメーカに就職しても商品としてのOSとかRDBMSの開発はほとんどやっていないので自分のやりたいことはできない。

昨今だとLinuxやMySQL/PostgreSQLなどオープンソースソフトウェアのおかげで別に大手ベンダーなり外資系ベンダーなりに就職しなくても、意欲さえあれば自分でがんがんコードを書くことは可能になった。

わたしのキャリアは1-aのパターンで、それ以外のところには正直土地勘がない。デスマーチの大規模エンタープライズ案件の修羅場とかはくぐったことがないので実状はどうなのかよくわからない。

最近はmixi、モバゲー、ニコ動などWebサービス系の開発現場のお話を聞く機会が多いのだが、その開発スタイルというのはウォーターフォールモデルとは全くことなる原理原則で開発されていて、それはそれで大変興味深い。

SIなんかは多重下請け構造みたいなのに組みこまれてしまうと単価勝負の世界になって人月いくらという話になるというのは理屈ではわかる。でもそれって経営者が、そーゆー判断したんじゃね？経営の問題じゃね？とか思う。

そーするとやはり案件ごとの受託開発よりも自社開発のソフトウェア製品開発とかWebサービス、あるいは運営サービス、サポートなんかの方が自社の強み特長をいかせておもしろいような気がする。

技術についても基盤系であればかなり蓄積が効くし、経験のつみかさねが強みになる。

そんでもって35歳停年説にもどるのだが、わたしがシリコンバレーに行ったのは36歳で、コードを書きまくったのが30代後半だった。未踏ソフトウェアは44歳、Cache Pollution Aware Patchは46歳、取締役退任。生涯一プログラマ宣言は49歳。そしてこの9月4日で50歳だ。

年齢は関係ない。限界を決めるのは自分だ。

Do not limit your self.

注記：定年の表記に関しては当初は停年と記していましたが、定年の方が一般的なようなので、そのようにしました。

未踏ソフトウェア奮闘記
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030619/1/
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030619/2/
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030709/1/
http://itpro.nikkeibp.co.jp/members/NSW/ITARTICLE/20030709/2/

Linux Kernel 2.6.18とCache Pollution Aware Patch/ユメのチカラ
http://blog.miraclelinux.com/yume/2006/09/linux_kernel_26_2c2c.html

エンジニアの未来サミット
http://gihyo.jp/news/report/01/engineer
http://gihyo.jp/event/2008/engineer
パネリストとして参加します。

創刊号巻頭座談会「エンジニアのマインドとは」～ボーナストラック
#3　座談会「エンジニアのマインドとは」
http://gihyo.jp/dev/serial/01/talks-bt/0003?page=2

プログラミングはパッションだ

この夏、セキュリティ＆プログラミングキャンプとU-20プログラミングコンテストの実行委員、審査委員をした。若い人達のプログラムに対する姿勢を身近に接っする機会があった。

キャンプは4泊5日の長丁場だし、U-20プログラミングコンテストの審査は一次審査、最終審査それぞれ丸々一日、ずっぽり若者のプログラムにひたりっぱなしであった。体力勝負の感もなくはないが彼等の発想を真のあたりにする大変貴重な機会となった。

プログラミングの技能(テクニック)はおそらく座学でも伝達できる。細い技術的な事は授業することができる。だけど、プログラミングの楽しさや面白さをどう伝えたらばいいのだろう。プログラミング言語の文法を教えることがプログラミングの楽しさを伝えることになるのか、デバッガのコマンドを教えることがプログラミングの面白さを伝えることになるのか。

コンピュータの仕組をしらなければ、プログラミング言語の文法をしらなければプログラミングはできない。最低限の事は知っている必要がある。その上で何を教えるのか。何を共有するのか。

彼等は生まれたときからコンピュータが身近にあった。物心ついたときにはインターネットがあたりまえであった。ディジタル・ネイティブである。空気のようにネットやコンピュータをあやつる。

彼等にわれわれは何を伝えるのか。どのような言葉をわれわれは持っているのだろう。そんなことを考えた。

U-20 プログラミングコンテストに応募された様々な作品を審査したときに考えた。

プログラムは自己表現だ。自分が何かをしたいと強く思うことによって、ハッカーはなにがしかのものを作る。その強い意思、強い思いがあってこその技術力であり表現力である。

確かに中学生(!)、高校生のプログラミングテクニックは、プロの目から見ればまだまだ未熟なものかもしれない。だけど、何物かを作りたいというパッションは誰にも負けない。そのパッションがわれわれの心を揺振る。

技術は教育できるかもしれなが、パッションは教育できない。それは一人一人が自分で獲得していくしかない。

われわれにできることがあるとしたら、そのようなパッションを持っている若いプログラマを発見し、彼等彼女等が思う存分活躍できる場を提供することぐらいだろう。一緒になって、そのフィールドを作っていくことぐらいだ。

技術はコピーできても、パッションはコピーできない。

そのような、あたりまえな事に気がつかせてくれた若いプログラマ志願者に感謝をしたいと思う。

英語を学びたいと思うこと

英語の勉強法の事ではない。

先日のLL Futureの感想を書いてたいろいろな人のブログやら日記やらを読んでみた。自分の英語だめすぎ(涙目)、もっと英語ができたらなあ(願望)、よし英語を勉強しちゃる(希望)などなどいっぱい目にした。

間違いない。英語は出来ないより出来た方が絶対自分の世界が広がる。断言する。

プログラミングの世界は英語が第一言語だというのは紛れもない事実だ。Larryに日本語を覚えさせるより自分が英語を勉強した方がどれだけ自分にとってメリットがあるかという話だ。

その意味で今回のLL Futureは未来のまつもとゆきひろを作るためにも、多くの若い(おじさんもいたけど)プログラマに英語を獲得する必要性をリアルに示したという大変な貢献をした。

通訳は必要ない。

英語ができなければ悔しい。その悔しさをモチベーションにする。Larryと話したい。それがモチベーションだ。自分のコードを見せたい。そのために英語を学びたい。そーゆー思いを喚起させた素晴しい経験を多くの参加者にあたえたのではないだろうか。

あえて通訳しないというのが素晴しいハックだと思った。

LL Future

週末LL Futureに行ってきた。朝の10時から夜9時まで11時間の長丁場である。参加するだけでもヘロヘロなのだから裏方の実行委員や発表者の皆様のご苦労は大変なものだろう。感謝。

わたしがこの夏のLLイベントにはじめて参加したのはLL Ring (2006)からで、昨年のLL Sprits(2007)、そして今回のLL Future (2008)というような感じである。

基調講演はPerlのLarry Wallである。Perl 6のお話をするのだけど、言語そのものの拡張機能をビルトインするらしい。うは、Lisp的な。しかし、ふつーの利用者は、言語の文法を拡張したいのだろうか？シンタックスをばりばり変更拡張して、俺様言語を作るというのをふつーの利用者は望んでいるのだろうか。

うーむ。よくわからない。むしろ言語設計者の役割は、様々なプログラミング言語のアイデアを絶妙なバランスで取捨選択して、デフォルトとしてふつーの利用者に提供するのがお仕事なのではないだろうか。

昔のプログラミング言語は会議室で設計された。FORTRANもCOBOLもAdaもLispですら標準化委員会で設計された。LLの場合は、そうではなくて一人あるいは少数のハッカーによってコアが設計された。PythonもPerlもRubyもそうである。

Perlの力はCPANのようなコミュニティが開発した豊富なライブラリにある。言語は、それらの膨大なライブラリによってささえられている。であるとするならば、文法の独自拡張は、そのコミュニティを分断することになるのではないかと思ったりする。つまりXXの機能を利用するためにYYという文法定義が必要で、それが従来のZZとコンフリクトするので素直には利用できない。ライブラリやパッケージでも同様な問題はおきなくはないが、文法は通常一緒なので最悪コピペ的に回避することは不可能ではないが、文法をいじってしまうと、それも簡単ではない。

言語の拡張可能性というのは昔からとりざたされている機能ではあるが、実用的な観点からは大きな？マークである。

動的言語はおおかれすくなかれeval的ななにがしかを持っているので拡張可能性を持っているのだが言語要素そのものを自由に追加、変更できるというのは、バザールモデル的にはあんまりお得ではないような感じがする。

最近は言語仕様についてもバザール的にわいわい開発するモデルが主流になりつつあるので、特にそう思ったりする。

「LLで未来を発明する」パネルディスカッション。参加者はLarry Wall、まつもとゆきひろ、藤田善勝、住井英二郎、ひげぽん。

未来の話はほとんどでてこなくて、かと言って何かびっくりするくらいクレージーな話でもなく凡庸(？)なお話になっていた。問題設定が100年後の未来という事であったので、そんなのわかんねーよというのが普通の感覚なので、10年後の未来とかあるいは6分後の未来とかの方が話が盛り上ったのではないかと思った。

それこそコンピュータアーキテクチャがノイマン型(プログラム内蔵方式のコンピュータ)であるならば、どっかのレベルではメモリという概念が必要になってきて、関数型のOSやらshellを用意したところで、どうしてもC的なレイヤがでてくる。

ふつーの人がプログラミングしないなんていうのは昔から言われているわけで、いまだってふつーの人はプログラミングしない社会である。

そうではなくて今後のコンピュータを作る人がどのようなプログラミングモデルを必要としているのか、ぐらいのことは語ってほしかったぞと強く思ったパネルディスカッションである。

その後、いろいろと興味深いパネルが続くのであるがまじめなセッションよりもコードゴルフとかおなじみのライトニングトークとかの方が楽しめた。

しかし、プログラミング言語のイベントに1000人も集まってしまうなんて異常だ。いったいどーゆー事だ。しかも朝から晩まで11時間も数百人の人達がわいわいがやがや楽しげにやっているなんて、すごいすごい。

日本はじまったな。

11時間にわたる長丁場お疲れさまでした、そしてありがとうございました＞参加者の皆さん