Holy Chao : Holy Chao | Being a collection of deranged ramblings regarding Discordian tainted independence, and other such rubbish

"What the hell is going on with everyone?" - Our increasing awareness of misogyny

2012-03-24T13:43:26Z

My CEO/friend/person who's fired me twice Justin Gehtland exclaimed on the twitters yesterday: "What the hell is going on with everyone? Boston API Jam, Belvedere Vodka, Santorum. Is it National Misogyny Month and I missed the PSA???" I glibly replied: "People started paying attention to misogyny and calling it out. The misogyny didn't increase, your visibility into it did."

I find this basically true and explanatory, but after a few hours of reflection and home improvement I'd like to discuss it in further length than 140 characters allow.

I think we are seeing a consequence of a few important factors, and I'd like to describe a couple. First I'd note that our increased social interaction and eased communication have resulted in more people having more empathy with others. Secondly, in the U.S. we are in the middle of a Republican primary election where the defining attributes of the debate for many outside observers, including me, includes who can behave the most misogynistic.

I find the first of these particularly encouraging; it suggests our movement toward a more egalitarian and sympathetic world. This movement has used technology as a lever, which I find pretty cool considering how I spend most of my vocational efforts. People can more easily object to, for instance, including women as an item on a bulleted list of highlights to voice their objections and to have those objections reinforced in a meaningful way today. This ad hoc organization of protest demonstrated material consequences in the real world: the sponsors of the Boston API Jam started pulling their financial support. The organizers accepted the fact they upset a significant number of people they tried to make money off of (they mismanaged it pitifully, but that's a different concern). Everyone else who organizes events now has to wonder if they will cross the same line. The organizers, Sqoot, do not appear to directly engage with the public, but with businesses. It appears they still feel consumer backlash; in 2012, every company is consumer facing. These material consequences amplified the visibility of the issue as well.

Right now people understand that there are financial consequences for failing to conduct themselves in a way considerate of women. This is a consequence of a social reality, the financial consequences only exist as long as a sufficient number of people care to enforce them, but right now, it does exist. This is great. It might even form the foundation of lasting, meaningful social reforms that further undermine the disequality many women in the U.S. experience today.

However, I find the second point cuts at how much confidence I can have in this prospect for meaningful progress in our social consciousness. We have a caustic political environment in the U.S., one that precipitates far more negativity and vitriol than it does pride and inspiration. Many people's political identities are defined by what they oppose, rather than what they promote. Worse still, these identities do not always derive from opposition to repugnant principals, but by opposing principals held by a repugnant political opposition.

Some hard questions I do not think we can find the answers to today, but that do concern me: Would there be these same outcries against misogyny if they were not the sword with which Rush Limbaugh was attacked? Would people find the Boston API Jam ad offensive if we were not in the midst of a Republican primary advocating vociferously for stripping women of self-determination over what happens in their own bodies? Will the social reality that casual misogyny will precipitate calamitous financial ruin persist past November?

These are hard questions because they essentially ask how we as people will behave in the future, or would behave in counterfactual scenarios. Only our future conduct, collectively, will determine the answers.

Typo needs to work on their migrations...

2012-02-06T21:55:01Z

I use Typo, because I like Rails, and it's free, and the feature set is pretty nice. But often I find that migrating between major versions sucks.

I just upgraded to 6 from 5, and experienced a problem every time I tried to read an article imported from 5. The failures looked something like:

ActionView::MissingTemplate (Missing template /articles with {:handlers=>[:erb, :rjs, :builder, :rhtml, :rxml], :formats=>[:html], :locale=>[:en, :en]} in view paths "/blog/themes/scribbish/views", ...)

After digging around a bit I found the culprit.

New Typo apparently supports multiple presentations for content, and now has a 'post_type' column in the contents table. If you write a new article in Typo 6, it will get the value 'read'. I went to my database and updated all the old contents to have post_type of read. e.g.

UPDATE contents SET post_type='read' WHERE post_type IS NULL;

After this, all my blog posts worked.

REE has a special trick...

2012-01-16T15:22:31Z

If you're trying to install REE with RVM, and you just, for example plug in the following

rvm install ree-2011.03

It doesn't work terrifically under OS X

It also serves as a local minima of functionality, in that it will get caught with the failure condition even if you remember to add something like:

rvm install ree-2011.03 -C --with-readline-dir=/usr/local

after having done the wrong thing.

You need to do the following:

rvm cleanup all
rvm install ree-2011.03 -C --with-readline-dir=/usr/local

Try not to BCrypt so much.

2011-08-13T10:14:42Z

At Relevance, one of our favorite tools to use is Devise. It has become the de facto standard for authorization when we need a solution, and with good reason. It solves a specific problems and plays nicely with others.

However, it can totally ruin your test suite's performance.

By default, Devise ships configured to use bcrypt. If you investigate your config/initializers/devise.rb file, on or about line 64 you should see something like the following:

config.stretches = 10

Shortly put, this is configuring the computational complexity bcrypt will calculate encrypted passwords with. This is a pretty cool feature of bcrypt, and it is a valuable security feature in its default configuration. If for some horrible reason, someone gets a hold of all the encrypted passwords in your db, the amount of time it will take to brute force crack the passwords with this default strength is sufficiently long as to allow you plenty of time to react and change passwords. (Assuming you are aware of the breach...)

However, if you're using factory_girl and rspec (as we do), and generate a bunch of devise users who happen to have passwords (as we do), then you'll spend a lot of time in your tests calculating encrypted passwords with this config. There are some other solutions out there (mentioned in this github issue) for getting around the bcrypt bottleneck when testing. Jason Rudolph and I have a better one though.

First, change the line in your config/initializers/devise.rb from

config.stretches = 10

config.stretches ||= 10

Then in your config/environments/test.rb add

Devise.setup do |config|
  config.stretches = 1
end

This configures your app to by default use an aggressive bcrypt strength, but allows you to override that configuration on a per environment basis.

Kicking butt with CoffeeScript, Underscore, and Backbone

2011-05-24T15:20:14Z

I've recently had the opportunity to work with some really exciting JavaScript tools that make developing apps that run in the browser much more powerful and managable than I've been accustomed to working with in the past. The trio of tools I am specifically interested in is CoffeeScript, Underscore.js and Backbone.js. I am specifically targeting technical audiences for this work, I will be assuming a good deal of comfort working with JavaScript, the DOM, and jQuery already. Additionally I will assume you understand Rails well enough to build a trivial app in it.

I'll start with a high level overview of the purposes of each of these tools.

CoffeeScript is a language built on top of JavaScript which puts a large deal of syntactic sugar in place to ease its crafting. It additionally emits JavaScript with several best practice idioms, and its output is generally built in order to pass Lint checks. The syntax is highly reminiscent of Ruby. When integrating CoffeeScript to a Rails app with Sprockets, source files will be compiled down to JavaScript on the fly providing a pleasantly responsive development cycle.
Underscore.js is a library of clever utility functions. It includes mechanisms for templating, functional programming, and compensating for some of the curious interactions of JavaScript operating against a DOM in a browser. Many of its offerings seem redundant when compared with jQuery, and often in fact are. jQuery strongly focuses on DOM elements however, while Underscore plays very nicely with arbitrary javascript objects. This makes it a valuable tool when you start to embed non-UI logic in JavaScript applications.
Backbone.js is a MVC library for JavaScript. Compared with SproutCore or Cappuccino, it is lighter weight and significantly decoupled. (To be fair, SproutCore is currently undergoing modularization efforts to reduce it's footprint.) Backbone.js features Models and Collections for modeling your data, Controllers for routing to functions, and Views for binding DOM fragments to functions and model data.

CoffeeScript

CoffeeScript is a language built on top of JavaScript to provide tools for easily creating code which adheres to best practices. It features:

Syntactic whitespace. Indenting a level creates a new JavaScript block.
Terse syntax. Common tasks like defining functions and referring to this are conveniently abbreviated.
Stricter scoping. JavaScript eagerly places things in global scope, but CoffeeScript generally creates immediate functions. By placing code in immediate functions, CoffeeScript constrains your work to local scopes by default.
Controlling binding. When binding functions of an object to events on some DOM element in JavaScript, this will, without some intervention, be bound to the DOM element instead of the object the function is defined for.
Splats. You can define functions of variable optional arguments using ellipsis.
Default returns. Much like Ruby, the last expression evaluated in a function is automatically returned to the caller.
Destructuring assignment. CoffeeScript makes it easy to pull apart maps and arrays
String interpolation. CoffeeScript lifts Ruby's string interpolation mechanics out wholesale.

This is a high level manifest of what you can get by using CoffeeScript. For more details, visit the website.

Backbone.js

Backbone is an MVC library which provides strong, decoupled foundations for building UIs. Its chief components are:

An event system which can be mixed into arbitrary objects using _.extend()
Controllers, which route from location hashes to controller methods.
Models and Collections, both designed to proxy remote objects communicated with JSON. If you subscribe to the contract of accessing all model attributes using the get and set methods, then event propagation will occur to queue changes in your views.
Views, designed to bind together a DOM element and an object, to catch events in the relevant fragment of the DOM, and to invoke changes to the model.
History, creating a chain of discrete UI states that can be reloaded and navigated using browser history functions.

We'll cover relevant tools in Underscore as we cross them. It is such a mixed bag that I do not see much value in providing an overview.

Let's build something!

I'll build a super trivial kanban board for this app. Our domain will consist of cards and lanes. Cards will have a name and a description. They will be placed in one of four lanes: Open, Development, Test, Approved. New cards will arrive in Open, and then transitions will move them forward and backward in the path until they reach Approved. My architecture will be built out of a Rails server which will serve up static resources to form the client app, and provide JSON endpoints for managing a shared state of the board. All user facing work will be done in CoffeeScript, or in HAML to produce templates that will end up as the content of Backbone views. Rails will not render any HTML as a result of actions in this example, an artificial restriction put in place to more put more weight on JavaScript. My work will be published as a github project for reference so that you can compare notes.

I started by making a new Rails 3.1 app. I used rspec and haml for testing and templating respectively. I set up Card and Lane models and controllers. Lanes have many cards, and optionally previous and next lanes. Seed data creates an Open lane by default, and all cards are by default placed in the Open lane. I set up a default application layout and a Templates controller for serving up HTML fragments that will make up the UI. If you'd like to play along at home you can look at the state of the project at this point here. I have:

Seed data for 4 lanes.
A JSON endpoint that lists all the lanes
A default route going to the templates controller, and a default layout that includes our application.js

Getting down to brass tacks

I'll start off with getting my dependencies in place. Rails 3.1 ships with jQuery and CoffeeScript as the defaults, this part is already taken care of for me! I'll need to add Backbone and Underscore still. I pull down underscore and backbone to the app/assets/javascript directory:

wget -O app/assets/javascripts/underscore.js documentcloud.github.com/underscore/underscore.js
wget -O app/assets/javascripts/backbone.js documentcloud.github.com/backbone/backbone.js

Next I'll need to add require statements to app/assets/javascripts/application.js:

//= require underscore
//= require backbone

As a first cut of getting a handle on backbone goodies, I'll set up a trivial first action for our backbone app. I want to do the following:

Trigger a default controller action.
Pull down all the lanes into a Backbone collection.
Create a view on that collection that logs it's contents to the browser console.

This won't be much of a view, but it demonstrates a lot of the basic functionality of Backbone. It will not demonstrate the binding of model data to views a user can see.

The controller is pretty simple, let's take a quick look:

#Define LanesController on this to put it in the global scope.
this.LanesController = Backbone.Controller.extend
  # Set up the routing map. The default route will go to the
  #  LanesController.index() function.
  routes:
    "": "index"

  # Fetch the data for the initial page, and display a view with it.
  index: ->
    lanes = new Lanes()
    lanes.fetch()
    board = new LanesIndex(model: lanes)

Some pieces to note here:

When CoffeeScript compiles to JavaScript, it wraps everything in an Immediate Function to keep it from polluting the global namespace. It also takes the binding of "this" from the scope where that Immediate Function is called, and propagates it into the body of the function, so that this is going to be bound either to window in the case of a browser, or globals in node.js. By defining things on this, you explicitly put them in the global namespace.
The default route in Backbone is the empty string. To initialize CoffeeScript's controller logic, you initialize one or more controllers, and then call Backbone.history.start(). It will then route to the default route if there is one, and start monitoring the location hash in order to trigger changes in the controller.
The index function is pretty brief, it just reads some data and then hands it to a view.

Let's take a look at the models now.

this.Lane = Backbone.Model.extend
  # When a backbone model receives a JSON blob in
  # its constructor, it shoves all of the JSON properties
  # into an internal attributes hash. These are exposed by
  # get(name) and set(name, value) methods on the model.
  # You can directly access the attributes hash, but if 
  # you shove values directly into it event propagation won't
  # happen. SO DON'T DO IT! 
  name: ->
    @get("name")

# Lanes is a collection of multiple Lane instances
this.Lanes = Backbone.Collection.extend
  # Request URL with XHR to pull down, returns
  # a JSON blob.
  url: "/lanes.json"
  # Specify what this collection is a model of.
  # With this set, you can hand JSON blobs to the collection
  # and it will add new Backbone Models instantiated
  # from those JSON blobs.
  model: Lane
  # Parse accepts a JSON blob representing a collection of multiple
  # model objects. It returns a list of instantiated models. We get
  # an Array of JSON blobs back from Rails, so we can just shove
  # them in objects and we are off to the races.
  parse: (response)->
    _.map(response, (laneJson) ->
      new Lane(laneJson))

This is pretty trivial. I just want to expose the name of a lane with a convenience method, fetch a list of all the lanes from the server as a JSON result, and create lanes from the JSON result.

Backbone is smart enough to do the right thing with the url property regardless of whether it is a string or a function. If you define url as a function, you can issue dynamic queries for filtered collections.

Finally I'll implement half of a view. Why half? Views do two things: they bind to data, and they bind to HTML in the page. They are not responsible for specifying a presentation (unless you implement it yourself). They do provide convenience methods for declaratively binding to events in the DOM element which they own, and they will also conveniently bind this to the view, instead of the element which fires the event. First I'd like to demonstrate the binding to data, and then we can create some HTML and present it to the user in a later step.

this.LanesIndex = Backbone.View.extend
  # Initialize is called at the end of the view
  # constructor to set up the new view. You can bind to
  # events on the model this view was constructed for,
  # and do other housekeeping tasks here.
  initialize: ->
    # bindAll accepts an object and a list of function names.
    # It then binds this in the body of each of those functions
    # to its first argument. In the example below, without using
    # bindAll this would evaluate to the collection firing the event
    # instead of the view to be rendered.
    _.bindAll(@,"render")
    # When a collection fetches its contents from the server, it
    # fires a "refresh" event upon successfully parsing the contents
    # of the response. We re-render this view when the contents change
    # to keep the presentation to the user up to date.
    @model.bind("refresh", @render)
  # Render is a no-op by default, but the intent is to stuff data
  # from the view's model into the HTML element the view is holding onto.
  # At this stage in the example app, we are simply logging all of the Lane
  # objects to the browser console.
  render: ->
    _.each(@model.models, (model) ->
      console.log(model.name()))
    @

Now I have all the code I need. I put my backbone files in controllers, models, and views directories under the javascript directory, and then embed them in application.js like so:

//= require models/lanes
//= require views/lanes-index
//= require controllers/lanes-controller

I'm almost done. Now that all the backbone work exists, I need to invoke it. It's pretty easy! Just initialize the controllers that need to be active in the application (no need to hold onto the instances though!), and then call Backbone.history.start()

new LanesController()
Backbone.history.start()

The default route on LanesController will fire when the page is first visited, and if you load up the app it will log the names of the seed lanes to the console. For those playing along at home, you can check out the tree at this point. If you load it up, you should see the lane names logged to the console.

Now let's start working on presenting information. Your options with generating content to stick in the page are enormous, there are numerous templating systems available for JavaScript. If you'd like you could build dom elements dynamically and insert content as appropriate. I'm going to use underscore's templating system, for two simple reasons. First, we need underscore for Backbone, so there's no extra effort to incorporate it. Second, underscore's templating performs reasonably well in the spectrum of Javascript templating tools. I have experienced some issues with the stack depth when using underscore templating though, so if you have nested templates, contemplate the appropriateness of using underscore before you commit to it.

I like to take the approach of putting templates on the server and pulling them down when the app loads. I added a "lane" action to the templates controller, it returns the following HTML fragment:

<div class='lane'> 
 <div class='lane-name'> 
  <%= lane.name() %> 
 </div> 
 <div class='lane-cards'>
 </div> 
</div>

That ERBish looking bit is recognized by underscore as an escape. When you turn this into an underscore template, it will call the name method on lane, and fill in the content with the return value of name.

Next, here's a little bit of code to prefetch all of the templates before starting up the app.

this.KoffeeTemplates = {
  templatesUrls:
    lane: "/templates/lane"
  triggerReady: ->
    @trigger("ready")
  init: ->
    _.after(_.keys(@templatesUrls).length, @triggerReady)
    _.each(@templatesUrls, (path, name) ->
      $.get path, (data) ->
        KoffeeTemplates[name] = data
        KoffeeTemplates.triggerReady()
    )
}
_.extend(KoffeeTemplates, Backbone.Events)

This little bit of utility lets me specify templates on templateUrls. It will fetch the contents of those urls and add them to the KoffeeTemplates object as strings. I can add more templates by defining them on templatesUrls. E.g. if I wanted a card template, I would change

  templatesUrls:
    lane: "/templates/lane"

  templatesUrls:
    lane: "/templates/lane"
    card: "/templates/card"

With this change, when the "ready" event fires KoffeeTemplates.lane will return the lane template, and KoffeeTemplates.card will return the card template. I'll need to change our initialization in application.js to fetch the templates and then initialize the application. After the appropriate changes, application.js looks as follows:

//= require jquery
//= require jquery_ujs
//= require underscore
//= require backbone
//= require koffee-templates
//= require models/lanes
//= require views/lanes-index
//= require controllers/lanes-controller
KoffeeTemplates.bind("ready", function() {
  new LanesController();
  Backbone.history.start();
})
KoffeeTemplates.init();

As I'm no longer logging things to the console, it'd be good to have my content actually affecting the DOM. I'm going to hook up the view's element to be the contents of the body tags by changing the LanesController.index method as follows:

  index: ->
    lanes = new Lanes()
    board = new LanesIndex(model: lanes)
    $('body').append(board.el)
    lanes.fetch()

Finally, I rewrote the view to render as a function of the lanes it holds. The new LaneIndex view looks like this:

this.LanesIndex = Backbone.View.extend
  tagName: "div"
  id: "board"
  # Initialize is called at the end of the view
  # constructor to set up the new view. You can bind to
  # events on the model this view was constructed for,
  # and do other housekeeping tasks here.
  initialize: ->
    # bindAll accepts an object and a list of function names.
    # It then binds this in the body of each of those functions
    # to its first argument. In the example below, without using
    # bindAll this would evaluate to the collection firing the event
    # instead of the view to be rendered.
    _.bindAll(@,"render")
    # When a collection fetches its contents from the server, it
    # fires a "refresh" event upon successfully parsing the contents
    # of the response. We re-render this view when the contents change
    # to keep the presentation to the user up to date.
    @model.bind("refresh", @render)
  # Render is a no-op by default, but the intent is to stuff data
  # from the view's model into the HTML element the view is holding onto.
  # At this stage in the example app, we are simply logging all of the Lane
  # objects to the browser console.
  render: ->
    laneTemplate = _.template(KoffeeTemplates.lane)
    _.each(@model.models, (model) =>
      $(@el).append(laneTemplate(lane: model)))
    @

With this code in place, it renders full page columns for our cards to live in, one column for each lane. As usual, those following the examples can view the tree here.

BAMFCSV - BAMF, your data's here!

2011-05-06T09:36:38Z

Rivaling the amazing transitive powers of Nightcrawler, Jon Distad and I decided to tackle the problem of parsing CSV rapidly under Ruby 1.9. "Aha!" you might be saying, "FasterCSV was already rolled into the stdlib in Ruby 1.9! Why would I need a gem to handle it?" Well you have a very good point there, FasterCSV was a good response to the performance of the old 1.8 stdlib CSV parser. However there are still cases where it doesn't quite go fast enough.

In our specific use case for a client project, we needed to parse large result sets coming in a csv format. How large? About 25 megs large, 200,000 records large. Decently, but not outrageously large. When we used the FasterCSV route, we could consume the data in about 8 seconds or so on our staging environment. I groused about how it could be better with a C extension. Jon rose to the challenge and started working on one, and I dutifully obliged by contributing patches and we spent a couple of Fridays pairing on it. I liked our results.

It's fast. How fast? Well we took our problem CSV input and started benchmarking with it. We then tuned it the only way that makes any sense: profiling, identifying hotspots, and circumventing them. Here's a quick benchmarking session I just ran on my MBP:

alexs-MacBook-Pro:bamfcsv alex$ irb
ruby-1.9.2-p136 :001 > require 'benchmark'
 => true 
ruby-1.9.2-p136 :002 > require 'bamfcsv'
 => true 
ruby-1.9.2-p136 :003 > require 'csv'
 => true 
ruby-1.9.2-p136 :004 > Benchmark.measure { CSV.read "observations.csv" }
 =>   2.050000   0.040000   2.090000 (  2.085173)
 
ruby-1.9.2-p136 :005 > Benchmark.measure { CSV.read "observations.csv" }
 =>   2.190000   0.050000   2.240000 (  2.230679)
 
ruby-1.9.2-p136 :006 > Benchmark.measure { CSV.read "observations.csv" }
 =>   2.190000   0.020000   2.210000 (  2.215040)
 
ruby-1.9.2-p136 :007 > Benchmark.measure { CSV.read "observations.csv" }
 =>   2.140000   0.050000   2.190000 (  2.180277)
 
ruby-1.9.2-p136 :008 > Benchmark.measure { CSV.read "observations.csv" }
 =>   2.170000   0.040000   2.210000 (  2.208252)
 
ruby-1.9.2-p136 :009 > Benchmark.measure { BAMFCSV.read "observations.csv" }
 =>   0.270000   0.040000   0.310000 (  0.301174)
 
ruby-1.9.2-p136 :010 > Benchmark.measure { BAMFCSV.read "observations.csv" }
 =>   0.210000   0.020000   0.230000 (  0.233012)
 
ruby-1.9.2-p136 :011 > Benchmark.measure { BAMFCSV.read "observations.csv" }
 =>   0.220000   0.020000   0.240000 (  0.239818)
 
ruby-1.9.2-p136 :012 > Benchmark.measure { BAMFCSV.read "observations.csv" }
 =>   0.210000   0.020000   0.230000 (  0.224568)
 
ruby-1.9.2-p136 :013 > Benchmark.measure { BAMFCSV.read "observations.csv" }
 =>   0.220000   0.020000   0.240000 (  0.240832)

That's about a 10x increase over the FasterCSV you'll get out of the box with 1.9.

We haven't tried to match FasterCSV feature for feature. We haven't tried to implement good Windows support. But it's really fast, and if you're hurting on CSV parsing performance, it can help you out in 1.9.

There's many 1.8 CSV libraries built as native extensions out there. Some report ridiculously fast performance, orders of magnitude faster than BAMFCSV. And in our attempts to use them under 1.9 they all blew up. So here's an effort to solve the same problem for Ruby 1.9.

First Cut of Cleavage

2011-03-04T11:24:53Z

Kymera Magic Wand Remote and Windows 7

2010-09-21T13:30:08Z

I recently was presented with the opportunity to purchase a Kymera Magic Wand Remote. "I get to play wizard while controlling my television?" I thought, "SIGN ME RIGHT UP!"

It's a very neat toy and considering the technology problem it is trying to solve, very well done. (I find there's some crosstalk between "flick down" and "tap top").

However it's a learning universal remote, and the problem with these is that if you use it with Windows via a Windows Media Center receiver device, the operating system will "Debounce" all inputs. Essentially you will end up able to do any input once, but not multiple times in a row without some other input intervening.

This is a stupid, compatibility breaking feature. Fortunately you can disable it. Point REGEDIT to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\HidIr\Remotes\745a17a0-74d3-11d0-b6fe-00a0c90f57da. Find the EnableDebounce key, and change it's value from 1 to 0. Poof! You've just done a little more magic to make Windows compatible with something Microsoft didn't build.

Mac OS X 10.6.*, ruby 1.9.2, and rvm

2010-09-12T09:18:59Z

I've been running into some complications trying to get ruby 1.9.2 installed by RVM on OS X 10.6.3. This is likely not an original problem, but I got it to work. My environment is pretty crufty, I have an oldish Macbook Pro that came installed with 10.4, and has had an upgrade path including 10.5. Macports, and it's ruby interpreter were on my system, as well as the default Mac ruby, and a ruby source tarball installation.

I had since uninstalled all rubies except for the 1.9.2 source tarball, and uninstalled Macports in favor of migrating to Homebrew.

My specific problem is working on a project in which the .rvmrc specified ruby-1.9.2-p0, and rvm install ruby-1.9.2-p0 did not act as expected. I received the error

readline.c:1292: error: 'username_completion_function' undeclared (first use in this function)

Starting with brew and rvm installed I then needed to do some more:

Install readline:

brew install readline

Cleanup to only one version of readline:

brew cleanup readline

Link the brew install to /usr/local:

brew link readline

Install with rvm passing args to autoconf:

rvm install 1.9.2-p0 -C --enable-shared,--with-readline-dir=/usr/local

No compile errors, and proper readline support! Yay. My thanks to George at Plataforma Tecnologia for this solution.