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 version.pl, 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 version.pl – 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:

cpan-prc-2017

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:

https://github.com/search?q=label%3Acpan-prc-2017&ref=searchresults&utf8=%E2%9C%93

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: http://cpan-prc.org/

Have fun – looking forward to your PRs,

jonasbn

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).

homepage.png

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.

settings.png

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:

custom.png

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: https://jonasbn.github.io/perl-test-timer/

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

Public Specifications FTW

Please note that this post is by no means endorsed by my employer, it is a personal reflection on a strategic move I have participated in, in my line of work as a professional software developer.

The above paragraph, which I felt I a need to write as a part of this blog post, is very aligned with the actual post topic in itself, please read on.

The place where I work have for a long time published specifications on some of the offered services. Either this was done using our CMS or using PDF artefacts from a Wordprocessor.

Both processes where tedious and held several issues:

  • Content in CMS
    1. Hard to edit longer documents with figures and cross references
    2. Version control was not obvious
    3. Drafts compared to published documents was not used
  • Wordprocesser artefacts
    1. Version control practically non-existing or external
    2. Document control based on files shares, folders and naming conventions
    3. Manual publication proces

There was probably several other issues I have happily forgotten, like PDF meta-data removal etc.

After having done a lot of open source work in Markdown and on Github and in conjunction with releases of some open source demo clients for our services, I proposed that we published the accompanying public specifications on Github.

This proved to be a very clever move.

It did require some consideration on our side and it was quite a new move to us. Yes we had published specifications for public availability for long a time, but putting these in a public repository was still a new move for us. But the concerns hastily evaporated and the proces became natural and incredibly productive compared to the old processes.

At the time of writing we have 6 open sourced specifications and 3 clients accompanying these and a repository with XSD files supplementing one of the specifications.

Not all of the specifications are finished, but they are out there, so if somebody wants to see what is going on, they are most welcome. We have only received a single pull-request and that is completely okay. We do not want somebody to write our specifications, that is our job, but corrections to sample code, clarifications and of course spelling corrections are most welcome.

Here are some of the pros I have observed:

  • Using Git and Markdown
    1. Version control is built-in
    2. Markdown is quite powerful and easy to edit
    3. Syntax highlighting of code samples (bash, XML, JSON, text etc.)
    4. The flow resembles a development flow and the toolchain is somewhat the same
    5. Tagging of versions and complete history is available
    6. An engaging proces supporting pull-requests (oh well)
    7. Branching for new editions and proposals for change requests

Currently one of the specification has 4 branches, when evaluation and review is finalized, will be merged onto the master, which can be tagged as the authoritative specification – and this proces is so easy to grasp and complete since it is same proces we use for source code.

One last benefit I really enjoy, one which I think is a bit underestimated is – the contract.

When we publish a public specification, we aim at to be informative, useful, correct, exact, educational, clear and to the point.

This works quite well and since often I find that we refer to the public specifications when discussing topics related to our services and since the quality of these sometime outshine our internal specifications, I often find myself thinking that we should publish much more, much much more.

So revisiting the opening paragraf – ever so often we are afraid and publishing API’s become a side-project. Do not be afraid to publish your specifications and documentation, do not be afraid to use an existing platform and toolchain, the pros outweigh the cons and you will quickly forget all about the old way of doing things and you will find yourself more productive and in the end getting your specifications published will be easier than ever.

Whether you are publishing a website or a PDF document, the information is public, the proces is actually the most important aspects and Github and Markdown REALLY leverage this.

The discussion on how far you can go and how much you can publish is a huge topic and should perhaps be another blog post.

Public Specifications FTW

Documentation

Having been a long term Perl developer I have used, read, liked, written and learned from a lot of technical documentation as the one found on CPAN. Back in 2011 Chromatic wrote a good piece entitled: “Victims of the Success of CPAN Documentation”, this piece hit the nail on the head and addresses one of my long time concerns and issues with technical documentation.

“It is not always user-friendly”

I have played around with the idea of extending my documentation boilerplate/template with a section named: “Features”. The idea of the “Features” section would simply be to add information on some basic use-cases, recommended uses and core functionality (what does it do).

Often technical documentation only lay out the bricks and building blocks, letting it be up to the user to assemble the pieces, much like Ikea furniture. Ikea furniture however does have one clear advantage over software components, it does have a clearly stated goal: “You can eat|sit|sleep|contain|relax with X”, meaning Ikea sells an idea to the end-user before the fact of assembly-process comes to mind of the customer.

Software components are not Ikea furniture, it is more like LEGO bricks. but also LEGO sells the idea of a working concept, instead of just a box of bricks – you get the bricks, but you also get the blueprint. Yes you can build constructions of your own design and yes you can combine with other LEGO sets.

My youngest son builds a lot of LEGO, yes he can follow the assembly guide, and yes he an build stuff of his own design, but in a place where he truly excels is in the remix of LEGO sets. He loves taking apart standard models or models I have built, but instead of breaking them into atoms, he breaks them down to smaller LEGO models and then he combines them to alternative models – a lot of this is retrofitting guns and cannons, but that is not important for this blog post.

So when we want somebody to use our open source software, we need to sell the concept. Yes there are plenty of ways to “sell” the software, demo videos, blog posts etc. – but users think in use-cases and with the amount of open source software available, it can be hard to decide on which solution to pick – you evaluate on a lot of different parameters (this could be a blog post by itself), and one of them is sometimes documentation.

So documentation should be considered a factor to make somebody choose your software instead of some other implementation. This means you have to describe some key parameters in order to sell the concept.

  • What does it do
  • If you use it like this, it is: fast/reliable/intuitive/interactive/customisable/beautiful
  • And in addition you can: produce/calculate/render/secure/build/execute/integrate

Describe features and key concepts and core functionality as an elevator pitch and you might hook the reader.

I have grown very fond of a plugin for Sublime Text, it is a pretty basic plugin, which creates a Table of Contents on a Markdown document.

I use it all of the time.

I looked at the documentation and I got it to work, as I said it is pretty basic and the documentation was sufficient, but not impressive. I sent a pull-request for a bug fix and I sent a pull-request for some documentation spelling corrections – all was accepted.

The author is really a cool guy and I love his software product. So I thought to myself. I am not a Python programmer (my first PR was the deletion of a line), perhaps I can contribute in another way – this piece of software is really marvellous and I want everybody else to see it, try it, use it and love it – just like me.

So I wrote him and asked – What do you think about a complete rewrite of the documentation?

And he said go ahead

So today I have sent him a pull-request with a complete re-write of the documentation going from a format focused on parameters in the software to a feature centered approach.

All of the pieces where there, all the examples, all the data – I simply shuffled it around and added some prose and rephrasing to make it more human-readable.

I do not know if my theory on this holds water, but I actually like the outcome of my work and I hope this new format will be more appealing to the potential users and existing users, who read the documentation to become wiser, or get the information on how to tweak the use of the software to their needs, because the software actually had a lot to offer, but it was not immediately clear, when skimming the documentation.

I know this might not apply to all types of documentation and yet again it might.

Give it a shot.

 

Documentation

Date-Pregnancy 0.06 released

When I woke up this morning, I had received an email from somebody who are repackaging a Perl distribution of mine Date-Pregnancy for Debian.

I have been extremely busy the last 4 months with work, so I have not contributed anything to open source at all and I have not been doing much work on this sphere at all.

But now it is my winter holiday and I thought, why not process this patch as rapidly as possible to acknowledge the person who take the time to repackage my distribution and also took the time to correct spelling errors in my documentation.

So today I published Date-Pregnancy 0.06 to CPAN.

jonasbn

Date-Pregnancy 0.06 released