Or several. It depends on how good of a model you want of a 'real' web server with separate web server and database, plus separate test system to drive the load. I wouldn't spend money for it from scratch, but if you already have recent hardware in a small form factor it would be worth considering.
Log4j supports selective logging. That means you can have info/debug/trace priority messages in place, but never see them in the log unless you explicitly enable extra logging for that class or package. You can do this at runtime, e.g., via something like 'chainsaw' (which attaches to a running process) or hooks in your UI.
Our policy is that logs are usually very quiet. Application startup/shutdown and not much more. But if there's a problem the debugging messages are already in place to let us peak into the system, even if it's been deployed to a production site.
BTW AOP is also great for this. You can configure logging interceptors that log activity when you're in a development environmnent, but easily removed in production. This is a natural approach when going from one layer to the next, e.g., when wrapping the DAO layer.
The car analogy is interesting since some of us have convertables. We -can't- secure our cars, anyone could take something from our car. (Or worse, leave something in our car if they need to dump something illegal fast.)
But the courts and insurances have an answer -- lock our doors. It's a clear demonstration of our intent to secure the car, even if it's of no practical value. Other than giving us full protection on our insurance policies, that is.:-)
Ditto tents, at least in Colorado. Tent flap open, anyone (and specifically, cops) can look in and see what you have. Tent flap closed and they need a search warrant, same as if they wanted to look into your house or the closed trunk on a car. Tent zippers are no real deterence, but it's enough to change the legal status.
So DRM isn't just about preventing unauthorized use, it's about -demonstrating- a reasonable effort to prevent unauthorized use. The original infringer will have a hard time claiming that 'I didn't know' if he had to use sophisticated to crack the DRM -- same as trying to claim that somebody didn't mind you going into their house since their locks were easily broken with a set of lock picks.
Or enough people will get burned that we, as a society, grow the fuck up and realize that it really doesn't matter most of the time. We know that we aren't the same person who wrote a screed at 16, so we are willing to accept that the guy who came in for an interview probably isn't the same guy he was when he was 16 either.
Same thing applies at 26, and 36, and even 46 if you're a Republican candidate brushing off a 'youthful indiscretion'.
Some stuff needs to stick. But we have words for them. Felonies. Criminal records. Other stuff? We need to let it go.
The difference is about the same as pointing your finger at somebody and going 'bang' and pointing a loaded gun at them.
It's perfectly legal for guys to screw 17-year-olds in many states. What's not legal is for them to try to screw 12- to 14-year-olds, the typical age in these stories.
It also looks clear that the guys are approaching the 'tweens' and bringing up sex in their chat rooms, not the other way around. (I don't know that from direct knowledge, but I can't imaging police and prosecutors continuing to work with them if there was even a whiff of entrapment.)
On the other hand, it's legal in every state to have consensual sex with another adult, even if it involves BSDM. Adultery is only a crime, unenforced, in a few states -- and many of the guys were single in any case.
But other than that, yeah, I guess they both involve 'sex' and 'internet'.
The problem with blaming the victim is that a lot of the men -weren't- married or in committed relationships. Where's the sleaze factor with them?
I'm not an unbiased person here, though, since the local craigslist had a woman who was constantly screeching and (claimed to be) warning other women about the perverts on the list. You know, the guys who actually responded to more than one of her fake ads.
It was a mark of infidelity, or something. How dare a guy respond to several women of about the same age, interests, etc. We're not even talking about somebody, gasp, getting together over coffee or something. The mere response was enough to set her off, and it totally poisoned the environment.
"the closest I found was a site that... had a special deal for customers that had expired in June!"
What about customers that died in May? Are they screwed again?
Do they expect much repeat business from the recently departed?
Is this a way to get around the memory erasure of the River Lethe (in Hades)? A way around the memory erasure during Buddhist reincarnation? If so, how would we know they successfully restored their memories? (I guess we would know the reincarnated retained their memories in a few years, when they start talking again.)
Thank you, thank you. The fish is very good tonight, and don't forget to tip your waitress!
Commercial leases have different rules. IIRC from my business law book, they generally don't have any blanket access provisions, although that's negotiable.
A website is clearly not residential. A lease colo box would clearly be analogous to a commercial lease, although I doubt the law sees them as such. A simple hosting provision... who knows.
I don't buy that 'compromise other users' argument. It might be a shared database SERVER, but every customer should be at least one distinct database user and should get their own database on that server(*)(**). Nobody should be able to see anybody else. If the database server can't handle it, find one that does. If the hosting company doesn't bother giving everyone their own database user accounts, find one that does.
The only reason the hosting company should ever look at the contents of a customer's database is 1) court order or 2) to do transparent optimization to eliminate real performance hits on other users, as permitted by hosting contract. This would cover the case somebody else mentioned where the hosting company added indexes to his database. The hosting company should have kept him informed, though.
(*) you want multiple users so that the owner of the database tables is different from the web app. You might still get hit by SQL injection if you aren't careful, but you won't have some bozo altering your tables.
(**) the exception is if the host provides certain tools to all users, e.g., an interface to a credit card processing engine. In this case the app might have a common backend database, but should still be designed so that one user can't see any other user's data.
It's a serious crime because it might mask other criminal acts, or at least make them unprosecutable. We can't go by what they're publicly saying since the city will legitimately want to keep that information quiet.
As a loose analogy, look at the recent case where a couple burglarized a house, then put a "everything free!" posting on craigslist to hide the crime. That 'prank' suddenly became a very serious effort to cover their felony.
This is partly a self-fulfilling problem. The developers and low-level management always have to keep their next job in mind, so they have an incentive to pad their resume with skills that their competition won't have. So they embrace new technology for the sake of embracing new technology, and that in turn brings in candidates who might not be very strong in the fundamentals but have/want these skills. Lather, rinse, repeat, and you have an explosion of "just because it's different" technology.
At the same time, there -is- legitimate change. It just takes longer and is only revolutionary in one aspect. With small/mid-scale J2EE, it was introduction of parameterized classes in Java 1.5, the introduction of Spring (dependency injection!), the widespread adoptation of maven for dependency management. A lot of us wouldn't have recognized our current environment three years ago, even though it's the same language and (mostly) the same libraries.
A good question is what's different in the two worlds. I think it's partly the environment, whether your user base is in the thousands or hundreds of thousands. The latter makes you a bit more conservative.
In this reality, the alpha developers get fed up after a few years and find more interesting and/or lucrative work elsewhere. Or they just feel it's time to move on since they aren't learning new stuff (read: remaining competitive) because somebody higher in the food chain thinks you should leave developers in place once they've become the experts.
The deltas, on the other hand, know they have it pretty sweet since they won't get canned unless they really screw up or there's a layoff... and they're relatively layoff-proof since the alphas and betas would have probably seen the writing on the wall and already split. Meanwhile they've been around the longest and most likely to be productive... right.
Both of which argue for management moving people around. It gives the alphas room to grow and they don't feel like it's professional suicide to stay, and it kicks the deltas out of their nest so their new projects can identify them as deadweight that needs to be trimmed.
What do they do when the computer's owner claims that the tech planted the porn on my disk? It's difficult to fight these charges (you have to fight jury anger at the material in addition to the substantial legal costs, you need to have a plausable reason why the tech would do it and have access to the material, etc.), but it's a legitimate question during the appeal process.
This isn't a moot point. Jonathan Turley (jonathanturley.org) recently had a piece on a guy who won a suit against his former employer. They found porn during routine maintenance and fired him on the spot. One small problem -- it had been somebody else's computers first and they had screwed up the antivirus checking when they reassigned the computer. So it had been infected by dozens of viruses and become part of a botnet carrying illegal material. It was totally without his knowledge, reasonable expectation, or ability to control.
The cases aren't exactly parallel, but it shows that cases have already come up where the problem was incompetent (or even malicious) maintenance.
First, few people are competent to make informed decisions about the guy without third party validation (licensing). The problem isn't whether the guy can handle the 95% of cases that are routine, it's whether he can recognize the 5% of cases that -aren't- routine and require more extensive intervention. This sounds trivial, but it isn't. A lot of serious problems start as nothing but aches or a fever. Lose a few friends or relatives and you suddenly take the 'small stuff' much more seriously.
(That 95%, though, is a good argument for allowing RNs to be able to offer primary treatment provided they are supervised by a doctor. You want an easy escalation path if something isn't quite right.)
Second, you're assuming that people are free to make their own choices. In the real world people usually go through insurance companies and that company may say that it will only cover visits to Dave's Discount Doctoring. If you want to go to somebody with a license, it's out-of-network and subject to a hefty copay. Again, that's fine for the 95% routine cases, but your insurance company has a vested interest in you overlooking that 5% until you move to a new insurance carrier.
You might think this is begging the question, but you'll always need health insurance. Not for the routine care that you could probably pay out-of-pocket, but for the catastrophic care after being in a severe accident, developing cancer, having a heart attack or stroke, etc. I can't remember the exact numbers, but something like 80% of the average person's lifetime medical expenses occurs in the last week of their life.
This isn't a direct response, but one of the biggest things in java right now is continuous testing. The tools make it extremely easy to 1) write unit tests, 2) run said unit tests as part of your build process, and 3) verify your unit tests have good code coverage.
It's not a silver bullet -- far from it -- but if you're diligent it's a very good way to catch unexpected changes in behavior very quickly. Definitely before anyone starts to depend on the broken behavior. That, by itself, goes a loooong way. We still had to work with testers for the functional testing, but we were able to focus on adding missing functionality instead of things just not working right.
That 4k in java isn't 4k in freshman comp sci java. It's going to be leveraging widely used libraries that have millions of SLOC and a wide deployment base. Reading between the lines, I would be surprised if the tiger team didn't use the same tools as countless midsized projects that are maintained by teams of a few dozen at most. You can do a phenomenal amount in little code if you use the right frameworks and some decent xml configuration files.
In fact my coworkers and I have noticed an extremely frustrating trend in our side projects. We apply tools we learn at our day job (in part to understand them better), and our side project SLOC shrinks. A lot. Much of the 'interesting bits' disappears. Suddenly a 12k SLOC side project that took some serious effort to maintain is just a 4k SLOC side project, more functional, and easier to extend. It's a good thing -- don't get me wrong -- but it can be a real ego buster.
Portability isn't a big driver on server-side projects. It's nice, but only really comes into play when you deploy to new hardware or OS version. The larger the project, the longer the deployment cycle. (Think enterprise linux.) For something with a budget in hundreds of millions of dollars you'll have a deployment cycle that lasts at least 5 years.
It's a lot better than it used to be. "Invisible idiot" was a class mistranslation from English to Chinese (or maybe Russian) and back. Which makes sense, if you don't know idioms. "out of sight" is obviously the same concept as "invisible", and "out of mind" is the same concept as "idiot".
Today feels more like somebody with a year or two of college-level instruction (but no real-life experience), or at best a high school student writing a term paper with the use of a thesaurus. More intelligible, but all of the nuances have been scrambled and left in the summer noontime sun.
You still need facts for context to understand the information google gives you, and as a first-order filter on whether it makes any sense. Chocolate chip cookies are often drunk with milk. Otherwise you can be distracted by irrelevant information. Or people trying to convince you to try shrimp cookies, perhaps because they're trying to sell you special shrimp cookie sheets.
Without that background, you'll run the risk of being a Chinese "invisible idiot" who is always out of sight, out of mind. Machine translation was first attempted in the 1950s.
One thing google is very good at is exposing you to new things that can be used to broaden your knowledge, so you get a cascading effect. But you have to be very careful -- there are eddies and cesspools of groups that create their own reality (Bush is one of the best presidentz evr!) and you need that outside context to see just how out of touch they are.
This problem has existed since the first libraries -- how could you ever be sure that the book you are reading isn't full of shit? -- but people were generally only exposed to stuff on the edge of their existing knowledge. Google makes pet cats good. It also exposes younger and younger people to information they don't have the experience to judge properly.
I vaguely recall there being a key legal point that you have to be able to simultaneously point to one party and exclude all others. Check with a lawyer (or law school student) to be sure.
The reason is to prevent an "I was framed!" defense as much as preventing framing innocent parties. It's not unheard of for people to plant evidence of their own guilt. Discredit the planted evidence and most people will (reasonably) have a lot of doubt about the rest of it.
I had a big box retailer refuse to honor my credit card because of this rule. Which makes absolutely no sense -- they not only lost the immediate sale, they guaranteed I would be so pissed off that I wouldn't return to their store for a very long time. And for what -- I would have happily provided my drivers license.
The only explanation has to be that they were burned recently and management got on everyone's case to check credit card signatures... and the drone(s) thought I was checking their security.
That answers the immediate question, but there's still the question of why the -law- considers a fax to be a legal facsimile.
I think the answer to that, ironically, comes back to businesses. Businesses needed a way to send 'signed' documents quickly, and pre-FedEx there weren't really many options. Fax machines were bulky and expensive. They didn't accept signed documents from just anyone, they had already vetted the other party to some extent.
So, on balance, the convenience of 'legal facsimile' faxes outweighed the cost of the rare forgery. They pushed the law to recognize the same.
Now things have totally reversed. You can send documents to anywhere in the country in a day for a modest amount, you can create perfect forgeries using a scanner, basic editing software and fax modem, etc. People would be insane to trust faxes for anything but the most trivial things...... yet, my company's pretax account takes documentation via fax. I could mail the documents, of course, but that will add time and processing costs to all parties involved. (I'm sure they use electronic copies of the faxes, not paper copies.) So it's a significant benefit to all parties to use 'legal fascimile' faxes.
Bottom line is that businesses use faxes since it's legal, and it's legal because businesses want to use faxes. It's not going away soon, but I agree 100% that it's insane to trust faxed documents for anything of significant value. (E.g., we used faxes to the seller when I bought my house a decade ago.)
I think the ultimate question is refutability. I don't care if a business accepts faxes -as long as I can refute a forged fax-. That's the only same solution -- put all liability on the receiver. They can continue to accept low-balance transactions if it's convenient, while I can be confident that nobody will try to forge documents "selling" my house to a third party.
(It turns out we have a good recent example of this -- credit card companies don't require signed receipts for low-balance credit card transactions. The cardholder always wins any dispute, but businesses are willing to accept that risk in exchange for the convenience of moving people through the line quicker or avoiding the need for customer interaction at all (e.g., at gas stations))
I can't remember the name of the doctrine, maybe something with 'lesser evil'? It's an affirmative defense where you admit to committing a lesser crime in order to stop or prevent a greater evil.
In practice, this situation didn't come up much and I think most states have dropped it. They leave it to the prosecution's discretion in dropping those charges.
BTW the canonical example is probably assaulting somebody in order to stop/prevent a rape. This might sound like a no-brainer, but what if the would-be rescuer misread the situation? This has happened and it's always messy.
Back in the stone age ('82 or so) my physics program required a year of introductory programming, and the math program required just a junior-level class in numeric methods. Or maybe it was the other way around. Either way we still did almost everything in both programs in the classical way.
I noticed something interesting in the our CS classes, though. We caught the programming aspects in about a week. Our classmates struggled with the math all semester. But they did better on the presentation, even when their answers were wrong.
This makes sense, when you think about it. Proofs are analogous to programs in a very high-level language -- with extremely strict compilers. Anyone who's survived several years of physics will be comfortable writing software, so you can collapse several CS courses into a single term.
The key is what you keep. Having worked as a software developer working with PhD-level scientists, I think it's fairly simple -- algorithms, data structures and numeric methods. The guys who stayed in science could "write software", but it was usually pretty bad from a CS perspective. A few simple data structures, a few standard optimizations and the code would be much faster and more reliable. The scientists didn't need to know these things well, but it would have helped tremendously if they knew they -existed- so they would know they could ask the right questions later.
It depends on where you are, how quickly police can get to you, etc. Don't forget that there are large parts of the country where the nearest cop may be an hour away. Or both of them might be busy handling another situation.
This happened outside of Denver a few months ago. Scumbag with long criminal record broke into a not-quite-empty house, and continued struggling with homeowner even after he was (allegedly) repeatedly told that he could just walk away -- he said the homeowner would shoot him in the back.
The homeowner eventually managed to reach one of his guns. The intruder no longer had to worry about hypothetical situations. The homeowner doesn't have to worry about the intruder's true intentions. He doesn't have to worry about the law either since Colorado law gives broad protection to homeowners.
IIRC the news said it did take the police about an hour to arrive. This situation might not be common, but it does happen.
I'm -not- saying that guns are always a good idea. In fact, I agree that most urban and suburban residents would probably be better off without them. But you can't make broad statements. Millions of people live far from police assistance, millions of people have specific threats, etc.
Slashdot Mirror
Or several. It depends on how good of a model you want of a 'real' web server with separate web server and database, plus separate test system to drive the load. I wouldn't spend money for it from scratch, but if you already have recent hardware in a small form factor it would be worth considering.
Log4j supports selective logging. That means you can have info/debug/trace priority messages in place, but never see them in the log unless you explicitly enable extra logging for that class or package. You can do this at runtime, e.g., via something like 'chainsaw' (which attaches to a running process) or hooks in your UI.
Our policy is that logs are usually very quiet. Application startup/shutdown and not much more. But if there's a problem the debugging messages are already in place to let us peak into the system, even if it's been deployed to a production site.
BTW AOP is also great for this. You can configure logging interceptors that log activity when you're in a development environmnent, but easily removed in production. This is a natural approach when going from one layer to the next, e.g., when wrapping the DAO layer.
The car analogy is interesting since some of us have convertables. We -can't- secure our cars, anyone could take something from our car. (Or worse, leave something in our car if they need to dump something illegal fast.)
But the courts and insurances have an answer -- lock our doors. It's a clear demonstration of our intent to secure the car, even if it's of no practical value. Other than giving us full protection on our insurance policies, that is. :-)
Ditto tents, at least in Colorado. Tent flap open, anyone (and specifically, cops) can look in and see what you have. Tent flap closed and they need a search warrant, same as if they wanted to look into your house or the closed trunk on a car. Tent zippers are no real deterence, but it's enough to change the legal status.
So DRM isn't just about preventing unauthorized use, it's about -demonstrating- a reasonable effort to prevent unauthorized use. The original infringer will have a hard time claiming that 'I didn't know' if he had to use sophisticated to crack the DRM -- same as trying to claim that somebody didn't mind you going into their house since their locks were easily broken with a set of lock picks.
Or enough people will get burned that we, as a society, grow the fuck up and realize that it really doesn't matter most of the time. We know that we aren't the same person who wrote a screed at 16, so we are willing to accept that the guy who came in for an interview probably isn't the same guy he was when he was 16 either.
Same thing applies at 26, and 36, and even 46 if you're a Republican candidate brushing off a 'youthful indiscretion'.
Some stuff needs to stick. But we have words for them. Felonies. Criminal records. Other stuff? We need to let it go.
The difference is about the same as pointing your finger at somebody and going 'bang' and pointing a loaded gun at them.
It's perfectly legal for guys to screw 17-year-olds in many states. What's not legal is for them to try to screw 12- to 14-year-olds, the typical age in these stories.
It also looks clear that the guys are approaching the 'tweens' and bringing up sex in their chat rooms, not the other way around. (I don't know that from direct knowledge, but I can't imaging police and prosecutors continuing to work with them if there was even a whiff of entrapment.)
On the other hand, it's legal in every state to have consensual sex with another adult, even if it involves BSDM. Adultery is only a crime, unenforced, in a few states -- and many of the guys were single in any case.
But other than that, yeah, I guess they both involve 'sex' and 'internet'.
Put more simply, your need to shit doesn't give you the right to shit on other people.
The problem with blaming the victim is that a lot of the men -weren't- married or in committed relationships. Where's the sleaze factor with them?
I'm not an unbiased person here, though, since the local craigslist had a woman who was constantly screeching and (claimed to be) warning other women about the perverts on the list. You know, the guys who actually responded to more than one of her fake ads.
It was a mark of infidelity, or something. How dare a guy respond to several women of about the same age, interests, etc. We're not even talking about somebody, gasp, getting together over coffee or something. The mere response was enough to set her off, and it totally poisoned the environment.
I can normally resist this, but this is too much:
"the closest I found was a site that... had a special deal for customers that had expired in June!"
What about customers that died in May? Are they screwed again?
Do they expect much repeat business from the recently departed?
Is this a way to get around the memory erasure of the River Lethe (in Hades)? A way around the memory erasure during Buddhist reincarnation? If so, how would we know they successfully restored their memories? (I guess we would know the reincarnated retained their memories in a few years, when they start talking again.)
Thank you, thank you. The fish is very good tonight, and don't forget to tip your waitress!
That's residental rentals/leases.
Commercial leases have different rules. IIRC from my business law book, they generally don't have any blanket access provisions, although that's negotiable.
A website is clearly not residential. A lease colo box would clearly be analogous to a commercial lease, although I doubt the law sees them as such. A simple hosting provision... who knows.
I don't buy that 'compromise other users' argument. It might be a shared database SERVER, but every customer should be at least one distinct database user and should get their own database on that server(*)(**). Nobody should be able to see anybody else. If the database server can't handle it, find one that does. If the hosting company doesn't bother giving everyone their own database user accounts, find one that does.
The only reason the hosting company should ever look at the contents of a customer's database is 1) court order or 2) to do transparent optimization to eliminate real performance hits on other users, as permitted by hosting contract. This would cover the case somebody else mentioned where the hosting company added indexes to his database. The hosting company should have kept him informed, though.
(*) you want multiple users so that the owner of the database tables is different from the web app. You might still get hit by SQL injection if you aren't careful, but you won't have some bozo altering your tables.
(**) the exception is if the host provides certain tools to all users, e.g., an interface to a credit card processing engine. In this case the app might have a common backend database, but should still be designed so that one user can't see any other user's data.
It's a serious crime because it might mask other criminal acts, or at least make them unprosecutable. We can't go by what they're publicly saying since the city will legitimately want to keep that information quiet.
As a loose analogy, look at the recent case where a couple burglarized a house, then put a "everything free!" posting on craigslist to hide the crime. That 'prank' suddenly became a very serious effort to cover their felony.
This is partly a self-fulfilling problem. The developers and low-level management always have to keep their next job in mind, so they have an incentive to pad their resume with skills that their competition won't have. So they embrace new technology for the sake of embracing new technology, and that in turn brings in candidates who might not be very strong in the fundamentals but have/want these skills. Lather, rinse, repeat, and you have an explosion of "just because it's different" technology.
At the same time, there -is- legitimate change. It just takes longer and is only revolutionary in one aspect. With small/mid-scale J2EE, it was introduction of parameterized classes in Java 1.5, the introduction of Spring (dependency injection!), the widespread adoptation of maven for dependency management. A lot of us wouldn't have recognized our current environment three years ago, even though it's the same language and (mostly) the same libraries.
A good question is what's different in the two worlds. I think it's partly the environment, whether your user base is in the thousands or hundreds of thousands. The latter makes you a bit more conservative.
In our dreams.
In this reality, the alpha developers get fed up after a few years and find more interesting and/or lucrative work elsewhere. Or they just feel it's time to move on since they aren't learning new stuff (read: remaining competitive) because somebody higher in the food chain thinks you should leave developers in place once they've become the experts.
The deltas, on the other hand, know they have it pretty sweet since they won't get canned unless they really screw up or there's a layoff... and they're relatively layoff-proof since the alphas and betas would have probably seen the writing on the wall and already split. Meanwhile they've been around the longest and most likely to be productive... right.
Both of which argue for management moving people around. It gives the alphas room to grow and they don't feel like it's professional suicide to stay, and it kicks the deltas out of their nest so their new projects can identify them as deadweight that needs to be trimmed.
Call the cops, eh?
What do they do when the computer's owner claims that the tech planted the porn on my disk? It's difficult to fight these charges (you have to fight jury anger at the material in addition to the substantial legal costs, you need to have a plausable reason why the tech would do it and have access to the material, etc.), but it's a legitimate question during the appeal process.
This isn't a moot point. Jonathan Turley (jonathanturley.org) recently had a piece on a guy who won a suit against his former employer. They found porn during routine maintenance and fired him on the spot. One small problem -- it had been somebody else's computers first and they had screwed up the antivirus checking when they reassigned the computer. So it had been infected by dozens of viruses and become part of a botnet carrying illegal material. It was totally without his knowledge, reasonable expectation, or ability to control.
The cases aren't exactly parallel, but it shows that cases have already come up where the problem was incompetent (or even malicious) maintenance.
There are two problems with that position.
First, few people are competent to make informed decisions about the guy without third party validation (licensing). The problem isn't whether the guy can handle the 95% of cases that are routine, it's whether he can recognize the 5% of cases that -aren't- routine and require more extensive intervention. This sounds trivial, but it isn't. A lot of serious problems start as nothing but aches or a fever. Lose a few friends or relatives and you suddenly take the 'small stuff' much more seriously.
(That 95%, though, is a good argument for allowing RNs to be able to offer primary treatment provided they are supervised by a doctor. You want an easy escalation path if something isn't quite right.)
Second, you're assuming that people are free to make their own choices. In the real world people usually go through insurance companies and that company may say that it will only cover visits to Dave's Discount Doctoring. If you want to go to somebody with a license, it's out-of-network and subject to a hefty copay. Again, that's fine for the 95% routine cases, but your insurance company has a vested interest in you overlooking that 5% until you move to a new insurance carrier.
You might think this is begging the question, but you'll always need health insurance. Not for the routine care that you could probably pay out-of-pocket, but for the catastrophic care after being in a severe accident, developing cancer, having a heart attack or stroke, etc. I can't remember the exact numbers, but something like 80% of the average person's lifetime medical expenses occurs in the last week of their life.
This isn't a direct response, but one of the biggest things in java right now is continuous testing. The tools make it extremely easy to 1) write unit tests, 2) run said unit tests as part of your build process, and 3) verify your unit tests have good code coverage.
It's not a silver bullet -- far from it -- but if you're diligent it's a very good way to catch unexpected changes in behavior very quickly. Definitely before anyone starts to depend on the broken behavior. That, by itself, goes a loooong way. We still had to work with testers for the functional testing, but we were able to focus on adding missing functionality instead of things just not working right.
That 4k in java isn't 4k in freshman comp sci java. It's going to be leveraging widely used libraries that have millions of SLOC and a wide deployment base. Reading between the lines, I would be surprised if the tiger team didn't use the same tools as countless midsized projects that are maintained by teams of a few dozen at most. You can do a phenomenal amount in little code if you use the right frameworks and some decent xml configuration files.
In fact my coworkers and I have noticed an extremely frustrating trend in our side projects. We apply tools we learn at our day job (in part to understand them better), and our side project SLOC shrinks. A lot. Much of the 'interesting bits' disappears. Suddenly a 12k SLOC side project that took some serious effort to maintain is just a 4k SLOC side project, more functional, and easier to extend. It's a good thing -- don't get me wrong -- but it can be a real ego buster.
Portability isn't a big driver on server-side projects. It's nice, but only really comes into play when you deploy to new hardware or OS version. The larger the project, the longer the deployment cycle. (Think enterprise linux.) For something with a budget in hundreds of millions of dollars you'll have a deployment cycle that lasts at least 5 years.
It's a lot better than it used to be. "Invisible idiot" was a class mistranslation from English to Chinese (or maybe Russian) and back. Which makes sense, if you don't know idioms. "out of sight" is obviously the same concept as "invisible", and "out of mind" is the same concept as "idiot".
Today feels more like somebody with a year or two of college-level instruction (but no real-life experience), or at best a high school student writing a term paper with the use of a thesaurus. More intelligible, but all of the nuances have been scrambled and left in the summer noontime sun.
You still need facts for context to understand the information google gives you, and as a first-order filter on whether it makes any sense. Chocolate chip cookies are often drunk with milk. Otherwise you can be distracted by irrelevant information. Or people trying to convince you to try shrimp cookies, perhaps because they're trying to sell you special shrimp cookie sheets.
Without that background, you'll run the risk of being a Chinese "invisible idiot" who is always out of sight, out of mind. Machine translation was first attempted in the 1950s.
One thing google is very good at is exposing you to new things that can be used to broaden your knowledge, so you get a cascading effect. But you have to be very careful -- there are eddies and cesspools of groups that create their own reality (Bush is one of the best presidentz evr!) and you need that outside context to see just how out of touch they are.
This problem has existed since the first libraries -- how could you ever be sure that the book you are reading isn't full of shit? -- but people were generally only exposed to stuff on the edge of their existing knowledge. Google makes pet cats good. It also exposes younger and younger people to information they don't have the experience to judge properly.
I vaguely recall there being a key legal point that you have to be able to simultaneously point to one party and exclude all others. Check with a lawyer (or law school student) to be sure.
The reason is to prevent an "I was framed!" defense as much as preventing framing innocent parties. It's not unheard of for people to plant evidence of their own guilt. Discredit the planted evidence and most people will (reasonably) have a lot of doubt about the rest of it.
I had a big box retailer refuse to honor my credit card because of this rule. Which makes absolutely no sense -- they not only lost the immediate sale, they guaranteed I would be so pissed off that I wouldn't return to their store for a very long time. And for what -- I would have happily provided my drivers license.
The only explanation has to be that they were burned recently and management got on everyone's case to check credit card signatures... and the drone(s) thought I was checking their security.
That answers the immediate question, but there's still the question of why the -law- considers a fax to be a legal facsimile.
... yet, my company's pretax account takes documentation via fax. I could mail the documents, of course, but that will add time and processing costs to all parties involved. (I'm sure they use electronic copies of the faxes, not paper copies.) So it's a significant benefit to all parties to use 'legal fascimile' faxes.
I think the answer to that, ironically, comes back to businesses. Businesses needed a way to send 'signed' documents quickly, and pre-FedEx there weren't really many options. Fax machines were bulky and expensive. They didn't accept signed documents from just anyone, they had already vetted the other party to some extent.
So, on balance, the convenience of 'legal facsimile' faxes outweighed the cost of the rare forgery. They pushed the law to recognize the same.
Now things have totally reversed. You can send documents to anywhere in the country in a day for a modest amount, you can create perfect forgeries using a scanner, basic editing software and fax modem, etc. People would be insane to trust faxes for anything but the most trivial things...
Bottom line is that businesses use faxes since it's legal, and it's legal because businesses want to use faxes. It's not going away soon, but I agree 100% that it's insane to trust faxed documents for anything of significant value. (E.g., we used faxes to the seller when I bought my house a decade ago.)
I think the ultimate question is refutability. I don't care if a business accepts faxes -as long as I can refute a forged fax-. That's the only same solution -- put all liability on the receiver. They can continue to accept low-balance transactions if it's convenient, while I can be confident that nobody will try to forge documents "selling" my house to a third party.
(It turns out we have a good recent example of this -- credit card companies don't require signed receipts for low-balance credit card transactions. The cardholder always wins any dispute, but businesses are willing to accept that risk in exchange for the convenience of moving people through the line quicker or avoiding the need for customer interaction at all (e.g., at gas stations))
I can't remember the name of the doctrine, maybe something with 'lesser evil'? It's an affirmative defense where you admit to committing a lesser crime in order to stop or prevent a greater evil.
In practice, this situation didn't come up much and I think most states have dropped it. They leave it to the prosecution's discretion in dropping those charges.
BTW the canonical example is probably assaulting somebody in order to stop/prevent a rape. This might sound like a no-brainer, but what if the would-be rescuer misread the situation? This has happened and it's always messy.
Back in the stone age ('82 or so) my physics program required a year of introductory programming, and the math program required just a junior-level class in numeric methods. Or maybe it was the other way around. Either way we still did almost everything in both programs in the classical way.
I noticed something interesting in the our CS classes, though. We caught the programming aspects in about a week. Our classmates struggled with the math all semester. But they did better on the presentation, even when their answers were wrong.
This makes sense, when you think about it. Proofs are analogous to programs in a very high-level language -- with extremely strict compilers. Anyone who's survived several years of physics will be comfortable writing software, so you can collapse several CS courses into a single term.
The key is what you keep. Having worked as a software developer working with PhD-level scientists, I think it's fairly simple -- algorithms, data structures and numeric methods. The guys who stayed in science could "write software", but it was usually pretty bad from a CS perspective. A few simple data structures, a few standard optimizations and the code would be much faster and more reliable. The scientists didn't need to know these things well, but it would have helped tremendously if they knew they -existed- so they would know they could ask the right questions later.
It depends on where you are, how quickly police can get to you, etc. Don't forget that there are large parts of the country where the nearest cop may be an hour away. Or both of them might be busy handling another situation.
This happened outside of Denver a few months ago. Scumbag with long criminal record broke into a not-quite-empty house, and continued struggling with homeowner even after he was (allegedly) repeatedly told that he could just walk away -- he said the homeowner would shoot him in the back.
The homeowner eventually managed to reach one of his guns. The intruder no longer had to worry about hypothetical situations. The homeowner doesn't have to worry about the intruder's true intentions. He doesn't have to worry about the law either since Colorado law gives broad protection to homeowners.
IIRC the news said it did take the police about an hour to arrive. This situation might not be common, but it does happen.
I'm -not- saying that guns are always a good idea. In fact, I agree that most urban and suburban residents would probably be better off without them. But you can't make broad statements. Millions of people live far from police assistance, millions of people have specific threats, etc.