Railsエンジニアの越川です。
よく、テストでRails.cacheを使ったテストをしたいけれども、テストの度に念のため消しておきたいという事情でspec/rails_helper.rbに
config.before(:each) do
Rails.cache.clear
end
このように書いていたりします。
このRails.cache.clearですが、cacheをdefaultのFileStoreにしていると、tmp/cacheの中身を消すようです。
この時、sassなどを使っているプロジェクトの場合、tmp/cache/assets/配下も一緒に消されてしまいます。これに気づかないとfeature specを実行するたびにsassのコンパイルが走ってしまい何故かfeature specがべらぼうに遅い！という自体が起きてしまいます。本格的にsassを使っているほど顕著です。
エンジニアの越川です。ActiveRecordを拡張するgemを作りたい。そんなときテストで使うダミーのモデルのテーブルをどう作るかに悩みますね。
本格的なRails拡張ではrails pluginコマンドを用いて開発することが多いと思います。その際は自動で作成されるspec/dummy配下のダミーアプリでmigrationを書くのが楽です。
一方そこまで大きくないActiveRecordの拡張ではもっと手軽に書きたいですね。
例として、protectedカラムがtrueのとき、destroyが出来ないようにするActiveRecordの拡張を考えてみましょう。(今回作成したgemは、github.com/ppworks/kienaideに置いてあります。)
11月4日に入社しましたエンジニアの越川です。
本日は、私がコードを書く際に気をつけていることを書こうと思ったのですが、どう書くかに迷った末、ブログ記事駆動ハッカソンを行うことでそのプロセスで考えいたことなどを記事にすることにしました。
私はコードを書く際におもてなしの心が大事だと思っています。おもてなしの心は最終的なアウトプットに触れるユーザーはもちろんのこと、チームメンバー、未来の自身へ向けた思いやりです。
今回題材とするのは、KPTツールです。KPTは、日々の活動を振り返り「Keep」すべきこと「Problem」であること「Try」したいことを上げて、活動を振り返るために使われます。
先日行われた「オレたちが目指す”最強のエンジニアドリブン”」を終えた後に振り返りでKPT使ったので、それをWebアプリにしてみます。
今回のコードはすべて、ppworks/furikaeri/tree/v1.0.2に置いてあります。