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.

Sonic Pi – The Live Coding Music Synth for Everyone

by Ben

Sonic Pi
The Live Coding Music Synth for Everyone.

Welcome to the future of music.

Simple enough for computing and music lessons.
Powerful enough for professional musicians.
Free to download with a friendly tutorial.

Learn to code creatively by composing or performing music in an incredible range of styles from classical & jazz to EDM.

Source: Sonic Pi

The goal of these articles is to explore the relationships between music and code, by analyzing and recreating the track Aerodynamic from Daft Punk.

Unlike classical approaches to generate sound on a computer, we are going to generate sound by writing text: instead of adding tracks, instruments, samples… on a timeline, we will see how to express those in code and how to play music.

Source: Aerodynamic · mxs

OSC-over-UDP is just OSC packed data sent over a UDP connection. My first serious encounter with OSC-over-UDP was when I attended strangloop and talked about The Mess We’re In

I bumped into Sam Aaron, the unstoppable force behind Sonic Pi and said that it would be really cool to control Sonic Pi from Erlang. …

Sam told me that to control Sonic Pi all I had to do was send it OSC encoded messages over UDP.

Source: Joe Armstrong – A Badass Way to Connect Programs Togther

Module: TSort (Ruby 2.3.3)

by Ben

TSort implements topological sorting using Tarjan’s algorithm for strongly connected components

Source: Module: TSort (Ruby 2.3.3)

A new way of blogging about JavaScript, Clojure, and Ruby

by Ben

The klipse plugin is a small step toward Alan Kay’s vision: it is a javascript tag that transforms static javascript code snippets of an html page to live and interactive snippets.

Source: A new way of blogging about javascript

Available for Clojure, JavaScript, and Ruby.

Using splats to build up and tear apart arrays in Ruby

by Ben

One of the things that I love about Ruby is the depth of its features. You may use an operator, but do a little digging and you’ll find that you’ve only been scratching the surface of what it’s capable of. The humble splat operator (* and **) is a great example.

You’ve probably used splats for “catch-all” arguments. And that’s all that most people use them for.

This is useful, but you can use splats for a lot more. Let’s dive in!

Source: Using splats to build up and tear apart arrays in Ruby

heapfrag – Heap visualizer for Ruby

by Ben

This is a library for dumping and visualizing your heap in MRI.

Source: heapfrag – Heap visualizer for Ruby

Google Cloud Platform Blog: Ruby on Google App Engine goes beta

by Ben

We’re thrilled to welcome Ruby developers to the Google Cloud Platform, and we’re committed to making further investments to help make you as productive as possible. This is just the start — stay tuned to the blog and our GitHub repositories to catch the next wave of Ruby support on GCP.

Source: Google Cloud Platform Blog: Ruby on Google App Engine goes beta

Jay Fields’ Thoughts: Testing: One assertion per test

by Ben

Limiting your tests to using one assertion is a controversial topic. I originally stumbled upon the idea on Dave Astels’ blog. I liked the style of development that Dave described and decided to give it a try, that was over 2 years ago. Since then I’ve worked on teams ranging from 4 developers to 16, codebases in Ruby and C#, and project timelines ranging from 3 months to 8. I think it’s fair to say I’ve given the concept plenty of chances to fall down. But, regardless of the variables, the guideline has always remained valuable.

For me, the main motivator for using one assertion per test is the resulting maintainability of the test. Tests that focus on one behavior of the system are almost always easier to write and to comprehend at a later date.

Source: Jay Fields’ Thoughts: Testing: One assertion per test

Arlo Guthrie and the origins of the Collection protocol

by Ben

During the interview he [Dan Ingalls] was asked about the origin of those enumeration methods of the Smalltalk collection classes. Alan Kay had told the interviewer that they had come from a song. At first Dan didn’t remember this but then remembered that there was a song which had a string of words like inject, select, detect etc. As far as I recall, though he didn’t name the song.

Source: Arlo Guthrie and the origins of the Collection protocol

ICRuby for March 5th: Using Ruby to program a Sphero using Artoo

by Ben

From the Meetup event:

Joe Seeley will be giving an informal talk on Artoo, “a Ruby framework for robots, physical computing, and the Internet of Things.”  He’ll be bringing his Sphero and show us a couple of basic samples.

Thanks to Joe for volunteering to present!

Ruby Rogues on Pair Programming

by Ben

026 RR Pair Programming – Ruby Rogues –

I’ve looked this up too many times in conversations with coworkers, so I’m bookmarking it with this post.

These are their bullet points for the podcast:

  • Driver/Navigator vs Driver/Driver
  • One person writes a test, the other makes it pass (Ping-pong pairing)
  • It can be more productive
  • Code review
  • Shortens code review cycle
  • Higher engagement
  • Raises the quality floor
  • Pairing effectiveness
  • Less likely to rabbit hole
  • We learn from each other
  • Better code quality
  • Transmitting information
  • Lowers your bus number
  • Territoriality and knowledge silos
  • Learning new things from people who know how to do them better
  • Challenging peoples’ assumptions
  • Ability to roll new teams in
  • Pass on programming practices and culture
  • Lower defect rates
  • Fewer failed launches
  • Maintainability is higher
  • To get started:
    • Have a neutral setting for pairing. Location. Software. etc.
    • Use a text editor you’re both comfortable with.
    • Use driver/navigator.
    • Communicate well.
  • Keep your partner apprised of where you’re going
  • Pair programming is a learned skill
  • You have to get your ego in check
  • Reduce barriers to collaboration