Category — perl

Sensationalist title I know but I work, at least for the minute, for a newspaper company that’s just been bought out. Now I’m fairly sure that our new corporate overlords will have no requirement for two web development departments. Meaning at least one of us is for the chop and they are the larger company buying the smaller one, so centralising to their own resources seems likely to be the way they’ll go.

We have a strong development team here, with a great work ethic, who all love working with modern (enlightened) Perl. However only a cursory look at the Jobs market around our location shows us that there aren’t very many openings for experienced Perl developers. Sure there are some around London, but outside of the big bad city there seems to be very few and for most of us relocating simply isn’t an option due to family commitments.

So being that we’re all competent developers switching to a different language isn’t a massive issue to us from a technical point of view but we’ve given some of the best years of our lives to Perl and the community surrounding it. Abandoning it, even only on a professional level, seems like it’s almost more gut-wrenching than the likely ensuing redundancies.

So is this the death of Perl for me/us? Perhaps and it’s gutting.

Welcome to Mark, soon to be blogging on per.ly. Mark currently works primarily in PHP, but is slowly learning to love the Perl. Hopefully he’ll get to converting his site to Catalyst soon!

On another note, thanks to everyone who showed up for the NWE.pm tech meet last night. I thougt it went well.

Just a quick one to welcome mdk to per.ly and shout about the NWE.pm meet that we hosted at work. Anyway it was great and Mark has posted a full write-up.

I promise to post something more fulfilling soon, honest.

The next Northwest England Perl Mongers meet is going to be a technical meet on 1st July. Everyone attending is invited to deliver a lightning talk relating to anything you think we’ll be interested in. Lightning talks should be about 5 minutes long.

We will be meeting at MEN Media’s headquarters on Deansgate in Manchester but the powers that be would like an attendees list before hand so please drop a line on the mailing list or let us know in #northwestengland.pm on irc.perl.org.

Oh yeah, and we need to think of a talk subject for Matt Trout to talk about, as he volunteered to talk about a subject of our choosing.

So it appears there are some drawbacks in WordPress Mu. Mainly that there is a complete lack of a decent content aggregation plugin for it. Well that’s no problem, I’ll just write one…. wait just one minute. Perhaps the reason that their isn’t one already is because Mu is basically a giant hack!

There is an ugly bit of PHP that basically sets the current blog and then everything works, however changing the current blog breaks pretty much everything. Also Mu creates a set of tables for every blog, so all the posts are in different tables. Thus making writing a nice clean Mu plugin to aggregate the posts an impossibility.

So Perl it is then. A quick script to union the tables, TT the data and then print the output. Add a bit of caching and hey presto, done in less than an hour.

Still could use a bit of tidying up in the templates but other than that it’s all good. Anyway it’s running the per.ly homepage now. Also if anyone wants a per.ly blog, to post about anything related to Perl leave a comment.

Recently I was reading an article from the good folks at Perl Training Australia about the 5.10 Smart Match functionality. I was particularly interested in the fact that they referred to the speed of the Smart Match being “extremely fast”, so I decided to hack together a quick script to see what potential speed gains we were looking at.

I focused my investigation on comparing two arrays and using Benchmark to see how much quicker using the Smart Match would be.

I created two quick routines to compare the arrays:

sub smart_compare {
    return 1 if(\@a ~~ \@b);
}

sub foreach_compare {
        return 0 if(@a != @b); #Scalar compare to check lengths.
        my $i = 0;

        foreach (@a) {
                return 0 if($a[$i] != $b[$i]);
                ++$i;
        }

        return 1;
}

The smart match comparison being much more concise and the foreach_compare not having an particular optimisations, but both being fairly trivial.

So I chose four simple test cases for comparing the arrays:-

• Matching arrays (1,2,3,4,5,6) == (1,2,3,4,5,6)
• Last value different (1,2,3,4,5,6) == (1,2,3,4,5,5)
• First value different (1,2,3,4,5,6) == (5,2,3,4,5,6)
• Number of items in arrays different (1,2,3,4,5,6) = (1,2,3,4,5,6,7)

I was expecting the Smart Match to be quicker, although not by too much in all of the cases. It turns out that the Smart Match was slower in all but one case (Over a million iterations).

• Matching arrays (Smart Compare: 21 Seconds Foreach Loop: 7 Seconds)
• Last value different  (Smart Compare: 20 Seconds Foreach Loop: 6 Seconds)
• First value different  (Smart Compare: 5 Seconds Foreach Loop: 3 Seconds)
• Number of items in arrays different  (Smart Compare: 1 Second Foreach Loop: 1 Second)

When the number of items in the array is different the Smart Match and Foreach loop perform pretty much evenly across repeated tests.

All the tests were ran on Perl 5.10.0, installed from Source on a P4 with 2 Gig of ram. Whilst these findings show the smart match to be slower when comparing arrays, this is of course only a simple test case and other types of comparisons offered by the Smart Match should obviously be investigated too.

The test script is available for download if anyone wants to give it a go on their system (or find any mistakes).

I completely forgot to blog about the Northwest PM meet last week. Perhaps the Perl scene in Manchester isn’t as lacking as we initially thought. Although there were only a few of us actually from Manchester.

Three interesting talks were given:

• Object oriented database design in PostgreSQL (Matt S Trout)
• Converting 16k user mailboxes from MBOX to MDIR++ (Ian Norton)
• Functional Pe(a)rls v3 (Osfameron)

All the talks were fairly good and I’d recommend any other Perl devs (or even potential ones) show their faces. We’re friendlier than we look… honest

The next meet is a social, again in Manchester.

One of the fine gentlemen I work with recently blogged about how he started out with Perl and it got me thinking about why Perl currently seems to be failing to drive the interest it so rightfully deserves.

Perhaps by thinking about how developers select a language we are more likely to understand why Perl doesn’t get the numbers. I personally can’t even remember how I started out on Perl, it was that long ago. I suspect it was because PHP wasn’t even around, and it was the most obvious choice for a dynamic site, or more likely page at the time.

So what are we doing to attract new developers to the wondrous Perl? CPAN offers a great resource for developers who already work with Perl, but what is there for developers new to Perl? Or more importantly what is there to actually entice them to Perl. Every virtual corner you turn someone is mentioning PHP or Ruby on Rails, but Perl seems to be less “down with the kids”.

Let me be the first to admit, I certainly don’t have the answers, but perhaps by looking at how we got the Perl bug, we can come up with some ideas how to hook in more users.

Recently on the Catalyst mailing list was a thread about the press release detailing the latest 5.8 version and discussions turned to the “outlandish claims” that PHP and Ruby evangelists make. But I find my self wondering do we do enough to actually proclaim the things that Perl does well?

Now I realise I’m ranting, but it’s entirely possible that I’ll need to be looking for a new job in the near future and I’m not entirely convinced I’ll be able to get one working with Perl. I’d love to be able to blame this on someone, but to be honest it’s entirely our own fault. As Perl developers we simply aren’t doing enough!

Test::Aggregate is a simple, yet fantastic module that allows, you guessed it, tests to be aggregated. This turns out to be a true god send when testing large Catalyst apps.

Previously in order to run all the tests against an app I would generally have ran a stand alone server in one terminal, and then ran the tests against that stand alone instance in another, something along the lines of:

term1#> perl script/myapp_server.pl

term2#> CATALYST_SERVER="http://localhost:3000" prove -Ilib t

Of course simply running prove t would run all the tests, but with the time taken to initialise the Catalyst instance being added to the start of each test, this could be hugely time consuming.

Using Test::Aggregate a very simple script can be knocked up that will run all your tests, and only actually create a single Catalyst instance.

    use Test::Aggregate;

    my $tests = Test::Aggregate->new( {
        dirs => 'myapp/t',
    } );
    $tests->run;

This will load all your tests, each into their own unique package space. Meaning that only a single Perl instance is required to run all the tests and that all the required modules will only be loaded once. Both the overhead in running the entire test suite and the execution time will be drastically reduced.

Problems can occur if you are using global variables, in that they may be overwitten by the tests as they run, but of course you aren’t using them anyway… are you?

Saw a message on the Catalyst mailing list about catalyzed.org, a new blog aimed at helping the public image of modern Perl. In their first post/article they happened to mention Matt’s Script Archive. So I thought I’d take a look at the old favorite.

Even back in it’s early days I thought the code that was on there was less clean than it could be, and not particuarly maintainable, but still thousands of users were running variants of the code. So why did Matt’s Archive dominate the Perl world so much? Simply because there was very little competition. Perl was one of very few mature scripting languages suitable for the job and Matt created a collection of tools all in one place that “did the job”.

So can we consider CPAN to be the modern day Matt’s Archive? It’s where we go for scripts, or more likely modules (to “do the job”). Thankfully CPAN is publicly maintained, and if you don’t like the way a module works you have a number of options from submitting a patch to creating your own version.

Whilst there are quite a few unmaintained modules on CPAN, there are a great number of current technical resources, developed in an extensible way that can be used for any number of tasks. It can certainly be said that most, every-day, functionality is exceptionally maintained. Often even older, unmaintained modules offer a starting point for development if you can’t find something current.