/s is bloat, say it like you mean it!
/s is bloat, say it like you mean it!
For a while I had an Asus laptop, and no matter what, it seemed to not want to work properly with systemd-based distros. It would hang on-boot about 95+% of the time, I’d hard shut-off, restart, repeat.
On a whim, I tried Void Linux (runit) on it. And for whatever reason, it worked.
Of course. I don’t call Facebook Meta, and I don’t call Google Alphabet.
You can change your company’s name, or nest it in a shell, people still know who you are
Essentially, there is a massive pixel-divided canvas. It starts out pure-white.
You are allowed to place one single pixel of a certain subset of colors every x minutes (I don’t remember how often, somewhere between 5 minutes to an hour).
Your pixel(s) can be overridden by any other user who places their pixel on your space after you place yours.
Some people come together to form collaborative art, messages, etc. (As seen here).
In the past, there have been countries’ flags, a giant spreading black void, hidden Among Us beans, and many fandom-specific and subreddit-specific images.
If its something that represents mutually exclusive states, like the license plates examples (Gov’t, Embassy, Learner), an enum like 4wd mentioned is a better idea than many boolean keys. This would also be the switch/case question you posed. For a “regular case”, I would include that in the enum, but if you create an enum that only contains “special cases”, you can always set it to null.
On the case of booleans, I would suggest avoiding them unless it is necessary, and truly a binary (as in, two-option, not binary numbers), self-contained-in-one-key thing (obligatory anti-boolean video). If the use case is to say what a different key’s object represents, you don’t need it (see: enums. You’ll thank yourself later if you add a third option). If the use case for using it is saying another key contains value(s), you don’t need it. Many languages can handle the idea of “data is present, or not present” (either with “truthy/falsey” behavior interpreting “data-or-null”, or “Maybe/Option” types), so often “data-or-null” can suffice instead of booleans.
I would suggest trying to always include all keys of a present object, even if it’s value is null or not applicable. It will prevent headaches later when code might try to access that key, but it isn’t present. This approach might also help you decide to reduce the quantity of keys, if they could be consolidated (as in taking booleans and converting to a state-like enum, as mentioned above), or removed (if unused and/or deprecated).