Many registrars let you buy a domain and set up dynamic DNS for it within their system so you can own a domain and get dyndns on it.
Otherwise you could accomplish it with a VPS but you’d only need the smallest one available because it would just need to run nginx to forward to your home ip (and a small tool to update that IP when it changes). So you could probably get something for less than $5/mo.
I see you got your answer, but I’m adding on for anyone else that comes across this.
For me, I learned the most when I had a disposable and replaceable system. When I was dual booted I was too scared to touch anything in case it fucked everything up. Once I started poking round on a Pi, LiveUSB, etc it was a lot easier to learn because I could always restart.
Id start there with something like Mint or Ubuntu. Then set it up in a way where you can easily replace your OS so you can reset it often and fuck around. Then just learn as you go.
How long are folks planning to wait before migrating to something new? I suspect this is still safe for at least a few months before things fall out of date, right?
Or I guess it allows wire guard to update freely so it’s probably safe until something specifically breaks.
Just be careful you don’t get their “smarthome” line, at least for cameras. It doesn’t require Internet to operate, but it requires Internet for configuration and management.
I’m not sure if that’s the same with their doorbells, but it was true of their wifi cameras.
With a comment on the test detailing why it matters so people don’t just assume the test is out of date when it fails.
And ideally test the underlying result of x before y, not the fact that x is called before y.
And while we’re at it, assert in Y that X has been called, and again comment the reason for the preconditions.
Code comments for "why"s that persist. Commits for why’s that are temporary.
If you need to run X before Y, add a comment. If you added X before why because it was easier, leave it in a commit
Don’t just summarize the content though, summarize the rationale or how things connect. I can read your diff myself to see what changed, I want to know the logical connections, the reason you did X and not Y, etc.
Or just say “stuff” and provide that context in the PR description separately, no need to overdo the commit log on a feature branch if you’re using squash merges from your PR.
Sourcetree is still best by far for history browsing, and I’ll die on that hill.
A Windows VM running Windows terminal, SSH’d back into the host, obviously.
Honestly I stick with whatever the default is and never had a problem that led me to find anything else.