Watched on Tuesday April 29, 2025.

Watched on Monday April 28, 2025.

Watched on Sunday April 27, 2025.

Watched on Friday April 25, 2025.

Watched on Tuesday April 22, 2025.

Last week, I wrote a blog post about how I gave new life to an old domain by building a new website to live on that domain. With help from ChatGPT, it only took a few hours to build the site. While I’ll be adding new businesses and events to the site over time, that is currently a manual process and the site is mostly static.

This week, I wanted to take things a bit further. I wanted to build a site that was updated daily – but without any input from me.

Whois tells me I first registered cool-stuff.co.uk in September 1997. It was one of the first domains I registered. It has hosted a couple of very embarrassing early sites that I built, and for a while, it served as the email domain for several members of my family. But since they all moved to GMail, it’s been pretty much dormant. What it has never hosted is what I originally registered it for – a directory of cool things on the world wide web. So that’s what I decided to build.

So here’s the plan:

• A very simple website
• Each day it features a cool website – just the name, a link and a simple description
• An archive page showing previously featured sites
• Auto-generated each day with no manual intervention from me

I decided to stick with Jekyll and Minimal Mistakes as I enjoyed using them to build Balham.org. They make it easy to spin up a good-looking website, but they also have ways to add complexity when required. That complexity wasn’t needed here.

The site itself was very simple. It’s basically driven from a YAML file called coolstuff.yml which lists the sites we’ve featured. From that, we build a front page which features a new site every day and an archive page which lists all the previous sites we have featured. Oh, and we also have an RSS feed of the sites we feature. This is all pretty basic stuff.

As you’d expect from one of my projects, the site is hosted on GitHub Pages and is updated automatically using GitHub Actions.

It’s in GitHub Actions where the clever (not really all that clever – just new to me) stuff happens. There’s a workflow called update-coolstuff.yml which runs at 02:00 every morning and adds a new site. And it does that by asking ChatGPT to recommend a site. Here’s the workflow:

name: Update Cool Stuff

on:
  schedule:
    - cron: '0 2 * * *' # Runs at 2 AM UTC
  workflow_dispatch:

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Perl dependencies
        run: |
          sudo apt-get update && sudo apt-get install -y cpanminus
          cpanm -n --sudo OpenAPI::Client::OpenAI YAML JSON::MaybeXS

      - name: Get a cool website from OpenAI
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          perl .github/scripts/fetch_cool_site

      - name: Commit and push if changed
        run: |
          git config user.name "github-actions"
          git config user.email "github-actions@github.com"
          git add docs/_data/coolstuff.yml
          git diff --cached --quiet || git commit -m "Add new cool site"
          git push

There’s not much clever going on there. I needed to ensure I had an OpenAI subscription with credit in the account (this is going to cost a tiny amount of money to run – I’m making one request a day!), and I set up the API key as a secret in the repo (with the name “OPENAI_API_KEY).

The magic all happens in the “fetch_cool_site” program. So let’s look at that next:

#!/usr/bin/env perl

use strict;
use warnings;

use builtin qw[trim];

use OpenAPI::Client::OpenAI;
use YAML qw(LoadFile DumpFile);
use Time::Piece;
use JSON::MaybeXS;

my $api_key = $ENV{"OPENAI_API_KEY"} or die "OPENAI_API_KEY is not set\n";

my $client = OpenAPI::Client::OpenAI->new;

my $prompt = join " ",
  "Suggest a really cool, creative, or fun website to feature today on a site called 'Cool Stuff'.",
  "Just return the name, URL, and a one-paragraph description of why it's cool. Only return one site.",
  "The URL should just be the URL itself. Do not wrap it in Markdown.";

my $res = $client->createChatCompletion({
  body => {
    model => 'gpt-4o',
    messages => [
      { role => 'system', content => 'You are a helpful curator of awesome websites.' },
      { role => 'user', content => $prompt },
    ],
    temperature => 1.0,
  }
});

my $text = $res->res->json->{choices}[0]{message}{content};
my @lines = split /\n/, $text;

my ($name, $url, @desc) = @lines;
$name =~ s/^\*\s*//;
my $description = join ' ', @desc;

my $new_entry = {
  date => localtime->ymd,
  name => trim($name),
  url  => trim($url),
  description => trim($description),
};

my $file = "docs/_data/coolstuff.yml";
my $entries = LoadFile($file);

unless (grep { $_->{url} eq $new_entry->{url} } @$entries) {
  push @$entries, $new_entry;
  DumpFile($file, $entries);
}

We’re using OpenAPI::Client::OpenAI to talk to the OpenAI API. From my limited knowledge, that seems to be the best option, currently. But I’m happy to be pointed to better suggestions.

Most of the code is copied from the examples in the module’s distribution. And the parsing of the response is probably a bit fragile. I expect I could tweak the prompt a bit to get the data back in a slightly more robust format.

But it works as it is. This morning I woke up and found a new site featured on the front page. So, rather than spend time tweaking exactly how it works, I thought it would be a good idea to get a blog post out there, so other people can see how easy it is to use ChatGPT in this way.

What do you think? Can you see ways that you’d like to include ChatGPT responses in some of your code?

The website is live at cool-stuff.co.uk.

The post Finding cool stuff with ChatGPT first appeared on Perl Hacks.

Last week, I wrote a blog post about how I gave new life to an old domain by building a new website to live on that domain. With help from ChatGPT, it only took a few hours to build the site. While I’ll be adding new businesses and events to the site over time, that is currently a manual process and the site is mostly static.

This week, I wanted to take things a bit further. I wanted to build a site that was updated daily – but without any input from me.

Whois tells me I first registered cool-stuff.co.uk in September 1997. It was one of the first domains I registered. It has hosted a couple of very embarrassing early sites that I built, and for a while, it served as the email domain for several members of my family. But since they all moved to GMail, it’s been pretty much dormant. What it has never hosted is what I originally registered it for – a directory of cool things on the world wide web. So that’s what I decided to build.

So here’s the plan:

• A very simple website
• Each day it features a cool website – just the name, a link and a simple description
• An archive page showing previously featured sites
• Auto-generated each day with no manual intervention from me

I decided to stick with Jekyll and Minimal Mistakes as I enjoyed using them to build Balham.org. They make it easy to spin up a good-looking website, but they also have ways to add complexity when required. That complexity wasn’t needed here.

The site itself was very simple. It’s basically driven from a YAML file called coolstuff.yml which lists the sites we’ve featured. From that, we build a front page which features a new site every day and an archive page which lists all the previous sites we have featured. Oh, and we also have an RSS feed of the sites we feature. This is all pretty basic stuff.

As you’d expect from one of my projects, the site is hosted on GitHub Pages and is updated automatically using GitHub Actions.

It’s in GitHub Actions where the clever (not really all that clever – just new to me) stuff happens. There’s a workflow called update-coolstuff.yml which runs at 02:00 every morning and adds a new site. And it does that by asking ChatGPT to recommend a site. Here’s the workflow:

name: Update Cool Stuff

on:
  schedule:
    - cron: '0 2 * * *' # Runs at 2 AM UTC
  workflow_dispatch:

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Perl dependencies
        run: |
          sudo apt-get update && sudo apt-get install -y cpanminus
          cpanm -n --sudo OpenAPI::Client::OpenAI YAML JSON::MaybeXS

      - name: Get a cool website from OpenAI
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          perl .github/scripts/fetch_cool_site

      - name: Commit and push if changed
        run: |
          git config user.name "github-actions"
          git config user.email "github-actions@github.com"
          git add docs/_data/coolstuff.yml
          git diff --cached --quiet || git commit -m "Add new cool site"
          git push

There’s not much clever going on there. I needed to ensure I had an OpenAI subscription with credit in the account (this is going to cost a tiny amount of money to run – I’m making one request a day!), and I set up the API key as a secret in the repo (with the name “OPENAI_API_KEY).

The magic all happens in the “fetch_cool_site” program. So let’s look at that next:

#!/usr/bin/env perl

use strict;
use warnings;

use builtin qw[trim];

use OpenAPI::Client::OpenAI;
use YAML qw(LoadFile DumpFile);
use Time::Piece;
use JSON::MaybeXS;

my $api_key = $ENV{"OPENAI_API_KEY"} or die "OPENAI_API_KEY is not set\n";

my $client = OpenAPI::Client::OpenAI->new;

my $prompt = join " ",
  "Suggest a really cool, creative, or fun website to feature today on a site called 'Cool Stuff'.",
  "Just return the name, URL, and a one-paragraph description of why it's cool. Only return one site.",
  "The URL should just be the URL itself. Do not wrap it in Markdown.";

my $res = $client->createChatCompletion({
  body => {
    model => 'gpt-4o',
    messages => [
      { role => 'system', content => 'You are a helpful curator of awesome websites.' },
      { role => 'user', content => $prompt },
    ],
    temperature => 1.0,
  }
});

my $text = $res->res->json->{choices}[0]{message}{content};
my @lines = split /\n/, $text;

my ($name, $url, @desc) = @lines;
$name =~ s/^\*\s*//;
my $description = join ' ', @desc;

my $new_entry = {
  date => localtime->ymd,
  name => trim($name),
  url => trim($url),
  description => trim($description),
};

my $file = "docs/_data/coolstuff.yml";
my $entries = LoadFile($file);

unless (grep { $_->{url} eq $new_entry->{url} } @$entries) {
  push @$entries, $new_entry;
  DumpFile($file, $entries);
}

We’re using OpenAPI::Client::OpenAI to talk to the OpenAI API. From my limited knowledge, that seems to be the best option, currently. But I’m happy to be pointed to better suggestions.

Most of the code is copied from the examples in the module’s distribution. And the parsing of the response is probably a bit fragile. I expect I could tweak the prompt a bit to get the data back in a slightly more robust format.

But it works as it is. This morning I woke up and found a new site featured on the front page. So, rather than spend time tweaking exactly how it works, I thought it would be a good idea to get a blog post out there, so other people can see how easy it is to use ChatGPT in this way.

What do you think? Can you see ways that you’d like to include ChatGPT responses in some of your code?

The website is live at cool-stuff.co.uk.

The post Finding cool stuff with ChatGPT first appeared on Perl Hacks.

Building a website in a day — with help from ChatGPT

A few days ago, I looked at an unused domain I owned — balham.org — and thought: “There must be a way to make this useful… and maybe even make it pay for itself.”

So I set myself a challenge: one day to build something genuinely useful. A site that served a real audience (people in and around Balham), that was fun to build, and maybe could be turned into a small revenue stream.

It was also a great excuse to get properly stuck into Jekyll and the Minimal Mistakes theme — both of which I’d dabbled with before, but never used in anger. And, crucially, I wasn’t working alone: I had ChatGPT as a development assistant, sounding board, researcher, and occasional bug-hunter.

The Idea

Balham is a reasonably affluent, busy part of south west London. It’s full of restaurants, cafés, gyms, independent shops, and people looking for things to do. It also has a surprisingly rich local history — from Victorian grandeur to Blitz-era tragedy.

I figured the site could be structured around three main pillars:

Throw in a curated homepage and maybe a blog later, and I had the bones of a useful site. The kind of thing that people would find via Google or get sent a link to by a friend.

The Stack

I wanted something static, fast, and easy to deploy. My toolchain ended up being:

• Jekyll for the site generator
• Minimal Mistakes as the theme
• GitHub Pages for hosting
• Custom YAML data files for businesses and events
• ChatGPT for everything from content generation to Liquid loops

The site is 100% static, with no backend, no databases, no CMS. It builds automatically on GitHub push, and is entirely hosted via GitHub Pages.

Step by Step: Building It

I gave us about six solid hours to build something real. Here’s what we did (“we” meaning me + ChatGPT):

1. Domain Setup and Scaffolding

The domain was already pointed at GitHub Pages, and I had a basic “Hello World” site in place. We cleared that out, set up a fresh Jekyll repo, and added a _config.yml that pointed at the Minimal Mistakes remote theme. No cloning or submodules.

2. Basic Site Structure

We decided to create four main pages:

We used the layout: single layout provided by Minimal Mistakes, and created custom permalinks so URLs were clean and extension-free.

3. The Business Directory

This was built from scratch using a YAML data file (_data/businesses.yml). ChatGPT gathered an initial list of 20 local businesses (restaurants, shops, pubs, etc.), checked their status, and added details like name, category, address, website, and a short description.

In the template, we looped over the list, rendered sections with conditional logic (e.g., don’t output the website link if it’s empty), and added anchor IDs to each entry so we could link to them directly from the homepage.

4. The Events Page

Built exactly the same way, but using _data/events.yml. To keep things realistic, we seeded a small number of example events and included a note inviting people to email us with new submissions.

5. Featured Listings

We wanted the homepage to show a curated set of businesses and events. So we created a third data file, _data/featured.yml, which just listed the names of the featured entries. Then in the homepage template, we used where and slugify to match names and pull in the full record from businesses.yml or events.yml. Super DRY.

6. Map and Media

We added a map of Balham as a hero image, styled responsively. Later we created a .responsive-inline-image class to embed supporting images on the history page without overwhelming the layout.

7. History Section with Real Archival Images

This turned out to be one of the most satisfying parts. We wrote five paragraphs covering key moments in Balham’s development — Victorian expansion, Du Cane Court, The Priory, the Blitz, and modern growth.

Then we sourced five CC-licensed or public domain images (from Wikimedia Commons and Geograph) to match each paragraph. Each was wrapped in a <figure> with proper attribution and a consistent CSS class. The result feels polished and informative.

8. Metadata, SEO, and Polish

We went through all the basics:

• Custom title and description in front matter for each page
• Open Graph tags and Twitter cards via site config
• A branded favicon using RealFaviconGenerator
• Added robots.txt, sitemap.xml, and a hand-crafted humans.txt
• Clean URLs, no .html extensions
• Anchored IDs for deep linking

9. Analytics and Search Console

We added GA4 tracking using Minimal Mistakes’ built-in support, and verified the domain with Google Search Console. A sitemap was submitted, and indexing kicked in within minutes.

10. Accessibility and Performance

We ran Lighthouse and WAVE tests. Accessibility came out at 100%. Performance dipped slightly due to Google Fonts and image size, but we did our best to optimise without sacrificing aesthetics.

11. Footer CTA

We added a site-wide footer call-to-action inviting people to email us with suggestions for businesses or events. This makes the site feel alive and participatory, even without a backend form.

What Worked Well

• ChatGPT as co-pilot: I could ask it for help with Liquid templates, CSS, content rewrites, and even bug-hunting. It let me move fast without getting bogged down in docs.
• Minimal Mistakes: It really is an excellent theme. Clean, accessible, flexible.
• Data-driven content: Keeping everything in YAML meant templates stayed simple, and the whole site is easy to update.
• Staying focused: We didn’t try to do everything. Four pages, one day, good polish.

What’s Next?

• Add category filtering to the directory
• Improve the OG/social card image
• Add structured JSON-LD for individual events and businesses
• Explore monetisation: affiliate links, sponsored listings, local partnerships
• Start some blog posts or “best of Balham” roundups

Final Thoughts

This started as a fun experiment: could I monetise an unused domain and finally learn Jekyll properly?

What I ended up with is a genuinely useful local resource — one that looks good, loads quickly, and has room to grow.

If you’re sitting on an unused domain, and you’ve got a free day and a chatbot at your side — you might be surprised what you can build.

Oh, and one final thing — obviously you can also get ChatGPT to write a blog post talking about the project :-)

Originally published at https://blog.dave.org.uk on March 23, 2025.

A few days ago, I looked at an unused domain I owned — balham.org — and thought: “There must be a way to make this useful… and maybe even make it pay for itself.”

So I set myself a challenge: one day to build something genuinely useful. A site that served a real audience (people in and around Balham), that was fun to build, and maybe could be turned into a small revenue stream.

It was also a great excuse to get properly stuck into Jekyll and the Minimal Mistakes theme — both of which I’d dabbled with before, but never used in anger. And, crucially, I wasn’t working alone: I had ChatGPT as a development assistant, sounding board, researcher, and occasional bug-hunter.

The Idea

Balham is a reasonably affluent, busy part of south west London. It’s full of restaurants, cafés, gyms, independent shops, and people looking for things to do. It also has a surprisingly rich local history — from Victorian grandeur to Blitz-era tragedy.

I figured the site could be structured around three main pillars:

• A directory of local businesses
• A list of upcoming events
• A local history section

Throw in a curated homepage and maybe a blog later, and I had the bones of a useful site. The kind of thing that people would find via Google or get sent a link to by a friend.

The Stack

I wanted something static, fast, and easy to deploy. My toolchain ended up being:

• Jekyll for the site generator
• Minimal Mistakes as the theme
• GitHub Pages for hosting
• Custom YAML data files for businesses and events
• ChatGPT for everything from content generation to Liquid loops

The site is 100% static, with no backend, no databases, no CMS. It builds automatically on GitHub push, and is entirely hosted via GitHub Pages.

Step by Step: Building It

I gave us about six solid hours to build something real. Here’s what we did (“we” meaning me + ChatGPT):

1. Domain Setup and Scaffolding

The domain was already pointed at GitHub Pages, and I had a basic “Hello World” site in place. We cleared that out, set up a fresh Jekyll repo, and added a _config.yml that pointed at the Minimal Mistakes remote theme. No cloning or submodules.

2. Basic Site Structure

We decided to create four main pages:

• Homepage (index.md)
• Directory (directory/index.md)
• Events (events/index.md)
• History (history/index.md)

We used the layout: single layout provided by Minimal Mistakes, and created custom permalinks so URLs were clean and extension-free.

3. The Business Directory

This was built from scratch using a YAML data file (_data/businesses.yml). ChatGPT gathered an initial list of 20 local businesses (restaurants, shops, pubs, etc.), checked their status, and added details like name, category, address, website, and a short description.

In the template, we looped over the list, rendered sections with conditional logic (e.g., don’t output the website link if it’s empty), and added anchor IDs to each entry so we could link to them directly from the homepage.

4. The Events Page

Built exactly the same way, but using _data/events.yml. To keep things realistic, we seeded a small number of example events and included a note inviting people to email us with new submissions.

5. Featured Listings

We wanted the homepage to show a curated set of businesses and events. So we created a third data file, _data/featured.yml, which just listed the names of the featured entries. Then in the homepage template, we used where and slugify to match names and pull in the full record from businesses.yml or events.yml. Super DRY.

6. Map and Media

We added a map of Balham as a hero image, styled responsively. Later we created a .responsive-inline-image class to embed supporting images on the history page without overwhelming the layout.

7. History Section with Real Archival Images

This turned out to be one of the most satisfying parts. We wrote five paragraphs covering key moments in Balham’s development — Victorian expansion, Du Cane Court, The Priory, the Blitz, and modern growth.

Then we sourced five CC-licensed or public domain images (from Wikimedia Commons and Geograph) to match each paragraph. Each was wrapped in a <figure> with proper attribution and a consistent CSS class. The result feels polished and informative.

8. Metadata, SEO, and Polish

We went through all the basics:

• Custom title and description in front matter for each page
• Open Graph tags and Twitter cards via site config
• A branded favicon using RealFaviconGenerator
• Added robots.txt, sitemap.xml, and a hand-crafted humans.txt
• Clean URLs, no .html extensions
• Anchored IDs for deep linking

9. Analytics and Search Console

We added GA4 tracking using Minimal Mistakes’ built-in support, and verified the domain with Google Search Console. A sitemap was submitted, and indexing kicked in within minutes.

10. Accessibility and Performance

We ran Lighthouse and WAVE tests. Accessibility came out at 100%. Performance dipped slightly due to Google Fonts and image size, but we did our best to optimise without sacrificing aesthetics.

11. Footer CTA

We added a site-wide footer call-to-action inviting people to email us with suggestions for businesses or events. This makes the site feel alive and participatory, even without a backend form.

What Worked Well

• ChatGPT as co-pilot: I could ask it for help with Liquid templates, CSS, content rewrites, and even bug-hunting. It let me move fast without getting bogged down in docs.
• Minimal Mistakes: It really is an excellent theme. Clean, accessible, flexible.
• Data-driven content: Keeping everything in YAML meant templates stayed simple, and the whole site is easy to update.
• Staying focused: We didn’t try to do everything. Four pages, one day, good polish.

What’s Next?

• Add category filtering to the directory
• Improve the OG/social card image
• Add structured JSON-LD for individual events and businesses
• Explore monetisation: affiliate links, sponsored listings, local partnerships
• Start some blog posts or “best of Balham” roundups

Final Thoughts

This started as a fun experiment: could I monetise an unused domain and finally learn Jekyll properly?

What I ended up with is a genuinely useful local resource — one that looks good, loads quickly, and has room to grow.

If you’re sitting on an unused domain, and you’ve got a free day and a chatbot at your side — you might be surprised what you can build.

Oh, and one final thing – obviously you can also get ChatGPT to write a blog post talking about the project :-)

The post Building a website in a day — with help from ChatGPT appeared first on Davblog.

I built and launched a new website yesterday. It wasn’t what I planned to do, but the idea popped into my head while I was drinking my morning coffee on Clapham Common and it seemed to be the kind of thing I could complete in a day — so I decided to put my original plans on hold and built it instead.

The website is aimed at small business owners who think they need a website (or want to update their existing one) but who know next to nothing about web development and can easily fall prey to the many cowboy website companies that seem to dominate the “making websites for small companies” section of our industries. The site is structured around a number of questions you can ask a potential website builder to try and weed out the dodgier elements.

I’m not really in that sector of our industry. But while writing the content for that site, it occurred to me that some people might be interested in the tools I use to build sites like this.

Content

I generally build websites about topics that I’m interested in and, therefore, know a fair bit about. But I probably don’t know everything about these subjects. So I’ll certainly brainstorm some ideas with ChatGPT. And, once I’ve written something, I’ll usually run it through ChatGPT again to proofread it. I consider myself a pretty good writer, but it’s embarrassing how often ChatGPT catches obvious errors.

I’ve used DALL-E (via ChatGPT) for a lot of image generation. This weekend, I subscribed to Midjourney because I heard it was better at generating images that include text. So far, that seems to be accurate.

Technology

I don’t write much raw HTML these days. I’ll generally write in Markdown and use a static site generator to turn that into a real website. This weekend I took the easy route and used Jekyll with the Minimal Mistakes theme. Honestly, I don’t love Jekyll, but it integrates well with GitHub Pages and I can usually get it to do what I want — with a combination of help from ChatGPT and reading the source code. I’m (slowly) building my own Static Site Generator ( Aphra) in Perl. But, to be honest, I find that when I use it I can easily get distracted by adding new features rather than getting the site built.

As I’ve hinted at, if I’m building a static site (and, it’s surprising how often that’s the case), it will be hosted on GitHub Pages. It’s not really aimed at end-users, but I know to you use it pretty well now. This weekend, I used the default mechanism that regenerates the site (using Jekyll) on every commit. But if I’m using Aphra or a custom site generator, I know I can use GitHub Actions to build and deploy the site.

If I’m writing actual HTML, then I’m old-skool enough to still use Bootstrap for CSS. There’s probably something better out there now, but I haven’t tried to work out what it is (feel free to let me know in the comments).

For a long while, I used jQuery to add Javascript to my pages — until someone was kind enough to tell me that vanilla Javascript had mostly caught up and jQuery was no longer necessary. I understand Javascript. And with help from GitHub Copilot, I can usually get it doing what I want pretty quickly.

SEO

Many years ago, I spent a couple of years working in the SEO group at Zoopla. So, now, I can’t think about building a website without considering SEO.

I quickly lose interest in the content side of SEO. Figuring out what my keywords are and making sure they’re scattered through the content at the correct frequency, feels like it stifles my writing (maybe that’s an area where ChatGPT can help) but I enjoy Technical SEO. So I like to make sure that all of my pages contain the correct structured data (usually JSON-LD). I also like to ensure my sites all have useful OpenGraph headers. This isn’t really SEO, I guess, but these headers control what people see when they share content on social media. So by making that as attractive as possible (a useful title and description, an attractive image) it encourages more sharing, which increases your site’s visibility and, in around about way, improves SEO.

I like to register all of my sites with Ahrefs — they will crawl my sites periodically and send me a long list of SEO improvements I can make.

Monitoring

I add Google Analytics to all of my sites. That’s still the best way to find out how popular your site it and where your traffic is coming from. I used to be quite proficient with Universal Analytics, but I must admit I haven’t fully got the hang of Google Analytics 4 yet-so I’m probably only scratching the surface of what it can do.

I also register all of my sites with Google Search Console. That shows me information about how my site appears in the Google Search Index. I also link that to Google Analytics — so GA also knows what searches brought people to my sites.

Conclusion

I think that covers everything-though I’ve probably forgotten something. It might sound like a lot, but once you get into a rhythm, adding these extra touches doesn’t take long. And the additional insights you gain make it well worth the effort.

If you’ve built a website recently, I’d love to hear about your approach. What tools and techniques do you swear by? Are there any must-have features or best practices I’ve overlooked? Drop a comment below or get in touch-I’m always keen to learn new tricks and refine my process. And if you’re a small business owner looking for guidance on choosing a web developer, check out my new site-it might just save you from a costly mistake!

Originally published at https://blog.dave.org.uk on March 16, 2025.

I built and launched a new website yesterday. It wasn’t what I planned to do, but the idea popped into my head while I was drinking my morning coffee on Clapham Common and it seemed to be the kind of thing I could complete in a day – so I decided to put my original plans on hold and built it instead.

The website is aimed at small business owners who think they need a website (or want to update their existing one) but who know next to nothing about web development and can easily fall prey to the many cowboy website companies that seem to dominate the “making websites for small companies” section of our industries. The site is structured around a number of questions you can ask a potential website builder to try and weed out the dodgier elements.

I’m not really in that sector of our industry. But while writing the content for that site, it occurred to me that some people might be interested in the tools I use to build sites like this.

Content

I generally build websites about topics that I’m interested in and, therefore, know a fair bit about. But I probably don’t know everything about these subjects. So I’ll certainly brainstorm some ideas with ChatGPT. And, once I’ve written something, I’ll usually run it through ChatGPT again to proofread it. I consider myself a pretty good writer, but it’s embarrassing how often ChatGPT catches obvious errors.

I’ve used DALL-E (via ChatGPT) for a lot of image generation. This weekend, I subscribed to Midjourney because I heard it was better at generating images that include text. So far, that seems to be accurate.

Technology

I don’t write much raw HTML these days. I’ll generally write in Markdown and use a static site generator to turn that into a real website. This weekend I took the easy route and used Jekyll with the Minimal Mistakes theme. Honestly, I don’t love Jekyll, but it integrates well with GitHub Pages and I can usually get it to do what I want – with a combination of help from ChatGPT and reading the source code. I’m (slowly) building my own Static Site Generator (Aphra) in Perl. But, to be honest, I find that when I use it I can easily get distracted by adding new features rather than getting the site built.

As I’ve hinted at, if I’m building a static site (and, it’s surprising how often that’s the case), it will be hosted on GitHub Pages. It’s not really aimed at end-users, but I know how to use it pretty well now. This weekend, I used the default mechanism that regenerates the site (using Jekyll) on every commit. But if I’m using Aphra or a custom site generator, I know I can use GitHub Actions to build and deploy the site.

If I’m writing actual HTML, then I’m old-skool enough to still use Bootstrap for CSS. There’s probably something better out there now, but I haven’t tried to work out what it is (feel free to let me know in the comments).

For a long while, I used jQuery to add Javascript to my pages – until someone was kind enough to tell me that vanilla Javascript had mostly caught up and jQuery was no longer necessary. I understand Javascript. And with help from GitHub Copilot, I can usually get it doing what I want pretty quickly.

SEO

Many years ago, I spent a couple of years working in the SEO group at Zoopla. So, now, I can’t think about building a website without considering SEO.

I quickly lose interest in the content side of SEO. Figuring out what my keywords are and making sure they’re scattered through the content at the correct frequency, feels like it stifles my writing (maybe that’s an area where ChatGPT can help) but I enjoy Technical SEO. So I like to make sure that all of my pages contain the correct structured data (usually JSON-LD). I also like to ensure my sites all have useful OpenGraph headers. This isn’t really SEO, I guess, but these headers control what people see when they share content on social media. So by making that as attractive as possible (a useful title and description, an attractive image) it encourages more sharing, which increases your site’s visibility and, in around about way, improves SEO.

I like to register all of my sites with Ahrefs – they will crawl my sites periodically and send me a long list of SEO improvements I can make.

Monitoring

I add Google Analytics to all of my sites. That’s still the best way to find out how popular your site it and where your traffic is coming from. I used to be quite proficient with Universal Analytics, but I must admit I haven’t fully got the hang of Google Analytics 4 yet—so I’m probably only scratching the surface of what it can do.

I also register all of my sites with Google Search Console. That shows me information about how my site appears in the Google Search Index. I also link that to Google Analytics – so GA also knows what searches brought people to my sites.

Conclusion

I think that covers everything—though I’ve probably forgotten something. It might sound like a lot, but once you get into a rhythm, adding these extra touches doesn’t take long. And the additional insights you gain make it well worth the effort.

If you’ve built a website recently, I’d love to hear about your approach. What tools and techniques do you swear by? Are there any must-have features or best practices I’ve overlooked? Drop a comment below or get in touch—I’m always keen to learn new tricks and refine my process. And if you’re a small business owner looking for guidance on choosing a web developer, check out my new site—it might just save you from a costly mistake!

The post How I build websites in 2025 appeared first on Davblog.

At the end of my last post, we had a structure in place that used GitHub Actions to run a workflow every time a change was committed to the PPC repository. That workflow would rebuild the website and publish it on GitHub Pages.

All that was left for us to do was to write the middle bit – the part that actually takes the contents of the repo and creates the website. This involves writing some Perl.

There are three types of pages that we want to create:

• The PPCs themselves, which are in Markdown and need to be converted to HTML pages
• There are a few other pages that describe the PPC process, also in Markdown, which should be converted to HTML
• An index page which should contain links to the other pages. This page should include a table listing various useful details about the PPCs so visitors can quickly find the ones they want more information on

I’ll be using the Template Toolkit to build the site, with a sprinkling of Bootstrap to make it look half-decent. Because there is a lot of Markdown-to-HTML conversion, I’ll use my Template::Provider::Pandoc module which uses Pandoc to convert templates into different formats.

Parsing PPCs and extracting data

The first thing I did was parse the PPCs themselves, extracting the relevant information. Luckily, each PPC has a “preamble” section containing most of the data we need. I created a basic class to model PPCs which included a really hacky parser to extract this information and create a object of the class.

Building the site

This class abstracts away a lot of the complexity which means the program that actually builds the site is less than eighty lines of code. Let’s look at it in a bit more detail:

#!/usr/bin/perl

use v5.38;
use JSON;
use File::Copy;
use Template;
use Template::Provider::Pandoc;

use PPC;

There’s nothing unusual in the first few lines. We’re just loading the modules we’re using. Note that use v5.38 automatically enables strict and warnings, so we don’t need to load them explicitly.

my @ppcs;

my $outpath = './web';
my $template_path = [ './ppcs', './docs', './in', './ttlib' ];

Here, we’re just setting up some useful variables. @ppcs will contain the PPC objects that we create. One potential clean-up here is to reduce the size of that list of input directories.

my $base = shift || $outpath;
$base =~ s/^\.//;
$base = "/$base" if $base !~ m|^/|;
$base = "$base/" if $base !~ m|/$|;

This is a slightly messy hack that is used to set a <base> tag in the HTML.

my $provider = Template::Provider::Pandoc->new({
  INCLUDE_PATH => $template_path,
});

my $tt = Template->new({
  LOAD_TEMPLATES => [ $provider ],
  INCLUDE_PATH => $template_path,
  OUTPUT_PATH => $outpath,
  RELATIVE => 1,
  WRAPPER => 'page.tt',
  VARIABLES => {
    base => $base,
  }
});

Here, we’re setting up our Template Toolkit processor. Some of you may not be familiar with using a Template provider module. These modules change how TT retrieves templates: if the template has an .md extension, then the text is passed though Pandoc to convert it from Markdown to HTML before it’s handed to the template processor. It’s slightly annoying that we need to pass the template include path to both the provider and the main template engine.

for (<ppcs/*.md>) {
  my $ppc = PPC->new_from_file($_);
  push @ppcs, $ppc;

  $tt->process($ppc->in_path, {}, $ppc->out_path)
    or warn $tt->error;
}

This is where we process the actual PPCs. For each PPC we find in the /ppcs directory, we create a PPC object, store that in the @ppcs variable and process the PPC document as a template – converting it from Markdown to HTML and writing it to the /web directory.

my $vars = {
  ppcs => \@ppcs,
};

$tt->process('index.tt', $vars, 'index.html')
  or die $tt->error;

Here’s where we process the index.tt file to generate the index.html for our site. Most of the template is made up of a loop over the @ppcs variable to create a table of the PPCs.

for (<docs/*.md>) {
  s|^docs/||;
  my $out = s|\.md|/index.html|r;

  $tt->process($_, {}, $out)
    or die $tt->error;
}

There are a few other documents in the /docs directory describing the PPC process. So in this step, we iterate across the Markdown files in that directory and convert each of them into HTML. Unfortunately, one of them is the template.md which is intended to be used as the template for new PPCs – so it would be handy if that one wasn’t converted to HTML. That’s something to think about in the future.

mkdir 'web/images';
for (<images/*>) {
  copy $_, "web/$_";
}

if (-f 'in/style.css') {
  copy 'in/style.css', 'web/style.css';
}

if (-f 'CNAME') {
  copy 'CNAME', "web/CNAME";
}

We’re on the home straight now. And this section is a bit scrappy. You might recall from the last post that we’re building the website in the /web directory. And there are a few other files that need to be copied into that directory in order that they are then deployed to the web server. So we just copy files. You might not know what a CNAME file is – it’s the file that GitHub Pages uses to tell their web server that you’re serving your website from a custom domain name.

my $json = JSON->new->pretty->canonical->encode([
  map { $_->as_data } @ppcs
]);

open my $json_fh, '>', 'web/ppcs.json' or die $!;

print $json_fh $json;

And, finally, we generate a JSON version of our PPCs and write that file to the /web directory. No-one asked for this, but I thought someone might find this data useful. If you use this for something interesting, I’d love to hear about it.

Other bits and pieces

A few other bits and pieces to be aware of.

• I use a page wrapper to ensure that every generated page has a consistent look and feel
• The navigation in the page wrapper is hard-coded to contain links to the pages in /docs. It would make sense to change that so it’s generated from the contents of that directory
• I used a Javascript project called Simple Datatables to turn the main table into a data table. That means it’s easy to sort, page and filter the data that’s displayed
• There’s a basic hack that hides the email addresses when they appear in the main table. But it’s currently not applied to the PPC pages themselves. I’ve idly contemplated writing a TT filter that would be called something like Template::Filter::RemoveEmailAddresses

In conclusion

But there you are. That’s the system that I knocked together in a few hours a couple of weeks ago. As I mentioned in the last post, the idea was to make the PPC process more transparent to the Perl community outside of the Perl 5 Porters and the Perl Steering Council. I hope it achieves that and, further, I hope it does so in a way that keeps out of people’s way. As soon as someone updates one of the documents in the repository, the workflow will kick in and publish a new version of the website. There are a few grungy corners of the code and there are certainly some improvements that can be made. I’m hoping that once the pull request is merged, people will start proposing new pull requests to add new features.

The post Proposed Perl Changes (part 2) first appeared on Perl Hacks.

At the end of my last post, we had a structure in place that used GitHub Actions to run a workflow every time a change was committed to the PPC repository. That workflow would rebuild the website and publish it on GitHub Pages.

All that was left for us to do was to write the middle bit – the part that actually takes the contents of the repo and creates the website. This involves writing some Perl.

There are three types of pages that we want to create:

• The PPCs themselves, which are in Markdown and need to be converted to HTML pages
• There are a few other pages that describe the PPC process, also in Markdown, which should be converted to HTML
• An index page which should contain links to the other pages. This page should include a table listing various useful details about the PPCs so visitors can quickly find the ones they want more information on

I’ll be using the Template Toolkit to build the site, with a sprinkling of Bootstrap to make it look half-decent. Because there is a lot of Markdown-to-HTML conversion, I’ll use my Template::Provider::Pandoc module which uses Pandoc to convert templates into different formats.

Parsing PPCs and extracting data

The first thing I did was parse the PPCs themselves, extracting the relevant information. Luckily, each PPC has a “preamble” section containing most of the data we need. I created a basic class to model PPCs which included a really hacky parser to extract this information and create a object of the class.

Building the site

This class abstracts away a lot of the complexity which means the program that actually builds the site is less than eighty lines of code. Let’s look at it in a bit more detail:

#!/usr/bin/perl

use v5.38;
use JSON;
use File::Copy;
use Template;
use Template::Provider::Pandoc;

use PPC;

There’s nothing unusual in the first few lines. We’re just loading the modules we’re using. Note that use v5.38 automatically enables strict and warnings, so we don’t need to load them explicitly.

my @ppcs;

my $outpath = './web';
my $template_path = ['./ppcs', './docs', './in', './ttlib'];

Here, we’re just setting up some useful variables. @ppcs will contain the PPC objects that we create. One potential clean-up here is to reduce the size of that list of input directories.

my $base = shift || $outpath;
$base =~ s/^\.//;
$base = "/$base" if $base !~ m|^/|;
$base = "$base/" if $base !~ m|/$|;

This is a slightly messy hack that is used to set a <base> tag in the HTML.

my $provider = Template::Provider::Pandoc->new({
  INCLUDE_PATH => $template_path,
});

my $tt = Template->new({
  LOAD_TEMPLATES => [$provider],
  INCLUDE_PATH => $template_path,
  OUTPUT_PATH => $outpath,
  RELATIVE => 1,
  WRAPPER => 'page.tt',
  VARIABLES => {
    base => $base,
  }
});

Here, we’re setting up our Template Toolkit processor. Some of you may not be familiar with using a Template provider module. These modules change how TT retrieves templates: if the template has an .md extension, then the text is passed though Pandoc to convert it from Markdown to HTML before it’s handed to the template processor. It’s slightly annoying that we need to pass the template include path to both the provider and the main template engine.

for (<ppcs/*.md>) {
  my $ppc = PPC->new_from_file($_);
  push @ppcs, $ppc;

  $tt->process($ppc->in_path, {}, $ppc->out_path)
    or warn $tt->error;
}

This is where we process the actual PPCs. For each PPC we find in the /ppcs directory, we create a PPC object, store that in the @ppcs variable and process the PPC document as a template – converting it from Markdown to HTML and writing it to the /web directory.

my $vars = {
  ppcs => \@ppcs,
};

$tt->process('index.tt', $vars, 'index.html')
  or die $tt->error;

Here’s where we process the index.tt file to generate the index.html for our site. Most of the template is made up of a loop over the @ppcs variable to create a table of the PPCs.

for (<docs/*.md>) {
  s|^docs/||;
  my $out = s|\.md|/index.html|r;

  $tt->process($_, {}, $out)
    or die $tt->error;
}

There are a few other documents in the /docs directory describing the PPC process. So in this step, we iterate across the Markdown files in that directory and convert each of them into HTML. Unfortunately, one of them is the template.md which is intended to be used as the template for new PPCs – so it would be handy if that one wasn’t converted to HTML. That’s something to think about in the future.

mkdir 'web/images';
for (<images/*>) {
  copy $_, "web/$_";
}

if (-f 'in/style.css') {
  copy 'in/style.css', 'web/style.css';
}

if (-f 'CNAME') {
  copy 'CNAME', "web/CNAME";
}

We’re on the home straight now. And this section is a bit scrappy. You might recall from the last post that we’re building the website in the /web directory. And there are a few other files that need to be copied into that directory in order that they are then deployed to the web server. So we just copy files. You might not know what a CNAME file is – it’s the file that GitHub Pages uses to tell their web server that you’re serving your website from a custom domain name.

my $json = JSON->new->pretty->canonical->encode([
  map { $_->as_data } @ppcs
]);

open my $json_fh, '>', 'web/ppcs.json' or die $!;

print $json_fh $json;

And, finally, we generate a JSON version of our PPCs and write that file to the /web directory. No-one asked for this, but I thought someone might find this data useful. If you use this for something interesting, I’d love to hear about it.

Other bits and pieces

A few other bits and pieces to be aware of.

• I use a page wrapper to ensure that every generated page has a consistent look and feel
• The navigation in the page wrapper is hard-coded to contain links to the pages in /docs. It would make sense to change that so it’s generated from the contents of that directory
• I used a Javascript project called Simple Datatables to turn the main table into a data table. That means it’s easy to sort, page and filter the data that’s displayed
• There’s a basic hack that hides the email addresses when they appear in the main table. But it’s currently not applied to the PPC pages themselves. I’ve idly contemplated writing a TT filter that would be called something like Template::Filter::RemoveEmailAddresses

In conclusion

But there you are. That’s the system that I knocked together in a few hours a couple of weeks ago. As I mentioned in the last post, the idea was to make the PPC process more transparent to the Perl community outside of the Perl 5 Porters and the Perl Steering Council. I hope it achieves that and, further, I hope it does so in a way that keeps out of people’s way. As soon as someone updates one of the documents in the repository, the workflow will kick in and publish a new version of the website. There are a few grungy corners of the code and there are certainly some improvements that can be made. I’m hoping that once the pull request is merged, people will start proposing new pull requests to add new features.

The post Proposed Perl Changes (part 2) appeared first on Perl Hacks.

Many thanks to Dave Cross for providing an initial implementation of a PPC index page.

– Perl Steering Council meeting #177

Maybe I should explain that in a little more detail. There’s a lot of detail, so it will take a couple of blog posts.

About two weeks ago, I got a message on Slack from Phillippe Bruhat, a member of the Perl Steering Council. He asked if I would have time to look into building a simple static site based on the GitHub repo that stores the PPCs that are driving a lot of Perl’s development. The PSC thought that reading these important documents on a GitHub page wasn’t a great user experience and that turning it into a website might lead to more people reading the proposals and, hence, getting involved in discussions about them.

I guess they had thought of me as I’ve written a bit about GitHub Pages and GitHub Actions over the last few years and these were exactly the technologies that would be useful in this project. In fact, I have already created a website that fulfills a similar role for the PSC meeting minutes – and I know they know about that site because they’ve been maintaining it themselves for several months.

I was about to start working with a new client, but I had a spare day, so I said I’d be happy to help. And the following day, I set to work.

Reviewing the situation

I started by looking at what was in the repo.

• A README file
• The PPCs themselves
• A few other pages of documentation

All of these documents were in Markdown format. The PPCs seemed to have a pretty standardised format.

Setting a target

Next, I listed what would be essential parts of the new site.

• An index page containing a list of the PPCs – which links to a page for each of the PPCs
• The PPCs, converted to HTML
• The other documents, also converted to HTML
• The site should be automatically rebuilt whenever a change is made to any of the input files

This is exactly the kind of use case that a combination of GitHub Pages and GitHub Actions is perfect for. Perhaps it’s worth briefly describing what those two GitHub features are.

Introducing GitHub Pages

GitHub Pages is a way to run a website from a GitHub repo. The feature was initially introduced to make it easy to run a project website alongside your GitHub repo – with the files that make up the website being stored in the same repo as the rest of your code. But, as often happens with useful features, people have been using the feature for all sorts of websites. The only real restriction is that it only supports static sites – you cannot use GitHub’s servers to run any kind of back-end processing.

The simplest way to run a GitHub Pages website is to construct it manually, put the HTML, CSS and other files into a directory inside your repo called /docs, commit those files and go to the “Settings -> Pages” settings for your repo to turn on Pages for the repo. Within minutes your site will appear at the address USERNAME.github.repo/REPONAME. Almost no-one uses that approach.

The most common approach is to use a static site builder to build your website. The most popular is Jekyll – which is baked into the GitHub Pages build/deploy cycle. You edit Markdown files and some config files. Then each time you commit a change to the repo, GitHub will automatically run Jekyll over your input files, generate your website and deploy that to its web servers. We’re not going to do that.

We’ll use the approach I’ve used for many GitHub Pages sites. We’ll use GitHub Actions to do the equivalent of the “running Jekyll over your input files to generate your website” step. This gives us more flexibility and, in particular, allows us to generate the website using Perl.

Introducing GitHub Actions

GitHub Actions is another feature that was introduced with one use case in mind but which has expanded to be used for an incredible range of ideas. It was originally intended for CI/CD – a replacement for systems like Jenkins or Travis CI – but that only accounts for about half of the things I use it for.

A GitHub Actions run starts in response to various triggers. You can then run pretty much any code you want on a virtual machine, generating useful reports, updating databases, releasing code or (as in this case) generating a website.

GitHub Actions is a huge subject (luckily, there’s a book!) We’re only going to touch on one particular way of using it. Our workflow will be:

• Wait for a commit to the repo
• Then regenerate the website
• And publish it to the GitHub Pages web servers

Making a start

Let’s make a start on creating a GitHub Actions workflow to deal with this. Workflows are defined in YAML files that live in the .github/workflows directory in our repo. So I created the relevant directories and a file called buildsite.yml.

There will be various sections in this file. We’ll start simply by defining a name for this workflow:

name: Generate website

The next section tells GitHub when to trigger this workflow. We want to run it when a commit is pushed to the “main” branch. We’ll also add the “workflow_dispatch” trigger, which allows us to manually trigger the workflow – it adds a button to the workflow’s page inside the repo:

on:
  push:
    branches: 'main'
  workflow_dispatch:

The main part of the workflow definition is the next section – the one that defines the jobs and the individual steps within them. The start of that section looks like this:

jobs:
  build:
    runs-on: ubuntu-latest
    container: perl:latest

    steps:
    - name: Perl version
      run: perl -v

    - name: Checkout
      uses: actions/checkout@v4

The “build” there is the name of the first job. You can name jobs anything you like – well anything that can be the name of a valid YAML key. We then define the working environment for this job – we’re using a Ubuntu virtual machine and on that, we’re going to download and run the latest Perl container from the Docker Hub.

The first step isn’t strictly necessary, but I like to have a simple but useful step to ensure that everything is working. This one just prints the Perl version to the workflow log. The second step is one you’ll see in just about every GitHub Actions workflow. It uses a standard, prepackaged library (called an “action”) to clone the repo to the container.

The rest of this job will make much more sense once I’ve described the actual build process in my next post. But here it is for completeness:

- name: Install pandoc and cpanm
      run: apt-get update && apt-get install -y pandoc cpanminus

    - name: Install modules
      run: |
        cpanm --installdeps --notest .

    - name: Get repo name into environment
      run: |
        echo "REPO_NAME=${GITHUB_REPOSITORY#$GITHUB_REPOSITORY_OWNER/}" >> $GITHUB_ENV

    - name: Create pages
      env:
        PERL5LIB: lib
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        mkdir -p web
        perl bin/build $REPO_NAME

    - name: Update pages artifact
      uses: actions/upload-pages-artifact@v3
      with:
        path: web/

Most of the magic (and all of the Perl – for those of you who were wondering) happens in the “Create pages” step. If you can’t wait until the next post, you can find the build program and the class it uses in the repo.

But for now, let’s skim over that and look at the final step in this job. That uses another pre-packaged action to build an artifact (which is just a tarball) which the next job will deploy to the GitHub Pages web server. You can pass it the name of a directory and it will build the artifact from that directory. So you can see that we’ll be building the web pages in the web/ directory.

The second (and final) job is the one that actually carries out the deployment. It looks like this:

deploy:
    needs: build
    permissions:
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

It uses another standard, pre-packaged action and most of the code here is configuration. One interesting line is the “need” key. That tells the workflow engine that the “build” job needs to have completed successfully before this job can be run.

But once it has run, the contents of our web/ directory will be on the GitHub Pages web server and available for our adoring public to read.

All that is left is for us to write the steps that will generate the website. And that is what we’ll be covering in my next post.

Oh, and if you want to preview the site itself, it’s at https://davorg.dev/PPCs/ and there’s an active pull request to merge it into the main repo.

The post Proposed Perl Changes first appeared on Perl Hacks.

Many thanks to Dave Cross for providing an initial implementation of a PPC index page.

– Perl Steering Council meeting #177

Maybe I should explain that in a little more detail. There’s a lot of detail, so it will take a couple of blog posts.

About two weeks ago, I got a message on Slack from Phillippe Bruhat, a member of the Perl Steering Council. He asked if I would have time to look into building a simple static site based on the GitHub repo that stores the PPCs that are driving a lot of Perl’s development. The PSC thought that reading these important documents on a GitHub page wasn’t a great user experience and that turning it into a website might lead to more people reading the proposals and, hence, getting involved in discussions about them.

I guess they had thought of me as I’ve written a bit about GitHub Pages and GitHub Actions over the last few years and these were exactly the technologies that would be useful in this project. In fact, I have already created a website that fulfills a similar role for the PSC meeting minutes – and I know they know about that site because they’ve been maintaining it themselves for several months.

I was about to start working with a new client, but I had a spare day, so I said I’d be happy to help. And the following day, I set to work.

Reviewing the situation

I started by looking at what was in the repo.

• A README file
• The PPCs themselves
• A few other pages of documentation

All of these documents were in Markdown format. The PPCs seemed to have a pretty standardised format.

Setting a target

Next, I listed what would be essential parts of the new site.

• An index page containing a list of the PPCs – which links to a page for each of the PPCs
• The PPCs, converted to HTML
• The other documents, also converted to HTML
• The site should be automatically rebuilt whenever a change is made to any of the input files

This is exactly the kind of use case that a combination of GitHub Pages and GitHub Actions is perfect for. Perhaps it’s worth briefly describing what those two GitHub features are.

Introducing GitHub Pages

GitHub Pages is a way to run a website from a GitHub repo. The feature was initially introduced to make it easy to run a project website alongside your GitHub repo – with the files that make up the website being stored in the same repo as the rest of your code. But, as often happens with useful features, people have been using the feature for all sorts of websites. The only real restriction is that it only supports static sites – you cannot use GitHub’s servers to run any kind of back-end processing.

The simplest way to run a GitHub Pages website is to construct it manually, put the HTML, CSS and other files into a directory inside your repo called /docs, commit those files and go to the “Settings -> Pages” settings for your repo to turn on Pages for the repo. Within minutes your site will appear at the address USERNAME.github.repo/REPONAME. Almost no-one uses that approach.

The most common approach is to use a static site builder to build your website. The most popular is Jekyll – which is baked into the GitHub Pages build/deploy cycle. You edit Markdown files and some config files. Then each time you commit a change to the repo, GitHub will automatically run Jekyll over your input files, generate your website and deploy that to its web servers. We’re not going to do that.

We’ll use the approach I’ve used for many GitHub Pages sites. We’ll use GitHub Actions to do the equivalent of the “running Jekyll over your input files to generate your website” step. This gives us more flexibility and, in particular, allows us to generate the website using Perl.

Introducing GitHub Actions

GitHub Actions is another feature that was introduced with one use case in mind but which has expanded to be used for an incredible range of ideas. It was originally intended for CI/CD – a replacement for systems like Jenkins or Travis CI – but that only accounts for about half of the things I use it for.

A GitHub Actions run starts in response to various triggers. You can then run pretty much any code you want on a virtual machine, generating useful reports, updating databases, releasing code or (as in this case) generating a website.

GitHub Actions is a huge subject (luckily, there’s a book!) We’re only going to touch on one particular way of using it. Our workflow will be:

• Wait for a commit to the repo
• Then regenerate the website
• And publish it to the GitHub Pages web servers

Making a start

Let’s make a start on creating a GitHub Actions workflow to deal with this. Workflows are defined in YAML files that live in the .github/workflows directory in our repo. So I created the relevant directories and a file called buildsite.yml.

There will be various sections in this file. We’ll start simply by defining a name for this workflow:

name: Generate website

The next section tells GitHub when to trigger this workflow. We want to run it when a commit is pushed to the “main” branch. We’ll also add the “workflow_dispatch” trigger, which allows us to manually trigger the workflow – it adds a button to the workflow’s page inside the repo:

on:
  push:
    branches: 'main'
  workflow_dispatch:

The main part of the workflow definition is the next section – the one that defines the jobs and the individual steps within them. The start of that section looks like this:

jobs:
  build:
    runs-on: ubuntu-latest
    container: perl:latest

    steps:
    - name: Perl version
      run: perl -v

    - name: Checkout
      uses: actions/checkout@v4

The “build” there is the name of the first job. You can name jobs anything you like – well anything that can be the name of a valid YAML key. We then define the working environment for this job – we’re using a Ubuntu virtual machine and on that, we’re going to download and run the latest Perl container from the Docker Hub.

The first step isn’t strictly necessary, but I like to have a simple but useful step to ensure that everything is working. This one just prints the Perl version to the workflow log. The second step is one you’ll see in just about every GitHub Actions workflow. It uses a standard, prepackaged library (called an “action”) to clone the repo to the container.

The rest of this job will make much more sense once I’ve described the actual build process in my next post. But here it is for completeness:

- name: Install pandoc and cpanm
      run: apt-get update && apt-get install -y pandoc cpanminus

    - name: Install modules
      run: |
        cpanm --installdeps --notest .

    - name: Get repo name into environment
      run: |
        echo "REPO_NAME=${GITHUB_REPOSITORY#$GITHUB_REPOSITORY_OWNER/}" >> $GITHUB_ENV

    - name: Create pages
      env:
        PERL5LIB: lib
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        mkdir -p web
        perl bin/build $REPO_NAME

    - name: Update pages artifact
      uses: actions/upload-pages-artifact@v3
      with:
        path: web/

Most of the magic (and all of the Perl – for those of you who were wondering) happens in the “Create pages” step. If you can’t wait until the next post, you can find the build program and the class it uses in the repo.

But for now, let’s skim over that and look at the final step in this job. That uses another pre-packaged action to build an artifact (which is just a tarball) which the next job will deploy to the GitHub Pages web server. You can pass it the name of a directory and it will build the artifact from that directory. So you can see that we’ll be building the web pages in the web/ directory.

The second (and final) job is the one that actually carries out the deployment. It looks like this:

deploy:
    needs: build
    permissions:
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

It uses another standard, pre-packaged action and most of the code here is configuration. One interesting line is the “need” key. That tells the workflow engine that the “build” job needs to have completed successfully before this job can be run.

But once it has run, the contents of our web/ directory will be on the GitHub Pages web server and available for our adoring public to read.

All that is left is for us to write the steps that will generate the website. And that is what we’ll be covering in my next post.

Oh, and if you want to preview the site itself, it’s at https://davorg.dev/PPCs/ and there’s an active pull request to merge it into the main repo.

The post Proposed Perl Changes appeared first on Perl Hacks.

If you have a website, then it’s very likely that you would like as many people as possible to see it. One of the best tools for achieving that is to ensure that your site is returned close to the top of as many search results pages as possible.

In order to do that, you really have two targets:

1. Ensure the search engines know what your website is about
2. Ensure the search engines think your website is an important source of information on the topics it covers

The second item on the list is mostly about getting other websites on the same topic to link to you – and it is outside the scope of this post. In this post, I want to talk about a good way to ensure search engines know what your site is about.

Of course, the search engines have invested a lot of money in working that out for themselves. They scan the text on your site and processes it to extract the meaning. But there are various ways you can make it easier for them. And they like sites that make their lives easier.

One of the most powerful ways to achieve this is to add structured data to your site. That means adding extra mark-up to your web pages which explains what the page is about. On the Schema.org website, you can find dozens of “things” the you can describe in structured data – for example, here is the definition of the Person entity. Each entity has a number of (largely optional) properties which can be included in structured data about an object of that type. Each property can be a string or another structured data entity. Additionally, entities are arranged in a hierarchy, so one entity can be based on another, more generic, entity. A Person, for example, inherits all of the properties of a Thing (which is the most generic type of entity). This is a lot like inheritance in Object-Oriented Programming.

Perhaps most usefully, the definition of each entity type ends with some examples of how structured data about an entity of that type could be added to an HTML document. The examples cover three formats:

1. Microdata. This involved adding a lot of new attributes to various elements in the HTML (you might also add more <span> and <div> elements in order to have a place to put these attributes. These attributes have names like “itemscope”, “itemtype” and “itemprop”.
2. RDFa. This looks a lot like microdata, but the attributes have different names – “vocab”, “typeof” and “property”.
3. JSON-LD. This is different from the other two formats. It is not added to the existing mark-up, but it is a separate element which contains JSON defining the entities on the page.

Because it is completely separate to the existing mark-up, I find JSON-LD to be easier to work with. And for that reason, I wrote MooX::Role::JSON_LD which makes it easy to generate JSON-LD for classes that are based on Moo or Moose. Let’s look at a simple example of using it to add Person JSON-LD to a web page of a person. We’ll assume we already have a Person class that we use to provide the data on a web page about a person. It has attributes first_name, last_name and birth_date.

We start with some configuration. We load the role and define two subroutines which tell us which entity type we’re working with and which attributes we want to include in the JSON-LD. The code might look like this:

with 'MooX::Role::JSON_LD';

sub json_ld_type { 'Person' };

sub json_ld_fields { [ qw[ first_name last_name birth_date ] ] };

We can now use our Person class like this:

use Person;

my $bowie = Person->new({
  first_name => 'David',
  last_name  => 'Bowie',
  birth_date => '1947-01-08',
});

say $bowie->json_ld;

This produces the following output:

{
   "@context" : "http://schema.org/",
   "@type" : "Person",
   "first_name" : "David",
   "last_name" : "Bowie",
   "birth_date" : "1947-01-08"
}

This looks pretty good. But, sadly, it’s not valid JSON-LD. In the Schema.org Person entity, the relevant properties are called “givenName”, “familyName” and “birthDate”. Obviously, if we were designing our class from scratch, we could create attributes with those names. But often we’re adding features to existing systems and we don’t have that luxury. So the role allows us to change the names of attributes before they appear in the JSON-LD. We need to look more closely at the json_ld_fields() subroutine. It defines the names of the attributes that will appear in the JSON-LD. It returns an array reference and each element of the array contains a string which is the name of an attribute. But one of these elements can also contain a hash reference. In that case, the key of the hash is the name of the property we want to appear in the JSON-LD and the value is the name of the matching attribute in our class. So we can redefine our subroutine to look like this:

sub json_ld_fields {
    [
      { givenName  => 'first_name' },
      { familyName => 'last_name' },
      { birthDate  => 'birth_date' },
    ]
}

And now we get the following JSON-LD:

{
  "@context" : "http://schema.org/",
  "@type" : "Person",
  "givenName" : "David",
  "familyName" : "Bowie",
  "birthDate" : "1947-01-08"
}

Which is now valid.

There’s one other trick we can use. We’ve seen the Schema.org Person entity has a “firstName” and “lastName” properties which map directly onto our “first_name” and “last_name” attributes. But the Person entity inherits from the Thing entity and that has a property called “name” which might be more useful for us. So perhaps we want to combine the “first_name” and “last_name” attributes into the single JSON-LD property. We can do that by changing our json_ld_fields() subroutine again:

sub json_ld_fields {
    [
      { birthDate => 'birth_date'},
      { name => sub { $_[0]->first_name . ' ' . $_[0]->last_name} },
    ]
  }

In this version, we’ve added the “name” as the key of a hashref and the value is an anonymous subroutine that is passed the object and returns the name by concatenating the first and last names separated by a space. We now get this JSON-LD:

{
  "@context" : "http://schema.org/",
  "@type" : "Person",
  "birthDate" : "1947-01-08"
  "name" : "David Bowie",
}

Using this approach, allows us to build arbitrary JSON-LD properties from a combination of attributes from our object’s attributes.

Let’s look at a real-world example (and the reason why I was reminded of this module’s existence earlier this week.

I have a website called ReadABooker. It’s about the books that compete for the Booker Prize. Each year, a shortlist of six novels is announced and, later in the year, a winner is chosen. The winning author gets £50,000 and all of the shortlisted novels get massively increased sales. It’s a big deal in British literary circles. I created the website a few years ago. It lists all of the events (the competition goes back to 1969) and for each year, it lists all of the shortlisted novels. You can also see all of the authors who have been shortlisted and which of their shortlisted novels have won the prize. Each novel has a “Buy on Amazon” button and that link includes my associate ID – so, yes, it’s basically an attempt to make money out of people who want to buy Booker shortlisted novels.

But it’s not working. It’s not working because not enough people know about the site. So last week I decided to do a bit of SEO work on the site. And the obvious improvement was to add JSON-LD for the book and author pages.

The site itself is fully static. It gets updated twice a year – once when the shortlist is announced and then again when the winner is announced (the second update is literally setting a flag on a database row). The data about the novels is stored in an SQLite database. And there are DBIx::Class classes that allow me to access that data. So the obvious place to add the JSON-LD code is in Booker::Schema::Result::Book and Booker::Schema::Result::Person (a person can exist in the database if they have been an author, a judge or both).

The changes for the Person class were trivial. I don’t actually hold much information about the people in the database.

with 'MooX::Role::JSON_LD';

sub json_ld_type { 'Person' }

sub json_ld_fields {
  [
    qw/name/,
  ];
}

The changes in the Book class have one interesting piece of code:

with 'MooX::Role::JSON_LD';

sub json_ld_type { 'Book' }

sub json_ld_fields {
  [
    { name => 'title' },
    { author => sub {
      $_[0]->author->json_ld_data }
    },
    { isbn => 'asin' },
  ];
}

The link between a book and its author is obviously important. But in the database, that link is simply represented by a foreign key in the book table. Having something like “author : 23” in the JSON-LD would be really unhelpful, so we take advantage of the link between the book and the author that DBIx::Class has given us and call the json_ld_data() method on the book’s author object. This method (which is added to any class that uses the role) returns the raw data structure which is later passed to a JSON encoder to produce the JSON-LD. So by calling that method inside the anonymous subroutine that creates the “author” attribute we can reuse that data in our book data.

The Person class creates JSON-LD like this:

{
   "@context" : "http://schema.org/",
   "@type" : "Person",
   "name" : "Theresa Mary Anne Smith"
}

And the Book class creates JSON-LD like this:

{
   "@context" : "http://schema.org/",
   "@type" : "Book",
   "author" : {
      "@context" : "http://schema.org/",
      "@type" : "Person",
      "name" : "Theresa Mary Anne Smith"
   },
   "isbn" : "B086PB2X8F",
   "name" : "Office Novice"
}

There were two more changes needed. We needed to get the JSON-LD actually onto the HTML pages. The site is created using the Template Toolkit and the specific templates are author.html.tt and title.html.tt. Adding the JSON-LD to these pages was as simple as adding one line to each template:

[% author.json_ld_wrapped -%]

And

[% book.json_ld_wrapped -%]

We haven’t mentioned the json_ld_wrapped() method yet. Let me explain the hierarchy of the three main methods that the role adds to a class.

• json_ld_data() returns the raw Perl data structure that contains the data that will be displayed in the JSON-LD
• json_ld() takes the value returned from json_ld_data() and encodes it into a JSON document
• json_ld_wrapped() takes the JSON returned from json_ld() and wraps it in the <script type="application/ld+json">..</script> tag that is used to embed JSON-LD in HTML. This is the method that you usually want to call from whatever is generating your HTML

And that’s how I added JSON-LD to my website pretty easily. I now need to wait and see just how effective these changes will be. Hopefully thousands of people will be buying books through my site in the coming weeks and I can sit back and stop having to write code for a living.

It’s the dream!

How about you? Which of your websites would benefit from the addition of a few carefully-crafted pieces of JSON-LD?

The post Adding structured data with Perl first appeared on Perl Hacks.

If you have a website, then it’s very likely that you would like as many people as possible to see it. One of the best tools for achieving that is to ensure that your site is returned close to the top of as many search results pages as possible.

In order to do that, you really have two targets:

1. Ensure the search engines know what your website is about
2. Ensure the search engines think your website is an important source of information on the topics it covers

The second item on the list is mostly about getting other websites on the same topic to link to you – and it is outside the scope of this post. In this post, I want to talk about a good way to ensure search engines know what your site is about.

Of course, the search engines have invested a lot of money in working that out for themselves. They scan the text on your site and processes it to extract the meaning. But there are various ways you can make it easier for them. And they like sites that make their lives easier.

One of the most powerful ways to achieve this is to add structured data to your site. That means adding extra mark-up to your web pages which explains what the page is about. On the Schema.org website, you can find dozens of “things” the you can describe in structured data – for example, here is the definition of the Person entity. Each entity has a number of (largely optional) properties which can be included in structured data about an object of that type. Each property can be a string or another structured data entity. Additionally, entities are arranged in a hierarchy, so one entity can be based on another, more generic, entity. A Person, for example, inherits all of the properties of a Thing (which is the most generic type of entity). This is a lot like inheritance in Object-Oriented Programming.

Perhaps most usefully, the definition of each entity type ends with some examples of how structured data about an entity of that type could be added to an HTML document. The examples cover three formats:

1. Microdata. This involved adding a lot of new attributes to various elements in the HTML (you might also add more <span> and <div> elements in order to have a place to put these attributes. These attributes have names like “itemscope”, “itemtype” and “itemprop”.
2. RDFa. This looks a lot like microdata, but the attributes have different names – “vocab”, “typeof” and “property”.
3. JSON-LD. This is different from the other two formats. It is not added to the existing mark-up, but it is a separate element which contains JSON defining the entities on the page.

Because it is completely separate to the existing mark-up, I find JSON-LD to be easier to work with. And for that reason, I wrote MooX::Role::JSON_LD which makes it easy to generate JSON-LD for classes that are based on Moo or Moose. Let’s look at a simple example of using it to add Person JSON-LD to a web page of a person. We’ll assume we already have a Person class that we use to provide the data on a web page about a person. It has attributes first_name, last_name and birth_date.

We start with some configuration. We load the role and define two subroutines which tell us which entity type we’re working with and which attributes we want to include in the JSON-LD. The code might look like this:

with 'MooX::Role::JSON_LD';

sub json_ld_type { 'Person' };

sub json_ld_fields { [qw[ first_name last_name birth_date] ] };

We can now use our Person class like this:

use Person;

my $bowie = Person->new({
  first_name => 'David',
  last_name => 'Bowie',
  birth_date => '1947-01-08',
});

say $bowie->json_ld;

This produces the following output:

{
   "@context" : "http://schema.org/",
   "@type" : "Person",
   "first_name" : "David",
   "last_name" : "Bowie",
   "birth_date" : "1947-01-08"
}

This looks pretty good. But, sadly, it’s not valid JSON-LD. In the Schema.org Person entity, the relevant properties are called “givenName”, “familyName” and “birthDate”. Obviously, if we were designing our class from scratch, we could create attributes with those names. But often we’re adding features to existing systems and we don’t have that luxury. So the role allows us to change the names of attributes before they appear in the JSON-LD. We need to look more closely at the json_ld_fields() subroutine. It defines the names of the attributes that will appear in the JSON-LD. It returns an array reference and each element of the array contains a string which is the name of an attribute. But one of these elements can also contain a hash reference. In that case, the key of the hash is the name of the property we want to appear in the JSON-LD and the value is the name of the matching attribute in our class. So we can redefine our subroutine to look like this:

sub json_ld_fields {
    [
      { givenName => 'first_name' },
      { familyName => 'last_name' },
      { birthDate => 'birth_date' },
    ]
}

And now we get the following JSON-LD:

{
  "@context" : "http://schema.org/",
  "@type" : "Person",
  "givenName" : "David",
  "familyName" : "Bowie",
  "birthDate" : "1947-01-08"
}

Which is now valid.

There’s one other trick we can use. We’ve seen the Schema.org Person entity has a “firstName” and “lastName” properties which map directly onto our “first_name” and “last_name” attributes. But the Person entity inherits from the Thing entity and that has a property called “name” which might be more useful for us. So perhaps we want to combine the “first_name” and “last_name” attributes into the single JSON-LD property. We can do that by changing our json_ld_fields() subroutine again:

sub json_ld_fields {
    [
      { birthDate => 'birth_date'},
      { name => sub { $_[0]->first_name . ' ' . $_[0]->last_name} },
    ]
  }

In this version, we’ve added the “name” as the key of a hashref and the value is an anonymous subroutine that is passed the object and returns the name by concatenating the first and last names separated by a space. We now get this JSON-LD:

{
  "@context" : "http://schema.org/",
  "@type" : "Person",
  "birthDate" : "1947-01-08"
  "name" : "David Bowie",
}

Using this approach, allows us to build arbitrary JSON-LD properties from a combination of attributes from our object’s attributes.

Let’s look at a real-world example (and the reason why I was reminded of this module’s existence earlier this week.

I have a website called ReadABooker. It’s about the books that compete for the Booker Prize. Each year, a shortlist of six novels is announced and, later in the year, a winner is chosen. The winning author gets £50,000 and all of the shortlisted novels get massively increased sales. It’s a big deal in British literary circles. I created the website a few years ago. It lists all of the events (the competition goes back to 1969) and for each year, it lists all of the shortlisted novels. You can also see all of the authors who have been shortlistedand which of their shortlisted novels have won the prize. Each novel has a “Buy on Amazon” button and that link includes my associate ID – so, yes, it’s basically an attempt to make money out of people who want to buy Booker shortlisted novels.

But it’s not working. It’s not working because not enough people know about the site. So last week I decided to do a bit of SEO work on the site. And the obvious improvement was to add JSON-LD for the book and author pages.

The site itself is fully static. It gets updated twice a year – once when the shortlist is announced and then again when the winner is announced (the second update is literally setting a flag on a database row). The data about the novels is stored in an SQLite database. And there are DBIx::Class classes that allow me to access that data. So the obvious place to add the JSON-LD code is in Booker::Schema::Result::Book and Booker::Schema::Result::Person (a person can exist in the database if they have been an author, a judge or both).

The changes for the Person class were trivial. I don’t actually hold much information about the people in the database.

with 'MooX::Role::JSON_LD';

sub json_ld_type { 'Person' }

sub json_ld_fields {
  [
    qw/name/,
  ];
}

The changes in the Book class have one interesting piece of code:

with 'MooX::Role::JSON_LD';

sub json_ld_type { 'Book' }

sub json_ld_fields {
  [
    { name => 'title' },
    { author => sub {
      $_[0]->author->json_ld_data }
    },
    { isbn => 'asin' },
  ];
}

The link between a book and its author is obviously important. But in the database, that link is simply represented by a foreign key in the book table. Having something like “author : 23” in the JSON-LD would be really unhelpful, so we take advantage of the link between the book and the author that DBIx::Class has given us and call the json_ld_data() method on the book’s author object. This method (which is added to any class that uses the role) returns the raw data structure which is later passed to a JSON encoder to produce the JSON-LD. So by calling that method inside the anonymous subroutine that creates the “author” attribute we can reuse that data in our book data.

The Person class creates JSON-LD like this:

{
   "@context" : "http://schema.org/",
   "@type" : "Person",
   "name" : "Theresa Mary Anne Smith"
}

And the Book class creates JSON-LD like this:

{
   "@context" : "http://schema.org/",
   "@type" : "Book",
   "author" : {
      "@context" : "http://schema.org/",
      "@type" : "Person",
      "name" : "Theresa Mary Anne Smith"
   },
   "isbn" : "B086PB2X8F",
   "name" : "Office Novice"
}

There were two more changes needed. We needed to get the JSON-LD actually onto the HTML pages. The site is created using the Template Toolkit and the specific templates are author.html.tt and title.html.tt. Adding the JSON-LD to these pages was as simple as adding one line to each template:

[% author.json_ld_wrapped -%]

And

[% book.json_ld_wrapped -%]

We haven’t mentioned the json_ld_wrapped() method yet. Let me explain the hierarchy of the three main methods that the role adds to a class.

• json_ld_data() returns the raw Perl data structure that contains the data that will be displayed in the JSON-LD
• json_ld() takes the value returned from json_ld_data() and encodes it into a JSON document
• json_ld_wrapped() takes the JSON returned from json_ld() and wraps it in the <script type="application/ld+json">..</script> tag that is used to embed JSON-LD in HTML. This is the method that you usually want to call from whatever is generating your HTML

And that’s how I added JSON-LD to my website pretty easily. I now need to wait and see just how effective these changes will be. Hopefully thousands of people will be buying books through my site in the coming weeks and I can sit back and stop having to write code for a living.

It’s the dream!

How about you? Which of your websites would benefit from the addition of a few carefully-crafted pieces of JSON-LD?

The post Adding structured data with Perl appeared first on Perl Hacks.

The London Perl Mongers have had a website for a very long time. Since some time in 1998, I think. At first, I hosted a static site for us. Later on, we bought our own server and hosted it at a friendly company around Silicon Roundabout. But for most of the lifetime of the organisation, it’s been hosted on a server donated to us by Exonetric (for which we are extremely grateful).

But all good things come to an end. And last week, we got an email saying the Exonetric was closing down and we would need to find alternative hosting by the end of February.

The code for the site is on GitHub, so I had a quick look at it to see if there was anything easy we could do.

I was slightly surprised to find it was a PSGI application. Albeit a really simple PSGI application that basically served content from a /root directory, having passed it through some light Template Toolkit processing first. Converting this to a simple static site that could be hosted on GitHub Pages was going to be simple.

Really, all it needed was a ttree configuration file that reads all of the files from /root, processes them and writes the output to /docs. The configuration file I created looked like this:

src = root
dest = docs

copy = \.(gif|png|jpg|pdf|css|js)$
copy = ^CNAME$

recurse

verbose

To be honest, most of the static web site work I do these days uses a static site builder that’s rather more complex than that, so it was really refreshing to remind myself that you can do useful things with tools as simple as ttree.

The next step was to add a GitHub Actions workflow that publishes the site to the GitHub Pages server each time something changes. That’s all pretty standard stuff too:

name: Generate web page

on:
  push:
    branches: 'master'
  workflow_dispatch:

jobs:
  build:
    if: github.repository_owner == 'LondonPM'
    runs-on: ubuntu-latest

    steps:
      - name: Install TT
        run: |
          sudo apt-get update
          sudo apt-get -y install libtemplate-perl

      - name: Checkout
        uses: actions/checkout@v4

      - name: Create pages
        run: ttree -f ttreerc 2>&1 > ttree.log

      - name: Archive ttree logs
        uses: actions/upload-artifact@v4
        with:
          name: ttree.log
          path: ./ttree.log
          retention-days: 3

      - name: Update pages artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: docs/

  deploy:
    needs: build
      if: github.repository_owner == 'LondonPM'
      permissions:
        pages: write
        id-token: write
      environment:
        name: github-pages
        url: ${{ steps.deployment.outputs.page_url }}
      runs-on: ubuntu-latest
      steps:
        - name: Deploy to GitHub Pages
          id: deployment
          uses: actions/deploy-pages@v4

The only slightly complex lines here are the two lines that say if: github.repository_owner == 'LondonPM'. We’re hoping that other people will fork this repo in order to work on the site, but it’s only the main fork that should attempt to publish the current version on the GitHub Pages servers.

There was a bit of fiddling with DNS. Temporarily, we used the domain londonperl.com as a test deployment (because I’m the kind of person who just happens to have potentially useful domains lying around, unused!) but enough of us are slightly obsessed about using the correct TLD so we’ve settled on londonperl.org[*]. We’ve asked the nice people at the Perl NOC to redirect our old domain to the new one.

And it’s all working (well, with the exception of the redirection of the old domain). Thanks to Sue, Lee and Leo for the work they’ve done in the last few days to get it all working. And a big thanks to Mark and Exonetric for hosting the site for us for the last couple of decades.

These changes are already having the desired effect. People are submitting pull requests to update the website. Our website is probably more up-to-date than it has been for far too long. It’s even responsive now.

I realise there has been very little Perl in this post. But I thought it might be useful for other Perl Mongers groups who are looking for a simple (and free!) space to host their websites. Please let me know if you have any questions about the process.

[*] We wanted to use Cloudflare to manage the domain but their free service only supports top-level domains and london.pm.org (our original domain) is a subdomain – and none of us wanted to pay for the enterprise version.

The post London Perl Mongers on GitHub Pages first appeared on Perl Hacks.

The London Perl Mongers have had a website for a very long time. Since some time in 1998, I think. At first, I hosted a static site for us. Later on, we bought our own server and hosted it at a friendly company around Silicon Roundabout. But for most of the lifetime of the organisation, it’s been hosted on a server donated to us by Exonetric (for which we are extremely grateful).

But all good things come to an end. And last week, we got an email saying the Exonetric was closing down and we would need to find alternative hosting by the end of February.

The code for the site is on GitHub, so I had a quick look at it to see if there was anything easy we could do.

I was slightly surprised to find it was a PSGI application. Albeit a really simple PSGI application that basically served content from a /root directory, having passed it through some light Template Toolkit processing first. Converting this to a simple static site that could be hosted on GitHub Pages was going to be simple.

Really, all it needed was a ttree configuration file that reads all of the files from /root, processes them and writes the output to /docs. The configuration file I created looked like this:

src = root
dest = docs

copy = \.(gif|png|jpg|pdf|css|js)$
copy = ^CNAME$

recurse

verbose

To be honest, most of the static web site work I do these days uses a static site builder that’s rather more complex than that, so it was really refreshing to remind myself that you can do useful things with tools as simple as ttree.

The next step was to add a GitHub Actions workflow that publishes the site to the GitHub Pages server each time something changes. That’s all pretty standard stuff too:

name: Generate web page

on:
  push:
    branches: 'master'
  workflow_dispatch:

jobs:
  build:
    if: github.repository_owner == 'LondonPM'
    runs-on: ubuntu-latest

    steps:
      - name: Install TT
        run: |
          sudo apt-get update
          sudo apt-get -y install libtemplate-perl

      - name: Checkout
        uses: actions/checkout@v4

      - name: Create pages
        run: ttree -f ttreerc 2>&1 > ttree.log

      - name: Archive ttree logs
        uses: actions/upload-artifact@v4
        with:
          name: ttree.log
          path: ./ttree.log
          retention-days: 3

      - name: Update pages artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: docs/

  deploy:
    needs: build
      if: github.repository_owner == 'LondonPM'
      permissions:
        pages: write
        id-token: write
      environment:
        name: github-pages
        url: ${{ steps.deployment.outputs.page_url }}
      runs-on: ubuntu-latest
      steps:
        - name: Deploy to GitHub Pages
          id: deployment
          uses: actions/deploy-pages@v4

The only slightly complex lines here are the two lines that say if: github.repository_owner == 'LondonPM'. We’re hoping that other people will fork this repo in order to work on the site, but it’s only the main fork that should attempt to publish the current version on the GitHub Pages servers.

There was a bit of fiddling with DNS. Temporarily, we used the domain londonperl.com as a test deployment (because I’m the kind of person who just happens to have potentially useful domains lying around, unused!) but enough of us are slightly obsessed about using the correct TLD so we’ve settled on londonperl.org[*]. We’ve asked the nice people at the Perl NOC to redirect our old domain to the new one.

And it’s all working (well, with the exception of the redirection of the old domain). Thanks to Sue, Lee and Leo for the work they’ve done in the last few days to get it all working. And a big thanks to Mark and Exonetric for hosting the site for us for the last couple of decades.

These changes are already having the desired effect. People are submitting pull requests to update the website. Our website is probably more up-to-date than it has been for far too long. It’s even responsive now.

I realise there has been very little Perl in this post. But I thought it might be useful for other Perl Mongers groups who are looking for a simple (and free!) space to host their websites. Please let me know if you have any questions about the process.

[*] We wanted to use Cloudflare to manage the domain but their free service only supports top-level domains and london.pm.org (our original domain) is a subdomain – and none of us wanted to pay for the enterprise version.

The post London Perl Mongers on GitHub Pages appeared first on Perl Hacks.

I’ve been a member of Picturehouse Cinemas for something approaching twenty years. It costs about £60 a year and for that, you get five free tickets and discounts on your tickets and snacks. I’ve often wondered whether it’s worth paying for, but in the last couple of years, they’ve added an extra feature that makes it well worth the cost. It’s called Film Club and every week they have two curated screenings that members can see for just £1. On Sunday lunchtime, there’s a screening of an older film, and on a weekday evening (usually Wednesday at the Clapham Picturehouse), they show something new. I’ve got into the habit of seeing most of these screenings.

For most of the year, I’ve been considering a monthly post about the films I’ve seen at Film Club, but I’ve never got around to it. So, instead, you get an end-of-year dump of the almost eighty films I’ve seen.

1. Under the Skin [4 stars] 2024-01-14
   Starting with an old(ish) favourite. The last time I saw this was a free preview for Picturehouse members, ten years ago. It’s very much a film that people love or hate. I love it. The book is great too (but very different)
2. Go West [3.5] 2024-01-21
   They often show old films as mini-festivals of connected films. This was the first of a short series of Buster Keaton films. I hadn’t seen any of them. Go West was a film where I could appreciate the technical aspects, but I wasn’t particularly entertained
3. Godzilla Minus One [3] 2024-01-23
   Around this time, I’d been watching a few of the modern Godzilla films from the “Monsterverse”. I hadn’t really been enjoying them. But this, unrelated, film was far more enjoyable
4. Steamboat Bill, Jr. [4] 2024-01-28
   Back with Buster Keaton. I enjoyed this one far more.
5. American Fiction [4] 2024-01-30
   Sometimes they’ll show an Oscar contender. I ended up having seen seven of the ten Best Picture nominees before the ceremony – which is far higher than my usual rate. I really enjoyed this one
6. The Zone of Interest [3] 2024-02-03
   Another Oscar contender. I think I wasn’t really in the mood for this. I was tired and found it hard to follow. I should rewatch it at some point.
7. The General [4] 2024-02-11
   More Buster Keaton. I really enjoyed this one – my favourite of the three I watched. I could very easily see myself going down a rabbit hole of obsessing over all of his films
8. Perfect Days [3.5] 2024-02-15
   A film about the life of a toilet cleaner in Tokyo. But written and directed by Wim Wenders – so far better than that description makes it sound
9. Wicked Little Letters [4] 2024-02-20
   I thought this would be more popular than it was. But it vanished pretty much without a trace. It’s a really nice little film about swearing
10. Nosferatu the Vampyre [3.5] 2024-02-25
    The Sunday screenings often give me a chance to catch up with old classics that I haven’t seen before. This was one example. This was the 1979 Werner Herzog version. I should track down the 1922 original before watching the new version early next year
11. Four Daughters [3.5] 2024-02-29
    Because the screenings cost £1, I see everything – no matter what the subject matter is. This is an example of a film I probably wouldn’t have seen without Film Club. But it was a really interesting film about a Tunisian woman who lost two of her daughters when they joined Islamic State
12. The Persian Version [3.5] 2024-03-07
    Another film that I would have missed out on without Film Club. It’s an interesting look into the lives of Iranians in America
13. Girlhood [3] 2024-03-10
    This was the start of another short season of related films. This time it was films made by women about the lives of women and girls. This one was about girl gangs in Paris
14. Still Walking [3] 2024-03-16
    A Japanese family get together to commemorate the death of the eldest son. Things happen, but nothing changes
15. Zola [3.5] 2024-03-17
    I had never heard of this film before, but really enjoyed it. It’s the true story of a stripper who goes on a road trip to Florida and gets involved in… stuff
16. Late Night with the Devil [3.5] 2024-03-19
    I thought this was clever. A horror film that takes place on the set of a late-night chat show. Things go horribly wrong
17. Set It Off [3.5] 2024-03-24
    A pretty standard heist film. But the protagonists are a group of black women. I enjoyed it
18. Disco Boy [2] 2024-03-27
    I really didn’t get this film at all
19. Girls Trip [3.5] 2024-03-31
    Another women’s road trip film. It was fun, but I can’t remember much of it now
20. The Salt of the Earth [3] 2024-04-07
    A documentary about the work of photographer Sebastião Salgado. He was in some bad wars and saw some bad shit
21. The Teachers’ Lounge [3.5] 2024-04-10
    Another film that got an Oscar nod. A well-made drama about tensions in the staff room of a German school.
22. Do the Right Thing [4] 2024-04-14
    I had never seen a Spike Lee film. How embarrassing is that? This was really good (but you all knew that)
23. Sometimes I Think About Dying [3] 2024-04-17
    I really wanted to like this. It was well-made. Daisy Ridley is a really good actress. But it didn’t really go anywhere and completely failed to grip me
24. The Trouble with Jessica [4] 2024-04-22
    Another film that deserved to be more successful than it was. Some great comedy performances by a strong cast.
25. Rope [4.5] 2024-04-28
    A chance to see a favourite film on the big screen for the first time. It’s regarded as a classic for good reason
26. Blackbird Blackbird Blackberry [3] 2024-04-30
    Another film that I just wouldn’t have considered if it wasn’t part of the Film Club programme. I had visited Tbilisi a year earlier, so it was interesting to see a film that was made in Georgia. But, ultimately, it didn’t really grip me
27. The Cars That Ate Paris [3] 2024-05-12
    Another old classic that I had never seen. It’s a bit like a precursor to Mad Max. I’m glad I’ve seen it, but I won’t be rushing to rewatch it
28. Victoria [3.5] 2024-05-19
    This was a lot of fun. The story of one night in the life of a Spanish woman living in Berlin. Lots of stuff happens. It’s over two hours long and was shot in a single, continuous take
29. The Beast [3.5] 2024-05-22
    This was interesting. So interesting that I rewatched it when it appeared on Mubi a few months ago. I’m not sure I can explain it all, but I’ll be rewatching again at some point (and probably revising my score upwards)
30. Eyes Wide Shut [4] 2024-05-26
    I hadn’t seen this for maybe twenty-five years. And I don’t think I ever saw it in a cinema. It’s better than I remember
31. Rosalie [3.5] 2024-05-28
    A film about a bearded lady in 19th-century France. I kid you not. It’s good
32. All About My Mother [3.5] 2024-06-02
    Years ago, I went through a phase of watching loads of Almodóvar films. I was sure I’d seen this one, but I didn’t remember it at all. It’s good though
33. Àma Gloria [3] 2024-06-04
    I misunderstood the trailer for this and was on the edge of my seat throughout waiting for a disaster to happen. But, ultimately, it was a nice film about a young girl visiting her old nanny in Cape Verde
34. Full Metal Jacket [3.5] 2024-06-09
    This really wasn’t as good as I remembered it. Everyone remembers the training camp stuff, but half of the film happens in-country – and that’s all rather dull
35. Sasquatch Sunset [2] 2024-06-11
    I wanted to like this. It would have made a funny two-minute SNL sketch. But it really didn’t work when stretched to ninety minutes
36. Being John Malkovich [4] 2024-06-16
    Still great
37. Green Border [4] 2024-06-19
    A lot of the films I’ve seen at Film Club in previous years seem to be about people crossing borders illegally. This one was about the border between Belarus and Poland. It was very depressing – but very good
38. Attack the Block [4] 2024-06-23
    Another old favourite that it was great to see on the big screen
39. The 400 Blows [3] 2024-06-30
    The French New Wave is a huge hole in my knowledge of cinema, so I was glad to have an opportunity to start putting that right. This, however, really didn’t grip me
40. Bye Bye Tiberias [2.5] 2024-07-02
    Hiam Abbass (who you might know as Marcia in Succession) left her native Palestine in the 80s to live in Paris. This is a documentary following a visit she made back to her family. It didn’t really go anywhere
41. Breathless [3] 2024-07-07
    More French New Wave. I like this more than The 400 Blows – but not much more
42. After Hours [4] 2024-07-13
    Another old favourite from  the 80s that I had never seen on the big screen. It’s still great
43. What Ever Happened to Baby Jane? [2.5] 2024-07-14
    This was an object lesson in the importance of judging a film in its context. I know this is a great film, but watching it in the 21st century just didn’t have the impact that watching it in the early 60s would have had
44. Crossing [3.5] 2024-07-16
    A Georgian woman travels to Istanbul to try to find her niece. We learn a lot about the gay and trans communities in the city. I enjoyed this a lot
45. American Gigolo [3] 2024-07-28
    Something else that I had never seen. And, to be honest, I don’t think I had really missed much
46. Dìdi (弟弟) [3.5] 2024-07-31
    Nice little story about a Taiwanese teen growing up in California
47. I Saw the TV Glow [4] 2024-08-05
    I imagine this will be on many “best films of the year” lists. It’s a very strange film about two teens and their obsession with a TV show that closely resembles Buffy the Vampire Slayer.
48. Hollywoodgate [2.5] 2024-08-13
    I really wanted to like this. An Egyptian filmmaker manages to get permission to film a Taliban group that takes over an American base in Afghanistan. But, ultimately, don’t let him film anything interesting and the film is a bit of a disappointment
49. Beverly Hills Cop [1] 2024-08-18
    I had never seen this before. And I wish I still hadn’t. One of the worst films I’ve seen in a very long time
50. Excalibur [4] 2024-08-25
    Another old favourite that I hadn’t seen on the big screen for a very long time. This is the film that gave me an obsession with watching any film that’s based on Arthurian legend, no matter how bad (and a lot of them are very, very bad)
51. The Quiet Girl [3.5] 2024-09-01
    A young Irish girl is sent away to spend the summer with distant relations. She comes to realise that life doesn’t have to be as grim as it usually is for her
52. Lee [3.5] 2024-09-04
    A really good biopic about the American photographer Lee Miller. Kate Winslet is really good as Miller
53. The Queen of My Dreams [3.5] 2024-09-11
    Another film that I wouldn’t have seen without Film Club. A Canadian Pakistani lesbian woman visits Pakistan and learns about some of the cultural pressures that shaped her mother. It’s a lovely film
54. My Own Private Idaho [2] 2024-09-15
    Another film that I had never seen before. Some nice acting by Keanu Reeves and River Phoenix, but this really didn’t interest me
55. Girls Will Be Girls [3.5] 2024-09-17
    A coming-of-age film about a teenage girl in India. I enjoyed this
56. The Shape of Water [3.5] 2024-09-22
    I don’t think I’ve seen this since the year it was released (and won the Best Picture Oscar). I still enjoyed it, but I didn’t think it held up as well as I expected it to
57. The Banshees of Inisherin [3.5] 2024-09-29
    I’d seen this on TV, but you need to see it on a big screen to get the full effect. I’m sure you all know how good it is
58. The Full Monty [3] 2024-10-06
    I never understood why this was so much more popular than Brassed Off which is, to me at least, a far better example of the “British worker fish out of water” genre (that’s not a genre, is it?) I guess it’s the soundtrack and the slightly Beryl Cook overtones – the British love a bit of smut
59. Timestalker [2.5] 2024-10-08
    I really wanted to like this. But if just didn’t grab me. I’ll try it again at some point
60. Nomadland [3] 2024-10-13
    Another Best Picture Oscar winner. And it’s another one where I can really see how important and well-made it is – but it just doesn’t do anything for me
61. The Apprentice [4] 2024-10-17
    I don’t know why Trump was so against this film. I thought he came out of this far more positively than I expected. But it seemed to barely get a release. It has still picked up a few (well-deserved) nominations though
62. Little Miss Sunshine [4] 2024-10-20
    Another old favourite. I loved seeing this again
63. Stoker [3] 2024-10-27
    I had never seen this before. I can’t quite put my finger on it, but I didn’t really enjoy it
64. Anora [4] 2024-10-29
    This was probably the best film I saw this year. Well, certainly the best new film. It’s getting a lot of awards buzz. I hope it does well
65. (500) Days of Summer [4] 2024-11-03
    I don’t think I had seen this since soon after it was released. It was great to see it again
66. Bird [3] 2024-11-05
    This was slightly strange. I’ve seen a few films about the grimness of life on council estates. But this one threw in a bit of magical realism that didn’t really work for me
67. Sideways [3.5] 2024-11-10
    Another film I hadn’t watched for far too long
68. Sunshine [4] 2024-11-17
    This is one of my favourite recent(ish) scifi films. I saw it on the Science Museum’s IMAX screen in 2023, but I wasn’t going to skip the chance to see it again
69. Conclave [3.5] 2024-11-19
    Occasionally, this series gives you a chance to see something that’s going to be up for plenty of awards. This was a good example. I enjoyed it
70. The Grand Budapest Hotel [4] 2024-11-24
    I’ve been slightly disappointed with a few recent Wes Anderson films, so it was great to have the opportunity to see one of his best back on the big screen
71. The Universal Theory [4] 2024-11-26
    I knew nothing about this going into it. And it was a fabulous film. Mysteries and quantum physics in  the Swiss Alps. And all filmed in black and white. This didn’t get the coverage it deserved.
72. Home Alone [2] 2024-12-08
    I thought I had never seen this before. But apparently I logged watching it many years ago. I know everyone loves it, but I couldn’t see the point
73. The Apartment [4] 2024-12-15
    This was interesting. I have a background quest to watch all of the Best Picture Oscar winners and I hadn’t seen this one. I knew absolutely nothing about it. I thought it was really good
74. The Taste of Things [3.5] 2024-12-21
    A film that I didn’t get to see earlier in the year. It’s largely about cooking in a late-nineteenth century French country kitchen. It would make an interesting watch alongside The Remains of the Day
75. Christmas Eve in Miller’s Point [2] 2024-12-24
    I didn’t understand this at all. It went nowhere and said nothing interesting. A large family meets up for their traditional Christmas Eve. No-one enjoys themself
76. La Chimera [2] 2024-12-29
    And finishing on a bit of a low. I don’t understand why this got so many good reviews. Maybe I just wasn’t in the right mood for it. Something about criminals looking for ancient relics in Italy

The post Picturehouse Film Club appeared first on Davblog.

Royal Titles Decoded: What Makes a Prince or Princess? — Line of Succession Blog

Royal titles in the United Kingdom carry a rich tapestry of history, embodying centuries of tradition while adapting to the changing landscape of the modern world. This article delves into the structure of these titles, focusing on significant changes made during the 20th and 21st centuries, and how these rules affect current royals.

The Foundations: Letters Patent of 1917

The framework for today’s royal titles was significantly shaped by the Letters Patent issued by King George V in 1917. This document was pivotal in redefining who in the royal family would be styled with “His or Her Royal Highness” (HRH) and as a prince or princess. Specifically, the 1917 Letters Patent restricted these styles to:

• The sons and daughters of a sovereign.
• The male-line grandchildren of a sovereign.
• The eldest living son of the eldest son of the Prince of Wales.

This move was partly in response to the anti-German sentiment of World War I, aiming to streamline the monarchy and solidify its British identity by reducing the number of royals with German titles.

Notice that the definitions talk about “a sovereign”, not “the sovereign”. This means that when the sovereign changes, no-one will lose their royal title (for example, Prince Andrew is still the son of a sovereign, even though he is no longer the son of the sovereign). However, people can gain royal titles when the sovereign changes — we will see examples below.

Extension by George VI in 1948

Understanding the implications of the existing rules as his family grew, King George VI issued a new Letters Patent in 1948 to extend the style of HRH and prince/princess to the children of the future queen, Princess Elizabeth (later Queen Elizabeth II). This was crucial as, without this adjustment, Princess Elizabeth’s children would not automatically have become princes or princesses because they were not male-line grandchildren of the monarch. This ensured that Charles and Anne were born with princely status, despite being the female-line grandchildren of a monarch.

The Modern Adjustments: Queen Elizabeth II’s 2012 Update

Queen Elizabeth II’s update to the royal titles in 2012 before the birth of Prince William’s children was another significant modification. The Letters Patent of 2012 decreed that all the children of the eldest son of the Prince of Wales would hold the title of HRH and be styled as prince or princess, not just the eldest son. This move was in anticipation of changes brought about by the Succession to the Crown Act of 2013, which ended the system of male primogeniture, ensuring that the firstborn child of the Prince of Wales, regardless of gender, would be the direct heir to the throne. Without this change, there could have been a situation where Prince William’s first child (and the heir to the throne) was a daughter who wasn’t a princess, whereas her eldest (but younger) brother would have been a prince.

Impact on Current Royals

• Children of Princess Anne: When Anne married Captain Mark Phillips in 1973, he was offered an earldom but declined it. Consequently, their children, Peter Phillips and Zara Tindall, were not born with any titles. This decision reflects Princess Anne’s preference for her children to have a more private life, albeit still active within the royal fold.
• Children of Prince Edward: Initially, Prince Edward’s children were styled as children of an earl, despite his being a son of the sovereign. Recently, his son James assumed the courtesy title Earl of Wessex, which Prince Edward will inherit in due course from Prince Philip’s titles. His daughter, Lady Louise Windsor, was also styled in line with Edward’s wish for a lower-profile royal status for his children.
• Children of Prince Harry: When Archie and Lilibet were born, they were not entitled to princely status or HRH. They were great-grandchildren of the monarch and, despite the Queen’s adjustments in 2012, their cousins — George, Charlotte and Louis — were the only great-grandchildren of the monarch with those titles. When their grandfather became king, they became male-line grandchildren of a monarch and, hence, a prince and a princess. It took a while for those changes to be reflected on the royal family website. This presumably gave the royal household time to reflect on the effect of the children’s parents withdrawing from royal life and moving to the USA.

Special Titles: Prince of Wales and Princess Royal

• Prince of Wales: Historically granted to the heir apparent, this title is not automatic and needs to be specifically bestowed by the monarch. Prince Charles was created Prince of Wales in 1958, though he had been the heir apparent since 1952. Prince William, on the other hand, received the title in 2022 — just a day after the death of Queen Elizabeth II.
• Princess Royal: This title is reserved for the sovereign’s eldest daughter but is not automatically reassigned when the previous holder passes away or when a new eldest daughter is born. Queen Elizabeth II was never Princess Royal because her aunt, Princess Mary, held the title during her lifetime. Princess Anne currently holds this title, having received it in 1987.

The Fade of Titles: Distant Royals

As the royal family branches out, descendants become too distanced from the throne, removing their entitlement to HRH and princely status. For example, the Duke of Gloucester, Duke of Kent, Prince Michael of Kent and Princess Alexandra all have princely status as male-line grandchildren of George V. Their children are all great-grandchildren of a monarch and, therefore, do not all have royal styles or titles. This reflects a natural trimming of the royal family tree, focusing the monarchy’s public role on those directly in line for succession.

Conclusion

The evolution of British royal titles reflects both adherence to deep-rooted traditions and responsiveness to modern expectations. These titles not only delineate the structure and hierarchy within the royal family but also adapt to changes in societal norms and the legal landscape, ensuring the British monarchy remains both respected and relevant in the contemporary era.

Originally published at https://blog.lineofsuccession.co.uk on April 25, 2024.

Royal Titles Decoded: What Makes a Prince or Princess? — Line of Succession Blog was originally published in Line of Succession on Medium, where people are continuing the conversation by highlighting and responding to this story.

Changing rooms are the same all over the galaxy and this one really played to the stereotype. The lights flickered that little bit more than you’d want them to, a sizeable proportion of the lockers wouldn’t lock and the whole room needed a good clean. It didn’t fit with the eye-watering amount of money we had all paid for the tour.

There were a dozen or so of us changing from our normal clothes into outfits that had been supplied by the tour company — outfits that were supposed to render us invisible when we reached our destination. Not invisible in the “bending light rays around you” way, they would just make us look enough like the local inhabitants that no-one would give us a second glance.

Appropriate changing room etiquette was followed. Everyone was either looking at the floor or into their locker to avoid eye contact with anyone else. People talked in lowered voices to people they had come with. People who, like me, had come alone were silent. I picked up on some of the quiet conversations — they were about the unusual flora and fauna of our location and the unique event we were here to see.

Soon, we had all changed and were ushered into a briefing room where our guide told us many things we already knew. She had slides explaining the physics behind the phenomenon and was at great pains to emphasise the uniqueness of the event. No other planet in the galaxy had been found that met all of the conditions for what we were going to see. She went through the history of tourism to this planet — decades of uncontrolled visits followed by the licensing of a small number of carefully vetted companies like the one we were travelling with.

She then turned to more practical matters. She reiterated that our outfits would allow us to pass for locals, but that we should do all we could to avoid any interactions with the natives. She also reminded us that we should only look at the event through the equipment that we would be issued with on our way down to the planet.

Through a window in the briefing room a planet, our destination, hung in space. Beyond the planet, its star could also be seen.

An hour or so later, we were on the surface of the planet. We were deposited at the top of a grassy hill on the edge of a large crowd of the planet’s inhabitants. Most of us were of the same basic body shape as the quadruped locals and, at first glance at least, passed for them. A few of us were less lucky and had to stay in the vehicles to avoid suspicion.

The timing of the event was well understood and the company had dropped us off early enough that we were able to find a good viewing spot but late enough that we didn’t have long to wait. We had been milling around for half an hour or so when a palpable moment of excitement passed through the crowd and everyone looked to the sky.

Holding the equipment I had been given to my eyes I could see what everyone else had noticed. A small bite seemed to have been taken from the bottom left of the planet’s sun. As we watched, the bite got larger and larger as the planet’s satellite moved in front of the star. The satellite appeared to be a perfect circle, but at the last minute — just before it covered the star completely — it became obvious that the edge wasn’t smooth as gaps between irregularities on the surface (mountains, I suppose) allowed just a few points of light through.

And then the satellite covered the sun and the atmosphere changed completely. The world turned dark and all conversations stopped. All of the local animals went silent. It was magical.

My mind went back to the slides explaining the phenomenon. Obviously, the planet’s satellite and star weren’t the same size, but their distance from the planet exactly balanced their difference in size so they appeared the same size in the sky. And the complex interplay of orbits meant that on rare occasions like this, the satellite would completely and exactly cover the star.

That was what we were there for. This was what was unique about this planet. No other planet in the galaxy had a star and a satellite that appeared exactly the same size in the sky. This is what made the planet the most popular tourist spot in the galaxy.

Ten minutes later, it was over. The satellite continued on its path and the star was gradually uncovered. Our guide bundled us into the transport and back up to our spaceship.

Before leaving the vicinity of the planet, our pilot found three locations in space where the satellite and the star lined up in the same way and created fake eclipses for those of us who had missed taking photos of the real one.

Originally published at https://blog.dave.org.uk on April 7, 2024.

Changing rooms are the same all over the galaxy and this one really played to the stereotype. The lights flickered that little bit more than you’d want them to, a sizeable proportion of the lockers wouldn’t lock and the whole room needed a good clean. It didn’t fit with the eye-watering amount of money we had all paid for the tour.

There were a dozen or so of us changing from our normal clothes into outfits that had been supplied by the tour company – outfits that were supposed to render us invisible when we reached our destination. Not invisible in the “bending light rays around you” way, they would just make us look enough like the local inhabitants that no-one would give us a second glance.

Appropriate changing room etiquette was followed. Everyone was either looking at the floor or into their locker to avoid eye contact with anyone else. People talked in lowered voices to people they had come with. People who, like me, had come alone were silent. I picked up on some of the quiet conversations – they were about the unusual flora and fauna of our location and the unique event we were here to see.

Soon, we had all changed and were ushered into a briefing room where our guide told us many things we already knew. She had slides explaining the physics behind the phenomenon and was at great pains to emphasise the uniqueness of the event. No other planet in the galaxy had been found that met all of the conditions for what we were going to see. She went through the history of tourism to this planet – decades of uncontrolled visits followed by the licensing of a small number of carefully vetted companies like the one we were travelling with.

She then turned to more practical matters. She reiterated that our outfits would allow us to pass for locals, but that we should do all we could to avoid any interactions with the natives. She also reminded us that we should only look at the event through the equipment that we would be issued with on our way down to the planet.

Through a window in the briefing room a planet, our destination, hung in space. Beyond the planet, its star could also be seen.

An hour or so later, we were on the surface of the planet. We were deposited at the top of a grassy hill on the edge of a large crowd of the planet’s inhabitants. Most of us were of the same basic body shape as the quadruped locals and, at first glance at least, passed for them. A few of us were less lucky and had to stay in the vehicles to avoid suspicion.

The timing of the event was well understood and the company had dropped us off early enough that we were able to find a good viewing spot but late enough that we didn’t have long to wait. We had been milling around for half an hour or so when a palpable moment of excitement passed through the crowd and everyone looked to the sky.

Holding the equipment I had been given to my eyes I could see what everyone else had noticed. A small bite seemed to have been taken from the bottom left of the planet’s sun. As we watched, the bite got larger and larger as the planet’s satellite moved in front of the star. The satellite appeared to be a perfect circle, but at the last minute – just before it covered the star completely – it became obvious that the edge wasn’t smooth as gaps between irregularities on the surface (mountains, I suppose) allowed just a few points of light through.

And then the satellite covered the sun and the atmosphere changed completely. The world turned dark and all conversations stopped. All of the local animals went silent. It was magical.

My mind went back to the slides explaining the phenomenon. Obviously, the planet’s satellite and star weren’t the same size, but their distance from the planet exactly balanced their difference in size so they appeared the same size in the sky. And the complex interplay of orbits meant that on rare occasions like this, the satellite would completely and exactly cover the star.

That was what we were there for. This was what was unique about this planet. No other planet in the galaxy had a star and a satellite that appeared exactly the same size in the sky. This is what made the planet the most popular tourist spot in the galaxy.

Ten minutes later, it was over. The satellite continued on its path and the star was gradually uncovered. Our guide bundled us into the transport and back up to our spaceship.

Before leaving the vicinity of the planet, our pilot found three locations in space where the satellite and the star lined up in the same way and created fake eclipses for those of us who had missed taking photos of the real one.

The post The Tourist appeared first on Davblog.

I really thought that 2023 would be the year I got back into the swing of seeing gigs. But, somehow I ended up seeing even fewer than I did in 2022 – 12, when I saw 16 the previous year. Sometimes, I look at Martin’s monthly gig round-ups and wonder what I’m doing with my life!

I normally list my ten favourite gigs of the year, but it would be rude to miss just two gigs from the list, so here are all twelve gigs I saw this year – in, as always, chronological order.

• John Grant (supported by The Faultress) at St. James’s Church
  John Grant has become one of those artists I try to see whenever they pass through London. And this was a particularly special night as he was playing an acoustic set in one of the most atmospheric venues in London. The evening was only slightly marred by the fact I arrived too late to get a decent seat and ended up not being able to see anything.
• Hannah Peel at Kings Place
  Hannah Peel was the artist in residence at Kings Place for a few months during the year and played three gigs during that time. This was the first of them – where she played her recent album, Fir Wave, in its entirety. A very laid-back and thoroughly enjoyable evening.
• Orbital at the Eventim Apollo
  I’ve been meaning to get around to seeing Orbital for many years. This show was originally planned to be at the Brixton Academy but as that venue is currently closed, it was relocated to Hammersmith. To be honest, this evening was slightly hampered by the fact I don’t know as much of their work as I thought I did and it was all a bit samey. I ended up leaving before the encore.
• Duran Duran (supported by Jake Shears) at the O2 Arena
  Continuing my quest to see all of the bands I was listening to in the 80s (and, simultaneously, ticking off the one visit to the O2 that I allow myself each year). I really enjoyed the nostalgia of seeing Duran Duran but, to be honest, I think I enjoyed Jake Shears more – and it was the Scissor Sisters I was listening to on the way home.
• Hannah Peel and Beibei Wang at Kings Place
  Even in a year where I only see a few gigs, I still manage to see artists more than once. This was the second of Hannah Peel’s artist-in-residence shows. She appeared with Chinese percussionist Beibei Wang in a performance that was completely spontaneous and unrehearsed. Honestly, some parts were more successful than others, but it was certainly an interesting experience.
• Songs from Summerisle at the Barbican Hall
  The Wicker Man is one of my favourite films, so I jumped at the chance to see the songs from the soundtrack performed live. But unfortunately, the evening was a massive disappointment. The band sounded like they had met just before the show and, while they all obviously knew the songs, they hadn’t rehearsed them together. Maybe they were going for a rustic feel – but, to me, it just sounded unprofessional.
• Belle and Sebastian at the Roundhouse
  Another act that I try to see as often as possible. I know some people see Belle and Sebastian as the most Guardian-reader band ever – but I love them. This show saw them on top form.
• Jon Anderson and the Paul Green Rock Academy at the Shepherds Bush Empire
  I’ve seen Yes play live a few times in the last ten years or so and, to be honest, it can sometimes be a bit over-serious and dull. In this show, Jon Anderson sang a load of old Yes songs with a group of teenagers from the Paul Green Rock Academy (the school that School of Rock was based on) and honestly, the teenagers brought such a feeling of fun to the occasion that it was probably the best Yes-related show that I’ve seen.
• John Grant and Richard Hawley at the Barbican Hall
  Another repeated act – my second time seeing John Grant in a year. This was something different as he was playing a selection of Patsy Cline songs. I don’t listen to Patsy Cline much, but I knew a few more of the songs than I expected to. This was a bit lower-key than I was expecting.
• Peter Hook and the Light at the Eventim Apollo
  I’ve been planning to see Peter Hook and the Light for a couple of years. There was a show I had tickets for in 2020, but it was postponed because of COVID and when it was rescheduled, I was unable to go, so I cancelled my ticket and got a refund. So I was pleased to get another chance. And this show had them playing both of the Substance albums (Joy Division and New Order). I know New Order still play some Joy Division songs in their sets, but this is probably the best chance I’ll have to see some deep Joy Division cuts played live. I really enjoyed this show.
• Heaven 17 at the Shepherds Bush Empire
  It seems I see Heaven 17 live most years and they usually appear on my “best of” lists. This show was celebrating the fortieth anniversary of their album The Luxury Gap – so that got played in full, alongside many other Heaven 17 and Human League songs. A thoroughly enjoyable night.
• The Imagined Village and Afro-Celt Sound System at the Roundhouse
  I’ve seen both The Imagined Village and the Afro-Celts live once before. And they were two of the best gigs I’ve ever seen. I pretty much assumed that the death of Simon Emmerson (who was an integral part of both bands) earlier in 2023 would mean that both bands would stop performing. But this show was a tribute to Emmerson and the bands both reformed to celebrate his work. This was probably my favourite gig of the year. That’s The Imagined Village (featuring two Carthys, dour Coppers and Billy Bragg) in the photo at the top of this post.

So, what’s going to happen in 2024. I wonder if I’ll get back into the habit of going to more shows. I only have a ticket for one gig next year – They Might Be Giants playing Flood in November (a show that was postponed from this year). I guess we’ll see. Tune in this time next year to see what happened.

The post 2023 in Gigs appeared first on Davblog.

Dave Cross posted a photo:

via Instagram instagr.am/p/CmyT_MSNR3-/

Dave Cross posted a photo:

via Instagram instagr.am/p/Cmv4y1eNiPn/

Dave Cross posted a photo:

via Instagram instagr.am/p/Cmv4rUAta58/

Dave Cross posted a photo:

via Instagram instagr.am/p/Cmq759NtKtE/

Dave Cross posted a photo:

via Instagram instagr.am/p/CmOfgfLtwL_/