hhrib/tacs-tp

tacs-tp's Issues

Integracion Api Imagenes

Usar Map en vez de Array

Cosas como estas son medio toscas, creo que lo pueden resolver mejor con otras estructuras de datos (Hola Map!)
for (Municipality aMuni : match.getMap().getMunicipalities())
{
if (aMuni.getId().equals(requestBean.getIdOriginMuni()))
{
muniOrigin = aMuni;
idsNotFound.removeIf(id -> id.equals(aMuni.getId()));
}
if (aMuni.getId().equals(requestBean.getIdDestinyMuni()))
{
muniDestiny = aMuni;
idsNotFound.removeIf(id -> id.equals(aMuni.getId()));
}
}

Pendientes entrega 2

• Definir bien interacción front-back: Qué información se envía para la creación de partidas (idProvincia vs nombreProv)

• Agregar CORS al back

• Control de usuarios: Si el front es el encargado de permitir selección de usuarios, ¿Por qué sería necesario controlar usuarios desde el back?

• Paginado en listado.

Backend - User stories 2

Partidas, se debe:

• Generar nuevas partidas seleccionando provincia, cantidad de municipios a usar y usuarios participantes (y por lo tanto buscar usuarios)
• Listar todas las partidas, buscar, ordenarlas y filtrar por: fecha, estado
• Modificar estado de una partida (en juego, terminada)
• Cada partida se da sobre un mapa, el mismo es una provincia de argentina a seleccionar.

Frontend - User Story 3

• Visualizar en un mapa todos los municipios que me pertenecen y los de mis enemigos

• Mover gauchos entre municipios que me pertenecen

• Atacar otro municipio

• Modificar la especialización del municipio entre producción o defensa

• Visualizar las estadísticas de producción y defensa de cada municipio. También se debe utilizar una imagen para cada municipio para ver sus detalles

Claves de Auth0 expuestas

Integración con API externa datos topológicos

• Datos topologicos: https://www.opentopodata.org/

Concurrencia

Hay temas de concurrencia por ejemplo en MatchServiceImpl.passTurn pero excede el scope del TP, no pasa nada. Me interesa que los detecten porque esto en PROD explota y es difícil de encontrar. Si los ven dejen comentarios en el javadoc.

Nuevos usuarios no se replican en el backend

Backend - User stories 1

Usuarios: Sign In, Login, Log Out (elegir: sistema propio o integrado con Google/FB/Github/LinkedIn)

Usar Patron State para estados de municipios

#Municipality.produceGauchos Revisen el patrón state por favor.

Mucha logica en service

Service también está resolviendo mucha lógica de negocio. Sin llegar a ser un god object, esperaría que entre Match y Municipality resuelvan por ejemplo el caso de uso de mover gauchos.

Match con ID Autoincremental

Hacer que el ID de Match sea un autoincremental creando una collection que actúe de Sequence.
https://www.baeldung.com/spring-boot-mongodb-auto-generated-field

Manejo de errores en frontend

Es muy importante que los mensajes de error de muestren de cara al usuario. Al menos con un alert, pero enfóquense en tener features cerrados punta a punta, no cuelguen con esto porque además dificulta bastante para ver la app funcionando.

Primera versión del front - User stories 2

Front

Partidas, se deben:

• Generar nuevas partidas seleccionando provincia, cantidad de municipios a usar y usuarios participantes (y por lo tanto buscar usuarios)
• Listar todas las partidas, buscar, ordenarlas y filtrar por: fecha, estado
• Modificar estado de una partida (en juego, terminada)
• Cada partida se da sobre un mapa, el mismo es una provincia de argentina a seleccionar.

Justificar la eleccion de mongoDb en documentacion

Mostrar respuestas satisfactorias en front

Cuando se hace una acción en el cliente (mover gauchos, cambiar estado municipio, etc) y sale ok, no nos enteramos.
Hacer un modal o algo por el estilo.

Integración con API externa GeoRef

• Datos GeoRef de argentina: https://apis.datos.gob.ar

Mezcla de Responsabilidades controller y service

Hay una mezcla de responsabilidades entre el controller y el service. Por ejemplo
#MatchServiceImpl.passTurn
Long matchId = validateAndGetIdLong(matchIdString, "MATCH");
Optional matchOptional = matchRepository.findById(matchId);
Match match = matchOptional.orElseThrow(() -> new MatchException(HttpStatus.NOT_FOUND, Arrays.asList(new ApiError(MATCH_NOT_FOUND_CODE, MATCH_NOT_FOUND_DETAIL))));

Esto lo resolvería a nivel controller. Esperaría que un service ya entienda de objetos de dominio y no IDs.

También esperaría que le puedas decir al match que pase el turno al próximo (tell, don't ask)

Avisar a jugadores que terminó la partida

Vale la pena avisar o diferenciar el caso de un ataque donde un rival pierde la partida? Creen que sería útil para alguien saberlo?

EDIT:

• Avisar a un jugador que perdio la partida (Backend /topic/{id_match}/defeated_player).

• Si el jugador que perdió era el último que quedaba además del ganador no mandarle el mensaje de que perdió. Que le llegue directamente el de final de partida (Backend)

• Avisar a un jugador que perdio la partida (Frontend)

• Avisarle a los demas jugadores que se terminó la partida (Backend)

• Avisarle a los demas jugadores que se terminó la partida (Frontend)

API REST: Saber si un usuario ya está en una partida

Se envía una solicitud http a un endpoint (a definir) para saber si un jugador ya se encuentra en una partida activa.

EDIT Ale:
Se devolverá el matchId de la partida en la que está anotado el usuario (JSON)
Si no estuviera en ninguna partida se devolverá Not Found.

Backend - User Story 4

• Cambiar el estado de un municipio entre producción o defensa

• Los municipios producen gauchos (ver enunciado)

• Si un municipio ataca, se obtiene el municipio atacado si quedan gauchos después del ataque.

• Mover gauchos entre municipios de un mismo jugador

• Configuraciones de Partidas

Documentación - Diagrama de clases Match, Province y Municipality

Armar un pequeño diagrama de clases que muestre la relación entre Match, Province y Municipality.
Fue pedido por el profesor Sebastián para saber cómo estamos modelando esa cuestión.

Correcciones - Entrega 2

• "No pude levantar la app de una.

➜ tacs-tp git:(a927c78) docker-compose -f docker-compose-build.yml start
Starting front ... failed
Starting back ... failed
ERROR: No containers to start

Después le di docker-compose bulild y luego up y levantó."

• Error al crear usuario nuevo

• GameApplication con todos los métodos estáticos. Tiene pinta por un lado de god object, y por otro deberían ser servicios que se inyecten donde sea necesario.

Muchos If anidados?

Esto es un tema de gustos, pero con métodos con mucha validación yo prefiero siempre ir descartando los escenarios de error, tirando excepción y dejando al final el código limpio del caso donde se dan todas las precondiciones. Sino hay if anidados y el código se hace más difícil de seguir.

"Imagen de Ryu tirando un Hadouken al codigo"

Primera versión del front - User stories 1

Front de Usuarios: Sign In, Login, Log Out (elegir: sistema propio o integrado con Google/FB/Github/LinkedIn)

Mejorar Respuesta al Atacar un Municipio

No me copa mucho que #Municipality.attack devuelva un int como código de retorno. Que quieren representar? Hay una forma mejor de hacerlo?

Endpoints Entrega 3

• post de gauchos para mover entre municipios

• post /municipios/atacar --- devolver estado a todos --- ver websockets?

• patch de municipios para modifacar la especializacion entre prod y def

• get para estadisticas -- ver websockets? -> EDIT: No es websockets, quedamos que triggerea el cliente las estadísticas.

Endpoint matches devolver centroide

Falta que el endpoint de matches me devuelva el centroide del mapa:

{
"id": 1,
...
"map": {
"id": 2851832386141158144,
"nombre": "Buenos Aires",
"municipalities": [
{
"id": 145,
"nombre": "Mar Chiquita",
"centroide": {
"lat": "-37.4984341236931",
"lon": "-57.6436183313312"
},
...
},
],
"centroide": null
},
"turnPlayer": {
"id": "auth0|5f767f28b498e2006b9415a8",
"username": "gamer1"
},
"winner": null,
"config": {
...
},
"date": "2020-10-02 12:45:30"
}

Municipality State sigue estando mal

El profe no dió detalles...

Cancelar dialogos en frontend no cancela

PASA CON TODOS LOS DIALOGS
Si presiono Cancel

Procede a hacer el request normalmente