---
title: 'Video: Sinatra At Boston.rb, Part 3'
teaser:
tags: news,web,ruby,sinatra
author: Dan Croak
published_on: 2009-10-20
---

This is the third 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](https://thoughtbot.com/blog/post/215005339/sinatra-at-boston-rb-part-1) and
[Part
2](https://thoughtbot.com/blog/post/215237920/sinatra-at-boston-rb-part-2) if
you'd like.

<object width="400" height="300">
  <param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=7114267&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"
    />
  <embed src="http://vimeo.com/moogaloop.swf?clip_id=7114267&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"
    type="application/x-shockwave-flash" width="400" height="300" />
</object>

## Legacy APIs

Blake uses "legacy <abbr title="Application Programming Interface">API</abbr>s"
as a common use case for Sinatra. The reason `params[:splat]` and
`params[:matches]` and super-flexible routing in Sinatra exists is because of
work done on an existing non-RESTful, ugly <abbr title="Application Programming
Interface">API</abbr> that sent all the data back in the <abbr title="Uniform
Resource Locator">URL</abbr> itself (not in JSON or some other format).

This seems to be consistent with the philosophy of "[Don't fear the
URLs](http://adam.blog.heroku.com/past/2008/8/12/dont_fear_the_urls/)".

## Return values must respond to "each"

In order to be Rack-compliant, your return values of Sinatra routes should
respond to each. Blake mentions the Ruby 1.9 gotcha that the Rack spec also
mentions:

> The Body must respond to each and must only yield String values. The Body
> should not be an instance of String, as this will break in Ruby 1.9. If the
> Body responds to close, it will be called after iteration. If the Body
> responds to `to_path`, it must return a String identifying the location of a
> file whose contents are identical to that produced by calling each. The Body
> commonly is an Array of Strings, the application instance itself, or a
> File-like object.

## Templates

    get '/' do
      erb(:index)
    end

The file would be named "index.erb". Sintra doesn't use the same
"name.format.template" convention because the routes are supposed to be "less
magical". You should know what your response format is based on which route
you're already in.

## begin/rescue vs. throw :halt

I hadn't seen a discussion of these two control structures before.
`begin/rescue` is meant for exceptions and [throw
:halt](http://railsapi.com/doc/sinatra-v0.9.4/classes/Sinatra/Base.html#M000066)
is meant for returning a value and returning to another section of code.

The promise is that this will come in very handy as we dive deeper into
Sinatra.

    get '/' do
      halt(404) unless session[:user]
      # ...
    end

As Sinatra processes the route, it's listening for `halt`s and
`pass`es.

## When Sinatra, When Rails

I cut a section out for space reasons where Blake talks about thanking David
Heinemeier Hansson for writing Rails. Blake had been trying to get Ruby into
companies for years without much success, then Rails came along and made it
acceptable.

Rails:

* get bigger apps going quickly
* less pain to get a <abbr title="Create Read Update Delete">CRUD</abbr> app going

Sinatra:

* more control
* choose your own conventions
* legacy <abbr title="Application Programming Interface">API</abbr>s
* small apps going quickly
* take full advantage of Rack, no special magic to be compatible

## Shotgun

At the end of this video, I included a section where Blake shows, in response
to an audience question, how to append to an existing body via
`response.body`.

I thought his `shotgun` command was more interesting, though.

[Shotgun](http://github.com/rtomayko/shotgun) is "an automatic reloading
version of the rackup command that's shipped with Rack." It gets you
"application-wide reloading of all source files and templates on each request"
by forking into a child process, processing, then exiting the child process.

Note that this is not part of Sinatra at all. This is obviously great for a
development environment, but keeps Sinatra clean by being a third party.