A fine time was had the other night in the offices of Boston’s Vermonster, when a few Vermonsters generously helped some folks from Boston.rb get up to speed on the use of some NoSQL projects from Ruby.

Up until now, I’ve been a little leery of NoSQL. Probably due to painful past experience with ZODB failing to keep up with moderate loads, and reading too many Philip Greenspun essays at an impressionable age. Happily, it appears that the projects collected under the NoSQL banner can actually walk and chew gum at the same time, without rendering your data unreasonably inconsistent.

The whole question of the Consistency of one’s data is addressed by the CAP theory, which I understand to roughly say

Consistency, Availability, Partitionability: pick (at most) two, particularly under certain challenging conditions such as running Google or Amazon.

Even if you aren’t running something quite that big, there seem to be some situations where you’d want to think about this stuff — for example, running an app on Google’s App Engine (right? Haven’t yet myself.) Plus, all the cool kids are into it.

We worked with the locally-written Riak (looks like it’s the topic of the April Boston.rb meeting!) and with CouchDB. Both are ridiculously easy to get running locally, have Ruby client libraries, and are powered mainly by Erlang, with javascript Map/Reduce. For the latter, we used the couch_potato library, which seems to do a nice job of writing your javascript for you in the most common cases.

We wrapped the evening up with a coding challenge. My brain was fried & I gave up 2/3rds of the way through, but still had a blast & learned plenty. As a side benefit, beyond the exposure to the NoSQL, my state-of-the-art-circa-2008 Ruby habits got challenged by working with RSpec, 1.9.1, and RVM, all of which will should prove handy for future things.

Big ups to Vermonster for hosting, feeding, and educating us. They are good guys, skilled teachers, and have excellent taste in beverages.

• Somewhat like Rails, there’s DB-independent schema definition! Big win here. Among other things, this lets you develop in SQLite and deploy in MySQL, which is a nice pattern. Rails’ awesome migrations aren’t here, so it’s not as useful and flexible a system, but it’s better than nothing for getting up & running.
• One big difference from Rails that’s clear right away: rather than building code dynamically based on the DB schema, thousands of lines of getters / setters / etc. are generated by the symfony command line tool. Makes sense for PHP, but it’s a clunkier development experience.
• There’s testing built in! It’s a bit of a PITA to do things like create a test database, and all the pieces for testing your models aren’t there right away, but still better than CakePHP. The aforementioned missing piece is available as a plugin. There doesn’t seem to be a straightforward way to get the propel-insert-sql task to run on alternate environments, so one must create the db on their own. I’m using SQLite, which is great, but my local environment somehow ended up with PHP having SQLite 2.8 while my command line is version 3 (macports at fault? what a step backwards from Ubuntu…). One port install sqlite2 later, and you can do sqlite data/test.db < data/sql/lib.model.schema.sql
• No console, which makes the tests even more essential, so it does seem to be worth the pain of getting them working.

Side note — already, on the basis of the previous post, I’m seeing a surprising amount of traffic from searches on CakePHP, Symfony, and REST. Clearly I’m not the only one looking for this kind of thing.

• No migrations; you have to generate the DDL on your own, both initially and for any subsequent modifications. Also, no model or controller generators. It’s definitely nicer to just do script/generate scaffold post title:string body:text; rake db:migrate and be off to the races — from Rails 1.2 on, those races include the whole REST business. To be fair, there is a one off reference to ‘bake’ scripts in the CakePHP manual, but no pointers on what those are, or where they live, and the website isn’t much clearer.
• No TDD. Woah. That’s, like, half the advantage of Rails — automated testing is right there in your face, and is firmly entrenched in the community.
• PHP code is not quite as elegant as Ruby. For example, generating a link to delete a post looks like this: $html->link('Delete', "/posts/delete/{$post['Post'][id']}", null, 'Are you sure?' ). Can you spot the syntax error? Probably you can, but it took me a good few minutes. The Rails equivalent would be
  link_to "Delete", { :action => "delete", :id => @post.id }, :confirm => "Are you sure?", :method => :delete
• A lack of the experiences baked into Rails. For example, after the Google Web Accelerator fiasco, it became common practice to make all links to destructive actions happen via POST, which can be done via link_to’s :method parameter. Compare to the GET-powered delete link above, straight from the Cake tutorial.
• I miss my vim & rails integration, which makes creating and navigating the various files a breeze. (Glad I went to the trouble of making that a link, as it got me re-reading the plugin’s about page, and I saw the parts about partial extraction and migration inversion, neither of which I’d noticed before)

On the upside, using CakePHP sure beats writing a CRUD-heavy PHP application from scratch. One of my current projects, a completely custom contact management application, would be in much better shape if it were using CakePHP instead of the project-specific ORM I cobbled together — I’m going to have to give conversion of that project to CakePHP some serious thought.

But is CakePHP a DSL for the web in the sense that Rails is? Not yet.