---
title: The Town of hidden beauty
summary: A small town in size but a huge one from the inside.
cover: https://substackcdn.com/image/fetch/w_1280,h_720,c_fill,f_webp,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff16d1c84-c7de-40be-92f1-cbefa90834b7_1556x2066.jpeg
tags: ["adventure", "traveling", "france"]
date: 2024-11-05
---

I finally arrived in the village with my best friend, something we were looking forward after a long journey. As I depart the bus, the fresh mountain air smell of the town blows over me. While the bright sun rays were warming up my face.

The stunning views combined with the old architecture of the town, and the mountains that are partly covered by the glaciers, which had started to become grayish. I couldn’t believe my eyes what I'm seeing.

I'm wandering through the town, and the deeper I go, the more beauty I discover, how can a place have so much beauty?

A familiar sound draws me in, I walk over to see and indeed it is a river flowing through the city, where people were rafting in, the screams of joy mixed with fear are barely audible from the river’s powerful flow.

As I went deeper I found these big rocks facing the sun, I could hear the sound of metal hitting the rock, the sound of struggle people were making while they were climbing on, some were just watching the others climb, some were facing the other way and enjoying the view that they had behind.

The town never stops giving. I turn a corner — there’s a beautiful lake, so calm with its dark green color reflecting the mountains like a perfect mirror.

As the day drifted on, I kept hearing different languages that people were talking, some I recognised some not, but I understood that this is a very international town.

As I walk into the hotel where I'm going to stay for the night, The English receptionist hands me the cool, brass key, directing me to my room with a deep accent.

-----

Thank you for reading!

If you enjoyed this short story, feel free to hit the like button or leave a comment—I’d love to hear your thoughts.


A small town in size but a huge one from the inside.

The Town of hidden beauty

---
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.

The Town of hidden beauty

Navigating Deadlock Challenges in Real-World Scenarios

Change your perspective on code review

Stay up to date 🎉

Work