Good bye PGCon!

Back from PGCon2009 in Ottawa, to my annoying day-to-day works. It was arranged quite well, made up by people who came from all over the world, so it gave good experience to me. Although there were uncountable things I learned there, only one thing is to write here from them;

In the first night party held by EnterpriseDB I talked with Tom Lane, who is fifty years old (I asked him!), writes bunch of PostgreSQL code overall, has deep insights as an engineer and is respected by community people including me. He looks like a typical nerd and his English is kind of peculiar so I hardly understood what he said, but an answer to my silly question struke me.

- "I really respect you. I'd like to be like you someday."
- "Well, just do things in front of you."

Then I believed that's what has made him as he is today. It is an easy, well-known and simple rule but also hardest to keep for decades.


http://img199.imageshack.us/my.php?image=b9w.jpg&via=tfrog

青臭い

地下鉄の駅を出ると空気の青臭さを感じる季節になりました。嫌いじゃないです、この匂い。

Debug Hacksジュンク堂に参加してきました。事前予約をしていたわけではないのですが、Twitter経由でまだ空きがあって当日でも入れそうだと知ったので、フラッと行ってみたらすんなり入れました。

Debug Hacks -デバッグを極めるテクニック&ツール
吉岡 弘隆 大和 一洋 大岩 尚宏 安部 東洋 吉田 俊輔
オライリージャパン
売り上げランキング: 1179

速攻サマリーがあるので細かいことはこちらに譲るとして、自分はQ&Aで「会社の名前で本を書くということで、会社からこれは書くな、ということはあったか」という質問をしました。答えは、「顧客との紐付けができることはマズイが、一般的な内容なら良い」ということで、これが吉岡さんの持論なのか会社の方針なのかはわかりませんが、とにかく「デバッグという技術はプログラマのコミュニティのものであって会社に属するものではない」という意見でした。吉岡さんをはじめ著者たちの所属するミラクルリナックスというと扱っているLinux自体オープンソースだしある意味技術もコモディティ化しているしそういった文化が発達しているのでしょう。

この吉岡さん、もう結構いい年なのに「技術はコミュニティのものであって会社のものではない」と言ってみたり、「生涯プログラマ宣言」をしてみたり、「日本はじまったな」と叫んでみたり、元気が良すぎます。普通なら「オレもいい年だからそういう青臭いことは若い人に任せるよ」と自分で言い出したり周りからそういう風に窘められたりするのだと思うのですが、そんな雰囲気を一切感じさせない、元気のいいおじさんでした。同じことを自分のような20代そこそこの人間が発信しても「何もわかっちゃいない」と一蹴されるだけなのでしょうが、ミラクルという会社の経営にまで携わった人がこういうことを言うというのはすごいことですよね。よく「最近の若い人は元気がない」というおじさんが昔からいますが、こういう元気のいい、言い換えれば青臭いおじさんがもっといてもいいかもしれないですね。

同質問の答えで「PostgreSQLの開発に関してもいろいろノウハウがあるはずだから、Debug Hacksみたいな本が書けるんじゃない?」という指摘も頂きました。確かに、どこのドキュメントにも(本家のWikiやマニュアルでさえ)書いてない、PostgreSQL特有のHacksはたくさんあるので一度纏めてみたい気はします。ユーザーガイドではなく、Hackそのものっていうのは面白そうです。最近日本人でPostgreSQLのソースについて詳しい人が増えてきたので、そういう発想もありかも。id:pgsql/id:higepon/id:iakio/id:taedium/その他のみなさま、ぜひ一度ご検討くださいw。

仕事外でオープンソースに参加すべき3つの理由

今年もお世話になりました。

さて、半年来個人的に関わってきたプロジェクトがようやく一段落ついたのでお知らせ致します。

pgsql: Support window functions a la SQL:2008.

PostgreSQLというオープンソースのデータベースソフトウェアに機能追加の提案を行っていたのですが、先日本体に取り込まれたようです。

オープンソースに参加するプログラマには大きく分けて二種類あります。一つは、フルタイムでオープンソースに参加し、企業からもそのことに対してお金を貰っている専業の人。もう一つは仕事として別な(多くはプログラムを書く)ことをやっていて、個人の時間を利用して参加している人です。自分は普段企業で顧客向けのコードを書いており、PostgreSQLのコードを書いても1円も貰えないので後者に属します。

では1円も貰えないのに、何故仕事以外でオープンソースに参加すべきか、自分の経験から3つに纏めました。

1.スキルアップ
会社とは全く違う環境、違う基盤の上でプログラムを書くことになるので、新しいツールやルールを覚える必要があります。自分の場合でも、最近流行りのgitというソースコード管理ツールを使って今回のプロジェクトを進めていたため、仕事では覚えるはずのなかったツールについても学ぶことができました。また、全てのやりとりは英語を使って行われるため、英語の良い練習にもなっています。「こんな単語はここでは使わない」とネイティブから指摘されるのが、公の場であるメーリングリストなわけですから、世界への恥さらしもいいところなわけで、必然的に身につくものがあります。


2.世界を体感する
(いわゆるオフショアではなく)海外のエンジニアと会話をしながら仕様や設計を決めて行く作業は、刺激的です。自分一人では思いつかなかったような実装がやいのやいのやっているウチにできあがっていくプロセスは面白いの一言です。
また、ユーザからも「この機能を待っていたんだよ」などとダイレクトにフィードバックが来ますので、作りがいがあります。ここの部分は難しいから後回しに、なんて逃げようとしても、「そこがなければ全体として意味がないです」と見知らぬユーザに言われてしまうと、ううむ、作ってやるか、という気持ちになります。
一般に世界中で使われるプロダクトに日本で携わるのは難しいのではないかと思うのですが、日本の新宿の片隅にいながら世界中の人の期待を感じながらモノを作る楽しみはなかなか味わうことができないと思います。

3.日常業務とのバランスをとる
これが一番大事なのですが、仕事をしていると顧客や上司に仕事を押しつけられたりして自分の貴重な時間が奪われていくような、スポイルされていくような不安を多くの人が感じているようです。本当はそんなことないと思うのですが、やはり自分も少なからずそういった感覚をもったことがあります。そんな時こそ、オープンソースに参加すべきです。オープンソース界隈には本当に優れたエンジニアがいて、また金で繋がれた関係がありません。もちろん納期もありません。自分が諦めればそれまでの努力が報われないだけのことです。こうした活動によって、コーディングの楽しさを取り戻し、また日常業務に精を出すことができるのです。但し、仕組みは、謎です。

というわけで、まるで「オープンソースマンセー」な人に見えるかもしれませんが、自分は決してフルタイムのオープンソースエンジニアになりたいとは思っていません。最後の項目に書いたように、どちらが大事ということではなく、日常業務とのうまいバランスこそが、エンジニア人生をより楽しくするものだと考えているからです。

それでは良いお年をお迎え下さい。

NHKオンデマンドで武豊の「プロフェッショナル」を見た。

ご無沙汰です。

NHKが有料で過去放送分をネットで見られるようになった、とのニュースを見たので、ちょっと時間に余裕があった先週末に、こっそりプロフェッショナル 仕事の流儀「挑み続ける者に、限界はない〜騎手・武豊〜」を家のPCで見ました。

結論から言うと、やっぱりテレビは面白い。そして、NHKのコンテンツの質は超越している。だからNHKのコンテンツはもっと有効活用して欲しいし、それを維持するのに必要なお金は視聴側として払いたい。ただ、意味のわからない受信料は払いたくないし、めんどくさい方法ではテレビを見たくない。

実際問題、NHKオンデマンドのページにいって、コンテンツを探すのがかなり骨が折れました。本当はイチローの奴(1年前ぐらい?)が見たかったのですが、過去1週間分しか見れないのですね。まあ、最初はアカウント作らないと番組一覧も見れないのではないかと思っていたので、とりあえずどんなものが見れるようになっているかを確認できたのは幸いでした。

そして、いざ番組を選らんで「視聴する」とか押すと、コンテンツ購入ページがあり、さらに決済方法の選択があります。僕は普段Firefoxをメインブラウザとして使っているのですが、全ての項目を入力して「OK」ボタンを押すと、エラーになります。よく読むと、「Internet Explorer6.0以上のみが対象です」と書いてあります。今時これはどうかと。確かに、番組のコンテンツ自体はWindows Media Playerで配信されるのでIEで見る必要があるのですが、決済方法のフォーム入力ぐらい、どのブラウザでもいいじゃないですかね。

そういう事情で武豊を見たのですが、やっぱり面白い。「ただ、いい騎手になりたい」とか言われると、「ただ、いいプログラムが書きたい」とか思ってしまうわけです。茂木という人は昔から嫌いですが、武豊のニコニコした顔をいろんな角度から捉えるカメラ、番組構成はやはり秀逸だと思います。

これだけのクォリティのコンテンツを大量に倉庫にしまったまま、受信料うんたらかんたらの議論を延々と続けて新人記者を畑のど真ん中へ軽トラックで連れて行って、「受信料もらってこいよ〜」といってその日の夕方まで放置するという(友人の実話w)、労力の無駄遣い以外の何者でもないことに費やしているのは、怠惰を通り越して犯罪だと思うのですが、如何でしょうか。

以前、もういっそのこと全部ネットに上げちゃえばいいんじゃね? - umitanuki日記でも書いたように、どんどんネットに上げてしまえばいいと思うのです。それは、ネットが無料でアクセスできる手段だからではなくて、情報の流通速度や可用性が高いからなんだと思います。コンテンツが流れていくのは、止められない。ならば、そこからどうやって収益を上げるかを考えた方が早い。いっそのこと、受信料を一切やめて、ネット経由での視聴からのみお金を頂きます、みたいな方法にしてもらってもいいとさえ個人的には思っています。そんなの不公平だ、というのはきっと無意味で、テレビの収益構造なんて最初から不公平なのです。

コンテンツをうまく利用することに関して、テレビの人たちは本当に下手だなと素人目には映ってしまいます。ネット屋さんからは例えば、先輩であるid:gamellaから『リビングにネットコンテンツを届けるDLNAサーバソフトウェア「coRockets」の開発』が未踏本体に採択されました - Future Insightのような提案や、それに似たプロジェクトとして、ネット界のテレビっ子こと、id:miyagawaからremedie - Pluggable media center application - Google Project Hostingのようなネタも出てきていて、デラ楽しみです(これらのプロジェクトが何なのかは、リンク先に譲ります。まだかみ砕いて説明できるほど自分が理解していないため)。

武豊が馬に乗るときに気をつけているたった一つのこと、それは「馬の邪魔をしない」ことだそうです。その理屈でいけば、「コンテンツの邪魔をしない」ことは大事なことなんじゃないかと思います。コンテンツは、もっと自由になりたいと思っているような気がします。そういう意味で、coRocketsremedieにはとても期待。そしてそういったコンテンツを自由にするプラットフォームによって、結果的にコンテンツを作る側にも今より利益がもたらされることを楽しみにしております。

敬具。

オープンソースについて考えています

これは、良書でした。

オープンソースワールド 川崎 和哉


オープンソースについては仕事上、そして趣味上よく知っているつもりでしたが、改めて考えてみようと思ったところ、実は細かい歴史や登場人物、文献等について何も知らなかったことに気づき、紀伊国屋に駆け込んで手に入れたのがこの一冊。何気なく手にとっただけなのですが、読んでみると内容の充実に満足。連休で一気に読み終わってしまいました。

ストールマンFSFネットスケープ、「伽藍とバザール」について名前ぐらいは知っている人も多いと思いますが、それらの点を線で結べと言われると困るのではないでしょうか。オープンソース文化を体系的に、また時系列的に整理できるという意味ではこれは良書といっていいと思います。内容は若干古く、時代的には「ネットスケープの失敗」で終わっているのですが、その後のことはネットを調べればだいたいわかるので大きな問題ではないです。

自分が何について考えているかというと、オープンソースはなぜお金にならないかということについてです。オープンソースはお金になるというのが最近のそしてこの本の結論なのですが、ただしその方法はサポートやオープンソースインフラに載せた副次的なコンテンツに依っていて、ソフトウェアそのものの価値には一銭も払われていないわけです。明らかに、世界中の人がそのオープンソースソフトウェアの改善によってメリットを享受できるにもかかわらず、そこにはマネーが一切発生せずに、逆にサポートなどその上に乗った人々にお金が発生するというのは、歪だと思うのです。少なくともソフトウェアを書く人間としては。

ハッカーはお金に興味がなくて知的欲求を満たされるからそこにはお金が発生しないのだという主張は正しいですがそれだけではキレイ事だと思うわけです。自分の果たした役目についてお金をもらえるのであればもらえた方がよいに決まっているし、またお金によって価値を評価されることもまた、承認欲求を満たすはずなのです。

ビル・ゲイツはソフトウェアの存在価値についてよく知っていた。だからこそ、ソフトウェア・ライセンスビジネスというものを確立した。そのこと自体はとても評価されるべきだと思うんですよね。但し、やり過ぎた。だから、その不自由で独占的な体制に怒りを覚えた原理主義的な人々がソフトウェアは本来フリーであるべきだと唱えた。ある意味ダンピングだとも思うわけです。今のところ、そういう方法でしか帝国の牙城を崩すことができなかったというだけのことであって、本質的にソフトウェアがフリーで無償でお金にならないというのは少し変だなというのが今のところの自分の見方です。

そんなこんなでこの興味深い世界についてはまだまだ足を突っ込んで見ようと思いますが、オープンソースはお金とか情報とか価値とか人間の自然な欲求とかそういうものを複合的に考える上ではとても良い文化です。大学とかでぜひこれを体系的に教えるべきだと思うのですが、自分の知る限り2001〜2004の頃には、そんな授業はありませんでした。フェミニズムも大事だけど、プログラミングと広告と政治とアートと文学と看護が同居する大学にこそ、オープンソース文化についての授業が必要なんじゃないかなあと(今はあるのかも)。

Google Chromeは速くないって

Google Chromeが速いという意見をよく耳にしますが、何を言っているのかさっぱりわかりません。そういう人たちはGoogleのマーケティング戦略に騙されすぎです。

ブラウザの速さを決めるのはたくさんの要素がありますが、Chromeが速い理由の一つにJavascriptエンジンであるV8が速いことが挙がっています。本当にそうでしょうか。

まず理論面から。
多くのWebアプリケーションで、Javascriptボトルネックになるとすれば、その大半はDOM操作によるものです。そしてDOM操作はレンダリングエンジンが実装していて、Javascriptはそれらを呼び出しているにすぎません。ChromeレンダリングエンジンはSafariと同じWebkitです。ということは、速度の大半を決めるレンダリングエンジンが同じ以上、Chromeが爆速だというのは迷信です。ちなみにFirefoxのJSエンジンであるSpiderMonkeyTraceMonkeyに入れ替えるという話の中でも、実際の問題の多くはGeckoにあることが知られてきています。
つまり、数値計算による物理シミュレーションをリアルタイムで行うならまだしも、Web/Javascriptでは言語自体の実装が速くなっても大きな変化はないということです。

次に実験。
Firefox3/Safari3/Chromeに対して以下のような実験を行います。
1.一つの変数に繰り返しかけ算を行う
2.ドキュメントに繰り返しDOMノードを追加する
3.あるオブジェクトのプロパティに繰り返しアクセスする
4.配列に数値をため込み、join("")で文字列にする

結果は以下のとおりです。

test1(かけ算) test2(DOM操作) test3(プロパティアクセス) test4(文字列生成)
Firefox 84 257 93 75
Safari 109 31 140 62
Chrome 8 113 12 55

予想通り、Chromeは純粋な演算(test1)とプロパティアクセス(test3)には滅法強そうです。ただし、DOM操作(test2)はSafariより遅く、文字列生成も他とあまり変わらず。DOM操作がSafariより格段に遅いのには驚かされます。

結論。
パフォーマンスチューニングにおける大事なことは、ボトルネックを見極めて局所的につぶしていくことですが、残念ながらV8の設計者はただの速度バカだったようです。一画面でJavascriptを数千行書いている自分に言わせれば、クライアントサイドのJavascriptはDOM操作と文字列生成がほとんどです。足し算やかけ算がいくら速くなってもアプリが速くなることはありません。

まとめ。
Chromeは本当に速いのか?をJavascriptの側面から理論と実験で考察しました。タイトルは釣りですが、Googleのマーケティングにやられている人たちを見る度に嘆かわしくなるのでちょっと纏めてみました。本当はJavascriptだけでなくレンダリングやネットワーク戦略(ダウンロード、DNS他)等もブラウザの速さに大きく寄与する部分ですが、とりあえずJavascriptは速くないということがわかっていただけたと思います。むしろChromeの速さのはレンダリング部分であって、その実体Webkitはすごいので、みんなSafariを使うべき!

おまけ。
テスト内容を載せておきます。

<html>
<head>
<script type="text/javascript">
function time(){
	return (new Date()).getTime();
}

function test1(){
	var t0 = time();
	var n = 1000000;
	var res = 0;
	for(var i=0; i<n; i++){
		res *= (i+1);
	}
	
	alert(time() - t0);
}

function test2(){
	var t0 = time();
	var n = 10000;
	for(var i=0; i<n; i++){
		document.body.appendChild(document.createElement("div"));
	}
	alert(time() - t0);
}

function test3(){
	var t0 = time();
	var n = 1000000;
	var obj = {a: 1, b: 2};
	for(var i=0; i<n; i++){
		var tmp = obj.a + obj.b;
		
	}
	
	alert(time() - t0);
}

function test4(){
	var t0 = time();
	var n = 100000;
	var buf = [];
	for(var i=0; i<n; i++){
		buf.push(i);
	}
	var result = buf.join("");
	alert(time() - t0);
}
</script>
</head>
<body>
<input type="button" value="test1" onclick="test1()">
<input type="button" value="test2" onclick="test2()">
<input type="button" value="test3" onclick="test3()">
<input type="button" value="test4" onclick="test4()">
</body>
</html>