Cambios

Después de haber leído e investigado más a fondo sobre formas de trabajar sesiones con Django hemos decidido hacer ligeros cambios en el diseño y la implementación de la base de datos que ya teníamos hecha. Agregamos una tabla a la base de datos con el fin de mantener un registro de las actividades completadas por los jugadores, se agregaron algunos campos a las otras tablas pero principalmente se cambió la tabla Usuario.

Las ventajas de usar este nuevo modelo son:

• Métodos pre hechos de gran utilidad tanto para administrar como para implementar en las funciones de nuestra lógica.
• Seguridad en el manejo de datos mediante password cifrados y no visibles de manera sencilla
• Validación en los datos para evitar caracteres que puedan comprometer la seguridad del sistema
• Capacidad de autenticar de manera automática y otorgar permisos a los usuarios

Las desventajas:

• La manera de trabajar con los fixtures cambia debido a la seguridad que se menciona antes, esto trae también la desventaja de no poder registrar usuarios mediante los fixtures, dependiendo totalmente de la base de datos
• Modificar las pruebas de unidad

Por otro lado, ya tenemos la interfaz de inicio casi total (falta modificar unas cosas de diseño), y así es como se ve

Por descuido no habíamos subido en la semana anterior todo lo que habíamos avanzado en las sesiones de trabajo que habíamos tenido, pero el ritmo de trabajo ha sido continuo aunque hasta cierto punto un poco accidentado por errores que no nos habían dejado cumplir a cabalidad con los tiempos requeridos.
toda la semana anterior nos habíamos concentrado, como habíamos espeificado en las tarjetas, en la creacion de las bases de datos de nuestro sistema. cuyas tablas ya quedaron implementadas.
También comenzamos la parte de los registros de usuario y validacion de ellos mismos. Al principio quisimos hacer uso del modelo user definido por django, pero no pudimos concluir el proceso usando este modelo ya que nos producía algunos errores a la hora de probar las tablas. sentiamos que el manejo que hacia de las tablas y la informacion que le dabamos era un poco rara y no nos permitiría hacer los fixtures de la manera que queríamos. Hemos intendado resolver el problema y empezamos a ver si sería mejor para nosotros adecuarnos a este modelo o buscar otra opcion para desarrollar lo que queremos.
También comenzamos a hacer los templates del sistema. Usando varias herramientas comenzamos a diseñar las hojas de estilo y las demás interfases del sistema. pero también tuvimos algunos problemas por no haber tomado en cuenta los cambios que tenemos que hacer para que django nos deje manejar el contenido estático, como las imagenes que usaríamos como fondo y nuestras barras.
Seguimos trabajando en finalizar nuestra segunda historia, y acoplarnos con los tiempos que habíamos propuesto. Al mismo tiempo seguimos trabajando en nuestra tercera y cuarta historia para terminarlas segun los tiempos que habiamos propuesto.

Diseño Detallado de la Base de Datos

Como en la entrada anterior lo desciribimos, se hizo un diseño general de la base de datos siendo suceptible a cambios. El cambio más drástico fue el modelo que se usó, ya que el anterior trato de hacer todo 1 a 1, pero al estudiar más a fondo la implementación en Django se hizo un diseño que adoptara los modelos de Django, haciéndolo que fuese de muchos a muchos.

Por otra parte hemos decidido que usaremos MySQL que es una base de datos más robusta que SQLite y se puede utilizar sin problemas en un ambiente distribuido. Además con esta base de datos se puede sacar ventaja también de los modelos de Django para la creación de las tablas de la base de datos.

A continuación se muestra el diseño detallado de la base de datos, tal y como ha sido implementada en Django:

Esta parte la definimos durante el fin de semana, pero hasta hoy hicimos un commit sobre la base de datos que implementamos, ya que también, duarante el fin de semana estuvimos estudiando nuestras opciones y al elegir MySQL, estudiamos su forma de implementación, así como la actualización y adaptación de nuestras StoryCards y TaskCards

Diseño Conceptual del Juego

El día de hoy se hizo un burdo diagrama de flujo en el cual se puede ver la transición en general que el usuario recorrería para entrar e interactuar en el juego. Todo esto con el fin de definir completamente la estructrura de la base de datos, más específicamente, las tablas que se necesitarán para el funcionamiento del juego y sus atributos.

Para explicar mejor el diagrama de flujo, cabe mencionar que el usuario al entrar a las interfaces de la zona roja puede moverse a cualquier otra dentro de la zona roja, y de igual manera, en cualquiera de ellas, el usuario puede finalizar la sesión y automáticamente será direccionado a la página de login. Por otra parte, para entrar a la interface denominada "RETO CON BOSS/USUARIO" desde las interfaces de "ACTIVIDADES" y "USUARIOS PARA RETAR", que dependiendo de si es un usuario o un bot automatizado, interactuará con la tabla que le corresponda para cargar los atributos para el reto.

El diseño de la base de datos se basa en un análisis del diagrama de flujo anterior, resultando en el diseño que se muestra a continuación. Cabe mencionar que este diseño podría cambiar durante el desarrollo del juego, debido a requerimientos que no fueron detectados al momento del análisis o por una mala relación entre las tablas, por lo que lo consideraremos como la versión 1.0 del diseño.