Sérgio Bernardino :: Uploaded

Hartverdrahtet – Infinite complexity in 4096 bytes Worthy...

Fri, 11 May 2012 17:32:54 +0100

Hartverdrahtet – Infinite complexity in 4096 bytes

Worthy winner of the PC 4kB intro competition at Revision 2012 and latest example of the compact-coding tradition exercised within the demoscene, Hartverdrahtet by Akronyme Analogiker is a three minute long audio-visual trip into a procedural fractalverse, compressed into a minuscule piece of software.

No bigger than 4069 bytes – less than an empty Word document, as demoscene activists like to point out – the executable file contains all the mathematics needed to generate the unfolding visual complexity and audible ambience upon a double-click.

Absolutely amazing.

"Say you’re in the kitchen in front of the refrigerator, thinking about a sandwich. You take a..."

Mon, 26 Mar 2012 00:13:00 +0100

“

Say you’re in the kitchen in front of the refrigerator, thinking about a sandwich. You take a ‘continuation’ right there and stick it in your pocket. Then you get some turkey and bread out of the refrigerator and make yourself a sandwich, which is now sitting on the counter. You invoke the ‘continuation’ in your pocket, and you find yourself standing in front of the refrigerator again, thinking about a sandwich. But fortunately, there’s a sandwich on the counter, and all the materials used to make it are gone.

So you eat it. :-)

”

- “The Continuation Sandwich: explaining first-class Continuations”, perl.perl6.language

in flight

Sat, 10 Mar 2012 20:45:00 +0000

in flight

The Most Astounding Fact “… when I look up at the...

Tue, 06 Mar 2012 21:10:24 +0000

The Most Astounding Fact

“… when I look up at the night sky and I know that yes, we are part of this Universe, we are in this Universe. But perhaps more important than both of those facts is that the Universe is in us.

When I reflect on that fact, I look up - many people feel small because they’re small and the Universe is big - but I feel big, because my atoms came from those stars.

There’s a level of connectivity.

That’s really what you want in life, you want to feel connected, you want to feel relevant, you want to feel like you’re a participant in the goings on of activities and events around you.

That’s precisely what we are, just by being alive.”

— Neil deGrasse Tyson

“They don’t advertise for killers in the newspaper....

Fri, 02 Mar 2012 10:56:00 +0000

“They don’t advertise for killers in the newspaper. That was my profession. Ex-cop. Ex-blade runner. Ex-killer.”

— Blade Runner (1982)

I, for one, welcome our new plain text overlords

Mon, 27 Feb 2012 10:22:00 +0000

I, for one, welcome our new plain text overlords:

Markdown is text, just plain text. Its the one format that has not changed over all the years. Oh sure, we’ve gone from a 7-bit ascii code to UTF-8, but all text editors happily handle the old text formats. And when they stop, a small C program will fix it.

Plain text, and therefore Markdown, are as future-proof as you can get in computing.

Since I can remember I’ve been acutely sensitive to file format lock-in, for all the reasons ranging from portability, to maintainability, and future-proofing. Plain text has always been my format of choice for anything involving writing.

In that context, Markdown (or any sort of light-weight markup language for plain text, in fact), is nothing new or revolutionary. It has, however, become increasingly popular this past few years, and it is a trend that I find most welcome.

The more people rave about it as the pinnacle of data portability, the more tools spring out of the woodwork to support it, and facilitate its creation, editing, and consumption. And that’s great!

Tools like iAWriter, TrunkNotes, and plain old - reliable - vi, are common-place (and increasingly valuable) in my daily workflow¹. This post itself has been written with Markdown formatting, and on the day the format is replaced by “The Next Big Thing (TM)”, all the time I spend buried away in Perl code should keep me, and my data, safe enough².

All of it tightly weaved up around Dropbox, unsurprisingly. ↩
Not accounting for other side effects from prolonged exposure to Perl code, of course ;-) ↩

Recursively delete specific files within a directory tree

Sun, 26 Feb 2012 19:22:00 +0000

Here’s something I find myself needing time and time again, but never seem to have the accurate syntax at the tip of my fingers.

Suppose you have a complex directory hierarchy, with several different types of files within it, in which you want to remove all files of a specific format. How does one accomplish this with a single command?

You simply pipe the output of ‘find’ into ‘rm’, like so:

    find . -name '*.log' -exec rm -i "{}" \;

The double quotes are needed if the names within the hierarchy have white-spaces, and the escaped semi-colon is required to close the ‘exec’ statement.

"As I learned more about how these early role-playing games worked, I realized that a D&D module..."

Thu, 12 Jan 2012 14:30:00 +0000

“As I learned more about how these early role-playing games worked, I realized that a D&D module was the primitive equivalent of a quest in the OASIS. And D&D characters were just like avatars. In a way, these old role-playing games had been the ﬁrst virtual-reality simulations, created long before computers were powerful enough to do the job. In those days,if you wanted to escape to another world, you had to create it yourself, using your brain, some paper, pencils, dice, and a few rule books. This realization kind of blew my mind. It changed my whole perspective on the Hunt for Halliday’s Easter egg. From then on, I began to think of the Hunt as an elaborate D&D module. And Halliday was obviously the dungeon master, even if he was now controlling the game from beyond the grave.”

- Ernest Cline, READY PLAYER ONE (2011)

Dungeons & Dragons - The Way Forward

Wed, 11 Jan 2012 15:00:00 +0000

Dungeons & Dragons - The Way Forward:

I stopped playing D&D during the transition from the 3.5 Edition to the 4th¹. I was somewhat burned out after playing the former for a long period of time without meaningful interruptions, and the new mechanics introduced by the latter did not grip me at all.

To see news of Wizards (or should I say, Hasbro) planning a new major edition a mere three years after the debut of the Fourth Edition (by comparison, the gap between the 3rd and 4th was eight years, with the 3.5 revision showing up roughly mid-cycle) really rings alarm bells to me. It looks clear now that the Fourth Edition wasn’t all that successful in stopping the increasing loss of players to the digital RPG front (such as MMO video games), and the like.

Having them boast that, this time around, what the community wants truly matters to them is just silly, and Penny Arcade nails the “why” perfectly. People who are really serious about pen & paper roleplaying games aren’t at all aligned with what Wizards really needs: people willing to spend unreasonable amounts of money on renewing their core book sets and on increasingly contrived accessories like cards and miniatures.

You can catch up on that experience, through some writing I did during that time, on Draconus Dictum. It’s only available in Portuguese, though. ↩

rocket

Sun, 18 Dec 2011 18:32:00 +0000

rocket

“The 9000 series is the most reliable computer ever made. No...

Mon, 21 Nov 2011 10:29:00 +0000

“The 9000 series is the most reliable computer ever made. No 9000 computer has ever made a mistake or distorted information. We are all, by any practical definition of the words, foolproof and incapable of error.”

— 2001: A Space Odyssey (1968)

The Codebits Experience

Thu, 17 Nov 2011 12:42:00 +0000

If I wanted to surmise the Codebits experience into one simple word, it would be this: more.

One goes to Codebits looking for knowledge, and leaves it craving more. One enters Codebits with a set amount of friends, and surely leaves it with even more. One reaches Codebits expecting to have fun, and ends up having more. In short, every time a Codebits edition ends, it leaves everyone waiting for more.

Codebits 2011

Codebits is already in its fifth year, and although I missed the first two editions, since my visit in 2009, I’ve made an effort not to miss another one. To be sure, it’s not as trivial as just saving time for it. One has to earn the privilege of attending, and I have been fortunate enough to have done so. With three consecutive editions under my belt, I can say with considerable certainty that it really is a memorable experience that has only gotten better throughout the years.

Being an event deeply rooted in technology and (mainly) the Internet, it undeniably has a very specific target audience. I have found, however, that there is a bit of everything for everyone with an inquisitive disposition, and that the only two real prerequisites are the willingness to learn, and to have fun doing so. From there, the Codebits aura of sheer raw energy will make sure you’ll feel more than welcome.

And you are welcome

Any geek worthy of the name has a weak spot for tech-related swag¹. We all have more t-shirts, pens, notepads, and USB keys than we need or care for, but those short moments after getting the welcome kit are like a small piece of Christmas right then and there on the show-floor.

The Codebits organization has turned this into a relevant part of the experience by systematically upping the ante every year, to the point where the kit is riddled with actually useful stuff. Even the more negligible bits have the purpose of serving as teasers for what’s to come.

Is the LEGO League present on the venue? Add an amusing “Top Secret” envelope with a random piece to make you wonder about it. Will there be workshops about Arduino? Add a tiny kit with a LED and a sensor to spur you on. Which T-shirt did you get this year? The artwork in each is random, and I do think I like that guy’s pick of the draw more than I do mine…

At a glance, it all sounds like minor stuff, but it’s smart, and works for a killer first impression.

This year, the most surprising piece of swag in the package (for me) turned out not to be swag at all, but a very valuable offer. What seemed at first as “yet another useless USB key”, proved to be something entirely different: An individual Yubikey for each an every attendee.

Used as a way to actively promote SAPO’s new two-step authentication feature in its unified login process, a Yubikey is much more valuable than that when you consider Yubico’s developer-friendly demeanor. By exposing a web API with which to use the Yubikey, the possibilities are immense².

Might as well use that O’Reilly coupon, also found inside the classy Codebits laptop backpack that wrapped the complete package, to get a free ebook that helps out with these ideas.

They shower us with gifts. And we love it.

Home Away From Home

Despite being backed by very important companies from the local Portuguese technology spectrum (and beyond), I believe that Codebits is much more than just a venue where people go to publicly demonstrate their highly tuned technical, and business, skills, or to be charmed into any random corporate recruitment process.

Codebits is a celebration of everything that surrounds the geek culture when related to technology. Be it the hacker’s spirit of constant tinkering and reverse engineering, the unquenchable thirst for the most recent shiny piece of hardware, or the love for retro-computing. Sprawling from any recognizable Internet phenomenon, to the most inscrutable memes, and even common pop culture (like movies, TV shows, music, or books). Codebits has all this, and it’s proud to showcase it in every corner, and at every opportunity. It wouldn’t stand for it to happen in any other way.

From serious corporate keynotes, to insane gauntlets in which participants are charged with presenting esoteric (even borderline nonsensical) keynotes they’ve never even seen before, to a full-fledged Quiz Show: the venue’s Main Stage has it all.

Game consoles are conspicuously placed in areas with a lot of foot traffic, you see people gliding effortlessly about on home-made skate boards, and anywhere you go you’re likely to cross paths with a tiny fledgeling robot built exclusively for the purpose of exploring these unique surroundings, as if it just happened to have landed on Mars.

At a pre-determined time in the schedule, people drop everything they are doing, and line up to have a taste of an outlandish dish: It features the hottest chili pepper in the world, and to eat it is an experience that’s described as nothing short of incredibly excruciating. But some venture forth, and return grinning (albeit in pain) with the priceless “badge of honor” proving that they were one of the few that did it.

All of this, and much more, under the backdrop of green-tinted walls, enormous screens flashing an assortment of items (from schedule news, to Twitter updates), and the constant buzzing of voices from those merely chatting, those embroiled in their projects, or even the speakers dishing out their knowledge in any of the secondary stages.

There’s a lot of laughter permeating through Codebits. People are happy to be there. And comfortable. For the geek, it’s a home away from home.

And yet, it works

But let’s not get too carried away. Work does happen within the walls of Codebits. Serious work. Ideas flow and plans are sketched and executed. Some are bad, some are good. Some make it to the end, some don’t³. A few win, and the rest go back to the drawing board and hope to make it big next year.

As expected from a hackaton of this caliber, computers are everywhere⁴, and you’ll constantly see scores of faces focused on streams of text in a screen. Flip-charts exist, riddled with sketches, designs, flowcharts. Those ideas considered bad are promptly torn and discarded, in a race to meet the deadline. Everyone wants to reach the finish line, and in the best shape possible.

You’ll be hard pressed to navigate the wide sea of large desks, occupied chairs, cables, and exhausted people sleeping on bean bags, when the talk you want to attend is precisely on the other side of the working area. It’s a tight space, for so many eager.

It all climaxes in a massive final presentation where each of the competing teams is given an incredibly short window of time to prove their worth, as the audience watches and votes, and the jury listens and ponders.

It’s not an easy thing to watch. The system isn’t perfect, and you witness glitches and such technical problems you can’t help but to wonder why they still happen after 5 years of supposed fine-tuning. 90 seconds is indeed a very short timespan, but when you multiply it by dozens of projects, it wears you down. The teams frailties and exhaustion are laid bare in those precious seconds, and you (if indeed you care) have to endure through all the poorly prepared speakers, failed live demos, and incredibly flat attempts at humor.

Neither is it easy to present. In fact, it’s not easy at all. Everyone knows that the margin for success is incredibly thin. That no matter how good your project is, if you fail in that key moment, it’s all over. Compressing 48 hours of intense work into 90 seconds of supposed genius, in front of a highly skeptical (and tired) audience, is the worst (and takes a special kind of talent).

Quite a few crash and burn spectacularly. Like a slow motion car wreck you’re horrified to witness, but can’t seem to avert your eyes from. You feel sorry for the guy, and you’re glad you’re not him.

On the flip side, a talented few shine as bright as the rising sun on a hot summer day. People spontaneously burst into cheers and impromptu rounds of applause. You’re glad for that guy, even a bit envious, and you do wish you were the one to whom that happens. Everyone does.

There are prizes, of course. To the victors go the spoils, and what a rich bounty it is: From premium priced computers and tablets, to smart phones and even huge television sets that simply can’t be easily hauled off the stage. You barely notice the expensive books also being haphazardly given away. It’s so crazy, it reaches TV game show proportions.

It all combines into a powerful machine that drives you more and more towards wanting to be a part of it. You want to be on that stage and shine.

In The End

There is a whole lot left unsaid, with many things yet to mention⁵. The clichéd expression “you had to have been there” repeatedly comes to mind, and though it pains me to use it, it is quite appropriate.

Codebits is unique in the way it winds you up into a twisting ball of excitement, as much as it drains you of your much needed energy. You wake up the following day, thanking for it to be a Sunday, feeling like you just took an enormous beating.

But you regret nothing, and always come back to ask for more.

“Stuff We All Get” : The assorted promotional merchandise offered in venues such as this. ↩
From using their PAM module to reinforce remote server access, to port-knocking, it was enough to set my brain into overdrive. ↩
Mine didn’t, to my dismay. A tale for another time. ↩
On that note, the amount of Apple computers at the event was absolutely staggering. ↩
There’s a world of material concerning all things #softwood, and a certain group of crazy lobsters, but unfortunately… we lack the time ;-) ↩

focused writing

Thu, 17 Nov 2011 00:37:00 +0000

focused writing

Errors when Installing DBD::mysql on Mac OS X

Wed, 16 Nov 2011 17:33:00 +0000

For some reason, installing DBD::mysql on Mac OS X is the source of much grief. There are countless blog entries, forum posts, and Stack Overflow questions floating around about this very same issue.

Obviously, it was only a matter of time until I was afflicted by this and end up losing hours of valuable time trying to puzzle out the proper solution. But fortunately I got it working, so I’ll add what I’ve found to the countless bits of information already in the “pile”.

“Symbol not found”

I’m assuming you’re not using the system’s default Perl installation¹, and that you’ve installed the default MySQL binaries for your architecture from dev.mysql.com. The issue manifested itself to me on Snow Leopard, but I’ve no reason to believe (so far) that in Lion the behaviour is any different.

With Perl and MySQL properly installed on the machine, you move onto installing DBD::mysql². It should build fine and begin testing.

At this time, you might get errors similar to this:

Error: Can't load './blib/arch/auto/DBD/mysql/mysql.bundle'
  for module DBD::mysql:
    dlopen(./blib/arch/auto/DBD/mysql/mysql.bundle, 2):
      Symbol not found: _is_prefix

or it might vary slightly, showing you this:

Error: Can't find 'boot_DBD__mysql' symbol in
  ./blib/arch/auto/DBD/mysql/mysql.bundle

Now, this only happened to me when I tried to install the module manually (after the tests failed when loading the client library - more below)³. If this is your case, first and foremost, make sure you’re invoking the configuration command correctly.

This is WRONG:

perl Makefile.PL --libs="-lmysqlclient -L/usr/local/mysql/lib"  \
--cflags=-I/usr/local/mysql/include

This is RIGHT:

perl Makefile.PL --libs="-L/usr/local/mysql/lib -lmysqlclient" \
--cflags=-I/usr/local/mysql/include

Notice the subtle difference in the order of the parameters.

In these circumstances, the best idea is to collect the adequate values like so:

~/ $> mysql_config --libs      
-L/usr/local/mysql/lib -lmysqlclient   -lpthread

~/ $> mysql_config --cflags
-I/usr/local/mysql/include  -Os -g -fno-common -fno-strict-aliasing -arch x86_64

Copying the information from this source will guarantee that you’ll avoid mistakes like the one I did above.

“Library not loaded”

But even if you aren’t affected by the errors above, chances are that you’re being greeted with this particular message:

Error:
    Can't load './blib/arch/auto/DBD/mysql/mysql.bundle'
  for module DBD::mysql:
    dlopen(./blib/arch/auto/DBD/mysql/mysql.bundle, 2):
      Library not loaded: libmysqlclient.18.dylib

This means that the compiled bundle is looking for the client library in the wrong place. You can correct this by fixing the reference in the bundle itself with the command:

sudo install_name_tool -change libmysqlclient.18.dylib  \
/usr/local/mysql/lib/libmysqlclient.18.dylib  \
./blib/arch/auto/DBD/mysql/mysql.bundle

Or you can make sure it never happens again by always setting this variable in your environment:

export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/mysql/lib/

All done!

With all this set in place, the installation of DBD::mysql is unlikely to give much more trouble, beyond failing the connectivity tests if you don’t have the MySQL server running as it expects you to be.

But that is a harmless issue.

If you’re not working from a perlbrew setup, that’s your first mistake. ↩
For this effect (and to make your life easier) installing Bundle::DBD::mysql from CPAN, is recommended. ↩
Yes, by trying to dig myself out of a hole, I dug one deeper and nearly buried myself in it. ↩

List of Freely Available Programming Books

Mon, 14 Nov 2011 16:28:00 +0000

List of Freely Available Programming Books:

Incredibly comprehensive list of readily available books related with programming.

I find lists like these to be a double-edged sword. They are very useful, but one can harm himself with too much information, by quickly losing focus and the realization that actually doing something is as important (if not more) than just endlessly reading about how it is done.

Still, this one is a keeper, and definitely worth a browse.

Codebits::API

Tue, 08 Nov 2011 16:00:00 +0000

Codebits, the massive hackathon extravaganza organized by Portuguese tech company SAPO, has its fifth edition happening in only a few days and I couldn’t be more excited about it. This will be my third consecutive year attending, and given that it has been improving by leaps and bounds with each edition, I have high expectations for this year.

API Preamble

Since the machine began churning inexorably towards the event’s November date, I made a point personally on being a lot more (pro-)active in my participation. Beyond taking part in the pre-event shenanigans (the geek quiz is one example that I am a huge fan of), I began planning an adequate participation in the 48h programming/hacking competition. I am a software developer after all, but the amount of code I’ve written in past Codebits editions has been pitiful.

While musing on ideas to tackle at the event proper, I took time to lay some groundwork that might prove useful eventually. In particular, I decided to map the event’s API onto my weapon of choice: Perl.

Although I am unsure of how many Perl mongers will attend (or even intend to hack on some Perl code during) the event, I purposefully left the implementation available publicly in the off-chance that it might be useful to someone. You can find it here:

[ smpb/codebits-api - GitHub ]

Networking

Undoubtedly, you will be able to find me there dabbling away at some of this, or similar, code. If you’re attending the event, and have any passing interest in Perl¹, don’t hesitate to drop by for a chat.

Or even if you don’t. It’s not really like there should be a prerequisite for some good conversation :-) ↩

$self++;

Fri, 04 Nov 2011 10:00:05 +0000

$self++;

An everyday love story set in the not so distant future sees...

Thu, 27 Oct 2011 11:05:05 +0100

An everyday love story set in the not so distant future sees blackbirds battling with technology, automatic palm readers and power cuts.

This must be Thursday. I never could get the hang of Thursdays.

Perl Weekly Newsletter

Mon, 24 Oct 2011 12:07:09 +0100

Perl Weekly Newsletter:

You are busy churning out code or managing the developers. You care about Perl but don’t have time to go through tens and hundreds of articles and blog posts every day. You want to keep an eye on the development of Perl without drowning in a sea of blog posts. You need someone to point out the most important news and articles in the Perl World. Let me be your guide.

One could make a snarky comment pointing out that there are likely nowhere near hundreds of articles being posted these days about Perl. But that would be missing the point.

If you care for Perl, this is a valuable resource.

Moose Delegation and References Currying

Sun, 23 Oct 2011 18:09:01 +0100

Storage abstraction in object-oriented programming is an interesting problem, approachable from several directions. While using Moose to build a set of self-storable objects, to tackle that particular issue, I came across a particular implementation detail that puzzled me for a while.

My approach involves Roles, insofar as the objects in question consume the ability to be “storable”, with the complexity of the database access hidden away under a minimalistic interface.

Within the Role, a private attribute holds the instance of the database object meant to deal with all the storage calls, and in order to minimize the number of open connections throughout the set, that object is implemented as a Singleton.

When in trouble, delegate

Since the database instance is the one supposed to be troubled with all the storage-related methods, it stands to reason that we should invoke said methods directly on it:

my $dude = Person->new(name => “Lebowski”);
$dude->db->get_money();

The problem with this is obvious: we are exposing the storage implementation details to the outside.

Fortunately, Moose allows for quick and easy setup of method delegation when defining attributes:

package My::Role::Storable;

use Moose::Role;
use My::Singleton::DB;

has '_db' => (
  is          => 'ro',
  isa         => 'My::Singleton::DB',
  handles     => [ qw( get_money get_rug abide ) ],
  lazy_build  => 1,
);

sub _build__db
{
  My::Singleton::DB->instance();
}

By explicitly defining that the instance “handles” the method, we have the desired mean of invocation:

$dude->get_money();

Perfect!

A contextual omission

But what I’ve described is fairly known and expected, since it’s explained clearly in Moose’s documentation. And despite the simplicity of the delegation syntax, there is a detail - also documented - that somewhat jinxes this idea.

In the context of the delegated method, the reference passed on invocation is the one of the database instance, and not of our storable object.

What this means is quite simple: if you invoke an “abide” method (because that’s what Dude’s do), it won’t work because the database instance has no implicit idea of which Dude you mean.

Passing the object at the time of the instantiation of the database is also not a option, since we are dealing with a Singleton, which internally - by its own nature - needs to remain as generic as possible.

Explicitly adding the object itself as an argument in each invocation would obviously work,

$dude->get_money($dude);

But I believe it’s plain to see why this is just wrong.

Curry in a hurry

Part of the answer lies - again - in Moose’s documentation, since we are able to create delegations with a pre-set of parameters. Thus, every time the method is called, those values are passed along first no matter what other arguments are specified.

has '_db' => (
  is          => 'ro',
  isa         => 'My::Singleton::DB',
  handles     => {
    get_money => [ get_money => 'one million dollars' ],
  },
  lazy_build  => 1,
);

This is, by definition, what is called “currying”.

The crux of the matter

This seems to resolve the issue. All is needed is to curry along a reference to the object holding the database instance so that when the method is called, and forwarded, the instance knows where the request actually came from.

Unfortunately, it does not work.

Moose’s syntax for handling delegation, and currying in particular, can only deal with static arguments. It’s only meant for the simple case.

If the item to be curried along varies at runtime, we need to define our own custom sub-routine outside of the normal attribute declaration. In this case, something like this:

sub get_money { my $self; return $self->db->get_money($self, @_); }
sub get_rug { my $self; return $self->db->get_rug($self, @_); }
sub abide { my $self; return $self->db->abide($self, @_); }

This works just fine.

Some clean-up

But if you’re getting some cold chills from just looking at all that repetition, you’re not alone. It’s ugly, lazy, and promises to be annoying to maintain.

Albeit, not as short, this is much better:

sub BUILD
{
  my $self = shift;
  my $meta = $self->meta;

  for my $method(qw( get_money get_rug abide ))
  {
    $meta->add_method($method,
      sub {
        my $self = shift; return $self->db->$method($self, @_);
      }
    );
  }
}

With this we are assured that, at the moment after the object is constructed, the expected methods are added in the proper way. If the needs arises, the list of methods itself can be abstracted away into a variable, where it can be more easily altered in the future.

Closing Thoughts

It took me a while to realize that the solution above was the correct one since I chose to believe that I was missing something from the Moose documentation¹. I fully expected the delegation mechanism to support these slightly more elaborate needs, but I was wrong.

In the end, it’s not as compact and cohesive has I’d hoped in the first place, but it’s what I got.

So, yeah, well: the Dude abides.

And my thanks to Pedro Melo, and the fine folk at #moose on irc.perl.org for helping me out. ↩