Stuff like that is a good argument for using structured logging, but even if you are just parsing text logs, surely you can make the parser be a bit more specific when retrieving the log level.
What if user sends some sort of auth token or other type of data that you yourself can't validate and third party gives you 4xx for it?
You won't know ahead of time whether that token or data is valid, only after making a request to the third party.
There are still some special cases, because 404 is used for both “There’s no endpoint with that name” and “There’s no record with the ID you tried to look up.”
That's a useful feature for long-running issues to include updates in the opening post. Or to improve formatting when a bug reporter isn't familiar with markdown.
And that it shows in the edit history should at least discourage abuse.
The vanishing small percentage of people that would actually check a comment’s history are the same people who would check a Wikipedia entries history.
At a bare minimum, the post should have in big bold lettering: Edited by <user_name>.
Allowing the maintainer to prepend a comment to the top seems more sensible to me to be honest. Would make API use harder potentially, but it would avoid weird abuse like this.
github is meant for collaboration, designing it around adversarial use would be a loss for everyone. Adding a function to report absusive edits rather than an entire post would be a better choice imo.
reporting abusive edits requires moderation/arbitration. the rules can instead be changed to sidestep the issue, while maintaining the value of the feature.
Report to whom? Github, who allows the behavior and therefore doesn’t see anything wrong with it, or the repo admins who have proven they they couldn’t give a rat’s ass about the very thing you’re reporting? The well is already poisoned, there is no reason to think that they’d suddenly change their stance and cooperate.
In this case at least, github (most probably) banned this account, presumably after reports. There are also other stories for github banning accounts for pr trolling kind of behaviours. So not sure if everything is perfect, but at least there are cases such things work.
Yes, with an edit history I think it's a useful feature. I often use it to add pre formatting to errors or code examples people post, or to edit titles to be more helpful ("weird issue with X" → "clearer description of the bug" after triage). It used to be that it didn't have an edit history. I think it was added about five or six years ago? You could also delete comments with no indication there was ever a comment there.
I once had someone request a feature and they became quite aggressive after I declined it. I essentially told them to fuck off[1] and that was the end of it. A few months after this he strategically edited and deleted some comments to make it appear I was just insulting them for no reason and then started posting on HN and Lobsters what an asshole I was. Back then, there was no real indication of their manipulation.
[1]: In part because he was already a known troll. Well, maybe troll isn't the right word, but he does have a history of mass-reporting hundreds of feature requests across hundreds of repos, to the point where it's basically just spam. He's been banned from Github many times over this, but just keeps creating new accounts and it all starts over again.
No, that's not obvious at all. A single event is evidence that some abuse still happens, it does not tell us how much more abuse there would be in the counterfactual where the history wasn't available.
I get what you're saying, but I feel like they should highlight comments in some way if a repo admin completely replaces a comment with different text. I'm struggling to imagine a situation where that would really be appropriate. The "Edited by: username" seems too easy to overlook.
I maintain the formatter for Dart, so a lot of my job involves maintaining the issue tracker for the formatter.
I use this feature all the time. Users get Markdown wrong, give titles to issues that don't make any sense, have typos, etc. Being able to edit issues helps me keep the issue tracker easier to understand and navigate for maintainers and users.
Every feature can be used. That doesn't mean every feature should not exist. The fact that the edit history is still visible means it's next to impossible to abuse the feature. It works fine.
Markdown is pretty tricky for new users to figure out, so quite often, users will just paste big snippets of code without formatting them, which is nearly unreadable. I'll usually edit these posts to add ```backticks``` around any code.
This is particularly useful when editing the top-level comment of a popular issue to specify the current status. Or when a peer opened a placeholder issue and you fill it up. Etc.
If you actually use GitHub as a social network of sorts, there are many reasons to do edit comments. All the edits are visible anyway. You're on Git-Hub, you can already edit everything you have write access to.
That also means that some users will be pressured to censor illegal speech no? If you live under e.g. a regime that disallows or discourages criticism, now suddenly the onus is on you to do something about those comments because you have the ability to. If you couldn't edit the comments it's not your fault.
Either way I think it's a pretty stupid feature the way it's implemented; it should show the edit more clearly or indicate that the comment has been written by multiple people (like StackOverflow does), especially if edits change more than e.g. 10% of the original comment.
This is not an improvement. Having named variables for things is good actually. They will need to be declared again immediately once you want to modify the code. insertCell(i).innerText = c is a nonsense statement, it should be 2 lines for the 2 operations
I disagree, but maybe it is a cultural thing for those of us that are more used to functional styles of programming? I was taught method chaining as a style by a seasoned JavaScript and Ruby programmer myself and I do not find the semantics confusing. "Create X with Y set to 17 and Z to 4711" can be either on one or three lines to me, as long as the method calls are clear and short enough.
As for variables, I (again personally) find it taxing to have many variables in scope, so I do net see their presence as a universal good. If we instead simply use expressions, then there is no need to concern yourself with whether the variable will come into play later on. Thus, I think it increases clarity and favour that over the ease of future modification argument you propose (heck, I would argue that you get better diffs even if you force the variable declaration into a future modification).
As for bikeshedding this piece of code further, if I steal some ideas from chrismorgan [1] and embedding-shape [2] who appear to be way more seasoned JavaScript programmers than me:
const $t = document.createElement('table');
for (const r of
[
['one', 'two', 'three'],
['four', 'five', 'six' ],
]) {
const $r = $t.insertRow();
for (const e of r)
$r.insertCell().innerText = e;
};
document.body.append($t);
This is now rather minimal and the logic is easy (for me) to follow as the scopes are minimal and namespace uncluttered. It was a rather fun little exercise for a language I am not overly familiar with and I learned a few tricks and perspectives.
It's really tough to read through a text where you can't go more than a few sentences without having something be described as *an adjective, a second adjective, and a third adjective*. Just let the code example speak for itself, man.
Speaking of the code examples, I am not convinced at all. The supposedly bad example is idiomatic and understandable to me, and I have a much better idea of what's going on than in the supposedly good examples. It contains the kind of constructions I expect to see when working on a Go codebase, and it will be easier to modify correctly for another Go developer coming in later. Please, work with the language instead of forcing it to wear a programming paradigm it doesn't like.
It has to be AI generated or at least edited right? The reliance on bulleted lists. The endless adjectives and declarations. ...but also the subtle... well not exactly errors, but facts I think are open to dispute?
Such as:
> Together, these tools make Go perfect for microservices, real-time systems, and high-throughput backends.
Real-time systems?! I have never heard of anyone using Go for realtime systems because of its GC and preemptive scheduler. Seems like the sort of thing an LLM would slip in because it sounds good and nails that 3 item cadence.
> Built on top of Go channels → broken backpressure.
But then the example is about ordering. Maybe I'm being pedantic or missing the specific nomenclature the ReactiveX community uses, but backpressure and ordering are different concerns to me.
Then the Key Takeaways at the end just seems like an LLMism to me. It's a short article! Do we really need another 3 item list to summarize it?
I'm not anti-LLM, but the sameness of the content it generates grates on me.
I have never heard of anyone using Go for realtime systems because of its GC and preemptive scheduler.
I don't know. I've seen "realtime" used quite often in a sort of colloquial sense, where it means something fairly different from "hard realtime system" as an embedded systems person might use the term. I think there's a pretty large base of people who use "realtime" to mean something that others might call "near real-time" or just "continually updating" or something along those lines, where's there's no implication of needing nanosecond level predictable scheduling and what-not.
That's not to say that the article isn't AI generated, or whatever. Just that I wouldn't necessarily see the use of the "realtime" nomenclature as strong support for that possibility.
reply