Reviews by Zoffix Znet


RT-Client-REST (0.50) **

Works as advertised, but the design of the module requires an extreme amount of API requests to fetch ticket information, making its use both slow and producing too much load on the servers of the API provider.

For example, if I want a list of tickets created after some date or all tickets in the queue, the API provides the '/search/ticket' endpoint that returns a list of found ticket IDs together with their subject lines. Pretty useful as the basis to find a ticket you want.

This module, however, discards the subjects and returns only IDs. If you do want those subjects, you have to call another method that makes another API request, *for each ticket.*

The same issue exists with individual tickets too. If I want to read the ticket and all of the replies to it, the API provides the '/ticket/###/history' endpoint that returns all of that information.

The module, however, requires you get_transaction_ids() for IDs of all the individual items on the ticket, which along with comments includes status changes, for example. And once you have those IDs, you have to request each individual transaction using get_transaction().

Consider a single ticket with 5 comments, status change from `new` to `open`, `bug` tag added, and then status changed from `open` to `resolved`. Using the API with `curl`, I can obtain all of that information in a single API request (login credentials can be part of the URL).

But if I use this module, I have to make 1 request to get transaction IDs, then 8 additional requests to get each individual "transaction."

If all I want is a list of all RT tickets with subject lines for perl6 queue, I can't even reasonably use the module, as instead of 1 API request I can do with `curl`, I will have to make one per ticket I want, resulting in over 1300 requests for the full queue.

Despite promising to be the API client, this module is entirely unusable for my simple and non-exotic task.

Pithub (0.01030) *****

A thoroughly-documented module with a nice interface that did the job.

However, I did spend a lot of time trying to figure out how to not have to set user/repo values on each object, as well as how to set the OAuth token.

Turns out those are documented in the Pithub::Base module and not the distro's main Pithub module, so be sure to read the docs of that.

JSON-Meth (1.001006)

[Author's Review]

First, to respond to Ben Bullock's review: the ambiguity you mention is simply preserved by the module. I'm not sure why you expect the module to magically tell you whether your initial, completely random data is JSON or Perl. To put your question on its head: how would you know when to call to_json() or from_json() when using other JSON modules?

As for the actual review:
I don't recommend using the default $j method and instead you should explicitly request export and use the $json method. The $j is too cryptic and unintuitive and has no place in a production environment, past the semi-joke way this module was originally released.

In addition, by the nature of it, this module does not encode JSON that isn't an array or object at root, which it permitted by the more recent JSON spec, since that obviously leaves ambiguities with Perl strings. More specific conversion methods might be implemented by the module in the future, but currently I lack the tuits to do so. PRs are definitely welcome though.

Mojolicious (6.25) *****

While many other reviewers lauded the distro solely as a fantastic Web framework, I'd like to add that many of the modules included are quite useful even for non-web-application related tasks.

One that stands out the most is Mojo::DOM, which is by far the best HTML parser of what's available on CPAN. It allows you to select elements using CSS selector and a few dozen of methods let you manipulate that HTML any way you want.

Mojo::UserAgent is also mention-worthy: a non-blocking UA. I started using it over LWP::UserAgent thanks to sane methods for manipulations of HTTP Cookies, but another nice feature is the ability to easily get parsed HTML (->dom method gives you Mojo::DOM object) or decoded JSON (->json method).

Mojo::Util is another module I frequently use. It provides common features that I used to import from a dozen different modules: html/url escaping, trimming whitespace, encoding handling, file slurping and spurting, and more.

As for the framework itself: I love the availability of Mojolicious::Lite, which lets you put together quick and dirty single-file web apps. At the same time, I've successfully used Mojolicious to build more complex apps (like the XTaTIK distro).

I've been using Mojolicious since around version 6.01 and did not experience any of the frequently changed API issues described by other commenters. The core team also behaves professionally and all PRs are scrutinized on their technical merits—of course, such scrutiny often results in PRs being downvoted, which I suspect is the reason why several of the reviewers felt they were attacked for making suggestions.

In summation, Mojolicious is a great Toolkit that includes a fantastic Web Framework. It's a gem of CPAN and I certainly recommend it to all.

JSON-Create (0.20) *

We already have a million JSON modules, and I can appreciate someone's alternative take on the problem, but JSON::Create poorly solves only half of it, at the price of a full module, without any added benefit or originality. You can only encode Perl data structures to JSON—something pretty much all other JSON modules can already do. If you want to decode, you need another module.

Considering the module has author's own JSON::Parse in prereqs, I don't see why the author could not simply add the 'create_json' subroutine to JSON::Parse.

Even the author's own comments suggest there's no reasonable rationalle for this module's existence. From the HISTORY section of the documentation: "I started making this module so that, with this and JSON::Parse, I wouldn't have to ever use any of the existing JSON modules on CPAN ever again." A bizarre and baseless desire.

The author is passive-aggressive about the critique they received on this module and advises to "calm down" when bugs in the module are reported on the official bug tracker. After a discussion on GitHub, the author actually deleted and edited all the comments by contributors and then closed the Issues. They also post deliberately skewed benchmarks, appear to be down-voting all the negative reviews using multiple accounts, and post snarky reviews of other JSON modules.

They even went as far as package a "response" file to this review in their distribution claiming "harassment" that never happened and "early release" comments when this review clearly demarcates the module version it's for:

Looking further at technical aspects:
*) The module offers just a single subroutine, yet you have to explicitly request its export.
*) Unlike many other JSON modules on CPAN, JSON::Create does not handle objects that implement ->TO_JSON method and instead the base datatype is used (e.g. bless [qw/foo bar baz/], "foo" ends up encoded as ["foo", "bar", "baz"]). BUT, that conversion happens inconsistently: e.g. the module dies if you try to encode Mojo::URL, despite that object's overloading stringification.
*) Speaking of objects, JSON::Create dies if you feed it JSON::XS::Boolean or similar objects that special-handle conversion between Perl and JSON booleans
*) Be sure to sanitize your data for any subrefs. JSON::Create dies if it encounters them.
*) There's no handling for globs either and instead of doing something sensible (e.g. "null"), the module encodes them as "*Symbol::GEN0" or similar.

In summation, this module does not offer any original solution and seems to be a partial reimplementation of the things already available on CPAN. The author is hostile and does not welcome suggestions for improvement. Avoid this module at all costs.

PDF-Reuse (0.36) **

The functionality is fantastic; especially useful is the ability to add pages from existing PDFs to your document.

The interface on the other hand is an abomination and the fact that code uses package variables means you can't easily distill the module into some object.

The docs exist and look to be complete, but there's just too much of them (partly due to bad interface). It took me a while to find how to change page size and I still don't know how prForm and prDoc differ or how to change font colour.

Geo-IP2Location-Lite (0.04) *****

Works great as a drop-in replacement for the buggy and bloated original Geo::IP2Location that refused to work for me without a patch.

Math-Permute-Lists (1.001) *****

Despite the scary-looking test results (currently, 89 passes/300 fails for version 1.001), this proved to be an excellent module.

I had the exact list of permutations I wanted to have after less than 2 minutes of finding this module; simply by writing this: permute { push @permuted, join '.*?', map quotemeta, @_} @bits;

Much simpler than the convoluted `glob` code I had.

The interface is simple enough to get you up and running simply by glancing at the SYNOPSIS.

Well-deserving of 5 stars.

Mojolicious-Plugin-PDFRenderer (0.08) **

Seems a nice idea in theory, but in practice I ended up mucking around it for awhile before I even got any decent output that doesn't result in timeouts from workers.

I understand the problems lie essentially deeper down the tree of what this module uses under the hood, but indirectly, the module inherits the issues along with the code:

1) A couple of simple pages that I tried to render as PDF resulted in workers dying due to time outs. A 3-screen page takes several minutes to render even after I increase heartbeat timeouts—definitely not something I'd have available for use in production.
2) I found the above is largely rectified by using wkhtmltopdf version 0.9.9 instead of the current, but the plugin doesn't let you specify a different path to the executable
3) Using Bootstrap (and anything similar) results in the output rendered as if it were displayed on the "extra small" screen, even if you set giant page sizes.
3) Plugin generates a ton of 'uninitialized value' warnings
4) There are no options to allow PDF generation on only a few routes instead of ALL of them.
5) The docs mention you can pass options to wkhtmltopdf, but it's not too clear how to do it, and even when I managed to pass some, I got errors from wkhtmltopdf telling me the option I passed is in the wrong place.

In summation, I'd like to quote the current docs: "Then go to yourapp:3000/any/route, take a good look, then go to yourapp:3000/any/route.pdf. Cool, huh?"... yes, pretty cool, but offers little practicle value.

App-GitHub (1.0.1) *

Tried using --fork=... the app said fork successfully created, but in reality nothing was created

Tried using --create=... the app said creation failed, but in reality the repo was created.

Omitted --username and --password because I did not remember whether I had github credentials in .gitglobal... No errors on --fork=, says "no auth" on --create.

In summation, it looks like the module needs comprehensive testing and debugging in its logical pathways. And fixing to make it actually work.

HTML-Template (2.95) **

I've been using this module for about 6 years now and I probably have over 100,000 lines of HTML::Template templates code.

This module is easy to learn and use... and that's why it sucks.

The simplicity tricks you into choosing to use it, but you quickly hit its limits. Unwilling to learn better templating systems, you continue to use HTML::Template, nesting a ton of <tmpl_if>s to solve fairly common logic situations, because there's no <tmpl_elsif>, and willingly burying yourself into an unmaintainable tag soup.

There's also no surrounding white-space handling, so if you choose to write readable documents at 80-char width, your output will end up with dozens of empty lines all over it.

In summation, if you want a quick one-off template generation that has virtually no learning curve, go for it, but if you're choosing something to write many HTML templates in, avoid this module—and I speak from experience.

If you're stuck with a bunch of HTML::Template templates, take a look at HTML::Template::Compiled. It offers more features and seems to work well as a drop-in replacement to HTML::Template.

Net-FullAuto (0.999999999994) *

This module should be avoided by all. Personally, I suspect its use will cause damage either due to author's incompetence or malicious intent.

The pod reads like a bad Infomercial: "IT REALLY IS THAT EASY!", "Net::FullAuto is POWERFUL", "Net::FullAuto is the ANSWER!"

It barely describes what the module does, and according to the extensive RT#100658 (titled "documentation lies") the module performs many security-sensitive tasks, yet they are undocumented and the unmaintainable mess of the code essentially guarantees there are droves of bugs. Furthermore, the output (according to the docs) of the script that uses this module is litered with unwanted messages like "Starting fullauto" and asking the user for additional passwords, which limits the use of this code as a Perl module.

The author doesn't use conventional Perl distribution tools and seems to be manually hacking Makefile.PL, which, at the time of this writing, is 6319 lines long. The code is trying to guess OS in use and then installs a bunch of software using system package manager (e.g. sudo yum -y install 'openssl-devel'). Due to issues, the author also disabled CPAN TESTERS service on the module.

The installation asks for sudo password for no explained reason (RT#97421).

Looking at the files inside the distro, there are lots of puzzling examples: UNINSTALL_CYGWIN, install_mozrepl_plugin.ahk, a directory with 75 figlet fonts! What are those doing in a Perl CPAN distribution? The code is a huge mess and even the author says it isn't really meant to be understood by merely perusing it (RT#100658).

The author also frequently uploads null updates to CPAN, presumably to gain exposure to the module, thanks to CPAN update services. The current version number is a ridiculously long sequence of 9s and the 7-year old Changelog contains 2278 lines!

In summation, this distribution does not adhere to accepted CPAN standards, the code is in poor state and works with security/system sensitive aspects, which makes the code dangerous to use.

Avoid at all costs. Don't even install for curiosity.

Orignal (0.03) *

First, I'm not even sure what this is doing on CPAN in the first place. There is Class::Accessor::Grouped, Moose, and Moo that do the same things in a saner fashion—and that's just off the top of my head; I'm sure there are dozens more.

The code is baffling: a ton of string evals and you can sell those backslashes by the pound.

The interface is questionable: the hashref/arrayref values have a handful of methods that supposedly re-implement what perl can already do and I would argue that any object that would actually require all those methods doesn't encapsulate its data properly.

And finally, my biggest gripe is the name of the distro. It's completely undescriptive and meaningless. It looks like a typo in your code. Perhaps, the author found it creative, amusing, and cute, but in reality it's nothing but top-level namespace pollution that will make searches difficult and anyone who actually uses this code will give nightmares to maintainers.

If I could give this a negative rating, I would.

Bundle-dualLived (1.05) *

A dangerous module, as I've learned the hard way today.

After installing it with perl 5.14.2, my perldoc essentially broke, displaying "ESC[blah" type of stuff everywhere that used to be in bold font.

Luckily, I was using local::lib and deleting the local user version of Pod::Perldoc fixed the issue. However, to be on the safe side, I nuked all the locally-installed modules (can't be arsed to fish out just the core ones), and right now I'm reinstalling all the modules that I usually use.

Are there more sinister issues introduced by updating other core modules?

Who knows...

Learn from my fail. Avoid this module.

REST-Google (1.0.8) **

He's dead, Jim!

* The installation fails with "got 403" in t/05_translate.t.
* RT query shows 4-year-old bugs
* Author inactive for at least the last 2 years
* Documentation is non-existent: synopsis mensions ->pages and ->cursor, but the POD has no explanation for what those mean

Despite all that, I actually managed to piece together something I could use for a small script (so the module seems to still be working).

Seeing the current state of the module, I would NOT use this for production code.

Test-Kwalitee-Extra (v0.2.0) ***

It's nice to be able to test all the extra Kwalitee metrics with this dist, but what is really annoying is the test frequently freezes (I'm unsure whether it just hangs or whether it's trying to access some online resource that isn't responding).

I had to disable this test (in Dist::Zilla's dist.ini) in about 40% of dists where I used it and at this point I'm debating going back to plain Test::Kwalitee

Test-Deep (0.112) ****

Great module that allowed me to thoroughly test a bunch of very large structures.

My only disappointment is the documentation: it currently (v0.112) doesn't mention some of the available functions. One of such is hash_each() and I spent an hour or more searching for the solution without keys()... At the end, I've decided to try to implement it myself, when I spotted it already made in the source.

Other than that, this module is gold!

Search-Indexer (0.77) *****

Great module that I've used many times so far. Performance is decent too.

I have barely scratched the surface of the functionality: the module assignes relevance scores to each found document and provides the regex for the matching term so you could highlight matching text in your document.

The module also provides search patterns to make the search more specific; for example you can search for "word1 AND (word2 OR word3) AND NOT word4"

Reviewer ديم الخمير wrote about a problem in this module in his/her review, however he/she was simply not using a method correctly.

WWW-Alexa-API (0.03) *

This is the review of version 0.05

Overall, there is no need for this module.

There's already WWW::Alexa::TrafficRank that is maintained, provides more features, and has a higher Kwalitee rank and tests that actually pass.

My attempt to see whether this module actually worked had issues, as prerequsites (such as XML::Hash::LX) didn't want to install without XML C libraries, and even once I got those installed, this module failed to install due to failing POD tests.

The documentation doesn't say anything about the structure of the hashref returned from the get() method, and even after dumping it with Data::Dumper, I'm quite uncertain about the meaning of all the various keys in it.

This is the author's first distro on CPAN, so any misgivings are of course, understandable, but as far as the module itself goes, WWW::Alexa::TrafficRank is a better alternative.

Number-Range (0.10) *****

I was able to accomplish my task 10 minutes after I encountered this module on MetaCPAN.

It takes in ranges of numbers and allows you to manipulate the data. My only issue with the module is restricted acceptable format. To specify a range you use ".." and "-" is not allowed ("-" is what my input from the user was going to be). The other issue is that the module allows separation of numbers either with a comma or a space, but it's an error to use a space right after a comma (e.g. "10, 20").

The module dies with an error message if an incorrect range is specificed.

App-ZofCMS (0.0224)

Author Review:

I've been using App::ZofCMS on personal and work sites for about half a decade now.

It works well for sites where individual pages don't offer too much functionality. It's fine if the functionality is spread over several pages: the largest app I wrote with ZofCMS is over 100,000 lines of code written in 132 pages.

Several plugins—ImageGallery, HTMLMailer, QuickNote, UserLogin and it's companion plugins—turn a semi-ardious coding task into simply setting a few parameters and copy/pasting a few lines of code from the docs.

Very easy to deploy on limited hosts where you can't SSH or install modules.

Notable problems:
-- Current plugin system is very poorly designed in regard to running the same plugin several times on the same page. On some complex pages I found myself going all over the template trying to figure out what the code does. To work around this, I either split functionality across several pages, or code a separate module that I then use in the ZofCMS Template.

-- Many plugins try to be overly flexbile and overly configurable. This clutters up their documentation and makes it more difficult to remember what format of configuration to use, so unless you're comfortable with the plugin already, it can be annoying trying to read all those docs.

-- The framework uses HTML::Template for templates, and I always find my templates looking like a giant mess. The template variables blend in with HTML code and become hard to spot. Lack of switch{} statement (or if / elsif /else) can clutter up your template quickly with nested ifs. Global ZofCMS Template variables (or the ones in {t} special key) are not present in HTML::Template loops, which can be really annoying when you're trying to set one global variable and end up stuffing it into loops in your code over a dozen pages.

-- No effort has been made to benchmark the performance of this framework. The most oft-visited site on ZofCMS that I have gets about 10,000 visits a month and is located on a shared server where I can't even run cpan due to memory constrains. So far no trouble, but would the same hold true for 20,000 visits? 50,000? I have no idea.

PDF (111) *

Doesn't work at all, despite successful installation.

Docs virtually don't exist... well, and 7-year-old bugs show how much the author cares.

perl-vgalib (0.4)

Even though, the cause is likely to be my own dumb fault, installing this module "exploded" my box.

While installing within X, my box stopped responding during EVGA tests. I hard rebooted it, and to my surprise the X config file was all messed up (I am NOT implying that this is module's fault).

The second attempt at installing I did outside of X, and that session froze too.

I would advise caution when running tests for this module.

Date-Manip (6.42) ****

It's a great module and it does what it is advertised.

However, it's rare that my task requires the use of this module, and for that reason, I always find myself referring to the documention; that part always makes me utterly annoyed. I always find myself scrolling back and forth trying to remember what routine(s) I used to use in the past.

To the author I would suggest using more =head elements in the pod - even for every method/function and even arguments. This way one, who probably used the module in the past, can just glance at the Table of Contents and go "Aha! these two are the ones I used before!".

File-Size (0.06) ****

Not sure what "UNAUTHORIZED RELEASE" means; I couldn't install the module via cpan File::Size. However, module does what it is ment to do and does it fast. Documentation could be improved a bit as I had to run test codes to figure out what exactly some methods return, other than that I like this module.

POE-Component-Proxy-TCP (1.2) *

With version being 1.2 I was expecting the module to be stable or at least workable. The example provided in the documentation (which is only half-written) errored out on the module's code.. after fixing the error and fixing two more errors that followed I gave up on the module.

When installing test freezes... not a single "PASS" with CPAN testers. Question is, why would you release a module with partial documentation and the one that doesn't even work is a mistery to me.

If you have some beta work and would like other people to contribute at least mention that fact in documentation and don't release it under the version number which is commonly understood as meaning "mature" release.

Thank you for your time.

Syntax-Highlight-HTML (0.04) *****

Excellent module. Simple, "press button - receive bacon", interface which works as advertised.

I use it to display code examples on my tutorials, haven't seen it misbihave. You can highlight in different colors: doctypes, comments, tag delimiting angled brackets, tag names, attribute names, attribute values and even HTML entities.

By giving the constructor one short argument you can turn on line numbers for which there is also a separate highlighting color.

A note of caution, if you are going to use the CSS code conveniently provided to you in eg/html-syntax.css make sure to set background colors or make sure they are shown properly from parent elements. I've ran into so many pages that set only the color and on my "dark" system theme colors show up as "gray on gray" ^_^

Excellent work on the part of the author. I give this module 5 stars

POE-Component-IRC-Plugin-BasePoCoWrap (0.004)

As the author of this module I won't give it any ratings to play the game fair.

Personally, I found this module useful on many, many occasions. The module allows you to take some POE::Component::*, which in my case were the non-blocking wrappers aroung goodies, and quickly make a fully functionaly and configurable POE::Component::IRC::Plugin::* and ... plug it. The module automatically provides functionality for specifying triggers for commands coming from each of public, privmsg and notice message types, to which of those messages the plugin will respond as well as who is banned or in reverse, who is allowed to use the plugin.

If your plugin needs some extra arguments with some defaults,
adding those is a snap. Want it to not say anything but instead just send events - done deal.

You can dynamically change any of the arguments passed to the constructor at any time, even though that involves poking directly into the object, but that's advertised, thus I don't see it as a big problem. Want to ban someone one the fly? push @{ $plugin->{bans} },
qr/^somedude\@\d+[.]/i; done

After releasing perhaps more than 10 plugins based on this module I completely felt in love with it. The "DOCUMENTATION FOR YOUR PLUGIN" section incourages lazy people (like me) to provide decent documentation to their work.

Thanks for your time.

WWW-Cache-Google (0.04) ****

Simple little module, works almost as advertised despite the bug. Until the bug is fixed the fetch() method is useless as google blocks LWP::Simple's default UA string. The module could be improved by switching to LWP::UserAgent and providing a decent error message. The check for whether or not the fetch()ed page actually exists in Google cache (which turned out to be quite easy to do) would be a very nice addition.


XML-Simple (2.18) *****

Despite the previous comment I rate this distro to max.. it does what it was made for.. haven't failed me so far. I like the "press button - receive bacon" interface. As for "sometimes hashes - sometimes arrayrefs" this can be configured. Read the documentation.

WWW-Google-Video (0.4) **

The module doesn't do any error checking when using get() from LWP::Simple which causes warnings to be printed due to subsequent regex matches done on (undefined due to error) variable. Maybe it's just me, but I dislike the fact that you have to poke around in object's hash keys in order to obtain results of a fetch(), why not *return* a list, hash(ref) instead? That would easily allow implementation of error mechanizm. Not sure why "url to FLV" gets its "+" characters changed to plain spaces and not just left as they are, or at least changed to %20. Makes it pain to paste those URIs to say, IRC.

I question readability of ${$_[0]} throught the code as well.

Overall, I would say that if an author would put an extra five minutes of his time into this module it could be a decent piece of software.


POE-Component-IRC (5.40) *****

A bit hard to start up with, but after a while you get a hang of it and start IRC Bots Co. Ltd. :D

BingOS++ for great work