A Waage Blog

Fellow Ruby-ers, please be warned!!! DO NOT use Ruby floats when performing arithmetic calculations involving money!

My calculations work in IRB, so I was really confused when I ran into this weird situation where (what I thought was) a simple arithmetic calculation led to strange results in my unit tests (I cannot stress the importance of good unit testing!).

My backend calculation was basically this (simplified):

# arbitrary amounts for these two variables
percentage = 12
total_in_cents = 400

discount = percentage.to_f / 100.0
total_in_float = total_in_cents.to_f * 100.0
new_price = (total_in_float * discount ).round / 100

Now, it’s pretty obvious that 12% of (400 cents) $4.00 should just be $0.48 (48 cents)
However, my barrage of unit tests kept producing strange results where a simple calculation was returning incorrect results. Doing some research, I discovered a series of articles worth reading including:

• How to properly round and calculate totals
• BigDecimal arithmetic in Ruby

Also, check out the Money gem – I’ve never used it personally, but people have said good things about it.

Heeding the advice I found online, I re-wrote all my money-related calculations using BigDecimals instead of Floats.

percentage = 12
total_in_cents = 400
discount = BigDecimal(percentage.to_s) / 100
total_in_float = BigDecimal(total_in_cents.to_s) * 100
new_price = (total_in_float * discount ).to_i / 100

After switching over from Floats to BigDecimals, my unit tests all passed!
Lesson learned and hope this heads-up helps you guys too.

Summary:
Use BigDecimals for money calculations and remember to write good UNIT TESTS!!

I finally got around to trying Grape – a “RESTful API microframework built to easily and quickly produce APIs for Ruby-based web applications”. This is a project still in baby stages, but has a lot of potential and worth exploring for anyone creating a Rack-based API in Ruby, not necessarily Rails!

Now, after creating a pretty basic API that used HTTP Basic Authentication, I was inclined to write some RSpec tests to make sure my API was working the way I thought it was (.. or because I am obsessed with well-tested, beautiful code..).

After some thought, I decided that the best way to test my API was with RSpec “request” specs. Now, if you are at all relatively new to RSpec (I was a Test::Unit kinda guy before), it might not be completely obvious that “request specs” are basically what I have come to know as “integration tests”, testing high-level functionality that spans multiple controllers and multiple requests – (think: a user’s interaction with the app).

My reasoning for choosing request specs is because I want to test specific API URL endpoints routed the way I expected. (Routing is handled magically by Grape with a simple mount in the config/routes.rb file). API testing just kinda makes sense to handle in request specs.

Anyways, I ran into a couple issues because in REQUEST specs, you do not have access to the @request object (haha?), as you do in controller specs. Now, in order to mock HTTP Basic Authentication, you need to mock the request object to send headers along with the GET request.

Well, solution: It turns out you can pass headers into your get() method! I only wish I had discovered that an hour ago!

Here’s a simple excerpt from my API request specs that shows how to mock the HTTP basic authentication and test your API functionality:

With NO basic auth, it’s just a simple GET request

  it 'should return a 401 with no basic auth to /api/v1/rewards' do
    get '/api/v1/rewards'
    response.code.should == '401'
    response.body.should == "Unauthorized - Please check your username and password"
  end

To mock the basic auth, simply pass header hash as argument to the GET request! No need to access the request object here.

  it 'should return a 200 with valid basic auth to /api/v1/rewards' do
    # Uses basic_auth helper method
    credentials = basic_auth('testuser','test')
    get '/api/v1/rewards', nil, {'HTTP_AUTHORIZATION' =>  credentials }
    response.code.should == '200'
    response.body.should == "..."
  end

# You can define this at the bottom of your spec file, or in spec_helper for convenience
def basic_auth(user, password)
  ActionController::HttpAuthentication::Basic.encode_credentials user, password
end

Hope this helps someone else. Now go write some request specs!

Often in my Ruby code or Rails application, I will need to find a value in a nested hash. Frequently this also comes in handy when dealing with JSON and parsing JSON to a hash. For example, I might have a hash of user information that looks like this:

user_hash = {:id => 1, :name => 'John doe', :extra => {:birthday => {:month => 11, :day => 16, :year => 1951}}}

Now, when I want to find the birthday year, I have to do something messy like this:

year = user_hash[:extra] && user_hash[:extra][:birthday] && user_hash[:extra][:birthday][:year]

How inconvenient is this?! Every level of the hash I am checking for existence of the hash-key. Here’s a helper method that I use so that I can avoid these verbose statements and get the value I want in 1 line. It adds a ‘hash_val’ method to any hash, and takes in the hash-keys as arguments. If one of the nested hash keys is missing, it will simply return nil.

# I usually define this in an initializer, so it can be used all over my app:
# Eg. Place in config/initializers/hash_val.rb
class Hash
  # Fetch a nested hash value
  def hash_val(*attrs)
    attr_count = attrs.size
    current_val = self
    for i in 0..(attr_count-1)
      attr_name = attrs[i]
      return current_val[attr_name] if i == (attr_count-1)
      return nil if current_val[attr_name].nil?
      current_val = current_val[attr_name]
    end
    return nil
  end
end

Now, getting a nested hash value is so easy!

user_hash.hash_val(:extra, :birthday, :year)
 => 1951

And, if the hash-key does not exist, it simply returns nil:

user_hash.hash_val(:extra, :trouble)
=> nil

I ran into a problem as I was trying to decode and parse the Facebook signed_request for their new Registration plugin (http://developers.facebook.com/docs/plugins/registration).

Folowing the PHP example, I attempted to decode and read the signed_request returned by Facebook. Unfortunately, it seemed like the decoded JSON returned was malformed! It was missing the end hash character “}”. This may not happen in all cases, but the reason is due to the padding in Base64 encoding (See Base64 for URLs in Wikipedia).

To account for the padding in Base64, I used the following helper method to do the base64_url_decode. Hope it helps someone else trying to base64 decode Facebook’s signed_request in Ruby on Rails!:

 def base64_url_decode(str)
   str += '=' * (4 - str.length.modulo(4))
   Base64.decode64(str.tr('-_','+/'))
 end

Notice there’s two things that must happen before decoding the string:

1. Pad the encoded string with “=”
2. Replace the character ‘-’ with ‘+’, and ‘_’ with ‘/’

I wish Facebook mentioned this clearly on their API !

In a recent Rails project, I was trying to figure out how to allow users to view any email’s “Date:” header in his/her own timezone. Here’s a short explanation about how I accomplished this using Ruby’s TZInfo gem!

Purpose:
If an email was sent out from New York, the header would contain a Date string like the following (notice the offset):

Fri, 24 Oct 2008 18:35:07 -0400 (EST)

Now, it makes sense for a user in Los Angeles to be able to view the Date/time as 15:35 pm, while a user in New York City should be able to view it as 18:35pm.

Here’s what I did.

Of course, I installed TZinfo first:

%>sudo gem install tzinfo

Each user should have a timezone associated. Try the following method for a list of timezones in US:

 >>TZInfo::Country.get('US').zone_identifiers

Let’s take two users as an example. We have lakersfan is on the west coast, and knicksfan is on the east coast:

>> lakersfan.timezone = TZInfo::Timezone.get('America/Los_Angeles')
>> knicksfan.timezone = TZInfo::Timezone.get('America/New_York')

Given a date/time string like the following (could be taken from the email header or elsewhere):

>>timestring = "Fri, 24 Oct 2008 18:35:07 -0400 (EST)"

first call Time.parse(timestring) which will create a time object with offset info. **Note that this is different from calling timestring.to_time (which will disregard offset info and store the Time object as UTC).

>> timestring = "Fri, 24 Oct 2008 18:35:07 -0400 (EST)"
>> Time.parse(timestring)
=> Fri Oct 24 18:35:07 -0400 2008 #Stores the Time object with offset
>> timestring.to_time
=> Fri Oct 24 18:35:07 UTC 2008 #Incorrect - the offset is ignored

Now, once you’ve got the Time object in proper format (with offset), you can just call the ‘utc’ method to convert the time into UTC format:

>> utctime = Time.parse(timestring).utc

Lastly, once the time is in UTC format, you can use any user’s timezone object to call ‘utc_to_local’ method and convert that utc time into the user’s timezone!

>> lakersfan.tz.utc_to_local(utctime)
=> Fri Oct 24 15:35:07 UTC 2008
>> knicksfan.tz.utc_to_local(utctime)
=> Fri Oct 24 18:35:07 UTC 2008

Voila! Lakers fan (west coast) sees the time as 15:35, while the Knicks fan (on east coast) sees the time as 18:35 – the same as the email header.