Jarre's 'Laser Harp' Sound for Propellerheads Reason

Those of you familiar with the music of Jean Michel Jarre will probably have heard, and possibly seen, his Laser Harp. It's a crazy instrument played by passing the hands through laser beams. The Laser Harp has been a feature at many of his concerts over the years and while it's mostly for show, I've always loved the sound, which is generated by an Elka Synthex synthesizer.

I set about recreating the Laser Harp sound in Propellerheads Reason, using Reason's Thor synthesizer and a few supporting effects. I'm very happy with the results and thought I'd share them.

If you have Reason Version 4 or higher, you can download a copy of the Reason patch here. If you can improve upon it, then please let me know.

Have fun.

Mac OS X Java Update breakage.

I just knew I shouldn't have let Mac OS X apply the recent Java update. Just a couple of days after the update I had reason to upgrade the rjb ('Ruby Java Bridge') gem. The upgrade process exploded in my face with the following error:

checking for jni.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

The problem appears to be missing Java supporting sources that the most recent Java update removed. Luckily, I found the solution over at the nicely named Kick me in the nuts blog. For your convenience here are the magic incantations:

Step 1: Go to http://connect.apple.com and download and download Java for Mac OS X 10.6 Update 3 Developer Package. You'll need a registered Apple Developer account, but it's free.

Step 2: Install it.

Step 3: Open a Terminal.app window and type:

sudo -s
cd /System/Library/Frameworks/JavaVM.framework/Home
ln -s /Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/src.jar .
ln -s /Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/docs.jar .

After the above, developer calm should be restored.

Using StormMQs Messaging Cloud with Ruby

A little while back I was asked by Ross Cooney of StormMQ to write a Ruby client for their enterprise class managed message queueing service. It was a fun little project. The client code is open source and is hosted on GitHub and we've also published it as a gem for easy installation. What follows is a tutorial explaining how to get up and running with StormMQ's service using the Ruby client.

The first thing you'll need is an account with StormMQ, so head on over to their site and register. Registration is free, non-binding and gives you access to the free cloud based message queue service.

Next you'll need to install the Ruby client. The easiest way to do this is via the gem. Open a command line and type:


gem install stormmq-client


This will install the client and its dependencies on your system.

For this tutorial we're going to write some simple code to publish a test message to a queue and then read it back. Since message queues are most often used to build loosely coupled systems that communicate asynchronously via one of more queues, we'll separate the publisher and consumer of the test message by writing each as an independent script.

Let's start with the publisher. Launch your favourite text editor, or IDE, paste in the following code and save it as 'publish.rb':

#!/usr/bin/env ruby

# Before we can call the client we need to require it!
require 'rubygems'
require 'stormmq/amqp'

# For convenience we'll create a hash of the required connection options.
client_options = {
  :user        => 'my_username',
  :pass        => 'a_very_looooooong_password',
  :company     => 'my_username',
  :system      => 'my_username',
  :environment => 'development'
}

# Connect to the AMQP service using the options configured above. 
# Note, the run() method creates the connection and executes
# the code in the block. When the block terminates, the connection
# is closed.
StormMQ::AMQPClient.run(client_options) do |client|

  # Declare a queue on the exchange
  queue = client.queue('test1')

  # Publish (submit) our test message to the new queue.
  queue.publish('Hello World!')
end

The above code will open a connection to StormMQ's service, using your account details (you did use your account details, right?). It will then declare a queue called 'test1', publish the traditional 'Hello World' to the queue and close the connection.

Run it from the command line with

ruby publish.rb


That's all well and good, but let's see if we can re-connect to the queue and read the message from it. Returning to the text editor or IDE, open a new file and paste in the following:

#!/usr/bin/env ruby

require 'rubygems'
require 'stormmq/amqp'

# Use the same settings as before
client_options = {
  :user        => 'my_username',
  :pass        => 'a_very_looooooong_password',
  :company     => 'my_username',
  :system      => 'my_username',
  :environment => 'development'
}

StormMQ::AMQPClient.run(client_options) do |client|
  queue = client.queue('test1')

  # Read the message from the queue and display it.
  puts queue.pop[:payload]
end

Save the new file as 'subscribe.rb' and run it as follows:


ruby subscribe.rb


All going well, this should print 'Hello World!' on screen. Congratulations! You've just written your first code to talk to an enterprise class message queuing system.

The Ruby client is actually a thin wrapper around the Bunny library, which is an AMQP compliant ruby client. My contribution provides the extra bits needed to support StormMQ's virtual host configuration. My client is also a REST client for StormMQ's configuration system to allow customers to manage their systems. We'll take a look at the REST component of the client in a future blog post.

Rails foreign key assignment and belongs_to associations

I keep getting bitten by some odd behaviour in the way Rails handles assignment to the foreign key attribute of a belongs_to association. Specifically, assigning the foreign key id directly, as one might do when processing a form submission with mass attribute assignment, only works for new records or records where the belongs_to association has not already been loaded.

There's a long-standing ticket for this issue here, but little progress seems to have been made in resolving it.

Frankly, this is a pain in the ass. I wasted a ton of effort on trying to workaround this problem, finally resorting to monkey patching ActiveRecord, which then broke when we tried to upgrade our application to Rails 2.2.2.

On another trip on the merry-go-round this morning, I got lucky and finally spotted a solution that I'd missed before. While others were debating the merits / demerits of various patches and whether all cases were adequately covered, Matt West who opened the ticket, provided a fix in the form of a plugin:

http://code.torchbox.com/svn/rails/plugins/belongs_to_synchronisation/

Unfortunately, it was hidden in a blog post linked from the ticker. See the original blog post here.

How not to implement a web service using SOAP.

Twice in the last six months, I've been faced with implementing a client for a SOAP-based web service. On both occasions there's been a distinct lack of sunshine and rainbows.

After the initial optimism ("this should be easy - it uses SOAP") faded, things went downhill fast. It's an anti-pattern that I expect to see again soon.

The initial exploratory exchange for getting two systems talking over web services, typically goes something like this:

Our Business People: "We'd like our Fobniculator system to be able to talk to your FooBarWidget web application so that going forward we leverage the synergies to bring about a positive sales variance."

Their Business People: "Sure! We'll get our nerds to talk to your nerds."

Some considerable time passes...

Me: "What platform is your FooBarWidget web application built on?"

One of Their nerds: "VB.NET. What about your Fobniculator system?"

Me: "Ruby on Rails."

One of Their nerds: "That's okay! Our web service uses SOAP. SOAP is platform and language independent and is great for interoperability. Oh, and our interface is so simple. I'm sure Ruby on Rails can talk SOAP?"

Me: "It sure can! Ruby on Rails prefers RESTful web services, but SOAP will work. This should be very easy, I'll be done by lunch. Hey! Talk to me a bit about the interface that allows us to update a FooBarWidget's data."

OoTN: "No problem. You call the FooBarWidgetUpdate() method and pass an instance of a .NET DataSet containing the data for the FooBarWidget."

Me: "Um, in what way is that platform independent?"

Awkward silence...

OoTN: "What do you mean? It's SOAP ain't it?"

Please, if you are going to tie your web service to .NET by using proprietary objects that shun the platform independence of SOAP, then please don't pretend that you are doing the rest of us any favours.

Acceptance Testing in Ruby

I'm teaching myself Ruby with the help of a 'toy' project. Sometime ago I wrote PerlActor, an Acceptance Testing framework that was inspired by Exoftware's Exactor open source project. I thought it would be educational and fun for me to port my Perl effort to Ruby. I've made good progress to date and I've learnt a lot about Ruby along the way. However, a question arises: Is an Exactor / PerlActor style testing framework useful for Ruby projects?

Exactor and PerlActor express tests in a simple language specific to the domain under test. They take an approach similar to FIT, but with test cases stored in simple text files, rather than embedded in HTML tables. By way of an example, a typical PerlActor test, in this case for a web application, might look like the following:


NewUserAgent
GoTo http://www.google.com/
PageTitleShouldContain Google


'GoTo','NewUserAgent' and 'PageTitleShouldContain' are commands, which are domain specific and either provided by the framework or implemented by the user of the framework. Exactor comes with a library of such commands. PerlActor is more basic, with the supplied commands really just being examples.

IMHO, a big selling point of this approach to testing is the customer-friendliness (in the Agile sense) of the tests. The test cases are very readable and it's possible for customers to write their own acceptance tests without needing to learn a complex syntax.

With Ruby's excellent support for meta programming, it may be possible to express such tests in Ruby code, while keeping the syntax as clean as the above. I'm not sure how to acheive this level of simplicity in Ruby and so I would be interested in hearing your opinions.

Ruby Ireland

Ruby is a fascinating language whose star is rising thanks to the buzz being generated by the Ruby on Rails web development framework. I've been itching to try Ruby on a real world project for quite some time, but alas the day job is stubbornly Perl-centric.

To get a much needed Ruby fix, I attended my first Ruby Ireland Group meeting last Tuesday at the Morrison Hotel in Dublin. The turnout was good with about a dozen folks in attendance. I thoroughly enjoyed the two presentations and the followup nosebag in the nearby La Taverna di Bacco.

Olivier Ansaldi gave us a whirlwind tour of Why The Luck Stiff's Camping web framework, which manages to be both very weird and very clever. David J Rice scared us with his plans for world domination using an army of Giant Robots controlled by Distributed Ruby (Drb) code.

The Ruby Ireland group plans to meet on the 2nd Tuesday of every month in the Morrison. If you have an interest in Ruby and related technologies then come along a take part in the fun.