Merge branch 'gh-pages' of github.com:JJ/IV into gh-pages

documentos/proyecto/2.Modelo.md

@@ -47,6 +47,14 @@ que hacerse teniendo en cuenta las historias de usuario creadas en el [objetivo
 código que se añada al repositorio *siempre* tiene que añadir valor al cliente
 (cuyos deseos están representados en las historias de usuario).
 
+> En este objetivo se empezará a escribir código. Se **recomienda
+> encarecidamente** que se usen modelos de generación de código con
+> juicio, usándolos solo a nivel de recordar la sintaxis o completar
+> una línea de código y *no* generar conjuntos completos de
+> ficheros. Saber como generar código es fundamental, pero no debe
+> sustituir la comprensión del mismo o saber qué es lo que hay que
+> generar, que es lo que un ingeniero/a debe aprender.
+
 ## Explicación
 
 El convertir los deseos de los clientes en una realidad informática implica una
@@ -239,18 +247,24 @@ implementación deben seguirse una serie de reglas. Algunos consejos pueden ser:
 
 Diferentes conceptos a tener en cuenta:
 
-1. Interfaz vs clase. Un interfaz tiene sólo el API. Algunos lenguajes, como
-   Java o TypeScript, permiten crear interfaces que se tendrán que *implementar*
-   en una clase concreta, sin tener ninguna lógica de negocio.
+1. Interfaz vs clase. Un interfaz tiene sólo el API. Algunos
+   lenguajes, como Java o TypeScript, permiten crear interfaces que se
+   tendrán que *implementar* en una clase concreta, sin tener ninguna
+   lógica de negocio. En general se usan interfaces sólo cuando va a
+   haber varias clases que los implementen de forma diferente, pero a
+   este nivel un interfaz puede reflejar mejor que una clase la
+   funcionalidad que queremos tener en un modelo.
 2. Mutabilidad frente a inmutabilidad: una clase inmutable no permitirá cambiar
    de valor tras su creación; los objetos valor *siempre* son inmutables. A
    veces se denominan "congeladas" (*frozen*) o *dataclasses* (ya que,
    esencialmente, son datos, o sea, objetos que contienen sólo un valor). En
    ocasiones se consigue la inmutabilidad simplemente no permitiendo cambiar
    ningún atributo desde el API de la clase.
-3. En esta mutabilidad se tendrá que tener en cuenta el uso de variables de
-   instancia privadas, así como sólo los *getters* (ningún *setter*). En general,
-   conviene usar lenguajes que tengan en cuenta este tipo de distinción.
+3. En esta mutabilidad se tendrá que tener en cuenta el uso de
+   variables de instancia privadas, así como sólo los *getters*
+   (ningún *setter*, que romperían la privacidad). En general,
+   conviene usar lenguajes que tengan en cuenta este tipo de
+   distinción.
 4. Composición frente a herencia. La programación dirigida a objetos es muy
    rica, y mientras que algunos lenguajes permiten sólo herencia, otros permiten
    composición de *roles* o *mixins* (como Ruby o Raku).
@@ -261,6 +275,33 @@ Diferentes conceptos a tener en cuenta:
    teniendo en cuenta lo que se va a usar en la lógica de negocio, no
    simplemente reflejar los nombres de los atributos de la clase, que son
    detalles de implementación.
+7. *Lo más importante* es que se use lo mínimo la generación de
+   código; lo imprescindible para que te recuerde (o te cuente) la
+   sintaxis específica *una vez que tengas claro qué es lo que hay que
+   hacer*. En general, una persona siempre le va a ganar a una máquina
+   general código porque una persona va a tener en cuenta las
+   diferentes posibilidades que hay, y qué ventajas e inconvenientes
+   tiene cada una. Una IA generativa te va a presentar una solución
+   como la única posible, y te va a impedir que entiendas qué estás
+   haciendo y por qué. Adicionalmente, hay un problema fundamental en
+   las IAs generativas: como son modelos estadísticos entrenados con
+   *todo* el código presente, la solución que te van a generar no va a
+   ser una de las correctas, sino la más común y en muchos casos con
+   versiones obsoletas.
+
+> Finalmente tenéis que recordar que el código que uséis en un PR lo
+> van a revisar compañeros/as vuestros/as y finalmente el profesor. Si
+> retroalimentáis lo que se diga en el PR al modelo, seguirá generando
+> código posiblemente erróneo (porque no tiene presente lo que
+> hicisteis inicialmente) pero genere lo que genere *tú* vas a seguir
+> sin entender lo que estás haciendo. Recordad la capacidad más
+> importante de ingeniero/a: preguntar por qué. En general, una IA
+> generativa te va a responder por qué hace algo con cierta
+> competencia (o va a mentir descaradamente, o a alucinar), pero
+> cuando lleves tres ciclos de generación-corrección-preguntar por
+> qué-más generación-más corrección ¿en serio no te merece la pena
+> consultar el manual de referencia de un languaje o mirar algún
+> tutorial sobre buenas prácticas? ¿No acabarás antes?
 
 Los factores anteriores son comunes a casi todas las aplicaciones, y llevarían
 normalmente a la elección de un lenguaje que tenga comprobación de tipos en
@@ -301,6 +342,12 @@ adicional.
 > Si usas IDEs específicos del lenguaje, como los de IntelliJ, lo más probable
 > es que esto esté todo ya integrado.
 
+Finalmente, debes configurar este entorno de trabajo para que use
+alguna IA generativa integrada como CoPilot (gratis con la cuenta de
+GitHub de estudiante). Una IA generativa es una gran herramienta,
+siempre que la uses para tareas mecánicas y para cosas que ya
+entiendes, no para generar cosas ciegamente desde cero.
+
 ## Información adicional
 
 Se pueden consultar los siguientes temas
@@ -317,12 +364,62 @@ que se ha enlazado antes es bastante extensa, pero justifica bien todas las
 prácticas y las enlaza con otras buenas prácticas como el Single Responsibility
 Principle.
 
+## Planificación del trabajo
+
+En este objetivo hay que comenzar a planificarse, teniendo en cuenta
+ya las dos reglas que se han explicado desde el principio: qué hacer a
+continuación, y si lo que se va a hacer está bien una vez
+completado. Hay que trabajar también con otra persona, así que hay que
+tener en cuenta sus tiempos y disponibilidades a la hora de
+trabajar. En *todos los objetivos* habrá que planificarse, pero en
+este es en el primero que es necesario, así que habrá que hacerlo
+especialmente bien. En concreto, habrá que seguir los siguientes
+pasos.
+
+* Mirar las historias de usuario, que en muchos casos se conocerán ya
+  desde el objetivo anterior, porque se habrá revisado. Estas
+  historias de usuario tienen que ser adecuadas para poder empezar a
+  trabajar. En general será así, porque ya han superado ese objetivo,
+  pero puede que haga falta alguna puntualización. Comentando en las
+  mismas se puede aclarar un poco más; quien haya creado el proyecto
+  tendrá que editarlas hasta que sean adecuadas para comenzar a
+  trabajar.
+* Habrá que decidir un lenguaje de programación adecuado al proyecto,
+  pero también con el que se sientan cómodas las dos personas
+  involucradas en esta fase. En estad dos fases tendrán que estar las
+  dos involucradas
+* Lo siguiente es plantear una serie de problemas/issues que, a partir
+  de las historias de usuario, se planteen con los diferentes
+  conceptos que se mencionen en las mismas. Es posible que haya una
+  cascada, cada issue/problema relacionado con el anterior, pero
+  también que sean independientes. Eventualmente, se llegará a una
+  descripción de un problema que sea fácilmente resoluble mediante
+  código usando el tipo más simple en DDD, un *objeto-valor*.
+* Se resuelve ese issue escribiendo el código correspondiente. Se
+  puede crear el PR en ese momento, para que quien haya creado el
+  proyecto pueda dar retroalimentación.
+* Una vez hecho eso, se podrán resolver el resto de los problemas
+  descritos.
+* Una vez resueltos todos (o una cantidad razonable), se solicita al
+  propietario/a revisión.
+
+Desde el punto de vista del propietario/a, se puede ayudar a quien
+cree el código comentando en el PR que cree, o bien en los issues, o
+incluso editando las historias de usuario adicionalmente si se ve que
+no es suficiente para resolver los issues. *Toda la descripción del
+problema tiene que estar en las historias de usuario*. Las historias
+de usuario deben responder a la pregunta "si lo que se hace está
+bien", no el propietario/a. En ingeniería del software, se trata de
+que se cree el código de la forma más autónoma posible, con tests
+basados en las historias de usuario, no en que alguien diga si está
+bien o mal.
+
 ## Entrega de la práctica
 
 Todo el material para este objetivo se tiene que desarrollar, como siempre, en
 una rama. Desde esta rama se hará un pull request a la rama principal del
 repositorio propio del estudiante. **Importante**: el título de este *pull
-request* **tiene* que incluir la cadena `[IV-23-24]` para que puedan filtrar
+request* **tiene* que incluir la cadena `[IV-24-25]` para que puedan filtrar
 fácilmente los mensajes recibidos. Cuando se hagan mejoras en el PR, el
 estudiante deberá pedir explícitamente revisiones adicionales con un comentario
 en el mismo que diga "Listo para revisión".
@@ -333,7 +430,7 @@ fusionar). Cuando se haga, se etiquetará a JJ en un comentario donde se diga qu
 está listo para revisión.
 
 A este
-[fichero](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-2.md) se
+[fichero](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-2) se
 subirá (mediante un PR *desde una rama*) el nombre del proyecto, el autor y un
 enlace al pull request creado en el repositorio.
 

documentos/proyecto/3.5.tests.md

@@ -2,6 +2,11 @@
 layout: index
 
 
+---
+---
+layout: index
+
+
 ---
 # Crédito extra: probar, mejorar y ampliar los tests de otro proyecto
 

documentos/proyecto/3.Automatizar.md

@@ -166,13 +166,11 @@ este tipo de instrumentación en algún *milestone*.
 
 El material del [curso cero](https://jj.github.io/curso-tdd) incluye
 varios temas relacionados con el desarrollo basado en test. Se
-recomienda encarecidamente que se entiendan los conceptos, antes de proceder a
-hacer el trabajo relativo a este objetivo en si.
-
-* Sobre los
-  [*task runners*](https://jj.github.io/curso-tdd/temas/gestores-tareas.html) o
-  gestores de tareas.
-
+recomienda encarecidamente que se entiendan los conceptos, antes de
+proceder a hacer el trabajo relativo a este objetivo en
+si. Adicionalmente, se puede consultar este trabajo sobre los [*task
+runners*](https://jj.github.io/curso-tdd/temas/gestores-tareas.html) o
+gestores de tareas.
 
 ## Lista de comprobación
 
@@ -205,7 +203,7 @@ completas y correctas?
 
 Se tendrá que haber actualizado el repositorio que se usara en los objetivos
 anteriores y [añadir al fichero de este
-objetivo](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-3.md) el
+objetivo](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-3) el
 nombre del proyecto, el autor y un enlace al mismo y hacer un **pull request**.
 
 La descripción del proyecto tiene que seguir progresando, así que el

documentos/proyecto/5.Docker.md

@@ -109,6 +109,19 @@ puede optar o no, por tanto, por usarlo, pero lo que hay que tener en cuenta es
 que las bibliotecas estarán *dentro* del contenedor, y los fuentes *fuera* del
 mismo, en un directorio donde *no hay derechos de escritura*.
 
+**Aviso**: este es un caso en el que las IAs generativas pueden
+generar automáticamente el Dockerfile completo, *y sistemáticamente lo
+hacen mal*, sin seguir las buenas prácticas habituales, con versiones
+aleatorias o deprecadas y en general en disonancia con lo que se pide
+en la ingeniería de software. Aunque la asignatura está diseñada para
+que si se envía algo que no cumpla todas las condiciones se explique
+al estudiante qué problemas hay a través del PR, se ahorrará bastante
+trabajo tanto al estudiante como a los otros estudiantes que revisen
+el PR como al profesor si se hace *a mano* siguiendo el manual o algún
+tutorial, entendiéndose así mejor las diferentes partes del Dockerfile
+y por supuesto la retroalimentación en el PR y cómo construir otros
+más complejos.
+
 ## Lista de comprobación
 
 Recuerda que hay que copiar y pegar en el PR de tu repositorio, y marcar lo que

documentos/proyecto/5.Serverless.md

@@ -2,6 +2,11 @@
 layout: index
 
 
+---
+---
+layout: index
+
+
 ---
 # Quinto Hito: Uso de sistemas *serverless*
 

documentos/proyecto/6.CI.md

@@ -16,14 +16,15 @@ integración continua y configuración del mismo.
 
 ## Prerrequisitos
 
-Haber superado el [objetivo anterior, contenedores](5.Docker).
+Haber superado los tests en el [objetivo anterior, contenedores](5.Docker).
 
 ## Explicación
 
 En sistemas de desarrollo ágil quien desarrolle tiene que asegurar que
 el código pasa todos los tests antes de ser desplegado o simplemente
 incorporado a la rama principal, porque los tests son la especificación
-de los requisitos. Para ello se escriben una serie de tests que se
+de los requisitos expresados en la historia de usuario. Para ello se escriben
+una serie de tests que se
 ejecutan automáticamente al añadir o modificar código o cuando se
 solicite un *pull request*. Estos tests tienen el fin obvio de
 asegurar la calidad del mismo (via implementación de las pruebas para
@@ -58,8 +59,19 @@ Preparar un proyecto para integración continua implica varias cosas:
   API*](https://docs.github.com/en/rest/reference/checks).
 
 Esta fase de integración continua es esencial para el posterior
-despliegue en un PaaS o IaaS sobre el que se probarán técnicas de despliegue
-continuo.
+despliegue en la nube sobre el que se probarán técnicas de despliegue
+continuo (será el último objetivo de la asignatura).
+
+**Aviso**: este es un caso en el que tanto el mismo GitHub como
+CoPilot pueden generar automáticamente el fichero de workflow
+completo, *y sistemáticamente lo hacen mal*. Aunque la asignatura está
+diseñada para que si se envía algo que no cumpla todas las condiciones
+se explique al estudiante qué problemas hay a través del PR, se
+ahorrará bastante trabajo tanto al estudiante como a los otros
+estudiantes que revisen el PR como al profesor si se hace *a mano*
+siguiendo el manual o algún tutorial, entendiéndose así mejor las
+diferentes partes del *workflow* y por supuesto la retroalimentación
+en el PR y cómo construir otros más complejos.
 
 ## Lista de comprobación
 
@@ -89,7 +101,7 @@ misma versión en CI y en el contenedor Docker en otro sistema CI?
 
 Se tendrá que haber actualizado el repositorio que se usara en los hitos
 anteriores y añadir al
-[fichero de este objetivo](https://github.com/JJ/IV-21-22/blob/master/proyectos/objetivo-6.md)
+[fichero de este objetivo](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-6)
 el nombre del proyecto, el autor y un enlace al mismo y hacer un **pull
 request**. El PR tendrá que estar en un milestone/PMV, y por supuesto este
 tendrá que incluir como parte lo que se haya creado en este objetivo.

documentos/proyecto/6.Microservicio.md

@@ -2,6 +2,11 @@
 layout: index
 
 
+---
+---
+layout: index
+
+
 ---
 # Sexto hito: Diseño y test de un microservicio
 
@@ -13,7 +18,7 @@ anterior y cumpliendo los requisitos de las historias de usuario.
 ## Prerrequisitos
 
 Haber alcanzado el 60% de
-los [objetivos del tema correspondiente](../temas/Microservicios.md)
+los [objetivos del tema correspondiente](../temas/Microservicios)
 tras haber realizado los ejercicios propuestos (hasta el bloque 4 de
 ese tema). Haber superado el hito anterior de la práctica.
 
@@ -165,4 +170,4 @@ ruta que se indicó en el [hito 1](1.Infraestructura).
 ## Reenvío
 
 Si ya se ha entregado y corregido la práctica y se quiere subir nota,
-[se reenviará siguiendo estas instrucciones](Reenvios.md).
+[se reenviará siguiendo estas instrucciones](Reenvios).

documentos/proyecto/7.Final.md

@@ -2,6 +2,11 @@
 layout: index
 
 
+---
+---
+layout: index
+
+
 ---
 # Hito 7: Despliegue desde cero de una aplicación en la nube
 
@@ -13,7 +18,7 @@ plataformas de producción.
 ## Prerrequisitos
 
 Haber alcanzado el 50% de los objetivos de los temas de
-[gestión de infraestructuras](../temas/Gestion_de_configuraciones.md). Sin este
+[gestión de infraestructuras](../temas/Gestion_de_configuraciones). Sin este
 requisito este hito del proyecto estará suspenso. Evidentemente, tendrán que
 estar aprobados todos los hitos anteriores.
 
@@ -25,7 +30,7 @@ provisione la máquina virtual, se despliegue la aplicación y se
 arranque la misma.
 
 En la asignatura se ha visto como
-[provisionar las aplicaciones y servicios necesarios y hacerlo de forma ágil y reproducible](../temas/Gestion_de_configuraciones.md).
+[provisionar las aplicaciones y servicios necesarios y hacerlo de forma ágil y reproducible](../temas/Gestion_de_configuraciones).
 
 Este hito es el que concluye la asignatura. La documentación para que cualquier
 usuario pueda llevar a cabo el despliegue del mismo debe estar en un solo
@@ -54,7 +59,7 @@ relacionadas con el mismo (inclusive esta automatización) creada.
 ## Entrega de la práctica
 
 Por otro lado, la entrega se hará de la forma habitual, modificando el
-[documento](https://github.com/JJ/IV-19-20/blob/master/practicas/hito-7.md)
+[documento](https://github.com/JJ/IV-19-20/blob/master/practicas/hito-7)
 y haciendo un *pull request* de la forma habitual.
 
 Los elementos de la práctica se tendrán que hacer constar en el

documentos/proyecto/7.PaaS.md

@@ -2,6 +2,11 @@
 layout: index
 
 
+---
+---
+layout: index
+
+
 ---
 # Séptimo hito: Despliegue de una aplicación en un PaaS
 

documentos/proyecto/7.Servicios.md

@@ -52,7 +52,7 @@ también integrándolo en un PMV.
 
 Del [curso 0](https://jj.github.io/curso-tdd) se puede consultar el
 material sobre [servicios avanzados en
-informática](https://github.com/JJ/curso-tdd/blob/master/temas/servicios.md).
+informática](https://github.com/JJ/curso-tdd/blob/master/temas/servicios).
 
 La configuración es un ejemplo de dependencia que debe estar desacoplada, por lo
 que se aconseja que se mire [el tema de inversión de
@@ -81,7 +81,7 @@ importantes?
 
 Subir los fuentes a GitHub y hacer un *pull request* al
 [fichero de este
-objetivo](https://github.com/JJ/IV-21-22/blob/master/proyectos/objetivo-7.md). En
+objetivo](https://github.com/JJ/IV-/blob/master/proyectos/objetivo-7). En
 el fichero `iv.yaml` habrá que añadir la clave `configuracion` que use como
 valor el fichero en el que se haya abstraído la configuración de la aplicación.