We'll respond shortly.
Aaron starts out with a really bad joke about ‘eyhelp’, which puts him in good standing with me, at least (I like bad jokes).
He’s from Brooklyn, NY, which gets a few woots.
Most everyone in the audience has used Sinatra. It is “The Classy Web Framework”
You can make a very simple controller, just require ‘sinatra’, and define a simple get to make the most basic app, and you can define routes as well.
There’s been a lot of effort to reorganize the Sinatra codebase. Now there is a base class, and you can define apps which extend Sinatra::Default. He mentions Pat Nakajima’s Rack::Flash for rack and flash message integration.
The nice thing about this is that you can define multiple classes and apps, which allows you to encapsulate things better.
Sinatra is not a framework. Rails is a framework. Rails makes a lot of assumptions about how you will write an app, convention over configuration. It is like a “shelving unit” with places to put everything you need.
Sinatra, on the other hand, is like a wooden board. It is NOT MVC, it is really simple and straightforward.
WDNNSP = “We Don’t Need No Stinkin’ Pattern”
Aaron would like to remove the idea of Sinatra as a framework, for doing “smaller” Rails app. That works, and you can use something like Sinatra Generator to make small apps. However, he’d like us to think of it as a different way to build apps.
We can have our awesome Ruby project, but as an aside, it has Sinatra and can run on the web. You can think about HTTP as a language. It is a protocol, but with REST and other conventions, you can think of HTTP as a way for two apps or distinct pieces of code to talk to each other.
It’s up to you, but if you do, then Sinatra is an easy way to do it. One box saying “GET”, and another box giving a “response”.
The first box on the “GET” side is a User (RestClient), and the other box is Rack and Sinatra. Sinatra is really good at handling the box on the “response” side.
Think of our local computers a place to interact with apps.
Aaron discusses CouchDB now. It has a local interface which lets you interact with it, and it is a simple way to interact with the app, which runs on the web on your local machine.
He’s now describing a scenario with “Jane” in the Accounting department of “Megacorp”. When she needs to run reports, she usually sends them to the developers who have to run them from the command line. Instead, why not just make a simple webapp with a field for Jane to type into and generate her report by herself.
He would like to see all developers turn their apps into Sinatra web apps – Gems, everything. What if all our gems and code came packaged with web interfaces?
An example of this that he wrote is “Gembox”. It is a simple interface for browsing your gems. 99% of the code is RubyGems, with just a little Sinatra file to present the data via the web. He shows the code layout. The important part just consists of a file which runs the “gem list” command, with some view helpers around it. There’s not a lot of assumptions around the directory tree.
“Super Simple Sinatra Starter”.
Vegas is a bin file which wraps your app, and allows you to run it on whatever Sinatra server you have available. It makes it really easy to write and start embedded apps.
Gems + Vegas as a distribution platform
Even easier workflow for mounting
Vegas as Central Brain
Distribute Tasks across local network
See more at http://code.quirkey.com
Q: You showed code: ‘set :sessions, true’. Can you talk more about how sessions work, because they are really complex.
A: This is just a shortcut to including the Rack Sessions middleware in Sinatra. It is based on cookies, but you could write more complicated ones for distributed db sessions, etc.
Q: (from Alex Chaffee) Vegas is cool, but what about the security implications of running on localhost?
A: Yeah, it is insecure. But, you can do really cool things like running the command line. Maybe it could be sandboxed?