Ditch your laptop and code in the cloud—it's easier than you'd think.

On September 19, 2011, I said goodbye to my trusty MacBook Pro and started developing exclusively on an iPad + Linode 512. This is the surprising story of three months spent working in the cloud.

Figure 1. iPad on Sofa

It all started when I bought my first MacBook a couple years ago; despite a decade using Linux, I never really was satisfied with either GNOME or KDE. In OS X, I hoped to find a slick window manager on top of a solid BSD implementation. I enjoyed hardware with drivers that "just worked", but I missed decent package management and the rest of the Linux ecosystem.

Although I like to use Python and GAE for my own projects, at work, we write heavyweight C++/Qt code that runs on clusters, such as the 200,000 processor Jaguar machine, so most of my day was spent in Linux anyhow, a lot of it on remote systems. Typically, I'd develop in MacVim locally and run my code remotely or on Ubuntu under VMware Fusion.

One fateful day, VMware and OS X conspired to trash my shared filesystem. While dd was recovering as much as it could, I started toying with the idea of giving up on local filesystems altogether. To my surprise, it seemed possible—even plausible. The more I thought about it, the more attractive it seemed. I knew then, I just had to try.

It turns out you need a little more than just an iPad and a dream, but not too much more:

• iPad 2 (16Gb, Wi-Fi).

• Apple wireless keyboard.

• Stilgut adjustable angle stand/case.

• iSSH (and optionally Jump).

• Linode 512 running Ubuntu 11.04.

• Apple VGA adapter.

• Total cost: around $800 + $20 per month.

Figure 2. iPad and Keyboard Box

I chose a Linode 512, which has been perfect for my needs. You get fantastic CPU power and a tiny little bit of RAM. Surprisingly, this is enough when you do most of your work at the command line, but it's nice knowing I always can upgrade it later.

I also turned on the $5-a-month backups. Zero-effort data safety for less than the price of a hot chocolate? Yes, please!

Linode's interface walks you through adding your new node. Pick a region close to yourself—you want to minimize the roundtrip time to the server. I spend most of my time in Munich, so I have mine in London and get a 30–40ms ping, which is great.

I run Ubuntu 11.04 in 32-bit mode on mine, but they offer a wide selection of pre-built Linux images along with the option to install your own.

For access to the server, you need a really good SSH client. On the iPad, I've tried both iSSH and Prompt, and of these, only iSSH is even feasible for serious use. The hardest part of setting up an SSH client on a tablet is getting your private SSH key on there without entrusting it to a third party. I split mine across multiple services and removed it after recombining it, but a better way would be to SSH in with a password first, then use copy and paste to copy the key inside iSSH itself.

I typically start my day by catching up on the bug-tracker chatter, mercurial diffs and other e-mails with the iPad in one hand while lying on the Combinat56 sofa.

I actually hate the mail app for this—the stupid animation when archiving posts adds unnecessary delay, and the archive button is uncomfortably placed at the top of the screen. More recently, I've been scanning e-mails over IMAP with a Python script instead.

Next, I lazily swipe to Safari and review my tickets for the day in our Web-based bug tracker then return to the keyboard and fire off a couple e-mails before settling back into coding—the new four-finger swipe gestures in iOS5 have really improved my life.

But, I was talking about coding, which brings me back to the only reason this setup works for me at all: Vim.

Perhaps the only reason this transition has been so smooth is because my favourite editor/IDE looks and feels almost exactly the same running on an iSSH console as it did running locally on my MacBook. iSSH supports xterm-256color, which means you still can have pleasant color schemes despite working in a terminal. All my plugins are there, my code-completion, quick navigation and so on.

Figure 3. Vim on iPad

I found Ubuntu's default Vim didn't have everything I wanted, but don't worry! It's easy to download and build it yourself. See Listing 1 (also available at ).

install-vim.sh #

apt-get install mercurial
apt-get build-dep vim
hg clone https://vim.googlecode.com/hg/ vim
cd vim
./configure --enable-rubyinterp --enable-pythoninterp 
 ↪--with-features=big
make
make install

I honestly can't remember which plugins I installed and which ones I actually use. I just copied the existing .vim folder from my MacVim installation. I definitely use these every day though:

• a.vim

• cctree.vim

• clang_complete.vim

• color_sample_pack.vim

• command-t.vim

• cscope_maps.vim

• NERD_tree.vim

• scratch.vim

• searchfold.vim

You can get them all from http://www.vim.org/scripts, but you may want to install pathogen and get them that way instead. Note that command-t requires you to build a stub—follow the install instructions in command-t.vim, and it just works.

To use the clang_complete plugin, you'll need clang. Typing apt-get install clang should do the trick. I had to play around with it a bit to get it working on my project, which included adding all the -I and -D command-line options to a .clang-complete file in the project directory.

Everybody configures Vim differently. Listing 2 shows my .vimrc (also available at https://gist.github.com/1357590). Some of the things here relate to our internal tracker system and won't be interesting for you, but it should be clear what most of these things do and which keys are bound to them.

"Set Mapleader
let mapleader = ","
let g:mapleader = ","

"Theme
colo zenburn

"NERDTree
map <Leader>, :NERDTreeToggle<cr>

"Taglist
let Tlist_Ctags_Cmd = '/usr/local/bin/ctags'
let Tlist_WinWidth = 50
map <Leader>. :TlistToggle<cr>

"Check python syntax
let g:pcs_hotkey = '<LocalLeader>x'

"Quick Open
let g:CommandTMaxFiles=30000
set wildignore+=*.o,.ddt-*,.treeserver-*
let g:CommandTMatchWindowAtTop = 1

"Scratch buffer
map <Leader>k :ScratchOpen<cr>

"RT
map <Leader>rt "zyiw:ScratchOpen<cr>:0r!~/Work/code/util/rt show -f
↪id,Subject,Queue,Status,Creator,Owner,LastUpdated,Priority
↪ticket/<C-R>z<cr>o<Esc>
map <Leader>tt "zyiw:r!~/Work/code/util/rt show -f Subject ticket/<C-R>z 
↪\| grep Subject \| cut -d' ' -f2-<cr>kA:<Esc>Jj

"ctags
set tags=tags;$HOME

"Rebuild cscope
map <Leader>cs !cscope -bqk<cr>:cs add cscope.out<cr>

"Buffer shortcuts
map <Leader>f :b#<cr>

"ddt log files
map <Leader>gdb :!cdata-from-log % >/tmp/cdata.log<cr>:e 
 ↪/tmp/cdata.log<cr>

"Disable virtual bell
set vb t_vb="

"Make backspace work
set backspace=2

"Code navigation
map <Leader>gd ?^{<cr>kf:ll

"Misc stuff
set autoread
set hidden
set hlsearch
set incsearch
set ignorecase
set smartcase
set smartindent
map <Leader>c :let @/ = ""<cr>
syntax enable
set nu
set textwidth=0 " No annoying word wrapping
set tabstop=4
set shiftwidth=4
set expandtab
set guifont=Menlo:h14
filetype on
filetype plugin on
set nocp
autocmd FileType python set omnifunc=pythoncomplete#Complete
autocmd FileType javascript set omnifunc=javascriptcomplete#CompleteJS
autocmd FileType html set omnifunc=htmlcomplete#CompleteTags
autocmd FileType css set omnifunc=csscomplete#CompleteCSS
autocmd FileType xml set omnifunc=xmlcomplete#CompleteTags
autocmd FileType php set omnifunc=phpcomplete#CompletePHP
" Replaced by clang_complete for now
" autocmd FileType c set omnifunc=ccomplete#CompleteCpp
autocmd FileType ChangeLog set tw=80

In short, it's a seamless transition from my MacVim environment. If I were developing OS X apps with Xcode or used Eclipse or Visual Studio regularly, this change probably would have killed me.

As it happens, working in the terminal on a remote Linode is even better than working locally, thanks to the magic of GNU Screen.

GNU Screen is like a window manager for your terminal sessions, giving you multiple tabs, searchable history, activity/idle notifications and—best of all—persistence.

Figure 4. GNU Screen Bar

So, I fire up iSSH, tap on my Linode connection and reconnect to the already-running Screen session. All my terminal tabs are exactly where I left them. Other SSH tunnels still are set up. My cursor still is in the same position. The clipboard is as I left it. It's as if I never left, because for my side projects, I have a different Screen session with a different set of tabs and editor instances running—perfect separation.

It's hard to overstate how pleasant it is to be able to return to exactly the same session each day. On a MacBook, there'd usually be some other distracting programs left that I'd opened in the meantime, and of course, any remote connections would have been dropped. At the very least, I'd have used MacVim for something else in the evenings. It might be a largely psychological benefit, but it feels as if I can drop back into the flow almost as easily as I left it. (Listing 3 shows an example .screenrc file, also available at https://gist.github.com/1357707.)

#
# Example of a user's .screenrc file
#

# This is how one can set a reattach password:
# password ODSJQf.4IJN7E    # "1234"

# no annoying audible bell, please
vbell on

# detach on hangup
autodetach on

# don't display the copyright page
startup_message off

# emulate .logout message
pow_detach_msg "Screen session of \$LOGNAME \$:cr:\$:nl:ended."

# advertise hardstatus support to $TERMCAP
# termcapinfo  * '' 'hs:ts=\E_:fs=\E\\:ds=\E_\E\\'

# make the shell in every window a login shell
#shell -$SHELL

# autoaka testing
# shellaka '> |tcsh'
# shellaka '$ |sh'

# set every new windows hardstatus line to something descriptive
# defhstatus "screen: ^En (^Et)"

defscrollback 1000

# don't kill window after the process died
# zombie "^["

################
#
# xterm tweaks
#

#xterm understands both im/ic and doesn't have a status line.
#Note: Do not specify im and ic in the real termcap/info file as
#some programs (e.g. vi) will not work anymore.
termcap  xterm hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
terminfo xterm hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l

#80/132 column switching must be enabled for ^AW to work
#change init sequence to not switch width
termcapinfo  xterm Z0=\E[?3h:Z1=\E[?3l:is=\E[r\E[m\E[2J\E[H\
↪E[?7h\E[?1;4;6l

# Make the output buffer large for (fast) xterms.
termcapinfo xterm* OL=10000

# tell screen that xterm can switch to dark background and has
# function keys.
termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l'
termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'
termcapinfo xterm 'kh=\E[1~:kI=\E[2~:kD=\E[3~:kH=\E[4~:kP=
↪\E[H:kN=\E[6~'

# special xterm hardstatus: use the window title.
termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'

#terminfo xterm 'vb=\E[?5h$<200/>\E[?5l'
termcapinfo xterm 'vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l'

# emulate part of the 'K' charset
termcapinfo   xterm
'XC=K%,%\E(B,[\304,\\\\\326,]\334,{\344,|\366,}\374,~\337'

# xterm-52 tweaks:
# - uses background color for delete operations
termcapinfo xterm be

################
#
# wyse terminals
#

#wyse-75-42 must have flow control (xo = "terminal uses xon/xoff")
#essential to have it here, as this is a slow terminal.
termcapinfo wy75-42 xo:hs@

# New termcap sequences for cursor application mode.
termcapinfo wy*
CS=\E[?1h:CE=\E[?1l:vi=\E[?25l:ve=\E[?25h:VR=\E[?5h:VN=
↪\E[?5l:cb=\E[1K:CD=\E[1J

################
#
# other terminals
#

#make hp700 termcap/info better
termcapinfo  hp700
'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$}:fs=
↪\E[0}\E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@'

# Extend the vt100 description by some sequences.
termcap  vt100*
ms:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC
terminfo vt100*
ms:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=
↪\E[%p1%dD:RI=\E[%p1%dC
# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm-256color 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on" 

################
#
# keybindings
#

#remove some stupid / dangerous key bindings
bind k
bind ^k
bind .
bind ^\
bind \\
bind ^h
bind h
#make them better
bind 'K' kill
bind 'I' login on
bind 'O' login off
bind '}' history

# Yet another hack:
# Prepend/append register [/] to the paste if ^a^] is pressed.
# This lets me have autoindent mode in vi.
register [ "\033:se noai\015a"
register ] "\033:se ai\015a"
bind ^] paste [.]

################
#
# default windows
#

# screen -t local 0
# screen -t mail 1 elm
# screen -t 40 2 rlogin faui40

# caption always "%3n %t%? @%u%?%? [%h]%?"
# hardstatus alwaysignore
# hardstatus alwayslastline "%w"

# bind = resize =
# bind + resize +1
# bind - resize -1
# bind _ resize max
#
# attrcolor u "-u b"
# attrcolor b "R"

hardstatus alwayslastline
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR} 
↪(%{W}%n*%f%t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= 
↪%{g}][%{Y}%l%{g}] %{=b C}[ %m/%d %c%]%{W}'

At work, we develop a graphical parallel debugger, so I can't spend all my time in the terminal. For hands-on tests and GUI work, I need X. iSSH has a workable, if not perfect, solution, but for a few extra dollars, I find Jump far superior.

Although it's still not as quick and accurate as using a mouse to interact with a traditional GUI program, both iSSH's on-screen "touchpad" and particularly Jump's tap circle work better than I'd expect. And as it happens, being limited isn't all that bad:

One good way to evaluate the usability of a program or dialog is to try to use the mouse with just one finger.—Joel Spolsky

VNC on the iPad isn't nearly as bad as pushing the mouse around with one finger, but it does make you consider users with lower screen resolutions, larger font sizes and mouse control that hasn't been honed by countless years playing Quake and Starcraft. I'd be lying if I said I hadn't wished iOS had Bluetooth mouse support some days.

Today is not one of those days. I unwrap a chocolate croissant, make a fresh cup of tea and settle down to work: a quick hg pull -u && make to start the recompile, then Ctrl-X to my editor tab and carry on coding while the rebuild happens. Ctrl-X is my screen's "hot key"; it defaults to Ctrl-A, but on a wireless keyboard, that leaves Unicode characters in the terminal—I assume this is related to Apple's support for some common Emacs keybindings in iOS. It's strange, but easy enough to work around—unless you're an Emacs user, I imagine.

Figure 5. iPad and Croissant

After a few minutes of coding, the bar at the bottom of the screen notifies me that my compile has finished. I Ctrl-X back, start a sanity test suite running just to be sure nothing horrible was broken overnight, then carry on coding again. Compiling on the quad-processor Linode is around twice as fast as inside VMware on my MacBook was. It's also completely, blissfully silent. The only sound is the raindrop-like patter of the keyboard as I work. It doesn't even get warm—a surprisingly refreshing change from the keyboard of a hard-working laptop!

I swipe to the DuckDuckGo app and look something up in the Qt APIs, then swipe back. It's becoming second nature, but I still miss a keyboard shortcut for task switching.

After an hour or two of uninterrupted development, the UK team wakes up and the first instant messages arrive. Thank heaven for the iOS5 update! I use the imo messenger app, which is fine, but of course, before the notification center, each pushed message would interrupt whatever I was doing with a frustrating pop-up. Now, the new notifications center behaves much more like a growl notification would—it lets me know, and it gets back out of the way again.

I finish the function I was working on, then four-finger swipe to the chat app; it's my boss reminding me about our 11am conference call.

Skype-based conference calls work fine on both the iPad and the iPhone; at least, as well as VoIP calls ever work—that is, fine after a few false starts while someone reconfigures the Linux audio drivers. I appreciate not having to think about that anymore—with a thin, consumer client and a powerful Linux server, I'm really enjoying the best of both worlds.

During the Skype call, my iSSH session timed out in the background. It's only held for ten minutes or so. Fortunately, a single tap reconnects me, and through the magic of GNU Screen, I'm back at exactly the place I left off again.

As is always the case, while fixing one bug, I encounter another, apparently unrelated one.

Instead of messing around with some Web interface, I've switched to grabbing screen dumps (I recommend vncsnapshot) and any log files or stack traces with a command-line script run on the Linode itself. We use the Best Practical RT tracker (for our sins), which conveniently comes with a Perl script to interact with it from the command line. Doing this is actually quicker and easier than uploading via a browser used to be—one command with a bug description and the attachments, and I'm done.

And, it's lunchtime already! I close the iPad and head off with the others. The remote rebuild I left going will still be there—no need to worry about any uploads getting interrupted; it's all happening in on the Linode, after all.

Figure 6. iPhone SSH

During lunch, I pull out my iPhone and connect to the Linode again. Unfortunately, the build failed early on—out of disk space on one of the office staging machines. The iPhone keyboard is somewhat painful to use, but for rm -rf /tmp/build-2011-* it suffices. I kick off a new build while waiting for dessert to arrive.

Now I'm feeling nicely fed and just a little drowsy. To keep awake, I move to a standing workstation and set off some longer-running performance tests on a remote cluster. I find I move around between a lot of different working configurations with the iPad—much more frequently than when using a laptop. I'm not sure why—perhaps it's something about having a separate keyboard and screen that makes it easier to find a comfortable typing position, or perhaps it's just the novelty.

The tests will take an hour or so. I close iSSH and review the latest spec/schedule changes my colleagues have made to an upcoming spec, stored in Google Docs.

In a bitterly ironic twist, the only part of working in the cloud that doesn't work smoothly is using Google's cloud-based MS Office replacement. The mobile word processor is a joke, frequently losing the cursor position and sizable chunks of text. The spreadsheet version is better, but it's still a pathetic experience compared to the desktop version. There are no good native apps, so the only thing to do is to force Google to show the desktop versions of the sites and ignore the script errors. I wish I could convince my team to switch back to OpenOffice.org.

The tests have finally finished and the results are in. I move to the lounge area and connect to the big HD TV with the VGA cable—something about seeing console-mode Vim in giant HD makes me smile every time.

There are some oddities in the logs. I copy and paste a few snippets to a colleague and discuss them in chat. I'm glad copy and paste work smoothly, although having three different sets of buffers (iPad, Screen, Vim) does lead to confusion from time to time. Idly, I wonder if any of my colleagues have noticed I've been using an iPad instead of a laptop for the last month.

Six pm rolls around, and it's time to head home for the day. Despite a full day's intensive use, my iPad is still showing 15% battery life. I never bring a charger to work, and I've never needed one. That in itself is a taste of freedom.

Later that evening, I pull the iPad out and open up Pages to finish a blog post. The house is quiet. Only the distant sounds of the city drift in from outside and mingle with the gentle patter of key presses on this delightful wireless keyboard.

I started this experiment because I fundamentally believe that most people don't want to rearrange windows, babysit their own general-purpose computers or back up their data. Sooner or later, almost everyone will work like this, and I wanted a taste of what that might feel like. I expected to find something that didn't work, but as the days turned into weeks and the weeks into months, I found I hadn't returned to my laptop even once.

I don't miss the weight. I don't miss the keyboard getting warm when I'm compiling. I don't miss its fragility, both physically and virtually. I don't miss running out of power. To my surprise, I find I am happy. Coding in the cloud isn't for everybody, but for my work flow, it's a perfect fit and I love it.

After a few minutes, the perfect peace is rudely disturbed by the twin jet-engine that is my MacBook fans spinning up to full power on the shelf behind me. I can't believe I used to put up with this all day and night.

Despite that, I leave the MacBook running. It's doing the only thing I still need it for on a regular basis. It's ripping DVDs.