Nigel Metheringham

HTML::Scrubber 0.09 release

2011-04-01T15:41:22Z

Following my recent post on HTML::Scrubber, I have been given maintainership rights on the module.

So I have sorted all the urgen stuff, including the 3 separate RT entries for a tmp file vulnerability, and pushed a new version to CPAN.

Coincidently, whilst updating the Changelog, I noticed the last release was exactly 7 years ago. So, umm, happy birthday HTML::Scrubber 0.08, but you have now been superseded!

HTML::Scrubber maintainership

2011-03-28T15:43:51Z

HTML::Scrubber appears unmaintained at present, and I cannot find a way to contact the author (podmaster) - email bounces and I cannot see any activity later than 2006.

If you know a means to contact podmaster aka D. H. then I'd appreciate it if you could put us in touch so I can see if he would be open to an offer of co-maintainership or handing the module over.

DBIC Deployment Handler

2011-02-25T16:51:35Z

I think, after a load of floundering around, that the way to use DBIx::Class::DeploymentHandler has finally clicked - I have no idea why it seems to have been so hard for my mind to work out how to use it, but this module has really made my head hurt!

So, I am aiming to put together a few blog posts on using Deployment Handler to manage upgrades (and theoretically downgrades, but I have never tried those). I should get something produced around the end of next week (minor issues like stage managing a play in theatre all next week allowing!).

HTML::Formatter release

2011-02-18T21:00:37Z

I've pushed out an initial release (version 2.05) of HTML::Formatter which covers the incompatibility with current perls and RTF formatter initialisation.

I'll work through the other issues as I get the opportunity - but the incompatibility with current perl versions was the reason I took on maintenance, so I wanted to get a release with that fixed out quickly.

Picking up HTML::Formatter maintenance

2011-02-14T20:45:50Z

I've volunteered to pick up maintenance of the HTML-Format module, which has been lacking love recently (last update 2004).

Initial intention is to do maintenance on it - its currently causing warnings about UNIVERSAL::Can on recent versions of perl and there are a number of RT tickets for it.

I am converting it to use Dist::Zilla for release management (although my CPAN volume does not really justify this, the fact that it manages the bits I would otherwise forget does!). Source - including imported versions of all the previous tar files I could find on backpan, is now in git on github.

A trial release has gone out, although I intend to further work before pushing out the next proper release - specifically improving the documentation and tests.

Not A Post

2010-11-26T20:05:23Z

This is not a perl blog post... Unfortunately I have not posted for a good while, and theres going to be a further gap before I start again properly.

So, following a week of holiday, a week on an intensive training course, a week running a theatre show and two weeks organising things for pantomime; I am about to start 2 weeks of pantomime stage management.

So basically I am not going to do much more in terms of blogging until late December.

Server Deployment Packaging (2)

2010-10-15T11:36:05Z

Last week I posted about my current experiments in deploying perl applications to our Centos 5 servers - or rather the first steps of building a perl package along with the required modules.

I am just starting work on testing this all through, when suddenly one of the blocks to using the current stable perl (ie 5.12.2) has disappeared - TryCatch is now supported on 5.12.x

So, although I have some current tests running, I am just in the process of modifying a few parts of the build scripting (mainly down to me missing a couple of local modules from the build), and then a new version based on current stable perl will hit the build systems.

Server Deployment Packaging

2010-10-08T13:59:22Z

We tend to use Centos 5 on server systems.
In the past I have handled perl package deployments by using the native (or occasionally, when upstream maintenance has gone wonky, a minimally patched rebuild of the native) perl, with all the modules I require built as native rpm packages.
Maintaining this has been, frankly, a bugger.
Additionally the system perl is often less than performant, and somewhat elderly.
So I am trialling a new mechanism.
This uses perlbrew to build a perl into /opt/perl - currently using perl 5.10.1 (mainly because a pile of things won't build with 5.12.x due to TryCatch failing to build (and its a dependancy of many other packages I do need).
I then have a local Task:: module which pulls in all the DBI, Catalyst and other random CPAN goodness I could need, with CPAN configured to look at a local versioned mirror so that the complete build is repeatable.
So I end up with a monster package (actually only 27MB) of perl binary and modules, which all our applications will depend on.
This is, frankly, a kludge.
And it does have drawbacks (dependancy handling will be somewhat bypassed, it requires a complete rebuild to add/update a module). However its cleaner than the current approach in my opinion.
So I just need to start testing things with this configuration....

A few of my favourite things.... Set::Object

2010-10-04T11:32:04Z

One module I discovered a few years ago, and seem to end up using for many things, is Set::Object by Sam Vilain.
Although this initially looks like a degraded hash - it holds a number of scalars and references - it comes with a whole batch of set operations (union, intersection, differences etc), and its fast.
Its also been consistently and carefully maintained, and Sam is a responsive maintainer.
Set::Object has been far more useful to me than I first expected, has preserved me from a ton of code mangling hashes to do the same operations, and is a really useful part of my toolkit.
The only downside is I mostly use it when working on billing related code at work - an occupation that does not fill me with joy :-/

So who knew...

2010-09-24T11:18:13Z

I'm currently working with extracting data from a system with an XML based command UI, so I am fairly often dumping serialised (using Data::Dump) perl objects out whilst debugging.
To make the piles of debug output easier for me to parse I pushed the files through Perl::Tidy.
You would not believe how long it takes, or how much memory is required, to run 110MB of perl datastructure dumps through perltidy!
Actually I don't know how long or how much memory it took either - I killed it after half an hour and 3GB.
I mean, who knew! :-)

More thoughts on Dist::Zilla

2010-09-17T11:23:42Z

Having just read Zbigniew's blog entry on Dist::Zilla managed distributions.

This is a real issue - admittedly I have been trying out a number of plugin bundles recently, but having to test a new config by doing dzil build and scroll back to the top error message to find the missing plugin, install that, redo is just not a fun development method.

Maybe as a first cut we could do with a dzil tool to spit out a required plugin/plugin bundles set which we can then pass to cpanm or similar.

For me this is just an irritation. I suspect for someone who has just cloned their first project from github because they want to try changing something, this could be a real pain...

Working For Bletchley Park

2010-09-11T20:51:27Z

This might not seem like a perl blog post. However it is...
Back in the second world war Bletchley Park was the focus of the allied code breaking operations, and the equipment and techniques devised there were the direct ancestors of modern computers and algorithms.
Perl builds on foundations laid at Bletchley.
After the war the role of Bletchley was treated as a state secret, and to the shame of the UK the whole history and site was allowed to crumble; only in the last few years have serious efforts been made to preserve the site and its history, but more work and money is still needed.
So, if you are in the area, why not visit Bletchley.
And, if, like me, you have a good career in computing, why not consider donating something back to the birth place of the modern computer.
At least 100 others have joined me and pledged 1 day's salary to the Bletchley Park Trust - we would love it if you could join us.
You can find more details at http://www.work4bletchley.org.uk or donate at http://www.justgiving.com/workforbletchleypark

Adventures with Dist::Zilla - 3 - Can't Get No Satisfaction

2010-09-03T11:53:05Z

I am still slowly working my way through Dist::Zilla attempting to get the config that works for me...

I suspect that the plethora of PluginBundles::personid are down to it being very hard to slightly modify a config other than by writing it out in full or by nasty filtering gymnastics...
For example I've been building a Task:: module for work - this pulls in everything I want as a base system on our servers. I started with an existing Task module, git cloned it, and modified it into the form I wanted - bringing along the initial Dist::Zilla config and changing that to suit as well.
The dist.ini file worked well for it - I just wanted to make 3 changes:-

Use my own timezone rather than the embedded configured one

Specify version numbers rather than using the AutoVersion

Not upload to CPAN - this is internal (and experimental) only

The config fragment I ended up with was this:-



[NextRelease]

; -- Use JQUELIN's bundle but without auto version numbering

; -- and with NextRelease removed (time zone issues)

; -- and with the actual PAUSE upload suppressed (private module)

[@Filter]

-bundle = @JQUELIN

-remove = AutoVersion

-remove = NextRelease

-remove = UploadToCPAN

weaver  = task

; -- we need a releaser module, so here is a fake one...

[FakeRelease]

which just feels too fiddly and as though I am sifting through the internals of the system.
Maybe I am just too fussy...

Useful side effects of the perl testing culture

2010-08-27T12:06:28Z

I am currently in the middle of trying a new mechanism to deploy perl applications (several which are catalyst based) on servers at work while attempting to keep the level of supporting system (ie perl and the required modules) maintenance work to a minimum whilst being able to use modern perl - and we are running on Centos systems by default, so currently the system perl is 5.8.8. I intend to write about my proposed solution to this in a few weeks when I have had more of a chance to see how it works...
However as part of this I have been building perl and a whole raft of supporting modules under a set of build system scripts - encouragingly the whole build appears to be around one hour in length.
What I wasn't expecting to see was test failures when building the modules.
I really wasn't expecting to see a set of failures down to the tests failing in XML::Parser - thats a widely used and slow changing module.
So I went digging... and finally got to the Red Hat Bugzilla entry #556415.
A undertested security fix to expat had caused a regression - which went unnoticed other than by the XML::Parser test suite.
Thats a big win for the perl testing culture.

Adventures with Dist::Zilla - 2 - Weaving The Pods

2010-08-20T11:30:34Z

I've been spending a bit of time this week looking at Pod enhancements for Dist::Zilla released modules, I have hit a bit of an impasse.
I quite like the [Availability] Pod::Weaver section plugin - Pod::Weaver::Section::Availability, however currently it hardwires some of the information to make it specific for the author (and unfortunately that means that the module name space is polluted by this). I'm just working out the best way to parameterise this information - although its a little tricky since really Pod::Weaver should work outside of Dist::Zilla, and the mechanisms I can see others using are grabbing information from Dist::Zilla for it...
Less controversial is the [BugsRT] module (Pod::Weaver::Section::BugsRT) which adds bug tracker information to the POD.
The two of these together should allow me to get released modules with pods how I like them.