これから始める"Ruby on Rails"2013年秋版

http://atnd.org/events/44191 のスライドです

Transcript

1. + これから始める"Ruby on Rails”2013年秋版
 株式会社じげん 津村 泰史
2. + 自己紹介 n  始めは組み込み屋。 7、8年ほど色々やっていました n  下位層はbootloader、linux driverからファーム等 n  組み込みに飽きたので、ソーシャルゲーム業界に n  アプリ開発から解析システム開発等 n  現在は株式会社じげんで主にサイト作成を担当。 n  最近は、テストにも力を入れています。 n  Twitter @prioniae
3. + アジェンダ n  最近の開発環境 n  テスト周り n  便利な機能/gem
4. + テーマ n  Rails4のリリースから時間も経過しました n  勉強会、Blogを始めとして色々情報は出ています n  しかし、実際の開発環境、現場はどうなのか? n  ということで、普通のエンジニア向けの、普通の現場の状況で す n  テストが多め
5. + 最近の開発環境
6. + Ruby + Rails n  rbenv n  Ruby : 1.8、1.9、2.0 n  Rails : 2,3,4 n  サービス毎によって、Ruby + Railsのバージョンが色々 n  アップデートが課題 n  ビジネスロジックが多く、場合によっては作り直しの方が早 かったり
7. + RailsとDjangoの比較 n  前職ではDjangoを触っていましたので比較 Rails Django 環境(人、物…) ◎ △ 開発速度 ◎ ◯ バージョン問題 △ ◯
8. + MySQL n  サービスによって複数のバージョンを使用 n  5.1、5.5、5.6 n  複数バージョンのインストールをどうするか? n  MySQL::Sandboxで複数インストール n  ただし、gemのmysql、mysql2のインストールは少し難しい n  コンパイルが必要なのでパスを通す必要が有り
9. + テスト周り n  ユニットテストを始めとするテストコードの必要性は一般的に なっています n  実際の所はどうか? n  テストコードを書いているエンジニア、組織はまだまだ少ない 印象 n  社内ではDevOpsの影響もあり、テストコードを書くことが進 み始めている。が、まだまだこれからです
10. + テストを書き始めるおすすめの手順 n  時間の合間に書けるもの徐々にテストを始め、テストに慣れる n  import周辺、helperなどのmodel/DBが関わらない部分 n  Requestテスト(後述) n  model周辺（validationなど） n  統合テスト n  ユーザー登録 n  Post
11. + Rspec n  Railsのテストフレームワークのデファクトスタンダード n  Controller, Model/DB, Helperを中心に「本来あるべき挙動」 を記述していく この「あるべき挙動」のことを「Spec（ス ペック）」と呼び、rubyで書いていく n  expect( <調べたいもの> ).to eq(期待する値)
12. + Rspec再入門
13. + Rspec再入門
14. + Rspec再入門
15. + Request spec n  RoutingをトレースしたControllerのテスト n  つまり、特定のURLにアクセスして、エラーチェックを行う n  テストが行き届いておらず、リリース後にバグでアクセスエ ラーという自体を防ぐ n  これがあるだけで安心感が全然違います
16. + Request spec
17. + View側のテスト n  Rspecだけでは出来る事が限られている n  ボタンの動作 n  ページ遷移 n  Javascript、… n  結局、人間が手動でテストをせざるを得ず、時間の無駄が多い → 自動化をしたい n  回答 : Rspec + Capybara + Poltergeist
18. + Capybara n  受け入れテスト、統合テスト用のフレーム n  イメージとしては、Webアクセスの自動化 + テスト n  Rspecと組み合わせることで、spec内でDOM(フォーム要素な ど)のテストが行える。
19. + 例えばこんなフォームの場合 ↓
20. + Capybaraのテスト
21. + Poltergeist (phantomjs)とは n  Phantomjsはseleniumの軽量版 n  Poltergeistはphantomjsのruby用ドライバです。 Capybaraの pluginとして動作します。 n  機能 n  ブラウザテスト n  スクリーンキャプチャ n  Bot n  Networkモニタリング
22. + インストール n  phantomjs n  Macはbrew、portsでインストール n  最近のLinuxだと本家からダウンロード n  少し古いLinuxだとソースからコンパイルが必要 n  Poltergeist n  gemでインストール n  Ruby 1.9移行
23. + こんな動きをテスト出来る
24. + Rspec+Capybara+Poltergeist
25. + そしてCIへ n  テストコードができれば、CIの準備完了 n  Jenkinsで自動テスト n  gitでpush時に自動的にテストを実行 結果はメールで送信 n  DevOps、テストコード作成の影響もあり徐々に導入を進めて います n  まだ、始めたばかりなので、利用しているプロジェクトは2,3 程度
26. + 便利な機能/gem
27. + Railsの高速化 n  Spring n  Railsは各種コマンドの起動が遅い n  Railsの実行ファイルを予めキャッシュし、デーモンとして別 プロセスで生かしておく n  spork、zeus、commands n  注意 n  Ruby 1.9.3,Rails3.2以降が対象 n  gitでのブランチ移動の場合は再起動が必要
28. + Rubocop n  Rubocop : 静的コードチェッカ n  Ruby 1.9以上 n  インストールはgemで n  コーディングルールのチェックツール n  設定ファイルでルールを変更することが可能! n  言語を問わず昔からあるツールの類 n  Jenkinsを利用することにより、コーディングルールの形骸化 を防ぐ
29. + このようなコードをチェック
30. + 結果は…
31. + TDD n  CIは通常git + Jenkinsで行われるが、 TDDはコーディングとセットで行うもの n  gem : guard、watchrが便利 　Ruby製ですが、他言語でも使用できます n  ファイルの変更をトリガーにテストを実行 n  Growlを使用することにより、テスト結果を分かりやすく表示
32. + TDD + Growl
33. + Growlの問題点 n  現在は有料なのが難点かも n  ただし、古いバージョンのソースコードが公開されている n  ダウンロードしてコンパイルすれば使える n  ただし、コンパイルエラーが出て修正が必要かも n  Webで情報が少しはあるのでなんとかなる! n  Linuxだとgrowl4linuxで代替できるようです
34. + TDDの感想 n  TDDは今までのプログラミングのリズムから大きな変化がある ため最初は大変 n  TDDを始めた場合、始めは開発時間が1.5〜2倍は覚悟が必要 n  しかし、テストと同時に開発を行うので信頼性はUP n  慣れるまでは、すごく疲れます 残業する元気はなくなります
35. + 今回紹介したツール n  gem n  Spring n  Guard / Watchr n  Rubocop n  Rspec、Capybara、Poltergeist n  phantomjs n  Growl n  購入 / コンパイル n  Linux growl4linux / Notify-OSD
36. + 今後の課題 n  テスト導入による効果を数値化 n  別プロジェクトへの展開 n  テストコードの量を増やす
37. + 有り難うございました!