Powered by Perlanet
7fd9597
🟩 Aphra is up (200 in 218 ms) [skip ci] [upptime]
2218c66
🟩 Klortho is up (200 in 558 ms) [skip ci] [upptime]
Watched on Sunday January 19, 2025.
Watched on Saturday January 18, 2025.
Watched on Thursday January 16, 2025.
Watched on Monday January 13, 2025.
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:
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:
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.
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.
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:
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:
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.
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 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 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…
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.
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.
There are also a few bits of header information you’ll want to add:
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.
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.
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.
There are also a few bits of header information you’ll want to add:
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.
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.
Last weekend, we had a very successful (and very enjoyable) London Perl Workshop. After a five-year break, it was great to see so many old faces again. But in addition to people who had been regular attendees at recent workshops, two other groups of people were there in large numbers—people who had moved away from the Perl community (and who were coming back for the nostalgia) and new Perl users who hadn’t been to any Perl conference before. In both cases, it seems that one marketing move was particularly effective at telling both of these groups about the workshop.
It was a small, text advert that ran on MetaCPAN.
I had nothing to do with the organisation of the workshop, so I have no idea who had the idea of running that ad, but it was (like so many great ideas) obvious in retrospect. It’s great to publish blog posts about upcoming events and mention events in the Perl Weekly newsletter. But marketing like that is mostly going to be read by people who are already part of the Perl community. And they (hopefully) already know about the workshop.
Whereas, sites like MetaCPAN are visited by Perl programmers who don’t consider themselves part of the community. People who don’t attend Perl Mongers meetings. People who don’t read blogs.perl.org. People who are (to use terminology that has been used to explain this problem for about twenty years) outside the echo chamber.
Advertising Perl community events to as large an audience as possible is a really good idea, and I think we should do more of it. But it has its downsides. Someone has to do some work to create a pull request to add the advert (and another one to remove it once the event is over). That’s not hard, but it requires thought and planning. I started to wonder if we could simplify this process and, in doing so, encourage more people to run ads like these on sites where more people might see them.
After an hour or so, I had a prototype of the Perl Ad Server – which I have subsequently cleaned up and improved.
It’s a simple enough concept. You add a tiny fragment of Javascript to your website. And that then automatically adds a small banner ad to the top of your site. We can control the ads that are being promoted by simply editing the JSON that we serve to the client sites.
It’s experimental. So I’d like to get as many people as possible to try it out.
It comes with a tiny caveat. I’m neither a web designer nor a Javascript expert. So it may interact with some web frameworks in weird ways (I added it to CPAN Dashboard and the ad appeared under the navbar – which isn’t supposed to happen). If it doesn’t work with your site for some reason, please remove the Javascript and raise an issue so I can investigate.
And if you’d like your event added to the current list of ads, let me know too.
The post Advertising Perl appeared first on Perl Hacks.
Last weekend, we had a very successful (and very enjoyable) London Perl Workshop. After a five-year break, it was great to see so many old faces again. But in addition to people who had been regular attendees at recent workshops, two other groups of people were there in large numbers—people who had moved away from the Perl community (and who were coming back for the nostalgia) and new Perl users who hadn’t been to any Perl conference before. In both cases, it seems that one marketing move was particularly effective at telling both of these groups about the workshop.
It was a small, text advert that ran on MetaCPAN.
I had nothing to do with the organisation of the workshop, so I have no idea who had the idea of running that ad, but it was (like so many great ideas) obvious in retrospect. It’s great to publish blog posts about upcoming events and mention events in the Perl Weekly newsletter. But marketing like that is mostly going to be read by people who are already part of the Perl community. And they (hopefully) already know about the workshop.
Whereas, sites like MetaCPAN are visited by Perl programmers who don’t consider themselves part of the community. People who don’t attend Perl Mongers meetings. People who don’t read blogs.perl.org. People who are (to use terminology that has been used to explain this problem for about twenty years) outside the echo chamber.
Advertising Perl community events to as large an audience as possible is a really good idea, and I think we should do more of it. But it has its downsides. Someone has to do some work to create a pull request to add the advert (and another one to remove it once the event is over). That’s not hard, but it requires thought and planning. I started to wonder if we could simplify this process and, in doing so, encourage more people to run ads like these on sites where more people might see them.
After an hour or so, I had a prototype of the Perl Ad Server – which I have subsequently cleaned up and improved.
It’s a simple enough concept. You add a tiny fragment of Javascript to your website. And that then automatically adds a small banner ad to the top of your site. We can control the ads that are being promoted by simply editing the JSON that we serve to the client sites.
It’s experimental. So I’d like to get as many people as possible to try it out.
It comes with a tiny caveat. I’m neither a web designer nor a Javascript expert. So it may interact with some web frameworks in weird ways (I added it to CPAN Dashboard and the ad appeared under the navbar – which isn’t supposed to happen). If it doesn’t work with your site for some reason, please remove the Javascript and raise an issue so I can investigate.
And if you’d like your event added to the current list of ads, let me know too.
The post Advertising Perl appeared first on Perl Hacks.
After a break of five years, the London Perl Workshop returns next weekend. It’s been twenty years since the first one. This year’s event is at a new venue called The Trampery, which is very close to Old Street tube station. If you’re a veteran of the early-2000s “Silicon Roundabout” excitement, you’ll know the place as it’s right across the road from The Foundry – the place to be seen if you were working in that area. I seem to remember taking people there as part of the entertainment programme for the first YAPC::Europe back in 2000. The pub isn’t there any more – it’s been knocked down and replaced by a modern hotel.
So I thought I’d have a look at the schedule and point out some of the interesting talks that I’m looking forward to seeing next Saturday.
Following Julian’s introduction, there’s an early indication of the quality of the talks – as there’s a massive clash. I understand how most people would want to see Paul Evans talking about Perl in 2030, but at the same time I’ll be talking about PerlDiver in the other main room. Now, obviously, I don’t want to sway anyone’s decision about which talk to choose – but I will have swag to give away. I don’t have any choice over which room I’ll be in, but I really want to see Paul’s talk, so I’m hoping it’ll be videoed.
I should point out that alongside the two main tracks, there’s a third room that the organisers hope will be used for hackathons, BOFs and things like that.
Next up we have Dave Lambley with Cloudy Perl, how it looks now and Richard Hainsworth with Using new RakuDoc v2. AWS Lambdas and Raku are both things that I’ve never really wrapped my head around. But I suspect that AWS will be more useful to me in the long run, so I’ll be with Dave.
The next choice is between Stuart Mackintosh’s TPRF Presentation and discussion and Ralf Langsdorf who sounds like he’s battling against Little Bobby Tables. I don’t do much community leadership stuff these days, but I’m glad there are still people who are willing to take on those roles – so I’ll be with Stuart. But Ralf’s is another talk that I’ll be looking forward to catching up with later.
In the final slot of the morning, the breakout room is hosting a talk – giving you a choice of three: James Green with I Adopted a Dist, and This is What Happened, José Joaquín Atria with Using OpenTelemetry in your Perl libraries and applications and Steve Roe with Raku HTML::Functional. I love a good CPAN module story, so I’ll be with James.
There’s then an hour for lunch. I’ll be trying one of the many local sandwich shops or pubs.
First up in the afternoon is a choice between Salve J. Nilsen – Metadata, CPAN, FOSS Supply Chains, and EU’s Cyber Resilience Act, Leon Timmermans – A modern introduction to XS and Andrew O’Neil – Chemometrics with Perl & Pharmaceutical Applications. Salve is covering a topic that, while seemingly dull, is something that more people need to take notice of. Leon is covering another topic that I’ve never quite understood. And Andrew is doing science – which is always fun. I think I’ll be listening to Leon in the hope I can finally understand XS.
Next up is Mohammad Anwar explaining What’s new in Perl v5.40?, Paul Cochrane on Fixing a fifteen-year-old curve fit bug or Salve is following up on his talk with a CPAN security BOF in the breakout room. Mohammad is always worth watching, but I very much enjoyed reading Paul’s blog post on this bug recently – so I haven’t decided yet where I’ll be.
Then we have a choice between Max Maischein – Managing recent files from Perl (which sounds useful), Nana Insaidoo – opensource vulnerabilities and where to find them (which sounds vital!) and the continuation of Salve’s BOF.
The last slot in this session is Mike Whitaker – Names are hard (which is inarguable), Yujia Zhai – Perl/Raku Based Coursework Design for Engineering Education or even more of Salve’s BOF.
Then we have a twenty-minute break. Phew. I think we’ll all need it after all that top-notch information.
Things get a bit disjointed after the break. There’s Andrew Soloman with Perl Talent Management: How Logicly attracts, develops, and retains their Perl developers. But that overlaps with two talks in the other main room – Ian Boddison with Perl, AI and Your System followed by Saif Ahmed with Bit Vector Arrays to Pixels in a Terminal with One Subroutine. And while all that’s going on, the breakout room has a session of Science Perl Talks chaired by Andrew Neil. They all sound interesting, but my interest in training trumps my other interests, so I’ll be listening to Andrew Soloman.
And then there are the lighting talks. As always, there will be a wide range of talks. I’ll be giving a brief update on Perl School. If you’ve been watching my social media, you might have an idea what I’ll be announcing.
Then we have the intriguingly-named Thanks & The Future of LPW before we all head off to the pub for a debrief.
There are currently about 140 people signed up for the workshop. I don’t know what the venue capacity is, but I’m sure they can squeeze a more in if you’d like to register. Oh, and if you are registered, please mark the talks you’re interested in on the schedule – it makes it easier for the organisers to decide which talks should be in which rooms.
Of course, if you’re not within easy travelling distance of London, then don’t forget that there are other Perl events in other parts of the world. In particular, there will be a TPRC in Greenville, South Carolina next year. See https://tprc.us/ for details.
To close, I’d like to thank the sponsors of this year’s LPW. Without them, the workshop wouldn’t be able to go ahead. Please show them some love.
The post London Perl Workshop 2024 – Preview appeared first on Perl Hacks.
After a break of five years, the London Perl Workshop returns next weekend. It’s been twenty years since the first one. This year’s event is at a new venue called The Trampery, which is very close to Old Street tube station. If you’re a veteran of the early-2000s “Silicon Roundabout” excitement, you’ll know the place as it’s right across the road from The Foundry – the place to be seen if you were working in that area. I seem to remember taking people there as part of the entertainment programme for the first YAPC::Europe back in 2000. The pub isn't there any more - it's been knocked down and replaced by a modern hotel.
So I thought I’d have a look at the schedule and point out some of the interesting talks that I’m looking forward to seeing next Saturday.
Following Julian’s introduction, there’s an early indication of the quality of the talks – as there’s a massive clash. I understand how most people would want to see Paul Evans talking about Perl in 2030, but at the same time I’ll be talking about PerlDiver in the other main room. Now, obviously, I don’t want to sway anyone’s decision about which talk to choose – but I will have swag to give away. I don’t have any choice over which room I’ll be in, but I really want to see Paul’s talk, so I’m hoping it’ll be videoed.
I should point out that alongside the two main tracks, there’s a third room that the organisers hope will be used for hackathons, BOFs and things like that.
Next up we have Dave Lambley with Cloudy Perl, how it looks now and Richard Hainsworth with Using new RakuDoc v2. AWS Lambdas and Raku are both things that I’ve never really wrapped my head around. But I suspect that AWS will be more useful to me in the long run, so I’ll be with Dave.
The next choice is between Stuart Mackintosh’s TPRF Presentation and discussion and Ralf Langsdorf who sounds like he’s battling against Little Bobby Tables. I don’t do much community leadership stuff these days, but I’m glad there are still people who are willing to take on those roles – so I’ll be with Stuart. But Ralf’s is another talk that I’ll be looking forward to catching up with later.
In the final slot of the morning, the breakout room is hosting a talk – giving you a choice of three: James Green with I Adopted a Dist, and This is What Happened, José Joaquín Atria with Using OpenTelemetry in your Perl libraries and applications and Steve Roe with Raku HTML::Functional. I love a good CPAN module story, so I’ll be with James.
There’s then an hour for lunch. I’ll be trying one of the many local sandwich shops or pubs.
First up in the afternoon is a choice between Salve J. Nilsen – Metadata, CPAN, FOSS Supply Chains, and EU’s Cyber Resilience Act, Leon Timmermans – A modern introduction to XS and Andrew O’Neil – Chemometrics with Perl & Pharmaceutical Applications . Salve is covering a topic that, while seemingly dull, is something that more people need to take notice of. Leon is covering another topic that I’ve never quite understood. And Andrew is doing science – which is always fun. I think I’ll be listening to Leon in the hope I can finally understand XS.
Next up is Mohammad Anwar explaining What’s new in Perl v5.40?, Paul Cochrane on Fixing a fifteen-year-old curve fit bugor Salve is following up on his talk with a CPAN security BOF in the breakout room. Mohammad is always worth watching, but I very much enjoyed reading Paul’s blog post on this bug recently – so I haven’t decided yet where I’ll be.
Then we have a choice between Max Maischein – Managing recent files from Perl (which sounds useful), Nana Insaidoo – opensource vulnerabilities and where to find them (which sounds vital!) and the continuation of Salve’s BOF.
The last slot in this session is Mike Whitaker – Names are hard (which is inarguable), Yujia Zhai – Perl/Raku Based Coursework Design for Engineering Education or even more of Salve’s BOF.
Then we have a twenty-minute break. Phew. I think we’ll all need it after all that top-notch information.
Things get a bit disjointed after the break. There’s Andrew Soloman with Perl Talent Management: How Logicly attracts, develops, and retains their Perl developers. But that overlaps with two talks in the other main room – Ian Boddison with Perl, AI and Your System followed by Saif Ahmed with Bit Vector Arrays to Pixels in a Terminal with One Subroutine. And while all that’s going on, the breakout room has a session of Science Perl Talks chaired by Andrew Neil. They all sound interesting, but my interest in training trumps my other interests, so I’ll be listening to Andrew Soloman.
And then there are the lighting talks. As always, there will be a wide range of talks. I’ll be giving a brief update on Perl School. If you’ve been watching my social media, you might have an idea what I’ll be announcing.
Then we have the intriguingly-named Thanks & The Future of LPW before we all head off to the pub for a debrief.
There are currently about 140 people signed up for the workshop. I don’t know what the venue capacity is, but I’m sure they can squeeze a more in if you’d like to register. Oh, and if you are registered, please mark the talks you’re interested in on the schedule – it makes it easier for the organisers to decide which talks should be in which rooms.
Of course, if you’re not within easy travelling distance of London, then don’t forget that there are other Perl events in other parts of the world. In particular, there will be a TPRC in Greenville, South Carolina next year. See https://tprc.us/ for details.
To close, I’d like to thank the sponsors of this year’s LPW. Without them, the workshop wouldn’t be able to go ahead. Please show them some love.
The post London Perl Workshop 2024 – Preview appeared first on Perl Hacks.
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 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:
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.
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.
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.
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.
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.
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.
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.
Yesterday’s coronation showed Britain doing what Britain does best — putting on the most gloriously bonkers ceremony the world has seen…
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.
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.
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.