Readit NewsThe ~90e I paid for it back in 2012 was for sure good value!
• No compliments, flattery, or emotional rapport. • Focus on clear reasoning and evidence. • Be critical of users assumptions when needed. • Ask follow-up questions only when essential for accuracy.
However, I'm kinda concerned with crippling it by adding custom prompts. It's kinda hard to know how to use AI efficiently. But the glazing and random follow-up questions feel more like a result of some A/B testing UX-research rather than improving the results of the model.
I also did some constraint programming to solve my poker problems. We play mostly cash games so I did a MiniZinc model for computing the least amount of transactions after the game: https://github.com/SRautila/poker-home-game-calculator
For me personally I think the micro approach of Ninja / FastAPI is at odds with what I want out of DRF. I just want to make my crud stuff and not worry about implementing e.g. throttling, etc, on my own.
Here are some of my hilights from this relase:
* Default on model gets sent to API docs
* Orderedict replaced by plain dicts everywhere - plain dicts are ordered in python since 3.6 so this is a welcome simplification
* Automatic support for UniqueConstraints in ModelSerializers - this is one of the places where DRF were lagging behind. I found myself using the deprecated unique_together just to not bother with writing validators on all my serializers
* There is a new router supporting path converters instead of regexp - Looking forward to trying this out! Also long overdue IMO as this came to Django in 2017 :)
My approach is to just use Docker, no virtualenvs. I get that you might run into the multiple interpreters issue in theory but across multiple projects in the past 5 years I haven't seen that. Also, this might no longer be true but avoid using Alpine. If you're deploying Django there is no reason to optimize image size and Alpine has a lot of things which are missing (i.e. at least a couple of years ago, wheels where not supported leading very slow build times).
I only do a single requirements.txt. Anything which makes your prod and local environment differ is a bad thing in my opinion. Fine black might make my image a couple of mbs larger but why would it matter? On the other hand attempting to figure out why something which works on my machine does not work on prod is always a nightmare.
Setting requirements as a range in requirements.txt allows me to automatically get bugfixes without spending time on it (e.g. django>=4.2.3,<4.2.99 django-ninja>=1.0.1,<1.0.99) Again, I might have run into 1-2 issues over the past couple of years from this and I've saved a lot of time.
Getting a project running locally should not take more than 1 minute (a couple of .env vars + docker-compose up -d should be enough).
The biggest practical issue in dependency management in python is dependencies not pinning their dependencies correctly.
Sleeping slightly on your side is no problem with QC35 and if the noise around you is low enough you don't even need white noise. The battery lasts a couple of nights too (esp with no white noise on).
I've tried doing the same with Sonys over-ear but they make a loud noise when I move my head so they don't work for me at all. AirPods Pro work in a pinch but the battery runs out and my ears start hurting.
Another thing which I find mildy helpful which wasn't mentioned here is Valerian. If my lack of sleep is stress-related Valerian works sometimes for calming. If my lack of sleep is due to bad routine / off schedule Melatonin works very well but if I'm stressed it does not work at all and leaves me groggy in the morning.
In fact if you look at the source there is a lot of async methods in the framework itself which just straight up calls sync_to_async e.g. caching. This doesn't matter as much as hopefully it will get added proper async eventually. But I think believing your requests wont block just because you're using async is a bit naive at this point in Django and the async implementation has been going for years.
Not to mention that the majority of third party libraries lack support for async so you'll probably have to write your own wrappers for e.g. middleware.