fun fact comment, Asimov thought about this, I'm quoting the short part that is relevant from this article on wikipedia :https://en.wikipedia.org/wiki/Foundation_series
"One key feature of Seldon's theory, which has proved influential in real-world social science,[3] is the uncertainty principle: if a population gains knowledge of its predicted behavior, its self-aware collective actions become unpredictable."
You are making judgments about OP using Docker. But from my point of view you are a true pain to work with because you do not containerise your work. Anytime I'd have to work with one of your creations I'd have to go figure what you are using, set it up and make sure it works. That's a waste of time and you are promoting that very fact because you were unable to figure any usage for it. I doubt OP has only "read some blog post about it somehwere" It's literally wide in usage by a lot of companies. "People who like Docker often seem to be working in larger teams, which is totally fine and they're probably right to use Docker." -> it's actually about that, it is useful is scaling that's true, but it's also very useful just to share the env your software should work with. And I'd dare to say that giving a Dockerfile is now standard practice.
You're judging my code without ever having seen it, nor knowing the context of my projects. You won't have to work with my creations because as I explained my projects usually involve just me. As I also explained above, i think Docker can make sense in companies. And re "standard practice", I like to make decisions on what's best for each project, not by dogma.
What if you want to run the code on a different architecture? In that case isn't it better to document which "pip install" etc. you have to perform to get it running? And from there do you really still need docker?
"Just use the same Python version and a roughly similar PostgreSQL version in development and production, and you're good to go" -> And that's more time than it would take to re-use that Dockerfile and docker-compose that i literally wrote once and go to once in a while.
Having a React / Vue whatever in addition to your Django server allow you to split the "View" from the "Model-View-Control" paradigm that Django respect, when you have django & react, Django is only "MC" and react becomes "V"
Simply put, when you are in the template paradigm you are producing HTML files, when you are using React you are generating HTML.
For instance, I'm not building up an "account" page, i'm building up a "detail" page that can be reused with a query that I'm passing in. That query is a function that defines the call to Django. Eventually I'm passing parameters to the component to drive it's behaviour.
I'd simply suggest you to go learn some react, it is difficult and it takes time, but it will allow you to see more solutions to problems that you might be handling in the "industrial" way (eg: writing 10 templates and having some jquery mixxed in the html)
I've been working with django and react for a while now, and i'm now used to 100% coverage without much hassle and very good productivity (dare I cite my boss :) )
"I don't want to go full SPA with Django as this defeats the purpose of Django IMO" -> What is this "purpose" ? Django is here to help me model my database, handle few permissions and bring few API up online, I see no problem with having a PWA in front of it. Are you trying to get all of your website server rendered ? In which case you could do that without having to worry about integrating it with Django... TBH after 5 years of react and 8 of Django, i'm just not mixxing them up except for the front-end calling a query on the back-end (which both can be served at the same domain using nginx) ;
Honestly in the real world you would generally already know if the need expressed is meant to be a web service (for instance) and if it requires a database - and in those cases, most framework already propose an sqlite / fully-fleged database in the same code.
If we already know that a database might be required later then using something like sqlite straight is smart move that would allow you to write code that is instantly going to work when you actually need something fully fledged instead of re-writing it.
Knowing if you need a database or not is simply one of the first things you know, and writing code before setting that up is a waste of time or a learning process.
It is not whether you need a database or not. It is "how configurable/dynamic things should be". More configurability usually means more power to your users and more pain to maintain the software. So I usually go to the least amount of configurability and then add things when required.
The same goes for abstractions (you often need more of them when things becomes more configurable)
Simplicity is what strikes the brightest of minds, some prefer to have simple shortcuts and a tone of sh*tware that prevent the user from knowing how to use it's tools (git, configuring an IDE), some prefer to have something they can master over the years, is standard in the industry, and that doesn't induce tons of un-controlled behaviours.
What are you talking about ? Most people working with sound today do so by using a DAW like Ableton, QBase or Fruity Loop that work on Windows or sometimes Mac Os
They're not hard-realtime, so they definitely can miss a few samples. You can workaround that by reconfiguring an external device rather than generating the samples locally, but that's not what Ableton or FL do.
Win and Mac have soft-realtime scheduling and the mentioned software does what it can without guarantees https://help.ableton.com/hc/en-us/articles/209072289-How-to-... I've been to a live gig before where the performance was paused a few times because artist's mac was misbehaving.
