When I write replies to questions on StackOverflow and places like that recommending that people abandon CGI programs in favour of something that uses PSGI, I often get some push-back from people claiming that PSGI makes things far too complicated.

I don’t believe that’s true. But I think I know why they say it. I think they say it because most of the time when we say “you should really port that code to PSGI” we follow up with links to Dancer, Catalyst or Mojolicious tutorials.

I know why we do that. I know that a web framework is usually going to make writing a web app far simpler. And, yes, I know that in the Plack::Request documentation, Miyagawa explicitly says:

Note that this module is intended to be used by Plack middleware developers and web application framework developers rather than application developers (end users).

Writing your web application directly using Plack::Request is certainly possible but not recommended: it’s like doing so with mod_perl’s Apache::Request: yet too low level.

If you’re writing a web application, not a framework, then you’re encouraged to use one of the web application frameworks that support PSGI (http://plackperl.org/#frameworks), or see modules like HTTP::Engine to provide higher level Request and Response API on top of PSGI.

And, in general, I agree with him wholeheartedly. But I think that when we’re trying to persuade people to switch to PSGI, these suggestions can get in the way. People see switching their grungy old CGI programs to a web framework as a big job. I don’t think it’s as scary as they might think, but I agree it’s often a non-trivial task.

Even without using a web framework, I think that you can get benefits from moving software to PSGI. When I’m running training courses on PSGI, I emphasise three advantages that PSGI gives you over other Perl web development environments.

  1. PSGI applications are easier to debug and test.
  2. PSGI applications can be deployed in any environment you want without changing a line of code.
  3. Plack Middleware

And I think that you can benefit from all of these features pretty easily, without moving to a framework. I’ve been thinking about the best way to do this and I think I’ve come up with a simple plan:

  • Change your shebang line to /usr/bin/plackup (or equivalent)
  • Put all of your code inside my $app = sub { ... }
  • Switch to using Plack::Request to access all of your input parameters
  • Build up your response output in a variable
  • At the end of the code, create and return the required Plack response (either using Plack::Response or just creating the correct array reference).

That’s all you need. You can drop your new program into your cgi-bin directory and it will just start working. You can immediately benefit from easier testing and later on, you can easily deploy your application in a different environment or start adding in middleware.

As an experiment to find how easy this was, I’ve been porting some old CGI programs. Back in 2000, I wrote three articles introducing CGI programming for Linux Format. I’ve gone back to those articles and converted the CGI programs to PSGI (well, so far I’ve done the programs from the first two articles – I’ll finish the last one in the next day or so, I hope).

It’s not the nicest of code. I was still using the CGI’s HTML generation functions back then. I’ve replaced those calls with HTML::Tiny. And they aren’t very complicated programs at all (they were aimed at complete beginners). But I hope they’ll be a useful guide to how easy it is to start using PSGI.

My programs are on Github. Please let me know what you think.

If you’re interested in modern Perl Web Development Techniques, you might find it useful to attend my upcoming two-day course on the subject.

Update: On Twitter, Miyagawa reminds me that you can use CGI::Emulate::PSGI or CGI::PSGI to run CGI programs under PSGI without changing them at all (or, at least, changing them a lot less than I’m suggesting here). And that’s what I’d probably do if I had a large amount of CGI code that I wanted to to move to PSGI quickly. But I still think it’s worth showing people that simple PSGI programs really aren’t any more complicated than simple CGI programs.

London Perl Workshop Review

(Photo by Mark Keating)

Last Saturday was the annual London Perl Workshop. And, as always, it was a great opportunity to soak up the generosity, good humour and all-round-awesomeness of the European Perl community. I say “European” as the LPW doesn’t just get visitors from London or the UK. There are many people who attend regularly from all over Europe. And, actually, from further afield – there are usually two or three Americans there.

I arrived at about twenty to nine, which gave me just enough time to register and say hello to a couple of people before heading to the main room for Mark Keating’s welcome. Mark hinted that with next year’s workshop being the tenth that he will have organised, he is starting to wonder if it’s time for someone else to take over. More on that later.

I then had a quick dash back down to the basement where I was running a course on Modern Web Development with Perl. It seemed to go well, people seemed engaged and asked some interesting questions. Oh, and my timing was spot on to let my class out two minutes early so that they were at the front of the queue for the free cakes (courtesy of Exonetric). That’s just my little trick for getting slightly higher marks in the feedback survey.

After the coffee break I was in the smaller lecture theatre for three interesting talks – Neil Bowers on Boosting community engagement with CPAN‎ (and, yes, I’ve finally got round to signing up for the CPAN Pull Request Challenge), Smylers on Code Interface Mistakes to Avoid‎ and Neil Bowers (again) on ‎Dependencies and the River of CPAN‎ which was an interesting discussion on how the way you maintain a CPAN module should change as it becomes more important to more people.

Then it was lunch, which I spent in the University cafeteria catching up with friends.

After lunch, I saw Léon Brocard on Making your website seem faster, followed by Steve’s Man Publishing Pint, which turned out to be about publishing ebooks to Amazon easily – something which I’ve been very interested in recently.

The schedule was in a bit of a state of flux, so I missed Andrew Solomon’s talk on How to grow a Perl team‎ and instead saw Steve Mynott talking about Perl 6 Grammars. Following that, I gave my talk on Conference Driven Publishing (which is part apology for not writing the book I promised to write at the last LPW and part attempt to get more people writing and publishing ebooks about Perl).

Then there was another coffee break which I spent getting all the latest gossip from some former colleagues. We got so caught up in it that I was slightly late for Theo van Hoesel’s talk Dancer2 REST assured. I like Theo’s ideas but (as I’ve told him face to face) I would like to see a far simpler interface.

Next up was the keynote. Liz Mattijsen stood in for Jonathan Worthington (who had to cancel at the last minute) and she explained the history of her involvement in Perl and how she was drawn to working on Perl 6. She finished with a brief overview of some interesting Perl 6 features.

Then there were the lightning talks which were their usual mixture of useful, thought-provoking and insane.

Mark Keating closed the conference by thanking everyone for their work, their sponsorship and their attendance. He returned to the theme of perhaps passing on the organisation of the workshop to someone new. No-one, I think, can fail to be incredibly grateful for the effort that Mark has put into organising the last nine workshops and it makes complete sense to me that he can’t maintain that level of effort forever. So it makes sense to start looking for someone else to take over organising the workshop in the future. And, given the complexity of the task, it would be sensible if that person got involved as soon as possible so that we could have a smooth transition during the organisation of next year’s event.

If you’re interested in becoming a major hero to the European Perl community, then please get in touch with Mark.

There was no planned post-workshop event this year. So we broke up into smaller groups and probably colonised most of central London. Personally, I gathered a few friends and wandered off to my favourite restaurant in Chinatown.

I can only repeat what Mark said as he closed the workshop and give my thanks to all of the organisers, volunteers, speakers, sponsors and attendees. There’s little doubt in my mind that the LPW is, year after year, one of the best grass-roots-organised events in the European geek calendar. And this year’s was as good as any.

The Long Death of CGI.pm

CGI.pm has been removed from the core Perl distribution. From 5.22, it is no longer included in a standard Perl installation.

There are good technical reasons for this. CGI is a dying technology. In 2015, there are far better ways to write web applications in Perl. We don’t want to be seen to encourage the use of a technology which no-one should be using.

This does lead to a small problem for us though. There are plenty of web hosting providers out there who don’t have particularly strong Perl support. They will advertise that they support Perl, but that’s just because they know that Perl comes as a standard part of the operating system that they run on their servers. They won’t do anything to change their installation in any way. Neither you nor I would use a hosting company that works like that – but plenty of people do.

The problem comes when these companies start to deploy an operating system that includes Perl 5.22. All of a sudden, those companies will stop including CGI.pm on their servers. And while we don’t want to encourage people to use CGI.pm (or, indeed, the CGI protocol itself) we need to accept that there are thousands of sites out there that have been happily using software based on CGI.pm for years and the owners of these sites will at some point change hosting providers or upgrade their service plan and end up on a server that has Perl 5.22 and doesn’t have CGI.pm. And their software will break.

I’ve always assumed that this problem is some time in the future. As far as I can see, the only mainstream Linux distribution that currently includes Perl 5.22 is Fedora 23. And you’d need to be pretty stupid to run a web hosting business on any version of Fedora. Fedora is a cutting edge distribution with no long term support. Versions of Fedora are only supported for about a year after their release.

So the problem is in the future, but it is coming. At some point Perl 5.22 or one of its successors will make it into Red Hat Enterprise Linux. And at that point we have a problem.

Or so I thought. But that’s not the case. The problem is here already. Not because of Perl 5.22 (that’s still a year or two in the future for most of these web hosting companies) but because of Red Hat.

Red Hat, like pretty much everyone, include Perl in their standard installation. If you install any Linux distribution based on Red Hat, then the out of the box installation includes an RPM called “perl”. But it’s not really what you would recognise as Perl. It’s a cut down version of Perl. They have stripped out many parts of Perl that they consider non-essential. And those parts include CGI.pm.

This change in the way they package Perl started with RHEL 6 – which comes with Perl 5.10. And remember it’s not just RHEL that is affected. There are plenty of other distributions that use RHEL as a base – Centos, Scientific Linux, Cloud Linux and many, many more.

So if someone uses a server running RHEL 6 or greater (or another OS that is based on RHEL 6 or greater) and the hosting company have not taken appropriate action, then that server will not have CGI.pm installed.

What is the “appropriate action” you ask. Well it’s pretty simple. Red Hat also make another RPM available that contains the whole Perl distribution. So bringing the Perl up to scratch on a RHEL host is as simple as running:

yum install perl-core

That will work on a server running RHEL 6 (which has Perl 5.10) and RHEL 7 (which has Perl 5.16). On a future version of RHEL which includes Perl 5.22 or later, that obviously won’t work as CGI.pm won’t be part of the standard Perl installation and therefore won’t be included in “perl-core”. At that point it will still be a good idea to install “perl-core” (to get the rest of the installation that you are missing) but to get CGI.pm, you’ll need to run:

yum install perl-CGI

So this is a plea to people who are running web hosting services using Red Hat style Linux distributions. Please ensure that your servers are running a complete Perl installation by running the “yum” command above.

All of which brings me to this blog post that Marc Lehmann wrote a couple of days ago. Marc found a web site which no longer worked because it had been moved to a new server which had a newer version of Perl – one that didn’t include CGI.pm. Marc thinks that the Perl 5 Porters have adopted a cavalier approach to backward compatibility and that the removal of CGI.pm is a good example of the problems they are causing. He therefore chose to interpret the problems this site was having as being caused by p5p’s approach to backward compatibility and the removal of CGI.pm.

This sounded unlikely to me. As I said above, it would be surprising if any web hosting company was using 5.22 at this point. So, I did a little digging. I found that the site was hosted by BlackNight solutions and that their web says that their servers run Perl 5.8. At the same time, Lee Johnson, the current maintainer of CGI.pm, got in touch with the web site’s owner who confirmed what I had worked out was correct.

Later yesterday I had a conversation with @BlackNight on Twitter. They told me that their hosts all ran Cloud Linux (which is based on RHEL) and that new servers were being provisioned using Cloud Linux 6 (which is based on RHEL 6).

So it seems clear what has happened here. The site was running on an older server which was running Cloud Linux 5. That includes Perl 5.8 and predates Red Hat removing CGI.pm from the “perl” RPM. It then moved to a new host running Cloud Linux 6 which is based on RHEL 6 and doesn’t include CGI.pm in the default installation. So what the site’s owner said is true, he moved to a new host with a newer version of Perl (that new version of Perl was 5.10!) but it wasn’t the new version of Perl that caused the problems, it was the new version of the operating system or, more specifically, the change in  the way that Red Hat (and its derivatives) packaged Perl.

Marc is right that when Perl 5.22 hits the web hosting industry we’ll lose CGI.pm from a lot a web servers. You can make your own mind up on how important that is and whether or not you share Marc’s other opinions on how p5p is steering Perl. But he’s wrong to assume that, in this instance, the problem was caused by anything that p5p have done. In this instance, the problem was caused by Red Hat’s Perl packaging policy and was compounded by a hosting company who didn’t know that upgrading their servers to Cloud Linux 6 would remove CGI.pm.

RHEL 6 was released five years ago. I suspect it’s pretty mainstream in the web hosting industry by now. So CGI.pm will already have disappeared from a large number of web servers. I wonder why we haven’t seen a tsunami of complaints?

Update: More discussion on Reddit and Hacker News.

LPW Slides

A more detailed write-up of the LPW will follow in the next few days. But in the meantime, here are the slides to the three talks I gave.



London Perl Workshop 2015

This time next week we will all be enjoying the London Perl Workshop. I thought it was worth looking at what the day has in store.

As always (well, except that one time when they had no power) the LPW will take place at the Cavendish Campus of the University of Westminster. I’m told there are exams or something like that taking place on the same day, so it’s important to follow the signs when you get there or you might end up in the wrong place being forced to take an exam.

The workshop starts at 9am, but registration queues can be quite long, so I’d recommend getting there half an hour or so earlier than that. If you get lucky and register quickly, then why not look for an organiser and volunteer to help out for a while.

You’ll want to be in the main room for the welcome address at 9am – just in case there’s any important news about the day. But the talks start at 9:10.

My ‎Modern Perl Web Development‎ course starts then. Hopefully it will be in my usual classroom. Alteratively, Andrew Solomon’s Crash course on Perl, the Universe and Everything‎ starts at the same time and goes on much longer. Or you might want to see some shorter courses. If I wasn’t running my training, I’d want to see Tom Hukins talking about ‎Escaping Insanity‎ and Rick Deller on Developing Your Brand – from a job seeker , Business to sole contractor/consultant‎ – he assures me that his slides are no longer the shocking pink he has used in previous years.

At 11:00 there’s a coffee break sponsored by Evozon. My training finishes at that point, so I’m free to see a few talks. Unfortunately, I want to see all of the talks in the next slot. I suspect I’ll end up seeing Neil Bowers’ Boosting community engagement with CPAN‎ and Smylers’ ‎Don’t Do That: Code Interface Mistakes to Avoid‎, but I could well be tempted into Aaron Crane’s Write-once data: writing Perl like Haskell‎ instead. Or, back on the workshop track, there’s Dominic Humphries on From can to can’t: An intro to functional programming. Just before lunch, I think I’ll see Neil Bowers again. This time he’s talking about Dependencies and the River of CPAN.

After lunch there’s another session where I want to see everything. I’d love to see Stevan Little talking about his latest iteration of the p5-mop, but I suspect I’ll end up seeing Leon Brocard on Making your website seem faster‎ followed by Kaitlyn Parkhurst on Project Management For The Solo Developer. Dominic’s functional programming workshop continues after lunch and is joined by John Davies and Martin Berends talking about Parallel Processing Performed Properly in Perl on Pi‎.

The big talk after the next short break is going to be Matt Trout on A decade of dubious decisions‎ but it’s another I’ll miss as I’m talking about Conference Driven Publishing‎ in another room during the second half of it. During the first half I’d recommend Steve Mynott’s Perl 6 Grammars‎.  But, I saw him practice it at a recent London Perl Mongers technical meeting, so I’ll be seeing Andrew Solomon explaining How to grow a Perl team‎. In the workshop stream, Christian Jaeger will be covering Functional Programming on Perl‎.

Then there’s another coffee break (this time sponsored by Perl Careers) and then we’re into the last few sessions. In the first you have a choice between Jeff Goff on From Regular Expressions to Parsing JavaScript: Learn Perl6 Grammars‎ and Theo van Hoesel on ‎Dancer2 REST assured‎. I think I’ll be in Theo’s talk.

These are followed by Jonathan Worthington’s keynote – The end of the beginning‎ and the lightning talks. It will, no doubt, be a great end to a fabulous day.

The London Perl Workshop is always a great day a learning about Perl and catching up with old friends. And because of the brilliant sponsors, it doesn’t cost the attendees a penny.

If you’re going to be near London next weekend and you have any interest in Perl, then why not register and come along?

Here’s a brief video of last year’s workshop.