otl

I found the documentation extremely lacking last time I looked at Swift 2 or 3 years ago. Any changes there? Or perhaps there's somewhere outside of Apple's own docs I should have been looking?

I would use reportMissingData

Agreed, report feels clearer as the verb "record" is more about permanent storage and later reference.

Or even just reportMissing? Depending on what's happening around call sites, I often find I can drop generic stuff like "Data" and it's just as clear, especially when looking at a function signature. For instance:

func reportMissing(data) { ... }

It attracts passionate and clever people, but as a result comes with a (rightful) reputation of being hard/expensive to hire for.

Worked at a Scala shop for a while. It was interesting as an outsider to see exactly that play out (I'm a diehard Unix hacker type, love Go etc.). There were some brilliant minds who really seemed to "get" the Scala thing. Then there were others who were more run-of-the-mill Java developers. Scala and the JVM makes all that, and everything in between, possible. With so many Java projects around, the Java devs would come and go depending on team/company factors like job cushiness, salary, or number of days in the office. But the more Scala-leaning people hung around. They made a huge impact on how projects were run.

The bosses would often talk with me about how hard it was to find those people. From a business perspective, they said it was absolutely worth the effort to find the Scala people despite operational overhead of the rotating door for the armies of Java devs.

The Philosophy section has quite a few wonky arguments; I'd skip it altogether.

Guidelines is pretty succinct and has many rules-of-thumb that almost any software would benefit from. That's including CLI, GUI, libraries -- even hardware if you take a bit of a step back.

and full of old bugs and legacy code.

The feeling of reading through those crazy JVM stack traces with classes named "hudson" from the Jenikins prototype... I shudder! Well done for pushing through it all!

But, since this particular set of data is so well-defined, and unlikely to change, roll your own is maybe not crazy.

I think that's the trick here. A relational database lets you do a whole bunch of complex operations on all sorts of data. That flexibility doesn't come for free - financially nor performance-wise! Given:

• engineering chops
• a firm idea of the type of data
• a firm idea of the possible operations you may want to do with that data

then there's a whole range of different approaches to take. The "just use Postgresql" guideline makes sense for most CRUD web systems out there. And there are architecture astronauts who will push stuff because they can, not because they should.

Every now and then it's nice to think about what exactly is needed and be able to build that. That's engineering after all!

or is a specific company being singled out just because some low-level grunt filled in a field in a bug report?

FYI they're not a "low-level grunt". The bug author's job title is Principal Software Engineer at Microsoft with (at least) 18 years' experience.

(they're somewhat unpredictable too - wait what? Why are you downvoting that?! 😂) I had nothing but positive reaction the the dotnet and MAUI communities.

Ha yes know exactly what you mean. The ActivityPub system I've written (from where you'll receive this reply) just drops any Like/Dislike activity altogether!

Fair enough. Just wanted to give a heads-up as to why there's been a negative reception to the post. Good luck with the talk :)

I am giving a talk next week about making the most of the Fediverse

The spirit of link aggregations sites and forums in general is to share ideas and foster discussion. This post is promoting an event. There are no ideas and there's nothing to discuss.

Perhaps wait until after you've given your talk and then share a link to a recording/transcript of it?

"A failure to plan on your part does not constitute an emergency on my part."

Wow now that is a quote I'm going to steal. Wondering if "A failure to understand on your part does not constitute an emergency on my part." has the same punch or is as relevant... anyway, thanks for sharing!

Great question. Short answer: yes!

Long answer: I did this on a production system about 2 years ago.

The system was using MySQL, which was served from 3 virtual machines. Nobody took responsibility for that MySQL cluster, so outages and crazy long maintenance windows were normal especially as there was no DB admin expertise. The system had been hobbling along for 3 years regardless.

One day the company contracting me asked for help migrating some applications to a new disaster recovery (DR) datacentre. One-by-one I patched codebases to make them more portable; even needing to remove hard-coded IP addresses and paths provided by NFS mounts! Finally I got to the system which used the MySQL cluster. After some digging I discovered:

1. The system was only ever configured to connect to one DB host
2. There were no other apps connecting to the DB cluster
3. It all ran on "classic" Docker Swarm (not even the last released version)

My ex-colleague who I got along really well with wrote 90% of the system. They used a SQL query builder and never used any DB engine-specific features. Thank you ex-colleague! I realised I could scrap this insane not-actually-highly-available architecture and use SQLite instead, all in a single virtual machine with 512MB memory and 1vCPU. SQLite was perfect for the job. The system consisted of a single reader and writer. The DB was only used for record-keeping of other long-running jobs.

Swapping it over took about 3 days, mostly testing. No more outages, no more working around shitty network administration, no more "how does the backup work again?" when DB dumps failed, no more complex config management to bring up, down DB clusters. The ability to migrate DB engines led to a significant simplification of the overall system.

But is this general advice? Not really. Programming with portability in mind is super important. But overly-generic programs can also be a pain to work with. Hibernate, JDBC et al. don't come for free; convenience comes at the cost of complexity. Honestly I'm a relational database noob (I'm more a SRE), so my approach is to try to understand the specific system/project and go from there. For example:

I recently saw a project that absolute didn't care in the slightest about this and used many vendor specific features of MS SQL all over the place which had many advantages in terms of performance optimizations.

Things I would want to learn more about:

• were those performance optimisations essential?
• if so, is the database the best place to optimise? e.g. smarter queries versus fronting with a dumb cache
• are there database experts who can help out later? do we want to manage a cache?

Basically everyone always advises you to write your backend so generically with technologies like ODBC, JDBC, Hibernate, ... and never use anything vendor specific like stored procedures, vendor specific datatypes or meta queries with the argument being that you can later switch your DBMS without much hassle.

Things I would want to learn more about:

• how many stored procedures could we be managing? 1, 100, 1000? may not be worth taking on a dependency to avoid writing like 3 stored procedures
• is that tooling depended on by other projects already?
• how much would the vendor-specific datatype be used? one column in one table? everywhere?
• does using vendor-specific features make the code easier to understand? or just easier to write? big difference!

My shitty conclusion: it depends.