All posts by Gregg Pollack and Olivier Lacan

Episode #502 – October 14th, 2014

RailsRumble, Ruby Motion for Rails devs, how Ruby Hashes work, how to deal with data migrations, clean up your routes file, and get better logs.

Episode #469 – June 3rd, 2014

This week we talk about the brand new RSpec 3 and Git 2, but also how to use bower-rails instead of JavaScript gems, JSON responses with PostgreSQL, and the quirks of Ruby serialization & enumeration.

Ruby 2.0.0-p576 Released

September 19, 2014

We are pleased to announce the release of Ruby 2.0.0-p576, to celebrate the holding of RubyKaigi2014 in Japan now.

This release includes many bugfixes, such as:

many fixes of memory leaks and using extra memory,
many fixes of platform-specific issues (especially in build process),
many documentation fixes.

See tickets and ChangeLog for details.

Download

http://cache.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p576.tar.bz2

SIZE:   10753403 bytes
MD5:    eccd42d43620544a085c5e3834572f37
SHA256: 8cfdbffc81cebd1d25304225ffadc7dcb612a500c81ba6f5f95c5296dfa62059
SHA512: e089cca4867cd9c715f4f37e40a1db9af6ba0c74b47e79568121bb980476f8877a87ccb848b973381edb4667c0c73165f5e1761f60db839e67f6326302dbd864

http://cache.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p576.tar.gz

SIZE:   13610215 bytes
MD5:    2e1f4355981b754d92f7e2cc456f843d
SHA256: 9f5a593d81768c856155be6b2d2e357b961b5c43e04ba54c1ee511987fac2b66
SHA512: f5b7e7fba87ed21ee5a422ea978794adbd2f63669db7c361cec3698b3ebba2e95fc113791de2e22513bbe23c5fecc0605d1b76cadb0e714162a2c0e94cbd77b9

http://cache.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p576.tar.xz

SIZE:   8318772 bytes
MD5:    d64d6a92d6101c83396ef4a2754d9d2a
SHA256: 4aeac1cbca1b5ead0ace5625ba5ea50bb11ee6f8c41ff7cd305f7ff760e09496
SHA512: e556435df9e6b4aae1ad27f986307a5aa6718b4b6a3365f6572b1eb3be72f1fa7cdda3cf5b9c142b878617770497ea2660595f505d1fe6924dcffacb5ccabecf

http://cache.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p576.zip

SIZE:   15122735 bytes
MD5:    620e105c4f9a4274a8351516d0f6a53a
SHA256: cb0166d9afb0126612dff10d15848483984df4900c1b34cd053b1be6893ea38b
SHA512: adce5f044283e97fccbc80c770f999d20e366f7ee8e13782ca71490b5a16198ae0cdbc6df7419f085e2f7adea30552704141d37496cefcb9b147802b55d3ff82

Release Comment

I’m grateful to everybody who supports Ruby. Thank you.

Posted by usa on 19 Sep 2014

[…]

Using model constants for project sanity

June 23, 2009

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.

[…]

The Ruby Rails Aggregator