Slashdot Mirror
E-commerce with mod_perl and Apache
rob_99 writes: "Cool new mod_perl article at perl.com documents building a large scale ecommerce solution w/ mod_perl & apache!" Pretty cool stuff - it's kind of funny to think how ephemeral their work turned out to be.
great article, i hope php gets such a good write up.
Interesting to since what was nappening behind the scenes away from the marketroids.
"It is a greater offense to steal men's labor, than their clothes"
Maybe you should learn to write better code? Sloppy code indicates a sloppy mind.
17 mod 5 = 2
17 mod_perl 5 = ?
Actually the Metallica lyrics are from the self-titled album and not Ride The Lightning you dolt...
EPHEMERAL
Adjective
1. Lasting for a markedly brief time: "There remain some truths too ephemeral to be captured in the cold pages of a court transcript" (Irving R. Kaufman)
2. Living or lasting only for a day, as certain plants or insects do.NOUNA markedly short-lived thing.
ETYMOLOGY From Greek ephemeros, ep-, epi-, epi-, + hemera, day
Just in case your vocabularly sometimes leaves you wondering (as mine does).
That which does not kill me only makes me whinier
I remember my first expierance with mod_perl. I was working for a small development company. That's not the key part
:)
The key part is that I was in charge of the perl backend, and it was really lagging. Loaded mod_perl up and *bam*, we had a fast enough system. I never did a serious benchmark, but it was like 100% improvment
Thus all I can say is good job guys! This doesn't surprise me at all, and it's good to see recognition get passed around in the correct quantity for once
No, I comment my code. Really, people always beat up Perl and say that it's not readable. That's not true. I would guess that anybody who spends a fair amount of time in Perl learns to use the $,%,@, and etc. as their friends.
These things are convient shorthand, not unreadable code, if you spend some time with the language.
That which does not kill me only makes me whinier
HAHAHAHA, I was wondering where YOU have been....
...that they used MySQL.
Nope, no problems.
We use Embperl, which is Perl tags in HTML, like PHP. Embperl is very impressive.
I learned Embperl before PHP. Now I'm learning PHP on the side and feel that it is lacking features which Embperl includes. For example, in Embperl, I don't have to do "stripslashes" or "addslashes" when I read from a database. This makes the code cleaner. Also I can use straight HTML in between conditional statements without having to use "print" everywhere.
[$ foreach $key ( keys %ENV ) $]
My key is [+ $key +], which is [+ $ENV{$key} +]
[$endforeach $]
Nice and clean code
Guess plain text posts on Slashdot don't have their text escaped. Hence why my HTML tags disappeared :(
The application servers use "sticky" load balancing. That means that once a user goes to a particular app server, all of her subsequent requests during that session will also be passed to the same app server. The f5 hardware accomplishes this using browser cookies.
Doing something similar, I just hashed the users IP, mod by the number of servers, and sent it to that particular server. (ie. 10.0.0.1 = 0xA000001, 0xA000001 % 0x0A = 0x01, hence send to server #1)
In case of server failure, the sessions might get unstuck from the server, but that shouldn't happen often enough to be much of a performance hit.
No; I haven't had that problem at all. Perl is a
good language for writing understandable code.
I was recently contacted by some people about a
web site full of cgi scripts that I wrote several
years ago. They sorta apoligized for not getting
back in touch, explaining that the code was so easy
to understand and modify that they just did it and
didn't need to contact me. But now they had some
more sophisticated needs that they weren't sure they
could program, so they thought they'd call back an
expert.
So maybe the lesson here is that I should learn to
write less readable code. Then people won't be able
to modify it themselves, and they'll have to hire
me to make trivial changes.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
But an application server it is not. Container managed persistance, transactional support, message queues, naming and lookup services? Integration with existing business objects and processes? These aren't trivial in Perl, but they are the core functionality of app servers. They pulled off clustering for eToys, but it was hardly an out of the box solution.
If all you want is a servlet container, don't spend the money on an application server. Tomcat works great and iPlanet bundles one with their web server.
I was I could mod that as flamebait.
Part of keeping society up and moving in a forward direction is for everyone to do what they are best at. Joe Blow who lives in Kansas can't do a single thing to help those people (beside give blood, money, pray, etc.), so what would you have them do?
By doing what we do best we are helping improve technology, which is always important in any time. Although serving X amount of pages an hour isn't as important as developing whatever new technology that could be used to save lives, it is society moving forward.... which is always important.
Kenny
I love Perl - it's a great scripting language. So is PHP (as seen on my useless website). However, for powerful web applications I could do without either one. No matter how elegant the design, the word "spaghetti" comes to mind. Now, switch over to a fully compiled, OOP, event driven "paradigm" (sorry), and you've got me hooked. Whethor it be Java Servlet's with JSP, or more favorably ASP.NET with C#.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Having built numerous e-commerce sites and even worked on a commercial shopping cart written entirely in Perl, I can't say that I think it's the best choice. It's great if the job is small; it's quick to code, is installed on almost all hosting providers, and so forth. But for large projects the code becomes very difficult to manage, mainly because getting people to write clean Perl code is difficult.
.xs version of the Perl client which wrapped around our C library. This has proven to be much easier to maintain.
There's a second downside: lack of good SSL networking. SSL is critical for credit card processing. I ported the GPL version of TCLink for Perl, and we ran into a lot of problems due to lack of a standard SSL library. For the first version of the client we ended up distributing a patched version of Net::SSLeay which added all of the certificate authentication functions we needed (and are missing from the standard install of Net::SSLeay). Later this became such a headache for the various platforms we were trying to support that we just coded a
Long story short: sure, Perl's great. Is it the best choice for e-commerce? I'm not so sure.
So in your opinion, nobody is allowed to do anything while "The souls of the victims are watching"?
How are people supposed to move on from this tradgedy if they cant do anything to take their minds off it?
Anyway to get ON TOPIC, perl is a great language to write this sort of thing in. I prefer using Embedded Perl myself (i wonder how that would perform as an ecommerce solution.).
but perl IMHO is the most powerful and versatile CGI language around, java creates too much of a load, and C requires you to recompile after altering any of the code.
ok im rambling now..
when everything is working perfectly.. BREAK SOMETHING before something else FUCKS up!
But I gotta say, I would have loved to have been on that team for that. Though I would have rankled at the suggestion of needing "help" with object oriented programming, it would have been worth it to meet those two.
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
For all the good(ish) things about perl (a massive developer community, libraries to do ANYTHING, reasonable performance under mod_perl, and instant recognition), describing perl as:
'Through the use of Perl's object-oriented features and some basic coding rules, you can build a set of code that is a pleasure to maintain, or at least no worse than other languages.'
is rather laughable.
Perl has a tacked-on-the-side OO layer that kind of works if you are careful, and I don't think anyone would argue against the well known write-only feature of perl code. Maintainable yes, equal to other languages? Less likely.
However, I find the most interesting part of the article the switch from MySQL (popular, but has REAL trouble scaling, I know I will get flamed for that, but it is my real experience) to Oracle. I wonder what other systems were tested? If they were getting a significant speedup with a berkely-db cache of serialised objects, then they were not getting a lot of performance from their database.
I would have been very interested in a comparison between their Oracle setup and a PostgreSQL system, given their need for local caching running a PostgreSQL cache on each machine could have been quite a win.
Their code samples given certainly do not represent 'clean and maintainable code' to my eye. perhaps they should invest in a python book, possibly the most readable language I have yet found (but will not stop looking).
It seems like the primary (note /.'ers, I said PRIMARY, not your little pet project :) ) use for mod_perl is to avoid the overhead associated with loading modules.
It seems like the better choice would be to avoid using modules altogether. Or using another language like C or PHP that has stuff built-in. It's amazing how much CPU time loading a simple perl module takes.
Comparing performance between mod_perl, servlets or even asp is pretty fair... My preference is still for the java solution because i like the variety in VMs and there's some nice (and some bad... think back to classloader issues with the pre-2.1 servlet spec; ejb-jar interdependencies...) tools that are forced upon you with j2ee.
This article drives home a very good point: sound architectural design is what makes a complex system work. If you know what the big picture looks like, you can fill in the details whichever way suits you.
C++ guy who did industrial OO perl for two years --
.15 seconds with perl. The images loading (even on broadband) will be the gating factor on pageloads.
[quick disclaimer, feel free to use ruby or php for a substitute for perl below]
Perl is very good for a much larger range of projects than you think. [with a HUGE deference to C++/OO people, see note at bottom]. Very few sites rely on pure computational power. Most sites only need a small compenent to be fast, and that you can implement in the language of you choice with perl bindings. The majority of your site is glue -- and this is what perl does well.
I worked for a small team (5 developers) that wrote 200k lines of perl in a year and a half. That represents a far larger body of code if it had been written in another language. That isn't to say you lose control by using perl. You get to ignore the details, and in the bargain get a perfect language (and some extra time) to write regression tests.
All in all, unless you are a games site that cares about milliseconds, you can get a page out the door in under
-spRed
the deference to OO folk, you can teach people who only know C++/Java perl, you can't teach people who only know perl the others. The reason why is that real CS educations are portable. Perl [and other interpreted languages] are looked down upon by CS folk - so only non-CS folk will persue perl as a primary language. Perl is, however, extremely useful for whatever you are doing (95% of you). Give it a chance, it will save you alot of time in the long run.
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
I love it! And I quote...
"When it comes to building a large e-commerce Web site, everyone is full of advice. Developers will tell you that only a site built in C++ or Java (depending on which they prefer) can scale up to handle heavy traffic."
then later...
"Since searching was such a large percentage of overall traffic, it was worthwhile to dedicate resources to it and take the load off the application servers and database. The software on these boxes is a multi-threaded daemon that we developed in-house using C++."
So, if Perl is so scalable.. why did they write this search engine in C++?
Appearantly the myth is true!
I rest my case.
"Oooh.. that feature will require the parallax scrolling chip..."
Perl allows you to do some really cool things, like fit 10-20 lines of code in any other language into 1 line of Perl. (Here's the proof.) Of course, you pay the penalty for being "clever" 6 months down the road.
It's good to remember that just because you can do something, it doesn't mean you should do it.
Seriously though, if you've ever had to debug or maintain someone else's code, you should know how much trouble Perl can make for you. I'd almost rather debug assembly...almost. ;-)
Turambar
------------------------------
Common sense is not so common.
--Voltaire
If you've had a bad experience with PERL, give Perl a try!
how to invest, a novice's guide
This paper was presented by the authors at Apachecon 2001 in Santa Clara, last April. The [ApacheCon.com]session info is still (sort of) online. Cool stuff.
What Would the Fab Five Do?
I part own an e-commerce company that's partly built with Apache/mod_perl/MySQL. We crank millions of dollars through those servers every week (porn still pays, what can you say ;-). The compile time of a script that pulls in libraries with 200k+ lines of code without mod_perl is several seconds. With, it's < 1sec. True we have/need 4GB RAM/server, but it does allow us to scale to whatever we want.
;-)
I often read articles saying perl/mysql can't handle enterprise solutions. Well, it can, does and is doing so in our case. Like any tool, it's as effective as the people wielding it.
We also have a huge codebase in C/C++, Java, Python and a few others. There's even a few NT boxes thrown in for dealing with some obscure hardware. I'm not particularly bias one way or the other, I just need the results.
By the by, I do have one solution for ensuring my programmers don't take sloppy shortcuts and write obviously quick and dirty code. It's the pink slip method. I find it works equally well in any language
Robert Nice
WebsiteBilling.com Inc.
Where is the advantage of this over a simple round-robin scheme? With round-robin each server will at least get the same number of sessions to start. With your scheme it'd be possible to for a couple of machines to be bogged down while the rest are relatively idle. Sure that might be unlikely to happen but I don't understand why you would even give it the chance.
Great article.
I'm looking at setting up a similar type of system using postgres, apache, mod_python, and XSLT. Has anyone else ventured down a similar path?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I don't understand the community of Perl developers to be frank...but I am not a programmer, so may be someone will answer this in perlish English ?
Want to buy some cookware?
Because you'll see large numbers of users coming from single IP addresses in the case of proxies. Think AOL, WebTV, ...
Today's hardware is designed to distribute sticky sessions randomly or round-robin, resulting in more uniform load distribution than your "smart" hash.
http://software.tangent.org/projects.pl?view=mod_l ayout
Were that I say, pancakes?
...lies with the first moderator who doesn't get your humor. Oh well.
I'm sure this one will be flamebait too, because some moderator won't get the "-c" joke.
Turambar
------------------------------
Common sense is not so common.
--Voltaire
If you're problem is even moderately interesting, there will be no out-of-the-box solutions. That Open Source might require more implementation time may be true, but the "turn-key" fantasy is most always a lie.
I used to work for eToys.
In November, eToys had over well over 1000 employees. By March, they had fired all but a 10-20 employees (all management), and most of those people are gone by now. Few of these 1000 employees received their full severance package because eToys had no money (This was a violation of the contract, but suing was a lengthy and tedious option).
Between December of 1999 and December of 2000, eToys burned though several *HUNDRED* million dollars in funding.
KB Toys bought the eToys merchandise (toys), the eToys brand, some of the computer hardware (but not the intellectual property needed to maintain it, e.g. the engineers and administrators), and I think the warehouses (One of the warehouses was a $20-million high tech warehouse).
That counts as going under.
Their only successful subsidiary, Babycenter.com, lives on. But they don't use mod_perl (It's an Apache + java application server shop).
Have the Issues with expat, etc, that mod_perl has been sorted out? XML is vital to "e-commerece" infrastructure these days, but the last time I tried using the perl XML modules with mod_perl (2 months ago) I was greeted with a stunning array a segfaults, and I was told it was a known issue (something to do with expat, IIRC). I did look in the usual places and can't find any mention of these issues being fixed, unless I'm not looking in the right place?
.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
As for stripslashes and addslashes you should look into magic quotes with PHP.
As for too many print statements you can do <?=$variablename?> to print more concisely.
eToys had over 100 people coding plain vanilla HTML... is that a good example of how mod_perl can be used as an ecommerce app server?
mod_perl definately has it's uses, but eToys is a bad example. Remember, eToys went out of business, in part because they spent way too much money on hardware and had way too many employees doing simple jobs.
You would think a large site like eToys would make good use of templates and would reuse programming objects all over the place. This wasn't the case for eToys at all.
eToys initially felt it was too difficult to use mod_perl to create templates or reuse objects on their site. They almost never reused elements in their pages, and they had very few templates. There was hardly anything there you could call an 'application server', and most of their pages were not dynamic (outside of store item entry).
Instead, they had over 100 HTML people to write the HTML for just about every single page on their site. It wasn't a very large site either. When I say 'HTML', I don't mean 'they wrote DHTML or PHP or java or perl. They had 100 people writing plain vanilla *HTML*.
Towards the end, eToys hired a few smart folks who knew the capabilities of mod_perl. They were on their way to creating a templated dynamic site. In the middle of this new effort, they went bankrupt.
(I used to work for eToys. Posting as AC to protect me from Toby Lenk's lawyers).
So they used mostly open source software, but not for the database engine. Is MySQL really that bad wrt. scalability? (Or has that changed with newer versions?) And what about PostgresQL? If it is the case that there are no viable open source solutions for highly scalable databases, why have there been no development efforts to produce more powerful database engines?
This is just a question. Use your mod points on good answers. (-:
I don't need no steen'kin karma!
They wrote a small piece in C++ because it was the right tool for the job. They wrote the rest in Perl because it was the right tool for the job.
If the whole thing was written in C++, they would probably still be coding the basic application.
When your needs are to get an application to market quickly, there are few languages that can compete with Perl.
If you question the scalability of Perl, I would challenge you to write a complex web application in any language that would handle 200,000 sessions and 2.5 million page views per hour.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
TrustCommerce offers a drop in .pm module as well for people writing perl front ends to their web sites. The Raven SSL package allows apache to serve https, not make ssl connections from a perl program. The trouble with SSL in perl is not serving https+mod_perl, its in writing those easy drop in .pm modules for connecting to the eCommerce gateways. Lucky for all you eCommerce site developers, we gateway programmers get to worry about that, not you.
I don't think Adam's comment was meant to detract from the power of something like Mason and mod_perl for developing web site front ends. It was just that of all the API's we have open source libraries for (C, Perl, J2SE, J2EE, Python, PHP and ColdFusion), the Perl module was by far the hardest to develop as the existing tools lack some important features.
I completely agree. We had a horrendous problem with JSP proliferation, getting to the point where we had hundreds of JSP pages for a relatively simple application. Basically, as web developers learned some Java, they'd use it. In and of itself, that's not a big deal, but they really didn't know how to use it, and it became quite a nightmare. They'd take advantage of the servlet base, resubmitting temporary results to other JSPs, confusing and confounding the information flow.
We rearchitected the system around XML/XSL, assigning the webmonkeys (ahem) to the XSL layer to compose views based on a standard XML document structure. Client requests were dispatched to function handler objects by a mediating servlet, and then to the back-end business logic.
We lost a lot of flexibility by eschewing JSP, but that was part of the goal, which was the result of a lack of discipline on the part of the presentation developers. Taking away a lot of their options didn't solve all of the problems, and introduced some new ones[1], but it simplified QA remarkably and reduced my headaches.
[1]: We had to operate in lock-step. As presentation is sometimes much easier to develop than business logic, the XSL developers often had to wait, none-too-quietly, for adequate function handler and XML-generation code.
Most Computer Science majors are lazy, therefore they think that perl is amazing. They hate prolog because it is radically different. They know C++ and Java, but for quick jobs, they go with perl.
Most Computer Science professors hate teaching perl (at least for intro stuff) because the syntax is crazy. They love prolog because the students hate it and most of them are crazy and love everything, except for teaching perl to newbies.
CS alumni program in whatever language their job requires!
ephemeral (-fmr-l)
adj.
Lasting for a markedly brief time: "There remain some truths too ephemeral to be captured in the cold pages of a court transcript" (Irving R. Kaufman).
Living or lasting only for a day, as certain plants or insects do.
n.
A markedly short-lived thing.
http://www.codewolf.com - Just good stuff to waste time
Like the subject says, you should be safe in your career. After all, you know The One True Programming Language, right? Perl isn't a toy, though, is it? I mean, if it's functionally equivalent with Ruby or PHP in all respects then it must be worth something, right? (Just don't let those interpreted guys into the Compiled Officer's Club... they might tell wild stories about getting lots of work done really quickly or spread notions about non-compiled languages being the right tool for the job...)
Seriously (or maybe not), perhaps you could check your OO bigotry at Dr. Dobbs door when you come slumming it in Scripting Land? I know some of us started using Perl before a "real" language like C++ or Java, but that doesn't make us unable to learn that real language, does it? Does it mean that we won't be able to get real work done? Are the sites we work on less useful to you?
Why would you look down on someome who has started out with Perl? I started out in the computing world using BASIC on my VIC-20. I didn't have the luxury of Java or C++. Do you think I can still learn? Am I worthy? Can I evolve to your level? Will I ever be able to look down my OO nose at mere scripters like you do? Can I be effete?
Ok, sorry to bait you. I use perl as much as I use shell scripts. I no longer use BASIC or Pascal and I'm glad. Quick and dirty GUI apps in C and C++ are a pipe dream -- Java works very well for that (especially when your app has to very quickly work on everything from BSD to WinNT). But I hate to break it to you: I have no CS eductation. The only CS course I ever took I wound up teaching. Should I resign from my job? Am I doing my company a disservice by "trying" to write OO Java apps for them since I don't have a "real CS education"? Are the OO perl apps I've written even OO enough to get me in the club? Are my C apps more portable than my lack of education? Are my Java apps?
You should realize that your "real" CS education bought you knowledge, but not at the expense of anyone else's abilities. Software Engineering is not a zero-sum game; we can all play without dimishing the accomplishments of others. But if you need to feel important, then I guess your post is like therapy for you or something...
Life is too short to be a snob.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
What I would like to see is an article about reinstalling a large scale ecommerce solution w/ mod_perl & apache.
http://www.michaelmoore.com/2001_1008.html
Anyone got a big site running on mod_python or mod_snake? Care to post some stats?
Thanks!
Alex.
Interactive Visual Medical Dictionary
My personal favorite bit is the way you can suddenly create a new instance variable on a whim, just by assigning a value to
$this->varName, halfway down a random function.
Oh, actually my favorite bit is the way a piece of code will start referring to the value stored in a local variable that has never been declared or apparently assigned anywhere previously, and eventually you find out that it has been created out of thin air, because earlier it was passed as an argument to a function that took the parameter by reference.
Or the way that php's idea of variable typing is that if you perform a string operation on an array it has a habit of overwriting the array with the string "Array" rather than, oh, I don't know, a compile time error?
I find features like that really help code maintenance.
Over to SourceForge there is a project called Minti. What it was was an application server that we had developed which could handle catalog's, ecomerce, banners, general searches, administration, authorization and a bunch of other goodies. The lead programmer built the engine while the rest of (3 co-workers) us worked on different modules. We basically wrote our own mark-up to get data from a mysql database onto a site. www.swimpools.com is one example of a site we as a small group built with our tools.(you won't see any code if you veiw the source because it is parsed out and replaced with its data) I just find it neat what a small group of guys can do with a little perl and some data.
Well, this shows that Apache and mod_perl have the speed, performance, configurability, etc, to get the job done. Why do we see so many Microsoft/ASP web sites?
I think that it's due to marketing. If the open source movement paid for advertising, publicity, etc, then a lot more people would consider the open source alternative, but they opt for the large company with marketing, and reps, and so on....
Note to ACs: I won't mod you up, even if you are being funny or insightful. So take a chance! It's not real life!
What a bunch of fools. Sitting in their cubes thinking they are really k00l d000dz while management loots the company. Did these idiots get golden parachutes? Did they get severance?
My personal favorite bit is the way you can suddenly create a new instance variable on a whim, just by assigning a value to $this->varName, halfway down a random function.
This, and I would think to say that all your piss-poor examples of why Perl is bad are cured with one statement:
Stop spreading FUD. I've seen and worked with many large, OO and non-OO Perl scripts which are a joy to maintain. You can get bad code in any language. Perl lets you shoot yourself in the foot if you want to. My personal preference is not to hire these types of programmers instead of complaining that the language is too flexible.
I'm a bit late here, but I can't see how many 'nodes' they have. 7000 - 20000 orders per hour, or whatever other stats they throw up, just isn't impressive unless I know how many machines (and their power) handle that. 5-10? Probably impressive. 100? Probably not. Anyone got any more info?
creation science book
E-Commerce + Perl = security disaster.
To keep your ecommerce secure you gotta use a
framework that has a solid security model. Build
it with JSP, EJBs, and JDBC. Really scary to think
an ecommerce site would use Perl or PHP on the
server side. Yikes.
Things like Perl, ASP, ColdFusion scripts, etc.
that don't implement "least privilage" can allow
hackers to take over the whole server.
Check one of the bug lists to get the stats
showing the numbers of Perl security bugs...
Ah, so that's where I've been going wrong. I should write use strict; at the top of my PHP programs. And foolishly it seems I've been running my PHP scripts through the Zend engine, whereas I should probably run them through the Perl interpreter.
Come on, if you're going to flame me, at least make sense. I replied to a post about PHP, gave some PHP code examples as to why PHP is bad, and you've come back with that Perl users' mainstay: use strict;
Did you even read my post before you wrote this?
If your problem is even moderately interesting, there will be no out-of-the-box solutions.
I hope that by now, e-commerce should not be an interesting problem at all. It's a standard business practice that ought to have simple (and secure) OotB solutions.
Ok, I'm going to try you on this. Reason is, I've written fairly serious server code in Java, and didn't use many "application server" facilities, because I didn't see the advantage.
Container managed persistance
Far as I can tell, this saves you writing some trivial SQL statements. Plus, as soon as you have any interesting data (ie, not just one row in a table) or performance needs (this is backed up by benchmarks by an experienced app-server user), container manager persistence is impractical anyway, so you have to learn how to do it yourself.
transactional support
Unless you have some exotic need, a transactional data store is the beginning and the end of the solution.
message queues
Easily implemented over an SQL database (I wrote some pseudo-code, but it's too hard to format in slashdot).
naming and lookup services
I know Java has some facilities for this, but what do they do that's not easy with LDAP or similar?
Integration with existing business objects and processes?
You'd be surprised how many of these are already in Perl. :-) That aside, most of this means accessing an SQL database. I mean, sure, Java will integrate better with a Java shop and other Java software, if that's important.
They pulled off clustering
Pretty easy with a remote data store.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I think you're over-stating the necessity of these things. Container managed persistence is often a way to replace one short SQL statement with 3 long XML files. Message queues are trivial in a good database (Oracle). Naming and lookup services are need if you're using EJBs, but we didn't need EJBs.
They pulled off clustering for eToys, but it was hardly an out of the box solution.
How do you define out of the box? We didn't do much work beyond the custom programming that was needed for our application. The open source components filled in our anfrastructure needs very nicely. It wasn't a "packaged solution", but it was easier than many commercial packages I've had to use in the past.
So, what happens when you have a request coming from behind an iptables firewall (or something else that does this) using "iptables -A POSTROUTING -s $INTERNAL -j SNAT --to 10.1.1.1-50" (assuming I didn't mangle the syntax) and thus have requests that rotate through the 10.1.1.1 to 10.1.1.50 IP range? This is fairly common, and breaks things that depend on the remote IP for session tracking.
This is cool, and I like perl, if only for while(<>), but I really don't see the application described as having an enterprise architecture, and this is where maintainability is really an issue.
Separating code into MVC layers is a good start, but the real issue is the interfaces between M and V and between V and C. The article really made it sound like these components were coupled pretty tightly. That's not perl's fault, and Java as a language doesn't really offer an special tools for a clean separation, but I think Sun has done a good job of spec'ing out how these interfaces should work, even if you don't like Sun's licensing practices.
Why is this important? I like writing code, and I always prefer to build rather than buy, but sometimes you just need to buy shit, or use an open source thing, or whatever. If my persistence layer (for example) is written to a standard API like JDO, I can swap in a different implementation whenever necessary.
What if eToys had survived the dot-com implosion, and bought or were bought by another company? How well would this system plug into (or be plugged into) any special-needs components of the new system? That's the real acid test of maintainability in the large.
Maybe these standards exist for perl, and I haven't used it enough in an enterprise context to stumble across them. However, you can't help but stumble across the J2EE stuff when you work with Java. Are these standards perfect? No. Are they complete? No. But they're standards, and that's what makes pluggable components possible.
Come on, if you're going to flame me, at least make sense. I replied to a post about PHP, gave some PHP code examples as to why PHP is bad, and you've come back with that Perl users' mainstay: use strict;
I did read your post; I noticed that you had one reference to PHP in there, and I also took into account the subject line and came to the conclusion that you were knocking both Perl and PHP, as Perl has some of the same problems (creating variables out of thin air and silent conversion between incompatible types mainly) as PHP. It was a thought-out flame. Honest.
If you are just selling products in a plain way, you can get simple enough e-commerce. But if you want to provide good e-commerce that ties in with other content, again there are no out-of-the-box solutions. Also, you have to be happy with a out-of-the-box appearance, where you get to control a few graphics and colors on the page, but the essential layout is fixed. It's usually (but not always) pretty easy to change layout -- but that's still not really out-of-the-box.
eToys had at least four types of nodes: static page servers, dynamic page builders, search servers, database servers. If memory serves, the numbers were like (20, 40, 20, 2). The static page and search server numbers were excessive since they were never stressed by Christmas loads. Except for the database servers, these were all twin P450's. I would argue that handling the third highest e-commerce traffic on the web with less than $80,000 in PCs and no licensing cost (except database) is big bang for the buck.
I think the point he was making was perfectly valid. Perl is not a less real or useful language than C++/Java, but I think anyone would agree that there is a huge paradigm difference in how one goes about coding similar applications in these different languages. Personally, I learned C as my first "real" computer language (ie actually USED, unlike Pascal and BASIC -- this was pre VB).
For me, at least, making the paradigm switch from C to C++ took me forever. I was also self-taught, no CS education to speak of. I took two programming courses and ended up teaching them both -- something I know you can relate to.
Perl I learned in a week, well enought o code on a production system. I can only assume though if I hadn't had the OO knowledge and the procedural experience both, I wouldn't have been able to function in Perl quite so easily. Likewise, if I'd started with Perl, I can only imagine that it would have taken me forever to switch my mode of thinking to be able to code efficiently in Java/C++.
If I were hiring for a company, I'd make damn sure that if the hiree didn't have a CS education, they at least had serious experience with botha procedural language and an OO language and demonstrated ability to think and code effectively in both paradigms.
Yes, I am classifying Perl as a procedural language here. Yes, it supports many OO features, but at least here it's used mainly for things that lend themselves better to procedural thinking than OO.
Interchange (ic.redhat.com) is much better. :-)
Daniel
That's only useful if the "s///" operator controls an inner loop. If you have a program where the high-speed loop is the outer loop, like a parser, that trick doesn't help.
Go read the comments for HTML::Parser before the C version.
This still doesn't seem that impressive. I mean, the SIZE of it is, but it doesn't really 'prove' Perl (or anything else) is 'scaleable'. The design approach is scaleable, with enough money.
:)
If they really were doing 2 million page views per hour, that's about 600 page views per second. Across even JUST the 40 'dynamic page builder' servers, that's 15 pages/second. If you include the reported 20 static page servers, you get 600/60 = 10 pages per second. Certainly nowhere near taxing on a dual P450, ime.
What this really points out is that people need to spend more time engineering solutions rather than buying 'scaleable enterprise fill-in-the-blank' for hundreds of thousands of dollars. Again, just mho.
creation science book
No, what you're doing now is trying to convince us that your wildly off topic rant is somehow is ON TOPIC. Thanks for playing, though.
Why didn't they use mod_perl's Apache::Registry mode? Was there a particular programming practice that prevented switching easily?
--LP