First, you need to set cookies via the response object, as Sinatra no longer has a helper for it.

response.set_cookie("foo", "bar")

Second, set_cookie always takes two arguments. If you need to set advanced options, pass a hash:

# the large number is several years in the future, in seconds
response.set_cookie("foo", {:value => "bar", :expiration => Time.today + 94608000}

There are a good handful of options available. One gotcha with the expires option is that it must respond to .gmtime, which the Date object does not. So you need to use Time or DateTime as far as I can tell.

set_cookie("thing", { :value => "thing2",
                      :domain => myDomain,
                      :path => myPath,
                      :expires => Time.today,
                      :secure => true,
                      :httponly => true } )

To read the underlying code for setting cookies, it’s in the rack gem, rack-1.0.0/lib/rack/response.rb line 56.

To fetch cookies, it’s simply calling the cookie method:

cookies["foo"] # => "bar"

Monk consists of several components:

Monk Binary

At the core of Monk is a command line tool for starting new projects.  Think of the rails command, and what it does and you have a good idea of what the monk command does.  It lists, manages and instantiates new skeletons for your project. The Monk binary can instatiate any skeleton you want, which means it is a great way to start projects in any language.

Monk Skeletons

A Monk skeleton is a set of files defining the structure of a new project.  There are almost no rules here, the new project can be Sinatra, Django, an ircbot setup, or anything else you want, heck, it could even be Rails. 

Monk Default Skeleton

The default Monk skeleton is where lots of work has gone in, and where you’ll find the meat of Monk.  It’s a set of amazing tools forming a full-stack Sinatra based web development platform.

• Sinatra - super lightweight web DSL. You know what this is (and if you don’t, go read the rest of this blog, and check it out)
• Ohm - data access layer using Redis, a stupid fast key-value database.  Super simple models for your app
• Monk Glue - a Reloader, Logger, and Settings handler for your new application. Don’t worry about it, Sinatra Logging finally made easy…  Monk Glue is destined to keep growing too, including a handful of mix & match helpers for common tasks.
• Rack-Test, Contest, Stories, Webrat, Faker, Spawn - An amazing unit and integration test stack, allowing both low level unit tests of your code, and high level integration tests, similar in style to Cucumber, but without that nasty repeating-yourself part.  You owe it to yourself to try the stories & webrat approach to testing your Sinatra application.
• Dependencies - trivial management of all the gems you rely on. Just define a dependencies file, and the dependencies gem will handle vendoring and unpacking your requirements.

Monk Glue

Logging - a perennial problem and hassle in setting up new projects is now simple with Monk, and Monk Glue. 

get '/' do
  logger.info("Entered homepage route")
  "homepage text"
end

Reloader - an alternative to the classic Sinatra reloading (with weird require related issues), and Shotgun, which causes a fork() each request, which is fairly heavyweight.  Glue’s Reloader is the happy midpoint, between the other two solutions. It reloads everything, but in the same Ruby process, making it much faster.

Settings - a minimalist implementation of the settings.yml file, with environment support. Easily switch up your database settings, your email address, url and more.  Bonus Feature: the default skeleton creates an automatic settings.yml file when you first run monk:start. 

get '/' do
  @foobar = settings(:foobar)
  "the value of the foobar setting is:" + @foobar
end

Ohm Persistence Layer

Ohm is a lightweight data management layer that uses Redis as it’s backend. Redis is a fast key-value database, and Ohm makes mappings that are simple to define, and automates the nasty parts of key-value databases like reverse lookups (indexes). Ohm isn’t technically an ORM, since there’s no relational database backing it, but it fills the same niche as ActiveRecord or Datamapper, storing your data for future use.

Awesome Reddit Clone Example

Check out http://news.monkrb.com/, the code is located at http://github.com/monkrb/reddit-clone

Pay attention for a future blog post digging further into this example code, and dissecting it.

Get Monk & Find out More

Install Monk

gem install monk

Links

• Official Monk Website - http://monkrb.com
• Monk Github: http://www.github.com/monkrb/monk
• Monk Default Skeleton Github:  http://www.github.com/monkrb/skeleton
• Monk Glue Github: http://www.github.com/monkrb/glue
• Ohm Documentation: http://ohm.keyvalue.org/
• Ohm Github: http://github.com/soveran/ohm
• Monk Mailing List Link: http://groups.google.com/group/monkrb

My favorite way of accomplishing this is to wrap the normal get and post methods with additional JSON abilities.

require 'rubygems'
require 'sinatra'
require 'json'
 
def json_get(route, options={}, &block)
  get(route, options) do 
    block.call.to_json
  end
end
 
json_get '/' do
  {"bar" => "baz", "foo" => "bar"}
end

And of course, this can be expanded to other cases where you’d want to pre-process or post-process certain routes. You could easily define an admin_get that checks that the user is logged in as an admin. Or an xml_get, or a timed_get method.

def admin_haml(template, options={}) 
  haml(template, options.merge(:layout => :'admin/layout')) 
end

Which I then used in my code like:

get '/admin/users' do
  @users = User.all
  admin_haml :'admin/user/index'
end

This also shows how to have nested directories in the views folder if you were curious. This will look for the view views/admin/users/index.haml, and render it with the layout views/admin/layout.haml.

In plain Rails, it’s simple:

Rails::Initializer.run do |config|
  config.time_zone = 'Pacific Time (US & Canada)'
end

But I wasn’t running Rails proper, and didn’t want to pull in the whole Rails boot sequence. So the Rails::Initializer call didn’t work. To do it manually, time zone config turns out it’s a 3 lines of setup calls:

require 'activerecord'
Time.zone = "Pacific Time (US & Canada)"
ActiveRecord::Base.time_zone_aware_attributes = true
ActiveRecord::Base.default_timezone = "Pacific Time (US & Canada)"

When you do that, time zone attributes work both going into the database, and coming back out. If you miss the last line, they’ll just not work coming out, which is a damn confusing thing to deal with.

Ohh, and one other thing I ran into when getting this setup is that AR pulls in Active Support, which in turn pulls in Builder (to hack xml support or something). Just watch out for that, you’ll get weird crashes if you don’t have builder installed. Honestly, I just went and commented out the areas of Active Support that did it, I didn’t want builder anyway.

/Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- blankslate (MissingSourceFile)
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from ./vendor/rails/activerecord/lib/../../activesupport/lib/active_support/basic_object.rb:21
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from ./vendor/rails/activerecord/lib/../../activesupport/lib/active_support/duration.rb:1
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from ./vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/time/calculations.rb:1
	 ... 18 levels...
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'

Tokyo Cabinet - A Key Value database that’s stupidly fast 
Tokyo Tyrant - A network layer on top of Tokyo Cabinet
Tokyo Dystopia - A full text search (inverted index) on top of Tokyo Cabinet 

Official Docs:

These include mostly the official C API docs.  They are useful if you skim through them, not for the C definitions, but to get an idea of what is possible.  You will get lots of sparse explanations, but it’s a start.

• Tokyo Cabinet: http://tokyocabinet.sourceforge.net/
• Tokyo Tyrant: http://tokyocabinet.sourceforge.net/tyrantdoc/
• Tokyo Dystopia: http://tokyocabinet.sourceforge.net/dystopiadoc/

Ruby Libraries:

• Official Ruby Lib (forked to github & gemified) http://github.com/careo/tokyocabinet-ruby
• Official Ruby Lib (forked to github & gemified) http://github.com/careo/tokyotyrant-ruby
• Rufus Library (FFI Based) http://github.com/jmettraux/rufus-tokyo/tree/master
• Datamapper Adapter  http://github.com/makoto/dm-tokyo-cabinet-adapter
• Speed Comparison (At the bottom): http://www.igvita.com/2009/02/13/tokyo-cabinet-beyond-key-value-store/

More About Rufus Library:

• Rufus 0.1.5 Release Notes - http://jmettraux.wordpress.com/2009/02/13/rufus-tokyo-015-hail-to-the-tyrant/
• Rufus 0.1.9 Release Notes - http://jmettraux.wordpress.com/2009/02/27/rufus-tokyo-018-rufusedo/

OSX Installation:

Macports version of Tokyo Cabinet and Tokyo Tyrant are broken.  The current state is that there are incompatible versions of cabinet & tyrant, and that there are Portfile problems as well, where the checksum doesn’t match the downloaded file.  I eventually gave up, and just used the instructions at http://openwferu.rubyforge.org/tokyo.html to install it manually (the version numbers in that post are old, but otherwise accurate).  Those instructions install it to /usr/local/bin, so you may need to add it to your path.

Key Value Store Theory:

• This post talks about Redis, but is a good introduction to the thinking needed for Key Value storage, as opposed to a relational approach. http://code.google.com/p/redis/wiki/TwitterAlikeExample
• http://antirez.com/post/Sorting-in-key-value-data-model.html

More Cabinet Docs:

• A quick intro into the storage and theory of Cabinet.  Not much actionable content here, but useful background. http://www.scribd.com/doc/12016121/Tokyo-Cabinet-and-Tokyo-Tyrant-Presentation

Cabinet Storage Engines:

I’m still vague on the real differences in this section. I’ll expand out as I learn and understand more. What I do know is that B-Tree and Table have additional methods on them, and that Tyrant doesn’t support at least the B-Tree ones (at a C level, it’s not a problem with the Ruby bindings).

• Hash - Standard hash structure for storing a key. 
• B-Tree - Tree structure to store keys. Allows for ordering, and multiple values.
• Table - ?? Allows storing of arbitrary keys, and indexes (like CouchDB?).
• ?? - I think array is another one, for fixed length values, but I haven’t gone into that one yet

Other Items:

Lightcloud is some sort of distributed layer on top of tyrant, which gives some horizontal scaling ability. I haven’t looked much further than that.

• Lightcloud - http://opensource.plurk.com/LightCloud/
• Lightcloud Ruby - http://github.com/mitchellh/lightcloud
• Django Tokyo Sessions - http://pypi.python.org/pypi/django-tokyo-sessions/0.1.0

That’s enough for now…. I’ll try to keep this updated as I learn.

It turns out that Leopard installs capistrano 2.0 automatically, and in a battle between /usr/bin/ and /opt/local/bin, the first one on the path of course wins. The trick is to run sudo /usr/bin/gem uninstall capistrano which will get rid of both the gem, and more importantly the cap and capify commands that came with it.  Now just install capistrano in your macports install of gems sudo /opt/local/bin/gem install capistrano and run cap: /opt/local/bin/cap deploy

This blog post was very helpful while I was hunting down this info.