New logicLAB Policy for Perl::Critic Policy: ModuleBlacklist

From the MOTIVATION section in the POD of this new policy:

I once read an article which compared programming languages to natural languages. Programming languages in themselves are not large as such, but if you also regard the APIs, data structures and components a computer programmer use on a daily basis, the amount is enormous.

Where I work We try to keep a more simple code base, the complexity is in our business and that is our primary problem area, so it should not be difficult to understand the code used to model this complexity.

So sometimes it is necessary to make a decision on what should be allowed in our code base and what should not. This policy aims to support this coding standard.

This sounds fairly unproblematic and peaceful, but there is a more sinister motivation behind the implementation as well.

After long debugging sessions at the most inconvenient times involving a small set of modules, which causes me too many problems – I decided to write this policy.

Over the cause of time and working in a growing team, we have a constantly growing code base and many takes on how to accomplish things and solving problems. Constantly our code base is breaking and new bugs are introduced and this is all okay and a pretty natural part of software development.

Developers are great!

– They add value
– They add code
– They fix stuff
– They build stuff

But…

– They introduce bugs
– They implement security holes
– They add code
– They break stuff

So sometimes that have to be regulated.

We use peer reviews, not to the extent we should, but we do try and aim try to have this is a part of our SDLC (Software Development Life Cycle). Sometimes we tend to discuss the somethings over and over and perhaps at some point we decide to adjust our coding policy to accommodate the outcome.

My thesis is a that we should use Perl::Critic and Perl::Tidy to enforce our coding standard to the extent possible so peer reviews can focus and can be provide maximum value and we can discuss business, value, security and discover new anti-patterns/patterns, instead of discussing old hat.

So when a certain issue has been observed on more that one occasion, write a policy to enforce a regulation against to address it.

This policy can help you to enforce a regulation when you want to prohibit use of certain modules or even when you want to recommend alternatives.

So if you want to specify a list of blacklisted modules:

[logicLAB::ModuleBlacklist]
modules = Try::Tiny, Contextual::Return, IDNA::Punycode

And if you want to hint at recommendations for use:

[logicLAB::ModuleBlacklist]
modules = Try::Tiny => TryCatch, Contextual::Return, IDNA::Punycode => Net::IDN::Encode

Please note that this is the first shot at the policy, feedback and suggestions most welcome (Github).

Happy regulating,

jonasbn, Copenhagen

Advertisements
New logicLAB Policy for Perl::Critic Policy: ModuleBlacklist

Nordic Perl Workshop 2013

The Nordic Perl Workshop for 2013 is just over. I had promised myself to write a blog post up to the event, but organization, $job and life took what little time I had.

The event was hosted by my employer DK Hostmaster and took place in Copenhagen and I was involved in the organizing.

With a varied one-track schedule, with talks on topic like: Hadoop, Prima, Carton, SVG, natural language processing, Perl 6, Postgres, Mojolicious and Websockets the workshop provided a nice platform to learn, reflect and socialize.

It was nice to see old friends and make new friends and everything went really well. I did two lightning talks on Perl::Critic (peer/code review) and Mojolicious and REST. I planned to do a follow-up on my Jenkins talk, with some updates on perlbrew, but I dod not have the time to get it prepared.

One presentation which I found really interesting was Tatsuhikos Miyagawas presentation on Carton. Carton is a bundler handling CPAN dependencies and it is most impressive and together with cpanm and App::scan_prereqs_cpanfile (by TOKUHIROM) it is a serious contribution to the Perl toolchain.

When I get my notes processed, I will do a brief write-up of my reflection of Carton. I am going to evaluate possible use of Carton at my place of work and it could be what we need to get our deployment process really rolling.

Make sure to crowdsource or follow the Lanyard site if you want to access more information on the Nordic Perl Workshop 2013.

Next years workshop will be in Helsinki, Finland – hope to see you there.

Nordic Perl Workshop 2013