Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Developing; Fast and Slow

I recently picked up a copy of Daniel Kahnemann’s Thinking; Fast and Slow. It’s an excellent book describing, amongst other things, the many ways in which our brains process signals and inputs from our environment. I’m talking here about various stimuli which affect our behavior both consciously and subconsciously.

Read more »

LABS
ActiveRecord Refactoring: Move Association Behavior to Associated Class

In a typical Rails app, one ActiveRecord model tends to accumulate a lot of associations and related methods. This is usually the User class; e.g., the User has many posts, comments, contacts, projects, etc. It’s also common to have a few instance methods to filter these associations, e.g., User#unpublished_posts, or User#recent_contacts.

Read more »

LABS
Incremental refactoring

Refactoring is an extremely important part of the process of developing software. It’s what makes your code maintainable with the help of it’s equally important counterpart test suite. It is always good to go on refactoring mode after you made your tests green, but what if you miss it?

Read more »

LABS
method_missing hazardous to your module?

We built an(other) object factory module for our current project and it looks a lot like all the others:



Read more »

LABS
The Big Design Refactor

What is The Big Design Refactor?

Design starts with systematic thinking and then shifts to incremental changes. No matter where a project starts, at some point the design systems’ integrity will degrade to the point that you need to look at the whole thing fresh.

Read more »

LABS
Refactoring the Deeply-Nested Hash Antipattern

On a few different Ruby projects, I have seen an antipattern emerge involving nested hashes.

For example, consider this simple question-and-answer command-line script:

QUIZ = { question_1: { prompt: "What is your name?" }, question_2: { prompt: "What is your favorite color?" } } answers = {} QUIZ.each do |name, question_hash| print question_hash[:prompt], " " answers[name] = gets.chomp end p answers

The QUIZ constant isn’t too hard to understand.

Read more »

LABS
Migrating from a single Rails app to a suite of Rails engines

TL;DR

We moved a Rails app into an unbuilt engine of a new blank slate container app to allow new parts of our app to live next to it as engines as well. It has been working great for us!

I have a sample app rails_container_and_engines of the result's structure on github.

Skip to the pitfalls and discoveries section to read about some of the speed bumps we during our transition. Interested in the why and how? Read on!

LABS
Simple DRY Validations

Here's a handy trick for making custom validations easily reusable.

This is an extract from a customer model with three different street addresses, in which we validate all three of the zip codes. (In this code, the GeoState.valid_zip_code? method answers if something that looks like a zip code is an actual zip code - not all five digit combinations are in use as zip codes, and we want to make sure we've got a live one.)

def validate_home_zip_code
  validate_zip_code(:home_zip_code)
end

def validate_mailing_zip_code
  validate_zip_code(:mailing_zip_code)
end

def validate_previous_zip_code
  validate_zip_code(:previous_zip_code)
end

def validate_zip_code(field)
  errors.add(field, :inclusion) if errors.on(field).nil? && !GeoState.valid_zip_code?(send(field))
end

validates_presence_of :home_zip_code
validates_format_of :home_zip_code, :with => /^d{5}(-d{4})?$/, :allow_blank => true
validate :validate_home_zip_code

validates_presence_of :mailing_zip_code
validates_format_of :mailing_zip_code, :with => /^d{5}(-d{4})?$/, :allow_blank => true
validate :validate_mailing_zip_code

validates_presence_of :previous_zip_code
validates_format_of :previous_zip_code, :with => /^d{5}(-d{4})?$/, :allow_blank => true
validate :validate_previous_zip_code

That looks very wet to me. (WET == "Write Every Time") But it's not too hard to dry this up using just a tiny bit of knowledge of how ActiveRecord validations work.

LABS
Refactoring a dead horse

A while back I made the point that the HasOneThroughAssociation class in Rails shouldn't be a subclass of HasManyThroughAssociation. I also submitted a Rails patch in which I changed the superclass of HasOneThroughAssociation from HasManyThroughAssociation to HasOneAssociation and moved the shared Through functionality into a module. Despite support from the teeming millions, Rails core team member Pratik rejected the patch for being "just a refactoring."