Uncategorized Sending a Slack invite with a Perl CGI script

Sending a Slack invite with a Perl CGI script

a.k.a. “CGI is not dead”

We wanted to invite people to a Slack channel, but Slack provides no automated means of doing so. So we developed a simple CGI script, slack_invite.cgi, that accepts query parameters from a form and calls the Slack API to generate an invitation.

Uncategorized Migrating a Legacy Perl app to AWS

Migrating a Legacy Perl app to AWS

Cloud computing is a growing fact of life in websites and web services. John Napiorkowski (Jnap) is perhaps best known as a lead developer of the Catalyst web development framework, at least until recently. His breadth of experience includes cloud-based web solutions, such as Amazon Web Services, Docker, Linux, and of course Perl. (He’s also …

Read Article Read More

Uncategorized The Perl Conference, Glasgow Roundup

The Perl Conference, Glasgow Roundup

The big news this week in the Perl community was TPC Glasgow (formerly YAPC::EU). I was unable to make it: a pity, as Scotland is on my bucket list. However, a number of attendees journaled their experiences. Tim KingTim King is Lead Developer at The Perl Shop. Tim got his start writing real-time embedded software …

Read Article Read More

Uncategorized How Viable is Perl?

How Viable is Perl?

A few months ago, John D. Cook wrote about the viability of unpopular programming languages. His story starts with a comment about Perl 6, to which someone replied, “Does anyone actually use Perl 6?” (or words to that effect). “My first thought,” he writes, “was, I bet more people use Perl 6 than Haskell, and …

Read Article Read More

Uncategorized Long Import Lists (and available strategies for managing them)

Long Import Lists (and available strategies for managing them)

I ran across this the other day while writing some sample code for the next chapter of Testing Strategies for Modern Perl. How can we use long lists of symbols from an imported package and still keep the code readable? I usually prefer use statements of the form: use My::Module qw(symbol1 symbol2 symbol3); Except for …

Read Article Read More

Uncategorized Why Programmers Use the Test Hierarchy Antipattern

Why Programmers Use the Test Hierarchy Antipattern

The first part of this series described Test Hierarchy, a hierarchy of test classes that mirrors the classes under test, and explained why it’s an antipattern. Part two explored what makes a good unit test and why Test Hierarchy does not. This third and final post reflects on why programmers use Test Hierarchy and why …

Read Article Read More

Uncategorized Testing Insights from B::DeparseTree

Testing Insights from B::DeparseTree

Rocky Bernstein’s recent post about B::DeparseTree contained several insights on testability and writing good tests. Here are my takeaways. Tim KingTim King is Lead Developer at The Perl Shop. Tim got his start writing real-time embedded software for high-speed centrifuges the 1980’s and went on to do embedded software for Kurzweil Music Systems and Avid …

Read Article Read More

Uncategorized Test Hierarchy Produces Poor Unit Tests

Test Hierarchy Produces Poor Unit Tests

The first part of this series described Test Hierarchy, a hierarchy of test classes that mirrors the classes under test, and explained why it’s an antipattern. For how common it is, this practice doesn’t even produce good unit tests. This three-part series has also been published as a combined essay, “Test::Class Hierarchy Is an Antipattern.” …

Read Article Read More

Uncategorized Test::Class Hierarchy Is an Antipattern

Test::Class Hierarchy Is an Antipattern

Test::Class is particularly good at testing object-oriented code, or so it is said. You can create a hierarchy of test classes that mirrors the hierarchy of classes under test. But this pattern, common in Perl projects, is conspicuously missing from the rest of the xUnit world, and with good reason.

Uncategorized DFW Perl Mongers Winter 2013 Deduplication Hackathon: Judging

DFW Perl Mongers Winter 2013 Deduplication Hackathon: Judging

The contest offered a bunch of categories in which you could win. We split them into two groups. The first were objective measures, like speed, memory consumption, lines of code, and Perl::Critic score. The second group were subjective measures, like documentation quality, most (useful) features, packaging (as a reusable application), and best effort (some evidence that a lot of time was put into the code). With our time constraints we would only be able to judge the objective measures prior to the DFW.pm meeting.