sinatra/README.de.rdoc

= Sinatra

Sinatra ist eine DSL, die das schnelles Erstellen von Webanwendungen in Ruby
mit minimalen Aufwand ermöglicht:

  # myapp.rb
  require 'sinatra'
  get '/' do
    'Hallo Welt!'
  end

Eingach via rubygems installieren und starten:

  gem install sinatra
  ruby -rubygems myapp.rb

Die Seite kann nun unter http://localhost:4567 betrachtet werden.

== Routen

In Sinatra ist eine Route definiert durch eine HTTP Methode und ein URL Muster. Jeder dieser Routen wird ein Ruby block zugeordnnet.

  get '/' do
    .. zeig etwas ..
  end

  post '/' do
    .. erstelle etwas ..
  end

  put '/' do
    .. update etwas ..
  end

  delete '/' do
    .. entferne etwas ..
  end

Die Routen werden in der Reihenfolge durchlaufen, in der sie definiert sind.
Das erste Routemuster, das mit dem Request übereinstimmt, wird ausgeführt.

Die Muster der Routen können benannte Parameter beinhalten, die über den
<tt>params</tt> Hash zugänglich gemacht werden:

  get '/hallo/:name' do
    # passt auf "GET /hallo/foo" und "GET /hallo/bar"
    # params[:name] ist 'foo' oder 'bar'
    "Hallo #{params[:name]}!"
  end

Man kann auf diese auch mit Blockparametern zugreifen:

  get '/hallo/:name' do |n|
    "Hallo #{n}!"
  end

Routenmuster können auch mit Splat- oder Wildcardparametern über das
<tt>params[:splat]</tt> Array angesprochen werden.

  get '/sag/*/zu/*' do
    # passt auf /sag/hallo/zu/welt
    params[:splat] # => ["hallo", "welt"]
  end

  get '/download/*.*' do
    # passt auf /download/pfad/zu/datei.xml
    params[:splat] # => ["pfad/zu/datei", "xml"]
  end

Routen mit regulären Ausdrücken sind auch möglich:

  get %r{/hallo/([\w]+)} do
    "Hallo, #{params[:captures].first}!"
  end

Un auch hier kann man Blockparameter nutzen:

  get %r{/hallo/([\w]+)} do |c|
    "Hallo, #{c}!"
  end

=== Bedingungen

An Routen können eine Vielzahl von Bedingungen angehängt werden, die erfüllt
sein müssen, damit der Block ausgeführt wird. möglich wäre etwa eine
Einschränkung des User Agents:

  get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do
    "Du verwendest Songbird Version #{params[:agent][0]}"
  end

  get '/foo' do
    # passt auf andere Browser
  end

Andere mitgelieferte Bedingungen sind +host_name+ und +provides+:

  get '/', :host_name => /^admin\./ do
    "Adminbereich, Zugriff verweigert!"
  end

  get '/', :provides => 'html' do
    haml :index
  end

  get '/', :provides => ['rss', 'atom', 'xml'] do
    builder :feed
  end

Man kann auch relativ einfach eigene Bedingungen hinzufügen:

  set(:probability) { |value| condition { rand <= value } }

  get '/auto_gewinnen', :probability => 0.1 do
    "Du hast gewonnen!"
  end

  get '/auto_gewinnen' do
    "Tut mir leid, verloren."
  end

=== Rückgabewerte

Durch den Rückgabewert eines Routenblocks wird mindestens der Response Body
festgelegt, der an den HTTP Client, bzw die nächste Rack Middleware
weitergegeben wird. Im Normalfall handelt es sich hierbei um einen String, wie
in den vorrangehenden Beispielen zu sehen. Es werden alledings auch andere
Werte akzeptiert.

Man kann jedes Object zurückgeben, bei dem es sich entweder um einenen validen
Rack-Rückgabewert, einen validen Rack-Body oder einen HTTP Status Code
handelt:

* Ein Array mit drei Elementen: <tt>[Status (Fixnum), Headers (Hash), Response Body (hört auf #each)]</tt>
* Ein Array mit zwei Elementen: <tt>[Status (Fixnum), Response Body (hört auf #each)]</tt>
* Ein Objekt, das auf <tt>#each</tt> hört und den an diese Methode übergebenen Block nur mit Strings als Übergabewerte aufruft.
* Ein Fixnum, das den Status Code festlegt.

Damit lässt sich relativ einfach Streaming implementieren:

    class Stream
      def each
        100.times { |i| yield "#{i}\n" }
      end
    end

    get('/') { Stream.new }

== Statische Dateien

Statische Dateien werden aus dem <tt>./public</tt> Ordner ausgeliefert. Es ist
möglich einen anderen Ort zu definieren, indem man die <tt>:public</tt> Option
setzt:

  set :public, File.dirname(__FILE__) + '/static'

Zu beachten ist, dass der Ordnername public nicht Teil der URL ist. Die Datei
<tt>./public/css/style.css</tt> ist unter
<tt>http://example.com/css/style.css</tt> zu finden.

== Views / Templates

Standardmäßig wird davon ausgegangen, dass sich Templates sich im
<tt>./views</tt> Ordner befinden. Man kann jedoch einen anderen Ordner
festlegen:

  set :views, File.dirname(__FILE__) + '/templates'

Eine wichtige Sache, die man sich hierbei merken sollte, ist das man immer mit
Symbols auf Templates verweisen sollte, auch wenn sich ein Template in einen
Unterordner befindet (in diesen Fall <tt>:'subdir/template'</tt>).
Renderingmethoden rendern jeden String direkt.

=== Haml-Templates

Das haml gem wird benötigt um Haml-Templates rendern zu können:

  ## haml muss eingebunden werden
  require 'haml'

  get '/' do
    haml :index
  end

Dieser Code rendert <tt>./views/index.haml</tt>.

{Hamls Optionen}[http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#options]
können global durch die Sinatrakonfiguration gesetzt werden,
siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
und individuell überschrieben werden.

  set :haml, :format => :html5 # Standard Haml-Format ist :xhtml

  get '/' do
    haml :index, :format => :html4 # überschrieben
  end

=== Erb-Templates

  ## erb muss eingebunden werden
  require 'erb'

  get '/' do
    erb :index
  end

Dieser Code rendert <tt>./views/index.erb</tt>.

=== Erubis

Das erubis gem wird benötigt um Erubis-Templates rendern zu können:

  ## erbubis muss eingebunden werden
  require 'erubis'

  get '/' do
    erubis :index
  end

Dieser Code rendert <tt>./views/index.erubis</tt>.

=== Builder-Templates

Das buidler gem wird benötigt um Builder-Templates rendern zu können:

  ## builder muss eingebunden werden
  require 'builder'

  get '/' do
    content_type 'application/xml', :charset => 'utf-8'
    builder :index
  end

Dieser Code rendert <tt>./views/index.builder</tt>.

=== Sass-Templates

Das haml gem wird benötigt um SASS-Templates rendern zu können:

  ## sass muss eingebunden werden
  require 'sass'

  get '/stylesheet.css' do
    content_type 'text/css', :charset => 'utf-8'
    sass :stylesheet
  end

Dieser Code rendert <tt>./views/stylesheet.sass</tt>.

{Sass Optionen}[http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#options]
können global durch die Sinatra-Konfiguration gesetzt werden,
siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
und individuell überschrieben werden.

  set :sass, :style => :compact # Standard Sass-Style ist :nested

  get '/stylesheet.css' do
    content_type 'text/css', :charset => 'utf-8'
    sass :stylesheet, :style => :expanded # überschrieben
  end

=== Scss-Templates

Das haml gem wird benötigt um SCSS-Templates rendern zu können:

  ## sass muss eingebunden werden
  require 'sass'

  get '/stylesheet.css' do
    content_type 'text/css', :charset => 'utf-8'
    scss :stylesheet
  end

Dieser Code rendert <tt>./views/stylesheet.scss</tt>.

{Scss Optionen}[http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#options]
können global durch die Sinatra-Konfiguration gesetzt werden,
siehe {Optionen und Konfiguration}[http://www.sinatrarb.com/configuration.html],
und individuell überschrieben werden.

  set :scss, :style => :compact # Standard Scss-Style ist :nested

  get '/stylesheet.css' do
    content_type 'text/css', :charset => 'utf-8'
    scss :stylesheet, :style => :expanded # überschrieben
  end

=== Less-Templates

Das less gem wird benötigt um Less-Templates rendern zu können:

  ## less muss eingebunden werden
  require 'less'

  get '/stylesheet.css' do
    content_type 'text/css', :charset => 'utf-8'
    less :stylesheet
  end

Dieser Code rendert <tt>./views/stylesheet.less</tt>.

=== Liquid-Templates

Das liquid gem wird benötigt um Liquid-Templates rendern zu können:

  ## liquid muss eingebunden werden
  require 'liquid'

  get '/' do
    liquid :index
  end

Dieser Code rendert <tt>./views/index.liquid</tt>.

Da man aus Liquid-Templates heraus keine Methoden (abgesehen von +yield+)
aufrufen kann, will man nahezu in allen Fällen +locals+ übergeben:

  liquid :index, :locals => { :key => 'value' }

=== Markdown-Templates

Das rdiscount gem wird benötigt um Markdown-Templates rendern zu können:

  ## rdiscount muss eingebunden werden
  require "rdiscount"

  get '/' do
    markdown :index
  end

Dieser Code rendert <tt>./views/index.markdown</tt> (+md+ und +mkd+ sind
ebenfalls zulässige Dateiendungen).

Da es weder möglich ist Methoden aufzurufen, noch +locals+ zu übergeben, ist
es am sinnvollsten Markdown in Kombination mit einer anderen Template-Engine
zu nutzen:

  erb :overview, :locals => { :text => markdown(:introduction) }

Es ist auch möglich die +markdown+ Methode aus anderen Templates heraus
aufzurufen:

  %h1 Hallo von Haml!
  %p= markdown(:greetings)

=== Textile-Templates

Das RedCloth gem wird benötigt um Textile-Templates rendern zu können:

  ## redcloth muss eingebunden werden
  require "redcloth"

  get '/' do
    textile :index
  end

Dieser Code rendert <tt>./views/index.textile</tt>.

Da es weder möglich ist Methoden aufzurufen, noch +locals+ zu übergeben, ist
es am sinnvollsten Textile in Kombination mit einer anderen Template-Engine
zu nutzen:

  erb :overview, :locals => { :text => textile(:introduction) }

Es ist auch möglich die +textile+ Methode aus anderen Templates heraus
aufzurufen:

  %h1 Hallo von Haml!
  %p= textile(:greetings)

=== RDoc-Templates

Das rdoc gem wird benötigt um RDoc-Templates rendern zu können:

  ## redcloth muss eingebunden werden
  require "rdoc"

  get '/' do
    rdoc :index
  end

Dieser Code rendert <tt>./views/index.rdoc</tt>.

Da es weder möglich ist Methoden aufzurufen, noch +locals+ zu übergeben, ist
es am sinnvollsten RDoc in Kombination mit einer anderen Template-Engine
zu nutzen:

  erb :overview, :locals => { :text => rdoc(:introduction) }

Es ist auch möglich die +rdoc+ Methode aus anderen Templates heraus
aufzurufen:

  %h1 Hallo von Haml!
  %p= rdoc(:greetings)

=== Radius-Templates

Das radius gem wird benötigt um Radius-Templates rendern zu können:

  ## radius muss eingebunden werden
  require 'radius'

  get '/' do
    radius :index
  end

Dieser Code rendert <tt>./views/index.radius</tt>.

Da man aus Radius-Templates heraus keine Methoden (abgesehen von +yield+)
aufrufen kann, will man nahezu in allen Fällen +locals+ übergeben:

  radius :index, :locals => { :key => 'value' }

=== Markaby-Templates

Das markaby gem wird benötigt um Markaby-Templates rendern zu können:

  ## markaby muss eingebunden werden
  require 'markaby'

  get '/' do
    markaby :index
  end

Dieser Code rendert <tt>./views/index.mab</tt>.

=== CoffeScript-Templates

Das coffee-script gem und das `coffee`-Programm werden benötigt um CoffeScript-Templates rendern zu können:

  ## coffee-script muss eingebunden werden
  require 'coffee-script'

  get '/application.js' do
    content_type 'text/javascript', :charset => 'utf-8'
    coffee :application
  end

Dieser Code rendert <tt>./views/application.coffee</tt>.

=== Inline-Templates

  get '/' do
    haml '%div.title Hallo Welt'
  end

Rendert den Inline-Template-String.

=== Auf Variablen in Templates zugreifen

Templates werden im selben Kontext ausgeführt wie Routen. Instanzvariablen in
Routen sind auch direkt im Template verfügbar:

  get '/:id' do
    @foo = Foo.find(params[:id])
    haml '%h1= @foo.name'
  end

Oder durch einen expliziten Hash von lokalen Variablen:

  get '/:id' do
    foo = Foo.find(params[:id])
    haml '%h1= foo.name', :locals => { :foo => foo }
  end

Dies wird typischerweise bei Verwendung von Subtemplates (partials) in anderen
Templates eingesetzt.

=== Inline-Templates

Templates können auch am Ende der Datei definiert werden:

  require 'sinatra'

  get '/' do
    haml :index
  end

  __END__

  @@ layout
  %html
    = yield

  @@ index
  %div.title Hallo Welt!!!!!

Anmerkung: Inline-Templates die in der Datei definiert sind die <tt>require
'sinatra'</tt> aufruft werden automatisch geladen. Um andere Inline-Templates
in anderen Dateien aufzurufen muss <tt>enable :inline_templates</tt> explizit
verwendet werden.

=== Benannte Templates

Templates können auch mit der Top-Level <tt>template</tt>-Methode definiert
werden:

  template :layout do
    "%html\n  =yield\n"
  end

  template :index do
    '%div.title Hallo Welt!'
  end

  get '/' do
    haml :index
  end

Wenn ein Template mit dem Namen "layout" existiert, wird es bei jeden Aufruf
verwendet. Durch <tt>:layout => false</tt> kann das Ausführen verhindert werden.

  get '/' do
    haml :index, :layout => !request.xhr?
  end

== Helfer

Durch die Top-Level <tt>helpers</tt>-Methode, Helfer-Methoden
definiert, die in Routen und Templates verwendet werden können:

  helpers do
    def bar(name)
      "#{name}bar"
    end
  end

  get '/:name' do
    bar(params[:name])
  end

== Filter

Before-Filter werden immer vor jedem Request in dem selben Kontext wie danach
die Routen ausgeführt. So kann man etwa Request und Antwort ändern. Gesetzte
Instanzvariablen in Filtern können in Routen und Templates verwendet werden:

  before do
    @note = 'Hi!'
    request.path_info = '/foo/bar/baz'
  end

  get '/foo/*' do
    @note #=> 'Hi!'
    params[:splat] #=> 'bar/baz'
  end

After-Filter werden nach jedem Request im selben Kontext ausgeführt, und
können ebenfalls Request und Antwort ändern. In Before-Filtern gesetzte
Instanzvariablen können in After-Filterm verwendet werden:

  after do
    puts response.status
  end

Filter können optional auch mit einem Pattern ausgestattet werden, welches auf den Request-Pfad passen müssen, damit der Filter ausgeführt wird:

  before '/protected/*' do
    authenticate!
  end

  after '/create/:slug' do |slug|
    session[:last_slug] = slug
  end

== Anhalten

Zum sofortigen stoppen eines Request in einen Filter oder einer Route:

  halt

Der Status kann beim stoppen auch angegeben werden:

  halt 410

Oder auch den Response-Body:

  halt 'Hier steht der Body'

Oder beides:

  halt 401, 'verschwinde!'

Sogar mit Headers:

  halt 402, {'Content-Type' => 'text/plain'}, 'Rache'

== Weiterspringen

Eine Route kann mittels <tt>pass</tt> zu der nächsten passenden Route springen:

  get '/raten/:wer' do
    pass unless params[:wer] == 'Frank'
    'Du hast mich!'
  end

  get '/raten/*' do
    'Du hast mich verfehlt!'
  end

Der Block wird sofort verlassen und es wird nach der nächsten treffenden Route
gesucht. Ein 404 Fehler wird zurückgegeben, wenn kein treffendes Routen-Muster
gefunden wird.

== Konfiguration

Wird einmal beim Starten in jedweder Umgebung ausgeführt:

  configure do
    ...
  end

Läuft nurm wenn die Umgebung (RACK_ENV Umgebungsvariable) auf
<tt>:production</tt> gesetzt ist:

  configure :production do
    ...
  end

Läuft nur wenn die Umgebung auf <tt>:production</tt> oder auf <tt>:test</tt>
gesetzt ist:

  configure :production, :test do
    ...
  end

== Fehlerbehandlung

Error Handler laufen im selben Kontext wie Routen und Filter, was bedeutet,
dass alle Goodies wie <tt>haml</tt>, <tt>erb</tt>, <tt>halt</tt>, etc.
verwendet werden können.

=== Nicht gefunden

Wenn eine <tt>Sinatra::NotFound</tt> Exception geworfen wird oder der Statuscode 404ist, wird der <tt>not_found</tt> Handler ausgeführt:

  not_found do
    'Kann nirgendwo gefunden werden.'
  end

=== Fehler

Der +error+ Handler wird immer ausgeführt wenn eine Exception in einem Routenblock
oder in einen Filter geworfen wurde. Doe Exception kann über die
<tt>sinatra.error</tt> Rack-Variable angesprochen werden:

  error do
    'Entschuldige es gab einen hässlichen Fehler - ' + env['sinatra.error'].name
  end

Benutzerdefinierte Fehler:

  error MyCustomError do
    'Was passiert ist...' + request.env['sinatra.error'].message
  end

Dann, wenn das passiert:

  get '/' do
    raise MyCustomError, 'etwas schlechtes'
  end

Bekommt man dieses:

  Was passiert ist... etwas schlechtes

Alternativ kann ein Error Handler auch für Statuscode definiert werden:

  error 403 do
    'Zugriff verboten'
  end

  get '/geheim' do
    403
  end

Oder ein Statuscode-Bereich:

  error 400..510 do
    'Boom'
  end

Sinatra setzt verschiedene <tt>not_found</tt> und <tt>error</tt>
Handler in der Development Umgebung.

== Mime-Types

Wenn <tt>send_file</tt> oder statische Dateien verwendet werden, kann es
vorkommen, dass Sinatra den Mime-Typ nicht kennt. Registriert wird dieser mit
+mime_type+ per Dateiendung:

  mime_type :foo, 'text/foo'

Es kann aber auch der +content_type+ Helfer verwendet werden:

  content_type :foo

== Rack Middleware

Sinatra baut auf Rack[http://rack.rubyforge.org/], einen minimales Standardinterface für Ruby Webframeworks. Eines der ainteressantesten
Features für Entwickler ist der Support von Middleware, die
zwischen den Server und die Anwendung geschaltet wird und so HTTP
Request und/order Antwort überwachen und/oder manipulieren kann.

Sinatra macht das erstellen von Middleware-Verkettungen mit der Top-Level
Methode +use+ zu einem Kinderspiel:

  require 'sinatra'
  require 'my_custom_middleware'

  use Rack::Lint
  use MyCustomMiddleware

  get '/hallo' do
    'Hallo Welt'
  end

Die Semantik von +use+ mit identisch mit der gleichnamigen Methode der
Rack::Builder[http://rack.rubyforge.org/doc/classes/Rack/Builder.html] DSL
(meist verwendet in Rackup-Dateien). Ein Beispiel dafür ist, dass die
+use+-Methode mehrere/verschiedene Argumente und auch Blöcke entgegen nimmt:

  use Rack::Auth::Basic do |username, password|
    username == 'admin' && password == 'secret'
  end

Rack bietet eine Vielzahl von Standard Middleware für Logging, Debugging,
URL-Routing, Authentifizierung und Session-Verarbeitung.
Sinatra verwendet viele von diesen Komponenten automatisch, abhängig von der
Konfiguration, so muss man häufig +use+ nicht explizit verwenden.

== Testen

Sinatra Tests können mit jedem auf Rack aufbauendem Test Framework geschrieben
werden. {Rack::Test}[http://gitrdoc.com/brynary/rack-test] wird empfohlen:

  require 'my_sinatra_app'
  require 'rack/test'

  class MyAppTest < Test::Unit::TestCase
    include Rack::Test::Methods

    def app
      Sinatra::Application
    end

    def test_my_default
      get '/'
      assert_equal 'Hallo Welt!', last_response.body
    end

    def test_with_params
      get '/meet', :name => 'Frank'
      assert_equal 'Hallo Frank!', last_response.body
    end

    def test_with_rack_env
      get '/', {}, 'HTTP_USER_AGENT' => 'Songbird'
      assert_equal "Du verwendest Songbird!", last_response.body
    end
  end

Anmerkung: Das eingebaute Sinatra::Test Modul und die Sinatra::TestHarness
Klasse werden seit Version 0.9.2 nicht mehr unterstützt.

== Sinatra::Base - Middleware, Bibliotheken, und modulare Anwendungen

Das Definitieren einer Top-Level Anwendung  funktioniert gut für
Microanwendungen, hat aber Nachteile wenn man wiederverwendbare Komponenten
wie Middleware, Rails Metal, einfache Bibliotheken mit Server Komponenten
oder auch Sinatra Erweiterungen bauen will.
Die Top-Level DSL belastet den Objekt-Namespace und setzt einen Microanwendungsstil voraus (ein einzelne Anwendungsdatei, ./public und ./views
Ordner, Logging, Exception-Detail-Seite, usw). Genau hier kommt Sinatra::Base
in das Spiel:

  require 'sinatra/base'

  class MyApp < Sinatra::Base
    set :sessions, true
    set :foo, 'bar'

    get '/' do
      'Hallo Welt!'
    end
  end

Die MyApp-Klasse ist eine unabhängige Rack-Komponente die als Middleware,
Endpunkt oder via Rails Metal verwendet werden kann. Verwendet wird sie durch
+use+ oder +run+ von einer Rackup +config.ru+ Datei oder als Serverkomponente
einer Bibliothek:

   MyApp.run! :host => 'localhost', :port => 9090

Die Methoden der Sinatra::Base-Subklasse sind genau die selben wie die
der Top-Level DSL. Die meisten Top-Level Anwendungen können mit nur zwei Veränderungen zu Sinatra::Base-Komponenten konvertiert werden:

* Die Datei sollte <tt>require 'sinatra/base'</tt> anstelle von
  <tt>require 'sinatra/base'</tt> aufrufen, ansonsten werden alle von
  Sinatra's DSL Methoden in den Top-Level- Namespace importiert.
* Alle Routen, Error Handler, Filter und Optionen der Applikation müssen in
  einer Subklass von Sinatra::Base definiert werden.

+Sinatra::Base+ ist ein unbeschriebense Blatt. Die meisten Optionen sind per default deaktiviert, das betrifft auch den eingebauten Server. Siehe {Optionen und Konfiguration}[http://sinatra.github.com/configuration.html] für Details über möglichen Optionen.

SIDEBAR: Sinatras Top-Level DSL-Methoden sind als einfache Delegationen
implementiert. Die Sinatra::Application-Klasse -- eine spezielle Subklasse von
Sinatra::Base -- erhält alle :get, :put, :post, :delete, :before, :error,
:not_found, :configure und :set Meldungen die vom Top-Level aus gesendet
werden. Schau am besten im Code nach: Hier ist {Sinatra::Delegator mixin}[http://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1064] definiert und wird in den {globalen Namespace eingebunden}[http://github.com/sinatra/sinatra/blob/master/lib/sinatra/main.rb#L25].

== Kommandozeile

Sinatra Anwendungen können direkt gestartet werden:

  ruby myapp.rb [-h] [-x] [-e ENVIRONMENT] [-p PORT] [-h HOST] [-s HANDLER]

Die Optionen sind:

  -h # Hilfe
  -p # Den Port setzen (Standard ist 4567)
  -h # Den Host setzen (Standard ist 0.0.0.0)
  -e # Die Umgebung setzen (Standard ist development)
  -s # rack server/handler setzen (Standard ist thin)
  -x # mutex lock einschalten (Standard ist off)

== Der neueste Stand (The Bleeding Edge)

Um auf den neuesten Stand von Sinatras Code zu sein, kann eine lokale Kopie
angelegt werden. Gestartet wird in der Anwendung mit dem <tt>sinatra/lib</tt>
Ordner im <tt>LOAD_PATH</tt>:

  cd myapp
  git clone git://github.com/sinatra/sinatra.git
  ruby -Isinatra/lib myapp.rb

Alternativ kann der <tt>sinatra/lib</tt> Ordner zum <tt>LOAD_PATH</tt> in
der Anwendung hinzugefügt werden:

  $LOAD_PATH.unshift File.dirname(__FILE__) + '/sinatra/lib'
  require 'rubygems'
  require 'sinatra'

  get '/ueber' do
    "Ich laufe mit Version " + Sinatra::VERSION
  end

Um Sinatra Code in der Zukunft zu aktualisieren:

  cd myproject/sinatra
  git pull

== Mehr

* {Projekt Website}[http://sinatra.github.com/] - Ergänzende Dokumentation,
  News und Links zu anderen Ressourcen.
* {Hilfe beisteuern}[http://sinatra.github.com/contributing.html] - Einen Fehler gefunden? Brauchst du Hilfe? Hast du einen Patch?
* {Issue Tracker}[http://github.com/sinatra/sinatra/issues]
* {Twitter}[http://twitter.com/sinatra]
* {Mailingliste}[http://groups.google.com/group/sinatrarb]
* {IRC: #sinatra}[irc://chat.freenode.net/#sinatra] auf http://freenode.net