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é.

Un site parodique de fausse excuses pour ne pas faire de la sécurité correctement :D

(Via Marc)

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)

Un très bonne comparaison entre les performances de recherches d'Elasticsearch et MongoDB et le résultat est sans appels.

Sur la recherche, Elasticsearch est jusqu'à 20x plus rapide que MongoDB.

Sur les aggrégations, Elasticsearch est jusqu'à 38x plus rapide que MongoDB.

Sur l'insertion, MongoDB est 1.20x plus rapide que Elasticsearch.

Sur le parcours des données, Elasticsearch offre des performances stables quand MongoDB passe de 5 à 60 sec pour récupérer les derniers documents d'une collection.

Sur l'espace disque, MongoDB occupait 2x plus d'espace avec les mêmes données. (sans index!)

Ces benchmarks ont été effectués sur de grosses collections (dizaines de millions) mais les différences performances se font aussi sentir sur de plus petites collections.

Les performances seules ne doivent pas guider le choix mais aussi les features, par exemple les limitations d'Elasticsearch sont les suivantes:

• Near Realtime Search: les documents ne sont pas disponible immédiatement dans le search après écriture
• Pas de modification possible du type d'un champs d'une collection (int vers string par exemple)
• Pas de transactions
• Pas de pseudo-relationnel comme en MongoDB

Whoa après Bubble c'est au tour de Sentry de communiquer sur son financement des projets Open Source.

260 000$ reversés à plus de 193 projets et fondations.

L'histoire incroyable d'un président accusé injustement de corruption et envoyé en prison.

Lula aurait bien pu finir ses jours en prison après ce coup d'état judiciaire mais c'est sans compter sur l'aide d'un hacker qui a prouvé la partialité de la justice dans cette affaire.

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 :-)

Utiliser correctement une base de donnée relationnelle reste un exercice compliqué car il y a beaucoup de subtilité à comprendre.

Le plus important reste le concept d'index de lecture qui sont des structures permettant de retrouver plus rapidement de la donnée en échange d'un temps d'écriture plus long.

Le plan d'exécution des requêtes est aussi très important, l'auteur présente un exemple simple:

-- compute "now() - interval 3 days" then execute a table scan
publish_date < now() - interval '3 days'

-- for each line, compute "publish_date + interval 3 days and compare to now()"

publish_date + interval '3 days' < now()

Dans le deuxième cas, on va devoir récupérer chaque ligne et faire un calcul pour executer la requête. Il ne faut pas oublier que les bases de données relationnelles sont ensemblistes et donc faites pour fonctionner sur des ensembles de lignes plutôt que sur des lignes individuelles.

Un autre exemple de grille de calcul des salaires.

Plusieurs points qui se démarquent du reste:

• ancienneté totale et pas ancienneté dans l'entreprise
• bonus personne à charge
• prime parisienne

Une bande dessinée qui explique les raisons d'utiliser un message broker comme Kafka et le fonctionnement de ce dernier.

(Merci Gaël pour le partage)

Un broker de messages temps réel qui utilise des Server Side Events (SSE)

L'histoire incroyable de deux fondateurs qui se font évincer de leur société à la suite d'une fraude minutieusement organisée.

C'est dingue ce qu'il leur est arrivé, malgré un pacte d'actionnaires sensé les protéger, deux fonds d'investissements ont fait pression sur eux via des intimidations pour les virer.

Les fonds savaient que ça prendrait du temps de faire valoir leurs droits devant les tribunaux, ils ont du se battre pendant 2 ans.

Ce qui est dingue c'est que même après la décision de la cour d'appel, ils ont du batailler pour retrouver leur poste, notamment avec la surprise de découvrir 240000€ de chèques émis sans factures. Sans compter le "nouveau" PDG qui double son salaire et se facturait en plus comme freelance.

Breega a publié un droit de réponse et ce n'est pas tout blanc du côté des fondateurs non plus: https://breegavc.medium.com/solendro-ou-quand-linvestisseur-a-tout-les-torts-r%C3%A9tablissons-les-faits-832a5550adfa

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.

Analyse d'une attaque qui vise les ressources gratuites de différents provider pour miner des Monero.

A ce jour les chercheurs ont détecté 30 comptes Github, 2000 comptes Heroku et 900 comptes Buddy impliqués.

Un serveur de distribution de messages en temps réel.

Il supporte de nombreux protocols pour la distribution:

• Server Side Event (HTTP)
• Polling (HTTP)
• WebSocket
• gRPC

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.

Un bundler/builder Javascript pour remplacer Webpack, c'est écrit en Rust et ils affichent des performances de 5 à 10 fois supérieurs.

Pour l'instant c'est que pour les projets Next.js ou Vite.

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