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.