9月14日から16日の3日間、札幌市産業振興センターにて札幌Ruby会議2012 が開催されています。3日間に渡り、随時レポートをお届けします。ここでは2日目の内容をレポートしていきます。
昨日とは会場受付等の場所が変更されています。受付は建物入り口すぐに移動しました。
アンカンファレンス形式の、ぬRubyKaigiは、受付場所とは別棟の3Fで本日、明日と開催されます。まだまだ空いている時間帯がありますので、発表したいネタがある方は気軽に検討してみてください！
佐藤竜之介さん「コミュニティのある風景。」
Ruby札幌に所属し、Nothubの開発者である佐藤竜之介さんの発表です（スライド等はこちら ） 。札幌Ruby会議2012のテーマである「We Code.」について、佐藤さん自身が考えることをまとめました。
プログラミングとの出会い
佐藤さんがはじめにプログラミングと出会ったとき、コードを書くことが楽しかったそうです。しかしそのコードは、大きなソフトウェアの一部分であったり、ドキュメントを書くといったことで、オープンソースソフトウェアとの関わりもあまりありませんでした。
「もっとコードを書きたい」から オープンソースへ
もっとコードを書きたいと思い、佐藤さんが現在勤める株式会社えにしテックに入社しました。そこで、今となっては普通に使っている、Mac OS Xや、コマンドライン、GitなどといったOSやツールに触れることになったそうです。その頃からオープンソースのプロダクトを使う機会が増えてきました。
これまではプロダクトというものは、どこからともなく大きいものが出てくるというイメージだったのですが、実際は中に作っている人がいて、日々開発を行なっている。また、読もうと思えばソースコードを読むことができる。佐藤さんは、こうしいった点に「楽しさ、魅力」を感じたと言います。
魅力からGithubへ
オープンソースの「楽しさ、魅力」を感じ、佐藤さんはGithubを用いて気になるプロダクト、気になってる開発者を追いかけ始めました。普段の開発のなかでオープンソースのプロダクトを用いていると、バグを発見する場合が多々あると思います。佐藤さんは手元で直すことができたら本家に送りたいと考えました。
GithubであればPull Requestという機能があるので、この機能を使おうと考えたそうですが、Pull Requestには「怖い」「 恥ずかしい」「 気が引ける」といった不安があったと話します。このような恐怖を取り除くためには、安心できるまでチェックして自信をもって送ることだとし、そのために佐藤さんは「本当にバグ？」と疑い、次の観点から本当にバグか調査を行いPull Requestを送っているとのことです。
commit logのチェック
MLでの議論
テストの有無（バグではなく作者の意図ではないだろうか）
作者の意図に合っているだろうか Pull Requestを送るということ
佐藤さんが初めて送ったPull Requestは簡単なもので、READMEの記述ミスの修正でした。この修正自体は小さなものでしたが、みんなが使うプロダクトに自分のパッチが入ったこと、自分が困り解決したことでみんながよろこぶことに嬉しさを覚えたそうです。
このPull Requestにより、プロダクトというものは「自分ひとりではない開発。嬉しい、もっと書きたい」と強く思うようになったと言います。
佐藤さんが送ったPull Requestの例としては、次のようなものがあります。
active admin のマルチバイト対応
active admin の日本語ロケールの文言編集
CapybaraのスクリーンショットをpublicなAPIにする提案 しかしながら、いつも良いPull Requestを送ることができたわけではなかったとし、例えばhomebrewというプロジェクトに送ったバージョンアップのPull Requestは、同じ内容のものを少し早いタイミングで送った人がいたことを挙げました。このとき、先に送った人は「こっちと同じだよ。でもありがとう」とコメントをくれたようで、この最後のありがとうのおかげで報われた気がしたそうです。
良いPull Requestではなくとも、Pull Requestを送るとプロダクトに対する「作者の意図」や「目指すもの」 、「 考え方」を教えてくれるので、失敗ではないとのことです。
Nothubの開発へ
パッチを送る量が増えるにしたがい、自分の送ったPull Requestへのフィードバックが気になり、好きなハッカーがどういうことに興味があるのかなど、Githubのタイムラインが気になり始めたそうです。何度もGithubのページを見に行くのもあまり良くないと思い、Githubのタイムラインを通知してくれるサービスを探したが、自分に合うものは見つからなかったとのことです。そこで、無いのなら自分で作ろうと思いたち、Nothub を開発しました。
このNothubは、Githubのイベントを通知してくれるChrome Extensionです。Nothubを使うことで、新しいライブラリに出会うことも多くなり、一層バグなどを発見しやすくなることを示しました。
We Code.
ここまでPull Requestでみんなと開発を行うことについて説明しました。佐藤さんの中では「Pull Request = We Code?」の答えは「No」であるとし、Pull Requestはあくまでコードを通じて会話をする手段なだけだとしました。このPull Requestを使って行なっているのは「とてもふつうの開発」だと言います。
また、テキストベースの開発よりも、もっと身近にパソコン並べて一緒に座って開発したい！という気持ちがあるそうです。そして、その開発を実現できるのが佐藤さんにとって「Ruby札幌」でした。「 みなさんの周りにそういう場所はありますか？」と会場に問いかけ、佐藤さんはもしなかったら「自分で作ろう！」と語りました。実際に佐藤さんも札幌でJavaScriptの勉強会であるSapporo.jsを立ち上げ活動しています。
まとめ
Pull Requestであっても、最寄りの場所でも、人と一緒にコードを書ける場所があるということは尊いことだとし、このような場所から次のものを得ることができたとのことです。
ひとの考え方
プロダクトの文化
一緒にコードを書く仲間
そして、「 もっとコードが書きたくなる気持ち」 最後に佐藤さんは、もしかすると「今この場も、そんな場のひとつかもしれません」と締めくくりました。
前田修吾さん「Purely functional programming in Ruby」
Rubyコミッタ、NaCl取締役、Rubyアソシエーション事務局長であり、さらに釣り人でもある前田修吾さんによる発表です（スライド等はこちら ） 。今朝近くの川へ釣りに向かったものの、何も釣れずにがっかりされたそうです。
関数型プログラミングの定義
関数型という言葉はオブジェクト指向と同様に、定義がはっきりしていない部分があります。そこで、前田さんはまず今回のセッションで触れる関数型プログラミングとは何を指し示すのかを定義しました。
今回は「関数型プログラミングとは、副作用を用いないプログラミング」という定義にしたそうです。関数型は定義を書くのに向いていますので、関数型のセッションが関数型の定義から始まるというのもおもしろい構造ですね。
それでは副作用とは何でしょうか。副作用とは同一の変数に以前と異なる状態を保持するというもので、前田さんは例として変数の再代入、オブジェクトの状態変更、入出力を挙げていました。
Rubyは関数型プログラミングか
なぜ関数型プログラミングという技術が着目されているのでしょうか。いくつか技術的な理由もありますが、大きな理由は何かかっこよさそうだからだと話します。
Rubyは関数型でしょうか？ ブロックやlambdaがある点、ifが文ではなく式である点などは関数型言語の特徴を受けていますが、基本的なデータ構造は短命データ構造であり、実装としては命令型であるとのことです。
短命データ構造と永続データ構造
短命データ構造とはArrayやHashのような、破壊的な変更を加えると前のデータが失われるデータ構造のことで、変更を加えても元のデータが失われない（破壊的な変更ができない）データ構造のことを永続データ構造と呼ぶそうです。
関数型プログラミングでは永続データ構造を用いるため、破壊的な操作を行えないListというクラスを新たに定義して、関数型プログラミングのトピックである再帰、遅延評価、メモ化、遅延ストリームなどを行えることを示しました。
Rubyの末尾再帰
再帰ではメソッドを呼び出すごとにスタックというものが増えるため、Rubyで行うとすぐにスタック数の上限に達してしまい、StackOverflowというエラーになると言います。
関数型言語では、メソッドを呼び出してもスタックを増やさない末尾再帰という機能があるため、スタックの上限に達しにくいように工夫しているそうです。
実は、Rubyには既に末尾再帰が実装されているのですが、コード内にて明示的に有効化しなければならず、あまり知られていないため利用しているユーザーは少ないのではないかと話していました。もしかすると2.0ではデフォルトで有効化されるかもしれないとのことです。
gem化とベンチマーク
今回のセッションで説明したコードはimmutable というgemにまとめられているとし、このライブラリを用いて、通常のArrayと速度の比較を行ったところ、10-50倍ほど遅いため、通常のプロダクトではまだArrayを利用したほうが良いとのことでした。
質疑応答では、immutableの遅延評価はマルチスレッドに対応しているかという質問があり、していないという回答でした。
Shota Fukumori (sora_h)さん「Social Coding をはじめよう」
元「中学生」Rubyコミッターとして知られるsora_hは実践的なGitHubの活用法について発表しました（スライド等はこちら ） 。現在はアルバイトとしてCookpad社に勤め、「 中卒フリーター」を名乗っています。
GitHubはどこがソーシャルなのか
はじめに「GitHubの回し者ではない」と断った上で、今回のセッションではGitHubを使ったソーシャルコーディングについて解説を行いました。「 GitHubのアカウントを持っている人は？」と会場に挙手を求めると、会場のほとんどの人が手を挙げていました。また「GitHubに積極的にコードを置いている人」「 Pull requestをしたことがある人」「 プライベートリポジトリを使用している人」などにも少なくない数の人が手を挙げました。
GitHubではTwitterのように人をフォローしてダッシュボードにコミットが流れてくる、プロジェクトに"star"（お気に入り）をつける、"watch"して議論を追う、コミットにコメントを残せる、などの機能があります。しかしGitHubを「ソーシャルコーディング」たらしめるのは"Fork"と"Pull Request"ではないでしょうか。
"Fork"とは、他の人のリポジトリをフォーク(分岐)して、自分のリポジトリにコピーする機能です。このリポジトリは自分専用にカスタマイズしたり、パッチを書くために活用することができます。そして"Pull Request"です。これはパッチをFork元のリポジトリに送るための機能です。"Pull Request"の"Pull"とは、`git pull`の"pull"です。ただし、後述しますが、Pull Requestは同一リポジトリの別ブランチにも送ることができます。
GitHubではパッチを送る手順は「forkする」「 コミットする」「 pushする」 、そして「Pull Requestする」です。この方法を一度覚えておけば、あとはどのリポジトリに対してでもスムーズにパッチを送ることができるようになります。
Pull Requestのベストプラクティス
ここからが本題で実際にPull Requestを送るためのベストプラクティスを紹介しました。
まず、使用しているライブラリなどに不満を抱いたとします。例えばバグがあった、ほしい機能がないなどの理由です。GitHubでリポジトリのページを開き「fork」ボタンを押します。押したら自分のリポジトリを`git clone`しましょう。コードを編集する前にトピックブランチを切ることを忘れないようにしましょう。`git checkout -b foo master`でmasterから新しくfooリポジトリを作成することができます。
コードが完成したらコミットしてGitHubにpushします。そしてブラウザでGitHubに戻り、ブランチを選びます。このときに'wキー'を押すとマウスを使わずにブランチを選ぶことができます。変更を加えたリポジトリに切り替えたらPull Requestボタンを押し、タイトルと概要を書いて送ります。
Pull Requestのタイトルはパッチの内容を簡潔にまとめます。バグならば、概要にはバグを再現する最小手順を書きます。確認する方にも再現コストがかかるので、可能な限り単一のbug.rbなど小さなスクリプトにまとめると良いでしょう。また、「 何が起きたのか」「 何を想定していたのか」説明することも必須です。
機能追加した場合は、その機能が何に使えるのか、どう使うのかを説明できると良いと言います。プロジェクトによってはテストコードが必須の場合があります。Pull Requestを提出したあとでも追加コミットをpushすれば反映されますので、指摘されたら直しましょう。時間がかかりそうなら「テストはいま書いてます」などと書けばよく、指摘されても怖がらずに対応しましょう。また、GitHubではMarkdownという形式が使用できるので、項目ごとに「Use case」「 Usage」など見出しと読みやすくなるとしました。
おもに日本人向けのベストプラクティスとして、日本人が相手でも英語で書くことを挙げます。日本語を併記しても良いですが、英語でも書きましょう。できないなら勉強が必要ですが、コードで語ることがとても有効ですので、拙い英語でもコードで伝えることはできるでしょう。また"I want this method!!!!!!!!!!!!!!!!" で取り込まれた例もあり、人と場合によっては熱意で通ることもあるそうです。ここまで来れば、あとは「send」ボタンを押すだけです。反応を待って、修正や質問などのフィードバックがあれば真摯に対応しましょう。
GitHubの活用について
冒頭でプライベートリポジトリの使用について会場への質問がありましたが、有料のプランにすると外部から見ることのできない非公開のリポジトリを持つことができるようになります。学生の場合は無料で使用することができるとのことで羨ましいと言っていました。
また、企業のイントラ内でGitHubを利用したい場合は、値段は張りますがGitHub:Enterpriseを利用するなどのプランが用意されています。これらのプランすべてで、もちろんPullRequestの機能を使用することができます。
また、hubというコマンドラインツールがあり、これを使用することでブラウザを開かずにシェルからgithubの機能を使うことができるようになります。例えば「既存のissueにパッチを添付してPull Requestを送る」という操作を行うことができ、便利とのことでした。
辻本和樹さん「Pattern Matching in Ruby」
Rubyには無いパターンマッチについて、Rubyコミッタの辻本和樹さんが発表しました（スライド等はこちら ） 。
Ruby2.0のリリースが2013年2月24日に予定されています。Ruby2.0というのは、長らくRuby開発者にとって遠くにある目標、言わば人参のようなものでした。
2.0のリリースがされると、その遠くにある目標がなくなってしまいます。そこで、次なる目標としてパターンマッチを入れるのはどうかと提案しました。辻本さんはこの発表、この提案が新機能の議論の下地になることを期待しています。
パターンマッチとは
パターンマッチについて、Rubyの多重代入のコードを例示して説明しました。そして次の3点を多重代入の問題点として挙げました。
Arrayに限定されること
個数の確認ができないこと
途中の式を拾えないこと 多重代入の問題点は、次のように言い換えることができます。
パターンマッチによってこれらの問題点を解決することができるそうです。
Rubyにおけるパターンマッチ(本題)
辻本さんは、自作のライブラリであるpattern-match の基本的な使い方とともにテキスト処理の利用例を紹介しました。また、パターンマッチがある場合とない場合のソースコードをユースケース別に複数提示しました。例えばCSVや木構造の処理を比較的簡単に書くことができます。パターンマッチがある場合は、処理すべきテキストのパターンに集中すればよいため、よりシンプルにプログラムを書くことができます。
新機能としてRubyのコアに取り込みたい理由
パターンマッチを実装することで、Rubyのプログラムをよりわかりやすく書くことができるため、Rubyのコアに取り込みたいと考えています。しかしながら、現状の実装ではmethod_missingを多く利用しているので、実行が遅かったり問題があるかもしれないと考えています。
まとめ
パターンマッチはとても強力なので、辻本さんが発表で例示したユースケースだけでなく、実際にユーザーがライブラリを利用して得られるパターンマッチのユースケースを共有して、コアへ取り込んでもらう際の説得材料としたい。そのために皆さんでパターンマッチをたくさん使ってもらいたいと締めくくりました。
Aaron Pattersonさん
@tenderlove、たこやき仮面（ruby-list メーリングリスト）などでも知られる、著名なRubyist Aaronさんによる「サラミ」の発表です。
It my turn
Aaronさんは、「 ruby conf」で日本人が英語で発表しているのをみて、自分もいつかは日本語で発表したいと思っていたそうです。6年間日本語を勉強してきて、ついに今日、それが達成されました。
「ゆっくり喋りますので、もし間違えても恥ずかしいので翻訳しないでください」の一言で会場が爆笑の渦に巻き込まれていました。実際、彼の日本語はとても丁寧で分かりやすいものでした。
We Eat
「食べることは楽しい」「 友達と作った料理を食べるのはもっと楽しい」「 危ない料理はおいしい」 。おいしい（=食中毒になりそうな）サラミを作るのが好きなAaronさんですが、自分が作ったサラミで友達を殺したくはありません。衛生管理について十分な予習をした後実際のサラミ作りを行なったそうで、そのことについてアツく語ってくれました。
「良いバクテリア」は酸性の環境をつくり、悪いバクテリアを育たなくすること。良いバクテリアがサラミの味を形成すること。そのために肉に対して重量比で0.012%のバクテリアを投入しなければいけないこと。塩を入れて悪いバクテリアの繁殖を抑えること。0.0143%の亜硝酸塩を入れることでボツリヌス菌を発生させないこと。水分を蒸発させることで悪いバクテリアを退治させること。温度ははじめの3日は良いバクテリアを培養するため21度、その後30日は15度に設定すること。
それぞれをあまりにもマジメに、しかも日本語で語るもので、会場は大爆笑です。
サラミ作りでは冷蔵庫の温度管理がとても重要です。サラミ作り専用の冷蔵庫を用意し、モニタリングするデバイスまで作成してしまいました。
ここまで、まだRubyのRの字も出てきていません。
We Play
食べることは楽しいです。でも、サラミ作りのデータを解析したら、もっと楽しいとAaronさんは考えます。データはデジタル信号で送られてくるので、それを解析します。
そして、解析したデータを紹介されました。室温の推移状態で、Rを用いて算術平均を求めることで正規化した情報を求めます。室温は12度から15度に推移していることを説明されていました。高速フーリエ変換を用いてスペクトル密度を求めていたり、上限実数の位置を求めたりもされていました。
良く分かりませんが、すごいことをやっていたようです。やっとRが出てきましたが、RubyのRではありませんでした。
We Code
ここで「集まったサラミ用データをシェアしましょう。Rails4で」と言い出したAaronさん。
リアルタイムシステムは、入出力のオブジェクトで簡単にリアルタイム処理ができるとのことです。AaronさんはPipeとThreadを使って実装されていました。1秒ごとにパイプにデータを送るようなスレッドを作り、スレッド内では送られたデータを即座に読み取ります。Aaronさんは、これが一番簡単なリアルタイムシステムの実装だと考えているそうです。
アメリカでは「The Cloud is a series of Tubes.」という言葉がありますが、Aaronさんは「The Cloud is a series of Pipes.」と思うとのことです。なぜなら、RailsにPipesと同じように機能してほしいと思っているからだと仰っていました。「 ActionController::Live」を使うことでRailsにIO.pipeと同じようなことをさせることが可能のようです。
HTML5の機能であるSSE（Server Sent Events）を使うことでサーバーのイベントをブラウザに送ることが可能で、クライアントはJavaScriptで実装されていました。ただしIEでは動かなかったようです。コード上では、IOオブジェクトのように記述していますが、実際のサーバーとクライアントとのやり取りではオブジェクトとレスポンスをSSEに書き込んでいます。
まずサラミを収めた冷蔵庫（Publisher）のデータをcreateアクションでBusに知らせます。Busはイベントを複数のSubscriberへ知らせることができ、Thread内では共有される仕組みになっています。
ブラウザ（Subscriber）はあらかじめBusに対してイベントを登録しておくことで、サラミを収めた冷蔵庫がデータをBusに知らせたら、すぐにそのデータを受け取ることができます。データは、サーバからSSEの形式でブラウザへ送られてきます。
最後にサーバからクライアントへ送った値を分かりやすくするために、GChartを使うことでグラフにされていました。
終わりに
このスライドは今回の札幌Ruby会議のテーマである「We Code」を表したものであり、このスライドが共有されることが目的であるとのことです。今回発表したサラミのデータを共有する話からも、みんなでデータを共有したいからこそできたものだと感じているそうです。
また、Rails4はまだ開発途中ですが、リアルタイム処理が強化されそうなことが良くわかることから期待が膨らみます。
まつもとゆきひろさん「One size does not fit all」
2人目の基調講演はご存知Rubyの生みの親、Matzこと「まつもとゆきひろ」さんです。まつもとさんはRubyKaigiでは基調講演皆勤賞で、また札幌で開催された「札幌Ruby会議03 」に引き続き今回の「札幌Ruby会議2012」でも基調講演を引き受けていただきました。
本セッションではまつもとさんがコードを書く、ということについて感じることやモチベーションが生み出すこと、そして多様化するRuby処理系について語りました。
We Code.
まつもとさんはまずコードを書く人に向けて話をすると宣言し、コードを書くことについての思いを話し始めました。コードを書くことは自分の存在意義でありとても幸せなこと。よくプログラマの35歳定年説と言われていますが、以前まつもとさんもその例に漏れずプロジェクトマネージャを任されたことがありました。コードを書く事が好きなプログラマにとっては実に砂を噛むような仕事をやらなければならず、結果的にそのプロジェクトは大炎上してしまったそうです。しかしそれが功を奏し、今もプログラムを書き続けることができて幸せだといいました。
Rubyは1993年2月から始まった
まつもとさんはなぜRubyを生み出したのでしょう。最近ある人からこんな質問を受けたそうです。「 どうしてPerlがあるのにRubyを作ったのか。車輪の再発明だし人的リソースの無駄遣いなのではないか」と。まつもとさんはこの質問に対し、もっとも大事なのは人的リソースではなく、何かを創りだそうとするモチベーションだと主張しました。新しいプログラミング言語を作りたいというモチベーションをもった人に、それを諦めさせることは偉大なことを成し遂げる可能性を失うことになると話します。
作りたいものがたとえ車輪の再発明だとしても、やりたいというモチベーションがあるのであれば、まつもとさんはそれをやるべきと言います。なぜなら多様性は善であると信じているからです。この言葉はまつもとさんが自分の中で持つルールの中でも上位に位置する大事な言葉とのことです。
また世の中に数万は存在すると言われているプログラミング言語を例に挙げ、多様性にはコストがかかるが、それはイノベーションを生むためのコストになりえると言います。しかし実際にイノベーションがどうして起こるのかは誰もわかっていなく再現性も無いため、例えばまつもとさんと同じようにしようとしても上手くいくとは限りません。だから余計な心配をせず、自分がコードを書くことにアイデンティティを感じるのなら楽しくコードを書こう。そしてハッピーになろうと述べました。
広がるRubyの世界
まつもとさんはTwitterやGitHub、Square、Heroku、EngineYard、Cookpad、楽天などでRubyが使われている有名なサービスを例に挙げ、RubyはWebの世界で多く使われるようになったと言います。多様性を善とするRubyはこれまで様々なプラットフォーム環境下で動作する処理系が開発されており、具体的にはJRubyやRubinius、MagLevについてそれらの特徴を示しました。様々な処理系が存在することによって今では多くの環境にてRubyを活用することができています。
Web、PC以外にもソフトウェアが活用されている領域として、モバイルフォンや情報家電、自動車、ゲーム機などの組み込みの分野があり、まつもとさんはこれらを含めたあらゆるところでRubyを使いたいと述べました。
そこでまつもとさんはmrubyを作り始めました。mrubyの最大の特徴は組み込み向けのAPIを持っているということです。リアルタイム性を高めるためにGCはインクリメンタルGCを採用しており、軽量化のためにIOや正規表現などのいくつかの機能を外しています。
様々なデバイスで動作することのできるmrubyはiPhoneやAndroidはもちろんのこと、ルーターや自動販売機、LEGO mindstormsに組み込まれた実績もあるとのことです。ソースコードは今年4月にGitHubにMITライセンスで公開されているので自由に試すことができます。
We Code, Therefore We Are.
最後にまつもとさんは"We Code, Therefore We Are."「我らコードを書く、故に我らあり」と言及し、これが私達のアイデンティティであるとしました。「 私達が私達の幸せを、コードを書くことに探すならば、幸せを見出すことができるのではないか。幸せになっていただきたい」という言葉を残して本セッションを締めくくりました。
Danish Khanさん「Γυβψ のコミュニティ」
GitHubのDanish Khanさんが、Rubyのコミュニティにおいて取るべき行動について発表ししました（スライド等はこちら ） 。ここでいうコミュニティとは、ソフトウェアの開発にあたってのコミュニティ、特にオープンソースソフトウェアのコミュニティを指しています。
このセッションでは、Danishさんがコミュニティで感じたことを踏まえ、コミュニティで活動するにあたってどんな行動を取るべきかということを話しました。
「Matz is nice and so we are nice」であるべきこと
最近ではRuby on Railsが流行し、書籍や採用事例が増えたことで、多くの人がRubyのコミュニティに加わるようになりました。しかしその一方で、プログラム言語の人気度指標の一つであるTIOBE Index では、Rubyはかつては9位で、2012年5月には11位に落ちています。DanishさんはRubyの人気が上がってこない理由の一つに、RubyコミュニティがMINASWAN（Matz is nice and so we are nice）に沿ってないことがあるのでは、と言及しました。
文句が多かったり口調が悪いコミュニティからは、人は離れたくなるものだ、とDanishさんは言います。人がついてくるには、礼儀や敬意が必要と指摘しました。
プロジェクトを引き継げるようにすること
Danishさんは、自分が使いたいと思っていたRubyのライブラリにpull requestを送ったものの反応がなく、結局別のライブラリに乗り換えたことがあったと述べていました。自分が貢献できるソフトウェアを使いたい、という気持ちが働いたそうです。
もちろん、プロジェクトを一度立ち上げても、時間がないなどの理由で放置せざるを得ない場合もあります。しかしそういったときのために、ほかの人がプロジェクトを引き継げるようにしておくことが重要だとDanishさんは述べていました。その具体的な方法として、mojodna氏の発表 を紹介しました。
他の「コミュニティ」との対比
Ruby以外のさまざまなコミュニティから、われわれが学べることがあるとし、いくつかのIT技術系ではないコミュニティの例を挙げていきました。
Danishさんはまず、ボーイスカウトの意識である「集団行動」「 他の人を尊重すること」や、プロスポーツチームにおける「個人の力のみならず、チームでも力を発揮すること」を見習うべき意識と述べていました。またソクラテスの述べた「メンターの重要性」 、アリストテレスの「人に教えることができるというのは、自分がよく分かっているということ」も挙げていました。
コミュニティの一員として取るべき行動
最後にDanishさんは、「 Solutions - Yes We Code」という表題で、コミュニティの一員としてあるべき行動をしようと話します。
まず、基本的な意識として「お互い敬意を持って接する」 。ソフトウェアを作る際の具体的な行動として「READMEファイルを付ける」「 よいドキュメントを書く」「 例を載せる」「 ほかのメンテナを見つける」 。またGitHubにおける行動として「GitHubページを使う」「 issueにラベルを付与する機能を用いて、初心者/中級者/上級者を分ける」「 pull requestを送る」といったことが挙げていました。
セッション後の質疑応答では、「 GitHubでホストされているソフトウェアで、元の開発者のメンテナンスが止まった場合に対策ができないか」というものがあり、これに対してDanishさんは「まだすぐに出せる成果はないが、フォークされた方のレポジトリの方がアクティブならば、そちらを検索結果において優先して出す、といった対策などを検討している」と話していました。
Rubyでは、作ったソフトウェアをソースコードごと公開するということは多いです。すでにそのような活動をされている方にとってはもちろん、まだソースコードを公開する活動をされていない方にとっても、この発表は「ソースコードを公開するというのはどういう意識か」ということを考える契機になるのではと感じました。
原田洋子さん「アメリカのカンファレンスに行こう！」
@yokoletこと原田洋子さんはJRubyやNokogiriのコミッタであり、今年「Ruby Hero 2012」に選ばれました。これは、日本人としては初めてのことです。しかし、今回はJRubyなどの技術的な話はせず、まあ楽しもうじゃないか、とセッションが始まりました（スライド等はこちら ） 。
最初の一歩を踏み出す勇気
初めて参加したアメリカのカンファレンスは2010年の「RailsConf」だったそうです。このカンファレンスには「とにかく行ってみたいと思って行った」とのことでしたが、ここで原田さんは「人生が変わった」と言います。ここで会ったひとたちを写真で紹介し、@tenderloveに声をかけられたほか、「 画面に入りきらない」さまざまな人と交流を持つことができたそうです。
当時原田さんはミシガンの田舎でひとりプログラミングをしていましたが、このときの体験で世界が開けたと話します。RailsConfの場で原田さんは「素晴らしいソフトウェアを作ってくれてありがとう」と、いろいろな方に声をかけられたと言います（原田さんはNokogiriという、非常にメジャーで有用なRubyライブラリのコミッターのひとりです） 。
オープンソースのソフトウェアは、例外はありますが、その作者たちはほとんどがボランティアです。「 ありがとう」という言葉はコーディングする上で、非常にエネルギーになるそうです。
また、バグは忙しいと放置してしまいがちですが、実際に報告してくれるひとたちとも会ってみると非常に真摯な良い人たちで、親しくなってもっともっと頑張るぞという気分になると言います。
アメリカにはRailsConfのほかにも多くのカンファレンスがあり、Submit Proposals, Made Presentation, Tried Lightning Talksといったイベントに参加したそうです。昼食の会場にはそこら中にナード集団が居て、食事が終ってもトークに花を咲かせているとのことです。
英語から逃げない
英語ができないからアメリカに行かないのは間違いで、行かないから英語ができないのだと原田さんは言います。英語も道具なので使わないといけないものです。Rubyを習得するにも、できるだけ多くのコードを書かないといけないのと同じことです。
また、質疑応答でも「日本に住んでいるプログラマは英語と関わりがない、カンファレンスで外国人と会うのとも隔りがあるが、どうすれば良いか」との質問に対して、日本人は英語についてとてもネガティブであることを指摘しました。原田さんはアメリカに既に6年住んでいらっしゃいますが、移民の人たちは英語を覚えて行きていくことに必死で、教科書を読んだりしない、と言います。
多くのカンファレンスに出席しようと思うと、どうしてもお金は多くかかります。しかし、金はなくても安く上げる方法はいろいろあると話します。たとえば原田さんは、カンファレンスの地域コミュニティの人たちに部屋を貸してもらう、あるいはアメリカのホテルは（宿泊人数ではなく）ルーム単位の料金になっているそうなのでシェアして安く上げる、などの手段をとったそうです。
アメリカのカンファレンスは客層が厚く、本当に世界中から参加者が集まります。外からの目線で自分たちを見ることができ、仕事を休んで行ったとしても決して無駄ではないとのことですので、ぜひ参加してみましょう。
宮川達彦さん「Ruby; Exported」
Perlプログラマとして知られ、YAPC::Asiaの開催にも関わっている宮川達彦さんの発表です（スライド等はこちら ） 。宮川さんは現在は現在サンフランシスコに在住で、アメリカのクックパッドに勤務しており、仕事ではRubyを使っているとのことです。また、Ruby会議への参加は今回がはじめてとのことでした。
このセッションではRubyがPerlから取り入れた機能や、逆にPerlがRubyから受けた影響、それぞれの文化の違いについて紹介しました。
PerlからRubyが取り入れたもの
はじめに宮川さんはRubyがPerlから取り入れた要素についての話をしました。宮川さんがRubyはPerlの良い所を残しつつ、より綺麗になっている言語という印象を持っているとのことです。これは宮川さんだけではないようで、以前宮川さんがPerlコミュニティの仲間にRubyの会社に転職したということを伝えた時にも、あまり驚かれなかったということがあったと言います。
RubyがPerlから取り入れた要素の例として、正規表現やARGF、%記法、特殊変数などを挙げていました。このなかには取り入れてよかったと言われているものが多数あった一方、特殊変数など取り入れなくてもよかったと言われているものもあると述べていました。
RubyがPerlに与えた影響
続いてRubyが他の言語に与えた影響の話をしました。影響が大きかったものとして真っ先にRailsとSinatraを挙げていました。例としてPerlのJiftyというサーバーはRailsのDRY、CoC（設定より規約）といった特徴に影響を受け、同じくPerlのDancerはSinatraに影響を受けていると紹介しました。
また、Rubyでよく使用されるDSLとメタプログラミングについても触れ、それぞれRubyとは切っても切れない関係であること、またそれと同じようなことをPerlで実現するライブラリもCPAN上に見つかるということを紹介していました。
Plack/PSGI、cpanm、Carton、Starman
宮川さん自身もRubyにはとても影響を受けているとのことで、宮川さんがRubyのプロダクトのコンセプトをPerlに移植したプログラムもあります。ここではそれらのうちPlack/PSGI、cpanm、Carton、Starmanを紹介しました。
Plack/PSGI は、RubyのRack とPythonのWSGIにインスパイアされて作成したものだと言います。コードはWSGIとよく似ており、ドキュメントはRackを参考にしたとのことです。
Plack/PSGI作成以前はPerlで使用されるサーバーとフレームワークの対応関係は複雑になっていて関係を把握するのが大変だったそうですが、Plack/PSGIが広まって以後はサーバーの部分とアプリケーションを綺麗に分離することができるようになったそうです。現在はCPAN上のフレームワークの8?9割がこれに対応しているとのことで、どれだけPerlのコミュニティで広く受け入れられたかが伺えます。
またWSGIとRackに比べてPlackは後発なのですが、後発の場合は他の実装を参考にすることができるという利点があるとし、「 はじめるのに遅すぎることはない」と述べていました。
その他、RubyGemsにインスパイアされて作成したcpanm、Bundler にインスパイアされて作成したCarton 、Unicorn にインスパイアされて作成したStarmanといったプロダクトもPerlのコミュニティに好意的に受け入れられたと言及しました。これらのプロダクトがコミュニティに受け入れられるかはとても心配だったそうなのですが、好意的に受け入れられた上、twitter上で感謝の言葉を見かけるなど、すごく嬉しい反応があったそうです。
また、Starmanについては名前付けの裏話も披露しました。これは海外ではDavid Bowieの"Starman"という曲から名付けられたと思われているそうですが、実は宮川さんがファンであるというユニコーンの"スターな男"から名付けたとのことでした。
RubyとPerlの文化の違い
最後にプロダクトの名前付けとコミュニティの文化という側面からRubyとPerlの違いに触れました。
CPANに登録されているプロダクトは、例えば「HTTP::Server::Simple」のように長い名前が付けられることが多いそうです。これは一見しただけで機能が分かりやすいという反面、把握しづらくタイピングするのも大変というデメリットがあるとのことです。
Perlのあまり個性がない名前に対し、Rubyは「Psych」「 Unicorn」など"キラキラした名前"が多いと言っていました。Rubyの名前づけに全面的に賛成ではないものの、Perlでもサーバーやよく使用されるような便利なコマンドラインツールでは個性的な名前をつけるのも良いかもしれないと思っているとのことでした。
コミュニティの文化という面ではPerlは柔軟なコミュニティで、他の言語の良い所をオープンに受け入れて行っていると言います。宮川さんがアメリカで開催されたYAPC::NAというPerlのイベントで"Ruby is not the enemy. They are neighbors."というメッセージを伝えた時にはよく受け入れられていたそうです。
PerlとRubyのコミュニティではお互いにリスペクトしあって、良い所を取り入れていけば良いと考えているそうです。宮川さんは9月27日から29日の3日間に開催されるYAPC::Asia Tokyoでは今度はRubyの話をしてくるとのことです。
セッションの中で紹介していたPSGI/Plackについては宮川さん自身がこちらhttp://gihyo.jp/dev/serial/01/perl-hackers-hub/000101 の記事で、Cartonについては昨年のYAPC::Asia2011での宮川さんの発表スライド: で詳しく紹介されているので興味のある方は読んでみてはいかがでしょうか。
アンドリューグリムさん「Japanese - a programmer's language」
オーストラリアから札幌Ruby会議2012へ参戦したAndrew Grimmさんの発表です（スライド等はこちら ） 。Andrewさんは、冒頭で「日本語について英語で話すことにします」と本セッションを紹介しました。
Andrewさんから見た日本語
まずAndrewさんは、日本語は文法が簡単であるといいます。その理由として、次の3つを挙げました。
英語のように名詞に性別がない
名詞に複数形もない
性別も、複数形も、一人称、二人称、三人称も残りの文と関係がない（例：英語の場合I amとYou areでbe動詞が変わる） これは英語には無い日本語の簡単さであるとのことです。
また日本語は、「 自然言語のProlog」だとし、文章を質問するのに言葉の順番を変えなくても良いことが理由だそうです。例えば、日本語での質問文は
となるものが、英語では以下のようになります。
This is a pen.
Is this a pen? そして、日本語には書くための文字が4種類「漢字」「 ひらがな」「 カタカナ」「 ローマ字」が存在し、昔日本には文字がなかったこと、中国から漢字を取り入れ日本に文字が生まれたと話しました。
ひらがなはモンキーパッチ
Rubyやプログラミング言語の話は出てこないのかな？と思っていたところで、「 モンキーパッチ」の話になりました。モンキーパッチとは、オリジナルのソースコードを改変することなく、動的に実行時拡張、変更する方法です。
Andrewさんは日本語の「ひらがな」はモンキーパッチだと思うと言及しました。例えば、「 行きます」をひらがなでモンキーパッチをすることで、「 行きませんでした」という否定文にすることができるとしました。
和製英語と敬語
次にAndrewさんが面白いと思った日本語が2つあります。それは和製英語と敬語です。和製英語では、Salaryman, Office ladyを例として挙げました。敬語では、人名の後ろに「～さん」とつけると思いますが、この「～さん」という言葉には性別が存在しないのが面白いとこのことでした。そのほか敬語には、「 お」をつける文化もあり、「 お寺」など畏敬の念を抱くものはもちろん、「 お手洗い」など汚いものにもつけることで、柔らかい言葉にする意味があると説明しました。
魔法の言葉
Andrewさんは、日本に来るときに使える「魔法の言葉」を説明しました。それらは次の文であり、これらがあればどうにかなるとのことでした。
サンドイッチください
これをください
はい！
なに？
すみません。 その他の「魔法の言葉」についても、5分でわかる日本語と題して、次の言葉を紹介しました。
すみません
ください
どうぞ
ありがとう
おはようございます
こんにちは
こんばんは
じゃ、また
ばいばい まとめとしてAndrewさんは、日本語では「丁寧に話すことが大切」だと話します。「 Rubyと雪が好きな人は連絡ください」と、来年の2月20～22日にオーストラリアで開催されるRubyカンファレンス、[[Ruby Conf Australia 2013 |http://www.rubyconf.org.au/ ]] を紹介してセッションを締めくくりました。
松田明（＋豪華ゲスト陣）さん「Rails3レシピブック外伝」
松田明さんによる「Rails3レシピブック外伝」です（スライド等はこちら ） 。松田さんは地域コミュニティ「Asakura.rb」の発起人であり、日本におけるRailsの第一人者でもあります。また本セッションでは、ゲストとして諸橋さん、高橋さん、Aaronさんにもお話しいただき豪華なセッションとなりました。
今回はRails3レシピブックで載せきれなかった、または新しく追加された様々なレシピの発表しました。
まずはレシピ000として「Railsレシピブックを購入する」というレシピを紹介しました。こちらは電子書籍版 もあるとのことです。
レシピ001："Entry"というモデル名を避ける（松田さん）
「これは良くない例なのでまねしないでください」という一言とともに紹介されたレシピは、「 Entry」という名前のモデルを使わないことでした。これは、AssociationProxyの影響で意図しない挙動を起こすことが原因です。これは書籍の執筆中に気づいたものの、サンプルコードはすべて動作しますし、影響範囲が大きすぎて修正を断念してしまったとのことで、「 Rails4レシピブック」を執筆することになったら対応するとのことです。
他にも避けたほうが良い"危ない名前"をいくつか紹介しました。typeという名前のカラムがポリモルフィックスと干渉したり、Taskという名前のモデルがRakeのTaskと干渉するなど、松田さんが身を以て体験した事例を取り上げました。最近では、求人サイトで応募を表す「Application」から「ApplicationsController」というコントローラを作ると干渉してしまうので「Applikation」という名前にしたというエピソードも挙げていました。またgemの名前とModelの名前が同じだと干渉してしまうこともあるようで、gemにキラキラしたネームが多いのはそういった背景もあるそうです。
レシピ002：AssociationProxyを使う（松田さん）
AR::Associationとは、モデル間の「関連」を抽象化したものです。Associationは結果をキャッシュしており、関連に対してproxy_associationメソッドを呼び出すと、実態を取り出すことができ、実はArrayではないということが分かったりします。また、関連に対してメソッドを定義することも可能です。
レシピ003：ポリモルフィックスアソシエーションのN+1問題を回避する（諸橋さん）
前述で取り上げたAssociationProxyですが、「 N+1」問題が発生することがしばしば起こりえます。ポリモルフィックアソシエーションは、N個の通常の関連にも分解できるので、通常の関連にしてからeager loadで予め取得したものを使うことで発行クエリ回数を抑えることができるとのことです。また、それを簡便に実現するライブラリを作成したとのことで、「 東京に戻ったらgem化します」とのことでした。
レシピ004：AR::Relation#mergeを使い倒す（松田さん）
AR::Relation#mergeを用いて、RelationっぽいものをいろいろMergeするレシピの紹介です。scopeとmergeするとビジネスロジックをモデルに取り込めて簡潔に書けるというレシピを書籍で取り上げましたが、このレシピではAssociationともmergeすることができること、whereにRelationを食わせてサブクエリとして利用できることなどを紹介しました。
レシピ005：notやlikeのクエリをRubyishに記述する（松田さん）
ActiveRecordではRubyのHashを使ってwhereを綺麗に記述できますが、NOTやLIKEを使うとSQLライクな書き方をせざるを得ない状態です。Jeremy Kemperが4ヶ月程前に新しい記述方式をgithub上で提案しており、notやlikeをチェーンで記述することができるようになっていました。松田さんが実装担当として名乗り出たのですがpull requestがまだ行われていない状態のようです。gem化は完了していてeverywhere というgemを使うことで一足先に試すことが可能とのことでした。
レシピ："Special" Twisting SQLite3（Aaron先生）
松田さんが紹介したような便利なレシピではなく、面白いレシピと前置きしてからレシピを紹介しました。rbファイルの最後にSQLiteのデータベース情報を組み込むというネタで、IOをフックして仮想ファイルシステムを用いて、実行スクリプトに記述してある「__END__」の後にデータを置くようにするデモが披露されました。
レシピ006：Rails consoleの隠しコマンドたち（松田さん）
Rails consoleには便利なコマンドがありますが、レシピブックに書き忘れたものがいくつかあったとのことで、appメソッドからパスを取得できること、helperと書くとActionViewのヘルパーを呼べること、reload!メソッドを紹介していました。
レシピ007：不要なRackミドルウェアを削ってレスポンスを速くする（松田さん）
Rack::middlewareにはいくつか搭載されていますが、いくつかのmiddlewareを無効にすることで高速化するレシピです。Rake::Cacheはリクエストがある毎にmemcachedを参照しますが、大規模サイトのような大量のWebサーバと、その裏でmemcachedが動いているような環境ではそこがボトルネックになってしまうとのことです。これを無効化するだけで1.5倍早くなったという事例がありました。
レシピ008：隠しRakeタスクを全部知りたい（松田さん）
実行可能なRakeタスクを表示するには基本的には「rake -T」というコマンドで確認可能なのですが、膨大になってしまっているので表示しないように変更されています。すべてのコマンドを確認するには「rake t」で確認できるとのことでした。
レシピ009：migrationをGUIで実行する（松田さん）
migrationを毎度コマンド叩いて実行するのは面倒なので、GUIで使うmigrationのgemを作ったそうです。erd というgemを追加してRackサーバを起動し、「 http://localhost:3000/erd 」とアクセスするだけで使えるとのことです。まだフロントエンドが充実していないので、フロントエンドのブラッシュアップをこれから行いたいとのことでした。
レシピ010：helperをオブジェクト指向っぽく書く（松田さん）
Railsのhelperは関数ベースのため、メソッド名や引数について、userの関数なのに引数にuserが必要だったりと非常にダサいと言います。そこでactive_decorator というプラグインを開発されたとのことです。このプラグインを使うことでこの問題が解決されます。このプラグインを導入すると、ModelオブジェクトがControllerからViewに渡されるときに、自動的にヘルパーメソッドに相当するメソッドが追加されます。
レシピ011：ArelのオブジェクトをRubyのコードに変換する（松田さん）
ネタとのことで, タイトル通りARelオブジェクトからRubyコードに変換する方法を示していました。
レシピ333：Railsレシピブックを更新する（高橋さん）
初代RailsレシピブックからRails3版を作成された時に、初代Railsレシピブックの版下のPDFからコピペしながら作られたそうですが、Mac OS Xだとutf-8に関連した問題で濁点や半濁点が別の文字となってしまう問題がありました。UTF-8 MACで読み込んだテキストデータをうまく加工してUTF-8に書き換えるrubyスクリプトを紹介しました。
レシピ012：Engineを使う（松田さん）
Rails Engineを使ったり、作ったり、テストしたりするレシピを紹介しました。Rails EngineとはRailsのアプリケーションのようなもので、RailsアプリケーションもEngineの一種とのことです。Rails::Engineを使うと、他のRailsアプリケーションとして作成したものを呼び出したりすることができます。実例としてはDevise やkaminari などがEngineで、実はPlug-inがEngineだったりすることもあります。
最後に非常にマニアックな話題として、Engineの上にEngineを載せたくなった時に通常はgemを分けるのですが、gemspecに「require_path」を設定することで実現可能とのことでした。興味がある方はこちらのgem がそのような作りになっているので、ご覧くださいと述べていました。
笹田耕一さん「Towards Ruby 2.0: Progress of VM Internals」
初日にHeroku弁当の配布も行なっていた、HerokuのささださんによるRuby2.0の中身についての発表です（スライド等はこちら ） 。ささださんはHerokuのmatzチームに所属しており、そこでRuby処理系の開発を行なっています。
セッション冒頭からRuby2.0の機能についての話ではなく、その機能をどのように実現しているのか、ということについての話だということや、RHG（Ruby Hacking Guide） くらいは読んでる人が対象、ということでハードルを上げながら話を始めました。
Ruby2.0
Rubyは1993年2月24日に誕生しました。20周年を迎える2013年2月24日にRuby2.0を出す予定です。大きな機能追加の凍結を今年8月に、機能の凍結を10月、コードの凍結を12月など、リリースに向けて間に合わない機能追加はやめるという思い切りの良いリリースプランで進めています。
リリースポリシーとして"Rubyらしからぬ"ことに互換性を重視して開発を行なっていて、matzが"100% compatible"と言っているとのことです。もし以前のコードが動かないということがあれば、連絡をすると2.0に修正を入れてもらえるかもしれません。
これまでにやったこと
そのなかでこれまでに作ったものとして以下の紹介を行いました。
Object単位ではなく、Class単位でのextendを実現するModule#prepend
immediate valueを実現し、GC発生を抑えて性能を向上させるFlonum
CallStackを便利に素早く扱える新しいバックトレースAPIであるcaller_locations
invokeするイベントを指定できる、バインディングされるまで生成を遅延させるTracePoint API
非同期例外の発生有無を制御できるControllable asynchronous interrupts
他、VMのソースコードを読んだことある人向けの細かい仕様の変更 特にFlonumについては詳しく説明しました。Flonumでは既存のFloatの仕様からexponentの範囲にある2bitを貰って実現したことや、上3bitでFlonumかどうかの判断ができること、bit patternが増えてどのように変わったのか、32bitでは既存通りの動きをすることなどを取り上げていました。
これからやること
次に2.0のリリースまでにこれからやることとして、VM（仮想マシン）の変更、プロファイラ/デバッガのサポート、今回入らなかった機能のC APIを実装することを挙げました。
VMの変更について、笹田さんがはじめにYARVをつくったときには、多くの最適化コンパイルオプションをつくったのですが、現在はすべて無効にしており、それを有効にしたいとのことでした。なぜ現在無効になっているかというと、効果が大きくでていないのと、どのような用途の時にどのオプションを指定すべきかをきちんと調査をして出さなければならないからと言います。
メソッド呼び出しの速度向上についても取り上げ、現在たらいまわし関数などで実行時間を測定したところ、VM実行時間の1/3近くがメソッド呼び出しにかかっているとし、ここの速度を向上したいとのことでした。
将来やりたいこと
最後に話す予定だったのは、将来的に実現したい、夢の話とのことでした。残念ながら今回は時間が足らずお話は聞けませんでしたが、スライドには書いてあるのでそちらをごらんくださいとのことでした。最後に「来年Ruby2.0がでますので、よろしくお願いします」とセッションを締めくくりました。
浦嶌啓太さん「Ruby on Rails: The Bad Parts」
永和システムマネジメントの浦嶌啓太さんによるRails開発におけるよくある問題と、その解決方法に関する発表です（スライド等はこちら ）
Railsアプリケーションの死因
Ruby on Railsは「Ride on Rails」 、すなわちレールに乗った開発を行うことで気持ちよくWebアプリケーションを作ることができるフレームワークです。レールに乗ることで、理想としては動作する綺麗なコードが手に入るはずです。しかしながら、現実としては数ヶ月後には触れたくないようなコードとなってしまいます。テストコードがあったとしても、それはよいコードを書くためには十分ではありません。
浦嶌さんは、QA@ITの開発でRailsを採用する時、これまで死亡してきたRailsのアプリケーションの分析を行いました。すると、大きく3種類の死因があることが解りました。
ヘルパーは私たちを助けてくれない
ヘルパーはRailsのビューで必要になる共通的な処理を記述する場所です。しかし大きなアプリケーションではヘルパーに多くのメソッドが追加されていき、気がつくと巨大で管理できないコードができあがります。
この問題は、これまでRailsがビューと呼んでいるものはテンプレートでしかないというのが原因でした。ビューであればプレゼンテーションのロジックも含むべきですが、その部分がヘルパーとして分離しており、それを多くのテンプレートから利用しているためヘルパーが巨大になってしまうのです。また、プレゼンテーションとモデルを分離するためには仕方ない面もありますが、メソッドの引数にモデルを渡さなければならないインターフェイスはダサいです。
これらの問題を解決するために、active_decorator プラグインを使います。active_decoratorを使うことで、モデルオブジェクトに動的にプレゼンテーションロジックを追加することができます。これまで、ビュー（テンプレート＋ヘルパー）で次のように書かざるを得なかった記述を改善できます。
helperを利用：<%= link user %>
active_decoratorを利用：<%= user.link %> もちろん、モデルに直接記述するわけではありません。デコレータを独立したクラスとして定義し、実行時に拡張されるしくみです。このしくみを導入することで、巨大化しがちなヘルパーを使わずに、スマートなプレゼンテーションロジックを記述できます。
ちなみに、似たプロダクトとしてDraper というのもあるそうです。細かい違いはあるようですが、基本的には同じ設計思想であり、モデルにプレゼンテーションロジックを差し込むプラグインです。これらのプラグインを使うことで、ヘルパーを使わずにきれいなビューに整理することができます。
パーシャルはパーシャルであってパーツではない
2つ目の死因はパーシャルです。例えば、質問の一覧を表示する機能のコントローラで、タグの一覧を取得するのは美しくありません。それはページデザインの都合であり、仕様変更により影響を受けやすいでしょう。このような場合、Railsではパーシャルとfilterを使うことが推奨されています。しかしながら、パーシャルは根本的な解決にはなっていません。もし、タグの一覧が他のページに移動するならば、パーシャルのコードも移動させる必要があります。パーシャルは「部分的なもの」でしかなく、部品（コンポーネント）ではないのです。
この問題を解決するために、Cells というプラグインを使います。Cellsは、Railsにコンポーネントを提供します。簡単に言えば、テンプレート（ビュー）から直接モデルを取得してレンダリングできる「部品」です。
Cellsはコントローラと同じように実装します。コントローラからは完全に分離されてビューから呼び出されるため、独立したきれいな部品とすることができるとしました。
モデルになるには太りすぎている
最後の死因は、モデルです。「 Skinny Controller, Fat Model」はよく知られた設計思想ですが、実践してみると500行を超えるようなモデルができあがります。もちろん、モデルにHTMLを生成するコードやSQLのコードがあるわけではありません。モデルに関連する処理を集約していった結果であり、本来あるべき姿ともいえます。しかしながら、太りすぎたモデルは、きれいなコードではありません。
この問題を解決する手段は、ライブラリの活用です。非常に手間のかかる処理であっても、ライブラリを活用すれば数行ですむため、モデルが太りすぎることを防止できます。しかしながら、いつでも利用できるライブラリがあるわけではありません。そこで、そのシステムに必要な、小さなライブラリを作ることを提案していました。汎用的にする必要はなく、タグ付けするといった小さな機能を抽象化し、ライブラリにまとめるだけです。このようにライブラリを活用することで、モデルをシンプルできれいなコードにできます。
また、ユーザの行動や振る舞いを抽象化したフレームワークとして「アクティビティレイヤー」という考え方を提案していました。アクティビティレイヤーとは、DCIのエッセンスを含んだ考え方で、複数のモデルが協調する必要がある処理をユーザのアクティビティとして抽象化したものです。例えば、ユーザが質問に答えた時には、幾つかのモデルに影響を与えますが、そのような場合質問のモデルではなく、「 回答する」というアクティビティに着目し、コードをきれいに整理します。
最後に
まとめとして、Railsはよいフレームワークですが、乗るべき「レール」がないこともあります。そのような部分は、先人の作ったライブラリを使ったり、作ったりして対応しましょうと述べ、本セッションを結びました。
中村成洋さん「Rubyによる本気のGC」
CRubyのコミッタであり、もっぱらGCをメンテナンスしたり壊したりしているnariさんの発表です（スライド等はこちら ） 。nariさんは徹底改造G1GC実装編 という本を無料配布しています。ぜひご覧ください。
Google TrendでGCという言葉を検索してみたところ、平日にくらべて休日の検索数が大きく減っていました。nariさんはこれを「休日に趣味でGCをいじる人が少ない」と解釈し、GCはまだまだ愛されていないと残念がっていました。
RubyでGC
今回のセッションをやろうと思った理由については、今までのRuby会議での発表がすべてC言語での話だったこと、卜部さんのブログ に「ちゃんと調査すればCで書かなくてもいい実装はたくさんある」と書かれており、自分がC以外でGCを書けるか試されていると感じたことを挙げていました。
Ruby上でGCを実装した場合、Ruby上のGC自身がCでのGCの影響を受けるため性能評価しにくく、あまり意味がないため、違うアプローチを模索したそうです。
Meta-circular evaluator
そこで目をつけたのがpypy、rubiniusなどのMeta-circular evaluatorです。Meta-circular evaluatorとは自身のコードを用いて自身を評価する評価機で、今回はJavaでJavaが書けるJikesRVMに着目したと話します。
JikesRVMはGC部分がMMTkという別ライブラリに分けられているため、その部分を切り替えることでGCの振舞いを変えられます。これでJava言語ではGCを作り放題になったのですが、残念ながらRubyではありませんでした。
Regicide
そこでJRubyを使い、Regicide （国王殺し）というライブラリをつくりました。ちなみに、名前は「RとGとCで辞書をgrepしてそれらしいのを選んだ」と述べていました。
まとめ
Regicideを作ってみた結果、本当に欲しかったものはこういったものではなく、「 GC実装に特化したミニ言語」であるかもしれないと気づいたため、今後はそちらを攻めていきたいとのことでした。
Lightning Talk
2日目の最後にLightning Talkが行われました。今回は11本のLightning Talksがありました。ドラ娘は、スタッフの娘さんが担当しました。
プログラミングとRubyと家族と自分 - 沼田一哉
フリーソフトウェア開発者である沼田さんのLTです。沼田さんは自身のプロダクトである家計簿ソフト「家計簿さな太郎」の開発を通して、家族のために役立つソフトウェアを作ることはとても良いこととであると主張しました。
筆者が印象に残ったのは妻をユーザと見立てて要求の優先付けや作った機能のフィードバックを素早く得るという、まさにアジャイルな開発を家庭内で実践しているということです。さらにそれがなかなか理解されにくいプログラマの仕事の凄さを家族に知ってもらうきっかけとなったり家庭内のコミュニケーションが増えたりと、家庭円満に繋がる素敵な取り組みだと思いました。
7 reasons you should buy the dRuby book. - Masatoshi SEKI
dRubyによる分散・Webプログラミングの著者である関さんが、「 The dRuby Book」を買うべき7つの理由を語りました。「 The dRuby Book」はサラミを作っている人やRubyに興味が無いけど並列プログラミングをしたい人、パターンマッチを追っている人、さらにERBのトレーニングをする人に向けて最適の本であるのでぜひ買ってほしいとのことでした。筆者もdRubyに少し触ったことがある程度ですが手元に置いておきたい一冊と感じました。
axlsxを使ったグラフ・書式・画像などを含めたOOXML生成 - モーガン・ランディ
Randy MorganさんはRubyでOOXMLを生成することができるaxlsxというgemの開発者で、顧客にレポートを提出する場合にaxlsxを使うべきだと主張しました。その理由としてCSVとの対比を行い、axlsxを使ってxlsxを生成するコードを見ながらレポートのスタイルや画像、グラフなどを簡単に出力できるということを説明しました。ソースコードはGitHubに公開 しているので開発に参加してほしいとのことでした。
thinreports-railsのご紹介 - 篠田健
PDFジェネレーターであるThinReportsをRailsで使うためのテンプレートハンドラについて、作者の篠田さんがそれを開発した経緯や使い方などを説明しました。特にThinReportsをRails上で動作させるメリットを使って、Twitterと連携した「つぶやき台帳」を作ることができるなどの応用ができるのが非常に面白いと思いました。
Rails Hackathon in Okinawa - 安川要平
Okinawa.rbの設立者である安川さんが11月17日と11月23日、24日に行われるRails hackathonについての紹介を行いました。安川さんはOkinawa.rbとしては今回初めて公式の場で発表を行ったということで、砂浜で寝転んだり浅瀬でプログラミングするとても沖縄らしい様子をOkinawa.rbの勉強会として紹介していました。ハッカソンについてはMinami.rbとShibuya.rbと共同して開催し、11月17日はアイデアソン、11月23、24日はハッカソンという日程とのことです。
非Rubyな会社で仕事にRubyを持ち込むための5つの方法 - 栗林健太郎
栗林さんは会社でPHPで書かれているサービスに携わる中で、仕事の中の様々な部分でRubyを使う方法を紹介しました。その方法とは、他言語で書かれたサービス開発の中でデプロイの自働化でCapistranoを用い、サーバの構成管理でChefを用い、外部テストでCapibaraを用い、ログ収集でなどfluentdを用いるというように、言語に依存しない場面に上手くRubyプロダクトを活用している事例を解説しました。
Code Review in Action - Naoto Takai
Cookpadの高井さんが、社内で毎日10を超えるpull requestsをGitHub Enterpriseでレビューを行っている経験から、コードレビューを通して内部の品質を高める方法と、そのポイントについて発表しました。高井さんはコードレビューで見るべきポイントとして、バグを見つけるというよりは読みやすいかどうかを見るべきとし、さらに指摘する際のポイントとしては「どこが悪いのか」「 なぜ悪いのか」「 どう改善できるのか」を伝えることができると良いレビューになると指摘しました。また、相手の気分を悪くするようなレビューは良くないとし、コメント欄に絵文字を入れて和ませる工夫もしているとのことでした。
nadoka さんの m17n 対応のベストプラクティス - 西山和広
IRCのサーバクライアントプログラムであるnadokaさんをRuby1.9で動かしたときに、文字コードの違いによりEncoding::CompatibilityErrorになってしまいました。この対応の中で他言語化のベストプラクティスが見えてきたと発表しました。具体的なプラクティスとしては、サーバやクライアントに文字コードは任せて、pluginでは何もしないということや、受信時に一度だけ変換すること、nadoka本体に文字列を渡す際に一度だけ変換することです。force_encodingで手抜きをするのは得策ではないということや、現在開発中のRuby2.0ではiconvがなくなってしまうので、どうしたらいいか考えているところと話していました。
mruby on TOPPERS - 高橋征義・やまねゆりえ
達人出版会・日本Rubyの会の高橋さんと、やまねゆりえさんがLTの時間中に実機でmrubyを動かすデモに挑戦しました。実際にmrubyをビルドし、QEMU上のシミュレータで動作するところをデモした後、ハードへ書き込むところで時間切れになってしまいました。
自分のためのコードを書こう - Hibariya
永和システムマネジメントのHibariyaさんがRubyに出会い、コードを書くようになったことで私生活も変えることができたと発表しました。自分の生活を便利にするものを作れるようになりたいと思っていましたが、長い間何もできてなかったそうです。しかし、実際にCline や、Reditor などを作ってみると、自分がコーディングすることで誰かを幸せにできることを知ったと話していました。
LET'S SUBMIT YOUR PROPOSAL - こしば としあき
東京Ruby会議10実行委員長を務めるこしばさんが、会場のみなさんも発表に申し込んでみよう！と熱く訴えかける発表をしました。CFPがRejectされてしまった自身の経験を「名誉の向こう傷」や「Rejectされたことは負けではない」と言います。札幌Ruby会議2012が終わって一週間後に、東京Ruby会議10の発表申し込み締め切りが設定されています。LET'S SUBMIT YOUR PROPOSAL!!
懇親会
2日目のイベント終了後、札幌グランドホテルに場所を移し、同ホテルのレストラン2か所で懇親会が催されました。1つの会場では、まつもとさんが乾杯のあいさつを行いました。皆さん、時間いっぱいまで歓談していました。
またやる出張版toRuby
本日12:30からは関将俊さんと米澤慎さんが進行役となり、dRubyを体験する、ゆるくぬるい勉強会が行われていました。
ぬRubyKaigi
冒頭紹介したように、いくつかの、ぬRubyKaigiが行われました。まつもとさんを囲う会も開かれていました。
以上が2日目のレポートです。
