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.

Test a will_paginate Custom Renderer 01-22-2012

I was recently working on a project where my employer wanted me to make the site's current pagination work the way the old site's pagination worked. I had recently switched over using will_paginate, and while there are a number of good resources for making customized link renderers: frivolous, thewebfellas are a few. They don't really mention testing.

While searching through the internets, I eventually stumbled upon this on tsigo's github with some specs for his renderers. For me, I just had to test an override of windowedpagenumbers, and link. Setting up the test can be seen easily enough from the github file, but essentially, you just create an instance of WillPaginate::Collection and pass that into whatever renderer you have created along with any options like so:

@renderer = LinkRenderer.new
@collection = WillPaginate::Collection.new(page, per_page, total_entries)
@renderer.prepare(@collection, options, '')

@renderer.method_name.should do_something

You will have noticed that I've stubbed out the url method. That is because we aren't using a real collection of objects and therefore there is no url to generate.

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

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

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.


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;


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)

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

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.