In my opinion this is a poor, vendor-originated commentary attempting to spread FUD and drive people to a product. Not worth reading, and I wish I didn't.
Accepting responsibility and leaving is a cop-out?
That's totally opposite to my impression. She took responsibility, left and the company has now shown externally and internally that these kinds of errors have large consequences.
Also: This was not the first sign of mismanagement and bad culture at Norsk Tipping.
I get that it's sort of an accepting of responsibility if you accept we made a grave error -> the person who made (was responsible for) the grave error must be fired; I am ultimately responsible for everything -> I must be fired.
But it's not an accepting of responsibility in the sense of we made a grave error -> it must be made right. Someone getting fired doesn't help the people who were improperly notified. It likely doesn't help prevent improper notifications in the future.
Taking responsibility could mean setting up a quality control process for future changes as well as validating all current the notification strings are appropriate and accurate. And sending an apology to the affected people.
That said, it is perhaps a time for reflection when considering this:
> The company acknowledged it has experienced “a number of technical problems” over the past year.
If you're responsible and things continue to go wrong, perhaps someone else would do a better job, and the best choice is to let someone else have a try.
Yes, that makes sense, if there were many instances and really the leader could have observed that and better lead. My comment was about this approach in general, and specifically when it's just one incident resulting in someones head rolling, in what seems to be a disconnected feedback loop.
I'm just gonna say it: this does not matter. Just use whatever you want. If you're afraid that someone is going to think less of you for it: the people who matter won't.
An excellent example of why dash length matters. Because of the wrong usage of ‘—’ and ‘-’, it took me 10 more seconds of rereading and re-parsing your comment to understand what that first sentence meant.
I see what you did in the second paragraph too. It’s another example of “a millimeter of difference in the length of a line” mattering in that it looks weird, though it’s not much harder to read.
The undotted small "i" character comes from the modern Turkish alphabet. It's perhaps only slightly disorienting for an English reader to slightly shorten some letters that are just lines in a sans-serif font. In Turkish though, a millimeter of line can make an entirely different letter.
Being able to render a variety of line lengths with different meanings is a cool and useful thing.
Either pick one of the recent JavaScript sandbox escape CVEs on a vulnerable browser, or redirect to your phishing page as to your liking. Again, hypothetical and very unlikely, but the risks are there.
highly recommend edamagit in vscode for those over here.
except there's currently a bug that stops commit from working (c - c) when developing in wsl or a devcontainer, hopefully it'll be fixed soon. BUT if you're developing directly on your machine it is an excellent interface to git.
The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting").
Unless the server believes you as an individual user were sending too many it should not have been a 429
If the server was unable to handle the volume of requests more generally it should have been a 503 which also supports Retry-After
IME, it is relatively common to get this response code incorrectly, i.e., not triggered by rate. IME, it can be triggered by sending one and only one HTTP request to a site one has never visited before. For example, a request sent to a certain IP address with a certain set of HTTP headers and header values using a certain HTTP method and HTTP version.
Despite what "Too many requests" suggests, people writing/configuring software are (accidentally) sending this error in response to requests based on quality not quantity.
In each case where I have received it, I was able to make the error go away by changing something about the request.
reply