Posted by jj on Wed 8 Apr 2009 at 10:21
Last year I led the development of Penny's Arcade, an online retail store selling gifts and home accessories. Now, 6 months after launch, it's time to look back and evaluate how we did and if the right choices were made.
There's no shortage of e-commerce applications available, both open-source and commercial, not to mention companies offering hosted solutions. So why did we choose to develop our own software? Quite simply, it's the only way to have full control over the user experience.
During our research phase, we looked at our competitors websites and found several usability issues. Even now, plenty of sites do not follow simple best practices such as clearly showing delivery charges before the checkout. To provide a better user experience, we had to make sure that our software platform did not tie us in to any poor design choices. There were also some features we specifically wanted, such as letting customers purchase without registering for an account, that were missing from most off-the-shelf solutions.
With Perl though, there's always more than one way to do it. Thanks to the CPAN, the choice isn't just "buy or build", we have a middle option of using ready-made frameworks and modules, but glued together using our own business logic.
The base of our application was Catalyst, the web framework used by the BBC iPlayer, Manchester Evening News, Foxtons.co.uk, Vox.com, and many other successful high-traffic websites.
With a CMS and product database put together using DBIx::Class and HTML::FormFu, both modules which integrate seamlessly with Catalyst, the next stage was to add the shopping functions: a "basket" for customers to store items temporarily, which would then go through a "checkout" process and be converted to an "order".
The Perl module Handel, again easily integrated with Catalyst, implements these concepts in the form of a Cart class and an Order class. These have standard methods for many common operations - adding and removing items, working out the total order value, and so on. The best feature of Handel though, it that it is very easy to customise. For example, we could define our own delivery calculation simply by subclassing the Handel::Cart module and adding in the relevant method.
CPAN helped us with the front-end as well. Using Image::Magick we wrote a Catalyst view which can render banner images for category pages, thumbnails in any size and aspect ratio (with or without rounded corners), and the homepage slideshow, all from the same set of high-res product photos. This enabled us to tweak the visual design very quickly just by changing URL paths in a template.
However, one of the most important criteria when evaluating a software technology is not the development process itself, but rather the ongoing maintenance and support.
Since the site was first put live, we've deployed over 30 maintenance releases to refine the user interface, add new features, and (of course) fix bugs. This ongoing development process has really put Perl and Catalyst to the test, both in terms of how easily the codebase can be added to or changed, and in deploying new versions while minimising downtime.
Fortunately, this is one area where Catalyst really excels. The natural structure of a Catalyst application, i.e. the "separation of concerns" between different areas of the code, together with the built-in debugging and tracing tools make it very easy to locate which class and method provide a given piece of functionality. The Catalyst development server then gives instant feedback by automatically reloading whenever source code is changed.
As an example, our shipping labels are produced using a Catalyst PDF view which uses a template to annotate a blank receipt (created in Microsoft Word) with details from the Handel order object. Separating presentation from code in this way has long been regarded as good practice, and this meant that when we added support for multiple shipping addresses, only one part of the source code - the Catalyst model - needed to be changed.
Incidentally we've since released our PDF view, Catalyst::View::PDF::Reuse, as open-source which can be downloaded from CPAN.
In the same way we have added cross-sell tools, improved reporting features, and alternative categorisation options, all with small targeted changes which have had little or no impact to the wider application. I've also been involved in maintaining an existing Catalyst application for another company and have had much the same experience.
So, 6 months on, would we make the same technology decisions again? Undoubtedly. The technical aspects of Perl - stability, performance, and so on - have never been doubted. But it has been the availability of professional, well-documented modules from CPAN and the ease of maintenance that modern Perl environments such as Catalyst bring that have given us the clearest benefits.
This article can be found online at the Perl is Alive website at the following bookmarkable URL:
This article is copyright 2009 jj - please ask for permission to republish or translate.