Damien Krotkine

MooX::LvalueAttribute - Lvalue accessors in Moo

2013-02-11T00:00:00-08:00

MooX::LvalueAttribute - Lvalue accessors in Moo

Yesterday I was reading Joel’s post, where he lists great Perl things he’s seen done lately. Indeed these are great stuff. I was particulary interested by his try at playing with Lvalue accessors.

I thought that it would be a great exercise to try to implement it in Moo, as an additional feature, trying to get rid of the AUTOLOAD. Also, I was willing to avoid doing a tie every time an instance attribute accessor was called. Surely, I needed to tie only once per instance and per attribute, not each time the attribute is accessed.

So I started hacking on the code of Moo. Getting rid of the AUTOLOAD was easy, as I could change the way the accessor generator was, well, generating the, err, accessors.

Shortly after I started having issues to cache a tied variable. I asked the all-mighty Vincent Pit, and he found a solution for my tied variables, but more importanlty pointed me to Variable::Magic, which is faster, more flexible and powerful.

All I needed was to move my hacks in a proper Role, and wrap the whole in a module, and push it on CPAN. Tadaa, MooX::LvalueAttribute was born.

In the process I used play-perl to register my quests, and exchanged thoughts with Joel Berger. I think I’m going to use this website more, see if it can boost my productivity, and help me figure out what’s really important to do.

On IRC, haarg discovered a bug and recommended to use so-called fieldhashes, from Hash::Util::FieldHash::Compat. At the end of the day, I only acted as a glue between different pieces of knowledges, and that was very satisfactory.

TL:DR

MooX::LvalueAttribute is a module that provides Lvalue attributes:

package App;
use Moo;
use MooX::LvalueAttribute;

has name => (
  is => 'rw',
  lvalue => 1,
);

# Elsewhere
my $app = App->new(name => 'foo');

$app->name = 'Bar';

print $app->name;  # Bar

Enjoy!

New Perl module: Action::Retry

2013-01-21T00:00:00-08:00

New Perl module: Action::Retry

UPDATE: I have included a functional API, as per Oleg Komarov request, and amended this post accordingly.

I’ve just released a new module called Action::Retry.

Use it when you want to run some code until it succeeds, waiting between two retries.

A simple way to use it is :

use Action::Retry qw(retry);
retry { ... };

And the Object Oriented API:

Action::Retry->new( attempt_code => sub { ... } )->run();

The purpose of this module is similar to Retry, Sub::Retry, Attempt and AnyEvent::Retry. However, it’s highly configurable, more flexible and has more features.

You can specify the code to try, but also a callback that will be executed to check the success or failure of the attempt. There is also a callback to execute code on failure.

The module also supports different sleep strategies ( Constant, Linear, Fibonacci…) and it’s easy to build yours. Strategies can have their options as well.

my $action = Action::Retry->new(
  attempt_code => sub { ... },
  retry_if_code => sub { $_[0] =~ /Connection lost/ || $_[1] > 20 },
  strategy => { Fibonacci => { multiplicator => 2000,
                               initial_term_index => 3,
                               max_retries_number => 5,
                             }
              },
  on_failure_code => sub { say "Given up retrying" },
);
$action->run();

And the functional API:

  use Action::Retry qw(retry);
  retry { ... }
  retry_if_code => sub { $_[0] =~ /Connection lost/ || $_[1] > 20 },
  strategy => { Fibonacci => { multiplicator => 2000,
                               initial_term_index => 3,
                               max_retries_number => 5,
                             }
              },
  on_failure_code => sub { say "Given up retrying" };

Strategies can decide if it’s worthwhile continuing trying, or if it should fail.

Action::Retry also supports a pseudo “non-blocking” mode, in which it doesn’t actually sleep, but instead returns immediately, and won’t perform the action code until required time has elapsed. Basicaly it allows to do this:

my $action = Action::Retry->new(
  attempt_code => sub { ... },
  non_blocking => 1,
  strategy => { 'Constant' }
);
while (1) {
  # if the action failed, it doesn't sleep
  # next time it's called, it won't do anything until it's time to retry
  $action->run();

  do_something_else();
  # do something else while time goes on

}

of course do_something_else should be very fast, so that the loop goes back quickly to retrying the attempt_code.

Action::Retry is based on Moo for performance (and because the module is simple enough to not require Moose). Moo classes properly expand to Moose ones if needed, so there is no excuse not to use it.

So, please give a try to Action::Retry, and let me know what you think.

Mass-Testing Dancer's Plugins

2012-09-20T00:00:00-07:00

Mass-Testing Dancer’s Plugins

So, as I said at YAPC::EU 2012, one thing that remains to be done before Dancer 2 can be released : migrating the plugins, making sure they work with it.

To be able to do that, what’s best than an automatic testing facility ?

The goal is to get all Dancer plugins, test them with Dancer1, and Dancer2, and produce a report, to check which one fails and need fixing.

Step 1. Get the list of Dancer plugins.

Easy ! let’s use Metacpan. After searching, I finally got a way to get the list of all modules that depend on Dancer. Then filtering out the ones that don’t contain "Plugin" will do the trick.

#!/usr/bin/env perl

use Modern::Perl;
use ElasticSearch;

my $es = ElasticSearch->new( servers => 'api.metacpan.org', no_refresh => 1 );

my $scroller = $es->scrolled_search(
    query       => { match_all => { } },
    search_type => 'scan',
    scroll      => '5m',
    index       => 'v0',
    type        => 'release',
    size        => 100,
    filter => {
            term => {
                     'release.dependency.module' => 'Dancer'
                    }
              },

);

my $result = $scroller->next;

my %plugins;
while ( my $result = $scroller->next ) {
    $result->{_source}->{name} =~ /Dancer-Plugin/
      or next;
    my $name = $result->{_source}->{name};
    $name =~ s/-\d.*//;
    $name =~ s/-/::/g;
    $plugins{$name} = 1;
}
say $_ foreach sort keys %plugins;

Cool, let’s save this script as get_modules_list.pl.

Step 2. Prepare two Perl environments

We want two instance of Perl, without polluting anything. We’ll use perlbrew for that. Easy. The small trick is to have PERLBREW_ROOT initialized to a local directory to not polute existing ~/perl5 installation.

Step 3. Have a way to test modules

Well, let’s use cpanm, which has an option --test-only to only test a module without installing it. Oh but plugin modules that we’ll test may require dependances. We’ll install them using cpanm --installdeps, which does just that.

Step 4. Create a result file

I was lazy and just output to a .csv text file, but I may store the results somewhere else later.

Step 5. Let’s glue all that in a Makefile

The beauty of this is that by writing a proper Makefile, we can install this auto-tester anywhere. The requirements are minimal : bash, curl, and perl, with ElasticSearch and Modern::Perl installed.

( This post is intentionally named the same as the one from Yannick, because he proposed a different implementation. We’ll try to merge the good ideas together )

HERE=${PWD}

# set up the local Perlbrew location
PERLBREW_DIR=${HERE}/perlbrew
PERLBREW=export PERLBREW_ROOT=${PERLBREW_DIR} \
    && source ${PERLBREW_DIR}/etc/bashrc \
    && PERLBREW_ROOT=${PERLBREW_DIR} ${PERLBREW_DIR}/bin/perlbrew

# This will run the cpanm from the local Perlbrew, on each of the 2 perls
CPANM_DANCER1=${PERLBREW} exec --with dancer1_plugin_tests ${PERLBREW_DIR}/bin/cpanm
CPANM_DANCER2=${PERLBREW} exec --with dancer2_plugin_tests ${PERLBREW_DIR}/bin/cpanm

# loop on the plugin list, install the deps and test each plugin and output result
all: got_curl got_bash got_perlbrew_perl plugins_list
	echo "Plugin name,Pass on Dancer 1,Pass on Dancer 2" > result.csv
	@for i in `cat plugins_list`; do pass_d1=0; pass_d2=0; \
	  echo " ---------- TESTING on Dancer 1 : $$i"; \
          ${CPANM_DANCER1} -n --installdeps $$i \
              && ${CPANM_DANCER1} --test-only $$i && pass_d1=1; \
	  echo " ---------- TESTING on Dancer 2 : $$i"; \
          ${CPANM_DANCER2} -n --installdeps $$i \
              && DANCER_FORCE_PLUGIN_REGISTRATION=1 ${CPANM_DANCER2} --test-only $$i \
              && pass_d2=1; \
          echo "$$i,$$pass_d1,$$pass_d2" >> result.csv; \
        done;

clean:
	rm -rf plugins_list

fullclean:
	rm -rf ${PERLBREW_DIR}

# Get and install Perlbrew locally
${PERLBREW_DIR}/bin/perlbrew:
	@echo " - creating a local perlbrew"
	export PERLBREW_ROOT=${PERLBREW_DIR} && curl -kL http://install.perlbrew.pl | bash

# Get and install cpanm in the local Perlbrew
${PERLBREW_DIR}/bin/cpanm:
	${PERLBREW} install-cpanm

got_curl:
	@which curl >/dev/null \
        || ( echo "you don't have curl, please install it and retry" && false )

got_bash:
	@which bash >/dev/null \
        || ( echo "you don't have bash, please install it and retry" && false )

got_perlbrew_perl: ${PERLBREW_DIR}/bin/perlbrew ${PERLBREW_DIR}/bin/cpanm perlbrew_dancer1_plugin_tests perlbrew_dancer2_plugin_tests

# Build perl from scratch and call this instance dancer1
perlbrew_dancer1_plugin_tests:
	${PERLBREW} list | grep dancer1_plugin_tests > /dev/null \
        || ( ${PERLBREW} install -j 2 -n perl-5.16.1 --as dancer1_plugin_tests )

# Build perl from scratch and call this instance dancer2
perlbrew_dancer2_plugin_tests:
	${PERLBREW} list | grep dancer2_plugin_tests > /dev/null \
        || ( ${PERLBREW} install -j 2 -n perl-5.16.1 --as dancer2_plugin_tests \
             && ${CPANM_DANCER2} ${HERE}/../.. )

# This gets the list of plugins, as previously described
plugins_list:
	${HERE}/get_modules_list.pl > plugins_list

It’s really cool to see what you can do with modern tools of the Perl ecosystem !

Paris.pm technical meeting

2012-09-15T00:00:00-07:00

Paris.pm technical meeting

( french version below )

The next Paris.pm technical meeting will happen the 25th september 2012, with:

Elizabeth Cholet: Firefox automatization with Perl using AnyEvent, Coro and MozRepl modules

Location : 181 avenue Daumesnil, 75012 Paris, France

Google map : google map

If you are interested, and live in Paris, please join us ! If you need more info, ask in the comments.

La prochaine réunion technique de Paris.pm se tiendra mardi 25 septembre 2012, et le programme est :

Elizabeth Cholet : l’automatisation de Firefox avec Perl en utilisant AnyEvent, Coro et les modules MozRepl

Adresse : 181 avenue Daumesnil, 75012 Paris

Google map : google map

Si vous êtes intéressé, n’hésitez pas à venir, entrée libre et gratuite. Pour plus d’info, demandez dans les commentaires.

dams.

MooseX::Singleton is slow

2012-07-04T00:00:00-07:00

MooseX::Singleton is slow

Just a quick note : if you plan to use MooseX::Singleton, beware ! It is easy to use and it implements properly what it claims, however it is quite slow.

If my profilings are corrects, each call to ->instance() calls meta(), get_metaclass_by_name() one time, and blessed() two times.

So for now I’ll avoid it and implement a simplified version using something similar to this :

use Moose;

my $singleton;

sub instance {
    return $singleton //= $CLASS->new();
}

# to protect against people using new() instead of instance()
around 'new' => sub {
    my $orig = shift;
    my $self = shift;
    return $singleton //= $self->$orig(@_);
};

sub initialize {
    defined $singleton
      and croak __PACKAGE__ . ' singleton has already been instanciated'; 
    shift;
    return __PACKAGE__->new(@_);
}

dams.

Dancer is community-driven

2012-06-20T00:00:00-07:00

Dancer is community-driven

Long time I haven’t blogged about Dancer.

Antelink is a french startup, specializing in Software Life Cycle Management and Open Source Component Detection. They provided us with cool Dancer sourcecode analyzis graphs.

Overall contribution by users

.pm files contribution by users

Pod files contribution by users

Test files contribution by users

Reading these graphs

UPDATE : The surfaces represent a mean between the number of commits, and the weight of modifications contributed (in term of “code line”), only when these are original content addition. Moving content around isn’t counted as active contribution.

Note that some people are registered twice with different names, I’ll try to post an updated version

What does that demonstrate ? It shows that Dancer is really powered by its community. Decisions are made together, the code is hacked by multiple hands, and the management is done in a collegial manner on github.

It’s a great reward to be visible on these graphs :)

More Graphs

UPDATE : Erwan (@Labynocle) sent me new graphics, they show the difference between core devs and contributors. By the ay, Erwan will be at the French Perl Workshop in Strasbourg, France.

So here we go :

.pm files contribution by groups

Pod files contribution by groups

Test files contribution by groups

As a side note, I’ve proposed 2 talks related to Dancer for YAPC::EU. One called “Dancer + WebSocket + AnyEvent + Twiggy”, and an other one mixing Dancer, Log::Message::Structured and Message::Passing.

Let’s hope they’ll get accepted !

Cross Posting to blogs.perl.org

2012-04-05T00:00:00-07:00

Cross Posting to blogs.perl.org

So, a while ago, I moved my blog to github, using jekyll and markdown, with jekyll integration in Emacs.

That works great, and I like the fasct that posting a blog entry is just a regular git push.

My blog is aggregated in some places, but it doesn’t appear on blogs.perl.org, because it’s not an aggregator (and that’s cool, it’s not its purpose). But, blogs.perl.org audience is big, and I’m missing all these potential readers (in improbable case people would actually be interested in what I have to say :) )

Anyway, so I decided to bite the bullet and write a script that would cross post my entry to blogs.perl.org. I made the script generic enough to work with different type of blogs, but here I’m going to explain only the blogs.perl.org specific case.

blogs.perl.org is a Movable Type blog engine. A look on Metacpan indicates us there is a Net::MovableType module. That’s great, let’s use that.

There is a catch: to use this module, you need your login, and your API password, not your regular password. You can get it easily though, by following these instructions (thanks to davorg for directing me to it).

To avoid storing the user / password in the script, and to have to pass it on the command line, let’s have a configuration file, that will lie at ~/.crosspost.ini, and that we’ll load with Config::Any::Merge.

The file name of the original post will have to be passed on the command line, using Getopt::Long and Path::Class to retrieve and slurp it.

Here is the configuration file.

# file ~/.corsspost.ini
[ main_blog ]
title = dams blog
url = http://damien.krotkine.com

[ blogs.perl.org ]
type = mt
username = foo
password = bar
url = http://blogs.perl.org/rsd.xml

And here’s the code:

# file crosspost.plcorsspost.ini

use Modern::Perl;
use Carp;

use Net::MovableType;
use Config::Any::Merge;
use Getopt::Long;
use Path::Class;
use Text::Markdown qw(markdown);

my $file;
GetOptions ("file=s"   => \$file)
  or croak "failed to parse command line options";

$file
  or croak "need a file";

$file = file($file);

# Get a hash representing the config file
my $cfg = (values %{Config::Any->load_files({files => [ $ENV{HOME} . '/.crosspost.ini' ], use_ext => 1 })->[0]})[0];

# Grab some main info
my $main_blog_title = $cfg->{main_blog}{title};
my $main_blog_url = $cfg->{main_blog}{url};

my $text = $file->slurp;
# In reality, I do some transformation on $text to interpret jekyll specific
# syntax

$text = "\n <i>cross-posted from [$main_blog_title]($main_blog_url)</i>\n\n" . $text;

# So now we have the content to be posted, but it's in markdown. Let's
# transform it in HTML
my $html = markdown($text);

# Then we loop on all the other blog to cross post to
foreach my $site (grep { $_ ne 'main_blog'} keys %$cfg) {
    say "posting to $site";
    my %properties = %{$cfg->{$site}};

    # for now we handle only movable type
    if ($properties{type} eq 'mt') {
        my $username = $properties{username};
        my $password = $properties{password};
        my $url = $properties{url};

        my $mt = Net::MovableType->new($url);
        $mt->username($username)
          or croak $mt->errstr;
        $mt->password($password)
          or croak $mt->errstr;
        We need to get the user's blog id
        my $user_blogs = $mt->getUsersBlogs
          or croak $mt->errstr;
        $mt->blogId($user_blogs->[0]->{blogid})
          or croak $mt->errstr;

        # finally, the post
        $mt->newPost({
                      title       => $title,
                      description => $html,
                      mt_allow_comments => $properties{allow_comments} // 1,
                     },
                     # uncomment this line to directly post it
                     # 1
                    );

    }
    
}

Missing in this code is some mungling of the text to manage jekyll specific syntax. And while I was at it, I improved it so that it supports cross-posting to twitter, using Net::Twitter, and posting only a short description of the entry. Here is an example (I had to create a custom Twitter app called blog-cross-poster)

Now, I just need to add a git hook to be executed at push time, check if there is a new post or a modified one, and cross post it. Yay !

Perl, fun again!

2012-03-02T00:00:00-08:00

Perl, fun again!

I’m happy to announce a new Perl event that will be held in Paris (France) next Monday, presented by the French Perl Mongers.

It’s called Perl, fun again!

It will be held at La cantine Monday 5 March 2012, in the evening.

From 19:00 to 22:00, a set of short talks (15 min) will be given. I expect a wide audience, beyond Perl users, primarily geeks, coders, web designers, administrators, basically IT-related people with some knowledge of programming ( in any language), and interested in seeing what makes Perl so appealing these days.

I organised the event ( representing the French Perl Mongers ), with the help of Laurent Boivin, and La cantine, kindly hosting the event for free. I managed to enroll 8 speakers, including some well-known Perl figures, to deliver the following set of talks. Of course, in French :) :

19:00

Perl Intro ( Sylvain Lhullier )
Modern Perl Object with Moose (Damien “dams”Krotkine )

20:00

Dancer, the light web framework ( Alexis “sukria” Sukrieh )
Perl and NoSQL, with MongoDB. ( Jean-Marie Gouarné )
Build a webservice easily with Dancer & Spore ( Camille Maussang )

21:00

How to deploy modules and applications with Perl ( Vincent Pit )
Debug and profile with Perl and NYTProf ( David Morel )
Perl development, Perl future ( Rafael “rgs” Garcia-Suarez )

I’d like to thank the speakers to devote their time and passion to help promoting Perl in France.

Dancer::Plugin::Params::Normalization

2012-02-27T00:00:00-08:00

Dancer::Plugin::Params::Normalization

Just released a new version of Dancer::Plugin::Params::Normalization. This plugin allows to normalize or alter parameters recieved by a Dancer route.

An example of what developers usually want is to accept mixedcased request parameters, and have them all lowercased. That is done easily :

# In your configuration file
plugins:
  Params::Normalization:
    method: lowercase

And that’s it, now you are sure that all your parameter names will be lowercases.

Now this plugin goes further by being very flexible and powerful. It supports standard methods like lowercase, uppoercase, ucfirst. But you can also give it a class name, which have to implement a normalize method, thus giving you full flexibility.

If you don’t want all parameters of all routes to be normalized, you can set general_rule to ondemand, and use the added keyword normalize to trigger the normalization. Or, you can instead specify a filter to be applied on parameters. Only those matching it will be normalized.

But that’s not the end. This plugin also allows you to specify which parameters should be normalized: query parameters, body parameters, or the parameters from the route definitions.

I tried to be pretty exhaustive with this plugin, but if anything happen to be missing for your usage, let me know :)

Paris.pm January Technical Meeting

2012-01-13T00:00:00-08:00

Paris.pm January Technical Meeting

( french version below )

Since September 2011, I’ve taken over the management of the Paris.pm monthly technical meetings. Paris.pm is part of the French Perl Mongers.

These meetings happen every months in a very nice building in Paris (it’s an ancient rail station), and usually 15 people gather for one evening. We are relatively well equipped, with a video beamer, microphone and video camera. Thanks to other mongers that help, things go smotthly.

The next meeting will happen the 18th january 2012, with:

Guillaume Rousse: advanced LWP
Pierre Marc: demonstration of the Nirva Systems Application Server

Location : 181 avenue Daumesnil, 75012 Paris, France

Goggle map : google map

If you are interested, and live in Paris, please join us ! it’s free of course.

Depuis septembre 2011, j’ai repris la gestion des réunions techniques de Paris.pm (groupe parisien des Mongueurs de Perl).

Ces réunions ont lieu tous les mois dans des très beaux locaux dans Paris (l’ancienne gare de Bercy), et accueille habituellement une quinzaine de personnes, intéressées par Perl . Nous sommes relativement bien équipé, avec projecteur, micro et caméra, et grâce à l’aide des autres mongueurs, tout se passe bien.

Lors de ces réunions, deux à trois présentations techniques ont lieu, suivis de questions. Le tout se fini généralement dans un restaurant dans le coin.

La prochaine réunion se tient mercredi 18 janvier 2012, et le programme est :

Guillaume Rousse : LWP avancé
Pierre Marc : présentation du serveur d’application de Nirva Systems

Adresse : 181 avenue Daumesnil, 75012 Paris

Lien goggle map : google map

Si vous êtes intéressé, n’hésitez pas à venir, entrée libre et gratuite.

protect a screen session with a password

2011-09-01T00:00:00-07:00

protect a screen session with a password

At work, I’m currently deploying my Perl modules on a new platform ( multiple servers ), which doesn’t have an automated deployment mechanism yet. I use Gnu Screen a lot. It’s a must have tool when working on remote servers.

Long time ago, I spent time to craft a good .screenrc configuration file for my needs. But I only discovered yesterday that I could protect my screen session from being recovered from a super user on the remote server. The documentation is lacking precise description on how to set it up, so here is a quick tutorial.

The idea is that when a screen is running, it can be detached and reattached. However, a super user has the possibility to attach any screen launched by a user of the system. Now, what if inside the screen, you use sensitive informations, or connect to other remote servers ? The super user will have access to these as well. To protect yourself from that (actually to mitigate the issue), it’s possible to have screen ask for a password when trying to reattach it.

DISCLAIMER

In no way this method will prevent root to access your sensitive information. This method will just make it more difficult for a super user to see your screen content using su $user and screen -r -d.

As daxim pointed out on #dancer, there are numerous ways for root to get at your sensitive information :

attach to the process with a debugger, then skip the password check when it comes up
read the process memory of screen and dig out interesting stuff
install a network monitor and grabs your password as it is transmitted next time. rsa encryption (via ssh) does not help because root also has the keys

Launch a new screen

Easily done :

$ screen

Encrypt a new password

screen provides a way to encrypt a password right from a screen session. In the following snippets, I assume the default screen key is A, as default.

# hit ctrl A :password
# enter the new password twice

Now, the encrypted password is in the screen clipboard. We need to retrieve it

Paste the crypted password

The key shortcut for pasting the clipboard is by default Ctrl-A ]

# hit ctrl A ]
# the encrypted password should be pasted in the console

Edit the screen configuration file

Copy the encrypted password and paste it in ~/.screenrc (or whatever your screen configuration file is)

# add this line, with your encrypted password
password VGdGzMopF

Restart screen

You need to restart screen to take the password in account. Now, next time a screen is reattached, the password will be prompted.

dams@foo:~$ screen -r -d plop
Screen password:

Moose and enum

2011-06-17T00:00:00-07:00

Moose and enum

At $work, we are using Moose a lot. So I spend a lot of time declaring attributes, and some of them are Strings that should be picked from a fixed list of values.

For instance, I need to be able to define a task that can be only one of 'profit', 'world_domination'. And use it like so:

# works fine
$attribute->task('profit');

# fails
$attribute->task('failure');

So basically, the attribute is an enum.

The painful way

Until now, I was defining a new subtype for each enum I needed. Something like:

# type definition
use Moose::Util::TypeConstraints;
subtype 'My:Type:Task' => as 'Str' =>
  where { my $r = join( '|', __PACKAGE__->get_possible_tasks ); /^(?:$r)$/ };
coerce 'My:Type:Task' => from 'Str' => via {lc};
sub get_possible_tasks {qw(profit world_domination)}

# attribute declaration
has task => ( isa => 'My:Type:Task' );

It’s very verbose, painful and not readable, isn’t it ?

The right way

Moose::Util::TypeConstraints provides the enum method, that serves exactly our purpose. It’s basically a shortcut to create a subtype based on ‘Str’, limited to a list of possible values. You can use it to build a named enum subtype, or an anonymous subtype. See the usage in our case :

# using a named enum subtype:
use Moose::Util::TypeConstraints;
enum 'My:Enum:Task', [qw(profit world_domination)];
has task => ( isa => 'My:Enum:Task' );

# using an anonymous enum subtype:
use Moose::Util::TypeConstraints;
has task => ( isa => enum([qw(profit world_domination)]) );

So that’s all, I guess this kind of feature is nothing new for seasoned Moose developers, but it may help beginners, as there is no mention of enum in Moose::Manual::Attributes.

Perlbrew, Emacs, Flymake

2011-05-27T00:00:00-07:00

Perlbrew, Emacs, Flymake

So I’m a seasoned user of Emacs (I started using it back to 1999). I’m using it for all things, especially Perl coding, using the cperl-mode Emacs mode.

Lately, I’ve come to using flymake. Flymake is a tool in Emacs, which tries to compile the file you are editing, and displays compilation errors in your buffer. There is a mode for Perl, so the result is really nice : realtime syntax checking of the current Perl file you’re editing. It looks like that :

Perl + Emacs + Flymake + PerlBrew

Then comes perlbrew, which allows you to have multiple Perl interpretors installed on your machine, and switching between them easily.

Alas, flymake is not working by default with Perlbrew, as it uses /usr/bin/perl. So one needs to configure Emacs to recognize various perls installed via Perlbrew, and tell Flymake to use one of them.

kentaro has made a Perlbrew mode, and explained how to use it with flymake.

However, for various reasons, this Perlbrew mode it doesn’t work well on my machine and Franck ( lumperjaph ) reported similar issues.

So I went on and rewrote a simple Perlbrew mode that would do almost nothing. It would only play with directories path, to allow you to say where the various Perlbrew perls are installed, and which one to use. perlbrew-mini.el was born.

perlbrew-mini.el

Requirements : you need Emacs, a functional perlbrew with at least one Perl installed, and you need Project::Libs.

Then, download perlbrew-mini.el from github, and put it in a place where Emacs will see it.

Then, edit your .emacs so that it contains these lines:

(require 'perlbrew-mini)
;; change to your username below
(perlbrew-mini-set-perls-dir "/home/uername/perl5/perlbrew/perls/")
;; change the version you wish to use
(perlbrew-mini-use "perl-5.12.2")

(require 'flymake)

(defun flymake-perl-init ()
  (let* ((temp-file (flymake-init-create-temp-buffer-copy
                     'flymake-create-temp-inplace))
         (local-file (file-relative-name
                      temp-file
                      (file-name-directory buffer-file-name))))
    (list (perlbrew-mini-get-current-perl-path)
          (list "-MProject::Libs" "-wc" local-file)))
)

(add-hook 'cperl-mode-hook (lambda () (flymake-mode t)))

And voilà, Flymake will work with your Perlbrew Perl, as it used to work with the system Perl.

DateTime duration in seconds

2011-05-25T00:00:00-07:00

DateTime duration in seconds

It has been too many times that I forget how to get a DateTime::Duration between two DateTime objects in seconds (and nanoseconds). That is, where I can then do ->seconds and have the duration in seconds between the two dates.

I know it’s in the DateTime POD, but I keep forgetting it, and it takes me always a lot of time to find it back.

Here it is so that hopefully the next time I search for “Perl DateTime Duration seconds” on the Intarweb, it shows up…

my $duration = $dt2->subtract_datetime_absolute($dt1);
my $seconds = $duration->seconds();

Simple usage of Perl state variables

2011-05-24T00:00:00-07:00

Simple usage of Perl state variables

I see this type of code too often:

package Foo;
{
  my $structure = {};
  sub plop {
      #...
      $structure->{$foo} = 'bar';
      #...
  }
}

Or things like that:

package Foo;
{
  my $cache;
  sub plop {
      #...
      defined $cache or $cache = _load_cache();
      #...
  }
}

If you are using a non-ancient version of Perl (that is, 5.10 or more), you should consider using the state keyword. It’s similar to the static variables inherited from C.

From the documentation :

state declares a lexically scoped variable, just like my does. However, those variables will never be reinitialized, contrary to lexical variables that are reinitialized each time their enclosing block is entered.

So the two code snippets become :

package Foo;
sub plop {
    state $structure = {};
    $structure->{$foo} = 'bar';
    #...
}

and:

package Foo;
sub plop {
    #...
    state $cache = _load_cache();
    #...
}

Nothing terribly amazing here, but it’s really easy, saves keystrokes and makes the code more readable. So why not use it more widely ?

Moose trick with MooseX-Getopt and roles

2011-05-18T00:00:00-07:00

Moose trick with MooseX-Getopt and roles

18 May 2011 - Paris

On MooseX::Getopt

At work I extensively use Moose in my everyday Perl coding. I also use MooseX::Getopt to automatically handle command line arguments as attributes, thus simplifying the implementation of scripts.

By default, MooseX::Getopt consider all public attributes to be mapped on a command line argument. There are many ways to tell MooseX::Getopt to ignore a public attribute:

you can turn your attribut to a private one, but with public accessors
you can have the attribute use MooseX::Getopt::Meta::Attribute::Trait::NoGetopt
you can have the attribute use the MooseX::Getopt::Meta::Attribute::NoGetopt

Act on distant attributes

The previous actions are to be performed on the attribute definition. But what about the situations where you don’t write the attribute definition yourself ? Like, for instance, if you inherits the attributes from an other class, or if you got the attributes by consuming a role ?

In this case, you’ll need to perform an action on the attribute from a distance. Here are two solutions, that were given to me by the nice folks on #moose (namely sartak and doy)

Apply the trait from a distance

The first solution is to run this code after having consumed a role, or inherited a class, that provides the attribute ‘some_attr’:

   MooseX::Getopt::Meta::Attribute::Trait::NoGetopt->apply(
       __PACKAGE__->meta->get_attribute('some_attr')
   );

Adds the trait to the attribute definition

A syntactically simpler solution is to add the trait in the attribute, in our class:

    has '+some_attr' => (traits => ['NoGetopt'])

The ’+’ character allows to add things to an already defined attribute, instead of trying to overwrite its definition altogether.

Migrating to Jekyll

2011-04-30T00:00:00-07:00

Migrating to Jekyll

30 Apr 2011 - Paris

So, this post is about migrating this blog from Typepad to Jekyll, using a small Perl script.

The reasons why I’m moving away from Typepad are :

Typepad is slow
Typepad is not free
Typepad editor is not techie compatible
Typepad is a blog engine…

And blog engines are not hype anymore :) Seriously, I was looking for something easy and simple, and compatible with my geek side.

Back in the days, I remember that I enjoyed a lot using nanoblogger. But it’s too slow, and you need to host it yourself.

So I followed the current trend, and set up my pages on github, and transfered my posts from Typepad to jekyll.

Jekyll is :

light
easy
simple

But the real power is that it can be coupled with github’s pages. So I feel right at home, and so editing code and pushing to git(hub) (stuff I do everyday) won’t be different from editing blog posts and pushing to github.

Oh, but how did I migrate my blog posts from Typepad to Jekyll ? I couldn’t find any migration script on internet or importers in jekyll, so I wrote a quick and not so dirty Perl script. it’s all on github here : the mighty typepad_to_jekyll ! Feel free to fork it. Feedback welcome :)

Perl Moderne, a new Perl book

2011-02-16T00:00:00-08:00

I haven't been blogging a lot this year-and-half, and for various reasons. But the reason number one is that I've been very busy writing a Perl book from scratch, in French, with 3 other fellow French Perl Mongers.

The book is called Perl Moderne. That means "Modern Perl", but it has nothing to do with chromatic's book. The book was actually published long time ago, end October 2010. But it took us authors some time to recover :)

This book is written in French, for French speaking readers. Its goal is to present the Perl 5 language as it exists now, and tries to teach the reader how to start using it the right way, that is, the modern way. The book is not a bible, nor an encyclopedia of the historical language. Instead, it's a collection of the useful concepts that are used nowadays, and how to use them in the latest version of Perl and CPAN.

The reader can be a total newbie in Perl, but it has to have a previous development experience with an other language, for instance PHP, Ruby, Python, or Java. However, the book goes far beyond introducing the language. It allows the reader to become fluent with the Perl data structure, regexps, Moose OO and typing, POE, interacting with databases, files, DateTime, XML and configuration files, Web interactions, and more...

It's big in content (many subjects covered, and 450 pages !) but small in size, as it's an A5 format, so it fits easily in a bag, and it's not heavy :)

The people

Historically, Pearson France, the press editor, posted a request on the French Perl Mongers mailing list, saying that they were looking for authors willing to write a new Perl Book in French.

I decided to not let this opportunity pass : it's very rare that French editors are interested by Perl, and willing to produce good quality books. After some struggling, I ended up setting up a team of 4 brave French Perl Mongers, that became 4 Perl book authors :

Sébastien Aperghis-Tramoni (SAPER on CPAN) : active French Perl Monger, he knows almost everything about CPAN modules. He wrote several modules himself, and maintains numerous others. He wrote several Perl articles in the GNU/Linux Magazine France. He is also the hidden admin of your Perl conferences, as he maintains Act, empowering a lot of Perl conferences
Philippe Bruhat (BOOK on CPAN) : well known Perl figure, active French Perl Monger, former president of them, founder and treasurer of the YAPC Europe Foundation. Received a White Camel Award in 2009, and maintains quite a few modules on CPAN. Also wrote articles in the GNU/Linux Magazine France.
Jérôme Quelin (JQUELIN on CPAN) : active French Perl Monger, knows a great deal about Tk, wrote Games::Risk among other things, and maintains a bunch of CPAN modules. He is also maintaining a lot of Perl packages at Mandriva and Mageia. Also wrote articles in the GNU/Linux Magazine France.
Damien Krotkine (DAMS on CPAN) : well that's me ! I'm an active French Perl Monger, using Perl for 11 years or so, I wrote a couple of Perl articles in the GNU/Linux Magazine France, have some modules on CPAN (among them Curses::Toolkit), and I'm now a proud core developer of Dancer, the new big thing.

The content

Perl Moderne starts with a gentle (but concise) introduction to Perl, with many pointers to external resources, focusing on ease-of-use. For instance, we mention CPAN and cpanm very early. Then the real business starts with an explanation of the major programming concepts (data structures, OO, databases, formats, event programming and the intarweb).

We tried to provide a preferred way to do each thing, while mentioning alternatives. We didn't separated the language and CPAN. "Perl is the syntax, CPAN is the language"... So about half of the book describes how to solve a problem using this or that CPAN module. And I think it's great. It allowed us to teach Object Oriented programming with Moose, explain event programming with POE, etc.

I think it is very important that new Perl books get written, and very important that some are written natively in non-english. It fits better its purpose to the localized need (students, teachers, academic structures and way of thinking are different from one country to another). That also makes editors aware of the local Perl activity, and help spreads the words about the language in schools and universities, where native books are preferred to translations.

So, if you know any French speaking (or learning) geek or computer scientist, around you, please consider recommending them this book. It was crafted with care and love by Perl passionated ! :) You can point them to the dedicated website of Perl Moderne

Here is an english translation of the table of content :

01. Start with Perl
02. Install a Perl module

I. Language and data structures
03. Language
04. Data structures
05. Regular expressions

II. Modern object programming
06. Basic Perl objects
07. Moose
08. Typing system in Moose
09. Methods in Moose

III. Data manipulation
10. Files and directories
11. SQL databases
12. SQL abstraction, ORM, non-SQL databases
13. Dates and times

IV. Formats
14. XML
15. Data serialisation
16. Configuration files

V. Event programming
17. Introduction to POE
18. Practical POE
19. Distributed POE

VI. Web
20. HTML documents parsing
21. HTTP and the Web
22. LWP
23. Web browsing
24. WWW::Mechanize

Perl Dancer and DBIC

2010-12-13T00:00:00-08:00

Are you curious to see how to create a real app from scratch with Perl Dancer, using DBIX::Class ? Well, my Perl Dancer Advent Calendar article has been published saturday :

http://advent.perldancer.org/2010/11

Enjoy !

Disqus on Typepad

2010-12-07T00:00:00-08:00

Disqus is great. It's a full featured cross-site comments free management system. I have an account on it, so I wanted to use disqus instead of the typepad comments system.

"Easy enough" I said to myself : there is a dedicated page to help you install Disqus in Typepad. This includes adding a new "Embed your own HTML" module in your blog content, and copy-pasting a Javacript snippet in it.

Alas, the Javascript snippet didn't work fine. I suspect that the Typepad code has changed since the Disqus install documentation has been written. Maybe the Javascript code of Typepad tries to block other scripts playing with the comment tags.

Anyway, here is a solution : I changed the code a bit, and wrapped it in an Javascript onload . I'm not saying it's the best solution, but it works for me... Here is the Javascript code snippet to be used instead of the one Disqus provides in the Typepad Install section. Of course, replace YOUR_DISQUS_LOGIN with, well, your disqus login...


<script type="text/javascript">

var my_func = function() {
  var div = document.getElementById('all-comments');
  var script = document.createElement('script');
  script.type = 'text/javascript'; script.src = 'http://disqus.com/forums/YOUR_DISQUS_LOGIN/embed.js';
  document.getElementsByTagName('body')[0].appendChild(script);
  div.innerHTML = '' ;
  div.id = 'disqus_thread';
};

var x = window.onload;
window.onload = function() {my_func(); if (x) x(); }

</script>

Let me know if it works for your Typepad blog.

Perl Dancer version 1.2 and Advent Calendar

2010-12-01T00:00:00-08:00

Perl Dancer should at least ring a bell to you : it's a popular Perl micro web framework. Route based, easy to use, simple clean design, with low dependancies, Dancer is gaining in popularity and maturity.

Version 1.2 has been released ( see sawyer's announcement here ), and is described as the first stable community release.

But that's not all ! Go check out the awesome Perl Dancer Advent Calendar. You'll learn all about Dancer, how to get started with it, what cool plugins are available, what are the nice tricks. Step by step, a new article will be revealed each day.

Dancer is a young project with a nice community. Check it out :

http - http://perldancer.org/
IRC - #dancer on irc.mongueurs.net
ml - http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

Ulimit doesn't work on Leopard (memory limitation)

2010-10-06T00:00:00-07:00

After many tests on my side, I got confirmation from this page : it looks like ulimit doesn't work for memory limitation starting from Mac OS 10.5. That's a shame...

perl -E 'use BSD::Resource; setrlimit(RLIMIT_VMEM, 2000, 2000); my $s; for my $i (1..50_000) { $s .= "A" x 1024 } say "damned, I should have been killed"'

Merge PDFs easily with Perl

2010-06-29T00:00:00-07:00

Today I discovered an easy way to merge PDFs files using Perl.

In my current project, I have to automatically generate a technical documentation from my perl modules PODs. It's easy to create one PDF file for each modules, but then I need to merge them all in one.

The very easy to use CAM::PDF Perl module provides appendpdf.pl. However it can only merge 2 files together.

I've copied and modified it for my need, and renamed it mergepdf.pl

Download : mergepdf.pl

Usage : appendpdf.pl [options] file1.pdf file2.pdf ... fileN.pdf outfile.pdf

See the help for more options.

flagedit

2010-03-29T00:00:00-07:00

Description

flagedit is a CLI USE flag editor for Gentoo Linux. It let you edit the use flags of /etc/make.conf, as well as the /etc/portage/package.use file.

features :

edit system use flags (in /etc/make.conf)
edit per package use flags (in /etc/portage/package.use)
edit system keyword (ACCEPT_KEYWORDS in /etc/make.conf)
edit per package keywords (in /etc/portage/package.keywords)
get the list of possible use flags, and keywords, with their descriptions
flagedit warns you when you try to edit a flag or keyword that doesn't exist
you can specify alternates files for package.use package.keywords make.conf
it creates a backup before overwriting

News

2009.01.16 Version 0.0.8. make flagedit compatible with directories support ( as per bug 241668 )

2005.12.26 Version 0.0.7. The help fits in 80 columns

2005.11.24 Version 0.0.6. some improvments

2005.11.15 Version 0.0.5. some improvments

2005.10.14 Version 0.0.2. An ebuild is available for gentoo linux.

2005.09.29 New version : now warns if the flag is not a valid one. More features also

2005.07.24 just did this web page.

Download

here

Documentation

This is just the raw output of flagedit --help, but I think it's self-explanatory :

flagedit allows you to edit the use flags or the keywords for a particular
ebuild, or for the whole system. a backup is done for each modified file, named
file.old.

Usage: flagedit [PACKAGE] [ACTIONS | -- KEYWORD_ACTIONS] [ OPTIONS ]

Examples:
 flagedit net-im/amsn --show # shows the use flag set for net-im/amsn
 flagedit net-im/amsn +gnome # adds the gnome use flag to net-im/amsn
 flagedit net-im/amsn -kde +xmms # adds the xmms use flag and set the -kde one
 flagedit net-im/amsn %kde # reset the kde use flag (it's removed from the line)

 flagedit %kde # reset the global use flag (it's removed in make.conf)
 flagedit +gnome -qt # add gnome and -qt in make.conf

 flagedit net-im/amsn -- %x86 # reset the x86 keyword for net-im/amsn
 flagedit net-im/amsn -- +~ppc +~x86 # adds the ~ppc and ~x86 keywords for net-im/amsn
 flagedit net-im/amsn -- % # resets the keywords for this package
 flagedit -- +~x86 # sets ACCEPT_KEYWORDS to "~x86" in /etc/make.conf

You can mix the flags and keywords :
 flagedit net-im/amsn +gnome -- +~x86

PACKAGE is a package name (like dev-ruby/ruby-atk). If no package is given,
flagedit will edit the maine USE flags (in make.conf), or the main
ACCEPT_KEYWORDS (in make.conf)

ACTIONS are :
+FLAG enable the FLAG. Example : +sse
-FLAG disable the FLAG. Example : -sse
%FLAG reset the FLAG to default. Example : %sse
% reset the whole flags of PACKAGE to default. In this case, PACKAGE is not optional

KEYWORD_ACTIONS are :
+KEYWORD enable the keyword. Example : +x86
-KEYWORD disable the KEYWORD. Example : -~x86
%KEYWORD reset the KEYWORD to default. Example : %x86
% reset the whole keywords of PACKAGE to default. In this case, PACKAGE is not optional


OPTIONS are :
 --package-file <path> specify an alternate package.use file (default is /etc/portage/package.use)
 --keywords-file <path> specify an alternate package.keywords file (default is /etc/portage/package.keywords)
 --make-conf-file <path> specify an alternate make.conf file (default is /etc/make.conf)
 --portage-dir <path> specify an alternate portage directory path (default is /usr/portage)
 --alpha-order sort the flags or keywords alphabetically instead of keeping the original order
 --show don't edit, display the flags or keywords of the PACKAGE. If no package is given, display the system USE flags or the system ACCEPT_KEYWORDS.
 --list don't edit, display the entire list of possible flags or possible keywords.
 --desc if specified with --list, display the flags or keywords description also.
 --keywords specifies that actions are to be done on keywords, not on use flags
 -- same as --keywords
 --strict if a specified flag or keyword name is invalid, dies, instead of just warning.
 --nowarn if a specified flag or keyword name is invalid, don't warn.
 --help this help
 --version prints the version
 
see http://dkrotkine.com/flagedit/

About

author : dams
license : GPL-2 (not upper version)

Thanks to

tigger for requesting it, and testing.

Syntax Highlighting in Typepad

2010-03-15T00:00:00-07:00

Code Snippets, Syntax Highlighting, Source examples, Verbatim text, etc...

I'm sure I'm not the only one to need to display nice clean and compatible code snippets, source code examples, and similar stuff. I'm using Typepad as blog engine, but what I'll explain here should work with MovableType as well (as the former is a professional version of the open source latter one).

First of all, the needs :

I need a tool to display code snippets, examples,
It has to be easy to use,
It has to be nice
It should have syntax highlighting and coloring
It has to support Perl, Javascript, and ruby syntax
It has to allow download and view as text
It has to degrade properly, so that it works in RSS clients

The solution is of course SyntaxHighlighter, the well known tool by Alex Gorbatchev. This tool is used widely and some people have already written on including it in Movable Type, or even in Typepad.

But I thought I would write on it as well, because there are some subtleties, and both SyntaxHighlighter and Typepad evolved since these entries were created.

So, if you don't know this too yet, or are too lazy to check its description page, SyntaxHighlighter is a pure JavaScript + CSS tool that finds and renders content, from a specific standard HTML tag you specify.

Example

# Some Perl code my $var = 42; my @array = map { reverse } grep { length } @strings; sub my_function { my ($a, $b) = @_; return ($a * $b); }

Download

First of all, you don't want to download SyntaxHighlighter from it "official" google code home, because it's hosted by Google (sorry, just kidding) because only the version 1.5 is available there. What we want is version 2.0, which has more features, and includes a Perl syntax brush by default (so no need to get it from elsewhere).

Download SyntaxHighlighter from this page. I downloaded version 2.1.364 (local copy here in case the site is down)

Upload to your TypePad Account

Next, you need to upload the files to your TypePad File Manager. You'll find it in the Library Tab.

Then create a directory (I created mine as syntaxhighlighter at the root), and upload the following files. This list is the bare minimum to have it working, but you can (you should) add more brushes to support more languages highlighting, and also upload the icons (the .png files). You could as well upload all the languages brushes. And you can also use a different theme (I'll try the Emacs one, as I'm an Emacs addict).

Make sure your upload works by trying to access one of the file (of course replace your real site host name) :

http://YOURSITE.COM/syntaxhighlighter/shCore.js

If you can see or download the file, it means the files are properly uploaded.

Add some magic

For SyntaxHighlighter to work, you need to include some Javascript and CSS to the pages that will contain things you want to highlight. The best is to include it on every pages, as the tool is smart enough to find and apply styling only on what you specify to be highlighted.

Now, how do you add CSS and Javascript to your TypePad blog? There are two cases :

Either you are using a simple TypePad design
Or you are using an advanced TypePad design

All blog entries I've seen on this topic only handles the case of advanced design, because it's easier to do. But, people using advanced design don't need a tutorial to include SyntaxHighlighter on their blog, they are, you know, advanced enough to do it on their own... So I thought it would be more useful to describe how to do with a simple design.

With a simple design on TypePad, you don't have access to the templates of the pages, but luckily, you can add a module that allows you to add any HTML code in your page. So the idea is to this module to your design content, and add the needed javascript and CSS reference to it. Here is how you can do it.

From your TypePad dashboard, go to Design -> Content
Add a new module, called "Embed your own HTML" (see picture)
Give it a name (it's not used in the page, it's just to see what this module is here for).
Be sure that you move the module to be on the lowest part of your blog content (to be loaded last)

The content of the module will be used to load SyntaxHighlighter. Here is what I input in the module :

<script type="text/javascript" src="http://YOURSITE.com /syntaxhighlighter/shCore.js"></script>   <script type="text/javascript" src="http://YOURSITE.com /syntaxhighlighter/shBrushPerl.js"></script>   <link href="http://YOURSITE.com/syntaxhighlighter/shCore.css" rel="stylesheet" type="text/css" /> <link href="http://YOURSITE.com/syntaxhighlighter/shThemeDefault.css" rel="stylesheet" type="text/css" />  <script type="text/javascript"> SyntaxHighlighter.config.tagName = "code" // use <code> tags SyntaxHighlighter.config.stripBrs = true // disregard trailing <br> SyntaxHighlighter.all() </script>

The Options

As you can see, there are 2 options set at the end. These options are to make SyntaxHighlighter more compatible with the TypePad graphical editor. By default, SyntaxHighlighter looks for <pre> tags. But these are rebuilt each time you modify an entry in the graphical editor. So one of the option is to be able to use <code> tags, that are left untouched by TypePad. Well, almost untouched, TypePad tends to add <br> tags at the end of line, which is why the seconde option is there.

Include your code snippet in TypePad

Now that everything is setup, all there is to do to have a nice code example into TypePad is to create a new Post, write the text using the "Rich Text" view of the editor. Then when you want to include a code snippet, switch to the "HTML" view, and add this :

<code class="brush: perl"><br> # Your code example goes here. For instance, some Perl :<br> my %hash = { foo => 'bar' };<br> </code>

Which will output on your blog page as :

# Your code example goes here. For instance, some Perl : my %hash = { foo => 'bar' };

And inside the TypePad graphical editor, this is what you will see. Most of the Atom / RSS feeds client (like Google Reader) will also have it like this :

Which is in my opinion, not too bad !

Conclusion

So here it is : a nice, free and open source syntax highlighter in your TypePad posts, easily included, wich themes, colors, a lot of languages supported, and which degrades nicely for feeds readers. There is more customization possible, I suggest you go look at the SyntaxHighlighter documentation.

I have tried to make this post / tutorial as easy as I possible, but please let me know if you think I should clear ups things, or add more screenshots. If you try to do it on your TypePad account and it works, let me know in the comment. If it doesn't work, I'll try to help.

Typepad

2010-03-05T00:00:00-08:00

I'm in the metro of Paris, testing Typepad :

new beta account I just subscribed to
new mobile version of the blog
Iphone App
automatic Twitter posting
per category feeds

Typepad is Based on Movable Type, the best blog system ouuta there. It's Perl based. It rocks.

Perl tests in Hudson via JUnit

2009-11-25T00:00:00-08:00

Perl tests in Hudson

I'm willing to automate the unit testing of my Perl modules, by plugging them into Hudson. Hudson is a continuous integration server, it "monitors executions of repeated jobs, such as building a software project or jobs run by cron". It works well, is extensible, and looks good.

So, The easiest way to do that is have Hudson to execute the module test suite, and look at the output. Actually, not really the output, but a file containing the output of the tests, in JUnit format.

Now, by default, Perl unit tests doesn't output JUnit. You know, that kind of stuff :

That's the standard output of tests run through TAP, the Test Anything Protocol, which is great, and (imho) better than JUnit.

Anyway, that output is generated because the tests are run through TAP::Harness, that outputs the result in TAP format on the console.

So first of all, let's see how to transform the tests output into JUnit. My modules use Module::Build (and also Dist::Zilla, but that's an other story) as building and releasing system. When using Module::Build, running the test suite is easy :

Solution 1 : use TAP::Formatter::JUnit

After some research and looking in the source code, I discovered that you can pass a lot of options to TAP::Harness, via Module::Build. Especially, you can specify a formatter to TAP::Harness when running the test suite. TAP formatters are modules that all inherit of TAP::Formatter::Base.

For instance, if instead of outputing the result on the console, you want it to be stored in a file, use TAP::Formatter::File. As you may have guessed now, there is a formatter that outputs JUnit : TAP::Formatter::Junit. That's exactly what we want. By issuing the following command line, the output of the test suite is in JUnit format.

Now we just need to tell Hudson to run it and look at the output

Solution 2 : use TAP::Harness::JUnit

For some reasons, I had some trouble with TAP::Formatter::Junit on windows, mainly because there is no ActiveState PPM for this package. So I decided to give a go with TAP::Harness::JUnit

Its documentation is self-explanatory : it's a child class of TAP::Harness, that accepts an xml file name as argument, and procudes directly a JUnit output. This module being directly available in ActiveState Perl, it seemed to be aa good approach.

So the goal is to replace the call to TAP::Harness into TAP::Harness::JUnit, when doing Build test. And actually, it would be better to have an additional action to Build, so that we could do Build test, and Build hudson_test.

Luckily, Module::Build makes it easy to add an action. By looking at the ACTION_test method in Module::Build::Base, it's easy to see what needs to be changed. See this code snippet. What we want is a copy of that code that would run TAP::Harness::JUnit instead of TAP::Harness.

After some work, here is what I eneded with. This code is to be added into your Build.PL.

Now, build and run your tests in hudson mode

Configure Hudson

That's the easiest part : Setup a new project, add as execution line "perl Build.PL & Build hudson_test" (if you are on a windows hudson node). And point the project to the output file called "hudson_test_output.xml". That's it !

Curses Toolkit is on CPAN

2009-10-31T00:00:00-07:00

After few months of delay, Curses::Toolkit is now available on CPAN.

Curses::Toolkit tries to be a modern toolkit to implement semi-graphical interfaces using Curses. It's inspired by Gtk.

I gave a presentation of Curses::Toolkit at the French Perl Workshop 2009, and at the Open Source Developers conference France 2009. BooK presented it as part of a Lightning Talk at YAPC EU 2009 where I couldn't participate. Thanks to him for that. I will try to participate to London Perl Workshop this year and give a talk about it as well. I have received quite good feedback from people and users about it.

I'd like to mention that Jerome Quelin helped me with the initial release, injecting some Dist::Zilla magic into Curses::Toolkit. Thanks, Jerome.

What next ? I'll try to post a video of what is currently possible with Curses::Toolkit. I need to add more widgets and signals, and fix some bugs. Also, migrating to Moose is on the todo list. The module is usable now, but you can't really build a very nice big application with it.

Want to help ? If you have some free time, please consider helping me on next development of the module. You don't need to be a coder, here are some of the things you could help with :

Improve documentation : current documentation has some errors, and a better front page for the module would be good.
Create a Tutorial : preferably in POD, but not tied to follow sub-modules' names
Help implementing additional widgets
Create new themes : it's all about colors
Help the migration to Moose

If you're interested, contact me. The source is here

New Home

2009-10-29T00:00:00-07:00

The new server I had setup few weeks ago got hacked, brute force ssh attacks being made from it... I had spent some time setting it up, and now I'm bored.

So, I decided to migrate my blog to a hosted solution. As I'm a big fan of movable type, I decided to give Typepad a go. So this is yet another rebirth of my blog (I think it's the 6th time now).

I'll use that opportunity to catch up with the Perl blogging Iron Man competition.

More to come about Perl and Curses::Toolkit, my baby :)