Building stuff!

I’ve said what I’m not doing, but not yet said what I am. I suppose I should do something about that.

Ignoring work for now[1], my current focus is on something called Project Eyeshine, the working title for a photo and video gallery webapp that I’m writing in Perl. Why does the world need another web gallery system, you ask? Buggered if I know what the world wants, but I know my wife and I want one that isn’t crap… and guess what all the web gallery systems out there are? Why yes, they are indeed all crap. I have spent entirely too long trawling through alternatives, and they range from the just-about tolerable to things resembling the collected unholy, festering scrapings from the bottoms of a thousand diarrhoetic devils. None of them are actually good. They either look ghastly, are painfully broken in places, have bizarre and ridiculous dependencies and system requirements, lack important features, seem to have been developed by people besotted with shiny features at the expense of actually useful stuff, or generally appear to have been coded by someone who was teaching themselves PHP as their first language while trying to find every bad practice and security risk they could. This, frankly, will not do.

I’ve made a fair amount of progress, even though I’ve only been working on it since just before Christmas, but in reality a lot of the progress hasn’t been directly on the system itself: it’s been in the framework of classes that sit beneath it (more specifically, improving the implementation of the authentication code to handle auth systems that don’t support password reset, and speeding up parts of the template handling). This framework, imaginatively called Webperl, is another one of my perennial projects – a library of classes and modules intended to simplify the process of developing web applications in Perl. Why does the world want another one of them as well? Well…

• This is Perl: “There’s More Than One Way To Do It” is its motto.
• This is Perl: a very large amount of the code out there is horrible, unreadable, madness-inducing spaghetti lacking any real attempt at code documentation. I don’t write code like that[2].
• Each framework, explicitly or implicitly, tends to impose a specific approach on the developer using it (whether the creators of it admit it or not), which may or may not be the way things work in the developer’s head.
• Most of the web frameworks available when I started this thing (some 10 years ago!) were either too simplistic to be useful, too buggy to be reliable, or so complicated it was faster to write something from scratch than work out how the devil to use them.

The latter point is something that has simply become more pronounced over the years, culminating in things like Catalyst, a framework that eschews such piffling simplicities as including a kitchen sink, instead giving you a dozen different modules for different variations of kitchen sink components (well, actually, more like 500 modules) and expecting you to put them together.

Webperl isn’t intended to be immensely powerful and complicated. It doesn’t do a fraction of the things you can in Catalyst, very intentionally so – if you want that level of power, use Catalyst! But that’s not to say it isn’t decently capable: it is used in half a dozen major projects in work, including running the registration, submission, shortlisting, and judging for a national competition with nearly a thousand entries per year. The key for me is balancing the features the system provides with making it actually usable.

So, yes – a lot of what is likely to appear on here in the nearish future is going to concern either Project Eyeshine, or changes made to Webperl. Hopefully soon, I’ll even be able to link the former so people can poke at it…

[1] not exactly straightforward to do, as much of the stuff I’m doing out of work can actually be repurposed for work, and vice versa!

[2] which I freely admit sounds quite ridiculously stuck up, pompous, snobbish, and self-deceiving, but it’s also frankly true. On any given project, I generally have over 35% of my code given over to comments, webperl is 54.4% comment – and that’s excluding standalone documentation. I react to the “Perl is a write-only language” meme by explicitly setting out to prove it wrong.