the “what” is interesting on interfaces or when you generate documentation with some tool like sphinx or javadoc.

the “why” is interesting when you are somewhere inside a class or function and do something in a “strange” way, to work around a quirk in the codebase or something like that, or when you employ optimizations that make the code harder to read or atleast less obvious why somethings are done.

subscribers and something called bits of which i dont know the purpose.

• avoid automated documenting tools

the output of tools like sphinx, javadoc and so forth is a good starting point, especially if you feed them properly commented code.

the rule “garbage in, garbage out” definitely applirs here.

good Tester.

If something stupid can be done, it will be done.

I’ve seen enough programmers blindly copypasting code from stackoverflow and other forums without thinking and never understanding the thing they just “wrote”, to know that tools like copilot won’t make programmers worse, they will allow more people to be bad programmers.

people need to read more code, play around with it, break it and fix it to become better programmers.

the touchpads atleast feel like the ones on the steam controller.

flickstick is a control scheme where your stick only controls the camera horizontaly, so if you push the stick down you’ll spin 180° if you push it to the right you’ll turn until your character faces to the right and so forth.

deck is mostly more input options (right stick, d-pad, 4 back buttons instead of 2).

the biggest difference is the placement of the touchpads imho, as i cant use both shoulder buttons and the touchpad on a side without adjusting my grip, but that only mattered in shooters for which i use flickstick on the deck and not the right touchpad.

parquet is cloesely tied to the apache foundation, because it was designed as a storage format for hadoop.

But many data processing libraries offer interfaces to handle parquet files so you can use it outside of the hadoop eco system.

It’s really good for archiving data, because the format can store a lot of data with relatively low disk space, while still providing ok read performance because often times you won’t need to read the whole file due to how they are structured, where csv files would be a lot of plaintext taking up more diskspace.

since none of your examples add anything of value in the body: a plain old 403 is enough.

response bodies for 400 responses are more interesting, since you can often tell why a request was bad and the client can use that information to communicate to the user what went wrong.

best error code remains 418, though.

for receipts and such paperless ngx is good. that won’t track your repairs or inform of you of likely maintenance problems, but that and a spread sheet sounds like a good start.

there is no “undefined” in java. this would either be a map containing the key value pair (“name”, null) or it would be mapped to an object of some class with an attribute “name” which can hold a null value. in any case {} wont equal {“name”:null}.

look into local dns servers if you want multiple machines to use your local domains if you only want a single windows or linux (and probably mac) computer to use the domain to access a specific local ip an entry in your etc/hosts file would be enough

sounds like you want a MultiKeyMap and a way to store the data from which you build the map, so i’d suggest to look up that data structure. incremental search could than be implemented by filtering on the key sets or subsets of it.

https://github.com/docker-mailserver/docker-mailserver should be able to do it.

if i remember this in 6 weeks i’ll check the setup at work.