Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Tuesday June 14, 2005
02:24 AM

The part of the Perl community I really hate

[ #25188 ]

Very very rarely do people piss me off. But the Perl community has one group that really gets me riled.

The BOFHs.

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Wouldn't it be easier if you just posted your root password?

    Having a (standardized?) vmware image is missing the point as it's the different configurations that finds the errors that you as a developer can't test yourself.

      - ask

    -- ask bjoern hansen [], !try; do();

    • It doesn't need to be heavily standardised. It only need to behave in a very limited number of specific ways. The bits that _are_ standard are likely to be outside the testing scope for all but a few cases.
  • I got the impression while reading your post that you think "they" should do it. Try posting this on group. I am sure "they" would encourage "you" to do it and in the meantime "they" will continue with building the test modules "they" are working on.
    • That is not point. The point is that I should not have to be the one to write _everything_. I'm absolutely sick of people that offer to help, and the proceed to describe not only why the thing they are offering to help on sucks and won't work, or "isn't needed cause you can solve your specific case like so". When it will work, and it is needed.
  • There are currently around 60 regular CPAN Testers, who test on a variety of platforms and perls. Last month there were 22 different platforms and 11 different perls giving 241 different setups. Being able to have perhaps a good selection of images, with at least the major perl releases and the most popular platforms is a good idea. And the idea you're proposing would hopefully catch most of the obvious bugs, but you aren't going to get away from using CPAN testers. I am pretty certain every single one of t
    • CPAN Testers doesn't solve the problem of testing. Full stop.

      They solve ONLY the limited subset "testing released CPAN packages".

      CPAN Testers is no solution at all for company or private packages.

      And of course they test only what they want. If they didn't want to be in CPAN testers, they wouldn't be there.

      They have full control over what they do, and I have ZERO control over them, as you would expect from people contributing their time in this way.

      I'm just starting to get a little frustrated that every
      • CPAN Testers doesn't solve the problem of testing. Full stop.

        No it does solve complete coverage of testing, but it goes a long way to covering the bulk of scenarios. Trying to test every scenario that exists is a huge task and one I don't think will ever be achieved.

        CPAN Testers is no solution at all for company or private packages.

        Why? I assume you're talking from your own experience. In my experience the cpan-testers have proved useful to know what works on various platforms out of the box and what

      • Don't you think that a "company or private package" only has to work in the "company or private" environment and that consequently the "company or private" developer can, if he likes, use exactly the same tools as the CPAN testers to do his testing?
  • First of all, an offering. Below is some bash-shell code that might be a start toward a portion of what you requested. The code was passed a parameter that was the name of a perl source tar-ball (.gz). It built the version of perl and installed it to a local usr/test/ directory tree relative to where it was installed, and at the time would execute the CPAN module's 'autobundle' command and write to a file. (It also removed the 'built-in' and 'command line' entries from the various Makefiles, because of issu

  • We can tell several things from your journal entry.
    1. You don't know any good sysadmins. When you say "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)" you miss the point that most of a sysadmin's job is tedious and easily automatable, and so it *should* be automated away. This isn't because he's lazy and wants to sit back and do
    • Your claim that developers want to solve problems in the widest most generic way possible just ain't true. Developers work to deadlines and to customer requirements.

      Indeed, and they are compromises from the ideal.

      You seem to think that sysadmins don't plan ahead. A good sysadmin is *not* thrown into a panic when hardware fails. A good sysadmin *knows* that the hardware is out to get him, and will have automatic failover configured (and tested!) or will have plans to temporarily restore service elsewher
  • My very own thoughts: typical perfect world developer mindset to assume that a big and complex problem is straightforwardly and fully solvable. I expect that if you actually try, you’ll find reality to be pricklishly difficult, full of nasty edge cases and little ratholes. Testing is a messy problemspace; that’s why CPANPLUS is still rough.

    However, I am open to being shown otherwise; if you think you really can solve this, go ahead and try. You’ll either find out that everyone else was r