Perl Advent Calendar 2025

Pecan's Tale: Migrating a terminal application from Term::ReadLine to Tickit

2025-12-24T00:00:00Z

Pecan: "I've got a terminal application[0] based on a mature audio processing library[1]. The terminal interface uses Gnu ReadLine, a widely used C library accessed via the CPAN module Term::ReadLine::Gnu. Nama was previously covered in the Perl Advent calendar of 2023[2], which began a great deal of head-scratching."

"The problem is I want a facility to process keystrokes immediately, for example hotkeys to control volume or adjust playback position. Not only a command line with parameters, we have that."

"But I have an answer, a second-generation terminal library that represents each cluster of keyboard scan codes as an object. The are a lot of questions you might want to ask this object, and Tickit provides methods for anything you might want to know. Being an OO design, you can use subclassing to alter any of the default behaviors. Another example besides volume control would be overriding the cursor keys to simulate a pager that stops scrolling at the top line of the supplied text."

"I use a scrollbox widget to display terminal output, with a line reserved at the bottom for a text entry widget. Simple, right?"

"The widget hierarchy looks like this:"

Tickit::Async::Loop
&nbsp;&nbsp;&nbsp;&nbsp;Tickit::Term (an object exposing the underlying TermKey library)
&nbsp;&nbsp;&nbsp;&nbsp;Tickit::Vbox (root widget, displays its child widgets as a column)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tickit::Scrollbox (scrollable, eliminates the need for shelling out to less)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TODO: set a stop for scrolling back only the last N lines of output
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tickit::VBox
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tickit::Widget::Text::Static (one line of display text)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tickit::Widget::Text::Static
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tickit::Widget::Text::Entry (anchored to bottom screen line, for prompt and command entry)

Step 2: Redirect file handles

"I'm facing hours of work and tedious bugfixing to convert every routine printing to STDOUT or STDERR to generate a static text object and add it to the scroller widget. There has to be a better way."

In perl, on CPAN, there usually is! Here, it's Tie::Simple[3].

our ($old_output_fh);
sub redirect_stdout {
&nbsp;&nbsp;&nbsp;&nbsp;open(FH, '&gt;', '/dev/null') or die;

		# TODO: Replace the bareword filehandle FH with a scalar, $fh.
&nbsp;&nbsp;# That's recommended practice, right?

		# On second thought, no. A bareword filehandle is necessary
&nbsp;&nbsp;# because Tie:Simple alters the associated typeglob
&nbsp;&nbsp;# object *FH. That object would not be available in a
&nbsp;&nbsp;# reference $fh, which points directly to the associated memory
&nbsp;&nbsp;# location.

&nbsp;&nbsp;&nbsp;&nbsp;FH-&gt;autoflush;
&nbsp;&nbsp;&nbsp;&nbsp;$old_output_fh = select FH;
&nbsp;&nbsp;&nbsp;&nbsp;tie *FH, 'Tie::Simple', '',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WRITE      =&gt; sub {  }, # stub methods are needed
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PRINT      =&gt; sub { my $text = $_[1]; print_to_terminal($text) },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PRINTF     =&gt; sub {  },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;READ       =&gt; sub {  },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;READLINE   =&gt; sub {  },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;GETC       =&gt; sub {  },
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;CLOSE      =&gt; sub {  };
}

sub print_to_terminal ($text) {
&nbsp;&nbsp;&nbsp;&nbsp;$vbox-&gt;add( Tickit::Widget::Static-&gt;new( text =&gt; $text ));
&nbsp;&nbsp;&nbsp;&nbsp;$scrollbox-&gt;scroll_to(1e5); # move cursor to bottom, TODO: there must be a neater way
}

# called on program exit

sub restore_stdout {
&nbsp;&nbsp;&nbsp;&nbsp;select $old_output_fh;
&nbsp;&nbsp;&nbsp;&nbsp;close FH;
}

"I also need to redirect warnings. Here's the new code:"

BEGIN { $SIG{__WARN__} = \&amp;filter_print_to_terminal }

sub filter_print_to_terminal {
&nbsp;&nbsp;&nbsp;&nbsp;print_to_terminal(@_) unless $_[0] =~ /ScrollBox/; # skip spurious warnings related to the ScrollBox object
}

"Our fix doesn't break the following line, which a naive search-and-replace for 'print' or 'say' would miss."

# produce a stacktrace on exception when any logging filters enabled
SIG{ __DIE__ } = sub { Carp::confess( @_ ) } if $category_tags;

Our intrepid elf-hero and his mentor

Hunched over the terminal, in his usual coding posture with keyboard on lap, Pecan the elf knits his brows. Pages of printouts cover his desk and most of the floor around him.

Lybinthia, an elf with decades of CS and IT experience, is watching him struggle. She knows Pecan is not the sharpest knife in the drawer. He makes up for his lack of effortless facility in coding with persistence and a willingness to learn.

After decades of plodding progress and countless dead ends, he's learned to read (at least browse) the documentation of the libraries he uses as fully as possible, knowing that those before him have crystallized their own experience of blood, sweat and tears into the man pages generally supplied with each library distribution installed from CPAN, the Comprehensive Perl Archive Network.

Elves have lots of work to do. Pecan's section of the North Pole Coding Collective is largely a perl shop. They've ignored the fads and marketing, sticking to a language with excellent features, backward compatibility, and a culture of software testing that ensures libraries substantially accomplish what they promise on the package wrapper. (The package metaphor tickles Pecan, because if elves love anything, it is presents with cheerful wrappings and ribbons.)

But in this instance he's been disappointed, three months of hard work paddling upstream against a recalcitrant C-library all for nothing.

Our intrepid reporter, the Ghost of Perl Programming's Future, listens in on the conversation.

"What's your hangup?" Lybinthia (who grew up in the 60s) asks him.

"I'm an elf, not a cat," Pecan sniffs self-righteously, "and therefore never much of a mouser. I work best at the terminal, sharing several consoles with a multiplexing application, usually screen or tmux."

Lybinthia senses a big picture introduction, unfortunately, the only way Pecan talks.

"Besides satisfying my own itches," he says, stretching and scratching his armpit thoughtfully, "my applications are usable by all elves, including those whose accessibility needs require use of a braille display or screen reader, as well as old-fashioned console cowboys."

The latter group is easily recognizable at the North Pole by their Stetson hats, western boots and large belt buckles, a significant contingent of stylish elves that Pecan wants to serve.

Lybinthia: "So, tell me about your program."

The program and its command line (includes shameless elf promotion)

Pecan introduces it with his usual elevator spiel. (Who knew there were elevators at the North Pole?)

"The program's a multitrack audio editing application providing functions for recording, editing, mixing and mastering sound files via a command prompt, In other words, it's modeled on the unix command shell. Despite its small code footprint, it provides a lot of what you'd find in other DAW software such as Audacity or ProTools. I also think it's easier to use, as you never need to remember which command is under which menu."

"The prompt tells the user key information: the currently selected project, bus, track, effect plugin, etc. With most commands, you don't need to specify the object to modify, making inputs concise."

"Like my hero programmers who created unix, I'm trying to get the most results from the fewest keystrokes, while keeping it all memorable. When memory fails, there's a help facility with listings by category, command and text search. I really am proud of it."

Grammar

Lybinthia: "How do you process the commands?"

"While there are more modern libraries nowadays, I use Parse::RecDescent[4] to generate the parser for Nama's command grammar.

"The parser takes a command line, identifies the command name (generally the first token in the command line) and fires off the corresponding subroutine with whatever parameters are provided."

"And if the command has a syntax error?"

"It falls through the grammar, printing the unparseable command with a warning and (generally) no other effects."

"What about features like command history and tab completion?"

"They come for free with ReadLine."

"So all is good then, isn't it?" she asks. "What is the exact problem you're having with ReadLine?"

No direction HOME

"The problem is I want a facility to process keystrokes immediately, for example using cursor keys to control volume or adjust playback position, not always a command name with parameters terminated by newline.

"I've been trying to do this for months, now feel like I'm ready to slit my wrists, both of them, with a rusty knife."

"One wrist would probably be enough," notes Lybinthia with a grimace. "Doesn't ReadLine provide all this? I mean, any terminal based music player available for linux has keys for these functions."

"That's the rub. While all that works well enough from C, in perl we use Term::ReadLine::Gnu to access the ReadLine library, and this glue code doesn't support all the bells and whistles available through straight C."

"Didn't you know that from the docs?"

"No, the main reference is the docs for the C library, and of course, they have no idea what ReadLine-via-perl can or cannot do."

"It took me quite a while to get as far as I have. Especially setting up an event loop so I can have a background process like playing an audio clip while executing and processing commands in the foreground, firing off subroutines when certain events occur, like reaching the end of a clip."

"I had to cargo cult my way through it. It took forever, now I have to migrate to a new library. At least I have a library to migrate to." Pecan pauses to touch his scalp.

Lybinthia: "It's a good thing elves live a long time."

"Well, my supervisor doesn't like it. He's worried about my graying hair and the sores I developed from scratching my head."

"So where are we now?"

That's the Tickit

"As I was saying, I found a solution, now just trying to migrate over. The new shiny is Tickit, a terminal handling library by Paul Evans. Paul is a prolific perl core contributor, maybe even luminary. It's a high level approach that builds on his previous effort in this area, a C library and perl wrapper called TermKey. It's easy to intercept any keystroke and fire off whatever subroutine you want."

"Isn't Tickit the library Paul used as a testbed while developing Object::Pad?"

"Yes, the same." Tickit integrates well with IO::Async, also by Paul Evans, with adapters to several other event loops."

Object::Pad is great, by the way, and as late-generation take on perl OO, it's quite a bit easier to use and to read. Now finding its way, step by step, into the perl core. You can look at the new class syntax.[5]

"If Tickit is a high level API using widgets, it should be easier than ReadLine was."

"Yes, that's true, but there is a bit of a mismatch. For ReadLine all I need to do is print lines to STDOUT, however for outputs longer than the number of screen lines, we currently call out to a pager application, in this case 'less.'"

"With Tickit, I use a scrollbox widget to mimic the way text scrolls up a terminal.

"The problem is that I have various subroutines that print to STDOUT. I feel daunted about having to change them one-by-one, having suffered through previous refactoring efforts, such as converting Nama's data structures from hashes to objects. Without AI help (which I'd mistrust anyway) I'm facing hours of work and tedious bugfixing to convert some 70 routines printing to STDOUT or STDERR to generate a static text object and add it to the scroller widget. I've engaged in the whack-a-mole before, and don't like it. I always end up missing something."

Here was where Lybinthia gave Pecan some vital advice. In perl (and probably any other language worth its salt) you can redirect any file descriptor including STDOUT and STDERR.

After a couple of false starts, he ended up using Tie::Simple to trigger a subroutine on each print action.

"Also, I'm finding I need to change over event loops because of some compatibility issues with AnyEvent."

"Well, apply yourself, Pecan, I'm sure you'll find a suitable hack, you always do -- usually in the shower. We hear you talking to yourself there, a dialogue of two parts in squeaky and basso profundo voices."

"Yes" said Pecan, turning a beet red that matched his cap perfectly, "that's what works best for me."

Within a short time, he'd whipped up a wrapper, mapping the AnyEvent AE::timer function calls to IO::Async event loop that better integrates with Tickit. Depending on the parameters, it calls either IO::Async::Timer::Countdown ( for a one shot timer) or IO::Async::Timer::Periodic (for polling.)

Converting the code was a simple search-and-replace. For example:

-       $project-&gt;{events}-&gt;{poll_engine} = AE::timer(1, 0.5, \&amp;poll_progress);
+       $project-&gt;{events}-&gt;{poll_engine} = timer(1, 0.5, \&amp;poll_progress);

And the wrapper code looks like this:

sub timer ($delay, $interval, $coderef ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $timer;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ($interval == 0){
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$timer = IO::Async::Timer::Countdown-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;delay =&gt; $delay,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;on_expire =&gt; $coderef,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$timer = IO::Async::Timer::Periodic-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;interval =&gt; $interval,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;on_tick =&gt; $coderef,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$timer-&gt;start;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$text-&gt;{loop}-&gt;add($timer);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$timer
}

When the basic coding was done, and both had clocked out for the day, the two elves poured themselves a shot of brandy, toasting Larry Wall for a language of manipulexity and whipuptude, bywords he'd coined for Perl's facility at making easy things very easy and hard things possible. Which other language can boast such a combination!

A Quick Response

2025-12-23T00:00:00Z

Cautiocus smiled as he checked over the Workshop Safety Questionnaire one last time. In all his years as Assistant Head of the Elf & Safety Directorate at the North Pole's busy Toy Workshops, no-one had so much as caught their thumb with a hammer in the run-up to Christmas, despite the huge demand for beautifully fashioned Jack-in-the-Boxes, spinning tops, walkable dogs, dolls, yo-yos and all sorts of toys. Cautiocus' attention to detail was considered impressive even for an elf.

He flipped the intercom switch on his desk. "Fry, I'm happy with the survey. Let's get it out!" The Workshop Safety Questionnaire was a vital part of Cautiocus' carefully layered procedures to make sure no elf had to spend the festive season nursing a sore thumb due to an overlooked unsafe working practice.

The elf paused again, thinking. The survey had a long URL, and the workshops' Lead Joinery Elves were very busy. He had already arranged free tickets for all respondents to a Yuletide performance with Bilbo Frostby, the North Pole's favourite crooner. Incentives were all very well, but he also had to make answering the survey as frictionless as possible. He flipped the switch again. "Fry, what was that article you were talking about?"

The Assistant Head's assistant entered holding the latest issue of Polar Web Monthly. "Here you go, boss. It's called 10 ways to boost online survey responses." Cautiocus scanned the text; one of the sections caught his eye.

    5. Use a QR code for the survey link

    The folks you want to hear from have plenty to do already! Do they all have time to type in a long, cumbersome URL, especially on a portable device? Even if they do, what if they mistype it? Will they have the patience to try again, or will they conclude that the survey is down? If your survey link is longer than about 15 characters, or has any kind of numbers in it, let alone hex or a GUID, you&#39;ll be lucky to hear from anyone!

    Instead, use a &#39;QR code&#39;: a square design encoded with your weblink which respondents can scan with their mobile devices to take them straight to your questionnaire!

    Create a free QR code at:
    https://gr8.arcticinternet.northpole/qrcode

"This is it!" Cautiocus said. "Don't send the actual survey link out on the workshop order sheets. Hardly any elf got back to us last year because the SurveyFlunkey URL was hard to type. Use one of these instead!"

Fry generated a 'QR code' using the handy webapp mentioned in the magazine and uploaded it to the Central Workshop server so it could be added to the toy order lists sent out to all elf workshops. Cautiocus checked the QR code one more time with his Elfone and smiled in quiet satisfaction, looking forward to the replies rolling in.

Fry brought up the survey dashboard on a large display on the wall of Cautiocus' office in the warm Safety Cabin so they could monitor the responses in real time. After returning with two mugs of cocoa, he was delighted to see that five responses had already appeared.

The next day

Cautiocus entered the office the next morning. He stared at the display with concern. Still the same five responses! He summoned Fry, who tried refreshing the page. It came back just the same!

Feeling queasy, Cautiocus tested the QR code again. Calamity!

the unfortunate QR code

Gr8 Arctic Internet apparently stood for 'Grinch Ate the Arctic Internet'. His QR code now led to a page on their website demanding all the toys bound for children in the Nordic countries in order to reenable the survey link – and suggesting the children deserved coal instead!

This was an emergency. Cautiocus put his pointy hard hat on and called the IT Helpdesk. "We're sending down Tech Elf Tania now," he was told.

Techie Tania whirls into action

Tania shot in 45 seconds later. "I hear you have a problem with your survey!"

Cautiocus glumly indicated the sample order sheet. Tania scanned it with her own Elfone. Up popped the Grinch's webpage, with his grisly green mien glowering out of it, eager to ruin Christmas for millions of children.

"What happened?!" cried Cautiocus. "Did that old rogue hack into our servers?"

"Well, no," Tania responded. "Did you get this QR code from an external provider?"

"Yes... I thought they were called 'Great Arctic Internet'."

"There's the problem. By sweet-talking a local journalist and masquerading as a respectable Arctic business, the Grinch has managed to persuade local elves, including you, to use his QR code generator. It never pointed to your survey, just to a GrinchNet URL that originally redirected to your survey ... but now to something far less beneficent!"

"What can we do?"

"Well, the first thing is to generate a QR code to your actual survey. Fortunately I have just the Perl script! It uses the Imager::QRCode distribution by Yoshiki Kurihara to output QR codes of various kinds. You can even choose the colours! Though, say, dark blue and purple together won't work very well, of course."

#!/usr/bin/env perl

use strict;
use warnings;

use Imager::QRCode;

my $qrcode = Imager::QRCode-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;size          =&gt; 4,
&nbsp;&nbsp;&nbsp;&nbsp;margin        =&gt; 1,
&nbsp;&nbsp;&nbsp;&nbsp;version       =&gt; 1,
&nbsp;&nbsp;&nbsp;&nbsp;level         =&gt; 'L',
&nbsp;&nbsp;&nbsp;&nbsp;casesensitive =&gt; 1,
&nbsp;&nbsp;&nbsp;&nbsp;lightcolor    =&gt; Imager::Color-&gt;new(255, 255, 255),
&nbsp;&nbsp;&nbsp;&nbsp;darkcolor     =&gt; Imager::Color-&gt;new(0, 0, 0),
);

my $message = shift;

die 'must provide message' unless $message;

my $img = $qrcode-&gt;plot($message);

$img-&gt;write(file =&gt; &quot;qrcode_&quot;. time() . &quot;.gif&quot;)
&nbsp;&nbsp;or die &quot;Failed to write: &quot; . $img-&gt;errstr;

Tania ran the script inputting the URL for Cautiocus' safety survey and a new QR code appeared.

She scanned the new QR code on her Elfone and up popped the safety survey. Cautiocus and Fry beamed!

"Well done, Techie Tania! But what about the old QR code?"

"That's a bit more difficult. But we can certainly configure our enterprise routers to redirect the GrinchNet URL back to your survey. That'll work for any device connected to the workshop WiFi. Not so much if they're outside, though."

Cautiocus was delighted. "That'll do. Merry Christmas, Tania. Will we see you at the Bilbo Frostby gig?"

"I'm looking forward to it. Merry Christmas."

Bit vectors save space on Santa's list

2025-12-22T00:00:00Z

The number of children in the modern world has strained Santa's meager on-sleigh systems. Back when he first started, he was consulting a scroll the elf handed him as he left the North Pole. When the scroll got too unwieldy, an elf intern created a small Naughty/Nice (NN) database that Santa could install on the ancient navigation system, but space was running tight since Santa had once been told that 640k should be enough for anyone (someone is permanently on the Naughty list). He had plans for upgrades, but there was always something more important. The bar code scanner subsystem he added had cut down on mis-gifting (ever got a present you didn't expect?), but that didn't leave enough space for the NN database. Something needed to happen.

There was an ancient elf, long since retired, who had an idea, and Santa brought him out of retirement for a special assignment. This was a make-or-break effort; mess this up and Santa might have to cut out the parts of the world he couldn't fit into the meager memory he had left. "Greybeard Elf," Santa said, "you have to save Christmas." Greybeard Elf responded "Again?" There's a reason these elves retire.

Greybeard Elf had fixed all the COBOL programs on December 24, 1999, so Santa was expecting big things. Greybeard Elf corrected Santa: "No, you expect small things, and I'm going to use the smallest of small things."

Since every present was already bar-coded and every child had been assigned a special Santa Number, the trick was to see whether that number was Naughty or Nice. Santa doesn't have time for anything fancy. Just tell him yes or no.

Greybeard Elf, versed in the ways of C and Perl, did everything with bit fiddling even before the definition of the byte standardized on 8 bits. If he represented every child as a single bit, he could do it all in about 300 MB on an SD card he could put in a Raspberry Pi he would stick to the sleigh. "Green means Nice, red means Naughty", Greybread Elf said.

Perl, in particular, makes bit fiddling easy through `vec`, a built-in function to manipulate regular strings as if they were bit fields. It lets you set the width of the group of bits (in powers of two up to 64), then access it similarly to a list.

Greybeard Elf showed Santa an example of setting a single bit:

use v5.42;
my $bitmap;
my $WIDTH = 1;

my $pos = 13;

vec( $bitmap, $pos, $WIDTH ) = 1;
say show_bitmap($bitmap);

sub show_bitmap ($b) {
&nbsp;my $bits = 8 * length $b;
&nbsp;my $s = join '',
&nbsp;&nbsp;map { vec($b, $_, $WIDTH) ? '+' : '.' }
&nbsp;&nbsp;0 .. ($bits - 1);
&nbsp;}

This set the 13th bit, extending the string as necessary to access a bit position. The output was a visual representation of the entire bit string, with a dot representing 0 and a plus sign representing 1. The 12th bit, counting from 0, is on (true, 1, whatever):

 .............+..

Reading the bit field is just as easy. If you don't assign to `vec`, you get the answer back:

my $nice = vec($b, $pos, $WIDTH);

Short and simple. No need for tricky services or programs. Santa said "Okay, whatever, I just need it to work!" in the way managers try to get out of these sorts of conversations quickly.

Greybeard Elf showed off another trick. These are just strings, so you can change characters in that string. What's the difference between "perl" and "Perl"? It's just one bit:

{
&nbsp;my $bitmap = &quot;perl&quot;;
&nbsp;say show_bitmap($bitmap);
&nbsp;vec($bitmap, 5, 1) = 0; # bits are reversed within the byte
&nbsp;say $bitmap;   # &quot;Perl&quot;
}

And, this even works on memory-mapped files. For example, you can start with a file that holds a string that is wide enough for all the bits that you might want to set. The string could be all null bytes (which is different than the character "0", which has set bits). Once you have the file, you can then read or set bits, and whatever you do is persistent:

use v5.36;

use File::Map qw(map_file);

my $FILENAME = 'naughty-nice.db';
my $BITS = 56;

{ # this is just to set up the &quot;pre-existing&quot; file
open my $fh, '&gt;', $FILENAME;
print {$fh} &quot;\000&quot; x ($BITS/8);
close $fh;
}

map_file my $bitmap, $FILENAME, '+&lt;';  # file must exist
foreach my $i ( random_numbers($BITS, 13) ) {
&nbsp;vec( $bitmap, $i, 1 ) = 1;
&nbsp;printf &quot;%3d: %s\n&quot;, $i, show_bitmap($bitmap);
&nbsp;}

sub random_numbers ($max = $BITS, $n = 10) {
&nbsp;my @a = map { int rand $max } 1 .. $n;
&nbsp;}

sub show_bitmap ($b) {
&nbsp;my $bits = 8 * length $b;
&nbsp;my $s = join '', map { vec($b, $_, 1) ? '+' : '.' } 0 .. $bits - 1;
&nbsp;}

The output shows the bit vector after each bit operation. Note that some bit positions (10, 14, 43) are "set" twice, which just means they remain set. You can only be Nice once, no matter how nice you are:

  27: ...........................+............................
  54: ...........................+..........................+.
  43: ...........................+...............+..........+.
  12: ............+..............+...............+..........+.
  45: ............+..............+...............+.+........+.
  10: ..........+.+..............+...............+.+........+.
  43: ..........+.+..............+...............+.+........+.
  49: ..........+.+..............+...............+.+...+....+.
  35: ..........+.+..............+.......+.......+.+...+....+.
  14: ..........+.+.+............+.......+.......+.+...+....+.
  10: ..........+.+.+............+.......+.......+.+...+....+.
  14: ..........+.+.+............+.......+.......+.+...+....+.
  17: ..........+.+.+..+.........+.......+.......+.+...+....+.

But that's not all. Greybeard Elf wants to know Nice children count. You could test each bit individually, but there's a trick with `unpack` that counts the set bits. The `%` provides a checksum of the value (and the `*` is just a repetition of the field):

say &quot;Unique numbers seen: &quot; . count_bits($bitmap);

sub count_bits ($b) { unpack(&quot;%32b*&quot;, $b) }

I (the author) adapted this example from a particular task I had. Working in a shared container provided to me in which I had no special privileges, I had to count unique IPv4 addresses found in a series of PCAP files. There can be about 3.7 billion of those, excluding the private or reserved addresses. Accumulating these in a hash not only created billions of keys, but each key was itself 4 (packed) bytes. That's a lot of memory, and it was a bit slow.

I only needed to know if a set of IP addresses was part of the data, and I didn't care at all about how many times. In a hash, this would use `exists` to check the key and ignore the value (so undef would be a fine value). With `vec`, I merely look at the bit position that matches the numeric value of the IPv4 address.

And, I could easily save the result and inspect it later without loading a big data file that I would have to parse. I did try freezing with `Storable`, but I knew that wasn't going to work. But it gave me something to do as the problem worked itself out in the back of my head. The output sizes were just too large, and I had too many files to create. With the bit string, roughly one file per every hour of the last four years, with each one file about 400 MB (about 10 GB a day, 4 TB a year).

Part of the problem is that Perl values aren't just values, but carry along all the baggage of Perl SVs, the underlying data structure that tracks all the magic and other things a scalar value knows about itself. This is many times larger than the size of a small value, such as an IPv4 address, and it's repeated for every value. Even an undefined value in an SV takes up quite a bit of space, and a short string takes up much more:

 $ perl -MDevel::Size=total_size -E &#39;my $x; say total_size(\$x)&#39;
 24
 $ perl -MDevel::Size=total_size -E &#39;my $x=q(1); say total_size(\$x)&#39;
 48

So, using a hash to count even a small fraction of the IP space takes up much more space, and counting a significant portion of it smashes the stack.

The Gift of Readability

2025-12-21T00:00:00Z

Night Shift at PDN Headquarters

At the Present Delivery Network headquarters, December nights were always long.

The elves — engineers by trade, magicians by necessity — sat beneath glowing dashboards tracking sleigh routes, Aurora Borealis hit ratios, and reindeer latency.

All of it powered by Perl. Old Perl. New Perl. Perl written by elves long retired to toy-making or cloud-making. Perl written by skilled masters. Perl written by babies.

She rubbed her eyes.

Three hours. Three hours she'd been trying to understand this function. Three hours to fix what should have been a five-minute bug.

The Present Delivery Network ran flawlessly — millions of gifts delivered every year with magical precision. But behind the scenes, the elves maintaining the codebase were drowning in their own cleverness.

This code worked perfectly for ages, yet recently it stopped feeding Rudolph. And it is utterly incomprehensible for her.

for my$r(@$rslts){push@${${$r-&gt;{feed}//next}-&gt;{$r-&gt;{reindeer}//next}},getPreferredReindeerFuel($r-&gt;{name}//next,$r-&gt;{prefs})if!!$r-&gt;{active}==!!1;}

“Why,” she whispered to the empty office, “why do we do this to ourselves?”
"The Present Delivery Network was designed to be efficient."
"This code … less so."

She thought about the astigmatic, colour-blind elf, squinting at compressed code through his magnifier. She thought about the foreigner elf, parsing English as their second language. She thought about the new elf starting after the holidays, terrified to touch anything.

And so began the quiet refactoring ...

The Invisible Barrier

The Capability to Read is Not Given

Readable code isn't just about aesthetics or dogma.

It is about politeness. It is about inclusiveness.

It is about respecting the time others have to spend dealing with our, ehm, work. Time spent in code review. Time lost while hunting bugs. Time newcomers need before they dare to change a line.

We often forget that reading code is a learned skill layered on top of another learned skill: reading English.

Whilst most programming languages and source code use English-based syntax, only about 400 million people speak English as their native language. Another about 1.5 billion speak it as a second language. Even among those who do, reading dense technical English is a different skill from ordering coffee or chatting about the weather.

As an example, try to quickly read my favourite German word:

Rindfleischetikettierungs&uuml;berwachungsaufgaben&uuml;bertragungsgesetz

For those who do not speak German, it means:

The law for the delegation of duties for the supervision of the labelling of beef.

Without delimiters, the brain struggles to find word boundaries. Code is no different.

Machines execute instructions flawlessly; humans do not. Code is written once, but read many times, often by people who were not present when the first line was typed.

How Humans Actually Read

When children learn to read they don't read words as whole units. They decode letters, syllables, fragments. Adults learning a foreign language do the same.

Reading is a learned skill.

The cognitive process of reading involves a delicate dance of fixations (pauses where the eye rests to process information) and saccades (rapid eye movements between fixation points).

Efficient readers generally have shorter fixations and longer saccades.
Better comprehension comes from familiarity with language, vocabulary, and topic.

Compare:

calculateUserAccountBalance
calculate_user_account_balance

Snake case provides explicit visual boundaries. The eyes don’t have to guess where words end. For non-native readers, tired eyes, or magnified screens, those underscores are not just style: they are guidance.

Yes, you can learn to read camelCase efficiently, just like you can learn vocabulary of a foreign language. But learning costs time and energy. Readable code spends less of both.

As an extreme example, try to quickly read my favourite German word:

Rindfleischetikettierungs&uuml;berwachungsaufgaben&uuml;bertragungsgesetz

Do Germans have a problem with such long words? Perhaps they do.

Reading is a learned skill, and reading also includes the vocabulary of words you are familiar with. Yes, you can learn to recognise even such monsters.

However, since you should learn the business domain rules regardless, you should use that knowledge and your brain's capability to combine common words into known expressions.

The Table Principle

The human brain excels at processing tabular organization.

Compare the hash definition in the PDN code:

my %config=(host=&gt;'localhost',port=&gt;5432,user=&gt;'admin',timeout=&gt;30);

Versus:

my %config = (
&nbsp;&nbsp;&nbsp;&nbsp;host    =&gt; 'localhost',
&nbsp;&nbsp;&nbsp;&nbsp;port    =&gt; 5432,
&nbsp;&nbsp;&nbsp;&nbsp;user    =&gt; 'admin',
&nbsp;&nbsp;&nbsp;&nbsp;timeout =&gt; 30,
);

The Version Control Revolution

Modern development is collaborative. We live in the age of Git, where every change is tracked, reviewed, and discussed. Yet how often do we write code that makes reviewing diffs a nightmare?

She pulled up a recent code review. The commit showed:

-my %user = (name =&gt; &#39;Alice&#39;, email =&gt; &#39;alice@examp1e.com&#39;, role =&gt; &#39;admin&#39;);
+my %user = (name =&gt; &#39;Alice&#39;, email =&gt; &#39;alice@example.com&#39;, role =&gt; &#39;admin&#39;, department =&gt; &#39;Engineering&#39;);

Wouldn't it be easier to review this?

my %config = (
&nbsp;&nbsp;&nbsp;&nbsp;name       =&gt; &#39;Alice&#39;,
-    email      =&gt; &#39;alice@examp1e.com&#39;,
+    email      =&gt; &#39;alice@example.com&#39;,
&nbsp;&nbsp;&nbsp;&nbsp;role       =&gt; &#39;admin&#39;,
+    department =&gt; &#39;Engineering&#39;,
);

One line fixed. One line added. One concept changed. Perfect clarity.

Trailing Commas: The Unsung Heroes

In the diff-friendly example above, notice the trailing comma after admin? That comma means when you add department, you only change one line. Without it:

-    role       =&gt; &#39;admin&#39;
+    role       =&gt; &#39;admin&#39;,
+    department =&gt; &#39;Engineering&#39;,

Two lines changed for one concept. Trailing commas keep your diffs clean and prevent noisy changes. The goal is not minimal characters, but minimal surprise.

The Lexical Consistency Principle

She opened another file:

my $user    = get_user ($id);
my $order   = fetch_order ($order_id);
my $product = lookup_product ($sku);

"Are these different operations? Or just different words for the same thing?" she wondered.

Humans build mental dictionaries while reading code. If one word means one thing here and something else there, the dictionary collapses.

This is cognitive overload in action. When every developer uses their favourite verb, readers must constantly translate. Consistent vocabulary is kindness.

Prefer verbs with contracts, e.g.:

find — Always returns at least one element; or throws a "not found" exception
search — Try to find; or return an empty result set

Look into dictionaries. Google's query explain search literally returns try to find.
fetch — Retrieve data from an external source (API, file, database)
create — Create a domain entity (external interface)
build — Create a domain entity (internal interface)
ensure — Returns true if state matches expectations, throws exceptions otherwise
validate — Check if data meets criteria without throwing exceptions, returning true on success
exclude — Filter-out operation
include — Filter-in operation

Avoid verbs like:

get — Too generic. Consult a thesaurus; this verb has dozens of meanings
filter — Inconclusive. Better to use include or exclude
maybe — Such logic is part of the method's contract; the method should decide what to do
return — Redundant when used as a verb in method names
sanction - autoantonym (e.g.: sanction_trade_with_russia)

It is always a good idea to summarize such verbs and their project meaning in a glossary.

When everyone speaks the same language, code becomes self-documenting.

For more examples, see: https://gist.github.com/happy-barney/1ee36e693751dbbfc046a268cde258de

The Gift of Readability Manifesto

As dawn broke on Christmas morning, she compiled her learnings into a gift for her team - The Gift of Readability Manifesto.

1. Use snake_case Everywhere

Even in package names. UserAccountManager becomes User::Account::Manager or User_Account_Manager, variables become $user_account_balance, constants USER_ACCOUNT_MANAGER.

Exercise: play with terms "settable" and "set table".

2. Indent with Tabs

One tab equals one indentation level. No such things as "half-level".
Do not specify tab width in your project.
Let each contributor configure their editor to their preferred width (2 spaces, 4 spaces, 8 spaces - whatever they like).

Every modern editor supports this.

The visualisation of indentation is not a choice of the writer or the project; it is choice of the reader.

Every person prefers different visual length of indentation. I have worked on projects that used 1, 2, 3, and 4 spaces for indentation. I even worked on one project that consisted of three different parts, each using a different language and a different indent width.

Conversely, when you begin to treat a hard tab as the declaration of one indent level, life becomes easier for everyone.

3. Never Align on Lines with Different Indentation

4. Use Paired Characters as Quoted Operator Delimiters

It reduces the number of backslashes you need to use:

q (function () shouldn't return &quot;$foo&quot;);
qr (a/b);

# vs

'function () shouldn\'t return &quot;$foo&quot;';
&quot;function () shouldn't return \&quot;\$foo\&quot;&quot;;
qr/a\/b/;

5. Space Around Operators and Keywords

Make breathing room:

if (! $condition) {
&nbsp;&nbsp;&nbsp;&nbsp;function_call ($arg =~ m (...));
}

# Not:
if(!$condition){
&nbsp;&nbsp;&nbsp;&nbsp;function_call($arg=~m/.../);
}

Examples of proper and consistent spacing:

if (), function (), q (), s () ()
(! condition)
$x = $y + $z

6. One Line, One Concept

When writing multiline expressions, each line should contain either:

Complete information (opening and closing parenthesis on the same line), or
A single piece of information (opening parenthesis as the last character)

The left parenthesis is either on the same line as its counterpart or is the last character on a given line.

# Good: complete expression on one line
my $result = calculate ($param) + other_function ($other);

# Good: leading operators on line signals that there is more in usage of such symbol.
my $good
&nbsp;&nbsp;&nbsp;&nbsp;= calculate ($param)
&nbsp;&nbsp;&nbsp;&nbsp;+ other_function ($other)
&nbsp;&nbsp;&nbsp;&nbsp;;

# Good: opening paren ends line, closing paren starts line
my $good = calculate (
&nbsp;&nbsp;&nbsp;&nbsp;$param,
&nbsp;&nbsp;&nbsp;&nbsp;other_function ($other),
);

# Bad: mixed structure
my $bad = calculate (
&nbsp;&nbsp;&nbsp;&nbsp;$param ) + other_function (
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$other );

# Bad: opening paren mid-line
my $bad = calculate ($param,
&nbsp;&nbsp;&nbsp;&nbsp;other_function ($other));

# Good: each element on its own line
my $good = (
&nbsp;&nbsp;&nbsp;&nbsp;'alpha',
&nbsp;&nbsp;&nbsp;&nbsp;'beta',
&nbsp;&nbsp;&nbsp;&nbsp;'gamma',
);

# Bad: inconsistent breaks
my @bad = (
&nbsp;&nbsp;&nbsp;&nbsp;'alpha', 'beta',
&nbsp;&nbsp;&nbsp;&nbsp;'gamma'
);

What if these values belong to logical groups?

Solution: Name the logical group and use the group name (or an appropriate data structure) to contain these values instead of defining them individually.

Principle: Do not mix different kinds of information or concepts within a single grouping. Groupings should follow the Single Responsibility Principle.

my @modern = (
&nbsp;&nbsp;&nbsp;&nbsp;'alpha',
&nbsp;&nbsp;&nbsp;&nbsp;'beta',
);

my @deprecated = (
&nbsp;&nbsp;&nbsp;&nbsp;'gamma',
);

my @good = (
&nbsp;&nbsp;&nbsp;&nbsp;@modern,
&nbsp;&nbsp;&nbsp;&nbsp;@deprecated,
);

What if these values form lists that are too long?

Put list into function / constant. Order them (usually alphabetically). Split them into groups.

my @good = My::Good::Values-&gt;ALL_GOOD_VALUES;

Epilogue

The office filled again. They gathered around her monitor.

“It’s so much longer,”

someone said.

“Yes,” she replied.
“But look at the diff."
"Look at elf reading this with a magnifier."
"Think about the newcomers touching this file for the first time.”

She smiled.

“Readable code isn’t about writing less now.
It’s about respecting those who read it tomorrow.”

The team was silent for a moment.

"Thank you. This... this actually makes my work easier."

And that, she thought, was the greatest gift of all.

P.S.

This kind of document always sparks heated discussions so I've created a GitHub project with discussion enabled: https://github.com/happy-barney/the-gift-of-readability/discussions.

I've been many times rightfully accused of omitting information I consider too obvious. If you found some place where you think I did it again, please start related discussion as well.

This article is summary of my experiences and things I learned. See for example books:

Clean Code
The Art of Readable Code

brian d foy left a comment when I submitted this article:

    &quot;One of the great mistakes of Perl Best Practices is that it led people to believe
    that there were hard rules, even though that was not the authors intent. This sort
    of article makes a similar mistake. Readability isn&#39;t some sacred knowledge hidden
    across books stored away in dark library basements.&quot;

He is right. This article should not be treated as a set of strict hard rules. It should spark the creation of some kind of base class, some kind of readability framework, real projects can be based on.

I believe that every rule must be explained, complete with reasoning, pros, and cons. This explanation should also cover complementing rules to explain why they were rejected.

For example, imagine an early advocacy argument for camel case:

    &quot;To save space, as source code storage is limited to 1.44 MB.&quot;

(Do people even remember 1.44 MB nowadays?)

How SUSE is Using Perl

2025-12-20T00:00:00Z

Last year a new Perl Advent tradition was started, where a remote presentation is made as part of the calendar. That presentation was Half My Life With Perl by Randal Schwartz. This year we we had the pleasure of hearing from Michael Schröder, Tina Müller and Oliver Kurz talking about how Perl is in use at SUSE.

The primary coverage of the talk concerns SUSE's openQA and the Open Build Service. These both lean heavily on Perl and are tools that you may find useful in your own work.

Now, please enjoy "How SUSE is Using Perl":

Advent of the Underbar

2025-12-19T00:00:00Z

Advent of the Underbar

According to podcast index, there are (at the time of writing) 4,558,912 podcasts, 432,264 of which have been published in the last 60 days.

The Underbar is one of them.

That is a lot of podcasts, and the first question that comes to mind is "why create another one?" (quickly followed by "how long do you think it's going to last?").

A tangent: my pandemic projects

Before I can describe the podcast, I have to go on a tangent, which will set the stage for how I ended up creating yet another computing podcast.

During the 2020 pandemic (I sadly think we'll have to date them), and more specifically during the global lockdown, a lot of people were telling the world how they spent their newly discovered free time baking bread or exploring their artistic side.

Having worked mostly remotely for over a decade at the time (my team was in Amsterdam, Netherlands, and I worked from the local office in Lyon, France), I didn't feel much change (except that my office was now in my home).

I too wanted to have lockdown projects, so I came up with three. My hope was to complete at least one of them in a reasonable amount of time (before the end of 2021, I think).

🗹 Le bâton de joie

My first idea was to pick up and finally finish a 20 years old project: building an arcade joystick to play arcade games on an emulator (such as MAME).

That project was started with two friends in 2000. Back then, we had bought all buttons and sticks from an arcade repair shop, pulled the electronics out of a PS/2 IBM Model M keyboard, mapped the keys to the pins, and wired one joystick and two buttons. The whole lot went into a box after we plugged it into a computer and we managed to play a game of Frogger with it.

Another reason for putting on hold is that one of the friends' wife cheated with the other, forgetting the first rule of gaming: don't cheat with friends. Over the course of 20 years, another friend gifted me a chassis, that sat alongside the box for over a decade.

Picking up that project after 20 years, everything was easier. Now I could buy USB zero delay joystick adapters on the Internet, and throw away the keyboard electronics. I just had to drill 17 or so holes in the chassis, screw in all the buttons and joysticks, and wire the lot to the USB cards. After attaching a Raspberry Pi to the side (another thing that didn't exist in 2000), I could temporarily move the Nintendo Switch away, and show my kids what videogames looked like in the eighties.

This took a few months to complete in real time. We played our first games in May 2021.

🗷 Programming Sentimental Advice Column

My second project I dubbed the "Perl Love Letters". The idea was to set up a web site to collect and publish "love letters" (and possibly breakup letters too), written to Perl by its users or ex-users as if it were an old flame.

I've been part of the Perl community since 1999, and I've had numerous conversations with lots of people about Perl, what we love about it, its quirks and its future. I really believe there is a trove of interesting stories of people discovering Perl, some sticking with it, some moving on, etc. We collectively have a lot to say about this programming language, and how it changed our lives.

This idea was inspired in particular with a late night bar conversation with my then work and later Perl Steering Council team mate Graham Knop, who told me sincerely, almost within the same breath, that Perl was the worst programming language, and also his favorite one.

Alas, although I thought about it many times, I never managed to write my own love letter to Perl. This project remains a cute idea to this day.

(As the quote goes, "ideas are easy": if you're interested in making this happen, please do. I promise I'll write my love letter to Perl and send it to you once you have set up the web site.)

☐ The book that did not exist

As I considered the shelves in my office, filled with computer books, from those I have barely skimmed to those I read from cover to cover, I realized that there was one book that I wanted to read. The main problem was that no-one had written it.

I wanted to read a Larry Wall biography.

Instead of badly rephrasing it, I'll quote the email I sent Gloria Wall in 2023 (!), to present the project:

In late 2020, at the height of the pandemic, I looked at my computer books collection, and realized there was one book that was missing in there. One book that I would really really love to read. A book that would not be afraid of technical jargon, or showing some source code or raw emails: a book written for people like me. A book that details the enormous influence Larry Wall has had on Open Source and programming in general.

It turned out no one had written that book yet.

For the past two years, my fantasy project has been to collect material for whomever would write that book. I'm not an author, I'm not even a native English speaker, so I knew from the beginning the author couldn't be me. A year ago, I was chatting with my good friend Wendy van Dijk, and I exposed the project to her in more detail than I had ever written before:

I want to know about patch, about rn. About how pack and unpack came to be. Sure, some of the personal details too, but his philosophy of computing and collaboration is more interesting.

Also, biography is a specific kind of book. We'd need someone who knows how to write one, and an editor, etc.

There's also the story of the early days of Open Source. Wasn't he in the meeting where the name "open source" was coined?

He's been both influential and humble.

I also feel I can't be the one doing it. Maybe ask some questions, run some interviews, but one has to be a native speaker, and a writer, and I'm neither.

[...]

At the last Perl Toolchain Summit, which I organised in my home city of Lyon, France, I talked about this with Ingy döt Net and Leon Timmermans. They both thought this was a great idea, and someone should definitely do it.

[...]

I don't know if this project will actually lead anywhere. Best case, an actual book will exist in a few years. Worst case, some material will be available for someone better equipped than me to pick this project up.

Gloria's reply is a wonderful example of her wit and Larry's humility:

Personally I don't think Larry's life is all that compelling--he has spent most of it typing on a computer keyboard or in long bouts of just thinking (while staring at a computer screen). But yeah, he changed the world.

The story of Larry Wall is intertwined with the story of Perl and the early Internet (between the Unix wars and the Dot-com bubble burst).

The way I saw this biographical project involved a data collection step: find and save as much of what was already available (interviews, videos, etc). Another side of it was producing more data: get Larry's answers to the specific questions I had, and get the people around him to talk.

The project is currently in a limbo state: I have collected some material, but Larry is mostly retired, and doesn't seem very interested in talking about all this. I eventually lost steam, and moved to other things.

Why create another podcast?

Back to the podcast and why I created it.

I slowly made my way into recording a podcast by listening to a few of them.

In 2021, my colleague Bailey Stewart suggested to me the On the Metal podcast. After listening to all episodes (and waiting for the next one for a very long time, not realizing they had moved on to another format), I started listening to Digital Citizen, by our very own Ricardo Signes.

It was Ricardo who suggested to me in January 2024:

Advent of Computing is excellent, and I think you'd really like it.

He was right on both counts: Advent of Computing is excellent, and I really like it.

The history of computing and programming is one of my favorite topics (my shelves contain both books about the history of computing, and historical computing books).

The unwritten book project, combined with my recent interest in computing podcasts, planted the idea of making my own podcast in my head. Telling the story of Larry Wall's enormous influence on modern computing is a herculean task, probably beyond my reach, but that wouldn't prevent me from trying to record some fireside stories of the Perl community.

A little bit over a year ago, as I was trying to write my Advent Calendar entry for 2024, I started talking with Olaf Alders about the idea that had taken root in my head:

I'm listening to podcasts, and there's one I'm slowly getting into https://oxide.computer/podcasts/oxide-and-friends It feels like being in a bar conversation with other technical people. I don't always fully understand what they're talking about, but I like what I hear.

I'm been thinking about having something like this with people I know for some time, thinking about doing it at work (but being worried that the suits would not like the idea of a recording, and that maybe the participants wouldn't like it too much either). I already do "old men ranting calls" with colleagues, but we haven't recorded them so far. Would probably be too controversial anyway...

Now I'm wondering if an idea like that could work with Perl people. We're used to hanging out in bars, after all! What do you think?

To which Olaf replied:

I think it would be an interesting experiment. I have fond memories of Perlcast: <https://perlcast.net/>

I believe Olaf's superpower is to encourage people to actually do what they already wanted to do in the first place, and just jump in.

JFDI in action

This was also an experiment in getting things done in spite of my perfectionist mindset. Better make something now and improve it over time, than plan for the perfect outcome and never achieve anything. (As noted earlier, ideas are easy. The real effort is in delivering on those ideas.)

Over the years, I've tried to think less and do more, because I also know that (according to The Cult of Done Manifesto), "Done is the engine of more". And I want to have produced more than just ideas with my time in this world.

Anyway, at the end of December 2024, we picked the topic du jour (the new Perl logo), grabbed everyone who was involved, and eventually recorded our conversation. Thibault Duponchelle helped with editing this first episode (which was numbered 0, obviously), while I slapped the new Perl logo on the podcast logo (I've been having a lot of fun creating the logos for the individual episodes!) and created a static web site to host the feed. In our excitement, we went from recording to publication in little more than a week!

I managed to convince Olaf to be my co-host: I think we complement each other well, and that widens the scope of questions we ask to our guests.

Podcasting as data collection

My goal is not just to record those interesting conversations with the people who make things happen. Using modern technology, it's very easy to have good enough transcripts. Apple Podcasts generates one automatically after publication, and when using Zoom (thanks to The Perl and Raku Foundation for letting us use their license to record some of our episodes), we have a transcript along the raw recording.

My plan is not only to edit and add those as closed captions for the podcast, but also put them on the web site, for better searchability and indexing. Adding notes for the readers is also a goal. This would let us explain the jargon, and point to more sources for those who want to dig in.

I want to record witness accounts, from primary sources, of what the Perl and Open Source communities have achieved over the years.

How long will this last?

I didn't want to fall into the classic blunder of buying new gear for a new project, and then leaving it gathering dust on a shelf because the project went nowhere. So I promised myself I'd only get a proper microphone when I have published enough episodes with a regular schedule. My self-imposed target was the end of the year and the holiday season. By then, we'll have published 9 episodes, and I expect to find a nice microphone under the tree this year. (Here is your connection to Santa Claus for this Advent Calendar entry!)

Hopefully, as long as there are people interested in talking about past, present and future Perl, we'll be able to get them to talk to us. I've set my sights on a relaxed schedule (one episode a month), which doesn't put me under too much pressure. I'm also not doing this alone: Olaf Alders is co-hosting the podcast with me, Salve Nielsen is bringing his ideas and contact list to the talk, and Thibault Duponchelle is regularly reminding me of my responsibilities as a publisher. Dave Cross made one of the first pull requests, to add a prominent link to the podcast feed on every page of the web site. And of course, over 20 people have been talking with us on the podcast!

I've paced myself, because I'm in this for the long run. One episode a month seem about right as a schedule. I want to have more of those conversations, I want to hear the story of Perl and its communities, and more generally, of Open Source and Unix communities and projects.

We haven't run out of topics yet.

The first year

After the first episode, we just ran from there: at the end of February we had recorded another episode, on a more controversial topic (Perl 42).

It took more time than expected to get it published (May), but we respected the self-imposed schedule of one episode a month since (the August episode was delayed until September; since there was also a September episode, so I count this as within the margin of error).

Here's a summary of our published episodes:

Episode 0 - The New Perl Logo
Episode 1 and 2 - Perl leadership and Perl 42

During the Perl Toolchain Summit 2025 in Leipzig, Salve J. Nilsen lended his recording material, and we spent the entire Sunday recording conversations with teams assembled there. This led to four more episodes:

Episode 3 - MetaCPAN
Episode 5 - Test::Smoke
Episode 6 - CPAN Testers
Episode 7 - CPAN Security Group

During PTS, I also spent some time talking with Salve about the upcoming European CRA law, and we thought it would be useful to record a version of that conversation for a larger audience:

Episode 4 - The Cyber Resilience Act

Salve has a lot of contacts in the Open Source community, and he managed to get a slot on Olaf Kolkman's busy schedule. We recorded a three hour conversation with the pioneer of DNSSEC and prominent Internet Society member Olaf Kolkman, which will make up our next two episodes.

Help needed

The podcast format captures the conversations, and makes it easy to enjoy those conversations while doing something else (I do most of my own podcast listening while walking outside or cooking). But if this material is meant to be used as "primary source" for some future work about the history of Perl and its community, text is going to be the best format long term.

If there are topics you want to listen to, or corrections you want to make to the web site, you can write to underbar AT cpan.io or submit a pull request to the repository

Can't wait to hear from you!

Safer last-minute hotfixes before Christmas

2025-12-18T00:00:00Z

Christmas is just around the corner, but a critical misconfiguration in ChristmasPresentDistributor service has been unearthed! Angry parents start calling the Christmas Inc. Support Center arguing that their children haven't gotten their presents yet. Social media is in utter chaos and the stock price took a nosedive. What a disaster! An incident response team consisting of a single elf, Frosty, has been dispatched to deal with the situation ASAP while the programmer team develops, reviews and publishes the fix in the ServiceConfigurator service codebase. There could be many hours before it is complete and all the services are reloaded!

Frosty was trusted with temporary admin permissions to make sure he can set it straight. The fix turned out to actually be pretty straightforward - just modify a couple of config files, but... *gasp* directly on a production server! To make sure he doesn't make the situation worse, he should at the very least:

Back all the files up
Make changes in all the files, preferably simultaneously
Be able to restore the files from backups at any time, preferably simultaneously

As it turned out, there's a tool called App::Transpierce that was developed by a fellow Perl hacker who often had to deal with this kind of... incidents. It is written in perl 5.10 and abuses the ubiquity of perl interpreter on Linux machines. The script can export itself into a single file, and then get copied into any remote environment using scp or alike, to do the dirty (but much needed) work. Since perl is everywhere, it should work everywhere with only core modules installed!

How does it work? First, Frosty created a transpierce.conf config file for it, which could be as easy as a list of files he wanted to modify:

        /path/to/file1.conf
        /path/to/file2.yml

This file can be placed in regular user's home directory. With the transpierce script copied there too, he could prepare a target directory for his working environment:

mkdir PROD_HACK
cp transpierce.conf PROD_HACK
./transpierce --describe PROD_HACK

The --describe call looked at his configuration, checked the files he listed and dumped a list of actions. This was a dry run, so nothing actually got done yet!

        Files specified in the config file
        /path/to/file1.conf
          mode -&gt; 0644
          uid -&gt; 0
          gid -&gt; 0
        -------
        /path/to/file2.yml
          mode -&gt; 0644
          uid -&gt; 0
          gid -&gt; 0
        -------

        Actions:
        Create a directory
          mkdir -&gt; PROD_HACK/restore
        -------
        Create a directory
          mkdir -&gt; PROD_HACK/deploy
        -------
        Make copies of /path/to/file1.conf
          copy -&gt; PROD_HACK/restore/__path__to__file1.conf
          copy -&gt; PROD_HACK/deploy/__path__to__file1.conf
        -------
        Make copies of /path/to/file2.yml
          copy -&gt; PROD_HACK/restore/__path__to__file2.yml
          copy -&gt; PROD_HACK/deploy/__path__to__file2.yml
        -------
        Create script in PROD_HACK/restore.sh
          restore -&gt; /path/to/file1.conf
          restore -&gt; /path/to/file2.yml
        -------
        Create script in PROD_HACK/deploy.sh
          deploy -&gt; /path/to/file1.conf
          deploy -&gt; /path/to/file2.yml
        -------
        Create script in PROD_HACK/diff.sh
          diff -&gt; /path/to/file1.conf
          diff -&gt; /path/to/file2.yml
        -------

Frosty had a long look at that output. The script inspected his actual production files to determine their original mode, uid and gid. It listed a bunch of actions to perform: create restore and deploy directories, copy production files into them and create three scripts: restore.sh, deploy.sh and diff.sh.

Frosty was satisfied with the description, so he ran the script again without the --describe flag, which performed all the listed actions. But wait, shell scripts? I thought this story was about Perl?!

You see, in a production environment, it is much better to have a shell script that contains no magic and can be audited before actually running it as root. For example, this is what the deploy.sh script looked like:

cp &quot;deploy/__path__to__file1.conf&quot; &quot;/path/to/file1.conf&quot;
chmod 0644 &quot;/path/to/file1.conf&quot;
chown 0 &quot;/path/to/file1.conf&quot;
chgrp 0 &quot;/path/to/file1.conf&quot;

cp &quot;deploy/__path__to__file2.yml&quot; &quot;/path/to/file2.yml&quot;
chmod 0644 &quot;/path/to/file2.yml&quot;
chown 0 &quot;/path/to/file2.yml&quot;
chgrp 0 &quot;/path/to/file2.yml&quot;

This is easy to understand. This does not put the fate of a production server into the hands of a 450-line third-party script. This is easy to extend if some additional tasks need doing (like reloading the configuration).

restore.sh script looked exactly the same, but it copied from restore directory instead. The third script, diff.sh, had a different purpose: it compares the files from restore directory and their actual locations using diff command. If it returns no output, it means the files are unchanged.

With everything set up, the next step was to go into the deploy directory and modify the files. Their names looked a bit goofy now, with all directory separators replaced with double underscores, but at least it made the structure flat. Frosty was already sure about the required changes, so this step was actually really easy. He made sure not to touch the restore directory, because that could mess up his backup files.

It was time for the grand finale. Up until this point, the risk of breaking the production installation was exactly zero. Since he was done, Frosty had to run the dreaded sudo ./deploy.sh command and hope for the best. His hands were shaking as he typed his password. His throat felt dry, even though he'd been sipping on a cup of mulled wine all this time. It was however a great consolation to know that he could always run sudo ./restore.sh and undo it all within seconds. So "YOLO", as young people say!

The Elves Learn to be Lazy

2025-12-17T00:00:00Z

"Two Bulls Clash Antlers" by USFWS Mountain Prairie is licenced under CC BY 2.0 .

The Naughty or Nice Subsystem

Putting together Santa's naughty or nice list is one of the elves' most important tasks. To assist them a Naughty or Nice Subsystem (NORN) has been developed over many years.

Initially the system was very simple. The norn table had a row for every child and Santa would go through and set the is_nice column to either true or false. The elves would then run the list generation routine, Santa would check it twice, and Christmas would proceed.

After a particularly difficult year Holly the elf, wearing her PM hat, decided that this decision couldn't be left to Santa's whims and that each child's actions over the year should be categorised and stored as either good or bad in the norn table. The child was considered nice if they had been good more often than bad.

Some time later Holly thought that some actions were either very_good or very_bad and should count double.

As each set of modifications took place the is_nice method became more complicated, but the tests didn't. The elves were loath to work on such important code with a limited safety net.

A New Algorithm

Last year young Sophie Farrington from Finsbury Park, somewhat upset at finding only coal in her stocking, issued an FOI request. She subsequently claimed that many of her actions which had been categorised as bad were, at worst, cheeky and were perhaps even charming. Mrs Claus agreed, and tasked the elves in the R&D department to come up with a more fair algorithm.

Eventually the algorithm was finalised and Holly created a new story for the backlog. It replaced the old very_good and very_bad categories with more nuanced categories of noble, virtuous, errant and iniquitous to go with the original good and bad classifications. And there was a suitably complicated algorithm to accompany them to determine the ultimate judgement.

But none of the elves wanted to pick it up. The code was just too brittle and, since the external consulting company had recommended Santa only checking the list once as a cost-saving measure, and later that the checking should be completely skipped, no one wanted to be known as the elf who messed up the Naughty or Nice list and ruined Christmas.

But doing nothing wasn't an option either.

The Reindeer's Cousins

With Christmas on the line, Santa called everyone in to find a solution. It was Blitzen who had the bright idea of getting the reindeer's cousins, the moose, involved.

Donner explained the concept. By converting the plain OO class to use Moose it becomes easy to break up large methods. The key is to use lazy attributes to calculate variables within the algorithm. This simplifies the code around the algorithm and, crucially, makes it easy to test parts of the algorithm rather than just the end result.

Prancer further explained that by using lazy attributes the return value is only calculated once, and then it is stored and immediately returned on subsequent calls. Even better, each attribute is calculated only when first accessed. If the code never calls $norn->noble_count, that expensive calculation never runs at all. This helps keep the code efficient too, which is important with a list of over one billion entries.

Laziness

The elves took on the project. And it wasn't too difficult. The class API didn't really change, it just expanded. So existing code using Norn->new(...)->is_nice worked identically with NornV2, making the migration straightforward and low-risk.

The original code contained one large method with lots of expensive calculations. It looked something like:

package Norn;

use 5.42.0;

sub new {
&nbsp;&nbsp;my ($class, %args) = @_;
&nbsp;&nbsp;die &quot;child_id is required&quot;    unless exists $args{child_id};
&nbsp;&nbsp;die &quot;child_id must be an Int&quot; unless $args{child_id} =~ /^\d+$/;
&nbsp;&nbsp;bless \%args, $class
}

sub is_nice {
&nbsp;&nbsp;my ($self) = @_;
&nbsp;&nbsp;my $sum = 0;

  # expensive calculation to get event data
  my $event_data = { ... };

  # expensive calculation of good count from $event_data
  my $good = ...;
&nbsp;&nbsp;$sum += $good;

  # expensive calculation of bad count from $event_data
  my $bad = ...;
&nbsp;&nbsp;$sum -= $bad;

  # expensive calculation of very good count from $event_data
  my $very_good = ...;
&nbsp;&nbsp;$sum += $very_good * 2;

  # expensive calculation of very bad count from $event_data
  my $very_bad = ...;
&nbsp;&nbsp;$sum -= $very_bad * 2;

&nbsp;&nbsp;$sum &gt;= 0
}

1

The test code was fairly simple:

#!/usr/bin/perl

use 5.42.0;
use Test2::V0;
use Norn;

subtest setup =&gt; sub {
  # set up test fixtures
};

subtest is_nice =&gt; sub {
&nbsp;&nbsp;my $norn = Norn-&gt;new(child_id =&gt; 1);
&nbsp;&nbsp;is $norn-&gt;child_id, 1, &quot;child_id is 1&quot;;
&nbsp;&nbsp;ok $norn-&gt;is_nice, &quot;is nice&quot;;
};

subtest teardown =&gt; sub {
  # tear down test fixtures
};

done_testing;

The updated code was obviously more involved but was broken into individual methods, each of which was simple enough to understand and test individually.

package NornV2;

use 5.42.0;
use Moose;

has child_id =&gt; is =&gt; &quot;ro&quot;, isa =&gt; &quot;Int&quot;, required =&gt; 1;

has event_data       =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_event_data&quot;;
has noble_count      =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_noble_count&quot;;
has good_count       =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_good_count&quot;;
has virtuous_count   =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_virtuous_count&quot;;
has errant_count     =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_errant_count&quot;;
has bad_count        =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_bad_count&quot;;
has iniquitous_count =&gt; is =&gt; &quot;ro&quot;, lazy =&gt; 1, builder =&gt; &quot;_build_iniquitous_count&quot;;

sub _build_event_data ($self) {
  # expensive calculation to get event data
}

sub _build_noble_count ($self) {
&nbsp;&nbsp;my $event_data = $self-&gt;event_data;
  # expensive calculation of noble count from $event_data
}

sub _build_good_count ($self) {
&nbsp;&nbsp;my $event_data = $self-&gt;event_data;
  # expensive calculation of good count from $event_data
}

sub _build_virtuous_count ($self) {
&nbsp;&nbsp;my $event_data = $self-&gt;event_data;
  # expensive calculation of virtuous count from $event_data
}

sub _build_errant_count ($self) {
&nbsp;&nbsp;my $event_data = $self-&gt;event_data;
  # expensive calculation of errant count from $event_data
}

sub _build_bad_count ($self) {
&nbsp;&nbsp;my $event_data = $self-&gt;event_data;
  # expensive calculation of bad count from $event_data
}

sub _build_iniquitous_count ($self) {
&nbsp;&nbsp;my $event_data = $self-&gt;event_data;
  # expensive calculation of iniquitous count from $event_data
}

sub is_nice ($self) {
&nbsp;&nbsp;my $sum = 0;

  # assign $sum from a complicated algorithm involving
&nbsp;&nbsp;# $self-&gt;noble_count, $self-&gt;good_count, $self-&gt;virtuous_count,
&nbsp;&nbsp;# $self-&gt;errant_count, $self-&gt;bad_count, $self-&gt;iniquitous_count

&nbsp;&nbsp;$sum &gt;= 0
}

no Moose;

__PACKAGE__-&gt;meta-&gt;make_immutable;

1

And the test code was still fairly simple but, importantly, was able to test individual data values stored in the lazy attributes.

#!/usr/bin/perl

use 5.42.0;
use Test2::V0;
use NornV2;

subtest setup =&gt; sub {
  # set up test fixtures
};

subtest is_nice =&gt; sub {
&nbsp;&nbsp;my $norn = NornV2-&gt;new(child_id =&gt; 1);
&nbsp;&nbsp;is $norn-&gt;child_id, 1, &quot;child_id is 1&quot;;

&nbsp;&nbsp;my $gold_event_data = {...};  # expected event data for child_id 1
&nbsp;&nbsp;is $norn-&gt;event_data, $gold_event_data, &quot;event data&quot;;

&nbsp;&nbsp;is $norn-&gt;noble_count,      15,  &quot;noble count&quot;;
&nbsp;&nbsp;is $norn-&gt;good_count,       104, &quot;good count&quot;;
&nbsp;&nbsp;is $norn-&gt;virtuous_count,   226, &quot;virtuous count&quot;;
&nbsp;&nbsp;is $norn-&gt;errant_count,     51,  &quot;errant count&quot;;
&nbsp;&nbsp;is $norn-&gt;bad_count,        20,  &quot;bad count&quot;;
&nbsp;&nbsp;is $norn-&gt;iniquitous_count, 3,   &quot;iniquitous count&quot;;

&nbsp;&nbsp;ok $norn-&gt;is_nice, &quot;is nice&quot;;
};

subtest teardown =&gt; sub {
  # tear down test fixtures
};

done_testing;

Conclusion

The elves were very happy with their new code. With it broken down into manageable and individually testable methods they didn't fear making changes to the Naughty or Nice system.

Dasher and Comet noted that not only was the code improved, but the elves were also able to crank it out faster and with fewer bugs.

Mrs Claus was glad that the coal deliveries were reduced.

And young Sophie Farrington turned out to be nice after all, so Santa rewarded her with a stocking full of chocolate coins and tangerines.

Auto-instrument your code with OpenTelemetry

2025-12-16T00:00:00Z

"Hot chocolate" by David Thompson, CC BY-NC-SA 2.0

A whole year had gone by since the elves at Santa's workshop had started using OpenTelemetry to collect and export telemetry from their multiple services, and things had been going well. But in a meeting room deep under the icy cover of the North Pole, trouble was brewing.

"Well what do you suggest, then?", asked Duende Juniorsson, the junior elf in the team.

"I don't have a solution, I just know where the problem is", answered Gnomo Knullpointer perhaps a little more exasperated than he should be. "I know that OpenTelemetry has been a game changer, and that we want to have more of it. But instrumenting code has a cost, and I'm just wondering how much longer we can keep paying it".

The elves had been relying on instrumentation libraries to generate telemetry without having to make changes to their own codebase. This "zero-code instrumentation" had been the key selling point when they started using OpenTelemetry. But it meant that they were limited either by the libraries that were available, or by the resources they could dedicate to writing their own.

"If we want to instrument something, and there is no instrumentation library for it, and we don't have the resources to write our own, then the only other option is to instrument it manually", said Duende.

"Sure, but that is only marginally less work. And anything you touch will have to be tested", said Tess 't Moor, the QA elf. "So we might be saving time for you developer elves, but only because I'll be the one testing things".

There was a pause in the conversation, as each elf stopped to gather their thoughts. Santa, who was sitting at one end of the table looking nervous, did not like this. He did not like his elves getting upset and forgetting what Christmas was all about, but more than anything, he did not like being in a meeting where nobody was talking. It made him feel like maybe they were waiting for him to say something, and under pressure the only thing he could ever think of saying was "Ho ho ho". He was pretty sure this was not the right time to say it.

Ada Slashdóttir, the team's senior elf, cleared her throat and absentmindedly started tapping her cup of hot chocolate with a candy cane. "What if we get Perl to write the instrumentation code for us?".

Auto-auto-instrumentation

"Most OpenTelemetry instrumentation libraries look very similar", she continued. "They declare methods in a package that need to be instrumented, and then monkey-patch them to generate the necessary telemetry."

"But not all telemetry is the same", replied Gnomo. "OpenTelemetry specifies which attributes need to be set in what kinds of spans: a span representing an HTTP transaction needs to specify the URL it is for, one for a database operation needs to specify what database it is for, etc. We cannot have a one-size-fits-all approach".

"We can probably get 90% of the way with a generic approach", continued Ada. "And worry about the last 10% when we get there".

"Isn't this making the problem worse?", asked Duende. "A minute ago we didn't have the resources to write an instrumentation library, and now we are talking about writing a library to write instrumentation libraries?".

"Ah, but we don't need to write it ourselves", said Ada. "We can use the new OpenTelemetry::Instrumentation::namespace".

The elves loaded up the documentation and dove in.

Ada brought up her terminal. "Say you have some code that calls some package to do something":

use v5.36;
use UUID4::Tiny 'create_uuid_string';

say create_uuid_string;

"That will print out a UUID", said Duende.

"Exactly", replied Ada. "And if we add OpenTelemetry?".

use v5.36;

# Dump spans to STDERR in prettified JSON format
BEGIN {
&nbsp;&nbsp;&nbsp;&nbsp;$ENV{OTEL_TRACES_EXPORTER}              = 'console';
&nbsp;&nbsp;&nbsp;&nbsp;$ENV{OTEL_PERL_EXPORTER_CONSOLE_FORMAT} = 'json,pretty=1';
}

use OpenTelemetry;
use OpenTelemetry::SDK;

use UUID4::Tiny 'create_uuid_string';

say create_uuid_string;

"Nothing will change", said Gnomo. "We loaded the API and initialised the SDK, but since we are not generating any telemetry, nothing is different".

"Now let's try loading the namespace instrumentation", said Ada.

use v5.36;

# Dump spans to STDERR in prettified JSON format
BEGIN {
&nbsp;&nbsp;&nbsp;&nbsp;$ENV{OTEL_TRACES_EXPORTER}              = 'console';
&nbsp;&nbsp;&nbsp;&nbsp;$ENV{OTEL_PERL_EXPORTER_CONSOLE_FORMAT} = 'json,pretty=1';
}

use OpenTelemetry;
use OpenTelemetry::SDK;
use OpenTelemetry::Instrumentation namespace =&gt; [
&nbsp;&nbsp;&nbsp;&nbsp;'UUID4::Tiny' =&gt; 1,
];

use UUID4::Tiny 'create_uuid_string';

say create_uuid_string;

The output of the script had changed! The UUID was still being printed at the bottom of the screen, but above it were several lines with JSON encoded OpenTelemetry spans. Slightly edited for brevity, the output looked a little bit like this:

    {
       &quot;end_timestamp&quot; : 1765582438.54618,
       &quot;instrumentation_scope&quot; : {
          &quot;name&quot; : &quot;UUID4::Tiny&quot;,
          &quot;version&quot; : &quot;0.003&quot;
       },
       &quot;name&quot; : &quot;UUID4::Tiny::create_uuid&quot;,
       &quot;parent_span_id&quot; : &quot;dbed67eb5146795b&quot;,
       &quot;span_id&quot; : &quot;c2f03b363333f610&quot;,
       &quot;start_timestamp&quot; : 1765582438.54615,
       &quot;trace_id&quot; : &quot;386e98e4fa576fc5280e8da1f59d3031&quot;,
       ...
    }
    {
       &quot;end_timestamp&quot; : 1765582438.54669,
       &quot;instrumentation_scope&quot; : {
          &quot;name&quot; : &quot;UUID4::Tiny&quot;,
          &quot;version&quot; : &quot;0.003&quot;
       },
       &quot;name&quot; : &quot;UUID4::Tiny::is_uuid_string&quot;,
       &quot;parent_span_id&quot; : &quot;e266cf2b01725042&quot;,
       &quot;span_id&quot; : &quot;6165bab8a0b6f448&quot;,
       &quot;start_timestamp&quot; : 1765582438.54666,
       &quot;trace_id&quot; : &quot;386e98e4fa576fc5280e8da1f59d3031&quot;,
       ...
    }
    {
       &quot;end_timestamp&quot; : 1765582438.54678,
       &quot;instrumentation_scope&quot; : {
          &quot;name&quot; : &quot;UUID4::Tiny&quot;,
          &quot;version&quot; : &quot;0.003&quot;
       },
       &quot;name&quot; : &quot;UUID4::Tiny::uuid_to_string&quot;,
       &quot;parent_span_id&quot; : &quot;dbed67eb5146795b&quot;,
       &quot;span_id&quot; : &quot;e266cf2b01725042&quot;,
       &quot;start_timestamp&quot; : 1765582438.54654,
       &quot;trace_id&quot; : &quot;386e98e4fa576fc5280e8da1f59d3031&quot;,
       ...
    }
    {
       &quot;end_timestamp&quot; : 1765582438.54686,
       &quot;instrumentation_scope&quot; : {
          &quot;name&quot; : &quot;UUID4::Tiny&quot;,
          &quot;version&quot; : &quot;0.003&quot;
       },
       &quot;name&quot; : &quot;UUID4::Tiny::create_uuid_string&quot;,
       &quot;parent_span_id&quot; : &quot;0000000000000000&quot;,
       &quot;span_id&quot; : &quot;dbed67eb5146795b&quot;,
       &quot;start_timestamp&quot; : 1765582438.54598,
       &quot;trace_id&quot; : &quot;386e98e4fa576fc5280e8da1f59d3031&quot;,
       ...
    }
    4c9debb9-6370-4d7c-94f2-a5f1799475ce

"Hey, this is much more like it", said Duende, who had got pretty familiar with OpenTelemetry spans. "You can see that they all share a trace_id, and can track what span created which other span by looking at the span_id and the parent_span_id".

"Yeah, and look at the names", said Gnomo. "They are the fully-qualified subroutine name of the code that executed. So you can tell that when we called create_uuid_string it called uuid_to_string, which itself called is_uuid_string".

"And all of that without using a pre-made instrumentation library for UUID4::Tiny, or manually instrumenting anything", said Ada.

"How does this even work?", asked Duende after looking at the code a little more carefully. "We load the instrumentation before loading the code to be instrumented. How does it know what to instrument before we import it?".

"Good question!", said Ada excitedly. "Let's dive deeper."

Looking under the hood

"When you load the namespace instrumentation with a rule like the one we gave it, it will look among the modules that have been loaded to see if any match the one we want to instrument", said Ada. "In this case, since we haven't loaded UUID4::Tiny, it won't find it".

"So how does it know when to instrument it?", asked Gnomo.

"It uses a require hook that will execute when a module of interest is loaded. At that point, it installs the necessary instrumentation", explained Ada.

"Is that safe? Won't that make everything slower?", asked Duende.

"To some extent, yes", replied Ada. "Which is why this is not really made as a substitute for writing instrumentation libraries. It is meant as a way to facilitate the instrumentation of existing codebases, or as a stopgap measure to use when exploring what to instrument. But it's hard to predict the impact in the abstract: we'll always just have to benchmark things to see what the real impact is, and decide whether it makes sense to pay the price".

"That seems reasonable, but why does it need the hook at all?", asked Gnomo. "Wouldn't it be simpler to just make sure to load it after the import?".

"Ah, but there we hit another interesting caveat with this instrumentation", replied Ada. "Let's try it: what happens if we do that?". Ada modified the code to look like this and re-ran it.

use v5.36;

# Dump spans to STDERR in prettified JSON format
BEGIN {
&nbsp;&nbsp;&nbsp;&nbsp;$ENV{OTEL_TRACES_EXPORTER}              = 'console';
&nbsp;&nbsp;&nbsp;&nbsp;$ENV{OTEL_PERL_EXPORTER_CONSOLE_FORMAT} = 'json,pretty=1';
}

# Import the function first, then instrument
# This probably won't do what you want!
use UUID4::Tiny 'create_uuid_string';

use OpenTelemetry;
use OpenTelemetry::SDK;
use OpenTelemetry::Instrumentation namespace =&gt; [
&nbsp;&nbsp;&nbsp;&nbsp;'UUID4::Tiny' =&gt; 1,
];

say create_uuid_string;

"It still works", said Gnomo. "I can see the OpenTelemetry traces".

"But there's one span missing!", said Duende. "We lost the one for create_uuid_string".

"Precisely", said Ada. "A case like this, where we load a package and import a function from that namespace into ours, is very common. But if we load the instrumentation after we've imported it, when we execute the imported symbol from our own namespace we'll be running the uninstrumented code. To solve this we have to instrument the code before importing it, but then we have to use the require hook".

"This suddenly feels very Perlish", said Duende. "In that it is very powerful but also a little risky".

"It's all about taking managed risks", replied Ada. "This instrumentation works best when used in a targeted way, aimed at having the smallest impact possible while still being useful. That's why it tries to give you plenty of options to control what gets instrumented and when: you can match packages with literal strings or with regular expressions, and while we haven't been doing it here, you can also do the same for individual functions within any package of interest".

"Is that why the options are in an array reference?", asked Duende.

"Yes", answered Ada. "The instrumentation will process the rules in order. You can pass them in an array reference to control that order, or in a hash reference if you don't care about the order. But the array reference is more predictable".

Here a use, there a use, everywhere a yule use

"I can see how this would be useful", chimed in Tess. "But I could see this list of 'rules' getting unwieldy, if we need to have them all in the same place and they include package and subroutine matchers, etc".

"Yes, that can become a problem", agreed Ada. "So you don't actually have to have everything in the same place. You can load the instrumentation multiple times with different rules, and each invocation will be independent. This is particularly true of options, which can be passed together with the rules to modify how that particular set of rules are interpreted, or to load the rules from an external source."

"That's useful", said Gnomo. "But even then, if the code we are instrumenting is our own code, it might be awkward to have the instrumentation live far away from the code itself. In those cases, manual instrumentation might still be better".

"Yeah, I agree. A small scope is always better", replied Ada. "Luckily, there's a related instrumentation that you can use in those cases: OpenTelemetry::Instrumentation::caller. Let me show you how using that one looks like".

The instrumentation is coming from inside the package

"Say we have some utility package where we have some functions", said Ada.

package Santa::Workshop;

use v5.36;

sub allocate_gifts { ... }

sub is_naughty { ... }

# Sensitive data. Do not reveal!
sub dump_naughty_list { ... }

"If we want to auto-instrument this code", said Ada, "but we don't want (or can't) touch it, we can load the caller instrumentation. We just need to make sure we load it after the functions have been defined".

"Does it also take the same options and rules as the namespace instrumentation?", asked Duende.

"Yes", said Ada, "but since we are already 'inside' a package, so to speak, we skip the package-level matchers and go straight to the subroutine-level ones."

package Santa::Workshop;

use v5.36;

sub allocate_gifts { ... }

sub is_naughty { ... }

# Sensitive data. Do not reveal!
sub dump_naughty_list { ... }

use OpenTelemetry::Instrumentation caller =&gt; [
&nbsp;&nbsp;&nbsp;&nbsp;dump_naughty_list =&gt; 0,    # Ignore sensitive function
&nbsp;&nbsp;&nbsp;&nbsp;qr/.*/            =&gt; 1,    # Instrument the rest
];

Wrapping up

The elves were happy to have at least a path forward. They understood that these instrumentations were experimental, and that the best way to help was to use them and see where they felt awkward. And that's exactly what they aimed to do.

It was another successful day at Santa's workshop, making hard things possible, and Santa was happy to see that his elves had once again managed to figure things out by themselves. He was proud of his elves. Proud to see them grow and learn and try new things. And proud as well to see that, even when deep in the weeds of some technical problem, they knew that what mattered was what they were working towards. The rest was just the tools for the job.

Oh-oh. Santa had been lovingly staring at the elves for too long, and now they were staring back, as if waiting for him to say something. But this time, he knew exactly what to say.

"Ho ho ho!", laughed Santa, and everybody smiled.

Using Mojolicious::Plugin::Mount to help test your applications

2025-12-15T00:00:00Z

Introduction

When testing Perl applications we have many well known options and techniques but in this post we won't cover any of those fancy tools. Instead we will present a simple trick that takes advantage of the Mojolicious::Plugin::Mount.

Test Scenario

When testing modules or applications that make requests to third party services, one technique is to mock the user agent to answer mocked data for each request.

But when the module or application makes multiple requests to different external services that could be challenging.

The idea here is to mock the external services instead.

How `Mojolicious::Plugin::Mount` can help

This plugin basically allows us to glue together small Mojo applications into a single one that could be started by Test::Mojo.

Consider the two following small apps:

#!/usr/bin/env perl
use v5.42;
use Mojolicious::Lite -signatures;

get '/baz' =&gt; sub ($c) { $c-&gt;render( text =&gt; 'baz' ) };
get '/etc' =&gt; sub ($c) { $c-&gt;render( text =&gt; 'etc' ) };

app-&gt;start;

#!vim perl
#!/usr/bin/env perl
use v5.42;
use Mojolicious::Lite -signatures;

get '/lala' =&gt; sub ($c) { $c-&gt;render( text =&gt; 'lala' ) };
get '/lele' =&gt; sub ($c) { $c-&gt;render( text =&gt; 'lele' ) };

app-&gt;start;

You can check their routes by saving each one to separate files, making them executable, and running these commands:

user@host$ ./foo.pl routes
/baz  GET  baz
/etc  GET  etc

user@host$ ./bar.pl routes
/lala  GET  lala
/lele  GET  lele

By using Mojolicious::Plugin::Mount you can glue them together in this file named mock.pl:

#!/usr/bin/env perl
use v5.42;
use Mojolicious::Lite;

plugin Mount =&gt; { '/foo' =&gt; './foo.pl' };
plugin Mount =&gt; { '/bar' =&gt; './bar.pl' };

app-&gt;start;

And check the routes:

user@host$ ./mock.pl routes
/foo  *  foo
/bar  *  bar

That indicates that all requests starting with /foo will be delivered to the app foo and all requests starting with /bar will be delivered to the app bar.

You could prefix both with / meaning that the original routes will remain root-based.

Let's start the new app:

user@host$ ./mock.pl daemon
[2025-12-07 15:57:34.24246] [1437] [trace] Your secret passphrase needs to be changed (see FAQ for more)
[2025-12-07 15:57:34.24515] [1437] [info] Listening at &quot;http://*:3000&quot;
Web application available at http://127.0.0.1:3000

And make some requests:

user@host$ curl http://localhost:3000/foo/baz
baz

user@host$ curl http://localhost:3000/bar/lala
lala

Note the app logs:

  [2025-12-07 15:59:25.05863] [1437] [trace] [PJ0Qy_rY7rEA] GET &quot;/foo/baz&quot;
  [2025-12-07 15:59:25.05920] [1437] [trace] [PJ0Qy_rY7rEA] Routing to application &quot;Mojolicious::Lite&quot;
  [2025-12-07 15:59:25.06005] [1437] [trace] [PJ0Qy_rY7rEA] GET &quot;/foo/baz&quot;
  [2025-12-07 15:59:25.06020] [1437] [trace] [PJ0Qy_rY7rEA] Routing to a callback
  [2025-12-07 15:59:25.06046] [1437] [trace] [PJ0Qy_rY7rEA] 200 OK (0.000383s, 2610.966/s)

  [2025-12-07 15:59:38.70389] [1437] [trace] [1gOGBF3hsoml] GET &quot;/bar/lala&quot;
  [2025-12-07 15:59:38.70418] [1437] [trace] [1gOGBF3hsoml] Routing to application &quot;Mojolicious::Lite&quot;
  [2025-12-07 15:59:38.70511] [1437] [trace] [1gOGBF3hsoml] GET &quot;/bar/lala&quot;
  [2025-12-07 15:59:38.70529] [1437] [trace] [1gOGBF3hsoml] Routing to a callback
  [2025-12-07 15:59:38.70548] [1437] [trace] [1gOGBF3hsoml] 200 OK (0.000363s, 2754.821/s)

That means the request /foo/baz was delivered to the application foo.pl and the request /bar/lala was delivered to the application bar.pl.

You can use that to set up multiple test scenarios by "mounting" different mock apps, like "successful foo with failed bar" or "failed foo with successful bar".

Testing with mocked applications

There are some gotchas when testing with mocked mojo apps. Since Mojo::IOLoop is a singleton, both main app and mocked apps will share the same event loop. That means all blocking calls will make tests hang forever.

So in order to be able to test with mocked apps, your application should:

be able to overwrite the external URLs to point to mocked apps.
have all external calls async.

Here is an example which uses the foo.pl and bar.pl mock apps described above:

Consider the main application below which we will save as app.pl:

#!/usr/bin/env perl
use v5.42;
use Mojolicious::Lite -signatures;

get '/baz-lala' =&gt; sub ($c) {
&nbsp;&nbsp;&nbsp;&nbsp;$c-&gt;render_later;

&nbsp;&nbsp;&nbsp;&nbsp;# Getting external urls from 'config'
&nbsp;&nbsp;&nbsp;&nbsp;my $foo_url = Mojo::URL-&gt;new( $ENV{FOO_SERVER} ) . '/baz';
&nbsp;&nbsp;&nbsp;&nbsp;my $bar_url = Mojo::URL-&gt;new( $ENV{BAR_SERVER} ) . '/lala';

&nbsp;&nbsp;&nbsp;&nbsp;# Making async requests
&nbsp;&nbsp;&nbsp;&nbsp;my $foo_p = $c-&gt;ua-&gt;get_p($foo_url);
&nbsp;&nbsp;&nbsp;&nbsp;my $bar_p = $c-&gt;ua-&gt;get_p($bar_url);
&nbsp;&nbsp;&nbsp;&nbsp;Mojo::Promise-&gt;all( $foo_p, $bar_p )-&gt;then(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sub( $foo, $bar ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $res = $foo-&gt;[0]-&gt;res-&gt;text . '-' . $bar-&gt;[0]-&gt;res-&gt;text;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$c-&gt;render( text =&gt; $res );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;&nbsp;return;
};

app-&gt;start;

Here we get the external urls from %ENV and then we make async requests using promises versions of Mojo::UserAgent calls.

Now let's see the test:

#!/usr/bin/env perl

use v5.42;

package MyMock;
use Mojolicious::Lite;

plugin Mount =&gt; { '/foo' =&gt; './foo.pl' };
plugin Mount =&gt; { '/bar' =&gt; './bar.pl' };

package MyApp;
use Mojolicious::Lite;

plugin Mount =&gt; { '/' =&gt; './app.pl' };

package main;

use Test::More;
use Test::Mojo;

my $mock = Test::Mojo-&gt;new('MyMock');

# Checking mocks just in case
$mock-&gt;get_ok('/foo/baz')-&gt;status_is(200)-&gt;content_is('baz');
$mock-&gt;get_ok('/bar/lala')-&gt;status_is(200)-&gt;content_is('lala');

# Setting test
$ENV{FOO_SERVER} = $mock-&gt;ua-&gt;server-&gt;url-&gt;path('foo');
$ENV{BAR_SERVER} = $mock-&gt;ua-&gt;server-&gt;url-&gt;path('bar');
my $t = Test::Mojo-&gt;new('MyApp');

# Testing
$t-&gt;get_ok('/baz-lala')-&gt;status_is(200)-&gt;content_is('baz-lala');

done_testing;

Here you can see three packages: MyMock, MyApp and main. They are put together for simplicity but you can have them in separate files.

MyMock is a package to glue together all mocks.

MyApp is a package just to load the main app. If you have a full Mojo app instead you can just load it.

main is the package where we will run the tests. It is not needed if the packages are in different files.

After creating the Test::Mojo we get the urls of mocked apps and set the environment so the main app can get them.

Finally we make tests using Test::Mojo api.

Conclusion

Mojolicious::Plugin::Mount allow us to glue together small mojo apps that could be used to mock different scenarios of external services.

You can mount different mocks depending on the need of each test.

But in order to take advantage of them the application should keep external urls configurable and make external calls async.

The Twelve Slices Of Christmas: How Vasco Chained the Chaos

2025-12-14T00:00:00Z

The Missing Piece

After Vasco's team shipped NaughtyNice 3.0 on Christmas Eve, everyone wanted to know the secret. Carmen's No Estimates approach got all the attention—measure throughput, use real data, ship daily.

But here's what nobody saw: on Day 1, Vasco nearly quit.

Let me show you what happened behind the scenes.

The Crisis

The team met that first afternoon to define the MVP and break the work into slices. Thirty slices, each small enough to complete in a day or two. They put them all on the whiteboard.

Vasco stared at the board and did the math.

30 slices × 1 day each = 30 days of work.

They had 24 days until Christmas Eve.

He found Carmen, the Principal Elf for Special Projects, in her office. "No Estimates doesn't work."

Carmen looked up from her coffee. "Interesting. We haven't even started yet. Why not?"

"The math. We broke everything into thirty slices. Even if we complete one per day, that's thirty days of work." Vasco gestured in frustration. "We only have twenty-four days. We're going to miss."

"Show me."

They walked back to the war room. Carmen studied the thirty slices scattered across the whiteboard like confetti.

"Tell me something," Carmen said. "Can you score behaviors before you ingest them?"

"No, obviously not."

"Can you generate lists before you have scores?"

"No."

"Could Wheeler work on database optimization while Joel builds the CSV loader?"

Vasco paused. "Yes, actually. Those are independent."

"Can Quinn and Alice write acceptance tests while Joel codes?"

"Yes, with TDD they should actually start immediately. And we have the current system to test against."

Carmen grabbed a marker. "Then not all thirty slices are on the critical chain. Some can happen in parallel. Some have slack. You're not looking at thirty days of serial work—you're looking at a network."

She started drawing lines between slices. "Which ones have to happen in sequence? Which ones can happen alongside?"

Finding the Critical Chain

After thirty minutes of mapping dependencies, a pattern emerged. Most slices could happen in parallel or had flexibility in timing. But one path had to happen in strict sequence:

Ingestion → Validation → Scoring → Generate lists → Integration testing

Everything else could happen alongside or between these critical slices.

"That's your critical chain," Carmen said. "Count those slices."

Vasco counted. "Twelve slices. Twelve days."

"And you'll probably speed up a little," said Carmen.

Vasco sounded relieved. "Even at current pace, the critical chain fits easily in twenty-four days."

"Exactly. The other eighteen slices? They have slack. They can happen in parallel or whenever there's time. Here's the trick: the critical chain is where you die. If anything on this path slips, Christmas slips. Everything else has slack—time you can use to absorb problems or defer to January if things break."

Vasco stared at the diagram. The critical chain showed the minimum time to completion. Everything else was negotiable.

The Resource Reality

"Now the uncomfortable question," Carmen continued. "Who does what on the critical chain?"

They mapped it out:

Joel: API endpoints, CSV loading, data pipeline (critical chain: ingestion, validation)
Wheeler: Database design, optimization, queries (critical chain: scoring, lists)
Quinn and Alice: Test framework, integration tests, data validation (critical chain: final integration)
Vasco: Architecture decisions, stakeholder communication, triage

The critical chain bounced between people: Ingestion (Joel) → Validation (Joel) → Scoring (Wheeler) → Lists (Wheeler) → Testing (Quinn and Alice).

"See the problem?" Carmen asked.

Vasco saw it. "Handoffs. Joel finishes ingestion, but Wheeler might still be working on parallel database setup. So Joel starts something else. Then Wheeler's ready but Joel is deep in the new task..."

"Exactly. It's like a relay race. You don't start running when the previous runner finishes—you start when they're close enough to hand off the baton smoothly. That's called full-kit: don't start a critical chain task until everything it needs is ready AND the person is available."

They reorganized the first week:

Day 1-2: Joel focuses on CSV ingestion (critical chain)
Day 2-3: Wheeler handles database setup in parallel (off critical chain)
Day 3: Joel starts validation (critical chain) - Wheeler ready to receive
Day 4: Clean handoff to Wheeler for scoring algorithm

"No multitasking on the critical chain," Carmen emphasized. "Everything else can be parallel work."

What Happens When a Day Isn't a Day

"What happens if something comes up and it takes longer than a day to finish a task?" Vasco asked.

"Good question," Carmen said. "How would you normally solve this?"

"We'd add some buffer to the estimate, but we're not estimating anymore."

"Technically," said Carmen, "you're still estimating, just differently. You're estimating the complexity to be what you can accomplish in a single day. That's an easier thing to estimate, but you can still be wrong sometimes. That's where buffers come in."

She grabbed a marker. "Traditional approach: estimate each task, then pad each one for safety. 'This is 1 day but I'll say 2 to be safe.' What happens?"

"Parkinson's Law," Vasco said. "Work expands to fill the time. Everyone uses the full time whether they need it or not."

"Right. Plus student syndrome—people don't start until the deadline is close. So you get procrastination AND wasted padding. Then they still run late. So instead of padding each slice, we pool the buffer."

"How do we know how big the buffer should be?" Vasco asked.

"If we were doing estimates, we could take the difference between an aggressive and a safe estimate for each task. With No Estimates, we've got to do it a little differently." Carmen did the math on the whiteboard: "We start with a rule of thumb: a buffer of about 50% of your critical chain duration. You have twelve slices on the critical chain. Each sized to one day of complexity. That's twelve days, so start with a six-day buffer. Eighteen days total. You have twenty-four days until Christmas—plenty of room."

"That feels arbitrary."

"It is, to start. But you refine it with empirical data. As you measure your actual throughput, you'll see your real variance. If your slices average 1.3 days instead of 1, that's your actual variance—and that tells you how to size future buffers. The 50% rule of thumb gets you started; reality calibrates you."

"And the buffer absorbs the times we're wrong about complexity?"

"Exactly. You're not padding each slice—you're pooling the expected variance at the end where you can manage it. And updating it as you learn more about your variance." Carmen drew a diagram:

"The rules are simple:

Size each slice to one day of complexity. If it's bigger, break it down.
No padding individual slices. The buffer handles variance.
Watch buffer consumption. If slices consistently take 2+ days, you're burning buffer fast.
Buffer consumption tells you when to cut scope.

"What about when tasks finish early?"

"On the critical chain, that's buffer you didn't use—it stays available for later. Off the critical chain, it's just extra slack. Either way, keep moving."

"So 'No Estimates' is really about estimating complexity instead of time?"

"Exactly. Complexity is easier to estimate than time. 'This is about one day of work' is a much easier judgment than 'this will take exactly 8 ideal development hours.' But you're still making a judgment, and sometimes you're wrong. The buffer handles that."

Week 1: Testing the Theory

By Day 7, they'd completed 10 slices total. The critical chain had 4 slices done. Buffer still intact at 6 days.

"We're accelerating," Vasco told Carmen at the daily check-in.

"Good. But don't celebrate yet," Carmen warned. "This is where teams can get sloppy. Focus on releasing slices. Your buffer is for later."

The board showed clearly: critical chain progressing steadily, parallel work happening alongside. The visualization made it obvious what mattered.

Week 2: When Theory Meets Reality

Day 10 brought the first real problem. Joel finished the scoring algorithm slice and tried to hand off to Wheeler for database optimization. But Wheeler was still buried in parallel work—setting up monitoring, building backup systems.

Vasco called Carmen. "The critical chain is blocked. Wheeler's not ready to receive."

"What did we say about the relay race?"

"Right. Full-kit principle." Vasco looked at the board. "Wheeler needs to drop the monitoring work. That's off the critical chain—it can wait. The critical chain is blocked, which means Christmas is blocked."

Wheeler switched the next day. The handoff completed. Critical chain kept moving.

Cost: They consumed one day of buffer. But the critical chain didn't slip.

"This is exactly why we have the buffer," Carmen said later. "Not to absorb normal variance—to give us decision power when the critical chain gets blocked."

Week 3: The Buffer Saves Christmas

Day 16: Disaster. But not a technical one.

The Mall Santa Union needed to be able to upload toy requests into the database. Marketing was demanding to know when that feature would be available. This had been promised by Project Veritas as part of their MVP—but it was never in Vasco's original scope.

Vasco called Carmen. "They want us to add a feature. Toy request uploads from the mall Santas."

He broke down the new work:

Add database table for requests (0.5 days)
Build upload endpoint (1 day)
Add validation logic (0.5 days)

"Two days of new work. Is any of it on the critical chain?"

Vasco thought about it. "The upload endpoint would need the database schema to be finalized. That's after ingestion and validation... yes, it would go on the critical chain."

Carmen pulled up the buffer tracking. "Show me the math."

Vasco did the calculation:

Original: 5 slices remaining on critical chain ÷ 1.4/day = 4 days remaining
After adding toy requests: 7 slices ÷ 1.4/day = 5 days remaining
Buffer remaining: 5 days (started with 6, used 1 in Week 2)
Total needed: 10 days
Available: 8 days until Christmas

"We're over," Carmen said. "What does that mean?"

"Time to cut scope?" Vasco suggested.

"Show me what's NOT on the critical chain."

Vasco examined the network diagram. The audit report generation system had three slices:

Design report schema
Implement report generation
Build report UI

None were on the critical chain. They had slack.

"That's the beauty of the critical chain," Carmen explained. "Scope negotiation becomes objective, not political. Without this diagram, everyone argues their feature is critical. With it? The data shows you what actually has slack."

They showed Santa the network diagram with the buffer burn rate. "We can add the toy request uploads and ship core functionality on time—but we need to push the audit reports to January. The data is all stored and auditable in the database. We just won't have fancy reports on Christmas Eve."

Santa chose toy requests.

They removed the three report slices from December scope (not from the critical chain—they were already off it) and added the toy request slices.

New math: 7 slices remaining ÷ 1.4/day = 5 days + 3 days buffer cushion = 8 days. They'd ship on December 23rd, but with less margin than they'd like.

"The buffer gave us decision time," Carmen said. "And the critical chain told us WHAT to cut without politics. Anything not on the chain is negotiable. Anything on the chain determines whether Christmas happens."

Week 4: The Finish

December 22nd: Final critical chain slice completed.

December 23rd: Integration testing with buffer to spare.

December 24th, 6 AM: NaughtyNice 3.0 went live.

"We used half a day of buffer," Vasco told Carmen afterward. "If we'd padded every slice instead, everyone would've used their padding and we'd be late."

"Exactly," Carmen said. "That's the difference between spreading uncertainty across thirty tasks and pooling it where you can actually manage it."

What Critical Chain Added to No Estimates

After Christmas, Vasco did a retrospective with the team.

No Estimates gave them empirical data: throughput, velocity, actual progress. But Critical Chain gave them the structure to use that data effectively:

Dependency management: Not all slices are equal. The critical chain determines project duration. Everything else has slack.

Resource protection: Prevent multitasking on critical work. Full-kit principle keeps handoffs smooth—don't start until you can finish.

Buffer management: Pool uncertainty at the end where you can manage it, not spread across individual tasks where it gets wasted.

Objective scope negotiation: This is huge. Without Critical Chain, cutting scope is political—everyone argues their feature matters most. With Critical Chain, it's data-driven: anything not on the critical chain can be deferred without affecting the deadline. Anything ON the chain is truly critical.

Focus and steering: When the buffer burns, you know exactly where to cut scope or add resources. The critical chain is your constraint map.

Relay race mentality: Next person prepares to receive work before it arrives. No "I'll get to it when I'm free."

Together, Carmen's approach answered three questions:

No Estimates: "How fast are we actually going?"
Critical Chain: "Where should we be going, and what's blocking us?"
Fixed Scope + Critical Chain: "What can we defer without missing the deadline?"

The irony? Vasco came to Carmen on Day 1 thinking No Estimates had failed before they'd even started. The problem wasn't No Estimates—it was not understanding which work had slack versus which didn't.

For Your Workshop

Want to use Critical Chain to steer your Perl projects?

Start with bounded scope. List all the features you WANT. Then identify which are must-haves for initial release. This creates negotiating room.

Break work to fixed size. Size each slice to one day of complexity. If it's bigger, break it down. This is "No Estimates"—estimating complexity instead of time. Complexity is easier to judge: "This feels like about a day of work" beats "This will take exactly 6.5 hours."

Map your dependencies first. After breaking work into slices, draw the network. What has to happen in sequence? What can be parallel?

Find the critical chain. Longest dependent path through the project. This is your constraint—it determines minimum project duration.

Use the chain for scope decisions. When you need to cut scope (and you will), cut from slices NOT on the critical chain. They have slack. Anything on the chain is truly critical to shipping.

Protect the chain. No multitasking on critical work. Full-kit starts only.

Pool your buffer. Don't pad individual slices. Add buffer time at the project level—start with 50% of critical chain duration as a rule of thumb, then refine based on your actual throughput variance. The buffer is where reality meets your complexity estimates.

Watch buffer consumption. If you're burning buffer faster than completing work, that's your signal to negotiate scope. The critical chain tells you what's negotiable.

Think about using No Estimates for the data. Throughput tells you how fast you're moving through the chain.

Use Critical Chain for the structure. The chain tells you what to focus on and what can be deferred.

This Christmas season, give yourself the gift of knowing both how fast you're going and where you're headed.

May your critical chains be short and your buffers be sufficient.

Epilogue

Carmen consults on projects across the entire workshop. Her advice is simple: "Find your constraint. Protect it. Exploit it. Everything else is noise." The Veritas team is still trying to figure out their Critical Path. They estimate they'll have it mapped by summer.

Thirty Slices, Twenty-Four Days: How Christmas Was Saved By Abandoning Estimation

2025-12-13T00:00:00Z

The Crisis That Estimation Built

December 1st. Vasco sat in the emergency management meeting with a sinking feeling in his stomach.

"Project Veritas is not going to be ready," the Senior Elf for Software Development announced. "New estimate: March."

The room erupted. Back in January, that same team had promised the system would ship by Christmas. Management had approved Old Elf Morris's retirement based on that promise. Morris was now somewhere in the Caribbean, sending postcards and ignoring emails with his out-of-office: "I'm retired. Not my problem."

The legacy NaughtyNice.pl—50,000 lines of Perl4 written in 1991—had been limping along all year. No one dared touch it. When someone tried a test run last week, it crashed with a cryptic error about $biglist and package names. Nobody knew how Morris had kept it running.

"Vasco," Santa said, turning to him with that look. "I need a solution. Form a skunkworks team, get me something that will work. We only have 24 days."

"But—"

"The Veritas team estimated it would be done. They're already three months late and counting. I don't want estimates. I want it working by Christmas Eve."

Vasco stared at his notepad. 24 days. 2 billion kids. A completely new system. His team knew Perl inside and out—that was the obvious choice. But absolutely no time to figure out how long it would take.

The No Estimates Gambit

Vasco grabbed four of the best Perl elves he knew: Joel (web APIs), Wheeler (databases), and the testing team of Quinn and Alice. At a team meeting that afternoon, panic set in.

"We should estimate how long—" Joel started.

"No." Carmen appeared behind them. She'd been at the workshop since before Scrum was cool. "You've already lost if you start by guessing."

"But management needs to know—"

"Management knows when you need to be done. Management needs confidence that you'll actually be done on time. They just watched a team spend a year being wrong about their estimates. Give them something better: the truth."

Carmen laid out the approach: Stop trying to predict how long each task takes. Break the work into the smallest possible deployable slices—all the same size. Ship something working every single day. Measure your actual throughput. Use real data to forecast.

"We list everything that needs to work," Carmen explained. "Then we break each piece until it's small enough to finish in one day—about a day's complexity. Everything gets normalized to that same size. We ship it. We count how many slices we're completing. After a few days, we know our velocity. Then it's just math."

Vasco was skeptical. "What do I tell Santa when he asks when we'll be done?"

"After three days, you tell him based on what you've actually accomplished, not what you hope to accomplish. Way more honest than 'six weeks' or whatever number feels safe to say."

They had nothing to lose. The Veritas team had already proven that traditional estimation wasn't going to work.

Week 1: Finding the Rhythm

Day 1, Vasco and the team listed everything the system needed to do. Then they broke it down:

"'Build behavior ingestion system' That's too vague, too big." Vasco complained.

So they split it into smaller pieces:

Read CSV file of behavior reports → parse basic fields → store in database
Add field validation
Add deduplication logic
Handle different field elf data formats
Optimize for 2 billion records

Each piece was something they could finish and deploy in a day.

They counted: 30 total slices needed. Quick math: 30 slices × 1 day each = 30 days of work. They had 24 days.

"We're not gonna get everything done," Vasco said.

"Maybe," Carmen replied. "But you'll get faster as time goes on. Focus on shipping."

By end of Day 1, they had working code:

use v5.40;
use experimental 'class';

class BehaviorIngestor {
&nbsp;&nbsp;&nbsp;&nbsp;field $dbh :param;

&nbsp;&nbsp;&nbsp;&nbsp;method ingest_csv($filename) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;open my $fh, '&lt;', $filename or die $!;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (my $line = &lt;$fh&gt;) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ($kid_id, $behavior, $date) = split /,/, $line;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$dbh-&gt;do(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'INSERT INTO behaviors (kid_id, behavior, date) VALUES (?, ?, ?)',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;undef, $kid_id, $behavior, $date
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
}

Shipped. Tested. Working in staging. One slice complete.

Day 2: Field validation added. Another slice done.

Day 3: Deduplication logic. Third slice.

Week 2: The Acceleration

Something unexpected happened. By Day 7, they'd completed 10 slices total. The team was accelerating—they understood the codebase now, had their tooling working, found their rhythm.

New velocity: ~1.4 slices per day.

Remaining slices: 20.

New math: 20 ÷ 1.4 = 14 days = December 22nd.

They were going to make it.

But Vasco didn't trust it yet. He'd seen too many projects look good early and then crater. He kept shipping, kept measuring.

The Scope Creeps

Day 16: Disaster. But not a technical one.

"We need this," the Senior Elf for Software Development said. "The union is getting anxious."

In the old estimation world, this would trigger re-planning, re-estimating, panic, schedule slips, and probably a few arguments about whose fault it was.

Vasco looked at the board. He broke down the toy request feature:

Add database table for requests (0.5 days)
Build upload endpoint (1 day)
Add validation logic (0.5 days)

Two days of new work. He checked the remaining slices and their pace.

"We can do it," Vasco told Santa during a project review. "But we'll need to drop the audit report generation and add it in January. The data is all stored and auditable in the database. We just won't have fancy reports on Christmas Eve."

The key difference: They could see the trade-off. The board showed exactly what was left. They weren't guessing about invisible remaining work—it was all visible.

Santa nodded. Real data. Real options. No fantasy. "Do the toy requests. We'll get reports later."

Week 4: The Finish

December 22nd, 4 PM: The last core slice shipped. The system was working.

December 23rd: Integration testing with real field elf data. A few bugs found and fixed (each was small because the slices were small).

December 24th, 6 AM: NaughtyNice 3.0 went live.

2 billion kids processed. Lists generated. Workshop shipping presents on schedule.

Meanwhile, the Veritas team was still in a planning meeting, re-estimating their remaining work.

What Made It Work

After Christmas, Vasco and Carmen did a retrospective.

The No Estimates approach worked because:

Fixed scope from the start. Santa gave them clear, non-negotiable requirements: ingest behavior data, score kids against criteria, generate nice/naughty lists, handle 2 billion records, be auditable. The scope was bounded. What WAS negotiable: which features shipped in December versus January. This is critical—No Estimates works when you can trade scope for time, not when everything is mandatory.

Small slices kept problems small. When the database scaling issue hit, it was one slice to fix, not a three-week replanning disaster.

One-day slices protected focus. The smallest unit of work became a contract: developers wouldn't be asked to context-switch in smaller units than one day. This meant uninterrupted focus time and fewer "quick questions" derailing progress.

Daily shipping caught integration bugs immediately. No "it works on my machine" surprises in week 3.

Real data enabled real decisions. When velocity dipped, they could see exactly what was left and have honest conversations about scope. "We can ship these 8 slices by Christmas, or these 12 slices by New Year's—your choice."

No time wasted on estimation theater. They spent zero hours in planning poker, zero hours defending estimates, zero hours re-estimating. They spent those hours shipping instead.

Stakeholders had real visibility. Santa could see the board. He knew what worked, what was left, what was at risk. Way better than "we're 73% complete."

The irony? The whole crisis existed because someone had estimated Project Veritas would be done by Christmas. They're now three months late and still not shipping. Vasco's team delivered in 24 days by normalizing work to a single size and measuring reality instead of predicting the future.

For Your Workshop

Want to try No Estimates on your Perl projects?

Start with bounded scope. No Estimates works best when you can negotiate WHICH features ship, not WHEN you ship. If every feature is mandatory AND the deadline is fixed, you don't have a planning problem—you have a self-honesty problem. Define your must-haves clearly.

Normalize to one size. Traditional estimation is two steps from reality: estimate complexity, then estimate time. Fix time to one day and you only estimate complexity. What can you finish by tomorrow? "Add user authentication" becomes "login form," "password validation," "session handling." Complexity is easier to judge, and variance gets absorbed by the buffer.

Measure throughput. Count completed slices per week. That's your data.

Make work visible. A kanban board or even gantt chart showing what's done, what's next, what's left. No hiding.

Use data to forecast. After a few days, you know your pace. Remaining work ÷ pace = honest forecast. This is where you negotiate: "At current pace, these 10 slices ship by deadline. These other 5 slip to next month. Which matters more?"

Keep stakeholders honest too. Show them real progress. Let them reprioritize based on what's actually left.

This Christmas season, give yourself the gift of predictability through measurement.

May your deployments be frequent and your predictions be accurate.

Epilogue

Vasco's NaughtyNice 3.0 processed 2,147,483,647 kids in 47 minutes on Christmas Eve. Project Veritas launched a Demo the following April. It was deprecated immediately because Vasco's system was already handling everything.

Teaching Art to Computers the Hard Way

2025-12-11T00:00:00Z

"You shouldn't do art"

I was told this over and over growing up as a kid. "Your mind doesn't work that way," being the rationale for this. Teachers, if you are reading this, NEVER tell a kid that. Seriously. I believed it for nearly a half-century, then wrote my first novel, and later painted my first-ever oil painting. Anyone can do art of some kind.

To be fair to those teachers of long ago, my mind does like orderly art. I struggle with understanding impressionist art, but realism and abstraction both move me in ways I never thought possible: Realism, because it tells a story, and abstraction, because I strive to understand what is being abstracted, and can spend hours staring at an abstract painting and trying to grok the fullness of it.

Which brings us to Piet Mondrian. Surely you've heard of this famous Dutch man, a pioneer of 20th-century abstract art who believed that to properly abstract reality, we should use as little reality as possible? No? Well, maybe you've seen his work:

So looking at Tableau I here, I think to myself, "Self, could you teach a computer to do that?" and I answered, "Self, I betcha we can."

A bit of noodling around on the web discovered that someone had already done this in Python, and I liked their basic approach—use some configurable random number generators to generate a virtual canvas. But let's extend that some in the Perl instance. I'd like to have it working with close to Mondrian-correct colors as shown in Tableau I, and be able to output JPG, PNG, and SVG instead of the terminal. I'll use Moo, mostly because I like Moo, and it makes this generator into a modular object you could use later to store/retrieve specifications of Mondrian-styled paintings, if you want. Let's get started:

# Required:
#
#   cpan Moo Svg::Simple Imager Imager::File::PNG Imager::File::JPEG

package Acme::Mondrian::Generator;
use strict;
use warnings;
use Moo;
use Svg::Simple;
use Imager;
use Imager::File::PNG;  # We don't actually have to include these here, but they must
use Imager::File::JPEG; # be installed!

# Stuff the user can control on creation, with defaults
has resolution =&gt; ( is =&gt; 'ro', default =&gt; sub { return 80 } );      # width in cells
has aspect     =&gt; ( is =&gt; 'ro', default =&gt; sub { return 0.75 } );    # height = width * aspect
has line_thickness =&gt; ( is =&gt; 'ro', default =&gt; sub { return 4 } );   # SVG black line thickness
has scale_px       =&gt; ( is =&gt; 'ro', default =&gt; sub { return 20 } );  # px per cell in PNG/SVG
has palette =&gt; (
&nbsp;&nbsp;&nbsp;is      =&gt; 'ro',
&nbsp;&nbsp;&nbsp;default =&gt; sub {
      # I did some googling around for these, then asked ChatGPT for the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# RGB numbers.
      return {   # I used I&lt;Tableau I&gt; and an eyedropper tool for the web for these.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;white  =&gt; [ 224, 220, 221 ],        # lead white approximation
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;black  =&gt; [ 54,  37,  36 ],         # bone + carbon black
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;red    =&gt; [ 246, 68, 58 ],          # hematite / iron-oxide red
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;yellow =&gt; [ 238, 184, 42 ],         # mix: cadmium yellow / ochre / chrome yellow
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;blue   =&gt; [ 48, 50, 124 ],          # dark blue
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;}
);

# Logical canvas (grid)
has canvas =&gt; ( is =&gt; 'rw', default =&gt; sub { return {} } );
has width  =&gt; ( is =&gt; 'rw' );  # We'll calculate these at runtime.
has height =&gt; ( is =&gt; 'rw' );

1;

Okay, let's start working on the generator; this is the fiddly bit of the whole problem. In sub generate, which will need no parameters other than the object it$self, we can start by calculating and initializing the whole "canvas":

sub generate {
&nbsp;&nbsp;my $self = shift;
&nbsp;&nbsp;my $W = $self-&gt;resolution;
&nbsp;&nbsp;my $H = int( $self-&gt;resolution * $self-&gt;aspect );

&nbsp;&nbsp;$self-&gt;width($W);
&nbsp;&nbsp;$self-&gt;height($H);

&nbsp;&nbsp;my %canvas;
&nbsp;&nbsp;$self-&gt;canvas( \%canvas );

  # Initialize white grid
  for my $x ( 0 .. $W - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $y ( 0 .. $H - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;$x,$y&quot;} = 'white';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;}

Next, we need some lines, both vertical and horizontal. You could do these in either order, I suppose, but I'll start with vertical lines, then do horizontals. I'm not usually a fan of lexical blocks like this, but it keeps Perl::Critic and Test::NoWarnings happier, by avoiding redefining $x and $y in a haphazard way.

# Random thick grid lines like Mondrian
my $min_x_gap = int($W/10);
my $max_x_gap = int($W/5);
my $min_y_gap = int($H/10);
my $max_y_gap = int($H/5);

my $numberOfSegmentsToDelete = 0;

# Vertical lines
my @vlines;
{
&nbsp;&nbsp;&nbsp;&nbsp;my $x = int( rand( $max_x_gap - $min_x_gap + 1 ) ) + $min_x_gap;
&nbsp;&nbsp;&nbsp;&nbsp;while ( $x &lt; $W - $min_x_gap ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$numberOfSegmentsToDelete++;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @vlines, $x;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $y ( 0 .. $H - 1 ) { $canvas{&quot;$x,$y&quot;} = 'black' }
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$x += int( rand( $max_x_gap - $min_x_gap + 1 ) ) + $min_x_gap;
&nbsp;&nbsp;&nbsp;&nbsp;}
}

# Horizontal lines
my @hlines;
{
&nbsp;&nbsp;&nbsp;&nbsp;my $y = int( rand( $max_y_gap - $min_y_gap + 1 ) ) + $min_y_gap;
&nbsp;&nbsp;&nbsp;&nbsp;while ( $y &lt; $H - $min_y_gap ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @hlines, $y;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $x ( 0 .. $W - 1 ) { $canvas{&quot;$x,$y&quot;} = 'black' }
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$y += int( rand( $max_y_gap - $min_y_gap + 1 ) ) + $min_y_gap;
&nbsp;&nbsp;&nbsp;&nbsp;}
}

If we were to output $canvas, we'd get a random canvas of black lines and white blocks, with the lines unevenly spaced. There should be between five and ten of each, based on the max and min gaps above.

Mondrian did not always have his lines going all the way across; as you can see in Tableau I, he would occasionally delete one. This part is a bit tricky, as we need to find a single segment of line at a time.

my $numberOfRectanglesToPaint = $numberOfSegmentsToDelete - 3;
$numberOfSegmentsToDelete = int( $numberOfSegmentsToDelete * 1.5 );

# Delete a segment
for ( 1 .. $numberOfSegmentsToDelete ) {
&nbsp;&nbsp;&nbsp;&nbsp;while (1) {    # let's look for a black spot on the canvas.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $startx = int( rand( $W - 2 ) ) + 1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $starty = int( rand( $H - 2 ) ) + 1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next if $canvas{&quot;$startx,$starty&quot;} eq 'white';

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $orientation;    # Are we on a vertical line, or a horizontal
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (   $canvas{ ( $startx - 1 ) . &quot;,$starty&quot; } eq 'white'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp; $canvas{ ( $startx + 1 ) . &quot;,$starty&quot; } eq 'white' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$orientation = 'vertical';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif ($canvas{ &quot;$startx,&quot; . ( $starty - 1 ) } eq 'white'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp; $canvas{ &quot;$startx,&quot; . ( $starty + 1 ) } eq 'white' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$orientation = 'horizontal';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else {    # We're at an intersection, so don't delete here.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my @points    = (&quot;$startx,$starty&quot;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $canDelete = 1;

        # now find the collection of points on the rest of that segment, and push
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# them into @points.
        if ( $orientation eq 'vertical' ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $dy ( -1, 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $yy = $starty;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while ( $yy &gt; 0 &amp;&amp; $yy &lt; $H - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$yy += $dy;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $l = $canvas{ ( $startx - 1 ) . &quot;,$yy&quot; };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $r = $canvas{ ( $startx + 1 ) . &quot;,$yy&quot; };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ( $l eq 'black' &amp;&amp; $r eq 'black' ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif (( $l eq 'white' &amp;&amp; $r eq 'black' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|| ( $l eq 'black' &amp;&amp; $r eq 'white' ) )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canDelete = 0;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @points, &quot;$startx,$yy&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last unless $canDelete;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else {    # horizontal
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $dx ( -1, 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $xx = $startx;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while ( $xx &gt; 0 &amp;&amp; $xx &lt; $W - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$xx += $dx;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $u = $canvas{ &quot;$xx,&quot; . ( $starty - 1 ) };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $d = $canvas{ &quot;$xx,&quot; . ( $starty + 1 ) };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ( $u eq 'black' &amp;&amp; $d eq 'black' ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif (( $u eq 'white' &amp;&amp; $d eq 'black' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|| ( $u eq 'black' &amp;&amp; $d eq 'white' ) )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canDelete = 0;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @points, &quot;$xx,$starty&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last unless $canDelete;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next unless $canDelete;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{$_} = 'white' for @points;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;}
}

A 1-cell black border around the image would be nice:

# Border
for my $xx ( 0 .. $W - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;$xx,0&quot;} = 'black';
&nbsp;&nbsp;&nbsp;&nbsp;$canvas{ &quot;$xx,&quot; . ( $H - 1 ) } = 'black';
}
for my $yy ( 0 .. $H - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;0,$yy&quot;} = 'black';
&nbsp;&nbsp;&nbsp;&nbsp;$canvas{ ( $W - 1 ) . &quot;,$yy&quot; } = 'black';
}

Okay, now the next hard part, painting in a few rectangles. In this case, we're going to look for white space, then continue filling white space around it recursively until we hit a line.

# Flood fill rectangles
my @fillcolors = qw(red yellow blue white white white);    # biased toward white
my %seen;

for ( 1 .. $numberOfRectanglesToPaint ) {
&nbsp;&nbsp;&nbsp;&nbsp;my ( $sx, $sy );
&nbsp;&nbsp;&nbsp;&nbsp;for ( 1 .. 200 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$sx = int( rand($W) );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$sy = int( rand($H) );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last if $canvas{&quot;$sx,$sy&quot;} eq 'white';
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;my $color = $fillcolors[ rand @fillcolors ];

&nbsp;&nbsp;&nbsp;&nbsp;my @stack = (&quot;$sx,$sy&quot;);
&nbsp;&nbsp;&nbsp;&nbsp;while (@stack) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $pt = pop @stack;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next if $seen{$pt}++;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $x, $y ) = split /,/, $pt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{$pt} = $color;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$seen{$pt}++;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $d ( [ -1, 0 ], [ 1, 0 ], [ 0, -1 ], [ 0, 1 ] ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $nx, $ny ) = ( $x + $d-&gt;[0], $y + $d-&gt;[1] );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next if $nx &lt; 0 || $ny &lt; 0 || $nx &gt;= $W || $ny &gt;= $H;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $k = &quot;$nx,$ny&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @stack, $k if $canvas{$k} eq 'white';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
}

return 1;
&nbsp;&nbsp;}

And that's the end of sub generate. I'll return 1 at the end, just for tidiness' sake. At that point, the object now has a well-defined canvas that should look somewhat like a Mondrian painting. Now we need an output method. Nothing fancy here, but Imager will let you output either jpg or png, by just specifying the filename you want to use.

sub save_png_or_jpg {
&nbsp;&nbsp;&nbsp;&nbsp;my ( $self, $file ) = @_;
&nbsp;&nbsp;&nbsp;&nbsp;my $scale  = $self-&gt;scale_px;
&nbsp;&nbsp;&nbsp;&nbsp;my $W      = $self-&gt;width;
&nbsp;&nbsp;&nbsp;&nbsp;my $H      = $self-&gt;height;
&nbsp;&nbsp;&nbsp;&nbsp;my %canvas = %{ $self-&gt;canvas };

&nbsp;&nbsp;&nbsp;&nbsp;my $img = Imager-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xsize    =&gt; $W * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ysize    =&gt; $H * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channels =&gt; 3
&nbsp;&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;&nbsp;for my $k ( keys %canvas ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $x, $y ) = split /,/, $k;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $rgb   = $self-&gt;palette-&gt;{ $canvas{$k} };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $color = Imager::Color-&gt;new(@$rgb);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$img-&gt;box(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xmin   =&gt; $x * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ymin   =&gt; $y * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xmax   =&gt; ( $x + 1 ) * $scale - 1,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ymax   =&gt; ( $y + 1 ) * $scale - 1,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;color  =&gt; $color,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;filled =&gt; 1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;$img-&gt;write( file =&gt; $file ) or die $img-&gt;errstr;
}

After that, I scribbled up a little script to generate a Mondrian-styled painting using the default behaviors, and have it output a JPG.

...and that's how I started teaching art classes to Perl.

In the module I'll be releasing to CPAN this holiday season (look for "Acme::Mondrian::Generator" in the next week or so, and I'll be sure to update this to a link), I'll also include a script to let you play around with the parameters of the generator, and output PNGs and SVGs as well as JPGs.

For completeness, here's the whole Acme::Mondrian::Generator package after a bit of tidying-up:

package Acme::Mondrian::Generator;
use strict;
use warnings;
use Moo;
use Svg::Simple;
use Imager;

# Stuff the user can control on creation, with defaults
has resolution     =&gt; ( is =&gt; 'ro', default =&gt; sub { return 80 } );   # width in cells
has aspect         =&gt; ( is =&gt; 'ro', default =&gt; sub { return 0.75 } ); # height = width * aspect
has line_thickness =&gt; ( is =&gt; 'ro', default =&gt; sub { return 4 } );    # SVG black line thickness
has scale_px       =&gt; ( is =&gt; 'ro', default =&gt; sub { return 20 } );   # px per cell in PNG/SVG
has palette =&gt; (
&nbsp;&nbsp;&nbsp;is      =&gt; 'ro',
&nbsp;&nbsp;&nbsp;default =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return {   # I used I&lt;Tableau I&gt; and an eyedropper tool for the web for these.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;white  =&gt; [ 224, 220, 221 ],        # lead white approximation
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;black  =&gt; [ 54,  37,  36 ],         # bone + carbon black
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;red    =&gt; [ 246, 68, 58 ],          # hematite / iron-oxide red
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;yellow =&gt; [ 238, 184, 42 ],         # mix: cadmium yellow / ochre / chrome yellow
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;blue   =&gt; [ 48, 50, 124 ],          # dark blue

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;};
&nbsp;&nbsp;&nbsp;}
);

# Logical canvas (grid)
has canvas =&gt; ( is =&gt; 'rw', default =&gt; sub { return {} } );
has width  =&gt; ( is =&gt; 'rw' );                   # We'll calculate these
has height =&gt; ( is =&gt; 'rw' );

sub generate {
&nbsp;&nbsp;&nbsp;my $self = shift;

&nbsp;&nbsp;&nbsp;my $W = $self-&gt;resolution;
&nbsp;&nbsp;&nbsp;my $H = int($self-&gt;resolution * $self-&gt;aspect);
&nbsp;&nbsp;&nbsp;$self-&gt;width($W);
&nbsp;&nbsp;&nbsp;$self-&gt;height($H);

&nbsp;&nbsp;&nbsp;my %canvas;
&nbsp;&nbsp;&nbsp;$self-&gt;canvas(\%canvas);

   # Initialize white grid
   for my $x (0..$W-1) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $y (0..$H-1) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;$x,$y&quot;} = 'white';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;}

   # Random thick grid lines like Mondrian
   my $min_x_gap = int($W/10);
&nbsp;&nbsp;&nbsp;my $max_x_gap = int($W/5);
&nbsp;&nbsp;&nbsp;my $min_y_gap = int($H/10);
&nbsp;&nbsp;&nbsp;my $max_y_gap = int($H/5);

&nbsp;&nbsp;&nbsp;my $numberOfSegmentsToDelete = 0;

   # Vertical lines
   my @vlines;
&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $x = int( rand( $max_x_gap - $min_x_gap + 1 ) ) + $min_x_gap;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while ( $x &lt; $W - $min_x_gap ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$numberOfSegmentsToDelete++;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @vlines, $x;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $y ( 0 .. $H - 1 ) { $canvas{&quot;$x,$y&quot;} = 'black' }
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$x += int( rand( $max_x_gap - $min_x_gap + 1 ) ) + $min_x_gap;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;}

   # Horizontal lines
   my @hlines;
&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $y = int( rand( $max_y_gap - $min_y_gap + 1 ) ) + $min_y_gap;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while ( $y &lt; $H - $min_y_gap ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @hlines, $y;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $x ( 0 .. $W - 1 ) { $canvas{&quot;$x,$y&quot;} = 'black' }
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$y += int( rand( $max_y_gap - $min_y_gap + 1 ) ) + $min_y_gap;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;my $numberOfRectanglesToPaint = $numberOfSegmentsToDelete - 2;
&nbsp;&nbsp;&nbsp;$numberOfSegmentsToDelete     = int($numberOfSegmentsToDelete * 1.5);

   # Delete segments
   for ( 1 .. $numberOfSegmentsToDelete ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (1) {                   # let's look for a black spot on the canvas.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $startx = int( rand( $W - 2 ) ) + 1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $starty = int( rand( $H - 2 ) ) + 1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next if $canvas{&quot;$startx,$starty&quot;} eq 'white';

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $orientation;           # Are we on a vertical line, or a horizontal
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (  $canvas{ ( $startx - 1 ) . &quot;,$starty&quot; } eq 'white'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp; $canvas{ ( $startx + 1 ) . &quot;,$starty&quot; } eq 'white' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$orientation = 'vertical';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif ( $canvas{ &quot;$startx,&quot; . ( $starty - 1 ) } eq 'white'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp; $canvas{ &quot;$startx,&quot; . ( $starty + 1 ) } eq 'white' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$orientation = 'horizontal';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else {                     # We're at an intersection, so don't delete here.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my @points    = (&quot;$startx,$starty&quot;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $canDelete = 1;

         # Now find the collection of points on the rest of that segment, and push
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# them into @points.
         if ( $orientation eq 'vertical' ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $dy ( -1, 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $yy = $starty;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while ( $yy &gt; 0 &amp;&amp; $yy &lt; $H - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$yy += $dy;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $l = $canvas{ ( $startx - 1 ) . &quot;,$yy&quot; };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $r = $canvas{ ( $startx + 1 ) . &quot;,$yy&quot; };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ( $l eq 'black' &amp;&amp; $r eq 'black' ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif ( ( $l eq 'white' &amp;&amp; $r eq 'black' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|| ( $l eq 'black' &amp;&amp; $r eq 'white' ) )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canDelete = 0;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @points, &quot;$startx,$yy&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last unless $canDelete;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else {                     # horizontal
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for my $dx ( -1, 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $xx = $startx;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while ( $xx &gt; 0 &amp;&amp; $xx &lt; $W - 1 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$xx += $dx;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $u = $canvas{ &quot;$xx,&quot; . ( $starty - 1 ) };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $d = $canvas{ &quot;$xx,&quot; . ( $starty + 1 ) };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ( $u eq 'black' &amp;&amp; $d eq 'black' ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif ( ( $u eq 'white' &amp;&amp; $d eq 'black' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|| ( $u eq 'black' &amp;&amp; $d eq 'white' ) )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canDelete = 0;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @points, &quot;$xx,$starty&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last unless $canDelete;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next unless $canDelete;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{$_} = 'white' for @points;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;}

   # Border
   for my $xx (0..$W-1) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;$xx,0&quot;} = 'black';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;$xx,&quot;.($H-1)} = 'black';
&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;for my $yy (0..$H-1) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{&quot;0,$yy&quot;} = 'black';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{($W-1).&quot;,$yy&quot;} = 'black';
&nbsp;&nbsp;&nbsp;}

   # Flood fill rectangles
   my @fillcolors = qw(red yellow blue white white);    # biased toward white
&nbsp;&nbsp;&nbsp;my %seen;

&nbsp;&nbsp;&nbsp;for ( 1 .. $numberOfRectanglesToPaint ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $sx, $sy );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for ( 1 .. 200 ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$sx = int( rand($W) );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$sy = int( rand($H) );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last if $canvas{&quot;$sx,$sy&quot;} eq 'white';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $color = $fillcolors[ rand @fillcolors ];

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my @stack = (&quot;$sx,$sy&quot;);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (@stack) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $pt = pop @stack;
         # If our $color is 'white', this way we don't loop forever.
         next if $seen{$pt}++;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $x, $y ) = split /,/, $pt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$canvas{$pt} = $color;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$seen{$pt}++;
         # If any adjacent points are white, push them in for coloring.
         for my $d ( [ -1, 0 ], [ 1, 0 ], [ 0, -1 ], [ 0, 1 ] ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $nx, $ny ) = ( $x + $d-&gt;[0], $y + $d-&gt;[1] );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;next if $nx &lt; 0 || $ny &lt; 0 || $nx &gt;= $W || $ny &gt;= $H;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $k = &quot;$nx,$ny&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @stack, $k if $canvas{$k} eq 'white';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;return 1;
}

sub save_png_or_jpg {
&nbsp;&nbsp;&nbsp;my ( $self, $file ) = @_;
&nbsp;&nbsp;&nbsp;my $scale  = $self-&gt;scale_px;
&nbsp;&nbsp;&nbsp;my $W      = $self-&gt;width;
&nbsp;&nbsp;&nbsp;my $H      = $self-&gt;height;
&nbsp;&nbsp;&nbsp;my %canvas = %{ $self-&gt;canvas };

&nbsp;&nbsp;&nbsp;my $img = Imager-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xsize    =&gt; $W * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ysize    =&gt; $H * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;channels =&gt; 3
&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;for my $k ( keys %canvas ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $x, $y ) = split /,/, $k;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $rgb   = $self-&gt;palette-&gt;{ $canvas{$k} };
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $color = Imager::Color-&gt;new(@$rgb);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$img-&gt;box(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xmin   =&gt; $x * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ymin   =&gt; $y * $scale,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;xmax   =&gt; ( $x + 1 ) * $scale - 1,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ymax   =&gt; ( $y + 1 ) * $scale - 1,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;color  =&gt; $color,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;filled =&gt; 1
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);
&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;$img-&gt;write( file =&gt; $file ) or die $img-&gt;errstr;
}

1;

...and my little script to create one!

#!/usr/bin/env perl
use strict;
use warnings;
use lib './lib';
use Acme::Mondrian::Generator;

my $gen = Acme::Mondrian::Generator-&gt;new();
$gen-&gt;generate();
my $f = &quot;mondrian_&quot;.time().&quot;.jpg&quot;;
$gen-&gt;save_png_or_jpg($f);

I hope this little bit of creativity inspires your own, whether in Perl, or on a canvas—or even in Raku or Python! Happy painting, and the happiest of holidays to you and the people you love, wherever they may be!

The Ghost of Web Frameworks Future

2025-12-10T00:00:00Z

A message from Christmas Yet to Come

It was a cold December night when the Ghost of Web Frameworks Future visited young Petra the Programmer.

"I have something to show you," the spectral figure intoned, gesturing toward Petra's laptop. "The future of Perl web development."

Petra squinted at her screen. She'd been wrestling with a familiar problem: her company's venerable Catalyst application needed real-time features. WebSockets. Server-Sent Events. The kind of persistent, bidirectional connections that made traditional request-response frameworks break out in a cold sweat.

"I've tried everything," she sighed. "I could rewrite the whole thing in Mojolicious, but that's months of work. Or I could bolt on a separate WebSocket server, but then I have two systems to maintain..."

The Ghost smiled knowingly. "What if I told you there was another way? A specification designed from the ground up for asynchronous Perl web applications? One that could run your legacy PSGI apps alongside shiny new async code?"

Petra leaned forward. "Tell me more."

Enter PAGI: The Spiritual Successor to PSGI

PAGI - the Perl Asynchronous Gateway Interface - is a new specification for async-capable Perl web applications. If PSGI was Perl's answer to Python's WSGI, then PAGI is Perl's answer to Python's ASGI.

The key insight is simple: modern web applications need more than request-response. They need:

WebSockets for real-time bidirectional communication
Server-Sent Events for efficient server push
Streaming responses for large files and live data
Lifecycle hooks for connection pooling and startup/shutdown

PSGI, brilliant as it was, assumed a synchronous world where each request got a response and that was that. PAGI embraces the asynchronous reality of modern web development.

The PAGI Interface

At its heart, a PAGI application is beautifully simple - an async coderef with three parameters:

use Future::AsyncAwait;
use experimental 'signatures';

async sub app ($scope, $receive, $send) {
&nbsp;&nbsp;&nbsp;&nbsp;# $scope   - hashref of connection metadata
&nbsp;&nbsp;&nbsp;&nbsp;# $receive - async coderef to get events FROM the client
&nbsp;&nbsp;&nbsp;&nbsp;# $send    - async coderef to send events TO the client
}

The $scope hashref tells you what kind of connection you're dealing with:

http - A standard HTTP request/response
websocket - A persistent WebSocket connection
sse - A Server-Sent Events stream
lifespan - Process startup/shutdown lifecycle

Events flow in both directions as hashrefs with a type key. It's event-driven programming, but with the ergonomics of async/await.

Your First PAGI Application

Let's start with the classic: Hello World over HTTP.

# examples/01-hello-http/app.pl
use Future::AsyncAwait;
use experimental 'signatures';

async sub app ($scope, $receive, $send) {
&nbsp;&nbsp;&nbsp;&nbsp;# We only handle HTTP - throw for anything else
&nbsp;&nbsp;&nbsp;&nbsp;die &quot;Unsupported: $scope-&gt;{type}&quot; if $scope-&gt;{type} ne 'http';

&nbsp;&nbsp;&nbsp;&nbsp;# Send the response headers
&nbsp;&nbsp;&nbsp;&nbsp;await $send-&gt;({
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;type    =&gt; 'http.response.start',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;status  =&gt; 200,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;headers =&gt; [['content-type', 'text/plain']],
&nbsp;&nbsp;&nbsp;&nbsp;});

&nbsp;&nbsp;&nbsp;&nbsp;# Send the body and signal we're done
&nbsp;&nbsp;&nbsp;&nbsp;await $send-&gt;({
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;type =&gt; 'http.response.body',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;body =&gt; 'Hello from PAGI!',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;more =&gt; 0,
&nbsp;&nbsp;&nbsp;&nbsp;});
}

Run it with:

pagi-server --app examples/01-hello-http/app.pl --port 5000
curl http://localhost:5000/
# =&gt; Hello from PAGI!

Notice how the response is split into two events: http.response.start for headers, and http.response.body for content. This separation is what enables streaming - you can send multiple body chunks with more => 1 before the final more => 0.

Real-Time with WebSockets

Now for the exciting part. Here's a WebSocket echo server:

# examples/04-websocket-echo/app.pl
use Future::AsyncAwait;
use experimental 'signatures';

async sub app ($scope, $receive, $send) {
&nbsp;&nbsp;&nbsp;&nbsp;if ($scope-&gt;{type} eq 'websocket') {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Accept the WebSocket connection
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;await $send-&gt;({ type =&gt; 'websocket.accept' });

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Event loop: receive messages and echo them back
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;while (1) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $event = await $receive-&gt;();

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ($event-&gt;{type} eq 'websocket.receive') {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $message = $event-&gt;{text} // $event-&gt;{bytes};
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;await $send-&gt;({
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;type =&gt; 'websocket.send',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;text =&gt; &quot;Echo: $message&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;});
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;elsif ($event-&gt;{type} eq 'websocket.disconnect') {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;last;  # Client disconnected, exit loop
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;elsif ($scope-&gt;{type} eq 'http') {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Serve a simple HTML page for testing
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;await $send-&gt;({
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;type    =&gt; 'http.response.start',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;status  =&gt; 200,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;headers =&gt; [['content-type', 'text/html']],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;});
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;await $send-&gt;({
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;type =&gt; 'http.response.body',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;body =&gt; '&lt;script&gt;ws=new WebSocket(&quot;ws://localhost:5000/ws&quot;);'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;. 'ws.onmessage=e=&gt;console.log(e.data)&lt;/script&gt;'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;. '&lt;p&gt;Open console and type: ws.send(&quot;Hello&quot;)&lt;/p&gt;',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;more =&gt; 0,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;});
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;else {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;die &quot;Unsupported: $scope-&gt;{type}&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;}
}

The pattern is the same: await events from $receive, send responses via $send. But now we have a persistent connection with an event loop that keeps running until the client disconnects.

Test it:

pagi-server --app examples/04-websocket-echo/app.pl --port 5000
websocat ws://localhost:5000/ws
Hello
# =&gt; Echo: Hello

The PSGI Bridge: Bringing Legacy Apps to the Future

"But wait," Petra interrupted. "I have thousands of lines of Catalyst code. I can't rewrite everything!"

The Ghost nodded sagely. "You don't have to. PAGI includes a bridge."

One of PAGI's killer features is its ability to wrap existing PSGI applications. Your battle-tested Catalyst, Dancer, or Plack app can run alongside new PAGI code on the same server.

PAGI ships with PAGI::App::WrapPSGI which handles all the translation for you:

use PAGI::App::WrapPSGI;

# Your existing PSGI application (could be Catalyst, Dancer, etc.)
my $legacy_psgi_app = sub {
&nbsp;&nbsp;&nbsp;&nbsp;my $env = shift;
&nbsp;&nbsp;&nbsp;&nbsp;return [
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;200,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;['Content-Type' =&gt; 'text/plain'],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;['Hello from legacy PSGI!'],
&nbsp;&nbsp;&nbsp;&nbsp;];
};

# Wrap it for PAGI - that's it!
my $wrapper = PAGI::App::WrapPSGI-&gt;new(psgi_app =&gt; $legacy_psgi_app);
$wrapper-&gt;to_app;

The wrapper handles all the complexity: building the PSGI %env from the PAGI scope, collecting request bodies, translating headers, and converting responses back to PAGI events. It even supports PSGI's streaming response interface.

For a real-world Catalyst app, it's just as simple:

use PAGI::App::WrapPSGI;
use MyApp;  # Your Catalyst application

my $wrapper = PAGI::App::WrapPSGI-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;psgi_app =&gt; MyApp-&gt;psgi_app
);
$wrapper-&gt;to_app;

This means you can:

Run your existing Catalyst app under PAGI
Add WebSocket endpoints alongside your legacy routes
Gradually migrate to async as needed
Share connection pools and state between old and new code

The bridge handles the translation between PAGI's event-based model and PSGI's synchronous interface transparently.

PAGI::Simple: For When You Want Express, Not Assembly

"This is powerful," Petra admitted, "but it's also... verbose. Do I really need to manually send response headers every time?"

The Ghost chuckled. "Of course not. Meet PAGI::Simple."

PAGI ships with a micro-framework inspired by Express.js and Sinatra. It handles the low-level event plumbing so you can focus on your application logic:

# examples/simple-01-hello/app.pl
use PAGI::Simple;

my $app = PAGI::Simple-&gt;new(name =&gt; 'My App');

# Simple text response
$app-&gt;get('/' =&gt; sub ($c) {
&nbsp;&nbsp;&nbsp;&nbsp;$c-&gt;text('Hello, World!');
});

# Path parameters and JSON
$app-&gt;get('/users/:id' =&gt; sub ($c) {
&nbsp;&nbsp;&nbsp;&nbsp;my $id = $c-&gt;path_params-&gt;{id};
&nbsp;&nbsp;&nbsp;&nbsp;$c-&gt;json({ user_id =&gt; $id, name =&gt; 'Santa Claus' });
});

# POST with body parsing
$app-&gt;post('/api/data' =&gt; sub ($c) {
&nbsp;&nbsp;&nbsp;&nbsp;my $data = $c-&gt;json_body;
&nbsp;&nbsp;&nbsp;&nbsp;$c-&gt;json({ received =&gt; $data, status =&gt; 'ok' });
});

$app-&gt;to_app;

WebSockets are just as clean:

# WebSocket chat with PAGI::Simple
use PAGI::Simple;

my $app = PAGI::Simple-&gt;new(name =&gt; 'Chat');

$app-&gt;websocket('/chat' =&gt; sub ($ws) {
&nbsp;&nbsp;&nbsp;&nbsp;$ws-&gt;on(open =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$ws-&gt;send('Welcome to the chat!');
&nbsp;&nbsp;&nbsp;&nbsp;});

&nbsp;&nbsp;&nbsp;&nbsp;$ws-&gt;on(message =&gt; sub ($data) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Broadcast to all connected clients
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$ws-&gt;broadcast(&quot;Someone said: $data&quot;);
&nbsp;&nbsp;&nbsp;&nbsp;});

&nbsp;&nbsp;&nbsp;&nbsp;$ws-&gt;on(close =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print &quot;Client disconnected\n&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;});
});

$app-&gt;to_app;

And Server-Sent Events for real-time dashboards:

# SSE with PAGI::Simple
use PAGI::Simple;

my $app = PAGI::Simple-&gt;new(name =&gt; 'Dashboard');

$app-&gt;sse('/events' =&gt; sub ($sse) {
&nbsp;&nbsp;&nbsp;&nbsp;# Send events periodically
&nbsp;&nbsp;&nbsp;&nbsp;my $count = 0;
&nbsp;&nbsp;&nbsp;&nbsp;$sse-&gt;on(connect =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# This would typically be triggered by real events
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$sse-&gt;send({ count =&gt; ++$count });
&nbsp;&nbsp;&nbsp;&nbsp;});
});

$app-&gt;to_app;

PAGI::Simple includes:

Express-style routing with path parameters
Built-in JSON parsing and response helpers
Session management with pluggable stores
Middleware support (CORS, logging, rate limiting, etc.)
Static file serving
WebSocket rooms and broadcasting
SSE channels with pub/sub

The Road Ahead

The Ghost began to fade. "Remember, young programmer: this is a vision of what could be, not what must be. PAGI needs champions to make it real."

PAGI is currently in early beta. It passes its tests, the examples work, but it's not yet battle-tested for production. What it needs now is:

Adventurous developers willing to experiment
Feedback on the API and specification
Testing with real-world applications
Framework authors interested in building on PAGI

PAGI is not on CPAN at the time of this writing but the repository is at https://github.com/jjn1056/pagi and it's ready for your experimentation. Just don't use it for production just yet, unless you really, really know what you are doing.

If you're interested in the future of asynchronous Perl web development - if you want WebSockets and SSE without abandoning your existing codebase - PAGI might be exactly what you're looking for.

Petra smiled as dawn broke over her keyboard. She had work to do, but for the first time in months, she felt excited about it.

Maybe the future of Perl web development was brighter than she'd thought.

Getting Started

Ready to try PAGI yourself?

git clone https://github.com/jjn1056/pagi.git
cd pagi
cpanm --installdeps .  # Install dependencies
prove -l t/            # Run the tests

# Try the examples
pagi-server --app examples/01-hello-http/app.pl --port 5000
pagi-server --app examples/simple-01-hello/app.pl --port 5000

The repository includes:

9 raw PAGI examples demonstrating the protocol
4 PAGI::Simple examples showing the micro-framework
Complete specification documents
A reference server implementation

Happy holidays, and happy hacking!

Run specific tests in Perl

2025-12-09T00:00:00Z

Have you ever had the experience of having many subtests in a single test file, making it difficult to see the test results for the parts you want to check?

With Test2::Plugin::SubtestFilter, you can run only specific subtests. This is similar to vitest's --testNamePattern or go test's -run flag in other languages.

If you use Test2::Plugin::SubtestFilter, only subtests matching the SUBTEST_FILTER environment variable will be executed. For example, given the following test file, if you specify only_run_this in SUBTEST_FILTER, only only_run_this will be executed, and do_not_run will be skipped.

use Test2::V0;
use Test2::Plugin::SubtestFilter;

subtest 'only_run_this' =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;pass;
};

subtest 'do_not_run' =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;pass;
};

done_testing;

Run the test like this:

% SUBTEST_FILTER=only_run_this prove -lvr t/test.t
# =&gt; Test `only_run_this` / Skip `do_not_run`

Tips: VSCode Extension

With the following VSCode extension, you can run tests simply by clicking the run icon for test execution. How convenient!

VSCode Extension: Perl Test

Tips: Prompt for Coding Agents

If you give a coding agent a prompt like the following, it will use SUBTEST_FILTER. By narrowing down the test results to only the areas of interest, you get the benefit of reducing context consumption.

### Test Execution Rules (Required)

**When adding or modifying functions or subtests, always use
`SUBTEST_FILTER` to run only the relevant subtest.**

Example: When adding a `power` function
```bash
# Good: Run only the relevant subtest
SUBTEST_FILTER=power prove t/Hello/Math.t

# Bad: Run all tests (slow, adds noise from unrelated tests)
prove t/Hello/Math.t
```

Run all tests (`prove t/`) only in the following cases:
- When the user explicitly requests a full test run
- When making broad changes such as refactoring
- As a final check before committing

That's all. Please give it a try. Happy testing!

Perl who is Naughty or Nice?

2025-12-08T00:00:00Z

Elves are scrambling

Santa's ETL framework went down and now the elves are tasked with writing a Perl script to process the "Naughty or Nice" master feed files. To tackle this problem Chaz (one of Santa's elves) will generate a sample feed file and use it as test data for a new Perl script.

Test Data Format

Chaz needs to be able to conform with the original format of the feed file (a CSV file) with the following fields:

first_name last_name street_address city state postal_code Naughty_or_Nice_flag

While thinking about this problem, he remembered a Perl module named Data::Random::Contact that he found while searching for a module to generate random data via MetaCPAN. So he borrowed a laptop from the toy factory and started working on a script.

Random Data Generator script

The data from Data::Random::Contact is actually generated from Fakenamegenerator.com. To make the test data as close to production, Chaz wrote the script to generate at least 200 records.

#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
use Data::Random::Contact;

# write out a randomly generated list of demographic data
my $rand = Data::Random::Contact-&gt;new();

for ( my $i = 0 ; $i &lt; 200 ; $i++ ) {

    #person() returns a hashref of contact data
    my $person = $rand-&gt;person();

    # only print if postal code is def ( some records can have empty postal code )
    if ( $person-&gt;{address}{home}{postal_code} ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $n_or_n = int( rand(2) );
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print join(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;',',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$person-&gt;{given},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$person-&gt;{surname},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$person-&gt;{address}{home}{street_1},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$person-&gt;{address}{home}{city},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$person-&gt;{address}{home}{region},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$person-&gt;{address}{home}{postal_code},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$n_or_n
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;) . &quot;\n&quot;;

&nbsp;&nbsp;&nbsp;&nbsp;}

}

The Test Data

It's a few hours before Christmas and Chaz has already written a Perl script that will generate random data needed to test his new data extractor program.

Chaz executed the script like so:

$ generate_kids_data.pl &gt; master_list.csv

and generated the sample test data (truncated for visibility):

Use Getopt::Long to select Naughty and Nice output files

Chaz is very close to the last 2 hours of Christmas Eve and now has a working Perl script that will output Naughty and/or Nice kids from the list in separate files. Chaz also had to consider the fact that the master file of kids can be sent in batches of a few hundred records at a time so he had to add the ability to pass some argument options to allow for defining a filename as an argument and to select whether the output file will contain Naughty or Nice kids.

#!/usr/bin/perl

use strict;
use warnings;
use Data::Dumper;
use Getopt::Long;

my $nice    = '';
my $naughty = '';
my $file;

# parse options
GetOptions(
&nbsp;&nbsp;&nbsp;&nbsp;&quot;nice&quot;    =&gt; \$nice,
&nbsp;&nbsp;&nbsp;&nbsp;&quot;naughty&quot; =&gt; \$naughty,
&nbsp;&nbsp;&nbsp;&nbsp;&quot;file=s&quot;  =&gt; \$file,
&nbsp;&nbsp;&nbsp;&nbsp;&quot;help&quot;    =&gt; \&amp;help,
) or die(&quot;Unable to parse information&quot;);

sub help {
&nbsp;&nbsp;&nbsp;&nbsp;die &lt;&lt;'USAGE';
Naughty_or_Nice.pl -nice -naughty

Accepts the following arguments

-nice :    generates a nice list &quot;Nice_list.csv&quot;.
-naughty : generates a naughty list &quot;Naughty_list&quot;.
-file :    file name as input. default filename &quot;master_list.csv&quot;

USAGE

}
if ( ( $nice eq &quot;&quot; ) and ( $naughty eq &quot;&quot; ) ) {
&nbsp;&nbsp;&nbsp;&nbsp;die &quot;$0 requires -nice or -naughty option&quot;;
}

my $in_fh;

# Create a filehandle from file option or default csv file.
if ($file) {
&nbsp;&nbsp;&nbsp;&nbsp;open( $in_fh, '&lt;', $file ) or die( &quot;Unable to open &quot; . $file );
}
else {
&nbsp;&nbsp;&nbsp;&nbsp;open( $in_fh, '&lt;', 'master_list.csv' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or die(&quot;Unable to open master_list.csv&quot;);
}

our ( $nice_fh, $naughty_fh );

# Create file handle for Nice and Naughty files if set.
if ($nice) {
&nbsp;&nbsp;&nbsp;&nbsp;open( $nice_fh, '&gt;', 'Nice_list.csv' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or die(&quot;Unable to open Nice_list.csv&quot;);
}
if ($naughty) {
&nbsp;&nbsp;&nbsp;&nbsp;open( $naughty_fh, '&gt;', 'Naughty_list.csv' )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or die(&quot;Unable to open Naughty_list.csv&quot;);
}

while ( my $rec = &lt;$in_fh&gt; ) {
&nbsp;&nbsp;&nbsp;&nbsp;$rec =~ s/\R//g;

    # separate the fields
    my @fields = split( /,/, $rec );

    #filter out the nice kids
    if ($nice) {
        # Nice kids get printed
        if ( $fields[6] == 1 ) { print $nice_fh ( $rec . &quot;\n&quot; ); }
&nbsp;&nbsp;&nbsp;&nbsp;}

    #filter out the naughty kids
    if ($naughty) {
        # Naughty kids get printed
        if ( $fields[6] == 0 ) { print $naughty_fh ( $rec . &quot;\n&quot; ); }
&nbsp;&nbsp;&nbsp;&nbsp;}

}

In a rush Chaz executed the script to read the master_list.csv sample file and generate the Nice and Naughty output files:

$ Naughty_or_Nice.pl -nice -naughty

This resulted in two files: Naughty_list.csv and Nice_list.csv

Happy with the results he quickly created a pull request so the release team can install the script in production and schedule a run of the script against the kids feed files.

Abstract storage of Christmas letters

2025-12-07T00:00:00Z

Few things capture childhood wonder quite like a child writing a letter to Santa. The joy of watching the little ones list all the toys and sweets they desire. It's truly magical indeed. But have you ever wondered what happens to these letters after they get sent?

Well, this isn't something Christmas Inc. would consider sharing in a LinkedIn post. Up until recently, this was... purely manual labour. Having very numerous elf workers with unlimited energy at their disposal surely delays the decision to digitalize processes. However, this year that decision has finally been made. No more manual reading of letters - they would now be gathered and fed to an AI to read and pull kids' wishes out of them.

There's just one problem - the team responsible for gathering and storing the letters hadn't yet decided on where they are going to be stored! They managed to decide that the storage must work like a filesystem, with directories named naughty and nice containing files named the same as the sender. But would it be stored in an actual filesystem? A database? A cloud storage? Maybe a mix of those? They just didn't know yet! Even worse, that team consisted of only the most undecided elves in the entire corporation - you never know if this decision will be final or not. To make up for their clumsiness, the code needed to be written in a way that will make it easy to change the underlying source of data easily.

An elf named Frosty was tasked with writing a LetterStore service, which must deliver an API action to serve contents of the letters. Frosty could write a proper abstraction that will fetch him a letter content and replace it later if needed, but maybe there's a better way? Skimming through CPAN, he noticed a module called Storage::Abstract, which seemed to be doing exactly what he needed. He could get a module now and use it for testing in local filesystem, and if the location of the letters ever change, he will only need to write / acquire a driver for that storage, replace it in the configuration, and everything will work exactly the same!

There were a couple of problems - the module was listed as beta quality, and not many storage drivers existed for it yet. But he heard that a stable release of the module was planned very soon, and last-minute suggestions or reviews were welcome. As for the drivers, well, he would have to write the code himself anyway, so he might as well write it as a Storage::Abstract driver.

With his mind set on using the module, he started writing code. First, he wrote a small package that will build a Storage::Abstract instance and let it be reconfigured via a package variable:

package LetterStore;

use v5.42;
use Storage::Abstract;

# for now, assume some local directory
our %STORAGE_CONFIG = (
&nbsp;&nbsp;&nbsp;&nbsp;driver    =&gt; 'Directory',
&nbsp;&nbsp;&nbsp;&nbsp;directory =&gt; '/home/santa/letters',
);

sub get {
&nbsp;&nbsp;&nbsp;&nbsp;state $instance = Storage::Abstract-&gt;new(%STORAGE_CONFIG);
&nbsp;&nbsp;&nbsp;&nbsp;return $instance;
}

This package always returns the same instance, so it can only be reconfigured before get function is used. This was okay, since Frosty did not expect his colleagues to be crazy enough to modify the storage location dynamically.

Next, he wrote a small Mojolicious application which implemented the LetterStore service. It contained two actions - /letters/count to fetch the total number of letters, and /letters to fetch them. To avoid returning too many letters at once, he decided that they will be returned in pages, 5 at a time. The action to return them returns cursor, which may return an index of the next letter to fetch if there are more letters. This value can be appended into the action URL to fetch the next page:

#!/usr/bin/env perl

use v5.42;
use Mojolicious::Lite;
use List::Util qw(min);
use LetterStore;

use constant RESPONSE_SIZE =&gt; 5;

# get the storage and fetch the list of files. This assumes that new files
# will not be added at runtime, but it can be refreshed periodically if needed
my $store      = LetterStore-&gt;get;
my $store_list = $store-&gt;list;

get '/letters/count' =&gt; sub ($c) {
&nbsp;&nbsp;&nbsp;&nbsp;return $c-&gt;render( json =&gt; { count =&gt; scalar $store_list-&gt;@* } );
};

get '/letters/:cursor' =&gt; { cursor =&gt; 0 } =&gt; sub ($c) {

    # cursor will be an index of next letter to fetch - must be a positive integer
    my $cursor = $c-&gt;stash('cursor');
&nbsp;&nbsp;&nbsp;&nbsp;return $c-&gt;render( json =&gt; { error =&gt; 'bad cursor' }, status =&gt; 422 )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if $cursor =~ /\D/;

    # fetch a list of filenames
    my $next_cursor = $cursor + RESPONSE_SIZE;
&nbsp;&nbsp;&nbsp;&nbsp;my @files
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= $store_list-&gt;@[ $cursor .. min( $next_cursor - 1, $store_list-&gt;$#* ) ];

&nbsp;&nbsp;&nbsp;&nbsp;my @response_data;
&nbsp;&nbsp;&nbsp;&nbsp;foreach my $filename (@files) {

        # extract child name and conduct from path
        my ( $conduct, $child_name ) = $filename =~ m{ ([^/]+) / ([^/]+) $}x;

        # fetch file content
        my $fh = $store-&gt;retrieve($filename);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $file_content = join '', $fh-&gt;getlines;

        # add data to response
        push @response_data, {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;conduct =&gt; $conduct,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;child   =&gt; $child_name,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;letter  =&gt; $file_content,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;};
&nbsp;&nbsp;&nbsp;&nbsp;}

    # no cursor if we don't have any more data
    $next_cursor = undef if $next_cursor &gt; $store_list-&gt;$#*;

&nbsp;&nbsp;&nbsp;&nbsp;$c-&gt;render(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;json =&gt; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;data   =&gt; \@response_data,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cursor =&gt; $next_cursor,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;);
};

app-&gt;start;

That wasn't too hard and worked. Or did it? Errors at this stage would be unacceptable, as they could cause Christmas Inc. to lose credibility and crash its stock price. He had to test it, but how can he do it most efficiently? Use a temporary directory?

As it turned out, there's a better way. Thanks to Storage::Abstract being so abstract, you can set your test script to use Memory driver, which keeps everything inside Perl's memory, yet still acts the same as any other driver! This method is faster, requires no extra modules to be imported and no cleanup after the test:

use v5.42;
use Test2::V0;
use Test::Mojo;
use LetterStore;
use Mojo::File qw(curfile);

# point our storage to Memory. Needs to be done early,
# before the script is loaded
%LetterStore::STORAGE_CONFIG = (
&nbsp;&nbsp;&nbsp;&nbsp;driver =&gt; 'Memory',
);

# fill the storage with sample letters
my %wishlist = get_letters();
my $storage  = LetterStore-&gt;get;

foreach my ( $conduct, $names ) (%wishlist) {
&nbsp;&nbsp;&nbsp;&nbsp;foreach my ( $name, $letter ) ( $names-&gt;%* ) {

        # scalar reference marks content, unlike plain string which marks a
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# local filename
        $storage-&gt;store( &quot;/$conduct/$name&quot;, \$letter );
&nbsp;&nbsp;&nbsp;&nbsp;}
}

# load LetterStore service
my $script = curfile-&gt;sibling('letter_store.pl');
my $t      = Test::Mojo-&gt;new($script);

##################
#    TEST IT!    #
##################

subtest 'should have the right number of letters' =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;$t-&gt;get_ok('/letters/count')
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&gt;status_is(200)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&gt;json_is( '/count', 6, 'count ok' );
};

subtest 'should get first set of letters' =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;test_letters( undef, 5, 5 );
};

subtest 'should get second set of letters' =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;test_letters( 5, 1, undef );
};

done_testing;

sub test_letters( $cursor, $expected_data_count, $expected_next_cursor ) {
&nbsp;&nbsp;&nbsp;&nbsp;$t-&gt;get_ok( '/letters' . ( $cursor ? &quot;/$cursor&quot; : '' ) )
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&gt;status_is(200)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&gt;json_has('/cursor')
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-&gt;json_has('/data');

&nbsp;&nbsp;&nbsp;&nbsp;my $response = $t-&gt;tx-&gt;res-&gt;json;
&nbsp;&nbsp;&nbsp;&nbsp;is scalar $response-&gt;{data}-&gt;@*, $expected_data_count,  'data count ok';
&nbsp;&nbsp;&nbsp;&nbsp;is $response-&gt;{cursor},          $expected_next_cursor, 'cursor ok';

&nbsp;&nbsp;&nbsp;&nbsp;foreach my $letter_data ( $response-&gt;{data}-&gt;@* ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $conduct = $letter_data-&gt;{conduct};
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $name    = $letter_data-&gt;{child};

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;is $conduct, in_set( keys %wishlist ), 'conduct ok';
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;is $wishlist{$conduct}{$name}, $letter_data-&gt;{letter},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'letter content ok';
&nbsp;&nbsp;&nbsp;&nbsp;}
}

sub get_letters {
&nbsp;&nbsp;&nbsp;&nbsp;return (
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;nice =&gt; {

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Timmy =&gt; &lt;&lt;~LETTER,
            Dear Santa,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I've been really good this year! I'd love some toys for Christmas -
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maybe some action figures and a cool board game.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thank you for bringing presents to all the kids!
            LETTER

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Susie =&gt; &lt;&lt;~LETTER,
            Dear Santa,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I've been good all year and I'm so excited for Christmas! Please bring
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;me a unicorn toy, some colored markers, and a dollhouse.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thank you for making Christmas magical!
            LETTER

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Lisa =&gt; &lt;&lt;~LETTER,
            Dear Santa,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hi! I hope your reindeer are doing good. This year I was nice mostly.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;For Christmas I want:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- A bicycle
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- A puppy
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- A Nintendo Switch
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- A skateboard
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- A guitar
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- A trampoline
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Can you bring all of them? Please?
            LETTER

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;naughty =&gt; {

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sammy =&gt; &lt;&lt;~LETTER,
            Dear Santa,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This year I've tried hard to be good. I hope you'll visit me on
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Christmas Eve! I really want a skateboard and some art supplies - oh,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and maybe a video game too.
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;You're the best!
            LETTER

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Maggie =&gt; &lt;&lt;~LETTER,
            Dear Santa,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I know I haven't been perfect this year - I've talked back and gotten
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;into trouble a few times. Would you bring me a roller skate and a
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;gaming headset for Christmas? I promise to be better next year!
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I hope you'll still visit me!
            LETTER

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stevie =&gt; &lt;&lt;~LETTER,
            Hey Santa,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I want a drone, a remote control car, and the new gaming console. I
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;better get them or I'm telling everyone you're not real.
            LETTER
        },
&nbsp;&nbsp;&nbsp;&nbsp;);
}

Test script had proven that the service worked as expected. Moreover, Storage::Abstract had more cool tools at its disposal that could prove useful later, like a Composite meta-driver which lets you use more than one driver at once. All it lacks is an ecosystem of drivers, but everyone has to start somewhere, right?

Frosty shared his thoughts and experiences with the author of the module, so that he can make a more informed decision about releasing the stable version. Thanks to the elf's work, every child should get their present this year!

ToyCo want to push new toy updates

2025-12-06T00:00:00Z

ToyCo are not happy...

Sophie cleared her throat, waited for Ernest, Santa's right-hand elf, to look up from his screen. "Boss. We have a problem."

"Oh?" He sighed. "What now?"

She gestured at the tablet she was holding. "You know that script we had that fetched new arrivals from their API? Well... it seems Santa wants those updates the instant they appear, so every department is running that script once a minute, and it's crippling ToyCo's servers." A pause. "Um, also we get duplicates because there are multiple copies of it running."

Ernest managed a slight frazzled grin. "You know how to fix that, at least."

She nodded. "Yes, but ToyCo also said they could push us a feed, if we set up a web server to accept it. How do we do that?"

Mojolicious::Lite

He chuckled for real this time. "Oh? that all? Easy. Watch and learn, young elf." With a few keystrokes, he opened an edit window on a new file called toyco_app.pl.

#!/usr/bin/env perl

use Mojolicious::Lite;

Sophie perked up. "What's that?"

"That? It's a very simple module that allows us to run up a web server. Here..."

post &quot;/feeds/toyco&quot; =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;my $c = shift;
};

"It comes," he explained, "With a bunch of little helper subs that basically make up a tiny Domain Specific Language that will allow us to define stuff. So post says we want to accept a POST request at that URL, and then the $c argument contains the data we'll need to handle."

Sophie hmmed. "And we just tell them the URL? How...?"

He smirked. "I'll get to that. First up, let's parse the data. I'm assuming it's coming in the request body in the same JSON format as the last time?"

A nod. "Yes, but one item at a time, rather than a list."

Ok. That's easy. Back to our POST handler. $c->req is basically our incoming request, and Mojo has a really fast JSON parser built in that will give us the request body as a perl data structure...

post &quot;/feeds/toyco&quot; =&gt; sub {
&nbsp;&nbsp;&nbsp;&nbsp;my $c = shift;
&nbsp;&nbsp;&nbsp;&nbsp;my $item = $c-&gt;req-&gt;json;

&nbsp;&nbsp;&nbsp;&nbsp;add_to_db(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;supplier =&gt; &quot;ToyCo&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SKU      =&gt; $item-&gt;{sku},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name     =&gt; $item-&gt;{name},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cost     =&gt; $item-&gt;{wholesale_price},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RRP      =&gt; $item-&gt;{rrp},
&nbsp;&nbsp;&nbsp;&nbsp;);
};

"Did they say if they expected any JSON back?"

Another glance at her tablet. "Just an optional message field with some arbitrary text."

Ernest hrmed. "Ok. Seems a bit pointless, but we could just do this before the end of the subroutine..."

$c-&gt;render( json =&gt; { message =&gt; &quot;Accepted&quot; }, status =&gt; 200 );

"...and there you go." He paused, laughed. "Whoops. Helps to start the app. So we stick this line at the end of the script proper..."

app-&gt;start;

Running and testing

Sophie hid a smile, then paused and worried at her bottom lip. "That's all very well, but how do we run it?"

Ernest gave her a pleased smile. "Thought you'd never ask. Ok. To test it, there's morbo, which is their development runner..."

morbo ./toyco_app.pl
Server available at http://*:3000

"There. That opens it by default listening on port 3000, so you can now test it by feeding it data via something like HTTPie."

Sophie's eyes widened. "What's that?"

He opened another terminal window. "It's a very handy script for making API requests - don't tell anyone, but it's written in Python. Google for it, and it's pretty easy to install - we have it on all our systems. So much easier than trying to remember all the incredibly cryptic flags for curl. And you can do this... You give it the body parameters as just key/value pairs in this case, and..."

http POST localhost:3000/feeds/toyco Content-Type:application/json \
&nbsp;&nbsp;&nbsp;&nbsp;name=&quot;Santa Hat&quot; rrp=36.50 wholesale_price=20.00 SKU=TC-03451
HTTP/1.1 200 OK
Content-Length: 38
Content-Type: application/json; charset=utf-8
Date: Tue, 02 Dec 2025 11:33:52 GMT
{
&nbsp;&nbsp;&nbsp;&nbsp;&quot;message&quot;: &quot;Accepted&quot;
}

"...and there you go..."

"But that's only development." Sophie frowned. "How do we get it up on production?"

"There's any number of ways. https://docs.mojolicious.org has pointers, but I guess what we'll do is ship it across to prod.northpole.net when it's good and tested..." He gave her a sly grin. "That's your job, by the way... and then'll we'll run it up using the prefork option under something like supervisor to restart it if it ever gets killed for some reason."

./toyco_app.pl prefork -l https://prod.northpole.net:10000

"And there we go." He sighed. "Right. Off you go and tidy that up and test it, and I'll get back to keeping Saint Nick out of Lima's restricted airspace."

"Still?" Sophie giggled.

"Still. Off with you, young elf."

Santa needs to know about new toys...

2025-12-05T00:00:00Z

'Twas a few nights before Christmas...

"Boss?"

Santa sighed, looked up from where he was programming the SledNav in advance of Christmas Day. "Yes?"

The junior elf had their usual pre-Christmas too-many-nights-coding, too-much- pizza, too-much-caffeine, too-little-sleep look. "New script for you to fetch the new toys off the distributor's site. Should save lots of time." They treated him to a frazzled, hopeful smile. "new_toys.pl, in the usual place."

Saint Nick nodded. Waved them away. "Go. Go. Get some sleep."

He knew what to expect, so didn't waste time this time.

"ERNEST!"

The problem

Santa's right-hand elf hurried in. "Yes boss?"

"Your minion's been at it again. See if you can figure out what this is supposed to do?"

Ernest sighed. "If we weren't always in such a pre-Christmas rush..."

Back at his desk, he opened the source code, winced, "Oh dear, oh dear, oh... Ewww...."

Right on cue, Sophie, his right-hand elf, appeared, trying to read over his shoulder. "What... oh... Ewwww... Parsing HTML with regexps? That's gross. What's it for...?"

Ernest hrmed. "They're scraping the distributor's new arrivals page, trying to parse the results and sticking them in our product DB."

She frowned. "Didn't the distributor say they had an API for that?" She pulled out her tablet. "Ah, yes. Here we are. ToyCo sent us a mail just after Black Friday. Forwarding it now."

He gave her a grateful smile. "Thanks. Hopefully, this will be quick - I'm still trying to debug the SledNav code from 2022 - it's mostly brilliant, but apparently last year it managed to send the boss to London via Peru. Something about the wrong Paddington. But - watch and learn..." He scanned the email she'd just forwarded, started typing.

use constant {
&nbsp;&nbsp;&nbsp;API_BASE =&gt; 'https://api.toyco.com/api/v2',
&nbsp;&nbsp;&nbsp;API_KEY  =&gt; 'rk_4F92bA7qLmN82xPT9hQw3D6zKp0RsvJ',
};

"So those are just constants?"

"Yup. At compile time, too. And they're at the top of the file if we need to change them for some reason, like ToyCo moving their endpoint, or expiring our key. And then we can use LWP to do the fetching."

"LWP?" she queried.

"Short for lib-www-perl. For historical reasons. Lost in the midst of time. It does all the heavy lifting of making web requests for us."

use LWP::UserAgent;
use URI;

my $ua  = LWP::UserAgent-&gt;new();
my $uri = URI-&gt;new( API_BASE . &quot;/new_arrivals&quot; );

"That's the right endpoint?" Ernest asked.

She checked her tablet. "Yes. Says here it returns JSON. And there's a link to the docs. But we do need to pass in the API key as an X-API-Key header or a query parameter."

He chuckled. "We'll do the former. It's cleaner. Besides, LWP just lets us set headers as extra hash arguments to the get call."

my $response = $ua-&gt;get(
&nbsp;&nbsp;&nbsp;$uri,
&nbsp;&nbsp;&nbsp;'X-API-Key' =&gt; API_KEY
);

"Better make sure we can parse the result, too."

use JSON;
my $json_parser = JSON-&gt;new-&gt;utf8(0);

She peered. "What's that do?"

"Gives us a JSON parser object, then tells it to expect Perl Unicode strings. It is UTF8, right?"

A glance down at the tablet. "Says so right here." She grinned. "What now?"

Ernest started typing again.

my $data = $json_parser-&gt;decode( $response-&gt;decoded_content );

Sophie scratched her head. "Uh. Woah, hold on. What's the $response?"

"Actually," Ernest explained, "it's an HTTP::Message object. The decoded_content method tells it to return the response body after it's applied any Content-Encoding headers, and specifically in our case it returns Perl Unicode strings, which is what we told JSON to expect."

"Cool. Now what?"

"Now?" Ernest grinned. "Now we have a bunch of new product data in the JSON that we can loop through - what fields did they say were in it?"

Sophie oh'ed. "There's a SKU, an RRP, a wholesale price, a name..."

"Right."

foreach my $item (@$data) {
&nbsp;&nbsp;&nbsp;&nbsp;add_to_db(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;supplier =&gt; &quot;ToyCo&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SKU      =&gt; $item-&gt;{sku},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name     =&gt; $item-&gt;{name},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cost     =&gt; $item-&gt;{wholesale_price},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RRP      =&gt; $item-&gt;{rrp},
&nbsp;&nbsp;&nbsp;&nbsp;);
}

He winked at her. "I'll leave the add_to_db sub as an exercise for the eager student." A grin. "That'd be you. Off you go, I need to get back to not having Himself routed via South America again this year." A pause. "Oh, and for heavens sake add some error handling? You know what the Big Red Boss is like if things fall over with cryptic messages."

Stopping the Evil Grinch: A Holiday Defense Guide

2025-12-04T00:00:00Z

During a December evening in Santa's workshop, the security team received an urgent alert: a malicious actor, known as the "Evil Grinch," intended to compromise the systems running the toy production environment. Fortunately, the team already relied on several essential security tools:

Lynis for system auditing
ClamAV for malware scanning
Perl to orchestrate everything

Installing Lynis Without Sudo

Because the environment restricted sudo usage, Lynis was installed in the user's home directory using the following commands:

wget https://downloads.cisofy.com/lynis/lynis-3.1.6.tar.gz
tar -xvf lynis-3.1.6.tar.gz
mkdir -p /home/user/bin
chmod 775 /home/user/bin

With this wrapper script, Lynis was executable without requiring sudo privileges.

cat &lt;&lt; 'EOF' &gt; /home/user/bin/lynis
#!/bin/bash
LYNIS_DIR=&quot;/home/user/lynis-3.1.6&quot;
export LYNIS_LOG_FILE=&quot;/home/user/lynis-logs/lynis.log&quot;
export LYNIS_REPORT_FILE=&quot;/home/user/lynis-logs/lynis-report.dat&quot;
cd &quot;$LYNIS_DIR&quot; || exit 1
./lynis &quot;$@&quot;
EOF

chmod 775 /home/user/bin/lynis

Installing ClamAV

ClamAV was installed using the system package manager:

sudo apt update
sudo apt install clamav clamav-daemon -y

Building the Perl Cron Script

A Perl script was created to automate security reporting and deliver the results via email.

First, the necessary Perl dependencies were installed:

cpanm Moo \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Email::Sender::Simple \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Email::Sender::Transport::SMTP \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Email::MIME \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Try::Tiny \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Types::Standard \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IO::All \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DateTime \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Readonly \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Log::Log4perl

The script is meant to run daily and exits early if it is not the last day of the month, determined via:

DateTime-&gt;now()-&gt;is_last_day_of_month()

Logging is handled by the Log::Log4perl module. The core of the script is the run_report function, which deletes any previous report file and executes each command. Because ClamAV errors are expected when scanning protected or locked files, the ClamAV call is allowed to return a non-zero exit code.

Below is the Perl script:

#!/usr/bin/env perl

use strict;
use warnings;

use DateTime;
use Cwd;
use Readonly;
use Log::Log4perl qw(:easy);
use Dotenv;

Readonly::Scalar my $lynis_file  =&gt; '/home/user/lynis-report.dat';
Readonly::Scalar my $clamav_file =&gt; '/home/user/clamav.log';

if ( DateTime-&gt;now()-&gt;is_last_day_of_month() ) {

&nbsp;&nbsp;&nbsp;&nbsp;my $logger = Log::Log4perl-&gt;easy_init(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;level =&gt; $DEBUG,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;file  =&gt; &quot;&gt;&gt;test.log&quot;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;&nbsp;$logger-&gt;debug('Last day of month detected. Preparing reports.');

&nbsp;&nbsp;&nbsp;&nbsp;my $env = Dotenv-&gt;load('.mail_env');

&nbsp;&nbsp;&nbsp;&nbsp;$logger-&gt;debug('Running Lynis report');
&nbsp;&nbsp;&nbsp;&nbsp;run_report(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'/home/user/bin/lynis', 'audit', 'system',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'--profile',            '/home/user/custom.prf'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$lynis_file
&nbsp;&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;&nbsp;$logger-&gt;debug('Running ClamAV report');
&nbsp;&nbsp;&nbsp;&nbsp;run_report(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'clamscan', '-r', '-i',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'--exclude-dir=^/proc',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'--exclude-dir=^/sys',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'--exclude-dir=^/dev',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'/home/user',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;--log=$clamav_file&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'-v'
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$clamav_file
&nbsp;&nbsp;&nbsp;&nbsp;);
}

sub _execute_cmd {
&nbsp;&nbsp;&nbsp;&nbsp;my ( $cmd, $file ) = @_;

&nbsp;&nbsp;&nbsp;&nbsp;my $cmd_str = join ' ', @{$cmd};

&nbsp;&nbsp;&nbsp;&nbsp;if ( $file eq '/home/user/clamav.log' ) {

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Accept non-zero exit code for ClamAV
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;system( @{$cmd} );
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;else {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;system( @{$cmd} ) == 0
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or die &quot;Cannot execute $cmd_str: $?&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;return;
}

sub run_report {
&nbsp;&nbsp;&nbsp;&nbsp;my ( $cmd, $file ) = @_;

&nbsp;&nbsp;&nbsp;&nbsp;if ( -f $file ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unlink $file;
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;_execute_cmd( $cmd, $file );
&nbsp;&nbsp;&nbsp;&nbsp;return;
}

To send reports securely, a Gmail App Password was stored in a protected file:

chmod 600 .mail_env

Then the SendMail class was implemented inside lib/SendMail.pm. The class defines the following attributes:

has sasl_username =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has sasl_password =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has from          =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has to            =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; ArrayRef );
has email_body    =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has attachments   =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; ArrayRef );
has subject       =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );

which are used internally to create an Email::MIME object and an Email::Sender::Transport::SMTP object, stored in:

has message   =&gt; ( is =&gt; 'ro', lazy =&gt; 1, isa =&gt; Object, builder =&gt; '_build_message' );
has transport =&gt; ( is =&gt; 'ro', lazy =&gt; 1, isa =&gt; Object, builder =&gt; '_build_transport' );

attributes. Finally, the class implements the send_email method, a simple wrapper over Email::Sender::Simple::sendmail.

The full body of the class is below:

package SendMail;
use Moo;

use Email::Sender::Simple qw(sendmail);
use Email::Sender::Transport::SMTP;
use Email::MIME;
use Try::Tiny;
use Types::Standard qw(Str ArrayRef Object);
use IO::All;

has sasl_username =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has sasl_password =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has from          =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has to            =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; ArrayRef );
has email_body    =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );
has attachments   =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; ArrayRef );
has subject       =&gt; ( is =&gt; 'ro', required =&gt; 1, isa =&gt; Str );

has message =&gt; (
&nbsp;&nbsp;&nbsp;&nbsp;is      =&gt; 'ro',
&nbsp;&nbsp;&nbsp;&nbsp;lazy    =&gt; 1,
&nbsp;&nbsp;&nbsp;&nbsp;isa     =&gt; Object,
&nbsp;&nbsp;&nbsp;&nbsp;builder =&gt; '_build_message'
);
has transport =&gt; (
&nbsp;&nbsp;&nbsp;&nbsp;is      =&gt; 'ro',
&nbsp;&nbsp;&nbsp;&nbsp;lazy    =&gt; 1,
&nbsp;&nbsp;&nbsp;&nbsp;isa     =&gt; Object,
&nbsp;&nbsp;&nbsp;&nbsp;builder =&gt; '_build_transport'
);

sub _build_message {
&nbsp;&nbsp;&nbsp;&nbsp;my $self = shift;

&nbsp;&nbsp;&nbsp;&nbsp;my @file_list;
&nbsp;&nbsp;&nbsp;&nbsp;foreach my $file ( @{ $self-&gt;attachments } ) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my @file_parts = split '/', $file;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my $mime = Email::MIME-&gt;create(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;attributes =&gt; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;filename     =&gt; $file_parts[-1],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;content_type =&gt; &quot;text/plain&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoding     =&gt; &quot;quoted-printable&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name         =&gt; $file_parts[-1],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;body =&gt; io($file)-&gt;binary-&gt;all,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;push @file_list, $mime;
&nbsp;&nbsp;&nbsp;&nbsp;}

&nbsp;&nbsp;&nbsp;&nbsp;my @parts = (
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;@file_list,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Email::MIME-&gt;create(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;attributes =&gt; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;content_type =&gt; &quot;text/plain&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;disposition  =&gt; &quot;attachment&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoding     =&gt; &quot;quoted-printable&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;charset      =&gt; &quot;US-ASCII&quot;,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;body_str =&gt; $self-&gt;email_body,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;),
&nbsp;&nbsp;&nbsp;&nbsp;);

&nbsp;&nbsp;&nbsp;&nbsp;return Email::MIME-&gt;create(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;header_str =&gt; [
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;From    =&gt; $self-&gt;from,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;To      =&gt; join( ',', @{ $self-&gt;to } ),
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Subject =&gt; $self-&gt;subject,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;parts =&gt; \@parts,
&nbsp;&nbsp;&nbsp;&nbsp;);
}

sub _build_transport {
&nbsp;&nbsp;&nbsp;&nbsp;my $self = shift;

&nbsp;&nbsp;&nbsp;&nbsp;return Email::Sender::Transport::SMTP-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;host          =&gt; 'smtp.gmail.com',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;port          =&gt; 465,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ssl           =&gt; 1,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sasl_username =&gt; $self-&gt;sasl_username,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sasl_password =&gt; $self-&gt;sasl_password,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;);
}

sub send_email {
&nbsp;&nbsp;&nbsp;&nbsp;my $self = shift;

&nbsp;&nbsp;&nbsp;&nbsp;try {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sendmail( $self-&gt;message, { transport =&gt; $self-&gt;transport } );
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;catch {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print &quot;|$_|&quot;;
&nbsp;&nbsp;&nbsp;&nbsp;};

&nbsp;&nbsp;&nbsp;&nbsp;return 1;
}

The package was integrated into the main script as follows:

use lib 'lib';
use SendMail;

my $mailer = SendMail-&gt;new(
&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sasl_username =&gt; $env-&gt;{cron_mail},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sasl_password =&gt; $env-&gt;{cron_password},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from          =&gt; $env-&gt;{cron_mail},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to            =&gt; $to,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;email_body    =&gt; 'Security report attached.',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;attachments   =&gt; [ $lynis_file, $clamav_file ],
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;subject       =&gt; 'Security Report',
&nbsp;&nbsp;&nbsp;&nbsp;}
);

Adding to Crontab

The monthly automation was scheduled as follows:

crontab -e
0 10 * * * cd /home/user/scripts &amp;&amp; /home/user/perl5/perlbrew/bin/perlbrew exec --with perl-5.42.0 perl security_report.pl &gt;/dev/null 2&gt;&amp;1

Happy auditing and secure coding!

Santa's Secret Music Studio

2025-12-03T00:00:00Z

Santa's Secret Studio

Privately, Santa was a musician. He practiced his scales and arpeggios diligently any time he could find a spare minute. Although who his teacher is or was remains a mystery.

In Santa's little music studio next to the Workshop, he had some guitars, an old Fender Jazz bass, a modern Arturia MIDI controller keyboard, a few classic synths, and even a bit of modular eurorack gear, too.

Over the years, he has given many, many a present to the likes of Keith Emerson, Rick Wakeman, and Trent Reznor even.

Anyway, he was fine with playing his individual instruments, by themselves, for a long time. He is old fashioned, you know. But he decided to hook his devices together with MIDI ("Musical Instrument Digital Interface") and play them with his superior Arturia (a Christmas present to himself, recently). So he got the necessary cables and connected his synthesizers and computer.

Now with a "digital audio workstation" app ("DAW"), you can orchestrate all your external MIDI instruments and record a masterpiece. But you can also control everything with Perl programs!

North Pole Perlers

Like any programmer worth his or her salt, he and the elves often used the Perl programming language to get things done without much fuss. And since he was also a musician, he wondered how to make musical things easier and fun with code.

It turns out that Santa is a geek at heart and occasionally searches MetaCPAN and checks out the recent uploads. One he found and installed was the idi module. That seemed to fit the bill for many quick and simple things, including playing any synth through MIDI with a controller.

Controlling MIDI

But before he could control anything, he had to know what his MIDI ports were named! In order to find that out, he ran the handy script he found while studying Perl real-time MIDI: list_devices.pl. Here it is:

#!/usr/bin/env perl
use strict;
use warnings;
use MIDI::RtMidi::FFI::Device;
my $midi_in  = RtMidiIn-&gt;new;
my $midi_out = RtMidiOut-&gt;new;
print &quot;Input devices:\n&quot;;
$midi_in-&gt;print_ports;
print &quot;\n&quot;;
print &quot;Output devices:\n&quot;;
$midi_out-&gt;print_ports;

Running this on his computer said,

&gt; perl list_devices.pl

Input devices:
0: USB MIDI Interface
1: KeyLab mkII 49 MIDI

Output devices:
0: USB MIDI Interface
1: KeyLab mkII 49 MIDI

The "USB MIDI Interface" was currently his microKORG synth, and the "KeyLab mkII 49 MIDI" was his Arturia controller. So by using the idi module on the terminal command line:

&gt; perl -Midi -E &quot;i(@ARGV)&quot; &#39;KeyLab mkII 49 MIDI&#39; &#39;USB MIDI Interface&#39;

He was able to control his synth! And what did it sound like?

Not especially Christmas-y at all, but it illustrates that with a single line, you can control a MIDI synthesizer without using a full-blown DAW.

It also implies that you can make a program do ANYTHING YOU WANT with live, real-time MIDI synthesizers. Hmmmmm...

Santa was satisfied and set out to dive deeper after Christmas and study MIDI::RtMidi::FFI::Device and its derivatives: MIDI::RtController, MIDI::RtController::Filter::Tonal, and related control modules next.

Conclusion

Be like Santa and, when you're not busy delivering presents to the children of the world, control your MIDI devices with Perl!

References

All I Want for Christmas Is the Right Aspect Ratio

2025-12-02T00:00:00Z

A bad start to Christmas

Pixie the Elf (whose parents had strange ideas about names) was not having a good December.

This year she’d been seconded from Santa’s Workshop to the North Pole Communications Department. Her job was to prepare a huge batch of festive images: hero banners for the NaughtyOrNice dashboard, thumbnails for the Sleigh Tracking app, preview cards for Elfbook, and even a few social posts for Santa’s surprisingly popular “Reels from the Sleigh”.

All of those systems wanted different aspect ratios.

The NaughtyOrNice dashboard wanted 16:9. The old in-house bulletin board insisted on 4:3. Elfbook square-cropped everything. One particularly opinionated goblin had even insisted on a tall “story” format.

And all Pixie had were a couple of folders of lovely but badly sized photos: Santa in front of the Northern Lights, reindeer in flight, close-ups of toys, and the occasional candid shot of Mrs Claus trying out the new espresso machine.

Every time she tried to resize them, the same thing happened:

Crop the image to fit the rectangle → chop off a reindeer’s antlers.
Add black bars → looks like a dodgy pirate stream.
Stretch to fit → Santa suddenly looked like he’d gained even more weight.

There had to be a better way.

So she did what she always did when stuck: topped up her mug of hot chocolate, opened her laptop, and started scrolling through r/elftech.

About three threads down, a title caught her eye:

“Reformatting images with blurred backgrounds in Perl”

The post was talking about a module called App::BlurFill. It promised to take a source image and produce a new one at a fixed width and height, filling the “spare” space with a blurred version of the same image instead of ugly borders.

“That’s exactly what I need,” Pixie muttered. “No more cropped reindeer noses.”

What App::BlurFill does

At its heart, App::BlurFill is a simple Perl class for generating images with a blurred background fill. You give it:

an input image file
a desired width and height

and it:

Loads the original image using Imager.
Creates a blurred version of that image as the background.
Scales the original image to fit inside the requested rectangle, preserving aspect ratio.
Centres the original image on top of the blurred background.
Writes out a new image file, typically named something like picture_blur.jpg.

By default, it aims at 650×350 pixels, which turned out to be just about perfect for one of Santa’s dashboards.

Even better, the distribution doesn’t just give you a Perl class and leave you to it. It comes with:

A Perl API (the class itself).
A command-line program: blurfill.
A Dancer2 web app so you can do it all in the browser.
A Docker container that bundles the web app so any elf with Docker can run it.

Pixie decided to try all four.

1. Using App::BlurFill from Perl

Pixie’s first target was the NaughtyOrNice dashboard. That app already had a background job that prepared images whenever new photos arrived in the “Workshop Photos” bucket. Dropping a bit of Perl in there was easy.

She installed the module the usual way:

cpanm App::BlurFill

Then, in her image processing script, she added:

use App::BlurFill;

my $blur_fill = App::BlurFill-&gt;new(
&nbsp;&nbsp;file   =&gt; 'images/santa-aurora.jpg',
&nbsp;&nbsp;width  =&gt; 1200,
&nbsp;&nbsp;height =&gt; 630,   # Nice &quot;social card&quot; size
);

my $output = $blur_fill-&gt;process;
print &quot;Blurred image saved to $output\n&quot;;

The constructor accepts:

file – input image (required)
width – output width (defaults to 650)
height – output height (defaults to 350)
output – optional explicit output filename; otherwise a _blur file is generated for you.

The process method does all the work and returns the path to the new file.

She wired that into the job that prepared thumbnails for the dashboard, redeployed, and refreshed the page.

Where she’d previously had:

A letterboxed or cropped Santa…

…she now had:

A perfectly centred Santa in the middle, with a soft, blurred version of the same photo filling the rest of the space. No black bars, no weird stretching.

“Right,” she smiled. “That’s the dashboard sorted.”

2. Letting the command line do the work

The next problem was the content team.

Not every elf is comfortable editing Perl code, but plenty of them are happy running commands in a terminal — especially once Pixie had written “DO NOT PANIC” across the workshop cheat sheet.

Luckily, App::BlurFill ships with a command-line program, blurfill.

The syntax is:

blurfill [-w width] [-h height] [-o output_filename] image_filename

If you omit the options, it uses the defaults:

-w → defaults to 650
-h → defaults to 350
-o → defaults to the input name with _blur appended, e.g. elfies.png → elfies_blur.png

So Pixie wrote a quick note on the internal wiki:

# Standard hero image (1200x630)
blurfill -w 1200 -h 630 aurora-santa.jpg

# Story-style tall image (1080x1920)
blurfill -w 1080 -h 1920 reindeer-selfie.png

Within minutes, the marketing elves were gleefully pushing perfectly formatted images into their social media queues. They didn’t need to know how the magic worked — just that the result looked better than anything they’d done in their old image editor.

3. A point-and-click Dancer2 web app

Of course, there were still a few elves who were allergic to terminals.

“Is there a web page where I can just upload an image?” one of them asked plaintively. “Preferably without any of those scary flags?”

Pixie was ready for this as well.

The distribution includes a Dancer2 web interface, App::BlurFill::Web. There's even a ready-made PSGI app in bin/app.psgi that just does:

use App::BlurFill::Web;

App::BlurFill::Web-&gt;to_app;

Under the hood, that web app offers:

GET / – shows a form where you can upload an image and (optionally) choose width and height.
POST /blur – processes the upload, produces the blurred image, and returns a results page showing the output with a download link.
GET /download/:filename – serves the processed file directly for download.

Width and height default to the same familiar values (650×350) if you don’t specify them.

In a typical development environment, Pixie could run:

plackup bin/app.psgi

Suddenly any elf could:

Visit the page.
Pick sleigh-team-photo.jpg.
Type 1200 and 675 into the width/height fields.
Click “Generate resized image”
Get back a nice preview and a link to the finished image.

4. Putting it in a box: the Docker container

Everything worked beautifully on Pixie’s machine.

But Pixie had been burned before by elves trying to reproduce her setup:

“It works on your laptop, but not in the Reindeer Barn!”

This time, she wanted a packaged solution: no “install Imager”, no “which version of Perl?”, no “do we have the right system libraries?”.

Conveniently, the project provides a pre-built Docker container that runs the web app. The details are in the DOCKER.md file on GitHub, with copy-and-paste commands for pulling and running the image in a single step.

That meant:

The DevOps goblins could run the same container on their Kubernetes cluster.
Workshop elves could run it on their own machines if they liked.
Everyone saw the same web UI, and everyone got the same results.

Pixie just had to share one short internal link to the instructions, and the entire organisation suddenly had a standard way of producing correctly sized images.

Result: Happier reindeer, better images

By Christmas week, the difference was obvious:

The NaughtyOrNice dashboard was full of crisp hero images, all perfectly sized.
The sleigh-tracking mobile app had consistent, professional-looking cards instead of a strange mixture of crops and letterboxing.
Social posts looked like they’d been designed by a real creative studio, not rushed together in an ageing bitmap editor.

Most importantly, the reindeer union stopped complaining about losing antlers, hooves, or tails in badly cropped shots.

On Christmas Eve, Santa stopped by Pixie’s desk.

“I’ve been seeing these lovely blurred-background images all over our systems,” he said. “It makes everything feel much more… professional. What changed?”

Pixie grinned.

“I stopped cropping the photos,” she said. “And I started letting App::BlurFill do the hard work.”

Santa nodded thoughtfully.

“Very good. Put the module on the ‘Nice’ list,” he said. “And while you’re at it, make sure we’ve got a blurred-background version of the sleigh for my new profile picture.”

Your own festive blur-filled images

If you find yourself juggling awkward aspect ratios this December, you can take the same approach as Pixie:

Use the Perl API when you want to integrate into existing scripts or web apps.
Use the blurfill CLI for batch processing from the command line.
Use the Dancer2 web app when you want a friendly upload-and-click interface.
Use the Docker container to give your whole team a standardised, reproducible setup.

And the nice thing is: it isn’t just for Christmas dashboards. The same blurred-background trick works beautifully for:

Website hero images
Social media cards
Video thumbnails

Anything where you need a fixed aspect ratio but don’t want to lose the important bits of your image

Just like Pixie, you might find that a little bit of Perl and a tasteful blur are all you need to make your images look more magical.

The Ghost of Perl Developer Surveys Past, Present, and Future

2025-12-01T00:00:00Z

It was a quiet December evening when a weary Perl developer—curled up with a warm mug of cocoa—received an unexpected visitor. The logs rustled. The LEDs flickered. And from the shimmering depths of CPAN emerged a familiar yet mysterious figure: The Ghost of Perl Surveys Past.

"Come," said the Ghost. "It is time to see what the community has been building, breaking, and dreaming over the years."

And so began our spectral journey through the Perl Developer Survey, culminating in the 2025 edition—our newest glimpse into the life of the language and the tools that help keep it alive.

The Ghost of Surveys Past

The Ghost whisked our developer back to the origins of Perl community surveying, when the questions were simpler, the spreadsheets smaller, and the editors... surprisingly similar.

The early surveys of 2009–2010 didn't try to capture the entire ecosystem; they focused on the fundamentals of how Perl developers worked, what shaped their decisions, and what tools they trusted.

The Ghost unfurled four parchment scrolls from those early years.

October 2009 — Which editor(s) or IDE(s) are you using for Perl development?

Vim and Emacs reigned like ancient kings, their terminal thrones rarely contested. Padre was young and promising. Komodo IDE had loyal supporters. Notepad++ and TextMate rounded out the tribe of early Perl scribes.

Modern Perl tooling builds on this foundation, but the Ghost smiled knowingly: Vim and Emacs are still with us. Some ghosts never leave.

November 2009 — What other technologies, languages, templating systems are you using besides Perl?

Early surveys discovered that Perl developers were well versed in the web ecosystem, often using JavaScript, HTML, CSS, SQL, and XML alongside Perl.

This was a hint that Perl developers were not isolated in their own world, but active participants in the broader web development community.

April 2010 — What is the primary operating system you use for developing Perl applications?

Linux dominated. macOS was rising among laptop-toting developers. Windows was present but rarely central.

The picture painted was unmistakable:

Perl grew up in UNIX-like environments—and thrives there still.

May 2010 — What are the most important features of an employer or a job opportunity for you?

Even in 2010, developers asked for:

good compensation
interesting technical challenges
stability
respect for work-life balance
opportunities to use modern Perl practices and tools
respect for Perl as a language

"These questions were seeds," the Ghost said. "From them grew the surveys we know today."

The Ghost of Survey Present (2025)

The Ghost shimmered and shifted, becoming a modern figure surrounded by bar charts, editor icons, CI pipelines, and version numbers. It held up a scroll containing the freshly gathered results of the 2025 Perl Developer Survey.

"What do Perl developers look like today?" the Ghost asked.

The 2025 survey revealed a vibrant, diverse conglomeration of developers, using a variety of tools. The ghost's scroll contained an iframe embedding the full results:

https://survey.perlide.org/results/2025

Some highlights included:

Editors and IDEs: Vim led the pack, with Visual Studio Code taking a large share, and Emacs trailing behind.
Other Tools: Perl::Tidy was used by the majority of respondents.
Language Version: Perl 5.40 was the most commonly used version, with a significant number also using Perl 5.42 and 5.38.
CPAN Client: cpanm was the dominant CPAN client, with cpan and other clients also in use.

The Ghost of Surveys Yet to Come

A silent figure emerged—hooded and watchful: The Ghost of Surveys Yet to Come, revealing only outlines and possibilities.

The ghost spoke in riddles:

"What if we could peer into the future of Perl development? What trends might we see? What tools might emerge? What challenges might we face?"

He unfurled an infernal scroll with speculative questions for future surveys:

Containerization: How extensively are Perl applications being containerized?
Cloud Usage: What cloud platforms are most popular among Perl developers?
CI/CD Adoption: How widely have continuous integration and continuous deployment practices been adopted in Perl projects?
AI Integration: To what extent are Perl developers utilizing AI tools in their development workflows?
Modern Frameworks: Which modern web frameworks are gaining traction in the Perl community?
Performance Optimization: What strategies are Perl developers using to optimize application performance in modern environments?
Security Practices: How are Perl developers addressing security concerns in their applications?
Community Involvement: How engaged are Perl developers with the broader open-source community?

The ghost began to fade...

"These questions are the seeds of future surveys," the Ghost whispered. "From them will grow the next chapters in our shared story."

The Gift of Insight

As dawn approached, our developer realized the purpose of the journey:

The Perl Developer Survey isn't merely data; it's a chronicle of how we work, what we value, and where we're going.

From the early questions of 2009 and 2010… to the detailed metrics of 2025… to the futures waiting in tomorrow's shadows…

the survey has emerged again to inform and inspire.

So this year, may your December be filled with green test suites, stable builds, and cheerful hacking.

See the full 2025 Perl Developer Survey results at https://survey.perlide.org/results/2025. Be sure to participate in future surveys to help influence the future of Perl tooling development!

Merry Christmas, and happy Perl programming to all!

Perl Advent Calendar 2025

Pecan&#39;s Tale: Migrating a terminal application from Term::ReadLine to Tickit

Step 1: Create widget hierarchy

Step 2: Redirect file handles

Our intrepid elf-hero and his mentor

The program and its command line (includes shameless elf promotion)

Grammar

No direction HOME

That&#39;s the Tickit

A Quick Response

The next day

Techie Tania whirls into action

Bit vectors save space on Santa&#39;s list

The Gift of Readability

Night Shift at PDN Headquarters

The Invisible Barrier

How Humans Actually Read

The Table Principle

The Version Control Revolution

Trailing Commas: The Unsung Heroes

The Lexical Consistency Principle

The Gift of Readability Manifesto

1. Use snake_case Everywhere

2. Indent with Tabs

3. Never Align on Lines with Different Indentation

4. Use Paired Characters as Quoted Operator Delimiters

5. Space Around Operators and Keywords

6. One Line, One Concept

Epilogue

P.S.

How SUSE is Using Perl

Advent of the Underbar

Advent of the Underbar

A tangent: my pandemic projects

&#x1F5F9; Le b&acirc;ton de joie

&#x1F5F7; Programming Sentimental Advice Column

&#x2610; The book that did not exist

Why create another podcast?

JFDI in action

Podcasting as data collection

How long will this last?

The first year

Help needed

Safer last-minute hotfixes before Christmas

The Elves Learn to be Lazy

The Naughty or Nice Subsystem

A New Algorithm

The Reindeer&#39;s Cousins

Laziness

Conclusion

Auto-instrument your code with OpenTelemetry

Auto-auto-instrumentation

Looking under the hood

Here a use, there a use, everywhere a yule use

The instrumentation is coming from inside the package

Wrapping up

Using Mojolicious::Plugin::Mount to help test your applications

Introduction

Test Scenario

How Mojolicious::Plugin::Mount can help

Testing with mocked applications

Conclusion

The Twelve Slices Of Christmas: How Vasco Chained the Chaos

The Missing Piece

The Crisis

Finding the Critical Chain

The Resource Reality

What Happens When a Day Isn&#39;t a Day

Week 1: Testing the Theory

Week 2: When Theory Meets Reality

Week 3: The Buffer Saves Christmas

Week 4: The Finish

What Critical Chain Added to No Estimates

For Your Workshop

Epilogue

Thirty Slices, Twenty-Four Days: How Christmas Was Saved By Abandoning Estimation

The Crisis That Estimation Built

The No Estimates Gambit

Week 1: Finding the Rhythm

Week 2: The Acceleration

Pecan's Tale: Migrating a terminal application from Term::ReadLine to Tickit

That's the Tickit

Bit vectors save space on Santa's list

🗹 Le bâton de joie

🗷 Programming Sentimental Advice Column

☐ The book that did not exist

The Reindeer's Cousins

How `Mojolicious::Plugin::Mount` can help

What Happens When a Day Isn't a Day

"You shouldn't do art"

'Twas a few nights before Christmas...

Santa's Secret Music Studio

Santa's Secret Studio

October 2009 — Which editor(s) or IDE(s) are you using for Perl development?

November 2009 — What other technologies, languages, templating systems are you using besides Perl?

April 2010 — What is the primary operating system you use for developing Perl applications?

May 2010 — What are the most important features of an employer or a job opportunity for you?