It's sort of like buying a car. Go check the resale value of an audi or bmw after 2 years/24k and compare it to a chevy malibu or ford taurus with the same criteria (try to stick with cars that for the past two years haven't had dramatic changes), you'll see right away why it's a bad idea to buy a malibu or taurus.
guy who got sick and tired of being turned upside down on car loans. yep, it's why I bought a new BMW, and a new 4Runner (Toyotas "suffer" from the same depreciation as BMW:) Audi, however, is just the opposite. Hence the reason I'm looking at a 2 year old Audi.
Drugging all troops before combat.... What a Brave New World this opens up. Sounds more like Dune's Sardaukar troops (I vaguely recall the books referring to their drugged state(s) even though wikipedia neglects to mention anything about this)
Who updates windows? Get a stable installation w/ SP1 or later for XP, and then forget it.
Don't run IE or any other MS software and be behind an external blocking firewall. 99.9% of your potential issues disappear. That last 0.01% of issues can be handled by not visiting pr0n sites and using a smidgin of common sense when deciding what email to view in their HTML glory.
Spring's primary raison d'etre is a solution looking for a problem. In their about page, they even mention it as a primary reason for its existence: "Testability is essential, and a framework such as Spring should help make your code easier to test." This can be read as "use dependency injection to easily test your code". Last time I looked, adding code specifically for testing into your production code is considered a "bad practice". Most implementations of Spring I've seen have this "feature" purely to allow for testing. The other bad thing about dependency injection is that you've now broken compile time checks and have to depend upon runtime checks. This can also tie a two ton anchor around your developers necks.
You're also spot on about Hibernate. Nice product, worlds better than JDO, but sometimes you just need custom actions with your DB that only SQL/custom code can perform. If you're already writing the custom code, you might as well access your data directly through SQL/stored procs, especially in cases that involve tens of thousands or more rows in multiple tables. ORM solutions do not handle those scenarios well. (In my case, I've almost always needed this capability, we've tried EJB persistence BLEAH!!, JDO - even bigger BLEAH!!! as it took much longer to get to the point that you could affirmatively state that JDO sucks rocks, and Hibernate bleah as it was only a couple of days to realize it wasn't going to handle our needs. (Hibernate's quick turn around is one of the reasons I like it, at least you don't spend weeks or months building and testing and tuning things before realizing its innappropriate:)
Well if you had coded to the original EJB standard you'd still be stuck with a painful migration, since it was a piece of crap. EJB only started looking reasonable after they copied the ideas from the very open source projects you are disparaging.
EJB only started looking reasonable? You've been drinking the kool-aid.
EJB sucks.
I have yet to see a problem that EJB "solves" that isn't better served by some other solution, including distributed transactions. It's a klunky overly verbose boilerplate generating POS. Annotations remove some of the tedium of the boilerplate, but still leaves you with the manual generation of a slew of crap to dictate visibility and so on. WTF it couldn't just have been "write a POJO - all public methods are visible both locally and remotely by default" is beyond me. Yes, you may not want them all visible, but that's the exception to the rule - you are, after all, writing a bean to plug in somewhere. That's the entire point of EJBs. (Overly simplified)
Rolling your own is not necessarily a good solution either, if it costs you more time and money than an off-the-shelf solution. Either way you have to pay the migration cost if something better comes along. If you've rolled your own and coded to standards, generally migration costs are close to nil if you even need to migrate in the first place. If you've used some off the shelf solution that is not following standards, you sometimes get into big hairy updates. Here are a few offenders: BEA (Weblogic, Portal), IBM (Websphere), ATG (Dynamo), and ECM (Documentum). All four of those have had issues with their proprietary implementations between even point releases. ATG even had issues if you didn't use their proprietary tags. Documentum has issues merely installing on the latest JDK releases.
And the kicker? You have to upgrade all of these products because maintenance on them skyrockets after they've been "sunsetted". When your business depends on such a product, not having maintenance is not an option (the CYA issue).
Of course, if you didn't use their proprietary hooks in the three appservers listed, updating is usually a minor issue other than testing. If you did use any, or any products that did, the upgrade cycle becomes a rather painful process as things break, or behave differently than you're expecting, and your entire dev team gets sucked into discovering what all the little flaws are. I've seen ATG and Websphere updates take almost 12 months before being vetted by QA to run in production. Weblogic took over 6 months. And those were the entire dev teams involved. And this isn't a one-time cost, almost every must-do upgrade is that painful, and you'll have to do one at least every 2 years.
So I ask you - what did running COTS "save" you in the end?
Now, I should also point out that I use tools like log4j, struts (yick:), and various other packages. I've also used a home-grown data abastraction layer that survived unchanged through 5 years of various upgrades on multiple systems. They all have one thing in common though - they're all designed to run on a standard implementation of the JVM/EE. Upgrades of the underlying infrastructure that these tools run on are usually painless.
Heck, if you think that's bad, wait for this one - they were actually arguing about just switching to DST permanently, but the cows were against it. (Search for "cow") Heck, there's a lot of "cow"argumentsagainstDST.
Absolutely!!!! That hits the nail squarely on the head.
Code to standards or roll your own. Forget these proprietary one-off solutions. All they do is tie you to a single vendor's single version. (Take a look at the pain involved in even migrating between versions of a single vendor's solution.)
And some of us think those optional "services" are all irrelevant, much like the menu fades and "glass" (transparency) features touted as a reason to upgrade to a new OS.
BS.... And most often 'unusable for Hibernate' database scheme just means that your 'SQL gurus' know nothing about normalization and treat tables as plain text files.
Good legacy schemes can be converted very nicely.... Actually, "unusable for Hibernate" DB schemes come about from a lack of good DBAs being around to say "HEY - DON'T DO THAT!!!". I have, unfortunately, had to deal with more of those than well-designed DBs. Those bad DBs make JDO or Hibernate suck wind to use, if you can get them to work at all. Oh, and JDO sucks anyways. I'm still on the fence about Hibernate. Looks nice, but....
I've never heard of the alpha releases of Chicago. I had heard of some "demos" that were shown, but never that anyone actually got their hot little hands on Chicago code.
You're not alone. There's some of us going all the way back to 93/94 that said that Cairo->Longhorn->Vista was going to kill MS should they ever actually try to release it. That's right, look at Cairo's claimed functionality, and you'll see Longhorn, of which Vista is the reality.
MS overshot/overstated their capabilities, and anyone with even half a brain knew it.
They are standard. The state you're in makes a huge difference. Some states are work at will states and also have clauses that invalidate contractual clauses that would prevent you from earning a living.
While that means you can not take IP with you, they cannot prevent you from using your skills in your new job. They also, in my state, cannot prevent you from talking to your previous clients/customers/business contacts.
To be honest, at a previous company, I think both the customers and the developers would have loved to have had salesmen that actually understood the product they were selling. Given the products that were being sold, that meant you had to at least be conversant in software development, as buying the software was only step one of many that included additional development to actually experience the ROI the software was capable of delivering. Instead we had empty headed fast talking imbeciles without half a clue selling some of the most sophisticated software on the planet to customers that wound up having long discussions with the developers post sale to figure out what they needed to do to realize the promised savings, and what the additional costs were going to be.
That's already been discussed as a reason for Apple's future to look brighter. After all - new interface, new paradigms, and lack of backwards compatibilities and lack of software all make for a nice big opening for other systems to enter the market. Add to that an entirely new administrative/maintenance learning curve, and going with something a little more stable, like, say, Apple or Linux, all of a sudden becomes quite enticing, especially when you include the lack of CALs (Client Access Licenses).
Vista may be the hay bale that broke the camel's back.
In other words, "we have WYSIWYG now, which doesn't use or need it" is completely missing the point. WYSIWYG is improperly built because it does not do this extra spacing. If you don't understand what I mean, you don't understand "stream formatting". In stream formatting, when you get to the end of a sentence, regardless of punctuation (period, question mark, exclamation point) you add additional spacing to make the sentence separation more obvious. Thus you should only enter one space as data (or better yet, none!) after a period, and let the display render it properly.
That's right, peeps. You should type no spaces after the punctuation at the end of a sentence, if you want to be technical about it. A WYSIWYG that forces you to type one (or else it shows none) but that strips out the extra one if you type two is not WYSIWYG! And it is not a stream formatter. It is an abomination that deserves death. All incompetent inferior programmers should die like pigs in Hell, you substandard losers! >:(:) "http://slashdot.org"
How would you render that?
and who claimed HTML/browser combinations are WYSIWYG? Have you been in outer space since 1993 or so? Browser incompatibilities aren't solely about failures to display HTML, but also about rendering it differently.
Well, I started with using my mom's typing course book long ago. I probably don't have proper posture, but it's been long enough that I've seen quite a few of my colleagues develop RSI issues. I tend to use wrist pads to force my wrists higher, and that seems to work for me. My touch typing skills are pretty decent, as I certainly get to practice quite a bit.
I also found those double spaces annoying as anything. I'm happy they're gone, except by those hold overs that refuse to change.
I'd say the same about people who put only one space after periods.... I'm not sure if they teach typing that way anymore, but it's hard to break a habit like this. Then again, I'm glad I took the class as I can touch type pretty fast and don't have RSI. If I had the choice of making you annoyed or having braces on my wrists, I can tell you which I'd choose:). Now think about this - what does hitting the space bar an extra time every time you hit a period have to do with RSI? Maybe increases the potential as it is an unnecessary additional motion?
You must really hate the web then, though, because most browsers automatically compress extra white space into a single space, unless you type an & nbsp;
It has to do with the fact that typewriters use a monospace font. Two spaces were used as a cue to the eye that the sentence had ended. Now that we use WYSIWYG editors and variable spaced fonts, we no longer need the extra space. I know where the practice came from, my point was wasn't a period followed by a space cue enough? I also found those double spaces annoying as anything. I'm happy they're gone, except by those hold overs that refuse to change.
It's the same process. If the distributors, publishers, and producers are all under one roof, it's a monopoly, and there's no room for anyone else at the inn. Not to mention that the airwaves belong to the people, not a corporation, no matter what they might think. (Of course, some corporate lapdog will point out that a corp most certainly does own that slice of frequency since they "paid" for it, they only paid for the right to use it for a limited time, with strings attached)
It's illegal for the same reason any racketering endeavor is illegal.
Who the f*** decided that sentences on the Internet shall no longer be formatted with two spaces after a period?! Who the fuck decided that they'd ever have 2 spaces to begin with? WTF is the period for?!?
I too believe that the majority of people don't care about their music. The reason "oldies" stations work? Most people appear to get "stuck" in their listening habits somewhere between 16 and 25, and then only listen to their "comfort music". Rarely are new tracks, much less actual new types of acts, added to their repertoire.
It's why there's so much trash on the radio now (besides payola, etc). The marketers have figured out that spoon feeding the same tripe to the young immature and uncritical listening audience allows them to churn "new" artists as needed maximizing their profits.
Large broadcast companies probably have paid a higher price in loss of listenership, as their tired, weary, and limited playlists have driven more and more people to alternatives such as iPods, MP3 players and satellite radio.
Sure, go ahead, fine them, order them to allocate time to new acts, that's a small loss they can see on their balance sheets in comparison to the difficult to calculate loss of listenership.
They'll now have 2 targets to blame their losses on - piracy (MP3s) and FCC actions.
Slashdot Mirror
guy who got sick and tired of being turned upside down on car loans. yep, it's why I bought a new BMW, and a new 4Runner (Toyotas "suffer" from the same depreciation as BMW:) Audi, however, is just the opposite. Hence the reason I'm looking at a 2 year old Audi.
Who updates windows? Get a stable installation w/ SP1 or later for XP, and then forget it.
Don't run IE or any other MS software and be behind an external blocking firewall. 99.9% of your potential issues disappear. That last 0.01% of issues can be handled by not visiting pr0n sites and using a smidgin of common sense when deciding what email to view in their HTML glory.
Heck - you should be modded up.
Spring's primary raison d'etre is a solution looking for a problem. In their about page, they even mention it as a primary reason for its existence: "Testability is essential, and a framework such as Spring should help make your code easier to test." This can be read as "use dependency injection to easily test your code". Last time I looked, adding code specifically for testing into your production code is considered a "bad practice". Most implementations of Spring I've seen have this "feature" purely to allow for testing. The other bad thing about dependency injection is that you've now broken compile time checks and have to depend upon runtime checks. This can also tie a two ton anchor around your developers necks.
You're also spot on about Hibernate. Nice product, worlds better than JDO, but sometimes you just need custom actions with your DB that only SQL/custom code can perform. If you're already writing the custom code, you might as well access your data directly through SQL/stored procs, especially in cases that involve tens of thousands or more rows in multiple tables. ORM solutions do not handle those scenarios well. (In my case, I've almost always needed this capability, we've tried EJB persistence BLEAH!!, JDO - even bigger BLEAH!!! as it took much longer to get to the point that you could affirmatively state that JDO sucks rocks, and Hibernate bleah as it was only a couple of days to realize it wasn't going to handle our needs. (Hibernate's quick turn around is one of the reasons I like it, at least you don't spend weeks or months building and testing and tuning things before realizing its innappropriate:)
EJB only started looking reasonable? You've been drinking the kool-aid.Well if you had coded to the original EJB standard you'd still be stuck with a painful migration, since it was a piece of crap. EJB only started looking reasonable after they copied the ideas from the very open source projects you are disparaging.
EJB sucks.
I have yet to see a problem that EJB "solves" that isn't better served by some other solution, including distributed transactions. It's a klunky overly verbose boilerplate generating POS. Annotations remove some of the tedium of the boilerplate, but still leaves you with the manual generation of a slew of crap to dictate visibility and so on. WTF it couldn't just have been "write a POJO - all public methods are visible both locally and remotely by default" is beyond me. Yes, you may not want them all visible, but that's the exception to the rule - you are, after all, writing a bean to plug in somewhere. That's the entire point of EJBs. (Overly simplified) Rolling your own is not necessarily a good solution either, if it costs you more time and money than an off-the-shelf solution. Either way you have to pay the migration cost if something better comes along. If you've rolled your own and coded to standards, generally migration costs are close to nil if you even need to migrate in the first place. If you've used some off the shelf solution that is not following standards, you sometimes get into big hairy updates. Here are a few offenders: BEA (Weblogic, Portal), IBM (Websphere), ATG (Dynamo), and ECM (Documentum). All four of those have had issues with their proprietary implementations between even point releases. ATG even had issues if you didn't use their proprietary tags. Documentum has issues merely installing on the latest JDK releases.
And the kicker? You have to upgrade all of these products because maintenance on them skyrockets after they've been "sunsetted". When your business depends on such a product, not having maintenance is not an option (the CYA issue).
Of course, if you didn't use their proprietary hooks in the three appservers listed, updating is usually a minor issue other than testing. If you did use any, or any products that did, the upgrade cycle becomes a rather painful process as things break, or behave differently than you're expecting, and your entire dev team gets sucked into discovering what all the little flaws are. I've seen ATG and Websphere updates take almost 12 months before being vetted by QA to run in production. Weblogic took over 6 months. And those were the entire dev teams involved. And this isn't a one-time cost, almost every must-do upgrade is that painful, and you'll have to do one at least every 2 years.
So I ask you - what did running COTS "save" you in the end?
Now, I should also point out that I use tools like log4j, struts (yick:), and various other packages. I've also used a home-grown data abastraction layer that survived unchanged through 5 years of various upgrades on multiple systems. They all have one thing in common though - they're all designed to run on a standard implementation of the JVM/EE. Upgrades of the underlying infrastructure that these tools run on are usually painless.
Heck, if you think that's bad, wait for this one - they were actually arguing about just switching to DST permanently, but the cows were against it. (Search for "cow") Heck, there's a lot of "cow" arguments against DST.
Absolutely!!!! That hits the nail squarely on the head.
Code to standards or roll your own. Forget these proprietary one-off solutions. All they do is tie you to a single vendor's single version. (Take a look at the pain involved in even migrating between versions of a single vendor's solution.)
Umm, you didn't use a data abstraction layer (framework) with caching in your own code?
That's like rule #1 for improving performance and increasing scalability of your application.
And some of us think those optional "services" are all irrelevant, much like the menu fades and "glass" (transparency) features touted as a reason to upgrade to a new OS.
And most often 'unusable for Hibernate' database scheme just means that your 'SQL gurus' know nothing about normalization and treat tables as plain text files.
Good legacy schemes can be converted very nicely.
I've never heard of the alpha releases of Chicago. I had heard of some "demos" that were shown, but never that anyone actually got their hot little hands on Chicago code.
:)
You might like this as well: Chicago, Cairo, Longhorn, Vista, it's kind of interesting
You're not alone. There's some of us going all the way back to 93/94 that said that Cairo->Longhorn->Vista was going to kill MS should they ever actually try to release it. That's right, look at Cairo's claimed functionality, and you'll see Longhorn, of which Vista is the reality.
MS overshot/overstated their capabilities, and anyone with even half a brain knew it.
They are standard. The state you're in makes a huge difference. Some states are work at will states and also have clauses that invalidate contractual clauses that would prevent you from earning a living.
While that means you can not take IP with you, they cannot prevent you from using your skills in your new job. They also, in my state, cannot prevent you from talking to your previous clients/customers/business contacts.
To be honest, at a previous company, I think both the customers and the developers would have loved to have had salesmen that actually understood the product they were selling. Given the products that were being sold, that meant you had to at least be conversant in software development, as buying the software was only step one of many that included additional development to actually experience the ROI the software was capable of delivering. Instead we had empty headed fast talking imbeciles without half a clue selling some of the most sophisticated software on the planet to customers that wound up having long discussions with the developers post sale to figure out what they needed to do to realize the promised savings, and what the additional costs were going to be.
That's already been discussed as a reason for Apple's future to look brighter. After all - new interface, new paradigms, and lack of backwards compatibilities and lack of software all make for a nice big opening for other systems to enter the market. Add to that an entirely new administrative/maintenance learning curve, and going with something a little more stable, like, say, Apple or Linux, all of a sudden becomes quite enticing, especially when you include the lack of CALs (Client Access Licenses).
Vista may be the hay bale that broke the camel's back.
That's right, peeps. You should type no spaces after the punctuation at the end of a sentence, if you want to be technical about it. A WYSIWYG that forces you to type one (or else it shows none) but that strips out the extra one if you type two is not WYSIWYG ! And it is not a stream formatter. It is an abomination that deserves death. All incompetent inferior programmers should die like pigs in Hell, you substandard losers! >:(
How would you render that?
and who claimed HTML/browser combinations are WYSIWYG? Have you been in outer space since 1993 or so? Browser incompatibilities aren't solely about failures to display HTML, but also about rendering it differently.
:)
Well, I started with using my mom's typing course book long ago. I probably don't have proper posture, but it's been long enough that I've seen quite a few of my colleagues develop RSI issues. I tend to use wrist pads to force my wrists higher, and that seems to work for me. My touch typing skills are pretty decent, as I certainly get to practice quite a bit.
I'd say the same about people who put only one space after periods.
You must really hate the web then, though, because most browsers automatically compress extra white space into a single space, unless you type an & nbsp;
I think a lot of us don't think he ever had a "career" in music. He certainly has a career in acting, but music? Naah, no more than Keanu.
It's the same process. If the distributors, publishers, and producers are all under one roof, it's a monopoly, and there's no room for anyone else at the inn. Not to mention that the airwaves belong to the people, not a corporation, no matter what they might think. (Of course, some corporate lapdog will point out that a corp most certainly does own that slice of frequency since they "paid" for it, they only paid for the right to use it for a limited time, with strings attached)
It's illegal for the same reason any racketering endeavor is illegal.
I too believe that the majority of people don't care about their music. The reason "oldies" stations work? Most people appear to get "stuck" in their listening habits somewhere between 16 and 25, and then only listen to their "comfort music". Rarely are new tracks, much less actual new types of acts, added to their repertoire.
It's why there's so much trash on the radio now (besides payola, etc). The marketers have figured out that spoon feeding the same tripe to the young immature and uncritical listening audience allows them to churn "new" artists as needed maximizing their profits.
Large broadcast companies probably have paid a higher price in loss of listenership, as their tired, weary, and limited playlists have driven more and more people to alternatives such as iPods, MP3 players and satellite radio.
Sure, go ahead, fine them, order them to allocate time to new acts, that's a small loss they can see on their balance sheets in comparison to the difficult to calculate loss of listenership.
They'll now have 2 targets to blame their losses on - piracy (MP3s) and FCC actions.