Refactoring

Posted on May 05, 2007

When I first started out developing, I was concern with getting things done and working as quickly as possible. I didn’t really understand the benefits of refactoring. Later on in my development career, I understood why refactoring was important, but I still couldn’t find any time to refactor – unless it was physically added to a project schedule, which wasn’t too often.

What I have finally come to understand, is that I just needed to find time to refactor. The time I spend on refactoring now, will probably save me a lot more time in the future tracking down bugs in a bloated code base. So today, when I ran into an issue because of a bloated code base I decided to refactor the code. Sure I spent all day cleaning up the code, but I feel more confident in the code base and I was able to add much more rpecs.

So, how often do you refactor? and when do you find time to refactor?

RailsConf Portland

Posted on April 25, 2007

The team at PLANET ARGON is excited that RailsConf 2007 in Portland is fast approaching. We are looking forward to meeting other ruby on rails developers. We are hoping we can help out our peers and find cool things to do in Portland during the conference. We have started a Portland Revealed Series. Okay, there’s only one post, but we hope to add a few more (busy times at PLANET ARGON).

We would also like to get recommendation from you on what types of things you would like to know about Portland.

fieldWithErrors

Posted on March 25, 2007

I came across a way to overwrite the default fieldWithErrors div that gets created when an input field has an error. Someone else might have already discussed this or has a better way. But I thought I would share what I came up with.

The code that creates the fieldWithErrors div around an input field with errors associated with it is defined in active_record_helper.rb file and it looks like:

  module ActionView
    class Base
      @@field_error_proc = 
              Proc.new{ |html_tag, instance| "<div class=\"fieldWithErrors\">#{html_tag}</div>" }
      cattr_accessor :field_error_proc
    end
    ...
  end

In my config/environment.rb file, I overwrite the behaviour like so:

  ActionView::Base.field_error_proc = 
           Proc.new{ |html_tag, instance| "<span class=\"field_with_errors\">#{html_tag}</span>" }

Rspec'ing Model Associations

Posted on February 27, 2007

How do you go about spec’ing model associations?

There’s an idea on the rspec mailing list.

However, I kind of like using reflect_on_association. Let’s say we have the following model:

class Product < ActiveRecord::Base

  has_and_belongs_to_many :categories
  has_many :images
  has_many :inventories
  belongs_to :designer

end

Then my context and specifications might look like:

context "Product model" do

  specify "should respond to inventories" do
    Product.reflect_on_association(:inventories).should_not_be_nil
  end

  specify "should respond to categories" do
    Product.reflect_on_association(:categories).should_not_be_nil
  end

  specify "should respond to images" do
    Product.reflect_on_association(:images).should_not_be_nil
  end

  specify "should respond to designer" do
    Product.reflect_on_association(:designer).should_not_be_nil
  end
end

This will catch the situation where an association definition is removed or changed.

Rspec'ing Rails Controllers

Posted on February 26, 2007

I’ve been using rspec for a few months now, and I really like it. I recommend trying it out if you haven’t.

I figure it might be nice to share how I organize controller specs, and get some feedback on how others might organize their specs. I like having one test per specification like so:

specify "should redirect to new session url" do
   response.should_redirect_to new_session_url
end

I also like calling the controller action in the setup method.

setup do
   ... any necessary setup info
   post :update, :id => model, :model => params
end

Here’s what a context might look like in all its glory.

context "Create with a valid product and authenticated user" do
  include ProductsControllerSpecHelper
  controller_name :products

  setup do
    @product = mock(:product, :null_object => true)
    Product.stub!(:new).and_return(@product)
    @product.should_receive(:save!).and_return(true)
    @product.should_receive(:categories).and_return([])
    authenticate_user_mock

    post :create, :product => valid_product_attributes

  end

  specify "should redirect to edit" do
    response.should_redirect_to edit_product_url(@product)
  end

  specify "should assign product" do
    assigns[:product].should_not_be_nil
  end

end

Look At My Gems!

Posted on February 12, 2007
In regards to several posts, by Robby and Chad and many others, here's my list:
actionmailer (1.3.1, 1.2.5, 1.2.3, 1.2.1)
actionpack (1.13.1, 1.12.5, 1.12.3, 1.12.1)
actionwebservice (1.2.1, 1.1.6, 1.1.4, 1.1.2)
activerecord (1.15.1, 1.14.4, 1.14.3, 1.14.2)
activesupport (1.4.0, 1.3.1)
ajax_scaffold_generator (3.0.3)
builder (2.0.0)
capistrano (1.3.1, 1.1.0)
daemons (1.0.3)
deprec (1.2.1)
diff-lcs (1.1.2)
fastercsv (1.0.0)
fcgi (0.8.6.1)
gem_plugin (0.2.1)
hoe (1.1.7)
money (1.7.1)
mongrel (0.3.13.4)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.0.10, 1.0.9)
payment (1.0.1)
piston (1.2.1)
postgres-pr (0.4.0)
rails (1.2.1, 1.1.6, 1.1.4, 1.1.2)
rake (0.7.1)
RedCloth (3.0.4)
rmagick (1.14.1)
rspec (0.7.5)
rubyforge (0.4.0)
rubygems-update (0.9.2)
shipping (1.3.0)
sources (0.0.1)
termios (0.9.4)
tzinfo (0.3.3, 0.3.0)
ZenTest (3.4.3)
Not that I use them all.