Video: Sinatra at Boston.rb, part 2

This is the second in a series of short videos. They feature Blake Mizerany discussing Sinatra and Heroku in great technical detail at September’s Boston.rb. Watch Part 1.

In HD this time… watch out, the kid is learning!

“use” is built-in

In this video, Blake extends his example code using Rack middleware from rack-contrib called Rack::AcceptFormat:

Adds a format extension at the end of the URI when there is none, corresponding to the mime-type given in the Accept HTTP header.

Example from the docs:

GET /some/resource HTTP/1.1
Accept: application/json

GET /some/resource.json HTTP/1.1
Accept: application/json

Blake says we can use Rack::AcceptFormat in our config.ru or in Sinatra, depending on the situation.

This middleware will re-write path_info

What’s cool about this is Sinatra doesn’t have to know about Rack::AcceptFormat’s deeds making our work with content types easier. By the time the request gets to Sinatra, “.json” has been added. Call it “just-in-time routing”.

Rack Hoptoad

On the day Blake spoke at Boston.rb, he and I sat down to get Rack Hoptoad working on Heroku. Staying true to the philosophy of backing into patterns, we started with a bare-bones Rack app, then moved to Sinatra.

In both cases, we need to specify the gem in our .gems file:

# http://docs.heroku.com/gems#overview
rack_hoptoad

Rack:

# config.ru
require 'rack_hoptoad'

use Rack::HoptoadNotifier, "123abc"
run lambda { |env| fail "Fail!" }

Sinatra:

# config.ru
require 'rack_hoptoad'
require 'example'

use Rack::HoptoadNotifier, "1234"
run Sinatra::Application

# example.rb
require 'sinatra'

configure :production do
  enable :raise_errors
end

get '/boom' do
  fail "Fail from Sinatra!"
end

when Rack, when Sinatra?

Blake’s rule of thumb is to start with Rack when he knows, when he’s starting, that he’s only going to have one route, maybe two, and there’s nothing special about them.

In many ways, Sinatra is just a clean DSL around HTTP with lots of delegation to Rack. Without it, you’d have messy conditional statements that are fine for a couple of routes, but get out of hand beyond that.

routing tricks

Access wildcard operators using block syntax instead of a Rails-style params[:first_name]:

get '/:first_name/:last_name' do |first, last|
  "Hello, #{first} #{last}"
end

Sinatra allows splats, such as this non-greedy match:

get '/:name.*?/:last' do
end

The returned object will be a normal Ruby MatchData object, so everything you can do with that applies in your Sinatra code.

next

Stay tuned next time when our protagonist discusses:

• POSTing data to a legacy API
• war stories
• view templates

Video: Sinatra at Boston.rb, part 1

This the first in a series of short videos. They feature Blake Mizerany discussing Sinatra and Heroku in great technical detail at September’s Boston.rb.

Blake Mizerany wrote Sinatra in 2006 because he was working on a high traffic site with a lot of POSTs, PUTs, and DELETEs. GETs can be cached but the others cannot.

In this video, Blake discusses the following concepts as they apply to Sinatra:

backing into patterns

Start with a string, start with a text file, use main on Ruby. Move up to Factories and Model-View-Controller and ActiveRecord when you need it.

Rails creates 72 files when you run the rails command. Blake decided he didn’t need to start with MVC on each new project.

clean routing system

Blake uses Sinatra often for web services. He compares Rails’ respond_to with Sinatra’s content_type declaration. He discusses his feeling that the routing systems in other frameworks are overly complex undesirable.

get '/users.json' do
  content_type :json
  @user = User.find(params[:id])
  @user.to_json
end

His first example, shown above, highlights Sinatra’s clean content type approach.

next

In the next video, Blake discusses:

• handling the Accepts header using Rack middleware
• deciding between Rack and Sinatra
• rack-hoptoad
• routing tricks such as passing wildcard params into block variables and non-greedy matching