こっちの時間で夜中から早朝にかけてプレゼンの準備をした。 スライドそのものはほとんど飛行機の中で完成していたのだが、 なにぶんスライドを見るだけで英語でしゃべる、なんて真似はなかなかできないので、 原稿を書く必要があるのだ。
いや、実は去年まではスライドとそれに書きなぐったメモだけで勝負していたのだが、 毎回さんざんな思いをしていたのだ。で、OSCONからは英語で講演する時には しゃべる内容を全部書き出すことにした。 聴衆の顔を見ながらはなすのが難しいのが欠点だけど、内容がめちゃめちゃなのよりはマシということで。 もっと早く反省しろよという感じだけど。
で、この原稿を表示しようと思ってリブレットを持ってきてたのだが、 昨日の事故で ACアダプタが死んでしまってどうしようか、と思っていたのだ。
そしたらThoughtWorksのスタッフから 彼の東芝ラップトップのACアダプタを借りることができた。ラッキー。
で、プレゼン。tutorial roomという二番目に広い部屋(200席くらい)を割り当てられたので、 どうしようかと思ったが、あらかた埋まっていた。びっくり。
ちなみに一番広いのがConference Hallでこれは1000人くらい入りそう。 あと、すこし小さい部屋が3つあるのだが、 今回はそれぞれprivate room, public room, protected roomと名づけられている。 Bjarnがくるって言うんで洒落で付けたみたい。 最初「private room」と言われてなんのことかわからなかったんだけど、 protected roomまで見てやっと分かったっていう。
プレゼンテーションは前半は例によって原則と哲学について、 後半は1.8や1.9, 2.0について。後半についてはLL Saturdayで話したのとほぼ同じ。
プレゼン資料はここに置いておく。
まあまあの反応だった。４５分割り当てられてしゃべってる時間が４３分だったので、 あまり計算していなかった割には良い出来だ。
「スライドにRubyのコードがあれば良かったのに」という声があった。 確かに1行のコードもない。 Rubyを知らない人もたくさんいたはずなので、その方が賢い選択だったよね。 毎回、同じことを言われているような気がする。
講演後、Artima.comのBill Vennersからインタビューを受ける。 そのうちArtimaのサイトに載るんじゃないだろうか。
なんだか与太話をいっぱいしたような気がするんだけど、これで良かったのか。
プレゼンも終わり、インタビューも終わり、解放された気分。
Speakerはカンファレンス主催者からディナーに招待される。 食事について心配する必要がないのがこのカンファレンスのいいところだ。
参加した講師陣に聞いてもほとんどの人たちは
とべたぼめ。カンファレンス関係者は食事に気を使った方がいいと思う。 その点でLinux Expo Parisは最悪だった。いや、それ以外の点でも最低最悪だったんだけど。
あと、このカンファレンスは講師陣でも聞いてみたいというセッションが多いのもある。 セッションによっては質問するのはアメリカから来たほかの講師たちばかりだったなんても珍しくないし。
行ったのはイタリア料理のレストラン。 個人的には日本の料理のほうがおいしいと思うけど、まあこれは個人の好みだろう。
とうとうBjarneと話をする。一緒に写真も撮った(ミーハー)。
で、11月にRuby Conferenceでテキサスに行くと話したら、じゃあ前日にうちの大学に来て (彼は今Texas A&M Universityの教授)学生と話しないか、と誘われた。空港まで迎えに行くよ、とも。 望むべくもない嬉しい申し出なんだけど、酔ってるせいじゃないか、と疑ってみたりして。
BjarneはこのAarhus出身なのだそうだ。「俺のホームタウンはどうだ、いいだろう」という感じだった。 気さくな人だ。
「C++のような世界的に重要な言語のデザイナーっていうのはどんな気分」と聞いたら、 「うーん、単なる偶然。そういうものが必要と思って作っただけだから」とのこと。
「Javaについてどう思う」という問いには「興味ない。書けと言われれば書くけど、 技術的には面白いものはないから。あれはマーケティングの産物だよね」だそうだ。 私以上に技術屋だ。ま、それはそうか。
BjarneにPARCでMVC(Model-View-Controller)を考えた人(Trygve M. H. Reenskaug、発音できない)を 紹介してもらった。この方はもうすっかりおじいさんなのだが、中身はすごいぞ。
UMLとかを見てもクラスとクラスの関係を記述している。が、本当に重要なのはオブジェクトだ。 あれじゃクラス指向じゃないか。
に始まって、鋭い指摘が満載でした。Naked ObjectとかModel Driven Approachとか新しめのキーワードも カバーしてるし。
日本にはこんなおじいちゃんいないよなあ。 あと何十年か後に私がそういうポジションを占めればよいのか。
めざせ、コンピュータおじいちゃん。
あー、ほかにもいろいろあったような気がするけど、忘れた。 帰りの飛行機の中で思い出すようにしよう。
しばらく前にNHK BSで放送していたものの録画。
1968年の映画とは思えない。パンナムがつぶれてたりするのは愛敬か。
この映画を見るのは確か3度目か4度目のはずだが、 意外と記憶と違っている部分があった。以下は雑多な感想。
全体に説明が少なく、かつ間延びした感じがする。
増やすところは増やして、削るところは削るともっとすっきりするかも。 そう感じることそのものが現在のハリウッド映画の「文法」に毒されているのかもしれない。 そういう身からは「未来予測がすぐれた映画」という印象が強い。 そう思えば、邦題『宇宙の旅』は適切なのかもしれない。 本来は人類の進化を描こうとしていたと思うんだけど。
SF的背景を持たない妻には、なんのことやらさっぱりわからなかったようだ。 彼女にとっては実験映画と同じ印象しかなかったようだ。 あれこれ説明したら少しは分かったようだが。
次は『2010』だが、いつ見る時間が取れるかな。
チームでGTDしたいのだが、理想的なツールがない。
Basecampはけっこうよろしいのだが、できれば手元にデータを置きたいのだ。 全員が同じプラットフォームを使ってるわけではないからWebベースが望ましい。
ちょっと調べたのは以下のようなもの。
どちらかというとIssue Managementツール。 あんまりGTDという感じではないか。 再帰的にマイルストーンが定義できるのは好ましい
GTDを謳うWiki。Instikiベース。 「todo:」と書いたエントリを一覧してくれる。 でも一覧からチェックはできないから素人にはちょっと使いにくいか。 MindMapを作れる機能あり。
Pimki2では ToDoをチェックできるようにする予定ということで将来に期待。
もしかしてBasecampクローン？
でも現時点ではソースを入手する手段がない。 まだ外見だけなのか。
todo機能はない。
Howm記法が使えるのは良い。リストからチェックはできないので、 todoがあるページを編集する必要がある。Pimkiもそうだが、この辺がWikiの限界か。
今日は1歳半から3歳までの子供のクラスの代理教師をする予定だったのだが、 ちょっとしたうっかりがあってやらなくても済んだ。
自分の娘を教えるのはちょっと抵抗があったし、 なにぶんまだ言葉もなかなか通じない赤ちゃんにどうしたもんだかと 少々悩んでいたので、ありがたいのだが、 自分のミスで楽になるというのはいかがなものよ。
神権会ではレッスンを行う。こっちは逃げられない。
テーマは「選択の自由」。 私たちは日々選択を積み重ね、 その結果を引き受けるわけだが、 自ら進んで選択を行うことができる権利が 人生においていかに大切か、ということについて。
Rubiniusが開発スプリントを行ったという話。 開発も順調に進んでいるようで素晴らしい。 あと、SunはJRubyだけでなく、Rubiniusや本家Rubyの開発も支援してる、 ということも忘れちゃいけない(ブログエントリ的にはそっちの方が重要)。
で、本家もスプリントを行いたいのだが、 地理的分散も大きいし、 どうしたもんだか。
そこで、SkypeやIRCを利用して、仮想的に集まることを 考えているのだが、なにぶん経験がないので うまくいく確信がない。
似たような経験のある人で、「こうした方がよい」とか 「このツールが役に立つ」とかいうような情報があれば 歓迎する。
とりあえず、通常の開発環境以外には Skype＋RememberTheMilkでやろうと思ってるんだけど。
Trac(やRedMine)を用意して、そこに全部チケット突っ込むという手もあるけど、 どうなんだろうね。
「メンテは趣味ではできない」という断言は早急すぎないか、 可能性の芽を摘まないか、という懸念。
など、メンテナンスには困難な側面があるのは事実だろうけど、 それなりに楽しい側面もあると思うよ。 私、実はメンテ、嫌いじゃないもの。
私の場合は、好き嫌いではなく、粗忽者すぎてトラブルを頻発させるから 「降ろされた」という感じかな。
OSSプロジェクトはちゃんとメンテできる人を三顧の礼で探すべきだ。
Tim BrayによるErlang探訪。
Erlangに1,167,948行のログファイルを食わせて、 「ongoing(彼のブログ)」へのアクセス105,099行を抽出してみたら、 MacBookで56.44CPU秒かかった。
どうもI/Oが遅そうなのでスキャン部分は全部外して、 単にファイルを読み込んでみたら34.165 CPU秒かかった。
一方、同じ処理をRubyにやらせたら、3.036 CPU秒しかかからなかった。
分散がうまくはまればErlangは驚異的な性能を発揮するが、 (スクリプト言語としては基本的な)ファイルI/Oや正規表現マッチなどは 驚異的に遅いということを認識する必要がある。 まだ、汎用言語になるには改善が必要かも。
ErlangのVMであるBEAMの実装についての解説。
個人的に一番興味深かったのは GCがプロセス単位であること。 アルゴリズムはシンプルなマークスイープだけど、 ひとつのプロセスがカバーするオブジェクト数は限定的なので、 停止時間が短くてすむのが特徴。
TIOBE Index同様Googleの出現数を使って「Suckな言語」を探す試み。
| Rank | Language | Query | Hits |
|---|---|---|---|
| 1 | Perl | perl sucks | 58,900 |
| 2 | C | c sucks | 49,600 |
| 3 | C++ | c++ sucks | 39,900 |
| 4 | Java | java sucks | 27,900 |
| 5 | Lisp | Lisp sucks | 19,100 |
| 6 | JavaScript | JS sucks | 13,400 |
| 7 | Visual Basic | VB sucks | 8,000 |
| 8 | PHP | php sucks | 3,000 |
| 9 | Python | python sucks | 2,000 |
| 10 | Ruby | ruby sucks | 500 |
Rubyってば、ダントツである。こういうタイプの調査に滅法強いんだよね。
さらに、「Hackな言語」についても調査し、 「Hack比/Suck比」を計算してみる。
| Language | Total Files | Hacks | Sucks |
|---|---|---|---|
| C | 4,530,000 | 224,000 | 11,300 |
| C++ | 847,000 | 2,700 | 3,000 |
| C# | 120,000 | 2,000 | 50 |
| Fortran | 115,000 | 400 | 20 |
| Java | 830,000 | 10,400 | 500 |
| JavaScript | 22,700 | 600 | 100 |
| Lisp | 36,000 | 600 | 100 |
| Perl | 208,000 | 14,200 | 400 |
| PHP | 580,000 | 14,200 | 300 |
| Python | 326,000 | 400 | 300 |
| Ruby | 15,600 | 2,000 | 50 |
| Shell | 80,600 | 4,000 | 50 |
| Visual Basic | 29,900 | 400 | 50 |
RubyはHackな言語であることが認定された。