6 ms·

I'd argue you shouldn't be working on remote servers at all. Ideally you should be working locally and deploy using Capistrano, Jenkins, Bamboo or git hooks etc

I'd argue you shouldn't be working on remote servers at all. Ideally you should be working locally and deploy using Capistrano, Jenkins, Bamboo or git hooks etc.

filsmick 12y ago
Sure, that's ideal, but what if you have a small laptop? It would be nice to make use of the power of your server to compile more quickly, and speed up your development cycle, right?
- simon_vetter 12y ago
  have a buildbot/jenkins set up which runs your test suite on a buildslave automatically when you push to a git branch? I would still run my editor locally (your pick. I use vim almost exclusively).
  - filsmick 12y ago
    and do that for every project, even small throwaway experiments?
    - QuercusMax 12y ago
      If it's a throwaway experiment, it shouldn't take too long to compile locally, I would think.
- simonebrunozzi 12y ago
  That's a remote workstation, not really a server. You should keep these two separate.
mdekkers 12y ago
"Remote Server" Doesn't necessarily mean "Production Server"
- vegancap 12y ago
  True, but wouldn't you use Vagrant, Doccker or something similar to develop on? Can't speak for the OP's situation, but it seems a strange set-up that's all.
  - moe 12y ago
    A Vagrant or Docker VM is still remote as far as the local desktop is concerned.
scott_s 12y ago
I work exclusively on remote servers. My remote "servers" are a 500 node cluster, and I do research and development for a parallel and distributed language and runtime system. The remote systems are setup for development, are managed by full-time staff, and continuously backed up. Not everyone has the same workflow, partly because not everyone has the same work.
duaneb 12y ago
Sure, and hope that you never have to ssh into a hung box to figure out what went haywire. You're entirely missing the point; there are reasons to manually make contact with a server aside from deploying.

6 ms·

I'd argue you shouldn't be working on remote servers at all. Ideally you should be working locally and deploy using Capistrano, Jenkins, Bamboo or git hooks etc

by vegancap 12y ago

I'd argue you shouldn't be working on remote servers at all. Ideally you should be working locally and deploy using Capistrano, Jenkins, Bamboo or git hooks etc.

filsmick 12y ago
Sure, that's ideal, but what if you have a small laptop? It would be nice to make use of the power of your server to compile more quickly, and speed up your development cycle, right?
- simon_vetter 12y ago
  have a buildbot/jenkins set up which runs your test suite on a buildslave automatically when you push to a git branch? I would still run my editor locally (your pick. I use vim almost exclusively).
  - filsmick 12y ago
    and do that for every project, even small throwaway experiments?
    - QuercusMax 12y ago
      If it's a throwaway experiment, it shouldn't take too long to compile locally, I would think.
- simonebrunozzi 12y ago
  That's a remote workstation, not really a server. You should keep these two separate.
mdekkers 12y ago
"Remote Server" Doesn't necessarily mean "Production Server"
- vegancap 12y ago
  True, but wouldn't you use Vagrant, Doccker or something similar to develop on? Can't speak for the OP's situation, but it seems a strange set-up that's all.
  - moe 12y ago
    A Vagrant or Docker VM is still remote as far as the local desktop is concerned.
scott_s 12y ago
I work exclusively on remote servers. My remote "servers" are a 500 node cluster, and I do research and development for a parallel and distributed language and runtime system. The remote systems are setup for development, are managed by full-time staff, and continuously backed up. Not everyone has the same workflow, partly because not everyone has the same work.
duaneb 12y ago
Sure, and hope that you never have to ssh into a hung box to figure out what went haywire. You're entirely missing the point; there are reasons to manually make contact with a server aside from deploying.