use Perl

Google Sites has been released. It allows you very easily to create web pages, and of course they come out looking pretty stylish.

For me, a web-luddite, this is great. I had some horrific gawdy old thing before, which was an embarrassment preserved for eternity via the Internet Web Archive. I just cut and pasted the content into my new Google Site - a few minutes' work and I have a new homepage :-)

The system is very much designed for collaborative work; I suppose it's a version of Google Page Creator with support for hierarchical structure and so on. You can edit in WYSIWYG or HTML mode, and easily import HTML from other pages. Perhaps this is a challenger to having a wiki for a Perl project?

In related news, I'm back to using Firefox for browsing under OS X (from OmniWeb, and Shiira). FF is plenty fast enough, and I just couldn't live without the awesome extension system - particularly del.icio.us, Firefox Showcase, It's All Text!, SwitchProxy, and Tab Mix Plus.

I recently had a few spare tuits and ran out of books to read, so the Moose object system popped to the top of my stack.

Like many new and cool projects, features are accellerating away from documentation, and often what a new starter wants is a low-down, which isn't there (yet). Catalyst and DBIx::Class were each like this at one point in time.

To help myself and others I have created a PDF Moose Quick-Ref Card with most of the functions and syntactic sugar consructs of the system.

Thanks go to folks in the #moose IRC channel, and the Programming With Moose WikiBook written by EvanCarroll. The ref card will work best if you can print it 2-up on one A4 sheet, cut that in half, then laminate the two A5 parts back-to-back.

Comments and suggestions for the ref-card will be gratefully received :-)

On the Mac (of which I have two, so you could say I'm a regular and keen user), I don't bother with Safari but instead use OmniWeb, a non-free third party browser. It's packed with features to help juggle dozens of open pages at a time, and other things besides, so is a good power alternative to Safari.

OmniWeb is generally very stable (or at least has got a lot better in recent months), although painfully slow to start. That's its most brain-dead feature (a side effect of the workspaces feature). What I really do like is the easy management of popup and cookie preferences per page/window/site, and the tab thumbnails.

It looks like there may be a new contender for OmniWeb's title as the power browser for mac - Shiira. This is based on the Apple Web Kit so is basically like Safari 3 inside, but with added bells and whisles. This one's Free and free, and with the recent release of version 2, looks like something to keep an eye on. I'm submitting this post from Shiira.

I was pottering around Wikipedia as you do, and stumbled across a link to an interview with a Twitter (social network website) dev. I'm pragmatic about programming language choices, but I do hate hype. Here's the URL and a juicy quote which seems to cut through some of that:

Interview with Twitter Developer Alex Payne

"By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.

"The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.

"None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

"It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow."

A very nice new toy recently landed on my desk at work, an Apple MacBook. It's my first Mac and I'm very impressed so far. One of the things I want to use it for is hacking Perl whilst on the move.

To get a # sign on the MacBook keyboard you use the Option (or Alt) key + 3. This seems terribly klunky to me, and # is of course used quite a bit in Perl. The other problem is that you might have the Alt key mapped to something else in a Terminal application.

This hack remaps another key on the keyboard to produce the # character. I chose the funny squiggle that's to the left of the number 1 key (§). This is the Section sign, used in document formatting. Just create a file at ~/Library/KeyBindings/DefaultKeyBinding.dict that contains the following:

{
    /* this will make all § turn into # */
    "\UA7" = ("insertText:", "#");
}

Any app that uses Apple's Cocoa interface widgets for text input will pick this up after being restarted. There are some that don't (perhaps TextMate? Not checked that one so if you know, please comment).

A lot more information about this is available at this excellent page on the Cocoa Text System, including some other neat hacks. Enjoy!

I'm quite surprised that I made it to the London Perl Workshop after quite a heavy night out with some friends in Oxford. Well, I did feel like death warmed up for most of the day, but still managed to enjoy the sessions through the hangover. I think that's praise!

Mostly I was in the Advanced track, and it was a delightful mix of the real-world and abstract, relevant and irreverent, scary and familiar :-) Jonathan Worthington made a fine start to the day with an excellent overview of some OO goodies in Perl 6. My day-job keeps me pretty busy with Perl 5 so I've not had a whiff of v6 pass my nose yet, and this was a superb talk at just the right level for me, with a nice dash of humour to boot. Next up was Dave Hodgkinson with some mod_perl scaling tips and tricks, so by this time I was in little puppy heaven! He brought some real honesty to the presentation which was very welcome and the chit-chat in the room after his short talk only added to the benefit.

The next two in the track, benchmarking gotchas by Abigail and Perl 5.10 regex by demerphq were equally good. I liked that Abigail made each slide a wee puzzle that made the audience race to find the logic error hidden within. Sorry to hear that Tom from miltonkeynes.pm couldn't make it to speak; hope he's feeling better now. demerphq and his clan clearly have some industrial scale cojones to tackle the regex code, but the results look impressive, especially exciting for us that run large Spamassassin installations. He also did all the work on his own time, full-time, courtesy of his previous redundancy package, so we owe our thanks for that generosity.

Jesse Vincent spoke after lunch about some scary code in the products of Best Practical. No real surprise there, as I've seen what RT does to a database, and it ain't pretty (DBIx::SearchBuilder, ugh!). Didn't really inspire me to install any other BP software, to be honest, after seeing his perversions (impressive and fun though they were) of Perl bugs. Finally I went to Alistair McGlinchy's "lightning" talk on network bandwidth. Interesting if not educating for me, listening to him describe his day-to-day job was quite entertaining. I then made a sharp exit for the next train home, reckoning I couldn't last a night out with London.pm on so little sleep, and I'd seen Jos Boumans's (excellent) talk before at YAPC::EU::2006, anyway.

In other Perlish news this week, I finally found the time to check out DBIx::Class. About a year and a half ago, whilst I was busily developing work's wireless guest service (think coffee-shop style thing), I wanted a good ORM to go with Catalyst. Matt Trout pm'd me a snippet of code from this new project he was working on, which looked pretty funky, but was way too raw to put into producton. I settled on Dave Rolsky's Alzabo, which isn't that scary, and has done sterling work since then. Aside: Dave Cross was a fool to miss Alzabo out of his round-up of ORM software when he layed into the topic in 2005.

Well, I came back to Matt's finished baby this week, and it's pretty damned cool. In fact, it's just about the same as Alzabo. By which I mean that if you sat down and thought about what you want an ORM to provide, which Dave R. did and Matt did, you'd not really be able to come up with much else. What differs between them, really, is that Matt's software is very much "of the moment" in terms of style and coding practice whereas Alzabo, even though it's fully OO of course, smells a bit "2004" to be honest. Alzabo isn't crap by any stretch, it's just that I'll be happier coding with DBIx::Class in the future because it better fits the way I happen to write code, and the way the authors of modules I use do as well.

The REST stuff has had to go on the backburner for a while, because I wrote down what needed to be done to start that, and it's a long list!

At work I've been setting up a new PostgreSQL server, and migrating a few of our systems to use DB schema, which has been interesting. For the uninitiated, a schema is a layer between the table and the database that allows logical grouping of tables. You can have one schema per app, say, and allow referential integrity between schema, whereas before you wouldn't have been able to directly refer to relations in another app's database.

I tend to avoid posting in journals when computers are giving me a hard time, and boy, this past weekend, it was just like that! I decided to re-image my MythTV system, for two ends: One was to change from RAID0 to RAID1, and the other was to upgrade Linux distro from FC4 to Ubuntu Edgy.

To be honest, this stuff is always a PITA. Myth is the kind of app that prefers to be run as a black box - once the thing's up and running just don't ever touch it again, and you'll be fine. Try to fiddle here and there, or update the odd package, and you'll be done for. So I should have expected the worst with a massive change like this, you're right. My big problem is that I have this great TV card called a Hauppauge PVR-350. I love it. It does MPEG2 encoding and decoding in hardware, and has the best quality TV-out of any graphics card I've ever seen. Sadly the Linux drivers are nowadays pretty much abandonware, and even the MythTV project has dropped official support. I can agree with their reasons, whilst still being upset, mind. I spent a frustrating day and a half pissing around with kernel modules and parameters, rebooting, and generally turning the air blue, before calling time on the card after three happy years.

Luckily for me, work had just upgraded my workstation graphics card and I had an Nvidia Geforce4 MX4000 sitting in the drawer. It's passively cooled, making it excellent for this application, and of course the binary drivers are nice and stable. It also has the TV-out I need to replace the Hauppauge card. I can report an immediate and noticeable loss in TV picture quality, but digital terrestrial is good enough to reveal that I suppose. The picture is just a little grainy, and washed out, but it's still leagues better than analogue. Having said that, SWMBO tends not to notice when Myth chooses to record from analogue rather than digital anyway, so we're hardly quality snobs!

Apart from that headache, the system's running like a dream under Edgy, and in fact I've implemented a few nice hacks that weren't in the old FC4 setup. I also use that box as a general GNU/Linux hacking system, so the wonderful, and beer-free, NX Server got installed. I can highly recommend it if you need remote desktop on a Linux box, but have (or want) SSH as your only means of remote access. Being a Kerberos fanboy, the system also gets setup to authenticate to the OX.AC.UK realm, so remote access into work becomes straightforward.

One last thing before I sign off. I'm looking forward to the London Perl Workshop tomorrow. I didn't manage to arrange to go in time for the last one, and it looks to be a nice lineup this year. I'll also bump into some new friends from MiltonKeynes.pm, and some old friends from London, I hope, making it a nice day out. See you there, maybe!

Let's talk a little more about RPC, and YAML::RPC. A lot has changed in my mind in the past few days (slow bus journeys this week, meaning I have time to really mull things over).

YAML::RPC is cool, as I said before, but there are a couple of things about it that annoy me. One of them is that each handler must be registered in the server's config. This means you have one file with your actual handler sub definitions, and another with their names (or mapped names), and this tends to cause me to make mistakes.

The other problem with YAML::RPC is that it's, well, YAML, and whilst I love YAML for its simplicity, readability and syntactic brevity, it's also prone to nasty bugs. For example, YAML represents the undefined value with a tilda (~), but in some circles this symbol can mean a user's home directory. If you don't take good care of your quoting, then in serializing and deserializing data you can turn a filesystem path into an undefined value. There are a few more examples involving the well-known whitespace issues, meaning that oftentimes you'll end up having to base64 encode data before serializing into YAML. This effort kind of undoes all the goodness brought about by YAML's syntax, don't you think?

So what I really want is an RPC system that avoids these two annoyances, and is a little more flexible than YAML::RPC in its dispatching mechanism, which is just a dumb call the sub thing. Okay, so I'll rewrite YAML::RPC to be Data::Serializer::RPC, and then we can use any data format, and get encryption/compression too if we want. I still need a flexible dispatcher and handler registration mechanism, and I want to have more options than just ucspi-tcp or other STDIN/STDOUT wrappers for network connectivity.

Seeing as the client-side of this will be a Catalyst model, it did strike me that Catalyst already has a lot of what I want... the flexible dispatcher, plugins (oh, yes, I was going to make it all pluggable using NEXT or Class:C3 because I like things like that), and network connectivity for free.

Hmm, why not just subvert Catalyst into an RPC system instead?

Around this time I happened to pop back onto #catalyst to ask about their plugin system, and got chatting with the nice folks there, and explained my plans. Matt Trout, who is a fountain of ideas, piped up with "You should look at XMLRPC, or REST." No way was I going to touch XMLRPC; I get a rash every time I use XML. But this REST thing rang a bell, and so I went googling and reminded myself what it was all about.

Okay, so REST is basically just what the web is already doing, but as well as GET and POST for web pages, you use DELETE, PUT, etc (as with WebDAV) and call the things you get "resources". The body of the HTTP response, as we know from things like SOAP w/HTTP can be any old data. It could even be YAML! So rather than use YAML::RPC, which has its own calling syntax, use HTTP and GET a resource, or PUT one. The Wikipedia REST page does a reasonable job of explaining how REST methods can map to CRUD methods.

The final nail in the coffin for my YAML::RPC project was that some bright spark has already written the necessary frobnits to make Catalyst into a REST server, and they even use Data::Serializer in the transport. That's enough for the backend, so all I need to do is write a REST Model that acts as a client; this is simple and just uses standard Perl LWP. Hopefully that should sneak its way out to the CPAN before too long; I've just had a reply from my director giving open source release on the code, which I'm pleased about.

I've worked on three or four things over the last few days, most of which were nice to get out of the way, because it's what's on the horizon that I'm finding more interesting!

I pushed a new release of Net::Appliance::Session and didn't hear much back about it, which was a little dissappointing to be honest. Earlier releases brought up five or six emails from around the world, with feature requests which were honoured in this release, so I'm anxious to hear what they think. I do now have a small group of users of the module though, which is more than I was ever expecting to know about, and I'm absolutely chuffed to bits with that.

The Net::MAC module is shaping up to be something really cool. Earlier in the year I sent Karl, the author, a small patch bomb which he kindly incorporated, and over the weekend he got another which nukes two more items on his TODO list. I've not heard back, but fingers crossed they'll make the next release. I'd urge you to wait until 1.2 is released, as it's got tons more features than the version that's on CPAN right now. If you look at NetAddr::IP and Net::Netmask, then Net::MAC is on its way to joining those two in my network hacker's Perl toolkit.

With those two things out of the way, my attention turns to YAML::RPC. This is a complete module which is as-yet unreleased, and I'm hoping to get my employer's permission to do that before long. Another time, I'll talk about their open source policy, which is a very cool thing to have, IMO. Anyway, YAML::RPC is also very cool, as it's a full RPC mechanism with a low overhead and human-readable (and writeable!) data stream. This makes testing a breeze! We hook it into something like ucspi-tcp and immediately your MVC Model layer becomes a paper-thin RPC client and your business logic or DB work is nicely (and safely) abstracted away from your webserver.

Right now, however, I'm just reviewing my slides for tomorrow's session of the Introduction to Perl course that I teach for my employer. It's great fun, although massively stressful, because I've taken the course over from Stephen Quinney, and previously Simon Cozens, so there's a lot to live up to! I've made some heavy changes to the format though, and I think they're working out well. Perhaps more on this next week when the course is over.

Welcome, dear reader. Like many folks who keep an on-line journal, I eventally decided to split off my geeky alter-ego from the traditional blog. So now I have this page here, for all that's techy in my life, and another page with stories about cats, gardening, friends, and SWMBO.

Let me introduce myself. My job title is "Senior Network Development and Support Officer", and I work for the University of Oxford. In plain English, it means that I co-admin a lot of Cisco kit, some DNS/DHCP/SMTP/RADIUS/etc servers, and write a ton of Perl, along with my colleagues Robin and Andy. I guess my two geeky loves are IP networks, and Perl ;-)

As we all know, it's Perl that glues the Cisco/DNS/etc bits together, and that's what I want to write about here. I hope the things I do will prove interesting, and from time to time I'll throw in something from home (MythTV being an example).

Oh, in case you didn't read my bio, my PAUSE ID is OLIVER,and the module I'm most proud of right now is Net::Appliance::Session .