I’ve just released a new version of Params::Validate that allows validation callbacks to die in order to provide a custom error message or exception object. This was a long-needed feature, and will enable me to make Moose::Params::Validate support the error messages provided by type objects, which has also been long-needed.

However, I’m a little nervous about any changes to Params::Validate, since it’s used a rather large chunk or CPAN. It has c. 350 direct dependents, and those include things like Log::Dispatch and DateTime, so the actual downstream reach is pretty huge. I’d rather not break some large of CPAN or your in-house applications.

That all said, the behavior of calling die in a callback sub has always been undefined and undocumented, so no one should have been doing it prior to now (I say with forced optimism and the realization that someone probably is doing it anyway).

So please take a moment to install the latest trial release and test it with your code base. If your apps are using a lot of CPAN modules there’s a good chance that Params::Validate is already in your stack, even if you don’t use it directly. If you find any breakage, please report it on rt.cpan.org.

If I don’t hear about any breakage in a week or so and CPANTesters looks good, I’ll release a non-TRIAL version.

We’ve actually been trying to hire someone for a while, but there was some question about what states we can hire from.

First of all, we’re hiring a Senior Software Engineer. This involves a lot of Perl, some Go, and the possibility of C and other languages from time to time. This is mostly backend work, building web services at an ever growing scale. We’re accepting applications for this position from all US states and Canada.

Perl experience is a plus, as is Go. However, we’re happy to consider anyone with some dynamic language experience. Perl is pretty easy to learn if you know Python or Ruby. Our code base is mostly written in Modern Perl using Moose, Plack/PSGI, DBIx::Class, and other good tools like that. We’re slowly weeding out the ancient crufty code, and we’ll be replacing our use of Apache::PageKit with Mojolicious in the future. We also have an extensive test suite built with Test::Class::Moose.

As a bonus or penalty (you pick), I’m the Software Engineering Team Lead, and we’ll be working together a lot.

The entire team is effectively remote, so we coordinate our work through HipChat and Google Hangouts. We also use Pivotal Tracker and GitHub Enterprise, and all new work is done in branches with code review before merging. All new code and bug fixes are expected to come with tests.

We’re also hiring Frontend Software Engineer to help us build single page apps using modern JavaScript. As the first Frontend Software Engineer at MaxMind, you’ll be in a position to set standards for frameworks, testing, and everything frontend-related. For now, this position is defined as being in the office part-time, so it’s local to Waltham, MA. That may change in the future.

Finally, we’re hiring an Interaction Designer to help make these new single page apps user-friendly. Also, you’ll get to make our website much less meh. Please note that the Interaction Designer position is onsite, not telecommuting.

I’ve been playing with the idea of making a new version of Log::Dispatch that breaks some things.

There are a few changes I’d like to make …

First, I want to trim back the core distro to only include a few outputs. This would just be those outputs which are truly cross-platform and don’t require extra dependencies. Right now that would be the Code, File, Handle, Null, and Screen outputs. I might also borg rjbs’s Log::Dispatch::Array, since it’s so darn useful for testing.

Here’s my plan for the other outputs:

  • Syslog – release it and maintain it myself
  • File::Locked – release it once and look for another maintainer
  • ApacheLog – up for grabs
  • Email outputs – up for grabs, but maybe I’d do a single release of the Email::Sender based output and look for a new maintainer

FWIW, I no longer have my programs send email directly. I log to syslog and use a separate log monitoring system to summarize errors and email me that summary.

I’d also like to change how newline appending is done so this has more sensible defaults. This means defaulting to appending a newline for the File & Screen outputs, but not for others like Code or Syslog.

As far as core API changes, while I think the core ->log() and ->debug()/info()/etc() methods would stay the same, I might want to make changes to some of the other methods.

I also plan to move to Moo internally, just to clean things up.

So given all this, what’s the best course of action? Should I just go ahead and release Log::Dispatch 3.0, along with Log::Dispatch::Syslog 3.0, etc.? Or should I actually rename the distro to Log::Dispatch3 or something like that so that the two can co-exist on CPAN? I’m leaning towards the latter right now.

Finally, if anyone has any other suggestions for improvements to Log::Dispatch I’d love to hear them.

Apparently my post on Perl 5’s overloading is deeply, deeply offensive. Here’s an email I got out of the blue today:

Perl isn’t your first language isn’t it?  You strike me as Java programmer.  Look.  Don’t do overloading.  If you need to do overloading then you are probably doing something wrong.

“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.”

No.  I don’t, because we are not programming in Java where that type of mentality is needed.  So yeah, please feel free to memorize my name and lets make damn sure we never work with each other.

And people say there’s no hope for humanity!

I suspect I’m not the only person who does this.

I start writing an email because I’m angry/annoyed/outraged/indignant. I write the whole thing. I sign it. I look at it. Then I discard it.

There’s something therapeutic about this. I get all of the benefits of venting without actually escalating a conflict. I wonder if there’s a market for an email client app or plugin that helps with this?

“While you wrote this email your writing speed was 20% faster than your standard writing speed. Are you pissed off? Are you sure you want to send this?”

Clearly, I’m about to get rich!

I’ve been doing a lot of work on Test::Class::Moose recently and I’ve released a trial distro with my changes.

The highlights in this release are:

  • Support for parameterized test classes – instantiate a class more than once with different parameters
  • Separated the test runner from Test::Class::Moose itself – there is now a new Test::Class::Moose::Runner class so your test classes themselves are not also runners
  • Integrated the parallel runner code into this new runner so you can just pass jobs => 2 to the Runner class and get parallel testing

These changes are (obviously) backwards incompatible so Ovid and I would love to get your feedback on these changes before enshrining them in a stable release. Please comment in the form of RT issues or GitHub pull requests.

The sign up for classes at this year’s YAPC is a little different than before. You sign up by pledging to a crowdfunding campaign on Crowdtilt. If enough people pledge then the class will happen (and you will be charged). So if you’re interested in taking my Introduction to Moose class, please sign up now!

This class is a one day, interactive introduction to Moose. The class will take place on Sunday, June 22, the day before the conference proper begins. The cost of the class is a mere $130 for a full day!

Here’s what one past student said about the class:

Great class. I especially liked your problem sets. You gave out problems you expected your class to actually solve, and you allowed class time for solving them. This should be a basic expectation for any class, but it’s amazing how often teachers don’t do this.

You can find more details about the class content on the class’s crowdtilt page.

I’ve been in Taiwan for about four weeks now. Most of the time I was working remotely (more remotely than usual), but for the last few days I’ve been on a real vacation in Taipei. I’ve had time to kill while my wife talks to her relatives (my Mandarin is not good enough for extended conversations) so I’ve been trying to work through my all too large rt.cpan and GH PR backlogs.

The past year or two I haven’t had as much time or energy for my free software projects as in the past. Part of this is that my current job at MaxMind is generally engaging and interesting. I actually get to work on some neat projects there, including the recently released Stepford. Between work, family health issues, and the time I spend planning events like Twin Cities Veg Fest, I haven’t had much time for FS/OSS work.

But I realized that if I could just allocate a few hours per month I could probably get a lot done, at least in terms of addressing small bugs and patches for my CPAN modules. To that end, I’ve added a new recurring 3 hour block to my calendar every other Sunday labelled “Free Software Sunday”. I’ve given myself permission to ignore that event when it pops up, but it will still be a good reminder.

My apologies to all of you who’ve submitted bug reports and patches in the past and haven’t received a response. If there’s something in particular you want me to look at, please comment on the rt.cpan ticket or GH PR again to remind me.