I think I’ve just done the latter.

Back in February 2021, Gabor Szabo wrote an article called Perl modules with their own web sites. He pointed out that a number of the larger Perl projects had websites of their own, in addition to their pages on MetaCPAN, and wondered whether this was something that more CPAN modules could benefit from.

I liked the idea. In fact, I liked it enough that later the same day I wrote Simple CPAN module web sites with GitHub Pages.

My argument was basically that GitHub Pages made this almost embarrassingly easy. If your CPAN distribution was already on GitHub, then you already had almost everything you needed. Turn on GitHub Pages, put some content in the repository, and a few minutes later your module could have a website.

At the time I wrote:

I think that anything which increases the amount of up-to-date Perl content on the web is a good idea.

Five years later, I still think that’s true.

Attempt one: automate everything

Of course, being a programmer, I immediately decided that something which took less than five minutes clearly needed automating.

A few months later I released App::CPANModuleSite, which attempted to generate a useful website for a CPAN distribution. I wrote about it in Easier web sites for CPAN modules.

It worked.

Nobody used it.

That’s fine. Not every experiment needs to become an indispensable part of the Perl ecosystem. App::CPANModuleSite is one of those projects that seemed like a good idea at the time but didn’t really go anywhere.

But the underlying idea never quite went away.

Meanwhile, the modules moved house

A couple of years later I made another, apparently unrelated, change.

For years, the Git repositories for my CPAN distributions had lived alongside everything else in my personal GitHub account. In 2023 I decided that wasn’t particularly useful, so I created a GitHub organisation called davorg-cpan and started moving my CPAN repositories there.

I wrote about the reasons for doing that in GitHub Organisations.

It separated my CPAN work from all the other random things in my GitHub account and gave the distributions a useful identity of their own.

And, importantly for what happened later, GitHub organisations get GitHub Pages sites just like users do.

So I created one.

Eventually I gave the organisation site a custom domain: it lives at cpan.perlhacks.com

I didn’t do very much with it. It existed. It listed some modules. That was about it.

But one useful piece of infrastructure was now in place.

Your README is already a website

Earlier this year I returned to another idea I’d been playing with: for many small software projects, the README already contains almost everything you would want on a simple project website.

So why maintain both?

I wrote a GitHub Action called readme-to-index. I described the idea in Your README is Already a Website.

It takes a repository’s README, runs it through Pandoc, adds Simple.css and publishes the result as a very simple single-page website using GitHub Pages.

There’s deliberately not much to it. No Jekyll configuration. No theme to maintain. No second copy of the documentation. The README remains the source of truth. Push a change to the README and the website changes with it.

I’ve now used it on several of my CPAN distributions, including App::HTTPThis, MooX::Role::SEOTags and WebServer::DirIndex.

And that’s when I noticed something rather pleasing.

The bit I hadn’t planned

A GitHub organisation Pages site normally lives at:

https://organisation.github.io/

A project site within that organisation lives underneath it:

https://organisation.github.io/project/

But GitHub Pages also lets the organisation site have a custom domain.

Mine is:

https://cpan.perlhacks.com/

And the individual project sites don’t have their own CNAME files. That means they simply inherit the organisation site’s domain. So the module sites automatically appear at addresses like:

https://cpan.perlhacks.com/app-httpthis/

https://cpan.perlhacks.com/moox-role-seotags/

https://cpan.perlhacks.com/webserver-dirindex/

No additional DNS configuration. No new domains. No CNAME management for individual projects. Move a CPAN distribution into the organisation, add the readme-to-index workflow, enable GitHub Pages, and it becomes another part of the same family of sites.

And suddenly I realised I’d accidentally built almost exactly the thing I was looking for in 2021.

A CPAN neighbourhood

MetaCPAN remains the canonical place to find information about my distributions. I’m certainly not trying to replace it.

But MetaCPAN has to present every distribution in approximately the same way. That’s one of its strengths.

A project’s own site serves a slightly different purpose. It’s somewhere I can send someone who just wants to know what this thing is and how to use it. It can emphasise examples and introductions rather than package metadata. And, perhaps most importantly, it gives the project a URL that looks like it belongs to the project rather than to a hosting service.

What I particularly like about the current arrangement is that the individual sites also clearly belong together.

They’re not a collection of unrelated domains. They’re a little CPAN neighbourhood: cpan.perlhacks.com with each distribution living underneath it.

The organisation provides the namespace and domain. GitHub provides the hosting and deployment infrastructure. readme-to-index turns documentation I’m already maintaining into the website.

There’s very little left to maintain.

Five years of accidental architecture

None of this was planned.

In 2021, I experimented with GitHub Pages because Gabor suggested that more CPAN modules should have websites.

Then I wrote a tool to automate that and discovered that nobody particularly wanted it.

In 2023, for largely unrelated reasons, I moved my CPAN repositories into a GitHub organisation.

Then I created an organisation Pages site.

Then I attached a custom domain to it.

Then, earlier this year, I wrote a GitHub Action for turning READMEs into tiny project websites.

Each decision made sense on its own.

Put them together and I now have a system where adding a website to one of my CPAN distributions is almost trivial, and every new site automatically becomes part of a consistent collection under cpan.perlhacks.com.

Sometimes architecture comes from diagrams, planning meetings and carefully written requirements. And sometimes you look back at five years of tinkering and discover that you’ve accidentally built something useful.

So over the next few weeks I’m going to start adding readme-to-index to more of the distributions in the davorg-cpan organisation and putting a bit more effort into the organisation site itself.

But perhaps you could do the same thing.

I bet your CPAN distribution already has a README. It might even be written in Markdown. If so, why not spend fifteen minutes turning it into a website?

You don’t need to design anything. You don’t need to maintain another copy of your documentation. And you don’t even need to pay for hosting.

Your README is already a website.

You just need to publish it.

The post Accidentally Building a CPAN Web Platform first appeared on Perl Hacks.

“The future is already here — it’s just not evenly distributed.”
— William Gibson

I was reminded of that quote this week when I received a support request for a Perl CGI script I helped write about twenty-five years ago.

If you’re a software developer, your immediate reaction is probably the same as mine was.

“A Perl CGI script? In 2026?”

But the more I thought about it, the more I realised that my surprise said more about me than it did about the person who sent the email.

We assume everyone lives where we do

If you spend your days reading Hacker News, watching conference talks and experimenting with AI coding tools, it’s easy to believe that everyone is building applications in containers, deploying them to cloud platforms and arguing about which JavaScript framework will replace the current JavaScript framework.

That’s our world. It isn’t everyone else’s.

One of the hardest lessons for any software engineer is accepting that we are not our users.

We spend our time talking to other software engineers, reading software engineering blogs and attending software engineering conferences. It’s easy to conclude that the whole world is moving at the same pace.

It isn’t.

Most businesses don’t think in terms of technology at all. They think in terms of problems. The website is there to answer customers’ questions when the office is closed. If it does that reliably, they’re happy.

Most businesses don’t employ software engineers. They employ accountants, manufacturers, retailers, charities, estate agents and consultants. Their website isn’t their product. It’s simply another business expense, somewhere between the telephone system and the office printer.

They’re not interested in Kubernetes. They don’t care whether their site is hosted on Cloud Run or a Raspberry Pi in someone’s garage. They certainly aren’t waking up each morning wondering whether they should migrate to the latest web framework.

They just want the website to keep doing what it’s done for years.

A support request from another era

The email came from the CEO of a small European company.

Their contact form had suddenly stopped working and, after a little digging, they’d discovered that the software processing it was NMS FormMail, part of the NMS project that I helped run around the turn of the millennium. They wanted to know whether I could help.

The diagnosis took about two minutes.

When the form was submitted, the browser displayed the Perl source code instead of executing it. That meant the program wasn’t failing. It wasn’t even running. The web server was simply serving the CGI script as a text file.

I suggested that the hosting company had almost certainly migrated them to a new server where Perl CGI was no longer enabled.

A few hours later they replied.

That was exactly what had happened.

The software wasn’t the problem

There’s an important lesson here.

Nothing in the software had broken.

The contact form had apparently been working happily for years. The Perl compiler hadn’t suddenly forgotten how to execute CGI programs. NMS hadn’t developed a bug after twenty-five years.

The thing that had changed was the hosting environment.

Twenty years ago, almost every budget Linux web host proudly advertised support for Perl CGI. Today, very few do. There simply isn’t enough demand to justify it. The overwhelming majority of customers want WordPress, PHP or a managed website builder, and hosting companies naturally invest in the technologies that almost all of their customers actually use.

Supporting Perl CGI today means maintaining packages that very few customers need, testing an increasingly niche platform and employing engineers with knowledge that has become correspondingly rare. That’s difficult to justify when you’re selling hosting for a few pounds a month.

The platform quietly disappeared.

Legacy software isn’t necessarily bad software

Software developers often talk about “legacy software” as though it’s automatically a problem.

Sometimes it is. But very often, legacy software is simply software that solved a problem so well nobody felt the need to replace it.

Think about the economics.

Suppose you’d phoned this company every year for the last twenty years and offered to modernise their website for £2,000.

Why would they have said yes? The website worked. The contact form worked. Customers could get in touch. There were no new features they needed.

From the business’s perspective, spending thousands of pounds to replace something that wasn’t causing a problem would have been irrational.

From my perspective, the website looked like a museum exhibit. From theirs, it looked like a website.

That’s the difference between software engineers and users. We see technology. They see outcomes.

That’s why we’re often so bad at predicting what people will actually adopt. We assume they’ll make technical decisions for technical reasons. In reality, most businesses make technology decisions for economic reasons.

Good engineering has a context

One part of the story particularly amused me.

The customer mentioned that they’d actually migrated to NMS in 2023.

Think about that for a moment.

NMS was created around 2000 as a modern replacement for Matt’s Script Archive. More than twenty years later, somebody was still upgrading to it.

That tells us something about the extraordinary lifespan of web software.

It also reminded me that engineering decisions only make sense in the context of their time.

One of the improvements NMS made over Matt’s original scripts was to use CGI.pm wherever possible. Back then, that was exactly what experienced Perl programmers recommended. CGI.pm was part of the standard Perl distribution, thoroughly tested and far preferable to everyone writing their own CGI parameter parser.

Today, CGI.pm isn’t installed by default with Perl. It still exists, but as a separate package. Ironically, if you somehow found a web host that still supported Perl CGI, there’s a reasonable chance that Matt’s original scripts would run immediately while NMS would first complain that CGI.pm wasn’t installed.

That doesn’t mean we made the wrong decision. It means the world changed.

The future really is here

William Gibson’s quote is often used when talking about AI, robotics or autonomous vehicles.

I think it’s even more applicable to enterprise software.

The future is here.

It’s just that it exists alongside Visual Basic applications, Microsoft Access databases, COBOL systems, Classic ASP websites and, until last week, a Perl CGI script quietly sitting in a cgi-bin directory somewhere in Europe.

Those systems aren’t still around because people love them.

They’re still around because they continue to solve the problem they were built to solve.

Software engineers tend to imagine technology replacing technology. Businesses replace technology only when the old technology stops delivering value or the ecosystem around it moves on.

That’s exactly what happened here. The Perl program didn’t fail. The web simply stopped expecting it to exist.

Looking back

Looking back, the email was a useful reminder.

Software engineers spend our careers chasing the future. We get excited by new languages, new frameworks and new deployment models. That’s part of the job.

But most of the world isn’t chasing the future.

Most of the world simply wants yesterday’s software to carry on working tomorrow.

That’s why William Gibson’s observation resonates so strongly. The future really is here. It’s just concentrated in places like conference talks, GitHub repositories and startup incubators.

Elsewhere, quietly and without anyone really noticing, there are still Perl CGI scripts processing contact forms, COBOL programs paying pensions and Microsoft Access databases running small businesses.

They aren’t there because people are afraid of change.

They’re there because, until something around them changes, they continue to solve the problem.

As software engineers, it’s worth remembering that we are not our users. The technologies we’re excited about today won’t become mainstream simply because they’re better. They’ll become mainstream when replacing yesterday’s solution makes economic sense.

Previously

As I previewed this post, I saw that the “related articles” section had found the 2024 article “The Present Isn’t Evenly Distributed Either.” I think my opinions on this have become more nuanced. Previously, I wrote “The present isn’t evenly distributed”, and now I’m adding, “…because the economics aren’t evenly distributed either”.

The post The Future Isn’t Evenly Distributed first appeared on Perl Hacks.

This week, it was Mohammad using WebAssembly to run Perl in his browser. Which led to me thinking about PerlScript.

If you’re a certain age, and you spent any time developing web applications on Windows in the late 1990s, you’ll probably remember it. If you’re younger than that, you’re quite likely to think I’m making it up.

Because, for a brief period, Internet Explorer could run Perl inside <script> tags.

Not JavaScript.

Perl.

It sounds absurd now.

It wasn’t absurd then.

The browser wars were weird

It’s difficult to explain to younger developers just how chaotic the web was in the late 1990s.

Today, if you’re building a web application, you write HTML, CSS and JavaScript. Every browser understands them. If you invent your own alternatives, you’re going to have a very lonely website.

None of that had been settled in 1998.

Microsoft and Netscape were engaged in what became known as the Browser Wars. Every release was packed with new features that only worked in one browser. Sometimes the other side copied them. Sometimes they ignored them. Either way, developers were left trying to support both.

We got Java applets. ActiveX controls. VBScript. Browser-specific CSS. Browser-specific DOM APIs. <marquee>. <blink>. Layers. Filters. Behaviours.

And, almost forgotten today, the ability to write client-side Perl.

Seen in that context, PerlScript wasn’t especially strange.

It was just another way for Microsoft to say, “Look how much more capable Internet Explorer is.”

Active Scripting

The clever part was that Internet Explorer wasn’t actually designed to execute JavaScript.

It was designed to host scripting engines.

JavaScript (or, more accurately, Microsoft’s implementation called JScript) was simply one of the engines that happened to ship with the browser. VBScript was another.

If you installed additional scripting engines, Internet Explorer would happily use those too.

One of those engines came from ActiveState.

It was called PerlScript.

That meant you could write something like this:

<script language="PerlScript">
  $window->document->write("<h1>Hello, world!</h1>");
</script>

Load the page in Internet Explorer on a machine with ActivePerl installed and it would execute exactly as you’d expect.

The browser itself didn’t understand Perl.

It simply handed the script to the installed PerlScript engine.

Looking back, it’s actually a pretty elegant architecture.

ActiveState’s role

Around this time, ActiveState was doing fantastic work making Perl a first-class citizen on Windows.

For years, Windows had been an awkward platform for Perl developers. ActivePerl largely solved that, becoming the standard distribution for Windows users.

PerlScript was one part of a much bigger picture.

The same scripting engine worked not only inside Internet Explorer, but also with Microsoft’s Active Server Pages (ASP) and Windows Script Host.

Write the engine once and Windows would happily host it wherever scripting was supported.

It was a neat example of software reuse.

Why it never caught on

Of course, there was one rather obvious problem.

For your web page to work, your visitors had to:

• be using Internet Explorer;
• be running Windows; and
• have PerlScript installed.

That isn’t exactly the recipe for a successful public web application.

For internal corporate systems it made a certain amount of sense. On the open web, JavaScript was always going to win.

An alternative web

What I find fascinating is that Microsoft’s approach wasn’t obviously wrong.

Imagine an alternative history where browsers had standardised on the idea of pluggable scripting engines.

Instead of asking whether a browser supported JavaScript, we’d ask whether it had PythonScript, PerlScript or RubyScript installed.

The browser itself would simply dispatch each <script> block to the appropriate interpreter.

In another timeline, perhaps that’s exactly what happened.

Instead, the web converged on a much simpler idea.

Every browser should speak the same language.

That language happened to be JavaScript.

Sanity eventually prevailed

Ironically, the browser wars eventually destroyed themselves.

By 2001 Internet Explorer had effectively won. IE6 reached an extraordinary market share, Netscape faded away and Microsoft slowed browser development to a crawl.

That turned out to be good for nobody.

Firefox arrived in 2004 and reminded Microsoft that browsers were still worth competing over. Chrome followed in 2008 and accelerated the change.

But something important had shifted.

The competition was no longer about inventing proprietary technologies that locked developers into one browser.

Instead, browsers competed on standards compliance, JavaScript performance and developer tools.

There were still plenty of innovations, but they increasingly became standards rather than vendor-specific features.

Frankly, that was a much healthier place for the web to end up.

Forgotten technology

One thing that surprised me while looking into PerlScript again was how little remains on the web.

There are countless articles about Flash, Java applets and Silverlight.

PerlScript barely gets a mention.

Perhaps that’s because hardly anyone used it. Or perhaps it was simply overshadowed by ActiveState’s much more successful server-side work.

Either way, it feels like an important little footnote in the history of the web.

A reminder that the future wasn’t always as inevitable as it now appears.

So no, I hadn’t imagined it.

There really was a time when you could install Perl on a Windows PC, open Internet Explorer and use it to execute Perl in a web page.

Looking back nearly thirty years later, it feels less like a forgotten product and more like a glimpse into an alternative history of the web.

The post Remember PerlScript? When Internet Explorer Could Run Perl first appeared on Perl Hacks.

That interview was done to promote the sixth Perl School book, The Best of Perl Hacks, so by that point I’d already been running an ebook-only publishing imprint for three years and was apparently still very comfortable with that decision.

And I stand by the sentiment. I love ebooks. I can carry my entire library in my pocket. Font size, brightness, instant delivery — what’s not to like? For years I’d been mildly irritated by publishers who promised me an “ebook” and delivered a PDF that was made to be read at a fixed size and fell apart on anything smaller than a large tablet. A proper ebook format reflows. It adapts. It goes where you go.

It seemed obvious, then, that Perl School should be ebook-only. No printing, no warehousing, no minimum print runs, no logistics. We started in 2017 with Perl Taster and have published nine titles since then — everything from a Selenium testing guide to a book on Cucumber to a collection of my best Perl Hacks posts. All ebooks. All on Amazon and/or LeanPub.

It turns out I am not representative of my audience. This is, of course, an important marketing lesson!

This should probably not have come as a surprise. Assuming you are a typical user is the most dangerous thing you can do as a technologist, and I’ve been in this industry long enough to know that. Yet somehow I still managed to assume that Perl developers were like me: screen-first, happiest with an ebook, not missing physical books at all.

The emails asking whether Perl School books were available in print suggested otherwise. And when Mohammad Sajid Anwar finished Design Patterns in Modern Perl, the demand for a physical edition was too consistent to ignore. Mohammad is a prolific Perl contributor (you may know him from his work on the Weekly Challenge or Perl Weekly), and his readers, it turns out, wanted something they could put on a shelf.

Amazon’s Kindle Direct Publishing (KDP) is the system you use to push ebooks into the Amazon machine. But you can also use it to publish paperbacks. And the barrier to entry is genuinely low. You supply a properly-formatted PDF for the interior, a cover image, choose your trim size and paper type, set a price, and wait for a proof copy to arrive in the post. No printing contracts, no warehousing, no minimum print runs. Print-on-demand means each copy is produced when someone orders it. KDP handles fulfilment, returns, and royalty payments. As a publisher, you just need to get the files right.

That said, “low barrier” doesn’t mean “no work.”

Our existing build pipeline already took Markdown source through pandoc to produce both a PDF and an EPUB. The PDF looked good on screen and worked fine for the A4 digital edition we’d been producing. But KDP paperbacks have their own specific requirements: the correct page dimensions for your chosen trim size (we went with 7″×10″, roughly the size of a standard technical textbook), margins that meet their minimum gutter requirements, and bleed on the cover image.

The gutter requirement caught me out. KDP scales its minimum gutter—the margin on the binding edge—with the page count of the book, because thicker books flex more when opened and text can disappear into the spine. For a 294-page book, the minimum gutter is half an inch. That’s more than we’d originally set, so the CSS needed adjusting. KDP’s print-readiness checker caught this when we uploaded the first attempt.

We also discovered that some code lines in the benchmark output sections were overflowing the right margin. In an ebook, this is invisible because text reflows to fit the screen. In print, it is not invisible at all—the text simply runs off the edge of the page. The fix was a small Perl script that identifies those specific lines and wraps them for the print build only, leaving the ebook output completely untouched. The same Markdown source produces both formats; the script runs only when building the KDP PDF.

The cover was its own adventure. The ebook cover image had been designed at 1600×2400 pixels, which works well for an ebook. But KDP’s front cover panel for a 7″×10″ book with bleed requires a different size and aspect ratio entirely. I had to work out the exact pixel dimensions—accounting for the trim size, the 0.125″ bleed allowance on all outer edges, and the spine width (which KDP calculates from the page count and paper type)—and then extend the original background pattern to fill the larger canvas. That’s the kind of fiddly arithmetic that’s easy to get slightly wrong, and I did get it slightly wrong the first time.

I also discovered, while working on the new cover, that the ebook cover had “Perl” duplicated in the title. The intended layout has “Design Patterns in Modern” on the first line, then a large “Perl” wordmark below it—so the full title reads as “Design Patterns in Modern Perl.” But the first line had originally been set to “Design Patterns in Modern Perl,” meaning the cover actually read “Design Patterns in Modern Perl Perl.” This had been the case for six months. The corrected ebook cover is in progress.

For all of this, I had help from Claude Cowork, Anthropic’s desktop AI tool, which I’d been using more and more for exactly this kind of technical publishing work. It helped write the CSS changes for the print layout, worked through the cover dimension calculations with me, rendered specific pages of the generated PDF to check for overflows and margin problems, and spotted the “Perl Perl” duplication that I had entirely failed to notice.

That last one stings a bit. But in fairness, catching subtle errors in things you’ve looked at many times is exactly the kind of task where a second pair of eyes—artificial or otherwise—earns its keep. It’s not the same as having a professional production editor, but for a small independent publisher with no budget for one, it covered a surprising amount of ground.

Design Patterns in Modern Perl is now available as a paperback. The page links to your local Amazon store. It’s priced at £20 (or local equivalent), which produces a per-copy royalty that compares rather favourably with what the traditional publishers were paying me back in the day—though we’ll need to actually sell some copies first before that becomes relevant.

This is an experiment. If the book sells—and I’m deliberately not defining “sells well,” because I don’t want to commit to a number I’ll later have to explain—then more Perl School titles will follow the same route to print. Mohammad has written a genuinely useful book. If you’re working with Perl and want to think more carefully about how you structure your code, it’s worth your time. And if you buy a copy, you’ll be helping to settle the question of whether Perl developers really do want physical books, or whether I was right all along.

I suspect I wasn’t.

The post Perl School Goes Paperback first appeared on Perl Hacks.

This week, thanks to a blog post from Olaf Alders, I discovered that it wasn’t behaving quite the way I thought it was.

Well… not quite. It wasn’t behaving the way I used it.

And that led to three releases in quick succession.

It wasn’t really serving “localhost”

When you started http_this, it printed something like this:

Exporting '.', available at:

    http://localhost:7007/

Like most people, I took that at face value. If a program tells me it’s serving on localhost, I naturally assume it’s only accessible from my own machine.

In reality, that wasn’t always what it was doing.

To be clear, http_this has long had a --host option. If you explicitly supplied a host address, everything behaved exactly as you’d expect—it binds to the named network interface. The surprising behaviour only occurred when --host was omitted—which, as it happens, is exactly how I always used the tool.

In that case, the server actually listened on every network interface (0.0.0.0). On many machines, a firewall would prevent anyone else from connecting, so most users would never notice. But the output was misleading. The software was saying one thing while doing another.

Olaf spotted this, wrote about it in his post Keep it Local, and submitted a pull request.

The first fix

Interestingly, Olaf’s pull request didn’t change the server’s behaviour. It simply made the output truthful.

If the server was listening on every interface, then the startup message should say so, together with a warning that other machines on the local network may be able to connect.

That was a worthwhile improvement in its own right.

But reviewing the change immediately prompted a more important question.

Should this really be the default?

Once the output accurately described the behaviour, I had to ask whether the behaviour itself was actually sensible.

For the vast majority of people, http_this is a quick way to preview a local website, browse some generated documentation, or inspect the output from a static site generator.

None of those use cases requires the server to be visible to every machine on the local network.

So in the next release, I changed the default. If you don’t specify --host, http_this now binds to 127.0.0.1.

If you genuinely want the previous behaviour, you can now ask for it explicitly using --all. That option also has an alias: --promiscuous.

I rather like that alias. It’s technically accurate, but it also makes you stop for a moment and think about whether exposing your server on every network interface is really what you intended.

To me, that’s a much better design. Software should generally do the safest reasonable thing unless the user explicitly asks for something different.

Breaking changes aren’t always bad

Changing a long-standing default like this is, by definition, a breaking change. Anyone who had come to rely on the previous behaviour would suddenly find that their workflow had changed.

That’s exactly what semantic versioning is for.

Rather than quietly slipping the change into a minor release, I bumped the major version number and released App::HTTPThis 1.0.0. The module has taken rather longer than most to reach a 1.0.0 release, but changing a long-established default seemed like an appropriate milestone.

I also made sure the documentation was very explicit about the behavioural change so existing users wouldn’t be caught by surprise.

(There’s now a 1.0.1 release too, but that’s just a small follow-up fix.)

Unfortunately, the first person I broke was me

I was feeling rather pleased with myself.

Then I tried using http_this from WSL.

One of the nice things about WSL is being able to run development tools under Linux while using a browser running on Windows. That’s a workflow I use every day.

Unfortunately, binding to 127.0.0.1 inside WSL isn’t quite the same thing as making the server available to Windows. By fixing the default behaviour, I’d accidentally made my own development workflow considerably less convenient.

Fortunately, I didn’t need to back out the security improvement.

Instead, I added a --wsl option (which can also be enabled in your configuration file). Rather than listening on every interface, it determines the appropriate WSL network address and binds specifically to that interface instead.

The result is that http_this now has three distinct modes:

• the default, which binds only to 127.0.0.1;
• --wsl, which binds to the interface Windows can actually reach; and
• --all (or --promiscuous), which exposes the server on every network interface.

That feels like a much better balance between security and convenience.

A nice example of open source collaboration

One thing I particularly like about this sequence of events is how neatly it illustrates the way good open source software evolves.

Olaf didn’t arrive with a proposal to redesign the module. He noticed that the program’s output didn’t accurately describe what it was doing and submitted a focused pull request to correct that.

Reviewing his contribution naturally led me to question whether the underlying behaviour was actually the right default. Fixing that exposed an edge case in my own WSL workflow, which in turn led to a better solution for WSL users.

Looking back over the week, one small pull request ended up making the module more honest about what it was doing, safer by default, and more convenient to use in one of my favourite development environments.

Not bad for a week’s work.

Sometimes the best bug reports don’t just fix one bug. They make you realise there’s a better way for the software to behave.

Oh, and if reading this post makes you think I’m not really someone you wouldn’t want to trust with your network configuration—you’re probably right!

Further reading

• My original article: App::HTTPThis – the Tiny Web Server I Keep Reaching For
• Olaf Alders: Keep it Local
• The pull request that corrected the startup message
• The pull request that changed the default behaviour to bind to localhost
• The follow-up commit adding WSL support

The post How One Pull Request Took App::HTTPThis to Version 1.0 first appeared on Perl Hacks.

It’s an interesting question, but I think it’s asking the wrong thing.

I’ve spent almost forty years moving up the stack of database abstractions. Every few years, someone invents a new layer, and every few years, experienced programmers explain that they don’t need it because they’re perfectly capable of working at the layer below. I’ve watched exactly the same argument play out over CGI, web frameworks, ORMs, containers and now AI-assisted coding.

Sometimes the new abstraction turns out to be a dead end. More often, it’s simply another step that lets us spend less time on plumbing and more time solving the problems our users actually care about.

I think that’s what’s really going on here.

You’re comparing different layers

The first thing that struck me about the discussion was that it jumped straight from DBIx::Class to Mojo::Pg, as though they were equivalent choices. I don’t think they are.

If you zoom out a little, there are several layers involved in database access:

• Application
• DBIx::Class / DBIO (ORM)
• DBI
• DBD::Pg / DBD::SQLite / DBD::MariaDB
• Database

Each layer builds on the one below it. DBIx::Class sits on top of DBI, DBI sits on top of a database driver, and the driver talks to the database itself. Every layer gives you a slightly richer abstraction whilst hiding a little more of the mechanics.

Mojo::Pg occupies a rather different place. It’s a PostgreSQL library designed specifically for Mojolicious. That’s a perfectly sensible design if you’ve already decided you’re using both PostgreSQL and Mojolicious, but it couples together decisions that I’d normally prefer to keep separate.

Personally, I like choosing my web framework independently of my database, and my database independently of my data access layer. The more independent those decisions are, the easier it is to change one without affecting the others.

Why I moved up the stack

I started writing embedded SQL in C in the late 1980s. When I moved to Perl in 1996, I used Sybperl, which was a thin layer over the proprietary Sybase database API. When I discovered DBI, I adopted it enthusiastically because it removed an enormous amount of repetitive code whilst remaining database-independent. Later, when DBIx::Class became mature enough for production systems, I happily moved another level up the stack.

None of those decisions happened because I couldn’t write SQL. I’ve been writing SQL since 1988 and I’m perfectly happy doing so.

The point was that I no longer wanted to spend my time writing the same joins, the same foreign key lookups and the same bits of boilerplate over and over again. Those aren’t the interesting parts of my applications. They’re necessary, but they’re plumbing. Good abstractions let me write that plumbing once and then think about the domain I’m modelling instead.

This isn’t just about databases

A few weeks ago, I wrote about The Long Road from CGI to Containers. The point of that article was that the history of web development is largely the history of building better abstractions.

We moved from CGI scripts to web frameworks. From hand-written deployment procedures to containers. Every step let us express our intent at a higher level whilst worrying less about the implementation details.

Database programming has followed exactly the same path.

But I like writing SQL

Whenever I recommend an ORM, someone inevitably assumes it’s because I don’t know SQL.

Nothing could be further from the truth.

SQL is probably the programming language I’ve been writing the longest. I enjoy writing SQL. But I don’t enjoy writing the same SQL repeatedly.

I don’t want every controller containing another join between the same tables. I don’t want to duplicate the same WHERE clause in half a dozen places. I don’t want to remember every foreign key relationship every time I touch the code.

Those things aren’t business logic; they’re plumbing.

An ORM lets me move that plumbing into one place and give it names.

What DBIx::Class gives me

For me, the biggest advantage of DBIx::Class isn’t that it generates SQL.

It’s that it models my application.

• A Person has many Titles.
• A Title belongs to a Person.
• A User has many Orders.

Those relationships become part of the vocabulary of the application. Queries become reusable methods. Business rules become object methods instead of comments beside SQL statements.

Instead of thinking about joins, I’m thinking about people, titles and orders.

That’s a much nicer level of abstraction.

Isn’t it slower?

One criticism often levelled at DBIx::Class is performance.

That’s not entirely unfair. It’s perfectly possible to write inefficient DBIx::Class code. I know because I’ve done it.

While recently carrying out some optimisation on my Line of Succession application, I discovered one page was generating hundreds of unnecessary database queries. The solution wasn’t to abandon DBIx::Class and replace it with hand-written SQL. The solution was to understand the ORM better.

Adding a couple of well-placed prefetch clauses reduced the number of queries dramatically with almost no change to the surrounding code.

The ORM wasn’t the problem; my use of the ORM was.

That’s a useful lesson. Every abstraction has a learning curve. If you don’t understand how it’s working underneath, you’ll eventually hit performance problems. But once you do understand it, you can often achieve dramatic improvements without sacrificing the higher-level API that made you choose the abstraction in the first place.

What if I just want to write SQL?

One thing that struck me about the original discussion is that it jumped straight from DBIx::Class to Mojo::Pg, as though those were the only two choices.

I don’t think they are.

If all I wanted was to execute SQL from a Mojolicious application, I’d probably start by looking for a DBI-based solution rather than one that’s tied specifically to PostgreSQL. Something like Mojolicious::Plugin::Database seems like a more natural fit, as it lets me use the standard Perl database abstraction whilst integrating cleanly with Mojolicious.

That still leaves me free to choose PostgreSQL, SQLite, MariaDB or whatever other database makes sense for the project.

By contrast, choosing Mojo::Pg bakes the decision to use PostgreSQL into your application at a deeper level than I’d be comfortable with.

Good abstractions should reduce coupling, not increase it.

The model layer

Of course, in larger applications, there’s usually another abstraction on top of the ORM itself. My controllers don’t generally talk directly to DBIx::Class resultsets; they ask domain-level questions such as “Who was sovereign on this date?” The fact that the answer currently comes from DBIx::Class is an implementation detail. That’s another useful abstraction—but it’s probably a topic for another article.

Choosing your abstraction

I don’t think this is fundamentally a question about Mojolicious.

I’d happily use DBIx::Class with Mojolicious, Dancer2 or any other web framework. I’d happily use DBI with all of them too. The web framework and the data access layer are largely independent architectural decisions, and I generally prefer to keep them that way.

The important decision isn’t the framework.

It isn’t even the database.

It’s deciding where you want your application to live.

Do you want to think in terms of SQL?

Do you want to think in terms of tables?

Or do you want to think in terms of the concepts that make up your application’s domain?

After nearly forty years of writing SQL, I know which one I’d rather spend my day thinking about.

The best abstraction isn’t the one that hides the most detail.

It’s the one that lets you spend most of your time thinking about the problem you’re actually trying to solve.

Further reading

I’ve written about different aspects of this topic before:

• DBIx::Class vs DBI (2012) — why I prefer to use an ORM over raw SQL.
• The Joy of Prefetch (2015) — how understanding your ORM can transform performance.
• The Long Road from CGI to Containers (2026) — why software engineering is really the story of building better abstractions.

The post Choosing the Right Database Abstraction first appeared on Perl Hacks.

A recent question from my friend and colleague Mohammad got me thinking about the way we identify data in web applications.

While working on the DBIC component of a REST API, he came across the term enumeration attack. In this type of attack, an attacker systematically guesses resource identifiers in order to access data they shouldn’t be able to see.

For example, if your API exposes URLs like this:

GET /users/123
GET /users/124
GET /users/125

then it’s easy for someone to try a large range of identifiers and see what they get back.

Mohammad’s question was simple:

Should we replace sequential IDs with UUIDs? And if we do, should we index the UUID column?

As is often the case, the answer turned out to be “it depends”.

Two Different Types of Data

The first thing I realised is that not all data objects have the same requirements.

Some objects are naturally public.

For example, books on a publishing website are intended to be discovered. In fact, you probably want people to be able to guess their URLs:

/books/design-patterns-in-modern-perl

In this case, a human-readable slug makes perfect sense. Other objects are private by nature. User accounts, orders, invoices and API resources generally shouldn’t be enumerable. In those cases, a UUID is often a better choice:

/users/550e8400-e29b-41d4-a716-446655440000

The important observation is that slugs and UUIDs solve different problems.

• Slugs are for humans (and, perhaps, search engines).
• UUIDs are for machines.

Database Design

A common question is whether a UUID should replace the primary key.

In most cases, I don’t think it should.

My preferred design is:

CREATE TABLE users (
  id BIGINT PRIMARY KEY,
  uuid UUID NOT NULL UNIQUE
);

The integer primary key remains the internal identifier used for joins and foreign keys.

The UUID becomes the public identifier exposed through APIs.

This gives you the best of both worlds:

• Small, efficient foreign keys.
• Fast joins.
• Unguessable public identifiers.

If the application regularly searches by UUID then the UUID column should be indexed. In practice, declaring it UNIQUE will usually create the appropriate index automatically.

The Hybrid Approach

Thinking about this reminded me that many large sites use a hybrid approach.

Amazon product URLs contain both a human-readable title and a stable identifier:

/Design-Patterns-Modern-Perl/dp/B0XXXXX123

The ASIN is what really identifies the product.

The title is there for humans.

Stack Overflow does something similar:

/questions/12345/how-do-i-index-a-uuid-column

Again, the question ID is authoritative. The title is helpful context.

My Line of Succession website uses the same idea.

A person page looks like this:

/p/2b5998-the-prince-william-prince-of-wales

The important part is the identifier:

2b5998

The rest is descriptive text.

This turns out to be particularly useful for royalty because titles change constantly. Someone might be “Prince William”, then “The Prince of Wales”, and eventually “King William V”.

By separating identity from presentation, old links continue to work regardless of title changes.

A Tiny Bug

While thinking about all of this, I discovered a small bug in Line of Succession.

The site allows any descriptive text after the identifier. These URLs all resolve to the same person:

/p/2b5998-the-prince-william-prince-of-wales
/p/2b5998-prince-billy
/p/2b5998-fred

The application correctly ignores the descriptive text and uses only the identifier.

However, there was a problem.

The page was generating its canonical URL from the incoming request path rather than from the person record.

That meant a request for:

/p/2b5998-prince-billy

generated:

<link rel="canonical"
      href="https://lineofsuccession.co.uk/p/2b5998-prince-billy">

which is obviously not the canonical URL.

The fix was surprisingly small:

sub canonical( $self ) {
   if ($self->request->is_date_page) {
     return '/' . $self->canonical_date;
+  } elsif($self->request->is_person_page) {
+    return '/p/' . $self->request->person->slug;
   } else {
     return $self->request->path;
   }
 }

At the same time I simplified another method by making it reuse the canonical URL logic.

The result was a six-line patch that fixed the SEO issue and made the code slightly cleaner.

Those are my favourite kinds of fixes.

Future Improvements

The fix also revealed an emerging abstraction in the code.

At the moment, various parts of the application know how to construct URLs for different object types.

A cleaner approach would be to give objects responsibility for generating their own URLs.

I’m considering a HasURL role that would require an object to provide an identifier and optionally a prefix, and then build the URL automatically.

That’s a job for another day.

For now, a small question about UUIDs led to a useful discussion about public identifiers, a review of URL design, and a tiny production fix. Not bad for an afternoon’s work.

The post Public Identifiers, UUIDs and a Tiny SEO Fix first appeared on Perl Hacks.

If you’ve spent any time around AI tooling recently, you’ve probably seen people talking about MCP. It’s often described as “USB for AI”, which is perhaps a little overblown, but the basic idea is sound. MCP provides a standard way for AI assistants to discover and use external tools and data sources.

In practical terms, it means that instead of building bespoke integrations for ChatGPT, Claude, Gemini and whatever comes next, you expose a standard MCP endpoint and let the AI clients do the rest.

For a data-driven site like Line of Succession, that seemed like an obvious experiment.

What is MCP?

The Model Context Protocol was originally developed by Anthropic and has rapidly become one of the emerging standards in the AI ecosystem.

An MCP server exposes:

• Information about itself
• A list of available tools
• Schemas describing how those tools should be called
• The results returned by those tools

An AI client can connect to the server, discover the available tools and invoke them when needed.

Instead of scraping web pages or attempting to infer information from HTML, the AI gets access to structured data.

That’s exactly the kind of thing Line of Succession is good at.

Why Add MCP?

The site already exposes information through a traditional web interface and a JSON API.

But those interfaces were designed for humans and developers respectively.

MCP gives AI systems a much cleaner integration point.

For example, an AI assistant can now answer questions like:

• Who was the British sovereign on 14 November 1948?
• What did the line of succession look like in 1980?
• Who was next in line when Queen Victoria died?

without having to scrape pages or understand the site’s internal URLs.

More importantly, it ensures that the information comes directly from the same database that powers the website.

The AI isn’t guessing.

It’s querying the source of truth.

As someone who runs a reference website, that’s a pretty attractive proposition.

The Initial Design

My first goal was to keep things simple.

Rather than exposing dozens of narrowly-focused tools, I started with just two:

• sovereign_on_date
• line_of_succession

Those two tools cover a surprisingly large proportion of the questions people are likely to ask.

The first returns the sovereign reigning on a given date. The second returns the line of succession for a specified date, with a configurable limit on the number of entries returned.

The implementation currently caps the list at thirty people. That’s enough for most use cases while preventing someone from accidentally asking for all six thousand people currently in the line of succession.

One thing I learned quite quickly is that MCP isn’t really about exposing huge amounts of data. It’s about exposing useful questions that can be answered from your data.

MCP Is Mostly JSON-RPC

One thing that surprised me when I first started reading the specification was how little protocol code is actually required.

At its core, MCP uses JSON-RPC.

A client sends requests like:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

and the server responds with:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    ...
  }
}

Once I’d written helper methods for creating standard JSON-RPC responses, most of the complexity disappeared.

The MCP module contains methods like:

sub rpc_result ($self, $id, $result)

and:

sub rpc_error ($self, $id, $code, $message)

which means the Dancer route handlers remain pleasantly small.

The protocol logic lives in one place and the web application simply delegates to it.

Separating the MCP Logic

I didn’t want protocol-specific code scattered throughout the web application.

Instead, I created a dedicated module:

package Succession::MCP;

This module is responsible for:

• Initialisation
• Tool discovery
• Tool execution
• JSON-RPC response generation
• Error handling

That keeps the Dancer routes thin and makes the MCP implementation easier to test independently.

It also means that if I ever decide to expose the same MCP server through a different transport mechanism, most of the work is already done.

Tool Calls Are Mostly Adapters

One pleasant surprise was how little new application logic I actually had to write.

The MCP server needs to expose tools, but those tools ultimately just answer questions about the succession database. The code to answer those questions already existed.

For example, the application’s model layer already contained methods such as:

• sovereign_on_date()
• line_of_succession()

These methods power parts of the website itself, so they already encapsulate all of the business rules and database queries.

The MCP implementation simply acts as an adapter.

When a tool call arrives, the server extracts the arguments, validates them and passes them to the existing model methods:

sub _call_tool ($self, $tool_name, $args) {
  my $tool = $self->_tool_dispatch->{$tool_name};

  return $tool->($args);
}

The tool implementations themselves are deliberately thin:

sub sovereign_on_date ($self, $args) {
  my $date = $args->{date};

  my $sovereign = $self->model->sovereign_on_date($date);

  ...

}

That’s exactly how I wanted it to work.

The MCP layer doesn’t know how to calculate a line of succession or determine who was sovereign on a particular date. It simply knows how to expose those capabilities through the protocol.

This is one of the advantages of adding MCP to an existing application. If your business logic is already cleanly separated from your web interface, an MCP server often becomes surprisingly straightforward to implement.

In many ways, adding MCP feels less like building a new application and more like adding another interface alongside the website and API.

The YAML Epiphany

The most interesting design decision came a little later.

Initially, the tool definitions lived in Perl data structures.

That worked, but it quickly became obvious that I was duplicating information.

The MCP server needed tool descriptions.

The documentation page needed tool descriptions.

The schemas needed to be defined somewhere.

And every change required updating multiple places.

The obvious answer was to move all of the tool definitions into a YAML file.

The MCP module now loads its tool definitions at startup:

sub _build__tools ($self) { return LoadFile($self->tools_file); }

The result is a single source of truth.

The same YAML file drives:

• The tools/list response
• Tool metadata
• JSON schemas
• Human-readable documentation

Adding a new tool now involves updating one file and writing the code that implements it.

Everything else follows automatically.

Here’s the current YAML file:

# data/mcp-tools.yml

- name: sovereign_on_date
  description: Return the British sovereign on a given date.
  documentation: |
    Looks up the reigning British sovereign for the supplied date.

    Use this when answering questions such as “Who was sovereign on
    6 February 1952?”
  inputSchema:
    type: object
    properties:
      date:
        type: string
        description: Date in YYYY-MM-DD format.
    required:
      - date

- name: line_of_succession
  description: Return the line of succession on a given date.
  documentation: |
    Returns people in the line of succession.

    If no date is supplied, the current line of succession is returned.
  inputSchema:
    type: object
    properties:
      date:
        type: string
        description: Optional date in YYYY-MM-DD format. Omit for the current line of succession.
      limit:
        type: integer
        description: Maximum number of successors to return.
        minimum: 1
        maximum: 100
      required: []

Looking back, this is probably the part of the design I’m happiest with. It feels very Perl-ish: keep configuration as data and avoid duplicating information wherever possible.

Human Documentation Matters

One thing I noticed while exploring other MCP servers is that many of them are effectively invisible to humans.

You know an endpoint exists.

You know it speaks MCP.

But unless you inspect the protocol responses manually, you don’t really know what it does.

I decided to add a conventional web page at /mcp.

The page lists all available tools, their descriptions and their schemas.

The nice part is that there is no duplicated documentation.

The page is generated from the same YAML definitions used by the MCP server itself.

If I add a new tool tomorrow, both the machine-readable and human-readable views update automatically.

Structured Data and Text Responses

Another nice feature of MCP is that tool results can include both structured data and human-readable text.

For example, a tool response might contain:

{
  "content": [ {
    "type": "text",
    "text": "The sovereign on 14 November 1948 was George VI."
    } ],
  "structuredContent": {
    ...
  }
}

The structured content is useful for software.

The text is useful for humans and language models.

Both are generated from the same underlying data.

That gives AI clients flexibility while ensuring consistency.

Getting Listed

Once everything was working, I submitted the server to the MCP directory at mcpservers.org.

That might seem like a small step, but discoverability is important.

An MCP server hidden on a random website isn’t much use if nobody knows it exists.

Directories like that are rapidly becoming the equivalent of API catalogues for the AI era.

Being listed means developers and AI enthusiasts can find the service without first discovering the website.

Was It Worth It?

Absolutely.

The amount of code required was surprisingly small. Most of the work wasn’t implementing the protocol; it was deciding how best to expose the data.

More importantly, it opens the site up to an entirely new audience: AI agents.

Historically, websites were built for humans and APIs were built for developers.

MCP introduces a third category: services designed specifically for AI systems.

For a structured-data site like Line of Succession, that’s a natural fit.

Will MCP still be the dominant standard in five years’ time? I have no idea. The AI industry changes too quickly to make confident predictions.

But right now it has significant momentum, broad industry support and a growing ecosystem of tools.

And if nothing else, it’s rather satisfying to ask an AI who was on the throne on a particular date and know that the answer came directly from my database rather than from whatever the model happened to remember.

The post Teaching AI About the British Monarchy with MCP first appeared on Perl Hacks.

That sounds abstract, but it turns out to explain a huge amount of the progress we’ve made in software development over the last twenty-five years.

And nowhere is that clearer than in Perl web development.

Many of us who built web applications during the dotcom boom spent years learning this lesson the hard way.

We wrote CGI programs that:

• parsed HTTP requests
• generated HTML by hand
• connected directly to databases
• embedded SQL inline
• mixed business logic with presentation
• relied on Apache behaviour
• assumed specific filesystem layouts
• and often only worked on one particular server configuration

It all worked. Until it didn’t.

The history of Perl web development is, in many ways, the history of gradually moving implementation details into more appropriate architectural layers.

The Early CGI Years

Early Perl CGI applications were often a single giant script.

You’d open a file and see:

• request handling
• authentication
• HTML generation
• SQL queries
• business logic
• configuration
• deployment assumptions

…all mixed together in a glorious ball of mud.

Something like this:

#!/usr/bin/perl

use CGI;
use DBI;

my $cgi = CGI->new;

print $cgi->header;
print "<html><body>";

my $dbh = DBI->connect(
  "dbi:mysql:test",
  "user",
  "pass"
);

my $sth = $dbh->prepare(
  "select * from users where id = ?"
);

$sth->execute($cgi->param('id'));

while (my $row = $sth->fetchrow_hashref) {
  print "<h1>$row->{name}</h1>";
}

print "</body></html>";

And to be fair, it was a huge step forward from static HTML sites.

But the design had a fundamental problem:

Everything knew too much about everything else.

The application logic knew:

• how HTTP worked
• how HTML worked
• how Apache launched CGI scripts
• how the database worked
• how the operating system was configured

Every concern leaked into every other concern.

That made systems:

• hard to test
• hard to reuse
• hard to deploy
• hard to scale
• and terrifying to change

The First Big Lesson: Put Logic in Libraries

One of the first signs of a developer maturing is the realisation that application logic should live in reusable modules, not in front-end scripts.

Instead of this:

if ($user->{status} eq 'gold') {
  $discount = 0.2;
}

my $discount = $user->discount_rate;

Now the business logic lives in a library.

And once that happens, several good things follow automatically.

Multiple Interfaces Become Possible

If the logic is in modules, then:

• a web front-end
• a CLI tool
• a REST API
• a cron job
• a queue worker

…can all use the same underlying code.

The interface layer becomes thin.

The application itself becomes independent of how users interact with it.

That’s a huge increase in flexibility.

Testing Becomes Easier

Testing CGI scripts was always awkward.

Testing modules is straightforward.

You can instantiate objects, call methods, and inspect results without needing a web server or HTTP requests.

The easier code is to test, the more likely it is to be tested.

And tested code tends to survive longer.

Deployment Becomes Safer

Once the core behaviour is isolated from the interface layer, replacing the interface becomes far less risky.

You can redesign the UI without rewriting the application.

That separation is one of the foundations of maintainable software.

The PSGI Revolution

The next big architectural leap in Perl web development came with PSGI and Plack.

Younger developers may not fully appreciate how painful web deployment used to be.

In the early 2000s, moving an application between hosting environments could require substantial rewrites.

• A CGI application worked one way.
• A mod_perl application worked another way.
• FastCGI had its own quirks.
• Embedded Apache handlers behaved differently again.

Many Perl developers spent years repeatedly rewriting applications simply because deployment environments changed.

That was madness.

The deployment model is an operational concern.

It should not affect application architecture.

PSGI fixed this by defining a standard interface between web applications and web servers.

The core idea was beautifully simple:

A web application is just a function that receives an environment and returns a response.

Once that abstraction existed, applications no longer cared whether they were running:

• as CGI
• under mod_perl
• inside FastCGI
• under Starman
• behind nginx
• on a development laptop
• or inside a cloud container

The deployment details moved down a layer.

Exactly where they belonged.

This was one of the most important architectural improvements Perl web development ever made.

And it reflected a broader truth:

Good abstractions stop lower-level implementation details leaking upward.

The Transitional Era: FatPacker and cpanfile

There was also an interesting intermediate stage between traditional Perl deployments and full containerisation.

For years, one of the hardest parts of deploying Perl applications was dependency management.

You’d move an application to a new server and discover:

• the wrong module version
• missing XS libraries
• incompatible Perl versions
• or an entire dependency tree that worked perfectly on the developer’s machine and nowhere else

Large parts of Perl deployment culture evolved around coping with this problem.

Tools like cpanfile improved things by making dependencies explicit and reproducible.

Instead of vaguely documenting requirements in a README, applications could formally declare:

requires 'Dancer2';
requires 'DBIx::Class';
requires 'Template';

Then tools like App::FatPacker went even further by packaging dependencies directly alongside applications.

Instead of relying on the target server’s Perl environment, applications could carry much of their runtime context with them.

These tools didn’t completely solve deployment portability:

• system libraries still mattered
• Perl versions still mattered
• operating system differences still mattered

…but they represented an important shift in thinking.

The industry was gradually realising that:

• deployment environments were part of the application
• reproducibility mattered
• and infrastructure assumptions needed to be controlled

Containers eventually pushed this idea to its logical conclusion by packaging not just Perl dependencies, but the entire runtime environment.

In hindsight, tools like cpanfile and FatPacker were stepping stones toward modern container-based deployment models.

Containers Are the Same Idea Again

Docker and containers are simply the same architectural principle repeated one layer lower.

Before containers, deployments were often fragile and highly environment-specific.

Applications depended on:

• particular Linux distributions
• specific Perl versions
• installed system libraries
• hand-configured servers
• undocumented setup steps

Developers became experts in “works on my machine”.

Operations teams became experts in swearing.

Containers changed the model.

Instead of deploying:

• source code

…you deploy:

• a complete runtime environment

Now the application no longer cares whether it runs:

• on bare metal
• on a VPS
• in Kubernetes
• in ECS
• in Cloud Run
• or on someone’s laptop

Again:

• infrastructure concerns move downward
• application concerns stay upward

The boundaries become cleaner.

The Pattern Repeats Everywhere

Once you notice this pattern, you see it throughout software engineering.

Templates

Template systems separate:

• presentation

from

• application logic

HTML should not contain database code.

Business logic should not contain giant blobs of HTML.

ORMs and Database Layers

DBI separates applications from database engines.

ORMs separate applications from raw SQL structure.

Again:

• implementation details move downward

Configuration

Configuration belongs outside code.

Deployment-specific values should not be embedded in applications.

APIs

Clients should not care whether data comes from:

• PostgreSQL
• Redis
• another service
• a queue
• flat files
• or magic elves

That’s the implementation’s problem.

The Goal Is Not Abstraction for Its Own Sake

Of course, experienced developers also know that abstractions can become ridiculous.

Some abstractions simplify systems.

Others merely hide complexity behind six additional layers of YAML.

Joel Spolsky’s “Law of Leaky Abstractions” remains painfully relevant.

The goal is not abstraction itself.

The goal is to isolate genuinely volatile details.

Good abstractions protect systems from change.

Bad abstractions merely obscure reality.

The Real Skill

The deeper lesson here is that software architecture is largely about deciding:

“What belongs where?”

Experienced developers develop an instinct for:

• which details are likely to change
• which layers should know about which concerns
• and where boundaries should exist

That instinct is often more important than language choice, frameworks, or technology stacks.

And if you spent the early 2000s rewriting CGI applications to run under mod_perl, you probably learned that lesson the hard way.

The post The Long Road from CGI to Containers first appeared on Perl Hacks.

Because, as I’m sure you’ve noticed, it’s very easy to forget.

So this month, I decided to automate it.

(And, if you’re interested in the end result, this is also a good excuse to mention that the newsletter exists. Two birds, one stone.)

The Problem

All of my Git repositories live somewhere under /home/dave/git. Over time, that’s become… less organised than it might be. Some repos are directly under that directory, others are buried a couple of levels down, and I’m fairly sure there are a few I’ve completely forgotten about.

What I wanted was:

• Given a month and a year
• Find all Git repositories under that directory
• Identify which ones had commits in that month
• Summarise the work done in each repo

The first three are straightforward enough. The last one is where things get interesting.

Finding the Repositories

The first step is walking the directory tree and finding .git directories. This is a classic Perl task — File::Find still does exactly what you need.

use v5.40;
use File::Find;

sub find_repos ($root) {
  my @repos;

  find(
    sub {
      return unless $_ eq '.git';
      push @repos, $File::Find::dir;
    },
    $root
  );

  return @repos;
}

(There are, of course, other ways to do this — you could shell out to fd or find, for example — but keeping it in Perl keeps everything nicely self-contained.)

Getting Commits for a Month

For each repo, we can run git log with appropriate date filters.

sub commits_for_month ($repo, $since, $until) {
  my $cmd = sprintf(
    q{git -C %s log --since="%s" --until="%s" --pretty=format:"%%s"},
    $repo, $since, $until
  );

  my @commits = `$cmd`;
  chomp @commits;

  return @commits;
}

my $since = "$year-$month-01";
my $until = "$year-$month-31"; # good enough for this purpose

A Small Gotcha

It turns out I have a few repositories where I never got around to making a first commit. In that case, git log helpfully explodes with:

The fix is simply to ignore failures:

my @commits = `$cmd 2>/dev/null`;

This is one of those little bits of defensive programming that makes the difference between a script you run once and a script you’re happy to run every month.

Summarising the Work

Once we have a list of commit messages, we can summarise them.

And this is where I cheated slightly.

I used OpenAPI::Client::OpenAI to feed the commit messages into an LLM and ask it to produce a short summary.

Something along these lines:

use OpenAPI::Client::OpenAI;

sub summarise_commits ($commits) {
  my $client = OpenAPI::Client::OpenAI->new(
    api_key => $ENV{OPENAI_API_KEY},
  );

  my $text = join "\n", @$commits;

  my $response = $client->chat->completions->create({
    model => 'gpt-4.1-mini',
    messages => [{
      role => 'user',
      content => "Summarise the following commit messages:\n\n$text",
    }],
  });

  return $response->choices->[0]->message->content;
}

Could I have written some heuristics to group and summarise commit messages? Possibly.

Would it have been as much fun? Definitely not.

And in practice, it works remarkably well. Even messy, inconsistent commit messages tend to turn into something that looks like a coherent summary of work.

Putting It Together

For each repo:

1. Get commits for the month
2. Skip if there are none
3. Generate a summary
4. Print the repo name and summary

The output looks something like:

my-project
-----------
Refactored database layer, added caching, and fixed several edge-case bugs.

another-project
---------------
Initial scaffolding, basic API endpoints, and deployment configuration.

A Nice Side Effect

One unexpected benefit of this approach is that it surfaces projects I’d forgotten about.

Because the script walks the entire directory tree, it finds everything — including half-finished experiments, abandoned ideas, and repos I created at 11pm and never touched again.

Sometimes that’s useful. Sometimes it’s mildly embarrassing.

But it’s always interesting.

What Next?

This is very much a first draft.

It works, but it’s currently a script glued together with shell commands and assumptions about my directory structure. The obvious next step is to:

• Turn it into a proper module
• Add tests
• Clean up the API
• Release it to CPAN

At that point, it becomes something other people might actually want to use — not just a personal tool with hard-coded paths and questionable date handling.

A Future Enhancement

One idea I particularly like is to run this automatically using GitHub Actions.

For example:

• Run monthly
• Generate summaries for that month
• Commit the results to a repository
• Publish them via GitHub Pages

Over time, that would build up a permanent, browsable record of what I’ve been working on.

It’s a nice combination of:

• automation
• documentation
• and a gentle nudge towards accountability

Which is either a fascinating historical archive…

…or a slightly alarming reminder of how many half-finished projects I have.

Closing Thoughts

This started as a small piece of automation to help me write a newsletter. But it’s turned into a nice example of what Perl is still very good at:

• Gluing systems together
• Wrapping command-line tools
• Handling messy real-world data
• Adding just enough intelligence to make the output useful

And, occasionally, outsourcing the hard thinking to a machine.

The code (such as it is currently is) is on GitHub at https://github.com/davorg/git-month-summary.

If you’re interested in the kind of projects this helps summarise, you can find my monthly newsletter over on Substack.

And if I get round to turning this into a CPAN module, I’ll let you know – well, if you’re subscribed to the newsletter!

The post Summarising a Month of Git Activity with Perl (and a Little Help from AI) first appeared on Perl Hacks.