Install Ruby using the One Click Installer.
Install the ODBC module (by copying the SO files into the c:\Ruby\1.8\i386-mingw32 folder).
Install the ActiveRecord ODBC adapter (gem install activerecord-odbc-adapter).
Edit C:\Ruby\lib\ruby\gems\1.8\gems\activerecord-odbc-adapter-2.0\ lib\active_record\connection_adapters\odbc_adapter.rb – look for line 1588.
Change the line from elsif dbmsName =~ /SQLAnywhere/i to elsif dbmsName =~ /SQLAnywhere/i or dbmsName =~ /adaptiveserveranywhere/i

Write some test code – something like:


require 'rubygems'
require 'active_record'

Whatever.all

Run this - hopefully you should get no errors.
Then sit down and have a long think about what the hell you are doing.

But the weirdest thing was we couldn’t figure out the cause. Well I could see why the code was failing (after adding some extra log messages). But ‘git blame’ said those lines of code were unchanged in twelve months. Why hadn’t people complained before? Why hadn’t we noticed it?

After much hunting through log files we found the point when the feature last worked. It coincided with a deployment. That deployment was our Rails 2.3.4 forms vulnerability fix. And the bug was in a form – a missing form parameter that earlier versions of Rails ignored, the newer Rails was choking on.

But why didn’t the tests catch it?

After more hunting I saw that the Cucumber test that exercised the form didn’t have a “When I press the Update button” step. And the subsequent tests were passing, even though the update button hadn’t been pressed.

So I added the step in and made the feature pass. Then deployed it as an emergency fix.

However, what are the lessons to learn here (as there are always some)?

• Firstly, testing cannot catch everything.
• Secondly, the cracks in your tests are where the bugs are.
• Thirdly, we probably need some sort of peer review for tests. I feel that this is more important than for code, because once the tests are right you can refactor the code without worry.
• Fourthly, you really need to log everything. Absolutely everything. Don’t worry about your huge log files – that’s what `logrotate` is for. Get it written down so that one time when you have an obscure bug, you’ll be able to find it easily.

I have no idea who he is or why he’s gone. But _why meant a lot to Ruby developers, myself included. He represented style and grace and art and weirdness – that Ruby was about more than just getting the job done in the most efficient way possible.

He had a class, descending from ActiveRecord::Base, with a custom constructor (initialize method). To debug it, he had the constructor raise an exception. In the console, Thingy.new(params) raised the exception as expected. But wotsit.thingies.find_by_field(value) did not. Even though it was instantiating an instance of Thingy and returning it.

“It must not be calling the constructor” he said.
“Rubbish” said I, “it’s a constructor. Constructors are always called. That’s the point of them”.

But as he dug deeper it certainly looked like the constructor wasn’t being called.

And then he found an article explaining that you should never rely on things being set up on in an Active Record constructor. Mainly because Active Record uses allocate to instantiate associated objects. And what is this mysterious allocate? Why explains it all.

To be honest, I’ve got mixed feelings about this. I can see the use of “allocate” – why’s example of marshalling an object makes sense (I’m slightly less sure about the way that Active Record uses it to load associations). But, to my mind, the definition of a constructor is “the code that is always called when an object is created”. So maybe I should just stop thinking of initialize as a constructor and more as an initialiser.

I’m going to change the tools that I use to code in Ruby for the first time in four years. You see, I must be one of the very very few Ruby-programming Mac-users that doesn’t like Textmate.

This is pretty much heresy to most Rubyists.

I used to think I didn’t like Textmate because of the single window interface. Multiple windows could be positioned exactly where I want them (that window only has a couple of lines in it so I can keep that tiny and see both that and that other file at the same time). Tabs are all the same size for each file and you can’t keep them arranged as you want them.

But then I bought the MacHeist bundle. And got a little web-developer’s editor called Espresso. I really like MacRabbit’s CSSEdit so was looking forward to trying Espresso. And like it I did. I even got over my tabbed interface problems (maybe nicely styled tabs with a list view beats ugly tabs with a drawer). But there was a problem. Espresso is crap for Rails development (despite Elliott Cable’s ruby “sugar”).

So, having been spoilt by an “integrated” editor, but still not liking Textmate, where could I go? Coda, by Panic, was where. And I have to say I really like it. It’s not perfect, it’s taken me about a week to get my head round how things hang together. But it deals with ruby and rails and is extensible.

Which is enough to make me shell out the $99. And change the way I work pretty fundamentally.

So, we at Brightbox have just launched http://isitruby1.9.com; a community site that lets you mark gems as working or not.  It’s quick and easy and will really help people out so please test your favourite gem, then stop by and record the results.

But where does MVC come from?

Well, like most things I enjoy in the world of software development, MVC has its roots in Smalltalk. However, things used to look slightly different to the MVC we know and love. In Smalltalk, the basic Object has a feature known as “dependencies” built-in; nowadays, we would call this the observer pattern. Basically, any object can register an interest in any other object and will be notified whenever the target changes.

target addDependent: listener.

Later, when something changes within target, it can decide to notify all its dependents (observers):

self changed: #SomeArbitraryMessage.

and the listener has its update: aSymbol method called.

Building this notification mechanism right into the core of the system means that it can be used everywhere – especially when designing user-interfaces (remember, Smalltalk was the GUI for the Xerox Star, which his Steveness bought and adapted for the Lisa). Models were the system components, the pieces of the system that actually do the work. Views represented portions of the screen and controllers represented the keyboard and the mouse. These parts were arranged as follows:

MVC in Smalltalk

The view would add itself as a dependent to the model and display the relevant aspects of the model on-screen. The user would see this, manipulate it via the mouse and keyboard, which triggers the controller. The controller sends messages to the model, which triggers its notifications, prompting the dependent view to redraw itself. In other words, the controller and view are independent objects that know nothing about each other – the only tie between them is the controller’s knowledge of the model and the dependency mechanism.

Contrast this to the MVC we know today:

MVC in Rails

Here the user pokes the controller, which in turn sends messages to the model. The model does its thing and then the controller extracts the relevant information and passes it to the view, which is then rendered to the user. In this manner, the controller lives up to its name, orchestrating the entire cycle – and is the centre of all the coupling (as it knows about the view and the model).

So why did things change (first in Smalltalk and then the following MVC frameworks)?

The first problem is that the controller takes input and the view handles output – as separate objects. Which, especially for desktop applications, doesn’t really work; if you click on a text-field you expect different behaviour to clicking on a scrollbar.

Secondly, imagine an array of models being shown in a list box. The list box has the concept of a current selection. So your array model (a model of models) needs to have a current selection, so that the view knows which is which. But what if the same list is rendered in two places at the same time. If you point both views at the same array model, they would both share the same selection properties. So you actually end up with something more like:

Getting Complicated

As you can see it gets nasty pretty quickly. And actually the controller is simply passing its messages directly through to the array model which is actually doing the routing of the other messages – the controller is pretty much redundant.

So if you swap things around, merge the controller and array model (into some sort of array controller) and then add multiple array controllers – one per view – to deal with the selection issue, suddenly you have the newer style object layout. Requests go into one of the controllers, it routes it to the model, then parcels up the results and invokes the view.

Evolution in action.

Firstly, a bit of history.

I first tried programming on a Commodore Vic 20, and then after that a C64. C64 BASIC was very simple – if you wanted to do anything beyond PRINT statements you needed to POKE values into registers and control the hardware directly. Great for learning how things actually worked. And, to be fair, I was shit at it.

But I do remember reading an article on a system called “Smalltalk” and its “Object Oriented Programming”. Suddenly, programming made sense. It read a bit like English. You sent messages to the thing that knows how to answer your question. It was like talking to people. You ask Dave a football question. You ask George a music question. Cos Dave knows crap all about music and George knows nothing about football.

But, in those days, Smalltalk cost a fortune; there was no way a child like me could get hold of a Smalltalk environment. So instead, I got hold of Turbo Pascal 6 With Objects (thanks Dad). It was not Smalltalk but it read a bit like English and it had objects. I played about with Turbo Pascal, went to university (where I didn’t do computing but did do some C++) and then got a job doing Delphi (Turbo Pascal for the 90s). This object-oriented stuff really worked for me; I put a lot of effort into writing classes that had really simple public interfaces and with code that read like English. And Pascal (the language underlying Delphi) was great for that. Then I discovered Java, which meant I could write Delphi-like code but with having to deal with memory management. I also discovered PHP, Python and Ruby. None of which clicked with me; dynamic typing made me nervous (and PHP and Ruby seemed a bit ugly).

However, I needed an ORM for a Delphi project and I thought I should try to copy an open source project. Whilst searching I discovered Rails and thought “this is the one to copy”. But a day into my “copy ActiveRecord into Delphi” plan I thought “this is just like Smalltalk”. Why make an inferior copy when I can use something that’s not far off the Holy Grail. Writing an application on Rails had the same effect on me as my original discovery of Smalltalk – it read like English, it felt fantastic. So I gave up on Delphi and became a Rails programmer.

What I liked about Rails was its emphasis on happiness. When I wrote Rails code I felt like I was writing beautiful prose. I would go back and refactor it until it read correctly. This was not like pure Ruby, which was often ugly. No; Rails had this idea about beauty in code that really got me excited. It made me happy. It also made decisions for me – put your code here, test it like this, set up your database this way. But Rails had performance problems – so Merb was born. A ground-up rewrite of many of Rails’ ideas but with an emphasis on configurability and performance.

Maybe it’s the Engine Yard connection (I turned Engine Yard down for a job because it didn’t “feel right”) – and now I work for Brightbox, one of their competitors – but for some reason, every time I tried Merb I just couldn’t get into it. It was weird. Structurally and functionally it was the same as Rails – but it was Rails plus performance plus options. And I didn’t like it. I never got past the tutorials. Merb emphasises clear and understandable code and was tested with RSpec (which I love). Rails is hard to understand and uses Test::Unit (which is ugly). But I love Rails and I can’t get into Merb. I just couldn’t figure out why.

Until today.

Mr Hanson did a blog post on his first piece of Rails-Merb integration. And something stood out at me. As he was describing Merb’s provides/display functionality I noticed that I didn’t really “get it”. provides made sense, but how does that relate to display. Mr H addresses that directly:

There were a couple of drawbacks with the provides/display duo, though, that we could deal with at the same time. The first was the lack of symmetry in the method names. The words “provides” and “display” doesn’t reflect their close relationship and if you throw in the fact that they’re actually both related to rendering, it’s gets even more muddy.

And then he describes the Rails 3 version of the same functionality. Instead of provides/display it becomes respond_to/respond_with. In particular display @users becomes respond_with @users.

It’s only a tiny thing. Logically and functionally, they are exactly the same. But DHH’s version has an emphasis on the words that are used. How they couple together (display/provide versus respond_to/respond_with).

And there is the reason that I was uneasy about Rails 3. What if Rails lost this emphasis on the human factors – how the words mesh together – in the search of performance. Merb is written functionally, Rails is written emotionally – Merb is about performance, Rails is about feelings.

But DHH has made me feel much better about Rails 3 – he has shown that he will take Merb constructs and Railsify them, humanise them. Because, although code is executed by computers, it is written, and more importantly, read by people like me.

If you find this useful then please take a look at some of my other writing – or recommend me on Working with Rails. Cheers.

So I’ve been reworking them all using RSpec, my fork of RSpec-Rails and my Object Factory (which means I can avoid fixtures).

Most of the work involves writing a spec that mimics the current behaviour (by inspecting the code and trying to match all paths through it), then refactoring the code, using the spec to prove that I haven’t broken it.

But some points have some really horrible code (and lots of it) within the controllers. As you probably know, Skinny Controllers is the Rails way – your application logic belongs in your models (as they are your application) – the controller should just find or create the relevant model, ask it to do something and then render the results.

Because of this, I opted to just rewrite the actions in question.

To do this I started by writing a Cucumber feature describing things from the user’s point of view. Actually writing the steps that match the feature was a lot of work; because Cucumber is a full stack test you have to deal with all the dependencies that your individual action has (for example, are you logged in with the correct permissions with all associated objects created and in the right state?).

Then I wrote a controller spec. Controller specs in RSpec should use mock objects; you don’t really want to test the models, you just want to prove that the controller finds or creates the right model, asks it to do something and renders the correct output at the end.

So a typical spec looks something like this (note that this is not RESTful as it was an existing part of the application that I am about to change):

  it "should process an item" do
    @item = mock_model Item, :work_type => :buy_stuff, :quantity => 2

    on_getting :process_item, :id => '1' do
     Item.should_receive(:find).with('1').and_return(@item)
      @stuff = mock_model Stuff
      @item.should_receive(:process).and_return(@stuff)
    end

    assigns[:stuff].should == @stuff
    response.should be_success
    response.should render_template('admin/orders/process_item')
  end

This basically says:

• We have an item, of type “buy stuff” with a quantity
• When the process_item action is called, we expect that the controller will try to find the item with the given id
• Then we should call process on the item and it should give us some stuff
• The stuff should be stored in an instance variable, called stuff
• And a page should be successfully rendered using the process_item template

That’s a pretty succinct explanation of what the controller should do – I can’t think of many ways of making that skinnier. It also bears no resemblance to the actual implementation of the action – which currently looks something like this:

def process_work_item
    @item =Item.find(params[:id])
    case @item.product.class.to_s.underscore.to_sym
    when :buy_stuff
      @stuff = Stuff.build_item(@item)
      @stuff.setup_new
      render :action => :process_stuff
    when :update_stuff
      @item.stuff.prepare_for_update
      render :action => :update_stuff
    else
      render :status => 404, :text => "Item product type #{@item.product.class.to_s} unknown."
    end
rescue ActiveRecord::RecordNotFound
  render_not_found
end

Pretty complicated – and as new types of item are added we need to add more and more clauses to that case statement.

First things first – I’ve said that we should call “process” on the item class. So I add a pending spec to the Item specification – this is to remind me that I’ve got some work to implement later on.

  it "should process itself based upon its work type"

Then I rework the controller so that the controller spec passes.

    @item =Item.find(params[:id])
    @stuff = @item.process
    render :template => "admin/orders/process_item"

Pretty simple huh?

What we have done is shifted the logic from the controller into this new “process” method on the Item. We have made it so that the controller knows virtually nothing about the item – all it knows is how to find it and that it has a process method. All the implementation details are now hidden within the Item, out of the way of the outside world.

Through the use of mocking we can ignore actual implementations and concentrate on presenting ourselves as simply, and minimally, as possible to the outside world. This reduces coupling, increases flexibility and makes our code easier to read. Don’t you agree?