Results tagged “tech”

The perl.org infrastructure is incredible. Ok, so not all of the subdomains of perl.org are hosted on the same servers, some of them are just DNS redirections, but they still run a large number of web sites there. It's not just web sites either, a large (and I mean large) number of Perl mailing lists are run on their servers. And that means they handle a lot of spam. They also run many of the sites under pm.org and cpan.org. You can get a good idea of what is involved from the NOC page on the site. It's an impressive list.

But the most amazing thing about the perl.org team is that they are volunteers. Both Robert and Ask have real jobs in addition to keeping the Perl infrastructure servers running. They have a small team that help them out with some of the work, but no-one gets paid for it. The hardware is all donated by sponsors too. If you have any hardware that a large network operations centre might be interested in then please take a look at their wishlist.

So each time you visit a Perl web site or use a Perl mailing list, spare a thought for the volunteers who keep it all running.

Yet another good reason to be proud to use Perl.

You can keep up to date with what is going on with the perl.org by reading their NOC blog.

My experience of web-based language support forums has been patchy to say the least. Often they seem to be a "blind leading the blind" kind of place with uninformed people helping each other to find sub-optimal solutions. I'm not suggesting for a second that Perl is immune to this phenomenon. I've seen many Perl sites that conform completely to this model.

So what it is that makes Perl Monks so different? The big difference has to be the quality of the programmers who visit the site. At any time of the day or night you'll find expert Perl programmers there who will be happy to help you with your problem. You can be sure that most of the advice you get from Perl Monks will be of top quality.

"Most of the advice"? Yes. Of course there will be times when you get advice that isn't quite as good as it could be. And that's where Perl Monks' other advantage comes into play. Perl Monks has good feedback in the form of its voting system. If you see a good question or answer on the site then you can give it a positive vote. If you see a bad question or answer then you can give it a negative vote. Voting for or against an entry also has a change of effecting the reputation of the author of that node. People who consistently give good answers will rise to the top of the league table so it becomes easy to know whose answers to trust.

Perl Monks is also one of the friendliest forums that I know. There are occasional arguments in the chatterbox, but most of the time it's a pleasure to be there. I think this was an ethos which was imposed by Tim Vroom (the original creator of the site) and which is now so deeply ingrained into the site that anyone who disturbs this peaceful and friendly atmosphere won't last very long on the site.

So you've got friendly experts who will happily answer your Perl questions in something like real time. I can't see any downsides there at all.

It's a site that makes me proud to use Perl.

Let's start with something really obvious - CPAN. The CPAN (or the Comprehensive Perl Archive Network, to give it its full name) is a marvel of the Open Source world. It contains thousands (over twelve thousand) of free libraries of Perl code that are available to help you solve all of your programming problems. Yes, the quality is variable, but the vast majority is useful code.

So reason one for being proud of the CPAN is the sheer amount of code that is available there. I don't know of any other single-language repository of libraries which has more code available. No other language has a single place where you can get all of the libraries you'll need.

And that leads me to reason two for being proud of the CPAN. It's the way that the CPAN is accepted in the Perl community as the one place to distribute your Perl code. For many Perl programmers, if your module isn't on the CPAN then it doesn't exist. It works both ways. If you want a Perl library, you go to CPAN to look for it. And if you want to distribute a Perl library then you put it on CPAN. There's really no other alternative. It's incredible that the Perl community has build up and maintained this idea that CPAN is the only code distribution network that they need.

Another reason for the popularity of CPAN is the way that pretty much all of the code their uses a standard method for packaging and installation. Once you've downloaded and installed one CPAN module, you know how to download and install them all. And it's so easy to do. No messing with paths or anything like that. A CPAN distribution uses the standard method to install the code into standard places that your Perl installation already knows about. Ok, to be honest, there are a few distributions there which don't follow these rules. But these are seen as second-class citizens and are generally ignored.

Then there's the whole eco-system that has grown up around the CPAN. Not sure exactly what module is right for you? Try the CPAN search engine. Is the standard 'make, make test, make install' installation method too complex for you? Then use the cpan (or, more recently, cpanplus) command line program instead. Do you want to see how well the code works without installing it? CPAN encourages the inclusion of test programs in module distributions. And these tests are automatically run each time a new version of a module is released. On many different platfforms. And you can see the results of these test runs. Want to know whether a module that you're interested in is packaged in the standard manner? Then look at CPANTS. Want to review and rate a module that you have tried or read other people's reviews? There's cpanratings. Found a problem with a CPAN module? Report it on the CPAN request tracker. The list goes one and on.

CPAN is Perl's "killer app". You're not a Perl programmer until you know how to use it. It's the number one reason why I'm proud to use Perl.