Even more than that, if this is a success it could even increase the likelihood that Apple adds native NFC capabilities to their devices, by demonstrating that it's useful (and to whom and for what).
Like a couple others have said in this thread, I think this is more about bootstrapping an ecosystem driven by network effects -- the more people adopt it and the sooner, the more useful it becomes and the more likely it is to actually go mainstream.
Flomio isn't just selling this device; look at the higher reward levels -- they're also selling an SDK and cloud analytics infrastructure -- I think they'd be perfectly happy if nobody needed this because it was built in.
Flomio was doing other NFC stuff before this, and considering the mentions of the SDK on the kickstarter page, I think that's their real play. I think they'd be perfectly happy in a world where this product isn't necessary. In the meantime, this is necessary to drag Apple devices into the small but growing ecosystem (and the utility of the NFC ecosystem is largely driven by a network effect, so this bootstrapping is important).
Yelp's points of interest are frequently at the wrong location. I've noticed this using Yelp's native app, which displays things on Google maps, ironically (ironically because Google knows the correct location if you search for the same place by name; I heard that Yelp stores lat/long for each place instead of letting Google look it up by name).
In my experience, this problem with Yelp's data is worse in Europe than the USA.
I think this is their "extensive beta and data collection period". Just using the entire iOS 6 customer base as the experimental set.
I think it would be kinda cool if they'd push the new maps as an app available for iOS 5, and if Google had their native iOS maps app ready, and the transition weren't so abrupt. I realize the mapping subsystem is baked in more deeply, with various APIs and libraries available to all apps on the system, not just a standalone app, but it would still be helpful to have the standalone apps. (If Apple Maps were available as a standalone app, that would facilitiate the "extensive beta period" you suggested without all the ire that they've attracted this way; and I really hope that Google Maps is coming back to iOS at some point real soon now.)
Actually, the open letter also recommends Google and Nokia maps, via their websites (because native apps don't exist).
BTW: Am I the only one that thinks it's fishy that Google's claiming (a) they only had 3 months notice of this change and (b) 3 months isn't enough to produce their own iOS maps app? I don't believe either of those claims.
I just got back from a 2 week vacation to Ireland. I planned and executed most of the trip on the fly using Google Maps on my iPhone 4S (3G data is cheap in Europe, even for nonresidents on prepaid SIMs!) running iOS 5.
Just out of curiosity, after I got back, I upgraded my iPad to iOS 6 to see whether all the complaints I'd read about Apple's maps were legit. Then I went and looked up a bunch of the places we'd traveled or stayed in Ireland, to see if the new maps would have gotten the job done. Short story, it would have been a lot harder. In the spot checks I did, the roads are there, and in one case the driving directions are better than what Google recommended, but it mostly didn't know what I was talking about when I searched for businesses, like hotels we stayed at.
Google has amassed a huge amount of really high quality data, not just roads but also businesses and places, which nobody else has. I don't know if there's widespread appreciation for how hard this is and how hard Google's been working on it (one example, and I'm sure this article is slightly politicized and the timing of it appearing now is no coincidence, but still, it's mostly fact: http://www.theatlantic.com/technology/archive/2012/09/how-go...). Hopefully Apple has the staying power to go amass the same data, but it's an uphill battle.
So neither the instapaper blog post (linked here) nor the news.me blog post (http://blog.news.me/post/21643399885/introducing-paper-boy-a...) comes right out and says it, but the point here is that since iOS doesn't let an arbitrary program schedule itself in the background or on a time-based schedule, but the iOS geofence APIs do let an arbitrary program schedule itself when you cross a geofence, you can abuse the latter to simulate the former?
The puzzle-piece representation of structure is neat, but at a 2-minute glance it seems not to scale to real complexity.
One of the big ideas in programming is abstraction/modularity/reuse, and I don't see how that fits in here.
(I found the "procedure" block, but I don't see anything that fits inside it other than "break out of loop", which doesn't make any sense. And I don't see how to call the procedure.)
So I find myself looking at the samples everyone's demonstrating here and finding they're harder to read than real well-organized code.
Well. There's a difference between "lack of sympathy for those who would violate copyrights" and "indiscriminate sueing of file sharers".
(Especially how it's turned out -- the few cases that went to court and proceeded to a verdict have absurdly huge penalties; the suits were structured so that often an accusee's best strategy is immediate settlement even if innocent.)
Many of us do rely on IP law to get paid, and there do need to be ways to reward and encourage creative work, but there also needs to be a balance.
Sun probably knew that at the time but due to hubris didn't want to admit it, so they just willingly looked the other way and kept doing what they were doing. So you get Jonathan Schwartz, in 2007, wishing that Google would take a license, but begrudgingly congratulating them anyway, but not doing the "Official Android Pro SDK" thing you suggest. (http://web.archive.org/web/20101023072550/http://blogs.sun.c...). So that was a small mistake, a missed opportunity, but life went on.
Then at some point (maybe even before they purchased Sun, maybe after?), Oracle decided to waaay up the stakes with this lawsuit. Given how it's turned out, I'd call that a much bigger mistake.
So it was probably a little clear even to Sun in 2007 that alienating Google was the wrong call but/so they decided not to do anything about it, and then Oracle, well, I don't know whether it's correct to characterize this as missing a call vs intentionally taking a big risk in hopes of a big reward.
It's not so simple as a magic section; AMT may or may not apply.
If you got the stock as a gift, or (more likely in this startup context) an RSU grant, the entire value is taxed as ordinary income at the time you receive the shares. I don't think there's any special AMT treatment here.
If you purchased the stock using NQOs (non-qualified options), the difference between the strike price and fair market value is taxed as ordinary income at the time of purchase, and again I don't think there's any special AMT treatment.
If you purchased the stock using ISOs (incentive stock options), then you have to watch out for AMT -- under normal rules, you don't owe tax at time of purchase, and when you sell, if you held long enough, the gain from strike price to FMV at purchase time may be taxed as capital gains. But under AMT rules, the purchase is a taxable event, and you may owe tax at exercise time.
Under any of these, if you exercise (or are gifted) shares and hold them and they decline, you may end up owing taxes on the higher on-paper value that never meant real money to you, and this ends up feeling unfair. But this case is generally obvious enough you would see it coming, except in the ISO+AMT case which is much less obvious, and this difference is what screwed a lot of people in the 2000-era bubble burst.
Normal disclaimer: I'm not a lawyer or accountant, there are many more details that apply here, and you need to figure out what applies to you before making any important decisions. But I believe the above is basically true.
The example you gave is pretty unlikely: (a) someone gives you a million dollars in stock and (b) you didn't know that was coming to prepare for it and (c) the stock immediately goes to 0 before you can sell it. Just noting that.
Still, this would likely end up in separate buckets. Someone giving you a million dollars in stock very likely counts as income, not capital gains. You'll have a tax liability for $1MM in income. Then, should it actually go to zero, you've got a $1MM capital loss. In general, capital losses are not fully deductible against income, only capital gains. I hope you also had a $1MM capital gain so you can do something with the loss...
But again, this case is pretty contrived. Likely if you're getting a large amount of stock like in this example, you know it's coming, and can decide what to do about it before it suddenly goes to 0. (Hint: holding onto it is deciding to let it ride.)
How can this possibly be what the tax code says? It just is.
Well, you shouldn't compromise on any of those if they're important to you. And if you don't care about your username, then great, one less thing to have to worry about.
But I think for anyone that does care about their username, it's a sign of respect when the company lets you choose it, and a sign -- not the end-all, but a sign -- of trouble ahead if they can't, and the OP's point is valid.
(The thing about large monitors isn't the end-all-be-all way of judging an employer either! These are just litmus tests that give a very quick way of judging whether they have an engineering-focused culture. I'd expect these factors to largely align, but hey, if there's somewhere that gets both these tests wrong but everything else right and is still an awesome place to be an engineer -- more power to them.)
Yup, it's just one metric, and "after 3 years" is pretty arbitrary.
Still interesting if you keep this in mind.
But I'd argue the most relevant time (for comparison of how well these companies built stable long-term value) is now, and it would be interesting to see numbers for % growth from IPO to now, or better yet, that measured per year (CAGR).
I actually think the transition from 3 to 5 (directly) is more interesting than the one from 4 to 5. Well, they're both interesting, so it's cool the visualization supports both.
I'm trying hard to let your valid points stand out from the rampant homonym abuse (effects should be affects, it's should be its, brake should be break)!
As others pointed out, that is at odds with the previous paragraph ("We will establish a secure connection from the cloud to the site owner on your behalf").
Also, unless they stop doing the Silk combining thing entirely, I don't see how it's possible not to peer inside the requests. They can either pass along the traffic without knowing what it is (meaning they can't cache, or combine, requests or responses, because they don't know what's in those requests and responses), or they have to see inside.
This, to me, means they're taking liberties with the meaning of "direct connection" in the snippet you quoted, and, if I'm being pedantic, I don't see how the final sentence ("Any security provided ... would still exist") is literally true at all. Seems to me that being end to end, encrypted by a key only you and the other end, know, is a form of security that does not still exist in this architecture.
(Somewhat off topic, but when using earlier-generation Kindles with whispernet 3G, over 3G, all traffic is proxied through Amazon's datacenters, even for SSL, and I have no idea if it's secured end-to-end all the way to the device, or decrypted in Amazon's datacenter, and possibly re-encrypted to send OTA to the device. There's no way to tell.)
And I don't see how it's possible for them to proxy SSL content without being MITM and re-encrypting. They could stay entirely out of the way for HTTPS requests, but if that's how they were doing it, I think their FAQ answer would just say so. If, on the other hand, they're inline enough to do the Silk acceleration thing at all, they have to be able to decrypt the traffic.
Like a couple others have said in this thread, I think this is more about bootstrapping an ecosystem driven by network effects -- the more people adopt it and the sooner, the more useful it becomes and the more likely it is to actually go mainstream.
Flomio isn't just selling this device; look at the higher reward levels -- they're also selling an SDK and cloud analytics infrastructure -- I think they'd be perfectly happy if nobody needed this because it was built in.