RubyKaigi 2013 に行ってきた

RubyKaigi 2013 に行ってきました。僕の気になった発表について、メモを残しておきます。

1 日目はほとんどコードを書いていたので 2 日目から :|

High Performance Rails - @mirakui

http://rubykaigi.org/2013/talk/S76 https://speakerdeck.com/mirakui/high-performance-rails-long-edition

Rails のログに書かれているレスポンスタイムではなく X-Runtime を参考にする。
X-Runtime はリクエストからレスポンスまでの時間。
Ruby は遅い。Ruby には極力処理させない。
Apache(static file) - Varnish(page caching) - Nginx(proxy buffering) - Unicorn(Rails)
REE 1.8.7 - MRI 1.9.3 - MRI 2.0.0 どんどんレスポンスタイムが短縮された
AR のオブジェクト生成とルーティングの解決が重い。
AR の Load は SQL の実行にかかる時間であって、実際には AR オブジェクトの生成にもっと時間がかかっていることを忘れがちである。
link_to ヘルパーについて、controller: 'hello', action: 'index' と書くよりも hello_index_url と書く方が 100 倍速い
テンプレートエンジンは Ruby コードにコンパイルした後の速さが重要。Slim が一番速く、その次が ERB 、一番遅いのは Haml…
Unicorn で GC.disable。GC を無効にすると Worker のメモリが膨れるので、unicorn-worker-killer で適宜落とす。
スロークエリを arproxy - fluentd - mongodb で記録。ツールを作って記録できるように。遅いコードを書いた人に斧を投げる。
プロファイリングは ruby-prof / kcachegrind を使うのが定番な感じだが、なかなか深いので読みにくい。3.2 から追加された ActiveSupport::Banchmarkable で何箇所か囲って重い部分を計測していく。これは便利そう。

新たに追加されたスライド

Browser-side Caching
Fragment Cache
Action Cache
Profiling

感想

WEB+DB PRESS の Rails 高速化記事が非常に良かった @mirakui さんの発表でした。アップロードされたスライドは、発表時間の都合で削除された 40 枚のスライドが追加されているもので、表示まわりのキャッシュについて書かれており、必見だと思いました。これだけのアクセスを捌く必要がある環境で Rails アプリを開発できるのはとても羨ましいですね。

Continuous gem dependency updating with Jenkins and Pull Request - @kyanny

http://rubykaigi.org/2013/talk/S72 https://speakerdeck.com/kyanny/continuous-gem-dependency-updating-with-jenkins-and-pull-request

gem はこまめにアップデートするべき
bundle update を Jenkins で
Gemfile.lock をコミットし spec を実行
可視化: ブランチを切って gem をアップデート。spec を走らせた後に Jenkins から pull request を送る / hub pull-request コマンドを使うのか
pull request のタイトルに Build: SUCCESS とか載せておくと判断するのに便利 / アイコンも Jenkins のおじさんにすると分かりやすい
Pull request で Changelog や tag の diff を読む。それもなければ git log を読む…

感想

Gemnasium からアップデートを通知されたら対象の gem をアップデートするようにしているのですが、その度に Changelog や Diff を確認するのは面倒です。それを Jenkins を使用して自動化し、テストが失敗したらチェックする、ということで負担を少なくするのは非常に良い考え方なだと思いました。そのためにはもちろんテストをしっかり書く必要がありますね。僕も真似したいなと思います。結構大変そうですが。

Concerning 'Applications' - @moro

http://rubykaigi.org/2013/talk/S61 https://speakerdeck.com/moro/concerning-application

感想

ActiveSupport::Concern で Fat Model 問題を解決する、という話でした。 Concern を使用することで細かい振るまいごとに分けていきます。 @joker1007 さんが、Concern を使用することによる良い点は、DRY 化やコードの整理よりも、振る舞いに名前が付く事だと思う。それはメンタルモデルの明示に繋がる。とおっしゃっており、非常に納得しました。

自分が思っていたより難しいテーマで、着いて行くのが精一杯で全くメモを取れませんでした。スライドを見なおす必要がありそうです。

Refactoring Fat Models with Patterns - @brynary

http://rubykaigi.org/2013/talk/S32 http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

感想

Concerning 'Applications' と似たような感じで、Fat な Model をリファクタリングする方法なのですが、内容が似ているのか？と思っていたら、こちらもとても役に立ちそうなものでした。具体的なコードが提示されており、とても分かりやすかったです。

こちらも英語を聞き取るのに精一杯でメモを取れませんでした。上に書いてあるブログ記事を発表したものです。発表に余裕があってかっこ良かったです。 Code Climate に興味が湧きました。

From Rails to the web server to the browser - @dabit

http://rubykaigi.org/2013/talk/S26 https://speakerdeck.com/dabit/from-rails-to-the-webserver-to-the-browser-ruby-kaigi

感想

発表を観ていなかったのであとで観る :(

Rails Gems realize RESTful modeling patterns - @tkawa

http://rubykaigi.org/2013/talk/S78 http://www.slideshare.net/tkawa1/rubykaigi2013-rails-gems-realize-restful-modeling-patterns

実際の gem のパターンを見てみる

認証: Devise
/users/sign_out
/users/sign_in
Devise だと Sessions がリソース(モデルではないリソース)
Session は単数: ユーザーごとに一つしか存在しない
Session Resource pattern /session
Authlogic はモデルを用意しており、継承して使う
認証処理が Model に移された -> 良さそう
検索: Ransak
q[name_cont]=hoge
filtered-collection
ページング: kaminari
ウィザード: wicked
GET /user_steps/personal
PUT /user_steps/personal
GET /user_steps/social
PUT /user_steps/social
グループに分かれている

リソースモデリングパターンをまとめている: http://rest-pattern.hatenablog.com/

感想

リソースに困ったら gem のパターンを見てみましょう、というのが良い考えだなと思いました。ルーティングを考える時になかなか良い案が浮かばないことがあって、その時は gem だとか有名な Rails アプリ(gitlabhq など)を参考にしてみると良いですね。

全体的な感想

色々な発表を聞くことができてとても良かったと思います。やる気が出ました。

RubyKaigi は初めての参加でした。大きいカンファレンスに参加したのもこれが初めてなのですが、Early Bird 価格で 2 万円というのはどの程度妥当なのかが気になりました。有名な方の話を実際に聞けたりするので丁度良いくらいなのでしょうか。

人見知りスキルを遺憾なく発揮したことで、だいたいぼっちでした。辛い感じです。

メモをまとめるのに疲れたのでここらへんで...