Reviews by Peter Makholm


mem (v0.4.1) *

This module provides two non-related features.

If loaded without parameters it handles a minor inconvenience related to in-line modules you want to 'use' (assumable to call the import method). If loaded with parameters it just acts as a obscured BEGIN block.

Whereas the first use case is arguably useful, the second feature is only useful for writing obscure code that is incomprehensible to people that actually knows Perl. Even if both features was even remotely sensible having them combined in this interface would would result in 'Interface' and 'Ease of Use' ratings at 1 from me.

The documentation suffers from a overly complicated example. The actual use case the example is trying to set up is obscure and the code requires some knowledge of another unrelated module written by the author. One of the issues the example tries to illustrate is duplicated 4 times, but it is never quite explained why it fails and if there is and difference between the 4 cases. (There is none, the author just seems to want to bad mouth part of the language she obviously doesn't understands).

File-UStore (0.12)

Rating abuse by the module Author is enough for me to give this module the least possible number of stars overall. (*Update*: The author has removed his rating,so I do likewise not to skew the result)

The code does roughly was it says on the box and with a few glitches it seems well documented. One of these glitches is that for the add() method the synopsis and the main documentation described to quite different usage patterns. (*Update*: The documentation is fixed)

The code looks like beginner perl and I would not be sure that the author really understands the obscurities used in the synopsis for the add() method and why it works.

The interface is directly lifted from File::HStore and therefore the author isn't the sole responsible for the interface. (*Update*: Just to clarify: This is good. There is no reason to re-invent interfaces. Reinventing interfaces unnecessary is bad. But it also means that some of my bad feelings about the interface should really be in a review of File::HStore)

My preference would be an interface where file descriptors was the main token instead of having to juggle with paths and temporary files. For File::HStore this might be reasonable as it requires access to the content of a file to generate the id.

Unless I had to replace File::HStore I would rather implement something myself. Having to deal with temporary files in my main code is just as complicated as writing the module from ground up.

But my main reason for looking at the module was the rating abuse by the original author. I havn't really tried the code...

Data-Taxi (0.96) **

It is a plus that the documentation clearly states that this module in no longer being developed or supported.

But the documentation seems to define 'taint aware' as "None of the input data is executed" which is rather worrying.

It actually seems to be taint aware in some acceptable sense (when de-serializing a tainted value the results seems to be tainted) but this seems more accidentally that a design decision and at lease it ought to be backed up with proper testing.

Map-Tube (0.04)

At this early stage this distribution contains a unweighted, undirected, graph of the London Tube map (in Map::Tube::Node) and what seems to be a home brewed Single Destination Shortest Path-algorithm (in Map::Tupe::_process_node()) which is in turn used to solve the Single Pair Shortest Path-problem.

An interesting problem for a novice programmer, but is it really interesting to have on CPAN?

For real use I would look at Graph, Graph::Fast, or Boost::Graph (but I havn't tried any of then lately)

To the author: You really want to read about Dijkstra's algorithm's_algo... (or even better in any book about basic algorithms).

Data-Serializer (0.49) ****

Having a unified way to use all the different serializers available for perl is a good thing and on top of this Data::Serializer even adds some interesting value adding features like compression, encryption and simple file handling.

If I discovered Data::Serializer during my normal development work I would have been a bit surprised that the default isn't just to wrap the underlying serializer but to encode the serialized string as a hex value and add some metadata to it.

I would really prefer having the raw serializer as default and then being able to add extra features as needed. At least I think that the documentation should state this more clearly in the leading paragraphs of the Description.

Everything comes at a price. I'm a bit surprised by the overhead of Data::Serializer. I have tested using a development version of Benchmark::Serialize (to be uploaded as version 0.8) and a home made bridge to JSON::XS

With a 60Kb json structure the default setting of Data::Serialize is 5 times slower the using JSON::XS directly for serialization and half the speed for deserilization. For smaller structures this difference gets even larger.

Using the raw-setting gives a overhead of 19% for serialization and 8% for deserialization for the same structure. With very small structures (like '{ a => 1 }') the overhead is 1000%.

This price might be acceptable if you only use serialization once in a larger process or if you need the added features. But as a naive drop-in wrapper in a project where you make heavy use of serialization of small objects it might not be acceptable.

As always, benchmarking is important and remember to use data relevant for you own use case.

Data-MessagePack (0.23) ***

this is an update of my previous review of version 0.16. The documentation has been improved resulting in a bump of my overall rating.

Yet another serialization module, this time with a binary format.

Speed-wise it is a bit slower than JSON::XS (about 20% for both packing and unpacking) and quite faster than Storable for packing perl structures (500%).

The API is quite simple, just two class methods 'pack' and 'unpack' each taking the data as the single argument. The documentation has improved since version 0.16 and now tell you about some of the limitations of the format. Also a discussion about the advantages has been included and the link to has got a more prominent place. These were my main issues with the module before.

Benchmarking is hard. I believe it to be very misleading using the serialization of {a=>1,b=>2} to show the small size compared to JSON and Storable. The sizes for the data structure presumable used for speed testing (benchmark/ is Data::MessagePack: 93 bytes, JSON::XS 120 bytes, and Storable. 132 bytes. I also find it misleading to conclude that JSON is slow when the deserilization numbers actually shows json to be faster.

If you don't have a lot of string content and serializes as often as you deserializes, the the benchmark might say that Data::MessagePack is preferable. BUT YOU HAVE TO MAKE YOU OWN BENCHMARKS!

It doesn't seem to handle any kind of structure that JSON::XS doesn't handle with the default settings. Only upside is that the resulting packed string is a bit shorter than both Storable and JSON. With a personal preference for the almost human-readable JSON format I still don't really see the point of Data::MessagePack.

Yes, it is quite early in the modules life cycle. My main reason for looking at the module was a request for adding it to Benchmark::Serialize and then I could as well share my experiences.

JSON-DWIW (0.45) ***

I have only tested with quite simple data structures, but it seems to produce the exact same output as JSON::XS by default, but JSON::XS is quite a bit faster.

Encoding to JSON is about 10 times faster with JSON::XS and decoding from JSON is 3 times faster.

Proc-InvokeEditor (1.02) *****

It's simple and solves the task.

I often write command line utilities but sometime you just need to edit a comment or another kind of text. This is easy with this module.

HTTP-Engine (0.03004) ****

As written on

For simple web-based services I usually just After having read a bit about HTTP::Engine I tried it for a simple project yesterday. Beside my own logic it only took a few line of code to have a stand alone HTTP server for my service.

My colleague needed it to be served from the same Apache server as the rest of his webapplication. Some tiny changes and my stand alone server was transformed into a plain CGI script. When we going to deploy the script I’m guessing we make some tiny changes and have it running as a mod_perl module.

Try it for you next project! Even if you usually just use

[EDIT 2010-07-21: These days I would probably use Plack for the same reasons]

Devel-ebug (0.49) *****

This isn't just another debugger to replace the standard perl debugger. It provides a simple, yet quite complete, API for interacting with the debugger process.

Integrating Devel::ebug with an editor like Padre took about one and a half hour - including learning to interact with Padre. If you want to write different frontends for debugging perl code, this is the backend you want!

Filesys-Virtual (0.06) ***

A workable and quite simple API for a virtual filesystem.

It does include some peculiar methods like login() and list_details(), the latter should return something like qx(ls -la), and it really misses some methods to copy or move or move files.

Copying and moving of files can only be done by reading the file and writing it to the destination. For some applications this works but for others these functions is really missing both seen from the side of implementing an Filsesys::Virtual and from using it in an application.

VFSsimple (0.03) *

If you're lookin for at virtual filesystem API I don't think this is the module for you.

But I could be wrong for I have no idea what the author is trying to do. It could be a frontend for getting the content of URI's, but who know because it looks like the actual work should be implemented ind some non existant VFSsimple::Drv:* modules.

VFS (0.01) *

If you need a virtual filesystem layer don't waste you time here.

Not even a proof of concept. Some stubs showing where the author might have been intending going, but neither code, API, nor documentation is really existing.

Apache-ParseLog (1.02) *

The documentation is extensive but unfortunately is missing some very important details like for example how to handle CustomLog's if you dont want to use the "parse a httpd.conf" interface.

The code quality probally speaks for it self. The config methods declaration of a list of variables and then using a set of variables named not quite the same is a minor issue. The getCustomLog method is recommended reading, quite a WTF.

Email-Abstract (2.132) *****

Together with Email::Simple this module provides a great interface for basic mail-handling. As long the simple solution will do just use Email::Simple as concrete mail class and when this is too simple just change a few places and all the legacy code will still work.

Parallel-ForkManager (0.7.5) ****

Even though I know how to use fork(2) directly I find that Parallel::ForkManager improves the readability of my code. It hides the gory details of bookkeeping of running processes whitout hiding whats going on.