Re: books reviewing (was Re: PerlRestartHandler)
OK, I do agree in principal (that it's important for the book to be the best that it can be). Although my post was really meant to be reassuring rather than saying that people shouldn't bother pitching in. I think the mod_perl guide is great. Yes, there may be inaccuracies in there (I haven't read it recently from cover to cover to say what those may be), but it's still better than ActiveState, Velocigen, JRun, ServletExec, NSAPI guide or any other commercial web app environment docs I have ever seen. In other words, while I applaud your efforts to be perfect because you care so much about open source -- your message seemed to be a bit stressed (eg going on about having to work together to beat the corporate sharks). The fact is that there will be inaccuracies which are uncovered later no matter how many people read the guide. Because that's just how it is. So while I think the goal to be perfect is great, I think you have already surpassed the intermediate goal of being better than commercial documentation for similar web application environments. With that said -- I do think its important for everyone to pitch in and read the book (and hopefully learn stuff along the way or discover bugs) which is why I am doing it. Because I do agree with pitching in to make it as good as possible. Well, anyway... Thanks, Gunther PS Thanks for posting my belly dancing pic... I needed that. :) At 11:02 AM 3/30/2001 +0800, Stas Bekman wrote: >On Fri, 30 Mar 2001, Gunther Birznieks wrote: > > > At 06:44 PM 3/29/01 +0800, Stas Bekman wrote: > > > > Indeed, I've often wished O'Reilly would provide book sources for > people > > > > that have bought the treebook. Manning has something like that, you > can buy > > > > the ebook cheaper than the actual book, and then if you decide to > buy the > > > > treebook it's that much cheaper. > > > > > >I agree. Meanwhile you can always get the source by helping others to > > >review books :) > > > > > > > /me goes off to read a certain book which he'd promised to review but > > > > hasn't quite finished... > > > > > >make sure to grab the latest version of the sources though, we have done > > >lots of small patches in the last days... > > > > > >I wish others who have promised to help to review the book were actually > > >helping us :( We gotta release it asap, but the book was hardly touched by > > >reviewers... I guess we will just release it as it is... don't be > > >surprised if there will be some glitches in it... what can we do... > > > > You shouldn't worry so much. Considering that the mod_perl guide was an > > open source effort in the first place, I suspect the book will have already > > been quite well reviewed even if you've added a lot. > >I do worry about it. The guide was many time considered as having the >ultimately correct information, and some of the broken stuff has been >revealed years after it was placed there. People were taking things for >granted, instead of getting the information scrutinuzed. > >Definitely the information there had been corrected many times, but it has >too much information for me to feel calm that most of it correct. > > > Our first book 7 years ago has a really stupid Y2K bug (stupid because the > > code says it takes Y2K into account and then goes on to not...) and oh > > yeah, some race condition in some of the file-based locking code...and ... > > we didnt use taint mode... and... files were opened without explicit > and > > < operators...and > > > > In the end though, for the audience of our book, we had gotten much more > > praise than flames. The important thing was that we released something to > > enable people to start coding web apps that were very highly documented > > relative to other free web apps written in Perl. And regardless of the > > quality -- still *at the time*, higher quality than many other free web > > apps. So in the end, I think we would have done a disservice by vetting the > > book more technically and waiting another year than the way we did it -- > > just release it. > >You see, for us, there is no such a thing as "good enough". We are open >source people and compared to commercial bodies who are willing to >releases unfinished products because there are just good enough and better >than their competitors, we don't accept that. We want to code and >documentation be perfect, and we aren't ready to release the final version >of it claiming it to be a final version before it's perfect. > >That's why the mod_perl guide and other online documentation projects are >great. Because it has never been claimed to be perfect, it's going >through the constant change. And one should never consider it to be >ultimately correct. It's in the constant beta version. > >Things are very different with deadtree versions of the documentation. >It's parallel to a product release. Books are considered to be perfect, >and at least expected to be. Personally I hate to find broken or >misleadin
Re: books reviewing (was Re: PerlRestartHandler)
On Fri, 30 Mar 2001, Gunther Birznieks wrote: > At 06:44 PM 3/29/01 +0800, Stas Bekman wrote: > > > Indeed, I've often wished O'Reilly would provide book sources for people > > > that have bought the treebook. Manning has something like that, you can buy > > > the ebook cheaper than the actual book, and then if you decide to buy the > > > treebook it's that much cheaper. > > > >I agree. Meanwhile you can always get the source by helping others to > >review books :) > > > > > /me goes off to read a certain book which he'd promised to review but > > > hasn't quite finished... > > > >make sure to grab the latest version of the sources though, we have done > >lots of small patches in the last days... > > > >I wish others who have promised to help to review the book were actually > >helping us :( We gotta release it asap, but the book was hardly touched by > >reviewers... I guess we will just release it as it is... don't be > >surprised if there will be some glitches in it... what can we do... > > You shouldn't worry so much. Considering that the mod_perl guide was an > open source effort in the first place, I suspect the book will have already > been quite well reviewed even if you've added a lot. I do worry about it. The guide was many time considered as having the ultimately correct information, and some of the broken stuff has been revealed years after it was placed there. People were taking things for granted, instead of getting the information scrutinuzed. Definitely the information there had been corrected many times, but it has too much information for me to feel calm that most of it correct. > Our first book 7 years ago has a really stupid Y2K bug (stupid because the > code says it takes Y2K into account and then goes on to not...) and oh > yeah, some race condition in some of the file-based locking code...and ... > we didnt use taint mode... and... files were opened without explicit > and > < operators...and > > In the end though, for the audience of our book, we had gotten much more > praise than flames. The important thing was that we released something to > enable people to start coding web apps that were very highly documented > relative to other free web apps written in Perl. And regardless of the > quality -- still *at the time*, higher quality than many other free web > apps. So in the end, I think we would have done a disservice by vetting the > book more technically and waiting another year than the way we did it -- > just release it. You see, for us, there is no such a thing as "good enough". We are open source people and compared to commercial bodies who are willing to releases unfinished products because there are just good enough and better than their competitors, we don't accept that. We want to code and documentation be perfect, and we aren't ready to release the final version of it claiming it to be a final version before it's perfect. That's why the mod_perl guide and other online documentation projects are great. Because it has never been claimed to be perfect, it's going through the constant change. And one should never consider it to be ultimately correct. It's in the constant beta version. Things are very different with deadtree versions of the documentation. It's parallel to a product release. Books are considered to be perfect, and at least expected to be. Personally I hate to find broken or misleading information in the books that I read, because I tend to trust that the book has been scrutinized before it has been published. And if I find errors from the very beginning I usually don't continue reading the book at all, since I don't want to be misleaded. (Of course I'm talking about books I try to learn something new from. If I read a book which talks about stuff familiar to me, I usually submit corrections to the author/publisher) If we get to the point where we mistrust the printed information, that will be very bad. And latest rush of the many publishers to print early and often is a very bad trend, since the quality of the books gets very very bad. (This is very different from the open source motto of releasing early and often, since those releases aren't considered stable/perfect). Luckily ORA books are still keeping a high profile. I hope they stay that way. Of course there is an issue of constant evolvement of the sw products which makes the books outdated, even before their get to the book shelves, therefore I believe that the feature is in the e-books, but we aren't there yet for various reasons. Finally, our book went through a major rewrite of the guide, and while you might still not notice a difference from the guide in many place, it's because I've placed those changes back into the guide. So the recent versions of the guide have lots of information which is new and never has been reviewed. That's why we need many eyes, of both experienced and non-experienced programmers and users to make all the bugs in the book shallow. So when the book gets pu
Re: books reviewing (was Re: PerlRestartHandler)
At 06:44 PM 3/29/01 +0800, Stas Bekman wrote: > > Indeed, I've often wished O'Reilly would provide book sources for people > > that have bought the treebook. Manning has something like that, you can buy > > the ebook cheaper than the actual book, and then if you decide to buy the > > treebook it's that much cheaper. > >I agree. Meanwhile you can always get the source by helping others to >review books :) > > > /me goes off to read a certain book which he'd promised to review but > > hasn't quite finished... > >make sure to grab the latest version of the sources though, we have done >lots of small patches in the last days... > >I wish others who have promised to help to review the book were actually >helping us :( We gotta release it asap, but the book was hardly touched by >reviewers... I guess we will just release it as it is... don't be >surprised if there will be some glitches in it... what can we do... You shouldn't worry so much. Considering that the mod_perl guide was an open source effort in the first place, I suspect the book will have already been quite well reviewed even if you've added a lot. Our first book 7 years ago has a really stupid Y2K bug (stupid because the code says it takes Y2K into account and then goes on to not...) and oh yeah, some race condition in some of the file-based locking code...and ... we didnt use taint mode... and... files were opened without explicit > and < operators...and In the end though, for the audience of our book, we had gotten much more praise than flames. The important thing was that we released something to enable people to start coding web apps that were very highly documented relative to other free web apps written in Perl. And regardless of the quality -- still *at the time*, higher quality than many other free web apps. So in the end, I think we would have done a disservice by vetting the book more technically and waiting another year than the way we did it -- just release it. Of course, it didn't help that our publisher cheated and took rough drafts of chapters instead of the final versions we submitted the night before the deadline because they wanted to get a head start on their own editing process (we didn't know) ... But in the end, I think it was still good to have released the book. And in history, there were some technically good points about what we had released compared to what existed at the time. eg I know for a fact that there were several CGI/Perl teaching books that taught people to send mail using the TO field as a command line parameter to mail opened with a PIPE with no real input validation rather than using sendmail -t to pipe all To's and From's plus validation (much safer) Hmm, is this encouraging? I meant it to be I think with so many people having reviewed the base document (even with a lot of stuff added to the book), I bet your book will be much better written than our first book. Well, I have a 30 hour flight coming up soon... perhaps I should download the sources. Then at ApacheCon we can all give you are reviews from our long flights. :)
Re: PerlRestartHandler
At 18:17 29/03/2001 +0100, Matt Sergeant wrote: >On Thu, 29 Mar 2001, Robin Berjon wrote: >> Indeed, I've often wished O'Reilly would provide book sources for people >> that have bought the treebook. Manning has something like that, you can buy >> the ebook cheaper than the actual book, and then if you decide to buy the >> treebook it's that much cheaper. > >http://safari.oreilly.com/ Yes, thanks for the pointer. I had already checked it out but I don't like the subscription system that much. Perhaps I'll try it one month to give them a chance, but a priori I prefer the way that Manning did it. -- robin b. There's too much blood in my caffeine system.
Re: PerlRestartHandler
On Thu, 29 Mar 2001, Robin Berjon wrote: > At 18:20 29/03/2001 +0800, Stas Bekman wrote: > >On Thu, 29 Mar 2001, Robin Berjon wrote: > >> Ah yes, hadn't spotted that one, thanks Stas (once again...). > > > >That's the benefit you get when you review someone's book. You get the > >book's source text :) So I just use grep... after reading the book harcopy > >once it's much more useful to have the source for an easy search and > >copy-n-paste re-use... > > Indeed, I've often wished O'Reilly would provide book sources for people > that have bought the treebook. Manning has something like that, you can buy > the ebook cheaper than the actual book, and then if you decide to buy the > treebook it's that much cheaper. http://safari.oreilly.com/ -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
books reviewing (was Re: PerlRestartHandler)
> Indeed, I've often wished O'Reilly would provide book sources for people > that have bought the treebook. Manning has something like that, you can buy > the ebook cheaper than the actual book, and then if you decide to buy the > treebook it's that much cheaper. I agree. Meanwhile you can always get the source by helping others to review books :) > /me goes off to read a certain book which he'd promised to review but > hasn't quite finished... make sure to grab the latest version of the sources though, we have done lots of small patches in the last days... I wish others who have promised to help to review the book were actually helping us :( We gotta release it asap, but the book was hardly touched by reviewers... I guess we will just release it as it is... don't be surprised if there will be some glitches in it... what can we do... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: PerlRestartHandler
Robin Berjon wrote: > Yes, I stole the content from the as yet unpublished Tk and mod_perl books > that I got to review and I'm writing "Applications mod_perl-Tk: le probleme > du monadisme heuristique chez Leibniz, Quine, et Bekman" for the Sorbonne > University Press. Ouch! Just reading the titles makes my head hurt! LOL! (I'm french canadian) Hmm, Tk from mod_perl, that would be weird. :-) -- Pierre Phaneuf Systems Exorcist
Re: PerlRestartHandler
At 18:20 29/03/2001 +0800, Stas Bekman wrote: >On Thu, 29 Mar 2001, Robin Berjon wrote: >> Ah yes, hadn't spotted that one, thanks Stas (once again...). > >That's the benefit you get when you review someone's book. You get the >book's source text :) So I just use grep... after reading the book harcopy >once it's much more useful to have the source for an easy search and >copy-n-paste re-use... Indeed, I've often wished O'Reilly would provide book sources for people that have bought the treebook. Manning has something like that, you can buy the ebook cheaper than the actual book, and then if you decide to buy the treebook it's that much cheaper. /me goes off to read a certain book which he'd promised to review but hasn't quite finished... >> I thought about it as a kind of CleanupHandler that doesn't affect the >> time it takes for a child to be available for service again (for non >> per-request cleanups obviously) but I couldn't think of what could >> usefully be done there. > >Are you writing yet another mod_perl book or something? Yes, I stole the content from the as yet unpublished Tk and mod_perl books that I got to review and I'm writing "Applications mod_perl-Tk: le probleme du monadisme heuristique chez Leibniz, Quine, et Bekman" for the Sorbonne University Press. No, in truth I am simply revamping the mod_perl framework we use here to make it more consistent and logical. I'm trying to put some pieces into the right phases to avoid some dirty hacks I have to do now. Has anyone actually written a PerlRestartHandler ? -- robin b. Critic, n.: A person who boasts himself hard to please because nobody tries to please him.
Re: PerlRestartHandler
On Thu, 29 Mar 2001, Robin Berjon wrote: > At 17:57 29/03/2001 +0800, Stas Bekman wrote: > >On Thu, 29 Mar 2001, Robin Berjon wrote: > >> just out of curiosity, has anyone used PerlRestartHandler ? To what use ? I > >> don't know what I'd use it for, so I'm wondering whether I'm missing out on > >> something really cool :) > > > >The eagle book says: > > > >PerlRestartHandler points to a routine that is called when the server > >is restarted. This gives you the chance to step in and perform any cleanup > >required to tweak the Perl interpreter. For example, you could use this > >opportunity to trim the global @INC path or collect statistics about the > >modules that have been loaded. > > Ah yes, hadn't spotted that one, thanks Stas (once again...). That's the benefit you get when you review someone's book. You get the book's source text :) So I just use grep... after reading the book harcopy once it's much more useful to have the source for an easy search and copy-n-paste re-use... > I thought about it as a kind of CleanupHandler that doesn't affect the > time it takes for a child to be available for service again (for non > per-request cleanups obviously) but I couldn't think of what could > usefully be done there. Are you writing yet another mod_perl book or something? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: PerlRestartHandler
At 17:57 29/03/2001 +0800, Stas Bekman wrote: >On Thu, 29 Mar 2001, Robin Berjon wrote: >> just out of curiosity, has anyone used PerlRestartHandler ? To what use ? I >> don't know what I'd use it for, so I'm wondering whether I'm missing out on >> something really cool :) > >The eagle book says: > >PerlRestartHandler points to a routine that is called when the server >is restarted. This gives you the chance to step in and perform any cleanup >required to tweak the Perl interpreter. For example, you could use this >opportunity to trim the global @INC path or collect statistics about the >modules that have been loaded. Ah yes, hadn't spotted that one, thanks Stas (once again...). I thought about it as a kind of CleanupHandler that doesn't affect the time it takes for a child to be available for service again (for non per-request cleanups obviously) but I couldn't think of what could usefully be done there. -- robin b. The more you run over a dog, the flatter it gets.
Re: PerlRestartHandler
On Thu, 29 Mar 2001, Robin Berjon wrote: > Hi, > > just out of curiosity, has anyone used PerlRestartHandler ? To what use ? I > don't know what I'd use it for, so I'm wondering whether I'm missing out on > something really cool :) The eagle book says: PerlRestartHandler points to a routine that is called when the server is restarted. This gives you the chance to step in and perform any cleanup required to tweak the Perl interpreter. For example, you could use this opportunity to trim the global @INC path or collect statistics about the modules that have been loaded. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
PerlRestartHandler
Hi, just out of curiosity, has anyone used PerlRestartHandler ? To what use ? I don't know what I'd use it for, so I'm wondering whether I'm missing out on something really cool :) -- robin b. The more you run over a dog, the flatter it gets.
Re: PerlRestartHandler Still Experimental ?
On Mon, 25 Oct 1999, Joshua Chamas wrote: > Hey Doug, > > Any reason why PerlRestartHandler is still experimental ? because nobody (that I knew of) had tested it besides myself :) > I gave it a spin at your advice by compiling with > PERL_RESTART_HANDLER=1 and it works great. It would be > nice if the handler moved into EVERYTHING=1 at some point. sounds great, will do for 1.22
PerlRestartHandler Still Experimental ?
Hey Doug, Any reason why PerlRestartHandler is still experimental ? I gave it a spin at your advice by compiling with PERL_RESTART_HANDLER=1 and it works great. It would be nice if the handler moved into EVERYTHING=1 at some point. PerlRestartHandler is useful with Apache::ASP, as it allows a parent httpd to recompile changed ASP scripts, if Apache::ASP->Loader() is run in the PerlRestartHandler. The parent recompiles changed scripts with a graceful restart, minimizing the downtime of one's site. This is much better than having to a full stop / start of apache, which will kill currently active connections. Precompiling scripts in the parent httpd shares these precompilations with the forked child httpds, so that RAM is saved and CPU spared, instead of compiling the scripts in each child httpd separately. A similar strategy may be used with precompiling cgi scripts run with Apache::Registry and precompiled by Apache::RegistryLoader. -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NODEWORKS >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
