Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
JhonDoe30742yWsl + docker was a good option for me until I ditched windows again
That's why you develop for and on windows. It always works
lbfalvy86322y@shoop Unless when it doesn't, which is about every other month. Not too bad for desktop but unacceptable for server.
lbfalvy86322ySeriously, no matter how hard MS tries, Windows will never beat Linux in one thing: stability when managed by an expert. Indeed, Windows is more stable when a reckless user installs all sort of shit, but a server isn't like that, and it occurs to me that MS had understood that already.
bahua132102yI cannot work without a dev environment that's largely identical to the prod environment, accessible at the exact same URL, with "dev." prepended. I SSH to the dev env, make my edits to the code that's actually running the software in dev, and hit F5 in a browser to see it update. Commit and push to the dev branch so other can test and give feedback, and merge with master when it's ready.
I just cannot wrap my head around the idea of development on a desktop with a big shiny graphical desktop app, like an IDE. It just feels like a hack, to accommodate bad practices.
> I cannot work without a dev environment that's largely identical to the prod environment, accessible at the exact same URL
If you stop there that's also a very common development strategy :D.
Also the old have it running on prod but different sub or path, IE, /appv2/.
You don't need to change everything through ssh, you can use X11 for windows though more commonly you would just share a folder.
There is a caveat that folder sharing can depending how you do it have various limitations.
My problem with working with some people who use Windows for development for a Linux server is their inability to document their modifications when they transfer their code to the server. I've seen incomplete code or lots of unnecessary code pushed to repositories because someone transferred their code to the server, it didn't work, did some configurations, and forgot about the configurations they made. Now anyone who clones the repository has to suffer the headache of making something that works in production work in their development environment.
Two days ago (previous rant), a Windows user accused me of having a huge ego and doing hacky shit because I was working on Linux. I was just using the shell in the platform where we deploy, the same shell they transfer their code to. I humored him and tried his Windows setup, it didn't work. It turns out he never got it to work and he's the one bending over backwards doing hacky shit to glue things together. I made it work, he didn't.
@Lor-inc This. I hate this fucking shit. Always when I'm working with someone, they tell me "there's a trick to make it work". A "trick" to make something work that isn't supposed to work there "work". Then they run around advising people to follow their setup until everyone's rectum is full of bloated shit they don't even need. Then of course, they push their "tricks" into the server and into the repositories so every future generation of developers can inherit the cancer they started. Fuck this field sometimes.
I am currently working in a Qt + mostly Linux shop. I have found that programs developed using Qt will run on Windows and Linux without changes (for the most part). I am impressed by how much they have abstracted that interface. I am currently developing some industrial servers for automation using Qts command line interface objects. This has been a very straightforward experience.
So another strategy may be to use a decent abstraction, hopefully maintained by someone else (reduced cost). Also, we settle on one compiler (gcc/g++ or mingw in windows). This also helps.
@Lor-inc as much as I want to disagree and argue, that is true.