Preparar el taller y demostrar lo aprendido

Ambos módulos tienen 30 sesiones de una hora. Cada sesión dedica 10 minutos a explicación, 45 a trabajo guiado y 5 a comprobar y guardar el avance. Esta guía se consulta cuando hace falta una herramienta; no añade una unidad ni una entrega.

No necesitas el CRUD de Servidor, el workflow de Intermodular ni haber cursado el otro módulo transversal. Si ya conoces una herramienta, utilízala para realizar la actividad de hoy y demostrar su objetivo. Puedes reutilizar un soporte, pero no presentar como nueva una evidencia ya evaluada sin aportar el análisis o comprobación que se pide aquí.

Preparar el trabajo y usar la terminal

1. Empieza por el objetivo de la actividad y los materiales de la sesión. Identifica qué problema vas a resolver y qué resultado podrás comprobar al terminar.
2. Durante el trabajo conserva las decisiones, datos y comprobaciones que explican tu resultado. Pueden ser tablas, cálculos, cambios de código o pruebas; utiliza los que pida la actividad.
3. En el cierre contrasta lo realizado con el resultado esperado. Distingue qué has comprobado, qué conclusión puedes justificar y qué dificultad queda pendiente.
4. Para un ZIP, utiliza «Extraer todo» y abre la carpeta extraída. No edites dentro del ZIP. En VS Code, Archivo → Abrir carpeta muestra sus archivos a la izquierda.
5. Terminal → Nueva terminal abre una consola. pwd muestra la carpeta actual en PowerShell y Bash; dir en Windows o ls en Linux/macOS muestra sus archivos. Antes de ejecutar un programa, comprueba que su archivo está ahí. Una ruta con espacios se escribe entre comillas.
6. Python ejecuta los programas de los laboratorios: comprueba python --version, o py --version en Windows. Si falta, utiliza el equipo preparado por el centro o la instalación de Python 3 del aula. Tras instalar, vuelve a abrir la terminal. Los paquetes y extensiones deben estar preparados antes de la práctica que los utiliza.

Los casos de empresa y sus datos están en la ficha de casos en PDF. Son situaciones didácticas. Escribe explícitamente cuándo una cifra es un dato del caso, una medida tuya o una estimación.

Guardar código en GitHub por primera vez

Git conserva versiones; GitHub aloja un repositorio y permite compartirlo. Para los primeros archivos podemos utilizar la interfaz web, sin depender del taller de Git de otra asignatura.

1. Inicia sesión con la cuenta disponible en el aula. Pulsa New repository, pon un nombre de laboratorio y añade un README. En el taller cloud usa un repositorio público con datos ficticios para que la VM pueda descargarlo sin credenciales.
2. Dentro del repositorio, Add file → Upload files. Arrastra los archivos extraídos, no el ZIP ni una carpeta que los oculte a otro nivel. Confirma la subida con un mensaje que describa lo guardado.
3. Abre el repositorio y comprueba index.html, estilos e imagen. El historial identifica esa versión. Copia el enlace del commit desde el historial cuando se pida una versión concreta.
4. Para actualizar un archivo, abre su edición web o sube su nueva versión, revisa los cambios y confirma. Descargar otra vez con Code → Download ZIP permite obtener la versión guardada. Conserva tus archivos locales al comparar.

Si utilizas Git local, comprueba primero git --version. Desde la carpeta padre, git clone URL carpeta descarga una copia y cd carpeta entra en ella. Sustituye URL por el enlace HTTPS que muestra Code; no escribas literalmente «URL». La actividad valora tus decisiones, no cuántos commits hayas hecho.

Cloud: del sitio inicial al entorno de laboratorio

Leer la guía del sitio inicial en PDF.

Descargar sitio inicial. Contiene HTML, CSS, una imagen SVG y su guía en PDF. No necesita Node, base de datos ni Spring. En Digitalización UD4 se modifica este mismo sitio.

Elegir y abrir el entorno

Para esta práctica necesitas un entorno Ubuntu con permisos de administración, IP y nombre de laboratorio. Puede estar en una suscripción del centro: no se exige comprar una cuenta ni disponer personalmente de Azure for Students. Si se utiliza una cuenta propia admitida, se comprueban antes disponibilidad y costes. Los fallos de acceso se resuelven con un entorno asignado; no se sustituyen evidencias técnicas por capturas ajenas.

1. En Azure, busca Virtual machines y crea una VM dentro del grupo de recursos de esta práctica. Selecciona Ubuntu Server LTS y un tamaño pequeño suficiente aprobado para el aula. Revisa región, disco y coste estimado antes de crear; los valores disponibles dependen de la suscripción.
2. Elige autenticación con clave SSH y anota el usuario, por ejemplo azureuser. Descarga y conserva la clave privada fuera del repositorio. No es un archivo para entregar.
3. En la red permite SSH desde la dirección de acceso del aula; HTTP y después HTTPS se abrirán para el sitio público. Cuando termine la creación, copia la IP pública desde el recurso.
4. En tu terminal local sustituye la ruta, usuario e IP del siguiente comando. Si es la primera conexión, contrasta la identidad del servidor con los datos del entorno antes de aceptar. Una vez dentro, whoami y hostname identifican la máquina remota.

ssh -i "RUTA_A_TU_CLAVE.pem" azureuser@IP_PUBLICA
whoami
hostname
sudo apt update

Si SSH no conecta: revisa VM encendida, IP pública, usuario, ruta de clave y regla del puerto 22. Una clave con permisos inadecuados requiere corregir sus permisos en tu sistema con ayuda del entorno del aula, no pegarla en el chat. La guía oficial de Azure muestra el procedimiento de creación y conexión.

Publicar con Nginx

Ejecuta estos comandos dentro de Ubuntu. systemctl muestra el estado del servicio; pulsa q para salir de esa vista. curl -I solicita las cabeceras de la respuesta.

sudo apt install nginx git
sudo systemctl status nginx
curl -I http://localhost
sudo ufw status

Permite TCP/80 en la regla de entrada de la VM. Si UFW ya está activo, permite también sudo ufw allow 'Nginx Full'. No actives un firewall remoto sin conservar antes el acceso SSH. Comprueba la bienvenida de Nginx por la IP pública.

Solo en la VM de laboratorio, sustituye el enlace del repositorio público y descarga el sitio. Si la carpeta ya existe, comprueba qué contiene y reutiliza su actualización; no vuelvas a clonar encima ni borres otra práctica.

sudo git clone https://github.com/TU_USUARIO/TU_REPOSITORIO.git /var/www/mi-sitio
ls /var/www/mi-sitio
sudo nano /etc/nginx/sites-available/mi-sitio

Pega la plantilla. root debe señalar la carpeta que contiene directamente index.html. Guarda en nano con Ctrl+O, confirma con Enter y sal con Ctrl+X.

server {
    listen 80;
    server_name _;
    root /var/www/mi-sitio;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Activa este sitio y desactiva únicamente el enlace de bienvenida de Nginx de esta VM recién creada. El archivo de bienvenida se conserva en sites-available. Si trabajas en un servidor compartido, utiliza una configuración propia y conserva su sitio por defecto.

sudo ln -s /etc/nginx/sites-available/mi-sitio /etc/nginx/sites-enabled/mi-sitio
sudo unlink /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

Ejecuta la recarga solo si nginx -t informa una configuración correcta. Si dice que el enlace ya existe, compruébalo; no lo crees de nuevo. Visita la IP y verifica el nombre de la empresa. Un 403 puede indicar carpeta equivocada o permisos de lectura; un 404 identifica un recurso no encontrado.

Nombre y HTTPS

1. Usa el nombre asignado por el centro. Como alternativa, en un proveedor de DNS dinámico del aula crea un subdominio y establece su IP pública. En DuckDNS, por ejemplo, se registra el nombre disponible y se actualiza su dirección desde el panel. El token de administración se conserva privado.
2. Desde la terminal local ejecuta nslookup TU_NOMBRE. La dirección debe coincidir con la VM. Si no, comprueba el registro y espera la actualización según el proveedor.
3. En el archivo de Nginx cambia server_name _; por server_name TU_NOMBRE;. Sustituye el marcador por tu nombre real, sin escribir http://. Comprueba, recarga y visita primero la URL HTTP.
4. Permite TCP/443 además de 80. En Ubuntu instala Certbot y su integración con Nginx. Ejecuta el comando de abajo con el nombre real; sigue la validación y configura redirección a HTTPS. El puerto 80 debe ser alcanzable para el desafío HTTP de este procedimiento.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d TU_NOMBRE
sudo certbot renew --dry-run

Certbot necesita un nombre público que resuelva correctamente y una ruta de validación accesible. Si el entorno está limitado a una red privada, utiliza el entorno público del laboratorio para comprobar este criterio; la simulación local permite avanzar, pero no demuestra publicación HTTPS. Consulta las instrucciones de Certbot para el sistema elegido.

Actualizar y cerrar el laboratorio

Después de subir el cambio a GitHub, en Ubuntu ejecuta:

cd /var/www/mi-sitio
sudo git pull --ff-only
git rev-parse HEAD

Si Git rechaza la propiedad de la carpeta, consulta la versión con sudo git rev-parse HEAD dentro de esa carpeta. El sitio de esta práctica es de solo lectura para Nginx. No es un flujo propuesto para aplicaciones con datos de usuarios o escritura en producción.

Comprueba la frase nueva desde la URL pública. Conserva un inventario de VM, disco, IP y nombre, y acuerda hasta cuándo deben estar disponibles para evaluar. Revisa los recursos asociados y el coste antes de retirarlos: cerrar SSH no apaga la VM y detenerla no elimina todos los recursos asociados.

IA, instrucciones y revisión

1. Abre solo la carpeta del laboratorio y el asistente del aula. En Copilot, inicia sesión en VS Code con la cuenta habilitada y abre su panel Chat. Utiliza el puesto de prácticas con acceso al agente para poder comprobar los cambios reales.
2. Pide primero que identifique archivos y proponga un plan sin editar. Contrasta su descripción con la carpeta abierta.
3. Escribe objetivo, contexto, restricciones y criterios de aceptación. Acepta cambios pequeños y revisa qué archivos solicita modificar.
4. Compara antes/después: en VS Code, selecciona el archivo inicial para comparar y después compara con la versión nueva; si hay Git, Control de código fuente muestra las modificaciones. Las líneas añadidas o eliminadas deben relacionarse con la tarea.
5. Prueba el resultado en el navegador o con las comprobaciones del laboratorio. Guarda petición, decisión y resultado; selecciona los intercambios que explican una decisión y comprueba su resultado.

En Copilot, las instrucciones generales del repositorio se guardan en .github/copilot-instructions.md. Comprueba que la función del agente que utilizas las lee; otros entornos pueden utilizar otra ruta. Véase la documentación oficial. Un ejemplo breve:

Este sitio estático presenta una empresa ficticia.
Conserva sus secciones y no añadas dependencias sin justificar su necesidad.
Antes de editar, explica los archivos que cambiarás.
Después, comprueba enlaces, imágenes y la tarea solicitada en el navegador.
Informa de las pruebas que no hayas podido ejecutar.

Plantilla de procedimiento reutilizable: si tu entorno admite skills, guárdala en la ruta reconocida, por ejemplo .github/skills/revisar-sitio/SKILL.md; si no, utiliza el contenido como ficha o prompt de revisión.

---
name: revisar-sitio
description: Revisar un cambio acotado de un sitio estático y sus evidencias.
---
1. Lee la tarea y sus criterios de aceptación.
2. Examina solo los archivos modificados y señala cambios fuera de alcance.
3. Comprueba el comportamiento solicitado y otro que deba conservarse.
4. Registra evidencia, resultado y límites; no afirmes pruebas no ejecutadas.

En Sostenibilidad puedes aplicar la revisión sin cursar Digitalización. Ficha alternativa para contrastar propuestas: «eliminar todas las imágenes reduce transferencia» debe rechazarse si destruye información útil; «convertir una imagen sobredimensionada» debe probarse midiendo y comparando calidad; «quitar un script porque pesa» requiere investigar su función. Si no hay acceso al asistente, se analizan estas recomendaciones preparadas y se registra como revisión de la ficha, sin atribuir una interacción inexistente a una IA.

Notebook y datos

Leer la guía del cuaderno en PDF.

Descargar notebook, requisitos y guía PDF. La guía PDF explica entorno, instalación, selección de kernel, ejecución de celdas y comprobación final. El Excel original se descarga desde UCI la primera vez y después se reutiliza. Si ya tienes el Excel original, colócalo en la ruta indicada para reutilizarlo sin descargarlo otra vez.

Si el puesto no permite instalar, abre el mismo notebook en el entorno Jupyter preparado por el centro, con pandas, openpyxl y matplotlib disponibles. Verifica la celda de carga antes de analizar. La salida esperada del original es 541.909 filas y 8 columnas; el cuaderno conserva decisiones de calidad y datos originales. Fuente: Online Retail, UCI.

Laboratorio de seguridad

Leer la guía y los retos en PDF.

Descargar laboratorio local. Incluye aplicación, siete pruebas y una guía PDF con matriz de permisos y pistas. La versión inicial tiene cuatro fallos deliberados: acceso a un pedido ajeno, SQL construido con entrada, configuración expuesta y detalle de error público. Tres pruebas pasan y cuatro fallan inicialmente; las siete deben pasar tras las correcciones de estos casos.

Extrae, abre su carpeta y ejecuta python app.py; visita http://127.0.0.1:8090. En otra terminal ejecuta python -m unittest -v. Todo utiliza datos ficticios y biblioteca estándar. La identidad está simulada para estudiar autorización; no se presenta como login seguro. La práctica se ejecuta solo localmente y no se publica junto al sitio de cloud.

PixelStore: abrir, medir y revisar

Obtener la copia correcta

Para UD3 abre el repositorio PixelStore, selecciona main y usa Code → Download ZIP. Extrae y renombra la carpeta como pixelstore. También puedes usar Git:

git clone https://github.com/MarcSemperLloret/webssos.git pixelstore
cd pixelstore
python -m http.server 8080 --bind 127.0.0.1

Abre http://127.0.0.1:8080, deja la terminal abierta y comprueba que carga el catálogo. El doble clic usa file:// y no reproduce correctamente esta práctica que carga datos. Si el puerto está ocupado, detén el servidor anterior o usa otro y anótalo.

Para UD4 selecciona barreras antes de descargar el ZIP y utiliza otra carpeta, o ejecuta desde una carpeta padre:

git clone -b barreras https://github.com/MarcSemperLloret/webssos.git pixelstore-a11y
cd pixelstore-a11y
python -m http.server 8081 --bind 127.0.0.1

Abre http://127.0.0.1:8081. Conserva la carpeta y mediciones anteriores de UD3: cambiar de rama sobre un trabajo sin guardar no es el procedimiento de este taller.

Medir antes y después

1. En Chrome/Chromium abre DevTools con F12 o Inspeccionar y selecciona Network/Red. Mantén la ventana abierta durante la prueba.
2. Selecciona un perfil acordado, por ejemplo escritorio sin limitación de red para esta comparación, y marca Disable cache/Desactivar caché. Limpia la lista, recarga y espera a que termine el catálogo. Registra si hay recursos fallidos.
3. Anota el total transferido y peticiones; ordena por tamaño y conserva los cinco recursos mayores. Distingue tamaño transferido de tamaño descomprimido y usa la misma columna después.
4. Abre Lighthouse, selecciona el mismo perfil en ambas versiones y ejecuta el análisis. Guarda su configuración y resultado como evidencia separada de Red. No ejecutes otras tareas intensivas durante la comparación.
5. Si los resultados varían mucho, repite en condiciones equivalentes y registra esa variación. La prueba demuestra el recorrido y entorno medidos, no todos los posibles usuarios ni emisiones.

Imagen: un cambio comprobable

Localiza el archivo que aparece en Red y su referencia en HTML, CSS o datos del catálogo. Con una herramienta de imagen del aula, como Squoosh, abre el archivo, ajusta dimensiones al uso previsto y exporta WebP u otro formato admitido. Compara visualmente antes de guardar. Cambia la referencia en el proyecto, recarga y verifica respuesta 200, bytes y calidad. Conserva el original fuera de la carpeta servida. No se exige un servicio de pago ni generar imágenes con IA.

Accesibilidad: una primera corrección

En una copia de trabajo, un control que ejecuta una acción debe usar un elemento apropiado. Si encuentras un div que actúa como botón, conserva sus clases y acción al cambiarlo por button type="button". Revisa posibles selectores JavaScript que dependan de la etiqueta. Comprueba Tab, Enter y Espacio, aspecto y resultado de la acción.

button:focus-visible {
  outline: 3px solid #17606a;
  outline-offset: 3px;
}

El color del foco debe distinguirse del fondo concreto de la página. Para un formulario, relaciona label for="correo" con input id="correo" y comprueba la asociación. En el inspector consulta el panel Accessibility/Accesibilidad del elemento: nombre, rol y estado. Un cambio puede no verse y sí afectar a tecnologías de apoyo; no quites ARIA solo porque el ratón siga funcionando igual. La guía W3C explica esta distinción.

Para la comprobación automática, ejecuta Lighthouse y la extensión axe DevTools habilitada en el aula: abre su panel, inicia el análisis, selecciona un aviso y localiza el elemento. Si la extensión no está disponible, registra Lighthouse más las pruebas manuales y declara ese alcance. Ni un resultado automático ni una corrección aislada acreditan conformidad completa.

Evaluación mediante actividades

Cada unidad tiene una actividad sobre 10 con su rúbrica específica. Cada sesión añade evidencias al mismo trabajo. La ponderación es proporcional a las horas de la unidad: nota del módulo = suma de (nota de actividad × horas de la unidad) / 30. No se añade examen. La exposición y las preguntas comprueban las decisiones de la actividad.

Ejemplo: en una unidad de cuatro horas, una actividad con 8 aporta 8 × 4/30 a la nota final. Los pesos suman 30/30 dentro de cada módulo. El plan final integra las evidencias anteriores y se valora por su coherencia y viabilidad; no vuelve a puntuar la misma implementación como una actividad nueva.

Cómo demostrar un criterio

Por ejemplo, para una comparación antes/después: sin referencia no se acredita la comparación; dos medidas con condiciones distintas dejan el criterio en desarrollo; medidas comparables permiten lograrlo; interpretar su cambio y límites completa el criterio. Estos niveles se aplican a la dimensión que describe cada fila de la rúbrica, no exigen añadir pruebas o texto ajenos a ella.

Trabajo compartido y mejora

1. Cada integrante registra al menos una decisión propia y explica su evidencia durante el taller o la revisión. No se evalúa a una sola persona al azar como representante de todas.
2. La rúbrica describe la calidad del producto común. La atribución individual se comprueba con las aportaciones y explicaciones; un criterio sin evidencia individual suficiente queda pendiente de comprobación, sin inferirlo del número de commits.
3. Tras el feedback, actualiza la misma actividad y añade criterio pendiente, cambio realizado y comprobación. Conserva ambas versiones o un registro de diferencias.