Programming

WWW::Mechanize Best Practices

published on
fields Recently at $work we were discussing some of the behaviours of WWW::Mechanize when submitting forms. For instance, when you pass the fields parameter to the submit_form() method, Mechanize might take a very lax approach to submitting your data. Imagine the following form: Now take the following code: Mechanize will happily post all of these fields to the form for you, even though the form doesn’t contain an input with the field “C”. Read More...

My “Go for Perl Hackers” Cheatsheet

published on
Last year I found myself working on some Go code at $work. When I’m trying to pick up constructs in a new language, I find it helpful to see how I would have done the same things in Perl. This sheet is far from complete, but I think it’s already helpful. You can find it at https://github.com/oalders/go-for-perl-hackers. Comments, critique and pull requests are welcome. I’ve already had some helpful feedback via Twitter which I’ve incorporated. Read More...

New defaults for Perl Linting in Vim’s Ale Plugin

published on
In my previous post, I talked about using Ale with vim for linting and syntax checking. Since that time, the Ale defaults for Perl have changed. Perl::Critic checks are still on by default, but you will need to enable the syntax and compile checks that are run via the `perl` binary itself. The reasoning for the new default is described in the Ale docs. If you want to (re-)enable your Perl checks, you can follow the example in my dot files. Read More...

vim, Ale, Syntastic and Perl::Critic

published on
As a vim user, I’ve used Syntastic for a long time. It’s a great tool for syntax checking. However, I was recently introduced to Ale. Ale does a lot of what Syntastic does, but it does it asynchronously. The practical benefits are You should experience less lag when editing large files Ale flags problematic lines containing errors and warnings in a gutter, making it easy to find problems Detailed information about errors and warnings appear at the bottom of your buffer I may actually be underselling it. Read More...

How I Spent my Perl Toolchain Summit 2017

published on
This was my 5th year of being invited to participate in the Perl Tool Chain Summit (formerly Perl QA Hackathon). It was a real pleasure to be invited to a rebranded version of the same helpful event. Our Sponsors This event would not have been possible without our sponsors. Let me take a moment to thank: Booking.com ActiveState cPanel FastMail MaxMind Perl Careers MongoDB SureVoIP Campus Explorer Bytemark CAPSiDE Charlie Gonzalez Elastic OpusVL Perl Services Procura XS4ALL Oetiker+Partner Overview For the second year in a row, MetaCPAN was well represented at the event. Read More...

Viewing Your Module Permissions on MetaCPAN

published on
We’re currently at the Perl Toolchain Summit in Lyon, working hard on improving MetaCPAN. One feature which we went live with yesterday is a view on CPAN module permissions. This means that you can now easily see which modules any CPAN author has permission to upload. If you want to see every module which Neil Bowers has permissions on, you can go to https://metacpan.org/permission/author/NEILB. You can get to this page via the module permissions link on the left sidebar of a MetaCPAN author page. Read More...

Getting to Travis and GitHub Pages Quickly

published on
Disclaimer: I’m sure this functionality exists elsewhere, but this was a fun little thing for me to work on. Also, you’ll need a minimum of git 2.7 for this to work. Often, when I’m working locally I like to bounce right over to a GitHub repository url to check something. I ended up writing a bit of code to make this easier. While I was at it, I decided it would be nice to have the same thing for Travis URLs. Read More...

Don’t Forget about URI::Heuristic

published on
Imagine you’ve got some user input that is supposed to be a valid URL, but it’s user input, so you can’t be sure of anything. It’s not very consistent data, so you at least make sure to prepend a default scheme to it. It’s a fairly common case. Sometimes I see it solved this way: This converts example.com to http://example.com, but it can be error prone. For instance, what if I forgot to make the regex case insensitive? Read More...