日本Ruby会議2011 2日目レポート［更新終了］

7月16日(土)から18日(月）までの3日間にわたり、練馬文化センターにて日本Ruby会議2011（略称：RubyKaigi2011）が開催されています。本ページでは、2日目の模様を随時レポートしていきます。

今回、Rubyistが集まっているRubyKaigiなのに1人ぼっちで昼食を食べることになりそうな人のために、何人かのグループになって昼食を食べに行くための斡旋エコシステム「Anti-Bocchi Lunch」が行われています。興味のある方は、お昼（前）に2Fジュンク堂書店RubyKaigi店横のボードの場所に向かってみましょう。

また、参加者の人がつくっていくアンカンファレンス!RubyKaigi(NotRubyKaigi)2011開催のための会場が3Fに用意されます。興味のある方は、スタッフの方に尋ねてみましょう。

西山和広さん「安全なプログラムの作り方」

@znzこと西山さんの発表です。歴史を振り返りながら、セキュリティの意識や、そこからでてきた脆弱性を話しました。

背景

JavaScriptもなかったころ、CGIで作された掲示板がありました。その掲示板は投稿されたメッセージから、 HTMLのタグを解析して必要なAタグやBタグ等はそのまま通し、BODYやHTMLタグなどをエスケープしていました。しかし、これはHTMLの構造が崩れてるのを避けるための対応で、セキュリティのためではありませんでしたと振り返ります。

しかし、ブラウザが高機能化した結果、JavaScriptが普及していき、onclick属性やjavascript:なスキーマをケアする必要がでてきたと言います。アプリケーション自体には何も変更しておらず、何も問題がなかったはずなのに、脆弱性のあるものになってしまったそうです。

このことから、永遠に安全なアプリケーションを作るのは困難であることを述べました。

具体例

一般的な話として、入力はきちんとチェックを行い、出力はエスケープを行うという基本を抑えるとともに、ブラウザを始めとする、外部環境の変化にも注意するべきだと言及しました。

また、具体的な避けるべきコーディングとして、いくつか例を挙げました。「⁠/tmp」を直接使用する場合、固定のファイル名を使ってしまうと特に危険で、symlink attack を狙われる可能性や、Windowsに移植したときに困ってしまうことを紹介しました。そのため、Ruby on Railsを使っているならばRails.root + "tmp"のようのようなパスを使用するか、tmpdirやtempfileのような標準添付ライブラリを使用したほうが良いとアドバイスしました。

次に、正規表現による脆弱性として、\A \Z の組み合わせと ^ $ の組み合わせの動作についてを紹介しました。 Rubyの場合、 /^マッチする文字列$/ のような正規表現の場合 "任意\nマッチする文字列\n文字列"にもマッチしてしまうため、文字列の先頭・末尾を使う場合は \A 等を使うべきと説明しました。

その他には、system関数を使用する場合は、実行するコマンドの引数の数だけ、 system関数の引数も増やす使い方をすることで各パラメータを正しく展開されるそうです。このような場合のチェックポイントとして、ファイル名に空白が入っている場合やnull文字が入っていても問題がないか、という点について気をつけると良いことを紹介しました。

Elise Huardさん「Actors on stage」

ベルギーから来たElise Huardさんによる、Actorモデルに関する発表です。発表の取っ掛かりとして、「⁠Actor」を「俳優」にひっかけて並列性について話がありました。曰く、映画の撮影ではアクターも複数人が別々の場所でロケを並行して撮る、音楽なんかも並行で作成し、映画監督が最後にMapReduceのように一つにまとめて出力する、と。

かように人間の活動はそもそも並列的です。そしてプログラムも、元々はシングルプロセスによる逐次処理が多かったのですが、近年になってマルチプロセスが増えてきたため、並行性を考えなければならなくなったと語ります。しかし、並行処理をプログラミングすることは難しく、VMとOSそれぞれでプロセス／スレッド管理があったり、状態の共有と変更が時に非決定的になったりすると述べました。

そこでActorモデル

Eliseさんはその難しさに対して「Why Bother（だからなんだっていうの？⁠）⁠」という言葉を掲げます。「⁠アプリケーション開発者レベルで並行性を考えるか？」「⁠それとも、サーバなど下のレイヤーに任せるか？」という問いがあるのなら、プログラマとして並行性を考慮していきたいと言及しました。

そんなEliseさんが注目するのが、Actorモデルです。Actorモデルには明示的なグローバル状態がなく、アクターと呼ばれる要素同士が非同期にメッセージのやりとりをして処理をこなしていきます。基本的に非同期なので、実行順序を決めたいときはそれに参加するアクター達だけで指定し合うことで解決。また、可変な状態はそのアクター内にのみ限定され、アクターが状態遷移器になっているとのことです。こういった特徴たちが、並行性に向いたプログラミングモデルを提供してくれるというわけですね。

そして、EliseさんはRubyで実装されたActorモデルを紹介しました。@mentalguyのRubinius Actors。スレッドベースではなくイベントベースである@basculaのRevactor。そして@basculaはCelluloidというライブラリも作っており、Eliseさんはこれに一番期待しているとして、Celluloidを利用して"Sleeping barber problem"という並列処理における典型的な問題を解くコードも披露しました。Rubyでは通常mutexを使うところを、Celluloidに用意されたモジュールをincludeすることでクラスをアクター化して解いていくと述べました。

他の言語を経由した利用

Actorモデルは、むしろRuby以外の言語で普及していると言います。商用言語としては初めてActorを本格的に採用したErlang。Erlangは関数型言語でもあり、コードには馴染みのない人が多いかもしれません。そこで、RailsコアチームのJose Valimが作ったElixirというものがあり、これはErlangVM上にRubyっぽい文法を構築したもの。ElixirならRubyistは馴染みのあるコードでErlangのActorを体験することができるとのことです。

また、Scalaでは標準ライブラリにActorライブラリが含まれていますが、それではなくAkkaというフレームワークが人気だそうです。Akkaの人気の一端としてはソフトウェアトランザクショナルメモリが実装されていることや、実際にEliseさんの知人の方もAkkaを使って大規模システムを運用しているといった話を挙げていました。そして、JRubyならばAkkaを使うことができる、という「裏道」を紹介しました。

銀の弾丸はない

以上のように並行性に対する強みを発揮するActorモデルですが、Eliseさんは「銀の弾丸はない」という注意も促しました。確かに、Actorモデルは「簡単に理解でき⁠」⁠、きちんとした研究と検証をくぐり抜けた「本物」のモデルであり、これを使えば「高度に分散化」されたソフトウェアをつくることができます。しかし、Actorモデルだけではシリアルな処理が必要な時には役立たずだし、依然デッドロックだって起こりうる。とはいえ、一度経験してみて損はない興味深いモデルの紹介だったのではないでしょうか。

最後に「並列プログラムを書くときは並列プリミティブを理解した方が良い」として、並列に相性の良いプリミティブをRubyの標準ライブラリにぜひ入れて欲しい、と提案して発表を終えました。

小川伸一郎さん「jpmobileのベストプラクティス」

RubyKaigi2010でも発表した、jpmobileメイン開発者である小川さんによるjpmobileの解説です。小川さんは、Tokyu.rbというコミュニティに参加しており、TokyuRubyKaigi04というイベントを10/29(土)に開催することを告知しました。

jpmobileには、メンテナンスのみ行なわれているRails2.3.X向けのバージョンと、現在のメインであるRails3.0.X向けのバージョン1.Xがあること。また、Rails3.1.X向けのバージョンとしてバージョン2.Xを出したいと述べました。今回は、jpmobile1.X系の機能を紹介しました。

jpmobileの機能の一つとして、まずキャリアごとに違う文字コードを自動で振り分けてくれる機能があります。jpcmobileではデータベースに文字列を格納する際にUTF-8に変換します。格納された文字列は、表示される際にそれぞれのキャリアが期待する文字コードに変換されます。また、携帯特有の絵文字に関しては、数値参照でViewに絵文字を埋め込むことによって、各キャリア向けの絵文字に変換して表示されると述べました。

携帯サイトでは、携帯電話がcookieに対応していないことがあります。そのような端末に対して、jpmobileでは自動でPOSTやGETのパラメーターに_session_idというパラメータを付与しSessionIDを付けてくれます。これは、Cookieが使えない端末かどうかを判定してくれ、使える端末ではCookieを使用してくれると述べました。

次にViewSelectorという機能を紹介しました。ViewSelectorでは、Viewファイル名のsuffixによって表示するViewを切り替えてくれる機能です。例えば、docomoの機種からリクエストがあった場合、以下のようなファイル名の順でファイルが存在するかを確認し、表示してくれるそうです。

index_mobile_docomo.html.erb
index_mobile.html.erb
index_mobile.html.erb

また、jpmobileでは携帯メールへの送信に対応していることを言及しました。Rails3のActionMailer::Baseを継承したJpmobile::Mail::Baseを使用することで、送信するメールアドレスにあわせた文字コードでメールを送信できるとのこと。

jpmobileではViewのテストのために、requiest.mobile?やassert_templateというメッソドを用意してると指摘します。これらのメソッドを使うことでFunctionalTestがしやすくなるということです。また、テストの手法によってjpmobileの返す文字コードが変わってくるそうです。

FunctionalTest: UTF-8
IntegrationTest: それぞれのキャリアの文字コード
MailerTest: UTF-8

最後に、現在わかっているjpmobileの既知の問題点等が述べられました。UTF-8をShift_JISに変換した後に、再度Shift_JISからUTF-8に変換するとき、きちんと元に戻らない文字があるとのこと。jpmobileでは波ダッシュや全角チルダなど、問題がありそうだとわかっている文字については自動的に変換されるようになっているそうです。 URIのパラメーターに日本語を使う場合や、メールを受信したときの文字コードなどは、まだjpmobileで自動的にできないため、それぞれ機種を判定して変換する必要があることを説明しました。

関将俊さん「Drip: Persistent tuple space and stream.」

恒例の"まだ初刷買えます"のdRuby本紹介から始まった関さんの発表。今年は「もうすぐ英語版が出るので、英語版の初刷も是非」と少し変化球をつけ、さらに英語版には今回の発表で触れるDripに関する章も追加収録されている、との朗報も伝えていました。

PTupleSpaceの反省

関さんが過去のRubyKaigiで発表したPTupleSpaceは、TupleSpaceの永続化版です。そもそもTupleSpaceとは、分散したプログラム同士が協調してデータ（タプル）を置いたり（write⁠）⁠、取ったり（take⁠）⁠、読んだり（read）ができる空間を提供するもので、Rubyの標準ライブラリの一つRindaにも含まれています。

このTupleSpaceを永続化すれば、障害が起きても復元できてストレージのように使えるかもしれない、として実装してみたPTupleSpace。ところが、dRubyで扱う制約上、PTupleSpaceから見て別プロセスへ渡ってしまったタプルは復元できないし、takeの途中でクラッシュするとタプルが削除前だったのか削除後だったのかわからないなどの欠点がありました。

また耐障害性以外の点でも、ストレージとして見たときのTupleSpaceは辞書ではなく同一データの重複を許す「Bag」であり、キー重複を許さないHashを模倣するには全体をロックしてチェックすることが必要でコストが高くなってしまう、といった部分があるようでした。以上から、TupleSpaceを単純に永続化するだけではイケテナイと結論づけていました。

新機軸のDrip

そこで今回発表するのが、Dripです。関さん曰く、Dripとは「かっこいいログ⁠」⁠。TupleSpaceとは違い追記はできてもデータの削除ができない点が特徴で、増加する番号（時刻を利用するが、同時にwriteが来た場合は片方に少しだけ数値を足す）が順にふってあるデータが並ぶ一次元のストリームのようなもの、とのことです。Dripではふってある番号を利用することがポイントで、例えばread時に番号を指定して「この番号以降をread」といった使い方をするようです。そして削除がないのでtakeがなく、Drip#writeとDrip#readがあるのですが、それ以外にもDrip#headという「最新の要素をn個くれ」というメソッドが追加されているとのことでした。

Dripでのクラッシュ時のデータの復元という点については、データに振ってある番号を覚えておけばそこから再開可能であるとのことです。また番号に時刻を利用しているので、時刻から推測してあたりをつけて再開することもできるのも嬉しい、といった点も挙げていました。

またDripはHashのように使えるかという点でも、データにタグをつけて保存し、そのタグがついたデータのうち最新のものを読み出すことで、それらしいことが可能になるとのことでした。ただしデータの削除はないから該当タグにnilを入れることで対応する等の工夫が必要、と述べていました。

結論としては、DripはTupleSpaceっぽさをバッサリ切り、協調機構から考え直したのがよかった、ということでした。最後に、実際にDripを使って動いているアプリとして、電力消費量のロガー＆レポートがあるよ、という紹介もありました。

松田明さん「たのしいRails」

Railsのコントリビューターであり、Railsプラグインkaminariの作者でもある松田さんの発表です。松田さんの発表と同じ時間の枠に、RubyGems の作者でもあり、Seattle.rbの創始者であるEricさんの発表があるということを説明し、「⁠そちらを観に行かなくて大丈夫か？」との問いから始まりました。

ソーシャルコーディングとは

自分以外の誰かのために開発をしたりもくもくとキーボードを叩くのではなく、コンピュータの向こうにいる人に対する開発者の開発スタイルのことをソーシャルコーディングと呼んでいるそうです。そして、RubyKaigiに来ているようなRubyプログラマーはRubyのコードを使ってコミュニケーションを取れる人たちですよね。今回でRubyKaigiも終わってしまうし、 Rubyを使って新しいコミュニティに入っていこうという呼びかけを行いました。そして、ソーシャルコーディングの力を高めるためにはどうしたら良いかというTipsを紹介しました。

Tips

Read Rails

毎朝、"git log"を読みましょう。毎朝読む新聞のようなもので、フレッシュな情報を得ることができると言います。logを見続けることで、Rails3.2やRails4.0に入る機能等をいち早く知ることができること、誰がどんなコミットをしているかがわかるようになってくると述べました。また、自分が良いコードを書くための良い指標になりますし、コミットコメントの書き方も参考になると述べました。

人々を知る

毎日git logを見ることで、常連のコミッタがどんな人かわかってくると言います。そこで気になる人が見つかったら、 githubやtwitter、blog等を見てどんな人となりなのかを見にいってみることを勧めていました。

良いコミットを知る

数々のコミットを見ることで、どんな単位が良いコミットかがわかるようになってくると言います。例えばテストを絶対に付けるということや、コミットコメントの一行目でどんな修正なのかが伝わるような書き方などが良い参考になるそうです。

English

ソーシャルコーディングを行う人にとっては必須の能力ですが、日本人は英語が苦手です。特に会話が苦手。そんな人には、RailsCastsのサイトを見ると良いかもしれない、と述べていました。動画が見られるので、ヒアリングの助けにもなるそうです。

Railsに貢献する

https://github.com/lifo/docrails/ はドキュメント専用のリポジトリなので、一番、失敗しても影響がありませんので気軽に関わることができるとのこと。すごく単純なスペルミスからでも良いのでコミットしていくと良いと述べました。

モンキーパッチをpullする

何かRails自体の不具合等を踏んでしまった場合、ブログに書いたり、そのRailsアプリのlibディレクトリに書いたままにしてませんか？と問います。そのような場合はfork railsして、pull requestを送ろう、と言います。モンキーパッチでは自分一人しか幸せになりませんが、pullして受け入れられれば、何人もの人が幸せになれると述べました。

会いに行こう

ここまでのことをしていると、きっとRailsにコミットしているメンバー達に興味がわいてくるはずだと言います。そうしたら、ぜひ年に一度開催されるRails Confに参加してみよう、と説きます。今までネットワーク越しでしか知らなかった人と実際に会えるとのこと。

本を書こう

本を書こうとすると、色々調べる必要があがあるし、バグを踏んだりしてハックしたりするので、大変勉強になるそうです。

というようなRailsについての話だったのですが、Rails以外にも有効なコミュニティに関わっていくためのTipsと言えるでしょう。

Eric Hodelさん「Writing Friendly Libraries」

seattle.rbのEric Hodelさんによる発表です。ライブラリを作る際に気をつけるべきことを、作成手順をこと細かに追いながら説明しました。これまでに90以上のgemやライブラリを作ってきた経験から生まれたtipsであるので、ライブラリ開発者の方の参考になる内容でした。

Friendlyなライブラリを書くのに大切にしてほしいこと

一番大切にして欲しいこととして、楽しくやることを挙げました。やはり楽しさを持ってやらないことには続かないことだということはみなさんが強く感じられていることではないでしょうか。

その他にも、以下のtipsを挙げました。

命名規則に従う
ディレクトリ構造を決める
意味のあるバージョン番号をつける
例外を実装する場合にサブクラスを使う
どうしてエラーになったのかエラーメッセージに書く
例外にデータを含めてデバッグしやすくする
振る舞いを定義してすべてをテストする
後方互換性を確保するためにAPIと実装を分離する
内部ドキュメントは書かず、動く例を提示する
フックを提供することで、ユーザがきれいに拡張できる
READMEで説明を載せ、バグトラッカーのURLを掲載する
手動だと間違いが発生するので、自動的にリリース作業を行う

会場からの質問では、リリース時の文書としてニュースとチェンジログのうち、なぜニュースを勧めるのかという問いに対し、ニュースはユーザに向けて重要なことを提供するのに向いており、チェンジログは開発者向けの情報であることを提示しました。拡張のためにC言語でコードを書くよりも、Rubyで書くことを勧める理由を問う質問には、Cのラッパーと高速処理のうち、Ericさんはラッパーを書くことが多いため、ラッパーを書く際にはRubyで書きたいと話しました。

原悠さん「Rubyマスターへの道」

ネットワーク応用通信研究所の原さんが、Rubyマスターになるためにはどうすればよいかということを話しました。

最初に、使用しているプレゼンテーションソフトがHTML5なので、RubyistとしてRubyタグを使って英訳した文を添えているということ紹介しました。

原さんは、プログラミング歴14年、Rubyist歴は9年になります。そんな原さんが、2009年に「Rubyが使いこなせる勉強法を教えてほしい」という質問を投げかけられたそうです。今回の発表は、そんな質問への回答になるそうです。

プログラマ準備編

原さんは、まず「プログラミングにはいろんな分野があることを理解してほしい」と言います。プログラマがかっこよさそうという「あこがれ」から、プログラミングを初めるのはいいことです。しかし、プログラミングできる分野は広いため、そこから自分が何を作りたいかというのを探そうとアドバイスしました。また、初日のAaronさんの発表を取り上げ「日本にはRubyで何かを作るための本がいっぱいあるので参考にするとよい」と述べました。

また、プログラミングマスターには時間がかかるため、途中で休みながらでも継続しつづけていくことが大事だと言及しました。だいたい10年やれば、大概のものは何でも上手くなるので、10年たったころにはプログラミングマスターになれるのではないかということです。

そして、「⁠コンピュータの中では、プログラマにできないことな何もないので、何でもできると思ってプログラミングを初めてほしい」と語ります。何でもできるプログラマなろうとすると、やらなければいけない分野が増えて大変だと言います。しかし、作ろうとしたときの勉強こそが「勉強すればなんでも作れる」という自信となるはずなので、「⁠たくさんプログラムを作りましょう」と言い、準備編を締めました。

プログラマ初級編

プログラミングを初めたら、まず「ライブラリを知る」ことが大事だと言います。Rubyには、組み込みライブラリや標準添付ライブラリのように初めから便利な機能があるライブラリがあります。そしてRubyのメソッドはバージョンアップするたびに便利な機能が導入されるため、定期的にドキュメントなどで見直しをするとよいと言います。また、「⁠プログラミングをして、身近な問題を解決しましょう」とプログラミングをするコツを紹介しました。ちょっとした自動化できたらいいなという処理からはじめるとよいそうです。

プログラマ中級編

中級者になるにはまず「良いコードを書く」ことが大事だと言います。「⁠良いコード」というのは、宗教的なものでなく、圧縮された「良さ」をもつコードのことだそうです。そして、他の言語のようなRubyコードでなく、Rubyらしいコードを書くことも大事だと言います。また、コードの読みやすさも意識するようにしましょうとも述べました。そして、ブログやGitHubなど「アプトプットする」ことが大事だと言います。ブログを書きはじめたときは、反応がないためつまらなく感じることがあります。しかし、検索エンジンごしの「誰か」に向けて書き続ければ、だんだん反応がもらえるようになるそうです。また、ブログを書くためにメモをまとめるので、考えがまとめる必要ができ、自分のためにもなります。ブログやGitHubなどのWebの世界だけでなく、現実の世界でも「発表する」ことが大事だと言及しました。いきなり大きなイベントでの発表は大変なので、小さなイベントから発表していくことがお勧めだそうです。また、自分が作ったものの発表だけでなく、他の人が作ったライブラリなどを勉強したことや、面白いと感じたことでも発表すべきと述べました。

プログラマ上級編

上級者になるには、自分が使っているものの「中を開けてみる」べきとアドバイスしました。今導入しているRubyGemsのソースコードを読んだり、自分でいじってみて動きを理解するとよいとのことです。また、ライブラリのコードだけでなく、Rubyのソースコードも読んでみるべきだとも言います。そして、「⁠Ruby以外の言語を勉強する」ということも、Rubyの勉強になるそうです。Rubyしかしらないというのは、Rubyの特徴がわからないという状況です。多言語を勉強することでRubyの特徴を知ることができると指摘しました。

プログラミングマスター編

プログラミングマスターになるためには、「⁠人と違うことをする」必要があると言います。「⁠人と違うこと」というのは、その道の第一人者になるということになります。マスターになると「やる気の問題」がでてくるそうです。やる気を保つためには、「⁠やる気がでるまで待つ」や「強制的に始める」というやり方の他に、「⁠達成すると嬉しいことが起きる環境を作る」「⁠やらざるを得ない環境を作る」など環境についてアドバイスしました。

プログラミングマスターになったら、どうなる?

最後に、原さんは「プログラミングマスターになってても良いことはない」と述べました。プログラミングの楽しみは、「⁠うごいた!!」という感動です。そのため、「⁠あんなに上手にできたら楽しいだろうな」と思ったり、今目の前のコードを楽しみ、「⁠気づいたら、Rubyマスターになっていた」となるのがよいと話をまとめました。

Richard Huangさん「Use rails_best_practices to refactor your rails codes」

rails_best_practicesというgemを作っている、Richardさんによる発表です。

@ihowerさんの「Rails Best Practices」

Richardさんがrails_best_practicesを作るきっかけとなったのがRails Conf Chilnaでの@ihowerさんによる「Rails Best Praictices」という発表だそうです。とても良い発表だったそうですが、実際にRichardさんがすべてを実践したら、ベストプラクティスの数が多すぎて大変だったそうです。なのでそれらを自動化するために作ったのがrails_best_practicesとのことでした。ただ、自動化するのが難しいプラクティスもあるそうで発表であったプラクティス全部を自動化できているわけではないと話していました。

rails_best_practices gemとは別にrails-bestpractices.comというサイトもあるそうです。このサイトは@ihowerさんのベストプラクティス以外にもたくさんのプラクティスを集めるために作ったサイトとのことで、ユーザがプラクティスを投稿したり、良いと思ったプラクティスに対して投票できるという機能があるとのこと。現時点で70ほどのプラクティスがあり、ベストと言えないものもあるが便利なものがたくさん登録されていることを紹介しました。

デモ

rails_best_practicesを使うためには gem install rails_best_practices でインストールし、rails_best_practicesコマンドを実行すればよいそうです。実行するとターミナルにリファクタリングすべきコードがどのファイルのどの行にあるかが表示されます。この結果はターミナルだけでなくオプションでhtmlなどにも出力可能であることを説明しました。

結果の出力にはリファクタリングすべき内容にしたがってrails-bestpractices.comの対象のプラクティスへのリンクが一緒に出力され、プログラマはそのリンク先に書かれているプラクティスを見てどのようにコードを修正すればよいのか確認できるとのことでした。

Richardさんは実際にその場でrails_best_practices gemを使ってデメテルの法則に違反しているコードを解消するデモを行いました。

rails_best_practicesを使った方がよい理由

rails_best_practices gemを使うと、ベストプラクティスにしたがった美しいコードを書けるようになるとのことです。また、細かい規約や文法などのチェックをrails_best_practices gemで自動的に行うことでプログラマがコードスタイルではなく、本質的なロジックに集中できるようになると述べました。Rubyにはその様なチェックをするツールがたくさんありますがほとんどがRubyのためだけのものでRailsに関する問題はみつけられないと指摘しました。

プラグイン

rails_best_practices gemは解析対象のRubyコードを一度SEXP(S式)に変換し、SEXPに対してプラクティスのチェックを行なっているそうです（SEXPへの変換にはruby_parserを用いているとのこと⁠）⁠。また、rails_best_practices gemはプラクティスのオン・オフも設定できるそうで、設定ファイルを記述することで変更可能と説明しました。

また、自分達でプラグインとしてプロジェクト固有のプラクティスを追加することもできるそうです。実際にRichardさんがRails.rootではなくRAILS_ROOTと書かれているコードを検出するプラグインを実際に作るデモを行ないました。

ライブラリの使い方の話だけでなく、内部の実装にまで踏み込んだ、作者ならではのおもしろい発表でした。

Wen-Tien Changさん「BDD style Unit Testing」

Wen-Tien Changさんの発表です。まず始めに、テストにはUnitTestとCustomerTest（受け入れテスト）の2種類があること。Unittestは正しいコードかどうかの検証のために行うものであり、CustomerTestは顧客の要求にあっているかの確認のために行うテストであることが紹介されました。

RubyのBDDツールとしては以下の2つがあると言います。

RSpec
Minitest/Spec

そしてテストには、以下の4つのフェーズがあると挙げました。

フェーズ1:セットアップ
フェーズ2:実行
フェーズ3:検証
フェーズ4:ティアダウン

この4フェーズがはっきりしないと、どういう順番でテストが実行されているかがわかりにくくなってしまうと述べました。

BDDの第一印象は、文法が仕様書のようで可読性が高いということを挙げました。そもそもBDDはxUnitを改良したもので、振る舞いにフォーカスしているとのことです。BDDからxUnitに変わることで用語も変わります。テストをスペックと呼ぶようになり、assertionをexpectationと呼ぶことを説明しました。

よく使われるツールはRspecとMinitest/Specですが、RSpecが最も高性能だと述べました。Minitest/specはRuby1.9.2から組み込まれていて、よりシンプルかつ高速に動作するそうです。BDDでよく使う要素はRspecのcontextで、一つのテストケースの例でありネストが可能であるとのこと。Minitest/specでは対照的にdescribeしかないけれども、深くネストしたcontextはコードの流れを追うのが難しくなるため危険であると述べました。ここでも4つのフェーズが鍵になると言及しました。

そして、シンタックスの問題を語りました。言語があなたの考え方に影響を与えると言います。test/unitはただ検証を行いますが、specは検証するだけでなく、どんな振る舞いをするかの定義もするため、テストの目的も分かりやすいと紹介しました。メタプログラミングが問題なのでしょうか？　問題になるべき点ではなく、RSpecの高度な文法のせいであると述べました。しかし、Wen-Tien Changさんの意見として、RSpecのDRYな文法が逆にテストを難しくしているということがあると言います。Railsチームでテストをネスト可能にしていないのは、この複雑さを避けたいためだと推測され、RSpecはモックを使いすぎだと感じているそうです。

結論として

最後に、「⁠BDDテストフレームワークは必須ではありませんが、チームの力になるものだと思います」と締めくくりました。

永井秀利さん「ThreadGroupクラスの強化とその利用法」

Ruby九州のメンバーでもある九州工業大学の永井さんによるThreadGroupの機能改善についての発表です。永井さんは、CRubyのコミッターでもあり、Ruby/Tkを主に担当しています。

ThreadGroupとは、組み込みライブラリの一つで、スレッドを管理するクラスになります。生成したThreadがまとめられる単位になり、以下の特徴があることが紹介されました。

生成したスレッドは親と同じThreadGroupに所属する
死んだスレッドはThreadGroupの管理から外れる
スレッドが所属するThreadGroupは動的に変更可能
ThreadGroupオブジェクト間には関係や階層がない

永井さんは、このThreadGroupがあまり活用されていないということに着目し、もっとみんなに使ってもらえるようになるために機能強化を考えられたそうです。永井さんは、ThreadGroupやスレッドの管理には次のような問題点があると指摘しました。

スレッド群を取り扱うための機能不足
スレッドを操作するための権限に関する概念が無い
ある程度コストをかけないと、スレッド群を終了順に処理できない
ある程度コストをかけないと、スレッドが終了したときに即応答ができない

このような問題に対し、4つの強化を試みたそうです。

スレッド（群）の操作性の向上
ThreadGroup間の操作権限の設定
例外終了を含むスレッドの整列化
閉鎖された実行空間の生成

これらの改善を図るのをライブラリでなく、Ruby本体に手を加えたことについて「Ruby本体側で変更を加えないと、実装がそもそも不可能、もしくは無駄なコストがかかるため」と問題を修正する難しさと語りました。

スレッド（群）の操作性の向上として、スレッドを生成する際に所属させたいThreadGroupを指定可能にしたり、ThreadGroupに所属可能なスレッド数を設定・参照できる機能等さまざまな機能を追加したそうです。また、ThreadGroupをThreadGroupで管理できるように、操作権限の概念を追加したことも紹介しました。

例外終了を含むスレッドの整列化として、今回ThreadGroupごと一つのthread queueを持たせ、例外終了を含む終了したスレッドがthread queueにいれることが可能になったと言います。このthread queueを使用すれば、終了したスレッドを順に処理したいというようなことが簡単にできるようになるそうです。

閉鎖された実行空間の生成として、local spaceという機能を説明しました。local spaceを利用するとThreadGroup内に閉じた実行空間を構築でき、ThreadGroup内で有効なメソッドや定数、クラスやモジュールなどを作成できるようになるそうです。

最後に、これらの強化案は実装中であり、議論中のものだと述べました。これらの機能に興味がある方は、ruby-devなどで意見を挙げてほしいと述べました。

諸橋恭介さん「5 years know-how of RSpec driven Rails app. development.」

昨年のRubyKaigiで高橋会長が話した「最後のRubyKaigiで何ができるか考えて欲しい」という言葉から、自分に何ができるかを考えた結果、自分が5年間行なってきたRails開発のノウハウを提供することだと思ったという話から始まった諸橋さんの発表です。なお、諸橋さんは『Rails3レシピブック』の共著者の一人でもあります。

まずは model のテストを書こう

Skinny Controllers Fat Modelsという言葉があるとおり、Controller にロジック記載するのはできるだけ避け、Model に記載することが推奨されています。しかし、モデルのテストを書こうとすると、データの複雑さによっては準備が非常に大変になってしまうと言います。

どのようにテストデータを作るか

そこで、テーブルを利用形態に合わせて3つのカテゴリに分類し、カテゴリ毎に準備しやすいデータの作成方法について紹介しました。

Mastar data
- 直接データの編集を行わないようなテーブル
Resource data
- アプリケーションから直接変更を行うようなテーブル
Event data
- テーブル間の関連があるようなテーブル

これらのカテゴリを元にどのようなツールを使うと、効果的にテストデータを作成できるか、ということを話しました。具体的には、以下のアドバイスがありました。

Master data
- Rails で使われている普通の fixture で良い。読み込み速度も早い。
Resource data
- フレキシブルにデータの作成が行い易い、 fixture repracement を使うと良い。具体的には、Factory Girl や Fabrication がおすすめ。
Event data
- RSpec 等に備わっている before/setup、 block 機能を使ったデータのセットアップが良い。

上記の分類は、テストを実装するための方針としてのたたき台として参考にしてもらい、実際の要件にあうように良い選択をしていけば良いと説明しました。

最後に、テストを実装する際に、重複するコンテキストをシェアしたい場合、shared_contexxtを使用するとすっきり記述ができて、DRYにコーディングが進められるアドバイスしました。

前田修吾さん「JIS X 3017の読み方」

NaClの前田さんからはJIS X 3017、つまりプログラミング言語としてのRubyを日本工業規格として標準化した、その文書の読み方についての発表です。読み方ではなくRubyの標準化プロセス自体に興味のある人は、島根で行われる今年のRuby World Conferenceでそういう内容のセッションがあるのでそちらを期待するように、とのことでした。

JIS X 3017とは

まずJIS X 3017の文書は7000円程度で購入可能だが、日本工業標準調査会のサイトで検索すれば無料で閲覧することもできますと情報ソースを紹介した後、各章について順に説明しました。

最初はJIS X 3017が対象とする範囲の説明で、JIS X 3017は言語の構文と意味、そして処理系とプログラムの要件のみを対象とし、それ以外の「マシンリソースによって決まる制限」「⁠下位のOSに関する制限」などは対象外。また当然ながらRailsのようなアプリケーションについては扱っていないということを述べました。

また、プログラムが規格に適合しているかを説明する言葉として、以下の3つの概念があるそうです。

規格厳密適合プログラム：規格で規定された機能だけを使用して書かれたプログラム
規格適合処理系：規格厳密適合プログラムを規格通りに実行する処理系。拡張機能があってもよい
規格適合プログラム：規格適合処理系で実行できるプログラム

ただし、規格厳密適合プログラムはすごい小さいプログラムでなければこの範疇に入らないとし、世のほとんどの（動作する）Rubyプログラムは規格適合プログラムだろうということでした。

Ruby特有の仕様記述

規格を説明していく中で、Rubyがなぜ改行を特別扱いするのかにも触れました。それはやはり文などの区切りの記号（;のような）を省略して書けるようにしたかったこと、一つの行に押し込まず複数行に分けて書くことも可能にしたかったことを挙げました。また同様に、空白類も特別扱いされていて、メソッド引数の括弧を省略したいという動機から来ているとのこと。これらが規格上の記述にも反映されている、と述べました。

規格の記述が複雑化するのは、Rubyの文法（の仕組み）が複雑であるからですが、なぜこんなに文法が複雑なのかといえば、文法の複雑性がプログラムの簡潔性をもたらすからだそうです。例えばセミコロンや括弧の省略を禁止してすべて書かせるようにすれば、文法は簡潔になるだろうが、それではプログラマに負担を強いる、というわけです。

このように、ぱっと見はシンプルでよく使う機能は自然だったりするが、実は仕様は複雑で特殊なケースでは処理が難しいのがRubyらしさだとしました。また概観してみると型変換など一貫性がない部分も存在してしまっているということでした。

標準化で変わる？

前田さんはRubyがこのように複雑になった理由の一つとして、仕様書が一切なかったため、少しずつ実装を積み重ねていったらこうなってしまった、という点を挙げました。では、「⁠標準化によってRubyは変わるか？」という問いには、これからもRubyは実装ベースで開発が進んでいくのは変わらないだろうと述べ、「⁠まつもとさんは永遠のカウボーイプログラマだ」という言葉で発表を締めくくりました。

Chris Kowalikさん「Efficient JavaScript integration testing with Ruby and V8 engine.」

Chrisさんは現時点でJavaScriptのインテグレーションについて汎用的な解決策がないと話し、Chirsさん自身が作っているHeadless Browserライブラリについて紹介しました。

現在のJavaScriptインテグレーションテストの方法の一つにSeleniumがありますが、Chrisさんは2000ステップもあるようなSeleniumでのテストは時間がかかりすぎるし、GUIを必要とするためCIで実行するのが難しいと話します。

Chirsさんはブラウザテストの方法としてまずはブラウザドライバについて説明しました。先程のSeleniumをはじめ、WatirやPhantomなどを紹介し、PhantomはHeadless Browserだと思っている人が多いけど、WebKitラッパーで実はそうではないことを指摘しました。これらのブラウザドライバの問題は実行速度が遅すぎることだそうです。

他の方法でJavaのライブラリのHTMLUnitを挙げました。Chirsさんのオススメのライブラリだそうですが、設定が面倒だとも話していました。他にもNode.jsのZombie.jsを挙げましたが、こちらも互換性などについて問題があるそうです。最後にEnv.jsを挙げましたが、Rubyistとして面倒な部分が多いとし、ベストなライブラリが存在しないとのことでした。

Chrisさんはこの状況に我慢できずに自分でライブラリを作りはじめたそうです。いくつか目指すゴールをあげ、JavaScriptの対応や使いやすいAPI設計であること、特に実行速度が速いことを強調していました。

プランの一つとしてRubyでV8を使うことにしたとし、RubyからV8を扱うためにmustangというライブラリを使っているとのことでした。mustangはrubyraceというライブラリの書き直しだそうで、ネイティブのV8よりは遅いけれども、rubyraceよりははやくなっているそうです。

ChrisさんによるとV8がよい理由として以下の面を挙げました。

スクラッチで設計・開発されている
パフォーマンス重視である
オープンソースである

この他にも、世代GCやHidden Classes、インラインキャッシュなどにも言及し、V8がとても良いものであるということをアピールしていました。

Chrisさんが作ったライブラリはHTMLUnitや、WebKitl、Zombie.jsに影響を受けており、現在は複数のwindowやframeのサポート、クリックやフォーム入力などが実装されているとのことでした。今後の課題として、ブラウザ互換のJavaScriptレイヤやWebSockets、Ruby Extentionなどに対応したいそうです。

最後に「I want your brains!」と会場のRubyistに開発の協力をお願いしていました。ライブラリは http://github.com/nu7hatch/mike で公開しているとのことです。

Thomas E Eneboさん、大場光一郎さん「Java in Ruby:Scripting Java in JRuby」

「普段仕方なくJavaを使っている人も、JRubyで楽しく開発しよう」ということで、Thomas E Eneboさんと大場光一郎さんによる英語・日本語の2ヶ国語でのJRuby布教セッションでした。

2ヶ国語と言っても同内容を英語と日本語で説明するのではなく、2人が別々のことを喋る発表になりますと説明し、「⁠これはRubyのカオスな状況を表しているんだ」とジョーク風の前置きをしていました。

なぜJavaを利用するのか

JRubyを使ってJavaをRuby風に使っていくことを、Javaスクリプティングと呼ぶそうです。なぜそうまでしてJavaを利用するかの理由として、Javaだけにあるライブラリ（例：Hadoop、Lucene、NASA Worldwide）がたくさんあること、同一VM上でのPolyglot（多言語）な開発はJavaではScala、Clojure、Groovyと当たり前であることなどを挙げました。

また、Javaスクリプティングは、RubyでいうところのCで拡張ライブラリを書くのに似ているそうです。しかしながら、JavaはCよりもRubyに近いとし、例えばどちらもVM層があるからPortabilityがあったり、GCがあることも共通している、といった点で親しみのある言語であることを強調しました。さらに、JavaスクリプティングではJavaインターフェースやJavaクラスをRubyのやり方のままで実装したり継承したりするが、C拡張の方ではCのコールバックを使用する必要があるなど、使い心地にアドバンテージがあることも指摘しました。

ただし、Javaスクリプティングをしてしまうと、コードがJRuby以外のRuby実装に持っていくことができなくなる、といった注意点にも触れました。

Rubyで利用

実際のやり方に入っていくためのスクリプト例としてbubblemarkベンチマークをJRubyで実装したものを用意し、実際に動かしたデモも行いました。これはArdor3DというJavaの描画ライブラリを利用して動かしているが、Javaコードを一切書かずRubyを書くだけで作れたとのことでした。ハードウェアアクセラレータも効いて、ぬるぬる動いていたのが印象的でした。

まず、RubyでJavaのサポートを開始するには最初にrequire 'java' が必要で、Javaライブラリの読み込みにはrequire 'lib/ardor3d-ui-0.8-SNAPSHOT.jar'のようにjarファイルを指定するようでした。驚きのポイントとして、Javaのメソッド名は普通キャメルケースで作られているのに、JRubyでJavaメソッドを呼び出す際はRuby風のアンダースコアで繋いだスネークケースで呼び出せるように自動変換されるとのこと。記述法だけでなく、getWidthのようなgetterメソッドもシンプルにwidthのみになったりするようです。

データ型についても、JavaにあるものがRubyで対応するものへ自動型変換してくれます。明示的に型を変えたい時は、to_javaメソッドを使って指定することもできるそうです。

Rubyで実装

JRubyならば、Javaコードを利用するだけでなく、Javaにある要素をRubyで実装することもできます。例えばJavaのインターフェースはincludeで持ってきて実装できると言います。また、イベントハンドラはクロージャのおかげでブロックを使っていい感じに書ける、と紹介しました。

そして「これが最も重要なフィーチャ」だとして、既存のJavaのクラスにRubyのメソッドを追加する方法も披露しました。普通にRubyでやる時と同じようにJavaのクラスを再オープンしてそこにメソッドを書いてしまえば追加でき、サンプルとしてjava::util::ArrayList#<<を実装した例を紹介しました。

もっとJavaを

その他のトピックとして、先述のArdor3Dに対してDSLの層を構築するThreepenceというライブラリを作ったことを宣伝しました。Javaは言語内DSLが苦手だけどRubyなら得意だから、Javaの機能を使いつつDSLなライブラリが作れてしまう。RubyとJavaの良いパートナーシップの実例とも言えるライブラリであると言及しました。

そして最後に、Javaに既にライブラリがあるのならそれを使いましょう、車輪の再開発はやめましょうと述べ、JavaのAPIをRubyのAPIのように飾りましょう、と提案しました。Javaの世界もRubyistにとって簡単に手を伸ばせる範囲にあるものなんだ、と気づかせてくれる発表だったのではないでしょうか。

Yehuda Katzさん「Advancing Net::HTTP」

Strobe, Inc.に勤めるYehuda KatzさんによるYehudaさんの拡張しているNet2::HTTPについての発表です。Yehudaさんはwycatsというハンドルネームで、Rails3リリース時に活躍されていました。

Net::HTTPについて

Yehudaさんは、Rubyには100近くのHTTPライブラリがあると言います。しかし、どのライブラリもNet::HTTPほど強力なものはないそうです。パフォーマンスもRubyで書かれているが十分で、Rubyで書かれているのでわかりやすいのがよいと述べます。

次にYehudaさんは、Net::HTTPのAPIについて紹介しました。Net::HTTPのAPIはブロックがたくさんでてくるため、煩雑に感じる人が多いです。しかし、ブロックの一つ一つがHTTPのリソースの取得・開放というふうに捉えると意味が理解できると説明しました。

Net2::HTTPの作成

では、なぜYehudaさんは、自身がよくできていると感じているNet::HTTPの改良を試みているのでしょうか?

それは、 Yehudaさんは、Rackでリクエストとレスポンスが別々のスレッドで処理する必要があったそうです。そのとき、Net::HTTPのtransport_requestでリクエストがブロックされ思うようにいかなかったと言います。そこで、Net::HTTPの改良に手をだすようになったとのこと。また、Net::HTTPに対してパッチをあてる方法でなく、大きな改良をしたくなったため、フォークしNet2::HTTPを作るという手段に出たと話します。

リクエストの並列処理

Yehudaさんは、リクエストを並列に処理するためのキーワードとして、"Async"を挙げました。Fileのreadを例に挙げ、Rubyレベルで並列に処理するためのテクニックを説明しました。

まずは、Threadを使うやり方です。IOを発行する箇所をThreadで処理をさせることで、メインのThreadではIOのブロックが発生しないというものです。次にThread一つで並列に処理する方法を説明しました。Thread一つで処理する場合には、IO.selectを使うようです。IO.selectとIO#read_nonblockを使用することで非同期に処理が進められると言います。

このIO.selectの仕組みを使い、もっと汎用的なIOを非同期に扱うための仕組みとしてNet2::Reactorを作成したそうです。これにより、Net::HTTPがSocketやFileと同じような取り扱いが可能になります。Yehudaさんは、Net::HTTPのようなハイレベルな概念を持つライブラリもIOのように取り扱うことができたら、Net::FTPなどもNet2::Reactorで取り扱うことが可能だと述べます。また、このNet2::HTTPをRuby本体に取り込んで欲しいと、提案をしました。

高尾宏治さん「MacRuby on Rails～MacRubyから見たcRuby～」

cRubyのコミッタであり、今年の3月にMacRubyのコミッタにもなった高尾さんの発表です。

MacRubyとは

まず、MacRubyとは一体どんなものか、という説明から始まりました。 Ruby1.9とObjective-Cを融合させたもので、現在のMacRubyプロジェクトの目標は、Ruby1.9との100％互換を目指している、と説明しました。

そもそも MacRubyとはcRubyとまったく別物というわけではなく、cRubyとMacRubyは基本的なコードベースは同じものを使われています。違いはRubyVMの代わりにLLVMを、GCをAutoZone、組み込みライブラリ部分にFoundationと呼ばれる機能を追加をした実装のことだそうです。 MacRubyはMac OSX上でのGUIプログラミングに関しては実用的には問題ないレベルになっているとのことで、XCodeを使ってソースコードとGUIのアプリケーションを作ることが可能だと述べました。

MacRuby on Rails

2011年3月ころにふと思い立って、MacRubyでRails3が動くのかを試してみたところ、なんとかRailsのインストールができたそうです。しかし、実際に動かそうとするとエラーが発生したり、SEGVが発生していたと振り返ります。そこから原因の調査を初めたことがきっかけてで、MacRubyのコミッタになることができたと話します。現在では MacRuby上でだいぶRailsが動きそうなところまでなってきているそうで、Railsが無事に動くようになることを機に MacRuby 1.0のリリースを行おうという話になっていると述べました。

また、MacRubyのコードを読む必要で必要な技術要素として、以下の理解が必要だと話していました。

cRuby
Objective-C
C++
LLVM

角谷信太郎さん「The Gate」

諸事情により来られなくなったDave Thomasさんに代わり、角谷さんがRubyコミュニティに向けて今後10年間の宿題を伝えたい、という発表になりました。

自己紹介

角谷さんはAsakusa.rbという地域Rubyist集団に所属しており、RubyKaigi2011のプラチナスポンサーでもある永和システムマネジメントで働いています。これまでのRubyKaigiの実行委員の経験やまつもとさんなどの会話を経て、最近は自身のことをRuby Evangelistだと思ってもいいのではないかと思っているがどうだろう、と述べていました。

Dave Thomasと私

本当ならばDave Thomasさんに基調講演をしてもらう枠だったのですが、諸事情によりキャンセルされてしまったので、代わりに話したいということが伝えられました。Dave Thomasさんを知らない方のために、まずDave Thomasさんについて紹介しました。

Dave Thomasさんは1999年に頭角を表したと言います。この年はAndrew Huntさんと『達人プログラマー』を書かれた年です。この達人プログラマーを自社の新入社員に買い与えられことという話です。この本を今読み直してみると、10年以上前に書かれた本でありながら未だに示唆に富む本であることに驚かれたとのことです。

2000年にはRubyについての本を出版されたり、『⁠アジャイルソフトウェア開発宣言』を出した一員となり、アジャイル開発のスタート地点に立たれたと言います。2003年には、Pragmatic Bookshelfというプログラマ向けの書店を作ったことに触れ、今ではビジネス的に大きくかつつプログラマからの信頼を得る存在となったと紹介しました。2005年にPragmatic Bookshelfから『RailsによるアジャイルWebアプリ開発』という本を出版しました。

そして、こういった本の邦訳を読んでいるうちに、2007年頃、角谷さんは日本の方に良い技術書を届けたい、まともな日本語で技術を伝える活動がしたいと思われたそうです。そしているうちに、監訳の仕事をするようになったと言います。最近では『アジャイルサムライ』を監訳したことを紹介しました。

RubyKaigiと私

角谷さんの中で、RubyKaigi2007はやりきった感じがしたと言います。特にDave Thomasさんに来ていただいたのは非常によい点だったと語ります。当時はRailsがこれから日本で広がるかどうかという状況でした。そのような状況でDave Thomasさんは、これからRubyやRailsの世界に入ってくる人が多く出てくるだろうと指摘し、「⁠これまでの自分たちのやり方を大事にしながら、新しく来た人たちから学んでいこう。今や孤島（Island of Ruby）は存在しない。新しくくる人たちをHappyに迎え入れる準備をしよう」と宿題を投げかけていったと振り返ります。

さらに2007年当時、角谷さんは仕事でRubyを使える状況にはなかったそうです。昼間はJavaを書き、夜にしかRubyを書けなかったときに、Railsだと素早くWebアプリケーションを作れると知ったと言います。そして、これを仕事でRubyを使うためのチャンスにしたい、Rubyの孤島へ行くために橋を架けたいと思うようになったそうです。さらに、JavaからRubyへどのような戦略を持ってシフトしていくかという視点に立つようになったことを話しました。

コミュニティの一員になる

Railsには、すごいたくさんの人が乗っている感じがすると言います。しかしそこで誰と仕事をやるかということが非常に大事であると話します。

Asakusa.rbやRails勉強会@東京での会場提供しコミュニティをホストするといろんな人がきてくれるのでいろんな人とコミュニケーションしやすくなっていると言います。そして、RubyやRailsに興味を持つ人たちとどう関わっていけるかということをよく考えているとのことでした。また、自社内というコミュニティでは楽しく仕事をするということが大事だとし、githubを使うことでコードレビューをしやすくしたり、楽しくしたり、楽しくて仕方ないという状態にすることが一番の目的だと言います。楽しんでる人たちがいるコミュニティの一員になるということが、一番大事だと思っていることと語りました。

また、楽しいということをみんなに見せていく場としてRubyKaigiは大事だと思われていると言います。楽しいということは、人間として根源的なことであり、楽しいからこそ世界中からみんなが練馬やつくばという場所にも集結するイベントになると語ります。しかし、この楽しさというものは、なかなか伝えることが難しいものだと述べました。

Dave Thomasさんからの宿題

アメリカではRubyのエコシステムが確立されているが、日本ではまだ確立されていないと言います。そのため、これから述べる宿題は少し早いように思えるけれども是非紹介したいと、以下の3つの問題を紹介しました。

1.Inspire someone：似たような仲間以外にも影響を与える活動をしてほしい。Sarah Allenさんの"Find someone to inspire who's not like you"という言葉を紹介しました。
2.Diversify：多様性を持たせなさい。これは自分自身に言えることです。Dave Thomasさんの"毎年一つの言語を学びなさい"という言葉で説明されました。日本ではLL文化があり、妙に言語に興味感心が高いので心配はないと思っていることも述べていました。
3.Get out of the Rut：Railから降りるということ。前の人が走った轍から抜けてみること。"Ruby is *in danger of becoming* a Suburb" Ruby界隈でも何を作っても新しいという世界ではなくなってしまったそうです。

これら3つの宿題を楽しんでやること。それがDave Thomasさんからの宿題です。たのしいRubyということを僕等はどう続けていくかが大事だと語りました。

赤井駿平さん「Method Shelters :ClassboxesでもRefinementsでもない別のやり方」

赤井さんはまずはRubyのオープンクラスの説明として、既にあるクラスなどに対してメソッドを追加したり、既に存在するメソッドなどを上書きすることができると話しました。オープンクラスの例として、openメソッドを上書きするopen-uriや、Stringなどにメソッドを追加するRuby on RailsのActiveSupport、プログラマ自身によるモンキーパッチを挙げました。

オープンクラスは便利である一方、メソッドの衝突などの問題があると言います。例えば、複数のライブラリが同名のメソッドを追加する場合、後から読み込まれたライブラリで上書きされてしまい、上手く動作しないと説明しました。赤井さん自身の経験として、Railsとflvtoolというライブラリが両方ともStringにメソッドを追加するため問題が起きてしまい無理矢理解決したという話を挙げていました。

このような問題を解決するためにClassBoxやRefinementsなどが既に提案されていますが、赤井さんはLocal Rebindingが欲しいということで新しくMethod Sheltersを提案したそうです。Method SheltersはClassBoxと似ていて、メソッドに対してスコープを与える仕組みになっているそうです。Methodの単語があるように、クラスなどの定数や、インスタンス変数については取り扱わないとのことでした。

内部の実装の話として、Exposed ChamberとHidden Chamber、Global Methodを紹介しました。Exposed ChamberにはパブリックなAPIを記述するそうで、これだけだとClassBoxと変わらず、Hidden Chamberにはそのモジュールの中で使うAPIを記述するとのこと。

いくつかの図を用いて内部の実装について説明されたあと、パフォーマンスについても言及しました。メソッドを探しにいくルートが増える分やはりパフォーマンスは落ちるらしく、rails3のプロダクション環境では4％ほど低下するとのことでした。例外としてtDiaryをあげ、はかったベンチマークのうち唯一パフォーマンスが向上したそうです。

話のテーマ上、CRubyコミッタの参加が多く、頻繁にIRCで様々な突っ込みが入る発表でした。

小崎資広さん「CRubyのロックデザインの解説および改善案について」

2日目小ホール最後の発表は、LinuxのコミッタでありRubyのコミッタでもある、小崎さんの発表です。小崎さんは、RubyではスレッドとかIOとか、OS依存になりそうな箇所に関わっています。

今回話してくれたGVMというのは、GlovalVMロックのことです。ロックが必要な処理をVMで一つのロックを使用し保護することにより、簡単にマルチスレッドでの資源保護ができる手法です。多くの資源を同一のロックで保護するため、CPUが複数ある環境では競合が多くなり、スケールしないというのが、GVMを利用したときの問題点です。この問題点について、小崎さんは「OSのスケジューラーを持つ悩みと似ている」と語ります。

RubyのGVMの実装は、ロックを保持して続け、waitする可能性のあるシステムコールを実行したときにロックを話すという実装になっていました。これでは、あるスレッドがずっとロックを保持してしまい、動かないスレッドが存在するようになってしまいます。そこで、Ruby1.9.2からはTimerThreadというのが導入され、このTimerThreadが10msに一回、動作しているスレッドに対してロックの解放要求を出し、スレッドはロックを解放することにしたと言います。しかし、今主流となりつつあるマルチコアのアーキテクチャと相性が悪いそうです。CPUとメモリの距離により、TimerTheradを使った方法がうまくいかないことがあり、ロックを解放したスレッドが他のスレッドのロック獲得前にロックを獲得してしまうことがあると述べました。

この問題を解決するために、同じスレッドがGVLを連続して獲得しないような実装を試みたそうです。Pythonでは、このような実装が行なわれているとのこと。Rubyでこの実装をし、実験をしたところ、小さいIOをたくさん発行するようなケースでは、GVLを獲得・解放するコストが多くなり、性能が落ちてしまったと述べていました。

Linuxスケジューラは最小走行時間を保証するようにしている(一定時間走らないと解放しない)ため、Ruby1.9.3ではロックを解放する契機に取得・解放方法を変更したことを紹介しました。

IO等のシステムコールによるロック解放
- 1.9.2と同様の取得・解放方法。
TimerThread経由によるロック解放
- 同じスレッドが長時間動いていると判断された場合、強制的にロックを解放させ、他のスレッドがロックを獲得するまでスリープする。

この実装でも、特定ロック手法では最大速度が2倍落ちることがあったと言います。これは、コードが増えると遅くなるという現象が表われたと考えられるそうです。しかし、vm_thread_mutext3というロックを使用したケースでは、1.9.2で3000秒以上かかっていた処理が4.4秒で完了するようになったと補足しました。

最後に、小崎さんは覚えて帰ってほしいこととして、「⁠GVLとイマドキのCPUでは相性が悪い」「⁠使っている人が気持ちよくRubyを書けるように、コミッターは一生懸命がんばっています」と述べました。

Lightning Talks 1

今年は2日に分けてライトニングトークが行なわれます。まず、本日のタイマー係とドラム娘が紹介されました。

ruby trunk changes 統計版、近永智之 (Yokohama.rb)

最近、CRubyコミッタになった近永さんは、この1年のRuby trunkへのコミットを100人の村だったらと仮定した話を展開しました。100人のうち、22人がバグ修正、11人が新機能の開発、20人がリファクタリングになると言うことで、半分がRubyの主な開発になるとのことでした。

RubyでつくるOS 、吉原陽香 (東京農工大学工学府情報工学専攻並木研究室)

現在、クリアコードでバイトしている吉原さんは大学の研究室で、PerlOSを作っている人がいて、Rubyでも作れるんじゃないかと思ったそうです。実際にその場でデモを行い、動作することを見せました。

Connecting Japanese Rubyists with the World 、 Paul McMahon (Tokyo Rubyist Meetup)

Tokyo Rubyist Meetupを主催するPaulさんは今までに日本人と海外のRubyistの間に溝を感じたことがあるそうです。まずはTryすることが重要だとし、わざわざ日本に来てる海外のプログラマは日本人と話したがってるから気軽に話してください、海外のプログラマも日本人はシャイだから話しかけてあげてくださいと発表しました。

るりまを便利に使う方法、ヽ（´・肉・｀）ノ (Ruby札幌)

るりまを便利に使う方法として、るりまは検索してもまだ古いマニュアルがヒットするのでまずはブックマークに登録しようと話し、他にるりまサーチや、Emacs用に自分で作ったanything-rurima-suggest.elを紹介しました。

James: An electronic butler that you can talk to. , Florian Hanke (Melbourne University)

コンピュータと会話することができるJamesというプログラムについて発表しました。実際にその場でデモを行い、最初はうまくいかず会場の笑いを誘いましたが、うまく動作すると流暢に話すJamesに会場は驚きで埋め尽されました。

別の "ASP.NET MVC 3 vs. Ruby on Rails 3" 、こんどうようへい ( http://phosphor-escence.blogspot.com/ )

ASP.NETのフレームワーク、MVC3とRuby on Rails3の比較について話しました。お互いにMVCフレームワークで、jQueryやCoC、RESTfullな点が共通しているとのことでした。違う点としてRazorというテンプレートエンジンがMVC3にはあり、Rails3の競合とも言えるフレームワークだということでした。

rubykaigi.orgを支える技術、関口亮一 (株式会社ディー・エヌ・エー)

Rails3のアプリケーションとしてrubykaigi.orgを紹介しました。rubykaigi.orgはgithubでコードが公開されており、Ralis3のアプリケーションとして非常に参考になるとのことです。rubykaigi.orgを支える人達を紹介し、最後にrubykaigi.orgを支えるのはRubyist力だと締め括りました。

Rios Proxy - コマンドラインインタフェースのためのプロキシフレームワーク、小山田昌史 (株式会社クリアコード / 筑波大学)

小山田さんは最近CLI(Command Line Interface)にはまっているそうです。CLIのプログラムは入力・出力ともにテストが難しいとのことで、riosという自作のCLIの入力・出力をフックするライブラリを紹介しました。

A Hayabusa-speed talk about living under the MacRuby rainbow 、 Eloy Duran & Vincent Isambart (MacRuby core contributors and procrastinators.)

Interactive MacRubyというirbをMacRubyで書き直したものについて紹介しました。MacRubyを使うことでCocoaと相性のいいirbを作ることができるとし、実際にInteractive MacRubyを通してGUIのプログラムを動作させるデモを行いました。

erbをすごく偲んで、関将俊 (druby.org)

「カスタマイズは仕様の議論から逃避する」と話す関さんは、erbのtrim_modeというオプションを軸に仕様の議論を行なわず、安易な対策に逃げてしまったエピソードを話しました。よいデフォルトをしめせないのは開発者の怠慢として、OSSでの仕様の議論は確かに面倒だがきちんと議論すべきと結論づけました。最後の余った時間は関さん著作のdRuby本の表示を映しつづけていました。

The Limited Red Society 、 Joseph Wilk (Songkick.com)

Josephさんは、TDDでテストが落ちている間をScrumなどの看板にたとえ、テストが赤い間はWorking In Progressと同じだと話します。WIPを減らすためにはパフォーマンスのビジュアライズが足りないとし、 http://limited-red.com を紹介しました。

懇親会

懇親会は、池袋のサンシャイン60にある「サンシャインクルーズ・クルーズ」に場所を移して催されました。まともとゆきひろさんによる乾杯のあいさつの後、400人もの懇親会参加者の皆さんが歓談を楽しんでいました。

2日目!RubyKaigi

2日目からは、アンカンファレンス形式の!RubyKaigiが催されていました。

2日目サイン会

お昼休みを利用して『Rails3レシピブック 190の技』（⁠ソフトバンククリエイティブ)の著者、高橋征義さん, 松田明さん, 諸橋恭介さんによるサイン会が行われました。なお、本書は2日目時点でジュンク堂書店RubyKaigi店にて200冊以上を販売したということです。

また、休憩時間を利用して『ウェブオペレーション』（⁠オライリー・ジャパン) の訳者である角征典さん、18章の執筆者である濱崎健吾さんによるサイン会が行われました。

2日目のレポートは以上になります。