I’ve been developing Rails applications for personal and work projects for several years now, and I recently realized that my understanding of the Rails internals was relatively limited. I’m totally comfortable wiring up routes and controllers and working with all of the MVC goodness that comes with Rails, but I didn’t really understand how it all tied together under the hood. I decided to change this by diving into the Rails source code to really understand what happens from the point that a request comes in to when a response is rendered and sent back. The result is a series of posts with some findings that I hope will be interesting and informative to anyone who works or has worked with Rails.

I recently started a new side project with Rails 4 that’s primarily based on an API. I wanted to get API versioning right from the start, and spent longer than I’d like wrestling with Rails routing. This post details the approach I ended up using in the end.

The Goal

Here’s an example of the type of route I was hoping to achieve:

POST http://api.mysite.com/v1/events/

Using a subdomain instead of something like /api/v1/events/ is just a preference, although both are easy to accomplish in Rails. The next part is tricky however. I wanted a directory structure that looks like something this:

app/controllers/
.
|-- api
|   `-- v1
|       |-- api_controller.rb
|       `-- events_controller.rb
|-- application_controller.rb

Here, ApiController is a subclass of ApplicationController, and acts as a parent class for all of the other API controllers. This lets us keep code for generic API stuff like access checking and resource delivery in one place (Zach Holman has some great notes about this in Ruby Patterns from GitHub’s Codebase).

Lambdas are a powerful way to write anonymous functions (or closures) in Ruby. I wrote about the subtle differences between lambdas and procs here, and this post is about something a little different. I recently discovered a number of different ways to invoke lambdas that I had never seen before, and ended up learning something new about Ruby itself.

Let’s look at a basic example. Here is a lambda that doesn’t do much of anything:

test = lambda do |*args|
  p args
end

So we have a lambda test that prints its arguments when invoked. The most basic example of this would be something like:

I spent the last weekend diving into the world of d3.js, investigating it for a potential project for work. d3 is a framework for manipulating ‘data-driven documents’, and provides an incredibly powerful toolkit for visualizing your datasets in all sorts of interesting ways. It lets you easily create standard representations like bar charts, pie charts, and line graphs, but it’s by no means limited to those; if you like, you can also use it for fancy visualizations like force layouts and choropleths. In fact, it’s unfair to even describe it as a mere charting framework - it describes itself instead as a tool for applying ‘data-driven transformations to a document’. I’m not going to attempt to dive into it all here - I recommend the official site or the tutorials as a good starting point.

I was browsing through the source code of the JavaScript driver for RethinkDB the other day, and I came across a clever pattern that was too good not to write about. RethinkDB is an open-source JSON document store that I’ve heard nothing but good things about, but unfortunately I haven’t spent too much time with it myself. Instead, this post is about a JavaScript pattern in their driver code, which is actually implemented in CoffeeScript. Let’s take a look.

Click for larger image