札幌Ruby会議2012に参加してきた

2012年9月14日(金)から16日(日)まで札幌で開催された「札幌Ruby会議2012」に参加してきました。
テーマは「We Code.」実行委員長の島田さんのお話では「コードを書く上で周りの人との関わりを考えて欲しい」とのことでした。

以下がセッションの感想です。(preで囲ってるところは私が取ったメモ)

9月14日(金)

Heroku(相澤 歩)

現在約220万ものアプリケーションを動作させている。200億円でセールスフォースに買収された。
あまり知られてないかもしれないけどgem install herokuをしなくてもデプロイは可能。
現在Ruby以外にもあらゆる言語が動作する。
追加のアドオンは80種類ぐらい存在する。FacebookアプリケーションはデフォルトでHerokuにデプロイされる。
8月27日にmixi API Quick Startが開始された。これによりmixiアプリはデフォルトでHerokuにデプロイされる。
herokuの実績
・asics ニューヨークシティマラソンのサイト
・do.com セールスフォースのプロダクト
・groupme メッセンジャーツール
その他の事例は次のURLを参照
http://success.heroku.com

質問
Q.Tokyo Regionにはいつ来るの?
A.具体的な計画はない
が、基盤となるクラウドに依存しない設計に変えてきている。

Q.日本語情報は?
A.情報の日本語化は進んでいない
@herokujpをフォローして下さいとのこと

個人的にはRailsはレールに沿って正しく作った時に、最大のパフォーマンスが発揮されると思っている。
なのでデプロイ先はIaaSよりPaaSサービスの方が好きかも。スケーリングにも容易に対応できるし。
Engine Yardの日本法人ができたり、ペーパーボーイのsqaleがサービス開始されたり、他にもIIJのMogokがあったり、選択肢が多いのはとてもいい事だと思う。

ふつうのソーシャルコーディング(高橋 健一)

永和システムマネジメントでは
1) Cucumberでエンドツーエンドテストを書く
2)RSpecでユニットテスト
3)プロダクトコード
4)リファクタリング

Activity Specを書いている。
これは「サインインした。」「質問をポストした。」というユーザーの行動単位のテスト。
仕様変更によって不要になったテストコードは捨てている。
Pull Request単位でレビューを行う
読みにくコードはリーダブルコードの章番号を入れて根拠を示している。
レビューは殺伐となりやすいのでGithubのissueのコメントに絵文字やミサワを入れている。
CIはTravis CIを使用している。プライベートリポジトリでTravis CIを使うにはTravis Proを使う必要がある。
ステージング環境でお客さんに動きを確認してもらう

永和システムマネジメントさんでどのように開発を行なっているかの説明だった。
テストコード量のリストではrequest_specが多く書かれていたのが気になった。

次の言葉が印象的。
「動くソフトウェアこそが進捗の最も重要な尺度です」
「自分たちプログラマが納得できるようなプロダクトを作ることもできずに、
お客様を満足させることはできるのか?私達プログラマが毎日使いたくなるようなものを作りたい」

我々開発者は正しい開発手法を学び、それをお客様にきちんと説明して共感を得ることが重要だと感じた。
あと、ソースレビューが殺伐としてしまうのを防ぐため、ウチの会社のレビューもミサワを推奨しようと思う。

クックパッドのつくりかた(井原 正博)

クックパッドは20-30代女性の1/2が利用している。
才能がきちんと生かされる社会。
技術を正しく理解することはコストを圧倒的に圧縮することを意味する。

・自分のやりたいことを見つける
・得意なことを見つける
・やるべきことを見つける
この3つが重なることだけをやろう。これが決まれば気持ちいい

・技術に対する考え方
→技術はあくまでも問題解決するための道具である

・ユーザーに対して
問題可決をさせてもらえることに感謝しよう
技術を使う場所に感謝しよう

・クックパッドのものづくり
→ユーザー中心のサービス開発
1行のログの向こうには、1人のユーザーがいる

・エンジニアが働く環境
エンジニアは成長のエンジンである。
履歴書ではなくもの(Github,Webサービス等)を見る
ソースは個人でも会社でも公開を推奨

クックパッドの経営理念である「毎日の料理を楽しみにすることで、心からの笑顔を増やす」という言葉をエンジニア一人ひとりが実践しているのを感じた。
世の中に「問題」が存在しなければ我々エンジニアの存在意義は無くなってしまう。そういう意味で問題を提供してくださるお客様に感謝しようという考えは共感する。

9月15日

コミュニティのある風景。(佐藤 竜之介氏)

http://nothub.org の作者
プログラミングと出会ったばかりの頃はオープンソースとの関わりもなかった。
そのうち気になっているプロダクトや人をgithubで追いかけるようになった。
Pull Requestへの不安。
・こわい
・恥ずかしい
・気が引ける

不安を解消するために安心できるまできちんと調べるようにした。
・commit logのチェック
・MLでの議論
・テストの有無
・作者の意図にあってるか?

Patchを送る量が増えるにつれて...
・自分の送った pull requestへのフィードバックが気になる
・頻繁にタイムラインを見に行く
・なので自分で作った -> nothub

自分で新しいものを作るということは、ライブラリの未知のbugに遭遇する
パッチを貰うと嬉しい

Q.Pull Requestの英文はどうやって書いているか?
A.10分で修正できるコードでも英文に3時間かかることもある。

岡山Ruby会議にも来て下さった佐藤さん。
自身がソーシャルコーディングにハマっていった過程を熱っぽく語っていたのが印象的。
私も好きなGemのgithubのコミットログは読むことにします。

Keynote(Aaron Patterson)

RubyConfでは日本人が英語でプレゼンしてる。こんどは私の番だ。
We Eat.
We Play.
We Code.

たこ焼き仮面さんがサラミづくりに必要な温度や湿度の管理をRubyで作った話。
正直どこまでがジョークでどこからがマジなのかよく分かりませんでしたが、日本語がとても上手でユーモアは伝わって来ました。

Keynote (まつもとゆきひろ)

One Size Does Not Fit All
我コード書く、故に我あり
1993年2月にRubyを作り始めた。来年で10周年。
初めはUNIXのスクリプト言語として作り始めた。Perlの代替品。
「なぜRubyをつくったの?車輪の再発明では?Rubyを作る労力をPerlの発展に注ぐべき」という意見があった。
限られたリソースを新しい言語につぎ込むのはムダなのか?

マンパワーではなくモチベーションである。
私たちは機械ではない。突き動かす力が必要。
車輪の再発明でもモチベーションがあるならやればいい。それは多様性をもたらす。
多様性は善である。

イノベーションのことについて理解していない
Matz自身も分からない。なのでRubyの成功の要因については正直分からない。

RubyはWebの世界を征服した。
But Web is not everything
Rubyが脳と機械の間に入ってる。Rubyが俺たちの脳にしっくり来ならPython,Haskel,Javaなど他の言語もある。

別のRubyの処理系を使おう
・JRuby
  マルチコア対応
  投資されている
  長く動作するプロセスに適している
  Windowsでもちゃんと動く

・Rubinius
  C++ Core
  内部のライブラリはRubyで開発されている。
  意外と高速である。

・MagLev
  VMWareで作ってる
  分散オブジェクトシステム
  オープンソースではない

・mruby
  組み込み向けAPIを持っている
  実行時に構文解析は不要である
  自販機に組み込むことも可能。

まつもとさんのお話はいたるところで聞いてるけど、ユーザーベースのコミュニティでお話されるときは生き生きしてますね。
車輪の再発明はムダではない」という言葉にはとても共感します。
どんな分野でも人月を投入して進化することはない。モチベーションがあるから進化するのだと自分なりに理解しました。

Rails3レシピブック外伝 (松田 明 + 豪華ゲスト陣)

使ってはいけない名前。
Entryというmodel。
typeというカラム名。
taskっていうモデルもダメ。
Applicationっていうリソース名もだめ。

gemの名前にだれかがモデルにしそうな名前をつけるのはNG。
なのでキラキラネーム推奨。

ポリモルフィックアソシエーション
has_manyなレコードを参照すると膨大なSelect文が発行されるn+1問題を防ぐことができる。
gemにしてくれる?

AR::Relation#mergeを使い倒す
whereでサブクエリを作成する。

notやlikeのクエリをruby的に書きたい
gem 'everywhere'
User.not(:age => 20)
User.like(:name => "%moto%")
みたいに書くことができる。

Rack middleewareを削ることで高速化させる
Rack::Cacheがクセモノ
消すことで1.5倍の速度

migrationをGUIで実行する
gem 'erd'
localhost:3000/erd

Engineを使う
小さいRailsアプリのようなものを作って他のプロジェクトにくっつけて使う。
deviseやkaminariで使用されている。

「Rails3レシピブック」に掲載されなかった内容の発表でした。
正直スピードが早くてついていくのがやっとでした。どの内容も使えそうなものばかりなのでキーワードを元に一つずつ検証しよう...

Ruby on Rails: The Bad Parts(浦嶌 啓太)

1ヶ月立ったら読みたくないコードは書きたくない。

対応策
1.ヘルパー多すぎ
2.パーシャル多すぎ
3.モデルが大きすぎ

1.ヘルパーは我々を助けてくれない
  ださい。
  railsがダメ。
  Helperは共通。

  AcitveDecorator (amatsuda作)
  https://github.com/amatsuda/active_decorator

  app/decorator/user_decorator.rb
  Helperに書くべきことをmodelにひもづけることができる

  AcitveDecoratorのライバルdraper
  ActiveDecoratorはmodelのオブジェクトが同一
  Draperはmodelが別オブジェクトになってしまう

2.パーシャルはパーシャルであってパーツではない
  actionにパーシャルで必要なインスタンス変数を作るのはヘン
  とはいえbefore_filterにかくのもおかしい

  apotonick/cellsを使った
  https://github.com/apotonick/cells
  app/cells/sidebar_cell.rb(ミニコントローラみたいなもの)
  app/cells/sidebar/recent_tags.html.haml テンプレートを書く

  viewで
  render_cell を呼び出す

3.モデルが太りすぎてる
  500行ある。でも、中をみるとおかしなことはやってない。

  小さなライブラリを作る
  extend ActiveSupport::Concern
  http://d.hatena.ne.jp/UNKK/20110719/p2

  モジュールをインクルードした時の処理をまとめる
  そんなに汎用化しなくていい。
  テストはインクルードした先を普通にテストしている


  複数のモデルが絡むロジックはどこに置けば良いのか?
  今までいっしょくたにモデルに突っ込まれていた振る舞いが、あるべき場所に収まる
  ->DCI

  3つの問題点の共通点
  アプリケーションに点在するロジックを置く場所がRailsが用意してない
  これを正しい場所に置くことが大切。

私にとって一番収穫があったのがこの発表でした。まず冒頭の3つの問題点は私が関わっているプロジェクトにもそのまんま当てはまります。
Railsはレールにそって作っていても必ず幸せになるとは限らないのです。
この3つの対応策を検証してプロジェクトに取り込むのが私のミッションだ!と感じました。

LT大会

・thinreports-rails
  データとデザインのヒモ付をviewに書くことができる

・axlsx
  CSVのダウンロードでいいの?顧客はそんなの使わない。開発者が楽したいだけじゃん。
  機能豊富なxlsx作成用gem

とりあえず印象的だったものだけ。

9月16日

Ruby の世界の継続的デリバリ(柴田博志)

3月に大江戸Ruby会議を開く。
tDiaryをPaaSサービス等あらゆる環境で動作するように改善を進めている。

・意識が低くても大丈夫なしくみ
  Jenkins、guardでテストを自動化する
  いつ導入するか? => プロジェクトの初め

・結合テストで品質が上がるわけではない。
  なぜならテストでは品質が高いかどうか確認するために行なっているから。

・確実なフィードバックと改善を行える仕組み
  「自分たちがリリースとしているのはなんだろう?」と話し合うこと

・テスト以外こそ機械にやらせよう
  Chef,puppet,Capistrano,webistrano(若干オワコン)
  Deploying Railsという本はpuppetでのデプロイ方法がかかれている

・サイクルタイムの短縮と継続した価値の提供
  変更すると決めてからユーザーが使えるようになるまでの時間を短縮する

・Jenkins Promoted Builds
  承認チェックを入れることができる。
  人がやる箇所もビルドパイプラインでに入れることができる。

・継続的な改善
  毎日ダメと感じたことがあれば毎日直す

・Migrationsはビルドパイプラインではどうにもならない。難しい問題。

1年前の自分と比べると自分が担当しているプロジェクトに多くのツールを導入できていると思う。
テストを書きJenkinsでCIを回し、Capistranoでデプロイできてる。ただ、その本質を見失っていたかもしれない。
本来の目的はお客様に正しく動くシステムを早いサイクルで届けるのが目的だったはず。それは達成できてるだろうか?
多分Noだと思う。この発表はツールが持ってる機能ではなく、なぜそのツールが必要なのかという点に気付かされた。

分散 RSpec (村田賢太)

クックパッドの月間利用者数2000万。レシピ数1,200k。
Modelが800個
Chanko specs 13030個

Chankoはアプリケーションの公開範囲を設定するツール

100人以上に公開する場合はきちんとしたテストを書くというルールにしている。
デプロイ可能になるまでの時間を短縮する。
1日40回リリースするためには6分でビルドが完了する必要がある。
開発者向けにいつでもフルテストが実行できるようにしている。不要なテストは削る必要がある。

テストの増加に対してスケールできるような仕組みが必要。
そこで分散spec。
CIでもrspecを分散実行→分散CI
1.RSyncでソースの同期
2.環境の構築
3.RSpecをリモートで実行

各specの実行時間を記録して、分散している。
どのサーバーから出てきたlogかを管理することができる。

実行時間が均等になるようにテストを各マシンに分散してもばらつきが発生してしまう。
繰り返しテストを行うことで徐々に遅くなることがあるのかも。
そこで実行時にワーカーの状態を見てダイナミックにテストを実行する方法を思いついた。
キューにスペックファイルのpathを突っ込む
dRuby + TupleSpaceで実行
まだ、実現していないが東京に帰ったら試してみる。

私が担当しているプロジェクトでもスローテストは大きな問題となっている。
私はrspecとcucumberのファイルを実行時間ではなく行数で判断して分割しJenkinsで並列テストを実行している。
当然実行時間にばらつきが発生してしまい、複数のマシンの力が十分発揮されてない。
村田さんのキューで処理する方法が正しいのは明らかだが、残念ながら私の技術力がまだそこまで到達していない。
今後の情報をこまめにチェックしていきたい。

Spree で約3ヶ月でイチからEコマースサービスを作るまで(白土 慧)

OhMyGlasses
http://www.ohmyglasses.jp
メガネの通販サイト
元々PHP Magentoで作られてた

「LEAN STARTUP」
Get the first Feedback
顧客はどこにいるか?
オペレーションがまわるのか?
一度検証する必要がある。

PHPのまま進むのか?
Railsでやるのか?

・なぜRailsにしたのか?
  試行錯誤を繰り返す必要がある。そのためにはエンジニアが手に馴染んだフレームワークである必要がある。

・なぜSpreeにしたのか?
  ECサイトが初めてだった。決済処理でトラブルのだけは避けたかった。

・Standing on the Shoulders of Giants.
  巨人の肩に乗る。使えるものは使う。

・Spreeについて
  spree_api
  spree_promo
  spree_auth_devise
  spree_dash
  幾つかのモジュールに分かれている。これらはRailsのENGINEで動いている。

・モデル
  大きく分けると
  User系
  CartPayment系
  Product系
  の3つに別れる

・巨人がどうできているかを知る必要がある。
  Gemの中にloggerや.tappを埋め込んで動きを調査した。

ソースを読むときにフォーカスを絞る
とりあえずはPHP版と同等の物を作る

Spreeの中で決済の流れは決まってるので、レンズを選ぶプロセスを挟む必要がある。
レンズを選ぶと金額も変わる。
Adjustmentsという仕組みがすでにあるのでLensAdjustmentsを追加した。
理解するためにはソースをコードを読むことが重要。

・Spreeはどうよ?
  カート、決済周りはよくできてる(できすぎ)
  商品の属性が1つしか無いのでやりづらい
  管理画面はよくできてる。

・ECサービスをつくってみてどう?
  BtoCのサービスは楽しい。これが広告モデルだとユーザーに邪魔に思われたりする。
  メガネを買ってもらって喜んでもらえれば利益が出るので分かりやすい。

・まとめ
  評価のためにフィードバックを得ることが大切
  イテレーションを早く回すことが大切
  巨人の肩の上に乗ってるのをよく認識する(ソースを読む)
  フォーカスを絞る

EC用フレームワークSpreeを使ってECサイトを作ったお話。
「今、必要な事は何か?」と、直近の問題に対してその都度方向を定めているのが良いと思った。
ただ、使うだけでなく、ピンポイントで正しく修正するためにはソースコードをよく読むことも重要だと思った。

テストに開発を駆動させたい!(諸橋恭介)

テストは書きたくないけど将来のために書いてるのか?
テスティングフレームワークを使って、開発を助けてくれている
データ投入等全部手でやるのは大変。

・考える
Railsの便利機能やgemはないか?
検索条件は?
どういうAPIにするか?
テストを見ながらメソッド名を考える。
まずはテストが通るような正常系を作る。

次にフォームの内容を考慮しつつ、テストを書く。
「あなたがこう動かしたい」という内容をテストとして書いて、ソレが動くまでコードを書く。

             code       
       ↑                ↓
   run       ←       think


デベロッパーテストは開発をドライブするためのもの。
書いたものはすぐに実行したい。
それをやってくれるのがテストフレームワークである。
将来のためにテストを書くのではなく。書いたプログラムを動かすためにテストを書いているのだ。

ActiveRecordのバリデーションのテストはやらない。
それはActiveRecordの作者がやってくれている。

moroさんにはRubyKaigi2011やRubyWorld Conferenceなどで何度かお話を伺っている。
その時テストの粒度やテスト方法など幾つかアドバイスを頂いた。
今回はテストについてとても愛のある話だったと思う。テストは将来のためにイヤイヤ書くものではない。
今作っているコードを動かすため、更に思考を繰り返すために書いているのだと熱く語られていたのが印象的だった。

クリアなコードの作り方(須藤功平)

Rubyだから楽しいわけではない。汚いコードと向き合うと楽しくない。
だんだんと汚れていくコードと向き合うと楽しくなくなる。
直しても直しても他の人が汚していく。掃除しているそばからゴミを捨てられているよう。
なので、クリアなコードを書いて欲しい。

他の人のことを考えて書く。他の人のコードを読む。

リーダブルコードの解説
1.実際にやる
  書く
  仕事場の環境が悪いから腐ってるんだ...ではダメ
  本を読んでるだけじゃなくて実際に書く

2.当たり前にする
  書く
  まわりのコードが汚くたって、自分も汚いコードを書いていい理由にはならない。
  1時間に1回もコミットしないのは異常。周りの人に相談しよう。
  読む
  少なくとも自分が関わっているプロジェクトのコミットはすべて読む

3.コードで伝える
  書く・読む・書く
  コードを通じて伝える。
  コードを書いているだけで人に影響を与えることができる。

コードを読むことの重要性については耳が痛い。仕事仲間のコードを十分読めてない。
「僕たちはコードで語り合える!」という言葉が、札幌Ruby会議のテーマ「We Code」にうまくつながり感動のフィナーレでした。

感想

「We Code.」言葉は要らない。私たちはコードで語り合えるという内容の発表が多いのが印象的でした。
最近コードが書けてるか?ちゃんと人のコードが読めてるか?皆さんの発表を聞きながら考えこむことが多かったです。

あと、今回はリージョナルRuby会議であるにもかかわらず海外の方の参加が多く参加されていました。コードで語り合えるとは言え、英語が話せればもっと多くの人とコミュニケーションできたのにと感じました。ダメなところがあればすぐに修正するのが本当の技術者。英語も何とかしないと。

最後にスタッフの皆様お疲れ様でした。会場のセッティングだけでなく懇親会の手配等大変だったと思います。
岡山にお越しの際はぜひ声をかけてください。