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:
- 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