The merge sort algorithm is a common example of the divide-and-conquer approach to algorithm design. This approach usually boils down to three steps: divide the problem into subproblems with are of the same type as the original problem, conquer the subproblems solving them via recursion, and combine the solutions of the subproblems into a solution for the problem we started with. In this context, the merge algorithm first divides an array into smaller arrays, sorts each of those arrays using merge sort (i.

This algorithm is exactly what you expect it to be: at every iteration, the elements of the array are randomized and we check if it is sorted. If not, we keep on trying and hoping. Obviously, this algorithm’s worst case scenario time complexity is technically unbounded, meaning that there is a chance that we never land on the sorted array. Conversely, in best case scenario, where our first shuffle yields the sorted array, we have a time complexity of $O(n)$.

This is fairly straightforward and inefficient way of sorting an array, but it is also a very easy to implement algorithm and is usually used when teaching the basics of sorting to new students. The intuition is also simple: you start by comparing the two last elements with each other. If the last is smaller than the one that precedes it, we swap them, so that the last element is the largest.

This sorting algorithm works very much like sorting a hand of playing cards. You start by evaluating the second leftmost card in your hand and you compare it to the one on its left. If it has a smaller value than it, then you swap them. If not, you do nothing and move on to the third card. If its value is smaller than the second card, you then also have to look at the first card because it can be even smaller.

Life update It has been a long time since I have posted an update on this project. I fully intended to pick it back up but I’ve been very busy interviewing and, as a consequence of doing somewhat well in the interview process, I’ve also been busy moving to Ireland, where I’ve joined Stripe as a Software Engineer. So why am I not picking the project back up in the near future?

I’ve already covered recreate deployments and canary deployments, so now it’s time for yet another deployment strategy, the blue/green deployment, which is a very common approach to deploying containerized software, for example. Other posts in this series Recreate/in-place deployment Canary deployment Blue/green deployment Blue/green deployment Blue/green deployment hinges on a simple concept, that you should ensure that your application is running and healthy before routing any real traffic to it. In practice, it happens as follows.