The Rails 3 Way - Review

Author: Obie Fernandez & Friends

You may ask yourself why you need this GIGANTIC book especially having already purchased The Rails Way. I’m here to tell you to shell out the clams and pick this up! There you go, that is my review. Oh, did that not convince you? OK… let me go into a little bit more detail.

First off let it be known that I started out this read with a review copy from my favorite user group ChicagoRuby. I enjoy getting the book knowledge at the insanely small cost of a book review. Really go check out your local user groups for similar deals! Anyway, I mention that because after enjoying the book so much I went and purchased a kindle edition so I could have it along with me all the time (the code written in this edition is very easy to read).

Not enough yet? OK. Have you read Obie’s first attempt in The Rails Way? Me too. I thought it was informative but just seemed like the Ruby on Rails API in printed form. I feel in this new edition there is a great deal not only rewritten for all the changes in Rails 3 but appears to have more editorial content as well. That’s what I ended up really loving about this book. Yes Obie and friends go through new and old API but also add in scenarios on how and when you’d use them. A bunch are stuff that a seasoned developer would already know but many caught me off guard as things I would have never thought of.

So not only do you get a huge amount of information but it is a somewhat easy read. A book this size is obviously more of a reference material to be used now and later but I found it to be a really easy read. I actually read it straight through to see what really changed about the first edition. Now I don’t recommend that for everyone, it is really made to jump around from chapter to chapter when needed.

With all of that being said… I want to let you know that this is a highly opinionated writing. We should expect that from Obie and the overall Rails community. What I didn’t expect was that the book is even opinionated on the tools that are discussed. Right out of the gate Obie explains that he will not be going over Test/Unit and ERB as they are inferior to RSpec and Haml.

So in closing I want to reiterate that I highly suggest you get this book. Software moves fast especially the Rails API but I feel this book has many core API and development concepts that will be usefully for a while to come. Go pick it up now and tell ‘em Matt sent ya.

Testing Scopes in Rails3

A while back there seemed to be this secret programming war going on… how do we test named_scopes?

It came down to the type of tester that you were. You could build out the ActiveRecord objects you needed and assert that when the scope was called, the correct objects were returned. Or you could call the scope and assert that the #proxy_options (conditions) you expected to be passed were there. The latter, to me, seemed to be the better option. You would have faster tests because there was no database calls due to the creation of objects and you would only be testing your implementation of the scope… not ActiveRecord.

Well here we are now with Rails3 and all of those #proxy_options calls are busted. There is no #proxy_options method defined on the ActiveRecord::Relation class, which is what all scopes are now. What is a guy to do?

I have found a another option that I don’t really like but will explain. You can now call #to_sql on your finder to get the SQL that would be executed. So with that being said you could assert, with a regular expression, what the query should be firing with. To me this option seems a bit messy but to each his own.

This next option I found while perusing the ActiveRecord source and no one seems to be talking about! ActiveRecord::Relation does have #where_values_hash. This method, like #proxy_options, returns a hash of conditions that would be passed to the query.

So it would be simple assert like this:

describe ".released" do
  it "returns records where #released == true" do
    Presentation.released.where_values_hash.should == {:released => true}
  end
end

Hooray! No database call necessary, we are testing our implementation of the scope, and we are not testing ActiveRecord implementation. I think this is a great find, let me know if you see any flaws or where it could be improved!

Besides not liking the syntax, yet another reason to not use #update_attribute.

It doesn’t run validations. This is news to me… anyone else?