Categories
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: 

1.8.6 

1.8.6-p420-syckfix 

1.8.7 

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 https://github.com/rubinius/rubinius.git && 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.

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

Categories
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. https://speakerdeck.com/jasonrclark/diy-thread-dot-profile

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

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

Categories
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!

Categories
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
    Thread.new do
      … interesting work here
    end
  end

… 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
  end

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

  end

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