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 firstname.lastname@example.org. 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.
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.
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
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.
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:
I couldn’t remember where I came across this before and wasn’t quickly finding it in the Ruby on Rails API, so decided that I’d do a quick write up on it.
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
So, our route was:
Which provided us with:
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. :-)
It’s time to find my passport again…
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.
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.
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.
- What are some ways that you could use Rip—http://heybrainstormr.com/t/pgte
Older posts: 1 2