April 28th, 2016
The Plone Community has project long traditions for community driven development sprints, nowadays also known as "hackathowns". For new developers, sprints are the best possible places to meet and learn from the more experienced developers. And, as always, when enough openly minded developers collide, amazing new things get invented.
One of such event was the Sauna Sprint 2011 at Tampere, Finland, organized by EESTEC. During the sprint, from the idea by Mikko Ohtamaa, with the help from top Zope and Plone developers of the time, we developed a fast code reloading tool, which has significantly speeded our Plone-related development efforts ever since.
So, what was the problem then? Plone is implement in Python, which is a dynamically interpreted programming language, already requiring no compilation between change in code and getting change visible with a service restart. Yet, Plone has a huge set of features, leading to a large codebase, and a long restart time. And when you are not doing only TTD, but also want to see the effects of the code changes in running software (or re-run acceptance tests), restart time really affects development speed. Python language did had its own ways for reloading code, but there were corner cases, where everything was not really reloaded.
While our tool is strictly specific to Plone, the idea is very generic and language independent (and, to be honest, also we did borrow it from a developer community of another programming language). Our tool implemented and automated a way to split the code loading in Plone startup into two parts: The first part loads all the common framework code, and the second part only our custom application code. And by loading, we really mean loading into the process memory. Once the first part is loaded, we fork the process, and let the new forked child proces to load the second part. And every time a change is detected in code, we simply kill the child process and fork a new one with clean memory. What could possibly go wrong?
That was already almost five years ago and we are still happily using the tool. Even better, we did integrate the reloading approach for a volatile Plone development server with pre-loaded test fixture: each change to code or fixture restarts the server and reloads the fixture. acceptance tests for it. No more time wasted for the other developer to continue from where you left.
