Skip to main content

Benjamin Oakes

Photo of Ben Oakes

Hi, I'm Ben Oakes and this is my geek blog. Currently, I'm a Ruby/JavaScript Developer at Liaison. Previously, I was a Developer at Continuity and Hedgeye, a Research Assistant in the Early Social Cognition Lab at Yale University and a student at the University of Iowa. I also organize, ICRuby, OpenHack Iowa City, and previously organized NewHaven.rb. I have an amazing wife named Danielle Oakes.

Filtering for the month May, 2015. Clear

Android Auto, Apple CarPlay on many 2016 Chevy models

by Ben

From their press release, the following Chevy models will have Android Auto and Apple CarPlay support:

For those unfamiliar with Android Auto or Apple CarPlay, it lets you replace or supplement the infotainment system that comes with your car.  For example, you could use a music or navigation app running on your phone, rather than using the software that came with the car.  This will be especially interesting 10 years from now (2025!), when you might really wish you had a more up-to-date infotainment system in your 2016 model-year car.  These Android and Apple systems make it much easier to update how your car works, especially compared to physically removing part of your dashboard and replacing it.  Personally, I’ve been thinking it would be interesting just to leave an old smartphone in the car, charging over USB and loaded with music and maps that were downloaded over WiFi.

I’m especially intrigued by this because I’ve been considering a replacement for our 2003 model-year car, and it’s important to think 10 years ahead for such a big purchase.  (After all, we’re using a 2003 model-year car in 2015.)  While Android Auto or Apple CarPlay support isn’t likely to make or break our decision, it definitely has its benefits.

Miscellaneous JavaScript Reading

by Ben

Some JavaScript reading I’ve been doing since Iowa Code Camp last week:

Android and iOS apps on Windows: What is Microsoft doing—and will it work?

by Ben

Android and iOS apps on Windows: What is Microsoft doing—and will it work? | Ars Technica.

The way Microsoft presented the Android and iOS support on stage last week wasn’t particularly encouraging. The way that Projects Astoria and Islandwood—the codenames for Android and iOS app support, respectively—were promoted in the keynote presentation, one might think that the Android and iOS support were pretty solid substitutes for the Universal Windows Apps that are native to Windows 10 on all the hardware form factors it will support. It seemed like porting apps from those platforms would be an effective alternative to any plans to develop native Windows applications.

This is pretty crazy: Windows will support Android and iOS applications through compatibility layers.  I don’t really see the iOS layer getting a lot of traction just because it takes a lot of work, but the strong Android support is going to further entrench Android as a platform you can deploy to almost anything (second only to HTML5).

How to Save the Day with Git Remotes

by Ben

This post originally appeared on Continuity’s engineering blog. I’ve cross-posted it here for posterity.

Can’t push commits to GitHub, but need to move them to another clone? Adding another remote is a good option to get you out of a bind.

Why did this come up?

We do a lot of pair programming at Continuity. One of the great things about it is that if someone is out sick, you can usually depend on the other person to know the details of what was happening. But what if both people are out sick and they forgot to push their branch to GitHub and the deadline is today?

(That happened last week!)

The solution described in this post is a little specific to how we pair program remotely. Our team is almost 50% remote developers, and we all share access to the same EC2 instance. We use wemux and vim to pair (among other tools), and the provisioning is automated by puppet.

Back to the tale of the missing pair, one idea that came up was installing another SSH key to the missing person’s ~/.ssh/authorized_keys, but that has a number of problems:

Finally, installing keys on another user’s account just feels like a practice to avoid, if no other reason.

Instead, what we decided to do was to become their user via sudo (which is logged) and then push to a local clone of the git repository. That might sound complicated if you’ve only ever used git in combination with GitHub, but it’s actually a lot simpler than you’d think.

The Plan

What we’re going to do is push the absent user’s code to a shared directory, then pull it to your clone of the repository.

We’ll refer to the absent user as them and the user that needs access to the code as you.

How to

Just to set the stage, let’s look at the normal remotes for a clone from GitHub:

them$ git remote -v
origin (fetch)
origin (push)

What we’re going to do is make a remote on the local filesystem.

We’ll start by cloning into a shared directory (/tmp in this case):

them$ mkdir -p /tmp/git
them$ cd /tmp/git
them$ git clone

We know that the absent user has a branch with code you need:

them$ git branch
* feature/lol-i-will-be-here-tomorrow

So we’ll push it to that repo on the local filesystem:

them$ git remote add my-awesome-local-git-repo /tmp/git/your-repo/.git
them$ git remote -v
my-awesome-local-git-repo       /tmp/git/your-repo/.git (fetch)
my-awesome-local-git-repo       /tmp/git/your-repo/.git (push)
origin (fetch)
origin (push)

Then you can go back to your user account and pull it.

But first, you’ll need to make sure the /tmp/git/your-repo files are accessible. Since it’s a temporary clone, you could do something like this:

you$ sudo chown -R you:you .

And then go back your clone, add the remote, and check out the branch:

you$ git remote add my-awesome-local-git-repo /tmp/git/your-repo/.git
you$ git fetch my-awesome-local-git-repo
you$ git co feature/lol-i-will-be-here-tomorrow

And there’s the branch you needed! We’re all done in our scenario, so you could now rm -rf /tmp/git.


Git allows you to do a lot of interesting things like have a remote on the local filesystem, as described above:

$ git remote add my-awesome-local-git-repo /tmp/git/your-repo/.git

The remote on the local filesystem acts just like any other remote; it just happens to be hosted locally. There’s very little magic going on! It’s just a pile of files that git manages.

Another useful type of remote you can make yourself is a clone on another machine that’s accessible over SSH (and has the required git executables in $PATH):

$ git remote add my-awesome-remote-git-repo ssh://your-server/path/to/your-repo.git

That’s a lot like a private GitHub repo, but without any of the pretty web user interface or authorization management.

I hope this example helps illustrate that git is very flexible and can bend to your needs. If you’ve only ever used GitHub as a remote when using git, you’re missing out on some useful functionality! However, it’s it’s still best to have all your code in a central location, even though you could add a thousand remotes. Like any tool, know when to use it!