metamatt

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.

Just my opinion:

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)!

Instagram: - tints photos - uploads them - and has 30 million users

I largely buy the gigaom explanation (http://gigaom.com/2012/04/09/here-is-why-did-facebook-bought...). That's why the water-in-desert metaphor is, IMHO, very apt.

Yup. Also pointed out here (http://news.ycombinator.com/item?id=3051585), sourced to the official terms and conditions (http://www.amazon.com/gp/help/customer/display.html/?nodeId=...).

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.)

Yeah, that's what I find worrisome as well.

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.

The forces in HP's favor in the tablet market are pretty different from the forces in Android's favor in the phone market.

But that said, I agree the tablet market is just heating up. The iPad is a pretty formidable competitor, not just because of its existing market share but really because it's a good product. Still, there's room for more than one product.

My impression (from reading press, not from firsthand experience) is that a few Android vendors (notably Samsung and Motorola) and RIM have all stepped up to the plate, took a swing, and pretty much struck out. Maybe they'll get better over time -- probably they will -- but it looks like they shipped too early and quality suffered as a result; the reviews I've read have been largely negative. Meanwhile Microsoft doesn't have anything coming soon.

All that means HP has a really good shot at the #2 spot right out of the gate.

If that's enough to get developers to return to webOS, the platform might still have a chance.

I'll echo the other reply to your post -- have you any experience with webOS?

I've gone back and forth between webOS and iOS phones over the past couple years, and while webOS is not better in every way, and is significantly handicapped in some ways, it's also significantly better than iOS in some ways. I really don't see webOS phones as poor attempts to jump on a bandwagon just to scrape whatever profit they can. This is much more a case of healthy competition.

I too expect Apple will eventually adopt a similar multitasking paradigm for iOS (you could call it Exposé-inspired, or webOS-inspired, as you wish), negating webOS's most obvious advantage. Which you could attribute to the effects of competition. Or maybe Apple would have inevitably done it once the hardware got powerful enough -- who knows.

Who knows how much they will make on Nokia Windows phones, but right now they're making $0 from them since there aren't any yet.

He's saying if he could optimize away all the requests by crawlers and robots, he'd have half as much work to do. Doing twice as much work costs more -- on the server side to serve it up, and on the network side to transfer it.

It's not literally a speed comparison, but you can imagine how if you could optimize away all the robot requests, you could do something else with the time and resources you'd formerly spent serving them.

The smugmug addendum to the story explains this pretty clearly.

And gratuitous roundtrips are fun, too :P

(You're uploading the data in order to then convert it client-side. Groxx noticed this too: http://news.ycombinator.com/item?id=2464347)

What volume do you really need, to get enough data to learn from? I'd think that 1% of Google traffic would still be a pretty big firehose to feed whatever learning algorithm you need to feed.

Don't Google, Facebook, et al run a lot of experiments for new projects on a subset of users/queries that's far smaller than 1% of traffic, and still yields very useful results?

I mostly agree with you, but I'm not sure the next frontier in web search is spelling correction. I feel like there have to be ways of producing better search results that work better than upranking the ones people click on.

On other CDMA smartphones, I've never seen data activity send callers to voicemail -- the call goes through, the data connection stalls until the call ends.

Not optimal, surely, but nowhere near as bad as sending calls to voicemail without ringing like the old iPhone on EDGE.

"Locking" doesn't mean the same thing it does for GSM phones; CDMA phones have a builtin ID which is registered with the network, and there's no SIM card or equivalent to swap out to change that ID.

Sprint and Verizon both use the same CDMA frequencies in the US, and Sprint and Verizon phones roam on each other's networks. But there's no button on your Sprint phone to push to make it a Verizon phone, or vice versa. Sometimes you can get the carrier to do it for you -- the new carrier can choose to activate your existing phone on their network. At least I remember stories of people doing that; I never tried it so can't speak from personal experience.

People moved to AT&T to get the iPhone, but a lot of them think the experience is subpar, and will prefer not to renew their contracts as things stand.

I expect there's a decent chunk of holdouts who'll have a good appetite for the VZW iPhone immediately, and there'll also be a steady stream of people switching from AT&T to Verizon as their contracts expire.