If there are parts of the book you find dissatisfying, please feel free to let me know. Another option is to use O'Reilly's feedback page. (I also welcome compliments on what we did right, and the editors probably don't mind that either.)
For what it's worth, I'm impressed with the editorial staff that worked on this book. It's better for having gone through the reviews. (Of course, if it were all up to me, I'd still be tweaking things.)
As someone who's read a few books here and there, I think O'Reilly's editors (especially the Acquisition Editors) fine work. I can name only a few other publishers who are consistent. That could mean I'm less discriminating than you, though.:)
During the quality check (proofreading the almost-photo-ready draft), we discussed this. If there's a second edition, it'll probably be out around the time of Slash 3.0. We had several ideas that didn't make it into the first version. I'd like to see more advanced information (especially about the default plugins) and fuller API documentation.
That said, if you read the first edition carefully, you'll know as much about Slash as just about anybody out there. (Read chapter six very carefully, and you'll know more about the moderation system than some of the core developers.:) That's a pretty good deal for $28-30.
It may surprise you, but I do remember those days, having downloaded (and read!) Slash 0.3. There's a spot in the book that says "People downloaded [the unreadable original version] anyway, and a hardy few used it to build their own sites." (If I recall correctly, Dave Aiello also runs a site built, successfully, on that mess of code.)
I can assure you that the authors of the book had and have no intent to rewrite history or to marginalize the work you or anyone did to get anything before Slash 1.0 to work. (I never figured it out.)
I'm not interested in defending Rob, though. He's a grownup and can and does speak for himself.
There's a footnote pointing to a port of Slash 1.x to Windows NT in the first chapter. Several people have asked about such a thing on the mailing lists. A few have started projects to port things, but, to my knowledge, nothing has come of them.
Most of the pieces should work, but fitting them together nicely would be a lot of busywork. Consequently, the book assumes that Slash is installed on a Unix or Unix-like machine. (It can be administered and edited from a Mac, or BeOS, or any operating system with a 1998-era web browser, though.)
It does, in chapter 8. This not only includes how to do it, but when to do it, why to do it, and all of the other options that make this a last resort. Your opinion on whether or not it's a good thing may disagree, but it's left up to each site owner to decide. (The rest of chapter 8 is all about running the site in such a way that this is rarely necessary.)
You seem to be talking about chapter 8, which is 13 pages long in the manuscript here. That's 5% of the book. Part of that is taken up by managing authors. It's included because the ability to install Apache and a database and whatever program you prefer doesn't automatically give people wisdom and insight into managing an online community. (It's also my favorite chapter.)
As for the installation information, that (in my opinion) is just about the only documentation Slash has, period. It's good stuff. We tried to include more information, especially about places to get help. (I did forget to explain how to add a new virtual user in DBIx::Password, so throw tomatoes at me.)
I do agree that it's aimed at a mostly non-technical audience, but the last third of the book was intended to provide a lot more meat. I'd like to think the description and back cover blurb make the target audience clear, but realize some advanced users will be disappointed. I'm sorry about that.
Chapter 6 discusses the moderation system (including the hirsute algorithms uses to pick moderators and to reconcile metamoderations). Chapter 8 has a section about anti-abuse features, like the blacklist and IP and Netmask IDs. Somewhere else tells how to disable author unlimited moderation.
There are no real case studies in the large, but there are several spots that say "A small site probably wants to do this" and "A large site needs to do that."
While I was working on the book, I fixed several bugs and added a couple of features to Slash. I might have done that anyway, but the financial impetus provided by the book helped. Take that for what it's worth.
I'd personally read a sequel or a revision of Jon Udell's Practical Internet Groupware. I'd love to see a revision of Advanced Perl Programming, and am awaiting Mark-Jason Dominus's Perl Advanced Techniques Handbook.
I'm also toying with a proposal for Testing Perl, though it may be more of a niche market than Software Development with Perl or Extreme Perl. Maybe not.
I respect the FSF opinion on documentation, but I'm not in complete agreement. As an author, I can seriously say that the advance for my book *did* fund some work on Perl itself. (Whether or not anything besides Regexp::English was impressive or useful, you be the judge.:) Parts of the book wouldn't have worked as documentation, and parts of the book wouldn't have been done, period, if it were not a book.
With regard to O'Reilly and Perl, don't forget that ORA still donates to YAS, hosts Perl.com, purchasing and publishing articles and news, and employs or partially funds people involved with Perl -- Nat Torkington, Jon Orwant, Simon Cozens (editing Perl.com). They're also paying royalties to Larry, Tom Christiansen, Tim Bunce, Randal Schwartz, Doug McEachern, Lincoln Stein, Jarkko Hietaniemi, et al.
Finally, I might point out that Perl's fine documentation is both voluminous and very close to the Camel in many spots. Some of the same people who work on Perl books (writing and editing) work on the FAQ and the included POD.
It may not be as direct a donation to Perl development as when Larry was a direct patron, but I think the company is still doing Good things. There will always be free resources for people to use, but I have no problem supporting good publishers like O'Reilly and Manning. If someone can set up a trust to produce free-as-in-speech documentation, I'll support that project too.
O'Reilly is willing to make books available in similar ways (redistributable and modifiable provided you make the copyright and changes clear) -- it's usually the choice of the author. Look at their Running Samba or Open Sources books for examples. (I know there's a link to a page somewhere that describes this in more detail, but I can't find it. You'll just have to trust me for now.:|)
Normal consumers simply aren't going to run C compilers
I don't completely understand how this makes things easier. If people aren't going to run C compilers, are they going to run bytecode compilers? If they are, then my question is answered.
I don't think they are, so it's a distribution problem again. Most people will probably download bytecode to run on the VM. Is that substantially different from downloading binaries? There will still presumably be dependencies, which further complicate things.
Now if the bytecode is *truly* platform independent, there's a big win for people producing software and for people who run any supported platform not in the majority.
I'm not trying to downplay that benefit -- it's nice, but it's only one part of a bigger issue. Feel free to enlighten me if I'm missing something more important.
As the submitter produced the entire story text, it's not fair to blame DiBona for this one.
What's the solution? Should the editors silently correct misspellings and questionable grammar? Should they add "[sic]" after every mistake? Should they reject a submission or rephrase it in their own words?
It's a four page article about a collaborative type of website and a little-known feature of the software that powers this site. It includes working code, discusses practical concerns, and gives some ideas for things I'd personally like to see. Hopefully that's interesting for programmers and webmasters.
The article is indeed designed to promote the book, but I wanted to write something new and unique instead of retreading what's in the book. It does contain a similar example, but the article had more room for a longer plugin.
You're welcome not to buy the book, and I hope there's enough information in the article that a decent programmer could write a new plugin without it. Feel free to send me a dollar if you do, though.:)
(I will, of course, sympathize with the cynics who say that Malda wants to promote the book 'cuz he wrote the foreword. No, he didn't use crayon. It's a nice piece.)
Any framework that stores scores or karma or whatever in a permanent form can be modified by anyone with the appropriate access. (It's more difficult if things are only kept in memory, but it's still possible.) Besides that, you have to trust that a site running on open code uses a known unmodified public version.
There are lots of ways to subvert something that don't involve modifying the code, especially when there's a persistent data store of some sort. You can trust the software as much as you want, but the person who owns the box has the potential to do just about anything.
A book on installing and running a Slash site would have to cover a lot of things - installing Linux, Apache, mod_perl(not to mention a bunch of other perl modules), and MySQL. Hopefully this book will show how to make a scalable site by using NFS and multiple web servers - since Slash is capable of running on such a beast.
Funny you mention that... has a copy of chapter 2 somehow gone backwards in time?:)
There's not a whole lot on multi-machine configurations, but it does come up. If you can get it installed in that situation -- and it's not difficult -- it works almost the same as a single-machine site. I'm really impressed.
That is indeed what I had in mind. If/When this appears, it would be possible to write feature articles (a book review, an investigation of some kind, a fiction story) in the Wiki, with authors correcting things or adding details and links to other information.
It would be interesting to see the revisions of a Story done this way.
Slashdot Mirror
For what it's worth, I'm impressed with the editorial staff that worked on this book. It's better for having gone through the reviews. (Of course, if it were all up to me, I'd still be tweaking things.)
As someone who's read a few books here and there, I think O'Reilly's editors (especially the Acquisition Editors) fine work. I can name only a few other publishers who are consistent. That could mean I'm less discriminating than you, though. :)
That said, if you read the first edition carefully, you'll know as much about Slash as just about anybody out there. (Read chapter six very carefully, and you'll know more about the moderation system than some of the core developers. :) That's a pretty good deal for $28-30.
I can assure you that the authors of the book had and have no intent to rewrite history or to marginalize the work you or anyone did to get anything before Slash 1.0 to work. (I never figured it out.)
I'm not interested in defending Rob, though. He's a grownup and can and does speak for himself.
Most of the pieces should work, but fitting them together nicely would be a lot of busywork. Consequently, the book assumes that Slash is installed on a Unix or Unix-like machine. (It can be administered and edited from a Mac, or BeOS, or any operating system with a 1998-era web browser, though.)
It does, in chapter 8. This not only includes how to do it, but when to do it, why to do it, and all of the other options that make this a last resort. Your opinion on whether or not it's a good thing may disagree, but it's left up to each site owner to decide. (The rest of chapter 8 is all about running the site in such a way that this is rarely necessary.)
As for the installation information, that (in my opinion) is just about the only documentation Slash has, period. It's good stuff. We tried to include more information, especially about places to get help. (I did forget to explain how to add a new virtual user in DBIx::Password, so throw tomatoes at me.)
I do agree that it's aimed at a mostly non-technical audience, but the last third of the book was intended to provide a lot more meat. I'd like to think the description and back cover blurb make the target audience clear, but realize some advanced users will be disappointed. I'm sorry about that.
I wanted an octopus. *shrug*
There are no real case studies in the large, but there are several spots that say "A small site probably wants to do this" and "A large site needs to do that."
While I was working on the book, I fixed several bugs and added a couple of features to Slash. I might have done that anyway, but the financial impetus provided by the book helped. Take that for what it's worth.
Try two thousand.
I'm also toying with a proposal for Testing Perl, though it may be more of a niche market than Software Development with Perl or Extreme Perl. Maybe not.
With regard to O'Reilly and Perl, don't forget that ORA still donates to YAS, hosts Perl.com, purchasing and publishing articles and news, and employs or partially funds people involved with Perl -- Nat Torkington, Jon Orwant, Simon Cozens (editing Perl.com). They're also paying royalties to Larry, Tom Christiansen, Tim Bunce, Randal Schwartz, Doug McEachern, Lincoln Stein, Jarkko Hietaniemi, et al.
Finally, I might point out that Perl's fine documentation is both voluminous and very close to the Camel in many spots. Some of the same people who work on Perl books (writing and editing) work on the FAQ and the included POD.
It may not be as direct a donation to Perl development as when Larry was a direct patron, but I think the company is still doing Good things. There will always be free resources for people to use, but I have no problem supporting good publishers like O'Reilly and Manning. If someone can set up a trust to produce free-as-in-speech documentation, I'll support that project too.
O'Reilly is willing to make books available in similar ways (redistributable and modifiable provided you make the copyright and changes clear) -- it's usually the choice of the author. Look at their Running Samba or Open Sources books for examples. (I know there's a link to a page somewhere that describes this in more detail, but I can't find it. You'll just have to trust me for now. :|)
I don't completely understand how this makes things easier. If people aren't going to run C compilers, are they going to run bytecode compilers? If they are, then my question is answered.
I don't think they are, so it's a distribution problem again. Most people will probably download bytecode to run on the VM. Is that substantially different from downloading binaries? There will still presumably be dependencies, which further complicate things.
Now if the bytecode is *truly* platform independent, there's a big win for people producing software and for people who run any supported platform not in the majority.
I'm not trying to downplay that benefit -- it's nice, but it's only one part of a bigger issue. Feel free to enlighten me if I'm missing something more important.
I'd be more comfortable with the phrase "opportunity cost" than "piracy".
What's the solution? Should the editors silently correct misspellings and questionable grammar? Should they add "[sic]" after every mistake? Should they reject a submission or rephrase it in their own words?
(This discussion probably belongs here, though.)
Aside from being dead, HotBlack Desiato was the life of the party.
Karl Fogel's Open Source Development with CVS covers some of that. It's well worth reading.
The article is indeed designed to promote the book, but I wanted to write something new and unique instead of retreading what's in the book. It does contain a similar example, but the article had more room for a longer plugin.
You're welcome not to buy the book, and I hope there's enough information in the article that a decent programmer could write a new plugin without it. Feel free to send me a dollar if you do, though. :)
(I will, of course, sympathize with the cynics who say that Malda wants to promote the book 'cuz he wrote the foreword. No, he didn't use crayon. It's a nice piece.)
There are lots of ways to subvert something that don't involve modifying the code, especially when there's a persistent data store of some sort. You can trust the software as much as you want, but the person who owns the box has the potential to do just about anything.
Maybe I'm misunderstanding your question.
Funny you mention that... has a copy of chapter 2 somehow gone backwards in time? :)
There's not a whole lot on multi-machine configurations, but it does come up. If you can get it installed in that situation -- and it's not difficult -- it works almost the same as a single-machine site. I'm really impressed.
It would be interesting to see the revisions of a Story done this way.
They're krows, actually. I wanted an octopus.