

True, but at that point, every website I’ll ever visit and have visited in the past might be a threat, so that doesn’t really matter too much to me.
True, but at that point, every website I’ll ever visit and have visited in the past might be a threat, so that doesn’t really matter too much to me.
I’ve got several hits, but none of them have permission to request my location. If I understand the README correctly, that should mean I’m safe, right?
If you want the magic explained, here’s a start: https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch
Well, what problems are you trying to solve by having the classes all access each other’s data members? Why is that necessary?
Late reply, but for me personally, I started doing it because my Keepass database is already accessed using two factors (password and key file). Therefore, I’d gain very little by keeping the second factor of those sites external - essentially, those second factors are compounded into the second factor for the database.
There are two different things mentioned here, which I feel I need to clarify:
First, what you said about merging / creating a PR with broken tests. Absolutely you shouldn’t do that, because you should only merge once the feature is finished. If a test doesn’t work, then either it’s testing for the wrong aspect and should be rewritten, or the functionality doesn’t work 100% yet, so the feature isn’t ready to get merged. Even if you’re waiting for some other feature to get ready, because you need to integrate it or something, you’re still waiting, so the feature isn’t ready.
At the same time, the OP’s point about tests being supposed to fail at first isn’t too far off the mark either, because that’s precisely how TDD works. If you’re applying that philosophy (which I personally condone), then that’s exactly what you do: Write the test first, checking for expected behaviour (which is taken from the specification), which will obviously fail, and only then write the code implementing that behaviour.
But, even then, that failing test should be contained to e.g. the feature branch you’re working on, never going in a PR while it’s still failing.
Once that feature has been merged, then yes, the test should never fail again, because that indicates a new change having sabotaged some area of that feature. Even if the new feature is considered “essential” or “high priority” while the old feature is not, ignoring the failure is one of the easiest ways to build up technical debt, so you should damn well fix that now.