Tim’s Internet Web Log

Damn, time goes quick.

Damn, time goes slow.

Anyway… that’s life.

Please vote. This democracy stuff only matters if we make it matter.

Also, spent longer searching online for a polling station (unsuccessfully) than I spent actually wandering out into the world in search of said station.

Probably says a lot about something.

http://www.londonelects.org.uk has a flash app that teases me with “Find your polling station” but clicking that box renders no action on either a Mac (FX or Safari) or a PC (Fx or Explorer). Sigh… why not just put up a PDF index alphabetically? Cheaper and more effective.

Update
Turnout was up this year which is great. It was still a lot lower than a general election but there was a better turnout than last time.
Link

General election turnouts have been falling. *sigh*

Back in a previous part of my career I spent a lot of time engineering systems that did a very important but mostly dull thing for companies: processing their credit card transactions, enabling their revenue. If there’s one thing companies really care about it has to be getting paid.

We had heaps of code that made that work and we built out new features regularly.

I think we did a pretty good job and our transaction systems had really great uptime. Not only that but we delivered our software to requirements and on time.

Requirements, though, often took quite a long time to work their way through the product development pipeline to the point where we could get started on the engineering part of the process. Couple that lag with a QA department that was probably a little light on the ground and we had an interesting problem.

Engineers sitting about with a little too little to do and no way to roll changes out without the aegis of a full project to work under because there was too little QA to see our changes safely through into production. Push and pray was certainly out the question with something as mission critical as credit card processing. So what does that mean? It means that the cards were stacked against engineers using the downtime between projects to actively refactor or improve the codebase. That meant that we’d bite off little mouthfuls of improvement while doing project work but it mostly meant we learned to live with a cumbersome codebase. Frustrating.

Yesterday I spent a couple of hours adding some more automated testing to the small project I’m working on the moment: http://whenshouldwe.com. Even such a small application was already suffering a little bit of code rot from a few chops and changes in direction Rory and I had made while getting to grips with the nitty gritty of working with Rails’ RESTful architecture (a real conceptual shift from action based web-MVC). I wanted to cut out that rot and make a couple of other refactorings but I didn’t want to break anything and esp. with a dynamic language like Ruby there’s no way to tell what’s broken until you run the code.

By adding a few more functional tests and wrapping up the happy path in an integration test I was able to give myself a lot of confidence that any changes I made would not break what I had out on the site already. I was able to hack away dead, unused, code safe in the knowledge that while my test suite kept passing I probably hadn’t done anything wrong. With a really good test suite (see rcov) and a source code management system you can make improvements with abandon.

Tests like these would have been tremendously useful at my previous employer, sadly I wasn’t introduced to TDD and automated testing until a couple of years ago. The tests are a safety net, they remove the need for courage, bravery, caution, concern and just let you get on with writing and improving code quickly and confidently.

rcov is a Ruby code coverage analysis tool that I’ve just been playing with for an hour or so while I look at how well my test cases are covering the code I’ve written.

You can gem install rcov

I’m working on a Rails app and there’s a handy plugin to make running rcov easy peasy:

http://svn.codahale.com/rails_rcov/

with some documentation here:

http://blog.codahale.com/2006/05/26/rails-plugin-rails_rcov/

Now I can just rake test:test:rcov to run all my tests and see what they’re covering.

Update: from playing around a bit I reckon that concentrating your coverage analysis around functional tests is probably the biggest bang for the buck. Functional tests exercise a lot of your code from both the controllers and the models.

rake test:functionals:rcov

rcov generates these amazing HTML reports telling you which code your tests exercised. More importantly it tells you which code your tests didn’t exercise so you can work out what extra tests you need to add.

How cool is that!

Now, what prompted all this was a post to the cc.rb mailing list about integrating rcov with a continuous integration build to fail the build if coverage drops below a certain acceptable threshold. Perhaps 80%? Perhaps 100% for those prone to collecting comic book series or trading cards.

There’s a rails plugin named vl_cruise_control that will help with failing a build with cruise. I’ve not tried it yet.

I think this might be very useful for creating expressive models.

Search for Association extensions inside the ActiveRecord::Associations::ClassMethods API doc.

Hrm… need a bit of time with this but I suspect I have a lot of uses for it floating around.

Monica made a few Hackney related tshirts a while back.

She sells one every so often and did so today. I think they’re cool.

Hackney t-shirts

Ah ha! I was working with Rory creating a Rails form backed by a nested resource the other day and we had code like:

<% form_for(:participant, @participant, :url => poll_participant_path(@poll, @participant), :html => {:method => :put}) do |f| %>

<% end %>

That code smelled really bad, having to put in the :url and the :html felt really wrong.

Solution:

<% form_for([@poll, @participant]) do |f| %>

<% end %>

The array of objects makes this much cleaner.

It was an old version. I reckon I should upgrade.

A plugin was installed in /tmp/ro8kbsmawge.txt that was apparently spamming people. *sigh*

Anyway, the only way I discovered it was hacked was because I was getting an error while uploading images from MarsEdit.

I was getting an XMLParse error and no data was coming back in the response.

Here’s a write up:

Link

Henry, Rory and I have been hacking away at a little utility website and I think we’ve got an early version that should stand alone and deliver some value.

whenshouldwe is a little web app designed to help people work out a time they can get together.

Baby steps, deliver some value as soon as possible and iterate quickly. We’ve got big plans to increase the feature set while keeping the user experience as simple and clean as possible.

Nice tips on using Splat!, the * operator.

Heads or tails?

Splat! can be used for more than just method definition and invocation. My personal favorite use is destructuring assignment. I read this in Active Record’s source code recently:

def sanitize_sql_array(ary)
statement, *values = ary
…
end

This is invoked when you do something like User.find(:all, :conditions => ['first_name = ? and last_name = ?', 'nick', 'kallen']). Splat! is used here is to get the head and tail of the conditions array. Of course, you could use always use shift, but the functional style used here is quite beautiful. Consider another example:

first, second, *rest = ary

Link