HN user

heypiotr

5 karma

[ my public key: https://keybase.io/heypiotr; my proof: https://keybase.io/heypiotr/sigs/Vhp9Sg4QOupz7SdCxWtLxiIyBEsDffBICwwaRDOQYJw ]

Posts0
Comments6
View on HN
No posts found.

The thing about CSR BLE mesh is, they differentiate between "active" and "passive" members, and the "active" members use a lot of energy. Mesh in Estimote Beacons is the first that's truly sustainable on battery power alone.

Disclaimer, I'm from Estimote (:

Actually, we did a bunch of testing at Estimote and we strongly suspect that the NFC in iPhones is just the "passive" variety, the same that's being put into contactless cards and the new Proximity Beacon => it's not capable of scanning other passive tags. Unlike the Androids, which are "active", i.e., can power the passive tags through induction & scan them. So it might actually be a hardware limitation, not just Apple's reluctance to open up the API.

We're yet to see how Google implements this on Android. Currently it's iOS only, and the "Today" Chrome widget only, no push notifications at all.

Also, see the above comment from jimiasty about Google ranking/filtering the URLs before it shows them in the widget.

Wholeheartedly agree! We never publish a blog post before the feature actually is live. We want people to be able to immediately go ahead and play with the it—which is also why we treat these posts as mini-readmes, i.e. we always try not only to paint the story behind the feature, but also do a short intro to how to get started (code snippets etc.)

Piotr, Tech Evangelist @ Estimote here. We try to mitigate any of such risks by:

(a) we'll start the sprint with an outline of a blog post, a few key points, and a general theme. Then we get to work, and as we're approaching the grand finale, we start drafting the post. It actually always surprises us—when you start describing something in more detail, you bump into a whole set of "hmm, we didn't think of that", "this could use better docs", "oh wow, that part really is exciting" etc. So it does us a ton of good in terms of polishing the feature we're about to release, but at the same time doesn't block us from moving forward with the implementation.

(b) but really, the rule we try to live by the most is to ship fast and often. A feature doesn't need to be perfect, we're shooting for an MVP. Sounds like a cliche, I know, but it works great for us. Long gone are the days when we'd debate, "maybe a few more RESTful endpoints for these new analytics, maybe a few more filters". Now we'll just ship it and start measuring traction & listening to feedback. If people want more, great, if not ... uh, at least we didn't waste time and can get back to the drawing board (:

From my experience, this usually happens with the older/cheaper Android devices that use a combined BT+WiFi radio/chipset (Nexus 4, Galaxy S3 etc.)

Fortunately, the Android hardware is getting better and better, e.g. I've noticed no such problems on Nexus 5 or Galaxy Edge.