@koreth
@lemm.eeWatched season 1 back when it was first airing, but never got around to season 2. People seem to hate it but I can't quite tell if that's because it wasn't up to the standard of season 1 or if it was just bad TV.
Should I skip it and go straight to season 3? Or is it worth watching on its own merits?
Domain-driven design includes the idea of a "ubiquitous language" where the engineers and the domain experts and the product owners come together and agree on terminology for all the domain concepts, and the project then uses that terminology everywhere.
But on the projects I've been involved with, much more common is a situation where the requirements docs mostly use one term but sometimes use a different name for the same thing because the docs were worked on by two people who disagreed on the terms, the designers decide they don't like how the words look so the UI calls the concept something else, the database developer reverses the term's word order to fit their personally-preferred schema naming conventions, the API designer invents a compound name that includes both the UI and the database names, and so on. (I only barely exaggerate.) Which names map to which other names becomes tribal knowledge that's usually not written down anywhere.
This kind of thing bugs me a lot, but I seem to be in the minority. I recognize that it makes very little functional difference, but it just feels sloppy to me and I don't like having to remember multiple names for things. I will usually advocate for renaming things in the code for consistency, and other people on the team will almost always agree that it's a good idea and will happily accept my PRs, but I'm usually the only one taking the initiative.
So, my question to you fine folks: am I wrong to care much about this? Do you think using consistent names for domain concepts across the board actually makes a meaningful difference in terms of code maintainability and discoverability? Or is the effort required to keep the names consistent over time actually greater than the mental overhead of working with the inconsistent names?
I ignored this show when it first came out because the initial trailer didn't do much for me, but I ended up enjoying the first season, and so far I'm enjoying season two even more.
It's kind of a variety-show take on "Rashomon" in the form of a comedy murder-mystery. The gimmick is that in each episode, you get one character's version of the story as a mini-movie in a film style that suits that character. So you'll see the same events unfold as a romantic comedy, an action thriller, a horror movie, a musical, and so on. Some of the mini-movies fall flat, but the ones that work are lots of fun.
The mystery itself was pleasantly constructed in season one, with clues hidden in plain sight from pretty early on if you knew what to look for. Season two isn't finished yet, but it seems like it'll do the same; in the first episode there's a little comedy bit about picking people up from a hotel that's just a quick gag on one level, but is also clearly the writers saying, "Pay attention, because minor inconsistencies are going to matter."
Anyone else watching this show?
I just filled out a passport renewal form and listed "brown" as my hair color. But if I'm honest, I'm at an age where there's more gray hair than brown hair.
There's still enough brown that it's obviously my original color, so I don't think I lied on the form, but it got me wondering: what's the cutoff?
Curious to know how many people do zero-downtime deployment of backend code and how many people regularly take their service down, even if very briefly, to roll out new code.
Zero-downtime deployment is valuable in some applications and a complete waste of effort in others, of course, but that doesn't mean people do it when they should and skip it when it's not useful.