Every year as far back as I can recall I've had a project on the go, some to pass the time and others to serve a purpose, usually for an aspect of motorcycle racing. I think it goes back to 2007 when I started by first website, Doctor Who for Newbies (DW4N), a (funnily enough) Doctor Who fansite following the 2005 revival (but with aspects of the classic series as well). This ticked over until 2011 when my undergraduate degree took more time than I had anticipated and alas, it fell by the way side now existing as a ghost site of articles and memories. In 2008, I moved onto a form of Stop Box Logging for Endurance Racing, primarily to computerise tasks being completed by humans. This evolved over 2008/2009 into an automated checking tool where users could input times and get results immediately, but, due to limitations in the computing powers, was limited in the checks it could perform. Most of the work was done with Excel macros and was built and maintained during a race season - not ideal for proper software when there are other concerns during a race meeting.
Doctor Who for Newbies (DW4N) (2007-2011)
In 2010, the project of the year was a RPG for DW4N scripted in PHP, which took me into early 2011 when the Stop Box Log took a new form in a proper piece of software made in Java. This was developed twice over 2011, the first was a quick solution to the problems arising from the use of Excel, while the second, developed after the race season ended in 2011, was a more stable version capable of quick analytics necessary during a fast paced Motorcycle Endurance race.
Stop Box Logging Software (2008-2011)
Late 2011/Early 2012 saw me continue a software creation trend with the creation of a staff rota creator for KUSU Bars, again attempting to computerise tasks undertaken (slowly) by humans. This project was perhaps quickest and easiest to create (simply it turned a manual process into a semi-automated one, reducing the time taken to produce rotas from avg. 3hrs to 30mins). 2013 was taken up by my undergraduate project which took up the time usually spent each year on a personal project. 2014 was, similarly, taken up by the start of my Engineering Doctorate and left little time for a brand new personal project, with focus being on the new job and instead RTM(V2).
KUSU Bars Rota Creator (2011-2012)
2015's personal project is not strictly speaking a brand new project either. In 2008, I developed an Excel tool which I named a Race Time Management (RTM) tool, which is used to predict race lengths, see the effect of changes (time lost or gained by changing laps, etc.) and progress throughout a meeting (with the tool dynamically updating as users input race start times). The RTM was, and still is, meant as a 'what-if' analysis tool, providing Clerks of the Course such as myself with quick calculations on how a race meeting is running. The first version of RTM (RTM(V1)) was developed on memories of a similar tool developed by Ted (Bemsee) in the days when I was working in race control typing up race logs for the Clerk of the Course of the day. RTM(V1) has provided to be very accurate over the years (providing the inputs are good - you have to avoid GIGO (Garbage In, Garbage Out) (alternatively RIRO (Rubbish In, Rubbish Out)) with any what-if analysis) and I have used it successfully at a number of race meetings with Bemsee. However, as is perhaps typical of things I develop for my use (the early versions of the Stop Box Log were similar), it was only usable if you know which functions to change for additional sessions, or where the background code is to make modifications or improvements. In short, RTM(V1) is only usable by me in the first instance, with others only able to use it if I've set it up for them for their race schedule.
Race Time Management (Version 1) (2008 - Present)
This directly led to my 2014 personal project - a second version of RTM which was more user friendly in set-up and use. Early in the 2014 race season I began work on a second version which split the inputs from the outputs, and exposed more of the inputs for user control. The outputs were also made to be more automatic - race day sessions are generated automatically from the inputs of the user without the need to show/hide rows and columns in Excel. RTM(V2) is still based in Excel though, with most of the code staying the same (some tweaks to some functions which occurs between RTM(V1) and RTM(V2)). RTM(V2) allows the user to input their number of sessions (for each type of session commonly seen in motorcycle racing - practice, qualifying and racing - and allows the user to set up their nominal race times and length of sessions - all items which were previously a large amount of hassle in RTM(V1).
Race Time Management (Version 2) input screen (2014 - Present)
Race Time Management (Version 2) output screen (2014 - Present)
RTM(V2) has been deployed since the middle of the 2014 race season alongside RTM(V1) for calibration checking and confirmation that the new version does not differ from the original in the times it gives (providing the inputs are the same and accounting for slight tweaks in some calculations). RTM(V2) works very well in the field, though is still currently undergoing testing alongside RTM(V1), with RTM(V1) being slowly phased out over the course of the next two years (hopefully).
However, RTM(V2), while slightly more usable than RTM(V1), lacks certain abilities which I think would be handy in a race control setting. These are functions which are currently still completed manually but could be easily automated (and indeed are in the case of BSB and other non-club level events) or semi-automated with new software. Which brings me to the crux of this post - my personal project for 2015 is a third version of the RTM which will continue to provide all the functions the current versions of RTM but with additional features to further computerise race control tasks for an increasingly digital age. At the moment, RTM(V3) is very early stages - simply a concept within my own head at the moment - but I envisage it being stand along software, no longer relying upon a version of Excel most likely created in C++ (for engine work) with a C# GUI (see my previous post for why C and not Java). I hope to be able to provide updates here as my 'diary' of development, as much for me to keep track of where I am, as this will be confined to weekend and evening development when I have no other priorities for my research... which does mean the start date is delayed already to June 2015 following the completion of some compulsory module coursework with Loughborough.
Failure is only the opportunity to begin again - only this time more wisely