| CPAN Ratings (Gamma) Reviews by Steffen Schwigon | |
| Home | Search | About | Login |
RSS | Module Info | Add a review of
3 out of 6 found this review helpful:
This module would be soooo nice and useful if it wouldn't break all filename globbing globally in other modules.
Therefore I strongly suggest moving this module below the Acme:: namespace where you can expect such things.
See bug
http://rt.cpan.org/Ticket/Display.html?id=27286
for some details.
*UPDATE:*
This issue is fixed with v0.0.5.
I therefore raised my overall rating. Thanks.
Steffen Schwigon - 2008-05-15 23:26:07
Was this review helpful to you?
Yes
No
I really like it.
This module helps surviving in a multi-language work environment where you need to participate in the discussion about the typical Perl FUD. And, admittedly, it really adds even more beauty and readability to your code.
I used it in the context of a Moose'ified and RPC:XML::Server-based application, providing an IMHO sufficiently complex environment of subs and methods that finally gave me a good feeling about this module, not being that alpha grade as it calls itself.
I would, of course, really appreciate it if the trailing semicolon after a method can be avoided. But currently the advantages in readability are worth it.
Steffen Schwigon - 2008-05-13 08:13:31
Was this review helpful to you?
Yes
No
I'm a long term user of this module, even before it's existence on CPAN. This module works good for me.
Why only 3 stars?
Generally it's good that this module is now on CPAN after it was hidden from most of the world on a japanese site. Unfortunately there are some issues with it:
- The file should use a lib path that matches its namespace, i.e., lib/DBIx/Class/Schema/Loader/DBI/Oracle.pm.
- It should be merged into the DBIx-Class-Schema-Loader package. In fact it already exists there but is hidden from pause indexer. (Strangely this only works because of it's original wrong lib path, see first point above.)
- It has documentation issues, eg. it uses "Postgres" in its description, probably because it was forked from that package. It's not that critical but such things make the user unsure. The hidden instance in DBIx-Class-Schema-Loader already fixed that.
My suggestion: Merge and fix the documentation (eg. the DBD::Oracle speed hint) into the DBIx-Class-Schema-Loader instance, no longer hide that other instance from indexer and take this instance here away again from CPAN.
I know, that it's a pity to give up on modules for the sake of authors reputation, but having it central in DBIx-Class-Schema-Loader is more worthy for the users. Maybe just incrementing version number in the DBIx-Class-Schema-Loader instance solves the reputation problem.
Steffen Schwigon - 2007-11-14 03:04:22
Was this review helpful to you?
Yes
No
CPAN.pm was of so high quality for so many years that I simply want to say Thank You for this module.
Some time ago I very often heard that CPAN.pm had too difficult internals, everything would be quirky and unmaintainable, etc. This might be true, I don't know and I don't care, because CPAN.pm (or better say its author) *never* let me alone. It always worked very robust for me on different platforms and with practically every version of it I tried.
It especially worked much more reliable than its designated successsor CPANPLUS. I tried to switch to CPANPLUS some years ago but switched back to CPAN.pm simply because of the much higher reliability.
And since the once stalled development resumed with support for Module::Build, CPAN::Reporter, etc., my CPAN world is in perfect balance.
Steffen Schwigon - 2006-10-20 16:16:54
Was this review helpful to you?
Yes
No
I'm coming from the explicit DBI/DBD/SQL programming world and are just switching/learning to the way of ORM. Therefore my point of view is rather at a beginner level.
DBIx class is really nice if you follow the path of the examples with widespread open source databases like MySQL. I mostly used it from within Catalyst and I got practically all simple and enhanced query problems solved quite elegant without programming in SQL.
So, why not 5 stars?
Because the documentation may become very confusing once you have to use another database system (Oracle in my case) and the basic examples are not enough or you need to do manually what normally Catalyst helper scripts do for you.
Then the documentation too often says "see This::Other::Related::Module". This might be true but requires you to understand each of those other related modules and to click through the hell of the circular dependencies between all those modules which is very annoying once you lost the thread. All this got worse when some of similar modules or some single methods just went deprecated. I really got lost there.
I wish the documentation would simply be more explicit even if that means doubling some prose and examples. Currently it feels a bit too much from a point of view of advanced regular DBIx::Class users.
Update 2008-05-30: I raise my rating to 5 stars. The docs got better and it's so worth all the effort to understand this ORM because it gets more and more fun the more you get used to it and the community on irc helps you with every problem within minutes. What else should they do to earn 5 stars?
Steffen Schwigon - 2006-07-05 03:42:27
Was this review helpful to you?
Yes
No
Mason is a very perlish templating tool.
It is extremely powerful, although by using Perl as its template language it desires some discipline to take care of separating logic and layout.
Self decided discipline is what a Perl programmer needs anyway in larger projects, so it's ok, but don't expect your non-Perl project fellows to love mason templates.
With Mason you can do with your layout code (the templates) what you do with your normal code all the time: restructure every snippet that occurs to be reusable. Masons well-thought component API allows you to do this in various ways: with OO like inheritance, function or macro like calls or just "classical" template including.
There is syntactic sugar everywhere, exactly when you just realise you could need a feature there. Example is the filtering of output with or without entity encoding.
For web programming I prefer Mason over Template-Toolkit (which in turn I prefer for strange text templating, so it's no criticism of TT).
The only thing that I don't like is its prerequisite to Apache::Request which in turn tries to install libapreq which in turn is, depending on the OS, a "challenge" (to avoid the word "problem") for itself and practically everytime better installed with the OS distribution tools or by the sysadmin. I don't know why this dependency is set because Mason can be used without Apache or mod_perl, e.g. with Catalyst. Maybe a historical legacy. I would like to see that coupling divided.
Another thing that might take some time is to customize you editor for mixing highlighting of Mason/HTML and Perl syntax. At least with Emacs it kept me awake some time to fiddle with MMM-mode.
Steffen Schwigon - 2006-04-06 01:15:26
Was this review helpful to you?
Yes
No
I like the idea of this module and even tried to reuse its contained collection of regexes, servers and answer types. Unfortunately it's probably too old to really recognize and handle most of the currently typical answers from whois servers.
I took Net::Whois::Raw instead and did some heuristically regexing for myself.
Steffen Schwigon - 2005-08-16 00:34:23
Was this review helpful to you?
Yes
No
Sorry, I can't share the euphoria.
I try and retry YAML once a year. I'm really willing to give it a
chance but I'm still unsuccessful.
YAML calls itself a data serialization language. And that's exactly
what I can't do without fear. For years now.
In the early days it misinterpreted hash keys and values in subtle,
hard to expose ways (leading zeros, version numbers and excessive
newline/carriage-return usage). Ok, with >= 0.37 the hard times of
ForceBlock seem to be gone, fine.
Now I fight with segmentation faults when my strings contain strange
characters (I can't reduce it to minimalistic data examples, sorry,
maybe I report my examples anyway, the longevity of unresolved bugs
on rt.cpan.org kept me away so far).
I don't want to think about the "right" content of my data when I use
something called "data serialization language". I like the good warm
feeling when using Perl for handling my data, and this feeling went
away every time I tried YAML.
In my understanding the root for the problems is the own data parsing
although using Perls parser (via eval) eventually would be more
robust. (Yes, I read about the advantages of not using Perl's eval.)
Don't get me wrong, I respect the idea, the YAML format itself and the
implementation, too. I just had problems with it since my first
try. More than with other CPAN modules.
Forgive me if I'm the only unlucky yaml fellow.
Steffen Schwigon - 2005-04-13 04:39:48
Was this review helpful to you?
Yes
No
I use it for some time. No problems from my linuxish point of view.
Steffen Schwigon - 2004-01-02 05:58:09
Was this review helpful to you?
Yes
No
I just wanted to rate my own package to get rid of those horrible question marks (now empty stars). And I use pod-mode everyday and it's really useful; pod-mode makes writing POD fun. Use it!
Steffen Schwigon - 2003-12-31 03:59:03
Was this review helpful to you?
Yes
No
|
Perl.org sites
: bugs
| dev
| history
| jobs
| learn
| lists
| use
Site Information and Contacts |
|