April 13, 2012 -
1 Comment -
ruby
rails
testing
rspec
Anyone who has spent significant time crafting automated tests with RSpec or Shoulda knows context nesting hell. This seems to be a common idiom with specs which are building up toward a successful scenario while testing failing scenarios along the way. This makes sense, because you’re testing different layers of requirements which seems perfectly suited to nesting contexts. That is, until you need to read the resulting spec, or make modifications to it down the road.
Here’s what I’m talking about:
Note that I’m using a regular method for request_params rather than let or let!. This is necessary so I can use super and keep the requirements DRY. You can’t access the parent context with let (at least not yet).
Now, this isn’t half bad. But imagine if you had more than just three requirements to satisfy, and each one had its own consequence for not being met. Now imagine you wanted to also share these requirements so they could be reused, mixed and matched for different controller actions. Now you have to extract them into shared exampl…
Read more…
February 09, 2012 -
11 Comments -
ruby
rails
patterns
command pattern
dci
Recently the Rails community has seen a flurry of activity regarding a new approach to encapsulating business logic in Rails called Data, Context, Interaction, or, DCI. And rightfully so! The old mantra of “fat models, skinny controllers” has cracked with wisdom as models in larger and more complicated applications have become not just fat but in fact rather obese. Furthermore, the question of which model some piece of business logic should live in has always been vague regarding operations involving multiple models of different kinds.
It is a problem. The results have been sub-optimal design, testability, and readability, coupled with huge model files bloating into thousands of lines of code. The DCI approach has been explored at length as a possible solution. Mike Pack wrote a great article both explaining the benefits of DCI and an example implementation.
The DCI Pattern: Pros and Cons
There are some clear benefits of the DCI approach, especially compared to the old way of just shoving business logic into the nearest relevant model:
Read more…
June 13, 2011 -
0 Comments -
tools
One thing I’ve found that most engineers dislike is the overuse of tools. I’m not talking about build tools or other command line tools, which automate repetitive tasks and make our lives easier. I’m talking about the tools that management wants everyone to use, whether it be for bug tracking, feature reviews, project management, or any other work that is peripheral to the actual task of writing software.
These tools aren’t inherently bad. They can be of great assistance to the process of deploying quality, production-ready code. But I’ve encountered the situation more than a few times where these tools have done more to get in the way than they have to actually help. Usually it’s either due to not picking a tool and sticking with it, or to using tools where they aren’t necessary.
Exhibit A: Too many tools
Here’s one scenario from real life. One company I worked at used five different tools for tracking progress. Five. Two is one too many, and they had five. Trac, Pivotal Tracker, Basecamp, and a couple others whose names I don’t even remember, all played into some sort of chaotic dance to which nobody in the company knew the steps. Every project had its own…
Read more…
