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..
Une caméra de 0.5 mm, avec 200x200 pixels et 30 images/seconde !
Une étude de plusieurs librairies pour gérer le state en Flutter.
(Via Pierre)
Un article assez critique sur l'organisation habituelle des Product/Feature Team.
Une de ses critique est que les Feature Team devraient plutôt se focaliser sur des problèmes à régler pour améliorer le business que sur des roadmap avec des features priorisées.
Il insiste aussi sur le rôle du Product Manager qui doit avoir une connaissance approfondi:
- du client
- de la donnée
- de l'industrie
- du business en particulier
Il a un rôle de designer du produit et de facilitateur car l'objectif est toujours de responsabiliser les équipes au maximum pour améliorer l'implication.
Un outil pour release automatiquement et gérer les releases Github via des labels sur les Pull Requests.
L'outil est très complet et supporte tout pleins de choses:
- releases canary (test) ou next (release candidate en plus des releases normales
- création des labels sur les repo
- support des anciennes versions majeures
Une excellente vidéo de ScienceEtonnante sur un système chimique simple qui coche les 4 critère de la vie.
(Merci Ru. pour le partage)