Of Dates, and Sigs, and Shiny Things (and cabbages and kings)

You know, I’ve been trying to analyze my working patterns lately, and I think I’ve hit on something.  Looking back over the past few years, it seems like I get obsessed with one particular project, work frantically on it and produce lots of great stuff, then I get distracted and next thing I know I’m obsessing over an entirely different project.  And then sometimes I circle back around to the first project, but it’s usually a long time later.  I’m actually starting to wonder if maybe I have some undiagnosed ADHD (not only because of the easily distracted, but also because of the hyperfocus, and SQUIRREL!).  Anyways, that appears to be the pattern of my life, so I think at this point I’m just going to have to learn to roll with it.

Now, why would you care about all this?  Well, most probably you don’t.  And that’s fine.  But insofar as you might care, you might care because some of those projects are Perl projects, and many of those Perl projects are CPAN modules (or will be someday (assuming I don’t get distracted (again (sort of like this sentence)))).  For instance, many of you first heard of me in connection with my work on Method::Signatures, which there was quite a lot of, back in the day.  In that particular case, I was aided not only by becoming obsessed with making signatures work in Perl, but also because I could spend $work time on it, which radically increases the amount of code I can crank out.  So I was able to do a lot with MSig, over the course of about a year, before I got distracted by other shiny things, and that was nice, but now it’s feeling a bit neglected and needs some love.1  For instance, I just now noticed that I released a trial version over six months ago that I just plain forgot to promote to a full release.  So ... sorry about that (and it should be there now).  Not much new there except a few compatibility features with native signatures, but still.

The Fifth Element (of YAPC)

This year I attended my fifth YAPC and, as usual, I’ve decided to reflect a bit on the venue, the talks, and the general mood.  Since I just did a (roughly) half-post in my date module series, I figured I’d go ahead and do another (roughly) half-post this week instead of waiting for next week.

A Date with CPAN, Part 11: Sweet Release

[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 cleaned up most of the remaining CPAN Testers failures.  This time I’m getting ready for the first official release.  There isn’t a lot to talk about here, so this will be (uncharacteristically) a short entry in the series.

A Date with CPAN, Part 10: Cleanliness Is Next to Timeliness

[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.

A Date with CPAN, Part 9: Composition Defeats Inheritance Yet Again

[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: