Yanick's Journal

Breaking off from the use.perl.org mothership

Yanick — 2009-05-10T23:40:55+00:00

For the last couple of months, as a concession between visibility and control, I'd been double-posting my blog entries both here and on my personal blog. But now that my blog is registered on both the Perlsphere and IronMan aggregators, the need for the second posts here has dwindled. So... I'm going on a limb and tentatively turn off the echoing. See y'all on Hacking Thy Fearful Symmetry!

Ruhr.pm: Die Meister des Psycho-Lamas

Yanick — 2009-04-22T00:31:18+00:00

reposted from Hacking Thy Fearful Symmetry

Last month, thanks to a concerted effort of German Perl Mongers[1] I was able to meet with the wonderful folks of Ruhr.pm.

It turns out that not only the Ruhr-area mongers are a superlatively friendly bunch, but they have pretty cool presentations too.

The feature presentation of the night was Fuse mit Perl, by Simon Wilper. After he was done, I also got treated with a quick replay of two previous presentations dealing with image manipulation. One was about openCV, a facial recognition software, and its Perl interface, and the other one was about the uses of Image::Magick, including the detailed instructions on how to create a psycho-llama. That last bit, I daresay, was worth the trip to Germany all by itself. The script to create the thing is in the presentation companion tarball, check it out (well, unless you suffer from epilepsy, in which case you want to stay as far away as possible).

So, bottom-line: Ruhr.pm rocks big time. If you're ever passing in the vicinity, I highly recommend paying them a visit. :-)

[1] Renée Bäcker saw my use.perl.org blog entry and forwarded the information to Ruhr.pm, Veit Wahlich -- fearless leader of the Ruhrgebiet mongers -- contacted me and arranged the details, and René Knopp was dispatched to pick me up from the train station. Many thanks to the whole bunch!

Just another Perl Ausländer

Yanick — 2009-03-04T18:28:37+00:00

(cross-posted from Hacking Thy Fearful Symmetry)

Ever since I've learned about the existence of $foo - Perl Magazin, I've been awfully curious to take a peek at it. Unfortunately, they don't ship subscriptions internationally. So I went for the obvious workaround: I hunted high and low for the loveliest German lass I could find, asked her to marry me, and coaxed her family to get and forward me a subscription for the magazine as this year's Christmas gift. Worked like a charm.

And it was worth it too. The magazine is even better than I expected, and it's high praises to the authors that I learned quite a few things from the articles even though my German is still at a protozoic stage. Whether you're a German wanting to learn Perl, or a Perl hacker wanting to learn German, I heartily recommend it.

And talking of Germany, I'll embark tomorrow on a three-week vacation trip across the republic. If there are any Perl mongers meeting this month around Duisburg, Morsbach or Schwieberdigen who wouldn't mind having an Ausländer in their midst, please feel free to drop me an email. :-)

Variation on the Faces of CPAN

Yanick — 2008-12-30T18:26:27+00:00

Faces of CPAN + GD::Image + blissfully idle holiday morning = this.

CPAN Patching with Git

Yanick — 2008-12-29T18:32:52+00:00

A few months ago, brian posted a blog entry about patching modules using Git. In the ensuing discussion, I pointed at a possible way to automatise the process a step further by punting the generated patch to rt.cpan.org. The hack was well-received and, with (very) minimal coaxing, I was subsequently convinced to expand on the idea for the Perl Review.

The resulting piece is now available in TPR 5.1. In the article, the initial command-line hack has morphed into four scripts -- git-cpan-init, git-cpan-clone, git-cpan-update and git-cpan-sendpatch -- that pretty much take care of all the administrative overhead of module patching. In most cases, grabbing a distro, fixing a bug and sending the patch can be done in four lines:

$ git cpan-init Some::Module $ git checkout -b mypatch ...hack hack hack... $ git rebase -i cpan $ git cpan-sendpatch

And, no, the lack of hyphen between git and cpan-X isn't a typo; the article also covers how to seamlessly integrate the new scripts into the git infrastructure (as Edna Mode would say, it's a non-feature, dahling).

Of course, I'm burning to say more, but I'll have to stop here. To know the whole story, you'll have to wait for The Perl Review to land in your mailbox (you are subscribed to TPR, right?).

cross-posted from Hacking Thy Fearful Symmetry.

introducing Dist::Release

Yanick — 2008-11-11T04:01:41+00:00

(cross-posted from Hacking Thy Fearful Symmetry )

I know, I know, there's already more module release managers out there than there are Elvis impersonators in Vegas. Still, module releasing seems to be a very personal kind of itch, and like so many before I couldn't resist and came up with my very own scratching stick.

Of course, I've tried Module::Release. But, although it is intended to be customized to suit each author's specific needs, one has to dig fairly deep in the module's guts to do so. What I really wanted was something even more plug'n'play, something that would be brain-dead easy to plop new components in. Hence Dist::Release.

In Dist::Release, the release process is seen as a sequence of steps. There are two different kind of steps: checks and actions. Checks are non-intrusive verifications (i.e., they're not supposed to touch anything), and actions are the steps that do the active part of the release. When one launches a release, checks are done first. If some fail, we abort the process. If they all pass, then we are good to go and the actions are done as well.

Implementing a check

To create a check, all that is needed is one module with a 'check' method. For example, here is the code to verify that the distribution's MANIFEST is up-to-date:

package Dist::Release::Check::Manifest::Build; use Moose; use IPC::Cmd 'run'; extends 'Dist::Release::Step'; sub check { my $self = shift; $self->diag( q{running 'Build distcheck'} ) my ( $success, $error_code, $full_buf, $stdout_buf, $stderr_buf ) = run( command => [qw# ./Build distcheck #] ); return $self->error( join '', @$full_buf ) if not $success or grep /not in sync/ => @$stderr_buf; } 1;

Dist::Release considers the check to have failed if there is any call made to error(). If there is no complain, then it assumes that everything is peachy.

Implementing an action

Actions are only marginally more complicated than checks. The module implementing the action can have an optional check() method, which is going to be run with all the other checks, and must have a release(), which make the release-related changes.

For example, here's the CPANUpload action:

package Dist::Release::Action::CPANUpload; use Moose; use CPAN::Uploader; extends 'Dist::Release::Action'; sub check { my ($self) = @_; # do we have a pause id? unless ($self->distrel->config->{pause}{id} and $self->distrel->config->{pause}{password} ) { $self->error('pause id or password missing from config file'); } } sub release { my $self = shift; $self->diag('verifying that the tarball is present'); my @archives = <*.tar.gz> or return $self->error('no tarball found'); if ( @archives > 1 ) { return $self->error( 'more than one tarball file found: ' . join ',', @archives ); } my $tarball = $archives[0]; $self->diag("found tarball: $tarball"); $self->diag("uploading tarball '$tarball' to CPAN"); my ( $id, $password ) = map { $self->distrel->config->{pause}{$_} } qw/ id password /; $self->diag("using user '$id'"); my $args = { user => $id, password => $password }; unless ( $self->distrel->pretend ) { CPAN::Uploader->upload_file( $tarball, $args ); } } 1;

As for the check(), Dist::Release figures out that a release() failed if there's a call to error().

Configuring for a module

Configuration is done via a 'distrelease.yml' file dropped in the root directory of the project. The file looks like this:

pause: id: yanick password: hush checks: - VCS::WorkingDirClean - Manifest actions: - GenerateDistribution - CPANUpload - Github

It's pretty self-explanatory. The checks and actions are applied in the order they are given in the file.

Crying havoc...

And once the configuration file is present, all that remains to be done is to run distrelease, sit back and enjoy the show:

$ distrelease Dist::Release will only pretend to perform the actions (use --doit for the real deal) running check cycle... regular checks VCS::WorkingDirClean [failed] working directory is not clean # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: Build.PL # modified: Changes # modified: README # modified: distrelease.yml # modified: lib/Dist/Release/Check/Manifest.pm # modified: script/distrelease # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # STDOUT # a # blog # xml # xt/dependencies.t # xxx no changes added to commit (use "git add" and/or "git commit -a") Manifest [failed] No such file: lib/Dist/Release/Action/DoSomething.pm Not in MANIFEST: a Not in MANIFEST: blog Not in MANIFEST: lib/Dist/Release/Action/Github.pm Not in MANIFEST: STDOUT Not in MANIFEST: xml Not in MANIFEST: xt/dependencies.t Not in MANIFEST: xxx MANIFEST appears to be out of sync with the distribution pre-action checks GenerateDistribution [passed] no check implemented CPANUpload [passed] Github [passed] 2 checks failed some checks failed, aborting the release

Getting the good

A first release of Dist::Release is already waiting for you on CPAN. It's beta, has no documentation, is probably buggy as hell, but it's there. And the code is also available on Github. Comments, suggestions, forks and patches are welcome, as always. :-)

Me at OsBootCamp 8

Yanick — 2008-09-06T15:06:01+00:00

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. :-)

Pasting repository info on CPAN page

Yanick — 2008-08-13T01:58:05+00:00

Out of the comments generated by a post by grink, I've learned that the location of the distribution's repository can be inserted in the META.yml. Neato!

And when grink asked if someone could come up with a Greasemonkey script to extract that information and show it on the distro's page... well, that's no simian fun I could let pass untackled. The resulting greasemonkey script can be found here.

Mohlohpoly game

Yanick — 2008-08-05T00:55:58+00:00

While working on WWW::Ohloh::API, I caught myself wondering how one could use Ohloh for some kind of game. A few bus trips later with no book to keep my mind out of trouble, I came up with the variant of Monopoly given below. I'm recording it here to get it out of my system. Maybe one day, when I'll have time (ah!), I'll implement it. It'd be worth it just for the fun of collecting famous hackers like Pokémons. :-)

Rules

Every player start with a given amount of "money" (or moohlah).
Developers can be bought for a price inversely proportional to their Ohloh rank. A developer can only be owned by a single player at any given time.
A player can sell one of his developers at market price at any time. The player can also sell a developer directly to another player for any agreed price between them. Or he can auction the developer in an open auction to the rest of the players.
Any time a developer receives a kudo, the player owning him or her gets a dividend proportional to the rank of the kudo giver.
If a player possesses all developers of a project, they "own" that project.
Each turn, each player gets to "use" a random project picked from the set of all projects owned by a player, and must pay a fee proportional to the review score and number of users of that project. If the player doesn't have enough moohlah to pay up, one his or her developer is picked at random and sold at market value until the player becomes solvent again. If the player ends up without moohlah or hackers, he or she goes under.

Object::InsideOut Cheatsheet

Yanick — 2008-07-20T01:31:14+00:00

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.)

Bart on Git

Yanick — 2008-07-16T02:13:07+00:00

Bart Trojanowki gave a Git presentation to the Ottawa Ruby Group earlier this month (I attended as a deep undercover Perl mole). The slides and the podcast are now available at http://excess.org/article/2008/07/ogre-git-tutorial.

Very good presentation, meant as an introduction to the beast, but containing enough little nudgets to have anyone learn something from it.

Bring the blog back hooome

Yanick — 2008-07-11T03:31:53+00:00

Just to say that my main blog is going to be here (although I'm probably going to echo my posts at use.perl.org for a while still).

I love the soapbox that use.perl.org provides but the site's blogging interface is, shall we say, a tad archaic and on the painful side. I can live with the html format of entries, but many times I've longed for something a little bit more code snippet-friendly. So, when Perlsphere appeared at the horizon, the temptation to repatriate my blog on my own server became just too great to ignore...

Of course, considering that it's a blog about Perl blabbering, using some PHP blog engine would have not felt quite right. So I decided to experiment with Angerwhale. It's a pretty nifty engine, but it has a few rough edges. In fact, I already began to hack and patch at it... expect some entries about it sometimes soon. :-)

Test::Class + Test::Group

Yanick — 2008-06-20T01:50:04+00:00

I've been playing with Test::Class lately and, I must say, it's a heck of a nice module. Only thing that I wish it had is the possibility to report each test as a single pass/failure, no matter the number of assertions done in the function. Just like Test::Group does.

Hmmm... But wait a second. Could it be possible to somehow stuff the caramel-like sweetness of Test::Group in the smooth chocolatey wrapping of Test::Class? Turns out that yes, it's perfectly possible! And even more, without even having to muck with the guts of either modules:

package Some::TestSuite; use base qw/ Test::Class /; use Test::Group; use Test::More; sub Test :ATTR(CODE,RAWDATA) { my ( $pkg, $funct, $code ) = @_; no warnings; # black magic starts here my $func_name = *{$funct}{NAME}; my $fullname = $pkg.'::'.$func_name; *{$funct} = sub { print "begin test [", scalar localtime, "]\n"; Test::Group::test( $fullname => \&{$code} ); print "end test [", scalar localtime, "]\n"; }; Test::Class::Test( @_ ); } sub aTest : Test { ok 1, 'eins'; ok 1, 'zwei'; ok 1, 'drei'; } sub otherTest : Test { ok 1, 'un'; ok 0, 'deux'; ok 1, 'trois'; } Some::TestSuite->runtests;

Which gives

$ perl test.t 1..2 begin test [Thu Jun 19 22:17:16 2008] ok 1 - Some::TestSuite::aTest end test [Thu Jun 19 22:17:16 2008] begin test [Thu Jun 19 22:17:16 2008] # Failed test 'deux' # in a.t at line 32. not ok 2 - Some::TestSuite::otherTest # Failed test 'Some::TestSuite::otherTest' # at a.t line 17. # (in Some::TestSuite->otherTest) end test [Thu Jun 19 22:17:16 2008] # Looks like you failed 1 test of 2.

This method, though, has two modest caveats:

A failed assertion will be given with the correct line, but the test itself will be reported as being located inside the Test() function.
Test fixtures have to be declared as having 1 test (i.e., it has to be sub mySetup :Test(setup => 1) { .. })

Why I am passionate about Perl

Yanick — 2008-05-11T16:03:22+00:00

The person who introduced me to Perl showed me that ... well, in my case it's kinda of a spurious question, considering that no-one really properly introduced me to the language. At the time, I just happened to look around for a good scripting language to learn and saw that Perl was one of the languages used by some members of my team. I bought the Camel book, dived in and... the rest is pretty much history.

I first starting using Perl to do small shell stuff. If I recall correctly, the first script I touched was a load balancer that was monitoring a unix corral and launching queued jobs on the less busy machines. Then I began to use it to diddle text files (change 'class Foo' to 'class Bar' in my source code, figure out how many functions are in each file, etc.). And then came the Solitaire 500. My entry to the contest shamefully crashed and burn at the starting line, but I still managed to squeeze a t-shirt and a love of the language out of the experience. To this day, I still have both (although one is pretty much due for replacement).

I kept using Perl because it is so much damn fun. Most other languages are like station wagon cars. They get you from A to B, but they are not much to write home about. But Perl... Perl is like James Bond's car. Beside the driving wheel, you have a red button here to activate the flamethrowers. Below the glove compartment -- yes, you see right -- there's a lever that engages the retro-propellers. And it doesn't end there: if one was to ever get bored with all those nifty toys, Q still comes up regularly with new features.

I can't stop thinking about Perl for the same reason a rock star can't stop thinking about his Fender Stratocaster XII.

I'm still using Perl because I have yet to find another language that is so delightfully idiosyncratic and yet so practical. Or that has such a striving community. Or that has anything remotely comparable to that magnificent temple dedicated to Aergia that we call CPAN.

I get other people to use Perl by asking them what task they want to achieve, and doing it before their eyes in a handful of lines. Once I have thus acquired their awestruck attention, I reel them in for my weekly Perl Lunch'n'Learns where the true corruption can begin.

I also program in TCL and Javascript, but I like Perl better since it doesn't make me want to drive red-hot tetanus-laden nails through my prosencephalon. Javascript is not that bad, mind you -- I actually like it. But nothing, nothing, can shear such deep gouges in one's psyche like badly written TCL can. And this is coming from someone who known Intercal, brainf*ck and VisualBasic...

CPAN/Ohloh mashup

Yanick — 2008-04-23T23:50:53+00:00

Now that I've registered my Perl modules on Ohloh, I thought it'd be fun to make things bilateral and have one of the Ohloh widgets displayed on the modules' CPAN page. So I mustered my Grease-Fu, and hacked a little something.

With that little script installed, if a module dist is registered on Ohloh [*], its widget will appear on the right side of the CPAN page right below the gravatar picture.

For sample modules, have a gander at Test::Pod::Snippet or XML::XPathScript.

[*] The project must also be configured to have a name url corresponding to module's name in lowercase and with all '::' substitued by '-' (e.g., 'Test::Pod::Snippets' => 'test-pod-snippets').

per(l)version

Yanick — 2008-03-20T02:13:22+00:00

Updating the version number is all the files of a module distribution is a pain in the behind. It's repetitive, boring and ridiculously prone to errors -- in short, a task fit for a script, not for humans. So I decided to hack myself a little something, for the time being called perversion, to take care of it.

The idea is pretty straight-forward. In the root directory of my distribution, I have a config file named perversionrc that contains Perl code that return an hash of all files where the the module version is given, and regular expressions to capture the said version. For example, here's the perversionrc of WWW::Ohloh::API:

use File::Find::Rule; my %file; $file{README} = qr/WWW-Ohloh-API version (\S+)/; for my $m ( File::Find::Rule->file->name( '*.pm' )->in( 'lib' ) ) { $file{$m} = [ qr/\$VERSION\s*=\s*'(.*?)';/, qr/This document describes \S+ version (\S*)/ ]; } %file;

Once that file is present, perversion is ready to rock. You want to verify that the version number is consistent in all given files?

$ perversion distribution version is set to 0.0.9 lib/WWW/Ohloh/API/Enlistment.pm:12: 0.0.6 !!! does not match distribution version (0.0.9) !!! lib/WWW/Ohloh/API/Repository.pm:10: 0.0.6 !!! does not match distribution version (0.0.9) !!! lib/WWW/Ohloh/API/ContributorLanguageFact.pm:10: 0.0.6 !!! does not match distribution version (0.0.9) !!! lib/WWW/Ohloh/API/ContributorFact.pm:10: 0.0.6 !!! does not match distribution version (0.0.9) !!! lib/WWW/Ohloh/API/ContributorFact.pm:241: 0.0.6 !!! does not match distribution version (0.0.9) !!!

Want to set the version to a specific value?

$ perversion -set 1.2.3 changing all versions to 1.2.3.. updating lib/WWW/Ohloh/API.pm.. updating lib/WWW/Ohloh/API/Language.pm.. updating lib/WWW/Ohloh/API/ActivityFacts.pm.. updating lib/WWW/Ohloh/API/Account.pm.. updating lib/WWW/Ohloh/API/Kudos.pm.. updating lib/WWW/Ohloh/API/Project.pm.. updating lib/WWW/Ohloh/API/Enlistment.pm.. updating lib/WWW/Ohloh/API/KudoScore.pm.. updating lib/WWW/Ohloh/API/Factoid.pm.. updating lib/WWW/Ohloh/API/Repository.pm.. updating lib/WWW/Ohloh/API/Projects.pm.. updating lib/WWW/Ohloh/API/ContributorLanguageFact.pm.. updating lib/WWW/Ohloh/API/Languages.pm.. updating lib/WWW/Ohloh/API/ActivityFact.pm.. updating lib/WWW/Ohloh/API/ContributorFact.pm.. updating lib/WWW/Ohloh/API/Analysis.pm.. updating lib/WWW/Ohloh/API/Kudo.pm.. updating README.. done

Don't want to go through the mental challenge of computing the next version yourself? No problem!

$ perversion -inc revision distribution version is set to 1.2.3 new distribution version is 1.2.4 $ perversion -inc minor distribution version is set to 1.2.4 new distribution version is 1.3.0 $ perversion -inc major distribution version is set to 1.3.0 new distribution version is 2.0.0 $ perversion -inc alpha distribution version is set to 2.0.0 new distribution version is 2.0_1

The script is still raw and in need of polishing, but for those interested, it's available from its very own git repository.

XPathScript slides

Yanick — 2008-03-02T03:43:29+00:00

An introduction to XPathScript that I gave at this month's Ottawa Mongers Meeting can be found here.

It probably reads a wee bit cryptic without my running commentaries, but some might still enjoy it. :-)

Thinking about taking over NetPacket

Yanick — 2008-02-12T17:24:22+00:00

At $work, an application that I wrote (remora, a companion application to Wireshark) is extensively using NetPacket. NetPacket is very handy but, alas, has some bugs, and seem to be orphaned (the latest update is from 2003). I've tried to poke the maintainers, but Stephanie Wehner's email is no longer working, and Tim Potter didn't reply yet (although, to be fair, I only began to poke last week).

Bottom line, I'm playing with the idea of taking over the module so that I can churn a new version with the bug fixes. So if anyone out there is in contact with Stephanie or Tim, can you let them know a madman is nefariously organizing a coup? Thanks. :-)

Git's the nightclub, Perltidy's the bouncer

Yanick — 2008-02-09T22:18:41+00:00

I finally wrapped my CVS-encrusted mind around Git's hooks. Huzzah! The biggest hurdle, really, was realizing that there is no spoon.

Anyway, as I'm an unsalvageable slob who always forget to run perltidy before committing changes, I've written a pre-commit hook that makes sure that all Perl files to be committed are all clean, neat and tidy (and aborts the commit and chides me if they are not):

#!/usr/bin/perl use Perl6::Slurp; my $status = slurp '-|', 'git-status'; # only want what is going to be commited $status =~ s/Changed but not updated.*$//s; my @dirty = grep { !file_is_tidy($_) } # not tidy grep { /\.(pl|pod|pm|t)$/ } # perl file map { /(?:modified|new file):\s+(\S+)/ } # to be commited split "\n", $status; exit 0 unless @dirty; # Alles gut warn "following files are not tidy, aborting commit\n", map "\t$_\n" => @dirty; exit 1; ### utility functions ############################################### sub file_is_tidy { my $file = shift; my $original = slurp $file; my $tidied = slurp '-|', 'perltidy', $file, '-st'; return $original eq $tidied; }

Greasemonkeying dependencies

Yanick — 2008-01-29T01:28:11+00:00

Escalation wars... you just have to love'em.

First, David came up with the über-cool CPAN deps page.

Then Andy comes up with a nifty Greasemonkey script to add it to the CPAN distributions main pages.

Then I add a small patch to the script to retrieve some information from the Deps page.

Then David creates an xml interface to CPAN deps, opening the door wide open for Web 2.0 goodiness.

Then (and this is where we are right now) I hack together a new CPAN_Dependencies monkeyscript to take advantage of said xml interface.

This, of course, is nowhere near the end of the story. My new script only scratches the surface of what can be done with the information contained in the xml. As soon as I have some tuits, I'll probably add a way to toggle between showing only the first-level dependencies and all dependencies, and have dependencies color-coded by degree of b0rkage, and whatever bell or whistle I can think of in the meantime.

Redux

Yanick — 2007-11-29T01:23:10+00:00

Lately, I've been having fun with GreaseMonkey. Net result: I've re-implemented my Perl-themed friends/foes icons (originally done using Stylish) and hacked RT to provide sorting of bugs by severity (I got the idea for that one from Schwern's journal). Both monkey scripts are available on userscript.org.

Also, a new version of Pod::Manual is out. The code to generate my unexpectedly wildly popular ad-hoc Catalyst manual was already included in the previous distributions, and in this one I added a similar manual for Rose::DB::Object. The order in which the modules are given is a little rough and need improvement, but it's a start. For those who care more about the end than the means, the pdf of both manuals are available here

No-one expected the Technorati inquisition

Yanick — 2007-08-01T12:21:59+00:00

Slightly amusing trivia: before the hoola-baloo of the last few days, I was persuaded that it was the technocrati, and that it was secret organization of nefarious hackers -- an amalgam of the Illuminati and WhiteWolf's Technocracy.

Anyway, here goes: Technorati Profile.

Trying to define badness: Shakesphackers

Yanick — 2007-07-22T16:10:29+00:00

Shakesphacker: (n.) a programer who, at the instar of Shakespeare's infamous chimps, randomly bang on the keyboard until the laws of probability make him generate a working line of code.

I came up with that term Friday to try to put a label on a coding philosophy I observed. I'm not entierely satisfied by it though -- it sounds way too sophisticated for the kind of feeling it try to convey. "Foo flinger" could be more adequate.

In all cases, shakesphackers can be easily identified by their exuberant love of evals -- they firmly believe that, just like violence, if it doesn't solve your problems, it's because your not using enough of it.

Pod::Manual

Yanick — 2007-07-15T01:27:00+00:00

A while ago, I hacked together a way to gather many pod files into a single pdf file. Well, finally I got around cleaning up the code and released it as Pod::Manual.

It's still very muchly alpha quality, but the basics seem to work. For example, the following works (at least on my machine)[*]:

use Pod::Manual; my $manual = Pod::Manual->new({ title => 'Catalyst' }); $manual->add_chapter( $_ ) for qw/ Catalyst::Manual::About Catalyst::Manual::Actions Catalyst::Manual::Cookbook Catalyst::Manual::DevelopmentProcess Catalyst::Manual::Internals Catalyst::Manual::Intro Catalyst::Manual::Plugins Catalyst::Manual::Tutorial Catalyst::Manual::Tutorial::Intro Catalyst::Manual::Tutorial::CatalystBasics Catalyst::Manual::Tutorial::BasicCRUD Catalyst::Manual::Tutorial::Authentication Catalyst::Manual::Tutorial::Authorization Catalyst::Manual::Tutorial::Debugging Catalyst::Manual::Tutorial::Testing Catalyst::Manual::Tutorial::AdvancedCRUD Catalyst::Manual::Tutorial::Appendices Catalyst::Manual::WritingPlugins /; $manual->save_as_pdf( 'catalyst_manual.pdf' );

At this stage of the game, bug reports and feature requests would be very welcome. As well as suggestions for other example manuals.

[*] caveat: for the moment you need TeTeX installed to generate pdf documents. One of the items on my todo list is to allow for other means to generate the pdf (jadetex, FOP, etc)

push @ISA, 'Married::Man'

Yanick — 2007-06-27T21:04:00+00:00

On Saturday, June the 23rd, me and my lovely lady joined APIs before friends, families and the Great Whitely-Bearded Hacker in the Sky (He was even kind enough to schedule some wicked light effects for the event).

Funnily enough, both the bride and the groom were wearing pearls for the occasion (in my case, it was an heirloom tie-pin given by the mother-in-law). As unforgivingly geeky as it is, I must say I got a secret kick out of that.

Catalyst's manual

Yanick — 2007-04-19T02:41:58+00:00

Don't get me wrong, I love perldoc. But for documentation that span several manpages, I often catch myself dreaming of tables of content, indexes, real dead-tree margins on which to annotate stuff. I'm funny that way.

So I went back to the script that I wrote to create the XPathScript manual and tinkered a bit with it. I then used that newly-concocted black magick (which basically convert and agglomerate pods into a docbook, which is then LaTeXified and subsequently pdfed) to turn the Catalyst manual into a cute little pdf. Me likes. I think I'll tidy up the aforementioned script and publish it as Pod::Manual or something of the kin as soon as time (ah!) allows.

(and yeah, I'm in the process of getting my feet wet with Catalyst. Last week I was hopelessly Not Getting It, but sometime during last week-end, an angel came to me and bapped me over the head with its trumpet. Epiphany! I grok it, now! Even better: I think I'm digging it too!)

Meeting Availability Dialect

Yanick — 2007-03-10T18:00:13+00:00

Background

Organizing the March meeting of Ottawa.pm, I came across the problem that setting a date is pretty much like playing Battleship. If a specific date is proposed, people tend respond with boolean answers (can/can't come on that day), which is perfect to assess the punctual value of the attendency function, but quite lousy to determine its monthly optimum.

So, taking the premise that there's no simple problem that can't be solved by an overcomplex solution, I thought about a way we could all signal our availabilities for a certain month in a simple, standard and easy to parse way (for I have evil plans to hack a script to help me do the scheduling). A few bus commutes later, MADness was born.

Meeting Availability Dialect

A MAD signature line has the following syntax:

month : availability

The month is simply the name of the month. Availability is defined by a sequence of tokens that add or remove available days, depending if they are modified by a plus or minus sign.

E.g.:

April : WD + Sat - Wed - Day(13)

which means any work day, plus Satudays, but not Wednesdays or the 13th of the month.

The base token are:

Mon
Tue
Wed
Thu
Fri
Sat
Sun
AD - Any day
WE - Week-end (same as 'Sat + Sun')
WD - Week days (same as 'Mon + Tue + Wed + Thu + Fri')

For a specific date, use Day(X), where X is the date. For example, 'WD - Day(14)' means all week days, except on the 14th (one can surmise that was for February).

To target a specific week, append '(X)' to the token, where X is the week in question. Several weeks can be given, separated by commas or a range operator '..'. For example, 'Tue - Tue(2)' is equivalent to 'Tue(1,3..4)' and means the first, third or fourth Tuesday of the month.

Availability is resolved from left to right, which means that, for example,

April : AD - WE + Sun(1)

means any day, except week-ends, although the first Sunday is okay. Note that
this is equivalent to

April: WD + Sun(1)

MAD doesn't consider whitespaces as significant. The full availability, however, must be represented on a single line.

$tea="Earl Grey";print $tea

Yanick — 2007-02-16T03:09:06+00:00

Don't go and gnaw off your fingers just yet. Judging from this demonstration of the bleeding edge of speech recognition technology, we will need our ten stubby friends to bang on keyboards for a little while still....

XML::XPathScript 1.47 is out

Yanick — 2007-01-20T23:46:12+00:00

It is with great relish that I announce that XML::XPathScript v1.47 is on its way to a CPAN mirror near you.

[ ED: Do'h! The test that was supposed to gracefully skip if B::XPath isn't installed bombs instead. (blame it on my naive assumption that 'eval { use B::XPath; 1 }' would work). I'll do a s/use/require/ on that test and release 1.48 tonight. ]

What is new in this release:

* template tag attributes can now be functions as well as strings.

For example,

$template->set( 'foo' => { testcode => sub {
my( $n, $t ) = @_;
my $name = $n->findvalue( 'name()' );
$t->set({ pre => transfurbicate( $name ) });
return $DO_SELF_AND_CHILDREN;
}
} );

can now be written

$template->set( 'foo' => { pre => sub {
my( $n, $t ) = @_;
my $name = $n->findvalue( 'name()' );
return transfurbicate( $name );
}
} );

* The 'content' template attribute, which associates template elements to
mini-stylesheets.

E.g., the code

<%
$template->set( 'foo' => {
pre => '<newFoo foo_myattr="{@myattr}" >',
post => '</newFoo>',
action => 'bar', # only process 'bar' node children
} );
%>

can now be written

<%
$template->set( 'foo' => { content => <<'END_CONTENT' } );
<newFoo foo_myattr="{@myattr}" > <%# look Ma, we interpolate! %>
<%~ bar %> <%# only process bar children %>
</newFoo>
END_CONTENT
%>
<%# process all foo's %>
<%~ //foo %>

Or, to be more easy on the eye, we can use the short-hand version:

<%@ foo
<newFoo foo_myattr="{@myattr}" > <%# look Ma, we interpolate! %>
<%~ bar %> <%# only proces bar children %>
</newFoo>
%>
<%# process all foo's %>
<%~ //foo %>

* B::XPath now a supported DOM tree. Bored with transforming XML documents?
How about transforming Perl Optrees? :-)

use B::XPath;
use XML::XPathScript;

sub guinea_pig {
my $x = shift;
print "oink oink " x $x;
}

my $xps = XML::XPathScript->new;

$xps->set_dom( B::XPath->fetch_root( \&guinea_pig ) );
$xps->set_stylesheet( '<%~ //print %>' );

print $xps->transform;

Resurrecting Ottawa.pm

Yanick — 2007-01-12T03:26:20+00:00

One of my resolutions for the new year is to try and see if I can stir Ottawa.pm back to life (it kinda went under two year-ish ago). I've already sent a humble request to the Power that Is at pm.org to get the keys to the ottawa.pm.org website and mailing list. But still remains the most daunting task: gather minions. I already spotted 11 Perl programmers on meetup.com that would probably be interested. And I should also be visiting the local LUG, always a fertile ground for young llamas....

Anyway. No need to say, if you are in the vicinity and want to join the fray, please feel free to frantically wave in my direction. If not, well, wish me luck. :-)