From the BBC’s article, Code centre ‘in financial crisis’:

Simon Greenish, director of Bletchley Park Trust, said: “The site is unique and one of the most important remaining from World War II.
“We have exciting plans to develop the park and save it for future generations. The more visitors we have helps us to realise these plans.”

As a British software developer I find this saddening, since stories of the efforts at Bletchley Park (partly due to Neal Stephenson’s depiction in Cryptonomicon) are partly what inspired me to get into programming.

Perhaps I’ll organise a big Helicoid visit to help!

Continue reading → | culture, programming, history, england

Rowland Watkins, an old university friend of mine (and a friend of all the staff at Helicoid), recently wrote up a comparison of the Google App Engine and Amazon Web Services. He’s specialised in grid and more general distributed computing for about 8 years now, so his comments on the topic have some pedigree.

Since we specialise in Rails, leveraging the power of Amazon Web Services has always seemed more natural than Google’s approach which currently relies on Python. Here’s what Rowland has to say on the matter:

The clear separation of duty in AWS is what gives it the edge over Google App Engine. EC2 allows businesses to deploy complete OS images from S3 to produce novel environments such as Morph. It gives business more control on how to put together business processes which currently isn’t possible with the Google App Engine.

It was announced today that Google are now “allowi…

Continue reading → | cloud, development, programming

I’ve just completed the third article in my Rapid Rails series.

• Rapid Rails Part 1: Command-line mastery
• Rapid Rails Part 2: Rapid in the literal sense
• Rapid Rails Part 3: Desktop mastery

If you’re interested in Ruby on Rails, or software development in general, check them out! They come straight from our experiences deep in the Helicoid software mines.

Continue reading → | rapidrails, programming, rails, ruby

Running a professional web application isn’t an easy thing to do. Even the most finely crafted and well tested code will have bugs somewhere, so we try to employ as many tools as possible to cut down time spent on bugs. Unfortunately, customers often won’t even report bugs, so if you’re not careful people will leave your service without even telling you something is wrong.

One technique we use to catch bugs is error email reporting. Depending on your development environment, it’s relatively easy to catch exceptions, display an error page and email your support staff.

Why are error emails so useful?

• You can get in touch the person that caused the error to ask for more information about what they were doing, and to also let them know you’re dealing with the problem
• Letting your customers know you’re aware of a problem even before someone raises a bug report is professional and good customer service
• In our experience emails …

Continue reading → | programming, maintenance, management

I’ve recently been providing consultancy for a few companies in London, advising them on skills and technologies that will improve the efficiency of their software developers. One thing these businesses didn’t do was version control. After explaining the basics I noticed people struggle with the “softer” skills required, and this raised the question: what’s a good commit message anyway?

It’s worth remembering that version control excels when it improves communication between developers. Log messages should form part of the evolving documentation of a project, where well-crafted messages become an asset rather than extraneous baggage. It’s important, especially in terms of saving time in the future on maintenance, that the people on your team understand how to write useful log messages.

In general, a good log message:

• Doesn’t contain references to changed files: version control systems do this for you
• Uses class or method names: make it easy for people to search in th…

Continue reading → | vcs, subversion, programming

Test Driven Development (TDD) is one of the techniques I use for creating Helicoid’s products. I’m still the only developer here, so I have to work incredibly efficiently and effectively. In fact, this technique is the greatest secret behind successfully “one man banding” without losing all of your evenings and weekends.

TDD will:

• Help you write better code: by working with the public interfaces from the start you’re encouraged to make cleaner interfaces
• Help design code
• Improve your confidence, ease deployment headaches: your tests will show recent changes are safe
• Communicate your intentions to colleagues (or yourself in the future!)

Don’t worry about UML, XP or any other unfamiliar jargon

There are plenty of books about TDD, and on the implications of it. Don’t read books about TDD, just start doing it right now.

1. If you don’t already write tests, look how people usually write unit tests in your project’s language
2. Take one of your project’s classes, and thi…

Continue reading → | testing, programming

There’s a few things I can’t live without when I’m programming. To that end, this is a list of 10 essential ruby gems that will make your life much easier, even if you only spend a small amount of time working with ruby.

Gems come and go, but these are keepers!

capistrano

Capistrano makes Rails application deployment less of a hassle. It’s also a clever framework for interacting with remote servers. I actually have backup scripts written with Capistrano, as an alternative to Rake/Net::SSH or shell scripts.

chronic

Chronic is a natural language time parser, with the added bonus of having a pun for its name.

Chronic.parse(‘3rd wednesday in november’)
=> Wed Nov 19 12:00:00 0000 2008

ferret

Ferret will make your boss/clients/customers love you. It provides tools for fast text searching, and you can even index PDFs and Office documents. I’ve used Ferret on some p…

Continue reading → | ruby, programming, code, tips | 7 comments