sources
Subscribe
OPMLPowered by Perlanet
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::httpsIt’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.
‘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.
author: J.J. Abrams
name: David
average rating: 3.85
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.
author: David Mitchell
name: David
average rating: 3.94
book published: 2020
rating: 0
read at:
date added: 2021/11/26
shelves: currently-reading
review:
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.
I’ve just upgraded my V6 box to Virgin TV 360. I’m starting to think that was a mistake.
When Liberty Global took over Virgin Media in 2013, it seemed likely that at some point in the future VM would stop using TiVo software to run its set-up boxes and switch to something based on Liberty’s Horizon platform. That something is Virgin TV 360, which was announced last year and is now being rolled out to any VM subscriber who asks for it. I asked for the upgrade last week and my new kit arrived today. I’ve been using it for a few hours and I’m beginning to wish I hadn’t.
I heard about Virgin TV 360 last year, but I haven’t been keeping up with the news, so I was somewhat surprised to see it advertised on television last week. On further investigation, I found the page about it on their website and discovered that I could order the upgrade for my account. The website upgrade path didn’t work for me, so I called them and booked the upgrade.
As I have a V6 box, I didn’t need new hardware, they just sent out a new remote control and told me that I could upgrade the software myself once the new remote arrived. That arrived this morning, so at lunchtime, I settled in to upgrade my system.
It started off smoothly. A screen warned that the upgrade could take up to half an hour, but it only took a few minutes before I was looking at the new interface.
The old TiVo interface was really showing its age and this new interface is much better. It looks pretty similar to Android TV. Gone are most of the lists of titles, replaced by tiles with pictures in them. But while the new look and feel had me smiling, my smile evaporated once I started to use it. I don’t think I was a particularly expert user of the old TiVo interface, but a lot of the functions I used to regularly use are either missing or buried so deeply in the interface that I haven’t found them yet.
A lot of the problems are around the search mechanism. Search is being pushed as the main way to interact with the new system, so it’s disappointing to see that it’s not as powerful as the old TiVo system was. It seems that the database that powers the search isn’t as sophisticated as the old one was.
The old database contained details of thousands of TV shows and films. You could search for pretty much any TV show and you could get information about it (lists of episodes, cast and crew lists, things like that). At that point, you could set a “series link” so that if that program was broadcast on any of your channels in the future, the TiVo would record it for you. There were ways to fine-tune those records — only record HD broadcasts, only record new episodes, only record season 3 onwards — things like that. The new search doesn’t do most of that. It seems to only find shows that are on in the next couple of weeks. When it finds something, you can create a series link, but it’s hard-wired to the channel that you found the program on. And none of the other fine-tunings are available.
A couple of examples might help here. On my old system, I had a series link set for “Doctor Who” on all channels. So it would record an episode of Doctor Who wherever it was broadcast. I wanted to set up something like that on the new system. I searched for “Doctor Who” and it found a few repeats that are coming up on W in the next couple of weeks. But if I used that to set up the series link, I’d miss the new season that’s being broadcast on BBC One later this year. I also wanted to set a series link for “What We Do in the Shadows”. There’s a new season of that coming at some point, but because there are no episodes being broadcast in the next couple of weeks, Virgin TV 360 knows nothing about it and I can’t create a series link.
I mentioned that the old search database had cast and crew lists. You could use those to search for people and set up automatic recordings for any show that mentioned those people. I had a dozen or so of those set up — so I’d never miss a show that featured Neil Gaiman, Alice Roberts, Gerry Anderson and many other people — but that’s not available in the new system. So that’s a whole type of use that I can no longer do.
But I think the most frustrating problem I’ve found so far is the way it renumbers channels. My Virgin Media subscription comes with over 200 channels. Many of them, I have no interest in. So the TiVo software had a “favourite channels” feature. I could mark the channels that I was interested in watching and the TV guide would give me a view that only displayed those channels. The new software also has something like that. But the new feature also has another, completely unexpected side effect. All of the channels have a three-digit number assigned. And over the many years I’ve been using Virgin Media, I’ve learned the numbers for many of the channels that I use frequently. But the new system uses my favourite channels to number the channels and that gives them new numbers that are completely confusing.
As an example, say I’ve only chosen three favourite channels — BBC One HD (108), BBC Four (107) and BBC News HD (601) — the new software actively hides the “real” channel numbers from me and, if I want to type a number on the remote to change the channel, expects me to type 1, 2 or 3. This is annoying for two reasons. Firstly, I need to memorise a whole new set of channel numbers and, secondly, those numbers will change whenever I add or remove a favourite channel. That seems like idiocy to me. Who thought that would be a useful feature?
All in all, I’m really struggling after a few hours with this new interface. I don’t think I’m usually someone who just dislikes change. I think these are real holes in the functionality that I’m missing from the old system.
I’m hoping that some of these will be fixed in future releases of the software. But I’m worried that some of them will be seen as a simplified way of doing things and, therefore, just something I’ll have to get used to.
Perhaps this won’t matter to new customers who are just joining Virgin Media. But if you’re an existing customer who likes using these powerful features, you might want to think twice before upgrading to this new system.
The post Virgin TV 360 — First impressions appeared first on Davblog.
Freelancing is becoming a really popular way to make money. Sites like Upwork and Fiverr are booming. But how do you decide which jobs to take on? Here are three questions that might help you decide whether to take on some work you’ve been offered.
Question 1: Do I need the work?
Obviously, when you first start out in freelancing, you’ll be grateful for all the work you’re offered and you’ll be happy to take it all on. But, if things go well, you will eventually reach the point where you’re offered more work than you have time to do. At this point you have three options:
- Politely tell the client that you have no capacity to take on any work currently — but also let them know when you will next be available (they might be happy to wait).
- Subcontract the work out to someone else — but don’t forget to allocate time to manage your subcontractors and carry out quality checks on their work.
- Work into the evenings or at weekends in order to finish the extra work. This might be ok occasionally, but remember that one of the reasons you got into freelancing was probably to have more control over your working week and to spend more quality time with your friends and family.
Of course, in order to know when you’re getting near to your capacity, it’s important to know what your capacity is. You need to be good at estimating how long each piece of work is going to take. One reason why I don’t like the third of the options above is that I save evenings and weekends for contingency when an estimate goes wrong and planning to use that time for work removes that contingency.
It’s also worth noting that if you’re consistently in a situation where you’re turning down work because you’re at capacity, that just might be the universe trying to tell you that it’s time to raise your prices.
Question 2: Is this work I really want to do?
Being at or near your capacity is a good reason to reconsider the types of work that you do. Perhaps there are bits of it that you don’t enjoy as much as others. This might be a good time to specialise.
Maybe you design book covers but the covers you really enjoy designing are for children’s books or chick-lit. Then stop taking on commissions for science fiction or war stories. Maybe you’re a copywriter but you find there are particular subjects that you prefer writing about. Carve out a large enough list of topics around your areas of interest and only take on work in those areas.
Or you can gently steer your work towards jobs that stretch you in certain ways. Freelancers don’t often take time for training themselves, but you can find ways to learn on the job. Maybe you create WordPress themes and you want to learn more about programming in PHP. Choose jobs that concentrate more on development and less on design. Change your job description from “WordPress theme designer” to “WordPress theme developer”.
Change your marketing materials appropriately so people stop asking you to work in areas that you don’t enjoy as much. You might have old clients who come back to you offering new work in the areas that you’re trying to cut out. You can decide on a case-by-case basis, but if you want to stick to your new specialisation, you can just say “I’m sorry but I don’t take on that kind of work anymore”. If you’re feeling particularly helpful, you might direct them to someone else you know who works in that area. That’s worth a commission payment, isn’t it?
Question 3: Is this a client I really want to work with?
We’ve all had “that client” who you never want to work with (see Clients From Hell for hundreds of examples). Well, if you’re working at capacity, then you don’t have to work with them again. When they approach you, tell them you’re fully booked up for three months.
But it’s not just individual clients that you have personal experience with. Maybe you find there are types of clients that you would rather not work with. Large corporations tend to move slowly. They might have complex procedures for signing you up as a new supplier and a seemingly infinite number of people who have to sign off on your work. You might decide it’s not worth the hassle.
On the other hand, some smaller organisations can be understaffed. Will your contacts be too busy elsewhere to give you timely feedback on your work? It can be frustrating to wait a week for someone to tell you how much (or how little!) they like your work.
We all have our personal preferences in this area. I’ve done work for some of the largest investment banks in the world and also for tiny internet start-ups. Given the choice, I’d go with the small company every time.
Or you could make a choice based on the client’s policies in various areas. Maybe you want to know their policies on looking after the environment? Or how they encourage diversity in their workforce? Or which political parties they make donations to.
Perhaps it’s actually what the client does that makes you want to avoid them. Are they involved in the arms trade? Do they enable rich people to avoid tax? Are they excessive polluters?
In all of these cases, if you decide not to work with the client, you can decide how you will tell them. You could use the standard approach of telling them you simply won’t have the capacity for several months or you might get a little more satisfaction by explaining exactly why you don’t want to do business with them (just don’t expect that your little protest will have any effect!)
Of course, having too much work is a great problem to have. But if you’re in that situation, I hope some of the strategies above will help you. Are there any other strategies that you use? Let me know in the comments.
The post Too much work? How do you choose what to take on? appeared first on Davblog.
[Update: the CPAN Request Tracker was saved. It’s now run by a new team of volunteers and none of my suggestions below are required.]
Two weeks ago, we learned that the CPAN Request Tracker was closing down early next year. I proposed a plan that CPAN authors could follow to ensure that their users can still find somewhere to report bugs in modules (and, perhaps more importantly, to see what bugs have already been reported in modules).
But that’s only part of the problem. In fact, it’s probably a minor part of the problem. If you’re an active CPAN author, then you probably already knew about the impending closure and had already made plans to deal with it. It’s likely that you had already moved your bug tracking to a new system. At the very least, you now know what the problem is and are considering the best way to deal with it before next March.
The far larger problem is the thousands of distributions that aren’t owned by active CPAN authors. What are we going to do about those?
How big is the problem? Well, the site cpan.rocks displays stats about CPAN. One of the panels on its front page shows a summary of the bugtracker information in CPAN distribution. You’ll see that 24,873 distributions (that’s 66% of them) have no bugtracker information included in their metadata. That’ll be for a number of reasons. Some of them will be distributions that haven’t been updated since alternative bugtrackers were supported by CPAN (originally, it was just assumed that everyone used the CPAN RT); some of them will be because the authors don’t know how to add the required metadata; and some of them (including most of my distributions) are missing it because the author just hasn’t got round to adding it yet. There will, of course, be many more reasons.
Some people will have read the recent news and will be galvanised into doing something about it (I fall firmly into that category) but others (and I’d suggest that it’s a large majority) either won’t hear about the change or won’t care about it. And why should they care? They were generous enough to donate some of their code to CPAN at some point. They don’t have any obligation at all to carry on maintaining it after they’ve lost interest in whatever project led to them writing that software.
Take, for example, Mail-Alias. That was released by someone called Tom Zeltwanger twenty years ago. He released three versions over a period of two months and then stopped. Who knows why. When he last updated the module, the CPAN search engine didn’t support alternative bugtrackers, so he never considered adding one. And that meant that the CPAN page for his module linked to the default bugtracker set up for the distribution on the CPAN RT. In the last fifteen years, four bugs have been reported against that module. But as Tom has moved on, nothing has been done about any of them. There are a lot of modules on CPAN in a similar situation.
But that leaves MetaCPAN (the current CPAN search engine) with a problem. Where does it send people who want to report a bug against an inactive module?
You might think that it doesn’t matter. But I disagree. Maybe I think that Mail::Alias would be the perfect module for a project I’m working on. Even before I start using it, it’s useful to be able to browse any existing bugs to see how they might affect my use of the module. And if someone later comes along and wants to take over maintenance of the module, then it’s useful for them to see any bugs that have been raised during the hiatus when the module was unmaintained.
So, I’m a big fan of having a default bugtracker for CPAN modules – even for ones with inactive authors. Which leads us to the question of where should that be. And I have a suggestion.
A few years ago, Micheal Schwern and Olaf Alders set up Gitpan. It’s an organisation which has a Github repo for every distribution on CPAN. And those repos each have a commit for every release of those distributions. Here, for example, is the repo for Mail-Alias – and you can see the three commits for the three releases I mentioned above.
So I’d like to suggest Gitpan as a suitable place to use as a default bugtracker for CPAN distributions. There are a couple of problems:
- It looks like the auto-population of the commits stopped a few years ago. We’d need to work out how that works and catch up on the recent uploads.
- None of the repos has the issue tracker turned on. But I expect that can be done with a relatively simple program that uses the GitHub API.
Of course, we also have the problem that some people object to using GitHub since it was taken over by Microsoft. But that’s fine, they can just point their bugtracker metadata to their preferred system.
The problem with the CPAN RT was that it needed too much maintenance – and the Perl NOC team is really overworked. Any self-hosted alternative seems likely to have the same problem eventually. So I’m all in favour of using a third-party alternative. And if you’re taking that route, then it makes sense (to me, at least) to use a third-party system that already has all (ok, most) of the repos set up.
I haven’t spoken to Schwern or Olaf about this, so I don’t know if there was some major problem that would stop this plan from working. But I think it’s worth looking at.
The post Replacing CPAN RT appeared first on Perl Hacks.
CPAN RT is going away. CPAN authors have until the beginning of March to extract any useful information from it.
RT is the “Request Tracker”, a bug tracking system that is written by Best Practical. For almost as long as I can remember, anyone who uploads a module to CPAN gets a free ticket queue for their module at rt.cpan.org. MetaCPAN assumes that’s where people should report bugs in your module and helpfully adds an “issues” link that goes to the appropriate page in RT.
But now that system is going away. It will be switched off on the 1st March 2021. The Perl NOC team is spread pretty thinly and they just don’t have the resources to keep it running.
Gabor has published a video talking about what this means and some of the potential problems. But I thought it would be useful to work on a list of things that CPAN authors should be thinking about over the next three months.
Firstly, and most importantly, you’ll need somewhere new for people to report problems with your modules. For most people, that’ll be simple enough. If you host your code repos somewhere like GitHub, then you could just use the issue trackers that most of those services provide. If you host your own code repos (or don’t have public code repos), then you’ll need to find an alternative solution.
Next you’ll need to tell people where to find your new bug tracker. You do this by adding it to the metadata for your CPAN distribution. If, like most people, you provide a Makefile.PL in your distribution, then you’ll want to add a snippet like this to your code:
META_MERGE => {
'meta-spec' => { version => 2 },
resources => {
bugtracker => {
"web" => "https://github.com/davorg/moox-role-json_ld/issues"
}
},It’s likely that you already have a “resources” key in your data structure (containing, for example, a link to your code repo), in which case you just need to add the “bugtracker” key inside it. When you release this new update to CPAN, the “issues” link will change to point to your new bug tracker.
You then have the problem of dealing with the tickets that are currently in your RT queues. I suggest one or more of the following strategies:
- Go through the list and fix any that can be easily fixed. I found two like that when looking through my list this morning. If you’re releasing new versions of the modules (to add the new bug tracker information) then you might as well fix a bug or two at the same time.
- Look for tickets that can be closed. My list contains some very old tickets. I mean like fifteen years old. If someone had a problem installing one of your modules fifteen years ago and hasn’t followed-up more recently, then there’s a good chance that they no longer care about the solution. What I’ve been doing is to check on CPAN Testers to see if anyone else has seen a similar problem. If I see other reports, I know that it’s something that needs to be fixed. If there’s just the one in RT, then I close it with a message saying (paraphrased) “if this is still a problem that you’d like me to investigate, then please open a new ticket at [link to new bug tracker]”.
- Then you’re left with the tickets that you’d still like to address at some point. The Perl NOC team say that they’ll probably make a static archive of the old RT tickets available. But it would be good to get those tickets over to your new bug tracker. As I’m using GitHub for my new bug trackers, and that’s currently the most popular solution other than the CPAN RT itself, I’m hoping that someone cleverer than me will write some code that will make moving the tickets easy. But if nothing happens before the end of January, I might have to look into that myself.
I’ve got a bit of work to do in this area myself. Although I’ve been using GitHub for all of my CPAN code for a long time, I haven’t been advertising the fact that I’d prefer people to use GitHub for bug reporting too. So I need to update all of my modules with the new bug tracker information included. I’ll do that over the next few weeks.
I have a couple of tools that might help in this process. Firstly, I’ve just added to CPAN Dashboard a column that links to the module’s bug tracker if one exists. I can use that to know which modules need to be updated.
You could add yourself to CPAN Dashboard if you wanted to get that information for your modules. But if you don’t want to do that, I’ve written a really short program that you can use to find your CPAN distributions that don’t include the bug tracker information. It’s available as a Gist.
Have I missed anything? I mean, yes, I know there are a large number of unmaintained CPAN distributions that no-one will get round to updating. But this post was aimed at active CPAN authors. If there’s anything else you think we should be doing, then please let me know in the comments.
The post RT – Action Plan for CPAN Authors appeared first on Perl Hacks.
Blog posts are like busses. You wait months for one and then two come along on consecutive days!
Yesterday I wrote about how we didn’t need a blogging platform for the Perl community – all we really needed was a good-looking feed aggregator. I mentioned Perlsphere as one such aggregator.
Then Matthew commented, saying that Perlsphere looked a bit broken as Dave Cantrell’s posts from a few years ago frequently pop up there as new posts. I had a quick look at the problem and couldn’t quite work out what was going on. His web feed seems valid, but Perlsphere didn’t seem to recognise the dates of the posts.
Perlsphere is implemented using Plagger, a feed aggregator written by Miyagawa a very long time ago (back when it seemed that web feeds were going to conquer the world). It’s a pretty complex beast and it seemed possible that somewhere deep in its code, it was mis-parsing Dave’s web feed. So I cloned the repo and tried to work out what was going on.
But Plagger hasn’t been updated for a very long time. As you can see from the test results, it stopped passing its tests a long while ago (I suspect when the current directory was removed from @INC). I spent a brief time trying to get it working but, ultimately, decided it was too hard a job.
So I took another look at Perlsphere. And I decided that if it’s based on bit-rotten software, it’s not going to be very easy to maintain (which gave me flashbacks to blogs.perl.org!)
But there’s another Perl tool for aggregating web feeds. And I wrote it. It’s called Perlanet (and, boy, do I regret that name now). Back in the first decade of this millennium, I was fascinated by web feeds and the idea of using them to build local “planets” – a web site that aggregated web feeds that had interesting information about your local area. Of course, that was back in the days when everything had a web feed and it was simple enough to pull them together and create really quite interesting sites. These days, of course, web feeds are rather unfashionable and almost no-one thinks to add them on to their web site.
However, they still cling to life in the world of blogging. Mainly, I suspect, because blogging platforms added them fifteen years ago and just haven’t bothered to remove them yet. And it’s blog posts that we’re interested in here – so we’re still in with a chance of building something useful.
And that’s what I did over lunch. I give you Planet Perl, a new site for aggregating Perl blogs.
Currently, it only has four blogs in the configuration. But the config file is on Github and I’ll be happy to get pull requests adding other blogs.
I hope you find it useful.
The post Down the rabbit hole appeared first on Perl Hacks.
I think it was at YAPC Copenhagen in 2008 that a small group of us first discussed the idea of building a shared blogging platform for the Perl community. It was over a year later that we launched blogs.perl.org.
I remember a lot of discussions over that time where we tried to thrash out exactly what we wanted to build. I know that one of my main drivers was that I wanted to replace the journals feature of use.perl. For those of you too young to remember, use.perl was a Perl community web site from the dawn of time. The site ran Perl news on its front page, but users could also have their own journal. For a few years, we had a nice little blogging community on the site. It used the same software as Slashdot and, like Slashdot, was looking pretty dated at the time. I remember being particularly disappointed that you couldn’t put images in a journal entry.
So that was certainly where I started from when planning blogs.perl.org. I wanted a modern blogging platform to replace use.perl. Other people wanted slightly different things. At least one person argued strongly that what we really needed was a nice-looking blog aggregator and that people could do their actual blogging on their own sites (or some other blog provider).
But, as you can see, that point of view lost out and we implemented a full blogging system using Movable Type.
Ten years on, I think that was a mistake. I think that having a community blogging platform for Perl is actively harmful to Perl.
I’ll explain why a bit later, but first let’s talk through a bit of more recent history of the site.
It’s well-known, I think, that the site is not is a good state. I’m happy to explain what happened there, but it’s a long and rather dull story. There have been a couple of attempts to build replacement systems but they both stalled before they were complete.
So we’re left in a situation where the site is broken and no-one really has the time or the expertise to fix it. And attempts to replace it seem doomed to failure.
Earlier this year I decided that the situation was untenable and that I wanted to close the site down. I spoke to Aaron and he pretty much agreed with me. We decided that we’d give people plenty of notice to take their blogging elsewhere and, rather than closing the site completely, we would make it read-only (so all the existing content would still be there). We ran the idea past the rest of the loose “management team” and Aristotle spoke up, saying that he would rather take the site over himself and try to improve matters. And that’s what happened. Over the last few months, Aaron and I have extricated ourselves from running the site and it’s all now handled by Aristotle.
I wish him all the best in those endeavours and really hope he manages to make the site better than it was (he’s already making great progress in removing loads of old spam blogs from the site).
But, really, I think that my original plan was a better idea. I don’t want people to blog about Perl on a Perl community site. I want people to blog about Perl on sites where people blog about other languages and technologies.
I’ve been giving talks about the need for the Perl community to break out of its echo chamber for almost as long as I’ve been part of the community. But I think it’s important. It’s a kind of low-key marketing. If you’re talking about your cool Perl project on a Perl community web site then only people who are looking for Perl articles will find it. But if you blog about it on a general programming web site then a) you’ll get a far bigger audience and b) some of that audience might say “oh! I never knew Perl could do that – perhaps I’ll give it a closer look.”
And that’s why I think blogs.perl.org (and, probably, use.perl before it) are harmful to Perl. It encourages Perl bloggers to blog for the Perl community – when it would be far better to get your blog posts in front of more people. Perl people will still read your Perl posts (through Perlsphere perhaps, or post the link to /r/perl or the Perl Community Facebook group) but other people will see them too. On blogs.perl.org, you’re pretty much guaranteed that only Perl programmers will see your posts.
To be honest, I don’t understand why people still use blogs.perl.org. Until Aristotle’s work bears fruit it’s painfully broken. What do you get that’s worth putting yourself through all of that pain? Why not just blog somewhere else and submit your web feed to Perlsphere? Or blog where other programmers blog – somewhere like dev.to, perhaps (I’ve started publishing my more technical blog posts there).
I think it will be great if Aristotle gets blogs.perl.org working well. I really want that to happen. But it would be even better if he didn’t have to. If people stopped using it; if they went off and started spreading their interesting Perl blog posts all over the web.
Break out of the echo chamber. Find yourself a bigger audience. Spread the word beyond the Perl community.
Or, alternatively, explain to me why it’s so vital that the Perl community has its own centralised blogging platform.
The post Blogging for Perl appeared first on Perl Hacks.
author: Mary Roach
name: David
average rating: 3.76
book published: 2008
rating: 0
read at:
date added: 2020/04/27
shelves: currently-reading
review:
author: Beth Buelow
name: David
average rating: 3.51
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)
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:
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.