I think I first discovered the joy of take and drop in my journeys through Haskell. But it appears that, since 2008 at least, we have had the pleasure of using them in Ruby too.

Need the first or last N elements from an Enumerable. Easy!

ary = (1..100).to_a
ary.take(5) # => [1, 2, 3, 4, 5]
ary.drop(95) # => [96, 97, 98, 99, 100]

range = (1..100)
range.take(5) # => [1, 2, 3, 4, 5]
range.drop(95) # => [96, 97, 98, 99, 100]

hsh = {:foo => 1, :bar => 2, :baz => 3}
hsh.take(1) # => [[:bar, 2]]
hsh.drop(2) # => [[:foo, 1]]

The real magic is when you use take along with other Enumerable goodies like select and map. Here’s one of my personal favorites amongst the code I wrote in 2010:

class QueryTracer < ActiveSupport::LogSubscriber

  ACCEPT = %r{^(app|config|lib)}.freeze
  FRAMES = 5
  THRESHOLD = 300 # In ms

  def sql(event)
    return unless event.duration > THRESHOLD
    callers = Rails.
      backtrace_cleaner.
      clean(caller).
      select { |f| f =~ ACCEPT }.
      take(FRAMES).
      map { |f| f.split(":").take(2).join(":") }.
      join(" | ")

    # Shamelessly stolen from ActiveRecord::LogSubscriber
    warning = color("SLOW QUERY", RED, true)
    name = '%s (%.1fms)' % [event.payload[:name], event.duration]
    sql  = event.payload[:sql].squeeze(' ')

    warn "  #{warning}"
    warn "    #{name} #{sql}"
    warn "    Trace: #{callers}"
  end

end

QueryTracer.attach_to :active_record

This little ditty is awesome because:

• It’s super-practical. Drop this in your Rails 3 app, tail your production log, see the slow queries, go to the method in your app calling it, and fix it. Easy.
• It only activates itself when it’s needed. Queries that execute quickly return immediately.
• No framework spelunking required. Rails 3’s notification system handles all of it. Rails’ backtace cleaner gizmo even makes the backtraces much nicer to read.
• It chains methods to make something that reads like a nice, concise functional program.

For more Enumerable joy, read up on each_cons.

I was building an API wrapper this weekend. As is common when writing these sorts of things, I found myself needing something that takes semi-structured data (hashes parsed from JSON) and yields Ruby objects that are easy to work with. I’ve always found myself hacking these sorts of things together on a somewhat ad-hoc basis. It’s a fun, but a bit of a yak-shave.

This time around, I decided to see if the state of the art has advanced in this realm. Luckily, I reviewed Wynn Netherland’s slides from Lone Star Ruby Conference and found exactly what I needed.

Where have you been all my life?

Intridea’s Hashie is a library built on the notion of making hash-like data structures act a little more like objects and a little easier to work with. I have literally wanted something like this for years!

Suppose you have a hash like the following:

hash = {
  "name" => "Adam",
  "age" => 31,
  "url" => "http://therealadam.com"
}

Coding up an object to store that isn’t too hard, but writing the code that pulls values out of the Hash and tucks them away in the right attribute on the object gets tedious quickly. Hashie’s Dash class makes this trivial.

class User >Hashie::Dashie
  property :name
  property :age
  property :url
end

Its even more delightful to use:

user = User.new(hash)
user.name # => "Adam"

Tons of boilerplate code, eliminated. My life is instantly better.

A great use of inheritance

It’s been pointed out that ActiveRecord’s use of inheritance is somewhat specious. To argue that “user is-a ActiveRecord::Base” takes a bit of hand-waving. So lately, you’ll find lots of libraries insinuate themselves into classes as a mixin, rather than as a parent class. This is a little bit of you-say-potato-I-say-potato, but whatever.

In Hashie’s case, I think that inheritance is being used correctly. All of the classes that Hashie provides (Mash, Dash, Trash and Clash) inherit from Hash. So the is-a relationship holds.

Sugary data structures taste great

While I’m going on about inheritance, here’s how I used to create these sorts of wrapper classes:

User = Struct.new(:name, :age, :url)

For creating simple objects that just need to hold onto some data, I really like this approach. If they end up needing data, it can easily grow up:

class User < Struct.new(:name, :age, :url)
  # Behavior goes here
end

I like what Hashie is doing even more though. Its enhancing a core class in a largely unobtrusive way, and doing so from the confines of a library that only those who need it can pull from.

I’d love to see more libraries like this that add extra sass to Ruby core library. An Array that pages values out to disk on an LRU-basis perhaps, or a bloom-filter based Set, perhaps?

I’m excited about languages like Erlang, Haskell, Scala, and Clojure and what they can bring to the adventurous developer. Despite that, I feel strongly that Ruby still has plenty of really nifty tricks up its sleeve.

(It so happens I’m presenting this at Dallas.rb tonight. Hopefully it can also be useful to those out in internetland too.)

RVM gives you three things:

• an easy way to use multiple versions of multiple Ruby VMs
• the ability to manage multiple indpendent sets of gems
• more sanity

First, let’s install RVM:

• gem install rvm
• rvm-install
• follow the directions to integrate with your shell of choice

Now, let’s install some Rubies:

• rvm list known will show us all the released Rubies that we can
  install (more on list)
• rvm list rubies will show which Rubies we have locally installed
• rvm install ree-1.8.7 gives me the latest release of the 1.8.7
  branch of Ruby Enterprise Edition
• rvm install jruby will give me the default release for JRuby
• rvm use jruby will switch to JRuby
• rvm use ree will give me Ruby Enterprise Edition
• rvm use ruby-1.8.6 will give me an old and familiar friend
• rvm use system will put me back wherever my operating system left
  me

The other trick that RVM gives us is the ability to switch between
different sets of installed gems:

• Each Ruby VM (JRuby, Ruby 1.9, Ruby 1.8, REE) has its own set of
  gems. This is a fact of life, due to differing APIs and, you know,
  underlying languages.
• rvm use ruby-1.9.1 gives you the default Ruby 1.9 gemset
• rvm use ruby-1.9.1%acme gives you the gemset for your work with
  Acme Corp (more on using gemsets)
• rvm use ruby-1.9.1%wayne gives you the gemset for your work with
  Wayne Enterprises
• rvm use ree%awesome gives you the gemset for your awesome app
• You can export and import gemsets. This can come in handy to bring
  new people onboard. No longer will they have to sheepishly install
  gems on their first day as they work through dependencies you long
  since forgot about.

Some other handy things to peruse:

• Some workflow examples
• CLI options

I also promised you some extra sanity:

• RVM knows how to compile things, put Rubygems and rake in place, even apply patches and pull from specific tags. You can do more important things, like watch The View or read an eleven part series on pre-draft analysis for the Cowboys.
• RVM lets you isolate different applications you’re working on. Got one app that doesn’t play nice with Rails 2.x installed? No problem, create a gem environment for that! Stuck in the spider-web of Merb dependencies? Isolate it in its own environment.
• RVM makes multi-platform testing and benchmarking easy. You can easily run your test suite or performance gizmo on whatever Rubies you have installed.
• RVM makes it easy to tinker with esoteric patchlevels and implementations. For instance, feel free to tinker with MagLev or the mput branch of MRI.

A couple other things RVM tastes great with:

• Using homebrew to manage packages instead of MacPorts
• Not using sudo to install your gems
• Managing your dotfiles on GitHub