Turn off tainting in brewed Perl.

I read that turning off tainting when building Perl can give you a speedup. Tainting also appears to be on the way out: it’s not needed for Mojolicious, for example. I brew my Perls so wondered how to do it. Some digging in the Perl distribution’s INSTALL file led me to a section on tainting. This suggested a flag. The next rabbit hole was how to get perlbrew to pass flags. Doing that and verifying with –verbose led me to:

perlbrew --verbose install perl-5.36.0 

And now some totally unscientific benchmarking using different Perl versions:

A simple benchmark suggested by David Farrell: https://www.perl.com/article/40/2013/9/29/How-to-benchmark-Perl-code-for-speed/

Perl-5.38.0 taint enabled:

equalsAssign: 11 wallclock secs 
(10.19 usr +  0.05 sys = 10.24 CPU) @ 200453.61/s (n=2052645)
shiftAssign: 10 wallclock secs 
(10.12 usr +  0.03 sys = 10.15 CPU) @ 202096.55/s (n=2051280)

Perl-5.38.0 taint disabled:

equalsAssign: 11 wallclock secs 
(10.52 usr +  0.02 sys = 10.54 CPU) @ 207983.40/s (n=2192145)
shiftAssign: 11 wallclock secs 
(10.51 usr +  0.01 sys = 10.52 CPU) @ 206375.10/s (n=2171066)
The code:

#!env perl

use strict;
use warnings;
use Benchmark qw/cmpthese timethese/;

timethese(-10, {
        shiftAssign => sub {    my @alphabet = ('A'..'Z');
                                for (my $i = 0; $i < 26; $i++){
                                    my $letter = shift @alphabet;
        equalsAssign => sub {   my @alphabet = ('A'..'Z');
                                for (my $i = 0; $i < 26; $i++){
                                    my $letter = $alphabet[$i];

So all-in-all about 10% in a handwaving kind of way.

Software anti-patterns

Python – Don’t be afraid of the dark

You may have an enormous ball of mud written in Perl but there are many benefits to introducing a new language like Python or Go:

  • The communities are vibrant
  • It’s easier to hire someone
  • They can do everything Perl can do

Documentation – Have some

  • Do not strip the comments from the code. That reminds me of WWII UK when signposts were removed to confuse the enemy.
  • Have documentation for each sub saying what the inputs are, the outputs and if you have a god object, what the side effects are.
  • Have documentation, preferably in POD in the code that reflects precisely what the code does. You can do lots with this. And test it.

Don’t have an overly complicated branching strategy

  • Don’t have a main branch that isn’t main/master.
  • Have a branch for each story.
  • Have branches for releases.
  • Do gitflow, it’s simple.

Jumphosts – They’re a PITA

  • Don’t be SO paranoid about security
  • Are you so locked down you have to ssh through a jumphost? And the jumphost won’t do ssh forwarding?
  • That breaks so much: no sshfs, no remote editing in your chainsaw of choice.
  • For bonus points, the dev machine can’t see the git repo. Please. I don’t like coding with a paper bag on my head.

CI on commit – Do it automatically

  • Once you have tests, run the CI pipeline when the code gets committed.
  • Preferably deploy (CD) that branch to the/a dev machine.
  • It exercises your deployment process. Remove a speed bump.
  • Deploy to dev and scheduled to test. It’s a computer: automate it.
  • Make friends with Docker. It makes life SO simple. Having laptops able to see the database is a BIG WIN.
  • Keep your dev database up to date.

No tests – a classic

  • Write your code so it’s testable. Don’t do everything through a God object. Have subs that have defined inputs and outputs.
  • When using Test::Perl::Critic::Progressive (or equivalent) to make sure your code isn’t getting worse, you’ll probably need to copy t/.perlcritic-history into and out of the artefact store between each run.
  • Can your CI machine see a test database? If not, you’re entering mocking hell.
  • Tests provide code examples. This is good.
  • Put the tests on a pre-commit git hook. Remember to chmod +x it.
  • Graph the progress if you can.

Damn you linux reference counting.

GitHub logoSo this was an hilarious case of reference counting.

There I was, developing my Perl Catalyst app. I migrate to gitlab like all the other cool kids. I move the original development directory to .bak like a good boy.

But, my plackup is still running and because reference counting, the open files are all still there so I was still happily running. I check out the gitlab version, make changes and NOTHING HAPPENS. Until finally the penny drops, I quit the original, now renamed directory and re-enter the correct one.

Suddenly everything works and hilarity ensues.

Please employ the bear to do something interesting!

So yet again, I spent time battling a legacy perl code base with no tests, no Jenkins/Bamboo, no deployment pipeline and half an agile process.

Now I get to do battle with recruiters again, something that fills my life with joy and purpose.

I thought I’d put my thoughts down as to what I’m looking for in a job.

First up, contract or permanent? That’s easy. I’ve been contracting for 18 years and I don’t see that changing UNLESS you have a really juicy CTO role on offer. More of that later. I think it’s just largely temperament. I like to have an independent, outside view, trying not to get absorbed in the local cargo cult. So there are two things I do.

Senior Perl developer.

My career can be best described as “careering from one thing to another”. If I’d had any sense, or career direction, or a mentor, I’d have stayed much more firmly in the CTO field. I’ve flirted with many startups over the years, but none have actually stuck. So what am I looking for in a perl gig? Here goes:

  • A modern framework. Give me Catalyst preferably, a framework standing on the shoulders of giants. Dancer or Mojolicious would work as well. Template Toolkit is the ideal templater.
  • Tests. It should be obvious, but often isn’t. If you write code without tests your code is immediately legacy.
  • A sane database schema. One that MySQL Workbench can reverse engineer into a pretty diagram. An ORM. There’s little point these days hard-coding SQL. That’s so passé. Give me DBIx::Class.
  • A well-run Agile process. I got my Scrum master certification and now “doing agile” as opposed to “being agile” brings me out in a rash. One purpose of agile is to get better and unless you do that, you’re not agile. Just standups and sprint planning don’t cut it.
  • Javascript I can take or leave, but it’s a given these days. I can do it but I’ll hate myself afterwards.
  • Don’t talk to me about web servers. Not my problem any more.
  • I want support infrastructure that’ been there since the beginning. That means Perl::Critic and perltidy. Pretty, clean code please.
  • Please let me please talk to REST APIs, none of that SOAP rubbish.


I’ve been a CTO. And interim a few times. Obviously I’d do it all completely differently this time, knowing what I know now.

  • Let me grow the team. I’ve had amazing luck in the past picking great teams. Indeed, a team that largely didn’t know perl and then became experts. I’ve also been involved in a firing. We’re still friends.
  • Let’s have all the tools we need: Atlassian (or equivalent) stack or integrated equivalent.
  • I want to buy in a good Agile coach for a few months to get us on the right track.
  • I want to manage upwards well. Demo the important stuff to the other directors and management at the end of every sprint. Respond to the business.
  • If you’re good, you can work from home. This is the 21st Century. Being forced to turn up to an office is one of my bugbears. You don’t need my physical presence. Skype and Slack will do the job.
  • Give me something exciting to lead. Not sure I could cope with another publisher web site.
  • Let me speak at conferences. Yes, I know I’m a straight, white male. It’s a burden. But I AM left handed! I’m a minority! It’s good for the company visibility.

And probably stacks more.

As an aside, any good personal projects worth chipping in to right now?