sufianrhazi

This is a great upcoming feature, I wrote some practical advice (a realistic example, how to use it with TypeScript/vite/eslint/neovim/etc…) about it a few months ago here: https://abstract.properties/explicit-resource-management-is-...

It strikes me that a straightforward solution to this problem would be to have Google Translate dispatch a new CustomEvent with a particular "type" and a reference to the new element in the detail field. So React and other frameworks could listen to this event and instead of dealing with Text node X, they could instead refer to the translated element Y.

Nah, I advocated for hiring someone out of a bootcamp who was previously a dancer. She ended up being a great addition to the team, was an excellent communicator, and was a significantly more clever and harder worker than others I’ve worked with who came from elite schools.

I sometimes think this attitude that you can’t teach good programming practices quickly on the job comes from folks who have never tried. We literally have code review practices for this reason.

Oh you're right, nice catch!

Nice! Though there are max 32 pieces on a board, not 16; so this scheme is 64 + 32 * 4 = 192 bits, or 24 bytes.

The bit to indicate whose turn it is isn't accounted for here. But it probably could probably represented by the binary negation of the bitboard -- if there are 32 or fewer bits set, then it is white's turn; if there are 33 or more bits set, then it is black's turn and you can negate the bitboard prior to determining which squares are occupied.

Taking things further, it probably can be compressed even more with (much) more complex logic, as the castling available bit must only be present on the corner positions, and the pawn en-passant capabilities are only available on the middle rows, so those bits are meaningless in other positions.

I hope people don't study this. The answer to this question doesn't matter.

The whole point of this question is to (1) gauge the clarity of the candidate's communication when explaining complex systems and (2) have them get to a place where they simply doesn't know and must start making assumptions of how things work and weigh the various tradeoffs. That's where things get interesting.

Unfortunately, this approach will not work for clients using Internet Explorer (save for IE 10). WebSockets and EventStreams are fairly new, and not supported across all browsers (both for mobile and non-mobile).

This is why socket.io and its contemporaries have several layers of fallbacks, even going back to infinite iframe/JSONP polling.