| CPAN Ratings (Gamma) Reviews by Sam Vilain | |
| Home | Search | About | Login |
RSS | Module Info | Add a review of
3 out of 3 found this review helpful:
Great module, but it has an irritating list of hardcoded currencies
meaning that it must be continually updated to work with those
currencies. Bad Barbie.
Sam Vilain - 2008-05-22 15:24:54
Was this review helpful to you?
Yes
No
The compile issue is fixed, and I'll replace the README with a more boring one in the next release for those without a sense of humour. Thanks for the feedback.
Sam Vilain - 2006-08-01 15:30:31
Was this review helpful to you?
Yes
No
As author of one of the previous metamodel modules on CPAN, T2 - it is nice to see a new metamodel come out that has made Rightâ„¢ architectural decisions at virtually every step.
Being the result of a long and extensive period of collaboration and dialogue with the core Perl 6 development team and veterans of various object systems, and being heavily researched in such longstanding prior art as the Smalltalk and CLOS Meta-Object-Protocols, the long question of "which accessors module to use" has finally been solved in a way that allows a new wave of advanced tools to be developed, as well as paving the way for a smooth migration to Perl 6 objects.
Naturally if you are unfamiliar with the higher level tricks then this might seem a bit pointless. However, modules like Template::Plugin::Heritable would be needlessly complicated and restricted to a 10-year old object model without the sophisticated abstractions provided by Moose and Class-MOP.
Sam Vilain - 2006-07-26 22:00:14
Was this review helpful to you?
Yes
No
Though a little short on docs and examples, with a bit of patience and experimentation it is easy to get curses forms and dialogs working with this module. I would certainly recommend it to somebody looking to have nicer prompts in their terminal applications, but who doesn't want to spend a lot of time messing around with it. Its widespread availability across Linux distributions is a bonus, too.
Sam Vilain - 2006-06-18 14:33:46
Was this review helpful to you?
Yes
No
Look at the source of, eg, Curses::UI::Dialog::Question, for the shortcomings in this module - it is not possible to just throw a few widgets together to make a dialog. This module does nothing to avoid the user from having to do fiddly layout and offset calculations in the code that makes new dialogs, and regrettably the "Question" dialog is not extensible to exchange the default TextEntry widget with another.
I found this module has an enticing looking interface but was upset when I found it next to useless trying to use it. Next I'm trying Newt.
Sam Vilain - 2006-06-15 18:56:47
Was this review helpful to you?
Yes
No
I rate this neutrally because I am the original author of Class::Tangram, and current maintainer of Tangram.
On first inspection, this module does not appear to implement any of the features of Tangram. It implements many of the features of the Class::Tangram accessor generation package. The distinction and seperation between the two parts is one thing that Aaron appears to have missed, and a key to the great flexibility of Tangram to use whatever accessor package you like.
So Pint Is (definitely) Not (anything even resembling) Tangram.
Sam Vilain - 2004-11-24 13:06:21
Was this review helpful to you?
Yes
No
It is the quality of our work which will please God and not the
quantity.
-- Mahatma Gandhi
Sam Vilain - 2004-10-13 13:41:15
Was this review helpful to you?
Yes
No
I will surely enjoy releasing my packages into Your::Momma
Sam Vilain - 2004-08-16 16:05:09
Was this review helpful to you?
Yes
No
This module provides for development coverage testing in a far superior manner to other approaches like Devel::Coverage. The way it works is by replacing the `runops' C function in the middle of Perl - and this extremely low-level approach is the only way to ensure that your coverage tests are complete and transparent (apart from a minor performance penalty).
Paul Johnson explained the topic well at YAPC::Europe 2003.
Watch out for a funky new report format with newer versions!
Sam Vilain - 2003-08-21 07:38:24
Was this review helpful to you?
Yes
No
Allow me to go against the grain here, but the only thing that mod_perl has going for it is that it is widely known and a lot of material and modules have been written for it.
Architecturally, it's a poor choice for building dynamic web applications. The problem is that the same process(es) are serving simple files as well as generating dynamic pages. This means that while images, etc are being served to clients by apache processes, all of the memory consumed by the Perl interpreter is essentially wasted.
The answer involves:
* hacking your application to fork() at just the right moment (which helps but doesn't address the real problem)
* setting up a Squid `reverse proxy' (Squid, using a select() loop model, is a far more efficient web server than Apache)
* running another version of Apache that the first one forwards requests to - the two processes communicating via HTTP.
* Using Apache/mod_perl 2.0, and hope that the threading model is stable enough for you.
It is also not possible (without installing a seperate Apache instance for each user) to use the Unix process model to seperate scripts for different web sites to run with the permissions of different users, for instance. Using Apache's `suexec' feature is incompatible with mod_perl and effectively reduces you to CGI performance.
It is widely accepted that once you hit a certain traffic level, you need to seperate front end processing from building dynamic page requests, and HTTP was not really designed for this; it works most of the time, but the integration is far from seamless.
People mention that some of the biggest sites in the world (Slashdot seems to be a common example, for some reason) use mod_perl, but they do not mention the blood, sweat and tears that were involved. Actually, the biggest sites in the world use extremely small web server processes, and binary-optimized protocols to talk to the real applications - these include NSAPI (SunOne/Netscape iPlanet), ISAPI (IIS), etc.
There is a binary optimized, Open Market standard that was designed for just this - FastCGI. See the FCGI module on CPAN and http://www.fastcgi.com/. FastCGI typically adapts quickly into Web Applicaiton Development Frameworks, and can increase performance markedly whilst requiring a lot less memory. FastCGI works with Apache, and the performance is on a par with mod_perl (actually, typically the performance is less subject to fluctuations).
It is for these reasons that I hold my opinion that Apache/mod_perl will be one day seen in the same light as Sendmail - filled with the cruft of years of creeping featuritis.
Sam Vilain - 2003-08-21 07:20:35
Was this review helpful to you?
Yes
No
|
Perl.org sites
: bugs
| dev
| history
| jobs
| learn
| lists
| use
Site Information and Contacts |
|