▲ 352 ▼ Microsoft announces Project Zenith, a clutter-free Windows experience meant to entice developers - Engadget (www.engadget.com) submitted 1 day ago by Wispy2891@lemmy.world to c/technology@lemmy.world 90 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 1 day ago* (last edited 4 hours ago) (2 children) . permalink fedilink source parent hideshow 4 child comments replies: [–] Vlyn@lemmy.zip 9 points 1 day 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 1 day ago* (1 child) 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 2 child comments replies: [+] partofthevoice@lemmy.zip 0 points 1 day ago* (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] hdsrob@lemmy.world 5 points 1 day 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 3 points 1 day 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 9 points 1 day 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 1 day ago* (1 child) 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 2 child comments replies: [+] partofthevoice@lemmy.zip 0 points 1 day ago* (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] hdsrob@lemmy.world 5 points 1 day 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 3 points 1 day 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 1 day ago* (2 children) [deleted] permalink fedilink source parent hideshow 4 child comments replies: [–] hdsrob@lemmy.world 5 points 1 day 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 3 points 1 day 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 1 day 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 3 points 1 day 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