stankmut

It’s a common thing in programming. There’s some legacy code that isn’t being used and yet removing it causes things to break. Nobody has the time to figure out what is still referencing that code, so it just gets a comment next to it saying “Not used, but removing it breaks the build” and then forgotten about.

Allowing Google to run an ad campaign targeting their members wasn’t the benefit Blue Cross was talking about, that’s a side effect from them not turning off the data sharing option in the Google analytics settings.

The analytics data is used for prioritizing development work. If a tool they have on the website relies on a library that isn’t compatible with a new version of React, for instance, do they know how many people use it? Having analytics allows you to decide what’s worth spending the development time to maintain.

The analytics would be for the web development team to see which pages/features are used. Usually a product manager uses that data for setting priorities on what gets worked on.

If you turn the disc over, you can actually count the rings without needing to cut into it! This lets you skip having to glue the disc back together after checking the age.

If the APIs are meant for public consumption, requiring feature parity makes a lot of sense. But when it’s for internal use by your own developers, waiting means you are making a bunch of new API endpoints no one will ever use. People will write more and more code using the older endpoints and those endpoints will start getting changes that your new ones will need ported over.

I think if you are going to force people to use new endpoints, you’ll need them to either write the endpoints themselves or have a team member who can write it for them and account for this while planning. If getting a new endpoint requires putting in a JIRA ticket with a separate backend team, 4 planning meetings, and a month wait, people are just going to stick with what currently exists.

It was basically the same thing. In the code base, there was only v3 and v4. I never bothered to check what happened to v1 and v2, but I suspect they were used in an older, archived code base.

In my experience, having to write new v2 (or in my case v4) endpoints for most new features was expected.

It’s not something you would be able to rely on all the time. Security cameras that use IR to see in the dark could be blinded by IR LEDs, but cameras can also have IR filters.

Seems a few people have gotten that confused. Article spent too much time rehashing the change in 15.0 before getting to 15.1 and felt like a typical ragebait article.

Still seems a little ragebaity, they don’t really have a lot of proof that Apple has intentionally disabled running unsigned apps. Their argument is that Apple changed the process for running in 15.0 and an app won’t start in 15.1, therefore the end of the era of sideloading. Personally, I would’ve liked more details on that part and less on history of 15.0.

That number should be how the total of upvotes and downvotes you have personally given that user. Useful for finding who to block when you see a troll comment and realize that nearly every comment you’ve seen from that user has been a waste of your time.

I’ve always felt like people were overblowing the pocket lint thing, since I’ve never had it happen to me. Just realized that it’s because my pockets are too small, so the only pocket I can use is my back pocket with the port sticking out.

The author complaining about Threads defederation from spinster was a pretty big red flag. It’s on every mainstream mastodon blocklist I’ve seen and it’s obvious he knows why. Really leaned into that “how can they discriminate against women!?” dog whistle that TERFs love to use.

Edit: Oh, it turns out he’s married to the person who runs that server. He’s also worked with Gab, used some of their code for his soapbox, and seems to have been involved with Trump’s truth social. No wonder his feelings are hurt.