ダラダラメモ。
Guard
herokuのバグによりgemfile.lockが読みこまれないことがある
RSpecはGuardよりも遅いしイライラする
Sporkとかを利用してRSpecの起動を速くする
zeus 神なのにゾンビ
Rails 3 でSpork + Guardで快速自動TDD - テクノロジーと広義のデザイン!
結局SSDにしたほうが早いんじゃないだろうか
spe_cuke
spe_cuke (rspecとcucumberを同じコマンドオプションで指定できるようにする)
$ gem install spe_cuke
vimでrspecかcucumberをひゅっと実行できるようにする
function! s:SetupSpeCuke() command! RunTestFile exe '!sc ' . expand('%:p') command! RunTestCase exe '!sc --line ' . line('.') . ' ' . expand('%:p') nnoremap -tf :RunTestFile<CR> nnoremap -tc :RunTestCase<CR> endfunction au BufRead,BufNewFile *_spec.rb,*.feature call s:SetupSpeCuke()
ただ、名前がダサすぎるので、scとかに改名したらいいんじゃないのか?
また、デバイス調べる時間のほうがコードを書く時間より長くなってしまっておる。
レガシーコード改善
テキストのリクエストはテキストのリクエストで返ってくる
DOMで現れる部分であれば、JSですらもcucumberでカバーできる
ただ、javascirptでcanvasで描画したやつは自動化のしようがありません。
所謂webアプリケーションのテキスト部分は自動化テスト可能である。
jenkinsが死ぬほど遅い
(15分かかる)
CIをうまく回している人っている?
C社は金で解決したらしいけど。
安いnodeを複数回かけてspecとcucumerを1台ずつ分ける
(小賢しい技術を駆使するくらいなら、普通にお金をかけてサーバーを増やしたほうがよい)
(でも企業の体力と要相談です)
specでviewのテストやってる?
コンテンツの中身にたいしてテストしているわけではなく、
htmlが壊れていないかとか、静的メッセージがきちんと表示されているかを確認する
featureに書くと重たくなるから。
controller spec
テンプレートのサーチパス
エンドポイントが分からない
controllerのspecを作ればhtmlとかjsonとかを吐きだす
そのままドキュメント化しておけばAPIドキュメントの代わりになるし、
ドキュメントを書くくらいならcontroller specをかいたほうがいい
model spec
controller specを優先する?(それはない)
どこまで書くか、というよりどこに書くかのほうが重要です
end2endをやると遅くてたまらない
modelに書くテストは開発者目線のテストであって、システムそのものを担保しているわけではない。
ロジックのテストを最初にやるべき
どこまで書くのか
プライベートメソッドのテストも書く人もいる
(ちょっとヤバそうだったら書く or プライベートも全部書く)
分割して外に出したほうが効率はよい。
active recordを継承しているクラスとそうでないものが半々くらい
クラスが多いのはよい。小さいクラス
クラスを命名するのがしんどくないか?
→ネーミングがプログラマの仕事の半分近くを占めてます
ship quality ruby code
Code Climate. Hosted static analysis for Ruby and JavaScript source code.
メソッドのネーミングとかソースコードとかを自動的に判断して、ランクづけしてくれる(無料だけど有料オプションもあり)
モジュール切り出し、機能単位でタグづけとかをやると本体のスコアが上がっていく
物理的に短くするのも重要じゃないだろうか
#398 Service Objects (pro) - RailsCasts
実践テスト駆動開発入門
日本語訳
(サンプルがガチすぎる)
原著
(サンプルコードがハードコアすぎる)
httpリクエストを作る必要がない
モデルからよせたほうがレイアウトとしては楽
紙面上でjavaのコードを読むのはキツイ。
DCI
そもそも話すの?
rubyのイベントに出たのにjavaの話するのか
そもそもDCIって何?
DCI and the application builds our mental models // Speaker Deck
MVC以外の切り口
Data
Context
Interaction
(例によって)口座管理のお話が出てきます
「預け入れと引き出しは振舞いが違うよね」って話
「客と開発者の言葉の定義を統一していこう」という話なのか?
イマイチ「コレダ!!」って話がない。
オブジェクト指向つって結局クラス作ってるだけじゃん!
DCI and the application builds our mental models | Sapporo RubyKaigi 2012 (札幌Ruby会議2012)
コントローラーを少なくするのはいいが、
モデルを肥大化さすのはよくない
若干限界が見えはじめているMVCにたいし、一石を投じるDCI
DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism