Hey I'm Cosmo, I wrote this post and lead eng @ Metronome. Happy to answer any questions here. It was a long week for us but I'm glad we got the option to learn and share this relatively novel failure mode.
Well to be fair a lot of the boarding time is tied up in people struggling to get luggage into overhead bins, and then eventually fully running out of space and having to swim upstream after they put their bag behind them.
The only photo with backwards facing seats in the article is labeled
“Check out this wild train interior on the Chinese version. It has a centrally located table and rear-facing front seats. Truly a "living room" layout.”
Which is describing a completely different vehicle.
> Lizardman’s Constant is an idea proposed by Scott Alexander that each poll always has about 4% weird answers. In one poll, 4% of Americans said that reptilian people do control our world and, in another 4% answered ‘Yes’ to the question ‘Have you ever been decapitated?’
Great article and excited to see another solution tackling the complex problem of billing. I’m an founding engineer at https://metronome.com (building usage-based billing infrastructure) and definitely echo the sentiments shared here — building a billing system that can scale is no small feat and anyone who previously built billing in-house can attest to just how painful that is.
I’ve not used this tool before (am excited to in the future though because..) having done a lot of API diffing with text diff tools in the past, they break down very quickly on things like: JSON key order can be random, causing false positives. Some headers will always be different (any sort of timestamp based header for example) while others must not be different. URL query params can be in any order, etc.
I think if you do api diffing at any reasonably large scale you’ll find yourself immediately building tools to help cut the signal from the noise, and this is an exciting step in that direction.
Matt Levine (as usual) has some good explanations for the value (or lack thereof) of stock splits, as well as some historical context, as seen via the lens of the recent Apple split: https://www.bloomberg.com/opinion/articles/2020-07-31/apple-... (Bloomberg has a pretty aggressive paywall, but usually a new incognito tab will bypass it).
"A company should be a thing, and people should be able to own a portion of its equity, and the portion that each person owned would be expressed as an arbitrarily precise percentage of the total...The “stock price” would be what we now call the “market cap”: The market would place a value of $X on the company as a whole, and if I wanted to buy another 0.01429% I would pay 0.01429% of $X....
The traditional, 19th-century answer to how many shares a company should have was that stocks should have a normal price, they should cost like $40 to $100...This was so standard that, when Charles Dow created a stock index in 1884, he just averaged the dollar stock prices of a bunch of stocks...because the stocks had normal prices.
There is an argument that high-priced stocks reduce liquidity because traders have less incentive to post quotes. It is good for a stock to trade at a bid/ask spread of a couple of “ticks,” the minimum price increment for trading. If a stock is worth $50 and trades at a bid/ask spread of $49.99/$50.01, a trader who posts a bid to buy at $49.99 will be able to buy from anyone who wants to sell immediately. If it’s worth $500 and trades at $499.90/$500.10, a trader who posts a bid to buy at $499.90 might lose out to a trader who bids $499.91. You can’t reliably earn a “normal” spread by trading the stock, so your incentive to provide liquidity is lower. Nasdaq published a paper arguing this point
At the time of Apple’s last split, in 2014, one popular explanation was that Apple was trying to get into the Dow Jones Industrial Average, which is still price-weighted and so still has an old-fashioned fondness for normal-priced stocks, but that worked and now it’s in the Dow so that’s no reason to split again"
Can't speak to the claims in this comment around type 2 diabetes, but worth noting this article and pill is specifically for type 1 diabetes, which is in no way related to weight or metabolism, but rather an autoimmune disease.
As a type 1 diabetic I can say (personally) the difficulties of managing my diabetes do not stem from taking insulin, that's a solved problem. Rather the difficulties come from taking the right amount at the right time. Insulin is slow acting (2-3 hours for it to fully take effect) so you're always trying to predict/aim for a moving target, and one that can shift rapidly depending on eating/exercise. If I could just set it and forget it, or even just have the ability to be 50% less accurate when calculating/planning dosage and activities, it would be a paradigm shift.
If you have an insulin pump (best if it's an older one, since newer ones are harder to hack) you should look into OpenAPS (open artificial pancreas system) https://openaps.org/. People have code/schematics available to build a closed loop system between CGM<>insulin pump which automatically adjusts the dosage based on glucose levels and keeps you in range better than even the best attempts at manual dosages. Seems like you've already done half the work, which is connecting the CGM to a device you can run custom code on.
As a type 1 diabetic I'm super excited to see apple working in this space, even if they're focusing it on type 2 to start (a logical move, considering there is something like 30x more type 2 diabetics in the US). I think making it easier to track glucose levels in real time is the number one thing that can be done to improve quality of life for both types of diabetics.
The "CGM" (continuous glucose monitor) has really come into it's own over the last 10 or so years, and I would encourage all diabetics (but especially type 1) to use one. Currently the only 2 real options on the market are:
- http://www.dexcom.com/ - Connects directly to your phone using bluetooth and will send glucose warnings etc as notifications.
Both these options are expensive (even with insurance for many), invasive, and not really tailored towards "casual" glucose monitoring. I think if Apple enters the space with a non-invasive tool it'll be a huge boon for causal glucose monitoring. I also think it could be a more accessible option for people who are interested using a CGM to treat their diabetes but can't/won't use one of the existing options due to cost or inconvenience.
This seems like a win win and I'm excited to see where it goes.
In my experience the swagger code generators are not very good (at least for go/node).
- Go - This thread on the PR adding go client generation is a good introduction - https://github.com/swagger-api/swagger-codegen/pull/1747, basically the generator currently only supports very simplistic datatypes and will just generate invalid code if you start to use any complex datatypes. The main user in that thread (casualjim) actually maintains (https://github.com/go-swagger/go-swagger) which is a much more robust implementation, but still has some rough edges such as:
- The generated servers don't give a nice (or even strongly typed) interface to implement. See an example of a handler here - https://github.com/go-swagger/go-swagger/blob/master/example.... First pass of Goa at least as a less leaky and more strongly typed implementation.
- All the actual codegen is done using gotemplates. As someone who has tried to make some small changes these are fairly hard to parse/understand (example: https://github.com/go-swagger/go-swagger/blob/master/generat...)
Overall the default swagger codegen is very simplistic and the alternative go-swagger code is better but has a few rough edges that are difficult to fix.
- Node - I haven't played around much with the node server generator, but the clients are very thing wrappers around the API without a ton of abstraction/client side safety/validation. Node JS obviously doesn't have types, but a good client library could still do runtime typechecking to make sure if I do createBook("hello") instead of createBook(new Book({})) the former would fail (instead of just sending it off to the server to deal with).
I recognize this may be a high bar for microservice codegen, but often swagger is compared to the likes of thrift, which has _very good_ codegen, and so these leaky abstractions and edgecases stick out in comparison. I can't yet speak to how Goa compares but the go server codegen seems better in the first pass.
Clever is simply replacing the existing processor of schools having to coerce CSVs and other horrible formats and them them off (over email sometimes) every time data changes.
Schools may or may not buys apps that help determine teacher performance. Clever may or may not be used for moving the data. However regardless teacher unions not be effected differently with Clever as opposed to without.
Schools have been buying applications since long before Clever. These are usually (but not always) gaint contracts across multiple schools or districts. after they are signed it can take months or sometimes full schoolyears to get the app provisioned and set up. This has to happen every time data changes as well. With clever it takes minutes.
