I feel the timeline is wrong re when dBase Inc took over. I remember working as a consultant on shipping new features for dBase back in 2000 or so.
I implemented reflection for the dBase language and was also part of trying to convert it to Visual C++ instead of using the Borland compiler. I was very green back then but it was interesting, my only time dealing with interpreters / compilers
We use BQ quite extensively there are a number of billing tuning options which are not that well documented.
1. for some it will make sense to move to pricing based on CPU time per query vs billing on scanned TB of data. This can be done through the commits in UI.
2. there is option to have storage billed on logical or physical bytes. If you have data with a lot of duplication (enums, customer ids etc) then physical billing can be a lot better option. Last I looked this was only available through CLI setting in dataset and you may need to ask Google to include you in their beta.
We lowered our billing with 30% for storage.
I try to keep an eye on GCP release notes to find things like the physical vs logical billing.
Completely unrelated but as HN works as an unofficial support channel.
This page https://www.cloudflare.com/ips/ seems to be missing a range of IPs which are in the 172.66.x.x range, our site appears under it but can't see it on the page
I think it won't give you much in Dev but can give your more in production. We have the following work flow
1. Use Docker images for our applications where we can run them locally by mounting in a config file pointing to local db or dev cluster db etc
2. We then use CI to build new docker images and push them to our registry
3. Using Kubernetes deployment yaml files we then deploy the new versions to the cluster with rolling upgrades.
This can be combined with auto scaling
For config we have a Kubernetes ConfigMap in the cluster which then gets mounted into the docker containers when they start.
My suggestions would be for you to check out Googles Hosted Kubernetes which removes a lot of the headache of getting up and running.
https://cloud.google.com/container-engine/
Actually my understanding is a bit different.
Flannel uses VxLan and acts as a overlay network (packet inside of packet) while Calico is a pure Layer 3 routing solution.
This means some performance gains but less protocol support vs VxLan. I think it would be quite interesting to test
We have been using calico Cni with kubernetes with quite some success.
It's a solution that assigns ips and then sets up bgp routing between your docker/kubernetes nodes. It makes it very easy to trace what's happening. Not as easy as a flat lan but still pretty easy.
Netstat -rn and you can see where the traffic is going or coming from. The added benefit is you can then bgp peer with other clusters and get routing across them
My experience in Singapore is that Google Maps trumps Apple Maps on finding points of interest. However with driving directions Apple is a lot easier to follow. Apple tends to alert at better points before turn and also give more precise information about the turn. Example would be the number of the exit from the express way.
So I've resorted to finding the address in Google and then using Apple for the directions.
I implemented reflection for the dBase language and was also part of trying to convert it to Visual C++ instead of using the Borland compiler. I was very green back then but it was interesting, my only time dealing with interpreters / compilers