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

CPAN Release Task::Jenkins 0.05

I have just released Task::Jenkins 0.05 to CPAN (meta).

This is a feature release and it now included Devel::Cover::Report::Clover which is a report formatter for Devel::Cover, which can generate Clover reports consumable Devel::Cover reports in Jenkins using the Clover Plugin.

This does as such not replace the HTML Publisher Plugin integration I normally recommend but it does provide the Jenkins use with a graphical overview of the coverage metrics.

An example:

clover-2014-01-29-15-49.png
The configuration of the plugin is pretty basic:

clover-conf-2014-01-29-15-49.png

We specify where we want the report to be and in our actually integration test step we add the following:

#create Devel::Cover report
./Build testcover

#create clover report from Devel::Cover using #Devel::Cover::Report::Clover
./cover -report clover -outputdir clover

In addition I generate the HTML reports and these are then accessible via clicking the graphical coverage report (please see my Wiki page on Continuous Integration for Perl using Jenkins).

#create html report from Devel::Cover::Report::Html
./cover -report html -outputdir clover && \
mv clover/coverage.html clover/index.html

This reports already exist since they are generated by Devel::Cover by default so perhaps a copy of these from cover_db can be done, but this was the first shot – or is strikes me I could just tell the clover report generation to output to
cover_db/ – this has to be tried out.

The rename of coverage.html to index.html is however unavoidable AFAIK to support the integration with the plugin.

This is really swell, BUT WAIT there is more…

This next part is not currently a part of Task::Jenkins, but I do mention it in the POD distributed with Task::Jenkins from this release and it might go in in the future. It was pointed out to be that a Jenkins plugin exists to visualize Perl::Critic reports, it is called Violations (thanks mil for the tips on plugins).

It is somewhat more tricky to set up. Lets start with the configuration:

violations-conf-2014-01-29-15-49.png

You start by pointing to perlcritic.txt, this file should contain output from a Perl::Critic run.

The plugin simply parses output from Perl::Critic. So you have to add a step to generate this file, which should contain something a long the lines of this:

./perlcritic –brutal –verbose 5 –profile \
t/perlcriticrc lib t > perlcritic.txt

I run with the highest severity since I just want a report of everything. I point to the perlcritic resource file following the distribution (also under version control), but I overwrite severity using –brutal and output format using the verbosity flag.

It is quite important to output in format 4 or 5 since only these are supported by the plugin. I normally prefer format 8 since it makes it easy to copy-paste the policy name into a perlcriticrc file.

With format five you get also the filenames and you redirect it into the text file.
Then you will get the following graph for you build.

violations-2014-01-29-15-49.png

And when you click the graph you get the following detailed view:

violations-detailed-2014-01-29-15-49.png

You can see violations, violations by severity, trends and by clicking the filenames you get even more in-depth information.

violations-detailed-file-2014-01-29-15-49.png

My Wiki page on Continuous Integration for Perl using Jenkins will be updated soon with all of these findings and other tips and goodies.

Please let me know if you experience issues or have other tips I could benefit from.

Continued happy integration!

jonasbn, logicLAB

CPAN Release Task::Jenkins 0.05

Yet Another New Perl::Critic policy in the pipeline: RequirePackageNamePattern

I have written up a first working version of yet another Perl::Critic policy, also this policy suggestion is highly experimental.

The policy assists in enforcing a package/module/class naming strategy, so if you prefer to have your modules names follow a certain pattern this policy could be of interest to you.

If you do not configure the policy it does not do anything. You can however configure it with as many patterns as you would like:

Patterns could look as follows:

^Acme # if you want all of you modules to start with Acme
Acme # if you want all of your modules to contain the work Acme
Acme$ # if you want all of you modules to end with Acme

For now you can only specify global patterns, but I was considering looking into the ability to specify different patterns for different directories:

Names
lib = <pattern1> || <pattern2>
t = <pattern1> || <pattern3>

And creating more complex patterns would also be great, like:

^Acme.*Test$

or:

^Acme && Test$

In addition the policy has the following configurable parameters:

– debug (for debugging)

– exempt_programs, so scripts etc. are not evaluated, these can however be of interest if you use inline packages

The motivation is to use the policy as a part of a coding standard for use at my work place, but I have developed it in my spare time since I wanted to contribute it to CPAN and as for my other policies I would like too use it on my own open source code base to begin with.

I will pack it up and push it to CPAN in a few days, but you are welcome to check it out on Github, please note that the policy is by no means done and much work remains.

jonasbn, logicLAB

Yet Another New Perl::Critic policy in the pipeline: RequirePackageNamePattern

New Perl::Critic policy in the pipeline: RequireParamsValidate

Inspired by my fellow hackers attending the Nordic Perl Workshop, I took the time to sit down (I was actually attending the Internetdagarna conference in Stockholm) and wrote up a first working version, so for now I consider this policy suggestion highly experimental.

The policy evaluates Perl subroutines for the presence of use of Params::Validate. It currently only evaluates public facing APIs, meaning subroutines prefixed with ‘_’ (private by convention) are ignored. This will be made configurable later.

I have run some basic tests and found one funny thing – the implementation itself does not comply with what the policy enforces and encourages.

The motivation is to use the policy as a part of a coding standard for a larger project on which I am embarking soon, but I would like too use it on my own code base to begin with.

I will pack it up and push it to CPAN within a few days, but you are welcome to check it out on Github.

jonasbn, logicLAB

New Perl::Critic policy in the pipeline: RequireParamsValidate

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

CPAN Release Perl::Critic::logicLAB 0.04 and 0.05

I have just uploaded Perl::Critic::logicLAB 0.05 to CPAN. I did not announce the release of 0.04 due to time constraints and since it was released during Easter I thought I could just as well announce them together.

The two releases introduces two new policies of mine:

The two policies focus on addressing interaction in, which your Perl components are working. Extending on the path that was set out with the release of Perl::Critic::Policy::logicLAB::ProhibitUseLib

Both new policies are simple policies, but hopefully useful. They are already giving me good feedback and value being put to use on a Continues Integration platform Jenkins.

All should be available on CPAN by now, both as individual distributions, but also as part of the Perl::Critic::logicLAB bundle mentioned here.

Feedback and patches most welcome,

jonasbn, Copenhagen

CPAN Release Perl::Critic::logicLAB 0.04 and 0.05

CPAN Release Perl::Critic::logicLAB 0.01 and policies

After a long time I finally got my own Perl::Critic policies released and uploaded to CPAN.

I have created a Task implementation bundle listing my two own policies for now (I expect to add other policies used later on). This gives you the opportunity to download the policies by themselves if they look like something you would like to use or you can even bundle them yourself with other policies you make use of.

This packaging is an experiment and is not the recommended way and so it might change in the future, so let me know if you have any feedback on the packaging, both if you are using Perl::Critic::logicLAB or the actual policies directly.

The policies which have also just been released and currently listed in Perl::Critic::logicLAB are:

Both are simple policies, but hopefully useful.

All should be available on CPAN by now.

jonasbn, Copenhagen

CPAN Release Perl::Critic::logicLAB 0.01 and policies