Vermutech #75
Encara és Black Friday. Ja no sé ben bé quan acaba i quan comença aquest “Friday”, però déu n’hi do. Com ja he comentat en altres edicions, estic molt satisfet amb el meu Chromebook, i he vist que ara està d’oferta a Amazon. Si t’ho estaves pensant, potser és un bon moment.
Aquest dissabte també he assistit a les jornades a11yConf a Girona, que des de GISCE-TI en som patrocinadors. Són unes conferències enfocades a l’accessibilitat digital. És un àmbit que continua sent força desconegut, i hi he après molt. També m’ha ajudat a prendre consciència de com d’invisible pot arribar a ser una barrera digital si no la vius de primera mà. Una experiència molt enriquidora.
En la part més tècnica, he estat treballant amb la integració de TimescaleDB dins l’ORM del nostre ERP. El repte és que, quan treballes amb un ERP, sovint accedeixes a registres concrets per identificador. El problema és que Timescale fragmenta la base de dades en chunks segons valors temporals. Si només tens un identificador, no pots saber en quin chunk es troba el registre, i això fa que la consulta sigui molt menys eficient.
La solució que hem aplicat és senzilla però efectiva: al propi identificador (BIGSERIAL) hi codifiquem el timestamp (fins a nivell de minut) multiplicat per un milió, i hi afegim una seqüència cíclica. A més, marquem el 62è bit per saber que aquest ID està codificat. Així, quan fem una lectura, actualització o eliminació per ID, podem extreure el timestamp i afegir una clàusula BETWEEN que ajuda Timescale a acotar millor el chunk i a fer la consulta molt més eficient.
Si t’interessa aquest enfocament i vols veure exemples o més detalls, pots demanar-ho pel canal de Telegram o deixar un comentari.
Començo amb algunes recomanacions,
💾 Programari
Snapdemo: Aquesta vegada no és una eina lliure, però l’he trobat prou senzilla i útil per fer-hi una menció. Permet crear vídeos interactius per fer demostracions o tutorials. Funciona com una extensió del navegador que enregistra la pantalla mentre l’utilitzes i, automàticament, detecta les interaccions i et genera textos d’acompanyament.
🤔 Curiositats
Bad UX World Cup: És una mena de competició on es valora qui aconsegueix la pitjor experiència d’usuari en un component tan aparentment senzill com un selector de data. Pot semblar una broma, però fa pensar.
📦 Recursos
Patterns.dev: Una col·lecció de patrons de rendiment i arquitectura per aplicacions web. Inclou tant enfocaments amb JavaScript natiu com amb frameworks, amb explicacions tècniques ben estructurades i aplicables.
📊 Enquesta
A la pregunta “Què fas quan veus ‘Hi ha una nova versió disponible’?”, la resposta va ser clara:
un 88% actualitza i creua els dits (valents!), mentre que un 13% deixa que el sistema els ho recordi més endavant.
Cap persona va confessar ignorar-ho o témer que exploti… però sabem que existeixen.
Aprofitant que he estat a l’a11yConf a Girona, on s’ha parlat molt sobre accessibilitat digital, i de com sovint no la tenim prou en compte, aquesta setmana et proposo pensar-hi un moment.
🌟 El concepte
Treballant amb un visor de mapes que carrega tiles d’un servidor TMS, vam detectar que en certes condicions la càrrega era molt més lenta del que tocava. Tot i tenir un backend àgil i recursos lleugers, la interfície es quedava enrere. El problema era que el navegador, sota HTTP/1.1, només permetia un nombre limitat de connexions simultànies per domini. I quan es generen centenars de peticions gairebé idèntiques a recursos del mateix host, això esdevé un coll d’ampolla. La solució va ser aplicar una tècnica que, tot i estar en desús en entorns moderns, encara té aplicacions molt concretes: el domain sharding.
Aquesta tècnica consisteix a repartir les peticions entre diversos subdominis que apunten al mateix origen. En lloc de servir totes les imatges des de tiles.exemple.com, es poden configurar subdominis com tile-a.exemple.com, tile-b.exemple.com, etc. Això fa que el navegador consideri cada un d’aquests com un host diferent i pugui obrir més connexions simultànies, evitant el bloqueig que es produiria si tot passés pel mateix domini.
En el cas concret del TMS, on cada tile és una petició separada i sovint se’n fan desenes en paral·lel mentre l’usuari fa zoom o es mou pel mapa, aquest límit pot degradar seriosament l’experiència. Repartint la càrrega en subdominis, es guanya fluïdesa i es redueix el temps de renderització global. Frameworks com Leaflet o OpenLayers tenen suport nadiu per a aquesta pràctica, simplement definint una llista de subdominis a la configuració del tile layer.
Ara bé, amb l’adopció generalitzada d’HTTP/2 i HTTP/3, el domain sharding ha deixat de tenir sentit en la majoria de casos. Aquests protocols permeten obrir una sola connexió per origen i enviar-hi múltiples peticions de forma multiplexada, amb menys overhead i millor aprofitament del canal. De fet, fer sharding pot empitjorar el rendiment: trenca la compressió entre recursos, obliga a establir més connexions TLS i incrementa la latència de DNS. Però en contextos on el servidor o el client no poden treballar amb protocols moderns, o quan es vol maximitzar la concurrència en entorns molt específics, continua sent una estratègia vàlida.
En aquest cas, ens va ajudar a millorar la resposta de l’aplicació sense haver de fer canvis profunds en la infraestructura. És un bon recordatori que, més enllà de les tendències actuals, algunes solucions del passat poden seguir sent útils si s’apliquen amb criteri.
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.