Date: 2008-07-28
Tags: event, ruby-on-rails

Webキャリアさん主催のRuby on Rails セミナーに参加

トーカーは、 Ruby on Rails 逆引きクイックリファレンス Rails 2.0対応 著者の大場寧子さん、大場光一郎さん、久保優子さん。今回は会社で一緒にRailsやってる同僚も一人連れて行ったんだけど、持ってきた名刺が2枚って‥‥。しかも1枚受付で渡しちゃうし。

資料は前述のサイトで後日公開されるらしい。

セミナー参加メモ

RoRの価値は?

  • 生産性が高い

  • RoRの感性にマッチしたエンジニアになる必要がある
    • 価値観・思想に染まる必要がある

  • スクリプト言語は作り捨てに向いている?
    • RoRは構造化に向いている、本格的なフレームワーク

  • 現状ではRoRエンジニアがキープできない
    • 現状の課題

    • これから育てていこう

RoRの開発チーム作り

  • 経験談
    • 最初はXP的にやった

    • 後半はコードが汚くなって生産性が落ちた
      • モチベーションが下がった

  • ロケットスタートできるようにトレーニングした
    • Java開発者なら3日ほどで書けるようになる

    • エキスパートが参画する

    • ビギナーに任せっぱなしにしない

    • 作りっぱなしにしない

    • Try&Errorの後はレビューして学ぶ

    • いつでもディスカッション/レビューする文化を創る

開発をどう進める?

  • 最初のミーティングで一気に
    • Wikiに箇条書きにして書いていく

    • モデル、モジュール構成を決めていく

  • 開始後は各自で開発を進めていく
    • 開発者同士でコミュニケーション

    • おおきな問題はミーティング招集

  • ドキュメントは?
    • 納品ドキュメントは納品前にやっつける

    • チームに必要なドキュメントは随時Wikiに書いていく

RailsはAgileじゃないと使えない?

  • 大規模な会社ではAgileという言葉は出しにくい
    • 1ヶ月くらいの小さなウォーターフォール

    • 保守の中で新規開発してしまう

  • ウォーターフォールだったらJavaで良いのでは?
    • Agile & Rails は画面を見せながら進められるのが良い

Rails開発を進めるときに大切なこと

  • 開発者は仕様にタッチしない
    • ・・・という雰囲気を打破することが重要

    • 大事なことは顧客を説得して仕様を変える

    • 開発者が「変だ」と思うことは意見する

  • 名前付けが重要
    • 型付けが弱いので名前付けを誤ると訳分からなくなる

    • 名前付けがよいとコードがすんなり読める

  • Rails経験者がDB設計に関わること
    • DBの構造や、テーブル設計がRails向きになってると楽

  • 既存のDBを利用するのは難しい?
    • 複合キーの代わりにプライマリキーを作る

    • カラム名をちょっと変える

    • 既存DBをまったく変えられない場合は破綻する事例もある...

  • 会議の議題を先にWikiに書いておく
    • 会議がスムーズに進む

バージョンアップの重荷

  • Railsはバージョンアップが大変
    • Railsはバージョンアップが頻繁にある

    • 自分のコードが動くかどうか確認するのが大変

    • プラグインがバージョンに追従してくれるか不明
      • 自分で面倒見る気で使おう

  • バージョンアップすると
    • 処理スピードが改善される

    • 開発者のスキルが向上する

    • 新しいプラグインを使えるようになる

  • Railsの仕組みを変えるようなコードは危険

何から始める?

  • Rails1.2のScaffoldでの生成コードを触ってみる
    • Rails2.0からのScaffoldは暗黙が多すぎて初心者には厳しい

  • 基本編
    • コントローラを作る

    • モデルを作る

    • フォームを作る

    • POSTして保存するようにしてみる

    • ここまででMVCが出来るので、ここまでを1.x系でやってみるのが良いかも

    • 初心者の内こそペアプロとか良いよね
      • 複数人が悩んでる箇所なら質問しやすい!

    • コードレビューは必須でしょう

  • 中級編以降
    • RESTful, Ajax など

開発環境は?

  • Aptanaを使っていますが(寧子)
    • 特段おすすめ、という訳でもないです

  • NetBeansを勧めています(光一郎)
    • ウィザードで簡単に色々できます

    • ドキュメント生成などもサポートされているので良い

  • MacはRakeが早い

バージョン管理?

  • CVS

  • Subversion
    • 最近の主流

  • Git
    • 今の流行

    • 2.0からのRailsでも対応している
      • pluginなど

    • GitHub
      • ソースコードSNS

      • gem の生成もやってくれる

プラグイン?

  • プラグインを主人にしない
    • 自分でメンテする気になって使おう

    • プラグインのコードは読んでおこう
      • 勉強になる

      • 何かあったときに対応できる

  • おすすめPlugin
    • acts_as_list

    • will_paginate

    • restful_authentication

    • jpmobile

    • backgrounDRb
      • 長時間かかる処理をバックグラウンドで実行

    • gettext
      • エラーメッセージやカラム名を日本語にしてくれる

      • バージョンアップには弱い

  • 時々使うプラグイン
    • active_scaffold
      • リッチなマスターメンテ機能をすぐに提供できる

      • 創意工夫を入れ込もうとするとハマる

      • Ajaxを多用してる

    • acts_as_taggable_on_steroids
      • タグ付けプラグイン

    • acts_as_state_machine
      • 状態遷移があるようなレコード
        • 処理中、処理受付中などをきれいに書ける

    • annotate_models
      • モデルの属性をrakeコマンドでコメント挿入してくれる

      • 便利

  • 開発したプラグイン
    • image_update
      • 画像を保存前にプレビュー

      • 回転もできる

    • html5jp_graphs
      • jsでグラフを表示するプラグイン

      • 日本語凡例を入れられるのがGoogle版より良い

パフォーマンスを出すには

  • Railsは率直に言って重い
    • Rubyの問題か、作りの問題かを切り分けよう

  • プロファイリング
    • 感で重い箇所を見つけるのは大抵間違っている

    • 重い箇所をしらべよう

  • チューニング
    • joinで5テーブルとか重い -> join数を減らす設計にしよう

    • 外部キーにindexを張るのも重要

  • キャッシュ
    • 重い箇所はキャッシュで。

    • Railsのキャッシュはとても柔軟
      • ログイン後用キャッシュ

      • ユーザー別キャッシュ

テスト?

  • Railsはテストの仕組みがデフォルト
    • UnitTest, FunctionalTest, IntegrationTest

  • テストのこつ(寧子)
    • 目的の結果のみをテストする
      • 途中経過をテストしない

      • 変化に強くする

    • メソッドをまとめる?
      • (よく分からなかった...)

  • RCov カバレッジツール
    • そのときのルールが、カバレッジ率100%だった

    • 意味があるのか?
      • あまり意味がないと思う(光一郎)

  • Selenium on Rails
    • ブラウザ操作をシミュレートできる自動リグレッションテスト

    • 初期から入れておくと良いと思う

    • 回すのにパワーがいると思う

  • フィクスチャ
    • ymlにid書かなくて良くなった

運用は?

  • 本番で動かなくなった、とかあるらしいけど、どうなの?
    • 本番と同じテストを使おう

    • Rubyは基本的に落ちますよ

    • 死活監視入れて、復帰するようにしよう

    • ミッションクリティカルな場所では使わないようにしようよ

  • FastCGIを使ってると高負荷で落ちやすい

  • 経験上、mongrelを使うようにしている

関連を使おう

  • コードがすっきりします

  • Lazyな作りになっているのでパフォーマンスの問題もありません

Rails2.0以降のポイント

  • RESTful

  • 組み替え (組み込み機能がplugin化)

  • フィクスチャ

  • NamedScope

  • Rakeタスク
    • 色々Rakeから操作できるようになった

  • パッケージ管理

  • マイグレーション
    • 大きく変わった

    • マイグレーションバージョン番号が日付時刻になった

  • git

RESTful

  • 美しいURLになる/しよう

  • URL設計を起点に開発を進める

  • 複雑なroutes.rbになってしまう
    • 初心者に難しい

NamedScope

  • 検索条件(Where句)個別に定義しておいて、利用時に任意の組み合わせ

    で利用することが出来る

まとめ

  • レールに乗ろう!
    • レールに乗って加速

  • 80/20ルール
    • ビジネスに必要な80%で切ってしまうとおいしいと思う

    • 20%の労力で80%をカバーするフレームワーク

  • 変更とつきあう

CTC Ruby 教育コース

  • Ruby技術者認定資格
    • 結構難しい

  • Ruby/Railsトレーニングコース

参加した感想

感想としては、アンケートにも書いたんだけど、トークが速い!どのくらい速いかというと、前述の参加メモを書き取るので精一杯なくらいは速い。LTを60分聞いた感じ?でもとても参考になったし、大場夫妻の掛け合いっぽいところも面白かった。一部あきらかにアドリブでやってる部分とかあったし。実はあのトーク全部アドリブとか。

質疑応答しようとして時間が無くて聞けなかった事

  • DBコネクションプールについて

  • 名前付けについて、ハンガリアン記法とかどうですか?

  • ヘルパーやプライベートをテストするには?

あきらかなネタが混じってますが(笑) いつか聞いてみよう。

../../_images/20080726_ror_book_sign.jpg