In January, 2015 I published the marionette-vdom project on GitHub. This project aims to implement Marionette.js views with virtual-dom, in a React similar fashion.


One among React’s top-notch features, virtual DOM is gaining momentum in the front-end development community. Since Marionette.js is a formidable and constantly evolving library, why not adding one good thing to another?

A key concern here is ensuring that whatever code implementing virtual DOM features won’t break any existing functionality. That is why we have incorporated the whole test suite from Backbone.js and Marionette.js for the related classes, and all the 163 specs are passing.

Current status

To the date, its version 0.1.2 is implementing VDOM versions for Marionette.ItemView and Marionette.CollectionView. It can be used through node.js, available on NPM.

Travis CI status:


This module exposes VDOMItemView as the VDOM implementation for Marionette.ItemView and VDOMCollectionView for Marionette.CollectionView:



In January, 2015 I published the jasmine-precondition project on GitHub. This project aims to implement a Jasmine instruction to ease setting up asynchronous pre-conditions before, during and after tests.


Since Jasmine 2.0, the runs, waits, and waitsFor methods have been removed in favor of allowing functions run as part of the spec to receive and invoke a done callback. This new approach is described at Upgrading Jasmine - Asynchronous Specs.

The done callback works great for asynchronous features with a callback (such as AJAX, jQuery animations or anything else with promises). However, there are yet other asynchronous features that will complete on their own and would be using waitsFor before Jasmine 2.0, like rendering Google Maps, images or anything else that can change both the DOM and the CSSOM.

While it is utterly possible to re-implement waitsFor I believe that Jasmine 2.0 direction is more towards stepping away from this idea and instead taking more advantage of done callbacks, like putting one it block as a pre-condition for another.

Thus, the preCondition instruction defined here will simply poll a given conditional function at a certain time interval, and once its condition is met the callback done will be fired off.

Current status

To the date, its version 0.1.0 can be used either standalone and through node.js, available on NPM.

Travis CI status:


preCondition(condition, done, interval);


  • condition: a conditional function that shall only return true when the condition you are expecting for is met.
  • done: the done callback from beforeEach, it or afterEach must be passed here.
  • interval (optional): a time interval in milliseconds between two condition executions. Default is 100.



In August, 2013 I published the Tasker Project on GitHub to illustrate the article I wrote for Java Magazine #123, Boosting applications with REST and Backbone.js .

Tasker is a web application using Backbone.js and Handlebars.js on the client-side and Play! over Java on the server-side. This application simulates a very simple Kanban board based on Agile methodologies. Basically, the board can have multiple projects, each project can have multiple stories and each story can have multiple issues, which can be either task, bug or enhancement.

The user can create and remove projects, stories and issues, and also move issues around 4 lanes representing its possible status: Backlog, In Progress, Verify and Signed Off.


The main purpose of Tasker is to demonstrate important front-end concepts of nowadays about smart client-side applications, such as:


  • MV* on the client-side with Backbone.js
    • REST-based models
    • views
    • routers
    • events
    • validation
  • Templating with Handlebars.js
    • Custom helpers
  • Using Bootstrap components
  • Using Font Awesome fonts
  • Writing LESS css
  • UI-level i18n
  • Responsive/adaptive layout


  • Play! Framework as a modern, simple yet powerful back-end
    • models
    • views
    • controllers
    • REST-based routers
    • Google Clojure compilation and minification
  • Ebean as a simple ORM approach
    • JPA-based mapping
    • simple query language
    • evolutions
  • JSON manipulation with Flexjson
  • Unit testing with TestNG
  • Code coverage
  • Setting production profile
  • Deploying to Heroku