Workflow Release 1.43

First release of Workflow in a long time, but luckily I received a pull request from Oliver Welter

Oliver Welter has earlier offered patches implementing custom workflows (1.35 and 1.37) and factory subclassing (1.35) and now improvements in logging for condition validation with the latest release 1.43 – thanks Oliver, you make me look lazy ūüôā

During the testing of the release I ran into an issue with the Dist::Zilla plugin: Dist::Zilla::Plugins::CJM. Related to failing tests due to deprecation. David Golden has offered a pull request, but the author Christopher J. Madsen seems unresponsive and his activity level on Github has flatlined :-/

Changed configuration to an alternative by Dave Rolsky and everything seems to be running as expected.

Release should be available on CPAN shortly – have a nice weekend,


Workflow Release 1.43

Date::Holidays 1.04 and 1.05 Released – introducing Belarus

I am happy to announce a new release of Date::Holidays. The release is 1.04 and is based on work by Vladimir Varlamov, namely an adapter for Date::Holidays::BY, a module for handling holidays in Belarus.

Thanks to Vladimir for his contributions.

Unfortunately I got carton’s local/ directory included in the distribution tar-ball, which Alexandr Ciornii (CHORNY) was quick to tell me so 1.05, got shipped shortly after.

Thanks to Alexandr for bug report.

Holiday season is coming up, so check out Date::Holidays


Date::Holidays 1.04 and 1.05 Released – introducing Belarus

What does full-stack developer even mean?

I see the term full-stack developer everywhere, this got me thinking:

What does it even mean?

To recruiters it seem to say:¬†“we want somebody who can do everything“, meaning we want to hire somebody being¬†a perfect match no matter what, perhaps even in context of wherever technology would take¬†us.

To developers however it seems to communicate that a developer is capable of handling the ability to work in all tiers of a given stack, meaning front-end to backend, UX implementation to datamodelling and everything in between.

The two are actually not far from each other, but … what stack are we actually talking about when we say full-stack and is this even possible?

Lets start by examining what a stack is.


Traditional LAMP Stack

There used to be a term, which you do not see so often anymore, since it has somewhat been booted by the full-stack term and that is  LAMP (Linux, Apache, MySQL, and PHP, source: Wikipedia).

The top-layer of the stack can¬†be replaced by a suited language like Perl, Python and possibly even Ruby), meaning that the definition of the LAMP stack is¬†not even entirely clear – but this is¬†a basic traditional stack and possibly one, which was and still is dominant in many workplaces, simply due to it’s popularity and wide-spread adoption.

Abstract LAMP stack


Since however the LAMP stack is a bit ambiguous lets break it down. From an¬†MVC (Model-View-Controller, source: Wikipedia) perspective it would look like this and¬†we get¬†recognisable depiction. This makes it a bit easier to identify the tiers of which the stack is comprised – let be get back to this later…

As mentioned the  LAMP stack is still around in some sense, but the classical representation does not really depict the more fine grained stack predominant today.

A 6 Tier Stack

Due to the Javascript revolution a large part of the stacks in production today can be broken down even further, Javascript was doable and used earlier, but not to the extent and in the same way as today. Taking this into consideration it is possible to do a more clear distinction.

6 tier stack

The controller/view tier, is much more well-defined and can be sub-divided on technologies, the distinction is not really communicated by the traditional LAMP stack, even though this possibly has been a more or less the de facto standard, having Javascript play a larger or smaller role based on adoption.

MEAN stack


Which brings us to another very predominant stack Рthe MEAN stack (MongoDB, Express.js, Angular.js and Node.js, source: Wikipedia).

The MEAN stack is a Javascript centric stack and the hard part when talking about a Javascript centric stack is the sheer number of variations based on frameworks etc. and the combinations possible, but the MEAN stack is very popular and seems adopted widely.


The abstraction of this stack demonstrates a very interesting aspect of the more modern stack Рthe separation from the operating system. Of course there is a an operating system beneath the stack, but in general it does not play as significant a role as earlier.

Abstract MEAN stack

This whole discussion on the significance of discussion the operation system as part of the stack is interesting, unfortunately the topic is beyond the scope of this article, so I will leave that stone unturned.

Yes there are alternatives and there possibly as many variants of this traditional stack as there are software teams/developers/PaaS product managers. I have attempted to annotate the 6 layer stack, with some technologies just to give you a picture, there are languages/technologies that I have unintentionally left out, forgotten or have not heard about, fill me in in a comment Рbut lets move on.

Annotated 6 layer stack

To get back to the question on: “What does full-stack developer even mean?” Building on the figure above, you would have to select a set of technologies to represent the 6 layers of your stack and then you should be able to work in all tiers of a given stack, meaning front-end to back-end, UX implementation to datamodelling and everything in between.

What I have observed is that these stack-jumping super-developers do not really exist.

Each of the stacks requires specialist knowledge, since they are technologically very different. If you look at a single tier, like the server logic tier, all of the languages mentioned derive from the language C and have so much in common it is almost just a matter of syntax… *ahem* Javascript is derived from C and all in the same category, so we can actually collapse these two tiers into one. The separation was only aimed to represent the two functional areas.

Based on the above plethora of choices, I do not think it makes sense to talk about full-stack developers in general, unless you are very clear on what stack you are talking about. Yes you could go for the most prominent stack or buy into some specific eco-system. I have chosen not to touch on the Microsoft stack, since I have no knowledge of Microsofts current offerings in this area and the same goes for Java.

Developer Origins

I have observed is that developers come from somewhere. They have played around with some technologies, languages, frameworks, applications, operating systems, a stack, while they learned their way around computers. Then they got a job or an education and got exposed to new technologies and possibly even new stacks.

Some developers are be top-down, they originate from the front-end, design, UX/UI or some industry or education related to visual presentation or they just started working with websites and at some point needed some more functionality.

Others are bottom-up developers they originate from Systems administration and operation, which mean they now the OS and they now the applications part and all the operational aspects of modern applications. Perhaps they even originate from database administration meaning they are strong on data-modelling etc.


The type I most often see is the diamond developer. These are classical computer programmers. They program and that is what they do. They originate from classical programming and at some point, they needed work with data so they got exposed to database technology. Later or before they get exposed to the concept of users  (other than themselves) and they had to create a proper user interface.


There are of course exceptions to all of the modelled developers I mention above and you can vary the size and contents of the different tiers, where some diamond developers excel in several interpreted and compiled languages, even other language concepts than the traditional procedural/OOP programming paradigms.

No matter where you come from, your perspective is unique and your toolbox is unique.

Full-stack Polyglot Specialised Generalist Developers

What does full-stack developer even mean?

It is a developer capable of working the different tiers of the stack and who can understand the different paradigms and technologies of which the tiers are comprised at the same time utilise best-practices and embrace requirements and who can consolidate everything into an application (on schedule, budget and with minimal defects and maximum security).

Just kidding…

Developers are a special lot. We specialise in our tools, we get thrown a problem and We have to understand the problem and the problem area. Which mean we have to become specialists in this particular problem area. When we solve the problem we get thrown a new problem, perhaps in a new job, gig, project and we have to become specialists again, but we often reuse our tool chain, which all of a sudden become a general tool. As we evolve with problem solving we extend our toolbox Рwe become specialised generalists or general specialists.

So to rephrase the question, does Full-stack Polyglot Specialised Generalist Developers exist?

I have met many extremely talented, clever and resourceful programmers over the course of my career and I hope to meet many more.

My conclusion is that the term full-stack developer has to take the following into account:

  1. What does the stack comprise of we are talking about
  2. How many variations to the stack have your shop/project made to the stack
  3. What is the prominent stack on the market

Then we have a slight chance of talking about the term full-stack developer and be on the same track, but at the same time this does not even make sense as a general term Рdevelopers evolve, stacks change, due to developer evolution.

The stack of yesteryear might be the legacy system you have to work with as your next problem area or you have to work with the untested error prone top-notch newest stack on the block designed especially for the problem at hand.

Stacks are just bundles of tools. Focus on problem solving, extend your toolbox, become a specialist, have a general perspective on technology and choose the best tool for the job. You will encounter numerous stacks, you will by far not become a specialist in all of them, some you will love, some you will hate, but for most you will do both since there are no silver bullets in software development Рbut there are plenty of problems, tools and the fantastic gratification of providing the solution.


What does full-stack developer even mean?

Aloha Module::Info::File

“Aloha: Means hello and Ehh.. also goodbye”¬†– Bighead

I have just processed some old PRs for Module::Info::File. A Perl distribution I created a long time ago. The module was implemented as a subclass of Module::Info, which I thought lacked some use-cases like basic file handling.

Actually the whole module concept came from a script named, which extracted basic meta data from Perl packages and Perl module files – this led me to Module::Info and to a solution of subclassing into Module::Info::File.

Anyway I got the PRs processed and got the whole thing working nicely. I had a look at the internals and was not satisfied, parsing version numbers in Perl components have always been interesting.

Based on a old note I had a look at Test::Version a module to test your version strings assuming it did something clever I had not thought of. It appeared that Test::Version was just based on Module::Metadata.

Module::Metadata looks quite impressive so I decided to pull out all the internals of Module::Info::File and implement new logic founded in Module::Metadata Р*clickity* *click* Рversion 1.00 ready and after some testing and adjusting uploaded to PAUSE/CPAN.

The Module::Info::File distribution contains a test to check whether the superclass Module::Info would implement the same functionality, causing Module::Info::File to be obsolete Рthis just never happened.

Just out of curiosity I read up on Module::Info, which had had several releases, a new maintainer and new functionality, which should have caused the mentioned tests to fail.

I had a look at the documentation and fell over the following:

“Module loaded using new_from_file() won’t have this information in which case you can set it yourself.”

So I thought why not look into whether my code can be ported to the superclass, since I actually do that, I did it prior to 1.00 and I do with 1.00…

Looking around for a Github repository link I ended up in the issues/bug tool RT. Here RT:115147 stood out.

“I wonder if it is time to deprecate Module::Info, or at least point to Module::Metadata as the in-core and preferred mechanism for gathering module information? It looks like Module::Info’s mechanism for parsing $VERSIONs out of files is quite incomplete and outdated.”

I had just changed Module::Info::File to use Module::Metadata and going over the newer releases of Module::Info I located module_info a magnificent tool for replacing my own Рexcept for the fact that it outputs the filename instead of the package name when providing it with a file as argument.

So now I am unsure of what way to go:

  • Should I deprecate Module::Info::File and just play along with Module::Info and it’s module_info
  • Should I talk to the current maintainer of Module::Info about using Module::Metadata internally so the file handling would improve, since I just observed that worked for Module::Info::File 1.00 and then deprecate Module::Info::File
  • Or should I just forget the whole ¬†Module::Info / Module::Metadata thing and focus or maintaining Module::Info::File

Anyway it is all in the life-cycle of Perl distributions – distributions come and go…

Aloha Module::Info::File

CPAN Pull Request Challenge 2017

I just received a mail from Neil Bowers asking if I would consider having my CPAN distributions be a part of the 2017 CPAN Pull Request Challenge.

My undelayed mental response: Well of course…

I participated in the 2016 Hacktoberfest, I did not contribute much, but I participated and I would have loved to contribute more. These sort of “events” are good, IMHO they bring out the best in open source and they demonstrate the essence of the open source community.

In addition they help tie a community together, so when you are like me; a maintainer of CPAN distributions with very little time, every patch and every PR is most welcome.

A CPAN Pull Request Challenge gives you exactly that.

The CPAN Pull Request Challenge 2017 is soon to kick off, which mean YOU have a chance to benefit from this incredible initiative.

If you have received a mail from Neil respond and be take into consideration for possible PR coming your way or you can tag your issues on Github with the label:


In order to add the label you have to do the following (This can possibly also be accomplished via the Github API, but that is beyond this blog post):

1. Go to you Github repository issues page
2. Click “Labels”
3. Click “New label”
4. Add the label “cpan-prc-2017”

This mean that the label will be present for both issues and PRs.

Please note that labelling issues will not make them go away automagically, but it will be easier for participants to find issues¬†suitable for¬†the challenge, and also lets participants know that you’re open to a PR for that issue. Since they can be easily identified using a primitive search:

Ask not what you can do for the CPAN Pull Request Challenge 2017, but what CPAN-PRC-2017 can do for you.

This blog post has primarily been on getting help with your distributions and issues from the challenge – there is of course also the option of participating as a contributor of PRs.

Please read more about CPAN Pull Request Challenge at:

Have fun – looking forward to your PRs,


CPAN Pull Request Challenge 2017

Github Pages

I have for long wanted to do something with Github Pages. I have seen cool projects having great websites for promotion and acting as landing pages and frontpages to Github repositories and the integration just seems to come so easy, but I could not really find the time to have a crack at it.

Then I read a¬†Github blog post stating “Publishing with GitHub Pages, now as easy as 1, 2, 3”, so I think, well know¬†it must be about time.

I have had a plan to do some promotion of the repository and Perl distribution Workflow. But I wanted to do some experimenting first, to get a feel for the process, tweaks and tricks and the result.

I started with my personal Github page, then that and my Today I Learned repository. Utilizing the available¬†themes was quite easy, but that would mean that your site/page at some point look like everybody else’s and the point of doing promotion is to stand out.

I have several Perl distributions on Github, I would for them to have some sort of resemblance so they would be easily identifiable as homepages for Perl distributions. MetaCPAN can utilize a link to a homepage using CPAN Metadata (See the specification: CPAN::Meta::Spec, resources).


Getting this set using Dist::Zilla was described in my latest blog post.

Well I decided for the Cayman theme and I decided to go for some basic customisation.

Github Pages uses Jekyll and adding a theme is quite easy doing it via the Github repository settings.


I am a complete n00b at this Jekyll stuff and I am primarily programming and not doing layout using CSS and HTML – I am one of those programmers who love Bootstrap. But I successfully got Jekyll running locally.

Anyway I forked Cayman repository and got it working so I could do changes, tweaks and customization.

When I finally got the “Cayman” theme to look like what I wanted, I ported my¬†changes to me repository using the Cayman theme following this piece of documentation.

The actual porting is quite simple, but I had to translate from some Sass directives to pure CSS. This was done using a combination of inspecting elements using the browser and copy-pasting CSS directive from my fork of the Cayman theme.

Lifted from the documentation referenced above:


My final result got to look as follows:


@import "{{ site.theme }}";

.page-header {
  color: #fff;
  text-align: center;
  background-color: #fff;
  background-image: linear-gradient(to bottom, #1e6bb8, #fff);

.main-content {
    h1, h2, h3, h4, h5, h6 {
        margin-top: 2rem;
        margin-bottom: 1rem;
        font-weight: normal;
        color: #222;

And you can see the result here:

Apart from getting to learn a bit about Jekyll, Sass, I learned a bit about CSS3 gradients.¬†I know my customizations are in the low end, but as I stated I would love to do something, which could communicated that it was a Perl 5 distribution, but the Perl 5 brand is somewhat vague –¬†so the next step is to spark some creativity to take this new customizations to a new level and if it is going to be widely used for my distributions, perhaps be folded into some sort of standardised theme, which can be easily applied to several repositories.

If you want to help me create a Perl Jekyll Github Page Theme – ideas and suggestions are most welcome…


Github Pages

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