Yesterday marked the first day of the RailsConf 2008. I am not going to report on the keynote or great sessions, because I am not in attendance. I am plugging along in Ruby & Rails code instead; I like it that way. One of the reasons that I am not driven to participate in the conference is that I love Ruby so much more than Rails. Don’t get me wrong; I know that Rails is a giant for excellent reasons: It makes the production of most web application features, fast and pleasurable. My problem is that I tend to pursue features just outside of “most” cases.

My first experiment in Rails was an adapter application that I hoped to use to translate legacy databases into sister databases equipped with Rails naming conventions. The idea was that it could take any two databases names and map table to table, field to field. It seemed like a good way to work with existing and live data while allowing the old application to stay in production. It came together amazingly fast, and never worked. I managed to unearth a bug in the Rails framework that only showed up once in Google and hasn’t since been reproduced. It is possible that newer versions of Rails could handle such an application, but really some things are best done with outside of Rails.

It turns out that a lot of Ruby developers have bumped up against the rigid edges of Rails. Some of them have created alternative web frameworks in Ruby. Her are just a few burgeoning Ruby frameworks: Camping, Ramaze, Mack, Sinatra and Merb. I want to call out attention to Merb, because it is evolving quickly. Standing on the shoulders of the great Rails giant, it has a faster, leaner code base that allows easier and deeper tinkering.

Merb was originally conceived by Ezra Zygmuntowicz as a way to allow fast concurrent file uploads. It is thread-safe, and is now being actively developed towards version 1.0 with the financial support of Engine Yard. While Rails is opinionated, believing that there is one right way to develop, Merb is opinionated believing that the framework should not limit the developer. Because of its added freedoms, Merb is slightly harder to develop.

One of the freedoms that Merb allows is the choice of an object relational map (ORM). Rails use its ActiveRecord module to map database data to Ruby objects. Merb lets the developer use ActiveRecord or any other ORM . This freedom has led to a massive growth in Ruby ORMs. Currently, there are Merb supported plugins for ActiveRecord, Sequel and DataMapper.

DataMapper has become the favorite ORM among Merbites for the same reason that Merb is becoming popular in fringe Rubyists: speed and flexibility. DataMapper typically runs at 60% faster than Active Record. It also allows easy usage of composite keys or natural keys. For people working with legacy systems, this freedom has a lot of appeal.

There are a host of features in both Merb and DataMapper that make each, much more than a speedy clone of their predecessor. In the future I will write in depth about their characteristics and merits. For right now, as I paint a broad picture of the changing Ruby landscape, I want to draw some attention to changes in databases as we know them too. DataMapper connects to the usual assortment of relational databases from Oracle to MySQL. It also has an adapter that connects it to an Apache incubator project called CouchDB.

CouchDB is not a relational database. It is a document-oriented database. In practice, relational associations are still created between documents. The thing that is different is the flexibility and scalability. Because data is not based on a table with specific columns, new attributes can be added to a document type by adding a key value pairs to a document. This is the database equivalent to a dynamically-typed language.

The CouchDB database server runs as an HTTP process receiving RES Tful JSON requests. That means it works well with Ruby or any other language. Its scalability comes from its HTTP underpinning and a carefully conceived architecture built on the messaging language, Erlang. Databases can exist on many different HTTP servers without having to establish slave-master relationships. This means fast writes and reads for distributed applications.

CouchDB is currently in alpha but is inspiring the imaginations of Rubyists. There is even a Ruby coded document-oriented database inspired by CouchDB, called RDDB.

Only time can tell whether object-oriented databases will become the future of database technology, but with Merb and DataMapper future trends are more clear. DataMapper released its first gem in the 0.9.X ilk this past Monday. It is a complete rebuild of its previous and well-conceived architecture. It has been the de facto ORM for experimental Merb developers, and with the release it is ready for more established commercial endeavors.

A couple months back Sony posted the first known job ad looking for a Merb developer. Since then many more startups and larger companies have semi-publicly declared their allegiance to Merb. In fact, I first noticed Integral Impessions because of their interest in Merb. Ben has been working on a new content management system in Merb that will be faster, leaner and more modular. I will be getting deep into its code sometime early next week. I couldn’t be happier, and I don’t regret missing the conference at all.