Rate a distribution
Find a distribution you would like to review:
Recent reviews (RSS feed)
It takes arrays as subroutine arguments which will result in slowness when the data is huge. I strongly advise metacpan.org/pod/List::MoreUtils as an alternative.
Use Digest::SHA instead. In general, there is no reason in using Digest::SHA1 over Digest::SHA. The latter is a core Perl module, more updated, and implements the other algorithms while the former only implements SHA-1 which is now deprecated.
The "checksum" (basically just adding 16-bit words) is too simplistic to be a real checksum or to be practically useful. Even MD5 or CRC32 is infinitely better.
Big dependency tree having to install Moose. Otherwise, it just works. Good (complete) example file helps a lot. Thank you!
Excellent approach. This module as simplified the code I use to access MongoDB tremendously.
I've been trying to debug an issue with a CPAN module which was shown up by CPAN testers. At the moment, the testers' reports are not available on the web. The problem seemed to be with older versions of Perl, but despite much effort I was unable to install them to find out what was wrong. I have never installed or even tried perlbrew before today, but in desperation I tried it out.
Thanks to perlbrew I was able to install a Perl 5.12.5 and find the errors in my CPAN module very quickly. I'm very impressed with how easy it was and how it managed to install the old version of Perl on my system where I wasn't able to. The whole system of shell replacements is just ideal for this kind of work.
Very good job! Thanks.
Before this package was adopted by a new author, I believe it was a good option for dealing with JSONRPC APIs. As it stands now, people writing Perl client software for JSONRPC are not as well served as they used to be. The module has deprecated JSON::RPC::Client, renamed that to JSON::RPC::Legacy::Client and pegged it to JSONRPC v1. I would guess that more people write client code than set up servers, so this is an odd direction to go. Such is life, however.
I recently needed to write some code to communicate with a production service that offers a JSONRPC v2 interface. Looking around, the best option I could find was LWP::UserAgent + JSON::RPC2. Based on prior experience with JSON::RPC I had not expected to roll my own client, and I was not particularly happy about it. I have not rated this package since I did not use it, and just leaving this as a comment.
Still works, partially, but in general out of date. For example, to get post the deprecated metaWeblog.getPost API method is still used instead of the newer wp.getPost call (which understandably is only introduced in WordPress 3.4, while this module is last updated with WordPress 2.8.4). And apparently wordpress.com doesn't return post_content anymore when you use metaWeblog.getPost.
Luckily, performing XMLRPC request directly is easy enough. Just use XMLRPC::Lite and peruse the Wordpress documentation here: codex.wordpress.org/XML-RPC_WordPress...
I'd have loved DBIx integration, though I understand why that wouldn't work out the same.
It's simply the best way to visualize the perl variable. Sorted keys, color and many more.
This module is essentially a super-optimised PSGI server. Although this sort of micro-optimisation is not necessarily useful for most web applications, the way this module works is very interesting and might have some great niche applications.
EDIT: My previous review stated that this module was not being maintained, but now AUDREYT is fixing the outstanding issues and merging pull requests, so that is no longer a concern.
Any drawback to say is that, it supports OO method only. Should be great if functions are allowed to call in procedural method.
While the documentation could be vastly improved, this is still a fantastic tool if you can get it working.
It uses the Google Discovery API to allow you to interact with most (all?) Google APIs with a single, consistent interface.
My new favorite Levenshtein distance module. It's as fast (if not faster) than Text::Levenshtein::XS and can provide a speed boost if you don't care about distances above a certain limit. Which I think in many cases is true.
An excellent debugging and exploration tool. My first run on one of my modules showed me things I didn't expect, and that I'll probably fix soon. I look forward to using it more.
Great and all, but one drawback is that it currently destroys original file's formatting in serialize().
Any module from ADAMK should be interesting, including this one. But please take a look at CPAN::Changes for the de facto standard nowadays.
Like Module::Changes, this module also tries to use a more defined format for Changes. Sadly, it has not caught on. Please also take a look at CPAN::Changes which seems to be the de facto standard nowadays.
In general I'm not opposed to the idea of this module. The included 'changes' script is also pretty cool (which I'm trying to recreate, for CPAN::Changes).
Just pointing out that I believe this module has not really "caught on" among the CPAN community. What has, is, CPAN::Changes which is followed by many authors and even employed on MetaCPAN.
Not even working. I don't see changes tool after installed.
metacpan.org/pod/distribution/Module-... is the doc I follow.
To be honest. It became useless as soon I realized you write an own constructor. I think this is not needed to make a setter / getter.
It is nice you provide it, but it must be optional.