In a question on StackOverflow a few days ago, a user was asking how to ensure that a document hasn't changed between when a client read the document and wrote to it. If user A reads the document and makes some changes (through a web form, for instance), the change should be accepted if and only if no other user B has updated the document since when user A read the document.

MongoDB doesn't support transactions, and even if it did, they wouldn't help in this case. An assumption underlying the question is that the time between any given user's reads and writes is long -- otherwise explicit/pessimistic locking would be the simplest solution -- in which case holding a transaction open on a traditional database server would be prohibitively costly (in terms of resource usage and performance).

The solution is to leverage MongoDB's atomic update semantics with an optimistic concurrency solution. This comprises four basic steps: 1. read a document; 2. modify the document (i.e. present it to the user in a web form); 3. validate that the document hasn't changed; 4. commit or abandon the user's update. For anyone who's used a source code version control system before, these steps should be familiar (i.e. pull, work locally, commit, and push for git users).

Thanks to a series of recent posts on the SvN blog, I've been thinking more about my little Python A/B testing framework, Dabble.

I built Dabble to A/B test (sometimes also called "split test") features on 10gen.com. Following the advice of a blog post I've since lost track of, Dabble configures A/B test parameters entirely in code, follows procedure for independent testing, and generally works without much of a hassle.

If you look at pretty much any job posting, you'll see some variation on this (in this case, for a hypothetical web programming position):

Requirements:

• BSc in Computer Science or equivalent
• 2-5 years web development experience
• Expert in Java, SQL, HTML, CSS, Javascript
• Strong communicator
• Able to multi-task

The numbers, degrees, and technologies will vary from one job to another, but the basic form is almost always there.

But what's the point of this section? I've never gotten a job for which I met all the "requirements," and I've never cared if the candidate I'm hiring doesn't meet them either. Is it just out of habit?

Just received this IM from my friend, Nick:

11:48:58 AM Nick: kjsahfdlkjashdflkajshdflkjh
11:49:02 AM Nick: it was the git gui itself
11:49:09 AM Nick: it periodically refreshes
11:49:14 AM Nick: with a forked git process

Version control GUIs are uniformly evil. They entice you with a multitude of colors, and 1-pixel lines; their siren song is one-click commits and graphical 3-way merges.

But, like Odysseus, if we have any hope of prevailing, we must lash ourselves to the mast and steer past this temptation.

I presented Professor, my MongoDB profile viewer and analyzer, this past Tuesday at the New York MongoDB User Group. Professor aims to use the new features in the MongoDB 2.0 profiler to make profile information intelligible and actionable. It's open-source (BSD-licensed) and written in Python and Flask.