dRubyConf draft

gistfile1.md

dRubyConf 2012　参戦日記

こんにちは。「RubyConf参加支援企画プログラム」に採択していただき、デンバーまで行ってきた井上といいます。

今回は私がアメリカのカンファレンスで発表するまでの道のりと、dRubyの作者である関将俊さん（以下「咳」さん）と一緒に聞いてきた他のトークの概要を紹介していきたいと思います。

ちなみに私たちはdRubyに関連するような並列、並行プログラミングやデータベースのトークを中心に参加したので、このカンファレンスは「dRubyConference」という視点で見ていきます。

応募するまでの道のり

８月１０日ごろに日本Rubyの会の角谷さんより参加支援企画プログラムのことを教えていただき、咳さんと一緒に応募することにしました。 ルビマの読者のみなさんはご存知かもしれませんが、咳さんは2006年にRubyKaigiが始まって以来毎年のようにトークをされており、話題が豊富です。 その中でなににフォーカスしようか迷っていたのですが、私が今年の３月にLondon Ruby User Group (LRUG)でdRubyについて話した時に、dRubyの初期バージョンのコードレビューをしながらdRubyの構造を解説した箇所が結構好評でした。

そこで今回は咳さん直々にdRubyの開発秘話を話していただくという方向性でトークプロポーザルを書くことにしました。

最初のバージョンは「The dRuby Begins (Metaprogramming rises)」というタイトルだったと思います。

しかしながら同僚にトークプロポーザルのレビューをお願いしたところ「そのタイトルでは話の中身は何で、参加者はどういうベネフィットを得られるかがわからない。あとタイトルはもっとキャッチーでちょっとあおりが入るぐらいがよい」 という指摘を受けました。そこで練り直したタイトルがこれです。

「Rails Is A Follower: what we can learn from dRuby’s metaprogramming magic」

Railsをフォロワー扱いしてしまうのはかなり大胆なタイトルだと思いますが、これはThe dRuby Bookの中でMatzに書いていただいたForewordの中から拝借しました。そして同時に参加者は「メタプログラミングについて学べる」という目的を提示できたのではないかと思います。

当選してから

９月５日に当選が決まってから実際に何を始めるか考えはじめたところ、「dRubyを開発するまでの歴史を1990年ぐらいから系統立てて話をしていくのはどうか」という方向性にで咳さんにドラフトを書いていただき、それを私や角谷さんからのフィードバックをもとに色々修正していきました。２人の役割分担としては、最初のイントロとdRubyのデモは私が担当し、その後にdRubyが出来るまでの咳さんのプログラミングスタイル、そしてそのプログラミングスタイルへの不満を解決するためにdRubyを設計した際のデザインポリシー、実際に実装する際のメタプログラミングのテクニックの数々を咳さんに直接話していただくことにしました。

大体カンファレンスの始まる２週間前までに咳さんに話す内容のスライドと台詞を全部日本語で書いていただき、その後で私が翻訳しました。デモの部分はライブで行うのには不安があったので、事前にscreenrというサイトでデモビデオを作成して、プレゼンテーションツールに埋め込む形にしました（私達のプレゼンツールはAppleのキーノートだったのですが、まつもとさんが私たちのトークをご覧になった際に「この機能Rabbitにも欲しい」と日本にいるすとうさんを叩き起こして急遽実装させていました）。

その後で一度咳さんの箇所も含めた部分を社内でリハーサルした後、同僚のMark（彼はイメージアップローディングgemのDragonFlyでちょっと有名です）に文法を直してもらった後、咳さんの担当個所を全て朗読してモノを音声ファイルにしてもらい、咳さんにお渡ししておきました。これで咳さんもカンファレンスが始まるまでに流暢なQueen's Englishをマスターされているはずです。

渡米

カンファレンスの始まる２日前の１０月３０日にデンバー入りしました。ホテルにつくと咳さんが既に到着しており、あいさつもそこそこに最後の打ち合わせに取りかかりました。

咳さんは、私がお渡しした音声ファイルを節ごとに再生可能な形に換えた上で何度も練習されていたようで、発音などは特に問題ありませんでした。ただ苦労されていたのは息継ぎのタイミングです。

例えば以下の例を見てみましょう。

You also spend time trying to come up with cool urls, but that’s not the core of your application.

Markはかなりゆっくりめに話してくれていたのですが、それでも英語を母国語でない人が話すには長過ぎて、途中でつまってしまいがちです。あと「that’s not the | core of your | application.」といった変な位置で区切ってしまうと聞きづらくなってしまいます。

そこでMarkの音声ファイルを一緒に聞きながら、以下の要に息継ぎのタイミングを紙に記入していきました。

You also spend time | trying to come up with cool urls, | but that’s not the core | of your application.

これで準備もバッチリのはずです。

この日の晩はBuppa Gumpというレストランでエビ料理を堪能しつつ万葉の五十嵐さんと卓球対決をしました。

Day 1

いよいよRubyConfが始まりました。見たいセッションはいくつもあったのですが、その中でも私たちのトークのネタとして使えそうなものを中心に見ていきました。

Allow me to reintroduce myself. My name is MagLev. 11:30am - 12:15pm (45m)

SmalltalkのオブジェクトデータベースをRubyで使うことの出来るMagLevの紹介。

Maglevの売りはデータもコードもまとめて「Stone」というデータベースに格納し、各バーチャルマシーンはトランザクションを使って保存できるのが売りです。

サンプルファイルはこのような感じです。

# VM #1
PROOT = Maglev::PERSISTENT_ROOT
pierre = Cat.new("Pierre")
pierre.object_id
# => 1234567
PROOT[:pierre] = pierre
Maglev.commit_transaction

トランザクションの始めは暗黙的に行われており、commit_transactionを打った時点でStoneの方に保存します。 またMaglevの軌道モードを変えることでトランザクションの範囲をRubyブロックの中で明示的に指定することも出来ますし、また「transient」というブロックの中で「この部分はStoneに保存せずLocal VMの中だけで持っておきたい」と指定するのも斬新でした。

Maglev.transient do
  # Will only be persisted locally
  # Won't be written to the stone
end

MagLevはどんなデータ構造を扱えるのでオブジェクトデータベースのように使うことも可能です。

また比較としてRedisのSorted Setの例を持ち出していました。Redisは多くのデータ構造を持っているのですが、例えばランキングボードを計算したい時にSorted Setを使うとします。しかしながらSorted Setは一つの値に対してしかソートできないので例えば「ポイントが同順位の場合は日付で順位決めができない」という問題が起きてしまうそうです（RDBMSだとorder by a, b, cと複数指定可能ですが）。 そういった際にデータベースの機能に縛られるのではなく素直にRubyでできると言っていました。

このトークを聞いてみての感想を咳さんに聞いたところ、「Maglevはオブジェクトデータベースとして使うには良いかもしれないが分散処理で同期をとるための機能としては向いていないのでは」とのことでした。 「でも逆にMaglevをdRubyで分散化したら良いんじゃない？」とのこと。面白いことに私たちのdRubyのトークの後にこのトークをした人が話しかけてきて、全く同じ提案をしてきました。

Building Data Driven Products with Ruby 3:30pm - 4:15pm (45m)

データサイエンティストによるBig Dataの扱いについて。

実は私はあまり集中して聞いていなかったのですが、咳さんは面白かったとのこと。何が面白かったのか聞いてみたところ「Hadoop Hadoopとか叫ばれているけれどBig Dataのうちのほとんどのデータはノイズなだけで、実は適切なフィルタリングをすることで十分にデータサイズを小さくすることが可能なんだよね」とのことでした。以下のような３行のコードでビッグデータを手なずけることが出来るのはある意味あっているかも知れません。

STDIN.each do |line|
  p puts line if line.match(/user_id=&/)
end

Dissecting a Ruby Block Pat Shaughnessy - 5:30pm (45m)

これは４５分間ひたすらRuby Blockの実装を解説するというマニアックなものでした（そしてこのトークの作者は、Rubyのソースコードを勉強するために６ヶ月会社を休職したそうです）。なぜBlockがdRubyと関係あるかについてですが、dRubyはオブジェクトを他のプロセスに渡す際にMarshal.dumpを行い、dumpが可能なものはそのオブジェクトの値そのものを、そうでない場合はそのオブジェクトの参照値のみをおくるという仕組みになっています。その際のMarshal.dumpが出来ないものの筆頭としてBlockがあげられるので、なぜそれができないかということを理解する意味で重要とのことでした。

実際にはblockの中身を実行する際にどのようにスタックやヒープが使われるかというのを丁寧に図入りで示してくれたのですが、私にはちんぷんかんぷんだったので、ホテルに戻ってさらに２時間ほど咳さんの特別講義を受けることになりました。

発表の前夜

明日はいよいよ発表です。この時点でスライドは完成していたのですが、初日の色々なトークに刺激をうけ、いくつかトピックを追加することにしました。ここまでの発表で紹介するdRubyの中身は比較的分かりやすいものばかりでした。しかしながらもっと難しいトピックも加えて聴衆を置いてきぼりにしたくなってきました。というのもトークの中身がただ分かりやすいだけだと「もうわかった」と満足して、そこから先がなかったりします。「う〜ん、これは難しい。ぜひもっと自分で調べてみよう」と思わせるぐらいのほうが刺激があると思ったからです。

ただそれにはひとつ問題がありました。その高度な問題を英語で説明する私が理解する必要があるということです。１０時ぐらいから咳さんに説明してもらって、コンセプトを説明するビデオをつくったり、私が理解するまで咳さんが根気よく説明を繰り返しているうちに夜中の１時になっていました。

Day 2

早朝にもう一度練習をした後会場入りしました。今日は「Concurrency Day」というべくトラック１〜３とある部屋のトラック３はConcurrencyに関係したトピックが並んでいました。もちろん私たちの発表もトラック３だったので、朝からずっとこの部屋に張り付いて他の発表を聞いてみました。

Asynchronous Processing for Fun and Profit 11:30am - 12:15pm (45m)

最近人気急上昇中のSideKickというバックグラウンドジョブライブラリーについての講演です。

まずは非同期プログラミングをするさいのTipとしてStateless、Idempotent (冪等性)、Embrace Concurrencyの３つをあげていました。 その上でResqueなどのライブラリーと比較した上でSideKiqの高性能をアピールしていました（主な理由はResqueではワーカーデーモンをプロセスで立ち上げるのに比べ、Sidekiqではスレッドを利用している分メモリを食わないとのことでした）。そして基本的な機能はLGPLでフリーですが、他の高度な機能やサポートサービスを有償で受けているそうです。

咳さんに意見を伺ったところ「dRubyでも同じの実装可能」とのことだったので「dRubyの有償サポートもお願いします」とお願いしておきました。

注：RubyConfのあとでNokogiri等で有名なAaron Pattersonさんより「Resqueは次のリリースでスレッドもサポートされる」とのことでした。そしたら再度ベンチマークを見る必要がありそうです。

DRb vs RabbitMQ Showdown 1:30pm - 2:15pm (45m)

「DRb vs Eventmachine Showdown　」というのがもともとのタイトルだったのですが、トークプロポーザルを出した後に予定が変わったそうです。 このトークが始まるまでは「あ〜、絶対なんでDRbからEventMachineに移行したかがメインのテーマで、DRbはものすごくDisられるんだろうな」と咳さんともどもびくびくしていました。

しかしながらこのトークの発表者のDavyさんはとっても良い人で、「使うのは適材適所、dRubyだと接続先のアドレスを指定しなければいけないけれど、複数のサーバ間でジョブをやり取りする際には適していないのでそこだけRabbitMQでメッセージバスを構築しました。でもそれ以外の箇所は今でもdRubyを使っています。だってとっても簡単で使いやすいんです」とおっしゃっていました。「その用途ならRinda(dRubyで作られた分散タプルスペース)で出来そう」という言葉はぐっと飲み込みつつ「咳さんが友達になってほしいと言っているので、後で一緒に写真を撮って下さい」と申し込んでおきました。

彼女は快く快諾しただけでなく、なんとすでにThe dRuby Book本を所持しており、咳さんだけでなく私にまでサインを求めてきました。サインを求められるなどということは今までの人生でなかったので私は舞い上がっていましたが、こういうことになれっこの咳さんは「咳さんdRuby専用ツバメはんこ」をクールに押していました。

Rails Is A Follower: what we can learn from dRuby's metaprogramming magic 2:30pm - 3:15pm (45m)

いよいよ私たちの出番がやってきました。心強いことに日本人の参加者の方々が座席の前の方に座っている上に、dRubyのエキスパートである「脳博士」ことEric HodelさんやMatzもいるので、いざ説明に困った際には助け船を求めることもできそうです。

まず最初に私の紹介と咳さんの紹介を行いました。事前に仕込んでいたアメリカンジョークはみごとにすべってしまいましたが、咳さんがポケモンの達人であるという点は受けていました。

次に私のデモです。dRubyは複数のプロセス間でのコミュニケーションを可能にするライブラリーなため、デモの際にirbを複数立ち上げるライブデモが必須です。しかしながら複数のターミナルを操りつつ何が起きているかを説明するのは自分の頭が混乱すること必至であったため、デモの内容をあらかじめビデオにとっていたのは正解でした。そして前日に急遽付け加えたトピックについてもちゃんと説明できました。スライドのコードの中にわざと未完のコードをのせ「このコードで正しいですよね」と会場に投げかけると、Aaronさん一人が「はい」と返事してまんまと罠にはまって下さいました。ごちそうさまです。

特訓の成果もあり、咳さんも堂々とdRubyの出来るまでの歴史と、dRubyをデザインする上での様々な技巧について説明されていました。ネタバレになってしまうのでここでは言いませんが、咳さんの最後の決め台詞にもしびれました。

いよいよQ&Aです。一番最初の質問は私がわざわざデモまでして説明したことを聞いてきたので「本当に私の説明は伝わったのだろうか」と不安になりましたが、このちょっと見当違いの質問にみんな安心してか、その後は様々な質問をしてくれました。中には私が答えられないような質問もいくつかあり「ごめんなさい。その箇所ってちゃんとdRuby本の最後の方に書いてあるんだけれど、もうその頃にはへとへとになっていて訳分からないまま翻訳しちゃいました」といった翻訳秘話を壇上から暴露するはめになってしまいました。それでもEricさんや@mrknさんにも飛び入りで説明していただいて、なんとか危機を乗り越えることが出来たと思います。

トークの後には壇上に数人の方々が来てくれて「すごいよかった」とか「実は私は金融機関で働いているだけれどそこでdRubyとRindaをかれこれ５年ほど使ってるんだと」といった胸熱な言葉までかけてもらいました。 また一番最後の人は「dRubyでの並列処理を高めるためのパッチを書いたんだけれどdRubyに取り込んでもらえませんか」と告白してきました。咳さんは丁寧にコードを見た上で、「彼のコードの致命的な欠陥を見つけるパッチを書きました」と嬉々として私に報告していました。 　　

Day 3

咳さんによるプログラミング集中講義

ここのところ時差ぼけもあり毎朝５時には起きていたのですが、今日は朝から「非同期プログラミングとは同期のプログラミングである」という禅問答じみた命題に対する講義を３時間ほど受け、その後も３日目の数々の発表はほぼ無視して似たようなトピックについて話し続けていたと思います。　あげくの果てには「MatzとのIntimate(親密な) Chat」と題するQ&Aの時間には、dRubyで非同期処理を実現するためのコードを咳さんは書き上げていました。中身を見せてもらったのですが、非同期にするための特別な処理は書かれておらずGC（ガーベージコレクション）に対処するためのコードが３０行程度あるぐらいでした。要は「dRubyには非同期処理をするための要素はほぼそろっている」からなのですが、理解するまではきつねにつままれた気分でした。　なんでもこのトピックに関しては札幌Ruby会議に提出されていたのですがリジェクトされたんだそうです。ぜひ来年のRubyKaigiで話してほしいトピックです。とっても深くて面白いトピックなので、各会議のみなさま採用してあげてください。

あと思ったことがあったのですが、咳さんに教えていただいて一瞬「分かった」と思っても、少し違うアングルで似たような問題を出されるととたんに答えに窮してしまうことが何度もありました。これを咳さんにいうと「書かないと分かんないじゃない？」と至極まっとうな答えが返ってきました。そう、必要なのは「We Code」。　ちょうどタイミングよく会社の同僚から関連したメールが届いていたので、それに反証するためのパッチを書いて送っておきました。

最後に

発表内容のビデオはConfreaksで公開される予定です。

またこれらのトークをより楽しむためにThe dRuby Bookをお手もとにおいておくことをお勧めします。

とても良い記事ですね！勉強になりました！（しかもおもしろい！）

「Maglevの軌道モードを帰る」→
「Maglevの軌道モードを_変える_」

「Sorted Setは一つの値に大して」→
「Sorted Setは一つの値に_対して_」

「dRubyで分散か」→
「dRubyで分散_化_」

（叩き起こされた理由を初めて知りました。。。）

「何が面白かったのか聞いてみたとろろ」→
「何が面白かったのか聞いてみたと_こ_ろ」

誤植の指摘ありがとうございます。