templaedhel

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.

They made a coffeescript for go

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.

This feels like a great introduction to the “Lizardman’s constant” (https://slatestarcodex.com/2013/04/12/noisy-poll-results-and...)

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.

Read the docs - React Native in general has good docs and the native module guides are especially well done in my opinion.

IOS - https://facebook.github.io/react-native/docs/native-modules-...

Android - https://facebook.github.io/react-native/docs/native-modules-...

Some cities (Paris off the top of my head) have "UberGreen" which is exactly this - You can elect to only take rides from hybrid or electric vehicles.

https://newsroom.uber.com/portugal/ubergreenen/

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.

Medtronic just came out with their first closed loop system (https://www.medtronicdiabetes.com/products/minimed-670g-insu...), but OpenAPS has been around for years, and not sure how Medtronic will go about getting the 670 approved in Germany.

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.

- https://www.medtronicdiabetes.com/products/enlite-sensor - Designed to work with Medtronic (who is a market leader) insulin pumps.

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.

I think the most interesting part of this for me is the fact it relies on the the SpeechRecognition api to return swear words redacted with asterisks.

See for example George Carlin's "Seven dirty words" as returned by the SpeechRecognition demo https://cl.ly/3A1F0r3U1H1D/Screen%20Shot%202016-09-03%20at%2...

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.

I wonder if anything interesting comes up if you correlate this data with the license plate camera data that Oakland released (https://news.ycombinator.com/item?id=10642139).

For what it's worth this book (which is excellent) is also published as a free ebook under a Creative Commons license (http://www.antipope.org/charlie/blog-static/fiction/accelera...).

The author is also a relatively prolific HN poster (https://news.ycombinator.com/user?id=cstross).

can anyone explain to me why I am wrong

Because you appear to misunderstand Clever.

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.

While this is technically true, unlike our customers, our main job is the intergration. This gives us the benefit of doing some things our customers don't want to dedicate time or money to do. It also gives us a wider view of the systems that are out there (one benefit of having 1/10 USA schools using your product), and allows us to build some really efficient pipelines.

For the vast majority of schools their data is syncing with their apps within a few minutes of them signing up. This is something that wouldn't be possible if we had to white glove every new school.

Last Spring, Clever was pitching me for a job (which full disclosure I accepted). I was dubious, edtech startups don't have the best track record, and they had barely gotten started (just got into YC). However after hearing the problem they set out to solve, and seeing how they planned to do it, I was convinced. Clever bypasses most of the biggest problems edtech startups run into, specifically selling to schools. Schools don't like to pay for things, and when they do it's shrouded in bureaucracy. Clever is free for schools, and instead sells to developers, easing their pain and in turn making it easier for them to sell and get setup with schools. From the Clever point of view a new schools takes 5 minutes to onboard.

This is one of the major points that allowed us to see this level of growth over the past year, and I'm excited to see where Clever takes education going forward.

We're also actively hiring so head over to our jobs page if being on the forefront of a revolution in the edtech space sounds interesting to you. https://getclever.com/about/jobs

Before making sweeping statements about a disease you obviously don't understand please read up on the difference between type 1 and 2 diabetes, and what the causes and treatments are for both.

TL:DR - This pump would be used for type 1 diabetics. This type means your body does not produce insulin, so the treatment is to artificially inject it (via this device for example). It's not caused nor limiting to diet. Being unhealthy/overweight doesn't increase your chances of getting type 1. It's a genetic, juvinile onset disease.

Type II is the type you're most likely thinking of. The body becomes less sensitive to insulin, so you need to consume less carbs and generally eat healthier. This pump would not be used by type II diabetics.

This is an interesting move for Square, at least to me. When I think about the future of square I saw them pushing out against more established POS systems (with more deals like the Starbucks one).

This is a slightly different route, the main competitors seem to be etsy.

While in reality they're trying to landgrab as much payment related market as possible, and the two approaches are slightly related, in my mind I'm interested to see what they become known for.

When mapbox first launched tilemill was when I first discovered them. I read about them on here, and went to check it out.

At the time I didn't really understand the value proposition. It was google maps without any of the useful API features like geocoding and routing. Plus they were using openstreetmap which at the time was lagging noticeably behind google data in my area [1].

Tilemill seemed nice, css to style maps. But google had a nice style wizard [2] that changed the maps on the clientside, no need to upload a custom tileset, which is what tilemill seemed to do.

To be honest I generally forgot about them. But then google started charging more for their maps, and I remembered them as an alternative. I still missed the flexibly google had for their map styles though.

However in the past week I've come to see them in a whole new light, in part due to this post, but also due to their vector map post [3] causing me to dig back in and play around. I now truly believe these guys are one of the coolest "underdog" startups I've encountered. They've been chugging along and have created some awesome advancements, or at least competitors in the online map space. I hope to continue seeing awesome work like this, those map images are gorgeous.

My only request is that they give a little more detail into how to create custom styled maps like they show in the vector blog post I linked to. The process of using their street maps with custom styles is a little hazy to me right now, although maybe I'm missing something obvious.

[1] It still does, but now only with minute details like service roads on the local university campus.

[2] http://gmaps-samples-v3.googlecode.com/svn/trunk/styledmaps/...

[3] http://mapbox.com/blog/vector-tiles/

Your critique seems to be based off comparing git to mercurial and declaring that git is designed better. I don't think you're going to see a ton of disagreement with that in this community. You make good points too, with context a lot of those commands make more sense.

However well designed software shouldn't need the context. Well designed software is intuitive. We shouldn't need to know the intricacies in the git data model to able to understand the major commands and tools. As we begin to do more complex operations then more knowledge can be a prerequisite.

The fact that these commands all made sense with a detailed explanation is only a symptom of the problem, not an excuse.

I think that is your iPad not supporting webGL.

Just want to be clear, I am not the developer behind this. I found this and was looking for discussion on HN about it because it was quite impressive. I wasn't able to find it by searching so I submitted it in hopes that it would take me to the past article (that is how the url duplicate detection code used to work), but instead it created a new story.

I actually submitted it trying to find a discussion, since I was having trouble searching for it. When it created a new story instead of linking to the past discussion I assumed it was new. Sorry about that!

I feel like confirmation bias is in play when you read about successful people who have dropped out of school, succeed, and then blogged about it. You have to keep in mind the hordes of people who have followeded a similar path only to archive not enough to blog about.

Self education may appeal to many of us here, but it applies to less than it appeals to.