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

It’s twelve days since I sent out the first of these weekly updates. Which means I’m more than a little late. I can see I’m going to have to be a little bit more organised here.

Part of the problem, I think is that there’s not actually very much to report. I took a couple of days off over my birthday to do tourist things in London and then, the following weekend, I decided I needed to recharge my mental batteries before starting again, so I spent a couple of nights down on the Dorset coast. And, in both cases, I rejigged my working week so that I allocated most of the time I had left to my part-time freelancing job. All of which means I haven’t, yet, dedicated much time to this project.

But there is some progress. On the journey back from Dorset I talked through one of my projects with my business partner and came up with several ideas. Before I get into those, let’s take a higher-level look at the project.

A Brief Introduction to More Than Code

More Than Code is the book I was working on when the pandemic struck in March 2020. It’s loosely based on a workshop I ran at the European Perl Conference in Glasgow in 2018. The workshop was called “The Professional Programmer” and the idea was to talk to programmers about the bits of their job that weren’t actually designing and writing code.

Over three or four hours we traced a route from very technical things like source code control, editors and databases past useful techniques like SCRUM and design patterns and ending on “fluffy” topics like building a career and personal branding. The attendees all seemed to enjoy it and find it useful and, over the rest of the conference, a couple of people approached me and suggested that I should think about doing more presentations along the same lines.

So that’s why it became my March 2020 project. I figured that if my small slice of the programming community found it useful, then maybe a book on the subject would be interesting to a far larger community (and, perhaps, people who were thinking about programming as a career).

The plan was to write 3,000 words a day. That would have got me most of the way to a book that I planned to sell through Amazon and other ebook services. I also thought that I could run seminars on the subject.

Of course, Covid stopped me from delivering on that plan. But I did get 18,000 words written before I ground to a halt. And, reviewing them over the last week, I see that most of them are pretty good words.

Moving Forward

I still think that More Than Code is a good idea, so it’s one of the projects that I’m going to be pressing on with over this year. Of course, at a basic level, the plan remains the same - write another 60,000 words or so on the subject. But I think there’s a bit more to it than that. And that’s what I was discussing with my friend on the way back from Dorset.

The big difference that contractors (like me) have to deal with when moving to a more entrepreneurial mindset is that it’s no longer about trading your time for money. Over the last twenty-five years, I’ve done pretty well at selling my time to many different companies. I turn up at their office for a day and sprinkle a little modern Perl magic over their codebase and they pay me some money. But that doesn’t scale. There are only a certain number of days in a year and there’s a limit to how much I can make by writing Perl for a day.

We need to think about moving to a model where we’re selling a product that doesn’t use up my time. Something that can be making money even when I’m asleep. The book is a good start in that direction. But only a massive optimist would suggest that a technical book could bring in as much income as a contractor does in a year.

My next thought was seminars. I can run public courses on the subject, or sell my services to a company and go in-house for a day, talking to their employees about their careers. But we’re back at trading time for money. I mean, yes, hopefully, my time would be more valuable in that scenario and I’d be able to charge quite a lot more for each day’s work. But I wouldn’t be working every day and, let’s face it, a seminar on technical careers isn’t going to sell out the Albert Hall.

So I think that’s a possibility. But it’s only really a stepping-stone to the next couple of ideas - selling videos and e-learning on the same subject.

Videos are the obvious next step. You can start by just recording a talk. But the problem with a video is the same as you get with a book - it’s very static. The first time you read a technical book, you might read it straight through. If it’s a useful book, you might later refer to particular sections when you have certain problems to solve. It’s not a very interactive way to learn.

But e-learning is better. With e-learning, you can change the route through the course depending on how the user is doing. They can choose their own way through the course. It’s far more interactive and, therefore, you find that more of the knowledge is retained by the student.

I also think that companies will pay more for e-learning. Whereas a company might buy two or three copies of a book for their technical library, you can sell them e-learning on a per-seat basis - and then they can make it available to everyone through their in-house learning portal.

Ultimately, I think I’ll end up with a hybrid strategy:

* Books sold through standard channels

* Seminars (both public and in-house)

* Videos of seminars

* E-learning

What do you think? Is this a service that you think you (or your company) might be interested in? What format would you want it in? Have I missed a useful format?

Of course, this all relies on me having the material ready. And that’s why the first order of business is to finish writing the book - which isn’t a trivial task!

More next week,

Dave…

Subscribe now

It was my birthday earlier this week. It seems unlikely (to me, at least) but I was 59. Which means there’s only a year to go until I am 60.

I’ve never really been bothered about those big “round number” birthdays. I’ve sailed through 20, 30, 40 and even 50 without any worries at all. “Age is just a number,” I’d say when asked (or some equally pointless nonsense).

But 60 feels different. I can tell it’s going to feel really different by the way I’m already thinking about it when it’s a year away. At 60, it’s going to be difficult to persuade myself that I’m still actually pretty young. By 60 you’re not only supposed to know what you’re going to do with your life - you’re supposed to have done most of it.

And I have a year left to get to that point.

Hold that thought.

Those of you who have been following my work for a while now might remember my “2020 Vision” project (or, more accurately, projects). I gave up my job and I planned to give myself six months to work on various ideas and see if any of them could be made into a sustainable business. I spent three months working on three different things with varying levels of success.

And then the pandemic hit.

I mean it didn’t hit me in any real, measurable fashion. I was already working from home, so my daily routine didn’t change. I was planning to live off my savings for six months, so I didn’t need to get involved in any of the government financial schemes for business owners. There was no reason for anything to change.

But everything changed.

I completely lost my focus. March’s project was to write a book. But I didn’t get a quarter of the way into it. My concentration was shot to pieces. I was spending too much of my diminishing mental energy worrying about infection rates and government briefings.

The second half of the year is a bit of a haze. I ended up taking on a contract for the last three months of the year - remote working of course. But as the end of the year approached I was adamant that I was going to have another try at building a business in 2021. So I ended my contract and started 2021 in pretty much the same position as I had started 2020 (except with a global pandemic raging in the background).

2021 didn’t start well. I was completely unfocused. I dabbled with a few things. I made tweaks to a lot of websites that I run. I released updated versions of most of the Perl libraries that I maintain.

I didn’t make any money.

Then an old client got in touch offering some work maintaining a codebase that I used to work on. I asked if they would consider a part-time contract and they said yes. So that’s where I am right now. I work two days a week for my client and the rest of the week is free for me to do what I want. And the contract brings in enough money for me to live on so I’m no longer burning through my savings. It’s all working out rather well.

Except, that I’m still not making much progress on my own projects. I needed something to push me into getting on with building a business.

And that’s where the 59th birthday scare comes in. I now have a deadline. I want to achieve something - have some kind of business going - by my next birthday.

So that’s the plan. I’ll spend two days a week working for my client and three days a week getting back to some of the projects I wanted to work on last year. Initially, I plan to finish the book and work on a project management tool that I’ve been building with a potential business partner - more about both of those projects in forthcoming emails.

And, in order, to keep myself on track, I want to share my progress with you. I’m going to send out a weekly update to this mailing list every week. Hopefully, the thought of having to tell people what I’ve achieved each week will mean I’m driven to actually achieve something.

Oh, and notice that the title for this piece is “Week 52”? That’s another little piece of psychological trickery. I’m giving myself a countdown to my 60th birthday; a target to aim at.

If you’re already subscribed to my mailing list, I hope you’ll find this slight realignment of it interesting. If you’re not already subscribed, I hope you’ll consider subscribing in order to keep up to date with what I’m doing.

See you next week.

Dave…

Subscribe now

I’ve been interested in eBooks for several years. Back in 2014, at the London Perl Workshop, I announced that I would be writing a book on Modern Web Development Techniques that would be available by the 2015 workshop. That book never happened, and one of the reasons for that was that I got lost down a massive rabbit hole while researching the best way to publish an eBook.

After a few false starts, I developed the pipeline that I still use today for publishing eBooks. I knew I wanted to store the text in a non-proprietary format - one that I could use all Unix’s text manipulation tools on; one that could be easily stored in a standard source code control system. I write in Markdown and I produce output in ePub, Mobi and PDF.

I gave a talk about my pipeline (called “Conference Driven Publishing”) at a few conferences in 2015 - including at that year’s London Perl Workshop, where I apologised for not writing the book I promised the previous year. In August, I wrote a blog post describing my process in more detail and in November, I used the pipeline to publish my first eBook - a collection of old blog posts called Eighteen Classic Albums.

In 2016, I adapted my talk to a less Perl-centric audience and gave the new version (renamed to “Writing Books (The Easy Bit)”) at the spring FLOSS UK conference in London. A few people seemed interested in what I was doing and I started to toy with the idea of publishing an eBook about publishing eBooks (a project that I have started, but am yet to finish).

I had been wondering what my next eBook would be but in 2017, a perfect opportunity presented itself. A beginners Perl tutorial that I had written for Udemy fell out of favour and found itself in a derelict section of their site where broken CSS made it pretty much unusable. When I contacted them about it, they said they had no plans to fix it but that I was welcome to republish it myself. So I decided to do that.

Turning the course into a (brief) eBook was easy - I was getting pretty used to my pipeline by that time. But I decided that I would take this a step further and make it the first book in a series of books about Perl. Five years earlier, I had used the Perl School branding for a series of training courses and I decided to reuse that brand for my new series of books. Perl Taster soon became the first book in the series and I gave a talk at the next London Perl Workshop introducing the brand and inviting other people to write for the series.

John Davies spoke to me after my talk and proposed a book on using Selenium with Perl (based on a talk he had given at the workshop). A few months later, Selenium & Perl became the second Perl School book and it began to look like we’d really need a website.

So we had a brand. And the brand got quite a boost when well-known Perl author brian d foy got in touch with me and asked if he could publish some eBooks through Perl School. I obviously leapt at the chance and we have now published four of brian’s books. Along with another book each by John Davies and me, that brings Perl School’s current catalogue to a total of eight books. I was interviewed by brian for perl.com about the ideas behind Perl School. We also started making some of our books available through LeanPub. Outside of Perl School, I helped a friend publish her chick-lit novel.

And that’s the story so far. I’ve written and published a number of eBooks on both Amazon and LeanPub and I’ve helped a few other people do the same thing.

But that’s not where it ends. Perl programming is a pretty niche market and the Perl School books aren’t exactly selling in large numbers. So it’s time for the next stage of the plan. I’m going to take the lessons I’ve learned from the last six years and apply them to a larger marketplace. For that purpose, I’ve set up Clapham Technical Press - a service that will do what Perl School does for Perl authors, but for people writing about any technologies. If you want to know a bit more about the mechanics of publishing eBooks, then please get in touch. If you want help turning your ideas into an eBook, then please get in touch. If you want someone to handle uploading your eBook to various platforms for you, then please get in touch.

We’re at hello@claphamtechpress.com and we’d love to help you get your knowledge out into the world.

Share

Leave a comment

Subscribe now