I'd use different types for those. Like Java's String vs. CharSequence.

It happens often when "error" field is not a bool, but a string, aka error_message. Could be empty string, or _null_, or even _undefined_ if we're in JS.

Then the obvious question why do we need _succeeded_ at all, if we can always check for _error_. Sometimes it can be useful, when the server doesn't know itself if the operation is succeeded (e.g. an IO/database operation timed out), so it might be succeeded, but should also show an error message to user.

Another possibility if the succeeded is not a bool, but, say, "succeeded_at" timestamp. In general, I noticed that almost always any boolean value in database can be replaced with a timestamp or an error code.

As someone said during COVID supply chain disruptions: when a system is very optimal it becomes fragile.

So probably they need to add more parallel tracks, unused most of the time.

The money for that is corrupted away as soon as provided by the state. If there is constructions going on, you won't be taking any regional train any time soon around here.

Google API libraries mark every class as "final" so it's not trivial to mock-extend it for tests. But third-party IO is exactly the thing you'd want to mock.

Probably because they zealously followed "Effective Java" book.

> But third-party IO is exactly the thing you'd want to mock.

You write an adapter.

Once you start writing adapters you need a way to instantiate them to choose between implementations, and factories is often used for this. Then you might generalize the test suites to make the setup easier and you end up with the infamous FactoryFactory pattern.

No, some other library classes accept only their own, not my adapter.

Not mentioning of course needless copy-pasting dosens of members in the adapter. And it must be in prod code, not tests, even though it's documentation would say "Adapter for X, exists only for tests, to be able to mock X".

You wrap whole 3rd party dependency in an adapter.

That's a lot of upfront work and maintenance, not to mention the friction of needing to mentally translate every occurrence of OurFooAdapter to Foo in order to find documentation.

The second argument still holds -- all those wrappers will exist in prod only for tests.

Moreover, that wrapper library is now a pretty large piece of code, and we'd want to maintain and test as well. But cannot without hacks.

I think it's easier to unpack/remove-"final"/re-compile the library .jar during the build time. Will be more stable to any changes than an adapter.

I read blockade survivors diaries, they all say it's easy to get used to hunger, but not to cold.

> this would also reject HTTP clients that are not browsers

Why? I can send any headers from a client I make.

And some very simple computations become much more cumbersome in SQL, e.g. Panda's df.diff() or df.cumsum() is much more awkward using window "functions".

My only problem with SQL is it was designed for human input (same as shell commands), not for machines. Hence the SQL Injection attacks and other peculiarities and inefficiencies.

IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL). So that any invalid SQL parameters like "1;DELETE FROM users;--" would just fail to parse.

It may be called ABI, although it may be textual as well (like json), not necessarily binary (like protobuf).

PostgreSQL already supports binary wire protocol, but I never seen it's being used, instead people prefer sending raw SQL strings designed for humans even from applications.

You'd have to be using very antiquated (by nearly two decades!) patterns or practices for SQL injection to be a concern.

Agree, but for example, migration scripts are still often just a bunch of long .sql files (unless it's Liquibase with its own cross-DBMS XML syntax), or test/staging/benchmark schemas. Even today.

And subling commenters say that all you need is raw SQL and results mapping to your code. Which I did for a while, but found that mapping is a lot of copy-pasta with minor diffs, a burden to maintain. So it's easier to use a thin library like JOOQ for mapping, or use only the mapper part of a bigger ORM framework like Django/Hibernate.

And my argument is that it's easier to map to/from a concise strongly-typed ABI/API structs instead of one raw SQL string with its structure designed for human reading/writing, like SELECT before FROM. There are such ABI-s, but they are DBMS-specific, while SQL is less so.

luckily you can use parameterized queries and completely avoid this problem.

Only for simple queries. E.g. it's hard to parameterize table names.

Also it makes an extra round-trip to server to prepare the query.

> For UUID v4s, primary key values in B-Tree indexes are problematic.

Wrong. Don't use B-Tree for random indexes, there's HASH index exactly for this:

    CREATE INDEX [index_name] ON [table_name] USING HASH ([column_name]);

GitLab actually implemented Actions first back in the day (called CI/CD). I remember GitHub was following their lead.

Which is funny reading how TFA tries to feign ignorance:

> When we shipped Actions in 2018, we had no idea how popular it would become.