Very very rarely do people piss me off. But the Perl community has one group that really gets me riled.
Traditionally, Perl has really shined in three areas, those being Admin, Web, and Data(munging|base).
As a result, quite a lot of Perl developers are professional sysadmins. And as a result of _that_, there's a percentage of BOFHs mixed in.
In fact, if you exclude the scientists and the speakers, most Perl people can be seen to fit on a scale that has "pure developer" at one end and "pure admin" at the other.
For some reason, admins seem to have a particular approach to life, that being to take an approach of doing things with the least amount of work possible. And BOFHs do this aggresively (with a good dash of misogeny thrown in).
Now, for normal day to day tasks, this is a good thing. We want people that can pull a bunch of tools, read some docs, and get stuff working quickly. And BOFHs are great in situations where you _really_ care about the infrastructure, and you don't want it to suffer because the users are bringing shitloads of jobs for the admins and distracting them.
In the development universe however, this approach completely sucks.
Developers, by their nature, are problem solvers of a different sort. Developers want to solve a problem, but they want to solve it once, properly, for the entire class of problem, in as many situations as possible. It's the "Lazy" part of that famous line. Putting in extra work now, so you can be lazy later.
Admins don't have this luxury. Despite the best efforts of an admin, hardware will still break, the business around them will change and invalidate their existing system, and things are generally more fluid.
Developers often have the blessing of a comparatively stable environment. Things don't just randomly break. If they do, it's due to a flaw, and not mere chance, and if you improve the solution, life is good again.
In the Perl world, the members of the "CPAN Double Figures Club" occupy the extreme end of this admin-developer scale.
These are the 162 people that have uploaded 10 or more packages that contain modules in the CPAN index.
The elite "CPAN Triple Figures Club" has only two members, Autrijus Tang(active) and Simon Cozens(retired).
For these 162 people, it is not so much that they wish to solve the problem once, but that they want to solve it once for everybody.
And it's done for the most part in the same spirit as Unix. Lots of small pieces that do one thing well, all interconnected.
So I get extremely annoyed when perfectly decent Perl people that normally act in a clueful manner seem to complete miss the point, and devolve into BOFH behaviour.
Today I got involved in an online conversation relating to testing. It's always perplexed me that the Perl community, filled to the brim with talented programmers and admins, using a language that shines at admin work, doesn't have a reliable way of testing packages.
Yes, we have CPAN Testers, but they only test CPAN packages, and only test what they want to test. In that regards, in the limited case we are willing to give code away to the community, we are behoven to the kindness of strangers to do our testing for us. We have to upload potentially broken packages, and then respond to the errors after they break.
Responding to errors and fixing it for each case is admin behaviour, evolved from an environment in which you can't predict errors until they happen.
As developers, we should be expected to solve it in a better way. And to do so that doesn't just work for CPAN, but is also useful for commerical packages.
Boosting the commercial Perl world boosts us all. It means more and better paying jobs for Perl programmers, and more and better Perl programmers.
So why not create a GOOD system for testing Perl packages of any sort.
The obvious solution (to me at least) is some form of defined testing system that anyone can use, made up of about 4 distinct components.
Lets call it Test::Platform.
A Test::Platform server must have an installation of perl configured to CPAN (or a minicpan).
It must have a service running on a defined port, probably in the form of a small web or SOAP server (wrapped up as a PAR dist to avoid altering the native perl installation), to which one can upload a CPAN-compatible tarball.
The Test::Platform::Server will take the tarball, unwrap it, configure, make, test and install the package, while capturing the output of the process. It will return the output to the client, that can do with it as they wish.
Test::Platform::Client would presumably take a file or URL, send it to the server, retrieve the result, analyze the result, and act on it accordingly.
It's a small step from there to imagine a script or module that would set up your system form you to act as Test::Platform-compatible server.
It's only another small step to imagine setting up a VMWare image like this, and having Test::Platform::Client::VMware boot up the image, connect to the standard testing image IP address, and fire the testing package at it.
Another step would see you being able to test a package against multiple images and collect the results in a database like SQLite.
And one more step sees someone hosting a repository of pre-built images somewhere.
You could install Test::Platform and VMWare, download a dozen images of your choice from the image repository, and test any package you wished.
All you would need would the hardware to run it on, and the patience to start it up and walk away while it ran the test run for each image.
Now, it seems perfectly straight forward to me, but _I_ am a mere developer, suck at admin stuff, and don't really have the time to learn on how to build VMWare images.
To have half a dozen BOFHs offer to help you out and say, "But it's so easy, you just $foo. Why do you need a module for that" is unbelievably frustrating, especially when what seems easy and simple to THEM is completely new and unexplored and difficult for you. Geeks and BOFHs are prone to this sort of thing.
Sometimes it's like hearing them say.
"It's easy, first you numb the area using any suitable neural analgesic, then drill a short-medium length into your head. Once there, use any applicable general relativity engine to write a Perl 6 implementation, then you're done. How hard could that possibly be!"
I don't want to solve my immediate problem.
Hell, I don't even HAVE an immediate problem of this nature. But there are 2800 CPAN developers, and hundreds of thousands of Perl programmers out there who would benefit if someone who knows this stuff that I don't would take the first small steps and write a basic Test::Platform implementation, or write a script to set up a VMWare image as a Test::Platform-compatible image, or even write a detailed or hell, a fucking cut and paste HOWTO so that someone else can write it.
ThreatNet has started to take off now. Why? Not because I wrote a bot that people could use, but because I added complete working config and filter code to the docs.
So all that anyone who was curious had to do was cut and paste and change some values.
When will the Perl community learn the key to making successful projects is to make it as trivially braindead as possible to install it and get started, and to make some fast early wins for the users.
At about the time they started to explode in usage, PHP and MySQL were (and to some extent still are) the ugliest and worst possible combination for making web applications in. And look where it got.
So in conclusion and on behalf of the 162 of us.
Dear Perl BOFH.
Show some fucking vision!
Take the first steps and encapsulate that great knowledge of yours, so that we can take the next steps and everyone can benefit.
We wrote most of the modules you use every day, how about giving something back occasionally.
The CPAN Double Figures Club
And if anyone is listening and wants to help start a project that could fix this whole testing problem once and forall, write a small module that will run a small web server on a specific port, that takes requests with three or four properties.
testid = string
cpan = path to a cpan mirror
package = file upload of a package tarball
respose = URL to send the results to
Have it unwrap the tarball, run perl Makefile.PL, make, make test, make install, capture the results of STDOUT and STDERR, and then send the response via a HTTP PORT to the URL it was provided.