Documentación inicial

[Slowmybrosh]

• Se ha añadido el lenguaje que se utilizará en el proyecto (#51)
• Se añade el gestor de dependencias (#52)
• Se ha añadido el gestor de tareas al proyecto siguiendo lo especificado en #49. Y se ha automatizado la generación del pdf utilizando este gestor (#47).
• Se ha añadido la justificación del uso de un gestor de tareas a la documentación
• Se han cambiado las descripciones de los milestones de la planificación al capítulo de implementación (#54)
• Se han realizado mejoras a las justificaciones de las herramientas, para mayor coherencia.

Ultimos cambios:

• Se cambia la justificación del lenguaje #51
• Se cambian las herramientas analizadas para gestor de tareas #49

[Slowmybrosh]

@JJ Cuando puedas echale un vistazo a esto

[Slowmybrosh]

Aparte de lo dicho (y de lo comentado) no sé qué lenguaje vas a usar, pero si vas a usar uno que ya tenga algún gestor de dependencias que incluya también cierta posibilidad de gestionar tareas usar Make en vez de esa herramienta es incluir dependencias adicionales y posibles confusiones. Una vez más, tienes que tratar de ir más allá de "hago esto por que me lo pide" para tratar de entender el fundamento de las decisiones que tienes que tomar y tomarlas de la forma más informada posible. Una vez más, tienes que tratar de ir más allá de "hago esto por que me lo pide" para tratar de entender el fundamento de las decisiones que tienes que tomar y tomarlas de la forma más informada posible.

He elegido un gestor de tareas que se puede usar de manera independiente de cualquier lenguaje porque todavía no tengo justificado un lenguaje, pero tengo preparada la justificación del lenguaje a usar, junto con un gestor de dependencias. Porque sin lenguaje no puedo justificar un gestor. La configuración del entorno en un .env todavía no es loable ya que no he podido ni justificar ni el tipo de aplicación que se va a realizar.

¿Subo primero el lenguaje y busco un gestor de dependencias con la posibilidad de automatizar tareas?

[JJ]

Aparte de lo dicho (y de lo comentado) no sé qué lenguaje vas a usar, pero si vas a usar uno que ya tenga algún gestor de dependencias que incluya también cierta posibilidad de gestionar tareas usar Make en vez de esa herramienta es incluir dependencias adicionales y posibles confusiones. Una vez más, tienes que tratar de ir más allá de "hago esto por que me lo pide" para tratar de entender el fundamento de las decisiones que tienes que tomar y tomarlas de la forma más informada posible. Una vez más, tienes que tratar de ir más allá de "hago esto por que me lo pide" para tratar de entender el fundamento de las decisiones que tienes que tomar y tomarlas de la forma más informada posible.

He elegido un gestor de tareas que se puede usar de manera independiente de cualquier lenguaje porque todavía no tengo justificado un lenguaje, pero tengo preparada la justificación del lenguaje a usar, junto con un gestor de dependencias. Porque sin lenguaje no puedo justificar un gestor. La configuración del entorno en un .env todavía no es loable ya que no he podido ni justificar ni el tipo de aplicación que se va a realizar.

¿Subo primero el lenguaje y busco un gestor de dependencias con la posibilidad de automatizar tareas?

Configuración en el entorno es meter todas las tareas relativas a la aplicación en código, y no como documentación o disperso en configuración de CI. También se trata de "separar las fases" https://12factor.net/es/build-release-run En general, lo que estés iniciando en cada momento debes tratar de justificarlos en buenas prácticas, buena parte de las cuales las explicamos en IV.

Con respecto a la última pregunta, no sé por qué sigues haciéndome esas preguntas. La respuesta siempre es la misma. Si crees que el tribunal va a entenderlo mejor eligiendo primero el lenguaje y luego el gestor de tareas (por cierto, es como se hace en IV) hazlo así, siempre que pienses que va a formar parte del PMV correspondiente. ¿En qué momento tienes todos los elementos necesarios para poder tomar la decisión? ¿Ahora o más adelante? Para cualquier decisión o problema que se presente, abre un issue, asígnalo a la HU correspondiente, y toma la decisión que consideres necesaria.

Más en específico, aquí has puesto 4 gestores de tareas (entre las decenas que hay), 3 de los cuales dependen de un lenguaje (que todavía no has elegido). ¿Te parece que tenga sentido elegir entonces un gestor de tareas antes del lenguaje?

Siguiendo con lo ya comentado en otros casos, ¿ves lo que ocurre con "voy a hacer lo que me dicen" en vez de entender por qué se hace cada cosa y aprender a hacerlas, que de eso se trata el TFG?

[Slowmybrosh]

@JJ He justificado el uso del lenguaje, el gestor de dependencias y el de tareas. Además de automatizar la generación de pdf con el gestor de tareas seleccionado. Cuando puedas le echas un vistazo

[Slowmybrosh]

@JJ Cuando puedas échale un vistazo :)

[Slowmybrosh]

@JJ Se han eliminado los requisitos del lenguaje buscado, justificando la elección del mismo en base a mis conocimientos y experiencia en el uso de frameworks de Python. Además se ha eliminado la sección de milestones hasta el inicio del desarrollo.

[Slowmybrosh]

@JJ Le puedes echar un vistacillo cuando puedas?

[JJ]

Aunque los cambios sean corrección a cosas que se te han indicado en el PR, debes incluir también un número de issue, porque cuando se acaben fusionando, se va a perder el sentido de por qué se hicieron. La buena práctica es usar como número de issue el del propio PR, aunque también puedes ver si se está cambiando algo porque no se ha solucionado correctamente algún issue o historia de usuario. Por otro lado, también es conveniente seguir la buena práctida de mensajes de commit de 50 caracteres sólo en la primera línea, para evitar que se parta en el resumen que muestra github como sucede en 3a7f9c1

[Slowmybrosh]

Se cierra este PR después de sacar los commits deseados de la rama 'tareas', se abrirán otros PR atómicos, a su debido tiempo, para abordar los issues mencionados en este PR.