Often a situation faced by coders, especially when following test-driven development, is the writing of very similar test cases, changing only in, for example, the expected and actual values, along with some set up parameters. We often end up writing dozens, nay hundreds of near identical test cases, and end up with a test class that looks that it has suffered from a terminal case of copy-paste. This blog post shows a little-known technique for making this sort of test class a little more readable using the nUnit TestCase attribute.
Here at thetrainline.com we have several useful online tools for helping our customers plan and manage their train travel, including Train Times and Live Departure Boards. We recently changed the way we build, test, and deploy these kinds of applications to enable us to release new features much more frequently and easily; in fact, we shortened the deployment cycle from one deployment every few months to multiple deployments per week. These changes have produced a sea change in team culture, with a marked increase in product ownership by the team. This post describes what we’ve done so far, and where we want to go over the coming months.
We (the tech team at thetrainline.com) will be at the Silicon MilkRoundabout recruitment fair on 17th November 2013, between 12 noon and 5pm. The event is at the Old Truman Brewery, Brick Lane, London.
Drop by and visit us on stand 17, and have a chat about what we’re up to!
We were at Silicon MilkRoundabout 5.0, so look out for our dark blue stand.
For several years, much of the code for the systems at thetrainline.com has been versioned and deployed together as a single ‘platform’. Recently, we have begun to divide up the platform into smaller chunks, to enable us to deliver some parts more frequently and rapidly, leaving other parts to evolve more slowly (as needed). Moving from a single version number for all subsystems to multiple version numbers for independent subsystems has implications for how code is built and released; this blog post outlines some of the work we have done so far in this area.
My colleague Owain Perry and I recently presented on this topic at the London Continuous Delivery meetup group (http://londoncd.org.uk/) and the slides we showed relate to the details in this post:
At thetrainline.com we use Opscode Chef for managing our build infrastructure. Like many other tools running on Windows, the chef-client ohai framework relies on WMI for extracting information about the server machine on which scripts are being run. We found that Windows WMI repository corruption can cause chef-client runs to fail due to missing WMI classes, which causes the node to remain out of policy. The WMI repo can be repaired using winmgmt /salvagerepository, and the WMI errors can be monitored using the WMIDiag script to alert on WMI repository corruption before future chef-client runs. This post details how we detected and fixed the problem, and how to monitor for WMI repository corruption.
In common with other big systems, thetrainline’s systems use a variety of technologies under the hood. Most of our code is written for the .NET framework, although there are bits of other technology stacks in there as well.
Recently, working with a project targeting version 3.5 of the .NET framework using Visual Studio, I came across a rather subtle gotcha.
Visual Studio 2010 was released in April 2010 and by default will target version 4 of the .NET framework. Version 4 of .NET came with, amongst other things, the following features.
- The Parallel extensions library.
- Dynamic dispatch.
- Named parameters.
- Optional parameters.
It was this last feature – optional parameters – that was the original source of this gotcha, leading to ‘error CS0241: Default parameter specifiers are not permitted’.
A commonly overlooked area of many systems are the non-functional requirements and the design to meet those requirements. Patterns for Performance and Operability by Ford, Gileadi, Purba and Moerman provides everyone involved in the software life-cycle from development to support with a good foundation in understanding why non-functional requirements are important and real examples of how to capture, develop, test and operate with these requirements. Systems fail when non-functional requirements have not be considered and it is everyone’s role in the SDLC to consider them.