Watched on Thursday February 20, 2025.

Watched on Tuesday February 18, 2025.

Watched on Monday February 17, 2025.

Watched on Sunday February 16, 2025.

Watched on Wednesday February 12, 2025.

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.

When I first wrote about my pointless personal side projects a few months ago, I used the software I had written to generate my own link site (like a LinkTree clone) as an example.

I’m happy to report that I’ve continued to work on this software. Recently, it passed another milestone—I released a version to CPAN. It’s called App::LinkSite[*]. If you’d like a Link Site of your own, there are a few ways you can achieve that.

In all cases, you’ll want to gather a few pieces of information first. I store mine in a GitHub repo[**].

Most importantly, you’ll need the list of links that you want to display on your site. These go in a file called “links.json“. There are two types of link.

1. Social media links. These appear as a row of icons across the top of your link site. I’ve covered most of the popular options, but if there are any more you need, just raise an issue against the repo.
2. Standard links. These go to web sites, blogs and things like that. In every case, you’ll need the link and a title to display. You can optionally add a subtitle and a “new” flag (which will slightly change the way the link is displayed – to make it more obvious).

There are also a few bits of header information you’ll want to add:

• Name
• Default handle – this is displayed on the page, but also used as the default handle in your social media links
• Image – presumably your picture
• Open Graph Image – which is optionally added to the header of the site
• The URL of your site – used for various SEO tags in the output
• Description
• Optional Google Analytics 4 Tag

Put all of that information into “links.json” and put the images in a directory called “img”. Fuller documentation is in the README.

Now you get to decide how you’re going to build your site.

Installed CPAN module

You can install the module (App::LinkSite) using your favourite CPAN installation tool. Then you can just run the “linksite” command and your site will be written to the “docs” directory – which you can then deploy to the web in whatever way you prefer.

Docker image

I build a Docker image whenever I release a new version of the code. That image is released to the Docker hub. So if you like Docker, you can just pull down the “davorg/links:latest” image and go from there.

GitHub Actions and GitHub Pages

But this is my favourite approach. Let GitHub do all the heavy lifting for you. There’s a little bit of set-up you’ll need to do.

• Store the “links.json” and the images in a new repo in GitHub
• Create a “.github/workflows” directory in your new repo and copy my “build.yaml” workflow into that directory

Now, whenever you change anything in your repo, your site will be rebuilt and redeployed automatically. There’s also a “run this workflow” under the “Actions” tab of your repo that allows you to run the build and deployment automatically whenever you want.

This is the mechanism I like best – as it’s the least amount of work!

If you try this, please let me know as I’d like to add an “Examples” section to the README file. Also, if you try it and have problems getting it working, then let me know too. It works for me, but I’m sure I’ve forgotten to cater for some specific complexity of how other people would like to use my software. I’m always happy to get suggestions on how to improve things – even if it’s just better documentation.

[*] My continued use of the new Perl class syntax still seems to be causing problems with the CPAN infrastructure. The distribution isn’t being indexed properly.

[**] This shouldn’t be too much of a surprise – I store pretty much everything in a GitHub repo.

The post A link site of your very own first appeared on Perl Hacks.

When I first wrote about my pointless personal side projects a few months ago, I used the software I had written to generate my own link site (like a LinkTree clone) as an example.

I’m happy to report that I’ve continued to work on this software. Recently, it passed another milestone—I released a version to CPAN. It’s called App::LinkSite[*]. If you’d like a Link Site of your own, there are a few ways you can achieve that.

In all cases, you’ll want to gather a few pieces of information first. I store mine in a GitHub repo[**].

Most importantly, you’ll need the list of links that you want to display on your site. These go in a file called “links.json“. There are two types of link.

1. Social media links. These appear as a row of icons across the top of your link site. I’ve covered most of the popular options, but if there are any more you need, just raise an issue against the repo.
2. Standard links. These go to web sites, blogs and things like that. In every case, you’ll need the link and a title to display. You can optionally add a subtitle and a “new” flag (which will slightly change the way the link is displayed – to make it more obvious).

There are also a few bits of header information you’ll want to add:

• Name
• Default handle – this is displayed on the page, but also used as the default handle in your social media links
• Image – presumably your picture
• Open Graph Image – which is optionally added to the header of the site
• The URL of your site – used for various SEO tags in the output
• Description
• Optional Google Analytics 4 Tag

Put all of that information into “links.json” and put the images in a directory called “img”. Fuller documentation is in the README.

Now you get to decide how you’re going to build your site.

Installed CPAN module

You can install the module (App::LinkSite) using your favourite CPAN installation tool. Then you can just run the “linksite” command and your site will be written to the “docs” directory – which you can then deploy to the web in whatever way you prefer.

Docker image

I build a Docker image whenever I release a new version of the code. That image is released to the Docker hub. So if you like Docker, you can just pull down the “davorg/links:latest” image and go from there.

GitHub Actions and GitHub Pages

But this is my favourite approach. Let GitHub do all the heavy lifting for you. There’s a little bit of set-up you’ll need to do.

• Store the “links.json” and the images in a new repo in GitHub
• Create a “.github/workflows” directory in your new repo and copy my “build.yaml” workflow into that directory

Now, whenever you change anything in your repo, your site will be rebuilt and redeployed automatically. There’s also a “run this workflow” under the “Actions” tab of your repo that allows you to run the build and deployment automatically whenever you want.

This is the mechanism I like best – as it’s the least amount of work!

If you try this, please let me know as I’d like to add an “Examples” section to the README file. Also, if you try it and have problems getting it working, then let me know too. It works for me, but I’m sure I’ve forgotten to cater for some specific complexity of how other people would like to use my software. I’m always happy to get suggestions on how to improve things – even if it’s just better documentation.

[*] My continued use of the new Perl class syntax still seems to be causing problems with the CPAN infrastructure. The distribution isn’t being indexed properly.

[**] This shouldn’t be too much of a surprise – I store pretty much everything in a GitHub repo.

The post A link site of your very own appeared first on Perl Hacks.

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.

Originally published at https://blog.dave.org.uk on December 31, 2023.

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.

Rather later than usual (again!) here is my review of the best ten gigs I saw in 2022. For the first time since 2019, I did actually see more than ten gigs in 2022 although my total of sixteen falls well short of my pre-pandemic years.

Here are my ten favourite gigs of the year. As always, they’re in chronological order.

• Pale Waves at the Roundhouse
  I’ve seen Pale Waves a few times now and I think they’ve firmly established their place on my “see them whenever they tour near me” list. This show was every bit as good as I’ve ever seen them.
• Orchestral Manoeuvres in the Dark at the Royal Albert Hall
  Another band I see whenever I can. This was a slightly different set where the first half was called “Atmospheric” and concentrated on some deeper cuts from their back catalogue and the second half included all the hits.
• Chvrches at Brixton Academy
  In 2020, I moved to a flat that’s about fifteen minutes’ walk from Brixton Academy. But I had to wait about eighteen months in order to take advantage of that fact. The last couple of times I’ve seen Chvrches were at Alexandra Palace, so it was nice to see them at a smaller venue again. This show featured a not-entirely unexpected guest appearance from Robert Smith.
• Sunflower Bean at Electric Ballroom
  Another act who I see live as often as I can. And this was a great venue to see them in.
• Pet Shop Boys at the O2 Arena
  There’s always one show a year that draws me to the soulless barn that is the O2 Arena. Every time I go there, I vow it’ll be the last time – but something always pulls me back. This year it was the chance to see a band I loved in the 80s and have never seen live. This was a fabulous greatest hits show that had been postponed from 2020.
• Lorde at the Roundhouse
  A new Lorde album means another Lorde tour. And, like Chvrches, she swapped the huge expanse of Alexandra Palace for multiple nights at a smaller venue. This was a very theatrical show that matched the vibe of the Solar Power album really well.
• LCD Soundsystem at Brixton Academy
  Another show at Brixton Academy. For some reason, I didn’t know about this show until I walked past the venue a few days before and saw the “sold out” signs. But a day or so later, I got an email from the venue offering tickets. So I snapped one up and had an amazing evening. It was the first time I’d seen them, but I strongly suspect it won’t be the last. That’s them in the photo at the top of this post.
• Roxy Music at the O2 Arena
  Some years there are two shows that force me to the O2 Arena. And this was one of those years. I’ve been a fan of Roxy Music since the 70s but I’ve never seen them live. Honestly, it would have been better to have seen them in the 70s or 80s, but it was still a great show.
• Beabadoobee at Brixton Academy
  Sometimes you go to see an artist because of one song and it just works out. This was one of those nights. In fact, it turns out I didn’t actually know “Coffee For Your Head” very well – I just knew the sample that was used in another artist’s record. But this was a great night and I hope to see her again very soon.
• Sugababes at Eventim Apollo
  Another night of fabulous nostalgia. The Eventim Apollo seems to have become my venue of choice to see re-formed girl groups from the 80s and 90s – having seen Bananarama, All Saints and now The Sugababes there in recent years. They have a surprising number of hits (far more than I remembered before the show) and they put on a great show.

Not everything could make the top ten though. I think was the first year that I saw Stealing Sheep and they didn’t make the list (their stage shows just get weirder and weirder and the Moth Club wasn’t a great venue for it) and I was astonished to find myself slightly bored at the Nine Inch Nails show at Brixton Academy.

A few shows sit just outside of the top ten – St. Vincent at the Eventim Apollo, John Grant at the Shepherd’s Bush Empire and Damon Albarn at the Barbican spring to mind.

But, all in all, it was a good year for live music and I’m looking forward to seeing more than sixteen shows this year.

Did you see any great shows this year? Tell us about them in the comments.

The post 2022 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_/

Using artificial intelligence (AI) to generate blog posts can be bad for search engine optimization (SEO) for several reasons.

First and foremost, AI-generated content is often low quality and lacks the depth and substance that search engines look for when ranking content. Because AI algorithms are not capable of understanding the nuances and complexities of human language, the content they produce is often generic, repetitive, and lacks originality. This can make it difficult for search engines to understand the context and relevance of the content, which can negatively impact its ranking.

Additionally, AI-generated content is often not well-written or structured, which can make it difficult for readers to understand and engage with. This can lead to a high bounce rate (the percentage of visitors who leave a website after only viewing one page), which can also hurt the website’s ranking.

Furthermore, AI-generated content is often not aligned with the website’s overall content strategy and goals. Because AI algorithms are not capable of understanding the website’s target audience, brand voice, and core messaging, the content they produce may not be relevant or useful to the website’s visitors. This can lead to a poor user experience, which can also hurt the website’s ranking.

Another issue with AI-generated content is that it can be seen as spammy or low quality by both search engines and readers. Because AI-generated content is often produced in large quantities and lacks originality, it can be seen as an attempt to manipulate search engine rankings or trick readers into engaging with the website. This can lead to the website being penalized by search engines or losing the trust and loyalty of its visitors.

In conclusion, using AI to generate blog posts can be bad for SEO for several reasons. AI-generated content is often low quality, poorly written, and not aligned with the website’s content strategy. It can also be seen as spammy or low quality by both search engines and readers, which can hurt the website’s ranking and reputation. It is important for websites to prioritize creating high-quality, original, and relevant content to improve their SEO and provide a positive user experience.

[This post was generated using ChatGPT]

The post 5 Reasons Why Using AI to Generate Blog Posts Can Destroy Your SEO appeared first on Davblog.