Recently I received an issue report for an older Perl distribution of mine Date::Holidays::Abstract.
The bug was pretty easy to address, it was a simple error in some meta-data for the distribution. I got everything fixed and shipped release 0.08.
Thanks Olaf Alders for reporting the issue, even though I had not made a releases since 2014.
Well diving in to the code and distribution sparked my inner boy scout and I decided to clean up some more. I tweaked my development environment and fixed some minor things with in-editor linting for Perl. If interested in this topic, please see my earlier posts: "Blog post: Bugs!? - static analysis to the rescue " and "Blog post: Static Analysis in Perl - or yet another policy ".
Anyway as I described in my previous blog post: "TIL: Todo Tree a nifty VScode Extension" I can now easily spot TODOs in my code base. A sometimes misleading presentation is the TODO file, which historically has accompanied open source distribution, when these where distributed as tar-balls. Today when you can access central repositories and share code and information more easily I do prefer to point to the issue list or similar, instead of maintaining a text files accompanying the source code. Well the plugin pointed to my TODO file.
TODO file for Date-Holidays-Abstract
$Id: TODO 1712 2007-02-13 21:42:34Z jonasbn $
- Create a proper test for the use part
- Implement some breaking tests using Test::Exception
- Move Abstract.pm to root directory this is a one-module distribution, no
need for the lib/ directory
And I even got some of the TODOs addressed and improved the unit-test coverage. The distribution is pretty basic and holds 100% coverage, but I wanted to implement some test scenarios demonstrating the code was working properly.
The distribution is basically an abstract class aiming to support additions of calendars to the Date::Holidays:: namespace and structure.
The test was a bit funny to implement since I wanted to trigger a compilation time error and catch this using a test, which are most often working in the context of runtime.
The solution proved to be be basic since I simply had to do the opposite of an idiomatic construct I have used plenty of times, dynamically loading a Perl component and throwing an exception if it failed. I coded up the same construct, knowing that my test component would trigger the exception, captured the exception and asserted it's contents.
#!/usr/bin/env perl
use strict;
use warnings;
use English qw(-no_match_vars);
use FindBin qw($Bin);
use lib ("$Bin/../t", 't');
use Test::More;
use Test::Fatal qw(dies_ok);
## no critic ( ProhibitStringyEval ProhibitComplexRegexes RequireDotMatchAnything RequireLineBoundaryMatching RequireExtendedFormatting)
local $EVAL_ERROR = q{}; # protect existing $@ ($EVAL_ERROR)
my $rv = eval 'use Example::Abstractionless';
diag("Diagnostics ($rv): ", $EVAL_ERROR);
like($EVAL_ERROR, qr/Class Example::Abstractionless must define is_holiday, holidays for class Date::Holidays::Abstract at/, 'abstraction not implemented, we observe a compilation error');
done_testing();
With this in place I could ship release 0.09 and I could get rid of the TODO file. As I outlined I can see all my TODO annotations in my editor and in addition I use probot, so when I committed my changes, probot reported an issue based on a new TODO annotation.
# TODO: we should get perltidy going so this policy can be reenabled
In addition the ever omnipresent Perl distribution patcher and CPAN contributor Mohammad S Anwar, filed a PR with some corrections to the documentation. I got that merged and released 0.10.
Thanks Mohammad S Anwar for keeping me on my toes.
The distribution is old and it probably not put to much use, but it is there and it has been a part of the Date::Holidays:: project, which I have blogged about on several previous occasions. Most of the code I write I write for myself, but I will happily share if somebody wants to learn from my experiments, implementations and mistakes. I do get occasional PRs and sometimes a completely new implementation for a calendar for Date::Holidays and that makes me happy, but what I primary get from being a open source software author is the freedom to tinker, experiment and learn. Date::Holidays is an exercise in using the adapter patters, Date::Holidays::Abstract is an exercise in using abstract classes and the cousin Date::Holidays::Super a super class.
Do not be afraid to put something out there, maintaining an open source distribution will get you exposed to a lot of disciplines involved on doing software development, like:
- documentation writing
- unit-testing, CI and QA
- releasing and shipping
- bug triage
- and of course coding
Practicing all of the above and doing it in the open can benefit your career and education. You can familiarize yourself with other areas, which you might not be part of your job or job description, but having an understanding, can make it easier to interact with DevOps people, testers, technical writers and supporters etc.
Anyway I take all of the above seriously for my open source ventures and I take contributions very seriously, so I decided to add the following to my contribution guidelines to acknowledge the contributors:
Acknowledgement and Mentions
Please note that all contributions are acknowledged and contributors are mentioned by available identification, if you as a contributor would prefer not to be mentioned explicitly please indicate this, PR mechanics cannot be ignored.
If you prefer to be mentioned in a specific manner other than by GitHub handle or similar please indicate this and accommodation will be attempted, limited only be the means available,
Since all I can offer is acknowledgement and heartfelt appreciation.
Top comments (0)