May I say, I'm not in a good frame of mind, for the author of this module, who passed away before, is being humiliated posthumously.
Surely the criticism of the module is one thing, and the condition of the author another. However, I wonder if you won't become tolerant, taking account of the dead.
No matter how superb modules may be, they age in the course of time, and all the same some of them survive. This module certainly belongs to this type, and come to think of it, Perl wouldn't be my programming language of choice without the module. In such a sense, I wish to express my deep gratitude to the original author and the present maintainer.
It's not exaggerated that I'm a fan of the author of this module.
To say nothing of the module, the author always explicitly writes the motives for why he wrote his modules. For example, take a look at the motives for the module. More importantly the motives are persuasive.
You can experience the speed of the module which is, so to speak, an in-memory version of MongoDB.
As with Number::Phone::JP, the author of this module always offers a practical module rather than a useful module. Such is by no means a negative comment in case you mistake. The module will be necessary to validate Japanese zip codes.
By "a practical module", I meant the module defined the purpose of which is practical use.
Incidentally, CPAN Ratings is anything but the place to respond to your query.
I go on since I'm pestered for more explanation.
By "a useful module", I meant the more comprehensive module, and no more. Thus, speaking for myself, there is no contradiction.
Hereafter I'll reject your query.
Last but not least, keep your big nose out of my business! You have only to look after your insignificant modules, if not bullshit.
To my shame, I have recently been aware of the existence of this module.
The author of the module, CodeRepos Committers is a pseudonym which consists of Japanese big-name geeks that you have presumably heard of.
The module encodes or decodes Japanese mobile phone pictographs. Granted, fixing problems might remain, but I don't doubt of its stability.
As you know, the correspondence between CP932 and Unicode ends in failure to be exact. Such failure notwithstanding, you may have not a few occasions of being compelled to transform the former into the latter and vice versa. In this regard, this module has its raison d'être, and will be helpful to you.
You may rest assured that the author of this module is an expert on character codes, and more importantly a responsible person.
The module is exactly what you want when dealing with what we call Shift-JIS.
You would profit from using this module if you will write a server program for the first time.
There are a large number of modules of this sort out there, and you would be at a loss as to which module is of great use. I, of course, have no silver bullet. My rule of thumb, though, is that if and only if you are a novice at server applications, then the module would come in handy as might have been expected. The fact is that the use of the module itself is too simple; none the less, the module takes aspects of security in consideration.
For the reason above, I'd like to recommend the module while you have no command of writing server applications.
How dull of me to forget to rate this module!
The module implements a symmetric key block cipher which is devised by NTT (NIPPON TELEGRAPH AND TELEPHONE CORPORATION), and named Camellia. I can but say that Camellia is an achievement the Japanese should be proud of.
The use of the module is too simple, and you have only to use it via Crypt::CBC.
First of all, keep out unless you are a Japanese.
To be honest, I was at a loss whether I should rate this module or not; in fact, the module is obviously confined to the Japanese users, and for this reason, its documentation, too, is written in Japanese. My work, however, owes much to the module, and I decided to rate it.
As with Mail::Address::MobileJp by Miyagawa-san, the module validates mobile mail addresses distributed from the Japanese mobile phone carriers; the former should be updated as its author says, whereas the latter has been maintained after a fashion, I reckon. At first blush, validating the addresses would appear easy, but that is by no means the case as a matter of fact, for historical reasons as to the Japanese mobile phone carriers.
In any case, I'd like to recommend the module to the Japanese users.
It strikes me as strange that this module has got no rating yet.
Although there are certainly lots of modules of this sort out there, the author's intention is obviously accurate; that is, a simple and fast form validator.
I suppose that a number of users, especially Japanese users, owe much to the module. The thing is, however, they have neglected to rate the module, and the fact of which is deplorable, I reckon.
Recall the following lines:
"Perl does not automatically patrol private/public borders within its modules--unlike languages such as C++, Java, and Ada, Perl isn't obsessed with enforced privacy. A Perl modules would prefer that you stay out of its living room because you weren't invited, not because it has a shotgun."
That being said, there are certainly such pedants or the management being substantially ignorant of the OO programming as are obsessed with the thought that what is called Access Control is indispensable for the OO programming, and were you to conflict with them, you might want to use this module in the interests of preserving both sides' face, provided you are using Moose.
Note that this review is revision of my former review referring to the version 0.22 of Mouse because the former one doesn't in the least reflect the status quo, and that this caters for folks with prerequisite knowledge of what is called the family of Moose. Keep your nose out of my business if you dislike following those trends.
As you know, the module was written by Shawn M Moore at the outset, and then taken over to Fuji, Goro-san (aka gfx), and thus the present maintainer is gfx; consequently, all the users are lucky to be comfortable using the module.
In the meantime, the definitive differentiation compared with the earlier versions of the module is that by default the module is built as an xsub, and needless to say, the pure perl version only can be installed as well, as per your request. That leads up to as fast execution of the module as possible, including its start-up time. Insofar as you don't deal with meta-objects, Mouse can be a drop-in replacement of Moose.
Last but not least, recognize that Moose, Mouse, and Moo are never in conflict with each other. They have their merits and demerits each. You want to read the following article written up by Stevan Little:
"The Moose Ecosystem"
This module is, so to speak, a combination of Devel::Peek and Data::Dumper, the simile of which the author may complain about, and in any case, the module is more manifold than either of the aforementioned modules. The module is highly recommended when you want both facilities.
I use the module day after day, and in fact it bears using all the time.
To be honest, I dislike remembering the SQL statements. I never believe the SQL is a programming language in general. Apart from the simple case of use, there are many dialects used to manipulate complexities a bit, and there is many a pitfall, more's the pity. Those beat me up, and push me over the edge again and again.
This module would be useful to you like pitiful me. Of course, there are several modules of this sort out there, but for the moment I'd like to recommend the module.
This review is completely identical to my review regarding Math::Random::ISAAC::XS, and have a look at that.
It's obviously natural to use the XS version rather than the pure perl version in the light of the speed performance, if possible.
This module implements the so-called ISAAC algorithm, which was proposed by Robert Jenkins in 1996. The feature of the ISAAC is, when all is said, so fast compared with other pseudorandom number generators.
I don't doubt that the module implements the algorithm safely and completely as well as its pure perl version, Math::Random::ISAAC. All the same, all you have to take care is that the secure seed remains to be adequately selected on your own account.
In order to stand by this module, or rather the admirable author, chocolateboy, I'd like to increase a score; that is, five stars.
If you ask me, I think "1;\n" present at the end of a module file is so ugly that I couldn't praise its use to the skies if there had been workarounds.
Now here is this module. Granted, the module installation might bother the users, but we should persuade them to install the module if need be. That's all there is to it. Moreover, what if the module should be included in the core?
Apart from incompetent authors, are you ready to put the kibosh on such an admirable author as chocolateboy?
The first question that comes over me is why the visitor pattern is restricted to YAML.
Anyone else demands such an inflexible spec?
I warrant here that at the best a year down the road this module will vanish.
Don't get me wrong.
I don't bother to write such a sarcasm just because the module is clumsy, for I doubt that the author sees the advantage of the visitor pattern in general.
This module covers more or less what Path::Class does, but the definitive differentiation is there: that is, even when using Windows, you need not worry about it. Simply put, you need not be conscious which what is called a basename is, which a directory is, or which what is called a volume is, etc.
Both have of course their merits and demerits. However, suffice it to say that the module is necessary to at least me.
I'm afraid that this module is too early to be rated, and not in the least sure what's different from DBIx::Skinny.
My ignorance notwithstanding, I'd like to bet on promise of the module, and to encourage the authors to develop the module, so five stars.
This module is what is called a HTTP/1.1 client. Of course, there are several modules of this sort out there, but the module is useful and handy for at least me.
It's worth noting that the author claims that it is more correct and more complete than HTTP::Lite.
In any case, I'd like to recommend the module for all!
First off, to my shame, I've forgotten to rate this module until now.
Do you have the UCA (Unicode collation algorithm) off pat? If that is the case, I have nothing to say.
The module is an implementation of the UCA, which gives you the DUCET (Default Unicode Collation Element Table). Most of the time, however, you aren't satisfied with the DUCET, especially if you are a Japanese, Chinese, or Korean, etc. In that case, the module is highly recommended.
In addition, it's only natural that the module is included in the core, and the fact of being in the core is why I forgot to rate the module, too.
This module is a transplantation of GNU diff3.c, as the author says.
It's worth noting that the module implements the so-called P. Heckel's algorithm, and that the author's intention is accurate.
Moreover, it's rare that its documentation bears reading compared with that which almost any of Japanese authors would write.
It strikes me as odd how this module has no rating yet.
To the best of my knowledge, in order to detect HTTP_USER_AGENT, especially in the case of Japanese mobile phones, the module is highly recommended.
The module was written by Miyagawa-san at the outset, and then taken over to Kurihara-san, I reckon.
Thus it comes as a surprise that Japanese users have yet to rate the module, I wouldn't put it past them to do such neglect though.
This review will be basically identical to my review regarding JSON.
If my memory serves me correctly, the author is the first person to have transplanted json to perl. Makamaka-san, is my recognition all right?
For the reason above, I'd like to compliment the author on his achievement.
This module is useful and simple to store objects. To the best of my knowledge, there are no object containers akin to such a simple module in terms of usage. What's more, decent Japanese hackers are participating in improving on the module. I'd like to recommend the module for all!
To validate telephone numbers in Japan, it's best to use this module, I reckon. All you have to care about is that the author has it that the module serves the validity of the telephone number, not the existence of it: to wit, a necessary condition, not a sufficient condition, though it's trivial.
As the author says, this module is to Mouse what MooseX::NonMoose or MooseX::Alien is to Moose. As with Moose, you might want to use the module taking care that with the module in tow, all classes cannot always be instantiated as Mouse objects. For more details, have a look at Moose::Cookbook::Basics::Recipe11.
As of this writing, it comes as a shock that this module rating has no more than four stars on average.
I really use the module in situ wherever it comes in handy.
I maintain that with the module in tow, you will be for the first time released from the low-level fork which is prone to make programs nasty.
I'd rather note that you need to read others due to insufficient documents of this module in the first place. It's better for you to see Mongo Documentation, www.mongodb.org/display/DOCS/Home, specifically Perl Tutorial; so minus one star.
Next, as of this writing, the behaviour of the module isn't stable, for example causing a segv under my circumstance with issuing "shutdown" command via run_command of MongoDB::Database. That is, the client side crashes, while the server side is safely terminated; so minus one star.
At any rate, I'd expect the improvement of the module.
As of 0.26(or 0.25?), MongoDB::Tutorial is added.
The document might become your first footing; so plus one star.
My aforementioned review referred to the version 0.26.
It's time I must update the review.
As you know, "MongoDB: The Definitive Guide" was published as well, MongoDB itself has gained wide recognition, I reckon.
I have long since been using this module, it's good quality. So, I'd like to add one more star: all in all, five stars.
Let me digress. NoSQL, which I think is a pointless term, never replaces RDBMS, or rather would fulfil RDBMS's drawbacks.
Yet another ORM module, but specialized with itself lightweight.
The only complaint of mine is that the English explanation of the author's motivation and the module design policy is nowhere to be found, though there is just the Japanese version; so a minus star.
In fact, writing documentation should be a way to get users to place their trust in an author.
My aforementioned review referred to the version 0.05.
Taking the endeavour of the author and his followers into consideration, I'd like to add one more star to the rating: to wit, the five stars, all in all.
This module, when all is said, is arguably stable compared to new ORM modules, and my only complaint about lack of explanation is almost eliminated.
I, as a fan of the module Mouse, am interested in this module.
First off, the author hits the nail on the head. Second, the module's name is cool, too!
You might as well try out the module if you use Moose or Mouse day after day, and it's worth noting that the use of the module comes easy.
I decided to remove my aforementioned review after a moment of hesitation.
This is because I'm afraid that the review might mislead you into thinking as if I did something dishonest, and I was indeed criticized as to the review by someone, for all I care.
I mean, it's too early to rate this module that low. That's all there is to it.
Incidentally, nadim, you've said more than enough, haven't you?
Although I usually oppose reinventing the wheel, I make an exception for such suitable authors as could make a worthwhile module. This module author, Goro Fuji, is one of them. The module is extraordinarily fast, and yet the syntax of a template by means of using the module is never a burden on even the designers out of the picture.
I'd like to recommend the module for all!
This module complements Text::CSV when you want to deal with UTF8.
Without the module, it could be cumbersome to use Text::CSV alone if you didn't have the notion of UTF8 off pat.
At any rate, you can deal with UTF8 out of the box.
Have you ever heard of Judy?
In a nutshell, Judy implements a sparse dynamic array. Consequently, it consumes memory only when it is populated. In fact, a Judy tree is more efficient on memory than any other tree.
This module is a Perl portion of Judy. You should notice its performance.
I'd like to pay a compliment to the author's achievement. The fact is, if my memory serves me, the author is the first person to have transplanted JSON's portion to Perl. Granted, there might be technical problems in detail such as compatibility and so forth, but it is just a claim in hindsight.
I wonder if anyone else uses this module.
The module is certainly interesting, unfortunately, however, it's hard to tell what the author thinks and the purpose of the module because of the rough documentation. Since I'm coincidentally a compatriot of the author, and was able to happily read another annotation written in Japanese as to the module, I can see the author's intention to have written the module. So, I would recommend the author to write the annotation in English.
It seems like the author is unresponsive to the CPAN testers reports, so a star decrease from the three stars.
Taking into account the authors's struggle, the rating is reverted to the three stars, though the documentation is invariably almost a nothing.
It strikes me as strange that this module hasn't been rated any stars yet.
It's simple to use the module, and yet it covers the advanced usage.
In addition, the module should work well under almost any platforms, even Windows.
You would presumably not be at a loss as to what modules relevant to IPC to use.
This is yet another homemade module.
I wonder if anyone else besides the author could use the module. I doubt that it is worth the author's while writing the module against honourable other modules, say, Data::FormValidator, etc. Nothing short of reinventing the wheel.
In effect, the module has no outstanding features, much less originality.
I know better than to use such a module.
Since when has the CPAN been reduced to a practice room for immature authors?
Have you ever been at a loss as to what modules are of great use to clone your data?
I'm also not an exception. Storable or Clone has commonly been used to clone data, but both have their merits and demerits as a matter of fact.
Data::Clone could be a drop-in replacement of them in a way. For accurate information, have a look at its POD.
Last but not least, unlike almost most of Japanese authors except admirable authors of course, the author explicitly writes the intention or the purpose of the module, so I trust him. Other Japanese authors playing dumb, follow his example and study harder, please.
It strikes me as odd how almost most of Japanese authors (of course, except honourable and admirable authors) don't write why they have written their modules and the intention of the modules.
So is the author of this module.
The module is yet another ORM module but unfocused one. What the heck is different from DBIx::Skinny? The explanation is nowhere to be found, but there is just an enumeration of methods. And yet could anyone else use the module?
I don't always oppose reinventing the wheel, in the case of this module, however, I wonder if it is worthy to be registered at any cost on CPAN.
You already have Moose, Mouse, etc. and otherwise Class::Accessor if you dislike the previous modules. Enough already! Do you need yet another but half-baked module, nonetheless?
I hear the author says that he is going to enlighten the perl's newbies, to be honest, however, in no case is he qualified to do so. In fact, he seems to be conceited because of the publication of his only book regarding Perl.
In any case, I fear that what he says and does would mislead the newbies (especially Japanese) deceived by another handle name of his, "perlcodesample".
What features does this module have?
The module is neither an ORM nor a useful DBI.
Certainly that might be most suitable to the author, though I'm not sure whether that is the features beyond honourable DBI.
At any rate, it's better for you to write raw SQLs using DBI rather than such a toy module.
This module is definitely interesting.
The feature, after all, is that the interface is KVS oriented, and that in no way is the data storage narrowed down to DBI.
Better still, the execution performance is as fast as that of DBIx::Skinny, the data storage of which is narrowed down to DBI, as far as I know.
Needless to say, that is faster than that of honourable DBIx::Class.
Never use this module. What a pitiful module!
Have you ever felt like testing subroutines only in a perl script(.pl)?
I can't imagine such a situation, and neither can see the author's motivation.
The module should go to Acme.
This module is particularly useful to those who write XSUB, thereby reducing a bother.
The author of the module, Goro Fuji, simply puts the features in perl-users.jp/articles/advent-calenda... (unfortunately written in Japanese) as follows:
Carrying compiler warnings into effect.
Automatically generating the specific version of ppport.h.
Needless to say, there are other features as to compiling options.
Is it too early to highly estimate this module?
Granted that the module is a reference implementation of PSGI, and existing web frameworks that support PSGI should be used as the author says, but IMHO Plack alone is useful and sufficient, especially in testing your applications without the web frameworks. The more the number of the web frameworks that support PSGI grows, the better your applications being tested on Plack could do anywhere.
Manipulating symbols table is often nasty. First of all, the description tends to be longer as opposed to your prospect. Second, it's hard to read as a matter of course. In which case, I'd like to recommend this module. The interface design and the documentation are both plain enough to use the module.
The outstanding feature of this module, after all, is the speed of execution.
In my experience, the module is definitely faster than other template modules, say, at least Template-Toolkit, HTML-Template, etc. Besides the speed, it's so easy to learn the module, and there is nothing to it.
For the record, the bug report on RT, "Fails when mask is /1" is a misunderstanding of the reporter. In fact, the reporter withdrew it; that is, not a bug.
For those suspicious of it, the following can be for reference:
perl -MNet::IP::Match::XS -le'print match_ip("126.96.36.199","127.0.0.0/1")? "yes":"no"'
This should print "no".
What's more, the net-mask /1 is virtually nonsense.
Have you ever struggled with detecting where leaks come from?
There are such tools as can detect the leaks out there, but you should be surprised how hard the use of them is at your disposal. IMHO it is the lack of flexibility that they own. In such cases, I'd rather recommend you this module.
The use of the module is so simple, and what you have to do is just enclosing statements with braces following leaktrace, etc.
This module makes a collection of functions such as Check functions(is_scalar_ref, is_code_ref, etc.), Validating functions(scalar_ref, code_ref, etc.), and so on. Each function is so useful, and the performance is also satisfactory to at least me. For those suspicious of it, I recommend them the benchmark tests shipped with the module. In case of having no compiler, however, you might not be able to get the performance that good.
At any rate, the module would be your toolbox.
I maintain that Perl couldn't spread so much up to Asian countries without Encode. This module was written by the late Nick Ing-Simmons at the outset, but many authors have since contributed to it. I'd offer my condolences on the late Nick Ing-Simmons, and I, as a user, am indebted to Kogai Dan-san representing the authors for their endeavours.
I admit that in case some customers request hiding source codes, unfortunately I have no choice but to respond to it against the policy of Perl.
It's absolutely terrible! In which case, though, this module is useful.
I, of course, don't know the details of the cryptography theory. For such people, however, this module might be a drop-in replacement of other significant modules.
First and foremost, the interface is simple, so much so that there is no room for wrong use of cryptography. In addition, you can use both symmetric and asymmetric keys.
The only worrying is the building of the module, especially under some platform.
Incidentally, although I'm coincidentally a compatriot of the author, it is nothing to do with the rate.