LavaRand, OVH, Braess, Demand, Robots, WiFi, Chrome, JSON

  • Cloudflare: LavaRand - The Nitty_Gritty Technical Details. Do you call that technical detail? I think it's still very generic and abstract and doesn't require implementation / developer level skills at all. - Afaik, truth is that even if you read some specification and think you got it. You don't really know enough about it, before you've written fully working implementation by yourself. Then you'll have to deal all the stuff which was too easy to ignore before writing the actually working implementation.
  • I'm again laughing. There's nothing hard about SSL certs, nor SMTP, nor DNS, and many other basic things. But I just wonder how people keep messing those things over and over again. I don't know if I should laugh or cry. Maybe just a bit both. - I guess same could be said about my problems with cx_freeze. It was obvious and trivial, when you just know exactly what to do.
  • Fun day, OVH RBX and SBG outages messed up my daily plan pretty much. It's always good to run independent monitoring and alerts. I got alerted about the issue before rest of Hacker News crowd notice the issue. - Actually this is exactly the reason why key systems are duplicated and designed to work locally without Internet connectivity at all. I think that even the fail was massive fail, it was also nice to notice that all systems automatically and fully recovered from the outage without local intervention from us. Phew, luckily there were not corrupted file systems or databases. That's major relief. Because when something serious and bad like that happens, you've gotta expect the worst outcome. Restoring everything from backups would have taken quite a while. Think it as DR situation where there's "total cloud loss."
  • Lot's of discussion about transactionality system integration. There's no single way to guarantee right outcome. It needs to be considered by case by case. If the data replaces existing data, if the data is delta data. If the receiver side does additional duplicate checking. If there is, or isn't unique identifiers for transactions etc. Of course having the unique identifiers makes things much easier. Data can be re-sent, until each specific unit of it has been separately confirmed to be processed.
  • Braess's paradox - Nice examples they got. Often when something is implemented very well. It's preferable to use it, and it might get used for things initially not even designed for. Adding lots of extra load and issues.
  • Induced demand - This is also quite normal. Because when something becomes seemingly abundant, it's easy to get many more new uses for it. because now we got more than enough.
  • You Will Lose Your Job to a Robot - Only future will tell. Nobody knows for now, that's quite sure. True Artificial Intelligence, Artificial General Intelligence (AGI).
  • After OVH SBG power outage studied some status-page solutions like Cachet. But personally I don't see that necessary. It would be better to inform users using the 'main stream channels'. Because only very small percentage of users would be looking for something like status page. And we do already of course have a status or system monitoring dashboard page, but it's reserved for internal use only. It was very helpful during the incident providing us clear visibility what is working and what isn't.
  • Quite nice WiFi test - Results are as quite much what's expected. Which means that there's large variations and no simple answers. Except that if you're looking for good network, WiFi isn't a good solution at all.
  • Way cool. Finally Chrome on Android supports additional search engines like DuckDuckGo . - Thanks! Chrome & DuckDuckGo.
  • Using simple JSON messages for all API's make boringly simple interfaces. I just removed tons of good old multipart/form-data boundary MIME stuff from one project.

2019-03-17