Hi ha diverses estratègies per fer-ho, però sovint els programadors es fan alguna funció per agafar les dades de la base de dades, una altra per generar el csv, i potser alguna altra per servir-lo al client.

Al principi tot va bé, però donat que el volum de dades acostuma a créixer amb el temps arriba un moment que se'ls hi omple la memòria o els hi salten els timeouts, etc. I ens demanen als de sistemes que augmentem els recursos quan tot és culpa d'una mala estratègia.

Una solució és partir la tasca, generar el fitxer en bach i després oferir el resultat per descarregar.

Tradicionalment les distribucions han portat sempre versions força antigues de node. Per poder desenvolupar fent servir les eines actuals, fins ara sempre manegava les versions de node instal·lades amb nvm o darrerament amb fnm, ambdues són prou útils si et cal anar canviant de versió segons el projecte.

Fa un temps em vaig topar amb una enquesta d'autoavaluació de l'esperit crític, però com que em feia una mica de mandra apuntar-me les respostes i després sumar les puntuacions de cadascuna, vaig decidir fer-me una senzilla aplicació en react i així passar l'estona. És molt útil fer-li fer al cunyat de torn per saber si val la pena raonar-hi o no ;)

Si hi ha una cosa que m'emprenya quan els clients et donen accés als seus projectes web per desenvolupar millores, arreglar bugs, etc, és haver-se de baixar desenes o fins i tot centenars de gigabytes de fitxers, el 90% imatges, vídeos o altres recursos, que només ocupen espai i no tenen cap utilitat per fer la feina.

O també en projectes on sovint vas replicant l'entorn de producció a preproducció i després de mitja hora esperant copiant fitxers peta tot perquè ja no hi cap ni un byte més al disc dur... Fitxers duplicats que no serveixen per res.

Feia dies que veia entrades estranyes al log del ejabberd i al final m'he decidit a bannejar les ips d'origen amb el fail2ban.

Treballant en Drupal a vegades ens trobem que ens cal processar grans quantitats de nodes per fer alguna tasca. Per aquests casos Drupal proveeix la Batch api o les cues segons ens convingui en cada cas. Però aquesta vegada es tractava d'exportar uns nodes a Excel i amb el temps la quantitat de dades a exportar anava augmentant (els nois no volien filtres, però òbviament els van acabar demanant, ja coneixem als usuaris...).

Sovint a la feina alternem entre projectes de varis clients, manteniments, bugs, etc. Tot són flors i violes fins que a final de mes et demanen un registre d'hores i ja està liada, et passes aquell dia mirant mails i buscant a stackoverflow com es feia aquell `git log` tant maco on sortien els teus commits entre dues dates, però t'ho miris com t'ho miris sempre et falten hores per tot arreu.

Avui ens hem trobat amb una situació un pel estranya al activar les caches d'un projecte abans de posar-lo en producció.

Es tracta d'una web on hi ha una sèrie de cursos on els usuaris s'hi poden apuntar. Els templates del content type curs estan personalitzats per mostrar informació diferent en funció de si l'usuari s'hi ha apuntat o no, de l'estat de la inscripció, etc.

En primer lloc afegim Prism al projecte:

yard add prismjs
# o bé
npm install prismjs --save

Després definim la funció de highlight a la configuració de markdownit del fitxer nuxt.config.js del projecte:

Molts dels projectes amb els que treballem requereixen executar certes comandes després d'actualitzar el codi font.

En aquest cas ens calia fer un composer install en el cas que s'hagués actualitzat alguna dependència del projecte.

Per fer-ho crearem el següent script pel hook post-merge a .git/hooks/post-merge assegurant-nos que és executable per l'usuari que fa el pull: