I'm a Floridian web engineer who planted his roots in Paris. Some of my favorite past-times are analyzing and optimizing development processes, building solid APIs, mentoring junior devs, and long walks on the beach.

Definition vs Function/Methods Style 10-15-2011

I was recently reading The Rails 3 way by Obie Fernandez when I came across a section of the book that was talking about how Ruby allows for a definition-style as opposed to a funtion-style. That is to say, using a function call without including the open and closing parentheses. Typically, I like using functions without parentheses because I feel that the function looks more clear.

I much prefer to see:


link_to "Some page", some_page_path

instead of:


link_to( "Some page", some_page_path )

Especially in a haml template, the first style looks nicer. However, "The Rails 3 way" mentions that one of the key benefits parenthesis-less function calls offer is macro-like feeling and should be a signifier that this call will affect other things and not act directly. Indeed when you look at the following code:


class Client < ActiveRecord::Base 
  has_many :billing_codes
  has_many :billable_weeks
  has_many :timesheets, :through => :billable_weeks
end

class Client < ActiveRecord::Base
  has_many(:billing_codes)
  has_many(:billable_weeks)
  has_many(:timesheets, :through => :billable_weeks)
end

You can see that the first one looks cleaner. It also looks more like a declaration. Indeed, the has_many function alters the object of the class that calls it giving all of it's instantiated objects a slew of other functions. This theme happens over and over again in the Rails framework. The filters that are added to controllers, such as before_filter and after_filter, will alter the functionality of actions that get called.

Ambiguity

The problem with the definition-style method is when there are nested functions which take parameters. For instance, if the function for generating the page for some_page requires parameters as well:


some_page_path( :user_id => current_user.id, :name => 'derp' ) # calls the path for some page

This will cause problems when the following call is made:


link_to "Some page", some_page_path :user_id => current_user.id, :name => 'derp'

In the link_to call, it can't be determined whether the :name parameter should be part of the params for link_to or part of the params for some_page_path.

Since consistency is always preferred, it is better to always use parentheses with function calls only leave them off only when the function is being used to alter the class in some way.

Tags: style ruby Rails

Accidental Globals in JavaScript 09-25-2011

var thing = function(){
    var a = b = 0;
};

thing();

console.log(a);  //ReferenceError, that makes sense b/c 'a' wasn't defined in global scope
console.log(b);  //0, oh noes!! Looks like our multiple equals statement from line 2 sets 'b' implicitly as a global

Names n Stuff 09-18-2011

A few days ago, where I work, there was an argument over whether the following function should exist:


def is_premium_or_has_receipt_for?(product)
  self.premium_member? || self.store.has_receipt?(product)
end

I had a hard time explaining myself as to why I thought the function should not exist. At first all I could think of was, "This seems like a bad idea." Then I ran into a similar piece of code today and it became clear to me.

The function should exist, but there is a problem with the name. It simply restates what the logic is. When writing functions one of the benefits is that it allows you to group a bunch of smaller ideas into a bigger one. In this scenario we are merely re-writing an if clause in a prettier fashion; But the lines of code together are conveying a higher level idea. What the function is actually saying is "return true if the user has access to the following product".

So the function should look something like:


can_use_product? product
Tags: ruby

Testing File operations 03-24-2011

I've recently been working on a gem that will integrate git and pivotal into my current command-line workflow. I'll talk more about that in a future post, but check it out if you're interested. As I've been working on it, I have become increasingly aware how awesome mocking and stubbing are. I've been using mocha(gem install mocha #bros) for all of my needs and after a little playing around it has made me a very happy person. I haven't had much use for either until this gem I've been working on. The gem does more file operations that I normally do since most web stuff is heavier on the db action.

On this project I ran into an issue where I wasn't sure how to test the following code.


def load_project_id
  File.open('.git/config') do |file| 
    file.each_line do |line| 
      if line.slice('[pivotal]')
        return file.gets.tr("\s\t\n",'').split(' = ').last
      end
    end
  end
end

For this chunk of code, I wanted to spoof the variable 'file' so that I could make sure that everything in the File.open block does what it needs to. At first I thought that there might be a way to stub the variable that comes in to the block, but it ends up there is a more straight forward thing to do. I ended up turning File.open(".git/config") into File.open(git_config) where git_config is a method that determines the git config directory based on the current working directory. This way I can test this method by stubbing the git_config method with some file I've put in the /tmp directory and keep my config files clean.

Dot-Rspec files 03-02-2011

I was recently working on a small library for assigning people a schedule and I decided to go with rspec 2 for testing. As I was working with it, I found that you can use a .rspec file to keep all of the settings in which seemed like a good idea to me. I'm used to having config files like that what with .bashrc, .rvmrc, etc. My file was laid out as such:


--color
--fail-fast
--format documentation

I could then run the command rspec spec/libs/* and it would run all of my tests in the desired format. I didn't want to have to specify the directory every time and so I decided to add the -I option in my .rspec file to include the directory. This, for some reason, would not work and while looking for a solution, I found the rspec 1 to 2 upgrade page with my answer.

Create a Rake Task

Under rake task it lists how you can set the options using a Rakefile, which in retrospec(...har), I should have been using anyways. I ended up using something like the following:


require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new do |t|
    t.rspec_opts = ["--color", "--format documentation", "--fail-fast"]
    t.pattern = ['spec/libs/*.rb']
end

Now I can call my tests with rake spec.

Moral of the Story

Don't use .rspec for your rspec configurations. You'll probably end up needing a Rakefile at some point anyways so you might as well use that.

Tags: rspec ruby