Words similarly fail me how much I loathe and detest its GUI (at least on mobile browsers, where I often play the game). As an example, one has to actually _close_ the dictionary popup if you fat finger a letter because the fucking backspace doesn't work, or rather seems to require an incomprehensible number of presses to start deleting letters
My holy grail will still be landing on a good multi-layer configuration setup for Rust CLIs. Ideally CLI flags merged over top of environment variables merged over top of configuration files.
Twelf [0] was close in unifying things, but I had some friction. Lately I've been using Schematic [1] to handle the environment + config layers, and then just a manual implementation of Clap arguments layered on top.
"Ideally CLI flags merged over top of environment variables merged over top of configuration files."
I used to wish for that too but I have changed my mind. I think in real world applications with many options it is preferable to not allow every option to be set in every way.
Environment variables shine for properties that vary per instances which share config files and for system properties (think $GOMAXPROCS).
Secrets should never go in the
command line nor the environment.
There is no one size fits all. Arguments, environment and config files have different pros and cons and should be used accordingly.
Yeah I agree, and do the same. Likewise some config gets complex and can only be reasonably set through config. I prefer when I have a system with one base configuration struct where certain fields can be tagged as available on the command line, another subset in the environment, etc.
> My holy grail will still be landing on a good multi-layer configuration setup for Rust CLIs. Ideally CLI flags merged over top of environment variables merged over top of configuration files.
You create your CLI with Click as usual, then Click Extra introspects your "--parameters" to build up support for a corresponding configuration file in either TOML, YAML, JSON, INI or XML.
Not a library, but I have a template repo [0] I made precisely for this purpose (since I found libraries aren’t as flexible as I needed). See it in use at [1].
Edit: If there’s demand I’d be willing to better document it.
I've seen a couple of cli apps recently take the path of "config file is long form arguments, minus the --, separated by newlines, overridden by actual arguments", so if you were doing `dsh` (which doesn't support this) it might look like
I've been using Figment [0] Needs a little bit of hand-holding when you have structs with different field names, but otherwise does everything I need for that particular part of the problem.
I prefer Tidal’s UI and album management. Tidal also has a good notification system for new releases, and otherwise gets out of the way. I moved to Tidal from Apple Music, but would move back if I had to over any other options.
Also, Tidal has been working on opening up more of an API which is hopefully a project that doesn’t die with this announcement.
There can be more of a difference than you might expect. In static site generators, Eleventy is about as fast as you can get in the JavaScript world, and is still 2-3x the time for Hugo in Go [1]. A couple orders of magnitude more than <10ms in this test which is predominantly markdown parsing.
Anecdotally, for large or extra large sites, the build performance gap between even Eleventy and Hugo can be quite large. And the gap from either of those to the newer JavaScript tools like Next.js is enormous.
Yes dictionary is a tough thing to nail down perfectly — to start with we're going to highlight existing words on the board that are invalid, but have a similar line of thinking around the "commit" tap after placing, at least behind some learning setting. There'll be a changelog screen for when things like that make it in :)
Amazing! Thanks for the detailed notes, and the insight.
Dictionary does still need work — especially around some words like soiree which got culled by our dictionary builder. We'll iterate on building it out (without adding "garbage" words
Interesting re: weakest link rule. Agreed that can be unintuitive when learning the game, but it's one of those rules that balances the game well overall. Possibly we just need to be better at explaining it.
Re: the end game — the current computer is just not-very-good, so a future NPC might play better there.
And good things to mull over re: undo buttons / highlighting tiles / letter distribution.
Thanks again for the detailed feedback, really really appreciated
I think the rule was quite well explained - there's a whole page on it, and fairly early on too. I just forgot it as there were so many rules to remember before you start playing.
On 1. — this is definitely the most common piece of feedback so far, so we'll certainly look into it.
On 2. — the battles rules are the most complex part of the game, since they have evolved through the play testing and battle analogies. Our intuition has been that an invalid attacker "sabotages" the battle, and makes the whole attack fail (i.e. an ineffective army rushing a position will often lose in its entirety). And a short-but-valid word is a competent soldier who just isn't strong enough to win on their own :) Possibly something for us to explain more in one of the tutorial/lore/explanation areas.
On 3. — defenders aren't even evaluated if the attacker fails, so the attacking invalid word is removed.
reply