couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <>
Subject Re: Blogpost: "Databases aren't boring"
Date Thu, 21 Apr 2016 22:10:23 GMT
Hey there!

Here is the latest version, thanks to the awesome help of Jenn!

I am leaving for Cuba in 6 hours, it would be cool if someone could publish
it. The feature is already merged. Please decide how you want to handle the
video (embedded youtube, gif or something else).

Thank you,

Original video:




# Databases aren’t boring

It sounds super boring, sometimes scary. Let’s talk about database
development, data management, and database administration. Sounds boring,
right? I promise: it isn’t. I mainly develop for [Fauxton](, the UI for CouchDB we’ll
release with 2.0. We are developing, designing, and concepting a UI for
administration and data management.

When I tell fellow developers and designers that I develop a database, many
of them look scared. Sometimes they also look bored, because people rarely
imagine data management is exciting. Some of them might think of boring
database courses in college. In this article we’ll discover what makes
database development so interesting and exciting.

One of our main objectives is to make data management as frictionless as
possible for the user. How can we lower the entry barrier for new users,
but still support our power users? How can we display data in an accurate,
detailed way, but still have a high density of information? How do we
measure our success without traditional systems to measure engagement, like
tracking? It is important to remember--we can be successful only if our
users are successful.

A recent example where we want to make our users more successful is
[eventual consistency and MVCC]( Large numbers of
conflicts can be problematic; they will slow down the database and take up
a lot of space. Some of the Fauxton developers recently had a hackweek. As
part of one project we asked ourselves: “How can we make conflict detection
and resolution a first class citizen in CouchDB and make it as frictionless
as possible?”

Our goals:

- Conflict detection should be as easy as possible
- Make conflict resolution as easy as possible and provide necessary tooling
- Help to avoid situations where a large number of conflicts become
- Provide better education and tutorials for conflict resolution, directly
in the dashboard

We focused mainly on conflict resolution as our time was limited to one
week. A document with conflicts has different revisions, and Couch elects
one as the “winning revision.” How to choose the right revision and get rid
of the other ones? Our project, codenamed “The Revision Browser,” was born.
We wanted to provide a way to easily diff revisions, and inspect the
revision tree. We also wanted an easy way to delete conflicting revisions
and select other revisions as a winner. The first, ugly prototype had two

![The first prototype](first-prototype.png)

We are a distributed team, so use video calls for evaluating the
iterations. We demo the current, incomplete work. Whenever possible, we
test ad-hoc changes directly in the browser during the session. One
addition that came up during our demos was to provide another view mode
next to the “diff mode”. It shows both conflicting documents next to each

![Both conflicting documents next to each other](1-to-1.png)

After the hackweek we had some work left to bring the project over the
finish line. I am happy to announce that we have a minimum viable product

![The diffing for both conflicting documents](diff.png)

The feature was created in close collaboration with other developers and UX
researchers. [Here is a video showing the new features in action](

<iframe width="420" height="315" src="" frameborder="0"

Data management is also interesting from the technical point of view. How
can we display a lot of documents, but keep the application snappy?

The revision browser is written in React. The code itself is pretty concise
as we recently added ES 2015 / ES6 support to Fauxton. Thanks to our test
coverage, we can refactor large parts of Fauxton. Recently, we changed the
whole infrastructure underneath without much trouble. Interested in the
code? It is available at:

## Conclusion

Despite its image, data management and database administration IS
interesting. We face hard problems from a product point of view. They are
challenging and it is fun to solve them in a team including developers, UX
researchers, and designers. We also face interesting technical problems and
solve them with the best technology available.

## About the author

Robert Kowalski is a passionate software engineer and CouchDB contributor.
He enjoys traveling and recently released a book about command line tools
in Node.js, [The CLI Book](

On Thu, Apr 21, 2016 at 12:50 AM, Robert Kowalski <> wrote:

> here is the original source of the video (maybe to create better gifs i my
> does not suffice?):
> On Thu, Apr 21, 2016 at 12:48 AM, Robert Kowalski <> wrote:
>> here is the gif:
>> On Tue, Apr 19, 2016 at 8:56 PM, Jan Lehnardt <> wrote:
>>> ooooh, I really like this, the feature and the writeup! Thanks for
>>> offering to post
>>> it on the CouchDB blog. I’d be very much in favour!
>>> I’d suggest we put this in a google doc and give it an editorial
>>> once-over (looking at Jenn with puppy-eyes ^^), but then this is ready to
>>> go.
>>> The video could maybe be a gif, so we can tweet/share it more easily, if
>>> you are up for converting it (or anyone, really).
>>> Great job! :)
>>> Best
>>> Jan
>>> --
>>> > On 19 Apr 2016, at 19:39, Robert Kowalski <> wrote:
>>> >
>>> > Hi there,
>>> >
>>> > I went into a hip cafe this weekend, drank espressi and wrote a
>>> blogpost!
>>> >
>>> > The draft is at
>>> >
>>> >
>>> > If you want we can publish it on the CouchDB blog, but I am also happy
>>> > to publish it somewhere else.
>>> >
>>> > btw.: seems GitHub does not support embedded videos in markdown, so I
>>> > linked it for the draft.
>>> --
>>> Professional Support for Apache CouchDB:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message