RubyKaigi2009 初日メモ

rubykaigi2009

思い返せば DHH が招待講演していた 2006 年の Ruby会議から今年で 4回目。何気に自分が全部参加していたことにびっくりしました。 (^^;


今年のテーマは「変える/変わる」。そして裏テーマは「COBOL」?。

一際国際色豊かなのも今年の特徴ですね。世界地図に出身を付箋紙で貼ってくのは面白いアイデアでした。


受付済ませて給電所でぼーっとしてたら角谷さんに会って、会場前の通路を RubyConf 風にしてみたと言ってました。たしかに連絡ボードとかドリンクサービス、給電所なんかがあるのは似てたかも。


全体的な内容や雰囲気についてはすでに gihyo.jp さんとかで公開されてる (GJ!) ので、以下は自分用のメモ。

git

  • 発表者の Scott Chacon さんが本を書いたらしい
    • CC ライセンスでもうすぐ公開 (素晴らしい)
    • http://progit.org/
  • git rebase --onto
    • branchのbranchã‚’masterに当てたいが、途中のserverブランチの部分がいらない
    • git rebase serverだけやると、だめ
    • --ontoを使うと、serverからみたclientブランチのコミットをとって、masterに当てる
  • squash
    • squashすれば、複数コミットが一つになる
    • pickして、squashしたら、新しいコミットメッセージを付ける
    • 注意：ローカルのコミットでやれ。pushしたものに対してやるな
  • Fork QUeue
    • 他のforkでのコミットをかんたんにみえる
    • 緑は問題なしとりこめるもの、赤の場合は衝突がある
  • rebase と merge の使い分け
    • ローカルだけで管理のとき or 外から取り込むときくらいで使い分け

現場で役立つ RoR パターン

  • 設計 / 実装の一体化で自分も実装できる、という意味でエンタープライズでも RoR を活用
    • マネージメントやオフショアなど、実装できない流れは嫌
  • 課題
    • 書き方がばらばら
    • 品質が揃っていないので、メンテナンスしにくくなる
  • コードをよい状態に保つには？
    • 共通パターン
    • DSL (控え目に利用、やりすぎは新規参入者の障壁)
  • 権限のあるデータの表示
    • find_by_user_id ã‚„ named scope でがんばるのは条件を書き忘れても気づきにくい
    • 関連を使って、オブジェクトからはじめる検索がいい
 @note = current_user.notes.find(params[:id]
    • データの権利者パターン
  • Filter の利用
    • 重複している処理を Filter に切り出す
    • ある程度強制力が働く..のかな？
  • 複雑なビジネスロジックのモデルへの集め方
    • Model のなかに do_create、do_destroy メソッドを切ったひとがいる (びっくり!)
    • コントローラに書きがちな処理をモデルにもっていく
    • モデルで attr_accessor で DB に関係ない属性を追加
    • パラメータ構造をかえる # form_for を使うとか
    • これでパラメータを受けとったタイミングでモデルにはいるのでコントローラで分岐処理を書く必要がなくなる
  • 付随する他モデルへの処理の移動
    • あるモデルを触るついでに別モデルもさわる場合もコントローラにかかれがち
    • モデルのコールバック (save ã‚„ destroy などの前後に呼び出される処理) に移しましょう
  • 話せなかったこと
    • 多レベルの検証 (範囲を決めて検証とか) # これ聞きたいな
    • STI の原則
    • 関連オブジェクトに属性情報を伝える
    • routes.rb の整理
  • 実装パターンの見いだし方
    • 誰のすべき仕事なのかにこだわる
    • 原則に従う (DRY、CoC、RESTful)
    • コントローラの設計は、URL 設計から (対象リソース1種類につき 1コントローラ)
    • 複数リソースの CRUD がひとつのコントローラにはいっているのはまずい
  • しつもん
    • Q. 想定している開発者数
    • A. 10人以上、4-5ヶ月の開発期間
    • Q. 気づくとモデルが1000行とか...そういった場合は？ by 食べろぐの京和さん
    • A. 機能別にモジュールに切り出す、1ファイルの内容をしぼる
    • Q. モジュールが増えて、名前空間にこまったりしない？
    • A. モデルにそった名前をつけるとか
  • あとで大場さんに聞いたら、まずいコードの検知はペアプロだそうな

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

  • あなたの会社でいちばん大切な資産って何ですか？
    • 人材？
    • エンタープライズなひとにとっては「要員」、それほど重要じゃないw
    • それはデータです。
  • データ中心アプローチ
    • プロセスよりもデータのほうが安定的
    • 要求をデータに対するものとして体系化できる
    • データモデルによって業務ルールを分析できる
  • Rails と DOA の類似点
    • RDBMS を前提にしたアーキテクチャ
    • モデル中心のフレームワーム
    • モデルに対する CRUD 分析を重視する
  • Rails と DOA の相違点
  • DOA と Rails のギャップを埋めるのが「エンタープライズ Rails」
    • 作者は MySQL が大嫌いらしい
    • 使えない SQL、制約が多いとのこと
  • ここまで前フリ
  • データを保護するためには、アプリ層だけじゃなく、DB層の制約を使う
    • NOT NULL 制約
    • チェック制約 # 4文字以上とか (こんなのあったのね)
    • データベースのユニットテスト
      • save_with_validation(false) とかすると、modell の validation をはずしてDBのチェックを確認できる
    • 外部キー
  • データベースでちゃんとチェックするためには複合主キーのほうが都合がよい
    • Rails での複合主キーへの対応、composit_primary_key
 set_primary_keys
 has_many :foreign_keys => [...]
  • データベースビューの利用
    • View-backed モデル
    • migration では、execute を使う

Rails3

  • 疎結合化
    • ActiveRecord、ActiveController、ActiveView がけっこう密に結合
    • Rails3 ではそのあたりが綺麗に掃除
    • Rails内部も ActiveSupport の必要なところだけを require、ちゃんと依存関係を尊重
    • Rails本体のデフォはたぶんallã‚’requireするけど(便利だから)、オフにするオプションはある
    • ただし、これからはrequire順が重要になる
    • それを楽にするのに、ActiveSuppor::Concern を追加した
    • includedというメソッドでモジュールがすでにロードされているかを簡単に確認できる
    • depends_on で依存関係を明確にすることもできる？
  • Rails は Ruby Citizen になる

Lightning Talks

懇親会

  • iPhone 人口多し、Bamp いいなー