Wiki de EGC - Contribuciones del usuario [es]

Frontend y visualización de resultados 1617

2016-12-01T08:33:40Z

Andjimrio: /* Integración continua */

= Aspectos organizativos =

== Miembros ==
* '''José Renato Ramos González:''' Project Manager
* '''José Gavilán Ruiz:''' Software Developer
* '''Eva Menendez Montes:''' Software Developer
* '''Andrés Miguel Jiménez Ríos''': Software Developer
* '''Andrés Doncel Ramírez:''' Software Developer

== Actas ==

== Gestión de código==
Se trabajará en una rama "dev". Los cambios en local se harán en una copia de esta rama

Cada versión se etiquetará como vX.Y.Z, siendo X la versión mayor, Y la menor, y Z la revisión. Las versiones candidatas se marcarán con "c" (de candidate) tras la versión.

Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en "dev" se juntará con la rama "master", marcando esa versión como "r" (de release).

== Gestión de incidencias ==
Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:
*Descripción
*Pasos a ejecutar
*Resultado esperado
*Resultado obtenido

Se espera compromiso por parte de los desarrolladores para que resuelvan activamente las incidencias surgidas. Cuando un desarrollador quiera resolver un issue, puede auto asignárselo. Si hay issues con más de una semana sin resolver, el project manager puede asignar a un desarrollador para que resuleva la incidencia.

Cuando una incidencia está resuelta, se debe indicar en el issue correspondiente. Es deseable hacer una referencia al commit que resuelve la incidencia, aunque no necesario. Una vez resuelta la incidencia, esta puede cerrarse.

===Tipos de incidencias===
*example: para ejemplos de cómo resolver incidencias
*bug: para informar de un error en el funcionamiento del código
*enhancement: para proponer una nueva funcionalidad
*help wanted y question: para dudas sobre el funcionamiento en general

===Prioridad y estado de incidencias===

A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.

Esto se complementa con las etiquetas de duplicate, invalid y wontfix, que indican, explicación previa, que la incidencia no es válida y no se va a resolver. Se procederá a cerrar la incidencia inmediatamente.

Por último, el estado de la incidencia se marca con solo dos etiquetas:

*started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla
*fixed: indica que la incidencia ha sido resuelta y verificada. Se espera confirmación del usuario que indicó la incidencia para que compruebe que realmente el problema está resuelto.

Si es así, se puede cerrar la incidencia.

En caso contrario, se debe volver a marcar la etiqueta started.

Como es natural. NO se puede cerrar un issue que esté en estado started, sino que debe pasar a fixed, duplicate, invalid o wontfix (siempre con explicación previa) antes de poder cerrarse.

== Integración continua ==
La idea es tener un sistema de despliegue e integración continua durante el desarrollo de los proyectos con el fin de facilitar tanto el desarrollo como la integración de los subsistemas. Para ello se ha pensado que dicha integración constará de 3 partes:

* Fase make. En esta fase se descarga el código tras una modificación y se prepara para ser lanzado. En ocasiones podrían ejecutarse test para comprobar su integridad antes del despliegue. En nuestro caso, no se hace nada.
https://jenkins.egc.duckdns.org/

* Fase beta. Esta fase se ejecuta automáticamente tras la finalización de la fase make. Se elimina la aplicación ya desplegada y se lanza la compilada en la fase make.
https://beta.frontend.agoraus1.egc.duckdns.org/

* Fase stable. Esta fase se ejecuta manualmente por el administración del Jenkins. Se diferencia de la fase beta en la estabilidad, algo necesario para la interacción por parte de los otros subsistemas con él. El código ejecutado en esta fase debe ser el mismo que el de la fase beta para corroborar su estabilidad antes de ejecutar este despliegue.
https://frontend.agoraus1.egc.duckdns.org/

Para la configurar Jenkins, nos hace falta utilizar un docker con la configuración de nuestro proyecto. Para eso, se ha utilizado la imagen: https://hub.docker.com/r/anapsix/nodejs/ ya que incluye todo lo que nos hace falta: nodeJS y sus comandos iniciales: _npm install_ y _npm start_. Los comandos para ejercutar en local el código son:

git clone https://github.com/AgoraUS-G1-1617/Frontend.git

git pull --all

sudo apt-get install docker.io

sudo docker pull anapsix/nodejs

sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs

== Repositorio de código ==
https://github.com/AgoraUS-G1-1617/Frontend

== Subsistemas relacionados ==

Frontend y visualización de resultados 1617

2016-12-01T08:33:06Z

Andjimrio: /* Integración continua */

= Aspectos organizativos =

== Miembros ==
* '''José Renato Ramos González:''' Project Manager
* '''José Gavilán Ruiz:''' Software Developer
* '''Eva Menendez Montes:''' Software Developer
* '''Andrés Miguel Jiménez Ríos''': Software Developer
* '''Andrés Doncel Ramírez:''' Software Developer

== Actas ==

== Gestión de código==
Se trabajará en una rama "dev". Los cambios en local se harán en una copia de esta rama

Cada versión se etiquetará como vX.Y.Z, siendo X la versión mayor, Y la menor, y Z la revisión. Las versiones candidatas se marcarán con "c" (de candidate) tras la versión.

Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en "dev" se juntará con la rama "master", marcando esa versión como "r" (de release).

== Gestión de incidencias ==
Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:
*Descripción
*Pasos a ejecutar
*Resultado esperado
*Resultado obtenido

Se espera compromiso por parte de los desarrolladores para que resuelvan activamente las incidencias surgidas. Cuando un desarrollador quiera resolver un issue, puede auto asignárselo. Si hay issues con más de una semana sin resolver, el project manager puede asignar a un desarrollador para que resuleva la incidencia.

Cuando una incidencia está resuelta, se debe indicar en el issue correspondiente. Es deseable hacer una referencia al commit que resuelve la incidencia, aunque no necesario. Una vez resuelta la incidencia, esta puede cerrarse.

===Tipos de incidencias===
*example: para ejemplos de cómo resolver incidencias
*bug: para informar de un error en el funcionamiento del código
*enhancement: para proponer una nueva funcionalidad
*help wanted y question: para dudas sobre el funcionamiento en general

===Prioridad y estado de incidencias===

A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.

Esto se complementa con las etiquetas de duplicate, invalid y wontfix, que indican, explicación previa, que la incidencia no es válida y no se va a resolver. Se procederá a cerrar la incidencia inmediatamente.

Por último, el estado de la incidencia se marca con solo dos etiquetas:

*started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla
*fixed: indica que la incidencia ha sido resuelta y verificada. Se espera confirmación del usuario que indicó la incidencia para que compruebe que realmente el problema está resuelto.

Si es así, se puede cerrar la incidencia.

En caso contrario, se debe volver a marcar la etiqueta started.

Como es natural. NO se puede cerrar un issue que esté en estado started, sino que debe pasar a fixed, duplicate, invalid o wontfix (siempre con explicación previa) antes de poder cerrarse.

== Integración continua ==
La idea es tener un sistema de despliegue e integración continua durante el desarrollo de los proyectos con el fin de facilitar tanto el desarrollo como la integración de los subsistemas. Para ello se ha pensado que dicha integración constará de 3 partes:

* Fase make. En esta fase se descarga el código tras una modificación y se prepara para ser lanzado. En ocasiones podrían ejecutarse test para comprobar su integridad antes del despliegue. En nuestro caso, no se hace nada.
https://jenkins.egc.duckdns.org/

* Fase beta. Esta fase se ejecuta automáticamente tras la finalización de la fase make. Se elimina la aplicación ya desplegada y se lanza la compilada en la fase make.
https://beta.frontend.agoraus1.egc.duckdns.org/

* Fase stable. Esta fase se ejecuta manualmente por el administración del Jenkins. Se diferencia de la fase beta en la estabilidad, algo necesario para la interacción por parte de los otros subsistemas con él. El código ejecutado en esta fase debe ser el mismo que el de la fase beta para corroborar su estabilidad antes de ejecutar este despliegue.
https://frontend.agoraus1.egc.duckdns.org/

Para la configurar Jenkins, nos hace falta utilizar un docker con la configuración de nuestro proyecto. Para eso, se ha utilizado la imagen: https://hub.docker.com/r/anapsix/nodejs/ ya que incluye todo lo que nos hace falta: nodeJS y sus comandos iniciales: _npm install_ y _npm start_. Los comandos para ejercutar en local el código son:

git clone https://github.com/AgoraUS-G1-1617/Frontend.git
git pull --all

sudo apt-get install docker.io
sudo docker pull anapsix/nodejs
sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs

== Repositorio de código ==
https://github.com/AgoraUS-G1-1617/Frontend

== Subsistemas relacionados ==

Frontend y visualización de resultados 1617

2016-11-30T11:11:37Z

Andjimrio: /* Integración continua */

Frontend y visualización de resultados 1617

2016-11-30T11:11:13Z

Andjimrio: /* Integración continua */

Frontend y visualización de resultados 1617

2016-11-30T10:51:40Z

Andjimrio: /* Integración continua */

Miembros Logistica 2016/17

2016-10-11T16:30:18Z

Andjimrio: /* Miembros del comité */

== Miembros del comité ==

Coordinación:

* Francisco José Baquero Boza 

Miembros del equipo: 

* Francisco Aguilar Cano
* Abdelkader Chellik
* María Remedios Dans
* Manuel de La Fuente Carmona
* Andres Doncel Ramirez
* Fermin Fernandez Borrego
* Carlos Gámez Ramirez
* Jose Gavilan Ruiz
* Jose Manuel Gavira Gonzalez
* Manuel Jesus Gil Del Fresno
* Alvaro Gonzalez Sierra
* Francisco Gonzalez Valle
* Jose Antonio Izquierdo Navarro
* Jose Maria Jimenez Jimenez
* Pablo Luna Dominguez
* Eva Menendez Montes
* Octavio Montero Oliva
* Pablo Morilla Leon
* Francisco Javier Ordoñez Medina
* Daniel Pineda Guerrero
* Juan Rodriguez Dueñas
* Jose Luis Salazar Gonzalez
* Andres Soto Valdes
* Zakaria Sahmoudt
* Andres Jiménez Rios

Asamblea 5 Oct 2016 - Grupo 1

2016-10-05T16:59:43Z

Andjimrio:

Al principio de la asamblea se eligió al delegado: solo hubo una candidatura, que fue la que ganó. Ahora nuestro delegado es Andrés Jiménez.

[[Archivo:05102016asamblea.jpg]]

Tras esto, se empezó a decidir los porcentajes de cada parte de la asignatura: ''Trabajo'', ''Jornada'' y ''Ejercicio''. Para empezar a dar propuestas, se dijo cuales fueron las puntuaciones del año pasado:
- Grupo 1: ''60-20-20''
- Grupo 2: ''75-15-10''

Con esto surgió el debate si era preferible dar mayor peso a la Jornada o al Trabajo. Los primeros apoyaban que dar mayor importancia a las Jornadas EGC implicaría reducir la carga del curso (díficil ya per se, si además tienes asignaturas de otros años) a dos semanas; los segundos, que era inhumano hacer en dos semanas lo que tendríamos que hacer durante todo un curso, y que por eso, preferirían una carga de trabajo más acompasada.

Con debates y uniones de candidaturas a tutiplén, quedaron estas tres propuestas:
A) ''50-30-30''
B) ''65-15-30''
C) ''40-40-20''
Siguiendo el orden del párrafo 2 (Trabajo, Jornada, Ejercicio) y cada número siendo un porcentaje.

De votó a mano alzada, consiguiendo A 15 votos; B, 51; C, 0. Por ello, el baremo que seguiremos en la asignatura será:
- '''Trabajo: 65%'''
- '''Jornadas EGC: 15%'''
- '''Ejercicio: 30%'''

Queda como misión del delegado comunicar al grupo 2 el porcentaje elegido de las Jornadas.

Asamblea 5 Oct 2016 - Grupo 1

2016-10-05T16:59:32Z

Andjimrio:

Archivo:05102016asamblea.jpg

2016-10-05T16:59:15Z

Andjimrio: Andjimrio subió una nueva versión de «Archivo:05102016asamblea.jpg»

Archivo:05102016asamblea.jpg

2016-10-05T16:53:10Z

Andjimrio:

Asamblea 5 Oct 2016 - Grupo 1

2016-10-05T16:52:42Z

Andjimrio:

Asamblea 5 Oct 2016 - Grupo 1

2016-10-05T16:51:37Z

Andjimrio:

Al principio de la asamblea se eligió al delegado: solo hubo una candidatura, que fue la que ganó. Ahora nuestro delegado es Andrés Jiménez.

[[Archivo:asamblea.jpg]]

Tras esto, se empezó a decidir los porcentajes de cada parte de la asignatura: ''Trabajo'', ''Jornada'' y ''Ejercicio''. Para empezar a dar propuestas, se dijo cuales fueron las puntuaciones del año pasado:
- Grupo 1: ''60-20-20''
- Grupo 2: ''75-15-10''

Con esto surgió el debate si era preferible dar mayor peso a la Jornada o al Trabajo. Los primeros apoyaban que dar mayor importancia a las Jornadas EGC implicaría reducir la carga del curso (díficil ya per se, si además tienes asignaturas de otros años) a dos semanas; los segundos, que era inhumano hacer en dos semanas lo que tendríamos que hacer durante todo un curso, y que por eso, preferirían una carga de trabajo más acompasada.

Con debates y uniones de candidaturas a tutiplén, quedaron estas tres propuestas:
A) ''50-30-30''
B) ''65-15-30''
C) ''40-40-20''
Siguiendo el orden del párrafo 2 (Trabajo, Jornada, Ejercicio) y cada número siendo un porcentaje.

De votó a mano alzada, consiguiendo A 15 votos; B, 51; C, 0. Por ello, el baremo que seguiremos en la asignatura será:
- '''Trabajo: 65%'''
- '''Jornadas EGC: 15%'''
- '''Ejercicio: 30%'''

Queda como misión del delegado comunicar al grupo 2 el porcentaje elegido de las Jornadas.

Asamblea 5 Oct 2016 - Grupo 1

2016-10-05T16:51:03Z

Andjimrio: Página creada con «Al principio de la asamblea se eligió al delegado: solo hubo una candidatura, que fue la que ganó. Ahora nuestro delegado es Andrés Jiménez. Tras esto, se empezó a ...»

Al principio de la asamblea se eligió al delegado: solo hubo una candidatura, que fue la que ganó. Ahora nuestro delegado es Andrés Jiménez.

Tras esto, se empezó a decidir los porcentajes de cada parte de la asignatura: ''Trabajo'', ''Jornada'' y ''Ejercicio''. Para empezar a dar propuestas, se dijo cuales fueron las puntuaciones del año pasado:
- Grupo 1: ''60-20-20''
- Grupo 2: ''75-15-10''

Con esto surgió el debate si era preferible dar mayor peso a la Jornada o al Trabajo. Los primeros apoyaban que dar mayor importancia a las Jornadas EGC implicaría reducir la carga del curso (díficil ya per se, si además tienes asignaturas de otros años) a dos semanas; los segundos, que era inhumano hacer en dos semanas lo que tendríamos que hacer durante todo un curso, y que por eso, preferirían una carga de trabajo más acompasada.

Con debates y uniones de candidaturas a tutiplén, quedaron estas tres propuestas:
A) ''50-30-30''
B) ''65-15-30''
C) ''40-40-20''
Siguiendo el orden del párrafo 2 (Trabajo, Jornada, Ejercicio) y cada número siendo un porcentaje.

De votó a mano alzada, consiguiendo A 15 votos; B, 51; C, 0. Por ello, el baremo que seguiremos en la asignatura será:
- '''Trabajo: 65%'''
- '''Jornadas EGC: 15%'''
- '''Ejercicio: 30%'''

Queda como misión del delegado comunicar al grupo 2 el porcentaje elegido de las Jornadas.