mc10

Would love it if the scrollbar was draggable on iOS! I thought it was broken until I realized you can click on a spot to scroll to.

The instructions state the following:

> Imagine you begin a journey in Seattle WA, facing exactly due east. Then start traveling forward, in a straight line along the Earth’s surface.

Where does it say to "travel exactly due East"?

Perhaps the HN headline doesn't match the article, but the instructions say:

> Imagine you begin a journey in Seattle WA, facing exactly due east. Then start traveling forward, in a straight line along the Earth’s surface.

where there isn't any wording saying "go east in a straight line".

I don’t think this is a fair conclusion; web development is harder than desktop GUI development for various reasons.

For one, clients (mobile, desktop) are drastically different with all sorts of downstream implications:

- Differing screen size requiring responsive design

- Internet speeds magnitudes different

- Intermittent internet

- Uneven feature support due to different versions of browsers

- Everything needs to be JS at the end of the day

Desktop apps generally don’t have to worry about any of these issues.

Also, desktop GUI frameworks are typically either fragmented (one per OS) or don’t look OS-native.

HSTS is intended for browsers. For API clients the correct behavior (following curl's lead) is probably to never follow/make any redirects by default.

Aren't these two forms isomorphic:

    type MyUnion = { type: "foo"; foo: string } | { type: "bar"; bar: string };

vs

    type MyUnion = Foo of { foo: string } | Bar of { bar: string };

You still need some runtime encoding of which branch of the union your data is; otherwise, your code could not pick a branch at runtime.

There's a slight overhead to the TypeScript version (which uses strings instead of an int to represent the branch) but it allows discriminated unions to work without having to introduce them as a new data type into JavaScript. And if you really wanted to, you could use a literal int as the `type` field instead.

The AgeMin/AgeMax example seems more of a deficiency due to a lack of named function parameters; it would be equally clear if it had a type signature (using OCaml as an example) of

    val is_admissible : min_age:int -> max_age:int -> bool

Both Katran[1] by Facebook and Unimog[2] by Cloudflare are L4 load balancers written using XDP. It's factually incorrect to claim that XDP is useless on servers as many companies intentionally choose to design their systems around commodity hardware.

  [1]: https://engineering.fb.com/2018/05/22/open-source/open-sourcing-katran-a-scalable-network-load-balancer/
  [2]: https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer

In this section:

> I think in the context of the merge commit ours/theirs discussion earlier, HEAD^ is “ours” and HEAD^^ is “theirs”.

Should HEAD^^ be HEAD^2 instead?

I wish there was some way to evolve the DMARC spec such that only DKIM and not SPF is used for validation. Sadly things like Google Calendar invites still fail DKIM…

Yeah I guess it depends on how sophisticated the "hiddenness" of the field is. Instead of straight up using the hidden property (which is easier for a bot to detect), you could try other things, like moving the input field offscreen and using overflow: hidden, or styling it such that it's the same color as the background and is unfillable. Now though you'll need to worrying about tabbing through fields (change tabindex to -1) and screen readers that might pick up the fields.