author: Alice Roberts
name: David
average rating: 3.89
book published: 2015
rating: 0
read at:
date added: 2019/01/14
shelves: currently-reading
review:

Dave Cross posted a photo:

via Instagram bit.ly/2Ro7UXz

Dave Cross posted a photo:

via Instagram bit.ly/2CiXEFN

Dave Cross posted a photo:

via Instagram bit.ly/2M77CP4

Earlier this week, I saw this code being recommended on Stack Overflow. The code contains a nasty, but rather subtle bug. The version I saw has been fixed now, but I thought there were some interesting lessons to learn by looking at the problems in some detail.

Let’s start by working out what the bug is. Here’s the code:

open my $fh, '<', $file
  || die "Can't open '$file': $!";

On first glance, it seems fine. It uses the common “open or die” idiom. It uses the modern approach of using a lexical filehandle. It even uses the three-argument version of “open()”. Code like has appeared in huge numbers of Perl programs for years. What can possibly be the problem?

I’ll give you a couple of minutes to have a closer look and work out what you think the problem is.

[ … time passes … ]

So what do you think? Do you see what the problem is?

The problem is that there is no error checking.

“What do you mean, Dave?” I hear you say. “There’s error checking there – I can see it plainly.” Some of you might even be wondering if I’m going senile.

And, yes, it certainly looks like it checks for errors. But the error checking doesn’t work. Let me prove that to you. We can check it with a simple command line program.

$ perl -e'open my $fh, "<", "not.there" || die $!'
$

You would expect to see the “die” message there. But it doesn’t appear. Ok, perhaps I’m lying. Perhaps I really do have a file called “not.there”. Let’s try another, slightly different, version of the code.

$ perl -e'open(my $fh, "<", "not.there") || die $!'
No such file or directory at -e line 1.

And there we see the error message. That file really doesn’t exist.

So what went wrong with the first version? Of course, a good way to start working that out is to compare the two versions and look at the differences between them. The difference here is that when I put parentheses around the parameters to “open()” it started working. And when you fix things by adding parentheses it’s a pretty sure bet that the problem comes down to precedence.

The order of precedence for Perl operators is listed in perldoc perlop. If you look at that list you’ll see that the “or” operator we used (“||”) is at position 16 on the list. But what other operators are we using in our code? The answer is lurking down at position 21 on the list. When we call a Perl built-in function without using parentheses around the parameters, it’s known as a list operator. And list operators have rather low precedence.

All of which means that our original code is actually parsed as if we had written it like this:

open my $fh, '<', ($file
  || die "Can't open '$file': $!");

Notice the parentheses that have appeared around $file and (crucially) the whole “or die” clause. That means that the bracketed expression is evaluated and passed to “open()” as its third argument. And when Perl evaluates that expression, it does that clever “Boolean short-circuiting” thing. An expression of “A || B” evaluates A first and if that is true, it returns it. Only if A is false will it go on to evaluate B and return that. In our case, the filename will always be true (well, unless you have a file called “0”) so the second half of the expression (the “or die…” bit) is never evaluated and, effectively, ignored.

Which is why I said, back at the start, that this code has no error checking at all – that’s literally true as the error checking has no effect at all.

So how do we fix it? Well, we’ve already seen one approach – you can explicitly add parentheses around the arguments to “open()”. But Perl programmers don’t like to use unnecessary punctuation and I’m sure I’ve seen this written without parentheses, so how does that work?

If you take another look at the table of operator precedence and look down below the list operators, you’ll see another “or” operator (the one that’s actually the word “or”, rather than punctuation). It’s right at the bottom of the list – at position 24. And that means we can use that version without needing the parentheses around the parameters to “open()”.

open my $fh, '<', $file
  or die "Can't open '$file': $!";

And that’s the version that you’ll see in most codebases. But, as we’ve seen, it’s vitally important to use the correct version of the “or” operator.

The worst thing about this bug is that it appears at the worst time. If your file exists and you can open it successfully, then everything works fine. Things only go wrong when… well, when things go wrong. If you can’t open your file for some reason, you won’t know about it. Which is bad.

So it’s important to test that your code works correctly when things go wrong. And that’s why we have modules like Test::Exception. You could write a test program like this:

use strict;
use warnings;
use Test::More;
use Test::Exception;

dies_ok {
  open my $fh, '<', 'not.there'
    || die $!;
};

done_testing;

And it would fail every time. But if you switched to the other “or” operator, it will work.

There’s one other approach you can take. You can use autodie in your code and just forget about adding “or die” to any of your calls to “open()”.

use autodie 'open';

# Dies if the open fails
open my $fh, '<', $file;

This is an easy bug to introduce into your code and a hard one to track down. Who’s confident that it doesn’t appear in any of their code?

The post A Subtle Bug appeared first on Perl Hacks.

Dave Cross posted a photo:

via Instagram bit.ly/2SHiS7a

Dave Cross posted a photo:

via Instagram bit.ly/2sbLhGV

It’s the last day of 2018, and I know I’m not going to a gig tonight, so that sounds like a very good time for my annual review of the gigs I’ve seen this year.

Songkick tells me that I saw 35 gigs in 2018. That’s the lowest number since I’ve been counting them. It’s even one fewer than 2012 when I had the excuse of having my leg in plaster for six months. I’m not sure why the number is so low. Perhaps I’m getting pickier about what I see.

Let’s start by talking about a few of the disappointments. I don’t know what I was expecting when I booked to see Kristin Hersh, but she didn’t deliver and I left just after she sang “Your Ghost”. I was similarly disappointed by The Primitives – I left after a few songs and didn’t even wait to hear “Crash”. But easily the worst show I saw this year was Tiffany. Yes, I know. I admit it was a bit of a gamble. But when I wondered aloud on Twitter about seeing the show, Tiffany replied, so I felt it was rude not to go. I lasted three songs before leaving.

On the other hand, here (in chronological order) are my ten favourite gigs of the year.

• Superorganism at Oval Space. If there’s any justice in the world, this will be one of those gigs that people claim to have been at. But only a few hundred of us were. If you haven’t heard Superorganism’s album, then I suggest you give it a listen. And then try to see them live as soon as you can.
• Lily Allen at the Dome. I’ve seen Lily Allen at the Brixton Academy before and she was pretty good. But I wasn’t going to miss the chance to see her in a small venue like this. It didn’t matter that most of the set was made up of her new album – she was great.
• Arcade Fire at Wembley Arena. Not many bands can persuade me to visit the soulless box that is Wembley Arena. But I’m glad I made an exception for Arcade Fire. They were (as always) sensational.
• Florence + the Machine at the Royal Festival Hall. I’m not a huge Florence fan but when she announced this sudden gig at the South Bank, I jumped at the chance to see her again. Through the magic of my South Bank membership, I got a front-row seat and loved every minute of the show.
• Pale Waves at Heaven. I saw Pale Waves twice this year, but I think the smaller show at Heaven just trumped the bigger show I saw later in the year at the Shepherd’s Bush Empire. I’m looking forward to seeing them again soon.
• David Byrne at the Hammersmith Odeon. It’s one of my great disappointments that I never saw Talking Heads live. This was my second time seeing David Byrne (the first time, he was playing with St Vincent) and this show was absolutely amazing. He did it again later in the year at the O2 Arena, so I’m glad I saw it in a smaller venue.
• The Cure at the Royal Festival Hall. This wasn’t billed as the Cure (for contractual reasons, I think) but everyone knew that’s what Robert Smith was planning. This was an incredible, chronological journey through the band’s music.
• Amanda Palmer at the Queen’s Hall. It’s been a couple of years since Amanda Palmer made this list and it’s great to report she’s back on top form. These shows at the Edinburgh Festival were a prototype for a tour she’s planning to take around the world over the next two years. I suggest you try really hard not to miss it. (I’ve just remembered that I saw her earlier in the year too – but that show is not on Songkick as it was a private event for her Patreon supporters. That was awesome too.)
• Soft Cell at the O2 Arena. I never saw Soft Cell when they were first around and I walked out of a Marc Almond show a couple of years ago. But there was no chance I’d miss this. Even the O2 couldn’t suck the life out of a Soft Cell show.
• All Saints at the Hammersmith Odeon. A little bit of cheese to end the year. All Saints were a bit of a guilty pleasure twenty years ago and they’re still a lot of fun these days.

Although I saw fewer shows this year, they must have been of higher quality than usual. I can’t believe that Sunflower Bean (who I saw twice), the Art of Noise, Belle and Sebastian or Heaven 17 didn’t make the top ten. Even Yes were far better than I’ve ever seen them before.

So that was 2018. I already have some interesting things lined up for 2019 – a Tears For Fears show that was postponed from this year, Chvrches (for what seems the first time for far too long), ABC and Nick Mason playing some old Pink Floyd numbers are among the tickets I’ve already bought. I also have ticket to see the Buzzcocks for the first time, but I’m not sure if that will still go ahead following the death of Pete Shelley.

What about you? What did you enjoy seeing live this year?

 

The post 2018 in Gigs appeared first on Davblog.

Last Saturday was the London Perl Workshop and (as has become traditional), I’m going to tell you how much fun it was so that you feel jealous that you missed it and make more of an effort to come along next year.

This year was slightly different for me. For various reasons, I didn’t have the time to propose and prepare any talks for the workshop so (for the first time ever) I decided I’d just go to the workshop and not give any talks. It very nearly worked too.

I arrived at about 9am, checked in at the registration desk and collected my free t-shirt. Then I went upstairs to the main lecture theatre to see Julian giving the organisers’ welcome talk. Julian is a new member of the organising committee, having only moved to London in the last year. But he’s certainly thrown himself into the community.

Following the welcome talk, I stayed in the main room to hear Léon Brocard explaining what’s new in the world of HTTP. It seems the HTTP3 is just around the corner and while it’s a lot more complicated than previous versions it has the potential to make the web a lot faster. I stayed in the same room to hear Martin Berends talking about Cucumber. I’ve been meaning to look at Cucumber in more detail for some years – perhaps this talk will be the prod I need.

Things were running a little late in the main room by this point, so I was a little late getting to Simon Proctor‘s 24 uses for Perl6‎. I try to get to at least one Perl 6 talk at every conference I go to. And this time, I was galvanised enough to buy a copy of Learning Perl 6 for my Kindle.

I caught up with a few friends over the coffee break and then headed back to the main room to see Saif Ahmed explaining Quick and Dirty GUI Applications (and why you should make them)‎. This was nostalgic for me. Almost twenty years ago at an OSCON in California, I remember a long, drunken night when some of us sketched out a plan to build a framework-agnostic GUI toolkit for Perl (like a DBI for GUIs). I think we gave up when we realised we would need to call it “PUI”. Anyway, it seems that Saif (who was keen to make it very clear that he’s not a professional programmer) has written such a tool.

After that I went to see my former colleague Andrew Solomon talking about ‎HOWTO: grow the Perl team‎. The talk was based around his experiences helping various companies training up Perl programmers using his Geek Uni site.

And then it was lunchtime. I met up with a few other former London Perl Mongers leaders and we had some very nice pizzas just over the road from the workshop venue. Over lunch, we claimed to be preparing for our afternoon panel discussion – but really we were mainly just reminiscing.

After lunch, it was back to the main room to see Peter Allan’s talk on Security Checks using perlcritic‎ and Tom Hukins on Contrarian Perl‎. Both talks were the kind of thing that really makes you think. Peter’s talk introduced some interesting ideas about pushing perlcritic further than it is usually pushed. And Tom pointed out that in order to write the best code possible, you might need to move beyond the generally accepted “industry standards”.

After that, there was a brief visit to a different room to hear Mohammed Anwar talking about The power of mentoring‎. Mohammed is another recent newcomer to the Perl community and, like Julien, he is certainly making a difference.

I skipped the coffee break and went back to the main room to prepare for the one session that I had been roped into contributing to – ‎”I’m a Former London.PM Leader – Ask Me Anything”‎. We had gathered together as many of the former London Perl Mongers leaders and we took questions from the audience about the past, present and future of the group. I was slightly worried that it might tip over into nostalgic self-indulgence, but several people later told me that they had really enjoyed it.

Then it was time for the lightning talks (which were as varied and entertaining as always) and Julien’s “thank-you” talk. Like last year, the post-conference started in the venue before moving on to a pub. I stayed for an hour or so, chatting to friends, before making my way home.

As always, I’d like to thank all of the organisers, speakers, sponsors and attendees for making the workshop as successful as it (always!) is.

Here’s a list of those sponsors. They’re nice companies:

• Eligo
• Perl Careers
• CV-Library
• Adestra
• Broadbean Technology
• Oleeo
• Opus VL
• Adzuna
• Perl 6 Community
• Geekuni

Hope to see you at next years workshop.

The post London Perl Workshop 2018 appeared first on Perl Hacks.

Earlier this week, the Perl magazine site, perl.com, published an article about writing web applications using CGI.pm. That seemed like a bizarre choice to me, but I’ve decided to use it as an excuse to write an article explaining why I think that’s a really bad idea.

It’s important to start by getting some definitions straight – as, often, I see people conflating two or three of these concepts and it always confuses the discussion.

• The Common Gateway Interface (CGI) is a protocol which defines one way that you can write applications that create dynamic web pages. CGI defines the interface between a web server and a computer program which generates a dynamic page.
• A CGI program is a computer program that is written in a manner that conforms to the CGI specification. The program optionally reads input from its environment and then prints to STDOUT a stream of data representing a dynamic web page. Such programs can be (and have been!) written in pretty much any programming language.
• CGI.pm is a CPAN module which makes it easier to write CGI programs in Perl. The module was included in the Perl core distribution from Perl 5.004 (in 1997) until it was removed from Perl 5.22 (in 2015).

A Brief Introduction to CGI.pm

CGI.pm basically contained two sets of functions. One for input and one for output. There was a set for reading data that was passed into the program (the most commonly used one of these was param()) and a set for producing output to send to the browser. Most of these were functions which created HTML elements like <h1> or <p>. By about 2002, most people seemed to have worked out that these HTML creation functions were a bad idea and had switched to using a templating engine instead. One output function that remained useful was header() which gave the programmer an easy way to create the various headers required in an HTTP response – most commonly the “Content-type” header.

For at least the last ten years that I was using CGI.pm, my programs included the line:

use CGI qw(param header);

as it was only the param() and header() functions that I used.

I should also point out that there are two different “modes” that you can use the module in. There’s an object-oriented mode (create an object with CGI->new and interact with it through methods) and a function-based mode (just call functions that are exported by the module). As I never needed more than one CGI object in a program, I always just used the function-based interface.

Why Shouldn’t We Use CGI.pm Today?

If you’re using CGI.pm in the way I mentioned above (using it as a wrapper around the CGI protocol and ignoring the HTML generation functions), then it’s not actually a terrible way to write simple web applications. There are two problems with it:

1. CGI programs are slow. They start up a Perl process for each request to the CGI URL. This is, of course, a problem with the CGI protocol itself, not the CGI.pm module. This might not be much of a problem if you have a low-traffic application that you want to put on the web.
2. CGI.pm gives you no help building more complicated features in a web application. For example, there’s no built-in support for request routing. If your application needs to control a number of URLs, then you either end up with a separate CGI program for each URL or you shoe-horn them all into the same program and set up some far-too-clever mod_rewrite magic. And everyone reinvents the same wheels.

Basically, there are better ways to write web applications in Perl these days. It was removed from the Perl code distribution in 2015 because people didn’t want to encourage people to use an outdated technology.

What are these better methods? Well, anything based on an improved gateway interface specification called the Perl Server Gateway Interface (PSGI). That could be a web framework like Dancer2, Catalyst or Web::Simple or you could even just use raw PSGI (by using the toolkit in the Plack distribution).

Often when I suggest this to people, they think that the PSGI approach is going to be far more complex than just whipping up a quick CGI program. And it’s easy to see why they might think that. All too often, an introduction to PSGI starts by building a relatively powerful (and, therefore, complicated) web application using Catalyst. And while Catalyst is a fine web framework, it’s not the simplest way to write a basic web application.

But it doesn’t need to be that way. You can write PSGI programs in “raw PGSI” without reaching for a framework. Sure, you’ll still have the problems listed in my point two above, but when you want to address that, you can start looking at the various web frameworks. Even so, you’ll have three big benefits from moving to PSGI.

The Benefits of PSGI

As I see it, there are three huge benefits that you get from PSGI.

Software Ecosystem

The standard PSGI toolkit is called Plack. You’ll need to install that. That will give you adapters enabling you to use PSGI programs in pretty much any web deployment environment. It also includes a large number of plugins and extensions (often called “middleware”) for PSGI. All of this software can be added to your application really simply. And any bits of your program that you don’t have to write is always a big advantage.

Testing and Debugging

How do you test your CGI program? Probably, you use something like Selenium (or, perhaps, just LWP) to fire requests at the server and see what results you get back.

And how about debugging any problems that your testing finds? All too often, the debugging that I see is warn() statements written to the web server error log. Actually, when answering questions on StackOverflow, often the poster has no idea where to find the error log and we need to resort to something like use CGI::Carp 'fatalsToBrowser', which isn’t exactly elegant.

A PSGI application is just a subroutine. So it’s trivial for testing tools to call the subroutine with the correct parameters. This makes testing PSGI programs really easy (and all of the tools to do this are part of the Plack distribution I mentioned above). Similarly, there are tools debugging a PSGI program far easier than the equivalent CGI program.

Deployment Flexibility

This, to me, is the big one. I talked earlier about the performance problems that the CGI environment leads to. You have a CGI program that is only used by a few people on your internal network. And that’s fine. The second or so it takes to respond to each request isn’t a problem. But it proves useful and before you know it, many more people start to use it. And then someone suggests publishing it to external users too. The one-second responses stretch to five or ten seconds, or even longer and you start getting complaints about the system. You know you should move it to a persistent environment like FastCGI or mod_perl, but that would require large-scale changes to the code and how are you ever going to find the time for that?

With a PSGI application, things are different. You can start by deploying your PSGI code in a CGI environment if you like (although, to be honest, it seems that very few people do that). Then when you need to make it faster, you can move it to FastCGI or mod_perl. Or you can run it as a standalone web service and configure your web proxy to redirect requests to it. Usually, you’ll be able to use exactly the same code in all of these environments.

In Conclusion

I know why people still write CGI programs. And I know why people still write them using CGI.pm – it’s what people know. It’s seen as the easy option. It’s what twenty-five years of web tutorials are telling them to do.

But in 2018 (and, to be honest, for most of the last ten years) that’s simply not the best approach to take. There are more powerful and more flexible options available.

Please don’t write code using CGI.pm. And please don’t write tutorials encouraging people to do that.

The post Please Don’t Use CGI.pm appeared first on Perl Hacks.

author: Chris Barbour
name: David
average rating: 3.67
book published: 2015
rating: 0
read at:
date added: 2018/10/17
shelves: currently-reading
review: