c_monster writes "My new book Perl for the Web has been published and should be in stores shortly. The full text is also available on my web site. It's all about using Perl to create Web applications with 100% less slowness. There's even a gratuitous mention of Slashcode. Read it. Cherish it. Let me know what you think."
I just skimmed through the book online this morning; first impressions.
There's a lot of good, generic advice here on how to architect websites. The author does a reasonable job of enumerating the available options and various tradeoffs that must be made.
It's pretty light on code samples and tends to refer to Velocigen products more than anything else. This is okay, but I found out later from a friend that Chris Radcliff is also Chief Evangelist for Velocigen. This fact is not made clear on his website; I hope it is clear on the book jacket.
Suddenly I have to evaluate this book in a whole new light. I find myself trying to see if the less-technical sections are just recast marketing material. Which is regrettable because in general it's a pretty decent book. I think it's fine to use Velocigen examples, it should just be clear that the author works for the company.
This book reminded me a lot of Phil and Alex's Guide to Web Publishing, both in the positive and negative senses.
This book didn't have nearly as many pictures of dogs though.
I would recommend this book to someone who may have knocked together some CGI scripts but wasn't sure how to scale.
Disclaimer; I work for ActiveState, which sells a product which competes with Velocigen in the CGI-acceleration and web services areas. I am *not* speaking for my employer, this posting is *my* idea, no one but me has "approved" this post.
It's pretty light on code samples and tends to refer to Velocigen products more than anything else. This is okay, but I found out later from a friend that Chris Radcliff is also Chief Evangelist for Velocigen. This fact is not made clear on his website; I hope it is clear on the book jacket.
My $.02 and a little explanation:
I am indeed the Chief Evangelist for VelociGen. I tried to keep the book as neutral as possible, but it's obviously going to be affected by my tool of choice. That would have been the case even before I was employed by the company, though. I was a big fan of persistence (who wouldn't shut up about it) and that's why I was hired.
I should mention that the examples, though written in a style that VelociGen natively supports, are meant to be used by anyone on any platform. To this end, I'm frantically working toward publishing a CPAN module to handle PSP embedded Perl files. If anyone's interested in helping me (or getting the half-finished source early), please let me know. I'm hoping to have it posted to the site within the next few weeks.
As a final note, remember that it's me writing this book, not my company. Any inaccuracies or blunders are my fault, because I'm human. I'm working from my own experiences over the last 6 years, so I'm bound to have forgotten or misremembered something along the way. Please feel free to correct me, and I'll add the correction to the copy on my site.
Thanks,
Chris Radcliff
Although this wasn't a 'learn to do CGI with Perl' book, per se, it would have been nice to see a section on safe CGI scripting.
That was an unfortunate ommission on my part. The book was originally titled Faster Perl Web Sites, and system calls of any kind tend to be speed killers.
I probably should have taken the fool-proof approach: "Never, ever do this. And if you do, use -T."
Hi, the author again. Apologies for being all over this thread, but I feel some explanation is in order.
I couldn't find anything about the many efficient ways to solve the problems with the one to one relationship between Apache processes and mod_perl processes.
That's primarily because I couldn't either. That's why I mentioned FastCGI as an alternate method for doing so. I admit that I'm not a mod_perl expert, so I'd be happy to add your comments (or links to performance enhancements) to the online version of the book. See below.
Another huge mistake is that the book says that mod_perl and Apache are under the GPL license.
That's a big blunder on my part, started by a little typo. In my defense, note that changing one or two sentences to mention the ASL instead of the GPL will fix it (which I plan to do right now.) The rest of the section on "open source licenses" still applies, in my opinion. (The gist is "open source is good for software.")
Tim Bunce released v0.01 of DBI.pm and is still the primary developer.
I consider DBI one of those "on the backs of giants" modules. Also, I could have sworn that Tim mentioned another developer on the original project. (That was TPC2, though, so my memory could be failing me.) Either way, the principle holds. (Again, "open source is good for software." I'm not going to back down on that.)
mod_perl can do that too.
In truth, this is the objection I was most worried about when writing the book. Unfortunately, listing all the features of all the tools would have meant 99% overlap because they're all great choices. It would have made an excruciatingly long chapter. (Since the book was published, I've already come across half a dozen tools I didn't know about, and the ones I did have more features than I could describe in a whole book.) What I tried to do instead was give a sense of the choices, covering breadth at the expense of depth. The idea was that depth can be found on the Web, so readers are more likely to look for options.
Again, I really do welcome your comments. I'd like to keep evolving the online version of the book in a Perlish community fashion. Please let me know if you think something should be changed or added.
Cheers,
Chris Radcliff
If I don't want to learn or deal or read any Velocigen related stuff and code; do you think I can still benefit from the book?
Although most of the book's examples are written using Perl Server Pages (PSP), Perl is still Perl. I even have a whole chapter on different Perl embedding environments, including EmbPerl and HTML::Mason. It's a trivial task to adapt the examples to other environments, as I mention in that chapter (with examples).
*Reference implementation* meaning it is useless but you can spend hours on it just to find out that you can't use this for real world.
Actually, this reference implementation happens to be the exact same PSP module VelociGen uses, with references to the VelociGen environment replaced with references to the mod_perl environment. The module isn't ready yet, but I'd be happy to release the original version under the Artistic License if anyone's willing to help.
Cheers,
~chris
There have been a couple of comments about the "reliance on VelociGen" in the book, so I figure it's important to note that version 0.1 of Apache::PSP is now available on the book's Web site.
Apache::PSP is a reference implementation of Perl Server Pages, the tag-based Perl embedding environment I use for examples in the book. It already allows arbitrary Perl to be embedded in HTML pages using mod_perl. When finished (soon), it will allow HTML-like tags to be defined using a combination of Perl and HTML. A library of tags for basic needs (like database access and template generation) will be included as well.
Please check out the module and let me know what you think.
Cheers,
~chris
So, what are (will be) the differences between this version and the commercial version.
There aren't any differences as far as PSP itself is concerned. All the same predefined tags are there. (They will be, at least, once I tie up all the loose ends.) There are tags for database access, XML processing, and Web client access, among others. There's also the <tag> tag which creates new PSP tags.
PSP pages written for either environment will work with the other. You'll need to install the corresponding CPAN modules (e.g. LWP, DBI, XML::Parser) to use all the tags, but they're all free for the download.
Of course, the real reasons to buy VelociGen are performance, scalability, and ease of use. It's intended for sites that need to process thousands of requests per second.
VelociGen can also run any CGI Perl script faster, no matter how badly written. A wrapper script cleans up all the common mistakes and persistence leaks.
