You don't have to understand everything, but you do need to at least understand the basics, like how networking works, how crypto works, etc. at a conceptual level. I feel like too many developers learn how to program by learning JavaScript and other scripting languages on their own, then jump into app programming thinking that it's only one step harder because you can sort of do it in Python/Ruby/other Obj-C bridged languages/other .NET languages, or because Swift looks like JavaScript, or whatever their logic might be. Unfortunately, it's not one step harder if you care about doing it right; it's a hundred steps harder, but the apparent accessibility of app programming tries to hide that fact, resulting in a lot of people getting in way over their heads.

Too many developers then balk when we tell them that they need to read conceptual books, insisting that they just want to learn how to solve their particular problem. The result is that they understand just enough of what they're doing to be dangerous. It's like deciding to build a house and telling someone, "I just want to know how to cut a board and hammer in a nail." You're likely to get a very strange looking house with no right angles. You really need to start with higher-level design and philosophy texts, then work your way down to the practical texts. That's equally true in programming, but the short-attention-span instant-gratification crowd just doesn't get that.

And I understand the desire to just learn how to solve the problem. I've been there, and I've done that, but only in areas where I was reasonably comfortable. Even then, I've often later discovered that snippets that looked right weren't quite right in certain edge cases, but at least this happens fairly infrequently, because I've taken the time to learn what I'm doing. Developers who don't do this aren't just hurting themselves; they're hurting their users. There's just no reason for that.

Code recycling is one thing, but not understanding what that code does when you put it into a production app or not following best practices is another. As Android gains popularity as a platform to develop for, we're going to lose quality as the new folks jumping onto the band wagon don't care how their apps work or look beyond the end goal. This mentality is already popping up with Android Wear developers who cram as much information as they can on the screen and claim that design guidelines are "just recommendations."

The exact same thing happens on every other platform, though perhaps to varying degrees. I refer to it as the Stack Overflow effect. One developer who doesn't know the right way to do something posts a question. Then, a developer who also doesn't know the right way to do it posts how he or she did it. Then ten thousand developers who don't know the right way to do it copy the code without understanding what it does or why it's the wrong way to do it. By the time somebody notices it, signs up for the site, builds up enough reputation points to point out the serious flaw in the code, and actually gets a correction, those developers have moved on, and the bad code is in shipping apps. Those developers, of course, think that they've found the answer, so there's no reason for them to ever revisit the page in question, thus ensuring that the flaw never gets fixed.

Case in point, there's a scary big number of posts from people telling developers how to turn off SSL chain validation so that they can use self-signed certs, and a scary small number of posts reminding developers that they'd better not even think about shipping it without removing that code, and bordering on zero posts explaining how to replace the SSL chain validation with a proper check so that their app will actually be moderately secure with that self-signed cert even if it does ship. The result is that those ten thousand developers end up (statistically) finding the wrong way far more often than the right way.

Of course, it's not entirely fair to blame this problem solely on sites like Stack Overflow for limiting people's ability to comment on other people's answers unless they have a certain amount of reputation (a policy that is, IMO, dangerous as h***), and for treating everybody's upvotes and downvotes equally regardless of the reputation of the voter. A fair amount of blame has to be placed on the companies that create the technology itself. As I told one of my former coworkers, "The advantage of making it easier to write software is that more people write software. The disadvantage of making it easier to write software is that... more people write software." Ease of programming is a two-edged sword, and particularly when you're forced to run other people's software without any sort of actual code review, you'd like it to have been as hard as possible for the developer to write that software, to ensure that only people with a certain level of competence will even make the attempt—sort of a "You must be this tall to ride the ride" bar.

To put it another way, complying with or not complying with design guidelines are the least of app developers' problems. I'd be happy if all the developers just learned not to point the gun at other people's feet and pull the trigger without at least making sure it's not loaded, but for some reason, everybody seems to be hell-bent on removing the safeties that would confuse them in their attempts to do so. Some degree of opaqueness and some lack of documentation have historically been safety checks against complete idiots writing software. Yes, I'm wearing my UNIX curmudgeon hat when I say that, but you have to admit that the easier programming has become, the lower the average quality of code has seemed to be. I know correlation is not causation, but the only plausible alternative is that everyone is trying to make programming easier because the average developer is getting dumber and can't handle the hard stuff, which while possible, is even more cynical than the original assertion and makes me weep for the future.

Either way, there's something really, really wrong at a fundamental level with the way we search for solutions to coding problems. There needs to be an easy way to annotate the fact that a code snippet was derived from a particular forum post, and to automatically receive email notifications (or bug reports) whenever someone flags the snippet on the original forum as being wrong or dangerous. And we as developers need to take the time to learn enough about the OS and the programming environment to ensure that we at least mostly understand what a piece of code does before we ship it in a product.

Now, now, now, it's not the version control system's fault that you checked in a bug....

I got the same error after a glitch. Turns out the redemption was successful the first time, but because the server was too slow responding to the redemption request, the App Store app timed out. For whatever bizarre reason, it appears that the app store server infrastructure doesn't treat redemption requests as idempotent (clearly a bug), so subsequent attempts to redeem the same code from the same account fail. Ideally, those subsequent attempts should do nothing, but should return whatever magic value tells the App Store app to update its list of purchased items and then do whatever other work it needs to do.

To make a long story short, if you quit the App Store app and relaunch it, the Yosemite beta should appear under the Purchases tab in the App Store. From there, you can start the download.

A nonprofit competitor is required by law to spend any profits they make on upgrading infrastructure. So unless they massively overhire or have higher expenses because of economies of scale or renting a more expensive building, the nonprofit is pretty much guaranteed to be able to undercut any for-profit competitor while providing better service, because it doesn't have the extra overhead of profit taking.

Particularly if all you need is heat. You could potentially build an almost entirely passive desalinization plant fairly readily by building a greenhouse atop the ocean and making the roof slope towards the sides with catch basins that then flow downhill towards the shore. The only thing required is an insane amount of glass (and an insane amount of space to dedicate to it).

Rum, of course. Or, if you prefer, vodka.

In theory, you can always learn more by continuing to study something. In practice, though, modern medicine has a pretty complete knowledge of smallpox. Humans have been studying the disease since before anyone even knew what a virus was. There's evidence that the Chinese were inoculating people for smallpox over a thousand years ago. And the first practical, widespread form of that vaccine dates back to the late 1700s. This was literally the very first virus ever treated with a vaccine. It's well-trodden ground, research-wise.

The problem is, this virus is highly contagious and relatively dangerous compared with other viruses. For variola major, the case fatality rate is typically 30–60%, which puts it among the worst communicable diseases out there, approaching the fatality rate of ebola, and far more contagious. With nearly a two-week average incubation period (and up to 17 days in the worst case), one minor screw-up could easily cause a very serious pandemic before enough vaccines could be produced and distributed.

So basically, you have to weigh the odds of an accidental release (which, with recent revelations about this stuff getting lost for decades, then turning up by accident, seems not so improbable) against the relatively small chance of learning anything new from it that can't also be learned from cowpox or other similar viruses. On the risk-reward curve, this seems to be so far towards the "pure risk" end that any reward would border on undeniable proof of divine intervention, which means the speculated rewards would have to be pretty darn amazing for it to be worth the risk.

What could possibly be gained from further experimentation at this point? We already know how to isolate it and how to produce vaccines for it. And for gene therapy, there are lots of other, less dangerous viruses that can be used as vectors for delivering genetic material. It seems that keeping anything more than the bare minimum amount of material needed to produce vaccines would fall pretty far towards the risk end of the risk-reward curve.

The SyFy version involves a pro wrestler playing the technician. Oh, and the plucky daughter just found out she's pregnant.

Well, that's not entirely true. The voice quality of analog phones has steadily improved, so the amount of data did go up a little bit in that hundred years. :-D

But seriously, we hit a wall with copper, and it only took a hundred years to get there. A single pair (or even a bonded double pair) of copper just can't cut it. But a single fiber provides more than enough growth potential. The current record is 100 terabit over a single fiber, or 100,000 times what most fiber providers currently provide. I figure that's good for another hundred years. Even governments can move at that speed. :-) And unlike copper, you don't have distance limitations from electrical resistance and capacitance. Yes, there's dispersion, but that hundred terabit speed was at a distance of 100 miles (without boosters, AFAIK), so we're talking about orders of magnitude less problems than you get with copper, where a mere ten gigabit over four pairs of copper will barely go the length of your house.

Can anyone explain this situation to me?

At least in my case, you're missing the mark. I've always thought that our state and federal governments were pretty close to incompetent, and I still do. But government-funded nonprofit corporations do work, and at the local level, governments sometimes work.

That long cycle worked fine for the telephone lines that serve your house. They served us well for a long time. The biggest flaw was that instead of managing the infrastructure themselves, they gave it to private companies to manage. Then, when they started abusing the monopoly, the government had to turn around and start requiring them to allow CLECs to use the lines. The phone companies, predictably, hated this, and did the absolute least that they could do to comply with the regulations, often refusing to fix problems with lines while blaming it on the CLEC (and vice versa).

All those problems would have been avoided if the government had simply maintained exclusive control over the lines and leased them out to third parties. That's how next-generation fiber networks in cities should be set up. The entire premise of letting a few companies maintain exclusive control over critical infrastructure is fundamentally flawed and can only lead to more of the same bulls**t we've had for the last two decades.

The only scheme that works is the public utility scheme, where the government owns the wires and private companies provide the service. We know this model works because it has worked with our interstate highway system and private shipping companies for decades. Is it perfect? No. The government historically hasn't charged those shippers enough money in gas taxes to cover infrastructure maintenance costs, resulting in some roads falling into disrepair. But that's mainly a problem caused by lack of a single management body that manages all of the roads in a region. Dozens of city governments working together isn't a great way to get things done except on an "It burns! It burns!" emergency basis. The solution to that problem, of course, is for all the cities in a metropolitan area to get together to form a non-profit corporation, and make that corporation responsible for the management and leasing of lines a la TVA.

And they added commercial radio equipment to warships to ensure that it would never happen again. One would hope that the Russians did similar things to their anti-aircraft batteries after hearing of that incident. If they didn't, one might reasonably ask what in hell is wrong with Russia. And if they did, one might reasonably ask what in hell is wrong with the people who fired that missile today without taking the time to use the equipment.

No, it isn't particularly interesting how it ended up in the middle of a war zone. Not at all. The area in question is not closed to civil aviation, or at least it wasn't prior to this incident. The aircraft was flying about a hundred miles off its usual flight path, which is a completely reasonable deviation when avoiding inclement weather as they were. Presumably, the deviation was approved by the Ukrainian civil aviation authorities.