perl.books.workers

manning permission by Uri Guttman

From: Uri Guttman
good day for permissions, as manning just replied too.

uri

Uri,

Absolutely no problem with using the book covers and links as you described.
In addition to the individual book web pages, we would appreciate a link to
the Manning Perl page where we have images of the current Perl books,
forthcoming titles, and even some nice new graphics for UGs to use at
www.manning.com/perl.html.

Also, if you plan to post sample chapters at your book site, we can send you
the PDf files.

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: linking permissions by Uri Guttman

From: Uri Guttman
well, we can copy o'reilly covers and deep link to them. i asked manning
also and i expect they will let us do this too but i haven't heard back
from them yet. we should put these permissions on some sort of legal
disclaimer page at some point.

uri

To: Uri Guttman , permissions@oreilly.com, cs@oreilly.com
From: Cindy Wetterlund
Subject: Re: linking permissions

Dear Uri,

Thanks for your mail and interest. O'Reilly grants you permission to
link to whatever Perl-related information on our site that might be
helpful or useful. You also have our permission to copy the book cover
images to enhance the images locally on your site.

Good luck with the project!

Best wishes,

Cindy

At 11:37 PM 8/30/2002 -0400, Uri Guttman wrote:

>books.perl.org may actually become a reality soon. we are creating a
>comprehensive site with information and links to all perl (and related)
>books. we want to know if we have permission to copy o'reilly book cover
>images to store on this site which will make the pages look better and
>display faster. also we will be linking to various book pages including
>their home page, contents, index, sample chapters, or whatever useful
>info we can find. this will not be copied but only deep linked.
>
>knowing your great support of the perl community i don't expect this to
>be a problem but we wanted explicit permission. it will then make it
>easier to get it from other publishers.
>
>the current prototype of the site is at:
>
> http://ouroboros.anu.edu.au/books/
>
>thanx,

Cindy Wetterlund
International Rights and
Licensing Manager
cindyw@oreilly.com

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: blobs by Drew Taylor

From: Drew Taylor As Dave mentioned already, file upload is your friend. I'm using it at work
to do exactly this sort of thing (attach a custom image to a db record).
Works great, and dead simple once you have the proper filesystem
permissions. :-)

Drew

At 02:03 PM 8/29/02 +1000, Iain Truskett wrote:

>Well, part of the idea is that all that ever changes on the site is the
>db. If I'm wanting to write images to disc from my components (since one
>of the other ideas is that it's fully maintainable via the web), I'll
>need to be able to write to disc.

--
Drew Taylor | Web development & consulting
http://www.drewtaylor.com/ | perl/mod_perl/DBI/mysql/postgres
----------------------------------------------------------------------
"If you don't know what your program is supposed to do,
you'd better not start writing it." -Edsger Dijkstra
----------------------------------------------------------------------
Speakeasy.net DSL - http://www.speakeasy.net/refer/29655

Re: blobs by Dave Rolsky

From: Dave Rolsky On Thu, 29 Aug 2002, Iain Truskett wrote:

> > This shouldn't be necessary if you are storing raw image data, actually.
>
> That's what I thought, but it didn't appear to be working.

You're using Postgres, right? Either the server or the driver is broken
with respect to binary data containg "\0", I believe.

> Well, part of the idea is that all that ever changes on the site is the
> db. If I'm wanting to write images to disc from my components (since one
> of the other ideas is that it's fully maintainable via the web), I'll
> need to be able to write to disc.
>
> Which is doable I suppose. It makes things easier in some respects. I'll
> confer with Robrt.
>
> In essence: assume that we can't (and don't want to) scp/ftp stuff.

But you can handle file uploads, I'm sure. I maintain the
apprentice.perl.org site and help out with jobs.perl.org, and with both of
them we can write to disc. Else how could you add new components?

-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: blobs by Uri Guttman

From: Uri Guttman >>>>> "IT" == Iain Truskett writes:

>> so why not have 3 links? same thing as one but you store 3 url's in
>> the DB (if the book has all 3 sizes).

IT> Because the site may only have one version? Amazon usually has three
IT> different versions (it's where all but about two of the covers on the
IT> current site come from [those two being 'Practical mod_perl', and
IT> 'Embedding Perl in HTML with Mason']). Or, the site may have one version
IT> and it's shite. It's usually the author's sites that have the best
IT> versions (and, yes, we could link there), but ideally all our iamges are
IT> around about the same size (aspect ratio notwithstanding).

IT> *Ideally* we have a nice big hires copy that we can scale however we
IT> like. We, obviously, can't just reference one image and use IT> width/height> unless we also store the aspect ratio.

>> > We could always cache and Magick them, but then we'd be storing =)

>> my whole point. why store when we don't have to.

IT> Flexibility.

i wasn't thinking about image sizing on the fly. i assumed that if there
was only 1 image, then all 3 urls would use it. much simpler than
worrying about what size it was and making 3 properly sized images from
it. but then i don't do much image hacking. this seems more a nice touch
than a needed feature. i would rather you spend your time on getting the
other links (home page, contents, etc.) going and then we can brainstorm

>> > There's another kettle of fish. Some places don't even like links to
>> > images from pages that aren't on their servers.

>> well, we can deal with that later. this is a non-profit info site. we
>> can ask the major publishers for permission (o'reilly and manning will
>> surely let us. i bet most of the others will too).

IT> That's what I suspect. I suspect they would even be friendly to us
IT> having copies of the covers ourselves.

yep.

>> i can do it for those two as i know people there. i don't know the
>> other publishers. i think we could just do the linking and let them
>> complain first. then we get permission or drop them.

IT> Which sounds a good step. We'd have two for precedent =)

ok, i will do that soon. i expect no issues from those two.

>> it is free publicity (unless the book sux) so they probably won't
>> mind. out site should help sell books which is what they want.

IT> Even bad books get good reviews. See Amazon =) The trick with this site
IT> is to get the Perl community rating and reviewing, because they
IT> theoretically know better than Joe Dredd who just picked up his Perl/CGI
IT> book and is looking for something more. And good books get bad reviews,
IT> etc.

oh, i agree. but we want 2 tiers of reviews, the unwashed masses (anyone
can sign on and add ratings/reviews) and the cabal (those who supposedly
know perl).

IT> O'Reilly and Manning, due to having ebook editions, would probably love
IT> the site =) After all, who visits Amazon, looking for a book and then
IT> finds Safari?

true. and we should have a link to those ebook pages for each book as
well.

my thought is to have some sort of table called book-links with the book
id, the link type (home page, contents, review, etc.) name (reviewer?)
and the url. that way we can easily add more link types and such without
adding fields. ebooks being a new link type and external reviews being
another.

all the book links will be extracted and binned according to type in the
mason code. so we can have the home page, contents, etc in one section,
and the reviews in another. thoughts?

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: blobs by Iain Truskett

From: Iain Truskett * Uri Guttman (uri@stemsystems.com) [29 Aug 2002 15:14]:
> * Iain Truskett writes:
> > Because, ideally, we have two to three versions.

> > Thumb for the index pages. Medium for the book pages, and perhaps a
> > Large for those who want to see the cover to some degree of detail.

> so why not have 3 links? same thing as one but you store 3 url's in
> the DB (if the book has all 3 sizes).

Because the site may only have one version? Amazon usually has three
different versions (it's where all but about two of the covers on the
current site come from [those two being 'Practical mod_perl', and
'Embedding Perl in HTML with Mason']). Or, the site may have one version
and it's shite. It's usually the author's sites that have the best
versions (and, yes, we could link there), but ideally all our iamges are
around about the same size (aspect ratio notwithstanding).

*Ideally* we have a nice big hires copy that we can scale however we
like. We, obviously, can't just reference one image and use width/height> unless we also store the aspect ratio.

> > We could always cache and Magick them, but then we'd be storing =)

> my whole point. why store when we don't have to.

Flexibility.

> > There's another kettle of fish. Some places don't even like links to
> > images from pages that aren't on their servers.

> well, we can deal with that later. this is a non-profit info site. we
> can ask the major publishers for permission (o'reilly and manning will
> surely let us. i bet most of the others will too).

That's what I suspect. I suspect they would even be friendly to us
having copies of the covers ourselves.

> > Anyone feel like writing to some publishers and asking what they
> > like? I think there's some legal thing that lets you play with the
> > covers (since it's in a review/organisational context rather than
> > trying to sell some competing product). But, IANAL.

(And, not only am I NAL, I'm not an American lawyer.)

> i can do it for those two as i know people there. i don't know the
> other publishers. i think we could just do the linking and let them
> complain first. then we get permission or drop them.

Which sounds a good step. We'd have two for precedent =)

> it is free publicity (unless the book sux) so they probably won't
> mind. out site should help sell books which is what they want.

Even bad books get good reviews. See Amazon =) The trick with this site
is to get the Perl community rating and reviewing, because they
theoretically know better than Joe Dredd who just picked up his Perl/CGI
book and is looking for something more. And good books get bad reviews,
etc.

O'Reilly and Manning, due to having ebook editions, would probably love
the site =) After all, who visits Amazon, looking for a book and then
finds Safari?

cheers,
--
Iain.

Re: blobs by Uri Guttman

From: Uri Guttman >>>>> "IT" == Iain Truskett writes:

IT> * Uri Guttman (uri@stemsystems.com) [29 Aug 2002 14:51]:
IT> [...]
>> why not just link to the image from the book's home page?

IT> Because, ideally, we have two to three versions.

IT> Thumb for the index pages. Medium for the book pages, and perhaps a
IT> Large for those who want to see the cover to some degree of detail.

so why not have 3 links? same thing as one but you store 3 url's in the
DB (if the book has all 3 sizes).

IT> We could always cache and Magick them, but then we'd be storing =)

my whole point. why store when we don't have to.

IT> There's another kettle of fish. Some places don't even like links to
IT> images from pages that aren't on their servers.

well, we can deal with that later. this is a non-profit info site. we
can ask the major publishers for permission (o'reilly and manning will
surely let us. i bet most of the others will too).

IT> Anyone feel like writing to some publishers and asking what they like?
IT> I think there's some legal thing that lets you play with the covers
IT> (since it's in a review/organisational context rather than trying to
IT> sell some competing product). But, IANAL.

i can do it for those two as i know people there. i don't know the other
publishers. i think we could just do the linking and let them complain
first. then we get permission or drop them. it is free publicity (unless
the book sux) so they probably won't mind. out site should help sell
books which is what they want.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: blobs by Iain Truskett

From: Iain Truskett * Uri Guttman (uri@stemsystems.com) [29 Aug 2002 14:51]:

[...]
> why not just link to the image from the book's home page?

Because, ideally, we have two to three versions.

Thumb for the index pages. Medium for the book pages, and perhaps a
Large for those who want to see the cover to some degree of detail.

We could always cache and Magick them, but then we'd be storing =)

[...]
> i don't think we should have copies of anything we don't
> own/copyright. links to them should be just fine. the only content we
> should have is url's, reviews and ratings.

There's another kettle of fish. Some places don't even like links to
images from pages that aren't on their servers.

Anyone feel like writing to some publishers and asking what they like?
I think there's some legal thing that lets you play with the covers
(since it's in a review/organisational context rather than trying to
sell some competing product). But, IANAL.

--
Iain.

Re: blobs by Uri Guttman

From: Uri Guttman >>>>> "IT" == Iain Truskett writes:

IT> * Dave Rolsky (autarch@urth.org) [29 Aug 2002 13:53]:
>> On 28 Aug 2002, Uri Guttman wrote: > no, you must convert it first
>> to a string by using storable (freeze > method) or some other
>> module. then you can insert it into a long > field of type BLOB.

>> This shouldn't be necessary if you are storing raw image data,
>> actually.

IT> That's what I thought, but it didn't appear to be working.

IT> Well, part of the idea is that all that ever changes on the site
IT> is the db. If I'm wanting to write images to disc from my
IT> components (since one of the other ideas is that it's fully
IT> maintainable via the web), I'll need to be able to write to disc.

why not just link to the image from the book's home page? that is what i
did and it works fine. all you need to store is the url and you have to
store several of them to link to the home page, contents, index, sample
chapter, etc. the cover should just be another url like those.

i don't think we should have copies of anything we don't
own/copyright. links to them should be just fine. the only content we
should have is url's, reviews and ratings.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: blobs by Iain Truskett

From: Iain Truskett * Dave Rolsky (autarch@urth.org) [29 Aug 2002 13:53]:
> On 28 Aug 2002, Uri Guttman wrote:
> > no, you must convert it first to a string by using storable (freeze
> > method) or some other module. then you can insert it into a long
> > field of type BLOB.

> This shouldn't be necessary if you are storing raw image data, actually.

That's what I thought, but it didn't appear to be working.

> But I'd strongly recommend just storing filenames in the DB. Why push
> and pull such large chunks of data from the DB? What's the point?

Well, part of the idea is that all that ever changes on the site is the
db. If I'm wanting to write images to disc from my components (since one
of the other ideas is that it's fully maintainable via the web), I'll
need to be able to write to disc.

Which is doable I suppose. It makes things easier in some respects. I'll
confer with Robrt.

In essence: assume that we can't (and don't want to) scp/ftp stuff.

> Better yet, simply generate filenames based on the ISBN or something
> unique like that (id in the db would work too).

Yep. That's the idea.

cheers,
--
Iain.

Re: blobs by Dave Rolsky

From: Dave Rolsky On 28 Aug 2002, Uri Guttman wrote:

> no, you must convert it first to a string by using storable (freeze
> method) or some other module. then you can insert it into a long field
> of type BLOB.

This shouldn't be necessary if you are storing raw image data, actually.

But I'd strongly recommend just storing filenames in the DB. Why push and
pull such large chunks of data from the DB? What's the point?

Better yet, simply generate filenames based on the ISBN or something
unique like that (id in the db would work too).

-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: blobs by Uri Guttman

From: Uri Guttman >>>>> "IT" == Iain Truskett writes:

IT> How does one actually go about inserting and retrieving binary data from
IT> a database?

IT> {
IT> my $sth = $dbh->prepare('insert into covers (isbn,small) values (?,?)');
IT> $sth->execute($isbn, $imagedata);
IT> }

IT> Because that's not working for me.

no, you must convert it first to a string by using storable (freeze
method) or some other module. then you can insert it into a long field
of type BLOB.

when you read it from the DB you do the conversion from text to binary
(thaw method) and assign it to your variable. make this image access a
cgi/url for the IMG tag and it should work fine.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

blobs by Iain Truskett

From: Iain Truskett Ok. I want the covers in the db.

How does one actually go about inserting and retrieving binary data from
a database?

Does one just do a:

{
my $sth = $dbh->prepare('insert into covers (isbn,small) values (?,?)');
$sth->execute($isbn, $imagedata);
}

Because that's not working for me.

[and I've updated the tarball:
Current code: http://ouroboros.anu.edu.au/books/books.tar.bz2
]

cheers,
--
Iain.

Re: perl books project by Iain Truskett

From: Iain Truskett * Drew Taylor (drew@drewtaylor.com) [28 Aug 2002 01:03]:
> I'm new to the project and was trying to create an account via
> http://ouroboros.anu.edu.au/auth/account but I get a "Resource Not
> Found" error. Is this page not done yet?

Not yet, no. Methinks the TODO page needs some work.

> And also, how can I go about getting the current code? Is it in CVS?

It was. CVS server broke. I'll have it in a perl.org one soon. That
said, http://ouroboros.anu.edu.au/books/books.tar.bz2

Some of the files will need to be renamed (x.perl.org prefers Mason
components to have no extension), but generally, yes.

> I'm interested in playing with some Mason code as I've never had the
> opportunity before, so I hope it's well structured. ;-)

AH, well. I can't claim that. I like the layout, but others may
disagree. There's a couple of things I'd like to change now (primarily
the names of the custom modules, and perhaps the table names) but on the
whole, I think it's good.

cheers,
--
Iain.

Re: [Boston.pm] perl books project by Drew Taylor

From: Drew Taylor I'm new to the project and was trying to create an account via
http://ouroboros.anu.edu.au/auth/account but I get a "Resource Not Found"
error. Is this page not done yet? And also, how can I go about getting the
current code? Is it in CVS? I'm interested in playing with some Mason code
as I've never had the opportunity before, so I hope it's well structured. ;-)

Drew
--
Drew Taylor | Web development & consulting
http://www.drewtaylor.com/ | perl/mod_perl/DBI/mysql/postgres
----------------------------------------------------------------------
"If you don't know what your program is supposed to do,
you'd better not start writing it." -Edsger Dijkstra
----------------------------------------------------------------------
Speakeasy.net DSL - http://www.speakeasy.net/refer/29655

Re: [Boston.pm] perl books project by Drew Taylor

From: Drew Taylor Ahh, marvelous. It's working great now. Thanks for the help.

Drew

At 12:12 AM 8/28/02 +1000, Iain Truskett wrote:
>* Drew Taylor (drew@drewtaylor.com) [28 Aug 2002 00:00]:
> > I'm interested in learning more but the URL below either refuses the
> > connection, or I get a "document contains no data" error after a bunch
> > of connections to the server.
>
>Sorry about that. Had a hard drive crash late last week, and the new one
>arrived today so had been setting it up. Chap who has physical presence
>to the machine removed the backup drive (from which we had restored),
>rebooted, and we hadn't set up apache to restart =(
>
>Should be fine now.
>
> > > http://ouroboros.anu.edu.au/books/

--
Drew Taylor | Web development & consulting
http://www.drewtaylor.com/ | perl/mod_perl/DBI/mysql/postgres
----------------------------------------------------------------------
"If you don't know what your program is supposed to do,
you'd better not start writing it." -Edsger Dijkstra
----------------------------------------------------------------------
Speakeasy.net DSL - http://www.speakeasy.net/refer/29655

Re: [Boston.pm] perl books project by Iain Truskett

From: Iain Truskett * Drew Taylor (drew@drewtaylor.com) [28 Aug 2002 00:00]:
> I'm interested in learning more but the URL below either refuses the
> connection, or I get a "document contains no data" error after a bunch
> of connections to the server.

Sorry about that. Had a hard drive crash late last week, and the new one
arrived today so had been setting it up. Chap who has physical presence
to the machine removed the backup drive (from which we had restored),
rebooted, and we hadn't set up apache to restart =(

Should be fine now.

> > http://ouroboros.anu.edu.au/books/

--
cheers,
Iain (who, at the very least, is happy to have a replacement for the old
machine).

Re: [Boston.pm] perl books project by Drew Taylor

From: Drew Taylor I'm interested in learning more but the URL below either refuses the
connection, or I get a "document contains no data" error after a bunch of
connections to the server.

Drew

At 12:47 AM 8/27/02 -0400, Uri Guttman wrote:

>Iain Truskett on his own volition actually created a prototype perl
>books page. you can check it out at
>
> http://ouroboros.anu.edu.au/books/

--
Drew Taylor | Web development & consulting
http://www.drewtaylor.com/ | perl/mod_perl/DBI/mysql/postgres
----------------------------------------------------------------------
"If you don't know what your program is supposed to do,
you'd better not start writing it." -Edsger Dijkstra
----------------------------------------------------------------------
Speakeasy.net DSL - http://www.speakeasy.net/refer/29655

Re: [Boston.pm] perl books project by Chris Devers

From: Chris Devers On Tue, 27 Aug 2002 GregLondon@oaktech.com wrote:

> Uri Guttman wrote:
>
> > Iain Truskett on his own volition actually created a prototype perl
> > books page. you can check it out at
> >
> > http://ouroboros.anu.edu.au/books/
> >
>
> I clicked on the link and got "That document contained no data"
> from Netscape. Am I missing something?

Well you're missing the document, anyway.

I'm also getting a network error on that URL. Server down or something?

% lynx --dump --head http://ouroboros.anu.edu.au/books/

Looking up ouroboros.anu.edu.au
Making HTTP connection to ouroboros.anu.edu.au
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Unexpected network read error; connection aborted.
Can't Access `http://ouroboros.anu.edu.au/books/'
Alert!: Unable to access document.

lynx: Can't access startfile

--
Chris Devers
Have you ever seen Jack Valenti &
John Ashcroft at the same time?

Re: [Boston.pm] perl books project by GregLondon

From: GregLondon Uri Guttman wrote:

> Iain Truskett on his own volition actually created a prototype perl
> books page. you can check it out at
>
> http://ouroboros.anu.edu.au/books/
>

I clicked on the link and got "That document contained no data"
from Netscape. Am I missing something?

Greg

perl books project by Uri Guttman

From: Uri Guttman
Iain Truskett on his own volition actually created a prototype perl
books page. you can check it out at

http://ouroboros.anu.edu.au/books/

you can edit, add or delete entries. don't worry about corruption as
this is a scratch DB.

since we learned (from federico) that there are qt3 perl bindings, the
idea of doing that project should be put aside. so i am proposing that
boston.pm take up the cause of making this perl books page a reality. it
needs testing, more features and much more data. it will eventually
migrate over to books.perl.org.

we hope to have a ratings/review system eventually with maybe two
levels, those from cabal members and those from the unwashed
masses. this will stop the problem of things like wierd ratings numbers
on amazon and imdb.

anyhow, if you are interested then subscribe to the list by sending
email to:

books-workers-subscribe@perl.org

so play with the current site, enter and edit data to get a feel for it
and send in your thoughts. we will need data entry, links, some
mason/html work, maybe some dbi work, etc. iain will lead this so he can
dole out the subprojects. i will stand on the side and cheer and
such. this has been a long time dream of mine and it will come true soon
enough. we have needed a site with quality info about all perl (and
related) books and resources.

thanx,

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: books.perl.org by Iain Truskett

From: Iain Truskett * Uri Guttman (uri@stemsystems.com) [07 Aug 2002 12:53]:
> * Iain Truskett writes:
[ http://ouroboros.anu.edu.au/books/ ]

> this is great. just what we needed. someone to actually do something
> we can then hack up and improve. :)

Speaking of which, anyone here good with MySQL? I'm more a PostgreSQL
man, but the site will be hosted on a MySQL box. I've not got anything
particularly fancy in the SQL, mind you. Just need to convert the 'text'
type (I prefer using text to varchar in most places.) I assume 'blob'
can take any amount of data?

> > Editing, addition and deletion facilities are available at:
> > http://ouroboros.anu.edu.au/books/auth/ (I'm currently fiddling with
> > book addition, so don't try that beyond looking at it)

> i will fool around some with it.

Cool. I've just made some changes to the booke diting. You can create
new authors from the 'edit book' page, and also categories. They're
simple categories, but they should suffice until we get ~400 books, I
imagine. Depends how everything gets classified, really.

> > Feel free to play with them: I have got a backup of the database =)
> > The idea is that the site should be fully editable from a web
> > interface. Login will be using the dev.perl.org system.

> that is good. we will need regular and privileged users. regular ones
> can submit new book info which has to be approved by the cabal to be
> seen in the DB. :)

Yep. Ditto for reviews. As much of a fan of having public reviews as I
am, I still think reviews should be checked for obscenities and libel
before going live.

> > First milestone will be full book, author and publisher management
> > by admin (us, I imagine), including the addition of adding URLs to
> > reviews.

And I'm just overhauling the URL system now. It'll be more in line with
your sysarch one, and be familiar as a relative of the author class on
the current site. (Or perhaps publisher. I'm cogitating about what the
URL stuff needs.)

> > Second milestone will be the ability for users to add their own
> > reviews.

> that sounds good.

> > It's at the second milestone that I'd like to see the site go
> > public.

> i think just with some cleanup and done todos it can go public sooner.

My thought is that if people can do stuff with the site, i.e. add links
to their own reviews, or add their own reviews, then they'll warm to the
site and won't just look once and forget.

Perhaps it's just my vanity, but I'd like the opening to be a good one
=)

[ snip regarding CVS hosting ]
> i can host it on my stemsystems.com box with cvs. ask and robrt have
> cvs support at perl.rog which is just as good and probably better
> admined. :)

I'll ask Ask/Robrt.

> thanx for this work.

Not a prob =)

cheers,
--
Iain 'Spoon' Truskett.

Re: books.perl.org by Uri Guttman

From: Uri Guttman >>>>> "IT" == Iain Truskett writes:

IT> Hello.
IT> I'm a reasonable way through constructing a Perl books site.

IT> http://ouroboros.anu.edu.au/books/

this is great. just what we needed. someone to actually do something we
can then hack up and improve. :)

IT> Editing, addition and deletion facilities are available at:
IT> http://ouroboros.anu.edu.au/books/auth/
IT> (I'm currently fiddling with book addition, so don't try that beyond
IT> looking at it)

i will fool around some with it.

IT> Feel free to play with them: I have got a backup of the database =) The
IT> idea is that the site should be fully editable from a web interface.
IT> Login will be using the dev.perl.org system.

that is good. we will need regular and privileged users. regular ones
can submit new book info which has to be approved by the cabal to be
seen in the DB. :)

IT> First milestone will be full book, author and publisher management
IT> by admin (us, I imagine), including the addition of adding URLs to
IT> reviews.

IT> Second milestone will be the ability for users to add their own reviews.

that sounds good.

IT> It's at the second milestone that I'd like to see the site go public.

i think just with some cleanup and done todos it can go public sooner.

IT> Naturally, more fields and tables will be added to the DB. At present I
IT> just have the basic fields in there. Some fields will be fairly quick to
IT> add (e.g. url).

IT> Comments anyone?

awesome.

IT> Also: If anyone has any bright ideas on where I can host a repository
IT> for the code, it would be appreciated. It's currently in my personal
IT> CVS. Sourceforge? Or is there something better out there?

i can host it on my stemsystems.com box with cvs. ask and robrt have cvs
support at perl.rog which is just as good and probably better
admined. :)

thanx for this work.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

books.perl.org by Iain Truskett

From: Iain Truskett Hello.

I'm a reasonable way through constructing a Perl books site.

http://ouroboros.anu.edu.au/books/

Lists of books, authors, book details, author details, publisher details
etc.

At present the data used was ripped from Amazon, and as such contains
various errors. Also the release date bit needs a bit of work since it
needs to cope with dates that are just years and months rather than down
to the day.

But, generally, the basic structure is there.

Editing, addition and deletion facilities are available at:
http://ouroboros.anu.edu.au/books/auth/
(I'm currently fiddling with book addition, so don't try that beyond
looking at it)

Feel free to play with them: I have got a backup of the database =) The
idea is that the site should be fully editable from a web interface.
Login will be using the dev.perl.org system.

First milestone will be full book, author and publisher management by
admin (us, I imagine), including the addition of adding URLs to reviews.

Second milestone will be the ability for users to add their own reviews.

It's at the second milestone that I'd like to see the site go public.

Naturally, more fields and tables will be added to the DB. At present I
just have the basic fields in there. Some fields will be fairly quick to
add (e.g. url).

Comments anyone?

Also: If anyone has any bright ideas on where I can host a repository
for the code, it would be appreciated. It's currently in my personal
CVS. Sourceforge? Or is there something better out there?

cheers,
--
Iain 'Spoon' Truskett.

Re: Categories by Sean Fritz

From: Sean Fritz

Technical -> utilities (grep, awk, sed)
Technical -> editors (emacs, vi)

DR> and maybe other categories. The only sticky wicket that needs to be
DR> decided is if a book can be in a parent and child at the same time, like:

DR> Technical -> Programming
DR> Technical -> Programming -> Perl

u>hmm, a node only has other nodes or books? u>or could it have both?

u>i would like to keep nodes either filled u>with books or other
u>nodes. sharing a node bothers me somehow.

nntp.perl.org seems to be down atm, so you get the lovley formating of my web based email.. *shrug*

ok, I can see that format working well, I was designing from a frontpage standpoint rather than an organizational(sp?)

my vote is to make it so a book can't be a member of any child nodes.

I think it works ok to have a node contain both books and sub-nodes, because otherwise the perl heirarchy will have to be so amazingly complex in order to hold everything that it would be almost worthless. an example of this in practice

~Sean

Re: Categories by Dave Rolsky

From: Dave Rolsky On Thu, 31 Jan 2002, Uri Guttman wrote:

> DR> Technical -> Programming
> DR> Technical -> Programming -> Perl
>
> hmm, a node only has other nodes or books? or could it have both?

A node can have both child nodes and books.

> i would like to keep nodes either filled with books or other
> nodes. sharing a node bothers me somehow.

It's not practical to enforce that. That means that every time you want
to create a child category, you need to create a child category for
_every_ book in that particular node. But imagine a node where you have
20 books, 8 of which can be grouped into a child node, but the other 12
are all different enough that they fall into groups of 1.

So you end up having to make 13 new nodes, one of which has 12 books and
12 of which have 1 book each, which sucks in terms of browsing.

-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: Categories by Uri Guttman

From: Uri Guttman >>>>> "DR" == Dave Rolsky writes:

DR> This kind of hierarchy lends itself pretty naturally to web browsing
DR> (think Yahoo) and searches.

ok, that works for me. the issue i have always had with hierarchies was
the one slot a book could be in.

DR> One very important thing to note is that a book can be in _more than one
DR> category_!

and that solves that problem!

DR> So for Uri's example of Mastering Regular Expressions, it'd be in:

DR> Technical -> Programming -> Regular Expressions
DR> Technical -> Programming -> Languages -> Perl

and in

Technical -> utilities (grep, awk, sed)
Technical -> editors (emacs, vi)

DR> and maybe other categories. The only sticky wicket that needs to be
DR> decided is if a book can be in a parent and child at the same time, like:

DR> Technical -> Programming
DR> Technical -> Programming -> Perl

hmm, a node only has other nodes or books? or could it have both?

DR> While I can see that there are probably a few books where that
DR> might make sense there are good reasons to outlaw it, mainly in
DR> order to prevent garbage from accumulating as new child categories
DR> are created and books are moved into then.

i would like to keep nodes either filled with books or other
nodes. sharing a node bothers me somehow.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: Categories by Dave Rolsky

From: Dave Rolsky On Thu, 31 Jan 2002, sfritz wrote:

> Base categories
>
> Perl
> (all perl categories) (since we know perl is the main programming intrest..)
> Tech
> (related stuff, basically anything technical thats not directly Perl)
> General
> (LOTR, Foundations Edge, whatever)
>
>
>
> Perl
> Learning
> Using (Intermediate? couldn't decide which was better)
> Guru (some stuff, (MRE) might end up in Using *and* Guru?)

I think you're confusing too many things here, like overall category
(fiction/non tech non fiction/tech) and level
(beginner/intermediate/advanced).

To get back to my original proposal, I think there's some serious
confusion, so I'll try to clarify.

First of all, I'm proposing that the categorization scheme be
hierarchical. In other words, categories get progressively narrower
(think Yahoo).

So our highest level categories might be:

- Fiction
- Non-technical Non-fiction
- Technical

Underneath we then get more speciifc:

- Fiction
-- Romance (love those Harlequin novels)
-- Sci-Fi/Fantasy (or Speculative Fiction)
-- Mystery

- Non-technical Non-fiction
-- Architecture
--- Design
-- Writing
--- Comic books
-- Politics
-- History
-- Linguistics

- Technical
-- Programming
--- Languages
---- Perl
----- DBI
----- Mason
----- Tk
--- Methodologies
---- Extreme Programming

The advantage to this is that when we have only a few books on a topic, we
simply put them in a high level category, like 'Non-fiction -> Politics'.
If that starts to get crowded, we create a few sub-categories like
'Non-fiction -> Politics -> Race' and 'Non-fiction -> Politics -> South
America'. Of course, we can still put things in 'Non-fiction ->
Politics'.

Now, most categories will probably not go beyond 2 or 3 deep for a long
time, except for the Technical category which will probably get fairly
deep quickly.

This kind of hierarchy lends itself pretty naturally to web browsing
(think Yahoo) and searches.

One very important thing to note is that a book can be in _more than one
category_!

So for Uri's example of Mastering Regular Expressions, it'd be in:

Technical -> Programming -> Regular Expressions
Technical -> Programming -> Languages -> Perl

and maybe other categories. The only sticky wicket that needs to be
decided is if a book can be in a parent and child at the same time, like:

Technical -> Programming
Technical -> Programming -> Perl

While I can see that there are probably a few books where that might make
sense there are good reasons to outlaw it, mainly in order to prevent
garbage from accumulating as new child categories are created and books
are moved into then.

-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: DB Layout by Uri Guttman

From: Uri Guttman >>>>> "DR" == Dave Rolsky writes:

DR> On Thu, 31 Jan 2002, Uri Guttman wrote:

>> i don't agree as we want to list reviews separately from other book
>> links. maybe a link_type that says what kind of link: cover, home page,
>> review, etc. then we can grab all the review links and our text review
>> entries and make one listing of reviews.

DR> You're confusing the schema with the UI. In the UI, we will certainly
DR> make a point of grouping 'internal' (in the DB) reviews and external
DR> (links) reviews. And those links will be separate from links to cover
DR> pages, table of contents, sample chapters, etc.

i am not confusing them (i think). i just wasn't sure how we find them
but if there is a link_type field that works for me.

DR> But that doesn't require that the Review table have a link column.

well, as i said above i agree as we can find review links in the links table.

DR> I was thinking we'd offer user's the ability to configure how that's
DR> handled, something like:

DR> Friends' book ratings are given:

DR> - 3x weighting
DR> - 2x weighting
DR> - 1.5x weighting
DR> - 1.1x weighting
DR> - normal weighting

DR> Foes' book ratings are given:

DR> - normal weighting
DR> - 0.9x weighting
DR> - 0.5x weighting
DR> - 0.1x weighting
DR> - the cold shoulder

custom weightings? hmmm...

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: DB Layout by Dave Rolsky

From: Dave Rolsky On Thu, 31 Jan 2002, Uri Guttman wrote:

> DR> Role
> DR> ----------
> DR> role_id
> DR> role -- editor, author, ...
>
> do we need to id roles?

You mean as opposed to simply having a text field in the BookPerson table?
I'd prefer to have the separate Role table for standardization.

> i don't agree as we want to list reviews separately from other book
> links. maybe a link_type that says what kind of link: cover, home page,
> review, etc. then we can grab all the review links and our text review
> entries and make one listing of reviews.

You're confusing the schema with the UI. In the UI, we will certainly
make a point of grouping 'internal' (in the DB) reviews and external
(links) reviews. And those links will be separate from links to cover
pages, table of contents, sample chapters, etc.

But that doesn't require that the Review table have a link column.

> we haven't covered ratings either. a new table with user_id, book_id and
> rating? we can keep the running average in the book table itself to make

There was a UserBookRating table in my original schema.

> it easy to sort by ratings. also we would want a user to be able to
> filter out foe ratings as well as reviews. who would want a dummy's votes to
> matter?

We can do that, though it does end up requiring more selects on the DB
(but that's probably ok).

I was thinking we'd offer user's the ability to configure how that's
handled, something like:

Friends' book ratings are given:

- 3x weighting
- 2x weighting
- 1.5x weighting
- 1.1x weighting
- normal weighting

Foes' book ratings are given:

- normal weighting
- 0.9x weighting
- 0.5x weighting
- 0.1x weighting
- the cold shoulder

-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: DB Layout by Uri Guttman

From: Uri Guttman >>>>> "DR" == Dave Rolsky writes:

>> book_authors
>> ------------
>>
>> book_id
>> author_id

DR> Yep, brain fart on my part. But that table would probably need an
DR> additional column, something like this:

i thought something stunk around here. :)

DR> BookPerson
DR> ----------
DR> book_id
DR> person_id
DR> role_id

DR> Role
DR> ----------
DR> role_id
DR> role -- editor, author, ...

do we need to id roles?

DR> I think distinguishing between reviews and comments needlessly complicated
DR> both the schema and the user interface. How are they distinguished? Who
DR> decides?

well, if they are text in our db then they could be the same.

>> reviews
>> -------
>> book_id
>> user_id (optional)
>> text (optional, internal review)
>> url (external review)
>> url_title (something which labels the reviewer or source)

DR> Gack. Null hell. Reviews which are just links can go in the BookLink
DR> table.

i don't agree as we want to list reviews separately from other book
links. maybe a link_type that says what kind of link: cover, home page,
review, etc. then we can grab all the review links and our text review
entries and make one listing of reviews.

we haven't covered ratings either. a new table with user_id, book_id and
rating? we can keep the running average in the book table itself to make
it easy to sort by ratings. also we would want a user to be able to
filter out foe ratings as well as reviews. who would want a dummy's votes to
matter?

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: DB Layout by Dave Rolsky

From: Dave Rolsky On Thu, 31 Jan 2002, Uri Guttman wrote:

> s> Book
> s> -------
> s> book_id
> s> ISBN
> s> title
> s> edition
> s> copyright_year
> s> page_count
> s> link
>
> link to what?

I was thinking that this'd be the "official" but there's no reason to not
just stick that in the BookLink table.

> s> Author
> s> --------
> s> author_id
> s> name
>
> where is a link from author(s) to books? this is many to many. to
> properly normalize (i think) we need a new table which is
>
> book_authors
> ------------
>
> book_id
> author_id

Yep, brain fart on my part. But that table would probably need an
additional column, something like this:

BookPerson
----------
book_id
person_id
role_id

Role
----------
role_id
role -- editor, author, ...

> s> UserBookComment
> s> --------
> s> user_id - PK
> s> book_id - PK
> s> comment
>
> reviews needs a similar table. reviews could be directly in our DB or
> links to other reviews on the web.

I think distinguishing between reviews and comments needlessly complicated
both the schema and the user interface. How are they distinguished? Who
decides?

> i think that we should have separate tables for comments and
> reviews. and as i mentioned above, reviews could be links.
>
> reviews
> -------
> book_id
> user_id (optional)
> text (optional, internal review)
> url (external review)
> url_title (something which labels the reviewer or source)

Gack. Null hell. Reviews which are just links can go in the BookLink
table.

-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: Categories by Uri Guttman

From: Uri Guttman >>>>> "s" == sfritz writes:

s> how about these?

s> Base categories

s> Perl
s> (all perl categories) (since we know perl is the main programming intrest..)
s> Tech
s> (related stuff, basically anything technical thats not directly Perl)
s> General
s> (LOTR, Foundations Edge, whatever)

hmm, a good start.

s> Perl
s> Learning
s> Using (Intermediate? couldn't decide which was better)
s> Guru (some stuff, (MRE) might end up in Using *and* Guru?)

i still like some other axes. like CS specialy: OO, algorithms,
language, etc. i don't want to go hog wild but i see a need for a couple
of extra axes.

s> Tech
s> Languages
s> Development (couldn't think of better name, for like Mythical Man Month)
s> OS
s> Algorithms (need better name for this category definatly)
s> Other (everything else)

well that covers my first axis above. this needs serious work at some
point but we can live with a short list for now.

s> General
s> Refrence
s> Fiction
s> Non-Fiction

hmm, a little broader maybe. i can't think of more right now.

s> Perl::Learning (would contain most books, also contains subcategory..)
s> CGI

s> Perl::Using
s> CGI
s> DB
s> RegEx
s> Language
s> Porting

what if a book fits multiple categories? are these unique or a checklist
type field?

s> Tech::Languages
s> Python, C, ect ect

s> Tech::Development
s> Need help flushing this category out, can't think of any subs

OO is one.

s> Tech::OS
s> category for each OS that perl is ported to..

and others too.

s> Tech::Algorithms
s> Introduction
s> Refrence

s> Tech::Algorithms::Refrence
s> Graphics
s> Compression
s> Encryption
s> Pseudorandom

i don't think we need that level of detail. but we can always add it
later.

s> Tech::Other
s> open for suggestions

s> General::Refrence

definitely need more than that. ever heard of the dewey decimal system? :)

s> General::Fiction
s> Sci-Fi
s> Fantasy
s> Mystery (can we just drop that category?)
s> Popular (should that be renamed? ^.^)

s> General::Non-Fiction
s> Biographies

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: DB Layout by Uri Guttman

From: Uri Guttman >>>>> "s" == sfritz writes:

s> From Dave
>>>
s> Here's a basic outline:

s> Book
s> -------
s> book_id
s> ISBN
s> title
s> edition
s> copyright_year
s> page_count
s> link

link to what?

s> publisher_id
s> UNIQUE( ISBN )
s> UNIQUE( title, edition )

s> Category
s> --------
s> category_id
s> category
s> parent_category_id -- whee, self-joins!

s> BookCategory
s> --------
s> book_id
s> category_id

s> BookLink
s> --------
s> book_link_id
s> book_id
s> book_link_type_id
s> link

i assume type_id is like home_page, cover_page, index, sample_chapter?

s> BookLinkType
s> --------
s> book_link_type_id
s> type -- cover, external reviews, excerpt, etc

ahh, just what i asked above.

s> Author
s> --------
s> author_id
s> name

where is a link from author(s) to books? this is many to many. to
properly normalize (i think) we need a new table which is

book_authors
------------

book_id
author_id

s> Publisher
s> --------
s> publisher_id
s> name
s> link

s> User -- may not be necessary, see below
s> --------
s> user_id
s> username
s> password

s> UserBookRating
s> --------
s> user_id - PK
s> book_id - PK
s> rating -- 1-10

s> UserBookComment
s> --------
s> user_id - PK
s> book_id - PK
s> comment

reviews needs a similar table. reviews could be directly in our DB or
links to other reviews on the web.

s> UserBookComment could also include reviews, or we could somehow
s> distinguish between comments ("OO Perl rocks") vs. longer reviews.

i think that we should have separate tables for comments and
reviews. and as i mentioned above, reviews could be links.

reviews
-------
book_id
user_id (optional)
text (optional, internal review)
url (external review)
url_title (something which labels the reviewer or source)

the reviews page/section would generate a list of links to both our DB and
external ones. links to ours would be cgi's to fetch the review text.

s> - it'd be nice to be able to tag books you're interested in and come back
s> and see them later.

that would be a personal library! it would have to be under the user's
preferences tables or whatever. maybe this:

library
-------
user_id
book_id

s> - links to online sellers? partner programs? I hate Amazon but maybe we
s> could link to multiple sellers.

oh, definitely multiple sellers. see my other reply on how we would do
that.

good start. i think we need to do a few passes on this and then we could
start a basic DB going and work on insert and search code.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Re: UI by Uri Guttman

From: Uri Guttman >>>>> "s" == sfritz writes:

s> slashboxes:
s> featured book
s> quick links
s> CPAN search
s> Poll
s> most popular books
s> most recent books

>>> no need for that if we have some headlines and short paragraphs, etc.
>>> i am not into busy pages like that.

s> hm, I actually think having a right and left colum is standard anymore?

that stuff makes sense.

s> I had been wondering about the cover pages thing, does anyone know how
s> that works legally?

good question. i linked to the cover page and didn't copy it. that
should be ok IMO. we can ask legal types at o'reilly and other pubs that
we have connections to.

s> Also can we get permission to use the camel in the logo? If not I can
s> think of something else, but the camel is my favorite =p

that is easy. as we will be perl.org and not a business, we can get
permission from o'reilly as long as we acknowledge their camel trademark
on the page.

s> couldn't it be alot simpler and just add a 'ignore reviewer'?

that would be adding that guy to your foe reviewer list.

>>> book price searching? we could become an affiliate(s) with our cut
>>> going to perl.org or YAS. easy way to support the perl community.

s> how does that work?

my old page does price searching and that isn't hard to do. mine is
b0rken somewhat as it does raw regex parsing of each site (it knows the
layouts and how to find the prices/discounts). the drawback is you have
to update the parse code (mine was simple and table driven) if the book
seller page alters its layout. as for affiliates, that is technically
easy. you join a vendor's affiliate program and they will give you a 15%
commission. you create links to their page for that book (by isbn) and
with your affiliate code. if someone clicks through that link and buys
the book, you get the commission. we would have to work with YAS to
figure out how to join for them and make sure they can take the money
and keep it non-profit, etc. we should talk to lenzo about this. i think
he would love it and it shouldn't be a major hassle.

we wouldn't search all book sites as most are not too perlish nor big
nor techie enough. i did amazon, B&N, bookpool, fatbrain IIRC. we could
add a few others.

some publishers now do E-books and we could become affiliates with them
too.

>>> keys to telling if a perl book is good? schwern had a couple of neat
>>> points he always checks for in the index. many perl books fail it.
>>> call this page, how to judge a perl book.
>>>> This sounds like some static content we could simply link of the top
>>>> page. Maybe an 'essays' section where we'd put that. It certainly
>>>> doesn't need to be dynamic since we're unlikely to get a lot of
>>>> submissions of that sort and we can review them on a case by case
>>>> basis.

s> how do we get the right to post the index?

again, i never copied any pages from a book site. i always linked to
them which is fine AFAIK. now, how to make links to other sites look
good is an issue. i used frames which work but some hate. this is a web
UI/design issue.

s> what were these points? (I don't think I saw that thread)

don't remember them. i am sure we could get them and other points from
our readers/reviewers. it would be an interesting page to create.

uri

--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

DB Layout by sfritz

From: sfritz From Dave
>>
Here's a basic outline:

Book
-------
book_id
ISBN
title
edition
copyright_year
page_count
link
publisher_id
UNIQUE( ISBN )
UNIQUE( title, edition )

Category
--------
category_id
category
parent_category_id -- whee, self-joins!

BookCategory
--------
book_id
category_id

BookLink
--------
book_link_id
book_id
book_link_type_id
link

BookLinkType
--------
book_link_type_id
type -- cover, external reviews, excerpt, etc

Author
--------
author_id
name

Publisher
--------
publisher_id
name
link

User -- may not be necessary, see below
--------
user_id
username
password

UserBookRating
--------
user_id - PK
book_id - PK
rating -- 1-10

UserBookComment
--------
user_id - PK
book_id - PK
comment

UserBookComment could also include reviews, or we could somehow
distinguish between comments ("OO Perl rocks") vs. longer reviews.

- it'd be nice to be able to tag books you're interested in and come back
and see them later.

- links to online sellers? partner programs? I hate Amazon but maybe we
could link to multiple sellers.

- use use Perl's friend/foe info to prioritize reviews ("I want to see
what Damian thinks...") or change the weight of rankings ("I want all my
foes rankings to count at 10% of other rankings").
<<

from uri
>>

we have the domain already and ask bjorn hansen will host us with most
of the rest of perl.org so that is covered. we have access to mod_perl,
a DBI database, etc. no issues with power.

<<

UI by sfritz

From: sfritz >- A front page where we can list things like most recent reviews, most
>recently added books, most popular Perl books, most popular computer
>books, most popular general books,

>These might be some sort of sidebar (kind of like the slashboxes on
>Slashdot and use Perl). The center could have a featured book >(something
>the admins would set) and maybe a section for a generic news headline
>where we might put something about a new perl book.

slashboxes:
featured book
quick links
CPAN search
Poll
most popular books
most recent books

>>no need for that if we have some headlines and short paragraphs, etc.
>>i am not into busy pages like that.

hm, I actually think having a right and left colum is standard anymore?

>- search form. Search for books by:

>-- title
>-- author
>-- publisher
>-- ISBN
>-- category
>-- copyright year
>-- checkbox for only books with reviews
>>sort results by ranking, publisher, etc.

check

>
>- a page for a single book. All the book's info (hmm, we need a way to
>have cover images) plus any reviews available.
>ability to rank book 1-10
>>and we would want to be able to rank the rankers. [:)]
>>>Yeah, I was hoping we could use the friend/foe stuff from use Perl
>>>for that. If you like someone's reviews you'll add them to your
>>>friend list. If you think they're a moron you'll remove them. If I
>>>trust you maybe I'll simply add your friend list to mine.

I had been wondering about the cover pages thing, does anyone know how
that works legally?

Also can we get permission to use the camel in the logo? If not I can
think of something else, but the camel is my favorite =p

couldn't it be alot simpler and just add a 'ignore reviewer'?

>- a form for submitting a new book

check

>>bios/credentials of the most well known reviewers?

pr?

>>
>>book price searching? we could become an affiliate(s) with our cut
>>going to perl.org or YAS. easy way to support the perl community.

how does that work?

>>keys to telling if a perl book is good? schwern had a couple of neat
>>points he always checks for in the index. many perl books fail it.
>>call this page, how to judge a perl book.
>>>This sounds like some static content we could simply link of the top
>>>page. Maybe an 'essays' section where we'd put that. It certainly
>>>doesn't need to be dynamic since we're unlikely to get a lot of
>>>submissions of that sort and we can review them on a case by case
>>>basis.

how do we get the right to post the index?

what were these points? (I don't think I saw that thread)

Re: looking to volunteer my services by sfritz

From: sfritz I'm starting new threads, it's becoming difficult to find stuff in this one.

perl.books.workers

manning permission by Uri Guttman

Re: linking permissions by Uri Guttman

Re: blobs by Drew Taylor

Re: blobs by Dave Rolsky

Re: blobs by Uri Guttman

Re: blobs by Iain Truskett

Re: blobs by Uri Guttman

Re: blobs by Iain Truskett

Re: blobs by Uri Guttman

Re: blobs by Iain Truskett

Re: blobs by Dave Rolsky

Re: blobs by Uri Guttman

blobs by Iain Truskett

Re: perl books project by Iain Truskett

Re: [Boston.pm] perl books project by Drew Taylor

Re: [Boston.pm] perl books project by Drew Taylor

Re: [Boston.pm] perl books project by Iain Truskett

Re: [Boston.pm] perl books project by Drew Taylor

Re: [Boston.pm] perl books project by Chris Devers

Re: [Boston.pm] perl books project by GregLondon

perl books project by Uri Guttman

Re: books.perl.org by Iain Truskett

Re: books.perl.org by Uri Guttman

books.perl.org by Iain Truskett

Re: Categories by Sean Fritz

Re: Categories by Dave Rolsky

Re: Categories by Uri Guttman

Re: Categories by Dave Rolsky

Re: DB Layout by Uri Guttman

Re: DB Layout by Dave Rolsky

Re: DB Layout by Uri Guttman

Re: Categories by Sean Fritz

Re: DB Layout by Dave Rolsky

Re: Categories by Uri Guttman

Re: DB Layout by Uri Guttman

Re: UI by Uri Guttman

DB Layout by sfritz

UI by sfritz

Re: looking to volunteer my services by sfritz

Categories by sfritz