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.

The Transaction Script Pattern

I recently called upon the services of the Transaction Script pattern to organise new business logic for my current software project. I had a bunch of procedural and database-centric logic to implement and needed a way to structure it so that it would be maintainable. I appear to have chosen a reasonable solution, because this pattern has helped me create a simple design that, so far, has proved easy to work with. I also ended up with code that is more readable than I could have hoped for. Go me!

The Transaction Script pattern is as simple as they come. It organizes multi-step business logic into discrete procedures with each procedure implemented either by a single method, or by a group of methods within a dedicated class. The pattern takes its name from the fact that most often a procedure will be executed within the scope of a single database transaction.

Martin Fowler presents the Transaction Script pattern in his book Patterns of Enterprise Application Architecture and it is also catalogued on his site.

In adopting the pattern for my own code, I opted to give each procedure its own class, a la the Command pattern / Object Method refactoring. I think that this decision has been central to my success with the Transaction Script pattern.

I found that partitioning the procedures into their own dedicated classes made for rapid progress, because it facilitated ‘coding by intention’ and refactoring. I was able to decompose each procedure into a set of small and cohesive methods that found a natural home within the class implementing that procedure. These methods could thus share state via instance variables, which removed the need pass data around. Where logic was duplicated across procedures, I found that I was able to extract the duplicated code into a method and pull it up to the base class.

I’m very happy with how it’s playing out so far, but it will be interesting to see the long-term maintainability of this design.

WTF?

If you're a Software Developer, or you work with developers, then you'll probably get a kick out of The Daily WTF, a look at "Curious Perversions in Information Technology". I came across the site a few weeks back and became hooked. I read it every day with my morning coffee (I find it's best not to attempt to drink the coffee until after you've read the post).

A Blog is Born

Well I've done it now! I've created a blog. A chain of events has been set in motion that can lead to only one of two outcomes. Either: a) I'll become famous and have riches beyond measure, or, b) I'll experience abject public humiliation and be forced to slink back into the shadows. Okay, so maybe these aren't the only possible outcomes.

So why have I to created this blog? Before embarking on this project, I did some brief Googling into motivations for blogging. I wanted to understand why I was attracted to the idea of writing a blog. I discovered that I fall squarely into the 'Blog as Muse' camp, which sees blogging as 'thinking' through 'writing'. I look at blogging as an opportunity for me to stop and think on a regular basis. Hopefully, sometime in the future I'll be able to look back at my collected musings and see how my thinking has evolved.

What will I be writing about? Well, I'm a Software Developer and I tend to think quite a bit about the practice of my trade. For the last few years I've been learning about Agile Software development - mostly in the form of Extreme Programming (XP) - and how Agile techniques can improve the chances of success on software development projects. I expect this blog will have a fair amount to say on my experiences of software development and agile methods.

No, wait! Come back! I'll throw in some other stuff, if you promise to hang around.