Blog

For my daily work as a freelancer i tend to use a lot of disposable environments: I use them to check a bug in that specific version for example, and them throw them away. Setting up Magento can be a lengthy process, but with this one liner i can bring it down to ~10 minutes, depending on you internet & cpu speed. It installs the required Magento version including sample data.

I've been using Sequel Pro for a few years for all my database needs. But lately my relation with Sequel Pro got troubled. This is due to a nasty bug in the latest version: If you close a tab, the program crashes. You can download a nightly build, but i still had weird problems.

In my day to day life i tend to switch between Magento, Laravel and Symfony on a regular basis. Each system has it's pros and cons, but Magento has one pro over the other two: If you are using Magerun you can run console commands from any directory inside your project. It always bugged me that there isn't such a thing for Laravel, Symfony or other frameworks. That's why i created Shorty

When people share their workflow/tools i love to read them as it gives me the option to improve mine. I think i currently have a pretty decent workflow which allows me to develop faster than ever. I wanted to share this flow with you so everyone can use it.

I always forget how to redirect a domain from http -> https when i'm in Direct Admin.

In 2015 i started my company, Control Alt Delete. As a developer, i was always building websites for friends and family. As this started to get out of hand, i decided to make it official and start a company. I did this next to my fulltime job, but eventually started doing this for 2 days a week, and in 2018, i decided to go fulltime.

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.