This past year of blogging has introduced me to a wide variety of people in the Perl community. Some I’ve admired from afar for years due to their published work, and even more, I’ve “met” while interacting on social media and other forums. This will be the first in an occasional series highlighting not just the code, but the people that make up the Perl family.
Paul “LeoNerd” Evans
I first came across Paul Evans’s work during his series last year on writing a core Perl feature; he’s responsible for Perl v5.32’s isa operator and v5.34’s experimental try/catch exception handling syntax. I interviewed him about the latter for Perl.com in March 2021. He’s been active on CPAN for so much longer, though, and joined the Perl Steering Council in July. He’s also often a helpful voice on IRC.
Avoid Yoda Conditions in Perl You Should
I remember a brief time in the mid-2000s insisting on so-called “Yoda conditions” in my Perl. I would place constants to the left of equality comparisons. In case I accidentally typed a single = instead of ==, the compiler would catch it instead of blithely assigning a variable. For example:
if ( $foo == 42 ) { ... } # don’t do this
if ( 42 == $foo ) { ... } # do this
if ( $foo = 42 ) { ... } # to prevent thisAnd, because a foolish consistency is the hobgoblin of little minds, I would even extend this to string and relational comparisons.
34 at 34 for V5.34: Modern Perl Features for Perl’s Birthday
Friday, December 17, 2021, marked the thirty-fourth birthday of the Perl programming language, and, coincidentally, this year saw the release of version 5.34. There are plenty of Perl developers out there who haven’t kept up with recent (and not-so-recent) improvements to the language and its ecosystem, so I thought I might list a batch. You may have seen some of these before in May’s post “Perl can do that now!”
The feature Pragma
Perl v5.10 was released in December 2007, and with it came feature, a way of enabling new syntax without breaking backward compatibility. You can enable individual features by name (e.g., use feature qw(say fc); for the say and fc keywords), or by using a feature bundle based on the Perl version that introduced them. For example, the following:
A Brief Note on Log4perl
The Java world had an....interesting weekend when security researchers revealed on December 9 a vulnerability in the popular Apache Log4j 2 software library for recording and debugging events. Systems as diverse as Amazon Web Services, Apple iCloud, and the Minecraft video game could be exploited to run arbitrary code on a server merely by sending a specially-crafted string of text. Information technology professionals have been scrambling ever since the initial disclosure to patch, upgrade, reconfigure, or otherwise protect affected servers. It's bad, and past unpatched vulnerabilities like this have been responsible for the exposure of millions of people's sensitive data.
Many Perl applications use the similarly-named and ‑designed Log::Log4perl library, and the good news is that, as far as I can tell, the latter doesn't suffer from the type of vulnerability described above. This doesn't mean poorly-written or ‑configured Perl-based systems are immune to all exploits, just this particular one. You should be safe to continue using Log4perl unless someone has deliberately configured it otherwise, and in fact, my work uses it extensively.
Sweeter Perl Exception Classes
I mentioned at the Ephemeral Miniconf last month that as soon as I write about one Perl module (or five), someone inevitably brings up another (or seven) I’ve missed. And, of course, it happened again last week. No sooner had I written in passing that I was using Exception::Class than the denizens of the Libera Chat IRC #perl channel insisted I should use Throwable instead for defining my exceptions. I’ve already blogged about various ways of catching exceptions.
Why Throwable? Aside from Exception::Class’s author recommending it over his own work due to a “nicer, more modern interface,” Throwable is a Moo role, so it’s composable into classes along with other roles instead of mucking about with multiple inheritances. This means that if your exceptions need to do something reusable in your application like logging, you can also consume a role that does that and not have so much duplicate code. If you're wondering, no, I’m not going to pick a favorite logging module; I’ll probably get that wrong too.
Leveraging CPAN and Perl Modules in Your DevOps Projects
There is an old saying: "Don't reinvent the wheel". This saying is correct, and it is applicable in all areas of our life, including programming. The whole concept of DevOps is to utilize existing tools and resources, so you don’t have to spend hours creating new code from scratch. Due to the powerful benefits it provides, it shouldn’t be surprising that the global DevOps market was worth over $4.3 billion in 2020.
In this article, we will talk about how to optimize our time and our results by learning how to use the modules that are built into CPAN.
Vicious (Test) Mockery of a Perl Modulino
Over the past two years, I've gotten back into playing Dungeons & Dragons, the famous tabletop fantasy role-playing game. As a software developer and musician, one of my favorite character classes to play is the bard, a magical and inspiring performer or wordsmith. The list of basic bardic spells includes Vicious Mockery, enchanting verbal barbs that have the power to psychically damage and disadvantage an opponent even if they don't understand the words. (Can you see why this is so appealing to a coder?)
Mocking has a role to play in software testing as well, in the form of mock objects that simulate parts of a system that are too brittle, too slow, too complicated, or otherwise too finicky to use in reality. They enable discrete unit testing without relying on dependencies external to the code being tested. Mocks are great for databases, web services, or other network resources where the goal is to test what you wrote, not what's out in "the cloud" somewhere.
The Reports of Perl’s Death Have Been Greatly Exaggerated
Look, I get it. You don't like the Perl programming language or have otherwise disregarded it as "dead." (Or perhaps you haven't, in which case please check out my other blog posts!) It has weird noisy syntax, mixing regular expressions, sigils on variable names, various braces and brackets for data structures, and a menagerie of cryptic special variables. It's old: 34 years in December, with a history of (sometimes amateur) developers that have used and abused that syntax to ship code of questionable quality. Maybe you grudgingly accept its utility but think it should die gracefully, maintained only to run legacy applications.
But you know what? Perl's still going. It's had a steady cadence of yearly releases for the past decade, introducing new features and fencing in bad behavior while maintaining an admirable level of backward compatibility. Yes, there was a too-long adventure developing what started as Perl 6, but that language now has its own identity as Raku and even has facilities for mixing Perl with its native code or vice versa.
Everyone’s a (Perl) Critic, and You Can Be Too!
The perlcritic tool is often your first defense against "awkward, hard to read, error-prone, or unconventional constructs in your code," per its description. It's part of a class of programs historically known as linters, so-called because like a clothes dryer machine's lint trap, they "detect small errors with big effects." (Another such linter is perltidy, which I've referenced in the past.)
You can use perlcritic at the command line, integrated with your editor, as a git pre-commit hook, or (my preference) as part of your author tests. It's driven by policies, individual modules that check your code against a particular recommendation, many of them from Damian Conway's Perl Best Practices (2005). Those policies, in turn, are enabled by PPI, a library that transforms Perl code into documents that can be programmatically examined and manipulated much like the Document Object Model (DOM) is used to programmatically access web pages.
A Good Old-Fashioned Perl Log Analyzer
A recent Lobsters post lauding the virtues of AWK reminded me that although the language is powerful and lightning-fast, I usually find myself exceeding its capabilities and reaching for Perl instead. One such application is analyzing voluminous log files such as the ones generated by this blog. Yes, WordPress has stats, but I've never let reinvention of the wheel get in the way of a good programming exercise.
So I whipped this script up on Sunday night while watching RuPaul's Drag Race reruns. It parses my Apache web server log files and reports on hits from week to week.
The Funhouse Mirror of Perl Criticism
I think this is the real point about Perl code readability: it gives you enough flexibility to do things however you like, and as a result many programmers are faced with a mirror that reflects their own bad practices back at them.
-orev, Hacker News
This is why Damian Conway's Perl Best Practices (2005) is one of my favorite books and perlcritic, the code analyzer is one of my favorite tools. Although, the former could do with an update and the latter includes policies that contradict Conway. Point perlcritic at your code, maybe add some other policies that agree with your house style, and gradually ratchet up the severity level from "gentle" to "brutal." All kinds of bad juju will come to light, from wastefully using grep to having too many subroutine arguments to catching private variable use from other packages. perlcritic offers a useful baseline of conduct and you can always customize its configuration to your own tastes.
Perl Debugger Superpowers, Part 2
In March I wrote The Perl debugger can be your superpower, introducing the step debugger as a better way to debug your Perl code rather than littering your source with temporary print statements or logging. I use the debugger all the time, and I've realized that some more techniques are worth covering.
Although I mentioned a caveat when debugging web applications, our apps at work all adhere to the Perl Web Server Gateway Interface (PSGI) specification and thus we can use tools like Test::WWW::Mechanize::PSGI or Plack::Test to run tests and debugging sessions in the same Perl process. (Mojolicious users can use something like Test::Mojo for the same effect.)
The Unknown Design Pattern
If you care about software, you have probably heard about design patterns: MVC, decorators, factories, etc. But there's an awesome design pattern that’s perfect for modeling complex behaviors, but it’s not well-known outside of the game industry.
We’ve built a narrative sci-fi MMORPG named Tau Station. Like many devs, we were quickly hit with the problem of developing complex items. At first, it looked like we wanted to create an Item class and inherit from that.
Perl Can Escape the Lisp Curse
Ten years ago Rudolf Winestock wrote The Lisp Curse, an essay that "attempt[ed] to reconcile the power of the Lisp programming language with the inability of the Lisp community to reproduce their pre- AI Winter achievements."
His conclusion? The power and expressiveness of Lisp have conspired to keep its developers individually productive, but collectively unable to organize their work into complete, standardized, well-documented, ‑tested, and ‑maintained packages that they could coalesce into interoperable and widely-adopted solutions. Everything from object systems to types to asynchronous non-blocking programming and concurrency is up for grabs and has multiple competing implementations.
4 Steps to Blogging Outside the Perl Bubble
The following is adapted from my lightning talk "Blogging Outside the Bubble" at last week's Perl and Raku Conference in the Cloud 2021. You can watch the presentation and download the slides here. Also, a tip: most of this applies to anyone who wants to start a blog.
Let's say you're a Perl developer distraught at the continued decline in usage and mindshare of your favorite language.
You know that you do good work and that your tools and techniques are sound, but the world outside of Perl-specific forums, software archives, social media groups, and regards it as antiquated, out-of-date, or worse, that IT epithet legacy. (And the newer developers haven't even heard of IRC!)
Moving Perl Mojolicious Routes to Their Own Module
A mentee asked me over the weekend if there was a way within a Mojolicious web application to store the routes separately from the main application class. Here's one way. These instructions assume you're using Perl 5.34 and Mojolicious 9.19 (the latest as of this writing) via the terminal command line on a Linux, Unix, or macOS system; make the appropriate changes if this doesn't apply to you.
First, if you haven't already, create your Mojolicious app at your shell prompt:
Perl Can Do That Now!
Last week saw the release of Perl 5.34.0 (you can get it here), and with it comes a year's worth of new features, performance enhancements, bug fixes, and other improvements. It seems like a good time to highlight some of my favorite changes over the past decade and a half, especially for those with more dated knowledge of Perl. You can always click on the headers below for the full releases' perldelta pages.
Perl 5.10 (2007)
This was a big release, coming as it did over five years after the previous major 5.8 release. Not that Perl developers were idle—but it wouldn't be until version 5.14 that the language would adopt a steady yearly release cadence.
A List of Perl List Processing Modules
As previously written, I like list processing. Many computing problems can be broken down into transforming and filtering lists, and Perl has got the fundamentals covered with functions like map, grep, and sort. There is so much more you might want to do, though, and CPAN has a plethora of list and array processing modules.
However, due to the vicissitudes of Perl module maintenance, we have a situation where it's not clear at a glance where to turn when you've got a list that needs processing. So here's another list: the list modules of CPAN. Click through to discover what functions they provide.