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 el código del laboratorio en GitHub

Git conserva versiones; GitHub aloja un repositorio y permite compartirlo. Si ya trabajas con Git desde la terminal, aplica tu procedimiento habitual y continúa en el apartado siguiente. Los pasos de aquí describen la alternativa por la interfaz web: basta para los archivos de estos talleres y no depende 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. Utiliza únicamente datos ficticios en los materiales de laboratorio.
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: actividades escritas sin servicios externos

Digitalización UD3 se realiza en papel o con un editor local. No necesita cuentas, conexión a Internet, máquinas virtuales ni despliegues. Los enunciados, conceptos y datos están en las cinco sesiones de la unidad.

Cada sesión dura una hora: 10 minutos de explicación, 45 de actividad y 5 de cierre. Guarda una ficha breve por sesión en el dossier: modelos de servicio, arquitectura web, diagnóstico de incidencias, comparación de costes y recomendación final. Se evalúan las respuestas y su justificación mediante la rúbrica de la unidad.

Sitio inicial para la unidad de IA

Para Digitalización UD4, descarga el sitio inicial, extrae el ZIP y abre index.html en el navegador. Contiene HTML, CSS y una imagen SVG. Conserva una copia antes de editar. El trabajo se comprueba en local y no requiere publicar la web ni haber creado un sitio en UD3.

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 en Internet.

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 individual y mejora

1. La actividad es individual: registras tus decisiones y explicas su evidencia durante el taller o la revisión. La rúbrica describe la calidad de tu trabajo, y un criterio sin evidencia suficiente queda pendiente de comprobación, sin inferirlo del número de commits.
2. Puedes consultar dudas y contrastar criterios con otras personas, pero la entrega, su comprobación y su explicación son tuyas.
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.