I have just revived a lot of my CPAN distributions after they where stranded in migration. One these distributions is Date::Holidays a wrapper/adapter to modules in the Date::Holidays namespace and related. Since development started up again I have made several releases and I am on a quest to get all of the RTs/issues out of the way.

Some release history:

0.19 2014.08.27 bug fix release, update not required (see below)

– This release addressed reports on failing tests for perl 5.21
The use in this distribution of UNIVERSAL is now deprecated,
see: Github issue [#3] and [RT:98337]

0.18 2014.08.24 feature release, update not required

– Added adapter class for Date::Holidays::BR [RT:63437]

0.17 2014.08.22 maintenance release, update not required

– Migrated from Module::Build to Dist::Zilla

– Fixed issue in some test, which would break if Date::Holidays::DK
was not installed

0.16 2014.08.18 maintenance release, update not required

– Fixed POD error

– Aligned all version numbers

– Added t/kwalitee.t Test::Kwalitee test

– Added t/changes.t Test::CPAN::Changes test

What struck me when I was shifting back and forth between perl versions on my laptop and had to install some of the Date::Holidays modules over and over again, was:

  1. I have to refamiliarize me with my own code
  2. I have to get an overview of what new distributions have been added to the namespace and acquire my attention, I feel like I have been on a looooong holiday
  3. I seriously need to get some work done and get some releases out

Enter Task::Date::Holidays! – using this distribution it will be easy for me to get all of the interesting distributions installed when I have completed point 2, then I can focus on point 3 and point one will solve itself.

Task::Date::Holidays 0.01, contain the following list of distributions:

– Date::Holidays::AT
– Date::Holidays::NO
– Date::Holidays::DK
– Date::Holidays::DE
– Date::Holidays::GB
– Date::Holidays::PT
– Date::Holidays::ES
– Date::Holidays::PL
– Date::Holidays::CZ
– Date::Holidays::KR
– Date::Holidays::SK
– Date::Holidays::FR
– Date::Holidays::BR
– Date::Holidays::CA_ES
– Date::Holidays::USFederal
– Date::Holidays::CA
– Date::Holidays::CN
– Date::Holidays::NZ
– Date::Holidays::AU

Many of these are completely new to me, so this will be very interesting – so expect plenty of releases of Date::Holidays as I chew my way through the list…

jonasbn, Copenhagen


Continous Integration with Travis CI and Github for Distzillians

This post started out at a comment on a blog post, but it was simply not possible for me to comment on the relevant post, so I have edited my comment into a blog post even though most of the contents are not mine :-/

So all the Kudos, credits, beers and stuff for the contents of this post should really go to: Alex Balhatchet, read his post:


Okay – I have migrated all of my CPAN distributions to Github and all new projects start up here. Over the years I have used Jenkins for continuous integration, so I was very happy when I found out that Github offered continues integration using Travis.

I had everything going with Module::Build, which have been my preferred build system and one I have been using for a long time, with Travis CI on Github, but recently I have started porting all my distributions from Module::Build to Dist::Zilla, which meant that I had to revisit my whole toolchain.

Finding Alex’s article was just what I was looking for.

The after reading Dave Cross blog post and presentation I got coverage with coveralls integrated (see my blog post on those spiffy badges)

In order to get coverage integrated with Alex’s example, I have made the following changes to his suggested setup.

install is extended with:

– cpanm –quiet –notest Devel::Cover::Report::Coveralls
– cpanm –quiet –notest Dist::Zilla::App::Command::cover

and this additional after_success section has to be added:

– dzil cover -outputdir cover_db -report coveralls

I did run into some issues with Alex version, so I have to explicitly install Test::Kwalitee since the version on the Travis CI platform is apparently too old, so also under install I do:

– cpanm –quiet –notest Test::Kwalitee

The Test::Kwalitee issue should go away Karen Etheridge patched her Dist::Zilla plugin

An in addition I also had to install the dependencies of the plugins explicitly under install:

– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied

This was due to an issue with Pod::Coverage tests, where Pod::Coverage::TrustPod.pm is missing.

You can have a look at one of my setups from my code Github:

language: perl
– “5.18”
– “5.16”
– “5.14”
– “5.12”
– “5.10”


# Prevent “Please tell me who you are” errors for certain DZIL configs

– git config –global user.name “TravisCI”


# Deal with all of the DZIL dependencies, quickly and quietly

– cpanm –quiet –notest –skip-satisfied Dist::Zilla

# Hack to getting the latest Test::Kwalitee

– cpanm –quiet –notest Test::Kwalitee

# Getting coveralls report

– cpanm –quiet –notest Devel::Cover::Report::Coveralls

# Getting cover command for Dist::Zilla

– cpanm –quiet –notest Dist::Zilla::App::Command::cover

# Getting all the plugins used by Dist::Zilla in this particular setup

– dzil authordeps | grep -vP ‘[^\w:]’ | xargs -n 5 -P 10 cpanm –quiet –notest –skip-satisfied

# Getting all the dependencies requested by author

– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied


# Getting all the dependencies requested by distribution

– dzil listdeps | grep -vP ‘[^\w:]’ | cpanm –quiet –notest –skip-satisfied


– dzil smoke –release –author


– dzil cover -outputdir cover_db -report coveralls

Thanks to Alex Balhatchet for the post – and thanks to Dave for his awesome post and Karen for most impressive responsiveness, when reporting an issue.

Continued good day,

jonasbn, Copenhagen

Continous Integration with Travis CI and Github for Distzillians


CPANday is over – I had HUGE plans, well not for CPANday in particular, but for all of my CPAN contributions.

CPANday did however come very handy and was a magnificent initiative, but as always did not get as much done as I wanted to.

I made 7 maintenance releases, mostly getting up to speed with my distributions, which was previously stranded in migration.

– Business::DK::Phonenumber 0.07
– Business::DK::CPR 1.11
– Tie::Tools 1.07
– XML::Conf 0.05
– Business::Tax::VAT 1.04
– Business::DK::Postalcode 0.09
– Workflow 1.41

I made a single feature release of one of my newer distributions.

– Business::GL::Postalcode 0.03

I made two deletions.

– WWW::Nike::NikePlus::Public
– Business::OnlinePayment::Cashcow

The later very much spurred by the blog post by Book. There is no need to keep distributions on CPAN where the service they use is no longer available. The first was a scraper on the Nike+ community site, where a more well defined API has been developed. I do not think there is a Perl integration, but I do not really use Nike+ anymore after having shifted to Endomondo, so … Cashcow seems to have been discontinued. I created this distribution when working for a client, which was using Cashcow, but the company do not exist anymore and neither does the Cashcow owners it seems.

I would have loved to:

– Do a new release – I have several new releases planned (as part of a quest)
– Thank somebody – I need to buy NEILB a beer for his continued energy and contributions to the CPAN community
– Put my CPAN stuff on Github – Done
– Improve the POD (see also etc.) – I plan to go over POD on all of my modules, now that all of them are accessible on Github
– Close RTs – I have created a quest today to do exactly that
– Get coverage reports with Devel::Cover – I NEED coverage badges on all my distributions
– Address some test reports from CPAN testers – I have many of them as RTs, so they will be addressed
– Delete some distributions – Done and Done
– Blog about a CPAN module – there are SO many to choose from, but I have just started fooling around with Dist::Zilla, perhaps a blog post should be written 🙂
– Give money to the Perl foundation – my employer does on a regular basis, but perhaps I should too

For me CPANday started a wave, it began slowly leading up to CPANday and now continuing with almost daily releases, cleaning, improving, fixing and most of all having a lot fun…

Thanks to all of the CPAN contributors, testers, users, Philippe Bruhat and especially Neil Bowers


CPAN deletions

As I wrote in my post ‘Stranded in Migration’ I plan to delete some of my old distributions from CPAN, since they no longer hold any value. For me they hold value as projects from which I learned a lot, but to the open source, CPAN and Perl communities they no longer offer much value (if they ever did).

So I have deleted:

– Module::Template::Setup, an attempt at what Dist::Zilla or similar do a much better job at
– Games::Bingo::Bot, a complementary IRC bot for Games::Bingo, which should perhaps have been in the examples directory instead

The last distribution is pre-github, back when CPAN was the best way to display and distribute Perl code, today you have alternatives like Github if you just want to demonstrate a concept or want to prototype something. Today there is no need to push everything to CPAN, at the same time CPAN is a marvellous distribution channel and it is the best way to distribute working CPAN components if you want to share with the Perl community.

I have done regular cleaning of my CPAN distributions, always attempting to keep it down to the two latest releases, so a diff can be done, but clearing out stuff which is no longer of value, can only be encouraged, so we do not drown CPAN in old, unmaintained and obsolete distributions no longer holding any value.

Check if somebody depends on your distributions, alternatively ask around before deleting.

This is the first time I have deleted distributions completely, apart from when I mis-named a distribution and uploaded under a different name and it does feel good. I am not embarrassed by my first attempts at CPAN distributions, but it does feel good to delete them and focus on new distributions and maintenance and development of code, which holds more value to me and perhaps to members of the community.

Well everything is at BackPAN and for me at Github so I can look at my old code and see if I have evolved as a programmer 🙂

jonasbn, Copenhagen

Update! 2014.08.13

I completely forgot I am also deleting Bundle::JONASBN, which has been replaced by Task::BeLike::JONASBN, an example of evolution of how to do things on CPAN.

CPAN deletions

Releases of Business::*::Postalcode for Greenland, Faroe Islands and an update for Denmark

These releases have been on my mind for a long time. I had the data resources to do it, but just could not find the time. Participating in the Questhub quest on releasing a new module every month was a boost and I scheduled the two new releases in this quest, but work and life in general caught up with me so they never got finalised.

During the summer holiday I finally found some time to get them out of the way, so I have released:

Business::DK::Postalcode 0.08
Business::GL::Postalcode 0.01
Business::FO::Postalcode 0.01

Business::DK::Postalcode has been extended with a Mojolicious::Lite web application example and hereby some new methods improving the API to the data source.

GL and FO have had additional releases as 0.02 since after GLs release I needed to makes some changes introduced by requirements from FO, which is a subclass of GL.

All distributions are based on the same data source, which I split up by country code. DK only holds a procedural interface either to validate or extract the data, where GL and FO is implemented as object oriented offering the procedural interface as a wrapper.

The latter comes to a certain price, something I am working on fixing, since the performance penalty for this (can be observed with the test suite) is painful.

The projects have taught me a lot about Perl’s __DATA__ and all of the problems of supporting both a procedural and an OO interface and there is much to be learned still, but now the initial versions are out there and I am working on improvements and changes for the DK distribution so it can used in an object oriented manner too.

I am also working on additional example applications, since these really provide good insights on how to do things, it is really healthy to eat your own dog food.

So more releases will follow and hopefully I will be able to catch up with the quest, since I have more new modules lined up for finalising and release in the coming months and lets not forget about CPANday!!

jonasbn, Copenhagen

Releases of Business::*::Postalcode for Greenland, Faroe Islands and an update for Denmark

Badges!? – we NEED stinking badges!

Spending a lot of time on Github, I observed that a lot of projects have cool badges on their pages indicating:

– build status
– coverage
– code climate

And so on…

I have been using Travis CI for my Github projects and it works like a charm. So when I fell over Dave Cross’ presentation and blog post on Travis CI and Github integration I had to read it case there was something useful I did not know and guess what there was.

Dave demonstrated how to get Travis CI and Perl on Github going, but also integrated with Coveralls and he showed how to get a coverage badge on your project.



And in combination with the Travis CI documentation describing how to get a build status badge



Okay, okay, two badges there most be more, so I did some googling and found CPAN badges, badges indicating the latest release to CPAN…



All examples are taken from my Github repository Business::DK::Postalcode and you know what it even works for MetaCPAN.

jonasbn, Copenhagen

Badges!? – we NEED stinking badges!

Stranded in migration

My personal projects and code have lived a long life. I have been using RCS locally, CVS and SVN. My first public repositories was in my local Perl user group Copenhagen Perl Mongers, where we shared a central repository. It started out as CVS, but was migrated to SVN about the same time as I started uploading distributions to CPAN.

In parallel I also set up a few projects at SourceForge and later at Google Code, both using SVN (SourceForge started out as CVS for me, but migration had taken place at some point). Actually the most important project of mine there was Workflow, which was migrated from a closed SVN repository from the original author Chris Winters to SourceForge.

Anyway – for a long time I worked as a freelancer, dreaming of doing my own software instead of others. So I decided to go for a hosted solution with Versionshelf, I later changed to Atlassian, which at that time had nice product consisting of Jira, Confluence, Fisheye and Subversion (it was actually Fisheye, which let me to this, metadata on code has always intrigued me). All my new projects public and non-public got hosted here, but I still had a legacy stuck at the Copenhagen Perl Mongers Subversion server.

I got Google Code migrated to the Atlassian platform, but stayed with SourceForge because of the project organisation. The Cph.pm repos was a dead end, due to the structure, several attempts at getting the projects extracted properly was unsuccessful.

Then came Github a long and a completely new trend in VCS systems. Not always being a first mover I decided to stay put. I still wanted to migrate my old codebase, but could not find the time to sit down and do it.

Michael Schwern created Gitpan, which seemed like a nice solution, but it was based solely on the releases and a lot of history would be lost (to me a serious loss of meta data). There was even some nice blog posts on how to get the most out of Gitpan.

Workflow got migrated from SourceForge to Github, even though SourceForge hosted Git. I had experienced some issues with the administrative interfaces, which rendered the platform useless in a confusing redirect hell (this has been addressed now).

Atlassian then announced the end of life for their Subversion hosting and migration to Git (Bitbucket/Github) was possible. This was the push I needed and all of my code hosted with Atlassian got migrated, well almost all of it I still have some old customer projects still in a Subversion dump. But all of my open source projects got migrated to Github.

All my new projects now start up on Github. But still I looked at my legacy of distributions on CPAN, which I did not have active repositories for and it haunted me.

The in the summer of 2014 (this summer), I fell over Tony Bowden’s Business::Tax::VAT. I have used Business::Tax::VAT::Validation for some projects and never discovered this module, so I checked it out and it seemed that it had not had any releases in a long time and 3 our of 4 RTs was low-hanging fruit, but no Git repo.

So I mailed Tony Bowden and got COMAINT on PAUSE, we wrote back and forth about Github and we investigated the Gitpan version. Luckily the latest version on CPAN was aligned with Gitpan, so I could pick up from there. Fork, Fix and Free. Got the 3 tickets closed and shipped a release, I had to do additional release when it got picked up by the CPAN testers, but that was nothing when it was hosted on Github.

This struck me as a marvellous situation, so I went back to Gitpan and compared it’s versions of my legacy distributions which was not on Github and I was able to create forks of all of them. Yes, this would mean loss of history, but again I would much rather be able to code and maintain, than not being able to do anything.

So now all of my open source Perl projects are on Gitpan and I am a very happy camper. Maintenance releases will start to go out for most of the legacy and some will be deleted (completely) from CPAN, since they are of no value, but they will still be on BackPAN, Gitpan and for me on Github.

My legacy is under control and I am no longer stranded in migration.

jonasbn, Copenhagen

Stranded in migration