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

Team-octopus – an anti pattern?

Many of our daily stand-up meetings and much of the daily over the desk communication sound like:

– “Somebody needs to update the QA database

– ”The regression test fails
– “What version of the application are your testing, did you make sure it is the latest

And the classic:

– “I have installed the components locally and it works on my machine

We also have more severe issues, in SCRUM these are called impediments, these are for the SCRUM Master to handle and might require help from people outside the SCRUM team or even escalation.

All of the examples I gave above are not at this level, they can be handled by the team and they should be handled by the team, but sometimes they fall between two chairs. In order to not confuse these with impediments I will call these obstacles, they can be overcome, but do require some effort.

Now lets set the stage.

We are a small team. We are all experts in some areas and weaker in others. At the same time our team profile consists of a set of functional roles, making sure that all the required aspects of our software development strategy are covered.

The team has grown over time and from time to time we have had consultants working as team members. Some of us have been with the company for a long time and others shorter. This mean that apart from what the individuals bring to the team based on education and prior experience, accumulated knowledge from our company also plays an important part on what and how we contribute individually.

All in all this gives a nice balance and after many failures, experiments, constellations, planning, retrospectives, changes, adjustments we have a good proces for developing software.

But it is not perfect.

Our biggest hurdle and what actually means that we have a low bus number for some parts, is the stuff that falls between chairs, the tasks that are on nobody’s job description, the stuff that glues everything together, the invisible workings of a modern software team.

Our team comprises of the following:

  1. – 1 Team Manager
  2. – 1 Front end UI / UX developer

– 3 developers
– 2 testers, where 1 also acts as test-manager        
– 1 Product Manager – that is me 🙂

The product manager and front end developer design the features and the developers develop and testers test. Our team manager sees to that operational issues are addressed in balance with new features and everything is pretty smooth sailing – well apart from what seems to be a never ending backlog, but that seems to be a part of the game.

This is a good setup for a making software releases, bug fixes, new features, but it does require that the infrastructure for developing software is in place. Here I mean:

– Ticketing system
– Version control
– Build system
– Continuous Integration System
– Test systems (applikation servers and database servers)

Our ticketing and version control system is under control by our operations department and works pretty much all the time. In case of problems we simply raise an issue and it is addressed.

Our build system is highly integrated into the applications and frameworks we build and is based on the platform we deploy to. So this is under version control and works quite well. At some point we experienced a lot of issues when Apple cut the ties to OpenSSL, which we solved by introducing Docker for the developers and that work quite well – but more on that later.

For CI, we also have a pretty stable setup. Once in a while our builds break. Often we can blame the culprit, based on the commit that triggered the build. Sometimes our test environments fail or a timed CI job fails, there are many reasons for this and often it is based on changes to example data or that more than one team member is working on the same dataset. There are multiple ways to overcome this and there is probably a nifty technical solution we can apply – well we have one issue where a download of an external component can render our Jenkins setup unresponsive, which still confuses me as to why this is even possible, but we have only observed it a handful of times.

All in all we have a well functioning team, development proces and infrastructure.

But I do observe the following problems:

– When stuff breaks out of the blue, it tends to fall between chairs
– Non-product code maintenance seems to be of nobody’s interest
– Maintenance of the shared databases are nobody’s responsibility
– Long term strategic ownership of the development platform is of nobody’s interest

I love building software and I love the whole SDLC and I often end up addressing the stuff listed above – which is bad because it is not in my job description, but I am simply the most senior on the team and it is my cryptonite, in that sense that I simply cannot leave it alone when it is not working, perhaps I should get professional help.

Which brings me back to Docker – which is a good example.

Docker saved us in a situation, where maintenance of development environments was consuming a lot of hours due to problems with our stack. Apple had cut the ties to OpenSSL, so all of our local development environments were experiencing issues. Luckily we deploy to Linux, so we weren’t experiencing issues there.

So I introduced Docker and we could get moving, it required a lot of experimentation, we learned a lot, but we got is stabilised and we have things under control.

This made me think that Docker could play a more prominent role – yes, I think long term about the development platform and deployment platform, simply because I care.

– What if we could skip the whole deployment packaging strategy we have today and simply use Docker images for deployment?

It is hard to make such a push ahead when it is not in your job description, it requires time and effort, way beyond introducing Docker in the development team, because it involves managers and other departments.

– What if it didn’t?

If you look at the team rooster and some of the problems, perhaps an operational profile in the team could do the trick, if the team was expanded with a devops role.

Historically we have a tight separation between operations and development due to IT-policy and standardisation emphasising this.

Currently our release proces is quite cumbersome and involves a certain amount of red tape, yes it has improved, but it is far from you one-click deployment and even continuous deployment setups you hear about.

– What if we could deploy Docker images directly into production?

This would most certainly be a boost to the feedback loop and therefor the team and then the productivity.

– But is it a good idea? – teaming up with roles with specialties in certain areas are a good idea, we can see from our current team what specialists can contribute with, but shouldn’t we aim for a better integration with our existing operations team?

If you look at the team we have no support function, our organisation only has a first level support, so we act as 2nd. or 3rd. level depending on how you depict it. What we did here was quite interesting, we made the support role go on tour in the team between the developers. This has increased the knowledge sharing and responsibility. I cannot take credit for this our current team manager introduced this, but I do wish I had introduced this years ago…

So perhaps the right solution to addressing the problems we face are applying the same strategy for the operational responsibility, I think this is called devops. So the team can handle everything by itself – problem solved!

I am still pondering about my role as a product manager, how far should I tage it. I see a lot of roles becoming abstract and facilitating roles – and I am simply not that type. It does not work for me, perhaps it is my techie background, but I need to have a more low-level understanding. I act as sort of an architect for parts of our systems and one thing I have picked up is, architects who do not code, loose the coupling to thing they are architecting. You should not be a code contributing team-member, but prototypes, examples etc. can be coding without interfering with the day to day software development cycle.

I am still trying to find my area as a product manager and I might come back to this in a future post. For now I am trying to get the team to find out how to overcome our obstacles…

Team-octopus – an anti pattern?

Release of Crypt::OpenSSL::X509 1.8.9

I have just released Crypt::OpenSSL::X509 1.8.9. Do note that this is not originally my distribution, but I have helped the author Dan Sully out a little since I am a user of his Crypt::OpenSSL::PKCS12 and Crypt::OpenSSL::X509 and I have an interest in the distributions continued existence, availability and functionality.

So this blog post is more a description of the proces of getting involved, using my involvement in Crypt::OpenSSL::X509 and it’s cousin Crypt::OpenSSL::X509 as examples.

I started out by making a few PRs for some issues we were experiencing, I slowly got involved as Dan not really maintaining the distributions so actively, not doing Perl and working on other stuff – all completely acceptable reasons. Dan started with giving me co-maintainership on PAUSE/CPAN, so I could upload releases. First release I made was simply from a fork, merging a PR post-release, not the best strategy, but it worked out.

Now I have commit privileges on both repositories and on PAUSE/CPAN I have co-maintainership so I can both implement and upload releases. Given this privilege is most certainly daunting and I am faced with a number of questions, some are easy to answer some are more difficult, some will not be answers at this time – anyway questions pop-up in your head:

  1. How much can I change?
    • Style?
    • Toolchain?
    • Functionality?
  2. Should I fix all the issues?
  3. Do I understand all aspects of the implementation?
  4. What if I cannot contribute?

Many answers will present themselves as you start to get more and more familiar with the project in question and other parts, over time, as you get more and more hands on. Currently I consider myself an apprentice in this context, everything is new, confusing and you are afraid to break something.
Modern software development is very forgiving, we have:

– version control and branching strategies
– continuous integration and unit-test suites
– collaboration platforms and open source
– and of course Google and StackOverflow

So it is very easy to get back to the original state, get feedback from either humans or machines or get help or find examples, which resemble what you are trying to accomplish.

Some of the PRs I had created enabled Travis integration for continuous integration, this was a contribution I could make without influencing the actual code – and easy one so to speak. Other PRs addressed issues the build tools. Both distributions are based on Module::Install, where all of my own distributions are based on Dist::Zilla, but for now it seems like at good idea to stick with what is already working, no need to change stuff just for the sake of change.

For coding style, I think it is a good idea to stick to the existing coding style of the project. When and if the project evolve even further, perhaps even on boarding more contributors or if PRs are getting difficult to review or understand it will perhaps be time to document a coding style or enforce a coding style.

Which brings me to the next point. Both Crypt::OpenSSL::X509 and Crypt::OpenSSL::PKCS12 are Perl implementations on top of a C-based library. For me this is a marvellous change to get to read some C-code, when reviewing PRs or familiarising myself with the project codebase.

Familiarising yourself with the existing codebase, can be also be accomplished by triaging bugs, the current bug count for the two project looks as follows;

– GitHub: Crypt::OpenSSL::X509 (17 issues)
– GitHub: Crypt::OpenSSL::PKCS12 (2 issues)

So there should be something to get me started.

In my opinion you do not have to fix all bugs, but it is a good way to dig in and learn a lot. Do not be hesitant to contact the bug reporter if you have questions, they might be long time users and have extensive knowledge of the projects inner workings. The same goes for contributors, which might even know even more since they have actually made a change and are requesting a merge.

What got me to release Crypt::OpenSSL::X509 1.8.9 was actually a PR, which I reviewed, it was in part of the code where I have proposed changes myself, so I would say I had an understanding of what was going on. The change however targeted an operating system, with which I am not familiar – so I wrote the contributor and asked, when there was something that was not clear to be. I got a marvellous response, point to some good documentation, so I learned something and I could complete my review.

Another strategy you can apply, or get anxious to start hacking away, is to add tests. Check the test coverage and implement more tests in the weak spots, that is also a good way to get into the functionality and composition of the project.

My advice is to just get started, review, read, code, learn, test… I do consider all that apprentice level, when you make your first release with a feature of your own or by request of some other, you are no longer an apprentice – you are a true contributor – and that is worth aiming for.

Good luck with your endeavours, there are plenty of projects to contribute to and there is nothing wrong with being an apprentice, all masters were apprentices once.

Release of Crypt::OpenSSL::X509 1.8.9

Date::Holidays 1.10 released

Release 1.08 of Date::Holidays had some issues with the test suite, which resulted in numerous failure reports from CPAN-testers, please see issue #21 for details.

This resulted in release 1.09, which addressed the problem with the bad tests. At the same time it however demonstrated issues with the integration towards Date::Holidays::NZ and Date::Holidays::SK, so issues #22 and #23 was created respectively.

Issue #22 has now been addressed in release 1.10 and next up is 1.11, which is planned to address issue #23 unless something else comes up.

The adaptation of Date::Holidays::NZ also supports the regional parameter described in: Date::Holidays::NZ.

So checking if New Years Day is a holiday in New Zealand, via Date::Holidays:

use Date::Holidays;

my $dh = Date::Holidays->new( countrycode => 'nz' );
if ($dh->is_holiday(year => 2018, month => 1, day => 1) {
        print “It is\n”;

And in particular for the region of Auckland (see Date::Holidays::NZ for details).

use Date::Holidays;

my $dh = Date::Holidays->new( countrycode => 'nz' );
if ($dh->is_holiday(year => 2018, month => 1, day => 1, region => 2) {
        print “In Auckland it is\n”;

You can also get a list of holidays:

use Date::Holidays;
use Data::Dumper;

my $dh = Date::Holidays->new( countrycode => 'nz' );

my $holidays_hashref = $dh->holidays(year => 2018);
print STDERR Dumper $holidays_hashref;

$VAR1 = {
    '0206' => 'Waitangi Day',
    '0402' => 'Easter Monday',
    '0102' => 'Day after New Years Day',
    '1022' => 'Labour Day',
    '1226' => 'Boxing Day',
    '1225' => 'Christmas Day',
    '0330' => 'Good Friday',
    '0425' => 'ANZAC Day',
    '0604' => 'Queens Birthday',
    '0101' => 'New Years Day'

And based on region:

use Date::Holidays;
use Data::Dumper;

my $dh = Date::Holidays->new( countrycode => 'nz' );

my $holidays_hashref = $dh->holidays(year => 2018, region => 2);
print STDERR Dumper $holidays_hashref;

$VAR1 = {
    '0129' => 'Auckland Anniversary Day',
    '1022' => 'Labour Day',
    '0101' => 'New Years Day',
    '0402' => 'Easter Monday',
    '1225' => 'Christmas Day',
    '0330' => 'Good Friday',
    '1226' => 'Boxing Day',
    '0102' => 'Day after New Years Day',
    '0425' => 'ANZAC Day',
    '0206' => 'Waitangi Day',
    '0604' => 'Queens Birthday'

Feedback most welcome,


Date::Holidays 1.10 released

Date::Holidays 1.08 released

I have just uploaded Date::Holidays 1.08 to PAUSE/CPAN.

It holds a new adapter class for Date::Holidays::USFederal (US) in response to a request from a user.

The implementation required a lot of changes to the internal code, due to the variation in the adapted Date::Holidays class name, Date::Holidays::USFederal, which is not an ISO compatible country code. I am pondering supporting this as US as well.

At the same time the test suite was restructured. I hope I did not break anything, all tests pass currently locally and with Travis via GitHub. I moved a lot of tests from *.t files into Test::Class based implementations, which I find much easier to work with.

Upon upload I did observe a failure in the indexing:

Status: Permission missing

module : Date::Holidays::Adapter::Local
 version: 1.08
 in file: lib/Date/Holidays/Adapter/
 status : Not indexed because of case mismatch.

I am not sure what this error means, but I will investigate if this has raises any issues or give complications. The class was called Date::Holidays::Adapter::LOCAL earlier, so this might be the cause of the problem.

CPAN-testers are reporting a lot of failing tests, which I will also investigate (issue #21). I do not suspect the indexing issue to be related, currently I can see that this seems to be an issue with the include path (@INC) for the test classes in the distribution, but I have not been able to reproduce the issue with either prove, make test (based on Makefile.PL) or ./Build test (based on Build.PL).

Date::Holidays 1.08 released

Watching live coding – strangely intriguing…

Watching live coding is strangely intriguing…

I cannot locate the exact resource and therefore I cannot reference it or make sure that the quote is correct, but the thing that caught my attention was something along the lines of the above quote, which I read somewhere online. I had heard about live coding streams in different fora, it sparked my curiosity and decided to check it out.

I decided to watch Suz Hinton (@noopkat) after reading Lessons from my first year of live coding on Twitch and hearing an interview with her on the podcast Hansel Minutes.

@noopkat does her live coding stream on Twitch, which I know from my two sons, both are avid gamers and Youtube watchers. There are other outlets for live coding streams, but I have no experience with any of these. I personally find Twitch very accessible and useful, you can watch on the web, they offer a native client or you can watch on your smart phone. I once tried watching on my phone on the train, but the signal was not entirely stable and in the end I have to give up.

Unfortunately @noopkat is always streaming Sundays when I am making dinner, so it is not always I can pay close attention or I pay attention have to pick an easier dish not requiring my complete attention – anyway I am hooked.

The best recommendation I can give is watching in the comfort of your sofa or similar, like old school flow-TV. I once had the stream running on a PS4, were a Twitch client also is available, freeing up my laptop to do something else – actually I find watching live coding inspirational and doing coding myself is parallel or looking up related resources is useful. The chat interface was however open on my computer to I could participate in the live coding stream, since the PS4 keyboard interface is not optimal, more on this later.

For a long time the Internet and the streaming medium has gone towards convenience consumption. You watch what you want, when you want. If you want to binge, you binge and if you want a break, you take a break. So it is sort of weird that live streaming consumption is attractive, since you now have to hurry home to catch the stream, or postpone dinner, much like when all we had was flow-TV with static schedules.

Twitch is primarily focused on gaming and gamers, but a few live coders can be found using the platform. I have watched: @yom_na and @thelarkinn whos stream I caught my first show of today before work. If you want the episode from today, you can hear a shout out to me, since I had to leave for work. And this is where live coding streams differ from regular flow-TV. The social aspect of the live streaming is important and it helps to build up a social relation and sense of community and even the spectators participate in the stream. @yom_na streamed a live coding session fixing issues and PRs in an open source project I am also contributing to, so that was quite educational.

I think I will continue to watch live coding streams, it is fun and stimulating. Next question is whether I should try to do a session myself. The software used by @noopkat: OBS is free and it would be fun to try out. The only issue is that all of the people I mentioned are incredibly talented and I am not sure I would be able to deliver the same high level.

Watching live coding – strangely intriguing…

Terms and Conditions as a Service – literally

Some time ago I changed my title to Product Manager. For many years I have worked as a developer and later team-lead for a development team, so this was an interesting change.

Working as a team-lead had slowly removed me from actual day to day coding, doing more and more human-resources related tasks and meetings. So when it was suggested to me to play a more active role in the software development, without the team responsibilities I accepted. The only requirement, which was presented to me in my new role was:

Use your knowledge and know-how to continuously support our software services and products.

I was a bit uneasy with the new role and perhaps mostly the title. Having worked as a developer for a long time, it was hard to loose the techie. I suggested “Technical Product Manager”, but it was denied – I got over it and at that point it really did not matter – after all it was just a title *1

Still fearing that it would move me away from coding, I decided to try to shape my new role to suit me better. The organisation I work for has never had a Product Manager before, so I figured I might as well try to outline my own role.

I started out by examining an idea I had played with for some time, but had not implemented. As a Product Manager I decided it was totally legal to create prototypes to evaluate possible candidates for our service portfolio.

The idea was to handle the problem area of “Terms and Conditions” and communication of these. The problem area can be described in the following way:

  1. The terms and conditions has to be available in a preservable format (I am not a legal specialist, so I do not know the exact wording, but this is the way it was explained to me)
  2. The terms and conditions have to be available to the end-user in the revision/version, originally presented to the user

In addition, the following, more basic, requirements followed:

  1. We want to be able to link to the current terms and conditions, so you can find them for example via a website
  2. We want to be able to link to specific revisions so we can create links for websites
  3. We want to be able to communicate the terms and conditions via email, without sending the complete terms and conditions, but just providing a link
  4. We want to support both danish and english

I boiled together a prototype service to handle exactly these requirements and the prototype can be found on GitHub and on DockerHub.

The solution offers the following:

– Terms and Conditions can be downloaded as a PDF and this has been accepted as a preservable format
– You can link to an exact revision, for building lists for example
– You can link with a date parameter, which will give you the revision relevant for the given date
– You can link to the service and get the current revision of the Terms and Conditions
– You can point to a given translation of the document in the URL by using the language indication ‘da’ for Danish and ‘en’ for English

Lets walk through it:

– Providing PDF files as an asset it pretty easy in any modern web development framework

– The date based query:

Returns terms and conditions active for the specified date. This can be used in email for example where you then can stamp with the current date.

– The revision based query:

Returns current terms and conditions revision 2. This can be used for enumerations and listings or specific deep links.

– The basic query:

Returns current terms and conditions, which can be used for webpages where you want to show the current revision for evaluation by the requester.

– The basic query, supporting another language:

Returns current terms and conditions in danish, can be changed to English by specifying: en instead of da.

All of the available documents are assets to the service, these could be fetched from a database or similar, in the prototype they are just publicly available files.

The prototype solves the problems outlined and gives us an overview of the public facing part, meaning the service and feature parts, but can be improved in many areas, especially in regard to the internals.

– You could annotate the documents, if they are no longer the current revision. My suggestion is to annotate the actual PDF, alternatively the presentation in the browser could take care of this. The current prototype does not handle this.

– Handling the problem of different timezones can be quite complex, my recommendation is to decide on one timezone being the authoritative timezone

– The algorithm for resolution could be optimised

– The representation of the terms and conditions artefacts in the back-end could be moved to a databased

– The date parameter is a weak point and the parameter handling could also be improved, at the same time, we expect to label the URL, resulting in a query, with a dateformat we already know

The prototype even holds a bonus feature, due to the way the central algorithm works, you can actually add an asset in advance. It will not be served as the current revision of the terms and conditions until it’s startdate is passed. This means that nobody has to work on New Year’s Eve to publish the new revision of the terms and conditions for availability on the 1st. of January.

These can of course be retrieved based on the revision. Handling of this could be implemented, but I actually consider this as a good thing, since it means that you can test the application, without jumping too many hoops.

I have never worked much with prototypes on a larger scale before, but using my boring stack, it was actually quite fast to get something to work, it would shed light on interesting aspects of the UX and the internal implementation, like the main algorithm and finally it provided a proof of concept, which could spark new ideas.

Becoming a product manager is hard, but it does not necessarily mean that you have to be removed from coding. Prototyping is a lot of fun and it is most certainly not the last time I have approached a problem area in this way.

*1 titles changes can backfire and ever since I changed my title on Linkedin I have received a lot of Product Manager related stuff

Terms and Conditions as a Service – literally