Sync documentos/proyecto/9.Microservicio.md de master a gh-pages

documentos/proyecto/9.Microservicio.md

@@ -8,54 +8,46 @@ layout: index
 ## Descripción
 
 Se trata de implementar el API REST para nuestra aplicación que se haya diseñado
-en el objetivo anterior..
+en el objetivo anterior.
 
 ## Prerrequisitos
 
 Haber pasado los tests del [objetivo anterior, diseño de REST](8.REST).
 
 ## Explicación
 
-Sobre la base de la clase o funcionalidad hecha en la práctica
-anterior, en este hito lo esencial es diseñar una API consistente en
-una serie de rutas (en el caso de un API REST) o tareas (en el caso de
-un microservicio basado en eventos) y testearlo exhaustivamente usando
-una biblioteca específica que te provea el microservicio o bien una
-biblioteca genérica, y crear la infraestructura necesaria para
-comenzar a ejecutarlo.
+Después de diseñar las rutas, es necesario implementarlas, y como en todo
+código, hay que testear todos los aspectos posibles usando herramientas de test
+automático.
 
 En cuanto a este último, se debe de usar el mismo fichero de
-<<<<<<< HEAD
 construcción que se haya usado en el hito anterior, siempre que se
 hayan usado las mismas tareas que se van a testear.
 
 * `build` hará una compilación o transpilación, o en general generará
   los ficheros que se vayan a desplegar efectivamente, que en muchos
-  casos no serán los mismos que los que hay en el repositorio.
+  casos no serán los mismos que los que hay en el repositorio. Sólo será
+  necesaria en caso de que haya que compilar o transpilar parte de los fuentes;
+  en la mayoría de los lenguajes interpretados no siempre se usa (aunque en
+  muchos casos se usan `bundlers` para integrar todos los fuentes en un solo
+  fichero junto con las dependencias, que será más fácil de desplegar).
 * `install` instalará esos ficheros en un lugar donde se vayan a
-  ejecutar, o hará otro tipo de instalaciones.
+  ejecutar, o hará otro tipo de instalaciones; este paso es alternativo al
+  anterior en la mayoría de los lenguajes intepretados.
 * `test` ya estará ejecutándose desde antes, salvo que ahora se
   incluirán también tests de integración.
 
-Los dos primeros casos no hacen falta en muchos lenguajes de
+Los dos primeros casos no hacen falta juntos en muchos lenguajes de
 programación; en ese caso se puede sustituir el objetivo por un
 `no-op` que no haga nada.
-=======
-construcción que se haya usado en el hito anterior,
-añadiendo una tarea `start`, que suele ser estándar para
-arrancar. Esto también permite, por ejemplo, usar uno de los sistemas
-de integración continua que se hayan creado para hacer una ejecución
-de prueba, en vez de ejecutar los tests. En general, todas las tareas
-que se ejecuten desde el sistema de integración continua deberán
-lanzar órdenes de esta herramienta que ejecute tareas.
->>>>>>> 71deec94eab48f12a8064d1329227bc9f04ad87b
-
-Como ya el proyecto ha llegado a un estado en el cual se puede
-desplegar como un servicio web, habrá que documentar cómo las rutas se
-ajustan a las historias de usuario que se hayan planteado desde el
-principio. No hace falta que en este punto todos los tests e historias
-estén implementadas, pero sí las suficientes para que se puedan llevar
-a cabo estos tests de integración.
+
+Como ya el proyecto ha llegado a un estado en el cual se puede desplegar como un
+servicio web, habrá que documentar cómo la implementación de las rutas se ajusta
+a las historias de usuario que se hayan planteado desde el principio (la
+justificación de la ruta en sí y sus nombres se habrá hecho ya en el
+anterior). No hace falta que en este punto todos los tests e historias estén
+implementadas, pero sí las suficientes para que se puedan llevar a cabo estos
+tests de integración.
 
 > Se recuerda que en este caso, la integración de la que se habla es
 > la de otras bibliotecas que dependan de la clase o clases que sean
@@ -75,9 +67,9 @@ de
 
 ## Entrega de la práctica
 
-Subir los fuentes a GitHub y hacer un *pull request* al documento que
-describa las prácticas y que se anunciará en la web de la
-asignatura.
+Habrá que subir los fuentes a GitHub y hacer un *pull request* al documento que
+describa las prácticas y que se anunciará en la web de la asignatura como es
+habitual.
 
 Para los tests, se descargará el repositorio y se
 ejecutará ese comando con tres targets en secuencia de esta forma:
@@ -100,32 +92,22 @@ que se ejecutarán a continuación.
 > en general el target que se suele usar para instalar las
 > dependencias es `installdeps`.
 
-En ninguno de ellos tendrá que dar error. También se comprobará
-(aunque ya se hace en el hito anterior) que pasen los tests en Travis
-que se usará para ejecutar los tests de integración.
+En ninguno de ellos tendrá que dar error. También se comprobará (aunque ya se
+hace en el hito anterior) que pasen los tests que se usará para ejecutar los
+tests de integración.
 
 ## Objetivos
 
 Tras la implementación de las rutas que se hayan planteado en el objetivo
  anterior, se tendrá que cubrir con tests de integración las rutas creadas y sus
  diferentes posibilidades (de acuerdo con las HUs que se hayan creado).
 
-Si la aplicación no funciona o hay plagio o trabajo en común, *la
-  práctica estará suspensa*.
-
 Se recuerda también que este es un hito de un proyecto, y como tal los
 tests para este hito incluyen los de todos los anteriores; el proyecto
 tendrá que seguir desarrollándose de acuerdo a lo indicado en el hito
 anterior y tener como mínimo la estructura que se creó en el
 hito 1.
 
-Se recuerda la política de plagios en esta asignatura: si una parte
-del código y la funcionalidad está copiada o de un tutorial o de otro
-estudiante, la práctica estará suspensa y en caso de reincidencia se
-podrá suspender la asignatura en la convocatoria ordinaria. La forma
-de asegurarse de que no es así es simplemente seguir las historias de
-usuario que se hayan creado desde el principio, incluyendo la hoja de
-ruta que se indicó en el [hito 1](1.Infraestructura).
 
 ## Valoración