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コネクションプールについて
名前付けについて、ハンガリアン記法とかどうですか？
ヘルパーやプライベートをテストするには？
あきらかなネタが混じってますが(笑) いつか聞いてみよう。
