Adopting EVs is an important step imo. The primary achievement of going EV is reducing oil/gas use. Moving away from cars as a society is a separate goal that can happen alongside this. We can never make gas green, at best net zero. EVs on the other hand can be better, with electricity from renewable sources, to batteries made with better materials. Both things which are happening and actively being researched.

So we can make EVs much better environmentally, and reduce gas demand significantly alongside reducing car use. Because we won't just stop needing gas magically, so replacing that is important for any transition away from it in the grand scheme.

I'm just a noob when it comes to low level languages, having only been in C# and python. But I took a course on C++ and encountered something that didn't seem right. And I asked and got the "that's undefined behavior". And that didn't quite sit tight with me. We don't know what will happen? It'll probably crash? Or worse? How can one not know how a programming language will perform? I felt it was wrong.

Now, it's quite some time since that happened, and I understand why it's undefined. But I still do not think it should be allowed by default. C and C++ both are "free to do as you want" languages, but I don't think a language should let you do something that's undefined especially if you aren't aware you're doing it. Everyone makes mistakes, even stupid ones. If we can make a place where undefined behavior simply won't happen, why not go there? If you need some special tricks, you can always drop the guard where you need it. I guess I'm just reiterating the article here though. But that's the point for me, if something can enforce "defined behavior" by default then I'd want that.

I'm not sure how you do it at the moment or already know this since you mention repository pattern. But here's how I know.

A pattern I encountered at my workplace is a split between the repository and the data access (Dao) layer.

The repository implements an interface which other parts of your program uses to get data. The repository askes the data access layer to make database calls.

For testing other parts of the programs, we mock the repository interface, and implement simple returns of data instead of relying on the database at all. Then we have full control of what goes in and out of your legacy code, assuming you are able to use this.

For testing the dao, I don't actually have much experience since that's not a good option for us at the moment, but as others mentioned you can use in memory databases or manually mock the connection object provided to the dao to test that your save methods store the correct data. The latter being somewhat clunky in my experience but the best option when you are trying to save something with 20 values and making sure they end up in the right order or have the right values when converting enum values to strings for example.

I don't know much about cache, but if you want to keep it then it's possible to do it in the repository class.

I saw these magic windows on my computer, and I too wanted the godlike power to control how they worked and what the buttons did. I looked into Python, then started University and they also taught us Python for science use. With exception of a C++ class, I self learned and used it, then managed to convince a company to hire me to develop, despite being a chemical engineer.

My first program was a GUI wrapper for YouTube-dl, and I still use it frequently.

It still makes sense, no?