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 TechCorridor.io, ICRuby, OpenHack Iowa City, and previously organized NewHaven.rb. I have an amazing wife named Danielle Oakes.

Filtering for the GitHub category. Clear

Fallback font for non-Mac users

by Ben

Recently merged into MailView:

Closes #27

Pretty simple: just add a fallback font family. Without this change, the headers (to, from, etc) are in Times New Roman on Linux, which looks really out of place.

Thanks for maintaining MailView!

SSH Agent Forwarding with Vagrant AWS

by Ben

The in-progress Vagrant AWS has a lot of promise, especially for devops. The ability to test your Puppet or Chef scripts on an EC2 instance using Vagrant is very tempting. Unfortunately, it’s not yet quite stable enough to rely on, in my experience. Some errors seem to happen sporadically. Most are related to ssh, although running ssh manually works fine (either vagrant ssh or ssh user@host).

Sometimes, something as simple as mkdir fails without reason:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mkdir -p '/vagrant'

Other times, rsync completes, but then it immediately terminates the instance:

[default] Rsyncing folder: /home/ben/aws-sandbox/ => /vagrant
[default] Terminating the instance...

I’m still hopeful that it can be useful to us in the future. Like I said, there’s a lot of promise in this young project.

At any rate, we took some time to research how to get SSH agent forwarding working, which is valuable for us when remote pairing. We were getting stuck with errors like this:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

It turns out that vagrant itself ignores anything but identity files, which was key to getting agent forwarding to work. This can be inspected using vagrant ssh-config

It turns out that lib/vagrant/util/ssh.rb can be modified like so:

--- a/lib/vagrant/util/ssh.rb
+++ b/lib/vagrant/util/ssh.rb
@@ -108,7 +108,7 @@ module Vagrant
         # IdentitiesOnly option. Also, we don't enable it in plain mode so
         # that SSH properly searches our identities and tries to do it itself.
         if !Platform.solaris? && !plain_mode
-          command_options += ["-o", "IdentitiesOnly=yes"]
+          command_options += ["-o", "IdentitiesOnly=no"]
         end
 
         # If we're not in plain mode, attach the private key path.

There’s a related change that can be made to make vagrant ssh-config match, but it seems to be cosmetic:

--- a/templates/commands/ssh_config/config.erb
+++ b/templates/commands/ssh_config/config.erb
@@ -6,7 +6,7 @@ Host <%= host_key %>
   StrictHostKeyChecking no
   PasswordAuthentication no
   IdentityFile "<%= private_key_path %>"
-  IdentitiesOnly yes
+  IdentitiesOnly no
   LogLevel FATAL
 <% if forward_agent -%>
   ForwardAgent yes

That was enough to get our SSH agent forwarding to work. These changes make sense in the context of AWS, but probably not in Vagrant at large. I’m tempted to make a pull request, but the above changes are a little half baked — and vagrant-aws still needs some fine tuning before the change can really be tested.

Maid v0.3.0 release!

by Ben

I released Maid v0.3.0 yesterday, after using Maid v0.3.0 Beta 1 for over a week myself. It was also downloaded 36 times, without any known bugs reported by beta test team.

From the change log:

I did have to make some expected changes from move to rename, however, but the warning messages for that show the new usage pretty clearly:

skipping move because foo is not a directory (use 'mkdir' to create first, or use 'rename')

Otherwise, work is progressing on the next version of Maid also. Hopefully there will be another beta soon.

But in the meantime, Maid v0.3.0 has already been downloaded 62 times. If you haven’t already given it a try, maybe Maid can help you with your spring cleaning… :)

Enjoy!

That’s not doing quite what you think…

by Ben

I recently helped an intern at Hedgeye work through a problem with a database query. Because I’m working in a separate timezone, I ended up making suggestions through a GitHub pull request. We discussed and decided that what I wrote was self-contained enough that I should re-post so it can help others.

:conditions => ["event_type != ?", 'LOGIN'||'LOGOUT'],

I don’t think this is doing quite what you think…

'LOGIN' || 'LOGOUT' # => 'LOGIN'

So this turns into:

where event_type != 'LOGIN'

I’m guessing you meant to do:

where event_type != 'LOGIN' or event_type != 'LOGOUT'

But, believe it or not, != is a MySQL proprietary extension to SQL. It would probably be best to use something that’s a part of ANSI SQL:

where event_type <> 'LOGIN' or event_type <> 'LOGOUT'
-- alternative:
where event_type not in ('LOGIN', 'LOGOUT')

Because these are literals (not user-provided values), there’s no point in sanitization using ?.

Conclusion:

:conditions => "event_type not in ('LOGIN', 'LOGOUT')",

database configuration does not specify adapter

by Ben

From an answer I wrote for StackOverflow:

Another possible cause:

In Rails 3.2.x, establish_connection has a default argument set from the environment:

From connection_specification.rb:

def self.establish_connection(spec = ENV["DATABASE_URL"])
  resolver = ConnectionSpecification::Resolver.new spec, configurations
  spec = resolver.spec

The way ConnectionSpecification::Resolver works depends on ENV['DATABASE_URL'] giving a nil if not set. (Normally, it would be something like postgres://...).

So, if you happen to have misconfigured DATABASE_URL such that ENV['DATABASE_URL'] == '', that will give you database configuration does not specify adapter.

Maid presentation

by Ben

Since I wasn’t able to make it to the newhaven.rb meetup, I ended up presenting about Maid at ICRuby today. I was happy there was quite a bit of interest.

I thought I’d share my (quick and dirty) slides and example scripts I created for the presentation. There’s no audio (besides the Ruby5 story), but you should be able to get a good sense of what I presented.

There were lots of good questions (which I wish I had written down), including how to use it with iTunes, how to use it as a replacement for logrotate, how I was using Vagrant for testing, how to automate more than set of rules, etc.

View the slides (or get the source markdown)

WindyCityRails 2012

by Ben

South Shore Cultural Center, Chicago

South Shore Cultural Center, Chicago
(Photo: Jeff Zoline CC BY-NC 2.0)

WindyCityRails was a lot of fun.

As I’ve done in the past, I took notes and put them into an open wiki on GitHub. Some quick stats: the wiki project is up from approx. 220 stars to 241 right now, and even got a few more contributors (~49 → 53).

Anyway, I thought I’d share some of the better talks:

* David Chelimsky: The RSpec Toolbox
* Evan Light: Frustration Driven Development
* Steve Klabnik: Development and Philosophy
* Several really good Lightning Talks

Both David Chelimsky and Steve Klabnik contributed to the wiki, which was a nice surprise. :) Steve’s talk was really good, but hard to do it justice with any notes… I was happy to see that he annotated it.

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).

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:

[[foo.jpg]]

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

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

Test upcoming browsers automatically via jsTestDriver

by Ben

We’ve been using jsTestDriver (JSTD) along with the Jasmine BDD library via jasmine-jstd-adapter. We’re also using some glue code I wrote called jasmine-jstd-conf which writes a jsTestDriver config file based on jasmine.yml.

Right now, we have some older, mostly-unused machines running a bunch of browsers attached to JSTD. While doing some maintenance today, I had an interesting idea: we need to support the browsers that are popular according to our analytics. That typically means the current and previous version, except for IE, which we support 7.0+ (9.0 is current).

However, we also need to support the next version of any popular browser.  Since Chrome and Firefox both have a beta channel of what is likey to be released as the next version, we can easily test whether any of our JavaScript will break in the new version of those browsers before they’re released and before a user runs into a problem we could have detected earlier.

So, we now have Chrome 16, 17 (current), and 18, along with Firefox 9, 10 (current), and 11.

Here’s some sample JSTD output from a Jasmine test suite we have:

Chrome 16.0.912.77 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (267.00 ms)
Chrome 17.0.963.56 Mac OS: Run 100 tests (Passed: 100; Fails: 0; Errors 0) (318.00 ms)
Chrome 17.0.963.56 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (196.00 ms)
Chrome 18.0.1025.39 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (209.00 ms)
Firefox 9.0.1 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (681.00 ms)
Firefox 9.0.1 Windows: Run 50 tests (Passed: 49; Fails: 1; Errors 0) (1598.00 ms)
Firefox 10.0 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (293.00 ms)
Firefox 10.0.2 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (260.00 ms)
Firefox 11.0 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (368.00 ms)
Microsoft Internet Explorer 7.0 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (2749.00 ms)
Microsoft Internet Explorer 8.0 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (2078.00 ms)
Microsoft Internet Explorer 9.0 Windows: Run 100 tests (Passed: 100; Fails: 0; Errors 0) (698.00 ms)
Safari 534.52.7 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (1553.00 ms)
Safari 6533.18.5 iPhone OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (184.00 ms)

With that many JavaScript implementations to support, writing automated tests only makes sense.

You might also be interested in the Testing Toolbox slides I presented at the NewHaven.rb October Lightning Talks.