before_install no hace nada e install realmente tampoco. Las versión de perl no coincide con la del script de tests.

Un poco de aquí

E introducirla antes de llegar a los microservicios, de forma que cuando se lancen los microservicios tengan ya diferentes fuentes de datos.

El path que comprueba está mal. Los ficheros no se llaman hito-*.md

Por ejemplo, tipado, compilado/interpretado.

• Los ejemplos no reflejan casos de uso y son más bien arbitrarios.
• El uso interno del contenedor tampoco explica bien para qué se puede usar y el caso de uso correspondiente.
• Documentar mejor buenas prácticas.

Desde no sumar 10, hasta usar algunas malas prácticas que ya se vio en IV que no eran buena idea.

En el tema relativo a contenedores, los ejercicios 6 y 7 tratan sobre un mismo tema, de forma que la realización del ejercicio 6, implica la realización del ejercicio 7, por lo que el ejercicio 7 no se trata de un ejercicio sino de una parte del ejercicio 6.

Incluir en el hito siguiente (y posiblemente en los sucesivos) una referencia explícita a la estructura del mismo.

Extenderlos con roles y diferentes órdenes, y añadir más ejemplos.

Poder hacer pruebas de staging en local con Docker Compose. Antes o después de Heroku. Posiblemente antes.

Al menos su uso como key-value store

Conceptos como API gateway, configuraciones distribuidas, sistemas de logs... Relacionado con #19

Me gustaría añadir ejemplos en otros lenguajes y también para otros sitios de integración continua. Tambien revisar enlaces, ortografía, gramática, y todo eso. El primer capítulo está aquí: http://jj.github.io/CC/documentos/temas/Desarrollo_basado_en_pruebas, pero la edición se hace desde https://github.com/JJ/CC/blob/master/documentos/temas/Desarrollo_basado_en_pruebas.md

Para entrar en harina en otras cosas más interesantes de virtualización. Si se queda el de PaaS, que sirva como introducción para trabajar con sistemas cloud como Azure.

El documento
El documento en github pages

Y posiblemente eliminar la introducción.

Que ha sido anunciado aquí y se han publicado instrucciones sobre cómo tenerlo en cuenta aqui

Para que se vea bien claro que no se puede escribir en él, ni aunque se tenga privilegios para hacerlo.

Aquí un pequeño resumen del proceso seguido para levantar el primer contenedor LXC:

Tras instalar LXC en Arch junto con el paquete arch-install-scripts (que sugiere en la documentación de Arch que se instale) con los comandos:

pacaur -S lxc
pacaur -S arch-install-scripts

Lo primero que observamos es que, como dice en la documentación anteriormente nelazada, los namespaces de usuario no aparecen como disponibles cuando comprobamos con lxc-checkconfig, esto es aparentemente por un motivo de seguridad de Arch lo que nos obliga a ejecutar los comandos con sudo al parecer.

Una vez hecho esto al intentar crear una máquina con Ubuntu con el comando sudo lxc-create -t ubuntu -n una-caja nos daba un error indicando que no podía ejecutar el comando debootstrap, con lo que lo hemos instalado por medio del comando sudo pacman -S debootstrap.

Una vez hecho esto, y tras un tiempo de espera, se ha configurado un contenedor con Ubuntu que arrancamos son sudo lxc-start -n una-caja y a la que nos ponemos conectar con sudo lxc-console -n una caja. Al hacer esto antes de pulsar ENTER que nos iniciará la consola de dicho contenedor, hemos de fijarno que cuando queramos salir de dicha consola hemos de emplear Ctrl+a q, si empleamos el comando exit lo único que haremos será "salir" de la máquina y aparecerá de nuevo la petición de usuario y contraseña para volver a entrar en ella.

Sería interesante añadir también a este repo un linter de markdown para que se ejecute en un workflow, al igual que se hizo en el repo de IV.

Buenas prácticas, qué estados son importantes (y cuales evitar), cómo y cuando usar las cabeceras...

La página web de esto debería estar entre las tres primeras, pero está la séptima. Hasta forks de otros años están por encima. Tratar de ver qué es lo que pasa y mejorar un poco el ránking.

Parece que no se desarrolla desde hace años. El repo del ejemplo no compila. Es posible que haya que usar una versión antigua de Java, pero en cualquier caso no es un sistema en desarrollo activo y es mejor dejarlo.

Aunque es necesario conocer qué arquitecturas vamos a tratar, decir qué arquitectura se elige en realidad no se relaciona por parte del estudiante con las historias de usuario que vaya a usar. Además, la arquitectura al final está condicionada por las historias de usuario, así que hasta que no existan esas HUs es muy difícil decidir por la arquitectura. En realidad, en los primeros hitos se crea la lógica básica de negocio, y sólo en el momento de conectar a datos o a otros servicios se debería de concretar si se van a usar microservicios, tareas, serverless, instancias monolíticas y qué servicios externos se van a conectar.

Aparte de hacer algunas comprobaciones locales, preguntaría una serie de cosas tales como

• ¿Has enviado los objetivos correspondientes?
• ¿Has cubierto todas las rúbricas y las has enlazado claramente?
• ¿Has avanzado tu proyecto desde el hito anterior?

A partir de ahí podría crear un PR sólo si se cumplen todas las condiciones y pasan los tests locales; también si se responde que no a alguna de las cosas anteriores se podría indicar qué hacer para cumplirlos. Habría que tener un cliente que tuviera actualizaciones constantes desde las sesiones (para los objetivos) y los guiones.

Siempre que se sigan las directrices, y no incluya código real, sino simplemente una definición de clase o clases que compile y que muestre que el API y los tipos de datos definidos representan un avance hacia la solución de las historias de usuario.

Y cómo documentar el proceso de decisión.

Añadir enlaces a posibles issues y actualizar las hojas de estilo quitando legacy

Crear ejemplos más reales, por ejemplo. Comprobar que todo funciona en las últimas versiones.

Porque quizá el PaaS no sea tan necesario...

Aparte de regenerar la web

La valoración del hito 2 está sobre 9

Dejar más claro y entrar más suavemente en el desarrollo ágil, con las diferentes partes del mismo: fases del desarrollo ágil, qué es la planificación de un proyecto, cómo se plantea un proyecto y todo eso.

Del hito de Microservicios pasaremos al de PaaS, en el que habrá que tener una single source of truth con un almacén de datos. Heroku permite crear almacenes de datos con Postgres y Redis, así que no hay mucho problema al respecto.

Ahora mismo son metadatos en un comentario al principio del tema que se tratan en un hook. Sería más fácil (y no habría que reeditarlo todo) que se hiciera en un fichero externo, de forma que sólo hubiera que cambiar este. Además, se evitarían inconsistencias (y se podría generar automáticamente la secuencia en el README)

Vagrant ya no se usa más que en casos muy especiales. Es mejor eliminarlo, o dejarlo como un seminario si acaso.

Como ejemplo de posibles arquitecturas. Relacionado con #36 y #19 (que está abierto permanentemente)

De forma que sean más "atómicos" y se puedan configurar fácilmente, así como compartir entre CC e IV. En general, separar por temática, no por temas de la asignatura.

Posibles mejoras:

• Mejoras gramaticales, o de explicación de algún concepto.
• Añadir enlaces a tutoriales, vídeos de Youtube, artículos o presentaciones
• Añadir ejemplos en diferentes lenguajes de programación.

Este capítulo publicado está aquí: http://jj.github.io/CC/documentos/temas/Arquitecturas_para_la_nube, pero la edición se hace desde https://github.com/JJ/CC/blob/master/documentos/temas/Arquitecturas_para_la_nube.md

Dentro del tema de Microservicios, en el ejercicio 2 se propone lo siguiente:

Realizar una aplicación básica que use express para devolver alguna estructura de datos del modelo que se viene
usando en el curso.

Se podría especificar de manera que se entienda el ejercicio sin necesidad de realizarlo únicamente con Node.js y Express.

Con el objetivo de mejorar en la segunda entrega.

Sobre todo con vistas al hito 1, si es que sigue en el estado actual.

Comenzar con Vagrant y continuar a partir de ahí.

Como este repositorio es un trabajo evolutivo en tiempo (cada curso escolar), recomendaría adaptar los enlaces de los archivos Markdown de "enlace inmediato" a "enlace referenciado", es decir:

# "Enlace inmediato"
Los criterios generales que figuran en la [guía docente](***) son los siguientes

# "Enlace referenciado"
Los criterios generales que figuran en la [guía docente][***] son los siguientes
···
···
[guia-docente]: ***

Esto permitiría definir los enlaces en un lugar más apropiado, como sea el final de la sección o capítulo, así como más fácil mantenerlos actualizados.

Para más información, consulta la documentación de CommonMark, un intento de estandarizar Markdown.

Tales como separation of concerns, creación de capas de abstracción, everything-as-code, combinando SOLID y otros principios.

Reportado por @mgarenas