The stalebot is most times useless. The only scenario where I can see use of it is a maintainer waiting for the reporter to add information. But closing issues because no maintainer checked on them? That’s garbage and discourages bug reports.
After a extremely long week, I sometimes participate in open source. I have to deal with malicious commits. I have to follow up on issues from misguided individuals who are actually looking for tech support. I have to guide new contributors to how this massive repo works and to submit tests. I have to negotiate with the core team and these convos can often last months/years.
And contributing to open-source is one of the few things that give me pleasure, even if it’s a extremely thankless job.
But I’m tired man.
I’m not dealing with low-quality memers who are providing zero value. Nor should we encourage it.
I do FOSS as well, but I’d rather people have fun punting the stalebot than just keep repeating “this issue still exists”. I will probably get a chuckle out of it.
Facebook for all its nastiness was very much incompetent in influencing the direction of the web. Look at their failed attempts like free basics.
Google on the other hand has the web tightly in its dirty grip. At this point, they aren’t even pretending to be nice. Even those plans that cause them reputational damage are brought back in some other name.
The only way to stop Google is for the regulatory agencies to put their foot down hard. They should be divided into at least a couple dozen companies that are not allowed to do business with each other.
I actually see a legitimate use case for it and helped add the actions version in a project where I'm a collaborator.
Quite a bit, certain bugs disappear after an update without us targeting it (partially because the logs get fudged a bit after going through dependencies, so sometimes multiple bugs have the same cause or it's actually a dependency issue that got fixed) and sometimes we forget about old feature requests.
The stale reminder doubles as a reminder for us to (re)consider working on the issue. When we know something probably isn't gonna get fixed suddenly, we apply a label to the issue. For enhancements that we'll definitely work on soon™, we apply help wanted. We've configured the action to ignore both. We also patrol notifications from stale to see if something shouldn't go stale. This is a medium-sized project so we can handle patrolling and IMO this helps us quite a bit.
Fair enough; I didn’t consider artifacts like logs and traces. I suppose a stale marker might prompt the original reporter to retest and supply fresh ones (or confirm it’s fixed in the dependency case).
In an ideal world I suppose we’d have automated tests for all bug reports but that’s obviously never going to happen!
I’ve seen this same thing happen with Python’s type hints. Turns out giving an “escape hatch” type for devs who have no clue what the type actually is leads to a lot of useless type hints.
Yeah, it’s especially bad, when a library doesn’t provide type hints itself. It can be comically difficult to find out what the return type of a function is, because every if-else-branch might have a different return value, so you may need to read the function body in full to figure out what the type might be.
Add to that, that lots of the tooling around type hints isn’t as fleshed out / useful as it is in fully typed languages and I can definitely understand why someone might not immediately feel like it’s a valuable use of their time.
If I had the willpower or time to go through a multi-thousand line (not including the html templates) legacy Angular 6 codebase where almost every property is typed ‘any’ then I assure you I would have, it’s driving me insane 🙃, also why I prefer backend
The boy scout technique: fix your types when you're working on a bug or a feature, one file at a time. Also try to use unknown instead of any for more sensitive parts, it will force you to typecheck.
The fuck the lemons technique: resign and seek an employer that didn’t fail at the most basic level of engineering management and development culture for years and years — because life is short and we’re all running out of time… always.
When life hands you lemons, just say fuck the lemons and bail
I kinda feel your pain. A project that I helped launch is written in Typescript technically, but the actual on-the-ground developers were averse to using type safety, so any is used everywhere. So, it becomes worst of both worlds, and the code is a mess (I don’t have authority in the project anymore, and wouldn’t touch it even if I could).
I’m also annoyed at some level because some of the devs are pretty junior, and I fear they are going to go forward thinking Typescript or type safety in general is bad, which hurts my type-safety-loving-soul
In theory I’m a fan of the inferred but static typing systems that most modern languages use (kotlin, rust, TS, etc.) where most local variable types can be inferred and only return types/object fields/parameters need explicit types.
I just despise typescript because it feels more like someone put a bandaid over JavaScript and all of its oddities instead of making a properly fleshed out language, and allowing the option for an ‘any’ type to be used freely by default emphasizes that.
Based on your description it sounds like you haven’t given it a fair shake. I’ll take TS over JS any day, at least there is room for improvement. I will say however I personally haven’t been unlucky enough to run into projects that abuse the any type. The worst I’ve run into is a JS library with no typings I have to manually type.
I imagine what they mean is e.g. that TypeScript can tell you something is a Date, but it doesn’t attempt to fix some of the confusing, quirky behaviour with that: developer.mozilla.org/en-US/docs/Web/…/Date#inter…
So, yes, it’s generally better than JS, but it doesn’t actually make it good/attractive, if you’re used to the sanity of backend languages. It very much feels like lipstick on a pig.
Exactly this. I’d rather use TypeScript than regular JS, but I enjoy using almost any other statically-typed language more (except maybe C++) because TS has the potential to be just as bad as JS for codebases where it isn’t being used correctly (this is true for other languages as well but it’s usually a lot more obvious).
Not that it isn’t possible to have good typescript code, but rather that code becomes a lot harder to maintain because of problems that could’ve been prevented at a language level (truthy/falsey logic, ‘any’ type being allowed by default rather than ‘unknown,’ etc)
Combine this with Chrome enforcing manifest v3 starting at June 2024, YouTube ads will be virtually unblockable on Chrome, even with an ads blocking extension installed because Google will be controlling the ad blocking mechanism used by the ad blocker. They can arbitrarily reduce the max number of the blocking rulesets, how often the extension can update the rulesets, or even elect to skip running any rulesets that target YouTube or Google domains.
They could instead severely cripple or outright block Firefox users. Since we are the minority, it won’t affect them. They will just blame it on Firefox and wash their hands off.
I read in a different post that the code was misinterpreted to be a 5 second sleep before showing the video, but instead was waiting 5 seconds to execute some anti-ad-block script. Still pretty sleazy either way.
There’s a video going around of a guy using a useragent spoofer to prove that it only does this on non-Chromium browsers. So I don’t think it’s necessarily anti-adblock, but it could be interpreted that way when you consider Google’s plans to implement DRM in Chromium.
When I went rooting around to find it. I figured it was some QA process that starts 5 seconds after the video loads (the timer seems to be async and the code sends a promise off while it waits). Of course, it’s all minified JS so it’s a huge pain to read.
The annoying thing is, when it’s happened it’s been like a day’s work tops. Making your initial declaration of “can’t be done without rewriting all of it” look very silly.
It usually involves working backwards from unholy abomination the sales team, your manager and the customer fucked into existence between them, and just find out what problem the customer actually wants solving.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.