Perlanet Improvements

I can be a bit of a lazy open source author at times. I love it when someone improves my code and then just emails me patches. I love it even more now that I’m using Github so that people can just fork my code and send me pull requests.

That happened over the weekend. I got a pull request from cycles saying that he’d been refactoring Perlanet and asking if I’d be interested in merging his changes. These refactorings had come out of a mini-hackathon that had been run by the North West England Perl Mongers. I knew that they had been interested in using Perlanet to power the Iron Man aggregator, but that the monolithic nature of  the code made it hard for them to subclass the bits that they needed to change.

So what cycles has done is to take my code and break it down into a number of smaller functions (and a couple more classes) so that people can subclass it and override methods where they want different behaviour to the defaults that I use. I can see this leading to a little ecosystem of Perlanet subclasses where people release their favourite tweaks to CPAN. I see this as a good thing.

I liked cycles’ changes so I merged them into my repository. They’re available there now if you want to look. I haven’t yet released a new version to CPAN as there are a few things I want to check out first.

Firstly, this new update seems to have increased the version of Moose required. With the version of Moose that I was running on my system (0.88), a lot of the tests were failing. Updating to 0.93 solved that problem. I need to work out exactly what the problem was and update the “requires” line in Build.PL appropriately.

Secondly, the newer version of Moose gave a deprecation warning when used with CHI. Updating to the latest version of CHI fixed that (but that, in turn, meant upgrading a few modules in the Log::Any family). This is all starting to get a bit too close to the bleeding edge of CPAN for a module that I want as many people as possible to use.

Finally, cycles had started to use TryCatch in the module. Not, of course, that I object to high quality exception handling in my code, but this is another module that isn’t yet in general use. It’s something that you won’t find in a “standard” (whatever that means) Perl installation.

I’m in the process of building RPMs of all of the missing modules (or later versions for the modules where the Fedora/Centos build is just lagging CPAN a bit). They’ll be available from rpm.mag-sol.com in the next few days.

Currently I’m leaning towards just releasing the new version and hoping that the people who want to use it will have enough enthusiasm that they won’t complain about the updated and new modules that are required. But I thought it would be interesting to ask for your opinions too.

As a user of CPAN modules, how do you decide when a module is too cutting edge for you to use? Do you just install newer versions of modules automatically when an installation asks you too? Or are you a little more careful than that? Would the constraints in this latest version of Perlanet prevent you from using it?

And as a writer of CPAN modules, how cutting edge do you allow yourself to be? Are you happy to release stuff that only works with the very latest versions of Moose or other fast-moving modules? Or do you like to ensure that your stuff is usable by people who might be a little behind the curve?

I should make it clear that I’m very grateful for the work that cycles did and I’m not disparaging his efforts at all. I’m just dithering a bit about how cutting edge I want to be.

Speaking in Milton Keynes

Last Thursday I went to visit the nice people at Milton Keynes Perl Mongers. I think I’ve spoken at one of the technical meetings every year since they started holding them in 2006. I always enjoy speaking to MK.pm. They’re a small and friendly group. And they always make me feel really welcome.

This time I tried something a bit different. I had a few talks prepared that I’d given earlier this year, but on their mailing list I asked them to suggest what they wanted me to talk about. After a bit of discussion they came up with a few interesting suggestions and I agreed to present two of them. And, interestingly they came up with two talks that I would never have considered writing.

The talks seemed to go down pretty well and the slides are now available on Slideshare. They probably won’t work quite so well without me waffling on in front of them, but you might find them interesting.

  • Maintaining CPAN Modules – the tools and techniques that I use to maintain my small selection of CPAN module
  • Perl Training – Some experiences, anecdotes and vague conclusions drawn from the right years that I’ve been running Perl training courses

I found it an interesting experience writing talks that I hasn’t planned to write. It’s one that I hope to repeat in the future. Perhaps conferences should consider changing the way that Calls for Papers work. Maybe they should add a checkbox which means “I don’t care what I talk about – please give me a title.”

Perlanet Update

Maybe it’s just me, but when I know that people are using my code it galvanises me into improving it. Following the discovery that people were actually using Perlanet, I’ve made quite a few releases over the last week or so. I thought people might be interested in what I’ve been doing.

Release 0.30 was a big one. I incorporated a lot of the improvements that Alex had made in his fork. Most important was probably switching to URI::Fetch instead of LWP::UserAgent. This means that we can now cache the feeds and only re-request them when they have changed.

Release 0.31 documented the caching feature. It also removed some annoying debugging output unless the program was running in a console. I also tweaked the output for failed requests and thereby introduced a nasty bug that wasn’t fixed for some days.

Release 0.32 added some better help for the ‘perlanet’ command line program and added a lot more of Alex’s fixes and improvements. I also tried running the code through both ‘perltidy’ and ‘perlcritic’ and made some changes based on their suggestions.

Release 0.33 featured a much improved test suite. It also fixed the nasty bug that I introduced in 0.31. If you were using a cache and a feed hadn’t changed from the previous request then it wasn’t processed at all. I found this bug whilst working on the test suite. Testing is good, boys and girls!

Release 0.34 went out in the last hour. Overnight I got a bug report about the caching support. I’ve been using CHI to provide caching, and because not everyone wants to use caching I had marked it as an optional dependency in Build.PL. But I was loading it in the code whether or not it was being used. So if you didn’t have it installed, Perlanet didn’t work at all. I’ve now made it truly optional – it’s only loaded if required. And if you try to use caching but don’t have CHI installed everything still works – just without a cache.

That got me thinking. And the version currently in github applies the same principle to OPML support using XML::OPML::SimpleGen. Not everyone wants to generate an OPML file, so I shouldn’t force everyone to install that module. That will be in release 0.35 which will go out in the next couple of days. I’m also thinking of doing the same for the HTML::Tidy[1] and HTML::Scrubber support.

I still have some more of Alex’s patches to apply. But I’m considering how to make things like filter support into an optional add-on. I’ve tried to get some discussion of these features going on the Perlanet mailing list. If you’re interested in Perlanet, please subscribe to the list and get involved in the discussions.

[1] I should point out that Perlanet already has support for HTML::Tidy, but installing HTML::Tidy is a bit of a black art currently. The RT queue seems to imply that the module has been abandoned. Does anyone want to offer to take it over from Andy?

This Makes Me Happy

I like it when my software is used to do interesting and useful stuff.

Alex Kapranoff has built PlanetPerl.ru to aggregate blogs about Perl in Russian. He has used a patched version of my module Perlanet. I’ll be taking a close look at Alex’s patches to see what I should bring back into the CPAN version of the module.

Moose or No Moose

I’ve known about Moose for some time.The first time I talked about it in a training course was at the Teach-In back in the summer of 2007. It’s been part of my training courses ever since.

But even though I was telling people about Moose in my training courses, I wasn’t really making use of it in my own code. Obviously as a freelancer, in my day-job I’m constrained to using whatever technologies my clients are using and I have yet to be paid to work on a project that is already using Moose (although I’ve suggested that a few clients switch to it).

That leaves my own code. Which is largely my CPAN modules. Until recently I hadn’t used Moose for any of them. The first one I released that used Moose was Guardian::OpenPlatform::API. That was a new module which used Moose right from the start. But I knew that eventually I’d want to go back and refactor my existing modules to use Moose wherever it was appropriate.

Having gone to YAPC::Europe this year, I was subjected to another week of people telling me face to face just how cool Moose was. So I decided that it was time to bite the bullet and start refactoring.

The next module I tried was Parse::RPM::Spec. I chose this for two reasons. Firstly, it’s very much an attribute-driven module. Apart from the initial parsing of the spec file, objects of this class exist simply to return the values of their attributes. This makes it a great match for Moose. In fact converting it to use Moose was largely a case of removing code. The second reason for choosing it was more pragmatic – as far as I know no-one is using the module so if I broke anything I wouldn’t have hordes of angry users on my back.

Impressed by how easily that conversion was I moved on to Array::Compare. This module holds a special place in my heart as it was my very first CPAN module. I don’t think it’s a particularly useful module. It’s algorithm is pretty basic and other than the project that I originally wrote it for I’ve never used it in any production code. I often use it to try out new techniques. I released version 2.00 on August 9th (the change of implementation seemed to justify bumping the major version number).

Yesterday I got an RT ticket asking me to stop using Moose. The ticket is pretty clear that for several uses (it specifically mentions command line usage) the extra overhead added by Moose leads to an unacceptable performance hit.

I’m not sure which way to go on this. As a developer I like using Moose. Moose makes it much easier to write object oriented code in Perl. And I think that over the next year or so more and more CPAN developers will be using Moose in their code. Already if you’re writing something reasonably complex in Perl there’s a good chance that you’ll be using a module that uses Moose. As time goes on the percentage of Perl code that relies on Moose will increase. But if it really imposes an unacceptable performance hit for smaller applications, do I really want to force developers into using Moose sooner than they want to?

I think I’m going to put on hold my plans to move stuff to Moose until I’ve thought this through a bit more. But I’d be interested in hearing other people’s opinions. If you’re a CPAN author, are you planning to move your modules to Moose. And if you’re an application developer, have you started to avoid CPAN modules which force you to use Moose?

Let me know what you think.

Update: Well, didn’t this entry start a lot of discussion? As well as the comments here, there have been a number of other posts that reference my post. Here are the ones I’ve seen (in no particular order):

I’ll add more as I come across them. Of course, the more discussion I see, the more unclear my decision becomes.

But thanks for the interest. The discussion has been fascinating.

Net::Twitter and Iranian Elections

Over the last few days I’ve seen a large number of tweets saying that the Perl module Net::Twitter is being used to post pro-government propaganda from Iran. If it’s true, this is almost certainly a reaction to the large number of people who are using Twitter to get around the Iranian government’s censorship.

It’s disappointing, of course, to see Perl being used as an instrument of propaganda and repression. But that’s one of the dangers you have to face when you release software under an open source licence. I only hope that people realise that Perl is a tool that can be used by anyone and that we don’t run the risk of being linked to Ahmadinejad’s regime just because of the programming language we use.

iransource seems to be one of the pro-Ahmadinejad bots, but it’s been quiet for a couple of days. Has anyone been tracking these bots? And is there any previous evidence of Perl being using by repressive regimes?

New CPAN Releases

I haven’t been particularly prolific in releasing new versions of my CPAN modules recently. But over the last couple of days I finally got my act together and release new versions of three modules.

In all three cases, I’ve fixed pretty obscure bugs, added minor functionality or fixed the documenation. There’s nothing there that is a particularly compelling reason to upgrade.

CPAN Web Feeds

I’m still thinking about adding stuff to this blog. I’d like to add some web feeds to the sidebar. In particular, I’d like a feed of my CPAN uploads. I don’t expect it to be a particularly busy feed (although having such blatant evidence of my laziness might galvanise me into being a bit more productive) but was surprised to see that such a feed doesn’t seem to exist.

CPAN has a “latest uploads” feed, And there are a couple more documented in the FAQ, but none of those do what I want.

It seems a simple enough idea. I can pull down the latest uploads feeds and filter it on my name. But before I do that I thought it was worth invoking the power of the lazyweb and asking if anyone else has already scratched that itch.

Joining the Github Massive

I got tired of hosting my own Subversion repostories and having to deal with setting up access for anyone who wanted to work on my CPAN code (ok, honestly, that was two people in the last five years!)

So I’ve moved all of my CPAN modules (and a few other random bits and pieces to Github. Let them deal with the hosting issues and, more importantly, let anyone who wants to hack on my code.

You’ll find it all in my Github account. Feel free to dabble.