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!
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.
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.
Love it , wouldnt work where i live , no flat roads. , Would be a new extreme sport going downhill though :) but I think I am gonna go for the one in the comments perhaps hackaday.io/…/180836-desk-ercising-with-the-exer-…
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.
This is the kind of pointless comment I see in my codebase all the time. Best I can tell, a couple of my coworkers like to plan out their code using comments, then backfill in the actual executable code. That’s fine, but they leave the comments in when they add no value.
` public static LocalDate parseEndDateFromString(String dateString) {
<span style="color:#323232;"> try {
</span><span style="color:#323232;">
</span><span style="color:#323232;"> String[] split = dateString.split("-");
</span><span style="color:#323232;">
</span><span style="color:#323232;"> //In order to get the last day of the desired month, we go to the first day of the next month, account for rollover, then subtract one day
</span><span style="color:#323232;">
</span><span style="color:#323232;"> int month = Integer.parseInt(split[0]) == 12 ? 1 : Integer.parseInt(split[0]) + 1;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> return LocalDate.of(Integer.parseInt(split[1]), month, 1).minusDays(1);
</span><span style="color:#323232;">
</span><span style="color:#323232;"> } catch (Exception e) {
</span><span style="color:#323232;">
</span><span style="color:#323232;"> throw new RuntimeException("Invalid date format - must be MM-YYYY");
</span><span style="color:#323232;">
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">
</span><span style="color:#323232;">}`
</span>
Stuff like this, otoh, is where comments are useful. The required format is obvious from the error message, the param and return from the method signature, the only part that requires a comment is the fiddly logic of accounting for the edge case where month == 12 and the rationale behind how we determine the last day of the month. As a rule, comments are for why something is being done, if it’s not obvious, and for magic numbers. Code should tell you what code does.
edit: can anyone spot the bug that I introduced with that parseEndDateFromString() method?
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.