There's a very large difference between source code and content.
No there isn't. HTML == code == text. Articles are text, just like C++ code is text. Graphics are binaries, which CVS can also handle.
Managing all that with CVS on an Enterprise scale (Business Foo with 250 employees) would be hell.
It would be the same hell that managing it with TeamSite is.
rsync has absolutely no notion of what defines a site. rsync doesn't guarantee that all assets published are archived and accounted for. rsync doesn't allow for content rollback.
Right. You check out what you want from CVS, and then rsync it to the target servers. It can all be wrapped up in a tiny Perl or shell script. You can easilly check out older versions, alternate branches, tagged releases, etc. from CVS and rsync those instead.
CVS has no semblance of workflow. CVS allows for rather large collaborations, but it's up to the developers (with or without sourceforge) to structure those collaborations.
That's true. TeamSite doesn't either until you program it to.
Um, have you every used Interwoven's products? What they mean by "wherein the staging area is adapted to receive web content changes of files modified in the work areas and is configured to check for conflicts in web content received from two or more work areas" is that when you check stuff in, it shows up in the shared code. Wow! That's basic CVS. I don't know where you got this stuff about "a system to quickly and directly retrieve content for a web site/application" from, but what TeamSite offers is just a way to sync the repository to a remote server. It's basically a very inefficient version of rsync.
Scripting languages do very well with RDBMS systems. Messaging middleware vendors provide a C API which is then wrapped in a scripting interface. There are very very few real world problems that actually benefit from distributed objects, as opposed to a much simpler parallel load distribution and failover system.
Some scripting languages, like Perl or Python, have gone to greater lengths to provide the necessary tools for building large programs. These usually center around OOP. Inexperienced programmers using those languages may not be familiar with these features or concepts and thus will tend to write less maintainable code. It's not because the features aren't there.
Working with 100+ developers on a project in any language is going to be pretty painful. It's no worse in a good scripting language than it is in Java/C++/C#.
In what way would Java have helped? It's not as if there was a an existing application like Slashdot, especially at the time Slashdot started. Performance between mod_perl and a fast Java servlet container are basically equivalent, and coding in Perl is quite a bit faster than coding in Java. Moreover, coding Slashdot in Perl enabled some people with a dream but not a lot of experience to build something that many have enjoyed. It's unlikely this would have happened so easilly in Java.
It might also be because when you have the code you can actually fix problems. I have seen showstopper bugs in open source systems fixed pretty quickly in-house by some solid debugging. When similar things happen with closed-source stuff, we always end up having to work around it, usually to the detriment of the overall system.
Re:XML is NOT just text!
on
XML and Perl
·
· Score: 3, Insightful
I work at a large company that is converting an existing e-commerce app to IBM WebSphere. I pushed for Linux, IBM pushed for AIX. They talked down Linux scalability, and basically spread open source FUD. There certainly are some people at IBM who support open source, but they don't work in sales.
He says you should avoid tying up database connections in processes that aren't using them. With mod_perl we do this by using a reverse proxy. You could do the same with PHP. He also says you should cache. Well, duh. It just seems odd how he puts this in terms of "Java saved us" when in fact these techniques are universal and any experienced developer would be using them by now.
I work in Soho, and I ripped about 8 of these off the sidewalks around my building the night they were put up. If our own Department of Justice has found Microsoft to be a criminal organization, why should I have to look at their crap when I go out for a cup of coffee? It's offensive.
Caching data, as opposed to just caching generated HTML, allows you to reuse that data in other pages, some of which can't be cached. For example, I worked on an application where we would cache data from a product catalog and use that data in the browsing pages, the shopping cart, the gift registry, etc.
A good system will allow for caching of both data and generated HTML.
I disagree. It is better organized and more clearly presented than most of the on-line documentation, and it provides more examples. It also shows how to do things that are not discussed anywhere else, like automatically caching the output of a content handler. It's a very handy book to have.
My experience with commercial load-testing apps is that they are outrageously expensive, a pain to program, don't really scale all that well, and mostly have to run on Windows with someone sitting at the mouse. There are some that work better than others, but the free stuff in this areas is quite good.
I recommend httperf and http_load for banging on lists of URLs really hard. At one place I worked, one of our developers rigged up some shell scripts that would play back log files through httperf and that worked pretty well.
I'm guessing it's the banana leaves that make it take so long. When they put the chicken into an oven, they don't wrap it in wet banana leaves. That's probably lowering the temperature in the chicken considerably.
The last three companies I've worked at had constant problems with Exchange. The users would gladly have swapped it for something else with simple, reliable IMAP mail if they could have just kept their scheduling. Your experience at one company does not change the fact that many companies have problems with Exchange.
3. The Replacement must be able to scale to 10's of thousands of users, in geographically diverse locations.
I've never seen an Exchange installation that can scale to hundreds of users in one location without huge amounts of downtime, both planned and not. On the other hand, I've seen Unix-based mail servers that just work with no problems for years.
If someone just provided a calendar sharing system to go with the strongly supported POP, IMAP, and LDAP we already have, I think that would be enough for most companies to switch.
One small example they used was that the MSFT tools allow you to backtrace a transaction all the way from your HTML front end clear on in to the database with a simple click of a button.
I bet this works just fine until the day when you need to deviate from the Microsoft plan in some way (maybe you have to do some unusual database stuff, or even talk to a non-Microsoft database that your warehouse uses or use something like a dbm file) and then it will all fall apart. People who learned how to use the tools instead of learning how to design and write programs will be lost when this happens. There is no substitute for understanding how things work, and Microsoft usually makes it harder to do that than other options like Perl or Java.
If you can get up in one hour what takes you one week 'learning from scratch'... as well as not having to write *or* maintain tools... isn't that money well spent?
The idea that tools like WebObjects will let you instantly build sites is a myth. Learning enough WebObjects to do anything even a little bit different from their sample applications will take you much more than a week, since it will involve learning Java (or Objective C), SQL, an object/relational mapping system, a suite of development tools, and a development framework that has been expanding for years. Most people want to do something relatively simple on their sites, and can get there a lot faster using a little perl code. Then there's the fact that many sites are hosted on shared web servers that allow CGI but do not allow things like WebObjects.
People who have equivalent knowledge in perl to what it would take to run WebObjects know that nearly everything they need is available for free from CPAN. There's no need to shell out a bunch of money for this stuff.
There is also the book "Elements of Programming with Perl" which has generally been well received. It is not a web-specific book, and assumes no previous programming knowledge.
Re:My Biased Opinion...
on
Perl & XML
·
· Score: 2
How many times would you need XML loaded vs. say a DB, where J2EE has an enormous advantage over perl.
That is complete bull. Perl's database interfaces are at least as fast as Java's if not faster. For most databases they are a thin layer over the C library provided by the database company. They fly.
How about compairing the overall speed of perl's webapp (including its faster XML loading) vs. the speed of the Java webapp (mod_perl vs a good java webcontainer is no contest).
Actually, it's very close, but mod_perl is a little faster. I benchmarked Resin against mod_perl doing a select from an Oracle database and displaying it. Both were fast, but mod_perl was faster. The Resin guys have some benchmarks on their page where they claim that Resin is faster, but the mod_perl code they used in that test has some mistakes in it that slow things down.
I'm DEFINATELY not saying Java is great for everything. BUT, the best tool for large enterprise websites in most cases is Java (well, J2EE).
There are some very large sites out there who would disagree with you. Yahoo and Amazon use a lot of Perl. I don't know of any J2EE sites that handle anywhere near that amount of traffic.
There's nothing terribly wrong with Java. I use it at work almost every day. However, it has no real technical advantage over Perl for building web applications.
Wouldn't the money be better used on projects that not as many people have heard about but that have a lot of potential if they can be completed?
No, the money would be best spent where it will result in the biggest benefit for the community. Perl has proven to be a very popular and very useful project to a large audience of developers. It has attracted some high-caliber programming talent to work on Perl 6. There are only a handful of other projects out there (Apache, Linux) with the same potential for positive impact on the open source programming world. So, Perl offers a better return on your investment than most of the projects that you could help fund.
Slashdot Mirror
No there isn't. HTML == code == text. Articles are text, just like C++ code is text. Graphics are binaries, which CVS can also handle.
Managing all that with CVS on an Enterprise scale (Business Foo with 250 employees) would be hell.
It would be the same hell that managing it with TeamSite is.
rsync has absolutely no notion of what defines a site. rsync doesn't guarantee that all assets published are archived and accounted for. rsync doesn't allow for content rollback.
Right. You check out what you want from CVS, and then rsync it to the target servers. It can all be wrapped up in a tiny Perl or shell script. You can easilly check out older versions, alternate branches, tagged releases, etc. from CVS and rsync those instead.
CVS has no semblance of workflow. CVS allows for rather large collaborations, but it's up to the developers (with or without sourceforge) to structure those collaborations.
That's true. TeamSite doesn't either until you program it to.
Um, have you every used Interwoven's products? What they mean by "wherein the staging area is adapted to receive web content changes of files modified in the work areas and is configured to check for conflicts in web content received from two or more work areas" is that when you check stuff in, it shows up in the shared code. Wow! That's basic CVS. I don't know where you got this stuff about "a system to quickly and directly retrieve content for a web site/application" from, but what TeamSite offers is just a way to sync the repository to a remote server. It's basically a very inefficient version of rsync.
I think I'd rather be "spammed" than "Michiganed."
Some scripting languages, like Perl or Python, have gone to greater lengths to provide the necessary tools for building large programs. These usually center around OOP. Inexperienced programmers using those languages may not be familiar with these features or concepts and thus will tend to write less maintainable code. It's not because the features aren't there.
Working with 100+ developers on a project in any language is going to be pretty painful. It's no worse in a good scripting language than it is in Java/C++/C#.
In what way would Java have helped? It's not as if there was a an existing application like Slashdot, especially at the time Slashdot started. Performance between mod_perl and a fast Java servlet container are basically equivalent, and coding in Perl is quite a bit faster than coding in Java. Moreover, coding Slashdot in Perl enabled some people with a dream but not a lot of experience to build something that many have enjoyed. It's unlikely this would have happened so easilly in Java.
It might also be because when you have the code you can actually fix problems. I have seen showstopper bugs in open source systems fixed pretty quickly in-house by some solid debugging. When similar things happen with closed-source stuff, we always end up having to work around it, usually to the detriment of the overall system.
Sure smells like text to me.
I work at a large company that is converting an existing e-commerce app to IBM WebSphere. I pushed for Linux, IBM pushed for AIX. They talked down Linux scalability, and basically spread open source FUD. There certainly are some people at IBM who support open source, but they don't work in sales.
He says you should avoid tying up database connections in processes that aren't using them. With mod_perl we do this by using a reverse proxy. You could do the same with PHP. He also says you should cache. Well, duh. It just seems odd how he puts this in terms of "Java saved us" when in fact these techniques are universal and any experienced developer would be using them by now.
Perl added a non-greedy matching operator several years ago.
I work in Soho, and I ripped about 8 of these off the sidewalks around my building the night they were put up. If our own Department of Justice has found Microsoft to be a criminal organization, why should I have to look at their crap when I go out for a cup of coffee? It's offensive.
I don't see how "any hot F's want 2 chat?" could be construed as an essay.
A good system will allow for caching of both data and generated HTML.
I disagree. It is better organized and more clearly presented than most of the on-line documentation, and it provides more examples. It also shows how to do things that are not discussed anywhere else, like automatically caching the output of a content handler. It's a very handy book to have.
PHP is fine, but it's not as fast as mod_perl.
I recommend httperf and http_load for banging on lists of URLs really hard. At one place I worked, one of our developers rigged up some shell scripts that would play back log files through httperf and that worked pretty well.
If you want to record browser sessions for testing specific paths through the site, look at http-recorder or roboweb. There's also webchatpp, HTTP::WebTest, and HTTP::MonkeyWrench on CPAN. More info on this can be found on the mod_perl mailing list or on PerlMonks.
I'm guessing it's the banana leaves that make it take so long. When they put the chicken into an oven, they don't wrap it in wet banana leaves. That's probably lowering the temperature in the chicken considerably.
The last three companies I've worked at had constant problems with Exchange. The users would gladly have swapped it for something else with simple, reliable IMAP mail if they could have just kept their scheduling. Your experience at one company does not change the fact that many companies have problems with Exchange.
I've never seen an Exchange installation that can scale to hundreds of users in one location without huge amounts of downtime, both planned and not. On the other hand, I've seen Unix-based mail servers that just work with no problems for years.
If someone just provided a calendar sharing system to go with the strongly supported POP, IMAP, and LDAP we already have, I think that would be enough for most companies to switch.
I bet this works just fine until the day when you need to deviate from the Microsoft plan in some way (maybe you have to do some unusual database stuff, or even talk to a non-Microsoft database that your warehouse uses or use something like a dbm file) and then it will all fall apart. People who learned how to use the tools instead of learning how to design and write programs will be lost when this happens. There is no substitute for understanding how things work, and Microsoft usually makes it harder to do that than other options like Perl or Java.
The idea that tools like WebObjects will let you instantly build sites is a myth. Learning enough WebObjects to do anything even a little bit different from their sample applications will take you much more than a week, since it will involve learning Java (or Objective C), SQL, an object/relational mapping system, a suite of development tools, and a development framework that has been expanding for years. Most people want to do something relatively simple on their sites, and can get there a lot faster using a little perl code. Then there's the fact that many sites are hosted on shared web servers that allow CGI but do not allow things like WebObjects.
People who have equivalent knowledge in perl to what it would take to run WebObjects know that nearly everything they need is available for free from CPAN. There's no need to shell out a bunch of money for this stuff.
There is also the book "Elements of Programming with Perl" which has generally been well received. It is not a web-specific book, and assumes no previous programming knowledge.
That is complete bull. Perl's database interfaces are at least as fast as Java's if not faster. For most databases they are a thin layer over the C library provided by the database company. They fly.
How about compairing the overall speed of perl's webapp (including its faster XML loading) vs. the speed of the Java webapp (mod_perl vs a good java webcontainer is no contest).
Actually, it's very close, but mod_perl is a little faster. I benchmarked Resin against mod_perl doing a select from an Oracle database and displaying it. Both were fast, but mod_perl was faster. The Resin guys have some benchmarks on their page where they claim that Resin is faster, but the mod_perl code they used in that test has some mistakes in it that slow things down.
I'm DEFINATELY not saying Java is great for everything. BUT, the best tool for large enterprise websites in most cases is Java (well, J2EE).
There are some very large sites out there who would disagree with you. Yahoo and Amazon use a lot of Perl. I don't know of any J2EE sites that handle anywhere near that amount of traffic.
There's nothing terribly wrong with Java. I use it at work almost every day. However, it has no real technical advantage over Perl for building web applications.
No, the money would be best spent where it will result in the biggest benefit for the community. Perl has proven to be a very popular and very useful project to a large audience of developers. It has attracted some high-caliber programming talent to work on Perl 6. There are only a handful of other projects out there (Apache, Linux) with the same potential for positive impact on the open source programming world. So, Perl offers a better return on your investment than most of the projects that you could help fund.
Exactly, and that would be Perl on Unix. That got it right before Microsoft knew there was such a thing as HTTP.