▲ 389 ▼ Microsoft announces Project Zenith, a clutter-free Windows experience meant to entice developers - Engadget (www.engadget.com) submitted 3 weeks ago by Wispy2891@lemmy.world to c/technology@lemmy.world 98 comments fedilink hide all child comments 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" 😸
[–] partofthevoice@lemmy.zip 0 points 3 weeks ago* (last edited 3 weeks ago) (5 children) . permalink fedilink source parent hideshow 5 child comments replies: [–] Vlyn@lemmy.zip 10 points 3 weeks ago 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. permalink fedilink source parent [–] hdsrob@lemmy.world 6 points 3 weeks ago* (3 children) Why an RDBMS on the local though? Testing shit doesn’t make sense to name it as a regular piece of software. 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. permalink fedilink source parent hideshow 3 child comments replies: [+] partofthevoice@lemmy.zip 0 points 3 weeks ago* (2 children) [deleted] permalink fedilink source parent hideshow 2 child comments replies: [–] hdsrob@lemmy.world 5 points 3 weeks ago 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. permalink fedilink source parent [–] 4am@lemmy.zip 4 points 3 weeks ago 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 permalink fedilink source parent
[–] Vlyn@lemmy.zip 10 points 3 weeks ago 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. permalink fedilink source parent
[–] hdsrob@lemmy.world 6 points 3 weeks ago* (3 children) Why an RDBMS on the local though? Testing shit doesn’t make sense to name it as a regular piece of software. 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. permalink fedilink source parent hideshow 3 child comments replies: [+] partofthevoice@lemmy.zip 0 points 3 weeks ago* (2 children) [deleted] permalink fedilink source parent hideshow 2 child comments replies: [–] hdsrob@lemmy.world 5 points 3 weeks ago 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. permalink fedilink source parent [–] 4am@lemmy.zip 4 points 3 weeks ago 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 permalink fedilink source parent
[+] partofthevoice@lemmy.zip 0 points 3 weeks ago* (2 children) [deleted] permalink fedilink source parent hideshow 2 child comments replies: [–] hdsrob@lemmy.world 5 points 3 weeks ago 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. permalink fedilink source parent [–] 4am@lemmy.zip 4 points 3 weeks ago 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 permalink fedilink source parent
[–] hdsrob@lemmy.world 5 points 3 weeks ago 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. permalink fedilink source parent
[–] 4am@lemmy.zip 4 points 3 weeks ago 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 permalink fedilink source parent