Non-Relational Databases

22 June 2011

This meetup was sponsored by the Software Architecture and Platform (SAP) SIG of the Silicon Valley Forum. The speaker - Chris Westin - was from a company called MongoDB, an open source database management system that is not relational.

Chris Westin started out by saying that implementations of the relational data model have difficulty with schema changes and slow write rates. He then categorized the current commercial landscape of non-relational database management systems:

I. Data Models

1) key/value stores

2) document stores where the document has named fields,

eg. json, xml -no joins necessary because of nesting

3) column-oriented store

4) graph databases - good for finding shortest paths, etc.

II. Consistency Models

1) single master

2) multiple master (aka "dynamo")

Any non-relational database currently available fits into one of the data model categories and one of the consistency model categories. For example, Mongo DB is a document store with the single master consistency model.

Features of MongoDB:

Open source, stores Json objects as Bson, has interesting advanced queries possible, supports sharding, supports all the application programming languages, downloadable from github.

MongoDB's business model is to get paid for support, consulting and training.

Users of MongoDB: Craigslist, bit.ly, Shutterfly

I asked "Where does Google's BigTable fit into the commercial landscape?" Answer: Big Table is dynamo (multiple masters) and column oriented, I think. It isn't on the slide because we can't download it and use it.

Chris saw a recent twitter: "If a product is not downloadable from github, it is dead to me."

Test Driven Development Meetup

23 June 2011

TDD is a coding process where you always write the tests first, watch them fail, and then implement the code until your tests pass. I have read the book by Kent Beck, but benefitted a lot from this BYOL (Bring Your Own Laptop) meetup.

You are testing functionality, not code, so you only write tests for the public functions that your program will provide to a user. In writing the test first, you are clear that you know what the functionality is before implementing. Refactor as you go, but make sure all your tests pass before refactoring.

The way that the meetup was organized was great. We were put it groups of 3, each group sharing one computer. One person is at each keyboard, but the group must communicate about what they are doing with the code. All the groups are working on the same problem, which in our case was a Yahtzee game. After 10 minutes or so, the person at the keyboard gets up and joins another group, and someone who was not at the keyboard the last time takes over at the keyboard this time.

I am trying to find a way to require students to program in this way. Apparently all of Google sw engineers use this technique, and other local employers have said that they are overjoyed to find job candidates that program in this way.

I found the organization of this meetup to be a great pattern for an inclass exercise. Another idea is to have one person write the test and another write the implementation.