mjuez / tfm2016_analisis-visual-revisiones-codigo Goto Github PK
View Code? Open in Web Editor NEWHerramienta para la obtención y visualización de datos de revisiones de código.
License: MIT License
Herramienta para la obtención y visualización de datos de revisiones de código.
License: MIT License
Tenemos que buscar una solución para gestionar la persistencia de los datos obtenidos de la API de Github para tratar de minimizar el número de peticiones necesarias a dicha API.
Dependiendo del tipo de sistema gestor de persistencia que escojamos (SQL, NoSQL, ficheros) existen diversas herramientas (ORM, ODM) para NodeJS que podrían facilitarnos el manejo de los datos.
NoSQL ODM (mongodb)
SQL ORM (PostgreSQL, MySQL, MariaDB...)
Como opción adicional existe ToroDB, un tipo de base de datos que es una mezcla entre NoSQL y SQL. Las consultas se hacen con la sintaxis de mongodb y los datos son almacenados en una base de datos PostgreSQL.
Se quiere añadir una nueva fase de revisiones automáticas de código (cobertura, complejidad, defectos de código, etc) al proceso de integración continua (hasta ahora construcción, pruebas y despliegue).
Se proponen dos herramientas de las que se debe escoger una:
Añadir la entidad Revisión (Review), y los puntos de acceso necesarios a los datos de dicha entidad desde la API REST.
Posiblemente también sea necesaria la creación de la entidad Comentario de revisión (Review Comment)
Nos gustaría hacer uso de una herramienta de integración continua que nos permita ejecutar los test y desplegar la aplicación en Openshift de forma automática.
Actualmente vamos a probar el funcionamiento de Travis CI.
Se puede realizar un prototipo de "hola mundo" en NodeJS para probar el funcionamiento e integración de Travis con los tests y con Openshift.
Actualmente se están utilizando herramientas como mongoose que se deben incluir en la memoria.
Añade una subsección en conceptos teóricos que incluya las buenas prácticas ágiles que vas a seguir en el TFM. Utiliza esta página (https://www.agilealliance.org/agile101/subway-map-to-agile-practices/ ) para seleccionarlas y obtener una pequeña descripción.
En la sección de herramientas describe su funcionalidad e indica la buena práctica ágil con la que está asocidada.
TaskBoard, Burndown chart -> Trello o ZenHub
Continuous integration -> Travis
Realizar una pantalla principal básica de la aplicación, por ejemplo con dos campos de texto (usuario, repositorio) que permitan crear una tarea para obtener un repositorio remoto.
También podría tener un desplegable con la lista de repositorios almacenados localmente que permita navegar hacia la parte de la interfaz donde se mostrarán gráficas para dicho repositorio.
Se podría utilizar un framework como boostrap o semantic-ui para el tema de interfaz, y jQuery para realizar llamadas a nuestra API.
Los métodos de los modelos (repositorios) de mongoose retornan premisas que cuando son resueltas retornan Documentos en lugar de Entidades.
Actualmente (aunque por alguna razón funciona) nuestros repositorios no hacen la conversión de Documentos a Entidades.
Este prototipo tiene como fin obtener por ejemplo una Pull Request de un repositorio GitHub y almacenarla localmente en una base de datos MongoDB.
Al parecer Heroku permite la instalación de MongoDB a través de un addon llamado mLab MongoDB, pero la versión gratuita está limitada a 496mb, por ello se trabajará con dos bases de datos, una local y la de heroku, se debería buscar la forma de que al realizar el despliegue (usando travis), se modifique la cadena de conexión para utilizar la base de datos de heroku en lugar de la local, en otras palabras, entorno de desarrollo (local) y entorno de producción (remoto)
Crear una vista que permita visualizar el listado de los repositorios almacenados localmente para en un futuro poder navegar hacia ellos.
Hará falta crear los endpoint necesarios en la API.
Las revisiones de código en Github se realizan a través del uso de Pull Requests, se trata por tanto de uno de los conjuntos de datos más importantes para este trabajo y se debe conocer su estructura y contenido.
A continuación pego el contenido de un comentario de @clopezno en la tarea #16 que puede ser de utilidad:
En el siguiente artículo se seleccionan las características de un pullrequest. Los criterios de clasificación de alto nivel que se especifican en la Tabla 1 del artículo son:
- Características del pull request - 16 medidas
- Características del proyecto - 8 medidas
- Características del desarrollador - 3 medidas
El análisis de datos esta hecho con R y obtenidos con GHTorrent
Las Pull Request de GitHub cuentan con varios elementos cuya diferencia no está muy clara y es importante conocerla:
En #28 se han utilizado los tres elementos y se busca ver cómo se obtienen usando la API y qué contenido específico tienen.
Duplicado #3
Adjunto la siguiente bibliografía para definir los conceptos teóricos sobre revisiones de código en la memoria
Issue creada por error probando el funcionamiento de la funcionalidad Projects de github.
Este prototipo tiene como fin obtener por ejemplo una Pull Request de un repositorio GitHub y almacenarla localmente en una base de datos MongoDB.
Al parecer Heroku permite la instalación de MongoDB a través de un addon llamado mLab MongoDB, pero la versión gratuita está limitada a 496mb, por ello se trabajará con dos bases de datos, una local y la de heroku, se debería buscar la forma de que al realizar el despliegue (usando travis), se modifique la cadena de conexión para utilizar la base de datos de heroku en lugar de la local, en otras palabras, entorno de desarrollo (local) y entorno de producción (remoto)
Se debe añadir al prototipo NodeJS una ruta que permita trabajar con la API de Github.
Como resultado se espera que dado un proyecto de Github, se calcule y muestre el número de revisiones que tiene.
Se busca incluir un pequeño manual del programador en el README del repositorio, así como las "badges" de travis y codebeat para mostrar el estado de la construcción de las ramas dev/master y el GPA del código respectivamente.
Se desea hacer sin consumir peticiones de la API de github para poder asegurarnos de responder al cliente instantáneamente si el repositorio existe o no.
Investigando el código fuente de la página 404 que arroja github frente a la de un repositorio existente, en el segundo caso incluye varias etiquetas meta características que no están presentes en la página de error, por ejemplo fb:app_id
, o description
. Al parecer la primera sirve para la interacción con facebook, la descripción sin embargo es característica de todo repositorio y aunque ambas deberían estar presentes siempre, la descripción tiene menos posibilidades de desaparecer que la aplicación facebook relacionada.
Si el repositorio no existe, nuestra API debería retornar 404 (paso previo a crear la tarea)
Se deben desarrollar pruebas unitarias para el prototipo actual.
Se tomó la decisión de realizar un cliente tipo SPA (single page application), lo que significa que las acciones que se realizan desde el cliente no deben provocar refrescos de la página.
Debido a la elevada cantidad de tecnologías que se utilizan en este proyecto, se decidió utilizar únicamente jQuery en el cliente, evitando frameworks como AngularJS cuyo aprendizaje nos supondría mucho tiempo.
El problema de utilizar únicamente jQuery es que labores como la de enrutamiento resultan muy tediosas cuando la cantidad de combinaciones de rutas crece. Éste problema está apareciendo en nuestro cliente actualmente al intentar implementar los filtros.
He encontrado un pequeño framework que funciona como plugin de jQuery llamado sammy.js, que simplifica la gestión del enrutamiento y considero necesario utilizarlo para conseguir un cliente mantenible.
Probar el framework d3js para hacer una gráfica que muestre el número de pull requests de un repositorio en base al tiempo.
Se debe incluir el diagrama de #5 en la sección de conceptos teóricos como justificación y base de nuevos conceptos a definir. También se debe revisar la sección y corregir erratas.
Hacer un menú de navegación para las principales secciones de la aplicación:
La idea es que en el futuro cada una de esas secciones contenga estadísticas generales, y un listado de cada una de las entidades para navegar hacia estadísticas concretas.
Se debe comenzar el desarrollo de la parte de técnicas y herramientas de la memoria, incluyendo las que se utilizan hasta la fecha.
Actualmente se pueden obtener Pull Request, y Revisiones, quedan 3 tipos de tareas por implementar:
Los métodos toEntity y toEntityArray del servicio PullRequestService deberían formar parte de las entidades en lugar de los servicios.
Estudiar y elegir la forma de documentar el código TypeScript que se va a desarrollar.
Mejorar el prototipo implementando un sistema de colas para tratar el límite de 5000 peticiones a la API de Github. Cuando se terminan las peticiones, se debe recordar el progreso de la tarea actual y continuarlo en el momento de renovación del límite de peticiones.
Lectura de la documentación de OpenShift con el fin de entender el funcionamiento de la plataforma y como poder desplegar una instancia de SonarQube.
Como fuente principal sugiero la información disponible en los siguientes enlaces:
-[Guía del desarrollador de OpenShift] https://developers.openshift.com/en/overview-what-is-openshift.html
-[Guía del usuario de OpenShift Origin] https://docs.openshift.org/origin-m4/oo_user_guide.html
Haciendo pruebas con el repositorio elasticsearch, hasta ahora no había problemas para obtener las pull request, sin embargo al implementar la funcionalidad de obtener las revisiones asociadas a las pull request, llega un momento en el cual la aplicación se cierra con el siguiente error:
<--- Last few GCs --->
[11766:0x3fc7a20] 343097 ms: Mark-sweep 1430.4 (1514.0) -> 1430.4 (1514.0) MB, 2645.3 / 0.0 ms (+ 1.4 ms in 1 steps since start of marking, biggest step 1.4 ms) allocation failure GC in old space requested
[11766:0x3fc7a20] 345249 ms: Mark-sweep 1430.4 (1514.0) -> 1430.4 (1483.0) MB, 2152.1 / 0.0 ms last resort gc
[11766:0x3fc7a20] 347259 ms: Mark-sweep 1430.4 (1483.0) -> 1430.4 (1483.0) MB, 2009.8 / 0.0 ms last resort gc
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x301787bc0d39 <JS Object>
1: $__buildDoc [/home/mario/Gdrive/TFM/git/node_modules/mongoose/lib/document.js:~159] [pc=0x8350aea3f34](this=0x2e04fdb28539 <a model with map 0x665d3aa6971>,obj=0x301787b04311 <undefined>,fields=0x2e683b05c7c9 <an Object with map 0x3602c8607011>,skipId=0x301787b043b1 <true>)
2: constructor(aka Document) [/home/mario/Gdrive/TFM/git/node_modules/mongoose/lib/document.js:~39] [pc=0x8350a...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [node]
2: 0x126426c [node]
3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
5: v8::internal::Factory::NewTransitionArray(int) [node]
6: v8::internal::TransitionArray::Insert(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Map>, v8::internal::SimpleTransitionFlag) [node]
7: v8::internal::Map::CopyReplaceDescriptors(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::DescriptorArray>, v8::internal::Handle<v8::internal::LayoutDescriptor>, v8::internal::TransitionFlag, v8::internal::MaybeHandle<v8::internal::Name>, char const*, v8::internal::SimpleTransitionFlag) [node]
8: v8::internal::Map::CopyAddDescriptor(v8::internal::Handle<v8::internal::Map>, v8::internal::Descriptor*, v8::internal::TransitionFlag) [node]
9: v8::internal::Map::CopyWithField(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::FieldType>, v8::internal::PropertyAttributes, v8::internal::Representation, v8::internal::TransitionFlag) [node]
10: v8::internal::Map::TransitionToDataProperty(v8::internal::Handle<v8::internal::Map>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::StoreFromKeyed) [node]
11: v8::internal::LookupIterator::PrepareTransitionToDataProperty(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::internal::Object::StoreFromKeyed) [node]
12: v8::internal::StoreIC::LookupForWrite(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) [node]
13: v8::internal::StoreIC::UpdateCaches(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) [node]
14: v8::internal::StoreIC::Store(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::Object::StoreFromKeyed) [node]
15: v8::internal::KeyedStoreIC::Store(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [node]
16: v8::internal::Runtime_KeyedStoreIC_Miss(int, v8::internal::Object**, v8::internal::Isolate*) [node]
17: 0x8350a6063a7
Aborted (core dumped)
Aparentemente es un problema con mongoose y el uso de memoria.
Añadir la entidad Repositorio, y los puntos de acceso necesarios a los datos de dicha entidad desde la API REST.
Implementar el listado de pull requests de forma similar al listado de repositorios.
Puede ser interesante ofrecer métodos de ordenación (ascendente, descendente):
Adjunto la siguiente bibliografía para definir los conceptos teóricos sobre revisiones de código en la memoria
Probar el correcto funcionamiento de la ejecución de las revisiones automáticas (codebeat) en un pull request.
Crear un gestor de tareas para tratar la realización de peticiones a la API de GitHub teniendo en cuenta el límite de peticiones.
Una tarea por tanto debe almacenar los parámetros para realizar las peticiones a la API de GitHub, así como el estado de la tarea, por ejemplo la última página obtenida de la API para así poder continuar con ella cuando se renueven las peticiones disponibles.
El gestor de tareas tendrá que decidir qué tarea se debe ejecutar en cada momento.
Ésta issue conecta con la número #27 que no se realizó en el quinto sprint.
Actualmente todas las peticiones GET a nuestra API hacen llamadas a la API de GitHub.
Queremos separar las peticiones GET en dos tipos:
La idea de esta separación tiene entre otros objetivos, el evitar que nuestra API emplee una cantidad de tiempo elevada en responder, las peticiones del segundo tipo deberían responder con el estado de la creación de una tarea que conlleva la petición de datos a la API de GitHub y que podría no ejecutarse en el momento (actualmente responde con los datos que se obtienen de GitHub).
Con los conocimientos que tenemos de la API y basándonos en este artículo y la herramienta ReDA, se busca establecer una definición inicial de las métricas a utilizar para el análisis visual de las revisiones de código.
Estudiar la posible mejora del prototipo permitiendo la obtención de contadores de pull requests totales de un repositorio y de un usuario.
Se deberá estudiar primero la API de Github para comprobar si existe un modo simple de obtener estos contadores, o por el contrario es una funcionalidad que requiere de un elevado número de peticiones a la API.
Añadir la entidad Usuario, y los puntos de acceso necesarios a los datos de dicha entidad desde la API REST.
Se busca realizar un prototipo básico de API REST en Node.JS.
Como framework web se utilizará Express (http://expressjs.com/es/). Se ha elegido este framework por los siguientes motivos:
También se va a utilizar Typescript (https://www.typescriptlang.org/), un superset de Javascript tipado. Los motivos de utilizar Typescript son los siguientes:
Inicialmente se va a utilizar Gulp (http://gulpjs.com/) como herramienta para automatizar tareas, aunque se deberá comparar con alternativas como Grunt.
En lo referente a los tests, inicialmente se utilizará Mocha (https://mochajs.org/) + chai (http://chaijs.com/), pero al igual que en el caso anterior, se deben estudiar en profundidad y valorar alternativas.
En el siguiente artículo se desarrolla un ejemplo bastante completo de uso de las anteriores tecnologías:
http://mherman.org/blog/2016/11/05/developing-a-restful-api-with-node-and-typescript/#.WKzA1iHhBpi
Análizar el concepto de revisión de código extrayendo el diagrama conceptual para definir gráficas que ayuden a analizar el proceso de revisión de código en un proyecto.
Usar ejemplos de de componentes gráficos de la biblioteca que se vaya a utilizar para implementación. Lo dejo a elección de Mario.
Comprensión del como se realizan revisiones de código mediante Gerrit Code Review
Usar la siguiente documentación
Gerrit Code Review - A Quick Introduction. (s. f.). Recuperado 4 de octubre de 2016, a partir de https://review.gerrithub.io/Documentation/intro-quick.html
La aplicación de estos conceptos en el TFM pueden transformarse en un futuro en una tarae
La API de github permite un máximo de 60 peticiones a la hora, cantidad que se puede aumentar utilizando autenticación.
Se debe buscar el modo de utilizar la autenticación para poder realizar un máximo de 5000 peticiones/hora. En este enlace de la guía de la API de github se detalla como obtener tokens oauth para aplicaciones específicas
Hasta ahora, la configuración de travis sirve para la prueba y despliegue del segundo prototipo.
A partir de este momento, se va a desarrollar un prototipo principal cuya funcionalidad se irá incrementando en cada Sprint.
Hay que adaptar la configuración de travis para llevar a cabo el proceso de integración continua en dos ramas:
Existirán por tanto dos aplicaciones en Heroku que sirven para simular dos entornos, el de producción (rama master) y el de desarrollo (rama dev). Las aplicaciones son las siguientes:
Actualmente existe un método recursivo en PullRequestService getAllPaginatedPullRequests
que va realizando peticiones de páginas y almacenándolas en un array de entidades.
Hasta que dicho array no contiene todas las páginas, las entidades no son persistidas en la base de datos local. Se quiere cambiar el comportamiento para que se vayan almacenando las páginas a medida que se obtienen.
Los resultados de obtener todas las entidades (por ejemplo Pull Request) de la base de datos local, también se deberían devolver paginados, siguiendo la estrategia que utiliza la API de GitHub (páginas con un máximo de 100 resultados)
Se busca adaptar el prototipo para utilizar la librería nodejs-github que ofrece interfaces de acceso a la API de GitHub.
Actualmente el cliente cuenta con un layout muy simple.
Se busca incluir un pie de página con información acerca del TFM, y también puede ser interesante un indicador con el estado del gestor de tareas que se actualice periódicamente (en ejecución, esperando de nuevas tareas, detenido -esperando peticiones-).
A lo mejor también se puede cambiar el menú superior por uno lateral en vistas a que en el futuro podríamos incluir la funcionalidad de hacer gráficas comparativas y una posibilidad puede ser elegir las opciones desde el propio menú.
En la página principal, mostrar un mensaje tras pulsar el botón indicando si ha ido bien la creación de la tarea o no.
En el repositorio he cargado en la carpeta memoLatex la plantilla que se utiliza en el TFG de GII. Se necesita ajustar sustituyendo todas las referencias de "TFG o Trabajo Fin de Grado" por "TFM o Trabajo Fin de Máster"
La herramienta que aconsejo utilizar para compilar LateX es TexMaker
Duplicado #6
Lectura de la documentación de OpenShift con el fin de entender el funcionamiento de la plataforma y como poder desplegar una instancia de SonarQube.
Como fuente principal sugiero la información disponible en los siguientes enlaces:
-[Guía del desarrollador de OpenShift] https://developers.openshift.com/en/overview-what-is-openshift.html
-[Guía del usuario de OpenShift Origin] https://docs.openshift.org/origin-m4/oo_user_guide.html
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.