Slashdot Mirror
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.
Manning Publications Company always seems to have these creepy cover illustrations.
I much prefer the O'Reilly animals.
And yes. I am being a little facetious here.
What, even the slug book? :-)
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
Don't want to be a troll but no matter how good the book is, surely for material like this, the web itself is the best medium.
.
A paper book is certainly more portable, and for most people easier on the eye, especially when you read for a long time but . .
Topical material is quickly out of date
You can't search too easily for the topic or phrase you want
You can't easily look up a reference for a term or concept you don't understand
If a certain paragraph doesn't make sense you can't look for alternative statements of the same concept
Once you've read it there isn't any easy way to look up a particular section when you next need it (the books at home, borrowed by a colleague etc)
Books cost!
Old-school Perl CGI is relatively slow, yes, though an awful lot of that has to do with the quality of the back-end code. But mod_perl is unbelievably fast -- and I say that as someone who makes his living developing and maintaining a database with a Web interface written in PHP, so it's not like I'm prejudiced in Perl's favor. "Serious webmasters" choose whichever tool gets the job done best, and if they're also good programmers, they write good, clean code that executes fast enough that the client doesn't have to care what's driving the site.
That being said (anti-flamebait!) I'm amazed you mentioned ASP, not because of of its flamebait value, but because, um, it sucks. I swear to God, there must be "if(client != "IEWin"){slow_down(); crash_unpredictably();}" in the source somewhere. 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.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
When I started web programming 2 years ago and faced the choice between working with Java, Perl and up-n-coming PHP, I looked around and it seemed to me that the people using Perl were doing the most innovative, creative stuff on the web. (Slashdot's "distributed moderation" scheme, which I regard as a quantum improvement over USENET moderation for providing large-traffic yet readable forums was just one example.)
I wanted to do innovative, creative stuff, so I started writing Perl.
No regrets. I don't think that aspect of Perl has been particularly usurped. Nor do I think there's another language which provides a platform for faster time-to-market and feature iteration.
As mentioned elsewhere on this thread, and Java and PHP have their own distinct advantages also.
--LP
Systems like PHP and (here comes the -1 Flamebait mod) ASP are faster and more efficient than Perl CGI.
:). Of course I should say that it's entirely theoretically possible that an ASP solution under Unix might give comparable, or even better, performance but given it's such a small market share and has comparatively tiny amounts of development time (measured in developer hours) associated with it it's not realistically likely - to the extent that I don't think anyone would even claim it is. It's more of a way of giving customers ASP without having the system administrator management headache of having to run NT servers.
Perl with mod_perl is *very* fast and no slower than PHP with mod_php. Perl on it's own certainly isn't very nippy under high load, but then PHP without mod_php isnt great either, though many PHP fans don't take the time to understand the difference before determining which is better (which is understandable when you take into account that PHP is now used more than Perl by less experienced users, due to it's greater ease of use).
ASP pages (at least served by IIS) are significantly less able to cope with high load than Perl with mod_perl. IIS really strains when serving dynamic load (though it's superb at serving static content, though that's not so useful
There seems to be a big PHP bandwagon among the hip and trendy crowd these days. That's not entirely a bad thing, because (like Perl) PHP is a GoodThing(TM) but it is a when they are just repeating what everyone else is doing (which is always a bit worrying).
The most compelling arguments are that PHP is of course easier, and so on balance PHP markup is much less prone to errors than Perl scripting.
Serious webmasters do it in Java or C anyhow, for serious speed.
Sorry, but I really dispute this. Not that serious webmaster to it in Java or C, just that it's not always very quick (I'll justify that in a minute) and that there is an implication there that 'serious webmasters' work only or even mostly in Java or C which I disagree with.
If you are writing a large scale project with many developers some find it easier to keep control over the project if it's written in Java or C (over Perl) because of Perl's flexible nature (which some see as a curse when you have a large project). I can certainly see the merits of this and am a big fan of Java.
The drawback is with C is that C code takes much, much longer to write, takes longer to modify and is more prone to errors due it's complexity. Very little CGI is written in C due to this. I think that most appropriate place for C CGI's is for particular CPU or memory intensive functions who's functionality will remain relatively static over time. This way you can rapidly build flexible CGI interfaces around a very fast C program, meaning that your servers are not tied up with that function, but that you can still easily modify and adapt the front end of your site. Perl modules written in C are typically created to be used in this sort of context.
Java is excellent in that it imposes a similar strictness to C while allowing you to still comparatively rapidly produce code that is less error prone than either C or Perl (IMO), meaning it's great for development among many developers. The drawbacks are however that it still takes longer to code a solution in Java than in Perl (though it's quicker than C) and Java does not really become an option for high load situations unless you have large Sun hardware with plenty of RAM (several Gigabytes) to throw at it - though at which point it really shines.
So 'speed' is a relative term, yes certainly code in C will execute faster than in Perl, but if it takes you a month instead of a week to write, you may have just wasted 3 weeks worth of project time (and this can doom a project or kill a startup). It's much, much quicker to write and modify code in Perl (or PHP) than in Java or C (though modifying _other_peoples_ Perl can be a different story, though I've never had any problem doing that, I can see how other people do).
I once worked out timescales for a project that went like ~2 months of Perl coding or ~4 months of Java or ~6 months of C and noted the problems/advantages of each and let my manager pick one. We went with Perl (with the option to have parts in Java or C as we came across parts of the project that would benefit), even though Perl alone might struggle with the load of the task we were doing, because it was felt that Perl would easier to maintain, given that more people in the company were comfortable with Perl, Perl meant rapid development allow us to bend with typically ever changing requirements and that Perl monkeys are easier and cheaper to find (should we all leave and minion adjustments required to the software at a later stage).
As I final note I'd say that PHP certainly is quite appropriate in many situations and I don't dislike it at all, but for those with a strong Unix bent, unless they have good Perl already they might be better off doing at least a couple of projects in Perl, as Perl becomes a key 'life skill' due the fact that it can be used to write extremely useful scripts that do very complex things very quickly, so learning it is very useful.
Why should I have to sit down and read through PHP stuff when I already know perl?
/cgi-bin/ is nice.
You know, I thought exactly the same thing - I've written a LOT of perl-driven sites over the years and always considered PHP a sort of "perl for dummies" until I actually decided to use it.
Maybe the earlier versions were bad (you can see by the fact the language still has a lot of ugly constructs that it's evolving all the time), but it really is excellent for putting a dynamic site together very quickly. The huge amount of convenience functions just save so much time (yeah, ok you could have a massive library of Perl objects and functions you coud pull in to every script, but it's not going to be as fast).
Then there's the fact a designer can work on the same files as a coder without having to use templates.
It's fast too! No, not C/C++ fast, but I certainly haven't noticed any database driven sites being held back by it - and freedom from
Of course, for command-line tools I still use Perl.
Code, Hardware, stuff like that.