RubyKaigi2009 参加レポート[1日目]

ruby イベント rubykaigi2009

去年に続き参加させて頂きました。
RubyKaigi2009!!!
今回のテーマは「変化」という事で、私も去年と違ってレポートをブログで書くなどしてみる


今回の場所は、学術総合センター!
そういえば、学生の頃、NII の先生と共同研究だったので、よく行ってたのですが、
社会人になって初めて行ってきたぜぃ!

Using Git and GitHub to Develop One Million Times Faster

発表者: Scott Chacon さん

git とは?みたいなお話し
  • tree , parent, author commiter の4つの情報から、コミット情報は保持している
  • git branch でブランチを見て
  • git checkout でブランチを切りかえる
    • 3つのmerge (よく使われる??)
git の良いところ
  • git は早い
  • ネットワークいらない
  • 簡単にブランチを切って、いろいろ試せる
    • ブランチはバッチキューである
  • Merqurial extentions
    • コマンド多すぎw
git rebase
  • git diff A B > A-B.patch
    • その差分をパッチとして、キープして、rebase でマスターに戻す
開発ではこんな使い方もしてるよ
  • 1つのsprintチーム毎にブランチを作って、sprint が終わったらマージする
gitHubのはなし
  • オープンソースだよ
  • 簡単に共有できる
  • パッチが簡単に受けつけれる
  • パッチを簡単に送れれる
  • fork すれば自分のコピーが出来る
  • 他のforkでのコミットを簡単に見れる
最後に
  • OSSなので、無料で働いてもらえて、効率が挙がる
  • Win Win だね
質疑
  • Q: CIみたいな機能拡張はありますか??
    • A: CIに関しては、開発予定はないのですが、第三者の会社にしてもらう予定です
  • Q: 何故GitHubを作ったのか?一言で
  • Q Windowsで、Gitが使いにくいなんか良い知恵は無いか?
感想

git, github の基本的な使いかたの説明だった!
「Mercurial ユーザの人〜」って質問があったが、
手を挙げてる人が居なさすぎて、ちょっと吹きそうになった。


英語はよく分からなかったけど、スライドが見やすくて、
なんとなく分かった(と思う)
後、@lchin さんの和訳がもの凄く助かった、ありがとうございます。

Pragmatic Patterns of Ruby on Rails - 現場で役立つRuby on Railsパターン

発表者: 大葉寧子さん大場寧子さん
発表資料(Blog):slideshare

背景
  • 中学生からプログラミングをしていた
  • 見積り、マネージメント、アウトソージングをやれといわれたが、実装がしたい
  • そこで、Rubyに出会った。
Ruby on Railsでの実装パタン
  • 複雑で大きなアプリ
  • チームでの開発
    • 書きかたばらばら、品質が揃ってない。メンテナンス出来ない
    • コードを良い状態に保つのが大事
    • 良い設計、読みやすい・分かりやすい、間違いもすぐ気付く
  • そこで、実装パタンですよ
    • 共通パタンを作る
    • DSLを作る(控えめに)
  • 効率も挙がる
  • 今回その1部をご紹介
O/Rマッパー(ActiveRecord)が好き
4つの実装パタン
  1. ARオブジェクトから検索をはじめる
  2. ARオブジェクトを得るfilter
  3. パラメータによる分岐ロジックの移動
  4. 付随する他モデルへの処理の移動

紹介するよ

ARオブジェクトから検索をはじめる
× @note = Note.find_by_id_and_user_id(params[:id],  current_user.id)
× @note = Note,wrriten_by(current_user.id).find(params[:id])
○ @note = current_user.notes.find(params[:id])
ARオブジェクトを得るfilter
  • 重複した内容.filter で書く
  • アクセス権もFilter内を変えれば良いので楽
  • 良いコントローラ名、読みやすいFilter
パラメータによる分岐ロジックの移動
  • 背景 複雑なビジネスロジックの場合、ロジックはモデルに集めたい
    • テストしやすい
    • 再利用しやすい
    • コードが分散せず、読みやすい
  • だけど、集めすぎるのは駄目
    • MVC壊れる
    • 再利用性が低い
  • なので上手くコントローラからモデルへうまくコードを移してみよう
    • パラメータによる分岐ロジックの移動
  1. 制御条件をモデルの属性にする
  2. attr_accessor でモデル属性に
  3. パラメータの構造を変える
  4. ビューでフィールド名を変更
    • check_box_tag を form_for の中に フォーム名.check_box に
  5. params[:モデル名] で渡せる
    • generate_tags ロジックの移動
  6. モデルで分岐できるようになる
付随する他モデルへの移動
  • モデルのコールバックへ持って行く
    • コールバックは、save, destroy が実行される時に呼ばれる
  • brfore_save とかに入れてやる。
  • 自律的なモデルになる
その他気になっていること
  • 多レベルの検証
  • STIの原則
  • 関連オブジェクトに属性情報を伝える
  • routes.rb の整理
感想

大場さんのご講演を聞くのは初めてでしたが、
Ruby, Rails への愛がもの凄く伝わる内容でした。
それ故、汚ないコードとかは許せないんだろうなぁ。


万葉さんはよく勉強会とかもされているので、
一度、遊びに行ってみたいなと、思いました。

『エンタープライズRails』に学ぶ企業ユーザのためのRails活用の極意

発表者: 高井直人さん
発表資料(Blog): slideshare

エンタープライズRails

7/23 発売!会場で先行発売!!
DOA - Rails = エンタープライズRails


今回の内容は、
エンタープライズRails からちょっと使えるテクニックを紹介

  • データベースの制約を活用する
  • データモデルに複合主キーを導入する
  • データベースビューでシンプルにする
データベースの制約を活用する
  • NOT NULL 制約
  • Check制約
  • 外部キー制約

Railsのバリデーションだけで不正なデータを防止することはできません
データベースの制約を利用しましょう

データモデルに複合主キーを導入する
  • 親-子-子の関係で個数を取得するとき
    • has_many :though を使うと、無駄にjoin しやがってとなる
  • 複合主キーによるアプローチ
    • CREATE TABLE 時にそれぞれ2つの外部キーを主キーにする
    • Rails での複合主キー
      • gem install composite_primary_keys
      • 最新のRailsと使うとバグがある

複合主キーを導入することで、よりスマートなデータモデルが可能になる

データベースビューでシンプルにする
  • ARは複数のテーブルを結合させたり、複雑な問い合わせが苦手
    • 複雑なSQLなげやがって!
  • そこで、データベースビューの定義
    • 複雑なクエリならビューを作成しましょう
    • 作成したビューを普通にモデルを作ってやると使える
まとめ
  • データ中心アプローチは、企業ユーザに適したアプローチ
  • 複合主キーはRails が捨てたものだが、利点もあること
  • DBの機能を利用することで、単純で明確なコーディングが可能
  • エンタープライズRailsは良本
質疑
  • Q: データベース制約はmigrateの中でどうやって書くのか?
    • A: excute を使ってかく。てか、migration は使わない
感想

正直、講演を聞くまでRails道から外れると幸せになれないと思っていたのですが、
このセッションが終わったら、本を買ってしまってましたw
(いや、外れてるという記述は不適切かもしれませんが#))


とにかく、一読しておく方が良いかな? と思った一冊!
というのは、今回紹介されたテクニックについて、
あまり意識せずに普段私は開発しているからで、
まさに、DOA - Rails の部分を補ってくれているものだと思います。

From Rails to Rack: Making Rails 3 a Better Ruby Citizen

発表者: Yehuda Katz さん

感想

すいません、レポートメモも無しです。
高井さんのサイン会に行ってたため途中から参加の上、
結構早口の英語のスピーチでほとんど理解出来ず(^ ^;)


Rails2.3 だとこんな内容なのが、Rails 3だとこうなるよ
というお話しだと思う(他の方のレポートをご参照下さい)


当日、こんな発言を残してます

Lightning Talks

感想(というか特に気になった単語)


いつも思うんですが、
LＴの資料は、後でゆっくり見てみたい!!