After three months of hard work we are finally releasing the next step in Scred development, ‘Ashes to Ashes‘. The name is significant because with this release it is time to say goodbye to our old Perl-based core. In fact we have effectively rewrote the entire Scred service on Django and Python. Every line of code had to be rethought, every template ported and even our database altered. Believe me when I say that this is more work than what might immediately be obvious, especially as we put in effort to do things like currency conversions correct instead of “close enough”.
Hardly any of this will be visible to the user. In fact we measure the success of our porting by that. Every corner case had to be replicated and no funny surprises should be visible to the user. Indeed this should be almost totally invisible to people visiting the site. It has been an immense task, so why did we do it? We did it for you, the users. Our old core was getting more and more difficult to maintain. Adding new features was slower than we liked and bugs would easily appear. With our new core we are positive this will change and we will now be immediately starting work on new features.
The only things users might notice with this new core is that our service is now somewhat faster, it has a bit better error handling and, for some users, there are very small differences in how balances are converted, and rounded, from one currency to another. In our belief this one is now more correct. Anyone affected has been notified.
Unsurprisingly this effort took more time than we would have liked, especially as we wanted to make absolutely sure user balances were not unduly impacted and that the new database structures would not cause problems. If, however, you stumble across problems, please let us know and we will work hard to fix them.
So why Django?
We will hopefully write up further articles about how the transition went, but basically Django had the best documentation, was easy to get into and was built on a language that gained adequate acceptance from our team. Ruby on Rails did not make us feel confident about scalability and performance, and Ruby is a language none of us are comfortable with. Catalyst seemed reasonable but Django’s documentation was simply better, and we liked the idea of making a clean break from our existing Perl templates and code. We did also investigate using OpenACS on Tcl, which looked like it would be the best at scaling and performance, plus being mature, but the learning curve for this felt very steep and documentation, again, difficult to approach. Plus it has the major downside of requiring AOLWebServer, which would mean moving away from Apache altogether. An idea that did not sound appealing.
We hope users will experience a smooth transition and rest assured that new features are speedily on their way.
