More "we want cheap labor trained with tax dollars" whining from industry. If there were a shortage of programmers, salaries would be going up. They're not.
More like a recruiting video to try to hire every last programmer who hasn't gotten drained by addiction to a video game.
Frankly, I've never seen an office as Stepford as the ones in that video.
I don't know any kid who would look at any office I've worked at in the past 20 years & get that excited about it.
So programmers who can get into a country club like that are gonna go there, and the rest of the world is gonna have to pay those four or five companies for our services.
The battle will really be over the non-smartphone users.
Android has an Achilles heal. It's old, immature and hard to update. It reminds me of Windows XP in terms of user experience and platform vulnerability. It's dug into the market well, but it's only mature enough for "smartphone" users who readily work around quirks and ill behaviors... not enough to grab the non-smartphone user.
This is why iOS will hold on to it's lead while it can maintain the premium smartphone image befitting of its contemporary Mac OS X. That said, "premium smartphone" is the iOS Achilles heal. A cheap, hobbled iPhone won't grab the non-smartphone user either.
BB already lost it's page to Microsoft in the Enterprise market.
More importantly, while MS isn't that popular in the US, it's got a jump on the non-smartphone users overseas... which I bet will only spread. It's got the base OS maturity (security) of Windows 7, the UI consistency of it's contemporary Windows 8 desktop, and the price range to make them accessible.
My wife traded her clunky droid for a WP8, and both our moms (our kids' grandmothers) love their Windows Phones
Another good reason PRO is likely to fail... I've said it before & I'll say it again. Surface is a cloud car.
If I need Intel horsepower on a tablet, I'll remote desktop into a real computer (or cloud-hosted VM). Why pay for Intel in a tablet when the RT version will provide excellent mobile functionality at significantly lower costs (in terms of both price AND power) with the ability to hook up to heavy iron to do the heavy lifting?
The more comments you have in code, the higher risk you have of time sucks and bugs (past, present, and future). Instead, use naming and syntax to make your code as human readable and comprehensible as possible. Bytes are cheap, there's rarely need for clever abbreviations; instead of getting clever with them, get clever with expressing your code closer to plain language. Think about the names of your nouns and verbs (and even adjectives and adverbs), and make sure they make sense to anyone who understands your problem domain.
In my humble opinion, broken code comments are almost as dangerous as broken logic, and should be treated as a bug if it's wrong. It's wrong if it's inappropriate, outdated, misleading, takes more than a line or so, or superficially obvious. If it needs more than a line or so, it should be documented, and the line in your code should brefly identify the problem and documentation location. I'd recommend that it refer to sections within a technical design document.
Just because we haven't explained or observed it doesn't mean it can't be.
Do you believe in a Higgs boson? If so, congratulations... you're a believer. You believe in something that people have spent billions trying to prove the existence of (and still haven't, just yet). If you're not a believer, what is it that you think your mass comes from? Or do you not believe you have mass? Now, if the Higgs is found... that's cool... but what does it get it's properties from? How do you know any of this exists... did you design the LHC and fire it up and make the observations yourself, or did you have faith in someone else's word?
The Bible is full of stories that couldn't be well articulated in the realm of understanding of the audience that originally received it. We had to grow up a bit and start digging into science to discover the deeper meanings of the metaphors.
At least someone put some real effort into trying to make a keyboard layout designed from the start to be easy to type fast.
I don't care who "ran the study" making QWERTY hard to type fast... I'm satisfied that its design goal was met. QWERTY was designed to try to minimize mechanical type-writer hammer entanglement (jams) caused by typing too fast. Anyone who ever used an old mechanical hammer style typewriter has seen how much those jams sucked. As carefully designed as they were to avoid it, get going too fast, and you might even bend a hammer arm trying to un-tangle the mess... then you were out time and money while the rig's being fixed at the shop.
On the other hand, I appreciate that Dvorak's goal was to design something that was easy to type fast with, which is what I need in my line of work. And I appreciate that he did run studies to try to test and/or validate his thoughtful, if not scientific design. It sounds almost like scientific method.
I wouldn't say I put more effort into learning the Dvorak layout, though. I took a class to learn touch typing with QWERTY, and used it heavily & constantly for over ten years, with plenty of "repetitive stress injury" along the way.
I considered learning Dvorak's layout an investigative experiment until I realized that in three or four months' time, my proficiency with Dvorak's layout had at least met my former proficency with the QWERTY layout, if not already exceeded it... no classes necessary. RSI's still happen, but I can push out quite a bit more before I have to take a break.
If you're worried about your typewriter jamming, go ahead... QWERTY might save you some money. But what is it with people who use (and even defend) standards against reason simply beacause they are "popular"?
An authority is a person who can tell you more about something than you really care to know.