So those of you following the Cerberus project will know that I’ve recently been spending my time working on implementing the build steps so I thought I’d do another video to show the changes so far. Again best viewed as big as you can make it, also, this one has sound!
Featured in this video:
Recently I was reading an old post by that guru of good software thinking, Joel Spolsky (Yes you should know him, you almost certainly know something he’s done) in it, as part of a series on writing good software specifications, he explains the virtues of having a section on ‘Nongoals’, which are, quite simply things that you will not do making (this version) of the software. This is very useful, especially for smaller projects that have the tendency to quickly expand beyond the abilities of the team working on them.
I’ve been fighting against this feature/scope creep with my latest project, Cerberus. As I develop it, I keep thinking of cool features that I could add to make it better, but I’m trying to keep it in a scope that is manageable by me in a sane time-frame. Now most of these features make it a more general product, something that would expand it from it’s initial me-centric design to something that could appeal to more people, picking and choosing which of these features should make it into the project requires both discipline to resist the It would be so cool if it did this! feeling and foresight to evaluate if a feature may be of great use to me in the future, a third factor also comes into play, since this is a hobby project designed to teach me new things (Python and jQuery so far!) I also have to weigh-up how much of an opportunity for learning a feature provides.
An example of how I have expanded the scope of Cerberus is the addition of ‘build steps’. Initially, Cerberus was designed to do 3 main tasks:
This is a very me-centric design, all the projects I currently work on are hosted on Mercurial repos and they all use Premake to generate the solution files. Now as I was developing Cerberus, the idea struck me that it would be quite cool if, for each repository, you could specify a series of steps to perform on the contents of that repository, so for example, if the project was hosted on a Git repository, you can replace the ‘Mercurial’ script for the ‘Git’ script and you’re good, or say a particular project had a set of tests that should be run, just add a new build step and you’re good to go.
Initially I resisted this idea, thinking it was a brazen case of feature creep, I was building a tool for me, and that was more than I needed. But the longer I thought about it, the more I thought how limited it was making the project, it only suited my needs now and would then have an influence on my practices for the future, I never want to be in the position where I feel resistant to implement a new thing because Cerberus would have to be re-written to accommodate it. Secondly, a few people have expressed interest in this project, which I have to admit adds weight to the argument of making it slightly more generally appealing.
So, today, while writing the code to add and edit repositories, I added the ability to specify build-steps per-repo, currently there is only 3, one to clone or update a Mercurial repo, one to run a Premake script, and one to actually compile it, but I am expecting to add more to it soon. I am happy that I decided to implement this feature, but it got me thinking about a list of things I most certainly am not interested in implementing, and thus I present (in no particular order) the list of Cerberus Nongoals:
These may take some explaining, firstly, the Chrome thing, Chrome is the browser I use, Cerberus as it is should run just fine in any standards compliant browser, but then again it may not, I don’t really care, if it bothers you, download the source and fix it.
Secondly, Cerberus makes use of javascript to make things easier, it does not have a fall-back.
Thirdly at the moment I only have need/want to test my code on Windows, Linux and OSX. Solaris, BSD, Haiku and other people, if you want it add it.
And finally, Cerberus was meant to be run on an internal network, it is not meant to be open to the general malicious public, and as such, it only performs basic error checking, it is assumed that anyone using it wants to compile some code and doesn’t want to break things, I have no real interest in attempting to patch all possible vulnerabilities in a system that essentially allows someone to run Python code on your server. Again, for all these points, if this is an issue for you, download the source and fix it, this is the beauty of open source.
Cerberus continues to progress towards a feature-complete beta state, and I am pretty excited to see it taking shape like this.
Have been continuing with Cerberus this week and managed to reach a rather important milestone, at 1:40am on Thursday 2nd June, Cerberus successfully cloned, and then compiled, the contents of the LibCT hg repository on Windows.
This is a pretty big step but there’s still a fair bit of work to be done. The fron-end needs some work still, especially repository management and the build report formatting, also need to write the Linux and OSX build slaves (which will hopefully not take long, since most of the build-slave code is common to all platforms)
I’ll leave you with a video showing off what’s been done so far, including a demo of the actual build process (best viewed in fullscreen HD, so you can read the text).