Running plenv 𝘢𝘯𝘥 perlbrew

So I just went to investigate switching from perlbrew to plenv.

This has failed before, because I run an old and grungy installation of Perl where I didn’t set up a local lib and just installed whatever without keeping records of which installed modules I need and which are just junk I tried for a few minutes. Unless I carry forward all that junk, I can’t switch perls without breaking all my local scripts – and I have better things to do.

Eventually I want to fix this situation, but no today on which it comes up has been the day for it so far.

Still, I do want to upgrade to 5.22 now that it’s out, and I’ve been wanting to switch to plenv for a while. What to do?

Uhm… *looks around*
ln -s ~/perl5/perlbrew/perls/perl-5.16.1 .plenv/versions/5.16.1
La la la… *walks away*

Yup, plenv global 5.16.1 is fine with that and a plenv rehash later, it works.

I threw out the rest of perlbrew, just kept the directory tree for the linked perl installation, and now I happily run this bastard/cuckoo setup. Teehee.

Now for installing 5.22 and making all my stuff work with it…

Plack::Middleware::SignedCookies

I released Plack::Middleware::SignedCookies some time ago because I went looking for it and came up empty. This is a middleware that signs outgoing cookies on the server with a HMAC digest and verifies the digest on incoming cookies. If a cookie doesn’t pass the signature test, it is dropped on the floor and your application never gets to see it.

There are several framework-specific plugins that do the same job, but I wanted to get rid of as much framework-specific code as possible.

One explicit design choice was to not handle expiration. Several of the plugins I saw do handle that themselves, and it certainly is useful for centralising all cookie policy in one place. However, expiration is almost certainly something you’ll want to handle at the application level, if only to vary the “not authorised” message you show the user. So there has to be a protocol to signal that a cookie was present but rejected because it was expired, and the application needs code implementing that protocol in order to react to expirations. This couples the application to the cookie policy code. Now that is fine when that is part of the framework, or a framework-specific component; it is not fine in a framework-agnostic Plack middleware. Leaving the expiration policy to the application means the application only needs to deal with the cookie interface provided by its framework: it is not coupled to the middleware.

Another choice I made in the spirit of “maybe YAGNI” – but which is likely a limitation – is that as of 1.103, SignedCookies doesn’t provide a way to pick which cookies to sign/verify. In a pinch, you can always use a middleware wrapped around it (such as an inline Rewrite rule, for convenience) to intercept and/or inject non-signed cookies outside of its purview. There is a likelihood that this will change in the future.

Anyway, have at it. Share and enjoy.

QA Hackathon 2015 (Berlin)

I was at the QA Hackathon in Berlin this year.

Everyone else writing about it has an introductory section about what it is, so I needn’t concern myself with one… as well we’re on blogs.perl.org here after all.

In a stupid move, I forced myself to constantly look for some other hacker to mooch power from – I left my own power supply at home. Fortunately as a semi-reluctant initiate to the Apple cult, I found plenty who were of the same hardware persuasion, whom I could bum some laptop juice of life from. I hope to not repeat this part.

But the main reason that I chose to be present at all was for the consensus discussions scheduled this year.

Today’s bit of black perl

use 5.010;
{
    package F;
    sub new { bless {}, shift }
    sub me { $_[0] = 'surprise!' }
}
my $f = F->new;
say $f;
$f->me;
say $f;

Output:

F=HASH(0x7f9daa025c80)
surprise!

Teehee…

Serializers for Perl: when to use what

This is a moderately edited (primarily rearranged) version of a comment on the Perl 5 issue tracker written by Yves Orton (demerphq). I thought it would be useful to a wider audience so I am reposting here with permission.

Note: this was written off the cuff and is not comprehensive. In correspondence, Yves noted that such an article could/should cover more formats, e.g. MsgPack.


I [feel strongly] that Data::Dumper is generally unsuitable as a serialization tool. The reasons are as follows: