Gabba: A Ruby Gem For Doing Server Side Google Analytics Tracking

Yo, Gabba! Gabba, hey? Gabba is a Ruby gem to do easy server-side Google Analytics tracking of page view and custom events. Gather around and I'll show you how it works.

Google Analytics is the gold standard of website traffic reporting. In addition to tracking page views, one of the interesting capabilities it has is to track custom events. These could be shopping cart checkouts or video plays from clicking on a button in a Flash player.

The way that Google Analytics is implemented is using the typical tracking image technique. An image is fetched from the server, and based on the infomation pased with this request, the information about the visit is tracked. One twist on this is that Google Analytics generates the tag for the "traxel" using a piece of asynchronous JavaScript. This means that clients without javascript are not able to use Google Analytics to track visitor metrics... or does it?

There is another lesser-known way to integrate that can generate the needed info entirely on the server. This is normally used to handle older mobile browsers that do not have JavaScript implementations. Since all you are doing is fetching a 1x1 pixel GIF image, all you really need is the magic URL.

This is in fact exactly what you would need to do if you want to track custom events, the only real difference being the specific parameters passed to Google Analytics.

There are a number of cases where you might want to track custom events for non-browser devices or other unique situations. Tracking when a purchase is completed, or when a video is played by Flash player or a phone call is initiated, are just a few things you might want to track entirely on the server, with no browser interaction at all.

I did a bit of searching, but did not find any Ruby library that did what I needed. You know what that means! Fire up the editor, I'm going in! And that is how the gabba gem was born.

It is very easy to use:

# track page views
Gabba::Gabba.new("UT-1234", "mydomain.com").page_view("something", "track/me")

# or track custom events
Gabba::Gabba.new("UT-1234", "mydomain.com").event("Videos", "Play", "ID", "123")

That is all there is to using it. Simple way to get server side Google Analytics tracking of page view and custom events. Fork gabba on github, or just "gem install gabba" and start tracking all your fun stuff.

I Think I'm Comatose

This last weekend, I upgraded a pretty complex application to the latest Ruby on Rails, and consequently had to upgrade a bunch of the plugins. In the case of Comatose 2.0, this was well timed, as there is a new release.

If you have never heard of Comatose, it is a very cool mini-CMS that you add to your Rails app as a plugin. For cases where you have an applcation, and you want to put the 'static' pages under the control of the users, while still integrating with your application, Comatose is the best option I have discovered.

If you are just discovering Comatose, just go check it out. Now. If, on the other hand, you are running into any problems going to the new version, read on.

Since this application had been running the 0.8 version of Comatose, I ran into a little problem, which has been documented on Google Groups here.

If you are running the older version of Comatose, you have a migration that contains this:

 module Comatose
   class Page < ActiveRecord::Base
     set_table_name 'comatose_pages'
     acts_as_versioned :if_changed => [:title, :slug, :keywords, :body]
   end
 end

The new version of Comatose, however requires this:

 class ComatosePage < ActiveRecord::Base
   set_table_name 'comatose_pages'
   acts_as_versioned :if_changed => [:title, :slug, :keywords, :body]
 end

What I did was, go and change the original migration to match the newly required format. This will allow a new clean installation to work correctly. Then, to handle upgrade installs, I created a separate rake task to perform the migration steps as described here.

Voila. Now this app is happily running the latest Rails, Comatose, ActiveScaffold, ActiveMerchant, and a few other plugins too. Life is good.

I Want My API

I just ran into a really great resource for open source API documentation. Called gotAPI, it links in a delightfully searchable way all of the APIs we love, but turn out to not actually know. Well, we know them, just not well enough to have their numbers setup for speed dial on our cell phones. Or our code able to call them directly without looking up a reference first.

Here is a small sample of ones I will actually use regularly:

• HTML


• CSS


• JavaScript


• Prototype


• jQuery


• Ruby Standard Library


• Ruby on Rails


• Erlang


• MySQL


• PostgreSQL


• Selenium

Plus gotAPI is a domain name I can probably remember. That should keep me from several pointless button mashing Google searches per hour just to end up back on the same sites that gotAPI is already linking to.

Money In The Ghetto

I keep thinking about Zed Shaw's vitriolic (and newly updated) posting, and one particular aspect about it that seems to bother me. One way of looking at a ghetto is that is keeps people in. Another, is that is keeps outsiders away. In either case, it is an economy, like most any other. And like any economy, there are winners and losers.

What exactly is Zed complaining about? That the overall level of technical competence is very low, even among many self-proclaimed developers? That the industry has lots of hustlers and scammers? That the MAN is keeping us down and holding back our progress? I am just curious, what was the ideal environment that Zed was waxing sentimentally about? Oh yeah, developing software for the NYC Department of Corrections. Hmmm, time for a gratuitous link about the prison-industrial complex.

Ahem, back to whatever point I was trying to make. Some people look at the folks who are collecting recyclables out of the trash as disgusting. Myself, I see them as micro-entrepreneurs. It is a desirable occupation? Of course not. But it is an alternative to the corporate/governmental control structures.

I can certainly understand Zed's frustration with the relatively small amount of influence developers have in most development projects, and how many shysters are looking to exploit someone. But this is not something unique to any particular industry. It has to do with human nature, and let's not think for a minute that anyone is immune.

The "ghetto startup" mentality has certain advantages than the entrenched corporate interests, because in the creative chaos there is opportunity for the individual entrepreneur to do something independently from the established control systems. Is the Ruby on Rails community a ghetto? A shantytown? Or is it a successfully growing colony of ingenious social anarchists, and the inevitable hangers-on, sycophants, and moochers that follow success?

So, let me complete this metaphor. I, for one, am not going to complain too much about the stupid A & R execs and greedy managers that are hanging around the clubs signing anyone in sight. Nor am I going to complain about how so many artists are stealing my sound. Instead, I am going to sell mix tapes out of the trunk of my car, and just try to get paid.

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!

RailsConf 2007 - Day 2

After the incredible energy of RailsConf Day 1, Day 2 seemed to slow down the pace a little bit. That was good for me, as I could spend some time catching up with friends both old and new, and not just attending sessions like an information junky. First would come the morning keynote speeches from Cyndi Mitchell of ThoughtWorks, and headliner Tim Bray of Sun Microsystems, with a short interlude from Charles Nutter.

Cyndi Mitchell - Thoughtworks

Ms. Mitchell is UK Managing Director of ThoughtWorks. As such, she is a polished corporate representative, which is exactly the kind of emissary that Rails needs in big organizations. She had a few interesting points:

* 40% of new work at ThoughtWorks is coming from Ruby on Rails in the enterprise
* We need to reclaim the word "enterprise" back from meaning "bloated, inefficient, and expensive" to its original meaning of "entrepreneurial"
* The "real" enterprises are using Ruby on Rails to get stuff to market quickly
* ThoughtWorks is offering a complete Rails production stack called RubyWorks, and is will be providing paid 24/7 support for Rails.

Tim Bray - Sun Microsystems
After Cyndi, the irrepressible Tim Bray took the stage. Despite not really being that much into Java, I have been following Tim's blog for quite some time, as he is a smart thinker with plenty to say to the industry at large.

Tim thinks that the Ruby language is as important as Rails (I agree!!). With JRuby, Sun wants to sell lots of hardware to large enterprises that will be choosing Sun Hardware and Solaris as the preferred platform for their Rails applications. Sun is also doing lots of work on NetBeans to do better Rails development.

Tim then briefly brought up Charles Nutter to give him some Rails street cred...er, I mean to explain why Ruby developers should care about JRuby.

Charles made two main points:
* A whole different way to do Ruby dev...using tried and true Java tools that already exist
* Move into enterprise where Java is accepted but Rails is still not

Then back to Tim:
It is not CIO's who lead industry...it is people like us.

How to make money on free products
* first you get adoption
* then you get deployments
* then you can monetize at point of value - no large business will adopt any tech that is not supported

Big companies will either get a handle on web 2.0 or get disintermediated

He assumes Rails will succeed beyond our wildest dreams.

Java, php, and .NET will never go away

The network is the computer...and its a heterogeneous network. And JRuby is how we get everything to talk to each other.

Java really consist of three main parts: language/JVM/Java APIs.
JRuby lets Rails programmers access the latter two.

How do we get everything to talk to each other? REST

Etags are a way to solve the REST problem with different versions of the same data.

ATOM - Everything should have a publish button: cameras, phones, browsers, etc

Is REST all there is? SOAP... WS-* 36 specs, ~1000 pages of documentation.

WSIT - interop with MS WCF

Hot developer issues
*static vs dynamic languages
*maintenance
*tooling
*integration
*concurrency
*time to market
*scaling
*load balancing
*observability
*file IO
*DBMS
*Shared nothing architectures
*CPU
*concurrency
*debugging
*unit test
*functional programming?

Which matter the most?
*Conventional wisdom for each language
- Java: performance, tooling
- php: web scaling, ease of use
- Rails - time to market, maintainability
*Tim says: The most important are Time to market, and maintainability

Extra Action Marching Band
After the speeches, I went to a session I didn't find that interesting at all, and so in the interest of not offending anyone else too badly, I shall let it remain anonymous...you know who you were. But near the end, a massive blast of sound came from the entrance to the conference center, and then proceeded past the sessions rooms toward the main hall.

It was the Extra Action Marching Band, an amazing avant-garde performance troupe. If San Francisco (which is where they are from) had a love-child with New Orleans, it would be something like this band.

Despite an almost-incident with the conference center security staff, they were able to finish their set. The music and performance were quite incredible, showing a high level of musicality as well as serious creativity. The bullhorn with a delay pedal attached was really amazing sounding...I have to make one like that for my harmonica.

After this unique musical interlude, it was back to the conference sessions...thamks to Tim Bray for the photograph.


Xen And The Art of Deployment
Ezra Zygmuntowicz of Engine Yard, Merb, and BackgrounDRb fame gave my favorite presentation of the day. The session was packed, with both information and people. If you wanted information about scalability, at least from the perspective of the stack, then this was the high point of the entire conference. Here are copious notes of what he said:

Serving up Rails right now is all about Mongrel

Mongral uses a Ragel state machine for validation

Why is mongrel better:
*HTTP is well known protocol
*Mongrel easy to setup and use
*Transparent wire protocol

Thread safety
*Rails not thread safe
*1 request at a time per mongrel

New dog, old tricks
*Wide # of options to load balance front end
*pen, pound, HA-proxy
*Lightspeed can serve static files
*Apache 2.2/mod_proxy_balancer can do same

Each current solution has problems

Nginx
*serious performance
*small resource footprint
*no leaks under heavy load
*killer rewrite and proxy mods
*author is cool and responsive
*Nginx + Mongrel
*This is THE stack
*apache for mod_dav_svn
*flexible config allows both serving static and dynamic requests
*fast!!!
*Nginx cannot do upload progress due to buffering
*no connection rate limiting for proxy modules yet

The future for nginx
*mod_rewite going away
*replace with http_script_module
*embed NekoVM directly into nginx

Perfect simple stack
*Linux
*Nginx
*Mongrel (mongrel_cluster)
*Monit

Swiftiply - the cool new solution

Evented Mongrel
*hot patch
*remove ruby treeads
*replace with eventmachine event loop
*mongrel single threaded
*big IO speed increase
*stand up to higher load

How is single threaded faster?
*Ruby green threads are slow
*mutex locks are expensive
*one process can only do so much IO
*event driven means running in a tight loop and firing callbacks
*without context switching between threads, single process has less overhead

Mongrel vs evented mongrel - performance stats
*1 user - 1K more req/sec
*100 users - 758 req/sec vs. 3700+

Swiftiply proxy
*event drive proxy, small memory footprint
*faster than ha-proxy

How is swiftiply different
*In a normal proxy, you need to config each back end server in advance before starting proxy
*swiftiply is a client/server architecture, where new back end servers register with proxy
*keeps persistent connection between proxy and back end servers
*auto-configuration of proxy

This means you can start/stop as many mongrels as you want, and they get configured into proxy, opening the door to auto-scaling

The Zen of Xen
*monolithic linux VS modular lnux
*old model: one box running all services
*new: specific virtual machines setup for specific purpose

We all want to modularize application why not modularize servers

What about more than 1 box?

Old school - more boxes
*mysql box
*another box for other services

New school
*add another xen box
*pick resource intensive parts, and more to another VM
*each VM only runs one thing, but well
*target performance problems
*scale better

Advanced clustering
*boot off dom0 off of USB drives
*SAN for all Xen domU
*red hat clustering suite for fencing and cluster options
*GFS for 100% posix file sys
*hardware load balancer, or dedicated box running Ultra Money or LVS

Create a fabric of compute and storage
*If a node fails, just swap in another
*Move hot VM's to less loaded machines
*Deploy app on 1 node, then bounce mongrels with GFS
*Fragment and page cache across nodes
*Scale from 1 or 2 VMs to as many as traffic requires and then back down again as traffic subsides

RAM RAM RAM
*most rails apps are RAM bound before they become CPU bound
*Avg mongrel serves 70-120 mMP PER mongrel
*RMagick is a typical RAM hog
*:include on active record also very bad performance
*95% of rails apps will leak memory at point or another

Use Rails plugin leakhouse to find leaks

Rails eats DB resources for breakfast

Most people's production apps hav no database indexes! Learn where and when to apply indexes.

ActiveRecord insulates developers so much to the point of massive inefficiencies.

You will need to denormalize data and use custom SQL statements to get performance

Other Tips
*do not use file system sessions
*script/runner is inefficient. do not load rails into bgprocesses.
*Use raw MySQL and Ruby without Rails if you can
*DO NOT use script/runner to pocess incoming email. Run deamon in loop and poll svr with net/pop3 or net/imap

Rails is great for 80/20 rule, but you are on your own for last 20%

Learn how to write custom mongrel handlers

When is optimization NOT premature?

Ruby is plenty fast, its Rails that is on slow side

Cache, cache, cache espcially static HTML files

Do not store full ActiveRecord object in session, just store hash to recreate it

Parting thoughts
*do not take anyone's word as gospel
*test and benchmark for yourself
*trust but verify

The Rest Of The Day
After Ezra'a session he was swarmed like a rock star. I know, cause I was standing nearby having a really nice chat with Zed Shaw the creator of Mongrel and Evan Phoenix, the creator of the Rubini.us Ruby runtime I was mentioning yesterday. You go, Ezra!

Later on, I got to hang out at the Engine Yard booth with Ezra for a few minutes, where Mike Brown and some other brilliant Kiwi whose name I didn't catch were chatting him up. I learned even more about hard-core clustering from listening to those guys go off...all I can say is I'm glad I have hosting at Engine Yard!

I wanted to go to Dr. Nic's RejectConf, but so many people told me they planned on going that I figured I wouldn't get in. I couldn't take the prospect of being rejected twice at the same conference, so I made other plans which turned out to be really fun.

After dinner with the same group of RailsConf friends from last year, with more delicious Portland beer, and excellent conversation, I headed to the BoF sessions, to hear about Amazon's EC2 service. I really wanted to learn more hard-core details about it, but so many people were just hearing about it for the first time, that the session was dominated by introductory questions. Oh, well!

I was about ready to turn in. Lucky for me, Rails Machine was having their party at my hotel. Bradley and company are really smart, cool people, and also offer a fantastic service, so I was glad to hang out with them for a few minutes. The most fun was jamming on harmonica with Joey deVilla the AccordianGuy. After hearing him last year, I had brought a couple of my harps with me just in case, and we finally had a chance to bust out a couple of songs together. That was really fun! Thanks, Joey. If anyone has any photos or video, please post it somewhere...if not, well, you had to be there.

My New MacBook Pro Rocks For Rails Development

The last week or so I have been very busy playing with and setting up my new MacBook Pro. This is, in fact, my first post from it. After spending some time with it, I have to say that I am still extremely pleased! I have my Ruby on Rails environment all setup and working spendidly. I have my primary dev toolset CocoaMySQL, Locomotive, TextMate, and SVNx and now everything is pretty dialed in. I was able to grab one of my rails projects from my SVN repository, and run it successfully, after tweaking a few file permissions.

Wow, this baby can cook! Not just the temp, but the performance is great. I installed Parallels and couple versions of Windows XP for testing. It seems funny to me, having XP in one window, bash in another, and a stylish OSX app in a third. I know I could have done more with virtual OS stuff before I had this Mac, but now it's just so fun and easy!

Anyhow, now that I have come back to the Mac side, I sure feel a whole lot better! I guess you really CAN have it all nowadays...

RailsConf 2007 Will Have Good Beer

Portland has good beer. There, now I've said it. One of the key benefits of holding the RailsConf 2007 conference in Portland has to be easily obtaining really good beer.

The McMenamins on Broadway is the closest place to the convention center to go where "Classics such as raspberry-tinged Ruby, medium-bodied Hammerhead and dark, strong Terminator Stout are always available."

In between the fun of learning all about Rails 2.0, Capistrano 2.0, scalability, more scalability, still more scalability, let us not forget to take the time to drink a really good beer together! Or more than one, perhaps...

Update: It's official...here is the link for RailsConf on Beer

I Will Be At RailsConf 2007

I just checked my email, and saw that registration has just opened for RailsConf 2007. I went to last year's conference, and it was the most interesting and exciting event in the software industry I had been to in years!

If you are interested in going, I suggest that you register immediately. Last year's event sold out in a couple days. When they added 100 additional spots last year, those sold out in hours!

This year's is looking to be even more amazing...be there, or spend all your time reading blogs to figure out what happened!

Merb Is The Word

I have been playing around with Merb, which is a very cool project from Ezra Zygmuntowicz. Merb combines the Mongrel web server with a lightweight Ruby web framework. It has way less stuff in it than Rails, but is somewhat more than Camping.
Where this all started, was that I was looking for some way to use Mongrel to create a new REST web service for a client. This service has no UI, and basically just needs to front end a Ruby DSL that I have been working on. Another need was that I had to have something that can easily handle multithreading. Rails will block on a single thread, and also I do not need all of the Rails AJAXy goodness. So Rails seemed like a bit too much, and Camping not quite enough.
It was at this point that I discovered Merb. Merb handles threading very simply, by dispatching each new request to a new controller created on a new thread. It also has a very clean and simple support for rendering of HTML, JavaScript, and XML views. In my case, I only really cared about returning XML, so Merb seemed ideal for my needs on this project.
Starting a new Merb project requires some hand copying of files. There is a sample application included, which helps see some of what Merb can do, as well as showing how to setup your own project. At this point, Merb is very early in its lifecycle, so if you want to use it, prepare for a hands-on experience. The Merb code is very simple and clear, however, so it is not hard to see what is going on under the hood.
One of the main problems that Merb was designed to solve is better handling of long running server processes. One example of this is uploading files to your web server. Rails will block on each file upload until the upload is completed, which is a recipe for poor performance (read server unresponsive) if you will have a lot of requests to upload big files. The Merb sample app shows how to use Merb to deal with file uploads. And since Merb supports ActiveRecord, you could easily integrate a Rails app with a small Merb app or two to handle some performance bottlenecks.
Merb is much newer than Rails or Camping, but despite it not being even quite half-baked yet, the parts that are finished are delicious! Looks like it will be a really nice option for an alternative/adjunct to Rails. Now someone just needs to create a generator that lets you start a new Merb project...and some documentation/tutorials.