graeme nelson

Again, its been a long time since my last post. A post about not posting. Its been very difficult to find time to write blog posts when you spend most of your time creating new apps. I love creating apps. Most of the applications were for other people, but I did manage to squeeze out an app for myself and friends. It’s called tastymate. Its a place to find and share tasty spots with your friends.

In the process of building tastymate and the other applications, I was able to play with the following:

• sphinx – I am really impressed with this search engine.
• beanstalkd – Its nice to defer some background process until later, so your rails process doesn’t slow down
• god – so far its done a really good at keeping all my processes up and running.
• geokit – A nice little geo location package that works well with ActiveRecord models.
• jQuery – A very nice javascript library.

I have several nice topics to write about in the future. I hope to get on them soon.

On an unrelated rails note, I took a look at jaxer and I am impressed. It will be interesting to see what traction this project gets. Have I told you that I am loving javascript :)

Cheers, graeme

A talk I really enjoyed at Rails Conf 2007 was Clean Code by Robert Martin. An important idea from that talk was “Always check in your code a little bit cleaner than when you checked it out”. I never looked at refactoring as being that simple, but it is. Prior to this talk, I looked at refactoring as this big undertaking. I mean the whole application can use some improvement, right? I also tended to take on big refactoring endeavors by deleting the current code and starting over. Robert Martin urges against this, since you might break the current application with the rework code, and that’s much worse than ugly code. At least the ugly code is working. Tackling the smaller refactors, by improving the code a little bit at a time, the refactoring process becomes manageable.

If you are attending RailsConf (or Portland in general) and you love BEER, be sure to check out PLANET ARGON Portland Revealed article.

I am looking forward to meeting others in the Rails Community, please hit me up if you are interested in meeting up. I am sure I will be at several of the after conference get togethers.

In the coming weeks, PLANET ARGON will be introducing a new hosting service called Boxcar. Be sure to sign up on the email list or watch the official PLANET ARGON Blog for more updates.

So, what is Boxcar? [from the official PLANET ARGON blog]:

”...a new hosting service, which aims to provide you with even more privacy, more guaranteed resources, and better options for scaling your Rails application as your business grows.”

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?

Recently, I’ve vowed to remove most of the model.find methods from my controller. I am not talking about simple find statements like:

 model.find(1) 
 model.find_by_title("my title") 

I am talking about find methods like so:

  model.find(:all, :conditions => ["status = ?", my_status])
  model.find(:all, :conditions => ["title = ?", my_title])

I would add methods on the model called, find_all_by_status(status) and find_all_by_title(title). Now, you may be thinking that these are simple find statements too. And I would agree with you. But in my opinion it makes the controller code look dirty. What would you rather see in your controller?

  model.find(:all, :conditions => ["status = ?", my_status])

~OR~

  model.find_all_by_status(my_status)

Which one can you comprehend faster? For me, the first statement takes some time for my brain to process, where as the second statement doesn’t not. Ok, if this isn’t enough to convince you. What if you introduce a new boolean attribute on your model called ‘active’ and the logic is to only show active model instances? Now you have to change all the places where you have:

  model.find(:all, :conditions => ["status = ?", my_status])

 ~TO~

  model.find(:all, :conditions => ["status = ? and active = ?", my_status, true])

You say you were thinking ahead and have a private method on your controller to handle this call, so you only have to make the change in one place. I would say congratulations, but I would point out that I think the controller knows too much about the model and thus breaks encapsulation.

I would like to hear what other think, and how they handle this situation.

I feel the area where I need to improve most is in cleaning up my views. I feel like I’ve done a good job cleaning up my controllers and models, thanks to posts like Skinny Controller, Fat Model.

I have known about the content_for in rails views. Which basically allows you to have a layout like so:

<html>
    <head>
    </head>

    <body>
        <div id="wrapper">
            <div id="header">
                <% yield :header %>
            </div>

            <div id="content">
                <%= yield %>
            </div>

            <div id="sidebar">
                <% yield :sidebar %>
            </div>

            <div id="footer">
                <% yield :footer %>
            </div>
        </div>
    </body>
</html>

And in your view the following:

  <% content_for :header do %>
       This would appear for the yield :header call
  <% end %>

  <% content_for :sidebar do %>
      This is the sidebar content
   <% end %>

  <% content_for :footer do %>
     This is the footer content
  <% end %>

   <%# the rest would just be the content for the plain yield call %>
    This is would be my main content

This is nice, but I wanted to find a way to supply default content and this is what I came up with.

  def yield_with_default(yield_on, content=nil, &block)
    yield_content = eval "@content_for_#{yield_on} || ''" 
    if block_given?(&block)
      concat(yield_content.empty? ? capture(&block) : yield_content, block.binding)
    else
      Binding.of_caller do |binding|
        concat(yield_content.empty? ? content : yield_content, binding)
      end
    end
  end

I placed this in my application_helper.rb file. And now I can add something like this to my view.

    # with a block
    <% yield_with_default :header do %>
        This is my DEFAULT header content
    <% end %>

   # without a block
   <% yield_with_default :header, "This would be my default content" %>

This feels pretty clean to me. But if anybody has any other suggestions I would love to hear them.

I am also looking for more information on best practices with views in Rails. There doesn’t seem to be much information on the subject.

UPDATED: 04/01/2007 – forgot the do in the content_for statements

When I firsted started writing Rails Apps, coming from the Java world, I forgot all my good OOP training. Within Rails, I viewed the model as this magically class that gave me all this power and I was afraid to add any of my own behaviour to the model. Which went against my previous way of doing things, which was to place as much of the business functionality within the model.

Well, I am glad Jamis came along and wrote this post.

I am back on track. I don’t know how many times I wrote something like this in a controller:

   def update
       @user = User.find(params[:id])
       @subscription_plan = SubscriptionPlan.find(params[:plan_id])
       @subscription_plan.update_attribute(:status, 'active')

       # deactivate previous plans
       @user.subscription_plans.each {|plan| plan.update_attribute(:status, 'disabled') if plan.status == 'active'}
       @user.subscription_plans << @subscription_plan
   end

This is just ugly. And goes against a lot of OOP best practices. The controller knows too much about the internals of the User and Subscription Plan models. Also, if I wanted to test this controller action using mocks and stubs, I would have to write a bunch of code. What if I fixed the controller code to be like so:

   def update
     @user = User.find(params[:id])
     @subscription_plan = SubscriptionPlan.find(params[:plan_id])
     @user.upgrade_to_subscription_plan(@subscription_plan)
   end

This is much cleaner and easier to mock/stub. Also, if I decided to change the behavior of how a user upgrades their plan, the upgrade_to_subscription_plan method isolates any changes from the controller action – as long as the method signature doesn’t change.

So, go ahead a love your models.