Table or Booth

Ruby Refactoring Pattern: "Forward with Default Params"

Introducing Ruby refactoring pattern called "Forward with Default Params."  This applies to any language that supports parameter defaulting, actually.  And, this pattern may already be documented somewhere for all I know - I haven't looked into it.  If someone can point this out, I'll be happy to defer all credit.  In the meantime...

Problem: You keep creating new methods, each calling the same helper or 'core' method (we'll call it 'method_a'), but with different params.  You can't change the required params of the core method because spagetti-legacy code relies on method_a, without params, such as with Rails controllers.  You should fix the spagetti code but time dictates otherwise.  However, you feel dirty violating DRY in your controller.  What to do?

The Rails Edge, 2006 - Day 1

In this post and the two that follow, I highlight interesting talks at The Rails Edge, 2006.  I do it for Google searching posterity and for my admittedly selfish desire to reinforce key concepts presented. 

Rails Load Path Resolution Tip

Nothing ground breaking in this post.  I write it only because the existing documentation for this behavior is weak or nonexistent. 

Have you ever seen the following message while testing your Rails app?

NameError: uninitialized constant ... blah, blah