He utilizado Javascript, ya que es un lenguaje ampliamente popular y que para mí es totalmente nuevo. Aunque por lo que he podido leer es un lenguaje bastante sencillo, rápido y muy versátil. Otra de sus famosas ventajas es que es multiplataforma y además es muy útil para desarrollar páginas dinámicas y aplicaciones web.

Todo lo relacionado con esta explicación se encuentra en este enlace.

He elegido Npm, el cual es el gestor por defecto para Node.js y además un entorno de ejecución para Javascript. También lo he utilizado como herramienta de construcción, además este gestor funciona a través de un fichero JSON, ya que se realiza un seguimiento de módulos instalados. En este fichero se contendrá información del proyecto, tal como el nombre, descripción, autor, etc.

De momento es una herramienta de construcción muy simple, dispone de funciones que por ahora abarcan todas nuestras necesidades, tales como instalar las distintas dependencias, módulos, paquetes y la ejecución de scipts, que por ahora solamente es testing. Además su metodología de programación es bastante sencilla, funciona como ya dije junto con un fichero JSON, el cual contiene:

• Todos los módulos necesarios para un proyecto y sus versiones instaladas.
• Todos los metadatos de un proyecto, como el autor y la licencia, entre otros.
• Secuencias de comandos que se pueden ejecutar para automatizar tareas del proyecto.

Los archivos JSON correspondientes: package.json y package-lock.json.

Todo lo relacionado con esta explicación se encuentra en este enlace.

Si no está 'testeado', está roto. Para llevar a cabo los test, he escogido Jest, el cual es un marco de prueba de JavaScript bastante sencillo de entender. Taskfile apuntará a util.test.js, el cual será ejecutado mediante package.json. JSON interviene en esta sección mediante la gestión de la instalación de dependencias con el comando npm install --save-dev jest. Se tendrá que modificar la parte de scripts para poder ejecutar npm test.

No podemos considerar a los test como una herramienta, ya que se interpreta a los test como parte integral del proceso de desarrollo y el código. Aun así, Jest es un framework de testing generalista que podemos utilizar en cualquier situación, en el cual podemos crear, ejecutar y estructurar pruebas. El lado positivo de estas pruebas es que puedes tener control sobre el funcionamiento de lo que estás creando, puedes incluso realizar diferentes tipos de pruebas a un mismo bloque de código y de esta manera puedes saber que tan susceptible es esa parte de código.

La principal ventaja es que supone un buen flujo de trabajo con Npm y Node. Además posee una gran documentación y comunidad, lo cual hace más fácil y ágil su aprendizaje. Tampoco hace falta una biblioteca de aserciones, ya que está incluida.

Todo lo relacionado con esta explicación se encuentra en este enlace.

Se ha creado el Dockerfile y .dockerignore siguiendo las recomendaciones de buenas prácticas. También se ha creado la build correspondiente en mi perfil de Dockerhub.

Estos son los contenedores que he podido probar localmente:

Contenedor Base	Tiempo de Construcción	Tiempo de Ejecución (testing)	Tamaño
node:14-stretch	109.3s	14.91s	978MB
node:14-buster	26.7s	15.884s	947MB
alpine:3.12	12.4s	13.592s	90.5MB
node:14-slim	14.2s	14.382s	202MB

Al principio he usado buster y la versión stretch, ya que son contenedores que lo tienen todo, aunque buster más nuevo, debido a que es la versión Debian 10. Al ser por así decirlo una versión genérica te incluye todas las necesidades, aunque el tiempo de construcción y el tamaño es bastante desfavorable. Por lo que me he inclinado en versiones más slim, en la cual la más ventajosa es 14-slim, ya que tarda muy poco en construirse y el tamaño de la imagen también es bastante pequeño, aun así, incluye todo lo necesario para el funcionamiento. También he utilizado una versión no oficial que incluía únicamente node (mhart/alpine-node:slim).

Aunque finalmente me he decantado por la versión Alpine, ya que es muy ligera, pese a que utiliza /bin/sh como shell, apk como packagemanger y algunas librerías inusuales. Esta imagen es mucho mejor, ya que aunque hayamos quitado YARN en como mejora de optimización en node:14-slim (aquí el commit correspondiente), la imagen ubuntu sigue ocupando bastante espacio. Por lo que al utilizar alpine, su última versión disponible, nos ahorramos bastante espacio. También borramos la caché y los archivos JSON innecesarios.

Se ha utilizado node como usuario, ya que no se necesita realizar instalaciones como superusuario, todo esto por motivos de seguridad. Posteriormente se ha utilizado también una optimización de la imagen limpiando la caché de npm, además de hacer un clean install. También se ha removido archivos no necesario, como los JSON. Otros ejemplos de optimización vienen siendo el uso de herramientas como squash o podman.

DockerHub

Se ha configurado y automatizado DockerHub:

GitHub Container Registry

Se ha configurado y enlazado GHCR:



Ejecución y prueba:

        docker pull nikitastetskiy/micro-calendario
        

        docker run -t -v `pwd`:/test nikitastetskiy/micro-calendario
        

Si usamos GitHub Container Registry:

        docker pull ghcr.io/nikitastetskiy/micro-calendario:latest
        

        docker run -t -v `pwd`:/test ghcr.io/nikitastetskiy/micro-calendario:latest
        

Todo lo relacionado con esta explicación se encuentra en este enlace.

• Travis: se ha configurado el fichero travis, siguiendo las buenas prácticas, de tal manera que pueda ejecutar los test junto al docker que ya teníamos implementado anteriormente. También se ha añadido una pequeña integración continua en el mismo archivo, esto se realiza mediante deploy y pages, el cual hace que se me actualice gh-pages autómaticamente.

• Shippable: se ha configurado el fichero shippable de una manera muy parecida a travis, pero ahora en vez de utilizar el docker, se ha utilizado directamente node para comprobar los test.

• GitHub actions - workflow: se ha configurado el fichero ghcr y el fichero linter-prettier. El fichero ghcr se ha utilizado para publicar un paquete docker en la parte de packages de github, testea el contenedor docker y se publica. El fichero linter-prettier se usa para corregir la sintaxis y el estilo del código con reglas definidas por mí y configuraciones generales.
Todo lo relacionado con las pautas de creación y configuración se encuentra en este enlace.

• Vercel: todo lo correspondiente a la instalación y configuración de Netlify o Vercel se encuentra en el repo ejercicios-IV, aunque lo único que tenemos que hacer es conectarnos con github en la plataforma Vercel. Posteriormente elegir y importar el código fuente de nuestro proyecto. Finalmente para enlazar el proyecto y nuestro directorio de trabajo, lanzamos vercel y lo configuramos, es decir lo linkeamos a nuestra plataforma de Vercel. Así pues cada vez que hagamos push se desplegará en estado production, aunque también podemos desplegarla antes como dev o hacer deploy para tener una preview de su funcionamiento. Gracias a este sistema he podido automatizar las funciones serverless. En su historia de usuario podemos ver todos los pasos seguidos para que este sistema funcione correctamente. Para su funcionamiento primero me he creado la cuenta y agregado el repositorio de la asignatura. Luego he inicializado Vercel en mi repo y he agregado la carpeta api y el archivo vercel.json para la configuración. En la carpeta se encuentran las distintas funciones. El archivo de configuración se ha realizado debido a que solo quiero que sean accesibles distintas rutas del proyecto y que solamente se use los métodos GET y POST. Como función serverless, primero he realizado un Hola Mundo el cual también funciona cuando accedemos a la raíz del proyecto. La segunda función devuelve un string en formato JSON con una fecha introducida por el usuario. Aunque la fecha a devolver tendrá un formato diferente al introducido. El archivo 5.json contiene lo mismo que si hacemos la petición a Vercel. El código de la segunda función está comentado y explicado.

• Netlify: todo lo correspondiente a la instalación y configuración de Netlify o Vercel se encuentra en el repo ejercicios-IV. Aunque igual que en Vercel, para que se nos actualice y haga build en cada push a GitHub lo que tenemos que hacer es registrarnos con nuestra cuenta, inyectar Netlify a nuestro repositorio y una vez hecho esto, inicializamos Netlify en el directorio del repo y linkeamos nuestro proyecto con el que tenemos en Netlify. Para la implementación de Netlify también me he basado en varias funciones, en este caso template, la primera de ellas es un Hola Mundo para poder probar el funcionamiento correcto del intercambio de datos en Netlify. Luego he probado la funcion Protected, la cual devuelve un JSON con el formato de salida "NOT ALLOWED" en caso de no identificar al usuario. He usado el redireccionamiento adecuado para esta situación en caso de que se quiera acceder a cualquier otro sitio que no sean las funciones implementadas. Finalmente también he implementado GraphQL, el cual nos facilita la consulta y manipulación de datos. He pensado que sería una opción interesante controlar las peticiones desde el cliente y no del servidor, como pasa en Rest. De esta manera podemos definir lo que pedimos. De momento solo están implementadas unas funciones básicas en las que pedimos un query endpoint Hola Mundo y varios types de Autores que ante la petición devuelven un JSON, aunque en un futuro podemos definir esta función para la consulta de eventos por fechas específicas o eventos.

• Telegram bot: este sistema va a estar compaginado con las funciones implementadas en Vercel. El primer paso es crear el token gracias a Bot Father. El funcionamiento del bot depende de la integración de los webhooks, esta opción es mucho más ventajosa que polling, ya que no estamos constantemente preguntando si hay cambios, sino que la función serverless funcionará cuando se envíe un mensaje. Para integrar el webhook solo tenemos que realizar una petición a esta URL https://api.telegram.org/botTOKEN_BOTFATHER/setWebHook?url=URL_FUNCTION_VERCEL. Sustituir TOKEN_BOTFATHER por el token correspondiente y URL_FUNCTION_VERCEL por la URL de la función, que en mi caso es https://micro-calendario.vercel.app/calendar-bot. Aunque para acceder a las funciones del bot solamente es posible con objetos JSON, por lo que si accedemos la URL nos dará un error. Aunque esto es fácil de arreglar con un if al principio del programa que nos compruebe si existe un body o mensaje en sí. Utilizamos el fórmato JSON porque necesitamos saber el ID del chat para que haya un intercambio de mensajes, también el contenido del mensaje y diversos datos como el nombre o la fecha del mensaje. Un ejemplo de JSON sería:

  
          "update_id":646911460,
          "message":{
              "message_id":93,
              "from":{
                  "id":10000,
                  "is_bot":false,
                  "first_name":"Jiayu",
                  "username":"jiayu",
                  "language_code":"en-US"
              },
              "chat":{
                  "id":10000,
                  "first_name":"Jiayu",
                  "username":"jiayu",
                  "type":"private"
              },
              "date":1509641174,
              "text":"/help"
          }
          

  Aquí puede ver el funcionamiento del bot y la función. Aunque puede probar el bot en este enlace.
Todo lo relacionado con las pautas de creación y configuración se encuentra en este enlace.

• Se ha añadido el fichero YAML Ain't Markup Language, con la ruta de la estructura del proyecto y las distintas claves cómo lenguaje, test y taskfile.
• Se ha creado la carpeta src con distintas clases:
• La primera clase events.js del proyecto, encargada de crear los eventos.
• La segunda clase planner.js para poder organizar y gestionar la clase evento.
• El fichero de test, el cual se encuentra en la carpeta test, bajo el nombre util.test.js.
• Se ha creado el Dockerfile y .dockerignore.
• Los archivos JSON correspondientes: package.json y package-lock.json.
• Se ha configurado el fichero travis, siguiendo las buenas prácticas.
• Se ha configurado el fichero shippable.
• Se ha configurado el fichero ghcr y el fichero linter-prettier.
• Se ha configurado el [iv.yaml](../iv.yaml) conforme la URL y el archivo 5.json.
• Se ha creado la carpeta con las funciones de Vercel api.
• Se ha creado la carpeta con las funciones de Netlify functions.

Todo lo relacionado con las pautas de creación y configuración se encuentra en este enlace.

api

• En este enlace se encuentran los issues cerrados.
• En este enlace se encuentran los milestones cerrados.
• Se han añadido las Historias de Usuario con su label correspondiente. Aquí se puede consultar las diferentes HU:
• HU1: Consulta de eventos.
• HU2: Consulta específica de eventos.
• HU3: Creación de eventos.
• HU4: Configuración de Docker.
• HU5: Instalación de ESLint y Prettier.
• HU6: Testing.
• HU7: Integración continua.
• HU8: Vercel.
• HU9: Netlify.
• HU10: Telegram bot.

Todo lo relacionado con las pautas de creación y configuración se encuentra en este enlace.