Continuous Integration Server Overview

Since I plan to set up a continuous integration server in the near future, I had a quick look around for open source and cloud-based solutions; my main concern was finding something which will work for a small scale project and result in reasonable costs.

Jenkins (Open Source)

The best choice if you are looking for an open source CI server. If you are familiar with Java, setting up and running Jenkins on your own is in all likeliness much cheaper than any cloud-based alternative.

Buildbot (Open Source)

Jenkins looks to be more widely used than Buildbot. However, if you have a Python project, Buildbot might be worth considering.

Travis CI (Cloud)

My top choice for open source projects. For commercial projects, however, the costs seem to be quite high starting with US$69 per month.

Circle CI (Cloud)

They offer one build container for free which seems like a very generous offer to me. I haven’t explored though how powerful this container is and how long builds would take.

AWS CodePipeline and AWS CodeDeploy (Cloud)

The best choice if you are using an AWS environment.

Codeship (Cloud)

They offer 100 builds per month for free which seems to be quite reasonable. However, since builds are triggered automatically this figure can be reached relatively quickly even with smaller projects.


Free Cloud CRM for Small Business

I had a brief look around today for Cloud-based (SaaS) CRM solutions which are free and of use for small businesses and startups.

My recommendation as of now would be to go with Podio. It’s free and offers a nice set of features and integrations.

Here is the list of all the solutions I looked at:

1. Insightly

PROS: Good integration with Gmail and other Google Services

CONS: Synchronization with Gmail contacts only available for paid accounts

2. Nimble

PROS: Good integration with various social platforms, especially for monitoring them.

CONS: Ability to synchronize contacts with Gmail only via PieSync (which starts at $5 / mo).

3. Zoho CRM

PROS: Good integration with other Zoho Services such as Email and Calendar.

CONS: No integration with LinkedIn (not that there could be much of it anyway). No Mass Emails for free account.

4. Highrise

PROS: Easy to use, focusses on the management of contacts and everything around them.

CONS: No file storage for free account.

5. Podio

PROS: Very versatile system with many other applications. Nice design.

CONS: Not very strong specific CRM features.

Further solutions I didn’t look into: Clevertim, Capsule, Odoo


Zapier is not exactly a CRM system but it is a great service to link the various CRM systems to other systems such as an email system or various social networks. But watch out, some of the CRM services, such as Zoho CRM are marked as ‘Premium Services’ of which you can only connect a small number without incurring higher fees.

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