GAC Informática

GAC005 no es un curso de programación. Trata sobre el uso de la computadora para realizar trabajo académico con calidad: encontrar fuentes confiables, escribir en equipo, llevar a cabo un proyecto pequeño y presentar los resultados.

Todo se evalúa según lo que produzcas. Un conjunto típico incluye una tarea de búsqueda y escritura, un proyecto grupal (小组项目) con presentación, un vídeo (视频) y trabajo continuo (平时作业). No hay examen escrito, por lo que los archivos que entregas constituyen la totalidad de la nota.

• El trabajo se juzga tanto por el artefacto como por el proceso. Guarda borradores y notas; un proyecto grupal se califica parcialmente según tu contribución al mismo.
• ⚠ La integridad académica (学术诚信) aplica a los medios tanto como al texto. Una imagen, un gráfico o un clip tomado de la web necesita una fuente y una licencia que permita su uso.

Cualquiera puede encontrar una página. La habilidad que se evalúa es encontrar una fuente que puedas defender.

• Busca con palabras clave (关键词), no con oraciones. Selecciona los sustantivos que deben aparecer en una buena respuesta y omite todo lo demás.
• Los operadores (运算符) acotan la búsqueda: las comillas forzan una frase exacta, el signo menos excluye una palabra y site: restringe los resultados a un solo dominio.
• Evalúa una fuente antes de usarla. La autoridad (权威性) indaga quién la escribió y qué sabe; la actualidad (时效性) indica su antigüedad; el sesgo (偏见) revela la intención del autor.
• Una fuente primaria (一手资料) es material original, como el informe de un experimento. Una fuente secundaria (二手资料) la describe o interpreta, como un artículo periodístico sobre dicho informe.
• Los resultados de búsqueda están clasificados, no verificados: la posición en la página no garantiza precisión.

Ejemplo resuelto. La pregunta es si los autos eléctricos generan menos dióxido de carbono en general que los autos de gasolina. Una búsqueda con la oración completa devuelve páginas de opinión. Una búsqueda con las palabras clave lifecycle emissions electric vehicle comparison devuelve estudios, y al añadir site:gov se restringe a informes gubernamentales cuyos autores y métodos están declarados. La segunda búsqueda no es más inteligente, pero especifica mejor cómo debe verse una respuesta utilizable.

Escribir juntos es una forma normal de trabajar, y el módulo evalúa cómo lo haces.

• Un documento en la nube (云端文档) mantiene una copia única en tiempo real que todos editan, eliminando completamente el problema del "final_v3_really_final".
• El historial de versiones (版本历史) registra quién cambió qué y cuándo. Te protege: tu contribución es visible incluso cuando un archivo parece tener una sola voz.
• Los comentarios (批注) proponen cambios sin aplicarlos; el modo sugerencias (建议模式) propone cambios que el propietario puede aceptar o rechazar. Úsalos en lugar de sobrescribir párrafos ajen os.
• Acuerda la estructura (结构) antes de que alguien escriba. Dividir un documento por secciones funciona; dividirlo por oraciones no.
• Mantén un solo estilo (文体): decide sobre la persona, el tiempo verbal y la ortografía al inicio, y designa a una sola persona para la revisión final.

Un proyecto grupal fracasa con mucha más frecuencia por falta de organización que por falta de capacidad.

• Un enunciado de alcance (范围) define lo que el proyecto hará y lo que no hará. La mayoría de los desbordes de tiempo comienzan con un requisito adicional no escrito.
• Los hitos (里程碑) son puntos de control con fechas. Convierten "tenemos tres semanas" en algo que permite detectar retrasos a tiempo para corregirlos.
• Asigna roles (分工) a personas, no tareas al grupo. Una tarea asignada a todos es responsabilidad de nadie.
• Un acuerdo de equipo (团队协议) registra cómo el grupo se reunirá, tomará decisiones y manejará a un miembro que no cumpla. Escribelo mientras el ambiente sigue siendo amable.
• Rastrea las dependencias (依赖关系): la presentación no puede terminarse antes de recolectar los datos, por lo que los datos tienen la fecha límite anterior.

Ejemplo resuelto. Un proyecto de cuatro personas para encuestar y presentar hábitos de transporte estudiantil, con entrega en la semana 6. Trabajando hacia atrás: ensayo en la semana 6, construcción de diapositivas en la semana 5, análisis en la semana 4, recolección de respuestas en las semanas 2 a 3, redacción de preguntas en la semana 1. Las preguntas son el elemento más riesgoso porque todo lo posterior depende de ellas, por lo que se revisan con todo el grupo y nada más en la semana 1.

Una presentación se juzga por si la audiencia entiende, no por la cantidad de contenido en pantalla.

• Un mensaje (信息) por diapositiva. Si una diapositiva requiere dos oraciones para resumirse, son dos diapositivas.
• Las diapositivas apoyan al ponente. Los puntos clave (要点) son recordatorios, no un guion; leerlos en voz alta es la causa más común de pérdida de nota.
• El contraste (对比度) y el tamaño determinan si quien está en la fila trasera puede leerlo: texto oscuro sobre fondo claro, mínimo 24 puntos, y tipografía sans-serif (无衬线).
• Usa un gráfico (图表) cuando la forma de los datos sea el punto central, y una tabla (表格) cuando los valores exactos sean esenciales. Un gráfico siempre necesita etiquetas de ejes y unidades.
• Cita las fuentes en la misma diapositiva donde aparece el material, y mantén una lista de referencias (参考文献列表) completa al final.

Una vez que el contenido es correcto, queda la exposición.

• Ensaya en voz alta (出声), de pie y con cronómetro. Leer en silencio oculta todas las oraciones que realmente no puedes decir.
• El señalamiento (提示语) guía a la audiencia: "primero", "la razón de esto", "para resumir". En una lengua extranjera cumple más función que cualquier animación de diapositiva.
• El contacto visual (眼神交流) y el ritmo importan más que el vocabulario. Ir más despacio casi siempre es mejor.
• Prepárate para las preguntas (提问) listando las tres que menos te gustaría que te hicieran y respondiendo anticipadamente.
• La animación (动画) tiene un único uso legítimo: revelar un diagrama complejo parte por parte. Todo lo demás distrae.

Un vídeo corto se evalúa como cualquier otro producto académico: planificado, con fuentes y editado.

• Un guion gráfico (分镜脚本) planifica cada toma antes de grabar: qué aparece en pantalla, qué se dice y cuánto dura. Marca la diferencia entre cinco horas de edición y una.
• Un guion (脚本) mantiene un vídeo de dos minutos dentro de ese tiempo. Hablar sin guion lleva tres veces más tiempo y dice menos.
• La calidad de audio (音质) importa más que la calidad de imagen. Una habitación silenciosa supera a una cámara costosa, en todo momento.
• Usa solo material licenciado (授权): imágenes y música bajo licencias que permitan reutilización, con crédito en pantalla o en la descripción.
• Exporta (导出) a un formato común y tamaño razonable, y verifica que se reproduzca en una máquina ajona antes de entregarlo.

Ejemplo resuelto. Un vídeo explicativo de dos minutos sobre reciclaje de plásticos. El guion gráfico tiene ocho tomas de aproximadamente quince segundos. La toma 3 muestra un gráfico de lo que realmente recicla una ciudad, en pantalla durante doce segundos con una sola oración hablada, citando la fuente en la esquina. Como el guion gráfico fijó primero la duración, el guion se escribió para ajustarse al tiempo, en lugar de cortar el vídeo para ajustar un guion que ya era demasiado largo.

GAC011 es el espacio donde construyes y publicas un sitio web real. Seis unidades te guían desde un diseño en papel, pasando por HTML, CSS y JavaScript, hasta la puesta en marcha del sitio y un plan para promocionarlo.

Todo se evalúa según lo que produces: un storyboard y un diseño, el propio sitio web, una estrategia de redes sociales, además de los trabajos prácticos. No hay examen escrito.

• El diseño tiene tanto peso como el código. Los resultados de aprendizaje del módulo nombran la estética, el diseño, la navegación y la usabilidad junto con la programación.
• ⚠ El sitio que diseñes aquí es lo que GAC017 le añade un backend y una base de datos. Un plan débil ahora costará tiempo en el siguiente módulo.

Puedes ejecutar todos los ejemplos de este módulo en el entorno de desarrollo integrado del sitio, y las referencias a HTML, CSS y JavaScript allí profundizan más que estas notas.

• Comienza en papel. Un wireframe muestra la estructura sin color, que es la única forma de debatir sobre la estructura.
• La arquitectura de la información define qué va dónde: las páginas y el camino que sigue un visitante entre ellas.
• La jerarquía visual indica al ojo lo que importa —a través del tamaño, el peso, el espaciado y el contraste, no mediante adornos—.
• Diseña para la audiencia, y define quiénes son antes de elegir cualquier elemento.

• HTML marca el significado, no la apariencia. Un encabezado es <h1> porque es un encabezado.
• Un elemento tiene una etiqueta de apertura, contenido y una etiqueta de cierre; un atributo va dentro de la etiqueta de apertura.
• Los elementos semánticos —<header>, <nav>, <main>, <article>, <footer>— informan al navegador, al motor de búsqueda y al lector de pantalla qué representa cada sección.
• Toda imagen necesita texto alternativo. Es lo que escucha un visitante con discapacidad visual y lo que lee un motor de búsqueda.

• CSS controla la apariencia, y mantenerlo separado del HTML es todo el punto de esa separación.
• Un selector elige elementos; una declaración asigna un valor a una propiedad.
• El modelo de caja explica el diseño: contenido, luego relleno (padding), luego borde (border) y finalmente margen (margin).
• El diseño responsivo hace que una página funcione en un teléfono y en una laptop, generalmente con anchos flexibles y una consulta de medios.

Ejemplo resuelto. Una tarjeta demasiado ancha en un teléfono.

La solución no es un ancho fijo en píxeles. Establece max-width para que la tarjeta nunca supere la pantalla, permítele encogerse por debajo de ese límite, y añade una consulta de medios solo para el cambio que una pantalla más pequeña realmente necesita, como apilar dos columnas en una sola.

Diseñar primero el caso flexible y tratar la consulta de medios como una excepción es lo que significa "responsivo".

• JavaScript se ejecuta en el navegador y modifica la página después de que esta ha cargado.
• El DOM es la página representada como un árbol de objetos que tu código puede leer y modificar.
• Un evento —un clic, un envío de formulario, una pulsación de tecla— activa una función que has escrito.
• Mantén la complejidad baja en este nivel: valida formularios, alterna menús, filtra listas. Un sitio que deja de funcionar cuando falla JavaScript es un error de diseño, no de codificación.

• El hosting coloca tus archivos en un servidor; un nombre de dominio dirige a los visitantes hacia ellos.
• Prueba antes de publicar: cada enlace, en un teléfono, en un navegador que no sea el tuyo.
• La accesibilidad no es opcional —contraste, texto alternativo, navegación por teclado y texto que se pueda redimensionar—.
• ⚠ Verifica qué está permitido publicar. Una imagen o una fuente en tu sitio necesitan una licencia que lo permita, exactamente igual que una cita en un ensayo necesita una referencia bibliográfica.

• Define la audiencia y el objetivo antes de elegir una plataforma. "Estar presente en redes sociales" no es un objetivo.
• Un plan de contenidos dice qué publicarás, con qué frecuencia y quién lo escribirá.
• Las métricas deben vincularse al objetivo: alcance, interacción y clics hacia tu sitio son cosas distintas, y solo una de ellas es tráfico.
• Mide, luego cambia una sola cosa. Cambiarlo todo a la vez no te enseña nada sobre qué cambio funcionó.

GAC017 es el módulo de computación de Nivel III: lo que hay detrás de un sitio web. Seis unidades cubren el back-end JavaScript, bases de datos, SQL, conectar ambos y una primera introducción a la ciencia de datos.

La evaluación es totalmente práctica: una base de datos que tú diseñes y construyas, una aplicación web que se comunique con ella, un proyecto de análisis de datos y tareas continuas, generalmente distribuidas a lo largo de la mayor parte del semestre en lugar de concentrarse al final.

• El trabajo se juzga por si funciona y responde a una pregunta, no por la cantidad de código.
• ⚠ Diseña la base de datos antes de escribir una consulta. Casi todos los problemas posteriores son problemas de tablas disfrazados de consultas.

Cada ejemplo de SQL aquí se ejecuta en el entorno de código propio del sitio, y la referencia de SQL allí es la versión más completa de estas notas.

• El front-end se ejecuta en el navegador; el back-end se ejecuta en un servidor y contiene lo que el navegador no debe ver.
• Un servidor recibe una petición y devuelve una respuesta. Ese bucle es toda la arquitectura.
• Una API es la forma acordada de esas peticiones y respuestas.
• ⚠ Cualquier dato secreto: una contraseña, una clave, pertenece solo al back-end. El código en un navegador es legible por cualquier persona que visite el sitio.

• Una ruta asocia una URL al código que se ejecuta cuando se solicita esa URL.
• Valida la entrada en el servidor. Comprobar en el navegador es una comodidad para usuarios honestos, no una defensa.
• Nunca construyas una consulta uniendo cadenas con entradas de usuario. Así ocurre la inyección SQL, y es la falla de seguridad que esta unidad existe para prevenir.
• Devuelve un estado honesto: 200 para éxito, 400 para una solicitud incorrecta, 404 para algo que no existe.

• Una base de datos relacional 关系数据库 almacena datos en tablas 表 formadas por filas y columnas.
• Una clave primaria identifica una fila de forma única. Una clave foránea apunta a la clave primaria de otra tabla, y ese puntero es la relación.
• La normalización elimina datos duplicados para que un hecho viva en un solo lugar.
• Diseña preguntándote cuáles son las entidades, y luego qué las conecta.

Ejemplo resuelto. Una escuela quiere almacenar estudiantes, cursos y quién cursa qué.

Dos tablas no pueden hacerlo: un estudiante cursa muchos cursos y un curso tiene muchos estudiantes. La relación muchos a muchos necesita una tercera tabla — matrículas — cuyas filas sean pares (estudiante, curso).

Reconocer que se requiere esta tercera tabla es la idea de base de datos más útil del módulo, y es donde suelen fallar los primeros diseños.

• SQL hace preguntas a una base de datos. SELECT … FROM … WHERE … es el núcleo.
• JOIN combina filas de dos tablas mediante una clave coincidente.
• GROUP BY con COUNT, SUM o AVG responde a preguntas de "cuántos por…".
• ⚠ WHERE filtra filas antes de agrupar; HAVING filtra grupos después. Usar el equivocado es el error clásico de SQL, y suele devolver una respuesta plausible pero incorrecta.

Ejemplo resuelto. ¿Qué cursos tienen más de 20 estudiantes?

SELECT c.title, COUNT(*) AS students
FROM enrolments e
JOIN courses c ON c.id = e.course_id
GROUP BY c.title
HAVING COUNT(*) > 20;

El conteo es una propiedad del grupo, por lo que el filtro es HAVING. Escrito con WHERE no se ejecuta — y cuando un error similar sí se ejecuta, responde silenciosamente a una pregunta diferente.

• El back-end toma una petición, ejecuta una consulta parametrizada y devuelve las filas como datos, normalmente en formato JSON.
• Parametrizado significa que los valores viajan separados del texto de la consulta. Eso es lo que hace que la inyección sea imposible en lugar de improbable.
• Maneja el caso vacío. Una consulta que no devuelve filas es normal, y una página que falla por ello no está terminada.

• La ciencia de datos convierte datos en una decisión, y la mayor parte del trabajo ocurre antes de la análisis: limpieza, unión y comprobación de lo que los datos pueden soportar.
• La estadística descriptiva resume; una visualización muestra la forma; ninguno prueba una causa.
• La correlación no implica causalidad — la frase que todo proyecto de datos necesita y que la mayoría omite.
• Declara las limitaciones de tu conjunto de datos. Un proyecto que nombra lo que sus datos no pueden mostrar obtiene mejores puntuaciones que uno que afirma silenciosamente más de lo debido.