HN user

aflinik

52 karma
Posts3
Comments44
View on HN
Poor Man's Polaroid 5 months ago

This is a really inspiring project and exactly the type of content I'm looking for on Hacker News.

A bit surprising that so many people in the comments would rather see links to cheap temu polaroid knockoffs.

There has been a similar project developed in Poland already. (https://en.media.pkobp.pl/78483-strategic-partnership-betwee...) In practice it's not much more than government-branded version of Google Cloud Platform and Microsoft Azure. So far it serves well as a marketing vehicle for a handful of the biggest corporations, but it's barely used by anyone.

I can see it could make sense as a solution to some particular problems though – European regulations often forbid banks from processing/storing customer data in other countries, so even though the tech is provided by the American tech giants, having everything hosted locally makes it possible for local financial services to finally move away from hosting everything on premises.

I’d say all of those examples show that you need to be first to the actual market, not just first or first to _some_ market

Having it learn on human games was just a way of speeding up the initialization process before running reinforcement learning, it didn't limit the state tree that was being searched later on.

Economic Inequality 11 years ago

Being a Pole, I wish more people understood that. :(

We're in the process of dismantling our democracy by removing all of the checks you mentioned, while supporters of the ruling party argue that democratically elected majority is within full rights to do it.

That's true, although I see no reason Elm couldn't be compiled to server-side JS running in Node.

I'd love to see some full stack solution that would abstract away separation between backend and frontend (like Meteor perhaps) using some sane programming language and architecture.

Having built lots of SPAs and APIs serving as a backend for them I always feel that what's really relevant is modelling your data and domain logic (which tends to happen on a server side) and the UI consuming this data on the other end. Everything in between – endpoints exposing the data on the backend, frontend machinery to pull that data into client – seems to be totally arbitrary and implementing it is nothing short of a grind.

Although it's meant to be sarcastic, I believe it nicely exposes typical things developers used to argue about back then, not that different from modern arguments about JS vs compiled-to-js, elixir vs erlang, GC vs manual memory management, etc.

Anybody knows some more serious piece from those times that would show the actual arguments of, say, PASCAL opponents?

According to this quiz, you can either have small guaranteed impact or bet on something bigger while accepting you might fail.

I wonder what's their take on bootstrapped startups, that have potential to grow exponentially but don't rush it valley-style. Biggest long-running tech companies had positive revenue since very early in their life (if not day 1).

Think of it as of seeing URL printed on the wall (or hidden in QR-code), just easier to use if you actually want to.

It's not spamming notification center. Whenever the beacon signal is heard the information about it is shown in Chrome widget, but you still have to manually go there to see it. If you ignore it and move away from the beacon it will simply disappear.

We're doing sensor-fusion trying to use as much data as possible coming from different sources, so besides RSSI from beacons there's also accelerometer, magnetometer, etc. Lots of non-trivial maths to combine that into a robust model, but results are getting more and more incredible. :)

I remember React devs saying they always remember about that, so the whole library is designed to be easily detachable from the DOM, or whatever renderer you might be using. They're also kind of proving that now with ReactNative, and knowing what's coming in the next React versions it's gonna be even better.

Nice thing about React is that even after you remove the Virtual DOM it still encourages a really good model of programming and makes it effortless to build your app.

Don't see how that's a bad thing, nobody forces you to use it, and odds are some nice ideas will get validated here and more popular frameworks will adopt them. Think how React influenced the changes in rendering models of Ember, Angular, etc.

Always baffles me how HN crowd can at the same time revere Lean/Agile mindset, and at the same time despise the same principles applied to the tools ecosystem. To me it's obvious that to make progress of any kind multiple attempts are needed. Naturally only few of all those experiments will survive, the thing is nobody knows which ones.

I'm curious to see real world deployments of Angular based apps, even without the source code.

FB's React is much younger and we already can see it used in lots of popular web apps, but given the Angular popularity among the devs there's surprisingly little.

You're criticizing the raw JS language, but that's not what most people in the industry are using. Fine, the original language design was horrible, but if you consider the typical stack used for web development (which could be any combination of transpilers like CoffeeScript/TypeScript, Flow, Promises, module systems, etc) it's not that bad.

Also we already have Strict mode; I imagine in the future it will get more and more uncompromising, so the JS subset we'll be actually using will be just fine.

Thanks for your feedback! Sorry to hear about faulty beacons, what happened definitely doesn't sound normal. I'd suggest to contact our community team at contact@estimote.com and they're probably able to replace these beacons with new ones.

Indoor SDK is still in very early phase, but we're pushing very hard to roll out a series of updates with new features like multiple rooms support, cloud integration and even better accuracy, so you can expect more comprehensive solution in the near future.

And if you're interested in bigger deployments we also offer beacons in bulk quantities with much better pricing.

We're treating R&D very seriously as we're thinking of beacons as much more than simply hardware. There's still a lot of ideas to explore and we try to support the community as much as we can, so I hope you'll give it another chance.

Thanks again for sharing your thoughts. That's extremely important to us and makes it possible to address issues people have with beacon technology ASAP

(Disclaimer: I work for Estimote) Indoor location works much better if you utilize data from other sensors in the phone (like accelerometer etc) and apply machine learning to make better sense out of all the signals. I'd suggest you take a look at our SDK that works surprisingly well even with just 4-5 beacons. You can also map your room with our iOS app by just walking around it. You can find it here if you're interested: http://estimote.com/indoor/

We've also implemented some adaptive algorithms to optimize the battery life in our beacons, so with conservative settings they should work for 5+ years now.