I have just revived a lot of my CPAN distributions after they where stranded in migration. One these distributions is Date::Holidays a wrapper/adapter to modules in the Date::Holidays namespace and related. Since development started up again I have made several releases and I am on a quest to get all of the RTs/issues out of the way.
Some release history:
0.19 2014.08.27 bug fix release, update not required (see below)
- This release addressed reports on failing tests for perl 5.21
The use in this distribution of UNIVERSAL is now deprecated,
see: Github issue [#3] and [RT:98337]
0.18 2014.08.24 feature release, update not required
- Added adapter class for Date::Holidays::BR [RT:63437]
0.17 2014.08.22 maintenance release, update not required
- Migrated from Module::Build to Dist::Zilla
- Fixed issue in some test, which would break if Date::Holidays::DK
was not installed
0.16 2014.08.18 maintenance release, update not required
- Fixed POD error
- Aligned all version numbers
- Added t/kwalitee.t Test::Kwalitee test
- Added t/changes.t Test::CPAN::Changes test
What struck me when I was shifting back and forth between perl versions on my laptop and had to install some of the Date::Holidays modules over and over again, was:
Enter Task::Date::Holidays! – using this distribution it will be easy for me to get all of the interesting distributions installed when I have completed point 2, then I can focus on point 3 and point one will solve itself.
Task::Date::Holidays 0.01, contain the following list of distributions:
Many of these are completely new to me, so this will be very interesting – so expect plenty of releases of Date::Holidays as I chew my way through the list…
This post started out at a comment on a blog post, but it was simply not possible for me to comment on the relevant post, so I have edited my comment into a blog post even though most of the contents are not mine :-/
So all the Kudos, credits, beers and stuff for the contents of this post should really go to: Alex Balhatchet, read his post:
Okay – I have migrated all of my CPAN distributions to Github and all new projects start up here. Over the years I have used Jenkins for continuous integration, so I was very happy when I found out that Github offered continues integration using Travis.
I had everything going with Module::Build, which have been my preferred build system and one I have been using for a long time, with Travis CI on Github, but recently I have started porting all my distributions from Module::Build to Dist::Zilla, which meant that I had to revisit my whole toolchain.
Finding Alex’s article was just what I was looking for.
The after reading Dave Cross blog post and presentation I got coverage with coveralls integrated (see my blog post on those spiffy badges)
In order to get coverage integrated with Alex’s example, I have made the following changes to his suggested setup.
install is extended with:
- cpanm –quiet –notest Devel::Cover::Report::Coveralls
- cpanm –quiet –notest Dist::Zilla::App::Command::cover
and this additional after_success section has to be added:
– dzil cover -outputdir cover_db -report coveralls
I did run into some issues with Alex version, so I have to explicitly install Test::Kwalitee since the version on the Travis CI platform is apparently too old, so also under install I do:
- cpanm –quiet –notest Test::Kwalitee
The Test::Kwalitee issue should go away Karen Etheridge patched her Dist::Zilla plugin
An in addition I also had to install the dependencies of the plugins explicitly under install:
- dzil listdeps –author | cpanm –quiet –notest –skip-satisfied
This was due to an issue with Pod::Coverage tests, where Pod::Coverage::TrustPod.pm is missing.
You can have a look at one of my setups from my code Github:
# Prevent “Please tell me who you are” errors for certain DZIL configs
– git config –global user.name “TravisCI”
# Deal with all of the DZIL dependencies, quickly and quietly
– cpanm –quiet –notest –skip-satisfied Dist::Zilla
# Hack to getting the latest Test::Kwalitee
– cpanm –quiet –notest Test::Kwalitee
# Getting coveralls report
– cpanm –quiet –notest Devel::Cover::Report::Coveralls
# Getting cover command for Dist::Zilla
– cpanm –quiet –notest Dist::Zilla::App::Command::cover
# Getting all the plugins used by Dist::Zilla in this particular setup
– dzil authordeps | grep -vP ‘[^\w:]‘ | xargs -n 5 -P 10 cpanm –quiet –notest –skip-satisfied
# Getting all the dependencies requested by author
– dzil listdeps –author | cpanm –quiet –notest –skip-satisfied
– export RELEASE_TESTING=1 AUTOMATED_TESTING=1 AUTHOR_TESTING=1 HARNESS_OPTIONS=j10:c HARNESS_TIMER=1
# Getting all the dependencies requested by distribution
– dzil listdeps | grep -vP ‘[^\w:]‘ | cpanm –quiet –notest –skip-satisfied
– dzil smoke –release –author
– dzil cover -outputdir cover_db -report coveralls
Thanks to Alex Balhatchet for the post – and thanks to Dave for his awesome post and Karen for most impressive responsiveness, when reporting an issue.
Continued good day,
CPANday is over – I had HUGE plans, well not for CPANday in particular, but for all of my CPAN contributions.
CPANday did however come very handy and was a magnificent initiative, but as always did not get as much done as I wanted to.
I made 7 maintenance releases, mostly getting up to speed with my distributions, which was previously stranded in migration.
- Business::DK::Phonenumber 0.07
- Business::DK::CPR 1.11
- Tie::Tools 1.07
- XML::Conf 0.05
- Business::Tax::VAT 1.04
- Business::DK::Postalcode 0.09
- Workflow 1.41
I made a single feature release of one of my newer distributions.
- Business::GL::Postalcode 0.03
I made two deletions.
The later very much spurred by the blog post by Book. There is no need to keep distributions on CPAN where the service they use is no longer available. The first was a scraper on the Nike+ community site, where a more well defined API has been developed. I do not think there is a Perl integration, but I do not really use Nike+ anymore after having shifted to Endomondo, so … Cashcow seems to have been discontinued. I created this distribution when working for a client, which was using Cashcow, but the company do not exist anymore and neither does the Cashcow owners it seems.
I would have loved to:
- Do a new release – I have several new releases planned (as part of a quest)
- Thank somebody – I need to buy NEILB a beer for his continued energy and contributions to the CPAN community
- Put my CPAN stuff on Github – Done
- Improve the POD (see also etc.) – I plan to go over POD on all of my modules, now that all of them are accessible on Github
- Close RTs – I have created a quest today to do exactly that
- Get coverage reports with Devel::Cover – I NEED coverage badges on all my distributions
- Address some test reports from CPAN testers – I have many of them as RTs, so they will be addressed
- Delete some distributions – Done and Done
- Blog about a CPAN module – there are SO many to choose from, but I have just started fooling around with Dist::Zilla, perhaps a blog post should be written
- Give money to the Perl foundation – my employer does on a regular basis, but perhaps I should too
For me CPANday started a wave, it began slowly leading up to CPANday and now continuing with almost daily releases, cleaning, improving, fixing and most of all having a lot fun…
As I wrote in my post ‘Stranded in Migration’ I plan to delete some of my old distributions from CPAN, since they no longer hold any value. For me they hold value as projects from which I learned a lot, but to the open source, CPAN and Perl communities they no longer offer much value (if they ever did).
So I have deleted:
- Module::Template::Setup, an attempt at what Dist::Zilla or similar do a much better job at
- Games::Bingo::Bot, a complementary IRC bot for Games::Bingo, which should perhaps have been in the examples directory instead
The last distribution is pre-github, back when CPAN was the best way to display and distribute Perl code, today you have alternatives like Github if you just want to demonstrate a concept or want to prototype something. Today there is no need to push everything to CPAN, at the same time CPAN is a marvellous distribution channel and it is the best way to distribute working CPAN components if you want to share with the Perl community.
I have done regular cleaning of my CPAN distributions, always attempting to keep it down to the two latest releases, so a diff can be done, but clearing out stuff which is no longer of value, can only be encouraged, so we do not drown CPAN in old, unmaintained and obsolete distributions no longer holding any value.
Check if somebody depends on your distributions, alternatively ask around before deleting.
This is the first time I have deleted distributions completely, apart from when I mis-named a distribution and uploaded under a different name and it does feel good. I am not embarrassed by my first attempts at CPAN distributions, but it does feel good to delete them and focus on new distributions and maintenance and development of code, which holds more value to me and perhaps to members of the community.
Well everything is at BackPAN and for me at Github so I can look at my old code and see if I have evolved as a programmer
I completely forgot I am also deleting Bundle::JONASBN, which has been replaced by Task::BeLike::JONASBN, an example of evolution of how to do things on CPAN.
In: Releases8 Aug 2014
These releases have been on my mind for a long time. I had the data resources to do it, but just could not find the time. Participating in the Questhub quest on releasing a new module every month was a boost and I scheduled the two new releases in this quest, but work and life in general caught up with me so they never got finalised.
During the summer holiday I finally found some time to get them out of the way, so I have released:
Business::DK::Postalcode has been extended with a Mojolicious::Lite web application example and hereby some new methods improving the API to the data source.
GL and FO have had additional releases as 0.02 since after GLs release I needed to makes some changes introduced by requirements from FO, which is a subclass of GL.
All distributions are based on the same data source, which I split up by country code. DK only holds a procedural interface either to validate or extract the data, where GL and FO is implemented as object oriented offering the procedural interface as a wrapper.
The latter comes to a certain price, something I am working on fixing, since the performance penalty for this (can be observed with the test suite) is painful.
The projects have taught me a lot about Perl’s __DATA__ and all of the problems of supporting both a procedural and an OO interface and there is much to be learned still, but now the initial versions are out there and I am working on improvements and changes for the DK distribution so it can used in an object oriented manner too.
I am also working on additional example applications, since these really provide good insights on how to do things, it is really healthy to eat your own dog food.
So more releases will follow and hopefully I will be able to catch up with the quest, since I have more new modules lined up for finalising and release in the coming months and lets not forget about CPANday!!
Spending a lot of time on Github, I observed that a lot of projects have cool badges on their pages indicating:
- build status
- code climate
And so on…
I have been using Travis CI for my Github projects and it works like a charm. So when I fell over Dave Cross’ presentation and blog post on Travis CI and Github integration I had to read it case there was something useful I did not know and guess what there was.
Dave demonstrated how to get Travis CI and Perl on Github going, but also integrated with Coveralls and he showed how to get a coverage badge on your project.
And in combination with the Travis CI documentation describing how to get a build status badge
Okay, okay, two badges there most be more, so I did some googling and found CPAN badges, badges indicating the latest release to CPAN…
My personal projects and code have lived a long life. I have been using RCS locally, CVS and SVN. My first public repositories was in my local Perl user group Copenhagen Perl Mongers, where we shared a central repository. It started out as CVS, but was migrated to SVN about the same time as I started uploading distributions to CPAN.
In parallel I also set up a few projects at SourceForge and later at Google Code, both using SVN (SourceForge started out as CVS for me, but migration had taken place at some point). Actually the most important project of mine there was Workflow, which was migrated from a closed SVN repository from the original author Chris Winters to SourceForge.
Anyway – for a long time I worked as a freelancer, dreaming of doing my own software instead of others. So I decided to go for a hosted solution with Versionshelf, I later changed to Atlassian, which at that time had nice product consisting of Jira, Confluence, Fisheye and Subversion (it was actually Fisheye, which let me to this, metadata on code has always intrigued me). All my new projects public and non-public got hosted here, but I still had a legacy stuck at the Copenhagen Perl Mongers Subversion server.
I got Google Code migrated to the Atlassian platform, but stayed with SourceForge because of the project organisation. The Cph.pm repos was a dead end, due to the structure, several attempts at getting the projects extracted properly was unsuccessful.
Then came Github a long and a completely new trend in VCS systems. Not always being a first mover I decided to stay put. I still wanted to migrate my old codebase, but could not find the time to sit down and do it.
Michael Schwern created Gitpan, which seemed like a nice solution, but it was based solely on the releases and a lot of history would be lost (to me a serious loss of meta data). There was even some nice blog posts on how to get the most out of Gitpan.
Workflow got migrated from SourceForge to Github, even though SourceForge hosted Git. I had experienced some issues with the administrative interfaces, which rendered the platform useless in a confusing redirect hell (this has been addressed now).
Atlassian then announced the end of life for their Subversion hosting and migration to Git (Bitbucket/Github) was possible. This was the push I needed and all of my code hosted with Atlassian got migrated, well almost all of it I still have some old customer projects still in a Subversion dump. But all of my open source projects got migrated to Github.
All my new projects now start up on Github. But still I looked at my legacy of distributions on CPAN, which I did not have active repositories for and it haunted me.
The in the summer of 2014 (this summer), I fell over Tony Bowden’s Business::Tax::VAT. I have used Business::Tax::VAT::Validation for some projects and never discovered this module, so I checked it out and it seemed that it had not had any releases in a long time and 3 our of 4 RTs was low-hanging fruit, but no Git repo.
So I mailed Tony Bowden and got COMAINT on PAUSE, we wrote back and forth about Github and we investigated the Gitpan version. Luckily the latest version on CPAN was aligned with Gitpan, so I could pick up from there. Fork, Fix and Free. Got the 3 tickets closed and shipped a release, I had to do additional release when it got picked up by the CPAN testers, but that was nothing when it was hosted on Github.
This struck me as a marvellous situation, so I went back to Gitpan and compared it’s versions of my legacy distributions which was not on Github and I was able to create forks of all of them. Yes, this would mean loss of history, but again I would much rather be able to code and maintain, than not being able to do anything.
So now all of my open source Perl projects are on Gitpan and I am a very happy camper. Maintenance releases will start to go out for most of the legacy and some will be deleted (completely) from CPAN, since they are of no value, but they will still be on BackPAN, Gitpan and for me on Github.
My legacy is under control and I am no longer stranded in migration.
From the MOTIVATION section in the POD of this new policy:
I once read an article which compared programming languages to natural languages. Programming languages in themselves are not large as such, but if you also regard the APIs, data structures and components a computer programmer use on a daily basis, the amount is enormous.
Where I work We try to keep a more simple code base, the complexity is in our business and that is our primary problem area, so it should not be difficult to understand the code used to model this complexity.
So sometimes it is necessary to make a decision on what should be allowed in our code base and what should not. This policy aims to support this coding standard.
This sounds fairly unproblematic and peaceful, but there is a more sinister motivation behind the implementation as well.
After long debugging sessions at the most inconvenient times involving a small set of modules, which causes me too many problems – I decided to write this policy.
Over the cause of time and working in a growing team, we have a constantly growing code base and many takes on how to accomplish things and solving problems. Constantly our code base is breaking and new bugs are introduced and this is all okay and a pretty natural part of software development.
Developers are great!
- They add value
- They add code
- They fix stuff
- They build stuff
- They introduce bugs
- They implement security holes
- They add code
- They break stuff
So sometimes that have to be regulated.
We use peer reviews, not to the extent we should, but we do try and aim try to have this is a part of our SDLC (Software Development Life Cycle). Sometimes we tend to discuss the somethings over and over and perhaps at some point we decide to adjust our coding policy to accommodate the outcome.
My thesis is a that we should use Perl::Critic and Perl::Tidy to enforce our coding standard to the extent possible so peer reviews can focus and can be provide maximum value and we can discuss business, value, security and discover new anti-patterns/patterns, instead of discussing old hat.
So when a certain issue has been observed on more that one occasion, write a policy to enforce a regulation against to address it.
This policy can help you to enforce a regulation when you want to prohibit use of certain modules or even when you want to recommend alternatives.
So if you want to specify a list of blacklisted modules:
modules = Try::Tiny, Contextual::Return, IDNA::Punycode
And if you want to hint at recommendations for use:
modules = Try::Tiny => TryCatch, Contextual::Return, IDNA::Punycode => Net::IDN::Encode
Please note that this is the first shot at the policy, feedback and suggestions most welcome (Github).
Following up on the comments to my blog post on CPAN::Changes and CPAN::Changes::Spec, I created a fork of the distribution on Github and implemented a first shot for the author to evaluate. I sent the pull request yesterday, so now it will be interesting see whether it will be found useful at all.
I did a lot of thinking before starting the actual coding and I was not quite satisfied with the vocabulary I was using to describe the concept. Originally I referred to the concept as impact pointer, but it is simply misleading and not particularly descriptive. So when it occurred to me that the concept was actually hints on how the reader should view the changes and release described it came to me that the obvious name should be “update hint”.
Hints are everywhere and is the term is highly popular these days. Hints are less intrusive and in this case a much better description.
Here is an example lifted from the POD.
0.03 2010−08−01 − update recommended
− Fixed serious bug in bar method
0.02 2009−07−17 − update not required
− Added more foo() tests
− Initial release
I decided for two values of the hint:
- update recommended
- update not required
The first for for releases, which address serious issues/bugs like security fixes, memory leaks etc. the second for releases which are housekeeping releases, updates to tests, documentation, build scripts etc.
As you can see there is no hint for the initial release. I do not want to impose my proposal on the existing specification as such and I well let it be up to the maintainer to decide whether it should be optional and what the actual values should be, my proposal works, but it just a proof of concept and in my opinion it is a nice concept I hope will be adopted.
Please feel free to evaluate my proposal for update hints in the CPAN::Changes::Spec and let me know what you think.
I have been using the Sublime Text 2 editor for some time now. Editors are a funny thing and over the years I have used quite a few different ones: pico, vi, vim, jEdit, BBEdit, TextMate, Komodo IDE and now Sublime Text. I like to have an armory of editors in my toolbox for different kinds of things. An editor for basic fast (right now) text editing, one for longer coding sessions and one for project development with several files of different types.
For a long time I was using a combination of Vim, BBEdit/TextMate and Komodo IDE for the different coding assignments under the circumstances I mentioned above. I later exchanged BBEdit for TextMate at some point and when I got CLI integration running for TextMate I slowly stopped using Vim. I still use the Komodo IDE, since the graphical debugger is a magnificent tool, one I simply cannot live without, but Komodo has longer startup time and is not well suited for short tasks unfortunately.
Hearing all the (b|f)uzz about Sublime Text intrigued me and made me want to check it out. I have read quite a few blog posts and I have watched several video tutorials – and they all say that when you start with Sublime Text you will not want to go back – yeah right!
I must however admit that I am impressed, the editor is flexible, easy to use, incredibly fast and responsive and it is really, really, really easy to customize.
Editors are the primary tool of most developers. Often we spend more time in editors editing code, than we actually do compiling or translating the actual source code. There are many opinions on editors, most developers have a favorite and in addition an opinion on the other developers favorite. Some are quite religious about their editor and mocking or talking about the other editors is not uncommon and most of you already know the funny diagram depicting learning curves for the most “popular” editors.
The depiction is funny, but as it is with most satiric fun, it comes with a grain of truth. I am not going to dig more into the above visualization since I will not attempt to visualize the learning curve of Sublime Text and because my opinion would be subjective and not as funny as the above examples, which I guess are all created with great love/hate to the editors mentioned. I think I can take liberty of writing love/hate since it is with most things you love you really hate when they let you down.
Getting back to Sublime Text I can only say that the editor is growing on me and I do not love it as such and it was not love at first sight since I actually just thought that it was just another editor, but Sublime Text continues to impress me and I feel like it gets better the more I use it and really feels like the editor for me. I do spend time coding, not as much as I would like to, since I am also using the Microsoft Word (editor) for a large part of my work, but luckily I get to do some coding and if not at work then at least when I am not at work.
When watching some Youtube tutorials I fell over the concept of Zen Coding, this was the idea of being able to write code with as few key stroke as possible (not like Perl golf), but getting productivity and speed up utilizing and maximizing you and your editors coding/typing capabilities. The demo for Sublime Text for HTML markup was really impressive and it got me thinking.
Sublime Text has a nice Perl integration, syntax highlighting, it builtin auto-completion can get you a long way and you can install plugins for integration with Perltidy and the plugin SublimeCodeIntel will extend this even further.
Inspired by the Zen Coding demonstration I thought CPAN has a log of APIs, so what would be the most useful ones to play around with for creating cool snippets for speeding up my Perl coding and then it occurred to me, that the modules and APIs I actually use the most are for implementing unit tests using Test::More and Test::Class, I do this across all my distributions and projects and both at home and at work.
So here is my first shot at snippets for Test::More and Test::Class available on Github for you to use with Sublime Text or fork you can fork them to suit your own needs. I am working on getting them made available via SublimeTexts Package control, which requires a pull request to a central repository of metadata, where I am still waiting for approval.
If you are in a situation where you feel like trying out a new editor, checkout Sublime Text, I have only tried version 2 and there is a version 3 on the way, I will not say that “it will not make you want to go back”, since my history of editors is long and proves the opposite and I expect it will continue to evolve, but I can promise you that it will be both fun and inspiring as you discover the nifty features and niceties which gives the sublime in Sublime Text.
This blog acts as a channel for communicating logicLAB’s open source activities. Announcements on open source initiatives, involvements and releases of open source distributions of software products, projects and applications.