Temas que cruzan áreas

La misma pregunta reaparece en áreas distintas. Estas etiquetas cortan transversalmente los ocho campos.

Planificación y decisión

Definir un problema, priorizar y elegir qué no hacer

16 artículos

También aparece en: Fundamentos de producto · Apps móviles · Seguridad · IA en la práctica · Oficio, calidad y equipos

001De una idea a un problema que se puede resolverAntes de elegir tecnología, escribe quién sufre el problema, qué hace hoy en su lugar y cómo sabrás que lo has resuelto.002El prototipo más pequeño que demuestra algoUn prototipo existe para responder a una pregunta peligrosa, no para lucir un producto: por eso puede ser feo, manual e incompleto.003Escribir una especificación que el equipo lea de verdadUna buena especificación describe comportamiento y criterios de aceptación, no maquetas: y se mide en páginas, no en decenas.004Elegir qué no construirLa capacidad de decir no es lo que separa un producto que se lanzó de uno que se desarrolla para siempre.005Cuánto tardará: estimaciones sin ilusionesUna buena estimación es un rango con supuestos visibles, que se actualiza a medida que crece el conocimiento, no un único número dicho una vez.006Construir, comprar o integrarConstruye solo lo que te hace distintivo; todo lo demás: cómpralo, intégralo o renuncia a ello.007Investigación de usuarios en tres díasCinco conversaciones de media hora con quienes hacen el trabajo revelan más que una encuesta de mil respuestas.009Deuda técnica: cuándo tomarla y cuándo pagarlaLa deuda técnica es un instrumento de financiación legítimo, siempre que se tome a conciencia, se registre y tenga una fecha en que se hable de su pago.010Primera versión: qué debe entrarLa primera versión debe hacer una cosa de principio a fin, y hacerla de un modo en que puedas confiar.011Cómo priorizar cuando todos gritanPriorizar no es una lista ordenada sino una regla de decisión que todos conocen de antemano; si no, la fija quien habla más fuerte.012De la especificación a tareas con las que empezar a trabajarUna buena tarea termina en un resultado que puedes ejecutar y comprobar, y dura un día o dos, ni una semana ni una hora.021Nativa, multiplataforma o un sitio web móvilLa elección la fija cuánto necesitas del dispositivo y el tamaño del equipo, no qué tecnología está de moda este año.061Un modelo de amenazas en una horaEsboza qué tienes, quién podría quererlo y dónde cruza un límite, y obtendrás una lista de prioridades real en vez de una corazonada.075Cómo elegir un modelo, y por qué no es la primera decisiónEmpieza con el modelo más potente para comprobar si la tarea es resoluble, y solo entonces baja a uno más barato hasta que la calidad se rompa.097Elegir tecnología sin arrepentirse en dos añosElige por el equipo, la madurez y la comunidad, y lo aburrido y familiar casi siempre supera a lo nuevo y emocionante.100Qué decide de verdad si un proyecto tiene éxitoNo la tecnología ni el tamaño del equipo, sino la claridad del objetivo, los ciclos de retroalimentación cortos y una persona responsable de decidir.

Medición

Saber si algo mejoró de verdad

12 artículos

También aparece en: Fundamentos de producto · Apps móviles · Infraestructura, nube y DevOps · IA en la práctica · Oficio, calidad y equipos

001De una idea a un problema que se puede resolverAntes de elegir tecnología, escribe quién sufre el problema, qué hace hoy en su lugar y cómo sabrás que lo has resuelto.002El prototipo más pequeño que demuestra algoUn prototipo existe para responder a una pregunta peligrosa, no para lucir un producto: por eso puede ser feo, manual e incompleto.008Métricas de éxito que no mientenElige una métrica ligada al valor que recibió el usuario, y a su lado una que te impida romper otra cosa.025Rendimiento en móvil: memoria, batería y la sensación de velocidadEn las apps, la sensación la fijan el tiempo de arranque y la fluidez del desplazamiento, y ambos los rompen las imágenes y el trabajo que corre en el hilo principal.029Monitorización de fallos y errores en una appSin reporte automático de fallos te enteras de los problemas por las valoraciones de la tienda; es decir, demasiado tarde.052Monitorización y observabilidad: saber que algo se rompió antes que el clienteTres tipos de señal —métricas, registros y trazas— y una pregunta que deben responder: qué ocurre ahora y por qué.054Costes de la nube: adónde va el dineroLa mayor parte de la factura viene de tres sitios: recursos que corren y nadie necesita, almacenamiento que crece sin política, y tráfico entre regiones.079Evaluación: cómo saber que el sistema mejoróSin un conjunto de evaluación fijo, cada cambio es una creencia, y una mejora en un área ocultará una regresión en otra.081Clasificación y extracción: las tareas que más devuelvenAntes de construir un chat, comprueba si el problema es en realidad clasificar una consulta o extraer campos de un documento: dos tareas simples que devuelven valor inmediato.082Alucinaciones: por qué ocurren y qué ayuda de verdadUn modelo al que se le hace una pregunta sin respuesta producirá una respuesta plausible; la solución no es pedirle que no cometa errores, sino darle una fuente y una forma de decir que no.088Experimentos: cómo saber que el cambio mejoró algoCompara dos versiones en el mismo tráfico al mismo tiempo; cualquier comparación de 'antes y después' también mide el mundo, no solo a ti.100Qué decide de verdad si un proyecto tiene éxitoNo la tecnología ni el tamaño del equipo, sino la claridad del objetivo, los ciclos de retroalimentación cortos y una persona responsable de decidir.

Usuarios

Qué ocurre del lado de la persona que usa el sistema

11 artículos

También aparece en: Fundamentos de producto · Web y frontend · Apps móviles · Seguridad · IA en la práctica

007Investigación de usuarios en tres díasCinco conversaciones de media hora con quienes hacen el trabajo revelan más que una encuesta de mil respuestas.014Rendimiento en el navegador: qué frena de verdad un sitioEn la mayoría de los sitios lentos el culpable no es el código sino el peso: imágenes grandes, fuentes y scripts de terceros.015Accesibilidad: el mínimo que no puedes saltarteLa mayor parte de la accesibilidad viene de escribir HTML correcto, y la mayoría de los fallos vienen de reemplazar elementos estándar por algo dibujado para parecerse a ellos.016Diseño adaptable sin dolorEmpieza por la pantalla pequeña, deja que el contenido decida dónde se rompe, y no diseñes para una lista de dispositivos.017SEO técnico para sitios modernosAntes de las palabras clave, asegúrate de que el buscador llega a la página, la lee y entiende qué es.019Formularios: la parte donde más se rompe a los usuariosUn buen formulario pide poco, comprueba en el momento adecuado, explica un error donde ocurrió, y no borra lo tecleado.020Hebreo y de derecha a izquierda: qué se rompe y cómo arreglarloLa mayoría de los fallos de derecha a izquierda vienen de usar izquierda y derecha en vez de inicio y fin, y de texto mixto que choca en una línea.023Notificaciones push sin perder usuariosUna notificación justificada es una cuya ausencia el usuario lamentaría; todo lo demás lleva a apagar el permiso, algo casi irreversible.028Experiencia de usuario en móvil: qué cambia frente a una pantalla grandeEn el móvil el usuario está de pie, con prisa, sujetando con una mano y a veces al sol, y eso cambia cada decisión.063Contraseñas, doble factor y sesionesGuarda las contraseñas con un algoritmo lento dedicado, habilita el doble factor, y haz posible cerrar sesión en todos los dispositivos.084Diseñar una interfaz para un sistema que no siempre aciertaUna buena interfaz muestra la certeza variable, permite la corrección fácil, y no presenta una suposición como un hecho.

Arquitectura

Cómo se dividen los componentes y cómo se comunican

16 artículos

También aparece en: Web y frontend · Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · IA en la práctica · Oficio, calidad y equipos

013Elegir entre sitio estático, sitio renderizado en servidor y app de navegadorCuanto más fijo es el contenido, más simple debe ser la arquitectura; y cada capa de dinamismo que añades la pagas todos los días desde entonces.018Gestión de estado en una app webLa mayor parte de lo que se llama estado son datos de servidor guardados en el sitio equivocado; sepáralos y la mitad de la complejidad desaparece.021Nativa, multiplataforma o un sitio web móvilLa elección la fija cuánto necesitas del dispositivo y el tamaño del equipo, no qué tecnología está de moda este año.022Trabajar sin red: una app que no se rompe en un ascensorDiseña la app en torno al supuesto de que no hay red, y obtendrás gratis una app que además se siente rápida cuando la hay.034Bases de datos: elegir y no arrepentirseEn la mayoría de los casos una base de datos relacional es la respuesta correcta, y cualquier otra elección necesita un motivo que puedas decir en una frase.036Colas y trabajos en segundo planoTodo lo que dure más de un segundo y no haga falta para la respuesta al usuario pertenece a una cola, no a la petición.037Caché: acelerar sin servir datos viejosAntes de añadir una caché, decide cuánto tiempo un dato viejo sigue siendo aceptable: es la única pregunta que de verdad importa.039Un servicio o muchos: cuándo dividirEmpieza con un sistema bien ordenado. Divide solo cuando haya dolor real: equipos que se bloquean entre sí o un componente que necesita otra escala.040Diseñar un modelo de datos que dure añosUn buen modelo representa la realidad del negocio, no la primera pantalla que te pidieron construir.042Archivos y almacenamiento de objetosLos archivos no pertenecen a la base de datos ni al disco del servidor, sino al almacenamiento de objetos con direcciones firmadas.055Escala: horizontal, vertical y lo que de verdad hace faltaAntes de escalar, mide dónde está el cuello de botella; en la mayoría de los sistemas está en la base de datos o en una consulta, no en el número de servidores.076Conectar tu conocimiento al modelo: recuperación sin palabras grandesEl modelo no conoce tus documentos; necesitas encontrar los fragmentos relevantes para cada pregunta y adjuntarlos a la indicación.077Agentes: cuándo dejar que el sistema actúe soloUn agente decide por sí mismo qué acciones realizar; toda la recompensa y el riesgo están en los permisos que le diste.087Automatización de procesos: dónde un modelo añade y dónde sobraSi el proceso es fijo y claro, escribe código; un modelo vale exactamente en los lugares donde hace falta juicio sobre texto no estructurado.089Arquitectura de un sistema basado en modelosEl modelo es un componente dentro de un sistema ordinario, y el sistema a su alrededor es la mayor parte del trabajo y del riesgo.096Nombres, estructura y código al que se puede volverEl código se lee mucho más de lo que se escribe, por eso un nombre preciso y una estructura predecible valen más que cualquier ingenio.

Datos

Estructura, almacenamiento e integridad de la información

13 artículos

También aparece en: Web y frontend · Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · Seguridad · IA en la práctica

018Gestión de estado en una app webLa mayor parte de lo que se llama estado son datos de servidor guardados en el sitio equivocado; sepáralos y la mitad de la complejidad desaparece.022Trabajar sin red: una app que no se rompe en un ascensorDiseña la app en torno al supuesto de que no hay red, y obtendrás gratis una app que además se siente rápida cuando la hay.026Almacenamiento local y datos sensibles en el dispositivoDa por hecho que el dispositivo se perderá o será vulnerado: lo que se guarde en local debe ser mínimo, cifrado y revocable en remoto.034Bases de datos: elegir y no arrepentirseEn la mayoría de los casos una base de datos relacional es la respuesta correcta, y cualquier otra elección necesita un motivo que puedas decir en una frase.035Migraciones de esquema sin tiempo de caídaCambia el esquema en pasos compatibles hacia atrás: añade, rellena, cambia, y solo al final: elimina.040Diseñar un modelo de datos que dure añosUn buen modelo representa la realidad del negocio, no la primera pantalla que te pidieron construir.043Búsqueda: cuándo la base de datos deja de ser suficienteLa búsqueda de texto libre con relevancia, errores tipográficos y múltiples filtros es un mundo propio, y no todo sistema lo necesita.046Trabajar con dinero: pagos y cargosNunca guardes datos de tarjeta, nunca confíes en una cantidad que llegó del cliente, y mantén siempre un registro inmutable de eventos.053Copia de seguridad y recuperación: lo que no se prueba no existeUna copia de seguridad no es una política; una política es cuántos datos puedes perder y cuánto tiempo puedes estar caído, y la prueba de que lo cumpliste.069Privacidad desde el diseño: recoger menosLa forma más barata de proteger la información es no recogerla; y cada campo recopilado debe tener una finalidad, un propietario y una fecha de borrado.076Conectar tu conocimiento al modelo: recuperación sin palabras grandesEl modelo no conoce tus documentos; necesitas encontrar los fragmentos relevantes para cada pregunta y adjuntarlos a la indicación.081Clasificación y extracción: las tareas que más devuelvenAntes de construir un chat, comprueba si el problema es en realidad clasificar una consulta o extraer campos de un documento: dos tareas simples que devuelven valor inmediato.083Datos: de dónde vienen y qué hacer cuando no hayEn la mayoría de los proyectos los datos existen pero están dispersos, sin etiquetar y sin limpiar, y esa es la etapa que se lleva la mayor parte del tiempo.

Rendimiento

Velocidad, carga y cómo se siente para el usuario

11 artículos

También aparece en: Web y frontend · Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · IA en la práctica

013Elegir entre sitio estático, sitio renderizado en servidor y app de navegadorCuanto más fijo es el contenido, más simple debe ser la arquitectura; y cada capa de dinamismo que añades la pagas todos los días desde entonces.014Rendimiento en el navegador: qué frena de verdad un sitioEn la mayoría de los sitios lentos el culpable no es el código sino el peso: imágenes grandes, fuentes y scripts de terceros.017SEO técnico para sitios modernosAntes de las palabras clave, asegúrate de que el buscador llega a la página, la lee y entiende qué es.025Rendimiento en móvil: memoria, batería y la sensación de velocidadEn las apps, la sensación la fijan el tiempo de arranque y la fluidez del desplazamiento, y ambos los rompen las imágenes y el trabajo que corre en el hilo principal.031Archivos, medios y subidas desde el dispositivoUna foto de la cámara pesa decenas de veces más de lo necesario; trátala en el dispositivo antes de que toque la red.037Caché: acelerar sin servir datos viejosAntes de añadir una caché, decide cuánto tiempo un dato viejo sigue siendo aceptable: es la única pregunta que de verdad importa.043Búsqueda: cuándo la base de datos deja de ser suficienteLa búsqueda de texto libre con relevancia, errores tipográficos y múltiples filtros es un mundo propio, y no todo sistema lo necesita.045Carga: límites de tasa y autoprotecciónUn sistema sano rechaza pronto y con claridad, en vez de derrumbarse lentamente bajo una carga que no puede soportar.055Escala: horizontal, vertical y lo que de verdad hace faltaAntes de escalar, mide dónde está el cuello de botella; en la mayoría de los sistemas está en la base de datos o en una consulta, no en el número de servidores.080Costes y latencia en sistemas basados en modelosLa mayor parte del coste viene del texto que entra, y la mayor parte de la latencia del que sale; por eso las dos soluciones son distintas.086Modelos pequeños, locales y en el bordeCuando el volumen es grande, la latencia es crítica o los datos no pueden salir, un modelo pequeño en tu lado supera a uno grande en la nube.

Fiabilidad

Qué pasa cuando algo se rompe

13 artículos

También aparece en: Fundamentos de producto · Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · IA en la práctica

010Primera versión: qué debe entrarLa primera versión debe hacer una cosa de principio a fin, y hacerla de un modo en que puedas confiar.022Trabajar sin red: una app que no se rompe en un ascensorDiseña la app en torno al supuesto de que no hay red, y obtendrás gratis una app que además se siente rápida cuando la hay.036Colas y trabajos en segundo planoTodo lo que dure más de un segundo y no haga falta para la respuesta al usuario pertenece a una cola, no a la petición.041Fiabilidad en las llamadas a servicios externosCada llamada que sale fallará en algún momento; la única pregunta es si planificaste qué ocurre entonces.044Correo saliente, mensajes y webhooksLos mensajes salientes son una interfaz pública: necesitan una cola, reintentos y un registro de qué se envió a quién.045Carga: límites de tasa y autoprotecciónUn sistema sano rechaza pronto y con claridad, en vez de derrumbarse lentamente bajo una carga que no puede soportar.051Estrategias de despliegue: azul-verde, canario y gradualUn buen despliegue se mide por la capacidad de revertir rápido, no por la velocidad de salir.053Copia de seguridad y recuperación: lo que no se prueba no existeUna copia de seguridad no es una política; una política es cuántos datos puedes perder y cuánto tiempo puedes estar caído, y la prueba de que lo cumpliste.056Redes y certificados: dominio, DNS y HTTPSLa mayoría de los incidentes de 'el sitio no carga' son un dominio, un certificado caducado o el enrutamiento, no el código.058Revisión de incidentes sin buscar culpablesTras cada incidente merece la pena una hora de revisión escrita centrada en el sistema, no en la persona; si no, el mismo incidente volverá.059Alta disponibilidad y recuperación ante desastresDecide cuánto te cuesta una hora de caída y solo entonces decide cuánta redundancia compras.082Alucinaciones: por qué ocurren y qué ayuda de verdadUn modelo al que se le hace una pregunta sin respuesta producirá una respuesta plausible; la solución no es pedirle que no cometa errores, sino darle una fuente y una forma de decir que no.089Arquitectura de un sistema basado en modelosEl modelo es un componente dentro de un sistema ordinario, y el sistema a su alrededor es la mayor parte del trabajo y del riesgo.

Seguridad

Pensar como un atacante antes de que él lo haga

19 artículos

También aparece en: Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · Seguridad · IA en la práctica

026Almacenamiento local y datos sensibles en el dispositivoDa por hecho que el dispositivo se perderá o será vulnerado: lo que se guarde en local debe ser mínimo, cifrado y revocable en remoto.038Autenticación y autorización: quién eres y qué tienes permitidoIdentidad y autorización son dos preguntas distintas, y la mayoría de las brechas vienen de que la segunda se comprueba en la interfaz y no en el servidor.046Trabajar con dinero: pagos y cargosNunca guardes datos de tarjeta, nunca confíes en una cantidad que llegó del cliente, y mantén siempre un registro inmutable de eventos.056Redes y certificados: dominio, DNS y HTTPSLa mayoría de los incidentes de 'el sitio no carga' son un dominio, un certificado caducado o el enrutamiento, no el código.057Gestionar secretos y clavesUn secreto en el repositorio de código es un secreto filtrado, aunque el repositorio sea privado y aunque lo borraras después.061Un modelo de amenazas en una horaEsboza qué tienes, quién podría quererlo y dónde cruza un límite, y obtendrás una lista de prioridades real en vez de una corazonada.062Los diez fallos que se repiten en cada auditoríaLa mayoría de los hallazgos no son sofisticados: permisos no comprobados en el servidor, entrada que llega a una consulta, y bibliotecas viejas.063Contraseñas, doble factor y sesionesGuarda las contraseñas con un algoritmo lento dedicado, habilita el doble factor, y haz posible cerrar sesión en todos los dispositivos.064Inyecciones: separar una instrucción de los datosCada lugar donde una cadena del usuario se ensambla en un comando es una brecha; la solución son parámetros, no filtrado.065Asegurar las interfaces públicasUna interfaz abierta a internet se escanea automáticamente desde el primer día; da por hecho que cada ruta se llamará, en cualquier orden, con cualquier entrada.066La cadena de suministro del códigoTu código es una minoría de lo que corre en producción; la mayor parte del riesgo está en los paquetes que trajiste y en las herramientas que los construyeron.067Cifrado: cuándo, dónde y cómo no equivocarseUsa bibliotecas conocidas con valores por defecto modernos, y no inventes nada; casi todo fallo de cifrado es un fallo de uso.068Permisos en la nube: la regla más importante es el mínimoLa mayoría de los incidentes graves en la nube empiezan con una identidad que tiene más permisos de los que necesita y sin caducidad.070Seguridad en el navegador: protecciones que se activan en las cabecerasGran parte de los ataques del lado del cliente se bloquean con unas pocas cabeceras de respuesta y unos ajustes correctos de las cookies.071Seguridad del equipo: donde empiezan la mayoría de las brechasIncluso un sistema seguro se vulnera a través del dispositivo de un empleado, un correo de phishing o una cuenta sin doble factor.072Pruebas de seguridad: qué pedir y cuándoEl escaneo automático es higiene continua; una prueba de penetración es un evento enfocado, y ambos necesitan un objetivo escrito.073Seguridad en sistemas basados en modelosUn modelo añade dos riesgos nuevos: contenido externo interpretado como una instrucción, y salida que llega a un lugar sensible sin comprobación.074Prepararse para un incidente antes de que ocurraDurante un incidente no hay tiempo para decidir quién decide; el papel escrito una mañana tranquila es la diferencia entre una hora y una semana.077Agentes: cuándo dejar que el sistema actúe soloUn agente decide por sí mismo qué acciones realizar; toda la recompensa y el riesgo están en los permisos que le diste.

Privacidad

Recoger menos y proteger lo que sí se recoge

5 artículos

También aparece en: Apps móviles · Infraestructura, nube y DevOps · Seguridad · IA en la práctica

026Almacenamiento local y datos sensibles en el dispositivoDa por hecho que el dispositivo se perderá o será vulnerado: lo que se guarde en local debe ser mínimo, cifrado y revocable en remoto.060Registros: guardar bien y encontrar rápidoUn buen registro está estructurado, identificado con un ID de petición, guardado durante un tiempo definido, y libre de información personal que no tiene motivo de estar ahí.067Cifrado: cuándo, dónde y cómo no equivocarseUsa bibliotecas conocidas con valores por defecto modernos, y no inventes nada; casi todo fallo de cifrado es un fallo de uso.069Privacidad desde el diseño: recoger menosLa forma más barata de proteger la información es no recogerla; y cada campo recopilado debe tener una finalidad, un propietario y una fecha de borrado.085Sesgo, equidad y responsabilidad en el uso de modelosUn modelo refleja lo que vio; por eso las decisiones que afectan a personas requieren comprobación por segmentos, una persona en el bucle y documentación.

Coste

Cuánto cuesta y por qué crece

7 artículos

También aparece en: Fundamentos de producto · Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · IA en la práctica

006Construir, comprar o integrarConstruye solo lo que te hace distintivo; todo lo demás: cómpralo, intégralo o renuncia a ello.031Archivos, medios y subidas desde el dispositivoUna foto de la cámara pesa decenas de veces más de lo necesario; trátala en el dispositivo antes de que toque la red.042Archivos y almacenamiento de objetosLos archivos no pertenecen a la base de datos ni al disco del servidor, sino al almacenamiento de objetos con direcciones firmadas.054Costes de la nube: adónde va el dineroLa mayor parte de la factura viene de tres sitios: recursos que corren y nadie necesita, almacenamiento que crece sin política, y tráfico entre regiones.075Cómo elegir un modelo, y por qué no es la primera decisiónEmpieza con el modelo más potente para comprobar si la tarea es resoluble, y solo entonces baja a uno más barato hasta que la calidad se rompa.080Costes y latencia en sistemas basados en modelosLa mayor parte del coste viene del texto que entra, y la mayor parte de la latencia del que sale; por eso las dos soluciones son distintas.086Modelos pequeños, locales y en el bordeCuando el volumen es grande, la latencia es crítica o los datos no pueden salir, un modelo pequeño en tu lado supera a uno grande en la nube.

Pruebas

Detectar fallos antes de que lleguen a producción

6 artículos

También aparece en: Infraestructura, nube y DevOps · Seguridad · IA en la práctica · Oficio, calidad y equipos

050Una tubería automatizada de construcción y despliegueCada fusión debería disparar la misma secuencia: construcción, pruebas, comprobaciones de seguridad, despliegue; sin un solo paso manual en medio.062Los diez fallos que se repiten en cada auditoríaLa mayoría de los hallazgos no son sofisticados: permisos no comprobados en el servidor, entrada que llega a una consulta, y bibliotecas viejas.072Pruebas de seguridad: qué pedir y cuándoEl escaneo automático es higiene continua; una prueba de penetración es un evento enfocado, y ambos necesitan un objetivo escrito.079Evaluación: cómo saber que el sistema mejoróSin un conjunto de evaluación fijo, cada cambio es una creencia, y una mejora en un área ocultará una regresión en otra.091Pruebas: cuántas, cuáles y cuáles no valen la penaInvierte en una mayoría de pruebas que ejerciten tu lógica, algunas de integración, y muy pocas de extremo a extremo.098Calidad sin burocracia: cómo no romper lo que funcionaLas regresiones se previenen con tres cosas: pruebas automáticas, publicaciones pequeñas y frecuentes, y la capacidad de revertir rápido.

Despliegue

Cómo el código llega a producción y cómo se revierte

8 artículos

También aparece en: Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · Oficio, calidad y equipos

030Despliegue gradual e interruptores de capacidadPublica a un pequeño porcentaje, observa las métricas y expande; y mantén la capacidad de apagar una función sin publicar una versión.035Migraciones de esquema sin tiempo de caídaCambia el esquema en pasos compatibles hacia atrás: añade, rellena, cambia, y solo al final: elimina.047Entornos: desarrollo, pruebas y producciónTres entornos construidos desde la misma definición, que difieren solo en configuración y datos; cualquier otra diferencia es un fallo que espera ser encontrado.048Contenedores: qué aportan y cuándo sobranUn contenedor empaqueta la app con todo lo que necesita para correr, de modo que se comporta igual en todas partes.049Infraestructura como códigoSi no puedes reproducir el entorno desde un archivo en el control de versiones, no tienes infraestructura sino un historial de clics.050Una tubería automatizada de construcción y despliegueCada fusión debería disparar la misma secuencia: construcción, pruebas, comprobaciones de seguridad, despliegue; sin un solo paso manual en medio.051Estrategias de despliegue: azul-verde, canario y gradualUn buen despliegue se mide por la capacidad de revertir rápido, no por la velocidad de salir.098Calidad sin burocracia: cómo no romper lo que funcionaLas regresiones se previenen con tres cosas: pruebas automáticas, publicaciones pequeñas y frecuentes, y la capacidad de revertir rápido.

Monitorización

Saber qué está pasando ahora y por qué

4 artículos

También aparece en: Apps móviles · Infraestructura, nube y DevOps · IA en la práctica

029Monitorización de fallos y errores en una appSin reporte automático de fallos te enteras de los problemas por las valoraciones de la tienda; es decir, demasiado tarde.052Monitorización y observabilidad: saber que algo se rompió antes que el clienteTres tipos de señal —métricas, registros y trazas— y una pregunta que deben responder: qué ocurre ahora y por qué.060Registros: guardar bien y encontrar rápidoUn buen registro está estructurado, identificado con un ID de petición, guardado durante un tiempo definido, y libre de información personal que no tiene motivo de estar ahí.090Operar un sistema de IA a lo largo del tiempoLos modelos se reemplazan, los documentos cambian y los usuarios aprenden a preguntar de otra manera; un sistema al que no se ha tocado en seis meses es casi siempre peor.

Documentación

Lo que no se puede inferir del código

6 artículos

También aparece en: Fundamentos de producto · Backend, APIs y datos · IA en la práctica · Oficio, calidad y equipos

003Escribir una especificación que el equipo lea de verdadUna buena especificación describe comportamiento y criterios de aceptación, no maquetas: y se mide en páginas, no en decenas.032Diseñar una interfaz con la que puedas convivirUna buena interfaz es predecible, consistente y aburrida; cada sorpresa en ella se vuelve una pregunta recurrente y un fallo para quien la usa.078Indicaciones: escribe una especificación, no un conjuroUna buena indicación define un rol, la entrada, las reglas de decisión y la estructura de salida, y se trata como código, en control de versiones y con pruebas.092Revisión de código que mejora en vez de retrasarUna buena revisión es pequeña, rápida y centrada en la corrección y la mantenibilidad, no en las preferencias de estilo que una herramienta automática debería aplicar.094Documentación que la gente lee de verdadDocumenta lo que no se puede inferir del código: decisiones, límites y la forma de empezar; todo lo demás envejece y engaña.095Incorporar a un nuevo desarrollador en una semana, no en un mesLa métrica es cuánto tiempo pasa hasta el primer cambio en producción, y la mayor parte del retraso son los accesos y la configuración local, no entender el código.

Proceso y equipos

Cómo trabajar juntos sin bloquearse mutuamente

22 artículos

También aparece en: Fundamentos de producto · Apps móviles · Backend, APIs y datos · Infraestructura, nube y DevOps · Seguridad · IA en la práctica · Oficio, calidad y equipos