Falsehood, IoT, Abstractions, Refactoring, Cloud Spanner, Tools, Fuchsia, HEAD, Sigfox

Post date: Oct 28, 2017 10:08:38 AM

  • List of falsehood's. Nice! CSVs and RESTful APIs. And of course the classic fast, that companies like Microsoft got nobody competent enough to even validate email addresses, I'm referring to outlook rejecting totally valid and working addresses. - The CSVs list made me really happy.
  • Changed loT of internal stuff to use IPv6 alone. Global addressing is just so much nicer than the good old horrible NAT mess with port and IP forwardings. So even if public facing services are also available over IPv4. Many backend services are actually available only by using IPv6. Firewalls, networking and everything is easier to manage with IPv6 even if some seem to claim otherwise.
  • Lot of Python code I write uses abstractions so that basically it's trivial to cloud port it or to run it locally. There are just handlers like get or set data. Which can then be trivially mapped to any kind of blob / indexed data storage. Firebase, RDS, PostgreSQL, MySQL, MS SQL, SQLite3 or flat files, blobs in database, or S3 / B2 buckets.
  • Wondered how many times some basics need to be refactored. Like basic project login & authentication. First basic, then something cool, and then people get annoyed by that cool being too complex, and fall back to basics. Sigh. Well, yeah. That's it. Over engineering sucks. Another funky thing is asynchronous requests and responses, does it require tracking ID and does it really matter at all. Should it be random or sequential, etc. Or is it just utterly meaningless.
  • Cloud Spanner @ Google Cloud Platform - JDBC, ok. I haven't needed JDBC so far, but I assume it's not a big deal. Pretty similar to other connectors. I did read several papers about databases and so far it seems very likely that Cloud Spanner (must have) serious rate limits, due to latency and strong consistency. That's just the way it has to be. Same restrictions apply even to NoSQL databases, if strong consistency is required. Without breaking CAP, it's impossible to make distributed databases fast with strong consistency. Of course these limitations can be alleviated on software level, using different fall back logic. But not on database level. It's good idea to read the full - white paper - it's only 7 pages long. -. The white paper just confirmed what I thought. Very serious rate limits. Which of course need to be considered when developing software using the database. kw: TrueTime, Google, Spanner, Cloud, CAP, geographically distributed, Chubby.
  • Had a very long discussion with one team about options. Should we use existing tools, and suffer from potential limitations. Or build something new, and suffer from bad implementation and constant problems. - It's not easy trade-off. - It's nice to be in control, but it can be also very bad thing, depending from aspect. - As said earlier, there's no answer to this question. It needs to be evaluated case by case. Even then it's large possibility that the chosen option isn't right one.
  • Read an article about Fuchsia / Mojo and merging of Android & Chrome OS. Which AFAIK does perfect sense.
  • Noticed with one particular web app that curl -I and curl -i does actually make different requests. - It doesn't just show headers, it makes HEAD request. When -i includes headers in response. For many of my apps, that doesn't really make difference, because head request gets same reply as get, but for some apps it does make difference, and can mislead you.
  • Once again, I don't want to discuss matters, and generic blah blah. I prefer clear proposals, with facts. Not some ambiguous "We're so awesome, our blah blah is better than blah." - Very simple measurable / fact based arguments, plz. I really don't know how silly some customers clearly are, because it seems that large part of vendor marketing is totally underestimating their customers.
  • Registered a account for LoRaWAN / LPWAN Loriot.io service and checked it out. Looks good. Sigfox coverage isn't yet as good in Finland as I thought. It seems that several providers are betting on LoRaWAN / LPWAN in Finland. Sigfox provides longer range and cheaper hardware, but it's closed system.