第２回渋谷Edge Rails勉強会に行ってきました #shibuyarails

最近Rails3の勉強を始めてて、ちょうどいいタイミングで勉強会があったので参加してきました。

【満員御礼/増員230名】第２回渋谷Edge Rails勉強会 @masuidrive氏によるRails3講義 × 株式会社ドリコム事例発表

講師は風呂グラマーとして有名な @masuidrive さん。以前 Titanium Mobile の勉強会でお会いしたのですが、まさかRails勉強会でも会うことになるとは。

今回は先日購入した新しいiPadを実戦投入してみたということでメモを取るのに必死で途中聞けなかったんですが、頑張ってまとめてみます。

内容はRailsの歴史から始まって、Railsを取り巻く環境（経済面）とか開発・運用の話、Railsの今後について広く浅くという感じでした。ところどころ具体的な話が出てきて色々参考になりました。気になった点は以下のとおり。

Railsアプリを監視するNew Relicというサービスがある
Railsアプリを開発・運用してるとバージョン追従問題に躓く
テストを書いてないとRailsアプリの運用は大変
レベル別デプロイというアイデア
Scaffoldは使わない

Railsアプリを監視するNew Relicというサービスがある

これはすごいです。New Relic というサービスなんですが、Railsアプリのレスポンスのパフォーマンスだけでなく、メソッド呼び出しレベルまで落としこんで計測できるらしいです。どのメソッドにどれだけの時間がかかっているからそこをチューニングすれば云々とかが一発でわかりますね。
いいなーって思ったんですが、１サーバの監視で月額1万円くらいするらしく、個人にはちょっと辛いサービスだなという感じです。でも使ってみたい。

Railsアプリを開発・運用してるとバージョン追従問題に躓く

Railsの場合バージョンが0.1でも違うと大きく変わっていたりして、大変らしいです。Twitterのタイムラインを見ていても2.x系から3.0にバージョンアップするより、3.0から3.1にバージョンアップするほうが苦労したなんて人もいました。それぐらい大変。
でもそれにはRailsのしっかりとした思想があって「変化を進んで受け入れる」ということらしいです。開発者のDHHさん曰く「テストをしっかり書いて、テストがこけた部分だけ修正すればいいじゃん」みたいなことらしいです。

テストを書いてないとRailsアプリの運用は大変

ということで、テストを書いてないとRailsアプリの運用は大変みたいです。周辺のライブラリのバージョンを上げる必要が出てきて、そのバージョンを上げるためにはRails本体のバージョンも上げないと行けなくなって大変。みたいなことが起こるそうです。
コードとテストの比率は1:3位が理想だけど、最低でも1:1は必要とのこと。1:3という比率は、コードを書くのに1週間かかったら、そのテストを書くのに3習慣かかるってことらしい。大変。

レベル別デプロイというアイデア

レベル別デプロイってどういう事かというと、新機能を追加するときにステージング環境を用意しないで、最初から本番環境にデプロイしましょうということ。ただし、新機能を公開する範囲を制限する。最初にそのサービスの開発者だけが使えるように制限して、その後、部内→社内→αテスタ→βテスタ→全体公開という流れで開放していく。そうすることでスムーズに新機能が追加できるよねということ。
現場でよく聞く「開発環境だと動くんですけど」なんて言い訳を効かなくなる日もそう遠くない？

これはクックパッドかどこかがやってたよなーって思ってたら、質問タイムでそういう話が出てきました。なんていうプロダクトか忘れましたがなんかあるっぽいです。

Scaffoldは使わない

衝撃的でした。railsを初めて触ったときに衝撃を受けた機能なだけに、それを使わないっていうのも衝撃的でした。まあ、Model定義してController書いてroute.rb編集してView書いてってしたほうが自分の思ったような挙動になるよね。というか、モデルに対する単純なCRUDなんて、実際のアプリケーションだとそんなに多く無いのかな。

感想

masuidriveさんの後にもう一つ「Railsのはまりポイント10選」という発表もあったのですが、iPadでメモを取ることに疲れてそんなにメモが取れていません。申し訳ない。ただ、気をつけようと思ったのは以下の2つ。どちらもMySQL使用時に引っかかりそうな罠です。

index名の長さ

MySQLのindex名は64文字まで。
Railsが生成するindex名の規則は「テーブル名_カラム名1_カラム名2_....」みたいになるので要注意。

tinyintという型について

ActiveRecordではMySQLのtinyintはbooleanとして扱われる。

おまけ

iPadを使って一生懸命とったメモを貼っておきます。

Railsの歴史から

2005年にrails誕生
特徴
CoC
DRY
MVC
フルスタック
Generator/Scaffold
Write less code
なるべく少ないコードでいろいろできる
問題点
不安定
遅い
メモリ食い
実績が少ない
Ruby プログラマが少ない
特に海外

2007年 rails2
特徴
RESTfull
XMLからJSONへ
問題
実装複雑
他のフレームワークが出てきた
Merb まーぶ
モデル != テーブル
DataMapper

周辺
Merbベースにrailsを作るぞ！
周辺サービスが出てきた
heroku
new ralic 監視サービス
railsのプラグインとして組み込める
月1万円くらい
Engine yard
しばらく食べていけそうな経済圏が出来ている

2010年 rails3
特徴
問題
バージョン追従問題
本体のバージョンを固定するとプラグインのバージョンを上げられない
バージョンアップにはテストが必要
3.2.2でほぼ完成

Railsの思想
変化を進んで受け入れる
互換性よりはプログラムとしての正しさを追求する

向いてるアプリ
一般的なwebサービス
変化が激しい
apiを提供する

コードを書く
黙々かく
後で呪われないように
scaffoldは使わないよね
プラグインを使うか、使わないか

テストを書く
変化への備え
最低でもtest/codeは1.0を超えたい
3あるといい
UnitTest vs RSpec
密かに裏コマンドを用意する
テストデータを作る

パフォーマンス
ベンチマーク
 sqlレベルでチューニングするしかない
特にmysql
キャッシュ
memcached使ってます
routes重いよ

運用
Unicorn? Passenger?
heroku
監視

レベル別デプロイ
一部のユーザのみに新しいコードをデプロイ
開発者部内社内あるふぁべーた全体という段階を踏む
ますいさんがnginxモジュールとして開発中
クックパッドが似たようなの作ってたよ

rails4
次のバージョンは4
今年出る予定
Ruby1.9系
REST 強化
Railsは大きくなりすぎてる懸念
モジュール化しすぎててどこを直せばいいかわからない

Delayed Jobはいけてないの？
何となくresque使ってます

rails for zombie