Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

BooK (2612)

BooK
  {book} {at} {cpan.org}
http://paris.mongueurs.net/
Yahoo! ID: philippe_bruhat (Add User, Send Message)

Obfuscation [plover.com]. Pink [axis-of-aevil.net]. HTTP::Proxy [cpan.org]. YEF [yapceurope.org]. Fishnet [perl.org]. Kapow [cpan.org]. Cog's [perl.org] bitch [cpan.org]. Invitation [perl.org]. White [perl.org] Camel [perl.org]. Nuff' said.

Journal of BooK (2612)

Thursday October 22, 2009
03:13 AM

Switching perls

I have a few perls compiled and installed in /opt/perl:

$ ls /opt/perl
5.10.0  5.6.2  5.8.7  5.8.8

A long time ago, I tried to set up an environment that would setup the proper PATH to always reach the perl I wanted when typing perl on the command-line. That involved a shell script, which of course couldn't change the environment of the outer shell, so it actually started another shell, resulting in the following mess:

5271 pts/2    Ss     0:01 bash
6182 pts/2    S      0:00  \_ /bin/bash ./perlenv 5.10.0
6183 pts/2    S      0:00      \_ /bin/bash

I could also have moved a canonical symlink around, but this had the advantage that several independent shells could run different perls.

Anyway, that was unworkable until I realized I could change the current shell environment using aliases or shell functions. So, assuming my perl binaries live in /opt/perl/$VERSION/bin, the following bash shell function does the trick:

setperl ()
{
    export PATH=`echo $PATH|sed -e "s:/opt/perl/[^/]*/bin:/opt/perl/$1/bin:"`
}

And my ~/.bashrc points to the perl I want to use by default.

Wednesday October 14, 2009
02:00 AM

Mail::Box++

So sferics' disk died and took everything that wasn't backed up with it. It turns out that one of the important configuration items that weren't backed up were the configurations and subcribers lists of the Mailman mailing-lists.

To get the subscribers lists back, we didn't have many options:

  • Resubscribe all posters, which would also subscribe the ones who did unsubscribe at some point, and kick out all the lurkers... Not so good.
  • Process all the administrative messages to get a chronological list of subscribe/unsubscribe action, and rebuild the list from there.
  • Seed the list with the list of posters, if possible the subscribed ones (i.e. not the one whose mails were passed through moderation)

We use Mailman for managing our mailing-lists. It works well enough for us, but it has its share of hate:

  • Localized admin messages are nice, but a X-Mailman-Action header would be nicer, so we would have to process the body of each actions, in all languages we might have used

Luckily, it also has a few helpful headers:

  • List-Id, so we can process a folder full of admin messages and know about which list each message is about
  • X-Mailman-Approved-At, so we can detect messages sent by non-subscribed posters

I used Mail::Box to create two scripts to process the messages (in French and English, so anyone who subscribed in German is out of luck) and provide some useful info (the people with the archives and the admin-fu did the actual work of fixing the lists).

Sure, Mail::Box is slow, and the interface is a bit complicated, but on the other hand it is well documented, and it's correct.

Summary at the end of the day^Wlong week-end:

  • (incomplete backups)--
  • Mailman-- # misses useful headers that would have made the job easier
  • Mail::Box++ # gets the job done in 20 lines
Monday October 05, 2009
06:21 PM

OSDC.fr

I just came back from OSDC.fr (Open Source Developers Conference, France). This was the first edition of the conference, organized jointly by Les Mongueurs de Perl, AFPy (Association Francophone Python) and Ruby France.

There were a lot more people on the Saturday than on the Friday, probably because many people were at work and it was hard for them to get work to let them go on company time. Or something.

In my view, as an attendee and an organizer (I had a tiny tiny role in the organizing team), it was a great success. I saw presentations about:

  • OpenSUSE on the Gdium
  • Cucumber (Ruby)
  • Hadoop
  • Seaside (Smalltalk)
  • Moose (Perl)
  • JavaScript
  • MySQL
  • Acmeism (Ingy döt Net's new religion)
  • Dancer (yet another Perl web framework)
  • Why one shouldn't say that "reinventing the wheel" is bad, but "reinventing the toothbrush" clearly is
  • And a few others...

The Seaside presentation was really an eye-opener showing how clean web development can be (and how exciting Smalltalk is), even though I'll probably never use it.

I keep hearing about Moose and Catalyst, but am too lazy and busy to really start investing and learning about those. So going to the Moose talk at least kept me informed.

I realized Acmeism is the religion of OSDC.fr. ;-)

Dancer is a new lightweight web framework (ported from Ruby's Sinatra) and I really want to try it now. Maybe some of the websites' idea I have will finally see the light!

In the hallway track, I spent some time talking about gender issues with a woman (not a developer, but having been involved in a few projects with geeks) that was passing by and stopped to talk with us. I also spent a lot of time showing the power of Git to other Perl Mongers. In the end, I took over an empty slot to tour the Git object database and reply questions from the audience... I really should work on the Git tutorial I have in mind. (By the way, O'Reilly Media's Version Control with Git contains everything I would like to find in a Git tutorial, and more.)

All in all, excellent conference; I got to meet the people from over the fences and you won't believe how much they look like us. ;-)

Tuesday September 29, 2009
07:04 AM

Test::Database, for CPAN testers

Hopefully, a week after my Test::Database, for CPAN Authors, some CPAN authors have started to use Test::Database. ;-)

Test::Database is fine to test database independence on your local setup, but to really leverage the power of CPAN Testers to fully test your module over all types of setups, it needs to be installed and configured on a sufficient number of tester hosts.

During my YAPC Europe 2009 talk about Test::Database, I invited several CPAN testers to attend. This is a chicken and egg type situation: this is a useful module, but CPAN authors will use it if they know it will be available on a reasinable number of testing hosts. On the other hand, few CPAN tester will bother configuring it if noone's using it anyway.

This post is basically a replay of my YAPC::Europe talk: last week I invited CPAN authors to try out Test::Database, and this week I invite CPAN testers to install and configure Test::Database as part of the toolchain installed on their smokeboxes.

And the documentation contains a nice tutorial, so it shouldn't be too hard.

Monday September 21, 2009
08:40 PM

Test::Database, for CPAN authors

About a year ago, I realized there was no good way to test code that claims to be database independent. Even testing code that needs a database is difficult: most modules either use SQLite (but they don't test the database independence) or request some environment variables defining the DSN to be setup (but these are unlikely to exist on a CPAN tester's machine, though).

So I decided to write Test::Database.

It took me a while to get right, but thanks to the isolation and focus that the Birmingham QA Hackathon from March 2009 gave me (and the completely broken state I put the module into at that time), I managed to come up with a satisfying version 1.00 in July this year (the module is now at version 1.06).

Basically, what Test::Database does is simply this: it gives you the information you need to connect to a database that matches your testing needs (implicitely allowing you to do whatever you want in there, including creating and dropping tables).

Test::Database has a single interface for test authors:

    my @handles = Test::Database->handles( @requests );

@request is a list of "requests" for databases handles. Requests must declare the DBD they expect, and can optionaly add version-based limitations (only available for drivers supported by Test::Database).

Test::Database will return as many matching Test::Database::Handle objects as it can find or create, depending on the locally installed modules and the configuration of the user running the code.

You can then simply use the information from the Test::Database::Handle object:

    # $handle is a Test::Database::Handle object

    # get all the info you need and DIY
    my ( $dsn, $user, $pass ) = $handle->connection_info();
    my $dbh = DBI->connect( $dsn, $user, $pass );

    # be lazy and let it do the DBI->connect( $dsn, $user, $pass ) for you
    my $dbh = $handle->dbh();

So once you've added support for MySQL to your module (in addition to SQLite), you can simply edit the test script like so:

    my @handles = Test::Database->handles( 'SQLite', 'mysql' );

And your test suite will pick up a MySQL handle wherever there's one available.

Many thanks to SUKRIA, who'll be the first CPAN author to really use Test::Database to test a CPAN module (namely, Coat::Persistent, when the latest release finally hits CPAN).

Sunday September 13, 2009
05:53 PM

My favorite Perl logo

TIMTOPL - There is more than one Perl logo (BAOTATM - But All Of Them Are Trade Marked):

My favorite Perl logo, by far, is the onion. When it appeared, I found it the perfect logo: simple, recognizable, easy to include and modify. It was quickly adopted by the community (I remember seeing T-shirts with the logo very early on).

In his 2nd state of the Onion, Larry said:

If you cut an onion, it looks like this. If we take this to be a picture of the world of Perl, then I must be that little bit of onion inside. Around me are some of the early adopters of Perl, who are now revered as heroes of the revolution. As more people have joined the movement, new layers have been added.

When I saw the onion logo, this image sprung to my mind. Maybe the Onion is the symbol of the Perl Community, rather than of Perl itself.

Thursday September 10, 2009
08:26 AM

A reason to like the Perl 6 logo

It seems that some people don't like the new Perl 6 logo (Camelia)

Do you remember the time when the worst thing people said about Perl was "it's vaporware"? The people working on Perl 6 had a hard time failing to convince them of the contrary, no matter how many commits happened, how many tests were passing, how many implementations were in the works.

Today, it seems the worst thing people can say about Perl 6 matches /the logo is (gay|feminine|childish)/. To me, this looks like the easiest kind of critique to discard.

As for those who think that the camel is more manly than a colorful butterly, maybe they should remember that the Camel is named Amelia.

And by the way, it seems to have made people forget the "vaporware" argument. Even if you don't like how the new logo looks, you can still love it for that.

This was supposed to be my first post for the Ironman Perl blogging contest. I resolved to post every Monday... Late before even starting! :-(

Sunday August 09, 2009
09:35 AM

White Camel

This year at OSCON, I received a White Camel award. Since I didn't attend OSCON, my good friends Liz and Wendy arranged a little ceremony at the end of YAPC::Europe 2009 where David Adler gave me a big box containing a "Schrödinger White Camel".

Even though I knew about the award and was warned about the ceremony, my little thank-you talk didn't come out so well: I was too moved to make sense.

Here's what I wanted to say:

I'm deeply honoured and extremely proud of receiving this award.

First I would like to thank the people who decided I was worthy of it.

And I would like to add that I'm actually driven by example: in this room I see plenty of people who organize Perl workshops and conferences all over the world, that run mongers groups and technical meetings... All these people are setting the example I followed in my work with the French Perl Mongers and the YAPC Europe Foundation.

So, thank you very much to all of you, for setting such a good example to follow.

Thanks to everyone involved, and thanks a lot to the Perl community for being what it is: a large group of friendly people achieving wonderful things, both technical and non-technical.

Sunday January 04, 2009
09:04 AM

/me ♥ git

I just uploaded Git::FastExport 0.07 on CPAN. I think I've reached a stable point in the stitching algorithm, where I'm confident that the results of stitching any number of git repositories together will be consistent. I'll probably do a presentation about it at the next Amsterdam.pm and Lyon.pm technical meetings.

To celebrate, I also setup a web server with my public git repositories. Clone away! Over time, I'll move most of my older CVS/Subversion repositories to git.

By the way, I love git because:

  • git add -i (lets one pick up hunks to add or not, and even edit them!)
  • it gives me full control over the history
  • it makes it very easy to share code
  • it makes it very easy to contribute code
  • it makes me code faster
Friday January 02, 2009
12:05 PM

An iCalendar for all Perl events

Wondering when the next Perl event is? Wouldn't it be nice if the information was automatically available in your calendar?

Cry no more, for I have setup an iCalendar file holding all the Perl events (conferences, workshops, hackathons) for which I have enough date information. Simply subscribe to all Perl events worldwide using your favorite calendar tool. This calendar is hosted by the YAPC Europe Foundation.

If some data is missing or incomplete, please let me know, preferably by sending me a patch against the source YAML file (this is the best way to ensure fast updates).