Using metrics like flog can be immensely helpful for cleaning up code. However, metrics are fallible, and flog is no exception.

During a session of some serious code refactoring, flog was returning high scores on a couple of methods that appeared to be relatively clean, and the main culprit for the scores was something called to_proc_normal.

Consider this example. We have a Test class and Fruit class. Within the Test class are the following methods:

  def fruit_names_1
    fruits.map(&:name)
  end 

  def fruit_names_2
    fruits.map do |fruit|
      fruit.name
    end
  end

Both methods return an array containing the names of fruits associated to the Test class. They are, functionally, extremely similar. So how do they match up in flog?

While I was DRYing up some code, I noticed that a lot of my Sunspot searches were using the same options over and over. Default scope is a nice option in ActiveRecord queries, why not in our searches?

class Item
  # simple default scope to add an order_by to all queries
  def self.default_search_scope(&additional)
    search = Sunspot.new_search(Item)
    search.build(&additional)
    search.build do
      order_by :created_at, :desc
    end
    search.execute
    search.results
  end

  # pardon the contrived example
  def self.with_keywords(user, query)
    default_search_scope do
      keywords query
    end
  end
end

This way you can specify your search options in the Sunspot DSL from each method, while moving repetitive options to a single location. Clean, readable, and effective.

Great props to Mr Mat for his help

My last two posts have both had the word “dodeca-thalon” in the first paragraph. Dodecathalon means a series of 12 things. Those 12 things are the 12 Agile Principles. So far I’ve covered the first two. If you haven’t read them, please do. And then, read this one, #3.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

As I mentioned with the last principle, we welcome change. We count on change happening, and we use it, Judo-style, to our advantage. But, part of the success to navigating change is feedback. You need quick feedback. And, when you’re developing software, feedback comes from delivery.

Corey and I have been using Cucumber to write our integration tests on our current project and I thought I’d share a tip with you that has made our lives so much easier. When making steps in Cucumber, try to make them reusable. The idea behind Cucmber’s integration tests is that you are creating a language to talk about (and test) your project. By creating a dictionary of reusable steps we cut down the amount of time it takes to write new features, and decrease the size of the testing language which makes it easier to wrap your head around it. Here is a sample step definition that could be used to check for various http response codes