Well, that's just a slippery slope argument. The real problem with the Catholic position here is that it is incoherent.
Covering contraception under a health plan is not "paying for contraception". It's paying for contraception *coverage*, because it is the employee that decides to take the medication -- which by the way has numerous other therapeutic applications besides contraception. What's going on is the RC church trying to interfere with their employee's medical coverage.
Short, simplistic answer: the ISP found a way to fraudulently skim a percentage from online retailers for every purchase made by the ISP customers.
Slightly more detailed answer: the ISP directed users looking for online merchants like "amazon.com" to it's own bogus server. That bogus server then re-directs the user's browser to the merchant's server in such a way the consumer doesn't notice and the merchant thinks the customer is following a product referral from an advertising partner. Thus the ISP collects a kickback intended for people who make product recommendations and referrals, without actually having made any recommendation or referral.
There's a big difference between people who are capable of doing things "by the book" making an informed decision not to do so, and people deciding to do things in an ad hoc manner because they can't master the "by the book" method.
Every successful project, in my opinion, requires both discipline and risk taking; the art is knowing how much of each the project you are currently managing needs. Every project should have a bit of a stretch built into it, otherwise people get sloppy because they've become complacent. But *too* much risk, and they get sloppy because marginal additions to risk become meaningless to them.
You want control and measurement and all that rational stuff, but developers aren't automatons. They need motivation to care about those things; if they're just going through the motions a formal methodology becomes so much dead weight. So excitement, challenge, novelty, even a whiff of fear can be healthy things. But not chaos, impossibility,blue-sky goals and outright terror. An excessive dose of medicine is poison.
I expect that they object to being viewed as persons of intrinsically lesser capability.
It's wrong, although not malicious, to say "deaf people are vulnerable," because vulnerability is not a permanent attribute; it's an ephemeral state that can usually be engineered out of the environment. A level crossing with only a crossbuck sign can be fitted with flashing lights.
The difference I was originally highlighting was more that Wave integrated with XML at the server, in a season that people realized the implications of "AJAX" (i.e. JSON)
Well, seems like apples and oranges to me. AJAX is not a data representation model, it's a communication model. If you have to, say, obtain data from a server to repopulate an HTML table in response to a user action, JSON fits the bill, because you need only the most rudimentary semantics. But that doesn't mean JSON can replace XML for every purpose, e.g. something like Open Document Format. So you might well do a lot of AJAXy stuff with JSON to the browser, but do a lot of DOM manipulation stuff on the server side.
Not every tool has to work equally well for every task.
I'm not saying that it makes no difference. I'm saying it's an implementation detail, which is a far cry from saying the choice never matters. If you can't grasp the distinction between a choice mattering and it needing to be localized in a design, you'll never be a competent software designer.
If a system is somehow irretrievably ruined by choosing XML over JSON, then bad programming must be at least equally to blame because if you don't need any XML features that JSON doesn't have, the switch should be easy.
Most people are priggish busybodies. If they don't understand something, they act like that's proof its worthless.
That said, a lot of the fun of art is having opinions about it. Not liking a piece of art isn't the same as "shitting on it". You like what you like; where you end up on treacherous ground is when you have an opinion about what other people *ought* to like.
I don't like the novel Twilight. I have very specific opinions about things that are not good about that novel. On the other hand, I understand why the people who like that novel like it. My not liking that novel doesn't make me better than them, only different. Likewise I can tell you a lot about what's wrong with Lord of the Rings as a novel, but it's a story I love and re-read every couple of years.
The more serious you are about an art form the less it becomes about what you like or don't like. Liking or not like is still important, but it's not everything.
Most of the complaints I hear about XML are really complaints about lousy software architecture. Yes, XML is complex, but that should cause *zero* hassle on the front end. If it is causing hassle throughout your project, you're doing something wrong architecturally.
The desire to flex your muscles in a hot technology often overwhelms good design sense. Thus ten years ago you'd see people parsing and doing XML DOM tree manipulation directly in UI code and crap like that. Doing the same with JSON would be just as bad design, although since JSON's feature set is much smaller the results are less immediately catastrophic. But they're still bad design.
If your objection to XML is that it spreads complexity throughout your code, you're just a mediocre coder. Choosing XML or JSON should be a very minor implementation detail.
Isn't there a massive oil boom going on in the US and other countries at the moment?
Yes, and not for the first time either. There was a shale oil boom in the 1970s that went bust when Saudi Arabia opened the oil spigots in the 80s.
Note what this means: we knew the shale oil was there; we had the ability to get it, but we left it in the ground because it was more expensive than regular petroleum. As we anticipate not having access to cheap oil, we're turning *back* to shale.
This is what it looks like when a planet runs out of oil. It's not like one day you pump the last drop of petroleum out of the ground. We'll never get that far. What happens is that we'll go after increasingly marginal sources of oil, until the day comes that the next drop of oil extracted is more expensive than some alternative energy source. And because what is "economically extractable" is dependent on technology, nobody can put a precise date on that, but looking for more energy efficiency and resuming shale oil operations are two sides of the same coin.
The F150 has been the best selling vehicle in America for decades, so it takes a lot of guts, or a lot of motivation to do something radical with it. I'm guessing that Ford isn't doing this out of public-spiritedness, but because they anticipate higher fuel prices some time in the next few years.
Of course comparing gasoline prices to global production is a bit like comparing weather to climate; there are factors in play which swamp the long term trends -- over the short term. Still I've seen some predictions that gasoline will hit $6/gallon in the next five years from it's current level of $3.65/gallon. If that prediction is even remotely true, then even if the new truck is plagued with problems it'll be a winner. And eventually crude prices are going to send gas prices that way.
Aluminum *does* corrode. In most situations the oxides form a stable protective layer, but in situations where aluminum is in contact with dissimilar metal you can get galvanic action and the less noble metal will corrode. There's also a phenomenon called stress corrosion cracking where a metal in a corrosive environment can fail catastrophically after being repeatedly exposed to stress.
So a piece of structural aluminum near a fastener in a salty environment isn't safe from corrosion failure. Naturally I'd assume Ford is on top of this, and you'd have nothing to fear from your new aluminum truck. How safe it would be after a ten or fifteen years of being driven hard over New England roads is something that I wouldn't be altogether sure of. Again I'm sure the engineers have taken this into account, engineers are fallible so we'll have to wait and see.
Steel really is an amazing material, both strong and tough. It tends to fail in benign ways (bending rather than breaking), which also contributes to the safety of a steel vehicle. When steel is damaged it is easy to repair. My wife has had a couple incidents with her car and a certain steel beam in the garage at work. When it happens we replace the passenger side doors and have our mechanic beat the door pillar back into shape with big hammer. I'm not sure an aluminum vehicle could be repaired this way.
So as a geek I'm delighted Ford is trying something new. But there are good reasons nobody's attempted this before. I'm hoping it's a brilliant success, but we won't be sure until the vehicles have been on the road for a few years.
Now, imagine what happens with the plumbing analogy when you try to make everything go backwards.
Alright, I'm game. We're talking about residential rooftop panels, right? Here goes.
I'm imagining... nothing happening.
According to the link the panels the guy installed generate 35kw. That's bound to be sucked up by his neighbors on the running off the local transformer.
Still not enough to merit an accusation of dishonesty. It's just an interesting fact, that people with working brains can take into account without hyperventilating.
It actually *is* a quite interesting fact, because it shows how the relationship of antarctic ice to global temperatures is quite complicated, as are weather conditions in any one region of the Earth at any particular time. It's something to keep in mind, next time you look out your window and see a little unseasonable snow, or unseasonable sunshine for that matter.
to do something that furthers his criminal enterprises has a name. It's called "conspiracy".
So if you ever try your hand at hunting down criminals like this, be aware of the potential danger of tying yourself to the criminal's legal fate. If you've done business withhim that's the least bit shady, and he's overseas beyond the reach of local authorities, things could get quite ugly for you.
Well, we're talking far too abstractly here to be very meaningful. I'm not saying an RDMS couldn't be *part* of the picture. I'm saying that a system architecture that punted all the persistence and data consistency problems to a distributed RDBMS is a non-starter for something on this scale. People don't build systems like this one that way. If they don't, even though that technology is a mature one, that's a good reason to be skeptical of the idea that that approach would be a panacea.
More to the point, it doesn't have the scalability across distributed systems. Show me one application approaching this scale, just *one*, that relies RDBMS clusters and two-phase commit exclusively to support this kind of transaction volume. Don't get me wrong; I'm an old-school RDBMS guy myself; I know a lot about relational database systems, including their limitations. I'd look to the way outfits like Amazon,,Google or LinkedIn design their infrastructure rather than Oracle on big iron. This is well outside the sweet spot for that approach.
RDBMS servers are made to just do the job quietly and reliably, with very strict ACID compliance...
This is a very simple-minded approach to architecture, one that's admittedly very serviceable in a wide array of applications. But useful as ACID is as a set of assumptions you can rely upon, it's not the only way to create a reliable, serviceable system. In fact there are situations where it's provable that ACID falls short. Google "CAP Theorem" and "eventual consistency". It's fascinating stuff.
It does not sound to me as though known management tools were used. Did they sit down with the government personnel in charge, and present their approach, and what the site would look like (menus, flow, etc) when finished? Were there testable milestones, and a final presentation of working software? It sure doesn't sound like it.
They might well have done all these things and still failed to catch the problems before the site's launch.
Performance, like security (ack! scary!) is a non-functional requirement -- that is to say it's not the kind of requirement where you can sit down with a checklist and say, 'yep, this it works,' or 'no, it doesn't.' You have to develop a more sophisticated test.
Load testing is a step in the right direction, but you also have to look at system architecture. Remember the days before people figured out that you had to load web ads asynchronously, after the page content was loaded? Sometimes the page load would be slow, not because the page's server was loaded, or because of the user's browser or internet connection were slow. Often it would be the ad server that was overwhelmed, which if you think about it is bound to be more common than the content server being overwhelmed. You could functional test and even load test the heck out of a page with synchronous ad loads, but until it went into production chances are you wouldn't catch the fatal performance flaw. That kind of problem is architectural; some of the data being delivered is coming from servers outside your control.
Ordinary tests are about ensuring reproducible results, but when the architecture leaves you vulnerable to things happening on servers and networks outside your control your problems *aren't reliably reproducible*. You have to design around *possibilities*.
Some of the problems with Healthcare.gov were of this nature, although with not so simple a solution as "use window.onload()." The site is supposed to orchestrate a complex, *distributed* process *synchronously*. You have to go out the Homeland Security's database to confirm citizenship, then to the IRS databases to confirm claims about income, then get quotes from the private insurers that meet the customer's needs. There is, in my opinion, no way to be 100% sure, or even 80% sure that a system like that will work under real work load, unless you present it with real work load.
Were I architecting such a site, I'd plan to do a lot of that work batch; that is I'd build the healthcare application offline on the user's browser, with internal consistency checks of course. Then I'd send the user's application through a batch verification system, emailing him when a result was ready. This is a clunky and old-fashioned approach, but it wouldn't force the user to chain himself to his browser . And it would have more predictable performance. Predictability is a vastly under-rated quality in a system. A system which is fast most of the time may not be as desirable as one which provides the answer consistently.
Let me start with a disclaimer: I'm not an expert in Bitcoin, but this is my understanding.
One of the important differences between Bitcoins and regular currency is that every bitcoin has an unique serial number. This is not true for dollars; oh a particular banknote my have a serial number, but the dollars in your bank account have no individual identity. The fact that every bitcoin has a serial number makes it possible to distribute information about who owns a particular bitcoin. Thus the physical location of the fact of ownership is the entire network of computers participating in bitcoin transactions. Naturally, the protocol has provisions for resolving contradictory assertions, so that over time the network will converge towards consensus on any particular bitcoin.
Now as to how Uncle Sam can 'seize' a bitcoin, it's simple. Uncle Sam doesn't seize your bitcoin *wallet*, he seizes the cryptographic keys you use to conduct Bitcoin transactions. Then for every bitcoin X in the wallet, he sends out the message, "I, BringsApples, transfer bitcoin #X to Uncle Sam." Furthermore, since the protocol is de-centralized, there is no mechanism for the participants to agree that bitcoin X really belongs to you. The only way to "get the bitcoin back" is for Uncle Sam to broadcast a message, "I, Uncle Sam, transfer bitcoin #X to BringsApples."
The bitcoins don't reside anywhere, including in any particular "virtual wallet on a PC".
If you don't believe that, make 100 copies of that "virtual wallet" and ask yourself if you now have 100 times as many bitcoins.
Well, let's ask a far more pertinent question: if you make 100x copies of wallet, do you have 100x the bitcoin purchasing power? The answer is no. It is theoretically possible to spend the same bitcoin twice, but th protocol is designed so that on average that costs more than obtaining a second bitcoin legitimately. You don't have to make it impossible to cheat; you only have to make it pointless.
A bitcoin is an abstraction, just as the dollars in your bank account are. If you have $100K in a bank account, that doesn't mean there's a stack of banknotes in the vault that corresponds to that. Your funds "in the bank" exist only on that bank's ledgers. They have no physical existence, they exist according to a set of rules which assign those dollars to you. When nearly everyone in the system agrees that according to the rules you have $100K in the First National Bank of Podunk, then you've got $100K there. Bitcoins work exactly the same way, except the rules are voluntarily agreed-upon conventions rather than national law. Once everyone in the Bitcoin universe agrees you own a certain bitcoin, you can exchange that bitcoin for goods and services.
These predictions are all 100% accurate, just like Ted Danson's prediction that all U.S. cities will be completely uninhabitable by 1980 because Reagan was president throughout the 1970's and are even MORE accurate than ALGORE's 100% accurate prediction that the entire polar ice cap has permanently melted and all polar bears are dead.
Which specific predictions are you talking about? Nobody brought up Ted Danson, so I fail to see his relevance unless you are making this argument: if Ted Danson's predictions aren't accurate, then nobody's can be.
In any case it seems to me that the summary and linked article is kind of sloppy, almost as if it were designed to provoke this kind of silly strawman response.
For example, the notion that the power grid might be vulnerable to a geomagnetic storm the size of the 1859 event isn't a prediction. It's merely an assessment of vulnerability to a rare but possible event (e.g., a 14+m tsunami hitting Japan). A large geomagnetic storm is a possibility that should be taken into account, not an event to put on the calendar.
Likewise, nobody is suggesting that there's anything special about the 400ppm CO2 figure, other than that it is a round figure. It's common sense to look for climate impact, not because we've hit some "magic" number, but that CO2 levels are higher than they've been at any time in the past three million years. This is especially so because the slope of the CO2 concentration graph shows no sign of topping out.
Keep in mind there's no such thing as a "natural disaster". There are only natural events that catch us unprepared. There's nothing inherently disastrous about flooding in Bengladesh, except that economics and politics forces people to live in the flood plain. Likewise there's nothing about a world that's two or three degrees warmer that makes it uninhabitable by humans, but the changes involved along the way will be *perceived* as catastrophic. For example models predict a drier western US. That doesn't mean that one day it will stop raining, it only means that rainy years will be less common and drought years more common. For all we know we'll have a rainy year in 2014, but it still makes sense to plan for the day when the Colorado River won't be able to supply all the water cities in the west require from it (Los Angeles, San Diego, Denver, Phoenix, Tucson, Salt Lake City, and others). The disaster won't be lack of water, it will be lack of preparedness.
Slashdot Mirror
Well, that's just a slippery slope argument. The real problem with the Catholic position here is that it is incoherent.
Covering contraception under a health plan is not "paying for contraception". It's paying for contraception *coverage*, because it is the employee that decides to take the medication -- which by the way has numerous other therapeutic applications besides contraception. What's going on is the RC church trying to interfere with their employee's medical coverage.
Short, simplistic answer: the ISP found a way to fraudulently skim a percentage from online retailers for every purchase made by the ISP customers.
Slightly more detailed answer: the ISP directed users looking for online merchants like "amazon.com" to it's own bogus server. That bogus server then re-directs the user's browser to the merchant's server in such a way the consumer doesn't notice and the merchant thinks the customer is following a product referral from an advertising partner. Thus the ISP collects a kickback intended for people who make product recommendations and referrals, without actually having made any recommendation or referral.
the topic it describes would be an acre of bread.
The optimist's viewpoint is that 60% of American's *do* believe in evolution.
There's a big difference between people who are capable of doing things "by the book" making an informed decision not to do so, and people deciding to do things in an ad hoc manner because they can't master the "by the book" method.
Every successful project, in my opinion, requires both discipline and risk taking; the art is knowing how much of each the project you are currently managing needs. Every project should have a bit of a stretch built into it, otherwise people get sloppy because they've become complacent. But *too* much risk, and they get sloppy because marginal additions to risk become meaningless to them.
You want control and measurement and all that rational stuff, but developers aren't automatons. They need motivation to care about those things; if they're just going through the motions a formal methodology becomes so much dead weight. So excitement, challenge, novelty, even a whiff of fear can be healthy things. But not chaos, impossibility ,blue-sky goals and outright terror. An excessive dose of medicine is poison.
I expect that they object to being viewed as persons of intrinsically lesser capability.
It's wrong, although not malicious, to say "deaf people are vulnerable," because vulnerability is not a permanent attribute; it's an ephemeral state that can usually be engineered out of the environment. A level crossing with only a crossbuck sign can be fitted with flashing lights.
The difference I was originally highlighting was more that Wave integrated with XML at the server, in a season that people realized the implications of "AJAX" (i.e. JSON)
Well, seems like apples and oranges to me. AJAX is not a data representation model, it's a communication model. If you have to, say, obtain data from a server to repopulate an HTML table in response to a user action, JSON fits the bill, because you need only the most rudimentary semantics. But that doesn't mean JSON can replace XML for every purpose, e.g. something like Open Document Format. So you might well do a lot of AJAXy stuff with JSON to the browser, but do a lot of DOM manipulation stuff on the server side.
Not every tool has to work equally well for every task.
I'm not saying that it makes no difference. I'm saying it's an implementation detail, which is a far cry from saying the choice never matters. If you can't grasp the distinction between a choice mattering and it needing to be localized in a design, you'll never be a competent software designer.
If a system is somehow irretrievably ruined by choosing XML over JSON, then bad programming must be at least equally to blame because if you don't need any XML features that JSON doesn't have, the switch should be easy.
Most people are priggish busybodies. If they don't understand something, they act like that's proof its worthless.
That said, a lot of the fun of art is having opinions about it. Not liking a piece of art isn't the same as "shitting on it". You like what you like; where you end up on treacherous ground is when you have an opinion about what other people *ought* to like.
I don't like the novel Twilight. I have very specific opinions about things that are not good about that novel. On the other hand, I understand why the people who like that novel like it. My not liking that novel doesn't make me better than them, only different. Likewise I can tell you a lot about what's wrong with Lord of the Rings as a novel, but it's a story I love and re-read every couple of years.
The more serious you are about an art form the less it becomes about what you like or don't like. Liking or not like is still important, but it's not everything.
Most of the complaints I hear about XML are really complaints about lousy software architecture. Yes, XML is complex, but that should cause *zero* hassle on the front end. If it is causing hassle throughout your project, you're doing something wrong architecturally.
The desire to flex your muscles in a hot technology often overwhelms good design sense. Thus ten years ago you'd see people parsing and doing XML DOM tree manipulation directly in UI code and crap like that. Doing the same with JSON would be just as bad design, although since JSON's feature set is much smaller the results are less immediately catastrophic. But they're still bad design.
If your objection to XML is that it spreads complexity throughout your code, you're just a mediocre coder. Choosing XML or JSON should be a very minor implementation detail.
Isn't there a massive oil boom going on in the US and other countries at the moment?
Yes, and not for the first time either. There was a shale oil boom in the 1970s that went bust when Saudi Arabia opened the oil spigots in the 80s.
Note what this means: we knew the shale oil was there; we had the ability to get it, but we left it in the ground because it was more expensive than regular petroleum. As we anticipate not having access to cheap oil, we're turning *back* to shale.
This is what it looks like when a planet runs out of oil. It's not like one day you pump the last drop of petroleum out of the ground. We'll never get that far. What happens is that we'll go after increasingly marginal sources of oil, until the day comes that the next drop of oil extracted is more expensive than some alternative energy source. And because what is "economically extractable" is dependent on technology, nobody can put a precise date on that, but looking for more energy efficiency and resuming shale oil operations are two sides of the same coin.
The F150 has been the best selling vehicle in America for decades, so it takes a lot of guts, or a lot of motivation to do something radical with it. I'm guessing that Ford isn't doing this out of public-spiritedness, but because they anticipate higher fuel prices some time in the next few years.
Of course comparing gasoline prices to global production is a bit like comparing weather to climate; there are factors in play which swamp the long term trends -- over the short term. Still I've seen some predictions that gasoline will hit $6/gallon in the next five years from it's current level of $3.65/gallon. If that prediction is even remotely true, then even if the new truck is plagued with problems it'll be a winner. And eventually crude prices are going to send gas prices that way.
Aluminum *does* corrode. In most situations the oxides form a stable protective layer, but in situations where aluminum is in contact with dissimilar metal you can get galvanic action and the less noble metal will corrode. There's also a phenomenon called stress corrosion cracking where a metal in a corrosive environment can fail catastrophically after being repeatedly exposed to stress.
So a piece of structural aluminum near a fastener in a salty environment isn't safe from corrosion failure. Naturally I'd assume Ford is on top of this, and you'd have nothing to fear from your new aluminum truck. How safe it would be after a ten or fifteen years of being driven hard over New England roads is something that I wouldn't be altogether sure of. Again I'm sure the engineers have taken this into account, engineers are fallible so we'll have to wait and see.
Steel really is an amazing material, both strong and tough. It tends to fail in benign ways (bending rather than breaking), which also contributes to the safety of a steel vehicle. When steel is damaged it is easy to repair. My wife has had a couple incidents with her car and a certain steel beam in the garage at work. When it happens we replace the passenger side doors and have our mechanic beat the door pillar back into shape with big hammer. I'm not sure an aluminum vehicle could be repaired this way.
So as a geek I'm delighted Ford is trying something new. But there are good reasons nobody's attempted this before. I'm hoping it's a brilliant success, but we won't be sure until the vehicles have been on the road for a few years.
Find someone to blame, then make sure they get *all* the blame.
Now, imagine what happens with the plumbing analogy when you try to make everything go backwards.
Alright, I'm game. We're talking about residential rooftop panels, right? Here goes.
I'm imagining... nothing happening.
According to the link the panels the guy installed generate 35kw. That's bound to be sucked up by his neighbors on the running off the local transformer.
Still not enough to merit an accusation of dishonesty. It's just an interesting fact, that people with working brains can take into account without hyperventilating.
It actually *is* a quite interesting fact, because it shows how the relationship of antarctic ice to global temperatures is quite complicated, as are weather conditions in any one region of the Earth at any particular time. It's something to keep in mind, next time you look out your window and see a little unseasonable snow, or unseasonable sunshine for that matter.
to do something that furthers his criminal enterprises has a name. It's called "conspiracy".
So if you ever try your hand at hunting down criminals like this, be aware of the potential danger of tying yourself to the criminal's legal fate. If you've done business withhim that's the least bit shady, and he's overseas beyond the reach of local authorities, things could get quite ugly for you.
I assumed "it" referred to his basement.
Maybe the world has colors in it besides black and white.
Well, we're talking far too abstractly here to be very meaningful. I'm not saying an RDMS couldn't be *part* of the picture. I'm saying that a system architecture that punted all the persistence and data consistency problems to a distributed RDBMS is a non-starter for something on this scale. People don't build systems like this one that way. If they don't, even though that technology is a mature one, that's a good reason to be skeptical of the idea that that approach would be a panacea.
No, it doesn't have the "pop" of NoSQL,
More to the point, it doesn't have the scalability across distributed systems. Show me one application approaching this scale, just *one*, that relies RDBMS clusters and two-phase commit exclusively to support this kind of transaction volume. Don't get me wrong; I'm an old-school RDBMS guy myself; I know a lot about relational database systems, including their limitations. I'd look to the way outfits like Amazon, ,Google or LinkedIn design their infrastructure rather than Oracle on big iron. This is well outside the sweet spot for that approach.
RDBMS servers are made to just do the job quietly and reliably, with very strict ACID compliance...
This is a very simple-minded approach to architecture, one that's admittedly very serviceable in a wide array of applications. But useful as ACID is as a set of assumptions you can rely upon, it's not the only way to create a reliable, serviceable system. In fact there are situations where it's provable that ACID falls short. Google "CAP Theorem" and "eventual consistency". It's fascinating stuff.
It does not sound to me as though known management tools were used. Did they sit down with the government personnel in charge, and present their approach, and what the site would look like (menus, flow, etc) when finished? Were there testable milestones, and a final presentation of working software? It sure doesn't sound like it.
They might well have done all these things and still failed to catch the problems before the site's launch.
Performance, like security (ack! scary!) is a non-functional requirement -- that is to say it's not the kind of requirement where you can sit down with a checklist and say, 'yep, this it works,' or 'no, it doesn't.' You have to develop a more sophisticated test.
Load testing is a step in the right direction, but you also have to look at system architecture. Remember the days before people figured out that you had to load web ads asynchronously, after the page content was loaded? Sometimes the page load would be slow, not because the page's server was loaded, or because of the user's browser or internet connection were slow. Often it would be the ad server that was overwhelmed, which if you think about it is bound to be more common than the content server being overwhelmed. You could functional test and even load test the heck out of a page with synchronous ad loads, but until it went into production chances are you wouldn't catch the fatal performance flaw. That kind of problem is architectural; some of the data being delivered is coming from servers outside your control.
Ordinary tests are about ensuring reproducible results, but when the architecture leaves you vulnerable to things happening on servers and networks outside your control your problems *aren't reliably reproducible*. You have to design around *possibilities*.
Some of the problems with Healthcare.gov were of this nature, although with not so simple a solution as "use window.onload()." The site is supposed to orchestrate a complex, *distributed* process *synchronously*. You have to go out the Homeland Security's database to confirm citizenship, then to the IRS databases to confirm claims about income, then get quotes from the private insurers that meet the customer's needs. There is, in my opinion, no way to be 100% sure, or even 80% sure that a system like that will work under real work load, unless you present it with real work load.
Were I architecting such a site, I'd plan to do a lot of that work batch; that is I'd build the healthcare application offline on the user's browser, with internal consistency checks of course. Then I'd send the user's application through a batch verification system, emailing him when a result was ready. This is a clunky and old-fashioned approach, but it wouldn't force the user to chain himself to his browser . And it would have more predictable performance. Predictability is a vastly under-rated quality in a system. A system which is fast most of the time may not be as desirable as one which provides the answer consistently.
Let me start with a disclaimer: I'm not an expert in Bitcoin, but this is my understanding.
One of the important differences between Bitcoins and regular currency is that every bitcoin has an unique serial number. This is not true for dollars; oh a particular banknote my have a serial number, but the dollars in your bank account have no individual identity. The fact that every bitcoin has a serial number makes it possible to distribute information about who owns a particular bitcoin. Thus the physical location of the fact of ownership is the entire network of computers participating in bitcoin transactions. Naturally, the protocol has provisions for resolving contradictory assertions, so that over time the network will converge towards consensus on any particular bitcoin.
Now as to how Uncle Sam can 'seize' a bitcoin, it's simple. Uncle Sam doesn't seize your bitcoin *wallet*, he seizes the cryptographic keys you use to conduct Bitcoin transactions. Then for every bitcoin X in the wallet, he sends out the message, "I, BringsApples, transfer bitcoin #X to Uncle Sam." Furthermore, since the protocol is de-centralized, there is no mechanism for the participants to agree that bitcoin X really belongs to you. The only way to "get the bitcoin back" is for Uncle Sam to broadcast a message, "I, Uncle Sam, transfer bitcoin #X to BringsApples."
The bitcoins don't reside anywhere, including in any particular "virtual wallet on a PC".
If you don't believe that, make 100 copies of that "virtual wallet" and ask yourself if you now have 100 times as many bitcoins.
Well, let's ask a far more pertinent question: if you make 100x copies of wallet, do you have 100x the bitcoin purchasing power? The answer is no. It is theoretically possible to spend the same bitcoin twice, but th protocol is designed so that on average that costs more than obtaining a second bitcoin legitimately. You don't have to make it impossible to cheat; you only have to make it pointless.
A bitcoin is an abstraction, just as the dollars in your bank account are. If you have $100K in a bank account, that doesn't mean there's a stack of banknotes in the vault that corresponds to that. Your funds "in the bank" exist only on that bank's ledgers. They have no physical existence, they exist according to a set of rules which assign those dollars to you. When nearly everyone in the system agrees that according to the rules you have $100K in the First National Bank of Podunk, then you've got $100K there. Bitcoins work exactly the same way, except the rules are voluntarily agreed-upon conventions rather than national law. Once everyone in the Bitcoin universe agrees you own a certain bitcoin, you can exchange that bitcoin for goods and services.
These predictions are all 100% accurate, just like Ted Danson's prediction that all U.S. cities will be completely uninhabitable by 1980 because Reagan was president throughout the 1970's and are even MORE accurate than ALGORE's 100% accurate prediction that the entire polar ice cap has permanently melted and all polar bears are dead.
Which specific predictions are you talking about? Nobody brought up Ted Danson, so I fail to see his relevance unless you are making this argument: if Ted Danson's predictions aren't accurate, then nobody's can be.
In any case it seems to me that the summary and linked article is kind of sloppy, almost as if it were designed to provoke this kind of silly strawman response.
For example, the notion that the power grid might be vulnerable to a geomagnetic storm the size of the 1859 event isn't a prediction. It's merely an assessment of vulnerability to a rare but possible event (e.g., a 14+m tsunami hitting Japan). A large geomagnetic storm is a possibility that should be taken into account, not an event to put on the calendar.
Likewise, nobody is suggesting that there's anything special about the 400ppm CO2 figure, other than that it is a round figure. It's common sense to look for climate impact, not because we've hit some "magic" number, but that CO2 levels are higher than they've been at any time in the past three million years. This is especially so because the slope of the CO2 concentration graph shows no sign of topping out.
Keep in mind there's no such thing as a "natural disaster". There are only natural events that catch us unprepared. There's nothing inherently disastrous about flooding in Bengladesh, except that economics and politics forces people to live in the flood plain. Likewise there's nothing about a world that's two or three degrees warmer that makes it uninhabitable by humans, but the changes involved along the way will be *perceived* as catastrophic. For example models predict a drier western US. That doesn't mean that one day it will stop raining, it only means that rainy years will be less common and drought years more common. For all we know we'll have a rainy year in 2014, but it still makes sense to plan for the day when the Colorado River won't be able to supply all the water cities in the west require from it (Los Angeles, San Diego, Denver, Phoenix, Tucson, Salt Lake City, and others). The disaster won't be lack of water, it will be lack of preparedness.