And I can related. I used to be in the "J2EE is the only proper way to do things" camp too. Read about 4,000 pages worth of books cover to cover about everything from Struts, Hibernate, Tapestry, and EJB's on. Also thought all interfaces should be done with XML and XSLT because it was just the right way. Preached about it to people.
Then reality actually hit. I went to work for a large telecom company who's upper management constantly was obsessed with converting everything into J2EE but because I had some PHP experience I ended up doing both and got to live in both worlds.
The result was was that, of about 80 different internal and external websites that worked 75 of them were PHP, 4 were J2EE, and 1 was ASP (pre.NET). Our team of 3 developers maintained all 75 PHP sites and 1 of the J2EE apps. The other three J2EE apps each had a team of 8 people on average, dedicated DBA's (because the application "required" Oracle). The ASP app only worked in IE6 and had 3 people responsible for it.
Now, exactly what does it say about maintainability when 3 people can maintain 75 different sites and have spare time for new development. After a while, when my eyes were officially opened to the man hours / licensing fees wasted on pursuing the "right" way of doing things we convinced our VP to let us rewrite a particularly buggy J2EE app that we had to interface with a lot. This system had take 6 months for 5 people to build.
Our team rewrote the entire thing in 1 night, bug-free for at least the next 1.5 years too (I left for another job after that).
The lesson that we learned was simply this: practical abstraction.
You can strive for ideals all day long, but if the ideals are so bloated that it takes 8 people to do the job of 1 person it is no longer cost effective.
With J2EE you spend so much time learning all of the "right way" to do things that it prevents you from having any amount of time to learn all the other surrounding web technologies. You also end up with people who are literally afraid to learn anything new because they've invested so much time into learning what they already know. Ever meet Java people who think EVERYTHING needs to be done in Java? That's why.
At the same time, a language like PHP that you can be polished with in a week is a powerful tool in the hands of a good developer. It gets a bad rap because it's so easy to learn a little bit at a time that designers and other people with no formal programming background at all are able to jump in and create some bad code.
The dumbest can write code that does a wealth of damage regardless of language and Java is no different.
Reasonable quality control measures can remove the issues pretty quickly. Code reviews for new team members until you can ensure a programmer is providing you at least "passable" code consistently will make sure that "the dumbest can't do do much damage."
1. If the app needs that, it can be built without a whole lot of complexity. Abstracting it so that it can just be applied is a lot more complicated and bravo to Java for having that.
2. Single Sign On is not a complicated process. I worked as a J2EE architect and PHP developer for a telcom company a few years back. The java only team implemented their "standards based" single sign on system that was marketed by the J2EE vendor as doing all that and a bag of chips. Took forever to get setup, constantly had issues and was nowhere close to as good as advertised.
Eventually the VP came to our little web team of PHP + a specialty guys (J2EE,.NET, and Perl) because our stuff actually worked when we wrote it. We replaced the ENTIRE system with a from scratch SSO solution across 18 different internal and external sites/applications in under 2 weeks. You know why? Because J2EE talks a big game and has a whole lot of giant books but when it comes time to deliver it comes up short OVER and OVER and OVER again. It's going to be behind schedule, over budget, and under-functional 9/10 times.
3. Yes. You can.
Do you have any idea how much money corporations throw away on J2EE Application Servers to get that functionality built in? 6 figure numbers minimum.
Do you have any idea how much you need to pay for the annual salary of a good server admin? Usually less than that.
Do you have any idea how much time it will take for a good server admin to set that up for you? 2 weeks to a month so you can use it forever.
Session failover? Really? If you've got a multi-server app running it better darn well failover or you've written a POS app. Again, not that complicated to implement in less than a day.
4. Ah, the dream. It always sounds so good and yet, never really works that way. Great marketing pitch though.
5. Again, sounds good. J2EE app servers are very good for that, however, paid app servers for a lot of other languages will give you detailed trace modes for exactly that reason.
Getting a vendor to support you is a great idea too. It's actually more of a testament to out-sourcing than anything else though. By depending on a vendor to support their application, you're basically just paying to depend on their programming team, documentation, and training processes instead of yours. If you're trying to figure out if it's a server issue or an issue with the application that you've written in house, I hope you've already got the tools available to trace those down.
Finally, all this aside, I was a java guy before. Completely bought into all of the talk about ideal architecture, standards, "enterpriseyness", etc. I literally had the "I can't believe anybody would try to use anything but Java...it solves everything" mindset.
Then I saw it in practice and reality is far from what's spec'd on paper. For one thing, J2EE is serious overkill for 99% of applications and that is very important. When people get into java, they want to do EVERYTHING in Java. This is where most of the "standardize on a language" people come from. If you try to do everything a company needs in java, the company is going to simply hemorrhage money.
Additionally, the beauty of the web is that through web services, REST, and API's everywhere it's easier than ever to use the right tool for the job. J2EE is a swiss army knife. You can hammer a nail with it, but it will take forever and your fingers will get bloody. Use it for heavy lifting backend work if you need to and then just let everything else talk to it via a web service. It's one of the most effective ways to take advantage of Java where it's needed and to not use it where it's inefficient to develop and not cost effective - aka, web apps.
One of Java's biggest flaws in the world of more and more client-side web apps is the save + build + war + deploy to app server + refresh + compile JSP at first runtime that takes absolutely forever. In other languages that are more suited to the web (PHP, Python, Ruby, Perl) yo
1. If the app needs that, it can be built without a whole lot of complexity. Abstracting it so that it can just be applied is a lot more complicated and bravo to Java for having that.
2. Single Sign On is not a complicated process. I worked as a J2EE architect and PHP developer for a telcom company a few years back. The java only team implemented their "standards based" single sign on system that was marketed by the J2EE vendor as doing all that and a bag of chips. Took forever to get setup, constantly had issues and was nowhere close to as good as advertised.
Eventually the VP came to our little web team of PHP + a specialty guys (J2EE,.NET, and Perl) because our stuff actually worked when we wrote it. We replaced the ENTIRE system with a from scratch SSO solution across 18 different internal and external sites/applications in under 2 weeks. You know why?
Because J2EE talks a big game and has a whole lot of giant books but when it comes time to deliver it comes up short OVER and OVER and OVER again. It's going to be behind schedule, over budget, and under-functional 9/10.
3. Yes. You can.
Do you have any idea how much money corporations throw away on J2EE Application Servers to get that functionality built in? 6 figure numbers minimum.
Do you have any idea how much you need to pay for the annual salary of a good server admin? Usually less than that.
Do you have any idea how much time it will take for a good server admin to set that up for you? 2 weeks to a month so you can use it forever.
Session failover? Really? If you've got a multi-server app running it better darn well failover or you've written a POS app. Again, not that complicated to implement in less than a day.
4. Ah, the dream. It always sounds so good and yet, never really works that way. Great marketing pitch though.
5. Again, sounds good. J2EE app servers are very good for that, however, paid app servers for a lot of other languages will give you detailed trace modes for exactly that reason.
Getting a vendor to support you is a great idea too. It's actually more of a testament to out-sourcing than anything else though. By depending on a vendor to support their application, you're basically just paying to depend on their programming team, documentation, and training processes instead of yours. If you're trying to figure out if it's a server issue or an issue with the application that you've written in house, I hope you've already got the tools available to trace those down.
Finally, all this aside, I was a java guy before. Completely bought into all of the talk about ideal architecture, standards, "enterpriseyness", etc. I literally had the "I can't believe anybody would try to use anything but Java...it solves everything" mindset.
Then I saw it in practice and reality is far from what's spec'd on paper. For one thing, J2EE is serious overkill for 99% of applications and that is very important. When people get into java, they want to do EVERYTHING in Java. This is where most of the "standardize on a language" people come from. If you try to do everything a company needs in java, the company is going to simply hemorrhage money.
Additionally, the beauty of the web is that through web services, REST, and API's everywhere it's easier than ever to use the right tool for the job. J2EE is a swiss army knife. You can hammer a nail with it, but it will take forever and your fingers will get bloody. Use it for heavy lifting backend work if you need to and then just let everything else talk to it via a web service. It's one of the most effective ways to take advantage of Java where it's needed and to not use it where it's inefficient to develop and not cost effective - aka, web apps.
One of Java's biggest flaws in the world of more and more client-side web apps is the save + build + war + deploy to app server + refresh + compile JSP at first runtime that takes absolutely forever. In other languages that are more suited to the web (PHP, Python, Ruby, Perl) you can simply hit save + refresh.
When you're
And runs on Linux, OSX, and Windows. I forget the name, but there was a file sharing service like that which MS bought and the Linux version just...vanished.
It's a historical account of encryption and the math behind it along with the war stories that go along with it. It's really entertaining and educational from a historical and math perspective. Not so long that it becomes a chore either.
I just downloaded this beta and installed it, getting a message about how I would have to purchase Norton AV by the time the trial period expires (keep in mind I was running NIS 2004 w/ AV before this). Well, the trial period ends...today (5/6/2005).
That's just a waste of my time.
The article shows it too.
The entire point of that article was to appeal as if he were a Mac fan, hype of some of the improvements that nobody will consider a big deal or that Windows already has or will have, and then make Tiger out to be no big deal. It's a well written, remove the hype piece from a Windows guy.
Let's face it. He's covering features that nobody will really care about:
1. Searches everywhere
2. Widgets
3. Pinstripe look fading
4. Safari's great, too bad it's not on Windows
Automater alone makes me want a Mac. In my mind that is the single most impressive new feature and he went out of his way not even to highlight it among the "minor" improvements.
Slashdot Mirror
Price is a reflection of what people are willing to pay and based on iPhone sales, I'd say it's priced pretty well.
Sent from my iPhone
And I can related. I used to be in the "J2EE is the only proper way to do things" camp too. Read about 4,000 pages worth of books cover to cover about everything from Struts, Hibernate, Tapestry, and EJB's on. Also thought all interfaces should be done with XML and XSLT because it was just the right way. Preached about it to people.
Then reality actually hit. I went to work for a large telecom company who's upper management constantly was obsessed with converting everything into J2EE but because I had some PHP experience I ended up doing both and got to live in both worlds.
The result was was that, of about 80 different internal and external websites that worked 75 of them were PHP, 4 were J2EE, and 1 was ASP (pre.NET). Our team of 3 developers maintained all 75 PHP sites and 1 of the J2EE apps. The other three J2EE apps each had a team of 8 people on average, dedicated DBA's (because the application "required" Oracle). The ASP app only worked in IE6 and had 3 people responsible for it.
Now, exactly what does it say about maintainability when 3 people can maintain 75 different sites and have spare time for new development. After a while, when my eyes were officially opened to the man hours / licensing fees wasted on pursuing the "right" way of doing things we convinced our VP to let us rewrite a particularly buggy J2EE app that we had to interface with a lot. This system had take 6 months for 5 people to build.
Our team rewrote the entire thing in 1 night, bug-free for at least the next 1.5 years too (I left for another job after that).
The lesson that we learned was simply this: practical abstraction.
You can strive for ideals all day long, but if the ideals are so bloated that it takes 8 people to do the job of 1 person it is no longer cost effective.
With J2EE you spend so much time learning all of the "right way" to do things that it prevents you from having any amount of time to learn all the other surrounding web technologies. You also end up with people who are literally afraid to learn anything new because they've invested so much time into learning what they already know. Ever meet Java people who think EVERYTHING needs to be done in Java? That's why.
At the same time, a language like PHP that you can be polished with in a week is a powerful tool in the hands of a good developer. It gets a bad rap because it's so easy to learn a little bit at a time that designers and other people with no formal programming background at all are able to jump in and create some bad code.
For further reading material, check out "The Top 10 Signs You're a Crappy Programmer (and don't know it)." http://damienkatz.net/2006/05/signs_youre_a_c.html
The dumbest can write code that does a wealth of damage regardless of language and Java is no different.
Reasonable quality control measures can remove the issues pretty quickly. Code reviews for new team members until you can ensure a programmer is providing you at least "passable" code consistently will make sure that "the dumbest can't do do much damage."
It's all about the process.
1. If the app needs that, it can be built without a whole lot of complexity. Abstracting it so that it can just be applied is a lot more complicated and bravo to Java for having that.
2. Single Sign On is not a complicated process. I worked as a J2EE architect and PHP developer for a telcom company a few years back. The java only team implemented their "standards based" single sign on system that was marketed by the J2EE vendor as doing all that and a bag of chips. Took forever to get setup, constantly had issues and was nowhere close to as good as advertised.
Eventually the VP came to our little web team of PHP + a specialty guys (J2EE, .NET, and Perl) because our stuff actually worked when we wrote it. We replaced the ENTIRE system with a from scratch SSO solution across 18 different internal and external sites/applications in under 2 weeks. You know why? Because J2EE talks a big game and has a whole lot of giant books but when it comes time to deliver it comes up short OVER and OVER and OVER again. It's going to be behind schedule, over budget, and under-functional 9/10 times.
3. Yes. You can.
Do you have any idea how much money corporations throw away on J2EE Application Servers to get that functionality built in? 6 figure numbers minimum.
Do you have any idea how much you need to pay for the annual salary of a good server admin? Usually less than that.
Do you have any idea how much time it will take for a good server admin to set that up for you? 2 weeks to a month so you can use it forever.
Session failover? Really? If you've got a multi-server app running it better darn well failover or you've written a POS app. Again, not that complicated to implement in less than a day.
4. Ah, the dream. It always sounds so good and yet, never really works that way. Great marketing pitch though.
5. Again, sounds good. J2EE app servers are very good for that, however, paid app servers for a lot of other languages will give you detailed trace modes for exactly that reason.
Getting a vendor to support you is a great idea too. It's actually more of a testament to out-sourcing than anything else though. By depending on a vendor to support their application, you're basically just paying to depend on their programming team, documentation, and training processes instead of yours. If you're trying to figure out if it's a server issue or an issue with the application that you've written in house, I hope you've already got the tools available to trace those down.
Finally, all this aside, I was a java guy before. Completely bought into all of the talk about ideal architecture, standards, "enterpriseyness", etc. I literally had the "I can't believe anybody would try to use anything but Java...it solves everything" mindset.
Then I saw it in practice and reality is far from what's spec'd on paper. For one thing, J2EE is serious overkill for 99% of applications and that is very important. When people get into java, they want to do EVERYTHING in Java. This is where most of the "standardize on a language" people come from. If you try to do everything a company needs in java, the company is going to simply hemorrhage money.
Additionally, the beauty of the web is that through web services, REST, and API's everywhere it's easier than ever to use the right tool for the job. J2EE is a swiss army knife. You can hammer a nail with it, but it will take forever and your fingers will get bloody. Use it for heavy lifting backend work if you need to and then just let everything else talk to it via a web service. It's one of the most effective ways to take advantage of Java where it's needed and to not use it where it's inefficient to develop and not cost effective - aka, web apps.
One of Java's biggest flaws in the world of more and more client-side web apps is the save + build + war + deploy to app server + refresh + compile JSP at first runtime that takes absolutely forever. In other languages that are more suited to the web (PHP, Python, Ruby, Perl) yo
Thanks! Didn't know about that.
I've since updated it, but it doesn't seem like there's any way for me to edit the original comment.
1. If the app needs that, it can be built without a whole lot of complexity. Abstracting it so that it can just be applied is a lot more complicated and bravo to Java for having that. 2. Single Sign On is not a complicated process. I worked as a J2EE architect and PHP developer for a telcom company a few years back. The java only team implemented their "standards based" single sign on system that was marketed by the J2EE vendor as doing all that and a bag of chips. Took forever to get setup, constantly had issues and was nowhere close to as good as advertised. Eventually the VP came to our little web team of PHP + a specialty guys (J2EE, .NET, and Perl) because our stuff actually worked when we wrote it. We replaced the ENTIRE system with a from scratch SSO solution across 18 different internal and external sites/applications in under 2 weeks. You know why?
Because J2EE talks a big game and has a whole lot of giant books but when it comes time to deliver it comes up short OVER and OVER and OVER again. It's going to be behind schedule, over budget, and under-functional 9/10.
3. Yes. You can.
Do you have any idea how much money corporations throw away on J2EE Application Servers to get that functionality built in? 6 figure numbers minimum.
Do you have any idea how much you need to pay for the annual salary of a good server admin? Usually less than that.
Do you have any idea how much time it will take for a good server admin to set that up for you? 2 weeks to a month so you can use it forever.
Session failover? Really? If you've got a multi-server app running it better darn well failover or you've written a POS app. Again, not that complicated to implement in less than a day.
4. Ah, the dream. It always sounds so good and yet, never really works that way. Great marketing pitch though.
5. Again, sounds good. J2EE app servers are very good for that, however, paid app servers for a lot of other languages will give you detailed trace modes for exactly that reason.
Getting a vendor to support you is a great idea too. It's actually more of a testament to out-sourcing than anything else though. By depending on a vendor to support their application, you're basically just paying to depend on their programming team, documentation, and training processes instead of yours. If you're trying to figure out if it's a server issue or an issue with the application that you've written in house, I hope you've already got the tools available to trace those down.
Finally, all this aside, I was a java guy before. Completely bought into all of the talk about ideal architecture, standards, "enterpriseyness", etc. I literally had the "I can't believe anybody would try to use anything but Java...it solves everything" mindset.
Then I saw it in practice and reality is far from what's spec'd on paper. For one thing, J2EE is serious overkill for 99% of applications and that is very important. When people get into java, they want to do EVERYTHING in Java. This is where most of the "standardize on a language" people come from. If you try to do everything a company needs in java, the company is going to simply hemorrhage money.
Additionally, the beauty of the web is that through web services, REST, and API's everywhere it's easier than ever to use the right tool for the job. J2EE is a swiss army knife. You can hammer a nail with it, but it will take forever and your fingers will get bloody. Use it for heavy lifting backend work if you need to and then just let everything else talk to it via a web service. It's one of the most effective ways to take advantage of Java where it's needed and to not use it where it's inefficient to develop and not cost effective - aka, web apps.
One of Java's biggest flaws in the world of more and more client-side web apps is the save + build + war + deploy to app server + refresh + compile JSP at first runtime that takes absolutely forever. In other languages that are more suited to the web (PHP, Python, Ruby, Perl) you can simply hit save + refresh.
When you're
And runs on Linux, OSX, and Windows. I forget the name, but there was a file sharing service like that which MS bought and the Linux version just...vanished.
It's a historical account of encryption and the math behind it along with the war stories that go along with it. It's really entertaining and educational from a historical and math perspective. Not so long that it becomes a chore either.
And it just never ever got old.
I just downloaded this beta and installed it, getting a message about how I would have to purchase Norton AV by the time the trial period expires (keep in mind I was running NIS 2004 w/ AV before this). Well, the trial period ends...today (5/6/2005). That's just a waste of my time.
The article shows it too. The entire point of that article was to appeal as if he were a Mac fan, hype of some of the improvements that nobody will consider a big deal or that Windows already has or will have, and then make Tiger out to be no big deal. It's a well written, remove the hype piece from a Windows guy. Let's face it. He's covering features that nobody will really care about: 1. Searches everywhere 2. Widgets 3. Pinstripe look fading 4. Safari's great, too bad it's not on Windows Automater alone makes me want a Mac. In my mind that is the single most impressive new feature and he went out of his way not even to highlight it among the "minor" improvements.