koreth

joined 1 year ago
[–] [email protected] 6 points 1 year ago* (last edited 1 year ago) (3 children)

I don’t think Netflix actually cancels shows after two seasons any more often than other networks do.

Somehow people got it into their heads that Netflix is far more cancel-happy than its competitors, but if you look at the numbers, traditional TV networks have had like a 50% cancellation rate for decades.

Even TOS was cancelled after two seasons!

If Netflix is more prone to cancelling shows at all, which I’m not convinced is even true, it can’t be by an enormous margin.

[–] [email protected] 9 points 1 year ago

The paper (linked from the article) has a photo of the actual tablet in question, which was apparently discovered circa 1900.

 

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?

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago) (1 children)

The "developed or supplied outside the course of a commercial activity" condition is part of why people are up in arms about this. If I'm at work and I run into a bug and submit a patch, my patch was developed in the course of a commercial activity, and thus the project as a whole was partially developed in the course of a commercial activity.

How many major open-source projects have zero contributions from companies?

It also acts as a huge disincentive for companies to open their code at all. If I package up a useful library I wrote at work, and I release it, and some other person downloads it and exposes a vulnerability that is only exploitable if you use the library in a way that I wasn't originally using it, boom, my company is penalized. My company's lawyers would be insane to let me release any code given that risk.

 

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.