I feel compelled to counteract the 5-star rating by the module's author.
Adam Kennedy's review is NOT bullshit for saying that UNIVERSAL::isa(undef, 'Foo') dies, when you consider that:
* the review was written for version 0.02 of the module, which did have that bug
* the bug was fixed for version 0.03, which is great, but there's no mention of the change, or acknowledgement that the bug ever existed. Heck, there's not even a changelog!
Some people may question the usefulness of a bundle containing Ovid's (or any particular author's) favorite modules. I think they can be useful if you find an author with module preferences similar to yours. In this case, I find that I agree about 90% with Ovid's selection, which means that I might actually use his bundle since I'm too lazy to roll my own. :-)
If you don't find it useful, don't use it. It's not like it's "hijacking" an important namespace with useless stuff.
Think of it as amazon's listmania feature. Maybe then we can add an "if you like this module, also try this one" feature! ;-) (I'll leave it to the reader to decide whether that is good or not).
This module produces nice-looking output with lots of information about a perl installation. Granted, it's possible that when you need this information, such as when first getting access to a new server, you might still have some difficulty installing modules in the first place (in the worst case you can resort to things such as perl -V and print Dumper \%ENV). However, I imagine that this module could be useful if the hosting providers installed it. That way they wouldn't need to keep separate documentation about their perl resources, as they can be computed on the fly.
Brilliant! This might help some people produce cleaner code. ;-)
A caveat: sometimes I get spurious error messages the first time I run it on ugly code, but it works when trying again. It seems that the perl interpreter gets confused when the source file gets modified while it's being compiled.
A very practical way of testing code by throwing hundreds or thousands of random inputs at it. LectroTest provides a concise syntax for describing the input domain and expected output, runs the tests automatically, and prints the result in TAP, so they can be digested by Test::Harness. The documentation is excellent.
This is a very nice and useful Kwiki plug-in. However, you should consider that, just used out of the box, it may present a significant security risk.
The problem is that users can upload any type of file. That means that, for example, if you are using a typical Apache server with PHP, users will be able to upload arbitrary PHP programs that get executed by your server. You may be able to tweak the Apache configuration to work around this.
Another solution is that the plugin has an *undocumented* configuration option called "attachments_skip". That's a step in the right direction, although having an "attachments_allow" would be much better. You can add this option to config.yaml to provide a regular expression to recognize the attachments that should be skipped. If you want to allow only certain kinds of attachments, you can use a negative lookahead in the regular expression to negate it. Something like this should allow only PNG, JPG, and GIF files:
Essential for anyone trying to do automated processing of CPAN distributions, if you need to figure out the distribution name and version from the filename. It is based on hard-earned experience about the crazy ways in which authors name their files.
Originally I complained that the module was redundant because it seemed to duplicate functionality from the core File::Path module. However, the new versions of File::Remove have additional functionality that is worth mentioning, such as sending the deleted files to the OS-dependent "trash can", where they can be undeleted later.
This module does basically the same thing as the core Carp::longmess function. It does have some interesting additional features such as showing the context in which each function was called. However, I find disturbing that it doesn't even mention Carp::longmess in the documentation. I believe the docs should be fair and balanced and include other relevant modules in the See Also section, and say why they are better or worse.
Great for simplifying the handling of gzipped files, because it allows you to use the standard perl filehandle interface. However, you have to be careful and not take the filehandle analogy too far, as many standard filehandle methods are not supported. For example, $/, seek, and tell. This means that you can't slurp files using the conventional idioms, and that you can't pass the filehandle to other modules that expect a fully functional filehandle. Note that I don't blame the authors for these limitations, as they are a consequence of the limitations of the underlying modules and libraries.
For a more transparent alternative (but with its own caveats as well), you can consider PerlIO::gzip, but it requires perl 5.8.x.
I'm very unhappy that it doesn't support the standard PREFIX option. I use this option to install modules with CPAN.pm on my home directory and I'm very happy with the layout that it produces. When I tried to install a module that used Module::Build, everything became a big mess.
This program can give you a significant performance boost for CGIs (or other frequently executed programs) that take a long time to compile, without some of the headaches of mod_perl (of course, mod_perl allows you to do many other interesting things, but it is not always available).
For example, I had a CGI that used Template and Class::DBI, among other modules. It took at least 0.25 seconds to run because of the startup overhead. Just by changing the first line to #!/usr/bin/speedy, the runtime went down to about 0.013 s, a 20x improvement!
It seems to me that this module just complicates a simple thing (sorting). The call and options to make_sorter can be (to me) longer or harder to remember than just using sort directly in the first place. The documentation is very detailed and educational, however.
I really like this module because it allows me to do two things that I want:
1) Include in a distribution the modules that are only needed for testing so that the user doesn't have to install them.
2) Create "real bundles" that actually include everything so that they can be installed without a network connection.
The only problem for new users is that the documentation is not as complete or as clear as it could be. There is an article in The Perl Journal (June 2003) by Brian Ingerson that helps a lot, but it requires subscription.
I started using Parse::RecDescent, which is very convenient, but it ended up being too slow for my needs. Parse::Yapp is way, way faster. Writing the grammar may have been a little bit harder, but it was worth it.
I didn't have familiarity with yacc/bison, which is handy when using this module because the documentation often just says "it works like bison". But after looking at the bison docs, everything became more clear.
The best way I've found to convert POD to HTML in a reasonably flexible way. You can choose whether you want the whole file or just the body; whether you want an index or not; and you can override specific formatting methods (I find it's usually necessary to override the Link method). Another nice thing is that it includes a decent search.cpan.org-like stylesheet by default.
I have nothing against the content itself, but I find that such a huge, monolithic document is hard to use and slow to render. If it was published in CPAN as a module, presumably it's because it should be usable within perldoc. Imagine if the whole camel book were published as a single POD file! (Well, I guess some people would prefer it that way...)