We’ve recently opened up the call for papers for the 2020 edition of PHP Yorkshire last year, I put a fair amount of effort into modifying OpenCFP to get it to run well on Google Kubernetes Engine, in this post I’m going to detail what was done to achieve this as it covers a lot of the steps you may need to take with your own applications to get them to run in a Docker/Kubernetes environment.

Recently, most of my spare development time has gone into building the set of tools I use to run PHP Yorkshire focused mostly on the ticketing system. This application is built using Zend framework, and the goal of the project was to provide a modular system which other conferences could pick and choose components of to use for themselves.

To this end, the main repository only contains a small amount of bootstrapping for the Zend application, the rest of the code is contained within modules pulled in as composer dependencies, this makes development of the modules themselves slightly awkward this post describes my new setup for making this work seamlessly.

One of the founding principals of event sourcing is that events are forever, they cannot change or be deleted. You need to keep the entirety of history so that you can derive business value from rebuilding projections or adding new ones to answer new questions or build new features.

In a post GDPR world, this comes into conflict with users being able to assert control over their personal data you are processing. User requests are not the only reason you may need to delete or modify events - a change in requirements may lead to drastic changes in your model and a need to rethink the events in your system.

In this post I’ll explore some of the ways you can manage these situations.