• Category Archives: development

Using model constants for project sanity

On one of our larger client projects (approx. 160 models and growing…) we have a specific model that we refer to quite a bit throughout our code. This model contains less than 10 records, but each of them sits on top of an insanely large and complex set of data. Each record refers to a each of their regions that our client does business in.

For example… we have, Australia, United Kingdom, Canada, United States, and so forth. Each of these regional divisions has their own company code, which are barely distinguishable from the next. They make sense to our client, but when we’re not interacting with those codes on a regular basis, we have to look constantly look them up again to make sure we’re dealing with the right record.

I wanted to share something that we did to make this easier for our team to work around these codes, which we should have thought of long ago.

Let’s take the following mode, Division. We only have about 10 records in our database, but have conditional code throughout the site that are dependent upon which divisions specific actions are being triggered within. Each division has various business logic that we have to maintain.

Prior to our change, we’d come across a lot of code like:

# For all divisions except Canada, invoices are sent via email
# In Canada, invoices are sent via XML to a 3rd-party service
def process_invoices_for(division)
  if division.code == 'XIUHR12'
    # trigger method to send invoices to 3rd party service
    # ...
  else
    # batch up invoices and send via email
    # ...
  end
end

An alternative that we’d also find ourselves using was.

if division.name == 'Canada'

Hell, I think I’ve even seen if division.id == 2 somewhere in the code before. To be fair to ourselves, we did inherit this project a few years ago. ;-)

Throughout the code base, you’ll find business rules like this. Our developers all agreed that this was far from friendly and/or efficient and worst of all, it was extremely error-prone. There have been a few incidents where we read the code wrong and/or got them confused with one another. We were lacking a convention that we could all begin to rely on and use.

So, we decided to implement the following change.

Model Constants

You might already use constants in your Ruby on Rails application. It’s not uncommon to add a few into config/environment.rb and call it a day, but you might also consider scoping them within your models. (makes it much easier for you to maintain them as well)

In our scenario, we decided to add the following constants to our division model.

class Division < ActiveRecord::Base
  AFRICA      = self.find_by_code('XYU238')
  ASIA        = self.find_by_code('XIUHR73')
  AUSTRALIA   = self.find_by_code('XIUHR152')
  CANADA      = self.find_by_code('XIUHR12')
  USA         = self.find_by_code('XIUHR389')
  # etc..
end

What this will do is load up ech of these constants with the corresponding object. It’s basically the equivallent of us doing:

if division == Division.find_by_code('XIUHR389')

But, with this approach, we can stop worrying about their codes and use the division names that we’re talking about with our clients. Our client usually approaches us with, “In Australia, we need to do X,Y,Z differently than we do in the other divisions due to new government regulations.”

if division == Division::CANADA
  # ...
end

case division
  when Division::AFRICA
    #
  when Division::AUSTRALIA
    # ...
end

We are finding this to be much easier to read and maintain. When we’re dealing with a lot of complex business logic in the application, little changes like this can make a big difference.

If you have any alternative solutions, we’d love to hear them. Until then, we’ve been quite pleased with this approach. Perhaps you’ll find some value in it as well.

Read more at the source

Aliasing resources in Ruby on Rails

Earlier today, a friend working on a project asked me how we approached routes on our website. If you take a quick peak at our website, you’ll see that we have URLs like so:

When we launched our new site a few months ago, we were working off an existing code base. We have a model named, TeamMember and a corresponding controller. When we decided to come up with new conventions for our URL structure, we opted to ditch the normal Rails conventions and go our own route. What we weren’t sure about was how to alias resources in our routes nicely. After some digging around, we came across the :as option.

So, our route was:

  map.resources :team_members

Which provided us with:

  • /team_members
  • /team_members/robby-russell

We simply added :as => 'who-we-are' to our route:

  map.resources :team_members, :as => 'who-we-are'

…and we got exactly what we were looking for in our URLs.


* /who-we-are
* /who-we-are/gary-blessington

If you look at our site, you’ll notice that we did this in a few areas of our application so that we could define our own URL structure that was more friendly for visitors and search engines.

Anyhow, just a quick tip for those who want to change up their URLs with Ruby on Rails.

p.s., if you know where I can find this documented, let me know so that I can provide a URL in this post for others. :-)

Read more at the source

Howdy Rip!

Chris Wanstrath (@defunkt) just posted the following on twitter.

“Hello Rip – http://hellorip.com/

The Rip project describes itself as, “an attempt to create a next generation packaging system for Ruby.”

One of the cool features is that it supports multiple environments. For example, you can have different Rip environments (with different gem versioning) that are targeted towards specific applications. I have to dig around more through the project, but this looks fascinating.

Check it out at http://hellorip.com/

I’m also curious as to how you think you might be able to start using this.

Read more at the source

Hello, HeyBrainstormr.com

If you follow me on twitter, you might have heard that we launched a little project that we’ve been cooking up at Planet Argon. (news post)

HeyBrainstormr is a lightweight web application that we created so that we could start a brainstorm on a specific topic and solicit ideas from each other. That’s all it does. Nothing more. Nothing less.

We know that having an open brainstorming session requires there to be zero criticism and opted to keep the process anonymous so that even the quiet people could share their ideas. :-)

what can i do right now? : Brainstorming for the rest of us. : HeyBrainstormr

We’ll be posting more details about it on our blog in the near future, but wanted to invite all of my readers to give it a whirl.

I have a few topics that I started (and tweeted about). Feel free to share your ideas on them. :-)

We hope that you find it as fun as we have.

Read more at the source

82,520 minutes on Phusion Passenger

It’s been over 83,520 minutes since I made the switch from using mongrel as my development environment web server to Phusion Passenger. I’ve been extremely impressed with it. Our team has all switched over and haven’t really hit any obstacles in the transition.

Since some people asked me to let them know how this trial period worked out, I felt it was my duty to encourage you all to try it. You can check out my previous post, Switch to Passenger (mod_rails) in development on OSX in less than 7 minutes or your money back! to get rolling.

Additionally, if you’re looking for a streamlined Ruby on Rails deployment environment that includes Passenger, check out Rails Boxcar.

Read more at the source

Building a prototype? Bring some rope.

While scanning through Allison’s copy of Designing for the Digital Age: How to Create Human-Centered Products and Services, I came across this nugget.

The problem with software prototypes

It seems to be widely understood that industrial design and mechanical engineering prototypes—from paperclips and tape to polished appearance models—are disposable learning tools. Prototyping is clearly distinct from manufacturing, so it would be ludicrous to think that even a late-stage prototype could be reused as part of the final product. In software, however, the tools used for anything other than paper prototyping are generally the same tools used for “manufacturing” (i.e., writing production code). For this reason, many stakeholders can’t see why a detailed prototype that appears functional is still many months away from completion.

It immediately reminded me of a few posts that I had written about three years ago on the topic of developing prototypes and NOT keeping them.

The author continues with…

It’s important to educate stakeholders that prototype code is kind of like the illusion of automatic doors on Star Trek—it looks like it’s working, but it’s really a guy standing behind the wall pulling a rope.

I completely agree that education is the most important aspect to managing client expectations. With regard to the amount of work that you put into a prototype, we need to be careful on how much time and energy is put into them. If we can get away with a guy (or some quick Javascript hacks) to demonstrate possible functionality, make sure we aren’t using much more than rope. Rope is cheap. Prototypes should be too.

Related Posts

Read more at the source
close