I wish they just didn’t give out crappy plastic toys at all.

It’s the default for a reason.

This is clearly a form letter that was hastily sent without due diligence.

The EU is not a country. A normie on the street might think of it as one, but the US government should understand / recognize the nuance. Whether this was a subtle dig or incompetence I’m not sure. Probably both.

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.

I’ll get up and go to another room. Try to read or do something until I get sleepy and try again.

Can you share your smb.conf?

Clear concise code that reads like documentation is the ideal. Good function and variable names, formatting, and encapsulation play into this. Tests should document and describe the system.

If it still isn’t clear what the code is doing, and I’m all out of ideas (or time) for refactoring, a well placed, accurate comment is fine. It needs to be kept up to date like any other artifact in the project.

It’s harder to keep comments accurate than code, since code can be executed and tested. I use them sparingly; when I’ve otherwise failed to write clean code, or the code is just so complex that it needs to be described.

Comments are just another tool in the toolbox. If they add clarity to the situation, by all means, use them.

If you can think of an expressive variable name that lets you skip a comment eg “employeeCount”, instead of “e” // number of employees, do that.

Probably try to get my identity back. I’m not trying to escape anything currently, and not having documentation is a dangerous thing in the world these days.

Til https://www.merriam-webster.com/grammar/jerry-built-vs-jury-rigged-vs-jerry-rigged-usage-history

I’m usually for personal choice, but smoking needs to go. Good job France.

Oddly this year they are really prevalent in my area. In prior years I haven’t seen nearly as many.

I’m intentionally avoiding lawn treatments and insecticides this year. I love my yard, but I’m also thinking about switching to clover.

I ran it for a while, and loved it. Cinnamon is sleek and feels polished. The installation is really fast and not bloated with garbage software.

Everything generally works, and the interface feels familiar.

It is Ubuntu/Debian under the hood, so compatibility with most software is good. Bleeding edge drivers may run into issues, but most of them work with a little fiddling.

It’s worth a try. If nothing else toss it on a USB drive and give it a test drive.

Some browsers have built in fingerprint resistance techniques you can enable:

https://support.mozilla.org/en-US/kb/resist-fingerprinting

I wouldn’t entirely trust it, but enabling this feature in strict mode would tick a few of your listed boxes.

More than you’d ever want to know: https://en.m.wikipedia.org/wiki/Let_expression

Brother laser gang here – highly recommend. I print a handful of things every year and it hasn’t let me down. Still rocking the original toner and I bought it in 2021.

I recently drove eight hours on a trip. It’s brutal, but you’ll be fine.

• download offline maps on your phone
• get lots of music, podcasts, and things to keep entertained
• stop every few hours to stretch your legs, use the bathroom, and maybe get something to eat
• be aware of your route. Think about where you can stop. Be ready for construction and other unexpected delays.
• check your tire pressure before you leave (especially the spare!)
• make sure you have basic stuff like a jack and jumper cables
• make sure you have your license, insurance, and registration
• if you can afford it, dashcams are nice to have