14

When you're developing it's very well advised to run your software locally in an environment as much as possible matching the real environment.

So for example, if you're running linux on production then you also run it locally to run your code.

Here's where people need to shut the fuck up:

No, mac is not good for linux development. Not unless portability is already a concern that you have and even then it might be counter productive. So many times when people say this, portability isn't not a concern. What runs on servers is up to them.

If your servers are going to be centos, then you develop with centos. Not with debian, gentoo, ubuntu, maxosx, etc.

Even different linux distros are a headache for portability when it's just to support a few desktops for development so don't think that macosx is going to cut it. It might not be as radical a difference as between windows and linux traditionally is but it's still not good for "linux" development. I don't think people making that statement really know what linux is now how different distributions work.

What you use for your graphical operating system doesn't matter to much but when you run your code then there's a simple solution.

Another thing people need to shut up about. It's not docker, unless you're already in Linux where docker is one of many options such as chroot or lxc.

This question always comes up, how do you developer for linux in windows? No it's not docker it's virtual machine.

It's that simple. You download the ISO for the distro you want and then install it on a VM. What does docker for windows do? It runs a linux VM that runs docker.

This may come as a great shock to developers around the world but it is possible to run linux in a VM and then any linux application your want including docker.

Another option is to shove a box in the corner, install what you need on it, share the file system and have people use that to run their code. It really is that easy.

Comments
  • 0
    Wsl + docker was a good option for me until I ditched windows again
  • 1
    That's why you develop for and on windows. It always works
  • 4
    @shoop Unless when it doesn't, which is about every other month. Not too bad for desktop but unacceptable for server.
  • 2
    Seriously, 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.
  • 2
    I 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.
  • 1
    > 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.
  • 0
    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.
  • 1
    @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.
  • 0
    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.
  • 0
    @Lor-inc as much as I want to disagree and argue, that is true.
Add Comment