Heroku, Why Haven't I Been Using You Till Now?

Last night, I finally got around to deploying something on Heroku, an interesting service founded by my formerly LA-based Ruby programming chums Adam Wiggins, James Lindenbaum, and Orion Henry. I had played with their previous incarnation of the service, now known as "Heroku Garden" but only recently have I gotten to know a little bit more about the incredible offering they have evolved into.

Basically, the Heroku crew have addressed the question "how can I deploy my Ruby on Rails, Sinatra, or other Rack-based web application into a dynamic cloud of servers with ridiculous ease?" They have done this with an ingenious architecture that takes advantage of Amazon's EC2 to provide their internal infrastructure. This allows Heroku to concentrate on their most important core value proposition, of a simple way to take your Ruby code and just push it into the cloud.

Notice I said "push". Heroku requires that you use git for source control of your application. You are using git for everything now, right? If not, git with it! Sorry, could not resist that. Anyhow, by simply adding a remote master to your existing git repo that points to Heroku, along with a few Ruby gems that they provide, you can deploy your app just by pushing your current branch to the Heroku master.

Doing this, causes your app to get packaged up into "slug". Once you have an active slug, it will be be deployed to a "dyno" within the Heruku grid, which is what a virtual node within their architecture is called. As your app requires more resources, the slug can be deployed to more dynos within "less than 2 seconds for most apps". That is way faster than starting up a new Amazon EC2 instance yourself, and having this extra layer has a number of other interesting benefits as well.

Heroku has a quick start guide, which pretty much runs down what you need to do. I had found a slightly more simplified quickstart here. I already had an existing Sinatra-based app that I wanted to test on Heroku, so here were my steps:

1. Install heroku gem

sudo gem install heroku

2. Setup Heroku account info, and upload public key

heroku keys:add 

This will prompt you for your Heroku account info. If you have not created one yet, better jump over to http://heroku.com/signup and create one

3. Create Heroku app from my existing app
I just changed so my current directory was the app I wanted to add to Heroku, then entered:

heroku create myappname

This creates the new app on Heroku, and creates a remote branch so you can deploy just by pushing the code.

4. Deploy my code

git push heroku master

That's it! If you have a really simple app, with no database access, you are done. What, you are deploying a Ruby on Rails app and need a database setup? OK, then...

5. Run database migrations

heroku rake db:migrate

NOW, you are fully deployed and running on Heroku. Unless you are not. I still had a minor problem with my app. I was writing my log file into "logs/production.log" but Heroku does not normally allow write access to disk. The two exceptions to this are the "tmp" directory and "log" directory (notice singular). They do provide an easy way to view your most recent log entries, by typing

heroku logs

which is how I figured out my problem with the log directory.

So, here is my total time required to deploy this app on Heroku:
- Reading quickstart = 3 minutes
- Installing gem and entering account info = 2 minutes
- Making my app a Heroku app = 1 minute
- Deploying my app for the first time to Heroku = 2 minutes
- Figuring out what I had done wrong from the Heroku documentation = 10 minutes
TOTAL = 18 minutes

Here were my bonus steps:
- Reading Heroku docs on using a custom domain with Heroku = 1 minute
- Realize I need to rename my app using Heroku command line = 1 minute
- Rename my app using Heroku command line = 1 minute
- Setting my DNS settings to point to Heroku = 5 minutes
- Telling Heroku about my custom domain = 1 minute
TOTAL = 9 minutes

So there you have it... a fully deployed app, living in the Heroku grid and consequently the Amazon EC2 cloud, in less than 30 minutes, having never used their tools before, including troubleshooting a minor configuration problem. That may seem unfair... and it is. That is exactly the kind of unfair I like on my side!

Much credit should go to the Heroku team for creating something extremely cool and functional. Important details are still not available, like pricing etc., but at least for now Heroku, is a great way to easily get your app up into the cloud within literally minutes.

What is the future for Heroku? Funded by Y Combinator, they have been quietly working away, and now with Sinatra team leads Blake Mizerany and Ryan Tomayko onboard as well, I think we will be hearing a lot from this exciting little company.

LARubyConf 2009 - Blake Mizerany - "Sinatra: the Ultimate Rack Citizen"

I was very happy when the next presenter at the Los Angeles Ruby Conference 2009 (LARubyConf) was Blake Mizerany, creator of the very cool Ruby micro-framework Sinatra. As long-time readers of this blog know, I am very into Sinatra.

There has been an incredible amount of work going into Sinatra lately, so I was very interested to catch up on what the team has been up to.

What is Sinatra? A Ruby Domain Specific Language (DSL) Mapping REST to simple actions

Why?
- small
- fast
- great rack and ruby citizen
- strong focus on HTTP
- HTTP caching helpers built in before it was cool
- content negotiation
- no boilerplate
- dead simple config when the default are not enough
- smart configuration
- DOCS- sinatrarb.com
- extending is easy
- rack is the only dependency
- very low WTF to LOC ratio (jeremy mcnally's rubyfringe talk)

when?
- a few controllers models and views
- starting any web application
- you need reusable apps and/or middleware and/or resources
- you need speed

who?
- heroku
- github
- taps
- integrity

sinatra in your gems
- a mini-github for offline repo browsing
- a local plugin and play wiki
- memcached utilization graphs
- config reusable github hook

Example: NotTwitter

As classic Sinatra

set :username,
  Proc.new { fail "yo"}
  
get '/' do
  ...
end

Change

  require 'sinatra'

to

  require 'sinatra/base'

But I want to deploy to Passenger or Heroku! No problem.

./bin/install-not-twitter
Copy example config.ru to cwd
Copy .gems file

.ru is a standard Rack config file.

.gems is a Heruku configuaration file that will handle any needed Ruby gems installations

  git init && git add .
  git commit
  heroku craete
  git push heku  aster
  heroku 

3 Awesome Features in Sinatra
pass - I cannot handle this request, try the next route
forward - sinatra as middle ware... done my job, let the next app take over... pop in front of rails metal
use - Sinatra loves rack so much, we made sure not to hide it


Resources
http://sinatrarb.com
http://github.com/rack/rack
http://github.com/rack/rack-contrib
http://github.com/rtomayko/rack-cache

If you are doing everything with Rails, you are probably using too much for the job. Sinatra is simple, fast, and extensible. I am using it in two production applications right now, along with Rails. Sinatra handles parts of the application better than how Rails does, so that is how I roll.

Especially with the ever increasing momentum behind Rack, Sinatra is a good bet for getting things done. Combined with Rails Metal, and you really have it all.

Getting Async With Sinatra And Passenger Using spork

Everyone wants it all. In the case of upload processing, this means we want both the convenience of Sinatra coding, plus the performance that a nice process/threading model gives us. Go off and do some work I just assigned you, and don't make me wait around to see you do it.

If you are using Passenger, it already is buffering your uploads, and not calling your Sinatra application until the upload is complete. That saves system resources for more important things, like even more uploads. Pretty nice.

But a lot of work often has to take place after the upload is completed. A common example these days would be a video transcoding or image processing server. Once your user has uploaded their file, it would be considerate to let them go off and do something else. Sites like YouTube and Flickr have been doing exactly this for some time.

For certain highly transactional system, a solid message queue would be essential. But more humble needs, like an upload/transcoding/image thumbnail server, does not really need all of those extra moving parts.

Thanks to the power of the underlying Ruby language itself, it is very simple to fork off blocks of code into a separate process. Combining this with Passenger's already pretty robust process handling, and you get a pretty well performing solution with not much coding effort.

But wait... it does not work?! Sure enough, there are issues in the underlying interaction between Passenger and Rack, that you must address, or your long-running code will be just that, long-running, making the user sit there and wait for it to complete before Passenger allows Sinatra to return a response.

Enter spork... a blatant ripoff of both the spoon and the fork... I mean of the Spawn plugin for Rails, except with no actual Rails stuff in it, of course. spork handles the monkeypatching required to get things working the way they should be, and also lets you run under thin with no code changes should you so wish, like when running in development mode locally.

Anyhow, it may not be a glamorous implement, but it is a useful one. Have a look at spork if you are using Sinatra on Passenger, and you want to get all asynchronous on your users.

Sinatra and Passenger Back On The Rack

There is a new release of the Sinatra gem, version 0.9.1. This happens to work out well, since the newest Passenger 2.0.6 has a strong dependency on Rack 0.9, and the previous Sinatra 0.3 simply did not work at all due to dependency on Rack 0.4. The last few days have had some of us apoplectic over Ruby gem version hell.

And lots of interesting and even important things require all three. For example, I have been messing around with Integrity, a very cool little continuous integration server which is built using Sinatra. Foca and the rest of Team Integrity are still struggling with upgrading a morass of DataMapper gems, but this should help.

The point here, is getting everything up on Rack 0.9 seem to have made these problems go away, at least for my own Sinatra-based projects. Thanks to everyone who worked on these new releases, and special thanks to the IRC dwellers that provide support for the community.

April Is For AOL

Last night was the always fun Los Angeles web application developer Meetup, this time at AOL in Beverly Hills. After navigating a veritable maze of cubes, we found ourselves in a fairly large screening room chock full of AV equipment, accompanied by a large pile of pizza boxes. A few moments later, the throng of LA-based developers shuffled in, ready for the latest and greatest. The prerequisites fulfilled, we got down to some serious techno-babble.

First up was Omer Singer from DigiTrust, talking about Web Application Firewalls. Although it strayed a little closely to a sales pitch, Omer was able to tie it together with his definition of "defense in depth", which is simply enough having multiple layers of overlapping protection. One good point that he raised which is often overlooked is the cost of "brand-damage" in the marketplace from a web application being hacked. There were several good security related question asked afterwards, so yes the crown was paying close attention.

Next, was Mitch Hashimoto recent hire at CitrusByte, with a brief overview of the newly beta released Google App Engine. Mitch took us on a brief tour of the main capabilities of the Python-based system, like a Datastore API (based on BigTable), and the Users API (based on the Goog's own account authentication database). If you like Python, and don't mind doing everything the Google Way and no other, then the App Engine might be for you.

After Mitch, I did a presentation about Frankie, my newly released Ruby gem for easy development of Facebook applications. If you don't yet know, Frankie uses the Sinatra web server and the Facebooker gem to allow you to create a basic Facebook application with only 10 lines of Ruby. I also did a brief demo of a new, super-secret web thing that I have been working on for a little while... more will be revealed soon!

Last up was programming chum and Ruby expert Ari Lerner, talking about Amazon's EC2 service, and showing a little of another upcoming pet project of ours called "Pool Party", which makes it easy to deploy an auto-scaling application to the EC2 cloud.

It was a really great meetup, and the turnout was really good. Thanks to the persistent efforts of organizer Will Jessup, the community in LA is really thriving, and we were even able to keep the annoyance of non-technical recruiter sales pitches away. Great job, everyone!

Frankie Goes To Facebook

UPDATED 4/12/2008: Now compatible with Sinatra 0.2.0
So you want to create a small Facebook application... seems like it should be a small thing, right? But creating an entire Ruby on Rails application just for a tiny little Facebook application is, at the very least, a bit wasteful. In the case of a overly popular Facebook app you could end up with, as Marc Andreessen put it, a "self-inflicted denial of service attack", unless you have both a pretty serious infrastructure to support it, as well as lots of cash to keep that data center running.

Wouldn't you rather be able to create a highly scalable "hello, world" Facebook application in around 13 lines of Ruby code? Say hello to Frankie:

require 'rubygems'
require 'frankie'

configure do
  set_option :sessions, true
  load_facebook_config "./config/facebooker.yml", Sinatra.env
end

## facebooker helpers
before do
  ensure_authenticated_to_facebook
  ensure_application_is_installed_by_facebook_user
end

## the site
get '/' do
  body "<h1>Hello #{session['facebook_session'].user.name} and welcome to frankie!</h1>"
end

Frankie is a plugin for the minimalist and very fast Sinatra web framework that allows you to easily create a Facebook application by using the Facebooker gem. Why would you want to use it? If your Facebook application needs to be highly scalable, is fairly small, or is really a mashup of other web-available resources, than Frankie could be a good solution.

Frankie is available now for your enjoyment. Here is how to get started:

- Install the Frankie gem, which will install the Sinatra and Facebooker gems if you do not already have them.

sudo gem install frankie

- Create the application directories for your new app:

mkdir myapp
cd myapp
mkdir config

- Put your facebooker.yml file into the /myapp/config directory, and set the values to your information. Here is a simple example of the file:

-------
development:
 api_key: apikeyhere 
 secret_key: secretkeyhere
 canvas_page_name: yourcanvashere    
 callback_url: http://localhost:4567
test:
 api_key: apikeyhere 
 secret_key: secretkeyhere
 canvas_page_name: yourcanvashere    
 callback_url: http://localhost:4567
production:
 api_key: apikeyhere 
 secret_key: secretkeyhere
 canvas_page_name: yourcanvashere    
 callback_url: http://yourrealserver.com

- Make sure you have setup your facebook application on the facebook site. Google "setup new facebook application" if you are unsure how to do this. I recommend starting with an IFrame application, so that you can point a development version of your Facebook application to your local machine. This, like our example here, would use "http://localhost:4567" as the callback URL when configuring the Facebook app.

- Create your application, based on the sample above, and run it:

ruby sample.rb

This will start the Sinatra Ruby web server running:

== Sinatra has taken the stage on port 4567!

- Test it by pointing your browser to http://apps.facebook.com/yourappname. If you have things setup correctly then you should see your application appear inside of Facebook's site.

Facebook is now your playground... have fun with Frankie!

Everybody Into The Pool

A few weeks back, I indulged my current obsession with grid computing, and Amazon's EC2 and S3 services in particular, with a lengthy post. I mentioned how friend Ari Lerner and I had built a really neat solution, and were going to put all of our processing farm goodness into a nice neat gemified package. Well, mostly thanks to Ari, we now have a new Ruby gem called ProcessorPool that uses EC2 and S3 to do all the hard work for you.

Based on Sinatra, with a bunch of S3 goodness mixed in, the ProcessorPool gem makes it staggeringly easy to exploit the power of the EC2 grid. More info about it is available at the Blog @ CitrusByte, and you can also check it out on RubyForge here.

All kinds of fun applications await you in the pool... image processing, video/audio transcoding, heavy computational stuff, long crawls of content... and it is fun to delegate to a pool of worker machines in the EC2 cloud.

Come on in... the pool is fine.

On The Grid With EC2

Lately, I have had a chance to get seriously into Amazon's Elastic Compute Cloud (EC2) service. I doubt any reader of this blog is unfamiliar with the existence of EC2, but many of you have probably not even gotten to the tire kicking stage, like I had been until recently.

Even after attending several sessions about Amazon's EC2 at RailsConf 2007, I still had only a very general idea about the service. However, it is true that there is no substitute for experience, and now that I have finally been getting hands-on, I am pretty excited about what you can do with it.

A client with a pretty complex Ruby on Rails application needed to create a processing farm for doing video conversion, as well as serving up the resulting video files. Sounds like the perfect application for Amazon's utility computing services. I dug in to the myriad of online sources of information available...

I decided to base my Amazon Machine Image (AMI) on Ubuntu 7.1. Oh, Ubuntu, such a modern operating system you are! That turned out to be a very good decision, and apt-get was quite co-operative getting the myriad of prerequisites my open source video processing farm would require.

I also decided to base my upload processor on Sinatra. My application's entrypoint is a single stateless call, but there are lots of these calls, and each requires a bunch of intensive back-end processing. Something nice and multithreaded, like some kind of mongrel handler, was called for. In this case, even Merb seemed like it was too heavyweight!

Luckily, I had colleague Ari Lerner available to help me strap Sinatra into my processing farm, who proved to be indispensable. We ran into some issues with Rack, which I am sure Ari will be blogging about. Thanks, Ari, you are the man.


Some lessons learned about working with EC2 and S3:

• When you can launch a new instance whenever you want, you can really work on your machine configurations in an iterative way. Treat your AMI like source code, and don't be afraid to bundle and upload iterations of the AMI as you go along. If you mess up something, you will be glad you did. And there is no bandwidth charge between EC2 and S3 so go ahead, pile it into S3! At $0.15 per GB-Month of storage used, you cannot afford not to.



• Amazon provides very complete instructions on how to create an image. When you are "developing" an AMI, by iteratively modifying a running instance, and re-bundling and re-uploading, you can skip the step of uploading your keys. However, you will need to delete /mnt/image before you can re-run the "ec2-bundle-vol" utility, or else you get an "the specified image file /mnt/image already exists" error.



• You can get DRY with your AMIs. You can use a single AMI, and pass in launch parameters to set various configuration settings. For example, when I launch a processor instance, I use my main AMI and just pass in the required launch parameters to tell it if is staging or production, and which pool of processors to join itself to. And how do you retrieve this individual instance data at runtime? You use a REST call to get it. Neat!



• At some point, I did something wrong with the code that generated keys for each file I was saving to S3, which in S3 corresponds to the path and file name. For whatever reason, it messed up, and I could not even delete the S3 objects using the S3 Firefox Organizer! Fortunately, the somewhat ugly, but much more functional Bucket Explorer was able to get rid of the offending files.



• To really take advantage of the distributed nature of the solution, I decided to use a client-side load balancing scheme like that described by Lei Zhu in this article.
  
  The solution described does load balancing without a separate load balancer. It accomplishes this as follows: when a new processing node comes online, it registers itself by saving its name into a special bucket. Any server listed in this special bucket is available to serve requests. Add in regular peer to peer checking to verify that a node has not gone offline, and the peer removes it from the bucket. If that node, or a replacement, comes online, it will register itself. And so on... Zhu's solution is both effective and minimalist.
  
  As I said, the solution proposed at the end of the article was really cool, but no actual code was provided, since it is part of what appears to be the codebase for the author's startup company. So, I decided to implement it myself, which proved to be really fun and easy. A fully Ruby-based client side load balancer for EC2 is a pretty useful thing to have around. If anyone else is interested, I will publish as a gem or something.

We are not quite finished with our video processing farm, but it is almost there, and the results are a surprisingly small amount of code. I am been extremely impressed by the relative ease with which we have put together a pretty sophisticated solution.

Grid computing... it's not just the future, it's the present.

Sinatra, a Ruby web framework, and Why It Matters

As followers of this blog know, I am very interested in the Ruby language itself, not just web development. But it is undeniable that Ruby has become popular largely due to web development powered by Ruby on Rails. However amazing Rails is, however, it is not the final web framework to be developed in Ruby.

When Ari Lerner first told me of the Sinatra project, I was interested to see where he was going with it. Now that I have seen it, I totally get it, and I am more interested than ever. Let's compare it to Rails, Camping, and Merb, to better understand where Sinatra fits in, and why Ruby programmers should take a look at it.

Unlike Ruby on Rails, Sinatra is not a Model-View-Controller (MVC) based framework for creating websites. If you want helper functions that help you create forms, connect to databases, or any of the other myriad of functions that Rails provides, you will not find them. Instead, Sinatra is a very simple, yet powerful, Domain Specific Language (DSL) for defining RESTful HTTP actions, and then defining how the application is going to respond to them.

Rails requires a separate routes file to define how the web application is going to respond to requests, which hooks up to the appropriate controllers/models. Sinatra defines the simplest thing that could possibly work. When you declare a new "get" or "post" action, Sinatra will automatically add the route, and simply start responding to requests that match.

Here is a simple example of a Sinatra application:

require 'rubygems'
require 'sinatra'

get '/' do
   "Hello world"
end

As you can see, a Sinatra application's code is tiny, similar to Camping in that you can easily create an entire web application deployed as a single file. Unlike Camping, Sinatra does not have such a "crazy meta magic" feel to it... why's coding style is not for the faint of heart.

Like Merb, Sinatra is implemented as a Mongrel handler. Also, like Merb it is both thread-safe and has better performance than Rails. However, where Merb tries to be a "Rails-lite" for devs who are already familiar with Rails, but want a more bare-metal approach, Sinatra unabashedly takes an entirely different direction with its very minimal DSL-syntax.

Not to say that you cannot use ActiveRecord or whatever other Ruby gems you want to create your application. But unlike Rails, Sinatra's base core is incrediby minimal, and it puts the onus on the developer to decide what to include, instead of adding a bunch of things that may not be appropriate for the type of application that Sinatra would be good for.

So what would it be good for? API implmentations, quick minimal applications, and web development that does not want or need things that are included in Rails, like ActiveRecord. Control panel mini-applications, or perhaps widgets. I am looking forward to really getting into some fun with Sinatra... check back soon here for more.

Yesterday, the Ruby Inside blog mentioned Sinatra, and some of us have been digging it for the last few days. Take a look, and you will enjoy the appeal of a simplicity and elegance in development you haven't felt from Ruby for a long time... a very long time.

More Developer Fun In Los Angeles

Last night was the always entertaining Los Angeles Application Developer Meetup. L.A. is not known for the same massive quantity of developers as the bay area, for example, but having joined forces with the LA Ruby on Rails Meetup crew some time back, the monthly event is still growing.

This month's was held at the impressive new digs of YellowPages.com, who have been busy building out a huge Ruby on Rails based local search replacement for their venerable 100K+ lines of Java code. Thanks for the great sandwiches, boys... next time, buy beer!

Anyhow, four presentations took place on various fun topics of technical interest. First, Jeff Yamada and his associate (sorry I didn't catch your name) showed AIR. I then did a short presentation on Continuous Integration and CruiseControl.rb. Olmo Maldonado talked about his impressive JavaScript library MooTools, and then Ari Lerner showed his just-relased Ruby web development framework, Sinatra.

AIR
Long, long ago, I used to work with Flash and ActionScript. Most of us more "serious" programmers were always very frustrated with the language, the programming environment, pretty much everything except for the final product. Since then Adobe has introduced technologies like Flex and AIR to try to address the shortcomings of using Flash as a "real" development tool. Yamada and friend are the authors of the upcoming book "AIR Bible". AIR nee Apollo is designed to provide a way to create native OS applications, while using the toolset that Flash/Flex developers are used to. If you are into Flash/Flex already, then this is probably great for you, but I am not overly in love with so many angle brackets mixed in my code... let's just say that "it ain't Ruby". One small thing I will suggest to the boys: please try to find some relevant application to show for a demo a of a new technology. Between this, and what all of the Microsofties were show a few months back for Silverlight, no one is going to take this new desktop app paradigm seriously!

How To Get Your Code Together and Keep It That Way
Then I did a presentation myself, called "How To Get Your Code Together and Keep It That Way". It was really an exhortation to use the best practice of Continuous Integration, while showing how easy it is to get started with the ultra-cool CI tool CruiseControl.rb. If you are a Rails dev, and you are not using CruiseControl.rb yet, you should be. If you have a development project with greater than zero developers, it is worth it to setup a CI system, even just to keep yourself in check. You can get a copy of my presentation here. But don't just believe me, it is in yesterday's O'Reilly Radar too.

As I was demoing the CC.rb project page, where they are doing CI builds of both CruiseControl.rb itself and the Ruby on Rails project, I noticed that the Rails build has had failing unit tests since Oct. 3. What is up with that? Let's get on it boys!

MooTools
Next up was Olmo Maldonado, once of the authors of MooTools. MooTools is a JavaScript framework for web development along the lines of Prototype or jQuery. I had been hearing about MooTools, but hadn't really checked it out. Naturally, since both of those other JS frameworks already exist, and with Prototype really having dominated in the acceptance wars, MooTools does have a different approach on several levels to justify its existence.

Heavily optimized for speed, according to Maldonado, Moo performs much faster than either Prototype or jQuery on the slickspeed benchmark test at performing DOM selects, which is the core convenience provided by any JS framework.

Another difference is that MooTools libs are completely orthogonal. As such, the developer only needs to incorporate the specific libs that contain the functionality that is required for that application, unlike both Prototype and jQuery which require downloading the entire framework to use any part of it.

MooTools seems to have a more serious emphasis on good software devlopment practices than the othe JS framework projects. One example of this is that MooTools was developed using JSSpec, which is a Behavior Driven Development framework for JavaScript.

Already up to version 1.2, MooTools has been adopted in some very interesting places. The three demos that Maldonado showed were the iPhone version of the Pop-Cap game Bejeweled, the Ubuntu.com website, and then most curious of all, the Microsoft Expression website! What, M$ couldn't use Silverlight? Oh yeah, everyone already has Javascript... no additional download required. Whatever happened to that famous dogfooding?

MooTools is realy designed for the developer who wants to work in pure JavaScript. Most Rails devs like to use the Ruby on Rails Prototype helpers to do nice AJAX-y things like edit in-place and auto-complete functionality. MooTools does all that, plus has a bunch of UI gadgetry too, but having no inline functions, is not really compatible with the way the Rails helpers work. Perhaps someone will create a Rails plug-in that can collect up all of the MooTools Javascript, kida like what the Unobtrusive Javascript plugin does... for those Rails people who want to take advanatge of the DSL-like syntax, instead of dropping all the way into JavaScript.

Sinatra
Speaking of DSLs, the final presentation of the evening was by Ari Lerner, showing his incredibly cool new little Ruby web framework called Sinatra. In fact, I was so impressed by Sinatra, that I decided to give it its own posting. I suggest you go check it out right now!