4

In a talk about time management, a famous computer scientist said:

"One machine in your life is the right number."

He recommended a laptop with a docking station.

After trying this approach for about a month, I miss my more powerful desktop (i7 quad core hyperthread), but it is not in my technology road map (or budget) to upgrade from my old Intel Core 2 Duo (2006) notebook this year.

What strategies can help me use the desktop while at my desk and without much manual effort the notebook when I am on the go?

Improve this question

5 Answers 5

Reset to default
2

Actually, I think working on many PCs can increase your productivity (albeit not without an initial investment).

The reason for this is complex, but you can sum it up this way:

You are forced to think about creating a good development environment, independent of your PC.
I'd argue in better-organized companies this is the case and there are documented instructions about setting up a new computer up to speed with the tools required for the project developed.

In order to achieve what you want, you should decouple your process from the machine as much as possible.
So, a couple of tips:

1. Always use version control.
This applies to both code and data. Tools for the code and data differ, of course. You might want to favor distributed tools, since this gives you more flexibility.

2. Document the process of setting up the development environment
This is pretty straight-forward, although admittedly it's also time-consuming. However the importance is utmost: if you suddenly have to setup a new machine, this is immensely helpful.

3. Create a VM containing a ready development machine
This is rather an emergency response step, but it's very good to do that, too. This way, you can just start coding when presented with a new PC, which can save you much time if you're in a hurry.

4. Have a dedicated deployment / continuous integration server.
This way you can assert that the code works on the deployment machine as well as yours. There are many service providers for this, plus dedicated virtual servers are not very expensive anymore.

5. Use a cross-platform IDE (if possible) and learn how to cross-compile and cross-debug (if applicable).
Again, allows you to work in an even more unfriendly environment, plus this is the only way you can catch some of the more persistent bugs. It allows you to do stuff like leave your work machine on when leaving the office and debugging on it from home, even if you can't run the project locally.

6. Make yourself comfortable with SSH, VNC, SCP and RDP.
You're going to need at least one of these, since there's always some mixup when a deadline is approaching: a file you've forgotten to upload to the server and is on a PC in another city, or you need to fix something on a remote machine, etc.

Think of #6 as a last resort; you shouldn't depend on anything you don't have easy access to for your work, except in unforeseen cases, and SSH is not easy access.

Accidentally, you might notice some of these tips are considered good practices in general; I believe them to be such. This is all a matter of organization and improving it will save you time, eventually.

Improve this answer
8

Here are some things I've done, or have seen done:

Store as much as you can in remote repositories. Git/Mercurial/Subversion is your friend in this aspect. You can make anything a repository, and with services like Github, you can store everything, including config files, in remote repositories. Doing this gives you a central location from which to sync to and pull from (just make sure you push your latest stuff before switching machines). If you run Linux, you can probably repo your entire /home directory.

If you don't want to use repo storage services, store everything on a USB storage device. Large thumb drives, and USB hard drives are pretty cheap these days, so if you don't want to/can't use a third party storage system, then pick one up, just don't forget to take it with you!

Use software with config files and find those files so you can copy them (and don't forget your OS's configs). This may or may not be feasible, depending on what you do, but it's a very good idea to check to see if your software does. Copying config files is easier than trying to manually set up the configuration between the two machines. This is great even for utilities and OS configs, such as .bashrc for terminal, if you're not using default settings.

Use software that has a per-user, instead of per-install license. If you're not using free/open source software (Eclipse, Netbeans, etc), try to go for stuff that uses a per-user license model (such as Sublime Text). This will avoid the headache of dealing with software on multiple machines and staying kosher regarding licenses.

Use web-based tools when feasible. Things like Freshbooks, Harvest, Basecamp, and Google Apps help remove the headaches caused by multiple machines by removing the local machine to begin with (save for having a browser to access them).

Leverage your browser's syncing tools. Most, if not all, of the major browsers have syncing tools that allow you to sync your bookmarks, history, passwords, etc. between your computers (and the ones that don't very likely have addons that can). This is a huge asset, so don't be afraid to make use of it.

Script what you can. Scripting things like the download and install of your software can both speed up setup and help you not forget anything. It also helps as a "start it and forget it" type of thing, so you can do other things while the script handles the legwork of downloading and installing your software. (Note: this is very likely quite a bit easier on Linux machines, since most of your software will be in repos most likely, but it is doable on any OS, as long as you can get the installers via a commandline downloader such as curl or wget.)

Improve this answer
2
  • 2
    +1 Storing config (dot) files in something like Dropbox or Github can be really powerful. To set up a new machine, just make symlinks to those sync'd files and it acts just like your other machine(s).
    – grossvogel
    Sep 3, 2012 at 1:53
  • 1
    Storing dotfiles in a Github repository is a good thing, but if you want to use a public repo (e.g. to share your dotfiles with other people) be careful with SSH keys, passwords etc.... (speaking from experience).
    – Renan
    Sep 3, 2012 at 5:21
2

You've not really specified what your actual problem is so I can only speculate from personal experience:

Does your company offer a VPN so you can work from home? If so maybe you can remote desktop into your desktop machine. Otherwise, maybe ask for a laptop cooler so the OS doesn't underclock the CPU as often when it gets hot. Or ask for more RAM, it's cheap these days.

If your problem is about sharing data get an external HD with an encrypted partition, or remember to check stuff you've done into source control at the end of the day.

Improve this answer
1

My advice is exactly the same set up I have for myself (I have 2 desktops, 1 netbook and 1 remote server running just nicely with this):

  • web browser use either Firefox (with Firefox sync) or Google chrome (with it's google account) to keep history, bookmarks and preferences consistent.

  • unison this is a free (as in freedom) tool to keep things many systems syncronized. I find it works like a charm. The perfect setup would be to have a server running it but it also works fine if you have an external HD that you move around (I used that before). And you don't have to keep them always syncronized. I found it to be quite good to make a guess about when updating files. And it's also very flexible. For example, you can have your desktops syncing some directories (such as Pictures and Videos) that are not syncing with a netbook (maybe you don't have a lot of space there).

  • do not use SVN if you have many version control systems either use mercurial or git. SVN works with file locks and some other magic inside the .svn directories and will not work when you use unison (or other sync tools) to keep the files between systems synchronized. Of course if you always makes a commit then on the other systems you only have to update the repo and there's no problem. But I'm not always ready to make a commit when have to go from one to another system.

Improve this answer
0

I just solved this for myself.

I have laptop for development and couple weeks ago it crashed. Well. I learned that even I have backups, svn, etc pain was huge just because I was so hardware dependent. To restore dev environment on different machine takes time. Even with on-site mintenance plan I was down for 4 days.

Long story short I bought pretty beefy desktop and run VMWare on it. Performance is better than it was on laptop and my whole system is in one folder which I backup daily. It is on separate SSD and when I need to go somewhere I just put it in dvd bay on my laptop. Slow but ok for travel.

This way I have backup, independence from hardware and backup hardware in case laptop or desktop ever fails

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.