Ruby会議2009 #1 (2009/07/17)

まとめと感想

  • 初日で平日にも関わらず,結構な入り具合
  • Rails 3 は劇的ビフォア・アフター
    • ただ構造はよくなる予感
  • 大場さん@万葉社長のプレゼンの前半にのろけがあった模様?
  • Github が小数で運用されているらしいのが,凄いことだと言うことと同時に,やればできるんだなぁと思いました.

開会の言葉

  • 高橋さんによる開会の言葉
  • 4回目
  • 3日間
  • 3セッション同時並行
  • スポンサーのご紹介
  • 中継をどこかでやるらしい
    • 中会議場,特別会議室などには電源がある

Using Git and GitHub to Develope One Millon Times Faster

What is git
  • Snapshot, not patch
  • branche is pointer to a commit.
  • merging -> create a new commit which parent is default and experimental
  • 3 hot way(?)
  • Save individual time
    • No network needed
    • frictionless context switching <- branching
      • non-linear development
        • create new branches, switching between branches and development
      • branching as a patch queue
        • ブランチを作ることでパッチを作成できる.キューっぽく
        • fork queue on github. queue!
        • git rebase/format-path/am
  • git rebase -> make patches
    • commit 間の patch をスタックして,rebase 先の commit に適用する感じ
  • git rebase --onto master server
    • branch of branch の時に,親の親に rebase できないのを,onto で指定する感じ
  • squash
    • commit message を1つにまとめる
  • Save team time
    • integration manager をおいて管理する
    • dictator/l...
Github
  • Grit
  • Jekyll
  • 4人の会社
  • なぜ github を作ったのか
    • git の hosting は面倒だから
  • git の Windows client は?
    • Git Extensions
    • TortaiseGit
    • EGit for Eclipse
  • git submodule をもっと有効に使うにはどうすればいいか?
    • 「subtree merging 40 lines of Rake」をググれ
    • progit.org で1章丸ごと submodule について書いている
  • いつ merge いつ rebase
    • 自分で作業している場合は rebase ,外から来たのは merge

Pragmatic Patterns of Ruby on Rails

  • 大場寧子さん@万葉
  • Akasaka.rb
  • 飴,とギャルゲーがあるらしい
  • iCarta
Personal Message
conding patterns with RoR
  • 実装パターン
  • ターゲット
    • large and complicated
    • team building
  • Problems of large applications
    • coding style
    • coding quality
  • メンテしにくくなる
  • いいコードを書く必要がある
    • いい設計,読みやすい,わかりやすい,間違いにすぐ気づく
  • そこでパターン
    • 共通パターンを作る
    • 控えめに DSL を使う
  • このプレゼンで触れないこと
    • パフォーマンスの追求
  • ActiveRecord
    • OOP で書ける
    • 複雑さに耐えられる
    • pragmatic
    • RoR の中核
    • AR 中心の話に
    • 基本的に RESTful な事例
  • 実例紹介#1
    • 権限のあるデータを表示(show permitted data)
    • パターン#1
      • 普通に検索する
        • find_by_id_and_user_id
        • written_by(user_id).find(:id)
          • named_scope
        • これらは条件を忘れても気づきにくい
      • オブジェクト起点で検索
        • current_user.notes.find(:id)
          • 文脈でわかる
      • Filter で書く
        • controller の filter で書く
          • @group = ... を before_filter で処理しておく
          • conding style に自然な強制力が働く
          • ちゃんと名前をつけることで,わかりやすくできる
  • 実例紹介#2
    • 複雑なビジネスロジック
    • ビジネスロジックはモデルに書きたい
      • テスト,再利用しやすい
      • コードが分散せずに,読みやすい
    • 集め方が問題
      • MVC を壊すのはダメ
      • controller から model へ method の移し方を紹介
    • パラメータによる分岐ロジック
      • controller に処理を書きがち
    • 制御条件をモデルの属性に
      • params の構造も変える
      • あとは
        • 付随する他モデルへの処理の委譲
          • モデルの callback に移す
      • 自律的なモデルができる
実装パターンの見いだし方
  • Rails において自然であるように考える
    • OOP
      • 「誰が」「何を」すべきかを考える
      • テーブル(database tables)で決めない
    • 原則に従う
      • DRY
      • CoC
      • RESTful
        • Rails では RESTful から逃げない方がいい
        • リソース1つに1つのコントローラー
        • URL 設計から考えるとよろしい感じ
  • Rails プログラマにとって標準的な coding style になる
    • 誰でも読める
  • Enterprise とは
    • 10人ぐらい
  • モデルが肥大化するのでは?
    • module に切り分けていたりしている
  • RESTful で batch や非同期処理は?
    • 複数リソースへの PUT として考えている

エンタープライズRails」に学ぶ企業ユーザのためのRailsアーキテクチャ

前振り
  • 「人材は人月で買ってこれるから重要じゃない」@高井
  • 企業システムにとって一番重要なのは「データ」
  • DOA(Data Oriented Approach)
    • プロセスよりもデータの方が安定的
      • 業務フローは変更されるが,データは変更されない
    • データに対する要求として体系化できる
    • データモデルによって業務ルールを分析できる
  • RailsDOA に類似している
    • RDBMS 前提
    • モデルを中心にした Framework
    • CRUD 分析を重視する
  • 相違点もある
    • データモデルを重視していない
    • 業務ルールはアプリケーション層のみで実装
    • 背景にはリソース指向がある
  • DOA - Rails = 「エンタープライズ Rails
データベースの制約を活用する
  • データ保護はアプリケーション層のみでは不十分
    • アプリケーションやフレームワークは変化する
    • アプリケーションにはバグがある
    • DBは複数のアプリケーションから利用される
  • データベース層でもRDBMSレベルで保護すべき
    • NOT NULL制約 / CHECK制約
      • データベースのユニットテスト
        • validation を skip して SQL Error が raise するかどうかを検証する
    • 参照制約
      • 外部キー制約
複合主キーを導入する
  • has_many だと無駄な JOIN が発生してしまう
  • 望ましいのは,Employees に company_id を入れた感じ
    • ただしこれだとアプリケーションレベルでの制約しかなくなる
    • そこで Departments に複合主キーを作る
      • Employees にかならず Companies/Departments の組み合わせのキーが入るので,存在しない Companies/Departments の組み合わせを取得することができない
  • Rails 側で導入するには
    • # gem install composite_primary_key
  • 中間テーブルを複合主キー化する
    • 子テーブルに親の親の主キーと親の主キーへの外部参照を設定する
ビューでシンプルにする
  • 複数のテーブルからの,複雑な検索条件を問い合わせたい
  • ビューを作って,モデルも作れば参照できる
    • view-backed model と言うらしい
    • ビューはサブクエリみたいに使える
Q&A
  • migration では制約はどう書く?
    • execute で書く
    • エンタープライジーな人は migration なんて使わない
  • ビューは使えるのか?
    • view-backed model は使える
      • パフォーマンスの問題はある
    • 使いどころを見極める
  • composite_primary_key は最新の Rails で使えるの?
    • forum 見ようね
  • AR の代替は書いてる?AR は好き?
    • 代替は書いてない
    • AR は好きというか,流されてる?
  • memcached とかどう?
    • materialized view の涙ぐましい努力を見ようね
      • (キャッシュのレベルが違う?)
  • 複合主キーの良い例は書いてる?
    • 複雑な例が書いてある
  • Web の人に呼んで欲しい
    • 原書 PDF で読もうかな

より良きruby市民のために Rails 3

Summary
  • 劇的な変更があるが,これにあわせてシステムを書き換えるのはかなり大変そう
    • まあ一部の機能しか使わなければ,特に問題にはならないのかも知れないが
Q&A
  • Plugin はどうかわる?
    • API を定義するからこれで最後の変更になる
    • こっからがんばってくれ

Lightning Talks

  • あとで写真アップ予定
  • KeyValue Store な話が複数あったのは,時代の流れだろうか.
  • レガシー = P** な話が一番おもしろかった

懇親会

  • キーサインパーティー
    • 人生初のキーサイン.まだ署名してかぎ送ってないけど....
  • プチ jpmobile 会議
    • @darashi さんと初対面.Rails 2.3.2 対応はマージしちゃいましょう!と言う話になりました.
      • 来れなかった方ごめんなさい><
  • matz とかいろんなひとのサイン
    • 人数でしたか.@ngtyk さんが一位だったらしい