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:
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.
"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!
I'm sure Microsoft has some good devs that are a net benefit to the open source projects they use, but this is not one of them.
Found the guy who created the FFMpeg ticket on LinkedIn. Job title: "Principal software engineer at Microsoft", saying they are "A detailed, analytical Software Engineer with Eighteen years of experience". 18 years?! Fuck me dead...
Spreading awareness of using git how it's actually designed to be used is cool to see.
I'm not clear on how I'd send patches to a repository hosted with ayllu. For example with the repo ayllu, they list codeberg (to which you can't send patches) and sourcehut (which uses lists.sr.ht). So... is ayllu really "email-based"? Can anyone else see any other way to communicate via email?
As someone who never did much web development, I was... surprised... at the amount of tooling that existed to paper over this issue. The headaches which stood out for me were JavaScript bundling (then you need to choose which tool to use - WebPack but then that's slow so then you switch to esbuild) and minified code (but that's hard to debug so now you need source maps to re-reverse the situation).
Of course the same kind of work needs to be done when developing programs in other languages. But something about developing in JS felt so noisy. Imagine if to compile Java or Rust you needed to first choose and configure your own compiler, each presenting their own websites with fancy logos adorning persuasive marketing copy.
I often like reading his older pieces. I forget how long he's been at it for. Here's one making fun of Apple almost 10 years ago: https://www.theguardian.com/technology/2015/feb/13/if-dishwashers-were-iphones
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?