Between 0.9.26, RC and final 1.0 release, bundler went thru some heavy changes with respect to command line options it supports. Luckily, twitter, forum and blogs kept everybody in the loop.

The blogs, however, became obsolete quickly and even blog posts few months old don’t work with latest version of bundler. We came across this issue that kept is in a loop for a while.

Snow Leopard changed a few things with ruby and mysql gem when it came out. Most mysql installation issues are hammered out by now and are well documented. In summary, installing mysql gem requires 2 things:

• Specifying architecture flags: ARCHFLAGS=”-arch x86_64″
• Specify location of mysql_config to compile agains: –with-mysql-config=/usr/local/mysql/bin/mysql_config

Prior to bundler, this is what you would do on snow-leopard to install mysql:

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

With bundler, there is no command line option that I could find that I can pass to “bundle install” command. Having been in the loop around bundler, I knew that such OS specific options don’t go in Gemfile and have to be specified in user specific files such as ~/.bundle/config file. The official website for gem-bundler doesn’t have any mention of this (is it because we need to keep things simple for people just getting upto speed with bundler?).

A search for “build-options” (recalling from vague memory) turns up these results, which are all obsolete.

# WARN: this doesn't work with latest bundler gem. Read on for proper instructions
$ gem bundle --build-options build_options.yml

After looping for a bit, I finally ended up at the right place (Google found this on gembundler.com but there is no way to get to this from the website itself). So, I did this:

$ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config

This updated my ~/.bundle/config with proper information that it will need for “bundle install” command. It make sense to keep this in ~/ folder and not my project folder since it applies only to my environment and it applies to all projects on this machine.

With this, doing “bundle install” still doesn’t install mysql properly. Comparing this to the pre-bundler command, it solves one issue. The ARCHFLAGS still need to be available for “bundle install”. With some leap of faith, I set an environment variable to this effect:

$ export ARCHFLAGS="-arch x86_64"
# should this go in my .bash_profile (so that mysql installs fine always, for all projects?
# And I don't have to remember to set this each time I do a fresh bundle install.

And voila, “bundle install” installs mysql correctly.

Bundler is stable now and is making everybody’s life much much easier. It isn’t changing as fast and so this blog post won’t be obsolete too soon
s

Share/Bookmark

When it comes to monitoring servers and processes in production, there is quite a few open source tools: nagios and hyperic are proven solutions for enterprise apps. Monit and god are the favorites of ruby/rails community. God has been around for a few years now and most critical issues with god seem resolved. So, I decided to use that on my project.

If you’ve worked with any deployment related stuff before, you know that it hardly ever goes as planned. With few machines involved, few processes, file/folder permissions and process permissions, there is bound to be things that will take longer. God is no different. And no wonder you will find wiki/forum posts from folks who’ve been thru it. I had my share of those and in the end I am happy with the config I found.

Here is a journey as it went:

Goal-1: Monitor delayed_job using god:

# run with: god -c /path/to/file.god -D
RAILS_ROOT = "/home/sjain/projects/pfa/omt"

# Watch for delayed_job
God.watch do |w|

  w.name = "delayed_job"
  w.interval = 30.seconds # default
  w.dir = RAILS_ROOT
  w.start = File.join(RAILS_ROOT, "script/delayed_job start")
  w.stop = File.join(RAILS_ROOT, "script/delayed_job stop")
  w.restart = File.join(RAILS_ROOT, "script/delayed_job restart")
  w.start_grace = 10.seconds
  w.restart_grace = 10.seconds
  w.pid_file = File.join(RAILS_ROOT, "tmp/pids/delayed_job.pid")
  w.log = File.join(RAILS_ROOT, 'log/god.log')

  w.behavior(:clean_pid_file)

  w.start_if do |on|
    on.condition(:process_running) do |c|
      c.interval = 5.seconds
      c.running = false
    end
  end

  # lifecycle stuff goes here ...
end

This is fairly standard from God’s website. The only interesting thing here is I kept RAILS_ROOT as a string constant at the top since I know I will have to make it configurable as part of my capistrano deploy script. With this, I could run following command and have god monitor my delayed job:

$ god -c /var/www/html/application/current/config/app.conf
# Verify with 'god status'

Goal-2: Monitor apache using god:

# Watch for apache
God.watch do |w|

  watch_name = "app_server"
  w.name = watch_name
  w.interval = 30.seconds # default
  w.dir = RAILS_ROOT
  w.start = File.join(RAILS_ROOT, "/etc/init.d/httpd start")
  w.stop = File.join(RAILS_ROOT, "/etc/init.d/httpd stop")
  w.restart = File.join(RAILS_ROOT, "/etc/init.d/httpd restart")
  w.start_grace = 10.seconds
  w.restart_grace = 10.seconds

  w.start_if do |on|
    on.condition(:http_response_code) do |c|
      c.host = 'localhost'
      c.port = 3000
      c.path = '/'
      c.code_is_not = 200
      c.timeout = 10.seconds
      c.times = [2, 5]
    end
  end
end

This was a straight modification from the delayed_job config, which didn’t work for a few reasons:

1) Since I was starting god under my account, it couldn’t execute the start/stop commands specified in the watch file. For those to work, I had to start god script under sudo permissions.

$ sudo god -c /var/www/html/application/current/config/app.conf
# Once you start god as sudo, all other commands for god need sudo as well ... 'sudo god status'

2) The other issue with the above apache monitoring config was that once I start god as sudo, I still need my apache process to run under restricted user on the destination machine. Since we use CentOS for our production environment, this use is ‘www-data’. So, updated my god config with following:

# Watch for apache
God.watch do |w|
  ...
  w.uid = 'www-data'
  w.gid = 'www-data'
  ...
end

Also, now that I am starting god as sudo, all watches now need to specify uid/gid. So, I had to go back and update my delayed_job watch with uid/gid to be that of my ‘railsdeploy’ user. My rails app gets deployed under ‘railsdeploy’ user account and delayed_job process runs under this user as well.

# Watch for delayed_job
USER = "railsdeploy"
GROUP = "railsdeploy"

God.watch do |w|
  ...
  w.uid = USER
  w.gid = GROUP
  ...
end

Notice, how we are not hard-coding user/group directly. We know that eventually our capistrano script will need to replace those variables with configurable values. I kept all such things at the top of my .god file. There is a few more to come.

3) No, that was not all. The next problem I ran into was related to user environment. Since I am starting my god under sudo now, it was not guaranteed that my environment variables are still the same under that user. I found this the hard way (another 1/2 hr.) and in my case the default PATH under sudo was setup to give access to a different ruby version that the one we use for our production environment. So, I had to update both of my watches to have few necessary environment variables.

RAILS_ROOT = "/var/www/html/application/current"
RAILS_ENV = "sandbox"
RUBY_PATH = "/opt/ruby-enterprise/bin"

God.watch do |w|
  ...
  w.dir = RAILS_ROOT
  w.env = {
    'RAILS_ROOT' => RAILS_ROOT,
    'RAILS_ENV' => RAILS_ENV,
    'PATH' => "#{RUBY_PATH}:/usr/bin:/bin"
  }
  ...
end

A few tricks to remember when working with god is where to look for clues in case something doesn’t work. I found following things useful.

Adding log-level of debug when firing up god:

$ sudo god --log-level debug -c /var/www/html/application/current/config/app.conf
# with this god prints information each time it does a check on your monitored processes. These are big help to validate your frequency of poll and tweak your retry limits etc.

If you didn’t specify the log file location for god in command line, they go to system messages. This can be /var/log/messages on CentOS or /var/log/Syslog on Ubuntu (I guess). You can also specify log file in command line:

$ sudo god --log-level debug -c /var/www/html/application/current/config/app.conf -l /var/log/god.log

Or, during your test setup, you can run god in non-daemon mode to have it print all messages in console.

# -D option for non-daemon mode
$ sudo god --log-level debug -c /var/www/html/application/current/config/app.conf -D

So, with this, I have 2 processes being monitored and each with different user/group setting. So far, so good.

Goal-3: Monitor passenger using god (failed):

Since we run apache+passenger combo in our environments, I wanted to see if I can restart passenger also if http-response didn’t work as part of apache watch. So I attempted this:

# adding passenger to apache monitoring
God.watch do |w|
  ...
  apache_init = "/etc/init.d/httpd"
  passenger_restart = "touch #{RAILS_ENV}/tmp/restart.txt"
  w.start = "#{apache_init} start; #{passenger_restart}"
  w.stop = "#{apache_init} stop; #{passenger_restart}"
  w.restart = "#{apache_init} restart; #{passenger_restart}"
  ...
end

So, what I trying to do here is run 2 commands as part of one watch. Apparently, this doesn’t work. I believe, this has more to do with how god hands over those commands to under lying system that anything else. I couldn’t figure this one and I am not aware of the best way to monitor passenger outside of apache to I left it at that. My guess if the http-response is not working and I restart apache, it should technically restart passenger as well and fix the issue.

Goal-4: Leverage capistrano to help with god configuration:

Since I don’t even run apache locally for development (I run mongrel), I had to test all these things on a sandbox machine. I leveraged capistrano to help me out with deploying these god config files after I modified them each time locally. Here is what capistrano tasks looked like:

 namespace :god do
   task :start, :roles => :app do
     god_config_file = "#{latest_release}/config/omt.god"
     sudo "god --log-level debug -c #{god_config_file}"
   end
   task :stop, :roles => :app do
    sudo "god terminate" rescue nil
  end
  task :restart, :roles => :app do
    god.stop
    god.start
   end
   task :status, :roles => :app do
    sudo "god status"
   end
   task :log, :roles => :app do
    sudo "tail -f /var/log/messages"
   end
  task :deploy_config, :roles => :app do
     god_config_file = "#{latest_release}/config/omt.god"
     god_script_template = File.dirname(__FILE__) + "/deploy/templates/omt.god.erb.rb"
     data = ERB.new(IO.read(god_script_template)).result(binding)
     sudo "god load #{god_config_file}"
   end
   task :redeploy, :roles => :app do
     god.deploy_config
     god.load_config
   end
 end

Most tasks are straight forward with managing god itself (start/stop/restart/log). The deploy_config tasks worked great with the following config file in order to generate proper .god config file on the destination machine:

# run with: god -c /path/to/file.god -D
RAILS_ROOT = "<%= latest_release %>"
RAILS_ENV = "<%= rails_env %>"
USER = "<%= user %>"
GROUP = "<%= group %>"
RUBY_PATH = "<%= ruby_home %>/bin"
GOD_ENVIRONMENT = {
  'RAILS_ROOT' => RAILS_ROOT,
  'RAILS_ENV' => RAILS_ENV,
  'PATH' => "#{RUBY_PATH}:/usr/bin:/bin"
}

God.watch do |w|
  ...
  w.dir = RAILS_ROOT
  w.env = GOD_ENVIRONMENT
  w.uid = USER
  w.gid = GROUP
  ...
end

As you can see above, the constants defined at the top of .god.erb.rb template file picked values for variables from the capistrano script and replace them in template to generate the actual .god config file. Now, I could use this file to generate script for each environment and have it generate this with each god deploy. The god script once configured doesn’t change often but I still like to regenerate it with each capistrano deploy just as I would generate apache vhost file using capistrano with each deploy. This is debatable but I just like it that way.

Goal-5: Configure god as init script

Any monitoring solution isn’t complete until it takes care of starting/stopping itself automatically. God has to be configured to start automatically on server reboot. Now, it was time to create init script for god itself. After a few trial errors I ended up with following init script template:

#!/bin/bash
#
# God
#
# chkconfig: - 99 1
# description: start, stop, restart God (bet you feel powerful)
#

# source function library
. /etc/rc.d/init.d/functions

RUBY_PATH="<%= ruby_home %>/bin"
PATH=$RUBY_PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=$RUBY_PATH/god
PIDFILE=/var/run/god.pid
LOGFILE=/var/log/god.log
SCRIPTNAME=/etc/init.d/god
CONFIGFILEDIR=/etc/god

#DEBUG_OPTIONS="--log-level debug"
DEBUG_OPTIONS=""

# Gracefully exit if 'god' gem is not available.
test -x $DAEMON || exit 0

RETVAL=0

god_start() {
  start_cmd="$DAEMON -l $LOGFILE -P $PIDFILE $DEBUG_OPTIONS"
  #stop_cmd="kill -QUIT `cat $PIDFILE`"
  echo $start_cmd
  $start_cmd || echo -en "god already running"
  RETVAL=$?
  if [ "$RETVAL" == '0' ]; then
    sleep 2 # wait for server to load before loading config files
    if [ -d $CONFIGFILEDIR ]; then
      for file in `ls -1 $CONFIGFILEDIR/*.god`; do
        echo "god: loading $file ..."
        $DAEMON load $file
      done
    fi
  fi
  return $RETVAL
}

god_stop() {
  stop_cmd="god terminate"
  echo $stop_cmd
  $stop_cmd || echo -en "god not running"
}

case "$1" in
  start)
    god_start
    RETVAL=$?
    ;;
  stop)
    god_stop
    RETVAL=$?
    ;;
  restart)
    god_stop
    god_start
    RETVAL=$?
    ;;
  status)
    $DAEMON status
    RETVAL=$?
    ;;
  *)
    echo "Usage: god {start|stop|restart|status}"
    exit 1
    ;;
esac

exit $RETVAL

A few things to note here. If you look carefully at the god_start() function, it starts the god process as daemon and then loads any *.god files in /etc/god/ folder. This has several benefits. When the server reboots, god doesn’t need to hunt around for config files in various places. And whatever application needs to be monitored can have one of their config files installed here for god to pickup. The capistrano deploy can now be updated to deploy a .god file in this folder and then call “god load app.god” to have it loaded during each deploy. The next time machine/god restarts, it will pick up monitoring of configured apps automatically.

The capistrano task could look like:

namespace :god do
  task :deploy_config, :roles => :app do
    # deploy omt.god file
    god_config_file = "#{latest_release}/config/omt.god"
    god_script_template = File.dirname(__FILE__) + "/deploy/templates/omt.god.erb.rb"
    data = ERB.new(IO.read(god_script_template)).result(binding)
    put data, god_config_file
    sudo "mkdir -p /etc/god", :pty => true
    sudo "ln -sf #{god_config_file} /etc/god/omt.god", :pty => true
    # load file into god service (assumes god is already running)
    god_config_file = "#{latest_release}/config/omt.god"
    sudo "god load #{god_config_file}"
  end
end

Since each deployed environment (sandbox, staging, production) can have ruby-home in different folder location. I couldn’t use static init script file. I leveraged capistrano to use a template file (with ERB engine) to replace variables on the fly. The capistrano task for this looks as follows:

Even deploying god init script file could be done using capistrano:

namespace :god do
  task :deploy_init_script, :roles => :app do
    # Note: god gem (version >= 0.11.0) must be installed as system gem for this to work
    god_init_template = File.dirname(__FILE__) + "/deploy/templates/god.init.template.sh"
    data = ERB.new(IO.read(god_init_template)).result(binding)
    put(data, "/tmp/god_init_script", :via => :scp, :mode => "755") # put command doesn't support sudo, so we can't directly copy to /etc/init.d folder
    sudo "mv /tmp/god_init_script /etc/init.d/god"
    sudo "/sbin/chkconfig --level 35 god on" # enable run levels 3 and 5
  end
end

As you can see above, we copy the init script in /etc/init.d/god folder and then run chkconfig command to have it restart automatically in unix run-levels 3 and 5. Now, assuming god is already setup on your server to run as init script. We can modify our capistrano task for god start/stop/restart/status commands to leverage unix’s standard “service” command.

# capistrano tasks: god:start, god:stop, god:restart, god:status
namespace :god do
  ["start", "stop", "restart", "status"].each do |cmd|
    task cmd.to_sym, :roles => :app do
      sudo "service god #{cmd}"
    end
  end
end

There is still a few more things I have to left to do. For example, monitoring mysql database server. Since my database in production resides on a different server than app server, this will require installing a different script on mysql server machine or somehow monitor remotely from one of the app servers…

As I mentioned previously, deployment tasks never go as planned. There are always hiccups. But it is fun to see it all working at the end of the day!

Share/Bookmark

Bundler is optional for rails 2.3.X. However, it is not a bad idea to upgrade to bundler for several reasons:

• It is stable now and will solve your gem dependency conflicts better than rubygems require.
• You will be better prepared to migrate to rails3 when you are ready.

Instructions for using bundler with rails 2.3 will get you off to a good start. We use shoulda and mocha for our test suite. If you do too, you may run into an issue that Yehuda rightly blogged about here.

To fix this, here is what you need to do:

In config/boot.rb, replace:

    def load_gems
        @bundler_loaded ||= Bundler.require :default, Rails.env
    end

with:

      def load_gems
        @bundler_loaded ||= begin
          result = Bundler.require(:default)
          Bundler.require(Rails.env) unless Rails.env.test?
          result
        end
      end

And in your config/environments/test.rb, add following at the end:

require "shoulda"
Bundle.require(:test)

As Yehuda explains, Mocha adds a few features depending on weather shoulda is loaded or not. The trick is to ensure that shoulda is loaded and is available before mocha is loaded.

Besides, if you are using mocha version 0.9.8, and have a ‘require “mocha”‘ line at the bottom of your test/test_helper.rb (as required by mocha/README), you can probably remove that here. Bundler takes care of it properly.

Again, don’t forget that non-rails commands must be executed with bundle exec:

$ bundle exec cucumber

Enjoy!

Share/Bookmark

Ever wondered how to login as two different users at the same time? The situation manifests in any project where you want to be able to test a workflow involving several actors with different roles. The problem is that browsers allow only one login for a given domain at any one time. So, you are required to logout as current_user before logging in as another. One of the solution people use is install multiple browsers.

Solution: Multiple Browsers

So, lets say your favorite browser is firefox. And you also have IE7 installed by default on your windows machine. And you have a google chrome installed just so you can try out the new and blazing contribution by google. Most developers, I assume, more than a single browser installed on their system. Given this, you can login as different user in each browser.

This works but here is another solution that, as you will quickly realize, is better.

Solution: Multiple names for your “localhost”

Just update your /etc/hosts file to add more names for your local machine. Lets take a concrete example:

So, on a project, realted to mortgage industry, I have several actors like borrower, realtor, loan officer, mortgage-broker. I updated my /etc/hosts file (on linux) from this line:

127.0.0.1 localhost

to this:

127.0.0.1 localhost r lo mb b

With this above line, I can access my local application using following URLs:

http://r:3000 (for realtor)
http://lo:3000 (for loan officer)
http://b:3000 (for borrower)
http://mb:3000 (for mortage broker)

Now, I can open 4 tabs in a browser each with different URL and login as different users. Coupled this with password saving feature of browser, I don’t even have to type username/password for each user as long as I am disciplined about not cross-logging in as realtor inside borrower url (b:3000). Go ahead, leave yourself logged in and never logout!

This simple trick is better than multiple browser solution since it doesn’t require as many browser and you can have as many unique URLs as you want. And you are not limited to using this trick for local testing. If you have a staging server at http://staging.project.com that resolves to an IP, say, 192.1.2.3, you can repeat the same process:

# my /etc/hosts file
127.0.0.1 localhost r lo mb b
192.1.2.3 staging.project.com sr slo smb sb
# Now I can
# http://sr (staging realtor)
# http://slo (staging loan officer)
# you get the drill ...

There you go. Happy testing!

Share/Bookmark

So, I found this issue with google chrome and safari web browser and I believe this applies to any webkit based browser. When a form submit is disabled by setting the submit button to disabled=true attribute, the browser is usually expected to prevent submission when the user hits “ENTER” on any of its text fields. This works fine in Firefor, my default browser.

In my rails app, I had to do this to work around this.

We use haml rendering engine for our project and my form looks like this:

- remote_form_for @product_search, :url => product_searches_path, |
  :html => {:method => :post, :id => 'product_search_form'} do |form|

This generates a form like this:

  <form onsubmit="jQuery.ajax({data:jQuery.param(jQuery(this).serializeArray())
  + '&authenticity_token='
  + encodeURIComponent('MlHm/z3dsdYtETKwtNnwQlojx1NIduLlWFMECbjntsM='),
     dataType:'script', type:'post', url:'/product_searches'});
     return false;"
  method="post" id="product_search_form"
  class="product_search"
  action="/product_searches">

I was working with an ajax form but I believe the bug happens even with traditional form POST as reported by another user here.

So, I had to create an onSubmit javascript myself to fix the situation:

- semantic_form_for @product_search, :url => product_searches_path, |
  :html => {:method => :post, :id => 'product_search_form', |
  ::onsubmit => "return jQuery.productSearchOnSubmit();"} do |form| |

(function($){
  $.productSearchOnSubmit = function() {
    if ($('#product_search_submit').attr('disabled')) {
    // do nothing
    } else {
      jQuery.ajax(
      {
        data: jQuery.param(jQuery('#product_search_form').serializeArray()) + '&authenticity_token=' +
        encodeURIComponent(form_authenticity_token),
        dataType:'script',
        type:'post',
        url:'/product_searches'
      });
    }
    return false;
  }
})(jQuery);

I also had to add global javascript variable for form_authenticity_token to make it available for javascript when performing submit.

%html
  %head
    :javascript
      var form_authenticity_token = '#{form_authenticity_token}';

If you think, this is a bug too, please vote for a fix.

Share/Bookmark

ActionMailer classes, for sending out emails, typically reside with models, inside app/models folder. Yet, they have traits that are similar to controllers. For example, each actionmailer class has a view folder inside app/views where email templates are defined. And testing support for email is provided as functional tests with assert_select macros such as assert_select_email.

In my current project, most of our email hooks are defined on model classes as after_filter. This is in line with recommendation to keep controllers thin and models fat. However, testing email body’s html format is a pain since assert_select_email support is only available in ActionController::TestCase hierarchy, and not in ActionMailer::TestCase hierarchy.

Consider following ActionMailer test:

class MortgageBorrowerEmailerTest < ActionMailer::TestCase
  should "invite borrowers" do
    realtor, borrower = User.make, User.make
    response = MortgageBorrowerEmailer.deliver_invite_borrowers(realtor, borrower)
    # test from/to/subject works now 
    assert_same_elements([borrower.email], response.to)
    assert_equal([realtor.email], response.from)
    assert_equal("#{realtor.full_name} has invited you to manage your mortgage application in Lendable", response.subject)
    # testing body is still primitive 
    assert response.body.include?(realtor.full_name)
    assert response.body.include?("/account_preferences/#{borrower.perishable_token}/edit")
  end
end

ActionMailer::TestCase has decent support for intercepting mail delivery and hold onto mails for introspection. This allows us to assert smaller pieces like from, to, subject etc. However, what it doesn’t support is more fine grained assertion on email’s html body. it would be nice to be able to apply assert_select assertion on email’s response body for critical pieces of information that needs to be present in an email.

So, I dug into ActionController::TestCase’s assert_select_email to see how I can duplicate it for my unit test. Here is what the original method looks like:

# [rails]/actionpack/lib/action_controller/assertions/selector_assertions.rb
module ActionController::Assertions::SelectorAssertions
  def assert_select_email(&block)
    deliveries = ActionMailer::Base.deliveries
    assert !deliveries.empty?, "No e-mail in delivery list"
    for delivery in deliveries
      for part in delivery.parts
        if part["Content-Type"].to_s =~ /^text/htmlW/
          root = HTML::Document.new(part.body).root
          assert_select root, ":root", &block
        end
      end
    end
  end
end

As this implementation depicts, it is interesting to see how easy it is to take any html code snipped and create an HTML::Document out of it so that assert_select can be applied to it. Anyway, the default implementation for assert_select_email assumed multipart email with one or more parts in it. Since my email are simplistic text/html rendered as email body, I hacked to get what I needed. As follows:

class MortgageBorrowerEmailerTest < ActionMailer::TestCase
  include ActionController::Assertions::SelectorAssertions
  def assert_select_with_string(html_text, &block)
    root = HTML::Document.new(html_text).root
    assert_select root, ":root", &block
  end
  ...
end

With this in place, I could now take my email response’s body and assert-select on it:

should "share mortgage with existing client" do
  ...
  assert_select_with_string(response.body) do
    assert_select "h1", :text => "Greetings from Lendable"
    assert_select "tr#sender_identity td strong", :text => @realtor.full_name
    assert_select "tr#rate_search_criteria" do
      assert_select ".purchase_price"
      assert_select ".loan_amount"
    end
    assert_select "tr#rate_info td a[href=?]", "http://#{DEFAULT_HOST}/rate_selections/#{@rate_selection.id}",
      :text => "#{@rate.program.type_and_term} Mortgage at #{number_with_precision(@rate.rate, :precision => 3)}% from #{@rate.program.lender.name}"
  end
end

As we can imagine, this assert_select_with_string() can be useful in testing helper methods that return html snippets. I am not sure what the downside is for testing email body format as unit test vs. funcational test but I am happy that I can test it in isolation as unit test.

Do you know of any?

Share/Bookmark

Yes, we did. And here’s why.

I was at a recent social gathering where we started talking about how funny and bizzare it is that people use twitter to post messages like .. sh**, woke up late .. having lunch at Gino’s East … driving to work … my dog peed on my bed … . .. Oh ok, that last one is probably out of thin air but posting those kinds of messages probably don’t add much value for anybody, the author or the readers.

To test the waters, I created an account about 6 months ago. Very quickly I realized that twitter fills in a void that none of the other communication tools do.

Keep in touch, I mean real touch:
We don’t make it a point to write email to every single one on our list of 200 or 500 contacts every once in a while. Why? Because you will have to walk down the list, write to each person individually. We would have to come up with something to talk about that this person might be interested in. Too much work. But we still want to peek into their life and vice versa to find out if there is anything that interests both of us. Twitter fits the bill. You tweet (by definition, short) about anything that touches your life. If the other person is interested in you, he/she will follow you and vaguely peruse over your tweets. You do the same and follow him. Even if you no longer meet each other (because one of you has moved to different city or different job), you can talk to each other over this channel. If everybody in my group did this, I’d be fully aware of what happens with them on a day by day, hour by hour basis without actually calling them up. And vice versa.

Another great advantage that isn’t apparent at first is that twitter allows me to follow person who I am not associated with directly but what he does has a large impact on my life. Since I am programming in Ruby these days, I want to know what ruby gurus (@dhh, @wycats) are upto each day. If you are a java programmer, you may want to follow RodJohnson. These guys (I thank them) tweet few times a day and knowing that DHH and his team is upto each day is huge… it is gold mine!

Mass conversation:
Twittering is like sitting at a bar with folks that share your interests and talk about interesting things, just that it happens in a very loosely coupled way. All the same conversation rules apply. You want to be having light and funny yet intelligent conversation without having to invest the time to walk to a bar. And you can be in multiple bars at the same time. It doesn’t replace the bar meetups but it does make it easier to have more of those in our daily life, a good thing isn’t it.

You are never alone, even when you are alone:
We always had internet to keep us busy surfing and killing time when alone. One problem with plain vanilla internet surfing is that you have manually visit several websites to dig relevant pieces out that are important to you. Twitter makes it easier to subscribe to channels (people or companies or search tags) that are relevant and in very short message bursts gives you lots of superficial information. This is great for quickly perusing on channels and then dig deeper into stuff that interests you. With twitter account and a smartphone, those 5 minute wait at bus station, 10 minute wait at restaurant could be good investment in keeping in touch.

Books, Articles, Blogs and now Twitter:
We couldn’t write books every month, so we started writing articles. We couldn’t write articles each week, so we invented blogs. We can’t write blogs every day, so we have twitter. It is just a very low cost way to get the message across.

After using it for a while here are some things I learnt as far as twitter etiquettes are concerned:

Keep audience engaged:
My leg is hurting … nice weather … are boring tweets. They don’t initiate interesting conversation. Instead what I’ve found useful is to post an opinion on some news you just heard. Or some article, blog that you came across or commenting on a live TV cast of Presidents’ speech. Ask quick yes/no type questions although not always. Talk about pair programming .. how about twitting a quick question to you programmer colleague on how to solve a pesky problem? beat that!

Post often but not too often:
Posting 15, 20, 30 tweets a day on an account is good. Anything more is annoyance and you run the risk of loosing your followers. Posting less isn’t good either. It isn’t blog or article after all. Its purpose is to keep in touch … how about a tweet an hour on average.

Have separate accounts:
You need separate accounts to match each of your personalities. By personalities, I mean you are a professional at work, music rockstar in your school circle and lazy bum in your family circle. Sometimes the differences in these personalities are so stark that you don’t want to mix those. For example, my mom and sister will have no interest what so ever in my ruby programming tweets. However, my colleague at work aren’t really interested (much) in my hindi movie reviews and cricket fan club conversations. Having separate accounts keeps things simple.

All in all, the concept of twitting is here to stay!

Certainly, a great innovation. Does twitter.com hold a patent for this

Share/Bookmark

acl9 is a an authorization library for rails applications. It is one of the widely used library if not the most widely used now. Our experience with acl9 shows that it might be heavy weight if your authorization needs are simpler (which most projects are) but could be useful for other projects.

If you’ve used acegi/spring-security for authorization in your java apps, you know that acl9 is very similar in principle and hence very powerful. In addition to primary roles, it provides object level permissions which are stored in a generic way separately from the objects being controlled, all without the need for handcoding/distributing your authorization columns in each authorization-object tables.

One place where acl9 differs from acegi is how it doesn’t differentiate between a role and a permission. Acegi signifies roles as global permission level which allows you to do certain things (some action on any object of a given class). Where as, a “permission” controls whether your can take that action on a certain object of a class or not. Acl9 calls them all “roles” (primary-roles and object-roles). As you can imagine, a given user may have a few roles in system but end up with lot and lots of permissions in system depending on how many objects user owns etc. This may seem like good idea at first but it presents a unique problem which is not apparent at first. Since roles and permissions are not conceptually separate in acl9 – and that a user can have lots of them (few roles and lots of permissions) – prevents us from loading and caching them in memory. Why do we need to keep them in memory? Because you are querying user’s primary roles most often in your rendering of pages.

For example, consider navigation-bar which is common in most applications. Different users are presented with different tabs in navigation-bar and this bar gets rendered on each request/response cycle. Whether to render a particular tab is conditional to whether a user has certain role (primary role in particular) or not. Since acl9 cannot keep all roles (and permissions) in memory, it has to perform database query every time it has to find whether a user has_role?(admin) or not. Given that there can be only a few primary-roles that the user will have in any system, it seems in-efficient to not cache them and go to database each time.

The solution would be to separate these primary-roles from permission-roles and cache them for each request. In acl9 this means overriding User.has_role? and user.has_role!.

class User
  def has_role?(role, object = nil)
    if object || !Role.primary?(role)
      super
    else
      primary_roles.collect(&:name).include?(role.to_s)
    end
  end

  def has_role!(role, object = nil)
    super
    @primary_roles = extract_primary_roles if(Role.primary?(role))
  end

  def primary_roles
    @primary_roles ||= extract_primary_roles
  end

  def extract_primary_roles
     self.role_objects.select { |r| r.primary? }
  end
  private :extract_primary_roles
end

That does it. You cache the primary-roles and leverage those for has_role? queries.

Share/Bookmark

Sphinx (and its rails plugin thinking-sphinx) is my choice of search engine on ruby/rails project. It is powerful yet super easy to setup.

However, testing Sphinx code is not easy at first. Since Sphinx works by leverging database commit hooks, it cannot be tested within the bounds of unit testing framework that rails provides. This is understandable because, in rails testing, a transaction is started before each test that is bound to rollback after the test is finished. Since the test data is never committed, sphinx doesn’t get a chance to index anything and cannot be tested.

The documentation for sphinx testing suggests using cucumber for integration testing. To me, cucumber test are still miles away from the smallest piece of sphinx code (inside Model) to be tested. So, I turned to how transactional code is tested in rails framework for some cue.

Here is what I ended up with:

class TransactionalUserTest < ActiveSupport::TestCase
  // any transactional test needs to have this
  self.use_transactional_fixtures = false

  context "with no users in database" do
    setup do
      // clear the existing data for our test - not sure if this affects other test but we use machinist instead of fixture files, so we should be good here.
      User.destroy_all
      UserProfile.destroy_all
    end

    context "with a few users created" do
      setup do
        @john = @david = nil
        // any data for sphinx test should be wrapped in transaction so sphinx can see these changes
        User.transaction do
          @john = User.make(:first_name => "John")
          @david = User.make(:first_name => "David")
        end
      end
      should "find user with first name john" do
        // start sphinx server
        ThinkingSphinx::Test.run do
          // give sphinx an opportunity to index newly added data (required before calling search)
          ThinkingSphinx::Test.index
          assert_equal([@john], User.search("john").collect)
          assert_equal([@david], User.search("david").collect)
          assert_equal([],User.search("cheese").collect)
        end
      end
    end
  end
end

Isn’t it nicer to be able to test sphinx code in isolation

Share/Bookmark

Fixtures are notorious in rails. To get around issues like brittleness and multiple file flipping to understand single test, there have been better approaches using gems like fixture_replacement, machinist and factory_girl. No complains there. In my experience, fixture are still great for one thing: loading seed data. This is because seed data is often used by many many tests and they don’t change often and hence won’t cause tests to be brittle. Another great advantage of fixtures is that any fixture data is loaded once and only once for the entire test run.

Rails 2.3.4 includes a new rake task for loading seed data called db:seed. It suggests keeping all seed data as a ruby code inside of db/seeds.rb file. The issue with this is this is not DRY. You have duplicate set of representation for seed data: one side of seeds.rb and one in fixture files (.yml). Keeping them in sync is a pain and all the other disadvantages that come with not having single source of truth.

Problem

To have single source of seed data and be able to load that seed data once and only once for the entire test run.

Solution 1: Use Fixtures:

Advantage: Fixture are ideal since fixture files (.yml) get loaded once and only one before the tests start running.

Disadvantage: requires duplicating seed data that is already coded in db/seeds.rb into .yml files. We might try to get around this by having another rake task that converts data inside seeds.rb into .yml files or vice versa. In any case, it feels like a hack.

Solution 2: Load seeds.rb as part of test

# test/test_helper.rb
module TestHelper
  def load_seed_data
    load File.dirname(__FILE__) + '/../db/seeds.rb'
  end
end

class ActiveSupport::TestCase
  include TestHelper
end

Advantage: loads the seed data from same seeds.rb and eliminates duplicating them into fixture files (.yml).

Disadvantage: load_seed_data has to be called once before each single test and data is loaded and discarded as part of each test. This impacts test runs greatly and is not scalable as codebase and hence tests grow.

The Solution: call db:seed as part of db:test:prepare

Rails executes db:test:prepare when tests are run. This solution entails adding a hook to run db:seed as part of this. This ensures that the seed data from seeds.rb is loaded before the tests start. One caveat here is disable fixture loaded by deleting all .yml files, otherwise it will delete the seed data loaded here.

namespace :db do
  namespace :test do
    task :prepare => :environment do
      Rake::Task["db:seed"].invoke
    end
  end
end

Advantage: Re-uses seeds.rb, loads seed data into test database only once for entire test run

Disadvantage: none so far.

Caveats:

• While running individual tests or test files (as part of invoking test from inside IDE), we need to ensure that test database is already loaded with seed data. This can be easily done using “db:reset” rake task on test environment.
• The .yml files have to be deleted from test/fixtures folder. If any .yml file exists, rails will delete the data from the table corresponding to that file as part of test setup. This will happen even if the file is empty and does not contain any seed data.

Clean and DRY. That feels good.

Share/Bookmark