Happy Birthday, Go!
13 ans déjà, le langage est beaucoup plus mature aujourd'hui et même si il n'a pas pris la place du C comme langage pour la programmation système (c'est plutôt Rust qui est en passe de le faire), Golang reste un des langage majoritaire dans les outils d'infrastructure aujourd'hui.
Kubernetes, Terraform, Traefik et de nombreux autres outils très populaires son écrit en Golang.
Une feature intéressante que je ne connaissais pas, le fuzzing intégré au langage pour tester le comportement de son programme avec des milliers d'inputs aléatoires !
Une explication très clair du fonctionnement des executions asynchrones avec Node.js.
La plupart des opérations de type I/O (lire un fichier, faire une requête http, etc) sont réalisées en parallèle du reste du code dans une pool de thread gérée par la libuv.
Cela permet de ne pas bloquer le thread principal en attendant le retour d'une requête HTTP (qui est très long comparé à executer du code ou récupérer une donnée en RAM)
(Merci Ludo pour le partage)
De bon conseils pour créer des types, notamment des union types pour être sur de manipuler des objets correctes.
Plutôt que de faire ça
type Event = {
name: 'CREATE' | 'DELETE';
id?: string;
content?: string;
}
Faites plutôt:
type EventCreate = {
name: 'CREATE';
content: string;
}
type EventDelete = {
name: 'DELETE';
id: string;
}
type Event = EventCreate | EventDelete;
Un document interne technique la manière d'optimiser la destructuration d'array qui est massivement utilisé dans les React Hook.
C'est intéressant de voir que la destructuration d'objets était plus légère et rapide que la destructuration d'array (64 bytes d'instructions vs 305).
La destructuration d'objet est même plus rapide que de faire:
const array = useState(),
count = array[0],
setCount = array[1];
Ces différences sont très légères et uniquement observées sur le bytecode non optimisé.
Une alternative au compilateur officiel TSC pour Typescript.
C'est beaucoup plus rapide (~100x plus rapide) car:
- écrit en C++
- écrit uniquement pour les versions récentes de TS
- cache des fichiers compilés
Il utilise un bytecode intermédiaire pour représenter le typescript et conserve un cache pour ne prendre en compte que les dernières modifications.
Par contre toutes les fonctionnalités ne sont pas supportées.
(Merci Sébastien pour le partage)
Une librairie pour dessiner des graphiques qui reste assez méconnue malgré ses features et ses performances.
Contrairement à beaucoup de lib (ApexChart, Chart.js), Vizzu utilise des canvas pour dessiner les graphs.
Il y a aussi de très belles animations natives :-)
Il ne faut pas forcément se focaliser sur la performance à tout prix ou sur la maintenabilité à tout prix.
C'est toujours une histoire de compromis entre les deux.
J'aime beaucoup cette citation qui me fait pensé au mécanisme de gestion mémoire de Rust:
Sharing state is fine, so long as we don’t mutate it.
Mutating state is fine, so long as we don’t share it.
Le processus de stringification de typescript-json est beaucoup plus rapide car la librairie se base sur une liste de types pour les serialiser.
En gros à l'étape de compilation, la librairie va générer le code Javascript pour sérialiser exactement toutes les propriétés d'un objet typé donc on s'épargne les étapes de parcourir de l'objet et de découverte des types des propriétés.
Par contre on ne peut traiter que des payloads ayant un type défini à l'avance.
Exemple de code généré pour un type ({ name: string, age: number
):
const $string = typescript_json_1.default.stringify.string;
const $number = typescript_json_1.default.stringify.number;
const $so = [
input => `{"name":${$string(input.name)},"age":${$number(input.age)}}`
];
return $so[0](http://input);
A force de voir les développeurs Junior galérer à trouver un premier job, je me suis dit que je pourrais donner quelques conseils:
- Apprenez des technos en faisant des projets perso
- Prenez soin de votre image sur LinkedIn
Mais surtout: Contribuez à des projets Open Source.
Ça fait monter en compétence avec les revues de code et les contributions sont publiques donc accessibles aux recruteurs.
De super conseils pour écrire de bons messages d'erreurs à destination des utilisateurs finaux.
Un bon message d'erreur doit:
- expliquer ce qu'il s'est passé (
Unable to connect your account
) - rassurer l'utilisateur (
Your changes were saved
) - aider à réparer le problème (
Please try connecting again
) - fournir une aide externe (
If the issue keep happening, contact support
)
10 challenges pour comprendre les promises en Javascript
Une très bonne explication des nombreux avantages de la programmation avec le langage Rust créé par Mozilla.
Rust offre de très bonnes performances, proches du C et du C++ tout en proposant un modèle de gestion de la mémoire innovant.
Jusqu'ici, la gestion de la mémoire était soit un facteur de dégradation des performances du à l'introduction d'un garbage collector (Java, Go, C#), soit un facteur de risque de sécurité important (buffer overflow, use-after-free, segmentation fault, etc.)
Rust introduit un mécanisme ou une référence peut être soit constante et partagée, soit mutable mais unique (Borrow Checker).
La gestion des erreurs est aussi plutôt pas mal en prenant le meilleur du système d'exceptions (implicite) et du système de retour d'erreur (explicite)
// the "?" operator mean that potential errors will be propagated
let result = foo()?.bar()?;
Un autre avantage est le potentiel de portabilité dans le navigateur avec WASM. Il est possible d'utiliser Rust comme langage fullstack à l'instar de Javascript.
Il y a aussi bien sur des choses plus compliqués avec Rust:
- la syntax inhabituelle
- temps de compilation assez long
- ecosystème naissant
La meilleure explication que j'ai eu des CORS (Cross Origin Resource Sharing).
Les CORS sont un ensemble de règles envoyées par un serveur dans les header HTTP qui sont ensuite respectées par le navigateur afin d'empêcher un site d'envoyer des requêtes vers un autre site.
Par exemple, un script Javascript qui s'exécute sur https://links.aschen.ovh ne peut pas envoyer une requête sur le domaine gmail.com car les CORS de gmail.com ne l'autorise pas.
(Merci Florian pour le partage)
L'auteur d'une lib de CSS in JS pour React explique les désavantages de ce fonctionnement.
Les deux principaux désavantages sont le poids supplémentaire des libs nécessaires et l'impact non négligeable sur les performances de rendu.
Après la lib offre quand même une DX très confortable donc à chacun de faire ses compromis.
(Merci Ludo pour le partage)
Un repo Github ou j'ai rassemblé pas mal de ressources à propos du fonctionnement des moteurs Javascript (principalement v8)
C'est toujours bien de comprendre comment est executé le code que l'on écrit, pour le debuguer plus efficacement mais aussi pour l'optimiser quand on en a besoin !
Au programme:
- Hidden Classes
- Inline Cache
- Closures
- Function Polymorphisme et Mégamorphisme
- Interpreteur et Compilateur spéculatif
- Micro Benchmark
Certains articles sont assez complexes mais en règle général ça reste abordable.
Un framework pour créer des API REST en codant les contrôleurs et modèles en TypeScript avec des annotations.
Ça génère automatiquement la spec OpenApi et les JsonSchema en plus.
(Merci Bombi pour le partage)
Un système de queing entièrement basé sur Redis.
Ils proposent toutes les fonctionnalités dont on a besoin:
- multi-queue producers et consumers
- garantie du delivery unique
- expiration des messages
- rate limiting
Une lib pour générer des JSON Schema depuis des types Typescript
Il ne faut pas toujours chercher à rendre le code clean avec des abstractions et en évitant les répétitions.
Souvent cela rend le code plus complexe et donc plus difficile à maintenir.
La est toutes la subtilité du métier de développeur, trouver le bon compromis entre clean code et KISS code (Keep It Simple and Stupid).
L'auteur pointe aussi une autre erreur, de gestion d'équipe, il a refactoré le code d'un collègue sans lui en parler avant.
Un article de fond sur l'évolution du développement frontend.
L'article commence par un historique du frontend:
- Pages dynamique CGI : PHP
- AJAX : JQuery, Flash
- Split frontend/backend : Backbone
- Two way binding : Angular
- JAMStack: Gatbsy, Next
- Components: React, Vue
Le frontend s'est tellement complexifié qu'on atteint des limites en terme de coût de manipulation du DOM (résolu par le Virtual DOM) mais également en terme de traffic réseau et du rendering des éléments d'une mage qui peuvent se bloquer entre eux (charger du CSS par exemple)
L'auteur revient sur les différentes innovations mises en place chez Facebook avec React:
- Optimizing runtime costs: Virtual DOM, CSS avec Stylex
- Optimizing the network: Relay, GraphQL
- Optimizing Javascript bundles: Tree shaking (Facebook utilisent carrément une IA !)
Les différents framework du marché sont passé en revue: React, Svelte, Vue, Solid, Astro, Marko, Fresh, Next, Remix et Qwik
Pour moi le plus important est cette phrase de l'auteur
It’s a good reminder that if you’re on the bleeding edge, you are usually the one bleeding. Defaulting to “boring” technologies, ones you are familiar with, and being a late adopter is often a great choice.
La morale c'est qu'il faut choisir son framework en fonction de ses besoins actuels et faire très attention aux choix techniques pour des projets long termes.