Personal end-of-year report for 2012

Previous end-of-year report for 2011. Previous quarterly report: Apr-Jul 2012.

2012 is my most productive year yet in my "CPAN career": 943 releases (compared to 495 in 2011). That's about 2.5 releases per day! So far I have about 215 distributions under my account, almost half of them (96) are new modules in 2012. The reasons the number of distributions is high include: Perinci modules family being split into many distributions (and then some, to avoid recursive dependencies problems that I seem to keep bumping into), the various Task distributions, and also the fact that releasing CPAN modules is so darn fun! A little too much fun, I'm afraid.

My data validation library, Data::Sah, is already usable (though currently broken in the last several weeks). I am already using it to validate function arguments and get it involved in the module releasing process. The performance is very satisfactory. Being compiled into direct Perl, it surpasses every existing validation framework on CPAN that I know, from the slow ones like Validation::Class and Data::Domain, to the so-so-performing ones like Data::FormValidator, and lightweight/do-little ones like FormValidator::Lite, to Params::Validate. I expect to formally introduce it in the next month or two.

Haven't begun writing any significant code for my form handling library, ReForm, but expect to get at it after Data::Sah gets enough features.

Summary of the work I did between Jul-Dec 2012:

Some reflections:

  • The whole Rinci transaction thing. I started this work because I hoped to use it in a transactional software installer and configuration management tool. And also at first because I wanted to write some command-line tools for ledger to add transactions from the command-line. That ledger tool is not yet written until today, and I've also come to the decision that I don't want to include transactional capability to the configuration management tool. Yet I spent at least two months defining and refining the transaction protocol. All is not wasted, though, writing the specification is a nice exercise, nevertheless.

  • Releasing patches to modules as patch-modules instead of (or in addition to) submitting them to the original modules. I like this approach because submitting patches to CPAN modules in my experience is a lot slower and far less deterministic process. I get less than 50% response rate from the original authors and even then the responses often come in an untimely manner (say after over 1 month). Releasing the patches as patch modules is an express publishing mechanism that allows me (and others) to use my work immediately in applications.

    I hope to continue doing this, and even hope others might pick up the habit.

To be honest, I really don't expect to release as many CPAN modules/distributions in 2013, but who knows?

Here's to a happy new year and a productive 2013 all year long.


What do you mean by "Releasing patches to modules as patch-modules instead of (or in addition to) submitting them to the original modules.", could you please explain?

If you actually care about a dist, you need to actually do some sleuthing at times and try and find ways to contact them more directly other than with an easily ignored ticket. This will not only raise the chances of actually getting things fixed, but also lays the groundwork for the module take-over process. In your example of Time::Duration it seems like you'll get much further if you simply ask him on facebook ( ) if he'd give you comaint on PAUSE. Then everyone wins and we don't need to have timebomb modules sitting on CPAN.

Leave a comment

About Steven Haryanto

user-pic A programmer (mostly Perl 5 nowadays). My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.