I’ve actually been getting my hands dirty with code again this week – both my existing Catalyst based apps are working fine, so just to keep things interesting I’ve got another two apps as work-in-progress and refactoring the existing ones for translations.
NowÂ that I’ve got my FastCGI monit test running, things have been pretty smooth – Google Analytics reports almost 4 million pageviews across the two sites for the last week. Not too shabby, especially when you consider how much is (not) being spent on hosting them. I still need to find the cause of the lockups (I’m tending towards thinking it’s more to do with long, “killer” requests rather than a problem with the actual codebase as such, and the Catalyst debug log provides me with more than enough information to identify these requests and handle them gracefully). Still this is all old news…
One new development on these existing apps is the translation support. There was an abortive attempt to allow for translations in the codebase they replaced, but it was…less than elegant. So, when I found Catalyst::Plugin::I18N, I was seriously impressed at how easy it is to support multiple languages. On the Perl site, you just add “I18N” to the list of Catalyst plugins, and it Just Worksâ„¢ – no config is really needed. The template side of things, however, is a bit more tricky – wrapping every piece of natural language in 40 template files in a [% c.loc(“This to be translated”) %] is slow, boring and slightly error-prone, but it’s a case of “I’d probably spend more time creating an automatic solution than I would JFDI”. Like Unicode support, though, once you’ve got into the habit, there really is no reason why new templates shouldn’t be written with this from the start. Once done, you run the standard GNU gettext tools (okay, a Perl version of them, which supports TT etc.) and you end up with a standard .po file for translation. I finally had a play with Poedit‘s “Translation memory” feature, and it’s pretty good (although I found I was getting insane numbers of segfaults with poedit, and some of the “fuzzy” translations were very fuzzy!)
I’ve said before how I’ve started using jQuery for the client side of things, and I’m starting to find that now I’m getting more used to it, jQuery is starting to provide me with a similar level of development acceleration that Catalyst was providing on the backend. jQuery really does take a lot of the tedium out of DOM work, with the added bonus of handling all of those annoying JS engine quirks for you. 🙂 Finding a TinyMCE/jQuery plugin was a bit of a bonus as well. So, this new version of the site should hopefully run faster, be easier to add new features to, look nicer and generally be easier to use – I hope the users appreciate it! 😀
The second app is also somewhat exciting. While, technically, there’s no real difference between creating an site for mobile devices and one for “normal” computers, it’s always good fun running otherwise good pages through a validator/phone/PDA and seeing them totally screw up. The mobile web is still another world, with it’s own special rules, but in the coming weeks I’ll be taking a tour of it.
I also believe I’ve volunteered to do a talk at the next Birmingham PerlMongers technical meet in May about developing with Catalyst, which should be “interesting” given that the main lesson I’ve learned while lurking in the #catalyst IRC channel is “Everything I know is wrong”. Still, it’s only a short slot, and provided I steer clear of fine details I should hopefully be able to give a positive impression of Catalyst. 🙂