Recently in perl Category

entry originally published on the Pythian blog.

Recently, hanekomu was contemplating how to make subsequent installs of a Task::BeLike module upgrade its dependencies to their latest version.

The idea is intriguing. It’s not something you want to do for a typical module, but it makes sense in the context of Task::BeLike. If you care enough about a module to put it in your Task::BeLike, you probably care enough to want to upgrade when there’s a new version out there.

Alas, I think hanekomu’s proposed way of doing it is flawed (mind you, the debate is still going on as of the writing of this entry, and I can very well still be proven wrong). But after some pondeferous chin scratching, I might have come with a cunning alternative to it.

Let’s say that in your Build.PL (the logic would be the same for a Makefile.PL) you have your dependencies stashed in %dependencies. Something akin to:

%dependencies = (
    XML::LibXML      => 0,          # any version will do
    XML::XPathScript => '1.42',     # 1.42 or higher
    Moose            => 'latest',   # nothing but the shiniest!
);

All we want to do, really, is to switch the latest for, well, the latest version available. Surprisingly, that something that is almost as easy to do than to say:

for my $mod ( keys %dependencies ) {
    next unless $dependencies{$mod} eq 'latest';

    require CPANPLUS::Backend;
    state $cb = CPANPLUS::Backend->new;

    $dependencies{$mod} = $cb->module_tree( $mod )->package_version;
}

Yes, that’s really all there is to it. A little further hacking later, I have incorporated the functionality to my own Task::BeLike::YANICK module. The way I implemented it, installing the module the usual way will yield no surprise (i.e., dependencies already present are not going to be updated). But if the environment variable TASK_UPGRADE is set to true, like so:

TASK_UPGRADE=1 cpan -f Task::BeLike::YANICK

 . . . then the magic is going to be unleashed (the -f is to force the re-install, if the Task has already been installed before).

Alternatively, just to know which dependencies are out-of-date, one can also extract the distribution and do a

perl ./Build.PL --upgrade
./Build prereq_report

entry originally published on the Pythian blog.

picture by Geophaps
Hey, that one in the sixth row…
Doesn’t he looks familiar?

So there I am, on my morning bus ride, reading my copy of The Definitive Guide to Catalyst (keep your eyes peeled for the upcoming review of the book in the Perl Review).

I’m near the end, in Chapter 11, Catalyst Cookbook. As it is with most tech books, the last chapters are the most engrossing, as the gloves finally come of and the writers throw at you all the wonderful, mind-bending stuff that the rest of the book prepares you for.

The section I’m at is about the development process. Specifically, it shows how you can put hooks in your versioning system to automatically screen commits to conform to Perl::Critic and Perl::Tidy policies. The given example script uses Git, which is just dandy with me as it is my current VCS of choice. But there’s something . . .  funny about that script. The way the utility functions are stashed at the end after a

### utility functions ##############################

line. The choice of variable names. The comments. It all feels oddly familiar. And then my eyes fall on the line

exit 0 unless @dirty; # Alles gut

and everything falls into place. The script in the book is a wee bit different and has been improved upon, but its origin is unmistakable. Somehow, unexpectedly, a hack of mine found its way into publication. Fame, glory, and page 293 of the Catalyst book, I can finally claim ‘em all as rightfully mine!

But, serendipitous glee aside, three important lessons lie in this little story.

1. Blog posts, great and small, the Perl Gestalt, it reads them all

All clever tricks, code snippets, and insights you come up with? Blog ‘em. Even if you think they are only an itsy widdly little bit clever. Chances are, if there is a spark in there, it’ll ignite the mind of someone insaner than you are and ultimately result in something awe-inspiring. Or, more importantly, something awe-inspiring for which you’ll have bragging rights.

And don’t despair if your blog entries mostly go without comments. Provided that you are broadcast by an aggregator or two, people will read you. Silently, furtively, your thoughts will slip in the Perl subconscious like so many pumpkin seeds into autumn soil.

2. Code carries your DNA

No big discovery here, but it’s interesting to see how surprisingly easy it is to recognize one’s own code. One would think that nothing looks more like a line of code than another line of code, the same way nothing looks more like a baby emperor penguin than another one.

Yet, we do recognize ours by a curve of the beak, a specific timbre of the voice. Admittedly, Perl’s flexibility provides much more latitude for transposing our idiosyncrasies unto our digital babies. But then again, isn’t why a lot of us love Perl so much?

3. Some of my code made it into a Catalyst book!

I mean, seriously, how terminally cool is that?!

In the last three months, I've been eerily quiet both on my blog (it's been so long, I'm afraid I'm going to bolt straight past Paper Man and end up Pulp Man) and on the module front. Ironically enough, this long silence has actually been caused by events in my life that have Perl plastered all over them.

In a nutshell, after 11 years of working in the telecom industry, I've decided to take the plunge and try something different. As of the end of July, I've switched allegiance to The Pythian Group. They are a company specializing in database support, and they happen to use Perl-based internal tools. Which is where, as the astute reader may surmise, I enter the picture.

So, no more watching from the peanut gallery for li'll old me -- we'll now see if I can make a living out of that Perl stuff.

No need to say, I'm in equal part thrilled, exhilarated and terrified of what lies ahead. Hopefully, my new colleagues will feel the same way before long. :-)

The talks of the last perl Monger meeting are now available online for your viewing pleasure. In addition of the classic decks of slides, thanks to Andrew Ross of the FOSSLC we also have full-fledged recordings of the talks:

• Tim Procter's ''Portable Perl Daemons'': audio-visual extravaganza or just the slides.

• Your truly introduction to Moose: audio-visual extravaganza or just the slides.

Enjoy!

The Ottawa Mongers meet this month!

On the program, we have a Monger special edition of the Moose talk I gave at the FOSSLC Summercamp last week, and Tim Procter of the Pythian Group will give a talk about Perl Daemon Processes.

Location and Time

The meeting will take place Tuesday May 26^th, at 7:00pm. We'll be at the Pythian Group office (Suite 1000, 116 Albert Street).

If you plan to come, please let me know so that we make sure we can accommodate everyone.

Ever since Perl 5.10 came out, my soul is torn asunder by a particularly prickly dilemma.

On one hand, my love of shiny new toys urge me to go forth and use the new features of 5.10 to their full extent so that my code is clean, concise and, most important of all, spiffy.

On the other hand, my insatiable thirst for glory dictates that I should strive to make my modules accessible to the widest range of configurations possible. In that light, setting the requirement bar to Perl 5.10 is a severe drawback. Kinda like longing for world domination, but restricting oneself to invade only countries with names beginning with 'M'.

So far I pretty much went the 5.8-compatible way. But the call of the shiny is becoming just too strong, and from now on I'll try a new approach.

Conceptually, I'll divide my modules into two categories: modules that are for general consumption (WWW::Ohloh::API, XML::XPathScript, etc), and modules that are tools for developers (Dist::Release, Git::CPAN::Patching, Test::Pod::Snippets).
The formers, I'll keep 5.8-compatible. For the latter, though, I'll go on a limb and assume that they'll be used on development machines. Machines that can afford -- nay, should be expected -- to have a Perl 5.10 binary stashed somewhere.

Now, my only hope is that by doing so I'll not alienate my user base. Well, not exactly: I also hope there is actually a user base to alienate in the first place. :-)

(by the by, I joined the fun and accepted the Perl Iron Man Challenge.)

As assiduous readers of my blog may recall, last year I gave a 35 minutes Perl introduction at OSBootCamp 8. For unphantomable reasons, I've been asked to come back and recidive for FOSSLC Summercamp 2009, which is happening on the 13, 14 and 15 of May.

This time, my talk is going to be an introduction to Moose. Why Moose? Since my goal is to hook unsuspecting students on Perl, I figured the easiest way to tip them to the dark side would be to show those java-tainted young minds the latest and shiniest OO coolness that the Perl community has to offer.

Sorry, what? ... Didn't I mention in a previous blog entry that I prefered Object::InsideOut over Moose?

Ah... Hum... Well, yes, true, I might have said that... (darn those assiduous readers)

Mind you, I still think that Object::InsideOut is a very fine module indeed, but several things made me progressively slide in the Moose camp:

• Moose has an incredibly strong momentum in the community.
  Notwithstanding the fact that when so many bright people get excited about something, it's usually for a good reason, it also means that Moose development is thriving. And not only core development, but extensions are by now abounding.
  And this, for my little lazy heart, is true bliss. The MooseX namespace is quickly growing into a mini OO-CPAN.

• At the time, I was arguing with Yuval that I had no need for those cute 'before' and 'after' method modifiers. Ah! That was before I seriously tried using them...

• Roles. Those things are dangerously addictive. And they do such a damned good job of simplifying one's code.

• MooseX::Method::Signatures, Moose types, coercion, and the myriad of other things that all work together to move the tedious bits of coding out of the way, and to fragment the good parts into small, easy to understand/maintain pieces.

• Meta-programming. Pure mad scientist type of fun. How can I possibly resist?

So yeah, I call on my right to change my volatile mind. Color me a new Moose adept. And, hopefully, I'll similarly be able to color some more converts this Friday. Wish me luck.

This week I finally got a good excuse to go on and dabble with Moose meta-programming. In my WWW::Ohloh::API classes, a lot of attributes take their values from an initial xml snippet. The original, naive way those values were extracted was along the lines of:

has xml_src => (
    is   => 'ro',
    isa => 'XML::LibXML::Node',
);

has created_at => (
    is         => 'ro', 
    lazy      => 1,
    default => sub {
        return $_[0]->xml_src->findvalue( 'created_at' );
    }
)

has sender_account_name => (
    is          => 'ro', 
    lazy      => 1,
    default => sub {
        return $_[0]->xml_src->findvalue( 'sender_account_name' );
    }
);

Not harrowingly horrible, but rather repetitive. I figured out it would be much niftier to provide the name of the attribute holding the source xml and the pertinent xpath, and let Moose magic take care of the rest. Something like:

has created_at => (
    metaclass => 'XMLExtract',
    is => 'ro', 
    xml_src => 'xml_src',
    xpath => 'created_at',
)

Well, turns out that once one knows how, this is fairly easy to do:

package XMLExtract;

use Moose;

extends 'Moose::Meta::Attribute';

has 'xml_src' => ( isa => 'Str', );

has xpath => ( isa => 'Str', );

has '+lazy' => ( default => 1 );

before '_process_options' => sub {
    my ( $class, $name, $options ) = @_;

    die "attribute '$name' in class '$class' must be lazy-evaluated\n"
    if defined $options->{lazy} and not $options->{lazy};

    my $src = $options->{xml_src} ||= 'xml_src';
    my $xpath = $options->{xpath} ||= $name;

    $options->{default} = sub {
        return $_[0]->$src->findvalue($xpath);
    };

};

1;

If you notice, I've set 'xml_src' and 'xpath' to default to 'xml_src' and the name of the current attribute, so that the code can be further simplified to

has xml_src => (
    is   => 'ro',
    isa => 'XML::LibXML::Node',
);

has created_at => (
    metaclass => 'XMLExtract',
    is => 'ro', 
)

has sender_account_name => (
    metaclass => 'XMLExtract',
    is => 'ro', 
);

Short, sweet and to the point. Now we're talking code I like!

OS Bootcamp is a cool initiative to inform and initiate university students to the wonders of the Open Source world.

OsBootCamp 8, which took place on August 28th, was about interpreted programming languages. On the agenda were short introductions of the three big kids on the block (Perl, Python and Ruby).
And yup, the honor to ramble about Perl was given to li'll old me. For the morbidly curious, there's a video of the resulting show. :-)

Everybody is raving about Moose these days, but I must say that I still prefer Object::InsideOut. One of the things I love about OIO is its extensive documentation (70 glorious pages worth of pod!). One of things that I find daunting about it is, well, finding back the attribute I'm looking for as I thumb through those seventy-something blasted pages.

So I made myself a cheatsheet. It's not complete yet, but it's already containing what most mortals would use on a daily basis.

(btw, I've used Scribus to generate the 3-fold. Although I really, really want to like that software, I must say that it makes me miss Quark XPress real bad. If anyone has any suggestion for an alternative Desktop Publishing tool, please feel free to let me know.)