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.
>choosing open source is such a good idea then do
>we really need shit like this pointed out?
Do you see the market share Windows has? While it isn't right for everyone, there are a lot of people who ARE right for open source but don't know it yet.
What, even the slug book? :-)
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
Unfortunately, after a second edition in 1997 the book hasn't been updated.
And yet, it's still being used in the Department of Foreign Affairs as need-to-know material for our intranet site developers.
However, most of the n00bs here seem to read PHP and MySQL web development, by Luke Welling and Laura Thomson.
The Canadian government uses Java, XML, VB/VBA, SQL Server, and ASP, but SQL and PHP are the primary ones.
I did ask around at web development and we did in fact order copies of the new book that you reviewed though. Cool, eh?
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.
You obviously didn't even finish reading his sentence..I really find it hard to believe that Perl with apache could be the best example for why OSS works!
From davorg's commentary, "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." That does *NOT* mean that Perl/Apache is the best argument for going Open Source, he's merely saying that the book provides good reasoning for doing so. The Mythical Man-Month was written 25 years ago and refers mainly to assembly and PL/I code (which is irrelevant since 95% of coding occurs in a higher level language today, and all's quiet on the PL/I front), but it still remains a definitive reference on software engineering principles and how to manage massive software projects. Good insight comes from the abstract, not the implemenatation.
--- What
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.
Apache and Perl was the way to go in 1996, but times have changed. Systems like PHP and (here comes the -1 Flamebait mod) ASP are faster and more efficient than Perl CGI. Serious webmasters do it in Java or C anyhow, for serious speed.
Serious Web programmer do not even mention "CGI" and "speed" in the same sentence.
Now,for some serious flamebait : PHP has always stuck me as an adequate, if somewhat anemic, Perl replacement but nothing more. It have a few very good library (PEAR and Horde), but nothing nearly as complete as CPAN. Zend is reputed very fast, but is it faster than mod_perl ? Instead of throwing half-baked opinion, please provide some hard number to back up your claim.
And what's ASP ? Is this some kind of tasty threat ? Never heard of that before ...
:wq
-- Sorry, I can't think of anything funny to say here.
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!
From the site:
why is there zero abstraction in PHP?
Because it's using native drivers wherever it can and you get the best performance that way. If you WANT abstraction (and the accompanying slowdown) you can use ADODB, Metabase, PEARDB, or other projects.
creation science book
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
Perl & Apache is an excellent combination for bringing sanity to legacy systems.
As far as dealing with legacy systems, nothing is better than Perl. For example, in a project I'm working on, in my company there is a vast array of legacy tools which require using telnet to get the work done. And the web interface I'm building (CGI & Net::Telnet) get's the work done beautifily. (Try doing this in PHP or Java.) The admin people are happy, and the development time so far has been almost negligible. Perl is the supreme glue language.
"...get its documentation all in one place, and get my head around it."
.pl file into their favorite html editor (dream weaver? front page?) You can say bye bye to your perl code. In the other hand, with script tags like <? ?> The editors will know not to touch those!
Ever visited php.net ? the official PHP manual is one of the best manuals I've ever read.
Everything is there! Well organized and easy to find. You also have user comments which are extremely helpful.
<i>"Speaking of database calls, why is there zero abstraction in PHP?"</i>
How hard is it to code your own wrapper functions to add your own level of abstraction on top of php's DB functions? Or use one of the million classes out there already created for you?
<i>"Also I think the embedded nature of PHP, while handy in simple cases, encourages people to mix up program logic and presentation. "</i>
So you are telling me that you prefer:
#!/usr/bin/perl
$var="Hello World";
print "Content-type:text/html\n\n";
print "<html>\n";
print "<body>\n";
print "$var\n";
print "</body>\n";
print "</html>\n";
Over this?
<?php $var="Hello World"; ?>
<html>
<body>
<?php print "$var\n"; ?>
</body>
</html>
Embedded languages like php/jsp/asp PROMOTE separation of presentation and program logic!
In addition for more complex cases, it is easy create html templates to add yet another level of abstraction to your scripts/presentation.
Ask your html designers to try importing the
How about text editors that do syntax high-lighting? with <? ?> they can do syntax highlighting for both, HTML AND PHP! giving the programmer a visual of the actual separation!
So.. the embedded approach encourages people to mix up program logic with presentation? Don't think so.
[alk]
You should try ASP.NET then. Not only is it precompiled and therefore much faster, it also is cross-browser, cross-platform friendly.
For some totally unfounded reason, I am septikal of this claim ...
:wq
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.
And if you put a cache product on the PHP machine, it'd be as fast or faster than mod_perl. mod_perl is caching the script in memory, something the default PHP doesn't do. Compare apples to apples please.
creation science book
One could add another caching layer on top of mod_perl to speed things up too....
But that 'caching' layer would be in addition to what it's already doing. mod_perl is already caching compiled scripts in memory. PHP by default is not. To accurately compare the max speed available, run the accelerator from php-accelerator.co.uk on the PHP machine.
Of course speed isn't everything, but you seemed to want to make it a big factor in comparison with PHP, and I was simply pointing out the flaw with the comparison.
creation science book
The cover should have a slug, a snail, and some salt. Which is which is up to you.
(B) + (D) + (B) + (D) = (K) + (&)
I have compiled a list of books I think should be on every web developers bookshelf. While I don't cover perl (I'm a PHP/JSP guy), if you are interested in this topic, you may find my page of interest. (http://www.starvingmind.net/tech.jsp)
For the Perl/Java tech argument. Well designed java pages can be just as fast, or faster then poor perl cgi's, and vis versa. I too have seen very slow JSP/servlet's. JSP's should not be programmed the same way as a language like PHP or perl in many cases, it will be slow. Perl ranks third for me, but not totally off the charts.
I for one would argue JSP based development makes more sense for most sites, due to development productivity, and language functionality. And as I said before, a well design Java site can execute as fast or faster than some perl CGI sites. PHP ranks right behind JSP's in my mind, since they don't provide as much functionality, although they are very fast for simple things.
Perl should be a tool in your developer's toolbox, although I believe PHP or JSP's are in most cases a better tool for the job of making dynamic web sites.
-Pete
Soccer Goal Plans
ASP is a nasty, venomous reptile which can bite you in the ass and end your Egyptian dynasty.
dave "or something like that."
Hey, someone writing a book has to make these choices. If you don't like them, write your own book based on your preferences. You prefer php to perl? Then don't buy this book!
If all this should have a reason, we would be the last to know.
If all this should have a reason, we would be the last to know.
I do not want to start a flame war or anything. I have been getting into Python lately and am starting to wonder why I don't see more sites using Python over Perl? Can anybody point me to some dynamic sites that have passed over Perl, PHP, JSP, CFM -- and decided to go with Python. Having played around with many languages over the years? -- there is something about Python that made me do a double take and I have been indulged ever since....
(+1 Funny) only if I laugh out loud.
any website based on perl is doomed to become an unmaintainable mess. look at languages better designed for web use or at least maintainability (php, python, etc).
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.
Well I wouldn't worry about "piling on" with that example. If anything, demonstrating perhaps the most inefficient method to write "Hello World" in perl is just helping promote PHP...
Code, Hardware, stuff like that.
If you are just comparing how short something can be and still say "Hello, world" when you view it on a browser, then I can do you one better. Step 1: Create a text file that contains the following:
Hello, world.
Step 2: Change the .txt file suffix to .html
The C++ way of writing a "Hello, World" program looks inefficient to a BASIC programmer for the same reason you are turning your nose up to Perl's CGI:pm object... the BASIC programmer doesn't yet understand the power of what he's looking at.
Information wants to be anthropomorphized.
That's the way it's supposed to be. After carefully observing the behavior of ASP pages on IEWin vs. every other browser/OS combination, I'm not convinced that that's the way it is. I'm not entirely kidding about the idea of client sniffing.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
You can be both more incisive and factually correct:
any website coded by perl 1337 hackers who spent more time reading slashdot than studying CS is doomed to become an unmaintainable mess. look for programmers whose code is better designed for web use or at least maintainability (be it in perl, php, python, etc).
There you go.
Freedom is the freedom to say 2+2=4, everything else follows...
Danny.
I have written over 900 book reviews
And I'll back you up on this. Although you disputed it by talking about time-to-deployment, I dispute it on grounds of actual speed of page returns. I worked at Borland and built tons of apps using Perl (pre-JBuilder), then at Arzoo using JSP, and now at SST using PHP. PHP is by far faster than the rest. And there is another Web team at SST, and that team works on competing projects, and they used ASP at first, and now JSP, and they regularly come and ask how the hell we return pages so quickly. Because we're experiencing some real-world payoffs -- for example, our group is getting the new projects -- I'm sticking with PHP.
I think the biggest problem with PHP is that it is fast enough to allow us to be sloppy -- if we want to put 20 SQL queries on a page and have 15 included files, we can do it without much of a performance hit (though MySQL is crazy-fast on selects, so that deserves credit too). Back in the old days, I'd have to optimize, optimize, optimize. Maybe even drop some less necessary features because the slowdown was too much. If you really want to talk about super-slow Web apps, remember IntraBuilder. Anyone remember that? It was a Borland product with a LiveScript clone on the backend, and oh my God would it crumble under pressure. We had to use it at Borland, sort of a eat-your-own-dogfood kind of thing. But when your own employees start to hate your product and bristle at the mention of it, the product is doomed.
My Greasemonkey scripts for Digg &
When we talk about the advantages of different languages, how much of the time are we talking about the language, and how much is about the tools?
I mean, when I've played with OS X programming in Obj-C, I know that Cocoa apps could be written in Eiffel or Ada or any number of other languages. But the tools don't support these languages, and the tools make things so unbelievably easy.
So is it the tools, or is the language/runtime?
In web development, it's all about the tools. The language doesn't really matter. Think about it. For web development, you need a language which can:
1) Connect to a database
2) Be good at string handling
Why are strings important? Well, most stuff in web development is about strings. You interact with the DB via strings, you send the client a bunch of strings etc. Hell, even a god-awful language like Tcl can be really good for web development when you couple it with a kick-ass toolkit, like aolserver/openacs. Incidentally, aolserver/openacs and expect are the only reasons any mentally stable person agrees to learn Tcl.
Performance, on the other hand, is not that important. Most of the time you'll be waiting for the database or to push data to that guy behind a 14.4 modem anyway. What matters performance-wise is that you have some mechanism of keeping the script interpreter loaded all the time (like aolserver/mod_perl/php/java) and having persistent db connections.
So why use Java? It's not really good at handling strings, strong typing is often not necessary in web development and having to compile your code before you test it slows you down (yes, I know JPS:s are automagically compiled). As I said at the beginning of my rant, it's all about the tools. Java has _excellent_ tool support. XML stuff, web services, layered architectures (J2EE), you name it. Java has it. And all the major players in the industry are behind it, except Microsoft of course.
Java is also scalable. For the really simple site, writing a JSP page is as simple as writing a PHP/ASP page. For the high-end stuff, you can have 27 bazillion layers all cleanly separated on separate clusters costing umpteen million dollars.