pablojjimenez / tfg Goto Github PK

Nunca llega a descargarse la imagen timeout

Poder leer el estado del arte para que se perciba el análisis críticao del estado del arte y mi propuesta de mejora.
Debo explicar el panorama actual y que voy a hacer para mejorarlo en parte o totalmente.

Configúralo de forma que sólo comprueba los PRs o los push, pero no los dos, porque está repitiendo el test dos veces.

Study the possibility of adding a Gantt chart in the documentation. Take into account the granularity of those tasks

Esencialmente, es

1. Hacer ciertas predicciones sobre datos existentes de una sola fuente
2. Dar un API a esos datos que permita hacer peticiones complejas sobre los datos.

Esta motivación

Por tanto, no se ajusta a estos objetivos. Deberías revisarlos y reescribirla.

Como usuario programadora
quiero poder acceder para trabajar a los datos de mortandad
tal que pueda construir aplicaciones y servicios sin tener que preocuparme de montar cualquier infraestructura para obtener estos datos.

Cada milestone debe:

1. Describir un producto mínimamente viable (e incremental desde el anterior)
2. Tener un orden determinado.
3. Desarrollarse en el orden indicado.

Como programadora quiero poder obtener predicciones sobre el incremento de defunciones
tal que dada una enfermedad pueda obtener su predicción de defunciones en los próximos años.

En aras de completar la HU #42
Implementar una una interfaz de comunicación REST para poder usar el trabajo usando verbos HTTP.

Ahora mismo no se puede utilizar ese operador en la sintaxis de queries

El uso de la biblioteca Prophet nos obliga a trabahar con Python >= 3.8

Como programadora
quiero poder ver gráficas personalizadas basadas en los datos
tal que dada una variable disponible (enfermedad, ccaa, ...) pueda obtener su representación gráfica respecto a otras.

En relación a la HU #14 quiero que se pueda leer especificado la procedencia de cada una de las fuentes y las variables existentes.
Fuentes primarias: INE, datos abiertos gob, ISCIII

De la HU #42
Desarrollar las clases que componen el dominio del problema, sus relaciones y restricciones.

De la HU #42
El código que se introduzca en el repositorio tiene que cumplir estándares de calidad para ello tiene que existir una CI que se encargue de que el código sea bello evitando malas prácticas y que se ejecuten los tests para que asegurar la calidad del código.

Como estudiante quiero investigar como obtener la cobertura de tests que tiene el código para hablar con propiedad ante el tribunal.

El CSV con el tiempo dedicado ponlo en un directorio específico, o bien donde tienes el informe.

No puede haber ninguna constante en el código. Tienes que usar configuración, preferiblemente distribuida. Consulta el capítulo correspondiente de IV.

Originally posted by @JJ in #71 (comment)

Una programadora probablemente querrá que esté documentado lo que usa. Ninguna de las clases que has usado para esto está documentada, ni has puesto una tarea para generar la documentación (que podría estar en la web del propio repo, por ejemplo).

Originally posted by @JJ in #51 (comment)

Avanza la HU #42
Los usuarios quieren poder utilizar el API desarrollado mediante una URL accesible

En aras de cumplir con la HU #14 los contenidos de la memoria tienen que estar bien estructurados en sus capítulos pertinentes...

La motivación formula un problema, que siempre tiene que ser previo a la solución. La ingeniería software debe dedicarse a resolver problemas; si no hay problema, es difícil plantear objetivos y por tanto la solución a través de los mismos. También sin problema no hay posible usuario, no hay historias de usuario, y el resto del desarrollo no se puede edificar sobre eso.
Esta motivación hay que formularla, dentro de lo posible, antes de #1

Como programadora
quiero utilizar este software de forma agnóstica
tal que si se quiere utilizar este proyecto como biblioteca con las restricciones que esto supone.

Especificación
Ahora mismo solo se puede utilizar este proyecto como una biblioteca de otro y es obligatorio que en el proyecto se use el mismo lenguaje de programación que en el que está escrito este trabajo.

En aras de completar la HU #14

es necesario explicar claramente (que ahora mismo no está) porque se ejecutan las pipelines para todas las versiones de python e indicar qué bibliotecas han ido siendo las que han provocado que se reduzca el número de versiones funcionales de Python.

En aras de satisfacer la HU #14

Los lectores quieren leer un pequeño resumen (en-es) del trabajo así como las palabras claves

En el marco de la HU #42 y la tarea #48

• Ahora mismo los datos se cargan en vectores de Python directamente, llevarlos a json y hacer la carga en dataframes para probar tambien esa carga.

• Corregir algunos campos de los modelos que no se ajustan a la realidad de los datos.

Avanza en la HU #14

Como consecuencia de la issue #72 donde mi tutor me pide que explique el modelo de datos y clases que he cread. Me he dado cuenta que la creación de los repositorios se realiza en distintas partes del código y requiere de importar muchas clases de otros módulos. Esto es debido a que algunos modelos contienen muchos value-objects y la creación del repositorio para importarlos es tediosa.

Como solución plantearé en la PR implementar el patrón Factory method para simplificar y unificar el proceso de creación de instancias.

No está justificado en la memoria, ni tampoco en los mensajes de commit de #56

Tampoco devuelven un objeto del mismo tipo. No acabo de entender muy bien el modelizado que estás haciendo, la verdad. Deberías justificarlo también en la memoria.

Con toda la infraestructura necesaria como comprobación ortográfica, los mismos milestones, HUs iniciales y demás.

En relación a la HU #42
Para trabajar con todos esos datos es inviable si no se dispone de una funcionalidad que permita al usuario programador manipular la información que desea en cada momento. Para ello es necesario poder indicar que condiciones de datos quiero (año, causa, grupo de edad al que pertenece...) en que orden quiero obtener los datos y límite con paginación.

La memoria del trabajo debe recoger se establece el marco de la decisión y se explica lo que se ha decidido como indica mi tutor.

En el contexto de evaluación de la memoria, necesito que la memoria cumpla los siguientes requisitos:

1. Claridad.
2. Orden.
3. Explicación del problema.
4. Explicación de la solución y justificación de las herramientas utilizadas.

En aras de contribuir a la tarea #63 y en consecuenta a la HU #62

El generador de gráficos tiene que ser capaz de generar las imágenes en un directorio temporal, es decir que se borran tras cumplir su cometido y no dejemos residuos en el servidor.

El path debe de ser configurable, relación con la issue #73

HAy que pensar en el caso que nos puede ocurrir de que varios usuarios estén haciendo uso de esta funcionalidad al mismo tiempo. Con la implementación actual, cada uno podría recibir una imágen distinta a la esperada. Una forma de solucionar esta casuística es generando un identificador aleatorio único que identifique a que usuario corresponde la imagen generada.

Tarea fundamental para el cumplimiento de la HU #42

Mi tutor ha encontrado un conjunto de datos de mayor calidad al que tenía hasta el momento por lo que es necesario adaptar el modelo de datos a estos nuevos.

La mayor diferencia apreciada es que ahora todo se concentra en un único fichero CSV mientras antes había uno central como con claves foráneas a otros csv.

Estos mnuevos datos se pueden encontrar en este enlace.

Avanza en la HU #42
El motivo de trabajar con repositorios es para abstraer la capa de acceso a datos. Cuando se realice esta issues seremos capaces de poder trabajar con conjuntos de datos e implementar la pertinente lógica de negocio.

https://lyz-code.github.io/blue-book/architecture/repository_pattern/

En la primera página donde aparece el titulo, el nombre del tutor y el mío aparecen en la siguiente hoja descuadrados.

Este por ejemplo probablemente sobra

Quieren poder consultar a los repositorios de datos por palabras, coincidencias indicando sobre el campo a buscar

Darle una vuelta a los contenidos redactos centrándonos más en los usuarios diana que ya conocemos (gracias a la técnica de personas).

En sintonía con la issue #95 y en aras de cumplir la issue #62

Los usuarios quieren un sistema donde con una sola llamada se puedan obterner datos de distintos recursos. Asimismo, tienen que tener la libertad de poder elegir sobre que campo proyectar la respuesta y no tener que devolver todos.

Como alumno del TFG
Quiero una CI
Tal que me avise cuando cometa errores ortográficos

Especificación
Crear una pipeline que compruebe si el texto escrito tiene errores

Notas de testeo
Cuando se se suba nuevo texto al repo debe saltar la pipeline y analizar si hay faltas ortográficas.

En aras de completar de la forma más eficiente posible la HU #62 y atendiendo a la tarea #63, planteo el siguiente problema:

Cuando se solicitan recursos GET se cargan en tiempo de demanda los objetos con los datos de disco, tras devolver la respuesta estos son eliminados por el Python garbage collector, pero ocurre que inmediatamente despúes se puede solicitar otra operación que requiere cargar de nuevo lo que minutos antes ya se había cargado.

Es interesante medir y estudiar si sería posible implementar un sistema de cachés que permita mantener los datos cargados, hay que ver si esto afectaría demasiado a la memoria...

El prefijo debería estar en una constante.

Originally posted by @JJ in #76 (comment)

En aras de contribuir a la tarea #63 y en consecuenta a la HU #62

Es necesario notificar al usuario del API los posibles errores que pueden darse al igual que he hecho en otras capas de la aplicación mediante excepciones.

Los errores de los clientes están en el rango [400, 499] en esta API vamos a contemplar los siguientes casos:

• 400 como código de error genérico ante una acción del usuario no esperada.
• 404 cuando no se encuentra el recurso que solicita
• 422 cuando la entidad no es entendible. E.g: la query formada por el usuario para traerse los datos es incorrecta (en contenido o forma)

Para errores del servidor se usa el rango [500, 599]

De la HU #42
Ante los posibles estados inválidos que puedan surgir es necesario otorgar defensivamente de semántica a estos errores mediante el tratamiento y diseño de excepciones que determinen los motivos de los posibles problemas que puedan surgir.

Makefile no es el más adecuado, ni está instalado por omisión cuando tienes Python.

Hay que justificar la elección de cualquier gestor, y cambiar la decisión a invoke u otro más pythónico. También hay que añadir todas las tareas que haya, como lanzar el backend.