KeepFlying

I started with zero-based budgeting via YNAB ages ago when ynab was a local-only app. Over time though I've adjusted and focus on tracking my expenses rather than budgeting. I've found that for me, budgeting is hard to stick to because I can never predict well enough. Ynab helped back when I used it but even then I always had a "rollover" fund I had to steal from almost arbitrarily to make things balanced.

I do keep a rough spreadsheet budget of my fixed expenses though (rent, internet, phone, electricity, etc) that I use to understand how much of my money is "locked-in" and what is discretionary.

For tracking, I have a spreadsheet I input all my expenses into every month or two that I use to see how Ive been spending my money, and I use that to decide if I'm happy with where I am.

I wonder if you could copy (or buy used) some crypto mining rigs for this. I'm not sure if there's some kind of bottleneck im not aware of though.

That's a shame. I didn't realize it was that locked down. Ive had a lot of terrible routers but all the ones I remember allowed me at least a port forward.

I think OP can accomplish some of the same result if he can get a cheap VPS to connect through (have the laptop Wireguard to the VPS, then have a proxy on the VPS forward to the laptop over the VPN, but that's probably not worth the hassle for a starter project unfortunately.

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.

3D Printing and homelab. I run a lot of services at home on my server (things like a personal streaming service, smarthome, security camera software, and more).

With most consumer wifi networks you can usually enable port forwarding. That would let you access services from anywhere.

Personally I would set up a Wireguard VPN server on the laptop and enable port forwarding only for the Wireguard port. This will let you access your laptop from anywhere, and it will protect you by limiting your attack surface (basically you only need to have a device Wireguard connection and you don't need to worry as much about securing every other service you want to run).

Then I'd set up dynamic DNS with any DNS provider so you don't need to keep track of a changing IP.

Then you can install whatever services you want on the laptop and you'll be able to access them from anywhere by connecting to the Wireguard VPN. It does mean you can't easily let a friend access a service on your laptop, but the tradeoff is you don't have to worry as much about security while you're learning.

It's especially weird when the existing targeting can be so effective for much cheaper.

For tvs for example, they can see what you watch, when, what ads you mute and which you don't, what you display over HDMI (content ID), the other devices on your network, your location, your accounts for every streaming service, what you search for. Then if you install their companion app they learn the other apps on your phone, your location habits, the media you play on your phone (looking at you Bose connect app...), bluetooth and network devices you are near (connecting you to other profiles they know), and probably a lot more.

Maybe. They might do some processing locally and just upload as text so it might be easy to batch the data, making the upload volume and pattern less obvious.

It also saves them network bandwidth so I'm sure that would motivate them too. Uploading raw mic data from all TVs would be expensive.

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.

"stuff"

Sourcetree is still best by far for history browsing, and I'll die on that hill.