RailsConf 2008まとめ(簡易版)

Ruby on Rails
  • 参加分のみまとめ
  • 聞き取り調査したベンダのまとめは別途

2008/5/29(Tutorial)


Refactoring Your Rails Application

  • 印象に残った事
    • コントローラはできるだけ薄く
    • ViewにあるロジックはPresenterにextract
    • 改造版STracによるプロジェクト計画管理
    • 「なんか不自然」「読みにくい」「テストしきれてない」...そういうコードは、「技術的に借りを作ってしまった」ということ。借金は膨れ上がらないうちに返さなければならない。そのための技術がリファクタリング。

Powering AIR Applications with Rails

2008/5/30

IronRuby on Rails

  • Microsoft .NET上実装のIronRubyでもRailsが動いているよ、というお話
  • コードの変更はほとんど不要。SQLServerアダプタ利用を宣言するところくらい。
  • but wait... there is more!
  • SilverlightアプリケーションをIronRuby on Railsから制御するためのライブラリSilverlineが紹介されていた。
  • んー、でもこのためにWindows導入して苦労するのもなんだかなー。

Surviving the Big Rewrite: Moving YELLOWPAGES.COM to Rails

  • YellowPages.comをRailsで全面書き換えしたプロジェクトの報告。
  • 今回、一番感動した話。
  • 古いコードを「資産」としてとらえるか「不良資産」としてとらえるか。
  • テストコードがない、コードが汚くて保守性が低い...これらは「不良資産」。
  • RailsできちんとAgile開発する事で短期間のうちに、きれいで高性能コードの成果物を届ける事ができた。
  • あくまで、人の問題でもあるわけだが...
  • CTO(技術担当最高役員)の理解が得られたのも大きい。
  • 資料

Faster, Better, ORM with DataMapper

  • ActiveRecordとはちょいと違うORM
  • id map...ある行を格納するオブジェクト実態は常に一つだけ
  • lazy loading...大量の行を読み込んでも、実態にローディングされるのは参照時直前
  • connection poolやらdirty trackingやら、ActiveRecordよりもよさげ
  • レガシーDBとのマッピング定義も多少楽になりそう
  • 関連リンク

Flexible Scaling: How to Handle 1 Billion Pageviews

  • Facebook上で動くWorld War Craftもどき「Warbook」の性能対策
  • WarbookはAmazon EC2上で動いている。バランサはperlbalで、後ろに12台のmongrelを並べてスケールさせた。
  • 使うべきツール
    • firebug, iostatやmtopなどのコマンド
  • 使うべきではない手段
    • logging
  • 使った手段...とにかくキャッシュヒット率を高めるようにした。95%達成。
    • memcache (GByte単位)
    • セッション情報をmemcache上に置くようにした
    • no-select design
    • cache_fu

UI Design on Rails

  • 37signalsにおけるデザイナとプログラマ連携の事例紹介
  • デザイナにも積極的にviewファイル(.erb/.rhtml)を触らせろ、そしてリポジトリを使わせろ、というお話
  • 最初はちょんぼもあるかもしれない。でも、そこで壁を高くしては駄目。ちゃんと対話し、一緒にイタレーションを回せるようになれば、開発はとてもうまくいく。
  • 目から鱗が落ちた

2008/5/31

Assembling Pages Last: Edge Caching, ESI & Rails

  • ESI (Edge Side Includes)を使った高速化の話
  • ESIそのものはRailsに限った話ではない
  • 画面構成部品(Railsならrender partialで描く単位)ごとにキャッシュさせる
  • 商用サービスのESI(Akamai)なら、キャッシュを地域分散させることも可能。ESI実装で一番完全に近いのはAkamai。
  • オープンソースだと、mongrel-esiやsquidなどが使える
  • 商用製品だとWebsphare, Oracle Web Cache 10g, Big-IPなど
  • ESI利点
    • ESIから先は並列実行が可能になるのでレスポンスが高速化される
    • Rails（あるいはその手前のmongrel)に到達する問合せは激減する
    • RESTと相性が良い
    • そのままRSSシンジケーションになる
  • ESI欠点
    • cache invalidationが簡単ではない。(これはESIに限らずどこでも同じ話？)
    • オープンソース製品がまだ早熟
    • 実装コストが高くつく

Advanced RESTful Rails

  • RESTによる実装は教科書的なアプリケーションだと簡単だけど、複雑になってくると中々考えちゃうよね。
  • その際に考慮するべき事項の解説。
  • 資料

Fast, Sexy, and Svelte: Our Kind of Rails Testing

Integration Testing with RSpec's Story Runner

  • RSpecのStoryRunner使い方
  • それよりも、Feature, Story, Scenarioの書き方お手本が役に立ちそう
  • 資料

2008/6/1

The Worst Rails Code You've Ever Seen (And How Not to Write It Yourself)

  • いわゆる「汚い」コードの数々と、そうならない・そうさせないためのTips集
  • 悪い例
    • Integration of concerns...一つのメソッドでなんでもやっつける
    • Premature deoptimization...半端な非最適化（笑
    • Application-wide actions...どのリクエストでも必ず実行されるメソッド...
    • 巨大コントローラ...1130行の実例を見せてもらった！
  • SmallTalkを知っているベテランを探し出せ。そして、その人と若手とでペアプロさせるのだ。
    • 日本だと無理っぽい。

Advanced Mongrel: Handlers and Plugins

Oh the Fail I've Known

  • すんません。つまらなかったので熟睡しちゃいました。

Advanced Active Record Techniques: Best Practice Refactoring

  • 題名は「Advanced」となっていたが、その場で「Simple」に「リファクタリング」された
  • callback (before_hogehogeなど)を活用する事で、コードがコンパクトになり可読性が向上する
  • business logicはできるだけmodelに
  • その際、DRY原則をとにかくつらぬく
  • named_scopeを使うとmodel実装の可読性があがる

その他

各発表の資料へのリンクは適宜追加していく予定。

はじめてのRuby on Rails3―「Webアプリケーション」作りに定番の「フレームワーク」を使う! (I・O BOOKS)

はじめてのRuby on Rails3―「Webアプリケーション」作りに定番の「フレームワーク」を使う! (I・O BOOKS)