Acme-CPANModules-Import-CPANRatings-User-stevenharyanto

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        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 &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

    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 &quot;competitor&quot; 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), &quot;/&quot; 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 &amp; 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



( run in 1.681 second using v1.01-cache-2.11-cpan-302cb4679cc )