Blog

So in my day to day development i like to use continues deployment for every project where i can. Continues deployment means that everytime i push a commit to master the latest version of master will automatically be deployed to my production environment. This makes my development cycle way faster, and it makes sure that it don't have any basic problems, like handling untracked changes on the production. It just works.

Recently I was in the process of migrating a Magento webshop to a SaaS webshop solution. Normally I would access the product and other data by using the API. In this case this was a problem as there was a lot of data that I was not able to access. I needed the output of blocks and some custom modules which where not exposed to the API.

Coming up next week is MageTestFest. For the last ~2 years I have been doing a lot with testing and Magento, and I think this is awesome. In that spirit I decided to write this blogpost down.

Recently i was working on a Magento 2 webshop. It had a bug that when you visited the order grid you would get an exception. It was very generic, from the exception trace i was not possible to find the source. When i had a similar problems in Magento 1 the first step i would do was disable all non-Magento modules. This was simple, just move the xml files of the module you wanted disabled out of the app/etc/modules directory and you're done.

In Laravel you can set your environment specific variables by using the .env file. In the application you can then easily retrieve the variable by using the env('VARIABLE_NAME') function. This file is not be meant to be added to git. This way you can a secret values in your project without accidentally add them to git and sharing them.

This week i attended the European version of Laracon. It was a lot of fun and i talked to a lot of friends. There where a lot of great talks.

Deploying an application can be hard. The new code must be pulled in, permissions must be set, migrations must be run, etc. In some cases the whole website goes down while deploying a new version. And the more that must be done manual, the more can, and eventually, will go wrong.

Since a few years everyone seems to be using Laravel for about everything. That is completely understandable, as it provides some great features. The only downside is that when there is a (security) bug this is easily exploited.

A few weeks back it was my birthday. I never now what to ask that is cheap enough for most people. But this time i thought of the Raspberry PI Zero W.

Composer is a revolution in the PHP world. You can use it to manage your dependencies, but it can be slow on big projects.