Acme-CPANModules-Import-CPANRatings-User-stevenharyanto
view release on metacpan or search on metacpan
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).
<br><br>For more "proper" scripts though (anything above
say 20-30 lines) I'd recommend using something like Getopt::Long
with a real spec. Some of the features I like in G::L not in
Opt::Imistic: the ability to get --noOPT for free for flag options,
the ability to configure permute/no_permute (mix mashing options
with arguments), some data validation, and of course:
autoabbreviation of long option names, which requires a spec after
all.
Devel::STrace
Author: DARNOLD <https://metacpan.org/author/DARNOLD>
The doc looks promising, it really looks like it could be the
"strace for Perl functions", but the usage is awkward (you
have to open two terminals, one for running your program and
producing trace file, and another for reading this file). And I'm
probably an idiot, but I can't get this module to work for me.
<br><br>One alternative if you're looking for a similar module is
Debug::LTrace. <br><br>
Devel::TraceSubs
Author: PARTICLE <https://metacpan.org/author/PARTICLE>
For an alternative, try Debug::LTrace, which roughly provides the
same basic feature but is more convenient to use from the
command-line and give extra information like timing. <br><br>
Devel::TraceCalls
Author: COSIMO <https://metacpan.org/author/COSIMO>
Might be powerful and flexible, but not convenient to use especially
from command-line. (I was searching for something like "strace
for Perl function"). <br>
Debug::LTrace
Author: KOORCHIK <https://metacpan.org/author/KOORCHIK>
One of the more convenient and usable subroutine tracing modules on
CPAN. If you're looking for something like "strace for Perl
functions", try this. <br>
Debug::Trace
Author: JV <https://metacpan.org/author/JV>
Good module, but try its derivative Debug::LTrace instead.
Debug::Trace doesn't fake caller() yet so traced/wrapped subroutines
get caller() results that are "off-by-1" (see
Hook::LexWrap). Plus, Debug::LTrace gives more information like
timing. <br><br>
App::Trace
Author: SPADKINS <https://metacpan.org/author/SPADKINS>
The name and abstract is slightly inaccurate/misleading. This module
is supposed to be a general logging framework instead of just
subroutine entry/exit tracer. For alternative subroutine tracer, I'd
recommend Devel::TraceSubs or Devel::TraceCalls (or even
Devel::Trace + variants). <br><br>Not very convenient to use. It
still requires you to put 'if $App::Trace' clause everytime. For
general logging that can be switched on/off upon runtime, I'd
recommend using Log::Any instead. <br><br>Lastly, this module is
tied to App::Options and thus only really usable if you use both.
A nice, minimalistic, terminal-based user interface for browsing
your database and tables. Might be useful for simple cases.
<br><br>It would be *much* more useful if usernames/passwords,
queries, and other settings can be saved in a config/session file.
<br>
Locale::Maketext
Author: TODDR <https://metacpan.org/author/TODDR>
Users might want to check out this article on why one should perhaps
use Locale::TextDomain instead of Locale::Maketext: <a
href="http://www.perladvent.org/2013/2013-12-09.html"
rel="nofollow">www.perladvent.org/2013/2013-12-09.html</a>
Curses::Toolkit
Nice effort, but one might also want to look at Tickit, which is not
curses-based and looks more promising. Being based on Curses, this
module still suffers from the many bugs and limitations of curses.
The lack of Shift-Tab support, for one. <br><br>See also: <a
href="http://www.perlmonks.org/?node_id=1059926"
rel="nofollow">www.perlmonks.org/?node_id=1059926</a> <br><br>As I
explore doing TUI more, I will update the reviews. <br>
Moo::Lax
Author: DAMS <https://metacpan.org/author/DAMS>
Great idea! I've been bitten and annoyed by strictures on more than
one occasion. It has its uses, but users should have a choice on how
to react to warnings. <br>
App::YTDL
This module is based on WWW::YouTube::Download but its documentation
does not yet explain how it differs from WWW::YouTube::Download.
From what I see at a glance, App::YTDL supports downloading a video
from a playlist and setting download speed limit, but perhaps the
author should do the mode detailed explaining to help users when to
choose between the two. <br>
Data::CompactDump
Author: MILSO <https://metacpan.org/author/MILSO>
At the current form, simply too simplistic to be an alternative to
Data::Dump or Data::Dumper. No support for blessed refs,
filehandle/globs, circular references, and so on. Changes numbers to
stringy numbers or vice versa. <br><br>Currently also contains some
bugs like for -1 (changes it to string), "\" (produces
invalid dump, does not handle backslash yet currently), <br><br>And
Data::Dump's dump of {} and [] are currently more compact ;-)
<br><br>Need to be improved significantly first. But keep up the
effort.
P Author: LAWALSH <https://metacpan.org/author/LAWALSH>
I personally don't mind the namespace choice. There are other
single-letter CPAN modules too like B, L, U, V. If you have a beef
with regard to namespace, don't single out P and perhaps downvote
the other modules too. <br><br>Having said that, I would like to
comment on the design and implementation of this module. <br><br>1)
The choice of Unicode character U+2204 as representation of undef.
Unless one does something like 'binmode STDOUT, ":utf8"',
with 'say P undef' I am just trading one warning ("Use of
uninitialized value") with another ("Wide character in
say/print"). The wide character warning is avoided if you do 'P
"%s", undef' though, which means... <br><br>2) P loads
utf8 by default. For ultra-lightweight cases, this is sometimes not
desirable. There is currently no way to turn this off. <br><br>3)
The arbitrary choice of three levels deep when printing references.
This can be customized but with an unusual syntax. But again, the
arbitrary choice of three. <br><br>4) The "complex" rules
of newline printing. p() is like puts, it can optionally add a
newline. But unlike puts, the doc says it can also remove newlines.
The behavior can also change if the string to be printed ends with
0x83. <br><br>I might use P for a sprintf/printf replacement, but
for debugging values, I'd prefer something "dumber" like
Data::Dump::Color (or Data::Printer, if that's your thing).
Xporter
Author: LAWALSH <https://metacpan.org/author/LAWALSH>
A couple of comments. First, if you want to import the default
exports *as well as* some additional others, you can use Exporter's
feature (the :DEFAULT tag): <br><br>use SomeModule qw(:DEFAULT a b
c); <br><br>or you can also "use" twice: <br><br>use
SomeModule; # imports default exports <br><br>use SomeModule qw(a b
c); # import a, b, c <br><br>Second, if you use Xporter, your module
will behave unlike most CPAN modules out there, because a majority
of modules use Exporter. When people see this Perl code: <br><br>use
SomeModule qw(a b c); <br><br>normally they will expect only a, b,
and c are exported. If SomeModule uses Xporter, it will also by
default export the default exports. <br><br>Basically Xporter is
just Exporter with a different default (not arguably better or more
user-friendly). For the sake of minimizing surprise to my users, I
would avoid the use of Xporter. <br><br>UPDATE 2014-01-24: some
edits. I appreciate the effort of the author to defend her module,
though I am not convinced by her arguments.
Dist::Zilla::Shell
Author: DOLMEN <https://metacpan.org/author/DOLMEN>
Nice tool that lets you type dzil commands like 'build', 'test', etc
while sending all the other unknown commands like 'ls -l', 'man Foo'
to the underlying shell. Also lets you avoid multiple startup
overhead of dzil :-)
CPANPLUS::Shell::Curses
Author: MARCUS <https://metacpan.org/author/MARCUS>
Unmaintained. Installs but no longer runs.
Rating: 2/10
Task::Mechanistic
If you peek into its Makefile.PL, you'll see a seemingly
random/heterogenous collection of modules to install (instead of
just WWW::Mechanize). This is probably a Task::BeLike::$AUTHOR in
disguise. <br><br>
Sereal
Author: YVES <https://metacpan.org/author/YVES>
So far the best of the bunch. <br><br>FAST: much faster than
Wouldn't a function like
load_module("Math::Module")->new(42) be more obvious?
Is there a specific goal for using a tied hash (since there is
already %INC)?
Promises
Author: YANICK <https://metacpan.org/author/YANICK>
5-star for its documentation. <br>
Lingua::ITA::Numbers
Author: PETAMEM <https://metacpan.org/author/PETAMEM>
Does the author care to explain the sudden influx of
Lingua::<3-letter-code>:: modules (which look like mostly just
repackaging of their corresponding Lingua::<2-letter-code>::
modules with no mention of purpose in the PODs)? The original
modules are not orphaned either (for example, I still maintain
Lingua::ID::*). <br><br>No Changes file. Versioning synchronized for
all 3-letter modules with no indication of what version of the
2-letter-code module is used. For example, Lingua::ITA::Numbers' doc
still says "decimals don't work properly", while
Lingua::IT::Numbers' doesn't (however, needless use of
Regexp::Common does gets removed).
HTTP::Headers::Patch::DontUseStorable
Author: PERLANCAR <https://metacpan.org/author/PERLANCAR>
@zaxon: I'm not sure if it's a bug with HTTP::Headers, more like a
workaround for Storable. See the FAQ in the updated v0.03 for more
details. <br>
Storable
Author: NWCLARK <https://metacpan.org/author/NWCLARK>
Balancing previous glowing reviews. Storable has it faults, for
example historically its track record for file format backwards
compatibility is poor, making programs fail when loading Storable
files after the module is upgraded. <br><br>Also, more importantly,
add builtin support for Regexp object already! It's almost 2013,
Regexp object has been around for, what, more than a decade? I can
understand not supporting serializing filehandle or coderef, but
Regexp object?
Rating: 2/10
WWW::YouTube::Download
Author: OALDERS <https://metacpan.org/author/OALDERS>
Works for me too ATM. I've tried several command-line scripts (most
of them Python-based, like youtube-dl, tubenick, etc). Sometimes
they work, sometimes they broke. It's the nature of this kind of
script. The quality comes from persistence. This module has been
maintained since 2009, through several YouTube's changes. I commend
the author, good job, and thanks!
Number::Zero
From the module's POD: "The number zero and undef are difficult
to determine in Perl." <br><br>Are they? <br><br>say
!defined($data) ? "undef" : "not undef";
<br><br>say defined($data) && $data==0 ? "zero" :
"not zero"; # yes, warn if non-numeric <br><br>use
Scalar::Util 'looks_like_number'; <br> say looks_like_number($data)
&& $data==0 ? "zero" : "not zero";
<br><br>Though I understand the need for a convenient
"is_zero" function if you need to test for zero in a
program a lot.
Syntax::SourceHighlight
Author: MATLIB <https://metacpan.org/author/MATLIB>
IMO, currently the only usable (read: non-crap) code syntax
highlighting library on CPAN. Cons: you'll need to install GNU
Source-highlight (and its development library/header) which pulls
over 100MB of packages on my Debian. <br>
Rating: 8/10
Syntax::Highlight::Engine::Kate
Author: MANWAR <https://metacpan.org/author/MANWAR>
Highlighter engine doesn't seem updated (for example, defined-or is
not yet interpreted correctly by this module but already correctly
by Kate itself). Does not provide default theme (must specify all
colors). Seem to be very slow (takes 1.5s for a 18K Perl .pm file
while Pygments only takes 0.2s). <br><br>
Rating: 2/10
Syntax::Highlight::JSON
Author: MART <https://metacpan.org/author/MART>
No documentation. Combines formatting and syntax-highlighting, so
you cannot preserve original formatting. Only outputs to HTML and no
default "theme" (CSS) provided. <br>
Rating: 2/10
Syntax::Highlight::Engine::Simple
Author: AKHUETTEL <https://metacpan.org/author/AKHUETTEL>
Output looks decent. However, it currently only formats to HTML/CSS
(no ANSI, LaTeX, etc). Also, it needs more languages support. <br>
Rating: 6/10
Syntax::Highlight::Universal
Author: PALANT <https://metacpan.org/author/PALANT>
Only targets (X)HTML (i.e. no alternative output like ANSI or
LaTeX). Supposedly slow. But it doesn't matter because code no
longer builds (last updated in 2005).
Rating: 2/10
text::highlight
Outdated (no longer updated), poor capability (even for some simple
Perl code, the output is atrocious), few languages supported. A far
cry from Pygments or coderay.
Rating: 2/10
SemVer
CHI Author: ASB <https://metacpan.org/author/ASB>
The DBI of caching. Stop reinventing your caching framework and just
use this. <br><br>UPDATE 2013-01-16: unfortunately, the use of Moose
reduces the usefulness of CHI for command-line scripts (0.2s/146
files/53k lines startup overhead just to initialize a File cache).
So 4 stars instead of 5. Let's hope the author migrates to Moo
someday. <br>
Rating: 8/10
Monkey::Patch
Author: FRODWITH <https://metacpan.org/author/FRODWITH>
Compared to several other monkey-patching modules (like Sub::Monkey
or Class::Monkey) I prefer this one because the interface is
simplest and the documentation is the most straightforward. Plus it
can do stacked patching and unordered restore, which is cool.
<br><br>
Log::AutoDump
Author: CAGAO <https://metacpan.org/author/CAGAO>
This module is simple and to the point. Unfortunately, if you're a
user of Log4perl or other logging framework, you'll have to switch
just for a single feature (autodumping). <br><br>An alternative is
to use Log::Any, which also features autodumping (via
$log->debugf("%s", $complex), $log->warnf(), and
friends), while still allowing you to use Log4perl and other
frameworks supported by Log::Any. <br><br>
List::Pairwise
Author: TDRUGEON <https://metacpan.org/author/TDRUGEON>
Two nice and possibly very useful functions. But IMO the names
'mapp' and 'grepp' are two similar to 'map' and 'grep', making it
prone to typos and misreading. Perhaps consider 'map2' and 'grep2'?
Log::Log4perl::Appender::File::FixedSize
Author: HOREA <https://metacpan.org/author/HOREA>
Module name should perhaps be
Log::Log4perl::Appender::File::RoundRobin to make it clearer that
the backend is File::RoundRobin. <br>
Any::Mo
Why exclude Moo? <br><br>Also the issue with any Any::* (or Any::*)
modules is that there should be a mechanism (preferably a common
one) to adjust the ordering. Sometimes I prefer Moose first, for
full capability or compatibility or whatever. Sometimes I prefer
Mouse or Moo, for quick startup (but don't mind Moose if those are
not available). This also happens to me for YAML::Any: in some cases
I prefer YAML::Syck, in others YAML::XS, this depends on the data
that I'm handling. <br>
PerlX::Perform
Author: TOBYINK <https://metacpan.org/author/TOBYINK>
I personally don't see much value of this syntactic sugar since Perl
already allows us to express clearly. Pick one: <br><br>for ($foo) {
say $_ if defined } <br><br>for (grep {defined} $foo) { say $_ }
<br><br>do { say $_ if defined } for $foo <br><br>say $_ for grep
{defined} $foo <br><br>And save yourself from having to remember
whether we should add a comma or not before "wherever".
<br>
TOBYINK::PerlX::A
I have nothing against bundles like this, but beware that adding
'use TOBYINK::PerlX::A' will cause Perl to load 460 files and
compile +- 160k lines (takes 1s on my Core i5 machine and 8s on my
Atom netbook).
WWW::Google::Images
Just adding a note that this module is unmaintained (as expressed by
the author) and has stopped working for some time. If you are
looking for alternatives, try REST::Google (which includes
REST::Google::Search::Images). The latter has been working OK for
me.
Acme::Damn
Author: IBB <https://metacpan.org/author/IBB>
5 stars for cute metaphor (there's also Acme::Holy by the same
author, but that is just another implementation of Scalar::Util's
blessed()) and for prompt support from the author. <br><br>I'm sure
there exists a real use case to move this out of Acme::, however
obscure that might be. Can't come up with any right now, all I can
think of is reblessing, which can be handled with bless() from the
start. <br><br>UPDATE 2013-09-11: I found a real use-case for it!
Cleaning up data to be sent to JSON. BTW, Data::Structure::Util also
has an unbless() function, but Acme::Damn is smaller and faster.
Data::Structure::Util also currently doesn't build on Windows. <br>
WWW::Parallels::Agent
@Justin Case: The name is unfortunate, but it's already proper
(WWW:: followed by website or company name). HTTP client libraries
are in LWP::. But VM:: is also an apt choice. <br>
Underscore
I don't know why Sawyer X's review is marked as unhelpful (2 out of
8), but I agree with him. This is *not* an Acme module, it's a port
of a JavaScript library of the same name. <br>
Locale::Geocode
Author: DIZ <https://metacpan.org/author/DIZ>
Sorry to have to rate with 1 star. I don't have problem with the
interface/documentation. The 1-star rating is just to warn people
that the data used by this module is not up to date. And that
YEARS-old bugs are not being fixed. <br><br>At the time of this
writing, this module still uses ISO 3166-2:1998 (first edition) +
the newsletters (minor updates) up to 2006. When it should be
updated to ISO 3166-2:2007 (second edition) + all the newsletters.
For example, this module does not report 3 newer provinces in
Indonesia. <br><br>Sadly we live in a world where countries and
subcountries change all the time.
Rating: 2/10
Locale::SubCountry
Author: KIMRYAN <https://metacpan.org/author/KIMRYAN>
UPDATE 2012-08-30: I am not sure if the module is now fully
compliant to the new ISO 2007, but bug reports are certainly being
responded and resolved now. Updating rating from 1-star to 4-star.
Thanks, Kim. <br><br>2012-02-17: Review to version 1.47:
<br><br>Sorry to have to rate with 1 star. I don't have problem with
the interface/documentation. The 1-star rating is just to warn
people that the data used by this module is not up to date. And that
months-old bugs are not being fixed. <br><br>At the time of this
writing, this module still uses ISO 3166-2:1998 (first edition) when
it should be updated to ISO 3166-2:2007 (second edition) + all the
newsletters (minor updates). For example, this module does not
report 3 newer provinces in Indonesia. <br><br>Sadly we live in a
world where countries and subcountries change all the time.
<br><br>EDIT: Ok, so I was not being clear that I was not talking
about my own bug report (posted at about the same time of this
review). And bugs were certainly being resolved up to about 7 months
ago. <br>
Rating: 8/10
Data::Rmap
Author: BOWMANBS <https://metacpan.org/author/BOWMANBS>
A very handy utility, sort of like s/// on your nested data
structure instead of just strings. One nitpick: no coderef support.
I needed to replace all coderefs inside a data structure into a
string, since I want to pass it to JSON encoder. None of the
rmap_*() functions seem to let me get to the coderefs. (RT wishlist
ticket added.) <br><br>UPDATE 2011-12-30: The author (Brad) quickly
responded to my RT ticket and added rmap_code. Upgrading from 4- to
5-star :) Regexp support is not there yet though, and I have
suggested the ability to get all kinds of Perl-specific and weird
objects, because one of the main uses of Data::Rmap for me is to
"clean" a data structure to pass to non-Perl systems. <br>
Data::Properties::JSON
Author: JOHND <https://metacpan.org/author/JOHND>
The abstract for this module is a bit strange. What does this have
to do with 'test fixtures'? Also the documentation doesn't say much,
e.g. What will happen if a hash key contains funny characters (or
arrays, etc)? <br><br>A similar module in spirit is Data::Hive. I
think "providing convenient chained method access to
hierarchical data" should be refactored out. So perhaps
Data::Properties::{JSON,YAML,...} should just be a convenient
shortcut for {JSON,YAML,...} parser + Data::Hive.
Exporter::Auto
Author: NEILB <https://metacpan.org/author/NEILB>
I discourage module authors from exporting like this because it's
simply too impolite/intrusive for module users. If the module author
is lazy, there is already Exporter::NoWork which offers a few
options for module users. This module, on the other hand, gives no
control at all for users (so they'll have to resort to 'use Module
();'). <br><br>Let me remind all again by quoting from Exporter's
POD: "Do *not* export anything else by default without a good
reason! Exports pollute the namespace of the module user."
Net::Douban
Interface to web services should be put under WWW::*, not Net::*
HTML::Form::XSS
Author: DUMB <https://metacpan.org/author/DUMB>
Should probably be put under Test::*?
Thread::IID
Author: WROG <https://metacpan.org/author/WROG>
When I saw the perlmonks thread yesterday, I thought "well,
someone should package it and put it on CPAN". And then someone
did :) Thanks. <br>
Test::Lite
Author: BRADH <https://metacpan.org/author/BRADH>
This is just a reimplementation of Test::More. But I thank the
author for writing a short description of why this module is
written, how it is different from others, and suggestion of what
modules users should use. There are a lot of wheels being reinvented
on CPAN, and that's okay, I just wish more people would document the
reason.
Sub::Mage
Author: BRADH <https://metacpan.org/author/BRADH>
Since the first release, there are 13 subsequent releases in total.
What are the changes between releases? No idea, the author doesn't
bother to update Changes (and no public repo is listed). Apparently
all his other modules are also like this. Not very user-friendly.
<br><br>UPDATE 2011-11-22: I see that this has been rectified by the
author, there is now Changes entry for each new release. Cool,
thanks. <br>
relative_lib
Documentation is placed in README.md, so it's inaccessible from
perldoc et al. Why? This is not a Python library.
CPAN::Mini::Webserver
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
Log::Fast
Author: POWERMAN <https://metacpan.org/author/POWERMAN>
This logging framework is also minimalistic: no
categories/hierarchiecal loggers, no custom levels, no config file,
or other whistles and bells. And the interface & default levels
are rather syslog-oriented. But it's fast alright. The POD doesn't
mention a comparison to Log::Log4perl, but a casual benchmark shows
that it's at least 10x faster. <br><br>So this module will certainly
come handy if you have a performance critical application.
<br><br>Btw, note that the benchmarks are done for actual logging to
output. For log statements that do not actually get logged (e.g.
because the level is below the desired output level), I don't find
that extreme differences in overhead between logging frameworks. For
example, on my Athlon64 X2 5600+ PC, Log::Fast's overhead is roughly
around 3mils/sec, while Log::Log4perl is around 1,5mils/sec.
Log::Minimal
Author: KAZEBURO <https://metacpan.org/author/KAZEBURO>
Log::Minimal's slogan is "minimal but customizable". It's
minimal alright, probably only suitable for simple scripts as the
moment you organize your application/library into separate modules,
you'll want/need categories instead of just level, which is not
provided by Log::Minimal. <br><br>Also, only formats is
customizable, there is currently no way to customize level. And the
levels are "not standard" (not that there is an official
authoritative standard, but the popular convention is
TRACE/DEBUG/INFO/WARN/ERROR/FATAL and NONE). Log::Minimal's levels
are <br> DEBUG/INFO/WARN/CRITICAL and NONE). Surely most people
would expect another level between WARN and CRITICAL, for
non-critical errors? But that is actually just a matter of taste.
<br>
Rating: 4/10
Log::Fine
Author: CFUHRMAN <https://metacpan.org/author/CFUHRMAN>
Log::Fine is touted as a framework for those who "need a
fine-grained logging mechanism in their program(s)". But apart
from the emphasis on custom levels, to me there is nothing extra
fine-grained about it. The other thing it provides is
categories/namespace, which is also supported by a lot of other
frameworks. So I fail to see the benefit/uniqueness of Log::Fine.
<br><br>Btw regarding custom levels, this practice is long
deprecated by log4j (and thus also by Log4perl, although Log4perl
can do custom levels). I can understand this decision as I sometimes
already have trouble managing the popular convention of 6 levels
(FATAL/ERROR/WARN/INFO/DEBUG/TRACE) as it is, much less with custom
levels!
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>
Capture::Tiny
Author: DAGOLDEN <https://metacpan.org/author/DAGOLDEN>
Another very handy little module that takes the hassle out of
figuring the various mechanisms of capturing output. <br><br>Nice
interface, great documentation, very easy to use. But....
<br><br>Currently it cannot just capture stdout *ONLY* or stderr
*ONLY* (while leaving the other alone). I believe this is one of the
most commonly requested feature (already in RT). If that feature is
implemented, this module deservers a 7-star rating.
Rating: 8/10
File::chdir
Author: DAGOLDEN <https://metacpan.org/author/DAGOLDEN>
This is a handy little module, with a simple and nice interface. One
of the more common bugs encountered in my scripts is forgetting to
track the current working directory after doing chdir() in
subroutines. By localizing $CWD, I don't have to worry that
subroutines mess up current working directory anymore.
FAQ
What is an Acme::CPANModules::* module?
An Acme::CPANModules::* module, like this module, contains just a list
of module names that share a common characteristics. It is a way to
categorize modules and document CPAN. See Acme::CPANModules for more
details.
What are ways to use this Acme::CPANModules module?
Aside from reading this Acme::CPANModules module's POD documentation,
you can install all the listed modules (entries) using cpanm-cpanmodules
script (from App::cpanm::cpanmodules distribution):
% cpanm-cpanmodules -n Import::CPANRatings::User::stevenharyanto
Alternatively you can use the cpanmodules CLI (from App::cpanmodules
distribution):
% cpanmodules ls-entries Import::CPANRatings::User::stevenharyanto | cpanm -n
or Acme::CM::Get:
% perl -MAcme::CM::Get=Import::CPANRatings::User::stevenharyanto -E'say $_->{module} for @{ $LIST->{entries} }' | cpanm -n
or directly:
% perl -MAcme::CPANModules::Import::CPANRatings::User::stevenharyanto -E'say $_->{module} for @{ $Acme::CPANModules::Import::CPANRatings::User::stevenharyanto::LIST->{entries} }' | cpanm -n
This Acme::CPANModules module also helps lcpan produce a more meaningful
result for "lcpan related-mods" command when it comes to finding related
modules for the modules listed in this Acme::CPANModules module. See
App::lcpan::Cmd::related_mods for more details on how "related modules"
are found.
HOMEPAGE
Please visit the project's homepage at
<https://metacpan.org/release/Acme-CPANModules-Import-CPANRatings-User-s
tevenharyanto>.
SOURCE
Source repository is at
<https://github.com/perlancar/perl-Acme-CPANModules-Import-CPANRatings-U
ser-stevenharyanto>.
SEE ALSO
Acme::CPANModules - about the Acme::CPANModules namespace
cpanmodules - CLI tool to let you browse/view the lists
AUTHOR
perlancar <perlancar@cpan.org>
CONTRIBUTING
To contribute, you can send patches by email/via RT, or send pull
requests on GitHub.
Most of the time, you don't need to build the distribution yourself. You
can simply modify the code, then test via:
% prove -l
If you want to build the distribution (e.g. to try to install it locally
on your system), you can install Dist::Zilla,
Dist::Zilla::PluginBundle::Author::PERLANCAR,
Pod::Weaver::PluginBundle::Author::PERLANCAR, and sometimes one or two
other Dist::Zilla- and/or Pod::Weaver plugins. Any additional steps
required beyond that are considered a bug and can be reported to me.
COPYRIGHT AND LICENSE
This software is copyright (c) 2023, 2018 by perlancar
<perlancar@cpan.org>.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
BUGS
Please report any bugs or feature requests on the bugtracker website
<https://rt.cpan.org/Public/Dist/Display.html?Name=Acme-CPANModules-Impo
rt-CPANRatings-User-stevenharyanto>
When submitting a bug or request, please include a test-file or a patch
to an existing test-file that illustrates the bug or desired feature.
( run in 0.703 second using v1.01-cache-2.11-cpan-800906f7e73 )