三村益隆さん「ソーシャルコーディング時代のふつうのプログラマサバイバルガイド」

RubyKajaにも選ばれた，永和システムマネジメントの三村さんのセッションです。三村さんはasakusa.rbに所属し，rails勉強会＠東京を開催しています。また，herokuを使って開発やサービスを運営する人たちのためのwiki「mwiki」の開発者でもあります。

本セッションでは，永和システムにgithubが導入されてから三村さんが感じた変化と自分の取り組みについて発表しました（スライド等はこちら⁠）⁠。

github導入

永和システムマネジメントは，多くのメンバが関わる大規模開発でのコードビューの効率化やトレーサビリティの向上を目的として約一年前にgithubを導入しました。多くのメンバは既にプライベートやオープンソース活動でgithubを使い慣れていたため，pull requestに対するコードレビューを行うというプロセスを用いることにより，コードレビューを改善できたと話します。

その他，自分たちが作るツールなどもgithubを用いることで簡単に共有することができるようになり，他人が作ったツールの利用や改善が盛んになりました。さらに社内の別プロジェクトのコードベースも見えるようになったことによって，プロジェクトを越えたメンバからのフィードバックも得られるようになりました。

そのような状況の中，三村さんは自分の書いたコードに対してたくさんのレビュー指摘を受けるようになり，非常に辛い精神状態になったそうです。レビュー指摘を受けるということは，コードを書くのが好きな人にとって自分のアイデンティティを否定されているように感じてしまったと言います。

三村さんはこのままではいけないと思い，逆境をチャンスに変えるべくレビュー指摘の捉え方を変えました。酷いコードに対し見捨てずにレビュー指摘をもらえることは有難いこと。指摘された内容を自分のものにすれば自分もレビューアのような良い習慣を身につけられるはず。そう考えるようにしたそうです。そもそもレビューアは永和システムマネジメントのマスターブランチに対し良くないコードを置きたくないという意識でレビュー指摘をしているのであって，コードを書いた人のアイデンティティを否定しているわけではないことに気がつきました。

3つのこと+1

そして三村さんは具体的に次のことに取り組みました。

1つめは「コードの形を気にするようになった」ことです。特に改行や空白もコードの一部と考え，コードの形に統一感を持たせるよう気を配るようになりました。

2つめは「説明できるコードを書く」ことです。これまではかっこいいコードを書こうとしてメタプログラミングなどを駆使していましたが，結果的に他人にわかりにくいコードになることがありました。変数や関数の名前づけをしっかり考え，コードの意図を明確にすることを大事にするようになりました。

3つめは「道具を知る」ことです。例えばrailsであれば様々なapiやライブラリのことを詳しく知ることで，より文脈に合った意図が伝わるコードを書くことができます。そこでapiリファレンスやgithubからの情報収集，他プロジェクトで使っているgemの調査を行い，自分が使う道具の知識を増やすようにしました。

さらにもう1つおまけとして「課外活動をするようにした」ということも挙げました。自分が学んだことをネット上にアウトプットしたり，コミュニティに参加し様々な人と交流することで新しい知識を得ることができたそうです。

自分の変化

三村さんはこれらの取り組みを行う中で自分の中で変化があったと言います。あれほど辛かったソースコードのpushが楽しくなり，また自分が書いたコードが前よりも確実に良くなっていることを実感しました。さらに自分が得たことを他のメンバに伝えることを意識するようになり，人に教えることを通してより自分の理解や考えも深まっていくことが分かりました。

ソーシャルコーディング時代が到来し，今後会社の中でも使われるケースが増えていくと予想されます。三村さんは自分のことを「ふつうのプログラマ」だとし，そんな「ふつうのプログラマ」が生き残っていくためには，辛いことがあったときにもそれは上達するチャンスだと捉え，そこから学んでいこうとする姿勢を持つことや，なによりもコードを書くことを楽しもうとする意識が大切だという言葉で本セッションを締めくくりました。

Nick Suttererさん「Off the Tracks - Challenging the Rails Mindset」

@apotonickことNick Suttererさんによるセッションです（スライド等はこちら⁠）⁠。Nickさんの開発したCellsやApotomoはRailsのViewを拡張するモジュールとして多くの方に使われています。

はじめに

NickさんはRailsを本物のオブジェクト指向フレームワークとして使いたいと考えています。そのためにはDomain Object, Persistance, TDD, PORO, DCI, Dependency Injection, Fat models, Skinny Controllers, Decorator, Presenter, Exhibit, View Component, View Inheritance, REST API, Representerといった多くのことを学ばなければなりません。

これらを学ぶためにNickさんが提案したことは「Object on Rails」「⁠Clean Ruby」といった書籍を読むことです。これらを紹介し，このセッションは終了です（もちろんNickさんのジョークです⁠）⁠。

Rails = デス・スター

NickさんはRailsを映画「スターウォーズ」に登場する宇宙要塞デス・スターにたとえました。Railsプログラマーは時に巨大なコントローラー，巨大なモデル，巨大なビューを作りがちです。肥大化しすぎたソースコードを適切なサイズにリファクタリングを行い分割しなければなりません。肥大化したクラスを整理するために，"Fat model, Skinny Controller" の設計を用いることができるでしょう。

PORO

カウボーイたちが焚き火を囲んで集っています。ジムと呼ばれる男がスティーブに話しかけました。「⁠なんか飲むかい，スティーブ？」「⁠ああ。いいね」

このようなカウボーイ同士の簡単な会話のやりとりでさえ，Railsプログラマーはデータベースにテーブルを作りがちです。しかしこのケースではPORO (Plain Old Ruby Object)を使ってみるといいです。

POROは要するにごくシンプルなRubyオブジェクトのことです。さっそくPOROでカウボーイを表現してみます。

class Cowboy < OpenStruct end

このようにOpenStructを継承したCowboyクラスを作ります。すると，

jim = Cowboy.new(:name => "Jim") jim.name #=> "Jim"

のようにJimの名前が設定されたCowboyオブジェクトができました。

カウボーイ同士の会話はどうしましょうか？ Cowboyクラスにsayメソッドを追加し，発言を表現するMessageオブジェクトを返すようにします。返答を行うrespondメソッドも合わせて追加し，誰かへの返答であるResponseオブジェクトを返すようにしましょう。発言を保持するMessageクラス自身もPOROで，これまでと同様OpenStructから継承してクラス定義します。ResponseクラスはMessageクラスを継承して，さらに返答相手を保持するプロパティを設定します。このようにモデルを作らなくても，POROのみを使ってチャットアプリケーションは作ることができそうです。

しかし発言をデータベースに保存したいこともあるでしょう。この場合，POROをActiveRecordを使ったモデルに書き直すことはしません。POROにDataMapperをインクルードすることでモデルとして利用できます。DataMapperをインクルードしたMessageクラスは実際にRailsのコントローラーに使うことができます。

View

次に巨大になりがちなビューをどうにかしてみます。

• カウボーイのJimを左側，Steaveを右に配置
• JimかSteaveいずれかが発言した場合，吹き出しを表示。
• 発言がない場合は発言用入力フォームを表示。
• 返答は相手の発言から「返答」ボタンを押して返答用入力フォームを表示

このようなビューを作る場合，メッセージ部分をpartialを使って書くと思います。しかしpartialで読み込んだビューの内部では，渡されたMessageの種類を判別して入力フォーム・発言・返答フォームのいずれかをさらにpartialで取り込む処理になっています。これはゴチャゴチャしていて，あまり良いやり方ではなさそうです。

この場合，View ComponentであるCellsを使ってみるのがいいです。CellsはRailsのコントローラーとビューの間に入り込むCellクラスを定義し，Cell用のビューを出力する機能を持ちます。 renderからCells用のrenderメソッドに置き換える事は簡単です。ただ，単に導入しただけではゴチャゴチャした処理を置き換えることはできません。

View Inheritance

処理を置き換えるにはView Inheritanceを使います。Rails3.1で採用されたView Inheritanceは，親子関係にあるController同士で同じ名前のビューを出力すると親か子どちらかのビューを出力できます。

Cellsでもこれと同じやりかたが使えます。MessageCellで渡されたMessageがResponseかどうか判断し，Responseの場合，ResponseCellがビューを出力します。これでビューに書いていた処理をCellsのクラスに移動させることができ，ビューをすっきりにできました。

Cellsはまた，Cellsのクラス内でキャッシュを持たせることもでき，ビューの負担をさらに軽くします（キャッシュはビューで行う仕事ではありません⁠）⁠。また，Cellsの仕組みを使うと，1つのページに含む部品ごとにMVCを埋め込むことができるため，複雑な構成のページでもシンプルに書きやすくなります。

Controller

REST APIとしてControllerを使うために，roar-railsのようなRepresenterを用いることで，JSONからRubyオブジェクトをシリアライズ・デシリアライズできる事を紹介しました。

今回のKaigiではRailsアプリケーションの肥大化について取り上げているセッションがいくつかありました。それぞれのセッションで便利なgemや自作のライブラリ，設計の変更などによって，シンプルで見通しのよいアプリケーションを作るやり方を紹介していました。本セッションも肥大化するRailsアプリケーションに苦労している人の参考になることでしょう。

原悠さん「自給自足プログラミング」

ネットワーク応用通信研究所の原悠さんの発表です（スライド等はこちら⁠）⁠。発表スライドの表紙に，ネットワーク応用通信研究所の名前とともにまつもとゆきひろさんが映され，来場者の笑いを誘っていました。

原さんは，自分が欲しいと思ったソフトウェアを多数作成しており，それを自身のWebサイトやGitHubで公開されています。このセッションでは，自分で欲しいと思ったソフトウェアを作るにあたって考えていること，感じたことを話しました。

自給自足することのよさ

「自給自足」とはもともと農業の言葉です。また「自給自足」に相当する英語として「DIY」（⁠Do It Yourself）がありますが，これはもともと「家具を自作する」という意味があります。一方で原さんにとっての自給自足のプログラミングは，味の型紙で示された料理の考え方が近いといいます。これは例えば，そばつゆや天つゆを個別に買うのではなく，醤油・みりん・だし汁の組み合わせで実現する。面倒ではある一方，味を自分で調整できるし，調味料を置く場所は取らないし，何より楽しく感じられる。というものです。

自分で作るソフトウェアなら，必要な機能を自分で盛り込めるし，ソフトウェアを作って生活を変えられる。そこがソフトウェアを「自給自足」するよさだと述べていました。

また原さんは，ソフトウェアを自給自足することは，プログラミングの練習としてもよいと述べていました。技術が身につくということはもちろん，設計から自分でしないとならないので多くのことを考える。業務と違って売れないかもしれないソフトウェアを作ってもよい。失敗しても大きな問題にならない。ということが利点であるとのことです。

自給自足で作る

ソフトウェアを作るにあたっては，まずどんなものを作るか考えることになるでしょう。その際にほしいソフトウェアをRubyで作るには，Rubyでどんなソフトウェアが作れるかを知っておくのがよいだろうと話します。

原さんは，Rubyで作れるソフトウェアの類型を9つ紹介しました。典型的なものとしてCLIで動作するソフトウェアが挙げられますが，デスクトップアプリケーションもRuby-GNOME2やRuby/Tk，はたまたRailsとブラウザの組み合わせで作ることができますし。モバイルアプリケーションもブラウザはもちろん，iOS向けのRubyMotionやMobiRuby，Android向けのRubotoといったツールがあります。また，Rubyと他の言語（Java，Objective-C，JavaScriptなど）やツール（Emacs Lisp，VimScript，Gnuplotなど）を組み合わせることも考えるとよいと話していました。

続いて実際にソフトウェアを作るプロセスとして，「⁠まずはブレインストーミングで紙にどんどん書いていく。次にその紙を捨てる」と原さんは述べました。これには会場から笑いも起きましたが，原さんの意図としては「紙を捨ててから次に作るものは，最小限動くもの」とのことでした。最初に動くものができるまでに時間がかかりすぎると，モチベーション切れで続かないかもしれないし，またアイデアがよくなくて開発を続けなくなってしまう可能性もあるため，まずは小さく始めるのがよいとしました。

原さんの失敗事例としては，位置情報をもとに店で利用した金額を書き込むWebアプリケーションを作った際，実際に使ってみると不正確な位置情報が出ることがしばしばあり，これでは使えないと感じ公開には至らなかったことです。そのとき，もし最初からユーザ認証の作り込みを行っていたら，それも無駄になってしまっただろう，と話していました。

ソフトウェアを腐らせない

原さんは，「⁠ソフトウェアは腐るものだ」という，一見不思議に思えることを言及しました。続いて原さんは，ここでいう「腐る」とは「レガシーになる」ということ，すなわち放っておいたソフトウェアの更新が難しくなることだと言います。実際原さんも，MoneyRailのRailsのバージョンを容易に上げられず2.3のままにしており，テストコードがあればバージョンを上げるのがもっと楽だったのでは，と述べていました。

そして，ソフトウェアを腐らせないための方法として原さんは，「⁠テストを書く」「⁠こまめに手を入れる」「⁠ToDoはメモしておく」ということを挙げていました。テストについては指針として，最初からテストを書かなかったとしても，手作業でテストするのが難しくなってきたらテストを書こう，と述べていました。またこまめに手を入れることは，コードについて思い出すという意味で腐らせないことに役立つそうです。

またこれ以外に，ソフトウェアを一度作り上げてからやっておくとよいこととして，「⁠GitHubに公開する」ということも挙げていました。実際原さんは公開したことで，たまに外国の人からメールが来てびっくりすることがあったと言います。GitHubに公開することで必ずしも他人見られるとは限らないものの，公開しなければそもそも見られる機会もないので，公開してみようと話していました。

最後に発表の締めくくりとして原さんは，この発表を見て「何か作りたくなった」という人がいたらうれしい，そして「実際に何か作ったよ」という報告があったらもっとうれしい，と述べました。