It only works with passengers on your same flight. In practice, it's good for kids in the same family or school group who are sitting across the aisle from each other. I've used it for some of their other games
I know I'm getting old when I read comments like this. It wouldn't have occurred to me in a million years that it might pair me with passengers on another flight. I'm conditioned by having first experienced this feature probably 30 years or so ago when pairing to passengers on other flights would have been science fiction.
That's how the system was originally designed, before in flight WiFi was common. If they're gonna hook it up to the broader internet and allow playing games cross-flight, they might as well just hook it up to an existing service like chess.com and have a significantly larger user base imo
> where you can't just download a leap-second file from someone else's site thanks to the SOP
WDYM by this? Why does the SOP prevent a website from hosting a leap seconds file? All they need to do is set Access-Control-Allow-Origin to allow websites to access it. Or provide it as a JS file—in which case no headers are necessary at all. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.
> Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy
Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file. Adding such a data file and keeping it up to date would probably be a pretty non-trivial task for new browser developers—just for something the browser will never end up using itself. It's not like the ICU/CLDR files where browsers are going to need them anyway for rendering their own user-interface components.
> All they need to do is set Access-Control-Allow-Origin to allow websites to access it. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.
They can, but the major providers (read: the ones I would trust to update it) don't. The IERS doesn't [0], the USNO doesn't [1], IANA doesn't [2], and NIST uses FTP [3]. Keep in mind that these files are constantly being downloaded by various clients for NTP and whatnot, it's not like these providers want to restrict public access, they just don't bother to set the header that would allow JS requests.
> Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file.
From ECMA-262:
> It is required for time zone aware implementations (and recommended for all others) to use the time zone information of the IANA Time Zone Database https://www.iana.org/time-zones/.
Any browser that ships with a copy of tzdb, or knows where to find a copy from the OS, should have access to its leapseconds file. Unless you mean that all of them go solely through ICU and its data files? Which I suppose could be an obstacle unless ICU were to start exposing them.
"the group of people behind AssemblyScript" is just one person, as far as I can tell from this doc / the relevant Github threads. I wouldn't necessary call it infighting per se, at least not from this interaction.
No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either.
You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".
Really interesting post, but this part from the beginning stuck out to me:
Ruby Gems are tar files, and one of the files in the tar file is a YAML representation of the GemSpec. This YAML file declares all dependencies for the Gem, so RubyGems can know, without evaling anything, what dependencies it needs to install before it can install any particular Gem. Additionally, RubyGems.org provides an API for asking about dependency information, which is actually the normal way of getting dependency info (again, no eval required).
It would be interesting to compare and contrast the parsing speed for a large representative set of Python dependencies compared to a large representative set of Ruby dependencies. YAML is famously not the most efficient format to parse. We might have been better than `pip`, but I would be surprised if there isn't any room left on the table to parse dependency information in a more efficient format (JSON, protobufs, whatever).
That said, the points at the end about not needing to parse gemspecs to install "most" dependencies would make this pretty moot (if the information is already returned from the gemserver)
Although Yaml is a dreadful thing, given the context and the size of a normal gemspec I would be very surprised if it showed up in any significant capacity when psych should be in the low single digit MB/s throughput.
It mostly doesn't matter, because these metadata files are pulled into their respective package managers. When you publish to RubyGems the file is read into their database and made available to their API, just like when you publish a Python file the pyproject.toml is parse into the PyPI database and made available.
This is a major reason why UV is faster than older python package managers, as they were able to take advantage of the change in the PyPI registry that enabled this. Now these package managers can run their dependency calculations without needing to download the entire package, decompress the package files, and then parse them.
Ah, I had misremembered the article as saying that the API was sufficient for "most" tasks, all it actually says is that it's the "normal" way of getting the dependency info. I was wondering if there was some less common operations (e.g. upgrading?) that needed more info beyond what was in the API.
For a "YAML" lockfile, you could probably write a much simpler and much more performant parser that throws out much of what makes YAML complicated, in particular, anchors, data type tags, all the ways of doing multi-line strings, all the weird unexpected type conversions (like yes/no converting to a boolean)... If the lockfile is never meant to be edited by human hands, only reviewed by human eyes, you can build a much simpler parser for something like:
This is about the gemspec (e.g. the project or package file, like pyproject.toml or package.json) for each dependency. The lock file is in a custom plain text format to make it easy for both humans and bundler to understand
In some companies, this type of information is often very important and very easily available to everyone at all levels of the business to help prioritize and understand customer value. I would not consider it "sensitive" in the same way that e.g. PII would be.
Good to know! At previous jobs, that information wasn't available to me (and it didn't matter because the customer bases were small enough that every customer was top priority), so I assumed it was considered more sensitive than it perhaps is.
> Fediverse itself doesnt know how to handle direct messages
What do you mean by this? Direct messages are not end-to-end encrypted, I don't know what you mean by "doesn't know how to handle". Almost every platform with direct messages doesn't have E2E today, that's the same as email, twitter, Discord... basically every other messaging platform on the web besides Signal and Matrix, for better or worse.
Well yeah to be honest, I kinda hope that one day we can get something like matrix on top of fediverse and so yeah you are right almost every platform doesnt have direct message e2ee but I was hoping that someday someone can build it for fediverse.
A lot of work can be wrapped inside a database transaction, but never everything. You're always going to want to interact with external APIs eventually.
Yes of course. External calls still need to be idempotent. But the point is some frameworks allow you to make some, or even most, of your work safe for durable execution by default.
reply