Ruby会議2010 1日目レポート［更新終了］

本日8月27日(金)から29日(日）までの3日間にわたり、茨城県つくば市のつくば国際会議場にて日本Ruby会議2010が開催されます。本ページでは、1日目の模様を随時レポートしていきます。

会場入り口から受付場所まで動画で撮影しました。今回は2Fで受付が行われます。その隣のスペースには、ジュンク堂RubyKaigi店が出店しています。

ニコニコ動画：https://www.nicovideo.jp/watch/sm11896723

RubyKaigi開催前にはコミッター関係者が集まり、Ruby開発者会議が行われました。今後のRubyについて議論が交わされていました。

なお、スタッフは、以下の本イベント用のTシャツを着用しています。困ったことがあれば話しかけてみましょう。気さくに答えてくれるはずです。

オープニング

実行委員長の高橋征義さんから、今回のRubyKaigiのテーマ「Conflicts and Resolutions（衝突と解決⁠）⁠」について説明が行われました。その後、スポンサーが紹介され、最後に「イベントを楽しんでほしい」と参加者全員に呼びかけました。

Akira Matsudaさん Masayoshi Takahashiさん Matzさん Yehuda Katzさん tenderloveさん Leonald Chinさん「Conflicts and Resolutions in Ruby and Rails」

本来Jeremyさんによる基調講演の予定でしたが、急遽予定を変更しての講演となりました。実は今回のRubyKaigi2010のテーマはJeremyさんのRubyWorld Conferenceでの講演にちなんでいます。その時の講演の内容は「Rails3をどのように作っているか」「⁠RubyとRailsのコミュニティでもっと仲良くしよう」という話で、それに感銘を受けたので基調講演に招待することになったそうです。

明日28日にはRubyコミッタQ&AやMatzさんの基調講演などRubyの話が中心になることが予想されたので、Railsのことを中心に話すと冒頭で説明がありました。会期中はRailsのコアチームのメンバーが何人か訪れており、その中からYahuda Katzさんとtenderloveさんにお願いして登壇していただくことになりました。

他にも日本のRailsエンジニアの第一人者のMatsudaさんにも登壇してもらい、日本Rubyの会会長のTakahashiさん、Ruby生みの親のMatzさん、Leonald Chinさんと豪華な顔ぶれとなるセッションになりました。MatsudaさんがYahuda Katzさんとtenderloveさんに質問をし、Takahashiさんが司会、MatzさんとLeonald Chinさんが翻訳というQ&Aにも似た形で進行しました。

Rails3について

Rails3.0がリリース間近と言うこともあり、話題の多くはRails3.0についてでした。Railsチームは互換性を気にしており、Rails3では古いAPIも新しいAPIも両方使える「Rails2の上位互換」にあたると説明されていました。また、ActionMailerやActionControllerなど、多くのコアの部分が書き換えられRailsから独立して使えるようになったとのことです。しかし、ActiveRecordやActiveRelationについてはまだ満足できてはいないそうです。とは言え、現在作業中とのことなので今後に期待できそうです。

RailsがMerbと統合すると発表した当時目指していたものと、現在を比較した点については「よくやれてたと思う、期待通りだった」と頼もしい発言をされていました。

Rails3とRuby1.9

Rails3ではRuby1.8とRuby1.9をサポートしていますが、1.9をサポートする上で良いところと悪いところは?の質問に対し、「⁠1.9は1.8と両方で動くコードがかける」と述べ、「⁠Python3と違って」などとジョークも交え、会場は笑いに包まれました。しかし、たくさんのメソッドが文字列ではなくシンボルを返すことを例とし「内容は正しいが、このような大きな変更はもっと慎重に行ってほしかった」とも言っていました。

Ruby1.9の文字エンコーディングについても言及し、悪いところを「文字エンコーディングに考える必要ができた」と述べ、良いところについては「正しく文字エンコーディング」ができると述べていました。Yahuda Katzさんは控えめに話していましたが、tenderloveさんによるとRuby1.9サポートで文字エンコーディングまわりはとても大変な作業だったようです。

継続的インテグレーション

Ruby1.9に関する質問の回答の中で継続的インテグレーションについても言及され、RailsではリポジトリのTrunkに対していつもテストを行っているそうです。その結果、Ruby1.9と近い時期にRails3もリリースできるし、Rails、Ruby共にたくさんのバグを見つけることができたそうです。

熱意があればコミッタになれる

tenderloveさんはRubyのコミッタでもあり、Railsのコミッタでもあるという特殊な立場の方ですが、コミッタになった経緯については「たくさんのパッチを送ったらメンテナがコミット権をくれた」と話をしていました。横にいたYahuda Katzさんは「Railsチームは何ヶ月か継続的にパッチを送っていればコミット権を与える」とも言っていました。また、テストがないパッチは採用されにくいとも話し、改めてRailsチームのテストへの意識の高さが伺えます。

RubyチームとRailsチームの良いところ悪いところ

tenderloveさんはRubyチームとRailsチームを比較して、Rubyはコードの責任範囲が狹い傾向にあるとのことでした。例えば、GC.cをtenderloveさんが書き換えることは難しいが、Railsでは自分が書きたいところを書けるそうです。

また、Rubyには日本語と英語のMLがそれぞれ存在することにも言及し、これらがコミニュケーションを阻害していることを心配していました。お互いに言語を学び、自信がなくとも積極的にコミニュケートすることが大事だそうです。tenderloveさんは日本語を少し話すことができ、横にいるYahuda Katzさんに対し「日本語ならったほうがいいです」と片言ながら日本語で話しかけ会場の笑いを誘っていました。

最後に

「最後にいい残したことは?」と聞かれ、Yahuda Katzさんは改めてRuby1.9の後方互換性の素晴しさを強調し、Ruby1.9.3やRuby2.0でも互換性を大事にして欲しいと話されていました。tenderloveさんはアメリカの開発陣にとって言語の違いが最大の壁とし、お互いの言語を学び、積極的にコミニュケートをすれば、お互いにたくさんのことを学べると話されていました。

Shin-ichiro OGAWAさん「jpmobile on Rails 3 の作り方」

大ホール最初の講演は、携帯サイト開発ライブラリjpmobileのメインコミッタの一人であるShin-ichiro OGAWAさんによるお話です。

日本の携帯電話というのは、絵文字やHTMLエンコーディングに特徴があり、"デコメ"やワンセグ、おサイフケータイと他国に比べ独特です。たとえば、絵文字は各キャリアで同じものを表わすのに絵文字でも違う絵になっていたり、Encoding、code pointも違います。また、HTML Encodingも各キャリアで違っており、文字エンコーディングが違っています。

jpmobileはそのような独特な実装のされている日本の携帯電話の絵文字やHTMLエンコーディングに対する各キャリアの違いを吸収するライブラリです。最初は、えにしテックの@darashiさんがRailsライブラリとして作成しました。

jpmobileの機能としては、主に以下のような機能があります。

文字コード変換
- 自動的にキャリアに対応したエンコードで応答します。
- キャリアから送信されたデータを変換して保存します。
絵文字の相互変換
- 絵文字のエンコーディングを変換し保存して、他キャリアに送信する際も意味の伝わる絵文字にして返します。
- 絵文字をviewに数値として書くこともできます。
セッションマネジメント
- 携帯の一部はクッキーの保存ができないため、セッションidをPOST/GETのパラメーターに自動的に追加してセッション管理ができるようにします。
viewの切り替え
- 一つのアクションで複数のviewを返せるようにします。携帯の各キャリアだけじゃなくて、PCとの切りわけすることができます。
link helper
- GPS情報をとるようなlinkを記述する際に、各キャリアに対応したリンクを生成してくれます。

jpmobile on Rails 3.0での特徴が詳細が語られました。

一部の機能のRack Middleware化
- ユーザーエージェントからどのキャリアから判別する機能であるMobileCarrier
- パラメーターのエンコード変換を行なう ParamsfFlter&Filter
スマートフォンに対応するための Smart Phone classesが作成されました。
メソッドの移動 to_internalやto_extternalというエンコード変換のメソッド移動し、他の人がオーバーライドすることで独自の対応ができるようになりました。
Ruby1.9.2対応

jpmobileの開発は、railsのメソッドをフックし独自の処理を追加することで機能が実現されています。そのような実装方法を実現するには、Railsのコードをひたすら読んで、メソッドのフックポイントを見つけることだと言います。このを自身の経験をもとにして紹介されていました。railsのメソッドは、メタプログラミングが多用されていたり、大量のメソッド呼出しが行われており、ひとつのメソッドを追いかけるだけでも大変です。

今後jpmobieの機能として、絵文字つきメール送信や、デコメ対応したいとの発言されていました。

また、OGAWAさん主催のjpmobile Kaigi2010 が明日9:30より企画部屋で行なわれます。

Masaki Yamadaさん「Ruby on Railsではじめる携帯電話向けオープンソーシャルアプリケーション開発」

Masaki Yamadaさんによる、オープンソーシャルアプリをRuby on Railsで開発したときの経験談です。

オープンソーシャルとは、SNSのプラットーム独自のデータを外部アプリが利用することのできる仕組みです。オープンソーシャルのアプリとしては、PC版とモバイル版があり、それぞれ以下のような違いがあるそうです。

PC版の特徴
- ユーザーがアプリのサーバーと直接通信する
- ユーザー認証はセッション管理の必要がある
- クライアントサイドはHTML+javascriptで作成する
- サーバ負荷は小さい
mobile版の特徴
- ユーザは直接アプリサーバに接続しない
- クエリパラメータでユーザを特定
- OAuthで常にユーザー認証を行なう
- クライアントサイトHTMLのみで記述する
- APIの実行はサーバ間で行なうためレスポンスが遅くなる
- サーバ負荷が高い

そのため「モバイル版のほうがPCより簡単」とMasaki Yamadaさんは言います。

また、携帯のオープンソーシャルゲームについて、「⁠UIが不親切なCMSと考えられる」と言います。Railsを使用したほうが簡単であり、携帯でもjpmobileが利用するため、「⁠オープンソーシャル開発はRuby on Rails で、いますぐ簡単にできる」と述べ、Rubyを利用すべきと話されていました。

そのほか、オープンソーシャルのアプリをRuby on Railsで作成した際に、自身で作成されたオープンソーシャルアプリのライブラリが紹介されました。作成されたライブラリはmasarakki's Profile - GitHubにて公開されています。

質疑応答で「オープンソーシャルアプリを開発して面白いことは?」という質問に対し、「⁠ユーザーの反応が大きくて楽しい」と、オープンソーシャルアプリ開発の魅力を語ってくれました。

Sarah Meiさん「Feels Like Ruby」

「皆さん、こんにちは。名前はメイ・サラです」「⁠サンフランシスコに住んでいます」と日本語で自己紹介をされていたSarah Meiさんは、Pivotal Trackerを作成しているPivotal Labsに勤めています。

「JavaScriptを本当の言語にするには」というテーマでお話されました。サラさんは、Rubyの好きなところは、言語そのものや、RspecやCucumberなどテスト駆動開発に適したライブラリがあることだと述べました。Rubyと比較してJavaScriptも嫌いではないと述べ、どうしてJavaScriptのコードでテストをしないのか、と問題提起をしました。現状、Railsではサーバとストレージはテストがしやすく、クライアント側もerb、sass、rjsなどRailsとgemsを使ってテストを書くことが多い、とまとめました。しかしSQLと比べて、JavaScriptは言語としてまだ流動的であるとも述べました。 Seleniumを使ってテストは書けるが、面倒なことが多いとも指摘しました。

そして、JavaScriptのテスティングフレームワーク、Jasmineを紹介しました。RSpecのように記述できるBDD（ビヘイビア駆動開発）フレームワークです。Jasmineの哲学は、「⁠DOMに依存せず、JavaScriptでJavaScriptをテストしよう」というものです。 Railsアプリケーションでは、"spec/javascripts/projet_form_spec.js"のようにおきます。describe、it、expectなど、rspecのような書き方ができます。 http://localhost:8888/にアクセスすると、テストを実行し結果をブラウザに描画します。

最後に、"Respect your JavaScript!"と、発表を締めくくりました。

質疑応答では、「⁠ほかにもJavaScriptのテスティングフレームワークはあるが、どうしてJasmineを作ったのか？」という質問に対して、「⁠JsUnitやそのほかのフレームワークは、DOMに依存していた。また、私がヘビーなRSpecユーザだったから」と答えていました。

geemusさん「User Experience for Library Designers」

EngineYardかに所属するgeemusさんは、発表をこんな言葉で始めました。"DREAM JOB. BEING PAID TO BE CREATIVE."

geemusさんは、社会人になったころ、ライブラリデザインのエキスパートになろうと決心しましたが、Rails、ActiveRecord、MySqlなどはハードルが高く、その他のプロジェクトに目をつけたそうです。その中にはMerb、Datamapper、Couchなどがありました。

その経験から、オープンソースのライブラリを開発する際に重要な点を発表しました。まず、オープンソースで起こりがちなのが、ユーザがちょっとしたことで怒って離れてしまう、ということです。ライブラリで大事なのは、貢献しやすい環境を作ることだと述べました。また、「⁠Release Early（リリースははやめに⁠）⁠」⁠「⁠Release Often（リリースは頻繁に⁠）⁠」が大事であるとし、ユーザのフィードバックに期待しようともお話され、実際にgeemusさんのfogというライブラリでは138回以上のバージョンアップを行ったそうです。パッチを書いてくれたらできるだけそれを取り入れたリリースをする、というのが大事だそうです。また、「⁠ドキュメントはしっかり書こう」「⁠ユーザへのケアを大事に」とも述べられました。

もちろん、ユーザが増えすぎると困ることもあります。その際も、ユーザが貢献しやすい環境を作ることが大事であり、Tシャツをあげるとかモノで釣るのもいい、とも

また、一貫していること、何をすべきかを明確にすることも大事です。ライブラリを使うためのツールとして、テストツールや、ベンチマークツールを公開することもよいそうです。

Makoto Inoueさん「リアルタイムウェブができるまで」

イギリスのロンドンからいらっしゃったInoueさんによるPusherという非同期処理のライブラリについて、および構成要素や開発に至る経緯についてのお話です。

Pusher作成の動機として、node.jsのデモを見た時の非同期な動作を見たということと、そのすぐ後に発表されたWebSocketという技術を目の当たりしたことがきっかけだったそうです。また、Pusherという名前には「使い始めたらやめられない！」というサービスにしたいという思いが込められているとのことです。

クライアントへの通知にWebSocketを使用することはCometなどと比較してもオーバーヘッドが少なく、とても魅力的だったそうです。しかし、ChromeやSafari、Firefox(beta)での実装しかされておらず、普及段階とは言えない状況だったのですが、WebSocketと同等の動作をFlashで実現するライブラリが存在することをしり、その他の多くのブラウザに対応することができたそうです。

Pusherを実際に使う例として、このデモが行われました。また、実際にPusherを使うためにはどのように実装するのかをソースコードを交えて説明されました。

サーバサイドはDBの保存など時間のかかる処理の結果をPusherライブラリに対して渡す
クライアントサイドはイベントハンドラのようにPusherライブラリに関数を設定して通知を待つ

このような処理を記述するだけでPusherサーバを経由して非同期通知が行われるようになり、簡単に非同期化させられることが語られました。

nariさん「われわれは、GCをX倍遅くできる」

nariさんは、2008年、2009年のRubyKaigiに続き、GCについて話されました。

最初に現状のCRubyに実装されているGCや今回の主題であるLazySweepGCについての特徴、メリットデメリットを含めてどのようなアルゴリズムで処理が行われるかという話をイラストや画象を挟みながら紹介しました。そして本題の、CRubyについにLazySweepGCが実装されたという話題に移りました。

今年に入りLazySweepGCがCRubyに実装されたのですが、実は2008年にもLazySweepGCを実装したパッチを作ったもののrevertされたという経緯がありました。そして、2009年でのnariさんのセッションでは別のGCアルゴリズムの実装についての語ったのですが、当時の質疑応答で「なんでLazySweepGC実装されてないんでしたっけ」などの質問があり、周囲のnariさんによるLazySweepGCの実装の期待の高さが伺えました。そのようなことも手伝って、今年に入って改めて実装を行い、ついにCRubyに取り込まれたということが述べられました。

LazySweepGCが取り込まれることで、CG総停止時間は10%増、GC最大停止時間40%減の性能となり、その成果をkaboomというかわいらしいキャラクターが走りまわるデモアプリを通じて紹介されました。このデモをLazySweepGCを実装されたRubyと実装される前のRubyで同時に実行し、デモ実行中の動作の滑らかさなどを確認することができました。

また、今後のGC改良の候補として、「⁠CPythonで実装されたアルゴリズムを適用させたらどうだろうか」などの展望が語られました。

質疑応答では「GCが遅い、ということをどのように調べればよいでしょうか」という質問に対して、Ruby1.9ではGC::Profilerというものがあるので、それで測定するとよいと回答されていました。

Carl Lercheさん「Rubygems、Bundler、and the future」

EnginYardに所属するCarl Lercheさんによる発表でした。CarlさんはBundlerのコミッタの一人です。主にBundlerを作ろうとした経緯や、作る過程について話されました。

gemには依存関係が存在しています。例としてRSpec2やRails3は大量の依存関係が存在することをあげ、それらを手動で管理するのはすごく大変だとCalrさんは言います。例としてあるバージョンがactivateされていると、別のバージョンがactivateすることができないことをあげていました。

can't activate foo( >= 0.8, runtime), already activated foo-0.7

「cant' activate」「⁠runtime」「⁠already activated」など、先程のエラーメッセージをキーワードとしてGoogle検索した場合のキャプチャを示し、どれだけたくさんの人がこの問題でつまづいているか説明していました（8,800results!⁠）⁠。この件でEnginYardにサポートリクエストが届いたことがBundlerを作ろうとしたきっかけだそうです。このような依存関係の問題を他にもあげ、それらを解消するためにかなり苦労したと話されました。

BundlerではGemfileにgemの依存関係の一覧を記述します。例えば以下のようになります。

source "http://rubygems.org"
gem "rails", "~> 3.0.0.rc"
gem "mysql2"
gem "nokogiri", "~> 1.4.0"

もし、自作のアプリケーションの中でBundlerの仕組みを利用したければ「require 'bundler/setup'」を使用します。Railsの例でいうとboot.rbの中で使用しているそうです。

Gemfileを用意し「bundle install」を実行するとgemを取得します。Railsの例でいうと、development環境ではシステムにインストールされ、production環境では「vendor/bundle」にインストールされます。vendor/bundleにインストールされることで他のアプリケーションなどに影響与えずにすむためです。

また、GemfileはSCM（バージョン管理システム）で管理すべきとも述べていました。理由としてはGemfileがあればどの環境でも同じgemをインストールできるためだそうです。

Bundlerは1年間ほど開発しているとのことです。Rails3でも採用されていることから今後も開発が続くことが予想されます。

Sarah Allenさん「井の中の蛙、大海を知らず」

「井の中の蛙、大海を知らず」「⁠海のように言語があります」と片言ながらも最初の数分間は日本語で話されていました。

こういう場ですと「言語」と聞くとついつい「プログラミング言語」を想像しがちですが、Sarahさんの言う言語とは「日本語」や「英語」などと言った普通の会話で使われるものを指しています。SarahさんはWebのことを「海」と表現し、「⁠井戸の中の蛙のように、自分達の言語のことだけ考えている」と言います。

SarahさんはMightyverseというWebサービスの開発をしており、それはビデオ収録された言葉や文章などを収集し、様々な言語に翻訳をするというサービスと説明していました。

Webアプリケーションにおける国際化の話を4つのステップにわけ説明されました。

1.HTTPヘッダー

HTTPヘッダーのaccept-charsetをきちんと判別することが重要だと述べていました。

2.Rubyコード

ほとんどのWebアプリケーションではUTF-8の文字列をただのバイト文字列で扱うと説明し、Ruby1.8でもただのバイト文字列として扱うと述べていました。Ruby1.9では文字列にエンコーディング情報を持つので、Ruby1.8よりはRuby1.9の方が良いそうです。

3.データベース

データベースには「クライアント」「⁠コネクション」「⁠サーバ」の3つでエンコーディングについて判断する必要があると説明されました。またcollationにおいては、言語によってはソートの順番が変わってしまうなどの問題が起きてしまうそうです。例としてドイツ語ではウムラウト付きのAが通常のAより先に来てしまうと説明されました。また、ソートだけでなく文字列の等値性でも影響があるそうです。

4.表示するHTML

最後に表示するHTMLのContent-typeを判別することと話されていました。

Yehuda Katzさん「Truth and Consequences: Handling Ruby 1.9 Encodings in Rails」

「Conflicts and Resolutions in Ruby and Rails」でも登壇されたYahuda Katzさんのセッションです。冒頭で文字エンコーディングの理論的な話をすると述べられていました。

まず、そもそもエンコードとはなにか?とということが話られました。「⁠会議」という単語を例にあげ、コードポイントの配列をとるサンプルを表示し、エンコーディングはバイトであると説明されました。

"会議".codepoints.to_a
[20250, 35696]

Ruby1.8 Python2

Ruby1.8やPython2では文字列はただのバイト列と述べ、Ruby1.8ではただのバイト列なので違うエンコーディングの文字列を連結できることが説明されました。また、UTF-8で書かれたページをLatin-1で表示すると文字化けを起すと説明をし、エンコーディングが一致しないと問題が起こることを話されました。

正規表現を持ち出した例では、以下のようなコードを示し$KCODEの値によって結果が変わると説明していました。

/\w/ =~ "会議"

また、Ruby1.8では文字列がただのバイト列の例として、以下のようなコードを表示し、日本語で「悲しい」と資料に書かれており会場の笑いを誘う場面もありました。

"会議"[0]

Java Python3

Javaにおいての文字列はUnicode列と説明し、ShiftJISの複数のコードポイントが1つのUnicodeにマッピングしてしまう問題を取り上げていました（http://support.microsoft.com/kb/170559⁠）⁠。

Ruby1.9

Ruby1.9では文字列にエンコーディングを持つと説明し、以下のようなコードが表示されました。

 String == Struct {
             Bytearray bytes,
             Encoding encoding
           }

Ruby1.9では文字列にバイト列だけでなくエンコーディング情報を持つため、違う文字コードでは連結することができず無理矢理連結するにはfoce_encodingを用いる必要があるとのことです。

force_encodingについては、ライブラリなどの外部と自分のプログラムとの境目を「境界」と表現し、エンコーディングがはっきりとわかっている場合にのみ使うべきでそれ以外の用途にはあまり使うべきではないと説明されていました。

Yasuko Ohbaさん「Rubyで作るDSLの基礎」

現役のRubyプログラマであり、株式会社万葉の社長であるYasuko Ohbaさんがドメイン特化言語（DSL⁠）⁠、その中でもプログラムで使用する言語と同じ言語を使用して作成される言語内DSLについてのお話をされました。

「RubyはDSLに向いている」といわれている一方「DSLはすごい人が使うもの」と思われているのではないかと、Ohbaさんは話します。しかし、本来はそんなことなく、簡単に書けるコツを伝えてくれました。

プログラムがDSLっぽいかというのは、感覚的な区別がわかりづらいということで、普通のRubyプログラムと比べたときのDSLの特徴を述べられました。Rubyのようなオブジェクト指向言語の場合、メソッド呼び出しが、レセプト(レシーバ)に対して命令をするという形式で記述します。一方、DSLでは「宣言的記述」「⁠ブロックの活用」「⁠特定の概念を表わすメソッド」という特徴を意識して記述するのが特徴のようです。

「宣言的記述」とは、「⁠○○はXXです」のように状態や性質について記述する方法です。関数型言語の特徴の一つとしてあげられるようなものです。「⁠宣言的記述」をするコツとして「実現したい処理がクラスの性質として表現できないかを考えること」「⁠レセプタは必ずしも重要でない」というポイントが示されました。

「ブロックの活用」では、ブロックを使用する箇所として、「⁠複雑なデータ構造を表現するため」と「処理のスコープを限定させたいとき」の2つのポイントが語られました。

「特定概念をあらわすメソッド」では、メソッドの命名について言及し、「⁠名詞がわりのメソッド」「⁠他の言語にマッピングされるようなメソッド名にする」ことが説明されました。

このように、RubyとDSLの特徴の違い説明するため、プログラムとして書かれたコードをDSLにしていく例を示すことで、DSLは難しくないといことを伝えてくれました。

Shugo Maedaさん「君のクラスの最高の偽物」

RubyKaigi初日大ホールの最後は、株式会社ネットワーク応用通信研究所のShugo Maedaさんによる、Rubyにclassboxを実現させるというお話でした。

オープンクラスとは、Rubyにもある既存のクラスに対して拡張が行なえる便利な機能のことです。メソッドの追加や置き換えが可能で、組み込みクラスにも行なえます。しかし、オープクラスには「オープンクラスによる変更の影響がグローバル」「⁠複数の拡張の衝突が発生する」という問題点があります。実際、RailsでString#charsがあり、ruby1.8.7で追加されたString#charsと衝突が起きたりしたようです。

このような問題を防ぐため、他の言語ではclassboxという機能のがあり、オープンクラスの影響の範囲をおさえこむことができます。しかし、Rubyにはないため導入してみたいというのが今回のお話のテーマです。

classboxを実現するために、メソッドの探索方法や、拡張したクラスのsuperの探索方法等の問題点をどのように解消したかという方法を詳しく解説し、動作デモが行われました。そして、その解決方法を使用して、classboxを言語内DSLとして実装されたようです。

また、caller bindingという面白い機能も紹介されました。caller bindingとは、eval()に対して実行コンテキストをどれだけ戻るかという情報を渡すことができるようになる機能です。

def foo
  eval("p x", binding(1)) # 1と書くと1つコンテキストを戻って値の探索をする
end
x  = 123
foo #=> 123

次に"Ruby2.0の新機能(かもしれないもの)(2) nested def as local function"を見て、やり方が思いついたという、メソッドのネストを実現方法が解説されました。

本講演で紹介された機能のRubyに対するパッチは、shugo.netにて公開されています(対応するRubyは8/7のもの)。このパッチをあててもRubyのtest-allが成功することを確認されているそうです。ただし、たまにセグメンテーションフォルトが発生してしまうとのことです。

質疑応答では、「⁠メソッド呼出が複雑になっているので、遅くなってしまうのではないか?」という質問がでました。しかし、その場でベンチマークをとり、あまり遅くならないことを見せてくれました。

jugyoさん「My many failed products」

株式会社万葉で働いているjugyoさんは、ご自身が開発されたいくつかの「自称・失敗プロダクト」について、「⁠なぜ失敗したのか」「⁠学んだことはなにか」といった考察を交えて話されました。

ひとつめは、jugyoさんの代表作ともいえる「g」についてでした。gは、Rubyのpのように手軽に、Mac OS X用のアプリケーションであるGrowlを利用した通知を実現してくれるライブラリです。RubyConf 2009では、gについてのLTでBest Talkerに選ばれています。

「gのソースコードはたった30行くらい。この程度のライブラリでも、RubyConfで話すネタになる」と紹介したあと、問題点は「けっこうしょぼいこと」であると付け加えました。理想としては、SmalltalkのInspectorのように高機能なものを目指していることのことでした。

続いて紹介されたのは「growl-logger⁠」⁠。Growlへのログ出力を扱うライブラリです。「⁠Loggerのログレベルも、Growlの通知のレベルも、どちらも5段階なので、ぴったり。最初はすごいアイディアだと思ったが、一度も使うことはなかった」と述べ、ふりかえりとして「アイディアの過大評価」を挙げました。

3つめは「growl_sql⁠」⁠。これはRuby on Railsのプラグインです。SQL文が実行されるたびに、その文をGrowlで通知してくれるというもの。「⁠大量のSQLが実行されると通知で画面が埋め尽くされて大変なことになる。アイディア自体がよくなかった」と話しました。

さらに「termtter」の紹介へと続きます。こちらはターミナル上で動作するCUIのTwitterクライアントで、Rubyで簡単にプラグインを作ることができる珍しいものです。「⁠ユーザアイコンを表示させたい」等の要望があるそうです。

他にも「gitki」「⁠termcolor」「⁠cinatra」と、畳み掛けるように紹介があり、密度の高いプレゼンテーションでした。こうしてたくさんのライブラリを作って「gemの簡単な作り方が分かった」とし、最後に「ブログを書くようにコードを書こう」と、プログラマとしての姿勢を示しました。

tenderloveさん「みんなが楽しくプログラミング出来る魔法」

Jeremyさんのキャンセル枠にも登壇したtenderloveさんの発表です。いつもエンターテイメントな彼の発表ですが、今回はスーツ姿に「たこ焼き」のかぶりものというスタイルで、会場の笑いを誘っていました。

「レゴブロックでなにかを作るのが好きだった」と、幼少時代のお話からトークは始まりました。「⁠だけど、開発者になってしばらく、物作りが好きであることを忘れていた」と述べ、彼にとっての「楽しむために大切なこと」の話に続きます。

「言語は大切である」と彼は言います。自然言語に比べて、プログラミング言語は複数種類の体得がカジュアルに行われています。「⁠言語は思想を入れる箱である」とし、多様な入力と多様な出力をもって、楽しい活動の起爆剤とするのです。

「環境は大切である」と、彼はまた言います。「⁠バスで」「⁠電車で」「⁠公園で」と言ってスライドがめくられるたびにスクリーンに映し出される「たこ焼き仮面」に扮した彼の写真に、聴衆は大いに沸きました。「⁠なにかをかぶっているときに、最も生産的だったりする」という彼は、彼の所持する「花の帽子」「⁠かつら」「⁠ロシアの制帽」などを、装着時の写真とともに披露してくれました。

発表も後半に突入すると、次第に開発やプログラミングの話にシフトしていきます。彼が参加するSeattle.rbでは、週次でHack Nightという集まりを開催しています。「⁠自分より能力のある人となにかするのが好きだ。人同士のつながりを大切にする。これまでにたくさんの人たちと会えた」と言います。

終盤には、YAMLのparser/emitterであるPsychやphubyの紹介がありました。特にphubyの紹介では、phubyを通してRuby上でPHP製のブログソフトであるWordPressを動作させるデモがあり、会場の注目を集めていました。

「自分自身への挑戦を続ける」と締め括られたプレゼンテーションは、気持ちの在り方からピュアな技術の話題までを含み、観客を飽きさせないものでした。

セッション以外の模様

ジュンク堂RubyKaigi店（1）

3日間にわたり、ジュンク堂の出張所「RubyKaigi店」が開設されています。先行販売されている『メタプログラミングRuby』がさっそく売れているようです。『⁠WEB+DB PRESS』も100冊ありますので、ぜひ手にとってご確認いただき、そのまま購入をご検討いただければ幸いです。

「Ruby on 松江ラーメン」の出張販売

株式会社中隆さんが、会場にて「Ruby on 松江ラーメン」の出張販売を行っています。1,000個以上持ち込まれているそうです。限定パッケージもあるそうなので、ぜひ手に取ってみてください。

コミュニティナイト

1日目の全セッション終了後、同会場の多目的ホールにてコミュニティナイトが行われました。参加者全員で食べものや飲みものを持ちより、歓談を楽しみました。途中、各地域のRubyコミュニティから、各コミュニティのアピールタイムが取られていました。

ネットワーク状況について

本日の会場ネットワーク状況を踏まえ、RubyKaigi日記にて「RubyKaigi2010会場のネットワークについて」という記事が公開されました。

記事では、会場ネットワークは本日すでに混雑している状況であり、2日目からは参加者が増えることが見込まれるため、ネットワーク状況がより厳くなることが想定されること、したがって譲りあって利用してほしい旨が述べられています。