Sailing the Seven YAPCs


[This is my seventh YAPC / TPC.  If you like, you can read about my other YAPC experiences: YAPC 2011, YAPC 2013, YAPC 2014, YAPC 2015, YAPC 2016, YAPC 2018.]


Well, after taking a very long break inspired (to understate it a bit) by the pandemic, I’m back to attending in-person Perl events with my seventh YAPC.  Or, The Perl Conference, I suppose, but it still feels like YAPC to me.  As per usual, here are some reflections.

A Twist of a Date


Here’s a quickie little post, just to remind everyone of the usefulness of Date::Easy.

Recently, I downloaded some pictures from Google Photos, and unzipped them into my directory of other photos.  I ended up with something that looked like this:
'2024-03-01 09.34.44.jpg'
'2024-03-01 13.18.34.jpg'
'2024-03-31 14.25.27.jpg'
'2024-03-31 14.27.09.jpg'
'2024-03-31 14.27.40.jpg'
'2024-03-31 14.28.23.jpg'
'2024-03-31 14.30.03.jpg'
'2024-03-31 14.33.32.jpg'
'2024-03-31 14.34.10.jpg'
'2024-03-31 14.36.01.jpg'
PXL_20240331_212527635.jpg
PXL_20240331_213601848.jpg
PXL_20240331_212823287.jpg
PXL_20240331_212709501.jpg
PXL_20240331_213332846.jpg
PXL_20240331_212740070.jpg
PXL_20240331_213410146.jpg
PXL_20240331_213003515.jpg

Well! said I.  This is hardly ideal.  A foolish consistency may well be the hobgoblin of little minds, as Emerson once wrote, but there is certainly something to be said for a sensible consistency.  But ... how to achieve it?

Mystery Buglet #2

Hey! I know, I know: long time, no blog.  I would love to blame the pandemic, but the truth is, I just haven’t been inspired with any sufficiently Perl-y topics lately.  Until recently, when I ran into this.

Now, once upon a time, I wrote a post about a small buglet I had encountered.  The post presented the problem, then asked you if you saw the problem, then explained what was going on.  So let’s do that again.  First, the code:
sub generate_temp_file
{
state $TMPFILES = [];
END { unlink @$TMPFILES }
my $tmpfile = `script-which-generates-tempfile`;
chomp $tmpfile;
push @$TMPFILES, $tmpfile;
return $tmpfile;
}

As before, the actual code does a bit more, but I promise I’ve omitted nothing that’s relevant to the bug.  Do you see it?  If not, click to find out more.

TIL about Literate Programming

As a programmer whose first job was in the mortgage software industry, “TIL” has always meant “Truth In Lending” to me: you know, that document that the bank is required to give you when you get a mortgage, that’s supposed to explain how much you’re really paying after all the bank’s hidden finance charges, except the numbers don’t seem to make any sense so you just sign it anyway and don’t know anything more than you did before?  Yeah, that one.

Of course, nowadays it means something else, and I’ve had to redirect my ossified mental patterns into new channels, so that, now when I see “TIL,” I can have my brain recognize it as “Today I Learned.” Which is a handy phrase: it encapsulates feelings of discovery, serendipity, and epiphany all into one.  And TIL1 that the way I’ve always tried to write code has a name, a history, and a venerable progenitor—most of my life, without even realizing it, I’ve been trying to use literate programming (only without the tangling).

To Hardcode, or Not to Hardcode: That Is the (Unit) Test-ion

In my last blog post, there was a bit of a discussion in the comments about whether data in unit tests should be hardcoded or not.  Tom Metro scored the last point with this comment:

We always coach developers to use hard coded test data to the extent practical. When writing tests you have to unlearn a lot of DRY principles. We tolerate a lot more repetition, and factor it out sparingly.

and then I said that this really required a longer discussion than blog post comments would allow.  This, then, is that longer discussion.

So, first of all, let me agree whole-heartedly with Tom’s final statement there: “We tolerate a lot more repetition, and factor it out sparingly.” Absolutely good advice.  The only problem is that, as I noted previously on my Other Blog, we humans have a tendency to want to simplify things in general, and rules and “best practices” in particular.  I don’t think that Tom was saying “always hardcode everything in your unit tests!” ... but I think some people will read it that way nonetheless.  I would like to make the argument that this is a more nuanced topic, and hopefully present some reasons why you want to consider this question very carefully.1