Hacker News Reader

Comment by vegancap | Hacker News Reader

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.

View on HN

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.

"Remote Server" Doesn't necessarily mean "Production Server"

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.

A Vagrant or Docker VM is still remote as far as the local desktop is concerned.

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.

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?

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).

and do that for every project, even small throwaway experiments?

If it's a throwaway experiment, it shouldn't take too long to compile locally, I would think.

That's a remote workstation, not really a server. You should keep these two separate.

Reply on news.ycombinator.com