Meeting notes: September 1, 2009 -- Cucumber + iPhone, Ruby + CouchDB

Skip to first unread message

Igal Koshevoy

Sep 8, 2009, 6:50:16 PM9/8/09
to Portland Ruby Brigade
We had another good meeting at the Robert Half Technology conference room in the KOIN Tower, they provide technical recruiting and placement services:

Luke Kanies will be giving his previously-scheduled "Ruby, Parser Generators, and External DSLs" talk at the next Ruby Brigade meeting, October 6th: <>.


1. "Testing iPhone apps with Ruby and Cucumber" by Ian Dees, @undees,
2. "Ruby Persistence with CouchDB" by Jesse Hallett, @hallettj,
  • Jesse posted excellent, detailed notes on CouchDB recently at <>.
  • The notes below aim to provide additional information not in the other notes.
  • At the previous pdxruby meeting's non-relational database comparison <>, it came up that CouchDB was slower than the other document stores. Jesse explained that some of these were the cost of some beneficial features of CouchDB:
    • HTTP: It provides open access using the ubiquitous HTTP protocol. This may be less efficient than some specialized binary protocol, but makes things more open and lets you use commonly available tools that speak HTTP.
    • Reliability: Every write is flushed to the disk and you don't get a response back until it succeeds. Data is stored using a B-tree with two header copies, so that if the system crashes, you should only lose uncommitted data.
    • Priorities: It's not trying to be a fast key-value store, but rather aims to be a reliable, replicatable document store.
    • Effective indexing: Map-reduce produces powerful, efficient indexes.
    • Larger stores: CouchDB benchmarks faster than SQL stores on particularly large stores. {Igal adds: In contrast, things like Tokyo Tyrant slow to a crawl after you add a million records}
    • Awesome replication: CouchDB's multi-master replication is excellent, letting you have many servers cooperating. It also includes automatic conflict resolution or can write own, e.g., if you update the same record on multiple servers at the same time. Collisions are stored so different versions can be reviewed.
    • Simple scaling: You can just send requests to a cluster of servers replicating the same database, no need to setup a master-standby pair with read-only slaves using other technologies.

Reply all
Reply to author
0 new messages