はじめに
前回のブログでもお伝えしたとおり、「RSpec初心者に送るRSpec最強チュートリアル ~RubyMineもあるよ!~」というWeb勉強会を放送しました。
今回はこの勉強会に関する情報を一通りまとめておきます。
過去最高の参加人数!
このWeb勉強会はソニックガーデンが主催するSonicGarden Studyの第8回の放送になります。
これまでの最高人数は「第5回・そのテストは本当に必要ですか」の135人だったのですが、今回はこれを超えてなんと192人もの人が参加登録してくれました。
USTREAM上の延べ視聴者数も300人を超えたみたいです。すごい~!
SonicGarden Studyに初めて参加する人もたくさんいたようで、この勉強会の認知度が多少上がったんじゃないかなと思います。
参加してくれたみなさん、どうもありがとうございました!
放送の前後はちょっとドタバタ・・・
本編の放送はまずまず予定通りに進んだのですが、放送の出だしと終わりでちょっとトラブルがありました。
(「画面が小さい」「用意していたエンディングBGMが鳴らない」等々)
すいません、言い訳になっちゃうんですが、子どもの体調不良等で家の中がバタバタしていて、放送の前に十分な準備時間が取れませんでした・・・。(注: この勉強会は僕の自宅から生放送してました)
で、結局「時間がない、いそげー!」みたいな感じでスタートさせちゃったので、トラブルが起きちゃったんだと思います。
視聴者のみなさん、どうも失礼いたしましたm(_ _)m
ライブコーディングは「RubyMine縛り」
この日のライブコーディングは「RubyMine縛り」という勝手な制約を作って、ターミナルや他のエディタを一切使わず、RubyMineだけでgit cloneからサンプルアプリケーションの実行、テストコードの作成、テストの実行までを一通りデモンストレーションしました。
「RubyMineって名前は聞くけど、あまり知らない」という方には参考になったんじゃないかな~と思うのですが、いかがでしたか?
本編で書いたRSpecのコードはこんな感じ
この勉強会では「Everyday Rails - RSpecによるRailsテスト入門」の第3章を題材にして、RSpecのテストコードをライブコーディングしていきました。
ただし、本と全く同じコードにするのではなく、僕なりに少しアレンジしたコードを書きました。
僕が書いたコードはこんな感じになります。
require 'spec_helper' describe Contact do describe 'validation' do before :each do @contact = Contact.new( firstname: 'Juncihi', lastname: 'Ito', email: 'ito@example.com' ) end context 'firstname, lastname, emailがある場合' do it 'is valid' do expect(@contact).to be_valid end end context 'firstnameがない場合' do before :each do @contact.firstname = nil end it 'is invalid' do expect(@contact).to have(1).error_on(:firstname) end end end end
なぜこう書いたのかは本編でお話ししたとおりです。(説明になってない)
リモートワーカーのための秘密兵器「Remotty」も登場
最近SonicGardenで使い始めた、もとい、作り始めたバーチャルオフィスwebサービス「Remotty」も放送中に使って、渋谷や岡山にいるメンバーとリアルタイムにやりとりしました。
「画面が変だよ」とか「そこタイポしてるよ」みたいなツッコミに何度か助けられました。
まあ、最後の方は「印税は?」「いくら儲けたの?」なんていう身も蓋もない質問が飛んできましたが・・・(- -;;
ちなみに、本の売り上げに関してはたぶんみなさん気になっていると思うので、そのうちブログに書こうかな~と思っております。
今はまだヒ・ミ・ツ♪
勉強会で使ったスライドや教材について
勉強会で使ったスライドはこちらです。
本編のメインだったライブコーディングの部分はスライド化できませんが、雰囲気ぐらいなら伝わるかもしれません。
また、説明で使った教材は以下の2点です。
これさえあれば、誰でも勉強会の内容が再現できます!
Q&Aコーナー
この勉強会ではTwitterでリアルタイムに質問が投げられるようになっていました。
そのQ&Aをここでも一部取り上げてみましょう。
seleniumのバージョンは何に修正すれば良いんでしたっけ?
#sg_study
— T.Ishii (@TakeBiker) March 17, 2014
selenium-webdriverのバージョンは2.39.0に上げてください。
そうしないと最新版のFirefoxでうまく動きません。
なお、2014年2月28日に公開したEveryday Railsの正式版でもこの点に言及しています。(第8章)
RSpecはitとかdescribeとかcontextとかshouldとかexpectとかあってどういう書き方がいけてるのかわからなくなってくるから困る #sg_study
— piyopiyo (@xoyip) March 17, 2014
たしかに、いろんな書き方ができますよねー。
「it/specify」「describe/context」はエイリアスの関係なのでどちらも同じものです。
これは「it "~"」「context "~"」と書いたときに自然な英語になる方を選べば良いかなと考えています。
少なくともdescribeはメソッドや機能をグルーピングするために、contextは状態や条件の違いをグルーピングするために使い分けると良いと思います。
もちろんこのあたりの説明はEveryday Railsの第3章にも書かれています。
「should/expect」については「expect」一択です。shouldは衰退していきます。
モデルのテストで、バリデーション単体をテストするのって、みなさんやられてることなんですか? なんか、validates だけをテストするのって構文エラーレベルのテストケースな気がして、あんまり意味を見出せないのですが。。ちゃんと記述すれば動くの前提ですし。。 #sg_study
— 濱田 章吾 (@hamasyou) March 17, 2014
正直に話すと、僕は必ずしもバリデーションのテストは書きません。
書く時は正規表現を使ったパターンチェックとか、ifを使った条件付きのバリデーションなど、少し複雑な分岐が発生するときです。
ただし、著者のAaronさんは「モデルにどんなバリデーションが必要か考えて、TDDで開発するようにすれば、バリデーションの設定し忘れがなくなる」と書いています。(第3章)
@xoyip #sg_study
まだよく見てないですが、そのうち見ようと思ってるのは。publify(ブログ), fat_free_crm(CRM)、spree(EC)、CrowdhosterがRspecですよ。
— 村上健太 (@kntmrkm) March 17, 2014
@xoyip 個人的にこちらのリポジトリは非常に参考になりました。https://t.co/JXy3nTZZT7
— ネコゲルゲ (@nekogeruge_987) March 17, 2014
僕はぱっといい例が思いつかなかったのですが、こうやって視聴者の間で情報交換できるのは非常にいいですね!
テストケースが増えてくると、specの数が膨大になって、ファイルが大きくなってくると思うんですが、specファイルを分割したりってするほうがいいんですか? #sg_study
— 濱田 章吾 (@hamasyou) March 17, 2014
「大きくなったから分割する」のではなく、「大きくなることでxxという問題が出てきたので、それを解決するためにxxする」と考えるようにした方がいいかな~と思います。
Gemfileでのgemのバージョン指定はだいたいするものですか? #sg_study
— sousk (@sousk333) March 17, 2014
僕は普段はあまりバージョン指定しないです。
この本はRSpecの本なので、その周辺のgemについては特にバージョンにこだわって明記したのかも。
【質問】今回はdescribeをvalidationを一つのグループとして分けていましたが、どういった単位で分けるのが一番良いのかいつも悩みます。どういった分類に分けるように気をつけていますか? #sg_study
— tochi (@aguuu) March 17, 2014
この質問に答えるのは難しいですね。いつも感覚的にやっているので、明文化しにくい感じです。
ただ、今回のライブコーディングでもやったように、テストコードを書く前にdescribeやcontextを使ってアウトラインだけを先にまとめておくと「良いグループ分け」が見えやすくなる気がします。
あとは純粋に「管理しやすくなるように分ける」ということでしょうか。
まあそこが明文化しにくいところなんですが・・・。
ちなみに第3章に書いてある「スクロールが必要なぐらいスペックが長くなったらDRYを捨てる」というのは、明確な指針の一つかな~と思います。
letの使い方少ししかわかってないんですけど、@のインスタンス変数で書いてたところがletで全部いけるってイメージですか?#sg_study
— 村上健太 (@kntmrkm) March 17, 2014
基本的にインスタンス変数(@xxx)はほぼletで置き換えられます。
ただし、完全に同じ物ではないので、たまにそのままだと動かなくなるケースもあります。
話はちょっと変わりますが、letとlet!を使い分けられるようになっておくと結構役に立ちますよ。
使われてたRubyMineのショートカット、知りたい…。調べよう…。パッとSpec実行させるとか、DRYするときになんか表示されたヤツとか。#sg_study
— Shiozaki Hidekazu (@novice_artisan) March 17, 2014
RubyMine、わからなくなったときはだいたい command+shift+A を押してます #sg_study
— Toru KAWAMURA (@tkawa) March 17, 2014
そうですね、RubyMineはそこまでがんばってショートカットを覚えなくても、Command + Shfit + Aを押して、検索窓にそれっぽいキーワードを入力するとコマンドの候補が一覧表示されるので、そこから実行することも多いです。
あとは下記ページにある「Keyboard Reference for Mac OS X (PDF)」をチートシートとして利用すると、よく使うショートカットを早く覚えられるかもしれません。
Resources - Documentation | RubyMine
feature test を書く前提だと controller の unit test をあんまり書きたくなくなる気がよくするのですが、実務でやられている方のご意見をお聞きしてみたいです。自分は今は両方書いてますが、冗長だなーと思うことが多いので..。 #sg_study
— ふくい(ま) (@msfukui) March 17, 2014
この点については本書の中で全く同じテーマでAaronの見解が書かれています。
詳しくは第5章「コントローラスペックの基礎」をご覧ください。
ちなみに僕はこの本を読んでからコントローラスペックを書く機会が増えました。
Twitter上の反応
たくさんの人が見てくれるということで嬉しい反面、プレッシャーも増えてちょっとドキドキしていましたが、Twitter上の反応を見ていると好意的な反応が多くてほっとしました。
RubyMineのショートカットっぷりが凄い!これは勉強になる。(RubyMineの使い方的に) #sg_study
— tochi (@aguuu) March 17, 2014
Remottyのリアルな運用?も見れて幸運 ( #sg_study live at http://t.co/KvCjBDyosz)
— がんじゃ (@thc_oO) March 17, 2014
【感想】言葉でしかわかっていなかった「プログラムの振舞 (behaviour)」を記述するための「ドメイン特化言語」というのが、伊藤さんのライブコーディングを聞いていてなんか『感覚的』に染みてきたっ..!!ありがとうございます。お怪我の方はもう大丈夫ですか??#sg_study
— 原 俊太郎 (@museumvendor) March 17, 2014
とても分かりやすくて良かったです。
ライブコーディングっていいですね!
教え方の勉強にもなりました。
#sg_study
— Tatsuya Ogi (@t_oginogin) March 17, 2014
さらに、さっそくブログを書いてくれた方もいるようです。
感激!!
視聴者のみなさん、まだまだ感想お待ちしていますので、お時間のあるときにブログ等で感想を書いてもらえると嬉しいです!
当日のツイートはTogetterにまとめました
当日のツイートはTogetterにまとめましたので、こちらもあわせてご覧ください!
【SonicGarden Study #08】RSpec初心者に送るRSpec最強チュートリアル ~RubyMineもあるよ!~ #sg_study - Togetter
放送を見逃した方へ
参加しようと思ってたけど完全に忘れてた しにたい / “RSpec初心者に送るRSpec最強チュートリアル ~RubyMineもあるよ!~ SonicGarden Study #08 - SonicGarden Study | D…” http://t.co/fuq69JgIm5
— yusuke mori (@jiskanulo) March 17, 2014
いやいや、死んじゃダメです!!
放送を見逃した方でも、SonicGarden Studyにメンバー登録してもらったら、動画のURLをご連絡しますので、Doorkeeperのコミュニティページから「お問い合わせ」してください。
質問も随時受け付けますので、お気軽にTwitterでメンションを飛ばしたりしてくださいね。
次回のSonicGarden Studyについて
放送でもお伝えしましたが、次回はみなさんの声を参考にしながらテーマを決めたいと思います。
候補は以下の4つです。
- node.js入門
- AngularJS入門
- AWS OpsWorks入門
- SG式Rails超入門
放送は終わっていますが、投票はまだ受付中ですので #sg_study のハッシュタグを付けて聞いてみたいテーマをツイートしてください!
僕はAngularJSがいいかな~。
まとめ
というわけで、繰り返しになりますが視聴してくれたみなさん、どうもありがとうございました!
今回説明したのはごくごく基本的な内容ばかりでした。
中級者に近づくための最強チュートリアル、「Everyday Rails - RSpecによるRailsテスト入門」をまだ買ってないという方はぜひ購入して、自分の手と頭を動かしてみてください。
この内容をマスターして、自分のRailsアプリケーションでもテストが書けるようになれば、きっと周りからも「RSpecをわかってる人」と認められるはずですので!
「Everyday Rails - RSpecによるRailsテスト入門」はPDF、Kindle、iBooks等で読めます
ご購入はこちらからどうぞ。
お知らせ その1: 2014/3/29(土)はRuby/Rails勉強会@関西 60thで発表します!
今月はもう一本RSpec関連の発表をします。
2014/3/29(土)のRuby/Rails勉強会@関西 60thです。
この勉強会では「How to upgrade your Rails application to RSpec 3 (仮) 」というタイトルで、既存のテストをRSpec 2からRSpec 3にアップデートする手順をやはりライブコーディングで説明します。
告知ページを見るとすでにキャンセル待ちが出ちゃっていますが、参加できそうな方はぜひ聞いてやってください。
お知らせ その2: 西脇.rb & 東灘.rbも毎月勉強会をやっています!
僕とAkiさん(@spring_aki)で毎月主催している西脇.rb & 東灘.rbの合同勉強会もよろしくお願いします。
神戸ぐらいなら足を運べそう、という方はぜひDoorkeeperのサイトからメンバー登録してください!
http://nishiwaki-higashinadarb.doorkeeper.jp/
ちなみに告知ページはまだ公開していませんが、次回の勉強会は2014年4月5日(土)を予定しています。