Assuming that the failure happens more than once every few thousand test runs, here’s a handy shell snippet: while prove -bv t/MaxMind/DB/Writer/Tree-freeze-thaw.t ; do reset; done This will run the relevant test in a loop over and over, stopping at the first failure. The reset in between each run makes it easy to hit Ctrl-Up in the terminal and go to the beginning of the test run that failed, rather than having a monster scrollback buffer.

About a million years ago (ok, more like 6 months) a kind soul by the name of Polina Shubina reported a small bug in my Markdent module. She was even kind enough to submit a PR that fixed the issue, which was that the HTML generated for Markdown tables (via a Markdown extension) always used </th> to close table cells. However, there was one problem, there was no test for the bug.

A little while back I asked people to test Params::Validate 1.14. Judging by the lack of bug reports I’m sure that many people tested it and it worked fine. Ok, just kidding. I strongly suspect almost no one tested it and that someone will yell at me for breaking their software. But hey, I tried. Now I’m asking folks to try out MooseX::Params::Validate 0.20. This release makes a rather major change to the exception thrown when a type constraint rejects a value.

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 of CPAN. It has c.

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.

autarch@houseabsolute:~/projects/DateTime-TimeZone (master $>)$ dzil release [DZ] beginning to build DateTime-TimeZone Cannot determine local time zone

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.

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.

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.

You can find them here: Intro to Moose class A Date with Perl Stepford, a Thing Sort of Like Make