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


- 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:

modules = Try::Tiny, Contextual::Return, IDNA::Punycode

And if you want to hint at recommendations for use:

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

Following up on the comments to my blog post on CPAN::Changes and CPAN::Changes::Spec, I created a fork of the distribution on Github and implemented a first shot for the author to evaluate. I sent the pull request yesterday, so now it will be interesting see whether it will be found useful at all.

I did a lot of thinking before starting the actual coding and I was not quite satisfied with the vocabulary I was using to describe the concept. Originally I referred to the concept as impact pointer, but it is simply misleading and not particularly descriptive. So when it occurred to me that the concept was actually hints on how the reader should view the changes and release described it came to me that the obvious name should be “update hint”.

Hints are everywhere and is the term is highly popular these days. Hints are less intrusive and in this case a much better description.

Here is an example lifted from the POD.

0.03 2010−08−01 − update recommended

− Fixed serious bug in bar method

0.02 2009−07−17 − update not required

− Added more foo() tests

0.01 2009−07−16

− Initial release

I decided for two values of the hint:

        - update recommended
        - update not required

The first for for releases, which address serious issues/bugs like security fixes, memory leaks etc. the second for releases which are housekeeping releases, updates to tests, documentation, build scripts etc.

As you can see there is no hint for the initial release. I do not want to impose my proposal on the existing specification as such and I well let it be up to the maintainer to decide whether it should be optional and what the actual values should be, my proposal works, but it just a proof of concept and in my opinion it is a nice concept I hope will be adopted.

Please feel free to evaluate my proposal for update hints in the CPAN::Changes::Spec and let me know what you think.

jonasbn, Copenhagen/Denmark

I have been using the Sublime Text 2 editor for some time now. Editors are a funny thing and over the years I have used quite a few different ones: pico, vi, vim, jEdit, BBEdit, TextMate, Komodo IDE and now Sublime Text. I like to have an armory of editors in my toolbox for different kinds of things. An editor for basic fast (right now) text editing, one for longer coding sessions and one for project development with several files of different types.

For a long time I was using a combination of Vim, BBEdit/TextMate and Komodo IDE for the different coding assignments under the circumstances I mentioned above. I later exchanged BBEdit for TextMate at some point and when I got CLI integration running for TextMate I slowly stopped using Vim. I still use the Komodo IDE, since the graphical debugger is a magnificent tool, one I simply cannot live without, but Komodo has longer startup time and is not well suited for short tasks unfortunately.

Hearing all the (b|f)uzz about Sublime Text intrigued me and made me want to check it out. I have read quite a few blog posts and I have watched several video tutorials – and they all say that when you start with Sublime Text you will not want to go back – yeah right!

I must however admit that I am impressed, the editor is flexible, easy to use, incredibly fast and responsive and it is really, really, really easy to customize.

Editors are the primary tool of most developers. Often we spend more time in editors editing code, than we actually do compiling or translating the actual source code. There are many opinions on editors, most developers have a favorite and in addition an opinion on the other developers favorite. Some are quite religious about their editor and mocking or talking about the other editors is not uncommon and most of you already know the funny diagram depicting learning curves for the most “popular” editors.


The depiction is funny, but as it is with most satiric fun, it comes with a grain of truth. I am not going to dig more into the above visualization since I will not attempt to visualize the learning curve of Sublime Text and because my opinion would be subjective and not as funny as the above examples, which I guess are all created with great love/hate to the editors mentioned. I think I can take liberty of writing love/hate since it is with most things you love you really hate when they let you down.

Getting back to Sublime Text I can only say that the editor is growing on me and I do not love it as such and it was not love at first sight since I actually just thought that it was just another editor, but Sublime Text continues to impress me and I feel like it gets better the more I use it and really feels like the editor for me. I do spend time coding, not as much as I would like to, since I am also using the Microsoft Word (editor) for a large part of my work, but luckily I get to do some coding and if not at work then at least when I am not at work.

When watching some Youtube tutorials I fell over the concept of Zen Coding, this was the idea of being able to write code with as few key stroke as possible (not like Perl golf), but getting productivity and speed up utilizing and maximizing you and your editors coding/typing capabilities. The demo for Sublime Text for HTML markup was really impressive and it got me thinking.

Sublime Text has a nice Perl integration, syntax highlighting, it builtin auto-completion can get you a long way and you can install plugins for integration with Perltidy and the plugin SublimeCodeIntel will extend this even further.

Inspired by the Zen Coding demonstration I thought CPAN has a log of APIs, so what would be the most useful ones to play around with for creating cool snippets for speeding up my Perl coding and then it occurred to me, that the modules and APIs I actually use the most are for implementing unit tests using Test::More and Test::Class, I do this across all my distributions and projects and both at home and at work.

So here is my first shot at snippets for Test::More and Test::Class available on Github for you to use with Sublime Text or fork you can fork them to suit your own needs. I am working on getting them made available via SublimeTexts Package control, which requires a pull request to a central repository of metadata, where I am still waiting for approval.

If you are in a situation where you feel like trying out a new editor, checkout Sublime Text, I have only tried version 2 and there is a version 3 on the way, I will not say that “it will not make you want to go back”, since my history of editors is long and proves the opposite and I expect it will continue to evolve, but I can promise you that it will be both fun and inspiring as you discover the nifty features and niceties which gives the sublime in Sublime Text.

Happy coding,

jonasbn, Copenhagen/Denmark

Today I have uploaded a new release of my Perl::Critic::logicLAB, it lists the two new policies I mentioned on earlier occasions in my blog.

- Perl::Critic::Policy::logicLAB::RequireParamsValidate
- Perl::Critic::Policy::logicLAB::RequirePackageNamePattern

Both released are released and maintained as separate distributions and Perl::Critic::logicLAB acts as a collection (Task::). RequirePackageNamePattern 0.01 was uploaded to CPAN about a month ago and RequireParamsValidate 0.01 was uploaded today together with Perl::Critic:.logicLAB 0.08.

I could have uploaded RequireParamsValidate earlier, but I decided to participate in the Questhub challenge of releasing a new CPAN distribution for every month for 2014 so I decided to stretch the releases for two months. Apparently I forgot to blog about the releases as nicely pointed out by the master questhubber and overall CPAN magician Neil Bowers, so here it is the public announcement of the two releases for January and February.

Their basic details have been fleshed out earlier so I am not going to go into details with the policies as such, but I do however want to address an issue that was raised in conjunction with the challenge on Questhub and that was the flooding of CPAN of new releases bringing no actual value (as I read it). This brings me back to my own contributions and the two mentioned policies.

It is really hard to come up with CPAN distributions that satisfy a greater audience, I for one do by no means satisfy needs other than my own, I would love to, but lets be honest, that is hard – I will get back to that later.

The same problem applies to Perl::Critic policies, coming up with original ones are not so easy as it sounds. But I write policies that my own scratch my own itch and I write policies to get accustomed to working with policies. And just as policies, Perl distributions serve many purposes and some are for getting your head around a specific problem area or improving your own workflow for working with a certain problem area.

A very positive thing in all this apart from the obvious reasons like learning something new, sharing your knowledge and sharing your techniques as open source benefits others – yes it might be annoying and it might be hard to find exactly the best suited module for addressing a certain problem, but my experience with CPAN tells me that the community part of CPAN will take care of that and you can always use trusted sources like the Intarwebs to find your way – what I really mean is that you can always go to you local Perl mongers group, IRC or places like StackOverflow to get guidance and pointers in the right direction and if all is lost – roll you own.

I have several distributions on CPAN, which are dead-ends, they should perhaps be deleted, they will persist on BackPAN, but I just have not gotten “around to it”. These distributions served a purpose at one time, I made errors and mistakes, I learned lessons and I improved as a Perl programmer, CPAN distribution maintainer and Open Source contributor.

Most of us can agree that trial and error is one of the best learning practices and practicing with CPAN distributions might be overkill for silly and personal experiments, but for a long time and still to some extent CPAN is the main repository for Perl code, yes we have Github and cpanm and we can do things differently, but CPAN is just a part of larger ecosystem and the questions you most hear often when you interact with the Perl community when people outline an idea, a concept or a project are:

  1. It is on CPAN?
  2. When will it be on CPAN?
  3. Will it be on CPAN?

(the order of the questions should be random, but for the sake of the beauty of the poetry in the questions the order here is arranged).

So CPAN is important for marketing and distributing your work and getting all the benefits of the community driven tool-chain. And to get back to a previous blog post on Perl and its role in the overall developer community, where it is often regarded as dead, every little contribution, every new distribution which is uploaded or updated on CPAN matters. Perl is alive because of CPAN (*1), because here everybody can play along and it is not so hard and it should not be hard to contribute. I recently migrated my Workflow distribution from SourceForge to Github, simply to easy the process of contributing and SourceForge and Github are important, but CPAN is the distribution channel.

And if you read the blog post I mentioned, the other languages to which Perl is compared their repositories are larger and they are growing and have outgrown CPAN and they are generating buzz, so there is absolutely no need to shut the castle gates and go all ivory over Perl – yes there will be lots of useless crap uploaded and I for one will be one of the contributors in to the (cr)App:: namespace (*2), but natural selection will sort it out and the best distributions will survive, long after there authors have stopped maintaining them, simply because of the community – and CPAN is the community, so when you contribute to CPAN you contribute the community.

It is hard to contribute with original stuff, it is hard to come up with original ideas and implementations that will rock the community. But everybody who has just touched product development, entrepreneurship know so. So until you ship that distribution, which will rock CPAN and get the Perl community all buzzing, because “you can get it on CPAN today” – code, share and learn.

I plan to upload 10 more new distributions this year, I have about 5 up my sleeve and I will run out of ideas just after summer with the current plan, but I am sure that using CPAN and interacting with the Perl community will give me additional ideas for contributions and this gives me a slight chance that I might be able to complete the challenge for 2014.

jonasbn, Copenhagen/Denmark

*1 Not solely, I do not want to forget all the people contributing to the Perl core, they are indeed keeping Perl alive, but in this context they will be mentioned in a footnote – sorry.

*2 This is just a pun, like “Captain of the USS Make-shit-up”, the App:: namespace is a fine a well respected namespace of which I am a happy user – thanks to its contributors

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:

The configuration of the plugin is pretty basic:


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:


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.


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


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


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

As I have mentioned on previous occasions in this blog, quests on Questhub can boost your productivity if you are into gamification. Another positive thing with doing quests on Questhub is that you actually learn something new.

So when I took the quest “Get 20 of my CPAN distributions to conform with the CPAN::Changes::Spec” it actually served several purposes.

  1. It raised the quality of 20 of my CPAN distributions by getting all my Changes files to adhere to a specified standard by using a uniform format
  2. I had fun
  3. I got to know a new module CPAN::Changes
  4. And I had fun

But it should not be a secret that this blog post also serves another more sinister purpose since I am currently on a new quest: “Blog about a module you are using”, but I would also like to reflect on the new stuff I learned and the new module I added to toolbox of modules I often use, namely CPAN::Changes.

Some time ago I collected my thoughts on communicating changes in my Wiki (the page has not been updated with the new stuff I learned, but it will be at some point).

In the page I describe my idea of the formatting of a Changes file and the idea of reverse chronological order. The formatting should contain bullet points on the single changes, the heading should be version number and date. And the reverse chronological order would serve for easier reading so you would always have the newest entry at the top (so you would save time to scroll down to the bottom).

In my opinion Changes communication and Changes files are very important, I very often consult Changes files for CPAN distributions and other packages of software when I want to see if and when a bug was fixed or a feature was introduced.

I was very happy to see that my view on Changes files formatting was very much in line with the CPAN::Changes::spec (part of CPAN::Changes) so the quest was not a tough one, but it required some work to get all of my distributions cleaned up, since the specification did formulate some more strict requirements.

So I picked up some new things:

  1. Dates should be uniform, the specification requires W3CDTF
  2. Keeping a uniform format means you can actually assert how wellformed a Changes file is

This would bring me to yet another module in my ever growing toolbox: Test::CPAN::Changes and its boilerplate.

        use Test::More;
        eval ‘use Test::CPAN::Changes’;
        plan skip_all => ‘Test::CPAN::Changes required for this test’ if $@;

Most of my CPAN distributions now have uniform Changes files adhering to the recommended standard and automated tests asserting this. I was actually only just able to get to 20 as specified by the quest, since some of my distributions where not in a state where I could easily get them in the bulk, but that is a different story and perhaps even another quest.

I can honestly recommend CPAN::Changes and Test::CPAN::Changes by BRICAS

There is however one thing I miss, a single thing I mention this in my wiki page and perhaps it should be a patch to CPAN::Changes::spec and Test::CPAN::Changes. It is what I refer to as the impact pointer. Is it nothing special, but I think when I heard about the concept I thought it was a really good idea.

The concept was not called impact pointer and I do not remember the exact wording, but I coined the term for use in my wiki page. Since I cannot remember where I heard it and how it was worded I still feel I should mention that I think it was INGY who mentioned the importance of the Changes file clearly communicating whether an update would be recommended with a certain release of a distribution of whether you could sit it over.

For now I do not want to conflict with the specification, so I try to remember to mention the impact pointer as the first bullet point under a release in a Changes file and I try to always try to categorize my releases into one of 4 categories:

  • Initial releases, it would be nice to get somebody to use and evaluate the release, so impact indicator is not so beneficial, but one could communicate, state of release, like alpha/beta/experimental/developer etc. – some of this can be communicated in the version number, but human readable terms can be nice to the untrained eye
  • Maintenance releases, house-keeping release, stuff like adding boilerplate code for testing and asserting your Changes file, indicating often that an update is not necessary
  • Bug fix releases, can be serious so the impact indicator is important, often it indicates that an update is recommended, often based on the severity of the bugs addressed
  • Feature releases, often updates are not required, but it would be nice to get somebody to use and evaluate the release, like an initial release

So in addition to the recommendations to your toolbox I want to recommend adding clean and concise information on whether an update is required/recommended/unnecessary – this really can save your users a lot of time.

It felt good to complete the original quest and it does feel good to write this blog post and complete yet another quest, but so much other stuff seems to go on the TODO list, like creating a POC for the impact indicator for CPAN::Changes::spec, updating my wiki page and getting the rest of my CPAN distributions addressed so they also adhere with the recommended standard.

Just before christmas I received a bug report for my Perl::Critic policy: Perl::Critic::Policy::logicLAB::ProhibitShellDispatch.
The policy was motivated and implemented to avoid calls to platform specific utilities etc. At a certain point I was involved in migrating a rather large code base from Solaris to Linux and then we really got bitten by this.
The recommendation is to use pure-perl tools where available. An example of this I had observed earlier was calls to hostname like so:

    my $hostname = qx/hostname/;
my $hostname = `hostname`;

These can easily be exchanged by use of the CPAN distribution Net::Domain and you can possibly find other such examples (please let me know of these, since I am always on the lookout for more examples).

A pretty basic problem area and a very simple implementation.

Now back to the bug report.

The initial policy was one of my first and the code was pretty basic and I did expect it to hold some issues, but since the problem area was so basic I did not know what to expect.
The issue reported was a false-positive for Net::OpenSSH‘s system method. The issue demonstrated that the code was way too simple and I had to rewrite the internals. The policy simply evaluated PPI::Token::Word‘s (and some others), but I had to extend the policy to evaluate the context of the words and hence look at the involved statement as a whole.
So all in all a somewhat hard to fix bug, since the policy was perhaps broken by design. But at the same time, the policy is better now and I think it addresses some other cases I do not know about, with the improved implementation.
Considering the value provided by the bug report and can only welcome bug reports and emphasize the importance of reporting bug and requesting features etc. and if I was afraid of bug reports, the policy would never have been released in the first place.
The distribution is now on Github, but this does not mean you have to fork and create a pull request – you can always just contact me, but you are most welcome to use the open repository.

jonasbn, Copenhagen
(cross-posted from

Just having read was must be the annual piece in Dr. Dobbs on the state of programming languages entitled: “The Rise and Fall of Programming Languages”, it was with some concern I observed my local minicpan mirror reports being seriously reduced in size.

From January 9th.

authors/01mailrc.txt.gz … updated
modules/02packages.details.txt.gz … updated
modules/ … updated
authors/id/J/JI/JIMI/Statistics-Reproducibility-0.04.tar.gz … updated
authors/id/J/JI/JIMI/CHECKSUMS … updated
authors/id/J/JI/JIMI/Statistics-TheilSenEstimator-0.04.tar.gz … updated
authors/id/L/LT/LTP/Audio-Play-MPlayer-0.05.tar.gz … updated
authors/id/L/LT/LTP/CHECKSUMS … updated
authors/id/O/OV/OVNTATAR/GitHub-Jobs-0.05.tar.gz … updated
authors/id/O/OV/OVNTATAR/CHECKSUMS … updated
authors/id/S/SE/SEKIA/Algorithm-LibLinear-0.09.tar.gz … updated
authors/id/S/SE/SEKIA/CHECKSUMS … updated
authors/id/T/TH/THALJEF/Pinto-0.097.tar.gz 500 read timeout
authors/id/V/VT/VTI/Attribute-Contract-0.05.tar.gz … updated
authors/id/V/VT/VTI/CHECKSUMS … up to date
authors/id/Y/YT/YTURTLE/Nephia-Setup-Plugin-Assets-Bootstrap-0.04.tar.gz … updated
authors/id/Y/YT/YTURTLE/CHECKSUMS … updated
cleaning /Users/jonasbn/.minicpan/authors/id/J/JI/JIMI/Statistics-Reproducibility-0.03.tar.gz …done
cleaning /Users/jonasbn/.minicpan/authors/id/L/LT/LTP/Audio-Play-MPlayer-0.04.tar.gz …done
cleaning /Users/jonasbn/.minicpan/authors/id/O/OV/OVNTATAR/GitHub-Jobs-0.04.tar.gz …done
cleaning /Users/jonasbn/.minicpan/authors/id/R/RW/RWSTAUNER/Dist-Zilla-Plugin-CPANChangesTests-1.002.tar.gz …done
cleaning /Users/jonasbn/.minicpan/authors/id/R/RW/RWSTAUNER/Dist-Zilla-Plugin-PodLinkTests-1.006.tar.gz …done
cleaning /Users/jonasbn/.minicpan/authors/id/T/TH/THALJEF/Pinto-0.096.tar.gz …done
cleaning /Users/jonasbn/.minicpan/authors/id/Y/YT/YTURTLE/Nephia-Setup-Plugin-Assets-Bootstrap-0.03.tar.gz …done

From January 10th.

authors/01mailrc.txt.gz … updated
modules/02packages.details.txt.gz … updated
modules/ … updated
authors/id/T/TH/THALJEF/Pinto-0.097.tar.gz … updated
authors/id/T/TH/THALJEF/CHECKSUMS … updated

With some horror I thought that the prophecies were coming true? – Perl is dying?

As always Perl is declared dead or dying and in this article Perl is mentioned explicitly. I always take these articles with a grain of salt. I write Perl on a daily basis and I am really busy, so I do not consider Perl dead. The article however did not only list the always problematic TIOBE index, but also Ohloh. I actually considered Ohloh dead (sorry, we should not go around considering things dead), but still it hurt since I love Perl and I worry that Perl dies at little every time this is mentioned, so writing the blog post is probably not a good idea at all – since I might be assisting in fulfilling a prophecy.

Anyway – visiting Ohloh, I found out that all of my CPAN contributions listed there had b0rken links to repositories. I have just migrated a large part of my repositories from a hosted Subversion solution, so I quickly ran through all my projects and updated the repository links.

I know that my small contributions are insignificant, but at least I could flag that my CPAN contributions are out there, they are being somewhat actively maintained, as I wrote I am busy, so open source activities are not always on the top of my TODO for whatever little CPU time I have available.

Then the minicpan reports started coming in, in normal size and when I read Perl Weekly issue #129 and discovered that PAUSE had had issues I felt relieved, fear leads to … yoda yada yada.

Tiobe and Ohloh might be statistics trying to say something about how Perl is doing compared to other languages, but judging by the number of updated modules coming to PAUSE (CPAN) on a daily basis, a lot of active development is actually going on.

I did a swift comparison of some package repositories (numbers from the time of writing).

Perl (CPAN): 28.992 distributions (
Ruby: (rubygems): 68.915 gems (
Python (PyPI): 38.887 packages (
PHP (PEAR): 595 packages (

I cannot conclude anything from these numbers, since they say more about the communities and the concept of code distribution and packaging. A statistic from github would perhaps be more interesting. Gabor Szabo wrote a blog post mentioning another blog post on the topic. Here PHP is actually doing quite well compared to Perl.

So taking a step back and looking at the statistics on all the languages I am thrilled to see the sheer number of different programming languages represented on Github (20). That is awesome. I love Perl and I love programming, so seeing how many open source projects and languages are available makes me happy. And it seems that no matter what the statistics say there is still and always room for Perl as a language.

So a note to self is “do not believe in statistics and prophecies”, even though my name is Jonas

But if you however want to play the statistics game on the Perl team, you could do the following:

- join the Questhub quest of releasing a new Perl distribution every month
- put your Perl projects on Github
- mention your projects on Ohloh

Have a nice and productive day programming in whatever language that solves your problem the best.

jonasbn, Copenhagen

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:

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

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



^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

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

About this blog

This blog acts as a channel for communicating logicLAB’s open source activities. Announcements on open source initiatives, involvements and releases of open source distributions of software products, projects and applications.


  • » Blog Archive » Some Modules I’m Looking At Currently: [...] learned of this module from this blog post, and am both intrigued and frustrated. Intrigued, b [...]
  • jonasbn: The Test::More package has been added to SublimeText's package control. So the installation proce [...]
  • jonasbn: Hello Stas, I am just a software developer blogging about stuff that interests me like computer p [...]
  • Stas Ustimenko: Hi. We would like to add review of our free PHP IDE - Codelobster PHP Edition http://www.codelo [...]
  • jonasbn: Just a brief note, on twitter the new editor 'Atom' is generating a lot of (f|b)uzz: http://daily [...]


April 2014
« Mar