Un système de management de repo Javascript.
Dans le même genre que Lerna ou Turborepo, c'est écrit en Rush et ça permet d'automatiser les builds (entre autre)
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.
C'est le résultat d'une étude lancé par Google en 2012.
Les deux comportements des équipes qui fonctionnent le mieux sont:
- liberté d'expression: prise de parole et partage de point de vue
- empathie
Ces deux facteurs amène une sécurité psychologique qui améliore la qualité de vie au travail et aussi la productivité.
Un article très complet sur l'API Gateway utilisé par Uber.
Ils ont développé leur propre API Gateway qui est en frontal de leurs micro-services écrits dans différents langages.
user access, etc
Les API Gateway peuvent être de simples routeurs mais peuvent aussi aller plus loin en incorporant de la logique métier, comme celle de Uber justement ("low level" vs "feature rich")
Dans le cycle de vie d'une requête, ils ont extraits 4 familles de composants:
- Protocol Manager: responsable de décoder et d'encoder (JSON, Thrift, Protobuf)
- Middleware: briques métier réutilisables (authentification, rate limiting, etc)
- Endpoint Handler: convertit la requête entrante dans le format attendu par le service backend
- Client: envoi la requête au service backend (validation, timeout, retries, etc)
Bubble décide de redistribuer une partie de ses bénéfices à des projets open source qu'ils utilisent en interne.
En tout ils vont donner 20K$ répartis entre 3 projets.
C'est très bien ce genre d'action, plus d'entreprises qui font des millions avec de l'open source devraient prendre exemple.
La meilleure solution serait néanmoins un financement mensuel pour aider les développeurs des projets à se projeter sur le long terme.
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.
Dans la même mouvance que Dall-E, Stable Diffusion et MidJourney, une IA pour générer des modèles 3D à partir de texte.
C'est toujours bien de voir émerger d'autres runtime car cela amène de nouvelles idées et concepts.
Par contre il ne faut pas se voiler la face, il y a très peu de chances que Deno ou Bun puissent remplacer Node.js.
L'industrie a mis des années avant de faire confiance à Node.js et aujourd'hui je vois difficilement les entreprises se tourner vers un nouveau runtime simplement pour des histoires de design ou quelques % de perfs en plus sachant que le coût d'adoption à l'échelle industriel est très élevé.
Un outil de création de base de connaissance interne dans le même genre que Notion.
Un retour d'expérience sur l'utilisation de Timescale DB pour ingérer et traiter de grosses séries temporelles.
TimescaleDB est une extension de PostgreSQL donc on retrouve facilement ses repères.
Une de leur feature extra est la compression optimisée des séries temporelles pour gagner jusqu'à 90% d'espace (!)
Une utilisation intéressante de Stable Diffusion pour compresser des images.
Stable Diffusion est un algorithme de génération d'image à partir d'un texte.
L'histoire d'une migration de AWS sur des serveurs custom.
Encore une fois, ce sont les transferts de données qui coutaient le plus cher à l'entreprise.
C'est très souvent un coût "caché" car très compliqué à évaluer.
Leur solution finale se base sur:
- serveurs bare metal pour le computing
- MinIO pour le stockage S3-like
- Cassandra pour la base de données
Les cloud comme AWS ont une tarification du traffic réseau et surtout du traffic réseau externe pour vous garder un maximum au sein de leurs écosystèmes.
Il vaut mieux se tourner vers des hebergeurs comme OVH ou Scaleway qui eux ne facturent pas le traffic https://links.aschen.tech/shaare/Q0rZJw
Après la génération d'image à partir d'un texte, maintenant Facebook propose la génération de vidéo à partir d'un texte
Plusieurs outils autour de la CI de Gitlab.
Une technique (entre autre) pour lancer sa CI Gitlab en local!
Concrètement ça lance les jobs de CI avec les bonnes images pour valider le fonctionnement en local.
(Merci Erwan!)
Un super outil pour analyser les statistiques en provenance de Github!
Statistiques développeurs, repositories, etc
Un compresseur PNG qui va modifier légèrement les couleurs de votre image pour avoir une palette plus petite.
A l'oeil ça ne se voit presque pas mais le poids de l'image peut être réduit de plus de 75%!
Meetup du CTO de BAM sur leur méthode pour réduire l'incertitude dans les cycle de développement.
En gros on est sur du développement centré autour des Epic (features) et non plus des Users Stories.
Mais surtout leur méthode implique de la modélisation de la logique applicative avec un subset de BPMN (ça ressemble à des diagrammes).
Ce langage commun utilisé par tous permet d'identifier les edge-case, de faire valider les features par le client, de discuter autour d'une feature, etc
Dans notre métier on a souvent envie de tout recommencer à 0, de faire un "gros refactor", de changer de stack technique.
Seulement si c'est fait pour les mauvaises raisons il y a de grandes chances que ça échoue et/ou coule le business.
Tant qu'il n'y a pas de contraintes techniques fortes il vaut mieux faire évoluer son legacy.
Un article qui tacle un peu la tendance d'avoir des CTO / VPE plus dans le management pur que la technique.
Il donne notamment 5 raisons:
- les capacités technique permettent un meilleur jugement sur les personnes ou les systemes
- l'importance de comprendre les enjeux d'un compromis
- plus de facilité à gagner le respect des équipes
- la passion pour la technique apporte une meilleure vision et plus de motivation
- plus facile de recruter des ingénieurs qualifiés
Le groupe Altice (SFR, etc) et Patrick Drahi ont été la cible d'un ransomware.
Pas très bon pour l'image alors que SFR se targuait de nombreuses fois de pouvoir contrer les ransomwares justement.
On y voit le mode de vie des ultra-riche:
- carte bleu plafonnée à 38000€
- tableaux de Pigasso, Kandinsky, etc
- yachts, voitures de luxe, jet privés
C'est édifiant..