XP2DEV - Episode 4 - L'effondrement du marché tech 2024

XP2DEV - Episode 3 - Actus IT et Freelancing 2023

XP2DEV - Episode 2 - Comment devenir un meilleur développeur

# L'écosystème des startups françaises : crise ou assainissement ?

Mac4Ever a posté dernièrement un article qui parle de l'écosystème startup en France et s'appuie sur des études et statistiques pour faire plusieurs constats: [https://www.mac4ever.com/web/187803-la-bulle-eclate-pour-les-startup-francaises](https://www.mac4ever.com/web/187803-la-bulle-eclate-pour-les-startup-francaises)
- Les startups vont mal (car nombreuses sont celles qui coulent)
- Les startups les plus anciennes ont plus de mal à affronter le marché actuellement
- Les startups d'après 2020 tiennent mieux (avec moins de financement)

Pour avoir connu ce marché et avoir travaillé avec des startups sur ces périodes, oui, il y a eu une chute du financement. 

## Pour autant est-ce négatif ?

Oui et Non !

D'un côté, c'est dommage que certains projets ne se lancent pas faute de budget, mais d'un autre côté, c'est bien mieux d'affronter le marché en ayant bootstrapé un projet et en étant capable de subvenir seul à ses besoins, que d'être obligé de lever des fonds pour survivre.

_"Bootstrapper une boîte, c'est se faire vacciner contre le marché et avoir les anticorps."_

Si la boîte a toujours besoin d'être sous perfusion, il y a un problème !

## La root cause

J'ai beau retourner le problème dans tous les sens, je pense que tout ceci arrive parce que le marché a toujours raison. La plupart des projets qui ont obtenu un financement ne sont pas fous, il faut se l'avouer. Certains d'entre eux sortent du lot (**Mistral**, **Qonto**, **BackMarket**, **Alan**)... Rien de ce que je vais dire n'est sponsorisé, c'est juste un constat en tant que consommateur:

- Oui **BackMarket** propose de supers produits avec des garanties: **écologique, pratique et économique**, que demander de mieux ?
- Oui **Mistral** est incroyable, probablement **un des meilleurs modèles du moment**. 
- Oui **Qonto** (ma banque) est une banque géniale, ça marche très bien, c'est réactif, les opérations fusent... Ils ont mis la barre haute à tel point que quand je me fais démarcher par une banque traditionnelle, c'est MORT ! **Jamais un prestataire traditionnel ne pourra lui arriver à la cheville en matière de fiabilité et de prix** (certaines banques m'ont demandé un pourcentage de CA pour signer chez eux, mais lol), donc même s'ils ont augmenté leur prix depuis les débuts, impossible de se dire que la valeur n'y est pas quand on met ce prix.

## En dehors de ces quelques géants, on a quoi ?

Des tentatives de marketplace avec une exécution désastreuse (seul **Mirakl** survie), des constructeurs de vélos qui ont esquivé les tests techniques...

Dans la vie, il faut essayer des choses, et continuer d'essayer. Je trouve même que c'est bien que ces sociétés aient tenté l'aventure. **Mais le marché a tranché et si le service ne décolle pas c'est qu'il n'en valait pas la peine.**

## Faut-il s'alarmer du taux d'échec ?

Je pense que comme dans la vie, plus on échoue, plus on apprend et plus on a des chances de réussir. Je reste persuadé qu'un acteur majeur va émerger prochainement et que notre état sera au devant de la scène internationale. 

**Morihei Ueshiba** nous dit bien que: **l'échec est la voie du succès**.

Quand je vois le nombre de crash de sociétés aux États-Unis, je pense qu'on devrait accélérer pour avoir encore plus de chance de trouver de belles sociétés.

Ralentir le rythme fera aussi en sorte que nous ayons moins de chance de briller.

large_french_tech_chute.jpg

medium_french_tech_chute.jpg

small_french_tech_chute.jpg

thumbnail_french_tech_chute.jpg

french_tech_chute.jpg

L'écosystème startup français face aux défis : analyse de la crise, des success stories comme Qonto et Mistral, et pourquoi l'échec est peut-être nécessaire pour l'innovation.

La French-Tech en baisse de régime

Loin de moi, l'idée de lyncher un confrère qui a voulu bien faire en rédigeant un article sur le typage **Typescript**. Ce dernier a voulu partager une optimisation de code dans un article **Medium** afin de réduire l'impact d'une **PR** qui s'étendait sur plusieurs fichiers. J'ai d'autant plus peur quand je vois la centaine de commentaires qui acclament cet article, j'espère vraiment que ce sont des bots parce que das le cas contraire, on a du soucis à se faire sur nos projets ! Je rédige donc cet article afin de vous montrer une approche plus pratique.

Quelque part, je comprends le besoin initial, on a tous, la phobie du **merge conflict** quand on travaille dans une grosse équipe, donc on fait le maximum pour réduire l'impact.

Pourtant, son approche ne me parait pas judicieuse et je vais vous expliquer pourquoi.

<u>Disclaimer:</u> N'allez surtout pas le harceler dans les commentaires, je pense qu'il a voulu bien faire et aider la communauté. Malheureusement, son manque d'expérience peut coûter cher à terme si vous optez pour son approche.

Je ne vais pas revenir sur son état de code initial qui était justement ce qu'il cherchait à optimiser, mais directement vous montrer le résultat final après refacto.

### Voici le typage proposé

L'élémet qui nous intéresse, c'est la clé "reactions" dans le type **FinalResponse**.

```tsx
// FinalResponse.ts
import { Reaction } from './Reaction'

type AllowedReactions =
  | 'likes'
  | 'unicorns'
  | 'explodingHeads'
  | 'raisedHands'
  | 'fire'

export type ReactionMap = {
  [key in AllowedReactions]: Reaction
}

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: ReactionMap
}
```

Pourtant quand je lis cette approche, je trouve cela complexe et pas optimisé, la création d'un type supplémentaire **ReactionMap** me semble superflu. 

J'aurais procédé de la sorte:

```tsx
// FinalResponse.ts
import { Reaction } from './Reaction'

type AllowedReactions =
  | 'likes'
  | 'unicorns'
  | 'explodingHeads'
  | 'raisedHands'
  | 'fire'

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: Record<AllowedReactions, Reaction>
}
```

### Pourquoi privilégier un typage simple et lisible ? 

- Premièrement, il faut réduire au maximum le nombre de types intermédiaires (surtout quand on peut s'en passer)
- Et parce que lorsque l'on na moins de types à maintenir et que chacun de ces types est correctement utilisé, cela réduit le scope du projet et le rend simple.

J'applique avec beaucoup de ferveur l'approche de **Dijkstra** qui dit que <u>**la simplicité est un prédicat de la fiabilité**</u>. 

Ce n'est que lorsque vous manipulez des choses simples, que vous créez du code fiable, robuste!

N'essayez pas de produire quelque chose de confus et difficile à lire. Certains pensent que le code complexe est synonyme de maitrise, mais je suis persuadé qu'il reflète surtout une incompréhension de l'auteur.

large_ts_bad_type.jpg

medium_ts_bad_type.jpg

small_ts_bad_type.jpg

thumbnail_ts_bad_type.jpg

ts_bad_type.jpg

Simplifiez votre TypeScript : pourquoi l'utilisation de Record<K,V> est préférable aux types intermédiaires superflus pour un code plus maintenable et robuste.

Ne vous trompez pas de type

Souvenez-vous, il y a quelques mois je sortais un projet : [Versus-DB](https://versus-db.com), qui est une encyclopédie des manipulations pour les jeux de baston.
Initialement, j'avais sorti ce projet en 3 briques (sans compter la base de données):

- un serveur **Nextjs 14**
- un backend **Typescript**
- un serveur **Temporal.io**

Entre le front et le backend, j'ai mis en place un système d'encryption à la volée qui demande un décryptage côté front avec des clés spécifiques. Cela permet de ne pas exposer l'API.

Mais étant donné que je fais la maintenance seul, ce découpage est lourd à mettre à niveau. J'ai donc opté pour une approche monolithique afin de me faciliter la vie.

### Next 15

J'ai basculé sur **Next 15**, donc, voici la nouvelle architecture:

- Un serveur **Next.js 15**
- Un serveur **Temporal.io**

Et pour répondre à la question, quels sont les principaux changements ?
Sachez que dans mon cas ils concernent essentiellement 2 points :

- Les <u>routes params sont maintenant asynchrones</u> (api ou page)
- Les <u>cookies sont également asynchrones</u>

#### Routes params

```tsx
type GetUserParams = {
  params: Promise<{
    userId: string
  }>
}

export async function POST(req: NextRequest, { params }: GetUserParams) {
  try {
    const { userId } = await params
    ...
```

Comme on peut le voir, les params sont asynchrones et pour les récupérer il faut faire un **await**.

Donc si vous avez des routes params donc les dossiers comme ceci: **/resource/[id]/route.ts**, vous serez dans l'obligation de réécrire un peu de code.

#### Cookies

```tsx
import { cookies } from "next/headers"

export default async function MyPage() {
  const cookieStore = await cookies()
  const cookieConsent = cookieStore.get("cookieConsent")
  ...
```

Dans le cas contraire votre variable renverra une Promise et vous n'aurez aucun moyen de faire un **.get()** dessus.

### Quels sont les résultats

Moins de briques signifie moins de communication donc moins de latence.
Le **DOMContentLoad** a été drastiquement réduit:

![VSDB_resized.jpg](https://bo.dev-freelance.fr/uploads/VSDB_resized_b0bc959ddf.jpg)

Donc, un gain de perf non négligeable pour le projet qui gagne énormément en stabilité par la même occasion. J'ai aussi fait quelques optimisations sur le rendu static de certaines pages.

Je suis très satisfait de cette migration. Finalement elle est peu coûteuse et ramène beaucoup de performance, je pense un coefficient de 2 par rapport à avant.

large_versus-db-next15.jpg

medium_versus-db-next15.jpg

small_versus-db-next15.jpg

thumbnail_versus-db-next15.jpg

versus-db-next15.jpg

Migration Next.js 15 : passage d'une architecture fragmentée à une approche monolithique pour Versus-DB. Découvrez les changements clés et les gains de performance significatifs obtenus.

Versus-db sur Next 15

### Rappel sur l'intérêt de faire du React

On ne code pas en **React** parce que c'est un framework à la mode, parce que c'est simple ou compliqué, ou encore parce que c'est stylé. 

Le premier intérêt lorsque l'on utilise React, c'est que <u>les composants sont designés pour être réutilisables</u>, que <u>le code généré est optimisé</u> (dans ses cycles de render, dans sa génération HTML, etc...).

Avec l'avènement de **Next.js**, on a commencé à faire des pages où le rendu server-side permettait de préparer en amont le **DOM** (le résultat **HTML**) avant même que le front ait besoin d'interpréter le **JSX**. Cette approche a plusieurs avantages, une réduction notable du chargement de la page côté front (on va juste rafraîchir les composants et écouter les événements du **lifecycle**), mais aussi apporte des améliorations pour la **SEO**. 

En revanche, la plupart des projets **Next.js** où je suis intervenu avaient souvent un problème de conception : **les composants ne sont pas designés pour le server-side rendering**.

### L'approche React-Query

Il y a plusieurs façons d'exploiter Next.js sur les projets. Certains développeurs utilisent Next.js uniquement pour faire des requêtes vers des API, passent les réponses au client sous forme déshydratée (ou sérialisée) afin d'utiliser ensuite React-Query pour récupérer ce "cache" côté front.

```tsx
// Composant back
import { HydrationBoundary, QueryClient, dehydrate } from "@tanstack/react-query"

export const BackendComponent = async () => {
  const data = await fetch("http://api.weather.url/data")
  const json = await data.json()

  const queryClient = new QueryClient()
  queryClient.setQueryData(["weather-data"], json)
  
  return (
    <HydrationBoundary state={dehydrate(queryClient)}>
      <FrontendComponent />
    </HydrationBoundary>
  )
}

// Composant front
"use client"

import { useQuery } from "@tanstack/react-query"

export const FrontendComponent = () => {
  const { data: myData } = useQuery({
    queryKey: ["weather-data"],
    queryFn: () => fetch("http://api.weather.url/data").then((res) => res.json()),
    initialData: undefined
  })

  return (
    <div>
      {myData.map((item) => (
        <div key={item.id}>{item.name}</div>
      ))}
    </div>
  )
}
```

Dans cet exemple, le server side ne prépare pas le DOM, c'est bien le front qui va se charger de ça. En revanche il a passé les données au front pour éviter d'ajouter le temps de latence au moment du chargement côté navigateur. Dans certains cas, ce procédé permet de garder une opacité sur les appels API (empêcher l'exposition des clés, token etc...).

Pour autant, il n'y a aucune optimisation SEO dans cet exemple. Lorsque l'on va analyser le code source de la page au chargement, on constatera que les données passées à **React-Query** sont en fait un **JSON** qui passe dans le code source et qui sera ensuite parsé côté front.

### L'approche Server-Side Rendering

On peut essayer de rendre le DOM côté serveur pour éviter au front d'avoir à le faire de son côté et ajouter de la latence alors que les données sont déjà chargées. Et cette approche est aussi bénéfique pour le **SEO** du site, car le **DOM** a beaucoup plus de valeur pour le crawler que de la donnée brute dans un array.
Il est possible de procéder de la sorte :

Depuis un fichier serverSideAction.ts :


```tsx
"use server"

export const getDataFromServerSideAction = async () => {
  const data = await fetch("http://api.weather.url/data")
  const result = await data.json()
  return result
}

```

Dans la page:


```tsx
import ...

export const MyComponent = ({ item }: { item: any }) => {
  return <div>{item.name}</div>
}

export const BackendPage = async () => {
  const json = await getDataFromServerSideAction()

  return ( 
    <div>
      {json.map((item) => (
        <MyComponent key={item.id} item={item} />
      ))}
    </div>
  )
}
```

Dans ce cas, le composant sera rendu côté serveur.

### Ce qu'il faut savoir concernant les composants

J'utilise souvent les classes en **TypeScript** afin d'ajouter des méthodes (utilitaires, etc...) ou champs virtuels, clés camelCase etc... au lieu de manipuler directement les réponses API ou base de données.

Cependant, si vous procédez de la sorte, il est primordial de créer des méthodes de sérialisation afin de les rendre exploitables dans vos composants JSON.
En général, je crée la méthode statique **"fromDatabaseObject"** pour me rendre une instance de ma classe ou encore une méthode **"toDatabaseObject"** pour rendre un <u>plain object</u> au format base de données.

Le <u>plain object</u>, c'est l'ingrédient essentiel de vos composants afin qu'ils fonctionnent toujours en fullstack.

C'est à dire que vous ne devez passer en props, que des valeurs qui sont :
- des primitives (string, number, boolean...)
- des plain objects (un JSON)

Lorsque vous passez des classes avec des méthodes etc., vous ne pouvez pas render ce composant depuis le backend, ceci peut même lever une erreur !

### Le cas des données provenant du projet

Si vous voulez récupérer en server-side les données provenant du même projet, ne repassez pas par les API du serveur Next pour fetch. 
**Dans votre server-side action, appelez directement votre base de données.**

Dans le cas contraire, vous allez créer une espèce de boucle de latence qui repasse par du network alors que le projet se parle à lui-même. Dans ce cas, vous ne faites qu'ajouter de la latence inutilement.



large_react_design.jpg

medium_react_design.jpg

small_react_design.jpg

thumbnail_react_design.jpg

react_design.jpg

Découvrez comment créer des composants React fullstack puissants et réutilisables grâces à de simples règles et bonnes pratiques.

Comment designer ses composants React

Quand certains cherchent toujours, d'autres ont des postes pour ne rien faire.

Dernièrement je tombais sur [cet article](https://blog.stackademic.com/1-in-10-silicon-valley-engineers-are-ghost-engineer-earning-300k-for-doing-almost-nothing-474b667da09d) sur medium.

Un chercheur de la **Stanford Business School** nous parle de ces développeurs fantômes et d'après ses chiffres de performance provenant de **100 grandes sociétés** concernant **50 000 développeurs**.

D'après les chiffres, **10% d'entre eux produisent 2 code changes par mois**.

<u>Des métriques assez incroyables et peu flatteuses.</u>

Mais je tiens à partager mon expérience avec vous. Je pense qu'il faut prendre ces métriques avec des pincettes.

Effectivement je pense qu'une grosse partie de ces développeurs ne sont pas productifs, et ça ne devrait pas être difficile à démontrer.

En revanche, je sais aussi ce que c'est de travailler dans les grandes boîtes avec des flows et process répartis dans tellement d'équipes, que le process lui-même crée tellement d'inertie que de passer une modif, demande la validation de X personnes avant même de rendre possible le merge.

Après, attention, <u>on parle de merge, pas de commit ou de push continu</u>. **Car oui, si un développeur ne push rien, c'est certain, il ne fait pas grand-chose.**

C'est aussi pourquoi, **il faut faire les process les plus simples et éviter au maximum de s'engouffrer dans des organisations et process politiques** qui risquent de ralentir fortement votre capacité à sortir du code.

Je m'explique...

Il vous est peut-être arrivé de travailler dans des boîtes où on vous parle d'ownership sur des sujets. Que pour toucher à telle partie il faut la validation de X, que pour modifier telle autre partie, il faut la confirmation de Y, etc etc...

Je dirai que dans cette situation, **par design, votre entreprise n'est pas faite pour débiter des features et innover à grande vitesse**. Je suis même persuadé que le fait de laisser au maximum les droits à chacun (tout en continuant à faire de la review) permet d'aller plus vite, et aussi de s'affranchir d'avoir un unique référent par sujet.

Il faut donc recruter mieux et laisser plus de marge de manœuvre pour que ça marche efficacement.

Et je pense sincèrement, que lorsqu'il s'agit de technique, pour évaluer l'apport d'un développeur, il suffit de poser la question à ses pairs. Ce que les développeurs pensent de leur collègue en dit souvent long sur leur apport dans le projet.

large_dev fantomes.jpg

medium_dev fantomes.jpg

small_dev fantomes.jpg

thumbnail_dev fantomes.jpg

dev fantomes.jpg

Découvrez pourquoi 10% des ingénieurs de la Silicon Valley sont payés 300K$ pour "ne rien faire" et ce que cette réalité cache vraiment sur les processus d'entreprise.

Les développeurs fantômes

Hey les développeurs et développeuses, 👋

Aujourd'hui nous allons développer un composant **React** pour remplacer un composant **select** ou **radio**.

Dernièrement je vous parlais d'un composant **ReactJS** que j'ai designé de manière à rendre <u>plus pratique</u> un choix multiple de 3, 4 ou 5 items:

![cs2strats-after.gif](https://bo.dev-freelance.fr/uploads/cs2strats_after_f85135f9d7.gif)

Surtout dans une situation où on l'on peut mettre une icone ou une image pour un choix, cela rend les choses beaucoup plus simple à visualiser.

Pour réaliser ce composant, j'ai utilisé **React**, **React-hook-form**, **Tailwind** sur **NextJS 14**.

### Composants

Je commence par créer un composant _**CircleButton.tsx**_:

```typescript
export type CircleButtonProps = {
  children: React.ReactNode;
  onClick: () => void;
}

export const CircleButton = ({ children, onClick }: CircleButtonProps) => {
  return (
    <div
      className="w-28 h-28 bg-white border border-gray-200 rounded-full shadow dark:bg-gray-800 dark:border-gray-700 flex flex-col items-center justify-center cursor-pointer hover:bg-gray-300"
      onClick={onClick}
    >
      {children}
    </div>
  );
};

``` 

Ensuite, je crée  un composant _**CircleChoice.tsx**_:

```typescript
import { useState } from "react";
import { Control, Controller } from "react-hook-form";
import { CircleButton } from "./circleButton";
import cn from "classnames";
import styles from "./CircleChoice.module.css"

type Choice = {
  value: string;
  content: React.ReactNode;
};

export type CircleChoiceProps<T> = {
  fieldTitle: string;
  fieldName: string;
  control: Control<any>;
  choices: Choice[];
};

export const CircleChoice = <T,>({ fieldName, control, fieldTitle, choices }: CircleChoiceProps<T>) => {
  const [isOpened, setIsOpened] = useState(false);

  const radius = 120; 

  return (
    <div className="mb-6 relative flex flex-col items-center justify-center">
      <Controller
        control={control}
        name={fieldName}
        render={({ field }) => (
          <>
          <div 
            className="fixed top-0 left-0 w-full h-full bg-black opacity-50 z-10" 
            style={{ display: isOpened ? "block" : "none" }} 
            onClick={() => setIsOpened(false)}
          >
          </div>
          <div className="relative z-20">
            <CircleButton
              onClick={() => {
                setIsOpened(!isOpened);
                field.onChange(field.value);
              }}
            >
              {
              field.value ? 
                choices.find(choice => choice.value === field.value)?.content : 
                fieldTitle
              }
            </CircleButton>

            {isOpened && (
              <div
                className={`absolute inset-0 transition-all duration-500 scale-100`}
                onClick={() => setIsOpened(false)}
              >
                
                <div
                  onClick={() => setIsOpened(false)}
                  className="absolute w-12 h-12 bg-gray-300 border border-gray-400 rounded-full shadow dark:bg-gray-800 dark:border-gray-700 flex flex-col items-center justify-center cursor-pointer hover:bg-gray-400"
                  style={{
                    transform: `translate(${radius / 4}px, ${radius / 4}px)`,
                  }}>
                    ✖
                </div>

                {choices.map((choice, index) => {
                  return (
                    <div
                      key={choice.value}
                      className={cn("absolute transition-transform duration-500", 
                        styles[`circle-button-anim-${choices.length}-${index}`]
                      )}
                    >
                      <CircleButton
                        onClick={() => {
                          field.onChange(choice.value);
                          setIsOpened(false);
                        }}
                      >
                        {choice.content}
                      </CircleButton>
                    </div>
                  );
                })}
              </div>
            )}
          </div>
          </>
        )}
      />
    </div>
  );
};

```

Et enfin j'ajoute mon module pour le CSS dans un fichier _**CircleChoice.module.css**_:

```CSS
@keyframes moveAway-3-0 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(0px, -120px);
    opacity: 1;
  }
}

@keyframes moveAway-3-1 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(103.92px, 60px); 
    opacity: 1;
  }
}

@keyframes moveAway-3-2 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(-103.92px, 60px); 
    opacity: 1;
  }
}

.circle-button-anim-3-0 {
  animation: moveAway-3-0 0.5s ease-out forwards;
}

.circle-button-anim-3-1 {
  animation: moveAway-3-1 0.5s ease-out forwards;
}

.circle-button-anim-3-2 {
  animation: moveAway-3-2 0.5s ease-out forwards;
}

@keyframes moveAway-4-0 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(120px, 0px); 
    opacity: 1;
  }
}

@keyframes moveAway-4-1 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(0px, 120px); 
    opacity: 1;
  }
}

@keyframes moveAway-4-2 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(-120px, 0px);
    opacity: 1;
  }
}

@keyframes moveAway-4-3 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(0px, -120px); 
    opacity: 1;
  }
}

.circle-button-anim-4-0 {
  animation: moveAway-4-0 0.5s ease-out forwards;
}

.circle-button-anim-4-1 {
  animation: moveAway-4-1 0.5s ease-out forwards;
}

.circle-button-anim-4-2 {
  animation: moveAway-4-2 0.5s ease-out forwards;
}

.circle-button-anim-4-3 {
  animation: moveAway-4-3 0.5s ease-out forwards;
}

@keyframes moveAway-5-0 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(120px, 0px); 
    opacity: 1;
  }
}

@keyframes moveAway-5-1 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(37.08px, 114.43px); 
    opacity: 1;
  }
}

@keyframes moveAway-5-2 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(-97.08px, 70.63px); 
    opacity: 1;
  }
}

@keyframes moveAway-5-3 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(-97.08px, -70.63px); 
    opacity: 1;
  }
}

@keyframes moveAway-5-4 {
  from {
    transform: translate(0px, 0px);
    opacity: 0;
  }
  to {
    transform: translate(37.08px, -114.43px); 
    opacity: 1;
  }
}

.circle-button-anim-5-0 {
  animation: moveAway-5-0 0.5s ease-out forwards;
}

.circle-button-anim-5-1 {
  animation: moveAway-5-1 0.5s ease-out forwards;
}

.circle-button-anim-5-2 {
  animation: moveAway-5-2 0.5s ease-out forwards;
}

.circle-button-anim-5-3 {
  animation: moveAway-5-3 0.5s ease-out forwards;
}

.circle-button-anim-5-4 {
  animation: moveAway-5-4 0.5s ease-out forwards;
}
```

Enfin, à l'utilisation, j'ajoute dans mon composant le bout de code suivant:

```typescript
const VEHICLES = {
  "car": "Voiture",
  "plane": "Avion",
  "train": "Train",
  "bus": "Bus"
}

// ...

<CircleChoice 
          fieldName="vehicle" 
          control={control} 
          fieldTitle="Choix du véhicule" 
          choices={Object.entries(VEHICLES).map(([key, value]) => ({ 
            value, 
            content: (<>
              <img 
                src={`/vehicles/${value.toLowerCase()}.png`} 
                alt={key} className="w-10 h-10 mb-2" />
              <span className="text-sm">{key}</span>
            </>) 
          }))} 
        /> 
```

Voilà, c'est assez simple et efficace je trouve, bon code à vous ! 😉

Je vous laisse personnaliser cela selon vos besoins.

medium_component_react_select.jpg

small_component_react_select.jpg

thumbnail_component_react_select.jpg

component_react_select.jpg

Découvrez comment créer un composant React innovant pour remplacer select/radio, avec React-hook-form, Tailwind, et NextJS. Intuitif et personnalisable ! 🚀

Composant Circle Choice ReactJS

### Qué pasa?

J'étais en train de bosser sur le **Mac** du boulot, et je cherchais à build mon code. Mais là, **Docker Desktop** en a décidé autrement.

Vous connaissez **Docker Desktop** ?

Ceux qui sont sous **Linux** doivent se demander qu'est-ce que c'est que ça ? Mais sous **Mac** il n'y a pas énorméments d'alternative à l'installation de **Docker** (de manière officielle je parle).

Ils offrent désormais un package qui propose une interface pour environnement graphique, et ont packagé le tout dans une fenêtre avec des menus pour voir les _logs_, les _images_, les _volumes_, etc... Ils ont aussi embed les commandes **docker-compose**. Bref du graphique quoi et un peu d'utilitaires, mais entre nous, que du superflu, on peut très bien s'en passer.

Pour info, ça ressemble à ça:

![docker-desktop-hero.png](https://bo.dev-freelance.fr/uploads/docker_desktop_hero_52b474c2f3.png)

**Docker** part d'une base communautaire et de base, il n'y a rien de payable ou d'obligatoire, sauf si on a des besoins spécifiques d'entreprise etc...

Mais voilà que pour mon build, je me retrouve coincé, car ma fenêtre **Docker Desktop**, a décidé de se blur toute seule et m'afficher un message comme quoi j'aurais dépassé un quota de licence d'entreprise. Alors que je n'ai jamais rien demandé de la sorte. 

A partir de là, qu'est-ce que je suis bien sensé faire ? 

Même si je veux payer une licence, tout est figé, je ne peux absolument <u>RIEN</u> faire ! et ce n'est pas une blague, je n'ai qu'un message, rien d'autre. 

Je ferme, je relance, pareil.

Je désinstalle, je réinstalle, pareil.

Je désinstalle, je clean, je vire absolument tout via terminal, pareil.

Ok ben au suivant alors, si on ne peut plus bosser, **ça dégage !**

Mais par quoi peut-on bien remplacer **Docker Desktop** sur un **Mac** aujourd'hui ?

### Colima, le remplaçant de docker desktop à l'ancienne

Je suis passé sur [colima](https://github.com/abiosoft/colima).

![colima.png](https://bo.dev-freelance.fr/uploads/colima_5201293c7e.png)

Pour l'utiliser, c'est très simple il y a 2 commandes à savoir:

```
# lancer colima avant toute commande docker
colima start 

# stopper en cas de besoin
colima stop
```

Pour utiliser **docker** et **docker-desktop** ensuite je les ai réinstallé à partir de **python pip**. 

Truc important à savoir, c'est que lorsque l'on fait un **colima stop**, il drop tous les containers. Il faudra les recréer si vous relancez **colima** ensuite (important à savoir si vous travaillez sur de multiples projets).

Voilà, article très bref, mais je voulais partager ma frustration tout en vous proposant une alternative s'il vous arrive la même chose.

Bon code !



large_docker_desktop.jpg

medium_docker_desktop.jpg

small_docker_desktop.jpg

thumbnail_docker_desktop.jpg

docker_desktop.jpg

Docker Desktop bloqué sur Mac ? Découvrez comment Colima peut sauver votre workflow de développement. Alternative gratuite et efficace sans licences restrictives. Guide simple inclus.

Docker Desktop sur mac, ça dégage !

Tout d'abord, laissez-moi vous donner un peu de contexte concernant mon point de vue sur **les architectures micro-services**. Je développe depuis presque 17 ans en environnement professionnel, j'ai passé énormément de temps sur des projets (**monolitiques** ou **micro-services**). Depuis presque 7 ans, le micro-service est mon quotidien de développeur, ayant travaillé sur des projets à grande échelle, dans une filiale de **TripAdvisor**, chez **Engie** ou chez **Webedia**. J'ai eu le temps de me familiariser avec cette architecture, voici un conseil ou une observation qui pourra vous faire gagner beaucoup de temps et d'argent.

Lorsque l'on découpe un projet en micro-services, le plus souvent on va donner à chacun de ces services un domaine métier. Sa responsabilité sera de gérer la couche data et logique de cette brique métier. 

Par exemple: un service **Users** va gérer les utilisateurs, la persistance de ces derniers etc., de même pour un service **Products**, il va gérer les produits et leur persistance etc.

Lorsque l'on travaille en micro-services, on va souvent avoir des processus qui sont cross-services, une opération va débuter sur une brique puis finir sur une autre. Peu importe qu'on utilise un **orchestrateur**, une **message-queue** ou autre, il faut parcourir toute la chaîne.

Dans ce cas, les développeurs mettent souvent en place des tests **e2e** à partir d'outils comme **Jest**, **Playwright** ou **Cucumber** qui sont censés dérouler le workflow d'un bout à l'autre.

Pour ce faire, on s'appuie souvent sur des **mocks** lors de ces processus.
Rares sont ceux qui font réellement du test de bout en bout avec la base de test, des jeux de données (fixtures) dédiés à ces mêmes tests etc.

**Et mocker chaque service depuis une autre brique peut amener plusieurs problèmes:**
- Un état faux comparé au service réel car un mock est un état statique qui peut rapidement devenir obsolète (dès que le service est mis à jour).
- Des tests positifs alors qu'ils devraient être en erreur.
- Ceci engendre une détection tardive des bugs.
- Incohérence entre les environnements.
- Connaissance fragmentée (les développeurs manipulent des éléments dont ils ignorent la logique métier complète s'ils ne sont pas **owners**).

## L'ownership du mock

De la même manière qu'on a réparti les domaines métier dans des briques, la responsabilité du **mock** devrait revenir à la brique **owner** de ce domaine. C'est-à-dire qu'il n'y a aucun sens à ce que le **mock** **Users** se trouve dans une brique **Products** et vice-versa.

### Pourquoi faut-il rapatrier les **mocks** et **fixtures** dans leur domaine respectif ?

La réponse est très simple, lorsque l'on met à jour une brique, on va rarement aller chercher dans toutes les autres où sont les dépendances et où on doit impacter les modifications afin que toute la chaîne reste d'équerre. 

Lorsque l'on intervient sur une brique, admettons que ce soit Users, on va devoir passer les tests au moins sur cette brique, le linter, la compilation **TypeScript** etc. Ce qui signifie que c'est l'endroit idéal pour y mettre les **mocks** et **fixtures** car ces derniers seront mis à jour (par obligation) car ils ne respecteraient plus les règles de typage.

## Comment propager ces changements ?

Je pense que chaque micro-service devrait fournir un endpoint **/api/tests/...** qui fournirait des endpoints de tests sur des features. Quitte à renvoyer des données statiques (fixtures). 

Ce path devrait être le miroir de tous les autres paths de **/api/...**

Les équipes pourront choisir d'interagir ou non avec une vraie base mais cela permettrait d'avoir des tests avec un jeu de données à jour dans 100% des cas.

## Quid de la production

En production il ne nous reste plus qu'à mettre un middleware **404** sur les paths **/api/tests/...**  en fonction d'une condition sur **NODE_ENV**.

Mais ceci nous permettrait d'avoir des environnements de **Staging** ou **UAT** bien plus robustes et permettra de détecter des bugs bien plus tôt. 

Aujourd'hui, lorsque l'on déploie une mise à jour sur une brique unique, on oublie souvent que cela impacte les autres projets et de nombreux edge bugs se produisent dans ces cas. 

La CI pourrait alors redéclencher une chaîne de tests complète, cross-service et empêcher ce scénario catastrophe.

large_e2e_tests.jpg

medium_e2e_tests.jpg

small_e2e_tests.jpg

thumbnail_e2e_tests.jpg

e2e_tests.jpg

Optimisez vos tests E2E en architecture micro-services : comment rapatrier les mocks à leur service d'origine pour des tests plus fiables et maintenir la cohérence API.

Comment organiser ses tests E2E en architecture Micro-Service

Bienvenue sur mon blog où je parle de tech, de code, d'actu, de freelancing et de plein d'autres choses.   

<u>Qui suis-je ?</u>  
J'ai passé plus de **20 ans à coder**, j'ai appris énormément de choses au fil du temps et des transformations dans la tech. Aujourd'hui, je continue d'apprendre et de découvrir dans ce monde fascinant qu'est la programmation.   

J'ai été **Lead Dev** sur des projets que vous avez peut-être déjà vus, **lauréat de plusieurs concours d'innovation**, **enseignant universitaire** et **formateur**.   

<u>Je peux :</u>  
- Résoudre une de vos problématiques  
- Accélérer la livraison de vos projets  
- Automatiser un processus que vous faites manuellement aujourd'hui  
- etc...  

Si vous recherchez un passionné, une personne motivée, un bosseur pour réaliser votre projet, n'hésitez pas à me solliciter.  

Nous pouvons déjà estimer votre projet (en temps, en budget), c'est gratuit !
