Ask HN: Programs that saved you 100 hours?

aText https://www.trankynam.com/atext/

grep -ri "Something.Something"

For sure!

Black and isort complement each other in formatting your code, and both have flags to check whether they would change anything in your code. You can do the former either as a script or Makefile target, and the latter in CI to verify that the code is actually lint-free.

flake8 is your standard linter - it checks for idiomatic Python. I prefer to set it quite strict, with `max-complexity` starting at something like 4 and only moving it up if I really can't figure out a way to make the code simpler. And you shouldn't have to ignore any lints unless there's a linter or formatter bug or conflict. The only place I've seen this is with E203.

mypy is a tricky one if you're not yet used to Python type hints. I would recommend starting with no configuration and then introducing stricter rules as you understand more of them. My current go-to configuration sets all of check_untyped_defs, disallow_any_generics, disallow_untyped_defs, ignore_missing_imports, no_implicit_optional, warn_redundant_casts, warn_return_any, and warn_unused_ignores.

To list all the files in your project tracked by Git (because you don't want to lint or format any third party files) NUL-terminated (because you want to handle weird file names) run `git ls-files -z -- '[star].py'`. To instead list only the files changed from origin/master (your typical target branch for a merge request) except for those you've deleted locally you can run `git diff --diff-filter=d --name-only -z origin/master -- '[star].py'`. You can then pipe the result of either command to `xargs --no-run-if-empty --null black` and similar. Use the first Git command in CI to lint all the files, so that you don't miss out on any changes for example when any of the linters change their rules. Use the second Git command locally to format and lint your changed code. And make sure you have some way to force formatting/linting all the code for when you update any of these programs.

Finally, running all the linters as part of a pre-commit hook is a great way to make sure you never commit broken code. Having a bunch of lint fixup commits is ugly and counter-productive.

draw.io -- [browser based](https://www.draw.io/) as well as [desktop drawing tool](https://github.com/jgraph/drawio-desktop/releases/tag/v12.9....) with many templates for flowcharts, UML, etc. Free and very useful.

Odd. Completely the opposite experience here. Windows requires searching and installation of drivers and configuration via GUI. Linux has drivers built in so just works. I haven't had to install a driver manually since ditching nvidia a year ago. And all my config lives in text files on Github.

I'm guessing you haven't tried Linux in 10 years or so, but even then I don't understand how Windows does any better on the drivers front.