React gets Context & Suspense. Quo vadis, Redux?

Disclaimer: this article targets developers that are using Redux with React. If you are using Redux with another Framework, this article might not be important for you.

Last thursday, Dan Abramov gave a talk on JSConf Iceland called „Beyond React 16“. A few hours later, featured an article titled RIP Redux: Dan Abramov announces future fetcher API. While I agree with almost nothing that article has to say about Redux, the article got one thing right: Somewhere between 6 or 12 months from now, the way we are using Redux (at least when starting a new project) will be drastically different from the way we are using it today.

But before we take a gaze into the crystal ball, let’s take a step back and see what happened.


Of races and mutexes: synchronizing async operations in JavaScript

While JavaScript is a strictly single-threaded language, the asynchronous nature of its execution model can easily lead to situations in which two or more async operations run at the same time and compete with the program flow depending on which operation succeeds first. The result is a specimen of the dreaded species of race conditions.

Issues of this type can be arbitrarily hard to reproduce, debug and fix, and I guess that every seasoned JavaScript developer can relate one or two horror stories where they literally spent days before finally fixing such an issue for good.

Race conditions are a well-known problem from any language that supports for concurrency, and often a mutex is used as a tool to synchronize such operations. This article shows how to apply the concept of mutexes to JavaScript in order to avoid race conditions.


Travel Your Project

As a traveler and project guy, I often noticed that these two important things in my life have a lot in common. Things that happen while I’m on the road are similar to situations I observe in my daily project business. When I struggle in a new or existing project I often think about similar situations I had on journeys with my backpack.

9 Tips How Travel Experience Will Improve Your Project Skills

Traveling people are described to gain skills abroad that help them in their everyday life. Not only in everyday life, but also in projects or working environment. So „traveling your project“ could be a legit approach in dealing with certain situations. Some of the skills I think to be helpful are collected in this article.


From Vagrant to NixOps

I have been following the development of NixOps for some months. NixOps is a cloud deployment tool using nix, the functional package manager for unix systems. Nix makes it very intuitive to define absolute package dependencies. No more thinking and guessing about required runtime dependencies.
NixOps supports deploying to different platforms. Bare-metal, cloud, and even virtual environments like virtualbox work out of the box. I have worked in many projects using vagrant. Out of curiosity I migrated an existing vagrant project using wasted (Web Application STack for Extreme Development) to nix and NixOps.
This post is a walkthrough to configure a symfony2 project with nginx, mysql, and php-fpm from scratch. Weiterlesen

mobile dev hint #2 – Use Browsersync for mobile testing

While testing mobile websites on different devices and browsers, testing time grows exponentially. You need to duplicate click-through movements on all the devices, fill out forms many times and do all the user interaction for too many times. This is where Browsersync starts, it cuts out all the repetitive manual tasks. You can mirror all interactions on your testing devices and you  can integrate Browsersync in your web platform and build tools easily. The CLI usage is simple and developer friendly and the great UI can help the testers to interact with the software live during the testing. Weiterlesen

mobile dev hint #1 – Remote Debugging Websites on iOS Devices

When it comes to mobile testing, we need to talk about testing on real devices. What seems to be an easy task for the tester, could be hard when you try to debug device specific errors on the device itself.

This short guide will help you with the setup of the remote debugging with the Safari Developer Tools. It is easy as counting to three, but you need to find the right settings. Weiterlesen

Hardening Compiler Flags for NixOS

In the past year some Mayflower colleagues have started using and contributing to NixOS, a purely functional GNU/Linux distribution that combines package and configuration management. We decided that we would give it a try in production but stumbled upon some issues that had to be resolved first. We have added new packages, services and fixed up some internal. Due to this work two colleagues have even gained commit access in the process. Weiterlesen

Do you know the difference between continuous integration, continuous delivery and continuous deployment?

Probably every common agile developer has heard these terms. But have you ever thought about the difference between them. I have really been wondering about this question and after some investigation I would like to share all information on this topic i have gathered.

To be able to understand continuous deployment it can be helpful to define its predecessors first – continuous integration and continuous delivery. Continuous integration (CI) usually refers to integrating, building and testing code within an integration environment. It assumes frequent integration of developers code into a shared repository, at least once a day. This makes sure that the local version of every individual developer doesn’t differ too much. Weiterlesen

Running a secure docker registry

Some time ago, our team decided to deploy the application which we are developing for our customer as a docker container. As docker is a promising but still very young technology, this decision naturally put us on a quest for finding a reliable, secure and maintainable setup — many things are still in flux in the community, and the resulting lack of proven best practices leaves a lot of room for experiments (sometimes frustratingly so).

In this blogpost, I want to share one result of our experiences: how to set up and maintain a secure private docker registry.


Domain-specific languages for fixture generation – a case study with Antlr4

A domain-specific language (DSL) is a programming language or descriptive file format to formulate and solve specific problems in specific domains, as opposed to generic descriptive file formats (such as XML) and general-purpose programming languages (such as Java) which can be employed in any domain.

A paradigmatic use case for a domain specific programming language is domain-specific computations, e.g. physical simulations, which can be simplified and optimized by using a language containing the required and only the required mathematical and physical expressions. At a project at Mayflower, we recently encountered a use case for employing a DSL as a descriptive file format: we designed a DSL describing document models to generate database fixtures from it. Weiterlesen