Rails勉強会@東京 第7回

rails データベース

Rails勉強会@東京 第7回 に行ってきた。今回はドリコム恵比寿オフィスにて。

drecom.jpg

小雨の降る中、参加者がぞろぞろと集まってくる。残りの人を待っている間、話題になるのは 昨日のはぶにっき のこと。はぶさんから提示された「RailsのやりかたはDOAへの退化ではないか」という疑問と、いくつかの質問。そしてそれへのid:takahashimこと高橋会長のコメント。これは懇親会の話題にも続いた。

ドリコムのオフィスはビリヤード台が設置された素敵な感じ。

drecom-office1.jpg

drecom-office2.jpg

前半セッション

4つのセッションに分かれた。

  • DHHの講演の録音を聴く
  • 「ARを詳しく」をあとで読む
  • Railsのパフォーマンス問題の英語のテキストを読む
  • AWDwRの付録Aを読む。

私は「Railsのパフォーマンス問題」に出た。ネタにしたのは A Look at Common Performance Problems in Rails 。よしみさんがこの記事を持ってきて紹介してくれて、みんなで読んでみた。

内容としては細かなノウハウの塊という印象。

特に、link_toの代わりに、リンク先URLをERbでベタ書きしようというのはまさにバッドノウハウ。みんなそろって反対した。確かに、link_toはRoutingを参照するから遅いんだけど、それよりは先にページごとのキャッシングでなんとかするよなーと。

関連を地道に辿るよりは findで:includeしようというのはくまくまの人も言っている話でごもっとも。で、一緒に出ている:joinの場合を簡単にする方法は くまくまの人が書いてる 。

リクエストURLをRouteにマッチさせるのも意外ににコストが掛かるので「よく使うRouteを上に書こう」と。デフォルトではwsdlへのrouteがトップに来ているけれど、これはconflictしなければ後ろに移したほうがよい。その場で聞いた話では、実はconfig/routes.rbの設定をを1行追加すると、100ミリ秒/リクエストぐらい食うことがあるらしい。

あとは、セッションはPStore遅いし、memcachedでしょとか。

全体としてはRailsのソースを読んでるようなマニア向けの文書ではなくて、Railsが何もかもを何とかしてくれると思っている初心者向けに、「何とかしてくれない部分」をつぼを押さえて書いてあるという印象。とりあえず、一度読んでみるとよいんではないでしょうか。でも全部を間に受ける必要はないです。

他のセッション

  • DHHの講演の録音を聴く

    日本Rubyカンファレンス2006での講演の録音をみんなで聞いたらしい。内容は 安藤さんのやつ が詳しい。CRUD重要。

  • 「ARを詳しく」をあとで読む

    同じく日本Rubyカンファレンス2006でのくまくまの人の「 ActiveRecordを詳しく 」のプレゼン資料が公開されているので、それを読んだ。

  • AWDwRの付録Aを読む

    Rails初心者向けに、RailsのためのRubyを学んだ。Marshalあたりまで読んだらしい。

後半セッション

後半セッションのお題決めはもめた。最初、「 はぶさんの記事 への返答を考える」にコアなひとたちが集中して他のセッションが成立しないかもしれなかったので。実際、いくら謙遜してみてもはぶさんはDB設計に関してはすごい人なわけで、DBまわりに関するその指摘はとても強烈でそこから掘り下げていくら考えても考えたりないということはない。人が集まるのも仕方がないのだけれど、でもこのネタは「懇親会でもできるよね」ということで封印された。

rails-tokyo07-session.jpg

結局、こんなセッションが開かれた。

私は「ARモデリング入門」に出た。ソーシャルブックマークサービス(SBS)を題材にすることにして、まずはみんなで話し合いながらSBSをモデリングしていった。

id:moroさんとか私とか、よくしゃべりる人たちがはぶさんのABD(Activity Based Datamodel)の信奉者だったせいで、どうしてもリソース系/イベント系とか、ABDの流儀に染まったモデリングになりがちだった。 ヤドカリの人 の観察によれば、「『テーブル設計がきちんとできないとRailsは使いこなせない』ことが証明されたのも同じ」と映ったようだ。

全体に、今はRailsでも交差エンティティをしっかりとモデル化する流れになっている。AWDwR 2nd ed.でもHABTM(has_and_belongs_to_many)の説明は割愛されて、Railsの開発方針としてHABTMの代わりにhas_many :through => ...の使用が推奨されている。関連テーブルからさらに関連が派生するのは気持ち悪いという意見はありつつも、このセッションでも交差エンティティをしっかりとモデル化する方向で話が進んだ。

仕様はdel.icio.usやはてなブックマークとあまり変わらない。

  • ユーザーは複数のページをブックマークする
  • 同一のページは複数のユーザーからブックマークされ得る
  • 1人のユーザーは1つのページを1回しかブックマークできない
  • ユーザーには複数の「お気に入りのユーザー」がいる
  • ブックマークは複数のタグを振られる
  • 同一のタグは複数のブックマークに共有されえる

まずはホワイトボードにER図を描いてっと。で、それを実際にActiveRecordで書いてみた。コーディングは井上さんがやってくれて、みんなでプロジェクタ経由でそれを眺めた。

  • User

    • has_many :pages, :through => :bookmarks
    • has_many :favorite_users, :through => :favorites, :table_name => :users, :foreign_key => favorite_user_id

  • Favorites

    • belongs_to :user
    • belongs_to :favorite_users, :table_name => :users

  • Page

  • Bookmark

    • belongs_to :user
    • belongs_to :page
    • has_many :tags, :through => :tagging

  • Tag

    • has_many :bookmarks, :through => :tagging

  • Tagging

    • belongs_to :bookmark
    • belongs_to :tag

ともすればABDに落ち着きそうになってしまうのを必死に避けようとしたので、微妙にはぶさんの推奨するやり方とは違う感じになってると思う。もっとABDしてたほうが私は好きだ。

ここでひとつ問題。上では、usersテーブルがfavoritesテーブルを通じてmany to manyな自己参照を持っている。has_manyのリファレンスには:throughを指定したときは:foreign_keyは無視されると書いてあって、自己参照する場合のhas_many :throughの指定の仕方がわからない。結局、:sourceあたりを使えばよさそうではあったのだけれど、その場では誰もはっきりとはわからなかった。その後、勉強会のメーリングリストにて 解答 が紹介された。

他のセッション

懇親会

はぶさんの話。Haskellの話。いつもの話。みんなで携帯ではぶにっきを見ていろいろ考えてみた。やどかりの人曰くその姿は「おたくっぽい」。id:moroさん曰く、「だっておたくだし」

「Javaにblockとオープンクラスとオブジェクトとしてのクラス（クラスメソッドの多態)と気楽な実行時メソッド定義とmethod_missingと継続とDuck typingと括弧なしのメソッド呼び出しがあればRubyじゃなくてJavaでもいいよね」という話をしていたら「それ何ていうC# 3.0？」と言われた。確かに、C# 3.0はかなり願望を満たしてくれるんだよね。

肝心の高橋会長が、はぶさんからの返答があったことをまだ知らなかったらしいので、二次会では高橋会長を囲んで本格的にはぶさんへの返事を考えた。

総論としては、DHHも講演で交差エンティティを強調してCRUD重要と言ってるし、基本的な方向性は合致してるんでないかなということ。DHHの講演の意味を本当に知りたかったらはぶさんの『 楽々ERDレッスン 』を読めと言いたいぐらい。

じゃあ、双方の考えはどこで違ってるのかというと、その点は id:moroさんがまとめてる 。これを読めばわかりやすいと思う。

id:moroさんは「で、そうするとさらにお客さまの『作りなおしたい』『大幅に変えたい』要求に」と書いているけれども、そうすると多分DB設計自体も変わってくる場合があると思う。あるいは、私の身の回りみたいに、1ヶ月ぐらいで対象業界の構造自体が変化していく場合、DBの構造の変化は避けられないと思う。ちょっと前までの私だったらそんな状況に立ちすくむばかりだったと思うけれど、今は「そこでABDですよ」と言う。はぶさん自身がABDをどう捉えてるかは知らない。でも私は Seasar ConferenceでABDを聞いたとき 、DBの構造自体がみるみる変化していくような状況において、変化に強いDBを作る方法だと受け取った。

そういうところで、Railsだけだったら現実の要求に応えられなくても、ABDとRailsを組み合わせれば強いと、やっぱり私は思う。あとはABDを支援するhas_one :throughみたいな機能をRailsに追加できれば面白い。RailsにおけるABDの実践は次回の勉強会でネタにする。

あ、Seasar Conferenceで貰いそこなったから、今度はぶさんに会えたらそのときこそERD本にサインしてもらわねば。