I’ve just released a new module, CatalystX::Routes, which adds a layer of sugar for declaring Catalyst actions (aka URI mapping, routes, etc). Route declarations work together with the Catalyst::Action::REST distribution to make it trivial to declare RESTful actions in your controllers. I’m very excited about this module for several reasons. First, Catalyst’s sub attribute-based action declaration is hideous. I cringe every time I look at it. The syntax is also un-Perlishly picky.

I was looking at some $WORK code recently. It had a lot of “stuff” in configuration. This seemed wrong to me, but I wasn’t sure why it bugged me. Thinking about it more, I realized that I had developed a set of unarticulated rules that guide my thinking about configuration. These guidelines are applicable to more than configuration. A setting can be exposed to non-developers through a configuration file, command line switches, environment variables, etc.

First, my apologies, as this isn’t strictly related to either activism or programming, but it touches on both. Recently, the programming community has been talking about anti-harassment policies in light of a recent incident. More recently, my animal rights group, Compassionate Action for Animals, was confronted with the need to create our own policy. Having a public policy in place is important. It makes it clear that the conference/organization takes harassment seriously, and provides a clear direction on how to report alleged harassment.

I’ve written quite a few new modules in the past few months, but I haven’t really written about them. Here’s a summary of recent(ish) releases. Silki (Ok, this isn’t really recent, since the first release was in May.) Silki is a wiki application built with Catalyst and Fey::ORM. Silki is a multi-tenant wiki hosting system. Translated into English, that means that once you install Silki, you can host many wikis, each of which can have totally different sets of users.

I’ve been thinking of writing some CPAN API review blog posts. There’s a lot of bad APIs on CPAN. But before I pick on other people’s modules, I thought it would be good to start with something of my own. The first release of DateTime was in early 2003. There’s 7+ years of mistakes to review, but I’ll just hit the highlights. Duration and subtraction APIs In my experience, the single most confusing part of the distribution is DateTime::Duration API.

My last blog entry, “What Versions of Core Perl Should Module Authors Support?”, generated a lot of discussion in the comments. There were a number of points raised that are worth addressing. First, in a wild coincidence, RHEL 6 was released the day I wrote the blog entry. It includes Perl 5.10.1, which means that the last major Linux distro still shipping 5.8.x is now a little more up to date.

The new Perl 5 core release schedule raises some interesting questions for Perl module authors. In the past, major version releases of Perl were unpredictable. There were approximately two years from 5.005 to 5.6.0, then another two years to 5.8.0. After that, it took a whopping five years til 5.10.0, and then about 2.5 years til 5.12.0. However, that’s all about to change. The Perl 5 core developers have moved to a timeboxed release plan, and there will be a new major version of Perl once per year.

I often wish that I had an infinite supply of time, motivation, and skill. If I did, I bet I could get a lot done! My programming (and programming-related) todo list includes so many items that I’m quite sure I’ll never get to most of them. Here’s my current list, though I’m probably missing some stuff, in no particular order … CPAN Search $NEXT I’ve been thinking about this for quite some time, but I haven’t really done much with it.

If I were being accurate, this entry would actually be titled “What’s Wrong With Perl 5’s Overloading for People Who Care About Defensive Programming?” If you don’t care about defensive programming, then Perl 5’s overloading is perfect, and you can stop reading now. Also, please let me know so I can avoid working on code with you, thanks. Defensive programming, for the purposes of this entry, can be defined as “checking sub/method arguments for sanity”.

I wanted to turn all the dates in my Changes file into the YYYY-MM-DD format (in this case from things like “Aug 27, 2008”). Here’s my one-liner: 1 2 3 4 perl -MDateTime::Format::Natural -pi -e \ '$f = DateTime::Format::Natural->new; s/^([\d\.]+\s+)(\w+.+)$/$1 . $f->parse_datetime($2)->ymd/e' \ Changes The DateTime project is pretty badass, if I do say so myself. Note that most of the credit here should go to Steven Schubiger for DateTime::Format::Natural