[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]

Last time I rearranged our UI to be (hopefully) a bit more intuitive.  This time I want to clean up the remainder of those pesky CPAN Testers failures on our way to the next solid release.

So, the first thing I needed to do was to figure out what all those failures were.  See, as I touched on before, CPAN Testers failures tend to come in groups.  The trickiest part (usually) is identifying the patterns and figuring out what they have in common, which usually tells you what caused the failures.  Once you know what the failures are, it’s often trivial to actually fix them.  Often, but not always.  We have a bit of a mix here, as it turns out.  But first I had to analyze the failures and pick out the patterns.

Except I didn’t have to.  Because the Perl community is awesome, and someone thoughtfully did it for me.  Literally a day or two before I was about to start wading into the fail reports myself, Slaven Rezić (a.k.a. SREZIC on CPAN, a.k.a. eserte on GitHub) opened three GitHub issues wherein he’d already done all the work for me.  So I have to give a big shout out to Slaven: he did the hard part.  And, with the hard work done for me, all I had to do was buckle down and just fix the errors.

[This is a post in my latest long-ass series.  You may want to begin at the beginning.  I do not promise that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.

IMPORTANT NOTE!  When I provide you links to code on GitHub, I’m giving you links to particular commits.  This allows me to show you the code as it was at the time the blog post was written and insures that the code references will make sense in the context of this post.  Just be aware that the latest version of the code may be very different.]

Last time I talked about fixing the worst of the problems CPAN Testers was thoughtful enough to find for me.  As of this writing, my latest trial version has a 59% pass rate on CPAN Testers, which is a major improvement.  It’s still not good enough, of course, but we’ll look at fixing that next time around.  This time I want to talk about eating your own dogfood.

This is a fairly common expression in the places I’ve worked, but, just in case you’ve never heard it, it means very simply that you should be using the products you develop.  This is a pretty simple concept, if you think about it: if you want your products to make your users happy, you need to be their first user, and you need to demand that they make you happy first.  Especially because you’re the person who can most easily fix whatever problems there are.

So once I had Date::Easy in a usable state—even though it’s still a fairly primitive one—I started trying to use it for things.  Nothing important, of course ... just little quickie things, often from the command line.  Quick, easy command line date fiddling should be one of the things that Date::Easy excels at, after all ... if it’s doing its job properly, anyway.  And I quickly ran into this: