Local vs. Remote Development

Album Cover: Icky Thump

"You can't be a pimp and a prostitute, too."
White Stripes / Icky Thump

Posted on May 10, 2005 1:44 PM in Web Development
Warning: This blog entry was written two or more years ago. Therefore, it may contain broken links, out-dated or misleading content, or information that is just plain wrong. Please read on with caution.

Back in my PLU Web Development days I used to live and die by WS_FTP LE (before it became known and as WS_FTP Home and started to suck) with the firm notion of "local vs. remote" engraved into my mind. Since then, I've moved on to the more secure SSH protocol for managing files on my web server, but the whole local vs. remote idea is still there.

In the application I currently use for transferring files between my development machine and my web server (which shall remain nameless since I don't think I am supposed to be using it), the same local-view-on-the-left and remote-view-on-the-right approach is taken as was in WS_FTP LE. It is therefore very easy to see which files exist on my local drive, and which exist on the remote server. Transferring files between the two, in either direction, is simple and allows for a level of redundancy that makes me feel comfortable.

However, more and more I have been doing development on the remote server itself, usually using vi, a very powerful (and equally hard to master) Unix text editor. The beauty of developing remotely is that it eliminates the extra steps of saving my changes locally and then transferring them to the server before checking to see the results. Editing remotely, I can save the file (using the uber-intuitive :w command in vi) and immediately check the result in a browser.

The downside of editing remotely, though, I've already touched upon. Because all changes are made on the server, I do not have a backup copy on my local drive should anything disastrous happen. This is especially problematic when working in a hybrid mode, if you will. If I transfer files half the time and edit remotely the other half, it can lead to a false sense of security. I begin to think that maybe I have the most recent version of a file saved locally...but do I really? Checking timestamps adds an extra layer of complexity that only decreases efficiency.

So what is the best way to go? I don't have the answer to that. I still do quite a bit of file transferring, mainly because it feels safest to me. However, I fire up vi quite often these days, just because I love quick results and quick fixes. So I guess that puts me in hybrid mode, and like I said earlier, this is perhaps the most dangerous mode to work in. I trust myself, though (maybe too much), so I'm willing to live with the hybrid approach for the time being.

What approach do you use? Why? Have Windows linefeed vs. Unix linefeed problems shaped your decision at all? Other factors? I'd love to hear.


Dwight Brown on May 11, 2005 at 4:43 AM:

You might consider using the text editor UltraEdit which allows you to open and save Remote files while retaining a Local backup.


Ryan on May 21, 2005 at 2:24 AM:

Been meaning to comment for a while...

I have the same problem, Bernie. Generally, I do remote editing for early stage exploratory programming, when I'm experimenting with big new concepts and loosing everything wouldn't really matter too much, becase most of what I'm doing isn't for the code, but for learning about it. When a website becomes more mature, however, I tend to edit locally then upload. In this case, it is about the code, not about anything I might learn from hacking away quickly on a remote server. That being said, I am not immune to vim'ing my index.php or wp-layout.css when the urge comes across me, as I have recently done (you may or may not have noticed).

However, the real point of all of this is to let you know that WinSCP has a auto-sync feature that keeps a local and remote directory up to date with each other. This way, you get the benefits of local editing and backups with the joy of instant, hasstle-free insta-updates.

Disclaimer: I have never used the feature, and I don't know how well it works. <grins>


Post Comments

If you feel like commenting on the above item, use the form below. Your email address will be used for personal contact reasons only, and will not be shown on this website.


Email Address:



Check this box if you hate spam.