茨城県つくば市のつくば国際会議場にて日本Ruby会議2010が開催されています。本日は2日目です。本稿では、2日目の模様を随時レポートしていきます。
スタッフは朝8時半に集合して、朝会が行われました。運営上の確認点や注意点に関する情報をスタッフ全員で共有していました。
本日から、ジュンク堂書店RubyKaigi店では、Rubyに関係ある書籍のサイン会が行われます。こちらも要チェックです！
なお、会場ネットワーク状況に関して、RubyKaigi日記にて「RubyKaigi2010会場のネットワークについて 」が案内されています。現地で参加する方は確認しておきましょう。
Yuguiさん、Shugo Maedaさん「Ruby 1.9.2 is released! / Rubyコミッタ Q & A」
Yuguiさんによる1.9.2のお話
最初はYuguiさんによるRuby 1.9.2の話からスタートしました。1.9.2のリリースは8月21日にruby-talk:367983にて告知されました。Ruby1.9.2の特徴として以下のようなものがあります。
IPv6を透過的に扱えるSocket
2038年問題に対応したTime
Ramdom
日本の携帯絵文字に対応した encodings
より便利になったArray/Enumerable enhancements
新しいライブラリであるFiddle、Psychの追加 次に今回の1.9.2のリリースまでをふりかえりました。RubyKaigi2009で「2009年のクリスマスリリース」と宣言したが、ここまで遅れた理由として「RubySpec対応」をあげました。「 RubySpec 」とは、増えだしたRubyの実装に対し、Rubyとしてどう振る舞うのが正しいかを定めるテスト（仕様）のことです。これに対応することで、Ruby1.9がどのよう振る舞うかを定めたかったと話します。RubySpecへの対応について、コミッターの一人である、えんどうさんが壇上にあがりました。また、FFIとfiddleの開発をしたtenderloveさんも活躍をたたえられ、壇上にあがりました。
いろんな改善のされたRuby1.9.2ですが、以下のような問題があると述べられました。
dl2 の導入により移植性が下った
Syckの開発者がいなくなってしまった
Rubyの標準添付になったRubyGemsが1.8の頃と挙動が違う
数学関連ライブラリの仕様が安定していない 今後のRuby1.9としては、RubySpecによって他のRuby実装との共通性の基盤ができたため、Ruby1.9としての独自の機能拡張性を模索していきたいと述べられました。独自の機能拡張の候補として「profiler」「 tracer」「 debugger」「 MVM」をあげ、個人的には、dtraceの導入の検討を話されました。
まとめとして、Ruby1.9は仕様をよりかためていくということと、実験的な方法を模索していくことが言及されました。仕様の確定により現在の振る舞いが変わり従来のプログラムが動かなくなる可能性や、実験的な機能の場合は無くなるかもしれないので注意を払う必要があるようです。
公演中、「 Ruby1.9.2はbetter 1.9.1」とYuguiさんは、話されていました。そんな1.9.2をわたしたちも早く使っていきたいですね。
コミッターQ&A
後半は、壇上に総勢26人のRubyコミッターが集合して、会場からの質問に答えるという豪華なものになりました。
「1.8と互換性のない1.9のルールで書かれたスクリプトを1.8で実行するときに、動かなくていいのでパースは成功させてほしいのですが可能ですか？」や「MVM（Multi VM）はいつごろ導入されますか？」という質問から「エディターは何をつかってますか？」という質問まで、様々な質問が飛びかいました。また、コミッターのえんどうさんより会場に対し「Rubyの古いバージョンに対して、新しいバージョンの新機能をどんどんいれてほしいか、安定化をめざしてほしいか？」と逆に質問が投げられたりもしました。
このセッションの最後にでた質問で、コミッターのnari3さんより「コミッターとして大事なものは？」という質問に対し、えんどうさんが「継続力」と答えられていたのが大変印象に残りました。
Matzさん「基調講演」
Rubyの生みの親、Matzさんは、"Ruby 2.0"と題して基調講演を発表しました。
まずはじめに、8月18日にRuby 1.9.2がリリースされたことに触れました。今回Ruby 1.9.2 Awardとして、Rubyコミッタの遠藤さん（@mametter）を表彰し、Rubyアソシエーションから、賞状と「ルビーの原石」がプレゼントされました。
まつもとさんはTwitter にて「RubyKaigiで歴代キーノートでも最高にマニアックでテクニカルな話をしてもOKだろうか」とつぶやいていたが、昨日の前田修吾さんの発表のほうがもっとマニアックだった、と述べていました。
まつもとさん曰く、「 プログラミング言語の進化として、"Good Enough"、"Nearly Perfect"、"Perfect!"という段階があり、Ruby は十分に良い言語（Good Enough）である」と言います。さらに「Rubyは良い言語、良い実装、役に立つ」「 だからこそわたしたちはここにいる、いい時間を過ごしたいからつくばまできた」「 そして、もっとよくすることはできるだろう」と述べました。
その後、"To Make Ruby Nearly Perfect"として、まつもとさんがいまのRubyの気に入らない点を4つあげました。
Scope of local variabls
ローカル変数のスコープの解決で問題になることがあり、解決策として“ 外側で参照されたら、自動的に外側のスコープに所属を更新する” という案を考えたが、いくつかの人に聞いたところ、関数型のように記述したり、Enumerableを使うので、問題に当たらなくなってきたとのことでした。
結局、気に入らないけど重箱の隅であり非互換性があるので、そのままにしようと約束する、と述べました。
Mix-in defect
モジュールを読み込む際、あとからincludeされても反映がされないなど、コードの例をあげ説明しました。今回の発表にてこの問題についての解決策を提案しました。
No private method
Rubyでのprivateは、C++のprotectedに相当するものです。よってたまたま名前が重なってしまったときに面倒なことになる、とのことでした。この問題についての解決策を提案しました。
Global monkey patching
モンキーパッチをあてて動作を変更するような場合、環境全体で反映されてしまうため影響範囲が大きいという問題があります。CLassboxを導入して解決しようと考えているとのことです。
Integer division
現在のRubyでは、割り算を実行する際、数値の型を意識しないと意図した計算ができません。この問題は、mathnを利用し、Classboxと併用することで安心して使えるようになるだろうと述べました。
そして、Mix-in defectとNo private methodについて、解決策を説明しました。
まず継承についてLSP（Liscov置換原理）を紹介し、「 静的言語ではLSPはとても重要であるが、動的言語ではダックタイピングがもっと重要である」と述べました。
RubyではMix-inを提供しており、任意の数のmoduleから継承ができます。
しかし、複数のモジュールをincludeしたとき同じ名前の属性がある場合、ぶつかったことを見つけることができないし、解決の仕方もわからないという問題があります。またinclude関係があとから変更されたときにわからないという点があります。今回のRubyKaigiのテーマにむりやり合わせたそうです:-)
この問題の解決策として"mix"という構文を提案されました。mixはSmalltalkのTraitsのような機能で、includeメソッドのように、mixメソッドを定義します。
たとえば、以下のようなコードの場合、
class Bar
mix Foo
end
includeと違い、スーパークラス（ancestors）にFooは列挙されません。同じ名前があり衝突する場合は、エラーがでるようになります。そして、mix japanese, :address => :jp_address のようにして、取り込むメソッドの名前を変えることもできます。
また mix foo,[:D => :C] などとして、定数の取り込みを可能にします。
privateの問題については、リファクタリングなどで一時的にメソッド名を変更した場合にメソッドが衝突する可能性があります。この点については、Classboxが役にたつのではないかと述べていました。
最後にRuby 2.0の構想について"just started"と述べ、「 RubyKaigiから帰ったらそのままはじめる」ということです。実際には、2.0に付け加えるものはさほど多くない予定で、もしかしたら1.9.3にしようと思っていたものが2.0になるかもしれない、とも述べました。その候補としては、Traits、Classbox、Keyword arugmentsがあるそうです。
質疑応答では、mixを実際に利用する際のユースケースを想定し、「 いくつかのmoduleがincludeされているmoduleをincludeするとどうなるのか」などを議論をされていました。
また、「 複雑な仕組みで、ユーザは使いあぐねるのでは？ユースケースはありますか？」との質問には、Railsなどで、alias method chainでプラグインを実装しているところなどに使えると思うと回答しました。
「 privateメソッドはJavaと同じprivateに変えるのではダメか？」について「正しい、を実現して6割のコードが動かなくなるのでprivateの単語の意味そのものを変えるのは受け入れがたい。ClassboxのAPIについてはもっと簡単な表現で提供することは可能だと思う」と述べていました。
「includeとmixが両方存在すると、どう使い分けてよいか分からない」という質問に対しては、「 将来的には、includeは使わず、mixを使うようにしましょう、と言えるといい」と回答していました。また、「 従来のincludeだとincludeされていることがわかるが、mixの場合はわかるのか？」との質問に、「 基本的にない。よりduck typingに近づく」とのことでした。
Munjal Budhabhattiさん、Sudhindra Raoさん「Rocking the enterprise with Ruby」
ThoughtWorks社のBudhabhattiさん、Raoさんによるエンタープライズ領域でのRubyの活用事例として、データセンターでの管理システムを実装されたケースについての発表です。具体的にはデータセンターで使用されるネットワーク機器の監視、ログの取得などを行うシステムだそうです。
Rubyを選択した理由として、リファクタリングのしやすさや、自然な構文でアプリケーションを書くことができる、そしてThoughtWorks社自体にRubyに詳しい人が多いのでアドバイスを受けやすかった、という点を挙げていました。
なお、以下のOSSを利用しているとも話されていました。
また、質疑応答の時間では「なぜRubyを選択したのか」という質問に対し、「 コミュニティが大きく、助け合いができているから」と回答していました。
Jiang Wuさん「Rails to Sinatra: What is ready」
Jiangさんは、開始時に「こんにちは」と日本語であいさつをして話を始めました。その後、Sinatra 1.0の世界にようこそ を執筆された@tsuyoshikawa はいますか？と聴衆に問いかけるシーンがありました。
発表では、今年1.0がでたばかりのsinatraについて、"友達"というキーワードを元にシンプルさ、モジュールの組み合わせなどが語られました。
Rackは最高の友達として、Rack::URLMapやRack::Cacheなどを組み込む例などを紹介しつつ、Sinatraを使う際に一緒に使っていくライブラリについて詳しく説明されました。
Sinatraの友達として、以下のものが挙げられました。
これらの組み合わせで使うのがオススメの組み合わせだそうです。
テストでの組み合わせでは、Rack::MockRequestを必須の友、と述べました。また、認証の組み合わせは標準では持ちあわせていないので好きなものと組み合わせを作ることができますが、Wardenを組み込むことでOpenIDやOAuthへの対応をすぐにできるということが語られました。
Railsとの比較としてrespond_toではなく、sinatraの持っているroutesという機能を使用するのですが、.xmlや.jsonの場合に特定の処理をしたいというような要求の場合は正規表現を使ったroutesの指定をするとシンプルにかけるというテクニックが紹介されました。
Ted Hanさん「Mapping the world with DataMapper」
Tedさんの発表です。初めに日本語で簡単な挨拶を行われました。日本語は3年程勉強したそうですが、「 全部忘れました！英語で話します！」と話し、会場の笑いを誘っていました。また、DataMapperの話の前に「早口で話すので」とつげ、資料のURLを教えてくれました（http://cl.ly/6233b0f56bb686e57b74 ） 。
TedさんはGoogleやApple、Facebookなどのサービスを例にあげ、「 これらの会社はサービスを提供するかわりに、あなたのデータを集めている」と言います。続けて「これらのデータを元に間接的に利益をもらえるが、自分たちのデータなのに何故直接利益を得られないのか？」とも話していました。そして、実は利益を得る方法はあってRubyとDataMapperでできると言及しました。
例として「Googleの検索履歴の解析」をあげました。Googleは検索履歴用のAPIを提供しませんが、Google Chromeが生成するローカルのデータを用いることで解析できると述べました。
また、検索履歴のsqlite3のデータからURLテーブルを例にだし、Urlクラスとしてモデルを定義するコードを紹介しました。DataMapperのマッピングは、SQLのテーブルとほとんど同じとのことです。
その後、Tedさん自身の検索履歴からruby-doc.orgの解析結果を示し、「 どの時間によく働いているかがわかる」と説明しました。
次に、海外のWebサイトのページ を例にあげました。このページは「Edge Magazine:http://www.next-gen.biz ]]はアンチPS3であるか?（XBOX360を贔屓しているか?） 」という内容で、これを確かめるという話でした。Edge MagazineはAPIが存在せず、スクレイピングを行う必要があり、そのためにnokogiriというライブラリを用いたと述べられました。スクレイピングして集めたデータをDataMapperでマッピングし、解析するとEdge MagazineはアンチPS3でないことがわかるそうです。
以上の2つの例から、「 他にもたくさんできることがある。あなたは何を学びたいですか？」と話し、セッションを締め括りました。
Yusuke Endohさん「超絶技巧 Ruby プログラミング」
先の「RubyコミッタQ&A」にも登壇し、まつもとさんの基調講演の中では「Ruby 1.9.2 Award」を贈られた、Ruby 1.9.2リリースマネージャー補佐のEndohさんによる発表です。タイトルは「超絶技巧Rubyプログラミング」という、なんだかすごそうだけどよく分からないものです。
最初に、Esoteric languageについて説明しました。例えば、Rubyで「Hello, world!」を出力するコードは、もちろん1種類ではありませんが、ほとんどの人は以下のように書くでしょう。
puts "Hello, world!"
ですが、Endohさんの書いたコードは以下の通りです。
alias|send\
;$stdin=GC | "%p?"%def#
FALSE.gets();(8 | 64).chr+232424.
to_s(25)+", "+%w|w ! | *"orlc". next<<012||
(c).Yusuke end;"oh, 2009" | "stegano-X."[0,4].reverse
d,be="whydoes","crypto";:make. | %.mains..tr'eams',be.delete(d)
さあ、超絶技巧Rubyプログラミングの世界への扉が開かれました！
続いて紹介されたのが「数字だけでHello, world!」「 _（アンダースコア）だけでHello, world!」の2つです。そろそろ訳がわからなくなってきましたね。見所は「ゲーデル数などの、むだに深淵な背景知識」「 勝つためならなんでもする」であると語れました。
次はQuineのお話です。Quineとは、自分自身のソースコードだけを出力するようなプログラムのことです。以下は、RubyのQuineの例です。試しに実行し、出力を確認してみてください。
s="s=%s; printf(s,s.inspect)\n"; printf(s,s.inspect)
Endohさんがブログで紹介されている山手quine のデモをはじめ、15PuzzleのQuine、Tic-Tac-Toe（○×パズル）のQuine、オセロのQuine、クリスマスソング演奏機能付きQuine、11種類のプログラミング言語を使ったquineリレー と、様々な自作Quineを披露しました。
「実行に5分ほど掛かるスクリプトを動かします」といって質疑応答の時間に入ると、スクリーンには「RubyKaigi2010 Credit」と題したテキストが出力され、スクロールされていきました。スタッフの名前やスポンサー企業のロゴ画像をアスキーアートで表示し、おまけにBGMまで流れました。これがQuineだというのだから驚きです！
最後まで会場が沸き続けた発表でした！
Kazuhiro NISHIYAMAさん「Rubyな日々」
Rubyのコミッターであり、るりまのコミッターでもあるNISHIYAMAさんの発表です。コミッターとしてどのような時間を過ごしているかが紹介されました。
Rubyとの関わり方は、最初に「使っている人が少そうな環境で実行してみる」「 変な引数を与えて実行してみる」そうです。そこでバグらしきものを見つけたら「本当にバグかどうか確認する」「 バグを再現する最小限のコードを書く」「 できることなら、テストを書く」ことになります。それから「パッチを作り、IRC等で相談して質を高める」作業に入り、ようやくRedmine に登録します。
バグを解決する準備ができたら、いよいよ「コミット」です。バグがセキュリティに関連しそうなものであれば専用窓口へ渡されます。また、コミットのあとにも作業はあります。「 ドキュメントを更新する」「 るびまを更新する」といったお仕事もRubyユーザにとって大切なことです。
普段、一般のRubyユーザにはなかなか見えてこない、コミッターの日常を垣間見ることができる発表でした！
コミッターがチェックするIRCチャンネル
NISHIYAMAさんが普段チェックしているIRCの接続先として、以下が紹介されていました。
okkezさん「Ruby リファレンスマニュアル刷新計画 2010 夏」
Rubyリファレンスマニュアル刷新計画 (通称るりま) プロジェクトの活動報告をokkezさんが紹介しました。
るりまは「ruby1.8.7 or 1.9.1のリリースとともに完全なリファレンスマニュアルをリリースすること」を目標としています。マイルストーンがいくつか設定されており、第一段2006/10/11に、第二弾は2007/01/08に達成しました。現在第三段階に向かっており、第三段階のマイルストーンは「組み込みライブラリ、標準添付ライブラリすべてのメソッドエントリを記述する」ことです。
続いて、るりまのRubyKaigi2009からの活動実績が述べられました。
るりまリポジトリをjp.rubyist.netへ
るりまWikiをredmine.ruby-lang.orgへ
doc.ruby-lang.orgを8月半ばから公開 上記以外の大きな動きとして、るりまサーチ とmyrurema のリリースがありました。るりまサーチとはいうのは、るりまの全文検索サービスが株式会社クリアコード の社長である須藤さんによって公開されました。るりまサーチについては、3日目に須藤さんによって発表されます。また、myruremaという、るりまのgemパッケージが yahara さんにより公開されました。
また、るりまプロジェクトの現状として「コミッタが減った」ということを述べられてました。そして、歴代コミット数グラフでコミット状況の推移が紹介されました。現在、るりまでドキュメント化の完了したライブラリは全体で286あるうちの190が終わっている状態であり、組み込みクラスについては92クラス中の90が終わっているということです。
okkezさんは、「 Rubyをよく知ることができた。そして、Rubyのバグをいくつか発見できた」と、るりまをやっていた感想が語られました。ソースを良く読むことで、Rubyをよく知ることができたそうです。
今後のるりまの予定として、「 第三段階をできるだけ早く終わらせ、参加しやすくすいを環境作り」が挙げられました。るりまは全部のバージョンのRubyをビルドして確認する必要があるため、参加するための障壁下げていきたいとのことでした。
そして、るりまプロジェクトで困っていることとして、以下の事柄などが挙げられていました。
windows系
1.9.2対応
標準添付ライブラリ
ツール整備 最後に、「 今まで使うだけだった人や企業」「 具体的に行動したい人や企業」「 Ruby力を飛躍的にあげたい人」に、るりまを手伝ってみませんか、と言葉を投げかけられました。
okkezさんの発表後、質問タイムが設けられ、会場からるりまプロジェクトの発起人である青木峰郎 さんが登壇され、okkezさんと二人でるりまの今後について相談されていました。
Jake Scruggsさん「The Necessity and Implementation of Speedy Tests」
一時間の枠だったのですが、30分のセッションx2という体裁で進むことになったJakeさんのセッションです。
Speedy Tests
まず最初に、遅いテストとは「あなたのチームのモラルを吸い取る吸血鬼だ」と話し、どのように悪い影響があるのかを示し、テストがあることで安心を得ることができると語りました。では、どのように遅いテストを改善するか、という問題については、以下の項目について検討すると良いということが述べられました。
マルチコアを有効に使用してCPUを余らせない
ディスクI/0を減らす
atime の更新を止める この他に、クレイジーなテクニックとして、Ruby EEを使用してGCの設定を非常に大きな値にすることでGCのコストを減らし、テストを早くすることもできるという話も紹介されました。
銀の弾丸の話はここまでとして、実際に直面している問題に対してどのように対応していけば良いかが説明されました。
Webにアクセスするような重い処理をスタブ化しよう
前処理が多いテストはテスト対象のオブジェクトとしては良くない
FactoryGirlはとっても( ・∀・)イイ！ 最後に、一番伝えたいこととして、テストを書くときは実行速度についても考えておくことは重要だと語りました。
コードの Metrics
後半は、ボトルネックを調べるためのMetrics測定ツールとして、metric_fu を紹介しました。とても重宝しているそうです。構造的な重複を検出できるため、DRYなコードを保つために役に立ちます。
また、Saikuroというツールを使うことでコードの複雑度が測定できるそうです。複雑度の解決には設計が重要なので、一人で考えてうまくいかなければチームで考えることも有効だと語りました。
paulelliottさん「Seamless Integration Testing」
paulelliottさんは、統合テストツールのCapybaraやその関連ツールを紹介しました。
統合テストとはお客さんとの契約であり、機能に対する責任と将来のメンテナンスのために必要なものであると語りました。
CapybaraはRubyのDSLとしてテストを書くことがあり、DOMの操作にはXPath記法を使って実装することができ、比較的馴染みのある記述を行うことができます。
以下のようなコードでHTHLの操作を行うことができます。
visit root_path
click "A link"
click "A button"
fill_in "Name", :with => "Paul"
select "Developer", :firom => "Profession"
attach_file "Profile Pic", "hoge.jpg"
check "Male"
uncheck "Female"
page.should have_content("Paul")
within("//div[@class='personal_info']") do
page.should have_xpath(hogehgoe)
end
また、その他にrspecに組み込んで「ログインをする」というストーリーを想定して作成したテストを、HTMLで書く場合とJSで書く場合にどのようなコードになるのかをスライドに映してどのような実装になるかが説明されました。
Tanaka Akiraさん「Unix修正主義」
Tanaka AkiraさんによるRuby APIについてのお話でした。最初にこれまでの話と称し「Rubyがどうデザインされているか」「 Unixの機能をどういうデザインで提供するか」という話をされました。
Ruby IO
例としてRuby1.4.6当時のIOのメソッドの多くがC言語（stdio）やUnix、Perl、C++、Windowsなどが由来となっているとし、RubyはUnix文化圏に属すると言及されました。TanakaさんはUnixのI/O機構をオブジェクト指向化することで、Unix使いにとって覚えることが少なく使い易さを実現すると説明しました。
RubyのIO#eof?はfeof()由来ですが、実は動作が異るそうです。EOFを判断する関数にはPascalの動作とCの動作が違うと話し、RubyはPascalと同じように動作することが説明されました。Cのfeof()は「C言語 FAQ 12.2」になるほどPascalの動作を期待する人が多く、Rubyはそれを考慮してPascalと同じ動作になっているそうです。
しかし、実はfeof()は必要ないと話します。これは先程のFAQにも書かれています。PythonはEOF判定のメソッドを提供しておらず、Pythonの見識は素晴しいと語られました。Ruby1.9ではstdioを捨てる際にEOFフラグを実装せずに済んだそうですが、YAMLの例にあげ、挙動をユーザの期待に近づける余地があるかもと言及しました。
select
次にシステムコールのselectを例にあげ、RubyにIO.selectとして実装されているが、これも動作が違うことが説明されました。システムコールのselectはstdioのバッファを考慮せず、RubyのIO.selectは考慮するよう実装されているそうです。Ruby1.9においては、stdioを捨て独自にバッファリングを実装したそうですが、Rubyスクリプトレベルではあまり関係ないと話されました。
read、writeシステムコール
read、writeシステムコール共にノンブロッキングモードかどうかで動作が変わって良くないことが説明されました。プロセス内バッファとの組み合わせで問題が発生し、Rubyのマルチスレッドが問題をさらに拡大させるそうです。readシステムコールについては「readpartial」「 read_nonblock」という2つのメソッドを用意、writeシステムコールについては「write_nonblock」を用意することで解決したそうです。
時間の都合上、forkシステムコールや時刻関数などは省略されましたが、これら問題を修正した上でRubyに実装されているそうです。
過ちては改むるに憚ること勿れ
Tanakaさんは孔子の言葉「過ちては改むるに憚ること勿れ」を引用し、過ちを犯したらためらわず改めるべきと言います。とは言え、互換性に勝つことはできないとも述べられました。
findの-depthオプション
Unixにはfindコマンドが実装されており、Rubyにもfindライブラリがあることが紹介されました。findには-depthオプションが存在しますが、実はこれは名前が間違っていると述べられました。-depthオプションはRubyライブラリに実装されておらず、仮に誰かが実装したとしても-depthという名前だったら反対すると話していました。
デフォルトで FD_CLOEXECという提案
Rubyでは意図しないfd継承で問題が起こることがあるそうです。Ruby1.9では継承を拒否できますが、それがデフォルトではないのは互換性のためと説明されました。互換性の問題はあると説明しつつも、中期的にはデフォルトで拒否オプションをtrueにし、長期的には内部のフラグをデフォルトで設定するのがいいのではないかと述べられました。
openat
opennatは新しいPOSIXで定義されたシステムコールで、これをRubyに取り込む場合について説明されました。いくつか案をあげた上で、その中からさらに3つ程の有望な案を紹介していました。
非同期シグナル
非同期シグナルをUnixの大失敗と言いますが、説明するには時間が足りないと話し、残念ながら要約を説明する程度に留められていました。
まとめ
最後に「案を練る方法」として、以下の順序が望ましいことが紹介されました。
問題を発見する
用法を調べる（超重要）
他の処理系の解法をサーベイ
Rubyに適用するいろいろな案を考える
用法をうまく解決できるか検討する 特に「用法を調べる」については、普段のプログラミングの中で発見した問題ならその状況が用法となると述べられました。最後に改めて「RubyはUnix文化圏」「 Unixの失敗はなおす」「 Rubyの都合も考慮する」と話し、発表を締め括りました。
Paolo "Nusco" Perrottaさん「A Metaprogramming Spell Book」
JavaのORMツールであるHibernateのコミッターであるPaoloさんによる、メタプログラミングについての発表でした。会場前を右に左に動き、身振りでうったえかけながら、ところどころにジョークをいれて会場を飽きさせないスタイルで講演されました。
Paoloさんは、Rubyを書きはじめたころ、書けるんだけどもJavaっぽいということに気付き、Railsのソースコードを読みだしたそうです。そのとき、activerecodeを読んだそうですが、「 extend」「 class_eval」「 base_send」など見たこともないようなコードがいっぱいあり自信がなくなってしまったと話されました。これらは、Rubyのメタプログラミングで良く使われるメソッドです。
しかし、「 Rubyが好きだから」という理由であきらめずに挑戦し、わからなかったメタプログラミングをメモしてき1冊の「スペルブック」にしました。この発表では、そこに綴られた黒魔術（メタプログラミング）が紹介されました。
Part.1 Objectの基本
彼の似顔絵が描かれた図解で、Rubyの特徴的なインスタンスメソッドやクラスメソッド呼びだし時の探索順序が説明されました。Rubyのメソッド探索は「レシーバのクラスにむかって右へいき 継承チェーンを上にいく」と言います。
Part.2 Classについて
Classについての黒魔術について、途中クイズを交えて説明されました。クイズの問題は、
module Topic
def talk_about
"Ducks are yummy!"
end
end
というモジュールがあるときに、
class Duck
end
に対して、どのようにするとDuck.talk_aboutというクラスメソッドが呼ぶようにできるかという問題です。答えは、Duckクラスに対してTopicモジュールをextendします。extendすることによって、モジュールのメソッドがクラスのクラスに対してincludeされることになります。
class Duck
extend Topic
end
魔術書を作って
このような魔術書を作り、再度Railsのコードに挑んだところ、記述されているコードがよく馴染み読むことができたそうです。
そこで、Paoloさんは、驚くことに気付いたそうです。RailsのコードはBaseのクラスを作っていろんな機能を追加するスタイルです。そんなBaseを調べたとき（例:activerecord::Base）では、継承しているクラスは42個、メソッドが240個、クラスメソッドにいたっては508個と、とても多いことに気付きました。しかし、Javaだとこのようなコードを記述すると読みづらくメンテナンス性がないのに、Railsのコードではそんなことないと述べました。その理由を「Rubyだから」と語ってくれました。そして、「 JavaのマナーをRubyで守る必要はない。違う言語の偏見を持ち込まない方がいい」と、その言語らしい記述をすべきということが語られました。
またQ&Aでは、質問の中に「普通のRubyプログラマにもメタプログラミングをすすめる？」というのがありました。その質問に対して「まず勉強することはとても大切。メタプログラミングが危険だという人もいるが危険だから使わない！習わない！という考え方はよくない。私は、これはどのように役に立つと考え、他のテクニックと同じように考えて使うようにしたほうがいい」とアドバイスされていました。
今回紹介した黒魔術については、Paoloさんの「メタプログラミングRuby 」という本で詳しく説明されています。
Lightning Talks
今年もライトニングトークが行われました！
前説
今年のライトニングトークでは、残り持ち時間を表示するタイマー係 の募集をしていました。結果、今年のタイマー係は五十嵐邦明さん(@igaiga555 )が担当されることになりました。また、ドラ娘は筑波大学の学生さんに担当いただきました！
Urabe、Shyouheiさん「ARToolKit Ruby Binding」
卜部さんは、AR（拡張現実）のデモとして、カメラの画像の上にプレゼンテーション資料を載せて発表しました。技術的には、"require qt"として、QtからWebKitをそのまま利用できるため、プレゼンテーション画像をSVGで作ることで簡単に実装ができたそうです。github に公開されています。
Hidetoshi NAGAIさん「Ruby/Tk-Kit から RubyKit へ：Ruby の単一ファイル実行環境の構築に向けて」
標準添付ライブラリのRuby/tkのメンテナである永井さんの発表は、GUIライブラリのRuby/Tkの将来について語られました。RubykitというTclkit、Ruby/Tk-Kitの考え方をRubyに持ち込むことで、Rubyそのものを単一ファイルで実行できるという利点があるそうです。
Shota Fukumori/@sora_hさん「What is few?」
中学2年生のsora_hさんの発表です。まず、Rubyに"String#>>"というAPIを提案し、今回のRubyKaigi会期中の開発者会議にて、">>"はRejectされたものの"prepend"というメソッドとしてtrunkに取り込まれたそうです。本編として、lessコマンドの代替として、fewというアプリケーションを紹介しました。fewは出力結果をブラウザに表示する、という特徴があります。SSH経由で使う時は、CGIに送信しローカルから10秒ごとにチェックしているそうです。fewはgithub にて公開されています。
Koichi Sasadaさん「Toward Lightning RubyVM」
笹田さんは、英語で発表されました。RubyのVMのパフォーマンス、スピードアップについて"VM re-design"として、VM自体の再設計が語られました。RDocやRailsの実行時間を解析し、どこに時間がかかっているのかを紹介されました。この結果、CRubyでは並列スレッドを導入するのは良くないのではないかと述べました。また、並列化について、「 Rubyistは気にすることがなく、VMが自動で並列化する」ための方法について、構想が語られました。
Sadayuki Furuhashiさん「MessagePackで多言語間通信」
kumofsなどのプロダクトを古橋さんは、MessagePackについて発表しました。MessagePackは、JSONのようなシリアライズ形式でJSONより速く、小さいという特徴があります。また、C++、Pythonなどのプロセス間通信を可能にする、MessagePack-RPCも紹介されました。Parallel Pipeliningなどがあり、ThriftやAvroより使いやすく、堅実な実装だそうです。
Yoshihiko Haraさん「Rubyで手軽に暦日を算出しよう！」
原さんは、「 趣味のライブラリの紹介です」とおっしゃりながら、Almanac for Rubyを紹介しました。これは、Almanac for JavaをRubyで再実装したそうです。Almanac for Rubyは、太陰暦に従って、干支や二十四節気、東洋暦日、二十八宿などを算出でき、利用例を上げていました。
Kazki Matzさん「Introducing the Lingo Project：A New Generationi Text Input System Leveraging Non-native English Writing」
「Matzです。The Matzではありません」という松本さんの発表です。英文を書く際の機械翻訳はまだまだ精度が低く、"Machine Translation"ではなく"Mad Translation"だと述べ、まだまだネガティブイメージがあると話されました。そこで、多言語を学ぶための、Firefoxプラグインを作成したそうです。書きながら英語の訂正をしてくれるプログラムで、デモを披露すると会場からは感嘆の声が上がっていました。
Ben Hoskingsさん「babushka―test-driven sysadmin for rubyists」
Benさんは、"test-driven sysadmin"をキーワードとして、Babushkaというツールを紹介しました。設定ファイルを記述することで、必要なツールをダウンロードしビルドして、サーバの環境を自動で設定できるというツールで、Cucumberのインストールを実演しました。
Ando Yasushiさん「parse.y の歩き方 -ワシの Ruby は 4 式まであるぞ-」
おそらく今回のLTで最も盛り上がったセッションでしょう！あんどうさんは、まず「人類史上最後のGoogle Wave本」の紹介をし、会場を盛り上げました。本題としてRubyのクリスマスリリースを話題にし、2009/12/25に、parse.yをいじってXMLリテラルを利用できるようにしたXRubyを公開したそうです。また、Objective Cのような記述のできるORubyを紹介し、つづいて、"if then"のthenの部分を"probably"、"maybe"、"perhaps"と指定できるFRubyを紹介しました。FRubyで"maybe"を指定すると、50%の確率で実行されたりされなかったりするそうです:-)
最後に、Rubyが生まれて17年、我々がMatzからもらうのは終わろう、クリスマスリリースは、ユーザが勝手Rubyを作って公開する日にしよう、とまとめました。
Masayoshi Takahashiさん「時を超えた電子出版の道の中を Ruby と歩いていく」
高橋会長のプレゼンテーションは、達人出版会について遠い未来の展望を「社外秘」と言いながら語ってくれました。技術本の寿命が短いという点が説明され、時を超える本を作るためには、少しづつ手を加える必要があるが力尽きてしまうことが多いのではないかということが語られました。
ReViewというレビューツールを開発しており、いくつかの本を作成するなかで利用しているそうです。将来的には、「 githubの文書版をつくりたい」との構想を披露されました。
このレポートも他言無用ですよ！
Tadashi Saitoさん「Ruby Summer of Code 2010 のご報告 ～俺たちの Decimal はまだ始まったばかりだ～」
斉藤さんの発表は、数値演算ライブラリDecimalの開発でRuby Summer of Code 2010に採択された経験が紹介されました。Ruby Summer of Codeは、FLOSSプロジェクトの学生を支援するプロジェクトです。「 いい学生には時間があり、いいRubyistはお金をもっています。いい学生といいRubyistが集まればいいプロダクトができる」と述べ、RSoC、スポンサー、メンターのかたに感謝をあらわし、学生の参加を募集していました。
セッション以外の模様
サイン会の模様（1）
本日から、セッション休憩中に、ジュンク堂書店RubyKaigi店恒例の著者サイン会が開催されています。
Paolo Perrottaさん、角征典さん、まつもとゆきひろさんによる『メタプログラミングRuby』のサイン会は長蛇の列が出きていました。
artonさん監訳の『JavaによるRESTfulシステム構築』のサイン会も行われました。
青木峰郎さん、後藤裕蔵さん、高橋征義さん、まつもとゆきひろさん合同で、『 Rubyレシピブック 第3版 303の技』『 たのしいRuby 第3版』『 Rubyベストプラクティス』のサイン会も行われました。
Chad Fowlerさん、武藤健志さんによる『情熱プログラマー』のサイン会が行われました。
まつもとゆきひろさん監訳の『プログラミングRuby 1.9 言語編・ライブラリ編』のサイン会も行われました。
RejectKaigi発表者を受付中
RubyKaigi直後に同会議場で行われる、RejectKaigi のエントリーボードが設置されました。締切は明日お昼頃とのことです。
懇親会
2日目のセッション終了後には、同会場で懇親会が催されました。今年の懇親会では各自が「自分の会いたい人」が書かれた紙を名札に入れ、もし自分が紹介できる人をその紙に書いている人がいたらその場で紹介するという企画が行われました。また、懇親会の最後には紹介した人数が多い人達にプレゼントが贈られました。
