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!!

# Pass it into the GET request!
get '/programs/100', nil, {'HTTP_HOST' => 'sub.domain.com'}

The 3rd parameter to the get method is a hash of HTTP headers.
See the Rails API documentation for details.

Note:
Depending on the type of test you are working with (support / controller / request / integration etc.) you pass in the sub domain differently.

Here’s some good reference posts on Stack Overflow for setting subdomains in controller specs:
1. Rails RSpec Set Subdomain

# Set the @request.host in a before block
before(:each) do
  @request.host = "#{mock_subdomain}.example.com"
end

2. Subdomains in RSpec Controller Tests

 # I haven't tried this, and not sure you would need to mock out the current_subdomain method.
  @subdomain = 'sub.domain.com'
  controller.expects(:current_subdomain).returns(@subdomain)
  @request.host = "#{@subdomain}.test.host"

Here’s the easy way to run one test in RSpec… by line number!
Look at the line-number of any RSpec block (it, describe, etc), and simply run the rspec command, passing in the [filename]:[line number]:

$ rspec models/user_spec.rb:27

Happy testing!

# Can place this in environment.rb
# 2nd argument - number of log files to keep
# 3rd argument - size (bytes) that log files are allowed to reach before rotation
config.logger = Logger.new(config.log_path, 8, 1024)

However…. I like the customizability of using logrotate better!
Here’s my logrotate config file that handles weekly log rotation, delayed compression and uses the copy-truncate method:

I place this config in the /etc/logrotate.d folder (ubuntu)
(ie. /etc/logrotate.d/<rails_app_name>)

/var/www/rails//shared/log/production.log {
  weekly
  missingok
  rotate 8
  compress
  delaycompress
  notifempty
  copytruncate
}

This config will rotate my production.log file weekly, keeping at most 8 log files. It delays compression until next rotation (extra precaution, simply to make sure the log file is not in use), and uses the ‘copytruncate’ method which basically copies the current log file, and then truncates this log file, so the Rails app maintains file pointer for continued writing.

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!

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

ProjectName::Application.routes.draw do
...

This means that changing a project name involves changing a number of files to reference the new project name as well. Here’s a quick list of the standard files to change:

Rakefile
config.ru
config/application.rb
config/database.yml
config/environment.rb
config/environments/*.rb
config/initializers/secret_token.rb
config/initializers/session_store.rb
config/routes.rb

Besides these, it’s a good idea to also check all files in config/ and config/initializers/
If you want to be thorough, run this grep command in your project root, and you will get a list of all files that contain your old project name:

grep -Ri 'oldprojectame' * | cut -f1 -d':' | sort | uniq

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 !

Anyways… too much on Redmine! This post is to describe how to setup a Git repository for use with Redmine.

The important thing to note is that the Git repository MUST BE on the same server as your Redmine setup. So, you probably need to have access to that server!
This was not ideal for me because our Git server does not have Ruby/Rails, etc. installed on it. That’s okay! You just need to clone the repository as a BARE repository on the same machine that your Redmine app is running on. Let’s see how:

Pick a place on your Redmine app server to house all your bare Git repos.
I will choose “/var/local/git_copies” for my example.

Note: Make sure that your permissions allow for your web-user to access these Git repos. My web-user is ‘build’.

# Change to build user (see above)
$ su - build
# Create the directory
$ mkdir /var/local/git_copies

Now, create your git clone as a bare repository clone.
Note: a bare repository will not have your actual files. It will just contain the standard git folders

# Goto your git_copies directory
$ cd /var/local/git_copies
# Make a bare clone of the repo
$ git clone --bare ssh://git@reposerver/usr/local/git_root/foo-project.git

Change into your project and configure remote branch tracking for your local copy.

$ cd foo-project.git
$ git remote add origin ssh://git@reposerver/usr/local/git_root/foo-project.git

Now, normally you want to sync up the repo, but you cannot do a normal git fetch && git merge into a bare repo.
Instead, do a fetch and reset the HEAD to point to the remote branch commit. You need the ‘–soft’ flag or else you will see errors!

$ git fetch origin
$ git reset --soft refs/remotes/origin/master

Now, remember you need to manually sync your new Git repo to have the changes appear on Redmine. A better idea would be to create a cronjob that does this automatically. Especially with more than 1 repository, automating this process will save much time. Here’s the basic idea:

# Add the following to your crontab
*/30 * * * * cd /var/local/git_copies/foo-project.git && git fetch origin && git reset --soft refs/remotes/origin/master > /dev/null

Instead of doing many times in your crontab, maybe it would be easier to setup a bash script to run:

#!/bin/bash
# Not tested! Use at your own risk, and change your GIT_ROOT and "*.git" to fit your setup.
GIT_ROOT=/var/local/git_copies

cd $GIT_ROOT
ls *.git | while read repo; do
  cd $repo && git fetch origin && git reset --soft refs/remotes/origin/master > /dev/null && cd $GIT_ROOT
done

Then, just add this one script to your crontab and have it run every N minutes as you desire!

This site is helpful and worth checking out as well:
Reference on synchronizing 2 git repositories

That’s it, let me know how it goes!

I know I can never remember how to do it, so here’s a post for me and hopefully you!

Create a local Git repository in your application for your local files.

#On local machine
cd foo_project
git init
git add *
git commit -m "My initial commit message"

Now, create the repository on your Git server. All of my git repositories are owned by a user git and located at /usr/local/git_root/. You can change these things accordingly to match your server setup.

#On remote machine (Git remote repository)
sudo su - git
cd /usr/local/git_root/

Create your new project git repo as a bare Git repository

mkdir foo-project.git
cd foo-project.git/
git --bare init

Make sure permissions are set properly. These are common options I use for my shared repositories

git config core.sharedrepository 1
git config receive.denyNonFastforwards true
find objects -type d -exec chmod 02770 {} \;
#The core.sharedrepository flag tells git to keep everything group readable and writable.
#The receive.denyNonFastforwards flag makes sure that merges can't happen when you push to the repo. You have to do the merges on your local machine, and then push the result.

Now, go back to your local repository, and add the newly created remote repository so it tracks from the remote repository (origin).

#On local machine, in your git project
git remote add origin ssh://git@example.com:2227/usr/local/git_root/foo_project.git
git push origin master

Now, to ensure that your local branch is tracking when you do a fetch, you need to use -f option to force a new local branch to be created even though it already exists.

#Switch to origin/master so you don't get any error about "fatal: Cannot force update the current branch."
git checkout origin/master
#Create the local "master" branch that is tracking the "origin/master" branch
git branch -f master origin/master
#Switch back to your "master" branch
git checkout master

There you have it. You should be able to push changes to origin and fetch changes to your local copy!