Roughly the angular reolution of a telescope is 1.22*wavelength/diameter. See https://en.wikipedia.org/wiki/Angular_resolution. Hubble uses visual light (0.5 um wavelength) while JWST uses IR (5 um wavelength) and beyond. So the wavelength for JWST is 10x larger than Hibble, but the diameter is only ~2.7X (Hubble 2.4m vs JWST 6.5m dia). So JWST resolution is 1.8x worse than Hubble.
Is it really that important that the time to get to 200 should be small? I understand that it may be frustrating to get started, but assuming I am stuck to this API for a long time, I am lot more worried about stability, quality, performance and availability of the system than time to onboard.
A case where it can matter is when there is no clear commitment yet to use that API.
For instance if there is 2 or 3 alternative services, and you want to explore one of them to have a better idea of the trade-offs. Setting up an account and making “real” requests will be your benchmark.
Actually, even for a service with a decent chance to commit to it, there will still be an exploration phase to get an estimate for the implementation cost. Depending on how much the devs struggle to just try the API, the project could get more or less reprioritized for lower hanging fruits.
I'm with you on those other aspects being very important, but I'm not sure they are more important in general. After all, relatively few APIs are truly essential, offering access to some exclusive facility that users of that API couldn't also find somewhere else and/or implement themselves. For everything else, unless you can hold enough of a potential user's initial interest for them to carry on trying things out, the other stuff doesn't matter.
Basically if you want to replicate data across multiple nodes, all of them need to agree on the sequence of data updates. For example if I did [x=6, x=7], then the outcome of those ops is very different if I did it in the opposite order [x=7, x=6]. Easiest way to do this sequencing is to have a unique leader who will impose the unique order. Strict sequencing is not really serializability, but linearizability. For example, Cassandra doesn't by default have the concept of a leader and hence can't provide linearizability. Of course, there is a problem on how you decide who is the leader and what happens if two nodes think they are the leader at the same time. That's where the genius of Multi-Paxos/Raft comes in. You can read more about sequencing here
Zookeeper is the standard one which has been around the oldest. Zookeeper is not based on raft, but it has similar semantics as etcd. So if you don't care about the impl, ZK may be good as well.
Oracle cloud is quite a thing. It's in 4th place behind AWS, Azure and GCP and has significant presence. For example zoom is a big customer:https://www.lastweekinaws.com/blog/why-zoom-chose-oracle-clo.... I assume under the new tiktok deal, tiktok might run on the Oracle cloud.
The author's advice is country dependent. My assumption is that he is writing from the perspective of buying in India.
1) In India, rents are very low compared to mortgage payments.
2) Home value appreciation is low given the rate of inflation.
3) financial instruments like home equity line of credit are not available.
So yes, it probably is not a good decision to buy a house in a big city in India. Elsewhere? Do your own calculation.
There are some painpoints that are being addressed:
1) timestamp : I have had issues with a round-tripping timestamp representation quite a bit
2) decimal : currency is denoted in decimal rather than float and shows the Amazon retail heritage. This is very useful.
3) symbols : I've had cases where symbol table/dictionary would have made big difference in serialized size
Re time stamp and decimal, probably no surprise that it is used heavily by QLDB, where having a very clear time for a change is important and a common use case is logging debits and credits as a financial ledger.
I don't know. It was common knowledge for me in college (as in it was taught as part of the curriculum) but as far as I can tell in the intervening 30+ years that knowledge seems to have been lost and relearned many times over.
cash values should be represented in fixed precision to maintain the integrity of the transaction and your book, while the prices for securities represent something different.
In securities transactions, the quantity and quote are critical. You aren’t buying securities from Plaid, right?
If you try to liquidate or resize based on the Plaid quote, your brokerage or counterparty is going to provide a totally different quote, and one from a system engineered to provide quotes aligned exactly to the market standards.
