Recursos oficiales y cómo leerlos#

Este catálogo prioriza documentación primaria ligada a las lecciones. No es una lista de cursos que debas terminar antes de programar: abre la referencia cuando una pregunta concreta aparezca, lee el tramo señalado y vuelve a probar una predicción. Enlaces consultados el 2026-10-18; una URL accesible no garantiza que el recurso o tu versión local coincidan para siempre. “Core” indica lectura útil para el camino principal; “después” señala profundización opcional.

Para definiciones conceptuales exhaustivas desde primeros principios, consulta en paralelo el glosario técnico general del curso.

Diccionario de términos de las fuentes oficiales#

Antes de consultar la documentación primaria en inglés, revisa la definición formal de los términos canónicos empleados por los autores de los estándares y herramientas oficiales:

1. Toolchain (Cadena de herramientas)#

• En palabras simples: El conjunto articulado de herramientas que necesitas para construir un mueble: el metro de medir, la sierra, el taladro y la lija, ensamblados para trabajar con la misma madera.
• Definición técnica: Conjunto cohesivo y versionado de binarios que cooperan para compilar y procesar software: el compilador (rustc), el enlazador (linker), el gestor de paquetes (cargo), la biblioteca estándar (std) y componentes de depuración o análisis para un destino de arquitectura y sistema operativo específico (target triple, ej. x86_64-pc-windows-msvc).
• Qué NO es: No es un lenguaje de programación; es la suite de software que procesa el código del lenguaje.

2. Rustup#

• En palabras simples: El encargado de compras y mantenimiento de herramientas: si necesitas cambiar de la caja de herramientas estable a la versión nocturna o añadir soporte para compilar hacia WebAssembly, rustup descarga y organiza las herramientas sin que tengas que desinstalar nada a mano.
• Definición técnica: Multiplexor oficial y gestor de versiones para toolchains de Rust. Administra la descarga, actualización y conmutación entre canales de distribución (stable, beta, nightly) y componentes opcionales (clippy, rust-analyzer, rust-src).
• Qué NO es: No es el compilador; solo decide qué versión de rustc y cargo se ejecuta al invocar el comando en la terminal.

3. Crate#

• En palabras simples: Una caja sellada de piezas de construcción con su propia etiqueta identificadora.
• Definición técnica: La unidad mínima e indivisible de compilación en Rust. Puede ser un binario ejecutable (crate-type: bin) o una biblioteca reutilizable (crate-type: lib).
• Qué NO es: No es un módulo suelto (mod); un crate contiene un árbol jerárquico completo de módulos.

4. Lint#

• En palabras simples: La alarma de un revisor ortográfico que te avisa: "Esta frase se entiende, pero está escrita con una construcción ambigua que confundirá a tus lectores".
• Definición técnica: Regla de análisis estático que examina el árbol sintáctico y el flujo de tipos en busca de construcciones sospechosas, código inalcanzable, variables no utilizadas, convenciones de nombres violadas o patrones propensos a errores (anti-patterns), sin alterar la generación de código.
• Qué NO es: No es un error de sintaxis que impida la compilación básica; es una advertencia de calidad estructural.

5. Clippy#

• En palabras simples: Un colega veterano que revisa tu código por encima del hombro y te dice: "En Rust solemos escribir eso con un iterador en lugar de ese bucle manual, ahorrarás memoria y código".
• Definición técnica: Colección oficial de más de 600 lints estáticos para Rust que diagnostica ineficiencias de rendimiento, falta de idiomaticidad, complejidad ciclomática innecesaria y desviaciones de las mejores prácticas de la comunidad.
• Qué NO es: Un validador de lógica de negocio; Clippy no puede saber si tu cálculo de impuestos es correcto para el país donde operas.

6. Grapheme Cluster (Grupo de grafemas)#

• En palabras simples: Lo que el ojo humano percibe como "una sola letra o símbolo" en la pantalla, independientemente de cuántos bytes invisibles de computadora se necesiten para dibujarlo.
• Definición técnica: Secuencia de uno o más puntos de código Unicode que, según el algoritmo estándar de segmentación UAX #29, representa una unidad de texto indivisible para un lector humano (por ejemplo, la letra e seguida del modificador combinable de acento agudo ´, o un emoji familiar compuesto por cuatro puntos de código unidos por caracteres de unión de ancho cero).
• Qué NO es: No es un byte ni un char de Rust. Un único grafema puede ocupar 8 bytes o más en un String.

7. Extractor (Actix Web)#

• En palabras simples: El empleado del banco que abre el sobre sellado de tu trámite, verifica que el documento de identidad sea original, saca los billetes y te los deja contados y listos sobre el mostrador antes de que comience la reunión.
• Definición técnica: Mecanismo tipado en Actix Web basado en el trait FromRequest. Procesa la solicitud HTTP entrante de forma asíncrona para deserializar componentes tipados (web::Json<T>, web::Path<T>, web::Query<T>, web::Data<T>) antes de que el handler sea invocado.
• Qué NO es: No es un middleware de transporte general; se evalúa por parámetro dentro de la firma de un handler específico.

8. ACID#

• En palabras simples: La garantía incondicional de un traspaso de dinero: o el dinero sale de una cuenta y entra en la otra a la vez, o la operación se cancela como si nada hubiera ocurrido.
• Definición técnica: Conjunto de cuatro propiedades matemáticas que garantizan la integridad de transacciones en bases de datos: Atomicidad (todo o nada), Consistencia (respeto de invariantes), Aislamiento (ejecución sin interferencias concurrentes) y Durabilidad (persistencia indestructible respaldada por WAL).
• Qué NO es: No implica que la base de datos sea inmune a fallos de diseño lógico del programador (ej. insertar datos absurdos pero con tipos válidos).

9. MVCC (Multi-Version Concurrency Control)#

• En palabras simples: En lugar de tapar con cinta blanca un libro para corregirlo impidiendo que otros lo lean, le sacas una fotocopia instantánea al capítulo para que los lectores sigan leyendo la versión anterior mientras tú redactas la nueva página en privado.
• Definición técnica: Mecanismo de persistencia concurrente utilizado por PostgreSQL donde cada modificación (UPDATE, DELETE) no sobreescribe la fila física inmediatamente, sino que genera una nueva versión (tuple) con identificadores de transacción de creación (xmin) y expiración (xmax), permitiendo que las lecturas no bloqueen escrituras y las escrituras no bloqueen lecturas.
• Qué NO es: No es almacenamiento infinito; requiere el proceso periódico de VACUUM para reclamar el espacio de filas viejas no referenciadas.

10. Narrowing (Estrechamiento de tipos en TypeScript)#

• En palabras simples: Empezar sabiendo que en una caja hay "un animal" y, al escuchar que ladra y ver que mueve la cola, deducir con certeza que es "un perro" y poder pedirle que te dé la pata.
• Definición técnica: Proceso formal del verificador estático de TypeScript donde el tipo de una variable pasa de una unión amplia o abstracta (como unknown o string | number) a un tipo más restrictivo y específico mediante guardas booleanas de código ejecutable (typeof, instanceof, in, Array.isArray o predicados de tipo).
• Qué NO es: No es un casteo forzado con as; el narrowing exige comprobaciones reales ejecutadas en tiempo de ejecución.

11. OWASP (Open Web Application Security Project)#

• En palabras simples: La fundación global sin fines de lucro de seguridad informática que recopila los manuales de prevención de fraudes y las listas de fallos más frecuentes para que los constructores de software no repitan errores del pasado.
• Definición técnica: Comunidad internacional y organización de estándares abiertos que publica hojas de trucos metodológicas (Cheat Sheets), guías de pruebas y clasificaciones canónicas de riesgos de seguridad (como el OWASP Top 10 y el API Security Top 10).
• Qué NO es: No es un software ni un antivirus instalable; es un catálogo riguroso de diseño de seguridad y defensa en profundidad.

12. OpenTelemetry (OTel)#

• En palabras simples: El estándar universal para los sensores y cajas negras de los aviones: unifica cómo medir revoluciones, combustible y altitud sin importar si el avión es Boeing o Airbus.
• Definición técnica: Marco y estándar abierto de instrumentación de observabilidad independiente del proveedor (vendor-neutral). Define especificaciones, APIs y SDKs para recolectar, procesar y exportar trazas distribuidas, métricas y registros estructurados hacia plataformas analíticas.
• Qué NO es: No es una base de datos de almacenamiento ni una interfaz gráfica; es el protocolo y SDK de instrumentación.

Módulo 00 — preparar el estudio#

• Core — Rustup: instalación oficial.
• Guía de estudio paso a paso: 1. Antes de pulsar ningún botón de descarga, abre tu terminal y ejecuta rustc --version y cargo --version. 2. Lee en la documentación qué variables de entorno configura rustup (principalmente CARGO_HOME y RUSTUP_HOME) y cómo manipula la variable de entorno PATH. 3. Inspecciona qué componentes gestiona rustup (rustc, cargo, rust-std, rust-docs) y cómo se selecciona entre canales (stable, beta, nightly).
• Qué buscar exactamente: Comprende cómo rustup aísla los toolchains en carpetas locales de usuario sin requerir permisos de administrador en Windows.
• Preguntas profundas de verificación al leer la fuente:
• ¿Qué resultado en la terminal prueba empíricamente que un comando está disponible y funcional, y cuál sería solo una instrucción de instalación sugerida por el sistema operativo?
• Si tienes instalado un compilador mediante rustup y otro mediante un gestor de paquetes de terceros (como winget o scoop), ¿cuál de los dos se invocará al escribir rustc y qué variable del sistema operativo determina esa precedencia?

Módulo 01 — Rust independiente#

• Core — The Rust Programming Language, capítulos:
• Capítulo 3: Conceptos comunes de programación: Variables, inmutabilidad por defecto, tipos escalares y compuestos, funciones, expresiones vs sentencias.
• Capítulo 4: Comprensión de Ownership: Reglas de propiedad, pila vs heap, semántica de movimiento (move), referencias compartidas (&T), referencias mutables (&mut T), slice types (&str, &[T]).
• Capítulo 5: Uso de Structs: Definición e instanciación de structs, sintaxis de actualización, structs tupla, métodos y bloques impl.
• Capítulo 6: Enums y Pattern Matching: Definición de variantes con datos, el enum Option<T>, control de flujo exhaustivo con match, construcción if let.
• Capítulo 8: Colecciones comunes: Vectores Vec<T>, cadenas UTF-8 String, tablas asociativas HashMap<K, V>.
• Capítulo 9: Manejo de errores: Errores irrecuperables con panic!, errores recuperables con Result<T, E>, el operador de propagación ?.
• Capítulo 10: Tipos genéricos, Traits y Lifetimes: Parámetros genéricos, definición e implementación de traits, sintaxis de trait bounds, sintaxis de anotación de tiempos de vida (lifetimes).
• Capítulo 11: Cómo escribir pruebas automatizadas: Atributos #[test], macros de aserción (assert!, assert_eq!), pruebas unitarias frente a pruebas de integración.
• Guía de estudio paso a paso: 1. Lee un capítulo a la vez justo cuando tu ejercicio práctico lo demande. No intentes memorizar el libro de corrido. 2. Cuando el texto afirme que "Rust no permite X", abre un archivo temporal y escribe intencionalmente ese código para observar el diagnóstico exacto emitido por rustc. 3. Rastrea en un papel qué variables residen en la pila y qué bloques se alojan en el heap para cada ejemplo de ownership.
• Qué buscar exactamente: La relación causal entre la semántica de movimiento en el stack y la liberación determinista de memoria en el heap mediante Drop.
• Preguntas profundas de verificación al leer la fuente:
• ¿Por qué el compilador de Rust prohíbe tener una referencia mutable (&mut T) y una referencia inmutable (&T) activas en el mismo ámbito temporal?
• ¿Qué ocurre en la memoria si intentas mover un String a otra variable mientras una referencia inmutable a ese String sigue siendo leída?

• Core — Rust by Example.
• Guía de estudio: Úsalo como catálogo de sintaxis mínima para comparar patrones después de haber razonado el mecanismo en el libro.
• Qué buscar exactamente: Formatos idiomáticos para declarar módulos (mod), closures y conversiones de tipo con traits From e Into.
• Preguntas profundas de verificación:
• ¿Puedes explicar la diferencia entre pasar una variable por valor (T), por referencia (&T) y por referencia exclusiva (&mut T) en cada ejemplo pequeño?

• Core — Rustlings.
• Guía de estudio: Serie de ejercicios interactivos con errores deliberados.
• Qué buscar exactamente: Lee atentamente el mensaje del compilador antes de modificar el archivo. La enseñanza pedagógica reside en el diagnóstico de error, no en la solución apresurada.
• Preguntas profundas de verificación:
• ¿Qué invariante de memoria intentaba proteger el compilador cuando el ejercicio fallaba inicialmente?

• Core — Cargo test y Rust Clippy.
• Guía de estudio: Aprende las opciones de filtrado de pruebas (cargo test <nombre>) y las categorías de advertencias de Clippy (correctness, suspicious, perf, style).
• Qué buscar exactamente: Cómo Clippy detecta asignaciones redundantes de memoria o clones innecesarios.
• Preguntas profundas de verificación:
• ¿Un aviso de Clippy en categoría style demuestra que el programa es incorrecto? ¿Qué evidencia te haría decidir entre aceptar o suprimir un lint con #[allow(...)]?

• Después — Rust Book: Strings en profundidad.
• Guía de estudio: Estudia por qué Rust no implementa indexación directa por números enteros en cadenas (&text[0]).
• Qué buscar exactamente: La diferencia entre bytes (u8), puntos de código escalar (char, 4 bytes) y grupos de grafemas humanos.
• Preguntas profundas de verificación:
• ¿Por qué word.len() sobre una cadena como "año" devuelve 4 y no 3? ¿Qué sucedería si el compilador permitiera cortar la cadena en el byte número 2?

Módulo 02 — HTTP, Actix, PostgreSQL y async#

• Core — MDN: Overview of HTTP.
• Guía de estudio paso a paso: 1. Revisa la estructura anatómica de una solicitud y una respuesta HTTP en texto plano. 2. Distingue la capa de transporte (TCP/TLS) de la capa de aplicación (HTTP/1.1 o HTTP/2). 3. Estudia la semántica formal de seguridad e idempotencia para cada método HTTP estándar.
• Qué buscar exactamente: Cómo las cabeceras configuran el contrato de serialización (Content-Type, Accept) y cómo los códigos de estado informan del resultado.
• Preguntas profundas de verificación:
• ¿Un código de respuesta 200 OK garantiza que el cuerpo de la respuesta contiene datos válidos para el cliente? ¿Por qué es un error grave responder 200 cuando el servidor sufrió un fallo de base de datos?

• Core — Actix Web: Getting Started y Testing.
• Guía de estudio paso a paso: 1. Estudia cómo HttpServer instancia múltiples instancias de App (una por cada hilo de trabajo de hardware). 2. Diferencia una prueba de servicio en proceso (actix_web::test::init_service) de una prueba de cliente de red completa con sockets TCP.
• Qué buscar exactamente: La necesidad de que el estado compartido envuelto en web::Data<T> sea clonable e implemente Send + Sync.
• Preguntas profundas de verificación:
• ¿Qué frontera de red física NO recorre una prueba ejecutada mediante test::init_service? ¿Por qué es mucho más rápida que levantar un servidor en el puerto 8080?

• Core — Actix Web en docs.rs.
• Guía de estudio: Consulta las firmas de los traits FromRequest y Responder.
• Qué buscar exactamente: Qué tipos implementan Responder de fábrica (como HttpResponse, &'static str, String) y cómo se construyen respuestas con códigos de estado tipados.
• Preguntas profundas de verificación:
• ¿Cómo garantiza el compilador que un extractor no sea invocado si la solicitud HTTP no incluye la cabecera Content-Type: application/json correspondiente?

• Core — PostgreSQL: Constraints, Transaction Isolation e Indexes.
• Guía de estudio paso a paso: 1. Lee las definiciones de restricciones PRIMARY KEY, UNIQUE, CHECK y FOREIGN KEY. 2. Analiza los fenómenos de concurrencia: lecturas sucias (dirty read), lecturas no repetibles (non-repeatable read) y anomalías de serialización (serialization anomaly). 3. Estudia el funcionamiento de índices B-Tree y la lectura de planes con EXPLAIN ANALYZE.
• Qué buscar exactamente: Por qué una restricción UNIQUE en la base de datos es la única defensa real contra colisiones concurrentes, y por qué un SELECT previo en el backend es vulnerable a condiciones de carrera TOCTOU.
• Preguntas profundas de verificación:
• ¿En qué nivel de aislamiento predeterminado opera PostgreSQL? ¿Qué anomalía de concurrencia puede ocurrir en READ COMMITTED que queda completamente prevenida en REPEATABLE READ?

• Core — Rust Book: Async/Await.
• Guía de estudio: Entiende la suspensión cooperativa de tareas asíncronas mediante máquinas de estados sintetizadas por el compilador.
• Qué buscar exactamente: La distinción entre un hilo del sistema operativo y una tarea asíncrona liviana (task).
• Preguntas profundas de verificación:
• ¿Por qué ejecutar una llamada síncrona como std::thread::sleep dentro de una función async congela todo el hilo de trabajo del runtime y causa inanición en otras tareas?

Módulo 03 — HTML, CSS, TypeScript, React#

• Core — MDN: Structuring Content y Web Accessibility.
• Guía de estudio: Estudia el árbol DOM y el Árbol de Accesibilidad (AOM). Explora los puntos de referencia estructurales (<main>, <nav>, <header>).
• Qué buscar exactamente: Cómo el navegador calcula el nombre accesible a partir del texto interior o etiquetas <label>.
• Preguntas profundas de verificación:
• ¿Qué información percibe una persona que utiliza un lector de pantalla o navega exclusivamente con teclado frente a una persona que observa la pantalla con ratón?

• Core — MDN: Forms and Buttons y CSS Box Model.
• Guía de estudio: Aprende la asociación canónica entre label for e input id, y la diferencia entre content-box y border-box.
• Qué buscar exactamente: Cómo box-sizing: border-box evita que el padding y el border aumenten el ancho total exterior de una caja interactiva.
• Preguntas profundas de verificación:
• ¿Por qué un atributo placeholder no reemplaza legalmente a una etiqueta <label> según las pautas WCAG?

• Core — MDN: Using Fetch.
• Guía de estudio: Analiza el ciclo de resolución de una promesa retornada por fetch().
• Qué buscar exactamente: El comportamiento ante errores HTTP: por qué un estado 404 o 500 no entra al bloque catch.
• Preguntas profundas de verificación:
• ¿Qué condición física de red causa que fetch() rechace su promesa? ¿Por qué es imperativo comprobar response.ok antes de invocar response.json()?

• Core — TypeScript Handbook: Narrowing.
• Guía de estudio: Rastrea cómo las comprobaciones de guardia en runtime reducen un tipo amplio (unknown, uniones) a un tipo concreto.
• Qué buscar exactamente: Predicados de tipo definidos por el usuario (value is T) y uniones discriminadas con verificación exhaustiva de tipo never.
• Preguntas profundas de verificación:
• ¿Por qué escribir const data = raw as Task; no provee ninguna garantía real de seguridad si el JSON recibido del backend carece de los campos esperados?

• Core — React Learn y Synchronizing with Effects.
• Guía de estudio: Estudia el flujo unidireccional de datos, la inmutabilidad en las actualizaciones de estado y el ciclo de vida de los efectos con funciones de limpieza (cleanup).
• Qué buscar exactamente: La diferencia fundamental entre un valor computado derivado durante el renderizado y una variable de estado almacenada con useState.
• Preguntas profundas de verificación:
• ¿Qué ocurre si mutas un arreglo directamente en memoria con array.push() y luego llamas a setArray(array)? ¿Por qué Object.is cancela el re-renderizado?

• Después — MDN HTTP CORS.
• Guía de estudio: Estudia la política del mismo origen (SOP) y las solicitudes preliminares (preflight) con el método OPTIONS.
• Qué buscar exactamente: Las cabeceras Access-Control-Allow-Origin, Access-Control-Allow-Methods y Access-Control-Allow-Headers.
• Preguntas profundas de verificación:
• ¿Por qué una arquitectura configurada con un proxy inverso que sirve frontend y backend bajo el mismo dominio y puerto no requiere habilitar CORS?

Módulo 04 — refactorización, límites y tests#

• Core — Rust Book: Testing.
• Guía de estudio: Analiza la anatomía de una prueba de comportamiento y el aislamiento mediante aserciones claras.
• Qué buscar exactamente: Pruebas que verifican contratos de entrada/salida y preservación de invariantes sin acoplarse a detalles privados de la estructura.
• Preguntas profundas de verificación:
• ¿Qué comportamiento observable habría hecho fallar tu prueba si la lógica de negocio hubiera introducido un defecto sutil de cálculo?

• Core — Martin Fowler: Code Smell.
• Guía de estudio: Comprende el smell como una señal diagnóstica de fricción, no como una regla dogmática que exige cambios sin justificación.
• Qué buscar exactamente: Señales clásicas: Obsesión por primitivos, Clases de datos anémicas, Ceguera booleana y Cirugía de escopeta.
• Preguntas profundas de verificación:
• ¿Qué fricción observable en el mantenimiento del código respalda tu hipótesis de que existe un smell? ¿Qué prueba de comportamiento refutaría la necesidad de refactorizar?

• Después — Refactoring Catalog.
• Guía de estudio: Consulta la mecánica paso a paso de transformaciones conocidas (Extract Function, Replace Primitive with Object, Introduce Parameter Object).
• Qué buscar exactamente: Cómo cada micro-paso de la transformación conserva la suite de pruebas en estado verde (GREEN).
• Preguntas profundas de verificación:
• ¿Cómo demuestras de forma concluyente que una refactorización estructural no introdujo una regresión de comportamiento inadvertida?

• Después — Playwright Introduction.
• Guía de estudio: Analiza la arquitectura de pruebas de extremo a extremo automatizando el protocolo DevTools del navegador.
• Qué buscar exactamente: Pruebas que interactúan a través de localizadores accesibles basados en roles y nombres (getByRole), simulando al usuario real.
• Preguntas profundas de verificación:
• ¿Qué clase de fallos detecta una prueba E2E en un navegador real que una prueba unitaria o de servicio jamás podrá advertir?

Módulo 05 — seguridad y operación#

• Core — OWASP Authorization Cheat Sheet.
• Guía de estudio: Revisa el principio de denegación por defecto (fail-closed) y la verificación de permisos en cada solicitud individual.
• Qué buscar exactamente: La prevención de vulnerabilidades de tipo BOLA / IDOR mediante la vinculación del identificador de recurso con el Principal autenticado.
• Preguntas profundas de verificación:
• Si el cuerpo JSON de una petición incluye un campo userId: 999, ¿por qué el backend jamás debe confiar en ese campo y debe utilizar exclusivamente la identidad validada en la sesión?

• Core — OWASP Session Management Cheat Sheet.
• Guía de estudio: Analiza el ciclo de vida de los identificadores de sesión, la rotación tras el inicio de sesión y los atributos de seguridad de las cookies.
• Qué buscar exactamente: El propósito de HttpOnly, Secure y SameSite para mitigar ataques de robo de sesión y fijación de sesión.
• Preguntas profundas de verificación:
• ¿Qué clase de ataques previene el atributo HttpOnly y frente a qué clase de amenazas no ofrece ninguna protección si la página tiene una vulnerabilidad XSS activa?

• Core — OWASP CSRF Prevention Cheat Sheet.
• Guía de estudio: Comprende el mecanismo de adjunción automática de credenciales por parte del navegador y la protección basada en tokens anti-CSRF sincronizados.
• Qué buscar exactamente: La diferencia entre la protección pasiva provista por SameSite=Lax/Strict y los tokens criptográficos de un solo uso.
• Preguntas profundas de verificación:
• ¿Por qué configurar cabeceras CORS en el servidor no previene los ataques de tipo Cross-Site Request Forgery (CSRF)?

• Core — OpenTelemetry Documentation.
• Guía de estudio: Analiza la instrumentación unificada de trazas distribuidas, métricas y logs estructurados.
• Qué buscar exactamente: El concepto de Correlation ID (o Trace ID) propagado a través de las cabeceras HTTP para correlacionar eventos entre el cliente, el backend y la base de datos.
• Preguntas profundas de verificación:
• ¿Por qué la media aritmética de latencia oculta las colas de saturación de un servicio y qué percentiles (p95, p99) revelan el impacto en los usuarios más afectados?

• Después — The Twelve-Factor App: Config.
• Guía de estudio: Examina la estricta separación entre el binario compilado y la configuración específica del entorno de ejecución.
• Qué buscar exactamente: La inyección de credenciales y rutas de servicios mediante variables de entorno del sistema operativo sin recompilar el artefacto.
• Preguntas profundas de verificación:
• ¿Qué valores varían legítimamente entre entornos de desarrollo, pruebas y producción sin requerir una sola línea de código modificada?

Límites de estas referencias#

Las páginas oficiales son fuentes de aprendizaje primarias, no promesas de compatibilidad eterna ni evidencia de que los ejemplos del curso hayan sido probados en tu servidor local. Para versiones, APIs y comandos específicos de una práctica, consulta la documentación vigente correspondiente al proyecto local. Si una página cambió desde el acceso de 2026-10-18, sigue la versión oficial vigente y anota la diferencia observada en tu registro de estudio.