I'm not sure if I understand why. I like snapshot testing, but I'm not sure what you gain from using this dsl approach instead of a snapshot library and a more typical test framework, but there are some notable downsides:

• you have to write typical tests in a different place from your snapshot tests. some things are more complex than "this value never changes", you might just care about a property holding, it produces the same value for several different inputs, etc. properly capturing a big for a regression test is more than a snapshot
• you lose editor tooling, I can't just send tests to the repl from my editor, I don't have autocomplete, etc
• need edn serializers for all values you care about. seems easy enough to return a host language object without a proper representation
• may just be me but I'm not a fan of the added levels of nesting

I have a GL.iNet GL-MT6000, works great. not sure about newer models but people generally seem to like their higher end ones

it ships with almost vanilla openwrt, and it's easy to install an upstream build if you'd like. the big advantage of GL.iNet is that it's officially supported, so I've been able to send emails to support about openwrt stuff and they've been helpful

AdGuard works great and is built in to their version, so you wouldn't even need the separate device for pihole

I also like supporting a company that supports oss software

NixOS, plasma rn but sometimes jump to sway. I'd say distro is more relevant. for the most part I just have an editor and a browser open, DE doesn't change much about my workflow. NixOS definitely does though

chosen by my team, company at large doesn't care but it's nice for everyone to be on something consistent. company devices

NixOS is a nice balance of the two

I generally just copy my personal setup, which I've spent a decent amount of time on, but because I enjoy it

not particularly, but nix supports all of the big ones

language and stack a little bit, it's all stuff that has good integration with nix. we deploy nix containers and then have consistent environment everywhere without having to work in a container. my team is a pretty standard team maintaining some full stack web stuff

it doesn't matter how it was made once it's secondhand since it doesn't support the manufacturer

I suppose there's people that bought the original item since it had resale value, but I really doubt that's significant overall, especially at most thrift stores

you could look at the user agents and have 2 versions, one for normal browsers and one for Links and similar.

you could also probably do something terrible with having an initial page that supports both, adding a cookie and detecting if the css file gets downloaded, then after that point serving them the css styled if they did or the table styled if not. you could even reload the page with js if it's enabled and you detect the css was downloaded. this hinges on Links and similar not even downloading the css, which I'm not sure if is true.

even without hotswappable switches there's a good chance you'd be able to replace the switch anyway

if cleaning it doesn't work, you should be able to look up how to desolder and then replace the switch yourself. you should only need a cheap soldering iron, some wick, some solder, and a new switch.

as long as it's easy to physically get the keyboard apart, the switches should be just about the easiest thing to solder there is

probably about the same as like vapor smoothing abs with acetone. I think pla has solvents that work too but they're much nastier