As it happens though I did finally make it to a NWE.pm meet this month where we planned some of the stuff for the hack day.

The plan, ambitious as it may be for a day, is to work up something similar to Heroku but for Perl apps obviously. I hope to be able to take over some of the good things I’ve learnt from the RoR community and use them on this project.

On another not, it appears that the per.ly homepage has stopped aggregating the blog posts. I’ll get that sorted!

KTHXBYE

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.

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

I promise to post something more fulfilling soon, honest.

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.

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.

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

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.

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!

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?