
Hello! 👋

As **performance** and **reliability** is more and more important in software development, it is important to know how to write **efficient code**, and also learn to **not rely on every possible dependency of the world**, when it is not worth it.

The more dependencies we add to our projects, the greater the complexity and maintenance overhead becomes. Each additional dependency requires understanding its functionality, <abbr title="Application Programming Interface">API</abbr>, and potential conflicts with other dependencies. This complexity makes the codebase harder to maintain, and it also poses significant security risks.

We don't want to "reinvent the wheel" and rewrite everything from scratch for each project. In fact, you are **always depending on something** when you are writing your software. At the very least, you are dependent on the programming language you are using. Even if you are doing very low-level stuff, you are still depending on something: hardware.

However, it is important to draw a line between what dependencies are worth the cost and which are not.

Most likely adding a [JavaScript npm package `is-odd`](https://www.npmjs.com/package/is-odd) to check if a number is odd or even for example, is not worth it. Writing it ourselves is easier and allows a better maintenance in the long term.

Learning **how to solve problems** and how to write efficient code is very important and also a very broad and complicated topic, so this blog post will only be an **introduction to the subject**, and will not go in depth.

**Note:** Sources used to write this blog post are available at the [end of this post](#sources).

## What is Competitive Programming?

**Competitive programming** consists of solving correctly and efficiently **well-defined problems** by writing **computer programs** under specified **constraints**. Typically a solution to a problem is a combination of well-known techniques and new insights.

There are many famous competitions: [Google Code Jam](https://codingcompetitions.withgoogle.com/codejam), [Facebook Hacker Cup](https://www.facebook.com/codingcompetitions/hacker-cup), [International Olympiad in Informatics](https://ioinformatics.org/), [International Collegiate Programming Contest](https://icpc.global/), [LeetCode](https://leetcode.com/), [CodinGame](https://www.codingame.com/), etc.

The most common programming languages used for Competitive Programming are: **C++**, **Python** and **Java**. However the design of the algorithms and data structures are applicable to **any programming language**.

All examples solutions on this blog post will be done in **Python**.

## Topics to explore/learn with Competitive Programming

- Time/Space complexity and Big O Notation

- Sorting: Sorting algorithms and Binary search

- Data structures: Arrays (1D, 2D: Matrix, 3D, Multidimensional), Dictionaries, Linked lists, Stack, Queue, Trees, Graphs, Heaps, etc.

- Complete search: Generating Subsets, Permutations, Combinations, etc.

- Greedy algorithms: Coin problem, Scheduling, Minimizing sums, etc.

- Dynamic programming: Fibonacci, Coin problem, Knapsack, etc.

- Bit manipulation: Bit representation, Bit operations, etc.

- Shortest path: Dijkstra, Bellman-Ford, Floyd-Warshall, etc.

- String: Trie structure, String hashing, Z-algorithm, etc.

You can see there are lot of concepts to learn and explore, and it is not an exhaustive list. On this blog post, we will only see the first topic: **Time/Space complexity and Big O Notation**.

## Time/Space complexity and Big O Notation

### Definition

An Algorithm is a finite sequence of well-defined instructions, that have to be given to the computer to perform a specific task. In this context, the variation can occur the way how the instructions are defined. There can be **any number of ways**, a specific set of instructions can be defined **to perform the same task**. Also, with options available to choose any one of the available programming languages, the instructions can take any form of syntax along with the performance boundaries of the chosen programming language. We also indicated the algorithm to be performed in a computer, which leads to the next variation, in terms of the operating system, processor, hardware, etc. that are used, which can also influence the way an algorithm can be performed.

Different factors can influence the outcome of an algorithm being executed, it is wise to understand how efficiently such programs are used to perform a task. To gauge this, we require to evaluate:

- The **Space complexity** of an algorithm **quantifies** the amount of **space or memory taken** by an algorithm to run based on the size of the input.
- The **Time complexity** of an algorithm **quantifies** the amount of **time taken** by an algorithm to run based on the size of the input.

We more often talk about the **time complexity** than space complexity of an algorithm, because we can reuse memory unlike time and memory is cheap nowadays.

**Big O Notation** describes the complexity of an algorithm in terms of **how quickly it grows relative to the input size $n$ (e.g: length of the string, size of the array etc.)** by defining the $N$ number of operations that are done on it.
Example of Big O notation: $O(n^2)$.

### Time complexity

Time complexity **measures** the **time taken** **to execute each statement** of code in an algorithm. It is not going to examine the total execution time of an algorithm. Rather, it is going to give information about the variation (increase or decrease) in execution time when the number of operations (increase or decrease) in an algorithm.

There are many rules to calculate the time complexity of an algorithm.

#### Loops

A common reason why an algorithm is slow is that it contains many loops that go through the input. The more nested loops the algorithm contains, the slower it will run.

If there are $k$ nested loops, the time complexity of the algorithm will be $O(n^k)$.

##### Example $O(n)$

```python
for iteration in range(n):
    pass

# or with a while loop
iteration = 0
while iteration < n:
    pass
```

##### Example $O(n^2)$

```python
for iteration in range(n):
    for iteration2 in range(n):
        pass
```

##### Example $O(n^3)$

```python
for iteration in range(n):
    for iteration2 in range(n):
        for iteration3 in range(n):
            pass
```

etc.

#### Order of magnitude

A time complexity does not tell us the exact number of times the code inside a loop is executed, but it only shows the **order of magnitude**.

In the following examples, the time complexity of the algorithms is $O(n)$ but the number of operations is different.

##### Example 1

```python
for iteration in range(0, n * 3, 1):
    pass
```

Number of operations: $3n$

##### Example 2

```python
for iteration in range(0, n + 5, 1):
    pass
```

Number of operations: $n + 5$

##### Example 3

```python
for iteration in range(0, n, 2):
    pass
```

Number of operations: ${n \over 2}$

#### Phases

If the algorithms consists of consecutive phases, the total time complexity is the largest time complexity of a single phase because it is usually the bottleneck of the code.

The following code consists of 3 phases, with time complexities $O(n)$, $O(n^2)$ and $O(n)$. Thus the total time complexity is $O(n^2)$.

```python
for iteration in range(n):
    pass

for iteration in range(n):
    for iteration2 in range(n):
        pass

for iteration in range(n):
    pass
```

#### Several variables

Sometimes the time complexity depends on several factors. In this case, the time complexity formula contains several variables: $O(nm)$.

```python
for iteration in range(n):
    for iteration2 in range(m):
        pass
```

#### Recursion

The time complexity of a recursive function depends on the number of times it is called and the time complexity of a single call. The total time complexity is the product of these values.

##### Example 1

The call `recursive(n)` causes $n$ calls and the time complexity of each call is $O(1)$. Thus the total time complexity is $O(n)$.

```python
def recursive(n: int):
    if n != 1:
        recursive(n - 1)
```

##### Example 2

```python
def recursive(n: int):
    if n != 1:
        recursive(n - 1)
        recursive(n - 1)
```

In this case, `recursive(n)` causes 2 other calls except for $n = 1$.

The following table shows the function calls produced by this single call:

| function call | number of calls |
| ------------- | --------------- |
| $g(n)$        | $1$             |
| $g(n - 1)$    | $2$             |
| $g(n - 2)$    | $4$             |
| ...           | ...             |
| $g(1)$        | $2^{n - 1}$     |

Based on this, the time complexity is:

$$
1 + 2 + 4 + ... + 2^{n - 1} = 2^n - 1 = O(2^n)
$$

#### Complexity Classes (from fastest to slowest)

![Big O Notation](../public/images/posts/programming-challenges/big-o-chart-notations.webp)

Here is a list of classes of functions that are commonly encountered when analyzing the running time of an algorithm.

- $O(1)$: **Constant** (does not depend on the input size). A typical constant-time algorithm is a direct formula that calculates the answer.

- $O(\log_2(n))$: **Logarithmic** algorithm often halves the input size at each step. $\log_2(n)$ equals the number of times $n$ must be divided by 2 to get 1.

- $O(\sqrt{n})$: **Square root** algorithm is slower than $O(\log_2(n))$ but faster than $O(n)$.

- $O(n)$: **Linear** algorithm goes through the input a constant number of times. This is often the best possible time complexity, because it is usually necessary to access each input element at least once before reporting the answer.

- $O(n \log_2(n))$: **Log linear** often indicates that the algorithm sorts the input, because the time complexity of efficient sorting algorithms is $O(n \log_2(n))$. Another possibility is that the algorithm uses a data structure where each operation takes $O(\log_2(n))$ time.

- $O(n^2)$: **Quadratic** algorithm often contains 2 nested loops. It is possible to go trough all pairs of the input elements in $O(n^2)$ time.

- $O(n^3)$: **Cubic** algorithm often contains 3 nested loops. It is possible to go trough all triplets of the input elements in $O(n^3)$ time.

- $O(2^n)$: **Exponential** often indicates that the algorithm iterates through all subsets of the input elements. For example, the subsets of $\{1, 2, 3\}$ are $S = \{\{\empty\}, \{1\}, \{2\}, \{3\}, \{1, 2\}, \{1, 3\}, \{2, 3\}, \{1, 2, 3\} \}$.

- $O(n!)$: **Factorial** often indicates that the algorithm iterates through all permutations of the input elements. For example, the permutations of $\{1, 2, 3\}$ are $P = \{\{1, 2, 3\}, \{1, 3, 2\}, \{2, 1, 3\}, \{2, 3, 1\}, \{3, 1, 2\}, \{3, 2, 1\} \}$.

### Estimating efficiency

By checking the time complexity of an algorithm, it is possible to check before implementing the algorithm,that it is efficient enough for the problem.

Example: assume that the time limit for a problem is 1 second and the input size is $n = 10^5$. If the time complexity is $O(n^2)$, the algorithm will perform about $(10^5)^2 = 10^{10}$ operations.

Given that a modern computer can perform some hundred of millions of operations per second. This should take at least 10 seconds, so the algorithm seems to be too slow for solving the problem.

## Practical problem: Maximum subarray sum

There are often several possible algorithms for solving a problem such that their time complexities are different. This section discusses a classic problem that can be solved using several different algorithmic techniques, including brute force, divide and conquer, dynamic programming, and reduction to shortest paths, each technique with different time complexity.

**Maximum subarray sum**: Given an array of $n$ integers, find the contiguous subarray with the largest sum.

Contiguous subarray is any sub series of elements in a given array that are contiguous ie their indices are continuous. The problem is interesting when there may be negative values in the array, because if the array only contains positive values, the maximum subarray sum is basically the sum of the array (the subarray being the complete array).

### Example 1

#### Input

```txt
[1, 2, 3, 4, 5, 6]
```

#### Output

```txt
21
```

**Explanation:** The subarray with the largest sum is the array itself (as there is no negative values) `[1, 2, 3, 4, 5, 6]` which has a sum of `21`.

### Example 2

#### Input

```txt
[-1, 2, 4, -3, 5, 2, -5, 2]
```

#### Output

```txt
10
```

**Explanation:** The subarray with the largest sum is `[2, 4, -3, 5, 2]` which has a sum of `10`.

### Worst solution: Brute force

```python
def maximum_subarray_sum_cubic(array: list[int]) -> int:
    """
    Time complexity: O((array_length)^3)

    We go through all possible subarrays, calculate the sum in each subarray and maintain the maximum sum.
    """
    if len(array) == 0:
        return 0
    best_sum = array[0]
    length = len(array)
    for i in range(length):
        for j in range(i, length):
            sum = 0
            for k in range(i, j + 1):
                sum += array[k]
            if sum > best_sum:
                best_sum = sum
    return best_sum
```

### Better solution: Linear time

```python
def maximum_subarray_sum_linear(array: list[int]) -> int:
    """
    Time complexity: O(array_length)

    We loop through the array and for each array position, we calculate the maximum sum of a subarray that ends at that position. After this, the answer for the problem is the maximum of those sums.
    """
    if len(array) == 0:
        return 0
    best_sum = array[0]
    length = len(array)
    sum = 0
    for i in range(length):
        sum = max(array[i], sum + array[i])
        best_sum = max(best_sum, sum)
    return best_sum
```

## Conclusion

Problems solving is a very complicated and large topic, and also a very important skill to have as a software developer.

To improve our problems solving skills, we can regularly practice with [programming challenges](https://github.com/Divlo/programming-challenges).

## Sources

- [Wikipedia - Competitive programming](https://en.wikipedia.org/wiki/Competitive_programming)
- [Frontend Masters - The Last Algorithms Course You'll Need](https://frontendmasters.com/courses/algorithms/)
- [Big-O Cheat Sheet](https://www.bigocheatsheet.com/)
- [programming challenges](https://github.com/Divlo/programming-challenges)


What are Programming Challenges and Competitive Programming and an introduction to Time/Space Complexity with Big O Notation.

🧠 Programming Challenges


Hello! 👋

Welcome to the Ultimate Guide to master `git` in your daily workflow, we will see what are the most used commands, what are the best practices, and tips and tricks.

This guide is a summary of the most important things to know when working with `git`, and in general, will link to the official documentation of `git` or other resources for more details, it is on purpose to not go in depth in each topic, it allows to summarize `git` and vocabulary about it (you can use it as a `git` cheatsheet).

**Note:** Sources used to write this blog post are available at the [end of this post](#sources).

## Introduction

**Git** is a free and open-source distributed **version control system** for keeping track of changes across a set of files.

Git was originally authored by [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in 2005 for the development of the [Linux kernel](https://kernel.org/).

Git allows:

- to be able to work with several people on the same codebase.
- track changes to know who did what and when.
- revert changes.

Git is **decentralized**, which means that every developer has a full copy of the repository and the complete history of the project.

## Get started with `git` and `.gitconfig` config file

The first thing you should do when you install Git is to set your user name and email address.

```sh
git config --global user.name "Username"
git config --global user.email "email@example.com"
```

These configurations are stored in the `.gitconfig` file in your home directory (e.g: `~/.gitconfig`) with this format:

```sh
[user]
  name = Username
  email = email@example.com
```

You can find more information and useful `git` configurations in the [official documentation](https://git-scm.com/docs/git-config).

## How `git` works?

Each `git` project is called a **repository** (or **repo** for short) and it contains all the files and folders for a project, as well as each file's revision history (**commits**) stored in the `.git` folder.

The history of a repository is represented by a graph.

Each node is called commit and contains:

- an instantaneous view (snapshot) of the state of the repository at a specific moment
- metadata: message, author, creation date, etc.

Commits are **snapshots** (not diffs on each file) of the project at specific moments in time.

There are several areas where the files in your project will live in Git:

- **Working directory**: the files that you see in your computer's file system.
- **Staging area**: the files that will go into your next commit (files added with `git add <filename>` command).
- **Local repository**: the `.git` directory, which contains all of your project's commits, branches, etc. (files added with `git commit -m "message"` command).
- **Remote repository**: the `.git` directory in a remote server (files added with `git push` command).

## Commands cheatsheet

You can find the official documentation of `git` commands at [git-scm.com/docs](https://git-scm.com/docs).

```sh
# Initialize a new git repository
git init

# Clone a repository
git clone <url>

# Add all the files to staging area
git add .

# Add specific file to staging area
git add <file>

# Commit changes
git commit -m "chore: initial commit"

# Add remote repository
git remote add <remote> <url>
# The main <remote> is often called `origin`

# Add forked repository
git remote add <remote> <url>
# The forked <remote> is often called `upstream`

# List all the remotes
git remote

# Sync forked repository
git fetch <remote>
git merge <remote>/<branch>

# Push changes to remote repository
git push <remote>

# Pull changes from remote repository
git pull <remote>

# Show the status of the working tree
git status

# Show the commit history
git log

# Create a new branch
git checkout -b <branch>

# Switch to a branch (or tag or commit)
git checkout <branch>

# Merge a branch into the current branch
git merge <branch>

# Delete a branch
git branch --delete <branch>
git push <remote> --delete <branch>

# Fetch branches from remote repository and prune
git fetch --prune

# Revert a commit
git revert <commit>

# Change several past commits (interactive rebase)
# HEAD points to the current consulted commit.
git rebase --interactive HEAD~<number-of-commits>

# Reset the current branch, delete all commits since <branch> (without removing the changes)
git reset --soft <branch>

# Apply the changes introduced by some existing commits
git cherry-pick <commit>
```

## `.gitignore` file

The `.gitignore` file is a text file that tells `git` which files (or patterns) it should ignore.

The `.gitignore` file is usually placed in the root directory of the repository.

We usually ignore files that are generated by the build process or files that contain sensitive information.

Example of `.gitignore` file:

```sh
.env
build
*.exe
```

## `.gitkeep` file

The `.gitkeep` file is a file that is used to keep an empty directory in a Git repository.

This is useful when you want to keep an empty directory in your repository but you don't want to commit any file inside it.

## Git remote repositories (GitHub/GitLab)

Once you are ready to share your code over the internet, you will need to create a remote repository on a service like [GitHub](https://github.com) or [GitLab](https://gitlab.com).

There are many other services, you can also self-host your own Git server.

### SSH vs HTTPS authentication

Once you have created a remote repository, you will need to authenticate to push and pull changes.

There are two main ways to authenticate:

- **SSH**: you will need to generate an SSH key pair and add the public key to your remote repository.
- **HTTPS**: you will need to provide your username and password each time you push or pull changes.

SSH authentication is the recommended way to authenticate to a remote repository.

You can find more information about SSH authentication in the [official documentation](https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key).

### Sign `git` commits with `gpg`

As we have seen in the [Get started with `git` and `.gitconfig` config file](#get-started-with-git-and-gitconfig-config-file) section, we can configure `git` with a name and email address with a value of our choice.

That means that **anyone can create a commit with any name and email address and claim to be whoever they want** when they create a commit.

To avoid this, you can sign your commits with a <abbr title="GNU Privacy Guard">[GPG](https://gnupg.org/)</abbr> key.

You can find more information about signing commits in the [official documentation](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work).

### Continous Integration/Continuous Delivery (CI/CD)

Once you have your code in a remote repository, everyone (with access) can potentially start contributing to the project. This is great, but it also means that you need to have a way to ensure that your code is working as expected for each change in the project.

You could do it manually, depending on the size and the complexity of the project, but it could be a tedious task.

Instead, you can use a **Continuous Integration** (CI) service to automate the process of testing your code, running linting, unit tests, e2e tests, etc.

There are many CI services, but the most popular ones are [GitHub Actions](https://github.com/features/actions), [GitLab CI](https://docs.gitlab.com/ee/ci/), [CircleCI](https://circleci.com/), [Travis CI](https://travis-ci.org/), and many others...

Then, once your code is ready, tested and working as expected, you can use a **Continuous Delivery** (CD) service to automate the process of **deploying your code**.

CI/CD services are usually integrated with remote repositories, so you can configure them to run automatically when you push changes to the remote repository.

## Best practices and `git` workflows

Commit messages are very important, they are a way to easily know what has changed in the project.

There are many conventions for commit messages, but the most popular one is the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.

Then, we can use the commit messages to automatically determine a [semantic version](https://semver.org/) for the next release of the project.

When multiple developers are working on the same project, it is important to organize the work in a way that everyone can work on different features without conflicts (changes in the same files).

There are many ways to organize the work, but the most popular ones are:

- [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/)
- [GitHub Flow](https://guides.github.com/introduction/flow/)
- [Trunk-based development](https://trunkbaseddevelopment.com/)

They are called **Git workflows**, or **Git branching strategies**.

## Conclusion

`git` is the tool that every programmer should know to do collaborative work (not only, `git` is also very powerful even when working alone) and keep track of changes across a set of files.

## Sources

- [Git official website and documentation](https://git-scm.com/)
- [Git Explained in 100 Seconds](https://www.youtube.com/watch?v=hwP7WQkmECE)
- [Understand Git in 7 minutes](https://www.jesuisundev.com/en/understand-git-in-7-minutes/)
- [How (and why) to sign Git commits | With Blue Ink](https://withblue.ink/2020/05/17/how-and-why-to-sign-git-commits.html?utm_source=tiktok&utm_campaign=codetok-sign)
- [What Are the Best Git Branching Strategies](https://www.flagship.io/git-branching-strategies/)


What is `git`, what are the most used commands, best practices, and tips and tricks. The Ultimate guide to master `git` in your daily workflow.

🗓️ Git version control: Ultimate Guide


Hello! 👋

After months of hard work, [Thream v1.0.0](https://www.thream.divlo.fr/) has been released! 🎉

[**Thream**](https://www.thream.divlo.fr/) is your open-source platform to stay close with your friends and communities, talk, chat, collaborate, share and have fun.

## Presentation

[**Thream**](https://www.thream.divlo.fr/) is a social network to stay close with your friends and communities to talk, chat, collaborate and share.

The project is largely inspired by [Discord](https://discord.com), a proprietary instant messaging service, but differentiates itself by its **non-profit open source philosophy** and will integrate special features.

The source code is available on [GitHub](https://github.com/Thream).

The idea is that a user can create an account to authenticate with an email address, and a password, or directly use an account from another platform (currently supported: Google, GitHub, Discord). Once the user is authenticated, he/she can create and join "guilds", in other words communities, in order to discuss with other people in several channels to group discussions talking about the same subject.

![The Thream app on a community page](../public/images/posts/thream-v1-0-0/thream-ui.png)

[**Thream**](https://www.thream.divlo.fr/) is a website that works on any recent browser, accessible on [thream.divlo.fr](https://www.thream.divlo.fr/).

## History

The idea for the project has existed since May 13, 2020, symbolized by a [publication on Twitter](https://twitter.com/Divlo_FR/status/1260638175246135296) by the creator: Divlo.

The main goal is to put into **practice knowledge in web development** and computer science in general on a concrete project that can **easily evolve over time** where you can add many features.

The development of the project begins under the name of **SocialProject**, on August 20, 2020, with colors close to the image of Divlo.

![SocialProject](../public/images/posts/thream-v1-0-0/social-project.jpg)

When I started the project, I had little knowledge of database design, real-time management or the architecture of such a large <abbr title="Information Technology">IT</abbr> project, so this will be accompanied by many technical problems, to which we will need to find appropriate solutions.

On October 19, 2020, **SocialProject** becomes **Thream**, an invented name, not yet used and more original than the previous one, and also changes colors so that the application is accessible in two distinct themes (light and dark).

With the help of [Walidoux](https://github.com/Walidoux), a junior developer really good at making beautiful <abbr title="User Interface">UI</abbr> with <abbr title="Cascading Style Sheets">CSS</abbr>, we were able to collaborate on this side project together.

Since the project is mainly developed during free time (mainly on weekends), the project took longer to be developed than desired, but now we finally released the first version. 🥳

## Implementation and Technical Difficulties

### Architecture

**Thream** is divided into two distinct projects:

- The **server** part, called **backend**, which the user does not see, allows actions to be taken to save or recover data in the **database**, it is the technical and functional aspect of the project. This part uses a style of software architecture defining a set of constraints to be used to create web services that establish interoperability between computers on the Internet, called REST <abbr title="Application Programming Interface">API</abbr>.

- The **client** part, called **frontend**, what **the user sees on the screen**, such as forms, buttons and all the **graphic elements** with which the user can interact from a browser.

![HTTP Communication Schema](../public/images/posts/thream-v1-0-0/http-communication.png)

This design allows the separation between the client and the server, as long as they both structure their communication according to the <abbr title="Representational state transfer">REST</abbr> architectural guidelines, using the <abbr title="Hypertext Transfer Protocol">HTTP</abbr> protocol, they will be able to communicate with each other, which makes it possible to work independently on the backend and on the frontend using different technologies and skills, really useful in teamwork.

To allow the development of this design, it is necessary to think about its architecture in order to solve the following problem: how to store and structure the folders and files of a source code in order to find which file to modify to correct a problem with a particular feature, or to add a feature?

There are two main architectures to solve this problem:

- The **Monorepo** architecture is a single directory containing several distinct projects with well-defined relationships, i.e. it allows the modification of the code in the client and server part simultaneously in the same place by verifying that a modification in the server part does not impact the client part.
- The **Polyrepo** architecture are several directories, a directory corresponding to a project.

Both architectures track source code file history using version control systems such as [git](https://git-scm.com/).

**Thream**, uses the **Polyrepo** architecture, to make it easier to set up and allows complete independence between client and server code.

### Technologies

Now that we have discussed, on the architecture of the source code, we will discuss the choice of technologies. The chosen technologies must meet the need, and allow the developer to be productive to quickly have a result. Often there are several possible technologies to meet the same need, so it is a question of choosing the technology that you prefer and that you know best.

To ease the development, we chose for **Thream** to use the [TypeScript](https://www.typescriptlang.org/), an open source programming language made by Microsoft. It's a stricter syntactic superset of **JavaScript**, and adds optional static typing to the language, meaning we can assign a "type" (`string`, `number`, `boolean` etc.) to each data/variable in the code, which has the advantage of identifying program errors even before execution and thus greatly improves developer productivity.

The **TypeScript** code is then compiled into **JavaScript** language which is one of the basic technologies of the **World Wide Web**, alongside HTML and CSS (in the client part), this makes it possible to make the pages of websites **interactive** by executing code depending on a certain event, for example when clicking on a button, or when pressing a key on the keyboard.

Since the creation of **Node.js** in 2009, it is now also possible to execute **JavaScript** outside the browser, for example on a server. **Node.js is a runtime environment** that offers modules that handle various basic features for interacting with files/folders, networking (DNS, HTTP, TCP, TLS/SSL, or UDP), and other functions inaccessible from a browser and designed to reduce the complexity of developing server applications.

**TypeScript** allows you to code with the same programming language, the client part and the server part, with different needs.

### User Interface (frontend)

The needs of the graphical interface (the client part):

- be accessible through a web browser
- allow the user to install the application
- adapts to screen size
- real-time data update (example: when a new message is sent)
- save the authenticated user (in cookie)

In order to meet its needs, Thream is a **<abbr title="Progressive Web App">PWA</abbr>**, this consists of making a website appear to the user as a native application, which makes it possible to combine the functionalities of browsers with those of the experience offered by native applications, such as the possibility of installing the application. The main advantage is to be able to **code once** and to provide the **application on several platforms (iOS, Android, Windows, GNU/Linux etc.)** without the need to develop specifically according to each platform.

To design a **<abbr title="Progressive Web App">PWA</abbr>**, and allow updating the data on the graphical interface, we can use a framework, a development infrastructure to offer us a set of tools and software components. For **Thream**, we use [Next.js](https://nextjs.org/), a framework based on [React.js](https://reactjs.org/), which allows you to create interactive user interfaces in JavaScript, to **update the graphical interface when the data changes**.

### Server (backend)

By using the protocol, **<abbr title="Hypertext Transfer Protocol">HTTP</abbr>**, it is the client who sends a request to the server, but to allow the transfer of data in real time, the **<abbr title="Hypertext Transfer Protocol">HTTP</abbr>** protocol is no longer sufficient.

We use **WebSockets** so that it is the server that send a response to all connected clients without the client requesting to the server to get a response, the server sends responses according to events, for example when creating or deleting a message.

Thanks to [Fastify](https://www.fastify.io/), a fast and low overhead web framework, for Node.js and [Socket.io](https://socket.io/), a bidirectional and low-latency communication for every platform, we can easily make REST API and real time communication.

To store the data, we use [PostgreSQL](https://www.postgresql.org/) database, and [Prisma](https://www.prisma.io/), a <abbr title="Object-Relational Mapping">ORM</abbr> for Node.js, which allows us to easily interact with the database without the need of writing <abbr title="Structured Query Language">SQL</abbr> ourselves.

## Current and future state

The main interest of **Thream** is to be able to put into practice the computer knowledge acquired as an autodidact on a concrete project, in order to learn, and understand the problems and potential solutions to complex computer applications such as social networks.

Now that the first version of **Thream** has been released, there may not be any major evolution thereafter, the project will continue to be maintained to fix any bugs, and remain accessible, for as long as possible.

The other interest of the project is that it is completely **open-source**, and allows those who want to contribute to the development, and add new features.

**Thream** is **non-profit** and therefore has no financial goal, deadline or specific feature target, which makes the design of the project a hobby and a way to learn new concepts.

Feel free to give feebacks and suggestions to improve the project, and to report any bug you find.

**Thream** is available: [**thream.divlo.fr**](https://www.thream.divlo.fr/).


Your open source platform to stay close with your friends and communities, talk, chat, collaborate, share and have fun.

🟢 Thream v1.0.0


Hello! 👋

I will explain some of the mistakes I made as a junior developer, so you can avoid doing them.

## 1. Skipped learning how to do automated tests

Probably one of the most common errors junior developers does.

When you begin in programming, you learn a programming language, so you learn variables, conditions, loops, functions, etc.

With these concepts, you might start a new project, but as the project grows, you will end up using functions at multiple places in code, so if you change the behavior of a function, it will affect the whole project.

And because the code grows, you might do some refactoring to make it more maintainable, but because we are humans, we make mistakes, you could accidentally break the entire project even with a tiny change you thought was safe to do.

If you had automated tests, you would have a way to know if you made a mistake even before deploying to production.

Depending on the programming language you are using, and what is the project you are working on, writing tests will be different.

Be aware that there are 3 main testing strategies:

- [Unit testing](https://en.wikipedia.org/wiki/Unit_testing)
- [Integration testing](https://en.wikipedia.org/wiki/Integration_testing)
- [End-to-end testing](https://en.wikipedia.org/wiki/End-to-end_testing)

After you learned the basics of programming, learn how to write automated tests, it will save you a lot of time and debugging.

I would even say that you should get used-to writing tests, it should be an automatism, you should not even have to think about it to do it.

## 2. Thinking too big, with too much abstraction

Abstraction is great, but it can be harder to understand what is going on if actually don't need this abstraction.

Find the right balance, between abstraction and simple implementation, start simple, and then gradually improve and add more features.

When you start a new project, you should focus on the core of the project, not on the details, to release as soon as possible, a working usable version of your project also called a [**Minimum Viable Product** (MVP)](https://en.wikipedia.org/wiki/Minimum_viable_product), it is better than a half-functioning, over-engineered project.

I made this mistake while developing [Thream](https://thream.divlo.fr), your **open source** platform to stay close with your friends and communities, **talk**, chat, **collaborate**, share and **have fun**.

Basically, I thought it was cool, to do a "big" v1.0.0 release with a lot of features, but in fact, it was not, because I could not even show what I was developing (to the end-users, not technical people) as I was making multiple features at the same time and also mainly focused on the **REST API** side and not at all the **website (frontend)**.

What I recommend you to do is to start with a **v1.0.0** release as soon as possible with the minimum required features needed for your project idea, and then gradually add new features and release new versions.

In my example for [Thream](https://thream.divlo.fr), I could release a v1.0.0 without these features:

- English/French translation (could be only English)
- Light/Dark theme (could be only Dark)
- OAuth2 Authentication (could be only simple email/password authentication)
- User public profile
- Channels (maybe could be only one channel per guild to start with)

And probably more, what was really required with [Thream](https://thream.divlo.fr), is that users could authenticate, create a community of friends, and then they could communicate with each other with messages in real-time, really that was enough.

And then with this basis, I could release, v1.1.0, v1.2.0 etc. with more features, and release new versions more often to show the progress of the project, it is also more motivating to have users testing our project and to **get feedback sooner**.

**Start simple, improve later.**

## Conclusion

The real key to success is to **be passionate**, **keep learning** on your own, and **look at mistakes as learning experiences**.


Here are mistakes I made when I started, to prevent you from making the same mistakes.

❌ Mistakes I made as a junior developer


Hello! 👋

Have you already heard of "**Clean Code**" or "**Design Patterns**"?

Even if you know what it is about, this blog post will probably still be useful to you, I will share some tips and tricks to make your code more readable and maintainable in the long term.

**Note:** Sources used to write this blog post are available at the [end of this post](#sources).

## Definition: Clean Code

A clean code is a code that is **easy** to **read** and easy to **understand**.

But I promise it is not a code that is easy to write, in fact it is really **hard to write Clean Code**.

We could ask ourselves, what is **easy** to **read** and easy to **understand** ?

It depends of many factors, and is somewhat relative to each one of us. The **perfect** Clean code **doesn't exist**, but we can try to be **as perfect as possible**.

## Why is it so important?

Code like that works great, but it is not enough, even if the code will be read by the computer and understood by the machine, we should not forget that the code is **written by human** and will be also **read by human** not only a machine.

For example the [Linux kernel](https://www.kernel.org/), is one of the biggest open source project with many contributors worldwide. Last data shows that it is about **20 millions** lines of code.

With a project of this magnitude, we can't let everyone do what they want and however they want, **we must set rules and conventions** to get everyone to agree, this allows to add features faster and will reduce possible bugs as **developers** will not struggle as much to understand the code.

## Definition: Design Patterns

These **rules** and **conventions** are so called **Design Patterns**.

A software design pattern is a general way of **solving a problem** by applying a **well-known solution**.

Design patterns are formalized **best practices** that the programmer can use to solve common problems when designing an application or system.

## How to write Clean Code and famous Design Patterns

To show you the rules and conventions, I will write the examples in the [TypeScript](https://www.typescriptlang.org/) programming language but it is relevant to any programming language.

### Naming variables

We all know that **variables** are used everywhere in **programming**, good variable names allow us to better understand the intention of the code.

#### Same vocabulary for the same type of variable

##### Example (bad way)

```typescript
function getUserInfo(): User
function getUserDetails(): User
function getUserData(): User
```

##### Example (good way)

```typescript
function getUser(): User
```

---

#### Avoid "Magic Numbers"

##### Example (bad way)

```typescript
// What does 86400000 mean?
setTimeout(restart, 86400000)
```

##### Example (good way)

```typescript
const MILLISECONDS_IN_ONE_DAY = 24 * 60 * 60 * 1000
setTimeout(restart, MILLISECONDS_IN_ONE_DAY)
```

---

#### Explicit is better than implicit (no abbreviations or acronyms)

##### Example (bad way)

```typescript
const u = getUser()
const s = getSubscription()
const t = charge(u, s)
```

##### Example (good way)

```typescript
const user = getUser()
const subscription = getSubscription()
const transaction = charge(user, subscription)
```

---

#### As short as possible, as long as necessary

##### Example (bad way)

```typescript
interface Car {
  carModel: string
  carColor: 'red' | 'blue' | 'yellow'
}
const printCar = (car: Car): void => {
  console.log(`${car.carModel} (${car.carColor})`)
}
```

##### Example (good way)

```typescript
interface Car {
  model: string
  color: 'red' | 'blue' | 'yellow'
}
const printCar = (car: Car): void => {
  console.log(`${car.model} (${car.color})`)
}
```

---

#### Boolean names

The name of a boolean variable should be a question, and the answer should be true or false. We can use prefixes like `is`, `has`, `can` to make it more explicit and we should avoid negation.

##### Example (bad way)

```typescript
let person = true
let age = true
let dance = true
function isEmailNotUsed(email: string): boolean
```

##### Example (good way)

```typescript
let isPerson = true
let hasAge = true
let canDance = true
function isEmailUsed(email: string): boolean
```

---

### DRY (Don't Repeat Yourself)

When we copy/paste the same lines of code, we should better abstract it in a function, that we can reuse later without having to copy/paste the lines of code, that makes the code more maintainable afterwards, because if we need to change the behavior of this piece of code, we won't need to change it in several places, but only when declaring the function.

---

### KISS (Keep It Simple Stupid)

As we have just said, we will prefer to abstract the code in multiple functions, rather than leaving everything in the same place, but a function should not do "too much", and we should rather separate it into several distinct functions.

We have to keep it as simple as possible, not to implement features that are not requested, and to divide the functions as much as possible into small functions.

### Example (bad way)

```typescript
import fs from 'node:fs'
import path from 'node:path'

const createFile = async (
  name: string,
  isTemporary: boolean = false
): Promise<void> => {
  if (isTemporary) {
    return await fs.promises.writeFile(path.join('temporary', name), '')
  }
  return await fs.promises.writeFile(name, '')
}
```

`createFile` is a function that does 2 things so it is better to split it in 2 separated functions.

### Example (good way)

```typescript
import fs from 'node:fs'
import path from 'node:path'

const createFile = async (name: string): Promise<void> => {
  await fs.promises.writeFile(name, '')
}

const createTemporaryFile = async (name: string): Promise<void> => {
  await createFile(path.join('temporary', name))
}
```

---

### TDD (Test Driven Development)

Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.

We first write tests that should fails because there are no implementation, and then we write the code implementation to make the tests succeeds.

The End To End (e2e) and Unit tests should document what is the behavior intended for the code.

---

### Avoid comments

One of the most important rule of "Clean Code": If you need to add **comments**, it's because your code is **not clean**.

I know that might be counter intuitive at first, as most developers will advice you to add comments to your code, to document what it does.

The thing is that you should choose good variable names, break down features in multiple functions, so that others developers can read your code and understand it just by reading the functions names etc.

You can write comments, but that should only be used documenting how to use a function but not for the implementation itself and in places where you can't be more explicit.

In fact, as we saw in the [TDD section](#tdd-test-driven-development), automated tests can document what a function should returns, and how the code should behave, so that should already improve code maintainability.

Having a good comment explaining a difficult code is better than nothing with a bad written code, difficult to understand.

#### Example (bad way)

```typescript
// Check if subscription is active
if (subscription.endDate > Date.now()) {
}
```

#### Example (good way)

```typescript
const isSubscriptionActive = subscription.endDate > Date.now()
if (isSubscriptionActive) {
}
```

Here we are creating a new variable `isSubscriptionActive` that allows us to avoid the need of a comment to understand what the code does.

---

## Conclusion

We can't write the perfect clean code understandable by everyone but we can **write code that is as perfect as possible to ease maintaibility** for yourself and others developers.

## Sources

- [Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin](https://books.google.fr/books/about/Clean_Code.html?id=hjEFCAAAQBAJ)
- [Software Design Pattern (Wikipedia)](https://en.wikipedia.org/wiki/Software_design_pattern)
- [TDD - Test-driven development (Wikipedia)](https://en.wikipedia.org/wiki/Test-driven_development)
- [github.com/labs42io/clean-code-typescript](https://github.com/labs42io/clean-code-typescript)


What is "Clean Code", what are "Design Patterns", and why is it so important today? Tips and tricks to make your code more readable and maintainable in the long term.

🧼 Clean Code


Hello, world! 👋

## Introduction

This blog is here to document my journey of learning computer science, explaining technical difficulties and problems I encountered, and how I solved them.

The idea is that I will share my knowledge with you (readers), and hopefully help you to learn too.

Keep in mind that I will not translate the posts in French, all the posts will be written in English, as I'm not a native English speaker, I will probably make mistakes, feel free to open pull requests on [GitHub](https://github.com/Divlo/Divlo) to correct them. 😊

I plan to publish new posts when I have something new to share. There's no schedule, so stay tuned!

To stay informed of new blog post and to ask questions, feel free to follow me on Twitter: [@Divlo_FR](https://twitter.com/Divlo_FR).

## Project based learning

The blog posts subjects will be often related to the problems I encountered in the projects I am currently working on.

Most of the time, when I am learning something new, I **learn it because I actually need it for a project**, I don't learn [React.js](https://reactjs.org) because it is trending, and everyone talks about it.

I learn something new, because it solved a "real life" problem I had encountered. For example, [React.js](https://reactjs.org) allows to easily update the DOM (Document Object Model) in the browser, so we can add interactivity to our web pages, not only that, it allows to reuse multiple HTML (JSX) elements with components.

[React.js](https://reactjs.org) is only an example, but hopefully you understood my point: I often don't like too much theoretical thing, and enjoy much more practical things.

## How this blog is made

In this section, I will explain what technologies I used to make this blog, and what are the technical choices I had to do.

The code of this website is open source on [GitHub](https://github.com/Divlo/Divlo), so you can see the code and contribute to it.

### Technologies

- [Next.js](https://nextjs.org/)

  It allows to have a server-side rendered website, that means that it is faster and easier to have a good <abbr title="Search Engine Optimization">SEO</abbr> than a <abbr title="Single Page Application">SPA</abbr>.

- [MDX](https://mdxjs.com/)

  MDX is an extension of Markdown that allows you to use custom React components.

  Here's what Markdown looks like:

  ```md
  A simple paragraph, with some **bold** text and some `inline code`.
  ```

  When using Markdown in a web application, there's a "compile" step; the Markdown needs to be transformed into HTML, so that it can be understood by the browser. Those asterisks get turned into a `<strong>` tag, and each paragraph gets a `<p>` tag etc.

- [Tailwind CSS](https://tailwindcss.com/)

  Tailwind is a CSS framework to rapidly build modern websites without ever leaving HTML.

## Conclusion

I hope you will enjoy my blog, and will find it useful.

See you in the next posts! 😊


First post of the blog, introduction and explanation of how this blog is made.

Blog

🧠 Programming Challenges

🗓️ Git version control: Ultimate Guide

🟢 Thream v1.0.0

❌ Mistakes I made as a junior developer

🧼 Clean Code

👋 Hello, world!