- Nov 2021
-
unix.stackexchange.com unix.stackexchange.com
-
That's not how flatpack works; the executable is hidden in a container and you need to set up the whole environment to be able to call it. Delivering a well-isolated, not-to-be-run-from-outside environment is the whole point.
-
- Apr 2021
-
www.metacritic.com www.metacritic.com
-
Yes, it shares the name and the look of those previous games, but it lacks the all-important creative heart of its predecessors, and ends up being a by-the-numbers affair that goes through the motions in a shallow attempt to turn Scribblenauts' unique premise into a multiplayer party game.
-
- Mar 2021
-
blog.izs.me blog.izs.me
-
All too often, people get hung up on the wrong aspects of the Unix Philosophy, and miss the forest for the trees
-
- Feb 2021
-
-
with ActiveForm-Rails, validations is the responsability of the form and not of the models. There is no need to synchronize errors from the form to the models and vice versa.
But if you intend to save to a model after the form validates, then you can't escape the models' validations:
either you check that the models pass their own validations ahead of time (like I want to do, and I think @mattheworiordan was wanting to do), or you have to accept that one of the following outcomes is possible/inevitable if the models' own validations fail:
- if you use
object.save
then it may silently fail to save - if you use
object.save
then it will fail to save and raise an error
Are either of those outcomes acceptable to you? To me, they seem not to be. Hence we must also check for / handle the models' validations. Hence we need a way to aggregate errors from both the form object (context-specific validations) and from the models (unconditional/invariant validations that should always be checked by the model), and present them to the user.
What do you guys find to be the best way to accomplish that?
I am interested to know what best practices you use / still use today after all these years. I keep finding myself running into this same problem/need, which is how I ended up looking for what the current options are for form objects today...
- if you use
-
- Jan 2021
-
askubuntu.com askubuntu.com
-
No, this is not a duplicate of that linked question. I don't need to know "why it's a snap". I want to know how to use it without snap.
-
-
css-tricks.com css-tricks.com
-
I think you’re missing the spirit behind the classic “centering is hard” complaint in a couple of places, which, at least for me, always comes back to not knowing the height of the elements.
-
- Oct 2020
-
-
mixing the turing complete of javascript with the markup of HTML eliminates the readability of JSX so that it is actually harder to parse than a solution like hyperscript
-
- Sep 2020
-
github.com github.com
-
The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.
Tags
- arbitrary limitations leading to less-than-ideal workarounds
- +0.9
- key point
- Svelte: CSS encapsulation
- missing out on the benefits of something
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- important point
- Svelte: how to affect child component styles
Annotators
URL
-
- Jan 2020
-
-
Some questions are only asked by people with a fundamental misunderstanding. The friends who walk into my office and ask, “have you read all of these” miss the point of books.
-