Tutoriales Técnicos

sqlite3.OperationalError: database is locked: solución

2026-10-20T09:00:00.000-05:00

Varios procesos escriben en el mismo archivo de SQLite (por ejemplo, un ciclo de ingesta continuo y trabajos de reprocesado o de escaneo) y alguno falla con:

Traceback (most recent call last):
  File "ingesta.py", line 42, in guardar
    con.execute("INSERT INTO eventos(valor) VALUES (?)", (valor,))
sqlite3.OperationalError: database is locked

Lo peor es el efecto silencioso: un trabajo lanzado a mano y olvidado puede competir con el ciclo programado y dejar la canalización parada durante horas, sin más rastro que este error en un registro. Este artículo explica por qué ocurre, qué configurar en SQLite y cómo encontrar al proceso que estorba.

Por qué pasa

SQLite admite un solo escritor a la vez. La documentación de los códigos de resultado lo describe así: si el proceso A está en mitad de una transacción de escritura y el proceso B intenta iniciar otra, B recibe SQLITE_BUSY y debe esperar a que A termine. El módulo sqlite3 de Python lo muestra como OperationalError: database is locked.

En el modo de diario por defecto (rollback journal), además, lectores y escritores se estorban: varios procesos pueden leer a la vez (bloqueo SHARED), pero para confirmar una escritura hace falta un bloqueo EXCLUSIVE, con el que no puede coexistir ningún otro bloqueo. Un escritor puede tener que esperar a que terminen los lectores, y mientras confirma bloquea las lecturas nuevas.

La espera depende de dos cosas:

SQLite, por defecto, no tiene ningún manejador de ocupado (el valor por defecto es NULL), así que devolvería el error al instante.
Python lo compensa con el parámetro timeout de sqlite3.connect(), cuyo valor por defecto son 5 segundos. Pasado ese tiempo, lanza el error.

Cualquier transacción que retenga el bloqueo más de esos 5 segundos (un proceso que lee, procesa durante minutos y escribe, o uno que quedó colgado con una transacción abierta) provoca el error en los demás.

Solución

Activa el modo WAL una sola vez. La documentación de SQLite explica que, con WAL, los lectores no bloquean a los escritores ni al revés, y que el modo es persistente: una vez fijado, la base sigue en WAL aunque se cierre y se reabra.
```
import sqlite3

con = sqlite3.connect("datos.db")
print(con.execute("PRAGMA journal_mode=WAL").fetchone())  # ('wal',)
con.close()
```
WAL no elimina la regla de un solo escritor: según la documentación, solo puede haber un escritor a la vez. Por eso el paso siguiente sigue siendo necesario. Conviene ejecutar este paso con los demás procesos detenidos o, al menos, sin transacciones activas.
Define cuánto debe esperar cada conexión. La espera es por conexión y no se hereda: debes fijarla en cada proceso. Con Python, el parámetro timeout (en segundos) lo hace; también puedes usar el pragma, en milisegundos:
```
def abrir(ruta: str) -> sqlite3.Connection:
    con = sqlite3.connect(ruta, timeout=30, isolation_level=None)  # transacciones explícitas
    con.execute("PRAGMA busy_timeout=30000")  # equivale a timeout=30
    return con
```
Una conexión solo puede tener un manejador de ocupado: busy_timeout reemplaza cualquier otro definido antes.
Haz transacciones de escritura cortas y con BEGIN IMMEDIATE. Prepara los datos antes (lecturas, análisis, llamadas externas) y abre la transacción solo para escribir:
```
con = abrir("datos.db")
lote = [(v,) for v in valores]   # preparado antes de bloquear nada

con.execute("BEGIN IMMEDIATE")
try:
    con.executemany("INSERT INTO eventos(valor) VALUES (?)", lote)
    con.execute("COMMIT")
except Exception:
    con.execute("ROLLBACK")
    raise
```
La documentación de SQLite recomienda BEGIN IMMEDIATE para no encontrar SQLITE_BUSY a mitad de una transacción: puede fallar al iniciar, pero si tiene éxito, ninguna operación posterior hasta el COMMIT devolverá ese error. Hay un motivo más: si una transacción lee primero y luego escribe, y otra conexión escribió entremedias, SQLite devuelve el error de inmediato aunque el timeout sea de 30 segundos, porque esperar causaría un bloqueo mutuo. En WAL ese caso es SQLITE_BUSY_SNAPSHOT.
Reduce el número de escritores. Si varios procesos solo producen datos, que envíen sus filas por una cola a un único proceso escritor. Las lecturas pueden seguir en paralelo.
Encuentra procesos olvidados y evita duplicados. En Linux, ps -ef --forest muestra el árbol de procesos con su PID y su PPID (el proceso padre); un trabajo huérfano suele colgar de PID 1. Para saber quién tiene abierta la base:
```
ps -ef --forest | grep -E 'ingesta|reprocesar|escaneo' | grep -v grep
fuser datos.db
lsof datos.db
```
Detén el que sobra con kill <PID>. Para que no vuelva a pasar, ejecuta los trabajos largos como servicios (por ejemplo, con systemd) y protege los lanzamientos manuales con flock -n /tmp/escaneo.lock python escaneo.py, que no arranca si ya hay otra instancia con el mismo archivo de bloqueo.

Ten en cuenta las restricciones de WAL que indica la documentación: todos los procesos deben estar en el mismo equipo, WAL no funciona sobre un sistema de archivos de red, y el archivo -wal forma parte del estado persistente de la base. Si copias o mueves datos.db, hazlo junto con su -wal; sin él podrías perder transacciones ya confirmadas. Además, si siempre hay al menos un lector activo, los puntos de control no pueden completarse y el archivo -wal crece sin límite.

Cómo verificar que quedó resuelto

con = abrir("datos.db")
print(con.execute("PRAGMA journal_mode").fetchone()[0])  # wal
print(con.execute("PRAGMA busy_timeout").fetchone()[0])  # 30000

Después simula la concurrencia con varios procesos que escriben a la vez:

import multiprocessing as mp

def escribir(n):
    con = abrir("datos.db")
    for i in range(200):
        con.execute("BEGIN IMMEDIATE")
        con.execute("INSERT INTO eventos(valor) VALUES (?)", (f"{n}-{i}",))
        con.execute("COMMIT")
    con.close()

if __name__ == "__main__":
    with mp.Pool(4) as pool:
        pool.map(escribir, range(4))

Debe terminar sin OperationalError y añadir 800 filas. En producción, comprueba que el registro de tus procesos no vuelve a mostrar database is locked tras una noche de trabajo y que tu contador de elementos procesados sigue creciendo:

sqlite3 datos.db "SELECT count(*) FROM procesados;"
sleep 60
sqlite3 datos.db "SELECT count(*) FROM procesados;"

Si el segundo número es mayor que el primero, el proceso avanza. Por último, ps -ef --forest no debe mostrar más de una instancia de cada trabajo.

Variantes y errores relacionados

`database table is locked`

Es otro código: SQLITE_LOCKED indica un conflicto dentro de la misma conexión (o con una conexión que comparte caché), no entre procesos. Se reproduce, por ejemplo, ejecutando DROP TABLE mientras un cursor de la misma conexión aún lee esa tabla. Cerrar o terminar de leer el cursor lo resuelve; busy_timeout no ayuda.

`ProgrammingError: SQLite objects created in a thread can only be used in that same thread`

Aparece si compartes una conexión entre hilos. Abre una conexión por hilo o por proceso, que además encaja con la configuración por conexión de busy_timeout.

La base está en un volumen de red

WAL no funciona sobre un sistema de archivos de red. Si varios servidores deben escribir en la misma base, SQLite deja de ser la herramienta adecuada y conviene considerar un motor cliente-servidor.

Transacciones implícitas del módulo `sqlite3`

Con el control de transacciones heredado (el valor por defecto), el módulo abre una transacción implícita antes de INSERT, UPDATE, DELETE o REPLACE, de tipo DEFERRED salvo que indiques otra, y with con: confirma al salir. Si prefieres ese estilo, pasa isolation_level="IMMEDIATE" a connect() para que esa transacción implícita sea IMMEDIATE. Los ejemplos de este artículo usan isolation_level=None y BEGIN/COMMIT explícitos para que el momento del bloqueo sea evidente. Desde Python 3.12 existe además el atributo autocommit.

Resumen

SQLite permite un solo escritor a la vez; el segundo recibe SQLITE_BUSY, que Python muestra como database is locked tras agotar su timeout por defecto de 5 segundos.
Activa PRAGMA journal_mode=WAL una vez (es persistente) y fija la espera en cada conexión con timeout=30 o PRAGMA busy_timeout=30000.
Usa transacciones cortas con BEGIN IMMEDIATE y prepara los datos antes de abrirlas.
Busca procesos olvidados con ps -ef --forest, fuser o lsof y evita duplicados con servicios o flock.
WAL exige que todos los procesos estén en el mismo equipo y no funciona sobre sistemas de archivos de red.

Referencias

NestJS: property should not exist (forbidNonWhitelisted)

2026-10-19T15:00:00.000-05:00

Tu API de NestJS rechaza una petición PATCH o PUT con un 400 que nombra una propiedad concreta:

{
  "message": ["property categoriaId should not exist"],
  "error": "Bad Request",
  "statusCode": 400
}

Pasa en aplicaciones que registran el ValidationPipe de forma global con estas opciones:

app.useGlobalPipes(
  new ValidationPipe({ whitelist: true, forbidNonWhitelisted: true, transform: true }),
);

Aparece, por ejemplo, después de que el backend cambie un campo escalar por un arreglo, cuando el formulario del frontend reenvía campos deshabilitados o bloqueados, o cuando el servidor sigue ejecutando código antiguo. Este artículo explica cada caso y cómo distinguirlos por el nombre de la propiedad del mensaje.

Por qué pasa

La documentación de NestJS describe las dos opciones: con whitelist: true, el validador elimina del objeto las propiedades que no usan ningún decorador de validación; con forbidNonWhitelisted: true, en lugar de eliminarlas lanza una excepción. El resultado es que cualquier propiedad del cuerpo que el DTO no declare, o que declare sin ningún decorador de class-validator, produce un 400 con el mensaje property <nombre> should not exist.

El nombre de la propiedad indica la causa probable:

Un nombre antiguo (categoriaId): el backend lo renombró a categoriaIds y el frontend sigue enviando el anterior.
Un campo de solo lectura (id, createdAt, un campo bloqueado): el formulario envía el objeto completo y el DTO no los acepta.
Un campo que sí existe en tu DTO actual: el servidor que responde no ejecuta tu código nuevo. Lo más habitual es un proceso antiguo que quedó en marcha con un dist/ compilado antes del cambio.
Una propiedad declarada sin decorador: está en la clase, pero para el validador no existe.

Solución

Lee el nombre de la propiedad y decide de qué lado está el fallo. Si es un nombre antiguo o un campo de solo lectura, el error está en el payload del cliente. Si es un campo que acabas de añadir al DTO, revisa el decorador (paso 3) y que el servidor ejecute el código nuevo (paso 4).

Alinea el payload con el DTO. Envía solo los campos declarados, traduce los renombrados y omite los bloqueados. Para un PATCH, además, omite la clave cuando el valor no cambió:

function mismosIds(a: number[], b: number[]): boolean {
  const x = [...a].sort();
  const y = [...b].sort();
  return x.length === y.length && x.every((v, i) => v === y[i]);
}

// FormValues es el tipo de los valores de tu formulario
function construirPayload(form: FormValues, original: FormValues) {
  const payload: { nombre?: string; categoriaIds?: number[] } = {};
  if (form.nombre !== original.nombre) payload.nombre = form.nombre;
  if (!mismosIds(form.categoriaIds, original.categoriaIds)) {
    payload.categoriaIds = form.categoriaIds;
  }
  return payload; // las claves sin cambios no viajan
}

await api.patch(`/items/${id}`, construirPayload(form, original));

Hay un detalle con los arreglos: en algunos servicios, el arreglo recibido se interpreta como el conjunto completo de relaciones. Un [] enviado por descuido puede significar "quitar todo". Si no hubo cambios, no envíes la clave, y asegúrate de que el formulario conserva los valores cargados antes de enviarlos.

Declara cada propiedad con al menos un decorador. Para el DTO de actualización, deriva del de creación con PartialType (paquete @nestjs/mapped-types), que según la documentación deriva la variante sin repetir las propiedades ni sus decoradores de validación:
```
import { PartialType } from '@nestjs/mapped-types';
import { IsArray, IsInt, IsNotEmpty, IsString } from 'class-validator';

export class CreateItemDto {
  @IsString()
  @IsNotEmpty()
  nombre: string;

  @IsArray()
  @IsInt({ each: true })
  categoriaIds: number[];
}

export class UpdateItemDto extends PartialType(CreateItemDto) {}
```
Si una propiedad no necesita ninguna validación concreta, class-validator ofrece @Allow() para que no se elimine ni se rechace.
Si el cambio no se aplica, reinicia el proceso correcto. En un proyecto generado con Nest CLI, start:prod ejecuta node dist/main, es decir, el código ya compilado. No recoge cambios de src/ hasta que ejecutes nest build. Detén el proceso antiguo, compila y vuelve a iniciar. En Windows:
```
netstat -ano | findstr :3000
taskkill /PID 12345 /T /F
npm run build
npm run start:prod
```
En Linux o macOS:
```
lsof -i :3000
kill 12345
npm run build
npm run start:prod
```
Sustituye 3000 por tu puerto y 12345 por el PID de la última columna de netstat (la opción -o lo añade) o de lsof. En taskkill, /T termina también los procesos hijos y /F fuerza el cierre. Si al iniciar la versión nueva ves un error como Error: listen EADDRINUSE: address already in use :::3000, otro proceso sigue ocupando el puerto: Node lo describe como un intento de enlazar un servidor a una dirección que otro servidor ya ocupa.

Cómo verificar que quedó resuelto

Prueba la petición con los campos correctos (en PowerShell usa curl.exe):

curl -i -X PATCH http://localhost:3000/items/1 \
  -H "Content-Type: application/json" \
  -d '{"nombre":"prueba","categoriaIds":[1,2]}'

Debe responder 200. Después consulta el recurso con un GET y comprueba que el selector queda con los valores marcados y que las relaciones previas se conservaron. Como control, envía un campo inventado:

curl -i -X PATCH http://localhost:3000/items/1 \
  -H "Content-Type: application/json" \
  -d '{"campoInventado":1}'

Debe responder 400 con property campoInventado should not exist: confirma que el pipe sigue activo y que el servidor carga el DTO nuevo. También puedes cubrirlo con una prueba unitaria del pipe, sin levantar la aplicación:

const pipe = new ValidationPipe({ whitelist: true, forbidNonWhitelisted: true, transform: true });
const meta = { type: 'body' as const, metatype: UpdateItemDto };

it('acepta los campos declarados', async () => {
  await expect(pipe.transform({ nombre: 'x', categoriaIds: [1] }, meta)).resolves.toBeDefined();
});

it('rechaza un campo no declarado', async () => {
  const error = await pipe.transform({ campoViejo: 1 }, meta).catch((e) => e);
  expect(error.getResponse()).toMatchObject({ message: ['property campoViejo should not exist'] });
});

Variantes y errores relacionados

Solo `whitelist: true`

Sin forbidNonWhitelisted, las propiedades desconocidas se eliminan en silencio. El PATCH responde 200, pero el campo con el nombre antiguo no se guarda y nadie se entera. Si prefieres detectar estos desajustes pronto, mantén forbidNonWhitelisted activado.

No aparece el detalle del error

La opción disableErrorMessages: true del ValidationPipe hace que la respuesta no incluya los mensajes detallados. Si ves un 400 sin el nombre de la propiedad, revisa esa opción.

Las pruebas e2e pasan pero producción falla

La configuración de app.useGlobalPipes(...) suele estar en main.ts. Una prueba e2e que crea la aplicación desde el módulo de pruebas no la ejecuta, así que no reproducirá el 400 salvo que registres el mismo pipe en la prueba.

El DTO de actualización no deriva del de creación

Si UpdateItemDto es una clase independiente, cada campo nuevo que añadas a CreateItemDto será rechazado en el PATCH hasta que lo declares también ahí. Derivarlo con PartialType evita esa divergencia.

Resumen

Con whitelist y forbidNonWhitelisted, toda propiedad sin decorador de validación en el DTO produce property X should not exist.
El nombre de la propiedad orienta el diagnóstico: nombre antiguo o campo de solo lectura (frontend), o campo nuevo (decorador o proceso antiguo).
Envía solo los campos declarados y omite la clave de un arreglo cuando no cambió: un [] puede significar "borrar todo".
Si los cambios del backend no se aplican, detén el proceso antiguo, ejecuta nest build y vuelve a iniciar.
Verifica con un PATCH válido (200) y uno con un campo inventado (400).

Referencias

useEffect borra el estado: dependencia con referencia nueva

2026-10-19T09:00:00.000-05:00

Un componente de React pierde lo que el usuario acaba de escribir sin que nadie haya tocado ese estado. Se ha visto de tres formas:

Un diálogo para enviar un informe por correo pierde los destinatarios escritos y el mensaje de error después de un envío fallido.
Un formulario pierde los importes editados cuando termina una recarga de datos en segundo plano.
Una prueba nueva con Vitest y Testing Library se cuelga o falla.

En el tercer caso, la consola muestra este aviso:

Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.

La causa común es un useEffect que inicializa o reinicia estado local y depende de un valor cuya referencia cambia en cada render. Este artículo explica por qué se dispara y cómo corregirlo.

Por qué pasa

La documentación de React indica que compara cada dependencia con su valor anterior mediante Object.is. Un array u objeto creado durante el render es un valor distinto en cada render, aunque su contenido sea idéntico, así que el efecto se vuelve a ejecutar. Si ese efecto llama a setState con valores iniciales, pisa lo que escribió el usuario.

Los tres casos son variantes de esto:

Diálogo: el padre calcula const iniciales = guardados.length ? guardados : ['']. Cuando no hay destinatarios guardados, [''] es un array nuevo en cada render del padre. Al fallar el envío, el padre cambia su estado y se renderiza, el efecto detecta una dependencia "nueva" y restablece destinatarios y error.
Formulario con datos remotos: TanStack Query comparte estructuralmente los resultados, y su documentación indica que la referencia de data no cambia si los datos no cambiaron. Pero si la recarga trae algo distinto (aunque sea un campo que no editas), la referencia cambia y el efecto reinicializa el formulario. Las consultas están obsoletas por defecto y refetchOnWindowFocus vale true, así que esa recarga ocurre sola al volver a la ventana.
Bucle de renders: con const { data = [] } = useQuery(...), el valor por defecto crea un array nuevo en cada render mientras data es undefined. Si un efecto depende de él y hace setFilas(data.map(...)), cada render provoca otro. React solo registra el aviso de arriba en la consola y el bucle continúa: una prueba que espera ese render no termina.

Además, según la guía "You Might Not Need an Effect", los efectos son para sincronizar con sistemas externos; reiniciar estado por un cambio de props normalmente no necesita un efecto.

Solución

Identifica la dependencia que cambia. La documentación de useEffect sugiere registrar las dependencias y compararlas con Object.is entre renders:
```
const anterior = useRef(destinatariosIniciales);
console.log('misma referencia:', Object.is(anterior.current, destinatariosIniciales));
anterior.current = destinatariosIniciales;
```
Es solo para depurar: bórralo después. Si imprime false sin que el contenido haya cambiado, esa es la dependencia.

Inicializa solo en la transición de cerrado a abierto. Guarda el valor anterior de open en un useRef:

function InformeDialog({ open, destinatariosIniciales, onEnviar }) {
  const [destinatarios, setDestinatarios] = useState([]);
  const [error, setError] = useState(null);
  const estabaAbierto = useRef(false);

  useEffect(() => {
    if (open && !estabaAbierto.current) {
      setDestinatarios(destinatariosIniciales);
      setError(null);
    }
    estabaAbierto.current = open;
  }, [open, destinatariosIniciales]);

  // ...
}

La lista de dependencias sigue completa (el linter no se queja), pero la condición impide reinicializar cuando solo cambia la referencia del array.

Reinicializa solo cuando cambia la clave de negocio. Para formularios con datos remotos, guarda para qué registro se inicializó el estado:
```
function FormularioFactura({ id }) {
  const { data } = useQuery({ queryKey: ['factura', id], queryFn: () => obtenerFactura(id) });
  const [monto, setMonto] = useState('');
  const inicializadoPara = useRef(null);

  useEffect(() => {
    if (data && inicializadoPara.current !== data.id) {
      inicializadoPara.current = data.id;
      setMonto(String(data.monto));
    }
  }, [data]);

  // ...
}
```
La alternativa que recomienda React es no usar un efecto: separa los campos en un componente hijo con useState(() => String(factura.monto)) y renderízalo con key={data.id}. React reinicia el estado solo cuando cambia la clave. Una dependencia primitiva como dataUpdatedAt evita el problema de la referencia, pero cambia en cada consulta exitosa, así que sirve para vistas de solo lectura y no para pantallas donde se edita.
Usa referencias estables. Saca los valores por defecto del componente o memoízalos:
```
const SIN_FILAS = [];

function ListaFilas({ obtenerFilas }) {
  const { data = SIN_FILAS } = useQuery({ queryKey: ['filas'], queryFn: obtenerFilas });
  // ...
}

const destinatariosIniciales = useMemo(
  () => (guardados.length ? guardados : ['']),
  [guardados],
);
```
React presenta useMemo como último recurso para estabilizar una dependencia; primero conviene mover el valor fuera del componente o leer solo valores primitivos. Si pasas una función select a useQuery, la documentación de TanStack recomienda memoizarla.
Reduce las recargas donde el usuario edita. La documentación de TanStack indica que staleTime es la forma recomendada de evitar recargas excesivas:
```
useQuery({
  queryKey: ['factura', id],
  queryFn: () => obtenerFactura(id),
  refetchOnWindowFocus: false,
  staleTime: 60_000,
});
```

Escribe pruebas que fallen con el código anterior. La primera reproduce la secuencia del diálogo; la segunda usa Profiler, cuyo onRender se llama en cada commit, para cortar un bucle:

it('conserva destinatarios y error tras un envío fallido', async () => {
  const user = userEvent.setup();
  const enviar = vi.fn().mockRejectedValue(new Error('fallo'));
  render(<PaginaInforme enviar={enviar} />);

  await user.click(screen.getByText('Abrir'));
  const campo = screen.getByLabelText('Destinatarios');
  await user.clear(campo);
  await user.type(campo, 'ana, luis');
  await user.click(screen.getByText('Enviar'));

  expect(await screen.findByRole('alert')).toBeTruthy();
  expect(screen.getByLabelText('Destinatarios').value).toBe('ana, luis');
});

it('no entra en un bucle de renders', () => {
  let commits = 0;
  const onRender = () => {
    commits += 1;
    if (commits > 10) throw new Error('Demasiados renders: posible bucle de efectos');
  };
  render(
    <QueryClientProvider client={new QueryClient()}>
      <Profiler id="lista" onRender={onRender}>
        <ListaFilas obtenerFilas={() => new Promise(() => {})} />
      </Profiler>
    </QueryClientProvider>,
  );
  expect(commits).toBeLessThan(10);
});

Las pruebas asumen un componente PaginaInforme (el padre que renderiza el diálogo y le pasa enviar) y los imports habituales de Vitest, Testing Library y TanStack Query. El throw es lo que evita el cuelgue: sin él, render nunca devuelve el control cuando hay un bucle. Según su documentación, Profiler está desactivado por defecto en las compilaciones de producción, así que este guardia es solo para pruebas.

Cómo verificar que quedó resuelto

Ejecuta las pruebas con el código anterior: deben fallar (el campo queda vacío, el aviso desaparece o se lanza el error de "Demasiados renders"). Con la corrección deben pasar.
Reproduce en el navegador la secuencia exacta: abre el diálogo, escribe destinatarios, fuerza un fallo del envío (por ejemplo, con la red desconectada en las herramientas de desarrollo) y comprueba que los destinatarios y el mensaje siguen ahí.
En el formulario, edita un importe, cambia de pestaña y vuelve a la ventana: el valor editado debe conservarse.
Ejecuta la suite completa: ningún archivo de pruebas debería tardar de forma anómala. Un archivo que antes se colgaba debe terminar en pocos segundos.

Variantes y errores relacionados

Efecto sin lista de dependencias

Un useEffect sin segundo argumento se ejecuta tras cada render. La documentación pide revisar primero que no falte la lista de dependencias.

Funciones como dependencia

Una función definida dentro del componente también es nueva en cada render y provoca lo mismo. La guía Removing Effect Dependencies propone moverla fuera del componente o dentro del efecto; useCallback queda como último recurso.

Ajustar estado durante el render

React también documenta guardar la información del render anterior en el estado y ajustarlo durante el render. Es más eficiente que un efecto, pero la propia guía advierte que la mayoría de los componentes no lo necesitan: prefiere key o calcular el valor al renderizar.

StrictMode

El patrón del paso 2 funciona igual dentro de <StrictMode>, que en desarrollo ejecuta un ciclo adicional de configuración y limpieza de cada efecto al montar: la condición sobre estabaAbierto evita inicializar dos veces.

Resumen

React compara las dependencias con Object.is: un array u objeto creado en el render es "nuevo" cada vez y vuelve a disparar el efecto.
Un efecto que inicializa estado con ese tipo de dependencia borra lo que el usuario escribió; si además cambia el estado con un valor nuevo, genera un bucle.
Inicializa solo en la transición cerrado a abierto o cuando cambia la clave de negocio, o usa key para reiniciar el componente.
Estabiliza los valores por defecto (constantes fuera del componente o useMemo) y limita las recargas en pantallas de edición.
Cubre el caso con pruebas que fallen antes y pasen después, incluyendo un guardia de menos de 10 renders.

Referencias

FileNotFoundError por ruta larga en Windows (MAX_PATH)

2026-10-18T15:00:00.000-05:00

Un script de Python escribe un archivo en una carpeta que existe y falla igualmente:

FileNotFoundError: [Errno 2] No such file or directory: 'C:\\proyectos\\mi-app\\tmp\\sesion\\resultados\\...\\informe_final.xlsx'

En Node.js, una herramienta que lanza procesos desde una carpeta muy anidada puede abortar con un mensaje como este (el texto exacto depende de la herramienta):

Error: Current working directory has a path longer than allowed for a Win32 working directory

El patrón siempre es el mismo: todo funciona en carpetas cortas y falla solo en carpetas temporales o de sesión muy anidadas. No falta nada: la ruta completa supera el límite clásico de Windows de 260 caracteres. Este artículo explica cómo confirmarlo, qué soluciones hay y qué cubre cada una.

Por qué pasa

En la API de Windows, la longitud máxima de una ruta es MAX_PATH, definida en 260 caracteres. Esa cifra incluye la letra de unidad, los dos puntos, la barra inicial, los nombres separados por barras y el carácter nulo final, así que en la práctica quedan unos 259 caracteres. Una carpeta base larga más nombres de archivo largos (títulos de informes, identificadores, fechas) suman más de 260 con facilidad.

Cuando se supera el límite, Windows responde "ruta no encontrada" y Python lo traduce a FileNotFoundError, aunque la carpeta exista. Con rutas largas desactivadas, os.path.isdir() devuelve False sobre una carpeta que sí existe, y os.makedirs() falla con [WinError 3] ("El sistema no puede encontrar la ruta especificada" en Windows en español). Cualquier biblioteca que escriba en esa ruta con open() fallará igual: guardar un libro de Excel con openpyxl, una imagen con Pillow o una figura con savefig de matplotlib.

El directorio de trabajo tiene además su propio límite. La documentación de SetCurrentDirectory indica que, por defecto, el nombre está limitado a MAX_PATH caracteres y que fijar un directorio actual más largo hace fallar CreateProcessW, la función con la que Windows crea procesos. Por eso lanzar un subproceso con un cwd largo falla incluso en programas que sí pueden escribir archivos con rutas largas.

Desde Windows 10 versión 1607 el límite puede levantarse, pero es opcional por aplicación: según Microsoft, hacen falta dos condiciones. El valor de registro LongPathsEnabled debe estar en 1 y la aplicación debe declarar longPathAware en su manifiesto. Activar el valor de registro no afecta a las aplicaciones que no lo declaran, y el sistema lo lee una vez por proceso, por lo que puede ser necesario reiniciar.

Solución

Localiza las rutas largas. Este script lista los archivos de una carpeta cuya ruta tiene 250 caracteres o más. Usa el prefijo \\?\ para poder recorrer lo que una ruta normal no deja abrir:

import os
import sys

def rutas_largas(raiz, umbral=250):
    for carpeta, _, archivos in os.walk("\\\\?\\" + os.path.abspath(raiz)):
        for nombre in archivos:
            ruta = os.path.join(carpeta, nombre)[4:]  # quita el prefijo \\?\
            if len(ruta) >= umbral:
                yield len(ruta), ruta

for largo, ruta in rutas_largas(sys.argv[1]):
    print(largo, ruta)

Trabaja desde una ruta base corta. Es la solución más fiable porque no depende de ninguna herramienta. Crea una carpeta como C:\tmp\trabajo, genera ahí los archivos intermedios y copia al destino definitivo solo el resultado final. Muchas herramientas toman la carpeta temporal de las variables TMP y TEMP (la función GetTempPath de Windows las consulta en ese orden), así que en PowerShell puedes redirigirlas para esa sesión:
```
New-Item -ItemType Directory -Force C:\tmp\trabajo | Out-Null
$env:TMP = "C:\tmp\trabajo"
$env:TEMP = "C:\tmp\trabajo"
```
Qué cubre: todo, incluido el directorio de trabajo, cmd.exe y las herramientas que no admiten rutas largas.

Acorta los nombres que genera tu código. Usa identificadores cortos y guarda la correspondencia con el nombre largo en un archivo de manifiesto:

import csv
from pathlib import Path

def guardar_lote(carpeta: Path, items: list[tuple[str, bytes]]) -> None:
    carpeta.mkdir(parents=True, exist_ok=True)
    with (carpeta / "manifiesto.csv").open("w", newline="", encoding="utf-8") as m:
        w = csv.writer(m)
        w.writerow(["id", "nombre_original"])
        for n, (nombre, datos) in enumerate(items, start=1):
            id_corto = f"{n:04d}"
            (carpeta / f"{id_corto}.bin").write_bytes(datos)
            w.writerow([id_corto, nombre])

Qué cubre: ataca la causa (la longitud total) y funciona en cualquier equipo, sin tocar la configuración de Windows.

Activa las rutas largas en Windows. En una consola de PowerShell con permisos de administrador:
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
  -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
También puede activarse con la directiva de grupo "Enable Win32 long paths" (Configuración del equipo, Plantillas administrativas, Sistema, Sistema de archivos). Reinicia el equipo: Microsoft indica que puede ser necesario porque algunos procesos pudieron arrancar antes del cambio. La documentación de Python para Windows indica que, con este valor activado y tras reiniciar, open(), el módulo os y la mayoría de las funciones de rutas aceptan rutas de más de 260 caracteres sin más configuración.

Git tiene su propio ajuste. Con --system escribe en la configuración del sistema, por lo que normalmente requiere permisos de administrador:
```
git config --system core.longpaths true
```
Qué cubre: las aplicaciones que declaran longPathAware (Python, según su documentación) y los comandos de Git escritos en C. No cubre las herramientas que no lo declaran. Git for Windows advierte además que los comandos de Git implementados como scripts pueden seguir fallando.
Usa el prefijo \\?\ en el código que controlas. Para las funciones de la API que lo admiten, una ruta absoluta con este prefijo se pasa al sistema con modificaciones mínimas:
```
import os

ruta = r"C:\tmp\trabajo\una\carpeta\muy\larga\informe.txt"
with open("\\\\?\\" + os.path.abspath(ruta), "w", encoding="utf-8") as f:
    f.write("ok")
```
Microsoft precisa que con este prefijo no puedes usar barras normales, ni . ni .., y que las rutas relativas siguen limitadas a MAX_PATH. Qué cubre: solo el código propio que llama a funciones compatibles; no sirve como argumento para otros programas ni para el directorio de trabajo.

Cómo verificar que quedó resuelto

Si activaste las rutas largas, comprueba el valor de registro:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name LongPathsEnabled

Debe mostrar LongPathsEnabled : 1. Después prueba una ruta que supere los 260 caracteres sin el prefijo:

from pathlib import Path

ruta = Path(r"C:\tmp\trabajo") / ("a" * 120) / ("b" * 120) / "prueba.txt"
print(len(str(ruta)))
try:
    ruta.parent.mkdir(parents=True, exist_ok=True)
    ruta.write_text("ok", encoding="utf-8")
    print("OK: la ruta larga funciona")
except FileNotFoundError as e:
    print("FALLA:", e)

Con rutas largas desactivadas debe imprimir FALLA; con ellas activas (y tras reiniciar), OK. Si optaste por la ruta corta o los nombres cortos, vuelve a ejecutar el script original desde C:\tmp\trabajo: debe guardar los gráficos y el libro de Excel sin FileNotFoundError, y el libro debe abrirse con normalidad.

Variantes y errores relacionados

Node.js y subprocesos

El síntoma cambia según la API. En una prueba con Node.js 24 en Windows 11 con rutas largas desactivadas, process.chdir() falló con ENAMETOOLONG y child_process.spawnSync con un cwd largo falló con un engañoso spawnSync cmd ENOENT, mientras que fs.writeFileSync con una ruta absoluta larga funcionó. En Python, subprocess.run(..., cwd=ruta_larga) lanzó NotADirectoryError: [WinError 267] ("El nombre del directorio no es válido"). Es un comportamiento observado que puede variar entre versiones; la solución es la misma: ejecuta desde una ruta corta.

Git: Filename too long

Al clonar un repositorio con nombres largos dentro de una carpeta que ya es larga, Git puede informar de que no puede crear un archivo porque el nombre es demasiado largo (Filename too long). Microsoft menciona justo este caso. Clona en una carpeta corta como C:\src o activa core.longpaths.

El límite de los directorios es menor

Al crear un directorio con la API, la ruta no puede ser tan larga que no quepa después un nombre 8.3: el nombre del directorio no puede superar MAX_PATH menos 12 caracteres. Puedes encontrar errores con rutas de 250 caracteres.

Explorador, cmd.exe y otras aplicaciones

Aunque tu script funcione, el Explorador de archivos, cmd.exe y muchas otras aplicaciones (incluidas las utilidades que ejecutas desde Git Bash, si no declaran soporte) pueden seguir sin admitir rutas largas. Microsoft señala que el shell y el sistema de archivos tienen requisitos distintos, y que activar el registro solo afecta a las aplicaciones preparadas.

Resumen

Un FileNotFoundError con la carpeta existente y una ruta de más de 260 caracteres apunta al límite MAX_PATH de Windows.
El directorio de trabajo tiene su propio límite: un cwd largo hace fallar la creación del proceso.
Lo más fiable es trabajar desde una ruta corta (C:\tmp\trabajo) y usar nombres cortos con un manifiesto.
LongPathsEnabled y core.longpaths ayudan solo a las aplicaciones y comandos que lo admiten; el prefijo \\?\ solo al código que lo usa.
Verifica con el valor de registro y una prueba que cree un archivo en una ruta de más de 260 caracteres.

Referencias

git status muestra todos los archivos modificados en WSL

2026-10-18T09:00:00.000-05:00

Haces un merge o un checkout con Git para Windows, vuelves a la terminal de WSL2 y git status lista cientos de archivos como modificados, aunque no editaste ninguno:

$ git status --short
 M src/app.ts
 M src/lib/formato.ts
 M README.md
 ...

Si el repositorio usa git worktree y alguno se creó desde Windows, en WSL aparece además este error:

fatal: not a git repository: //wsl.localhost/Ubuntu/home/usuario/mi-app/.git/worktrees/rama-x

Y al intentar filtrar el ruido con git status --ignore-cr-at-eol, Git responde:

error: unknown option `ignore-cr-at-eol'
usage: git status [<options>] [--] [<pathspec>...]

Los tres síntomas tienen una causa común: dos instalaciones de Git (la de Windows y la de WSL) trabajan sobre el mismo árbol de archivos. Este artículo explica cómo confirmarlo, cómo limpiar el estado sin perder cambios reales y cómo evitar que se repita.

Por qué pasa

Git para Windows y Git dentro de WSL son instalaciones independientes, cada una con sus propios archivos de configuración. Es habitual que la de Windows tenga core.autocrlf=true (el libro Pro Git recomienda ese valor en Windows) y que la de WSL no tenga ninguna conversión configurada. Compruébalo ejecutando el mismo comando en ambos lados:

git config --show-origin --get-all core.autocrlf

En Windows puede devolver algo como file:C:/Program Files/Git/etc/gitconfig true; en WSL, ninguna línea.

Según la documentación de Git, core.autocrlf=true equivale a poner text=auto en todos los archivos y core.eol=crlf: al hacer checkout o merge, Git para Windows escribe los archivos con CRLF y los convierte a LF al guardarlos en el índice, que sigue teniendo LF. Git en WSL, sin conversión, compara los bytes del disco (CRLF) con los del índice (LF) y concluye que el archivo cambió. Solo se ven afectados los archivos que esa operación reescribió: el número (100, 400...) depende del merge o del checkout, no del tamaño del repositorio.

Para verlo, git ls-files --eol muestra el fin de línea del índice (i/) y del directorio de trabajo (w/). Los archivos fantasma aparecen como i/lf w/crlf.

La opción --ignore-cr-at-eol pertenece a git diff (ignora el retorno de carro al final de la línea al comparar), no a git status; por eso este último responde unknown option.

El error de los worktrees tiene un origen parecido. Un worktree enlazado tiene un archivo .git que apunta a un directorio privado dentro del .git del repositorio principal (.git/worktrees/<nombre>), y ese directorio guarda a su vez la ruta del worktree. Si el worktree lo creó Git para Windows, esas rutas se escribieron tal como Windows ve el repositorio (una ruta UNC como //wsl.localhost/Ubuntu/... o una ruta de unidad como C:/...), y Git en Linux no sabe resolverlas.

Solución

Confirma que son cambios fantasma y separa los reales. Desde WSL, en la raíz del repositorio:
```
git diff --ignore-cr-at-eol --stat
git diff --ignore-cr-at-eol --name-only
git ls-files --eol | grep 'w/crlf'
```
Si el primer comando no imprime nada, todas las diferencias son de fin de línea. Si imprime archivos, esos sí tienen cambios reales: el segundo comando los lista y conviene conservarlos. El tercero muestra los archivos con CRLF en disco.
Restaura desde WSL los archivos afectados. Desde una terminal de WSL, o desde PowerShell anteponiendo wsl.exe:
```
wsl.exe -d Ubuntu -e bash -lc "cd ~/mi-app && git restore ."
```
git restore . (equivalente a git checkout -- . en versiones antiguas) descarta todos los cambios sin confirmar. Si el paso anterior mostró cambios reales, exclúyelos con un pathspec:
```
git restore -- . ':(exclude)src/cambio-real.ts'
```
Los archivos se reescriben con LF, que es lo que tiene el índice.
Fija el fin de línea con .gitattributes. En la raíz del repositorio:
```
* text=auto eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
```
Según la documentación de Git, core.autocrlf solo se consulta cuando el atributo text no está definido; con este archivo, las dos instalaciones de Git se comportan igual. La combinación text=auto eol=lf requiere Git 2.10 o posterior. Las dos últimas líneas conservan CRLF en los scripts de Windows, que suelen necesitarlo. Después renormaliza y revisa antes de confirmar:
```
git add .gitattributes
git add --renormalize .
git status
git commit -m "chore: normalize line endings to LF"
```
Si el repositorio tenía archivos guardados con CRLF en el índice (git ls-files --eol | grep 'i/crlf'), aparecerán en git status como cambios preparados: es la conversión única a LF y es lo esperado.
Repara los worktrees creados desde Windows. En WSL, desde el repositorio principal, indica la ruta Linux real del worktree:
```
git worktree list
git worktree repair ~/mi-app-rama-x
```
La documentación de git worktree describe repair justo para este caso: restablece la conexión entre el repositorio principal y los worktrees cuando sus archivos administrativos quedaron desactualizados. Si prefieres hacerlo a mano, el archivo .git del worktree debe contener gitdir: /home/usuario/mi-app/.git/worktrees/rama-x, y el archivo gitdir dentro de .git/worktrees/rama-x/ debe contener la ruta Linux de ese .git. Como última opción, usa git worktree prune y vuelve a crear el worktree desde WSL con git worktree add; el contenido sin confirmar del directorio viejo no se mueve solo, así que cópialo antes.
Haz las operaciones que escriben desde un único Git. Ejecuta checkout, merge, pull, rebase, stash y worktree add dentro de WSL, aunque edites los archivos con herramientas de Windows:
```
wsl.exe -d Ubuntu -e bash -lc "cd ~/mi-app && git pull --ff-only"
```
Tampoco ejecutes sobre todo el repositorio formateadores ni conversiones de fin de línea del editor que escriban CRLF.

Cómo verificar que quedó resuelto

git status --short
git diff --ignore-cr-at-eol --stat
git ls-files --eol | grep -c 'w/crlf'
git config --show-origin --get-all core.autocrlf

Los dos primeros no deben imprimir nada. El tercero debe dar 0, salvo por los .bat y .cmd si los tienes, que conservan CRLF a propósito. Después haz un git checkout o un git pull desde WSL y repite el git status: debe seguir limpio. Por último, abre el repositorio con tus herramientas de Windows (editor, cliente gráfico) y confirma que tampoco muestran cambios.

Variantes y errores relacionados

El repositorio está en `/mnt/c/...`

Funciona igual, pero la documentación de Microsoft sobre sistemas de archivos en WSL recomienda no trabajar con los mismos archivos desde ambos sistemas operativos salvo que haya una razón, y guardarlos en el sistema de archivos donde corren las herramientas. Si trabajas en WSL, un repositorio en ~/mi-app deja a Git para Windows fuera de la ecuación.

No puedes confirmar un `.gitattributes`

Alinea las configuraciones. La documentación de solución de problemas de VS Code propone, en Windows, git config --global core.autocrlf input (convierte a LF al confirmar y no escribe CRLF) o false (sin conversión), y avisa de que puede hacer falta volver a clonar para que el cambio surta efecto.

El diff muestra `old mode` y `new mode`

Ya no son fines de línea sino cambios en el bit ejecutable. La documentación de core.fileMode menciona que un repositorio visitado desde otro entorno puede perder ese bit y que en ese caso conviene ponerlo en false.

Worktrees que se abren desde ambos lados

git worktree admite enlaces con rutas relativas (--relative-paths o worktree.useRelativePaths), pensados para repositorios que se mueven entre entornos. La propia documentación avisa de que los Git antiguos no los entienden. Pruébalo primero en un repositorio de ensayo.

Resumen

Cientos de archivos "modificados" sin cambios reales suelen ser CRLF escrito por Git para Windows (core.autocrlf=true) y leído por un Git en WSL sin conversión.
--ignore-cr-at-eol es una opción de git diff: úsala con --stat o --name-only para separar lo real de lo fantasma.
Restaura desde WSL con git restore ., excluyendo con un pathspec los archivos que sí cambiaste.
Evita la recaída con * text=auto eol=lf en .gitattributes y ejecutando las operaciones que escriben desde un solo Git.
Los worktrees creados desde Windows guardan rutas que Linux no resuelve: arréglalos con git worktree repair <ruta-linux>.

Referencias

Docker build cache llena el disco: docker builder prune

2026-10-17T15:00:00.000-05:00

El disco de un servidor Linux está al 60 % y no sabes por qué. Las bases de datos pesan unos pocos MB, la aplicación apenas ocupa espacio y aun así el sistema de archivos raíz va llenándose con cada despliegue:

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       193G  115G   78G  60% /

Antes de contratar un servidor más grande, revisa lo que Docker guarda en el disco. Cuando los despliegues construyen las imágenes en el propio servidor, la caché de compilación (build cache) puede acumular decenas de GB sin que ningún contenedor ni imagen lo muestre.

Por qué pasa

BuildKit, el motor de compilación de Docker, guarda el resultado intermedio de cada paso de un build para reutilizarlo en el siguiente. Esa caché es independiente de las imágenes, los contenedores y los volúmenes: no aparece en docker images ni en docker ps, y el tamaño de tus bases de datos no influye. Cada build que cambia capas añade registros nuevos.

La documentación de Docker explica que BuildKit tiene un recolector de basura que limpia la caché de forma periódica según unas políticas, a diferencia de docker builder prune, que lo hace a petición. Aun así, en la práctica la caché puede llegar a ocupar decenas de GB, como en este ejemplo, así que conviene medirla en lugar de asumir que se limpia sola. El comando que lo muestra es este:

$ docker system df
TYPE            TOTAL   ACTIVE   SIZE      RECLAIMABLE
Images          ...
Containers      ...
Local Volumes   ...
Build Cache     ...     ...      107.7GB   100.1GB

En este ejemplo, la fila Build Cache ocupa 107,7 GB y 100,1 GB son recuperables. Las demás filas se omiten porque lo relevante es la diferencia de tamaño.

Solución

Diagnostica qué ocupa el espacio.
```
df -h /
docker system df
docker system df -v
docker buildx du
```
docker system df -v detalla el uso de cada imagen, contenedor y volumen. docker buildx du lista los registros de la caché de compilación. Si docker system df no explica el espacio, el consumo está fuera de Docker: revisa con du -xh --max-depth=1 /var | sort -h.
Confirma qué necesitas conservar. docker builder prune solo elimina caché de compilación: no toca contenedores, imágenes ni volúmenes. Si guardas etiquetas de reversión (rollback), son imágenes y se conservan; compruébalas con docker image ls. El costo es que el siguiente build no tendrá caché y tardará más.
Elimina la caché de compilación.
```
docker builder prune -af
```
-a amplía la limpieza a toda la caché sin uso (la referencia de buildx lo describe como incluir las imágenes internas y de frontend) y -f evita la confirmación interactiva. Si prefieres conservar la caché reciente para que los próximos builds sigan siendo rápidos, usa un filtro por antigüedad:
```
docker builder prune -af --filter until=168h
```
El valor es una duración (por ejemplo 24h); este ejemplo conserva lo usado en los últimos 7 días. También hay opciones por espacio, como --reserved-space 10GB. En documentación antigua aparece --keep-storage; el CLI reciente la marca como obsoleta y la reemplaza por --reserved-space. Confirma las opciones de tu versión con docker builder prune --help.
Programa la limpieza para que no vuelva a acumularse. Puedes hacerlo al final del script o del flujo de despliegue:
```
docker compose up -d --build
docker builder prune -f --filter until=168h
```
O con una tarea mensual en cron (en el crontab de un usuario con acceso a Docker), por ejemplo el día 1 a las 03:00:
```
0 3 1 * * docker builder prune -af --filter until=720h
```
Otra opción es ajustar el recolector de basura de BuildKit en /etc/docker/daemon.json, con un límite de tamaño para la caché. La documentación de Docker muestra esta forma:
```
{
  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "20GB"
    }
  }
}
```
Elige un valor acorde con tu disco y consulta en la documentación cómo aplicar el cambio de configuración del demonio.

Cómo verificar que quedó resuelto

df -h /
docker system df
docker ps --format "table {{.Names}}\t{{.Status}}"
curl -s -o /dev/null -w "%{http_code}\n" https://example.com

El uso del disco debe bajar de forma notable y la fila Build Cache de docker system df debe quedar cerca de cero. En el caso de referencia, el disco pasó de 115 GB usados (60 %) a 15 GB (8 %). Los contenedores deben seguir con el mismo tiempo en marcha (Up 3 weeks, no Up 5 seconds), lo que confirma que no se reiniciaron. Por último, las páginas deben responder 200. Cambia https://example.com por la URL de tu aplicación.

Variantes y errores relacionados

La diferencia con `docker system prune`

Según la documentación, docker system prune elimina contenedores detenidos, redes sin uso, imágenes huérfanas (dangling) y caché de compilación sin uso. Con -a también borra todas las imágenes que no tenga asociadas un contenedor: en un servidor que conserva imágenes de reversión, eso las elimina. Con --volumes añade los volúmenes anónimos sin uso. Por defecto no borra volúmenes, pero conviene no ejecutarlo a ciegas en producción. docker builder prune es la opción acotada: solo caché.

Los logs de los contenedores

Si docker system df no muestra una caché grande, revisa el tamaño de los logs. Con el controlador json-file, max-size viene sin límite por defecto. Puedes activar la rotación en daemon.json con log-opts (max-size y max-file); la documentación indica que se aplica a los contenedores creados después de reiniciar Docker, no a los existentes.

Imágenes antiguas

docker image prune elimina las imágenes huérfanas; con -a elimina todas las que no usa ningún contenedor. Antes de usar -a, asegúrate de que no necesitas esas imágenes para volver a una versión anterior.

Otro constructor de buildx

Si usas un constructor distinto del predeterminado, la limpieza se aplica al constructor seleccionado. La opción --builder permite indicar otro. En versiones recientes del CLI, la ayuda de docker builder prune muestra el uso docker buildx prune, por lo que la referencia de buildx citada abajo también aplica.

Resumen

Un disco lleno con datos pequeños suele deberse a la caché de compilación; confírmalo con docker system df (fila Build Cache).
docker builder prune -af elimina esa caché sin tocar contenedores, imágenes ni volúmenes; el siguiente build será más lento.
Con --filter until=... o --reserved-space conservas la caché reciente; revisa las opciones con --help en tu versión.
Programa la limpieza (fin del despliegue o cron mensual) o limita el recolector de BuildKit en daemon.json.
No uses docker system prune -a a ciegas: puede borrar imágenes de reversión.

Referencias

Prisma P2028: Transaction already closed (timeout)

2026-10-17T09:00:00.000-05:00

Una operación grande falla en producción con este error de Prisma, aunque en las pruebas con un solo elemento funcionaba:

PrismaClientKnownRequestError:
Transaction API error: Transaction already closed: A query cannot be executed on an expired transaction. The timeout for this transaction was 5000 ms, however 7413 ms passed since the start of the transaction. Consider increasing the interactive transaction timeout or doing less work in the transaction.
  code: 'P2028'

Según la operación que llegue tarde, el texto dice A query o A commit, pero el código es siempre P2028. Este artículo cubre el caso de prisma.$transaction(async (tx) => ...) en Prisma Client 6 con PostgreSQL, y la combinación de causas que lo provoca con más frecuencia: usar el cliente global dentro de la transacción y hacer una consulta por cada elemento.

Por qué pasa

Una transacción interactiva ($transaction con una función asíncrona) permanece abierta mientras la función se ejecuta. La documentación de Prisma define dos límites: timeout, el tiempo máximo que la transacción puede ejecutarse antes de cancelarse y revertirse (5 segundos por defecto), y maxWait, el tiempo máximo que Prisma Client espera para obtener la transacción de la base de datos (2 segundos por defecto). Cuando se supera timeout, las consultas posteriores fallan con P2028, cuya descripción oficial es "Transaction API error".

Con un elemento, la función termina en milisegundos y nunca se nota el límite. Con cientos, se suman dos problemas:

Cliente global dentro de la transacción. La documentación indica que las llamadas hechas sobre la instancia tx quedan dentro de la transacción; las que se hacen con otro cliente no forman parte de ella. Si un servicio importa el prisma global y lo usa en medio del callback, esas consultas se ejecutan fuera de la transacción (no se revierten con el resto) y, mientras tanto, la transacción sigue abierta consumiendo tiempo.
Consultas N+1. Calcular el número de secuencia de cada elemento con un COUNT(*) completo significa una consulta adicional por elemento, todas en serie. Con cientos de elementos, esos viajes a la base de datos pueden bastar para pasar de los 5 segundos.

La propia documentación advierte que mantener transacciones abiertas durante mucho tiempo perjudica el rendimiento y puede causar bloqueos mutuos, y recomienda evitar peticiones de red y consultas lentas dentro de la función y mantener la transacción lo más corta posible.

Solución

Localiza el trabajo innecesario dentro del callback. Este es el patrón problemático, simplificado:

await prisma.$transaction(async (tx) => {
  for (const linea of lineas) {
    // N+1: un COUNT(*) completo por cada línea
    const total = await tx.movimiento.count({ where: { loteId } });

    await tx.movimiento.create({
      data: { loteId, productoId: linea.productoId, cantidad: linea.cantidad, numero: total + 1 },
    });

    // este servicio usa el cliente global `prisma` por dentro, no `tx`
    await servicioStock.ajustar(linea.productoId, linea.cantidad);
  }
});

Pasa tx a todo lo que deba ocurrir dentro de la transacción. Las funciones auxiliares reciben el cliente transaccional como parámetro en lugar de importar el global:
```
import { Prisma } from "@prisma/client";

export async function ajustarStock(tx: Prisma.TransactionClient, lineas: Linea[]) {
  for (const linea of lineas) {
    await tx.stock.update({
      where: { productoId: linea.productoId },
      data: { cantidad: { increment: linea.cantidad } },
    });
  }
}
```
Prisma.TransactionClient es el tipo que genera Prisma Client para tx; la documentación oficial de la versión 6 no lo describe, así que confirma que existe en tu versión.
Calcula una sola vez y deriva el resto en memoria. Cuenta antes del bucle y asigna los números con el índice. Si puedes, inserta en bloque con createMany:
```
const base = await tx.movimiento.count({ where: { loteId } });

await tx.movimiento.createMany({
  data: lineas.map((linea, i) => ({
    loteId,
    productoId: linea.productoId,
    cantidad: linea.cantidad,
    numero: base + i + 1,
  })),
});
```
Si el número debe ser único aunque dos procesos reciban a la vez, contar filas no lo garantiza: apóyate en una secuencia de la base de datos o en una restricción única con reintento.

Saca de la transacción lo que no necesita ser atómico. Dentro queda lo que debe confirmarse o revertirse en conjunto. Auditoría, notificaciones, llamadas HTTP o invalidación de caché se ejecutan después del commit, con el valor que devuelve $transaction:

const resultado = await prisma.$transaction(
  async (tx) => {
    const base = await tx.movimiento.count({ where: { loteId } });
    // construirMovimientos arma el arreglo con `numero: base + i + 1`, como en el paso 3
    await tx.movimiento.createMany({ data: construirMovimientos(lineas, loteId, base) });
    await ajustarStock(tx, lineas);
    return { loteId, cantidadLineas: lineas.length };
  },
  { timeout: 30000, maxWait: 10000 },
);

// la transacción ya está confirmada
await registrarAuditoria(resultado);
await notificarRecepcion(resultado);

Si uno de esos pasos posteriores falla, los datos ya están guardados: hazlos reintentables o idempotentes.

Añade un margen con timeout y maxWait después de optimizar, no en lugar de optimizar. Subir el límite no hace más rápido el código, solo retrasa el fallo, y una transacción larga mantiene bloqueos. Úsalo como colchón. Si lo necesitas en todas las transacciones, el constructor acepta transactionOptions con los mismos campos:
```
const prisma = new PrismaClient({
  transactionOptions: { timeout: 30000, maxWait: 10000 },
});
```
Prueba con un volumen realista. Un caso con un solo elemento no detecta este problema. Ejecuta la operación con cientos de elementos, igual que en producción.

Cómo verificar que quedó resuelto

Ejecuta la operación con un volumen parecido al real y mide el tiempo:

console.time("recepcion");
await recibirLote(loteId, lineas); // 300-400 elementos
console.timeEnd("recepcion");

No debe aparecer P2028. Comprueba además la integridad de los datos:

SELECT numero, COUNT(*) FROM movimiento WHERE lote_id = 1 GROUP BY numero HAVING COUNT(*) > 1;
SELECT SUM(cantidad) FROM movimiento WHERE lote_id = 1;

La primera consulta no debe devolver filas (números únicos) y la segunda debe coincidir con la suma de las cantidades enviadas. En una prueba local con 350 elementos, la operación terminó en unos 7,4 segundos sin error. Ese tiempo supera los 5 segundos por defecto, lo que confirma que el límite también influía y que el margen del paso 5 era necesario.

Variantes y errores relacionados

Una primera corrección parcial no basta

Si solo cambias el cliente global por tx y pruebas con un elemento, el error seguirá en producción. Revisa ambas causas y prueba con volumen.

`maxWait` agotado

Si en lugar de superar el tiempo de ejecución no se logra iniciar la transacción a tiempo, el límite que se agota es maxWait. Revisa también el pool de conexiones y que no haya muchas transacciones largas a la vez.

P2024: agotado el pool de conexiones

La descripción oficial de P2024 es "Timed out fetching a new connection from the connection pool". Puede aparecer cuando muchas operaciones concurrentes mantienen conexiones ocupadas, por ejemplo transacciones largas.

Consultas sin `await`

Una consulta lanzada dentro del callback sin await (por ejemplo en un forEach) puede ejecutarse cuando la transacción ya terminó y producir un error similar. Usa for...of con await, o Promise.all sobre un map.

P2034: conflicto de escritura o bloqueo mutuo

Es otro error de transacciones: "Transaction failed due to a write conflict or a deadlock". Su descripción oficial pide reintentar la transacción.

Versión de la documentación

Este artículo se basa en la documentación de Prisma 6. La documentación publicada para versiones más recientes puede describir una API de transacciones distinta, así que confirma que consultas la versión de tu proyecto.

Resumen

P2028 "Transaction already closed" significa que la transacción interactiva superó su timeout (5 s por defecto) antes de que llegara otra consulta.
Dentro de $transaction usa siempre tx; un servicio que importe el cliente global ejecuta fuera de la transacción.
Elimina el N+1: calcula el conteo base una vez y deriva los números en memoria, con createMany si es posible.
Mueve a después del commit lo que no necesita ser atómico y añade { timeout, maxWait } solo como margen.
Prueba siempre con un volumen realista, no con un único elemento.

Referencias

Tailwind 4: las utilidades no se aplican (CSS sin @layer)

2026-10-16T15:00:00.000-05:00

Migras a Tailwind CSS 4 (o empiezas un proyecto nuevo, por ejemplo con shadcn/ui en Next.js) y algunas utilidades dejan de tener efecto. La clase está en el HTML y la regla aparece en el CSS compilado, pero el estilo calculado sigue siendo el global:

<div class="border border-red-500">Aviso</div>
<h1 class="text-white">Título</h1>

getComputedStyle(document.querySelector(".border-red-500")).borderTopColor
// el gris de tu regla global, no el rojo de la utilidad

Pasa con border-*, divide-*, text-* y cualquier utilidad que choque con una regla global de tu hoja de estilos. No hay mensaje de error: en las herramientas de desarrollo del navegador, la declaración de la utilidad suele aparecer tachada. Este artículo explica la causa y cómo corregirla.

Por qué pasa

Tailwind 4 usa capas de cascada nativas de CSS. El archivo que importa con @import "tailwindcss" declara el orden theme, base, components, utilities, inyecta Preflight en la capa base y coloca todas las utilidades en la capa utilities.

La regla de CSS que rige aquí está documentada en MDN: los estilos que no están dentro de ninguna capa siempre prevalecen sobre los estilos declarados en capas, para declaraciones normales (sin !important). Además, una vez establecido el orden de capas, la especificidad y el orden de aparición dejan de contar entre capas distintas. Por eso, una regla global como esta gana a cualquier utilidad, aunque la utilidad tenga una clase y la regla global solo un selector * o h1:

* {
  border-color: hsl(var(--border));
}

h1, h2, h3 {
  color: var(--text-heading);
}

En Tailwind 3 esto no ocurría con estos selectores. Allí no se usaban capas nativas (la directiva @layer la procesaba Tailwind), y la clase de la utilidad ganaba por especificidad al selector * o h1. En Tailwind 4 la comparación se decide antes, por capas, y el CSS sin capa gana. Si pegas el mismo código en un proyecto nuevo, falla sin avisar.

Solución

Localiza las reglas sin capa. Abre tu hoja de estilos global (en Next.js suele ser app/globals.css) y busca selectores que estén fuera de cualquier @layer: *, html, body, h1, a, etc. Las que fijan propiedades que las utilidades también controlan (color, borde, fuente, fondo) son las sospechosas.
Muévelas a @layer base. Es la capa que Tailwind reserva para los estilos por defecto de elementos y la que usa su documentación para ese fin:
```
@import "tailwindcss";

@layer base {
  * {
    border-color: hsl(var(--border));
  }

  h1, h2, h3 {
    color: var(--text-heading);
  }
}
```
La guía de instalación manual de shadcn/ui sigue el mismo patrón: sus reglas de * y body están dentro de @layer base. Las variables CSS de :root y .dark no compiten con las utilidades, así que no hace falta moverlas; la guía de migración de shadcn/ui a Tailwind 4 incluso las saca de @layer base.
No confundas acotar con dar prioridad. Si una regla no debe afectar a todo el documento, limita su alcance (por ejemplo .contenido h1), pero déjala igualmente dentro de una capa. Acotar el selector no devuelve la prioridad a las utilidades: una regla sin capa gana sin importar lo específico que sea su selector. Si quieres que sea un estilo de componente que las utilidades puedan sobrescribir, usa @layer components.
Pon en una capa el CSS de terceros. Una hoja de estilos importada sin capa tiene el mismo efecto. Impórtala dentro de una capa:
```
@import "tailwindcss";
@import "libreria-ui/estilos.css" layer(components);
```
Revisa las pantallas después del cambio. Elementos que se veían grises por error ahora mostrarán el color real de su utilidad. Un caso típico: un spinner con border-white sobre un fondo claro, que antes se veía gris y ahora queda invisible. Recorre las pantallas en modo claro y oscuro.

Cómo verificar que quedó resuelto

Mide el estilo calculado antes y después del cambio, en modo claro y en modo oscuro (alterna el modo como lo haga tu proyecto, por ejemplo con la clase dark en <html>). En la consola del navegador:

for (const sel of [".border-red-500", ".border-info\\/30", "h1.text-white"]) {
  const el = document.querySelector(sel);
  if (el) {
    const estilo = getComputedStyle(el);
    console.log(sel, estilo.borderTopColor, estilo.color);
  }
}

Antes de la corrección, todos los bordes devuelven el mismo gris global y el título conserva su color global. Después, cada elemento devuelve el color de su utilidad. Para descartar regresiones, ejecuta también el lint, la comprobación de tipos y la compilación de producción de tu proyecto.

Si comparas dos versiones del CSS compilado desde un script de Node con @tailwindcss/postcss, ejecuta cada una en un proceso distinto. El plugin guarda en caché el compilador por archivo de entrada y lo reutiliza entre compilaciones, así que dos compilaciones en el mismo proceso pueden no ser independientes.

Variantes y errores relacionados

Los bordes se ven del color del texto tras migrar

No es este problema. En Tailwind 4, el color de borde por defecto de border-* y divide-* pasó a ser currentColor (en Tailwind 3 era gray-200). La guía de actualización ofrece una regla de compatibilidad que, de nuevo, va dentro de @layer base:

@layer base {
  *,
  ::after,
  ::before,
  ::backdrop,
  ::file-selector-button {
    border-color: var(--color-gray-200, currentColor);
  }
}

Una clase propia en `@layer utilities` deja de funcionar con variantes

En Tailwind 4, @layer utilities ya no registra utilidades propias: la guía de actualización indica usar @utility para que funcionen con variantes como hover o lg.

`!important` como parche

MDN explica que !important invierte el orden: las declaraciones importantes dentro de una capa ganan a las importantes fuera de ella. Aun así, forzar cada utilidad es un parche frágil. Es mejor corregir la capa de la regla global.

Resumen

Si una utilidad de Tailwind 4 está en el CSS compilado pero no se aplica, busca reglas globales fuera de @layer.
El CSS sin capa gana al CSS en capas, sin importar la especificidad; las utilidades de Tailwind 4 están en @layer utilities.
Mueve esas reglas a @layer base (o a components) e importa el CSS de terceros con layer(...).
Revisa las pantallas: los elementos que parecían grises ahora muestran su color real, y algunos (como un borde blanco) pueden dejar de verse.
Verifica con getComputedStyle antes y después, en modo claro y oscuro.

Referencias

Prisma generate EPERM: query_engine-windows.dll.node

2026-10-16T09:00:00.000-05:00

Ejecutas prisma generate en Windows (a mano, en un script de instalación o dentro de un hook de Git) y falla con un error como este:

EPERM: operation not permitted, rename 'C:\proyectos\mi-app\node_modules\...\query_engine-windows.dll.node.tmp1234' -> 'C:\proyectos\mi-app\node_modules\...\query_engine-windows.dll.node'

Los puntos suspensivos sustituyen la parte intermedia de la ruta, que cambia según el gestor de paquetes (npm, pnpm, Yarn). Si el comando forma parte de un hook pre-push, el error bloquea el push aunque el lint, los tests y el build pasen. Este artículo explica qué proceso tiene bloqueado el archivo y cómo liberarlo sin matar todos los procesos de Node.js del equipo.

Por qué pasa

El cliente de Prisma incluye el motor de consultas (query engine), un módulo nativo con extensión .node que Node.js carga en el proceso. La documentación de Prisma indica que, en las versiones con motor en Rust, el cliente carga el motor como una librería Node-API por defecto, y que prisma generate deja los archivos del motor junto al cliente generado.

Al regenerar el cliente, Prisma escribe primero un archivo temporal con sufijo .tmpNNNN y luego lo renombra encima del archivo del motor. Si otro proceso node.exe tiene ese archivo cargado, Windows no permite reemplazarlo y el renombrado falla con EPERM. Los procesos que suelen mantenerlo cargado son:

el servidor de desarrollo (next dev, nest start --watch y similares),
un worker o script en segundo plano que usa el cliente de Prisma,
la sesión de otro editor o terminal que tiene el proyecto en ejecución.

El mensaje habla de permisos, pero la causa es un archivo en uso. Esto se puede reproducir sin Prisma: si un proceso carga una DLL y otro intenta renombrar un archivo encima de ella, Node.js devuelve EPERM en la operación rename, y el archivo temporal queda huérfano en la carpeta.

Alcance: el error pertenece a la arquitectura con el motor de consultas en Rust. Prisma ORM 7 hizo que el cliente sin Rust fuera el predeterminado y eliminó los motores de tipo librería y binario, así que este artículo aplica a Prisma 6 y versiones anteriores.

Solución

Detén el servidor de desarrollo y Prisma Studio de la forma habitual (Ctrl+C en su terminal) y cierra otras sesiones del proyecto. Si el error persiste, localiza los procesos node.exe que pertenecen a ese proyecto, y solo a ese. Con PowerShell:
```
$proyecto = 'C:\proyectos\mi-app'

$procesos = Get-CimInstance Win32_Process -Filter "Name = 'node.exe'" |
  Where-Object { $_.CommandLine -and $_.CommandLine.IndexOf($proyecto, [StringComparison]::OrdinalIgnoreCase) -ge 0 }

$procesos | Select-Object ProcessId, CommandLine | Format-List
```
La clase Win32_Process expone la línea de comandos de cada proceso en la propiedad CommandLine; el filtro conserva solo los que mencionan la ruta de tu proyecto. Revisa la lista antes de continuar: un proceso cuya línea de comandos no incluya la ruta no aparecerá aquí.

Deténlos. Primero una simulación con -WhatIf y luego la acción real:

$procesos | ForEach-Object { Stop-Process -Id $_.ProcessId -WhatIf }
$procesos | ForEach-Object { Stop-Process -Id $_.ProcessId }

Borra el archivo .tmp huérfano. Desde la raíz del proyecto:
```
Get-ChildItem -Path .\node_modules -Recurse -Force -Filter 'query_engine-windows.dll.node.tmp*' | Remove-Item -Force
```
Puede tardar unos segundos en proyectos con muchas dependencias. No toques el archivo query_engine-windows.dll.node sin sufijo: prisma generate lo reemplaza por ti.
Regenera el cliente.
```
npx prisma generate
```
Con pnpm sería pnpm prisma generate.

Cómo verificar que quedó resuelto

prisma generate termina sin el error EPERM y con el mensaje de que el cliente se generó. En un caso real tardó menos de un segundo.

No quedan archivos temporales:

Get-ChildItem -Path .\node_modules -Recurse -Force -Filter 'query_engine-windows.dll.node.tmp*'

El comando no debe devolver nada.

El flujo que fallaba vuelve a funcionar: haz git push y comprueba que el hook pre-push se ejecuta completo (lint, tests, build y generación del cliente) y que el push termina.

Variantes y errores relacionados

No uses `taskkill /im node.exe`

Ese comando termina todos los procesos con ese nombre de imagen, no solo los de tu proyecto: también otros servidores de desarrollo, herramientas y extensiones que usan Node.js. Por eso el filtro por línea de comandos del paso 1 es mejor: solo detienes procesos de ese proyecto.

No uses `--no-verify`

Saltarte el hook con git push --no-verify hace desaparecer el síntoma, pero también las comprobaciones que el hook existe para garantizar. El problema real (un proceso con el archivo en uso) sigue ahí y reaparecerá en la siguiente regeneración.

Si el error continúa

Normalmente significa que algún proceso sigue manteniendo cargado el motor. Puede ser un node.exe cuya línea de comandos no menciona la ruta de tu proyecto, o una herramienta que mantiene abierto el proyecto. Cierra las ventanas de editor y terminales que lo usen y repite el paso 1 con una parte más corta de la ruta. Como último recurso, reiniciar la sesión de Windows libera todos los archivos cargados.

Cómo evitarlo

Antes de cambiar de rama, actualizar Prisma o ejecutar prisma generate, detén el servidor de desarrollo del proyecto. Es un solo paso y evita todo este recorrido.

Resumen

El EPERM en rename de query_engine-windows.dll.node significa que otro proceso node.exe tiene cargado el motor y Windows no deja reemplazarlo.
Identifica los procesos de tu proyecto con Get-CimInstance Win32_Process, filtrando CommandLine por la ruta, y detén solo esos.
Borra el .tmp huérfano y ejecuta de nuevo prisma generate.
No uses taskkill /im node.exe ni --no-verify.
El caso aplica al motor en Rust (Prisma 6 y anteriores).

Referencias

UnicodeEncodeError: 'charmap' codec can't encode: solución

2026-10-15T15:00:00.000-05:00

Un script de Python que funciona sin problemas en otra máquina falla en Windows al imprimir texto con emojis o símbolos:

Traceback (most recent call last):
  File "informe.py", line 3, in <module>
    print("\U0001F550 \u2264")
  File "...\Lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f550' in position 0: character maps to <undefined>

El carácter puede ser otro (por ejemplo '\u2264', el símbolo ≤). Con la misma raíz, leer un archivo JSON con open() falla en sentido contrario:

UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 15: character maps to <undefined>

Los datos no tienen nada malo: el JSON es válido y el texto que quieres enviar a otro sistema también. Falla solo el paso local de leer del disco o escribir en la salida estándar con una codificación que no soporta esos caracteres.

Por qué pasa

Para convertir texto en bytes (y al revés) Python necesita una codificación. Si no se le indica una, usa la del sistema. En muchas instalaciones de Windows en español, esa codificación es cp1252, que no contiene emojis ni símbolos como ≤. El nombre charmap del error viene del códec que implementa cp1252, no de tu código.

Hay dos puntos donde ocurre:

Archivos. En Python 3.14 y anteriores, open() sin encoding usa la codificación local. Un archivo escrito en UTF-8 se lee entonces como cp1252: algunos bytes (como 0x90) no existen en esa tabla y producen UnicodeDecodeError; el resto se decodifica sin error, pero mal. Por ejemplo, canción se lee como canciÃ³n.
Salida estándar. Desde Python 3.6, la consola interactiva de Windows usa UTF-8, pero la documentación aclara que ese cambio solo se aplica a la consola interactiva, no cuando la salida se redirige a un archivo o a una tubería. Si el mismo script se ejecuta desde una tarea programada, un servicio, un sistema de CI, con > o |, o desde un terminal que entrega una tubería en lugar de una consola, print() vuelve a usar la codificación local.

Esto cambia en Python 3.15: según la documentación, el modo UTF-8 pasa a estar activado por defecto (PEP 686) y open() usa UTF-8 si no se indica encoding. En 3.14 y versiones anteriores el problema sigue vigente.

Solución

Comprueba qué codificación está usando tu Python.
```
import locale, sys
print(sys.version.split()[0], sys.stdout.encoding, locale.getpreferredencoding(False), sys.flags.utf8_mode)
```
Si ejecutas esto con la salida redirigida (por ejemplo, añadiendo | more al comando de Python) y ves cp1252 y 0, estás en el caso descrito.
En archivos, indica siempre la codificación. Es la solución más robusta porque no depende del equipo donde se ejecute:
```
import json

with open("datos.json", encoding="utf-8") as f:
    datos = json.load(f)

with open("salida.json", "w", encoding="utf-8") as f:
    json.dump(datos, f, ensure_ascii=False, indent=2)
```
Pasar encoding de forma explícita hace que el código se comporte igual en todas las versiones de Python y en todos los equipos.
En la salida estándar, elige una de estas opciones.
- Dentro del script, al inicio (disponible desde Python 3.7):
```
import sys
sys.stdout.reconfigure(encoding="utf-8")
```
- Con una variable de entorno, solo para la salida estándar. En PowerShell, para la sesión actual:
```
$env:PYTHONIOENCODING = 'utf-8'
python informe.py
```
  En cmd es set PYTHONIOENCODING=utf-8. Para dejarla definida en tu usuario puedes usar setx PYTHONIOENCODING utf-8; solo afecta a los procesos que abras después.
- Con el modo UTF-8 de Python (3.7 o posterior), que además hace que open() use UTF-8 por defecto:
```
python -X utf8 informe.py
```
  Equivale a definir PYTHONUTF8=1.
En una tarea programada o un servicio, configura el entorno de esa tarea. No hereda el entorno de tu terminal. La forma más simple es poner la opción en el propio comando, por ejemplo python -X utf8 C:\proyectos\mi-app\informe.py, o definir la variable de entorno en la configuración de la tarea o del servicio.

Elegir entre PYTHONIOENCODING y el modo UTF-8 es una cuestión de alcance. PYTHONIOENCODING solo cambia stdin, stdout y stderr. El modo UTF-8 también cambia la codificación por defecto de open(), por lo que un script que lea archivos antiguos en cp1252 sin indicar encoding pasaría a leerlos mal. Si tienes archivos así, indícalo en cada open() con encoding="cp1252".

Cómo verificar que quedó resuelto

Prueba siempre con la salida redirigida, porque en la consola interactiva el error puede no aparecer ni siquiera antes de la corrección:

python informe.py | more
python -c "import json; print(json.load(open('datos.json', encoding='utf-8')))" | more

El primer comando debe imprimir todo el texto, con emojis y símbolos, sin Traceback. El segundo debe cargar el JSON. Para confirmar la codificación de la salida:

python -X utf8 -c "import sys; print(sys.stdout.encoding)" | more

Debe mostrar utf-8. Si el script se ejecuta como tarea programada o servicio, revisa su registro después de la primera ejecución real.

Variantes y errores relacionados

Error al escribir un archivo

Un open("salida.txt", "w") sin encoding produce el mismo UnicodeEncodeError al escribir texto que cp1252 no contiene. La solución es la del paso 2.

`UnicodeDecodeError: 'utf-8' codec can't decode byte ...`

Es el caso inverso: el archivo no está en UTF-8, sino en cp1252 o en otra codificación, y lo abres como UTF-8. Indica la codificación real (encoding="cp1252") o convierte el archivo a UTF-8.

`PYTHONIOENCODING` con manejador de errores

La sintaxis es codificación:manejador. Por ejemplo, PYTHONIOENCODING=cp1252:replace evita la excepción sustituyendo cada carácter no representable por ?. Es útil para que un script no se detenga, pero pierde información: no lo uses si necesitas conservar el texto.

La variable no cambia nada en la consola interactiva

En Windows, PYTHONIOENCODING se ignora en los búferes de la consola interactiva (salvo que también se defina PYTHONLEGACYWINDOWSSTDIO); sí afecta a archivos y tuberías redirigidos. Por eso conviene probar con la salida redirigida, como se explica arriba.

Python 3.15 o posterior

Con el modo UTF-8 activado por defecto, el código sin encoding lee y escribe UTF-8. Si necesitas el comportamiento anterior, puedes desactivarlo con PYTHONUTF8=0 o -X utf8=0, o pedir la codificación local de forma explícita con encoding="locale" (disponible desde Python 3.10).

Resumen

'charmap' codec can't encode/decode en Windows suele significar que Python usó cp1252 por defecto; los datos no están dañados.
Al leer o escribir archivos, pasa siempre encoding="utf-8" a open().
Para la salida, usa sys.stdout.reconfigure(encoding="utf-8"), PYTHONIOENCODING=utf-8 o python -X utf8 (equivale a PYTHONUTF8=1).
El fallo aparece sobre todo con la salida redirigida (tareas, servicios, CI, tuberías); en tareas y servicios configura la opción en su propio entorno.
Desde Python 3.15 el modo UTF-8 es el predeterminado; en 3.14 y anteriores sigue haciendo falta lo anterior.

Referencias

fatal: detected dubious ownership in repository: solución

2026-10-15T09:00:00.000-05:00

Abres una carpeta con un repositorio, ejecutas cualquier comando de Git y todos fallan con este mensaje:

fatal: detected dubious ownership in repository at 'D:/proyectos/mi-repo'
To add an exception for this directory, call:

	git config --global --add safe.directory D:/proyectos/mi-repo

Según la versión de Git, entre ambas líneas puede aparecer información sobre el propietario de la carpeta y el usuario actual. Este artículo explica qué está protegiendo Git, cómo agregar la excepción correcta en Windows y por qué conviene evitar el comodín * que aparece en muchas respuestas.

Por qué pasa

La documentación de Git explica que, por defecto, se niega a leer siquiera la configuración de un repositorio cuyo propietario es otro usuario, y mucho menos a ejecutar sus hooks. La razón es de seguridad: la configuración y los hooks de un repositorio pueden ejecutar comandos, así que Git no los acepta de una carpeta que controla otra persona.

En Windows, Git compara el propietario de la carpeta (un identificador de seguridad, o SID) con el usuario que ejecuta el comando. Si no coinciden, aparece el error. Se ha visto en estos casos:

La carpeta la creó otro usuario.
El repositorio se copió desde otra máquina.
El repositorio está en un disco sincronizado.

Las versiones iniciales de esta protección mostraban otro texto: fatal: unsafe repository ('...' is owned by someone else). Es el mismo problema con el mismo arreglo.

Solución

Confirma que el propietario no coincide. En PowerShell:
```
"$env:USERDOMAIN\$env:USERNAME"
(Get-Acl -LiteralPath 'D:\proyectos\mi-repo').Owner
```
Si el segundo valor es distinto del primero (por ejemplo EQUIPO\otro-usuario frente a EQUIPO\tu-usuario), esa es la causa. Antes de continuar, asegúrate de que confías en el contenido de esa carpeta: la excepción hace que Git vuelva a aceptar su configuración y sus hooks.
Agrega la excepción de forma permanente, solo para ese repositorio. Usa la ruta exacta que muestra el mensaje, con barras normales:
```
git config --global --add safe.directory D:/proyectos/mi-repo
```
safe.directory admite varios valores, y --add agrega uno nuevo sin reemplazar los anteriores. La excepción vale para esa ruta; si mueves la carpeta, debes agregar la nueva ruta.
Si solo necesitas ejecutar un comando una vez, pasa la opción por línea de comandos en lugar de guardarla:
```
git -c safe.directory=D:/proyectos/mi-repo status
```
La documentación actual de Git incluye la opción -c entre las configuraciones "protegidas" que sí se respetan. En versiones antiguas, la documentación de safe.directory decía que se ignoraba cuando se pasaba con -c; si en tu versión no funciona, actualiza Git o usa el paso 2.

Cómo verificar que quedó resuelto

git status
git config --global --get-all safe.directory

El primer comando debe mostrar el estado del repositorio sin el fatal. El segundo debe listar la ruta que agregaste (una línea por cada excepción). Para confirmar que puedes trabajar con normalidad, crea y borra una rama de prueba:

git switch -c prueba-propietario
git switch -
git branch -d prueba-propietario

Variantes y errores relacionados

No uses `safe.directory '*'`

git config --global --add safe.directory '*'   # evítalo

Funciona, pero según la documentación de Git, el valor * desactiva por completo esta comprobación de seguridad. Dejas sin protección todos los repositorios del equipo, incluidos los que descargues o recibas de terceros en el futuro. Agrega solo las rutas en las que confías.

Agregarlo en el `.git/config` del repositorio no sirve

Git solo respeta safe.directory en la configuración protegida: la del sistema, la global y la de línea de comandos. Si lo escribes en el archivo de configuración del propio repositorio, se ignora, porque de lo contrario cualquier repositorio podría declararse seguro a sí mismo.

Revisa la carpeta antes de confiar en ella

Si el repositorio viene de una persona o de una máquina que no controlas, abre con un editor de texto el archivo .git/config y la carpeta .git/hooks antes de agregar la excepción. Son justo los elementos que Git no quiere ejecutar sin tu confirmación.

Quitar o revisar excepciones

Para revisar todas las excepciones usa git config --global --get-all safe.directory; con git config --show-origin --get-all safe.directory verás además de qué archivo viene cada valor. Estas excepciones se guardan en tu configuración global (por ejemplo, el archivo .gitconfig de tu carpeta de usuario). Para borrar alguna, abre ese archivo con git config --global --edit y elimina la línea correspondiente.

Alternativa: corregir el propietario

Si la carpeta debería pertenecerte, otra opción es cambiar su propietario al usuario actual con las herramientas de permisos de Windows (esto suele requerir permisos de administrador). A diferencia de safe.directory, resuelve la causa en lugar de aceptar la diferencia.

Resumen

El error significa que el propietario de la carpeta no es el usuario que ejecuta Git; es una protección, no un fallo del repositorio.
La solución permanente es git config --global --add safe.directory D:/ruta/exacta, una vez por repositorio y con la ruta tal como la muestra el mensaje.
Para un único comando puedes usar git -c safe.directory=... status, si tu versión de Git lo admite.
Evita el valor *: desactiva la protección para todos los repositorios.
Verifica con git status y git config --global --get-all safe.directory.

Referencias

Git: git-config, entrada safe.directory y sección SCOPES (configuración protegida)

curl no funciona en PowerShell: SessionVariable y Headers

2026-10-14T15:00:00.000-05:00

Copias un comando curl de la documentación de una API, lo pegas en PowerShell y en lugar de una respuesta HTTP obtienes errores como estos:

Invoke-WebRequest : Falta un argumento para el parámetro 'SessionVariable'. Especifique un parámetro del tipo 'System.String' e inténtelo de nuevo.

Invoke-WebRequest : No se puede enlazar el parámetro 'Headers'. No se puede convertir el valor "Accept: application/json" de tipo "System.String" al tipo "System.Collections.IDictionary".

Le pasa a quien usa Windows PowerShell 5.1, el que viene instalado con Windows, y ejecuta comandos pensados para el curl de Linux o macOS. Aquí verás por qué ocurre y tres formas de resolverlo.

Por qué pasa

En Windows PowerShell 5.1, curl no es el programa curl: es un alias del cmdlet Invoke-WebRequest. La documentación de Microsoft para la versión 5.1 lo indica de forma explícita: los alias de ese cmdlet son iwr, curl y wget.

Como el alias ejecuta un cmdlet, las opciones de curl se interpretan como parámetros de PowerShell:

-s es un prefijo único, así que PowerShell lo completa como -SessionVariable, que exige un valor. De ahí el primer error.
-H se completa como -Headers, que espera un diccionario (una tabla hash) y no el texto "Accept: application/json". De ahí el segundo error.
Otras opciones típicas de curl, como -X, tampoco existen: PowerShell responde que no encuentra ningún parámetro con ese nombre.

Hay un problema adicional: /dev/null no existe en Windows. Y si llamas al programa real, las comillas dobles de un JSON se pierden por el camino (más abajo se explica).

Una precisión sobre PowerShell 7: este alias es propio de Windows PowerShell 5.1. La documentación de Invoke-WebRequest para PowerShell 7.5 solo lista el alias iwr: curl y wget ya no figuran como alias del cmdlet. Si un comando curl te falla en PowerShell 7, la causa puede ser otra, por ejemplo la forma en que se pasan las comillas a los programas nativos.

Solución

Windows 10 y Windows 11 incluyen curl por defecto. Según el sitio de curl, la solución para PowerShell es invocarlo como curl.exe para que no se trate como alias.

Llama a curl.exe explícitamente.

curl.exe -s -H "Accept: application/json" https://example.com/api/items

Sustituye /dev/null por NUL. Para descartar el cuerpo y mostrar solo el código de estado:
```
curl.exe -s -o NUL -w "%{http_code}" https://example.com
```
Con /dev/null, curl.exe termina con el código de salida 23, que la documentación de curl describe como error de escritura.
Envía el JSON desde un archivo. Es la forma más portable. Guarda el cuerpo en body.json (UTF-8, preferiblemente sin BOM) y pásalo con --data-binary:
```
curl.exe -X POST -H "Content-Type: application/json" --data-binary "@./body.json" https://example.com/api/items
```
El prefijo @ le indica a curl que lea el cuerpo de ese archivo (la ruta es relativa a la carpeta actual) y --data-binary lo envía sin procesarlo.

Si prefieres escribir el JSON en la propia línea, en Windows PowerShell 5.1 hay que escapar las comillas dobles con una barra invertida; sin ese escape, el servidor recibe {nombre:mi-app} y no un JSON válido:
```
curl.exe -X POST -H "Content-Type: application/json" -d '{\"nombre\":\"mi-app\"}' https://example.com/api/items
```
Ese escape manual depende de la versión. PowerShell 7.3 cambió la forma de pasar argumentos a programas nativos (variable $PSNativeCommandArgumentPassing), y Microsoft lo documenta como un cambio que rompe compatibilidad. Si tu script debe funcionar en ambas versiones, usa el archivo.

Alternativa nativa: Invoke-RestMethod. Recibe los encabezados como tabla hash y convierte la respuesta JSON en objetos:

$headers = @{ Accept = 'application/json' }
$body = @{ nombre = 'mi-app' } | ConvertTo-Json -Compress

Invoke-RestMethod -Uri 'https://example.com/api/items' `
  -Method Post `
  -Headers $headers `
  -ContentType 'application/json' `
  -Body $body

Opcional: quitar el alias. Si usas curl a diario en PowerShell 5.1, puedes eliminarlo de la sesión con Remove-Item Alias:curl y agregar esa línea a tu perfil de PowerShell. Después, curl a secas ejecutará el programa real. Ten en cuenta que cualquier script tuyo que dependa del alias dejará de funcionar.

Cómo verificar que quedó resuelto

Comprueba a qué resuelve cada nombre:

Get-Command curl        # CommandType: Alias, Definition: Invoke-WebRequest
Get-Command curl.exe    # CommandType: Application

Luego ejecuta una petición real y revisa el código de estado:

curl.exe -s -o NUL -w "%{http_code}" https://example.com
200

El número final es el código de estado que devuelva tu servidor (200 en el caso normal).

Para comprobar que el JSON viaja intacto, envíalo a tu API local o a un servicio de eco y verifica que el cuerpo recibido conserva las comillas dobles. Con Invoke-RestMethod, la respuesta llega ya convertida en objetos, por lo que puedes leer sus propiedades directamente.

Variantes y errores relacionados

Aviso de seguridad al usar el alias en 5.1

La documentación de Microsoft indica que, tras la actualización de seguridad del 9 de diciembre de 2025 (CVE-2025-54100), Invoke-WebRequest en Windows PowerShell 5.1 pide confirmación antes de analizar el contenido de la página, con el mensaje "Security Warning: Script Execution Risk". Se evita con el parámetro -UseBasicParsing. Es otra razón para usar curl.exe cuando solo necesitas la respuesta cruda.

Archivos con BOM

En Windows PowerShell 5.1, Set-Content -Encoding UTF8 escribe el archivo con BOM (en una prueba, los primeros bytes fueron EF BB BF). Algunos servidores no aceptan un BOM al inicio de un JSON; guarda body.json desde un editor que permita UTF-8 sin BOM.

Mismo comando, otro resultado según el terminal

En Git Bash (que incluye curl) y en Linux o macOS con curl instalado, curl ejecuta el programa real y los ejemplos de la documentación funcionan tal cual. El problema aparece cuando el terminal es Windows PowerShell 5.1.

Resumen

En Windows PowerShell 5.1, curl es un alias de Invoke-WebRequest; por eso -s y -H se interpretan como -SessionVariable y -Headers.
En PowerShell 7.x la documentación solo lista el alias iwr.
Usa curl.exe, NUL en lugar de /dev/null y un archivo con --data-binary para el JSON.
Invoke-RestMethod -Headers @{...} -ContentType ... -Body ... es la alternativa nativa.
Verifica con Get-Command curl y Get-Command curl.exe y con una petición real.

Referencias

husky pre-commit script failed (code 127): causa CRLF

2026-10-14T09:00:00.000-05:00

Haces git commit y Husky aborta el commit con un mensaje que parece un problema de PATH:

.husky/pre-commit: 6: : not found
husky - pre-commit script failed (code 127)
husky - command not found in PATH=node_modules/.bin:/usr/local/bin:/usr/bin:/bin

Las líneas que añade Husky pueden variar según la versión, pero el detalle importante es el mismo: el comando que "no se encuentra" tiene el nombre vacío (6: : not found). Pasa al usar Git en WSL2 (Ubuntu), Linux o macOS con hooks que se editaron o se descargaron en Windows. Este artículo explica por qué no es un problema de PATH, cómo confirmarlo y cómo evitar que vuelva a ocurrir.

Por qué pasa

Un archivo de texto termina cada línea con LF (\n, Linux y macOS) o con CRLF (\r\n, Windows). El intérprete sh solo reconoce \n como fin de línea, así que el \r sobrante se queda dentro de la línea. En una línea en blanco guardada con CRLF, ese carácter es lo único que hay: sh lo toma como un comando llamado \r, no lo encuentra y responde "not found" con estado de salida 127. El estándar POSIX define 127 como el estado de un comando que no se encuentra.

Por eso el mensaje tiene un nombre vacío entre los dos puntos: el carácter \r no se ve. Según el terminal, incluso puede verse desordenado, porque el retorno de carro mueve el cursor al inicio de la línea. El número (6) es la línea del hook donde sh tropezó con el comando vacío.

Husky ejecuta cada hook con sh -e (el script se detiene en el primer comando que falla) y solo informa del código de salida. En las versiones recientes, cuando ese código es 127 añade además el aviso command not found in PATH. Ese aviso es genérico y desvía el diagnóstico hacia el PATH, aunque la causa sea el formato del archivo.

El CRLF llega al hook por varias vías: un editor en Windows configurado para guardar con CRLF, una herramienta que genera el archivo, o core.autocrlf=true al clonar el repositorio en Windows y luego usarlo desde WSL. Si el comando faltante fuera real, el mensaje mostraría su nombre (por ejemplo pnpm: not found). El nombre vacío apunta al fin de línea.

Solución

Confirma que el hook tiene CRLF. Desde la raíz del repositorio, en WSL o Linux:
```
cat -A .husky/pre-commit
```
Con CRLF, cada línea termina en ^M$; con LF solo aparece $:
```
pnpm lint-staged^M$
^M$
pnpm exec tsc --noEmit^M$
```
La opción -A es de GNU coreutils. En macOS puedes usar file .husky/pre-commit (muestra "with CRLF line terminators") o git ls-files --eol .husky (el valor w/crlf indica CRLF en el directorio de trabajo).
Convierte los hooks a LF. Hazlo con todos los hooks que tengas (pre-commit, pre-push, commit-msg, etc.):
```
sed -i 's/\r$//' .husky/pre-commit .husky/pre-push
```
Esa sintaxis de sed -i es la de GNU (Linux y WSL). En macOS funciona perl -pi -e 's/\r$//' .husky/pre-commit .husky/pre-push, y en cualquier sistema puedes usar dos2unix si lo tienes instalado. También puedes cambiar el fin de línea desde el editor: en VS Code, haz clic en el indicador CRLF de la barra de estado y elige LF.
Fija LF con .gitattributes. Crea o edita el archivo en la raíz del repositorio:
```
.husky/* text eol=lf
*.sh text eol=lf
```
Según la documentación de Git, eol=lf indica que el archivo se escribe con LF en el directorio de trabajo al hacer checkout, y el atributo eol activa text si no estaba definido, de modo que Git también normaliza a LF al guardar en el índice. Solo cuando eol no está definido Git recurre a core.autocrlf o core.eol.
Renormaliza lo que ya estaba guardado con CRLF.
```
git add --renormalize .
git status
git commit -m "chore: normalize hook line endings to LF"
```
--renormalize vuelve a aplicar el filtro de normalización a todos los archivos rastreados, algo pensado justo para cuando cambias atributos de fin de línea. Actualiza el índice, no el directorio de trabajo: por eso el paso 2 va antes. Revisa git status antes de confirmar; solo deberían aparecer archivos que coincidan con esos patrones. Si el propio commit falla porque el hook aún tiene CRLF, usa git commit --no-verify solo para este commit de corrección.

Cómo verificar que quedó resuelto

cat -A .husky/pre-commit
git ls-files --eol .husky
sh -e .husky/pre-commit; echo $?

El primer comando no debe mostrar ^M. El segundo debe mostrar i/lf y w/lf con el atributo text eol=lf para cada hook. El tercero ejecuta el hook como lo hace Husky y debe terminar con 0 si las comprobaciones del hook pasan. Para cerrar, haz un commit y un push de prueba: ya no debe aparecer el código 127.

Variantes y errores relacionados

El mismo error en `pre-push` y otros hooks

La causa es idéntica en cualquier hook. Convierte todos los archivos de .husky/ que hayas creado, no solo el que falló primero.

Mensajes distintos según el intérprete

Con Bash, el mismo problema se ve como line 6: $'\r': command not found. Si el hook tiene un shebang y se ejecuta directamente, el sistema busca un intérprete llamado sh\r y el error es de este estilo: env: $'sh\r': No such file or directory. También termina con estado 127. En todos los casos la solución es la misma.

Cuando sí es un problema de `PATH`

Si el mensaje incluye el nombre de un comando real (pnpm: not found, node: not found), el fallo es de entorno. Es habitual con gestores de versiones de Node o con clientes gráficos de Git que no cargan tu configuración de shell. La documentación de Husky tiene una sección sobre gestores de versiones y PATH.

Otros scripts del repositorio

Los archivos .sh, los scripts de entrada de un Dockerfile y cualquier script que ejecute Linux fallan igual con CRLF. La segunda línea de .gitattributes (*.sh text eol=lf) los cubre.

Resumen

.husky/pre-commit: 6: : not found con el nombre vacío no es un problema de PATH: es un \r de CRLF que sh interpreta como un comando.
El código 127 significa "comando no encontrado" y el aviso de PATH que añade Husky es genérico.
Confirma con cat -A (busca ^M$) y corrige con sed -i 's/\r$//' o con el selector de fin de línea del editor.
Evita que vuelva con .husky/* text eol=lf y *.sh text eol=lf en .gitattributes, más git add --renormalize ..
Verifica con git ls-files --eol .husky y un commit y un push reales.

Referencias

La fecha sale un día antes en JavaScript: toISOString

2026-10-13T15:00:00.000-05:00

Guardas o muestras una fecha en JavaScript y el día sale equivocado: una venta registrada a las 19:17 aparece con la fecha de mañana, o un <input type="date"> guarda el día anterior al que elegiste. En una máquina con zona horaria UTC-5 puedes reproducirlo así:

new Date('2026-08-18T19:17:00-05:00').toISOString().slice(0, 10)
// '2026-08-19'  (se esperaba '2026-08-18')

new Date('2026-07-09').getDate()
// 8             (se esperaba 9)

Le pasa a quien tiene usuarios en una zona horaria distinta de UTC y mezcla toISOString(), new Date('YYYY-MM-DD') y getters locales como getDate(). Aquí verás la causa exacta y una forma de manejar fechas que no depende de la zona horaria del servidor.

Por qué pasa

Intervienen dos reglas de JavaScript que parecen inofensivas por separado:

toISOString() siempre devuelve la hora en UTC. MDN lo resume así: la zona horaria es siempre UTC, indicada por el sufijo Z.
Un string de solo fecha (YYYY-MM-DD) se interpreta como medianoche UTC, mientras que un string con fecha y hora sin desfase (2019-01-01T00:00:00) se interpreta en la zona local. Esa diferencia está documentada en la página de Date.parse() de MDN.

En UTC-5, las 19:00 locales son las 00:00 UTC del día siguiente. Por eso una venta de las 19:17 sale con la fecha de mañana si la formateas con toISOString(). Y al revés: new Date('2026-07-09') es el 9 de julio a las 00:00 UTC, que en tu zona local es el 8 de julio a las 19:00. Si luego lees el día con getDate() o toLocaleDateString(), obtienes el 8.

En zonas al este de UTC ocurre lo contrario: las horas de la madrugada local caen en el día anterior de UTC. Y en un servidor configurado en UTC no verás el problema, que es justo lo que lo hace tan fácil de pasar por alto: funciona en el servidor y falla en el navegador del usuario (o al revés).

Solución

Primero distingue qué tipo de valor tienes, porque se tratan distinto:

Instante: un momento exacto (la hora de una venta, un createdAt). Se debe formatear en la zona horaria del negocio o del usuario.
Fecha pura: un día de calendario sin hora (un cumpleaños, una fecha de vencimiento, el valor de un <input type="date">). No debería pasar por UTC.

Instantes: formatea en una zona explícita. Con date-fns-tz (instala date-fns y date-fns-tz):

import { formatInTimeZone } from 'date-fns-tz';

const TZ = 'America/Bogota'; // zona de ejemplo con UTC-5

export function fechaLocal(instante: Date, tz: string = TZ): string {
  return formatInTimeZone(instante, tz, 'yyyy-MM-dd');
}

fechaLocal(new Date('2026-08-19T00:17:00Z')); // '2026-08-18'

Sin dependencias, Intl.DateTimeFormat con la configuración regional en-CA produce el formato año-mes-día:

new Intl.DateTimeFormat('en-CA', { timeZone: 'America/Bogota' })
  .format(new Date('2026-08-19T00:17:00Z')); // '2026-08-18'

Ese formato depende de los datos de localización del entorno, así que protege esta función con un test (paso 4).

Fechas puras: no las conviertas a UTC. Lo más seguro es conservar el string YYYY-MM-DD tal cual, tanto en el formulario como al enviarlo a la API. Si necesitas un objeto Date, créalo con los componentes, que se interpretan en hora local (y el mes empieza en 0):
```
const [y, m, d] = '2026-07-09'.split('-').map(Number);
const fecha = new Date(y, m - 1, d); // 9 de julio, medianoche local
fecha.getDate(); // 9
```
Si ya tienes fechas puras guardadas como medianoche UTC, no las recalcules: muéstralas indicando la zona UTC.
```
formatInTimeZone(new Date('2026-07-09'), 'UTC', 'yyyy-MM-dd'); // '2026-07-09'
```

Rangos por día: convierte los extremos desde la zona del negocio. fromZonedTime interpreta un string sin zona como hora local de la zona indicada y devuelve el instante UTC equivalente:

import { fromZonedTime } from 'date-fns-tz';

export function rangoDelDia(fecha: string, tz: string = TZ) {
  return {
    desde: fromZonedTime(`${fecha}T00:00:00`, tz),
    hasta: fromZonedTime(`${fecha}T23:59:59.999`, tz),
  };
}

rangoDelDia('2026-08-18');
// desde: 2026-08-18T05:00:00.000Z
// hasta: 2026-08-19T04:59:59.999Z

Con ese rango, una consulta por día incluye las ventas de las 19:17 en lugar de moverlas al día siguiente.

Agrega un test con una hora entre las 19:00 y las 23:59. Es el caso que rompe el código ingenuo. Como la función recibe la zona de forma explícita, el test no depende de la configuración de la máquina:

import { describe, expect, it } from 'vitest';
import { fechaLocal } from './fecha';

describe('fechaLocal', () => {
  it('no adelanta el día entre las 19:00 y las 23:59 (UTC-5)', () => {
    expect(fechaLocal(new Date('2026-08-19T00:17:00Z'))).toBe('2026-08-18');
  });

  it('a la medianoche local ya es el día siguiente', () => {
    expect(fechaLocal(new Date('2026-08-19T05:00:00Z'))).toBe('2026-08-19');
  });
});

Cómo verificar que quedó resuelto

Ejecuta la suite de tests: los dos casos de arriba deben pasar (2026-08-19T00:17Z debe dar 2026-08-18).
Compara ambos enfoques en una consola Node.js. En una máquina en UTC-5 verás: toISOString().slice(0, 10) da 2026-08-19, mientras que fechaLocal(...) da 2026-08-18.
Prueba el flujo completo con una venta creada entre las 19:00 y las 23:59: la fecha en pantalla, en la exportación a Excel o PDF y en el filtro por día debe ser la misma.
Elige una fecha en el <input type="date">, guárdala, recarga y comprueba que sigue siendo el mismo día.

Variantes y errores relacionados

Agregar "T00:00:00" cambia el significado del string

new Date('2026-07-09') es UTC, pero new Date('2026-07-09T00:00:00') es hora local. Según la zona, la diferencia entre ambos es de varias horas (5 horas en UTC-5). No lo uses como parche sin saber cuál de los dos necesitas.

Funciones del paquete con nombres antiguos

Si encuentras ejemplos con zonedTimeToUtc o utcToZonedTime, son los nombres anteriores a la versión 3 de date-fns-tz: pasaron a llamarse fromZonedTime y toZonedTime, según las notas de la versión 3.0.0.

Si prefieres no depender de `en-CA`

function fechaISO(instante: Date, timeZone: string): string {
  const partes = new Intl.DateTimeFormat('en-US', {
    timeZone, year: 'numeric', month: '2-digit', day: '2-digit',
  }).formatToParts(instante);
  const valor = (tipo: string) => partes.find((p) => p.type === tipo)!.value;
  return `${valor('year')}-${valor('month')}-${valor('day')}`;
}

No mezcles los dos tipos de valor

Una fecha pura que se guardó como medianoche UTC y luego se convierte a la zona local retrocede un día. Decide desde el modelo de datos si cada campo es un instante o una fecha pura, y mantén esa decisión de punta a punta: formulario, API, base de datos y exportaciones.

Resumen

toISOString() formatea siempre en UTC, y new Date('YYYY-MM-DD') es medianoche UTC; en UTC-5 eso cambia el día a las 19:00 locales.
Para instantes, formatea con una zona explícita: formatInTimeZone o Intl.DateTimeFormat con timeZone.
Para fechas puras, conserva el string YYYY-MM-DD o crea el Date con new Date(y, m - 1, d).
Para rangos por día, usa fromZonedTime desde T00:00:00 hasta T23:59:59.999.
Cubre el caso con un test entre las 19:00 y las 23:59.

Referencias

JavaScript heap out of memory en next build: solución

2026-10-13T09:00:00.000-05:00

Tu proyecto compila sin problemas en tu máquina, pero en Docker, en GitHub Actions o en un hook de Git el proceso se corta con este mensaje:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Suele aparecer durante el paso "Running TypeScript ..." de next build o al ejecutar tsc --noEmit. Este artículo explica por qué ocurre y cómo subir el límite de memoria de Node.js en los tres lugares donde normalmente falta: el Dockerfile, el pipeline de CI y el hook pre-push.

Por qué pasa

Node.js ejecuta tu código sobre el motor V8, que limita la memoria que puede usar el heap de JavaScript. Según la documentación de Node.js, ese límite es el que determinan los recursos del sistema o, si lo indicas, el valor de --max-old-space-size. Dicho de otra forma: el límite por defecto no es el mismo en todas partes.

En tu equipo, con bastante RAM, el límite por defecto es mayor y el build pasa.
En un contenedor o en un runner de CI con menos memoria, el límite por defecto es menor.
Cuando el proyecto crece, la comprobación de tipos y el empaquetado necesitan más memoria. La guía de Next.js indica que la verificación de tipos puede requerir mucha memoria en proyectos grandes.

Mientras el proyecto y el entorno no cambien, el resultado se repite, así que reintentar el job normalmente no sirve. Tampoco suele ser un error de tu código: el proyecto simplemente superó el límite. Si el consumo de memoria crece sin control entre versiones, entonces conviene perfilarlo, pero eso es un problema distinto.

Solución

La opción de V8 que lo resuelve es --max-old-space-size (en MiB). Node.js permite pasarla en la variable de entorno NODE_OPTIONS, y como las variables de entorno las heredan los procesos hijos, el valor llega también a los workers de next build y a tsc.

Elige un valor acorde con la RAM real. Empieza con 4096 (4 GiB) y sube a 6144 solo si hace falta y la máquina lo soporta. Deja margen para el sistema y otros procesos; la propia documentación de Node.js sugiere, para una máquina de 2 GiB, usar 1536 para evitar el swap.
Dockerfile (etapa de build). Define la variable justo antes del comando de build con la instrucción ENV:
```
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
ENV NODE_OPTIONS=--max-old-space-size=4096
RUN npm run build
```
Como cada FROM empieza desde cero, la variable no pasa a la etapa final a menos que esa etapa parta de builder. Para un build no hace falta que esté en la imagen final.

GitHub Actions. Declara la variable en el env del job para que la reciban todos los pasos (lint, tipos, tests y build):

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      NODE_OPTIONS: --max-old-space-size=4096
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npm test
      - run: npm run build

Hook pre-push (por ejemplo con Husky). Exporta la variable con un valor por defecto, de modo que cada persona pueda sobrescribirlo desde su entorno:
```
# .husky/pre-push
export NODE_OPTIONS="${NODE_OPTIONS:---max-old-space-size=4096}"
npm run lint && npx tsc --noEmit && npm run build
```
La expresión ${NODE_OPTIONS:-valor} usa el valor solo si la variable no está definida o está vacía. Si ya tienes NODE_OPTIONS con otras opciones, el hook no añade nada; en ese caso incluye la opción en tu propio valor.
Prueba local en PowerShell para confirmar que el cambio hace efecto antes de subirlo:
```
$env:NODE_OPTIONS = "--max-old-space-size=4096"
npm run build
```

Cómo verificar que quedó resuelto

Primero comprueba que el límite realmente cambió. Este comando imprime el límite del heap en MiB:

NODE_OPTIONS=--max-old-space-size=4096 node -e "console.log(Math.round(require('v8').getHeapStatistics().heap_size_limit / 1048576))"

La documentación del módulo v8 define heap_size_limit como el tamaño máximo del heap, ya sea el límite por defecto o el valor de --max_old_space_size. El número impreso será algo mayor que 4096 (en una prueba con Node.js 24 salió 4288), así que lo importante es que cambie respecto al valor sin la variable.

Para la imagen de Docker, construye solo la etapa de build y revisa la variable:

docker build --target builder -t mi-app-builder .
docker run --rm mi-app-builder printenv NODE_OPTIONS

Debe imprimir --max-old-space-size=4096. Después comprueba lo importante: que el job de CI termine en verde con todos los pasos (lint, tipos, tests y build), que git push pase el hook completo y que el build ya no muestre el FATAL ERROR.

Variantes y errores relacionados

Un valor demasiado alto empeora todo

El valor de --max-old-space-size es solo un tope: no crea memoria que la máquina no tenga. Si lo subes por encima de la RAM disponible, el sistema empieza a usar swap y el build puede quedarse prácticamente colgado. En un caso real, usar 8192 en una máquina de 7,4 GB de RAM llevó a swap y a un cuelgue de unos 25 minutos. En contenedores con límite de memoria, el kernel de Linux puede terminar procesos cuando falta memoria (lo describe la documentación de Docker sobre OOME), y entonces el síntoma es otro: el proceso desaparece sin el mensaje de V8.

No desactives la comprobación de tipos para "arreglarlo"

La guía de Next.js menciona que puedes saltarte el chequeo de tipos del build con typescript.ignoreBuildErrors, pero advierte que puede producir despliegues defectuosos. Es mejor dar más memoria y mantener el chequeo.

Otras formas de reducir el consumo en Next.js

La misma guía documenta opciones como experimental.webpackMemoryOptimizations (disponible desde la 15.0.0, experimental y pensada para Webpack) y desactivar la generación de source maps en producción. Úsalas como complemento, no como sustituto de un límite adecuado.

El CI estaba rojo y nadie lo notó

Un patrón frecuente: el workflow de pruebas y build falla, pero el despliegue vive en otro workflow que sí pasa, así que el error pasa desapercibido durante varios merges. Revisa todos los workflows del repositorio, no solo el que despliega.

Resumen

El error indica que el proceso alcanzó el límite del heap de V8, que depende del entorno; por eso falla en CI y en Docker aunque en local pase.
Define NODE_OPTIONS=--max-old-space-size=4096 (o 6144) en el Dockerfile, en el env del job de CI y en el hook pre-push.
Ajusta el valor a la RAM real: un número mayor que la memoria física causa swap y cuelgues.
Verifica con heap_size_limit y con un pipeline completo en verde, sin desactivar la comprobación de tipos.
Vigila todos los workflows para que un CI en rojo no pase inadvertido.

Referencias

Could not get lock /var/lib/dpkg/lock-frontend: solución

2026-10-12T15:00:00.000-05:00

Lanzas por SSH un script de instalación largo en un servidor Ubuntu 24.04 (Docker, swap, dependencias). A mitad de camino se corta la conexión, vuelves a entrar, ejecutas de nuevo el script y falla al primer apt-get:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

El mensaje no habla de un fallo: dice que otro proceso tiene el candado del gestor de paquetes. Este artículo explica cómo averiguar cuál es, qué hacer con él sin dañar el sistema y cómo lanzar trabajos largos para que no dependan de tu terminal. Los comandos se contrastaron con los manuales de apt, dpkg y systemd, y con la documentación de Ubuntu Server; no se ejecutaron sobre un servidor.

Por qué pasa

El gestor de paquetes permite que un solo proceso modifique la base de datos de paquetes a la vez, y lo garantiza con archivos de bloqueo como /var/lib/dpkg/lock-frontend. Cuando el candado está en uso, el segundo proceso se niega a continuar e indica el PID y el nombre del que lo tiene (aquí, apt-get).

Si la sesión SSH se corta a mitad de una instalación, desaparece el terminal, pero eso no garantiza que terminen todos los procesos que lanzó el script. Un apt-get o un dpkg que ya estaba en marcha puede seguir trabajando sin que nadie lo mire, y mientras lo haga conserva el candado. Es la razón por la que el segundo intento falla: el primero todavía no terminó.

También puede ser otro proceso del sistema. La documentación de Ubuntu Server explica que unattended-upgrades puede ejecutarse al arrancar la máquina y, mientras trabaja, impide otras operaciones de paquetes: si necesitas instalar algo, debe esperar a que terminen las actualizaciones. Es frecuente en un servidor recién creado.

La advertencia del propio mensaje lo resume: borrar el archivo de bloqueo no es la solución y puede dañar el sistema.

Solución

Identifica el proceso que tiene el candado. El mensaje ya da el PID. Con él y con las herramientas del sistema:
```
ps -p 1234 -o pid,etime,cmd
sudo fuser -v /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock-frontend
ps -ef | grep -E 'apt|dpkg'
```
ps -p muestra el comando completo y el tiempo que lleva en marcha (etime). fuser -v lista los procesos que usan el archivo, en formato parecido a ps; lsof hace algo equivalente, usa el que tengas instalado. La última línea busca cualquier proceso de apt o dpkg (verás también la propia línea de grep).
Comprueba si avanza. Mira el registro de dpkg y el registro de tu script:
```
sudo tail -f /var/log/dpkg.log
tail -f instalar.log
```
Si aparecen líneas nuevas (paquetes que se descomprimen, se configuran), el proceso sigue trabajando.
Si avanza, espera a que termine. Este bucle se detiene cuando nadie usa el archivo (fuser devuelve un código distinto de cero si ningún proceso accede a él):
```
while sudo fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do sleep 5; done; echo "candado libre"
```
Después vuelve a lanzar el script. Antes, comprueba que se pueda repetir sin efectos secundarios: instalar un paquete ya instalado no cambia nada, pero crear un archivo de swap o agregar una línea a /etc/fstab por segunda vez sí puede.
Si lleva mucho tiempo sin avanzar, deténlo con cuidado. Pide primero una terminación normal y espera:
```
sudo kill 1234
```
Evita la señal SIGKILL (kill -9) salvo como último recurso: puede dejar paquetes a medio instalar. Si el proceso se interrumpió, repara el estado de dpkg antes de seguir:
```
sudo dpkg --configure -a
sudo apt-get install -f
```
Según el manual de dpkg, --configure -a configura todos los paquetes desempaquetados pero sin configurar. La opción -f (--fix-broken) de apt-get intenta corregir un sistema con dependencias rotas.
No borres los archivos de bloqueo (rm /var/lib/dpkg/lock-frontend y similares). El mensaje de apt lo desaconseja de forma explícita, y el candado lo tiene un proceso vivo, no el archivo.
Lanza los trabajos largos desacoplados de tu terminal. Tres opciones, de menos a más robusta:
```
# 1. En una sesión nueva, sin terminal asociado
sudo setsid -f bash ./instalar.sh > instalar.log 2>&1 < /dev/null
tail -f instalar.log

# 2. Dentro de tmux: puedes desconectarte y volver
tmux new -s instalacion
bash ./instalar.sh
# Ctrl+b d para desacoplar; después: tmux attach -t instalacion

# 3. Como servicio transitorio de systemd
sudo systemd-run --unit=instalacion /bin/bash /ruta/instalar.sh
journalctl -u instalacion -f
```
El manual de setsid indica que ejecuta un programa en una sesión nueva (y -f obliga a crear un proceso nuevo, de modo que el comando devuelve el control enseguida). Lanza el script con sudo desde el principio: sin terminal no podrás responder a una petición de contraseña a mitad del trabajo. En tmux, new -s crea una sesión con nombre y attach -t se conecta a ella; la tecla para desacoplar por defecto es Ctrl+b seguida de d. Con systemd-run, el comando corre como un servicio gestionado por systemd, en un entorno limpio y separado, con el gestor de servicios como proceso padre.
Si el trabajo debe sobrevivir a un reinicio, crea un servicio. Archivo /etc/systemd/system/instalacion.service:
```
[Unit]
Description=Instalacion inicial del servidor
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/bin/bash /opt/instalador/instalar.sh
RemainAfterExit=yes
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target
```
```
sudo systemctl daemon-reload
sudo systemctl enable instalacion.service
sudo systemctl start --no-block instalacion.service
```
En Type=oneshot, el tiempo de espera de arranque está desactivado por defecto, así que una instalación larga no se corta por duración. Restart=on-failure está permitido para este tipo (el manual rechaza always y on-success) y relanza el script si termina con error, por lo que el script debe poder repetirse sin efectos secundarios. RemainAfterExit=yes mantiene el servicio como activo cuando el script termina bien. enable lo habilita para los próximos arranques. Sin --no-block, systemctl start espera a que el arranque de la unidad se complete, y en un servicio oneshot eso ocurre cuando el script termina; con la opción, solo encola el trabajo y te devuelve la consola.

Cómo verificar que quedó resuelto

sudo fuser -v /var/lib/dpkg/lock-frontend
echo $?
sudo dpkg --audit

Si nadie usa el archivo, fuser no imprime procesos y el código de salida es distinto de cero. dpkg --audit busca paquetes instalados solo en parte o con datos de control dañados; no debe listar nada. Si lanzaste el trabajo con setsid, tmux o systemd-run, cierra la sesión SSH, vuelve a entrar y comprueba que el registro (instalar.log o journalctl -u instalacion) sigue creciendo.

Variantes y errores relacionados

Otros archivos de bloqueo

El mismo error puede nombrar /var/lib/dpkg/lock o /var/lib/apt/lists/lock. El procedimiento es idéntico: el mensaje indica el proceso que lo tiene.

Lo tiene unattended-upgrades

Si el proceso es de actualizaciones automáticas, lo correcto es esperar. Según la documentación de Ubuntu, esas actualizaciones las lanzan los temporizadores apt-daily.timer y apt-daily-upgrade.timer, y sus registros están en /var/log/unattended-upgrades.

apt pide ejecutar `dpkg --configure -a`

Suele indicar que una instalación anterior se interrumpió. Ejecuta el comando como se indica en el paso 4 y repite después la instalación.

Dos instaladores a la vez

Si lanzaste el trabajo como servicio y además a mano, el segundo chocará con el candado del primero. Elige un solo mecanismo y revisa con systemctl status instalacion si ya está en marcha.

Resumen

El error significa que un proceso vivo (por ejemplo, el apt-get de la primera ejecución) tiene el candado de dpkg; no es un archivo corrupto.
Identifícalo con el PID del mensaje, ps y fuser -v; si avanza, espera; si está atascado, termínalo con kill y ejecuta sudo dpkg --configure -a.
No borres los archivos de bloqueo: el propio apt advierte que puede dañar el sistema.
Lanza instalaciones largas con setsid -f, tmux o systemd-run, con el registro en un archivo.
Si debe sobrevivir a reinicios, usa un servicio Type=oneshot con Restart=on-failure y un script que se pueda repetir.

Referencias

tar: Cannot change ownership to uid: Invalid argument

2026-10-12T09:00:00.000-05:00

Subes un proyecto desde Git Bash (Windows) a un servidor Linux empaquetándolo con tar y enviándolo por SSH:

tar cf - . | ssh usuario@servidor "tar xf - -C /destino"

La transferencia termina, pero el tar del servidor imprime una avalancha de líneas como estas:

tar: ./archivo: Cannot change ownership to uid 197610, gid 197121: Invalid argument
tar: ./otro-archivo: Cannot change ownership to uid 197610, gid 197121: Operation not permitted
tar: Exiting with failure status due to previous errors

Este artículo explica de dónde salen esos números, por qué el servidor intenta usarlos y cómo evitar el error. Los pasos de creación y listado del archivo se reprodujeron con GNU tar 1.35 de Git Bash en un directorio temporal; el error en sí ocurre en el servidor y no se reprodujo (no se usó ningún servidor), así que esa parte se apoya en el manual de GNU tar y en la documentación de Linux.

Por qué pasa

Un archivo tar guarda, para cada entrada, el propietario y el grupo del archivo original. Puedes verlo con tar tvf:

tar tvf proyecto.tar
tar --numeric-owner -tvf proyecto.tar

-rw-r--r-- usuario/197121     18 2026-01-15 10:30 ./package.json
-rw-r--r-- 197610/197121      18 2026-01-15 10:30 ./package.json

(Salida de ejemplo: la primera línea es el listado normal, con el nombre del propietario y el número de grupo; la segunda, el de --numeric-owner, con números.) En Git Bash tu cuenta de Windows se presenta con un uid y un gid numéricos altos; en la prueba, id -u devolvió un número de seis cifras. Esos números no corresponden a ninguna cuenta del servidor.

Al extraer, el manual de GNU tar indica que --same-owner (intentar extraer con el mismo propietario que figura en el archivo) es el comportamiento por defecto del superusuario, mientras que --no-same-owner (extraer como tú mismo) es el de los usuarios normales. Por eso el problema aparece cuando extraes como root: tar intenta ejecutar un chown a un uid y un gid que el servidor no conoce o no puede asignar.

Los dos mensajes del error indican cosas distintas:

Operation not permitted: el proceso no tiene privilegio para cambiar el propietario. Según chown(2), solo un proceso privilegiado (en Linux, con la capacidad CAP_CHOWN) puede cambiar el propietario de un archivo.
Invalid argument: el sistema rechaza el número como propietario. Suele verse cuando el destino no puede representar ese id, por ejemplo en un contenedor o un espacio de nombres de usuario con un rango limitado: user_namespaces(7) explica que cada espacio de nombres solo conoce los ids que tiene asignados y que los demás se tratan como no asignados.

El error no dice que el archivo esté dañado, solo que no se pudo asignar el propietario. Pero tar termina con estado de fallo (el manual define el código 2 como error fatal), lo que puede cortar un script que encadene comandos con && o use set -e.

Solución

Extrae sin conservar el propietario del archivo. Añade --no-same-owner al tar del servidor:
```
tar cf - . | ssh usuario@servidor "mkdir -p /destino && tar xf - --no-same-owner -C /destino"
```
Los archivos quedan a nombre del usuario que ejecuta la extracción. Si la aplicación corre con otra cuenta, ajusta después el propietario con chown -R cuenta:grupo /destino.
Alternativa: crea el archivo con propietario neutro. Con --owner, --group y --numeric-owner el archivo registra el uid 0 y el gid 0 en lugar de los de Windows:
```
tar --owner=0 --group=0 --numeric-owner -cf - . | ssh usuario@servidor "mkdir -p /destino && tar xf - -C /destino"
```
En la prueba, el listado con tar tvf mostró 0/0 en todas las entradas. Si el servidor extrae como root, los archivos quedarán a nombre de root; si lo hace un usuario normal, a nombre de ese usuario. Elige esta opción cuando quieras que el archivo sea portable y no solo arreglar el servidor.
Si también molestan los permisos, añade --no-same-permissions.
```
tar xf - --no-same-owner --no-same-permissions -C /destino
```
Según el manual, preservar los permisos del archivo es lo habitual para el superusuario; --no-same-permissions hace que se aplique la umask del usuario que extrae. Úsalo solo si lo necesitas: puede quitar bits que quieras conservar (por ejemplo, el de ejecución de un script). Revisa después con ls -l.
Comprueba que no falte ni cambie nada. Genera una lista de sumas de verificación fuera de la carpeta del proyecto, envíala al servidor y compárala:
```
find . -type f -exec sha256sum {} + > ../manifiesto.sha256
scp ../manifiesto.sha256 usuario@servidor:/tmp/manifiesto.sha256
ssh usuario@servidor "cd /destino && sha256sum -c /tmp/manifiesto.sha256"
```
Cada archivo debe mostrar OK. No guardes el manifiesto dentro del proyecto (por eso va en ..): así no se incluye a sí mismo en la lista ni en el envío.

Cómo verificar que quedó resuelto

Ejecuta de nuevo el comando de la solución y comprueba tres cosas:

echo "${PIPESTATUS[@]}"
ssh usuario@servidor "ls -ln /destino | head"

El primer comando se ejecuta en Git Bash justo después de la tubería y debe mostrar 0 0: el primer valor es el de tar local y el segundo el de ssh, que según su manual termina con el estado del comando remoto. El segundo comando muestra los propietarios numéricos: deben ser ids que existan en el servidor, no el de Windows. Por último, sha256sum -c debe dar OK en todos los archivos.

Variantes y errores relacionados

Solo fallan algunos archivos con `Operation not permitted`

Es la misma causa: tar intentó cambiar el propietario sin el privilegio necesario. La solución es la misma, --no-same-owner, en lugar de dar más privilegios al proceso.

En PowerShell, `tar` no es GNU tar

Las opciones de este artículo son de GNU tar (Git Bash y el servidor Linux). En una consola de PowerShell, tar suele ser el bsdtar que trae Windows (tar --version muestra bsdtar y la versión de libarchive), con opciones distintas; la ayuda que imprime no lista --owner ni --group. Ejecuta el comando de creación desde Git Bash.

El error sale en un contenedor o en un disco montado

Si extraes dentro de un contenedor o sobre un sistema de archivos que no admite propietarios arbitrarios, --no-same-owner también es la salida. Si de verdad necesitas conservar los propietarios, el servidor debe tener esos ids disponibles, y ese ya es un asunto de la configuración del contenedor o del montaje.

Resumen

El archivo de Git Bash guarda uid y gid numéricos altos de tu cuenta de Windows; el servidor no los conoce.
Como root, GNU tar conserva por defecto el propietario del archivo (--same-owner), y el chown falla con Invalid argument o Operation not permitted.
La solución directa es extraer con tar xf - --no-same-owner -C /destino.
También puedes crear el archivo con --owner=0 --group=0 --numeric-owner para que no lleve ids de Windows.
Aunque el error sea solo de propietarios, comprueba el resultado con sha256sum -c y revisa el estado de salida.

Referencias

Cómo las Tendencias en Twitter (Ahora X) Influencian el Desarrollo de Software y Aplicaciones

2026-10-11T16:20:25.921-05:00

Introducción:

Imagina un mundo donde lo que se dice en 280 caracteres o menos puede cambiar la forma en que interactuamos con nuestros dispositivos. Bueno, no necesitas imaginarlo: ese mundo es Twitter. Más que una simple plataforma de redes sociales, Twitter se ha convertido en un gigante influenciador, capaz de mover montañas en el mundo digital. O, en nuestro caso, capaz de influenciar el desarrollo de software y aplicaciones.

Twitter no es solo un lugar para compartir memes o discutir el episodio más reciente de tu serie favorita; es un hervidero de opiniones, ideas y, lo más importante, tendencias que reflejan lo que la gente realmente quiere y necesita. ¿Y adivina qué? Los desarrolladores de software y aplicaciones están prestando mucha atención. No es casualidad que las últimas actualizaciones de tu app favorita coincidan sorprendentemente con los temas más candentes en Twitter.

Así que, si alguna vez te has preguntado "¿Alguien más piensa que esta app podría mejorar?", probablemente alguien en Twitter ya lo haya expresado, y alguien en alguna parte del mundo del desarrollo de software lo esté considerando seriamente. Vamos a sumergirnos en cómo Twitter, el titán de los tweets, está marcando el compás en el baile del desarrollo de software y aplicaciones. ¿Listo para twittear el camino hacia la innovación tecnológica?

La Revolución Silenciosa: Cómo la Inteligencia Artificial Está Transformando Nuestra Vida Cotidiana

2023-11-30T20:24:00.001-05:00

Introducción:

Hola, ¡bienvenido a la era de los susurros tecnológicos! Aquí, en el tranquilo mundo de la Inteligencia Artificial (IA), donde las máquinas hablan en código y los algoritmos deciden qué café te gusta más. Sí, has leído bien. La IA no es solo una charla de nerds en una convención de ciencia ficción; es una realidad cotidiana, tan integrada en nuestras vidas que a veces ni siquiera nos damos cuenta. En este artículo, vamos a explorar (¡sin necesidad de un mapa del tesoro!) cómo la IA está cambiando silenciosamente todo, desde cómo bostezamos por la mañana hasta cómo nos deslizamos por nuestras redes sociales por la noche.

1. Asistentes Personales Inteligentes:

¿Alguna vez has deseado tener un asistente personal que no se queje de tus malos chistes? ¡Bueno, la IA te cubre! Siri, Alexa y Google Assistant son como los genios de las lámparas modernas (pero sin límite de tres deseos). Vamos a profundizar en cómo estos pequeños genios digitales están haciendo nuestras vidas un poco menos complicadas. Leer más.

2. Recomendaciones Personalizadas en Plataformas de Streaming:

¿Te has preguntado cómo Netflix sabe que te encantará esa serie rara de ciencia ficción? No, no es magia; es IA. Aquí te contaré sobre los algoritmos que conocen tus gustos mejor que tu mejor amigo. Leer más.

3. IA en el Comercio Electrónico:

De compras en pijama y aún así recibiendo recomendaciones personalizadas: exploraremos cómo la IA está transformando la forma en que compramos en línea, desde escoger el par de zapatos perfecto hasta encontrar esa oferta de último minuto. Leer más.

4. IA en Dispositivos Domésticos:

Nuestros hogares están más conectados que una red de chismes de vecindario, gracias a la IA. Descubre cómo la tecnología está haciendo que nuestras casas sean más inteligentes y por qué tal vez quieras agradecer a tu refrigerador la próxima vez que haga la lista de compras. Leer más.

5. Impacto en la Salud y Bienestar:

La IA no solo se trata de comodidad y entretenimiento; también está ayudando a mantenernos en forma y saludables. Desde aplicaciones que monitorean tu sueño hasta dispositivos que te recuerdan beber agua, la IA está aquí para cuidar de ti. Leer más.

Conclusión:

Entonces, ¿es la IA el futuro? ¡No! La IA es el presente, y está moldeando nuestro mundo de maneras que ni siquiera hemos empezado a comprender completamente. Pero no te preocupes, no estamos en una película de ciencia ficción apocalíptica... aún. Por ahora, disfrutemos de las maravillas de esta revolución silenciosa, siempre recordando usar la tecnología con sabiduría y un toque de humanidad.

Impacto de la IA en la Salud y el Bienestar: Tu Entrenador Personal en el Bolsillo

2023-11-30T20:22:00.001-05:00

Introducción:

¿Imaginas tener un entrenador personal que vive en tu smartphone y no te juzga por ese helado extra que comiste anoche? La Inteligencia Artificial (IA) está revolucionando el cuidado de la salud y el bienestar de formas que nunca imaginamos, ¡y no necesita que le pagues una membresía de gimnasio!

Tu Salud en Tus Manos (Literalmente):

Las aplicaciones impulsadas por IA están transformando nuestros teléfonos en centros de salud personalizados. ¿Quieres mejorar tu calidad de sueño? Hay una app que analiza tus patrones de sueño y te da consejos para dormir mejor. ¿Olvidas constantemente beber agua? No te preocupes, tu teléfono vibrará recordándote que es hora de hidratarte. Incluso hay aplicaciones que pueden ayudarte a meditar, reducir el estrés y hasta guiarte en ejercicios de respiración. ¡Adiós, estrés!

Un Vistazo al Futuro de la Salud:

Pero la IA no se detiene ahí. Está ayudando a los médicos a diagnosticar enfermedades con mayor precisión y rapidez, desde detectar anomalías en imágenes de rayos X hasta identificar síntomas de enfermedades raras. En el futuro, podríamos ver dispositivos aún más avanzados, como sensores que monitorean nuestra salud en tiempo real y nos avisan si algo anda mal. ¡Es como tener un doctor en tu bolsillo!

Conclusión:

La IA en el ámbito de la salud y el bienestar no es solo una tendencia pasajera; es una revolución que está aquí para quedarse. Con su ayuda, estamos aprendiendo a cuidar mejor de nosotros mismos y de nuestros seres queridos. Así que la próxima vez que tu reloj inteligente te diga que te muevas, ¡hazle caso! Podría ser el empujoncito que necesitas para llevar una vida más saludable. Y recuerda, ¡la IA está de tu lado!

IA en Dispositivos Domésticos: Hogares Inteligentes y sus Chismes Tecnológicos

2023-11-30T20:18:00.001-05:00

Introducción:

Imagina un mundo donde tu refrigerador critica tus elecciones de snacks nocturnos, o tu aspiradora tiene un mapa mental de cada rincón de tu sala. Bueno, no estamos lejos de eso. Con la Inteligencia Artificial (IA) infiltrándose en nuestros hogares, estamos viviendo en una versión menos dramática de una película de ciencia ficción. Vamos a zambullirnos en este mundo donde los dispositivos hablan, piensan (un poco) y, lo más importante, nos hacen la vida más fácil.

Los Chismosos de la Casa: Dispositivos Inteligentes:

Desde termostatos que aprenden tu rutina diaria hasta luces que cambian de color según tu estado de ánimo, la IA está convirtiendo nuestros hogares en algo sacado de una novela futurista. Y no es solo por diversión; hay una utilidad real aquí. Por ejemplo, esa cámara de seguridad que te avisa si un extraño ronda tu casa, o el asistente de voz que te recuerda comprar leche. ¿Quién necesita un mayordomo cuando tienes un ecosistema de gadgets inteligentes que se ocupan de todo?

Hablando con las Paredes: La Integración de IA:

La integración de IA en dispositivos domésticos no se trata solo de comodidad; es una revolución en cómo interactuamos con nuestro entorno. Ahora puedes hablarle a tu televisor para cambiar de canal o preguntarle a tu horno cómo cocinar el pollo perfecto. Y mientras que algunos podrían argumentar que nos estamos volviendo demasiado dependientes de estos dispositivos, la mayoría diría que es simplemente aprovechar lo que la tecnología tiene para ofrecer.

Conclusión: Agradeciendo a tus Electrodomésticos:

Así que la próxima vez que pases por tu nevera, tal vez quieras darle las gracias. Después de todo, está trabajando diligentemente para asegurarse de que nunca te falten tus snacks favoritos. La IA en los dispositivos domésticos no solo está haciendo nuestras casas más inteligentes, sino que también está agregando un toque de magia tecnológica a nuestras vidas cotidianas. Y quién sabe, tal vez en el futuro, incluso nuestros tostadores tendrán algo interesante que decir.

IA en el Comercio Electrónico: Tu Estilista Personal en Pijama

2023-11-30T20:11:00.003-05:00

Introducción:

¿Quién hubiera imaginado que comprar en pijama podía convertirse en una experiencia tan personalizada y sofisticada? Gracias a la inteligencia artificial (IA), el comercio electrónico ha evolucionado de ser solo una conveniencia a ser una experiencia casi mágica, donde cada clic te acerca más a lo que realmente quieres (¡o a lo que no sabías que querías hasta que lo viste!).

La Magia Detrás del Carrito de Compras:

Piénsalo: cada vez que buscas un nuevo par de zapatillas en línea, aparecen sugerencias que parecen leer tu mente. ¿Es telepatía? No, es IA. Utilizando datos de tus búsquedas anteriores, compras y hasta los artículos que abandonaste en el carrito, la IA configura un perfil de tus gustos y preferencias. Así, cada sugerencia es como un consejo de un amigo que conoce tus gustos a la perfección.

Más Que Solo Compras: Una Experiencia Personalizada:

En el mundo del e-commerce impulsado por IA, cada usuario recibe una experiencia de compra única. ¿Te gustan los estampados de leopardo? La IA lo recordará. ¿Prefieres las ofertas sobre las novedades? También lo sabrá. Esta tecnología no solo te muestra productos que podrían gustarte, sino que también adapta las ofertas y promociones según tus hábitos de compra. ¡Adiós, anuncios irrelevantes!

Un Futuro de Compras Inteligentes:

La IA está transformando no solo cómo compramos, sino también cómo se gestionan los inventarios y se predice la demanda. Imagina un futuro donde nunca haya un "agotado" en tu talla porque la IA ya predijo la demanda y ajustó el stock. O donde los precios fluctúen inteligentemente según las tendencias de mercado, maximizando tanto la satisfacción del cliente como el beneficio de la tienda.

Conclusión:

Comprar en línea ya no es solo hacer clic en un botón de compra. Es una experiencia personalizada, casi como tener un estilista personal que te conoce mejor que nadie (¡y todo esto mientras estás cómodamente en pijama!). La IA en el comercio electrónico no es solo una moda pasajera; es el futuro brillante y emocionante del shopping online. Así que la próxima vez que recibas una recomendación perfecta, recuerda: hay una IA trabajando para hacerte feliz.

Recomendaciones Personalizadas en Plataformas de Streaming: El Genio Detrás de la Pantalla

2023-11-30T20:05:00.002-05:00

Introducción:

¿Te ha sorprendido alguna vez esa sensación de que Netflix te conoce mejor que tu propia madre? Pues no estás solo. Resulta que detrás de esas recomendaciones, tan precisas que dan miedo, hay un cerebrito trabajando incansablemente: la inteligencia artificial. Y no, no se trata de un stalker digital, sino de algoritmos sofisticados que se han vuelto expertos en descifrar tus gustos y preferencias.

El Misterio de las Recomendaciones Personalizadas:

Imagina un chef que, sin preguntarte, prepara tu plato favorito cada vez que visitas su restaurante. Así funciona la IA en las plataformas de streaming. Estos algoritmos observan y aprenden de cada elección que haces: lo que miras, lo que te gusta, incluso lo que descartas después de 10 minutos. Basándose en estos datos, te presentan una bandeja llena de opciones personalizadas que probablemente te encantarán. Y lo mejor de todo es que, ¡no tienes que compartir tus palomitas de maíz con ellos!

Más Allá del "Me Gusta":

La IA en las plataformas de streaming va más allá de un simple "me gusta". Estos sistemas son como aquel amigo que te recomienda libros, pero a nivel experto. Analizan tendencias, calificaciones, e incluso se atreven a sugerirte algo fuera de tu zona de confort, como esa serie de documentales sobre insectos que, sorprendentemente, terminaste maratoneando un fin de semana.

El Humor y la Inteligencia Artificial:

Y lo que es más intrigante, estos sistemas aprenden con el tiempo. Empiezan entendiendo tus elecciones básicas y, poco a poco, se convierten en expertos de tus hábitos. ¿El resultado? Una experiencia de visualización tan personalizada que te sentirás como en una cita con tu alma gemela cinematográfica.

Conclusión:

En resumen, la próxima vez que te encuentres navegando por las recomendaciones de tu plataforma de streaming favorita, recuerda: no es magia, es inteligencia artificial. Estos algoritmos no solo conocen tus gustos, sino que también te desafían a explorar nuevos horizontes. Así que, ¡dale una oportunidad a esa sugerencia rara y disfruta del viaje que la IA ha preparado para ti!

Asistentes Personales Inteligentes: La Magia de la IA en Tu Bolsillo

2023-11-30T19:32:00.001-05:00

Introducción:

Imagina un mundo donde tienes un asistente personal que no solo es infalible sino que también soporta pacientemente tus bromas a altas horas de la madrugada. Ese mundo es ahora una realidad gracias a Siri, Alexa y Google Assistant. Estos asistentes virtuales, que han ido más allá de la mera tolerancia a nuestros chistes malos, están redefiniendo nuestra interacción cotidiana con la tecnología. Olvídate de frotar lámparas mágicas; estos genios digitales están listos para cumplir tus deseos con solo un comando de voz.

La Vida con Asistentes Personales Inteligentes:

La era de los asistentes personales inteligentes es una mezcla de comodidad y magia. Imagina despertar cada mañana con el aroma de un café recién hecho porque Alexa recordó encender tu cafetera inteligente. O qué tal cuando Siri te salva de un momento incómodo recordándote el nombre de alguien justo antes de una reunión. Y cuando se trata de evitar el tráfico, Google Assistant se convierte en tu copiloto personal, encontrando la ruta más rápida y segura a tu destino.

Más que Simples Ayudantes:

Pero la verdadera magia de estos asistentes va más allá de las tareas diarias. Son como amigos digitales que te conocen íntimamente. ¿Quieres relajarte? Alexa puede reproducir tu lista de reproducción de jazz favorita sin que tengas que pedírselo dos veces. ¿Necesitas un empujoncito para hacer ejercicio? Google Assistant te recordará amablemente tu rutina de ejercicios, y Siri puede incluso motivarte con un poco de humor. Son como esos amigos perfectos, siempre disponibles, nunca críticos y eternamente pacientes.

Conclusiones:

Los asistentes personales inteligentes son más que una maravilla tecnológica; son compañeros en nuestro viaje diario, facilitadores de una vida más fácil y entretenida. No solo están aquí para cumplir órdenes, sino para enriquecer nuestra vida diaria con su inteligencia y su toque personal. La próxima vez que interactúes con tu asistente de IA, recuerda que estás presenciando un milagro de la tecnología moderna: un genio en tu bolsillo, siempre listo para ayudarte con una sonrisa digital.

¿Cómo ha cambiado la tecnología nuestras vidas?

2023-05-21T00:00:00.001-05:00

La tecnología ha cambiado nuestras vidas de formas increíbles. ¿Te has detenido alguna vez a pensar en cómo ha cambiado la forma en que nos comunicamos, cómo aprendemos o incluso cómo cuidamos nuestra salud? En este artículo, vamos a explorar todo eso y más.

Primero, vamos a hablar sobre cómo la Transformación Digital ha cambiado la forma en que interactuamos con el mundo. Ya no necesitamos mapas de papel o enciclopedias pesadas. Todo lo que necesitamos está al alcance de nuestros dedos.

Luego, nos adentraremos en el mundo de la Tecnología y Salud. ¿Sabías que la tecnología está ayudando a los médicos a salvar vidas y a hacer que la atención médica sea más accesible para todos?

Después, hablaremos sobre la Tecnología en la Educación. Las aulas ya no están limitadas a cuatro paredes. Ahora, podemos aprender desde cualquier lugar, en cualquier momento.

Por último, pero no menos importante, discutiremos la Tecnología y el Medio Ambiente. Aunque la tecnología puede tener un impacto en nuestro planeta, también está ayudando a encontrar soluciones para un futuro más verde y sostenible.

Así que, si estás listo para un viaje emocionante a través de cómo la tecnología ha cambiado nuestras vidas, ¡sigue leyendo!

Transformación Digital: Un salto hacia el futuro

La revolución de la comunicación: De cartas a mensajes instantáneos

La Transformación Digital ha marcado un antes y un después en nuestra forma de interactuar con el mundo. Este salto hacia el futuro ha sido impulsado por la rápida evolución de la tecnología, que ha cambiado la forma en que trabajamos, aprendemos, nos comunicamos y, en general, vivimos nuestras vidas. La digitalización ha abierto un mundo de posibilidades, permitiéndonos acceder a información y servicios con solo unos pocos clics o toques en una pantalla. Ya no estamos limitados por la geografía o el tiempo. Podemos trabajar desde casa, aprender nuevas habilidades en línea, comprar productos de todo el mundo y conectarnos con personas en diferentes continentes.

Uno de los cambios más significativos ha sido la revolución en la comunicación. Piensa en cómo solíamos comunicarnos hace solo unas décadas. Las cartas escritas a mano eran la norma, y esperar días o incluso semanas para recibir una respuesta era común. Ahora, con la llegada de los mensajes instantáneos, podemos comunicarnos con cualquier persona, en cualquier lugar del mundo, en tiempo real. Las barreras de tiempo y espacio se han desvanecido, permitiéndonos mantenernos conectados con nuestros seres queridos, hacer negocios y compartir ideas de formas que nunca antes habíamos imaginado. La comunicación instantánea ha cambiado no solo cómo interactuamos, sino también nuestras expectativas de inmediatez y accesibilidad.

La era de la información: Conocimiento al alcance de un clic

La Transformación Digital ha propulsado a la humanidad hacia una nueva era: la era de la información. En este futuro digital, el conocimiento ya no está confinado a las bibliotecas o a las aulas de clase. Ahora, está literalmente al alcance de un clic. Internet, con su vasto océano de información, ha democratizado el acceso al conocimiento. Ya sea que quieras aprender una nueva habilidad, entender un concepto complejo, o simplemente satisfacer tu curiosidad, todo lo que necesitas es una conexión a internet y la voluntad de aprender.

Esta accesibilidad al conocimiento ha cambiado la forma en que aprendemos y nos desarrollamos. Las plataformas de aprendizaje en línea, los tutoriales en video, los blogs educativos y las aplicaciones de aprendizaje han hecho que la educación sea más flexible y personalizada. Ahora, puedes aprender a tu propio ritmo, en tu propio tiempo, y de la manera que mejor se adapte a tu estilo de aprendizaje. Además, la era de la información ha facilitado la colaboración y el intercambio de ideas, permitiendo a las personas de todo el mundo trabajar juntas para resolver problemas y generar nuevas ideas. En resumen, la Transformación Digital ha hecho que el conocimiento sea más accesible y valioso que nunca.

Tecnología y Salud: Salvando vidas con un chip

Telemedicina: Consultas médicas desde la comodidad de tu hogar

La intersección de la tecnología y la salud ha dado lugar a avances asombrosos que están cambiando la forma en que cuidamos nuestro bienestar. Uno de estos avances es la telemedicina, que ha transformado la forma en que interactuamos con los profesionales de la salud. Ya no necesitamos hacer largas colas en la sala de espera del consultorio del médico. Ahora, podemos tener consultas médicas desde la comodidad de nuestro hogar.

La telemedicina utiliza tecnologías de comunicación digital para facilitar las consultas médicas a distancia. Ya sea a través de una videollamada, un chat en línea o una aplicación móvil, los pacientes pueden comunicarse con los médicos, describir sus síntomas, recibir diagnósticos y obtener recetas médicas sin tener que salir de casa. Esto no solo es conveniente, sino que también es una bendición para aquellos que viven en áreas rurales o aisladas, donde el acceso a la atención médica puede ser limitado. Además, la telemedicina permite a los pacientes mantenerse en contacto con sus médicos para el seguimiento y la gestión de enfermedades crónicas. En resumen, la tecnología está haciendo que la atención médica sea más accesible y centrada en el paciente que nunca antes.

Innovaciones en cirugía: Robots en el quirófano

La tecnología ha revolucionado la forma en que se realizan las cirugías, y una de las innovaciones más emocionantes en este campo es el uso de robots en el quirófano. Aunque pueda sonar como ciencia ficción, los robots quirúrgicos son una realidad y están cambiando la forma en que se realizan las operaciones, mejorando la precisión y reduciendo los riesgos para los pacientes.

Los robots quirúrgicos, como el famoso sistema Da Vinci, permiten a los cirujanos realizar procedimientos complejos con una precisión y un control sin precedentes. Estos robots no realizan la cirugía por sí mismos, sino que son controlados por un cirujano que utiliza una consola para manipular los brazos del robot. Los robots pueden realizar movimientos más precisos y estables que la mano humana, lo que reduce el riesgo de errores. Además, los robots pueden acceder a áreas del cuerpo que serían difíciles o imposibles de alcanzar con las técnicas quirúrgicas tradicionales. Esto significa que las cirugías pueden ser menos invasivas, lo que a su vez puede llevar a una recuperación más rápida para los pacientes. En resumen, la tecnología está abriendo nuevas posibilidades en el campo de la cirugía, mejorando los resultados para los pacientes y facilitando el trabajo de los cirujanos.

El impacto de la tecnología en la educación

La tecnología ha revolucionado la educación, cambiando la forma en que los estudiantes interactúan con el conocimiento y cómo los maestros facilitan ese proceso. El aprendizaje ya no está limitado a las aulas físicas. Con la ayuda de la tecnología, la educación se ha vuelto más accesible y personalizada, adaptándose a las necesidades individuales de cada estudiante.

Aprendizaje online: La escuela en tu sala de estar

El aprendizaje online ha sido una de las transformaciones más significativas en el campo educativo. Esta modalidad ha permitido que la educación trascienda las barreras geográficas y temporales. Ahora, cualquier persona con acceso a internet puede aprender desde la comodidad de su hogar, a su propio ritmo. Los estudiantes pueden acceder a una amplia variedad de cursos y programas ofrecidos por instituciones de todo el mundo.

Además, el aprendizaje online fomenta la autodisciplina y la autogestión, habilidades esenciales en el mundo actual. Ya sea que estés buscando adquirir una nueva habilidad, mejorar tu conocimiento en un área específica o incluso obtener un título, el aprendizaje online ofrece una solución flexible y accesible.

En resumen, la tecnología ha convertido nuestras salas de estar en aulas, abriendo un mundo de oportunidades para aprender y crecer.

Tecnología en el aula: Mejorando la experiencia de aprendizaje

La incorporación de la tecnología en el aula ha mejorado significativamente la experiencia de aprendizaje.

Las herramientas digitales como las pizarras interactivas, las tabletas y los programas educativos han hecho que las lecciones sean más atractivas y participativas. Los estudiantes ya no son meros receptores de información, sino participantes activos en su propio proceso de aprendizaje. La tecnología también ha permitido la personalización del aprendizaje, donde los maestros pueden adaptar las lecciones a las necesidades y habilidades individuales de cada estudiante.

Además, la tecnología ha facilitado la evaluación y el seguimiento del progreso del estudiante, proporcionando a los maestros información valiosa para mejorar su enseñanza.

En resumen, la tecnología en el aula ha mejorado la eficacia de la enseñanza y ha enriquecido la experiencia de aprendizaje, preparando a los estudiantes para un mundo cada vez más digital.

La tecnología y el medio ambiente: Un arma de doble filo

La tecnología tiene un impacto significativo en nuestro medio ambiente, y no siempre es positivo. Por un lado, la tecnología ha permitido avances increíbles en áreas como la eficiencia energética y la conservación de recursos. Pero por otro lado, también ha contribuido a problemas ambientales serios, como la contaminación y el agotamiento de recursos naturales. Sin embargo, hay un área en la que la tecnología está haciendo una diferencia positiva y esa es la energía renovable.

Energías renovables: El poder del sol y el viento

Las energías renovables, como la solar y la eólica, están cambiando la forma en que generamos y consumimos energía. Gracias a la tecnología, ahora podemos aprovechar el poder del sol y el viento para generar electricidad de una manera que es amigable con el medio ambiente y sostenible a largo plazo.

Los paneles solares y las turbinas eólicas son cada vez más eficientes y asequibles, lo que hace que la energía renovable sea una opción viable para más y más personas. Además, la tecnología también está ayudando a mejorar la forma en que almacenamos y distribuimos esta energía, lo que nos acerca cada vez más a un futuro de energía limpia y renovable.

En resumen, la tecnología está jugando un papel crucial en la lucha contra el cambio climático y la protección de nuestro planeta para las generaciones futuras.

Tecnología verde: Innovaciones para un planeta más limpio

La tecnología verde es un término amplio que abarca una variedad de innovaciones y prácticas diseñadas para reducir nuestro impacto en el medio ambiente. Estas tecnologías buscan minimizar la contaminación, reducir el desperdicio, y promover la eficiencia energética. Desde vehículos eléctricos hasta edificios ecológicos, la tecnología verde está cambiando la forma en que vivimos y trabajamos.

Los vehículos eléctricos, por ejemplo, están revolucionando la industria del transporte. Al eliminar la necesidad de combustibles fósiles, estos vehículos reducen significativamente las emisiones de gases de efecto invernadero. Además, la tecnología de las baterías está avanzando rápidamente, lo que significa que los vehículos eléctricos son cada vez más eficientes y asequibles.

En el ámbito de la construcción, los edificios ecológicos están cambiando la forma en que pensamos sobre el diseño y la construcción. Estos edificios utilizan materiales sostenibles, maximizan la eficiencia energética, y a menudo incorporan sistemas de energía renovable. Además, muchos edificios ecológicos están diseñados para minimizar el desperdicio de agua y promover la calidad del aire interior.

En resumen, la tecnología verde está ayudando a crear un futuro más sostenible y ecológico. A través de la innovación y la adopción de estas tecnologías, podemos reducir nuestro impacto en el medio ambiente y crear un planeta más limpio para las generaciones futuras.

Conclusiones

En conclusión, la tecnología ha tenido un impacto profundo y transformador en nuestras vidas, cambiando la forma en que nos comunicamos, accedemos a la información, cuidamos nuestra salud, aprendemos y cuidamos nuestro planeta.

La transformación digital ha revolucionado la comunicación, permitiéndonos conectar con personas de todo el mundo en tiempo real. La era de la información ha democratizado el acceso al conocimiento, poniendo una cantidad casi infinita de información al alcance de un clic. En el ámbito de la salud, la tecnología ha permitido avances asombrosos, desde la telemedicina hasta la cirugía robótica. En educación, la tecnología ha abierto nuevas vías de aprendizaje y ha mejorado la experiencia en el aula. Y en términos de medio ambiente, la tecnología verde está ayudando a crear un futuro más sostenible.

Sin embargo, es importante recordar que la tecnología es una herramienta, y su impacto depende de cómo la usemos. Debemos esforzarnos por utilizar la tecnología de manera responsable y ética, y trabajar para garantizar que sus beneficios sean accesibles para todos. En última instancia, la tecnología tiene el potencial de mejorar nuestras vidas y nuestro mundo, pero depende de nosotros hacer que ese potencial se convierta en realidad.

Nos encantaría saber tu opinión sobre este artículo en los comentarios. ¿Te ha parecido útil? ¿Hay algún otro tema relacionado con la tecnología que te gustaría que exploráramos en Tutoriales Técnicos? Tu feedback es muy valioso para nosotros y nos ayuda a crear contenido que sea relevante y útil para ti. Así que no dudes en compartir tus pensamientos y sugerencias para futuros artículos. ¡Estamos ansiosos por leer tus comentarios!

PD: Comparte este artículo con todos tus contactos.

Tutoriales Técnicos

sqlite3.OperationalError: database is locked: solución

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

database table is locked

ProgrammingError: SQLite objects created in a thread can only be used in that same thread

La base está en un volumen de red

Transacciones implícitas del módulo sqlite3

Resumen

Referencias

NestJS: property should not exist (forbidNonWhitelisted)

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

Solo whitelist: true

No aparece el detalle del error

Las pruebas e2e pasan pero producción falla

El DTO de actualización no deriva del de creación

Resumen

Referencias

useEffect borra el estado: dependencia con referencia nueva

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

Efecto sin lista de dependencias

Funciones como dependencia

Ajustar estado durante el render

StrictMode

Resumen

Referencias

FileNotFoundError por ruta larga en Windows (MAX_PATH)

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

Node.js y subprocesos

Git: Filename too long

El límite de los directorios es menor

Explorador, cmd.exe y otras aplicaciones

Resumen

Referencias

git status muestra todos los archivos modificados en WSL

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

El repositorio está en /mnt/c/...

No puedes confirmar un .gitattributes

El diff muestra old mode y new mode

Worktrees que se abren desde ambos lados

Resumen

Referencias

Docker build cache llena el disco: docker builder prune

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

La diferencia con docker system prune

Los logs de los contenedores

Imágenes antiguas

Otro constructor de buildx

Resumen

Referencias

Prisma P2028: Transaction already closed (timeout)

Por qué pasa

Solución

Cómo verificar que quedó resuelto

Variantes y errores relacionados

Una primera corrección parcial no basta

maxWait agotado

P2024: agotado el pool de conexiones

Consultas sin await

P2034: conflicto de escritura o bloqueo mutuo

Versión de la documentación

Resumen

Referencias

`database table is locked`

`ProgrammingError: SQLite objects created in a thread can only be used in that same thread`

Transacciones implícitas del módulo `sqlite3`

Solo `whitelist: true`

El repositorio está en `/mnt/c/...`

No puedes confirmar un `.gitattributes`

El diff muestra `old mode` y `new mode`

La diferencia con `docker system prune`

`maxWait` agotado

Consultas sin `await`

Una clase propia en `@layer utilities` deja de funcionar con variantes

`!important` como parche

No uses `taskkill /im node.exe`

No uses `--no-verify`

`UnicodeDecodeError: 'utf-8' codec can't decode byte ...`

`PYTHONIOENCODING` con manejador de errores

No uses `safe.directory '*'`

Agregarlo en el `.git/config` del repositorio no sirve

El mismo error en `pre-push` y otros hooks

Cuando sí es un problema de `PATH`