Read my latest article: Six days to complete the Rails hosting survey (posted Thu, 24 Apr 2014 14:36:00 GMT)

Launching Rails projects, an open call for lessons learned

Posted by Tue, 23 Jun 2009 17:33:00 GMT

I’m working on my presentation for Rails Underground and was hoping to solicit a few tips from other people in the industry.

Have you launched a Ruby on Rails application recently? Are there some things that you wish you had known beforehand?

Mind sharing? You can email me with your story at robby+launchstory@planetargon.com. I’ll let you know if your tip gets used in the presentation and please indicate if you’d be okay with me posting your tip in a future blog post.

Using model constants for project sanity

Posted by Tue, 23 Jun 2009 06:39:00 GMT

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.

Aliasing resources in Ruby on Rails

Posted by Tue, 23 Jun 2009 06:00:00 GMT

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. :-)

Remember to Flush Your Toilet

Posted by Sat, 20 Jun 2009 00:58:00 GMT

Saw this tweet the other day…

Twitter / Teresa Brazen: Design Principle: Flush t ...
Uploaded with plasq’s Skitch!

So, I have to ask. How many toilets (buckets) do you maintain? How many of them still have projects/tasks in them? Why haven’t you flushed your toilets yet?

Speaking at Rails Underground 2009

Posted by Thu, 18 Jun 2009 13:40:00 GMT

It’s time to find my passport again…

Waiting at Gatwick Airport

I’ve been invited to speak at Rails Underground, which is being held in London, UK from July 24-25th.

My talk, which is tentatively titled, “Launching Ruby on Rails projects, a checklist”, will expand on several ideas that came out a previous article on the topic. Additionally, I plan to share some of the lessons that we’ve learned at Planet Argon as we’ve launched projects over last several years.

I'm speaking at Rails Underground!

If you’re able to make it, I encourage you to register for the event before it’s too late. Take a quick peak at the list of speakers. I’m grateful to the event organizers for the invite and look forward to seeing/meeting all of the attendees!

Also, for those of you in the London area. If you’re seeking a design and development team that specializes in Ruby on Rails and want to schedule a meeting with me while I’m visiting, don’t hesitate to get in touch with us. I’m planning on staying a few days extra around the conference dates to visit some of our existing clients and would be happy to meet you.

Howdy Rip!

Posted by Thu, 11 Jun 2009 17:35:00 GMT

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.

Older posts: 1 2