August 2014 marked the 19th anniversary of the amazing resource that is the Perl cpan. Node developers already know why cpan is so cool, they have npm which is a very similar tool.
cpan for those who don't know is the online collection of modules for Perl. These are the components you use when for example you want to connect to Facebook or Twitter. Rather than writing all the code to handle connecting and authenticating and then posting to twitter or facebook; you can simply install a module from facebook and away you go!
So for me as a person that makes a living currently from writing Perl code and relying on cpan to provide the linkages between what I want to achieve and the technical elements I need to use.
One of my early experiences was writing a interface layer between a windows application and some robotic hardware interfaces. The initial code implementation was done with TCP sockets with adhoc commication. Later in the project it was decided to use XML to format the communications; this was a pretty big change and could have been a nightmare, but with Perl is was really use a case of using a XML library from cpan. It was really a simple change (much quicker and easier than it was for the .net developers working on the other side).
As a Perl guy, I know and love the cpan and cpanday was something I wanted to support in some small way. I have had a cpan upload account for a longtime but never had something I wanted to upload. But somewhere I heard that one suggestion for cpan day was to upload something to cpan… so I decided that was what I would do.
But what to wrote and upload?
This was easy, I had been joking with a work colleague for a while about writing a Perl::Critic policy to prevent his use of Perlserets in the corporate code base. I even added it on (the written in perl) questhub.io site.
So this was the project I started last week: https://metacpan.org/release/Perl-Critic-Policy-Perlsecret
Now, I have never written a Perlcritic policy before, or contributed to cpan, so I did what any good perl developer would do; I stole!
I did some googling and looked at some other policies.
One that caught my eye was Perl::Critic::Policy::ValuesAndExpressions::PreventSQLInjection, which has it's code on GitHub. Including having tests on Travis-CI. So I checked out a copy of it and then used this as the starting point for my module.
So I created a git repo https://github.com/lancew/Perl-Critic-Policy-Perlsecret and used the files from the PreventSQLInjection as the basics for my module. I started by striping out and replacing names and files that I needed or didn't need.
The next step was to get the integration to Travis-CI working. Travis-CI allows you to run your test suite on a variety of Perl version without having to do it yourself. It took a while but after some misteps I had https://travis-ci.org/lancew/Perl-Critic-Policy-Perlsecret up and running including the button in the readme in the Gitgub repo. Next I did the same for Coveralls, which provides test coverage for reports: https://coveralls.io/r/lancew/Perl-Critic-Policy-Perlsecret?branch=master
It then got a bit interesting, I had some issues getting the pre-requisite modules working on my laptop. But interestingly, the travis-ci build worked nicely (mainly as I copied the setup). So I did have a working test environment (four in fact). Luckily, I wanted to approach this little project in a Test Driven Development (TDD) style. So I made the decision to stop wasting time fixing up my local environment and trying to put together a dev VM etc and decided to simply use the tools I had already setup.
My decision was simply to write my changes to github, then let the automated testing take place on Travis-ci and react accordingly.
So I got started, I looked at Perlsecret and wrote a test for the first entry, the "Venus Operator". I pushed it to Github and looked at Travis-CI and as expected, it was red (fail). Then I wrote the code to detect a Venus operator and pushed that. Travis-CI turned green as the test I wrote now started passing as my code detected the Venus operator.
Then I continued with each of the operators, with the same process:
* Write a test.
* Test fails
* Write code
* Test passes
* Repeat
So after some days of working evenings on it and some of Saturday (cpan day) 16th. I had a completed Policy with tests built and passing tests. Time to upload to cpan.
This again is something I have not done before, so more googling. It seemes I needed a TGZ to upload via the web interface. Now, if you remember; I said my actual local build was not working. So I could not actually build locally. But a couple of references talked about being able to upload direct from Github; so this is what I would attempt. Thankfully a very handy PerlMonks thread has all the details I needed… well almost. 😉
So I created a release, the only trick being I needed to name it just right "Perl-Critic-Policy-Perlsecret-0.0.1". That done it was really as easy as pointing CPAN at the github release url.
Done!!
It took 30-40 minutes before it was easily found on cpan metacpan etc but there it was/is, online and available for anyone to use. By morning it got even better, the massive cpan testers community had picked up the module and I had passing tests on Windows, Linux, Mac, BSD etc. Now as I write this (a day later) I see that the testing has continued and I even have some failures, something to look into already.
Now the one confession I have is that I have not actually used my shiny new module on anything at all! My plan is to try it Monday on the corporate codebase as a test. I know I have written a pretty naive module, pretty sure it will detect errors even if in comments (a false positive).
Also, it's probably a policy nobody will use, but that was not the point. The point was to do it, to wrote something and submit it to cpan on cpan day.
The result of cpan day was pretty impressive. 775 uploads from 107 people. Mine was one of 10 from new contributors.
You can read about it over at http://blogs.perl.org/users/neilb/2014/ … e-1st.html
For me it was a worthy use of my time, I make a living from writing perl and I was happy to be able to contribute a little something to the community that I have enjoyed being a part of on and off for such a long while.
It was also a good technical challenge and I got some "deliberate practice" in. I developed the code in a pure TDD style, this has meant that when I got to the end, the tests were already in place and I have confidence in it working; and the cpan testers successes show that it passes on a wide variety of platforms.
I have also learnt how to upload to cpan, the requirements and the methodology.
So for me, the inaugural CPAN day was a good experience and I am pleased to have participated in my own small way. I hope next year for the 20th anniversary that the community does even more and I will I think attend (or perhaps even organise) some form of hackday to celebrate with.
Thanks Perl, you've been great!
Lance
Categories: Uncategorised
