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.

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?

It’s all about SEO, marketing and those dirty things us coders try not to get involved with Of course, I will be there.

So why not give Think Visibility a go? You may just learn something.

However, it ought to be really simple (although I realise that this may be a bit late for some computer systems).

Never hard-code the VAT rate

Have a Tax class that the rest of the system can ask when it needs the tax rate. That way, you’ve only got one place to make the change.

Store the rate against your invoice lines

Add a field to your invoice lines that stores the rate applicable for that line. Populate this when the line is created. That way, an invoice at tax point 30th November 2008 will have lines with a 17.5% stored against them, those created on the 1st December 2008 will have a 15% stored against them. This keeps your most vital financial documents accurate over time.

Calculate the VAT as late as possible

When calculating the VAT on an invoice do not do this:

value_excluding_vat = 0

vat = 0

value_including_vat = 0

for each line in my invoice

  value_excluding_vat += line.value

  vat += line.value * line.tax_rate

  value_including_vat += line.value + (line.value * line.tax_rate)

The problem here is that you are calculating the VAT on a per line basis and then summing the values. This will lead to rounding errors - where your line values are a penny out from your totals.

Instead you need to place each line into a “bucket” for its tax rate, sum all values for a given rate and then calculate the tax on that. That way you are working on the largest numbers possible, reducing the risk of small decimal place discrepancies throwing your totals out.

value_excluding_vat = 0

for each line in my invoice

  bucket = the_bucket_for line.vat

  bucket.value += line.value

  value_excluding_vat += line.value

vat = 0

for each bucket in my collection of buckets

  vat += bucket.value * bucket.rate

value_including_vat = value_excluding_vat + vat

Have a Tax Band and Tax Rate model that deals with changes over time

If you really want to have a “minimal administration” system for dealing with tax rate changes then you should switch your data model to have multiple Tax Band objects (as remember, there are multiple VAT bands - “standard” is 17.5/15%, “low” is 5%, “zero-rated” is 0% and “exempt” is also 0% but needs to be accounted for separately to “zero-rated”).

Each Tax Band object should have a set of Tax Rate objects hanging off it - where each Tax Rate has a percentage rate and a start and end date. That way you can ask your “Standard Rate” tax object “what is the percentage on the 30th November 2008?” and it can give you the correct answer.

That makes dealing with a change like this simple - you simply go to the “Standard Rate” object, find it’s current rate object and set its end date to 30th November 2008. Then you add a new rate object to the “standard rate” of 15%, setting its start date to 1st December 2008, with an end date of 31st December 2009. Lastly, add another 17.5% rate object, with a start date of 1st January 2010 and no end date.

Update the rest of your systems to always ask the relevant tax object for the correct rate and tax rate changes will never be a headache again.

Ruby Programmers having a fight

What the fuck is this?

Merb is launched and DHH suddenly has a load of “Rails Myths” posts up on his blog. Like this sly little dig:

it shows the great power of being an full-stack framework

Wycats responds with a slightly less sly dig:

For the moment, these differences are the reason that Rails will continue to dominate amongst developers seeking to build apps similar in scope to apps built by 37Signals. I suspect that Merb will pick up steam amongst developers looking to build innovative apps leveraging the latest and greatest Ruby techniques and libraries.

Zed responds angrily to a mistake by DHH (which DHH subsequently corrects).

I admit I’ve not had much time to look at Merb in detail; the times when I have played with it my impression has been “it’s much the same as Rails but done in a different (probably cleaner) way”. I love the fact in Rails that everything comes in one bundle (apart from RSpec :-), I love the fact that Merb gives you choices (even though I don’t have the time to research those choices), I like the fact that the two frameworks are now feeding off each other.

But the thing that impressed me most when I came to Rails was how nice and friendly the Ruby community was. But, it would appear that that was an illusion and massive egos are in charge. Discussion is good. Adapting your ideas in the face of competition and change is good. Having a massive pissing match because my framework is better than your framework is stupid. I wish you would all just shut the fuck up.

UPDATE:

And the fighting continues - this time it’s _why versus Zed.

Smalltalk is one of my favourite languages but a decent Smalltalk implementation that fits with your native window manager is hard to find. The point of GNU Smalltalk is that it works “headlessly” (Smalltalk invented the graphical user-interface and the integrated development environment so this is quite a departure), so I can still use my favourite text editor and run stuff from the command line. Just like Ruby!

However, it’s taken me a couple of hours to figure out how to simply connect to a database. But now I have, here it is:

• Install GNU Smalltalk (in my case using MacPorts):
  sudo port install gst
• Start GNU Smalltalk and create a working image:
  cd /Users/rahoulb/source/st
gst
st> ObjectMemory snapshot: 'work.im'.
• Ctrl-D to exit Smalltalk and then restart using your new image:
  gst -I work.im
• Load the DBI database driver:
  st> PackageLoader fileInPackage 'DBI'.
  Load the MySQL driver:
  st> PackageLoader fileInPackage 'DBD-MySQL'.
  Save your image so you don’t need to reload these packages again:
  st> ObjectMemory snapshot.
• Open a connection to your database:
  st>con:= DBI.Connection connect: 'dbi:MySQL:dbname=mydatabase' user: 'myuser' password: 'mypassword'.
  Grab some data:
  st>results:= con select: 'select name from customers limit 10;'
• Bask in the glory of your data

On Sunday morning, I awoke to find an email from a web-site monitoring service that I use, stating that a client site was down. The email was sent at 5am. It was now 10am and I had no computer, a mere GPRS connection and a hangover. Not good.

However, I fired up TouchTerm (an SSH client) on my iPhone and connected to the server in question. Connect OK. Good. Then I type sudo monit status to find out what state the server is in. All services running OK. Then cat /etc/apache2/sites-enabled/rails-mysite. This lets me examine the web-server configuration file; and I can prove to myself that I had set up aliases for the site (so that the same site is also available on an alternative web address). I then used Mobile Safari to connect on the alternative addresses and everything works fine. Lastly, I write an email to the client stating that the site is down but nothing at my end is wrong - could it be a DNS problem?

iPhone with TouchTerm

Later that day I got an email from the monitoring service stating that the site had returned. And on Monday, the client tells me that their registrar had had a failure and all of their domain names had gone down for the day.

Still, I think that’s pretty good; Sunday, with a hangover, pro-actively investigating a fault on a customer’s server, on a telephone and an antique net connection.