Olivier Scherrer

CouchDB offers three distinct APIs for querying documents. It also comes up with an API to track changes happening in a database.

I’ve written 3 articles to explain how to use these APIs in real-time web applications, using the _changes API that is available through a keep-alive socket. They describe the flow of requests needed to fetch the documents, keep them up-to-date with the database, and when available, update the database when changes happened on the client side:

• Document API in a real-time application
• Bulk Document API in a real-time application
• View API in real-time a application

Also note that these articles reflect how Emily CouchDBStore works, in combination with Transport

CouchDB has a nice, simple and complete HTTP API. It can also feed a keep-alive socket with the changes happening in a database, thanks to the continuous feed. And this is a nice feature to be used in a real-time application.

There are three available APIs for querying data:

• document
• bulk document
• view

I’ve started a serie of articles in which I’ll explain the flow of requests I’m using to get data from CouchDB and to keep it synchronized with changes on the database, regardless of the API.

The first article involves the CouchDB document API and is available on github: https://github.com/flams/emily/wiki/CouchDB-document-in-a-real-time-application

I’m really happy to announce that Emily and Olives have been officially released today.

It’s hard to find the words to express what I’m feeling now. These two frameworks have consumed almost all my spare time since last September, and they’re the achievement of 2 years of trial and error, research and development, joy and fear. To be honest, had I known how hard it is to come up with what I’ve got today, I think I’d have given up on day 1.

My first Pirates JS Framework attempt has failed, it was in 2010. Emily was born in July 2011 from the ashes of Pirates. Emily is runtime agnostic, it provides tools for manipulating data and common design patterns such as states and observable. Olives is more about creating UIs, connecting views to models and fetching data from the server.

Running both frameworks allows to create incredible realtime applications on node.js with no effort. The API was designed to solve the developers’ problems, not mine.

But allow me to talk about their features in forthcoming articles.

For now, numbers:

• ~1300 hours work since last september
• 15 AMD/commonJS modules
• 100% code coverage, 100% TDD
• 408 tests and many, many more assertions
• Emily: 1815 lines of code, 3499 lines of tests
• Olives: 1301 lines of code, 2258 lines of tests
• Emily is only 12,858b and Olives 8,264b
• That’s 2.3 lines of working code per hour
• And 4.4 lines of tests per hour
• 0 regression. Never saw one.
• And as of today, 3 happy developers using them and making feedback for improvements.

There’s a working demo of Olives based on Addy Osmani’s todo app. There’s a suggestion application too that’s being developed, showing the full potential of Olives.

And more to come!

Also, I wanted to thank Olivier Wietrich @owietrich for his tremendous help. He’s brought lots of good ideas such as Olives plugins, he’s tested the frameworks, contributed to the code and was the first ever to actually develop on them. Many many thanks!

There’s one thing I dislike in JavaScript, it’s the if/else structure.

I’m not saying that I don’t use it, it’s nice to use it to check a value’s type or truthiness, for error proofing or input checking. But when it’s being used for deciding wether or not to execute an action, then I sense that it could be replaced by a nice behavioral design pattern.

That’s when the finite state machine enters the play. I like finite state machines because they’re open/closed compliant, they nicely structure the code, making it easy to read, to maintain and a breeze to add functionalities to.

In Emily and Olives frameworks, I use state machines in many places. In promises to handle resolved/unresolved states, in couchDB stores for synchronized/unsyncrhonized states, or in UIs because their life cycles can be a series of states.

I like them so much that I even golfed one down 140 bytes. It’s now 106 bytes and I don’t know what feature to add next in the remaining 34 bytes. 

Any clue?

Testing is an important part of a project. While developing Emily I had to set up an environment that would automate testing for several cases.

As I followed a full TDD process for developing Emily, I needed a way to get instant tests results. But Emily is designed to be executed in a browser, as well as in a node.js environment, and I wanted to pass the same tests for both.

So I started to look for a testing framework that would run in any JavaScript runtime and Jasmine appeared to be the perfect fit. It doesn’t rely on the DOM and it has the right documentation and tools for a quick and easy setup.

I npm installed an adapter for running the tests under node.js, managed to find a reporter for readable tests results in the shell and automated the task in my build process.

Everything went pretty well until I got stuck with running the specs with jsTestDriver when my modules under tests are loaded with require.js. JsTestDriver is needed for testing Emily’s modules in browsers.

I found a solution, thanks to two things:

• I wrapped the specs into AMD/commonJS modules
• The modules under tests are all loaded before the specs are executed 

Then I was able to run the same specs regardless of the environment.

The final step was to make the specs available for anyone to run. The goal here is to allow for developers to test Emily into their target environments by sharing a public HTML page that runs Jasmine against the built framework.

I’ve created a repository on github to showcase the whole solution. There’s a walkthrough in the wiki for reproducing the steps. Please feel free to comment and/or fork to improve the environment.

Here’s the link: https://github.com/podefr/jasmine-reqjs-jstd

And you, how do you test your code?