本日7月16日(土)から18日(月）までの3日間にわたり、練馬文化センター にて日本Ruby会議2011（略称：RubyKaigi2011） が開催されます。本ページでは、1日目の模様を随時レポートしていきます。
スタッフの皆さんは朝から集まり、当日準備が行われました。
スタッフの方は、専用のTシャツ、STAFF腕章をつけていますので、もし会場で困ったことなどがあれば相談してみましょう。
オープニング
実行委員長、高橋征義さんの挨拶
本イベントの実行委員長である高橋征義さんからオープニングの挨拶があり、そのなかで「RubyKaigiは2006年から数えて6回目で、集大成かつ一つの区切りとなる最後にして最高の日本Ruby会議を楽しんでいってほしい」と述べました。
笹田耕一さん「日本Ruby会議2011［+α］プログラムについて」
続いて、プログラム委員長である笹田耕一さんから、これまでのRubyKaigiのプログラムと発表傾向、今年のプログラムが紹介されました。選考方法についても説明がありました。
Aaron Pattersonさん「Ruby Ruined My Life.」
初日の最初のセッションはAaron Pattersonさんによる基調講演からスタートしました。被り物を使うことでも有名なAaronさんですが、今日はスーツ姿での登壇でした。
未来のRuby
「コンニチワ」「 たこ焼き仮面と申します」と日本語での第一声から始まったAaronさんの発表は、まず手始めに「Rubyの未来」といきなりの切り込み。「 PSRuby」と題したその予想は、RubyインタプリタをPostScriptで書けばRubyをプリンタに載せられるため、それによりプリンタの余ったプロセッサを使えるのでは、というもの。実はこれは、まつもとさんが最終日にRubyの未来に語る発表をやる前に言いたいことを言ってしまえ、という本題に入る前の肩慣らしのジャブのようでした。本気かどうか定かではありませんが、2013年夏頃に何かのイベントでこのことについて発表するかも、とのこと。
このジャブに続いてAaronさんが用意したのが「プログラミング道場」という未来予想。柔道着を着たAaronさんともう一人が芝生の上でノートパソコンに向かいながら正座で礼、そのままペアプログラミング、コーディングミスに対する寝技でのお仕置き、といったもので、スライドが切り替わるたびに会場からは笑いの声があがっていました。さらにはムービーまで作る気合の入りようで、楽しいパフォーマンスに本気をかけるいつものAaronさんでした。
Ruby開発とRails開発の比較
会場が温まったところでAaronさんが持ち出したのは、昨年のRubyKaigi2010からの主要トピックであるRubyの開発体制についてでした。昔、Aaronさんが仕事でリポジトリ管理の仕事をしていた頃、ビルドにミスが見つかった時にビルドチームにそれを伝えても「プログラマではないから直せない」と言われ、であれば自分が直すからと話しても「あなたはビルドチームじゃないから」と拒否された悲しい経験を踏まえて、「 境界」という言葉を焦点に話をしていくと言及しました。
Rubyコアチームでは
Rubyコアチームの特徴は、標準ライブラリなどで分野ごとに担当がはっきり決まっていることで、利点は各人が分野毎にスペシャリストになれることを挙げました。例えばAaronさんはYAMLライブラリの担当で、YAMLのスペシャリストになればよい、といった具合です。
欠点として、担当者以外が触ることができず、担当者がいないとその間まったく直すことができなくなってしまうことを指摘しました。また、日本語と英語という多言語で開発していることについて、英語がわからない人は日本語でも貢献できるという点が良いが、英語だけ話すメンバーと日本語だけ話すメンバーで境界ができてしまっている、と言います。
もう一つの問題として、Rubyの一部のライブラリが外部にupstreamのリポジトリを持っていることを挙げました。RubyGemsなどに問題があったとき、Rubyコアチームにお願いしてもダメで、外部のRubyGemsチームに頼まないといけないことを例示しました。
さらに、標準ライブラリが一部がgem化されているものと、されていないものがあり、不統一になってしまっている点も問題点として挙げました。
総じて、Ruby開発はみんなが同じチームなのに「境界」が存在してしまっており、Rubyのすべてに対して触れない、貢献できないという点が話されました。
Railsコアチームでは
対してRailsコアチームでは、分野というものは存在しているものの、コミッタであればどこに対してもコミットできる点を強調しました。欠点としては、Railsの各パーツの「オーナー」がいないため、その部分に対して強い意見を持つ人がいない場合があるということでした。Rubyコアチームが各分野にスペシャリストを置く利点と綺麗に真逆というわけです。
また、Railsコアチームメンバーは全員がリリースマネージャであるため、リリースのスピードは早いものの、リリースに誰も責任を持たなくなってしまうのではないか？という懸念も挙げていました。リリース前に最後までトラッキングしている人間がいないため、例えばバグをバックポートすることをよく忘れてしまう、といったことがあるようです。「 境界」がない故の欠点であり、Rails側からもRubyコアチームにも見習うべき点があるのではないか、という反省を述べていました。
Rubyコアチームへのメッセージ
Rubyコアチームの開発体制へのヒントとして、RubyコミッタでありリリースマネージャでもあるYuguiさんが1.9.3リリースへ向けてruby-coreへ投げたメール（ruby-dev:44055）から「feel free to commit your patch...」という文を引用し、パッチを自由にコミットせよ、という表現が私はすごく好きだと述べました。Railsがずっとこういう雰囲気だったから、こういう空気がRubyにも欲しいとのことでした。
ただしこの自由さには、"feel free to revert" という却下する自由も存在しています。そこで、必要なことはなぜrevert、というコミュニケーションをする責任であり、それこそがRubyコアチームに持ってもらいたいものではないか、と述べました。そうすれば、英語圏の人たちがよく言う「ruby-devで議論を済ませてからruby-coreにアナウンスするのはずるい」という批判も解消していけるのでは、ということを指摘しました。
標準ライブラリの見直し
別の話として、標準ライブラリの見直しを提案をしました。そもそものきっかけはSeattle.rbでのRyan(zenspider)と標準ライブラリについての雑談で、Aaronさんの「なぜminitestをruby trunkで直接開発しないのか」という問いに、Ryanは「いや、（ このminitestは）rubyじゃない。たまたまrubyと同胞した第三者のソフトだよ」と回答を受けたことだと話します。この発言がAaronさんにとっては新鮮な体験だったとのこと。
Aaronさんが言うには、標準ライブラリに必要なのは、つまりgem化だということでした。例えば、net/httpに依存したライブラリを作成していて、そこでRubyをアップデートすると、そのことでnet/httpのAPIが変わってしまえばライブラリが壊れてしまいます。しかし、もしnet/httpがgemであれば、Ruby本体をアップデートしても必要なgemだけをダウングレードして使い続けるといったこともできるようになる、といった利点を挙げました。
Railsプログラマは将来のエキスパート
Aaronさんが日本語を勉強するきっかけはRubyを勉強するためだったそうです。Rubyは日本で生まれた言語というのもあり、日本語でしかないドキュメントや本が多くあることを言及しました。その例として、咳さんの『dRubyによる分散・Webプログラミング』や原さんの『Rubyで作る奇妙なプログラミング言語』などを例に挙げ、日本には特定のトピックに対する本が多いと話します。
アメリカではRubyの入門本や、Rails開発の本が多く、Ruby初心者に対して不親切な状況になっているそうです。偏りの理由として、Rubyはできることがたくさんありすぎて、逆になにをしたらいいのかわからなくなりますが、Railsの本はWebアプリと対象がはっきりしているためとAaronさんは言います。そして、そのような背景からRubyに詳しくないRailsプログラマが生まれてしまうそうです。
とは言え、Web開発が簡単なわけでもなく、Railsの他にもHTML、CSSやHTTP、最近ではCofeeScriptも学ぶ必要があると述べます。ですが、その広い技術のなかから特定の技術について教えてあげれば、その技術のエキスパートになれるとし、Railsプログラマは将来のエキスパートと話しました。
そのためには日本で出版されているような特定のトピックの本があるのが有用とし、アメリカでもそのような本が出版されるとうれしいと述べました。
エンコーディングについて
Aaronさんには文字列のエンコーディングで気になる「仕様」があるそうです。その例としてmysqlのドライバを取り上げ、日本語文字列を取り出すケースを挙げました。日本語文字列をmysqlドライバで取り出すとバイナリ文字列になってしまうため、文字列を連結したときに正しく行なわれないそうです。
エンコーディングの仕様に対してASCII-8BITと他のエンコーディングの文字列を連結した場合には、常に例外を発生させて欲しいと提案していました。
$LOAD_PATHについて
Rubyの$LOAD_PATHについてFile APIを使用したいことも提案しました。そしてrequireの例をあげ、インターネットやSQLiteのデータベースからプログラムが読み込めたらすごいと述べていました。
DTrace対応
以前RubyにDTraceを入れるという話がありましたが、最終的には対応されなかったことについても話がありました。AaronさんはArray Allocationなどの例を挙げながら、DTraceが有用であると言います。DTraceをRubyに入れることはいくつか制限や課題があるとしながらも、対応すべきだと言及しました。
Rubyで人生破滅？
最後に、セッションタイトルである「Ruby Ruined My Life」に触れました。AaronさんはRubyをやる前に元々PerlとJavaを使っていて、Perl6を待望していたとのこと。その頃、上司から「Javaをもっと学ばないと別の仕事を探してもらうことになる」と言われたものの、Javaが嫌いであまりやる気がなかったそうです。そのような時にRubyを見つけたAaronさんは、昼間はひどいJavaを使って、夜だけ美しいRubyを使う生活になったと語ります。Rubyを仕事で使えたらいいのに！と苦しむ羽目になったわけです。
そこで転職を決意し、40％の減給を受け入れてRubyを使うスタートアップに移り、「 人生がハッピーになった！ “ No Ruby, No Life” である。そして“ No RubyKaigi, No Life” である」と述べ、発表を締めました。
"婚活"Kaigi
発表後、突如サイドスクリーンの翻訳用IRCに「以降は翻訳をしないで」という指示が出され、Carl Lercheさん（Yehuda KatzさんとコンビでcarlhudaとしてBundler、Merb等を作り活躍した）とそのガールフレンドのTiffanieさんが壇上に呼ばれました。
これはAaronさんからのサプライズで、CarlさんにはCarlさんの誕生日を理由に壇上に登ってもらい、実はTiffanieさんが壇上でプロポーズするというものでした。Carlさんは壇上での突然のプロポーズに少し混乱した様子を見せつつも、めでたく「yes」の返事。Carlさんだけでなく会場に集まったRubyistたちにとってもサプライズな一場面でした。
CRuby development team「Next version of Ruby 1.8 and 1.9」
午後最初のセッションは、CRubyのコミッターによる今後のRuby1.9、 1.8について語るセッションです。
まずは、Ruby1.8のメンテナである卜部さんより「Ruby1.8.7には未来がない」というセンセーショナルなスライドが表示され、1.8の今後について話がありました。Rubyのメインバージョンは1.9に移り、 1.8.7についてはゆるやかにメンテナンスはされますが、1.8.6についてはKirk Haninesさんが一回リリースをして終了することを宣言しました。
続いて、Ruby1.9.3のリリースマネージャであるYuguiさんの司会のもと、Ruby1.9についてのセッションが行なわれました。まず、Ruby1.9.3の大きな変更点について紹介があり、それぞれの担当者による紹介がありました。
成瀬さんより、ライセンスの話が紹介されました。現在のRubyのライセンス（狭義のRuby'sライセンス+GPL2互換ライセンス）では、GPLv3と非互換になるという問題点があるそうです。そこで、Ruby1.9.3ではGPL2互換ライセンスを切り離し、BSDライセンスから2つのライセンスを選択することで、GPLv2ともGPLv3とも互換がとれる方法を選択したと言います。
BSDライセンスのみにせず、Ruby'sライセンスを残した理由について、「 すべての利用者に説明することは大変なため」と理由を述べました。
続いて、1.9.2のリリースマネージャーであった遠藤さんより、PrivateConstantsという機能が紹介されました。Ruby1.9.2では、定数の可視性をprivateにすることはできません。そこで、private_constantというキーワードが新たに作成したと言います（private_constantが指定された定数の可視性は、privateとなります） 。
class YourLib
class InnerClass
end
private_constant :InnerClass
end
>YourLib::InnerClass
=> private constant YourLib::InnerClass referenced
private_constantで指定された定数はprivateと同じになりますが、今まで通り、オープンクラスでの参照や、Module#const_getにより参照可能なことを説明しました。
最年少コミッタであるsora_hさんは、自身がコミッタになったきっかけであるtest/unitの改善や IO::Write、 String#prependを紹介しました。test/unitの改善として、Ruby開発者が使うテストを並列化で実行できるようにすることで、テストの高速化を実現が行なわれたことが説明されました。sora_hさんが行なった実験（2コア、ハイパースレッディングにより4コアになるマシンで実施）によると、最大で2.7倍の高速化ができたようです。
Linuxカーネルのコミッタであり、Rubyのコミッタである小崎さんより、GiantVMLock(GVL)の改善について簡単な紹介が行なわれました。また、RunPaintRunRunさんが作ったIO::adviseという機能も紹介されました。IO::adviseはposix_fadvise(3) という、ファイルへのアクセス方法を宣言するためのposix関数のラッパーです。Linuxでは、:dontneedを指定することで、ページキャッシュを捨ててアクセスできるようになることを説明しました。
YARVの作者であるささださんより、TimerThreadの改善が紹介されました。
現在、Rubyを実行すると2つのスレッドが実行されます。そのうち一つがスレッドがスケジューリングをするためのTimerthreadであり、海外のMLであるruby-coreでよく消費電力が多くなっているという議論がよく行なわれているそうです。
TimerThreadは10msでSleepから復帰して監視をしているため、停止していたCPUが動き、消費電力が大きくなってしまいます。これをPipeを使うことで、CPUが起動することが抑制されるようになりました。
しかしこの改善はPipeを使うため、Passengerのようなファイルディスクリプタを全部閉じてしまうようなアプリケーションを実行すると、Pipeも閉じられるために正しく動作しなくなるそうです。そのようなライブラリを作成する場合は、CAPIの rb_reserved_fd_p()という関数を使用し、そのファイルディスクリプタを閉じてよいかを確認してくださいと述べました。
発表時間の残り30分ほどは質疑応答の時間となりました。質疑応答では、「 private_constantようなライブラリの開発者にかかわるような機能について、ライブラリ開発者の人にもっとアナウンスや議論があったほうがいい」というライブラリ作成者からRubyコミッタへの意見や、RubyコミッタからRubyコミッタへの質問などが行なわれていました。海外の方からの質問もあり、途中からまつもとさんが翻訳者として飛び入り参加していました。
また、「 Ruby2.0の開発をどこでやるか？」という議論がなされ、以前の結論の通りTrunkを2.0の開発に使うか、2.0用のブランチを用意するかは議論が活発なため、最後は「続きはMLで」という言葉で発表が終了しました。
舘野祐一さん「Rubyを利用した大規模ウェブサービスの開発・運用」
RubyKaigi2011のゴールドスポンサーであるクックパッドの舘野祐一さんが発表しました。クックパッドでは、毎日の料理を楽しみにすること。技術力を通して、たくさんの笑顔を作りたいとの考えのもとにサービスを運営されていることが話されました。
クックパッドを支える技術
クックパッドは、Ruby1.8.7とRails2.3によって動作しているとのこと。料理の画像をAWS（Amazon Web Services）に配置しており、社内で開発を行ったTofuと呼ばれるサーバを介すことにより、「 どのサイズで料理画像を取得してくるか」「 画像を貼り付ける画像はどこか」といった細かい指定を行いながら、画像を扱える工夫が凝らされていると説明しました。
検索には、Apache projectのSolrを使うようになったことが説明されました。Solrを使うことによって得られた利点は、集合を扱ったり、重み付け検索を行える点や、プロトタイプ開発にうれしい機能があり、開発効率が向上したところにあるという話です。
Solrを使うことにより、検索速度が向上したという利点ではないようです。
速度についてクックパッドでは、すべてのwebアプリケーションが200ms以内にレスポンスを返すことを目標にしていると述べます。新しい技術を導入したことで、劇的に高速化するということはなく、定石となっているテクニックをきちんと使いこなすことで200msというレスポンスタイム目標は達成できるとのことでした。
よくRubyやRailsは遅いから他の言語で実装したという話を聞きますが、実行速度が速いことよりも、Rubyが好きなエンジニアが多いのでRubyでコードを書けるということを大事にしていると語りました。
Railsアプリの多人数開発
Railsアプリを多人数で開発するにあたり大切にしていることとして、開発やフィードバック、デプロイのサイクルをいかに早く回すかという価値観を紹介しました。
今まで、Unit test/Functional test/Integration testの中でFunctional testを重視していたのをIntegration testを重視するようになったとのこと。
その理由として、スマートフォン上でもjavascriptを多用するようになっていることから、javascriptのテストを込みにして書くことができるIntegration testが大切だということを挙げました。
そのため、Capybara+Selenium Webdriver+webkitでテストの自動化を行えることは非常に有益であるとのことが述べられました。
また、テスト時間削減のために、テストをリモートで実行していることも簡単に紹介しました。詳細については大江戸Ruby会議01 の発表をご覧くださいと語りました。
Shota Fukumoriさん「Rubyとそのコミュニティと中学生の私」
「技術的な話が聞きたければもう一つのセッションへ行ってね！」という笑顔での元気な照れ隠し？から始まったのが、中学生コミッタsora_hさんの発表です。
sora_hさんは発表全体の構成として「1．どうやって自分がRubyコミュニティに入っていったか」「 2．なぜRubyコミュニティに中高生が少ないのか」「 3．Rubyコミュニティの課題」という3つを挙げ、それらを中高生の目線から語りました。
また発表前には、RubyKaigi用に日本語圏と英語圏の人間がコミュニケーションを取れるよう、Herokuを使ってYubisashi というアプリケーションを作ったことを報告しました。これは英語と日本語の単語や文章がペアになって並んでおり、文を指差しするだけでコミュニケーションを取れるというアイデアアプリケーションです。
sora_h少年とRuby
今ではRubyコミッタを務めるsora_hさんですが、もちろん最初はRuby初心者でした。最初は手探りでrubylang.org からチュートリアルを読みながらコードを書いてみたそうです。最初はうまくRubyっぽく書けず、キャメルケースを使ったり（Rubyはアンダースコアを使ったスネークケースが一般的） 、不必要にreturnを書いたり、eachを適切に使えなかったり、クラスを作るべきところでクラスを使わずグローバル変数を多用したりと、なかなかうまくいかなかったことを実際のコードと共に披露しました。
そんなsora_hさんがRubyコミュニティへ入っていけた一番最初のきっかけは、@pastak 、@rosylilly といった先輩に拾われたから、とのことでした。まずは91世代コミュニティ（1991年生まれのコミュニティ。念のため言及しておきますがsora_hさんは1997年生まれです！）という年上の集団に混ざって活動したのが、最初のコミュニティ体験だったわけです。
もう一つ大きなものが、RubyistのためのVim周辺ツールを積極的に開発したりしている ujihisa さんとの出会いであり、これによりいつの間にかRubySapporoのメンバーになったり、開発版のRuby(trunk)をインストールしてみるように勧められたりしているうちに、RubyKaigi2010ではsora_hさんの書いたパッチがRuby本体に取り込まれることになりました。その後は知る通り、現在はRubyコミッタです。
なぜコミュニティに中高生が少ないのか？
上記までをsora_hさんは「ただの自分語りです」と茶化していましたが、十分に示唆に富んでいるように思います。実際、sora_hさんは「なぜ中高生が少ないのか」という分析の中で、普通の中高生はプログラミングコミュニティに行こうにも周りは大人ばかりで萎縮しがちであり、そもそもシャイだったり、自分から行くのが難しいものだと指摘しました。そして自分の場合は背中を押してくれる人がいたから良かった、と述べています。
Rubyコミュニティの課題
それを受けてRubyコミュニティの課題としては、まず中高生のためのRuby教室のような集まりが欲しい、とのことでした。例としてScratch やSqueak といったものを題材とした教室を開いてる「きょーくり」というプログラミング教室を挙げました。また、島根にはRuby教室の取り込みがあるものの、東京圏その他にも必要であると指摘し、教材についてもScratchやSqueakのRuby版であるhackety-hack がある、と紹介しました。
その他にも、中高生に勧めたほうが良いこととして「Rubyのメーリングリストへ入ってもらうこと」「 コードを公開させること（Github重要） 」 「 ブログを書かせること」「 イベントに参加させること」を挙げ、もっともっと参加できるイベントが欲しい、との言葉で締めくくりました。
Rubyのバグレポートのやり方
発表時間が余ったため、Rubyのバグレポートについてミニセッションが行われました。sora_hさんはコミッタになる前のコントリビュータの頃からRuby開発チームのチケットの整理をしていて（今もしている） 、英語圏の人たちの方がレポートをたくさん送ってくれているといった点を挙げ、「 Rubyのバグレポートのやり方をここで復習しましょう」とバグレポートガイドライン を紹介をしました。
その後、「 ここでこの例外が起こるべきだ」「 ここでこの例外が起きないべきだ」といったことをレポートを書いてもらえると特にありがたい、といったことが説明されました。
質疑応答にて
質疑応答では「バグレポートのやり方」を受けて、「 レポートと言っても、真っ白なテキストボックスが用意されているだけでは、レポートしにくいのでは。報告項目を細かく分けるのはどうか？」という質問に「それはRedmineの範疇なので、YuguiさんがGithubに公開しているコード にパッチを送れば良い」と答えました。
その他に「Rubyや別の言語を学習する上で普段心がけていることは？」という質問にも、「 とにかく書いてみること。言語ごとの流儀を理解するのは最初大変だけど、どんどんGithubなどで公開すれば指摘してもらえる」と答えました。公開していくことに抵抗がない、こういったオープンさが現在のsora_hさんを育んでいるのだな、と感じた発表でした。
Corey Donohoeさん「Shipping at the Speed of Life」
Githubに勤めるCoreyさんによる発表です。CoreyさんはShippingを「リリースすること」と表現し、リリースとはユーザに価値を提供することだと説明しました。
まず、githubでは価値を提供することについてどう考えてるかの説明がありました。github.comではたくさんのユーザがおり、彼らのコミュニケーションを支えるにはgithub.comを健康な状態に保つことが重要だと言います。そのためにはgithub.comで何か問題がすぐに反応できる必要があり、様々なことを計測する必要があると話しました。
たくさんのツール
githubではそのためのツールを自分たちでたくさん作ったそうで、たとえばシステムの状態を見える化するためのツールや、単純作業を自動化するツールなどがあるそうです。また、Ruby on Railsは便利だけども限界があると説明し、他の言語を使うことや、Ruby on Rails自体に機能を足すこともあるそうです。
その他にBrowserMobを使ってパフォーマンスチェックなども行なっているそうです。BrowserMobを使うことで世界中の人達が速度についてどう体感しているかわかると言います。その際にgithub.comは大分速くなったけれど、日本では距離や光回線の限界などの理由からまだちょっと遅いかもとも話していました。今はAkamaiの使用も検討しているそうです。BrowserMob以外にもPingdomも使っているとのことです。github.comはまだまだクラウドに達してないと話しており、まだまだやれることがあると言っていました。Webのパフォーマンスだけでなく、collectedを使ったMySQLの秒間書き込みや、Nagiosを使ったサーバのCPU、メモリなどの状態も監視しているそうです。
github社内でのコミュニケーションではCampfireを使っていると言及しました。Campfireには様々な監視サービスの情報がそこに記録されているそうです。CampfireのAPIを使ったHuBotというものも作り、単純な作業をそこで自動化しており、毎日の開発のサイクルとツールの連携が重要だと述べました。
社内だけでなくユーザとのコミュニケーションも重要であると話し、メールやTwitterなどを使ってコミニュケーションをするそうです。その際にcotweetというツールを使い、社員の誰かが返事した内容に対して再度まちがえて返信してしまわないようにしているとのことでした。
本番環境にはエラーがつきものであると話し、Haystackという社内ツールを作ったそうです。このツールはHopToadに似たツールでアプリケーションで発生した例外をロギングし、例外頻度をチェックしているとのこと。リアルタイムに更新されており、各サービスごとに情報を分けてみれるようにしていることが語られました。そのため、サービスごとに頻度の高いエラーやどんなユーザで発生しているのかわかるとのことです。それにより、例えば発生している例外の対象ユーザが少ない場合、ただ単にそのユーザのリポジトリが壊れているだけとの推測ができると述べていました。
githubでは継続インテグレーションも行なっており、各ブランチの状態を常にチェックしているそうです。ツールはJenkinsを用いており、Jenkinsを扱う中間ツールとしてJenkyというものを作ったとのことです。JenkyはWebhooksを提供し、それを使って先程のHuBotに通知を行なうことが説明されました。
githubではこのようなたくさんのツールを用いて、様々な問題の発見や解決に役立てているとのことでした。
頻繁にデプロイ
githubでは頻繁に機能をデプロイするそうで、1日に20回以上行うこともあるそうです。デプロイはプログラマだけでなくデザイナもできる仕組みにしているとのことでした。デプロイはmasterだけでなく、ある特定のブランチをデプロイできるようにしており、そうすることでそのブランチに問題があってもmasterにすぐに戻せるようになっていることが紹介されました。そのため、パフォーマンステストや実験的な機能のデプロイもできると述べていました。
heavenというライブラリを作り、このライブラリはオプションを指定することでデプロイ先のサーバやブランチを指定できるそうです。このライブラリがあることでHuBot経由でheavenのAPIにリクエストを送り、Bot経由でデプロイできるようになっていると話しました。
他にも、デプロイの機能としてスタッフしか使えないように機能をデプロイするとか、大きめのリリースをしたときにはブログを通してユーザの反応を受けるなどをしているそうです。github.comのユーザは技術力の高い人が多く、彼らの意見を聞くことが大切であることを指摘しました。
総括として常に様々なデータをあつめると便利だと述べ、重要なのはユーザに頻繁に価値を提供することで、そのためには2週間のスプリントでは遅く、もっともっと早くする必要があると話しました。
須永高浩さん「Ruby用のリアルタイムプロファイラ」
東京大学大学院の須永高浩さんがリアルタイムプロファイラ の紹介とデモを行いました。
「プロファイラって使っていますか？」という質問から、このセッションは始まりました。
Rubyにはruby-prof というプロファイラがあります。しかし、ruby-profはプログラム終了まで待たないと結果が分からなかったり、オーバーヘッドが大きいと問題点があると述べます。そこで、須永さんはリアルタイムに情報を得ることができ、オーバーヘッドが軽いリアルタイムプロファイラを開発されたそうです。
リアルタイムプロファイラを実行すると情報サーバを起動され、ブラウザで実行結果が表示されます。特徴として、実行されている状況がグラフィカルに表示され、実行しているモジュールの大きさが面積で表現され俯瞰することが可能であることを挙げました。また、プロファイル結果をグラフとして見ることができるとのこと。
具体的には、このプロファイラには、5つの特徴があることが示されました。
リアルタイムに結果を見れる
別プロセスで起動される
Webブラウザで結果が見れる
関数呼出しのコンテキストを含めてプロファイル結果を見れる
オーバーヘッドが低い リアルタイムプロファイラを使用したプロファイルの事例紹介として、Arrow という須永さんが作成したWebサイトでプロファイルを実行した結果を紹介しました。ArrowはPythonで構築されたWebサービスですが、リアルタイムプロファイラが言語非依存のプロファイラのであり、簡単な修正で確認することができたそうです。また、Webサービスをプロファイルするために、以下の機能追加を行ったことが補足されました。
プロファイルしたい場所を指示する機能
多数のプロセスから情報を集約する機能 プロファイリングは、 Webサービスを動かしながら行なったそうです。そのような簡単な分析だけでも、多くの問題点に気付けたという結果を紹介しました。
最後に、リアルタイムプロファイラの今後として、いろんな言語への対応や、いろんな情報をプロファイルできるようにし、「 汎用的なプロファイラ構成用フレームワークにしたい」と構想を語り、発表が締め括られました。
Andy Delcambreさん「Toggleable Mocks and Testing Strategies in a Service Oriented Architecture」
冒頭で日本語のわかる人は手を上げてください、という質問から入ったEngine Yard社のAndy Delcambreさんの発表です。
まず、Engine Yard社でもサービスの提供を行なっているSOAの説明から話が始まりました。
単一責任の原則（UNIXの哲学）
それぞれの部品を別々にデプロイできる
複数のチームが異なるサービスロ開発できる Engine Yard での提供している形態では、複数のSOAサーバとその中心に置かれているユーザ情報を提供するSSOで構成されていることを言及しました。これにより、他のサービスがユーザの概念について知らなくても開発に専念できるという利点を挙げました。しかし問題点として、周囲のSOAのテストが大変である、と告げました。
まずはmockを使わない例の話を取り上げました。開発サーバに対してテストを実行する際に、開発用のSSOサーバへアクセスすることで比較的簡単にテストが可能ですが、これは致命的な問題点があり、遅いということと、テストが始まってしまうとオブジェクトの状態を戻せないという欠点を挙げました。
そこから、モックやスタブを使った場合にどのような利点があるか、という話が紹介され、スタブのライブラリの話へ移りました。
FakeWebというライブラリは「まぁまぁ悪くない」と表現するAndyさん。しかし、まだ十分ではありませんと続けました。
そしてartifice というライブラリを紹介しました。このライブラリはRackアプリケーションをnet/httpのスタブとして使うことで、HTTPレイヤーのテストを実行しているそうです。
artificeは環境設定の切り替えで、テスト環境のレイヤーの切り替えができるため、インメモリでスピードを重視したテストとインテグレーションテストの切り替えをソースコードレベルで変更せずに実行できると述べました。
質疑応答
質疑応答では、「 正常系以外の、エラー系のテストはどのようにしているのか」という質問が出され、Andyさんは「だいたいのテストはフェイクにエラー状態を用意することでテストに使いますが、できないところはユニットテストでカバーしています」と答えていました。
池原潔さん「組込みシステムのための動的コンポーネント機構とVMの最適化」
日立製作所の池原潔さんは、組込みシステム向けに、主に省メモリを目指してRuby本体に手を加えてみたという話を発表しました。なぜそれをしようとしたかの背景の話から、アプローチ方法、そして結果と順を追って説明しました。
なぜ組み込みでRubyなのか
まず背景となる事実として、近年は多くの組込みシステムがインターネットに接続するようになってきたことを挙げました。このような流れに対して、組込みシステムのほとんどでCコードが使われているが、文字列処理を書くのも苦労するCで、変化の激しいWebの世界に追いつくには生産性が十分ではないのでは、という実情を述べました。そこで、組込みでもRubyを使ってWebベースで作れたらいいのでは？という発案が今回の試みへ至る発端のようです。
ただし、Rubyを組込みに使うと言っても、組込み向けVMにはそれなりの要件があるとのこと。
1．メモリ効率が良いこと。多くの機能が搭載されるようになってきている組込みにおいて、メモリは貴重なリソース。
2．メモリ管理が正確でなければならない。
3．実行速度が十分速くなければならない。組込みのプロセッサは貧弱で、処理のオーバーヘッドも大きい。 この3つの内、最も組込みシステム特有な問題である「1．メモリ効率」にフォーカスすることにした、ということでした。そして、メモリの消費量を抑えるためにアプリ側とVM側という2通りのアプローチを取ることに決めたそうです。
アプリ側からのアプローチ
Rubyによるメモリ消費傾向の調査・検討のサンプルには、比較的シンプルで分かりやすいという理由でSinatraを選択（RubyはCRuby1.9.2） 。Sinatraを（Sinatraに限らず、ですが）を複数起動すれば、各VM毎にソフトウェアスタックが構築され、結果としてメモリ消費量は起動した分だけ嵩んでいきます。しかし、複数起動されたプロセス同士には似たデータがロード・インスタンス化されている部分があることが推測されると指摘します。
この無駄を解消する方法として：
1．Dynamic Component。複数のアプリケーションを単一のVMで実行する方法（最も効率的）
2．Multi-taskingVM。アプリケーションを個別のVMインスタンスで実行する方法（コードと資源の共有）
3．Inter-process Sharing。共通するコードをVMプロセス間で共有する（最も基本的） の3つがあり、今回は1番の動的コンポーネントを選ぶことにしたそうです。理由として、効率を求めたかったことと、2番や3番は静的なJavaなどと比べてどういったものが共有できるかわからずコード化が難しい、といった点を挙げていました。
そもそもコンポーネントとは、他者の機能を使ったり、他者に機能を提供したりするソフトウェアモジュールのこと。動的コンポーネントでは、文字通り実行時にコンポーネントを動的にリンク・アンリンクします。具体的には、コンポーネントフレームワークという物が各コンポーネント間のインターフェースを認識し、ソフトウェアスタック構築時に既にあるコンポーネントから選択してリンクしてくれる、といった仕組みのようです。Sinatraで言えば、自分のアプリ・Sinatra・Rackという組み合わせが複数回構築されても、コンポーネントの重複を生むことなくメモリを無駄にせず接続されるわけです。この動的コンポーネントの実装の結果、サーバを2つ起動させた場合でCRuby1.9.2と比べ4.8MiBのデータが削減が確認されたそうです（サーバ1つを単に起動させた場合、メモリ使用量は9.2MiB） 。
VM側からのアプローチ
もう一つ、VM側からのアプローチとして、VMに使われているデータ構造の最適化を試したとのことです。まずValgrindでCRuby1.9.2と1.8.7を比較してみたところ、1.8.7に比べて1.9.2はかなりメモリを消費しているように見えたそうです。これは1.9.2の方には速度を稼ぐためにメモリを消費させている部分があるからで、そこを削っていけば（速度低下を招くものの）メモリ消費が減っていくことが確認できたそうです。
具体的にはDirect Threaded Code用の命令列の生成を抑制したり、命令列を短くすること、命令に付随する余計な情報を削除することなどを試したとのことです。発表では特に命令列を短くする方法を取り上げ、使われる命令の中で比率の高い"send"と"trace"命令を特殊化したショートバージョンを作った、という手法を紹介していました。VM側アプローチ全体として、先述の状況で約2MiBの改善を見たとのことでした。
最後に、今後の課題としてオープンクラスと動的コンポーネントの相性問題や、保護ドメインのためのアクセス制御が難しいと言った点に触れ、発表を終えました。
VM作者、ささださんとの対話
質疑応答では、Ruby1.9のVMであるYARVを開発した笹田耕一さんとのやりとりがありました。「 速度のために命令列を4バイトにしているのはその通りで、命令列を小さくすることも研究しているのだが、実際に小さくすることでキャッシュ効率は上がったか？」という笹田さんの質問には、マイクロベンチマークレベルでは効果があったという回答をしていました。また、動的コンポーネントのところで出てきた他の選択肢であるInter process sharingは笹田さんも「実際にやろうとしている」など、RubyVM作者からのレスポンスが見られた発表となりました。
相澤歩さん「Issues of Enterprise Rubyist～SIerのなかのRubyistが考えるべきこと～」
RubyKaigi2011 実行委員の1人でもある相澤さんの発表です。相澤さんは、いわゆるSEとして働いているのですが、そんな中でRubyとの出会い、仕事場にRubyを持ち込むために行ったことを話しました。
そんな中で、具体的に紹介したいこととして、以下の2つを挙げました。
Rubyと出会って3年間で経験した課題
もし同じ境遇の人がいたら、考えてほしいこと Ruby との出会い
当初、相澤さんはRubyという言語は知っていたけれど、エンタープライズで使うようなものだとは考えていなかったそうです。しかし、参加した Rails勉強会@Tokyo で、同じようなエンタープライズ領域でRubyを使っている、エンタープライズRubyistと出会ったことで、その考えを改めたと語します。
ここから実際にRubyを学ぶフェーズに入り、Rubyを実際に社内で広めるために、有志による分科会を作り、Rubyが使える仲間を増やしていったそうです。
続かなくなりそうなこともあったそうですが、個別にその要因に対処していくことで、今でも分科会は続き、Ruby技術者認定試験合格者が10人にものぼると述べました。
続かなくなりそうになった原因と、対応策について、以下のように話してくれました。
興味本位でやったけど、忙しい
短い時間で終わらせる。一回で完結するようなテーマにする。
仕事に直接役に立たない
プログラミングに対してそこまで関心が高いわけではない
Ruby を仕事で使う
「仕事での小さなスクリプトにRubyを利用していても、あくまで個人の範囲を越えない。コミュニティーのパワー等をビジネスの価値にできないだろうか？」という問いを2009年のRubyKaigiで角谷さんの発表の質疑応答でしたところ、「 それは相澤さんの仕事なんじゃないでしょうか」と回答されたと振り返ります。
回答された直後は意味を飲み込めていなかったそうですが、数年後、どのように社内でRubyを案件に取り入れようかと、Rubyが案件にマッチするかを調べて、マッチしなければその他の最適なソリューションを選択するということをしていて、これは普段相澤さん自身の仕事として行っている、SEの仕事と変わりはないということに気がついたそうです。
最後に、「 3年間に自分が経験した様々な課題がありました。あなたが経験する3年間にはあなたの課題がある。その答えを見つけるのは、あなたの仕事ではないでしょうか」という言葉で発表を締め括りました。
軽量Ruby開発チーム「軽量Ruby」
経済産業省の地域イノベーション創出研究開発事業の一環である軽量Rubyの発表セッションです。
まず、福岡CSKの岡部さんより、プロジェクトの全体について紹介がありました。日本の組込みの業界には現在26万人の開発者がおり、高信頼性が求められる分野であることに触れ、「 軽量Ruby」とは、そのような組込み開発にも適用できる改良された軽量なRubyを作成する研究開発であると紹介しました。組込み分野でRubyが使用できるようになることで、高品質、低コストという要求に対応できるようになることが目標だそうです。
軽量Rubyでは、コンパイラやライブラリ、仮想マシン(VM)を組込み開発向けに軽量にすることで、組込み開発にも耐えうるRubyにすることを目指していると話します。また、Rubyチップと呼ばれる、軽量Rubyが実行されるマイコン、リアルタイムOS、 軽量RubyのVMをFPGAにしたチップを作成することで、より安価で高速な機器を提供することも目指しているそうです。
軽量Rubyの今後として、7月末に最小の機能を実装したα版、9月末にβ版をリリースすることが予定されていることが告知されました。また、10月からはいくつかの企業での評価検証を検討しており、現在は、3社ほどの組込みメーカーで実施されることが決定されているそうです。この研究開発は2012年の3月に経産省のプロジェクトとしては終了するため、その後はオープンソースとして公開したいという構想を描いていると述べました。
続いて、軽量Rubyの開発者である、まつもとさんより軽量Rubyの実装について解説が行なわれました。
軽量Rubyは、CRubyとは以下のような大きな違いがあると言います。
RubyのVMとして新たに開発しているRiteVMを採用
コマンドは'ruby'ではなく'mruby'
軽量RubyのためのCAPIにつくプレフィックスは'mrb_' 軽量Rubyは、CoreやMinimalと呼ばれる実行するために必要になる箇所についてはC99のみに依存するように書かれ、またRubyのJIS規格であるJIS X 3017にあたる箇所については、POSIX範囲内で実装されているため、高い移植性が実現されていると言及しました。
また、組込み分野ではリアルタイム性というのが重要になっていると語り、軽量Rubyでリアルタイム性を実現するために、CRubyのGCではなく、IncrementalGCやGenerationalGCが採用されていることを説明しました。
次に軽量Rubyの開発方針を紹介しました。軽量Rubyでは、コンパイラの機能や仮想マシンの機能、補助ツールをコンポーネント化することを目指しているそうです。コンポーネント化することで、必要な機能のみを組み合せた新しいRubyを作成できる（例えば、コンパイラ機能を外したevalの実行できないRuby等）と紹介し、「 ナニスル？」というスライドを提示し発表を終了しました。
田辺浩介さん「日本の図書館はどのようにRubyを使っているか ―「Next-L Enju」と「国会図書館サーチ」」
慶應義塾大学とオープンソース図書館システム開発プロジェクト Project Next-Lに所属する田辺浩介さんによる発表です。
オープンソース化された図書館システムの事例紹介から始まり、自らがRailsで作製した図書館システムについての話や、Rubyで作られたシステムの事例について語りました。
Next-Lプロジェクトについて
Next-Lプロジェクトは、図書館関係者で図書館システムをつくろうという意志のもと結成されたものであり、田辺さん自身は結成当時からずっと開発に携わっていると言います。
なぜNext-Lプロジェクトで、Enjuを作ろうと思ったのか
職場の図書館がシステム化されておらず、すべて紙での処理に嫌気が差したため、自分で図書館システムを作ることを決意したのがきっかけと語ります。最初はPHPで作り始めましたが、うまく動作しないために挫折してしまったとのこと。そしてWebフレームワークという便利なものがあることを知り、Railsに出会ったとのこと。
『ライド・オン・Rails』という書籍で全文検索を知り、図書館システム実現への大きな一歩となりました。『 ライド・オン・Rails』に掲載されていたPostgreSQLやMySQLを使い、全文検索を実現するサンプルが期待通り動いたためRailsで製作することを決意したと振り返ります。
また、図書館システムと検索機能の間には特殊なつながりがあると言及しました。これは、利用者向けには簡単に使える検索機能を提供し、司書向けには複雑な検索機能を提供するという要求があるからとのこと。
例として利用者向けの検索インターフェイスとしてGoogleの検索窓を、司書向けの検索インターフェイスとして、実際の図書館システムの検索インターフェイスを示しました。
Railsを使っていてよかったこと
RailsのよかったところとしてRestfulであることを挙げました。新着資料のRSSなど、RestAPIを備える図書館システムが増加しており、図書館システムの方向性とマッチしていたという背景があったそうです。
構築で苦労した点
苦労した点については、画面表示が遅いことを挙げました。職場の蔵書数が少ないことから大規模なシステムになることは想定していなかったのですが、あっという間に重たいシステムになってしまった過去があったそうです。この時は、テンプレートキャッシュを用いることで画面表示の遅さを解消したという話です。
事例紹介
物質・材料研究図書館や笹川スポーツ財団へNext-L Enjuを導入した事例を紹介しました。
また、Rubyを使用した図書館システムは最近になって出てきたように見えますが、実は10年程前から事例が存在することを挙げました。
神戸市図書館情報ネットワークでは、公共の図書館と大学の図書館を一緒に扱うシステムを保有しているのですが、実は公共向け図書館業務と大学向け図書館業務を一緒に扱えるパッケージは存在しなかったそうです。そこで、神戸市図書館情報ネットワークでは47万人のユーザーをRuby1.8.5とgtkで作ったインターフェイス、Oracleなどで支えていることを紹介しました。なぜRubyを導入したかと言うと、多少の改修であれば図書館員が自ら行えるように、日本語のサポートを受けられる言語でかつ可読性の高いRubyが選ばれたとのことです。
なお、この神戸市図書館情報ネットワークの動作デモ動画が上映されたのですが、図書目録機能はEmacs lispが使われており、おもむろにEmacs上にて業務を行う様子が上映された際には、会場からどよめきが起こりました。
nariさん「CRubyGCの並列世界」
CRubyコミッタのnariさんによるGCの並列化の発表です。現在のCRubyのGCはコアを一つしか使わないようになっているそうです。WALL-Eの画像を表示しながら、大量のゴミを一人で集めるのは大変であり、問題があると述べました。その解決策として、並列にGCを行なえば効率化できるとのことです。
マーキングを並列に
現在のCRubyのGCはマーク＆スイープというアルゴリズムを採用しており、このアルゴリズムはルートを辿って生きていけるオブジェクトに印つけ（マーク） 、マークついてないのを削除（スイープ）するというものであることを紹介しました。特徴として、シングルスレッド実装なので、Stop The World、つまりGC中は他のスレッドはすべて停止してしまうことを挙げました。
最近のマシンはマルチコアがあたりまえになっており、GC中に他のコアが遊んでしまうのは問題だと言います。CRubyはGVLがあるので一コアになっていますが、GCまで一コアにする必要はないと言います。
今回nariさんが実装したGCは、マーク＆スイープのマークの部分を並列に行なうそうです。この際にネイティブスレッドを利用しているとのこと。そして4コアぐらいから効果を発揮するのではないかと紹介しました。GC中のStop The Worldは変わらないらしく、シングルスレッド同様、GC中はアプリケーションスレッドはすべて停止するとのことですが、マーキングを並列に行なう分スループットの向上が望めるそうです。マーキングだけを並列にし、スイープにしない理由は笹田さんの調査の結果、スイープはそこまで遅くないというのが分かっているからとのことでした。
実装内容
実装の内容として各スレッドへの仕事の分配方法とLock-Freeについて説明しました。仕事の分配はルートから生えている枝葉に対して個別にスレッドを割り当てていくと、枝葉の大きさに偏りがあった場合に小さい枝葉のスレッドから仕事が終わってしまうため、結果的にコアに遊びができてしまうそうです。そこで、手が空いたスレッドは別のスレッドからタスクを盗んでくるTask Stealingという手段を採用したとのことでした。Lock-Freeはスレッドがロックせず進行が保証されることですが、nariさんはアムダールの法則を持ち出し、なぜLock-Freeが重要かを語りました。
具体的な実装については、Rubyによく似た疑似コードを用いて主にLock-FreeなThe deque（topとbottomを持つデータ構造）について説明しました。この実装でベンチマークをはかったら実は通常のGCより遅くなってしまったそうです。理由としてはdequeに実装されているpop_bottomなどの処理コストが高く、並列しても補えないコストになってしまったためとのことでした。そこで、dequeの各要素を固定長スタックにしたところ、今度は総GC時間が30％減ったそうです。
速度は上がったものの、まだいくつか問題があるとし、メモリの使用量が増えてしまったことや、SEGV、Windowsで動かないこと、テスト環境がないことを挙げていました。
最後に発表のまとめとして、並列GCはnariさんの手持ちの環境では一応改善したと改めて述べ、今まではRubyKaigiにあわせて一年に一つGCを実装してきたがRubyKaigiは今年で最後なのでGCの実装も今年で終わりかもと話していました。
江森真由美さん「Rubyで作った "critical mission" システムについて」
大江戸Ruby会議01でもお話をしてくださった江森さんの発表です。
江森さんとRuby
2004年に、仕事の都合でRubyを使う必要が出てきました、という出だしから始まりました。当時のRubyのバージョンは1.6.8だったそうです。
Rubyでの開発として、
CGIkit
Ruby on Rails1
等を使用していたと振り返りました。 mission criticalなシステム
mission criticalなシステムの定義として、
上記の条件で可動し続ける、ということを挙げました。
また、江森さんのケースでは、デーモンの開発をしたとのことです。
2004年の段階ではプロトタイプとしての開発だったそうですが、Rubyが起因しているものやそれ以外のもの含めて様々な問題に出会ったそうです。
ファイルディスクリプタの上限値の設定数が足らず、1,000プロセス立ち上がらない問題や、UDPのTimeout処理を実装しようとしたところ、Timeoutモジュールではうまく実装できず、組込み関数のselectを使用した、という話を紹介しました。
また、Thread が突然止まってしまう問題を解決するため、ヘルスチェックを行い、応答が無かったら再起動させる仕組みなども作ったそうです。
2009年のリニューアルを行う際には、計算処理が追いつかない部分をC言語で実装することになった点や、3種類だけだったプロセスが230種類に増えてしまったことに対して、Rubyで開発していてだいぶ楽に開発が進められた、という話を紹介しました。
最後に、Rubyで開発していて良かった点として、
直感的なプログラミングができる
UDP/TCPといったソケットプログラミングが容易
シンプルに記述できるので、その分バグの混入の可能性が少なくなる
異常系や無限Loopのテストも比較的楽に実装できる と言ったことを挙げました。最後に、「 大規模システムでもRubyを使えてます」とアピールをして発表を終えました。
ささだこういちさん「並列世界のRuby処理系」
一日目の小ホール最後は、YARVの作者であるささださんの発表です。ささださんは、発表の冒頭でDaveThomasの言葉である「FORK RUBY」を言葉をだし、Rubyがどうあると楽しいかを語りました。
昔は、SmalltalkやC++、Rubyで実装されたRubyができるなんて、誰もが思っていませんでした。また、RubyのJIS化なんて不可能だと思われていました。RubyのVM化や型推論、GCの並列化など想像もできませんでした。当然、昼間の仕事してRubyのプログラミングや、Rubyのコミッターが仕事として成り立つとも思えない状態でした。しかし、ここ10年で状況は変わり、これらのことは実現されていると言います。
10年前では夢のようなことが現実になった今、Rubyに対してこれからどのようなことができるかということを、実際の研究事例を交じえて紹介しました。
まず行なえることとして、スピードの改善をあげました。Ruby本体に対する改善として 、VMがコードを処理する際に、簡単な解析をすることでオブジェクト作成を抑制し、高速化を狙う手法を紹介しました。また、Rubyアプリケーションの速度向上のため、Rubyのコードに型情報を付与することで、半自動的にCのコードに変換して高速化を図るやり方を紹介しました。このやり方は、ささださんの研究室の学生が研究をしており、RDocを対象として実験したところ、2割の高速化に成功しているそうです。
また、マイクロソフトの支援のもと、64ビットWindows用のRails環境NougakuDo を使用し、マイクロソフトのOS上での性能の改善が行なわれていることが報告されました。
スピードの改善のターゲットとして、GCも対象であると言及しました。GCの手法として世代別GCを導入したいが、今作られているC拡張との兼ね合いで導入するのが難しいと述べました。GCの手法変更による改善以外に、GCに対してはデータ構造やVMのエスケープ解析を行なうことで速度改善が見込めるのではないかと提案しました。
使用されるメモリ量の削減として、Rubyの内部リソースをシェアし軽量化することや、電力消費量の削減として、午後一のセッションで述べていたTimerThreadの改善だけでは不十分なため、もっと改善をしたいと意欲を語りました。
また、Rubyプログラムのポータビリティを高めるため、一度Rubyコードコンパイルし、メソッド毎に共有ライブラリ化するという、現在行なっている研究の紹介がありました。
最後にできる改善方法として、並列化について、MVM(MultiVM)という手法を紹介しました。MVMは、一つのプロセス内に、複数のRubyVMを起動させ並列プログラミングの性能改善を狙う手法です。VMごとのデータ通信にはChannelというものを使用することで、VM間でデータを送りあう際にオブジェクトを作成しなくてすむとのことです。実際に、データベースへアクセスするアプリに用いた場合、MVMを使ったRubyだと、旧来のRubyでforkとTCPによる通信を使った方法より性能が改善されたそうです。MVMの将来への構想としては、同一プロセスだけでなく、違う計算機ノードで複数のプロセス間もChannelで通信できることを実現したいと述べていました。
最後に、ささださんは「Rubyは15年かけて良くなってきたけど、まだまだやることがある。私たちは、どうRubyをよくできるかを日々研究している。もっとよりよりRubyを作れると思っている」と述べ、発表を終えました。
闇RubyKaigi
本日20時から、闇RubyKaigi が行われます。18時20分に発表当選者とそのタイトルが発表されました。
プログラム開始前、サイドスクリーン上ではIRCでの発言が黒背景になることから、IRC上で空白を打ち込んでサイドスクリーンを黒で埋めることで盛り上がりました（それに対抗して白背景で表示されるTwitterの「光あれ」といった発言や冗長な空白の打ち込み発言が行われていました） 。
基調講演：tsuyoshikawaさん
日本の情熱プログラマーtsuyoshikawaさんによる基調講演では、自身のプログラマ歴が闇の歴史だったことが語られました。闇の歴史を語り終えてようやく光サイドの話になるところで時間切れとなり（基調講演なのに6分の持ち時間でした） 、「 俺達の闇RubyKaigiはこれからだ！」という言葉を残して闇（袖）に消えていきました。
@yuri_at_earth, @chihayafuruさん「ETロボコンRuby化計画 -Rubyでロボット制御-」
ETロボコンに携わっているRubyistの@yuri_at_earthさん, @chihayafuruさんによる発表です。WebサイトをXOOPSからSinatraに変更したこと、Ruby-NXTを使ってPC側でETロボコンを制御しようしたけれども破たんしたことことが語られました。軽量Rubyに期待しているそうです。
とくめいキボー（ko1）さん「紅い巨塔」
とくめいキボーさんは、Rubyコミッタの世界について発表しました。生態域、人物早見表などをピラミッド構造で示しました。詳細な自物早見表の解説では、各人物に二つ名がついており、会場の笑いを誘いました。
@ya_ma23さん「ZENPRE de PRESEN」
@ya_ma23さんは、Ustreamのストリーミング映像と事前にアップしたスライドをあわせて表示できるWebサービス「ZENPRE」を紹介しました。デモを行おうとしたところ、上手くいかないという、残念な結果になりました。最後に、ZENPREはRubyで作成されていることをアピールしていました。
だんさん「だとうtDiary メンバーぼしゅう!!」
tDiaryにいくつか不満があってtDiaryに代わる日記システムを作成しており、興味のある人はぜひメンバーになってほしいと語る、だんさん。今回は、この取り組みの歴史を語りました。最近は、HTML＋JavaScriptで書かれているpipinという日記システムを作っているとのこと。
@ywindish「あなたの話がききたい。」
@ywindishさんは、最初に触ったプログラミング言語はVisualAgeで、その後VB、ASPと渡り、孤独な感じだったけれども、現実にRubyistという人が存在し、闇や孤独ではなくなかったと話します。人にはそれぞれRubyとの出会いがあるので、それを聞きたいと述べていました。
@yuumi3さん「Ruby Port」
@yuumi3さんから、RubyKaigi非公式ドリンクRuby Portについて説明がありました。PortクラスのサブクラスであるRuby Portは、ポートワインの一種であることが滔々と述べていました。また、Portの楽しみ方も紹介されました。
かずひこさん「名付けRuby」
かずひこさんから、Rubyを使って、子供の名前を実際に利用した名付けた方法が紹介されました。ランダム、一文字、「 読みは3文字」などのルールを決めていったことが説明されました。なお、まずはリア充になる必要があることが補足されていました。
@auastro、@jonochangさん「GO for Rubyists」
プログラミングを開始するまで幽霊を信じていなかった、@auastroさん。コード中に悪霊がいそうな時こそブラックマジック「VOODOO Driven Development」が必要だと語り、VDD! VDD!と会場一体となって唱えました。大爆笑でした。
@joker1007さん「カラオケのためのRails」
@joker1007さんは、カラオケにかかせないものとして、ニコニコのボーカロイド曲を挙げます。そこで、リモコンプログラムを作成して、実際にニコニコ動画のボーカロイド曲を表示させてしまうデモを紹介しました。
@tmaedaさん「牛乳少女用 CMSを作った話」
@tmaedaさんは、別海ミルクガールズがいる北海道別海町の情報発信サイトの制作依頼を通して、地域情報のハブ「ろはぶー（Local+Hub） 」という仕組みを作ったことを紹介しました。
@udzuraさん「Railsダークサイドにおちいった人のためのSinatra/Padrino」
@udzuraさんは、Railsは機能が多いけど大掛かり過ぎる、Sinatraでは物足りない時があるというときに、Padrinoというフレームワークを知ったことを述べました。Padrinoのコンポーネントは、Sinatraアプリに一部機能だけをregisterして使えるそうです。
@ssig33さん「なるほど四時じゃねーのとRuby」
自作した、なるほど四時じゃねーのは迷惑なツールでしたと語るssig33さん。Rubyでの高速なHTTPアクセスが売りだということですが、スレッドが180並列を超えるあたりから異様に不安定になるため、スパマーはRuby以外のツールを使うのがよいと論じました。
@shunirrさん「facebook irc gateway」
@shunirrさんはfacebook irc gatewayの基本部分を作ってgithubで公開したところ、太麺仲間たちが猛然と改良して3日で完成したそうです。その際、いろいろ勝手にコントリビューターにしたときのメリットとデメリットを語りました。
id:secondlife「あなたの知らないREEの使い方」
id:secondlifeさんは、Ruby Enterprise Editionについて知っているかを聞いて回ったそうです。正解は、メモリバカ食い設定にしてしまい（≒GCタイミングを少なくすることで） 、提供するサービスの速度を早くすることを指すそうです。実際のグラフ（マジック）を交えつつ解説しました。
アジャイルUCD研究会「日本初!?アジャイルUX"公開実演"プロジェクト Agile UX Live!」
ここで闇RubyKaigi当選者の発表の中休みが取られ、イベント期間中に会場地下にある第二リハーサル室で開催されている「Agile UX Live!」が紹介されました。
りんむーさん「某SIの研修部門でRubyの研修コースを作ってみただけどあんまりお客さんはいらなかった件」
りんむーさんの作った研修コースで、4年間で育成したRubyistの数は20人くらいだったと述べます。この経験を踏まえ、Rails3で開発しているスタートアップに転職し、毎日Rubyを書けて幸せになったことが語られました。
kwappaさん「宝石の中の小石ひとつ」
kwappaさんは、朝令暮改、仕様変更、伝言遊戯、残業代無の職場でRailsを導入することでアジャイルなチームになり、光を見たチームメンバーは誰もいなくなったことを紹介しました。しかし、皆さんのチームに光あれ、すべてのチームに光あれ、と説きました。
みかよしゆきさん「気付きやすい通知」
みかよしゆきさんは、Autotest::Screenの結果が小さくて見づらいため、これを解決するためにSW Notifierを作成したことを紹介しました。スターウォーズのオープニングで文字が流れていくシーケンスに似せて作成したSW Notifierでは、とても大きく表示されていました。
†Zonu†さん「美しいRubyと私（それと闇プログラミング） 」
今年はMatzとYuguiさんが講師をされるというセプキャン（セキュリティ＆プログラミングキャンプ）が紹介されました。来年のことは分からないが、仕分けされてなければ一年後に皆さんも応募してみてほしいと案内しました。
jugyoさん「ライフハック」
jugyoさんの発表は、持ち時間の半分以上をディスプレイを表示できないというトラブル（ネタ？）で潰してしまいました。ディスプレイが繋がった後、irbが好きなので作ったというir_bについて紹介しました。相当早回しで解説することで、時間内に収めることができました。
Masaさん「ODBA（Open Dababase Access, Object cache library）の紹介」
スイスからきたMasaさんは、スイスのドラッグデーターベース（ch.oddb.org） 、そこに柔軟にアクセスするために作成したODBA（Object DataBase Access）を紹介しました。
匿名希望
匿名希望さんの発表が行われました。
Tatsuya Satoさん「割と大きな会社の中心で「楽しい開発を」と叫んだ獣」
紅い光がさしていた頃は、社内RubyKaigiなどを開催していたというTatsuya Satoさん。しかし、Rubyist達はできる人たちだったので、駆り出されてしまったとのこと。その後、PHPerになってしまったと言います。現在は社内RubyKaigiを復活させるために動いているそうですが、その光はまだ射していないそうです。
tomykairaさん「Rubyで作るメテオ」
tomykairaさんは「ツイートおおすぎ、働け」と持論を展開します。このパワーを「けしてやるメテオで」という想いに変換し、そして作られたのがTwitter TL Filterです。結果、25％とツイートが削除されたそうですが（#4sqや#NowPlaying、#shindanmakerなどのツイートは特に不要とのこと） 、特に問題ないと述べました。
@no6vさん「きんつばスイーツの会」
美味しいきんつばを食べることを趣旨に活動しているきんつばスイーツの会。RubyKaigiとの関係性、どのようなスイーツが持ち寄られるかが紹介されました。また、関西弁Ruby会議？についても開催が提案されていました。
山口泰宏さん「Rubyの入口でいきなり闇と立ち向かう」
まだRuby丁稚程度であるという山口さんは、2003年当時にVB6を研修で習いVB.netの仕事に従事し、その後もタスクを消化する日々だったそうなのですが、今年に入りRubyと出会ったとのこと。VBで目が死んで、Rubyに触り始めてちょっと生き返ったことを語りました。
u16suzuさん「A Rubyist in a GeekHouse ～Rubyと私～」
スライドが表示できなくなってしまったu16suzuさんの発表は、ギークハウス武蔵小杉の紹介です。ギークハウス武蔵小杉のテーマはビジネス志向だそうですが、住人の半分以上は定職に就いていないとか。訪問すればインドカレー食べられたり、ギー杉たんbot（ゴミの日をつぶやいてくれたりする）があることを紹介しました。
なかしまけんいちさん「賞金100万円！フクオカRuby大賞」
昔、家のお金で30万円で宝くじ買ったら3,000円しかあたらなかったというなかしまさんより、賞金100万円が1/80で当たるという夢のような話が紹介されました。それはフクオカRuby大賞です。厳選なる抽選ではなく審査で決めるけれども、ぜひ応募してほしいと呼びかけました。
@hamaknさん「RubyKaigi3日目昼 出張版 Rails勉強会@東京第64回やります！！」
@hamaknさんから、行きたい人にお薦めの危険な勉強会と題して、Rails勉強会@東京が紹介されました。会場から徒歩1分の自販機でペプシコーラが90円だそうです。なお、3日目に、出張版勉強会が開催されると告知がありました。
@1syoさん「わたしと1年目のyokohama.rb」
@1syoさんは、RubyKaigi2010で角谷さんの話を聞いて感極まってYokohama.rbを立ち上げたそうです。毎月1回開催しているyokohama.rbがどのような形態で催されているかを紹介しました。3日目に、ゆRubyが開催されることも告知がありました。
nariさん「円環の理（Garbage Collection） 」
nariさんの発表は自身が終盤まで、ディスプレイ接続ができないという円環に囚われてしまいました。ディスプレイが表示されるようになった終盤駆け足で、今回作ったleakyが紹介されました。leakyはオブジェクトにfreeというメソッドを作ることが示されたのですが、時間切れとなってしまいました。
sugamasaoさん「ぼくはボッチです」
The Last RubyKaigiということで感謝を伝えたいというsugamasaoさん。2008年当時はボッチだったが、転機となったのは2010年にRubyKaigiで「レポート班やらないか」と誘われたことだったと語ります。特に、誘っていただいた@kei_sさん、@june29さんに感謝していると述べていました。参加者全員が闇のイベントに染まっていたのですが、それを救い出す素晴らしいプレゼンでした。
ジュンク堂書店RubyKaigi店
今年もジュンク堂書店の出張所、RubyKaigi店が出店しています。先行発売の書籍もあり、休憩時間中はとても賑わっています。
1日目のサイン会
お昼に、まつもとゆきひろさん監訳の『7つの言語 7つの世界』（ オーム社）のサイン会が行われました。
1日目のレポートは以上になります。
