原悠さん「Rubyマスターへの道」

ネットワーク応用通信研究所の原さんが，Rubyマスターになるためにはどうすればよいかということを話しました。

最初に，使用しているプレゼンテーションソフトがHTML5なので，RubyistとしてRubyタグを使って英訳した文を添えているということ紹介しました。

原さんは，プログラミング歴14年，Rubyist歴は9年になります。そんな原さんが，2009年に「Rubyが使いこなせる勉強法を教えてほしい」という質問を投げかけられたそうです。今回の発表は，そんな質問への回答になるそうです。

プログラマ準備編

原さんは，まず「プログラミングにはいろんな分野があることを理解してほしい」と言います。プログラマがかっこよさそうという「あこがれ」から，プログラミングを初めるのはいいことです。しかし，プログラミングできる分野は広いため，そこから自分が何を作りたいかというのを探そうとアドバイスしました。また，初日のAaronさんの発表を取り上げ「日本にはRubyで何かを作るための本がいっぱいあるので参考にするとよい」と述べました。

また，プログラミングマスターには時間がかかるため，途中で休みながらでも継続しつづけていくことが大事だと言及しました。だいたい10年やれば，大概のものは何でも上手くなるので，10年たったころにはプログラミングマスターになれるのではないかということです。

そして，「⁠コンピュータの中では，プログラマにできないことな何もないので，何でもできると思ってプログラミングを初めてほしい」と語ります。何でもできるプログラマなろうとすると，やらなければいけない分野が増えて大変だと言います。しかし，作ろうとしたときの勉強こそが「勉強すればなんでも作れる」という自信となるはずなので，「⁠たくさんプログラムを作りましょう」と言い，準備編を締めました。

プログラマ初級編

プログラミングを初めたら，まず「ライブラリを知る」ことが大事だと言います。Rubyには，組み込みライブラリや標準添付ライブラリのように初めから便利な機能があるライブラリがあります。そしてRubyのメソッドはバージョンアップするたびに便利な機能が導入されるため，定期的にドキュメントなどで見直しをするとよいと言います。また，「⁠プログラミングをして，身近な問題を解決しましょう」とプログラミングをするコツを紹介しました。ちょっとした自動化できたらいいなという処理からはじめるとよいそうです。

プログラマ中級編

中級者になるにはまず「良いコードを書く」ことが大事だと言います。「⁠良いコード」というのは，宗教的なものでなく，圧縮された「良さ」をもつコードのことだそうです。そして，他の言語のようなRubyコードでなく，Rubyらしいコードを書くことも大事だと言います。また，コードの読みやすさも意識するようにしましょうとも述べました。 そして，ブログやGitHubなど「アプトプットする」ことが大事だと言います。ブログを書きはじめたときは，反応がないためつまらなく感じることがあります。しかし，検索エンジンごしの「誰か」に向けて書き続ければ，だんだん反応がもらえるようになるそうです。また，ブログを書くためにメモをまとめるので，考えがまとめる必要ができ，自分のためにもなります。ブログやGitHubなどのWebの世界だけでなく，現実の世界でも「発表する」ことが大事だと言及しました。いきなり大きなイベントでの発表は大変なので，小さなイベントから発表していくことがお勧めだそうです。また，自分が作ったものの発表だけでなく，他の人が作ったライブラリなどを勉強したことや，面白いと感じたことでも発表すべきと述べました。

プログラマ上級編

上級者になるには，自分が使っているものの「中を開けてみる」べきとアドバイスしました。今導入しているRubyGemsのソースコードを読んだり，自分でいじってみて動きを理解するとよいとのことです。また，ライブラリのコードだけでなく，Rubyのソースコードも読んでみるべきだとも言います。そして，「⁠Ruby以外の言語を勉強する」ということも，Rubyの勉強になるそうです。Rubyしかしらないというのは，Rubyの特徴がわからないという状況です。多言語を勉強することでRubyの特徴を知ることができると指摘しました。

プログラミングマスター編

プログラミングマスターになるためには，「⁠人と違うことをする」必要があると言います。「⁠人と違うこと」というのは，その道の第一人者になるということになります。マスターになると「やる気の問題」がでてくるそうです。やる気を保つためには，「⁠やる気がでるまで待つ」や「強制的に始める」というやり方の他に，「⁠達成すると嬉しいことが起きる環境を作る」「⁠やらざるを得ない環境を作る」など環境についてアドバイスしました。

プログラミングマスターになったら，どうなる?

最後に，原さんは「プログラミングマスターになってても良いことはない」と述べました。プログラミングの楽しみは，「⁠うごいた!!」という感動です。そのため，「⁠あんなに上手にできたら楽しいだろうな」と思ったり，今目の前のコードを楽しみ，「⁠気づいたら，Rubyマスターになっていた」となるのがよいと話をまとめました。

Richard Huangさん「Use rails_best_practices to refactor your rails codes」

rails_best_practicesというgemを作っている，Richardさんによる発表です。

@ihowerさんの「Rails Best Practices」

Richardさんがrails_best_practicesを作るきっかけとなったのがRails Conf Chilnaでの@ihowerさんによる「Rails Best Praictices」という発表だそうです。とても良い発表だったそうですが，実際にRichardさんがすべてを実践したら，ベストプラクティスの数が多すぎて大変だったそうです。なのでそれらを自動化するために作ったのがrails_best_practicesとのことでした。ただ，自動化するのが難しいプラクティスもあるそうで発表であったプラクティス全部を自動化できているわけではないと話していました。

rails_best_practices gemとは別にrails-bestpractices.comというサイトもあるそうです。このサイトは@ihowerさんのベストプラクティス以外にもたくさんのプラクティスを集めるために作ったサイトとのことで，ユーザがプラクティスを投稿したり，良いと思ったプラクティスに対して投票できるという機能があるとのこと。現時点で70ほどのプラクティスがあり，ベストと言えないものもあるが便利なものがたくさん登録されていることを紹介しました。

デモ

rails_best_practicesを使うためには gem install rails_best_practices でインストールし，rails_best_practicesコマンドを実行すればよいそうです。実行するとターミナルにリファクタリングすべきコードがどのファイルのどの行にあるかが表示されます。この結果はターミナルだけでなくオプションでhtmlなどにも出力可能であることを説明しました。

結果の出力にはリファクタリングすべき内容にしたがってrails-bestpractices.comの対象のプラクティスへのリンクが一緒に出力され，プログラマはそのリンク先に書かれているプラクティスを見てどのようにコードを修正すればよいのか確認できるとのことでした。

Richardさんは実際にその場でrails_best_practices gemを使ってデメテルの法則に違反しているコードを解消するデモを行いました。

rails_best_practicesを使った方がよい理由

rails_best_practices gemを使うと，ベストプラクティスにしたがった美しいコードを書けるようになるとのことです。また，細かい規約や文法などのチェックをrails_best_practices gemで自動的に行うことでプログラマがコードスタイルではなく，本質的なロジックに集中できるようになると述べました。Rubyにはその様なチェックをするツールがたくさんありますがほとんどがRubyのためだけのものでRailsに関する問題はみつけられないと指摘しました。

プラグイン

rails_best_practices gemは解析対象のRubyコードを一度SEXP(S式)に変換し，SEXPに対してプラクティスのチェックを行なっているそうです（SEXPへの変換にはruby_parserを用いているとのこと⁠）⁠。また，rails_best_practices gemはプラクティスのオン・オフも設定できるそうで，設定ファイルを記述することで変更可能と説明しました。

また，自分達でプラグインとしてプロジェクト固有のプラクティスを追加することもできるそうです。実際にRichardさんがRails.rootではなくRAILS_ROOTと書かれているコードを検出するプラグインを実際に作るデモを行ないました。

ライブラリの使い方の話だけでなく，内部の実装にまで踏み込んだ，作者ならではのおもしろい発表でした。

Wen-Tien Changさん「BDD style Unit Testing」

Wen-Tien Changさんの発表です。まず始めに，テストにはUnitTestとCustomerTest（受け入れテスト）の2種類があること。Unittestは正しいコードかどうかの検証のために行うものであり，CustomerTestは顧客の要求にあっているかの確認のために行うテストであることが紹介されました。

RubyのBDDツールとしては以下の2つがあると言います。

• RSpec
• Minitest/Spec

そしてテストには，以下の4つのフェーズがあると挙げました。

• フェーズ1:セットアップ
• フェーズ2:実行
• フェーズ3:検証
• フェーズ4:ティアダウン

この4フェーズがはっきりしないと，どういう順番でテストが実行されているかがわかりにくくなってしまうと述べました。

BDDの第一印象は，文法が仕様書のようで可読性が高いということを挙げました。そもそもBDDはxUnitを改良したもので，振る舞いにフォーカスしているとのことです。BDDからxUnitに変わることで用語も変わります。テストをスペックと呼ぶようになり，assertionをexpectationと呼ぶことを説明しました。

よく使われるツールはRspecとMinitest/Specですが，RSpecが最も高性能だと述べました。Minitest/specはRuby1.9.2から組み込まれていて，よりシンプルかつ高速に動作するそうです。BDDでよく使う要素はRspecのcontextで，一つのテストケースの例でありネストが可能であるとのこと。Minitest/specでは対照的にdescribeしかないけれども，深くネストしたcontextはコードの流れを追うのが難しくなるため危険であると述べました。ここでも4つのフェーズが鍵になると言及しました。

そして，シンタックスの問題を語りました。言語があなたの考え方に影響を与えると言います。test/unitはただ検証を行いますが，specは検証するだけでなく，どんな振る舞いをするかの定義もするため，テストの目的も分かりやすいと紹介しました。メタプログラミングが問題なのでしょうか？　問題になるべき点ではなく，RSpecの高度な文法のせいであると述べました。しかし，Wen-Tien Changさんの意見として，RSpecのDRYな文法が逆にテストを難しくしているということがあると言います。Railsチームでテストをネスト可能にしていないのは，この複雑さを避けたいためだと推測され，RSpecはモックを使いすぎだと感じているそうです。

結論として

最後に，「⁠BDDテストフレームワークは必須ではありませんが，チームの力になるものだと思います」と締めくくりました。

永井秀利さん「ThreadGroupクラスの強化とその利用法」

Ruby九州のメンバーでもある九州工業大学の永井さんによるThreadGroupの機能改善についての発表です。永井さんは，CRubyのコミッターでもあり，Ruby/Tkを主に担当しています。

ThreadGroupとは，組み込みライブラリの一つで，スレッドを管理するクラスになります。生成したThreadがまとめられる単位になり，以下の特徴があることが紹介されました。

• 生成したスレッドは親と同じThreadGroupに所属する
• 死んだスレッドはThreadGroupの管理から外れる
• スレッドが所属するThreadGroupは動的に変更可能
• ThreadGroupオブジェクト間には関係や階層がない

永井さんは，このThreadGroupがあまり活用されていないということに着目し，もっとみんなに使ってもらえるようになるために機能強化を考えられたそうです。永井さんは，ThreadGroupやスレッドの管理には次のような問題点があると指摘しました。

• スレッド群を取り扱うための機能不足
• スレッドを操作するための権限に関する概念が無い
• ある程度コストをかけないと，スレッド群を終了順に処理できない
• ある程度コストをかけないと，スレッドが終了したときに即応答ができない

このような問題に対し，4つの強化を試みたそうです。

• スレッド（群）の操作性の向上
• ThreadGroup間の操作権限の設定
• 例外終了を含むスレッドの整列化
• 閉鎖された実行空間の生成

これらの改善を図るのをライブラリでなく，Ruby本体に手を加えたことについて「Ruby本体側で変更を加えないと，実装がそもそも不可能，もしくは無駄なコストがかかるため」と問題を修正する難しさと語りました。

スレッド（群）の操作性の向上として，スレッドを生成する際に所属させたいThreadGroupを指定可能にしたり，ThreadGroupに所属可能なスレッド数を設定・参照できる機能等さまざまな機能を追加したそうです。また，ThreadGroupをThreadGroupで管理できるように，操作権限の概念を追加したことも紹介しました。

例外終了を含むスレッドの整列化として，今回ThreadGroupごと一つのthread queueを持たせ，例外終了を含む終了したスレッドがthread queueにいれることが可能になったと言います。このthread queueを使用すれば，終了したスレッドを順に処理したいというようなことが簡単にできるようになるそうです。

閉鎖された実行空間の生成として，local spaceという機能を説明しました。local spaceを利用するとThreadGroup内に閉じた実行空間を構築でき，ThreadGroup内で有効なメソッドや定数，クラスやモジュールなどを作成できるようになるそうです。

最後に，これらの強化案は実装中であり，議論中のものだと述べました。これらの機能に興味がある方は，ruby-devなどで意見を挙げてほしいと述べました。