## Organiser le code avec Meteor 

**Meteor.js** s'appuie sur Node.js et intègre nativement plusieurs fonctionnalités et librairies, tels que MongoDB, les sockets, etc...  

Il s'agit d'une plateforme fullstack qui permet de coder à la fois le front et le back dans des fichiers partagés qui peuvent être importé de n'importe où. C'est pourquoi il faut souvent vérifier dans le code où est-ce que l'on se positionne avant d'exécuter un code uniquement backend ou uniquement frontend.

![meteor-js ><](https://bo.dev-freelance.fr/uploads/meteor_js_7dd27b0515.png)

Pour savoir si le code est exécuté coté client on fait : 

```tsx
import { Meteor } from 'meteor/meteor'

if (Meteor.isClient) {
  // ... code exécuté uniquement sur le client
}
```

Pour le serveur, ce serait : 

```tsx
import { Meteor } from 'meteor/meteor'

if (Meteor.isServer) {
  // ... code exécuté uniquement sur le serveur
}
```

### Comment s'effectue sa communication backend/frontend ?

Meteor fait communiquer ces deux briques via ce qu'il appelle le protocole **DDP** (pour **Distributed Data Protocol**) qui utilise à la fois : 

- du RPC (**Remote Procedure Call**)
- le fait de pouvoir souscrire à des événements
- faire des stream etc...

Comprenez bien que ce protocole cadre énormément les choses par la suite !

Cela signifie que globalement vous ne ferez pas de **REST API** (même si vous pouvez en faire via des extensions), de même vous ne ferez pas de **GraphQL** (même si vous pouvez en faire via des extensions  😅).

Ainsi cela implique moins d'intervention sur la partie routing du projet, l'organisation se fera ailleurs via : 

- **La publication de données** : **Meteor.js** permet d'exposer une partie des données DB côté front (en lecture uniquement), on peut faire des requêtes directement depuis la partie cliente, mais à condition d'avoir autorisé le dataset et avec des pré-conditions de filtres (par exemple une clé ownerId ou companyId serait forcée côté client pour empêcher de requêter des données dont on est pas propriétaire). Côté serveur toutes les données restent accessibles... Ingénieux ! 🧐
- **La création de méthodes** : Le server défini un certains nombres de fonctions server-side que l'on peut appeler avec certains paramètres pour qu'il exécute du code non exposé au front. Généralement on y met les opérations d'écritures vers la base de données, écriture de fichiers, appels API, etc...
- **L'appels de ces méthodes** : Le client peut appeler les server-side methods et exécuter des insertions en base de données, des updates, etc. via l'utilisation de Meteor.call.

###  L'influence du DDP de Meteor sur l'organisation !

Autre plateforme, autre méthodo, je vous propose mon approche lorsque je travaille sur un projet **Meteor**. Cela demande de l'organisation afin de ne pas perdre ses repaires car nous sortons des sentiers battus.
Dans cet article, je ne mentionnerai pas la définition des types qui doit être faite en amont (la base de **Typescript** !).

#### Préparation du code Meteor.js côté server

On défini notre collection Mongo :

```tsx
// /imports/api/products.ts

import { Meteor } from 'meteor/meteor'
import { Mongo } from 'meteor/mongo'

export const ProductCollection = new Mongo.Collection<Product>('products')
```
J'utilise le fichier index pour centraliser tous les modèles et permettre de faire un import unique sur mon module serveur plus tard.

```tsx
// /imports/api/index.ts
// On exporte nos modèles ici

// ....
export { ProductCollection } from './products'
```

Il est temps d'exposer nos données sur le frontend, mais ceci ne se fait pas sans une sécurité préalable !
Ici nous exposerons uniquement les produits appartenant à une même compagnie sur le frontend.
Ce filtre sera appliqué par défaut pour toutes les requêtes DB qui arrivent du client. De même si l'on ajoute des conditions supplémentaires, elles viendront s'ajouter à celles existantes sur ce qui a été publié.  

Par exemple : companyId = 'ABCD' + name = 'clé usb'

Idem pour la pagination, les skip etc...

```tsx
// /imports/api/published/product-publ.ts

import { Meteor } from 'meteor/meteor'
import { ProductCollection } from '../product'

Meteor.publish('products', function (companyId: string) { 
  if (!companyId) return null
  return ProductCollection.find({
    companyId
  })
})
```
Le fichier index du dossier published permet de centraliser tous les sous-modules : 

```tsx
// /imports/api/published/index.ts

import './product-publ'
```

Enfin nous importons tout cela dans notre Meteor server :

```tsx 
// /server/main.ts

import '/imports/api/published'
import '/imports/api'
```

#### Préparation du code Meteor.js côté client

Lorsque j'utilise **Meteor**, je gère les pages avec un **react-router** traditionnel. Mais j'organise toujours mes pages de manière à exporter le composant avec un **Higher Order Component** (appelé aussi **HoC**) qui permet de lier la partie vue à la couche de données et de souscrire aux événements (à la manière d'un redux connect). 

Pratique pour le côté temps réel 👌! 

```tsx
// /imports/pages/products.tsx

import * as React from 'react'
import { useFind, useSubscribe, withTracker } from 'meteor/react-meteor-data'
import { ProductCollection } from '/imports/api' // On expose l'objet Mongo sur le front

type ProductsPageProps = {
  products: Products[]
}

function ProductsPage({ products }: ProductsPageProps) {
  return (
    <table>
      <thead>
        <tr>
          <td>Name</td>
          <td>Price</td>
        </tr>
      </thead>
      <tbody>
        {
          products.map((product: Product, index: number) => {
            return <tr key={index}>
              <td>{product.name}</td>
              <td>{product.price} €</td>
            </tr>
          })
        }
      </tbody>
    </table>
  )
}

// Mapping avec les données
export default withTracker(() => {
  // Hook de récupération de ma société (cookie ou session ou localStorage...)
  const { activeCompany } = useCompany()
  // On souscrit aux produits pour pouvoir les requêter
  const isLoading = useSubscribe('products', activeCompany) 
  
  
  const products = useFind(
    () => ProductCollection.find({}),
    [ ]
  )

  return {
    products 
  }
})(ProductsPage)
```

### Les sauvegardes en base de données avec Meteor

Toujours dans notre fichier d'api, pour la partie serveur, nous allons ajouter une méthode **Meteor** afin d'insérer la donnée en base : 

```tsx
// /imports/api/products.tsx

import { Meteor } from 'meteor/meteor'
import { Mongo } from 'meteor/mongo'

export const ProductCollection = new Mongo.Collection<Product>('products')

Meteor.methods({
  'product.create'(companyId: string, data: Product) {
    try {
      return ProductCollection.insert({
        ...data,
        companyId
      })
    } catch (err) {
      console.log(err)
    }
  }
})
```

Côté vue, on se crée une page de formulaire. Personnellement j'utilise react-hook-form, mais je reviendrai un peu plus en détail sur cette librairie dans un prochain article.

```tsx
// /imports/pages/product-add.tsx

import * as React from 'react'
import { useSubscribe, withTracker } from 'meteor/react-meteor-data'
import { useNavigate, useParams } from 'react-router-dom'

type ProductAddPageProps = {
  onSubmit: (data: Partial<Product>) => void
}

function ProductAddPage({ onSubmit }: ProductAddPageProps) {
  // ... formulaire sur lequel j'attache mon submit
})

export default withTracker(() => {
  const navigate = useNavigate()
  const { activeCompany } = useCompany()
  
  return {
    onSubmit: (data: Product) => {
      Meteor.call('product.create', activeCompany, data, (err: any, productId: string) => {
        alert('Product inserted')
        navigate('/products')
      })
    }
  }
})(ProductAddPage)
```

A ce stade vous savez faire de la lecture/écriture en base avec **Meteor.js** **React** et **Typescript**.

Dans de prochains articles nous verrons comment gérer les uploads et la pagination de données. Stay tuned ! 😃


large_tasos-mansour-ndWAEhY_w20-unsplash.jpg

medium_tasos-mansour-ndWAEhY_w20-unsplash.jpg

small_tasos-mansour-ndWAEhY_w20-unsplash.jpg

thumbnail_tasos-mansour-ndWAEhY_w20-unsplash.jpg

tasos-mansour-ndWAEhY_w20-unsplash.jpg

Découvrez Meteor.js, une plateforme JavaScript fullstack réactive et temps réel, compatible TypeScript et React, avec une communauté active depuis 10 ans.

Meteor.js avec React et Typescript

## Un blog avec Next.js et Strapi

Ces technologies ont la particularité d'avoir une communauté active et présente, et m'ont permis d'accélérer le développement de ce blog personnalisé. J'ai pu m'appuyer sur des bases existantes solides et me concentrer sur la personnalisation de l'affichage, du contenu, etc.

### Typescript, une course à la stabilité

Cette plateforme aura pris exactement deux semaines pour voir le jour. Alors, effectivement mon temps était sporadiquement utilisé sur ce projet personnel, le soir et les week-end et finalement, le projet a vu le jour assez rapidement. 

Le gros du changement concerne le langage utilisé pour coder la plateforme, on est passé de **Javascript** à **Typescript** qui est tout de même beaucoup plus fiable en matière de livrable. Cela signifie tout simplement que pour chaque feature livré, je n'ai pas ou quasiment pas eu à intervenir de nouveau pour fixer quelque chose.

Effectivement, on est sur une courbe de rendement (similaire à une courbe d'apprentissage), c'est à dire que pour produire quelque chose en **Typescript**, on fourni un peu plus d'effort, mais le résultat obtenu est très robuste et satisfaisant. 

Par ailleurs, nous avons pu faire cela en un délai record, grâce à **Strapi** utilisé dans sa version beta, elle aussi en **Typescript** !

Pour ceux qui ne connaissent pas [Strapi](https://strapi.io/v4), je vous recommande leur documentation ici, ainsi que pour [Next.js](https://nextjs.org/).

### Ce moteur de blog que fait-il de plus que les autres ?

Alors, il s'agit d'un moteur de blog avec **Strapi** utilisé comme backoffice, mais à la différence d'autres moteurs existants sur le marché tel que **Wordpress** ou **Joomla**, il est beaucoup plus flexible (en tout cas pour un développeur). 

Voici une liste des avantages : 

- Flexible (possibilités sans limite, vente de produits, contenu multimédia, etc...)
- Robuste (grâce à **Typescript**, j'imagine qu'il y a de petites choses à corriger, mais globalement pas de bugs)
- Rapide, grâce à notre **caching** sur mesure (entre 2 rafraîchissement je suis à 100ms parfois)
- Composants **React** (qui fera plaisir aux développeurs)
- **Responsive** nativement (oui j'ai codé 100% du thème dans un style clair et sobre grâce à **Tailwindcss**, sans utiliser de template ou autre)

Le blog prend alors ici des allures d'applications si on le souhaite, car on a les pleins pouvoirs et main mise sur le code source. 

### Quelles sont les fonctionnalités de ce blog ?

Le blog dev-freelance se devait de fonctionner comme tout type de blog, à savoir : poster du contenu et recevoir du feedback. C'est pourquoi, j'ai rapidement conçu un module de commentaires. Il est donc possible de s'inscrire sur le blog afin de poster des commentaires, réagir aux autres commentaires, de liker les articles...

Ce module commentaire a pu être intégré au sein même de **Strapi**, afin d'éviter de cumuler plusieurs backend pour le faire. J'ai créé les modèles de données, personnalisé certains endpoints et le tour était joué. Ce n'est pas la partie la plus difficile tant la documentation de **Strapi** est détaillée. Dans le cas contraire, vous avez énormément de supports sur internet (**github**, **stackoverflow**, etc.).

![module-commentaire-strapi ><](https://bo.dev-freelance.fr/uploads/ezgif_2_b62652a7fe_e756a2f644.gif)

J'ai aussi intégré mon système de **captcha** sur-mesure afin de parer à toute éventualité contre les bots d'internet (croyez-moi ils sont légion). Je constate tout de même que j'ai quelques optimisations à faire sur mobile, notamment sur les ratios d'image, mais cela reste potable.

![module-captcha-nextjs ><](https://bo.dev-freelance.fr/uploads/ezgif_2_49eb59a6f0_42b0dfec3f.gif)

L'intégration de contenu multimédia en passant par les vidéo **youtube** ou les audio de **soundcloud**.

![dev-freelance-blog ><](https://bo.dev-freelance.fr/uploads/ezgif_4_becc89aec0_2d4728ddab.gif)

### Quel projet après celui-ci ?

Maintenant que le blog semble assez stable, que ce soit pour la partie email, contenu, etc, il me reste tout de même quelques pages que j'aimerais ajouter comme la gestion du compte utilisateur. Et probablement encore du travail à effectuer pour optimiser le blog pour la SEO. 

En outre, je ne vous cache pas que j'ai encore beaucoup d'autres projets en cours, sur lesquels j'avance petit à petit et que j'ai hâte de sortir. Petit teaser, il y a des projets en **Meteor Typescript**, d'autres projets en **Next.js**... Bref encore beaucoup de challenge en perspective.


fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

large_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

medium_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

small_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

thumbnail_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

Découvrez pourquoi j'ai migré mon blog d'un moteur custom Node.js Express/Handlebars vers une plateforme Next.js, Strapi et React en full TypeScript.

Petit point technique sur le blog

## Réduire la taille du bundle généré par Next.js

Lorsque l'on importe nos composants dans nos pages de cette façon : 

```tsx
import {
  ComponentA,
  ComponentB,
  ComponentC
} from '@components'

// ...
```

Ce qu'il se passe réellement lors de la construction du bundle (**next build**), c'est que **webpack** resolve l'intégralité du fichier @components/index. 

En d'autres mots, si vous exportez aussi ComposantD, ComposantE, etc... ils seront dans le source code compilé de la page, même s'ils ne sont pas utilisés.

Il s'agit du comportement standard de **webpack**, tout ceci est normal. Même si cela peut nous porter préjudice : 

![next-build-non-optimized ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_06_28_22_34_46_313c923aba.png)

Nous devons alors, demander à **webpack** de purger le code inutilisé pour nous. Cette opération s'appelle faire du **tree shaking**, je vous invite à voir [la documentation de webpack](https://webpack.js.org/guides/tree-shaking/) d'un peu plus près.

### Première solution pour optimiser notre bundle Next

Une solution un peu plus longue, en fonction de la densité de votre code consiste à isoler les imports de chaque composant. Ainsi, vous aurez une ligne par composant et cela risque de prendre un peu de place : 

```tsx
import { ComponentA } from '@components/component-a'
import { ComponentB } from '@components/component-b'
import { ComponentC } from '@components/component-c'
```

J'entends que cette solution peut être fastidieuse à mettre en place, surtout si votre projet comporte énormément de pages et de composants.

Mais le jeu en vaut la chandelle : 

![next-build-optimized ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_06_28_22_34_56_6732e95352.png)

Dans notre cas, nous obtenons un gain de 16% par rapport au premier build.

### Une solution plus laxiste pour optimiser la taille du bundle Next.js

Cette seconde méthode n'est pas forcément la plus propre et ne vous permettra pas d'avoir une réelle maîtrise de tout ce qu'il se passe en dessous, mais elle aura l'avantage de vous faire gagner du temps. 

Cette méthode consiste à ajouter une ligne de configuration dans votre **package.json** afin de préciser à webpack comment effectuer son build.

```js
{
    ...
    "sideEffects": false
}
```

Et voilà, le tour est joué, vous aurez à peu près le même résultat, voire le même résultat lors du build. En revanche, ici, nous précisons juste à **webpack** de supprimer le deadcode lors du build. En théorie, cela devrait suffire mais nous ne sommes pas à l'abris d'un imprévu étant donné que nous n'avons pas manuellement exclus ce qui semble "inutilisé".

On a souvent tendance à minimiser l'impact du poids des pages sur la performance de notre site, mais à tord. Il a été maintes et maintes fois démontré que les sites les plus lents perdent du trafic, sans doute à cause de l'impatience des utilisateurs, à qui les moyens actuels (fibre, serveurs performants, 5G, etc...) apportent encore plus de confort.

large_saffu-E4kKGI4oGaU-unsplash.jpg

medium_saffu-E4kKGI4oGaU-unsplash.jpg

small_saffu-E4kKGI4oGaU-unsplash.jpg

thumbnail_saffu-E4kKGI4oGaU-unsplash.jpg

saffu-E4kKGI4oGaU-unsplash.jpg

Lorsque l'on organise son code, on a tendance à regrouper les composants dans un dossier, et souvent on exporte l'intégralité des composants via un fichier index. Sans le savoir voici ce qu'il se passe...

Optimisation des imports en Next.js

## ReactJS, un besoin d'organisation

Contrairement à d'autres libraries frontend comme **Angular**, **React** donne beaucoup de liberté aux développeurs pour organiser le code. Mais il est difficile de s'y retrouver si plusieurs personnes travaille avec des méthodologies différentes. **Redux** a apporté une façon d'organiser le code via des événements nommés et connus d'avance. Cependant le code à mettre en place avant de pouvoir le faire est assez dense. Et son utilisation au quotidien peut s'avérer problématique tant il est compliqué d'ajouter de nouveaux événements ou namespaces au fonctionnement existant.

### Comment s'organise le code avec Redux

Depuis que les développeurs frontend se sont mis à **React**, nombreux ont été les tentatives d'organisation du code autour d'un flow qui permet de gérer les états et les changements d'états. 

Dans tout cela, Redux a sorti son épingle du jeu en proposant une approche basé sur des stores de données qui écoutent des événements précis afin de changer d'état. Cependant, sa mise en place n'est pas des plus simple. Cela demande une organisation des fichiers sources, la création de chacun des états et la gestion de chacun des événements. 

Sans compter le fait que les composants qui utilisent ce store doivent être wrappé dans une fonction qui permettra de déclencher un re-render au moment d'un événement. Et que chaque composant doit être attaché au store pour pouvoir utiliser un état de ce dernier. Bref une mise en place qui une fois qu'on s'est habitué n'est pas si compliqué, mais qui demeure complexe à mettre en place et à organiser.

Chaque nouvel événement implique la création de ce dernier et se doit de spécifier comment va réagir le store de donnée en fonction des événements. Toute cette organisation demande surtout énormément de temps, que finalement on en passera pas à créer des features, mais plutôt à organiser notre code et essayer au maximum de gérer side-effects des événements cross-stores... 

![redux-flow ><](https://bo.dev-freelance.fr/uploads/redux_1_drawio_94d90142bc.png)

**Le temps passé à mettre en place l'architecture redux vous coûte cher à l'échelle d'un projet complexe.**

### La mauvaise méthode pour remplacer Redux

La solution à l'ancienne pour impacter un child sans utiliser redux était de créer un state à haut niveau sur un parent element, et passer les getter/setter en props à chaque composants. Ce pattern s'appelle le **props-drill pattern**.

En revanche, vous imaginez bien les limites de ce modèle, il s'agit de passer toujours de plus en plus de props à chaque composants intermédiaire et ses composants imbriqués. 

Pour vous donner une idée : 

![react-props-drill-pattern ><](https://bo.dev-freelance.fr/uploads/redux_2_drawio_579ef0919e.png)

Et en implémentation simplifiée cela donnerait quelque chose comme ça : 


```tsx
import * as React from 'react'

type User = {
  name: string
  age: number
}

type ParentContainerProps = {
  children: React.ReactNode
}

// Mock data fetch
const ConnectUser = (cb: (u: User) => void) => {
  cb({
    name: 'John Doe',
    age: 30
  })
}

// parent-container.tsx
const ParentContainer = ({children}: ParentContainerProps) => {
  const [user, setUser] = React.useState<User | null>(null)
  return (
    <div>
      <UserContainer user={user} setUser={setUser} />
      {children}
    </div>
  )
}

// user-container.tsx
const UserContainer = ({ user, setUser }: { 
  user: User|null, 
  setUser: (u: User) => void 
}) => {
  // Fetch data
  React.useEffect(() => {
    ConnectUser((connectedUser: User) => setUser(connectedUser))
  }, [])
  return user ? (
    <div>
      {user.name} - {user.age} ans
    </div>
  ) : null
}

export default ParentContainer
```

On constate que chaque composant doit avoir les props qui permettent de manipuler un user et se doivent de le passer à chaque child qui en a aussi besoin. Ce pattern est d'autant plus problématique qu'en Typescript, s'il s'agit d'une donnée que l'on récupère de manière asynchrone, cela implique qu'il risque d'être null ou changer d'état.

### Une meilleure approche pour remplacer Redux

Depuis que l'on utilise majoritairement des functional components et des hooks, la manière de faire a changé. Désormais, on emploie le **Provider/Context pattern**. 

La mise en place de ce pattern consiste à wrapper le code dans un Provider. Et comme ses enfants viendront consommer son context, il pourra ainsi gérer le re-render des composants si besoin. 

Pour rendre mon code réutilisable, je passe par les hooks pour isoler les getters, setters. Ainsi seuls les hooks viendront consommer les contexts (aucune lecture en direct) et les composants consommeront les hooks.

![react-provider-context-pattern ><](https://bo.dev-freelance.fr/uploads/redux_3_drawio_b8cda10bc0.png)


```tsx
import * as React from 'react'

type User = {
  id: number 
  username: string
  age: number
  email: string
}

// /context/user-context.tsx
type UserContextValues = {
  connected: boolean
  setConnected: (c: boolean) => void
  userInfos: User
  setUserInfos: (u: User) => void
}

export const UserContext = React.createContext<UserContextValues>({
  connected: false,
  setConnected: () => void,
  userInfos: {
    id: null,
    username: '',
    age: '',
    email: '',
  },
  setUserInfos: () => null,
})

export const UserProvider = ({ children }: { children: React.ReactNode }) => {
  const [connected, setConnected] = React.useState(false)
  const [userInfos, setUserInfos] = React.useState<User>({
    id: null,
    username: '',
    age: '',
    email: '',
  })

  // Get our user
  React.useEffect(() => {
    if (!connected) {
      fetch('/my/user/api/endpoint')
        .then(res => res.json())
        .then(user => {
          setUserInfos(user)
          setConnected(true)
        })
        .catch(err => console.log(err))
    }
  }, [connected])

  return (
    <UserContext.Provider
      value={{
        connected,
        setConnected,
        userInfos,
        setUserInfos,
      }}
    >
      {children}
    </UserContext.Provider>
  )
}

// /hook/use-get-user.tsx
export const useGetUser = () => {
  const { userInfos } = React.useContext(UserContext)
  return userInfos
}

// /components/user-card.tsx
export const UserCard = () => {
  const user = useGetUser()

  return user ? (
    <div className="card">
      <h3>{user.username}</h3>
      <p>{user.age} ans<p>
    </div> 
  ) : null
}

// app.tsx
// ...
return (
  <UserProvider>
    <App />
  </UserProvider>
)
```

Comme on peut le voir, la deuxième méthode est beaucoup plus propre et malgré un plus grand nombre de fichiers à créer, cela reste une approche simple pour accéder à des données centralisées à la manière d'un redux.

lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

large_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

medium_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

small_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

thumbnail_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

Découvrez l'évolution de React et Redux, des débuts en ES5 à TypeScript, et apprenez une méthode efficace pour organiser vos projets sans complexité excessive.

Pourquoi je préfère me passer de Redux 

## Quelques astuces pour bien progresser en tant que développeur web

Pour faire suite [au précédent article sur le développement](https://dev-freelance.fr/dev/mes-conseils-de-developpeur-partie-1), voici encore quelques conseils pour vous améliorer en développement.

### 1 - Tester son code

Cela demande du temps de tester en permanence les itérations de votre code source. Mais cette étape est très importante ! Elle assure le bon fonctionnement - parcours prévu, résultat attendu - de votre code.

Il y a plusieurs façon de tester son code : les TU (tests unitaires) souvent réalisé par les développeurs eux-mêmes.  

Il s'agit d'isoler une petite partie du code et tester son fonctionnement. On le fait généralement avec les fonctions que l'on peut tester directement via ses I/O (entrées, sorties). En gros on l'appelle avec des paramètres et on vérifie que la réponse est cohérente et qu'il s'agit bien du résultat attendu, ou comportement attendu s'il s'agit d'un void (fonction sans retour).

Pendant longtemps, les boîtes ont encouragé les développeurs à avoir un fort niveau de coverage, c'est à dire plus de teste sur une plus grande partie du code. Plus le coverage est élevé plus l'entièreté du code est testé. Or, d'expérience, c'est parfois contre-productif de le faire. Je dirais qu'il faut tester essentiellement les logiques complexes et avoir environ 60 à 65% de coverage est déjà largement suffisant.

Au delà, on passe surtout énormément de temps à maintenir les tests, moins à développer des features, en sachant que des langages comme Typescript (mon petit chouchou), règle déjà énormément de problèmes en amont.

Les TU restent cependant terriblement efficaces, a tel point qu'on en a fait une méthodologie de travail : le TDD (test-driven development). Ce qui signifie que l'on va commencer par implémenter les tests avant même de faire le code. 

Par exemple,  je dois faire une fonction qui doit multiplier un entier passé en argument par 2. 
Cette fonction s'appelle multPer2. 
Je commence par faire un test qui vérifie que le résultat est bien égal au double de mon entrée.
Avec les libs de tests assez connu tel que Jest, ça donnerait cela :

```js
describe('test libs', () => {
    it('Should multiply per 2', () => {
        var result = multPer2(2)
        expect(result).toEqual(4)
    })
})
```

Dans ce test, on vérifie que le résultat est égal à 4. Dans le cas contraire, le test renverra une erreur.
Maintenant une fois que les tests sont prêts, je peux commencer à coder ma fonction, le but du jeu est de faire tourner les tests (automatiquement si possible) jusqu'à ce que tout soit ok.

```js
function multPer2(inp) {
    return 2 * inp
}
```

Pour tester le front (des composants react par exemple) ce n'est pas si simple. En général, on utilisera des outils qui permettront de générer un fake DOM et de simuler des timers, pour les lifecycle de render (comme jest, react-testing-library, etc...). Mais ils ne sont pas simple à prendre en main, et si votre composant connait énormément de mutation d'état pour X ou Y raison, cela risque d'être difficile à tester. Mais rassurez-vous il y a des outils spécifiques pour ça : les tests E2E.

Les tests E2E (end-to-end) sont généralement implémentés (code ou no code) par les QA testeurs, donc des profils dédiés à ce type de tests. Mais dans certaines équipe il n'est pas rare que ce soit les développeurs eux-mêmes qui implémentent les E2E. Aujourd'hui, le marché propose de nombreux outils intéressants comme : Cypress ou Playwright et il y a de quoi faire !

Ou au moins testez à la main ce que vous faites, c'est un minimum. De même, si vous relisez la PR d'un collègue, prenez le temps de réellement tester les choses et ne validez pas uniquement en ayant lu sur GIT à moins que ce soit du code très simple CSS, etc... Prenez le temps de le faire.

### 2 - Anticiper le comportement du code

Lorsque vous prenez de l'expérience, vous serez en mesure d'anticiper plus facilement sur la complexité de ce que vous allez implémenter. 
Instinctivement, vous saurez d'avance : 

- quand est-ce qu'une implémentation risque de vous donner du fil à retordre
- quand est-ce qu'une valeur en entrée risque de changer
- pourquoi le code risque de ne pas s'exécuter
- pourquoi une partie de votre code est exécuté avant ou après telle ou telle action
- pourquoi le résultat obtenu risque de ne pas être correct

Maintenant, utilisez votre expérience pour prévenir ce genre de problèmes. Puisque vous savez que cela peut arriver, et que vous êtes en mesure de comprendre pourquoi. Il est possible de mettre en place des gardes-fous.

**Votre expérience ne doit pas vous servir uniquement à coder plus vite, mais surtout à coder mieux.**

J'ai des règles d'organisation et d'anticipation qui globalement fonctionnent très bien et me permet de dormir sur mes deux oreilles.

Voici ma méthodologie :

**La base :**

- J'organise toujours mon code de manière à savoir exactement où est positionné telle ou telle brique. Il faut que je n'ai pas à réfléchir pour retrouver un composant, une lib, une page, les configs, etc...
- Je n'inclus jamais les clés API, tokens et les endpoints au code source, car le code n'est pas hébergé sur ma propre machine. Dans un data center qui sait ce qui peut arriver ? Les sociétés comme Github, Bitbucket et autre ne sont pas à l'abris d'un hack de la couche 0... (l'humain, les employés eux même !). J'utilise l'environnement sans versionner le fichier .env

**Plus technique :**

- Je pars du principe que tout ce qui est externe a mon code n'est pas fiable, donc je redouble d'effort sur les vérifications de ces données. Par exemple une API peut ne pas répondre, changer de format de réponse, etc..., donc, je prends les devant et je vérifie que je dispose des éléments qui me permette de continuer à processer, dans le cas contraire, je m'arrête avant de générer des erreurs ou faire crasher mon programme.
- Lorsque je code du frontend, je réduis au maximum le nombre de composants qui font des calculs ou manipulent des données. En général, je crée le maximum de dumb components, destinés uniquement à faire de l'affichage. Et j'effectue des appels API et des opérations uniquement dans certains fichiers ciblés. Cela me permet en cas de dysfonctionnement de savoir exactement où effectuer une action.
- Je factorise au maximum les utilisation commune ou les schéma commun dans mon code, cela me permet de réduire mes efforts en cas de modification car plusieurs éléments seraient modifiés simultannément.
- Je dissocie la partie API (récupération de données) de la partie exploitation de ces données, afin de ne pas avoir de comportement trop spécifique sur ma brique la plus commune. Par exemple, je traite la réponse d'API et affiche des toasters etc... à l'endroit ou j'appelle ma librairie d'API et pas directement dans la lib.
- Sur les gros projets, je distingue fortement le traitement synchrone du traitement asynchrone. C'est à dire que je préfère garder sur mon API ce qui est vital pour que l'utilisateur puisse avoir le maximum de confort (temps de réponse courts, données essentielles, etc...). Et toute la partie traitement (stats, compteurs, cache, etc...) je le fais via d'autres threads que j'appelle les Workers.  
- Je privilégie toujours la lisibilité plutôt que la sur-optimisation. Biensûr dans certains cas, je préfère optimiser afin de ne pas trop multiplier les instructions et ralentir le code. Mais si cela rend le code plus lisible pour mes collègues, je prends le temps de montrer certaines opérations de manière plus explicite afin d'être plus clair et plus facile à appréhender.

### 3 - Surmonter ses peurs en programmation

A chaque fois qu'un sujet technique vous angoisse, car il vous parait complexe, soyez sûr que si vous le maîtrisez vous apprendrez quelque chose. 

Les outils à disposition des développeurs n'existent pas par hasard. Très souvent, ils sont le fruit de recherches et de travaux destinés à simplifier la vie du développeur.

Par exemple, combien de condition "if" vous faut-il pour remplacer une seule et unique RegExp ? 

Combien d'indentation vous faut-il utiliser dans une série de Promise, au lieu d'utiliser l'async/await ?

Une chose est sûr, cela m'a toujours été bénéfique d'apprendre de nouvelles choses. Et cela devrait être un sujet excitant et pas repoussant. 

Prenez le temps d'appréhender et de tester les nouveaux outils et les nouvelles méthodos. Si les gens en parlent, c'est qu'il y a forcément un intérêt qui a été décelé par développeurs.

Le plus simple est d'intégrer cet apprentissage à votre routine de veille technique. Une partie de votre temps doit impérativement être destiné à la veille technique et doit vous permettre de tester ces outils.

Même si, vous ne comptez pas vous en servir à terme, il est intéressant de savoir dans quelle situation, cela pourrait vous servir. De même, je vous recommande d'utiliser un outil de note, et de toujours noter une description, un exemple et tagger la note afin de la retrouver plus tard. 

**Votre apprentissage doit vous servir à quelque chose, car si vous ne faites que lire sur le sujet, votre lecture ne vous aura servi à rien si vous n'en avez pas tiré une information.**

### 4 - Intéressez vous aux patterns

Il y a des méthodologie partout et sur tout. Nous cherchons sans cesse le moyen de nous organiser, de faciliter la collaboration, c'est pourquoi, des chercheurs créent chaque jour de nouveau outils, des patterns afin de rendre cela possible.

Qu'est-ce qu'un pattern ?

**Un pattern est une méthode de travail qui va organiser comment implémenter notre code afin de répondre à une ou des problématiques (découpage des tâches, compatibilité, communication, etc...)**

Par exemple un Pattern d'organisation de projet MVC (Model, Vue, Contrôleur) cherche à isoler la complexité de chaque ensemble d'éléments (utilisateurs, produits, ventes, paiements, etc...), en le découpant en 3 axes. Si nous voulons utiliser le pattern MVC pour gérer des utilisateurs, nous ferons : 

- le model qui décrit de quoi est composé un utilisateur, ses champs (nom, prénom, age, etc...)
- la vue, c'est à dire comment on va afficher un ou des utilisateurs
- le contrôleur qui fera le lien entre le modèle, donc l'objet utilisateur au sens code et la base de données. En général le model décrira les actions qui manipulent un modèle utilisateur (créer un utilisateur, mettre à jour un utilisateur, etc...)

Ce pattern a plusieurs avantages, son découpage permet non seulement de réduire la complexité, mais de séparer le travail en plusieurs tâches réalisables par plusieurs collaborateurs. 

Dans notre cas, un intégrateur peut se charger de toutes les vues et un développeur peut se charger des Modèles et Contrôleurs...

Et il existe des milliers de patterns intéressants à connaitre qui permettent de régler beaucoup de problèmes. Certains patterns sont mêmes propre à des langages spécifiques, tel que l'Event-Driven Pattern que l'on peut faire essentiellement en JS, C# ou Java. 

Bien sûr il y a souvent des adaptations de certains pattern dans différents langages mais parfois certains langages s'y pretent mal de par leur conception.

Ainsi, je vous recommande d'en savoir plus sur les patterns afin de toujours faire le choix le plus éclairé dans une situation donnée.

### Conclusion

Globalement, le fait de répéter les mêmes choses chaque jour et de s'intéresser au développement vous aidera naturellement à progresser. 

Ce que je vous recommande pour mettre en place quelque chose de concret est de se donner 1 heure par jour de travail approfondi sur un sujet. Que ce soit une nouvelle techno, un pattern, une librairie etc... Se donner 1 heure même en deux session de 30 minutes (matin et soir) c'est une différence énorme sur une année (plus de 200h). En sachant qu'à chaque heure que vous passez à tester, ou réaliser quelque chose, vous devenez meilleur. 

A vos claviers ! 😃

fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

large_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

medium_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

small_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

thumbnail_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

Suite au précédent article où je vous parle de comment je me suis amélioré en tant que développeur. Je vous propose de continuer notre progression ensemble en parlant de ce que l'on peut faire pour devenir meilleur.

Mes conseils de développeur partie 2

## Comment s'améliorer en programmation ?

Ce post reprend un précédent podcast que j'avais fait au sujet de s'améliorer en tant que développeur. 
Retrouvez le [podcast audio sur comment s'améliorer en tant que développeur](https://dev-freelance.fr/media/xp2dev---episode-2---comment-devenir-un-meilleur-developpeur). Je tiens à préciser que cet article est un complément du podcast et ne reprend pas tout ce qui s'est dit précédemment, c'est pourquoi je vous recommande de l'écouter avant ou après cette lecture.

La programmation est une compétence qui demande du temps et de la répétition. A la manière d'un instrument de musique, ou d'une activité sportive, en pratiquant vous allez travailler vos réflexes musculaires, votre endurance, votre intelligence dans ce domaine, en revanche, il ne s'agit pas vraiment de travailler vos muscles, mais vous musclerez votre cerveau à le faire. 

Il est indéniable que vous y développerez des automatismes et comme une boule de neige qui devient de plus en plus grosse en roulant, plus vous coderez, plus vous deviendrez meilleur.

Dans le sport, en musique, ou autre domaine de compétence, il y a cependant des exercices que l'on vous conseille de faire afin de travailler votre compétence. J'ai personnellement passé des années à faire et refaire les mêmes choses jusqu'à atteindre un niveau qui me satisfait et qui me permet de satisfaire toute demande. Pour vous donner un exemple, en 2016, je codais 10 heures par jour (en moyenne 260h par mois, soit plus de 3000h cette année là, Noël compris, jour de l'an compris et jours fériés inclus).

Cette année là, j'ai appris plus de choses qu'en 5 ans dans toute ma carrière...

**Après avoir passé des années à coder voici ce que je vous recommande de faire pour exploser vos résultats et votre niveau en développement.**

### 1 - Recoder des petites librairies que l'on utilise au quotidien

Le gestionnaires de paquet npm, composer et autre voire même les repo git sont remplis de projets et de librairies qui répondent à tous les besoins. Très souvent la mise en place de nouveau projet consiste dans les premiers jours à piocher lesquelles de ces librairies nous allons choisir afin de réaliser notre objectif.

**Les librairies comme _lodash_, _uuid_ etc, sont à la portée de n'importe qui !**

On dit souvent qu'il ne faut pas réinventer la roue, mais ce n'est pas tout à fait vrai. Si ça vous prend 2 minutes pour faire quelque chose, faîte-le et commencez à réfléchir lorsque la chose en question vous prend au moins une journée. 

Mon constat après avoir travaillé dans une dizaine d'équipes différentes : les gens savent de moins en moins comment faire les choses et c'est affolant ! Trop de développeurs sont persuadés que si une librairie existe alors elle répond forcément à notre problématique, sans tenir compte du besoin réel, sans se demander s'il n'y a pas de façon plus optimisée de faire quelque chose.

Il y a plusieurs raisons saines pour lesquels il est intéressant de recoder une librairie :

- Comprendre réellement comment les choses fonctionnes (et croyez-moi, cela règle d'avance tous les problèmes que vous rencontrerez ensuite, bugs et autre)
- Entraîner votre logique
- Créer et utiliser uniquement ce dont vous avez besoin, parfois vous utilisez uniquement 5% d'une lib entière, pourquoi alourdir inutilement vos projets ?
- Etre propriétaire du code source (pas uniquement pour faire joli, mais vous maîtrisez réellement votre repo ou votre package et cela évite les hacks et garantie la propriété intellectuel du reste de votre produit)

### 2 - Continuer à coder

Le fait de ne jamais arrêter de coder est un tremplin pour vos compétences. 

**Faites des projets en permanence**

Il y a plusieurs raisons pour lesquels faire vos propres projets :

- Vous faire plaisir sur un sujet qui vous passionne
- Solutionner un problème du quotidien qui vous tient à coeur
- Tester une nouvelle technologie (un langage, un framework) ou une nouvelle méthodologie (une organisation, un outil)

Lorsque vous travaillez sur un sujet qui vous intéresse réellement, vous décuplerez votre énergie. Vous attaquerez chaque session de dev avec une pêche comme jamais auparavant. 

De même, vous serez forcément confronté à des bugs, ou des problématiques et le fait de trouver la solution vous fera progresser. 

**Si augmenter les poids sur une barre vous fait vous muscler davantage, régler des bugs musclera vos compétences de développeur.**

Mon observation du marché du travail depuis des années est la suivante. Lorsqu'une technologie sort, rare sont les sociétés qui adoptent cette dernière directement dans leur projet. Cela a été le cas pour Node.js (tout le monde restait sur du PHP), pour React (tout le monde restait sur du jQuery), etc...

Cela vous laisse le temps, à la sortie d'une technologie qui vous intéresse, de vous familiariser avec cette dernière. Et là ou les recrutements sont parfois un peu vicieux, lors des entretiens 3 ans après la sortie d'une techno, les RH vous demanderont de justifier d'un maximum de temps d'expérience sur cette compétence, en sachant que le marché l'a adopté bien après... la belle blague. En attendant, si vous l'avez utilisé même dans un cadre personnel, vous sortirez votre épingle du jeu !

En regardant de plus près, quel est le plus gros risque d'une société lorsqu'elle décide d'adopter une nouvelle technologie ? 
La réponse c'est la perte de maîtrise. La société a peur de ne plus rien maîtriser en terrain inconnu, c'est pourquoi beaucoup restent sur leurs acquis et préfèrent tabler sur quelque chose de maîtrise. 

Mais qu'est-ce que la maîtrise en définitive ?
La maîtrise c'est avoir déjà échoué, et savoir comment sortir des problématiques (l'expérience !).

Plus vous passerez à l'action en créant, en vous trompant et en recommençant, vous développerez les skills de toute une vie.

### 3 - Faire de la relecture de code

Relire du code vous permet de voir différentes approches pour répondre à une problématique. Les chemins pour arriver à un résultat sont presque infinis. C'est une gymnastique intéressante de se mettre dans la peau d'un autre et de regarder son cheminement logique. A moins que la logique utilisée soit trop complexe ou tordu, ne jugez pas les autres sur leur implémentation. 

Chacun est différent, chacun pense différemment, c'est pourquoi nous devons portez un regard bienveillant sur ce qui a été fait, et surtout veiller à ce que l'objectif soit atteint. 

Ce processus vous permettra d'apprendre des autres, d'observer les choses sous un autre angle et vous permettra de continuer à développer votre compréhension de la programmation car je le redis, tout est affaire de compréhension. 

**La compréhension règle chaque bug, vous permet d'anticiper sur des problèmes et enlève toutes les barrières mentales que vous pouvez rencontrer en codant.**

### 4 - Faire de la veille technique

**Y a t-il quelqu'un sur youtube, sur git ou twitter qui maîtrise un sujet que vous souhaitez maîtriser ?**

Cette personne pourrait être votre mentor, suivez cette personne, écoutez attentivement ce qu'elle a à dire. Lisez attentivement ses posts. Très souvent les développeurs partagent le fruit de leur recherches et leur observations. Si vous souhaitez apprendre également, rapprochez vous au maximum de ces gens là. 

Combien d'entre-nous ont appris le développement en imitant du code que nous avons vu ? Cela ne retire en rien la compréhension de ce code. A partir du moment où tout ce qui est fait est clair à vos yeux, réutilisez ces informations que votre cerveau détient déjà ! L'avantage avec cette technique, c'est que plus vous le faite, plus vous le faites vites car vous développez des automatismes. 

**Par exemple, regardez combien de temps vous a pris la déclaration de votre première classe en orienté objet, comparé au temps que cela met au bout de la 1000e fois que vous le faîtes.**

Le mimétisme est un excellent moyen d'apprendre et de progresser vite. Et plus la personne que vous mimez est doué, plus vous allez devenir vous-même talentueux. 

De nouveau langages, de nouvelles librairies apparaissent chaque jour. Tous avec un seul et même but : répondre à un problème de développeurs ! 

Prenez le temps de tester ces outils, prenez des notes, créez des repo ou des gist, cela vous aidera probablement un jour ! Ou du moins, vous permettra de savoir à quoi sert cet outil et quelle problématique cela règle.

Lorsque vous devez mettre en place une solution, votre choix sera toujours de meilleurs qualité si vous êtes conscient des différents outils à votre disposition pour y arriver, car vous saurez pourquoi passer par tel chemin et pas l'autre.

### 5 - La magie des todo list

J'imagine que tout le monde aujourd'hui sait ce qu'est une todo list, maintenant comment le faire efficacement ?

**Chacun des objectifs de votre todolist doit être réalisable en un jour.**

C'est pourquoi, il faut toujours découper votre objectif en séquences. 
Et cela fait totalement sens, de la même manière que pour construire la muraille de Chine, on n'aurait jamais fait une tâche :

- Construire la muraille

...mais plutôt un objectif découpé en centaines de mètres au quotidien.

De même pour faire décoller un avion, on ne ferait jamais : 

- Entrer dans l'avion
- Faire décoller l'avion

Cela demande réellement un travail qui relève de la conception, que de savoir observer chacune des étapes nécessaires pour réaliser un objectif. Et s’entraîner à faire cela, vous fera progresser sur les points suivants : 

- La conception (avoir la vision du chemin vers l'objectif)
- Pouvoir estimer plus facilement le temps moyen pour réaliser une solution (calculer la distance vers l'objectif)
- Etre motivé (car chaque jour, on voit la progression et l'objectif se rapproche)
- Savoir expliquer (car on sait où l'on se positionne par rapport à l'objectif)

Nous continuerons cette exercice dans un prochain article où l'on parlera des tests unitaires et d'autres techniques pour améliorer notre compétence.

large_james-harrison-vpOeXr5wmR4-unsplash.jpg

medium_james-harrison-vpOeXr5wmR4-unsplash.jpg

small_james-harrison-vpOeXr5wmR4-unsplash.jpg

thumbnail_james-harrison-vpOeXr5wmR4-unsplash.jpg

james-harrison-vpOeXr5wmR4-unsplash.jpg

Comment devenir un meilleur développeur ? J'ai consacré beaucoup de temps dans ma vie à mon apprentissage. J'y toujours passe le plus clair de mon temps et voici ce que j'ai appris...

Mes conseils de développeur partie 1

## Les transformations du marché de l'emploi

### Trouver un emploi avant les années 2000

Je me souviens d'un temps où les étudiants se demandaient encore s'ils choisiraient de faire du droit, de la comptabilité, de la finance, ou des études littéraires, tout cela semble si loin. Non pas que ces métiers n'existent plus, mais ils ont été rejoint par tellement d'autres emplois encore inconcevable à cette époque.

D'ailleurs mes propres frère et soeur sont allé vers ces métiers qui étaient alors les "seules" voies envisageables, ou plutôt mis en lumière par notre système scolaire. 

### L'émergence des métiers de l'IT

Une dizaine d'années après, j'étais moi même diplômé en ingénierie et à mon tour de me lancer dans le monde du travail. Jusqu'alors je ne m'y intéressait pas ou peu, mais lorsque j'ai du le faire moi même, c'est à ce moment que j'ai compris que quelque chose n'allait pas.

Outre le fait que l'enseignement a un train de retard sur les nouveaux métiers - cela s'explique par le temps de comprendre ou de valider un marché et d'identifier un besoin en compétence - je remarque que rien dans notre cursus ne nous prépare à aller chercher un travail ensuite.

Je passerai sur les cours, de rédaction de CV que j'ai bien reçu de l'enseignement public, merci à eux... Mais ne nous leurrons pas, lorsque notre feuille de papier arrive sur la table d'un décideur, non seulement elle n'est pas la seule, mais elle est mis en comparaison avec d'autres feuilles probablement plus noircies d'expériences... Et à ce moment là, nous verrons apparaître une fracture entre ceux qui ont déjà travaillé et qui continuerons, et les autres à qui on n'a jamais encore donné leur première chance.

A ce moment là, vous êtes totalement perdu et dépourvu de tout repaire que vous n'avez jusqu'alors jamais eu... Donc vous faites ce qui vous parait logique, vous vous tournez vers l'entité jusqu'alors en charge de distribuer votre CV en plus grand nombre. Je parle, bien évidemment du Pôle Emploi (anciennement ANPE...).

Et là, si vous venez du monde de l'IT, vous allez tomber de très très haut (même vous étiez toujours au sol). 

### Recruter pour l'IT ça ne s'invente pas

La première fois que j'ai poussé la porte du Pole Emploi, j'avais préparé mes pièces, mon diplome de bac+5, tout ce qu'il fallait. Mais je n'avais pas préparé ma date de naissance, à ce moment j'avais 23 ans et j'ai eu droit à ce topo :

- Ah ? Vous avez 23 ans ? Euh, alors je tiens à vous dire que vous allez devoir faire les démarches vous même, car pour être honnête nous on doit d'abord placer ceux de 25 ans et plus qui touchent le RSA (RMI à l'époque). En plus vous êtes un peu trop diplômé, les recruteurs ils s'arrêtent à BAC+2 ou licence en général, là vous n'aurez pas beaucoup de propositions.

- Je réponds, mais pourquoi j'aurais moins de chances qu'une autre personne alors que j'ai peut être plus de compétences ? 

Ce à quoi on m'a répondu, "Oui mais ici les directives c'est de placer ceux de 25 ans et plus ou ceux qui sont aux assedic".

Donc au final, je me suis inscrit sur l'une des plateforme les plus mal codé du monde, pour entrer des informations que je devais resaisir tous les mois. Et vous imaginez bien qu'au bout d'un moment étant donné qu'ils ne se bougeait pas pour soumettre ma candidature aux offres en cours, j'ai fini par arrêté de le faire. 

Puis un beau matin, j'ai reçu un courrier m'annonçant que j'étais radié car inactif, dans le même temps, le Pole Emploi annonçait des chiffres records concernant la baisse significative des taux de chômage. 
Je n'ai pas peur de le dire, rien n'a jamais baissé, ils ont tout simplement radié les jeunes en clamant haut et fort qu'ils ont trop bien fait leur travail.

### Le recrutement 20 ans plus tard

On est en droit de se questionner aujourd'hui quant à l'existence même de cette entité qui est uniquement chargé du flicage des personnes qui touchent les aides et minima sociaux. Son rôle aujourd'hui n'est pas de vous faire accéder à l'emploi (l'a t-il déjà été ?), mais uniquement de vérifier que certains n'abusent pas des aides...


### Les interlocuteurs lorsque l'on cherche un emploi

Mais au final, lorsque l'on cherche un emploi, a qui doit-on parler ?

Viennent alors une nouvelle vague de recruteurs, des startups dont le but est de trouver votre emploi et empocher une commission au passage, jusqu'ici rien d'anormal. Des outils tels que Linkedin, ont permis la mise en place d'un réseau tout en étant une trace de votre parcours et de vos réalisations.

Ces recruteurs spécialisés dans la techs sont souvent des ESN, des entreprises de portage salarial. Toutes les structures qui ont un intérêt à vous positionner quelque part afin de capter un peu de valeur (prendre un pourcentage du TJM).

### Comment se passe une recherche d'emploi aujourd'hui ?

Si vous ne passez pas en direct ou par une société de recrutement qui fera des pieds et des mains pour vous obtenir un boulot (car ils ont tout intérêt à le faire), autant dire que vous perdez votre temps. Et même dans ces conditions, rien n'est gagné pour autant. 

Il n'est pas rare de passer des jours entiers à peaufiner mon profil Linkedin à mettre à jours les informations afin de donner les détails de ce que je fais et de ce que j'exécute, mais d'avoir droit à des appels où mon interlocuteur me demande : alors, quelles ont été vos expériences ? 😒

Là vous vous dites, mais pourquoi je fais tout cela ? A quoi bon, vu que personne ne se donne la peine de vraiment lire votre profil. Mais, entre-nous, tout cela, vous êtes toujours obligé de continuer à le faire. 

**Que vous soyez Freelance ou à la recherche d'un CDI, il faut que votre profil soit sans cesse à jour, même si les gens ne se donnent pas la peine de le consulter.**

Tout le monde devrait jouer le jeu... Oui mais en pratique, vous verrez bien que très souvent, les recruteurs que vous aurez au téléphone ne se sont même pas donné la peine de lire votre profil. 

![allo](https://bo.dev-freelance.fr/uploads/non_mais_allo_d75a9526a8.gif)

### Le comportement à adopter pendant la recherche d'emploi

C'est normal, chacun prend uniquement l'information qui l'intéresse, c'est un peu une "mauvaise" habitude de toujours être focus que sur soi même sans trop se préoccuper du "besoin" ou encore du "client". Il faut que chacun fasse des efforts, vous aussi ! **Soyez patient !**

Mais j'ai noté les points qui font que je détecte un recruteur plus compétent que ses confrères :

- il s'est déjà intéressé à votre profil et arrive avec des interrogations
- il est à l'écoute
- il veut savoir ce que vous voudriez faire (technologie, méthodologie)
- il veut savoir quel est votre besoin (salaire, remote, ville, ...)

C'est pourquoi de son côté, en tant que développeur, il faut s'intéresser au maximum au besoin du recruteur, à ses attentes et être réellement motivé à se lancer dans ce process de recrutement. 

Quoiqu'il en soit, c'est un jeu auquel ne joue déjà plus le Pole Emploi, et mon petit doigt me dit que dans les années à venir, nous verrons apparaître quelques réformes de cette structure pour se concentrer essentiellement sur son activité de flicage au lieu d'essayer de vous trouver du travail.

De même, ce sur quoi on doit se concentrer en tant que demandeur sont les points suivants : 

- montrer votre motivation
- continuer à faire des projets avec ou sans structure
- continuer à apprendre (de votre métier et des autres)
- être patient avec ceux qui ne sont pas de notre monde

J'échange désormais uniquement avec des structures spécialisés dans l'IT ou des recruteurs tech, et tout est beaucoup plus simple. On en déduit que le recrutement tech a aussi connu des changements positifs en s'appuyant sur le numérique. 

large_van-tay-media-TFFn3BYLc5s-unsplash.jpg

medium_van-tay-media-TFFn3BYLc5s-unsplash.jpg

small_van-tay-media-TFFn3BYLc5s-unsplash.jpg

thumbnail_van-tay-media-TFFn3BYLc5s-unsplash.jpg

van-tay-media-TFFn3BYLc5s-unsplash.jpg

Ces 20 dernières années ont vu apparaitre énormément de modification dans notre manière d'accéder à l'emploi. L'apparition de nouveau métier, l'émergence des technologie a bouleversé le panel de métier à pourvoir, et la manière d'accéder à ces dernires.

Le marché du travail et les interlocuteurs

## Rire en programmation

Vous le savez probablement, les 10 dernières années, le monde a connu une transformation essentiellement numérique. L'apparition de beaucoup de services connectés a changé la vie des gens et beaucoup de personnes ont essayé de se frayer un chemin dans cet univers, tant sa croissance attire les loups et les requins.

De même, des gens pas forcément mal intentionnés se sont aussi senti obligés de franchir le pas pour paraître "au goût jour". Ce qui donne parfois des discours loufoques...

Je vous propose un petit outil pour vous rappeler de ces phrases que vous avez probablement déjà entendu par-ci ou par-là. Toute ressemblance avec quelques personnes que ce soit de votre entourage serait purement fortuite 🤣

**Voici notre générateur de bullshit :**

![my-pipotron ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_06_14_10_15_12_ebd171f642.png)

lien vers : [My Pipotron](https://mypipotron.fr)

large_afiq-fatah-jFMAz9hHeY8-unsplash.jpg

medium_afiq-fatah-jFMAz9hHeY8-unsplash.jpg

small_afiq-fatah-jFMAz9hHeY8-unsplash.jpg

thumbnail_afiq-fatah-jFMAz9hHeY8-unsplash.jpg

afiq-fatah-jFMAz9hHeY8-unsplash.jpg

Pour célébrer le bullshit à tout va, je vous propose un petit outil qui vous rappellera probablement des conversations, en tout cas, un air de déjà vu...

Le pipo bat son plein

## Une meilleure association Strapi Next.js

Lorsque vous rédigez vos articles avec Strapi, un input de type RichText se contentera de générer du texte au format **Markdown**. Pour pouvoir l'afficher avec la mise en forme, côté Next.js, nous allons utiliser un composant **React** : **React-Markdown**.

### A quoi sert cette librairie ? 

Elle remplace le Markdown généré par Strapi en composants HTML plus traditionnel. 

Des 
```
<H1> <H2> <H3>
```
pour les titres, 

des 
```
<A> 
```
pour les liens, 

des 
```
<UL>
``` 
pour les listes...

Cette librairie est personnalisable à souhait. On peut remplacer pour chaque élément HTML rendu par un composant custom et [la documentation](https://remarkjs.github.io/react-markdown/) nous montre comment nous y prendre : 

```tsx
import React from 'react'
import ReactDOM from 'react-dom'
import ReactMarkdown from 'react-markdown'
import MyFancyRule from './components/my-fancy-rule.js'

ReactDOM.render(
  <ReactMarkdown
    components={{
      // Use h2s instead of h1s
      h1: 'h2',
      // Use a component instead of hrs
      hr: ({node, ...props}) => <MyFancyRule {...props} />
    }}
  >
    # Your markdown here
  </ReactMarkdown>,
  document.querySelector('#content')
)
```

En **JSX** cela ne pose aucun problème, mais en **TSX** c'est une autre pair de manches...

### Comment se fait la surcharge de React-Markdown

On passe un objet à la propriété components, et chaque clé de cet objet représente un composant.
Le problème, c'est que le renderer est une fonction et cela pose pas mal de problème pour pouvoir typer ces éléments.

Voici comment j'ai procédé :

Je commence par créer mon composant **MarkdownLink** qui retourne un **JSX.Element** basique : 

```tsx
import * as React from 'react'

type MarkdownLinkProps = {
  href: string
  children: React.ReactNode
}

const MarkdownLink = ({ href, children }: MarkdownLinkProps) => {
  return (
    <a href={href} target="_blank" rel="noreferrer">
      {children}
    </a>
  )
}

export default MarkdownLink
```

Puis au moment du render de **React-Markdown** :

```jsx
<ReactMarkdown
    components={{
        a: ({ node, children }) => {
           return (
               <MarkdownLink href={(node.properties?.href as string) ?? ''}>
                  {children[0]}
               </MarkdownLink>
            )
        },
    }}
   >
   {post.attributes.content}
</ReactMarkdown>
```

Et voilà, notre composant remplace désormais la balise <a></a> standard généré par React-Markdown. 😉

large_sigmund-59yRYIHWtzY-unsplash.jpg

medium_sigmund-59yRYIHWtzY-unsplash.jpg

small_sigmund-59yRYIHWtzY-unsplash.jpg

thumbnail_sigmund-59yRYIHWtzY-unsplash.jpg

sigmund-59yRYIHWtzY-unsplash.jpg

React-Markdown est une librairie d'interprétation de contenu markdown qui permet de générer automatiquement le code HTML. Cependant, il génère des balises standards, sans classes et les affiche. Si vous voulez personnaliser tout ça, il faudra créer votre CSS en fonction de l'élément parent.
Nous allons voir comment créer nos propres renderer pour les composants HTML avec react-markdown en typescript.

Découvrez tous nos articles - page 10 sur 11