CodeMirror 3 Indent All Lines / Autoformat


You have created an instance of a CodeMirror and initialized it with some text and would like to correct its indentation or you would like to give the user the option to ‘autoformat’ the text entered.


Iterate over all lines in the editor and indent them individually:

var e = CodeMirror.fromTextArea(textarea.get(0), {});

for (var i=0;i<e.lineCount();i++) { e.indentLine(i); }

This should indent all lines in your editor nicely:

Note that in CodeMirror 2 there was an autoformatter add-in which is not officially supported for CodeMirror 3.

Setting Up Xtend with Maven and eclipse (Luna)

Xtend is currently my favourite alternative language for the JVM (closely followed by Kotlin). Unfortunately, I did not find a good guide of how to set up a Maven project within eclipse (Luna) which uses Xtend.

Specifically the following guide will allow you to allow you to write test cases in Xtend for your existing Java projects. A great way to get started with Xtend I suppose.

The following describes the necessary steps.

  • Install the Xtend plugin for eclipse as described here.
  • Add the xtend-maven-plugin to your pom.xml as follows:


  • Also add a dependency to the Xtend runtime libraries
  • Right click the project and select Maven / Update Project … and update the project.
  • Right clock the project and select Properties
  • Go to the Xtend / Compiler page
  • Set as the ouput director src/test/java

  • Go to the folder src/test/xtend. If the folder does not exist, create it.
  • Right clock the folder src/test/xtend and select Build Path / Use As Source Folder
  • Create a package in the new src/test/xtend folder and right click the package. Select New / Xtend class and define a class such as the following:

import org.junit.Assert
import org.junit.Test

class TestThatNumbersAreEqual {
    def void test() {
        Assert.assertTrue(3 == 3)
  • Immediately after you save the class a translated class should be created in the folder src/test/java

Now, have fun writing tests using Xtend’s concise syntax – while not affecting any step of your build and development workflow!

To see an example configuration in a complete project, also check out async-map on GitHub.


A Comparison of Data Models in BaaS (Backend-as-a-Service)

While Backed-as-a-Service (BaaS) – and their stepbrothers PaaS – offerings should sensibly support various domain-specific data models for the application they support, these services are inherently built on a ‘meta’ data model. This meta data model lays the constraints for all domain-specific data and should thus be an important consideration in selecting or not selecting a BaaS solution.

I have sifted through the documentation of five popular BaaS solutions and tried to uncover the fundamental model of data underlying these platforms. My findings are presented below.

In a Nutshell

All examined solution but Firebase have a ‘three-tier’ data model where similar JSON documents are aggregated in collections or classes, which allow the effective querying of these documents. These collections of JSON documents in turn are aggregated in databases or per application. Some solutions provide additional mechanisms for defining connections between JSON documents (Parse, usergrid). Firebase features the most unique model; where all data is stored in one very big, hierarchical JSON document.


Parse stores data internally as flat JSON Documents, called ParseObject, with have the restriction that keys must be alphanumeric strings. Parse automatically creates ‘classes’ for ParseObjects, grouping objects with similar properties. Classes and all objects associated to them belong to applications, which can be defined on the Parse web interface. In addition, Notably, Parse allows for various types of relationships between ParseObjects for one-to-many and many-to-many relationships.


Firebase stores data as JSON documents. Essentially, a data store in Firebase is one large JSON document. Data stores are associated with subdomains such as <my store>


Fundamentally, Kinvey stores data as collections and entities. Entities are essentially JSON documents. Collections belong to applications. Internally, data is stored in a MongoDB cluster.

Apache usergrid_

The Apache usergrid_ documentation did not make it easy to find out about the data model underlying the platform. I think the data is primarily stored as JSON documents named entities on the platform. These in turn (I think) are stored in collections. Collections themselves belong to applications. Notably, Apache usergrid has some support for graph-like data as relationships between entities. Internally, Apache usergrid is based on Cassandara and provides good support for relational/SQL type queries.


Data in BaasBox is stored as JSON documents called documents. These documents are grouped in collections. Collections are ultimately stored in databases. Since every BaasBox server represents one application, databases belong to the application configured for the server.



ParseObject JavaDoc

Parse JavaDoc

Parse Documentation – Data & Security


Firebase – How It Works

Firebase – Understanding Data


A backend’s representation inside Kinvey

Android – Data Store

Apache usergrid_ in usergrid Java client library

Apache usergrid Documentation


BaasDocument JavaDoc

BaasBox Documentation – Database Management

UML Diagrams created with





Force Android Studio to Update Maven Snapshot Dependencies


You are using Gradle to build your Android Studio project and you have linked Maven SNAPSHOT modules.

When you build your project, Gradle/Android Studio does not grab the latest version of the SNAPSHOT module but instead uses a cached version.


Add the following to your build.gradle:

configurations.all {

resolutionStrategy {

cacheChangingModulesFor 0, ‘seconds’




Gradle DSL Documentation – Resolution Strategy

Gradle Documentation Chapter 50, Section 50.9.22 Refresh

Gradle Forum – Use latest version of changing module