
Rien de très technique aujourd'hui...

> "Rooooooh !"  
— Les lecteurs qui n'ont pas cru le titre

... puisque nous allons parler du développement en général. Du métier de développeur/développeuse surtout.

Récemment, j'ai posté quelque chose de très court sur le fait que j'en ai marre de voir **MongoDB** (une base de donnée non-relationnelle) sur des projets qui sont **pensés tout en relationnel**, et les dégâts qu'une telle décision peut engendrer.

> "Toi tu cherches les ennuis..."  
— Un lecteur qui sait

Ce sujet a provoqué des débats intéressants (mais pas que).

Et au fil des jours, j'ai commencé à réfléchir...

> "Toi tu cherches VRAIMENT les ennuis..."  
— Un lecteur parti chercher des pop-corns

## Un simple constat

Je ne pense pas être le seul à pouvoir dire que sur le terrain, je croise surtout des projets en relationnel (**MySQL/MariaDB** mais pas que). 

Et il semble que le [sondage annuel de StackOverflow](https://survey.stackoverflow.co/2022/) va dans ce sens. Ci-dessous, les stats pour 2022 :

- Professionnels

![StackOverflow Dev Survey results 2022 1](/images/blog/posts/so-dev-survey-2022-pro.webp)

- Apprenants

![StackOverflow Dev Survey results 2022 2](/images/blog/posts/so-dev-survey-2022-learn.webp)

Vous voyez le problème ?

Chez les pros, **MongoDB arrive cinquième** derrière **quatre systèmes relationnels**.

Chez les apprenants, il est **second**.

Et vous pensez que c'est parce que les élèves en formation ont une meilleure vision du futur ?

Non, c'est juste les formations et les tutoriels très orientés stack **MERN** (**M**ongoDB **E**xpress **R**eact **N**ode). Le monde professionnel, lui, est surtout sur des bases de données relationnelles.

Comme l'auront deviné les plus malins, le problème n'est pas **MongoDB** (qui fait très bien son travail), mais le choix étrange de certains de se tourner **uniquement** vers un système de base de données, alors que beaucoup de projets utilisent en réalité **une conjugaison de relationnel et de non-relationnel**.

## "Leave Mongo alone!"

Et c'est là que j'aimerais en venir à un sujet plus profond...

> "Scaphandre ou tuba ?"  
— Un lecteur boute-en-train

... notre **affect** par rapport aux technologies, et ce qu'il cache.

Quand j'ai lancé le sujet sur les réseaux, j'ai eu beaucoup de réactions.

Certains défendaient l'usage de Mongo, d'autres déploraient sa surutilisation... mais tous étaient d'accord que chaque système, relationnel ou non, a ses forces et ses faiblesses, et qu'il faut **savoir astucieusement utiliser les deux**, comme décrit plus haut.

Et puis j'ai eu un développeur très remonté, choqué que je _stigmatise_ sa technologie préférée (ce sont ses mots). Il m'accusait aussi de faire de la désinformation pour les débutants... Ça s'est mal terminé, le gars allant jusqu'à insulter les autres personnes qui avaient commenté...

Après l'avoir bloqué (parce qu'à un moment, ça suffit), j'ai commencé à remarquer qu'on était nombreux comme lui. Et je m'inclus dans le lot, car il fut un temps, **moi aussi j'étais fan des technologies que j'utilisais**.

## La peur de l'inconnu

1. J'ai été fan du langage **Ruby**.

2. J'ai été fan de **ReactJS** contre Angular.

3. J'ai été fan de **LESS** contre Sass.

Le point commun dans ces trois cas ? **Je ne connaissais que ces technologies**.

1. Ruby : **mon premier langage**.

2. ReactJS : **on m'a embauché pour travailler avec** quand j'étais junior.

3. LESS : parce qu'on utilise des `@` comme en Ruby (ce n'est pas une blague) ET parce qu'on m'a fait bosser dessus en premier.

Et puis avec le temps, j'ai commencé à sortir de ma **zone de confort**.

1. J'ai appris les langages PHP, Python, j'ai commencé à créer des projets ces langages et j'ai fini par former des gens dessus.

2. J'ai découvert Vue, Svelte, et finalement **ReactJS me semble moins intéressant**.

3. J'ai utilisé Sass parce que **personne n'utilise LESS** (ne dites pas le contraire !), et finalement j'ai repris le chemin du CSS natif (avec les modules CSS tout de même).

## Juste un outil, bébé

Pour autant, je n'ai pas lâché ReactJS/NextJS (je mets ces deux ensemble).

Pourquoi ? Parce que **mes clients me paient pour travailler avec**. Et parce que je les maîtrise plutôt bien depuis le temps.

Et je les utilise aussi quand je commence un nouveau projet client : **je ne vais pas pénaliser mes clients parce que je veux essayer un nouveau truc qui me plaît**.

Et ils trouveront plus facilement des devs React pour reprendre le projet si besoin.

C'est ça, **être pro**.

Lancer des confettis à chaque fois que ReactJS/NextJS annonce un nouveau hook, défendre le fait de jeter son code parce que les devs de ces outils ont (encore) décidé de tout changer, vénérer chaque mot qui sort de la bouche de **Dan Abramov**...

Ça, c'est **être fan**.

Et vous ? Êtes-vous développeur ? Ou juste un fan ?

> PS : Je précise parce qu'il le faut : je n'ai rien contre **Dan Abramov** ni contre **MongoDB**, que j'utilise très souvent.  
> ...  
> MongoDB, pas Dan...


Être fan


Il y a quelques jours, j'avais une session avec un étudiant chez **OpenClassrooms** pour un projet d'intégration de maquette, et je lui ai expliqué un concept essentiel en frontend : le "**zoning**".

> "Cessons ces anglicismes !
![Zonard](/images/blog/posts/fr/zoning-zonard.webp)
On dit **zoner** !"  
— Un galliciste remonté

...

## Le concept

Le **zoning** consiste à délimiter des **zones**...

> "D'où le nom."  
— Un lecteur perspicace

... des zones donc, basées sur les différents composants visuels de votre design.

Je vous donne un exemple de ce que ça donne avec le design de **LinkedIn**.

![Base Linkedin](/images/blog/posts/fr/zoning-linkedin-desktop-base.webp)

## Délimiter les blocs principaux

Procédons à un premier découpage des **blocs principaux** :

![Découpage des blocs principaux](/images/blog/posts/fr/zoning-linkedin-desktop-main-blocks.webp)

Le découpage est plutôt simple :

- un **header** en haut avec une barre de recherche et des icones de navigation
- un **corps de page** découpé verticalement avec
  - le **fil d'actualité** au centre
  - deux **volets latéraux**

Le zoning permet d'identifier les blocs **similaires**. Par exemple, header et corps de page semblent faire la même largeur. On serait tenté de les mettre dans un même conteneur.

Mais il y a un **piège** : _la barre blanche derrière le header_. À cause de cette barre, le header prend **toute la largeur de l'écran**.

> "Ciel ! Mais que faire ?!"  
— Un lecteur désemparé

Il suffit d'appliquer **une même classe CSS** qui se chargera de donner une largeur maximale et des marges automatiques au corps de la page ET à **un conteneur invisible dans le header** (pointillés rouges).

![Conteneur invisible](/images/blog/posts/fr/zoning-linkedin-desktop-inner-container.webp)

Le code :

```html
<header>
    <div class="inner-container"></div>
</header>

<main class="inner-container"></main>
```

```css
.inner-container {
    max-width: 1128px;
    margin: 0 auto;
}
```

Le zoning permet d'identifier ce genre de difficultés avant que vous ne perdiez du temps dessus en codant.

## Délimiter les blocs secondaires

Une fois que vous avez procédé au découpage des blocs principaux, vous pouvez aller à l'intérieur de chacun d'entre eux et procéder à un découpage plus détaillé.

Voici un exemple pour le header :

![Découpage header](/images/blog/posts/fr/zoning-linkedin-desktop-header.webp)

On peut y voir plusieurs zones et sous-zones :

- Logo
- Barre de recherche
- Menu de navigation (1)
  - Icone + Texte
- Menu de navigation (2)
  - Icone + Texte

On remarquera que bien qu'il y ait un séparateur, les éléments en violet et jaune contiennent des blocs similaires composés d'une icône et d'un texte.

On pourra peut-être décider d'en faire un seul bloc; avec un séparateur avant les deux _items_ à droite ?

## Une approche atomique

En plus de vous guider dans votre intégration du design, le zoning présente comme avantage de vous pousser à **vous concentrer sur une zone** et la terminer avant de passer aux suivantes.

Il m'arrive par exemple de faire le header et le footer avant d'insérer le corps de la page. Ou le corps avant le header et le footer.

Le zoning me permet dans ces cas de voir quels blocs peuvent être avancés indépendamment du reste (c'est souvent le cas pour le header ou le footer).

## Aller plus loin

Le zoning s'applique aussi si vous faites du **no-code**. La plupart des outils no-code vous obligent à passer par des lignes et des colonnes. Il faut donc penser "blocs".

Un exercice très intéressant consiste à découper un site au hasard avec un schéma similaire à celui que j'ai fait, pour voir comment le design est pensé.

Vous pouvez ensuite inspecter chaque élément et voir les techniques CSS qui ont été appliquées pour tel ou tel effet.

Le zoning est un des **fondamentaux du frontend**. Que vous soyez junior ou backend secrètement intéressé par ces questions, le plus tôt vous l'adopterez, le plus vite vous progresserez.

> "Mince ! On est repérés ! Replions-nous !"  
— Des devs backend infiltrés

Je ferai prochainement un article sur le zoning et le design responsive.

---

_Cet article est une version remaniée d'[un de mes posts sur LinkedIn](
<https://www.linkedin.com/posts/daniel-orchanian_frontend-css-design-activity-7056514694794108928-drx->). Suivez-moi si ce type de contenu vous intéresse._


Utiliser le Zoning pour votre design


Parlons un peu de **gestion de projet**.

Je voudrais partager avec vous une petite méthode de gestion des tâches. Le but n'est pas de vous donner une recette, mais de vous aider à réfléchir sur votre façon de travailler.

La méthode que je vais vous exposer ici est transposable dans tous les outils existants : tableau Kanban, check-lists, etc.

## L'idée de base

Ces derniers temps, je me suis surpris à utiliser une organisation similaire sur plusieurs de mes projets de développement.

En gros, je sépare mes tâches en **3 lots** :

1. **Fonctionnalités (orange)** : ce dont l'appli a besoin, sans quoi elle est incomplète d'après les spécifications.

2. **Bugs (rouge)** : ce qui plante et qu'il faut régler.

3. **Améliorations (vert)** : ce qu'on peut améliorer, que ce soit en terme de fonctionnalités ou juste une refonte de code ici ou là.

## Gérer les priorités

Les tâches **orange*** (fonctionnalité) ont la priorité. C'est grâce à elles que je mesure l'avancée réelle du projet. Viennent ensuite les **rouges** (bugs). Et enfin les **vertes** (améliorations).

- Parfois, je suis d'humeur à faire du débogage et je vais prendre 1 ou 2 rouges _sur lesquelles j'aurai réfléchi_, et que je pense pouvoir résoudre. Si j'y passe trop de temps, je reporte. On verra plus tard.

- D'autres fois, je vais prendre une verte, et améliorer tel ou tel aspect du projet, si c'est rapide à faire.

## Grouper les tâches similaires

Mais souvent, je vais me retrouver avec une tâche orange, une rouge et deux vertes qui touchent à la même partie de code. Je les déplace dans mes tâches en cours et je peux au cours d'une même session :

- coder une fonctionnalité

- régler un petit bug que j'avais laissé de côté

- et améliorer deux points sur une fonctionnalité liée.

Une session **thématique** en quelque sorte.

## Une gestion des tâches optimisée

Le plus important dans ce système, c'est qu'on relativise vraiment les tâches **optionnelles** (les vertes), qui font souvent perdre plus de temps sur un projet qu'elles ne produisent de résultats.

- Si j'ai une deadline, elles vont tranquillement attendre. Priorité aux orange* et rouges.

- Si j'ai un peu de temps, je les regroupe avec les autres au cours d'une session (voir plus haut).

- Si j'ai VRAIMENT le temps (projet perso par exemple), je travaille exclusivement sur les vertes (pour me détendre).

Avez-vous un système similaire ?

> *Non, la couleur orange ne s'accorde pas au pluriel (ni au féminin mais ça ne se voit pas).

---

_Cet article est une version remaniée d'[un de mes posts sur LinkedIn](
<https://www.linkedin.com/posts/daniel-orchanian_parlons-un-peu-de-gestion-des-t%C3%A2ches-je-activity-7052535954703564800-qMuu>). Suivez-moi si ce type de contenu vous intéresse._


Trier et prioriser vos tâches


_Précédemment sur le blog, nous avons vu comment utiliser `Array.sort()` pour ordonner des listes de chaînes de caractères ou de nombres. [La partie 1 est ici](/blog/javascript-sort-2) si vous l'avez manquée._

Pour résumer, on avait vu que :

- `["d", "b", "c", "a"].sort()` rangeait les textes par ordre alphabétique : `["a", "b", "c", "d"]`

- `[100, 5, 38, 1, 3].sort()` rangeait les nombres par ordre alphabétique : `[1, 100, 3, 38, 5]` (et c'est n'importe quoi)

- `[100, 5, 38, 1, 3].sort((a, b) => a - b)` rangeait les nombres par ordre numérique : `[1, 3, 5, 38, 100]` (ouf).

> Si vous n'avez rien compris aux deux derniers éléments, allez lire la partie 1 et revenez.


## Le comportement trouble des objets

Beaucoup de tutoriels terminent leur explication de `sort` en présentant `(a, b) => a - b` comme solution et passent à la suite. Et quand le jeune développeur se retrouve avec **de vraies données à classer** (des objets avec des propriétés), il se retrouve bien embêté.

> "Me voilà bien embêté..."  
— Un jeune développeur

Logiquement, en appliquant la solution passée aux **propriétés** des objets, on devrait avoir une solution comme suit : `(a, b) => a.truc - b.truc`.

Essayons d'appliquer cela à notre tableau `users`. Un coup avec le nom, un coup avec l'âge.

```js
const users = [
    { name: "Raoul", age : 28 },
    { name: "Bob", age : 22 },
    { name: "Alice", age : 26 },
];

// Rangement par nom
users.sort((a, b) => a.name - b.name);
console.log(users); // => [{ age: 28, name: "Raoul" }, { age: 22, name: "Bob" }, { age: 26, name: "Alice" }]

// Rangement par âge
users.sort((a, b) => a.age - b.age);
console.log(users); // => [{ age: 22, name: "Bob" }, { age: 26, name: "Alice" }, { age: 28, name: "Raoul" }]
```

On constate quelque chose de suprenant : **le classement par âge fonctionne, mais pas celui des noms !**

La raison est toute simple : l'opération `a.truc - b.truc` a du sens avec des nombres, mais **pas avec des chaînes de caractères**.

En fait, je vais être honnête : utiliser la soustraction `a - b` ou `b - a` est juste un **raccourci**. En soi, cette solution n'a de sens que si on comprend comment fonctionne vraiment la fonction de comparaison.


## Le réel fonctionnement des fonctions de comparaison

En fait, les fonctions de comparaison utilisées dans la méthode `sort()` ont un fonctionnement un peu particulier, qu'on va résumer comme suit :
- si **a vient avant b**, on renvoie **-1**
- si **a vient après b**, on renvoie **1**
- s'ils sont **au même niveau**, on renvoie **0**.

JavaScript va ensuite se charger de ranger les éléments par rapport à ces résultats : **un rapport négatif entre a et b signifie "a vient avant b", un rapport positif signifie l'inverse, et un rapport d'égalité signifie que a et b seront classés au même rang**.

Traduit en code :

```js
function compare(a, b) {
    if (a < b) return -1;
    if (a > b) return 1;
    return 0;
}
```

> Cet extrait de code utilise des **if monolignes** et des **early return**. J'explique ces astuces dans [cet autre article](/blog/code-court-vs-lisible-refactorisation).

Ainsi, concrètement, pour ranger nos users selon leur nom :

```js
// Rangement par nom
users.sort((a, b) => {
    if (a.name < b.name) return -1;
    if (a.name > b.name) return 1;
    return 0;
});
console.log(users); // => [{ age: 26, name: "Alice" }, { age: 22, name: "Bob" }, { age: 28, name: "Raoul" }]
```

Notons que si la soustraction entre chaînes de caractères est un non-sens, la comparaison fonctionne bel et bien. JavaScript est tout à fait capable de comprendre que `"a" < "b"`, et `"b" < "c"`.


## La sombre verité

> "Mais alors, pourquoi ça marche avec la soustraction quand on travaille avec des nombres ?"

Je vais me citer moi-même.

> JavaScript va ensuite se charger de ranger les éléments par rapport à ces résultats : **un rapport négatif entre a et b signifie "a vient avant b", un rapport positif signifie l'inverse, et un rapport d'égalité signifie que a et b seront classés au même rang**.  
— Daniel Orchanian, auteur, in **Quelques lignes plus haut**

En fait, les valeurs -1 et 1 sont purement **arbitraires**. Ces valeurs fonctionnent elles aussi :

```js
// Rangement par nom
users.sort((a, b) => {
    if (a.name < b.name) return -10000;
    if (a.name > b.name) return 0.0001;
    return 0;
});
console.log(users); // => [{ age: 26, name: "Alice" }, { age: 22, name: "Bob" }, { age: 28, name: "Raoul" }]
```

Tout ce que JavaScript attend, c'est **un nombre négatif, un nombre positif ou zéro**.

Or :
- si **a est inférieur à b**, a - b sera forcément **inférieur à 0**.  
- si **a est supérieur à b**, a - b sera **supérieur à 0**.  
- et s'ils sont égaux, **a - b = 0**.

CQFD.


## Tout s'explique !

Vous comprenez maintenant quand je vous disais que la solution de la soustraction n'était qu'un **raccourci** ? Et pourquoi ça ne fonctionne **qu'avec des nombres** ?

![La boucle est maintenant bouclée](/images/blog/posts/vador-boucle.png)

Le plus intéressant dans tout cela, c'est qu'on peut **coder son propre algorithme de rangement** (par couleur, taille, etc.).

On peut écrire ce qu'on veut dans la fonction de comparaison du moment qu'on renvoie -1, 1 ou 0 !

> Vous désirez en apprendre plus ? Je donne aussi des **cours particuliers** (de programmation, pas de maths). [Le premier cours est offert !](/learn)

À bientôt pour une autre explosion de cerveau.


Maîtriser les arcanes de la méthode sort.

Utiliser sort en JavaScript (2)


Parlons un peu **tableaux** aujourd'hui.

> — Van Gogh était un génie !  
> — Je parle de listes, ou **arrays**...  
> — ???  
> — Ce truc : `[a, b, c]`...  
> — Aaaaaaaaaah !

Maintenant que vous êtes tous réveillés, on va examiner un petit souci courant dans la vie d'un développeur : **ordonner une liste** avec JavaScript. Et c'est moins simple qu'il n'y paraît.

Pour bien faire le tour du problème, je vais utiliser trois tableaux/arrays/listes :

- un tableau _fruits_, contenant des **chaînes de caractères**
- un tableau _numbers_, contenant des **nombres**
- un tableau _users_, contenant des **objets clé-valeur**.

```js
const fruits = ["pêche", "pomme", "poire", "abricot"];
const numbers = [9, 3, 1000, 56, 1, 5];
const users = [
  { name: "Raoul", age: 28 },
  { name: "Bob", age: 22 },
  { name: "Alice", age: 26 },
];
```

Allez, place à l'article !


## À la découverte de la méthode sort()

En JavaScript, on peut utiliser la méthode `Array.sort()` sur n'importe quel tableau de la façon suivante :

```js
const fruits = ["pêche", "pomme", "poire", "abricot"];

fruits.sort();

console.log(fruits); // => ["abricot", "poire", "pomme", "pêche"]
```

Ta-daaam ! La liste est **classée par ordre alphabétique**.

> Attention, la méthode `sort()` **agit directement sur le tableau**. Elle ne crée pas une copie de celui-ci.

Et là, vous me demanderez :

> "Mais... pourquoi sortir un article si le langage fait ça de base ?"  
> — Un lecteur qui croit que je n'ai que ça à faire

Essayons de reproduire notre exemple **avec des nombres** cette fois :

```js
const numbers = [9, 3, 1000, 56, 1, 5];

numbers.sort();

console.log(numbers); // => [1, 1000, 3, 5, 56, 9]
```

> "Euh... keskispass ?!"

En fait, c'est assez particulier de JavaScript : la méthode `sort()` procède à **un rangement par ordre alphabétique même avec les nombres** !

> "Un langage de clampins."  
> — Les développeurs Ruby et Python lisant des articles JavaScript en cachette

Heureusement, il existe une solution : introduire **une fonction de comparaison**.


## Utiliser une fonction de comparaison

La méthode `sort()` accepte en argument une fonction de comparaison. Cette fonction utilise deux arguments, qu'on appellera `a` et `b` selon l'usage.

```js
const numbers = [9, 3, 1000, 56, 1, 5];

// Fonction de comparaison
const compare = function (a, b) {
  return a - b;
};

numbers.sort(compare); // On utilise la fonction compare ici

console.log(numbers); // => [1, 3, 5, 9, 56, 1000]
```

Bien entendu, il est possible de placer la fonction directement dans `sort()` sans avoir à la nommer :

```js
numbers.sort((a, b) => a - b);
console.log(numbers); // => [1, 3, 5, 9, 56, 1000]
```

Et si on veut les nombres en ordre décroissant, il suffit d'inverser a et b :

```js
numbers.sort((a, b) => b - a);
console.log(numbers); // => [1000, 56, 9, 5, 3, 1]
```

![Magique](/images/blog/posts/magic.gif)

> "Trop cool ! Merci Daniel ! À la prochaine !"  
— Un lecteur pressé

**PAS SI VITE !**

Vous ne voulez pas en savoir plus ? Et notre **tableau d'objets** ?

_Et les lecteurs attendirent longtemps, très longtemps avant de savoir pour le tableau d'objet. Les saisons passèrent et l'attente du peuple grandissait à travers la contrée..._

Non, je plaisante : [la partie 2 ici](/blog/javascript-sort-2) (l'article était trop long, j'ai coupé au milieu).

Comprendre les bases de la méthode sort.

Blog

Articles récents