Powered by Perlanet
Last summer, I wrote a couple of posts about my lightweight, roll-your-own approach to deploying PSGI (Dancer) web apps:
In those posts, I described how I avoided heavyweight deployment tools by writing a small, custom Perl script (app_service
) to start and manage them. It was minimal, transparent, and easy to replicate.
It also wasn’t great.
The system mostly worked, but it had a number of growing pains:
systemctl
.curl
, not journalctl
.As I started running more apps, this ad-hoc approach became harder to justify. It was time to grow up.
psgi-systemd-deploy
So today (with some help from ChatGPT) I wrote psgi-systemd-deploy — a simple, declarative deployment tool for PSGI apps that integrates directly with systemd
. It generates .service
files for your apps from environment-specific config and handles all the fiddly bits (paths, ports, logging, restart policies, etc.) with minimal fuss.
Key benefits:
.deploy.env
.env
file support for application-specific settingsenvsubst
systemd
units you can inspect and manage yourself--dry-run
mode so you can preview changes before deployingrun_all
helper script for managing all your deployed apps with one commandYou may know about my Line of Succession web site. This is one of the Dancer apps I’ve been talking about. To deploy it, I wrote a .deploy.env
file that looks like this:
WEBAPP_SERVICE_NAME=succession WEBAPP_DESC="British Line of Succession" WEBAPP_WORKDIR=/opt/succession WEBAPP_USER=succession WEBAPP_GROUP=psacln WEBAPP_PORT=2222 WEBAPP_WORKER_COUNT=5 WEBAPP_APP_PRELOAD=1
And optionally a .env
file for app-specific settings (e.g., database credentials). Then I run:
$ /path/to/psgi-systemd-deploy/deploy.sh
And that’s it. The app is now a first-class systemd
service, automatically started on boot and restartable with systemctl
.
run_all
Once you’ve deployed several PSGI apps using psgi-systemd-deploy
, you’ll probably want an easy way to manage them all at once. That’s where the run_all
script comes in.
It’s a simple but powerful wrapper around systemctl
that automatically discovers all deployed services by scanning for .deploy.env
files. That means no need to hard-code service names or paths — it just works, based on the configuration you’ve already provided.
Here’s how you might use it:
# Restart all PSGI apps $ run_all restart # Show current status $ run_all status # Stop them all (e.g., for maintenance) $ run_all stop
And if you want machine-readable output for scripting or monitoring, there’s a --json
flag:
$ run_all --json is-active | jq . [ { "service": "succession.service", "action": "is-active", "status": 0, "output": "active" }, { "service": "klortho.service", "action": "is-active", "status": 0, "output": "active" } ]
Under the hood, run_all
uses the same environment-driven model as the rest of the system — no surprises, no additional config files. It’s just a lightweight helper that understands your layout and automates the boring bits.
It’s not a replacement for systemctl
, but it makes common tasks across many services far more convenient — especially during development, deployment, or server reboots.
The goal of psgi-systemd-deploy
isn’t to replace Docker, K8s, or full-featured PaaS systems. It’s for the rest of us — folks running VPSes or bare-metal boxes where PSGI apps just need to run reliably and predictably under the OS’s own tools.
If you’ve been rolling your own init scripts, cron jobs, or nohup
-based hacks, give it a look. It’s clean, simple, and reliable — and a solid step up from duct tape.
The post Deploying Dancer Apps – The Next Generation first appeared on Perl Hacks.
Last summer, I wrote a couple of posts about my lightweight, roll-your-own approach to deploying PSGI (Dancer) web apps:
In those posts, I described how I avoided heavyweight deployment tools by writing a small, custom Perl script (app_service
) to start and manage them. It was minimal, transparent, and easy to replicate.
It also wasn’t great.
The system mostly worked, but it had a number of growing pains:
systemctl
.curl
, not journalctl
.As I started running more apps, this ad-hoc approach became harder to justify. It was time to grow up.
psgi-systemd-deploy
So today (with some help from ChatGPT) I wrote psgi-systemd-deploy — a simple, declarative deployment tool for PSGI apps that integrates directly with systemd
. It generates .service
files for your apps from environment-specific config and handles all the fiddly bits (paths, ports, logging, restart policies, etc.) with minimal fuss.
Key benefits:
.deploy.env
.env
file support for application-specific settingsenvsubst
systemd
units you can inspect and manage yourselfSafe — supports a --dry-run
mode so you can preview changes before deploying
Convenient — includes a run_all
helper script for managing all your deployed apps with one command
You may know about my Line of Succession web site. This is one of the Dancer apps I’ve been talking about. To deploy it, I wrote a .deploy.env
file that looks like this:
WEBAPP_SERVICE_NAME=succession
WEBAPP_DESC="British Line of Succession"
WEBAPP_WORKDIR=/opt/succession
WEBAPP_USER=succession
WEBAPP_GROUP=psacln
WEBAPP_PORT=2222
WEBAPP_WORKER_COUNT=5
WEBAPP_APP_PRELOAD=1
And optionally a .env
file for app-specific settings (e.g., database credentials). Then I run:
$ /path/to/psgi-systemd-deploy/deploy.sh
And that’s it. The app is now a first-class systemd
service, automatically started on boot and restartable with systemctl
.
run_all
Once you’ve deployed several PSGI apps using psgi-systemd-deploy
, you’ll probably want an easy way to manage them all at once. That’s where the run_all
script comes in.
It’s a simple but powerful wrapper around systemctl
that automatically discovers all deployed services by scanning for .deploy.env
files. That means no need to hard-code service names or paths — it just works, based on the configuration you’ve already provided.
Here’s how you might use it:
# Restart all PSGI apps
$ run_all restart
# Show current status
$ run_all status
# Stop them all (e.g., for maintenance)
$ run_all stop
And if you want machine-readable output for scripting or monitoring, there’s a --json
flag:
$ run_all --json is-active | jq .
[
{
"service": "succession.service",
"action": "is-active",
"status": 0,
"output": "active"
},
{
"service": "klortho.service",
"action": "is-active",
"status": 0,
"output": "active"
}
]
Under the hood, run_all
uses the same environment-driven model as the rest of the system — no surprises, no additional config files. It’s just a lightweight helper that understands your layout and automates the boring bits.
It’s not a replacement for systemctl
, but it makes common tasks across many services far more convenient — especially during development, deployment, or server reboots.
The goal of psgi-systemd-deploy
isn’t to replace Docker, K8s, or full-featured PaaS systems. It’s for the rest of us — folks running VPSes or bare-metal boxes where PSGI apps just need to run reliably and predictably under the OS’s own tools.
If you’ve been rolling your own init scripts, cron jobs, or nohup
-based hacks, give it a look. It’s clean, simple, and reliable — and a solid step up from duct tape.
The post Deploying Dancer Apps – The Next Generation first appeared on Perl Hacks.
Watched on Wednesday May 28, 2025.
Watched on Tuesday May 27, 2025.
Watched on Saturday May 24, 2025.
Watched on Thursday May 22, 2025.
Watched on Tuesday May 20, 2025.
Like most developers, I have a mental folder labelled “useful little tools I’ll probably never build.” Small utilities, quality-of-life scripts, automations — they’d save time, but not enough to justify the overhead of building them. So they stay stuck in limbo.
That changed when I started using AI as a regular part of my development workflow.
Now, when I hit one of those recurring minor annoyances — something just frictiony enough to slow me down — I open a ChatGPT tab. Twenty minutes later, I usually have a working solution. Not always perfect, but almost always 90% of the way there. And once that initial burst of momentum is going, finishing it off is easy.
It’s not quite mind-reading. But it is like having a superpowered pair programmer on tap.
Obviously, I do a lot of Perl development. When working on a Perl project, it’s common to have one or more lib/
directories in the repo that contain the project’s modules. To run test scripts or local tools, I often need to set the PERL5LIB
environment variable so that Perl can find those modules.
But I’ve got a lot of Perl projects — often nested in folders like ~/git
, and sometimes with extra lib/
directories for testing or shared code. And I switch between them frequently. Typing:
export PERL5LIB=lib
…over and over gets boring fast. And worse, if you forget to do it, your test script breaks with a misleading “Can’t locate Foo/Bar.pm” error.
What I wanted was this:
Every time I cd
into a directory, if there are any valid lib/
subdirectories beneath it, set PERL5LIB
automatically.
Only include lib/
dirs that actually contain .pm
files.
Skip junk like .vscode
, blib
, and old release folders like MyModule-1.23/
.
Don’t scan the entire world if I cd ~/git
, which contains hundreds of repos.
Show me what it’s doing, and let me test it in dry-run mode.
With ChatGPT, I built a drop-in Bash function in about half an hour that does exactly that. It’s now saved as perl5lib_auto.sh
, and it:
Wraps cd()
to trigger a scan after every directory change
Finds all qualifying lib/
directories beneath the current directory
Filters them using simple rules:
Must contain .pm
files
Must not be under .vscode/
, .blib/
, or versioned build folders
Excludes specific top-level directories (like ~/git
) by default
Lets you configure everything via environment variables
Offers verbose
, dry-run
, and force
modes
Can append to or overwrite your existing PERL5LIB
You drop it in your ~/.bashrc
(or wherever you like), and your shell just becomes a little bit smarter.
source ~/bin/perl5lib_auto.sh cd ~/code/MyModule # => PERL5LIB set to: /home/user/code/MyModule/lib PERL5LIB_VERBOSE=1 cd ~/code/AnotherApp # => [PERL5LIB] Found 2 eligible lib dir(s): # => /home/user/code/AnotherApp/lib # => /home/user/code/AnotherApp/t/lib # => PERL5LIB set to: /home/user/code/AnotherApp/lib:/home/user/code/AnotherApp/t/lib
You can also set environment variables to customise behaviour:
export PERL5LIB_EXCLUDE_DIRS="$HOME/git:$HOME/legacy" export PERL5LIB_EXCLUDE_PATTERNS=".vscode:blib" export PERL5LIB_LIB_CAP=5 export PERL5LIB_APPEND=1
Or simulate what it would do:
PERL5LIB_DRYRUN=1 cd ~/code/BigProject
The full script is available on GitHub:
https://github.com/davorg/perl5lib_auto
I’d love to hear how you use it — or how you’d improve it. Feel free to:
Star the repo
Open issues for suggestions or bugs
Send pull requests with fixes, improvements, or completely new ideas
It’s a small tool, but it’s already saved me a surprising amount of friction. If you’re a Perl hacker who jumps between projects regularly, give it a try — and maybe give AI co-coding a try too while you’re at it.
What useful little utilities have you written with help from an AI pair-programmer?
The post Turning AI into a Developer Superpower: The PERL5LIB Auto-Setter first appeared on Perl Hacks.
Like most developers, I have a mental folder labelled “useful little tools I’ll probably never build.” Small utilities, quality-of-life scripts, automations — they’d save time, but not enough to justify the overhead of building them. So they stay stuck in limbo.
That changed when I started using AI as a regular part of my development workflow.
Now, when I hit one of those recurring minor annoyances — something just frictiony enough to slow me down — I open a ChatGPT tab. Twenty minutes later, I usually have a working solution. Not always perfect, but almost always 90% of the way there. And once that initial burst of momentum is going, finishing it off is easy.
It’s not quite mind-reading. But it is like having a superpowered pair programmer on tap.
Obviously, I do a lot of Perl development. When working on a Perl project, it’s common to have one or more lib/
directories in the repo that contain the project’s modules. To run test scripts or local tools, I often need to set the PERL5LIB
environment variable so that Perl can find those modules.
But I’ve got a lot of Perl projects — often nested in folders like ~/git
, and sometimes with extra lib/
directories for testing or shared code. And I switch between them frequently. Typing:
export PERL5LIB=lib
…over and over gets boring fast. And worse, if you forget to do it, your test script breaks with a misleading “Can’t locate Foo/Bar.pm” error.
What I wanted was this:
Every time I cd
into a directory, if there are any valid lib/
subdirectories beneath it, set PERL5LIB
automatically.
Only include lib/
dirs that actually contain .pm
files.
Skip junk like .vscode
, blib
, and old release folders like MyModule-1.23/
.
Don’t scan the entire world if I cd ~/git
, which contains hundreds of repos.
Show me what it’s doing, and let me test it in dry-run mode.
With ChatGPT, I built a drop-in Bash function in about half an hour that does exactly that. It’s now saved as perl5lib_auto.sh
, and it:
Wraps cd()
to trigger a scan after every directory change
Finds all qualifying lib/
directories beneath the current directory
Filters them using simple rules:
Excludes specific top-level directories (like ~/git
) by default
Lets you configure everything via environment variables
Offers verbose
, dry-run
, and force
modes
Can append to or overwrite your existing PERL5LIB
You drop it in your ~/.bashrc
(or wherever you like), and your shell just becomes a little bit smarter.
source ~/bin/perl5lib_auto.sh
cd ~/code/MyModule
# => PERL5LIB set to: /home/user/code/MyModule/lib
PERL5LIB_VERBOSE=1 cd ~/code/AnotherApp
# => [PERL5LIB] Found 2 eligible lib dir(s):
# => /home/user/code/AnotherApp/lib
# => /home/user/code/AnotherApp/t/lib
# => PERL5LIB set to: /home/user/code/AnotherApp/lib:/home/user/code/AnotherApp/t/lib
You can also set environment variables to customise behaviour:
export PERL5LIB_EXCLUDE_DIRS="$HOME/git:$HOME/legacy"
export PERL5LIB_EXCLUDE_PATTERNS=".vscode:blib"
export PERL5LIB_LIB_CAP=5
export PERL5LIB_APPEND=1
Or simulate what it would do:
PERL5LIB_DRYRUN=1 cd ~/code/BigProject
The full script is available on GitHub:
I’d love to hear how you use it — or how you’d improve it. Feel free to:
⭐ Star the repo
🐛 Open issues for suggestions or bugs
🔀 Send pull requests with fixes, improvements, or completely new ideas
It’s a small tool, but it’s already saved me a surprising amount of friction. If you’re a Perl hacker who jumps between projects regularly, give it a try — and maybe give AI co-coding a try too while you’re at it.
What useful little utilities have you written with help from an AI pair-programmer?
The post Turning AI into a Developer Superpower: The PERL5LIB Auto-Setter first appeared on Perl Hacks.
You might know that I publish books about Perl at Perl School. What you might now know is that I also publish more general technical books at Clapham Technical Press. If you scroll down to the bottom of that page, you’ll see a list of the books that I’ve published. You’ll also see evidence of the problem I’ve been solving this morning.
Books tend to have covers that are in a portrait aspect ratio. But the template I’m using to display them requires images in a landscape aspect ratio. This is a common enough problem. And, of course, we’ve developed a common way of getting around it. You’ll see it on that page. We create a larger version of the image (large enough to fill the width of where the image is displayed), apply some level of Gaussian blur to the image and insert a new copy of the image over that. So we get our original image with a tastefully blurred background which echoes the colour of the image. ChatGPT tells me this is called a “Blurred Fill”.
So that’s all good. But as I’m publishing more books, I need to create these images on a pretty regular basis. And, of course, if I do something more than three or four times, I will want to automate.
A while ago, I wrote a simple program called “blur” that used Imager to apply the correct transformations to an image. But this morning, I decided I should really make that program a bit more useful. And release it to CPAN. So that’s what I’ve been doing.
Adjusting images to fit various aspect ratios without losing essential content or introducing unsightly borders is a frequent challenge. Manually creating a blurred background for each image is time-consuming and inefficient, especially when dealing with multiple images or integrating into automated workflows.
App::BlurFill is a Perl module and CLI tool designed to streamline the process of creating images with blurred backgrounds. It takes an input image and generates a new image where the original is centred over a blurred version of itself, adjusted to the specified dimensions.
Install via CPAN:
cpanm App::BlurFill
Then to use the CLI tool:
blurfill --width=800 --height=600 input.jpg
This command will generate input_blur.jpg
with the specified dimensions.
App::BlurFill also includes a web interface built with Dancer2. You can start the web server and send POST requests with an image file to receive the processed image in response.
Example using curl
:
curl -OJ -X POST http://localhost:5000/blur -F "image=@input.jpg"
The response will be the new image file, ready for use.
App::BlurFill is written in Perl 5.40, using the new perlclass feature. It makes use of the Imager
module for image processing tasks. Currently, it supports JPG, PNG and GIF.
Future enhancements may include:
App::Blurred aims to simplify the task of creating visually consistent images across various platforms and devices. Feedback and contributions are welcome to help improve its functionality and usability.
Please let me know if you find it useful or if there are extra features you would find useful.
Oh, and why not buy some Clapham Technical Press books!
Update: I forgot to include a link to the GitHub repository. It’s at https://github.com/davorg-cpan/app-blurfill
The post Reformating images with App::BlurFill first appeared on Perl Hacks.
You might know that I publish books about Perl at Perl School. What you might now know is that I also publish more general technical books at Clapham Technical Press. If you scroll down to the bottom of that page, you’ll see a list of the books that I’ve published. You’ll also see evidence of the problem I’ve been solving this morning.
Books tend to have covers that are in a portrait aspect ratio. But the template I’m using to display them requires images in a landscape aspect ratio. This is a common enough problem. And, of course, we’ve developed a common way of getting around it. You’ll see it on that page. We create a larger version of the image (large enough to fill the width of where the image is displayed), apply some level of Gaussian blur to the image and insert a new copy of the image over that. So we get our original image with a tastefully blurred background which echoes the colour of the image. ChatGPT tells me this is called a “Blurred Fill”.
So that’s all good. But as I’m publishing more books, I need to create these images on a pretty regular basis. And, of course, if I do something more than three or four times, I will want to automate.
A while ago, I wrote a simple program called “blur” that used Imager to apply the correct transformations to an image. But this morning, I decided I should really make that program a bit more useful. And release it to CPAN. So that’s what I’ve been doing.
Adjusting images to fit various aspect ratios without losing essential content or introducing unsightly borders is a frequent challenge. Manually creating a blurred background for each image is time-consuming and inefficient, especially when dealing with multiple images or integrating into automated workflows.
App::BlurFill is a Perl module and CLI tool designed to streamline the process of creating images with blurred backgrounds. It takes an input image and generates a new image where the original is centred over a blurred version of itself, adjusted to the specified dimensions.
Install via CPAN:
cpanm App::BlurFill
Then to use the CLI tool:
blurfill --width=800 --height=600 input.jpg
This command will generate input_blur.jpg
with the specified dimensions.
App::BlurFill also includes a web interface built with Dancer2. You can start the web server and send POST requests with an image file to receive the processed image in response.
Example using curl
:
curl -OJ -X POST http://localhost:5000/blur -F "image=@input.jpg"
The response will be the new image file, ready for use.
App::BlurFill is written in Perl 5.40, using the new perlclass feature. It makes use of the Imager
module for image processing tasks. Currently, it supports JPG, PNG and GIF.
Future enhancements may include:
App::Blurred aims to simplify the task of creating visually consistent images across various platforms and devices. Feedback and contributions are welcome to help improve its functionality and usability.
Please let me know if you find it useful or if there are extra features you would find useful.
Oh, and why not buy some Clapham Technical Press books!
Update: I forgot to include a link to the GitHub repository. It's at https://github.com/davorg-cpan/app-blurfill
The post Reformating images with App::BlurFill first appeared on Perl Hacks.
I write blog posts in a number of different places:
And most of those posts get syndicated to other places:
It’s also possible that I’ll write original posts on one of these syndication sites without posting to one of my sites first.
Recently, when revamping my professional website I decided that I wanted to display a list recent posts from all of those sources. But because of the syndication, it was all a bit noisy: multiple copies of the same post, repeated titles, and a poor reading experience.
What I wanted was a single, clean feed — a unified view of everything I’ve written, without repetition.
So I wrote a tool.
I wanted to:
App::FeedDeduplicator is a new CPAN module and CLI tool for aggregating and deduplicating web feeds.
It reads a list of feed URLs from a JSON config file, downloads and parses them, filters out duplicates (based on canonical URLs or titles), sorts the results by date, and emits a clean, modern feed.
{ "output_format": "json", "max_entries": 10, "feeds": [{ "feed": "https://perlhacks.com/feed/", "web": "https://perlhacks.com/", "name": "Perl Hacks" }, { "feed": "https://davecross.substack.com/feed", "web": "https://davecross.substack.com/", "name": "Substack" }, { "feed": "https://blog.dave.org.uk/feed/", "web": "https://blog.dave.org.uk/", "name": "Davblog" }, { "feed": "https://dev.to/feed/davorg", "web": "https://dev.to/davorg", "name": "Dev.to" }, { "feed": "https://davorg.medium.com/feed", "web": "https://davorg.medium.com/", "name": "Medium" }] }
<link rel="canonical">
tagInstall via CPAN:
cpanm App::FeedDeduplicator
Then run it with:
feed-deduplicator config.json
If no config file is specified, it will try the FEED_DEDUP_CONFIG
environment variable or fallback to ~/.feed-deduplicator/config.json
.
There’s also a Docker image with the latest version installed.
The tool is written in Perl 5.38+ and uses the new class
feature (perlclass
) for a cleaner OO structure:
App::FeedDeduplicator::Aggregator
handles feed downloading and parsingApp::FeedDeduplicator::Deduplicator
detects and removes duplicatesApp::FeedDeduplicator::Publisher
generates the final outputIt’s all very much a work in progress at the moment. It works for me, but there are bound to be some improvements needed, so it works for more people. A few things I already know I want to improve:
If you want a clean, single-source feed that represents your writing without duplication, App::FeedDeduplicator
might be just what you need.
I’m using it now to power the aggregated feed on my site. Let me know what you think!
The post Cleaner web feed aggregation with App::FeedDeduplicator first appeared on Perl Hacks.
I write blog posts in a number of different places:
And most of those posts get syndicated to other places:
It’s also possible that I’ll write original posts on one of these syndication sites without posting to one of my sites first.
Recently, when revamping my professional website I decided that I wanted to display a list recent posts from all of those sources. But because of the syndication, it was all a bit noisy: multiple copies of the same post, repeated titles, and a poor reading experience.
What I wanted was a single, clean feed — a unified view of everything I’ve written, without repetition.
So I wrote a tool.
I wanted to:
App::FeedDeduplicator is a new CPAN module and CLI tool for aggregating and deduplicating web feeds.
It reads a list of feed URLs from a JSON config file, downloads and parses them, filters out duplicates (based on canonical URLs or titles), sorts the results by date, and emits a clean, modern feed.
{
"output_format": "json",
"max_entries": 10,
"feeds": [{
"feed": "https://perlhacks.com/feed/",
"web": "https://perlhacks.com/",
"name": "Perl Hacks"
}, {
"feed": "https://davecross.substack.com/feed",
"web": "https://davecross.substack.com/",
"name": "Substack"
}, {
"feed": "https://blog.dave.org.uk/feed/",
"web": "https://blog.dave.org.uk/",
"name": "Davblog"
}, {
"feed": "https://dev.to/feed/davorg",
"web": "https://dev.to/davorg",
"name": "Dev.to"
}, {
"feed": "https://davorg.medium.com/feed",
"web": "https://davorg.medium.com/",
"name": "Medium"
}]
}
<link rel="canonical">
tagInstall via CPAN:
cpanm App::FeedDeduplicator
Then run it with:
feed-deduplicator config.json
If no config file is specified, it will try the FEED_DEDUP_CONFIG
environment variable or fallback to ~/.feed-deduplicator/config.json
.
There’s also a Docker image with the latest version installed.
The tool is written in Perl 5.38+ and uses the new class
feature (perlclass
) for a cleaner OO structure:
App::FeedDeduplicator::Aggregator
handles feed downloading and parsingApp::FeedDeduplicator::Deduplicator
detects and removes duplicatesApp::FeedDeduplicator::Publisher
generates the final outputIt’s all very much a work in progress at the moment. It works for me, but there are bound to be some improvements needed, so it works for more people. A few things I already know I want to improve:
If you want a clean, single-source feed that represents your writing without duplication, App::FeedDeduplicator
might be just what you need.
I’m using it now to power the aggregated feed on my site. Let me know what you think!
The post Cleaner web feed aggregation with App::FeedDeduplicator first appeared on Perl Hacks.
Last week, I wrote a blog post about how I gave new life to an old domain by building a new website to live on that domain. With help from ChatGPT, it only took a few hours to build the site. While I’ll be adding new businesses and events to the site over time, that is currently a manual process and the site is mostly static.
This week, I wanted to take things a bit further. I wanted to build a site that was updated daily – but without any input from me.
Whois tells me I first registered cool-stuff.co.uk in September 1997. It was one of the first domains I registered. It has hosted a couple of very embarrassing early sites that I built, and for a while, it served as the email domain for several members of my family. But since they all moved to GMail, it’s been pretty much dormant. What it has never hosted is what I originally registered it for – a directory of cool things on the world wide web. So that’s what I decided to build.
So here’s the plan:
I decided to stick with Jekyll and Minimal Mistakes as I enjoyed using them to build Balham.org. They make it easy to spin up a good-looking website, but they also have ways to add complexity when required. That complexity wasn’t needed here.
The site itself was very simple. It’s basically driven from a YAML file called coolstuff.yml which lists the sites we’ve featured. From that, we build a front page which features a new site every day and an archive page which lists all the previous sites we have featured. Oh, and we also have an RSS feed of the sites we feature. This is all pretty basic stuff.
As you’d expect from one of my projects, the site is hosted on GitHub Pages and is updated automatically using GitHub Actions.
It’s in GitHub Actions where the clever (not really all that clever – just new to me) stuff happens. There’s a workflow called update-coolstuff.yml which runs at 02:00 every morning and adds a new site. And it does that by asking ChatGPT to recommend a site. Here’s the workflow:
name: Update Cool Stuff on: schedule: - cron: '0 2 * * *' # Runs at 2 AM UTC workflow_dispatch: jobs: update: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install Perl dependencies run: | sudo apt-get update && sudo apt-get install -y cpanminus cpanm -n --sudo OpenAPI::Client::OpenAI YAML JSON::MaybeXS - name: Get a cool website from OpenAI env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} run: | perl .github/scripts/fetch_cool_site - name: Commit and push if changed run: | git config user.name "github-actions" git config user.email "github-actions@github.com" git add docs/_data/coolstuff.yml git diff --cached --quiet || git commit -m "Add new cool site" git push
There’s not much clever going on there. I needed to ensure I had an OpenAI subscription with credit in the account (this is going to cost a tiny amount of money to run – I’m making one request a day!), and I set up the API key as a secret in the repo (with the name “OPENAI_API_KEY).
The magic all happens in the “fetch_cool_site” program. So let’s look at that next:
#!/usr/bin/env perl use strict; use warnings; use builtin qw[trim]; use OpenAPI::Client::OpenAI; use YAML qw(LoadFile DumpFile); use Time::Piece; use JSON::MaybeXS; my $api_key = $ENV{"OPENAI_API_KEY"} or die "OPENAI_API_KEY is not set\n"; my $client = OpenAPI::Client::OpenAI->new; my $prompt = join " ", "Suggest a really cool, creative, or fun website to feature today on a site called 'Cool Stuff'.", "Just return the name, URL, and a one-paragraph description of why it's cool. Only return one site.", "The URL should just be the URL itself. Do not wrap it in Markdown."; my $res = $client->createChatCompletion({ body => { model => 'gpt-4o', messages => [ { role => 'system', content => 'You are a helpful curator of awesome websites.' }, { role => 'user', content => $prompt }, ], temperature => 1.0, } }); my $text = $res->res->json->{choices}[0]{message}{content}; my @lines = split /\n/, $text; my ($name, $url, @desc) = @lines; $name =~ s/^\*\s*//; my $description = join ' ', @desc; my $new_entry = { date => localtime->ymd, name => trim($name), url => trim($url), description => trim($description), }; my $file = "docs/_data/coolstuff.yml"; my $entries = LoadFile($file); unless (grep { $_->{url} eq $new_entry->{url} } @$entries) { push @$entries, $new_entry; DumpFile($file, $entries); }
We’re using OpenAPI::Client::OpenAI to talk to the OpenAI API. From my limited knowledge, that seems to be the best option, currently. But I’m happy to be pointed to better suggestions.
Most of the code is copied from the examples in the module’s distribution. And the parsing of the response is probably a bit fragile. I expect I could tweak the prompt a bit to get the data back in a slightly more robust format.
But it works as it is. This morning I woke up and found a new site featured on the front page. So, rather than spend time tweaking exactly how it works, I thought it would be a good idea to get a blog post out there, so other people can see how easy it is to use ChatGPT in this way.
What do you think? Can you see ways that you’d like to include ChatGPT responses in some of your code?
The website is live at cool-stuff.co.uk.
The post Finding cool stuff with ChatGPT first appeared on Perl Hacks.
Last week, I wrote a blog post about how I gave new life to an old domain by building a new website to live on that domain. With help from ChatGPT, it only took a few hours to build the site. While I’ll be adding new businesses and events to the site over time, that is currently a manual process and the site is mostly static.
This week, I wanted to take things a bit further. I wanted to build a site that was updated daily – but without any input from me.
Whois tells me I first registered cool-stuff.co.uk in September 1997. It was one of the first domains I registered. It has hosted a couple of very embarrassing early sites that I built, and for a while, it served as the email domain for several members of my family. But since they all moved to GMail, it’s been pretty much dormant. What it has never hosted is what I originally registered it for – a directory of cool things on the world wide web. So that’s what I decided to build.
So here’s the plan:
I decided to stick with Jekyll and Minimal Mistakes as I enjoyed using them to build Balham.org. They make it easy to spin up a good-looking website, but they also have ways to add complexity when required. That complexity wasn’t needed here.
The site itself was very simple. It’s basically driven from a YAML file called coolstuff.yml which lists the sites we’ve featured. From that, we build a front page which features a new site every day and an archive page which lists all the previous sites we have featured. Oh, and we also have an RSS feed of the sites we feature. This is all pretty basic stuff.
As you’d expect from one of my projects, the site is hosted on GitHub Pages and is updated automatically using GitHub Actions.
It’s in GitHub Actions where the clever (not really all that clever – just new to me) stuff happens. There’s a workflow called update-coolstuff.yml which runs at 02:00 every morning and adds a new site. And it does that by asking ChatGPT to recommend a site. Here’s the workflow:
name: Update Cool Stuff
on:
schedule:
- cron: '0 2 * * *' # Runs at 2 AM UTC
workflow_dispatch:
jobs:
update:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Perl dependencies
run: |
sudo apt-get update && sudo apt-get install -y cpanminus
cpanm -n --sudo OpenAPI::Client::OpenAI YAML JSON::MaybeXS
- name: Get a cool website from OpenAI
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
perl .github/scripts/fetch_cool_site
- name: Commit and push if changed
run: |
git config user.name "github-actions"
git config user.email "github-actions@github.com"
git add docs/_data/coolstuff.yml
git diff --cached --quiet || git commit -m "Add new cool site"
git push
There’s not much clever going on there. I needed to ensure I had an OpenAI subscription with credit in the account (this is going to cost a tiny amount of money to run – I’m making one request a day!), and I set up the API key as a secret in the repo (with the name “OPENAI_API_KEY).
The magic all happens in the “fetch_cool_site” program. So let’s look at that next:
#!/usr/bin/env perl
use strict;
use warnings;
use builtin qw[trim];
use OpenAPI::Client::OpenAI;
use YAML qw(LoadFile DumpFile);
use Time::Piece;
use JSON::MaybeXS;
my $api_key = $ENV{"OPENAI_API_KEY"} or die "OPENAI_API_KEY is not set\n";
my $client = OpenAPI::Client::OpenAI->new;
my $prompt = join " ",
"Suggest a really cool, creative, or fun website to feature today on a site called 'Cool Stuff'.",
"Just return the name, URL, and a one-paragraph description of why it's cool. Only return one site.",
"The URL should just be the URL itself. Do not wrap it in Markdown.";
my $res = $client->createChatCompletion({
body => {
model => 'gpt-4o',
messages => [
{ role => 'system', content => 'You are a helpful curator of awesome websites.' },
{ role => 'user', content => $prompt },
],
temperature => 1.0,
}
});
my $text = $res->res->json->{choices}[0]{message}{content};
my @lines = split /\n/, $text;
my ($name, $url, @desc) = @lines;
$name =~ s/^\*\s*//;
my $description = join ' ', @desc;
my $new_entry = {
date => localtime->ymd,
name => trim($name),
url => trim($url),
description => trim($description),
};
my $file = "docs/_data/coolstuff.yml";
my $entries = LoadFile($file);
unless (grep { $_->{url} eq $new_entry->{url} } @$entries) {
push @$entries, $new_entry;
DumpFile($file, $entries);
}
We’re using OpenAPI::Client::OpenAI to talk to the OpenAI API. From my limited knowledge, that seems to be the best option, currently. But I’m happy to be pointed to better suggestions.
Most of the code is copied from the examples in the module’s distribution. And the parsing of the response is probably a bit fragile. I expect I could tweak the prompt a bit to get the data back in a slightly more robust format.
But it works as it is. This morning I woke up and found a new site featured on the front page. So, rather than spend time tweaking exactly how it works, I thought it would be a good idea to get a blog post out there, so other people can see how easy it is to use ChatGPT in this way.
What do you think? Can you see ways that you’d like to include ChatGPT responses in some of your code?
The website is live at cool-stuff.co.uk.
The post Finding cool stuff with ChatGPT first appeared on Perl Hacks.
A few days ago, I looked at an unused domain I owned — balham.org — and thought: “There must be a way to make this useful… and maybe even make it pay for itself.”
So I set myself a challenge: one day to build something genuinely useful. A site that served a real audience (people in and around Balham), that was fun to build, and maybe could be turned into a small revenue stream.
It was also a great excuse to get properly stuck into Jekyll and the Minimal Mistakes theme — both of which I’d dabbled with before, but never used in anger. And, crucially, I wasn’t working alone: I had ChatGPT as a development assistant, sounding board, researcher, and occasional bug-hunter.
Balham is a reasonably affluent, busy part of south west London. It’s full of restaurants, cafés, gyms, independent shops, and people looking for things to do. It also has a surprisingly rich local history — from Victorian grandeur to Blitz-era tragedy.
I figured the site could be structured around three main pillars:
Throw in a curated homepage and maybe a blog later, and I had the bones of a useful site. The kind of thing that people would find via Google or get sent a link to by a friend.
I wanted something static, fast, and easy to deploy. My toolchain ended up being:
The site is 100% static, with no backend, no databases, no CMS. It builds automatically on GitHub push, and is entirely hosted via GitHub Pages.
I gave us about six solid hours to build something real. Here’s what we did (“we” meaning me + ChatGPT):
The domain was already pointed at GitHub Pages, and I had a basic “Hello World” site in place. We cleared that out, set up a fresh Jekyll repo, and added a _config.yml that pointed at the Minimal Mistakes remote theme. No cloning or submodules.
We decided to create four main pages:
We used the layout: single layout provided by Minimal Mistakes, and created custom permalinks so URLs were clean and extension-free.
This was built from scratch using a YAML data file (_data/businesses.yml). ChatGPT gathered an initial list of 20 local businesses (restaurants, shops, pubs, etc.), checked their status, and added details like name, category, address, website, and a short description.
In the template, we looped over the list, rendered sections with conditional logic (e.g., don’t output the website link if it’s empty), and added anchor IDs to each entry so we could link to them directly from the homepage.
Built exactly the same way, but using _data/events.yml. To keep things realistic, we seeded a small number of example events and included a note inviting people to email us with new submissions.
We wanted the homepage to show a curated set of businesses and events. So we created a third data file, _data/featured.yml, which just listed the names of the featured entries. Then in the homepage template, we used where and slugify to match names and pull in the full record from businesses.yml or events.yml. Super DRY.
We added a map of Balham as a hero image, styled responsively. Later we created a .responsive-inline-image class to embed supporting images on the history page without overwhelming the layout.
This turned out to be one of the most satisfying parts. We wrote five paragraphs covering key moments in Balham’s development — Victorian expansion, Du Cane Court, The Priory, the Blitz, and modern growth.
Then we sourced five CC-licensed or public domain images (from Wikimedia Commons and Geograph) to match each paragraph. Each was wrapped in a <figure> with proper attribution and a consistent CSS class. The result feels polished and informative.
We went through all the basics:
We added GA4 tracking using Minimal Mistakes’ built-in support, and verified the domain with Google Search Console. A sitemap was submitted, and indexing kicked in within minutes.
We ran Lighthouse and WAVE tests. Accessibility came out at 100%. Performance dipped slightly due to Google Fonts and image size, but we did our best to optimise without sacrificing aesthetics.
We added a site-wide footer call-to-action inviting people to email us with suggestions for businesses or events. This makes the site feel alive and participatory, even without a backend form.
This started as a fun experiment: could I monetise an unused domain and finally learn Jekyll properly?
What I ended up with is a genuinely useful local resource — one that looks good, loads quickly, and has room to grow.
If you’re sitting on an unused domain, and you’ve got a free day and a chatbot at your side — you might be surprised what you can build.
Oh, and one final thing — obviously you can also get ChatGPT to write a blog post talking about the project :-)
Originally published at https://blog.dave.org.uk on March 23, 2025.
A few days ago, I looked at an unused domain I owned — balham.org — and thought: “There must be a way to make this useful… and maybe even make it pay for itself.”
So I set myself a challenge: one day to build something genuinely useful. A site that served a real audience (people in and around Balham), that was fun to build, and maybe could be turned into a small revenue stream.
It was also a great excuse to get properly stuck into Jekyll and the Minimal Mistakes theme — both of which I’d dabbled with before, but never used in anger. And, crucially, I wasn’t working alone: I had ChatGPT as a development assistant, sounding board, researcher, and occasional bug-hunter.
Balham is a reasonably affluent, busy part of south west London. It’s full of restaurants, cafés, gyms, independent shops, and people looking for things to do. It also has a surprisingly rich local history — from Victorian grandeur to Blitz-era tragedy.
I figured the site could be structured around three main pillars:
Throw in a curated homepage and maybe a blog later, and I had the bones of a useful site. The kind of thing that people would find via Google or get sent a link to by a friend.
I wanted something static, fast, and easy to deploy. My toolchain ended up being:
The site is 100% static, with no backend, no databases, no CMS. It builds automatically on GitHub push, and is entirely hosted via GitHub Pages.
I gave us about six solid hours to build something real. Here’s what we did (“we” meaning me + ChatGPT):
The domain was already pointed at GitHub Pages, and I had a basic “Hello World” site in place. We cleared that out, set up a fresh Jekyll repo, and added a _config.yml
that pointed at the Minimal Mistakes remote theme. No cloning or submodules.
We decided to create four main pages:
index.md
)directory/index.md
)events/index.md
)history/index.md
)We used the layout: single
layout provided by Minimal Mistakes, and created custom permalinks so URLs were clean and extension-free.
This was built from scratch using a YAML data file (_data/businesses.yml
). ChatGPT gathered an initial list of 20 local businesses (restaurants, shops, pubs, etc.), checked their status, and added details like name, category, address, website, and a short description.
In the template, we looped over the list, rendered sections with conditional logic (e.g., don’t output the website link if it’s empty), and added anchor IDs to each entry so we could link to them directly from the homepage.
Built exactly the same way, but using _data/events.yml
. To keep things realistic, we seeded a small number of example events and included a note inviting people to email us with new submissions.
We wanted the homepage to show a curated set of businesses and events. So we created a third data file, _data/featured.yml
, which just listed the names of the featured entries. Then in the homepage template, we used where
and slugify
to match names and pull in the full record from businesses.yml
or events.yml
. Super DRY.
We added a map of Balham as a hero image, styled responsively. Later we created a .responsive-inline-image
class to embed supporting images on the history page without overwhelming the layout.
This turned out to be one of the most satisfying parts. We wrote five paragraphs covering key moments in Balham’s development — Victorian expansion, Du Cane Court, The Priory, the Blitz, and modern growth.
Then we sourced five CC-licensed or public domain images (from Wikimedia Commons and Geograph) to match each paragraph. Each was wrapped in a <figure>
with proper attribution and a consistent CSS class. The result feels polished and informative.
We went through all the basics:
title
and description
in front matter for each pagerobots.txt
, sitemap.xml
, and a hand-crafted humans.txt
.html
extensionsWe added GA4 tracking using Minimal Mistakes’ built-in support, and verified the domain with Google Search Console. A sitemap was submitted, and indexing kicked in within minutes.
We ran Lighthouse and WAVE tests. Accessibility came out at 100%. Performance dipped slightly due to Google Fonts and image size, but we did our best to optimise without sacrificing aesthetics.
We added a site-wide footer call-to-action inviting people to email us with suggestions for businesses or events. This makes the site feel alive and participatory, even without a backend form.
This started as a fun experiment: could I monetise an unused domain and finally learn Jekyll properly?
What I ended up with is a genuinely useful local resource — one that looks good, loads quickly, and has room to grow.
If you’re sitting on an unused domain, and you’ve got a free day and a chatbot at your side — you might be surprised what you can build.
Oh, and one final thing – obviously you can also get ChatGPT to write a blog post talking about the project :-)
The post Building a website in a day — with help from ChatGPT appeared first on Davblog.
I built and launched a new website yesterday. It wasn’t what I planned to do, but the idea popped into my head while I was drinking my morning coffee on Clapham Common and it seemed to be the kind of thing I could complete in a day — so I decided to put my original plans on hold and built it instead.
The website is aimed at small business owners who think they need a website (or want to update their existing one) but who know next to nothing about web development and can easily fall prey to the many cowboy website companies that seem to dominate the “making websites for small companies” section of our industries. The site is structured around a number of questions you can ask a potential website builder to try and weed out the dodgier elements.
I’m not really in that sector of our industry. But while writing the content for that site, it occurred to me that some people might be interested in the tools I use to build sites like this.
I generally build websites about topics that I’m interested in and, therefore, know a fair bit about. But I probably don’t know everything about these subjects. So I’ll certainly brainstorm some ideas with ChatGPT. And, once I’ve written something, I’ll usually run it through ChatGPT again to proofread it. I consider myself a pretty good writer, but it’s embarrassing how often ChatGPT catches obvious errors.
I’ve used DALL-E (via ChatGPT) for a lot of image generation. This weekend, I subscribed to Midjourney because I heard it was better at generating images that include text. So far, that seems to be accurate.
I don’t write much raw HTML these days. I’ll generally write in Markdown and use a static site generator to turn that into a real website. This weekend I took the easy route and used Jekyll with the Minimal Mistakes theme. Honestly, I don’t love Jekyll, but it integrates well with GitHub Pages and I can usually get it to do what I want — with a combination of help from ChatGPT and reading the source code. I’m (slowly) building my own Static Site Generator ( Aphra) in Perl. But, to be honest, I find that when I use it I can easily get distracted by adding new features rather than getting the site built.
As I’ve hinted at, if I’m building a static site (and, it’s surprising how often that’s the case), it will be hosted on GitHub Pages. It’s not really aimed at end-users, but I know to you use it pretty well now. This weekend, I used the default mechanism that regenerates the site (using Jekyll) on every commit. But if I’m using Aphra or a custom site generator, I know I can use GitHub Actions to build and deploy the site.
If I’m writing actual HTML, then I’m old-skool enough to still use Bootstrap for CSS. There’s probably something better out there now, but I haven’t tried to work out what it is (feel free to let me know in the comments).
For a long while, I used jQuery to add Javascript to my pages — until someone was kind enough to tell me that vanilla Javascript had mostly caught up and jQuery was no longer necessary. I understand Javascript. And with help from GitHub Copilot, I can usually get it doing what I want pretty quickly.
Many years ago, I spent a couple of years working in the SEO group at Zoopla. So, now, I can’t think about building a website without considering SEO.
I quickly lose interest in the content side of SEO. Figuring out what my keywords are and making sure they’re scattered through the content at the correct frequency, feels like it stifles my writing (maybe that’s an area where ChatGPT can help) but I enjoy Technical SEO. So I like to make sure that all of my pages contain the correct structured data (usually JSON-LD). I also like to ensure my sites all have useful OpenGraph headers. This isn’t really SEO, I guess, but these headers control what people see when they share content on social media. So by making that as attractive as possible (a useful title and description, an attractive image) it encourages more sharing, which increases your site’s visibility and, in around about way, improves SEO.
I like to register all of my sites with Ahrefs — they will crawl my sites periodically and send me a long list of SEO improvements I can make.
I add Google Analytics to all of my sites. That’s still the best way to find out how popular your site it and where your traffic is coming from. I used to be quite proficient with Universal Analytics, but I must admit I haven’t fully got the hang of Google Analytics 4 yet-so I’m probably only scratching the surface of what it can do.
I also register all of my sites with Google Search Console. That shows me information about how my site appears in the Google Search Index. I also link that to Google Analytics — so GA also knows what searches brought people to my sites.
I think that covers everything-though I’ve probably forgotten something. It might sound like a lot, but once you get into a rhythm, adding these extra touches doesn’t take long. And the additional insights you gain make it well worth the effort.
If you’ve built a website recently, I’d love to hear about your approach. What tools and techniques do you swear by? Are there any must-have features or best practices I’ve overlooked? Drop a comment below or get in touch-I’m always keen to learn new tricks and refine my process. And if you’re a small business owner looking for guidance on choosing a web developer, check out my new site-it might just save you from a costly mistake!
Originally published at https://blog.dave.org.uk on March 16, 2025.
I built and launched a new website yesterday. It wasn’t what I planned to do, but the idea popped into my head while I was drinking my morning coffee on Clapham Common and it seemed to be the kind of thing I could complete in a day – so I decided to put my original plans on hold and built it instead.
The website is aimed at small business owners who think they need a website (or want to update their existing one) but who know next to nothing about web development and can easily fall prey to the many cowboy website companies that seem to dominate the “making websites for small companies” section of our industries. The site is structured around a number of questions you can ask a potential website builder to try and weed out the dodgier elements.
I’m not really in that sector of our industry. But while writing the content for that site, it occurred to me that some people might be interested in the tools I use to build sites like this.
I generally build websites about topics that I’m interested in and, therefore, know a fair bit about. But I probably don’t know everything about these subjects. So I’ll certainly brainstorm some ideas with ChatGPT. And, once I’ve written something, I’ll usually run it through ChatGPT again to proofread it. I consider myself a pretty good writer, but it’s embarrassing how often ChatGPT catches obvious errors.
I’ve used DALL-E (via ChatGPT) for a lot of image generation. This weekend, I subscribed to Midjourney because I heard it was better at generating images that include text. So far, that seems to be accurate.
I don’t write much raw HTML these days. I’ll generally write in Markdown and use a static site generator to turn that into a real website. This weekend I took the easy route and used Jekyll with the Minimal Mistakes theme. Honestly, I don’t love Jekyll, but it integrates well with GitHub Pages and I can usually get it to do what I want – with a combination of help from ChatGPT and reading the source code. I’m (slowly) building my own Static Site Generator (Aphra) in Perl. But, to be honest, I find that when I use it I can easily get distracted by adding new features rather than getting the site built.
As I’ve hinted at, if I’m building a static site (and, it’s surprising how often that’s the case), it will be hosted on GitHub Pages. It’s not really aimed at end-users, but I know how to use it pretty well now. This weekend, I used the default mechanism that regenerates the site (using Jekyll) on every commit. But if I’m using Aphra or a custom site generator, I know I can use GitHub Actions to build and deploy the site.
If I’m writing actual HTML, then I’m old-skool enough to still use Bootstrap for CSS. There’s probably something better out there now, but I haven’t tried to work out what it is (feel free to let me know in the comments).
For a long while, I used jQuery to add Javascript to my pages – until someone was kind enough to tell me that vanilla Javascript had mostly caught up and jQuery was no longer necessary. I understand Javascript. And with help from GitHub Copilot, I can usually get it doing what I want pretty quickly.
Many years ago, I spent a couple of years working in the SEO group at Zoopla. So, now, I can’t think about building a website without considering SEO.
I quickly lose interest in the content side of SEO. Figuring out what my keywords are and making sure they’re scattered through the content at the correct frequency, feels like it stifles my writing (maybe that’s an area where ChatGPT can help) but I enjoy Technical SEO. So I like to make sure that all of my pages contain the correct structured data (usually JSON-LD). I also like to ensure my sites all have useful OpenGraph headers. This isn’t really SEO, I guess, but these headers control what people see when they share content on social media. So by making that as attractive as possible (a useful title and description, an attractive image) it encourages more sharing, which increases your site’s visibility and, in around about way, improves SEO.
I like to register all of my sites with Ahrefs – they will crawl my sites periodically and send me a long list of SEO improvements I can make.
I add Google Analytics to all of my sites. That’s still the best way to find out how popular your site it and where your traffic is coming from. I used to be quite proficient with Universal Analytics, but I must admit I haven’t fully got the hang of Google Analytics 4 yet—so I’m probably only scratching the surface of what it can do.
I also register all of my sites with Google Search Console. That shows me information about how my site appears in the Google Search Index. I also link that to Google Analytics – so GA also knows what searches brought people to my sites.
I think that covers everything—though I’ve probably forgotten something. It might sound like a lot, but once you get into a rhythm, adding these extra touches doesn’t take long. And the additional insights you gain make it well worth the effort.
If you’ve built a website recently, I’d love to hear about your approach. What tools and techniques do you swear by? Are there any must-have features or best practices I’ve overlooked? Drop a comment below or get in touch—I’m always keen to learn new tricks and refine my process. And if you’re a small business owner looking for guidance on choosing a web developer, check out my new site—it might just save you from a costly mistake!
The post How I build websites in 2025 appeared first on Davblog.
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.
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.
The post 2023 in Gigs appeared first on Davblog.