As a contractor I completely disagree with this. We do B get the short end of the stick. We very definitely get a better end of the stick than most permanent employess. Simply put: We get paid better and don't have to put up with the crap I have to put up with. The same goes for temps. If we get abused we leave. Often taking key corporate knowledge with us. The company that abuses a contractor will get what is coming to them.
If these temp workers (contractors, whatever - the principal is the same - higher pay because of the instability) want the benefits bestowed on permies they should use thier higher wage to B for those benefits. Those 15% employee discounts aren't available because employees took the risk to join the company. Contractors don't want that risk (it's funny how the "risk" has turned around - it used to be more risky to be a contractor - that's just my biased opinion though I guess).
I don't think MS is saving a buck or two in this case - I seriously think they're doing what most companies do - paying through the nose for contractors because that extra pay gets them some extra benefits (instant hire/fire, highly knowledgable workers, etc).
I'm the developer of O'Reilly WebBoard's NNTP server. I do all the development at home on Linux and Sybase. The product ships on MS SQL Server 7 (or 6.5). It does take a little bit of work to make the two compatible, but not much. However I suspect it's an awful lot easier going from Sybase to MS SQL than the other way around, YMMV. However ultimately I doubt very much the licence for the package will allow you to change db like that - you'll lose all support.
Try a nightly build of mozilla. It won't support SSL, and some of the bugs are irritating, but it's currently my main browser as of the M13pre releases. I won't go back to Netscape (except when I need authentication or SSL) now.
"For quick and dirty sites, and if you already love Perl, then mod_perl is fine (personally I think PHP is easier)."
Oh I hate this sort of flamebait. I've built a few non-quick and dirty sites in mod_perl. They've been n-tier. They've been maintainable. And they ran well too. You can write crap in any language. Provided you stay away from Apache::Registry or Apache::PerlRun, then your n-tier ideas and object oriented way of working will be practically unavoidable in mod_perl. Same as in servlets+EJB.
"mod_perl will handle it as far as execution is conserned, but a n-tier, engineered application will create a better solution."
OK, so write an n-tier application. You can do that in mod_perl or servlets. mod_perl is not all about speeding up CGI's. If you think it is, then you're missing the best damn web tool around. Sadly, slashdot thinks it's just about speeding up CGI's.:)
Base your decision on 1 point and 1 point only: Who is going to develop and maintain your site (and what are their skills). Both tools are adequate. Both tools have excellent XML capabilities. Both tools have superb database access classes. Both tools support object oriented coding and separating the presentation layer. Only one of those tools is controlled by Sun (OK, that was flamebait:))...
Read the context though. The whole question is about mod_perl or servlets. In that context, "which" becomes "which (mod_perl or servlets)". So please don't give us biased benchmarks. If you have benchmarks to give comparing mod_perl to servlets (and not using Apache::Registry), then I'd love to see them.
Re:How do you take apart requests without ::Regist
on
Mod Perl or Servlets?
·
· Score: 2
Taking apart requests is really really simple. You can either do it yourself (rip the code out of CGI.pm if you want to - it's only about 40 lines if you ignore the extraneous crap), or use the aprequest library and Apache::Request, which is on CPAN in DOUGM's directory (called libapreq IIRC). Read the book. It's all there.
Personally I think that Y2K was an averted tradgedy, although like many I reserve judgment until at least the end of March (end 1Q 2000) for all reports and financial information to be run. Then we'll know for sure the extent of the damage. I do think certain companies will be looking red in the face about their predicted "damage estimates".
However mostly I'm just glad it's over. Finally IT departments can again devote thier IT budgets to truly interesting projects, not these dumb patch and fix projects. I've been personally affected by this phenomenon - having spent 2 months out of work in 1999.
I work purely with mod_perl, so I won't disservice you with biased rumblings of how I think mod_perl is better - follow the advice of another poster here: Pick whichever tool your company/team has more experience with, and feels most comfortable working with. That's the only decision that should matter. Good perl people are expensive (as are good Java people - but the perl ones are harder to find/employ) though.
My tip is simply if you go the mod_perl route, please don't pick the no-brainer Apache::Registry route (this is a CGI-emulation mode). It will just in the long term cause you more troubles than it's worth. If you're working on an application complex enough to require choosing between either mod_perl or servlets then it's large enough to sit down and design it well. First design it without even thinking about the language: Think objects. Then work that into mod_perl. And use the mod_perl API to the full - there are some very cool things in there, like the $r->notes and $r->pnotes methods.
Also, mod_perl is far more than just a way to develop applications. You can do anything you can imagine to the actual Apache server with mod_perl - which makes it an indispensible tool for sysadmins. Witness Randall Schwartz's recent web techniques column on stopping naughty IE5 offline downloaders from sucking all available bandwidth, all done in mod_perl. (may not be available on stonehenge.com yet - try the mod_perl mailing list archives).
Finally, buy some books:
"Writing Apache Modules in Perl and C" by Doug MacEachern and Lincoln Stein. Excellent guide to everything mod_perl.
"Object Oriented Perl" by Damian Conway. Superb guide to doing things right the OO way in perl.
Everyone knows this is complete and utter rubbish. Santa uses magic to get around to everyone - science just can't explain this one. Jeeez - don't they teach you anything in high school?
I've been developing an app that relies completely on styles for changing it's display properties. Sadly some things just didn't work out right when I followed the CSS1 spec to the letter in IE5 (e.g. the "white-space: nowrap" style didn't work in td tags - you have to revert to the HTML 3.2 nowrap tag instead... bah!). However I decided to check out the output in Mozilla. Works beautifully. All styles are rendered exactly as described in the CSS spec. This is an incredible boon for me.
However... of course this won't mean we can just develop web sites to the full CSS spec. Unfortunately those older browsers still exist, and often don't even degrade properly. IE4/5 now seems to have a 60% market share (or something like that).
Mozilla requires Java 1.3 for it's OJI (Open Java Interface). Currently Java 1.3 is available only in beta, but that should change before mozilla is released.
I have to say that mozilla already beat your comment. I've been using the pre-12's for a few days now, and it rocks. Barring a few scrolling problems, freshmeat and slashdot render instantly. The only issue now is waiting for the cache to be plugged in (apparently Intel is working on an advanced cache for Mozilla) and for a few stability issues to be fixed. Otherwise it's looking really great. Kudos to the developers.
I hear on the grapevine (actually at www.nedit.org) that NEdit 5.1 will be GPL'd and the next step is to make it a GTK application instead of Motif. Fantastic news if you ask me - nedit is the most kick-ass text editor on Unix IMHO.
Only really bad db driven web sites use changing content on static url's - almost every site that runs off a db (take those news sites you mention: cnn, news.com, cnbc, etc) redirects you to the content page which is either a unique identifier or a url with an embeded date. I see no reason why that can't be indexed - and in fact it is indexed.
As someone raised in York, I have to correct you - it's York Minster.
Personally I don't particularly view it as "interfering" (I know that's not the gist of what you're saying, but you do mention it as interfering). The Church has as much right to free speech on this and all other matters as anyone else. Sometimes they do interfere, and cross what I consider boundaries. I don't consider this one of those boundaries.
Section 5 prevents other people from charging a fee for your work, not you from charging a fee for your work. The idea is to prevent someone just packaging it up and selling it without modifications.
Nothing forces you to rename whole applications to use GPLed apps! You can ship Perl with your application; you just have to provide the source code to Perl if requested.
I was talking about the artistic licence when distributing highly modified version of perl (or other AL licensed product). I don't have to provide the source code if I simply rename the app to "myperl" according to section 3c and/or 4c of the license (of course I have to say what I've changed from the original in my source, but no-one else ever has to see that). I also have to ship the original - but if it's openly available anyway I don't see how that works, but I do it anyhow to comply.
There seem to only be landmines in the GPL if you ask me (of course those landmines don't exist if you understand the licence - but that's not the point). The AL is very commercial friendly - you can modify your perl, and ship it with your product, provided you rename it to be "myperl" or something. Been there - done that. Very useful and I thank Larry greatly for not making Perl GPL'd.
I also thank the numerous CPAN contributors who have made libraries that I can include in commercial work (I am also a CPAN contributor), add proprietary extensions to, and otherwise modify to my hearts content. Without this licence my work wouldn't be possible.
Seriously - read the subject. OOPerl is an amazing book - perhaps the only perl book you'll need. It's very concise, very clear, and the code you end up producing is clean code, not unlike Java or Python code.
Really though you're trolling. Sure there are things wrong with perl (like the fact that the second argument to bless isn't mandatory), but you can create crap code in any language. If you have experience of building a large app in perl and it all went horribly wrong because it got too large - you only have yourself to blame.
From what I've heard (correct me someone if I'm wrong) XSLT isn't going to happen in mozilla for release. But you can do anything you like within the bounds of CSS + DOM + Javascript (see a long thread about this on xml.com).
Having said that - I think XSLT will come very quickly after release. There's already (IIRC) IBM and Sun working on implementing XSLT within mozilla, so I suspect a plugin will come fairly soon.
The GPL is not appropriate for all documentation - specifically programming language tutorials. Picture someone at company X using this tutorial, say perlipc.pod (assuming that was a GPL'd tutorial - which it isn't), as a starting point for the IPC part of his perl application. He takes the code, and adds huge amounts to it (ie the bulk of his application). Suddenly he realises - one small piece of his code, taken from a tutorial, is GPL'd (because the tutorial itself is GPL'd). Suddenly his whole app has to be GPL'd because the GPL requires this. That's a bad thing, simply because he didn't really think this was a choice he was making. Who considers the licence on examples we copy from books? That sort of thing should be really free - public domain or some other licence that would allow this (the AL comes to mind).
I know this rant belongs to Tom C, but I feel the same.
However some docs can be GPL'd without this worry. I can't really see this affecting the CVS book for example - it's not like it's a programming language. Unless it contains C code examples (which I doubt it does).
Without this small hack of a utility bringing peoples changes to widely distributed sources would be a never ending pain. Of course patch isn't perlfect (yes, I did spell it wrong on purpose:)), but it does a damn fine job under the circumstances, and is used by an awful lot of people - myself included. Thanks Larry.
Things I don't consider hacks: Linux 2.0+, emacs, XFree (!), enlightenment, gnome, kde.
I'm running it on Linux (P133, 64Mb) and it's also dog slow compared to Netscape. Removing debugging might speed it up a bit, but there are a fair few speed related bugs in bugzilla now so I don't think that's really the issue.
Slashdot Mirror
Content-type: text/pod
As a contractor I completely disagree with this. We do B get the short end of the stick. We very definitely get a better end of the stick than most permanent employess. Simply put: We get paid better and don't have to put up with the crap I have to put up with. The same goes for temps. If we get abused we leave. Often taking key corporate knowledge with us. The company that abuses a contractor will get what is coming to them.
If these temp workers (contractors, whatever - the principal is the same - higher pay because of the instability) want the benefits bestowed on permies they should use thier higher wage to B for those benefits. Those 15% employee discounts aren't available because employees took the risk to join the company. Contractors don't want that risk (it's funny how the "risk" has turned around - it used to be more risky to be a contractor - that's just my biased opinion though I guess).
I don't think MS is saving a buck or two in this case - I seriously think they're doing what most companies do - paying through the nose for contractors because that extra pay gets them some extra benefits (instant hire/fire, highly knowledgable workers, etc).
I'm the developer of O'Reilly WebBoard's NNTP server. I do all the development at home on Linux and Sybase. The product ships on MS SQL Server 7 (or 6.5). It does take a little bit of work to make the two compatible, but not much. However I suspect it's an awful lot easier going from Sybase to MS SQL than the other way around, YMMV. However ultimately I doubt very much the licence for the package will allow you to change db like that - you'll lose all support.
Try a nightly build of mozilla. It won't support SSL, and some of the bugs are irritating, but it's currently my main browser as of the M13pre releases. I won't go back to Netscape (except when I need authentication or SSL) now.
"For quick and dirty sites, and if you already love Perl, then mod_perl is fine (personally I think PHP is easier)."
:)
:))...
Oh I hate this sort of flamebait. I've built a few non-quick and dirty sites in mod_perl. They've been n-tier. They've been maintainable. And they ran well too. You can write crap in any language. Provided you stay away from Apache::Registry or Apache::PerlRun, then your n-tier ideas and object oriented way of working will be practically unavoidable in mod_perl. Same as in servlets+EJB.
"mod_perl will handle it as far as execution is conserned, but a n-tier, engineered application will create a better solution."
OK, so write an n-tier application. You can do that in mod_perl or servlets. mod_perl is not all about speeding up CGI's. If you think it is, then you're missing the best damn web tool around. Sadly, slashdot thinks it's just about speeding up CGI's.
Base your decision on 1 point and 1 point only: Who is going to develop and maintain your site (and what are their skills). Both tools are adequate. Both tools have excellent XML capabilities. Both tools have superb database access classes. Both tools support object oriented coding and separating the presentation layer. Only one of those tools is controlled by Sun (OK, that was flamebait
Read the context though. The whole question is about mod_perl or servlets. In that context, "which" becomes "which (mod_perl or servlets)". So please don't give us biased benchmarks. If you have benchmarks to give comparing mod_perl to servlets (and not using Apache::Registry), then I'd love to see them.
Taking apart requests is really really simple. You can either do it yourself (rip the code out of CGI.pm if you want to - it's only about 40 lines if you ignore the extraneous crap), or use the aprequest library and Apache::Request, which is on CPAN in DOUGM's directory (called libapreq IIRC). Read the book. It's all there.
Personally I think that Y2K was an averted tradgedy, although like many I reserve judgment until at least the end of March (end 1Q 2000) for all reports and financial information to be run. Then we'll know for sure the extent of the damage. I do think certain companies will be looking red in the face about their predicted "damage estimates".
However mostly I'm just glad it's over. Finally IT departments can again devote thier IT budgets to truly interesting projects, not these dumb patch and fix projects. I've been personally affected by this phenomenon - having spent 2 months out of work in 1999.
I work purely with mod_perl, so I won't disservice you with biased rumblings of how I think mod_perl is better - follow the advice of another poster here: Pick whichever tool your company/team has more experience with, and feels most comfortable working with. That's the only decision that should matter. Good perl people are expensive (as are good Java people - but the perl ones are harder to find/employ) though.
My tip is simply if you go the mod_perl route, please don't pick the no-brainer Apache::Registry route (this is a CGI-emulation mode). It will just in the long term cause you more troubles than it's worth. If you're working on an application complex enough to require choosing between either mod_perl or servlets then it's large enough to sit down and design it well. First design it without even thinking about the language: Think objects. Then work that into mod_perl. And use the mod_perl API to the full - there are some very cool things in there, like the $r->notes and $r->pnotes methods.
Also, mod_perl is far more than just a way to develop applications. You can do anything you can imagine to the actual Apache server with mod_perl - which makes it an indispensible tool for sysadmins. Witness Randall Schwartz's recent web techniques column on stopping naughty IE5 offline downloaders from sucking all available bandwidth, all done in mod_perl. (may not be available on stonehenge.com yet - try the mod_perl mailing list archives).
Finally, buy some books:
"Writing Apache Modules in Perl and C" by Doug MacEachern and Lincoln Stein. Excellent guide to everything mod_perl.
"Object Oriented Perl" by Damian Conway. Superb guide to doing things right the OO way in perl.
Please don't bullshit us with your biased benchmarks of servlets vs Perl CGI. This "Ask Slashdot" is talking about mod_perl vs servlets.
Everyone knows this is complete and utter rubbish. Santa uses magic to get around to everyone - science just can't explain this one. Jeeez - don't they teach you anything in high school?
(posting with Mozilla and proud of it).
It's good. No, it's great.
I've been developing an app that relies completely on styles for changing it's display properties. Sadly some things just didn't work out right when I followed the CSS1 spec to the letter in IE5 (e.g. the "white-space: nowrap" style didn't work in td tags - you have to revert to the HTML 3.2 nowrap tag instead... bah!). However I decided to check out the output in Mozilla. Works beautifully. All styles are rendered exactly as described in the CSS spec. This is an incredible boon for me.
However... of course this won't mean we can just develop web sites to the full CSS spec. Unfortunately those older browsers still exist, and often don't even degrade properly. IE4/5 now seems to have a 60% market share (or something like that).
Mozilla requires Java 1.3 for it's OJI (Open Java Interface). Currently Java 1.3 is available only in beta, but that should change before mozilla is released.
I have to say that mozilla already beat your comment. I've been using the pre-12's for a few days now, and it rocks. Barring a few scrolling problems, freshmeat and slashdot render instantly. The only issue now is waiting for the cache to be plugged in (apparently Intel is working on an advanced cache for Mozilla) and for a few stability issues to be fixed. Otherwise it's looking really great. Kudos to the developers.
I hear on the grapevine (actually at www.nedit.org) that NEdit 5.1 will be GPL'd and the next step is to make it a GTK application instead of Motif. Fantastic news if you ask me - nedit is the most kick-ass text editor on Unix IMHO.
Only really bad db driven web sites use changing content on static url's - almost every site that runs off a db (take those news sites you mention: cnn, news.com, cnbc, etc) redirects you to the content page which is either a unique identifier or a url with an embeded date. I see no reason why that can't be indexed - and in fact it is indexed.
:)
And yes, even slashdot uses this scheme
As someone raised in York, I have to correct you - it's York Minster.
Personally I don't particularly view it as "interfering" (I know that's not the gist of what you're saying, but you do mention it as interfering). The Church has as much right to free speech on this and all other matters as anyone else. Sometimes they do interfere, and cross what I consider boundaries. I don't consider this one of those boundaries.
Section 5 prevents other people from charging a fee for your work, not you from charging a fee for your work. The idea is to prevent someone just packaging it up and selling it without modifications.
Nothing forces you to rename whole applications to use GPLed apps! You can ship Perl with your application; you just have to provide the source code to Perl if requested.
I was talking about the artistic licence when distributing highly modified version of perl (or other AL licensed product). I don't have to provide the source code if I simply rename the app to "myperl" according to section 3c and/or 4c of the license (of course I have to say what I've changed from the original in my source, but no-one else ever has to see that). I also have to ship the original - but if it's openly available anyway I don't see how that works, but I do it anyhow to comply.
There seem to only be landmines in the GPL if you ask me (of course those landmines don't exist if you understand the licence - but that's not the point). The AL is very commercial friendly - you can modify your perl, and ship it with your product, provided you rename it to be "myperl" or something. Been there - done that. Very useful and I thank Larry greatly for not making Perl GPL'd.
I also thank the numerous CPAN contributors who have made libraries that I can include in commercial work (I am also a CPAN contributor), add proprietary extensions to, and otherwise modify to my hearts content. Without this licence my work wouldn't be possible.
Seriously - read the subject. OOPerl is an amazing book - perhaps the only perl book you'll need. It's very concise, very clear, and the code you end up producing is clean code, not unlike Java or Python code.
Really though you're trolling. Sure there are things wrong with perl (like the fact that the second argument to bless isn't mandatory), but you can create crap code in any language. If you have experience of building a large app in perl and it all went horribly wrong because it got too large - you only have yourself to blame.
From what I've heard (correct me someone if I'm wrong) XSLT isn't going to happen in mozilla for release. But you can do anything you like within the bounds of CSS + DOM + Javascript (see a long thread about this on xml.com).
Having said that - I think XSLT will come very quickly after release. There's already (IIRC) IBM and Sun working on implementing XSLT within mozilla, so I suspect a plugin will come fairly soon.
The GPL is not appropriate for all documentation - specifically programming language tutorials. Picture someone at company X using this tutorial, say perlipc.pod (assuming that was a GPL'd tutorial - which it isn't), as a starting point for the IPC part of his perl application. He takes the code, and adds huge amounts to it (ie the bulk of his application). Suddenly he realises - one small piece of his code, taken from a tutorial, is GPL'd (because the tutorial itself is GPL'd). Suddenly his whole app has to be GPL'd because the GPL requires this. That's a bad thing, simply because he didn't really think this was a choice he was making. Who considers the licence on examples we copy from books? That sort of thing should be really free - public domain or some other licence that would allow this (the AL comes to mind).
I know this rant belongs to Tom C, but I feel the same.
However some docs can be GPL'd without this worry. I can't really see this affecting the CVS book for example - it's not like it's a programming language. Unless it contains C code examples (which I doubt it does).
patch.
:)), but it does a damn fine job under the circumstances, and is used by an awful lot of people - myself included. Thanks Larry.
Without this small hack of a utility bringing peoples changes to widely distributed sources would be a never ending pain. Of course patch isn't perlfect (yes, I did spell it wrong on purpose
Things I don't consider hacks: Linux 2.0+, emacs, XFree (!), enlightenment, gnome, kde.
I'm running it on Linux (P133, 64Mb) and it's also dog slow compared to Netscape. Removing debugging might speed it up a bit, but there are a fair few speed related bugs in bugzilla now so I don't think that's really the issue.
I disagree that this bug is the major cause of the slowdown though (and it appears some netscapers do too).
I think it goes deeper than that. My thoughts are that it has to do with the UI marshalling code, but I really don't know enough about it.