L’article met en lumière un piège courant en JavaScript : l’utilisation de Array.includes dans une boucle (comme source.some(item => target.includes(item))) peut devenir extrêmement coûteuse en performance avec des tableaux volumineux, car la complexité algorithmique passe à *O(nm). Par exemple, avec des tableaux de 60 000 éléments, l’exécution peut prendre plusieurs secondes. La solution consiste à utiliser des structures de données optimisées pour des recherches en temps constant, comme un objet, une Map, ou mieux, un Set (new Set(target)), réduisant la complexité à O(n + m)** et rendant le code quasi instantané même pour de très grands jeux de données. Une astuce simple, mais cruciale pour éviter des goulots d’étranglement inattendus dans le code JavaScript.
Sean Goedecke y explique que le bon design système repose sur la simplicité, la minimisation de l’état (state) et l’utilisation judicieuse de composants éprouvés (bases de données, caches, files d’attente, etc.). Un bon design se remarque surtout par son absence de problèmes et sa discrétion : si tout fonctionne sans accroc et semble plus simple que prévu, c’est souvent signe de réussite. L’auteur insiste sur l’importance de centraliser la gestion de l’état (via une base de données bien structurée et indexée), d’éviter la complexité inutile, et de privilégier des solutions robustes plutôt que des astuces sophistiquées. Les opérations lentes doivent être déléguées à des tâches en arrière-plan, et le cache utilisé avec parcimonie. Enfin, il souligne que les "hot paths" (chemins critiques) méritent une attention particulière, tout comme la journalisation et la gestion des échecs (killswitches, retries). En résumé, un bon design système est souvent invisible, mais efficace et maintenable sur le long terme.
L'article explique comment utiliser et interpréter les plans d'exécution dans PostgreSQL pour optimiser les performances des requêtes. Il commence par souligner l'importance de l'utilisation de la commande EXPLAIN ANALYZE pour comprendre comment PostgreSQL exécute une requête. L'article détaille les différents éléments d'un plan d'exécution, tels que les scans séquentiels et les scans d'index, et explique comment lire ces plans pour identifier les goulots d'étranglement. Il fournit également des conseils pour optimiser les requêtes, comme l'ajout d'index et la réécriture des requêtes pour une meilleure performance. Enfin, l'article aborde les options utiles de EXPLAIN et donne des pistes pour résoudre les problèmes courants identifiés dans les plans d'exécution.
L'article décrit comment une équipe a optimisé le temps de récupération des données d'API dans un projet Symfony, réduisant le temps de traitement de 40 minutes à seulement 10 minutes. En utilisant des requêtes concurrentes et des techniques de parallélisation, ils ont pu gérer plusieurs appels API simultanément, améliorant ainsi considérablement l'efficacité et les performances de leur application. Cette approche a permis de réduire le temps d'exécution global et d'optimiser la gestion des ressources.
L'article explique les concepts clés du Site Reliability Engineering (SRE) tels que les SLO (Service Level Objectives), SLI (Service Level Indicators), et Error Budget, introduits par Google. Il souligne l'importance de distinguer les SLA (Service Level Agreements), qui sont des contrats avec des pénalités financières, des SLO, qui sont des objectifs internes pour la fiabilité des services. L'article met l'accent sur l'identification des Critical User Journeys (CUJ), qui sont les parcours utilisateurs critiques pour le succès d'un service. Les SLI sont utilisés pour mesurer la performance de ces parcours, tandis que les SLO définissent des objectifs réalistes pour ces mesures. Enfin, l'Error Budget est présenté comme un outil pour gérer la fiabilité des services, permettant aux équipes de prendre des risques calculés tant que les objectifs de fiabilité sont respectés.
L'article explore les techniques pour rendre les animations SVG plus rapides, plus simples et plus faciles à gérer. L'auteur s'inspire des dessins animés classiques pour créer des animations modernes en utilisant des outils comme CSS et SVG. Il souligne l'importance de commencer avec un design propre et d'optimiser les fichiers SVG en réduisant les points d'ancrage et en utilisant des outils comme SVGOMG pour minimiser la taille des fichiers. L'article détaille également comment structurer le code SVG en couches pour faciliter l'animation et la maintenance, tout en réutilisant des éléments pour améliorer l'efficacité et la performance.
En 2024, Redis a changé de licence, incitant l'auteur à explorer PostgreSQL comme alternative pour gérer des données volatiles, offrant une meilleure organisation des données et simplifiant la stack technique. PostgreSQL permet de structurer les données de manière plus élégante grâce à l'héritage de tables et gère l'expiration des données via des requêtes planifiées, bien que cela nécessite une gestion manuelle. Bien que Redis soit plus performant, PostgreSQL, avec des tables UNLOGGED, offre des performances suffisantes pour la plupart des applications, tout en simplifiant l'infrastructure et en évitant les problèmes de licence.
La scalabilité est essentielle pour la survie des applications, permettant de gérer plus d'utilisateurs, de données ou de fonctionnalités sans dégradation des performances. React, avec son architecture basée sur les composants, le Virtual DOM et un flux de données unidirectionnel, offre une base solide pour construire des applications web évolutives. L'article présente les meilleures pratiques pour des applications React évolutives : l'optimisation de la taille des bundles avec le code splitting et le lazy loading, une gestion efficace de l'état, et l'utilisation de composants et de hooks personnalisés.
Un très bon tutoriel pour l’installation d’Anubis
La notation Big O est essentielle pour les développeurs afin de comprendre et optimiser la performance du code, en transformant la manière dont les ressources physiques sont consommées. Elle permet d'anticiper les problèmes de performance et de choisir les meilleures solutions algorithmiques en fonction des priorités comme la vitesse, la mémoire ou la lisibilité. En utilisant Big O, les développeurs peuvent passer d'un code qui "fonctionne" à un code qui "fonctionne efficacement".
L'autrice utilise EXPLAIN avant de lancer la requête - ce qui calcule son plan sans l'exécuter - afin de ne pas surcharger sa base de données avec une requête lente
Elle utilise EXPLAIN ANALYZE après l'exécution de sa requête afin de comprendre pourquoi elle est lente.
La syntaxe présentée est celle de PostgreSQL - à adapter donc selon le SGBD.
Microsoft a annoncé la migration du compilateur TypeScript de JavaScript vers Go, promettant une amélioration de performance de 10x. Cependant, cette amélioration concerne uniquement la vitesse de compilation du compilateur TypeScript, et non la performance d'exécution du code TypeScript lui-même. Le passage à Go permet de mieux gérer les tâches intensives en CPU grâce à ses goroutines et son modèle de concurrence natif, contrairement à l'architecture mono-threadée de Node.js. Cette migration soulève des questions sur la compatibilité future avec les navigateurs et l'écosystème des plugins TypeScript, mais elle illustre l'importance d'adapter les choix technologiques aux besoins spécifiques des projets en évolution
Tout est dans le titre
Utilisation de l'attribut "rel" et des différentes valeurs permises
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre