I have a few perls compiled and installed in
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 \_
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
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.
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:
We use Mailman for managing our mailing-lists. It works well enough for us, but it has its share of hate:
Luckily, it also has a few helpful headers:
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:
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:
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.
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.
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.
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.
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.
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
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!
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.
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:
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).