autarch writes "So I was thinking that it'd be a neat thing to have a place where the Perl community could go to recommend programming/computer/design/tech-related books. It could be real simple. People would submit titles and then others could comment on them or rate them from 1-10.
I was inspired by the fact that people often mention books in their journals that sounded interesting but I'd forget to note this down and then come back a month later trying to remember whose journal it was.
So would people like this? And if so, where should it go? Maybe here, on use perl? Or maybe a new site, books.perl.org or something?
Thoughts?"
It sounds like it would be a natural for use Perl; though I am not sure if there is currently code in Slash to support it (unless you think regular comments pages and polls would suffice), we could certainly put a simple Slash plugin together for it.
Re:books.perl.org
autarch on 2002-01-07T17:14:15
Ah, yes,
I do recall that.
I'm kind of split between wanting it here on use perl, which is sort of an existing community hub, or on books.perl.org, because it deserves its own site. For various reasons which may become apparent later, I'm leaning towards the latter at the moment.
-daveRe:books.perl.org
pudge on 2002-01-07T17:26:04
The good thing about doing it on use Perl is you already have the usersin the database with access etc. It's up to whoever wants to do it; if you want to do it on use.perl.org, I can help you do it. books.perl.org could redirect to use.perl.org etc. too. But if you have other plans, go for it.Re:books.perl.org
autarch on 2002-01-07T17:37:21
Yep, I thought of that too. It'd be one less login for people to deal with, which is nice. OTOH, it might be a conflict if we wanted to give me admin access to the books stuff, but not the rest of use Perl (I don't know how fine-grained the access controls are).Re:books.perl.org
pudge on 2002-01-07T17:52:12
I'd have no problem giving you admin access.Re:books.perl.org
autarch on 2002-01-07T18:01:28
Well _I_, of course, am a paragon of trustworthiness! But there are some shady characters like that Uri Guttman fellow who might be considered for admin duties related to book things as well. But you have to keep that guy on a _very_ tight leash!
(I'm joking, for those who aren't sure)
More seriously, I was thinking generally about whether we'd want to require a 100% overlap between having admin powers for book stuff and admin powers for use Perl in general. I, being a paranoid sort, tend to favor isolating systems.
For example, jobs.perl.org is only admin-able by a few designated people (me, Ask and Uri, for the curious) and that seems like a good default access level.Re:books.perl.org
pudge on 2002-01-07T19:42:14
There is some support in Slash for ACLs, but I've never used it. If necessary, it could be used, and if it needs some work, I could make it work. So no worries.:) Re:books.perl.org
uri on 2002-01-09T05:11:07
i resemble that remark. this thread made me actually get an account here. such work you are causing me!
anyhow, i got books.perl.org to do this kind of thing. first a comprehensive listing of all perl books (see my very old books page at: sysarch.com) with all the public info on the books. this sort of DB and layout is not something i think slashcode could do. then there is the reviews and ratings. do we want all entries to carry equal weight? then you get imdb wacko ratings. or do we give more weight those with known credentials and let all comment on the books? how do we store/sort the reviews/ratings?
there is also a very quiet companion email list for this which might be a better forum than use.perl. books-workers@perl.org and subscribe by sending mail to books-workers-subscribe@perl.org
i am interested in this project but can't put much time into it now. but i will be on that list if anyone wants to talk about the ideas and such. and i will give the books.perl.org domain to this project whereever it lands.Re:books.perl.org
pudge on 2002-01-09T05:27:29
this sort of DB and layout is not something i think slashcode could do.Yes, but that is a reflection of your limited knowledge, not of Slash.
:-) Slash is completely flexible in such matters. there is also a very quiet companion email list for this which might be a better forum than use.perl
Why?
Re:books.perl.org
uri on 2002-01-09T19:37:15
there are two main aspects to the books page, a basic db of all the books and a review/rating system. maybe i don't know slashcode but i don't think of it as a search front end.
as for why a mailing list is better that a web forum, i just can't answer that. it just is.:) you obviously have a biased view towards use.perl. :)
we already have a few interested people subscribed to that list so if autarch and anyone else wants to get involved, i suggest they subscribe there. the list will be ongoing even after this gets off the ground much as the perl jobs discuss list is active even with the jobs page/db/list working well. i don't think a web forum is as effective for a development/managing type of list. for a reviews/ratings user setup, slash looks great. how it gets integrated into a books db is another story.Re:books.perl.org
pudge on 2002-01-09T19:57:37
maybe i don't know slashcode but i don't think of it as a search front end.Slash is a general web application server. It can be anything you want it to be. pudge.net has a photo gallery and football picking. It is quite simple to add a search interface like that to Slash, you just write a simple plugin. Slash is actually very good at that kind of thing.
as for why a mailing list is better that a web forum, i just can't answer that. it just is.
:) you obviously have a biased view towards use.perl. :) A dead mailing list vs. a thriving discussion. QED.
for a reviews/ratings user setup, slash looks great. how it gets integrated into a books db is another story.
Please stop saying such things when you really don't know anything about Slash at all.
Re:books.perl.org
johnseq on 2002-01-07T17:17:23
What about using something PODish for inline book reviews in the online journals?
=bookreview Core Perl
This book ruined my recent Jamaican vacation. I couldn't but it down... yada yada
=cut
You could always parse and export to books.perl.org if/when put into production.
Spearhead the semantic web with simplistic inline comments. WOOHOO!Re:books.perl.org
johnseq on 2002-01-07T17:18:18
(cursed submit button)
What about using something PODish for inline book reviews in the online journals?
=bookreview Core Perl This book ruined my recent Jamaican vacation. I couldn't but it down... yada yada
=cut
You could always parse and export to books.perl.org if/when put into production. Spearhead the semantic web with simplistic inline comments. WOOHOO!Re:books.perl.org
autarch on 2002-01-07T17:38:58
Well, it would require a fairly complex bit of POD (title, edition, author(s), publisher, categories, rating, etc).
And people'd screw it up (or forget about it) on a regular basis. With a nice simple set of web forms it'd be easy to add info.Re:books.perl.org
johnseq on 2002-01-08T13:40:24
I'm not talking about creating the whole application with one tag. Just the text of the review.
There's something terrific about not having to interrupt your blog train of thought, log in to a separate application, look up all those attributes you mentioned, then type in your book review. Instead, use a tag to mark off your review, and either Slash outputs the necessary RSS-like file for bot consumption, or a web harvester comes along, parses your blog and dumps the text into some web-accessible ratings Db. This is the semantic web.
If the bookreview tag only had a title (ISBN optional), I'm guessing you could intuit the rest of the items you mentioned, except for ratings. Ratings would be entered on the web site that harvested reviews from blogs, as well as directly inputted in the traditional CGI fashion you describe.
With the straight CGI system you describe there's no technical risk, just the (large?) risk that people won't bother to enter the data they're already entering in their blogs.
How about doing a Google search on 'perl book reviews'?
Note to Pudge: I like the poll idea, though. Example:
Question for Pudge: What if people just sent you reviews via a story submission? I don't care as much about an N year old review about an N+M year old book. If there was a use Perl story (aka, review) of a book where N+M < 1 (or possibly N+M < 0, as in the case of Running Weblogs with Slash), that is something I'm very likely to read and possibly comment on. Your thoughts?
Re:Re-inventing the Perl book review wheel
autarch on 2002-01-07T18:37:29
I know you can find reviews out there. But these are generally all a single person's reviews.
My idea was that it'd be nice to:
A) Be able to see what others in the Perl community are reading (and not just Perl books, but other programming/tech books, design books, whatever).
B) Be able to see how much people liked certain books. Book X has a rating of 7.8 out of 10, with 200 votes is useful info, though I'd still like to hear that some particular person I trust liked it (but that would be there too, in the form of individual comments/reviews).
Polls don't really lend themselves to _lots_ of books, plus they're very top down (admins decide what books to poll for) as opposed to bottom up (anyone gets an account and enters info on some books they just read).Re:Re-inventing the Perl book review wheel
ziggy on 2002-01-07T18:56:14
I thought that books.perl.org would be the logical place for a community book review site. With this added request / requirement / feature, I'm not so sure.I'd still like to hear that some particular person I trust liked itSince slash now offers the friend/foe feature, a slash plugin on use.perl seems more reasonable. How difficult would it be to note that 200 people liked a particular book, including 8 of my friends? Conversely, showing that 8 of my friends liked a book while 12 disliked it would be similarly useful.
I don't see the value in reimplementing the logon/friend+foe system into books.perl.org (even if it were simply a slash site), since the whole point about use.perl is to build a coherent sense of community. books.perl.org might be useful insofar as it would point to a specific area on use.perl...
Just my €0.02.
:-) Re:Re-inventing the Perl book review wheel
pudge on 2002-01-07T19:46:29
None of that would be difficult. It would just take some work, but less work than starting from scratch.Re:Re-inventing the Perl book review wheel
autarch on 2002-01-07T22:06:05
Yep, I agree that re-inventing those wheels would be silly.
I'm still not sure that the whole use Perl structure is ideal for a books site though. The general feel here is 'blog' style, both the front page, the boxes, and the journals.
OTOH, a books site is more of a searchable database type of feel where you'd like to be able to browse by category, search by author and title, browse by reviewer, etc.
So I just had a thought. How about if we shared the use Perl database for user info and let people login via use Perl but constructed basically a new look and feel for the books piece of the site?
This seems like the best of both worlds, perhaps.
People would be able to go to either use.perl.org or books.perl.org and log in, but the login would be good for either site. Then if on use Perl there'd be a nice prominent link to the "Perl community book site". You'd click on that and be on what looks like a basically different site (different layout, different navigation paradigm).
Or you'd login at books.perl.org and could go to use.perl.org with the same layout.
If we wanted a 'book review' slashbox, that's certainly easy enough to do via RSS. And books.perl.org could host RSS feeds from elsewhere (jobs, use Perl, CPAN, etc).
I think it'd be technically feasible. Basically, whatever machine books.perl.org was on (maybe even on the use.perl.org machine itself) would have access to the use.perl.org DB for user info. Not too big a hurdle, I wouldn't imagine.Re:Re-inventing the Perl book review wheel
chromatic on 2002-01-07T23:51:49
Heh, and I'm avoiding finishing an article on how and why to write Slash plugins. Suffice it to say that it's *easy* to use the existing Slash framework to create something with an entirely different feel. If books.perl.org is more appropriate, that's fine, but there aren't any technical reasons against having it on here (and a few good reasons *for* doing that).At the risk of shameless self-promotion, watch for the article on the O'Reilly Network in a couple of days.
:) Re:Re-inventing the Perl book review wheel
autarch on 2002-01-08T00:27:22
Ok, I will wait for this article before going ahead with any coding. If we can have a 'site within a site' type of thing on use Perl that has its own feel then that works too.
books.perl.org can always redirect to use.perl.org/books, right?
Anyway, I really don't know enough about Slash yet so I'm mostly just guessing. Hopefully your article will help me in that area.Re:Re-inventing the Perl book review wheel
pudge on 2002-01-08T04:42:55
use Perl is in a place where you cannot have direct DB access. Sorry, it just isn't possible. Specifically, it is on the OSDN servers, right next to Slashdot, and we can't allow that kind of access into our network. If this kind of thing were to happen, it would have to be non-realtime. Also, unless it is a part of use.perl.org, it can't be on the server.
Unless, of course, we move use Perl to another server.
And yeah, use Perl has a *cough* blog (I hate that word) feel, but not every piece of it has to have the same feel.
Re:Re-inventing the Perl book review wheel
ask on 2002-01-08T16:55:25
bugs6.perl.org works like that. (Runs on a separate box in a different location but uses the dev.perl.org authentication thing). It can even transfer sessions.- ask
Re:Re-inventing the Perl book review wheel
pudge on 2002-01-08T19:04:41
But it cannot be real time, not sharing with use.perl.org, unless it is on the same network, and unless it is part of use.perl.org, it can't be on the same network. The machines belong to the company, and I can't do anything about it.
Unless use.perl.org moves elsewhere, of course.Re:Re-inventing the Perl book review wheel
ask on 2002-01-08T21:20:33
we do it with simple http requests ("check this user/password" requsts and the swerver replies with "(OK+userinfo|DENIED)"). No fancy access needed.Re:Re-inventing the Perl book review wheel
autarch on 2002-01-08T21:35:40
I thought of that too.
I still can't decide how best to pursue it.
Here's my thoughts so far:
Pros for use Perl plugin:
- one login is easy to do.
- infrastructure already exists (servers and such)
- one-stop "shopping" for users, just go to use Perl for all your Perl community needs.
Cons:
- I don't know squat about Slash. I can learn but the idea of learning someone else's DB wrapper, templating system, etc is kind of a drag (and also a time issue for me). This means it'll probably take longer for me to put together.
- It might be better for the books site in the long run to have a separate identity.
- If its not Mason I can't use it as the sample site for the Mason book (my previously mentioned hidden motive) but there are other possibilities for that.
Anyway, back to login, I think it'd be _very_ cool to have some sort Passport-like system for the *.perl.org domains, with a login on any system being transferable to any other (well, except jobs since only employers login there right now). This seems like it could be done with cookies and a centralized auth server.
All login forms would post to auth.perl.org, which gives a cookie set for ".perl.org". All *.perl.org sites would see the cookie, and would be able to use HTTP/SOAP/whatever to say to auth.perl.org, "Is this a valid token? What access levels does this person have for my site?"Re:Re-inventing the Perl book review wheel
perldoc on 2002-01-07T19:53:02
Strangely enough, Amazon already does these things for you...
A) Be able to see what others in the Perl community are reading (and not just Perl books, but other programming/tech books, design books, whatever).
..."Customers who bought this book also bought:". If that's not enough, follow the link that says "Explore similar items". If that's not enough, click on "More Results". Read the reviews of each title you are interested in along the way. Read the "Customers who bought this book also bought" lists, ad infinitum. B) Be able to see how much people liked certain books. Book X has a rating of 7.8 out of 10, with 200 votes is useful info,
..."Average Customer Review: ***** Based on 55 reviews". though I'd still like to hear that some particular person I trust liked it (but that would be there too, in the form of individual comments/reviews).
...Amazon even provides you with the means to manage your list of trusted reviewers, called the Favorite People List. So then, the only issue is getting people you trust to post reviews, either on Amazon or elsewhere. If there is someone you trust, why not just email them directly and ask them what they think of a particular book? If you'd like to browse reviews, why not use Amazon? It seems to me to be a large pool of potential "people you [can] trust".
Re:Re-inventing the Perl book review wheel
autarch on 2002-01-07T21:58:49
Gee, much as I love Amazon...
Wait, I really dislike Amazon, both for their patent strategy and even more so for their union-busting.
Yes, I know Amazon does this. But I want a community site for this. A site run by a commercial interest for commercial purposes (i.e. to make Amazon, Inc. more money) is not appropriate.
That's probably one of the reasons we have dbi@perl.org instead of dbi@yahoogroups.com, for example. Or why Ask and I bothered creating jobs.perl.org instead of telling everybody to go check Dice or Monster.
I doubt you'll be able to get everybody in the Perl community to rally behind Amazon. I'm quite sure, however, that we can get sufficient enthusiasm for adding this to use Perl or for making books.perl.org
-daveRe:Re-inventing the Perl book review wheel
perldoc on 2002-01-07T23:46:50
Well, well, well. We sure have an axe to grind, don't we.
All I did was give you a cost-free solution to your problem, which met or exceeded your stated requirements. Only now did you choose to reveal your hidden agenda. Far be it from me to suggest that you soil yourself with free help from Amazon.
I'm sure you'll keep track of all the hours you'll spend developing this, and factor that into the total cost of your book purchas(es).
Best of luck with your little pet project!
Amazon
autarch on 2002-01-08T00:32:43
My agenda was never hidden. I wanted to make a nice resource for the Perl community, that was of and for that community. As Ziggy pointed out, Amazon is out for Amazon, not for us. They do these things inasmuch as they think it'll promote sales, not inasmuch as it will help build the Perl community.
Besides the fact that it probably doesn't have all the features that I think would be useful, there's the other fact that people in the community (and not just me, either) would not want to participate simply because they don't want to be involved with Amazon (for one reason or another). That would be a problem for a community-building project, don't you think?
Maybe I didn't state that community-supported and -supporting were part of the goal, but I kind of thought it was implied.Re:Re-inventing the Perl book review wheel
ziggy on 2002-01-08T00:44:29
Now, now. Let's be fair here.You and Dave are looking at the "criteria" for evaluating "requirements" for books.perl.org with a host of unstated goals in mind.
Just because Amazon provides a zero-cost solution does not make it optimal.
Just because *.perl.org requires sweat equity to work does not make it "more costly". (Especially if Dave is looking for his next Mason/Slash project.
;-) Re:Re-inventing the Perl book review wheel
jdavidb on 2002-01-08T18:08:28
The real problem with Amazon is that we have a higher concentration of Perl awareness here. I mean, way too many people out there are still programming Perl like it's perl4 because they've read the wrong books and never gotten in touch with the community. We don't want those reviews, at least not as much. The fact that a new guy read a book that never mentioned C<strict> or C<use> and thinks it is wonderful doesn't really provide us with a lot of useful information.
Re:Re-inventing the Perl book review wheel
ziggy on 2002-01-07T23:53:42
Perhaps, but I've got to agree with autarch, mjd and numerous other Perl people on this one: Amazon isn't where this belongs.Strangely enough, Amazon already does these things for you...
Amazon even provides you with the means to manage your list of trusted reviewers, called the Favorite People List.Amazon can't be reasonably expected to create anything other than a community of book/stuff buyers. That's their goal, not ours, and they're certainly within their rights to try and create the best buyer's community they can. But this isn't about a buyer community, this is about our community. It's more important for us to know that 4 out of 5 DBI users recommend the DBI book, something that's much more useful to us than "95% of all buyers bought the DBI book also bought the Camel" (which is effectively a non-statement).
Another thing that Amazon can't track is recommendations from people who aren't buying books at there. For example, if 3 Perl trainers have good things to say about Damian's OOPerl, that has much more weight for me than three random reviewers or book buyers at Amazon.
Re:Re-inventing the Perl book review wheel
davorg on 2002-01-08T07:41:13
I've covered this in journals passim. The problem with the Amazon review and rating system is that people who don't know what they're talking about, use it.
Now I really don't want to come across as an intellectual snob, but I'd far rather read the reviews and ratings of the people who's opinions I respect.
For example, currently Programming Perl has 45 reviews and an average rating of 4.5 stars, but CGI Programming 101 has 43 reviews and also 4.5 stars. Even Matt Wright's book manages and average rating of 3.5 across its 46 reviews.
How is anyone supposed to work out that two of those three books really aren't worth buying and the third is an essential part of every Perl programmers library?
Re:Re-inventing the Perl book review wheel
Mischief on 2002-01-11T16:06:12
I agree! I don't know where I'd be without Matt Wright's CGI/Perl Cookbook. It even taught me how to develop custom subroutine libraries for my CGI programs, and comes absolutely packed with ready-to-use CGI programs to add interactivity to my web site!Re:Re-inventing the Perl book review wheel
pudge on 2002-01-07T19:45:26
Yes, we can do book reviews. It's best to contact me before submitting one, to make sure we're on the same page, though (don't go through all the work for nothing).
The Art of Computer Programming (Knuth), The Dragon Book aka
Compilers: Principles, Techniques and Tools (Aho, Sethi, Ullman), K&R,
Computer Graphics (Foley et al), Code Complete (Steve McConnell), the
Devil Book aka Design and Implementation of the 4.4BSD Operating
System (McKusick, Bostic, Karels, Quarterman), Practice of Programming
(Kernighan and Pike), Commentary on the Unix 6th edition, with source
code (John Lions), An Introduction to Algorithms (Cormen, Rivest and
Leiserson), Programming Pearls (Bentley), the networking books by
Stevens (TCP/IP Illustrated etc.), Essentials of User Interface Design
(Cooper), Applied Cryptography (Schneier), Design Patterns (Gamma et
al), An Introduction to Database Systems (Date), Extreme Programming
Explained (Beck), Refactoring (Fowler), Fundamentals of Database
Systems and Introduction to SQL (van der Lans), The Psychology of
Everyday Things (Norman), Inner Loops: A Sourcebook for Fast 32-bit
Software Development (Booth), Handbook of Logic in Computer Science
(Abramsky, Gabbay, Maibaum), The visual display of quantitative
information (Tufte), Software Tools (Kernigham, Plauger), The Mythical
Man-Month (Brooks), Software Engineering Economics (Boehm), Structured
Analysis & Design (DeMarco), Maximum Security (Greg Shipleu), Reasoned
Programming (Broda, Eisenbach et al), Practical File System Design
with the Be File System (Giampaolo), Operating System Design
(Tannenbaum), Computers under Attack (Denning), Bebop to the Boolean
Boogie (Maxfield), Analysis Patterns (Fowler), Peoplware (DeMarco).
That's a lot of books. Reviews needed
HTH, Leon
The trainers list recently chewed a guy a new ass for having a site at perltraining.com as it might be reinventing the wheel of what is dead on mouldering on perl.org. I encouraged this person to continue on anyway.
If someone wants to do book reviews, LET THEM . Besides, it's usually the people bitching who we can count on not to help in any way.
