Thanks to everybody who showed up at Monday’s ChicagoDB meeting for the great discussion on MapReduce and my talk on CouchDB. Sides from my talk can be found on Slideshare, and the files/commands that were used for the demo can be found on github. As usual, please don’t hesitate to email me with any questions or comments.

See everybody next month!

chicagodb, couchdb, talks

I’m going to be speaking about CouchDB at the next ChicagoDB meeting, which will be held on August 16th, 2010. I’m currently putting together some slides that will (I hope) provide a good introduction to CouchDB and its features. I also plan on doing a live demo at the end, so everybody can see CouchDB in action.

Information about the meeting can be found here. I hope to see you there!

couchdb, nosql

The slides from my WindyCityDB talk about Polyglot Persistence have been posted to Slideshare. You can see them here, or embedded in the post below.

The case for Polyglot Persistence was made throughout the day by several of the speakers. Most people seemed to acknowledge the fact that it is very likely one database may not have all of the tools you need to get your job done. Instead of coercing a single database to try and do things it was never designed to do, it is becoming more common for applications to use multiple databases, utilizing each for their respective strengths. But, of course, using multiple databases in a single application comes with its own set of issues, and you should make sure there is a real need for Polyglot Persistence before making that leap.

Thank you very much to the WindyCityDB organizers for putting on such a great event. I had a great time, learned a ton, met some interesting people, and participated in some great conversations. What more can you ask for in a tech conference?

nosql, polyglot persistence, slides, windycitydb

In the spring of 2009, we were starting to run into some performance issues with the Interactive Mediums application (formerly known as TextMe). At the advice of a contractor and friend, we began looking into CouchDB as a potential solution to these problems. As with most young projects, documentation was a bit scarce. The official CouchDB website and the CouchDB wiki had some good information, but after reading what was available we still had many questions. Should I create a new database for each type of document I have? How many views should I store in a design document? What are the advantages and disadvantages of views sharing a design document? How do I even begin migrating my relational database backed application to CouchDB?

So I started taking notes, documenting everything I could regarding what we learned about CouchDB, the design decisions we made for our application (and their respective trade-offs), and the migration of our application code to use CouchDB. I organized those notes, and posted them on this blog as a case study, hoping it would help others looking into CouchDB.

I received a lot of positive feedback from the posts, making me feel like I had in fact filled that need, at least to some degree. Even better, earlier this year I was contacted by Couchio about combining the series of posts into a white paper that would be posted on their site. This would put the case study in front of a larger audience, potentially helping even more people. I was thrilled.

Today, that white paper was released at the “Epic Interactive Mediums Whitepaper” (love the Epic :)). You can either download it as a PDF, or view it online. Many thanks to the kind folks over at Couchio for putting this together. I hope people will find it helpful.

couchdb, couchdb case study

I’ve recently started a re-write of my Addressbook application. Addressbook was my first Rails application, as well as my first full fledged Ruby application…and boy does it show! So, trust me, the re-write is justified :)

I saw the re-write as a good opportunity to get more familiar with Rails 3 and MongoDB. After getting Rails 3 setup to use MongoDB via MongoMapper (Ben Scofield’s setup script gets you most of the way there), I quickly realized that the tests would not run.

jwood-mbp:addressbook jwood$ rake test
(in /Users/jwood/dev/personal/addressbook)
Errors running test:units, test:functionals, test:integration!

jwood-mbp:addressbook jwood$ rake test:units
(in /Users/jwood/dev/personal/addressbook)
rake aborted!
Don't know how to build task 'db:test:prepare'

Some Googling revealed this post by Yehuda Katz, in which he says:

Additionally, users can completely remove the ActiveRecord gem, and be rid of the generators, rake tasks and other peripheral elements. An example: if DataMapper implements a db:test:prepare rake task, a Rails developer can replace ActiveRecord with DataMapper, and the test:units rake task will use DataMapper’s new tasks.

We’re not using DataMapper here, but the same thing applies to MongoMapper. So, all that is needed is to implement a db:test:prepare task, which I did in lib/tasks/mongo.rake

namespace :db do
  namespace :test do
    task :prepare do
      # Stub out for MongoDB
    end
  end
end

As of right now, the task does nothing. I may end up adding some functionality to it as I work on the project. We’ll see.

Running the tests again, I can see that was all that was needed to get going.

jwood-mbp:addressbook jwood$ rake test:units
(in /Users/jwood/dev/personal/addressbook)
Loaded suite /Users/jwood/.rvm/gems/ruby-1.9.1-p378@rails3/gems/
rake-0.8.7/lib/rake/rake_test_loader
Started
...
Finished in 0.062854 seconds.

3 tests, 3 assertions, 0 failures, 0 errors, 0 skips

I also had to remove the following gems from the project, as they don’t appear to be ready for Rails 3 quite yet:

shoulda (2.10.3)
factory_girl (1.2.4)

addressbook, mongodb, mongomapper, rails, rails3