If it were designed properly you wouldn’t need to be good at it, it would be trivial and obvious to do the only thing anyone ever needs to do to their content within an area of the page
- 0 posts
- 39 comments
- 7 months
Why? Isn’t it likely that it’ll just report e.g. “python-requests” for the user agent, and it’s up to the server side to decide what that means?
- Whelks_chance@lemmy.worldto
Linux@programming.dev•ReactOS Lands Improvements For Its USB Stack - Fixing Various Blue Screens of Death
7 monthsI don’t think a driver update is enough to fix whatever is going on in that photo
Tom Scott’s video is about to do the rounds again then
And the discussion on whether or not to pin versions.
Pinned, these packages work together, but don’t automatically pull in security updates.
Don’t pin, things randomly change on each build, best of luck debugging things.
Exactly. I got a drive by downvote which is a shame. Some people are in a situation where they’re happy to take a risk, and know that if it fails they won’t be destitute, and sometimes you might be paid more to account for the risk. Or less, but you get stock options to account for the risk. They’re all valid options as long as you’re not forced into it.
Someone else wrote some code, and he reviewed it and approved it, and merged it into the codebase.
Not sure why this is downvoted. It’s a lifestyle choice that is a genuine choice. You don’t have to live in SF if it’s not for you.
Finally, thanks I’ve been trying to remember the name of this for ages
I’m not sure there is a correct way to do this
I have the opposite issue with helm charts, where true and false are very, very loosely defined.
This is why I ask for the schema at the same time as asking for (even example) data at the start of a project. Don’t tell me you have the data, give me proof there’s a standardized structure, or the length of the project just tripled.
The fix might be 5 mins. Figuring out wtf was wrong in the first place is the time consuming bit. Especially if the report doesn’t contain a repeatable process to trigger the error condition.
Put it in the backlog and we’ll prioritise it in the next sprint planning. Except we’ve already got a good idea of what’s going in to the next sprint, so we’ll probably get to it in a month. Or two. End of the year tops. Bring it up in the quarterly planning if we haven’t finished it yet, and maybe we can squeeze it in before Q2. Unless the win the ACME project in which case all hands will be on that, so actually plan for it to be in production by Xmas. No, the one after that.
I’m now tempted to do this for all several thousand commits in the main branch, and at the very least create a better changelog.


Strongly reconsidering respecing my career into this. But there’s a risk it’ll just become “some junior with Dunning Kruger vibe coded this shite, now you have to fix it”