村田賢太さん「分散 RSpec」

Ruby札幌の村田賢太さんの発表です（スライド等はこちら⁠）⁠。村田さんはCRubyのコミッタであり，BigDecimalという実数演算のライブラリなどに貢献しています。

村田さんは現在は札幌を離れ，クックパッドで「エンジニアのためのエンジニア」ともいえる，開発基盤グループで仕事をしています。ちなみに開発基盤グループからは5名が今回の札幌Ruby会議に来ているそうです。村田さんはテストやCIの環境整備，RubyとRailsのバージョンアップ対応などを行っており，今回はこのうち「テストやCIの環境整備」として行ったことを話しました。

高速なテスト，高速なCIが必要な理由

村田さんは，クックパッドはRuby on Railsでできているアプリケーションとしては非常に大きいものであると言います。モデルが861個存在し，またspecの行数が数万行に及びます。さらに，example（テストケース）の数が1ヶ月に1,000以上増加することもあり，現在のspecファイルの数は7,000を超えています。このため，普通にRSpecコマンドを実行しては現実的な時間では完了しなくなっていると話します。

クックパッドでは新しい価値をすぐ提供できるよう，新しく機能を追加してから一般公開に持っていくまでのサイクルを早めたいそうです。そのため，新しいコードを追加してからデプロイができるようになるまでの時間を短くしたいとのことです。また，同時多発的にテストが行われても耐えられる，開発者の環境でもテストが高速に行われる，テストが増えてもスケールアウトで処理時間の上昇を抑えられる，といった条件も必要になるとしました。

RSpecの分散実行を実現する

そこで村田さんたちは，RSpecによるテストの実行を複数のworker（すなわちサーバ）に割り振って実行することで，これらの問題を解決する方針を取っています。大きな流れとしては，まずRSpec実行用のサーバにrsyncでコードを送り，MySQLやSolrの環境をリセットしたのち，そのサーバでRSpecを実行するというものです。

specファイルを分散してRSpecで実行するにあたり，前回のRSpecの実行時間をもとに，各workerがなるべく均等な時間を使うようにspecファイルを分担させます。その結果はログファイルに書き込まれ，次のRSpecの実行にあたって参照されます。

この仕組みを導入したことで，通常のRSpecコマンドでは完了までに膨大な時間がかかり，parallel_tests gemを使って8コア並列実行した場合でも1時間かかっていたものが，5台のサーバ（各6コア）に処理を分散させることで15分でRSpecが完了するようになったとのことでした。またクックパッドにおけるRSpecの所要時間のグラフを示し，テスト数が増えてもRSpecの所要時間が大きくは増えなかったこと，また9月にサーバを8台から14台に増強してRSpecの所要時間を減らせたことを説明しました。

さらなる改善点

村田さんは最近改善している点として，各workerへのspecファイルの分配方法についても言及しました。上記の方法では，各workerの状態（そのサーバが高速に処理可能な状態にあるか否か）は考慮せずに純粋に処理時間のみで分配を行い，さらにRSpecを実行する前に分配方法を固定していたため，どうしてもworkerごとの処理時間のばらつきが大きくなるとのことでした。そこで「キューに実行すべきテストを入れ，各workerに割り振っていく」という，いわゆるproducer-consumer patternを用いることで，各workerの実行時間の平準化を行えるのでは，と考えているそうです。

ただしこの方法では，consumerにspecファイルが割り振られるごとにRSpecコマンドが実行され，Rubyのプロセス立ち上げのために余計な時間がかかってしまいます。この対策として，RSpecコマンドはそのまま用いず，プロセスは立ち上げたままspecファイルを続けて実行できるような仕組みを作っているとのことでした。

最後に，この発表で紹介された分散RSpecのシステムは，「⁠remote_spec.gem」という名前で，オープンソースで公開される予定であると告知しました。

Linda Liukas, Terence Lee「The First Cut is Deepest」

Lindaさんは女性の初心者向け開発者コミュニティ，Rails GirlsのCommunity Managerであり，codeacademyに勤めています。TerenceさんはHerokuのエンジニアでRails Girlsのお手伝いをしています。

「最初の傷が一番深い」という日本語訳のタイトルとともにセッションが始まりました（スライド等はこちら⁠）⁠。

Being a Beginner

Lindaさんはフィンランドの出身です。フィンランドといえばMySQLやSSH, IRC, Linux, Gitなど有名なソフトウェアが多くあります。これらはすべて男性が作ったものです。私はこれを変えたかったとLindaさんは話します。

若い女性こそ一番ネットに強いグループであり，非常に強い情熱や創造性を持っています。facebookやtumblr，pinterestのようなサービスをとても活用しています。彼女たちはキュレーターになることはできますが，自分たちで創りだすことのほうがよりクールです。それを助けるのがRails Girlsです。

Rails Girlsははじめにヘルシンキで開催され，現在は全世界14の都市（うち1つは東京です！）で開催しています。今後も17の都市で開催が予定されており，1,000人以上の人が参加しています。Rails Girls Guideにはイベントの開催の仕方について詳細に記載してあり，スポンサーの探し方やプログラムの例，Rilasのインストールなどワークショップについても用意されています。

また，多くの初心者にとって一番の問題はウェブの言葉を理解することであり，略語が多すぎて辛いと言います。そこで考えたのがBento Boxです。storage logic infrastructure style and structureというような大きなカテゴリを弁当箱の形につくって，MYSQLのカードはstorage，nginxはinfrastructureなどのように弁当に詰めていきます。これを使ってクイズを行ったりすることで，詳細は知らなくても，その言葉がどんなものなのかを知ることができます。

多くの人々はプログラミングは孤独で，数学的で難しいものというイメージがあります。しかし，実際には集まった人々といろいろなことについて話すことができます。自分の職業についてや，趣味，アイデアなどです。他にもMatzについて語ったり，IDLEについて語ったり，"We Code."コードについて話すこともできます。

How Beginners Benefit Us

ここで，Terenceさんにバトンタッチしました。Terenceさんはコーチを行った経験を通して，コミュニティの側から見た，初心者を受容することについて話しました。自分が初心者だったことのことはあまり覚えているものではありません。失敗を忘れないために初心者と触れ合うことは良い経験になるのでおすすめです。

はじめにインストールフェスタについて取り上げました。いろいろな環境にRubyやRailsをインストールするのは初心者にとっては困難です。ここで躓いて，1行のコードも書くことができないのは困ったものです。Rails GirlsではTokaidoというコンパイル済みのRubyやgem，ライブラリがセットになったインストーラを使用しているとのことです。これは生徒にとっても依存性などの心配がなくRubyを動かすことに集中できますし，講師にとっても素早く環境を作って生徒を動かすことができ，無駄な時間を省けます。

Railsのエラーについて，db:migrationをし忘れてエラーを起こしてしまった経験があると思います。この時に表示されるNoMethodErrorというエラーメッセージはあまり親切ではありません。ここで同僚がPending migrationsという表示に変えるパッチを作ってくれました。これはユーザーを誘導してくれる，よいメッセージです。

1,000cuts，小さな傷，問題が初心者のやる気を少しづつ削っていきます。上記のような小さな改善の積み重ねは大切で，結果的に初心者だけでなく，ベテランも助けてくれます。

More tools to get people involved

コードを書き始めた人々を巻き込むために必要なものは何でしょうか。はじめてのワークショップの後にコードを書き始めた人たちがオープンソースのプロジェクトに参加したり，コミュニティに参加することを助けるためにはどうしたらよいでしょうか。

contribute.mdという小さな新しいプロジェクトがあります。markdownファイルをプロジェクトにおいて，初心者がどこから手をつけたらよいか書いておきましょうというプロジェクトです。バグフィックスやドキュメントを書くこと，翻訳をするなどオープンソースのプロジェクトをよりよくするために，できることはたくさんあるでしょう。

summarizing

まとめとして，Terenceさんから2つのことを挙げました。ひとつは，新しい参加者は我々に新しい能力とアイデアをもたらしてくれること。もうひとつは，わたしたちは単純でよりよいツールを作ることができる。塵も積もれば山となることを忘れないでほしいということです。

Lindaさんからは「より多くの人が基本的なコーディングスキルを身につけるにつれて，オープンソースやコミュニティの役割や価値を伝え，参加してもらうことがより重要になる。鍵はコミュニケーション。障壁を下げて，親しく，そしてたのしく，そうすればもっとたくさんの人を巻き込むことができる」と述べていました。

Eric Hodelさん「Writing Ruby for Fun」

Seattle Ruby Brigade（Seattle.rb）のメンバーであるEric Hodelさんのキーノートです（スライド等はこちら⁠）⁠。Ericさんは冒頭，今回初めてキーノートで話せることになり光栄に思っていると述べました。

EricさんはRubyで仕事をしており，Railsアプリやミドルウェアを扱ったり，最近では仕事としてRubyコミッタにもなりました。その一方で，趣味でもプログラミングを楽しんでおり，仕事のためにもなるものとしてnet/httpやmechanizeなど，またコミュニティのためにということでRubyGemsやRDocなどのコードを書いています。

Ericさんは，自身がプログラムを書く理由として「日々をよくしたい」「⁠技術を身につけるという挑戦をしたい」「⁠新たな知識や技術を知りたい」といったことを挙げていました。そして今回は，自身の取り組みでこれらのことを達成できたものについて話しました。

RDoc Browser

RDoc Browserは趣味でやっているプロジェクトのひとつです。RDocのブラウザは自分がほしかったもので，curses（コマンドライン端末を制御するためのライブラリ）を勉強するよい機会になったそうです。

このRDoc Browserでは，画面を再描画しないようにハイパーリンクを特別扱いしているようです。DisplayクラスにはCursesを継承していて，便利なメソッドを追加しています。ここで画面スクロールの問題が発生したそうです。このときEricさんはさまざまなチュートリアルを調べて対策を施したと言います。その結果，CursesにはPadという仕組みがあり，スクロールに役立つものだということがわかりました。その導入により，自由なスクロールができるようになりました。結果としてCursesの勉強になり，Ruby 2.0に向けてPadに対応するパッチも送ることができたとのことです。

ゲームのシミュレーション

Ericさんは高校時代に，Master of Orionという宇宙を舞台とする戦略ゲームを知り，とても気に入りました。一方でEricさんは，そのような面白いゲームを自分で作るのは難しいとも考えました。そこでEricさんは，新たなゲームを作るのではなく，こういったゲームのシミュレーションを作る，すなわち「宇宙船の移動や表示」「⁠AIの動作」といったことを自ら組み上げ理解することも楽しそうだと考え，実際に取り組みました。

宇宙船の移動は，当初は移動速度が常に一定に設定されていたため，止まっている状態から急に加速するという，スムーズではない挙動となっていました。これを解消するためにコサイン（Math.cos）を用いて，ゆっくり動き出してあとから速くなる，という挙動を実現したとのことでした。

また，「⁠一つの中心を基点に爆発が起き，多数の点がさまざまな方向に拡散される」というグラフィックを実装するにあたって，当初読んだチュートリアルは拡散する形が円形ではなく四角形になっており，現実味のないものに感じられませんでした。そこで，飛んでいく向き（角度）と速度をそれぞれ乱数（Kernel.rand）で与え，これを極座標の考え方で2次元の座標の値に変換すればよい，と示しました。

AIの動作については，描画とAIでスレッドを分けており，その際に一部の宇宙船が，AI上では動作が完結しているにもかかわらず描画に反映されないという問題が起きていました。これにはEricさんは非常に困ったと言います。これには結局，AIの処理が終わるまでは描画は行わず，描画が終わってからまたAIを再開することで対応しました。またその際，AIの処理に時間がかかる場合はこの方法ではまだ不十分である，とつけ加えました。

暖房の自動調整

もっともやりがいのあった取り組みとして，家での暖房の自動調整を行うシステムを作ったことを挙げました。Ericさんは家中の電気の遠隔操作，そして暖炉を制御するライブラリを開発しました。暖炉を制御し，適温を維持するために，ArduinoとXbee，温度センサを使用したとのことです。

Arduinoからの信号は，温度と湿度が同じ文字列で返されます。例えば，「⁠温度：24.3度，湿度：45.4%」の場合には，snprintfにより，「⁠"243C 454%\n"」といったテキストで返ります。snprintfを用いる理由としては，Arduinoのprintfでは，float型を対応していないからです。そして，このテキストをRuby側でパースします。

このテキストプロトコルの解析は容易であり，snprintfは省メモリ，省電力のArduinoには高価なため，挑戦してバイナリプロトコルで作成することにしたそうです。バイナリの通信では，非同期なので，時々データが壊れることがあるそうです（パケットの途中にデータを読むと，壊れるそうです⁠）⁠。そのため，パケットプロトコルを同期して読むために，バイナリにマーカを埋め込むことで回避しました。

通信が可能となったので，次に温度制御の方法を考えました。制御方法として，PID制御（Proportional, Integral, Derivativeの略で，それぞれ比例，積分，微分制御）で行うことを考えました。この制御方法は，多くのフィードバック制御に用いられていると説明されました。しかし，見た目が難しかったため，P制御（比例制御）で解決することにしました。このP制御を実装し，暖炉のon/offを行ったところ，適温±0.5度にすることができたそうです。

Ericさんは他に取り組んだこととして，木でヘッドボードを作るという，コンピュータとは関係ないことも紹介しました。そしてその際，研磨機が壊れたときに自分で直す方法も学んだと話していました。

挑戦しよう，楽しもう

Ericさんは最後に，「⁠挑戦しよう」（⁠Challenge Yourself）「⁠楽しもう」（⁠Have Fun）という2つの言葉を掲げました。そして，ソフトウェアを自作するにあたっての意識の持ち方として，「⁠自分のために作ったものであっても，公開してコミュニティに出してみよう」「⁠うまくいかず，困るときもあるけど，そこを解決できると非常に楽しい」「⁠失敗を気にせず取り組んだほうが楽しめる」といったことを示し，セッションを締めくくりました。