satococoa's blog

Web や iOS アプリを作るエンジニアの日記です

Rails勉強会@東京第60回に参加しました

Rails勉強会@東京第60回に参加しました。
今回は4部構成でそのうち後半2部は2トラックという、盛り沢山な内容でした。

リアルタイムプロファイラのお話

「リアルタイム」にrubyのプロファイルを取れる、という内容でした。
Javaでできたモニタプログラムと、rubyに仕込んだプロファイリングモジュール間でTCP/IP通信を行い、モニタプログラム上でリアルタイムにプログラムの状況が見られる、というものだそうです。
デモでは実際にrdocを実行しつつそのメソッドの呼び出しがツリー状に表示され、それぞれの占める実行時間/親の実行時間に占める割合(%)が表示される様子を見せていただきました。
発表を聞いた後は
  • 果たしてWebアプリを作る上で「リアルタイム」のプロファイリングが必要?
  • ダンプが取れれば十分かも
  • Webアプリではruby自体よりも、問題になるのはDBの方かもしれない
  • あらかじめ本番環境に仕込んでおいて、問題があったとき(異常にレスポンスが遅いときなど)のみプロファイルのダンプを見られると良い
などなどの意見交換がなされていました。
残念ながら僕は知識不足によりあまり理解できませんでした。そもそも恥ずかしながらプロファイルとったりしていないという・・・。
「そもそもプロファイルはどうやって取っていますか。」という質問に対しては、会場からは以下のような方法が上がってきました。
  • New Relic
  • ruby-prof, tracer, profile, rbtraceなどのライブラリ
New RelicはHerokuでも気軽に使えますね。あとruby-profとかも遅いスクリプトがあったときに試してみようと思います。

ちなみにこのリアルタイムプロファイラは3月中に公開予定だそうです。

Kaminariのお話

作者の@a_matsudaさん自身による、Kaminariの使い方の紹介〜コードの説明をいただきました。
最初にKaminariの特徴として、「engineプラグインである」ということを挙げていらっしゃいました。つまり、ただのプラグインではなくて小さなrailsアプリというイメージ、とのことです。
kaminariをgit cloneすると以下のような構成になっています。
├── app
│   └── views
│       └── kaminari
├── config
│   └── locales
├── lib
│   ├── generators
│   │   └── kaminari
│   └── kaminari
└── spec
    ├── acceptance
    │   └── support
    ├── helpers
    ├── models
    └── support
app/views/kaminari/にはページ番号やらリンクなどを描画するためのファイル(partial)、config/locales/にはi18n用の言語ファイル、lib/の中にロジックが入っています。
lib/kaminari.rbでrailtie, engineをrequireしています。
railtieはrailsのプロセスが機能する際に最初にinitializer的に動く部分で、boot.rbが実行されているときのからみで実行されるらしいです。なので「起動時に実行してほしいこと」を書くとのことでした。
engineは宣言みたいなもので、engineの初期化処理なども書けるそうです。
あとはlib/の中身についてざっと教えていただきました。

最後におっしゃっていたのが、「ドキュメントがんばって書いたら海外の方にずいぶん使ってもらえた」ということでした。
あとプラグインのテストの話までは時間が足りずに至らなかったのですが、興味のある人はspec/fakeapp.rbあたりを見ると良い、とtwitterでおっしゃっていました。

テストを書くお話

このコマは2トラックに分かれ、もう一方はMongoDBの話(こちらも非常に興味があるので、他の方のレポートを書いてくださるのを楽しみにしています。)でした。
こちらのセッションでは、まずはrailsのテストについては今月発売のWEB+DB PRESS Vol.61を読むと良い、とのことです。まだ僕は手に入れていないので、今週買いたいと思います。
あとはテストに使用するフレームワークについての話が主でした。
Test::Unit, Shoulda, RSpec
Test::Unitもバージョン2になって書きやすくなった、とか。使っている人が少ないためあまりそれ以上は踏み込まず・・・。
モックについて
永和さんではrrが一番人気らしいです。RSpecにもモックの機能がありますね。
使い比べたりしていないため、それぞれの特徴はよくわかりません。
テストの実行が遅い問題
テストをたくさん書いていくとテストの実行が遅くなっていってしまうが、それを解決するためにはテストの起動が遅いのか、テストケースが多すぎて遅いのか、問題を見極めれば対策がとれる、という話。
テストケースが多くて遅い場合には、RSpec2系ではタグで絞り込みができるのでその機能を使う、など。(参考:http://kerryb.github.com/iprug-rspec-presentation/#21
テストの起動が遅いことが問題である場合には:sporkや、drubyなどを使う、など。
fixture_replacementについて
The Ruby Toolboxによると、Factory GirlとMachinistが2強対決といったところです。僕はMongoDBでも使えるfabricationを使っているのですが、Factory GirlとはgithubでのWatcher数が一桁違います。
Machinistは最近開発があまり活発ではないみたいなので、Factory Girlが現状では良い選択肢なんでしょうか。fabricationと比べてFactory Girlの方が良さそうなところがあれば、乗り換えたいと思います。

あとは、親子関係が複雑な(または階層構造が深い)モデルをどう表現するのか、というところが議題になりましたが、みなさん悩んでいるところということで答えは出ませんでした。

forgeryというライブラリも紹介されました。FFakerみたいにデモデータを作るのに使えるライブラリのようですが、自分で辞書を定義することもできるというところが魅力的です。(例えばアルファベットだけじゃなく日本人の名前データを生成するようにする、とか。)

Herokuについて

このコマも2トラックに分かれ、もう一方はCIなどの「テストを書いた後」について語らうセッションとなっていました。
この日はSalesforceの中の人がいらっしゃっていたので、その方からお話を聞きながら議論を進めるという流れでした。

中の人的に気になっていたのは「どうすればrubyコミュニティにもっとherokuをアピールできる?」というあたりとのことでした。
これに対して会場からherokuに対する意見として挙がったのが
  • 最初は無料だけど、ちょっと本格的に使おうとするとすぐ高くなってしまい、結局「無料のうちはherokuで、有料になるレベルになったらEC2やVPSへ」という使い方をよく聞く
  • エンジニアじゃない人が読めるherokuの記事や紹介がない
ということでした。
それらに対しては、
  • スーツな人でも好みそうな「カタい」日本語の入り口を作ればとりあえず広まるのでは。
  • 金額については、単純にサーバー代だけではなくEC2やVPSを使ったときのインフラ担当の人件費も視野に入れて比較すべき。
との意見が出されました。

個人的には小さな企業や個人が安価なレンタルサーバーを借りてPHPでやっているような仕事/趣味をherokuでカバーできるようになって、さらにはそこからrubyistの裾野が広がるといいのかなぁ、という風に感じています。
そのためには、herokuというよりはむしろgitの方が敷居が高いのかも知れませんが。

懇親会

終わった後、希望者でビール片手に語り合いました。プロジェクト管理やタスク管理、見積もり、バージョンアップについて、他の言語について、など色々と話すことができて楽しかったです。

また次回も都合が合えばぜひ参加したいと思います。ありがとうございました。