Monday, 20 November 2006


Writing the previous post raised a number of thoughts while traversing the London Underground, which will keep me going in blog entries for a while, I think.

So... LAMP.

Linux, Apache, MySQL, and Perl (or PHP, but I kind of promised myself this blog would be mostly PHP-free. :) ). As characterised by O'Reilly's excellent OnLAMP section, in fact, which is recommended reading, and a champion of the cause.

Is this Enterprise Perl?

Interesting question. I think the answer is, sort of: it's its skeleton. It's the bones on which you can build an enterprise-level application in Perl. (Which reminds me - we still need to define exactly what we mean by that troublesome term 'enterprise', don't we?) But it doesn't actually define anything. A single CGI that uses the HTML generation methods and talks raw DBI to MySQL is as much LAMP as a fully OO MVC-style web application written in TT2 and DBIx::Class.

It clearly can work, though: Yahoo's internal CMS is written in Perl, so's IMDB, Amazon's publishing system, the entirety of CricInfo (trust me, I designed it - it's a TT2 fronted MVC web app, or at least it was when I left)... all these can be pointed at as examples of LAMP-done-well, and cover four of the biggest sites on the web (even CricInfo - a quarter of a billion page views a month on a single sport site). OK, so the 'L' occasionally stands for FreeBSD, but we'll draw a view over that - the spirit of the 'L' is 'Unix or Unix-alike on x86 commodity hardware', and we can let Yahoo off, just as we can excuse the folks who use Postgres. But there's really more to these than LAMP, or at least, we hope there is.

What we're looking at, from an enterprise point of view, is something I'm going to call LAMP++. I'm sure, with a bit of work, we might be able to come up with a better acronym, but by analogy with C++, LAMP++ is actually not that far off the mark. The '++' means we're talking adding, or rather mandating, an OO approach to Perl (including an OO DBI abstraction layer), some form of templating, be it TT2, Mason or whatever, and some form of Apache-embedded Perl interpreter (mod_perl). We're looking for Perl programmers, not scripters, and we'd probably really like test-driven development, too. We're taking as our bible not the Llama and the Camel, but Perl Best Practices and Intermediate Perl, and to guide our philosophy we keep handy Perl Testing: A Developer's Notebook, and Perl Design Patterns.

LAMP++. It's got legs, I reckon. More anon.

No comments: