Interested if you remember what was missing?
Ahh, that would make more sense, thank you - corrected
This is a great explanation, thank you.
I deal mainly with authorization and I'm not sure I've ever had the differences explained this simply (so I incorrectly lump them together)
AutheNtication vs. AuthoriZation, I believe
Depending on where you want your app to run, QT framework/creator has pretty powerful C++ GUI capabilities. The biggest benefit, I thought, is a lot of open source projects use it (e.g. Bitcoin and forks) meaning there are a lot of real examples out there rather than only docs.
The other option, which is more aligned with separate frontend/backend and WebApps, is simply have a basic server of some type wrapping the dll functionality you want to use as endpoints and communicate over ReST API.
This is an awesome graphic!
At one point I got in the habit of stash apply rather than stash pop.
I like it since the original stash stays unmodified, and can be reapplied if needed.
I dislike it since I am bad at cleaning up my stashes and they can grow large (my own fault). Also bad at naming my stashes (i.e. git stash save "my new stash") and then it gets hard to tell which is which when inspecting the stash.
I rebase my dev branches on main to get rid of garbage commit messages due to me being lazy.
Squash and merge PRs into main, no merge commits allowed.
I think there are reasonable arguments for allowing rebase and merge to main, but it often doesn't apply for me.
Merge commits in main will break a lot of out of the box GitOps tools.
This is an interesting option and probably pretty useful for python projects.
Although I generally push back against use of python usage as a build tool (it is not a build tool), I know tons of people still use python scripts in their CI (as a build tool), which, I think only makes sense if you are a python shop. Why install python to build java, for example? (pro-tip - don't)
Disclaimer: these opinions are mainly targeted toward closed source enterprise software.
People love using all sorts of fancy stuff in their CI, and I am personally a CI purist. If it can be done in bash, do it in bash. See scripts-to-rule-them-all by GitHub, which I personally think is still too little, but at least sets a good foundation.
CI purist examples:
I am of the opinion that if one feels like they need credentials for their cloud provider in CI (besides cloud provider as artifact host), the project probably needs better unit testing rather than integration tests requiring all sorts of real creds to be injected. Does it take some extra time, sure, but arguing against push back for "better testing" is not an easy path to go, trust me. ("No!!! My couple integration tests with bunches of dependencies injected are easy and get a lot of code coverage!!" -- code coverage != good tests)
I am also of the opinion that one shouldn't even be using things like 3rd party GitHub actions that one has no idea what they actually do, just that it works, and then auto bring in updates that one doesn't actually watch what is being updated. Sure it still works, but did it turn into malware, the project auto pulled in updates, and no one was watching? How does one know, if one isn't watching the upstream changes.
CI/CD is primetime for supply chain attacks. It is not an if, but a when. Prepare for the inevitable.
Free penetration testing ๐