ユメのチカラ

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

週末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時間にわたる長丁場お疲れさまでした、そしてありがとうございました＞参加者の皆さん

WEB+DB PRESS Vol.46

WEB+DB PRESSの人気インタビュー「小飼弾のALPHA GEEKに逢いたい」にインタビューされる側として登場した。詳細は本誌にゆずるとして、その時のお話をいくつか。

6月末の取締役CTO退任のブログをうけて、いろいろな方にインタビューを申しこまれて、弾さんのインタビューもその一つなのであるが、一番最初にじっくり話したのが、このインタビューである。

通常は弾さんのマシンガントークにインタビューイーが答えるという形式になるかと思うのだが、今回は、どちらと言うと、わたしがガンガンしゃべるまくるという感じになった。プログラマとしていろいろ思うところを語ったので、ぜひ読んでほしい。

インタビューはテープ起しで40頁分になって、そのうち4頁を掲載している。さらに場所をうつして居酒屋で40頁分を語りに語った。あーー楽しかった。すっきり。掲載されているのはしゃべった分の10%なので、濃縮還元ジュースみたいな感じになっている。

削りに削っての構成インタビューなので密度は濃い。

弾さん、編集の細谷さん、ありがとうございました。

404 Blog Not Found 予約開始 - WEB+DB PRESS Vol.46
http://blog.livedoor.jp/dankogai/archives/51098820.html

プログラミングキャンプ

この夏、8月13日から17日まで、セキュリティ＆プログラミングキャンプ2008というの企画した。わたしも講師の一人として、プログラミングキャンプに参加する。

セキュリティ＆プログラミングキャンプ2008 http://www.jipdec.jp/camp/
セキュリティ＆プログラミングキャンプ2008/ユメのチカラ　http://blog.miraclelinux.com/yume/2008/06/2008-7e81.html

わたしのやりたい事。プログラムの楽しさを少しでも若い世代に伝え、仲間を少しでも増し、プログラマがプログラマとしての専門性をいかし生き生きと豊かにおくれる社会をつくること。

高度ICTリーダー論/shi3mの日記http://d.hatena.ne.jp/shi3z/20080807/1218068383

もっと若い相手、たとえば高校生や大学1,2年生などを対象に、もっと幅広い講師を呼んで講演会を開き、刺激を与えた方が「真のトップノッチ」育成には役立つのではないか。

まさにプログラミングキャンプはそのような明確な意図のもと合宿形式でトップノッチの発掘、養成をめざしている。

それにはどのようなカリキュラム(プログラム)がよいのか、今年は初めてなので文字通り試行錯誤の連続である。

わたしは、デバッグの方法、コードリーディング、プログラミング入門をうけもつが、シラバスを作り、プレゼン資料、実習問題、デモの準備など、正直いってへろへろである。はたしてこのような問題設定でよいのか、はたしてこのような教材でいいのか、そもそも、このカリキュラムでいいのか、そのようなことを自問自答しながら七転八倒し教材を作成した。

まだ実際の講義をしていないので、何とも言えないのだが、講義という学生とのコラボレーションでわたしも多くのことを学ぶだろうし、多くのことを経験するだろう。そしてそのフィードバックは次に生かしていくつもりである。

単にプログラマとしてひいでているだけではなく、コミュニティのリーダとして人々に信頼され、尊敬されるような人材と巡り会いたい。養成とか育成とか、そのような上から目線ではなく、可能性を持つ人々を発掘し、生き生きとその才能を開花させるような環境を作りたい。

そのためにはその中間地点として、彼らがその才能を十二分に発揮できる環境を作るのがわれわれ大人の仕事で、それは具体的には、彼等を雇用できるようなビジネスを創出することが最ももとめられていることである。

Googleに多くの若い才能が結集しているのは、それは我々が十分彼らの才能を生かす仕事場を提供していないからである。日本のタレントを流出させているのは、我々がそのプレイグラウンドを提供していないからである。

その意味で、id:mkusunok の指摘は正しいと思うが、
geek虎の穴をつくろう/雑種路線でいこう http://d.hatena.ne.jp/mkusunok/20080807/ito

恐らく優秀なプログラマーなら日本にも少なからずいる訳で、私塾ではgeekに対してグローバルな視座や搾取されないだけのビジネススキルを獲得できる機会を提供し、geekだけでなく、彼らが活躍できる環境を整えることのできるようなサポーター、具体的には優れたビジネスマネージャやマーケティング、政策立案者も育てる必要がある。手をつけられそうなところから具体的なカタチにしていきたい。

育てるだけではなく、そのような社会環境を作るのが我々の仕事である。今まさに楠さんや清水さんにはそのような役割が求められているのである。

先行評価(Eager Evaluation)勉強法とトラブルシューティング

新人プログラマのよしおかです。どうぞ、よろしくお願いいたします(ぺこり)。という日々を送っている。日々のトラブルシューティングの話なんかをここに記したい。

そもそもAsianux Mobile Midinux 2.5Jというのは、Intel Moblin(http://www.moblin.org)準拠なのでいろいろお作法が違う。

debianのパッケージング方法なんかも一から勉強である。最近はインターネットのおかげで高速道路が整備されているので、必要なマニュアルは全てオンラインで入手できる。debianのドキュメントの充実度は目をみはるものがある。一見遠回りのようでいても、ドキュメントをひととおりざっと眺めてみることは、重要である。何か問題にぶちあたったときにググって断片的な回答を発見するのではなく、まづマニュアルにあたってじっくり仕組から理解をする。すぐに回答にたどりつかないように見えてもそれは自分に対する投資なのであせらない。習熟曲線というのは最初はなだらかで、ある程度いくとぐぐっと立ち上がる。そのぐぐっと立ち上がるところまでは自分に対する投資である。

まわりにいる、debian使いの人のお世話になって、最初の道案内をおねがいし、読むべきドキュメント、マニュアル類をおさえる。これ非常に重要である。必要になるかならないかわからないけどドキュメントをちゃんと読む。Eager Evaluation(先行評価)勉強法である。で、わたしは、その投資のリターンが非常に高いことを経験則として知っている。ドキュメントを読む時間(投資コスト)は低いので、ローリスク、ハイリターンな投資となる。

日記界隈のハッカーは遅延評価勉強法をとっているようである。何か問題にぶつかったら、それについて調べるというスタイルである。こちらの方が、一見レスポンスタイムが短かくお手軽ですぐれているように思えなくもない。しかし、一つのことを極めようと思ったら初期投資をおそれてはいけない。結局はマニュアルなど原典にあたることになる。

まあ、こーゆースタイルは誰かに強制するつもりもないし、強制できるものでもない。遅延評価で場当たり的にやっていても結局いつの日かマニュアルを読むことになって実はああ何か遠回りをしたなあと気がつく。マニュアルをはじから読むなんていうことは、自分にはなかなかモチベーションをキープするのが難しい。どうしてもつまみぐいになってしまう。という声も聞くが、人それぞれなので、もちろん強制はしない。

わたしなんかは、何度も言っているようにIntel Software Developer's Manualを読むのが趣味という芸風なので特殊例だとは思うが。

で、トラブルシューティングのお話なのであるが、最初はその問題について初心者で動作原理を十分理解していないから、現象を見ただけでは、なんでそのような現象が発生するかチンプンカンプンの状態からはじまる。これが、その問題についてのいろいろ経験して理解がすすんでいけば、現象を見ただけで、ある程度原因がわかっちゃったりするのであるが、そこにいくまでは、いろいろな試行錯誤の連続になる。プログラマはその経験のつみかさねで自分の適応可能領域をどんどん広げていくことになる。

初心者の場合、毎回毎回初めてみる現象に遭遇し、そのたびに、わけがわからなくて、どこからあたりをつけていいかわからないので、試行錯誤をくりかえす。初めての問題なので、そもそも簡単な問題なのか難しい問題なのかすらわからない。ひょっとしたらとんでもない超難問にぶつかってしまったのではないだろうかとか不安になったりもする。解決するには何日も何日もかかるような問題なのではなんて思ったりもする。

第一歩は問題を正しく理解することである。何がおこっているか正しく理解することである。安易な解決策に飛びつこうとしない。先入観をすててありのままに現象を観測する。それが第一歩である。

先日遭遇した問題はこんな問題であった。

ソースコード管理システム(git)からソース一式を持ってきて(git-clone)してビルドする。問題なくビルドできる。いろいろ変更して再度ビルドすると、ビルドできない。Makefile他ビルドシステムそれ自身は一切変更していないので何がなんだかわからない。こーゆー状況に遭遇した。

問題を切りわけるために、原点にもどってみる。git-cloneしてビルドする。問題なくビルドできる。いろいろ変更したのが問題かもしれないので、何も変更しないでビルドしてみる。ここが最初のチェックポイントだ。ビルドが失敗する。ここからトラブルシューティングの旅がはじまるのである。

何がなんだかわからない事は、その通りなのである。解決できるかできないかも、その時点では見通しすらたっていない。どういう戦略でトラブルシューティングをしていくか。

ビルドのログをじっくりながめてみる。エラーがないのか、あるのか。ビルドができないのは結果であって何でビルドができないのかを理解することが必要になる。そうすると、パッチをあてることを失敗している。なぜなんだろうか？debianパッケージの場合オリジナルのソースに独自パッチをあて、その後ビルドをするというプロセスになる。

なぜパッチをあてることを失敗しているのだろうか。

ビルドする前に前回あてたパッチをとりのぞいて真っ新な状態にする。そして、今回ビルドするにあたって再度パッチをあてビルドする。ログを見てみると、前回あてたパッチをとりのぞくことに失敗している。そのために同じファイルに2度目のパッチをあてることをこころみ結果としてそのビルドに失敗している。

なぜパッチをとりのぞくことに失敗しているのだろうか。

問題のパッチのコードを眺めてみることにする。失敗したパッチには.rejというファイルができているので、それもあわせて読む。

パッチのコンフリクトしている部分がrejファイルには記述されているので、それを見た。

そうすると、ある行についてパッチがあたらない。なぜか。

パッチファイルにはTABで書かれていたが、それが空白に変換されて適用されていた。そのためパッチをとりのぞく時に、とりのぞけなかった。

さて原因がわかった。現象を分析し正しく理解すれば原因がわかる。原因がわかれば解決策を作るのは簡単である。パッチファイルのTABを空白にした。再度ビルドしてみてビルドできることを確認した。

理解してみれば他愛のないことである。しかし現象をみた段階で、何がなんだかわからなかったことも事実である。問題を一歩一歩理解していくといくプロセスがトラブルシューティングの王道である。

その道標としてマニュアルをきちんと理解しておくことが重要である。

ハッカーと遅延評価勉強法/Slow Dance
http://d.hatena.ne.jp/LukeSilvia/20080402/1207149044

私の言語遅延学習法 - 三つのルール+1/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50999338.html

遅延評価的勉強法/IT戦記
http://d.hatena.ne.jp/amachang/20080204/1202104260

初めてのRuby

「初めてのRuby」は、他のプログラミング言語の経験があるプログラマ向けのRuby入門書である。プログラミングの入門書ではない。この明確なターゲット読者の設定がこの本の特長であり成功の要因である。

すくなくともわたしにとって、他言語(C言語)でのプログラミング経験があるものにとって、これほどまでにコンパクトかつ明解にRubyの真髄を語っている本書ほど、ありがたいものはない。

わたしはかねてからプログラミング言語の文法書は50ページ以内であるべきだと思っている。プログラミング言語の構文はシンプルであればあるほどいい。道具はシンプルな方が応用が効く。

それはともかく、プログラミング経験者にとって、第二、第三のプログラミング言語を学習するということは、計算機の入門、例えば計算機はどう動くかとか、メインメモリ、CPU、外部記憶の機能はどうだという事を学んだり、プログラミングの入門、アルゴリズムとか、計算量、データ構造、例えば、表、ハッシュ、N分木等々について学ぶのではなくて、そのプログラミング言語の文法や意味論を、そしてそのプログラミング言語の背景にあるプラグマティズムを学ぶことである。

つまり第二第三のプログラミング言語を学ぶということは、その言語が持つ哲学、思想、あるいは開発コミュニティのお作法までも含めた何がしかを学ぶことである。例えば、Perlという奇妙なプログラミング言語を学ぶということは、CPANというPerlハッカー達がよってたかって作ったライブラリのレポジトリについての何がしかを学ぶということで、そのような事を含めて理解してはじめてPerlという言語を学んだということになる。

なぜわざわざそのようなプラグマティズムを貴重な時間コストをかけてまでプログラマが学ぼうとするのか。そこにはそのコミュニティがはぐくんでいるベストプラクティスがあって、それは言語の壁をこえた普遍性があり、それを学ぶことの意義というのは強調されても強調されすぎることはないと考えている。

「初めてのRuby」はRubyを愛してやまないYuguiさんが、Ruby初学者に向けてRubyを学ぶ道標をあたえている。

他言語を使いこなすプログラマに向けて極めてコンパクトかつ明瞭にRubyのプラグマティズムを紹介している。言語の文法書にはでてこないRubyの考えかたを紹介している。

なぜRubyではforで繰り替えしを書かないのか。C言語族に属するわたしにとってYuguiさんの説明は明瞭でかつ説得力がある。なるほどなるほど。

先日、tokyo-emacsというemacs利用者(初心者からハッカーまで)の集りで、いろいろなelispのコードをながめたのだが、そのコードのスタイルが、なにかCを感じさせるものが多く、皆で「これってCだよなあ」というような事を言っていた。関数型と呼ばれる言語(elisp)ですらCの影響を受けたプログラマが書けばCの匂いのするプログラムになってしまうのである。

プログラミング言語がノイマン型コンピュータを抽象化し動作可能なものとしたのなら、そのプログラミングパラダイムはおおかれすくなかれ似たようなものになる。変数という概念があり、メモリはアドレスというもので識別され、そこには状態を保持するので、代入という概念を持つ。手続型としてくくれるものは、ほとんど似たようなものだと言える。このプログラミングパラダイムの中で様々な文法的な選択肢を絶妙なバランスで取捨選択したのがRubyであり、その取捨選択の思想をわかりやすく説明しているのが、本書である。

プログラミング経験者が第二、第三のプログラミング言語を学ぶ意義はなにか。プログラミング言語の瑣末な文法上の差異を学ぶことが重要なわけではない。プログラミング入門的な知識を得るために行なうのではなくて、言語設計の思想、ライブラリや、それを作りあげている開発者の思い、考え、ひいてはそのプログラミング哲学について学ぶというところにある。その言語コミュニティが持つ暗黙の哲学、価値観を学ぶプロセスにある。

しかしながら、そのような暗黙の哲学、価値観は究極にはそのプログラミングコミュニティに属し当事者にならないと容易には獲得できない。

本書は、そのコミュニティの入口まで初学者を連れてきてくれる。

Ruby初心者も中級者もばりばりのRubyハッカーも本書から得られるものは大きい。初心者にとっては、Ruby言語のみならずその思想にふれられるところ、中級者にとっては、そのRubyらしさという必ずしも明確になっていなかったものに対する指針がえられるところ、ばりばりのRubyハッカーにとっては、今まで空気のように感じていたRubyらしさというものを明示的に表現するというのはどのような事かということを整理、理解するつてとして本書の意義は大きい。

Rubyコミュニティの豊かな土壌からRubyKaigi(本当に素晴しい会議だ)があり、本書のような良書が生れ、多くのrubyistを拡大再生産している。持続可能なコミュニティはその文化を明示的に外に示し新人をリクルートする。素晴しいことである。

本書はRubyコミュニティの豊かさの象徴であると言っても過言ではないと思う。皆様にお勧めする。

-------------------------------
読んでいて気がついた誤殖など。
p53
誤：a >> 1  #=> 0b100
正：a >> 1  #=> 0b110
誤：a << -1 #=> 0b100
正：a << -1 #=> 0b110

p71
誤：p story[8, 7]     #=> "Grundy"
正：p story[8, 7]     #=> "Grundy,"
誤：p story[8...15]   #=> "Grundy"
正：p story[8...15]   #=> "Grundy,"

-------------------------------
索引について。

宇宙船演算子(p52)という見出しはあるが、"<=>"での見出しはない。ところがp36で<=>が初出するが何の解説もないので読者はp52を読むまで理解できない。索引で<=>の見出しがあれば、とりあえづそれを引いて疑問は解決する。

後方参照について

後に説明する項目については、多くの場合、明確にどこどこで説明すると明示してあるので安心して読みすすめる。下記は、いくつかの例外。

p112
def some_method(param = nil)
この構文(デフォルト値をあたえる)についていきなり解説なしで登場し、とまどった。

-------------------------------
p124
本章で扱っていないこと
イテレータとでているが、p119 6.3.6 イテレータを解説しているのではと思う。

p130
階乗の定義で、わたしなら再帰で書くなあと思った。
def fact(n); if n==0 then 1 else n*fact(n-1) end end

vi はじめに
File.chmodとFile#chmodの違いというのが結局どこらへんにあるのか良くわからなかった。

-------------------------------
本書を越える範囲のことについて

続編があるとしたら(勝手に期待するところであるが)、以下についてRuby風のお作法をぜひ読みたい。

テストの仕方
デバッグの仕方
性能のチューニング方法

-------------------------------
『初めてのRuby』サポートページ
http://yugui.jp/wiki/hiki.cgi?LearningRuby
『初めてのRuby』正誤表
http://yugui.jp/wiki/LearningRuby-Errata

プログラマ一年生のパッチと大物ハッカーのコード

「取締役退任。生涯一プログラマ宣言。」には大変な反響をいただいた。ここに記して御礼の気持ちとさせて頂く。トラックバック、ブックマークコメントなど可能な限り読んだ。過分のおほめ、励ましの言葉にあずかり、大変光栄に思う一方で厳しいお言葉も頂戴し皆様のご期待にそうよう一層精進していきたいと思った。

さて、プログラマ一年生である。最近では、MID (Mobile Internet Device)の開発にいそしんでいる。CPUもIntel Centrino Atomプロセッサだ。

ソフィアシステムズ Peartree用OS Asianux Mobile Midinux 2.5Jである。
http://www.sophia-systems.co.jp/ice/intel/Atom/PEARTREE/

インストーラを作っているのだが、先日ブートローダ(syslinux/extlinux)のバグに遭遇しそれを直すパッチを作成した。メーリングリストに報告したのが、7/2 18:35:14 PDT(米国西海岸夏時間)である。それに対する返事が、同日19:57:02 PDT(米国西海岸夏時間)、一時間ちょっとで、さっそく取り込んでくれた。その返事も素早いが、それだけではなく、リファクタリング(コードの改良)もしてくれた。

So it does (although the *real* problem is the lack of the stat and
device number comparison.)  I just applied a (slightly different) patch
to this and pushed it out as 3.71-pre3; could you try it out?

よしおかの超訳：バグだね(本当の問題はstatと装置番号の比較がなかった事だけど)。この問題に対するパッチ(ちょっと変更したコード)を適用し、それを3.71-pre3にいれておいた。試してみてくれる？

バグのあったコードは下記の部分である。細かい理解は必要ない。単にパターンマッチをして、上のif文と下のif文が対称じゃないことがわかればいい。

  if ( (mtab = setmntent("/proc/mounts", "r")) ) {
    while ( (mnt = getmntent(mtab)) ) {
      if ( (!strcmp(mnt->mnt_type, "ext2") ||
            !strcmp(mnt->mnt_type, "ext3")) &&
           !stat(mnt->mnt_fsname, &dst) &&
           dst.st_rdev == st.st_dev ) {
        devname = mnt->mnt_fsname;
        break;
      }
    }
  }

  if ( !devname ) {
    /* Didn't find it in /proc/mounts, try /etc/mtab */
    if ( (mtab = setmntent("/etc/mtab", "r")) ) {
      while ( (mnt = getmntent(mtab)) ) {
        devname = mnt->mnt_fsname;
        break;
      }
    }
  }

マウントされているファイルシステムのうち、ext2/ext3ファイルシステムを検索しているのであるが、上の部分は/proc/mountsで検索し、それがみつからなければ/etc/mtabで検索している。コードをじっくり眺めてみれば、下の部分のwhile(){...}で

      if ( (!strcmp(mnt->mnt_type, "ext2") ||
            !strcmp(mnt->mnt_type, "ext3")) &&
           !stat(mnt->mnt_fsname, &dst) &&
           dst.st_rdev == st.st_dev ) {

という比較がすっぽり抜けおちている。まあ、わかってしまえばトリビアなバグなのであるが現象としては謎であった。

なので、さっそくquick and dirty hackで下記のパッチを先のメーリングリストに投げたのである。

--- extlinux.c.orig    2007-02-10 20:47:08.000000000 +0000
+++ extlinux.c    2008-07-02 15:20:20.000000000 +0000
@@ -708,8 +708,13 @@
     /* Didn't find it in /proc/mounts, try /etc/mtab */
     if ( (mtab = setmntent("/etc/mtab", "r")) ) {
       while ( (mnt = getmntent(mtab)) ) {
-    devname = mnt->mnt_fsname;
-    break;
+        if ( (!strcmp(mnt->mnt_type, "ext2") ||
+              !strcmp(mnt->mnt_type, "ext3")) &&
+             !stat(mnt->mnt_fsname, &dst) &&
+             dst.st_rdev == st.st_dev ) {
+       devname = mnt->mnt_fsname;
+      break;
+    }
       }
     }
   }

7行追加のパッチである。まあ、素人目にはこれで一件落着である。

個人的には、ソフトウェア変更における、修正量最小化の法則、修正個所局所化の法則にのっとっているので、美しくはないかもいれないが、quick and dirty hackとしては合格点かと思った。

メンテナのちょっと変更したパッチというのが下記だ。

diff --git a/extlinux/main.c b/extlinux/main.c
index 0edce5a..819f74b 100644 (file)
--- a/extlinux/main.c
+++ b/extlinux/main.c
@@ -801,6 +801,32 @@ static int validate_device(const char *path, int devfd)
   return (pst.st_dev == dst.st_rdev) ? 0 : -1;
}

+#ifndef __KLIBC__
+static const char *find_device(const char *mtab_file, dev_t dev)
+{
+  struct mntent *mnt;
+  struct stat dst;
+  FILE *mtab;
+  const char *devname = NULL;
+
+  mtab = setmntent(mtab_file, "r");
+  if (!mtab)
+    return NULL;
+ 
+  while ( (mnt = getmntent(mtab)) ) {
+    if ( (!strcmp(mnt->mnt_type, "ext2") ||
+         !strcmp(mnt->mnt_type, "ext3")) &&
+        !stat(mnt->mnt_fsname, &dst) && dst.st_rdev == dev ) {
+      devname = strdup(mnt->mnt_fsname);
+      break;
+    }
+  }
+  endmntent(mtab);
+
+  return devname;
+}
+#endif
+
int
install_loader(const char *path, int update_only)
{
@@ -808,11 +834,6 @@ install_loader(const char *path, int update_only)
   int devfd, rv;
   const char *devname = NULL;
   struct statfs sfs;
-#ifndef __KLIBC__
-  struct mntent *mnt = NULL;
-  struct stat dst;
-  FILE *mtab;
-#endif

   if ( stat(path, &st) || !S_ISDIR(st.st_mode) ) {
     fprintf(stderr, "%s: Not a directory: %s\n", program, path);
@@ -848,35 +869,17 @@ install_loader(const char *path, int update_only)

#else

-  if ( (mtab = setmntent("/proc/mounts", "r")) ) {
-    while ( (mnt = getmntent(mtab)) ) {
-      if ( (!strcmp(mnt->mnt_type, "ext2") ||
-           !strcmp(mnt->mnt_type, "ext3")) &&
-          !stat(mnt->mnt_fsname, &dst) &&
-          dst.st_rdev == st.st_dev ) {
-       devname = mnt->mnt_fsname;
-       break;
-      }
-    }
-  }
-
-  if ( !devname ) {
+  devname = find_device("/proc/mounts", st.st_dev);
+  if (!devname) {
     /* Didn't find it in /proc/mounts, try /etc/mtab */
-    if ( (mtab = setmntent("/etc/mtab", "r")) ) {
-      while ( (mnt = getmntent(mtab)) ) {
-       devname = mnt->mnt_fsname;
-       break;
-      }
-    }
+    devname = find_device("/etc/mtab", st.st_dev);
   }
-
-  if ( !devname ) {
+  if (!devname) {
     fprintf(stderr, "%s: cannot find device for path %s\n", program, path);
     return 1;
   }

   fprintf(stderr, "%s is device %s\n", path, devname);
-
#endif

   if ( (devfd = open(devname, O_RDWR|O_SYNC)) < 0 ) {

ちょっとどころの騒ぎではない。全面改訂。随分コード量が増えている。

元のコードでは、if文でext2/ext3の比較をくりかえしていたのを、ばっさりカットして、find_device()という関数にまとめた。

そのおかげで、下記のように本体はすっきりした。

  devname = find_device("/proc/mounts", st.st_dev);
  if (!devname) {
    /* Didn't find it in /proc/mounts, try /etc/mtab */
    devname = find_device("/etc/mtab", st.st_dev);
  }

繰り返しをまとめるという基本中の基本である。ext2/ext3への比較などはfind_device()という新規に作った関数に閉じこめている。すっきりリファクタリングである。

syslinux一年生のコードをリファクタリングまでしてとりこんでくれたのである。

わたしは、著者のH. Peter Anvin (超大物カーネルハッカー)に会ったことも話したこともない。彼は、見ず知らずのどこの馬の骨ともわからない人間のパッチを軽やかに咀嚼して取り込んだのである。

ここまで一時間ちょっと。

オープンソースそしてバザールモデルというのはとてつもないソフトウェア開発方法論である。

まだまだ学ぶ機会に満ちている。素晴しいではないか。愉快ではないか。

gitによるコード。http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blobdiff;f=extlinux/main.c;h=819f74b5308bac7540fcdb580f94f93cde28d82e;hp=0edce5a597b65dfeb04764aa84582ce1e18dcfd7;hb=537164d509a4227416f6ac5b44c0030d6c79cb41;hpb=2b7251b3905e58ef5c34bb4b009ae537eb1b9333

メーリングリストでのやりとり。http://syslinux.zytor.com/archives/2008-July/010245.html
http://syslinux.zytor.com/archives/2008-July/010247.html

Emacs勉強会 - tokyo-emacs

Emacs勉強会に参加した。なんやかんやで30人を越える参加登録である。

自分は随分昔からEmacsを利用しているのだが、全然使いこなしている感じがしない。最近、Emacsを勉強しなおそうと思っていたので、早速参加することにした。

http://wiki.livedoor.jp/harg/d/FrontPage

Emacsの基本を勉強しなおそう市民連合(笑)の代表として一言挨拶をした。今回は同市民連合の決起集会(嘘)なので、大いにアジったのであるが、みんなでEmacsの基本を勉強しなおしたいと思った。

早水さんのEmacs Lisp講座は初心者に向けての優しい講座であった。

メモをはりつけておくが、これだけじゃあ、何が何だかわからないなあ。

Emacs Lispは怖くない
括弧は空気
EmacsのことはEmacsに聞け
  ヘルプの使い方
Lispは単純
リストが全て
  ドット対
関数名と変数名の名前空間は別

実践編
.emacsを眺める
  (server-start)
  ansi-term
入門書
  もうひとつのScheme入門
  独習Scheme三週間
  プログラミングGauche
---------------------

files.el

K1LoW
  moz.el
  pabbrev.el
  dabbrev.el

  drill-instructor.el

yuki_neko_nyan
  yasnippet

jj1bdx
  face
  color-theme

IMAKADO
  anything
  補完が凄い

Misho
  Emacs for Latex

naoya_t

.emacs
  IMAKADO

Emacsについて語り合う人が自分のまわりにいない人達にとってtokyo-emacsはとてもいいところだ。大変勉強になった。懇親会で、メモ用紙にマクロの解説をしている早水さんや、それを囲んでわいわいがやがや議論している。楽しかった。またやりたいと思った。

早水さん、参加の皆さんお疲れさまでした。ありがとうございました。

追記：資料を公開した。tokyo-emacs-080628.pdfをダウンロード

Googleを支える技術

Googleという不思議なサービスを提供するそのコンピュータシステムの内側に公開された資料だけを利用して迫った良書である。

Internetの向う側のGoogleというシステムについて、われわれは日々利用しているにもかかわらず殆ど何も知らない。少なくともわたしは技術的な側面について殆ど何も知らない。神秘的な、都市伝説的なもの、例えば、20%ルールとか、そんなことぐらいしか寡聞にして知らない。

本書はGoogleの分散ストレージ(GFS/BigTable/Chubby)、分散データ処理(MapReduce/Sawzall)、運用コスト、開発体制などについて公開された論文などを引きながら解説している。

コンピュータシステムというのは極論すれば、いかに速くするか、いかに安くするかという2軸で発展してきたようなものだから、Googleという巨大システムをどのようにエンジニアリングするかという観点からもこの速くすること、安くすることの実務的な教訓というのは大変興味深い。

RDBMS(関係データベース管理システム)というソフトウェアは多量なデータをいかに格納し、検索するかという観点から開発発展してきたものだが、Googleは、それを地球規模の巨大システムに実装したものと言える。

わたしが本書で最も興味を引かれたものは、分散ストレージや分散データ処理の話ではなく、運用コストの章であった。そしてわたしはこの章が本書の最もユニークなところでしかも最も重要なところかと思う。

フツーのプログラマが計算コストと言うときアルゴリズムの計算量の事を指す場合がおおいと思うが、計算にいくらかかっているかという観点から議論するということは、あまりないと思う。

ムーアの法則のすごいところは、18ヶ月で半導体の集積度は倍になる、すなわちコストが半分になると言い切って、フツーのプログラマにそれを意識させたことである。コストが半分になるのだから、それを意識したプログラミング、すなわちメモリがどんどん増えていく、あるいはメモリがどんどん安くなることを前提としたプログラミングが正しいこととされた。そのようなパラダイムでソフトウェアサイエンスは進化していったようなものである。

コンピュータの高速化の流れも、ムーアの法則にのとって、クロックを高速化する事によって、命令セットアーキテクチャを変更する事なく、様々な実装上の工夫によって、高速化していった。ソフトウェアにとっては、ほとんど何もしないで高速化していったわけであるから楽な時代であったと言える。

ところがクロックをどんどん上げて行くことによって、電力消費量もそれに比例してどんどん増加していって、発熱の問題などが顕在化してきた。そこで、クロックを上げることによる高速化ではなく、マルチコア化等による高速化などが必要になってきた。同様に消費電力あたりの性能を上げるための様々な工夫が必要になってきた(←今ここ)

計算機の消費電力は電気代というお金になる。Googleが利用している計算機は、2000ドル〜3000ドル程度の普通のIAマシンのようであるが、その消費電力が増加の一途をたどり、年間運用コストがそれを上まわるかどうかという事である。

電気代だけではなくてデータセンターの建設費、効率的な電力消費設計などがコスト負担にどんどかかってくる。プログラマは昔はムーアの法則をメモリ空間の増大などと一次元的に考えていればよかったが、今後はメモリ空間はまあそこそこあるとして、消費電力をどう効率的に利用するか、省電力プログラミングが求められてきているような気がする。

消費電力を半分にできれば運用コスト(電気代)は半分になるし、ばかでかいデータセンターの建設も先送りにできる。サーバー機の重要なコストファクタが電気代というのが常識になってくるとプログラマのプログラミングパラダイムも随分変化してくる。

速くするだけではなく、電気代を節約する速さが求められるのである。

モバイル機器なんかは電池の持ちが商品価値そのものを決めたりするので、もっと重要である。バッテリーのサイズが半分になればデザインの自由度も随分増すだろうし、なにより軽くできるし、ハードウェアコストも安くできる。プログラムが物理的なデザインに影響を与えるのである。

プログラマがもっとコストなどの側面に意識を持つべきだと思うのだが、その意味で本書の第5章などは大変興味深くかつ意義深いと思う。

省電力プログラミングというパラダイムをそろそろ真面目に考えないといけない時期である。

Googleを支える技術 ……巨大システムの内側の世界
サポートページ
http://gihyo.jp/book/2008/978-4-7741-3432-1/support

Happy Hacking Diary(著者：西田圭介氏の日記)
http://d.hatena.ne.jp/nishidakeisuke/20080428

Papers Written by Googlers
http://research.google.com/pubs/papers.html

未来のいつか/hyoshiokの日記(電気代)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%c5%c5%b5%a4%c2%e5

未来のいつか/hyoshiokの日記(省電力)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%be%ca%c5%c5%ce%cf

セキュリティ＆プログラミングキャンプ2008

ソフトウェアは人が作る。人がすべてだ。

若い人が魅力を感じなければその産業は衰退する。若い人にとってソフトウェア産業が魅力的なものだということを我々はもっと伝えないといけない。ビジョンを示し、その魅力を伝える努力をしないといけない。

一方で少しでも興味を持ってくれた人にソフトウェアを作ることの楽しさおもしろさ難しさを伝えることも必要だ。

人材育成だなんだと大げさにとらえるのではなく一緒にプログラミングの楽しさを経験したい。初心に戻ってプログラムを初めて作ったころの感動を体験したい。

22歳以下の皆さん。

あなたたちのために、そのような合宿を企画した。

セキュリティ＆プログラミングキャンプ2008 http://www.jipdec.jp/camp/

『若年層のセキュリティ意識の向上と優秀なセキュリティ人材の早期発掘・育成』という目的で2004年からやっているセキュリティキャンプがきっかけだ。合宿形式で行うセキュリティ人材育成のイベントのプログラミング版だ。

U-20プログラミングコンテストで若い人たち（中学、高校生）のプログラムを読む機会があるが、やはり回りに相談する人がいないのか、プログラムの基礎的なことなどの理解が足りていない。例えばif文を延々と重ねて処理をするとか、いたるところに数字（定数）が書かれていたりとか、そーゆー力ずくのコードを目の当たりにみて、コードを書くにしても基礎的なイロハの伝授が必要であるということを痛感していた。

コードの書き方だけではなく、デバッグの仕方とか、gitをはじめとする分散バージョン管理システムあるいはOSSを前提としたコラボレーションのちょっとしたコツとか、必ずしも明文化されていないがとっても重要なことについて学ぶきっかけを作りたかった。

もちろん、その先にあるプログラムを作ることの楽しさ、達成感、充実感なども共有したい。

わたしのミッションステートメントをここに記す。プログラミングキャンプ宣言だ。

    *  オープンソースソフトウェアを開発する元気のいい若手プログラマを輩出したい。
    * 単にプログラミングテクニックが凄いというだけではなく、コミュニティのリーダとして、人々の話をよく聞き(コミュニケーション能力)、信頼されるようなプログラマを輩出したい。
    * 彼等が今後の核になってさらに新しい人材を発見発掘するというエコシステムを作りたい。
    * 彼等が新しい価値を創造し、世界から尊敬されるような人々になって、日本という地域が、そのような人々が集まるような場所にしたい。

10年で200人。

これが、わたしのユメだ。

そのような若者を雇用するビジネスを作るのが大人の役目である。

多くの若者の応募を待つ。

git入門

社内勉強会でgit入門をやった。(参考資料をダウンロード )。

最近の開発でgitを使っているので、そのファーストインプレッションみたいなものである。マニュアルについては、日本語訳もあるので参考にしてほしい。

分散コード管理システムということで従来の集中コード管理システムとその使い勝手が相当違うように感じる。

基本的な使い方は、リモートにあるリポジトリをローカルにコピーして、そのコマンドをgit cloneというのだが、そのレポジトリに対してチェックアウト、チェックインを繰り返し最後にリモートのリポジトリにコミットするという感じである。

基本的には、集中型とそう違わないのであるが、精神的には随分違うという感じがする。

まず、変更はローカルのリポジトリにずんずん行なうという点。ローカルのレポジトリにずんずん行なうので、その時点でリモートにアクセスできなくてもいい。ノートパソコンにレポジトリを用意して、電車の中や街中でちょっとした変更をして、それをノートパソコンのローカルなレポジトリにずんずんコミットする、なんていう使い方ができる。

そこまでモバイルな使い方ではなくても、通常だったら、次のような感じかと思う。まづプロジェクト用リポジトリを準備して、各自は自分の開発マシンにリポジトリを置く。そして、個々の担当は自分のリポジトリにどんどんコミットする。テストが終った変更(コミット)に関しては自分のリポジトリからプロジェクトのリポジトリへpushする。

そんな感じである。

まだ、ありがたみが伝わらない？うーむ、説明が下手ですいません(ぺこり)

基本的には変更はブランチで行なう。ブランチが原則、前提。Linux Kernelの開発のように多数のプログラマによって独立に開発がおこなわれているというプロジェクトの場合、このブランチが原則というのは大変理にかなっているように思う。

また管理の対象もコミット単位(ファイル単位というよりも)というのも理にかなっている。

また各オブジェクトはSHA1のハッシュ値(16進40桁)で管理されているので、同じSHA1値であれば同じオブジェクトであるということがグローバルで担保されている。

ということは、例えばgitの開発ヒストリのログなんかも、本家をコピーしたリポジトリ全てで同一性が保証されている。Linusが最初にコミットしたオブジェクトは、世界中のどんなコピーでもe83c5163316f89bfbde7d9ab23ca2e25604af290という事が保証されている。通常は40桁のハッシュ値の最初の数桁を利用すれば参照できるので、例えば、

$ git-log e83c5163

とすればLinusが開発したgitの最初のコミットのログを見ることができる。すごいすごい。

$ git clone git://git.kernel.org/pub/scm/git/git.git

でソースも読めるのでいろいろ楽しめる。gitを利用したプロジェクトのヒストリの眺め方などという時間軸にそった楽しみ方もあるのではないかと妄想した次第である。

Rebase Early, Rebase Oftenという話をしたかったのであるが、紙面がつきたのでいつの日にか。

カーネルにおけるリグレッションの特定/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_d748.html

Git ユーザマニュアル (バージョン 1.5.3 以降用)
http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html

勉強をしなおす

いくつになっても勉強だ。昔とった杵柄。錆びたナイフを研ぐ。

という事で日頃なにげなく使っているEmacsのマニュアルを再読する事にした。会社の机の上にO'reillyの Learning GNU Emacs、Writing GNU Emacs Extensionsそして竹内監訳のGNU Emacsマニュアルがある。竹内監訳のGNU Emacsマニュアルの初版は1988年2月である。20年前である。いくら何でも日進月歩、秒進分歩のIT業界の時間感覚でなくても古すぎるだろうと思わなくもないが、機能がテンコ盛のEmacsにはversion 18ころの古典的な、基本機能をおさらいするには、サイズ的にも丁度いい感じである。

正直に告白すると、Emacsを日々使っているが自分で拡張を書いたりelispで手間仕事をちゃかちゃか片付けるという事はほとんどしていない。何かのきっかけでもないとマニュアルを読みかえすということもほとんどしない。ぐぐればどーにかなる。だけど、一見時間がかかると思えても基本にたちかえってみることは悪い事ではない。

今使っているEmacsは22.1.1だ。Ubuntu 8.04にデフォルトでついてくるやつである。10数年Emacsを使っているけど全然使いこなしている感じがしない。ちゃんと基本にもどって勉強しなおしてみよう。きっと新しい地平線が見てくるに違いない。

セキュリティ・キャンプ・キャラバンwithプログラミング沖縄

若年層の情報セキュリティ意識の向上と優れたセキュリティ人材の発掘と育成を目的として、毎年開催しているセキュリティキャンプの成果とその蓄積されたノウハウを広く一般の方々にも公開すること、これからキャンプに参加していただきたい若い方々に正しい情報セキュリティの理解と意識の向上を図ってもらうこと、また、オープンソースソフトウェア(OSS)を中心としてプログラミングやアプリケーション開発について興味を持っていただくことを目的として、「セキュリティキャンプ・キャラバン with プログラミング　-沖縄-」を開催します。
http://www.jipdec.or.jp/camp/caravan/caravan_okinawa.html

ということで沖縄にきている。わたしは大阪、筑波、そして沖縄と三ヶ所キャラバンした。

来週は横浜で開催するので東京近郊の皆様はぜひ参加してほしい。
http://www.jipdec.or.jp/camp/caravan/caravan_yokohama.html

セキュリティキャンプ・キャラバンwith プログラミング　2007
集まれ“若い力”
http://www.jipdec.or.jp/camp/caravan/caravan.html