Web Development with Apache and Perl
I mention Stein's book because that's what this new book reminded me of most (that, by the way, is a huge compliment). Petersen realises that an overview of the whole web development area would be difficult to write (and, ultimately, unhelpful) so he restricts himself to a subset of the available technologies - Perl and Apache - and gives a thorough review of the state of the art of web development in these areas.
But before he gets into the details of Apache and Perl, in chapter 1 Petersen takes a look at the wider world of Open Source Software and in the process presents one of the best arguments I've seen in print for why a company should choose Open Source Software. In chapters 2 and 3 he takes the same approach with web servers and scripting languages, giving compelling reasons for choosing Apache and Perl.
Having chosen his architecture, in part 2, Petersen moves on to looking at some common tools for web development. Chapter 4 looks at databases. The two main Open Source Databases (MySQL and PostgreSQL) are compared and MySQL is chosen as the basis for the rest of the examples. Chapter 5 discusses the shortcomings of the standard CGI architecture and introduces mod_perl as an alternative. This is a good introduction to a technology that some people can find hard to get to grips with. Petersen takes us through the use of Apache::Registry before moving on to the complexity and power of mod_perl handlers.
Chapter 6 looks at the importance of security in web applications and discusses in some depth the problems of user authentication and the use of SSL for secure data transmission. Chapter 7 looks at ways to separate content from presentation. First we look briefly at server-side includes, but the majority of the chapter is taken up with a review of the various templating systems that are available for Perl. The chapter finishes with a detailed look at two of the most popular templating solutions - HTML::Mason and Template Toolkit.
Part 3 of the book looks at three different types of web site in great detail. In each case Petersen uses the examples to take a brief survey of a number of the existing tools. For example chapter 9 looks at a community web site and contains information about a number of web-based forums and chat rooms. It also takes an extended look at Slashcode the software that runs Slashdot. Chapter 9 takes a similar approach for intranet sites and Chapter 10 for online stores.
In part 4 we take a longer term view of a web site. Chapter 11 looks at content management systems and chapter 12 lookat at performance tuning. Both of these chapters are full of useful advice on how to make running a web server as painless as possible.
I think this is a very useful book to have on your bookshelf. Anyone who is developing web applications using Apache and Perl will find something useful in the book. It should be obvious that in order for a single book to cover so much ground, sometimes there isn't quite as much technical detail as you might like, but there is a good bibliography that will show you where to go for more information. In my opinion the high-level approach makes the book particularly useful for a couple of groups of potential readers. Firstly I think it makes a great introduction to the subject for someone coming to Apache and Perl for the first time. Secondly (and perhaps most importantly) I can see the book (in particular the first three chapters) being very useful reading material for a manager who is making a decision between using Open Source Software or some proprietary technology.
You can purchase Web Development with Apache and Perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Perl CGI, when done correctly, can be a good solution for a large enterprise E-Commerce website. I don't like the look of the language, nor do I like how OOP is slapped in.
BUT
The chances of getting a large group of perl developers to code a large enterprise E-Comerce website and not take shortcuts nor kludges, and not to just fall away from good design and architecture is very rare.
Java, along with J2EE, JSPs, and taglibs FORCE you to follow good practice and design. Its a lot harder to 'kludge' something up without still following design and OOP (granted, its still possible). Another thing I LOVE telling C++/Perl/ASP people is taglibs. No other language has anything similar. An HTML monkey, that has NO coding experience, can modify JSP's that utilize taglibs. It just produces XML that HTML monkeys view as just more HTML tags.
All in all, having a perfectly designed J2EE website (built with experienced J2EE developers) vs a perfectly designed Perl/CGI website (built with experienced Perl developers) would show that the J2EE website would be easier to maintain and the ability of non-developers to change the design of the pages without any trouble.
The only negative point of J2EE is that its MADE for large projects. If you have a small e-commerce website, J2EE is overkill, and will take too much time to write. Perl/CGI is great for this type of site. But that is where I draw the line.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
You never heard of mod_perl, FastCGI, Embperl, or the Template Toolkit if you're still talking about PERL CGI scripts, have you?
Apache and PERL is still the bleeding edge of web developement. It's just no more alone at the top. Perhaps you should take a look on these Benchmarks. Especially the JSP don't look very good there and Embperl2 is usually very close to PHP regarding performance. Only Apache modules written in C are without real competitor. But you should also think about the ease of developent if you compare C code with PERL, PHP, ASP or JSP.
-- There is no place like $HOME.
Even these days, old-school Perl CGI is often the right tool for the job. Unless you're developing 100% for IEWin, IIS, and MS-SQL, ASP never is.
Go to monster and search on perl/cgi based jobs for web work.
Now search on Java based jobs for web work.
In general,
Your general simple/small/little processing pages use perl.
Your smaller companies that require dynamic pages use ASP.
Large business that have huge enterprise sites with multiple intraweb applications run Java/J2EE.
I've had multiple jobs that required me to change a smaller webapp from perl into Java since it started small and grew into a large program and started becoming difficult to maintain.
If I had time, I'd love to take slashcode and make it into a fully J2EE website to prove, once and for all, how much of an advantage it is for large websites to change to J2EE.
Now, don't get me wrong, perl is a WONDERFUL scripting language that I use almost daily. It makes great little sites (or even large sites that don't require a huge amount of processing/code) that you need to create in a short amount of time. Just, when it comes to making a large project with funding and time, J2EE has enough advantages and features that makes the job so much nicer. Maybe I'll make a journal entry to fully argue the points back and forth.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!