Date::Holidays releases – adapter pattern at large

Since the post on the release 1.10 of Date::Holidays I have released:

1.11 Improved support for Date::Holidays::SK
1.12 Improved support for Date::Holidays::USFederal as US
1.13 Support for Date::Holidays::CA_ES, via Date::Holidays::ES
1.14 Marking of Date::Holidays::UK and Date::Holidays::UK::EnglandAndWales as unsupported, using Date::Holidays::GB instead
1.15 Improved support for Date::Holidays::DE
– and 1.16 Support for Date::Holidays::CZ

And I have more releases in the pipeline.

All of this work started out primarily as an attempt at getting to the bottom of the issue list, new issues do pop up as I get around the different corners and adaptations, but that is perfectly okay and I might never get to the bottom of the issue list, but at least the Date::Holidays distribution will improve and stabilise.

The work is also caused by a change in perspective, where my original motivation was to create a way to consolidate and use all of the different Date::Holidays::* distributions without having to adjust the differing interfaces of all of them.

I just spotted that my documentation lacks a section on motivation, describing the why of Date::Holidays – one more thing to the issue list.

The new perspective is that many of the distributions are not really being updated (which is a pity), but instead of creating a patch for the relevant distributions I am adjusting the adapters in Date::Holidays to implement the lacking features where possible instead of sending patches to the authors of respective distributions – I might do this afterwards, but since this will require a lot of effort, the other way around is faster and easier in most cases. Unfortunately there is also the chance that the original authors are unresponsive and my patches will never be released, so the strategy could be described as a “better safe than sorry” implementation.

About faster and easier, I am creating small tasks, which can be accomplished, while commuting. I have always been inspired by Ricardo Signes (GitHub), who I think have coded more commuting, than I have in front of my computer. This might be a slight exaggeration and Ricardo must correct me if I my description of this is out of proportion, at the same time there is nothing like a good programmer’s myth – well Ricardo is truly a prolific CPAN contributor and he does as such not require a myth.

Anyway – I am not a regular commuter and I will primarily be biking over the summer, so this will possibly not continue with this frequency, but I do enjoy bite-size tasks and I will try to squeeze them in when I can.

The whole change of perspective (and my reading of “Clean Code” by Robert C. Martin) has engaged me a lot and as I deal with all the practical issues I am also giving some thought to the bigger picture.

Date::Holidays have always and will always be a side project, once in a while I get contacted by somebody who use it or is trying it out and it makes me immensely happy, but I am not fooling myself – I do not think Date::Holidays has a big audience. I do get PRs with new implementations and that is awesome and I will keeping pushing for more integrations and adaptations, but it does not change the fact that the user base is limited.

So why do I keep coding on Date::Holidays?

Well, it is incredibly educational.

When I started out it was an exercise in the Adapter Pattern and it probably still is, but things have changed. Now I am reading “Clean Code” as mentioned and I am trying to adopt and learn some of the principles from that book.

Which leads me to the new road map for Date::Holidays, which is slowly taking shape.

– Adopt some “Clean Code” principles
– Factor out the “nocheck” flag (this is one of the principles)
– Factor out general features working on implicit country lists, this does simply not belong in the class (this might be one of the principles)
– Evaluate possible adoption of format parameter from Date::Holidays::* distributions
– Evaluate possible implement localisation of data from Date::Holidays::* distributions

So for now there will be a lot of smaller releases improving the actual adapters and at some point, I will look into making a major release, taking Date::Holidays to the next level, with a lot of clean code and hopefully I will be learning a lot during the proces.

Date::Holidays releases – adapter pattern at large

Interacting with PAUSE using CLI

Interesting and most certainly word a try

perlancar's blog

Any CPAN author has to interact with PAUSE, the website you go to to upload files if you want to publish your work on CPAN. There is no API provided, so you have to use a browser to upload files manually.

Well, not really. There are some modules you can use, like CPAN::Uploader to upload files or WWW::PAUSE::CleanUpHomeDir to delete old releases in your PAUSE home directory. And if you use Dist::Zilla, by default you will use CPAN::Uploader when you release your distribution, so you don’t have to go to PAUSE manually. These modules all work by scraping the website since, like it is said above, there is no API.

WWW::PAUSE::Simple is another module you can use which: 1) provides more functions (aside from uploading, currently can also list/delete/undelete/reindex files, as well as list distributions and cleanup older releases, more functions will be added in the future); 2) comes…

View original post 789 more words

Interacting with PAUSE using CLI

Maintenance releases of Test::Timer

Over the last week or so I have released several maintenance releases of Test::Timer

It all started with finally getting around to evaluating a PR from p-alik. I decided to use the new review feature, this was strictly necessary, but it was fun to try it out.

Then based on a blog post from Github on their pages solution I set up a few an experimental Github Pages solutions and chose Test::Timer to be my first Perl distribution to get a Github homepage.

0.16 2016-12-29 Maintenance release, update not required

- Elimination of warnings in test suite, PR from p-alik

I am still in the proces of refining the theme, so it is not the standard, I might get back to this in a later blog post.

Anyway I wanted to communicate the new homepage to MetaCPAN, after consulting the #distzilla channel on IRC I got some good advice and exchanged Dist::Zilla::Plugin::GitHub::Meta for Dist::Zilla::Plugin::GithubMeta, this was but crazy, but quite easy. The two plugins for Dist::Zilla however resemble each other quite a lot, so a consolidation of the two would have been nice.

0.17 2016-12-30 Maintenance release, update not required

- Exchanged use of Test::Exception for Test::Fatal

- Exchanged use of: Dist::Zilla::Plugin::GitHub::Meta for 
 Dist::Zilla::Plugin::GithubMeta to specify a proper homepage attribute

But apparently the two distributions was not completely compatible, so the bug reporting facility fell back to the de facto standard So after receiving some more excellent advice on IRC, a release with Github issues reenabled could make it to CPAN – and everything seem to be indexed and working correctly on MetaCPAN now.

0.18 2016-12-30 Maintenance release, update not required

- Reenabled Github issues over RT, the Dist::Zilla plugins not completely 

So my dist.ini ended up looking as follows:

homepage =
issues = 1

Anyway all the maintenance is completed now, I still want to get my head around tweaking the Github Pages theme and Jekyll.

At the same time I plan to get the TODO list for Test::Timer migrated to Github issues and then find the time to do an actual feature release – the tool-chain is working, so that is not stopping me.

Happy new year,


Maintenance releases of Test::Timer