bifel

Wouldn't putting "everyone in a numbered sequence unknown to them" require a random number, which we don't have?

The method (at least here in my country) is really simple (and not really a secret): The voicemail can be reached from a special number. This number is easy to derive from the actual phone number (usually inserting one or two digits, depending on the provider). When the "owner" calls the mailbox, he gets the "admin" functionality. Anyone else calling it can only add messages. The rest is just simple call forwarding. So all that is needed is finding out the number of the mail box.

Having done a lot of python recently, this looks great (and familiar).

But some things feel a little bit rushed:

- In the example "(o is int i || (o is string s && int.TryParse(s, out i))": When reading this statement as a human, o is obviously not an int when it comes down to the TryParse function. But if the 1st part was removed, the 2nd part wouldn't be valid either. I know this is technically how declarations work and I don't have an idea, if there is a better solution for this, but it feels weird.

- The new features of the case statement are nice but the old syntax with the mandatory break is probably worth getting rid of. Especially since all cases share a scope, adding/removing cases is prone to errors. I'd love to see a solution similar to "catch".

- The Deconstruct method is introduced as a "magic name". No interface, no override, nothing... Even the return type is "void". Why not use something like "public out Point(...)" to keep it similar in fashion to the constructor. Other options may be something with "this" (like indexing) or "operator".

Using distinct and windowing functions to avoid writing group-by clauses may work fine with Postgres but is a very ugly hack.

I think it's a shame that many database courses don't even mention advanced features like CTEs or Window functions.

It makes me cringe anytime I see a statement with complicated nested self joins to solve a problem that should not exist because most current database systems implemented the relevant standards years ago.

Is "changing the locks" (revoking the certificate) really so complicated that this "janitor-solution" is easier/cheaper/safer?

I don't get it. What's the point in keeping the key secret from cloudflare whilst providing a key server signing everything it is asked to sign? Isn't this like "Sorry I don't trust you enough to provide you a key to my apartment. But if you need something, just ask the janitor, he'll open the door any time you want"?

so does any eval'd code

Common Table expressions are part of the SQL:1999 standard. Most RDBMS can handle them.