I’m just finishing my sixth week using the planning mechanisms I described in my last newsletter, and I’m very impressed by the difference they've made to my working day. I have a lot of progress to tell you about. And we’ll get to that, but first, I have a couple of speaking engagements that you might be interested in.

On Wednesday, 21 October (that’s next Wednesday, from when I’m writing this), I’m giving an online talk called MCP - Model Context Protocol in Perl: From Web App to AI Tools for Perl Maven. I’ll explain how I made the data that drives my Line of Succession website available to your favourite AI tools. There are already a ridiculous number of people signed up, but I’m sure there is room for a few more.

And then, a month later, we have the London Perl Workshop. The workshop seems to have fully recovered from its post-COVID interregnum—this is the third consecutive year that the event has taken place. And this year it’s at a new venue, the Zoopla offices in Shad Thames. I’m not sure what I’ll be speaking about yet, but I’ve proposed a few talks and left the choice in the hands of the organisers. But even if they don’t select any of my talks, I’m confident that the day will be packed full of useful and interesting information for Perl programmers.

With that out of the way, let’s look at what I’ve been doing.

Data Munging with Perl [2ed]

Lots of progress here. You can see exactly what has changed by looking at the updates section on the book’s website. I’m going to read the book through completely over the weekend and come up with a (hopefully very short) list of things that need to be fixed before the book can be published. The plan is that I’ll be able to bring some copies (real paperback copies!) with me to sell at the London Perl Workshop.

But if you can’t wait until then, you can still buy the Work In Progress version from LeanPub, which will allow you to update to the completed ebook once it is published.

It’s good to get to complete a project. And publishing this will leave a large, book-writing-shaped hole in my schedule. I already have a few ideas about what might fill that hole.

Perl School

Working on Data Munging with Perl led me to think a little more deeply about Perl School. At first, I was just publishing books by myself, but that has expanded and we now publish books by four different authors. I started to wonder what it might look like if Perl School turned into more of a “real” business (whatever that means). And, obviously, it means more books by more authors. But it also means running the business in a more professional manner. Which is what I’ve been trying to do over the last few months.

• I’ve had conversations with a number of people, which have led to potentially four or five new Perl School books to be written over the next year

• I’ve set up a mailing list for people who want to keep in touch with what’s going on with Perl School (you can subscribe using the form at the bottom of every page on the website)

• I’ve created the first draft of an author agreement, which forced me to think a bit more deeply about what Perl School is and how it works (related to that, I’ve also rewritten the “Write For Us” page on the website, so it better explains what we offer for authors)

• I’ve written software that takes sales and royalty data from both Amazon KDP and LeanPub and combines that in a database that makes it easier to produce statements, telling me how much I owe authors

• I’ve written production software that takes a book written in Markdown and produces an EPUB and two PDFs (one A4 with no blank pages for sale through LeanPub and a version for the Amazon KDP paperback print-on-demand system, that implements dozens of nice little formatting tweaks that make a print-on-demand book look more like a “real” book

We are never going to be O’Reilly (or even Manning). But I think I’m building the basis of a nice little business. I just need people to buy a few more books.

Line of Succession

Line of Succession is my most successful project. That is, it’s certainly the website that gets the most hits each month. But currently, it’s completely unmonetised. I ran Google Ads on in for a while, but I made almost no money and I don’t think they went well with the general ambience of the site. So I’ve been thinking about that.

• I’ve turned on paid subscriptions for the Substack associated with the site. No-one is paying yet though

• I’ve got into more of a regular rhythm of posting to the Substack once a week. And I’ve moved away from covering just the current British royal family

• I’ve fixed a few niggling little bugs on the site and made some improvements. For example, people who are excluded from the line of succession are now included in lists on the site

• I’ve improved how the site’s Model Context Protocol server works. I’ve been able to connect Line of Succession to both ChatGPT and Claude’s chatbot. It was an exciting day when that worked

But my biggest play on the site is demonstrated by the image at the top of this section. I want to sell personalised prints of the line of succession on a certain date. I’m thinking there will be three price points: a digital image, an unframed print (maybe in multiple sizes) and a framed version. There’s a page on the site where you can see how it would look for a date that is meaningful to you in some way, but I’ve yet to work out the payment path or how to connect to a print shop that would print and ship the print.

And everything else...

Those are the three projects that have taken up most of my time over the last few weeks. But there are plenty of other things that I’ve been working on. Here are a few of them.

Oneirina: I’ve been experimenting with AI-generated music for a while now, and I’ve created a virtual artist called Oneirina. She has released a few songs on the usual streaming services, but getting people to listen to them is a completely different challenge. I’ve been experimenting with creating short music videos for YouTube and TikTok, using a combination of AI video generation, ElevenLabs and CapCut. It’s been a lot of fun (and occasionally frustrating, particularly when TikTok decides to mute the music in a music video—when it’s my music on my video!) I’ve also just submitted a short video message from Oneirina for Spotify Wrapped 2026. I have no idea whether any of this will result in more people listening to the music, but I’m learning a lot along the way.

The Story Cupboard: Another experiment with AI-generated video. A while ago, I wrote a children’s story called George and the Smart Home. I’ve now turned it into a short animated video, complete with narration and music, and published it on YouTube. I’ve created a new channel called The Story Cupboard for this and similar projects. The next video will be based on another children’s book I’ve written, Digital Woodland ABCs. Again, I have no idea whether anyone will watch these videos, but it’s interesting to see just how much you can achieve with tools that didn’t exist a couple of years ago.

The Horsell Transmissions: Over the first half of this year, I wrote a science fiction serial called The Horsell Transmissions, which I published in instalments on Substack. I’ve now edited the whole thing into a book and published it as a paperback on Amazon. It’s nice to have another finished book out in the world. Of course, now I have to work out how to persuade people to buy it. I’m beginning to see a pattern here.

NonProphet: This is another project that uses AI to generate content. It’s a system that produces short, daily social media posts about religion, scepticism and critical thinking. I’ve built the first version of the software and set up accounts on TikTok, Instagram, Bluesky and YouTube. The content generation is working well, but building an audience is proving rather harder. It turns out that automatically creating content and getting people to look at it are two very different problems. Who knew?

Perl Hacks: I’ve also found some time to return to Perl Hacks, my long-running Perl blog. I’ve made a few improvements to the site and published some new posts. One of the most recent was a look back at the history of WWW::Shorten, a Perl module I first released over twenty years ago. It’s slightly alarming to realise that some of the software I’ve written is now old enough to have its own history.

So, is the planning working?

Looking back over everything I’ve written here, I’m actually rather surprised by how much I’ve managed to get done over the last six weeks. And that’s before mentioning all the smaller things that haven’t made it into this newsletter.

I don’t think I’m working any harder than I was before. I’m certainly not working longer hours. But I am spending less time wondering what I should be doing next, and more time actually doing things. Having a plan for the week, and knowing which projects I’m supposed to be concentrating on, seems to make a real difference.

Of course, there’s still a problem. I’m very good at coming up with new ideas, and I’m getting better at turning those ideas into finished projects. What I’m not particularly good at is persuading people to pay money for the results. That’s probably something I should spend a bit more time planning.

But, for now, I’m going to count the last six weeks as a success. I’ve made progress on several projects, finished a few things that have been hanging around for far too long, and learned some interesting new skills.

And all it took was a little planning. Who knew?

That’s all for now, see you next time.

Leave a comment telling me what personal projects you’re working on,

Dave…

At the end of 2019, I quit my job.

That probably needs a little context.

For most of my career, I’d been a freelance software developer. By 2018, I was a reasonably well-known Perl contractor and had worked for most of the companies in London that employed significant numbers of Perl programmers.

That year, I started a contract at FairFX (now called Equals Money). About a year later, the company decided to reduce its reliance on contractors. But rather than getting rid of me, they offered me a permanent job as a staff engineer.

I accepted.

About six months later, I realised that permanent employment really wasn’t for me.

So I resigned.

Fortunately, I had enough savings that I didn’t need to find another contract immediately. Instead, I decided to give myself a year to see whether I could turn one of the many ideas rattling around my head into a business that could support me.

I called it my 2020 Vision.

The plan was simple. I’d spend a month on each idea. At the end of the month, I’d move on to the next one. Presumably, at some point, one of them would show enough promise that I’d concentrate on it.

January was the Line of Succession. I’d been running a rather rudimentary version of the site for years, so I spent the month turning it into something more professional and started trying to find an audience for it.

February was Lystyng, an idea for a social network based around people sharing lists. That never got very far, although I still occasionally think there’s something in the idea.

March was More Than Code, a book about the parts of being a software developer that aren’t actually writing software.

And around this time, I started a newsletter to document the experiment.

I called it One Thing at a Time.

You can probably guess what happened next.

It was March 2020.

For no particularly rational reason (I was working at home anyway and had enough money to live on) the arrival of Covid completely derailed the experiment. The remainder of 2020 disappeared into a sea of confusion.

Since then, I’ve been slowly rebuilding.

I’ve taken more contracts. I’ve even had another attempt at permanent employment (I lasted four months that time). And, all the while, I’ve continued to collect projects.

Lots of projects. You will have seen me mention some of them in this newsletter.

There are books. Websites. Newsletters. Software projects. Music projects. Some are finished. Some are nearly finished. Some are little more than domain names and vague intentions. Some have been sitting untouched for years before suddenly springing back to life.

And this creates a problem.

The obvious solution is right there in the name of this newsletter: one thing at a time.

Pick the most important project. Work on it until it’s finished. Then pick another one.

It’s excellent advice.

And I seem completely incapable of following it.

The Three Ps

A few years ago, a friend suggested a different way of thinking about my collection of projects. I’ve refined the idea over time into what I now call the Three Ps.

They are Profit, Practice and Profile.

Profit is the obvious one. Does this project make money? Or, perhaps more importantly, is there a plausible route by which it might eventually make money?

Client work is almost entirely Profit. Other projects might not make much money today, but could conceivably grow into useful sources of income.

Practice is about developing skills.

I’m a software developer, but the list of things I want to be better at extends far beyond writing code. Writing, publishing, design, marketing, AI, video, audio, data analysis—there are always new things to learn.

A project can justify some of my time simply because working on it teaches me something useful.

And then there’s Profile.

Some projects put my work in front of people. They build an audience, enhance my reputation or introduce me to people I wouldn’t otherwise encounter.

That has value too. Sometimes it’s eventually financial value. Sometimes it leads to opportunities that I couldn’t possibly have predicted when I started the project.

The important thing is that these aren’t three separate buckets.

A good project might hit two of the Ps. A really good one might hit all three.

And a project that hits one of them particularly strongly can still be worth doing.

But there’s also an interesting question to ask about a project that doesn’t hit any of them.

Why am I spending time on this?

Perhaps there’s a good answer. This isn’t intended to be an algorithm for running my life. I’m allowed to do things just because I enjoy them.

But it’s a useful question.

One day at a time

Over the last couple of weeks, I’ve started using the Three Ps more deliberately to plan my working time.

And it’s made me reconsider what I meant when I called this newsletter One Thing at a Time.

Back in 2020, the unit of “at a time” was a month.

January was Line of Succession. February was Lystyng. March was More Than Code.

The theory was that I’d concentrate exclusively on one project for a month before moving on to something else.

I don’t think that works for me.

What seems to work rather better is making the unit a day.

I can have several active projects. But that doesn’t mean they all need to be competing for my attention simultaneously.

Today can be a book day.

Tomorrow can be a Line of Succession day.

Another day can be devoted to promoting some music I’ve released.

Another can be spent experimenting with some new technology.

The Three Ps help me decide which projects deserve those days. And once I’ve decided what a particular day is for, One Thing at a Time takes over.

There’s a surprisingly important psychological difference here.

If I know that a project has Thursday allocated to it, I don’t need to fiddle with it on Tuesday. I can concentrate on Tuesday’s project because I know the other thing’s turn is coming.

I’m still experimenting with this. I’m sure the system will change again.

But I increasingly think my problem was never that I had too many projects.

The problem was having too many projects asking for my attention at the same time.

Putting it into practice

This all sounds suspiciously like the kind of productivity system that is much more fun to devise than it is to actually use.

So I’ve started using it.

For the last couple of weeks, I’ve been looking across my collection of projects, thinking about how they score against the Three Ps, and giving particular projects whole days in my calendar.

Some of the choices are obvious.

Data Munging with Perl is the second edition of a book I first published more than twenty years ago. It’s currently about 80% complete and I want paperback copies available for the London Perl Workshop at the end of November. That’s primarily Profit (it’s a product I can sell), but writing it also keeps my Perl knowledge sharp and raises my profile in a community where I’ve been working for decades. So there’s a bit of all three Ps there.

Line of Succession is an even more interesting example. It’s the survivor from the original 2020 Vision experiment. It already has a small audience, and recently I’ve been looking seriously at ways to turn that audience into income — paid newsletter subscriptions, books and personalised printed family trees of the royal succession. That’s Profit and Profile, with plenty of Practice thrown in as I experiment with publishing and marketing.

NonProphet is a much newer project: a website and set of social media accounts looking critically at claims that Old Testament passages predicted events in the life of Jesus. At the moment, it’s mostly Practice and Profile. It’s an excuse to experiment with automated content production and social media formats while writing about something I find interesting. I don’t currently have much of a plan for making money from it.

Then there’s Oneirina, my increasingly elaborate experiment in creating and releasing music with generative AI. An album came out last week, which means there’s now the entirely different problem of working out how to persuade people to listen to it. That’s mostly Practice and Profile too: I’m learning an enormous amount about music distribution, promotion, video and AI tools.

Perl School is my small publishing house, specialising in books about Perl and related technologies. Next week I want to devote a day to looking at the business as a whole: the books already published, the ones in development, and what I can do to turn it into a more substantial source of income. It's an interesting Three Ps project because publishing obviously has potential for Profit, producing books involves plenty of Practice, and every new title helps build both the Perl School brand and my own Profile.

There are plenty of other projects too, at various stages of completion.

That’s one of the useful things about the Three Ps. It doesn’t tell me what to work on. It gives me a way to interrogate why I think something deserves my time.

2020 Vision, revisited

There’s one other thing I’ve noticed while thinking about all of this.

My 2020 Vision didn’t entirely fail.

The first project I worked on, back in January 2020, was the Line of Succession.

It’s still running.

In fact, over the last few weeks I’ve been putting more effort into it than I have for years: improving the site, building the newsletter and experimenting with ways that it might actually generate some useful income.

Six and a half years after I gave it its allotted month, I’m still finding out what that project might become.

Perhaps that was the real problem with 2020 Vision.

I assumed that a month would tell me whether an idea was worth pursuing.

But projects don’t necessarily work like that.

They can go quiet. They can change direction. Something that starts as Practice can become Profile. Something that builds Profile can eventually turn into Profit. An idea you abandon can suddenly become interesting again years later.

So perhaps I’m still following my 2020 Vision after all.

I’ve just stopped expecting it to run to a timetable.

And I’m still doing one thing at a time.

I’ve simply changed what I mean by “a time”.

How do you decide what to spend your time on? Could this framework be useful to you?

Until next time,

Cheers,

Dave…

P.S. There’s a certain irony in writing an entire post about Profit, Practice and Profile while giving you no way to contribute to the first of those.

So, as part of today’s experiment, I’ve switched on paid subscriptions for One Thing at a Time.

Nothing else is changing. I have no plans to put posts behind a paywall. If you enjoy reading this for free, please carry on doing exactly that. But if you particularly enjoy the newsletter, find some of my experiments useful, or simply want to support what I’m doing, you now have that option.

And here’s the interesting bit. Before I’d even switched payments on, two people had already pledged to become paid subscribers.

So One Thing at a Time became a revenue-generating project the moment I pressed the button.

I guess we can put a tick next to Profit.

I recently posted this image to social media with a caption saying I had received proof copies of “real” books. I got some mild pushback from people wondering if they counted as real books if they had a large amount of AI input.

I hope it’s obvious that I meant “real books” as opposed to ebooks - which is what I’ve mostly been publishing over the last decade. But the conversation got me wondering about what people consider an appropriate level of AI assistance when publishing books. Everyone draws the line at different points, of course. Let me explain where I draw it. Actually, as you’ll see, I think it can be drawn at different points for different projects.

The first thing to consider is the content of the book. There are a number of ways you could use an LLM to help create the actual text and images inside the book.

• You could brainstorm the subject with the LLM and use it to come up with a list of subjects you need to cover. The equivalent for a novel would be using the LLM to sketch out the skeleton of the plot.

• You could use the LLM to actually produce the text that makes up the book. And, having done that, you could make various levels of manual edits in order to give the text something that is closer to your voice.

• Or you could do the opposite. You could write the text yourself and then ask the LLM to proofread it, to ensure that your grammar was accurate and your prose makes sense.

• Then there’s graphics. You could use an LLM to create images to illustrate your book. Or to produce the cover.

Let’s look at the three books in the photo.

On the left, we have What to Ask Your Website Company. I’m hoping this is going to become something that introduces me to potential clients. The idea is that it helps small businesses work through the process of working with a web design company to get a website that they’re happy with. It contains checklists of questions that they should ask to avoid the kind of cowboy companies that I’m sure we’ve all come across. And there’s an offer that, if the book isn’t enough, they can engage me to manage the project for them. For this, I knew the kinds of things that I needed to cover, but I was happy to brainstorm the concept with ChatGPT to ensure that I had everything covered. It’s also a very visual book. It contains about a dozen images that were generated for me by Midjourney. As was the cover.

In the middle, we have Reimagining Diana. This is based on an experiment I carried out last year. I wanted to know if ChatGPT was capable of following a thread for long enough to create a novel. It turned out that it wasn’t. So we tried again by asking it to map out the plot first and then writing the novel a chapter at a time, sticking closely to the plot outline. This second attempt was rather more successful, and it’s that version that has ended up on Amazon. The cover was generated using ChatGPT. I suspect this is the book that will have the highest proportion of you thinking I’ve gone too far down the AI route.

Then, on the right, we have Design Patterns in Modern Perl - the latest book from Perl School Publishing. This isn’t written by me; it’s by Mohammad Sajid Anwar. And, to be honest, I don’t know how much use he made of AI while writing it (I strongly suspect none). Maybe I should ask the Perl School authors to declare that. But, honestly, if we get good books, I’m not sure how much I care. Oh, if you look carefully at the cover of this book, you’ll see there’s a light green pattern traced out. Mohammad sent me that, and I think he said he had asked ChatGPT to generate that for him. The rest of the cover (the layout of the text and the logo) is all down to my own meagre design skills. It’s pretty much the same layout that I’ve been using since long before any of us had heard about LLMs.

Another example. I’m (still!) working on the second edition of Data Munging with Perl. For various reasons, I’ve been working on it in a very disjointed fashion, which means I sometimes forget what I’ve done and what is left. The last time I returned to it, I generated a PDF from the most up-to-date version I had, handed that to Claude and asked it what still needed to be done to update the book to modern Perl - and it gave me a to-do list. I’m not going to ask the LLM to write any of the updates, but it’s steering how I work on the book. Oh, and yes, I got ChatGPT to draw the robot on the new cover.

So, the Data Munging example shows that LLMs can be useful, even if you’re not using them to actually create the content. They can be useful for planning your work. But the books in the photo are the result of another use I’ve recently found for an LLM in the publication process.

Claude Cowork makes a cracking publisher’s assistant.

Until now, most of the books I’ve published have been ebooks. That’s for a number of reasons (that we’ll get into below), but one of the most important is that it’s far easier to format a manuscript for an ebook. Grab any book from your bookshelf and browse through the bits at the start of the book. That’s called the “front matter”. It’s the bits that come before the book really starts. You’ll find a half-title page (that just contains the title), a title page (containing the title and the author’s name), a copyright page (including all sorts of obscure publication details), a table of contents and, perhaps, a dedication.

Of course, you don’t need to have all of those pages. But if you want people to think they’ve got a “real book” in their hands, then those extra pages all signal that this book has gone through a proper publication process.

Then there are the pages that make up the content of the book. The sections and chapters. The chapters all start on a right-hand page (called “recto” in publishing parlance). Odd- and even-numbered pages have different headers - book title on the even-numbered (“verso”) pages and chapter title on the odd-numbered (“recto”) pages. And the header might be skipped on the first page of a chapter. The page numbers go in the footer - but they’re left-justified on verso pages and right-justified on recto pages.

Again, this isn’t all essential. But it all makes the book look more professional. We’ve been trained to expect books to be formatted that way. If you have a book that you’ve always thought looked a bit off, then take a closer look. I’ll bet it’s missing one or more of the features I’ve just mentioned.

And getting all of that right is not trivial. It takes a lot of trial and error. But that’s where Claude Cowork comes in (I bet other LLMs can do this too). It was Claude who explained all of these requirements to me. And it was Claude who, within a couple of hours of work, had taken Mohammad’s Markdown files and turned them into a PDF that I could upload directly to Amazon’s Kindle Direct Publishing (KDP) system. Honestly, I think it saved me a week of work. And, because I’m a developer (and Claude knows that), it gave me a shell script that can regenerate both the ebook version and the paperback print-ready PDF. Which is, of course, now wired into a GitHub Action that fires whenever the input files change.

And the books look great. Feel free to buy one and have a closer look.

Last minute update: Before I move on from this subject (and onto another, closely related one), I just wanted to point out that I’ve been making some real progress on the second edition of Data Munging with Perl over the last week. I know it has taken rather longer than I originally promised, but you can buy the “work in progress” version from LeanPub and I hope to have the finished version available in a couple of months. I’ve even relaunched the book’s web site at datamungingwithperl.com.

Why publish paperbacks?

You might be wondering why I’m suddenly publishing loads of paperbacks. When I was interviewed by brian d foy about Perl School for Perl.com in 2020, I was pretty adamant that Perl School was an ebook-only publishing house. What has changed? A few things.

Firstly, and most importantly, ebooks haven’t changed the world in quite the way I thought they would. While I’ve been pretty much ebook-only for over a decade, I seem to be a bit of an anomaly. There are still plenty of people (the majority, I think) who want paper books that they can put on their shelves. To be fair to myself, I never thought ebooks would take over in the popular fiction category, but I expected that technical books would be one area where they would quickly become dominant. I was wrong. What has actually happened is that the technical books industry has become a shadow of its former self as people turn to websites and videos instead of books that are often out of date before they hit the bookshop shelves.

Secondly, I don’t often get to talk face-to-face with Perl School customers, but on the few occasions that has happened over the last five or six years, someone has always specifically asked for a paperback edition of one of the books. Sometimes it’s because they just like physical books, but, often, it’s because they find physical books easier to read for some reason. I want Perl School books to be as accessible as possible, so I’ve known for a while that I needed to look into this at some point.

Thirdly, the economics have changed. In that Perl.com interview, I talked about how it was easy for Perl School to publish an ebook, without all the upfront costs of a traditional publisher. Well, that has pretty much become true for paperbacks too. Amazon’s KDP system now has an interface with an international print-on-demand service - and that’s what I use to print the paperbacks. It’s just a case of uploading a print-ready PDF of the manuscript (and remember what I wrote above about Claude making that incredibly easy).

And, finally, there’s Mohammad. Mohammad is the author of Design Patterns in Modern Perl (as seen above). We published the ebook edition back in November 2025, but I always got the impression that he wouldn’t consider himself a “real” author until he held a physical copy in his hand. So, soon after the ebook was released, I promised him a paperback copy “in a few months”. Which is why I made the effort to get it out a couple of months ago. And, honestly, he seems far more excited about the paperback than he did when the book was originally published for the first time. He has certainly told more people about it this time - even building a website about it.

All in all, I feel I’ve learned a valuable marketing lesson here - “you are not your customers”. I was sure that Perl School’s target audience would want ebooks because they were all like me - and I wanted ebooks. It turns out that’s not true, and the only way to find out what your customers want is to actually ask them. What a radical idea!

So there will almost certainly be more Perl School paperbacks in the future. I certainly want a paperback edition of Data Munging with Perl. And I might well revisit some of the older books too. Have I mentioned I’m also setting up a wider technical publishing house called Clapham Technical Press? That’s how my book, GitHub Actions Essentials was published. Maybe some of those books need to be paperbacks too.

And maybe this time next year we’ll all be millionaires.

Some blog posts

Usually, I like to include links to a few blog posts that I’ve written since the last newsletter. But because it’s been six(!) months this time, there have been quite a few of them. Here is a selection:

• Still on the [b]leading edge

• Writing a TOON Module for Perl

• The Long Road from CGI to Containers

• Teaching AI About the British Monarchy with MCP

• Choosing the Right Database Abstraction

• The Future Isn’t Evenly Distributed

The one about MCPs is going to be turned into an online presentation for Perl Maven in October. Registration is already open.

The two on “CGI to Containers” and “Database Abstraction” form a matching pair about how the recent history of programming is largely a story of moving our abstractions to higher and higher levels. I’m considering using them as the basis of a talk at the London Perl Workshop this year.

But, of course, what’s more interesting is other people’s blog posts. Here are a few that I particularly enjoyed:

• I Went on Maternity Leave and Came Back to a World of Vibe Coding
  Irina was a colleague many years ago. This post amused me, but also had me wondering how many other women had got back to work after maternity leave to find the industry had completely changed while they were away

• Eight years of wanting, three months of building with AI
  An interesting example of how AI-aided coding can be a force for good. I have so many new little tools that I would never have got round to writing if I had had to do it all myself

• Highlights from my conversation about agentic engineering on Lenny’s Podcast
  Sometimes when the speed of change in the industry gets too much for me, I just go looking for Simon Willison’s most recent blog post that includes some kind of summary that he’s been asked to present. It always helps

• I got a private lesson on Claude Cowork & Claude Code
  How Boris Cherny, the inventor of Claude Code, uses his invention

• Learn How to Write Production-Quality Code with AI
  Curtis Poe is an old friend from the Perl community and one of the few people who seems to be working hard to port the “engineering” part of Software Engineering to AI-aided coding

Something completely different

All work and no play and all that…

I’ve mentioned Oneirina, my AI music project, previously. I continue to work on her music in my spare time. She now has a website (oneirina.com) that I’m pretty pleased with. I’ve also started making videos for her songs - so she has a YouTube channel too.

And songs from her debut album are starting to be released on Spotify.

That’s all for now. Tomorrow, I’m off to the Edinburgh Fringe Festival for a few days. But I’ll be back with another newsletter in (hopefully) a few weeks.

Cheers,

Dave…

I shouldn’t speak too soon - this is only the third monthly newsletter. But I’m happy to hit even that small milestone.

So what’s been happening in February?

Perl School Publishing

This is where I should be concentrating my efforts. And I’m certainly doing useful work in this area.

The first month’s royalties for Design Patterns in Modern Perl arrived. It’s not going to change Mohammad’s way of life, but I think he was pleasantly surprised at the amount of money he got.

I spent some time working on getting a dead tree version of Design Patterns ready. It’s not quite there yet, but it’s getting close. And, hopefully, once I’ve solved the problem for one book, I’ll have processes in place to make it easy to do the same for other Perl School books.

The other big project there is, of course, the second edition of Data Munging with Perl. I’m still making progress, but not at the rate I’d like. I’ve set myself a target, but I’m not going to tell you what that is - so you won’t laugh (or shout) at me when it sails past. It doesn’t help that I’ve had an idea that slightly pivots a previous writing project and has really excited me. I’ve told myself I can’t start working on it until Data Munging has been published.

When I first started using the “Perl School” brand (for training in 2012), I registered the .co.uk version of the domain. I mentioned that in a few blog posts at the time. But I soon realised the .com version was also available, so I bought that too. I kept them both for a while (redirecting the .co.uk to the .com), but three or four years ago, I decided to cut back on the domains I owned and let the original (.co.uk) version lapse. Last week, I saw a comment on one of those old blog posts, asking if I had fallen on hard times, because a link to the old domain now displayed a porn site. I guess I should be flattered that a porn gang thought the domain was valuable enough to register and hijack!

Line of Succession

I hadn’t done much work on the Line of Succession site since I redesigned it last year. So it was about time it had a bit of love. So I turned my attention to it for a few days.

Last year, I discovered WikiData, a site that provides machine-readable data about… well, about pretty much everything. I wish I had known about it when I was first filling in the data for Line of Succession six years ago. Back then, I spent many Sundays copying data from Wikipedia into my database. If I had known about WikiData I could have probably automated most of that.

But there’s always more data that can be added. And it’s always a good idea to ensure the data I have is still up to date.

So I’ve written a program that uses WikiData to audit my database. It looks for things like missing death dates and missing children (so I don’t have to spend time poring over the society pages to check for births and deaths). It will even fix many of these problems automatically. It will also help me push my data back in time - as it looks for missing parents and will insert those records based on the information stored in WikiData.

I’ve written a GitHub Actions workflow that runs the audit program every day and produces a report of potential problems. Currently, I don’t let it fix things automatically, but that’s bound to follow as my confidence in the program grows.

I’ve also tried to increase the rate at which I publish articles on the Line of Succession newsletter. If you have any interest in the British royal family, you might like to subscribe to that.

Web servers and directory listings

Back in January, I wrote a blog post about App::HTTPThis, a CPAN module I maintain that runs a simple static web server. I find it invaluable when I’m working on a static website (which is a surprisingly high amount of time).

The blog post led to a slight uptick in interest in the module and I ended up doing a bit more work on it. In particular, I took the code which generates a directory listing and split it out into a separate module (WebServer::DirIndex) in the hope that other people doing similar work could use the same code.

One interesting thing about this project was the way that I wrote almost no code for it. I created issues in the GitHub repo and assigned those issues to GitHub Copilot. A few minutes later, a pull request would show up and I would review it and (usually) merge it without any problems.

I was so impressed by how well this went that I wrote a blog post about it:

• Treating GitHub Copilot as a Contributor

Maybe a similar workflow would work for you, too.

Contributing to GitHub Marketplace

I’ve used GitHub since soon after it first appeared. I like to keep up to date with its newest features. I’ve even written a book about GitHub Actions (that probably needs to be updated - I wonder when I’ll have time to do that). But I had never written anything that was available from GitHub Marketplace.

Until yesterday.

Like most good Open Source tools, it does one simple thing. And it scratches a personal itch.

I have a lot of projects on GitHub - I mean hundreds. And I’m a firm believer that a good project should have a website. But when you have hundreds of projects, it’s impossible to maintain that number of websites.

But, many of those projects will already contain a file that could function as a simple, one-page website for the project - the README.md.

I wanted an easy way to take a README.md, convert it to index.html and publish it to GitHub Pages. You can do this with Jekyll, of course, but sometimes, bringing in a whole Static Site Generator ecosystem can feel like overkill.

So, that’s what readme-to-index does. It:

• Installs Pandoc in your workflow environment

• It uses Pandoc to convert your README.md to index.html

• By default, it uses Simple.css to make the page look nice

• It publishes that page to GitHub Pages

I wrote a blog post going into more detail - Your README Is Already a Website

KeepAChangeLog on MetaCPAN

I like the idea of using industry standards wherever possible. And I think that sometimes the Perl community prefers its own standards to more widely-recognised ones.

One example is change logs.

There’s a CPAN module called CPAN::Changes that defines a specification for change logs and then parses logs in that format. It’s used on MetaCPAN to present change logs in a very readable fashion.

But there’s an alternative standard called Keep A ChangeLog. And, because that format is widely-used in open source projects, it’s the format I like to use. However, MetaCPAN doesn’t recognise that format, so my change logs get presented in a less satisfactory manner.

• CPAN standard example change log

• Example of one of my change logs

Last April, I raised an issue asking for support for the Keep A ChangeLog format. And volunteering myself to implement it. And then promptly forgot about.

I was reminded a few weeks ago, when Olaf Alders posted a comment on that issue, asking if I was still planning to work on it.

That galvanised me into doing something. I’ve now released CPAN::Changes::Parser::KeepAChangeLog, which parses a Keep A ChangeLog-style file and produces a standard parsed change log object. I’m hoping that can be injected into the MetaCPAN page build process to display my change logs in a nice manner. But that’s a project for later this month.

We ❤️ the NHS

At the end of January, I had some routine blood tests, and some of the numbers came back slightly higher than my doctor was happy with. This led to a series of repeated tests, phone calls and a referral to a local hospital for some slightly deeper tests.

I’m sure I’m fine, and this is just my doctor ensuring that no possible avenue is left unexplored. And I think that’s great. I would far rather she order too many tests than too few.

I try to keep politics out of this newsletter, but I want to go on record as saying that the NHS is one of the great things about living in the UK. It’s something I appreciate more and more as I get older.

Anyway, enough sentimentality. That’s about all I achieved in February. Looking back at what I’ve just written, it seems rather more than I thought at the time. I guess that’s a good thing.

How about you? What achievements from February are you particularly proud of?

I’ll be in touch again in about a month.

Dave…

Welcome to 2026. What have you all been working on? Let me give you a bit of an overview of my month.

In-house training

I used to have a nice little sideline in in-house Perl training. But as fewer and fewer companies used Perl, it slowed down and, eventually, died off. For a few years, I assumed that part of my career was behind me.

But it’s had a late surge.

Just before Christmas, I got an email from an old friend from the London Perl Mongers, asking if I could give some Perl training to a few employees at his company. I, of course, agreed. I’ve done two days for them and I’m going back again next week.

All of which has made me think there might be other people out there who could also benefit from this training. In order to tempt those people into contacting me, I’ve put together a page where I’ve started to gather the slides from the large number of training courses I’ve run in the past. It’ll take a while (not least because my filing system has not been great in the past), but it’ll be worth a look, I hope.

If you think this could be useful to you, then please get in touch (just reply to this email).

Perl in TIOBE

Did you know that TIOBE stands for “The Importance of Being Earnest”? I’m not sure what the connection between Wilde’s play and a software popularity index is.

For about twenty years, there has been a lot of commentary in the Perl community over the TIOBE index. Many people have expended a lot of time and energy explaining why the TIOBE index doesn’t measure anything useful. This is because, over that time, has been showing a dramatic fall in interest in Perl.

Those complaints have stopped now.

That’s because, over the last year or so, Perl has been rising up the index again. Which is, to be honest, slightly surprising. But the rise is undeniable. In January 2025, Perl was at #25 in the index. In January 2026, it was at #11.

TIOBE only ever make the current month’s data available, which includes a comparison to the data from a year earlier. And because people often don’t realise that, we’ve had a year of “Perl leaps 20 places!” posts in r/perl. In order to attempt to counter that, I’ve put together a page that contains the data going back as far as I’ve managed to find it (which is, sadly, only to mid-2015). It would be great ot have the data going back further than that - but at least it gives some context to the currently monthly figures.

I still have no idea why Perl is suddenly doing so well, though. If you have any theories, I'd love to hear them.

Line of Succession work

I mentioned in the last newsletter that I’ve been doing some work on Line of Succession. This is all triggered by my desire to move it off my rented VPS and into the cloud. This means I want to make it as slim as possible, so cloud charges don’t cripple me.

One thing I did was to move the database from MariaDB to SQLite. The tables are all pretty small, and a permanent database server is one of the things that can really rack up the cloud costs. I should point out that this only works because the database here is totally read-only. The line of succession only changes three or four times a year and, when it does, I update a local copy of the database and upload that to the production server.

This was great, but I started to notice some outages on the app (thanks to PrettyGoodPing). It turned out that the system was running out of open filehandles. So the quick fix was to increase that to a huge number while I tracked down the real culprit. I soon worked out that I was assuming there was one persistent database connection per process - and that wasn’t the case. This was fine when I was using MariaDB, but for SQLite, each open connection is an open filehandle. Half an hour of investigation showed me where the problem was, and now the system runs forever without running out of filehandles.

Perl Ad Server

I run the Perl Ad Server - which is a simple way for people to add adverts for Perl community announcements to their websites. It’s been running for a while now and I had never really given much thought to the website that tells people what it is and how to use it.

Then Olaf Alders got in touch and asked if I would like to try out a new AI prompt/skill that he had developed (based on a blog post by Anil Dash). The idea is that you craft your text so that people are able to accurately (and accurately!) repeat your messaging, even when you aren’t around.

When looking at a project to try it out on, I thought of the Perl Ad Server. I fired up ChatGPT, gave it Olaf’s prompt and pointed it at the Ad Server’s web page. Within half an hour, I had the copy that you see on the page today. It’s a vast improvement on what was there before.

Dave Knows London

Later this year, it will be 46 years since I moved to London. I came here to go to university and just never left. In that time, I like to think I’ve walked most of the streets - certainly in Zone 1, maybe further out.

I’ve often thought that in an alternative universe, I could be a successful tour guide.

And now, I’ve dipped my toe into testing that theory. I’ve set up a website (using Substack) called Dave Knows London, where I plan to share my knowledge of London over the coming months. I’m also publishing PDFs of self-guided tours through interesting parts of London. The first one (a walk along the river from London Bridge to the Royal Festival Hall) is already available on Gumroad.

I wonder if anyone reading this newsletter was at the first YAPC Europe in London in 2000. As part of the evening entertainment, I took a group of people on a pub crawl along the Thames. That was basically this walk - but in reverse.

Domains & Substacks

I used to be a bit of a domain hoarder. You know, the kind of person who has a great idea for a side-project and buys the domain before writing any code. And then (in at least 50% of cases) never writes the code. Let me know if that sounds at all familiar.

I’ve got better recently, though. Since 2020, I’ve made a determined effort to let a load of domains lapse. I still have too many, but it’s a manageable number. That’s why I wrote the domain management tool that I mentioned in the last newsletter[*].

But I may have replaced that with a new vice - collecting Substacks. And I don’t mean Substack subscriptions (surely, we all do that - let me know if you have one and I’ll subscribe). No, I mean actual Substacks that I own.

In case you want to subscribe to the full set:

• One Thing at a Time - this one. You’re probably already subscribed

• Line of Succession - posts about the British royal family (and I’m still slightly puzzled how I became an expert on that)

• The Horsell Transmissions - my emerging novel, telling the story of The War of the Worlds from the perspective of the Martians

• Dave Knows London - as mentioned above. Still getting going

[*] And note that’s living on a subdirectory of an existing domain. In the past, that would have been on its own domain - that’s a sign of me getting better.

An intriguing series of posts

I like to mention at least one project that isn’t mine. And, today, it’s an intriguing series of blog posts from my old friend James Duncan. The point is to introduce his new project Pagelove. He has certainly piqued my curiosity.

1. The Hollow Web

2. The Cost of the Shell

3. Taking Documents Seriously

4. The Shape of Pagelove

The adverts

I’ve talked about my rejuvenated enthusiasm for in-house training. But that’s not the only way I could, perhaps, help you. Take a look at my services page and let me know if there’s anything there that interests you.

That’s all for this time. See you in a month (or so!)

Dave…

[The amount of time between newsletters continues to amuse and embarrass me in equal measures. I knew I had a draft newsletter that I wanted to finish and send out before the end of the year. I was surprised to find the draft dated from the middle of September!]

The title of this newsletter is supposed to remind me that it’s easier to make progress on a project if you only work on one thing at a time. The contents of this edition will be an object lesson in how bad I am at sticking to that.

Data Munging with Perl (2ed)

I am still making progress on this. But I’m embarrassed when I think of the talk I gave about it at the last London Perl Workshop, where I suggested it might be available at around Christmas. Luckily, I didn’t say which Christmas.

I have made progress on it though. In particular:

• Working on the chapter that used to be called “Hierarchical Data”. It used to cover HTML and XML. The new version will cut down on the XML content and replace it with coverage of JSON and YAML. I’ll publish a blog post soon that contains an extract from the new version of this chapter.

• I got a few reports from LeanPub that the “work in progress” version isn’t working very well for some people. I dug into that and it turns out that the EPUB document that I saved from Google Docs isn’t a particularly standards-compliant EPUB. I’ve been working on a new production pipeline where I download a DOCX version and convert that to EPUB using Pandoc. That seems to be working better.

And let me briefly remind you of the existence of the work-in-progress version. You can buy that now from LeanPub and you’ll get access to all updates - including the finished version when it arrives. That’s very useful for me, as I get to iron out little problems like the one I described above before I publish the final version.

Design Patterns in Modern Perl

I did publish a book, though. My good friend, Mohammad Sajid Anwar, approached me in the autumn and asked if I would be interested in publishing his book, Design Patterns in Modern Perl. If you know Mohammad’s work from Perl Weekly or The Weekly Challenge, then you’ll understand why I leapt at the chance.

We managed to get the book published on both LeanPub and Amazon just in time for Mohammad to announce it at the end of his talk at the London Perl Workshop. In working on turning his Markdown into an ebook, I took the opportunity to update my rather dated publication pipeline, and I wrote a blog post about that - Behind the Scenes at Perl School Publishing.

Mohammad tells me his next book is almost ready (and he has another in progress behind that). I suspect we’ll be renaming Perl School to “Anwar Books” before the end of 2026.

Improving websites

If you’ve followed my work for a while, then you’ll know that I run a lot of websites. At some point, they were each going to be the big, successful project that would make me ridiculous amounts of money and stop me from needing to work for a living. Of course, it never quite worked out like that.

Part of the problem (or, at least, as far as I can see) is my limitations as a web designer. I was delighted ten years ago when I discovered Bootstrap and realised my websites didn’t need to look quite as bad as they originally did. But, eventually, I began to realise that while my sites no longer made me want to scratch my eyes out, their design still left a lot to be desired.

Luckily, ChatGPT is pretty good at website design. So, together, we started a project to improve the look of many of my websites. Let me show you an example.

Read A Booker

This is how Read A Booker looked a few months ago. It’s a site that lists all of the shortlisted titles for the Booker Prize over the years. Of course, it’s just a way to encourage people to buy the books using my Amazon Associates tag. But it doesn’t really work when the site looks as uninteresting as that.

And here’s what it looks like today. Nothing has really changed in the structure of the site, but it just looks that little more enticing. It looks like a “real” website (whatever that means). The other pages all have similar improvements.

Oh, and as part of that project, ChatGPT also helped me write a little Javascript library that adjusts Amazon links and buttons so they automatically go to a visitor’s nearest Amazon site.

Line of Succession

ChatGPT has also helped me make some improvements to the Line of Succession website. This is a site that started as an intellectual puzzle and has grown into my most successful website. It’s a site that allows you to pick a date in the last 200 years and will show you the line of succession to the British throne on that date. It’s pretty niche, but it gets a reasonable amount of traffic each month. The British royal family are obviously still of great interest to a large number of people.

Over the last few months, my work on this site has been in three main areas:

• The site has been given a lick of paint. It’s still Bootstrap underneath, but it now looks far more professional

• I’ve done some work on the underlying data. Obviously, I know from the news when someone near the top of the list is born or dies. But it would be easy to miss changes further down the line. With help from ChatGPT, I’ve developed some code that queries WikiData and looks for births, deaths and other changes that aren’t already in my database. Later on, I think I can reuse a lot of that code to push my data further back in time

• The site is driven by a Dancer2 app that queries an SQLite database and builds the line of succession for a given date. This isn’t particularly efficient and I’ve started redesigning it so the line of succession is precomputed and stored in the database. This will make the site much quicker. This work is ongoing

Moving to the cloud

I still run a lot of my web apps on a VPS. This makes me feel like a dinosaur. So I’ve been moving some of those apps into the cloud. I wrote a blog post about my experiences.

• Dancing in the Clouds: Moving Dancer2 Apps from a VPS to Cloud Run

And then, because some people aren’t starting with nice, PSGI-compliant apps, I wrote another blog post explaining how you could also do that with crufty old CGI programs.

• Elderly Camels in the Cloud

Some silly toys

I’ve written before about how AI-assisted programming means a lot of little projects I wouldn’t previously have had time for are getting ticked off. Another version of that is fast becoming a good way to get bugs fixed in my software:

• Raise an issue in the GitHub repo

• Assign the issue to Co-Pilot

• Wait 20-30 minutes for the pull request to arrive

And most of the time, I’m finding that those PRs are of very high quality. Any problems can often be traced to deficiencies in my specification :-)

Here are a couple of toys that I’ve recently written that someone else might find useful:

• Dave’s Dry January Tracker - an older project, but it’s had a revamp for 2026

• MyDomains - I’m getting over my domain buying habit, honestly! But this helps me track the ones I still have

Feeding my soul

But I can’t work all the time. I need to soak in a bit of culture too - whether that’s consuming or creating. And I have plans to do more of both next year.

Consuming

• Film - for some reason I’ve seen about half as many films in 2025 as I did in 2024. I just got out of the habit. It’s a habit I plan to resurrect in 2026. Feel free to follow me on Letterboxd.

• Books - I used to be a voracious reader, but I’ve barely finished a book since the pandemic in 2020. You can follow my attempts to read more on Goodreads.

Creating

• I’ve written a couple of short stories that I’ve published on Medium.

  • The Tourist

  • MS Fnd in a Modl

• I’m experimenting with a long-form piece of fiction based on The War of the Worlds.

  • The Horsell Transmissions

• I’m no musician. But I’m enjoying the possibilities that AI music creation is bringing me. My main project is an artist called Oneirina (that’s her at the top of this newsletter). She’s on Spotify, too. I don’t pretend it’s deep or meaningful, but I think it’s fun.

Anyway, that’s a wrap on 2025 (especially for those of you who are in Australia or New Zealand), I think. I’ll see you in 2026.

Happy New Year,

Dave…

When I started to think about a second edition of Data Munging With Perl, I thought it would be almost trivial. The plan was to go through the text and

1. Update the Perl syntax to a more modern version of Perl

2. Update the CPAN modules used

And that was about it.

But when I started looking through the first edition, I realised there was a big chunk of work missing from this plan

• Ensure the book reflects current ideas and best practices in the industry

It’s that extra step that is taking the time. I was writing the first edition 25 years ago. That’s a long time. It’s a long time in any industry - it’s several generations in our industry. Think about the way you were working in 2000. Think about the day-to-day tasks you were taking on. Think about the way you organised your day (the first books on Extreme Programming were published in 2000; the Agile Manifesto was written in 2001; Scrum first appeared at about the same time).

The first edition contains the sentence “Databases are becoming almost as ubiquitous as data files”. Imagine saying that with a straight face today. There is one paragraph on Unicode. There’s nothing about YAML or JSON (because those formats both appeared in the years following publication).

When I was writing the slides for my talk, Still Munging Data With Perl, I planned to add a slide about “things we hadn’t heard of in 2000”. It ended up being four slides - and that was just scratching the surface. Not everything in those lists needs to be mentioned in the book - but a lot of it does.

When working on the book recently, I was reminded of how much one particular section of the industry has changed.

The problem of screen-scraping

The first edition has a chapter on parsing HTML. Of course it does - that was cutting edge at the time. At the end of the chapter, there’s an extended example on screen scraping. It grabs the Yahoo! weather forecast for London and extracts a few pieces of data.

I was thinking ahead when I wrote it. There’s a footnote that says:

You should, of course, bear in mind that web pages change very frequently. By the time you read this, Yahoo! may well have changed the design of this page which will render this program useless.

But I had no idea how true that would be. When I revisited it, the changes were far larger than the me of 2000 could have dreamed of.

• The page had moved. So the program would have failed at the first hurdle.

• The HTML had changed. So even when I updated the URL, the program still failed.

• And. most annoyingly, the new HTML didn’t include the data that I wanted to extract. To be clear - the data I wanted was displayed on the page - it just wasn’t included in the HTML.

Oh, I know what you’re thinking. The page is using Javascript to request the data and insert it into the page. That’s what I assumed too. And that’s almost certainly the case. But after an afternoon with the Chrome Development Tools open, I could not find the request that pulled the required data into the page. It’s obviously there somewhere, but I was defeated.

I’ll rewrite that example to use an API to get weather data.

But it was interesting to see how much harder screen scraping has become. I don’t know whether this was an intentional move by Yahoo! or if it’s just a side effect of their move to different technologies for serving this page. Whichever it is, it’s certainly something worth pointing out in that chapter.

Other writing

I seem to have written quite a lot of things that aren’t at all related to the book since my last newsletter. I wonder if that’s some kind of displacement therapy :-)

I’m sure that part of it is down to how much more productive I am now I have AI to help with my projects.

• Cleaner web feed aggregation with App::FeedDeduplicator explains a problem I have because I’m syndicating a lot of my blog posts to multiple sites (and talks about my solution).

• Reformatting images with App::BlurFill introduces a new CPAN module I wrote to make my life as a publisher easier (but it has plenty of other applications too).

• Turning AI into a Developer Superpower: The PERL5LIB Auto-Setter - another project that I’d been putting off because it just seemed a bit too complicated. But ChatGPT soon came up with a solution.

• Deploying Dancer Apps – The Next Generation - last year, I wrote a couple of blog posts about how I deployed Dancer apps on my server. This takes it a step further and integrates them with systemd.

• Generating Content with ChatGPT - I asked ChatGPT to generate a lot of content for one of my websites. The skeleton of the code I used might be useful for other people.

• A Slice of Perl - explaining the idea of slices in Perl. Some people don’t seem to realise they exist, but they’re a really powerful piece of Perl syntax.

• Stop using your system Perl - this was controversial. I should probably revisit this and talk about some of the counterarguments I’ve seen.

• perlweekly2pod - someone wondered if we could turn the Perl Weekly newsletter into a podcast. This was my proof of concept.

• Modern CSS Daily - using ChatGPT to fill in gaps in my CSS knowledge.

Other people’s writing

• How Google used generative media at I/O 2025

• My AI Skeptic Friends Are All Nuts

• Building software on top of Large Language Models

• Pete thinks he can help people sort out their AI-generated start-up code. I think he might be onto something!

The Substack conversation

Like most people, when I started this Substack I had an idea that I might be able to monetise it at some point. I’m not talking about forcing people to pay for it, but maybe add a paid tier on top of this sporadic free one. Obviously, I’d need to get more organised and promise more regular updates - and that’s something for the future.

But over the last few months, I’ve been pleasantly surprised to receive email from Substack saying that two readers have “pre-pledged” for my newsletter. That is, they’ve told Substack that they would be happy to pay for my content. That’s a nice feeling.

To be clear, I’m not talking about adding a paid tier just yet. But I might do that in the future. So, just to gauge interest, I’m going to drop a “pledge your support” button in this email. Don’t feel you have to press it.

Subscribe now

That’s all for today. I’m going to get back to working on the book. I’ll write again soon.

Dave…

Building websites (easily)

But it looks like I’m on a roll. I have a few things I want to share with you. I’ve been down a bit of a rabbit hole thinking about the various different ways that websites are built these days.

Over the last few months, I’ve become lightly involved with the Clapham Society - that’s a local group that spreads news about life in Clapham and gets involved in campaigning against things that are likely to have a negative effect on that life.

They wanted a new website. Now, I know a bit about how websites work, but I’d never describe myself as a web designer and I just don’t have the capacity to get involved in a project that needs to move a lot of content from an old website to a new one. But I had some conversations with them about what they were looking for in a new website and I helped them choose an agency that would build the new site (they went with Agency for Good, who seem to be very… well… good!) I also helped out wrangling their old domain name from their previous web hosting company and helped them get set up on Google Workspace (using a free account from Google for Nonprofits).

Anyway… that all went very well. But I started thinking about all of the horror stories you hear about small businesses that get caught up with cowboy website development companies and then end up with a website that doesn’t work for them, costs too much money and is hard to maintain.

And that led to me writing my Website Guide (aka “What to Ask Your Website Company”). The aim was to write in non-technical language and provide a short and easy-to-understand guide that would give small business owners[*] the information they need to make better decisions when choosing a company to design and build their website.

Yes, it’s a bit outside my usual areas of expertise, but I think it works. I’m considering turning it into a short e-book next.

I realised this had all got a bit meta. I had built a website about how to get people to build you a good website. So I decided to lean into that and wrote a blog post called “How I Build Websites in 2025” which explained the process and tools I had used to build the websites about building websites. Are you still with me?

Then, yesterday, I decided to take things a bit further. Like most geeks, I have several domains just lying around not doing anything useful and I wanted to know if I could quickly spin up a website on one of them that could bring me a bit of income (or, perhaps, get enough traffic that I could sell it on in a few months).

So in six hours or so, I built Balham.org. Well, I say “I”, but I couldn’t have done it without a lot of help from ChatGPT. That help basically came in three areas:

1. High-level input. Answering questions like “What sort of website should we build?”, “What pages should we have?” and “How do we make money out of this?”

2. Data and content. How long would it take you to get a list of 20 popular Balham businesses and create a YAML file suitable for use with Jekyll? ChatGPT did it in a minute or so.

3. Jekyll advice. I’m starting to understand Jeykyll pretty well, but this project went way beyond my knowledge many times. ChatGPT really helped by telling me how to achieve some of my goals.

We did what we set out to do. The site is there and is, I think, useful. Now we have the phase where so many projects stall (I nearly wrote “my projects” there, but I think this is a problem for many people). We need to promote the site and start making money from it. That’s probably another session with ChatGPT next weekend.

And finally on this subject, for now, at least, today I wrote a blog post about yesterday’s project - “Building a website in a day — with help from ChatGPT“.

[*] Owners of small businesses, not … well, you know what I mean!

Data Munging

I’m still working on the second edition of Data Munging with Perl. But, more urgently, I’m currently working on the slides for the talk I’m giving about the book next Thursday, 27 March to the Toronto Perl Mongers. I’m not flying to Toronto, it’s a virtual talk that I’ll be giving over Zoom. There are already over a hundred people signed up - which is all very exciting. Why not join us? You can sign up at the link below.

• Dave Cross: Still Munging Data with Perl

The book will be out as soon as possible after the talk (but, to be clear, that’s probably weeks, not days). Subscribers to this newsletter will be the first people to know when it’s published.

Anyway, that’s all I have time for today. I really need to get back to writing these slides. Thanks for taking an interest.

Cheers,

Dave…

So can I be the last person to wish you a Happy New Year? We’re eight weeks into the year. How’s it going for you so far?

Still munging data - 25 years on

Some of you might be old enough to remember my book Data Munging With Perl. Towards the end of last year, I decided it was about time to produce a second edition. It’s a book I’m proud of and I think it still contains a lot of good advice, but a lot of the actual Perl in the book is looking rather dated now and it will be nice to have a version that updates a lot of the code.

I talked about my plans in a lightning talk at the London Perl Workshop last year. At the time, I mentioned that I hoped the book would be available “by Christmas”. But then I went and took on a full-time client that rather ate into the time I had available to work on the book. So Christmas came and went without the book being published. But I’m still making progress and I hope it’ll be available before too long. I have a bit of a fixed deadline as I’m giving a talk about the book to the Toronto Perl Mongers at the end of March, and I’d like it to be available by then.

The talk will be given over Zoom and it’s free. So please feel free if you’re interested in the book. It’s on 27th March at 20:00 UTC.

• Dave Cross: Still Munging Data with Perl

Proposed Perl Changes

I’ve been part of the Perl community for far longer than I care to admit. But my contributions have mostly been non-technical. So I was surprised when a member of the Perl Steering Council contacted me at the start of the year and asked for my help working on a new website that would make it easier for the community to see upcoming changes that had been proposed for the Perl language.

The PPC process has been in place pretty much since the Perl Steering Council was formed in 2020. But it had been suggested that only having the documents available through the GitHub website means that many people who might otherwise be interested, aren’t reading the proposals. So the PSC had decided it would be useful to turn that repo into a real website. And because of my experience with GitHub Pages and GitHub Actions, I would probably be a good person to get a first draft up and running quickly.

So that’s what I did. You can read more details about how it all works on my Perl Hack blog (part 1, part 2) and you can form your own opinion on how successful I’ve been by looking at the site at https://perl.github.io/PPCs/

Other blog posts

I’ve written a few other blog posts over the last six months that you might find interesting:

• I wrote a simple ad server that allows people to add a banner advert for Perl community events to their website

• I talked about an application I’d written that provides a self-hosted (or, even better, GitHub Pages-hosted) LinkTree-like web page

• We moved the London Perl Mongers website to GitHub Pages (I’m starting to detect a bit of a theme here!)

• I explained a CPAN module I had written that makes it easy to add JSON-LD to a website

AI programming

I’ve been using various AI tools to increase my productivity. But I’m really only dabbling at the moment. Other people are obviously doing more than I am. So this article really interested me. I’m definitely going to try to incorporate some of these suggestions into my workflow.

• My LLM codegen workflow atm

I’ve also been given access to the preview version of GitHub Spark. So I’ll be trying that out over the coming weeks.

And finally…

In the past, I’ve definitely been guilty of buying domain names for projects that I only have the vaguest of plans for. But over the last five years I’ve made a determined effort to stop doing that and to let old domains lapse once it becomes obvious that I’m not going to complete the project they were bought for. I think I’ve let somewhere between a third and a half of my domains lapse.

But sometimes a domain just has to be bought.

And I realised last week that South Sudan were allowing domain registrations at the top level of their ccTLD.

So… davecro.ss.

That’s all for today. Let’s hope it’s not six months until my next newsletter.

Cheers,

Dave…

One of the original points of this newsletter was to tell people about upcoming training courses. That has been sadly lacking over recent years as I haven’t been running any public training courses since the pandemic.

But that’s all about to change. I have three online training courses coming up. And the first is in just a couple of days.

If you’ve been reading this newsletter for a while, you’ll know that I’ve been taking an interest in GitHub Actions. I even wrote a book about Github Actions last year.

If you haven’t come across GitHub Actions before, it’s basically a tool for Continuous Integration and Continuous Deployment. But it can be used for so much more than that. GitHub are allowing you to run code on their servers. Running that code can be triggered on a schedule, by an event (like a commit) in your repo or just by pushing a button on your repo’s web page.

I was interviewed by Software Engineering Radio about GitHub Actions last year.

If you’re using GitHub to store your software, then I’m sure that GitHub Actions will allow you to do something that will make your life easier.

I’m running a two-hour introduction to GitHub Actions this coming Wednesday (28 August). It will start at 15:00 UK time and will be running over Zoom. You can get full details (and book tickets) from my web site.

And that’s not all. I have two more course planned over the next few weeks. If you’re not interested in GitHub Actions, then perhaps you’re more interested in:

• GitHub Pages (11 Sep)

• GitHub Copilot (25 Sep)

Hopefully, one of these subjects will interest you.

Tickets for the courses are £49 each. But, as a subscriber to my newsletter, you can use this promo link which will give you 20% off.

I hope to see some of you online on Wednesday.

Dave…

I think I’ll stop apologising for the large gaps between these emails. In one way, I’m doing you all a favour by giving you less to read.

I will also skip the story about stealing a laptop from one of the world’s largest IT consultancies again. Maybe I’ll tell the story next time. Maybe I’ll leave it as a teaser for you all that never gets resolved. Maybe it never happened.

Today I want to talk about the difference between projects and products. This is a thought that turned up pretty much fully formed in my head a few days ago. I haven’t written it down before, but it feels important and/or useful so I thought I’d share it with you.

I’ve written a couple of blog posts recently about my “pointless personal projects”. I used to call them side-projects - but that ruined the alliteration.

• Here’s a blog post that’s even called “Pointless Personal Side-Projects”. It concentrates on the software I wrote to create my link site - links.davecross.co.uk. In it, I make the point that projects like this can be used to gain experience in new programming language features or new technologies.

• And here’s a more recent blog post about another of my projects - Combining Calendars. An important point in that post is how anyone showing the slightest interest in one of these projects can get me so excited that I’ll spend days adding new features.

These projects (and, if I’m honest, probably a dozen more) came into being because I had an itch to scratch. And, going back almost forty years, I remember that being the explanation for how most good open-source software projects got going. Someone had a problem and wrote software to fix that problem. Other people had the same problem and they got value out of using that software too.

Of course, projects that solve problems aren't all going to be open source. All software exists to solve a problem. And, if you’re lucky, people will pay you for the software that solves their problem.

And that’s when I started to wonder about the path from problem to project to product (there’s that alliteration again). The idea that popped into my head (while I was asleep) was that it’s a four-stage model.

1. In the first stage, there’s the recognition of a problem and some attempts to sketch out something that solves the problem. Here’s an example. I wrote a blog post about a program I wrote that would suggest artists that I might want to listen to. The blog post talks about a couple of iterations of the project but there were a few more after the post was written. At this point, the code doesn’t need to be good (although I have standards to meet if I’m going to include it in a blog post!) It’s just a proof of concept - demonstrating that the problem can be solved, even if we haven’t found the best solution yet. Very few of my projects stop at this stage.

2. The second stage is making the code available for other developers to read and use. These days, that means uploading it to GitHub. And because you’re making it available for other people to read, that’s going to involve cleaning up the code. This is when you become more interested in confirming that you have the best solution to the problem. You might well (certainly if you’re me) break the code down into classes, make it testable and remove any hard-coded configuration information (put it config files, accept command-line arguments or read it from environment variables - all three if you’re feeling generous). This is the point at which I’ll be thinking about including a version number. Most of my projects get to this stage. Very few of them get any further.

3. The third stage is making it available to the general public. These days, that’s probably a web app (although, I should probably investigate how easy it is to make a phone app too. In the past, it might have been some kind of desktop app but, to be honest, I’m glad those days are behind us. At this stage I’ll need about things like deployment and hosting. It’s likely that I’ll need some kind of user management system (although things like Line of Succession or ReadABooker don’t need that). This is definitely the stage that would benefit most from a checklist of things that need to be done). I kinda assumed I was bad at getting things to this stage but, thinking about it, I have quite a few projects in this state - it’s the reason why I own so many domains!

4. The final stage - the Holy Grail - is to make the it profitable. This is, of course, the hardest step. And that’s why so few projects get to this stage. First you need to decide how you monetise the site and then you have to implement that strategy. And, finally, you need to market it so you get enough users to make a profit. I know that marketting is where I fall down pretty much every time. I do get things to this stage (ReadABooker is full of Amazon affiliate links; Line of Succession has a shop page and a load of Google Ads) but none of them have the traction they need to make real money.

And there you have it. My roadmap to profitable products. I’m not saying it’s the only way to get to a profitable product, but I think it’s a workable one. And, having written this down, it’s clear where I need to address my efforts. I can’t just keep throwing projects up on the web and just expect them to find their audience. I need to get better at marketing. So even if you didn’t get anything useful out of this newsletter, I think I’ve learned a valuable lesson.

What do you think? Have you tried to turn an itch-scratching project into something profitable? What route did you take? How well did it work out?

In other news

A few other bits and pieces…

• I’ve mentioned before that I’ve been pleased with my experiments in AI-aided programming. I now have access to the beta version of GitHub’s Copilot Workspace. Where the standard version of Copilot makes suggestions in your editor while you’re working, Copilot Workspace takes it a step further. You give it an issue in one of your repos and it will plan and (when you give it the go-ahead) implement the required changes. You’ll end up with a pull request that you can examine and merge just as you would if it came from one of your colleagues. I had a lot of fun yesterday, whizzing through a load of issues that needed fixing in one of my (stage 2) projects. There was nothing that would have taken more than an hour to implement. But with the help of Copilot Workspace, each one took about ten minutes. I was very impressed and will be using it again.

• The first batch of talks for this year’s London Perl Workshop have been accepted. This includes a “Conference-Driven Development” proposal from me. I’m not quite sure where that fits on my list of stages above. Maybe Conference-Driven Development is its own thing. The LPW is returning for the first time since 2019.

• I’ve been worrying for a while about the way the Perl community is shrinking. A smaller community will have problems mainitaining community infrastructure and even adding new features to the language. A particular worry for me is the number of CPAN modules that are becoming unmaintained. This week, Curtis Poe realised that DBIx::Class (a popular library for database access) is basically unmaintained and hasn’t been updated since 2022. It currently still works fine, but that won’t be true forever. You might be interested in the discussions about this on Reddit and Facebook.

I won’t promise when the next of these newsletters will appear. But I’m quietly hoping that it’ll be some time in August.

Now I’m going to get back to moving projects along the product scale.

Cheers,

Dave…

Anyway, last time I wrote I was debating with myself about which project I would devote my time to. I never really reached a decision on that. So I’m still juggling a number of different things.

GitHub Actions Essentials

Marketing continues on the book I published last year. You’ll recall that I was interviewed for Software Engineering Radio about GitHub Actions. I thought that would be the last I would hear from them, but I forgot that the podcast was connected to the IEEE. Towards the end of last year, I heard from Gavin (who had interviewed me for the podcast) telling me that extracts from our conversation were going to be published in the IEEE’s Software magazine. The article appeared in their Jan-Feb 2024 issue and you can read it online (if you’re not already tired of reading me banging on about GitHub Actions).

In related news, I made some improvements to the Perl development workflows that I spoke about in Toronto last summer and finally got around to writing a blog post about them.

GitHub Pages Essentials

One of the potential projects on last year’s list was a follow-up to GitHub Actions Essentials which will be called GitHub Pages Essentials. Anyway, I’ve been making progress on that and I expect it to be published in a couple of months. Such a lot of my time currently seems to be spent working with GitHub Pages. I’m sure I must be one of the biggest users of the feature :-)

Perl Web Advice

I’ve just published another new blog post. This one is about how CGI programs aren’t anywhere nearly as dead as the Perl community would like to think they are. There are still plenty of people out there working under constraints (either real or imagined) which means they’re still deploying their web applications in CGI environments and cutting themselves off from over twenty years of technological improvements in how we deploy web apps.

I think that most of the problem comes down to education. So I’m resurrecting a project from about seven years ago where I was planning a web site that would talk about best practices for the development and deployment of Perl web applications. The site already exists (there’s not much there though) at web.perlhacks.com. I’d welcome any input you might have.

Update: I was writing this newsletter last night - just after I had published that blog post. This morning I’ve woken up to many comments defending CGI programs and asking what I’ve got against them. It seems clear that the argument for writing PSGI programs instead of CGI programs hasn’t been made strongly enough or clearly enough. So I guess that’s my next blog post sorted out!

Aphra

The subjects in this email are all a lot more intertwined than it might appear. The success of GitHub Actions Essentials has led to me thinking seriously about GitHub Pages Essentials. And Perl Web Advice sits at the intersection between my interest in GitHub Pages and wanting to steer people away from dated development and deployment techniques. And resurrecting Perl Web Advice has reactivated my interest in Aphra.

What’s Aphra? I hear you ask. Well, I’m glad you did, because I’m going to tell you.

As I said above, I use GitHub Pages a lot. And GitHub Pages is a tool for creating and publishing static web sites. And the best way to create static web sites is to use a static site generator.

Now, the default static site generator that’s baked into GitHub Pages is Jekyll. I’ve tried many times to understand Jekyll, but there’s something about it that just doesn’t match with how my brain works. I always end up with a site that doesn’t quite work how I’d like it to.

So about seven years ago (and it’s possible that Perl Web Advice was the site that pushed me into it) I did what any self-respecting geek would do and wrote my own tool (because that’s the only way you can guarantee it works exactly how you want it to work, right?)

[Quick sidebar to discuss the name: I wanted to call it Hyde so I could make jokes about it being uglier but more powerful than Jekyll. But Python had beaten me to it. I considered the names of a couple of other characters from Doctor Jekyll and Mr Hyde, but, finally, settled on Aphra to commemorate Aphra Behn, a woman who more people should know about.]

Anyway, I’ve been using it on a few sites for several years now. I’ve made a few improvements and I’m pretty happy with how it works. I should probably start encouraging more people to use it.

Maybe I should set up a web site for it. Does anyone know of a good static site generator? :-)

George and the Smart Home

I’ve put together a simple marketing web site for my children’s book, George and the Smart Home. Now you can see what the first dozen or so pages look like before you buy a copy.

Interesting links

Enough about me. Let’s finish with a few links to things that I’ve found interesting recently.

• Will You Lose Your Job To AI? Curtis Poe is usually well worth reading and this piece about the effects that AI will have on the job market is no exception

• Will Sowman - I’ve published a couple of books by a local author. One on prompt engineering and one on how to get out of the rat race and start freelancing

• The Odds and Ends of History - I first met James when we were both part of the skeptics/atheist/rationalist movement in the 2000s. I was an occasional contributor to his much-missed podcast, The Pod Delusion. Now he’s writing a weekly newsletter on Substack. And it’s really interesting stuff

• Introducing Sora - I expect you’ve all seen OpenAI’s impressive video-generating tool. But here’s a link in case anyone has missed it

Subscribe now

Share One Thing at a Time

That’s all for now. Hopefully, it won’t be another six months before my next newsletter.

Cheers,

Dave…

Hi all,

When I last wrote to you (which is longer ago than I would like it to have been), I mentioned a podcast I would be talking on. My episode was published yesterday, so I can now tell you all about it.

It’s an excellent example of serendipity. Gavin Henry is one of the presenters of Software Engineering Radio. He was looking for someone to appear on the podcast to talk about GitHub Actions when one of my newsletters plugging GitHub Actions Essentials appeared in his inbox. We exchanged a few emails and then spent a very pleasant hour or so talking about GitHub Actions back in April. The back-end team at SE Radio then took our conversation and turned it into a real podcast which is now available for you to listen to wherever you get your podcasts.

If you’re not really sure why you should care about GitHub Actions (and, more importantly, why you should buy a book about it) then I think our conversation does a good job of explaining what GitHub Actions is and how it can help you.

Other marketing efforts on the book continue to have a slow effect. I seem to be selling far more copies on LeanPub than on Amazon. I wonder if that’s my geeky audience having a preference for not using Amazon if possible?

ChatGPT and Copilot

Like the rest of the world, I’ve been experimenting with the new generation of Generative AI tools. Sometimes it feels like I’ve handed over most of the management of my life to GPT4. I’ve been using it to plan meals, exercise sessions and even sightseeing trips. It’s been really impressive.

But, as a geek, it’s coding where these tools really stand out for me. Over the last few years, I’ve become a reasonably competent Javascript programmer. But GPT4 has really increased my productivity. As an example, here’s my web page which links to the weekly status reports from the Perl Steering Council. The initial version built a static page each week when the new report was published. But now it loads the data from a JSON file and builds a table that can be sorted in various useful ways. None of that would have been beyond my Javascript abilities, but it would have taken me a few hours to get there. With a few carefully-chosen prompts, the new version was ready in about an hour. It wasn’t all plain-sailing - GPT4 consistently hallucinated the wrong name for a Font Awesome icon - but it was far easier than doing it myself.

I’ve also been experimenting with GitHub Copilot. I had put off trying it for months because I thought (wrongly, as it happens) that it only supported a small number of languages - that didn’t include Perl. But that’s not the case. Its Perl support seems to be pretty good. Ovid wrote a blog post which summarises his (positive) experience with Copilot and mine is very similar.

My “aha!” moment came when I decided to refactor some code and Copilot read my mind and produced the correct code without any prompts from me.

I was working on a web application that needed to switch between two display modes - one had basically no CSS and the other used CSS to make the output far prettier. The class had an attribute called “pretty” which determined which version to use. So the method that renders the output contains code like this:

my $css = $self->pretty ? $self->pretty_css : $self->standard_css;

And that $css variable was then interpolated into the output HTML. I decided to put that logic into a new method called “css()”. I just typed “sub css {“ and when I pressed the enter key, Copilot suggested a body for the method that was exactly what I wanted.

I was sold. I’m currently on the free trial, but once that’s up it’s going to be well worth the tenner or month it’s going to cost me.

AWS and AI

I was at the AWS Summit in London yesterday. As you’d guess, generative AI was a big topic there as well. AWS already has a number of AI-based services and that number is only going to increase as time passes. They now have a Copilot competitor called CodeWhisperer which might be worth a look.

I always come away from AWS Summit enthused to get my stuff moved into the AWS cloud and this year was no exception.

A few years ago, I started writing a series of blog posts called Into the Cloud, where I was going to explain how I moved one of my personal projects onto AWS. I never completed that project (real jobs got in the way) but I think the time is right to get back to it. And I think I’ll have a good helper this time. I’ve already had a conversation with ChatGPT about the project and we’ve come up with a plan to complete the transition. I’ll let you know how it goes.

Hire me

As you might be able to tell, I’m having a lot of fun writing books, experimenting with new toys and working on my own projects. But the mortgage still needs to be paid, so I’m in the market to take on a bit of work. If you or anyone you know can make use of my skills (Perl, Linux, web development, databases, GitHub Actions, and so on) then please get in touch.

Until next time,

Cheers,

Dave…

I released GitHub Actions Essentials into the world yesterday. The link will take you to a website which has links to all the places where you can buy it. Currently, that’s Amazon and LeanPub, but I’m open to suggestions of other places where you’d expect to buy it.

Currently, it’s ebook-only, but I’m looking into options for making it available in the physical world as well. Let me know if you’d find that useful.

This feels like the culmination of many weeks of work - researching the subject, writing the book, editing the book, wrangling it into a format that can be sold through various outlets. But, in reality, the real work starts now.

I now need to sell it.

I think I’ve mentioned before that I’m not a natural marketer (is it “marketer” or “marketeer”?) I would love to live in a world where I mention my new book on Twitter, Facebook and LinkedIn and suddenly the sales start flooding in. But, sadly, it’s not like that at all. There’s a lot more work that needs to be done. I did the easy tweeting and stuff like that yesterday. This newsletter is the next step in the campaign. This is a relatively easy step. This feels a bit like talking to a group of friends. I hope you don’t feel like you’re being marketed to - even though you are.

Buy my book! It’s great!!

But that’s not how marketing is supposed to go these days. Hey, I’ve read Seth Godin - I know how this stuff works. Let’s try again.

• GitHub Actions will make your life easier by automating a lot of the software engineering process

• GitHub Actions Essentials will show you how to use GitHub Actions in order to make your life easier

• Buy my book! It’s great!!

See! That’s better, isn’t it? My book solves problems and makes your life better.

Then there are the bits of the process that a traditional publisher would do for me. Sending out review copies to people (and, later, chasing for reviews), paying for adverts in the right places (knowing where “the right places” are). I’ll need to do all of that myself. (Hint - if you’re able to help me get a review copy to someone who will write a relatively high-profile review, then please get in touch.)

A couple of things have serendipitously fallen into my lap. LeanPub has started doing a series of “book launch videos” where they interview the authors of recently-published books. Overnight I got an invitation to take part in one of those - so I’ll be interviewed next Monday for that. Also, when my last newsletter went out, one of the subscribers was looking for someone to be interviewed about GitHub Actions for their (pretty well-known) software engineering podcast. We’re recording the conversation next week, so I’ll be able to share more details in the next newsletter.

Another important marketing tip is to use any existing audience that you have. Some of you will know me from my work in the Perl community. The Perl community has annual conferences in both Europe and North America and I’ve proposed a talk on “GitHub Actions for Perl Development” to both of them. Yesterday I heard that it had been accepted for the conference in Toronto in July, so it looks very much like I’ll be speaking there. This will be the first time I’ve spoken at a conference in North America since OSCON was in San Diego (over twenty years ago).

It’s possible that writing this newsletter is slowly turning into a marketing avoidance tactic. So I should probably stop now and turn my attention to some other potential customers. I’ll be back with more updates in a week or two. Oh, but before I go, I wanted to include an extract for you (step 1: provide useful content). So, below is “Appendix B: List of Useful GitHub Actions and Integrations”. Hopefully, this will give you a brief flavour of the kinds of things that you can do with GitHub Actions (thereby giving you a reason to buy the book - this marketing lark is addictive!)

Speak to you soon,

Dave…

Appendix B: List of Useful GitHub Actions and Integrations

This appendix provides a curated list of useful GitHub Actions and integrations that can enhance your workflows and improve your development process. While this list is not exhaustive, it should help you discover the potential of GitHub Actions and encourage you to explore the GitHub Actions Marketplace for more actions.

1. actions/checkout: This action checks out your repository so your workflow can access its contents. It is one of the most commonly used actions in GitHub Actions workflows.

   • Repository: https://github.com/actions/checkout

2. actions/setup-node: Sets up a Node.js environment on the runner, allowing you to run Node.js scripts and tools in your workflow.

   • Repository: https://github.com/actions/setup-node

3. actions/setup-python: Sets up a Python environment on the runner, allowing you to run Python scripts and tools in your workflow.

   • Repository: https://github.com/actions/setup-python

4. actions/cache: Caches dependencies and build outputs to improve workflow execution times.

   • Repository: https://github.com/actions/cache

5. actions/upload-artifact and actions/download-artifact: Uploads build artifacts from a job and downloads them for use in subsequent jobs.

   • Repository: https://github.com/actions/upload-artifact and https://github.com/actions/download-artifact

6. actions/create-release: Creates a new release on GitHub and uploads assets to the release.

   • Repository: https://github.com/actions/create-release

7. actions/github-script: Allows you to write inline scripts that interact with the GitHub API and other GitHub Actions features using Octokit and the actions-toolkit libraries.

   • Repository: https://github.com/actions/github-script

8. codecov/codecov-action: Uploads your code coverage reports to Codecov, a popular code coverage analysis and reporting tool.

   • Repository: https://github.com/codecov/codecov-action

9. deployments/ftp-deploy: Deploys your repository to a remote server via FTP or SFTP.

   • Repository: https://github.com/deployments/ftp-deploy

10. jakejarvis/lighthouse-action: Runs Google Lighthouse audits on your web application and generates reports.

• Repository: https://github.com/jakejarvis/lighthouse-action

11. peter-evans/create-pull-request: Automates the creation of pull requests from within your GitHub Actions workflows.

• Repository: https://github.com/peter-evans/create-pull-request

12. semantic-release/semantic-release: Fully automated version management and package publishing based on semantic versioning rules.

• Repository: https://github.com/semantic-release/semantic-release

13. snyk/actions: Scans your dependencies for vulnerabilities using Snyk, a popular open-source security platform.

• Repository: https://github.com/snyk/actions

14. SonarCloud/github-action: Integrates SonarCloud, a cloud-based code quality and security analysis platform, into your GitHub Actions workflows.

• Repository: https://github.com/SonarCloud/github-action

15. stale/stale: Automatically marks issues and pull requests as stale after a period of inactivity, and eventually closes them if no further activity occurs.

• Repository: https://github.com/stale/stale

Remember to explore the GitHub Actions Marketplace for additional actions and integrations that may suit your specific needs.

• GitHub Actions for semi-static web sites

• Not that PR, thanks

• Dependabot and GitHub Actions

• Deploying GitHub Pages sites with GitHub Workflows

I think that GitHub Actions is a useful feature which allows you to automate large parts of the software development process. Every day that I use it, I find another interesting thing about it and I’m sure I’ve only scratched the surface.

All of which means that over the last few weeks, I’ve found myself writing about GitHub Actions. And it’s almost ready to be published. The front cover is below and I’ve been working on a website about the book (it’s very much a work in progress - feel free to take a look but don’t be surprised if things don’t work and please don’t share the link with anyone else yet).

One thing that the web page does have already is a table of contents - so you can see whether or not you’ll be interested in the book. And, below, I present the first preview content from the book. This is an extract from section 10.3 - Automating Project Management and Collaboration.

Automating Project Management and Collaboration

Automating project management and collaboration tasks can significantly improve the efficiency of your development process and help your team stay focused on delivering high-quality code. GitHub Actions provides a flexible platform for creating custom workflows to automate various aspects of your project management and collaboration efforts.

In this section, we will discuss several examples of how you can leverage GitHub Actions to automate project management and collaboration tasks

Automating Issue and Pull Request Management

Issues and pull requests are at the core of GitHub's collaborative features, allowing team members to report bugs, suggest enhancements, and submit code changes. By automating their management with GitHub Actions, you can save time, improve organization, and ensure consistency in your project.

Here are some key aspects of automating issue and pull request management with GitHub Actions:

1. Labelling: Automatically apply labels to new issues and pull requests based on predefined criteria. For example, you can label issues as "bug" or "enhancement" based on their description or use specific labels for pull requests targeting particular branches. This helps categorize and prioritize tasks within your project.

2. Assignment: Assign issues and pull requests to specific team members or groups based on predefined rules. This ensures that the right person is responsible for addressing each task and helps distribute workload evenly across your team.

3. Triage: Automatically move issues and pull requests through different stages of your development process. For example, you can create a workflow that automatically moves a pull request to a "review" stage when it's ready for review, and then to a "testing" stage when it's been approved.

4. Notifications: Send custom notifications to team members, Slack channels, or email addresses when specific events occur. This can help keep your team informed about the progress of issues and pull requests, and ensure that everyone is on the same page.

5. Automated checks: Implement automated checks and validations for pull requests to ensure that they meet certain quality standards before they can be merged. For example, you can enforce that all pull requests pass your CI pipeline or meet specific code coverage thresholds.

6. Merging: Automate the process of merging pull requests once they meet certain criteria, such as passing all required checks or receiving a specific number of approvals. This can help streamline your development process and ensure that code changes are merged promptly and consistently.

To get started with automating issue and pull request management, explore the available GitHub Actions in the marketplace that are designed for these purposes. You can also create custom workflows tailored to your project's specific needs. By implementing automation in your issue and pull request management, you'll be able to focus more on the actual development work and maintain a more organized, efficient, and collaborative project environment.

Integrating GitHub Actions with Project Boards

GitHub Project Boards provide a visual representation of your project's progress, allowing you to manage tasks, prioritize work, and track milestones. Integrating GitHub Actions with Project Boards can streamline your project management and help you maintain an up-to-date view of your project's status.

Here are some key aspects of integrating GitHub Actions with Project Boards:

1. Automatic Card Creation: Automatically create cards on your Project Board when new issues or pull requests are opened. This ensures that all tasks are tracked in a centralized location and allows team members to get an overview of the work that needs to be done.

2. Card Movement: Automate the movement of cards between different columns on your Project Board based on specific triggers or events. For example, when a pull request is approved, you can automatically move its corresponding card to a "Ready for Merge" column. This helps maintain an accurate representation of your project's progress and minimizes manual work for your team.

3. Card Assignment: Assign cards to team members automatically based on predefined rules or conditions. This can help distribute the workload more evenly and ensure that the right person is responsible for each task.

4. Updating Card Details: Automatically update card details, such as labels, assignees, or due dates, based on changes in the associated issue or pull request. This keeps your Project Board up-to-date and ensures that all relevant information is easily accessible.

5. Project Board Notifications: Send custom notifications to your team when specific events occur on your Project Board, such as when a card is moved to a different column or when a due date is approaching. This can help keep your team informed and ensure that everyone is aware of important updates or deadlines.

To integrate GitHub Actions with your Project Boards, you'll need to create custom workflows that interact with the GitHub API to perform actions related to Project Boards. Explore the available actions in the GitHub Actions Marketplace for managing Project Boards or create your own custom actions tailored to your project's needs.

By integrating GitHub Actions with your Project Boards, you can automate and streamline your project management processes, leading to increased efficiency and better collaboration among team members.

Collaborating with External Teams and Services

In many software projects, collaboration extends beyond your immediate team to include external teams or third-party services. Integrating GitHub Actions with these external resources can facilitate seamless collaboration, streamline communication, and ensure that all parties stay informed and in sync.

Here are some key aspects of collaborating with external teams and services using GitHub Actions:

1. Interacting with External Repositories: Set up workflows that interact with external repositories, such as creating pull requests, opening issues, or updating code in a forked repository. This can be particularly helpful when working with open-source projects or collaborating with other organizations on shared initiatives.

2. Third-Party Service Integration: Integrate GitHub Actions with popular third-party services such as Jira, Trello, Slack, or Microsoft Teams to automate various project management, communication, and collaboration tasks. For example, you can create a workflow that posts a message to a specific Slack channel when a new pull request is opened or synchronize GitHub issues with Jira tickets.

3. Shared Workflows and Actions: Share workflows and actions across multiple repositories or organizations. This allows you to establish best practices and maintain consistency across your projects. You can also leverage GitHub's reusable workflows feature to minimize duplication of effort and streamline the setup process for new projects.

4. Access Control and Permissions: Configure access controls and permissions for your GitHub Actions workflows to ensure that only authorized users can perform specific actions or access sensitive information. This is particularly important when working with external collaborators, as it helps maintain the security and integrity of your codebase.

5. Collaboration on Custom Actions: Encourage collaboration on the development of custom GitHub Actions by making the source code available in a public repository. This allows external contributors to submit improvements, report issues, or suggest new features, fostering a community-driven approach to action development.

To successfully collaborate with external teams and services using GitHub Actions, it's essential to plan and implement appropriate workflows, access controls, and integrations. This will enable your team to work efficiently with external collaborators, harness the power of third-party services, and maintain the security and integrity of your projects.

Automating Code Review and Feedback

Automating code review and feedback processes using GitHub Actions can significantly improve the overall quality of your codebase and streamline collaboration among team members. By incorporating automated checks and reviews, you can ensure that your project adheres to established coding standards and best practices while minimizing human errors and oversight.

Here are some key aspects of automating code review and feedback using GitHub Actions:

1. Linting and Static Code Analysis: Integrate linters and static code analysis tools in your workflows to automatically check for syntax errors, code style violations, and other issues. These tools can provide immediate feedback on pull requests, ensuring that your codebase remains clean and maintainable. Popular tools include ESLint for JavaScript, Pylint for Python, and RuboCop for Ruby.

2. Automated Testing: Configure your workflows to run automated tests on every pull request or commit. This helps identify potential issues early in the development process and ensures that new changes do not introduce regressions. You can also use GitHub Actions to run tests in parallel or across multiple environments, further increasing the reliability and robustness of your codebase.

3. Code Review Automation: Use GitHub Actions to automate various aspects of the code review process, such as automatically assigning reviewers, enforcing review policies, or checking for compliance with specific guidelines. This can help streamline the review process and ensure that all code changes are thoroughly vetted before being merged into the main branch.

4. Automated Feedback: Integrate GitHub Actions with communication platforms like Slack or Microsoft Teams to provide real-time feedback on code changes. For example, you can create a workflow that sends a message to a specific channel whenever a new pull request is opened or when automated tests fail. This helps keep your team informed and encourages prompt action on issues.

5. Performance and Security Checks: Use GitHub Actions to automatically analyze your code for performance bottlenecks, security vulnerabilities, and other potential issues. Tools like SonarQube or Snyk can help you identify and address these concerns early in the development process, ensuring that your code remains secure and performant.

By automating code review and feedback processes using GitHub Actions, you can establish a more efficient and effective collaboration environment for your team. This, in turn, leads to higher quality code, fewer defects, and faster development cycles, ultimately resulting in a more successful and robust software project.

Streamlining Documentation and Knowledge Management

Effective documentation and knowledge management are critical to the success of any software project. They ensure that all team members have access to the information they need to understand, contribute to, and maintain the codebase. GitHub Actions can help automate and streamline various aspects of documentation and knowledge management, making it easier for your team to stay informed and up-to-date.

Here are some key strategies for streamlining documentation and knowledge management using GitHub Actions:

1. Automated Documentation Generation: Use GitHub Actions to automatically generate and update project documentation based on code comments, markdown files, or other sources. Tools like JSDoc, Sphinx, and Jekyll can help you create comprehensive and well-structured documentation with minimal effort. By integrating these tools into your workflow, you can ensure that your documentation remains current and accurate as your codebase evolves.

2. Documentation Linting and Validation: Validate your documentation for syntax, structure, and consistency using GitHub Actions. Tools like markdownlint, textlint, or reStructuredText linters can help you enforce documentation standards and best practices. By automatically checking documentation in pull requests or commits, you can maintain high-quality documentation that is easy to understand and navigate.

3. Automated Knowledge Base Updates: Integrate GitHub Actions with your knowledge management system or wiki to automatically update documentation and other resources when changes are made to your codebase. For example, you could create a workflow that updates a Confluence page or a GitHub Wiki whenever a new feature is added or an existing feature is modified. This ensures that your team always has access to the most up-to-date information.

4. Change Tracking and Notification: Use GitHub Actions to monitor changes to documentation and other knowledge resources, and notify team members of relevant updates. This can help keep your team informed about important changes and encourage collaboration and knowledge sharing. Integrating GitHub Actions with communication platforms like Slack or Microsoft Teams can facilitate real-time notifications and discussions around documentation updates.

5. Automating Release Notes: Generate and publish release notes automatically using GitHub Actions. By extracting relevant information from commit messages, pull requests, and issue tracker updates, you can create detailed and accurate release notes that help users understand the changes and improvements in each new version of your software.

By leveraging GitHub Actions to automate and streamline documentation and knowledge management processes, you can foster a more informed and collaborative development environment. This leads to better decision-making, more efficient workflows, and ultimately, a more successful and maintainable software project.

I need your help with the book. I think the book is in pretty good shape, but I’m looking for a handful of people to give it a read and let me know what you think about it. I’m really looking for help in three areas:

• Is the subject matter interesting or useful? And do I go into enough detail (or, perhaps, too much)?

• Is the content accurate? Or have I made a bit of a fool of myself in some places?

• How’s my English? I like to think that I know how to write reasonably well, but with something this substantial, there are always going to be a few errors that will creep in. Let’s get those knocked on the head.

I’m afraid, the timescales are pretty tight. I’d like to get this published towards the end of next week. So please only volunteer if you’ll have time to spend on the project over the next few days.

In exchange, you’ll get a credit in the foreword and a copy of the ebook in whatever format you prefer (as long as that’s EPUB, Mobi or PDF!)

Please get in touch by email or on Twitter or Mastodon if you’d like to help. I’ll send a link to the first half a dozen or so to get in touch.

And, hopefully, I’ll have more news about this next week.

Thanks for reading.

Dave…

This is a conversation space in the Substack app that I set up exclusively for my subscribers — kind of like a group chat or live hangout. I’ll post short prompts, thoughts, and updates that come my way, and you can jump into the discussion.

To join our chat, you’ll need to download the Substack app, now available for both iOS and Android. Chats are sent via the app, not email, so turn on push notifications so you don’t miss conversation as it happens.

How to get started

1. Download the app by clicking this link or the button below. Substack Chat is now available on both iOS and Android.

Get app

2. Open the app and tap the Chat icon. It looks like two bubbles in the bottom bar, and you’ll see a row for my chat inside.

3. That’s it! Jump into my thread to say hi, and if you have any issues, check out Substack’s FAQ.

Join chat