I was told last week that my current contract won't be extended when it finishes at the end of this month.
I'm obviously looking for a new contract, but I'm also investigating another option.
I'm thinking of running some commercial, public Perl courses in London at the end of July. The plan is basically that I'll book a room for a week and run a couple of two-day courses (Learning Perl and Intermediate Perl) and a one-day Advanced Perl course.
It's still far from confirmed, but if you're at all interested in this (or other training courses that I may run in the future) then please sign up to the mailing list in order to be kept up to date with the latest news.
Gabor asked for feedback on his proposed CPANTS metrics. Here is mine.
I don't like them.
Well, I don't like most of them. I'm ambivalent on the Test::NoWarnings one.
It's the Debian ones I really object to. I don't like the Fedora ones that were added recently for the same reason. I don't think they measure Kwalitee (or quality) in any meaningful way.
Don't get me wrong. I think it's important to up package CPAN modules for commonly used packaging tools like rpm. I've done some work in this area myself. I'd really like a system where I can get statistics on which of my modules are being built for popular systems like Fedora and Debian. And getting information about why a particular module isn't being packed (license issues perhaps, or bugs) would also be very useful.
But I don't think this stuff belongs in CPANTS. I don't think it says anything useful about the quality of the module. I don't think that CPAN authors should be forced to care about platforms that they might have no interest in. It would be nice if they did, but I don't think you can penalise them if they don't.
So, for what it's worth, I vote "no" on the new CPANTS metrics. And I'd further like to see the removal of the other Linux distribution based metrics. But I'd really like to see that information made available elsewhere.
Yesterday I sent out 353 mail messages to the PM group leaders using the contact details in the PM master XML document.
Almost instantly, I got 58 bounce messages back. That's an error rate approaching 1 in 6. A sixth of the contact addresses that we are publishing on pm.org are invalid. What kind of an impression does that give to people trying to contact a PM group? And that's after I posted messages a fortnight ago (on use.perl and on Perl Monks) asking leaders to check their contact details.
Oh and I got one reply from a challenge-response system. There's a special circle of hell reserved for people who use challenge-response systems. Especially on email addresses that are published as contact addresses.
If there's anyone reading this who should have received a mail but didn't, can you please contact me at census[at]pm.org so we can fix the problem. You might also check your contact details at http://pm.org/groups/ and email any corrections to support[at]pm.org.
Now I remember why it's been three years since the last census. It takes that long for me to forget what a massive headache it all is
p.s. Oh, but before I forget. A big thank you to the over one hundred group leaders who have already responded.
As promised a couple of weeks ago, I've sent a census email to all registered leaders of Perl Mongers groups. If you are the leader of a group and you haven't received the mail, then please contact me at census[at]pm.org.
Results should follow in a few weeks (dependent on how soon the group leaders respond).
We're organising another Perl Mongers census this year. The last one was in 2005 so it's about time. In the next few weeks all Perl Mongers group leaders will receive an email asking them to fill in a census return for their group.
The email will be sent to the group leaders using the email address we have in the PM group directory. And that's why I'm giving this advance notice. If you're in a Perl Monger group then please check that the contact details we have for your group are correct. If anything needs to be amended then please ask your group leader to get in touch with us to fix it.
Oh, it succeeded in fixing most of the the CPANTS issues that I was addressing. But doing that whilst producing a distribution that doesn't even build for most testers is probably a sub-optimal solution.
I'll get a fixed version uploaded tonight, but in the meantime, please ignore version 1.98.
And repeat after me: "Kwalitee is no guarantee of quality".
Yesterday I was in Birmingham at the UKUUG Spring Conference. This year the emphasis is on dynamic languages and they asked me to give a day-long Perl tutorial. I presented a (lightly) updated version of the Teach-In that I previously presented at the BBC last summer.
My plan is to (eventually) upload all of my talk slides to Slidehare. This is, however, being slightly hampered by the fact that many of my slides were created using various (generally home-grown) HTML generators. And Slideshare doesn't (yet) handle HTML presentations.
This morning I've submitted two talk proposals for YAPC::Europe 2008. The titles are:
Don't want to go into any more detail yet, but I hope they'll both be a lot of fun.
A couple of years ago I started building feed aggregation sites (aka "planets") using Plagger. Once you've installed Plagger, it's pretty simple to configure new planets.
Notice I say "once you've installed Plagger". Plagger is one of those CPAN modules which installs about half of CPAN. The CPAN dependencies page currently gives you a 26% chance of successfully installing Plagger.
The reason for that is clear. Plagger is an incredibly powerful tool. It is an all-purpose tool for slicing and dicing web feeds. It also includes special-case plugins for creating web feeds for many sources that don't currently publish them.
So the net result is that Plagger is large and often hard to install. And most people (or, at least, I) don't use a fraction of its power. I wish I didn't have to install all of Plagger's dependencies in order to just grab a few feeds and combine them into a planet site. Perhaps the Plagger team needs to look at breaking up the distribution into smaller parts that do less.
[Update: Miyagawa points out that the vast majority of Plagger's dependencies are optional, so I'm overstating the case here. Sorry about that.]
Recently I moved a lot of my sites to a new server. And I really didn't want to go through the pain of installing Plagger. Therefore all of my planets have been dead for a couple of months. And that has been bothering me. But a couple of days ago (prompted by something that Paul Mison wrote) I decided to do something about it.
I a few hours of spare time I wrote Perlanet. It doesn't do anything at all complex. It reads data from a YAML file, uses XML::Feed to parse the feeds and then the Template Toolkit to generate the web page (oh, and XML::Feed again to generate the combined feed).
It's very simple. And it's new, so there may well be bugs. But it's there if you find it useful. It's already powering a revived planet davorg. My other planets should come back to life over the next few days.
I'm sure I'll be adding more features over the coming weeks, but the main point is to keep it simple.
 After Planet the Python software that (as far as I know) first popularised this method of aggregating data.
 Yes, I know it's a terrible name. But it seemed obvious to me and now I can't shake it.
I've been a rather slack CPAN author for the last couple of years and haven't been updating my modules as much as I should.
But over the weekend, whilst updating the Teach-In slides for the UKUUG conference I discovered the new CPAN testers matrix and, in particular, the appalling test results for the current version of Symbol::Approx::Sub.
Obviously having major test failures in such a crucial module is a terrible state of affairs so I spent some time looking at the problem last night.
Luckily it was a relatively easy fix. It was just a test which had been written by someone (me!) whose knowledge of Perl had temporarily left them. Fixing it was simple enough, and I was able to release the first new version of Symbol::Approx::Sub for over two years. I also switched the distribution from ExtUtils::MakeMaker to Module::Build and made a few other tweaks which have improved its kwalitee.
And this morning, I saw a much happier set of test results. Which was nice.
Whilst poking around in my test results, I noticed that WWW::MakeAShorterLink was also failing far too many tests. It turns out that this is because the MASL web site no longer exists. Or, rather, it redirects to TinyURL. So I've submitted a deletion request for WWW::MakeAShorterLink. It will be removed from CPAN in the next couple of days. All of your URL-shortening needs will be handled by WWW::Shorten. And, yes, next on my list is to fix the problems in that distribution's test plan.
Many thanks must go to the CPAN testers whose is so important in revealing my inadequacies as a programmer.