Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, 10 Feb 2004, Simon Cozens wrote: > Hrm, there isn't an easy way to say this, but an issue with module > reviews is that they're generally written by someone with a particular > bias towards their own solution. (I say that as someone who wrote one > too ;) > > That's not necessarily a problem if they're presented as a "I took a > look at the options and this is why I'm doing it my way", but is not > all it could be if it is presented as an unbiased review. One way to ameliorate this is to allow others to contribute. For the POOP comparison, I've taken contributions from other module authors describing their modules and/or correcting my mistakes in describing them, so hopefully it's a bit more balanced. For the date/time stuff, it's obvious from my perl.com article that I considered the situation hopeless, I think ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Finding the module you want
* Eric Cholet <[EMAIL PROTECTED]> [2004-02-10 18:51]: > There is of course another category of modules that I use, > larger systems such as a templating module, or a date module. > For those, I have found that hanging around mailing lists and > forums quickly point me to the better alternatives. And that's exactly the process I think could be leveraged to build these comparative articles. I wasn't thinking of a single person writing an entire and exhaustive article on a subject. Exactly how it works would be a per-article issue; in some cases there might be one author who mostly maintains it themselves, or it could be someone taking "patches", or it might be a bunch of people writing mostly about the module they know best and addressing each other's points, or it might be maintained via a wiki.. I don't know. I don't think any single procedure is going to fit every domain here. This space intentionally left open. I'm just gunning for the simplest thing that could possibly work, here -- and we already have pretty much all the infrastructure for this suggestion in place. And if Perrin, Mark, and the others who have already written such articles on other occasions would make them available this way, we'd already have a sizable amount of tasks and popular modules covered. The selection isn't expected to be very large either. A single comparative article covers a broad spectrum enough that having just a dozen of them would probably account for 95% of the tasks people use CPAN modules for. I really think we don't need a whole lot to make this work well enough; we only need a small amount of an unfortunately extremely scarce resource -- people with interest and experience in a domain enough to be able and willing to write such articles, and (less effortsome) occasionally update them. And maybe one driven individual to organize the entire effort in the very beginning. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Finding the module you want (was: New module Mail::SendEasy)
* Mark Stosberg <[EMAIL PROTECTED]> [2004-02-10 16:31]: > With Perl modules, I think there is typically less on the line > than $100,000 contracts. I found in my own experience that > people are generally trustworthy. Precisely this lack of consequence actually makes me feel it might be more problematic. Cf popularity contest. > It's primary downfall now is that it's simply not being used a > lot. Making further barriers to using it would only serve to > work this worse. I certainly agree. > If the system is highly used and slightly abused (say 1%), the > ratings should still remain useful. That's precisely why I'm weary of incentive to abuse.. :) I don't know; this is mostly gut feeling. I am likely too suspicious; I just can't shake the unease. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, Feb 10, 2004 at 09:03:27AM -0600, Dave Rolsky wrote: > On Tue, 10 Feb 2004, A. Pagaltzis wrote: > > > * It's better to have comparative articles than module centric > > reviews; they're also less susceptible to manipulation. > > I think these are great. The problem is they're a lot of work. I've > written two (POOP and date/time) and I know Perrin wrote one for > templating systems. They require you to look at _lots_ of modules and > also to have a good understanding of all the problems that need to be > solved in the area. Comparative articles are an incredible amount of work, especially for problem domains with a lot of options. They're even more work when the author has a vested interest in one of the modules being compared. He must take extra precautions to enforce objectivity. Anything less, and the conflict of interest will almost assuredly tip the scales in his module's favor. Consider comparative benchmarks as an example. It's a lot of work to negate bias towards modules the author is more familiar with. Maybe Open Source needs an objective reviewing organization like Consumer Union (http://www.consumerreports.org/). They could compare programming languages, text editors, and operating systems. A number of long-standing holy wars could be ended once and for all. :) -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Finding the module you want (was: New module Mail::SendEasy)
[EMAIL PROTECTED] (Dave Rolsky) writes: > On Tue, 10 Feb 2004, A. Pagaltzis wrote: > > > * It's better to have comparative articles than module centric > > reviews; they're also less susceptible to manipulation. > > I think these are great. The problem is they're a lot of work. I've > written two (POOP and date/time) and I know Perrin wrote one for > templating systems. Hrm, there isn't an easy way to say this, but an issue with module reviews is that they're generally written by someone with a particular bias towards their own solution. (I say that as someone who wrote one too ;) That's not necessarily a problem if they're presented as a "I took a look at the options and this is why I'm doing it my way", but is not all it could be if it is presented as an unbiased review. -- Life would be so much easier if we could just look at the source code. -- Dave Olson
Re: Finding the module you want (was: New module Mail::SendEasy)
Le 10 févr. 04, à 17:29, darren chamberlain a écrit : * Eric Cholet [2004/02/10 17:27]: Le 10 f?vr. 04, ? 16:16, darren chamberlain a ?crit : I agree with you, but, if you are already investigating software to handle a task, wouldn't you look at as many alternatives as possible? I certainly wouldn't. Rather, I would look at as many alternatives as necessary until I find the module that does what I want with an API that suits me. More often than not it's been the first candidate. But how would you know you found the right one if you don't look at all of them? The first might look good, but the second might be even better. What's "the" right one? "A" right one is one that solves my particular problem, and doesn't make jump through hoops. Most of the time the module does one specific thing, and if I can just call methods to do that, then that's "good enough". There are some external factors, for example when I was looking for a logging module I looked at Log::Dispatch first because I have previous satisfaction with its author's work. There is of course another category of modules that I use, larger systems such as a templating module, or a date module. For those, I have found that hanging around mailing lists and forums quickly point me to the better alternatives. For those the time/budget issue is even more crucial because they take more effort and time to evaluate. -- Eric Cholet
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, Feb 10, 2004 at 05:27:11PM +0100, Eric Cholet wrote: > Le 10 f?vr. 04, ? 16:16, darren chamberlain a ?crit : > > >I agree with you, but, if you are already investigating software to > >handle a task, wouldn't you look at as many alternatives as possible? > > I certainly wouldn't. Rather, I would look at as many alternatives > as necessary until I find the module that does what I want with > an API that suits me. More often than not it's been the first candidate. Likewise, considering projects have budgets and timelines, I'd likely stop at the first one that seemed "good enough". Mark
Re: Finding the module you want (was: New module Mail::SendEasy)
* Eric Cholet [2004/02/10 17:27]: > Le 10 f?vr. 04, ? 16:16, darren chamberlain a ?crit : > > >I agree with you, but, if you are already investigating software to > >handle a task, wouldn't you look at as many alternatives as possible? > > I certainly wouldn't. Rather, I would look at as many alternatives > as necessary until I find the module that does what I want with > an API that suits me. More often than not it's been the first candidate. But how would you know you found the right one if you don't look at all of them? The first might look good, but the second might be even better. (darren) -- It is impossible to experience one's death objectively and still carry a tune. -- Woody Allen pgp0.pgp Description: PGP signature
Re: Finding the module you want (was: New module Mail::SendEasy)
Le 10 févr. 04, à 16:16, darren chamberlain a écrit : I agree with you, but, if you are already investigating software to handle a task, wouldn't you look at as many alternatives as possible? I certainly wouldn't. Rather, I would look at as many alternatives as necessary until I find the module that does what I want with an API that suits me. More often than not it's been the first candidate. -- Eric Cholet
Re: Finding the module you want (was: New module Mail::SendEasy)
* Dave Rolsky [2004/02/10 09:03]: > On Tue, 10 Feb 2004, A. Pagaltzis wrote: > > > * It's better to have comparative articles than module centric > > reviews; they're also less susceptible to manipulation. > > I think these are great. The problem is they're a lot of work. I've > written two (POOP and date/time) and I know Perrin wrote one for > templating systems. They require you to look at _lots_ of modules and > also to have a good understanding of all the problems that need to be > solved in the area. I agree with you, but, if you are already investigating software to handle a task, wouldn't you look at as many alternatives as possible? I think the trick is to write down your observations after you do one of these exhaustive searches. For example, IIRC, Perrin wrote his templating comparison paper because he spent a lot of time researching the templating systems anyway. (darren) -- An idea is not responsible for the people who believe in it. pgp0.pgp Description: PGP signature
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, 10 Feb 2004, Dave Rolsky wrote: > On Tue, 10 Feb 2004, A. Pagaltzis wrote: > > > * It's better to have comparative articles than module centric > > reviews; they're also less susceptible to manipulation. > > I think these are great. The problem is they're a lot of work. I've > written two (POOP and date/time) and I know Perrin wrote one for > templating systems. They require you to look at _lots_ of modules and > also to have a good understanding of all the problems that need to be > solved in the area. > > Not that I'm trying to discourage anyone, just pointing out that it's a > non-trivial task. I can concurr. I have written a bunch about XML modules (http://xmltwig.com/article/) and even the simplest ones, like the Ways to Rome series, take quite a long time to write. -- Michel Rodriguez Perl & XML http://www.xmltwig.com
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, Feb 10, 2004 at 09:59:32AM +0100, A. Pagaltzis wrote: > * Mark Stosberg <[EMAIL PROTECTED]> [2004-02-09 15:26]: > > I think the CPAN rating system could be of further help here as > > well. It could be integrated with the search.cpan.org search > > engine. The rating could appear on the results page, with > > top-rated modules appearing first. So, just searching for a > > module named "mail" should be begin to give you a sensible > > result. > > I like this proposition. However I'm just not sure I a) want it > used with no way to disable it b) want it used as the default. > > > This public prominence would also encourage more people to use > > the system, I believe. > > It would also encourage abuse, unfortunately. Not in my experience. I run http://www.skatepark.org/ , which allows for easy account sign up, at which point you can rate and review things. The most useful ratings and reviews are of the Skatepark developers. Skatepark contracts are typically for $100,000 or more, so selecting a skatepark contractor is a big deal. There was a lot of controversy when I launched the system. All the skatepark developers warned that their competitors would abuse it. Knowing some of their tactics and behaviors, I actually thought they might. :) But I was willing to try. That's been in place for some years now, and I personally look at all the ratings. I have no sense that the system has ever been abused. Sometimes people may rate themselves (once!). But that happens even less than with Perl module authors!. Sometimes I think developers ask clients to rate them, but the reviews seem fair enough, and I think that is reasonable. With Perl modules, I think there is typically less on the line than $100,000 contracts. I found in my own experience that people are generally trustworthy. I think it would be quite sufficient to have some way to flag reviews (or users) that appear to be abusive. From another angle, I see the current problem with the rating system is not abuse-- I've never noticed any beyond people rating their own modules with 5 stars with reviews like "It's my module". It's primary downfall now is that it's simply not being used a lot. Making further barriers to using it would only serve to work this worse. If the system is highly used and slightly abused (say 1%), the ratings should still remain useful. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark StosbergPrincipal Developer [EMAIL PROTECTED] Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, 10 Feb 2004, A. Pagaltzis wrote: > * It's better to have comparative articles than module centric > reviews; they're also less susceptible to manipulation. I think these are great. The problem is they're a lot of work. I've written two (POOP and date/time) and I know Perrin wrote one for templating systems. They require you to look at _lots_ of modules and also to have a good understanding of all the problems that need to be solved in the area. Not that I'm trying to discourage anyone, just pointing out that it's a non-trivial task. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Testing output to STDOUT and STDERR
> Hi, I also have a lot of stuff to bundle! I can even arrange to produce > unbundled code so you can practice your bundling skills. You can make a > reputation as "Lester the Bundler". It's not like I need practice in make a distro. I just wanna help along the stuff that I think sounds useful... xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Testing output to STDOUT and STDERR
"Andy Lester" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Because: > > a) I wasn't happy with the API > > b) I'm a lazy SOB and couldn't find the time to sort it out > > I'll be glad to help with the second part. Mail me the parts and I'll > bundle it up all nice for ya. Hi, I also have a lot of stuff to bundle! I can even arrange to produce unbundled code so you can practice your bundling skills. You can make a reputation as "Lester the Bundler". ;-) Nadim.
Re: Testing output to STDOUT and STDERR
* Adriano R. Ferreira <[EMAIL PROTECTED]> [2004-02-09 01:56]:
> While writing tests for some of my code, I was faced with the issue
> of capturing what the code sends to STDOUT and STDERR. As I have not
> found a module to make it easy, I wrote a trivial code to do it. It
> is used like this:
>
> use Test::More tests => 2;
> use Seize qw(seize release);
>
> my ($out, $err);
>
> seize \$out, \$err; # from here on, STDOUT and STDERR are seized
>
> print "1\n";
> warn "2\n";
> print "3\n";
> eval { die "4\n"; }
>
> release; # here STDOUT and STDERR are released
>
> is($out, "1\n3\n");
> is($err, "2\n3\n");
>
> My doubt is if this deserves a module: maybe it would be better
> to use idioms commonly employed to this kind of task. Maybe
> there is some module I am overlooking that already does that.
For Perl 5.8 (and 5.6 with IO::String? I think it works there)
it's trivial:
use Test::More tests => 2;
use Carp;
sub string_fh {
open my $fh, '>', $_[0]
or croak "Couldn't open scalar as filehandle: $!\n";
return $fh;
}
my ($out, err);
{
local STDOUT, STDERR;
*STDOUT = string_fh \$out;
*STDERR = string_fh \$err;
print "1\n";
warn "2\n";
print "3\n";
eval { die "4\n"; }
}
is($out, "1\n3\n");
is($err, "2\n3\n");
I believe this is a lot more robust than a tie() solution as
well. But it isn't really modularizable due to the local() and
there's not much anyway to stick in a module. Another approach I
only have the time to sketch here:
use Test::More tests => 2;
use Carp;
sub redir_fh {
my ($fh, $mode, $file);
my $saved_fh;
# dup $fh in here
open $fh, $mode, $file
# not sure this msg makes sense..
or croak "Couldn't dup $fh to $file: $!\n";
return bless [ $fh, $saved_fh ], 'RestoreHandle';
}
sub RestoreHandle::DESTROY {
# use $self to dup the original FH back into the used one
}
my ($out, err);
{
my $s_out = redir_fh \*STDOUT, '>', \$out;
my $s_err = redir_fh \*STDERR, '>', \$err;
print "1\n";
warn "2\n";
print "3\n";
eval { die "4\n"; }
}
# $s_* went out of scope here..
is($out, "1\n3\n");
is($err, "2\n3\n");
which uses lexical variables to implement dynamic scoping. :)
--
Regards,
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
Re: Class::HPLOO - Need advice in attributes and object persistence for OODB.
* Sam Vilain <[EMAIL PROTECTED]> [2004-02-09 10:57]: > This wheel has been re-invented far too many times already. That has never bothered some people. :) -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Finding the module you want (was: New module Mail::SendEasy)
* Mark Stosberg <[EMAIL PROTECTED]> [2004-02-09 15:26]: > I think the CPAN rating system could be of further help here as > well. It could be integrated with the search.cpan.org search > engine. The rating could appear on the results page, with > top-rated modules appearing first. So, just searching for a > module named "mail" should be begin to give you a sensible > result. I like this proposition. However I'm just not sure I a) want it used with no way to disable it b) want it used as the default. > This public prominence would also encourage more people to use > the system, I believe. It would also encourage abuse, unfortunately. In the current form of the system, it's *very* easy to sign up with a few different names and write a bunch of reviews rating a module well. Not that I really want this changed; I like the simplicity of CPANRatings.org. But if you want to use it for something like your proposition, you need a tighter system. Unfortunately no solution is going to be foolproof, only somewhat more or somewhat less problematic, which is why I feel uneasy about the idea. Hmm.. Ok, in thinking about it, I had an idea; I'll lay out how I got there. * It's better to have comparative articles than module centric reviews; they're also less susceptible to manipulation. * Maybe we could have a bunch of comparative articles about modules for certain common tasks, being presented on search.cpan.org for appropriate searches. * Wait, there's already a way to put results in the search engine -- namely, uploading a distribution.. How about putting writing such comparative articles and posting them under Introduction:: ? Like, Introduction::Ways_to_send_and_read_Mail_with_Perl -- I know the name is ugly, but it has to work within the constraints of module names. Ideally, search.cpan.org would rank these as the top hits when they're matched. Funnily enough, the review system already in place would immediately work for these as well, so people could review the reviews.. :) What does everyone think about the idea? I like it more the more I think about it. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
