Diferencia entre revisiones de «Taller de gestión de código (1) (06/10/14) - Grupo de Cabina de Votación - 14/15»

De Wiki de EGC
Saltar a: navegación, buscar
(Página creada con «'''Participantes:''' - Francisco Javier Aguadero García - Alfonso Alcántara López - José Ignacio Algarín Rodríguez - Carlos Borja García - J...»)
 
 
(No se muestran 3 ediciones intermedias de otro usuario)
Línea 12: Línea 12:
 
'''¿Qué hemos hecho?'''
 
'''¿Qué hemos hecho?'''
 
     - Repartir el trabajo a hacer entre los integrantes del grupo.
 
     - Repartir el trabajo a hacer entre los integrantes del grupo.
 +
    - Hacer un pequeño primer boceto de la interfaz de la cabina de voto.
 +
          Se ha optado porque nuestro subsistema se comunique con el resto de subsistemas por medio de una api REST utilizando JSON.
 +
          Recibirá y enviará siempre JSON.
 +
    - Decidir que el modo de comunicación entre los grupos será la wiki de la asignatura.
  
 
'''¿Qué vamos a hacer?'''
 
'''¿Qué vamos a hacer?'''
Línea 19: Línea 23:
 
     - Estudio de la herramientas a utilizar por los miembros del grupo.
 
     - Estudio de la herramientas a utilizar por los miembros del grupo.
 
     - Preparar las herramientas necesarias para nuestro proyecto.
 
     - Preparar las herramientas necesarias para nuestro proyecto.
 +
 +
 +
'''Entrega relacionada: ¿Qué problemas hemos encontrado a la hora de integrar las diferentes partes de código en uno solo?'''
 +
Los primeros y a nuestro parecer primordiales problemas a la hora de realizar la integración fueron los siguientes: El tiempo y la comunicación. La falta de tiempo para organizarnos y la cantidad de gente que conforma el grupo fue lo más difícil de manejar, dado que cada uno tiene su propio horario de clases y sus circunstancias, lo que hacía más difícil el poder quedar o contactar todos al mismo tiempo para dividir y repartir el trabajo a realizar.
 +
 +
Una vez realizadas las partes del código se decidió hacer la unificación a través del CVS. Pero esto también fueron más problemas dado que en un principio, se habló de usar BitBucket, pero, al registrarnos e intentar crear el equipo, nos dimos cuenta de que sólo se permiten grupos de cinco usuarios máximo para las cuentas gratuitas.
 +
Ante este problema, optamos por usar Google Code. Tras crear el proyecto y formar el equipo, nos dimos cuenta de que tanto la interfaz que nos ofrecía el sistema como la gestión de usuarios y contraseñas para acceder al repositorio era demasiad complicada.
 +
La solución final fue GitLab, donde se consiguió crear el equipo sin problemas y todo lo necesario para trabajar.
 +
 +
Una vez creado el proyecto en GitLab, tuvimos que estudiar cómo crear un proyecto en Django y subirlo al repositorio Git. Subimos una versión inicial pero al intentar descargarla el resto de compañeros, el repositorio respondía con que la prueba de conexión había fallado. Al final se solventó este problema, pero apareció uno nuevo, las versiones de django instaladas eran diferentes e incompatibles. Así que tuvimos que instalar todos la misma versión y empezar de nuevo.
 +
 +
Una vez solucionamos los problemas anteriores (o lo intentamos) pudimos integrar nuestros trozos de código. El problema fue que no conseguimos hacerlo funcionar. O al menos no en conjunto. En parte porque es una primera versión del proyecto, había gente que no había terminado de comprender la parte que tenía que realizar, trabajamos con poco conocimiento de qué y cómo hacerlo y además con poco tiempo para realizarlo.
 +
 +
'''Segunda entrega relacionada: Conceptos básicos de gestión del código fuente con los que han experimentado'''
 +
Como repositorio hemos utilizado el repositorio proporcionado por GitLab.
 +
En todo momento hemos utilizado como branch la rama máster de dicho repositorio.
 +
No hemos llegado a configurar nungún baseline dentro del repositorio.
 +
Como sandbox cada uno de los integrantes ha utilizado una copia del repositorio en su máquina local.

Revisión actual del 20:07 8 oct 2014

Participantes:

    - Francisco Javier Aguadero García
    - Alfonso Alcántara López
    - José Ignacio Algarín Rodríguez
    - Carlos Borja García
    - José Javier Delgado Cuder
    - David Jiménez Vargas
    - Juan Elias Maireles Osuna
    - David Miñon Saborido
    - Lara Rodríguez Ternero

¿Qué hemos hecho?

    - Repartir el trabajo a hacer entre los integrantes del grupo.
    - Hacer un pequeño primer boceto de la interfaz de la cabina de voto.
          Se ha optado porque nuestro subsistema se comunique con el resto de subsistemas por medio de una api REST utilizando JSON. 
          Recibirá y enviará siempre JSON.
    - Decidir que el modo de comunicación entre los grupos será la wiki de la asignatura.

¿Qué vamos a hacer?

    - Implementar de la primera versión de la cabina de votación.
    - Buscar un modo de comunicación con el resto de grupos.
    - Búsqueda de un repositorio adecuado a nuestras necesidades.
    - Estudio de la herramientas a utilizar por los miembros del grupo.
    - Preparar las herramientas necesarias para nuestro proyecto.


Entrega relacionada: ¿Qué problemas hemos encontrado a la hora de integrar las diferentes partes de código en uno solo? Los primeros y a nuestro parecer primordiales problemas a la hora de realizar la integración fueron los siguientes: El tiempo y la comunicación. La falta de tiempo para organizarnos y la cantidad de gente que conforma el grupo fue lo más difícil de manejar, dado que cada uno tiene su propio horario de clases y sus circunstancias, lo que hacía más difícil el poder quedar o contactar todos al mismo tiempo para dividir y repartir el trabajo a realizar.

Una vez realizadas las partes del código se decidió hacer la unificación a través del CVS. Pero esto también fueron más problemas dado que en un principio, se habló de usar BitBucket, pero, al registrarnos e intentar crear el equipo, nos dimos cuenta de que sólo se permiten grupos de cinco usuarios máximo para las cuentas gratuitas. Ante este problema, optamos por usar Google Code. Tras crear el proyecto y formar el equipo, nos dimos cuenta de que tanto la interfaz que nos ofrecía el sistema como la gestión de usuarios y contraseñas para acceder al repositorio era demasiad complicada. La solución final fue GitLab, donde se consiguió crear el equipo sin problemas y todo lo necesario para trabajar.

Una vez creado el proyecto en GitLab, tuvimos que estudiar cómo crear un proyecto en Django y subirlo al repositorio Git. Subimos una versión inicial pero al intentar descargarla el resto de compañeros, el repositorio respondía con que la prueba de conexión había fallado. Al final se solventó este problema, pero apareció uno nuevo, las versiones de django instaladas eran diferentes e incompatibles. Así que tuvimos que instalar todos la misma versión y empezar de nuevo.

Una vez solucionamos los problemas anteriores (o lo intentamos) pudimos integrar nuestros trozos de código. El problema fue que no conseguimos hacerlo funcionar. O al menos no en conjunto. En parte porque es una primera versión del proyecto, había gente que no había terminado de comprender la parte que tenía que realizar, trabajamos con poco conocimiento de qué y cómo hacerlo y además con poco tiempo para realizarlo.

Segunda entrega relacionada: Conceptos básicos de gestión del código fuente con los que han experimentado Como repositorio hemos utilizado el repositorio proporcionado por GitLab. En todo momento hemos utilizado como branch la rama máster de dicho repositorio. No hemos llegado a configurar nungún baseline dentro del repositorio. Como sandbox cada uno de los integrantes ha utilizado una copia del repositorio en su máquina local.