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:
- Finally get Data::Sah to the point of usable.
- Rinci: rewrite transaction specification. Now everything is a bit clearer and saner. No more 'steps' nonsense or a framework just to write a simple transactional function. Implement a few modules using this: File::{Truncate,Trash,Append,Prepend,Patch}::Undoable, Setup::File::TextFragment.
- Riap: introduce schemes riap+unix and riap+pipe. Enable easy creation of API service over piped program, SSH.
- Write new specifications: DefHash, IOD (INI file format, split from Config::Ini::OnDrugs)
- Make Text::sprintfn twice faster, though I would really like to make it 10x faster.
- Add command-line program and more options to Bench to make it more usable and convenient.
- New modules: a couple of release tools App::LintPrereqs and App::HasPrereqs, Data::Clean::JSON to replace slower code that uses Data::Rmap, Unix::Passwd::File to replace Passwd::Unix::Alt, Monkey::Patch::Action, Perl::Stripper, Progress::Any (blog post), YAML::Tiny::Color, JSON::Color, File::Write::Rotate.
- Proofs of concept: Software::Catalog.
- Several patch modules (and some more).
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?
Please read: https://metacpan.org/module/Module::Patch
Examples of patch modules (from this blog post):
http://metacpan.org/module/HTTP::Headers::Patch::DontUseStorable
http://metacpan.org/module/Log::Any::Adapter::Core::Patch::UseDataDump
http://metacpan.org/module/Log::Any::Adapter::Core::Patch::SetDumperIndent
http://metacpan.org/module/Time::Duration::Patch::Millisecond
This might also be a somewhat relevant example:
https://rt.cpan.org/Public/Bug/Display.html?id=81960
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 ( http://www.facebook.com/skrewtape ) if he'd give you comaint on PAUSE. Then everyone wins and we don't need to have timebomb modules sitting on CPAN.
Just an update: Time::Duration 1.1 was finally released on Apr 2. It seems a couple of nudges from other users in the ticket are needed though :)