How I am almost always able to answer fast to anyone asking me to decide.

Note: this blog post was written as part of my mission as a PrestaShop maintainer

Following previous post about Minor Release Lifecycle, here is more explanations about software lifecycle at PrestaShop, focusing on patch releases and the release process.

Note: this blog post was written as part of my mission as a PrestaShop maintainer

The journey of the release of PrestaShop 1.7.7.0 has started. This moment is a nice opportunity to explain PrestaShop’s minor release lifecycle.

This blog post is intended to help people willing to understand better the process to contribute to a github opensource project for the 1st time. It does not explain “how” to use the github fork workflow but rather “why” it is used and why it seems so complex the 1st time you look at it.

“If one day, I launch my startup, I will use language X instead of the crappy stack I have in my current job”.

I have heard this one more than once. And today I would like to discuss some items that I think should be considered when answering this question (“what stack should I choose for this greenfield project ?”), instead of only focusing on one’s favorite language.

Note: this blog post was written as part of my mission as a PrestaShop maintainer

The PrestaShop project currently (September 2019) has 389 pull requests open and new Pull Requests are opened almost everyday. All of these pull requests go through a thorough process which aims to provide a stable, consistent and reliable software that we all know under the name PrestaShop. Here is this process in details.

Nowadays, most (smart) companies know that they should avoid vendor lock-in. However I still see a lot of companies allowing dev lock-in to settle in although it is almost as bad as vendor lock-in.

Sometimes, I like to think of we developers as surgeons. I guess you heard before “developers are like writers”, “developers are like gardeners”, “developers are like artists” … did you know “developers are like surgeons” ? Here is why I like this metaphor…

I wanted to share cool tool combinations tricks I have learned this year. This post will show you how you can combine some tools together in order to build an API documentation, an API Client and some API integration tests.

Recently I have been practicing a development strategy that proved quite efficient. I call this “basic code is easy to maintain”. The contrary also works: “complex code is hard to maintain”.