@davorg davorg pushed to master in davorg/uptime · March 5, 2024 00:21
1 commit to master
  • @upptime-bot da3a4f5
    🍱 Update graphs [skip ci]
@davorg davorg pushed to master in davorg/uptime · March 5, 2024 00:06
2 commits to master
  • @upptime-bot f9ae0b2
    🗃️ Update status summary [skip ci] [upptime]
  • @upptime-bot dfcb5e3
    📝 Update summary in README [skip ci] [upptime]
@davorg davorg pushed to master in davorg/uptime · March 4, 2024 23:01
2 commits to master
@davorg davorg pushed to master in davorg/uptime · March 4, 2024 00:22
1 commit to master
  • @upptime-bot c413f2b
    🍱 Update graphs [skip ci]
@davorg davorg pushed to master in davorg/uptime · March 4, 2024 00:06
2 commits to master
  • @upptime-bot 69fc776
    🗃️ Update status summary [skip ci] [upptime]
  • @upptime-bot ffe8da5
    📝 Update summary in README [skip ci] [upptime]

The future is already here – it’s just not very evenly distributed
– William Gibson

The quotation above was used by Tim O’Reilly a lot around the time that Web 2.0 got going. Over recent months, I’ve had a few experiences that have made it clear to me that even the present isn’t particularly evenly distributed either. It’s always easy to find people still using technologies that we would consider archaic (and not in a rustic or hipster way).

We’ve known for twenty years that CGI is a bad idea. It’s almost ten years since CGI.pm was removed from Perl core. Surely, all of us are using something modern for web development these days.

Well, apparently not. CGI is alive and well and living on the fringes of the Perl community. I’ve come across it being used in some quite surprising places over the last year or so. I’m going to obfuscate some details in the following descriptions to, hopefully, prevent you (or, worse, the people involved) from recognising the companies involved.

  • I did some work for a spectacularly big (and I mean huge) consultancy company. They wanted to decommission some old servers – which involved moving some Perl CGI programs that no-one had looked at for about fifteen years. These programs were, of course, running vital bits of the business. Anyone who had ever edited them had left the company at least ten years earlier. They wanted to do it as quickly as possible and change as little of the code as possible. The code was incompatible with even vaguely modern versions of Perl, so much of the work involved installing old versions of Perl (along with Apache and even mod_perl) on new hardware running up-to-date operating systems.
  • I picked up two or three freelancing gigs on Fiverr. And for the first time in years, I found myself working with low-end, rented, shared servers. At least one of them was one of those situations where you don’t have root access and are extremely hampered by the lack of software.
  • A couple of weeks ago, I got an email to my SourceForge email address asking for help with nms Formmail (some readers may be young enough that they haven’t heard of Matt’s Script Archive or the London Perl Mongers rewrite of those programs into what we called “modern Perl” twenty years ago). The email asked if our Formmail supported anti-spam measures like SPF, DMARC and DKIM. It was nostalgic to recall how different the web was back in the days when every web site had a mail form, a guest book and a hit counter. I see that SourceForge have removed the nms web site. I doubt I’ll ever get the time to work out what happened to it.  [Update: I was wrong about that. It’s been so long since I’ve looked at the nms project that I had forgotten the URL. The web site is still there in all its early-2000s car-crash web design glory.]
  • The following day I saw a question on Stack Overflow about a “classic mailing script”. And, yes, it was nms Formmail again. This user had moved their web site to a new server and it had stopped working. We never got the error log content that we asked them for, but the user confirmed my suspicion that the new web server had a newer version of Perl – one that was released after CGI.pm was removed. The nms project had (for obvious reasons) made heavy use of the module and its removal from core Perl has rendered the nms programs unusable on cheap servers where the sysadmin has no knowledge of or interest in installing any Perl modules that aren’t part of the standard package. Sadly, this means that Matt Wright’s original versions (that were never updated to use CGI.pm) still work in environments where the nms versions are useless.

None of this should be taken as an argument that the nms project was wrong to use CGI.pm or that the Perl 5 Porters were wrong to remove it from the Perl standard library. I still support both decisions. I just found it a bit jarring to be reminded that while we’re all using PSGI or Mojolicious to write microservices in Perl that serve REST APIs that are developed and deployed in Docker containers, there are still people out there who are struggling to FTP code that was written in 1997 onto low-end shared hosting.

I think this state of affairs has two causes. Firstly (like the first client I mentioned above) some systems were set up when CGI was still in common use – and things haven’t changed since. These people get a sudden shock when they are forced to move to a more modern server for some reason. And then there are people like my Fiverr clients who install Perl CGI programs because that’s what they have always done and they don’t know that there is an alternative approach. Part of the problem there is, presumably, that Perl has meant badly-written CGI programs for a large proportion of the web’s existence and means anyone searching for information on this subject is likely to find pages and pages of advice telling them how to install CGI programs before they discover anything about PSGI or Docker. And I think there might be a solution to that problem (or, at least, a way to nudge the web in the right direction).

Over last weekend I was cataloguing subdomains (I know how to have fun!) and I found a web site that I had forgotten about. I had obviously been contemplating a very similar situation back in 2016.

The site is called Perl Web Advice. The intention was (is?) that it would be a definitive source of good advice about how to develop and deploy web applications written in Perl. I had only made tiny inroads into the task before something else apparently seemed more fun and the project was abandoned.

But there’s the start of a framework for the site. And, this week, I’ve given it a GitHub Actions workflow so it gets republished automatically whenever changes are pushed to the repo. I’ve even set up a Dockerfile to make it easy to use the static site generator that I’ve used for it. So perhaps the idea has merit. Once there’s a bit more useful content there I could see if I can remember any of my SEO knowledge and get it appearing in results where people are looking for advice on this topic.

I would, of course, be happy to consider contributions from other people. What do you think? Would you like to help me save people from the hell of CGI deployments?

The post The present isn’t evenly distributed either appeared first on Perl Hacks.

The future is already here – it’s just not very evenly distributed

– William Gibson

The quotation above was used by Tim O’Reilly a lot around the time that Web 2.0 got going. Over recent months, I’ve had a few experiences that have made it clear to me that even the present isn’t particularly evenly distributed either. It’s always easy to find people still using technologies that we would consider archaic (and not in a rustic or hipster way).

We’ve known for twenty years that CGI is a bad idea. It’s almost ten years since CGI.pm was removed from Perl core. Surely, all of us are using something modern for web development these days.

Well, apparently not. CGI is alive and well and living on the fringes of the Perl community. I’ve come across it being used in some quite surprising places over the last year or so. I’m going to obfuscate some details in the following descriptions to, hopefully, prevent you (or, worse, the people involved) from recognising the companies involved.

  • I did some work for a spectacularly big (and I mean huge ) consultancy company. They wanted to decommission some old servers – which involved moving some Perl CGI programs that no-one had looked at for about fifteen years. These programs were, of course, running vital bits of the business. Anyone who had ever edited them had left the company at least ten years earlier. They wanted to do it as quickly as possible and change as little of the code as possible. The code was incompatible with even vaguely modern versions of Perl, so much of the work involved installing old versions of Perl (along with Apache and even mod_perl) on new hardware running up-to-date operating systems.
  • I picked up two or three freelancing gigs on Fiverr. And for the first time in years, I found myself working with low-end, rented, shared servers. At least one of them was one of those situations where you don’t have root access and are extremely hampered by the lack of software.
  • A couple of weeks ago, I got an email to my SourceForge email address asking for help with nms Formmail (some readers may be young enough that they haven’t heard of Matt’s Script Archive or the London Perl Mongers rewrite of those programs into what we called “modern Perl” twenty years ago). The email asked if our Formmail supported anti-spam measures like SPF, DMARC and DKIM. It was nostalgic to recall how different the web was back in the days when every web site had a mail form, a guest book and a hit counter. I see that SourceForge have removed the nms web site. I doubt I’ll ever get the time to work out what happened to it. [Update: I was wrong about that. It's been so long since I've looked at the nms project that I had forgotten the URL. The web site is still there in all its early-2000s car-crash web design glory.]
  • The following day I saw a question on Stack Overflow about a “classic mailing script”. And, yes, it was nms Formmail again. This user had moved their web site to a new server and it had stopped working. We never got the error log content that we asked them for, but the user confirmed my suspicion that the new web server had a newer version of Perl – one that was released after CGI.pm was removed. The nms project had (for obvious reasons) made heavy use of the module and its removal from core Perl has rendered the nms programs unusable on cheap servers where the sysadmin has no knowledge of or interest in installing any Perl modules that aren’t part of the standard package. Sadly, this means that Matt Wright’s original versions (that were never updated to use CGI.pm) still work in environments where the nms versions are useless.

None of this should be taken as an argument that the nms project was wrong to use CGI.pm or that the Perl 5 Porters were wrong to remove it from the Perl standard library. I still support both decisions. I just found it a bit jarring to be reminded that while we’re all using PSGI or Mojolicious to write microservices in Perl that serve REST APIs that are developed and deployed in Docker containers, there are still people out there who are struggling to FTP code that was written in 1997 onto low-end shared hosting.

I think this state of affairs has two causes. Firstly (like the first client I mentioned above) some systems were set up when CGI was still in common use – and things haven’t changed since. These people get a sudden shock when they are forced to move to a more modern server for some reason. And then there are people like my Fiverr clients who install Perl CGI programs because that’s what they have always done and they don’t know that there is an alternative approach. Part of the problem there is, presumably, that Perl has meant badly-written CGI programs for a large proportion of the web’s existence and means anyone searching for information on this subject is likely to find pages and pages of advice telling them how to install CGI programs before they discover anything about PSGI or Docker. And I think there might be a solution to that problem (or, at least, a way to nudge the web in the right direction).

Over last weekend I was cataloguing subdomains (I know how to have fun!) and I found a web site that I had forgotten about. I had obviously been contemplating a very similar situation back in 2016.

The site is called Perl Web Advice. The intention was (is?) that it would be a definitive source of good advice about how to develop and deploy web applications written in Perl. I had only made tiny inroads into the task before something else apparently seemed more fun and the project was abandoned.

But there’s the start of a framework for the site. And, this week, I’ve given it a GitHub Actions workflow so it gets republished automatically whenever changes are pushed to the repo. I’ve even set up a Dockerfile to make it easy to use the static site generator that I’ve used for it. So perhaps the idea has merit. Once there’s a bit more useful content there I could see if I can remember any of my SEO knowledge and get it appearing in results where people are looking for advice on this topic.

I would, of course, be happy to consider contributions from other people. What do you think? Would you like to help me save people from the hell of CGI deployments?

The post The present isn’t evenly distributed either appeared first on Perl Hacks.

You might remember that I’ve been taking an interest in GitHub Actions for the last year or so (I even wrote a book on the subject). And at the Perl Conference in Toronto last summer I gave a talk called “GitHub Actions for Perl Development” (here are the slides and the video).

During that talk, I mentioned a project I was working on to produce a set of reusable workflows that would make it easier for anyone to start using GitHub Actions in their Perl development. Although (as I said in the talk) things were moving pretty quickly on the project at the time, once I got back to London, several other things became more important and work on this project pretty much stalled. But over the last couple of weeks, I’ve returned to this project and I’ve finally got some of the workflows into a state where I’ve been using them successfully in my GitHub repos and I think they’re now ready for you to start using them in yours. There are three workflows that I’d like you to try:

  • cpan_test: This runs your test suite and reports on the results
  • cpan_coverage: This calculates the coverage of your test suite and reports the results. It also uploads the results to coveralls.io
  • cpan_perlcritic: This runs perlcritic over your code and reports on the results

And using these workflows in your GitHub repos is as simple as creating a new file in the .github/workflows directory which contains something like this:

name: CI

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]
  workflow_dispatch:

jobs:
  build:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-test.yml@main

  coverage:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-coverage.yml@main

  perlcritic:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-perlcritic.yml@main

There are a couple of parameters you can use to change the behaviour of these workflows. In the Toronto talk, I introduced the idea of a matrix of tests, where you can test against three operating systems (Linux, MacOS and Windows) and a list of Perl versions. By default, the cpan-test workflow uses all three operating systems and all production versions of Perl from 5.24 to 5.38. But you can change that by using the perl_version and os parameters. For example, if you only wanted to test on Ubuntu, using the most recent two versions of Perl, you could use this:

build:
  uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-test.yml@main
  with:
    perl_version: "['5.36', '5.38']"
    os: "['ubuntu']"

Annoyingly, the parameters to a reusable workflow can only be a single scalar value. That’s why we have to use a JSON-encoded string representing an array of values. Maybe this will get better in the future.

The cpan-perlcritic workflow also has a parameter. You can use level to change the level that perlcritic runs at. The default is 5 (the gentlest level) but if you were feeling particularly masochistic, you could do this:

perlcritic:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-perlcritic.yml@main
    with:
      level: 1

The workflows are, of course, available on GitHub. It would be great to have some people trying them out and reporting back on their experiences. Raising issues and sending pull requests is very much encouraged.

Please let me know how you get on with them.

The post GitHub Actions for Perl Development appeared first on Perl Hacks.

You might remember that I’ve been taking an interest in GitHub Actions for the last year or so (I even wrote a book on the subject). And at the Perl Conference in Toronto last summer I gave a talk called “GitHub Actions for Perl Development” (here are the slides and the video).

During that talk, I mentioned a project I was working on to produce a set of reusable workflows that would make it easier for anyone to start using GitHub Actions in their Perl development. Although (as I said in the talk) things were moving pretty quickly on the project at the time, once I got back to London, several other things became more important and work on this project pretty much stalled. But over the last couple of weeks, I’ve returned to this project and I’ve finally got some of the workflows into a state where I’ve been using them successfully in my GitHub repos and I think they’re now ready for you to start using them in yours. There are three workflows that I’d like you to try:

  • cpan_test: This runs your test suite and reports on the results
  • cpan_coverage: This calculates the coverage of your test suite and reports the results. It also uploads the results to coveralls.io
  • cpan_perlcritic: This runs perlcritic over your code and reports on the results

And using these workflows in your GitHub repos is as simple as creating a new file in the .github/workflows directory which contains something like this:

name: CI

on:
  push:
    branches: [master]
  pull_request:
    branches: [master]
  workflow_dispatch:

jobs:
  build:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-test.yml@main

  coverage:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-coverage.yml@main

  perlcritic:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-perlcritic.yml@main

There are a couple of parameters you can use to change the behaviour of these workflows. In the Toronto talk, I introduced the idea of a matrix of tests, where you can test against three operating systems (Linux, MacOS and Windows) and a list of Perl versions. By default, the cpan-test workflow uses all three operating systems and all production versions of Perl from 5.24 to 5.38. But you can change that by using the perl_version and os parameters. For example, if you only wanted to test on Ubuntu, using the most recent two versions of Perl, you could use this:

build:
  uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-test.yml@main
  with:
    perl_version: "['5.36', '5.38']"
    os: "['ubuntu']"

Annoyingly, the parameters to a reusable workflow can only be a single scalar value. That’s why we have to use a JSON-encoded string representing an array of values. Maybe this will get better in the future.

The cpan-perlcritic workflow also has a parameter. You can use level to change the level that perlcritic runs at. The default is 5 (the gentlest level) but if you were feeling particularly masochistic, you could do this:

perlcritic:
    uses: PerlToolsTeam/github_workflows/.github/workflows/cpan-perlcritic.yml@main
    with:
      level: 1

The workflows are, of course, available on GitHub. It would be great to have some people trying them out and reporting back on their experiences. Raising issues and sending pull requests is very much encouraged.

Please let me know how you get on with them.

The post GitHub Actions for Perl Development appeared first on Perl Hacks.

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

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

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

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

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

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

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

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

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

The post 2023 in Gigs appeared first on Davblog.

I’ve mentioned before how much I enjoyed Olaf Alders’ talk, Whither Perl, at the Perl and Raku Conference in Toronto last month. I think it’s well worth spending forty minutes watching it. It triggered a few ideas that I’ll be writing about over the coming weeks and, today, I wanted to start by talking briefly about the idea of GitHub Organisations and introducing a couple of organisations that I’ve recently set up.

Olaf talks about GitHub Organisations as a way to ensure the continuity of your projects. And I think that’s a very important point. I’ve written a few times over recent years about the problems of getting fixes into CPAN modules when the maintainer has gone missing. This is also true of non-CPAN projects that members of the community might find useful. By setting up an organisation and inviting a few trusted people to join it, you can share the responsibility of looking after your projects. So if you lose interest or drift away, there’s a better chance that someone else will be able to take up the reins.

It’s actually a thought that I had before going to Toronto. A couple of months ago, I set up the Perl Tools Team organisation and transferred ownership of four of my repos.

There will, no doubt, be other repos that I’ll want to transfer over to this organisation in time. And, of course, if you have a tool that is used by the Perl community, I’ll be happy to add it to the list. Just get in touch and we can talk about it.

The other organisation (and I set this up just this morning) now owns all of the repos for my CPAN modules. I won’t be adding anybody else’s repos to this organisation, but if you send PRs to any of these projects (and I’m looking at you, Mohammad) then don’t be surprised if you get added to the organisation too! If you’ve watched my talk on GitHub Actions for Perl Development, then you might remember that I was developing a GitHub Workflow definition for releasing modules to CPAN. That’s still a work in progress, but now I’m thinking that I could add my PAUSE credentials to the GitHub secrets store for this organisation and the GitHub workflow could release the code to CPAN using my credentials without my input (but, obviously, I’m still considering the security implications of that – it would certainly only ever be available to me and a few trusted lieutenants).

This is still all very new and it will definitely develop in several directions over the coming months. But it feels like the a move in the right direction. After twenty years of CPAN releases, it feels like I’m turning my work into a “proper” project. And, hopefully, it can serve as a template that other people can follow. I’ll let you know how it goes.

So, what do you think? Is this the right model for CPAN development (and, also, Perl infrastructure development) moving forward? Would you be interested in joining either of these organisations? Do you have any tools that the Perl Tools Team could maintain for you?

The post GitHub Organisations appeared first on Perl Hacks.

I’ve mentioned before how much I enjoyed Olaf Alders’ talk, Whither Perl, at the Perl and Raku Conference in Toronto last month. I think it’s well worth spending forty minutes watching it. It triggered a few ideas that I’ll be writing about over the coming weeks and, today, I wanted to start by talking briefly about the idea of GitHub Organisations and introducing a couple of organisations that I’ve recently set up.

Olaf talks about GitHub Organisations as a way to ensure the continuity of your projects. And I think that’s a very important point. I’ve written a few times over recent years about the problems of getting fixes into CPAN modules when the maintainer has gone missing. This is also true of non-CPAN projects that members of the community might find useful. By setting up an organisation and inviting a few trusted people to join it, you can share the responsibility of looking after your projects. So if you lose interest or drift away, there’s a better chance that someone else will be able to take up the reins.

It’s actually a thought that I had before going to Toronto. A couple of months ago, I set up the Perl Tools Team organisation and transferred ownership of four of my repos.

There will, no doubt, be other repos that I’ll want to transfer over to this organisation in time. And, of course, if you have a tool that is used by the Perl community, I’ll be happy to add it to the list. Just get in touch and we can talk about it.

The other organisation (and I set this up just this morning) now owns all of the repos for my CPAN modules. I won’t be adding anybody else’s repos to this organisation, but if you send PRs to any of these projects (and I’m looking at you, Mohammad) then don’t be surprised if you get added to the organisation too! If you’ve watched my talk on GitHub Actions for Perl Development, then you might remember that I was developing a GitHub Workflow definition for releasing modules to CPAN. That’s still a work in progress, but now I’m thinking that I could add my PAUSE credentials to the GitHub secrets store for this organisation and the GitHub workflow could release the code to CPAN using my credentials without my input (but, obviously, I’m still considering the security implications of that – it would certainly only ever be available to me and a few trusted lieutenants).

This is still all very new and it will definitely develop in several directions over the coming months. But it feels like the a move in the right direction. After twenty years of CPAN releases, it feels like I’m turning my work into a “proper” project. And, hopefully, it can serve as a template that other people can follow. I’ll let you know how it goes.

So, what do you think? Is this the right model for CPAN development (and, also, Perl infrastructure development) moving forward? Would you be interested in joining either of these organisations? Do you have any tools that the Perl Tools Team could maintain for you?

The post GitHub Organisations appeared first on Perl Hacks.

It’s been over twenty years since I spoke at a conference in North America. That was at OSCON in San Diego. I’ve actually never spoken at a YAPC, TPC or TPRC in North America. I have the standard European concern about being seen to encourage the USA’s bad behaviour by actually visiting it, so when I saw this year’s TPRC was in Canada, I thought that gave me the perfect opportunity to put that right.

So I proposed a talk which was accepted.

It was also the first time I’d been to any kind of conference since before the pandemic. My last conference was in Riga in 2019.

Despite Air Transat’s determination to prevent it from happening, my girlfriend and I made it to Toronto a few days before the conference started. It was her birthday, so we spent Sunday and Monday relaxing and getting to know Downtown Toronto. On Monday afternoon, we moved to the conference hotel and prepared to geek out.

One of the first people I spoke to at the conference on Tuesday morning was fellow Londoner Mohammad Anwar. As is the law (I don’t make the rules!) I was mildly rebuking him about the ridiculous amount of work he puts into the Perl community. I told him the story of a senior member of the community who, about ten years ago, said to me: “I don’t understand why you still make so much effort, Dave. You have your White Camel, don’t you?” I swear I didn’t know that Mohammad was about to be awarded the 2022 White Camel – but it gave me the opportunity to go up to him and say, “See, you can stop making such an effort now!” I hope he doesn’t really stop; but he should really take things a bit easier.

The next three days were a happy blur of geekery. As always at these conferences, there were too many talks that I wanted to see and, inevitably, I still have to catch up on some of them on YouTube (thanks to the dedicated video team for getting making them available so quickly).

There are a number of talks that I’d like more people to see. I think it would be a great use of your time to watch these videos:

I gave two talks – a lightning talk on CPAN Dashboard and a longer talk on GitHub Actions for Perl Development. After not giving a talk for four years, I felt a little rusty – but I think they went ok.

And then, after a seemingly-fleeting three days, it was all over and we all returned to our own countries. There’s another conference in Finland next month. Unfortunately, I’m unable to be there – and last week’s experience makes me regret that.

It was great to catch up with old friends and share our mutual interest in Perl. It was particularly great after four years without a conference to go to. I hope it’s not four years until I’m at another.

The post The Perl and Raku Conference, Toronto 2023 appeared first on Perl Hacks.

It’s been over twenty years since I spoke at a conference in North America. That was at OSCON in San Diego. I’ve actually never spoken at a YAPC, TPC or TPRC in North America. I have the standard European concern about being seen to encourage the USA’s bad behaviour by actually visiting it, so when I saw this year’s TPRC was in Canada, I thought that gave me the perfect opportunity to put that right.

So I proposed a talk which was accepted.

It was also the first time I’d been to any kind of conference since before the pandemic. My last conference was in Riga in 2019.

Despite Air Transat’s determination to prevent it from happening, my girlfriend and I made it to Toronto a few days before the conference started. It was her birthday, so we spent Sunday and Monday relaxing and getting to know Downtown Toronto. On Monday afternoon, we moved to the conference hotel and prepared to geek out.

One of the first people I spoke to at the conference on Tuesday morning was fellow Londoner Mohammad Anwar. As is the law (I don’t make the rules!) I was mildly rebuking him about the ridiculous amount of work he puts into the Perl community. I told him the story of a senior member of the community who, about ten years ago, said to me: “I don’t understand why you still make so much effort, Dave. You have your White Camel, don’t you?” I swear I didn’t know that Mohammad was about to be awarded the 2022 White Camel – but it gave me the opportunity to go up to him and say, “See, you can stop making such an effort now!” I hope he doesn’t really stop; but he should really take things a bit easier.

The next three days were a happy blur of geekery. As always at these conferences, there were too many talks that I wanted to see and, inevitably, I still have to catch up on some of them on YouTube (thanks to the dedicated video team for getting making them available so quickly).

There are a number of talks that I’d like more people to see. I think it would be a great use of your time to watch these videos:

I gave two talks – a lightning talk on CPAN Dashboard and a longer talk on GitHub Actions for Perl Development. After not giving a talk for four years, I felt a little rusty – but I think they went ok.

And then, after a seemingly-fleeting three days, it was all over and we all returned to our own countries. There’s another conference in Finland next month. Unfortunately, I’m unable to be there – and last week’s experience makes me regret that.

It was great to catch up with old friends and share our mutual interest in Perl. It was particularly great after four years without a conference to go to. I hope it’s not four years until I’m at another.

The post The Perl and Raku Conference, Toronto 2023 appeared first on Perl Hacks.

[This post might sound like I’m angry at people making it hard to make progress on some things. That’s not the case at all. I realise completely that people have limited time and they get to choose how they spend it. If people are too busy elsewhere or have moved on to other projects then that’s just how it is and we need to deal with that the best we can.]

Back in December 2020, I wrote a blog post about how I wanted to fix a long-standing problem with App::HTTPThis. I’m happy to report that two and a half years later, the problem has been fixed.

To summarise my previous blog post:

  • App::HTTPThis allows you to run a tiny web server that will serve the contents of a directory over HTTP. But, unfortunately, it doesn’t support default pages like “index.html”.
  • App::HTTPThis uses Plack::App::Directory (which is part of the Plack distribution) to do the work – so it’s that which actually doesn’t support “index.html”.
  • People suggested Plack::Middleware::DirIndex, but that also didn’t quite do the right thing.
  • I submitted a pull request on Plack::App::Directory to add support for “index.html”.
  • I wrote a new module called Plack::App::DirectoryIndex which was like Plack::App::Directory but with added support for “index.html”.
  • I submitted a pull request on App::HTTPThis to use my module in place of Plack::App::Directory.

Now read on…

Both of my pull requests went unactioned for months. In the end, I decided to approach the Perl modules list to ask if I could get co-maintainer permission on App::HTTPThis (it looked like the original maintainer had lost interest – there hadn’t been a release since 2010). When I heard nothing back, I put the project to one side only occasionally returning to add a new comment on my two pull requests.

Then last month I decided I’d have another go at getting co-maintainer permissions. This time it worked and, earlier this week, I got an email from Neil Bowers saying that the previous maintainer had agreed to give me permission and that I could now upload the module to CPAN.

At that point, I realised that the release mechanism for the module was based on Dist::Zilla and also that fashions in the Dist::Zilla world had changed since App::HTTPThis had last been released. This meant that many of the plugins used had been deprecated and I had to do a bit of work to even release the module (which led to a small rant on Reddit).

But I managed to release version 0.003 to CPAN. Only to realise very soon afterwards that my Dist::Zilla-wrangling had missed an important fix. I fixed that and released version 0.004.

I then got an email from PAUSE telling me that I didn’t have permission to release the module. It seems this was a known PAUSE bug and Neil was able to apply a workaround for me. I was able to release version 0.004.

All of which means I now have a version of App::HTTPThis (and its included program, http_this) which supports default pages. You just have to type, for example:

$ http_this --autoindex .

And the current directory will be served over HTTP. Also (and this is the important bit!) if you have a file called “index.html” then that will be used instead of the server displaying a directory listing. It’s a tiny improvement, but one that will be very useful to me. And well worth the two and a half years I’ve invested in getting it released.

So why do I say that the mission is only “almost” completed? Well, there’s still that outstanding pull request on Plack::App::Directory. If that ever gets applied, I’ll remove Plack::App::DirectoryIndex from App::HTTPThis (and mark it as deprecated on CPAN).

This is, of course, a supremely unimportant fix in the grand scheme of things. But I think it illustrates an important issue that the Perl community should be thinking about. The community is shrinking. Or, at least, the part of the community that supports CPAN modules and runs our important infrastructure is shrinking. CPAN is full of modules that are now unsupported. I’ve lost count of the number of bugs I’ve reported or patches I’ve supplied that have been ignored because the module author is no longer interested. In some cases, I’ve taken over the module myself, but that’s not a scalable solution. Honestly, I don’t know what it is. But I do think that relying on CPAN modules has got harder over the last few years. And it’s not going to get easier any time soon.

The post Mission (Almost) Accomplished appeared first on Perl Hacks.

[This post might sound like I’m angry at people making it hard to make progress on some things. That’s not the case at all. I realise completely that people have limited time and they get to choose how they spend it. If people are too busy elsewhere or have moved on to other projects then that’s just how it is and we need to deal with that the best we can.]

Back in December 2020, I wrote a blog post about how I wanted to fix a long-standing problem with App::HTTPThis. I’m happy to report that two and a half years later, the problem has been fixed.

To summarise my previous blog post:

  • App::HTTPThis allows you to run a tiny web server that will serve the contents of a directory over HTTP. But, unfortunately, it doesn’t support default pages like “index.html”.
  • App::HTTPThis uses Plack::App::Directory (which is part of the Plack distribution) to do the work – so it’s that which actually doesn’t support “index.html”.
  • People suggested Plack::Middleware::DirIndex, but that also didn’t quite do the right thing.
  • I submitted a pull request on Plack::App::Directory to add support for “index.html”.
  • I wrote a new module called Plack::App::DirectoryIndex which was like Plack::App::Directory but with added support for “index.html”.
  • I submitted a pull request on App::HTTPThis to use my module in place of Plack::App::Directory.

Now read on…

Both of my pull requests went unactioned for months. In the end, I decided to approach the Perl modules list to ask if I could get co-maintainer permission on App::HTTPThis (it looked like the original maintainer had lost interest – there hadn’t been a release since 2010). When I heard nothing back, I put the project to one side only occasionally returning to add a new comment on my two pull requests.

Then last month I decided I’d have another go at getting co-maintainer permissions. This time it worked and, earlier this week, I got an email from Neil Bowers saying that the previous maintainer had agreed to give me permission and that I could now upload the module to CPAN.

At that point, I realised that the release mechanism for the module was based on Dist::Zilla and also that fashions in the Dist::Zilla world had changed since App::HTTPThis had last been released. This meant that many of the plugins used had been deprecated and I had to do a bit of work to even release the module (which led to a small rant on Reddit).

But I managed to release version 0.003 to CPAN. Only to realise very soon afterwards that my Dist::Zilla-wrangling had missed an important fix. I fixed that and released version 0.004.

I then got an email from PAUSE telling me that I didn’t have permission to release the module. It seems this was a known PAUSE bug and Neil was able to apply a workaround for me. I was able to release version 0.004.

All of which means I now have a version of App::HTTPThis (and its included program, http_this) which supports default pages. You just have to type, for example:

$ http_this --autoindex .

And the current directory will be served over HTTP. Also (and this is the important bit!) if you have a file called “index.html” then that will be used instead of the server displaying a directory listing. It’s a tiny improvement, but one that will be very useful to me. And well worth the two and a half years I’ve invested in getting it released.

So why do I say that the mission is only “almost” completed? Well, there’s still that outstanding pull request on Plack::App::Directory. If that ever gets applied, I’ll remove Plack::App::DirectoryIndex from App::HTTPThis (and mark it as deprecated on CPAN).

This is, of course, a supremely unimportant fix in the grand scheme of things. But I think it illustrates an important issue that the Perl community should be thinking about. The community is shrinking. Or, at least, the part of the community that supports CPAN modules and runs our important infrastructure is shrinking. CPAN is full of modules that are now unsupported. I’ve lost count of the number of bugs I’ve reported or patches I’ve supplied that have been ignored because the module author is no longer interested. In some cases, I’ve taken over the module myself, but that’s not a scalable solution. Honestly, I don’t know what it is. But I do think that relying on CPAN modules has got harder over the last few years. And it’s not going to get easier any time soon.

The post Mission (Almost) Accomplished appeared first on Perl Hacks.

Seventy Years of Change

Her Majesty has, of course, seen changes in many areas of society in the seventy years of her reign. But here, we’re most interested in the line of succession. So we thought it would be interesting to look at the line of succession on the day that she took the throne and see what had happened to the people who were at the top of the line of succession on that day. It’s a very different list to today’s.

  1. The Prince Charles, Duke of Cornwall
    We start with the one person who is in exactly the same place as he was seventy years ago. Prince Charles was three years old and hadn’t yet been made Prince of Wales.
  2. The Princess Anne
    Princess Anne has fallen a long way in seventy years. The birth of younger brothers (back in the days when sex mattered in the line of succession) and those brothers having families of their own mean that she is now down at number 17.
  3. Princess Margaret
    We’ve run out of the Queen’s descendants after only two places (today, they fill the top 24 places in the line) so we move to her sister. Princess Margaret had fallen to 11th place before her death in 2002.
  4. Prince Henry, Duke of Gloucester
    We’ve now run out of descendants of George VI, so we need to look at his brothers. This is the father of the current duke. He fell to 8th place before dying in 1974.
  5. Prince William of Gloucester
    The Duke of Gloucester’s eldest son had fallen to position 9 before sadly dying before his father in 1972.
  6. Prince Richard of Gloucester
    As his eldest son predeceased their father, it was Prince Richard who became Duke of Gloucester when the first duke died in 1974. He is currently in 30th place.
  7. Prince Edward, Duke of Kent
    The first Duke of Kent had died ten years earlier, so it was his son, Prince Edward, who held the title, at the age of 16, who was duke in 1952, He fell out of the top 30 in 2012.
  8. Prince Michael of Kent
    Prince Michael had fallen to 16th place before his marriage to a Catholic, in 1978, excluded him from the line of succession. He was reinstated in 2015 (because the Succession to the Crown Act meant that marriage to a Catholic was no longer a reason for exclusion) but he reappeared outside of the top 30.
  9. Princess Alexandra of Kent
    Princess Alexandra had dropped down the list pretty consistently throughout her life. From 1999 she popped in and out of the top 30 a few times. but she left it for the last time in 2003.
  10. Princess Mary, Princess Royal
    The youngest child and only daughter of George V, Princess Mary had called to 17th in line before she died in 1965.
  11. George Lascelles, The 7th Earl of Harewood
    Fell out of the top 30 in 1994 before dying in 2011.
  12. David Lascelles, Viscount Lascelles
    Fell out of the top 30 in 1993.
  13. Gerald Lascelles
    Fell out of the top 30 in 1982 and died in 1998.
  14. Princess Arthur of Connaught, Duchess of Fife
    Fell to 17th before dying in 1959
  15. James Carnegie, 3rd Duke of Fife
    Fell out of the top 30 in 1981 and died in 2015
  16. Olaf V, King of Norway
    A bit of a leap as we find the royal family of Norway surprisingly close to the top of the list. King Olaf was a grandson of Edward VII (through Edward’s daughter Maud). He fell out of the top 30 in 1979 and died in 1991.
  17. Prince Harald of Norway
    Prince Harald became king of Norway in 1991. He fell out of the top 30 of the British line of succession in 1977.
  18. Princess Ragnhild of Norway
    Princess Ragnhild fell out of the top 30 in 1973 and died in 2012.
  19. Princess Astrid of Norway
    Princess Astrid fell out of the top 30 in 1964.
  20. Carol II of Romania
    The next-closest royal family to ours is the Romanians. Carol II was a great-grandson of Victoria. The death of George VI moved him up a place from 21 to 20 and he remained there until his death the following year. Carol hadn’t actually been King of Romania since he was forced to abdicate in 1940.
  21. Carol Lambrino
    The question of Carol Lambino’s legitimacy is a question of some dispute — so he may not have been on the line of succession at all. But, if he was, he fell out of the top 30 in 1963 and died in 2006.
  22. Paul-Philippe Hohenzollern
    As son of the possibly-illegitimate Carol Lambino, Paul-Phillippe’s place in the line of succession is also in question. But, anyway, he fell out of the top 30 in 1962.
  23. Prince Nicholas of Romania
    Prince Nicholas fell out of the top 30 in 1961 and died in 1978.
  24. Elisabeth of Romania
    Fell to number 27 before dying in 1956.
  25. Maria of Yugoslavia
    Fell to position 30 before dying in 1961.
  26. Peter II of Yugoslavia
    Peter was no longer King of Yugoslavia, having been deposed in 1945. He fell out of the top 30 in 1961 and died in 1970.
  27. Prince Tomislav of Yugoslavia
    Fell out of the top 30 in 1960 and died in 2000.
  28. Prince Andrew of Yugoslavia
    Fell out of the top 30 in 1959 and died in 1990.
  29. Princess Ileana of Romania
    Fell out of the top 30 in 1954 and died in 1991.
  30. Archduke Stefan of Austria
    Fell out of the top 30 in 1953 and died in 1998.

I think that’s an interesting list for a few reasons:

  • The fact that we’ve gone from two of the Queen’s descendants to twenty-four of them on the list (but even that’s not as big a difference as happened during Victoria’s reign).
  • Only ten of the people on the list are still living.
  • There’s a large number of foreign royalty on the list — basically, the second half of the list is taken up by members of the royal families of Norway, Romania and Yugoslavia. This is obviously because of the way that royal families inter-married up until early in the 20th century. We see far less of that now.

So what do you think? Was the 1952 list a surprise to you? Did you expect it to be as different as it is from the current list?

Originally published at https://blog.lineofsuccession.co.uk on February 7, 2022.


Seventy Years of Change — 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.

Yesterday’s coronation showed Britain doing what Britain does best — putting on the most gloriously bonkers ceremony the world has seen…

Ratio: The Simple Codes Behind the Craft of Everyday Cooking (1) (Ruhlman's Ratios)
author: Michael Ruhlman
name: David
average rating: 4.06
book published: 2009
rating: 0
read at:
date added: 2023/02/06
shelves: currently-reading
review:

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

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

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

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

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

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

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

The post 2022 in Gigs appeared first on Davblog.

Dave Cross posted a photo:

Goodbye Vivienne

via Instagram instagr.am/p/CmyT_MSNR3-/

Dave Cross posted a photo:

Low sun on Clapham Common this morning

via Instagram instagr.am/p/Cmv4y1eNiPn/

Dave Cross posted a photo:

There are about a dozen parakeets in this tree. I can hear them and (occasionally) see them

via Instagram instagr.am/p/Cmv4rUAta58/

Dave Cross posted a photo:

Sunrise on Clapham Common

via Instagram instagr.am/p/Cmq759NtKtE/

Dave Cross posted a photo:

Brixton Academy

via Instagram instagr.am/p/CmOfgfLtwL_/

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

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.

‘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.

Do Parents Think Smart Devices Should Encourage Polite Conversations?

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.

Do Parents Think Their Children are Less Polite While Using Smart Speakers?

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.

What Approaches Have Been Taken By Tech Companies to Address the Problem?

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.

George and the Smart Home

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.

S.

S.
author: J.J. Abrams
name: David
average rating: 3.86
book published: 2013
rating: 0
read at:
date added: 2022/01/16
shelves: currently-reading
review:

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.

  • Tubular Bells at the Royal Festival Hall
    This was a strange show for several reasons. Firstly, it was advertised as commemorating the fiftieth anniversary of Tubular Bells. But the album was released in 1973, so it was two years early (apparently it was the fiftieth anniversary of when Mike Oldfield started writing the piece). Secondly, Mike Oldfield wasn’t performing – but you needed to examine the publicity very carefully to work that out. And thirdly, there was a troupe of acrobats that were pointlessly leaping around the stage while the musicians played. All in all, I thought this was slightly disappointing.
  • Heaven 17 at the Roundhouse
    Many of these shows were postponed from 2020. This was originally intended to celebrate the fortieth anniversary of the Human League album, Travelogue, but it ended but being the forty-first anniversary. But none of that mattered. This was Heaven 17 playing all of the first two Human League albums and it was absolutely wonderful. Apparently, they had invited Phil Oakey to take part, but he wasn’t interested. That’s Heaven 17 in the photo above.
  • LUMP at the Scala
    LUMP is Laura Marling playing with Tunng’s Mike Lindsay. I kinda assumed that their first album was going to be a one-off, but they produced a second album in 2020. This was the first gig I’d been to in a cramped venue like the Scala for a couple of years and it all got a bit too much for me. I really didn’t enjoy the atmosphere and left during the third or fourth song. I still love the album though and I hope to build up my tolerance for gig crowds over the coming months.
  • The Staves at Shepherd’s Bush Empire
    Actually, this was only two-thirds of the Staves. One of the sisters has has a baby recently and has decided to sit out tours for a couple of years. But the two remaining sisters still put on a great show.
  • Laura Marling at the Roundhouse
    Given how few gigs I saw last year, it’s surprising how repetitive they were. Here’s Laura Marling again (and the Roundhouse again!) Although she has yet to match the heights of the Short Movie tour, Laura Marling is always worth seeing and this show was no exception.
  • Heaven 17 at the Shepherd’s Bush Empire
    More repetition. I think the two Heaven 17 gigs were originally supposed to be several months apart, but the vagaries of the Covid scheduling changes led to them being just two months apart. This one celebrated the fortieth (actually forty-first) anniversary of Heaven 17 starting and was a glorious journey through their back catalogue. Oh, and the support was Pete Wylie, so I can finally say I’ve seen all three members of the Crucial Three live.
  • Orchestral Manoeuvres in the Dark at Hammersmith Apollo
    OMD are just one of those bands that I see live whenever I can. I’ve now been seeing them for over forty years (since they supported Gary Numan in 1980). They have such a massive back catalogue that they can just play hit after hit for two hours. But this show was a bit different as they started by playing all of their 1981 album, Architecture and Morality. They were as good as I’ve ever seen them.

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.

The Introvert Entrepreneur
author: Beth Buelow
name: David
average rating: 3.43
book published: 2015
rating: 0
read at:
date added: 2020/01/27
shelves: currently-reading
review:


Some thoughts on ways to measure the quality of Perl code (and, hence, get a basis for improving it)

How (and why) I spent 90 minutes writing a Twitterbot that tweeted the Apollo 11 mission timeline (shifted by 50 years)

A talk from the European Perl Conference 2019 (but not about Perl)
Prawn Cocktail Years
author: Lindsey Bareham
name: David
average rating: 4.50
book published: 1999
rating: 0
read at:
date added: 2019/07/29
shelves: currently-reading
review:

Write. Publish. Repeat. (The No-Luck-Required Guide to Self-Publishing Success)
author: Sean Platt
name: David
average rating: 4.28
book published: 2013
rating: 0
read at:
date added: 2019/06/24
shelves: currently-reading
review:


The slides from a half-day workshop on career development for programmers that I ran at The Perl Conference in Glasgow

A (not entirely serious) talk that I gave at the London Perl Mongers technical meeting in March 2018. It talks about how and why I build a web site listing the line of succession to the British throne back through history.
Dave Cross / Tuesday 05 March 2024 06:01