I imagine the first question on everyone's mind will be, "Why do we need a new web browser?" To which I imagine the truthful answer is: "We don't. At least not for technical reasons."
I believe what Google is looking to accomplish is to trade on their brand name in an attempt to further dislodge Internet Explorer.
Remember when AOL purchased Netscape? AOL didn't care about the browser in the slightest. They wanted Netscape for the brand name. To the vast majority of users, Netscape was the Internet.
Google has since taken that place. Google is the Internet to many people. So much so that Google has felt compelled to to prevent the genericizing of their mark.
In this particular case, however, the strength of their mark works to Google's advantage. They have already convinced millions of users to install their desktop software. If they can further convince millions of users to install and use their browser, they can cause enough of a disruption to finally remove IE's leadership in the browser market. Especially given the solid work already done by FireFox, Opera, and Safari. With only another 10% marketshare loss on the whole, even the most stubborn websites will be forced to support third party browsers. And once they support third party browser, it will be very little time before the technological superiority of the alternative browsers causes them to add special features not available for Internet Explorer users.
It will be Netscape vs. Internet Explorer all over again. Except that instead of two giants fighting it out, it will be Microsoft against everyone else. And when everyone else happens to be giants in their own right, Microsoft's prospects will start looking rather grim.
In effect, this move is a blow aimed squarly at Redmond. Not for the purposes of truth, justice, and the freedom of all mankind; as I'm sure many will imagine. Rather, for the purpose of hitting back at Microsoft for their attempts to leverage their monopoly in promoting MSN Search over Google. The only difference is that Google Search is a good product and it is entrenched. Internet Explorer hasn't been a good product since Microsoft stopped developing it nearly 8 years ago (piss-poor upgrades pretending to be standards-compliant not withstanding), and its entrenchments are slowly falling to competition.
The current revision of ColdFusion is based on a J2EE server. The ColdFusion part of it is simply a scripting language running in a servlet container. The end result is that the developer can mix and match Java with ColdFusion, thus using his existing ColdFusion knowledge to extend into Java.
Or so the theory goes, at least. In practice, it seems to give CF developers the wrong idea.
He was offered only 3 years if he plead manslaughter. He refused. 15 to life (which means that he has a life sentence and is eligible for parole in 15 years) seems like a pretty good choice. Especially if he does reform. Society earns nothing by keeping him locked away longer if a parole board feels he's fit to leave. 15 years means that he's going to miss out on potentially some of the most interesting parts of what could have been his life. So it's not as if he will not learn anything.
I just don't know what to say about this. It's sad, upsetting, and yet just at the same time. On one hand I'm happy (can that even be the right word?) to see that he repented. On the other hand, I'm frightened by the thought that he killed her over a flippant remark about taking the kids to the doctor. On one hand it's also good that he didn't get off with a 3 year sentence, yet you can't help but feel for the fact that his own arrogance got him into this trouble.
Worst of all, events like this always create ugly questions in one's mind. e.g. It's a natural reaction to assume that murders are people who would stand out as a societal misfit. Someone who you would never place trust in or respect. Yet here we have an instance of someone that I had previously respected and was even considering contacting (partly because of several pushes from acquaintances) to work out new possible uses for Reiser's filesystem.
That's a very unsettling thought. If we cannot trust even the basic morality of people who have worked hard for their measures of respect in today's global community, who can we trust?
If he's looking for something cheaper, I can vouch for RAZRs working with Java apps. There's a simple USB Mini port on the side (cable not included) that can be used to hook it up to a computer and transfer applications.
I have also been told that many Nokia phones allow Java programs to be installed, but I do not know the details of those.
I'm still not impressed. I don't care how many whizzy-gig features Microsoft adds to their browser. It is still useless to developers until Microsoft installs standards support. And by standards support, we don't just mean fixing the broken setAttribute method. How about supporting a fucking decade old standards?!? Nope, still no mention of it. In fact, the bug on the issue was "closed by design".
By design? By fucking design?!?! BULLSHIT. Microsoft does not want to be interoperable with other Web Browsers. Period. If Microsoft really wanted to turn around their image in the market, they can start with something as stupidly simple as supporting addEventListener, removeEventListener, and dispatchEvent. I don't even care if the code looks like this:
^That's fucking WRONG and it would STILL be an improvement!
Microsoft can take their God damn browser and shove it where the sun don't shine for all I care. They have shown such incredible disdain for their customers, that I have to wonder why their even trying to hide it from the market.
*DEEP BREATH*
Microsoft, you are transparent. Your juvenile attempts at lock-in are NOT working and will NOT work. All you're going to do is piss off the people recommending software to grandma, grandpa, mom, dad, sisters, cousins, next door neighbors, school teachers, bosses, subordinates, government agencies, etc. IE will continue to lose market share. It won't be much longer before the alternative browsers reach critical mass. Many websites already show Firefox maintaining parity or even surpassing Internet Explorer. If you actually want to WIN the market, try competing for a change!
After re-re-reading it, I have no idea what they're trying to say
Oh gosh, that's been there since the stone ages. All it means is that the *.ser format changes with each major release of the Java platform. Java is usually backward compatible with *.ser files, but it is not forward-compatible. Which means, for example, that Java 1.6 *.ser files cannot be read by Java 1.5.
In effect, nothing to write home about. And if you want to serialize Swing, you should probably use the XML Bean Serializer instead. You'll get far more portable results than with native serialization.
Given the chance, I'd do it again, but talk about the Thread class!
*sigh* There is nothing wrong with the Thread class. Suggesting that programmers extend it rather than implementing Runnable was a foolish. There is no compelling reason to extend Thread other than early documentation that suggested it. And the stop() method seemed like a good idea at the time, but it wasn't. Calling stop() can have very negative consequences on running code that hits a critical state. (This is not a Java-specific issue.) You should ALWAYS use a flag to force the thread to exit naturally. If you do anything else, I will personally come over there and pummel you with a copy of the Java API specification!
You're quite correct about this. However, Microsoft's technologies at the time (based heavily on COM and DCOM) did not support SOAP very well. Thus it didn't see serious adoption until.NET hit the streets.
it's telling that the Java "community" embraced SOAP so whole-heartedly.
It might have been if this were true. But it's not. I was part of the JavaLobby forum (the Java advocacy meeting place at the time) and there was definitely a push-back against SOAP. A lot of programmers felt it was far too complex and that Microsoft would use binary encoded Microsoft crudola to negate the multi-platform nature of SOAP. (Especially since the early versions of SOAP often did little more than wrap serialized COM information.) This lead directly to a push to use the simpler XML-RPC instead. (RMI was unsuitable due to the Java-specific nature of it, and CORBA was just a mess.)
XML-RPC had a short and fun little life as the preferred object communications protocol, but Microsoft's marketing machine was already convincing people to use SOAP. Without a strong competitor and with a push from the business side to support interop between Java and.NET, SOAP libraries began appearing. Most famous, obviously, is Apache's toolkit. It wasn't long after that Sun began the JSR to support SOAP. It was horribly late to the game, but the feeling was that if Java was going to do it, it should do it as best as it possibly could.
And I'll be damned if Java didn't take SOAP and make it its own. I was constantly frustrated with.NET developers I was working with because they were working around their tools rather than working with them, thus making everyone's lives harder. Yet on our side, we were able to tell the most junior guy in the company to go expose a predetermined list of interfaces and its was done lickety split and far superior to our.NET counterparts.
So in effect, Java's excellent support for SOAP was more about "do the job right or don't do it at all" rather than an overwhelming positive reaction to the technology. In fact, I don't think anyone in the Java camp ever quite warmed up to it. But it worked and there were bigger fish to fricassee.
The Serializable interface has been deprecated and will not be forward compatible
What in the world are you talking about? java.io.Serializable, right? I don't see anything in there that says "deprecated".
This would be especially weird because Serializable doesn't do anything. It's just a marker for a class to say "Yes, I am serializable!" Now you may be able to accomplish the same thing with the new attribute tags, but I see nothing that prevents you from using the Serializable interface.
I think you may be confusing Serializable with something else.:-)
In any case, deprecated features in Java usually don't go away. They simply are not recommended for use any longer.
Isn't that the whole problem with Java in a nutshell?
Only if you consider choice to be a bug. Personally, I like the fact that I don't have to use the officially sanctioned method if I don't want to. And the older official methods do not deprecate with the introduction of the newer methods. Both can still be used.
In fact, there is very little deprecated overall in Java. It's just that there is often more than one way to skin a cat. Choose the one that works best for you.
which probably explains why it was so enthusiastically adopted by Java
Actually, SOAP was pushed heavily by Microsoft as part of.NET. Java took a more holistic approach and created APIs for SOAP, XML-RPC, REST, and many other services. There are about 3-4 different ways you can do each of them, with two of them being official or semi-official. (The reason for the break is that the methodology for providing such services was greatly enhanced by the attribute tags added in Java 1.6.)
If you're doing SOAP services, I'd blame the market for slurping up Microsoft's push rather than blaming your tools which happen to support the standard.
What's the old saying? "It's a poor craftsman who blames his tools?";-)
Is anyone actually surprised that the CEO is denying this?
Not at all. As you say, he would have denied it even if NVidia WAS planning a CPU. What actually speaks volumes IMHO, is the vehemence with which he denied it. Any CEO who's cover-denying a market move is not going to close his own doors by stating that the company could never make it in that space. He would give far weaker reasons so that when the announcement comes the market will still react favorably to their new product.
In other words: stick a fork in it, because this bit of tabloid reporting is dead.
Good question. I had to look it up. (Would it have killed the submitter or editor to include a link?)
Basically, the software gets its name from the list processing functions "map" (to take every item in a list and transform it, thus producing a list of the same size) and "reduce" (to perform an operation on a list that produces a single value or smaller list). The actual software has nothing to do with "map" and "reduce", but it does to tokenization and processing on massive amounts of data.
Presumably the Map/Reduce part comes from first normalizing the items being processed (a map operation) then reducing them down to a folded data structure (reduce), thus creating indexes of data suitable for fast searching.
they are planning on supporting Flash 7.0 and I think this means one could play swfs on it (of which I know several addictive games online).
Flash 7 is pretty ancient tech at this point. The vast majority of Flash games are Flash 8 with many of the new ones being made in Flash 9. However, the Nintendo Wii has the same limitation, so you may find Wii gaming sites to be useful on the device.
FFMPEG is pretty nifty. It especially does a good job in converting movies to FLV. But in this case, I need to make my own player. The code is done and working, but the target device won't read SWC files. They MUST be SWF. I'd rather use an OSS toolchain for quite a few reasons (not the least of which is that I'm not locked in to the FLA format), but I need to figure out how to turn off SWC compression. In Flash CS3 it's as easy as unchecking the "Compress Movie" checkbox. In SWFMILL, however, 'compress="0"' doesn't seem to be changing anything.:-/
Yes. The video object is independent from the connection object which is independent from the streaming object. It's rather trivial to setup a live stream.
And in case you're wondering how I know that, I was mucking around with creating a Flash 7 video player last night. Does anyone know how to get MTASC to output uncompressed SWF files rather than compressed SWC files? (Not to be confused with the confusingly named SWC class libraries. Bleh.) Flash Studio has a nice option for that, but SWFMILL and MTASC don't seem to want to listen.:-/
Scientists estimate that 98% of the minifigs created in the last 3 decades have lost a hand in a tragic vacuum accident, been melted by a magnifying glass, or eaten by your dog.
They forgot "blown apart by blasters, whips, and batrangs".
"Falling Refrigerator" is the old NASA joke about the Shuttle's ability to glide. It is so heavy and its descent rate is so fast that the pilots often think of it more as controlled falling than gliding. No ill will intended by that remark.
As for NASA not parachuting a craft of this size since the 60's, I stand by that statement. NASA's spokesperson said as much. I dare you to prove otherwise.
As for the anti-criticism about experience with parachutes, I'll take that criticism. I was not aware that the CIA had done successful mid-air captures prior to Genesis. None the less, Genesis DID have a fault with its parachute systems, even if the fault ended up being as simple as a backwards component. However, I will point out that the parachutes "used across the solar system" don't reach the sort of complexity we're talking about with the Orion or Genesis chutes. Mars landers, for example, only use drogue chute to slow descent. Because of the thin atmosphere, the craft tend to use either a powered landing or a inflatable airbags for landing. Parachutes designed for landing would have to be much too large and complex.
I'll be sure to consult with my wife and kids on that matter. Not to mention the teams I lead in developing sophisticated Java and Javascript applications.
I don't know why you're complaining. I already said, you totally won me over!
It's simple: NASA hasn't designed a space capsule in 40 years. They've been flying refrigerators^W gliders instead. They need to get back into the groove of landing large objects with parachutes before these tests become routine again.
And then there was the Genesis probe. That had to be the weirdest recovery scheme I've heard of yet. And on top of everything, the contractor installed the accelerometer backwards! Which tells you about how much experience NASA and its contractors has had with parachutes since the 60's.
Done. That will work in IE, FireFox, Safari, and Opera. Yet the code targets only the Canvas tag.
The one caveat is that the shunt does not yet have complete event passing. So you need to click outside of the falling blocks area for the keyboard commands to be read.
Netbeans has a surprisingly good Javascript editor due to the recent edition of Javascript support in Java 1.6. So from an editor perspective, Netbeans is great.:-)
From a debugging perspective, you can't go wrong with FireFox's error window. If something goes wrong, it will tell you. You can also debug live applications by using the "javascript:" url in the urlbar to tell you information about the state of the scripting engine. For example, try this here on Slashdot:
Another great tool is the DOM Inspector in FireFox. It makes it easy to see how the DOM changes as you muck with it in Javascript. You can even update the DOM for testing!
There are step-through debuggers like FireBug, but I've never felt the need to use one. You may find such a debugger more interesting, though.:-)
I've supported VBA-intensive Access apps that were created in the 2.0 days that still work quite fine in 2007
Listen, I don't know what Microsoft Access you were using, but the CORE VBA APIs in Access changed from 97 to 2000. No backward compatibility was provided, though 2000 did have an import program that tried (usually failed) to convert the APIs from the old core to the new. More often than not, I and my coworkers were stuck converting the code manually. (The company I worked for at the time did data analyses in the field, so Access was a pretty good fit. And when I say "in the field" I quite literally mean "in the field". Or perhaps I should say "out in fields".)
Saying MS broke compatibility between VB6 and VB.NET is just being purposefully disingenuous
Horseshit. What Microsoft did was disingenuous. They created a new language, slapped the Visual Basic name on it, then laughed their way to the bank as millions of customers purchased Visual Studio upgrades that would no longer support their existing investments. I will not take the blame for Microsoft's poor actions just because a Microsoft fanboy thinks that they walk on water!
If Microsoft wanted to be straight with their customers, they would have sunset the Visual Basic line altogether. At least then customers would have been clear on the lack of an upgrade path. Either that or they should have made more of an effort to provide backward compatibility for Visual Basic applications. There is absolutely no reason why the.NET platform can't play host to the classic VB APIs. Except for the fact that Microsoft wanted to force their customers to upgrade.
Of course, I suppose I should be thanking them. Thanks to Microsoft greed and ineptitude, Visual Basic has all but disappeared from the work environment. And for that, I am eternally grateful.
Not really. It happens to developers who write bad software and dont bother to read about or understand the best practices and guidance for the platform they're writing on.
There is some truth to that statement, and there is some underhanded crap going on. Being a Microsoft fanboy, I'm sure you've read their documentation before. And one of the things that has always struck me about Microsoft's documentation is that they do a really TERRIBLE job of documenting the APIs themselves. Instead, Microsoft focuses almost entirely on articles that tell you how to do things. Oh hey, you want a taskbar? Just mix these button stylings with these tab widgets and voila!
Which is great and all, except that a lot of the poor coding practices are based on Microsoft's "cool tricks". Since they don't refine their APIs (they replace them; hello ODBC/JET/DAO/ADO), make sure they're well documented, and push best practices, the result is that programmers never manage to develop best practices. Instead, they are constantly chasing Microsoft's API of the week.
Which also explains why Microsoft shops tend to be home to some of the worst coders I have EVER seen in my career. The fact that these guys can rub two brain cells together is often amazing. Computers? Nothing Scientific about that! Just ask Microsoft! We're big partners with them! And we can boast that we've only been stabbed in the back 3 times rather than the usual dozen!
What's that? Me have strong feelings about Microsoft? Well, I guess you could say that.
These are the folks who wrote user configuration in C:\Program Files\, or who explicitly checked for admin rights on startup, even if they didnt need it. Or who used hardcoded paths to user directories, rather than the SpecialFolders API.
As a Java programmer, I used to see such mistakes made commonly there as well. You know what happened? The APIs stayed the same, the offenders were thwacked (both by their peers and their code breaking), and eventually we got past that. Windows prog
Slashdot Mirror
I imagine the first question on everyone's mind will be, "Why do we need a new web browser?" To which I imagine the truthful answer is: "We don't. At least not for technical reasons."
I believe what Google is looking to accomplish is to trade on their brand name in an attempt to further dislodge Internet Explorer.
Remember when AOL purchased Netscape? AOL didn't care about the browser in the slightest. They wanted Netscape for the brand name. To the vast majority of users, Netscape was the Internet.
Google has since taken that place. Google is the Internet to many people. So much so that Google has felt compelled to to prevent the genericizing of their mark.
In this particular case, however, the strength of their mark works to Google's advantage. They have already convinced millions of users to install their desktop software. If they can further convince millions of users to install and use their browser, they can cause enough of a disruption to finally remove IE's leadership in the browser market. Especially given the solid work already done by FireFox, Opera, and Safari. With only another 10% marketshare loss on the whole, even the most stubborn websites will be forced to support third party browsers. And once they support third party browser, it will be very little time before the technological superiority of the alternative browsers causes them to add special features not available for Internet Explorer users.
It will be Netscape vs. Internet Explorer all over again. Except that instead of two giants fighting it out, it will be Microsoft against everyone else. And when everyone else happens to be giants in their own right, Microsoft's prospects will start looking rather grim.
In effect, this move is a blow aimed squarly at Redmond. Not for the purposes of truth, justice, and the freedom of all mankind; as I'm sure many will imagine. Rather, for the purpose of hitting back at Microsoft for their attempts to leverage their monopoly in promoting MSN Search over Google. The only difference is that Google Search is a good product and it is entrenched. Internet Explorer hasn't been a good product since Microsoft stopped developing it nearly 8 years ago (piss-poor upgrades pretending to be standards-compliant not withstanding), and its entrenchments are slowly falling to competition.
The current revision of ColdFusion is based on a J2EE server. The ColdFusion part of it is simply a scripting language running in a servlet container. The end result is that the developer can mix and match Java with ColdFusion, thus using his existing ColdFusion knowledge to extend into Java.
Or so the theory goes, at least. In practice, it seems to give CF developers the wrong idea.
He was offered only 3 years if he plead manslaughter. He refused. 15 to life (which means that he has a life sentence and is eligible for parole in 15 years) seems like a pretty good choice. Especially if he does reform. Society earns nothing by keeping him locked away longer if a parole board feels he's fit to leave. 15 years means that he's going to miss out on potentially some of the most interesting parts of what could have been his life. So it's not as if he will not learn anything.
I just don't know what to say about this. It's sad, upsetting, and yet just at the same time. On one hand I'm happy (can that even be the right word?) to see that he repented. On the other hand, I'm frightened by the thought that he killed her over a flippant remark about taking the kids to the doctor. On one hand it's also good that he didn't get off with a 3 year sentence, yet you can't help but feel for the fact that his own arrogance got him into this trouble.
Worst of all, events like this always create ugly questions in one's mind. e.g. It's a natural reaction to assume that murders are people who would stand out as a societal misfit. Someone who you would never place trust in or respect. Yet here we have an instance of someone that I had previously respected and was even considering contacting (partly because of several pushes from acquaintances) to work out new possible uses for Reiser's filesystem.
That's a very unsettling thought. If we cannot trust even the basic morality of people who have worked hard for their measures of respect in today's global community, who can we trust?
The whole thing is just... sad.
If he's looking for something cheaper, I can vouch for RAZRs working with Java apps. There's a simple USB Mini port on the side (cable not included) that can be used to hook it up to a computer and transfer applications.
I have also been told that many Nokia phones allow Java programs to be installed, but I do not know the details of those.
I'm still not impressed. I don't care how many whizzy-gig features Microsoft adds to their browser. It is still useless to developers until Microsoft installs standards support. And by standards support, we don't just mean fixing the broken setAttribute method. How about supporting a fucking decade old standards?!? Nope, still no mention of it. In fact, the bug on the issue was "closed by design".
By design? By fucking design?!?! BULLSHIT. Microsoft does not want to be interoperable with other Web Browsers. Period. If Microsoft really wanted to turn around their image in the market, they can start with something as stupidly simple as supporting addEventListener, removeEventListener, and dispatchEvent. I don't even care if the code looks like this:
^That's fucking WRONG and it would STILL be an improvement!
Microsoft can take their God damn browser and shove it where the sun don't shine for all I care. They have shown such incredible disdain for their customers, that I have to wonder why their even trying to hide it from the market.
*DEEP BREATH*
Microsoft, you are transparent. Your juvenile attempts at lock-in are NOT working and will NOT work. All you're going to do is piss off the people recommending software to grandma, grandpa, mom, dad, sisters, cousins, next door neighbors, school teachers, bosses, subordinates, government agencies, etc. IE will continue to lose market share. It won't be much longer before the alternative browsers reach critical mass. Many websites already show Firefox maintaining parity or even surpassing Internet Explorer. If you actually want to WIN the market, try competing for a change!
Can I get an AMEN?
Oh gosh, that's been there since the stone ages. All it means is that the *.ser format changes with each major release of the Java platform. Java is usually backward compatible with *.ser files, but it is not forward-compatible. Which means, for example, that Java 1.6 *.ser files cannot be read by Java 1.5.
In effect, nothing to write home about. And if you want to serialize Swing, you should probably use the XML Bean Serializer instead. You'll get far more portable results than with native serialization.
*sigh* There is nothing wrong with the Thread class. Suggesting that programmers extend it rather than implementing Runnable was a foolish. There is no compelling reason to extend Thread other than early documentation that suggested it. And the stop() method seemed like a good idea at the time, but it wasn't. Calling stop() can have very negative consequences on running code that hits a critical state. (This is not a Java-specific issue.) You should ALWAYS use a flag to force the thread to exit naturally. If you do anything else, I will personally come over there and pummel you with a copy of the Java API specification!
Where do you work again? :-P
You're quite correct about this. However, Microsoft's technologies at the time (based heavily on COM and DCOM) did not support SOAP very well. Thus it didn't see serious adoption until .NET hit the streets.
It might have been if this were true. But it's not. I was part of the JavaLobby forum (the Java advocacy meeting place at the time) and there was definitely a push-back against SOAP. A lot of programmers felt it was far too complex and that Microsoft would use binary encoded Microsoft crudola to negate the multi-platform nature of SOAP. (Especially since the early versions of SOAP often did little more than wrap serialized COM information.) This lead directly to a push to use the simpler XML-RPC instead. (RMI was unsuitable due to the Java-specific nature of it, and CORBA was just a mess.)
XML-RPC had a short and fun little life as the preferred object communications protocol, but Microsoft's marketing machine was already convincing people to use SOAP. Without a strong competitor and with a push from the business side to support interop between Java and .NET, SOAP libraries began appearing. Most famous, obviously, is Apache's toolkit. It wasn't long after that Sun began the JSR to support SOAP. It was horribly late to the game, but the feeling was that if Java was going to do it, it should do it as best as it possibly could.
And I'll be damned if Java didn't take SOAP and make it its own. I was constantly frustrated with .NET developers I was working with because they were working around their tools rather than working with them, thus making everyone's lives harder. Yet on our side, we were able to tell the most junior guy in the company to go expose a predetermined list of interfaces and its was done lickety split and far superior to our .NET counterparts.
So in effect, Java's excellent support for SOAP was more about "do the job right or don't do it at all" rather than an overwhelming positive reaction to the technology. In fact, I don't think anyone in the Java camp ever quite warmed up to it. But it worked and there were bigger fish to fricassee.
What in the world are you talking about? java.io.Serializable, right? I don't see anything in there that says "deprecated".
This would be especially weird because Serializable doesn't do anything. It's just a marker for a class to say "Yes, I am serializable!" Now you may be able to accomplish the same thing with the new attribute tags, but I see nothing that prevents you from using the Serializable interface.
I think you may be confusing Serializable with something else. :-)
In any case, deprecated features in Java usually don't go away. They simply are not recommended for use any longer.
Only if you consider choice to be a bug. Personally, I like the fact that I don't have to use the officially sanctioned method if I don't want to. And the older official methods do not deprecate with the introduction of the newer methods. Both can still be used.
In fact, there is very little deprecated overall in Java. It's just that there is often more than one way to skin a cat. Choose the one that works best for you.
Actually, SOAP was pushed heavily by Microsoft as part of .NET. Java took a more holistic approach and created APIs for SOAP, XML-RPC, REST, and many other services. There are about 3-4 different ways you can do each of them, with two of them being official or semi-official. (The reason for the break is that the methodology for providing such services was greatly enhanced by the attribute tags added in Java 1.6.)
If you're doing SOAP services, I'd blame the market for slurping up Microsoft's push rather than blaming your tools which happen to support the standard.
What's the old saying? "It's a poor craftsman who blames his tools?" ;-)
No. Because any CEO who immediately kills the market he's about to enter with his own statements is a fool.
If you want to get into the market of competing with Intel, you don't say that you could never make a CPU as good as Intel can.
Not at all. As you say, he would have denied it even if NVidia WAS planning a CPU. What actually speaks volumes IMHO, is the vehemence with which he denied it. Any CEO who's cover-denying a market move is not going to close his own doors by stating that the company could never make it in that space. He would give far weaker reasons so that when the announcement comes the market will still react favorably to their new product.
In other words: stick a fork in it, because this bit of tabloid reporting is dead.
Good question. I had to look it up. (Would it have killed the submitter or editor to include a link?)
Basically, the software gets its name from the list processing functions "map" (to take every item in a list and transform it, thus producing a list of the same size) and "reduce" (to perform an operation on a list that produces a single value or smaller list). The actual software has nothing to do with "map" and "reduce", but it does to tokenization and processing on massive amounts of data.
Presumably the Map/Reduce part comes from first normalizing the items being processed (a map operation) then reducing them down to a folded data structure (reduce), thus creating indexes of data suitable for fast searching.
Flash 7 is pretty ancient tech at this point. The vast majority of Flash games are Flash 8 with many of the new ones being made in Flash 9. However, the Nintendo Wii has the same limitation, so you may find Wii gaming sites to be useful on the device.
FFMPEG is pretty nifty. It especially does a good job in converting movies to FLV. But in this case, I need to make my own player. The code is done and working, but the target device won't read SWC files. They MUST be SWF. I'd rather use an OSS toolchain for quite a few reasons (not the least of which is that I'm not locked in to the FLA format), but I need to figure out how to turn off SWC compression. In Flash CS3 it's as easy as unchecking the "Compress Movie" checkbox. In SWFMILL, however, 'compress="0"' doesn't seem to be changing anything. :-/
Yes. The video object is independent from the connection object which is independent from the streaming object. It's rather trivial to setup a live stream.
And in case you're wondering how I know that, I was mucking around with creating a Flash 7 video player last night. Does anyone know how to get MTASC to output uncompressed SWF files rather than compressed SWC files? (Not to be confused with the confusingly named SWC class libraries. Bleh.) Flash Studio has a nice option for that, but SWFMILL and MTASC don't seem to want to listen. :-/
They forgot "blown apart by blasters, whips, and batrangs".
"Falling Refrigerator" is the old NASA joke about the Shuttle's ability to glide. It is so heavy and its descent rate is so fast that the pilots often think of it more as controlled falling than gliding. No ill will intended by that remark.
As for NASA not parachuting a craft of this size since the 60's, I stand by that statement. NASA's spokesperson said as much. I dare you to prove otherwise.
As for the anti-criticism about experience with parachutes, I'll take that criticism. I was not aware that the CIA had done successful mid-air captures prior to Genesis. None the less, Genesis DID have a fault with its parachute systems, even if the fault ended up being as simple as a backwards component. However, I will point out that the parachutes "used across the solar system" don't reach the sort of complexity we're talking about with the Orion or Genesis chutes. Mars landers, for example, only use drogue chute to slow descent. Because of the thin atmosphere, the craft tend to use either a powered landing or a inflatable airbags for landing. Parachutes designed for landing would have to be much too large and complex.
I'll be sure to consult with my wife and kids on that matter. Not to mention the teams I lead in developing sophisticated Java and Javascript applications.
I don't know why you're complaining. I already said, you totally won me over!
It's simple: NASA hasn't designed a space capsule in 40 years. They've been flying refrigerators^W gliders instead. They need to get back into the groove of landing large objects with parachutes before these tests become routine again.
And then there was the Genesis probe. That had to be the weirdest recovery scheme I've heard of yet. And on top of everything, the contractor installed the accelerometer backwards! Which tells you about how much experience NASA and its contractors has had with parachutes since the 60's.
So you linked to the article linked to in the Slashdot summary. The article that was debunked by the VERY FIRST POST...
Well I'm convinced!
http://java.dnsalias.com/tetris/ie/
Done. That will work in IE, FireFox, Safari, and Opera. Yet the code targets only the Canvas tag.
The one caveat is that the shunt does not yet have complete event passing. So you need to click outside of the falling blocks area for the keyboard commands to be read.
Netbeans has a surprisingly good Javascript editor due to the recent edition of Javascript support in Java 1.6. So from an editor perspective, Netbeans is great. :-)
From a debugging perspective, you can't go wrong with FireFox's error window. If something goes wrong, it will tell you. You can also debug live applications by using the "javascript:" url in the urlbar to tell you information about the state of the scripting engine. For example, try this here on Slashdot:
Another great tool is the DOM Inspector in FireFox. It makes it easy to see how the DOM changes as you muck with it in Javascript. You can even update the DOM for testing!
There are step-through debuggers like FireBug, but I've never felt the need to use one. You may find such a debugger more interesting, though. :-)
Listen, I don't know what Microsoft Access you were using, but the CORE VBA APIs in Access changed from 97 to 2000. No backward compatibility was provided, though 2000 did have an import program that tried (usually failed) to convert the APIs from the old core to the new. More often than not, I and my coworkers were stuck converting the code manually. (The company I worked for at the time did data analyses in the field, so Access was a pretty good fit. And when I say "in the field" I quite literally mean "in the field". Or perhaps I should say "out in fields".)
Horseshit. What Microsoft did was disingenuous. They created a new language, slapped the Visual Basic name on it, then laughed their way to the bank as millions of customers purchased Visual Studio upgrades that would no longer support their existing investments. I will not take the blame for Microsoft's poor actions just because a Microsoft fanboy thinks that they walk on water!
If Microsoft wanted to be straight with their customers, they would have sunset the Visual Basic line altogether. At least then customers would have been clear on the lack of an upgrade path. Either that or they should have made more of an effort to provide backward compatibility for Visual Basic applications. There is absolutely no reason why the .NET platform can't play host to the classic VB APIs. Except for the fact that Microsoft wanted to force their customers to upgrade.
Of course, I suppose I should be thanking them. Thanks to Microsoft greed and ineptitude, Visual Basic has all but disappeared from the work environment. And for that, I am eternally grateful.
There is some truth to that statement, and there is some underhanded crap going on. Being a Microsoft fanboy, I'm sure you've read their documentation before. And one of the things that has always struck me about Microsoft's documentation is that they do a really TERRIBLE job of documenting the APIs themselves. Instead, Microsoft focuses almost entirely on articles that tell you how to do things. Oh hey, you want a taskbar? Just mix these button stylings with these tab widgets and voila!
Which is great and all, except that a lot of the poor coding practices are based on Microsoft's "cool tricks". Since they don't refine their APIs (they replace them; hello ODBC/JET/DAO/ADO), make sure they're well documented, and push best practices, the result is that programmers never manage to develop best practices. Instead, they are constantly chasing Microsoft's API of the week.
Which also explains why Microsoft shops tend to be home to some of the worst coders I have EVER seen in my career. The fact that these guys can rub two brain cells together is often amazing. Computers? Nothing Scientific about that! Just ask Microsoft! We're big partners with them! And we can boast that we've only been stabbed in the back 3 times rather than the usual dozen!
What's that? Me have strong feelings about Microsoft? Well, I guess you could say that.
As a Java programmer, I used to see such mistakes made commonly there as well. You know what happened? The APIs stayed the same, the offenders were thwacked (both by their peers and their code breaking), and eventually we got past that. Windows prog