Tests a desarrollar:

• Overall time exceded without package time exceded
• Package time exceded without overall time exceded
• Exceded but finished should not return errors
• In time unfinished should not return errors

Criterios para elegir el sistema de integración continua:

• Compatibilidad con Github Checks API
• Ofrecido como servicio SasS
• Gratuito para proyectos públicos

Algunas opciones:

• Done.io: Sistema gratuito para proyectos públicos y ofrecido como SaaS, no es compatible con Github Checks API aunque está en el roadmap y hay alguna solución no oficial aportada por la comunidad.
• codefresh.io: Sistema gratuito para proyectos públicos y ofrecido como SaaS, no especifica si es o no compatible con Github Checks API aunque sí que dispone de autentificación a través de aplicación de github.
• appveyor: Sistema gratuito para proyectos públicos y ofrecido como SaaS, no es compatible con Github Checks API.
• Semaphore: Sistema gratuito para proyectos públicos y ofrecido como SaaS, es compatible con Github Checks API, pero me ha parecido menos intuitivo la configuración inicial del workflow.
• circleci ❤️: Sistema gratuito para proyectos públicos y ofrecido como SaaS, se puede autentificar directamente como aplicación de github (lo que le da acceso a github checks api) a nivel de organización, por tanto es muy cómodo integrarlo correctamente con github para validaciones en PR's y demás.
• github-actions ❤️: Sistema gratuito para proyectos públicos y ofrecido como SaaS, como lo proporciona github, está totalmente ingtegrado con github checks api

Ambos sistemas elegidos están muy extendidos y por tanto tienen una gran comunidad detrás así como documentación sobre como realizar cualquiera de las tareas requeridas.

Algunos gestores de tareas:

• ❤️ npm/bun: proporcionan un task runner genérico que se puede utilizar más para documentación que para la propia ejecución de tareas, debido a que en la mayoría de tareas que deberemos utilizar en el proyecto serán comandos simples del sistema y no serán tareas paralelas o con un modelo complejo de ejecución, este gestor de tareas nos será más que suficiente en el proyecto.
• grunt y gulp: ambos gestores de tareas son bastante similares tanto en concepto como en modo de uso, ambos tienen un fichero de configuración donde se definen las tareas a ejecutar, se pueden extender mediante módulos y son proyectos marudados que ya apenas requieren mantenimiento (casi todo se hace mediante módulos). Actualmente no tenemos otra serie de tareas que no sean fácilmente integrables directamente en bun, por lo que no se usará por el momento.

A diferencia de los gestores de dependencias, los gestores de tareas se pueden combinar sin problema ya que nos pueden ser beneficioso el uso de uno concreto para la ejecución de alguna tarea determinada.

Hola @arsa-dev, me ha asignado este repositorio para trabajar el objetivo 2. Voy a utilizar este issue para comunicar contigo y para el desarrollo del objetivo. He visto que has abierto tú un issue también, pero he decidido abrir uno para poder referirme a las tareas en mi futuro PR.

Lista de tareas:

• Decidir el lenguaje de programación: he visto en el otro issue que has decidido usar typescript, me parece perfecto. Aunque no se si has comentado con el profesor de tu decisión.
• Decidir la estructura de los directorios y ficheros.
• Determinar los objetos valor y las entidades.
• Implementación.

Inicialmente se deberán de detectar las siguientes circunstancias:

• Los paquetes específicos dentro de una orden de fabricación que no están completados y exceden el tiempo estimado
• Si la orden de fabricación no está completada y excede el tiempo estimado

Para considerar esta lógica viable deben de superarse los tests descritos en #7

Creo esta issue para debatir el runtime a utilizar en el proyecto.

He estado leyendo esta comparativa que creo que es bastante objetiva, saco las siguientes conclusiones:

• Deno tiene algunos beneficios en el uso de typescript de forma directa, módulos ES en lugar de SystemJS
• No sería necesario el uso de gestor de paquetes ya que se puede importar directamente mediante urls, esto hace necesario por otro lado una serie de mejoras de seguridad que implementa Deno y no NodeJS. Por este mismo motivo el language server y typings que ofrece Deno para el proceso de desarrollo no está tan desarrollado para ofrecer un intellisense como al usar NodeJS descargando las dependencias.

Por otro lado, he estado revisando algunos de los frameworks más extendidos en el lenguaje pero no tienen compatibilidad con Deno:

• nestjs/nest#5183 (comment)
• loopbackio/loopback-next#2383

Como conclusión, creo que es más conveniente en el proyecto usar NodeJS ya que está mucho más extendido y se cuenta con frameworks consolidados que nos permiten no tener que reinventar la rueda para resolver problemas ya resueltos y mantenidos por la comunidad. Aunque esto abierto ante cualquier discusión extra que no conozca y me pueda hacer cambiar de opinión.

Tras hablar con Francisco, el dueño de la empresa, nuestro cliente interesado en el producto, nos transmite la necesidad de que la aplicación le notifique cuando hay un problema durante la producción, para él poder tomar riendas en el asunto y buscar una solución a tiempo.

Algunos test runners:

• Jest: Este test runner viene con su propia biblioteca de aserciones por lo que no habría posibilidad de elección en esto, además está muy enfocado a proyectos de react ya que facebook ha invertido gran parte de desarrollo en este test runner para integrarlo en react.
• Jasmine: Jasmine al igual que Mocha también está bastante extendido aunque, la instalación puede ser algo más compleja que Jest y requiere de una librería de aserciones externa para poder funcionar.
• Mocha ❤️: Mocha es muy extensible y flexible ya que viene sin librería de aserciones ni mocking, gracias a ello el desarrollador puede elegir cuál utilizar, además está bastante extendido y muchos CI runners tienen soporte para el mismo.

Algunas librerías de aserciones:
Entre las que podemos observar en la documentación de mocha (https://mochajs.org/#assertions) creo que la más interesante sería chai ya que está muy extendida y permite tres estilos de aserciones que puede dar más juego y facilidad en el desarrollo de tests.

Hola @vdeq79, he estado revisando la convención más utilizada en typescript para nombrar las propiedades de las clases (coincide con el por defecto de eslint que se puede consultar en https://typescript-eslint.io/rules/naming-convention/). Parece que el más utilizado es lowerCamelCase, si te parece bien podemos seguir esta norma en lugar de snake_case. Algunos casos:

• https://github.com/arsa-dev/OMP-Logic/pull/10/files#diff-5181e7c627f6cda81e1e660f30004e6a4405f052aaff329f9edb9c0d8a988de1R14
• https://github.com/arsa-dev/OMP-Logic/pull/10/files#diff-a94ae17a374f7672c5e7d84b26af6562d186a39e39ae275977632058e6c91765R10

@vdeq79 Abro hilo para comentar la tecnología a utilizar. Mi idea inicial es utilizar typescript, ya que de este modo se podrán avanzar en el producto con la seguridad ante errores que nos ofrece el uso de los tipos junto a los beneficios de usar nodejs (javascript del lado del servidor que es donde se implementará el modelo completo de información) para el desarrollo de la aplicación.

Pronto iré añadiendo al hilo algunos primeros pasos para inicializar el proyecto con typescript y con algunos paquetes simples muy utilizados que nos permitan transpilar typescript a javascript que es lo que podríamos ya lanzar usando el runtime de nodejs.

Algunos gestores de dependencias:

• npm: es el gestor de paquetes (dependencias) que fue originalmente desarrollado por el proyecto Node.js, nos permite generar paquetes y compartir estos módulos entre distintos proyectos, se desarrolló junto a npmjs.com, que es el repositorio de paquetes más extendido.
• yarn: desarrollado por Facebook, utiliza la misma jerarquía de directorios en node_modules pero instala dependencias en paralelo brindando una velocidad un poco mayor.
• pnpm: trata de simplificar el proceso de instalación de paquetes en las aplicaciones, de este modo se consiguen instalaciones mucho más rápidas y un gran ahorro de disco mediante el uso de hardlinks y softlinks. Además este gestor de paquetes no utiliza la misma jerarquía de directorios que npm y yarn, lo que simplica el proces de importación de dependencias en paquetes.
• ❤️ bun: este gestor de paquetes está muy enfocado en la velocidad, también por medio de uso de hardlinks y softlinks, así como de uso de ficheros binarios para el fichero lock, lo que aporta mayor velocidad en la serialización y deserialización. Se elige bun ya que es más rápido en benchmarks y además ya se ha elegido como runtime para node.

Todos estos gestores de dependencias nacen partiendo de la definición de paquete y dependencias (fichero package.json) que inicalmente implementa npm. Por ello todos funcionan a través de este paquete inicial aunque luego muestran comportamientos distintos en cuanto al fichero lock, y gestionan de forma distinta la instalación de dependencias.

Elección de la librería de logging #24

Criterios para elegir la librería de logging:

• Soporte diferentes backends de logging, entre ellos kibana
• Output por consola

Algunas opciones:

• NGX-Logger: Sistema de logging simple aunque muy enfocado para proyectos angular, no obstante se puede utilizar en otro tipo de proyectos y hay bastante comunidad detrás. No tiene soporte para el backend de logging kibana.
• Winston ❤️: Librería de logging muy extendida (diría que la más conocida en nodejs) y con soporte para diferentes backends de logging. Cumple con todos los criterios previos.

Ambos sistemas elegidos están muy extendidos y por tanto tienen una buena comunidad detrás así como documentación sobre como realizar cualquiera de las tareas requeridas.

• Operaciones. Define las acciones que realizan los operarios.
• Modelos. Conjunto de operaciones necesarias para la fabricación de un modelo concreto, dos modelos distintos pueden requerir de una misma operación.
• Órdenes de fabricación. Es un elemento que contiene uno o más paquetes de modelos y el número de unidades por paquete que deben de fabricarse

Algunas imágenes:

• dvlprtech/bun: Imagen de docker no oficial de bun, aparentemente funciona correctamente en 64bits pero no en arm64.
• imagen propia de bun: Se ha intentado encarecidamente generar una imagen para este runtime compatible con mi equipo pero tras varias horas de desarrollo se ha descartado la opción por el tiempo que requiere y motivos de compatibilidad.
• node:latest ❤️: Finalmente he optado por utilizar la imagen oficial de node, ya que mocha utiliza el runtime node y los problemas de commpatibilidad experimentados con bun en la arquitectura de mi equipo.

Elección del framework #28

Criterios para elegir el framework:

• Uso sencillo de verbos HTTP en controladores
• Definición de rutas personalizadas e integración con path y query parameters
• Generación automática de OpenAPI

Algunas opciones:

• express: Framework HTTP simple, no gestiona serialización ni entiende de OpenAPI aunque está muy extendido.
• loopback ❤️: Framework REST diseñado para generar aplicaciones de un modo simple y muy veloz, implementa conceptos como datasources (no necesariamente bases de datos), modelos, controladores...; además de generación automática de openapi a partir de modelos y controladores mediante el uso de decorators en typescript (reflect-metadata), etc. Además está mantenido por IBM y aunque no cuenta con la mejor documentación casi siempre se encuentran recursos de la comunidad para conocer como implementar casi cualquier problema al que nos enfrentemos.