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 April, 2012. Clear

My thoughts on GitHub for Mac

by Ben

I recently wrote a comment for “GitHub for Mac: Easier Updates”. Since it sums up my feelings on several subjects (including my feelings about the future of OS X), I thought I should repost it here.

Maybe more people use this than I realize, but I have to say I still don’t get this.

As a web developer myself, I tend to support web-based apps; perhaps the Mac app is popular with Mac/iOS developers? More can be done from the web interface, which works on Windows, Mac, and Linux. (Plus, the web UI always stays up to date.) The only additional feature this really seems to add is a “sync” button locally. Perhaps I’m missing something, but this is all that I take away from the feature list and what I’ve used of it.

To be honest, the direction in which OS X Mountain Lion is headed doesn’t thrill me. Since I’m contemplating a move from OS X back to Linux, it’s disappointing to see an interface for this closed system even being worked on. Such a huge amount of open-source projets are hosted on GitHub (including the Linux kernel itself). If I were to expect Linux support from anyone, it would be you guys. I can understand that OS X is likely a large market for GitHub users, but I would wonder about the portability of this app…

This would be much more compelling if it were an open-source interface for git repos, but I could understand how that might not be in GitHub’s best interest. (But imagine a GitHub tool built by the users, for the users…) Maybe I’m more of a git power user than I realize, but without at least support for a remote other than origin, multiple operating systems, etc., I can’t say this is something I’ll ever use. Making it open-source would be a bonus, although it seems unlikely at this point.

Maybe I’m just missing something, but other commenters here would seem to agree.

Update: By the end of the day, they deleted not only this comment, but many others that cast an unfavorable light on GitHub for Mac. (There was at least one other that had a function named shallWeUseThisSoft.)

In the interest of preservation, here are some other recently added comments that seem likely to be deleted:

From battlemidget:

At GitHub, we think that sharing code should be as simple as possible.
That’s why we created GitHub for Mac.

Where is the source code for this client so others can port it?

From GreatS:

Please do not distribute through the mac app store and if possible do not use an apple developer id to authenticate your apps so that we don’t end up with an ecosystem fully controlled by apple (see the gatekeeper non sense they are going to introduce in mountain lion).

Common configuration for production and staging

by Ben

Like many web apps, we typically have a need for a staging environment to test before we deploy to production. Combined with continuous deployment, it becomes much quicker and easier to find issues that would affect production by testing in this production-like environment.

This staging environment needs to be as close as possible to production; ideally the only things that are different are the data and some integration points. Having different behavior based on environment makes realistic testing difficult. Different configuration based on environment can also be problematic. In many ways, staging can be thought of as being based on production… but how does that work in pratice?

Rails doesn’t provide a built in idiom for a staging environment (the default environments are just “development”, “test”, and “production”), so many people have come up with their own way of managing the staging configuration problem. Many times the reality is that config/environments/staging.rb is a copied and pasted version of config/environments/production.rb along with some minor adjustments.

That’s ugly.

Here’s a more elegant strategy that we’re trying out:

# File: config/environments/common.rb
OurApp::Application.configure do
  # Common configuration goes here

  # Example:
  config.foo_bar = false

# File: config/environments/staging.rb
require_relative './common'

OurApp::Application.configure do
  # Any staging-specific configuration goes here.

# File: config/environments/production.rb
require_relative './common'

OurApp::Application.configure do
  # Any production-specific configuration goes here.

This allows us to set a baseline “production” configuration, but still override settings as necessary. It seems to reduce the amount of manual maintenance (“syncing”) of enviroments in the way we were hoping too, so we don’t accidentally let a configuration change go untested until a production deployment.

(Technical info: this was written against Ruby 1.9.2p180 and Rails 3.2.3.)

How do I embed images inside a GitHub wiki (gollum) repository?

by Ben

After pushing images into the wiki repository (clone, add images, push), you can use relative paths like so:


For more info, see the demo wiki’s page on images.

Update (2012-05-02): This is part of my answer on StackOverflow.