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, react-etc.net 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.
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.
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 →
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 →
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 →
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 →
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 →
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.
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 →
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.