Sessions at RubyConf 2011 about Metaprogramming

Thursday 29th September 2011

• Keeping Ruby Reasonable

  by Joshua Ballanco

  Pop quiz, hot shot! What is the value of this Ruby expression: "2 + 3"?

  What if I told you that somewhere earlier I had done this: "class Fixnum; alias :+ :*; end"? Changes everything, right?

  We're all familiar with Ruby's open classes. For many of us, they're one of the facets of Ruby that make it so much fun to work with. However, Ruby treats bindings as first class objects, and they are, similarly, open. This can lead to problems. What sorts of problems? Well, effectively, the only way to know what a Ruby program will do is to run it. Stated another way: it is impossible to reason about Ruby.

  Now, this may not seem like such a big deal for the seasoned Rubyist. So long as we're responsible in how we write our code and make sure not to do anything too crazy, we can have a pretty good idea of what any piece of code will do ahead of time. Unfortunately, compilers and runtimes can't rely on "responsible" programmers and having a "pretty good idea" of what code will do just doesn't cut it for a VM. As a result, method caches get invalidated far too often and whole classes of common optimizations do not work with Ruby.

  So, what's a programming language to do? Luckily, Ruby is not alone in facing this dilema. The Scheme community has been confronting similar issues from the very beginning, and in the R5RS and R6RS reports, they outlined a solution. This talk will take a look at what makes first-class environments and "eval" so problematic, and what lessons Ruby might learn from Scheme in how to be more reasonable.

  • Metaprogramming
  • Ruby

  At 4:20pm to 5:15pm, Thursday 29th September

  Coverage video

Friday 30th September 2011

• Services Inception with Ruby

  by Dave McCrory

  Ruby code creating services for it to then consume aka Service Metaprogramming

  A very large number of Ruby apps are deployed in hosted environments. Many of these hosted environments offer both internal and external services with APIs that your Ruby app can consume. The problem is that the use of these services often requires provisioning tasks for each service and the service must always be there or the app will fail.

  This session will show Metaprogramming Ruby code and a RubyGem for provisioning/de-provisioning, binding/unbinding, sharing configuration state, and more. This allows your application to create a Redis or MySQL instance only if needed (say on initial startup) or bind to a specific service, but only if/when it is present. This approach eliminates many of the forgotten steps during deployments and makes it easier to understand what your Ruby code really depends on because it is all encapsulated in the application’s code itself!

  • Metaprogramming
  • Ruby

  At 10:25am to 11:15am, Friday 30th September