I develop data visualizations. This is my personal blog. More about me.


27. März 2017

I happy to share some tidbits from a project I’ve been involved in lately. I was responsible for leading the data visualization team working on the FP7 project ASAP (Adaptive Scalable Analytics Platform). The system we developed is capable of visualizing aggregated information on millions of tweets and overlay it with additional data like telecommunication data (e.g. cell tower usage). Here’s a screencast demonstrating some of the features:

Keine Kommentare zu ASAP

Mini Modules

29. März 2016

My very personal opinion and 2 eurocents on the discussions surrounding the npm issues and the left-pad project: This post is not so much about the technological and social implications of the issues npm and the open source projects which had left-pad as a dependency faced. This is more about what I think regarding small/mini modules and the ecosystem which evolved around them. Personally, I really don’t care how many lines of code a module has. If it solves a need for someone else than myself, why not publish a single useful line of code as a module?

I think when discussing this, one has to take the whole ecosystem and it’s implications into account, not just the language itself. Unlike other languages which offer a unified VM or a supported runtime for your host system, JavaScript is strongly tied to the web and the runtimes provided by different browsers. There are so many interpreters/compilers/environments where JavaScript needs to work. It’s in a web developer’s DNA to work around the quirks and weird behaviour of different environments and solve cross browser issues. That’s why everyone was so fond of libraries like Prototype, jQuery, lodash and others. Their success is one part the patterns and ease of use they provide, but of course because they freed you from the one major pain when debugging web development issues which are of course the cross browser issues. And in recent years this isn’t even so much about the quirks of the major desktop browsers anymore. Think of all the mobile engines, think of the PlayStation browser, think of the poor guys who decided to spend their time developing websites with support for Google Glass.

The rise of mini modules in JavaScript stems from this: When you create code using JavaScript, a certain insecurity will remain if what you did will work everywhere in every kind of runtime that is out there. So even if you could of course implement little helpers like left-pad yourself easily, it’s hard and cumbersome to battle-test it under all kinds of circumstances.

This insecurity is the reason why I’m thankful as a developer to use a module which is hopefully well maintained by a bunch of other people, and more importantly used in the wild by others who will report and try to solve issues with the module (including myself in alternating the mentioned roles from time to time). This is how open source works for me and in that regard I don’t care if a module consists of a single or a hundred gazillion lines of code.

Keine Kommentare zu Mini Modules

An opinionated approach to have type safety in native JavaScript.

27. April 2015


I have to admit, I love JavaScript and do not completely grasp the bashing. It supports my style of thinking and prototyping. I like its flexibility, it gives me a lot of subjective freedom. But as Voltaire and others say, with great power comes great responsibility. By not forcing any models, certain styles or patterns on you there is a high probability of your project ending up in total spaghetti or even worse risotto code.

Therefore I’m a big fan of simple patterns and modularity. I don’t like monolithic frameworks which force you to use a certain structure or style of code. To understand what I like about simple patterns have a look at Bostock’s Towards Reusable Charts and Elliot on Inheritance in JavaScript. Over time I found a nice personal approach inspired by the mentioned ideas to structure code and work with OOP.

Originally coming from the PHP world (behave!) I like JavaScript being untyped/dynamically typed (whatever you prefer calling it). I understand that native statically typed languages might perform better. But I don’t like language fragmentation and I don’t understand why you would want to program in a different syntax or dialect if you’re „compiling“ to native JavaScript later on anyway (looking at you, TypeScript). IMHO there’s no advantage regarding the final compilation and you have to learn a new type of language in addition to creating tool overhead.

That doesn’t mean that I don’t see a need for type safety. It’s just that I’d like to keep using native JavaScript. That’s why I came up with Avocado.


Avocado is a small library and pattern guide to help you with type safety and data validation in native JavaScript. It is very very early in development, a prototypish state, a proof of concept. I post this so I’ll be able to find out if other developers share my mindset (see preface) and if it’s worth following this approach. I’ll accept if you tell me this is totally nuts too of course.
Avocado internally uses unified getters/setters and object factories to create a simple interface (interface not in the sense of OOP). Looking back how I came here, in my experience the underlying code might be a little hard to wrap your head around. But once you got it, this kind of programming leads to a more declarative style in an almost natural manner. Which I prefer.

Avocado gives you some tools to work with types, for example:

< 10

< Uncaught d is not an integer

< Uncaught d is not a number

Avocado allows you to create your own types.

var adultAge = function (i){
  return av(i, function (d){
    if ( >= 18) return d;
    else throw "not old enough!";

> adultAge(17)();
< Uncaught not old enough!

> adultAge(18)();
< 18

The real fun starts as soon as we combine this with objects;

var Person = function (i){
  return, {
    fullName: av.string,

Using this approach we can define requirements for objects and have them checked upon creation.

var gandalf = Person({
  fullName: "Gandalf the Grey",
  age: 2019

We get back an object with setters/getters for each property.

> gandalf.fullName();
< Gandalf the Grey

Each property uses its corresponding type validator.

> gandalf.fullName('Gandalf the White');
> gandalf.fullName();
< Gandalf the White

> gandalf();
< {name: "Gandalf the White", age: 2019}

How do you like that? Have a look at the github repository, to try it out yourself:

In my next post I’ll talk about on how to move on with this approach in regards to inheritance and nested objects (think Hobbits, Wizards, Orcs!).

Again, a reminder: This emerged as an experiment, a proof of concept, it’s far from really ready. So don’t be too harsh on the code and me :). I know it’s also a bit vague whether this is about type safety, static types or just type validation, I’d still love to hear your thoughts and where this could lead!

PS: If you like this, give it an upvote on Hacker News

15 Kommentare zu An opinionated approach to have type safety in native JavaScript.

15-cw12 — Dock me Amadeus

19. März 2015

Some much for regular blogging rebooted. Anyway, here’s a roundup of past findings.

Docker significantly changed the way I work. But it’s still a love-hate-relationship. I like how you define containers in a self-documenting, reproducable way. ATM it’s perfect for development. However, in production I still feel blind shooting and having nightmares in terms of security. I’m always afraid a wrong issued command might bust the host firewall through its fiddling with iptables (because it did more than once with different firewalls in the past). And while all major cloud providers are jumping on the docker ship, the software itself states that it’s still meant for development environments only. docker-compose (formerly known as fig) boldly states within its help screen: „Fast, isolated development environments using Docker.“. Maybe they should reconsider their versioning being above 1.0 already.

On the coding side, I’m still trying to make friends with the Java world. Slowly I’m feeling more welcome here (mainly thanks to

By the way, I like how Disqus is evolving. You might wanna follow me over there:

Keine Kommentare zu 15-cw12 — Dock me Amadeus

Climate Resilience Toolkit

17. November 2014

This year I joined webLyzard technology as a researcher. I’m excited to announce that we’re part of the team behind the newly released Climate Resilience Toolkit, a climate initiative launched by the US government. Our technology powers the website’s semantic search. I was responsible for internal visualization tools to assess the contents of the search API. Find out more about the project here:

Keine Kommentare zu Climate Resilience Toolkit


10. Juni 2014

A recent posting on Hacker News about A first-person engine in 265 lines in JavaScript reminded me of a „vintage“ developer book resting in one of me shelves: PC UNDERGROUND. The story of how I got my hands on it is at least somewhat noteworthy.


As far as I can remember, the book was quickly out of print. This was of course at a time before Ebay and „PDF-torrents“. I was eager to get the book but thought I was out of luck. One day I went to Kufstein to a computer related second hand store to sell of some stuff (among other things my „Fast Movie Machine“, don’t ask me what rid me to sell off that gem).

Thing was, that store was a weird mix of a porn video rental and a computer store. I swear I went there for the PC gear :). So there it was, standing in a shelf between the latest 90ies porn: PC UNDERGROUND. Guess it’s kind of sign that you’re a nerd if you go to a porn shop to buy a book about learning on how to program.


Keine Kommentare zu PC UNDERGROUND

McShark/McWorld vor Insolvenz. Aufregung um AWS Mittelstandsfonds.

5. Juni 2014


Mir ist nicht ganz klar, warum es jetzt der große Aufreger ist, dass AWS bei mcshark/mcworld beteiligt ist. Kann natürlich sein, dass ich selber falsch liege, aber ich glaube, die die jetzt aufschreien, haben nicht wirklich verstanden, wie der AWS wirklich funktioniert. Ich denke, die Angst, das die mcshark/mcworld Pleite auch den Steuerzahler trifft, ist unbegründet.

AWS ist eigentlich eine Bank, die u.a. Veranlagungen aus dem Marshall Plan reinvestiert. Banken „erfinden“ einen Großteils ihres Geldes, d.h. wenn Kredite nicht wieder einbringbar sind, juckt das eine Bank nur zu einem kleinen Bruchteil. Zudem ist Sinn und Zweck des AWS, Projekte mit hohem Risiko-Faktor zu unterstützen. Dass da auch mal etwas schiefgeht, ist kein Wunder, sonst gäb’s ja kein Risiko.

Man kann natürlich insgesamt der ganzen Sache rund um Subventionen, Förderungen etc. kritisch gegenüber stehen. Aber innerhalb des Systems „Förderlandschaft“ sehe ich jetzt nicht das Problem, warum AWS nicht in mcshark/mcworld aufgrund der Förderrichtlinien investieren hätte sollen.

Shark Image CC BY 2.0

Keine Kommentare zu McShark/McWorld vor Insolvenz. Aufregung um AWS Mittelstandsfonds.