Now that I’m writing (a little) more reliably in this blog, I hope to soon revive my “Module Monday” series. At the time I started doing it, it was fairly easy to come up with new modules to review, as I was the owner/operator of a CPAN-oriented Twitter-bot called “
@cpan_linked“. But then Twitter switched over to OAuth-only and I haven’t had the time and energy at the same time, in order to update the bot.
But I still frequently look at new and interesting modules, always looking for new tools with which to fill my Perl toolbox. Here are some that I am currently reading up on and/or playing with:
I learned of this module from this blog post, and am both intrigued and frustrated. Intrigued, because I’ve always felt that changes-files needed to be electronically parseable so that the information could be re-purposed to other uses and formats. But also frustrated, because I wrote something similar to this a while back (
App::Changelog2x, which is based on an XML format I designed), which as far as I can tell only I have ever used.
Mind you, I’ve known that ChangeLogML has drawbacks from the very start– for one thing, authoring in XML is a HUGE pain in the ass. I’ve only just recently gotten my emacs set-up to handle ChangeLogML very well, and for that I had to first convert the XML Schema to RelaxNG, then that to the compact format, then hand-edit the resulting RNC file to get around things that hadn’t converted correctly (though one or two of them may have been problems in the original XML Schema, to be fair). Even still, with all that, I’m still editing raw XML. I just have syntax highlighting and validation to help me find errors. And a lot of people just don’t like dealing with XML, let alone editing it by hand.
ChangeLogML keeps more information than the
CPAN::Changes::Specspecification does, but mine doesn’t have the concept of groupings, something I may look at trying to add if I ever revisit ChangeLogML and try to make it more useable.
One thing I’ll look at either way, is transforming ChangeLogML to a conforming “Changes” file for my modules. That should be a lot easier than convincing people to hand-edit XML on a regular basis.
Being easily distracted and fascinated by blinking lights and colors, this tool just amuses me greatly. That is is also incredibly useful is a great bonus.
It’s a module from Damian Conway, and I learned about it recently when he included it in a talk he gave to the London Perl Mongers group. I couldn’t go (the commute from California to London being prohibitive and all), but Damian was helpful in posting a follow-up message to the mailing list with a list of the modules he had discussed. I had already taken some interest based on the “Regexp” in the name, as I’m not the best wielder of regular expressions in the Perl world, so I often need debugger-ish tools to fall back on. But just to make it even better, in response to a comment by someone else, Damian followed up his list of modules with a YouTube link to a demonstration of the module.
Watch the video, and I’m sure you’ll be as interested in this module as I am. Note that this dates to 2012, and there have been several releases and new features since then.
I’m grouping these together as one provides a foundation that the second one builds upon.
Test::Trap, by Eirik Berg Hanssen, is an interesting approach to testing code in terms of blocks. You pass “
trap” the block to execute, and it handles the
evalmechanics for you, with the results and any error information wrapped in an object (called “
$trap” by default). There’s a great deal of flexibility and configurability here, as well.
Test::Effectsis another module from Damian, one that builds on
Test::Trapwith an interface that lets you test all the effects of your code-block in one go. Where the former module would have you pass the block to
trap, then choose what to test against using
$trap, this module gives you a testing routine called “
effects_ok” that looks at everything, or alternately just those things you want looked at. It is also extremely configurable, including some options that may make my long-neglected
Lastly (for this listing, at least), is the well-known
Mojoliciouspackage. I’m kind of late to the game on this one, as it has been around quite a while. A co-worker of mine has used it some, and convinced me to give it a look for some web-services applications I’ve been tinkering with. What interests me the most about it is the built-in support for WebSockets, something Apache doesn’t have (and doesn’t seem to be planning for any time soon). I’m currently looking at how easily I can use it in different styles of event-loop processing, as the main place I’d like to use it would be an application that has to manage both an HTTP event-loop and a separate client/server socket simultaneously. (At this point, I don’t yet know how the other socket works, or if it will play well with others. So Mojo might end up not being the deciding factor in that after all.)
So, there are five new modules that I’m currently focused on, any of which might end up getting their own post some day. Here’s hoping that one or two might be of interest to other readers.