For a few projects we make use of the Event Engine by prooph software which is a biased - in a good way(tm) - way of quickly building event sourced applications. While building a user registration context, I was stuck a bit how and where to properly hash the password for the user. I could have done it in the init() method of the command, that way I would have made sure that the cleartext password is not "visible" anywhere in the application code. In the end, I decided to make use of a provider class. The return value of the provider will be passed to the specified aggregate method and allows me to pass it to the respective event.
In a recent project, we make use of the Event Engine which is an Event Sourcing framework for PHP helping you to rapidly develop event sourced applications. Since parts of the exposed API by the Event Engine should be access proteced, we decided to use OAuth2 for access delegation. That way each route exposed by the Event engine application can be marked as "protected" if needed.
A few days ago Jordi announced the first dev build of Composer 2.0. I immediately went and downloaded it. Since version 2.x should be a lot faster, I thought it is a good idea to test it against a current Magento 2 project I am working on. I was a bit disappointed first because Composer failed with quite a few errors like that:
On the 24th and the 25th of January 2020 I was able to go to the PHPBenelux Conference in Antwerpen. It is a community-driven technology conference. As the name implies it is mostly about PHP and related topics. It was the first conference I visited besides our very own unconference at bitExpert. Therefore I was very excited and did not know at all what to expect.
These days we get more and more in situations where we have to push our code into Git repositories of our customers, either because the customer wants access to the source code or because we are working closely with their in-house team. Maintaining our own local copy of the source code and constantly keeping our copy in sync is a no brainer with Git.
Back at MageTestFest in Florence, I introduced the audience to a tool called Captain Hook for managing Git hooks. In the QA section of my talk, the question was raised why I have not recommended to use GrumPHP. A valid question since all the QA tools I talked about are already supported by GrumPHP out-of-the-box.