geekmade

Inspired by entp’s article ‘Tools on the edge’ and seeing some of my colleagues posting How they make websites I thought I would share some of the tools and techniques I use on a day to day basis as a BBC FM & T Vision Software Engineer.

Development

Ever since I have been at the BBC (nearly 2 years) our team in Manchester has mainly used Ruby on Rails.
The majority of our work is to create internal applications for editorial staff and to do quick prototyping of new ideas and proof of concepts.

We use Rails because:

• Its quick to develop with, especially when doing prototypes.
• Its open source so there is a huge resource of plugins and Ruby Gems to use.
• Has built in testing
• MVC framework
• Simple, RESTful based design patterns built in.
• Lots of other nice features, have a look.

We are all pretty hip developers in Manchester so we like:

• POSH, standards based markup
• Accessibility built in as standard
• JQuery - what all the cool cats are using, although Prototype is not bad either
• Progressive Enhancement
• Unobtrusive Javascript

We are all on Macs so most of the team use Textmate. We develop sites locally on our own machines then deploy to linux based servers.

When testing user interfaces I like to get the app working in Firefox using all the nice developer addons (A special mention to Firebug, Its like a mobile phone, I can’t remember how I managed without it).
Unfortunately we still have to support IE6 so we have a PC with various virtual machines on to test all the IE browsers and assorted others.

Source Control Management (SCM)

Code, configuration files and anything else that needs keeping safe, like wireframes or designs, are stored in a source control management system.
Doing web or software development without SCM is irresponsible and very naughty!
Either git or Subversion is used depending on the type project.

My personal preference is for git. Its perfect for collaborative working hence why many large open source projects, including Rails, now use it for SCM.
Its really easy to branch and has fundamentally changed the way I work, for every new feature I create a new branch. That way if a bug request comes in I can still fix the bug on the main branch without the new code interfering.

Testing

The middle last year we decided to introduce formal testing methodologies into all the work we were doing. Previously we were testing in an ad hoc manner just using a browser and server logs.
How did we know for sure that the application worked properly and that when we refactored code it didn’t break something else?
We started doing Behavioural Driven Design (BDD), a derivative of TDD and using RSpec as the test framework. I won’t go into the details, you can read about it yourself.

Since using BDD the number of bugs has reduced significantly and there is the ’safety net’ of a test harness in place to catch bugs when we refactor.
A nice side effect is a full specification of how the application works written in code. This can be checked against how the application is meant to behave and can be used to generate reports to show to non-technical people on the project.

It was not all plain sailing, we did have some problems.
Initially there is a big learning curve, its a different way of looking at development and while we were learning BDD our speed and output were effected. It took a few months to really bed down, despite this I would still encourage everyone to give TDD or BDD a try. Stick with it for a few months, you will soon see the benefits.

Deployment

For a standard deployment to one of our servers (Vision) we use Capistano to check code out of version control and deploy behind Passenger. Passenger really has made deployment much easier, because its Rack based its simple to use with other frameworks like Merb and Sinatra.

We also have stuff hosted on Audio & Music servers also. Deploying here is a little more complex involving building and installing RPMs to an integration server. The service management team then deploy to the final production server for us.

Communication and Organisation

The team uses a hybrid form of Scrum to run and manage the projects. We work in iterations of between 1 and 2 weeks in length and usually have some sort of working code demo or deployment for the end of each cycle.

When working in a team the most useful part of scrum is the standup meetings in the morning. It helps to keep track of what everyone is working on and more importantly, used to share problems that block the project.

For Personal time management I use Things to organise my day-to-day tasks in a GTD stylee.
We used to use Basecamp for project collaboration but not any more, not sure why not. Probably down to office politics or red tape issues : )

Those are the tools of my trade, hope someone finds this interesting.