Spike: Analyzing Rails Development Logs

As venerable as 'tail -f log/development.log' is to a Rails developer (and as undeniably useful as well), I've been using another tool that has been tremendously helpful in weeding through all the noise. Spike, written by Matt Mower with help from the Rails community, parses your development log and presents, in two windows, summary information and a detailed view.

Spike lets me see the flow of the application by filtering out records that aren't pertinent to what I'm looking for. For example, the 5 second refresh event coming in from EVERY browser -- ZAP and they're gone! I can filter by request, IP, session ID and so on. The detail viewer shows me all the parameters, the renders and all the activity in the log that is part of the request.

This has been a very helpful tool; my thanks to Matt and everyone who worked on Spike!

Lesson that I keep learning

While writing specs I keep learning this lesson over and over. After calling methods on your data model and saving it to the database, call the reload method to refresh your model. Otherwise, subsequent operations will be performed on stale data.

Do this in your engines and other business logic components that change & persist data. When calling myObject.do_something, which changes and saves internal state and you need to continue using myObject in the rest of your method, first call myObject.reload.

There. I've gotten it off my chest and I feel better.

VICTORY: FactoryGirl and Database Rollbacks that Failed

Draw near my children and listen to a terrible tale of trial, tribulation, twisting torment, teething, temper-tantrums, truculence, and truancy. Except the teething part. And there may have been truffles.

Seriously, I was ready to walk away from FactoryGirl. Perhaps you have heard of FactoryGirl, yes? Perhaps you have encountered records left in the database after the test completes. Perhaps you Google for all sorts of phrases like "FactoryGirl records left database" or "FactoryGirl rollback". Perhaps you scoured Google groups, the rdocs and all of that stuff. Yah, me too.

Yes, "use_transactional_fixtures" was true and "use_instantiated_fixtures" was false. I searched the entire code base. So did you.

But, I'm using rspec, so there is no test_helper. Spec_helper has slightly different syntax from test_helper, so "self.use_transactional_fixtures" won't work. You're using FactoryGirl, so you don't have any fixtures. I deleted mine; get that cruft out of the way. Heck, I deleted my entire test directory!

But I finally got it. And it seems so easy now. Like childs play, just like in Spock's Brain, when McCoy had to re-attach Spock's brain. And, hopefully this will help you too.

Make sure you have a fixtures directory. Mine is in RAILS_ROOT/spec, so I added the following line to my spec_helper.rb:

config.fixture_path = RAILS_ROOT + '/spec/fixtures/'

Then I told Spec::Runner that I had fixtures, even though the directory is empty! There is a fixture entry for every table that was not getting reset. For example, the users table was not getting reset, so I set:

config.global_fixtures = :users

And, when I needed the players table cleared, I added the following:

config.global_fixtures = :users, :players

That's it! All better. Rspec now clears up those tables just as purty as you please and the tests are passing -- big bars o' green! Yippee!

Good Ruby on Rails Tools

I'm looking at the following tools to add to my Ruby on Rails tool chain:

Continuous Integration

RunCodeRun at runcoderun.com
CruiseControl by Thoughtworks

Scalability

I'm excited by the products talked about at the NewRelic scalability blog. I saw the first episode and am very psyched about bullet by Richard Huang.

Metrics & Monitoring

Can't wait to try out Caliper for Ruby metrics and NewRelic for monitoring

I'm using SVN on a few projects, but I have been in the promised land and can't wait to get back to git, so let's add GitHub to the list.