7 Matching Annotations
- Apr 2021
-
store.steampowered.com store.steampowered.com
-
The responsiveness of the controls is terrible. It's nowhere near consistent, and the delay/lag between button presses and action on the screen is frustrating. It is nearly impossible to consistently jump while in motion, and if you can't do that in a platformer, you're better off not playing at all.
-
- Mar 2021
-
store.steampowered.com store.steampowered.com
-
Requires a lot of patience, which I don't have. Also, progress is not saved, there is no way to select levels, which is unacceptable.
-
- Jan 2021
-
linuxmint-user-guide.readthedocs.io linuxmint-user-guide.readthedocs.io
-
When Snap was introduced Canonical promised it would never replace APT. This promise was broken. Some APT packages in the Ubuntu repositories not only install snap as a dependency but also run snap commands as root without your knowledge or consent and connect your computer to the remote proprietary store operated by Canonical.
-
- Nov 2020
-
github.com github.com
-
It starts truncating it's output (shortening strings with ...) once you pipe it's output into grep. That is quite unacceptable. When I am checking if something is inhibited in a script, I should have all possible information available and not have to consider if a string will get truncated when being piped into a tool, that is perfectly readable on a wide terminal.
-
- Jul 2020
-
bugs.ruby-lang.org bugs.ruby-lang.org
-
Just to provide some context on the extent of the issue. Running the spec suite for Discourse results in 2,698,774 rows being printed to STDERR.
-
- Jun 2020
-
api.rubyonrails.org api.rubyonrails.org
-
transaction calls can be nested. By default, this makes all database statements in the nested transaction block become part of the parent transaction. For example, the following behavior may be surprising: User.transaction do User.create(username: 'Kotori') User.transaction do User.create(username: 'Nemu') raise ActiveRecord::Rollback end end creates both “Kotori” and “Nemu”. Reason is the ActiveRecord::Rollback exception in the nested block does not issue a ROLLBACK. Since these exceptions are captured in transaction blocks, the parent block does not see it and the real transaction is committed.
How is this okay??
When would it ever be the desired/intended behavior for a
raise ActiveRecord::Rollback
to have absolutely no effect? What good is the transaction then??What happened to the principle of least surprise?
Is there any reason we shouldn't just always use
requires_new: true
?If, like they say, the inner transaction "become[s] part of the parent transaction", then if anything, it should roll back the parent transaction too — not roll back nothing.
-
- May 2020
-
-
It's no less beyond the pale than when apple actively sabotaged people's devices to force them to upgrade or amazon deleted people's already bought and downloaded ebooks. It's completely unacceptable and frankly should fall under consumer rights laws.
-