We now need to organise a combined housewarming/engagement party...

Agile processes harness change for the customer's competitive advantage.

After two and a half years at Smoothwall, I'm moving on - Friday is my last day. Since I joined the development team, we have adopted Agile development, set up a pretty nifty Gerrit/Jenkins code review + integration system, and introduced dpkg for package management. Along the way, I helped with a bunch of important features for the business, like a ground-up rewrite of the web filter, and time-based browsing usage quotas.

I will be starting at CV-Library on Monday, for a whole new set of challenges. They're based in Fleet, so I'll have an hour-long commute each way on the train.

I've been assured by an expert in these matters that facilitating wage slavery is a comparatively more ethical pursuit than facilitating internet censorship. :)

To make the commute somewhat more bearable, I'm moving house on Saturday. So far, the packing's going quite well...

I'd love to claim that this was a grand gesture against privacy-invading apps, or a bid to recoup vast amounts of my spare time... but it's not, really. I rarely logged in to the site, these days, so Facebook has very little of my personal data.

Searching online, there were very few results (hence this short note) - just previous unrelated Linux kernel issues. I found someone with the same problem on Fedora, but no solution, so I started off by filing a bug report with Debian.

Of course, then I found the Arch user who had filed the same bug on Launchpad, and had discovered that resetting the BIOS to its default settings fixes the issue. If only that page mentioned the keywords "Ericsson", or "Lenovo"...

So after all that, it was just some weird BIOS issue. I hate hardware.

I couldn't figure out how such a dramatic reversal could have happened, until I asked Mithaldu on IRC; the admins of the old Leeds tutorial have added a (delayed) redirect. So, Google has interpreted that as a 302 status, and given perl-tutorial.org all the old inbound links, presumably.

Perhaps there is hope for Perl yet. :)

Last year, a bit of a fuss was kicked up in the Perl community about the low quality of search results for the phrase "Perl tutorial". Various ideas for fixing this were proposed, including the handy Perl tutorial hub, but kicking Leeds University off the coveted top spot is going to be a real challenge.

The problem is, most Perl tutorials on the internet were written for Perl 4; modern Perl doesn't get a look-in. It's a miracle anyone manages to learn Perl at all...

While thinking over this problem, I was reading Mithaldu's original criteria for the "content creation" option. "Community effort"... "github repo"... "exported to HTML regularly"... if only Perl had some central site where you can publish documentation... that all Perl hackers can access and update... like CPAN.

So although my documentation-writing skills are pretty weak, I proudly introduce the Perl-Tutorial CPAN dist and github repository. The great thing about writing Perl documentation using POD is that you can link to other CPAN references so easily - as the basics get filled out, they can guide the user towards how to learn more about each topic. Everyone who's anyone knows how to send a pull request on github, and there seems to be far more of a community feel to CPAN these days.

Version 0.001 is just "Hello, World!" - but watch this space. :)

Next problem: we want to both edit the site. Okay, so I create a group, make it the default group for both users... and now I need to set the umask to 002 so that all group members can edit all files. There's no option in the client...

Skimming Debian bug #496843 (closed Apr 2010, thanks Colin Watson!) we can set this in sshd_config these days - no need to mess about with wrapper scripts. Very easy:

Subsystem sftp /usr/lib/openssh/sftp-server -u 002

Now all content created through the sftp client is group-writable, and owned by the default group of each user! See 'man (8) sftp-server'.

There's just one small catch: they haven't released a server to go with the client. Oops. Apparently the internal systems are too tightly integrated to make that possible.

I have hacked up enough stubs of a BITE server in Perl to get the client to "log in" and show off some features. (Warning: it doesn't actually do anything useful yet.)

So far, I have learnt:

• To get BITE to point at your dev server, you need to edit bite.options.constants.ServerChannelOption in the file src/options/constants.js (as documented on the serverhandlers wiki page) before compiling it.
• To get a bug template to apply to all URLs, you need to use the string 'all' as the URL, which is hardcoded in 'templates.js' in the client.

Or just apply the handy Debian update, of course.