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:

A Date with CPAN, Part 8: Curse You, Daylight Savings Time!

[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 briefly about the raft of failures that CPAN Testers threw up for me to look at.  I mentioned that there were roughly 3 groups of failures, and that one of them was bigger than the other two.  I even gave a hint as to what it was in one of my examples:

cpan-testers --cache --failure "can still use parsedate normally" Date::Easy

That particular string I was trying to isolate is the test name (that is, the third argument to is1) for my unit test that verifies that I’ve undone my monkey-patching of Time::ParseDate.2  Now, I noted when discussing the decision to monkey-patch3 that I could imagine some problems with re-entrant code.  Which might also apply to threading, so my first thought was to see if this failure only happened on threaded Perls, but that wasn’t it.  Then I discovered a configuration argument4 called “pthread” and for a while I thought that was the correlation.  But it wasn’t.  During this time I was engaging in a bit of a back-and-forth on the CPAN Testers mailing list, trying to nail down how I could replicate building a Perl whose config_args would match that of a given smoker.  If you followed the link I gave you to that discussion, you already know what they told me: it’s the timezones, stupid.  (Well, they were much nicer than that.  But I certainly felt stupid.)