Blog of Jonathan Jaikoo Conway, web technologist, entrepreneur and daddy.

When it comes to a Rails or a Merb app I like to make sure there is a clean separation of concerns. One of the ways I do this is modularising the behaviour of an object into mixins.

For example, a movie object might need some logic that relates to video transcoding. Rather than have this explicitly part of the main class I move it into a mixin, this for me makes code that is:

• easier to read
• maintainable
• testable
• reusable

Of course like everything this requires thought and I’m careful not to go mad with this pattern as the last thing I want is something that resembles the old EJB 2.0 madness where all the business logic was contained in other service objects and all that’s left is an anaemic model in which you need an IDE like Intellij to discover what on earth is going on and where.

When it comes to constants I’ve noticed a few people extolling the virtue’s of putting constants in the environment.rb (dev/test/production) as an easy way of having globally accessible constants. This in my opinion should be avoided at all costs if possible.

Instead I favour putting my constants in either in the model that they relate to as this increases readability and stops pollution/collisions. Or my current favourite method is to group the constants up by context into their own yaml files and have them loaded and accessed from a module. It still keeps my models clean while still keeping my code readable and more maintainable.

For example something like this:

module Tasks
   module Config

    def self.message_queue_ip
      @@message_queue_ip ||= YAML.load_file \
       ("#{Merb.root}/config/tasks_conf.yml") \
        [Merb.environment]['message_queue']
    end

    #Rest of your constants....
   end
end

#Add access it with 
Tasks::Config.message_queue_ip

Of course this is a trivial example but you see how it automatically loads the correct value based upon the current environment without any conditionals. Yep, it’s all pretty much common sense but I still seem to always get handed apps that don’t follow simple rules of good OO design.

It looks like quite a few of us UK Ruby guys are going to be at Euruko in Prague this coming weekend which should be fun. I’ll be flying out this Friday around 13:45 on an Easyjet flight from Stanstead with Peter and Jamie.

I’ve also heard that all the bamboo’ers are going to be there which will be fun to catch up on old times. If you’re going to be at Euruko it’ll be good to chat and have some beers!

I got an email this morning asking how to daemonize RabbitMQ when running with the STOMP adapter. It’s pretty simple really, all you need to do is add ‘-detached’ to the RABBIT_ARGS in the makefile.

start_server:
    $(MAKE) -C $(RABBIT_SOURCE_ROOT)/erlang/rabbit run \
        RABBIT_ARGS='-pa '"$$(pwd)/$(EBIN_DIR)"' -rabbit \
            stomp_listeners [{\"0.0.0.0\",61613}] \
            extra_startup_steps [{\"STOMP-listeners\" \
                        ,rabbit_stomp,kickstart,[]}] -detached'

So a few weeks ago I unfairly called RabbitMQ complex without clarifying why. When it comes down to it there’s nothing hard about getting up and running with RabbitMQ especially these days with the Stomp and HTTP adapters out there. However the one sore point that a lot of Ruby people have when I recommend this fine messaging machine to them is that there isn’t much documentation on getting up and running with Ruby. Well, there’s nothing more pathetic than a man who grumbles but doesn’t do anything about it and so as promised I made a screencast. It’s actually based of the excellent RabbitMQ and Stomp tutorial that can be found on Lshifts great blog. Of course I altered it to have a bit of a Ruby twist with a really simple Rack/Merb version of hello world.

Well I’m still nursing a hangover this morning after a few too many fine beers and champagne that was to be had at Pizzaonrails last night. It was good to see everyone last night…