Software Development

Qué le hace realmente un decorador a tu función Quieres medir el tiempo de cada función que llama a una API externa lenta. Puedes pegar llamadas a time.perf_counter() en cada una, o escribir la medición una sola vez y aplicarla en todas partes. Un decorador es la segunda opción: es una función que toma otra función, la envuelve en un comportamiento adicional y devuelve la versión envuelta con el mismo nombre original. ...

Ejecuta 0.1 + 0.2 en una shell de Python y no obtienes 0.3. Obtienes 0.30000000000000004. Pruébalo en JavaScript, Java, Go, C o Rust y te sale la misma cola de dieciséis cifras. Cada uno de esos lenguajes hace exactamente lo que marca el estándar del hardware. Un número que necesita infinitos dígitos binarios se comprime en 64 bits, y algo tiene que ceder. Por qué 0.1 no se puede guardar de forma exacta en binario Los ordenadores guardan los números en coma flotante en base 2. En base 2, la fracción 1/10 tiene un desarrollo periódico, igual que 1/3 se repite sin fin en base 10 (0.3333...). Escrito entero, 0.1 en binario empieza así: ...

Una búsqueda en un diccionario de Python tarda unos 100 nanosegundos, tanto si el diccionario tiene 1.000 claves como 1.000.000. Un bucle anidado que busca duplicados en una lista tarda medio milisegundo con 200 elementos y 136 milisegundos con 3.200. Dieciséis veces la entrada, casi 280 veces la espera. Misma máquina, mismo Python. La notación Big O es el nombre de esa diferencia. Qué mide la notación Big O Big O describe cómo crece el tiempo de ejecución (o el uso de memoria) de un fragmento de código a medida que la entrada se hace más grande. No es una lectura de cronómetro y no le importa si tu portátil es rápido o lento. Le importa la forma de la curva de crecimiento: al duplicar la entrada, ¿el tiempo se duplica, se cuadruplica o apenas se mueve? ...

Ejecuta git reset --hard sobre un commit que tu equipo ya bajó y acabas de dejar tu historial en desacuerdo con el suyo. Ejecuta git revert sobre un typo que no has subido y añades un commit innecesario al log. Git tiene cuatro comandos para deshacer cambios, restore, reset, commit --amend y revert, y no son intercambiables. Elige el equivocado y el resultado es que no pasa nada, o pasa mucho más de lo que querías. ...

Aquí tienes una clase que no puedes probar con un unit test sin una base de datos real y un servidor SMTP funcionando: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService construye su propio SqlOrderRepository y SmtpEmailSender con new, con la connection string incluida. Cada test que toca PlaceOrder necesita una base de datos Orders real y un servidor de correo real, o falla antes de que se ejecute tu assertion. La lógica que quieres probar son dos líneas: guardar el pedido, enviar la confirmación. Está soldada a dos clases concretas que no puedes cambiar. ...

Una función puede tener el 100% de cobertura de pruebas unitarias y la página que la llama puede seguir devolviendo un 500 en producción. No es una contradicción. Las pruebas unitarias, de integración y end-to-end comprueban cosas distintas, y una suite cargada en una y floja en otra tiene un hueco específico y predecible. Qué comprueban las pruebas unitarias, de integración y end-to-end Toma una funcionalidad de registro: una función valida la entrada, escribe una fila en una base de datos y envía un correo de bienvenida. Tres pruebas pueden cubrirla, y cada una responde una pregunta distinta. ...

Ejecuta esto en Node o en la consola del navegador: 1 2 3 4 console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); El resultado es 1 4 3 2. Un setTimeout con un delay de 0ms igual se ejecuta después del callback de la promise, y ambos esperan a que termine cada línea de código síncrono que tienen debajo. async/await está construido sobre este orden, no es un mecanismo nuevo. La mayoría del comportamiento sorprendente en JavaScript async viene de escribir await como si pausara todo el programa, cuando en realidad solo pausa la función en la que está. ...

Tu frontend corre en http://localhost:5173, tu API en http://localhost:4000, y la llamada fetch que funcionaba sin problemas en Postman falla en el navegador con una pared de texto rojo: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Es muy probable que tu servidor haya procesado esa petición y devuelto un 200. El navegador se negó a entregar la respuesta a tu JavaScript. ...

Depurar un bug que solo ocurre en una máquina sin Visual Studio Un bug se reproduce en el servidor de pruebas y no en tu portátil. El servidor de pruebas no tiene Visual Studio, e instalar un IDE completo ahí solo para poner un breakpoint no es una opción. La depuración remota está pensada exactamente para esto. Un programa standalone pequeño corre en la máquina destino, tu Visual Studio local se conecta a él por red, y obtienes breakpoints e inspección de variables sobre un proceso que no está corriendo cerca de tu escritorio. ...