Ruby会議2010へ行ってきた。

Ruby会議2010へ行ってきた。何を隠そう、Ruby会議に参加したのは今回が初めてである。休日に自由時間を確保するのは、小さな子供が居る既婚者男性諸君であればそれが如何に厳しいことかということを理解しているはずだ。だが息子も３歳になり、さらに幸いにも予定が一切かぶっていなかったため、３日間すべて参加することが出来たのであった。

Ruby会議2010のテーマは「Conflict and Resolution」（衝突と解決）である。大規模なオープンソースプロジェクトには人々の衝突がつきものであるため、日本有数のオープンソースプロジェクトであるRubyにはピッタリのテーマであるといえよう。というわけで、Ruby会議初参加者による視点で、面白かったことや気になったことなどについてレポートをお届けしたい。

１日目

まず最初に、今回一番の目当てにしていた「Ruby開発会議つくば」を傍聴。gdgdなリラックスした雰囲気のもと、Rubyの今後について、非常に大事な議論がなされていた。まず第一に、Ruby 2.0というブランチを切らないということ。今後、1.9.xを改良していって、「こういう機能が揃えば2.0だと言える！」という状態になったとき、改めてRuby 2.0と呼ぼう！というような話であった（ように思う）。よってRuby 2.0ではRuby 1.9との後方互換性を保証します！というMatz氏の大胆（？）発言が飛び出して、会場が沸いた。Ruby 1.9との互換性があるというのはバージョンが上がってもスクリプトの修正しなくても良いということを意味するため、開発者にとっては非常にありがたいことであると思う。

もうひとつ気になったのがライセンスの変更について。現在、RubyはRubyライセンスとGPLv2のデュアルライセンスで配布されている。これを、Rubyライセンス+GPLv2以降もしくはRubyライセンス+BSDライセンスへ変更しようというものだ。フリーソフトウェア支持者である俺は、もちろんBSDライセンスへの変更はしてほしくない。なぜなら、GPLは素晴らしいからだ！

Rubyは、Rubyライセンスによって、実質的にプロプライエタリなソフトウェアでも利用可能である。GPLv2を付与することによって、フリーソフトウェアでも利用可能となっている。では、GPLからBSDライセンスへ変更する意義はなんだろうか？会場で指摘されていたのは「BSDLとRubyライセンスの非互換性」である。この非互換性により、RubyのソースコードをBSDLへ移植することが出来ないのである。

別にいいんじゃね？

などと言ったら袋叩きにされる気がするので言わないが、まあ困っているようなので提言をひとつ。著作権の原則として「自分が書いた部分」、つまりパッチの著作権者は自分自身である。著作権が自分のままであれば、Rubyプロジェクトでそのソースコードを利用することは出来ないので、著作権を譲渡することになる。（余談だけど、現在は暗黙的に著作権の譲渡が行われているようなので、この点はキッチリと文書化しておいたほうがいいと思う。裏をとったわけではないので間違っていたら聞き流してください＞Ruby方面の人）著作権を譲渡してしまうと、そのソースコードを自分で勝手に流用することが出来なくなってしまう。そこが問題で、パッチの再利用性を高めるのであれば、「パッチはRubyライセンスとBSDLのデュアルライセンスで提供してください。」という仕組みに変えてしまえばいいのである。これならば、他の人が書いた「パッチ」もBSDLなので、BSDLなプロジェクトでも再利用可能であろう。最終的な完成品であるRuby本体ではRubyライセンス+GPLであっても、この方式なら実質的に問題ないのではないだろうか。既存のソースコードは流用出来ないが、まあそれは諦めていただくしかないだろう。

ここで、RubyライセンスとGPLv2のデュアルライセンスということの意味を考えてみよう。Rubyライセンスはプロプライエタリなソフトウェアでの利用が可能であるが、Rubyという名前を使うことが出来ない。一方、利用者がGPLv2を選択した場合にはRubyという名前を利用することが可能だ。すなわち、「プロプライエタリなソフトウェアはRubyという名前を使ってはいけないヨ！」という制約がこのデュアルライセンスによってもたらされているわけである。これをRubyライセンスとBSDLのデュアルに変更すると、プロプライエタリでもRubyという名前のソフトウェアを作成することが可能になる。まとめると、Rubyライセンス+GPLv2からRubyライセンス+BSDLに変更すると、ライセンスの性質は次のように変化することになる。

• プロプライエタリな派生ソフトウェア（または引用した場合）においてRubyという名称が利用可能になる。
• BSDLなソフトウェアへの引用が可能になる。

俺自身はなぜ現在RubyライセンスとGPLv2のデュアルを採用しているかといった事情は知らないが、ライセンスを変更する前には本来の目的をよくよく考えていただきたいと思う。

また、厳密な話をすると、もし著作権の譲渡が行われていない場合、Rubyのライセンスを変更するにあたってはすべての著作権者に同意をもらわなければならないはずで、それはつまりパッチを送ってくれた人すべてが対象となる。Developper Howtoのページを見ても著作権関係の記述はないので、その辺の運用についてもう少し明記したほうがいいんじゃないかと思った。

ちょっと話が著作権関係に逸脱してしまったのでここで本題に話を戻すと、この会議では「オレオレデバッガ」を書いて持ち込んだ人が居たりして、会場が盛り上がっていた。仕組みはあまりよく理解出来なかったが、彼が熱い漢であることは間違いない。

そしてOpening。今年のテーマは「Conflict and resolutionだ！」ということについて言及された。


さて、お次はtoRuby勉強会に出席した。出席した動機は栃木県在住だから。toRubyの方々が普段勉強会を開いているのは西那須野なので、我が家からはちょっと遠いのだが、これを機に時間があれば参加させていただきたいと考えている。ちなみに、toRuby勉強会@Rubykaigi2010ではdRubyの講習会が開催された。

夜には「飲食物持ち寄り」の懇親会が開催された。懇親会ではMatz氏と初めて対面することができ、非常に嬉しかった。Matz氏にはRubyにおける並列処理の今後について質問してみた。（実は今一番興味があるのが並列処理についてなので、Matz氏と笹田氏に質問したい！という思いがあったのだった。）Matzi氏曰く、

「これからの並列処理はシェアードナッシングにするべきじゃないか」

とのこと。GILが残っている理由は単にスレッドセーフに処理を書き直すための手間が問題なのではなく、並列化の方向性としてスレッドセーフにしてスレッドを並列に走らせるよりも、ロックがない構造のほうが利点があるということなのだ。当然だが、いちいちロックを取らない構造の方が、シングルスレッドの処理は高速になる。

俺にとって、シェアードナッシングアーキテクチャと聞いてまっさきに思い浮かぶのはMySQL Clusterだ。シェアードナッシングアーキテクチャに関する考察については、いずれ機会を改めてエントリを設けたいと思う。

もう一方、お話が出来て嬉しかったのがRailsのコミッタであるwycatsことYehuda Katz氏。「最近、MySQLのドライバはmysql/ruby（@tmtms氏作)じゃなくてmysql2を勧めているよ〜」と曰っておられた。mysql2は拡張モジュール内で処理を並列化しているそうで、スループットが良いとのこと。

余談であるが、mysql2を利用するにあたって注意したいのはライセンス。MITライセンスの表示があるが、mysql2はlibmysqlclientのラッパーなので本来はGPLv2でなければならないはずだ。確かにmysql2自身の著作権は作者のものなので自由にライセンスを選択できるが、GPLv2の性質上、libmysqlcientをリンクした時点でGPLv2にしなければならないはずである。混乱するだけなので、GPLなライブラリを利用する場合はMITLやBSDLをつけるのはやめて頂きたい。

@tmtms氏には引き続きRuby/MySQLの開発に注力していただきたいと思う。

２日目

Matz氏による基調講演が行われた。内容は聴衆の期待を裏切らないRuby 2.0の話。現在のRubyの気に入らないところなどが紹介され、例えばLocal Variableのスコープが気に入らないけど、それに対してLocal Variable Propagationという対策があるけれども、やっちゃうと過去との互換性がなくなっちゃうから断念せざるを得ないよね、というような話がなされた。Matz氏は事前に「技術的な話すぎて聴衆を置き去りにするかも」という旨のことをTwitterで呟いていたが、その通りになったと思う。特に光の速さで聴衆を置き去りにしたであろうと思うのが「mix」の話。既存のMix-inではModuleからメソッドをincludeによって継承するけれども、mixではメソッドのコピーしてしまうそうだ。俺も置いて行かれたうちの一人なので、後でよく復習しておこうと思う。


この日は昼飯に出たらすごく時間がかかってしまい、「超絶技巧 Ruby プログラミング」を見逃してしまった。なので後から動画を見たのだが、面白いのでオススメである。


RubyコミッタであるTanaka Akira氏による「UNIX修正主義」も興味深かった。IOモジュールとlibcのstudioの違い、特にバッファリングに関するところなどが詳細に解説された。UNIX信者であれば、深く共感を覚える内容の講義であったと思う。UNIX方面の人は必見である。Rubykaigi日記に各種プレゼンの動画が上がっているので、今すぐチェックされたし。


そしてお待ちかねライトニングトークの時間。しょっぱなの「ARToolKit」に度肝を抜かれつつ、テンポよく最後まで楽しむことができた。個人的には「parse.yの歩き方 -ワシのRubyは4式まであるぞ」が好きだ。


２日目の夜は登録制の懇親会があった。会場に飲食物がたっぷり用意されており、参加費５０００円なり。妥当な価格だったと思う。（俺は個人スポンサー枠で登録したので、懇親会費込みであった。）そしてお目当ての笹田氏に突撃。並列処理について突っ込んで質問をさせて頂いた。MVMを利用した場合のAPIはまだ固まっていないらしい。

シェアードナッシングアーキテクチャを取るということは、オブジェクトやデータをVM同士で交換する必要があるため、マルチスレッド＋共有メモリというプログラミングスタイルは捨て去らなければならない。そのためには何らかの（例えばdRubyのような）VM間通信のためのAPIが必要になる。もちろん通信にはオーバーヘッド（特にメモリをコピーするときの）があるので、そこがボトルネックになってしまうと性能は出ないだろう。笹田氏がMVMにこだわるもうひとつの理由は、スレッド同士が競合状態になってしまったときにSIGSEGVが起きてしまう可能性があるからだ。並列プログラムでロックが失敗すればSIGSEGVはつきものであるというのは多くの人に共通する感覚ではないかと思う。だが、「Rubyではメモリが壊れたときはSEGVではなく例外が上がるべき」というMatz氏の考えがあるそうで、確かに尤もだと思う。（競合状態のデバッグは難しいので、Rubyによるプログラミングを平易なものに保ちたければ、そのようなデバッグが難しくなる要素を持ち込むべきではないという考えだ。）

シェアードナッシングにするべきか、ロック＋共有メモリにするべきかは、かなりデリケートな問題であると思う。ただ、笹田氏はすでにロックを使った場合にあまり性能が出ないということを博士論文で考察されているらしく、次はMVMの評価をしたいとのことであった。笹田氏の博士論文はWebで公開されているのでゲッツしたところだ。やはり学位論文だけあってかなりのボリュームがあるが、気合を入れて読もうと思う。

ちなみに、MySQLはロック＋共有メモリ型のマルチスレッドモデルであるが、丁寧にボトルネックを解消してきたおかげでバージョンを追うごとに並列処理性能が向上している。（前々回のエントリを参照。）並列処理性能を向上させるのは非常に根気の要る作業なのである。Rubyではそれほど多くの人手をかけられないかも知れないが、来たるべきメニイコア時代に向けて、並列処理性能の向上を地道に頑張って頂きたいと思う。（お前が手伝えよ！と思われるかも知れないが、大人の事情があるのでご理解頂きたい。）

３日目

この日は聴きたいものがなかなか同じ場所に定まらず、セッションが終わるたびに部屋を行ったり来たりしてしまった。色々聞いたけどここで取り上げたいのは、まずMongoDBの話。最近流行りのNoSQLである。

MongoDBはドキュメント型のデータベースであり、スキーマレスなのでなんの前触れもなくコレクション（RDBMSにおけるテーブル相当）に対して新しい属性を定義することが可能である。コレクション同士には関係性（≒外部キー）を持たせることが出来ないので、平たく言えばRDBMSにおいて完全に非正規化したデータを格納するような感じで使う。RDBMSの利点は、正規化することによりレコードを更新する箇所が限定されるという利点があるのだが、非正規化されたデータを扱う場合には更新しなければいけないレコードが増えてしまうというトレードオフが発生するだろう。スキーマレスか正規化かという選択である。また、MongoDBにはレコードをロックする仕組みがない。排他制御はどうすればいいのかと小一時間考えたのだが、恐らくVersion Numberパターンというデザインパターンを用いることで解決できるのではないだろうか。例えば以下のように。（識者の意見を求む。）

db.mmm.update({username: "mongo", version: 1}, {username: "mongo", version: 2, ...})
> db.runCommand( "getlasterror" )
{ "err" : null, "updatedExisting" : true, "n" : 1, "ok" : 1 }
db.mmm.update({username: "mongo", version: 1}, {username: "mongo", version: 2, ...})
> db.runCommand( "getlasterror" )
{ "err" : null, "updatedExisting" : false, "n" : 0, "ok" : 1 }

MongoDBは、単一のテーブルに非正規化したデータを保持するだけで済むようなアプリケーションなら、結構使えるんじゃないかと思った。


次に印象深かったのがるりまサーチの話。るりまサーチとは、るりま（ルビー・リファレンス・マニュアル）を全文検索できるアプリケーションで、http://rurema.clear-code.com/などで利用可能だ。そこで利用されているのが全文検索エンジン期待の星、そう、「Groonga」である。まずは「この度（というか本日＝8/29）Groongaバージョン1.0がめでたくリリースされました！」という発表から。バージョン1.0！！なので、もうゴリゴリ現場で使ってOKなのだそうだ。Groongaの特徴としては、

• Sennaの後継。Sennaはインデックスを構築するだけでデータは管理しなかったが、Groongaではデータをもつようになった。
• スキーマあり。
• 位置情報対応。

などが挙げられるそうだ。バージョン1.0なのでどんどん使おう


他に面白かったのは「How to survive in post Rails' world」というおはなし。ｔDiaryの作者であるhbst氏が新しい会社に入ってursm氏に出会い、思考パターンというか文化の違いを目の当たりにしたという話だった。観察し過ぎだろうと思った。


そして「情熱プログラマー」の著者であるChad Fowler氏による基調講演があり、Rubykaigi2010はClosingへと向かった。基調講演は拍手喝采であり、余韻冷めやらぬままReject会議へ突入。「Google WAVE本」のあんどうやすし氏の自虐ネタなどに盛り上がり、満足してつくばを後にしたのであった。

まとめ

Ruby会議は楽しいのでぜひみなさんも行きましょう。ただし、次回は「最後のRuby会議」になるそうだ。2011年7月、東京にて開催予定だそうだ。本当に最後なの？辞めないで〜！というのが正直なところである。

Ruby会議2010の様子は、RubyKaigi日記で公開されている（ニコニコ動画）ので、行けなかった方はぜひチェックして頂きたい。Reject会議の様子は、YouTubeにアップされているようである。まだまだRuby会議2010は当分楽しめそうだ。

運営スタッフの方々、発表者のみなさん、コミッタのみなさん、お疲れ様でした！！来年も楽しみにしています。