CouchDB Skeleton for Monk
August 27th, 2009 adminMonk is starting to take off, and people are already starting to make new skeletons specific for their own needs. Check out lazybones by TobyJoe for a CouchDB based skeleton. (Github)
Monk is starting to take off, and people are already starting to make new skeletons specific for their own needs. Check out lazybones by TobyJoe for a CouchDB based skeleton. (Github)
A few coworkers at Citrusbyte (@soveran, @djanowski) have been working on Monk, a new open source web framework. At its core is Sinatra, with a set of bundled technologies to help new projects get moving as quick as possible. It helps you figure out the best structure for your Sinatra app, and gets you moving quickly with logging, settings, and testing.
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.
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.
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.
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 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.
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.
gem install monk
Several times recently, there have been questions in the #sinatra channel, and on the mailing list about how to automatically render JSON, or any other kind of format as the response from Sinatra.
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.