We’re making good progress on this, after a stalled attempt to sort things out back in March when a busy period then struck. Our previous update has some background on this overall initiative.
Firstly, we’re planning a Developer Day in late summer – more news soon.
The last month or so has seen significant refactoring of some of the least clean parts of the codebase. In particular:
- The XML API generation framework has been tidied considerably, with a long-standing and obstructive dependency finally removed. There is more to be done later.
- The Photomap code has been restructured. For a long time it has been shackled by a wrong class hierarchy that saw all access (e.g. viewing photos, adding them, browsing on the map) going through an overarching class that really should just have been a resource class. Over a several-day refactoring this class hierarchy was reversed.
- The code for addition of photos in particular has been rather a mess for a while because there are many different GUIs writing to it. Work to move the model-related code to a separate model class is seeing this cleaned up, and various lurking bugs have been removed in the process.
Some of the work has been very difficult even for us as the original authors(!), with some of it quite painful due to the age of the code and the number of hacks it had acquired. It is code areas like these which we know would have put people off even considering helping because the risk of breakage was very high to an unfamiliar author.
A Git server has just been installed (thanks Wookey!), so we are about – at long last – to move away from SVN which will enable us to move to a multi-branch model and, more importantly, then to move to GitHub.
We’ve thought long and hard about whether to retain the SVN history during the migration to Git. I’m pleased to say that we do intend to retain this (unless any big problems arise), with over 9,000 commits therefore being carried forward into the new Git repo to be created. In coming to this conclusion we took the view that, despite presenting some risks, it means that the history of the development of the system – which is effectively its documentation – is retained. This is particularly important because of the code was never designed with unit tests in mind (unlike our new Cyclescape codebase).
We’ve identified most of the sensitive strings such as passwords and API keys that will be stripped out as part of this process.
Initially we planned to split out the split the codebase into around 7 separate repositories (e.g. Journey planner, Photomap, common, API launcher, etc.), but in retrospect we think this would cause more problems than it solves in terms of ease of installation. So instead we are planning to split the sections of the code more simply into directories at the top-level, and do this after putting the code on GitHub.
Stay tuned for imminent updates!
