As a sanity check when you're done, run "irb" (interactive Ruby), and type each of the following commands (in order). None of them should return errors.

1. require 'rubygems'
2. require 'sinatra'
3. require 'haml'

Okay, now on with the good stuff.

First Steps

Create a project directory, like first_app or something. Create a file with the .rb extension, like hello.rb. Open it up in your favorite (simple?) text editor (notepad++, gedit, TextMate).

Write the following:

Let's take a step by step to figure out exactly what's going on in this file. (list numbers correspond to line numbers)

1. "require" simply loads up a library. If it's already been loaded once, "require" will check to make sure it already loaded it and then do nothing. "require"ing rubygems loads up that library into memory so we can load other gems, like...sinatra. (Like Perl, Ruby has a number of "magic globals". The load path, where require looks, is an array in $:). Also, notice single-line comments are denoted by #. Ruby doesn't really have multiline comments amazingly, but there is a hacky substitute...
2. Now that we have rubygems loaded, we can load sinatra! Rubygems works by modifying that $: variable I mentioned above. By loading the sinatra gem, the libraries full capabilities are now ready -- and most importantly, new methods are available in the main scope.
4. Ah, 'get' is our first method call, which we get after loading sinatra. We're passing in one argument to it, "/hello", as well as a block. Blocks have some tricky aspects to them, but think of them as simply a way of passing a chunk of code around (see closure and Pragmatic Programmers for more info). Note that calling methods without the (optional) parentheses is generally considered against best practice, except in very simple cases, like this one.
5. As you may have guessed, this is a string. But what is it doing? The last line of any block or method is implicitly the return value. When sinatra asks this block "what's your value", the block will hand up whatever's on the last line. Of course, you can (and sometimes have to) be more explicit by prefixing your return value with the return keyword, like Java.

If you're confused about what method calls generally look like, here's a little snippet I prepared.

Okay, let's run this thing. In your terminal, run `ruby hello.rb`. The terminal will tell you where to point your browser: http://localhost:4567/. Go there -- you should see "Hello, world!"

Okay, the basics are out of the way. Let's get to the cookbook-style programs. (be sure to note the filename, in the corner of the gist)

Render a haml template and pass data to it

Render a layout

Layouts minimize redundant code across multiple views.

Adding javascript, css, images

Plop those files into a /public subdirectory and you should be able to reference them like /my_css.css in your views. See here: Sinatra Intro.

Posting a form and using that data

Preserving session information, like logins

The Sinatra FAQ is pretty good about this one: http://www.sinatrarb.com/faq.html#sessions

I'm cutting this off a bit short, but hopefully this is enough to get you started.

EDIT: cont'd.

Basic HTML/HAML stuff

A basic "sign in" application with link bar

See this little app I made at github. Click the Download Source button on that page, and/or browse around online.

Edit: apparently you can embed Gists. Sweet. Gist is below.

Exception tracking

Get Exceptional limit: 1 app
Hoptoad limit: 1 project, 2 users

Bug tracking:

there's github, of course, if you're already using that...
16bugs limit: 1 project
I'm not including full hosting platforms, like Google Code here, but you could use those, too

Email

One-off emails (i.e. signup)

Sendgrid limit: 200 emails/day
GMail allows 500 emails/day, but doesn't offer all the doodads that Sendgrid does

Mailing list (i.e. newsletter)

Mailchimp limit: 500 subscribers, 3000 emails total a month

Customer Support

SnapABug limit: 10 reports/day
uservoice limit: 100 unique users/month
GetSatisfaction limit: 0 official reps, not hosted on your url

Analytics

There's a ton of options in this space, but I use:
Google Analytics limit: no limits, because it's The Goog
Clicky limit: 1 website, 3000 hits/day

Metrics, Monitoring

New Relic limit: no troubleshooting, optimization, etc

User Avatar Hosting

Gravatar limit: none

Authentication

OpenID

RPX limit: up to 6 providers, instead of 12

Time tracking/invoicing

Harvest limit: 2 projects, 4 clients, 1 user

Help desk thing

Just kidding, couldn't find any free hosted help desk apps

Anything else I'm missing that every webapp needs?

1. Do as much of the models as possible in this first pass, skipping validation but including schema stuff
2. Stick a couple things into the controllers that I think I'll need
3. Build out some of the views, giving them some basic styles
4. Revisit the models to add validation, helper methods
5. Build out the rest of the views, give them real styles
6. Muse about specs, then give up before starting
7. Put more stuff into the controllers
8. Iterate on random components until you're done

Needless to say, I'm getting to the point where my lack of organization kills my mini-projects before I hit step 4, sometimes even sooner than that.  So I'm going to try a slightly more...conventional (or widely suggested, at least) approach:

1. Create controllers with just enough information so that your pages will display.  No setting variables yet or other logic!
2. Fill out the views with as much HTML and fake data as you need.  Site have a sign-in page?  Leave a link to "force sign-in" the user that simply sets them to an authenticated state.  All it should do is set a session variable
3. Spec out the models.  Don't check for validation yet, just check for core functionality, i.e. there is a User table, the first user has a name of Foo and email of bar@baz.com, etc.
4. Fill out your model code so that the specs pass -- this includes migrations with sample data (these can be removed in a later migration).
5. Spec out your controllers/views.
6. Fill out your controllers/views so they pass specs.
7. Do the rest of the little things that need doing, like validation, error messaging, authentication, styling, etc.
8. Revel in having finished a project.

Hopefully I'll get further than step 3 this way! I'm going to try to focus more on content/frontend instead of getting bogged down in the backend, and I want to actually write specs.

Any comments/suggestions?

And yes, it doesn't look that great.  But I'm expecting you to restyle everything anyway and possibly blow away the templates entirely in your instantiation of the skeleton.

Now, without further ado, here are features and screenshots:

Features/requirements

• Built on Bones
• Edge Rack/Innate/Ramaze
• Haml/Sass
• Sequel + sqlite3
• Blueprint CSS
• jQuery, jQuery UI
• OpenID (via RPX)
• RestClient
• Crack
• UUID
• Rack-flash

Screenshots

• Individual pages
• Slideshow

Repository

Github.

Thanks for looking!

So I like the design that, when you need a particular library in your code, you require it in right there in the method/class (JIT library-loading, so to speak), even if it means the require directive will get executed more than once. Running through irb you can tell that calling require twice on the same library is usually much faster the second time, but how much faster?
Read on for benchmarks!

Benchmarks

I came up with some simple benchmarks for a few gems below:

Example: heroku took 0.3 seconds to load the first time and subsequent attempts to load it were 800-900 times faster.
Note: these are very ballpark figures. I ran most of them 3-5 times and eyeballed the representative range.

Commentary

So what's the takeaway message? One is unless you're concerned about performance, re-requiring isn't going to be what's putting a damper on the speed in your program. On the other hand, you're probably well off not requiring activerecord or activesupport more than once, whereas requiring rest_client you can probably do as often as you want.

Where's the code?

Ah, right, the code. Here's a pastie link for ya.

From the repository

1. sudo aptitude install libopenssl-ruby1.9
2. sudo aptitude install ruby1.9

From source

1. sudo aptitude install libopenssl-ruby1.9
2. cd ~/Downloads/ruby-1.9.1-p0/ext/openssl
3. ruby extconf.rb && make && sudo make install

Note that if you haven't installed Ruby yet, you don't need to build the openssl gem manually -- I believe it will automatically get picked up during the regular Ruby 1.9.1 build process if all the dependencies are already there.

Disclaimer...

I'm not 100% sure these steps are accurate, so if they're not, please leave angry messages and I'll try to fix the directions. Otherwise, hope they help!

So, yes, Ruby+Gosu+Chipmunk play just fine with RubyScript2Exe on both Windows and Linux.