Dave Rapin

Mobile and Web Development

Pair Programming Remotely on a VPS

At Pair Shaped we firmly believe that pair working is the future (and the present). However a good part of our team works remotely and this can be a real challenge.

While remote pairing solutions are becoming increasingly popular, as a coder it’s hard to beat the Vim + Tmux combination. It’s simple, fast, and there’s no client OS or application dependencies.

In this post we take you through all of the steps to setup an amazing remote pairing environment using an affordable cloud server (VPS). What this will allow you and your team to do:

  1. Securely share persistent tmux (shell) sessions on a linux box on the cloud.
  2. Watch each other code.
  3. Take turns coding.
  4. Rotate between different persistent pairing sessions with multiple team members all within the same server.

I highly recommend adding voice to the mix whether it’s Skype, Google Voice, or a SIP provider.

For starters, we’ll need a linux box in the cloud. For the server we’re going to go Digital Ocean since it is one of the most affordable options at the time of this post. However, the steps are essentially the same with other hosts like Linode and EC2, so definitely check them out too.

Sign up for an account at Digital Ocean and then create a 512MB droplet running Ubuntu 12.04 x32. If you’re not sure about the hostname option, a good choice would be something like pair.yourcompanydomain.com. Make sure you chose a region that’s close to you and your team to minimize latency.

At this end of this tutorial you can shut you droplet down if you aren’t going to use it, and it’ll only end up costing you a few cents.

Once you’ve created the droplet, you should receive an email from Digital Ocean with your new boxe’s IP address and credentials. For the rest of this post I’ll use a fictional IP. Just substitute the IP you were given as needed.

Open up a terminal if you don’t already have one up and follow along with these commands to setup and install the basics.

Basic Server Setup

1
2
3
4
5
6
7
8
9
10
11
12
# Log into your droplet and enter the provided password when prompted.
ssh root@198.199.xx.x

# Update the system. This will take a little while to complete.
aptitude update
aptitude safe-upgrade

# Install essential build tools, git, tmux, vim, and fail2ban.
aptitude install build-essential git tmux vim fail2ban

# For more details on configuration options for fail2ban start here:
# https://www.digitalocean.com/community/articles/how-to-protect-ssh-with-fail2ban-on-ubuntu-12-04

Next we’ll need to setup user accounts for our pair. You can of course setup as many users as you want and run multiple tmux sessions, but that’s the topic of a future post.

Follow along with these commands, substituting your preferred usernames for “dave” and “dayton”.

Create Your Pairs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Create the wheel group
groupadd wheel
visudo
# Add the following line to the bottom of the file
%wheel ALL=(ALL) ALL
# Save and quit. (:wq)

# Create our pair users
# You'll want to substitude your own usernames for dave and dayton
adduser dave
adduser dayton

# Add them to the wheel group
usermod -a -G wheel dave
usermod -a -G wheel dayton

Now that we have your users setup with full rights (this is something you may want to change down the road), we can disable the root account and instead use a pair account.

Secure the Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Copy your shh key to the server
scp ~/.ssh/id_rsa.pub dave@198.199.xx.x:

# Login to your account
ssh dave@198.199.xx.x

# Enable ssh access using your rsa key
mkdir .ssh
mv id_rsa.pub .ssh/authorized_keys

# Now you should be able to ssh to the server using your key. Go ahead and try it. 
exit
ssh dave@198.199.xx.x
# If you have to enter a password, something went wrong. Try these steps again.

# Edit the sshd config
sudo vi /etc/ssh/sshd_config
# Disable root login
PermitRootLogin no
# Save and quit. (:wq)

# Reload ssh
sudo reload ssh

Now we have a fairly secure server with our pair accounts using password-less access and it’s time to setup the pairing environment. We’re going to use wemux which is backed by tmux to manage the sessions.

Wemux Installation

1
2
3
4
5
6
7
8
9
# Install wemux
sudo git clone git://github.com/zolrath/wemux.git /usr/local/share/wemux
sudo ln -s /usr/local/share/wemux/wemux /usr/local/bin/wemux
sudo cp /usr/local/share/wemux/wemux.conf.example /usr/local/etc/wemux.conf

# Change the host_list value to your pair usernames
sudo vim /usr/local/etc/wemux.conf
host_list=(dave dayton)
# Save and quit (:wq)

You are now the proud owner of a remote pairing environment.

Start pairing

It’s time to take it for a spin and make sure everything’s copasetic.

1
2
# Launch a shared tmux session.
wemux

You should now be running in a shared tmux session. One of your other accounts (pair2, etc.) can login and use the same command to join your session.

You will definitely want to checkout the wemux documentation for all of the configuration options.

RubyMotion Provisioning Profiles

I recently ran into an issue with RubyMotion where I couldn’t build to a development device without explicitly setting the provisioning profile in the Rakefile. Not only is this annoying, but it’s a big problem for team development because you’ll always want to check your Rakefile into source control and each team member would have a different Rakefile.

So I started hunting for a solution.

Official Documentation is Misleading

The RubyMotion official project configuration documentation states that it look for and use the first provisioning profile it finds on your computer. This is false though, at least when you have multiple profiles, because even if each of your profiles contains the device UID you’re building to, this still won’t work.

Existing Solutions Insufficient

The existing solutions are simply to explicitly refer to your provisioning profile in your Rakefile. That’s OK for solo development (but still annoying), however it’s not a good solution for team development.

See this stackoverflow Discussion

My Solution

After a little light reading I discovered that the RubyMotion build will check for a default profile named “iOS Team Provisioning Profile”.

So we simply need to create a new provisioning profile via the iOS provisioning portal named “iOS Team Provisioning Profile” and containing the device(s) we want to be able to run development builds on.

iOS Development With Ruby Motion

I’ve been building an iOS app with RubyMotion for a while now, and the verdict is…

I’m in love with RubyMotion.

Here’s why:

  • Ruby syntax runs circles around Objective-C syntax. If you’ve used Ruby and Objective-C for anything significant, and you’re not a masochist, then you know what I’m talking about.
  • It already has some amazing libraries like Teacup, BubbleWrap, and Formotion.
  • Building and deploying is a cinch with Rake. There’s even a testflight gem.
  • Bundler and CocoaPods for dependency management.
  • The REPL. I actually haven’t found this that big of a deal, but it can come in handy now and then.
  • I can continue using a text editor (vim or Sublime Text) instead of that hog called Xcode.
  • Really small archives.
  • The only (minor) downside so far has been occasionally translating example Objective-C code to RubyMotion code from Apple’s docs and Stack Overflow.

Learning VIM… Finally!

I had the opportunity to work with a bunch of TDD vim hackers during the last 4-5 months over at Nulogy, and after some initial resistance I decided to jump in and learn vim. My motivation is to really see if it lives up to the hype, and more importantly because it’ll make me look like a genius to the layman watching my screen (I.e. Gary Bernhardt).

I’ve tackled vim a few times over the years, but never fully committed to it. Since I believe you need to fully commit to something to do it well (including learning anything), I decided to pick up my touch typing first to really see the benefits of VIM.

Last week I achieved my typing goal of 75 words per minute, inspiration courtesy of Steve Yegge. I’ve since upped my goal to 90 wpm, but I think I’m at least quick enough now to really immerse myself into learning vim.

I’m starting with Peepcode’s Smash Into Vim, this Yehuda post, and of course the built in vim tutor.

Rock on!

Code School - Rails Best Practices Reviewed

Yesterday I ran through the “Rails Best Practices” course over at Code School.

I really like this interactive format. You watch a video / screencast covering a topic or set of topics, then you’re required to code up some excersizes to review the content of the video’s material before you can move on to the next topic.

Overall the format worked really well. The gamification (points etc.) didn’t make a difference for me, but it might be a motivator for some people. I do think they’re on to something here, and from the looks of it (also from the workd marketplace in their tagline) they’ll be refining this as a platform for use with other third party content.

The online editor was actually really well done. It’s not vim or emacs obviously, but it’s not super cludgy like you’d expect, so it works well enough for the small amount of material you’re covering.

I think there’s an opportunity to add in some social features so students can help each other if they get some harder topics going.

As for the content of the “Rails Best Practices” course itself, you can get the same content from here; http://rails-bestpractices.com/, however the code school environment was enjoyable enough.