Acme-CPANModules-Import-CPANRatings-User-stevenharyanto
view release on metacpan or search on metacpan
type from/to file extension).
Rating: 4/10
File::MMagic
Author: KNOK <https://metacpan.org/author/KNOK>
Works for basic usage, but has quite a few problems. Plus it is not
very performant. Doesn't seem to be maintained anymore. <br><br>The
currently recommended module in this area seems to be
File::LibMagic. Other alternatives include File::Type (gives less
useful results), File::MMagic::XS (also not actively maintained?
long standing bugs like failure to parse system magic file still
persists), Media::Type::Simple (only maps MIME type from/to file
extension). <br>
Rating: 4/10
File::Type
Author: PMISON <https://metacpan.org/author/PMISON>
As another reviewer has said, this module tends to conclude
"application/octet-stream" for many kinds of files, making
it not very useful. <br><br>The currently recommended module in this
area seems to be File::LibMagic. Other alternatives include
File::MMagic (slow, has quite a few bugs, no longer maintained),
File::MMagic::XS (also not actively maintained? long standing bug
like failure to parse system magic file still persists),
Media::Type::Simple (only maps MIME type from/to file extension).
<br>
Rating: 2/10
Time::Mock
Author: EWILHELM <https://metacpan.org/author/EWILHELM>
Balancing previous 1 rating by @Ingo. <br><br>To Ingo: You said
module's documentation is okay, one feature you use works okay, and
other features you don't use. Why only 1 star then? <br><br>This
module is a worthy alternative to Test::MockTime. It offers extra
features such as working across forks, mocking Time::HiRes
(eventually), and speeding/slowing down time.
Sakai::Stats
Release early, release often indeed. First you release nothing but
boilerplate :)
Rating: 2/10
Spreadsheet::Perl
Author: NKH <https://metacpan.org/author/NKH>
Good documentation. All modules' documentation should similarly
strive to contain at least: rationale for existence, pointer to
alternatives, and task-oriented organization.
Unix::PasswdFileOps
Author: BMAYNARD <https://metacpan.org/author/BMAYNARD>
Less-than-descriptive name (module's main function seems to be
sorting entries, can't be guessed from the name). No unit tests.
Doesn't handle /etc/shadow. Also, it might be useful to explain why
one needs to sort entries in passwd file. <br>
Rating: 4/10
Array::Diff
Author: NEILB <https://metacpan.org/author/NEILB>
Yes, simple and gets the job done. Though I'm a bit curious with the
implementation. If the interface is only to get number of deleted
and added items (instead of positions of deletion/insertion), why
depend on Algorithm::Diff (or use the name 'diff', for that matter).
<br>
DZ1 Why do we need this uploaded to CPAN?
Rating: 2/10
Passwd::Unix
Author: STRZELEC <https://metacpan.org/author/STRZELEC>
No tests. No detailed error status, only true/false (yes, there is a
'warnings' parameter on constructor, but this doesn't give out
warnings on all operations, only some). No locking (although there
is backup, but still). <br><br>Also, some weird choices, why use
bzip2 when creating backup? Or, why still require running as root
(checking $() if we are allowing custom database file location?
<br><br>Between this and Unix::ConfigFile, I'm seriously considering
using Unix commands instead (useradd, userdel, gpasswd, et al).
<br><br>UPDATE 2011-04-21: I created a fork of Passwd::Unix 0.52
called Passwd::Unix::Alt instead, which add some tests and
modifications. Try it out if your needs are also not met by
Passwd::Unix. <br><br>UPDATE 2012-08-30: I created a new module
called Unix::Passwd::File. Try it out if your needs are also not met
by Passwd::Unix.
Rating: 2/10
Unix::ConfigFile
Author: SSNODGRA <https://metacpan.org/author/SSNODGRA>
Outdated module that doesn't handle /etc/shadow and /etc/gshadow.
Rating: 2/10
lib::xi
Author: GFUJI <https://metacpan.org/author/GFUJI>
Handy module for installing dependencies. There are previous
efforts, but the arrival of cpanm makes autoinstall process less
tedious, so hats off also to the creator of cpanm. <br>
Capture::Tiny::Extended
Author: MITHALDU <https://metacpan.org/author/MITHALDU>
Indispensable. Provides nice enhancement to Capture::Tiny
(particularly the real-time teeing). <br>
google_talk_bot
Improperly packaged, improper POD formatting, bot messages hardcoded
in script, and yes... idiotic license. Basically a "trial"
script to bait users into consultation gig. CPAN is not a place for
this kind of thing. Please try again. <br>
Rating: 2/10
Clone::Any
Author: EVO <https://metacpan.org/author/EVO>
Using Clone::Any nowadays is more trouble than it's worth.
<br><br>First, there are annoying incompatibilities between cloning
modules. Most notably Storable, which is the default cloning module
if Clone is not available, *still* doesn't support storing Regexp
objects out-of-the-box after all these years. <br><br>Second, this
module has not been updated for a long time and newer alternatives
like the fast Data::Clone is not recognized. <br><br>Right now I'm
replacing all code from using Clone::Any code to Data::Clone.
<br><br>
Rating: 4/10
Array::OrdHash
Author: WOWASURIN <https://metacpan.org/author/WOWASURIN>
Fun module to play with, especially for those among us infected with
a bit of PHP envy (me, never!). <br>
Bash::Completion
Author: MELO <https://metacpan.org/author/MELO>
Clean code, plugin interface simple to use, but implementation needs
to be improved. For example, parsing $ENV{COMP_LINE} &
$ENV{COMP_POINT} into @argv is done simplistically using
split(/\h+/), without regard to shell's quotes/escapes.
(Getopt::Complete's way is somewhat better by invoking shell, but it
also has its problems. I guess in this regard external programs are
second-class citizens to shell functions because they don't get the
equivalents of COMP_WORDS/COMP_CWORD). <br>
Rating: 6/10
Bash::Completion::Plugins::cpanm
Author: PERLER <https://metacpan.org/author/PERLER>
Cool, except that with cpanm I often install local distribution
(cpanm Foo-Bar-1.23.tar.gz). Perhaps the completion can look in the
filesystem first before firing API request. Also, might be nice if
there is some caching because it seems to be slow (at least from
where I am). <br>
Rating: 8/10
Switch
Author: CHORNY <https://metacpan.org/author/CHORNY>
With all due respect to the author, Switch is no longer necessary in
5.10+ as 5.10+ already introduced smart matching and given().
given() is superior because it doesn't introduce compile-time
overhead, doesn't mess line numbers, and should be faster (simply
because smart match is fast, and Switch is not utilizing it).
<br><br>You have been using 5.10+, right? (Since 5.8 is no longer
officially supported) <br>
Moo Author: HAARG <https://metacpan.org/author/HAARG>
Last week I ported an application from Mouse (Any::Moose) to Moo.
Went without a hitch (well I did replace "with 'X', 'Y',
'Z';" to "with 'X'; with 'Y'; with 'Z';" as
instructed in the Moo documentation). Startup time decreased
significantly. Planning to move every Moose apps to Moo. Splendid!
<br>
Sub::StopCalls
Author: RUZ <https://metacpan.org/author/RUZ>
Cool idea, if a bit extreme. <br><br>If computing a value is
expensive, there's Memoize for the caller. On the callee side, you
can cache the result (there's state variable in 5.10+ so it's dead
simple to use). <br><br>So I believe Sub::StopCalls is only
necessary if you find the overhead of the sub call itself to be a
bottleneck. And if that is the case, perhaps you should refactor the
calling code anyway.
Rating: 8/10
Log::Log4perl::Tiny
Author: POLETTIX <https://metacpan.org/author/POLETTIX>
5 stars solely for the idea (I'm beginning to love the ::Tiny
movement more and more these days). Haven't actually tried it
though, but I bet many Log4perl users, me included, mostly only use
easy_init. As much as Log4perl is mature and fairly optimized, it's
still a relatively "huge" library. Nice to know there's a
drop-in ::Tiny replacement.
SHARYANTO::YAML::Any
Re: Blue. I guess I shouldn't release this. I need something quick
to fix our application, so this is not really something meant for
public use. Will be purging this from PAUSE. <br>
SQL::Easy
Author: BESSARABV <https://metacpan.org/author/BESSARABV>
IIRC, there has also previous similar attempt like this. Modules
like these are not necessary, as DBI already has something
equivalent (and even better): selectrow_{array,hashref,arrayref} and
selectall_{array,hash}ref. <br>
Rating: 2/10
CGI::Struct
Author: FULLERMD <https://metacpan.org/author/FULLERMD>
Cool, will definitely try this out the next time I write another
form processing CGI script. Although the module is named CGI::,
there's nothing CGI-specific about it, and that's good. So this
module is basically a "path-expander" for hash values.
<br><br>Btw, one thing I use rather often in PHP is naming parameter
as "foo[]" which will automatically add elements to the
$_REQUEST['foo'] array. Perhaps this feature can be considered too.
DateTime::BusinessHours
Author: BRICAS <https://metacpan.org/author/BRICAS>
Just tried it. It works, but the module/dist is not in the best
shape: <br><br>* Test fails (pod-coverage, error in POD) <br><br>*
dependency on Class::MethodMaker not yet specified <br><br>*
Documentation: Synopsis contains mistake (class name is
DateTime::BusinessHours not BusinessHours), the name '$testing' is
not very suitable, there are typos. <br><br>* Style-wise, method
naming is "joinedwords", while in DateTime families it's
"separated_words" (not a big deal though). <br><br>
Rating: 6/10
Bundle::Dpchrist
Every once in a while everyone of us encounters a programmer that
disregards existing reusable code and creates his/her own
"standard library" for everything, from trimming string to
creating random number to cleaning the kitchen sink. We all might
have been one too, at one time or another. I'm not saying that this
bundle is a case of the above, but it's giving me a similar feeling.
:-) <br><br>A commendable effort, David. But there really are a lot
of wheels being reinvented here.
Net::BitTorrent::File
Author: ORCLEV <https://metacpan.org/author/ORCLEV>
I mass download stuffs by putting a bunch of torrent files in a
directory on the server and let rtorrent takes care of them. With
this module I can quickly whip up a short script to calculate the
total size of the downloadable files so I can be pretty sure that
when I leave my server for days/weeks, I don't run out of disk space
because I put in too many torrent files. <br>
Module::CoreList
Author: BINGOS <https://metacpan.org/author/BINGOS>
self-rate-limiting and uses the Firefox or IE engine? A subclass
exists for each feature, but how do you use them together?
WWW::Mechanize needs to be more role/plugin-oriented instead of
inheritance-oriented. <br>
Mail::Sendmail
Author: NEILB <https://metacpan.org/author/NEILB>
I used Mail::Sendmail and a few others "older" modules
back from the days when it didn't support setting envelope sender
different from RFC From, and when the test hung on some dead host.
<br><br>If it's still working for you, great. I personally have
moved on to other modules like Email::Sender::Simple, which
abstracts sending mechanism (transport) and support SMTP auth, for
two. Also, many of the guide/documentation for Mail::Sendmail are
not quite up to date in style (though they still might work), for
example the low level way of building HTML email. Also, the
Changelog file doesn't seem to be maintained?
Rating: 6/10
autodie
Author: TODDR <https://metacpan.org/author/TODDR>
I started using autodie in almost all of my applications a few
months ago. It's somewhat of a mixed blessing. For existing
applications, it can break things and making things less robust,
solely because old code are not built with autodie in mind.
<br><br>But the best thing about it is that it's lexically scoped,
so for sections of code that you're not sure about, just sprinkle
'no autodie' to get the old behaviour. <br><br>It should be used on
probably 95% of code out there. For the rest of the cases, where you
need to report the status of each I/O operation, it's obviously more
convenient to check $? instead of trapping exception everytime.
<br><br>+1 for getting it into core. <br>
App::FileTools::BulkRename
Disclaimer: I maintain a "competitor" module, App::perlmv.
Apparently a lot of people, like me, likes to rename files using
Perl. And the examples in the documentation are about renaming movie
files too, something which I do a lot :) <br><br>I applaud Stirling
Westrup for taking a legacy script and improving it. May we have a
lot of ideas to borrow from each other. <br><br>This is an early
release, there are quite a few things I find lacking. Most
importantly, I suggest adding a test suite as soon as possible. The
filesystem differences can be tricky, and CPAN Testers can help
providing feedback. <br><br>Keep up the good work.
Rating: 8/10
Script::State
Author: MOTEMEN <https://metacpan.org/author/MOTEMEN>
Nice idea, straight and simple interface. A better name could
perhaps be chosen? Documentation should be expanded, e.g. to warn
users about security, since Data::Dumper a.k.a. eval() is used to
load variable content. Also, the implementation does not yet
consider file locking.
PathTools
I guess File::Spec's API is sane enough, but I suspect not a lot of
people are using it because there's not enough incentive for it.
When 99% population of the world use Unix/Linux/Windows (even Macs
been technically Unix for a number of years), "/" works
everywhere and using File::Spec does not gain you anything except
lots of typing exercise. <br><br>That's why I think Path::Class
might have a better chance of succeeding. It gives niceties like a
few more convenience methods, a shortcut of getting dir & file
object from each other, etc. It gives users more incentive of using
a proper path manipulation library because it gives extra stuff
along with that. It should also be in core to accompany File::Spec.
Rating: 8/10
File::Slurp
Author: CAPOEIRAB <https://metacpan.org/author/CAPOEIRAB>
I've been using File::Slurp for years and is generally satisfied
with it. However reading the negative reviews today and looking at
its RT queue, I realize that this module is broken for many and is
effectively abandoned by the maintainer (no new releases for almost
3 years now despite several RT items labeled as critical). So I
suggest others checking out the alternatives.
Rating: 2/10
Log::Log4perl
Author: ETJ <https://metacpan.org/author/ETJ>
It's a very mature and an excellent logging framework. However, some
of the common minor complaints are: 1) It's too complex. I agree: it
should not be this hard to get started. 2) Configuration is too
verbose. Agreed: but well, what can you do, most things from Java is
a bit overengineered and verbose anyway. At least you can do almost
anything with the configuration. 3) It's not very Perlish. Also
agreed. 4) Performance. My note: speed is not an issue in majority
of the cases and Log4perl's performance is adequate for most of the
rest of the cases. For faster/leaner alternatives you might want to
take a look at Log::Fast, but a lot of Log4perl's features are
missing. <br><br>One of the main strengths of Log4perl is its
sublogger/subcategory feature, which few other frameworks seem to
have. <br><br>For other alternatives, also take a look at:
Log::Handler, Log::Any. And of course Log::Message too. <br>
Log::Handler
Author: BLOONIX <https://metacpan.org/author/BLOONIX>
This review mostly compares Log::Handler with Log4perl, which is a
mature and one of the most popular logging frameworks. <br><br>I
think Log::Handler's interface is much simpler, nicer, more Perlish
than Log4perl. It's a bit similar to Log::Any::App, which I created
just because I hate Log4perl configuration. <br><br>There is a
unique concept of maxlevel not normally found in other frameworks,
though it can be emulated in other frameworks using filters.
<br><br>At a quick glance, the speed is around twice that of
Log::Log4perl, so I'll say it's on the low-end side (there are other
much faster logging modules, but anyway speed is not an issue to
most people). <br><br>It currently lacks sublogger (hierarchical
categorization and adjustable/automatic appending of subcategory to
its parent), so it cannot be used to replace Log4perl in most cases
as that's one of the main feature of Log4perl. Which is a pity
features, like dealing with line continuation, case sensitivity,
default section, multiline/array, deltas, etc. So for now, despite
all of its quirks, this module is still hard to beat.
<br><br>There's another nice little INI module that can do
read/set/delete/unset (instead of just read/dump): Prima::IniFile,
but it is included in a totally unrelated distribution.
Rating: 8/10
DateTime
Author: DROLSKY <https://metacpan.org/author/DROLSKY>
Amidst all the glowing reviews may I add a reminder that, as with
everything, there's a catch: runtime performance. On my PC, the
speed of creating a DateTime object is just around 6000/sec. If you
use DateTime intensively, it can quickly add up. <br><br>Imagine
serving a web page that fetches 50 rows from database, where for
convenience you convert each date column to a DateTime object, and
you have 120 requests/sec coming in... That's already 6000 objects
(an extra second!). <br><br>Which is unfortunate because DateTime is
so wonderful, convenient, correct, complete and all that. So one
approach you can use might be to delay converting to DateTime object
until necessary.
Date::Manip
Author: SBECK <https://metacpan.org/author/SBECK>
Wow, there are surely a lot of negative reviews ... <br><br>First of
all, Date::Manip has a long history. I used this module back in
2001-2002, IIRC. Back then it was *the* swiss army of date/time
manipulation, something you use when you want the most
flexible/complete thing in Perl. True, it's slow, but it works.
<br><br>But then things change. DateTime project was started, and
now it is somewhat the de facto standard. It's more modern and far
more modular than the monolithic Date::Manip (every timezone and
language support and parsing/formatting modules shipped in one
single distribution). <br><br>And then there's the 5.x -> 6.x
debacle. As someone who also sprinkle Perl 5.10 requirements to his
CPAN modules, I can feel for the author. But the difference is, most
of my modules are not that widely used/known, and also many start
its life already requiring 5.10 right from its first released
version. While in Date::Manip's case, this happens to a very widely
used module. Surely backwards compatibility should be considered
more. <br><br>All in all, you are free to use or not use
Date::Manip. There are other alternatives. Pick wisely. <br>
Rating: 6/10
App::pmuninstall
Author: XAICRON <https://metacpan.org/author/XAICRON>
One would wonder why CPAN clients still don't have this crucial
feature Though you see Miyagawa listed in the Credits so maybe
cpanminus or its sister will end up having this functionality? One
can only hope. At 0.06, some things are not working flawlessly
(submitted in RT). Keep up the good work! <br><br>
App::lntree
Author: ROKR <https://metacpan.org/author/ROKR>
I guess this app is still useful, since "cp -sR" still
doesn't work as many would expect, and there are Windows users out
there (yes, newer NTFS does support symlinks; though I don't know
whether this module supports creating symlinks on NTFS). <br><br>A
minor comment would be on the name, maybe lnstree can be considered
instead (since "ln" indicates hardlink, at least for me).
Btw, there's also a free software called "lns" to do the
exact same thing. <br><br>
Data::Clone
Author: GFUJI <https://metacpan.org/author/GFUJI>
I've never encountered difficulty in cloning data structures in
Perl, usually I just use Clone or sometimes Storable's freeze + thaw
(the later does not yet support cloning Regexp objects out of the
box). <br><br>However, I like Data::Clone for its speed! It's
several times faster than Clone or freeze+thaw. So hats up. Planning
to use Data::Clone in future projects. <br><br>Now if we can
convince Goro to write a fast serializer/deserializer with compact
output (essentially, a faster version of Storable), that would be
even nicer :-) <br><br>
Data::Pond
Author: ZEFRAM <https://metacpan.org/author/ZEFRAM>
With due respect to the author, I fail to see the practical point of
Pond. Pond (Perl-based open notation for data) is the Perl
counterpart of JSON, except that implementation is currently only
available in Perl (CMIIW), and "Pond represents fewer data
types directly". <br><br>Pond is pitched against Data::Dumper +
eval, which is dangerous, but Data::Dumper + eval is by far not the
only method available for serialization. Perl can do Storable, JSON,
YAML, even PHP serialization format. <br><br>The documentation does
not show what Pond looks like. <br><br>One cute thing about Pond is
that you can check Pond syntax using a single regex. But apart from
that, there's nothing compelling in using Pond to serialize data.
Rating: 4/10
File::Which
Author: PLICEASE <https://metacpan.org/author/PLICEASE>
You can always count on CPAN to have prewritten modules for various
things, including this one. I've never bothered before about
portability and just rely on the "which" command, but for
one reason there's a time when I just couldn't do that. <br><br>Btw,
there's also File::Which::Cached.
String::ShellQuote
Author: ROSCH <https://metacpan.org/author/ROSCH>
I admit it. Ever since I know about escapeshellarg() and
escapeshellcmd() in PHP, I've been reimplementing this function in
Perl literally a million of times (mostly because of laziness and
because it only takes a couple of lines in Perl). Only a few months
ago after the millionth time I said enough is enough and started to
look around in CPAN, and found this module. <br><br>The only problem
for this module is lack of visibility. Before I've never read
articles or blog posts mentioning this module, ever. Yes, we have
system() that can bypass the shell, but qx() can't. So yes, this
module needs to be marketed more! <br>
( run in 3.870 seconds using v1.01-cache-2.11-cpan-a49fcb8fa48 )