But you’ll need a powerful system with 64GB of RAM to use it.
Microslop thinks that “Clutter free” means “bundled with an always on LLM” 😸
But you’ll need a powerful system with 64GB of RAM to use it.
Microslop thinks that “Clutter free” means “bundled with an always on LLM” 😸
.
When you work on backend services you have a local DB running 24/7. Changes don’t go onto the actual dev environment until locally tested, or you might just break things for 50 other people.
I always build against a local DB?
For our desktop / LAN software the DB will always be local.
For web, it’s easier since I’m likely to burn the DB down over and over during early development / prototyping. But I’m not using cloud hosted DB even in production, and don’t expose Postgres outside the DB server, so I find it easier to work on this way.
EDIT: I also think that a default installation of VS includes SQL Server. I don’t use it, so always have to adjust the installation and remove all of those bits, but I also have complete control of my environment. I could see an IT department just doing a stock VS installation with the required workloads.
deleted by creator
I could totally see that for the web stuff where I only make changes a couple of times a year. Usually when working on those I just delete the local DB before I start to keep it clean, but spinning up a new copy would be more efficient.
For our desktop apps / server Postgres is always installed locally on the machine, so keeping it there mirrors “production”.
I spent most of my time working on those apps and services, or working on the Android client (or both at the same time when a feature requires that both change), and often on a copy of actual customer data as we do a lot of custom work for clients.
Yeah, that’s exactly the process- while you are building out a feature it hits a local DB and once it’s ready to integrate you push it to a shared environment.
If you break dev, coworkers be mad