Stephan Hochdörfer

Recently we hit a problem in our Force Login Magento 2 module: The module was not compatible anymore with Magento 2.1 due to a change in a constructor of a Magento base class we extended. This broke the DI configuration which in turn meant the module was not installable in a Magento 2.1 project any more. We were not able to spot this problem early on as our Travis build did only run against the latest Magento version 2.2. Inspired by this blog post of the heidelpay developers, I began to restructure our Travis build.

Yesterday, we released version 3.0 of our Force Login Module for Magento 2 which brings some requested features and fixes, here are the highlights of the current release:

While working on this prooph components powered API, I realized it would make sense for our mobile client to know when data changed on the server-side without constantly pulling all data from the API and comparing it locally. In a "traditional" application I would have used a checksum mechanism - e.g. creating a checksum of all the data in the datastore - but with an event sourced application this is no longer needed as we can simply rely on the timestamp of the last event happened to know if things have changed.

A while I ago I covered the upsert feature PostgreSQL introduced with version 9.5. Back then I showed you how to make use of upsert with one field - the primary key - as conflict target. In a recent attempt to modify the upsert logic to take 2 fields into account I tried to add the additional field to the conflict target:

As it seems there is no out-of-the-box way in Sencha ExtJS to provide a configuration based on the build environment (development, testing or production) to your application. Since you need at least different urls for your proxys, it makes sense to have a mechanism in place that would generate the respective configuration for you. This is our solution for the problem.

Linking Docker containers can be done in various ways. In my recent attempt of playing with Docker and our GitLab Review Apps setup, I experimented with different methods to figure out what would work best. These are the different options I played around with:

When we made the move to GitLab 1,5 years ago, it was clear to me that we would need some automation to simplify the creation of groups and projects and to sync the LDAP group memberships to the matching GitLab groups. I did a quick search on Packagist for GitLab client libraries and found the m4tthumphrey/php-gitlab-api package.

I wasn't really happy with the current approaches of dealing with different Dockerfiles and docker-compose.yaml files for development and production containers. I don't really see the point of managing multiple configuration files, building a few intermediate containers when the only difference between a development image and a production image is that the code is copied into the image during build. Adding files on every build is also not an ideal solution as you could potentially ship an old version of the application when you miss running a docker build after you made your final changes.

In my recent talk on introducing Disco - the DI container with the damn coolest name(tm) - I talk about why I believe that using XML or any other non-code configuration (YAML, JSON, ...) is not a good idea. This stirred some twitter discussion recently which led to this blog post.

In a recent attempt to automate a few things even more, I was looking for a way to post messages to our Mattermost instance via the Incoming Webhook feature of Mattermost. I did a quick search on Packagist for Mattermost client libraries and as it turns out there a quite a few. I picked the thibaud-dauce/mattermost-php package simply because it was the first match ;)