Terturionsland
02Blog

Documentación que falta

Notas de lo que vamos aprendiendo. Casi todo sale de un problema concreto que nos costó más de lo esperado.

Todas
  1. ProductoLa web de un pintor solo tiene que hacer una cosa: que le llamenHice la web y la app de trabajo de Mamu, un pintor de Valencia, en cuatro días sueltos. Lo que más mejoró la web fue borrar las páginas de precios y de por qué elegirnos.
  2. IACómo construimos Zenbu, un buscador de anime que busca por lo que cuentasCatorce mil animes, un vector por serie y un LLM que reordena al final. Lo que más nos costó no fue la búsqueda semántica: fueron las secuelas con sinopsis de una línea.
  3. ArquitecturaCuatro migraciones de auth y ninguna me dolió por el loginHe cambiado de proveedor de auth cuatro veces y el login siempre fue lo fácil. Lo que se rompe es la forma de la sesión que el SDK te deja repartida por toda la app.
  4. OperaciónCinco subidas de versión de Stripe y el bug que sí compilabaEl SDK de Stripe me ha roto el build cinco veces en poco más de un año. Arreglar el error de tipos es fácil. Lo que me preocupa es lo que compila después.
  5. ProductoHe empezado con créditos tres veces y las tres he acabado con saldo en céntimosCobrar por uso con créditos se entiende muy bien en la landing y se complica en cuanto metes un segundo modelo. Este es el camino que he repetido, con la parte del dinero en coma flotante que todavía no tengo resuelta.
  6. Bases de datosRLS protegía justo los caminos que no lo necesitabanHe montado Row Level Security en Postgres dos veces y dos veces lo he quitado. El problema no era la política, era que todo lo peligroso pasaba por la conexión que se la salta.
  7. CriterioMi plantilla es una dependencia más, y la traté como si no lo fueraArranco cada proyecto clonando mi propia plantilla. Me ha ahorrado semanas, y también me ha metido el mismo bug en todos los clones durante meses sin que me enterase.
  8. CriterioLo primero que borro al clonar mi boilerplate es StripeTengo la costumbre de arrancar los proyectos quitando el checkout, el webhook y la tabla de billing. Aquí va el criterio que uso para saber cuándo no hacerlo.
  9. ArquitecturaMis contadores de dinero mentían y ninguno lanzaba un errorIncrementos que se pierden bajo carga, un coste que desaparece al deduplicar, un saldo que se evapora en cada renovación. Cuatro bugs en tres proyectos, y todos por lo mismo.
  10. IANinguna capa de abstracción me ha ahorrado una migración de modeloSeis cambios de modelo de IA en año y medio, dos intentos de taparlo con OpenRouter y LangChain, y la conclusión incómoda de que lo que se rompe no es la llamada sino lo que el modelo acepta.
  11. Bases de datosCada vez que revertí mi modelo de contratos era una pregunta que no había hechoReescribí el mismo modelo SQL de contratos más de diez veces en un año. Casi todas las marchas atrás tenían el mismo origen: mi consulta estaba decidiendo cosas del negocio sin que nadie lo supiera, empezando por mí.
  12. Bases de datosRenombrar una columna cuesta dos segundos; lo caro es todo lo que la nombraMis esquemas cambian mucho durante el primer mes y he dejado de intentar evitarlo. Lo que sí intento es que cambiarlos cueste una migración corta y no un día entero tocando componentes.
  13. SeguridadTres versiones de un acceso de invitado, y la buena todavía tenía agujerosEmpecé con un código de seis dígitos para dejar entrar a gente sin cuenta. Tardé tres versiones en separar la invitación de la sesión, y una auditoría en ver que el arreglo había abierto otro hueco.
  14. OperaciónMi smoke test pasaba porque corría en la máquina equivocadaArreglé un micrófono muerto en un .deb y la siguiente versión no arrancaba en ninguna distro moderna. El CI no lo vio porque probaba el paquete en el mismo sitio donde lo construía.
  15. IngenieríaCuatro verdes que me mintieron (y cómo los pillé)Un test que imprimía TODOS LOS TESTS OK con seis SCRIPT ERROR dentro, otro que se comparaba consigo mismo y un CI que publicaba un .deb sin micrófono. Lo que tienen en común y la costumbre que me ha dejado.
  16. RendimientoNadie mide el panel de admin, y por eso es lo primero que revientaLa página interna que usan dos personas no tiene métricas, ni revisiones, ni límites. He tenido que arreglarla en cuatro proyectos, y casi siempre por las mismas razones.
  17. Seguridad¿Y si la lista viene vacía? Lo que salió al atacar mi propia APIMe senté un día a leer mi API de transcripción buscando cómo romperla y salieron seis fallos con los tests en verde. El peor era un filtro de permisos que, con la lista vacía, devolvía el corpus entero.
  18. ArquitecturaPido cuenta para buscar anime, y sé que suena ridículoSi cada petición te cuesta dinero, necesitas saber de quién es cada una. Probé a apañarme con IPs y cookies, y al final el login fue la clave más barata que encontré.
  19. CriterioUn commit llamado "never give up!!" y otras señales de que toca soltarloPasé tres semanas construyendo un editor de bloques a mano y otras seis sin atreverme a borrarlo. De las primeras no me arrepiento; de las segundas, bastante.
  20. FrontendLa prop que nadie leeMi señal para sacar estado a un store es muy concreta: un componente que recibe una prop, no la mira y se la pasa al siguiente. Y un editor donde todo pedía store a gritos y no le hizo falta.
  21. CriterioLo que encontró Biome la primera vez que lo encendíLlevo cinco proyectos pasados de ESLint y Prettier a Biome. Me esperaba ganar velocidad, y lo que más me ha servido es que en uno de ellos la primera pasada sacó 60 errores que llevaban meses ahí.
  22. CriterioEl documento que escribí antes del código estaba mal, y para eso servíaEn integraciones con APIs ajenas escribo primero lo que no controlo y luego dedico un commit entero a comprobar si era verdad. Ese commit descubrió que 18 de 20 issues eran pull requests.