![](https://lemmy.stuart.fun/pictrs/image/910b6b99-09cf-4901-ba16-a9b3fff89e56.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
I wish this wasn’t so true.
Just chilling
I wish this wasn’t so true.
It’s cool, it’s probably just self extracting. For convenience!
It’s promotion-driven development at its finest.
Believe it or not, straight to jail.
Is there a language that anyone would say really does fare well for continued development or is it just that few people enjoy maintaining code? I’ve maintained some pretty old Go programs I wrote and didn’t mind it at all. I’ve inherited some brand new ones and wanted to rage quit immediately. I’ve also hated my own code too, so it’s not just whether or not I wrote it.
I have found maintainability is vastly more about the abstractions and architecture (modules and cohesive design etc) chosen than it is about the language.
Or then you type the next letter of the word and the result you want goes away, but only after you’re milliseconds from tapping it.
The real primary benefit of storing your relationships in a separate place is that it becomes a point of entry for scans or alterations instead of scanning all entries of one of the larger entity types. For example, “how many users have favorited movie X” is a query on one smaller table (and likely much better optimized on modern processor architectures) vs across all favorites of all users. And “movie x2 is deleted so let’s remove all references to it” is again a single table to alter.
Another benefit regardless of language is normalization. You can keep your entities distinct, and can operate on only one of either. This matters a lot more the more relationships you have between instances of both entities. You could get away with your json array containing IDs of movies rather than storing the joins separately, but that still loses for efficiency when compared to a third relationship table.
The biggest win for design is normalization. Store entities separately and updates or scans will require significantly less rewriting. And there are degrees of it, each with benefits and trade-offs.
The other related advantage is being able to update data about a given B once, instead of everywhere it occurs as a child in A.
I’m not saying it doesn’t suck for this person, but product market fit is a thing for open source too. If people need it they’ll use it and contribute until something better comes along. If not, your idea wasn’t the one. That doesn’t mean it’s not possible. Nearly my whole life runs on open source software, so it’s pretty clearly sustainable.
over the years, using “open source” has become an excuse to avoid paying for software
Um. Yes. And to be blunt: obviously. And in return, I give away software I create for free whether people need it or not, and try to give back in the form of contributions too. But I’ve never once given up my day job for it. Would that be nice? Maybe. But open source software is more frequently sustained by passionate people using and expanding it for their own projects and not by expecting people to pay you for your efforts when you’re likely not paying (nodejs, github, ahem) for the software you’re building it on anyway.
Can we joke about log4shell? Maybe heartbleed?
Piracy is just staying over at a friend’s house.
A few days of my pain in exchange for months of glory and beyond.
My OSHA unapproved slip and slide flooring says otherwise.
Can this power be learned?
How very apt that Hollywood would be so skilled at projection.
It’s the Dodgerolet Corviper.
Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
I’m pretty sure they blame the others for not being more careful and that they if only they slipped and fell more often it wouldn’t hurt so much.
I can confirm this is related to the 0.19.4 update. The bug goes away if I downgrade my instance.
That said, it was extra bad with the beta because I think they never got marked read but now that the final release is cut and I’ve upgraded, they’re being marked read on refresh.
I think. It’s possible I just missed that it was working on refresh on beta6 too.