Dynamic pricing, HSTS, Design, Cloudflare: [GeoKey, Warp, Workers]

  • Nice post about dynamic pricing of hotel rooms using data science. Python, NumPy, SciPy and Pandas. Yep, that's something which has been used in the industry for ages. It's not rocket science. I personally like dynamic pricing, it encourages people to use resources, when there are more resources to be used. It's total win-win solution.
  • Google's blog post about HSTS preload which can be also used for TLDs.
  • Design and decisions - I liked the discussion what API should look like. There are so many ways to implement something. Which approach is best and why, that's often a very complicated question. Yet those answers need to be usually answered, when ever designing new software and architecture for any project. Nested or sequential code? Where logic should like, should the logic be distributed to individual modules, or should there be central business logic module. Should you use something generic or everything with individual class. Should the data be validated, and if so, against what? Will the validation be a problem for easy extendability, etc. I personally believe that easy extendability is important. Some say that existing models should be strictly followed. Which only makes the extendability more kludgeish, like splitting fields with some separators or so. In one case, I was told, that it's absolutely impossible to add extra field. Oh well. My solution? My own database, which replicates some data, and adds the extra field, and then joins it on every occasion. Totally horrible, but that's what you get when you get stuck with rigid non-extendable data structures. In some cases, APIs have been so horrible, that it has also required parallel transport methods. Because the original data path, can't be extended or changed. Well, we build completely parallel path using different technology, which just transports the 'records' which are missing from the main message / data. Yuck! But it works. Unfortunately this is quite common with 'standard formats', data brokers, which validate the messages and all kind of older systems. - Well, no problem, I can hack around those limitations. (Anything, over anything, and in any format you wish) But I would highly prefer using the original path with only minor additions. In worst cases, this leads something to be implemented almost completely in parallel, over and over again.
  • Cloudflare's Geo Key Manager is pretty cool stuff. And how it works article for nerds. Enjoyed reading it too. Don't forget to take a look at the awesome Gatebot post.
  • Cloudflare's Warp "Hide Behind The Edge". Well, this seems to be solution to the discussions I've been having with IPv4 "supporters". In 'future', you don't need to waste resources like one IP address / user. This is great example, where RSAP-IP NAT can be used and you can host web-sites even if you're behind NAT. Nice, indeed. Yet. I personally prefer, everyone should have plenty of IPv6 addresses, but that's not the situation yet. This is very nice way to work-around IPv4 address depletion. Wanna host site, done. No need to worry about port forwarding, static IP-addresses, or even having IP-address to begin with. You can have any private address and be behind even nested NAT.
  • Cloudflare's Workers and Why. More absolutely amazing stuff from Cloudflare. But let's check it bit more thoroughly and what's good and what's bad and why. Service Worker model looks very nice. Not that different from the Python WSGI model, etc. It seems that everything is pretty much after all the same, with slight differences. Depending on limits, etc, this is very very powerful tool. It's just the (web) cloud distributed to the Edge. But I'm pretty sure they got tight resource / time limits what you can run on it. Before reading the article, I was assuming they would use Node.js. In total, pretty much awesomeness. Just add suitably cached localstorage and sky is the limit.