So let me get this straight... This astronomer has proven that if you make up some numbers based on one of a set of unproven hypotheses and feed that into an equation based on one or more other unproven hypotheses you can get a number out with 5 significant figures? The art of data production via anal extraction has reached new heights.
There might not be enough room for both the chip and camera in the eye. I'm sure it'd be a much more invasive proceedure and much more prone to infection. Probably also much more difficult to connect to the optic nerve.
Finally, putting the camera in the glasses adds much more flexibility for adjustment, replacement, upgrade, etc.
Software has killed many people. Radiation machines under software control have killed people in the US, and Canada as well as the incident the article mentions in Panama.
A software glitch caused the crash of the first F-22 prototype (noone died fortunately) and as someone else pointed out, the Patriot missile failure in the first Gulf War (Software wasn't ENTIRELY to blame there. The bug was known and the folks in the field were given instructions on how to avoid it, but didn't follow them)
The trick is who do you hold responsible? The software person who has no training in mission critical software and who's working 80 hour weeks to meet the deadline the idiot managers are shoving down vis throat?
After 10 years in the industry I'm FINALLY starting to see movement towards software creation as a serious engineering discipline. Schools are starting to offer programs in Software Engineering, the ACM and IEEE have agreed on an official code of conduct (tho IHMO it still has SERIOUS problems), and most importantly companies are starting to listen to their technial folks when they say "You can't do that!".
Liability is just another incentive to head down that road. We need to be sure we pin the liability on the right folks.
I've had cable (Comcast), DirectTV, and DishNetwork. Here's my thoughts on each:
Comcast Digital Cable: Had it turned off after 6 months. Only a few of the channels are actually digital and even those sucked. Static was somehow introduced in the signal before the digital encode step. The analog signals were almost unwatchable. The service went out from time to time. Lousy customer service.
DirectTV: I had it for 2 or 3 years. It started out great, but over time they seemed to increase the level of MPEG compression (to add more channels is my only guess) and picture quality went down eventually becoming rather poor. I only ever lost service once for a few hours in a major storm.
DishNetwork: Going on 6 months now. Similar to DirectTV in features. The PVR functions are very nice. Picture quality is noticibly better than any of the others (but still not great). Requires 2 dishes in my area rather than one to get all channels. My only complaint is that it seems a bit suseptable to weather. I've had it cut in and out in moderate weather. That could be my particular installation. Hard to say.
I had the same reaction. Actually it looks like the development tools were done in Java (yay, they'll run poorly everywhere!). There's no mention of how the actual Mobile Basic environment works on the phone. I doubt if it's a BASIC VM on top of a JVM. That just doesn't make sense!.
I certainly wouldn't describe Radiant as easy to use. If you're just cranking out some small maps it's probably adequate. But for anything significant it's unstable, very confusing to anyone without a significant technical understanding of how the engine is put together, and will frequently eat your map files. The Unreal tools are MUCH better.
What you say is true. There is a lot of stress, long hours, etc. etc. in this job. Even more so than in other programming jobs.
It can also be quite rewarding. I started in the game industry about 10 years ago and left due to the stress. Since then most of the jobs I've had have only been slightly less stressful, but not nearly as enjoyable. I've recently come back to games and I'm happier than I've been in a long time. It's all a matter of doing what you love.
A note to our original poster: You need to take a closer look at how the game industry actually works. Trying to get in based on your skill with designing levels for a particular game is probably not going to pay off as well as you hope. A lot of companies frown on hiring people from what they call the "mod community". Also your first job will almost certainly not be doing what you want to do. Check out the career advice from professional game developer organizations like GDC (www.gamasutra.com) and IGDA (www.igda.org).
If you're looking for something entry level check out my current employeer (www.globalvr.com) We're hiring for a few positions, mostly in QA.
I remember when our government was all buddy-buddy with Saddam for a variety of reasons. We knew he had WMD, we knew he was a world class asshole, but we didn't care.
In 2003 we suddenly find that the guy's a threat and has to be taken out RIGHT NOW. I'm still not clear on what exacly changed.
Of course pointing out that our government once supported the same monster we just removed is "divisive" and "unamerican" so I should probably expect my financial records to be analysed and get ready for a visit from the FBI.
We're talking about more than just financial losses though. Insurance is great if you're talking about your company's web site being down for a couple of days. That can be covered.
(Hypothetical and hopefully impossible example follows) Imagine an Enemy(tm) exploits a vulnerability in Windows to crash the control systems on an Aegis class destroyer and the ship goes down with all hands. You CAN'T cover that with insurance.
I agree with you that licensing isn't the answer, but what IS?
The federal government licenses many professionals. Lawyers, doctors, and architects are just a few examples. Licensing software folks just puts them in the same both as these other people: mainly that they can be sued for their mistakes and will be limited in the types of jobs they can take (if any) if they don't have a license.
In the near term if they adopt a licensing scheme the first iteration at least will be something like the programming language Ada.
The US military brass decided at one point that it would be great if all of their software was written in one language. They forned a comittee to design what they wanted. Ada was created and various military agencies started insisting on its use.
The problem was that what they designed wasn't flexible enough and over time Ada became less and less important.
Licensing will go a similiar route. The government will spend millions on a comittee to come up with requirements for a standard software engineer license. Then they'll find out that their licensed folks STILL screw up and eventually it'll become less of a big deal.
That being said, if software engineering licenses come into existance at the federal level you can bet I'm going to get one.
I suspect we'll have some sort of meaningful licensing scheme someday. It'll probably take a while tho. There will be a lot of pain and probably more than a few witch hunts before it happens.
One problem (of many) is of course that if you make programmers legally responsible for security failures you also need to give them the authority to say "No! You can't do it that way! I don't care WHAT Marketeering says!"
Texas has had licensing for a few years. Anyone know how it's worked out?
This sort of thing is starting to show up in the US as well. Mainly in "arcade" machines. You can enter nationwide or local tournaments for real cash. It's most common on golf machines in sports bars. This sort of thing has taken off to the extent that there are now professional video golf players in the world.
The specific myths don't apply to every project, but it points out what I've been saying for years. The only way to write good code is to study and practice. Associate with talented people, learn everything you can from them, keep up with industry best practices, and constantly evaluate everything you do in terms of its quality.
The "1 in 3" statistic is bogus. I'm not sure of its origin. If it were true I and many of my friends would be dead now.
The last statistic I heard from a reliable source was several years back (in an AMA publication) and it claimed a 1 in 50 chance of "serious injury or death" each year. Cars were listed at about 1 in 100. If you remove wheelie popping, traffic splitting, morons on sport bikes from the mix I imagine the stats get much better
My personal experience (not a statisticly significant sample): I know about 15 motorcyclists. They average about 5 years of experience each. 100% of them (myself included) have crashed at least once. None of those crashes was serious enough to require medical attention. On a side note, 2 of the 15 HAVE been in serious accidents requiring hospitalization; they were both driving cars at the time.
Fighter pilots also tend to have a lot more training on their equipment than motorcyclists.
I'm kind of split on this issue. Not having to take my eyes off the road to check speed, rpm, location, etc would be nice, but having it constantly in my field of view would be distracting. It would also take a LOT of getting used to.
It's implied that the Galactica is the LAST Battlestar. They use the word similarly to how we use the word "battleship". Other Battlestars are mentioned in the show, generally in the long lists of casualties.
Yes, but it was done differently than in most space battles. The sounds were muted, no heroic blaring music. Instead of loud obnoxious laser blasts, roaring expolsions, and screaming ships we get weapons that softly "ratta-tat-tat", ships that whir and explosions that go poof. The battle music was a somber, militaristic percussion piece.
It's not as compelling as the idea of silent space battles but it's a step in the right direction.
Even if every country in the world outlawed spam I doubt if it would have much effect. A very large portion of todays spam is already sent by illegal means (hack or virus someone elses box, use it to spam the world). I doubt very much if the spammers would give up their so called business just because of another law in their way.
Take the American "do-not-call" list as an example. I know it's done wonders to prevent idiot marketeers from trying to send faxes to my home voice line at 2am. Not.
I've heard of this. The complexity of working with such a device blends many of the problems of hardware and software. I think of it as along the same lines as creating a custom embedded device that includes "firmware" as part of its design. It's more complex than pure hardware.
Public betas are often costly and tend to have questionable value for reliability. My guess is that the apps you describe were already rock solid before the beta started.
There are 2 big problems:
1: End users are usually more concerned with using the product than they are with doing consistent repeatable testing.
2: Most end users are incapable of writing good bug reports.
Public betas are VERY useful tools for public relations and for trying to figure out what changes users would like to see in future versions.
Most software DOES go through fairly stringent approval processes. There are even some standardised ones (WHQL for example), but I haven't seen a good standard yet.
The problem is in defining what exactly consitutes a GOOD approval process for any given piece of software. It's often easier to define this for hardware. You define proper operating ranges and how the thing should respond when used or abused in specific ways, and the result is often a product that will behave as expected in almost all realworld conditions.
In software the failure cases tend to be more open-ended. The set of all possible types of input to the system may involve infinite permutations. You can only test the ones you thought of, and if you thought of them they're probably handled correctly in the first place. If you're developing a commercial app you have to deal with the fact that the hardware and OS your program relies on may in fact be subtly flawed. Also, any set of tests for a piece of software must be custom designed for that piece of software.
Ideally software testing is more of a verification process than a corrective process. Your tests should (but rarely are) be created at the same time as your design and run continuously throughout the project lifecycle.
Slashdot Mirror
So let me get this straight... This astronomer has proven that if you make up some numbers based on one of a set of unproven hypotheses and feed that into an equation based on one or more other unproven hypotheses you can get a number out with 5 significant figures? The art of data production via anal extraction has reached new heights.
There might not be enough room for both the chip and camera in the eye. I'm sure it'd be a much more invasive proceedure and much more prone to infection. Probably also much more difficult to connect to the optic nerve.
Finally, putting the camera in the glasses adds much more flexibility for adjustment, replacement, upgrade, etc.
A software glitch caused the crash of the first F-22 prototype (noone died fortunately) and as someone else pointed out, the Patriot missile failure in the first Gulf War (Software wasn't ENTIRELY to blame there. The bug was known and the folks in the field were given instructions on how to avoid it, but didn't follow them)
The trick is who do you hold responsible? The software person who has no training in mission critical software and who's working 80 hour weeks to meet the deadline the idiot managers are shoving down vis throat?
After 10 years in the industry I'm FINALLY starting to see movement towards software creation as a serious engineering discipline. Schools are starting to offer programs in Software Engineering, the ACM and IEEE have agreed on an official code of conduct (tho IHMO it still has SERIOUS problems), and most importantly companies are starting to listen to their technial folks when they say "You can't do that!".
Liability is just another incentive to head down that road. We need to be sure we pin the liability on the right folks.
Comcast Digital Cable: Had it turned off after 6 months. Only a few of the channels are actually digital and even those sucked. Static was somehow introduced in the signal before the digital encode step. The analog signals were almost unwatchable. The service went out from time to time. Lousy customer service.
DirectTV: I had it for 2 or 3 years. It started out great, but over time they seemed to increase the level of MPEG compression (to add more channels is my only guess) and picture quality went down eventually becoming rather poor. I only ever lost service once for a few hours in a major storm.
DishNetwork: Going on 6 months now. Similar to DirectTV in features. The PVR functions are very nice. Picture quality is noticibly better than any of the others (but still not great). Requires 2 dishes in my area rather than one to get all channels. My only complaint is that it seems a bit suseptable to weather. I've had it cut in and out in moderate weather. That could be my particular installation. Hard to say.
I had the same reaction. Actually it looks like the development tools were done in Java (yay, they'll run poorly everywhere!). There's no mention of how the actual Mobile Basic environment works on the phone. I doubt if it's a BASIC VM on top of a JVM. That just doesn't make sense!.
I certainly wouldn't describe Radiant as easy to use. If you're just cranking out some small maps it's probably adequate. But for anything significant it's unstable, very confusing to anyone without a significant technical understanding of how the engine is put together, and will frequently eat your map files. The Unreal tools are MUCH better.
It can also be quite rewarding. I started in the game industry about 10 years ago and left due to the stress. Since then most of the jobs I've had have only been slightly less stressful, but not nearly as enjoyable. I've recently come back to games and I'm happier than I've been in a long time. It's all a matter of doing what you love.
A note to our original poster: You need to take a closer look at how the game industry actually works. Trying to get in based on your skill with designing levels for a particular game is probably not going to pay off as well as you hope. A lot of companies frown on hiring people from what they call the "mod community". Also your first job will almost certainly not be doing what you want to do. Check out the career advice from professional game developer organizations like GDC (www.gamasutra.com) and IGDA (www.igda.org).
If you're looking for something entry level check out my current employeer (www.globalvr.com) We're hiring for a few positions, mostly in QA.
I remember when our government was all buddy-buddy with Saddam for a variety of reasons. We knew he had WMD, we knew he was a world class asshole, but we didn't care.
In 2003 we suddenly find that the guy's a threat and has to be taken out RIGHT NOW. I'm still not clear on what exacly changed.
Of course pointing out that our government once supported the same monster we just removed is "divisive" and "unamerican" so I should probably expect my financial records to be analysed and get ready for a visit from the FBI.
(Hypothetical and hopefully impossible example follows) Imagine an Enemy(tm) exploits a vulnerability in Windows to crash the control systems on an Aegis class destroyer and the ship goes down with all hands. You CAN'T cover that with insurance.
I agree with you that licensing isn't the answer, but what IS?
The federal government licenses many professionals. Lawyers, doctors, and architects are just a few examples. Licensing software folks just puts them in the same both as these other people: mainly that they can be sued for their mistakes and will be limited in the types of jobs they can take (if any) if they don't have a license.
The US military brass decided at one point that it would be great if all of their software was written in one language. They forned a comittee to design what they wanted. Ada was created and various military agencies started insisting on its use.
The problem was that what they designed wasn't flexible enough and over time Ada became less and less important.
Licensing will go a similiar route. The government will spend millions on a comittee to come up with requirements for a standard software engineer license. Then they'll find out that their licensed folks STILL screw up and eventually it'll become less of a big deal.
That being said, if software engineering licenses come into existance at the federal level you can bet I'm going to get one.
One problem (of many) is of course that if you make programmers legally responsible for security failures you also need to give them the authority to say "No! You can't do it that way! I don't care WHAT Marketeering says!"
Texas has had licensing for a few years. Anyone know how it's worked out?
How about the continued poliferation of so-called Digital Rights Management?
Ahhh... I could very easily imagine the 1 in 3 number holding for the group you describe. Thanks for the clarification.
The specific myths don't apply to every project, but it points out what I've been saying for years. The only way to write good code is to study and practice. Associate with talented people, learn everything you can from them, keep up with industry best practices, and constantly evaluate everything you do in terms of its quality.
The last statistic I heard from a reliable source was several years back (in an AMA publication) and it claimed a 1 in 50 chance of "serious injury or death" each year. Cars were listed at about 1 in 100. If you remove wheelie popping, traffic splitting, morons on sport bikes from the mix I imagine the stats get much better
My personal experience (not a statisticly significant sample): I know about 15 motorcyclists. They average about 5 years of experience each. 100% of them (myself included) have crashed at least once. None of those crashes was serious enough to require medical attention. On a side note, 2 of the 15 HAVE been in serious accidents requiring hospitalization; they were both driving cars at the time.
I'm kind of split on this issue. Not having to take my eyes off the road to check speed, rpm, location, etc would be nice, but having it constantly in my field of view would be distracting. It would also take a LOT of getting used to.
It's implied that the Galactica is the LAST Battlestar. They use the word similarly to how we use the word "battleship". Other Battlestars are mentioned in the show, generally in the long lists of casualties.
It's not as compelling as the idea of silent space battles but it's a step in the right direction.
Take the American "do-not-call" list as an example. I know it's done wonders to prevent idiot marketeers from trying to send faxes to my home voice line at 2am. Not.
I want to patent "a method for limiting the decay of society by kicking the crap out of idiots at the patent office"
I've heard of this. The complexity of working with such a device blends many of the problems of hardware and software. I think of it as along the same lines as creating a custom embedded device that includes "firmware" as part of its design. It's more complex than pure hardware.
There are 2 big problems:
1: End users are usually more concerned with using the product than they are with doing consistent repeatable testing.
2: Most end users are incapable of writing good bug reports.
Public betas are VERY useful tools for public relations and for trying to figure out what changes users would like to see in future versions.
The problem is in defining what exactly consitutes a GOOD approval process for any given piece of software. It's often easier to define this for hardware. You define proper operating ranges and how the thing should respond when used or abused in specific ways, and the result is often a product that will behave as expected in almost all realworld conditions.
In software the failure cases tend to be more open-ended. The set of all possible types of input to the system may involve infinite permutations. You can only test the ones you thought of, and if you thought of them they're probably handled correctly in the first place. If you're developing a commercial app you have to deal with the fact that the hardware and OS your program relies on may in fact be subtly flawed. Also, any set of tests for a piece of software must be custom designed for that piece of software.
Ideally software testing is more of a verification process than a corrective process. Your tests should (but rarely are) be created at the same time as your design and run continuously throughout the project lifecycle.