Thoughts on working remotely

When working on a mobile platform, as many people are these days, a lot of the standard practices and conventions you might be used to using are sub-optimal. High latency connections, moving between hotspots (and IP addresses), and intermittent connectivity can wreck havoc with many people's normal approaches to working, particularly in technological fields.

I frequently travel, and oftentimes find my only internet connection to be my cell phone. Yes, I can tether, but this does nothing to solve the speed and latency problems, it just lets me do my work on my laptop. But I find that if you approach mobile carefully, you will not suffer any productivity hits. Here's my approach to it, hopefully it will be beneficial to you.

The problem with latency

There is a big push these days to have everything stored in the cloud. Everything seems to have an online, “*cloud*” based variant. IDEs, compilers, etc. Many developers scorn these applications, as they don't see them as reliable. These developers are right. However, many developers also seem blind to the fact that their own approaches to coding and developing are often subject to the same limitations.

One developer I knew did everything remotely. He had a beefy server collocated somewhere, and always logged into it using SSH. He would do his editing in vim, and stored almost nothing on his local computer. On a decent internet connection, this was not a problem. But he ran into a morass of latency when he tried to do any work on suboptimal internet connections.

When you do your work on a remote server, if you use SSH to interact with the server, you will have input lag. On fast connections, the lag is almost invisible; characters and input is reflected back to the client almost instantly. However, on a slow connection, it can take surprisingly long amounts of time for any input to appear on the client. I refer to this as input lag, for lack of a better name. Input lag completely halts your productivity. While you may be an accurate typist, sometimes characters get sent before other characters. This can lead to lines that read ls --laa or are mangled in similar ways. While for short commands it isn't bad, for long commands, you would have to correct it, or retype the entire command. Moving your cursor, presumably using the arrow keys, requires input as well, and you'll often overshoot or undershoot your target. The end result is maddening.

Working client side

The solution to a good number of your problems is a simple one: work locally. Either copy the file to your local machine and work on it there (or use an editor that provides this functionality), or use some form of version control (this is the better idea).

You can use whatever editor you want locally, even vim, you just have to install it on your machine. If you switch between many machines, you can even sync your configs between them (this is beyond the scope of this article, but you might want to use git or rsync). I particularly like using SublimeText. To manage getting the files to your machine, assuming you aren't using something like git, you can take a number of approaches. A lot of FTP/SFTP/SCP clients will allow you to “edit” a file, in effect copying it to a local directory, opening it in the default editor, and watching the file for changes. I know that both WinSCP and Transmit support this.

Some editors, such as SublimeText 2, have plugins (FTP for ST2, $16 but worth it for convenience) that can do all this from in-editor. If you use a bulky IDE, it will probably have something similar. Some quick Googling should turn something up.

What to do when you absolutely have to connect to a server

Your app server just went down. You need to update because of a CVE. Whatever the reason, you may have to log into your server at any point. On a bad connection, you run right into the input lag problems, which can slow you down when you're doing mission critical applications, such as recovering from downtime.

Times like this, it pays to think ahead.

One of the tools I always install on remote servers is MoSH, the mobile shell. MoSH is basically SSH, but has provisions for dealing with slow connections. MoSH is over UDP, instead of TCP, so its a bit more resilient. Basically, MoSH opens an SSH connection, starts a server on the remote machine, connects to it, then closes the SSH connection. MoSH is encrypted, although the encryption remains untested. The benefits of using MoSH on a slow connection are almost immediately tangible. MoSH has local buffers and predictive echoing, so you don't get horrible input lag. It's probably one of my favorite tools