In the recently released application, one of the most consistent exceptions we received was an “ActionView::TemplateMissing” exception because someone or something was hitting the following URLS.

The logical decision was to rescue these exceptions in the ApplicationController itself and serve the generic 404 page. So initially, we had a simple rescue block:

rescue_from "ActionView::MissingTemplate" do |exception|
  respond_to do |format|
    format.any {
      render "error_pages/404",
        :status => :not_found

This kept causing a TemplateNotFound exception because even though we were trying to respond to any format, it was still expecting the 404 template to exist in a zip or xml format. Having a symlink as 404.xml.erb or also is a bad solution because the expectation of the format is cascading i.e. any views rendered within the 404 would also be expected to have that format, and generally thats a bad idea. So I decided to simply override the request format in this particular case and save myself the trouble. Hence:

rescue_from "ActionView::MissingTemplate" do |exception|
  request.format = :html
  render "error_pages/404",
    :status => :not_found

Recently a colleague of mine showed me how to find out what environment variables a process is using at the time its running. This works on Linux but not on OS X.

Find out the PID for the process you want to inspect

[@riyadh:~] $ ps -ef | grep mysql
mysql 1142 1 0 Jul06 ? 00:00:24 /usr/sbin/mysqld

Then its a simple step of catting the environ section of proc for that PID which in this case is 1142

[@riyadh:~] $ sudo cat /proc/1142/environ

On OS X, you can get information by using:

[@riyadh:~] $ ps -Eww $PID

Be warned, this gives you a lot more than just what environment variables that process is using.

So yesterday, I was trying to do a simple MySQL query and realised that the value I wanted was of type text and the field I wanted was actually in the middle of the string and not always consistently there. So I decided to write up a script for myself which would do the DB query and then parse the string returned. As I had not done python for sometime, I decided to write it in python.

First things first, all I did was import MySQLdb. Nothing! Wasn’t installed. Fair enough. I had never had to previously install a python module, so I went to sourceforge and obtained the source, built it and it ran. That got me thinking, why do I have to do this myself?

I tried using go and even with the same import (mysql;), I needed to download the mysql module from google code and build it with the 8g and 8l binaries and then have a crack at it. Why am I still building these ???

If I wanted to do this in Ruby, I could use the gem installer and simply do a gem list -r mysql to find out which one was available and then do a simple gem install mysql-X.Y. No need to build. Installed and ready for use.

I like python and go a lot, but I believe for simplicity of use and for mimicking the behaviour of apt-get, ruby wins this one.

Of the languages that I have used in my professional career, Ruby is the one that makes testing easy and fun. It has an easy to understand testing framework and mocking out external classes, most of the time, is very simple. For example:

class Sauron
__def wants
____"the ring"

def Gandalf
__def wants

class MiddleEarth
__def who_wants_what
____if (Gandalf.wants == peace and Sauron.wants == "the ring") then
______return "war"
______return "peace"

Lets say that we have to test out Gandalf or Sauron.
Gandalf.wants.should eql "peace"
Sauron.wants.should eql "the ring"

The above test code is called RSpec and is very simple and easy to understand. Whether it is a Business Analyst or a Project Manager or even your mother, she can fully understand the required behaviour or Gandalf or Sauron.

But what if we had to unit test MiddleEarth? Then we would have to mock Gandalf and Sauron together and alternately to test all code paths. RSpec makes that easy.
Sauron.should_receive(:wants).and_return("something else")

If either method of either class expected arguments, that too we can deal with.
Sauron.should_receive(:wants).with(something).and_return("something else")

So there you go, testing and mocking made inherently easy with Ruby and its testing frameworks. But how does it compare to the old language of Perl. Perl too, now has a very similar testing framework to RSpec, called Test::Expectation. And for mocking out external influences when unit testing, we have Test::MockObject and Sub::Override.

And if we wanted to business test in either language, cucumber can sit on top of both, although inherently it works much more readily with Ruby/RSpec.