No need for dotfiles or tools on the remote.
Ask HN: How do you work efficiently on remote servers?
71–80 of 87 posts
Re: Ask HN: How do you work efficiently on remote servers?
#72I see no reason to develop on a server. If that's what you're doing, that's a very bad sign in most of the cases.
Re: Ask HN: How do you work efficiently on remote servers?
#73Since a few people mentioned Vagrant: can I use it to set up a production environment locally, with all the system dependencies, configuration files, and then pushing it to production? If so, is this the recommended approach?
Re: Ask HN: How do you work efficiently on remote servers?
#74In particular, the Twelve Factor App (http://12factor.net/) (by the founder of Heroku) had a big impact in my thinking of how to remotely deploy and administer. In particular "1. One codebase tracked in revision control, many deploys" and "X. Keep development, staging, and production as similar as possible". Note that these approaches are applicable to any hosting provider and technology.
Now, there are times (especially when you're debugging a breakdown in dev/prod parity) where it is enormously helpful to ssh into a remote machine. But I would endeavor to minimize those occurrences.
Re: Ask HN: How do you work efficiently on remote servers?
#75Earlier quoted context omitted.
Why you think is that? Could you, please, elaborate?
Sure. Couple of scenarios where I've seen people working on a server and why that's bad: 1) The developers in this company that work with ColdFusion develop their software on a dev server because they would otherwise require expensive licenses for each dev machine. This means that devs often find themselves editting the same file. It also means that one dev can break the software for all other devs. Last but not leas…
Re: Ask HN: How do you work efficiently on remote servers?
#76I use ssh + tmux + emacs. Security policy states no local copies of development files are allowed at my workplace without special authorization, which I never bothered asking for. Migrated my emacs configuration to the remote server as a git repository, along with any programs that aren't available (e.g. git, which I use for unofficial code; official code is managed via perforce). Use GNU stow to move those configura…
[N]o local copies of development files are allowed ... without special authorization I'm curious what kind of employer would hire programmers, and they tell them they couldn't develop locally as a matter of _security policy_, rather than "it won't fit on your machine". That seems like it would be very constraining.
Re: Ask HN: How do you work efficiently on remote servers?
#77As for tools, well vim is my default editor so:
vim (really lots of plugins, themes, extension support, personal .rc, etc.) + tmux (tmuxinator for projects) + ssh (heavy user, I use sockets to keep the connection up, use keys-only access, fine-tune the algorithms I use, etc.).
Re: Ask HN: How do you work efficiently on remote servers?
#78mosh + tmux + emacs I can't believe how few people mentioned mosh. I work on remote boxes "across the pond" all the time and it makes a huge difference. Laptop going to standby, VPN dropping, slow connection, all handled perfectly.
Re: Ask HN: How do you work efficiently on remote servers?
#79FTP? People still use FTP??? That's a protocol from another era, was designed to work in a way that's not compliant with today's best practices. The only FTP server I have runs on a Raspberry Pi file-server I have at home. There's no firewall in that little gem running. As for tools, well vim is my default editor so: vim (really lots of plugins, themes, extension support, personal .rc, etc.) + tmux (tmuxinator for pr…
Of course.. people never stopped. Anyone using Wordpress, for instance, will almost certainly require developers to use FTP. For most shared hosts, FTP is the default (if not only) available method for getting files on and off of the server (and yes, people still use shared hosting as well.) I would even venture to guess that "Save in Notepad, FTP to live server and F5 to see if it worked" is still the most common web development workflow in existence.