Path::Dispatcher: a dispatcher that can work just about anywhere. It works (roughly) analogously to the way mod_perl works when matching URIs and dispatching to URI handlers. This code can work in any context including the command line.

IPC::Run3: the successor to IPC::Open2. A simpler API with the same functionality.

Config::Model: A framework for creating configuration validation and editors. This is something I've wanted to write for awhile now. If I understand the goal of this module correctly it should make writing configuration systems very simple.

App::perlbrew: Manage perl installations in your $HOME. I can see where this can be very useful. Here is an introduction on its use.

Moose: It looks like version 1.0 of Moose has finally been released. I don't use Moose and my initial introduction to Moose (over 1.5 years ago now) was not a particularly positive experience. Having said that I would say that this is a pretty big deal. It seems a lot of people really like Moose and I think that sometime in the near future I may jump on the Moose bandwagon.

Acme::Module::Build::Tiny: A tiny replacement for Module::Build. Written by the same author who maintains Module::Build. It is missing a lot of features, but if you don't need those features this module is very light.

Scope::OnExit: Execute code on scope exit. I'm not certain when I'd use this, but it looks useful for theoretically interesting things.

SQL::Statement: SQL parsing and processing engine. The documentation details three things the author believes this module is good for.

PAR: The Perl Archive Toolkit. Perl's answer to tools such as jar. Allows the user to package up a complete distribution, including all dependencies, into a single file. Very, very cool.

PAR::Packer: A companion to the above module. This is a frontend script that allows for (among other things) the creation of standalone executable files that contain an entire distribution (including perl itself!).

An interesting post by Ovid about 100% test coverage, what it means, and what it does not mean. The first comment by David Golden is also worth a read.

I like the idea of 100% test coverage and I generally make every effort to get there. Using devel::cover is a great tool for finding code that will never be triggered, and the closer you get to 100% the easier it is to spot such code.

NEXT: I don't know that I will ever use this module, but it is interesting. Provides for interesting method dispatching scenarios such as calling all DESTROY's in the inheritance tree.

Net::Amazon::EC2: Perl interface to the Elastic Compute Cloud (EC2) environment. I'm not certain if this is a competitor to the Amazon Perl API or if it somehow complements it.

Yes he is. Granted I woudn't go quite so far as to say, "Benchmarking is pointless", but his point about the comparative usefulness of benchmarking versus profiling is right on the money.

I think the reason for this is not an inherent problem with benchmarking. The problem is that people (developers) tend to benchmark the wrong things and then they optimize the wrong things. Profiling on the other hand takes the entire system into account in its results. This is much more useful than optimizing based on a benchmark of a small part of a complex system.

XML::Compile::SOAP: A real replacement for SOAP::Lite.

POE::Filter::HTTPD::Chunked: As a big proponent of POE I thought this looked interesting. A drop-in replacement for POE::Filter::HTTPD that can deal properly with chunked encoding.

Template::ShowStartStop: Inserts comments in the generated output to show where one template ended and a new one begins. It overrides Template Toolkit's Template::Context to do this.

UNIVERSAL::require: A module that gets around the silly bareword requirements for the builtin require() sub.

IPC::Cmd: An API to run external commands. A wrapper around system() I would guess, but very nice looking.

A good introductory article about Perl namespaces and how they can become dirty. Not surprisingly it mostly talks about how to properly use namespace::clean.