---
title: Navigating Deadlock Challenges in Real-World Scenarios
summary: Deadlock problems in software often occur when two processes are trying to write into one resource at the same time, causing both to fail. This can be likened to two buyers trying to purchase the last product at the same time, both failing because they try to update the product data simultaneously.
tags: ["concurrency", "golang", "deadlock"]
date: 2024-05-15
cover: deadlock-concurrency.png
---

Deadlock problems in software often occur when two processes are trying to write into one resource at the same time, causing both to fail. This can be likened to two buyers trying to purchase the last product at the same time, both failing because they try to update the product data simultaneously.

One of the best ways to explain deadlocks is through the Five Philosophers Problem.

## The Five Philosophers Problem

Imagine five philosophers seated around a circular table. Each has a plate of noodles and a chopstick on both sides of their plate. The complication arises when they all try to eat at once, each needing both chopsticks to eat.

### Scenario Explanation

- **Setup:** Five philosophers sitting at a round table, each with a chopstick on either side.
- **Eating Process:** To eat, a philosopher must pick up both the left and right chopsticks.

Consider the following image for clarity:

*Five philosophers sitting at a round table with a chopstick on each side of their plate. If each philosopher picks up their left chopstick, they all hold one chopstick and wait indefinitely for the right one, resulting in deadlock.*

*Deadlock happened since everyone picked up a chopstick and waited for each other.*

## Implementing the Solution in Go

### Basic Eating Simulation

First, let's write a simple program to simulate the philosophers eating.

```go
package main

import "fmt"

type philosophers []string

func main() {
    philosophers := philosophers{"Aristotle", "Plato", "Socrates", "Descartes", "Kant"}

    for _, p := range philosophers {
        fmt.Printf("%s is eating\n", p)
    }

    fmt.Println("All philosophers are done eating")
}

*Output:*

```console
Aristotle is eating
Plato is eating
Socrates is eating
Descartes is eating
Kant is eating
```

### Introducing Chopsticks

Now, we introduce chopsticks, so each philosopher picks up the chopsticks before eating.

```go
type chopstick []int

func main() {
    chops := chopstick{0, 1, 2, 3, 4}
    philosophers := philosophers{"Aristotle", "Plato", "Socrates", "Descartes", "Kant"}

    for i, p := range philosophers {
        leftChop, rightChop := chops[i], chops[(i%4)+1]
        fmt.Printf("%s picked up chop %d \n", p, chops[leftChop])
        fmt.Printf("%s picked up chop %d \n", p, chops[rightChop])
        fmt.Printf("%s is eating \n", p)
    }

    fmt.Println("All philosophers are done eating")
}

```

*Output:*

```console
Aristotle picked up chop 0 
Aristotle picked up chop 1 
Aristotle is eating 
Plato picked up chop 1 
Plato picked up chop 2 
...
```

### Preventing Deadlock with Mutex

Next, we need to introduce a locking mechanism to prevent a chopstick from being used by two philosophers at the same time.    

The red connections to the chopsticks mean that the chopstick is locked and the therapist needs to wait for it to be available.     

To prevent deadlock, we use a locking mechanism. Each chopstick will be protected by a Mutex. I explained how mutex work in this article posted on my blog.

```go 
package main

import (
    "fmt"
    "sync"
    "time"
)

type Chop struct {
    sync.Mutex
}

type Philosopher struct {
    name     string
    eatCount int
}

func (p *Philosopher) Eat(leftChop, rightChop *Chop) {
    leftChop.Lock()
    rightChop.Lock()
    fmt.Println(p.name, "is eating")
    time.Sleep(time.Second)
    leftChop.Unlock()
    rightChop.Unlock()
}

func main() {
    var wg sync.WaitGroup
    chops := make([]*Chop, 5)
    for i := 0; i < 5; i++ {
        chops[i] = new(Chop)
    }

    philosophers := []Philosopher{
        {"Aristotle", 0},
        {"Plato", 0},
        {"Socrates", 0},
        {"Descartes", 0},
        {"Kant", 0},
    }

    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            philosophers[i].Eat(chops[i], chops[(i+1)%5])
        }(i)
    }

    wg.Wait()
    fmt.Println("All philosophers are done eating")
}
```

In the code above, we execute 5 goroutines for each philosopher to eat, and each of them waits for the other chopstick to be free in order to eat.     

But since we go in order 1…5, there won’t be a deadlock because they are just waiting until it’s their turn.

*Output:*

```console
Kant is eating
Plato is eating
Aristotle is eating
Descartes is eating
Socrates is eating
All philosophers are done eating
```

### Running Goroutines Indefinitely

In the following code, we will add an infinite loop that will just run goroutines in order, and each loop will wait until the previous 5 goroutines are done.

```go
func main() {
    var wg sync.WaitGroup
    chops := make([]*Chop, 5)
    for i := 0; i < 5; i++ {
        chops[i] = new(Chop)
    }

    philosophers := []Philosopher{
        {"Aristotle", 0},
        {"Plato", 0},
        {"Socrates", 0},
        {"Descartes", 0},
        {"Kant", 0},
    }

    for {
        for i := 0; i < 5; i++ {
            wg.Add(1)
            go func(i int) {
                defer wg.Done()
                philosophers[i].Eat(chops[i], chops[(i+1)%5])
            }(i)
        }
        wg.Wait()
    }
}
```

*Output:*

```console
...
Kant is eating
Plato is eating
Descartes is eating
Aristotle is eating
Socrates is eating
Plato is eating
Aristotle is eating
Kant is eating
Descartes is eating
...
```

This will give you a simple visualization of how the philosophers are going to eat and how they won't be able to eat if the adjacent one is eating.

## Conclusion

While this solution reduces the likelihood of deadlocks, it is not entirely foolproof.    

Go's concurrency model and goroutine scheduling help manage execution order, making deadlocks less common. Avoiding deadlocks in Go is easier thanks to its built-in tools and mechanisms.    

Deadlocks are a frequent problem in software, especially when working with microservices and multiple storage instances for data read/write operations. As you scale your project horizontally—running multiple instances—the chances of encountering deadlocks increase.      

Understanding and implementing proper concurrency control is crucial to mitigating these risks.

Deadlock problems in software often occur when two processes are trying to write into one resource at the same time, causing both to fail. This can be likened to two buyers trying to purchase the last product at the same time, both failing because they try to update the product data simultaneously.

Navigating Deadlock Challenges in Real-World Scenarios

---
title: Change your perspective on code review
summary: What is code review and how to adapt your team to it, how to approach a code review, what to look for and how other big companies do it.
tags: ["code review", "learning", "developer"]
date: 2023-08-20
cover: programming_cover.jpg
---


# What is code review?

Code review is a process where an author submits their work to be reviewed by other developers and vice versa.
This process is used to ensure that the code is of high quality and it follows the standards set by the team.   
Besides helping to keep a high-quality codebase and having clean code organization,
it also helps with something more important, which is **learning** and knowledge sharing.

I have worked on different teams and I have seen places where there are no Code Review processes, at other times developers use Code Review as a way to prove that they are right and the other person is wrong.
Later in the article, we will see which approach is the best that big companies developers do it. 


> If there is no harmony in the team, no good result will come from it.

# Real-world scenario

There are 8 steps in a code review process that developers go through in companies before it gets to production, these steps differ from company to company but most of them are as follows.  

1. The author submits the code for review
2. The reviewer reviews the code
3. The reviewer gives feedback
4. The author makes the changes
5. The reviewer approves the changes
6. The code is merged into the main branch
7. The changes are deployed into staging or pre-production for testing.
8. The changes are deployed to production

Some companies do it that at least two people review the new Pull Request before accepting it.
Others do it by randomly selecting team members.
Bigger companies did put more effort into this and they build AI tools that decides who can review the code for your Pull Request.

# How to approach a code review

The majority of the developers are used to reading PRs from top to bottom because that's how we read everything, some try to do it from bottom to top, but neither worked for me.
After reading about how other companies do it, I found out that identifying the most important part of the PR first is the best way to go.   
The best approach is to look with a Broad overview, then find out the Important parts, then focus on details.     


## 1. Broad overview

Although to identify the important part most of the time you need to know the project, but for small projects should be more straightforward.  
While scanning for the changes and identifying the more important parts, there are many tools that help you mark them or collapse them so you can focus on the important parts.


## 2. The important part

Once you have a good idea of what is being changed you should focus on the important parts of the code.
Here you take your time to check if everything is correct by focusing on the business logic and requirements and not the details.
This is the difference from the details part, here you should not focus on the code quality, but on the business logic and requirements.


## 3. Details

While you made sure that the important parts are correct, you can now focus on the details.
This is the part where you should check if the code is well organized if the code is easy to read and understand, if the code is following the standards of the team, and if the code is well documented.
Make sure the tests are covering the new code, and that the tests are easy to understand and maintain.
Make sure that the code is improving the codebase quality and not making it worse.

# The checklist

I will write a checklist that you can use to go through a PR and make sure that you are not missing anything.  
```
# Broad overview
[] Identify the important parts

# The important part
[] Are the requirements implemented correctly?
[] Is the business logic correct?
[] Is there any edge case that is not covered?
[] Are the tests covering the new code?

# Details
[] Is the code well organized? 
[] Is the code easy to read and understand?
[] Is the code following the standards of the team?
[] Is the documentation updated?
[] Are the tests easy to understand and maintain?
[] Is the code improving the codebase quality and not making it worse?
[] Do the names make sense?
```

# Automating the process

Automating the Code Review process is also something that helps you with the **Checklist** above, for example if you look for tools that do static analysis of your code, bug finders, etc.
Then you can configure and set up in a way which your team has agreed upon.

Checkout this [Github Repot](https://github.com/exakat/php-static-analysis-tools) to see a thorough list of tools you can use for PHP projects.
After implementing tools like above you will end up having a very simple checklist where it lets you focus only on the important parts.

```
# Broad overview
[] Identify the important parts

# The important part
[] Are the requirements implemented correctly?
[] Is the business logic correct?
[] Is there any edge case that is not covered?

# Details
[] Is the documentation explained well?
[] Are the tests easy to understand and maintain?
[] Do the names make sense?
```


# Commenting on a PR

Before giving feedback you should make sure that you understand the code, and that you have a good idea of what is being changed, but most importantly be curious about why the author made the changes.
When giving feedback you need to be polite and respectful, keep in mind that the author of the code is a human and your teammate.
Also, be clear and specific, and try to explain why you are suggesting the changes, be open to feedback as well, and you should be willing to discuss the changes.



# Changing the team's perspective

This is important that if you trying to do a change in the team, you need to be on the same level as the team, you need to understand how they feel about the topic, and what they know about it.    
By making sure everyone is on the same page and is on the same level, then you try to build a plan together.

### Checklist

```
[] Gather feedback from the team.
[] Make a detailed plan.
[] Present the plan to the team and ask for feedback.
[] Keep track of the team following the plan.
```

Below you will find a list of resources where you can also read more in detail about code review processes on how they affect the team speed and team morale.     

Consider this as an orientation and not a goal, because there is always room for improvement.     



**TIP:** [Google has found](https://google.github.io/eng-practices/review/reviewer/speed.html#responses) that it's very important for the individual responses to come quickly than it is for the whole process to happen rapidly, so instead of keeping the author waiting to write a comment when you will review it.

**TIP:** When creating a Pull-request, that is fixing a bug or adding a feature, don't make a lot of refactoring on top of that PR.
1. It delays the changes that might be urgent to deploy.
2. It adds more pressure on the reviewer and harder to review.
3. This should not stop you from doing refactoring changes, just add them on a different Pull-request.
> When adding a feature just add the feature and nothing out of that context. - <br/> The smaller the better.

# References 

- [Google Engineering Practices Documentation](https://google.github.io/eng-practices/review/reviewer/)
- [Meta Engineering on Improoving Code Review](https://engineering.fb.com/2022/11/16/culture/meta-code-review-time-improving/)
- [Github on Code Review]()
- [Microsoft on Code Review](https://microsoft.github.io/code-with-engineering-playbook/code-reviews/inclusion-in-code-review/)
- [Code review tools](https://blog.jetbrains.com/space/2021/12/15/best-code-review-tools/)



What is code review and how to adapt your team to it, how to approach a code review, what to look for and how other big companies do it.

Change your perspective on code review

---
title: Step-by-step Guide to Deploy Your PHP API on Google Cloud using Kubernetes and Docker
summary: Learn how to deploy your API using Kubernetes and Google Cloud, using free tier services you will be able to deploy your own code in a instance.
date: 2023-05-13
tags: [google-cloud, kubernetes, api, php, symfony, docker]
cover: kubernetes_cover.png
---

# Introduction

In this article, you will learn how to deploy a PHP API on Google Cloud using Kubernetes and Docker. You will learn how to:

* Containerize your application in a Docker image
* Create a basic Kubernetes configuration for your API
* Deploy your Kubernetes configuration to Google Cloud
* Expose your API to the internet


Before we start you need to have some things ready if you are planning to deploy your own API into Google Cloud.

1. Have a [Google Cloud account](https://console.cloud.google.com/), which you can have it as free trial.
2. Have an account on [Docker Hub](https://hub.docker.com/) where you are going to push your image into.
3. Have your API ready or just create a simple `index.php` file with a `Hello World` message,    
or use symfony skeleton by running `composer create-project symfony/skeleton simple_api`


**Optional**  

4. Have [Docker installed](https://docs.docker.com/get-docker/) in your machine.   
5. Have [kubernetes cli](https://www.docker.com/products/kubernetes/) installed in your machine, this is only if you want to try your configuration locally.

# Step 1: Containerize your application
In this step we will prepare a docker image with our code, which we will later use to deploy our API.    

Create a `Dockerfile` in the root of your project, and add the following content.

```yaml
FROM composer:latest as composer

WORKDIR /app
COPY . /app

RUN composer install

FROM php:8.2-fpm-alpine

WORKDIR /var/www/html
COPY --from=composer /app /var/www/html
```

Amazing! Let's build our docker file.
```bash
docker build -t username/simple-api:1.0.0 .
```
Next, we login into docker by running 
```bash
docker login
```
We push our built image into docker hub by running 
```bash
docker push username/simple-api:1.0.0
```


# Step 2: Create a Kubernetes configuration

The next image is trying to give you an overview of how kubernetes will communicate with different components.    
![Kubernetes cluster](/image/articles/kubernetes_overview.jpg)

The current project structure that I am using looks like the following, its a simple symfony API project.

```txt
├── composer.json
├── config
├── public
│   └── index.php
├── src
│   ├── Controller
│   └── Kernel.php
```

And for kubernetes I have the following files, which are the ones that I will explain in the next section.
```txt
├── nginx_configMap.yaml
├── nginx_deployment.yaml
├── php_deployment.yaml
├── php_service.yaml
└── projectStorage.yaml
```

![Kubernetes_components](/image/articles/kubernetes_components.jpg)

This is [the link to the github repo](https://github.com/didslm/kubernetes-template) containing the files,
this is a basic configuration of a kubernetes cluster with a php and nginx deployment.


## ConfigMap 

**ConfigMap** is a kubernetes object that allows you to store non-confidential data in key-value pairs, 
and in my case it will be used to store the nginx configuration file.   
You need to keep in mind that names and labels are important in kubernetes, 
you always refer to them in other files. [See file](https://github.com/didslm/kubernetes-template/blob/main/nginx_configMap.yaml)

## Deployment 

**Deployment** is a kubernetes object that allows you to deploy your application,
in my case I have two deployments, one for nginx and one for php.
They will be deployed in different pods, and they will be able to communicate with each other.   
[See PHP Deployment file](https://github.com/didslm/kubernetes-template/blob/main/php_deployment.yaml) and 
[See Nginx Deployment file](https://github.com/didslm/kubernetes-template/blob/main/nginx_deployment.yaml).   

Here is a part of `php_deployment` file, where I am using an initContainer to copy my code into a volume,
and then I am mounting that volume into my php container.

```yaml
# ...
spec:
  replicas: 1
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        app: php
        tier: backend
    spec:
      initContainers:
        - name: copy-project-files
          image: diarselimi/php-sample-api:1.0.6
          command: ["/bin/sh", "-c"]
          args:
            - cp -R /var/www/html /mnt
          volumeMounts:
            - name: tvc
              mountPath: /mnt
      containers:
        - name: php
          image: diarselimi/php-sample-api:1.0.6
          command: ["/bin/sh", "-c"]
          args:
            - chmod -R 777 /var/www/html/var
          ports:
            - containerPort: 9000
          volumeMounts:
            - name: tvc
              mountPath: /var/www
      volumes:
        - name: tvc
          persistentVolumeClaim:
            claimName: project-storage
```

## Service

**Service** is a kubernetes object that allows you to expose your application to the internet,
in my case I have one service for PHP and for exposing it to the internet I am using the command that you will see at the end of this article.   
[See PHP Service file](https://github.com/didslm/kubernetes-template/blob/main/manifest/php_services.yaml).

## Volume

**Volume** is a kubernetes object that allows you to store data in a persistent way,
in my case I have one volume for PHP and inside of PHP deployment I am mounting it to the `/var/www/html` directory.   
[See Volume file](https://github.com/didslm/kubernetes-template/blob/main/manifest/sample-volume.yaml).

Last step is to add the new image to our `php_deployment.yaml` file, by changing the line 
```diff
- image: <your-docker-hub-username>/<your-image-name>:<tag>
+ image: username/simple-api:1.0.0
```

This line is the one containing our codebase, so we need to add this to our kubernetes.


# Step 3: Deploy your Kubernetes configuration to Google Cloud

In this step we will setup our Google Cloud account, 
we will create a cluster and upload our kubernetes files in the cluster.   
Here is a short video for on google cloud platform.   

<Youtube src={"https://www.youtube.com/embed/zvM7VbNezzg"} />

After uploading my kubernetes configurations into google cloud platform, you will be able to run the following commands.

1. Apply the configurations by running 
```bash
kubectl apply -f .
```

2. You need to wait when the pods are both running, you can check that by running
```bash
kubectl get pods
```

3. Expose your external IP address so that it is accessible from everyone.
```bash
kubectl expose deployment nginx-deployment --type=LoadBalancer --port=80
``` 

4. You can get your external IP address by running
```bash
kubectl get svc
```

```bash
NAME          TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)        AGE
kubernetes    ClusterIP      10.51.128.1     <none>         443/TCP        3d19h
nginx         LoadBalancer   10.51.130.146   34.75.23.208   80:31852/TCP   27h
php-service   ClusterIP      10.51.131.237   <none>         9000/TCP       29h
```

# Cleaning up 

If you want to stop and clean up your cluster so that it doesn't spend your credits, first you need to delete your uploaded config files.
```bash
rm nginx_configMap.yaml nginx_deployment.yaml php_deployment.yaml php_services.yaml sample-volume.yaml
```
then you need to run the following command to stop everything
```bash 
kubectl delete pvc,pv,deployment,pods,configmap --all 
```
You can also delete the cluster and that way everything is deleted.
![Delete cluster in google cloud](/image/articles/delete_a_cluster.png)

### Conclusion

In this article, you learned how to deploy a PHP API microservice on Google Cloud using Kubernetes and Docker.   
You can use these steps to deploy any type of application on Google Cloud.


Learn how to deploy your API using Kubernetes and Google Cloud, using free tier services you will be able to deploy your own code in a instance.

Navigating Deadlock Challenges in Real-World Scenarios

Change your perspective on code review

Step-by-step Guide to Deploy Your PHP API on Google Cloud using Kubernetes and Docker

Stay up to date 🎉

Work