Olivier Scherrer

Missing feature of the day: grouping DOM nodes

Wed, 16 Jan 2013 01:04:00 +0100

Let’s say that you’re developing a JS Framework that has the concept of widgets. A widget is a JavaScript Object with a representation in the DOM. As you have one reference on the JS Object somewhere in your application, you’ll want to have one reference to its DOM structure, and unfortunately the only way is to wrap the template into one parent DOM element.

For example, one of your widgets has the following template:

<p>
    Text 
</p>
<ul>
    List items
</ul>

When converting this to dom nodes (how you do it doesn’t matter here) you may have a list of dom elements, one p tag, and one ul tag, or have a parent dom element wrapping them. Let’s call these two items a group. But when this group gets appended to the dom, you lose the notion of group, as they become two nodes among the others.

To illustrate this, let’s imagine that after being attached (how you do it doesn’t matter here) we have the following structure:

<div>
    <p>
        Text
    </p>
    <ul>
        List items
    </ul>
    <p>
        Another widget here
     </p>
</div>

As the notion of group is lost, there is no way now to distinguish them from the dom nodes of another widget. We can’t take them out and append them somewhere else.

This problem is solved by wrapping them into a parent dom element, which creates the notion of groups. Usually a div is chosen. But the drawback here is that we have added an unnecessary dom element that could have been avoided. And unnecessary dom elements are one major cause of performance loss.

One way of solving this issue would have been with using a document fragment. A documentFragment looks like a dom element though it can’t have a representation in the actual dom. Unfortunately, once appended to the dom, it loses its children.

// this is our dom element that doesn't exist in the DOM
var domFrag = document.createDocumentFragment();

// We add it actual dom elements, they're part of our widget
domFrag.appendChild(domElement1);
domFrag.appendChild(domElement2);

// It has two children
domFrag.childNodes.length == 2; // true

// We append our non-dom element somewhere into the DOM
destinationDom.appendChild(domFrag);

// Our documentFragment still exists, but has no more children
// Of course, it doesn't exist in the DOM, though its child now do.
domFrag.childNodes.length == 0; // true

Another way of doing it would have been to have a grouping method in the DOM.

// A real dom element without tag
var domGroup = document.createDocumentGroup();

// Let's call its innerHTML, it's fast and cross browser.
domGroup.innerHTML = "<p>Text</p><ul>list items</ul>";

// That's two items
domGroup.childNodes.length == 2; // true

// They get appended to destinationDom, no extra HTML tag added.
destinationDom.appendChild(domGroup);

// They're still part of the domGroup.
domGroup.childNodes.length == 2; // true

// So I can move them around
otherDestinationDom.appendChild(domGroup)

The domGroup would not have a representation in the dom, so its children could be direct children of the destinationDom, but can still be moved around by appending the group somewhere else. If ever a childNode gets appended somewhere else, it would simply leave the group.

You may also have noticed that a documentFragment doesn’t have an innerHTML property, which is a shame as it’s a cool way for creating dom nodes out of strings, and it’s fast because it’s using the browser’s rendering engine.

Fortunately, the domGroup would have this feature, which would become the number one tool for defining a widget’s view:

var widget = {
    this.element: document.createDocumentGroup(),

    this.render: function (template) {
        if (template instanceof HTMLElement) {
            this.element.appendChild(template);
        } else if (typeof template == "string") {
            this.element.innerHTML = template;
        } else {
            throw new Error('template must be either a string a set of dom elements');
        }
    },

   this.place: function (destinationDom) {
        destinationDom.appendChild(this.element);
   }
};

How cool would that be?

Migrating from Emily 1.2.0 to 1.3.1

Mon, 14 Jan 2013 00:28:37 +0100

Last week I explained how to migrate from Olives 1.2.0 to 1.3.0. Emily has seen a few breaking changes too between 1.2.0 and 1.3.1:

Modules are anonymous
Promise is fixed
CouchDBStore has been completely removed

Modules are anonymous

Olives modules are now anonymous, just like Emily’s. Read this to know what the implications are.

Promise is fixed

Until 1.3.0, Emily’s Promises where an interpretation of Promise/A, but were done wrong. After Domenic’s gist on promise I realized that I had to fix them. Emily 1.3.0 made Promise compliant with promise/A, and since 1.3.1 they’re now also compliant with Promise/A+.

The API has changed, resolve is now called fulfill, and chaining promises is now working as expected:

promise.then(function (result) {
    var newResult = doSomethingWithResult(result);
    return newResult;
}).then(function (newResult) {
    ...
});

CouchDBStore has been completely removed

Although CouchDBStore was removed from Emily since 1.2.0, the server part was still embedded in Emily’s handler. This is now fixed an part of CouchDB-Emily-Tools.

To use CouchDB-Emily-Tools, you simply need to add its handler to Emily’s server:

var emily = require("emily"),
    tools = require("couchdb-emily-tools");

emily.handlers.set("CouchDB", tools.handler);

tools.requirejs(["CouchDBStore", "Transport"], function (CouchDBStore, Transport) {

    var cdb = new CouchDBStore,
        transport = new Transport(emily.handlers);

    cdb.setTransport(transport);

    cdb.sync("mydatabase", "mydocument")
    .then(function () {
        console.log(cdb.toJSON());
    }, function (error) {
        console.log(error);
    });
});

Migrating from Olives 1.2.0 to 1.3.0

Fri, 04 Jan 2013 01:01:00 +0100

Olives 1.3.0 introduces two breaking changes that you must be aware of before upgrading:

Modules are now anonymous
Some of them have been renamed

These changes lead us to a new way of using Olives in your project:

EOWYN: Embed Only What You Need.

Anonymous modules

Until 1.2.0, Olives modules were named and prefixed with Olives/:

define("Olives/ModuleName", function ModuleName() {
    ...
});

Modules had to be named so they could be loaded into the test runner (jsTestDriver) before the specs and the specs are able to require them (with requirejs). Then they had to be prefixed with Olives/ to create a namespace and avoid collision with other libraries. The counterpart is that it’s ugly and repeats the file name, à la Java.

As I didn’t like it much I preferred adding a pre-compilation step before running the tests. I was then able to remove the names in the modules definitions, keeping my project DRY.

Olives modules are now anonymous by the commonJS definition.

Renamed modules

For the names to be more explicit and for Olives plugins being easier to spot, the following modules have been renamed.

Model-plugin.js is now called Bind.plugin.js
Event-plugin.js is now called Event.plugin.js
UI-plugin.js is now called Place.plugin.js
Transport.js is now called SocketIOTransport.js

EOWYN: Embed Only What You Need

Theses changes allow you to better integrate Olives within your project. Given that you already use require.js and its optimizer (or any equivalent), you can simply download Olives’s parts that you actually need and paste them into one of your application’s directory. Make your require.js configuration point to them and you’ll be able to develop and debug your app with the unminified version of Olives. Finally, when minifying and packing your application, Olives will be seamlessly embedded without any the extra weight.

Of course, you can still download and use the built Olives for rapid prototyping, just like it used to work with the previous versions of Olives, but with the new names.

Checkout Olives’ github for more information: https://github.com/flams/olives

Securing CouchDB in 3 steps

Wed, 05 Sep 2012 00:56:00 +0200

Freshly installed, CouchDB offers little to no security. There’s even a name for that temporary state: its called the “Admin Party”, as every user is considered to be an admin.

While it might seem dangerous, it’s actually a nice thing as it lets you fine tune the level of security you want to obtain.

Say you’re in learning mode and you just want to figure out what CouchDB is and how it works. You’re creating databases and documents and fetching them through design documents. At this time there’s no need to secure anything, and anyway, CouchDB is bound to your local address so you’re the only one who can mess around with it.

But start using it in production, with an application that manipulates sensible information, and you’ll have to go deeper into securing it.

And that’s what i’m going to describe, in 3 steps.

Identifying the user who issues the request
Limiting a user’s read/write access to a database
Limiting a user’s write access to his own documents

1. Identifying the user who issues the request

CouchDB stores its users in the _users database. A user document looks like this:

{
    "_id": "org.couchdb.user:couchdb",
    "_rev": "1-8995e8ff247dae75048ab2dc800136d7",
    "name": "couchuser",
    "password": null,
    "roles": [
    ],
    "type": "user"
}

The _id is the user’s name prefixed with “org.couchdb.user”. _rev is the document’s revision. name is the name of the user, the one that the user will remember, along with his password. Roles is a feature that we’ll develop when speaking about _security documents. It allows to create some sort of groups for the users. Finally, type can only be user.

While roles and type should be defined by the application during the account creation phase, name and password are chosen by the user. They are his credentials.

More information on the authentication database in the official wiki

So, how does one authenticate himself?

Basic authentication

This authentication mode is using the name:password@url style. For a couch user couchuser whose password is couchpass, the request url would be:

http://couchuser:couchpass@localhost:5984/db/document

Querying CouchDB with the user’s credentials will create a “user context” object that will be passed around to control functions, such as the validation functions we are going to talk about.

Cookie authentication

The second way of authenticating a user is by issuing a POST request on _session. The request must embed the credentials:

curl -vX POST http://localhost:5984/_session -H 'application/x-www-form-urlencoded' \
-d 'name=couchuser&password=couchpass'

The response’s header will have a Set-Cookie field that can now be re-used to authenticate the user for 10 minutes, depending on your configure files.

HTTP/1.1 200 OK
< Set-Cookie: \
AuthSession=Y291Y2hkYjo1MDQ2NUI3MjrL7w8A3NhUpW6XkVvVVJ25epeGsw; \
Version=1; Path=/; HttpOnly

You’re going to need to be able to extract the AuthSession from the header before passing it to further requests. Here’s an example of a request embedding AuthSession:

  curl [your request here] --cookie \
  AuthSession=Y291Y2hkYjo1MDQ2NUI3MjrL7w8A3NhUpW6XkVvVVJ25epeGsw

More on authentication is available here.

Now that the user is authenticated, we can control which databases he has access to.

2. Limiting a user’s read/write access to a database

Database-wise, there are two types of users, admins and readers.

Readers can create, read and write document except for design documents. Database admins can also modify design documents and _security documents. They can do some other stuff but it’s not the purpose of this article.

The _security document will simply specify what type of database user a CouchDB user is:

// This example comes from the CouchDB guide
{
    "admins" : {
        "names" : ["joe", "phil"],
        "roles" : ["boss"]
    },
    "readers" : {
        "names" : ["dave"],
        "roles" : ["producer", "consumer"]
   }

}

Notice the “roles” fields. Instead of adding every user in the names array of the _security document, you could instead specify which roles are admins or readers, and assign the adequate role to the user.

As soon as a _security document is added to a database, any user not listed in is not granted any access. [need to double check on that]

Authorization documents in the official wiki are explained here.

We can now prevent users from wandering around in our application. But if a user’s granted access to a database, how can we secure write access to documents that he doesn’t own?

3. Limiting a user’s write access to his own documents

Design documents can have a validation function that is called everytime a document is altered. Here’s an example of a function that checks if the user who tries to modify a document is its owner.

"validate_doc_update": "function (newDoc, oldDoc, userCtx) {
     if (newDoc.author != userCtx.name) { 
         throw({ 
             forbidden: 'Only' + userCtx.name + ' may edit this document'
         });
     }
  }"

Throw defines the error that is returned to the application. Other helper functions are available too:

required(field) : check if a field is set in a submitted document
unchanged(field) : prevent changes in a field
user_is(role) : check if user has given role

UserCtx has other properties:

roles : the roles that are assigned to the user
db : the name of the database

And a last argument is passed to the validation function, the database’s security document.

Locally test your npm modules without publishing them to npmjs.org

Thu, 30 Aug 2012 02:47:00 +0200

There could be several situations where you want to locally deploy an npm module of your own before publishing it to npmjs.org.

Say you’ve just created one and want to see how it deploys, or you’re fixing bugs and you want to test the module in integration before publishing a new version, or you just want to keep your npm private.

To create a local npm, change directory to where its package.json is.

cd /path/to/package.json

Then run the pack command:

npm pack

This will create, in the same directory, a tarball named after the name of the project + the version specified in the package.json.

This is exactly what is published to npmjs.org! You can now see what’s inside

tar -tf packagename-version.tgz

Or you can install it in your project to test it in integration.

cd path/to/your/project/
npm install ../path/to/your/npm/packagename-version.tgz

As you can see, ‘npm install’ can either be used to fetch an npm on the official repository, or to install a local one.

Note that each time you’ll run npm install, the previous files will be overridden by the new ones, regardless of the version number, which is pretty convenient!

Hope this helps!

Vincent Weyl: The toy designer: an Ideafy use case with Q&A

Wed, 22 Aug 2012 11:48:03 +0200

Vincent Weyl: The toy designer: an Ideafy use case with Q&A:

vweyl:

THE TOY COMPANY SCENARIO

Jane Doe is working at a toy company that just bought a license for a major motion picture to use the characters in connection with the toys they produce.

Usually making such a “buy” decision means you already have a good idea what you’re going to do with this…

HTML5 and bindable datalist

Tue, 12 Jun 2012 13:48:25 +0200

owietrich:

HTML5 datalist* allows to autocomplete input elements with static content (option element).
<input list="cars"/>
<datalist id="cars">
  <option value="BMW"/>
  <option value="Ford"/>
  <option value="Volvo"/>
</datalist>
Thanks to Olives Framework, you can bind datalist options to a store and set them as you wish.

If you are interested, I put an example into my github.

*Until now, only Firefox supports this feature.

Olivier Wietrich: A real-time blog by your own in 8 JavaScript lines of code

Mon, 11 Jun 2012 15:02:21 +0200

Olivier Wietrich: A real-time blog by your own in 8 JavaScript lines of code:

owietrich:

Hi,

If you’re familiar with Nodejs you’ve surely read some stuff about how to create a blog with this technology and others such as socket.io, mongoDB or couchDB.

I have and even though it was quite simple, it was still too much for me. Why make easy things difficult? It’s a question to which I…

Olives 1.1.5 supports SVG views

Fri, 01 Jun 2012 00:24:53 +0200

Since version 1.1.5 Olives is officially supporting SVG. SVG and HTML are very similar and can be manipulated almost the same way. It’s all about creating xml tags, setting there attributes and styling them. The great news is that Olives was born to support SVG and only a few modifications were required to support them.

In Olives, views are almost fully passive. They have no logic attached to them, let aside the data- attributes that describes the plugin calls. Considering that HTMLElement and SVGElement are almost similar, we should be able to treat SVG views just like we treat the HTML ones.

As an example, I’ve create an SVG+Olives charting demo.

Let’s see how the grid of the demo is built:

We first create an SVG group that will group the horizontal lines:

<g class="grid">
    <g data-gridy="foreach">
        <line x1="0" y1 x2="600" y2 data-gridy="bind: y1; bind: y2" />
    </g>
</g>

If you’re familiar with Olives, you’ll recognize the data- attributes that specify which plugin to use to manipulate the SVG. data-gridy will call the foreach method of the ‘gridy’ plugin on the Element, when bind will be called on the line method.

The plugin is configured in the Grid UI and it binds the SVG with the gridY data store.

grid.plugins.add("gridy", new ModelPlugin(gridY));

The combination of the SVG and Olives will generate as many lines as specified in gridY, with y1 and y2 being replaced by the store’s values, as declared by data-gridy=”bind: y1; bind: y2”.

Once the grid is generated, we can render the chart on top of it.

The chart is a polyline:

<g class="chart">
    <polyline points="" data-line="bind: drawLine, line" />
</g>

To add points to a polyline, we have to add them to the points=”” attribute. These points have a special formatting and can’t be simply extracted from an array of points. So we need to create a drawLine function that will handle this formatting. drawLine will then be added to the Model-plugin.

points is a simple array with many points: [ 43, 65, 87, 83, 79, 101, 102, 95 ]

chart.plugins.add("line", new ModelPlugin(model, {
    drawLine: function (points) {   
        var newPoints = [];

        // We populate the new array
        points.forEach(function (val, idx) {

            // 20px separate each point
            // the Y axis is "inverted" so subtract the value to 200
            newPoints.push([idx*20, 200-val]);

        });

        // It also has "terminating points"
        newPoints.unshift([0, 200]);
        newPoints.push([newPoints[newPoints.length-1][0], 200]);

        // Finally, we join all the points (x1,y1 x2,y2 x3,y3…)
        // And set the points attribute
        this.setAttribute("points", newPoints.join(" "));
    }
}));

Any kind of chart can be rendered using this technique, bar charts, pie charts, whatever. And we can even go further by connecting our models to a node.js server to have real-time charts!

Understanding Olives' MV* model

Wed, 16 May 2012 09:31:00 +0200

Olives is a JavaScript MVC-like framework for building web applications. There are already loads of MVC frameworks out there (more than 30 featured in todomvc.com including labs!) and almost each of them interprets the MVC model in a different manner. To better understand how to develop web applications using Olives, I need to explain its own interpretation first.

Olives’ MV* was carefuly designed to address 3 major points:

Maintanable application
Extendable application
User-centred API

Of course there are others, but these 3 certainly had the most impact on Olives’ design.

Let’s create an extremely simple UI example taken from Olives’ dev environment to see what it looks like

When I click on “en” I’d like “Hello Olives!” to be displayed, but when I click on “fr” I want “Bonjour Olives” instead.

View

In Olives, views are pure HTML, they’re completely passive:

<section>
  <span data-model="bind: innerHTML, greeting">Default Greeting</span>
   Olives!<br />
  Choose your greeting : 
   <a href="#" data-event="listen: click, changeLanguage">en</a> 
   | <a href="#" data-event="listen: click, changeLanguage">fr</a>
</section>

located in index.html

You’ll notice the data- attributes though, they’re the only link to the logic. I see multiple benefits to this approach:

Easy to add behavior to existing html
Easy to update, change or evolve even by a non programmer
Easy to style, no pre-processing needed
Easy to find, the view is in an .html files.
No new technology to learn, like a specific templating tool

Model

The model is an observable data store provided by the framework. Olives’ simplest Store can store data in an Array or an Object, and notify on changes. Of course the Model has no knowledge of both View and Model. Example of an Olives model:

// Initializing the Store with an object that has a greeting key.
var model = new Store({ greeting: "Hello" });

// updating the model...
model.set("greeting", "Bonjour");

// ... will also notify observers
model.watch("updated", function ( key, value ) {
   console.log(key, value); // "greeting" "Bonjour"
});

But it can also be sub-typed for persistence, like Olive’s LocalStore which stores the data in localStorage, following Liskov principle.

Olives’ controller uses the simple Store by default, and it can be overridden by any subtype of Store. This is what happens in our simple demo, which is the reason why no model is explicitly defined.

OObject

And then comes the OObject. The OObject is a kind of Controller but with more responsibilities. It’s actually a skeleton of the part of a user interface, it’s the place that concentrates the whole logic. Let’s see it in action.

// OObject creation
var ui = new OObject;

// The behaviors to add to the view can be implemented in plugins
ui.plugins.addAll({

  // This is a plugin that links the view to the model. 
  // Reachable through data-model
  "model": new ModelPlugin(ui.model),

  // This is a plugin that captures user inputs and 
  //transmits them to the OObject (ui)
  "event": new EventPlugin(ui)
});

// Specify the view of the UI
ui.alive(document.querySelector("section"));

// The function that is called when clicking on "en" or "fr"
ui.changeLanguage = function (event, node) {
  //  ....
}

located in index.html

The OObject binds the view to the model through the use of plugins. Olives has a built-in plugin called ModelPlugin, which implements double-way binding: when the model is updated, the view gets updated, and vice-versa.

It also has a plugin called EventPlugin which binds the view to methods of the ui, like changeLanguage.

And of course, you can imagine creating your own plugins to extend Olives capabilities. Why not adding mustaches on pictures using a face recognition plugin? Or translating coordinates to localized city names?

Application examples

The previous example is quite limited. There are two other applications using Olives that serve as example:

TodoMVC This is a more complete application that is divided between 3 UIs that share data.

Suggestions (Under development as of today) Similar to a todo list but with more features, such as routing, real-time model etc.

Comparing Olives’ MV* to MVC

When looking at the files tree, we see that an Olives application isn’t split between several model/controller/view files as we usually have, but in small UIs instead. Each UI is specifically designed for a simple task, like adding a todo, displaying todos, or counting them. And this makes it way easier to design, develop and maintain an application.

While this may not be obvious for a small application with few contributors over a small amount of time, it becomes dramatically more important with bigger projects.

As a project grows in size, its number of files increases, diluting the knowledge of the architecture. As years pass by, developers forget where to put code and just happen to place it where it works. Sometimes duplicating code, data or coupling things that shouldn’t be. The cost to avoid this, through processes, also increases as the project ages. I have seen this too often.

On the other hand, Olives MV* has a 1:1 correspondence between the UI and its source code. You could almost see the files tree as you look at the UI. Divide the UI into multiple views, and each view has a single js file. Because of the way the OObject works, it’s really hard to mix things up and associate some business logic to the wrong view, giving you even more hints on where to place your code. It’s also possible to create generic UIs that can be duplicated throughout the application. The result is that you have a code that is easy to maintain and to extend!

Less plumbing

Last but not least, as the example shows, there’s almost no plumbing. Scanning through the given code, one can seen that every line has a meaning to the developer and not to the framework. There’s no specific Olives way of structuring code, declaring classes, doing inheritance or such, it’s just plain JavaScript, and Olives is an API.

That’s what I call a user-centered API, but I’ll expand my thoughts in another post.

A BMW for wheelchair users

Tue, 08 May 2012 02:03:31 +0200

I worked on this project in 2007, when I was studying automotive design. I found these pictures buried deep into my hard drive and wanted to give them a second life.

The goal was to invent a car that would specifically be designed for wheelchair users without it being perceived as such by other drivers. It had to allow their users to easily get in and out, in a safe and elegant manner.

An innovative way to replace AJAX and JSONP using node.js and socket.io

Mon, 07 May 2012 02:07:00 +0200

I was so happy the first time I used socket.io, seeing how fast, reliable and easy to use it is, that when I started doing XHRs I felt that something was wrong. Current State of the Art implies using AJAX calls coupled with JSONP for getting data from a 3rd party server. To new applications we’re also adding WebSockets that allow to push data from the server to the client. Three different techniques for carrying data, can’t we unify them?

Actually, it turns out that we can. Let’s imagine something like this: data is fetched by the node.js server. By data I mean any data, whether it comes from a database, a web service, the file system, actually anything that node.js can have access to. Each data source is accessed by what would be called a request handler. And when the data is available on the node.js server, it can be accessed from within the application and be streamed to the client using socket.io.

It would resemble something like this:

How would it work from the client side?

A component, let’s call it Transport, would be responsible to query the requests handlers. For instance, verifying a browserID assertion would look like:

Transport.request("BrowserID", assertion, callback);

Fetching data from CouchDB would look like:

Transport.request("CouchDB", { path: "/db/_all_docs" }, callback);

And opening a keep-alive socket that would trigger the callback for every new chunk:

Transport.listen("CouchDB", { path: "/db/_changes" }, callback);

And the exact same syntax would work on the server side with a Transport directly connected to the requests handlers.

How to trick socket.io to transport the requests params and push the result back to the client?

Think of it like JsonP. You load a script on a different website which pads the result with a function name that you’ve previously defined. When you get this result, the callback is executed.

So what I do is, I send the requests params to the server and I ask it to reply on a previously defined channel (a unique one). The server executes the request through the handler, and streams the result back to the client. If transport.request is called, the channel is closed right away, otherwise a function responsible for closing it is returned.

The solution has 5 major benefits

One unique transport
Multi-purpose transport that can stream binary data too
Based on well known technologies
Easy to use
No cross-domain issues

Want to see it in action?

The solution was successfully implemented in Olives JS Framework, which Transport module can be found here, and requests handlers are explained here.

There’s a simple application currently being developed that also uses this Transport module and another use case

Warning

A discussion is going on on socket.io’s google groups. I’m exposing a database to the browser’s application to showcase this solution but this has security issues. I’m looking for a way to secure this and will post about it, until then, just be aware of the implications.

Using CouchDB in a real-time web application

Sun, 22 Apr 2012 23:45:14 +0200

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:

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

Central Park, NYC

Sun, 22 Apr 2012 23:27:19 +0200

Central Park, NYC

High Line Park, NYC

Sun, 22 Apr 2012 23:22:23 +0200

High Line Park, NYC

Photo

Sun, 22 Apr 2012 23:18:33 +0200

Manhattan, NYC

Sun, 22 Apr 2012 23:12:56 +0200

Manhattan, NYC

Harlem, NYC

Sun, 22 Apr 2012 23:10:01 +0200

Harlem, NYC

Manhattan, NYC

Sun, 22 Apr 2012 23:07:43 +0200

Manhattan, NYC

Brooklyn Bridge, NYC

Sun, 22 Apr 2012 23:06:10 +0200

Brooklyn Bridge, NYC

Olivier Scherrer

Missing feature of the day: grouping DOM nodes

Migrating from Emily 1.2.0 to 1.3.1

Modules are anonymous

Promise is fixed

CouchDBStore has been completely removed

Migrating from Olives 1.2.0 to 1.3.0

Anonymous modules

Renamed modules

EOWYN: Embed Only What You Need

Securing CouchDB in 3 steps

1. Identifying the user who issues the request

2. Limiting a user’s read/write access to a database

3. Limiting a user’s write access to his own documents

Locally test your npm modules without publishing them to npmjs.org

Vincent Weyl: The toy designer: an Ideafy use case with Q&A

HTML5 and bindable datalist

Olivier Wietrich: A real-time blog by your own in 8 JavaScript lines of code

Olives 1.1.5 supports SVG views

Understanding Olives' MV* model

View

Model

OObject

Application examples

Comparing Olives’ MV* to MVC

Less plumbing

Links

A BMW for wheelchair users

An innovative way to replace AJAX and JSONP using node.js and socket.io

How would it work from the client side?

How to trick socket.io to transport the requests params and push the result back to the client?

The solution has 5 major benefits

Want to see it in action?

Warning

Using CouchDB in a real-time web application

Central Park, NYC

High Line Park, NYC

Photo

Manhattan, NYC

Harlem, NYC

Manhattan, NYC

Brooklyn Bridge, NYC