![](/static/0b35d4a1/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
It’s always Patrick, so both are the same
It’s always Patrick, so both are the same
I have 1010 fingers
In my opinion, the settings file isn’t where this information should be presented. I would put these notes in the release log and readme and example settings file. I have also written this information to logging during startup so a user knows what to do, or I write a migration that does the change automatically if that’s possible.
This is only my opinion and you can use the comment method described like “//“: “Deprecated”
if desired.
For settings files I always have an example file with sensible values filled in and along with descriptive keys that serves as reasonable documentation. If something is truly unknowable, I’ve probably done something wrong.
Agreed. Except that it’s not easier to write imo
Every time I have reached for TOML I have ended up using JSON. The first reason is that Python standard library can read but not write TOML, which is generally useless for me. The second reason is TOML does not add any benefit over JSON. It’s not that much easier to read and IMO JSON is easier to write by hand because the syntax rules are completely obvious.
It appears you haven’t used chat gpt for coding help.
That’s just like your opinion man
I enjoyed 3D movies and wish it became a thing. I still break out the 3D glasses for my TV every once in a while
Only if the code base is well tested.
Edit: always add tests when you change code that doesn’t have tests.
I agree with your first point, but pretty strongly disagree with the other two. Code review is critical. Devs should be discussing changes and design choices. One Dev can not be all things all the time and other people have experience you do not or can remind you of things you forgot. Programming language absolutely matters when you’re not the only dev on the team.
I used to think something like this when I was younger. I spent an inordinate amount of time looking for good gui versions of cli tools. I have come to understand that this is not usually the case and cli tools are more convenient much of the time. I would not classify this as superiority complex, unless I’m being a jerk about it. I don’t care what you use, I just use whatever has the lowest barrier to entry with the most standardization, which is usually the original cli tool.
That said, jetbrains git integration is awesome.
When I look at the many communities with the same names, I completely stops me from interacting with them. Most of the time I know they’re going to be copies of each other with a bunch of duplicate content reposted to infinity.
I think your example is interesting but i disagree with your assertion that it some how facilitates finding niche content.
For example it would be difficult to have to explicitly know that obscure-instance.xyz/c/games
hosts content about 90’s graphic adventure games from the Netherlands and programming.dev/c/games
is actually about game design and not games generally. A better way, IMO, is to just name your community what it is. Names likeadventure_games_nl
and game_design
offer a significantly better user experience. If we want to make the fediverse feel accessible to people, it has to be easy to find what you’re looking for.
This whole thing feels like crypto where everyone has their own coin and they only kind of work together if you have some kind of exchange and some people accept Bitcoin and not Doge. It’s just too complicated for non technical people.
This brings back trauma