Powered by Perlanet
Updated Mar 27
Updated Mar 27
I've written before about how I use GitHub Workflows to keep "semi-static" web sites up to date. It's a technique that I've found really useful. When I wrote that blog post, things were pretty simple - you chose which branch held your web site (there was a tradition for a while to use gh-pages
) and whether the web site pages were in the repos root directory or the directory called /docs
. I usually put my web site files into the /docs
directory in the master
(now main
) branch and things worked just fine.
The reason for storing the site in /docs
was so that there was a separation between the files that were used to generate the site from the generated output site itself. Many of my repos would have a /tt
directory that contained templates, a /data
directory which contains JSON files or an SQLite database and a /bin
directory with a build
program that pulls all that stuff together and generates a pile of HTML files that end up in the /docs
directory. In my original blog post on this subject, I demonstrated a GitHub Workflow definition that would regenerate the site (when input files changed or on a schedule) and committed any changed files in the /docs
directory. Some GitHub magic would then ensure that the new version of the site was deployed to the GitHub Pages server. All was well with the world.
Then, a few months ago, things got a little more complicated. We gained options about how your GitHub Pages site was deployed. The standard version that I'd be using before was called "deploy from a branch" but there was another option called "GitHub Actions". It seemed likely to me that I really needed to start using the "GitHub Actions" option, but things were still working the old way, and I had far more interesting things to investigate, so I left things the way they were.
Well, I say things were still working in the old way... They were, but something was a bit different. It seemed that the old method was being powered by a new GitHub Workflow called "pages-build-deployment" that had been automatically added to all the repos that needed it. And looking into the details of that workflow, I noticed that it was doing some things that were unnecessary in my repos - for example it assumed that the site was being built using Jekyll and that was only true for a couple of my repos. For most of them, that was unnecessary work. So I needed to look into the new deployment option in more detail.
I started a couple of weeks ago, by simply switching the option from "deploy from a branch" to "GitHub Actions" in the hope that, because I was already using GitHub Actions, things would Just Work. But, unfortunately, that wasn't the case. My new site was being generated and committed to the repo - but the changes weren't showing up on the live site. So I switched things back until I had time to look into in it more detail.
That time was today. It seemed that I needed to include code in my GitHub Workflow that would actually handle the deployment of the site to the GitHub Pages servers. A quick search of the GitHub Actions marketplace found the Deploy GitHub Pages site action which seemed to be the right thing. But reading the documentation, I worked out that it wanted to deploy the site from an artifact, so I needed to create that first. And then I found Upload GitHub Pages artifact which did the right thing. So it was just a case of adding these two actions to my workflows in the correct way.
Previously, my workflows for these sites just needed a single job (called build
) but now I added a deploy
job which depended on build
. For example, the workflow that builds Planet Perl now looks like this:
name: Generate web page
on:
push:
branches: '*'
schedule:
- cron: '37 */4 * * *'
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
container: davorg/perl-perlanet:latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Create pages
run: |
mkdir -p docs
perlanet > perlanet.log 2>&1
- name: Commit new page
if: github.repository == 'davorg/planetperl'
run: |
git config --global --add safe.directory /__w/planetperl/planetperl
GIT_STATUS=$(git status --porcelain)
echo $GIT_STATUS
git config user.name github-actions[bot]
git config user.email 41898282+github-actions[bot]@users.noreply.github.com
git add docs/
if [ "$GIT_STATUS" != "" ]; then git commit -m "Automated Web page generation"; fi
if [ "$GIT_STATUS" != "" ]; then git push; fi
- name: Archive perlanet logs
uses: actions/upload-artifact@v3
with:
name: perlanet.log
path: ./perlanet.log
retention-days: 3
- name: Update pages artifact
uses: actions/upload-pages-artifact@v1
with:
path: docs/
deploy:
needs: build
permissions:
pages: write
id-token: write
environment:
name: github-pages
url: ${\{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v1
The bits that I've added are the final step in the build
job ("Update pages artifact") and the new deploy
job. All of the code is largely copied from the documentation of the two actions I mentioned above.
Having made this changes to one of my planet sites, I switched the deployment method and forced the workflow to run. And was very happy to see it ran successfully and the new version of the site appeared at the live URL as soon as the deployment had changed.
This makes me happy as I feel I'm using the GitHub Pages deployment the way that they're supposed to be used. I've updated all of my planet sites to use this method, but I have several other sites that I'll need to get round to switching at some point.
As always when I find out something new about a GitHub feature, it leaves me with a couple of other suggestions for improvements:
Anyway, I thought I'd share what I had discovered today. Is anyone else generating web sites this way? How do you do it?
This is a story of one of those nice incidents where something starts off simple, then spirals out of control for a while but, in the end, everyone wins.
On Reddit, a few days ago, someone asked ‘Is there a “Planet Perl” with an RSS feed?’ and a few people replied, pointing out the existence of Planet Perl (which is the first Google result for “Planet Perl”). I’m obviously not marketing that site very well as every time I mention it, I get people (pleasantly) surprised that it exists.
On this occasion, it was Elvin Aslanov who seemed to discover my site for the first time. And, very soon afterwards, he started sending pull requests to add feeds to the site. As a result, we now have three more feeds that are being pulled into the site.
You might know that Planet Perl is driven by Perlanet. So adding new feeds is just a case of adding a few lines to a configuration file. And looking at the pull requests I got from Elvin, showed a potential problem in the way the configuration was laid out. Each feed has three lines of YAML configuration. There’s a title for the feed, a URL for a web page that displays the content of the feed and the URL for the feed itself. They’re called “title”, “web” and “url”. And it’s that last name that’s slightly problematic – it’s just not clear enough. Elvin got “web” and “url” muddled up in one of his PRs and, when I pointed that out to him, he suggested that renaming “url” to “feed” would make things much clearer.
I agreed, and the next day I hacked away for a while before releasing version 3.0.0 of Perlanet. In this version, the “url” key is renamed to “feed”. It still accepts the old name (so older config files will still work) but you’ll get a warning if you try to use a config name in the old config.
I didn’t stop there. Last year, I wrote a blog post about producing a docker image that already had Perlanet installed – so that it was quicker to rebuild my various planets every few hours. Since then I’ve been rebuilding that image every time I updated Perlanet. But it’s been rather a manual process. And because I’m old and decrepit, I can never remember the steps I go through to rebuild it, tag it correctly and push it to the Docker Hub. This means it always takes far longer than it’s supposed to. So this time, I wrote a script to do that for me. And because I now have the kind of mind set that sees GitHub Workflows everywhere I look, I wrote a Workflow definition that builds and publishes the image any time the Dockerfile changes. I guess the next step will be to write an action that automatically updates the Dockerfile (thereby triggering the rebuild) each time I release a new version of Perlanet.
But that’s a problem for another day. For now, I’m happy with the improvements I’ve made to Planet Perl, Perlanet and the Perlanet Docker infrastructure.
The post Improvements to Planet Perl and Perlanet appeared first on Perl Hacks.
This is a story of one of those nice incidents where something starts off simple, then spirals out of control for a while but, in the end, everyone wins.
On Reddit, a few days ago, someone asked ‘Is there a “Planet Perl” with an RSS feed?’ and a few people replied, pointing out the existence of Planet Perl (which is the first Google result for “Planet Perl”). I’m obviously not marketing that site very well as every time I mention it, I get people (pleasantly) surprised that it exists.
On this occasion, it was Elvin Aslanov who seemed to discover my site for the first time. And, very soon afterwards, he started sending pull requests to add feeds to the site. As a result, we now have three more feeds that are being pulled into the site.
You might know that Planet Perl is driven by Perlanet. So adding new feeds is just a case of adding a few lines to a configuration file. And looking at the pull requests I got from Elvin, showed a potential problem in the way the configuration was laid out. Each feed has three lines of YAML configuration. There’s a title for the feed, a URL for a web page that displays the content of the feed and the URL for the feed itself. They’re called “title”, “web” and “url”. And it’s that last name that’s slightly problematic – it’s just not clear enough. Elvin got “web” and “url” muddled up in one of his PRs and, when I pointed that out to him, he suggested that renaming “url” to “feed” would make things much clearer.
I agreed, and the next day I hacked away for a while before releasing version 3.0.0 of Perlanet. In this version, the “url” key is renamed to “feed”. It still accepts the old name (so older config files will still work) but you’ll get a warning if you try to use a config name in the old config.
I didn’t stop there. Last year, I wrote a blog post about producing a docker image that already had Perlanet installed – so that it was quicker to rebuild my various planets every few hours. Since then I’ve been rebuilding that image every time I updated Perlanet. But it’s been rather a manual process. And because I’m old and decrepit, I can never remember the steps I go through to rebuild it, tag it correctly and push it to the Docker Hub. This means it always takes far longer than it’s supposed to. So this time, I wrote a script to do that for me. And because I now have the kind of mind set that sees GitHub Workflows everywhere I look, I wrote a Workflow definition that builds and publishes the image any time the Dockerfile changes. I guess the next step will be to write an action that automatically updates the Dockerfile (thereby triggering the rebuild) each time I release a new version of Perlanet.
But that’s a problem for another day. For now, I’m happy with the improvements I’ve made to Planet Perl, Perlanet and the Perlanet Docker infrastructure.
The post Improvements to Planet Perl and Perlanet appeared first on Perl Hacks.
If you're using GitHub Workflows to automate bits of your development process (test runs, deployment, stuff like that) then you're almost certainly using GitHub Actions as well. Actions are pre-build chunks of functionality that you can use in your workflows and which save you having to write a load of code yourself. I've never, for example, written a workflow definition that doesn't use actions/checkout to checkout the current repo on the container that is running that workflow. Part of my workflow definition will always look like this:
steps:
- name: Check out code
uses: actions/checkout@v3
Or, at least, it will look a lot like that. The bit that might change is that v3
on the end there. That is, of course, the version of the action that I'm using. And that will change when the author of the action releases a new version. Well, strictly speaking, it will change when I notice that there's a new version and bother to update the workflow definition.
Recently, I noticed that two of the actions I use frequently (including the checkout action which I use everywhere) had updated their version numbers and I hadn't known about the change. It took a few hours of work to update the version numbers in all of my workflow definitions.
And life isn't supposed to be that much work.
But there's a solution. And I discovered it thanks to a discussion on Reddit.
If you're doing much work on GitHub (particularly in the Javascript/Node) area, then you'll have met Dependabot. It's a bot that scans GitHub repos for dependencies that are out of date and then (and here's the really clever bit!) it generates pull requests that update the repo to use the updated versions.
To be honest, I don't have many projects on GitHub that use the technologies that Dependabot targets by default. The few I have are web sites that use frameworks I've cloned from elsewhere - so I get the occasional PR that updates packages.json
and I just apply them and forget about it.
But it seems that Dependabot can do far more than that. You just need to configure it properly in your repo. And one of the things it can do is to scan for out of date actions being used in your workflow definitions. You just need a file called dependabot.yml
in your .github
directory and the contents should look like this:
# Set update schedule for GitHub Actions
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
# Check for updates to GitHub Actions every week
interval: "weekly"
Dependabot will then check your actions versions once a week and create PRs for any that are out of date. I know it works, because I added this to all of my repos this morning and it promptly created half a dozen PRs for repos where I had updated the versions but hadn't pushed the changes to GitHub. When I pushed the existing changes, Dependabot checked its PR against the new code, realised the PR was no longer needed and closed the PR. Which was nice :-)
It you're using GitHub Workflows (and I can't really think of any reason why you wouldn't be) then I recommend adding this file to your repos. Of course, GitHub has documentation about this feature.
Dependabot clearly has more uses than I thought it did. I'm going to have to investigate it further. I wonder if it can check CPAN dependencies.
Do you have any Dependabot tricks that I would find useful?
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.
I thought it might be fun to show how I spent an hour or so yesterday throwing together a simple web site that is hosted on GitHub Pages and is updated daily using GitHub Actions.
So many web sites start out with an itch to scratch, and this one is no different. In this case, it was about wanting to stay more informed.
Each day, the BBC News web site publishes a story that shows the front pages of all of the British newspapers. Although a lot of the British press isn't particularly trustworthy, I still think it's good to get an overview of what they're saying about the day's news. So finding and reading this story on the BBC site is one of my morning rituals.
But they don't make it easy to find the archive of those stories. So it's hard to read anything than the current day's front pages - and even that story tends to vanish from the BBC site by lunchtime. I decided I'd like a page that contains an archive to these stories.
The BBC don't publish an API for their web site, so we need to resort to screen-scraping. That, of course makes the process inherently fragile but it seems to be the best we can do at this stage.
It wasn't hard to create a program that pulls what I want from the web site using Web::Query (my tool of choice for scraping web sites).
Of course, having scraped the data, we need to store it somewhere. I decided to store it in a JSON document and worry about displaying it later.
So here's the code I wrote:
#!/usr/bin/perl
use strict;
use warnings;
use feature 'say';
use Time::Piece;
use Web::Query;
use JSON;
my $site = 'https://bbc.co.uk';
my $start = "$site/news/";
my $file = 'docs/papers.json';
my $js_p = JSON->new->pretty->canonical;
my $data;
if (-e $file) {
open my $fh, '<', $file or die "$!\n";
my $json = do { local $/; <$fh> };
$data = $js_p->decode($json);
}
my $start_len = @$data;
my $q = wq($start);
$q->find('a')
->each(sub {
my ($i, $elem) = @_;
return unless $elem->text =~ /^The Papers:/;
push @$data, {
date => localtime->strftime('%Y-%m-%d'),
text => ($elem->text =~ s/^The Papers:\s*//r),
link => $site . $elem->attr('href'),
};
});
if (@$data == $start_len) {
warn "No new article found\n";
} else {
open my $fh, '>', $file or die "$!\n";
print $fh $js_p->encode($data);
}
Nothing too complex there. We look for all of the <a>
tags in the page and ignore the ones that don't contain text starting with "The Papers:". We then extract the information we want (the text, the link and the date) and store that all in the JSON document.
At that point, I could run the code to create the JSON file. I then created the GitHub repository and turned on GitHub Pages for the repo. Once that was all working, I could browse to https://davorg.github.io/bbc_papers/papers.json to see the JSON.
We need to run this code every day. That's simple enough with GitHub Actions. We simply add a workflow definition file to the repo. The workflow looks like this:
name: Overnight processing
on:
schedule:
- cron: '0 9 * * *'
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Install cpanm
run: sudo apt update && sudo apt install cpanminus
- name: Install dependencies
run: sudo cpanm -n --installdeps .
- name: Add data
run: ./get_link
- name: Commit new page
run: |
GIT_STATUS=$(git status --porcelain)
echo $GIT_STATUS
git config user.name github-actions[bot]
git config user.email 41898282+github-actions[bot]@users.noreply.github.com
git add docs/
if [ "$GIT_STATUS" != "" ]; then git commit -m "Overnight job"; fi
if [ "$GIT_STATUS" != "" ]; then git push; fi
Again, this is all pretty much standard stuff. We run the workflow on a Ubuntu container. It's a three-phase process:
Note that the workflow is triggered in two ways:
workflow_dispatch
line does)Having got a daily build of the data, we need to create a web page to display it. I'm not a web designer, so this is going to be necessarily basic. I threw together a simple page using Bootstrap.
The next step was to grab the papers.json
document, parse it and then display it on the page. Now, I can wrangle Javascript pretty successfully most of the time. but I wanted to get this working as quickly as possible, so I asked ChatGPT for some help. It only took a few iterations for it to give me this code:
document.addEventListener("DOMContentLoaded", function(){
fetch("papers.json")
.then(response => response.json())
.then(data => {
const tableBody = document.querySelector("table tbody");
data.forEach(item => {
const row = document.createElement("tr");
const date = document.createElement("td");
date.textContent = item.date;
row.appendChild(date);
const textLink = document.createElement("td");
const a = document.createElement("a");
a.href = item.link;
a.textContent = item.text;
textLink.appendChild(a);
row.appendChild(textLink);
tableBody.appendChild(row);
});
});
});
It didn't work first time. But that's because I'm an idiot and didn't tell ChatGPT the name of my JSON document or how to correctly identify the <table>
element in the HTML. But once I'd corrected my errors it all worked perfectly.
So that's how I spent yesterday's lunch break. I can now see an archive of the BBC's stories about each day'd front pages by just going to:
Of course, just after I'd written it, I (once again) had a look to see if someone else had created something similar and found the BBC's page listing all of the stories. Ah well, I had fun putting my version together.
All of this code is available on GitHub.
That's an screenshot of my GitHub contributions for the last year. Almost 50,000 commits is a ridiculous number for one person to make in a year. Obviously I had some help.
The explanation is in my previous article GitHub Actions for semi-static web sites. In that article I explained how I was using GitHub Actions to rebuild a number of web sites every few hours. It doesn't take very many of those web sites before you start getting into dozens of automated commits every day. And it is, of course, those automated commits that are artificially inflating my commit count.
This has been mildly worrying me over the last year. I decided that I needed to do something about it. I needed to find a way to separate my real commits from these automated ones.
The previous article includes a sample GitHub Workflow file that I was using to run these sites. And it's easy to see what's causing the problem. There's a step that commits the newly-generated site and that step includes the following:
git config --global user.name 'Dave Cross'
git config --global user.email 'my email address'
That email address is associated with my GitHub account and, therefore, those commits are seen as being made by me.
A few weeks ago, I made the first step towards fixing this. I changed that configuration to this:
git config --global user.name 'Automated Workflow'
git config --global user.email "${GITHUB_ACTOR}@users.noreply.github.com"
We're using a more descriptive name and an email address that GitHub generates for us based on the username of the user who is running the workflow. This is better (as it won't assign commits to me if someone were to fork my repo and run the workflow) but it's still using an email address which GitHub has assigned to me and, therefore, the automated commits are still associated with me.
Yesterday I had another dig into this problem and I have found the solution. The new version I use it this:
git config user.name github-actions[bot]
git config user.email 41898282+github-actions[bot]@users.noreply.github.com
It turns out that there is a special GitHub user account that can be used to commit to your repos. This user is specifically there to solve the exact problem that I wanted to solve. It's just not particularly well-documented (or, if it is, it's not in the documentation that I've been looking at!)
You might notice that I've also removed the --global
setting from the commands. On reflection, it seemed pointless to make global changes on a Docker container that is going to cease to exist in a minute or so.
So that's what I now use on all of my workflows that regenerate web sites. It will mean that I make substantially fewer commits this year and I can no longer be accused of trying to game the system in order to artificially inflate my number of commits.
Oh, and as a bonus, the GitHub Actions Bot has its own Octocat avatar that now appears in the commits for my repos.
It's possible, of course, that I'm the last person in the world to realise this. But, hopefully, sharing the information will be useful to someone out there.
ChatGPT exposes an API, but there’s no CPAN module for taking advantage of that. Let’s put that right (with help from ChatGPT)…
Write a Perl CPAN module for connecting to a ChatGPT server
To create a Perl CPAN module for connecting to a ChatGPT server, you will need to have Perl and the necessary dependencies installed on your system.
To begin, create a new directory for your module and create a file called “ChatGPT.pm” with the following content:
package ChatGPT; use strict; use warnings; use Net::WebSocket::Client; use Net::WebSocket::Server; use HTTP::Async; sub new { my ($class, %params) = @_; my $self = { host => $params{host}, port => $params{port}, }; bless $self, $class; return $self; } sub send_prompt { my ($self, $prompt) = @_; my $http = HTTP::Async->new; my $client = Net::WebSocket::Client->new( url => "ws://$self->{host}:$self->{port}" ); $client->connect; $client->send_utf8($prompt); my $response = $client->recv; $client->disconnect; return $response; } 1;
To use this module in your Perl code, you can create a new ChatGPT object and call the send_prompt
method like this:
use ChatGPT; my $chatgpt = ChatGPT->new(host => 'localhost', port => 8080); my $response = $chatgpt->send_prompt('What is your name?'); print "Response: $response\n";
This will send the text prompt “What is your name?” to the ChatGPT server running on localhost at port 8080, and print the response to the console.
Note: This is just a basic example of how you can create a Perl CPAN module for connecting to a ChatGPT server. There are many other features and considerations that you may want to add to your module, such as error handling and customization options.
To make your module available on CPAN, you will need to follow the guidelines for creating and distributing CPAN modules, which can be found in the Perl documentation and online resources.
Use Moose to create the class
To use Moose to create the ChatGPT
class, you will need to have Moose installed on your system. You can install Moose by running the following command:
cpanm Moose
With Moose installed, you can modify the class like this:
package ChatGPT; use Moose; use Net::WebSocket::Client; use Net::WebSocket::Server; use HTTP::Async; has host => ( is => 'ro', isa => 'Str', required => 1, ); has port => ( is => 'ro', isa => 'Int', required => 1, ); sub send_prompt { my ($self, $prompt) = @_; my $http = HTTP::Async->new; my $client = Net::WebSocket::Client->new( url => "ws://$self->{host}:$self->{port}" ); $client->connect; $client->send_utf8($prompt); my $response = $client->recv; $client->disconnect; return $response; } 1;
In this version of the class, the host
and port
attributes are defined using Moose’s has
keyword. These attributes are required and must be specified when creating a new ChatGPT
object. The send_prompt
method is unchanged from the previous example.
To create a new ChatGPT
object, you can use the new
method provided by Moose like this:
use ChatGPT; my $chatgpt = ChatGPT->new(host => 'localhost', port => 8080); my $response = $chatgpt->send_prompt('What is your name?'); print "Response: $response\n";
This will create a new ChatGPT
object with the specified host
and port
attributes, and send the text prompt “What is your name?” to the ChatGPT server running on localhost at port 8080. The response will be printed to the console.
Note: This is just one way to use Moose to create the ChatGPT
class. There are many other features and customization options available in Moose that you may want to consider adding to your class, such as type constraints, default values, and methods.
Call the class WebService::ChatGPT
To rename the ChatGPT
class to WebService::ChatGPT
, you will need to update the package name at the top of the file and update the use
statements to refer to the new package name.
Here is how you can update the ChatGPT
class to use the new package name:
package WebService::ChatGPT; use Moose; use Net::WebSocket::Client; use Net::WebSocket::Server; use HTTP::Async; has host => ( is => 'ro', isa => 'Str', required => 1, ); has port => ( is => 'ro', isa => 'Int', required => 1, ); sub send_prompt { my ($self, $prompt) = @_; my $http = HTTP::Async->new; my $client = Net::WebSocket::Client->new( url => "ws://$self->{host}:$self->{port}" ); $client->connect; $client->send_utf8($prompt); my $response = $client->recv; $client->disconnect; return $response; } 1;
With these changes, the class is now called WebService::ChatGPT
and can be used like this:
use WebService::ChatGPT; my $chatgpt = WebService::ChatGPT->new(host => 'localhost', port => 8080); my $response = $chatgpt->send_prompt('What is your name?'); print "Response: $response\n";
This will create a new WebService::ChatGPT
object with the specified host
and port
attributes, and send the text prompt “What is your name?” to the ChatGPT server running on localhost at port 8080. The response will be printed to the console.,/p>
Note: This is just one way to rename the ChatGPT
class to WebService::ChatGPT
. You may also need to update any other references to the class name in your code and documentation, as well as update the module file name and directory structure to reflect the new package name.
Suggest some tests using the standard Perl testing framework
Here are some examples of tests that you could write for the WebService::ChatGPT
module using the standard Perl testing framework (Test::More):
use Test::More; use WebService::ChatGPT; # Test creating a new ChatGPT object my $chatgpt = WebService::ChatGPT->new(host => 'localhost', port => 8080); isa_ok($chatgpt, 'WebService::ChatGPT', 'Object is a ChatGPT'); # Test sending a prompt and receiving a response my $response = $chatgpt->send_prompt('What is your name?'); is($response, 'My name is ChatGPT.', 'Response is correct'); # Test sending an invalid prompt eval { $chatgpt->send_prompt('') }; like($@, qr/Invalid prompt/, 'Invalid prompt error is thrown'); done_testing();
The first test uses the isa_ok
function to check that the object created by the new
method is an instance of the WebService::ChatGPT
class.
The second test uses the is
function to compare the expected response to the actual response returned by the send_prompt
method.
The third test uses the eval
function to catch any exceptions thrown by the send_prompt
method when an invalid prompt is provided, and the like
function to check that the exception message matches the expected error message.
These tests can be run using the prove
command:
prove -l t/chatgpt.t
I haven’t uploaded it to CPAN yet. Do you think I should?
The post Writing a CPAN module that talks to ChatGPT appeared first on Perl Hacks.
Using artificial intelligence (AI) to generate blog posts can be bad for search engine optimization (SEO) for several reasons.
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.
I’ve been building Docker containers again. And I think you’ll find this one a little more useful than the Perlanet one I wrote about a couple of weeks ago.
Several years ago I got into Travis CI and set up lots of my GitHub repos so they automatically ran the tests each time I committed to the repo. Later on, I also worked out how to tie those test runs into Coveralls.io so I got pretty graphs of how my test coverage was looking. I gave a talk about what I had done.
But two things changed.
Firstly, Travis CI got too popular and, eventually, removed their free service. And, secondly, GitHub Actions was introduced. Over the last few years, I’ve set up many of my repos to use GitHub Actions for CI. But, basically because I’m lazy, I didn’t remove the Travis CI configuration from those repos.
But last week I decided the time was right to start work on that. And when I went to remove the .travis.yml I realised that something was missing from my GitHub Actions CI workflows — they were running the unit tests, but they weren’t reporting on test coverage. So it was time to fix that.
I needed to reimplement the logic that connected Travis CI to Coveralls.io in a GitHub workflow. That actually turned out to be pretty simple. There’s a CPAN module called Devel::Cover::Report::Coveralls which takes the output from Devel::Cover, converts it to the correct format and sends it to Coveralls.io. And, as a bonus, it has documentation showing how to implement that in a GitHub workflow.
So I hacked at my workflow definition file for one of my CPAN modules and within a few minutes I had it working.
Well, I say “a few minutes”, but it took over thirteen minutes to run. It turns out that Devel::Cover::Report::Coveralls is a pretty heavyweight module and needs to install a lot of other modules in order to do its work.
At this point, you can probably guess where this is going. And you’d be right.
I’ve created a Docker container that has Devel::Cover::Report::Coveralls already installed. And, obviously, it’s available for everyone to use from the Docker hub — davorg/perl-coveralls.
A couple of small adjustments to my GitHub workflow and the coverage job is now running on my new container — and takes 29 seconds instead of 13 minutes. So that’s a win.
The relevant section of my workflow file is here:
coverage:
runs-on: ubuntu-latest
container: davorg/perl-coveralls:latest
name: Test coverage
steps:
- uses: actions/checkout@v3
- name: Install modules
run: cpanm -n --installdeps .
- name: Coverage
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: cover -test -report Coveralls
And it’s producing nice graphs on Coveralls.io like the one above.
Let me know if you find it useful.
Originally published at Perl Hacks.
I’ve been building Docker containers again. And I think you’ll find this one a little more useful than the Perlanet one I wrote about a couple of weeks ago.
Several years ago I got into Travis CI and set up lots of my GitHub repos so they automatically ran the tests each time I committed to the repo. Later on, I also worked out how to tie those test runs into Coveralls.io so I got pretty graphs of how my test coverage was looking. I gave a talk about what I had done.
But two things changed.
Firstly, Travis CI got too popular and, eventually, removed their free service. And, secondly, GitHub Actions was introduced. Over the last few years, I’ve set up many of my repos to use GitHub Actions for CI. But, basically because I’m lazy, I didn’t remove the Travis CI configuration from those repos.
But last week I decided the time was right to start work on that. And when I went to remove the .travis.yml I realised that something was missing from my GitHub Actions CI workflows – they were running the unit tests, but they weren’t reporting on test coverage. So it was time to fix that.
I needed to reimplement the logic that connected Travis CI to Coveralls.io in a GitHub workflow. That actually turned out to be pretty simple. There’s a CPAN module called Devel::Cover::Report::Coveralls which takes the output from Devel::Cover, converts it to the correct format and sends it to Coveralls.io. And, as a bonus, it has documentation showing how to implement that in a GitHub workflow.
So I hacked at my workflow definition file for one of my CPAN modules and within a few minutes I had it working.
Well, I say “a few minutes”, but it took over thirteen minutes to run. It turns out that Devel::Cover::Report::Coveralls is a pretty heavyweight module and needs to install a lot of other modules in order to do its work.
At this point, you can probably guess where this is going. And you’d be right.
I’ve created a Docker container that has Devel::Cover::Report::Coveralls already installed. And, obviously, it’s available for everyone to use from the Docker hub – davorg/perl-coveralls.
A couple of small adjustments to my GitHub workflow and the coverage job is now running on my new container – and takes 29 seconds instead of 13 minutes. So that’s a win.
The relevant section of my workflow file is here:
coverage: runs-on: ubuntu-latest container: davorg/perl-coveralls:latest name: Test coverage steps: - uses: actions/checkout@v3 - name: Install modules run: cpanm -n --installdeps . - name: Coverage env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: cover -test -report Coveralls
And it’s producing nice graphs on Coveralls.io like the one above.
Let me know if you find it useful.
The post Containers for Coverage appeared first on Perl Hacks.
It’s October. And that means that Hacktoberfest has started. If you can get four pull requests accepted on other people’s code repositories during October then you can win a t-shirt.
In many ways, I think it’s a great idea. It encourages people to get involved in open source software. But in other ways, it can be a bit of a pain in the arse. Some people go crazy for a free t-shirt and that means you’ll almost certainly get several pull requests that aren’t really of the quality you’d hope for.
I have a particular problem that probably isn’t very common. I’ve talked before about the “semi-static” sites I run on GitHub Pages. There’s some data in a GitHub Repo and every couple of hours the system wakes up and runs some code which generates a few HTML pages and commits those HTML pages into the repo’s “/docs” directory. And — hey presto! — there’s a new version of your web site.
A good example is Planet Perl. The data is a YAML file which mostly consists of a list of web feeds. Every couple of hours we run perlanet to pull in those web feeds and build a new version of the web site containing the latest articles about Perl.
Can you see what the problem is?
The problem is that the most obvious file in the repo is the “index.html” which is the web site. So when people find that repo and want to make a small change to the web site they’ll change that “index.html” file. But that file is generated. Every few hours, any changes to that file are overwritten as a new version is created. You actually want to change “index.tt”. But that uses Template Toolkit syntax, so it’s easy enough to see why people with no Perl knowledge might want to avoid editing that.
The README file for the project explains which files you might want to change in order to make different types of changes. But people don’t read that. Or, if they do read it, they ignore the bits that they don’t like.
So I get pull requests that I have to reject because they change the wrong files.
Last year I got enough of these problematic pull requests that I decided to automate a solution. And it’s this pretty simple GitHub Workflow. It runs whenever my repo receives a pull request and looks at the files that have been changed. If that list of files includes “docs/index.html” then the PR is automatically closed with a polite message explaining what they’ve done wrong.
This makes my life easier. It’s possible it might make your life easier too.
Originally published at Perl Hacks.
It’s October. And that means that Hacktoberfest has started. If you can get four pull requests accepted on other people’s code repositories during October then you can win a t-shirt.
In many ways, I think it’s a great idea. It encourages people to get involved in open source software. But in other ways, it can be a bit of a pain in the arse. Some people go crazy for a free t-shirt and that means you’ll almost certainly get several pull requests that aren’t really of the quality you’d hope for.
I have a particular problem that probably isn’t very common. I’ve talked before about the “semi-static” sites I run on GitHub Pages. There’s some data in a GitHub Repo and every couple of hours the system wakes up and runs some code which generates a few HTML pages and commits those HTML pages into the repo’s “/docs” directory. And – hey presto! – there’s a new version of your web site.
A good example is Planet Perl. The data is a YAML file which mostly consists of a list of web feeds. Every couple of hours we run perlanet to pull in those web feeds and build a new version of the web site containing the latest articles about Perl.
Can you see what the problem is?
The problem is that the most obvious file in the repo is the “index.html” which is the web site. So when people find that repo and want to make a small change to the web site they’ll change that “index.html” file. But that file is generated. Every few hours, any changes to that file are overwritten as a new version is created. You actually want to change “index.tt”. But that uses Template Toolkit syntax, so it’s easy enough to see why people with no Perl knowledge might want to avoid editing that.
The README file for the project explains which files you might want to change in order to make different types of changes. But people don’t read that. Or, if they do read it, they ignore the bits that they don’t like.
So I get pull requests that I have to reject because they change the wrong files.
Last year I got enough of these problematic pull requests that I decided to automate a solution. And it’s this pretty simple GitHub Workflow. It runs whenever my repo receives a pull request and looks at the files that have been changed. If that list of files includes “docs/index.html” then the PR is automatically closed with a polite message explaining what they’ve done wrong.
This makes my life easier. It’s possible it might make your life easier too.
The post Not that PR, thanks appeared first on Perl Hacks.
I’m a dinosaur who still believes that web feeds are a pretty neat idea. I wrote and maintain perlanet (a Perl program for aggregating web feeds into a new feed — and building a web site based on that new feed) and I use it to build a few sites on topics I’m interested in.
Last year, I worked out a way to use GitHub Actions to rebuild these sites automatically every few hours — thereby enabling me to host the sites on GitHub Pages (I still think it’s a useful technique, but I sometimes worry slightly about the large number of commits those repos have — someone at GitHub must surely notice one day!)
Yesterday, I was doing some light maintenance on one of those sites when I realised that each rebuild of these sites was taking a significant time (by which I mean four or five minutes) and started wondering if there was a way to speed them up and use less of GitHub’s resources. The problem is that Perlanet is a pretty hefty module and each rebuild was installing that module (and, therefore, dozens of other modules) on a pristine Ubuntu container.
When you say it like that, the solution is obvious.
You don’t need to run your GitHub Actions on the standard containers that GitHub supplies. You can run them on any container that’s available from any public container hosting service. So the solution was to build a Perlanet container and run the jobs using that instead. So that’s how I spent an hour or so yesterday.
Here’s the Dockerfile I ended up with:
FROM perl:latest
RUN apt-get update && \
apt-get -y upgrade && \
apt-get install -y build-essential && \
apt-get install -y cpanminus libtidy-dev libxml++2.6-dev libhtml-tidy-perl && \
cpanm --notest Test::Exception && \
cpanm --notest Perlanet && \
cpanm --notest LWP::Protocol::https
It’s (obviously) available on GitHub in case anyone wants to improve on my rather ropey knowledge of Docker.
I explicitly install Test::Exception because HTML::Tidy (one of Perlanet’s pre-requisites) needs it and I can’t work out why the standard installation procedure isn’t installing it. And while, LWP::Protocol::https is, strictly speaking, required by Perlanet, you wouldn’t get very far on the modern web if you only accessed web feeds that are available over HTTP.
A little bit of Docker Hub set-up and the container is available for everyone to use (and rebuilt automatically whenever I commit to the repo).
It was then just a case of changing my GitHub Actions to use my container. Here’s an example of one of the commits that did that.
I realise I’m pretty late to the party here, but I think this is a useful pattern. If you have a Perl library (or, indeed, any other software) that exists to provide a service to users then it’s a great idea to provide a containerised version of that software.
And I’m happy to report that my site rebuilds have gone from 4–5 minutes to about 45 seconds.
Originally published at Perl Hacks.
I’m a dinosaur who still believes that web feeds are a pretty neat idea. I wrote and maintain perlanet (a Perl program for aggregating web feeds into a new feed – and building a web site based on that new feed) and I use it to build a few sites on topics I’m interested in.
Last year, I worked out a way to use GitHub Actions to rebuild these sites automatically every few hours – thereby enabling me to host the sites on GitHub Pages (I still think it’s a useful technique, but I sometimes worry slightly about the large number of commits those repos have – someone at GitHub must surely notice one day!)
Yesterday, I was doing some light maintenance on one of those sites when I realised that each rebuild of these sites was taking a significant time (by which I mean four or five minutes) and started wondering if there was a way to speed them up and use less of GitHub’s resources. The problem is that Perlanet is a pretty hefty module and each rebuild was installing that module (and, therefore, dozens of other modules) on a pristine Ubuntu container.
When you say it like that, the solution is obvious.
You don’t need to run your GitHub Actions on the standard containers that GitHub supplies. You can run them on any container that’s available from any public container hosting service. So the solution was to build a Perlanet container and run the jobs using that instead. So that’s how I spent an hour or so yesterday.
Here’s the Dockerfile I ended up with:
FROM perl:latest RUN apt-get update && \ apt-get -y upgrade && \ apt-get install -y build-essential && \ apt-get install -y cpanminus libtidy-dev libxml++2.6-dev libhtml-tidy-perl && \ cpanm --notest Test::Exception && \ cpanm --notest Perlanet && \ cpanm --notest LWP::Protocol::https
It’s (obviously) available on GitHub in case anyone wants to improve on my rather ropey knowledge of Docker.
I explicitly install Test::Exception because HTML::Tidy (one of Perlanet’s pre-requisites) needs it and I can’t work out why the standard installation procedure isn’t installing it. And while, LWP::Protocol::https is, strictly speaking, not required by Perlanet, you wouldn’t get very far on the modern web if you only accessed web feeds that are available over HTTP.
A little bit of Docker Hub set-up and the container is available for everyone to use (and rebuilt automatically whenever I commit to the repo).
It was then just a case of changing my GitHub Actions to use my container. Here’s an example of one of the commits that did that.
I realise I’m pretty late to the party here, but I think this is a useful pattern. If you have a Perl library (or, indeed, any other software) that exists to provide a service to users then it’s a great idea to provide a containerised version of that software.
And I’m happy to report that my site rebuilds have gone from 4-5 minutes to about 45 seconds.
The post Building a Perlanet Container appeared first on Perl Hacks.
A little later than usual, here’s my review of the gigs I saw last year.
In 2020, I saw four gigs. In 2021, I almost doubled that to seven. Obviously, we spent a lot of the year with most music venues closed, so those few gigs I saw were all in the second half of the year. Usually, I’d list my top ten gigs. This year (as last year) I’ll be listing them all. So here they are in chronological order.
And that was 2021. What will happen in 2022? Well, I have tickets for a dozen or so shows but who knows how many of them I’ll actually see? I’ve already had emails postponing the Wolf Alice and Peter Hook shows I was going to see this month. I guess I’ll just have to wait and see how the rest of the year pans out.
Originally published at https://blog.dave.org.uk on January 9, 2022.
‘Okay Google. Where is Antarctica?”
Children can now get answers to all their questions using smart speakers and digital voice assistants.
A few years ago, children would run to their parents or grandparents to answer their questions. But with the ascendence of voice assistants to the mainstream in recent years, many children rely more on technology than humans.
Is this a good idea?
How does it impact the children?
When children interact with people, it helps them be more thoughtful, creative, and imaginative.
When they use artificial intelligence instead, several issues come into the foreground. These include access to age-inappropriate content and increasing the possibility of being rude or unpleasant, affecting how they treat others.
As mentioned, technology has both pros and cons. There are benefits to children using these devices, including improving diction, communication, social skills, and gaining information without bothering their parents.
Many families find that smart speakers like Amazon Echo and Google Home are useful. They use them for several functions, ranging from answering questions to setting the thermostat. Research shows that up to nine out of ten children between the ages of four and eleven in the US are regularly using smart speakers — often without parental guidance and control. So, what is the best approach for a parent to take?
Children up to seven years old can find it challenging to differentiate between humans and devices, and this can lead to one of the biggest dangers. If the device fulfils their requests through rude behaviour, children may behave similarly to other humans.
Most parents consider it essential that smart devices should encourage polite conversations as a part of nurturing good habits in children. The Campaign for a Commercial-Free Childhood or CCFA is a US coalition of concerned parents, healthcare professionals, and educators. Recently, CCFA protested against Amazon Echo Dot Kids Edition, stating that it may affect children’s wellbeing. Because of this, they requested parents avoid buying Amazon Echo.
However, in reality, these smart devices have improved a lot and focus on encouraging polite conversations with children. It is all about how parents use and present these devices to their children, as these factors can influence them a lot.
But in simple terms, parents wish these devices to encourage politeness in their children. At the same time, they want their kids to understand the difference between artificial intelligence and humans while using these technological innovations.
Many parents have seen their children behave rudely to smart speakers. Several parents have expressed their concerns through social media, blog posts and forums like Mumsnet. They fear these behaviours can impact their kids when they grow up.
A report published in Child Wise reached the conclusion that children who behave rudely to smart devices might be aggressive while they grow up, especially while dealing with other humans. It is, therefore, preferable if children use polite words while interacting with both humans and smart devices.
With interventions and rising concerns addressed by parents and health professionals, some tech companies have brought changes to virtual assistants and smart speakers.
The parental control features available in Alexa focus on training kids to be more polite. Amazon brands it as Magic Word, where the focus is on bringing positive enforcement. However, there is no penalty if children don’t speak politely. Available on Amazon Echo, this tool has added features like setting bedtimes, switching off devices, and blocking songs with explicit lyrics.
When it comes to Google Home, it has brought in a new feature called Pretty Please. Here, Google will perform an action only when children use, please. For instance, “Okay, Google. Please set the timer for 15 minutes.”
You can enable this feature through the Google Family Link, where you can find the settings for Home and Assistant. You can set these new standards for devices of your preference. Also, once you use it and figure things out, there will be no more issues in setting it up again.
These tools and their approaches are highly beneficial for kids and parents. As of now, these devices only offer basic features and limited replies. But with time, there could be technological changes that encourage children to have much more efficient and polite interactions.
It was thinking about issues like this which led me to write my first children’s book — George and the Smart Home. In the book, George is a young boy who has problems getting the smart speakers in his house to do what he wants until he learns to be polite to them.
It is available now, as a paperback and a Kindle book, from Amazon.
Buy it from: AU / BR / CA / DE / ES / FR / IN / IT / JP / MX / NL / UK / US
The post Should Children be Polite While Using Smart Speakers? appeared first on Davblog.
A little later than usual, here’s my review of the gigs I saw last year.
In 2020, I saw four gigs. In 2021, I almost doubled that to seven. Obviously, we spent a lot of the year with most music venues closed, so those few gigs I saw were all in the second half of the year. Usually, I’d list my top ten gigs. This year (as last year) I’ll be listing them all. So here they are in chronological order.
And that was 2021. What will happen in 2022? Well, I have tickets for a dozen or shows but who knows how many of them I’ll actually see? I’ve already had emails postponing the Wolf Alice and Peter Hook shows I was going to see this month. I guess I’ll just have to wait and see how the rest of the year pans out.
The post 2021 in Gigs appeared first on Davblog.
Doctor Who has a new showrunner. But he’s actually an old showrunner. Is that a good idea?
Since the news broke yesterday, Doctor Who fan forums have been discussing nothing but the fact that Russell T Davies is returning as showrunner after Chris Chibnall’s regeneration special is broadcast next year. Most fans seem to be very excited by this prospect; I’m not so sure.
Before I start, I should point out that I’ve been a big fan of Russell T Davies since long before he brought Doctor Who back to our screens in 2005. I’ll always be grateful for the work he did to bring the show back and I believe that he’s responsible for some great moments in Doctor Who history.
But I’m not sure I want to see him back as the showrunner. Let me explain why I’m so out of step with most of the show’s fans.
Firstly, although I’m grateful to him for bringing the show back, he’s not my favourite showrunner. Obviously, any Doctor Who is better than no Doctor Who but there was a lot of stuff in Davies’ first run that I didn’t like. For example, He was the person who first introduced us to companions’ families, which brought a slight soap opera feel to some of the episodes. Also, I thought that he often wrote himself into a bit of a corner. This was most apparent in the end of season two-parters. There were many occasions when the first part set up a fantastic premise only to be let down by a finale that just couldn’t live up to the promise. The Stolen Earth was great; Journey’s End was terrible. Then there’s The End of Time. Again, it started off well but had verged well into the ridiculous by the end of the first part. And don’t get me started on the self-indulgent, mawkish nonsense that made up the last twenty minutes of that story — leading to the Tenth Doctor’s regeneration.
I admit, however, that my opinions on Davies’ writing are purely personal. And, because of the massive rise in popularity of the show during his tenure, many viewers see his approach as the gold standard for how the show should work. My other points are, I hope, less opinion-based.
Secondly, Doctor Who is a show that should always be moving forward. In the classic era of the show, previous Doctors and companions would reappear very rarely. When someone left the show, you knew the chances of seeing them again were very slim. When an executive producer left (we didn’t call them showrunners back then) you knew that the show would change in new and experimental ways. Sometimes the changes didn’t work; most of the time they did. Change is fundamental to the show. It’s how the show has kept going for (most of) sixty years.
The newer sections of the audience don’t seem to realise that. I constantly hear fans wanting things to go back to how things were. As soon as Rose was written out at the end of series two, there were calls for her to come back. And while series four has some pretty good stuff in it, I think that bringing Rose back was pandering to the fanbase in an unhealthy way. We now have a situation where fans expect every character who has been written out of the show to be brought back at their whim. There aren’t very many weeks that pass without me seeing someone in a Facebook group suggesting some convoluted way that David Tennant could be brought back to be the Doctor again.
The show must always move forward. It must always change. I believe that RTD knows that, so I hope that his second era in charge will be sufficiently different to his first. But I worry that fans will start asking for Tennant back as the Doctor with Billie Piper by his side. For some fans, that seems to be the only version of the show they will be happy with.
Finally, I worry about what RTD’s reappointment means for the future of the show. When Chibnall’s departure was announced, all of the news stories claimed that he and Whittaker had a “three and out agreement” between themselves and that he only ever planned to do three years running the show. That’s rather at odds with the talk of him having a five-year plan for the show when he was appointed to the role. I realise that he will have done five years in the post by the time he goes, but he will have made three seasons and a handful of specials — so I’m not sure that counts.
No, I think it’s clear that Chibnall has been hounded out of the role by that toxic sector of the fanbase that refuses to give his work on the show a decent chance. And, given that Moffat also put up with a lot of abuse from certain fans, I begin to wonder how easy it is to find someone to take over the job. Chibnall’s departure was announced at the end of July and the BBC would certainly have known about it for some time before that. But they have failed to find someone new and exciting to take over the job and I wonder if it has become a bit of a poison chalice. People want to do the job because, hey, it’s running Doctor Who! But, on the other hand, if you don’t please the fanbase (and no-one can please all of the fanbase) then you’ll be vilified online and hounded off social media. Add to that the fact that both Davies and Moffat cited insane working schedules as part of their reason for leaving and, suddenly, the job doesn’t look quite as tempting.
I have no inside information here at all, but I wonder if the reappointment of RTD was an act of desperation on the part of the BBC. We know that Chibnall is steering the show up to and including a BBC centenary special that will be broadcast in 2022. But the show’s 60th anniversary is the year after that and without a showrunner, you can’t cast a new Doctor and without a new Doctor in place pretty soon, the 60th-anniversary celebrations would seem to be in danger.
The news of the reappointment has all been very celebratory, of course, but I wonder if that’s actually the case. I wonder if the BBC’s approach to RTD was more like this:
“So, that show you resurrected back in 2005. Well, we can’t find anyone to take over as showrunner, and unless we get things moving pretty quickly we’re not going to have a 60th anniversary worth speaking off. Seriously, we’re thinking of just cancelling it… unless you can suggest something that we could do…”
This, of course, leaves RTD thinking that the only way to save his baby is to step in himself. Maybe he’s stepped in as a stop-gap until the BBC finds someone else to take over. The announcement says he’s signed on for the 60th special and following series. But that’s a bit vague (because the English language doesn’t have a plural for “series”!) so who knows how long he’ll hang around for. Time will tell, I guess.
But, if you’re one of those fans who think it’s big or clever to be unrelentingly negative about the showrunner on social media, please stop and consider whether you’re part of a problem that could end up with no-one wanting the job and the show being cancelled.
All-in-all, I wish that the BBC hadn’t done this. I would have far preferred to see the show moving forward. But if, as I suspect, the alternative was no new Doctor Who for the foreseeable future, then obviously this is a good plan. I’m keen to see what Davies has in store.
But first I’m really excited to see what Chibnall has in store for his final series and the subsequent specials. If series 13 improves on series 12 to the extent that series 12 improved on series 11, then it’s going to be great.
The post The Return of RTD appeared first on Davblog.