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 26th, 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!
