Category — work

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.

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?

Sorry, I’m not actually dead… I’ve actually been posting loads recently, just not here. I’ve been concentrating on my photography blog for a while. New camera and not working much over Christmas, kinda lead me to work on my photography a little more. Anyway, I’ll be back with some Perl love soon I’m sure!

So you want to write a funky new model for Catalyst you say. Well the easy way to start would be to use the helper script to create a nice new model and start adding functionality. Woah there! One minute. If you continue down this route then a year down the line when it’s time to reimplement your site you are stuck with Catalyst. Or what if you need to write another app that uses your model.

So how do we get round this? We write a standard Perl module. Forget Catalyst for the time being, and of course write it like it’s meant for CPAN. Develop your module and use a test suite to test it as you go. No point waiting for Catalyst to restart every time you want to test a change and get the advantage that your tests will still hold true when you come back to this code in 6 months.

Eventually you will get to the point when your module is ready to be plugged into Catalyst. Now it’s time to create a model. Run the helper script as you would normally to do this. Now comes the interesting part…. As Catalyst instantiates all the models at initialisation time we still need to initialise our module so we use the COMPONENT method. We create a COMPONENT method within our model that initialises an instance of the module we created.

Something like:

use MyModule;
sub COMPONENT {
    my ($self, $c, @config) = @_;
    return MyModule->new(@config);
}

So now we have an instance of our model to work with. The config can be set from the Catalyst config by setting

$c->config->{'Model'}->{'MyModule'} = [<SOME CONFIG>];

The COMPONENT method is called when the Catalyst app is initialised and so it’s only called once per instance. If you want to initialise your module on a per request basis add a retrieve method to return a new instance of your module.

Much of this will be obvious to most people, it is to me, yet still I hadn’t (and still haven’t for some) actually done it for all the sites I currently manage.

Today I had the misfortune to end up using a slower than slow internet connection and discovered that a good chunk of the Internet becomes practically unusable at those slow speeds. So I took a look at some of the pages we had loading. The HTML content itself wasn’t too bad only a few kilobytes so I took to the YSlow plug-in for Firefox. This nifty little piece of kit will show you all kinds of information relating to how quickly your site loads and what optimisations you can make.

I was horrified to discover that the total size of some of our sites was nearly a megabyte so I started reading. Maybe half an hour or so later the home page of the site in question was down to less than 100k with all the images, CSS, JavaScript, flash and html. Most of this was achieved by minimising the JavaScript and by enabling mod_deflate in Apache.

Much improved already but I still didn’t really want our users to have to wait for 100k to download every time they visited the home page, so caching was in order. Adding expires headers to the content in Apache achieves this, but with the addition of ETags you can override the cached content when it is updated. Always good when I make a change to CSS that the users actually see it! Happily for static content Apache automatically provides ETags based on the modification time of the content.

As can be seen in the screen grab above, with the caching you can certainly get a large difference in the amount you need to download. I was happy enough with the result, until I got back to my usual Internet connection and loaded the page. Wow! So I thought it was annoyingly slow on the previous connection, well on the faster connection it was practically instant and that makes these improvements a must in my mind! Not to mention the obvious benefits to the bandwidth charges.

I’m not actually dead. I’ve not posted in a millena for a number of reasons:

1. Incredibly busy getting the latest Manchester Entertainments Site finished at work. (Look at that keyword rich link )
2. My charger for my camera batteries has died. I actually bought a replacement, but that turned out to be completely fake!
3. I’ve been moving to a new server, the setting up of which takes time!
4. I’ve been preparing for a baby!
5. I’m lazy!

Anyway I’ve been promoted to a “team leader” at work. I’m running the team that looks after the news sites, including the MEN. I’ve not got anything else exciting to say, but I just thought I’d make sure I am still alive.

    Awesome!

Another impressive message from our favourite content management system at work!

What a week! New job is going really well so far, and I’m actually looing forward to going to work on Monday morning! Had a busy weekend as usual. Got a couple of good photos from Lyme Park today, and Etherow yesterday. Oh yeah also got some more of the garden too.

Right too much to do… byeee!

I’m starting my new job with the Guardian Media Group in 10 hours. I’m very excited about it. As far as I’m aware I’ll be working with the Catalyst Framework which is  an MVC framework for Perl. I’ve been rewriting the Scout Group site using. It seems really really good, and exceptionally fast.

Anyway, I’m sure I’ll know more tomorrow.

Night Night…