Same, I think deals on the lifetime pass still show up periodically, but I got it when it was about $40 too. It’s good software I use daily, so I’m happy with it.

Looks like on the last deal it was $120

Currently it is $250, which is too rich for my blood. Then again I just paid $70 for Doom the dark ages

If a new project doesn’t come out called rockets impose I’ll be disappointed .

The rhythm of TDD is to first write a failing test. That starts driving the design of your production code. To do that you need to invoke a function/method with arguments that responds with an expected answer.

At that point you’ve started naming things, designing the interface of the unit being tested, and you’ve provided at least one example.

Let’s say you need a method like isEven(int number): Boolean. I’d start with asserting 2 is even in my first test case.

To pass that, I can jump to number % 2 == 0. Or, I can just return true. Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.

Now I am forced to write a test for odd input, so I assert 3 is not even. This test fails, because it currently just returns true. Now I must implement a solution that handles even and odd inputs correctly; I know modulus is the answer, so I use it now. Now both tests pass.

Then I think about other interesting cases: 0, negative ints, integer max/min, etc. I write tests for each of them, the modulus operator holds up. Great. Any refactoring to do? Nope. It’s a one-liner.

The whole process for this function would only add a few minutes of development, since the implementation is trivial. The test runtime should take milliseconds or less, and now there is documentation for the next developer that comes along. They can see what I considered (and what I didn’t), and how to use it.

Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level. That’s outside the scope of this lemmy interaction.

The monkey at the keyboard thinking is what software development is. When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.

In this case that is using math to check if the input is divisible by two without a remainder. If you don’t know how that works, you’re going to have a bad time, like the picture in this post.

TDD doesn’t promise to drive the final implementation at the unit level, but it does document how the class under test behaves and how to use it.

Read the article about property based testing. It is the middle ground between what you are describing and practicality.

I often pair with myself, which sounds silly but you can write failing tests by yourself, it just isn’t as fun.

In a world where this needs to be solved with TDD there are a few approaches.

If you were pair programming, your pair could always create a new failing test with the current implementation.

Realistically I would want tests for the interesting cases like zero, positive even, negative even, and the odds.

Another approach would be property based testing. One could create sequence generators that randomly generate even or odd numbers and tests the function with those known sequences. I don’t typically use this approach, but it would be a good fit here.

Really in pair programming, your pair would get sick of your crap if you were writing code like this, remind you of all the work you need to get done this week, and you’d end up using modulus and move on quickly.

TDD has cycles of red, green, refactor. This has neither been refactored nor tested. You can tell by the duplication and the fact that it can’t pass all test cases.

If this looks like TDD to you, I’m sorry that is your experience. Good results with TDD are not guaranteed, you still have to be a strong developer and think through the solution.

You would probably be able to run it. It will run like crap, but it will likely start. Postgres can run on as little as 8mb of ram, but not well. I’d recommend a box with at least 2gb of ram if you want to spin up multiple containers.

sqlite would probably be a better choice on an aging pi, but I’m sure you have your reasons.

Personally I wouldn’t worry too much about where you mount the volume, I use /storage on my boxes because I is easy to remember and sounds good to me. I also typically make a storage group that I give access to manage the files in the volume vs having my user own everything.

I wouldn’t put it in home just because you are considering sharing with others.

This! Uncle Bob is a garbage person. Used to really respect him, but F that guy.

It really is more of a visual medium. A picture is worth a thousand words after all!

Printing Butt is fun and all, but if I’m at the point of logging nonsense, it is usually a stronger word.

It’s not very sexy, but I just use SFTP and filezilla. Filezilla is available for all the major operating systems, and an ssh server is basically required anyways.

I enjoy Ubuntu server. At the end of the day I just want something simple. I run most of my services in docker compose, and zfs for the filesystem.