Say you have a very common task that, unfortunately, needs to work on a large set of data, but consistently results in only a few rows of data when it has finished going through all the data.
You say that as if it were a common thing. I can't think of why you would ever need to do that unless you were doing a join in your application rather than in the database, which would be a mistake. There are rare occasions when a stored procedure can be useful, but this one is so rare it doesn't bear consideration.
The best book out there on understanding how to make IT teams work well is DeMarco & Lister's "Peopleware." It's a great read and full of advice on how to effectively manage an unruly bunch like us. Going through it, I recognized their suggestions as the traits of the best managers I've had.
The problem with Apache 1.x/PHP/mod_perl/MySQL/PostgreSQL is that the so-called persistent database connection is per-process based.
And how is this a problem exactly? If your server is handling only dynamic pages (your static stuff should be split onto another server) you will almost certainly need a database handle on every request. Connection pooling is only useful if your application spends a lot of time NOT using the database.
Then there is the problem of running out of db connections for any particular process.
Why would a particular process need more than one database connection? Each process only handles one request at a time.
Apache 2.0 is likely to be better in this respect, but I still think that AOLServer is cleaner.
Apache 2 provides full support for threading, so it can use the same approach as AOLServer. It doesn't sound like you know very much about it, so maybe you should check it out before you tell everyone it's no good.
How does Yahoo maintain uptime? They have thousands of Intel servers in racks. Nothing too tricky.
The only thing that's truly proven to be faster than mod_perl is custom-coded Apache modules written in C. You can do that, but it will take you a long time.
Does mod_perl allow for resource sharing between processes?
With perl 5.8, apache 2, and mod_perl 2, you can share resources between threads. With earlier multi-process versions you can use shared memory or disk. On Linux, sharing on disk is very fast since frequently accessed files are kept in memory.
We presented this article at ApacheCon a couple of years ago. It describes how we built an e-commerce site that handled over 2.5 million page views per hour.
If you want to run some commercial software, like Oracle for example, you will probably need to run Red Hat. Some companies support multiple distros, but many only support Red Hat.
It sounds like you may be forgetting that most employees have no stake in the companies they work for and thus no reason to give a damn about whether or not they succeed. Most people understand very well that their companies don't give a fuck about them, and act accordingly. That naive "company man" mentality died a long time ago.
The Slashdot effect is pretty wimpy in the grand scheme of things. I worked at a site that got Slashdotted multiple times. We also got traffic from running an ad on AOL. The traffic from the AOL ad was much greater than the Slashdot traffic. Also, consider the size of the Slashdot servers. They have a small handful of Intel servers running basic Apache stuff. That's not an especially powerful system for serving a site, but they manage to handle this traffic all the time. Obviously the sites getting crushed by this traffic have pretty weak performance.
No one will believe this, but I swear it's true. My girlfriend loves hearing me talk about programming. She has a sort of fetish for smart men, and when I use a bunch of programming jargon it gets her all hot and bothered. When we're in bed she'll ask me to talk to her about Perl or Java while we fool around. I have recently explained the principles of encapsulation and inheritance to her, as well as the binary system, and how the color settings on her Macintosh relate to the number of bits per pixel, all with my hand between her legs. And she loves it!
I never would have believed it if it hadn't happened to me. We used to joke about finding a woman who thought programming was sexy -- now I have one! I am a lucky boy.
I can't even count the number of times some vendor has tried to tell me I need their application server in order to build a "scalable" web site. A company called Kiva (eventually purchased by Netscape) convinced my manager we needed their Java application server. This was before the days of Java servlets being widely adopted, when Java was unbelievably slow and certainly not up to the task of running a busy site. Nevertheless, we plowed ahead and built our site.
One of the lies I remember specifically was when I asked the salesman if their product cached database query results. He confirmed it absolutely. Of course it didn't, which we found out during our training. It also didn't have date formatting in its templating system despite what the documentation said, so we had to build that.
Finally we got the thing into production and it crashed like mad. We never did find out why. Probably something to do with the NSAPI module that handled connections from the Netscape web server to the application server. Even when it wasn't crashing, performance was horrible.
That round of managers eventually left and the whole thing was re-done in mod_perl. Guess what? Stable, fast, easy to work with. Oh yeah, scalable too.
my favorite comment from their regional sales director: "You'll never be able to keep up with your little shareware schemes!" -- this was in response to our use of Apache/mod_perl
That's hilarious, both because LoudCloud doesn't actually do any application development (they are strictly about monitoring and admin'ing), and because they claim to support Apache. I mean, they have stuff like ColdFusion on their list and they're looking down their noses at a rocket like mod_perl? Sad.
Corporations have lawyers on salary who spend their time looking for ways to protect against what they see as attacks on the corporation's reputation. There have been cases reported here where lawyers for some company went after someone in a way that the more Intnernet savvy people at the company would have prevented if they had known about it. A lot of those "cease & desist" letters are done without any approval from upper management. They're just part of the routine for corporate lawyers.
I've also wondered about this, since a large number of the postings in the "Your Rights Online" section seem calculated to incite anger, boycotts, and worse. Businesses are assumed to be liars and ingenuine in all of their statements. There is rarely any consideration given to the fact that the actions being criticized in many cases could be the fault of a single lawyer and do not reflect a general evil on the part of all amazon.com employees, or whoever today's target may be. Sooner or later, this may all come back around.
Isn't it possible that your rewrite was better just because it was a 2nd draft? There's really no reason you can't define interfaces for Perl classes and share them among a group of developers, like you did with your C++ header files.
You might want to reconsider perl as the language of choice for a large scale application. I realize I'm posting this comment to a Perl system, but Perl hangs together like an immense kludge of a language.
What a monstrous Christmas troll you are. What qualifies you to make this judgement? Perl, like any other mature language, has people who write kludges with it and people who write clean, elegant code with it. Your lousy Perl code is not indicative of a language problem.
That said, you're probably stuck with it, and AFAIK, you may be forging new paths in programming for reusability by applying the above concepts to Perl.
And this shows how much you know, since the Perl community is full of activity around design patterns, refactoring tools, unit-testing, and other practices which are in favor among experienced people trying to write solid, maintainable code.
My suggestion for those who are looking for actual useful advice rather than this kind of "throw away all your work and learn Java" crap, would be to head straight for http://perlmonks.org/ and read up. There's tons of advice there for serious Perl coders. You would also do well to start reading the mod_perl mailing list, which often has informative discussions about these issues.
Re:How about OS's that should be brought back?
on
Niche Operating Systems
·
· Score: 1, Offtopic
One of the strange aspects of computing is that everything has to be started from scratch and nobody seems willing to even consider the lessons learned in the past.
This might be partly due to the fact that employers insist on hiring the youngest programmers possible, preferably straight out of college, so that they can work the hell our of them. People who are old enough to remember how things were done before have all been relegated to management positions where they have little effect on the actual code.
While on the surface this sounds entirely good, it leaves some things open to interpretation. What's the feature that makes these sites illegal? Is it the fact that their URLs were close to the URLs of popular sites that young people might visit? That was true for etoy.com. Is it that the sites in question had offensive material on them? The etoy.com site had a picture of the bombed Oklahoma building with the caption "Such work requires careful training" and pictures of women in S&M garb.
It's difficult to draw the distinction without getting into questions of intent, and that's dangerous territory. In short, be careful what you ask for when talking about typo sites.
If you look at sites like http://mediametrix.com/, you'll see tha Slashdot doesn't get enough traffic to put in the top 50 most popular sites. It probably doesn't get enough to put it in the top 500. It's a small site by most measures, and the proof is that they can keep it going with a tiny handful of Intel machines.
The only reason the Java applets idea had a chance was that all browsers were going to support it, and even that didn't happen. Using an unusual plug-in which forces visitors to download and install a Python runtime and wrapper will quickly chase away everyone on your site. If you really need a rich GUI client-server app, there are plenty of better ways to do it than jamming it into a web browser. The browser is just excess baggage at that point.
Slashdot Mirror
You say that as if it were a common thing. I can't think of why you would ever need to do that unless you were doing a join in your application rather than in the database, which would be a mistake. There are rare occasions when a stored procedure can be useful, but this one is so rare it doesn't bear consideration.
I've often suggested that people with noisy mobile phones should "implant" them, but not in their mouths.
The best book out there on understanding how to make IT teams work well is DeMarco & Lister's "Peopleware." It's a great read and full of advice on how to effectively manage an unruly bunch like us. Going through it, I recognized their suggestions as the traits of the best managers I've had.
And how is this a problem exactly? If your server is handling only dynamic pages (your static stuff should be split onto another server) you will almost certainly need a database handle on every request. Connection pooling is only useful if your application spends a lot of time NOT using the database.
Then there is the problem of running out of db connections for any particular process.
Why would a particular process need more than one database connection? Each process only handles one request at a time.
Apache 2.0 is likely to be better in this respect, but I still think that AOLServer is cleaner.
Apache 2 provides full support for threading, so it can use the same approach as AOLServer. It doesn't sound like you know very much about it, so maybe you should check it out before you tell everyone it's no good.
The only thing that's truly proven to be faster than mod_perl is custom-coded Apache modules written in C. You can do that, but it will take you a long time.
With perl 5.8, apache 2, and mod_perl 2, you can share resources between threads. With earlier multi-process versions you can use shared memory or disk. On Linux, sharing on disk is very fast since frequently accessed files are kept in memory.
We presented this article at ApacheCon a couple of years ago. It describes how we built an e-commerce site that handled over 2.5 million page views per hour.
No, the Yahoo games run great on Linux with Mozilla 0.99. I didn't even upgrade Java - just used whatever came with Mozilla.
If you want to run some commercial software, like Oracle for example, you will probably need to run Red Hat. Some companies support multiple distros, but many only support Red Hat.
Actually, mod_perl is out in beta and people have been testing it for a while now.
It sounds like you may be forgetting that most employees have no stake in the companies they work for and thus no reason to give a damn about whether or not they succeed. Most people understand very well that their companies don't give a fuck about them, and act accordingly. That naive "company man" mentality died a long time ago.
The Slashdot effect is pretty wimpy in the grand scheme of things. I worked at a site that got Slashdotted multiple times. We also got traffic from running an ad on AOL. The traffic from the AOL ad was much greater than the Slashdot traffic. Also, consider the size of the Slashdot servers. They have a small handful of Intel servers running basic Apache stuff. That's not an especially powerful system for serving a site, but they manage to handle this traffic all the time. Obviously the sites getting crushed by this traffic have pretty weak performance.
I never would have believed it if it hadn't happened to me. We used to joke about finding a woman who thought programming was sexy -- now I have one! I am a lucky boy.
One of the lies I remember specifically was when I asked the salesman if their product cached database query results. He confirmed it absolutely. Of course it didn't, which we found out during our training. It also didn't have date formatting in its templating system despite what the documentation said, so we had to build that.
Finally we got the thing into production and it crashed like mad. We never did find out why. Probably something to do with the NSAPI module that handled connections from the Netscape web server to the application server. Even when it wasn't crashing, performance was horrible.
That round of managers eventually left and the whole thing was re-done in mod_perl. Guess what? Stable, fast, easy to work with. Oh yeah, scalable too.
That's hilarious, both because LoudCloud doesn't actually do any application development (they are strictly about monitoring and admin'ing), and because they claim to support Apache. I mean, they have stuff like ColdFusion on their list and they're looking down their noses at a rocket like mod_perl? Sad.
Corporations have lawyers on salary who spend their time looking for ways to protect against what they see as attacks on the corporation's reputation. There have been cases reported here where lawyers for some company went after someone in a way that the more Intnernet savvy people at the company would have prevented if they had known about it. A lot of those "cease & desist" letters are done without any approval from upper management. They're just part of the routine for corporate lawyers.
I've also wondered about this, since a large number of the postings in the "Your Rights Online" section seem calculated to incite anger, boycotts, and worse. Businesses are assumed to be liars and ingenuine in all of their statements. There is rarely any consideration given to the fact that the actions being criticized in many cases could be the fault of a single lawyer and do not reflect a general evil on the part of all amazon.com employees, or whoever today's target may be. Sooner or later, this may all come back around.
You can't do that yet. Both mod_perl and mod_php have to be ported to the new Apache 2 API first.
Isn't it possible that your rewrite was better just because it was a 2nd draft? There's really no reason you can't define interfaces for Perl classes and share them among a group of developers, like you did with your C++ header files.
What a monstrous Christmas troll you are. What qualifies you to make this judgement? Perl, like any other mature language, has people who write kludges with it and people who write clean, elegant code with it. Your lousy Perl code is not indicative of a language problem.
That said, you're probably stuck with it, and AFAIK, you may be forging new paths in programming for reusability by applying the above concepts to Perl.
And this shows how much you know, since the Perl community is full of activity around design patterns, refactoring tools, unit-testing, and other practices which are in favor among experienced people trying to write solid, maintainable code.
My suggestion for those who are looking for actual useful advice rather than this kind of "throw away all your work and learn Java" crap, would be to head straight for http://perlmonks.org/ and read up. There's tons of advice there for serious Perl coders. You would also do well to start reading the mod_perl mailing list, which often has informative discussions about these issues.
This might be partly due to the fact that employers insist on hiring the youngest programmers possible, preferably straight out of college, so that they can work the hell our of them. People who are old enough to remember how things were done before have all been relegated to management positions where they have little effect on the actual code.
It's difficult to draw the distinction without getting into questions of intent, and that's dangerous territory. In short, be careful what you ask for when talking about typo sites.
If you look at sites like http://mediametrix.com/, you'll see tha Slashdot doesn't get enough traffic to put in the top 50 most popular sites. It probably doesn't get enough to put it in the top 500. It's a small site by most measures, and the proof is that they can keep it going with a tiny handful of Intel machines.
Um, no, the article says that a re-write is 80% likely to NOT occur before the end of 2002, i.e. only 20% like to occur.
The only reason the Java applets idea had a chance was that all browsers were going to support it, and even that didn't happen. Using an unusual plug-in which forces visitors to download and install a Python runtime and wrapper will quickly chase away everyone on your site. If you really need a rich GUI client-server app, there are plenty of better ways to do it than jamming it into a web browser. The browser is just excess baggage at that point.