Where Everybody's Crazy

So I think the "how does Maypole scale?" question has been resolved once and for all, and in my favour. :)

I got bored. I shouldn't have got bored because I have a huge number of things to do, but I spent the day messing around with Maypole and Javascript and came up with You Need To Read This!

It's a Web 2.0 (spit) social book recommendation system, built heavily off of the Amazon Web Services. It's in its teething stages at the moment (hey, I only started writing it less than 24 hours ago) so you probably will break it. And it doesn't (yet) degrade nicely to browsers without javascript. Sorry, but there's more to come on it, if I get time.

Please don't go ravingly public with it just yet, as there needs to be a couple of tweaks made to some of the pages to make them scalable and I rather would like to keep my machine up and running. But do prod it about a bit and let me know if you like it.

Simon Wistow is right. I want to amplify and expand on some of what he said there.

• All web frameworks do exactly the same thing, in the same way that most programming languages are, as Dan says, just Algol with funny hats. So stress the distinctives: is yours supremely easy to set up? Does it allow you to admin it over the web nicely? (Nice one, Django)

• Pluggability is not necessarily a good distinctive to stress. Actually, the choice of model/view is largely irrelevant to gaining traction, as Rails - and, dare I say it, ASP has shown. I don't hear ASP folks crying out for twenty different ways to access the same data just because they can.

  When I was designing Maypole I tried to make it easy for people to implement other model and view classes. It is a matter of debate as to how well that design panned out, but, after long talks with Tony, I changed the emphasis on why I was doing this. As Simon points out, most people don't want a piece of software that can do a bazillion things; they want one which does do one thing, and one thing well. The Unix philosophy is there for a reason.

  So for me the support of alternate model and view classes was not primarily to allow Maypole to be all-things-to-all-people, (although it is a very nice side-effect) but as a proof of concept to ensure that I've got all the concerns properly separated at the right layers of abstraction. If Maypole is "too" tied to CDBI and TT, that's a feature, not a bug.

• Number and scope of plugins don't matter, for the same reason. Applications (in the sense of "what is applied") matters. I don't care if you have 40 different ways of doing authentication if I'm never going to use 39 of them.

• Develop for the 80 percent solution. I tried to do this with - and now I'm thinking about authentication plugins - the UserSessionCookie authentication module for Maypole. 80% of the time, it's exactly what you want. 10% of the time you have to subclass it. 10% of the time you need to write your own. Don't make people choose between a myriad of options for the most common case.

• I'm going to start working on a way to make setting up Maypole apps much easier; basically one command-line call should write you the code to get CRUD working with factory templates on an existing database and, what the hell, dump a new Apache config file out to /etc/apache/conf.d/ and restart Apache. Because 80% of the time, that's exactly what you want, and its ease of use would be a helpful distinctive for Maypole.

• Yes, those default templates need redoing by someone who has a better sense of design than me.

• I will start thinking about very cool demonstration project ideas.

I think that's all for now.

Since I've now given my talk (which went spectacularly badly, but it's OK) I'm now happier to give out Memories 1.0 source code, and the PDF of the tutorial. Have fun with them. I will be making arbitrary changes (um, I mean improvements) to Memories in the future, so there will be more releases soon.