Yes, people should absolutely learn MVC and taglibs. But MVC and taglibs are part of standard J2EE, they're not added on by frameworks--so there's still no need to go near any trendy framework-of-the-month.
And it's more like saying "Don't teach ASP.NET 1.0, because it's about to be completely replaced by ASP.NET 2.0." Except, at least ASP.NET is part of the standard, whereas Struts isn't. So it's more like saying "Don't teach WinForms using Mono"...
Right. I think this is key. The anti-spyware and anti-virus software business is all about trust, and it's fairly obvious to me that Microsoft are not strong competitors in that arena.
For example, does Spy Sweeper identify World of Warcraft as the piece of intrusive spyware it is? Does Microsoft's anti-spyware software?
I heard about how bad the Netscape codebase was from a guy who left the company. Mozilla was basically an almost total ground-up rewrite.
Netscape had arrogantly ignored standards and built a "tag soup" parser, then hacked in arbitrary features without regard for long-term supportability, and incompatibly with the standards. They ended up with a codebase that wouldn't let them actually implement web standards properly, once it became clear that they had to in order to compete with Microsoft.
Frankly, Netscape deserved to die. You don't win against Microsoft by playing proprietary feature war.
All the statistics showed that excluding 9/11, the various power grabs were followed by more people being killed by terrorists. So they stopped putting out the annual report...
A breathtaking piece of Argumentum Ad Novitatem, congratulations.
Two years ago people trying to be trendy and teach frameworks would have been teaching Struts. Then Struts 1.0 was put in maintenance mode, and Struts Ti (2.0) was to be merged with Open Symphony. Then Struts 2.0 was forgotten in favor of Shale and JSF.
That's the trouble with trying to be "modern" and "keep with the times"--by the time you've finished teaching the class, the stuff you were teaching is probably abandoned, deprecated or obsolete. Better to teach the fundamentals, and let people pick a web framework when they actually have a need for one.
did some tests and found my 32" Philips CRT draws 120W.
Most LCD computers monitors are around 100W so the power consumption (and thus heat output) are similar.
They must have drastically improved CRTs recently, then. My last CRT was noticably warm if you held your hand above it, whereas none of my LCDs are.
Except the Dyson vacuum cleaner is (a) the #1 selling brand in the UK and USA, and (b) the domestic vacuum cleaner that has the greatest suction according to independent testing.
They are also expensive, unreliable, and break very easily, so they're the perfect model to use to indicate something that sucks really hard.
Then again, my TV probably doesn't count as "large". If you want a 50" behemoth, LCD is still prohibitively expensive.
I initially liked the idea of DLP, but it has some problems:
- On many sets, latency is an issue. This was a killer for me, as I had to be able to play video games on the set.
- The bulbs need replacing, and they're a few hundred bucks each, so the ongoing cost is higher than LCD.
- The sets make noise. I'm really picky about noise, I don't want anything with a fan in the living room.
- The micromirrors don't generally fail, but the high speed rotating bits do.
- The rainbow striping can be a bit distracting.
- Visibility in daylight is problematic.
The downsides of LCDs:
- Contrast ratio not as good as DLP, but getting close.
- Price is high if you want to go over 40".
I don't see response time as an issue on the latest generation of LCDs. Certainly I've had no problem playing ultra-fast racing games. Picture is vibrant, strong saturated colors, and the brightness means there's no problem with daytime viewing. I haven't noticed viewing angle being an issue either, certainly no more so than it is with DLP.
The downsides of plasma:
- Short lifetime.
- Gridlike mask over the picture.
- Can't use it for video games.
- Not a good idea to use it for extensive viewing of letterboxed material.
- Heat, energy consumption.
Downsides of CRT:
- Weighs a ton.
- Energy consumption, heat.
- Takes up lots of space.
- Full of nasty chemicals, you'll pay someone to take it away at the end of its lifetime.
If you need a big screen and can't afford LCD at that size, projection LCD might be an option.
Interestingly, each technology seems to have one company that has a clear lead. Sharp are the technology leaders for LCD. Samsung are the leaders for DLP. Panasonic are the best for plasma. Sony are the best for CRT. I haven't seen enough LCoS sets to conclude who's the leader there...
What I see in people that turn how to program with an IDE is they are tied to that IDE, they dont want to use another. Its like pulling teeth to get them to switch. The other problem they have is they know nothing about the compiler.
Same is true of a lot of people who use Emacs too much. It becomes impossible to get them to even try another program. Introduce them to some new concept like, say, an N-dimensional sparse matrix manipulation system with typed data cells, and they say "So, is there an emacs interface for this?" They read their e-mail in emacs, they read news in emacs, some of them even use emacs as a web browser and shell.
So I'd say start with a text editor. Something simple. For Java, get them at least as far as building a small project with a handful of files into a jar and running it. Then, you can say "So, now you get how it works, here's a tool that can save time and effort..." Then you introduce an IDE. And also Ant, ideally.
Also, I'd say don't force the students to use a particular IDE or editor. That's not the point of the class. If they want to do the assignments using NOTEPAD.EXE, let 'em.
Personally, I thought Java for the Web with Servlets, JSP, and EJB by Budi Kurniawan, New Riders publishing, was really good.
It goes through J2EE systematically, is clear, and has good examples.
I wouldn't introduce frameworks of any kind until you've done the basics of J2EE. Otherwise, you're introducing people to a solution before they know what the problem is.
Also, most frameworks seem to me to be not worth (a) the pain of learning them and (b) the added dependency risks. They do things which simply aren't that hard to do.
Struts is my favorite example. Visit the web site and they throw a ton of complex crap at you, without ever answering the simple question "What compelling problems does this solve?"
The machine was shipped the equivalent of a 4 hour drive. The thing is, there's remote, and then there's really damn remote.
I work from a home office. It saves the company a ton of money without involving any of the headaches of outsourcing to India. And I'm still close enough that I can visit the machines in person if I need to.
Funnily enough, this last week I had a server that was causing problems shipped to my house so I could do setup and testing effectively. Once I've finished soak testing in a day or so, it'll be shipped back to its home for the local network guy to plug it in.
Sometimes there's just no substitute for locality.
A lot of C++ fans here, I see. I offer the perspective of someone who's written C++ and written Java, but who doesn't particularly like either of them.
What Java offers over C++ is robustness. It's designed so that a RAIJP (Redundant Array of Inexpensive/Interchangeable Java Programmers) can write code without creating a ton of memory leaks, null pointers and security exposures. From automatic memory management to mandatory exception handling, most of its features are designed to support that goal.
What Java doesn't offer is much improvement in development speed over C++. Simple tasks often take ridiculous amounts of code, offsetting the gains of automatic memory management.
So... in this case Java is really solving problems that are being introduced by adding offshore developers. So the real question is whether offshore developers are the solution to your problems. I'm guessing they're not.
OK, I'll indulge you. Why sendmail sucks, in a nutshell:
It was designed before Internet e-mail standards were established. As a result, it contains a general purpose rewriting engine that's Turing complete--the idea was it would be able to be configured to translate addresses between BITNET, UUCP, JANET, ARPAnet, CompuServe, FidoNet, and so on, without recompiling the sendmail binary. This was important because back in the 80s, those networks all had different address formats.
Nowadays the ability to arbitrarily rewrite addresses is completely unnecessary, but Sendmail keeps the old design. This leads to a number of major misfeatures.
Sendmail is a pig to configure. The "new improved" sendmail.mc is slightly better than the old sendmail.cf, but still awful compared to the alternatives because it's layered on top of M4, an ancient macro processor. Compare an example postfix config and an example sendmail config. And remember, that's the new.mc file that's compiled into the actual sendmail.cf; if you ever need to do something complex that requires editing the sendmail.cf itself, you'll be faced with something much nastier.
Sendmail has a continuing history of poor security. 16 vulnerabilities between 2000 and mid-2006, according to nvd.nist.gov. By comparison, Exim has had 9, Postfix has had 4, Qmail 3.
Sendmail was designed to parse and reconstruct the header of every e-mail going through it. This makes it brittle--give it something it isn't expecting, and the results are unpredictable. This has resulted in Bcc:ed recipients being revealed to each other, unknown header fields being destroyed, and so on. It also makes e-mail forensics difficult--just because the message looked like it had the right addresses when it arrived, didn't mean it had the right addresses when it was sent, if it has passed through sendmail. MTAs should not rewrite e-mail going through them; only e-mail being passed to them directly by a client.
It has broken behavior when sending to multiple recipients. For example, if the To: field is missing a comma between two addresses, sendmail will send copies of the e-mail to all the addresses that it can parse, then barf on the broken ones. This is unhelpful, because if the user then re-sends the mail, most people end up getting 2 copies.
So in short: it's broken, it's slow, it's insecure, and it's awkward to configure. There are other open source mailers that have a few of those defects, but sendmail is the only one that has them all. Do a search for "sendmail sucks" and you'll find plenty of people with the same opinion as me.
I administered email for a large corporation. I installed, setup, configured, made-route-to-one-another email across Lotes (lotus notes, or should I say "domino" -- wtf with the naming?), exchange & sendmail.
If you picked sendmail for your SMTP e-mailer, that pretty much destroys your credibility right there.
It's like saying "I have extensive experience with RealPlayer, and can say with authority that MP3 is no good..." or "I drive a Chevy Cavalier, and the Ford Focus just isn't a quality automobile..."
Slashdot Mirror
Yes, people should absolutely learn MVC and taglibs. But MVC and taglibs are part of standard J2EE, they're not added on by frameworks--so there's still no need to go near any trendy framework-of-the-month.
And it's more like saying "Don't teach ASP.NET 1.0, because it's about to be completely replaced by ASP.NET 2.0." Except, at least ASP.NET is part of the standard, whereas Struts isn't. So it's more like saying "Don't teach WinForms using Mono"...
Right. I think this is key. The anti-spyware and anti-virus software business is all about trust, and it's fairly obvious to me that Microsoft are not strong competitors in that arena.
For example, does Spy Sweeper identify World of Warcraft as the piece of intrusive spyware it is? Does Microsoft's anti-spyware software?
I heard about how bad the Netscape codebase was from a guy who left the company. Mozilla was basically an almost total ground-up rewrite.
Netscape had arrogantly ignored standards and built a "tag soup" parser, then hacked in arbitrary features without regard for long-term supportability, and incompatibly with the standards. They ended up with a codebase that wouldn't let them actually implement web standards properly, once it became clear that they had to in order to compete with Microsoft.
Frankly, Netscape deserved to die. You don't win against Microsoft by playing proprietary feature war.
So, this Acme editor lets you select any piece of text, and execute it as a shell command, with the results appearing in another window.
Maybe I'm missing something, but if I valued that functionality, I'm pretty sure I could have it in vim with a macro or two.
All the statistics showed that excluding 9/11, the various power grabs were followed by more people being killed by terrorists. So they stopped putting out the annual report...
A breathtaking piece of Argumentum Ad Novitatem, congratulations.
Two years ago people trying to be trendy and teach frameworks would have been teaching Struts. Then Struts 1.0 was put in maintenance mode, and Struts Ti (2.0) was to be merged with Open Symphony. Then Struts 2.0 was forgotten in favor of Shale and JSF.
That's the trouble with trying to be "modern" and "keep with the times"--by the time you've finished teaching the class, the stuff you were teaching is probably abandoned, deprecated or obsolete. Better to teach the fundamentals, and let people pick a web framework when they actually have a need for one.
Huh? I've had absolutely no problems with the regular VMware build scripts, and I run the standard Debian 2.6.15 kernel.
Yeah, but a DLP bulb lasts 2000-3000 hours, whereas the expected lifespan of an LCD backlight is 20,000-30,000 hours.
They must have drastically improved CRTs recently, then. My last CRT was noticably warm if you held your hand above it, whereas none of my LCDs are.
Except the Dyson vacuum cleaner is (a) the #1 selling brand in the UK and USA, and (b) the domestic vacuum cleaner that has the greatest suction according to independent testing.
They are also expensive, unreliable, and break very easily, so they're the perfect model to use to indicate something that sucks really hard.
Documented? Man, don't get me started...
It's Slashdot, you're allowed to say Hentai.
VMware Workstation runs nicely under Debian Testing, with ReiserFS filesystem.
Then again, my TV probably doesn't count as "large". If you want a 50" behemoth, LCD is still prohibitively expensive.
I initially liked the idea of DLP, but it has some problems:
- On many sets, latency is an issue. This was a killer for me, as I had to be able to play video games on the set.
- The bulbs need replacing, and they're a few hundred bucks each, so the ongoing cost is higher than LCD.
- The sets make noise. I'm really picky about noise, I don't want anything with a fan in the living room.
- The micromirrors don't generally fail, but the high speed rotating bits do.
- The rainbow striping can be a bit distracting.
- Visibility in daylight is problematic.
The downsides of LCDs:
- Contrast ratio not as good as DLP, but getting close.
- Price is high if you want to go over 40".
I don't see response time as an issue on the latest generation of LCDs. Certainly I've had no problem playing ultra-fast racing games. Picture is vibrant, strong saturated colors, and the brightness means there's no problem with daytime viewing. I haven't noticed viewing angle being an issue either, certainly no more so than it is with DLP.
The downsides of plasma:
- Short lifetime.
- Gridlike mask over the picture.
- Can't use it for video games.
- Not a good idea to use it for extensive viewing of letterboxed material.
- Heat, energy consumption.
Downsides of CRT:
- Weighs a ton.
- Energy consumption, heat.
- Takes up lots of space.
- Full of nasty chemicals, you'll pay someone to take it away at the end of its lifetime.
If you need a big screen and can't afford LCD at that size, projection LCD might be an option.
Interestingly, each technology seems to have one company that has a clear lead. Sharp are the technology leaders for LCD. Samsung are the leaders for DLP. Panasonic are the best for plasma. Sony are the best for CRT. I haven't seen enough LCoS sets to conclude who's the leader there...
Same is true of a lot of people who use Emacs too much. It becomes impossible to get them to even try another program. Introduce them to some new concept like, say, an N-dimensional sparse matrix manipulation system with typed data cells, and they say "So, is there an emacs interface for this?" They read their e-mail in emacs, they read news in emacs, some of them even use emacs as a web browser and shell.
So I'd say start with a text editor. Something simple. For Java, get them at least as far as building a small project with a handful of files into a jar and running it. Then, you can say "So, now you get how it works, here's a tool that can save time and effort..." Then you introduce an IDE. And also Ant, ideally.
Also, I'd say don't force the students to use a particular IDE or editor. That's not the point of the class. If they want to do the assignments using NOTEPAD.EXE, let 'em.
Look up "Poisson distribution".
Laptop hard drives last 2-3 years. That's just the way they're built. No vendor makes 'em significantly better than that.
Personally, I thought Java for the Web with Servlets, JSP, and EJB by Budi Kurniawan, New Riders publishing, was really good.
It goes through J2EE systematically, is clear, and has good examples.
I wouldn't introduce frameworks of any kind until you've done the basics of J2EE. Otherwise, you're introducing people to a solution before they know what the problem is.
Also, most frameworks seem to me to be not worth (a) the pain of learning them and (b) the added dependency risks. They do things which simply aren't that hard to do.
Struts is my favorite example. Visit the web site and they throw a ton of complex crap at you, without ever answering the simple question "What compelling problems does this solve?"
The machine was shipped the equivalent of a 4 hour drive. The thing is, there's remote, and then there's really damn remote.
I work from a home office. It saves the company a ton of money without involving any of the headaches of outsourcing to India. And I'm still close enough that I can visit the machines in person if I need to.
Personally I prefer to run the OS which crashes in VMware, and the OS which doesn't native...
Funnily enough, this last week I had a server that was causing problems shipped to my house so I could do setup and testing effectively. Once I've finished soak testing in a day or so, it'll be shipped back to its home for the local network guy to plug it in.
Sometimes there's just no substitute for locality.
A lot of C++ fans here, I see. I offer the perspective of someone who's written C++ and written Java, but who doesn't particularly like either of them.
What Java offers over C++ is robustness. It's designed so that a RAIJP (Redundant Array of Inexpensive/Interchangeable Java Programmers) can write code without creating a ton of memory leaks, null pointers and security exposures. From automatic memory management to mandatory exception handling, most of its features are designed to support that goal.
What Java doesn't offer is much improvement in development speed over C++. Simple tasks often take ridiculous amounts of code, offsetting the gains of automatic memory management.
So... in this case Java is really solving problems that are being introduced by adding offshore developers. So the real question is whether offshore developers are the solution to your problems. I'm guessing they're not.
OK, I'll indulge you. Why sendmail sucks, in a nutshell:
It was designed before Internet e-mail standards were established. As a result, it contains a general purpose rewriting engine that's Turing complete--the idea was it would be able to be configured to translate addresses between BITNET, UUCP, JANET, ARPAnet, CompuServe, FidoNet, and so on, without recompiling the sendmail binary. This was important because back in the 80s, those networks all had different address formats.
Nowadays the ability to arbitrarily rewrite addresses is completely unnecessary, but Sendmail keeps the old design. This leads to a number of major misfeatures.
Sendmail is a pig to configure. The "new improved" sendmail.mc is slightly better than the old sendmail.cf, but still awful compared to the alternatives because it's layered on top of M4, an ancient macro processor. Compare an example postfix config and an example sendmail config. And remember, that's the new .mc file that's compiled into the actual sendmail.cf; if you ever need to do something complex that requires editing the sendmail.cf itself, you'll be faced with something much nastier.
Sendmail has a continuing history of poor security. 16 vulnerabilities between 2000 and mid-2006, according to nvd.nist.gov. By comparison, Exim has had 9, Postfix has had 4, Qmail 3.
Sendmail has lousy performance. Postfix is 2-4x faster. Take a look at some benchmarks.
Sendmail was designed to parse and reconstruct the header of every e-mail going through it. This makes it brittle--give it something it isn't expecting, and the results are unpredictable. This has resulted in Bcc:ed recipients being revealed to each other, unknown header fields being destroyed, and so on. It also makes e-mail forensics difficult--just because the message looked like it had the right addresses when it arrived, didn't mean it had the right addresses when it was sent, if it has passed through sendmail. MTAs should not rewrite e-mail going through them; only e-mail being passed to them directly by a client.
It has broken behavior when sending to multiple recipients. For example, if the To: field is missing a comma between two addresses, sendmail will send copies of the e-mail to all the addresses that it can parse, then barf on the broken ones. This is unhelpful, because if the user then re-sends the mail, most people end up getting 2 copies.
So in short: it's broken, it's slow, it's insecure, and it's awkward to configure. There are other open source mailers that have a few of those defects, but sendmail is the only one that has them all. Do a search for "sendmail sucks" and you'll find plenty of people with the same opinion as me.
Notes 7 lets you use DB2 for the data store, WTF do you want that's more robust than that?
If you picked sendmail for your SMTP e-mailer, that pretty much destroys your credibility right there.
It's like saying "I have extensive experience with RealPlayer, and can say with authority that MP3 is no good..." or "I drive a Chevy Cavalier, and the Ford Focus just isn't a quality automobile..."