Tag Archives: cpan

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?

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.