Thursday, February 03, 2011
■rspec でふつうにテストを書く方法しりたい
先日の railsdevcon 以後、ちゃんとテスト書くようにしはじめたものの、何をお手本にしたらいいものかわからず、手探りでテスト書いてるので、ふつうのテストの書きかたを知りたい。
だんだんテストコードじゃないのが増えてくる
テストのヘルパー的メソッドが増えてきたら、/spec/support に別のモジュールでわけるようにしてるけど、こういう使いかたでいいのかなー？
module HogeModelTestHelper FIXTURES = [:hoges] def self.included(closure) closure.extend Helper closure.send :include, Helper closure.send(:fixtures, *FIXTURES) if closure.respond_to?(:fixtures) end module Helper # なんかいろいろ書く end end
spec のほうで呼んでつかう。
describe Hoge do include HogeModelTestHelper context 'ほげふがなとき' do subject { create_hoge } it { should be_valid } # とかなんとか end end
実際にテストしてるのじゃないコードは、わけちゃってる。
携帯からのアクセスとかをテストする方法がわからない
スタブをつかうべきなのかもしれないと思いつつも、jpmobile がいろいろいいかんじにいろいろやってるので、スタブだとちょっと大変かも、と思ってるところ。仕方ないので、インチキしてる。
class ActionController::TestRequest def set_env(key, value) @env[key] = value end end
とか書いて /spec/support においておいて、コントローラのテストでインチキをする。携帯の UID をつかった機能のテストとかで使う。
@request.set_env('HTTP_X_DCMGUID', uid)
あと、UA を偽装した風のリクエストをなげたりするときは、以下のようなインチキをしたりしてる。
module MobileAccessTestHelper private [:get, :put, :post, :delete].each do |http_method| define_method("#{http_method}_by_mobile") do |*args| set_mobile_ua send http_method, *args end end def set_mobile_ua(ua = "DoCoMo/2.0 SH902i(c100;TB;W24H12)") @request.user_agent = ua end end
ナイステスト情報しりたい。
Thursday, December 09, 2010
■[vim]プラグイン整理した
あたらしい mac という機会なので、vim プラグイン整理した。
- .vim/bundle
- pathogen 導入した
- ku.vim から unite.vim
- skk.vim を https://github.com/tyru/skk.vim/ のほうに変更
- そろそろ補完系の何かを導入したい気がする
あと homebrew つかってみてる。あと macbook air はケチらず 128GB のモデルにしたほうがいい。64GB すぐ容量カツカツなりそう。
Saturday, November 20, 2010
■ railsdevcon2010
http://railsdevcon.jp/ いってきた。
感想
- おもしろかった！
- 非常に参考になりました(真面目)
- インターネットでは、Rails ってけっこう使われてるのかなーという雰囲気は感じるけど、実際どうなんだろうか、と思ってた。今日行って、実際けっこう使われてる雰囲気を感じて何故かびびった。
- テスト駆動とかわりと普通にやってる、みたいな雰囲気が会場にあって、びびった(テストあんま書けてないですお)
- 自分のまわりではドリコムの onk さんのセッションナイス！みたいな感じだった(内容すごく濃かった)
- rails のカンファレンスとか勉強会含め行くのはじめてだったしテンションあがった
- お金はらってでもいきたいと思った
- オラクルさん太っ腹
- 運営のみなさんおつかれさまでした
以下メモ
ほぼスライドかきうつしてる状態なので、あんま意味ないこれ。
渡米して感じたこと (@masuidrive)
- 渡米の理由→英語ができないから
- 2006 railsconf 行って1週間ほどいたら言ってることわかるようになってきた
- むこうでくらしたら英語できるようになるんじゃね？
- ワイズノット民事再生
- Big Canvas
- seattle.rb
- いろいろあった
- 2年半居たけどしゃべれるようにならなかった
- 身振り手振り、ホワイドボードのスキル伸びる
- 仕様の交渉 (交渉技術、語学で負ける)
- アメリカの ruby/rails 事情
- ruby == rails
- $100k - $175k (spec, cuke, nosql, git, 3+年以上の ruby 経験…)
- スタートアップで ruby
- 英語できてないから、またいけるならいきたい
- 住環境いいし、車社会だけどいい
- 働く環境自由(フレックス、リモート、犬ok... 交渉次第)
- 家で夕食後に働いてるひとおおい(家で)
- いつクビになるかわからない、でも就職先は沢山ある(らしい)
- 一度海外でると日本に縛られない(日本じゃなくてもいいじゃんおもう)
- rails 世界で通用する
- Appcelerator(Titanium Mobile)
- rails 検定の問題つくってる
rails 情報源の歩きかた (@knsmr)
- @IT 編集部
- 英語だと情報いっぱいある
- 公式サイト、screencast公式ブログ、edgeRails、公式レポジトリ
- プラグイン、ウォッチ数200くらいこえてるといいかんじ
- プラグインナイスなのは？ → Asakusa.rb, rubygems.orb, ruby tools ...
- railscasts (asciicasts)
- Gregg の動画ナイス(クオリティたかい)
- RailsTutorial.org (html, pdf, 動画)
- rails wiki
- Confreaks (カンファレンス情報)
- カンファレンス参加するのがいい
- yehuda katz → jquery やりたいらしい
- StackOverflow よくぐぐるとでてくる(けっこうピンポイント)
- rails hub (12/22)
とあるソーシャルアプリの開発運用 (@onk)
課題
- API 利用
- 人口爆発
- 負荷
- アクセス数
- 巨大SNSだからスモールスタートさせてくれない
- 週10万ユーザ、月で30万ユーザとか
- データ量
- 1 click で1レコード増えるアクション(あしあととか)
- db なんとかする
- 更新系(マスタ)、参照(slave)
- マゾヒズムの gem 利用(マスタ/スレーブという関係…)
- クエリキャッシュの罠とかある(マスタ更新したのにスレーブでデータ古いとか)
- db縦分割
- リレーションで使えない(使わない)
- 横分割
- sharding octopus(3対応してる)
- MongoDB で解決？
- 負荷テスト
- 50万ユーザが3ヶ月遊んだ装丁
- faker でテストデータ
- スループット、ディスクIO、コネクション(表、DB)
- 最速レスポンス
- API, 非同期…など
- 5秒以内
- 非同期処理 resque, delayed_job
- resque
- 管理画面よい、アプリでバッチできる
- bulk insert
- 手抜きしたところはたいていボトルネックになる
- count → カウンタキャッシュ, like やらないなど
- 正しく web アプリをつくる
- エンジニアの甘えゆるさない
- アクセス数
- 負荷
- 短納期
- ドキュメントへらすように
- まよわないように(rails っぽいか？ rails らしく)
- 超高速 PDCA サイクル
- P, C をはやくようにする
- Plan
- いつでもかんがえてる
- Check
- はやいお
- Plan
- いつでもログ見られるように
- scribe
- scribe サーバ間でいいかんじに
- 転送量、データ pack して送るなどしてく予定？
Railsプロジェクトを成功させるために現場ができること (@ukstudio)
- タイトルの成功 → なに → お客さんが満足
- 要望とそれをコードなどで実現するぶぶん をどれだけはやく、高品質にできるか
- 技術的負債はいつか返さないといけない
- バグ対くりかえすプロジェクトは負債の利子返すだけでいっぱいいっぱい(自転車操業)
- 開発をいそいでしまう原因(仕様かわる、納期はやまる、あとなんか1つ)
- 技術的負債をなくす!
- テスト書こう
- テストないと変更時こまる → 負債
- テスト駆動(設計含む意味)
- モジュール間の依存をなるべくへらす
- リファクタリングしよう
- 返せる負債はすぐ返す
- 後ではかえせない(後になったら他のタスクにおわれてる)
- 未解決の負債の解決に週の20%(とかいくらか)をあてるなどするって決める
- バージョン管理
- git でブランチきってリファクタリング
- テストの資産価値
- 上位のテストで動作を保証
- 下位のテストの変更を自由に
- cuke とかで要求仕様にそってればユニットテストすてられる
- テストコード、どやってのこしてくか
- 書いてるひとの想定外のテストは書けない(設計能力に依存)
- レビュー、設計の勉強とかはやはり必要
- スキニーコントローラ、ファットモデル
- モデルに寄せないとテスト書きにくいだろjk
- rails 、モデルにひきずられやすい感
- クラスの責務を考える
- rails らしく → rails の機能をうまくつかえてるか
- rails らしさを共有してればメンバ間での無駄へる(チームでのコーディング規約みたいな)
- rails guides 読むべき
- 負債とスケジュール、トレードオフ
- 営業、機能ふやしがちで使われない機能できたりして負債(パッケージとかだととくに)
- お客の要求をちゃんと理解してないと使わない機能できたりして負債が
現実の世界で "はじめる！Cucumber" (@moro)
- Cucumber について
- ドキュメント(お客読める)をテストとして実行できる ナイス
- 現実
- 日本語の情報 → あります
- 達人出版の cuke 本
- 今のプロジェクトに適用する作戦が思いつかない
- 簡単なところから少しずつ
- GET / (トップページからやってみる、テストの練習としても)
- そこからリンクたどってみる
- POST してみる
- 今やってるタスクのテスト書いてみる(関心あることのほうが書ける)
- 簡単なところから少しずつ
- 日本語のシナリオの使いみち
- よみましょう(よみやすい日本語だし)
- 実行できなくてもよみやすい振舞(読んだひとがイメージできる)を書く(だいじ)
- 対話のきっかけに(イメージしりたいお客、タスク見積たいメンバ、実装の手掛かりわかりたい自分)
- そとからテスト書いて実装してテストパスしてくのが正しい一歩？
- それっぽい cuke, spec, 実装, テストパス…みたいなとこからはじめる
- 最終的になにしたいのか、という振舞書けば、何すればいいのか、自分の理解の助けになる(だいじ)
- 日本語の情報 → あります
- うごくようにするには
- 最低限のエラーとって、表記揺れ正して、ステップ定義追加して、ちょこちょこ実装、テストの修正
- cucumber のリズム
- プロダクトオーナーと会話、やることおおまかにきめる
- cuke かきながらふるまい考える(かきながらかんがえる)
- rspec かく
- 実装する
- cuke とおす
- テストのバリエーションふやしたり、つめたり
- お客に見せるか？ → 見せる
Rails Add-onsで楽々開発 - youRoomを題材に - (@mat_aki)
- skip のひと(SonicGarden アジャイルなところ)
- rails addons → サービスやプラグイン
- youroom
- youroom つかってるものなど紹介
- cuke
- グリーンならリリースできる
- 低コストな品質保証
- 肝心なところは徹底的して書く(ユーザ登録みたいなの)、バリデーションひっかかる系とかも
- ajax つかってる部分のテストがむずかしい
- OmniAuth
- SearchLogic
- plugin
- 検索機能をシンプル・DRY に
- activerecord 拡張してるので rails バージョンアップで不具合おこりうる(おきた)
- google docs (gdata api)
- アプリケーション以外のデータ(ユーザ数のスナップショット)
- アプリケーションにはアプリケーションのデータだけ
- github
- 有料なプライベートリポジトリのフォークは無料でプライベートに(ウラワザ)
- amazon
- ec2
- → heroku は？
- "rails アプリケーションの" ホスティング
- ec2/s3 とかのほうが運用ノウハウあったし、メール送信とか、delayed_job でコストかかるらしいので
- hoptoad
- アプリケーションエラー通知/管理サービス
- web app のエラーだけじゃなくて、cron や delayed_job のエラーも収集するように工夫した
- batch logger, notifier 的なかんじかなー？
- pivotal tracker
- アジャイル開発向け its
- うえから順に優先度
- yourooom
- グループの情報共有、どこからでもアクセスできてスッピードアップ
- API もあるので、ここで一括して情報をあつかえる
- ドッグフードを食う的ないみもあるのかなー？
- cuke
- プラグイン、サービスを利用して、低コスト、高速、高品質な開発
初めてがRuby (パネルディカッション)
- 紹介など
- 教育関係
- http://www.rubyworld-conf.org/ja/archives/2009/program/abstract/a-2/
- liverevolution (amatsuda さん, yuumi3 による教育)
- grooves R&D (amatsuda さんによる教育。ペアプロとかアジャイルためしたりとか、ラボの時間あったりとか、読書会あったりとか)
- 未経験から教育(うらやましい)。
- 松田さん → 新人だったひとたちに質問
- 研修とか
- liverevolution:
- 新人から内定者に教育
- たのしい Ruby
- grooves:
- OJT(これやってみようかからはじまるスタイル)
- github (プライベート)で管理、リポジトリで先輩とかからツッコミ
- liverevolution:
- たいへんだったこと
- ruby の勉強がアプリケーションでの利用へのイメージがつかない (ruby の先)
- rails3(ベータ)で開発してたので、フレームワークのバグなのか、自分のバグなのか
- SQL, HTML, プログラムやらなんやら、最初からいろいろ、何やってるのかわからなくなる
- ひとりでいろいろできるようになるので良い
- できるひとに rails の文化をつくってもらうことで、ひっぱってもらう
- 1系のメンテ、機能追加、それはそれで大変 → カオス…
- ブレイクスルー
- デバッグのコツつかんだとき
- モデルのコード見てオブジェクト指向つかんだ
- クエリメソッドでオブジェクトに問いかけてるの見てオブジェクト指向より理解できた、いいコード書けるようになった
- OJT で学ぶことがある(こういうことかー、みたいな)
- はじめてが ruby 、どうだったか(まとめ)
- 初学者(はじめてが ruby)にとってフレンドリー(よみやすい)
- ruby やってるひと、いいひとでよかったです (matz ナイス → ruby ナイス → 使ってるひとナイス！)
- いろいろ書いてみてたのしい、リファクタリングたのしい期
- irb ですぐためせる(速攻フィードバック)、たのしめる
- rails イイナー、直感的に書いて、やりたいことすぐできる(うらでなにしてるかわからない時点でも。いずれとっかかりになる)、rails たのしい
- 質問
- さいしょから知っときたかったことは？ → ドキュメント先に読め(ぐぐる前に、一時情報を最初に)
- 研修とか