Poll: Your preferred method for coding on a remote server?

Push to a GIT server, we have a branch called 'live', then we run a script on the servers that pull down the deploy branch. We also have a branch called 'development' for our dev boxes

X exported via NX -- works awesomely fast especially over slow links, tethered smartphones, etc.

1). Net-accessible dev and staging machines. Net-accessible staging servers are fairly easy to set up if you have a repeatable way of doing deployments. Security can be a mite tricky. Net-accessible dev boxes are modestly more difficult than staging if you do them right. (Simplest way is to use reverse SSH tunnneling on a net-accessible box under your control to your dev box, which is a single trivially Googleable command. The reason this takes thought is that giving the world access to an app server on your machine is potentially a Very Bad Idea.)

If the idea of having HTTP on your laptop does not fill you with mortal dread, Twilio has an OSS called localtunnel which makes your laptop web-accessible in seconds.

2). Source control for every change, deploy scripts to get it to environments safely and repeatably. DVCSes handle lots of little changes fairly elegantly, and you can squash a range of them after you e.g. figure out the magic incantation to get a foreign API working right. (Turning thirty one-character commits and ten deploy tags into a single "Foreign API now works" commit.)

I have done cowboy coding in Putty in the past. There is no excuse for it.

For the case of Facebook app development, there are few great substitutes for an SSH tunnel routing traffic back to your local dev environment. All the local dev tools your used to, including TextMate if that's how you roll, with a little bit of extra latency.

You can roll your own, but I'm happy to use Tunnlr.

I almost always SSH into the remote machine, but I use Emacs' TRAMP on occasion, when I know I'm only editing a couple of files.

EMACS + tramp - http://www.gnu.org/s/tramp/ - works great.

I use Sun Secure Global Desktop to connect to remote machines.

Well having done a Facebook app, step one set the URL to http://localhost:1234 or something on Facebook and you are away for local dev work. Unless you are working on something different to what I did, it just inspects the source URL.

Try using a web service mocking software and learning how to work your hosts file. Soap UI comes to mind... or whack together manual services on test boxes.

If you capture an coming response, maybe using fiddler or something, or if using visual studio its a breeze. Then just set up a basic web service that returns you data as you captured, no processing needed at all. Or even just set up some proper routing. There isn't really an excuse doing cowboy work will bite, maybe not today, but later.

I've seen to many huge f/k ups and been responsible for €50,000 mistake myself mucking with a live server with no testing environment.

My favourite for this is virtualisation BTW. Taking server snap shots of production, dumping them in a sand box where I have mocked third party set ups, and hack away. Makes releasing, testing, everything breeze. Big time cost up front, but it pays itself back ten fold on the first smooth release.

I like using ExpandDrive to mount remote filesystems, and then edit using TextMate or some other Mac editor.

I used to work solely on a remote Dev box, using ExpanDrive to edit locally. I would have an ssh session open to run commands/debug/shell.

I've recently starting moving towards local Vagrant instances. I don't like dealing with local library installs on my Mac, and Vagrant makes it stupid easy to repeat my dev setup. It also gives me a good starting point for provisioning servers (using Puppet), thought I haven't fully consolidated the local dev and server Puppet manifests, yet.

I import the remote filesystem into Plan 9 and edit it there.

Which might be u9fs via ssh | ftp | drawterm | cpu | sshnet & AoE | import | sshnet & ftp | import /net & AoE | import /net & ftp

The possibilities are numerous

I want to get good enough at Vim to just do all my coding in it, but for now using an SFTP bookmark + Gedit in Ubuntu is convenient and feels like I'm editing the files locally. I still have an ssh console open for gitting / grepping etc.

Trying to do the same sort of thing with MacFuse in OSX was an absolute nightmare though (slowwww), but perhaps I was holding it wrong.

Since I got an Imac at work, I mount the remote file system over SSHFS and it works quite good.

Before I used ZDE 5.5 for PHP dev. and opened the files remotely via SFTP. It was also not bad, though ZDE 5.5 is really buggy.

What I miss is an editor which supports opening files via SFTP and doing that fast (as ZDE) and is not that buggy (not as ZDE) and supports autocomplete.

I vote for the custom rsync script, as it's really easy and I get to keep working locally:

http://www.exratione.com/2011/08/use-rsync-scripts-for-painl...

Over the years I think I've done all of these. They're all a little painful. Being in Australia means that latency is an issue, I'm sure fast DSL in California is different.

If you're using SSH, an editor and terminal that supports GPM mouse over SSH (eg: iTerm2 on OS X and Vim on the backend) makes life easier.

It's rarely necessary. For Facebook in particular, 95% of the integration happens at the web browser level via signed URLs and/or Flash - Facebook's servers rarely talk directly to your servers or vice versa. Just run a web server locally and put 127.0.0.1 in your hosts file.

BCVI: http://sshmenu.sourceforge.net/articles/bcvi/

It's like a combination of "I SSH into a server, and work there using VIM/EMACS/etc." and "I use a local VIM/EMACS/MC/etc to open files remotely over SSH/FTP.".

You SSH in and type "vi foo.py" in the remote shell, but the file opens in your local Vim. When you save it's automatically transferred across.

Facebook let you use localhost as the canvas page; no idea if they also let you local network addresses as well. So that's one problem solved :)

For debugging calls such as those received by PayPal, I start by writing a small script that logs the GET or POST request, then write a simple test page that POSTS to the local script that I'm developing.

At any rate, if the only way to test the majority of your code is via a POST, there's something wrong with the way you're writing code; the objects you've created you should be able to test independently, for a start :)

I've shot myself in the foot enough times with "trivial" or even "one character" edits that everything goes through the normal source control + deploy process.

SSH, GNU Screen (byobu), and Vim.

I don't need to do this as much as I used to, so I normally use either a mounted ssh filesystem, or "sharing" through a DVCS these days.

A few years ago I worked at a place where they gave us a local windows box and a remote headless linux box where the code ran (this was before virtualization was ubiquitous). I used cygwin on windows and forwarded X11 sessions running on the remote linux box to my windows box over ssh.

windows w/putty: http://tldp.org/HOWTO/XDMCP-HOWTO/ssh.html OSX: http://dyhr.com/2009/09/05/how-to-enable-x11-forwarding-with...

It let me run eclipse and other GUI apps on the linux box, but have them mostly feel like native apps (well, native X11 apps) on the windows box.

None of the above. Google AppEngine does it all for me with the click of a 'deploy' button. Sysadmin work is so 80s.

To be honest, since GAE all I do now is open notepad2 and code, nothing else, then deploy and presto. I remember the old days when having apache, filezilla, svn, and a plethora of sys tools was the order of the day.

Coding is more fun when it is pure coding and nothing else than coding. Thanks GAE.

i ssh into a server, but i learned about using a local VIM instance to edit remote files yesterday (on HN, of all places) and will be doing it that way from now on. no more need to spread my fine-tuned vimrc to every server i use!

I use a cooperating set of Mac apps: connect to the server using Cyberduck, browse to a file and double-click to open it in TextMate, edit the file and type command-s to save, peripheral glance to the corner of the screen where Growl puts up a notification that the transfer completed successfully, then type command-shift-r to tell TextMate to tell the currently open web browser to reload its front-most window to see if the change had the desired effect.

A number of Mac file transfer clients and text editors support this type of integration.

vim + git + git repo hosting service + fabric

make changes locally, merge into remote environments branch, run fabric command that pushes change up to git hosting server, ssh's into remote server based on current branch then pulls changes from repo hosting servers & runs a few other bits remotely (migrations etc) depending on what has changed

I use codebasehq.com btw, been ace but i dont see a great need to use their deployment service.