Readit NewsRsync is great as there is a clear master copy. But if changes may happen at any copy of the data, it can become a chore.
Dead Comment
Dead Comment
I never use those. I suspect that in many cases if there are "legitimate interest" options¹ those will remain opted-in.
----
[1] which I read as "we see your preference not to be stalked online, but fuck you and your silly little preferences we want to anyway"
Going public with that was a bold call - CIA put its reputation on the line. But Ukraine was more prepared because of it - and so were its allies.
A lot of Ukrainian officials didn't believe that the war was about to start up until the moment it did. Imagine how much worse the situation could have been without US beating the drum.
If you have invented the disease, then surely you can warn in advance that a cure will be needed.
if a rich audiophile replaces his speakers every year with the latest and greatest, and his old speakers get passed down the food chain to other audiophiles with lower budgets, what falls off the other end of the chain is a very old speaker which whose carbon foot print has been amortized over 10 years or more, and a better listening experience for everybody in between, and perhaps even speakers for people who would not otherwise even have them who picked them up at Goodwill.
also, a healthier industry with more employment for folks who won't have much employment if they only sell a pair of speakers every 10 years.
And repairability just means that the industry can move people from manufacturing to service and support.
But to test things, I would need instances of model classes. However, I didn't want to have to specify all the required fields every time I needed an instance for a test. The fields might be mandatory, but not always relevant for each test. Such a field needs to be filled, but not necessarily by me in the test code. I knew from earlier projects, that Faker generates random data and in the past I have thought it shouldn't be difficult to write a thing that generates random strings and numbers and ids for fields, and recursively other required entities. So I decided to write it myself [1], rather than introducing factory boy and faker as dependencies.
Sure those libraries will have a lot more features, but my code is simple and does what I need and I gained additional understanding of the complications with Django's model handling.
I also suspect, that factory boy has to hack around some issues, that I avoided by always creating entities in the database, which most of my code is doing anyway. I am not sure how they solved creating instances of models, that have many to many fields without persisting the entities in the database for example, because Django raises an error when one tries to do set a value for such a many to many field, without storing the entity in the database first, so that it gets an id. Which makes sense. So I suspect there is quite some magic in that dependency, that I don't need for now.
What's more is, that my factory functions are just as easy to use, if not easier. I simply do `factory_for_model(MyModel)(kwargs)`. It is also easy to add more functionality like `gen_multiple(factory, count)` for example. Uniqueness is more difficult, due to how Django's fields and models are compared. But as far as I understand neither does Faker do uniqueness out of the box. I may be wrong about that though.
I also developed a decorator for pytest functions, that helps me avoiding long test names and instead puts a test description in the decorator arguments. Those sentence long test names have previously annoyed me and always caused linting to attack me for it.
[1]: https://codeberg.org/ZelphirKaltstahl/web-app-vocabulary-tra...
For standardized things like testing, I'm not sure if DIY makes sense. Even if you use 10% of its capabilities, sticking with an established test framework makes your codebase more maintainable and easier for others to contribute to.
[1] https://docs.syncthing.net/users/versioning.html