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

今年のRubyKaigiにも、世界中から人が集まりました。

開場前、スタッフの集合写真が撮られていました。

高橋征義さん、okkezさん、Sunao Tanabeさん「一般社団法人日本Rubyの会と関連プロジェクト報告(るびま、るりま)⁠」⁠

まずは高橋さんの方から日本Rubyの会について話がありました。

一般社団法人 日本Rubyの会

日本Rubyの会は現在一般社団法人にする予定となっており、日本Rubyの会が発足した8月に法人化すると述べました。

現在の任意団体と一般社団法人の違いの一つに、高橋さんは「契約」を挙げました。たとえばRubyKaigiの会場の契約は現在は個人、つまり高橋さんが契約していますが、法人化すれば法人として契約することが可能となるそうです。

他にも法人として資産が持てることをあげ、今まで個人が肩代わりしていたことを日本Rubyの会が法人として行なえるようになると述べました。

なお、一般社団法人にも様々なものがありますが、非営利性が徹底された法人とするとし、公益法人にはならないと言及しました。

また、法人化することで会員の構成も変わるとのことです。具体的には正会員、一般会員、名誉会員の3つに分類されるようになるとし、現在の理事が正会員となるそうです。正会員はいわゆる社員と同じ意味とのことです。現在の会員は一般会員に属し、名誉会員にはまつもとさんがなることを予定としているそうです。

法人化後の活動は現状とほぼ変わらないとのことでした。今年で最後となるRubyKaigiはRubyKaigiという名前も含めて一旦白紙から検討しなおすそうです。

法人化を行なうことにした背景には「継続性」があるそうです。社団法人となることで、属人性を排除することができるため、継続性のある団体として活動できるようになると述べました。

最後に「ご期待ください、というよりは皆さんと一緒に新しい形を作っていきたい」と話し、今後も日本Rubyの会は続いていくとまとめました。

Rubyリファレンスマニュアル刷新計画 2011 夏

続いて、okkezさんによるRubyリファレンスマニュアル、通称るりまの活動について話がありました。

最初の目標として、Ruby1.8.7もしくは1.9.1のリリースとともに完全なリファレンスを提供することがあったと話し、1.9.3のリリースが予定されている現在、活動としては遅れていると説明しました。

2006年に第1段階、2007年に第2段階が終了し、今では第3段階をずっと継続中だそうです。第3段階が長引いている理由としては、当初マニュアルの内容については質は気にしないがすべてのメソッドエントリを記述するとしつつも、協力してくれる方が質にも大分気をくばってくれているのでなかなか苦労していると話しました。

現状の残タスクについて触れたあと、今後の予定として今年の8月に第3段階を終わらし、メンテナンスフェーズに移行するとのことです。また、るりまに参加しやすいようにgemの提供やRDocとの連携などを考えているとのことでした。

最後に、Ruby1.9の言語仕様に詳しい人や、Windowsに関するドキュメントが書ける人が足りていないこと、BitClustに機能を追加したいことを挙げ、会場のRubyistたちに協力をお願いしました。

Rubyist Magazine

最後に田辺さんからRubyist magazine、通称るびまの活動について話がありました。アジェンダとして以下のことを挙げました。

• 2011年の今を報告
• 今後のるびまについて
• るびまの編集の募集
• るびまの記事の募集

まず、今年のるびまの活動として31号から34号、RubyKaigiのKaigiFreaksレポート班によるRubyKaigi2011直前特集号の発行したという報告がありました。そして今までもるびまでは記事の公募をしていましたが、改めてruby-listで公募を行なったとのことです。いくつかテーマを絞ったことでFiberなどの記事はすでに公開され、近いうちにSinatraなどの記事も出せる予定だそうです。Bundlerについて記事をかける人がいないそうで、Bundlerの記事を書いてくれる人を募集中とのことでした。

これからのるびまについて、あくまで編集部ではなく田辺さん個人の見解としながらも、ruby-devの翻訳プロジェクトの広報をしていきたいと述べていました。ruby-devは日本語での議論が中心なので海外の方は読むことができません。現状、翻訳する人も読む人も足りておらずあまり活発的とは言えないので、関わる人を増やしていきたいとのことでした。

るびまは組織で動くというより個々の人達が動くことからはじまるらしく、会場の人達に「いっしょにやりましょう」と呼び掛けました。

あんどうやすしさん「parse.yの歩き方⁠」⁠

あんどうやすしさんは昨年のRubyKaigi2010のLTでの発表の続きということで、parse.yを触ってRubyの文法を変更する方法についての発表しました。

前回のあらすじは、Rubyはクリスマス合わせで新バージョンを（毎回ではないが）リリースする慣習があり、Ruby誕生からもう18年も経つのだからこの「クリスマスプレゼント」を貰う側からあげる側になろう、そのために文法を改造したオレオレRubyを作ってみんなでクリスマスにリリースしよう、というものでした。このLTの時は技術的な詳細に触れていなかったため、How toに踏み込むのが今回の目的であると述べました。

parse.yとは

プログラミング言語は言語である以上文法が存在し、Rubyの場合その文法を定義しているのがparse.yというファイルです。これをyaccというパーサジェネレータに読みこませると、定義した文法を処理するためのプログラムが生成されます。例としてRubyのif文を定義している箇所を見せ、トップダウン的に文法を定義していくことを概観しました。詳細は『Rubyを256倍使うための本 無道編』を読むとよい、とのことです。

また、Go言語の文法定義ファイルであるgo.yとRubyのparse.yを比べると行数が約2,000行vs約10,000行とRubyがかなり大きく、スキャナ（条件分岐の判定をするもの）の状態数もGoの1つに比べRubyは11+αとかなり複雑であると述べ、1.9系のVM作者であるささださんの「parse.yは魔窟」という言葉も紹介しました。Rubyに詳しい人すらもこう言っているのが、parse.yというものなんだそうです。

では、「⁠我々一般のユーザがRubyを改造しプレゼントするのは難しいのか？」「⁠たくさんの勉強を経てからでなければならないのか？」という問いについて、「⁠長い旅行に必要なのは、大きなカバンではなく、口ずさめる一つの歌さ」というスナフキンの名言を引用。やっていけば結構なんとかなるよ、とその過程でわかったコツを実例と共に紹介しました。

Fuzzy Ruby

最初の例としてあんどうさんが作ったのが、Fuzzy Rubyです。これはif文のthenの代わりにprobably、maybe、perhapsのような曖昧さのある言葉を書くと、trueになる確率がそれぞれ80%、50%、20%になるというジョークRubyです。やっていることはジョークでも発想自体はまじめで、Rubyはオブジェクト指向言語というよりも文章指向言語であり、DSL風にすらすら読めるコードがみんな書きたいのではと思ったそうです。しかし文章の要素として名詞・動詞・形容詞はあるが副詞が見当たらず、それを追加すればおもしろいだろうと試してみた、ということでした。

初期の構想ではobj.do_something anywayのように処理の最後に副詞をつければ動作が変わる（この場合、例外を無視する）ものを目指していたがこれは難易度が高かったそうです。そこで目を付けたのがthenで、これも副詞だから、そこに別の副詞を置き換えるよう真似て書くことでうまくいったとのことでした。コツとしては、やりたいことと似ている文法を探すことが大事だと述べました。

また、実作業をする際にはとにかくgrepをして、参考元の文法が関わっている所を探すのがポイントということでした。Fuzzy Rubyではparse.y以外にもdefs/keywords（予約語を定義するファイル⁠）⁠、id.h等を触ったことを説明しました（id.hについては自動生成機構がある、とRubyコミッタが質疑応答で言及していました⁠）⁠。

そして、追加した文法に対応するアクションを書くところでは、もちろんC言語を書くがC言語を知らないなりでも結構いけたと述べ、分からないときは一旦Rubyで考えてみるといいと補足しました。例えばmaybeなら、Rubyだったらand rand < 0.5になると捉えて構成を考える。さらに、NEW_FCALL(rb_intern("..."), 0)のような関数を使えばRubyの既存のメソッドを使えるからこれを使ってみるのがいい、とのことでした。

XML Ruby

次に出した例がXML Rubyで、<?xml>?</xml>で囲むとそこがXMLオブジェクトになるというリテラルを追加したRubyです。実はこれはScalaにある機能で、他の言語はネタの宝庫なので自分で考えるより他から持ってくるのもアリ、としていました。

作るものが決まったら、Fuzzy Rubyの時に習い、Rubyから似た文法を探します。何行にも渡る文字列を囲うものと言えばヒアドキュメントが近いので、これを真似たそうです。ただし、そのままでは単なる文字列オブジェクトができてしまうためXMLに変換しなければなりませんが、それにはXMLを操作するライブラリを明示的に読み込む必要があるとのこと。そこで、prelude.rbにその処理を書いたそうです。prelude.rbはその中にRubyを書くとそのコードがまるで最初から言語に組み込まれていたかのようのようになるため、割と万能であると説明しました。

Objective Ruby

次に出てきたのがObjective Rubyで、%o{}に囲まれた内側はSmalltalkの文法になるRubyです。これも元ネタがあり、Objective-CがC言語とオブジェクト指向的なコードを混在させて書けることに着想を受けたそうです。ポイントとして、%o{}の内と外で同じ変数をやり取りするためにbindingを渡すという工夫をしていることを説明しました。また、RubyにはSmalltalkParserクラスがないため先程のXMLの場合と異なり、raccを使って自分でパーサを作ってしまった上でprelude.rbに組み込んだそうです。

ennnnd

最後の例は発端として、Rubyでブロックを多用するとそれを閉じるのに後ろにendが沢山並んでしまうのをどうにかしたいという動機を述べました。解決案の一つとしてPython方式でインデントを数えるというのがありますが、これは過去にMatzにrejectされているとし、であればさらに先人のLispの知恵である(cdr(cdr(cdr)))を(cdddr)と書く機能を真似たらいいと提案しました。すなわち、endが続いたらその数だけennnndのように書く方法で、その奇抜な発想に会場からは大きな笑いが巻き起こっていました。実装は意外と難しく、CRubyではなくRubiniusを使ってなんとか実現したそうです（発表後、あんどうさんが実際にRuby本体へ機能提案したところ、なんだか議論が盛り上がってるようです⁠）⁠。

最後に、「⁠今年からクリスマスはユーザーが勝手にRubyを作って公開する日にするのはどうでしょうか？」という提案を再度して、発表を終えました。皆さんもあんどうさんのように楽しいハックをして、サンタクロースになってみてはいかがでしょうか。

ucnvさん「Visual Glitch, using Ruby」

ucnvさんは、画像や動画の見た目をあえて壊すアート手法であるGlitch（グリッチ）をRubyで行うテクニックについて発表しました。

ucnvさんはウェブプログラマーとして働く傍ら趣味でグリッチをやっていたらビジュアルアーティスト的な扱いをされるようになり、『映像作家100人 2011』という本にも紹介されるようになったそうです。過去に作ったグリッチの映像作品を紹介され、一見動画ファイルが破損したような映像が会場のスクリーンに現れました。

グリッチとは

こういった状態を指すグリッチとは一体何なのか、ucnvさんは海外のブログや論文での考察を紹介しました。曰く、「⁠予期せぬエラーである」「⁠真のグリッチは再現不可能である」「⁠それがグリッチだと認識したら、その気づきによってグリッチ性は失われる」など。それでは、グリッチは再現不可能なのかと言えば、驚きの感情は再現不可能だが、コンピュータ上で行われる現象なら再現可能なはずとucnvさんは考えているそうです。

もっとも再現性についてそう難しく考えることはなく、グリッチとはつまり「ファイルが壊れている状態でプレイヤーで再生したとき、プレイヤーがエラーを無視しながら再生している状態」のことである、と説明しました。

画像をグリッチ

具体的な手法に入る前に、同じ画像をJPEG／PNG／GIF／TIFF／TGA／PSD／WebPといった画像フォーマット毎にグリッチしたものを並べ、フォーマットによってグリッチ結果の具合が異なることを見せました。ucnvさんは「PNGは変わった結果が出るので好き」と発言し、またPNGとWebPで似た壊れ方がするのでもしかしたらアルゴリズム的に似た所があるかもしれない、といった考察を述べました。

画像をグリッチする方法としては、特別なことはなくテキストエディタやバイナリエディタで画像を開いて適当に書き換えて保存するやり方を出発点として、catとsedを使ったワンライナーならとっさにグリッチが必要になったとき便利、もちろんRuby等のプログラムを使ってもよいと説明しました。ただし、こういった方法はucnvさんが言うには「モンキーグリッチ」であるとして、画像のヘッダを破壊してしまったり、チェックサムがついている画像フォーマットだとプレイヤーで開けなくなるという問題があるようでした。

そこで、正しく壊したいなら仕様にしたがってグリッチしよう、というよく考えると不思議なスローガンを掲げ、画像フォーマット毎の違いを意識した手法を紹介しました。例えばPNGならばzlib圧縮されているため解凍してから書き換えて再度圧縮してチェックサムを付け直すとうまくいくそうです。JPEGならヘッダ部分に1バイトだけ書き換えると全体が綺麗に壊れるポイントがあったり、画像本体も8x8ピクセルが基本単位になっているのでその単位でシャッフルすると良い、などを挙げました。

また、仕様を守って画像をグリッチできるライブラリとして「コードネーム：PhotoShop」を作成中であり、"PhotoShop"なら画像フォーマットを指定して簡単にグリッチが可能になると説明しました。

動画をグリッチ

動画のグリッチに入る前に、動画ファイルというのは画像のフレームの集まりでできていること、そのフレームには完全な情報を持つキーフレーム（I-frame）と前後への差分情報だけを持っている差分フレーム（P-frame、B-frame）があることを説明しました。こういった構造のファイルでは、動画の最初の方を破壊しても、次にキーフレームを通った時に全てのピクセル情報が復活してしまい、破損耐性が高くて「困る⁠」⁠。そこでキーフレームを全て抜くことで動画全体をうまく破壊するデータモッシングという手法があるとのことでした。

また、グリッチ用動画のフォーマットにはシンプルで扱いやすいという理由でAVIを使っているそうです。さらにXvidというコーデックがあり、これのおかげでMPEG4のようなキーフレーム・差分フレームの仕組みがオープンソースで使えるようになったということです。

実際にRubyで動画をグリッチするには、ucnvさんが自作したAviGlitchというライブラリを利用することができます。さらにAviGlitchにはdatamoshというコマンドが付属しているので、これを使えば簡単に動画をデータモッシュできるという利点があるそうです。

その後、応用編に入る前に惜しくも時間切れとなってしまいましたが、「⁠おもしろい壊れ方をする」「⁠正しく壊す」といった印象深い言い回しなど、新しい価値観に触れられる楽しい発表だったのではないでしょうか。

島田浩二さん、こしばとしあきさん、角谷信太郎さん「All About RubyKaigi Ecosystem」

RubyKaigi2011の実行委員である、島田さん、こしばさん、角谷さんによる、RubyKaigiに対するパネルディスカッションが行なわれました。

Rubykaigi とは何だったのか

日本Rubyの会のサイトには、RubyKaigiのページがあり、過去の開催規模などが掲載されています。このページを眺めながら、過去のRubyKaigiについて振り返り、RubyKaigiとは何だったのか、何を目指して開催していたのかということについて話しました。

RubyKaigi2007は頑張りすぎてしまい、お客さんが来すぎたと感じていたそうです。RubyKaigiは毎回最終回という気持ちで取り組んでいましたが、RubyKaigi2007の規模（410名の参加者）を越えるのは無理だと判断し、会場確保が比較的容易なつくばへ会場を移すことを決めたそうです。来場者が500名を越えると都内では一年以上前に確保をしないと次年度の開催は厳しいという背景もあったようです。しかし、Rubyistにそんな前持った行動ができるはずもなく、2008年度は空いていたつくばでの開催が決まったことを述べていました。

Regional RubyKaigi

こしばさんから、Regional Rubykaigiの作り方ややり方についての説明がありました。こしばさんとRubyKaigiのつながりは、

• 登壇、LT
• 主催
• 運営

以上の3つの側面から活動を繰り返しにあったそうです。しかし、狙ってこのサイクルを回していたのではなく毎回最終回と思いながら運営したり、一期一会だと思いながら活動したら、いつの間にかこのようなサイクルを回しながらの活動となっていたと述べました。

こしばさんが、Regional RubyKaigiを作った流れやRubyKaigiとのつながりについて、時系列に沿って遡りながら振り返りました。 2008年は初めてRegional RubyKaigiに参加したと言います。 2009年は、初めてRubyKaigiに参加し、初参加にて初実行委員を務めたとのこと。とても大きな規模でありながら日々の設計力を発揮したり、niceを心がけることにより、いいものをつくりあげることができたと感じているそうです。 2010年は、参加者がより喋る、参加者により喋ってほしいということを目指して活動したとのこと。しかし、規模が大きくなりすぎてしまった側面があり、手のひらサイズのできる範囲でコンパクトに開催することを目指す必要性が出てきたそうです。 2011年、東京Ruby会議05にて実行委員長を務め、実行委員を声掛けから始めて結成したとのこと。テーマを「対話と挑戦」と題した開催趣旨をまとめ、Regional RubyKaigiのMLに投稿することで、Regional RubyKaigiとして認知されるようになったそうです。

RubyKaigiを通して、自分の生活と、日常にちょっとした彩りを添えることを実践されてきたと言います。こしばさんは最後に、自分の望みと自分なりのアプローチについて語り、「⁠まずはやってみること」「⁠望みを口に出してみること」「⁠参加してみること」「⁠短時間発表（LTのような）に参加してみること」「⁠仲間と集まること」をみなさんも実践してみてはどうかと述べました。

Regional Rubyist community どんなコミュニティがあるのか

島田さんから地域ごとにどんなRubyコミュニティがあるか、どんな特徴を有しているかについての話がありました。

東京以外では、既にRubyに興味を持っている仲間を集めてRegional RubyKaigiを結成することはできないと感じられるそうです。また、既にRubyをやっている人たちがいつの間にか集まって、気がついたらこれってRubyKaigiと呼べるんじゃないかと気づくことが始まりなのではないでしょうか、と言います。一ヶ所だけではなくて、他のRegional RubyKaigiに行ってみるといいという意見も出ました。その他に海外参加者からは、Regional RubyKaigiに行ってみたいから、情報提供をして欲しいという声もあったようです。るびまの発表にもあった通り、英語での情報発信についても考えていく必要があるかもしれないと言及しました。

Andrew Grimmさん「Finding Black Holes in Ruby with the Small Eigen Collider⁠」⁠

バイオインフォマティクスの科学者であるAndrewさんによる発表です。Andrewさんは自分自身の研究にRubyを使っていたそうですが、扱うデータが大きいために解析にとても時間がかかってしまうとし、Ruby1.9.1で20分ほどかかると述べました。

RubyにはJRubyやRubinius、Ruby Enterprise EditionなどCRuby以外にも実装があることを挙げ、パフォーマンス向上のためにCRuby以外の別の実装を使うことも検討したそうです。

ですが、それらの各実装が正しく動作を知るためにはどうしたらいいのかと疑問を投げかけます。エラーが明確に発生する場合はすぐに気づけるので問題ないとし、些細な違いの方が気づきにくいため問題だと述べました。

RubyにはRubySpecプロジェクトがありますが、それが失敗しなかったからと言ってバグがないとは言えないと話すAndrewさんは、バグは未踏の領域で起きるとし、それを見つけるためのライブラリを作ったとのことでした。

Small Eigen Colliderはあるタスクを複数のRuby実装で実行し、その結果を比較するライブラリだそうです。タスクの実行にはメタプログラミングを使用して、テストするオブジェクトやメソッド、それに渡すパラメータをランダムに実行するとのことです。そのコードの各実装での結果の差異をチェックし、実装ごとに違いがないかのチェックをできるとのこと。

Andrewさんはこのライブラリを使い、Thread.killにnilをわたすとCRubyとRubiniusでSEGVが起きることを見つけ、このバグについては報告済みと述べました。

今後の課題として実行結果のログの出力にinspectを使っているが、この出力が実装ごとで違うことや、真偽値を返すメソッドでfalseを返す実装とnilを返す実装があることを挙げ、これがバグかどうかは微妙な問題だと話しました。また将来の方向性として、スピードの向上と、クラウドの移行を検討していると述べました。

最後に質疑応答では、質問をしてくれた方にAndrewさんからTシャツがプレゼントされました。

井上真さん「3/11 そしてRubyistとしてできること」

ロンドン在住のRubyistである、井上さんの発表です。

震災直後に何があったのか

震災でたくさんの方々が亡くなり、ライフラインは深刻なダメージを受け, また東京でも、携帯電話が通じなくなったりしました、と切り出しました。 そして, そんな状況でも、被災地以外ではインターネットはほぼ機能しており,ソーシャルネットワーク等を起点として、大きな情報爆発が起こったと分析しました。 例えばTwitter上でのハッシュタグを使ったやり取りや「拡散ツイート」等がとても多く行われました。しかし、その反面、デマやパロディ等の情報も多く発信され、悪意は無くとも間違っている情報というものも散見したと、当時の状況を振り返りました。

また, 震災直後に、GoogleはPerson Finderを立ち上げ, とてもシンプルですが、大きな役割を果たしたと話し、さらに同じ時期にsinsai.infoというサービスも立ち上がったと語りました。

sinsai.info とは

各地から、どのような問題があるかをレポートしてもらい、それに対してボランティアを募ったりするサイトだそうです。 Webからの入力フォームやTwitterからのインプットをベースとして、ボランティアによる誤情報の訂正やモデレーションを行っていると説明しました。 また、sinsai.infoは震災後4時間で立ち上げられたサイトなのですが、それはOSSのUshahidiのおかげだといいます。 このUshahidiは過去にハイチやリビアでの震災でも活用された実績がありました。 sinsai.infoはPHPで作成されているのですが、Rubyのコアチームのメンバーである@takano32さんや@sora_hさんも活動していることや、 日頃のOSS活動を通じて1から仕組みを創り上げていく能力に長けているRubyist達にぴったりなのではないかと語りました。

震災から4ヶ月たって

現在、フェーズは救助から復興へ移行しましたと語りました。 そして, 被災地の瓦礫の除去は、推定2183万トンのうち、仮置き場に移されたのはまだ35％程度にとどまっているそうです。 また、阪神大震災の時は仮設住宅からすべての人が退居するまでに、5年の年月が掛かったことから、復興は長い戦いになるだろうと述べました。

我々に何かできることはあるだろうか？

直近では 7月23、24日にhack4japanが開催されます。もし興味があればぜひ参加してみてくださいと呼びかけました。 また、sinsai.infoではボランティアのやり方等も掲載してあるそうです。hack4japanに限らず、復興は何年もの時間をかけて行っていくことなので、いまから動いていくことが長期的な支援に繋がるはずだと述べました。

最後に、東北には美しい場所がたくさんあること、機会があれば宮城の松島などを訪れてみるのも良いと話し、国内だけではなく、海外へ向けて、日本で今何が起こっているかを伝えることも重要なことだと語りました。

柴田博志さん「Ruby遺産とレガシーコード修理技術」

tDiaryのメインコミッタの柴田さんによる発表です。柴田さんが開発に携わるtDiaryは現在10年間メンテナンスされ続けており、その経験から25年使われる予定のソフトウェアをメンテナンスする方法を話しました。

tDiaryを25年使い続ける理由は、一時期ブログサービスが乱立した時期にたくさんのサービスが姿を消していった際に「こんな状況で安心して日記をかけるだろうか」とtDiaryを最初に作ったたださんが考えたためです。紙の日記に10年日記というものがあるそうで、この日記は10年同じフォーマットで書けることを保証する、Web日記でもそう言えたらうれしいなと考えたと言います。

tDiaryは作られてから10年たっており、ソフトウェアとしては大分古い部類です。柴田さんもtDiaryを作り替えずにメンテナを続けているのはなぜと質問をされたことがあるそうですが、柴田さんはtDiaryに関わっている人が好きだと話し、それがtDiaryのメンテナを続けるのが理由とのことでした。

tDiaryのように長くメンテナンスされていくソフトウェアは内部のコードは複雑化していることが多いのですが、これからもメンテナンスし続けていくためにはその傷をこれ以上増やさないこと、そして傷をふさいでいくことが重要だと話します。

レガシーコード改善ガイド

そのようなコードを改善していく方法として、『⁠レガシーコード改善ガイド』という本を挙げ、この本はJavaなどRuby以外のコードで書かれているため、そのまま使うことは無理だけど応用することはできるとし、実際にtDiaryの開発に応用された話を取り上げました。

機能の追加は慎重に削除は大胆に

長くメンテナンスされているソフトウェアには、時代に求められなくなった機能がでてくるそうです。tDiaryではTrackbackとPingbackを挙げました。この機能は今ではあまり活用されているとは言えず、現在のtDiaryではすでに削除されているそうです。時間をついやして実装した機能は気持ち的に消しづらいとしながらも、メンテナンス性を維持するために削除するべきと話しました。

仕様化テスト

コードを修正する際に、テストでコードが壊れない骨格をつくるべきという話をしました。テストにはユニットテストや、エンドツーエンドテスト、インテグレーションテストなどがありますが、コードが複雑になっている場合、ユニットテストが書くことが困難なことが多く、そういう時は例えばウェブアプリであればブラウザからのテストのようなエンドツーエンドで全体の動作を保証すると良いということでした。

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

この10年でRubyもバージョンがあがり、tDiaryでは1.8.6、1.8.7、1.9.2で正しく動くように気をつけているとのことです。各バージョンで正しく動くかどうかはJenkinsやtravis-ciなどといったCIツールによって自動でチェックするようにしているそうです。

新しい仲間をふやす

柴田さんは開発者の負担を減らすことが好きだと話し、開発者が安心して開発できるようにテスティングフレームワークを導入するといったようなことをしてきたと話します。そういった活動が新しい仲間を増やすための種になり、ソフトウェアを長くメンテナンスしていくためには新しい仲間は必要と言います。開発者の負担を減らすことで、減った負担の分だけどんどん新しいことを投入して欲しいと話し、各開発者が楽しいと感じることをできるようにすることが継続的な開発に続いていくそうです。

最後に、コミュニティや角谷さん、たださんたちに対して彼らのおかげで充実した仕事を送ることができていると感謝で発表を締め括りました。

Joshua Mooreさん「Writing custom DataMapper Adapters」

Joshua MooreさんによるDataMapperのカスタムアダプターの作り方を紹介するセッションでした。DataMapperはActiveRecordと並んで人気のあるORMの一つです。今回Joshuaさんは、MongoDBをデータ保存先とするアダプターの作り方を例にし、カスタムアダプターの作成のポイントを紹介しました。

カスタムアダプターを作成するには、まずDataMapper::Adapterモジュールの中に作りたいアダプターのクラスを作成し、アダプターのクラスはAbstractAdapterクラスを継承する必要があると言います。クラスを定義したあとは、DataMapper::Adapterモジュール内でconst_addedメソッドを使いクラスを登録し、アダプタークラスのコンストラクタ中でDBへのコネクションの作成や、Rubyコードでのリソースの名前とDBでのリソースの名前を対応付けするためのルールの定義を行なうとのことです。

次に、CRUDができるように以下のメソッドを作成する必要があると述べました。

• create
• read
• delete
• update

readメソッドを実装する際は、parse_query_conditionというメソッドを使い、DataMapperの受けとったクエリを処理できる形に変更していくそうです。また、DBの操作のログがとれるようにDataMapper.loggerを使いログを記録するのも大事だと言います。DataMapperのアダプターは簡単に作れるということが分かり、自分でも作ってみたくなるようなセッションでした。

須藤功平さん「テスティングフレームワークの作り方」

株式会社クリアコードの代表取締役である須藤功平さんによる、テスティングフレームワークの作り方の解説セッションです。作り方と言っても具体的なコードの書き方ではなく、こういう考え方で作るとよい、という大枠となる話でした。また、テスティングフレームワークだけでなく普通のライブラリを作るときにも参考になる話を取り上げました。

多くの成果物

須藤さんはたくさんのプログラムを作成して公開されている方です。テスティングフレームワークだけでもRubyのtest-unit2、C言語のCutter、GaucheのGaUnit、PythonのPikzieと複数作っているそうで、Kent Beckの『テスト駆動開発入門』の中から「筆者は新しいプログラミング言語に直面すると、xUnitを実装する」を引用し、みなさんはどうですか？と問いかけていました。

また、須藤さんはRuby製のプレゼンツールであるRabbitの作者でもあります。Rabbitは競争するウサギとカメがそれぞれスライドと時間の進行具合を表現してくれるのが特徴のツールで、RubyKaigiでも多くのRubyistが使用しているのが見受けられました（まつもとさんも使っています⁠）⁠。7年前に最初のバージョンがリリースされたRabbitですが、今月1.0.0をリリースしたことも伝えました。

判断基準を作る

そんな須藤さんが今回話すのは、何を基準にライブラリを作っていけばいいのか、という判断基準です。なぜ判断基準について話すかというと、物事をカタチにしていく上で判断基準があると楽であることを社長になりたての頃に気づいたという経験があったこと、そして判断基準を伝える人が少ないのではないか、と思ったからだそうです。技術系のコミュニティでは、聞くことが罪のように思われている部分があるけれども、判断基準のようなものは「盗む」のが大変であり、どんどん教えて皆を先に進ませた方がいい、と須藤さんは言います。

ではどういう基準があるかと言えば、まずターゲットを考えること。何でもできるものは目指さず、誰が使う物なのか、何のための物なのかを考えること。次に、自然であること。普通だったらこうだろうなというのが大事で、使い手が気づいたらできていた、ぐらいの作りになっているのが良いということでした。

自然さ

自然さの例として、先程のRabbitはEmacs使いでもVim使いでも初見でだいたい動かせるキーバインドになっていたり、dRubyではリモートにあるRubyオブジェクトに対して特別な文法なしでローカルなオブジェクトを触っているかのように使うことができるといったことを挙げました。またRuby自体も、こう書けばこう動くだろうで実際動いたりして自然さがある、としました。

自然さを考える上で大事なのは、一貫性があるかどうかということ、そして身近なものと同じ手順・同じルールになっているか、ということ。ただし、どんな一貫性／どんなルールでも良いわけではなく、選択ミスをすると間違った一貫性を追い求めてしまうことにもなる、と述べました。

ターゲットを絞る

次にテスティングフレームワークを例題とし、ターゲットを絞る具体例を示しました。テスティングフレームワークにおけるターゲットには、「⁠利用者はプログラマなのかテスターなのか？」「⁠プログラマだとしたら、普通のプログラマか様々な事に精通しているプログラマか？」といったものがあります。またそのプロジェクトでは何のためにプログラムを作っているのかを意識するのも大事で「自分が思いついたものを作っているのか」「⁠要求されたものを作っているのか」「⁠テストの目的はバグを見つけるためか」「⁠サービスの安定稼働のためか」といったことでも変わってくると言います。

例として、普通のプログラマがRubyで開発し、要求されたものを作りたいとする。コツは登場人物を使って関係性を考えることで、まず要求があってそれを具体化するという開発手順なら、要求を自然に書くことができるcucumberのようなテストフレームワークが考えに浮かび上がってくると語ります。

そして普通のプログラマによるRubyでの開発という部分を考えるならば、他の知識なしでいかに普通にRubyで書けるかという所にフォーカスすると言及しました。そうなるとRubyらしいAPIで、プログラム本体の実装と同じ知識を使える、test-unitのようなテストフレームワークを作るのが良いだろうということになる。この場合RSpecでは、Rubyの上に作られたRSpecのAPIを知っているかどうかになってしまうため、ターゲットを外れてしまうと述べました。

以上にように、判断基準を活かすことで有用なライブラリを作っていくことができることを話しました。今回は具体的なコード例や実装の話ができませんでしたが、そういうものは一回で話せば済むようなものではないので、本当に知りたければクリアコードで一緒にやっていきながら教えます、と開発者を募集していることを伝え発表を終えました。

秋田ファビオ誠さん「Personal Dilemma: How to work with Ruby in Brazil?」

最初に、「⁠RubyそしてRubyコミュニティのこれからの発展をお祈りします。matzとコミッタのみなさんありがとうございます」と流暢な日本語での挨拶がありました。

技術のシフト

ファビオさんは今までは違うRubyとは違うマーケットで働いていましたが、近年コミュニティ活動を始められたとのことです。RubyやRailsは2005年から学び始めたそうで、いろんな記事を読み毎日調査・勉強をしたと振り返ります。Ruby自体は2001年ころに知っていたのですが、2005年頃から突然Ruby、Railsの話題を聞く機会が増えたそうで、それがきっかけとなったそうです。また、DHHが世界で初めてRailsについてプレゼンテーションを行なったのは、2005年のブラジルで行なわれたOSSカンファレンスだそうです。

今年のRubyKaigiの基調講演でのAaronさんの「Rubyが人生をめちゃくちゃにした」という言葉を挙げ、あなたたちもRubyで人生を狂わせた経験があると思うと述べました。ファビオさんがRubyで仕事をしたいと思ったとき、アメリカに移住するか、諦めるかという選択肢を考えたそうです。99％の方がここで諦めてしまうと思いますが、ファビオさんはここで、Ruby/Railsのマーケットをブラジルに作ろう！と思ったと話します。ファビオさんはブラジルで一番に最初にRubyを触ったRubyistではないとのことでしたが、ブラジルからは逃げるつもりも新しくマーケットを作ることを諦めるつもりもないそうです。

また、みんな仕事でRubyを使おうとしていましたが、Rubyでの仕事を始めるにあたり、対話する相手を間違えていたそうです。HackerとHackerの会話といった限られたプログラマ間だけの会話だけでなく、心理学とマーケティングの知識を持ち出し、職をくれる人や給料を払ってくれる人と対話する必要があると述べました。

ファビオさんはコモディティとはどこの会社がやっても大体同じであることと説かれました。みんなと同じことをやっていたらコモディティの中にうもれてしまうとし、リスクをとらないという生き方ではキャリアを積むことができないと話されました。ブラジルでは昔の日本と同じように、同じ会社で働き続けるのが一般的であり、保守的であるという背景があるそうです。ファビオさんはあるアプリ開発で、フリーランスとしてブラジルからアメリカのプロジェクトに参加されことを例にだし、このような開発形態が可能であると示せたことは大きいと感じているそうです。

Railsイベントについて

2008年からRails Summitというカンファレンスが始まりました。予想を遙かに越える反響があり、何かが起こっているということしかわからなかったそうです。その後2009年にもRails Summitを開催し、2010年からはRubyConf Brazilと名称を変え、開催しているとのことです。名称を変更することでRailsを使っている人たちだけではなく、より多くの人たちにRubyのことを、そしてもちろんRailsのことを広めたいとの意向からだそうです。その際、Aaronさんの基調講演でも流れたような映画予告のようなRubyConf Brasilを紹介する動画が上映され、感動巨編のような映像に聴衆のみなさんが驚かされました。RubyConf BrasilではRailsの話題だけでなくnode.jsなどの話もあるそうです。ぜひともみなさんお越しくださいと紹介しました。

浅里洋嗣さん「Rubyを持て、世界に出よう！」

JRubyのコミッタであり、Engine Yardで働く、浅里 洋嗣さんの海外で働くために日本人が知るべきことを発表しました。浅里さんは、アメリカの大学で学び、そのまま海外の企業に就職、そして転職を経て、現在のEngine YardでJRubyのサポートエンジニアをやられています。浅里さんは、海外で働くには「言葉」「⁠ビザ」「⁠仕事」の3つが重要だと言います。

言葉の壁

日本以外の国で会話するには英語を習得する必要がありますが、どうすれば習得できるでしょうか？と問いかけます。浅里さんは「日本人が英語を勉強するには、話をしたいとう欲求が重要」と言います。会話できるためには、どれぐらいの英語力があるとよいかは分からないため、目標を決めて勉強してもコミュニケーションがとれるようになったとはいいきれません。そこで、どんどん海外の人とコミュニケートする必要があると述べました。また、「⁠ネイティブでも完璧な英語の人はいないのだから、物怖じせずにいくべき」とアドバイスしました。

次に、浅里さんがどのように英語を学んだかという話がありました。浅里さんは学生時代、『⁠600選』という本から英語を学習したそうです。そして、「⁠どんなものからでも英語は学べる」ということを、自身が海外のバンドの歌詞から学んだ経験を交えて紹介しました。また、英語を学習する際に注意すべきこととして、「⁠日本語訳は日本語の作文技術なので、日本語訳はしない」「⁠辞書は英和辞書を使うのでなく、英英辞書を使う」というポイントを述べました。

最後に、「⁠話さないと相手には伝わらないので話しましょう。相手が話に興味を持ってくれれば、英語が下手でも辛抱強く聞いてくれます」と、英語でコミュニケーションするための心構えを説きました。

ビザについて

海外で働くにはビザが必要になります。ビザの種類について紹介しました。

まずは、「⁠家族」にまつわるものです。海外の方と結婚したり、養子縁組を組んだりすることでビザを取得できます。また、永住権を既に持っている方からの支援がある場合でも取得が可能だそうです。次に、「⁠就労」にまつわるものです。就労するために必要となるH-1ビザは、年に発行される数が決まっているため、取得できるかどうかの予測が難しいそうです。また、大きい会社でなければ取得のための法的手続きの手際が悪いらしく時間がかかるとのことでした。続いては「学生」に関するビザです。学生のビザでは、特別な場合を除いて学校外で働くことはできませんが、在学中に就職活動ができるそうです。他のビザとして、資本金があれば取得できる「投資家」のビザ、永住権をもらうことができる「抽選」によるビザを紹介しました。またアメリカ以外には、25歳以下の人が行なえるワーキングホリデーがあると述べました。

職を探す

まず、職を探すということについて、「⁠自分の能力をいかに上手に売り込むかというゲームととらえるとよい」と述べました。海外の就職活動では履歴書が必要なく、コネクションがとても大事だとし、日本の就職活動との違いを言及しました。コネクションを作る方法として以下のような方法を挙げました。

• GitHub等のOSSの世界に自分のコードを出す
• 海外の会議に行って人脈をつくる
• LinkedInなどSNSを利用する

発表後に質疑応答の時間があり、浅里さんの経歴に関する質問など時間いっぱいまで質問が飛び交いました。

石塚圭樹さん「分散オブジェクト環境DeepConnectの新バージョンについて」

Rubyの名付け親で、irbの作者でもある石塚さんの発表です。少し前までは楽天でfairyの研究開発を行っていたそうです。

DeepConnectとは

DeepConnectは、分散オブジェクトシステムを実現するフレームワークです。DeepConnectを使用することで、別プロセスのオブジェクトをあたかもローカルにある普通のオブジェクトのように取り扱うことができると語ります。 ライブラリの簡単な紹介のあと、開発の歴史を語ってくれました。

• 1996年 途中で放棄
• 1999年 ソースをいじった形跡がある
• 2008年 fairyで適用を開始し、DeepConnectという名称へ
• 2010年 オープンソースとしてgithubで公開へ
• 現在 新しいインターフェイスでの実装を行なっている最中

この歴史からわかるように、最初の実装からかなり長い時間を経て DeepConnectは世に出ることになったと言います。 現在は、楽天でのfairyの開発が落ち着いたことと、新しいインターフェイスを思いついたということで、DeepConnectの開発を進めているそうです。

DeepConnect の特徴

特徴は、別プロセス上の定数や変数、ファイル等をあたかもローカルにある変数のように扱うことができることと言います。 これらのオブジェクトは基本的に参照渡しで値を受け渡ししているのですが、trueやfalseなどのImmutableなオブジェクトや、String 等パフォーマンスを考慮して値渡しにしているオブジェクトも存在するとのこと。文字列に関しては明示的な操作で参照渡しにすることも可能なのだそうです。 これらの機能をどのようなアーキテクチャで実装しているのかを丁寧に説明しました。

DeepConnectの今後

このDeepConnectはfairyで採用されていて、かなりハードな使い方をしていて品質についても安定しているとのことです。今後の方針としては、全体的な高速化を目指すため、ThreadやQueue等をC言語で再実装することを目標としていると述べていました。

島田浩二さん「Rubyの教えてくれたこと」

Rubyの教えてくれたこと

このセッションのタイトルは、仙台Ruby会議02で大場寧子さん発表されたトークのタイトルからいただいたそうです。島田さん自身、このトークをとても気にいっており、このタイトルでRubyKaigiで発表することを目標にし、Rubyに関する活動をされていたと語ります。島田さんは、「⁠RubyKaigiに来ると、自分のしたかったことやすべきことを思いだすことができ、おかげさまで人生をよくしてしてもらっている」と述べました。

最後のRubyKaigiで何を話すか

まず「楽しいRuby」という言葉について触れ、「⁠Rubyは楽しい。まずやってみることがとても大事」だと述べました。島田さんは、札幌Ruby会議03でも同名のタイトルで発表されています。このときは、Rubyのブロックを紹介することで、Rubyの良さについて語る内容でした。今回の発表も、Rubyの良さを伝えたいということは同じですが、プレゼンテーションの内容は全然別物になっているということを前もって説明しました。

Rubykaigiと私

島田さんは、2006年にこれまで勤めていた会社を退職し、フリーランスになりました。そこで、今後どのように進んでいくかという道を探していたと言います。この時期の島田さんは、OSSやコミュニティでの活動はしておらず、仕事としてプログラムだけのプログラマだったそうです。

そのような時期に、偶然立ち寄った書店で『プログラミングRuby』という書籍と出会い、Rubyと恋に落ちたそうです。その日以来、Rubyの本を買っては、その本を読みながらプログラミングをするという日々を繰り返してきたと言います。そして、この繰り返しをしている日々が楽しくて仕方なかったと語ります。

プログラミングが楽しいというのは、Rubyを使いだして初めて気づいた感覚だったそうです。また、楽しさによって自分がどんどんプログラミングをしてしまったことから、人が行動を起こすのに「楽しい」という感覚が重要だと訴えました。そして、プログラミング言語を選ぶというのが重要だということにも、この時期に気づいたといいます。Rubyには、今まで島田さんが目指していたり、現場でチャレンジしてきたものが、当たり前のようにあったと述べました。

Rubyコミュニティと私

次に島田さんは、誰かとRubyについて話したり話を聞いたりすることで、よりRubyを知ることができると思い、アクションを起こします。まずは、日本Rubyの会のメーリングリストなどのオンラインコミュニティに参加したと振り返ります。しかし、オンラインでコミュニケーションをとることに気後れを感じ、札幌にRubyコミュニティがあるかということを探したそうですが、見つからなかったそうです。

そこで、Rubyについて話せる場所が札幌にもあればいいと思い、Ruby札幌を作ろうと考えました。そして、勇気を振り絞って日本Rubyの会へメールしたそうです。そのメールには、日本Rubyの会会長の高橋さんから後押しをしてくれるような内容の返信や、Ruby関西の小波先生からRuby関西のやり方を教えてくるような返信をもらえたと語ります。そして、最初のRuby札幌が開催されました。Ruby札幌でRubyについて他の人と話しができるようになったことで、また新しい体験ができたそうです。それは、好きなRuby以外のいろいろな言語を知ることを楽しいと感じたり、Rubyの機能がどうしてこうなっているか等のバックグラウンドの話が楽しいと感じたことだと言います。

RubyKaigiのスタッフへ

しかし、コミュニティを続けることで大変なことも見えるようになったそうです。そういった大変さを解決するために、他のコミュニティをやっている方の話を聞きたいと思いましたが、島田さんの周囲にいませんでした。そこでコミュニティについてよく知っている人から学びたいと思い、RubyKaigi2007に当日スタッフとして参加することを決意しました。RubyKaigi2007のスタッフの仕事を通し、人生で初めてプロジェクトを楽しいと感じたそうです。今まで、仕事上のプロジェクトでは、やりきったという充実感はありましたが、楽しいと感じたことが無かったと言います。また、Rubyを作っている人達に会うことで、自分とRubyコミュニティという関係が見え、そこに「文化」を感じたと述べました。そして、もっとRubyコミュニティの一員になりたいと思うようになったそうです。

Ruby札幌と私

RubyKaigi2007から帰ってきた後、島田さんは次のアクションを起こします。それは、Ruby札幌運営チームを作るということです。今までは、Ruby札幌を島田さん一人でやっていましたが、いろんな人たちと作っていきたいと思い仲間を作ったそうです。Ruby札幌をやっていて感じるRubySapporoWayとして、「⁠やってみたいと思ったことをまずやってみる⁠」⁠、「⁠面白そうなことをどんどんやる」という価値があると紹介しました。

自分達が面白そうなことをどんどんやることで、外部のコミュニティとのつながりが生まれてきたと言います。そこで島田さんは、Ruby札幌を知らない人たちにもRuby札幌の楽しさが聞こえるくらい楽しくやりたいと強く思い活動をするようになったそうです。そういう活動をした結果、角谷さんから「RubyKaigi2008の運営にRuby札幌の力を借りたい」と話があったそうですす。RubyKaigi2008で全力でRubyコミュニティに向かって頑張ったところ、2008年10月に行なった札幌Ruby会議01に札幌以外のRubyistたちが来てくれるというお返しがあったと述べます。RubyコミュニティからもらったものをRubyコミュニティに返したら、またもらってというフィードバックループを「渦巻き」に例え、島田さん自身が良い方向に進めていけている感じを表しました。

2つの言葉

最後に、何が島田さんの始まりとなった高橋会長の言葉である「たのしいRuby」「⁠軽い気持ちでも、とりあえずやってみることが肝要。まずはやってみないと始まらない」という2つの言葉を紹介しました。そして、「⁠みなさんが最後のRubyKaigiから思った、"したい"ということを大事にしてください」という言葉を発表を締め括りました。

桑田誠さん「O/R Mapperを支える技術⁠」⁠

桑田さんは冒頭で簡単なSQLを表示し、「⁠どこに問題があるかわかりますか？」と会場に質問をしました。

select * from sales where deleted_at is null order by amount desc limit 10

その後、一旦プログラミングの話にうつり、メソッド抽出のリファクタリングについて話を展開しました。ここで重要なのはプログラミングで、大きいものを複数の小さいものに分割する機能、そしてその分割したものを呼び出す機能、名前をつけて抽象化する機能があると説明しました。

あらためて先ほどのSQLを表示し、SQLの問題はプログラミングのように、大きいものを分割することや、それらを呼び出すこと、そして抽象化することができないのが問題だと述べました。SQLは抽象化機能で言えばシェルスクリプトにも劣るそうです。

クエリオブジェクト

次にO/R Mapperについて取り上げました。ActiveRecordのfindメソッドについて、これはRubyでSQLをかけるようにしただけでSQLの抽象化はできているとはいえないと述べました。同じくActiveRecordのnamed_scopeについてはこちらはSQLを抽象化できているとのことで、O/R Mapperが本来はたすべき役割なのだそうです。

プログラミング言語はアセンブラからC言語、C言語からオブジェクト指向言語、関数型言語など抽象化がすすむ方向で進化してきたと話す桑田さんは、SQLはプログラミング言語で言うアセンブラに相当するので抽象化機能がないのも仕方がないと話されました。O/R Mapperの役目はそのアセンブラのようなSQLを抽象化することなのだと語ります。

桑田さんはこれからのモダンなO/R Mapperを支えるのはクエリオブジェクトだと話します。ActiveRecordは2から3のバージョンアップでかなりAPIが変わりました。ActiveRecord3では、whereやlimit、orderなどのメソッドを呼び出すとクエリオブジェクトが返るAPIになっています。クエリオブジェクトが返ってくることで今まで文字列操作でSQLを組み立てていたところを、クエリオブジェクトに対してメソッドを実行することでSQLを組み立てられるようになったとのことです。whereやlimitなどのメソッド以外にもDataMapperの&や|での演算、Sequelの副問合せの機能についても説明しました。クエリオブジェクトはコレクションだという考え方があるとし、コレクションだととらえることでクエリに対してのdeleteやselectがコレクションに対する操作と同じように扱えるとも言及しました。

View-Layer Cache

View側でのFragment Cacheについて取り上げ、コントローラ側でDBへの問合せを行なうとリクエストの度に問合せが発生するためよろしくないという話をしました。Viewのキャッシュの中で問合せを行なうことで解決できるが、MVCに違反するためそれもよくない解決だそうです。この問題はMVCがPushスタイルに対して、Fragment CacheがPullスタイルであるためアーキテクシャがマッチしていないために起きるとのことでした。

これを解決するには問合せをProcに閉じこめることでコントローラ側で問合せが発生しなくなりますが、実はクエリオブジェクトで解決できると言います。クエリオブジェクトはオブジェクトを作った時点ではDBに問合せを送らないため、遅延評価的にViewで呼び出された時点でDB問合せが発生するようになるとのこと。このメリットはView側での修正が必要なく、MVCも維持できることだと述べました。

N+1問題

O/R Mapperでよくある問題の一つにN+1問題を挙げ、通常これを解決するにはEager Loadingを用いると言及しました。ですが、あらかじめ特定の関連を指定せざるを得ないため変更に弱く、例えばデザイナがView側で別の関連を呼び出したり、逆に削除したりするとコントローラやモデルなどの修正が必要になるとのことです。

DataMapperのEager Loadingでは、関連名の指定が不要でDataMapper側でうまく処理してくれているそうです。ActiveRecordには現時点でこの仕組みは実装されていないとのことでした。

Ruby to SQL

最後にRubyの式をSQLに変換する仕組みについて言及しました。Rubyの式を一度ツリーに変換し、そのツリーをSQLに変換するという仕組みだそうです。SequelではSymbolを拡張し、そういった仕組みを提供しているとのことでした。

Lightning talks 2

会期中2日目のライトニングトークスの、本日のタイマー係とドラム娘が紹介されました。

アジャイルUX公開実演 結果報告 、 樽本徹也 (アジャイルUCD研究会)

RubyKaigiの会期中に、公開実演をしていたアジャイルUX公開実演の結果報告です。勉強会支援として3日間で価値のある製品を作ろう、というテーマで実演を進めました。1日目ユーザーストーリーを作り、2日目、3日目の午前中までコーディングを行い、無事に終わったそうです。また、期間中にたくさんの人に立ち寄ってもらえたとのことでした。3日目にはまつもとさんがやってきてサインを行うような場面もあったそうです。

浮動小数点数リテラルが無い世界 、 村田賢太 (株式会社ジェネティックラボ)

BigDecimalのメンテナでもある村田さんの発表です。初めにSapporo RubyKaigi04を来年の夏に行うというアナウンスから始まりました。 まず、Floatの動作の難しさについて話始めました。浮動小数点とは、ある"数"であると人間は思いがちだけれど、コンピュータから見るとある数値のレンジを表すものなので誤差による差異に困ってしまう場合があります。 Rationalクラスをを導入することで解決もできるのですが、実際には分数で表現されても困ってしまいます。そこでRationalを小数点で表現するクラスを作りましたという内容でした。また、詳細についてはRubyConf2011で発表されるそうです。

BioRuby -- 生物情報科学用ライブラリ 、 後藤 直久 (大阪大学微生物病研究所附属遺伝情報実験センター)

Solaris で Ruby をコンパイルするのが趣味と語り、その縁でコミッタになったという出だしで始まった後藤さんの発表です。 DNAの表現や生物データの解析を行うライブラリで、gemパッケージとして配布されています。 現在は1.8.x系のサポートのみですが、1.9対応が終わりつつあるので、速やかにリリースしたいと話していました。 また、ライブラリにはプラグイン機構が導入さており、追加機能はプラグインとして実装することが可能だそうです。

新人教育に、もっとRubyを！ 、 吉田裕美 (EY-Office inc.)

最近の仕事としては萌えトークという、Skypeで声優さんから声優レッスンを受けられるWebアプリの開発をしました、という紹介から始めった吉田さんの発表です。 教育分野にも力を入れているEY-Officeでの新人教育事業では、Rubyが増えてきているようです。 新入社員へRubyやTDDを教える機会も増えてきましたが、そんな中で良く聞かれた質問があったそうです。良い教育用テキストがないという声に対しては『楽しいRuby』や、なければ自分たちで作ろう、と語りかけていました。 また、どうやって教えれば良いかという質問に対しては自分の体験を言葉で、コードで語るのが良いと話しました。

コミュニティと勉強会の間で , 三村益隆 (takkanm)

Asakusa.rb とRails勉強会@東京という、2つの有名なイベントに参加している三村さんの発表です。 2つのイベントに参加しているうちに、コミュニティと勉強会の違いについて気がついてきたそうです。 まず、コミュニティとしの特徴として、メインとなる強いファウンダーがいて、その人を中心に人が集まってくるそうで、継続するために無理のあるような体制にはしない、という話をしました。 また、勉強会としては、タイムテーブルが決まっていることもあり、話題を中心に人が集まってくるという印象だそうです。さらに、継続するために、改善することも忘れずに行っていくそうです。

define_method define_method 、 大林一平 (京都大学数学教室/京大マイコンクラブ(KMC))

Module#define_method を使うことで外側のローカル変数にアクセスできることを利用してクラス変数のようなことができます、ということをコードを見ながら説明をしました。 しかし、ここまでは普通のことですよね、と切り返し、インスタンス変数のようなものを作ることはできないだろうか？と話し始めました。 インスタンス変数のようなものを作るとして、オブジェクト毎に呼ばれるnewやinitializeメソッドをフックするという手もあるのですが、それでは確実だけど、つまらないですよねと話し、define_method で実行しつつ、 さらにdefine_methodを実行するという黒魔術の一端を語りました。

Rubyist に不足しているのは会計（そろばん⁠）⁠！ , 福井修 (株式会社iRubySystems)

6月に娘が結婚しました、という素敵な報告から始まった福井さんの発表です。 会計はかならずついて回るものなのですが、あまり馴染みはありません。しかし、これからはRubyistを始め、みんな知るべきことで、以前は読み・書き・ソロバンと言われていましたが、現在はIT・英語・会計が必要ですと語り始めました。 とくに、XBRLという会計用のXML拡張の仕様を操作するのに、Rubyにはnokogiriという素晴らしいライブラリがあり、技術的な順応はしやすいと語りました。その後、XBRLの説明や会計周りの現状とこれからについて、詳しく淡々と話していました。

ActiveLdap が Rails3.1 で動くようになったよ。 、 吉本任利 ((株)マーキュリー・ブレイン・システムズ)

ActiveRecordのようにLDAPのデータを操作できるActiveLdapが Rails3.1 へ対応したという報告を行いました。 以前まではActiveRecordへ依存していたのですが、ActiveModelへの依存へと変化させたことや、技術的にどのように実現したのか、等を語ってくれたのですが、吉本さんのPCで動いている通知アプリケーションのせいでTwitterでリプライするとスライド上に写ってしまうというアクシデントが発生してしまい、すこしの間リプライが止まらない状態になり、会場が大きく沸く場面もありました。

MmapScanner作ってみた 、 とみたまさひろ (長野ソフトウェア技術者グループ(NSEG))

Ruby歴13年で、Ruby/MySQLやMySQL/Rubyでもあるとみたさんの発表です。 以前のRubyのCSVパーサが遅かったので、LightCSVというCSVパーサを作ったそうです。 速度的には1.8系と比較ではだいぶ早いのですが、1.9系になってからは速度は大差ないものとなってしまったそうです。また、シンプルなはずなのに103行もコードがあると話していました。 それから本題のMmapScannerの説明をしました。いわゆるMmapをRubyから使いたかったのですが、Rubyでは扱おうとするとStringへコピーされてしまい、あまり速度がでないというところから、MmapScannerという拡張ライブラリを作成したそうです。特徴としては、メモリ上に読み込んだファイルの内容を正規表現で走査することができ、明示的な to_s をしない限りは同じメモリ上の参照を使い、Stringへのコピーが発生しないという点です。まだ課題はあるとしながらも前述のLightCsvに組み込んだところ、速度の向上やコード量の減少がみられたとのことです。

pebbles: rubygemsにおけるジョークモジュールの名前空間について 、 塩谷啓 (株式会社ドワンゴ / 東京Basic Technology勉強会)

カッパのアイコンでおなじみの塩谷さんの発表です。 以前、ジョークでzenraモジュールを書いたのですが、gem search -r zenとやると、マジメなgemに挟まれて一覧にでてしまってとても気まずいというところが発端となったそうです。 そして、gemの名前規則として、単語の区切りは"_"で行い、機能の区切りは"-"で行うという話があったことに着目し、ジョークで作成したgem用の名前空間としてpabbles（小石）という名前を使いませんかという提案がされました。

C、イ㌔。 、 郡司啓 (Asakusa.rb)

以前、卜部さんのブログが話題になったことに対して、誤解をされてしまうと困ると思って登壇しました、と話し始めた郡司さんの発表です。 C言語を使うなとは言っているけれど、学ぶなとは言ってないという話から始まり、RubyistがCを学ぶべき3つの理由として具体例を上げてくれました。

• コンピュータへの深い部分へのアクセス
• すごい人との繋がり
• 膨大な知へのアクセス

例えば、CRubyコミッタはこの会場に、すぐ近くにいますよねと語り、また、すぐそこにある先人達の知として、LinuxやRubyのソースコードを挙げ、書けなくても、読めれば良いので教養として身につけておくと良いと話しました。

まつもとゆきひろさん「三題噺: 振子とPGと百年の言語⁠」⁠

司会進行からの「最後のRubyKaigi、最後のキーノートです」という紹介を受けて、「⁠あまり無駄にハードルを上げないで欲しい」という苦笑混じりの言葉から始まったまつもとさんのスピーチ。Ruby界隈に多いエンターテナーな"芸人"たちと違いこう見えても私はただのプログラマーなんで、とおどけた謙遜で会場の空気をほぐし、講演は和やかにスタートしました。

またRubyKaigiがこれで最後といっても、地域Ruby会議やRubyWorld Conferenceのようなイベントはあるし、一般社団法人として再出発する日本Rubyの会での新しい取り組みもあるだろう、と今後への期待を寄せました。

肩書きコレクターMatz

まず自己紹介代わりとして、最近は「肩書きコレクター」になっています、と様々な活動に携わっていることを振り返りました。1997年からはネットワーク応用通信研究所（NaCl）のフェロー（最初は主任研究員⁠）⁠。2007年からは楽天技術研究所のフェローになり、ROMAやFairyといったRubyを大規模システムで活用するための技術開発に関わりました。同2007年はRubyアソシエーションの理事長にもなり、これはビジネス方面でのRubyの利用を支援する組織です。いわゆるSIerと呼ばれる人々が、まさかRubyに興味を示すようになるとは、と時代の変化への思いを語りました。

2009年には松江市の活性化に貢献したとして、名誉市民に選ばれました。松江市のホームページに行けば、ラフカディオ・ハーン等と一緒に並んでいるまつもとさんを見ることができます。同2009年は島根大学の客員教授になり、年に数回授業をしているそうです。また、2010年からは福岡県のRuby・コンテンツ産業振興センターの館長に就任。島根県松江市在住のまつもとさんはそこに常駐することはありませんが、無人の館長室には代わりに軽量Rubyで動くロボットが席に着いているよ、と発言していました。真意の程はいかがでしょうか。

Salesforce.comとHerokuからの支援

そんなまつもとさんの最新の肩書きが、RubyKaigi2011開催の数日前に発表されたHerokuのRubyチーフアーキテクトへの就任です。これは元々、Herokuの親会社になったセールスフォース・ドットコムの会長兼CEOであるマーク・ベニオフ氏が来日した時、是非まつもとさんも我々にJoinして欲しい、と話をしたのがきっかけだそうです。その時は社交辞令と思っていたまつもとさんでしたが、次の週には「いつJoinしてくれますか？」とメールが来て、彼らが本気だと知ったとのことでした。

Herokuへ入社と言っても、アメリカに引っ越すこともなく、今まで通り松江でRubyを開発し続ける立場に代わりはないとのことです。また、まつもとさんは元からフルタイムでRubyの開発をしており、まつもとさん自身を雇用支援してもRuby開発のプラスにはなりにくい。そこで、Rubyの開発を促進したいと強く考えているセールスフォースとHerokuは、社内にRubyコアコミッタのチームを作ることを決めたそうです。そしてまつもとさんの口から、なかだのぶよしさんがフルタイムのコアコミッタとしてHerokuに雇用されたことが明らかにされました。なかださんはCRubyに対するコミット数ランキングで一位と大きな貢献をされている方で、フルタイムでRuby開発に携われるようになればきっとRubyの開発に良い効果があることでしょう。そして、Herokuに参加してくれるコアコミッタ（能力があれば、現コミッタ以外でも）をまだ若干名募集している、と述べました。

言語の国ジャパン

以上を前置きとして、本題である発表タイトルの「振子とPGと百年の言語」について話を始めたまつもとさんは、まず日本という国の特異性に触れました。曰く、日本は言語好きな国である。例えば、まつもとさんが監訳をした『7つの言語 7つの世界』という本がRubyKaigiの会場で先行販売されましたが、こういったカジュアルな言語紹介本がたくさん出版されて売れることは海外では珍しいのだと言います。また、LL（Lightweight Language）全体を題材としたイベントもアメリカでは3回で立ち消えになったが、日本では今も毎年開催されて皆喜んで集まる。日本が言語好きな国というのはもっと自覚されていいのかもしれない、とまつもとさんは語ります。

言語の実装に関しても、学術的な本は海外にも多いが、カジュアルに言語実装が学べる本があるのは日本特有で、それが年に複数出ていたりする。高校生ですら言語を作る人がいて、まがりなりにも動くものを作ってプログラミングコンテストに応募してくる。海外ではあまり知られていないけれど、日本語で動くプログラミング言語すらあると言及しました。

日本という蠱毒

こういった日本の状況を、まつもとさんは蠱毒（こどく）に例えます。壺の中に虫を沢山入れ、殺し合わせ、生き残ったものを使って呪術を行うという古い呪いが蠱毒です。日本の場合は、日本語という言語障壁で囲み、狭い中で言語好きを競わせ、生き残ったものが世界を制するために外へ出ていく、というわけです。もしかしたら「次の言語」は日本から出てくるのかも？との展望を示しました。

だとしたらそれは一体どういうものになるのか、ということも簡単に披露しました。それはアカデミックな場所から出てくるのではなく、ハッカーによるハッカーのための言語であること。全く新しいプログラミングパラダイムを持って登場するのではなく、既にあるものに対する優れたユーザーエクスペリエンスを重視していること。新規性より組み合わせの妙による「おもてなし」が意識された言語だと言います。

とはいえ、もちろん日本という壺の中には、まつもとさんのRubyも含まれています。まつもとさんは自身をかなり負けず嫌いな人間であると評し、言語の比較でRubyが他の言語に負けているという状況があると、内心では凄く悔しいのだそうです。よって、日本から「次の言語」となるような新言語が出てきたならば、それは全力で迎え撃つつもりである、と意気高く宣言しました。

未来の言語

次にまつもとさんは目線をさらに先に置いて、未来の言語はどうなるのか、を話し始めました。技術には静的型／動的型、オブジェクト指向／関数型、集中と分散など、時代によって流行と言われるものがあります。こういった変化は振子のようなものであるとして、振子の先だけを見ていても次がどうなるのかわからず、大局的な変化の方向を見失ってしまうのだそうです。

では未来を見据えるための大局的な変化とは何かといえば、ムーアの法則によって、より早くて安くて大容量な大量のマシンが使えるようになること。このことが言語に与える影響とはつまり、効率のためにプログラミング言語のデザインを決めなくてもよくなることです。現在では効率の呪縛により、デザインの歪みのようなものが発生しているが、未来においては本当に自由な言語デザインが可能になる。言語を使う人間のための設計に集中することができると語ります。

Paul Graham

ここで出てくるのが、セッションタイトルにある「PG」です。PGとはProGrammerでもProgramming Gengoでもなく、Paul Grahamです。まつもとさんとほぼ同世代のポール・グレアムはLispハッカーであり、Viawebを創立し後にヤフーに売却した起業家であり、現在はスタートアップを支援するベンチャーキャピタルであるY Combinatorを手がけています。またエッセイストでもあり、『⁠ハッカーと画家』という著書でよく知られています。

その『ハッカーと画家』に出てくるエッセイが「百年の言語⁠」⁠。彼は百年後の言語を想像することで、現在の言語の進化を促進させることができるだろうか、という思考実験を行っています。彼も先ほどのまつもとさんの考察同様に、未来においてはずっといいマシンがあるのだから、言語の実行効率はクリティカルな問題ではなく、必要なのはプログラマの生産性のための言語であることを挙げています。

逆にまつもとさんがポール・グレアムに同意できない点は、彼が大好きな（Lispの）マクロが言語に必須であると言っていること、そして言語のコアの要素がなるべく小さくなるような最小コンセプトを推進しようとする部分とのこと。

まつもとさんが考える未来の言語とは、つまりこうです。現在の水準からしたら無限とも思えるリソースで機械の側の都合を無視し、人間が如何にして自分がやりたいことを伝えられるかという観点に立ったら、自然言語に起こってきたようなことが起きるのではないか。そう考えると、マクロ付き自然言語や最小コンセプト自然言語などは今も人間の脳が本能的に求めていないためありえないとすると、未来の言語においてもそうではないか、と述べました。

百年の言語であり続ける

未来に起こるだろう変化について語り終えたまつもとさんは、最後にこの先100年を生き延びていく言語にあるだろう特徴を挙げていきました。それはやはり、自分が書くときにどうエンジョイできるかを考えられるハッカーの手による言語であり、プログラムを書く人がどう感じるかを重視する優れたユーザーエクスペリエンスを持つ言語であり、言語側がまるでプログラマを歓迎しているような「おもてなし」の精神のある言語が有望であると言います。

「それなんてRuby？」というノリツッコミで会場を沸かせたまつもとさんは、「⁠百年経ってもRubyでいいよね⁠」⁠、と今後への展望を語りました。これから先出てくるだろう新しい概念も取り込める柔軟なRubyでありたい。そのためには、私たちプログラマも、新しい物を柔軟に取り込んでいける存在になれるかが重要ではないか、としました。そして、新しい分野や概念の源泉として、Rubyコミュニティがあり続けて欲しいとも述べ、そのためにこうやって顔をあわせて集まれるイベントが、今後も続いていってほしいなと、最後のRubyKaigiへの手向けの言葉も寄せていました。

さらに、百年の道中を共に切磋琢磨して歩んでくれるような言語を作るライバルも歓迎するとのことでした。もちろん全力で迎え撃つけどね、と変わらない負けず嫌いさを見せるまつもとさんでした。

最後にまとめとして、大人げない大人になろう、自分で作らないと未来は来ないのだから、未来を作りましょう。空気を読みすぎて自分をひっこめたりせず、sora_hくんのようにイキイキと行動しましょう、との言葉で発表を締め括りました。

クロージング

実行委員長の高橋さんより、クロージングが行われました。「⁠楽しめましたか？」という言葉を投げかけ、本イベントを振り返りました。次回のイベントについては「一般社団法人日本Rubyの会先生の次回作にご期待ください」と述べました。

最後は、スタッフ全員が壇上に招かれ、スタッフへの労いの言葉がかけられるとともに、参加者に対してイベント参加へのお礼を改めて述べました。クロージングの終了時には、スタンディングオベーションが起こり、本イベントの成功を参加者と共有する形で幕が引かれました。

メッセージボード

るびまやRubyKaigiへのメッセージボード、RubyKaigiへの寄せ書きが設けられました。たくさんのメッセージが寄せられました。

3日目!RubyKaigi

3日目もアンカンファレンス形式の!RubyKaigiが催されていました。

3日目サイン会

お昼休みに、『⁠アジャイルサムライ』（⁠オーム社）の監訳者、西村直人さん、 角谷信太郎さんによるサイン会が行われました。長蛇の列ができていました。

今年のRubyKaigiのレポートは以上になります。最後までお読みいただきまして、ありがとうございました。