Installation rbenv Rubinius Ruby

Running Rubinius 2.0 with rbenv

With the release of Rubinius 2.0, I was keen to take a look at how hard it would be to get newrelic_rpm‘s tests passing against it. We make extensive use of rbenv on the Ruby agent team at New Relic, so I did the natural thing:

✔ ♥♥♥♥~: cd ~/.rbenv/plugins/ruby-build/

✔ ♥♥♥♥~/.rbenv/plugins/ruby-build: git pull 

✔ ♥♥♥♥~/.rbenv/plugins/ruby-build: rbenv install rbx-2.0.0

… but no joy. I ended up with an error that didn’t spell out the command it was running, but dropped this in the log:

/var/folders/_m/87xpgngn6d3_zpqh89dsdwxc0000gp/T/ruby-build.20131007124229.95689/rubinius-2.0.0 /var/folders/_m/87xpgngn6d3_zpqh89dsdwxc0000gp/T/ruby-build.20131007124229.95689 ~rbenv: bundle: command not found 

The `bundle’ command exists in these Ruby versions: 




Huh. Not exactly what I was looking for. At this point I was (and remain) a bit confused what’s trying to bundle during the installation, but clearly it isn’t finding what they need.

Luckily it wasn’t hard to work around and just build Rubinius directly. Inspired by this post, I ran:

✔ ♥♥♥♥~: git clone && cd rubinius 

✔ ♥♥♥♥~/rubinius: ./configure –prefix=~/.rbenv/versions/rbx-2.0.0 

✔ ♥♥♥♥~/rubinius: rake install

With that done, rbenv happily let me switch to rbx-2.0.0.

Although I didn’t run without it, I also use of the rbenv-rbx plugin for rbenv. At the moment there’s a pull request sitting to update the paths for Rubinius. I’m using that locally, and everything seems good.

I’m very curious if anyone has a good explanation of what went wrong with my initial rbenv install, since I need to install elsewhere and I’m not relishing building from source directly throughout our testing infrastructure.

Conferences Ruby

Make an Event of It!

Back in June, I spoke at my second conference, RubyNation. I’d been waiting a while to post about it until the video was up, but until then my slides are available online.

It was an awesome conference, not least for the chance to meet a number of people who I already followed and admire online–Avdi Grimm, Sandi Metz and Steve Klabnik. The Ruby community continues to prove itself as welcoming and friendly as I’ve always heard it is.

Will update if/when the video gets posted.

Conferences Ruby

DIY::Thread.profile – Light-Weight Profiling in Pure Ruby

First conference presentation, check! It was a great week in SLC visiting with friends and rubbing elbows with so many awesome Ruby folks. I might post some follow-up thoughts later on, but for now I wanted to be sure to link to my slides.

The ever awesome Confreaks were recording, so at some point a better video than the version will be up.

Ruby Talks

50 Line Profiler in Pure Ruby!

Yesterday was another first–my first presentation of any sort at a Ruby conference. I gave a 5 minute lightning talk at Ruby on Ales, the beeriest Ruby conference around.

Slides are up, the code is on github, and there’s even video at around 1:07:30.

This is a massively stripped down version of the talk I’ll be giving at MountainWest Ruby Conf early next month. It went well, and I’m really excited to run a longer presentation of the material.

Conferences Job Ruby

Two Firsts!

The first first, something I’ve written is live on the New Relic blog. Of course I’m also pretty pleased with the feature that it mainly discusses–Thread Profiling in Ruby–which is the first big chunk of code I’ve written that’s shipped so far.

Which actually leads to the next big news… I’ll be speaking at MountainWest Ruby Conf on Thread Profiling. This is the first talk I’ve had accepted to a conference, and I’m humbled to be on the same speaker page with Matz and Ward and so many other sharp folks. This time last year, I wouldn’t have dreamed that I’d be in this spot.

Working for New Relic is definitely paying off in more than just the day to day!

Ruby UnitTesting

Taming Asynchronous Testing

Ok, the title’s a bit overblown, but I encountered a fun bit of Ruby in working with threaded code.

My class’s primary responsibility was starting/stopping a loop on another polling thread. The basic shape of things ended up something like this:

  def start do
      … interesting work here

… which left a dilemma around testing. We forged down a path of setting the loop with timeouts and known counts, well knowing the perils. While these ran consistently enough locally, the time wasn’t always “enough” when we ran on our CI servers. We didn’t want to add tons of waiting in the unit tests, but cutting it too fine led to spurious failures on fussy VM’s.

I set out to revise the tests to be more deterministic. One prong of my attack was to provide functional/acceptance tests which could happily run with significant time buffers that would be cripplingly long in a unit test.

Unit tests, though, we remained a question. I toyed with passing in a stub to wrap the thread interactions, but because of the interactions that stub actually had to be plumbed through two separate classes to get where it was going. Ugly.

Could I use Ruby’s much vaunted openness to solve this? Of course! Instead of passing some other dependency, what if the Thread code was just replaced to work synchronously?

The statically-typed, C# side of my brain lurched at the thought, but it worked great. I created a FakeThread class that simply runs the block it’s given during initialize(). Other thread calls needed basic implementation in the FakeThread, but that was simple to accomplish.

With the fake class in hand, we needed to swap it in. However the naive approach:

  def setup
    Thread = FakeThread

… causes Ruby to gripe mightily:

  warning: already initialized constant Thread

But luckily we can “fix” that by removing the Thread constant from the module, then redefining it with our own implementation:

  def setup
    Object.send(:remove_const, “Thread”) if Object.const_defined?(“Thread”)
    Object.const_set(“Thread”, FakeThread)


Gnarly? Perhaps. I’d never consider this in production code. But the simplicity of splicing in the right dependencies into a test? It’s exactly what drew me to Ruby in the first place.

My coworker, when looking over the result, and hearing my bashfulness at having overridden a core class as Thread, concluded “Today, you are a Ruby programmer.”

Tools Vim

From VS to Vim

Given my background as a Windows developer, it’s no surprise most of my editing needs were met by the venerable Visual Studio. While at times a bit large and overloaded, VS was a familiar space. With Resharper and a judicious collection of keyboard shortcuts, I was quite happy with my world.

Of course, that all had to change.

Why Vim?
Since taking some grad classes, I’ve picked up vim when not on Windows. It never made the leap to day-to-day use, though. Notepad++ filled the gap when I didn’t need VS, but moving to New Relic and a Mac finally pushed me to vim full time.

There are other contenders–Emacs in the text editor world, and Sublime Text 2 if you’re looking for something more GUI-centric. Sublime falls down, though, since I really want to be able to work across ssh easily. With Emacs I figured I already have one new operating system, why take on another 🙂

Here are some of my favorite tweaks and tidbits regarding vim so far. I’ve posted my .vimrc at for posterity and sharing. Much of this was learned from the screencasts at and

Know the Basics
I claim no mastery, but I’m constantly pleased with the little features that I’m finding built into vim. Examples I’ve found in the last month of work:

  • When using :e to open a file, tab completion works perfectly
  • When using :b to change buffers, typing part of a filename will cycle through matches of that exact string anywhere in the path
  • << and >> will do indentation for you, per your current settings, without leaving normal mode. This works great with the multi-line visual block selections.

Anyone who’s been using vim a while probably wouldn’t think twice about these, but when you’re starting out they aren’t immediately obvious. Read up, watch screencasts, play around. There’s a lot of buried treasure there.

Love your Leader
To effectively edit, whatever the system, you need to learn the shortcuts. And when a critical shortcut isn’t available out of the box, you should define it. Wire those key presses into your muscles until you can do it in your sleep… or more to the point, while your brain is occupied with other things, like the problem at hand.

In vim, many shortcuts work off the so-called “leader” key. Following Bernhardt’s advice, I’ve remapped my leader to “,” which is super-accessible–lots easier than the default “”.

Most of my personal shortcuts follow with the leader key, from “,+r” to run tests on the current file, “,,” to go back to the last file.

I’ve tried to minimize the number of full-on vim plugins I use. I figure being able to do most of your work on an un/lightly optimized version of the software isn’t a bad thing.

But Command-T is indispensible. Coming from Resharper, with it’s CamelCase type/file search, for the first few days file navigation was a struggle, especially unfamiliar with the code base as I was. Then I saw this screencast on Command-T, and everything changed. (Sorry for the paywalled link, but Destroy All Software is totally worth it).

While Command-T doesn’t have type-level information, with sanely named class -> file mappings things act pretty similarly. I love typing any parts of the filename and having the list winnow down to all potential matches of that sequence.

While it has it’s quirks, I couldn’t live without Command-T anymore. I set my current directory just above my whole code-base so I can easily slip between files in any of the main projects.

Running Tests
This one’s pretty simple, but this command lets me quickly run unit tests for the current file that I’m on. While I’ve seen more complex setups for this–mostly around remembering the last file run–this works pretty well for now:

map <leader>r :w|:!~/.rbenv/versions/1.9.3/bin/ruby %<cr>

CTags fill some gaps in type information. Getting those generated properly is a topic for another time, though.

Once you have your tags files, you can easily integrate them into vim like this:

:set tags=ruby_agent/tags,multiverse/tags,rpm_test_app/tags

While I keep my current directory above all my code for Command-T access, I actually only want CTags from part of my tree. This line sets includes just the apps I want.

I also remapped some of the previous/next tag keys to <leader>+[ and <leader>+]. While I try to abide by the built-ins, these keys were just too badly spaced for me to live with.

Plenty of other things I’m learning day to day, but that’ll do for now. I’ve missed the full IDE experience less than I expected, though. Although refactoring and navigation aren’t identical, there’s been less struggle to fill the gaps–and more options opened by the deep customization possible–working with a basic text editor.

Nginx OS X Troubleshooting

Nginx Installation Woes on Mountain Lion

I needed to run the beta version of Passenger (3.9.1.beta) to see how New Relic’s Ruby agent fares against it, but hit a problem when installing Nginx for the first time.

Installing via passenger-install-nginx-module was resulting in this error:

Undefined symbols for architecture x86_64:
  "_pcre_free_study", referenced from:
      _ngx_pcre_free_studies in ngx_regex.o
ld: symbol(s) not found for architecture x86_64

Luckily, I found a solution via at The problem was an incompatible version of PCRE that ships with OS X. Once I removed the libpcre* files from /usr/lib, everything worked like a charm.

I’m finding that the *nix’y files that ship with OS X are often the root of a lot of issues if you’re trying to use newer versions of other software that depends on it. At least I didn’t have to double-click an MSI to get it done…

Job OS X

From Windows to Mac

In the move to New Relic, I’ve been looking forward to digging into a new OS. I’ve dabbled with Linux, but my spare tie for computers has been mostly devoted to languages (Ruby!) rather than operating systems.

The new job finally nudges me (who am I kidding, forcefully shoves!) to get used to something entirely different. Most of the company uses Macs–primarily Macbook Pro’s–and I am no exception.

In some ways, the shift to OS X is the least-familiar element of my changing environment. I’ve used Ruby before, and certainly have learned new languages plenty of times. I’ve tinkered with Vim for the past couple years, although never enough to use it day-to-day. But Macs? I hadn’t done much on them since college… the first time around.

Here’s what I’ve found awesome about OS X… and a few bits that bug the crap out of me.

Thunderbolt Display
I’m a huge proponent of dual monitors. It’s amazing how the extra real-estate changed my workflows for the better. I was even campaigning (with little hope of success) for a third monitor so it would look like a mad scientist’s setup provide a more ergonomic central monitor. I wouldn’t have considered going back to a single monitor…

… except for the gorgeous Thunderbolt monitor from Apple that is. Apparently once past a certain size, I stop craving the dual experience. And at 27″ is handily past that cutoff, with pixels enough to keep me happy. I haven’t felt a lack of space since making the switch. Partially, though, that’s aided by…

Years ago I tried a Windows app that gave the type of multi-desktop experience I’d seen in Linux. I fell in love immediately, but the software was too crashy to rely on. Sadly I relented, leaning eventually on the dual monitors for enough space. Every couple of years I’d browse in the vain for a suitable alternative.

OS X on the other hand, ships with Spaces built in. It’s just a Ctrl+Arrow key away. Heck, there’s even a gesture (a couple actually) on the trackpad. And with a setting in the System Preferences (check under Keyboard, on Mountain Lion at least), you can even move straight to a specific desktop pressing Ctrl+Number. This reminds me a lot of Window 7’s brilliant Win+Number feature for hopping between taskbar icons in all the best ways.

Spaces with the massive Thunderbolt has made task and window management a breeze, even without maximizing windows anymore.

Mighty Mouse
I wouldn’t have thought I’d post about a mouse. I’ve often referred to reaching for the mouse as a moral failing. But if you’re going to use a mouse, the Mighty Mouse is a step above the rest.

I’d never realized until using one how awesome a touch surface on your mouse can be. All the swipes I’ve gotten used to with my iPhone just work on the mouse. I can switch between Spaces, back up in my browser, and “naturally” scroll without thinking about it. The changeover from a mouse-wheel to the touch surface actually made the change to OS X’s reversed scrolling almost a non-issue, which is awesome.

The scrollbars suck, and I miss my Page Up/Down keys, but there you go.

While I haven’t used it for general searching, Spotlight is an adequate task launcher for my purposes. Command+Space and type the app name… after time on Windows 7, the pattern is entirely familiar. I’m just glad to be done with years of Win+R and memorizing Windows .exe names for quick launching.

Which brings us to the area where not all is raves about the change… keyboard shortcuts. I knew this would be tough, as I am a keyboard driven creature. Using different software has helped make a clean break in some ways, but a few things still catch me off guard after a couple weeks.

In ascending order of annoyance:

  • Alt+D doesn’t go to the address bar like it does in almost any address-able Windows app. Command+L gets it done, but I still end up almost-bookmarking pages repeatedly in Chrome
  • Ctrl+Arrow doesn’t move by words, it’s Alt+Arrow
  • Home/End goes to top/bottom of the document. Line movement is Command+Arrow

I swear I flip between Spaces at least twice a day still when I just wanted to slip my cursor over a word.

Ah well, if that’s the roughest thing in this journey, I got off easy!

Job OS X

New Relic: Week 1

My first full week at New Relic is in the bag. I can safely say that making the leap was a great choice.

First day, upon being shown to my desk, I was confronted with this shadow from the past:

The other devs started in on a whole spiel about how it’s a first day tradition to use the old Apple II, although they were vague about what precisely you had to accomplish. After the better part of 5-10 minutes, someone suggested you had to commit to the git repo from it. The awkwardness finally peaked, and everyone laughed. We packed up the Apple II, and I received my actual hardware, a brand spanking new Macbook Pro, huge monitor, and Mighty Mouse.

There are first day traditions beyond the purported Apple II, including committing a bug fix before the day is done. We had that finished up before lunch, which felt good.

Both of those experiences–the prank(s) and the getting-things-done of a first day commit–set the tone for my experience so far. I have felt welcomed and included, with folks introducing themselves left and right, good-natured fun and joking from the get-go, and lots of help whenever I need it. But that all comes along with a sharp focus on building great stuff.

One of my favorite small touches was the whiteboard in the main entry. On the first day it had a message welcoming me. I thought “That’s nice,” and didn’t think about it again. Then on Tuesday I showed up to this:

Each day a new message showed up, ending on Friday with:

That hints at the climate at New Relic. We’re growing quickly, with lots of new faces, and lots of excitement.

I’ll post more technical bits later, but the transition to OS X from a lifetime of Windows has been smoother than I expected. My first day it felt like all thumbs, but already I’m amassing new shortcuts and muscle-memory, customizing my tools bit by bit, and getting notably faster every day. Every day brings a pile of new things, large and small, to cram into my brain. From the intricate beauty of Ruby, to the Might Mouse’s touch gestures, to Vim addons… every day this week has stretched me exactly how I’ve been itching for.