I just found out the guy who works in the office next to me has never heard of the practice of parameterizing database statements to avoid SQL injection. He has about five years of development experience at several major US companies. This was the first project that I worked with him on that he wrote data access code. Apparently a lot of people still don't get the point. I recommended that he be "quarantined and trained" to my boss, but I'm sure he'll go right on writing code.
95% or the people I talk to think that as long as they use stored procedures, they'll be fine, even if they don't parameterize the call. It takes all the breath I have to convice these people that it's the parameterization that matters, not the use of stored procedures. Even after demonstrations, sometimes they still don't believe me.
Parameterized queries provide the exact same level of control without any app-level scrubbing. Performance is almost always nearly identical.
Dynamic SQL inside sp's defeats the entire point of sp's. The only difference is that you have to do data sanitization with T-SQL instead of a language that has evolved since the 1980s.
It's not all bad. At least you throw a 25mpg car into the pool for people who are not new car buyers. Just because you aren't driving it doesn't mean that nobody is driving it.
Better than buying a Prius or keeping your 25mpg car, drive a tiny micro-car that gets 60mpg. You aren't really trying hard enough to save the environment unless you are willing to risk your own life on the road for it. All those pansies in Priuses are simply doing the best they can without actually suffering at all. All of the death-traps from the 80s and 90s (Chevy Sprint, Dodge Omni, Honda Civic, etc...) got 50mpg easily.
So, how many drivers are at the edge of detonation for more than 0.1% of their drive to work? Car engines are not preigniting while cruising. Therefore, higher octane is likely to have very little effect on fuel economy for anything except a small turbo or a hybrid where the engine is purposely run at full tilt or turned off.
I have a 5.7 liter Dodge Challenger. You'd figure that if any car could get the last bit of usefulness out of a speck of fuel, it would be one of the new muscle cars that are dyno-racing each other in the magazines. My owners manual actually has a big paragraph stating that I will get absolutely no benefit from premium gasoline and I shouldn't even think about it.
Besides, knock is more likely to happen with the throttle fully depressed. Under what circumstances are you cruising for long distances at full throttle? Timing retardation due to knock is much more likely to reduce the peak HP number than fuel economy. Conversely, improving knock resistance is much more likely to increase HP, but not fuel economy.
Do you want to poison and pollute the world we're living in?
That's a loaded question. If that were the only question, then nearly all modern society would be thrown away. The result would be a population drop to under 4 billion people and a much lower quality of life for the survivors. Besides, poison is relative, so the question doesn't even have a precise meaning. There's a bumper crop of oil-eating bacteria in the Gulf of Mexico this summer.
Mobile communications is still a young technology. Charging by the byte is going to stunt the growth of technology. With an unlimited plan, people will experiment with stuff like remotely accessible cameras in the home and video chat. When video chat costs more per minute than a phone call due to bandwidth usage, the technology stagnates.
The explosion of smartphones the past few years was partly due to unlimited data plans coming down to an accessible price. If you accidentally choose the low volume AT&T plan and watch a single movie, it will cost $40.00 in over-bandwidth fees. With the new 960x640 screen rumored to be on the next iPhone, you could spend well over $100.00 to watch a single movie at max viewable resolution.
Having unlimited plans and throttling high-bandwidth users both efficiently and fairly uses the network and encourages adoption of new technology, while allowing the carrier to easily forecast income and plan upgrades. Pay-per-byte causes confusion, sticker shock, and timid adoption. What happens if your phone get rooted and runs up a $10,000.00 bill?
Sometimes I pre-pay for electricity. I'm on budget pay and I sometimes have a negative balance and still pay that month. The main problem is that electricity - in most cases - comes from coal, uranium, or gas. Consumption of a kilowatt-hour is consumption of fuel. Bandwidth doesn't have quite the same cost structure.
I never expected them to detect weight. But, 532 pounds of metal should be more likely to register on an inductive sensor than a thirty pound bicycle. The center of masses are about the same, but the bicycle's lowest metal point is a bit lower.
The market also feels the fortune 50 company I work at is worth less than our inventory on hand. It's not like we're in a dying industry, we're in health care. If you bought all of our stock, then you'd make your money back with three years of profits (based on history). If you bought all of Apple's stock, it would be 30 years (once again, based on history) before you made your $234 billion dollars in profit. The market is insane and its conclusions are nearly meaningless.
Yea, the ISPs in the US are providing all the bandwidth they can for the money collected. That's why we are #1 in the world for broadband penetration... oh, wait.
But, if a batch program does what you need, why in god's name would you use anything more complicated than that?
Because I've seen people push batch files way futher than they were ever intended to be pushed. Most of the time, a horrendously complicated batch file can be re-implemented as a fairly simple script in almost any scripting language. It's stupid to do it in batch, but it works. This is exactly the case where "it works" isn't good enough.
I don't know who told you batch scripts were hard to maintain, there is literally nothing to maintain
Any batch file that is more sophisticated than a handful of external program calls will become difficult to maintain. As soon as you start adding menu choices, calls to other batch files, iteration, or error trapping logic, batch files get ugly.
Basically, if it's for the IT guys, the script is more helpful. If it's for the end users, an app looks much more professional. There are various options between scripts and apps that you can use depending on how much effort this warrants.
Yes, there are options between batch scripts and apps, like scripts in real scripting languages. Perl, Python, PowerShell, VBScript, KiX, AutoIT, and bash are all much more powerful than DOS batch and don't add a lot of complicated process or opacity.
For example, write a DOS batch script that pings all of the IPs on a subnet and emails the results. It can be done in DOS batch, but it would be suicide. It is trivial in a real scripting language.
you don't understand the GP's philosophy at all. He's applying basic engineering concepts, like Keep It Stupid Simple, and you're weeding him out because he doesn't use whichever useless design paradigm flavor of the month you prefer
Nope, I'm weeding him out because he doesn't value readability and maintainability over functionality. DOS batch is only more readable in the most trivial cases. For those same cases, every other scripting language is identically easy to read (except VBScript which, for some reason, makes it non-trivial to shell out to another program).
...and make image maintenance a nightmare. Right now, I have 2 base OS images at about 2GB each and 3TB of virtual machine files for labs. If I switched from copying VM files to imaging an entire OS with VMs, I'd have 3TB of OS images. Today, if I change a hardware platform or want to get current with service packs, it takes me a few hours. If I switched to pure imaging, I'd have to redo all 3TB of images.
Of course I was running them with administrator rights, the whole point of these scripts is to copy files to the Program Files directory. UAC hates this, but it is my requirement. I spend a lot of time going through the following process -- Install OS, Install.Net Framework, Copy 50GB or so of files. I do this to refresh lab computers for week long training sessions. I do it at least a thousand times a year. Until Vista, I was very happy using batch files. After Vista, it's a pain in the butt with batch files.
I've found that UAC in Vista and Windows 7 hate batch files. Some of my old processes that are still batch file based fail silently on new operating systems. Suck it up and move into the 1990's at least.
DOS batch files make reusing scripts very difficult. Pretty much anything else is better. The lack of a function or subroutine construct is its biggest downfall. This can quickly lead to cut-and-paste hell or a pile of work-arounds that makes the scripts almost impossible to maintain.
BTW, your quote:
If it's stupid and it works, it's not stupid.
... is pretty much the opposite of how professional programmers feel. My philosophy is that any idiot can keep banging on the keyboard until it works. It takes a reasonably competent programmer to make it so that the next guy can understand it and maintain it. It takes a good programmer to make it so a new unanticipated feature can be added quickly without disturbing the system too much. I actually ask questions at interviews to try to find people with your philosophy and weed them out.
You folks do understand that the weight of the water above the well is what is causing this problem, right?
The exact same water that is creating the pressure to push the oil out is also creating pressure at the opening to push it back in. The relative sizes of the pipe opening and the entire bottom of the gulf don't matter as pressure is force per area, not total force.
So, why isn't it a requirement to have something built and ready to go for the eventuality of a pipe failure a mile down? If I were in charge of the world, I wouldn't have granted the permit to drill until a plan was filed for all of the "unlikely, but possible" scenarios. The government's most basic job is the protection of the commons.
The day I heard about this, I thought to myself, "Oh crap, no one knows how to deal with this. This isn't going to be solved until someone invents a new solution, builds it, and deploys it." The inventing and building should have already been done.
You're generally right, but I make it a point to write code with a watchful eye on things like limiting attack surface and granting least priviledge. I'm usually foiled by the people who implement my projects. For example, it drives me nuts that our implementers are willing to put passwords in plain text in config files when my platform offers a command line utility to encrypt them that is transparent to the application. Every time I'm involved in an implementation, the passwords get encrypted. By the time I get around to see the software again, someone had to troubleshoot the system or change the password and they left it in the clear.
The guys on the other side of the wall are always the idiots, no matter what side of the wall you work on.
relying on them as your primary recovery plan can be both costly and inconvenient
Costly? When you order 5000 Dell computers, the guy at the other end of the phone doesn't really care. If you get the top shelf warranty on those 5000 computers, he's going to DisneyLand with the commission check. It's impossible for a warranty to be both a great deal for the customer and a great deal for the seller. The seller certainly loves it, so guess who loses.
Also, the shiny new Dell the tech dropped on the desk isn't ready to go either. It didn't come with patches, it will have to go through the same process to get updated. It also isn't a member of the domain, doesn't have any corporate software on it, and generally isn't ready for anything except surfing the web or playing solitaire.
The "may see an advantage" you mentioned is exactly what I was asking for detail on. My empirical testing showed that 64-bit isn't a magic bullet, unless your apps have outgrown the memory limitations of the 32-bit world. There are a few natural disadvantages of 64-bit. For example, pointers are bigger, causing more cache misses. I've met way to many people that think that it is a foregone conclusion that 64-bit is faster than 32-bit all the time. I actually had someone respond "How can that be?" to a benchmark result showing 32-bit XP 15% faster than 64-bit XP for one specific workload. For those who may fall into this category, there are many reasons, from immature 64-bit drivers to hand-tweaked 32-bit app code whose 64-bit equivalent hasn't had the same number of years of care and tweaking.
I agree with everything except the warranty. A home user should get a warranty, but medium to large corporatations should buy reliable computers and deal with failure themselves. Buying one spare for every ten computers costs far less than a warranty on all of the computers an gives you immediate repacement instead of one day. The pulled computers can be refurbed at your liesure. A typical failure will be a hard drive, power supply, or maybe RAM. That's less than a hundred bucks in parts. The labor is usually about the same because a corporate tech usually has to let the Dell guy in, walk him to the site, and then install all the custom stuff after he leaves.
Do you have anything to back this up? I've done a lot of testing of I/O intensive workloads on XP and found 32-bit XP measureably faster than 64-bit XP. I'm sure 64-bit rocks for applications that require a lot of memory, but I can't see any reason why "64-bitness" should be an advantage for any application with a working set smaller than 2GB.
The con is the statement that the control shaft will require very little power to operate. If you stop the input shaft, you can see that the control shaft works the same as the planetary gear system on many commercial devices, like a cordless drill. I don't know about you, but the planetary drive on my cordless drill doesn't prevent me from going through batteries when I'm doing something heavy like using a hole saw. Given that, at times, the control shaft will require no less power than the input shaft, you would need a way to provide high power at variable speed. Therefore, you would need a CVT to operate your CVT.
My other concern is the gear tooth size. A traditional transmission uses gears that are quite large and have few teeth. The D-Drive has gear teeth with at least two orders of magnitude smaller teeth in critical places, and they are at a smaller radius. I think this thing will need to be huge to transmit enough power to move a vehicle. Large radius gears are necessary to transmit a lot of power. The planetary design of the D-Drive does not permit large radius gears.
Slashdot Mirror
I just found out the guy who works in the office next to me has never heard of the practice of parameterizing database statements to avoid SQL injection. He has about five years of development experience at several major US companies. This was the first project that I worked with him on that he wrote data access code. Apparently a lot of people still don't get the point. I recommended that he be "quarantined and trained" to my boss, but I'm sure he'll go right on writing code.
95% or the people I talk to think that as long as they use stored procedures, they'll be fine, even if they don't parameterize the call. It takes all the breath I have to convice these people that it's the parameterization that matters, not the use of stored procedures. Even after demonstrations, sometimes they still don't believe me.
Parameterized queries provide the exact same level of control without any app-level scrubbing. Performance is almost always nearly identical.
Dynamic SQL inside sp's defeats the entire point of sp's. The only difference is that you have to do data sanitization with T-SQL instead of a language that has evolved since the 1980s.
It's not all bad. At least you throw a 25mpg car into the pool for people who are not new car buyers. Just because you aren't driving it doesn't mean that nobody is driving it.
Better than buying a Prius or keeping your 25mpg car, drive a tiny micro-car that gets 60mpg. You aren't really trying hard enough to save the environment unless you are willing to risk your own life on the road for it. All those pansies in Priuses are simply doing the best they can without actually suffering at all. All of the death-traps from the 80s and 90s (Chevy Sprint, Dodge Omni, Honda Civic, etc...) got 50mpg easily.
So, how many drivers are at the edge of detonation for more than 0.1% of their drive to work? Car engines are not preigniting while cruising. Therefore, higher octane is likely to have very little effect on fuel economy for anything except a small turbo or a hybrid where the engine is purposely run at full tilt or turned off.
I have a 5.7 liter Dodge Challenger. You'd figure that if any car could get the last bit of usefulness out of a speck of fuel, it would be one of the new muscle cars that are dyno-racing each other in the magazines. My owners manual actually has a big paragraph stating that I will get absolutely no benefit from premium gasoline and I shouldn't even think about it.
Besides, knock is more likely to happen with the throttle fully depressed. Under what circumstances are you cruising for long distances at full throttle? Timing retardation due to knock is much more likely to reduce the peak HP number than fuel economy. Conversely, improving knock resistance is much more likely to increase HP, but not fuel economy.
Do you want to poison and pollute the world we're living in?
That's a loaded question. If that were the only question, then nearly all modern society would be thrown away. The result would be a population drop to under 4 billion people and a much lower quality of life for the survivors. Besides, poison is relative, so the question doesn't even have a precise meaning. There's a bumper crop of oil-eating bacteria in the Gulf of Mexico this summer.
Mobile communications is still a young technology. Charging by the byte is going to stunt the growth of technology. With an unlimited plan, people will experiment with stuff like remotely accessible cameras in the home and video chat. When video chat costs more per minute than a phone call due to bandwidth usage, the technology stagnates.
The explosion of smartphones the past few years was partly due to unlimited data plans coming down to an accessible price. If you accidentally choose the low volume AT&T plan and watch a single movie, it will cost $40.00 in over-bandwidth fees. With the new 960x640 screen rumored to be on the next iPhone, you could spend well over $100.00 to watch a single movie at max viewable resolution.
Having unlimited plans and throttling high-bandwidth users both efficiently and fairly uses the network and encourages adoption of new technology, while allowing the carrier to easily forecast income and plan upgrades. Pay-per-byte causes confusion, sticker shock, and timid adoption. What happens if your phone get rooted and runs up a $10,000.00 bill?
Sometimes I pre-pay for electricity. I'm on budget pay and I sometimes have a negative balance and still pay that month. The main problem is that electricity - in most cases - comes from coal, uranium, or gas. Consumption of a kilowatt-hour is consumption of fuel. Bandwidth doesn't have quite the same cost structure.
I never expected them to detect weight. But, 532 pounds of metal should be more likely to register on an inductive sensor than a thirty pound bicycle. The center of masses are about the same, but the bicycle's lowest metal point is a bit lower.
I'm not surprised, most of the sensors I drive over fail to detect my 532 pound motorcycle. I be more surprised if one of them did detect a bicycle.
The market also feels the fortune 50 company I work at is worth less than our inventory on hand. It's not like we're in a dying industry, we're in health care. If you bought all of our stock, then you'd make your money back with three years of profits (based on history). If you bought all of Apple's stock, it would be 30 years (once again, based on history) before you made your $234 billion dollars in profit. The market is insane and its conclusions are nearly meaningless.
Yea, the ISPs in the US are providing all the bandwidth they can for the money collected. That's why we are #1 in the world for broadband penetration... oh, wait.
But, if a batch program does what you need, why in god's name would you use anything more complicated than that?
Because I've seen people push batch files way futher than they were ever intended to be pushed. Most of the time, a horrendously complicated batch file can be re-implemented as a fairly simple script in almost any scripting language. It's stupid to do it in batch, but it works. This is exactly the case where "it works" isn't good enough.
I don't know who told you batch scripts were hard to maintain, there is literally nothing to maintain
Any batch file that is more sophisticated than a handful of external program calls will become difficult to maintain. As soon as you start adding menu choices, calls to other batch files, iteration, or error trapping logic, batch files get ugly.
Basically, if it's for the IT guys, the script is more helpful. If it's for the end users, an app looks much more professional. There are various options between scripts and apps that you can use depending on how much effort this warrants.
Yes, there are options between batch scripts and apps, like scripts in real scripting languages. Perl, Python, PowerShell, VBScript, KiX, AutoIT, and bash are all much more powerful than DOS batch and don't add a lot of complicated process or opacity.
For example, write a DOS batch script that pings all of the IPs on a subnet and emails the results. It can be done in DOS batch, but it would be suicide. It is trivial in a real scripting language.
you don't understand the GP's philosophy at all. He's applying basic engineering concepts, like Keep It Stupid Simple, and you're weeding him out because he doesn't use whichever useless design paradigm flavor of the month you prefer
Nope, I'm weeding him out because he doesn't value readability and maintainability over functionality. DOS batch is only more readable in the most trivial cases. For those same cases, every other scripting language is identically easy to read (except VBScript which, for some reason, makes it non-trivial to shell out to another program).
...and make image maintenance a nightmare. Right now, I have 2 base OS images at about 2GB each and 3TB of virtual machine files for labs. If I switched from copying VM files to imaging an entire OS with VMs, I'd have 3TB of OS images. Today, if I change a hardware platform or want to get current with service packs, it takes me a few hours. If I switched to pure imaging, I'd have to redo all 3TB of images.
Of course I was running them with administrator rights, the whole point of these scripts is to copy files to the Program Files directory. UAC hates this, but it is my requirement. I spend a lot of time going through the following process -- Install OS, Install .Net Framework, Copy 50GB or so of files. I do this to refresh lab computers for week long training sessions. I do it at least a thousand times a year. Until Vista, I was very happy using batch files. After Vista, it's a pain in the butt with batch files.
But DOS batch files still work just fine.
I've found that UAC in Vista and Windows 7 hate batch files. Some of my old processes that are still batch file based fail silently on new operating systems. Suck it up and move into the 1990's at least.
BTW, your quote:
If it's stupid and it works, it's not stupid.
... is pretty much the opposite of how professional programmers feel. My philosophy is that any idiot can keep banging on the keyboard until it works. It takes a reasonably competent programmer to make it so that the next guy can understand it and maintain it. It takes a good programmer to make it so a new unanticipated feature can be added quickly without disturbing the system too much. I actually ask questions at interviews to try to find people with your philosophy and weed them out.
You folks do understand that the weight of the water above the well is what is causing this problem, right?
The exact same water that is creating the pressure to push the oil out is also creating pressure at the opening to push it back in. The relative sizes of the pipe opening and the entire bottom of the gulf don't matter as pressure is force per area, not total force.
So, why isn't it a requirement to have something built and ready to go for the eventuality of a pipe failure a mile down? If I were in charge of the world, I wouldn't have granted the permit to drill until a plan was filed for all of the "unlikely, but possible" scenarios. The government's most basic job is the protection of the commons.
The day I heard about this, I thought to myself, "Oh crap, no one knows how to deal with this. This isn't going to be solved until someone invents a new solution, builds it, and deploys it." The inventing and building should have already been done.
You're generally right, but I make it a point to write code with a watchful eye on things like limiting attack surface and granting least priviledge. I'm usually foiled by the people who implement my projects. For example, it drives me nuts that our implementers are willing to put passwords in plain text in config files when my platform offers a command line utility to encrypt them that is transparent to the application. Every time I'm involved in an implementation, the passwords get encrypted. By the time I get around to see the software again, someone had to troubleshoot the system or change the password and they left it in the clear.
The guys on the other side of the wall are always the idiots, no matter what side of the wall you work on.
relying on them as your primary recovery plan can be both costly and inconvenient
Costly? When you order 5000 Dell computers, the guy at the other end of the phone doesn't really care. If you get the top shelf warranty on those 5000 computers, he's going to DisneyLand with the commission check. It's impossible for a warranty to be both a great deal for the customer and a great deal for the seller. The seller certainly loves it, so guess who loses.
Also, the shiny new Dell the tech dropped on the desk isn't ready to go either. It didn't come with patches, it will have to go through the same process to get updated. It also isn't a member of the domain, doesn't have any corporate software on it, and generally isn't ready for anything except surfing the web or playing solitaire.
The "may see an advantage" you mentioned is exactly what I was asking for detail on. My empirical testing showed that 64-bit isn't a magic bullet, unless your apps have outgrown the memory limitations of the 32-bit world. There are a few natural disadvantages of 64-bit. For example, pointers are bigger, causing more cache misses. I've met way to many people that think that it is a foregone conclusion that 64-bit is faster than 32-bit all the time. I actually had someone respond "How can that be?" to a benchmark result showing 32-bit XP 15% faster than 64-bit XP for one specific workload. For those who may fall into this category, there are many reasons, from immature 64-bit drivers to hand-tweaked 32-bit app code whose 64-bit equivalent hasn't had the same number of years of care and tweaking.
I agree with everything except the warranty. A home user should get a warranty, but medium to large corporatations should buy reliable computers and deal with failure themselves. Buying one spare for every ten computers costs far less than a warranty on all of the computers an gives you immediate repacement instead of one day. The pulled computers can be refurbed at your liesure. A typical failure will be a hard drive, power supply, or maybe RAM. That's less than a hundred bucks in parts. The labor is usually about the same because a corporate tech usually has to let the Dell guy in, walk him to the site, and then install all the custom stuff after he leaves.
Win7 x64 blows the shit off Win7 x86
Do you have anything to back this up? I've done a lot of testing of I/O intensive workloads on XP and found 32-bit XP measureably faster than 64-bit XP. I'm sure 64-bit rocks for applications that require a lot of memory, but I can't see any reason why "64-bitness" should be an advantage for any application with a working set smaller than 2GB.
The con is the statement that the control shaft will require very little power to operate. If you stop the input shaft, you can see that the control shaft works the same as the planetary gear system on many commercial devices, like a cordless drill. I don't know about you, but the planetary drive on my cordless drill doesn't prevent me from going through batteries when I'm doing something heavy like using a hole saw. Given that, at times, the control shaft will require no less power than the input shaft, you would need a way to provide high power at variable speed. Therefore, you would need a CVT to operate your CVT.
My other concern is the gear tooth size. A traditional transmission uses gears that are quite large and have few teeth. The D-Drive has gear teeth with at least two orders of magnitude smaller teeth in critical places, and they are at a smaller radius. I think this thing will need to be huge to transmit enough power to move a vehicle. Large radius gears are necessary to transmit a lot of power. The planetary design of the D-Drive does not permit large radius gears.