Acme-CPANModules-Import-CPANRatings-User-stevenharyanto
view release on metacpan or search on metacpan
user page.
This list is generated by scraping CPANRatings (cpanratings.perl.org)
user page.
ACME::CPANMODULES ENTRIES
Log::Any
Author: PREACTION <https://metacpan.org/author/PREACTION>
(REMOVED)
Process::Status
Author: RJBS <https://metacpan.org/author/RJBS>
Provides a thin/lightweight OO interface for $?, much like what
Time::Piece does for localtime()/gmtime() or File::Stat for stat().
Of course, Real(TM) programmers shift and fiddle bits by themselves,
but for the rest of us this module is a nice convenience.
Archive::Any
Author: OALDERS <https://metacpan.org/author/OALDERS>
Nice idea, but the API needs to richer to be more useful (otherwise
one will still need to go to individual Archive::Tar, Archive::Zip,
etc). Currently the API provided are: listing files and extracting
all files. We can't: create archive, add more files, extract some
files only, find files, and so on.
Rating: 8/10
Devel::Confess
Author: HAARG <https://metacpan.org/author/HAARG>
Very nifty, it's like Carp::Always but with much more
options/features (so you don't need a separate Carp::Always::Color,
Carp::Always::Dump, and so on).
SQL::Statement
Author: REHSACK <https://metacpan.org/author/REHSACK>
The concept is truly cool, unfortunately the parser is currently
flaky/buggy: one SQL query might work but another valid and
seemingly simple SQL would fail with weird error message. See
distribution's RT queue. <br>
Rating: 6/10
PerlMongers::Hannover
Author: PTC <https://metacpan.org/author/PTC>
Instead of just printing some info, why not make it an Acme::PM or
Acme::PerlMongers like Acme::CPANAuthors? Various stats can then be
produced about the various Perl Mongers. <br>
App::multiwhich
Note that File::Which can also search for all matches too if you use
it in a list context, e.g. @paths = which('foo'). File::Which also
comes with a pwhich CLI utility which also accepts multiple
arguments and has the -a switch to print all matches. The output
format is slightly different than 'multiwhich' though. <br><br>In
fact, the Unix 'which' command (or at least its Debian variant) also
sports the -a switch.
Object::Anon
Author: ROBN <https://metacpan.org/author/ROBN>
Nice idea. Some notes: 1) to be widely used, it really needs to be
very efficient; 2) if the goal is simply to objectify a hash,
perhaps Hash::Objectify or Object::From::Hash or Hash::To::Object
(or Data::Objectify and so on) is a more descriptive name. <br>
Data::Seek
The "extremely fast and efficient" claim currently doesn't
hold, as this module creates a *whole* flattened tree for *every*
search operation. <br><br>A simple benchmark: <br><br>### <br> use
Benchmark qw(timethese); <br> use Data::Seek; <br> use Data::DPath
qw(dpath); <br> use JSON::Path; <br><br>my $data = { map { $_ =>
{map {$*=>[1..4]} 1..20} } "a".."z" };
<br><br>timethese(-0.25, { <br><br>dseek => sub { $ds =
Data::Seek->new(data=>$data);
$ds->search("j.1.\@")->data },
<br><br>dseek*cacheobj=>sub{ state
$ds=Data::Seek->new(data=>$data);
$ds->search("j.1.\@")->data },
<br><br>dpath=>sub{ dpath("/j/1/*")->match($data) },
<br><br>jpath=>sub{
JSON::Path->new(q[$.j.1.[*]])->values($data) }, <br> }); <br>
=head2 #
<br><br>### <br> Benchmark: running dpath, dseek, dseek_cacheobj,
jpath for at least 0.25 CPU seconds... <br><br>dpath: 1 wallclock
secs ( 0.27 usr + 0.00 sys = 0.27 CPU) @ 8292.59/s (n=2239)
<br><br>(warning: too few iterations for a reliable count)
<br><br>dseek: 1 wallclock secs ( 0.29 usr + 0.00 sys = 0.29 CPU) @
37.93/s (n=11) <br><br>(warning: too few iterations for a reliable
count) <br> dseek_cacheobj: 0 wallclock secs ( 0.33 usr + 0.00 sys =
0.33 CPU) @ 42.42/s (n=14) <br><br>(warning: too few iterations for
a reliable count) <br><br>jpath: 0 wallclock secs ( 0.27 usr + 0.00
sys = 0.27 CPU) @ 11711.11/s (n=3162) <br><br>(warning: too few
iterations for a reliable count) <br> =head2 #
<br><br>Also: 1) the syntax is rather inconsistent: ':n' for array
index access, but '.@' (instead of ':@') for grabbing all elements.
2) currently cannot select subtree (must always select leaf node).
<br><br>As alternatives, I recommend the much simpler JSON::Path, or
the more powerful Data::DPath. <br>
Games::2048
Author: BLAIZER <https://metacpan.org/author/BLAIZER>
My favorite 2048 implementation (it's text-mode, written in Perl,
uses my module Color::ANSI::Util, and what else... oh yeah, it's the
only implementation where I've reached 2048 :-) ). <br><br>One tip:
enlarge the fonts of your terminal emulator (e.g. Ctrl-+ on Konsole)
until it's big and convenient enough.
App::D
Author: BESSARABV <https://metacpan.org/author/BESSARABV>
As an alternative, one can also do: <br><br>alias d=' <br><br>TZ=UTC
date; # show date in UTC <br><br>date ; # show date in local
timezone <br><br>cal -3 ; # show monthly calendar for curmon-1,
curmon, curmon+1 <br> ' <br><br>
Getopt::Long
Author: JV <https://metacpan.org/author/JV>
Having worked for quite some time with option processing and several
other similar modules, I have to say that most of the time you
probably want to use Getopt::Long instead of the other alternatives.
Or at least pick the alternatives which are based on Getopt::Long,
instead of those that reinvent the wheel and do their own option
parsing. <br><br>Most other modules that reinvent option parsing
either don't bother to do short option bundling (-abc instead of -a
-b -c), or abbreviation (--long-o instead --long-option-name), or
the choice to (dis)allow mix-mashing options and arguments, or
support '--' to end option processing, or respect ordering, or
support multiple options (--verbose --verbose), or support
'--foo=val' *as well as* '--foo val', and so on. These are features
and conveniences that are taken for granted by people working daily
in Unix command-line. <br>
Text::Table::Tiny
Author: NEILB <https://metacpan.org/author/NEILB>
Very fast, several times faster than Text::TabularDisplay or
Text::Table (and many times faster than the other slower
table-generator modules). It uses sprintf() to format a whole row
instead of formatting each cell separately using sprintf() and
joining cells together with join(). <br><br>I did a comparison in:
<a
href="http://blogs.perl.org/users/steven_haryanto/2014/07/benchmarki
ng-several-ascii-table-generator-modules.html"
rel="nofollow">blogs.perl.org/users/steven_haryanto/...</a>
Mo Author: TINITA <https://metacpan.org/author/TINITA>
A great alternative when Moo is a bit too much for you. Useful for
scripts that must start really fast. Mind you, Moo loads about 5K
lines of code and more than a dozen files, all of which takes +-
10ms on my computer. Mo on the other hand is only a single line of
+-500 characters, and it's inlinable. It loads in under 1ms. If a
script must be executed thousands of times a day, that 9ms
difference will matter more. <br><br>I use this for a very
lightweight parent class. A richer subclass then uses Moo.
<br><br>Isn't it great that we have the choices and upgrade path
from the very minimal Mo, to Moo for normal cases, to Moos and Moose
for even richer (but heavier) alternatives. Truly TIMTOWTDI! <br>
App::ChangeShebang
Author: SKAJI <https://metacpan.org/author/SKAJI>
Given that the name of this module/app is "change shebang"
(instead of "change shebang to samedir perl") perhaps this
app can be made more generic? For example, I've had to change all
shebangs from "#!/usr/bin/env perl" to "#!perl"
and vice versa. Perhaps this module/app can become a tool to easily
switch between shebangs. <br>
Hash::Ordered
Author: DAGOLDEN <https://metacpan.org/author/DAGOLDEN>
Overall looks ok, with the exception that it does not look and feel
like a regular Perl hash at all. Now someone just needs to create a
tie interface on top of this :) <br>
App::whatthecommit
Author: MUDLER <https://metacpan.org/author/MUDLER>
From the description: "App::whatthecommit is just another
lazy-to-lazy line command utility." I'd thought the definition
of laziness would be something like 'alias gc=git commit
--allow-empty-message'. This is more like hubris. Or whatever. :)
<br>
Opt::Imistic
Author: ALTREUS <https://metacpan.org/author/ALTREUS>
Very nifty for short scripts and some clever design inside (all
options are stored as arrayref, but there is some overloading to
make getting boolean/flag and normal scalar value convenient).
2010-10-13: <br><br>I admit, this is not the most flexible
configuration framework out there as it enforces some convention.
And I don't/can't use it on every project. But it's certainly one of
the easiest. You can slap a few lines of options declaration in your
code and voila, your script suddenly can accept command line
arguments, has --help message et al, read from config files (in
several preset locations). <br><br>There are still a few annoyances
(I submitted them in the RT), but in general, this is a very handy
module to use for lazy coders who just want to accept
configuration/options from outside the code. <br><br><shameless
plug>I'm trying to do somewhat the same with Config::Tree, but as
of now the module is not really done yet.</shameless plug>
<br><br>UPDATE 2013-08-15: <br><br>I'm reducing the ratings from 5
to 2. I've now avoided using this module due to two lingering issue
since 2010: 1) App::Options does not accept '--opt val', only
'--opt=val' which is incompatible with how most command-line
programs work, causing confusion for some of my users. 2) 'perl -c'
doesn't work under this module, it will still trigger command-line
processing. <br><br>I'm now using Perinci::CmdLine as replacement,
but I cannot recommend it in general, as the two modules are not
equivalent.
Rating: 4/10
Filesys::Notify::Simple
Author: MIYAGAWA <https://metacpan.org/author/MIYAGAWA>
It's rather unfortunate that currently the choice for general
purpose cross-platform filesystem notification modules on CPAN falls
between this module (FNS) or File::ChangeNotify (F::CN). The other
CPAN modules are either OS-/framework-specific. <br><br>FNS has a
simple API but is perhaps too simple for some uses, while F::CN uses
Moose and has a big startup overhead. <br><br>If you simply want to
check from time to time whether a change has occured, you need to
wrap the wait() method with alarm(). And I found on my Linux PC that
I need a timeout of at least 3 seconds for this to work reliably.
Rating: 8/10
experimental
Author: LEONT <https://metacpan.org/author/LEONT>
Vote +1 to add this to core. Please make coding in Perl 5 relatively
painless.
MIME::Lite::HTML
Author: ALIAN <https://metacpan.org/author/ALIAN>
Very straightforward to use (I needed to send a URL/webpage as HTML
email with embedded images/objects). With this module I can finish
my job with only a few lines of Perl in 3-5 minutes (searching for
this module in CPAN takes more than that! searching using "mail
web" or "email url" at first didn't get results).
<br><br>Blackberry is having trouble displaying the resulting email
though. No problem with Gmail or Thunderbird/Icedove.
Term::Size
Author: FERREIRA <https://metacpan.org/author/FERREIRA>
5-year old bug like RT#38594 still present. Use one of the alternate
implementations like Term::Size::{Unix,Win32,ReadKey}. <br>
Rating: 2/10
DateTime::Format::Flexible
Author: THINC <https://metacpan.org/author/THINC>
While it doesn't cover as much phrases as DateTime::Format::Natural,
at least it's simpler to translate (and the dist already includes a
couple of translations). BTW, I think like in the POD of
DateTime::Format::Natural, it needs to list which phrases it
supports. And probably add more :-) <br><br>
Rating: 8/10
DateTime::Format::Natural
Author: SCHUBIGER <https://metacpan.org/author/SCHUBIGER>
I'm giving DateTime::Format::Natural 3 stars because while it's
great for English (it covers more phrases than
DateTime::Format::Flexible), it's also hard to translate. Look at
the source code for DateTime::Format::Natural::Lang::EN: lots of
Englishisms and weird structures (%grammars). Wonder why so far
there has not been any translations to another language? <br>
Rating: 6/10
App::sourcepan
Author: PEVANS <https://metacpan.org/author/PEVANS>
Thanks, just what I needed. (I was hoping cpanm would accept my
--download patch, but this is just as well). <br><br>It still uses
CPAN.pm and thus downloads the relatively big 01mailrc.txt.gz and
02packages.details.txt.gz file, thus slowing the first use. If you
use cpanm exclusively, this is rather annoying especially if you're
on a slow link.
Rating: 8/10
Text::ASCIITable::TW
The method of determining visual width of Chinese characters is
rather hackish. Text::ASCIITable should perhaps use Text::CharWidth
(which can be used to determine visual width of text in other
languages e.g. Japanese, etc) thus rendering this module
unnecessary. <br>
Text::VisualWidth
Author: NANZOU <https://metacpan.org/author/NANZOU>
Also look at Text::CharWidth for an alternative that can be used
with text in other languages (Chinese, etc). <br>
Text::VisualWidth::PP
Author: TOKUHIROM <https://metacpan.org/author/TOKUHIROM>
Also look at Text::CharWidth for an alternative that can be used
with text in other languages (Chinese, etc). <br>
Taint::Runtime
Author: RHANDOM <https://metacpan.org/author/RHANDOM>
/usr/share/file/magic (bug first filed in RT 4 years ago).
<br><br>The currently recommended module in this area seems to be
File::LibMagic. Other alternatives include File::MMagic (slow and
buggy, no longer maintained), Media::Type::Simple (only maps MIME
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>
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
because I would otherwise switch.
Rating: 8/10
( run in 1.566 second using v1.01-cache-2.11-cpan-ff9377addf4 )