Tips for Using Multiple Development Systems

Question

When I travel, I don't pack up the desktop I use in the office and take it with me. Maybe I should, but I don't. However, since I'm a contract programmer I like to be able to work wherever I am:

I'm mostly thinking of web development here. Version Control goes a long way in keeping sane and working on multiple projects on multiple systems (two or three computers); however, there are the issues of:

• IDE settings - different display sizes mean the IDE settings can't be completely synced, if at all.
• Database - if the database is 'external' (even if it's running on the same system, it's not in version control), how do you maintain the needed syncs of structure.
• Development Stack - Some projects need non-standard extensions, libraries, etc installed.

Just an overview of some of the hassle involved with developing on multiple systems. I'll probably end up asking some specific questions, but I thought a CW style tips might reveal some things I wouldn't even think to ask about.

Update: I guess this would also address tips to make upgrading/replacing your development system easier (something I've just done).

So, one tip per answer please, so the 'top' tips are easy to find.

How do you make it easier to develop on multiple systems, or to transfer work after upgrading/replaceing a development system?

Answer 1

This is a really boring answer, but sticking to defaults is one way of making the transition from one IDE installation to another less painful. Of course it's not always viable, but the less you customize, the more you can count on being how you expect it to be.

Doesn't help at all with the other issues of course.

Answer 2

You mentioned Version Control, so I'll just expand on that one a bit. I've found the latest VC generation (Distributed Version Control) an ideal solution to this particular problem. If you go a step further and use a nice service like BitBucket or GitHub to host a mainline copy, your environment travels with you nicely wherever you go.

After time, you get a good feeling for what files are nice and portable across systems (vi config files) and what aren't (environment specific aliases). If you're disciplined about organizing the structure, it makes getting started in a new location or new environment much easier. You can always VC host baseline settings for stuff that doesn't travel well, then copy them and customize for your particular environments.

Answer 3

The database setup process should be part of the product, so that a new instance can be quickly deployed with migrations, fixtures or factories to fill it with default data. That way you need source the source code and the database engine installed; anything else is just one command during build to get running.

Answer 4

If you have a decent internet connection when you travel, you could VPN into your home network and use a remote terminal application to actually work on your home system.

I do this with my dev system at work, I VPN in from home and remote terminal to my desk machine. Works great because all the database / network connections are not slowed down by the VPN, it's just transferring the remote terminal screen updates.

Answer 5

Another option I use is Microsoft PC virtual machines (any VM would do though). I have a VM set up for XP Pro with Visual Studio 2005, one for VS 2008 and one for VS 2010.

I fire up the VM I need, then map a network drive in the VM to a physical drive where I keep my project files (that way the actual project files are not tied up in the VM).

Answer 6

(In keeping with one tip per answer)

Cross Platform Tools

Although it isn't always an option, picking tools that are not platform dependent can go a long way towards making life developing on multiple platforms much less painful.

For example, in setting up a web development test environment, choose Firefox over others for simple / quick testing. (You still must test with other browsers!) Firefox easily runs on multiple platforms, and there are numerous tools that allow you to synch settings across them.

Choose an editor that works everywhere. I'd be ashamed if I didn't plug Vim again, but there are many others, such as Eclipse, or if you must, Emacs ;-).

Answer 7

Keep shared items in a Dropbox shared between all your computers.

I keep Subversion repositories in mine so that every single edit doesn't have to be transferred over the Internet, but only when I commit changes.