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

[Igal Koshevoy]

We had another good meeting at the Robert Half Technology conference room in the KOIN Tower, they provide technical recruiting and placement services: http://www.roberthalftechnology.com/

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

PRESENTATIONS

1. "Testing iPhone apps with Ruby and Cucumber" by Ian Dees, @undees, http://ian.dees.name

• Slides: http://www.slideshare.net/undees/iphone-meets-cucumber
• Ian is the author of the well-respected book: "Scripted GUI Testing with Ruby" <http://www.pragprog.com/titles/idgtr/scripted-gui-testing-with-ruby>.
  
• He works at Tektronix and does GUI testing on their test and measurement devices (e.g., oscilloscopes), and was curious about how to do this with the iPhone.
• "Cucumber" is a behavior-driven development (BDD) framework that strives to write tests in plain English. You use it to write executable examples. Further details about Cucumber are at <http://cukes.info/>.
• Recommends reading: "How Thin is Your Gui? Presenter First Technique" by Brian Marick at <http://exampler.com/src/mwrc-start.zip>, with further details on "Presenter First" at <http://en.wikipedia.org/wiki/Presenter_First>.
• Ian used BDD to wrote an iPhone program called "Just Played". He published it as open source <http://github.com/undees/justplayed/tree/master>. Wanted his tests to be able to drive the GUI, pressing buttons and reading the results.
• Wrote infrastructure so the iPhone could run an HTTP server, accept requests that'd trigger UI events, and report back status as XML. This approach put the testing logic into external Ruby code, which was a big improvement over previous attempts that relied on internal, compiled code. Result is Brominet, published as open source at <http://github.com/undees/brominet>. Works fine with iPhone 2.2 OS, but needs fixes to run on 3.0.
• Additional resources:
• Pivotal Tracker is a free, hosted, story-based project planning app: http://www.pivotaltracker.com/
• YES provided information on what songs were played at what stations at what times <http://api.yes.com>.
• iBetaTest made it easier to publish development versions of the application for testers <http://iBetaTest.com>.

2. "Ruby Persistence with CouchDB" by Jesse Hallett, @hallettj, http://sitr.us/

• Jesse posted excellent, detailed notes on CouchDB recently at <http://is.gd/331EW>.
• The notes below aim to provide additional information not in the other notes.
• At the previous pdxruby meeting's non-relational database comparison <http://is.gd/331LH>, 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.

-igal