r.va.gg

I'm giving a presentation at Node.ninjas tonight in Sydney. I've put together a talk about LevelDB and Node that covers:

1. What LevelDB is and the basics of how it works
2. A quick introduction to the core LevelDB libraries in Node: LevelUP and LevelDOWN
3. Some preaching about the awesomeness of modularity around a small, extensible core; including a whirlwind tour of the current, flourishing, LevelDB+Node ecosystem

It's this last point that excites me the most. There's some very smart people building some very clever pieces to the Node Database puzzle. What's more, people are actually building functional databases in Node now, I've just collected a list from npm of what looks like functional databases that use LevelDB:

• Rumours
• LevelGraph
• PushDB
• NeutrinoDB
• PlumbDB
• Syncstore

And a few more that look like a work in progress. Plus, I'm sure there's more people out there we've never even heard of who are cooking up some amazing things using the LevelDB+Node combination!

The slides to my talk are here.

This is the second article in a three-part series on LevelDB and how it can be used in Node.

• Part 1: What is LevelDB Anyway?
• Part 2: Getting Up and Running

Our first article covered the basics of LevelDB and its internals. If you haven't already read it you are encouraged to do so as we will be building upon this knowledge as we introduce the Node interface in this article.

There are two primary libraries for using LevelDB in Node, LevelDOWN and LevelUP.

LevelDOWN is a pure C++ interface between Node.js and LevelDB. Its API provides limited sugar and is mostly a straight-forward mapping of LevelDB's operations into JavaScript. All I/O operations in LevelDOWN are asynchronous and take advantage of LevelDB's thread-safe nature to parallelise reads and writes.

LevelUP is the library that the majority of people will use to interface with LevelDB in Node. It wraps LevelDOWN to provide a more Node.js-style interface. Its API provides more sugar than LevelDOWN, with features such as optional arguments.

LevelUP exposes iterators as Node.js-style object streams. A LevelUP ReadStream can be used to read sequential entries, forward or reverse, to and from any key.

LevelUP handles JSON and other encoding types for you. For example, when operating on a LevelUP instance with JSON value-encoding, you simply pass in your objects for writes and they are serialised for you. Likewise, when you read them, they are deserialised and passed back in their original form.

Continue reading this article on DailyJS.com

This is the first article in a three-part series on LevelDB and how it can be used in Node.

This article will cover the LevelDB basics and internals to provide a foundation for the next two articles. The second and third articles will cover the core LevelDB Node libraries: LevelUP, LevelDOWN and the rest of the LevelDB ecosystem that's appearing in Node-land.

What is LevelDB?

LevelDB is an open-source, dependency-free, embedded key/value data store. It was developed in 2011 by Jeff Dean and Sanjay Ghemawat, researchers from Google. It's written in C++ although it has third-party bindings for most common programming languages. Including JavaScript / Node.js of course.

LevelDB is based on ideas in Google's BigTable but does not share code with BigTable, this allows it to be licensed for open source release. Dean and Ghemawat developed LevelDB as a replacement for SQLite as the backing-store for Chrome's IndexedDB implementation.

It has since seen very wide adoption across the industry and serves as the back-end to a number of new databases and is now the recommended storage back-end for Riak.

Continue reading this article on DailyJS.com

I visited lovely Dublin last month to attend PeerConf. While there I got to meet a great bunch of Irish programmers at Node.js Dublin, a semi-regular Node.js meet-up that happens in the Engine Yard office in Dublin.

I was invited to give a presentation on LevelDB and the work that I've been doing on it in Node.js. I was followed by Dominic Tarr who's doing some amazing work on top of LevelDB.

You can view my slides here but a written version is currently being spread over 3 parts on DailyJS. More about that soon!

In my previous post about Bean I discussed in detail the work that has gone in to a v1 release and how it will differ from the v0.4 branch.

Bean version 1.0.0 has now been released, you can download it from the GitHub repository or you can fetch it from npm for your Ender builds.

Here's a quick summary of the changes, but for a more in-depth look you should refer to my previous post.

on() argument ordering: the new signature is now .on(events[, selector], handlerFn), which will work on both Bean as a standalone library and when bundled in Ender. In Ender, the following aliases also pass through on() so the same arguments work: addListener(), bind(), listen() and one() (which of course will only trigger once). Plus all the specific shortcuts such as click(), keyup() etc. although these methods have the first argument hardwired.

add() is left intact with the same argument ordering for standalone Bean and delegate() has the same signature, the same as jQuery's equivalent.

off() is the new remove(): although remove() is still available in standalone Bean.

Bean attaches a single handler to the DOM for each event type on each element: as outlined above, Bean will iterate over all handlers for each triggered and (mostly) reuse the same Event object for each call.

Event.stopImmediatePropagation(): is available across all supported browsers, it will stop the processing of all handlers for the current event at the current element (i.e. the event will still bubble).

The selector engine argument to add() is now completely removed: you used to have to pass a selector engine in as the last argument for delegated events. Now you must set it once at start-up with setSelectorEngine(). This is automatically taken care of for you in an Ender build.

A duplicate-handler check is no longer performed when you add: performance testing showed that this was a massive slow-down and is simply not something that Bean should be responsible for. If you want to add the same handler twice then that's your business and responsibility.

Namespace matching for event fire()ing now matches namespaces using an and instead of an or: so for example, firing namespaces 'a.b' will fire any event with both 'a' and 'b' rather than either 'a' or 'b'. This is compatible with jQuery and is arguably a much more sensible and helpful way to deal with namespaces. You can find some discussion on this on GitHub.

Lots of internal improvements for speed, code size, etc..

There was one remaining question to be resolved—whether Event.stop() would also trigger Event.stopImmediatePropagation(). I've decided to not include it and leave it to the user to decide whether they want to prevent triggering of other listeners on the same event/element.

And that's it! Please give it a spin and open an issue on GitHub if you have any bugs to report or questions to be answered.