Ruby会議2009

##まとめと感想

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

##開会の言葉

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

##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 を１つにまとめる
  • 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 で１章丸ごと submodule について書いている
  • いつ merge いつ rebase
    • 自分で作業している場合は rebase ，外から来たのは merge

##Pragmatic Patterns of Ruby on Rails

  • 大場寧子さん＠万葉
  • Akasaka.rb
  • 飴，とギャルゲーがあるらしい
  • iCarta
    • 百人一首のトレーニングソフト

###Personal Message

  • Ruby でエンタープライズもいけるんじゃない？

###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 から逃げない方がいい
      • リソース１つに１つのコントローラー
      • URL 設計から考えるとよろしい感じ

  • Rails プログラマにとって標準的な coding style になる

    • 誰でも読める

  • Enterprise とは

    • 10人ぐらい

  • モデルが肥大化するのでは？

    • module に切り分けていたりしている

  • RESTful で batch や非同期処理は？

    • 複数リソースへの PUT として考えている

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

  • 高井さん＠Akasaka.rb
    • 「私がエンタープライズRuby」「Ruby会議のエンタープライズ枠は全て私のもの」

###前振り

  • 「人材は人月で買ってこれるから重要じゃない」＠高井
  • 企業システムにとって一番重要なのは「データ」
  • DOA(Data Oriented Approach)
    • プロセスよりもデータの方が安定的
    • 業務フローは変更されるが，データは変更されない
    • データに対する要求として体系化できる
    • データモデルによって業務ルールを分析できる
  • Rails は DOA に類似している
    • 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

  • Better Ruby Citizen
  • @wycats Yefuda Katz from EngineYard
  • merb + Rails -> Rails 3
  • EngineYard
    • Solo
    • Flex
  • Rails 3
    • Rack
    • JSON
    • Erubis
    • More love
  • Rails 3 have special API
    • for DataMapper
    • for jQuery
    • for CouchRest
  • ActiveModel
    • = ActiveRecord - DatabaseAdapter
    • ex)
    • include ActiveModel::Validations
      • use valdations like ActiveRecord
  • Components
    • API
    • extend ActiveModel::Naming
      • person_path(@person) works fine in controllers
      • form_for/error_messages works fine too in views
  • Decoupled
    • ActiveRecord + ActionController + ActionView = Rails 2.3
    • three classes are mutually combined
    • Rails 3 = ActionController + ActionView + ActiveModel
  • ActionPack
    • ActionContoller::Http
      • Metal in Rails 2.3?
    • Simple
      • Kaigi.action(:index) returns ActionController::Http object.
    • Callbacks
    • include AbstractController::Callbakcs
      • uses callbacks like ActionController::Base
    • Render
    • include ActionController::Renderer
      • uses render :template => “…” like ActionController::Base
    • Layouts
    • include ActionController::Layouts
      • uses layout “…” like ActionController::Base
  • ActiveSupport
    • require ‘active_support/all’ or require ‘actiove_support/ruby/shim’ <- Ruby 1.9.1
  • Less Pollution
  • Cherry Pick
  • Manage Modules
    • ActiveSupport::Concern
    • included?
  • Isolation Testing
    • include ActiveSupport:::Testing::Isolation
    • each test processes run in different enveioments

###Summary

  • 劇的な変更があるが，これにあわせてシステムを書き換えるのはかなり大変そう
    • まあ一部の機能しか使わなければ，特に問題にはならないのかも知れないが

###Q&A

  • Plugin はどうかわる？
    • API を定義するからこれで最後の変更になる
    • こっからがんばってくれ

##Lightning Talks

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

##懇親会

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