new module: Time::Seconds::GroupedBy #3

------=_NextPart_000_0022_01C468CF.DF6D2E90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,

I've made a new module, I'm thinking to call it =
Time::Seconds::GroupedBy. It
is designed to convert an amount of seconds in other time units. I'm =
calling
time units SECONDS, MINUTES, HOURS, DAYS, MONTHS, and YEARS . The user
defines which will be the time unit to group the amount of seconds.

Using my module, the following test code:

use strict;
my $seconds =3D 31556931;
foreach ('MINS', 'HOURS', 'DAYS', 'MONTHS', 'YEARS') {
            my $s =3D new GroupedBy ( $_ );
            my ($secs, $mins, $hours, $days, $months, $years) =3D
                        $s->calculate($seconds);
            print "Grouping by $_, $seconds seconds are:\n ",
                        "  $years years, $months months, $days days, =
$hours hours,",
                        " $mins mins, $secs seconds.\n\n";
}

Will bring this output:

Grouping by MINS, 31556931 seconds are:
   0 years, 0 months, 0 days, 0 hours, 525948 mins, 51 seconds.

Grouping by HOURS, 31556931 seconds are:
   0 years, 0 months, 0 days, 8765 hours, 48 mins, 51 seconds.

Grouping by DAYS, 31556931 seconds are:
   0 years, 0 months, 365 days, 5 hours, 48 mins, 51 seconds.

Grouping by MONTHS, 31556931 seconds are:
   0 years, 12 months, 5 days, 5 hours, 48 mins, 51 seconds.

Grouping by YEARS, 31556931 seconds are:
   1 years, 0 months, 0 days, 0 hours, 0 mins, 1 seconds.

The draft code of the module is bellow,

package GroupedBy;
sub new {
 my $class =3D shift;
 my $self =3D {};
 bless ( $self, $class );
 my $GroupedBy =3D shift;
 # Amount of Seconds input by the user (set by calculate() method)
 $self->{SECONDS};
 # Initializing data about years, months, days, hours and minutes;
 $self->{SECS}  =3D { result =3D> 0 };
 # A minute is 60 seconds
 $self->{MINS}  =3D { inSecs =3D> 60, opId =3D> 1, took =3D> 0, result =
=3D> 0 };
 # An hour is 60 * 60 seconds
 $self->{HOURS} =3D { inSecs =3D> 3600, opId =3D> 2, took =3D> 0, result =
=3D> 0 };
 # A day is 60 * 60 * 24 seconds
 $self->{DAYS}  =3D { inSecs =3D> 86400, opId =3D> 3, took =3D> 0, =
result =3D> 0 };
 # A month is 60 * 60 * 24 * 30 seconds
 $self->{MONTHS} =3D { inSecs =3D> 2592000, opId =3D> 4, took =3D> 0, =
result =3D> 0 };
 # Year is 60 * 60 * 24 * 365.24225 =3D 31556930.4 seconds (we'll ignore =
0.4 secs)
 $self->{YEARS}  =3D { inSecs =3D> 31556930, opId =3D> 5, took =3D> 0, =
result =3D> 0 };

 # OPID - operation ID, is a number indentifying the kind of grouping =
that
 # was chosen by the user. Each grouping requires a diferent operation =
to
 # calculate the resulting values.
 $self->{OPID} =3D $self->{$GroupedBy}->{opId};
 die "Unvalid value. Valid values are 'MINS', 'HOURS', 'DAYS', 'MONTHS', =
'YEARS'"
  unless defined $self->{OPID};

 return $self;
}

sub calculate { # returns: Array: the results of the calculus
 my $self =3D shift;
 $self->{SECONDS} =3D shift;
 $self->_clean();
 my @result =3D (  $self->_years(), $self->_months(), $self->_days(),
     $self->_hours(), $self->_mins(), $self->_secs() );
 return reverse @result;
}

sub groupedBy { # returns: String: the current GROUPED_BY type
 my $self =3D shift;
 my $GroupedBy =3D shift;
 $self->{OPID} =3D $self->($GroupedBy)->{opId};
 die "Unvalid value. Valid values are 'MINS', 'HOURS', 'DAYS', 'MONTHS', =
'YEARS'"
  unless defined $self->{OPID};
 return $GroupedBy;
}

# Cleans(set to 0)the 'took' and 'result' counters for all groups
sub _clean { # returns: nothing
 my $self =3D shift;
 foreach ( qw ( SECS MINS HOURS DAYS MONTHS YEARS ) ) {
  $self->{$_}->{took} =3D 0;
  $self->{$_}->{result} =3D 0;
 }
}

sub _secs { # returns: Integer: the result
 my $self =3D shift;
 my $name =3D "SECS";
 $self->{$name}->{result} =3D $self->{SECONDS} - $self->{YEARS}->{took}
   - $self->{MONTHS}->{took} - $self->{DAYS}->{took} - =
$self->{HOURS}->{took}
   - $self->{MINS}->{took};
 return $self->{$name}->{result};
}

sub _mins { # returns: Integer: the result
 my $self =3D shift;
 my $name =3D "MINS";
 if ( $self->{OPID} >=3D 1 ) {
  my $secsLeft =3D $self->{SECONDS} - $self->{YEARS}->{took}
   - $self->{MONTHS}->{took} - $self->{DAYS}->{took} - =
$self->{HOURS}->{took};
  $self->{$name}->{result} =3D int($secsLeft / =
$self->{$name}->{inSecs});
  if ( $self->{$name}->{result} !=3D 0 ) {
   $self->{$name}->{took} =3D $self->{$name}->{result} * =
$self->{$name}->{inSecs};
  }
 }
 return $self->{$name}->{result};
}

sub _hours { # returns: Integer: the result
 my $self =3D shift;
 my $name =3D "HOURS";
 if ( $self->{OPID} >=3D 2 ) {
  my $secsLeft =3D $self->{SECONDS} - $self->{YEARS}->{took}
   - $self->{MONTHS}->{took} - $self->{DAYS}->{took};
  $self->{$name}->{result} =3D int($secsLeft / =
$self->{$name}->{inSecs});
  if ( $self->{$name}->{result} !=3D 0 ) {
   $self->{$name}->{took} =3D $self->{$name}->{result} * =
$self->{$name}->{inSecs};
  }

 }
 return $self->{$name}->{result};
}

sub _days { # returns: Integer: the result
 my $self =3D shift;
 my $name =3D "DAYS";
 if ( $self->{OPID} >=3D 3 ) {
  my $secsLeft =3D $self->{SECONDS} - $self->{YEARS}->{took} - =
$self->{MONTHS}->{took};
  $self->{$name}->{result} =3D int($secsLeft / =
$self->{$name}->{inSecs});
  if ( $self->{$name}->{result} !=3D 0 ) {
   $self->{$name}->{took} =3D $self->{$name}->{result} * =
$self->{$name}->{inSecs};
  }
 }
 return $self->{$name}->{result};
}

sub _months { # returns: Integer: the result
 my $self =3D shift;
 my $name =3D "MONTHS";
 if ( $self->{OPID} >=3D 4 ) {
  my $secsLeft =3D $self->{SECONDS} - $self->{YEARS}->{took};
  $self->{$name}->{result} =3D int($secsLeft / =
$self->{$name}->{inSecs});
  if ( $self->{$name}->{result} !=3D 0 ) {
   $self->{$name}->{took} =3D $self->{$name}->{result} * =
$self->{$name}->{inSecs};
  }
 }
 return $self->{$name}->{result};
}

sub _years { # returns: Integer: the result
 my $self =3D shift;
 my $name =3D "YEARS";
 if ( $self->{OPID} =3D=3D 5 ) {
  $self->{$name}->{result} =3D int($self->{SECONDS} / =
$self->{$name}->{inSecs});
  if ( $self->{$name}->{result} !=3D 0 ) {
   $self->{$name}->{took} =3D $self->{$name}->{result} * =
$self->{$name}->{inSecs};
  }
 }
 return $self->{$name}->{result};
}

Any suggestions? Opinions? questions? etc....

A hug for everybody,
Bruno Negr=E3o





------=_NextPart_000_0022_01C468CF.DF6D2E90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Hi=20
all,<BR><BR>I've made a new module, I'm thinking to call it=20
Time::Seconds::GroupedBy. It<BR>is designed to convert an amount of =
seconds in=20
other time units. I'm calling<BR>time units SECONDS, MINUTES, HOURS, =
DAYS,=20
MONTHS, and YEARS . The user<BR>defines which will be the time unit to =
group the=20
amount of seconds.<BR><BR>Using my module, the following test =
code:<BR><BR>use=20
strict;<BR>my $seconds =3D 31556931;<BR>foreach ('MINS', 'HOURS', =
'DAYS',=20
'MONTHS', 'YEARS')=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
my $s =3D=20
new GroupedBy ( $_=20
);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
my=20
($secs, $mins, $hours, $days, $months, $years)=20
=3D<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

$s-&gt;calculate($seconds);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
print "Grouping by $_, $seconds seconds are:\n=20
",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
"&nbsp; $years years, $months months, $days days, $hours=20
hours,",<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
" $mins mins, $secs seconds.\n\n";<BR>}<BR><BR>Will bring this=20
output:<BR><BR>Grouping by MINS, 31556931 seconds are:<BR>&nbsp;&nbsp; 0 =
years,=20
0 months, 0 days, 0 hours, 525948 mins, 51 seconds.<BR><BR>Grouping by =
HOURS,=20
31556931 seconds are:<BR>&nbsp;&nbsp; 0 years, 0 months, 0 days, 8765 =
hours, 48=20
mins, 51 seconds.<BR><BR>Grouping by DAYS, 31556931 seconds =
are:<BR>&nbsp;&nbsp;=20
0 years, 0 months, 365 days, 5 hours, 48 mins, 51 =
seconds.<BR><BR>Grouping by=20
MONTHS, 31556931 seconds are:<BR>&nbsp;&nbsp; 0 years, 12 months, 5 =
days, 5=20
hours, 48 mins, 51 seconds.<BR><BR>Grouping by YEARS, 31556931 seconds=20
are:<BR>&nbsp;&nbsp; 1 years, 0 months, 0 days, 0 hours, 0 mins, 1=20
seconds.<BR><BR>The draft code of the module is bellow,<BR><BR>package=20
GroupedBy;<BR>sub new {<BR>&nbsp;my $class =3D shift;<BR>&nbsp;my $self =
=3D=20
{};<BR>&nbsp;bless ( $self, $class );<BR>&nbsp;my $GroupedBy =3D =
shift;<BR>&nbsp;#=20
Amount of Seconds input by the user (set by calculate()=20
method)<BR>&nbsp;$self-&gt;{SECONDS};<BR>&nbsp;# Initializing data about =
years,=20
months, days, hours and minutes;<BR>&nbsp;$self-&gt;{SECS}&nbsp; =3D { =
result=20
=3D&gt; 0 };<BR>&nbsp;# A minute is 60 =
seconds<BR>&nbsp;$self-&gt;{MINS}&nbsp; =3D {=20
inSecs =3D&gt; 60, opId =3D&gt; 1, took =3D&gt; 0, result =3D&gt; 0 =
};<BR>&nbsp;# An=20
hour is 60 * 60 seconds<BR>&nbsp;$self-&gt;{HOURS} =3D { inSecs =3D&gt; =
3600, opId=20
=3D&gt; 2, took =3D&gt; 0, result =3D&gt; 0 };<BR>&nbsp;# A day is 60 * =
60 * 24=20
seconds<BR>&nbsp;$self-&gt;{DAYS}&nbsp; =3D { inSecs =3D&gt; 86400, opId =
=3D&gt; 3,=20
took =3D&gt; 0, result =3D&gt; 0 };<BR>&nbsp;# A month is 60 * 60 * 24 * =
30=20
seconds<BR>&nbsp;$self-&gt;{MONTHS} =3D { inSecs =3D&gt; 2592000, opId =
=3D&gt; 4, took=20
=3D&gt; 0, result =3D&gt; 0 };<BR>&nbsp;# Year is 60 * 60 * 24 * =
365.24225 =3D=20
31556930.4 seconds (we'll ignore 0.4 =
secs)<BR>&nbsp;$self-&gt;{YEARS}&nbsp; =3D {=20
inSecs =3D&gt; 31556930, opId =3D&gt; 5, took =3D&gt; 0, result =3D&gt; =
0=20
};<BR><BR>&nbsp;# OPID - operation ID, is a number indentifying the kind =
of=20
grouping that<BR>&nbsp;# was chosen by the user. Each grouping requires =
a=20
diferent operation to<BR>&nbsp;# calculate the resulting=20
values.<BR>&nbsp;$self-&gt;{OPID} =3D=20
$self-&gt;{$GroupedBy}-&gt;{opId};<BR>&nbsp;die "Unvalid value. Valid =
values are=20
'MINS', 'HOURS', 'DAYS', 'MONTHS', 'YEARS'"<BR>&nbsp; unless defined=20
$self-&gt;{OPID};<BR><BR>&nbsp;return $self;<BR>}<BR><BR>sub calculate { =
#=20
returns: Array: the results of the calculus<BR>&nbsp;my $self =3D=20
shift;<BR>&nbsp;$self-&gt;{SECONDS} =3D=20
shift;<BR>&nbsp;$self-&gt;_clean();<BR>&nbsp;my @result =3D (&nbsp;=20
$self-&gt;_years(), $self-&gt;_months(),=20
$self-&gt;_days(),<BR>&nbsp;&nbsp;&nbsp;&nbsp; $self-&gt;_hours(),=20
$self-&gt;_mins(), $self-&gt;_secs() );<BR>&nbsp;return reverse=20
@result;<BR>}<BR><BR>sub groupedBy { # returns: String: the current =
GROUPED_BY=20
type<BR>&nbsp;my $self =3D shift;<BR>&nbsp;my $GroupedBy =3D=20
shift;<BR>&nbsp;$self-&gt;{OPID} =3D=20
$self-&gt;($GroupedBy)-&gt;{opId};<BR>&nbsp;die "Unvalid value. Valid =
values are=20
'MINS', 'HOURS', 'DAYS', 'MONTHS', 'YEARS'"<BR>&nbsp; unless defined=20
$self-&gt;{OPID};<BR>&nbsp;return $GroupedBy;<BR>}<BR><BR># Cleans(set =
to 0)the=20
'took' and 'result' counters for all groups<BR>sub _clean { # returns:=20
nothing<BR>&nbsp;my $self =3D shift;<BR>&nbsp;foreach ( qw ( SECS MINS =
HOURS DAYS=20
MONTHS YEARS ) ) {<BR>&nbsp; $self-&gt;{$_}-&gt;{took} =3D 0;<BR>&nbsp;=20
$self-&gt;{$_}-&gt;{result} =3D 0;<BR>&nbsp;}<BR>}<BR><BR>sub _secs { # =
returns:=20
Integer: the result<BR>&nbsp;my $self =3D shift;<BR>&nbsp;my $name =3D=20
"SECS";<BR>&nbsp;$self-&gt;{$name}-&gt;{result} =3D $self-&gt;{SECONDS} =
-=20
$self-&gt;{YEARS}-&gt;{took}<BR>&nbsp;&nbsp; - =
$self-&gt;{MONTHS}-&gt;{took} -=20
$self-&gt;{DAYS}-&gt;{took} - =
$self-&gt;{HOURS}-&gt;{took}<BR>&nbsp;&nbsp; -=20
$self-&gt;{MINS}-&gt;{took};<BR>&nbsp;return=20
$self-&gt;{$name}-&gt;{result};<BR>}<BR><BR>sub _mins { # returns: =
Integer: the=20
result<BR>&nbsp;my $self =3D shift;<BR>&nbsp;my $name =3D =
"MINS";<BR>&nbsp;if (=20
$self-&gt;{OPID} &gt;=3D 1 ) {<BR>&nbsp; my $secsLeft =3D =
$self-&gt;{SECONDS} -=20
$self-&gt;{YEARS}-&gt;{took}<BR>&nbsp;&nbsp; - =
$self-&gt;{MONTHS}-&gt;{took} -=20
$self-&gt;{DAYS}-&gt;{took} - $self-&gt;{HOURS}-&gt;{took};<BR>&nbsp;=20
$self-&gt;{$name}-&gt;{result} =3D int($secsLeft /=20
$self-&gt;{$name}-&gt;{inSecs});<BR>&nbsp; if ( =
$self-&gt;{$name}-&gt;{result}=20
!=3D 0 ) {<BR>&nbsp;&nbsp; $self-&gt;{$name}-&gt;{took} =3D=20
$self-&gt;{$name}-&gt;{result} * =
$self-&gt;{$name}-&gt;{inSecs};<BR>&nbsp;=20
}<BR>&nbsp;}<BR>&nbsp;return =
$self-&gt;{$name}-&gt;{result};<BR>}<BR><BR>sub=20
_hours { # returns: Integer: the result<BR>&nbsp;my $self =3D =
shift;<BR>&nbsp;my=20
$name =3D "HOURS";<BR>&nbsp;if ( $self-&gt;{OPID} &gt;=3D 2 ) =
{<BR>&nbsp; my=20
$secsLeft =3D $self-&gt;{SECONDS} - =
$self-&gt;{YEARS}-&gt;{took}<BR>&nbsp;&nbsp; -=20
$self-&gt;{MONTHS}-&gt;{took} - $self-&gt;{DAYS}-&gt;{took};<BR>&nbsp;=20
$self-&gt;{$name}-&gt;{result} =3D int($secsLeft /=20
$self-&gt;{$name}-&gt;{inSecs});<BR>&nbsp; if ( =
$self-&gt;{$name}-&gt;{result}=20
!=3D 0 ) {<BR>&nbsp;&nbsp; $self-&gt;{$name}-&gt;{took} =3D=20
$self-&gt;{$name}-&gt;{result} * =
$self-&gt;{$name}-&gt;{inSecs};<BR>&nbsp;=20
}<BR><BR>&nbsp;}<BR>&nbsp;return =
$self-&gt;{$name}-&gt;{result};<BR>}<BR><BR>sub=20
_days { # returns: Integer: the result<BR>&nbsp;my $self =3D =
shift;<BR>&nbsp;my=20
$name =3D "DAYS";<BR>&nbsp;if ( $self-&gt;{OPID} &gt;=3D 3 ) {<BR>&nbsp; =
my=20
$secsLeft =3D $self-&gt;{SECONDS} - $self-&gt;{YEARS}-&gt;{took} -=20
$self-&gt;{MONTHS}-&gt;{took};<BR>&nbsp; $self-&gt;{$name}-&gt;{result} =
=3D=20
int($secsLeft / $self-&gt;{$name}-&gt;{inSecs});<BR>&nbsp; if (=20
$self-&gt;{$name}-&gt;{result} !=3D 0 ) {<BR>&nbsp;&nbsp;=20
$self-&gt;{$name}-&gt;{took} =3D $self-&gt;{$name}-&gt;{result} *=20
$self-&gt;{$name}-&gt;{inSecs};<BR>&nbsp; }<BR>&nbsp;}<BR>&nbsp;return=20
$self-&gt;{$name}-&gt;{result};<BR>}<BR><BR>sub _months { # returns: =
Integer:=20
the result<BR>&nbsp;my $self =3D shift;<BR>&nbsp;my $name =3D =
"MONTHS";<BR>&nbsp;if=20
( $self-&gt;{OPID} &gt;=3D 4 ) {<BR>&nbsp; my $secsLeft =3D =
$self-&gt;{SECONDS} -=20
$self-&gt;{YEARS}-&gt;{took};<BR>&nbsp; $self-&gt;{$name}-&gt;{result} =
=3D=20
int($secsLeft / $self-&gt;{$name}-&gt;{inSecs});<BR>&nbsp; if (=20
$self-&gt;{$name}-&gt;{result} !=3D 0 ) {<BR>&nbsp;&nbsp;=20
$self-&gt;{$name}-&gt;{took} =3D $self-&gt;{$name}-&gt;{result} *=20
$self-&gt;{$name}-&gt;{inSecs};<BR>&nbsp; }<BR>&nbsp;}<BR>&nbsp;return=20
$self-&gt;{$name}-&gt;{result};<BR>}<BR><BR>sub _years { # returns: =
Integer: the=20
result<BR>&nbsp;my $self =3D shift;<BR>&nbsp;my $name =3D =
"YEARS";<BR>&nbsp;if (=20
$self-&gt;{OPID} =3D=3D 5 ) {<BR>&nbsp; $self-&gt;{$name}-&gt;{result} =
=3D=20
int($self-&gt;{SECONDS} / $self-&gt;{$name}-&gt;{inSecs});<BR>&nbsp; if =
(=20
$self-&gt;{$name}-&gt;{result} !=3D 0 ) {<BR>&nbsp;&nbsp;=20
$self-&gt;{$name}-&gt;{took} =3D $self-&gt;{$name}-&gt;{result} *=20
$self-&gt;{$name}-&gt;{inSecs};<BR>&nbsp; }<BR>&nbsp;}<BR>&nbsp;return=20
$self-&gt;{$name}-&gt;{result};<BR>}<BR><BR>Any suggestions? Opinions?=20
questions? etc....<BR><BR>A hug for everybody,<BR>Bruno=20
Negr=E3o</FONT><BR><BR><BR><BR><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0022_01C468CF.DF6D2E90--

0
bnegrao
7/13/2004 2:52:28 PM
perl.module-authors 1604 articles. 0 followers. Follow

87 Replies
670 Views

Similar Articles

[PageSpeed] 16
Get it on Google Play
Get it on Apple App Store

* Bruno Negr�o <bnegrao@engepel.com.br> [2004-07-13 22:02]:
> I've made a new module, I'm thinking to call it
> Time::Seconds::GroupedBy. It is designed to convert an amount
> of seconds in other time units. I'm calling time units SECONDS,
> MINUTES, HOURS, DAYS, MONTHS, and YEARS . The user defines
> which will be the time unit to group the amount of seconds.

Is there any reason to use it in preference to DateTime::Duration?

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/13/2004 8:35:52 PM
>
> Is there any reason to use it in preference to DateTime::Duration?
Hi Aristotle,

My module differs from DateTime::Duration because it is not dealing with dates. It does not try to foresee which is a future of past
date based in a bunch of seconds.

It just provide a means to calculate a "time quantity" that is more human readable than a big number of seconds.

For example, if you're making a big file transfer over the network everyday, and this transfer takes 7341 seconds to finish, and you
want to receive a report saying how much time the transfer took, indeed, you want to know that the file transfer took 2 hours, 2
minutes and 21 seconds (7341 seconds "grouped by" hours).

My module will calculate this conversion of seconds to a bigger "time group", HOURS, in this case.

To do this with my module you would:

#  - converting seconds to hours -
new $time = new Time::Seconds::GroupedBy('HOURS');
my ($secs, $mins, $hours) = $time->calculate(7341);
print "$hours hours $mins minutes $secs seconds\n";


So, if you have more seconds to calculate,  maybe hours is a small quantity, then you may chose to group seconds in a bigger group,
like DAYS. For example, to know that 734100 seconds are equivalent to  8 days, 11 hours, 55 mins, 0 seconds.

# - converting seconds to days -
$time->groubBy('DAYS');
my ($secs, $mins, $hours, $days) = $time->calculate(734100);


When "DAYS" is a small group, you could group them by "MONTHS", ultimately, by "YEARS".

Well, it's usefull for me. I didn't find yet a module providing this kind of conversion...

what do you think?

A hug,
bruno.

0
vpopmail
7/13/2004 9:51:33 PM
* Bruno Negr�o <vpopmail@engepel.com.br> [2004-07-13 23:53]:
> Hi Aristotle,
> 
> My module differs from DateTime::Duration because it is not
> dealing with dates. It does not try to foresee which is a
> future of past date based in a bunch of seconds.
> 
> It just provide a means to calculate a "time quantity" that is
> more human readable than a big number of seconds.

You mean, it deals with a... duration?

> To do this with my module you would:
> 
> #  - converting seconds to hours -
> new $time = new Time::Seconds::GroupedBy('HOURS');
> my ($secs, $mins, $hours) = $time->calculate(7341);
> print "$hours hours $mins minutes $secs seconds\n";

Ah, so you reinvented DateTime::Format::Duration.

    use DateTime::Format::Duration;
    my $fmt = DateTime::Format::Duration->new(
        pattern => '%H hours, %M minutes, %S seconds',
        normalize => 1,
    );
    print $fmt->format_duration_from_deltas(
        seconds => 7341,
    ), "\n";

> Well, it's usefull for me. I didn't find yet a module providing
> this kind of conversion...

I haven't done this before either. It took me about 10 minutes of
research on CPAN. Maybe my advantage was that I knew about the
DateTime project which set out to solve the issue of using Perl
for date and time math Once And For All.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/13/2004 11:14:09 PM
Hm

> > It just provide a means to calculate a "time quantity" that is
> > more human readable than a big number of seconds.
> 
> You mean, it deals with a... duration?
Can I call it "time quantity"?! ;-)


> Ah, so you reinvented DateTime::Format::Duration.
> 
>     use DateTime::Format::Duration;
>     my $fmt = DateTime::Format::Duration->new(
>         pattern => '%H hours, %M minutes, %S seconds',
>         normalize => 1,
>     );
>     print $fmt->format_duration_from_deltas(
>         seconds => 7341,
>     ), "\n";
> 
Oh, what a sadness. Indeed i never saw the DateTime project before.
But still my module is far easier to use than DateTime::Format::Duration.
Do you believe it is worth to publish it in Time::Seconds::GroupBy?

bruno.

0
vpopmail
7/14/2004 12:01:30 AM
On 7/13/2004 8:01 PM, Bruno Negr�o wrote:

> Oh, what a sadness. Indeed i never saw the DateTime project before.
> But still my module is far easier to use than DateTime::Format::Duration.
> Do you believe it is worth to publish it in Time::Seconds::GroupBy?

Not sadness, experience. Actually this was an exercise on the perl QotW 
(Quiz of the Week) mailing list[1]. So you are not the only one to write 
this code and then throw it away :-) It does seem this task is 
adequately provided for by at least 2 other modules, so...

Regards,
Randy.

1. <http://perl.plover.com/qotw/>


0
ml
7/14/2004 12:13:33 AM
On Wed, 14 Jul 2004, A. Pagaltzis wrote:

> Ah, so you reinvented DateTime::Format::Duration.

Actually, I think he reinvented Time::Seconds, which is part of the
Time::Piece distro.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
0
autarch
7/14/2004 1:23:21 AM
* Dave Rolsky <autarch@urth.org> [2004-07-14 03:25]:
> > Ah, so you reinvented DateTime::Format::Duration.
> 
> Actually, I think he reinvented Time::Seconds, which is part of
> the Time::Piece distro.

Well, both, I guess. Goes to show how many, *many* people have
written this sort of thing before in various forms and shapes.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/14/2004 12:36:40 PM
> >
> > Actually, I think he reinvented Time::Seconds, which is part of
> > the Time::Piece distro.
No guys, Time::Seconds doesn't give the same answer my module does. Time::Seconds converts seconds entirely in minutes or hours or
days or etc. For example, it says that 7341 seconds are:
2,03916 hours
122,35 minutes
0,08 days
etc.

I really Think i should extend Time::Seconds instead of publishing a new module, but i couldn�t contatc the authors of that module.

Time::Duration addresses the same calculation i'm doing, but the way it gives the answer is not that good.

i think i'gonna talk with DateTime group a litle bit, they are more inserted in this context.

thank you all,
bruno negrao.

0
vpopmail
7/14/2004 1:43:38 PM
On Tue, Jul 13, 2004 at 09:01:30PM -0300, Bruno Negr?o wrote:
>
> > Ah, so you reinvented DateTime::Format::Duration.
> > 
> >     use DateTime::Format::Duration;
> >     my $fmt = DateTime::Format::Duration->new(
> >         pattern => '%H hours, %M minutes, %S seconds',
> >         normalize => 1,
> >     );
> >     print $fmt->format_duration_from_deltas(
> >         seconds => 7341,
> >     ), "\n";
> > 
> Oh, what a sadness. Indeed i never saw the DateTime project before.
> But still my module is far easier to use than DateTime::Format::Duration.
> Do you believe it is worth to publish it in Time::Seconds::GroupBy?

I would rather see more standardization on the use of the DateTime
project, in much the same way that people think of DBI when they think
of accessing databases through Perl.

In this case, perhaps some clear documentation and examples (just like
the one above) would be the best solution. I think if such a solution
was easy to find on Google and clearly documented, people would use it,
especially once there is more awareness of DateTime as a comprehensive
date & time solution for Perl.

	Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark@summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .
0
mark
7/14/2004 3:27:39 PM
> I would rather see more standardization on the use of the DateTime
> project, in much the same way that people think of DBI when they think
> of accessing databases through Perl.
>
> In this case, perhaps some clear documentation and examples (just like
> the one above) would be the best solution. I think if such a solution
> was easy to find on Google and clearly documented, people would use it,
> especially once there is more awareness of DateTime as a comprehensive
> date & time solution for Perl.
I agree Mark, i've posted my module on the DateTime mailing list. Let's see what they say about it.

But i think the DateTime project is not gaining fair promotion once their modules are not even appearing on the main "Module List"
in the cpan's site at http://www.cpan.org/modules/00modlist.long.html.

If people should concentrate effort in making this framework the solution for Dates and times related problems, the DateTime
namespace should at least appear on the Module List, right?

Regards,
bruno.

0
vpopmail
7/14/2004 4:24:43 PM
On Wed, Jul 14, 2004 at 01:24:43PM -0300, Bruno Negr?o wrote:
>
> I agree Mark, i've posted my module on the DateTime mailing list. Let's see what they say about it.
> 
> But i think the DateTime project is not gaining fair promotion once their modules are not even appearing on the main "Module List"
> in the cpan's site at http://www.cpan.org/modules/00modlist.long.html.
> 
> If people should concentrate effort in making this framework the solution for Dates and times related problems, the DateTime
> namespace should at least appear on the Module List, right?

I think there is a separate more general issue that the module list is
losing relevance. I think a lot of people (like myself), use
http://search.cpan.org as a primary method for finding useful modules.
As a CPAN user, I don't consult the list when looking for modules. As 
a module writer, I have abandoned caring if my modules appear on the
list, because I have the perception it's not used much anymore.

So I would say a more important issue is that the DateTime modules don't
show up in the first 100 results for "Date" on that website:

http://search.cpan.org/search?m=all&q=date&s=1&n=100

I think part of the solution to fix that is to have more contributions to the
CPAN ratings system, and consider the ratings in the search results. 

	Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark@summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .
0
mark
7/14/2004 4:42:47 PM
mark@summersault.com (Mark Stosberg) writes:
> I think part of the solution to fix that is to have more contributions to the
> CPAN ratings system, and consider the ratings in the search results. 

The searching in search.cpan.org is, unfortunately, pretty awful. At some
point I plan to sit down and try using Plucene as a search engine for
module data.

This would, of course, be easier if the search.cpan.org code was more
widely available. *cough*

-- 
<Death> Damned electrons get into everything.
<Death> I found them in my BUTTERDISH just the other day.
0
simon
7/14/2004 4:57:30 PM
> I think there is a separate more general issue that the module list is
> losing relevance. I think a lot of people (like myself), use
> http://search.cpan.org as a primary method for finding useful modules.
> As a CPAN user, I don't consult the list when looking for modules. As
> a module writer, I have abandoned caring if my modules appear on the
> list, because I have the perception it's not used much anymore.
Since i heard this from you, i have always had the idea that the modules in
the Module List were the mainstream modules and we should consider them
first than the other ones in search.cpan.org.

Hmm, i think everybody who is new to perl think the same way i was thinking
and it takes a long time to realize that the Module List is not the main
source for the modules, or the main "inspiration source" for namespaces.

No, i really endorse that the most important(or popular) modules and/or
namespaces shall appear in the Module List.

bruno.

0
vpopmail
7/14/2004 5:04:28 PM
Simon Cozens sent the following bits through the ether:

> The searching in search.cpan.org is, unfortunately, pretty awful. At some
> point I plan to sit down and try using Plucene as a search engine for
> module data.

I thought that would be a good idea too, so I tried it. It works
*fairly* well.

  http://search.cpan.org/dist/CPAN-IndexPod/

Leon
-- 
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/

.... "Stupid" is a boundless concept.
0
acme
7/14/2004 5:08:16 PM
On Wed, 14 Jul 2004, Bruno Negr=E3o wrote:

> > I would rather see more standardization on the use of the DateTime
> > project, in much the same way that people think of DBI when they think
> > of accessing databases through Perl.
> >
> > In this case, perhaps some clear documentation and examples (just like
> > the one above) would be the best solution. I think if such a solution
> > was easy to find on Google and clearly documented, people would use it,
> > especially once there is more awareness of DateTime as a comprehensive
> > date & time solution for Perl.
> I agree Mark, i've posted my module on the DateTime mailing list. Let's s=
ee what they say about it.
>
> But i think the DateTime project is not gaining fair promotion once
> their modules are not even appearing on the main "Module List" in the
> cpan's site at http://www.cpan.org/modules/00modlist.long.html.

Some of them are, but not all.  Frankly, I don't think most people really
look at the list much, nor do most people consider it "authoritative".
What'd help more would be some articles on the project.  I've been wanting
to write one for a while, but I'm always short on time.

> If people should concentrate effort in making this framework the
> solution for Dates and times related problems, the DateTime namespace
> should at least appear on the Module List, right?

Some of them _are_ registered, but that document you're referring to
hasn't been regenerated since 2002/08/27!  I wish the CPAN folks would
just remove it if it won't be generated regularly.


-dave

/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
House Absolute Consulting
www.houseabsolute.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
0
autarch
7/14/2004 5:25:29 PM
On Wed, Jul 14, 2004 at 06:08:16PM +0100, Leon Brocard wrote:
> Simon Cozens sent the following bits through the ether:
> 
> > The searching in search.cpan.org is, unfortunately, pretty awful. At some
> > point I plan to sit down and try using Plucene as a search engine for
> > module data.
> 
> I thought that would be a good idea too, so I tried it. It works
> *fairly* well.
> 
>   http://search.cpan.org/dist/CPAN-IndexPod/

Does META.yaml have a place for keyowrds? It would be nice if it did and if
search.cpan.org indexed it. That would mean that it would be no longer
necessary to name your module along the lines of

XML::HTTP::Network::Daemon::TextProcessing::Business::Papersize::GIS

so that people can find it,

F

0
fergal
7/14/2004 5:30:59 PM
* Dave Rolsky <autarch@urth.org> [2004-07-14 19:26]:
> Some of them _are_ registered, but that document you're
> referring to hasn't been regenerated since 2002/08/27!  I wish
> the CPAN folks would just remove it if it won't be generated
> regularly.

Does anyone else here think that the list should probably just be
done away with entirely?

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/14/2004 5:31:48 PM
Simon Cozens <simon@simon-cozens.org> writes:

> mark@summersault.com (Mark Stosberg) writes:
> > I think part of the solution to fix that is to have more contributions to the
> > CPAN ratings system, and consider the ratings in the search results. 
> 
> The searching in search.cpan.org is, unfortunately, pretty awful. At some
> point I plan to sit down and try using Plucene as a search engine for
> module data.

It would be interesting to calculate the "importance" of a module by
how many other modules link to it, either via a use statement or by
reference in the POD, much like Google does with Web page links.
There's a project called Nutch that has abstracted out much of
PageRank and that sort of thing that would be useful, if anybody is
interested.  Nutch is written in Java, unfortunately for we Perl
folks, but isn't too hard to work with.  :)

    http://www.nutch.org/

----ScottG.
0
gifford
7/14/2004 5:36:55 PM
On Wed, 14 Jul 2004, A. Pagaltzis wrote:

> * Dave Rolsky <autarch@urth.org> [2004-07-14 19:26]:
> > Some of them _are_ registered, but that document you're
> > referring to hasn't been regenerated since 2002/08/27!  I wish
> > the CPAN folks would just remove it if it won't be generated
> > regularly.
>
> Does anyone else here think that the list should probably just be
> done away with entirely?

Given the fact that most authors seem to not register their stuff, the
modules@perl.org list is slow as heck, and that the web pages never get
regenerated, yes.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
0
autarch
7/14/2004 5:40:03 PM
gifford@umich.edu (Scott W Gifford) writes:
> It would be interesting to calculate the "importance" of a module by
> how many other modules link to it, either via a use statement or by
> reference in the POD, much like Google does with Web page links.

Someone's already done this for CPAN, but I can't find it at the moment.

> There's a project called Nutch that has abstracted out much of
> PageRank and that sort of thing that would be useful, if anybody is
> interested.

Algorithm::PageRank has also abstracted out much of PageRank... :)

-- 
Oh dear. I've just realised that my fvwm config lasted longer than my
marriage, in that case.
    - Anonymous
0
simon
7/14/2004 5:50:58 PM
* Dave Rolsky <autarch@urth.org> [2004-07-14 19:41]:
> > Does anyone else here think that the list should probably
> > just be done away with entirely?
> 
> Given the fact that most authors seem to not register their
> stuff, the modules@perl.org list is slow as heck, and that the
> web pages never get regenerated, yes.

Now the question is: how would we make that happen?

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/14/2004 6:24:55 PM
* Scott W Gifford <gifford@umich.edu> [2004-07-14 19:38]:
> It would be interesting to calculate the "importance" of a
> module by how many other modules link to it, either via a use
> statement or by reference in the POD, much like Google does
> with Web page links.

I was thinking the same thing, and I remember that someone
actually posted results from working code for something like that
a while back. I don't have the time to dig through the archives
right now, or I'd shake it up.

> There's a project called Nutch that has abstracted out much of
> PageRank and that sort of thing that would be useful, if
> anybody is interested.  Nutch is written in Java, unfortunately
> for we Perl folks, but isn't too hard to work with.  :)

And as Lucene/Plucene show, it doesn't have to be difficult to
reimplement good libraries in Perl, either. :-)

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/14/2004 6:28:19 PM
Fergal Daly wrote:

> Does META.yaml have a place for keyowrds?

The spec doesn't currently provide for keywords. I do think it would be 
a good idea, BUT I think it needs to be done in a way to avoid abuse. 
I'd hate to see META.yml files grow by the kb as authors add every 
conceivable keyword they can think of and try to manipulate the search. 
As limiting and as clumsy as it seems, I think that if keywords are 
added then it should be from a limited set of keywords, i.e. more of a 
classification scheme, really, where modules can appear under multiple 
classifications.

Randy.
0
randys
7/14/2004 7:11:00 PM
Fergal Daly wrote:

> Does META.yaml have a place for keyowrds?

The spec doesn't currently provide for keywords. I do think it would be 
a good idea, BUT I think it needs to be done in a way to avoid abuse. 
I'd hate to see META.yml files grow by the kb as authors add every 
conceivable keyword they can think of and try to manipulate the search. 
As limiting and as clumsy as it seems, I think that if keywords are 
added then it should be from a limited set of keywords, i.e. more of a 
classification scheme, really, where modules can appear under multiple 
classifications.

Randy.
0
ml
7/14/2004 7:11:11 PM
On Jul 14, 2004, at 12:11, Randy W. Sims wrote:

> Fergal Daly wrote:
>
>> Does META.yaml have a place for keyowrds?
>
> As limiting and as clumsy as it seems, I think that if keywords are 
> added then it should be from a limited set of keywords, i.e. more of a 
> classification scheme, really, where modules can appear under multiple 
> classifications.

Keywords are necessarily specific to the domain of the module, so I 
don't think that any global entity can designate an appropriate fixed 
set.  For instance, my module Net::OSCAR implements the protocol used 
by AOL Instant Messenger, so I'd give it keywords ["OSCAR", "AIM", 
"IM", "AOL Instant Messenger", "instant messenger", "instant 
messaging", "chat"].
0
matthewg
7/14/2004 7:22:31 PM
--WplhKdTI2c8ulnbP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Randy W. Sims <ml-perl at thepierianspring.org> [2004/07/14 15:11]:
> Fergal Daly wrote:
>=20
> >Does META.yaml have a place for keyowrds?
>=20
> The spec doesn't currently provide for keywords.

Is anyone generating META.yaml files by hand?  I thought they were all
generated (and regenerated) by Module::Build/MakeMaker?  How would that
work in the case of keywords?

(darren)

--=20
I interpret advertising as damage and route around it.

--WplhKdTI2c8ulnbP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9YoOzsinjrVhZaoRAvHmAJ0RB58Pn34gYrnuipuFIqoGrLGmlgCfck78
aDDBB94m6HKbu29s2MIAfa0=
=j3/Z
-----END PGP SIGNATURE-----

--WplhKdTI2c8ulnbP--
0
dlc
7/14/2004 7:31:26 PM
Matthew Sachs wrote:
> On Jul 14, 2004, at 12:11, Randy W. Sims wrote:
> 
>> Fergal Daly wrote:
>>
>>> Does META.yaml have a place for keyowrds?
>>
>>
>> As limiting and as clumsy as it seems, I think that if keywords are 
>> added then it should be from a limited set of keywords, i.e. more of a 
>> classification scheme, really, where modules can appear under multiple 
>> classifications.
> 
> 
> Keywords are necessarily specific to the domain of the module, so I 
> don't think that any global entity can designate an appropriate fixed 
> set.  For instance, my module Net::OSCAR implements the protocol used by 
> AOL Instant Messenger, so I'd give it keywords ["OSCAR", "AIM", "IM", 
> "AOL Instant Messenger", "instant messenger", "instant messaging", "chat"].

Classification for a module would probably be something like:

Net :: Protocol
Communications :: Chat :: AOL Instant Messenger
(That last comes from sf.net's topic system)

With the classification above AND a good one line synopsis of the module 
(which is already part of META.yml) most, if not all, of your keywords 
are covered.

Randy.
0
ml
7/14/2004 7:41:47 PM
On Wed, Jul 14, 2004 at 03:11:11PM -0400, Randy W. Sims wrote:
> Fergal Daly wrote:
> 
> >Does META.yaml have a place for keyowrds?
> 
> The spec doesn't currently provide for keywords. I do think it would be 
> a good idea, BUT I think it needs to be done in a way to avoid abuse. 
> I'd hate to see META.yml files grow by the kb as authors add every 
> conceivable keyword they can think of and try to manipulate the search. 

The search algorithm could pay attention to the first X keywords and
ignore the rest. Or at least, it could heavily weight the first few.

I think this is part of how search engines prevent the same kind of
above of the meta-tag keyword system. You can put as many keywords as
you want into the list, but I think the search engines only really care
about the first few.

I would prefer something like this over the "choosing from the fix list"
idea.

Having free-form tags is a feature I like on: http://del.icio.us/
It allows new classifications to spontaneously appear.

	Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark@summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .
0
mark
7/14/2004 7:44:23 PM
darren chamberlain wrote:
> Is anyone generating META.yaml files by hand?  I thought they were all
> generated (and regenerated) by Module::Build/MakeMaker?  How would that
> work in the case of keywords?

I haven't updated it in a while*, but 
<http://www.thepierianspring.org/meta.stats> shows in the "META.yml 
generated_by" section (partially duplicated below) that a few people 
are. This is done in by indicating to M::B/MM(?) that you want to handle 
the META.yml manually or by overriding the targets that generate the 
META.yml file.

META.yml generated_by:

<UNKNOWNS>:
   <UNDEFINED>    25
   Convert::Binary::C Makefile.PL     1
   Hand         1
   Kostas Pentikousis     1
   Mattia Barbon, by hand     2
   Tie::Hash::Indexed Makefile.PL     1
   hand         1
   hand!        1


* Anyone wanting to update it can find the script at 
<http://www.thepierianspring.org/meta_stats.pl.html>
0
ml
7/14/2004 7:55:12 PM
Mark Stosberg <mark@summersault.com> writes:

[...]

> The search algorithm could pay attention to the first X keywords and
> ignore the rest. Or at least, it could heavily weight the first few.
> 
> I think this is part of how search engines prevent the same kind of
> above of the meta-tag keyword system. You can put as many keywords as
> you want into the list, but I think the search engines only really care
> about the first few.

My understanding is that nowadays, most search engines ignore keywords
altogether, because they were so badly abused they became worthless.

----ScottG.
0
gifford
7/14/2004 8:48:00 PM
On Wed, Jul 14, 2004 at 06:30:59PM +0100, Fergal Daly wrote:
> On Wed, Jul 14, 2004 at 06:08:16PM +0100, Leon Brocard wrote:
> > Simon Cozens sent the following bits through the ether:
> > 
> > > The searching in search.cpan.org is, unfortunately, pretty awful. At some
> > > point I plan to sit down and try using Plucene as a search engine for
> > > module data.
> > 
> > I thought that would be a good idea too, so I tried it. It works
> > *fairly* well.
> > 
> >   http://search.cpan.org/dist/CPAN-IndexPod/
> 
> Does META.yaml have a place for keyowrds? It would be nice if it did and if
> search.cpan.org indexed it. That would mean that it would be no longer
> necessary to name your module along the lines of
> 
> XML::HTTP::Network::Daemon::TextProcessing::Business::Papersize::GIS
> 
> so that people can find it,

That's what the Description field is for.

Tim.
0
Tim
7/14/2004 9:34:08 PM
On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote:
> On Wed, 14 Jul 2004, A. Pagaltzis wrote:
> 
> > * Dave Rolsky <autarch@urth.org> [2004-07-14 19:26]:
> > > Some of them _are_ registered, but that document you're
> > > referring to hasn't been regenerated since 2002/08/27!  I wish
> > > the CPAN folks would just remove it if it won't be generated
> > > regularly.
> >
> > Does anyone else here think that the list should probably just be
> > done away with entirely?

The _file_ should go, yes. The concept of registering modules is different.

> Given the fact that most authors seem to not register their stuff, the
> modules@perl.org list is slow as heck, and that the web pages never get
> regenerated, yes.

Those are all fixable. Volunteers?

The real issues are bigger and deeper. I've appended a couple of emails.

Tim.


On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote:
> On Mon, 16 Feb 2004 01:32, Tim Bunce wrote;
> 
>   > I'd like to see a summary of what those "needs of the community"
>   > are.  (Maybe I missed it as I've not been following as closely as
>   > I'd have liked. In which case a link to an archived summary would
>   > be great.)
>   > It's very important to be clear about what the problems actually
>   > are.
> 
> I don't really want to argue this side of things, I think that the
> problems pretty much speak for themselves.  But I hate unspoken
> consensus, so let me suggest a few from my perspective; this applies
> to the combined Perl 5 modules list / using search.cpan.org:

I'll play devils advocate here and point out some alternative remedies
for the problems. By doing so I'm _not_ trying to detract for your
suggestion, which I like, I'm just trying to show how existing mechanisms
could be improved incrementally.

>   a) searching for modules for a particular task takes a long time and
>      unless you get your key words right, you might not find it at
>      all.  Refer the recent Mail::SendEasy thread.

Calls for a richer set of categories and cross-links of some kind.
(Editorial content alone is basically just more words to a search engine.)

>   b) it is very difficult to find good reviews weighing the pros and
>      cons of similar modules; they exist, but are scattered.
> 
>      CPAN ratings was a nice idea, but has too many "First Post!"
>      style reviews to be useful in its current form IMHO.

Argues for moderation of reviews and a minimum review length.
A "was this review helpful" mechanism would also help to bring
better reviews to the top.  Also the search.cpan.org should not
just show the overall rating, it should show the underlying three
individual ratings (docs, interface, ease of use).

>   c) it is nearly impossible to tell which modules are the wisest
>      choices from a community size point of view; using modules that
>      are more likely to fall out of maintenance is easy to do.

Argues for more stats. I think useful *relative* download stats
could be extracted from a sample of CPAN sites. Also search.cpan.org
could provide relative page-*view* stats for modules.

>   d) some great modules are not registered (I am referring of course
>      to such masterpieces as Pixie, Heritable::Types, Maptastic :),
>      Spiffy, Autodia, Want ... and those are just the ones missing
>      in my bag of tricks)

Argues for fixing the registration process.


>   > Originally the Module List had two goals:
>   >  1: to help people find perl modules for a particular task.
>   >  2: to provide a second-tier of modules above the 'anarchy' of 
>   >     people uploading half-baked ideas with half-baked names.
> 
> Honourable goals, which it solved adequately for a period of time, and
> full credit where it is due.
> 
> But now let's look at where we are.  We've got masses of modules,
> truckloads of categories and thousands of contributors.  This task
> cannot be left in the hands of a handful of hackers, no matter how
> much awe they inspire, they probably still have lives and day jobs ;)

The registration process can, and should, be automatic for any modules
for which no one objects. You'd apply and RT would automatically
register if no one commented on the application.


> I will maintain that the current format, or even simply adding some
> more fields to the database is *not* enough information to give
> uninformed people looking for a module the information to make an
> informed decision.
>
> It is my gut feeling that only editorial content, managed by people
> who are experts in the field, will truly perform this task - and that
> to gain maximum support, that it should be included in the content
> mirrored along with the rest of cpan.org.

I agree that comparative editorial reviews would be very valuable
for Goal 1 above. I wouldn't address Goal 2 effecively at all.


> I think we're mature enough as a community to be able to produce this
> content without it disolving into flamewars or being too one-sided.
> 
> In particular, I really think that as little red tape should be
> applied to this system as possible.  Let's just set up a few CVS /
> subversion accounts, to edit content that is autopublishing to the
> www.cpan.org site, with a few disclaimers chucked on the bottom.
> LARTing the naive and troublesome as appropriate.  

I agree. This all seems very similar to the DMOZ.org project that
maintains reviews of millions of web sites:
	"6,095,104 sites - 61,277 editors - 551,043 categories"
That's a mature and very sucessful model (used by google directory etc)
that's well worth learning from.


>   > The text file is out of date. The underlying database isn't:
>      [...]
>   > Please work with the PAUSE system, and Andreas and myself, to
>   > enhance what already exists (which includes a UI for module
>   > authors to pick which category they want the module in).
> 
> I'd be honoured to.  I think that the plan you propose would be an
> excellent step forward, and whether or not the editorial plan gains
> acceptance then it has merit.
> 
> Unfortunately right now I have to move house :-) but I should be able
> to dedicate at some time this week to research and kick-start this
> recategorisation effort.

Ultimely countless good ideas fail for lack of time.

Tim.


On Sun, Feb 15, 2004 at 08:20:39PM +0000, Zefram wrote:
> I am rather confused.
> 
> Many documents on PAUSE and CPAN refer to the Perl 5 module list.
> It is, for example, to be consulted when considering module naming, and
> to search for pre-existing modules.  Documents all over the web refer
> to it.  Without exception that I have been able to find, all of these
> references point to <http://www.cpan.org/modules/00modlist.long.html>
> as the place to get hold of the module list.
> 
> The document served at that URI is dated 2002-08-27 internally,
> and has a timestamp of 2002-08-28.  It lists (at a rough estimate)
> somewhere in the region of only half the number of modules that appear
> in the by-module hierarchy.  Evidently this is the module list as it
> was eighteen months ago.
> 
> PAUSE appears to maintain all the metadata that goes into the module
> list.  search.cpan.org searches on a recent version of this metadata.
> Evidently the module list is still being maintained.

This message I posted to module-authors recently may help explain:

  http://www.mail-archive.com/module-authors@perl.org/msg01752.html

(I could have cross-posted it here. I certainly meant to at least
tell people here that an important discussion was happening on
module-authors. So thanks for bringing this up now. Well timed.)

I'd recommend all modules@perl.org subscribers read that message.


> This is why I am mailing you to ask: what's going on?  Why is such
> an outdated module list being published in an authoritative location,
> and where can I get an up-to-date list?

Module List *document* was maintained by hand.  When managment of
the Module List *data* was automated there was a desire to automate
maintainance of the document but the document had a slightly richer
structure than the data. That small hurdle meant automation never
happened and the document was left unmaintained.

Around the same time search.cpan.org became functional so the
document had less relevance and busy people had other things to do.

I'll happily conceed that the *document* isn't important these days.
But I feel strongly that the *principle* (of moderated naming and
categorization) is.

The main pieces currently missing are:

1. Automated handling of module registration. [Where has that got to?]

2. Better integration of registration data into search.cpan.org
   So registration details are includes in search results, for example.

3. A 'fast path' process to register many modules that are in
   widespread use but are not registered. So then the majority of
   modules are registered and 

The alternative is just to give up. Seriously. We could just stop
banging our heads against authors uploading half baked ideas with
half-baked names (which are "self explanatory" to them).

The hope would be that out of the anarchy would rise some new
form of organization[*] (in the broadest sense) that would help
hapless users find what their looking for.

Do we want to do that? [I'm asking this question in all seriousness.]

Tim.

p.s. I think the term "Module List" should be deprecated in favor
of talking about "Registered Modules" and "module registration" etc.

[*] Presumably based on metadata, rantings, editorial reviews, download
stats and/or whatever else people can come up with.
0
Tim
7/14/2004 9:51:36 PM
On 7/14/2004 5:51 PM, Tim Bunce wrote:

> On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote:
> 
>>On Wed, 14 Jul 2004, A. Pagaltzis wrote:
>>
>>
>>>* Dave Rolsky <autarch@urth.org> [2004-07-14 19:26]:
>>>
>>>>Some of them _are_ registered, but that document you're
>>>>referring to hasn't been regenerated since 2002/08/27!  I wish
>>>>the CPAN folks would just remove it if it won't be generated
>>>>regularly.
>>>
>>>Does anyone else here think that the list should probably just be
>>>done away with entirely?
> 
> 
> The _file_ should go, yes. The concept of registering modules is different.
> 
> 
>>Given the fact that most authors seem to not register their stuff, the
>>modules@perl.org list is slow as heck, and that the web pages never get
>>regenerated, yes.
> 
> 
> Those are all fixable. Volunteers?
> 
> The real issues are bigger and deeper. I've appended a couple of emails.
> 
> Tim.
> 
> 
> On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote:
> 
>>On Mon, 16 Feb 2004 01:32, Tim Bunce wrote;
>>
>>  > I'd like to see a summary of what those "needs of the community"
>>  > are.  (Maybe I missed it as I've not been following as closely as
>>  > I'd have liked. In which case a link to an archived summary would
>>  > be great.)
>>  > It's very important to be clear about what the problems actually
>>  > are.
>>
>>I don't really want to argue this side of things, I think that the
>>problems pretty much speak for themselves.  But I hate unspoken
>>consensus, so let me suggest a few from my perspective; this applies
>>to the combined Perl 5 modules list / using search.cpan.org:
> 
> 
> I'll play devils advocate here and point out some alternative remedies
> for the problems. By doing so I'm _not_ trying to detract for your
> suggestion, which I like, I'm just trying to show how existing mechanisms
> could be improved incrementally.
> 
> 
>>  a) searching for modules for a particular task takes a long time and
>>     unless you get your key words right, you might not find it at
>>     all.  Refer the recent Mail::SendEasy thread.
> 
> 
> Calls for a richer set of categories and cross-links of some kind.
> (Editorial content alone is basically just more words to a search engine.)

Are we talking about the same thing: <perl.module-authors:2601> ?

>>  b) it is very difficult to find good reviews weighing the pros and
>>     cons of similar modules; they exist, but are scattered.
>>
>>     CPAN ratings was a nice idea, but has too many "First Post!"
>>     style reviews to be useful in its current form IMHO.
> 
> 
> Argues for moderation of reviews and a minimum review length.
> A "was this review helpful" mechanism would also help to bring
> better reviews to the top.  Also the search.cpan.org should not
> just show the overall rating, it should show the underlying three
> individual ratings (docs, interface, ease of use).

This is definately a trouble area. Not long ago I was exploring the 
cpanratings site and discovered the unhelpful "rampage" by one 
particular reviewer <http://cpanratings.perl.org/a/181>. Maybe breaking 
the reviews into catagories would be helpful? Rate: installation, 
interface, robustness, overall, etc.

>>  c) it is nearly impossible to tell which modules are the wisest
>>     choices from a community size point of view; using modules that
>>     are more likely to fall out of maintenance is easy to do.
> 
> 
> Argues for more stats. I think useful *relative* download stats
> could be extracted from a sample of CPAN sites. Also search.cpan.org
> could provide relative page-*view* stats for modules.

Narrow the interface for CPAN such that all viewing takes place on a 
single server where it can be monitored, and all download requests are 
distributed to mirror sites (ala sf.net).

As for the best of the best, I still believe there is a lot of merrit in 
the list built from dependencies idea.

>>  d) some great modules are not registered (I am referring of course
>>     to such masterpieces as Pixie, Heritable::Types, Maptastic :),
>>     Spiffy, Autodia, Want ... and those are just the ones missing
>>     in my bag of tricks)
> 
> 
> Argues for fixing the registration process.
> 
> 
>>This is why I am mailing you to ask: what's going on?  Why is such
>>an outdated module list being published in an authoritative location,
>>and where can I get an up-to-date list?
> 
> 
> Module List *document* was maintained by hand.  When managment of
> the Module List *data* was automated there was a desire to automate
> maintainance of the document but the document had a slightly richer
> structure than the data. That small hurdle meant automation never
> happened and the document was left unmaintained.
> 
> Around the same time search.cpan.org became functional so the
> document had less relevance and busy people had other things to do.
> 
> I'll happily conceed that the *document* isn't important these days.
> But I feel strongly that the *principle* (of moderated naming and
> categorization) is.
> 
> The main pieces currently missing are:
> 
> 1. Automated handling of module registration. [Where has that got to?]
> 
> 2. Better integration of registration data into search.cpan.org
>    So registration details are includes in search results, for example.
> 
> 3. A 'fast path' process to register many modules that are in
>    widespread use but are not registered. So then the majority of
>    modules are registered and 
> 
> The alternative is just to give up. Seriously. We could just stop
> banging our heads against authors uploading half baked ideas with
> half-baked names (which are "self explanatory" to them).
> 
> The hope would be that out of the anarchy would rise some new
> form of organization[*] (in the broadest sense) that would help
> hapless users find what their looking for.
> 
> Do we want to do that? [I'm asking this question in all seriousness.]
> 

We could accomplish required, automated, and reviewed registration by 
setting up a new list (the modules list is filled with so much automated 
chatter that I don't even look at it any more). Before an author could 
upload a module, a message would be auto posted to the list. If, after 
some arbitrary time period, no one responds, then registration is is 
approved. If there is a response, then it gets pushed on to a queue for 
moderator approval. Moderation is simply a select group of people who 
monitor the discussion and have authorization to act according to the 
consensus reached in the discussion. Moderators do not make the 
decision; they just execute it.

The list would accomplish the same thing that generally happens here 
(name discussion, reinvention, etc), but will be required.

Randy.

> Tim.
> 
> p.s. I think the term "Module List" should be deprecated in favor
> of talking about "Registered Modules" and "module registration" etc.
> 
> [*] Presumably based on metadata, rantings, editorial reviews, download
> stats and/or whatever else people can come up with.
> 


0
ml
7/14/2004 10:49:51 PM
On Wed, Jul 14, 2004 at 10:34:08PM +0100, Tim Bunce wrote:
> On Wed, Jul 14, 2004 at 06:30:59PM +0100, Fergal Daly wrote:
> > XML::HTTP::Network::Daemon::TextProcessing::Business::Papersize::GIS
> > 
> > so that people can find it,
> 
> That's what the Description field is for.

There's a Description field? I accept responsibility for not knowing about
this, I've never made an effort to see what is available. However, if
search.cpan.org had allowed me to search by Description field I probably
would have included one in all of my modules,

F

0
fergal
7/14/2004 10:51:44 PM
On Wed, 14 Jul 2004, Randy W. Sims wrote:

> As for the best of the best, I still believe there is a lot of merrit in
> the list built from dependencies idea.

Only in some areas.  For example, the top templating modules are probably,
TT, HTML::Template, & Mason.  How many modules depend on any of those?
Darn few, because they are kind of at the end of the module food chain.

OTOH, many modules in the DateTime suite depend on DateTime.pm.  This
doesn't make it best of breed (though I think it is for other reasons ;)


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
0
autarch
7/15/2004 3:59:05 AM
Tim Bunce writes:

> On Wed, Jul 14, 2004 at 06:30:59PM +0100, Fergal Daly wrote:
> 
> > Does META.yaml have a place for keyowrds? It would be nice if it did
> > ...
> 
> That's what the Description field is for.

A potential problem with people keyword-stuffing the description is that
for topics with a few synonyms fitting them all in makes the description
very stilted, lessening its worth as an explanation to a human reading
the description as a whole to work out what the module is for.  (See the
page titles on many commercial websites in crowded markets, such as
hotels.)

However, I still agree with you: humans in general are incredibly bad at
picking relevant keywords -- look how much better web search engines got
when they started ignoring the keywords and using other algorithms based
on picking the relevant bits out of the full text of pages themselves --
and having keywords being set independently by so many different people
does not sound like something with a high chance of yielding useful
results.

An appropriate multi-part module name plus a description field together
give a good opportunity for fitting in a reasonable number of keywords.

Smylers

0
Smylers
7/15/2004 7:03:36 AM
Randy W. Sims writes:

> Not long ago I was exploring the cpanratings site and discovered the
> unhelpful "rampage" by one particular reviewer
> <http://cpanratings.perl.org/a/181>.

Why do you think Randal's comments are unhelpful?  Personally whenever
I'm (considering) downloading a module I haven't used before I read any
reviews it has.  It would never've occurred to me that an author
would've have put default phone-home behaviour into a distribution's
installer, but on reading Randal's review of a module I'd then be aware
of it in advance.

That's certainly useful information to have.  Admittedly when you look
at the page giving all Randal's reviews there is a fair amount of
repetition going on, but the information he gives is pertinent to every
one of those modules, so it's the only way of ensuring the message
reaches potential users of all of the modules.

Actually I'm much more concerned by the opposite problem, that people
give 5 stars to modules they use lots and don't bother reviewing other
modules, or ones they tried a bit but gave up on -- partly, I suspect,
cos if you never quite got into a module properly then you feel it'd be
unfair to review it.  Look at one of the modules that Randal reviews,
CGI::Builder:

  http://cpanratings.perl.org/d/CGI-Builder

That's a flurry of 5-star reviews in a very short space of time.  I
suspect that isn't a co-incidence -- perhaps there's a CGI::Builder
mailing list somewhere that had a recent post encouraging users to
review the module?  There isn't anything wrong with that[*0], but it
could distort the value of reviews over all.

Cpan Ratings is still young.  Let's give it some more time to pan out; I
think it's one of the better ideas out there.

There's also some degree of a chicken-and-egg situation going on, but
once the site has more reviews in it there'll be more reason for people
to consult it and for places to link to it more prominently.

  [*0]  Well, there are ways in which such a mail could be phrased that
  would be wrong; but simply soliciting genuine reviews from genuine
  users can hardly be faulted.

Smylers

0
Smylers
7/15/2004 7:16:42 AM
On Jul 14, 2004, at 2:11 PM, Randy W. Sims wrote:
>
> The spec doesn't currently provide for keywords. I do think it would 
> be a good idea, BUT I think it needs to be done in a way to avoid 
> abuse.

I think maybe it would be better to put keywords right in the pod for 
the module, so they become part of the documentation too.  This is 
similar to the way they often appear in academic papers, right after 
the abstract - and people often find it useful for pinpointing the 
subject matter.

  -Ken

0
ken
7/16/2004 12:54:04 PM
On 7/14/2004 3:11 PM Randy W. Sims wrote:

> The spec doesn't currently provide for keywords. I do think it would be 
> a good idea, BUT I think it needs to be done in a way to avoid abuse. 
 > I'd hate to see META.yml files grow by the kb as authors add every
 > conceivable keyword they can think of and try to manipulate the search.

I think we shouldn't worry about abuse.  Module authors don't have the same 
incentives to manipulate searches the way web site operators might.

I do think if keywords are specified (I like the idea), that a guidelines 
document should be written to advise module authors on listing keywords.  A 
list of common keywords and what they mean would be helpful.

Keywords can be given a maximum size (say 1kb).  Module::(Build|Install) 
utilities and PAUSE/CPAN indexers can ignore extra keywords above that limit.


0
wlkngowl
7/16/2004 9:39:22 PM
On 7/14/2004 3:44 PM, Mark Stosberg wrote:
> On Wed, Jul 14, 2004 at 03:11:11PM -0400, Randy W. Sims wrote:
> 
>>Fergal Daly wrote:
>>
>>
>>>Does META.yaml have a place for keyowrds?
>>
>>The spec doesn't currently provide for keywords. I do think it would be 
>>a good idea, BUT I think it needs to be done in a way to avoid abuse. 
>>I'd hate to see META.yml files grow by the kb as authors add every 
>>conceivable keyword they can think of and try to manipulate the search. 
> 
> 
> The search algorithm could pay attention to the first X keywords and
> ignore the rest. Or at least, it could heavily weight the first few.
> 
> I think this is part of how search engines prevent the same kind of
> above of the meta-tag keyword system. You can put as many keywords as
> you want into the list, but I think the search engines only really care
> about the first few.

That seems a reasonable approach to overcoming the abuse problem. There 
is, however, another advantage to the catagory approach: Searching would 
likely be more consistent. It would help authors to place their modules 
so that they can be found with similar modules. It would also help 
ensure that users looking for a particular type module will get back a 
result set that is likely to contain all/most of the modules of that type.

> I would prefer something like this over the "choosing from the fix list"
> idea.
> 
> Having free-form tags is a feature I like on: http://del.icio.us/
> It allows new classifications to spontaneously appear.

I will conceed that there are definate advantages to the keyword approach.

Randy.

0
ml
7/17/2004 5:51:38 AM
On 7/16/2004 8:54 AM, Ken Williams wrote:
> 
> On Jul 14, 2004, at 2:11 PM, Randy W. Sims wrote:
> 
>>
>> The spec doesn't currently provide for keywords. I do think it would 
>> be a good idea, BUT I think it needs to be done in a way to avoid abuse.
> 
> 
> I think maybe it would be better to put keywords right in the pod for 
> the module, so they become part of the documentation too.  This is 
> similar to the way they often appear in academic papers, right after the 
> abstract - and people often find it useful for pinpointing the subject 
> matter.

Is it usefull to have in the pod? It seems like meta information to me; 
i.e. it seems like it would only be usefull to indexers. I am concerned 
that META.yml might become a huge document if everything gets put in 
there, but I think if we agree that it would be usefull to have 
keywords/catagories, then the best place is in META.yml. This also has 
the benefit that you can have a lightweight indexer that only has to 
look in one place.

Randy.

0
ml
7/17/2004 5:52:50 AM
* Randy W. Sims <ml-perl@thepierianspring.org> [2004-07-17 12:45]:
> There is, however, another advantage to the catagory approach:
> Searching would likely be more consistent. It would help
> authors to place their modules so that they can be found with
> similar modules. It would also help ensure that users looking
> for a particular type module will get back a result set that is
> likely to contain all/most of the modules of that type.

Why does it have to be either/or?

There could be two keyword lists, one with fixed keywords, and
the other freeform. Their names would have to be chosen carefully
to suggest this as the intended use (rather than filling both
with the same keywords) -- maybe ``keywords'' and
``additional_keywords'' or something.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/17/2004 11:32:36 AM
A. Pagaltzis writes:

> Why does it have to be either/or?
> 
> There could be two keyword lists, one with fixed keywords, and the
> other freeform. Their names would have to be chosen carefully to
> suggest this as the intended use (rather than filling both with the
> same keywords) -- maybe ``keywords'' and ``additional_keywords'' or
> something.

Warning:  Wild conjecture and multiple unrelated crazy ideas ahead.

This is becoming _way_ too complicated.  The more complicated it
becomes, the less chance there is of Cpan uploaders understanding it,
doing it well, or even bothering with it -- even presuming that they
hear about it in the first place.

And I still reckon most humans are approximately appalling at picking
appropriate keywords anyway.  A system like you're proposing still
requires an individual module's author to think of the right keywords
and bother to do this, which is putting a single-point of failure in the
system.

However, improved Cpan searching would be welcome.  There have been
occasions when it's taken me a lot of searching to locate a module (or
sometimes I didn't discover it by searching, but only encountered it by
chance later).  At that particular moment in time I am in the position
of having the name of a module plus a search term that I had hoped would
lead to that module but didn't.  This isn't some theoretical
classification, or term that somebody might search for, but one that I
actually did use.

It has occurred to me that at such a point it'd be good if I could
somehow 'tag' the module in question with the search term, so that
people searching for that term in future would find that module.  In
other words, it's the search-engine users, not the module authors who
define the keywords.  So no individual has to be great at
classifications, just a collective group being OK at it on average.

It would also mean the keywords used are the vocabulary of the target
audience; it doesn't actually matter if some of the keywords are not
what the author would use (or even if they're 'wrong'), so long as that
audience are finding them useful.

Could something like this be done just with the existing Cpan Ratings
system?  If you find a module is good for a particular task then you
give it a high rating and mention the task it's good for in the review?
So if the text of reviews were searched, and the ratings contributing
towards the ranking of results, would that be enough?  Or would the
'noise' of other words in reviews make this useless?  The fact that
Google works so well parsing significance from plain text makes me think
it's got a chance.

Another possibility is just allowing any user to 'assign' any keyword to
any module, and have those keywords added to the list of things the
search engine looks through.  That's more likely to be open to abuse
from authors -- either deviously trying to get more attention for
'their' module, or inadvertently picking bad keywords -- but no more so
than with something in META.yml.

The system degrades as it tends towards every keyword being assigned to
every module, of course; allowing people to remove keywords is
problematic (if a module is only slightly relevant to a keyword is
having it assigned helpful for those rare situations, or making it worse
for the common situations where the module isn't relevant?).

This kind of conflict between different people's views also occurs on
wikis, at least some of which seem to have a reasonable way of dealing
with them.  So perhaps each module (or distribution) page just needs a
wiki area where any users can add any useful annotations, keywords, or
whatever (or correct those made by previous users), and have the
wiki-like-comments being searchable too?

Would that overlapping too much with the Cpan Ratings system -- where's
the line between adding a useful annotation providing useful (hopefully
factual) information ("This module requires Windows 2000 or newer" say
or "Installing this module will phone home to the author's web-server")
and posting a (subjective) hatchet-job review?

Or perhaps module-keyword pairings are the way forward but also need
some kind of score against them, whereby more people advocating a
keyword gives a higher score (and possibly allowing negative-allocations
too); that way outliers are not so much of a problem, and we only need
for users to be right on average, kind-of similar to how 20Q.net learns
things from the average/consensus of many people's views:

  http://www.20q.net/

Do we actually want something like a 20Q.net instance where the only
objects the system knows about are Perl modules?  If you know a module
then you can teach the system about it; if you're looking for a module
then you answer its questions to describe the characteristics you're
after and look at the list of suggested modules it throws up?

[Don't say I didn't warn you about the crazy ideas.]

Smylers

0
Smylers
7/17/2004 12:39:21 PM
On Sat, Jul 17, 2004 at 01:32:36PM +0200, A. Pagaltzis wrote:
> * Randy W. Sims <ml-perl@thepierianspring.org> [2004-07-17 12:45]:
> > There is, however, another advantage to the catagory approach:
> > Searching would likely be more consistent. It would help
> > authors to place their modules so that they can be found with
> > similar modules. It would also help ensure that users looking
> > for a particular type module will get back a result set that is
> > likely to contain all/most of the modules of that type.
> 
> Why does it have to be either/or?
> 
> There could be two keyword lists, one with fixed keywords, and
> the other freeform. Their names would have to be chosen carefully
> to suggest this as the intended use (rather than filling both
> with the same keywords) -- maybe ``keywords'' and
> ``additional_keywords'' or something.

I agree that If there is to be an "official" list of keyowrds then it
shouldn't be either/or. The officials haven't regenerated the module list
for 2 years, there's no reason to think that the keyword officials will stay
up to date.

That said, I don't think having 2 lists is useful. The author should supply
a single list of keywords. Those that are on the official list are on the
official list, those that aren't aren't. The search engine/indexer will be
far better at figuring that out than the module author. Otherwise you are
just obliging the authors to keep track of the official list and move
keywords around in their meta info as the official list chnages.

It would be up to the search engine to perhaps give more weight to official
keywords. The search engine could also maintain "official" synonyms so that
"postgres" and "pg" are indexed together,

F

0
fergal
7/17/2004 12:54:16 PM
* Fergal Daly <fergal@esatclear.ie> [2004-07-17 14:56]:
> That said, I don't think having 2 lists is useful. The author
> should supply a single list of keywords. Those that are on the
> official list are on the official list, those that aren't
> aren't. The search engine/indexer will be far better at
> figuring that out than the module author. Otherwise you are
> just obliging the authors to keep track of the official list
> and move keywords around in their meta info as the official
> list chnages.

Which was exactly the purpose: to be able to make sure that the
list with official keywords really does only contain official
keywords, so a release tool can complain about misspellings f.ex.
If you simply allow both in a single list, then "netwrok" will go
unnoticed and make your module invisible to searches with the
correct keyword.

I don't think the existence of two lists should matter to the
indexer -- official keywords in the freeform list should have the
same value as official ones in the fixed keys list. That sort of
defeats the above point, I guess, but a list for fixed keys only
still helps those who want its benefits.

It might suffice to have the release tool check the list and tell
the user which keywords are official and which aren't, but I
don't know if that is helpful enough -- I personally would like
to be able to tell it to choke on all mistakes *except* those I
specifically declared as known non-official ones.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/17/2004 1:40:52 PM
On Jul 17, 2004, at 12:52 AM, Randy W. Sims wrote:

> On 7/16/2004 8:54 AM, Ken Williams wrote:
>> On Jul 14, 2004, at 2:11 PM, Randy W. Sims wrote:
>>>
>>> The spec doesn't currently provide for keywords. I do think it would 
>>> be a good idea, BUT I think it needs to be done in a way to avoid 
>>> abuse.
>> I think maybe it would be better to put keywords right in the pod for 
>> the module, so they become part of the documentation too.  This is 
>> similar to the way they often appear in academic papers, right after 
>> the abstract - and people often find it useful for pinpointing the 
>> subject matter.
>
> Is it usefull to have in the pod? It seems like meta information to 
> me; i.e. it seems like it would only be usefull to indexers. I am 
> concerned that META.yml might become a huge document if everything 
> gets put in there, but I think if we agree that it would be usefull to 
> have keywords/catagories, then the best place is in META.yml. This 
> also has the benefit that you can have a lightweight indexer that only 
> has to look in one place.

Well, I actually don't think we need a place for keywords *anywhere*, 
but if we have them somewhere, then yeah, I do think it's good to be 
able to see them in the pod.  Something like they are here (random 
academic paper in my field):

  http://www.cs.cmu.edu/~yiming/papers.yy/kdd02.pdf.gz

  -Ken

0
ken
7/17/2004 4:40:02 PM
On Jul 17, 2004, at 7:39 AM, Smylers wrote:
>
> Warning:  Wild conjecture and multiple unrelated crazy ideas ahead.
>
> This is becoming _way_ too complicated.

Agreed.


> And I still reckon most humans are approximately appalling at picking
> appropriate keywords anyway.  A system like you're proposing still
> requires an individual module's author to think of the right keywords
> and bother to do this, which is putting a single-point of failure in 
> the
> system.

Agreed.

>
> However, improved Cpan searching would be welcome.

Agreed.  Note that the primary contribution of search.cpan.org is that 
it has a really nice interface and lots of functionality.  But its 
actual search algorithm still isn't very good (it just uses WAIT, IIRC) 
- I think we could get far more mileage out of tuning the search engine 
better for the needs of perl-module searching, and perhaps doing stuff 
like grouping the results by distribution, than we'd ever get this way. 
  And we wouldn't need to add complexity to the modules themselves.

Smylers, I think your proposal is interesting but I don't think it's 
necessary for improving searching over CPAN modules.

  -Ken

0
ken
7/17/2004 4:51:28 PM
Smylers wrote:

>
>And I still reckon most humans are approximately appalling at picking
>appropriate keywords anyway.  A system like you're proposing still
>requires an individual module's author to think of the right keywords
>and bother to do this, which is putting a single-point of failure in the
>system.
>
>  
>
This list already advises authors (those that ask) on appropriate names,
it could readily name the top 10 keywords also.  Those that dont ask cannot
be helped w/o undue complexity.

OTGH, its not impractical for the many regulars here to moderate/gatekeep
on what modules are publicized.  New uploads (ie new dists) result in a 
reply
to the user, and a post to module-authors, flagging a new dist for name 
approval.

KISS.  (moderation may not be sufficiently simple)


0
jcromie
7/18/2004 3:25:23 AM
Ken Williams writes:

> I think we could get far more mileage out of tuning the search engine
> better for the needs of perl-module searching,

You speak great sense.  Now it's back to Simon's point about the source
code for it not seeming to be available.

> Smylers, I think your proposal is interesting ...

"Proposal" is flattering to my message -- "thinking out loud" was more
like it.  I wasn't seriously expecting anybody to start implementing any
of the things I said, but was just pointing out that there are many
different ways of approaching the problem which don't involve keywords
....

Smylers

0
Smylers
7/18/2004 9:19:42 AM
On Sat, Jul 17, 2004 at 03:40:52PM +0200, A. Pagaltzis wrote:
> Which was exactly the purpose: to be able to make sure that the
> list with official keywords really does only contain official
> keywords, so a release tool can complain about misspellings f.ex.
> If you simply allow both in a single list, then "netwrok" will go
> unnoticed and make your module invisible to searches with the
> correct keyword.
> 
> I don't think the existence of two lists should matter to the
> indexer -- official keywords in the freeform list should have the
> same value as official ones in the fixed keys list. That sort of
> defeats the above point, I guess, but a list for fixed keys only
> still helps those who want its benefits.
> 
> It might suffice to have the release tool check the list and tell
> the user which keywords are official and which aren't, but I
> don't know if that is helpful enough -- I personally would like
> to be able to tell it to choke on all mistakes *except* those I
> specifically declared as known non-official ones.

The only benefit I can see is that of spell-checking and that would be
better done by an actual spell-checker. Isn't it important not mis-spell any
keywords, regardless of their officialness?

F
0
fergal
7/18/2004 8:57:12 PM
On Sat, Jul 17, 2004 at 11:40:02AM -0500, Ken Williams wrote:
> Well, I actually don't think we need a place for keywords *anywhere*, 
> but if we have them somewhere, then yeah, I do think it's good to be 
> able to see them in the pod.  Something like they are here (random 
> academic paper in my field):
> 
>  http://www.cs.cmu.edu/~yiming/papers.yy/kdd02.pdf.gz

I think having them in the POD is nice but that makes them a little harder
for the indexer to extract them. Having them inserted into the POD at build
time might be a better option.

I think the need for keywords is there on CPAN just as it is for academic
papers. How sophisticated would the full-test based search engine have to be
to understand that "this module requires an XML parser" should not be a hit
for "XML parser"? Or that "this module does not yet support HTTPS" is not a
hit for "HTTPS"?

F

0
fergal
7/18/2004 9:09:02 PM
* Fergal Daly <fergal@esatclear.ie> [2004-07-18 22:59]:
> The only benefit I can see is that of spell-checking and that
> would be better done by an actual spell-checker. Isn't it
> important not mis-spell any keywords, regardless of their
> officialness?

You're right.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/18/2004 11:54:59 PM
I nominate the

  Review::*

Namespace for author-submitted module indexes and in-depth reviews, in 
POD format.  I think this has a number of advantages.  Let's use the 
infrastructure we already have, no?

The .pm versions of these modules could potentially contain lists (in 
YAML format of course) for use by the indexing systems, which would, 
after double checking, be used as a master data source for the 
auto-generated indexes and modules lists.

This probably needs to be prototyped a little, and a model review module 
(say that 5 times quickly) posted before reviews start coming in in earnest.

Sam.

Randy W. Sims wrote:

> On 7/14/2004 5:51 PM, Tim Bunce wrote:
>
>> On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote:
>>
>>> On Wed, 14 Jul 2004, A. Pagaltzis wrote:
>>>
>>>
>>>> * Dave Rolsky <autarch@urth.org> [2004-07-14 19:26]:
>>>>
>>>>> Some of them _are_ registered, but that document you're
>>>>> referring to hasn't been regenerated since 2002/08/27!  I wish
>>>>> the CPAN folks would just remove it if it won't be generated
>>>>> regularly.
>>>>
>>>>
>>>> Does anyone else here think that the list should probably just be
>>>> done away with entirely?
>>>
>>
>>
>> The _file_ should go, yes. The concept of registering modules is 
>> different.
>>


-- 
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)

0
sam
7/20/2004 6:15:49 AM
On Tue, Jul 20, 2004 at 06:15:49PM +1200, Sam Vilain wrote:
> I nominate the
> 
>  Review::*
> 
> Namespace for author-submitted module indexes and in-depth reviews, in 
> POD format.  I think this has a number of advantages.  Let's use the 
> infrastructure we already have, no?

Interesting, but what comes after Review:: if it's Review::Text::Balanced
then how do we get multiple reviews Text::Balanced or are you talking about
something else entirely?

F
0
fergal
7/20/2004 9:10:02 AM
On Tue, Jul 20, 2004 at 10:10:02AM +0100, Fergal Daly wrote:
> On Tue, Jul 20, 2004 at 06:15:49PM +1200, Sam Vilain wrote:
> > I nominate the
> > 
> >  Review::*
> > 
> > Namespace for author-submitted module indexes and in-depth reviews, in 
> > POD format.  I think this has a number of advantages.  Let's use the 
> > infrastructure we already have, no?
> 
> Interesting, but what comes after Review:: if it's Review::Text::Balanced
> then how do we get multiple reviews Text::Balanced

Maybe the convention could be:

Review::Text::Balanced::CPANUSERNAME

I'll let someone else suggest what should happen if the same person
decides to review the same module multiple times. (Perhaps there would be
an early negative review, and then a later positive review after the
module improved with feedback.)

	Mark	
0
mark
7/20/2004 2:30:47 PM
On Tue, Jul 20, 2004 at 09:30:47AM -0500, Mark Stosberg wrote:
> On Tue, Jul 20, 2004 at 10:10:02AM +0100, Fergal Daly wrote:
> > On Tue, Jul 20, 2004 at 06:15:49PM +1200, Sam Vilain wrote:
> > > I nominate the
> > > 
> > >  Review::*
> > > 
> > > Namespace for author-submitted module indexes and in-depth reviews, in 
> > > POD format.  I think this has a number of advantages.  Let's use the 
> > > infrastructure we already have, no?
> > 
> > Interesting, but what comes after Review:: if it's Review::Text::Balanced
> > then how do we get multiple reviews Text::Balanced
> 
> Maybe the convention could be:
> 
> Review::Text::Balanced::CPANUSERNAME
> 
> I'll let someone else suggest what should happen if the same person
> decides to review the same module multiple times. (Perhaps there would be
> an early negative review, and then a later positive review after the
> module improved with feedback.)

I thought someone might say that.

The more I think about it, the more I think that it's not a great idea using
the real CPAN to do things other than distribute code. Reuse the
infrastructure by all means but the idea of mixing bundles, code, reviews
and whatever else comes up in the same hierarchy with just naming
conventions to tell them apart does not appeal to me. If we weren't
dependent on collapsing all the relevant information down into a ::
delimited list it would be much nicer (fantasy land, I know),

F
 
0
fergal
7/20/2004 2:57:10 PM
On Tue, Jul 20, 2004 at 03:57:10PM +0100, Fergal Daly wrote:
>
> The more I think about it, the more I think that it's not a great idea using
> the real CPAN to do things other than distribute code. Reuse the
> infrastructure by all means but the idea of mixing bundles, code, reviews
> and whatever else comes up in the same hierarchy with just naming
> conventions to tell them apart does not appeal to me. If we weren't
> dependent on collapsing all the relevant information down into a ::
> delimited list it would be much nicer (fantasy land, I know),

I realize it's not a "clean" solution, but there are some things I like
about it:

- I can check http://search.cpan.org/recent for new modules and new
  module reviews. The means one less place to check for new and
  interesting Perl things that have been published. (OTOH, perhaps
  using an RSS News reader / aggregator would solve this just as well. )

- I like the idea of searching for a term and finding modules and
  reviews coming back. OTOH, we already have CPAN ratings for this. 

[ Thinks more. ]. 

OK, I'm changing my mind. I think it makes more sense to have a way
to integrate longer reviews with cpanratings.perl.org.

Perhaps a simple solution would be provide a field to link to longer
review, which could be anywhere in any format. 

	Mark

--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark@summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .
0
mark
7/20/2004 3:08:08 PM
So, if I want to write a review of Net::SMTP, I'd do the following.

1. Use Module::Build, or ExtUtils::MakeMaker to create
Review::Net::SMTP::CHRISJ, or whatever.

2. Make sure I have my README.txt, CHANGES, and MANIFEST file.

3. Write my review in POD format, and throw in some META.yml indexing code
as well.

4. Make sure the module/review is executable so it passes CPAN testing.

5. Upload the review to CPAN.

On Tue, 20 Jul 2004, Sam Vilain wrote:

> I nominate the
>
>   Review::*
>
> Namespace for author-submitted module indexes and in-depth reviews, in
> POD format.  I think this has a number of advantages.  Let's use the
> infrastructure we already have, no?
>
> The .pm versions of these modules could potentially contain lists (in
> YAML format of course) for use by the indexing systems, which would,
> after double checking, be used as a master data source for the
> auto-generated indexes and modules lists.
>
> This probably needs to be prototyped a little, and a model review module
> (say that 5 times quickly) posted before reviews start coming in in earnest.
>
> Sam.
>

--------------------
Christopher Josephes
cpj1@visi.com
0
cpj1
7/20/2004 4:57:42 PM
Mark Stosberg wrote:

>Maybe the convention could be:
>
>Review::Text::Balanced::CPANUSERNAME
>  
>

Good idea, but I think that is duplicated information.  CPAN already 
considers the uploaded user ID to be a part of the unique name of the 
module.  Two authors can upload a module with the same name; and that is 
fine; they will both be displayed uniquely when found on search.cpan.org.

Of course, when installing via CPAN.pm, the indexer will only 
automatically choose the versions of the modules written by the current 
maintainer (or some rule like that).  For reviews, this is not really a 
major consideration - except maybe for people compiling CPAN discset 
compilations.  OTOH, a link to http://search.cpan.org/dist/Some-Dist/ 
will go to whichever has the highest version number (see 
http://search.cpan.org/dist/Data-Lazy/ for an example).  Perfect.

Rather than trying to double the size of CPAN by making a review for 
each module, a review could cover a wide variety of different modules 
that cover a related problem space.  The reviews could be supplemented 
with examples and demonstrations exhibiting strengths and weaknesses of 
the modules that they review - for instance, benchmarking, memory tests, 
etc.  As new modules are written, the reviews could be extended 
(perhaps, but not necessarily by the same author as the original 
review).  You will get a similar situation to many of the modules in 
CPAN today, which have more than a handful of maintainers who have 
contributed.

There's nothing to say that individual module reviews shouldn't be 
written, and the convention of naming the review module the same as the 
single module it covers with a prefix is a good one.  This would almost 
certainly be linked to by the module which covers the generic problem space.

So, to make this distinction clear, maybe the

    Guide::*

namespace should cover "problem space" reviews, and serve as something 
of another index to CPAN - and

    Review::*

can be for more in-depth reviews of individual CPAN modules, to avoid 
potentional conflicts from using "Review::*" for both of these.  
Besides, I think Guide:: is more accurate here.

If no-one has any sound objections or beats me to the task, I will 
endeavour to complete Guide.pod, and Guide/Example.pod during my 
recreational Perl development time (not as abundant at present as it 
once was ;-)), and construct a skeleton of Guide:: distributions based 
on the old modules list.

But first, back to reinventing some more wheels ;-).
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
0
sam
7/22/2004 4:23:54 AM
On Jul 20, 2004, at 11:57 AM, Chris Josephes wrote:

> So, if I want to write a review of Net::SMTP, I'd do the following.
>
> 1. Use Module::Build, or ExtUtils::MakeMaker to create
> Review::Net::SMTP::CHRISJ, or whatever.
>
> 2. Make sure I have my README.txt, CHANGES, and MANIFEST file.
>
> 3. Write my review in POD format, and throw in some META.yml indexing 
> code
> as well.
>
> 4. Make sure the module/review is executable so it passes CPAN testing.
>
> 5. Upload the review to CPAN.
>

I was sort of hoping this idea would just die on its own, but now it 
looks like people are actually getting ready to do it.  In my opinion 
this is a bad idea.  I don't want a bunch of reviews all over CPAN 
disguising themselves as modules.  I also don't want CPAN sites to have 
to figure out what's a review and what's not, so they can filter out 
the reviews.

What's wrong with making one of these newfangled things called "web 
sites" to host reviews?  Oh, I know - that already exists.  So how 
about working with those people to fix whatever you think is broken 
about them before polluting CPAN with all this non-code?

  -Ken

0
ken
7/22/2004 6:50:37 PM
On Thu, 22 Jul 2004 13:50:37 -0500, Ken Williams <ken@mathforum.org> wrote:
> I was sort of hoping this idea would just die on its own, but now it
> looks like people are actually getting ready to do it.  In my opinion
> this is a bad idea.  I don't want a bunch of reviews all over CPAN
> disguising themselves as modules.  I also don't want CPAN sites to have
> to figure out what's a review and what's not, so they can filter out
> the reviews.

I too was hoping this would die on its own as an Obviously Bad Idea. 
Having a bunch of POD-only modules is about as appropriate as a review
medium as using email signatures.  Please, don't do this.  Make the
CPAN ratings web site better, or start your own web site, and use a
storage medium other than the CPAN module repository.

-John
0
siracusa
7/22/2004 6:55:04 PM
On Thu, 22 Jul 2004, Ken Williams wrote:

> I was sort of hoping this idea would just die on its own, but now it
> looks like people are actually getting ready to do it.  In my opinion
> this is a bad idea.  I don't want a bunch of reviews all over CPAN
> disguising themselves as modules.  I also don't want CPAN sites to have
> to figure out what's a review and what's not, so they can filter out
> the reviews.

Agreed.  I kind of hoped that by pointing out the steps that would be
involved in posting a review, people would kind of get the clue that the
proposal needs a little work.

> What's wrong with making one of these newfangled things called "web
> sites" to host reviews?  Oh, I know - that already exists.  So how
> about working with those people to fix whatever you think is broken
> about them before polluting CPAN with all this non-code?

It would be really easy to set up a blog or whatever to handle this, but
inevitably someone always asks the question "What About CPAN?"

I'm probably not on enough Perl mailing lists to make an expert opinion,
but the impression I get is that CPAN is a system without a clearly
defined future.

Questions always come up on who maintains it, where is the code, how do we
add this feature, why is the module list out of date, etc, etc.

CPAN works great for distributing perl code and modules, but as a software
package, CPAN is a mystery to a lot of us.


>
>   -Ken
>

--------------------
Christopher Josephes
cpj1@visi.com
0
cpj1
7/22/2004 8:02:28 PM
# The following was supposedly scribed by
# Ken Williams
# on Thursday 22 July 2004 01:50 pm:

>I was sort of hoping this idea would just die on its own, but now it
>looks like people are actually getting ready to do it. =A0

I'm going to jump on the bandwagon with Ken on this one.

>In my opinion=20
>this is a bad idea. =A0I don't want a bunch of reviews all over CPAN
>disguising themselves as modules.

When the discussion started, it was about the ratings and reviews system wh=
ich=20
is already available on CPAN (though little-used.)

I suggested why it was little-used, but that seems to have fallen by the=20
wayside.

>So how
>about working with those people to fix whatever you think is broken
>about them before polluting CPAN with all this non-code?

Let's take a tour...

searching for something...
  http://search.cpan.org/search?query=3DCGI&mode=3Dall

we click through...
  http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm

NO RATINGS ON THAT PAGE!  So, we click the 'up'-like link...
  http://search.cpan.org/~lds/CGI.pm-3.05/

ok, now we see the ratings, click-through to get reviews...
  http://cpanratings.perl.org/d/CGI.pm

Or do we?  I get a 404.  Not much use.

To continue the tour, let's hop over to some module which does have reviews=
=2E..
  http://cpanratings.perl.org/

Alright, pick one at random...
  http://cpanratings.perl.org/d/YAML

=46inally, here we are at a page with reviews.  Frankly, I've never seen on=
e of=20
these before, and I can't say that this one really does me a huge amount of=
=20
good.  I'm much better served by reading the documentation (which should=20
speak for the quality of the module on it's own.)  However, the 1-5 star=20
rating DOES provide a nice at-a-glance view of others' opinions.

So, we have ratings, and we have reviews.  What's wrong?

If anything, the ratings should be shown in the header of the documentation=
=20
page:  http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm and possibly even in =
a=20
column of the search results (now, THAT would be really useful), instead of=
=20
3-clicks into my search.  And, clicking on the bar-o-stars should be a link=
=20
to the reviews (which should, of course, work.)  It is worth noting that I=
=20
(and likely many others) rarely make it to the third click.  Rather,  I ski=
m=20
the documentation, and from there I'm off to a terminal where I type "perl=
=20
=2DMCPAN -e shell" and install the module.

There's more to be done to make it easier to rate and review modules (and o=
ne=20
should be able to rate without reviewing for a simple thumbs-up (though=20
3-or-less stars may require explanation...))

But, the first thing to do is to MAKE THE RATINGS VISIBLE.  That won't be=20
accomplished by creating a new website (except as a trial 'fork' of the mai=
n=20
one) and it won't be accomplished by pretending that Ratings::foo is a=20
module.

Yes, this is long, and SORRY FOR SHOUTING.  I'm just trying to emphasize th=
e=20
important bits for those that are skimming.

There have been others with mostly the same opinions throughout this=20
discussion, so we basically just need the source for search.cpan.org and=20
somebody to write a patch, right?

=2D-Eric
=2D-=20
"Everything goes wrong all at once."
                                        --Quantized Revision of Murphy's Law
0
ewilhelm
7/22/2004 8:05:27 PM
Eric Wilhelm [ewilhelm@sbcglobal.net] quoth:
*>
*>ok, now we see the ratings, click-through to get reviews...
*>  http://cpanratings.perl.org/d/CGI.pm
*>
*>Or do we?  I get a 404.  Not much use.

Well, that's an error and one you should take up with the people who run
the rantings pages at webmaster@perl.org. Graham only pulls the rantings
from their site and it's not local.

*>Finally, here we are at a page with reviews.  Frankly, I've never seen one of 
*>these before, and I can't say that this one really does me a huge amount of 
*>good.  I'm much better served by reading the documentation (which should 
*>speak for the quality of the module on it's own.)  However, the 1-5 star 
*>rating DOES provide a nice at-a-glance view of others' opinions.
*>
*>So, we have ratings, and we have reviews.  What's wrong?

That's a big question and I have a long answer for that but mostly I've
only seen stuff like Randal extorting authors with 1-star ratings, authors
sniping at each other via rantings and in module docs and, when they
aren't petty and vile they're 5-stars with 'great module'. There's a
smattering of useful reviews but, as on Amazon, YMMV. What's wrong isn't a
software issue.

e.
0
elaine
7/22/2004 8:26:56 PM
[BCC]

On 7/22/2004 4:05 PM, Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # Ken Williams
> # on Thursday 22 July 2004 01:50 pm:
> 
> 
>>I was sort of hoping this idea would just die on its own, but now it
>>looks like people are actually getting ready to do it.  
> 
> 
> I'm going to jump on the bandwagon with Ken on this one.
> 
> 
>>In my opinion 
>>this is a bad idea.  I don't want a bunch of reviews all over CPAN
>>disguising themselves as modules.
> 
> 
> When the discussion started, it was about the ratings and reviews system which 
> is already available on CPAN (though little-used.)
> 
> I suggested why it was little-used, but that seems to have fallen by the 
> wayside.

Agreed. Reviews as modules is not the best solution. CPAN does one thing 
and does it well. Adding reviews as modules is likely to cause more 
problems that it solves.

>>So how
>>about working with those people to fix whatever you think is broken
>>about them before polluting CPAN with all this non-code?
> 
> 
> Let's take a tour...
> 
> searching for something...
>   http://search.cpan.org/search?query=CGI&mode=all
> 
> we click through...
>   http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm
> 
> NO RATINGS ON THAT PAGE!  So, we click the 'up'-like link...
>   http://search.cpan.org/~lds/CGI.pm-3.05/
> 
> ok, now we see the ratings, click-through to get reviews...
>   http://cpanratings.perl.org/d/CGI.pm
> 
> Or do we?  I get a 404.  Not much use.

That's a bug. You'll notice the same bug if you click on the CPAN 
Testers link. Is this a bug in <search.cpan.org>? CPAN.pm is one of the 
few if not only module that has a name which includes the extension.

> To continue the tour, let's hop over to some module which does have reviews...
>   http://cpanratings.perl.org/
> 
> Alright, pick one at random...
>   http://cpanratings.perl.org/d/YAML
> 
> Finally, here we are at a page with reviews.  Frankly, I've never seen one of 
> these before, and I can't say that this one really does me a huge amount of 
> good.  I'm much better served by reading the documentation (which should 
> speak for the quality of the module on it's own.)  However, the 1-5 star 
> rating DOES provide a nice at-a-glance view of others' opinions.
> 
> So, we have ratings, and we have reviews.  What's wrong?
> 
> If anything, the ratings should be shown in the header of the documentation 
> page:  http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm and possibly even in a 
> column of the search results (now, THAT would be really useful), instead of 
> 3-clicks into my search.  And, clicking on the bar-o-stars should be a link 
> to the reviews (which should, of course, work.)  It is worth noting that I 
> (and likely many others) rarely make it to the third click.  Rather,  I skim 
> the documentation, and from there I'm off to a terminal where I type "perl 
> -MCPAN -e shell" and install the module.
> 
> There's more to be done to make it easier to rate and review modules (and one 
> should be able to rate without reviewing for a simple thumbs-up (though 
> 3-or-less stars may require explanation...))
> 
> But, the first thing to do is to MAKE THE RATINGS VISIBLE.  That won't be 
> accomplished by creating a new website (except as a trial 'fork' of the main 
> one) and it won't be accomplished by pretending that Ratings::foo is a 
> module.
> 
> Yes, this is long, and SORRY FOR SHOUTING.  I'm just trying to emphasize the 
> important bits for those that are skimming.
> 
> There have been others with mostly the same opinions throughout this 
> discussion, so we basically just need the source for search.cpan.org and 
> somebody to write a patch, right?

Ask posted with information about where to find the source for CPAN 
Ratings, and invited patches. Maybe if we could come up with a list of 
requirements as a start (not implementation or solutions, just 
requirements), we could then look them over as a group and figure out 
which ones are real problems that we need to fix. Then we prioritize 
them, figure out how to solve each, and start writing and submitting 
patches. Note there is also an (outdated) TODO list on the "About" page 
on CPAN Ratings, right next to the links for the source.

This doesn't solve all the issues with <search.cpan.org>, but it will be 
a place to start. And starting seems a good thing to do. This discussion 
has arisen in a dozen or so different threads over the last few months, 
so it is definately a problem ripe for solving. We just need to organize 
and do it.

Regards,
Randy.

0
ml
7/22/2004 9:50:41 PM
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 04:50 pm:

>Ask posted with information about where to find the source for CPAN
>Ratings, 

But, most of the interface improvements (IMO) need to be done to 
search.cpan.org.

I found http://combust.develooper.com/install.html, but the installation 
instructions lead me to a password-protected subversion repository at 
http://svn.develooper.com/

Yes, cpanratings.perl.org could use some bugfixes (and maybe rating-ratings 
(e.g. "your review was stupid, please justify it or remove it".))  But, first 
I think we need to get the ratings to be more visible on search.cpan.org.

--Eric
-- 
"There are three terrible ages of childhood -- 1 to 10, 10 to 20, 
and 20 to 30."
                                        --Cleveland Amory
0
ewilhelm
7/22/2004 10:13:00 PM
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 04:50 pm:

>Maybe if we could come up with a list of
>requirements as a start (not implementation or solutions, just
>requirements), we could then look them over as a group and figure out
>which ones are real problems that we need to fix. Then we prioritize
>them, figure out how to solve each, and start writing and submitting
>patches. Note there is also an (outdated) TODO list on the "About" page
>on CPAN Ratings, right next to the links for the source.

Okay, but we have requirements for both search.cpan.org and 
cpanratings.perl.org, right?

search.cpan.org is the front-end to most module-searching, and I think it 
should stay that way, but should have more visible (read: not so deep) links 
to ratings/reviews and show the "star-bar" in more places.

cpanratings.perl.org should have it's todo-list worked on (maybe broken into 
software and legwork (e.g. 'translations' is not so much software)).

Sorry, but maybe I'm not grasping the connection between search.cpan.org and 
cpanratings.perl.org.  The 'star-bar' at search.cpan.org seems to be a local 
image, but is it pulling the average rating (dynamically) from 
cpanratings.perl.org?  Seems that this is also true for the testers.cpan.org 
'pass/fail' counts

If these sites have separate maintainers, we should be working on two 
requirements lists.

--Eric
0
ewilhelm
7/22/2004 10:30:45 PM
On Thu, 22 Jul 2004, Eric Wilhelm wrote:
> Okay, but we have requirements for both search.cpan.org and
> cpanratings.perl.org, right?

Yes.  cpanratings could display more in depth statistics of the various 
modules and also allow for being to view a module as a whole and not just 
one particular verson of a module.

> search.cpan.org is the front-end to most module-searching, and I think 
> it should stay that way, but should have more visible (read: not so 
> deep) links to ratings/reviews and show the "star-bar" in more places.

For instance it would be nice to be able to sort search results by 
ratings.  Or it'd be nice if that were factored in somehow when doing 
search.  Maybe this would iron out the "greatest module since sliced bread 
that people who don't know the secret handshake have never heard about" 
problem.

> If these sites have separate maintainers, we should be working on two 
> requirements lists.

Some requirements would seem to be related.  For instance, cpanrating may 
need to provide a convenient way to get data that would the be utilized on 
search.cpan.org to make the impact less painful.  Maybe some sort of local 
ratings cache would need to be maintained?

-- 
</chris>
0
chicks
7/22/2004 10:54:40 PM
On Thu, Jul 22, 2004 at 03:26:56PM -0500, Elaine -HFB- Ashton wrote:
> *>Finally, here we are at a page with reviews.  Frankly, I've never seen one of 
> *>these before, and I can't say that this one really does me a huge amount of 
> *>good.  I'm much better served by reading the documentation (which should 
> *>speak for the quality of the module on it's own.)  However, the 1-5 star 
> *>rating DOES provide a nice at-a-glance view of others' opinions.
> *>
> *>So, we have ratings, and we have reviews.  What's wrong?
> 
> That's a big question and I have a long answer for that but mostly I've
> only seen stuff like Randal extorting authors with 1-star ratings, authors
> sniping at each other via rantings and in module docs and, when they
> aren't petty and vile they're 5-stars with 'great module'. There's a
> smattering of useful reviews but, as on Amazon, YMMV. What's wrong isn't a
> software issue.

	How would you suggest we deal with this? Maybe a bit of moderator
intervention?
	I concur with this, btw. The earlier "sacrifice stone" thread had me
picturing my modules (ok, me really) strapped to the stone and a venomous
critic with a very sharp knife getting ready to perform amateur surgery.
	One of the big reasons I haven't published much lately is it isn't
worth it for me to put on an asbestos suit to try to contribute.
	That said, perhaps it would be useful to have a set of "standard"
sort of comments that could be applied to the module, such as "some tests don't
seem to pass" or "requires compilation on the target platform", "module shares
similar functionality as XX", etc. along with other ratings. This would 
hopefully be useful but not condescending information.


	Austin
0
tex
7/22/2004 11:00:40 PM
On Thu, 22 Jul 2004, Randy W. Sims wrote:
>
> Agreed. Reviews as modules is not the best solution. CPAN does one thing
> and does it well. Adding reviews as modules is likely to cause more
> problems that it solves.

Do we really need reviews ? I am afraid not many people will take the
time to do a deep analyzis of a module. On the other hand,  I guess,
they would be ready to give their short opinion or ideas on how to use
the module, or which other module to use instead.

For part of this cpanratings fits well, maybe it needs improvements but
that's one direction.

There are two other options for some improvement:

What about creating an annotation system similar to what PHP has on its
documentation (see www.php.net ) ? It might be part of the rating system
or might be separate.

What about a web based discussion board that is module specific ?
Easy to search, categorized by modules, easy to post - no need to
subscribe to a zillion mailing lists.

Gabor
0
gabor
7/22/2004 11:26:54 PM
On Fri, 23 Jul 2004, Gabor Szabo wrote:
> Do we really need reviews ?

Short of some better sort of solution for helping guide people to the 
better choices of modules.

> I am afraid not many people will take the time to do a deep analyzis of 
> a module.

It doesn't take many people to provide a statistically large enough sample 
to be useful in helping perl newbies avoid the modules that somebody 
cooked up five years ago and hasn't updated since.

> What about a web based discussion board that is module specific ? Easy 
> to search, categorized by modules, easy to post - no need to subscribe 
> to a zillion mailing lists.

That'd be useful.  A lot of modules might form little communities to save 
them from author neglect if they could find each other.  So many modules 
have no mailing list and the author never responds.  Now I don't blame the 
author for not responding, but without some central place for people to 
congregate and trade patches thing die on the vine that wouldn't have to.

-- 
</chris>
0
chicks
7/22/2004 11:32:23 PM
* Austin Schutz <tex@off.org> [2004-07-23 01:03]:
> That said, perhaps it would be useful to have a set of
> "standard" sort of comments that could be applied to the
> module, such as "some tests don't seem to pass" or "requires
> compilation on the target platform", "module shares similar
> functionality as XX", etc. along with other ratings. This would
> hopefully be useful but not condescending information.

These facts are metadata and shouldn't be mixed with the reviews
at all.  Some of the ones you propose are in fact already
available.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/23/2004 12:38:18 AM
On 7/22/2004 5:50 PM, Randy W. Sims wrote:
> We just need to organize and do it.

1st crack at organizing ideas/suggestions made in this thread and in 
Ask's TODO list. Comments/Omissions?

Also available at <http://www.thepierianspring.org/perl/cpan-ratings.notes>

-- 

I) CPAN Ratings

   A) Abuse

      Authors abusing the system for political statements, to sabatoge
      authors of similars modules, etc.

     1) The usuall solution is a Karma type system. Number of reviews
        contributed by a reviewer. Thumbs up/down for individual reviews
        by a reviewer ("Helpfulness ratings"). Thresholds on Karma that
        automatically invoke a moderator.

     2) See also item I.C.1.

   B) All Reviews Pages (per module):

     1) Header with average rating and other summary information.

   C) All Reviews Pages (per reviewer):

     1) Header with reviewer information. (Obfuscated email address
        for one thing; try to keep people accountable).

   D) Searching

     1) If the number of reviews per module gets large, sorting on
        rating/date/version may be useful.

     2) Search results should include direct link to all reviews.

     3) Search results should include "average rating". (average per
        version?  overall average?)

     4) Allow direct search for reviews. I.E. don't send user off to
        CPAN Search, but do try to use it behind the scenes.

   E) Browsing for modules (?)

     1) By module/author.

   F) Author's Administrative interface

     1) Edit review? - Original author only.

     2) "Delete this review" - Original author only.

   G) "Top rated modules list" - Would this encourage abuse?

   H) RSS Feeds

     1) RSS feed of sitewide "recent reviews"

     2) Include rating numbers in the RSS feeds

     3) Subscribe to reviews of certain distributions
        (preferably by author)

     4) Reviews of modules by a certain author (for CPANID.rss feeds)
        [RWS: Same as above?]

   I) Ratings

     1) If a reviewer reviews two or more versions of a module, how are
        the averages calculated?

     2) Expand set of rated attributes?

     3) Let 'Overall' rating be calculated based on other specific
        attributes or let there be some additional type of 'overall' that
        is calulated, and let it be used in summaries--to _encourage_ a
        more balanced review (and discourage abuses).

   J) Other

     1) Reviews in other languages (with filters etc).

     2) Parse Embperl-2.0b9 correctly.

     3) Include the other rating numbers on [some page].

II) Misc:

   A) "Module Pages"

      Usage tips & experiences not directly related to reviews. Doesn't
      have to be organized around modules; it can be organized around
      topics (ala emacswiki). Linked to from CPAN Ratings? CPAN Search?

   B) Best of breed reviews.

      A single comparative review written on several similar
      modules. How would this show up in a search? Does this belong
      with CPAN Ratings?

III) Search CPAN:

   A) make /d/CGI.pm work

      Bug seemingly in Search CPAN for CPAN.pm (others?) possibly due
      to '.pm' being part of name. This appears on the module dist page
      for links to CPAN Testers & CPAN Ratings as 404 errors.

   B) Sorting

      Search results by relevance/rating.

   C) Searching

     1) Improve searching with Keywords (META.yml)




0
ml
7/23/2004 12:56:30 AM
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 07:56 pm:

>Comments/Omissions

>I) CPAN Ratings
>=A0 =A0B) All Reviews Pages (per module):
>=A0 =A0 =A01) Header with average rating and other summary information.

duplicate this in III.B.2

>III) Search CPAN:
>=A0 =A0A) make /d/CGI.pm work

move ^-- this to I.J.4, since it is a cpanratings.perl.org problem

>=A0 =A0B) Sorting
>=A0 =A0 =A0 1) Search results by relevance/rating.

         3) include 'star-bar' on manpage (as link to reviews)

e.g. http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm

=2D Module Version: 3.05
+ Module Version: 3.05   Source  ****

=2D-Eric
=2D-=20
"When the going gets tough, most people quit."
                                        --Unknown
0
ewilhelm
7/23/2004 3:19:36 AM
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 07:56 pm:

>=A0 =A0A) Abuse
>
>=A0 =A0 =A0 Authors abusing the system for political statements, to sabato=
ge
>=A0 =A0 =A0 authors of similars modules, etc.
>
>=A0 =A0 =A01) The usuall solution is a Karma type system. Number of reviews
>=A0 =A0 =A0 =A0 contributed by a reviewer. Thumbs up/down for individual r=
eviews
>=A0 =A0 =A0 =A0 by a reviewer ("Helpfulness ratings"). Thresholds on Karma=
 that
>=A0 =A0 =A0 =A0 automatically invoke a moderator.

Okay, so if I go on a bashing-fest and then you come through and thumbs-dow=
n=20
all of my reviews, I'll go through and thumbs-down your reviews too and the=
n=20
bash on your modules if I haven't made it there already.  Does that trigger=
 a=20
karma threshold of some sort?  Seems that it would be hard to detect.

How about peer-review of peer-review:

If I say that your review was bad, I think the next step is for you to defe=
nd=20
your review (unless it has previously gotten a thumbs-up, in which case I=20
must support my thumbs-down with a critique of your review.)

There may be a somewhat recursive process of attack and rebuttal here, but =
the=20
point is that a mean review is likely not going to be defended, and even if=
=20
it had received a spurious thumbs-up, a critical dismissal of said mean=20
review is likely to be supported rather than dismissed (thus giving weight =
to=20
the dismissal and counting further towards the thumbs-down.)

Recursion to level 3-or-so (pi) of the attack-rebuttal tree may invoke a=20
moderator (or just a chanting, blood-lusting crowd/mob.)

Additional weight can be given to reviewers who have posted many reviews an=
d=20
received many thumbs-up, etc.  But, the idea behind the tree is that it=20
localizes the debate to the review in question (rather than risk weighting=
=20
solely on what may have been karma generated by a flaming disagreement abou=
t=20
a completely different module's merits.)

Absolute dead-beats can still be identified by their failure to provide a=20
rebuttal or continually reaching level pi() with nonsensical or null=20
arguments.

=2D-Eric
=2D-=20
"You can't win. You can't break even. You can't quit."
           --Ginsberg's Restatement of the Three Laws of Thermodynamics
0
ewilhelm
7/23/2004 3:41:00 AM
On 7/22/2004 11:41 PM, Eric Wilhelm wrote:

> # The following was supposedly scribed by
> # Randy W. Sims
> # on Thursday 22 July 2004 07:56 pm:
> 
> 
>>   A) Abuse
>>
>>      Authors abusing the system for political statements, to sabatoge
>>      authors of similars modules, etc.
>>
>>     1) The usuall solution is a Karma type system. Number of reviews
>>        contributed by a reviewer. Thumbs up/down for individual reviews
>>        by a reviewer ("Helpfulness ratings"). Thresholds on Karma that
>>        automatically invoke a moderator.
> 
> 
> Okay, so if I go on a bashing-fest and then you come through and thumbs-down 
> all of my reviews, I'll go through and thumbs-down your reviews too and then 
> bash on your modules if I haven't made it there already.  Does that trigger a 
> karma threshold of some sort?  Seems that it would be hard to detect.
> 
> How about peer-review of peer-review:
> 
> If I say that your review was bad, I think the next step is for you to defend 
> your review (unless it has previously gotten a thumbs-up, in which case I 
> must support my thumbs-down with a critique of your review.)
> 
> There may be a somewhat recursive process of attack and rebuttal here, but the 
> point is that a mean review is likely not going to be defended, and even if 
> it had received a spurious thumbs-up, a critical dismissal of said mean 
> review is likely to be supported rather than dismissed (thus giving weight to 
> the dismissal and counting further towards the thumbs-down.)
> 
> Recursion to level 3-or-so (pi) of the attack-rebuttal tree may invoke a 
> moderator (or just a chanting, blood-lusting crowd/mob.)
> 
> Additional weight can be given to reviewers who have posted many reviews and 
> received many thumbs-up, etc.  But, the idea behind the tree is that it 
> localizes the debate to the review in question (rather than risk weighting 
> solely on what may have been karma generated by a flaming disagreement about 
> a completely different module's merits.)
> 
> Absolute dead-beats can still be identified by their failure to provide a 
> rebuttal or continually reaching level pi() with nonsensical or null 
> arguments.

I don't think anything this complicated or involved is needed. Neither 
am I convinced that the Karma solution is the best or a complete 
solution. However, This is pretty much the system that Amazon.com uses 
and it works pretty well IMO. Also, for this to get into back and forth 
arguments/bashing, the reviewers would have to attempt to track all of 
their reviews. The system would not provide an easy way to do that-there 
is no legitimate need for such a feature since the system is about 
reviews not reviewers. That's not to say it's not possible, but it's not 
easy either. I think that will discourage a large percentage of abuse, 
and high percentages is the best you can shoot for.

Regards,
Randy.



0
ml
7/23/2004 3:54:15 AM
Austin Schutz [tex@off.org] quoth:
*>
*>	How would you suggest we deal with this? Maybe a bit of moderator
*>intervention?
*>	I concur with this, btw. The earlier "sacrifice stone" thread had me
*>picturing my modules (ok, me really) strapped to the stone and a venomous
*>critic with a very sharp knife getting ready to perform amateur surgery.
*>	One of the big reasons I haven't published much lately is it isn't
*>worth it for me to put on an asbestos suit to try to contribute.

I don't like the rantings and think they add very little overall value
precisely because of the kind of reaction you seem to be having. People
pushed and whined for years and we were unenthused because we knew it
would turn into a mostly unmoderated slugfest that would taint the
willingness of some authors and even drive a few away which, if sustained,
could really damage the archive.

Moderator intervention? No, because the same rule that makes people give
lousy 1-star reviews and rantings also applies to moderators who are not
indiscriminate in their moderating. I think the stars without reading the
reviews is horribly misleading and there are a number of modules who have
gotten crap reviews undeservedly. I am not a fan of the cpanrantings. I'd
remove the site and replace it with an account on hates-software.com, but
I'm a softie.

And, the same people who are now bored with rantings are setting their
sights on a download statistics site. Folly and utterly meaningless
numbers at their finest but in a tiny little corner of the world where
size still matters, there's going to be a lot of crushed egos. Those who
hate the rantings will /really/ hate the idea of wildly inaccurate
download stats.

e.
0
elaine
7/23/2004 7:27:13 AM
Christopher Hicks [chicks@chicks.net] quoth:
*>On Fri, 23 Jul 2004, Gabor Szabo wrote:
*>>Do we really need reviews ?
*>
*>Short of some better sort of solution for helping guide people to the 
*>better choices of modules.

Writing a useful analysis, good or bad, pro or con, takes a lot of time,
thought and energy which few seem to take into consideration when writing
them. There are a number of objective points that users could use to judge
a module without including the wildly subjective view of people with a
grudge or an axe to grind.

Just about every argument for the rantings has included the 'think of the
newbies!' angle and, for the most part, I think this is a red herring as
people who can't point and click, can't distinguish a useful review from a
flawed review or can't figure out what a module does without reading the
documentation [if it has any] just aren't going to benefit from something
like cpanrantings. I might also add that those who push this argument the
most vehemently are the least likely to post reviews or even articulate
ones. 

I have pushed before and will continue to push the concept of author
bundles and SDK-esque bundles where a group of valued, quality and well
regarded modules could be trivially batch installed by users via cpan.pm
or cpanplus. 

The problem with cpanrantings is /not/ software. 

e.
0
elaine
7/23/2004 8:43:23 AM
* Randy W. Sims <ml-perl@thepierianspring.org> [2004-07-23 07:46]:
> 1) The usuall solution is a Karma type system.

Perlmonks shows that a Karma system needn't go horribly wrong,
but it also shows that it can't deter a troll.

Kuro5hin shows that it may only barely have any appreciable
effect whatsoever.

Slashdot shows that it can fail spectacularly.

I have yet to see any evidence that any Karma system actually
achieves its stated goal.

Regards,
-- 
Aristotle
"If you can't laugh at yourself, you don't take life seriously enough."
0
pagaltzis
7/23/2004 9:48:10 AM
Randy W. Sims sent the following bits through the ether:

> >  http://cpanratings.perl.org/d/CGI.pm
> >
> >Or do we?  I get a 404.  Not much use.
> 
> That's a bug. You'll notice the same bug if you click on the CPAN 
> Testers link. Is this a bug in <search.cpan.org>? CPAN.pm is one of the 
> few if not only module that has a name which includes the extension.

FWIW it's a bug in CPAN Testers too because the distribution name has
a dot in it. I was trying to be a little secure and avoid people
trying to do have tester reports which have "../../etc/whatever". I
might be being a bit over strict, but then again I think it's stupid
that it's called CGI.pm.

The source to the CPAN Testers website is available on CPAN (unlike
the other sites mentioned in this thread). Patches welcome.

Leon
-- 
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/

.... How do you pronounce my name? With reverence ;-)
0
acme
7/23/2004 11:32:33 AM
# The following was supposedly scribed by
# Randy W. Sims
# on Thursday 22 July 2004 10:45 pm:

>> - Module Version: 3.05
>> + Module Version: 3.05 =A0 Source =A0****
>
>The ratings are one click away on the dist page.

Yes, but as I said on the 'tour', I don't want or need to click there unles=
s=20
I'm trying to download the tarball.  And, since I use the command-line CPAN=
=20
to do the install, I don't need to download the tarball from my browser.  S=
o,=20
I almost *never* see that page.

>Lincoln D. Stein > =A0CGI.pm-3.05 > =A0CGI
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^ click ^^
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^ here =A0^^
>Module Version: 3.05 =A0 Source

My point in putting the star-bar here --^ is that it makes the ratings=20
visible.

This accomplishes two things:

  1.  makes ratings more useful (e.g. while I'm reading the manpage (which =
is=20
what drives the decision as to whether it is what I'm looking for) I can se=
e=20
the rating (and maybe I should also see a count of how many have rated it.))

  2.  raises awareness about ratings (oh!  there are ratings?), thus gettin=
g=20
more people to rate/review modules.

If ratings are good for anything, they are going to be taken with a grain o=
f=20
salt.  A 5-star rating vs a 0-star rating is not going to swing me away fro=
m=20
my own judgement.  They simply give me something else to consider.

I would also like to see a simple yes/no count in addition to the=20
rating/reviews.  If you have a list of "35 people use this::module" and "70=
0=20
said 'use this::other::module instead'", that helps raise awareness about t=
he=20
other module, and allows you to make a decision more quickly based on the=20
experiences of others.

=2D-Eric
=2D-=20
Entia non sunt multiplicanda praeter necessitatem.
                                        --Occam's Razor
0
ewilhelm
7/23/2004 4:10:50 PM
[Did I not reply to list in my previous message?]

Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # Randy W. Sims
> # on Thursday 22 July 2004 10:45 pm:
> 
> 
>>>- Module Version: 3.05
>>>+ Module Version: 3.05   Source  ****
>>
>>The ratings are one click away on the dist page.
> 
> 
> Yes, but as I said on the 'tour', I don't want or need to click there unless 
> I'm trying to download the tarball.  And, since I use the command-line CPAN 
> to do the install, I don't need to download the tarball from my browser.  So, 
> I almost *never* see that page.
> 
> 
>>Lincoln D. Stein >  CGI.pm-3.05 >  CGI
>>                     ^^ click ^^
>>                     ^^ here  ^^
>>Module Version: 3.05   Source
> 
> 
> My point in putting the star-bar here --^ is that it makes the ratings 
> visible.
> 
> This accomplishes two things:
> 
>   1.  makes ratings more useful (e.g. while I'm reading the manpage (which is 
> what drives the decision as to whether it is what I'm looking for) I can see 
> the rating (and maybe I should also see a count of how many have rated it.))
> 
>   2.  raises awareness about ratings (oh!  there are ratings?), thus getting 
> more people to rate/review modules.

I think one of the best ways to raise awareness is to add the ratings to 
the search results from Search. I'm still not sure that I agree about 
putting it on the documentation page, but I have added it to the 
outline. If it does get added, does it get added to all the 
documentation pages or just the main documentation page?

> If ratings are good for anything, they are going to be taken with a grain of 
> salt.  A 5-star rating vs a 0-star rating is not going to swing me away from 
> my own judgement.  They simply give me something else to consider.
> 
> I would also like to see a simple yes/no count in addition to the 
> rating/reviews.  If you have a list of "35 people use this::module" and "700 
> said 'use this::other::module instead'", that helps raise awareness about the 
> other module, and allows you to make a decision more quickly based on the 
> experiences of others.

Are you referring to the amazon.com-ish "N persons recommend X instead 
of (or in addition to) Y" type recommendations? I'm not sure CPAN is 
worth the added complexity. I don't think the target audience is big 
enough to justify a lot of "extra" features; the ratings should be 
enough, but I could be wrong...

Maybe we need to start prioritizing and weeding out the list at this point?

I hope others are interested in helping to implement these improvements. 
I'm going to try, but I have two obstacles: 1) the usuall problem--time, 
and 2) this is not my area of expertise. I have no experience with CGI, 
setting up Apache, etc. It's an area I've never really gotten into, but 
I hope to use this as an opportunity to learn a little.

Regards,
Randy.
0
ml
7/24/2004 8:06:18 PM
# The following was supposedly scribed by
# Randy W. Sims
# on Saturday 24 July 2004 03:06 pm:

>[Did I not reply to list in my previous message?]

no.  sorry if I failed to mention it.

>I think one of the best ways to raise awareness is to add the ratings to
>the search results from Search. I'm still not sure that I agree about
>putting it on the documentation page, but I have added it to the
>outline.

Compactness is important here.  I don't think that much more than a horizontal 
inch of screen-space should be absorbed.  Just something large enough for a 
link to cpanratings and a very terse summary of what you would find by 
following that link.

>If it does get added, does it get added to all the 
>documentation pages or just the main documentation page?

Could you give an example of what is 'main'?  I mean the page with the 
rendered version of the pod.  On my tour, I clicked the bigger-bolder link 
above the search-result entry 
(http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm) not the 
smaller-seemingly-less-important one below it 
(http://search.cpan.org/~lds/CGI.pm-3.05/).

To me, the former contains information which will let me make an informed 
decision about the module (e.g. the programmer's reference to the API which 
it provides) while the latter gives lots of links, ratings, test results, and 
related stuff, but only tells me this about the module in question: "Simple 
Common Gateway Interface Class" and I have already seen that exact 
information in the search-result entry.

>> I would also like to see a simple yes/no count in addition to the
>> rating/reviews.  If you have a list of "35 people use this::module" and
>> "700 said 'use this::other::module instead'", that helps raise awareness
>> about the other module, and allows you to make a decision more quickly
>> based on the experiences of others.
>
>Are you referring to the amazon.com-ish "N persons recommend X instead
>of (or in addition to) Y" type recommendations? I'm not sure CPAN is
>worth the added complexity. I don't think the target audience is big
>enough to justify a lot of "extra" features; the ratings should be
>enough, but I could be wrong...

For one, search.cpan.org would not be the keeper of this content.  It would 
have to be provided by cpanratings.

(as an aside, http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm does not (IMO) 
need to contain the 'search' bar.  If I'm looking at this page, I've probably 
got a previous browser window/tab with the original search results 
(http://search.cpan.org/search?query=CGI&mode=all) in it.  If not (e.g. I 
stumbled in from google), a 'home' link would be enough to get me there.)

I'm not sure right now how useful it would be or how many others would find it 
useful, but yes the N,X,Y is along the lines of what I mean.  The reason that 
I mention it is simply that I had the idea that it might be useful in 
selecting modules (yes, it's a popularity contest and should be ignored in 
favor of an informed decision based on reading the manpage, but we can't 
ignore information that isn't there.)

I'm sort of groping for something to 'season' the average-rating.  Since I am 
suggesting that the average rating be displayed at the top of the manpage, I 
thought I should provide an idea which would allow it to mean more than 5/5 
(e.g. one person rated it 5/5:  'big whoop'.)

I think '600 people said "it's useful"' may be more helpful than one mediocre 
review.  60 raving reviews would tend to bend your decision more, but it's 
easier to get 600 people to say 'ok' than it is to get 60 to say 
'this-is-great-and-here-is-why'.

--Eric
-- 
"One of the serious obstacles to the improvement of our race is 
indiscriminate charity."
                                        --Andrew Carnegie
0
ewilhelm
7/24/2004 8:39:18 PM
Eric Wilhelm wrote:
> Absolute dead-beats can still be identified by their failure to provide
> a rebuttal or continually reaching level pi() with nonsensical or null
> arguments.

How about putting rebuttals in your module's POD? ;-)
It's been done before. No, really it has:
 <http://cpanratings.perl.org/a/3860>
See the module review of Unix (0.02) module.
AFAICT, this Unix-0.02.tar.gz distribution (with its review rebuttal) has
since been removed from CPAN.

/-\


Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
0
ajsavige
7/25/2004 11:52:38 PM
Sorry for the delay. I haven't abandoned this; it's just been a long 
week, and there are some issues here that I've thought of that I'm 
unresolved on, but I'll bring that back up another time...

Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # Randy W. Sims
> # on Saturday 24 July 2004 03:06 pm:
> 
> 
>>If it does get added, does it get added to all the 
>>documentation pages or just the main documentation page?
> 
> 
> Could you give an example of what is 'main'?  I mean the page with the 
> rendered version of the pod.  On my tour, I clicked the bigger-bolder link 
> above the search-result entry 
> (http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm) not the 
> smaller-seemingly-less-important one below it 
> (http://search.cpan.org/~lds/CGI.pm-3.05/).

If you look at the page linked to by the "less-important" url, you'll 
see links to all the pod docs for that module. I was asking if you 
intended that the ratings be added the headers of all of that modules docs.

> To me, the former contains information which will let me make an informed 
> decision about the module (e.g. the programmer's reference to the API which 
> it provides) while the latter gives lots of links, ratings, test results, and 
> related stuff, but only tells me this about the module in question: "Simple 
> Common Gateway Interface Class" and I have already seen that exact 
> information in the search-result entry.

The latter links to all of the modules docs, the README, META.yml, etc. 
for all versions of that module. It's provides a junction point that 
leads to all info on that module. This is always the first place I go. I 
look at the README first, then the main pod. Then I can look at the 
META.yml if I need to check out dependencies, etc. before installing.

One other thing to consider: if ratings are added to the search results 
page, eg. <http://search.cpan.org/search?query=CGI>, then placing them 
on the documentation page is duplicating info that has already been made 
available.

>>>I would also like to see a simple yes/no count in addition to the
>>>rating/reviews.  If you have a list of "35 people use this::module" and
>>>"700 said 'use this::other::module instead'", that helps raise awareness
>>>about the other module, and allows you to make a decision more quickly
>>>based on the experiences of others.
>>
>>Are you referring to the amazon.com-ish "N persons recommend X instead
>>of (or in addition to) Y" type recommendations? I'm not sure CPAN is
>>worth the added complexity. I don't think the target audience is big
>>enough to justify a lot of "extra" features; the ratings should be
>>enough, but I could be wrong...
> 
[snip]
> 
> I'm not sure right now how useful it would be or how many others would find it 
> useful, but yes the N,X,Y is along the lines of what I mean.  The reason that 
> I mention it is simply that I had the idea that it might be useful in 
> selecting modules (yes, it's a popularity contest and should be ignored in 
> favor of an informed decision based on reading the manpage, but we can't 
> ignore information that isn't there.)
> 
> I'm sort of groping for something to 'season' the average-rating.  Since I am 
> suggesting that the average rating be displayed at the top of the manpage, I 
> thought I should provide an idea which would allow it to mean more than 5/5 
> (e.g. one person rated it 5/5:  'big whoop'.)

agreed. I think where ever "average" ratings are displayed it should 
include the number of reviewers, eg "this module rated 4.5 stars by N 
reviewers".

> I think '600 people said "it's useful"' may be more helpful than one mediocre 
> review.  60 raving reviews would tend to bend your decision more, but it's 
> easier to get 600 people to say 'ok' than it is to get 60 to say 
> 'this-is-great-and-here-is-why'.


I'm worried about some of the items that are on the list. Some that seem 
obvious like adding ratings to the search results on Search I'm not sure 
about any more. If ratings are used to compare modules (as opposed to 
judging each according to its merrits), some modules might be 
overlooked, especially new modules. Are ratings usefull? I won't argue 
that reviews are usefull. And ratings provide a summary of reviews, so 
are helpfull in that respect. But can ratings be harmfull? ...

Randy.
0
ml
8/2/2004 2:54:25 AM
# The following was supposedly scribed by
# Randy W. Sims
# on Sunday 01 August 2004 09:54 pm:

> If ratings are used to compare modules (as opposed to
>judging each according to its merrits), some modules might be
>overlooked, especially new modules. 

True, and the "popularity metric" that I was proposing would probably only 
worsen the situation.

>Are ratings usefull? I won't argue 
>that reviews are usefull. And ratings provide a summary of reviews, so
>are helpfull in that respect. But can ratings be harmfull? ...

It depends on the complexity of the module (or the task that the module 
facilitates.)  And, on the user.  IMO, CPAN should provide as much 
information as is possible in a compact and accurate way.

If I'm basically digging through a namespace on CPAN, I'm likely to try the 
first module which looks like it has a simple interface and fills the bill.  

Seems that a popularity metric and ratings would just help highlight this 
module.

Typically, I'll install it and try it.  If it is too simplistic or doesn't 
function the way I want it to, I'll peek at the code and consider modifying 
it or looking for a more fully-featured module.

If it is too complicated (maybe I'm looking for a more DWIM module), I'll go 
digging some more.

If this is somewhat typical, new modules which don't do something new won't 
get found, but new modules which have something to offer will.

If they get rated, then we'll have two or three highly rated modules fitting 
the same description.  One is the DWIM, another is the kitchen-sink version, 
and maybe the third is the object-oriented kitchen-sink version.

So, if ratings are harmful, which hurts more?  The pain of your module not 
getting found or the collective pain of everybody not finding the module they 
want?

--Eric
-- 
"Chess is a foolish expedient for making idle people believe 
they are doing something very clever when they are only wasting 
their time."
                                        --George Bernard Shaw
0
ewilhelm
8/2/2004 4:14:13 AM
On Sun, 1 Aug 2004, Eric Wilhelm wrote:
>> If ratings are used to compare modules (as opposed to
>> judging each according to its merrits), some modules might be
>> overlooked, especially new modules.
>
> True, and the "popularity metric" that I was proposing would probably only
> worsen the situation.

One of the "good ideas" in this thread to me was the application of them 
to search.  I agree that new unreviewed modules might be hurt by this, but 
if the search order let both the review rating and the "recentness" 
influence its order people would tend to be directed to the right place 
sooner.

> Seems that a popularity metric and ratings would just help highlight 
> this module.

As much as helping you highlight the right module it would hopefully let 
you steer clear of the poorly documented unmaintained module as well.

-- 
</chris>
0
chicks
8/2/2004 11:44:29 AM
Reply:

Similar Artilces:

New Module: Time::Seconds::GroupedBy
Hi all, I've made a new module, I'm thinking to call it Time::Seconds::GroupedBy. It is designed to convert an amount of seconds in other time units. I'm calling time units SECONDS, MINUTES, HOURS, DAYS, MONTHS, and YEARS . The user defines which will be the time unit to group the amount of seconds. Using my module, the following test code: use strict; my $seconds = 31556931; foreach ('MINS', 'HOURS', 'DAYS', 'MONTHS', 'YEARS') { my $s = new GroupedBy ( $_ ); my ($secs, $mins, $hours, $days, $months, $y...

new module Time::Seconds::GroupedBy
Hi all, I made a new module to calculate time duration. My module differs from DateTime::Duration because it is not dealing with dates. It does not try to foresee which is a future of past date based in a bunch of seconds. It just provide a means to calculate a "time quantity" that is more human readable than a big number of seconds. For example, if you're making a big file transfer over the network everyday, and this transfer takes 7341 seconds to finish, and you want to receive a report saying how much time the transfer took, indeed, you want to know that the file tr...

new module: Time::Seconds::GroupedBy #2
------=_NextPart_000_002D_01C468D0.01B08B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I've made a new module, I'm thinking to call it = Time::Seconds::GroupedBy. It is designed to convert an amount of seconds in other time units. I'm = calling time units SECONDS, MINUTES, HOURS, DAYS, MONTHS, and YEARS . The user defines which will be the time unit to group the amount of seconds. Using my module, the following test code: use strict; my $seconds =3D 31556931; foreach ('MINS', 'HOURS...

Fw: new module: Time::Seconds::GroupedBy
> I would rather see more standardization on the use of the DateTime > project, in much the same way that people think of DBI when they think > of accessing databases through Perl. > > In this case, perhaps some clear documentation and examples (just like > the one above) would be the best solution. I think if such a solution > was easy to find on Google and clearly documented, people would use it, > especially once there is more awareness of DateTime as a comprehensive > date & time solution for Perl. I agree Mark, i've posted my module on the DateT...

modules, modules
This site appears to be the most comprehensive list of free custom modules: www.dnnfaq.com Any other sites? I do like how Rainbow gives you a bucket of them - saves a lot of time over having to snoop around and find some of the DNN ones. Is there also a way to list modules as "certified"? Also - is there a decent repository of skins? I have recently installed version 2.0. Sure wish there were more modules ready for it! That would make it much easier to evaluate the program and give recommendations to my boss. The reason there aren't more 2.0 modules yet is becasue it h...

Module in Module
Hi, Is there a way to place a module inside another module (e.g. A feedback module inside a Text/HTML module) ? Cheers Tassos There is a way to inject controls into a module dynamically based on some criteria like a querystring parameter - is that what you are wanting to do?Dylan Barberread my stupid blog http://codemypantsoff.com There's a commercial module "wrapper" on Snowcovered that is designed to hold other modules.  So it is possible.I don't know if you could put a module holding a module inside a module containing a module, but I wouldn't try.  The entire space-time...

3.0.x Issue / Request: "Apply these module settings to new modules"
Looks great so far -- one of the properties I usually change everytime is the 'personalization' property. Can the DNN core team put this on the top-bar like the module title now (maybe as a dropdown list), so that the 'personalization' can be set without having to modify each module? More importantly, can you add some type of user interface to the module settings page like 'apply these settings to new modules'? I find myself always going in and setting the container, personalization, etc for every module I add. One of DNN's strengths is that you can create pages/content very quickly, ...

new emulation experiment
I've decided to start an experiment to see how much of a wheel I've remade when I released SQL::Routine and its friends. The results of it may end up being of practical use, or they may end up having just been a throw-away fun exercise. What I will do is create forks of various popular CPAN modules whose problem domain involves parsing and/or generating SQL or equivalents. With each one I will swap out as much as possible of the internals and replace them with a SQL::Routine object, so that what remains of each module is then a wrapper of SQL::Routine. The intent is ...

New module: DNF Toplist / Voting module
DNF Toplist Module With this module you can create lists like top 10 DVD's or any other subject of your choice. You can set the initial order of the items in your list. The users can of you want vote once per module and the votings will change the order of the list. So the users can change your top 10 DVD's list by voting on their favourite DVD. Simple yet useful. More on this on www.snowcovered.com or www.dotnetfriends.comModules - Skins - Containers Custom development and more... ------------------------------------------ Andreas Kviby Dotnetfriends www.dotnetfriends.com ...

a new version, new modules new skinobjects new colorpalettes new links
Hi Well dnn3 is on the horizon lots of people are working on some cool new stuff to add, so am I. A new free menu stem pure css based combined with a skinpackage also pure css based very fast loading and pretty much xbrowser. No need to buy sidemenus vetical menus etc all this can be handled in css alone. Im also working on some new modules and a javascript helper ( as some of you kow I love my Javascript :). But each new portal starts with a new designs and i found some more interesting color links. Colourlover User submitted colors and color schemes. this is my favourite some ver...

manually adding module from 3.0.13 to 3.1: new fields..
Hi, i have a simple dnn module (simple to dnn, but a link to a bit of complex db-oriented work in an outside app) that was working for 3.0.13. I am having trouble finding in the docs where and how to manually add a module in 3.1. I am getting an error message like "A critical error has occurred.Input string was not in a correct format." but not telling me which or why or how. Anyone have any urls or pointers? My module has no controller class, it is a simple module with one ascx file plus a few resources. Thanks for any thoughts, drew.. further info: i wanted to put my module into a compan...

Custom Module.. 3.0 Edit/Add Module
My actions.add looks like this /code Actions.Add(GetNextActionID, Localization.GetString Entities.Modules.Actions.ModuleActionType.AddContent, LocalResourceFile), Entities.Modules.Actions.ModuleActionType.AddContent, "", "", EditUrl(), False, DotNetNuke.Security.SecurityAccessLevel.Edit, True, False) Return Actions /code My Local Resource File has this <data name="AddContent.Action" type=""> <value>Edit</value> </data> My key in my edit module is Edit. Any ideas on why this isn't wor...

Modules within Modules
I purchaced the Internal Link Navigation from Snowcovered a while back and have modified it so I can insert user controls in the child-level pages. However, if I try to insert a IBS module, it returns an error because the IBS modules use desktopcontols.vb to pull properties for the module from the database and I haven't set that up properly. When I look at the code in tablayout.aspx.vb I have a hard time sorting through it. Any ideas? Do you want to post your mods to Internal Link Navigation - I have done a fair bit of work with that so may be able to help Or email the code to me Dav...

There is already a Module with this name. You cannot create a new Module with the same name.
Hi I upgraded ,y DNN site from 3.0.12 to 3.0.1. When I try to create new module definition in Host -> Module definition I keep getting this error message There is already a Module with this name. You cannot create a new Module with the same name. Any one else get the same ? Classifieds, Events, News and Quiz module for DotNetNuke Yeah - i had this one.  It was also during a 3.012 to 3.10 upgrade. That error message is the default 'fall-back' error message that is displayed when the 'add' method falls over for whatever reason - not necessarily reflecting the actual pr...

Web resources about - new module: Time::Seconds::GroupedBy #3 - perl.module-authors

Resources last updated: 12/7/2015 9:02:16 PM