So it's back to Perl Iron Man after *mumble* months. And back to square one in Perl Iron Man, thanks to those months, but that's no real surprise - I've always been a lousy blogger because I never seem to be able to find topics to write about on anything resembling a regular basis.

I do have another excuse aside from lack of topics, though: I was too busy writing Perl to bother with taking the time to write about Perl.

What was I writing in Perl, then? FishTwits, "a hub for recreational fishermen around the world to connect and share stories and a place for fishing businesses to reach and establish relationships with their customers." Stripped of the marketing-speak, it's a fishing-related subset of Twitter. It's also not entirely complete, but it's far enough along that I can take the time out to step back, try to regain at least a little Iron Man cred, and work on some other projects.

The FishTwits code is pretty much my own from top to bottom - the only major chunks of CPAN code are DBI, Template::Toolkit, CGI::Fast, CGI::Ajax, and Net::Twitter. The rest is all based on my own collection of OO infrastructure, web framework, and object persistence techniques that I've built up in the course of several other projects over the last few years. While it's all good code, it has the substantial flaw of being code that only I am using.

Maybe I'll generalize some of it and run it up the CPAN flagpole to see if anyone salutes, but, first, I'm taking the opportunity to start up a side project of my own (a space trader game, currently called "Lillon" until I can come up with an actual name for it) and use it to try out some of the modules being pushed under the Modern/Enlightened Perl banners.

So far, I've created a couple classes using Moose, which has worked wonderfully and proven to be much easier than I had expected from my earlier glances at its immense collection of features and correspondingly immense wall of documentation. There's definitely a lot more to Moose than what I'm using so far, but it's doing everything I need from it well enough that I doubt I'll be using my homegrown OO infrastructure again except in cases where startup performance is significant.

With Moose already a given, I'm expecting to be very happy with KiokuDB for persistence, although I haven't really looked at what needs to be done to get that going yet. I've tried getting into DBIx::Class in the past, but it really just doesn't work for me. The first "ORM" I ever encountered (years before I first heard the term) was one which a coworker and I built in Borland Deplhi and called an "object-relational persistence layer". It was set up to treat objects as the first-class citizens and contort the database to match them. Coming from that background, I've never been happy with the typical ORM approach of wrapping an object-like veneer around a database table and claiming it's a class. Kioku seems much more closely aligned with my views on how persistence "should" be done.

The web framework may be another matter, though. I do still intend to look more closely at the major players, but my current impressions, at least, are that they all have at least one of these (to me) fatal flaws:

1. Backpack web servers. Call me crazy, but I think a web framework should stick to frameworking ("do one thing and do it well") instead of coming with an integrated web server. Yes, yes, I know... "But a separate development web server lets you restart it without affecting other services." True, but I do my development on a dedicated machine which offers no public services. I can apache2ctl graceful all day and it won't bother anyone.
2. Heavy use of "helper" scripts. If starting a project with your framework requires running commands like "script/myapp_create.pl model DB DBIC::Schema MyApp::Schema create=static dbi:SQLite:myapp.db", then your framework is too complex. I thought the point of frameworks was to simplify things.
3. Centralized configuration. Maybe I just haven't found the right docs, but Catalyst seems to be the only one that auto-discovers available handlers rather than having one file that contains a master list of all routes/run modes/whatever.

My homegrown framework does, admittedly, take a little effort to set up (mainly because I've never gotten around to packaging it cleanly), but, once it's in place, all I do is create a new MyApp::CGI::Whatever module which contains a list of "actions" that it handles and it gets found automagically (thanks to Module::Pluggable), registers its actions, and we're ready to roll. No helper scripts needed to create the new module, no specific filesystem location where the module needs to be placed, and no need to edit any of the app's existing files. I haven't yet found that kind of ease of use/ease of extension documented in any of the web frameworks on CPAN.

So those are the things I'll be up to within Perl in the near future: Continuing development of FishTwits, learning Moose and (probably) KiokuDB, and either learning a mainstream web framework or packaging my own up for CPAN. With a little luck, this should give me a reasonably steady supply of things to blog about.

And this turned out to be a lot longer than anticipated (I may have trouble finding things to talk about, but, when I do find one, I seem to say a lot...), as well as turning into a bit of a mini-rant about web frameworks. But, hey, at least I'm back to Iron Man.

Hopefully it will last longer than my previous blogging efforts have.