Acme-CPANModules-Import-CPANRatings-User-stevenharyanto

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        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>&lt;shameless
        plug&gt;I'm trying to do somewhat the same with Config::Tree, but as
        of now the module is not really done yet.&lt;/shameless plug&gt;
        <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 &quot;mail
        web&quot; or &quot;email url&quot; 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>

        Nice idea. Perl should really have included something like this
        (analogous to warnings.pm for -w). <br><br>However, for something as
        security-related as tainting, I personally think the interface is a
        bit too complex and not robust enough. There are too many pitfalls
        where one can fail to turn on tainting properly. <br><br>* First,
        user must remember to import $TAINT, or doing '$TAINT = 1' has no
        effect. There's no error/warning for this mistake. <br><br>* Then,
        if one also forgets to import taint_start or taint_start, then doing
        'taint_start' or 'taint_env' (without parentheses) will do nothing.
        Also does not produce an error/warning except under strict mode.
        <br><br>* One must remember to 'taint_env' *after* 'taint_start'.
        There's no warning/error if one does the opposite. <br><br>I'd
        rather have something like this: <br><br>{ <br><br>use tainting;
        <br><br>... code is running in taint mode ... <br> } <br><br>use
        tainting; <br> { <br><br>no tainting; <br><br>... code is running
        without taint mode ... <br> } <br><br>No functions, no variables to
        set, no exports. Tainting of %ENV etc should be done automatically
        just like -T. <br><br>EDIT: I wrote tainting and uploaded it to CPAN
        as proof of concept.

        Rating: 8/10

README  view on Meta::CPAN

        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 &quot;with 'X', 'Y',
        'Z';&quot; to &quot;with 'X'; with 'Y'; with 'Z';&quot; 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 &quot;huge&quot; 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 &quot;path-expander&quot; for hash values.
        <br><br>Btw, one thing I use rather often in PHP is naming parameter
        as &quot;foo[]&quot; 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 &quot;joinedwords&quot;, while in DateTime families it's
        &quot;separated_words&quot; (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
        &quot;standard library&quot; 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>

        Wow, I was thinking the same exact &quot;godsend&quot; too and turns
        out some other reviewer already said so. Very very helpful to assist
        deployment and pick modules to use. I personally made a couple of
        command-line scripts like pm-in-core or core-since-when to save some
        typing. <br>

    WWW::Mechanize
        Author: SIMBABQUE <https://metacpan.org/author/SIMBABQUE>

        WWW::Mechanize is of course one of the indispensable tools for any
        web programmer or admin. The current problem is the proliferation of
        3rd party subclasses, the functionalities of which cannot be used
        together. So you want a polite Mechanize which does
        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 &quot;older&quot; 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

README  view on Meta::CPAN

        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 &quot;minimal but customizable&quot;. 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 &quot;not standard&quot; (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 &quot;need a
        fine-grained logging mechanism in their program(s)&quot;. 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!

        Rating: 6/10

    Config::IniFiles
        Author: SHLOMIF <https://metacpan.org/author/SHLOMIF>

        This module has been developed for more than a decade and seen
        different maintainers over the years. The codebase is indeed showing
        these, with different capitalization and indentation styles, among
        other things. <br><br>However, among more than a dozen or so of INI
        modules in CPAN, ironically there seems to be few other choices if
        you go beyond the most basic feature set. Some INI modules can only
        simplistically rewrite/dump the whole INI structure and thus lose
        comments/orders, while others can't even write INI files.
        <br><br>Config::IniFiles by far offers the most options and
        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 -&gt; 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 &quot;cp -sR&quot; 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 &quot;ln&quot; indicates hardlink, at least for me).
        Btw, there's also a free software called &quot;lns&quot; 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 &quot;Pond represents fewer data
        types directly&quot;. <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



( run in 0.626 second using v1.01-cache-2.11-cpan-cdf2f3d4e48 )