Contract testing with GraphQL

Contract tests (or Consumer-driven contract testing ) “are an essential part of a mature microservice testing portfolio, enabling independent service deployments” ( The basic idea is that a Service X (the Consumer) using Service Y (the Provider) can only be deployed if Service Y upholds the contract between X and Y (the same is true for the Provider: it can only be deployed if it is still compatible with all Consumers).

jsunconf 2016 talk

The slides for my talk “Evolution of a webapp” or “What to do with Angular 1?”: Slides as pfd

angular2 relay talk

Together with Sebastian I gave a talk at NG-NL about how to use Angular 2 and Relay. A writeup can be found here and the slides are availabe here.

why relay matters talk

Slides for my talk at the Berlin React Meetup on 25.01.2016: Pdf Links to topics mentioned in the talk: Relay GraphQL Relay-Core without React and generic-relay Deferred Fragments Subscriptions in graphql and the official blog post React Native support Support for in-memory and device data Isomorphic-Relay My talk about GraphQL/Relay and Faclor GraphiQL project, as standalone app and as Chrome Plugin React Higher Order Components Explaining Relay as a cartoon

Time zones for Developers

I spend more time than I ever wanted over the last decade dealing with time zone related problems. Most of them were caused by bugs introduced by developers (including myself) who didn’t know enough about it. This post is here to help with that: It’s not a complete coverage of time zones or an introduction. It’s based on my experience what the most common mistakes are and what is least understood.

graphql falcor talk

The slides for my talk about GraphQL and Falcor, which I gave at the berlinjs Meetup at 19.11.2015:

Software architecture: Real challenge, bad term

Software architecture is probably the strangest term in software development. No term is so widely used and the same time so vague defined. No term is so widely abused and at the same time so important to software development. A short history Since around 1968 people tried to fix software development through trying a more engineering like process for development. To make it short: It was a failure. One major influence for this “Software engineering” discipline was “Civil engineering”.

Emacs quick tip: No file tree pollution

This is just a quick tip for Emacs beginners. I didn’t find these informations in one place, so it might be useful for somebody: If not configured otherwise Emacs will create three different special files when editing a file: Backup Files: The file name is appended with a tilde ~. Auto Save Files: The file name is prepended and appended with #. Lock Files: The file name is prepended with .

Flux Architecture distilled (and a bit about AngularJS)

After watching the Flux Intro Video, reading about Flux and additionally reading some blog posts about AngularJS and Flux (e.g. #1 and #2) I had the feeling that the fundemantal ideas behind Flux are not very well presented and as a consequence not very well understood. (See also this infoq article.) So I will try to grap the essence of Flux (as I understand it): (I will focus on the Facebook Flux implementation https://github.

I am not a software engineer

Since around 1968 (the “software crisis”) people tried to fix software development through trying a more engineering like process for development. But it wasn’t very successful, projects still didn’t went by plan, failing to met budgets or timelines. And doing more planning and applying more engineering methods made it not better. As it turned out engineering is not a useful model for software development, I would even call it harmful.