six to start

We’ve just started on the first phase of a new project, step one of which (for me) includes deciding which technology platform we’re going to be using. We want something that lets us get working prototypes built quickly, changes to the system design implemented with as little pain as possible and, crucially, allows the system to perform and scale well after deployment (with the minimum of hand-holding).

Coming from the ((un)enviable) position of being mostly language-agnostic, I’m looking at a few different web application frameworks to assess their suitability.

There are a couple of obvious problems

• Very few objective comparisons exist of the different frameworks out there, using realistic sample applications.
• Short of implementing the entire application during the evaluation process, it’s nearly impossible to get an idea of the framework’s performance.

The contenders
We’ve yet to write any code in anger, so the comments below are based on books, examples, tutorials and entirely too long searching Google.

We’ve looked at:

Rails (Ruby)
http://www.rubyonrails.org/
From what I’ve seen so far, I like the Rails development process. I know a lot of people don’t, but I’m willing to step forward and be categorised as one of ‘those‘. I have some serious concerns however, mostly in relation to performance and deployment:

• The recommended method for deploying/hosting a Rails app sucks. Considering how much thought has gone in to the rest of the framework, the idea of having to set up and monitor individual Mongrel instances behind a proxy to run my app feels like it was borne out of repeated attempts from the Rails community to stop their applications dying under load; bear in mind that this isn’t something you do to tune your site, but something you do just to get it managing requests acceptably.
• I’m not entirely comfortable with ActiveRecord’s ability to generate well-performing sql (although I suppose this concern is one of ORMs in general). There are reports of people having to replace it with hand-written queries when going in to production, particularly in the case of associations. Is this true of all ORMs? Maybe …
• Twitter. Boy do they have a lot of downtime. This fuels worries about performance and the kind of day-to-day maintenance that a live Rails app needs.
• It’s trendy, and I don’t mean that in a good way.

We are going to be looking at:

Django (Python)
http://www.djangoproject.com/
The performance figures are encouraging for Django, and the fact that a memcached-backed caching layer comes as part of the framework indicates the thought that’s gone into it post-deploy. So far, a couple of things are bothering me:

• It seems geared up for use in publishing (understandable, given its background). However, the sort of sites we’ll be building will be very interactive, with a lot of two-way data exchange - I worry that Django isn’t going to help us much in this area.
• The whole Python whitespace thing is … well, I’m in the ‘hate’ camp on that one (although the language itself looks intriguing)

Catalyst (Perl)
http://catalyst.perl.org/
I need to do a lot more investigation here, but two people now whose opinions I respect hugely have told me I should be using Catalyst. It’s the least well ‘marketed’ of the three but word of mouth recommendations are worth a lot.

Information is a little light on the ground regarding real-world performance, but it’s Perl so it will be fast. The Perl community has been around for a little while, so there’s plenty of prior art in getting Perl web apps to scale.
For me, the one obvious problem is the very thing I like so much about Perl:

• TIMTOWTDI. One of Catalyst’s big selling points is the fact that, if you don’t like the default ORM, templating language etc, you can swap it out for a different one; essentially you get the whole of CPAN to play with. If I were an accomplished OO Perl programmer, this would be a big plus; as it is, I’m something of a Perl *scripter*, so this makes me wonder about the learning curve for Catalyst, and the maintainability of the code between different programmers.

So, the search continues. I need a coffee.

Inspired by this post over at Litmus (via Matt), here’s a run-down of what we use to run Six to Start:

• Campfire for internal IM, but we also use…
• Skype for IM to keep in touch with our external contractors. Then we bludgeon them with a blunt instrument or do the handkerchief-in-chloroform trick, bundle them in to a van and have them wake up in a Campfire internal chat
• Google Apps Standard Edition provides our calendaring, shared documents and email. This gets us: email with a good webmail client, mobile email access (though Google still haven’t come up with a decent native mobile client other than a mobile web interface), IMAP and POP; shared calendaring and shared documents. That said, Google Docs is good for getting everyone working on draft documents, but we frequently - if not always - export to Word or some other program to do prettying-up before we send over to a client.
• Basecamp for all project management - keeping track of developing deals, and then opening up to our clients when we’ve got a commissioned project running. We don’t use Writeboards, though - we use Google Docs for shared documents.
• Highrise for both CRM and the “if any of us gets hit by a bus” contingency plan - all incoming and outgoing mail goes through Highrise so we can a) keep track of what’s going on and b) everyone else can keep track of what’s going on. We’ve used Highrise to keep track of job applicants and interviews, through to contract negotiations.
• Wordpress to run this blog
• Mac OS X - everyone here - apart from James, so far - uses Apple desktops and laptops
• IKEA - what startup would be complete without the fabled new-employee IKEA desk run?

We’ve made one bum note, though:

• The HP LaserJet 3055 is our office printer/scanner/copier of choice - or at least, it would’ve been had it not inexplicably lost the ability to scan with Mac OS X 10.5. Not happy, HP. Get your act sorted out (and yes, we tried all the suggested fixes. None of them worked).