Category — perl

This is something that rears it’s ugly head from time to time, the need to create stand alone scripts that I can give to a none programmer to run on a Windows box. The last time I played with this, it was to create a version of the get_iplayer script for my dad to run. This time it was to run some network diagnostics scripts we’d hacked together on a machine we had no access to.

The machine we needed to run it on was a fairly well locked down ‘doze box, so installing Perl was unlikely to happen. The last time I used a nice little app called linux2perl. It worked fairly well, but the free version had a 2 second delay and a splash message on the start of the app.

So I decided to take a look at the Perl Archiving Toolkit (PAR). The PAR toolkit actually generates intermediate shippable packages, that are actually zip files with all the required modules included to run a script. So a PAR script can be packaged up and shipped to any user with perl and it’ll run regardless of architecture (almost… think XS), or installed modules.

To my delight, creating an executable was nice and simple:

pp -o outfile.exe infile.pl

PP is the PAR Packager, which is  nice little utility to convert the PAR files to executables for the current OS. Or as the CPAN page puts it “You may think of pp as perlcc that works without hassle.”

You’ll still need a windows box to build the binaries, but once they’re built they are completely shippable and can be sent to other boxes. Although they do end up being rather large, my simple script was a little under 4 Meg, leading me to wonder if more than just the libraries I used were packaged up too.

Either way it worked perfectly, I even repackaged the get_iplayer script for the old man.

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.

RSS Feeds are inherently repeated patterns over and over again with a bit of text in the middle for a link and some content. So what’s the best way to generate one. I’ve debated this to my self now for a few days and can’t really come up with a strong enough argument to sway me one way or the other.

As I see it there are three realisting posibilities. These are….

1. Generate the feed using print/sprintf statements. This has the advantage of being quick, having very little memory footprint and requiring less processing power. The major draw back is that the XML isn’t validated. Another drawback is that it won’t be the prettiest solution.
2. Use a templating system. If you pick the right templating system this could be quite fast, with HTML::Templates caching for example this could be done fairly quickly and fairly painlessly. Again the big disadvantage is that the XML isn’t parsed and validated.
3. Use an XML module such as XML::Simple or XML::Feed. XML::Feed you say, that sounds like it’s designed to do just the job. Well yes it is, but it aslo uses a full DOM to build up the feed, as would XML::Simple so it’s comparitively slow compared to the first two methods. The major advantage being that it would pretty much always generate validatable XML.

So with the first two sollutions we could generate the output and then validate it with an XML Parser to check it, but surely that takes away the major benifits of either sollution. If we use the templated sollution, so long as we ensure that the content within the template variables is XML friendly and in CDATA tags etc, surely we can guarantee that the XML output should be fine.

So do we go with a less elegant, more speedy sollution or a more elegant less speedy sollution. Of course we could cache the output of the more elegant sollution if the feed data wasn’t changing too often, making the argument a no brainer, but what if the data changes every few seconds…. I just can’t make up my mind.

POSIX is a Perl module that gives you access to the IEEE 1003.1 standard functions. It’s all implemented in C and so it’s nice and fast. Installed virtually everywhere and provided by the system.

All in all it’s lovely for it’s thing, until I saw this blog post. Obviously this is a Ruby problem, well oops no as I said POSIX provides some nice functionality including functions for rounding floating point numbers. So in essence both Ruby and Perl are using the same system calls to do the rounding.

So I fired up a console and tried the following:

> perl -MPOSIX -e 'print ceil(69.54 * 100), "\n"; '
> 6955

Sorry… you what???? 69.54 x 100 = 6954, so ceil(6954) = 6955…. I think not. So ceil(6954) is not equal to ceil(69.54 * 100). Try it on your OS and see what happens.

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.

As the title suggests, the top ten things that only Perl does. I reckon I’d change this list on a pretty much daily basis, but here goes:

1. $| = 1; Lovely little nuances like this make it so interesting. For anyone interested, who doesn’t already know this stops the screen buffer from writing out only on a new line (or when it’s full) and printing out one character as a time. Useful for those … status updates I’m fond of.
2. $z =$a ? $c : $d; Ternary operators, lovely pieces of code although I have pretty much ceased using them recently in favour of more readable code. This example evaluates to if($a) {$z = $c} else {$z = $d};
3. CPAN CPAN stands for Comprehensive Perl Archive Network. It’s the first stop for Perl functionality. If you need to write something, you can pretty much guarantee that someone already has. Check out CPAN and see what’s available. As it’s all open source everything on it has the advantage of being reviewed by the community at large.
4. Test::More Test::More is a fairly basic testing module that can do various things. It plugs in nicely with the Prove utility to provide the essentials for testing your code.
5. DBIx::Class I have to admit, when I first started using DBIC I wasn’t the biggest of fans. In my opinion it still doesn’t generate particularly nice SQL, however it does make development a breeze. Define your tables, define your relationships and let it do all the work for you. Just remember to make sure you write plenty of tests to make sure you don’t get bitten by any unexpected behaviour!
6. Portability Perl interpreters exist for pretty much any OS you can think of. With only a hand full of exceptions, practically any code can be written and run on any architecture you choose!
7. Mod Perl Mod Perl was the best thing ever for a web developer. I mean I could just load all the code into memory with Apache. Pool my DB connections etc etc and watch the systems simply fly. Having said that it’s only on the list because I had such a love for it. New and improved lovelies have come along now…..
8. Fast CGI Fast CGI is even better than Mod Perl! That takes some doing, but being as I primarily work on large Catalyst apps it wins hands down for one simple reason. I can restart the app without having to restart the whole web server and hence all the other apps. The Catalyst apps we use at work take about 5 mins to restart with Mod Perl, with Fast CGI it’s about 30 seconds. Fast CGI also offers all the benefits of Mod Perl that I use and probably some more.
9. Template Toolkit TT is my current templating system of choice. It’s been my primary choice for a few years now having used a few of the alternatives in years gone by. Having said that, I’m told that Mason has come on a long way in recent years and intend to do more investigation at some point!
10. TMTOWTDI There’s more than one way to do it…. It’s been a sort of motto of Perl for years and it’s as true today as it was the day it was first coined. Ask any group of Perl developers for a function to do pretty much anything and you are likely to get wildly different results. This variance and artistry of code means that there is always a faster/more readable/smaller/lower complexity/more poetic way of doing anything in Perl. That makes it an art in its own right!

That’s it! They aren’t in any particular order and probably not that definitive. I’m sure I’ll think of something I missed as soon as I hit submit.