e_y_

It would likely get voided as unconscionable if they just unilaterally demanded it, but it might hold up in specific circumstances (if the user is well-aware of the salary demand when they accepted the contract, and the user gets some proportionate value out of giving Apple a percentage of salary).

A lot of big manufacturers have had recalls (for things like laptop batteries, vehicle batteries, the infamous Hoverboards, etc) so I wonder what Anker's batting average is compared to others. It's clearly a hard problem and squeezing in the level of density that customers expect means potentially thinner safety margins.

It's not just a theory. It's well documented that Apple has a bunch of APIs and protocols (like AirPods proprietary low latency wireless instead of Bluetooth, NFC was not allowed until years after Apple Pay) that are not available to 3rd party developers. They will sometimes open things up after they've given their own products years of head start because apparently owning most of the ecosystem and having undying brand loyalty from their users isn't enough.

Actually for many years even to build regular Bluetooth devices that did anything besides audio, you needed to add a special chip (Made for iPhone chip) to your hardware to verify that it was an authorized Apple Accessory. Pebble had one, but any 3rd party apps that wanted to send data to the watch (like Uber app, sports apps, random indie apps) had to get allow listed to communicate with accessory devices like Pebble.

Ambulances are expensive enough that people are hesitant to call them, sometimes even in life threatening situations.

And if the person is unsure whether the situation is critical, they might try to "sleep it off" rather than driving or getting a ride, because ER is also kind of expensive and you could be stuck there all day.

If we're talking about public tracking: package theft

And Waymo doesn't currently operate on highways for passenger service (I think they have authorization to, but they're only testing on highways right now).

They should be able to get to SFO from Millbrae Ave and San Bruno Ave without getting on the highway proper, although it'll likely be a lot slower unless you're getting a ride from nearby. While SJC can serve downtown SJ and Santa Clara without getting on a highway.

Most likely both agreements had been in negotiations for a while and not something they just pulled together last week in response to SJC, although it's possibly they could have used it as leverage (hey we've talking to SJC ...)

Most cities don't have the density and wealth of Manhattan. How do we solve the last mile problem for everyone else?

Taxi services can potentially complement public service by filling in the gaps: last-mile connections (home to train station) and backup service late at night when transit runs less frequently or not at all.

There's a risk that robotaxis could become too cheap and people use them for point-to-point transportation because it's faster. This could be mitigated through taxes on robotaxis (with incentives to connect people to transit) and/or car usage in general, or maybe using robo-buses to provide a middle ground between personal convenience and system efficiency.

Could also be a big challenge if you have dozens or hundreds of autonomous cars in the area that need manual intervention to get them out (plus the people who get stuck there)

This seems unlikely. People are creating libraries and they're getting a lot of downloads because they're genuinely useful. It's a lot of work to write and maintain a library just for resume street cred.

I think the ecosystem has more of the opposite problem: engineers create libraries to scratch a particular itch, because they needed to solve a problem for their own project, or maybe it seemed like an interesting solution that they wanted to share with the world. If the person was working for a company, they may even be paid to maintain it for a while.

A bunch of other projects start depending on it, but the original creator/maintainer has moved on. They might not even be using the library for their own projects any more, nor paid to work on it. Now they're stuck maintaining it out of a feeling of obligation, or maybe it's a passion, but at a certain point it becomes unsustainable and the project becomes unmaintained or under-maintained (huge backlog of tickets). Maybe they find new blood to help out, maybe they don't.

To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.

For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.

There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.

There's quite a few formats that are self-describing already, so having a format that can skip the type and key tagging for that extra little bit of compactness and decoding efficiency is a unique selling point.

There's also nothing stopping you from serializing unstructured data using an array of key/value structs, with a union for the value to allow for different value types (int/float/string/object/etc), although it probably wouldn't be as efficient as something like CBOR for that purpose. It could make sense if most of the data is well-defined but you want to add additional properties/metadata.

Many languages take unstructured data like JSON and parse them into a strongly-typed class (throwing validation errors if it doesn't map correctly) anyways, so having a predefined schema is not entirely a bad thing. It does make you think a bit harder about backwards-compatibility and versioning. It also probably works better when you own the code for both the sender and receiver, rather than for a format that anyone can use.

Finally, maybe not a practical thing and something that I've never seen used in practice: in theory you could send a copy of the schema definition as a preamble to the data. If you're sending 10000 records and they all have the same fields in the same order, why waste bits/bytes tagging the key name and type for every record, when you could send a header describing the struct layout. Or if it's a large schema, you could request it from the server on demand, using an id/version/hash to check if you already have it.

In practice though, 1) you probably need to map the unknown/foreign schema into your own objects anyways, and 2) most people would just zlib compress the stream to get rid of repeated key names and call it a day. But the optimizer in me says why burn all those CPU cycles decompressing and decoding the same field names over and over. CBOR could have easily added optional support for a dictionary of key strings to the header, for applications where the keys are known ahead of time, for example. (My guess is that they didn't because it would be harder for extremely-resource-constrained microcontrollers to implement).

I never went to parties in high school, but based on my experience going to parties in college and as an adult, I imagine your individual experience at the parties would be very different depending on your social groups, social skills, and so on.

Although even as a non-participant, witnessing a party first-hand would be more informative than the filtered version you get from Hollywood.