1
00:00:00,460 --> 00:00:06,900
Buenas, somos Izan, Jacob e Iván y os vamos a presentar nuestro trabajo de fin de grado,

2
00:00:07,059 --> 00:00:15,339
Revive. Revive es una forma de no solo organizar los eventos y fiestas, sino vivirlos de una

3
00:00:15,339 --> 00:00:20,359
forma distinta, en la que se juntan varias funcionalidades como serían la creación

4
00:00:20,359 --> 00:00:26,899
y organización del evento en sí, un álbum de fotos que se mantendrá privado hasta que

5
00:00:26,899 --> 00:00:31,539
se termine el evento y una forma de repartir los gastos de la forma más óptima posible.

6
00:00:32,359 --> 00:00:34,140
Todo esto en una sola aplicación.

7
00:00:37,049 --> 00:00:43,310
El problema que queríamos resolver es que cuando alguien quiere crear un plan o tener

8
00:00:43,310 --> 00:00:49,289
un plan con sus amigos, ese plan se distribuye entre muchas otras aplicaciones como es la

9
00:00:49,289 --> 00:00:57,390
organización en un grupo de WhatsApp, los gastos en notas o en tickets sueltos por ahí

10
00:00:57,390 --> 00:01:15,370
Y además de toda esa organización, tenerla en una misma app, meterle una funcionalidad única que es tener un álbum de fotos en el que todo el mundo puede subir fotos, se juntan todas ahí y al final del evento las puedes publicar en una feed.

11
00:01:15,370 --> 00:01:22,260
En cuanto a objetivos técnicos, queríamos aplicar lo que hemos aprendido en el ciclo en una aplicación real

12
00:01:22,260 --> 00:01:26,099
Hemos hecho el frontend con Flutter para poder juntar tanto iOS como Android

13
00:01:26,099 --> 00:01:28,540
Y hemos hecho un backend con Spring Boot

14
00:01:28,540 --> 00:01:41,140
También hemos hecho acceso a datos, hemos tocado los siguientes módulos que serían programación, base de datos, desarrollo de interfaces, programación de servicios y procesos, programación de multimedia y dispositivos móviles y acceso a datos

15
00:01:41,140 --> 00:01:46,799
El backend está desarrollado con Java 25 y Spring Boot 3.5

16
00:01:46,799 --> 00:01:57,560
está hecho en una arquitectura por capas, una capa de interacción con usuario en la que estarían los controles REST

17
00:01:57,560 --> 00:02:04,819
una capa de dominio donde se definirían todas las entidades de las bases de datos y la lógica de negocio

18
00:02:04,819 --> 00:02:11,539
y una capa de repositorio donde sería en sí el acceso a datos de la aplicación

19
00:02:11,539 --> 00:02:20,819
Para la seguridad utilizamos JWT que es Java Web Token con dos tokens en concreto

20
00:02:20,819 --> 00:02:25,460
Sería un token de acceso que tendría una caducidad de 15 minutos

21
00:02:25,460 --> 00:02:31,539
Y un refresh token que serviría para poder refrescar este token y seguir teniendo acceso que duraría 30 días

22
00:02:31,539 --> 00:02:38,819
Para el almacenamiento de token utilizamos Redis, Remote, Directionary y Server

23
00:02:41,539 --> 00:02:47,300
abierto se puede utilizar de forma gratuita que utiliza el sistema clave

24
00:02:47,300 --> 00:02:51,819
valor también hay que decir que los datos de

25
00:02:51,819 --> 00:02:56,719
esta base de datos se almacenan en memoria ram en caché lo que hace que

26
00:02:56,719 --> 00:03:00,659
prácticamente la latencia se anula siendo capaz de soportar hasta un

27
00:03:00,659 --> 00:03:05,080
milisegundo de latencia las contraseñas se jasean con argon 2 id

28
00:03:05,080 --> 00:03:11,099
que es uno de los sistemas más robustos en la actualidad y para las bases de

29
00:03:11,099 --> 00:03:15,900
datos hemos utilizado tres en concreto. La primera sería Redis, como ya os he comentado.

30
00:03:17,340 --> 00:03:22,039
La segunda sería PostgreSQL, que es una base de datos relacional, muy parecida a MayaSQL,

31
00:03:22,319 --> 00:03:30,900
pero con un poco más de libertad a la hora de hacer restricciones e índices. Toda esta

32
00:03:30,900 --> 00:03:38,039
base de datos se utiliza para la parte de usuarios y eventos. ¿Por qué es importante

33
00:03:38,039 --> 00:03:42,860
de utilizar una base de datos relacional, la escritura de datos es muchísimo más rápido

34
00:03:42,860 --> 00:03:49,340
en base de datos relacionales que en los relacionales. Luego el acceso a datos es bastante más lento

35
00:03:49,340 --> 00:03:57,919
ya que haría falta joins complejos y consultas muy largas y muy costosas de hacer. Para poder

36
00:03:57,919 --> 00:04:02,479
solucionar esta problemática hemos utilizado Neo4j que es una base de datos no relacional

37
00:04:02,479 --> 00:04:12,740
basada en grafos donde se almacenarían tanto los nodos que serían las entidades en sí como las filas de MySQL y las relaciones entre ellas.

38
00:04:12,740 --> 00:04:22,339
Nosotros simplemente tenemos usuarios eventos, un usuario puede participar en un evento y un usuario puede ser amigo de otro usuario.

39
00:04:23,160 --> 00:04:31,980
De esta forma la feed automática sería muchísimo más rápida y el buscar usuarios también lo sería.

40
00:04:33,000 --> 00:04:39,019
El frontend está hecho con Flutter, que nos permite tener una sola base de código para tener la aplicación tanto en Android como en iOS.

41
00:04:40,120 --> 00:04:45,680
Seguiríamos la CleanArchitecture de Block, que es como básicamente el ViewModel que hemos aprendido en Kotlin en clase,

42
00:04:46,240 --> 00:04:52,420
pues para Dart, que es el lenguaje de programación que hemos utilizado, y para las aplicaciones HTTP utilizaríamos Dio,

43
00:04:53,279 --> 00:04:55,319
que es lo que se encarga de hacer las llamadas al backend.

44
00:04:55,839 --> 00:05:00,240
También utilizamos interceptores JWT, que es la seguridad que utilizamos en el backend,

45
00:05:00,240 --> 00:05:02,959
y con eso comprimiríamos tanto backend como frontend.

46
00:05:03,860 --> 00:05:10,259
Sincronizamos los tokens tanto de backend como de frontend y estos se renuevan automáticamente y se expiran también.

47
00:05:11,439 --> 00:05:15,860
El chat funciona con WebSocket, que utiliza un protocolo STOM sobre WebSocket.

48
00:05:17,100 --> 00:05:21,519
¿Esto qué es? ¿Por qué no utilizamos peticiones HTTP?

49
00:05:21,519 --> 00:05:31,480
Las peticiones HTTP utilizan una conexión momentánea, es decir, el usuario pide algo y lo recibe.

50
00:05:32,279 --> 00:05:39,439
En cambio WebSocket, lo que es, es un canal que se abre, en nuestro caso, cuando creamos un evento.

51
00:05:40,519 --> 00:05:45,360
Al crear el evento se abre este canal en el que los usuarios tienen una conexión continua entre ellos.

52
00:05:46,540 --> 00:05:49,939
Esto sirve para poder enviar mensajes, enviar y recibir mensajes todo el rato.

53
00:05:49,939 --> 00:06:02,000
Y en nuestro caso, los mensajes dejan de poder enviarse, o sea, ese canal se cierra cuando el evento termina, se suben las fotos a la feed y el chat desaparece hasta que crees otro evento.

54
00:06:03,000 --> 00:06:06,939
Los mensajes van cifrados cuando entras al chat de un evento por primera vez.

55
00:06:07,899 --> 00:06:13,779
El cliente descifra la clave AES con su propia clave privada del dispositivo.

56
00:06:13,779 --> 00:06:17,459
esta clave nunca sale del dispositivo

57
00:06:17,459 --> 00:06:19,319
y esto lo que le permite al usuario es

58
00:06:19,319 --> 00:06:21,319
tener seguridad sobre la filtración

59
00:06:21,319 --> 00:06:21,819
de los datos

60
00:06:21,819 --> 00:06:25,060
solo en su dispositivo tiene esa clave

61
00:06:25,060 --> 00:06:26,319
y por tanto

62
00:06:26,319 --> 00:06:29,040
solo él es capaz de ver esos mensajes

63
00:06:29,040 --> 00:06:32,959
el servidor lo único que hace

64
00:06:32,959 --> 00:06:34,180
es manejar

65
00:06:34,180 --> 00:06:35,939
el enrutamiento

66
00:06:35,939 --> 00:06:38,959
no es capaz de ver el contenido

67
00:06:38,959 --> 00:06:40,079
que hay en esos mensajes

68
00:06:40,079 --> 00:06:42,740
para el despliegue utilizamos RayWin

69
00:06:42,740 --> 00:06:48,939
Railway nos da un entorno real de producción en el que desplegar la aplicación

70
00:06:48,939 --> 00:06:50,519
Accesible a internet

71
00:06:50,519 --> 00:06:53,339
En este lo que podemos hacer es

72
00:06:53,339 --> 00:06:57,339
Gracias a la conexión que tenemos con GitHub

73
00:06:57,339 --> 00:06:59,220
Desplegar directamente el repositorio que tenemos

74
00:06:59,220 --> 00:07:02,079
Podemos comprobar los logs

75
00:07:02,079 --> 00:07:07,579
Aquí como os mostramos podemos ver que falla de la aplicación

76
00:07:07,579 --> 00:07:09,759
Que está ocurriendo en todo momento y como solucionarlo

77
00:07:09,759 --> 00:07:25,720
Lo que también podemos hacer es, en la pestaña de variables, con un .env que hemos creado con todas las variables de entorno que no tienen que ser visibles, las metes aquí y Railway gestiona esas variables para que no se rompa el código de GitHub.

78
00:07:25,720 --> 00:07:44,720
Por último, lo que también puedes hacer es ver todas las métricas o todo lo que consume nuestra aplicación para que podamos ver si necesitamos optimizarla más o menos, los errores que podemos tener, el tiempo de respuesta y cómo podemos solucionarlos.

79
00:07:44,720 --> 00:07:58,720
En local lo que hicimos nosotros fue levantar todos los servicios que os he comentado antes, que son PostgreSQL, Neo4j, Redis y Cloudflare.

80
00:07:58,720 --> 00:08:06,720
En el caso de Cloudflare desplegamos Minio para probarlo y a nivel producción utilizamos ya Cloudflare.

81
00:08:06,720 --> 00:08:12,839
ya Cloudflare. Utilizamos un Docker Compose con un Docker File para poder desplegar en

82
00:08:12,839 --> 00:08:19,800
Docker la aplicación en local para poder probar cada uno sin tener que estar pagando

83
00:08:19,800 --> 00:08:27,180
en Railway. ¿Qué pasa? Que para unificar una base de datos y que hiciésemos pruebas

84
00:08:27,180 --> 00:08:33,720
y que sepamos que está funcionando en varios dispositivos a la vez, lo que hicimos es unificar

85
00:08:33,720 --> 00:08:40,039
una base de datos utilizando el servicio de AVEN con PostgreSQL y el servicio de Neo4j

86
00:08:40,039 --> 00:08:46,000
Aura. Estas dos son igual que los servicios en local, lo que pasa que en la nube esto

87
00:08:46,000 --> 00:08:51,220
nos da unos usuarios y unas contraseñas que las ponemos en las variables de entorno y

88
00:08:51,220 --> 00:08:53,919
utilizamos los tres usuarios para poder hacer comprobaciones.

89
00:08:55,039 --> 00:09:00,840
El mayor reto técnico que encontramos al principio fue todo el tema de la autenticación,

90
00:09:00,840 --> 00:09:09,200
ya que al principio es todo muy engorroso y todo una montaña enorme el tema de la seguridad con JWT

91
00:09:09,200 --> 00:09:15,960
tanto la creación de los tokens en el backend como la sincronización con el front

92
00:09:15,960 --> 00:09:21,120
al tener que enviarlos en cada cabecera o en cada body de las llamadas HTTP

93
00:09:21,120 --> 00:09:26,360
gestionar la blacklist con Redis también fue un reto

94
00:09:26,360 --> 00:09:32,259
y asegurarnos que JWT Outfilter interceptaba correctamente todas las peticiones.

95
00:09:33,600 --> 00:09:39,419
Como ya he comentado antes, toda la sincronización del front y el back fue un tema súper complicado

96
00:09:39,419 --> 00:09:47,259
ya que no encontrábamos la forma de coordinar las respuestas de las llamadas del cliente

97
00:09:48,000 --> 00:09:51,840
o cuáles eran lo que requería una petición.

98
00:09:51,840 --> 00:09:54,960
Todo este problema lo solucionamos con Swagger

99
00:09:54,960 --> 00:09:59,659
Haciendo una documentación de la API en Java

100
00:09:59,659 --> 00:10:02,059
Para que así nuestro compañero Iván

101
00:10:02,059 --> 00:10:06,399
Que fue el que se encargó de todo el tema del front de la aplicación

102
00:10:06,399 --> 00:10:10,120
Tuviese en todo momento claro que es lo que iba a recibir

103
00:10:10,120 --> 00:10:13,360
Y que es lo que tenía que mandar para que todo funcionase correctamente

104
00:10:13,360 --> 00:10:20,840
En mi caso el problema que tuve fue WebSocket y Firebase

105
00:10:20,840 --> 00:10:25,340
en WebSocket tenía el problema de que era una tecnología nueva

106
00:10:25,340 --> 00:10:29,279
y que no conocíamos de antes, pero que queríamos utilizar para darle servicio

107
00:10:29,279 --> 00:10:33,500
un buen servicio al usuario, entonces fue el problema de encontrarse

108
00:10:33,500 --> 00:10:37,340
con algo nuevo que no habíamos dado antes, tener que aprenderlos para poder

109
00:10:37,340 --> 00:10:40,220
darle ese servicio bueno, y las notificaciones

110
00:10:40,220 --> 00:10:45,080
básicamente más de lo mismo, Firebase te da muchas facilidades

111
00:10:45,080 --> 00:10:49,279
pero igualmente tienes que meterte a aprender algo nuevo

112
00:10:49,279 --> 00:10:52,279
para poder darle algo bueno al usuario

113
00:10:52,279 --> 00:10:57,620
En mi caso también el mayor principal fue el desconocimiento

114
00:10:57,620 --> 00:10:59,799
y el tener que aprender algo nuevo desde cero

115
00:10:59,799 --> 00:11:04,639
porque el tema del frontend como he dicho lo hemos decidido desarrollar con Dart

116
00:11:04,639 --> 00:11:07,220
que es un lenguaje de programación completamente nuevo

117
00:11:07,220 --> 00:11:10,419
porque queríamos que en todo momento la aplicación pudiera ser desplegada

118
00:11:10,419 --> 00:11:11,879
tanto para Android como para iPhone

119
00:11:11,879 --> 00:11:14,980
entonces esto fue un reto desde el principio

120
00:11:14,980 --> 00:11:23,860
porque sobre todo al inicio tenía que aprender cómo funcionaba Flutter, todo el tema de CleanCode y de absolutamente todo

121
00:11:23,860 --> 00:11:26,299
y creo que ese ha sido el mayor problema con el que yo me he tenido que encontrar.

122
00:11:26,860 --> 00:11:30,299
Y ahora vamos a ver cómo se vería la aplicación en un móvil, en este caso en un emulador.

123
00:11:30,559 --> 00:11:34,700
Vamos a demostrar que cuando inicias sesión, si no te has registrado, pues no podrías hacerlo.

124
00:11:35,700 --> 00:11:42,720
Y vamos a hacer la lógica de registrarse en el cual al usuario le piden un nombre, un correo electrónico, una contraseña

125
00:11:42,720 --> 00:11:47,019
y un confirmar contraseña, la contraseña tendría que ser de 8 caracteres mínimo

126
00:11:47,019 --> 00:11:49,860
y tendría que coincidir evidentemente con el confirmar contraseña

127
00:11:49,860 --> 00:11:52,740
y el email, hemos creado un email de prueba

128
00:11:52,740 --> 00:11:58,299
el usuario introduciría su email personal y le llegaría un código de verificación

129
00:11:58,299 --> 00:12:02,379
y en el momento en el que el código de verificación se introdujera en esta pantalla

130
00:12:02,379 --> 00:12:04,740
pues se activaría la cuenta y podría iniciar sesión

131
00:12:04,740 --> 00:12:10,820
vamos a recibir aquí el código y lo vamos a introducir en la aplicación

132
00:12:10,820 --> 00:12:19,909
y con esto lo que conseguiríamos sería activar la cuenta

133
00:12:19,909 --> 00:12:23,230
si no se introdujera este código no se podría activar la cuenta

134
00:12:23,230 --> 00:12:25,210
y no podrías iniciar sesión, prueba TFG

135
00:12:25,210 --> 00:12:28,190
y vamos a introducir la contraseña

136
00:12:28,190 --> 00:12:32,070
y esto sería lo primero que encontraría el usuario nada más iniciar la sesión

137
00:12:32,070 --> 00:12:36,210
esto sería lo que se encontraría el usuario al iniciar sesión por primera vez

138
00:12:36,210 --> 00:12:39,570
al no tener ningún amigo todavía añadido

139
00:12:39,570 --> 00:12:41,950
pues la aplicación palabra no tendría mucho sentido

140
00:12:41,950 --> 00:12:44,029
pero encontraríamos un apartado de álbumes

141
00:12:44,029 --> 00:12:48,490
Un apartado de eventos, tanto participando como para descubrir los de tus próximos amigos

142
00:12:48,490 --> 00:12:56,409
Un apartado social, en el cual vamos a agregarnos a la cuenta de Ethan para demostrar cómo funciona la aplicación

143
00:12:56,409 --> 00:12:59,669
Pero también podrías ver tus amigos, invitaciones a eventos y solicitudes enviadas

144
00:12:59,669 --> 00:13:04,850
Y un apartado del perfil, con el cual iremos próximamente, pero que este sería la primera visualización

145
00:13:04,850 --> 00:13:08,590
Vamos a agregar ahora en buscar personas, vamos a buscar a Ethan

146
00:13:08,590 --> 00:13:12,830
Que al estar ya registrado, simplemente lo que haríamos sería enviarle una solicitud de amistad

147
00:13:12,830 --> 00:13:19,830
Y ahora al entrar en la cuenta de Ethan agregaríamos a esta cuenta y pasaríamos con todo el tema de los eventos y de toda esta lógica.

148
00:13:20,509 --> 00:13:32,610
Ahora estaríamos en la cuenta de Ethan, este álbum por ahora lo vamos a ignorar, lo que queremos enseñar es que te llegaría un 1 en el apartado social y te saltaría una solicitud de amistad pendiente en la cual te aguardaría el perfil de prueba TFG y podrías tanto aceptarle como rechazarle.

149
00:13:32,610 --> 00:13:36,330
en este caso vamos a aceptarle y vamos a crear un evento de prueba

150
00:13:36,330 --> 00:13:40,289
aquí y vamos a ponerlo

151
00:13:40,289 --> 00:13:43,929
tanto un nombre, puedes añadirle una descripción y una ubicación

152
00:13:43,929 --> 00:13:47,049
para que los usuarios puedan saber dónde se van a hacer los planes

153
00:13:47,049 --> 00:13:50,309
y puedan decidir a qué planes les puede interesar más unirse o no

154
00:13:50,309 --> 00:13:54,490
en el apartado de visibilidad se puede poner tanto público como privado

155
00:13:54,490 --> 00:13:57,110
como solo para amigos, en este caso lo vamos a poner solo para amigos

156
00:13:57,110 --> 00:14:01,450
para que la cuenta que acabamos de crear

157
00:14:01,450 --> 00:14:07,110
se pueda unir al plan y podamos enseñar toda la lógica social que tiene nuestra aplicación

158
00:14:07,110 --> 00:14:11,169
tienes para elegir la hora a la que inicia el evento y la hora a la que finaliza

159
00:14:11,169 --> 00:14:16,370
y entonces simplemente vamos a crear el plan y ahora vamos a unirnos desde la otra cuenta

160
00:14:16,370 --> 00:14:20,649
que sería la de prueba.tfg y vamos a pasar con el tema del evento

161
00:14:20,649 --> 00:14:24,450
vamos a crear el plan y vamos a enseñar cómo aparecería la pantalla del plan

162
00:14:24,450 --> 00:14:27,350
una vez la creas siendo tú el administrador

163
00:14:27,350 --> 00:14:30,190
esto es lo que se encontraría el organizador del evento una vez creado

164
00:14:30,190 --> 00:14:33,450
encontraría una primera card con la posibilidad de editar y eliminar el evento

165
00:14:33,450 --> 00:14:36,269
un apartado de gente en la cual por ahora solo estaríamos nosotros

166
00:14:36,269 --> 00:14:38,809
porque todavía no nos hemos unido desde la otra cuenta

167
00:14:38,809 --> 00:14:42,090
un apartado de un chat en el cual podríamos enviar mensajes

168
00:14:42,090 --> 00:14:46,029
un apartado del álbum que ya estaría desbloqueado porque ya habría iniciado la aplicación

169
00:14:46,029 --> 00:14:50,549
y un apartado de gastos en el cual en un futuro enseñaremos

170
00:14:50,549 --> 00:14:53,210
cuando sea una prueba TFG cómo funcionaría

171
00:14:53,210 --> 00:14:56,350
bueno y ahora acabaríamos de iniciar sesión otra vez en prueba TFG

172
00:14:56,350 --> 00:14:59,870
entonces en el apartado de eventos no saldría nadie participando

173
00:14:59,870 --> 00:15:03,950
pero al entrar en descubrir aparecerá la prueba que acaba de crear Ethan desde la cuenta de Ethan

174
00:15:03,950 --> 00:15:07,149
y saldrá la posibilidad de unirnos al evento ya que somos amigos de Ethan.

175
00:15:08,149 --> 00:15:11,210
Podríamos ver que ahora se movería participando una vez actualizado

176
00:15:11,210 --> 00:15:16,830
y en el apartado de gente ya apareceríamos nosotros también con Ethan con una estrellita

177
00:15:16,830 --> 00:15:21,870
ya que es el organizador del chat, digo del evento perdón, y cuando haya muchos usuarios está bien saber quién es el que lo organiza.

178
00:15:22,409 --> 00:15:29,070
El apartado chat en el cual podemos enviar mensajes y simplemente pues se enviaría, aquí lo vamos a ver,

179
00:15:29,870 --> 00:15:33,490
Y el apartado de álbum en el cual podremos subir una foto

180
00:15:33,490 --> 00:15:38,590
Vamos a subirlo desde la galería ya que al estar en un emulador no funciona la cámara

181
00:15:38,590 --> 00:15:44,070
Pero también existe la posibilidad de subir fotos desde la cámara

182
00:15:44,070 --> 00:15:45,929
Aquí se estarían subiendo las fotos

183
00:15:45,929 --> 00:15:50,649
Estas fotos, Izan no podría verlas hasta que finalizara el evento

184
00:15:50,649 --> 00:15:52,990
En el momento en el que se desbloquearían todas las fotos

185
00:15:52,990 --> 00:15:54,549
Y podría verlas

186
00:15:54,549 --> 00:15:58,029
También vamos a crear un gasto, en este caso de 15€

187
00:15:58,029 --> 00:16:19,049
Es una lógica muy básica, simplemente puedes elegir si es un reparto equitativo o personalizado, depende de quien quiera pagar más, pero al crear el gasto simplemente se dividiría en este caso entre dos y se generaría un resumen diciendo que prueba TFG le debería 7,50€ a ISAN ya que se han pagado 15€ por parte de ISAN y al dividirlo entre dos, una lógica bastante básica.

188
00:16:19,049 --> 00:16:38,730
Aquí cabe decir que en este ejemplo es una prueba bastante sencilla, como ha dicho Iván. El tema sería que con muchos más participantes y gastos más complejos, en los que solo tienen que unos pagar a alguien, reduciría mucho el tiempo en repartir estos gastos y estas deudas.

189
00:16:39,830 --> 00:16:47,450
No vamos a hacerlo aquí por falta de tiempo en el vídeo, pero es una herramienta bastante útil y que se aprecia que esté aquí.

190
00:16:47,450 --> 00:16:56,590
Ahora desde la cuenta de Ethan vamos a subir una foto para demostrar que a nosotros no nos aparecerían las fotos que ha subido Prueba TFG hasta finalizar el evento

191
00:16:56,590 --> 00:17:03,230
Una vez finalizado el evento te saldría la posibilidad de compartir las fotos solamente con los participantes o en el feed

192
00:17:03,230 --> 00:17:08,069
En este caso vamos a elegir el feed ya que podríamos enseñar más lógica de la app

193
00:17:08,069 --> 00:17:12,890
Puedes elegir una portada, vamos a elegir una cualquiera y ahora veremos que puedes cambiarla

194
00:17:12,890 --> 00:17:19,569
También existe la posibilidad de descargarse las fotos y llevarlas a la galería con este botoncito de aquí

195
00:17:19,569 --> 00:17:25,769
Entonces ahora al entrar en la galería, ahí aparecería de nuevo esta nueva foto que se acaba de descargar nuevamente

196
00:17:25,769 --> 00:17:33,690
También vamos a entrar en el apartado de feed de álbumes para enseñar cómo estaría ahora mismo la portada

197
00:17:33,690 --> 00:17:35,869
Y cómo al cambiarla se actualizaría

198
00:17:35,869 --> 00:17:37,329
Ahora mismo estaría la cascada

199
00:17:37,329 --> 00:17:41,930
estaría la cascada y cuando vayamos al evento y al álbum

200
00:17:41,930 --> 00:17:45,269
podríamos efectivamente desde este botoncito de aquí

201
00:17:45,269 --> 00:17:47,529
cambiar la portada a la cascada ya estaba

202
00:17:47,529 --> 00:17:51,809
entonces vamos a poner cualquier otra, las flores mismamente

203
00:17:51,809 --> 00:17:55,589
y entrar otra vez al feed de álbumes

204
00:17:55,589 --> 00:17:57,670
y vamos a ver cómo se habrían puesto las flores

205
00:17:57,670 --> 00:18:01,150
también existiría la posibilidad de eliminar una foto subida

206
00:18:01,150 --> 00:18:03,950
si en el momento te arrepientes o no has querido subirla

207
00:18:03,950 --> 00:18:12,309
Entonces simplemente desaparecería la foto y ya nos aparecería en el álbum y nos aparecerían las fotos tanto de Izan como de Prueba TFG como hemos podido contemplar.

208
00:18:12,309 --> 00:18:27,690
Vamos a ir ahora al apartado de perfil en el cual aquí teníamos nuestro perfil con el álbum que hemos subido, que teníamos la posibilidad de borrarlo del perfil si quisiéramos y también teníamos la posibilidad de editar el perfil para añadirle los datos que tú desees.

209
00:18:27,690 --> 00:18:31,009
puedes cambiar la foto que tienes puesta y añadirle una foto cualquiera

210
00:18:31,009 --> 00:18:33,890
un nombre y puedes quitarle lo de prueba

211
00:18:33,890 --> 00:18:36,930
para demostrar que se puede crear el perfil como tú quieras

212
00:18:36,930 --> 00:18:39,170
que se quede, en caso de que hayas escrito algo por error o lo que sea

213
00:18:39,170 --> 00:18:41,069
pues aquí simplemente se quedaría actualizado

214
00:18:41,069 --> 00:18:44,970
también tenemos una portada de ajustes con las siguientes posibilidades

215
00:18:44,970 --> 00:18:48,029
vamos a enseñar que en seguridad y contraseña tendrías para cambiar la contraseña

216
00:18:48,029 --> 00:18:51,009
actualizar el email o eliminar la cuenta que no es algo que vayamos a hacer

217
00:18:51,009 --> 00:18:53,150
ahora mismo porque es la cuenta de Izan

218
00:18:53,150 --> 00:18:56,329
puedes ver los dispositivos desde los que has entrado en la cuenta

219
00:18:56,329 --> 00:19:02,029
este es de uno de hace una hora, que sería el móvil de Ethan, y este sería el que estamos usando ahora mismo.

220
00:19:02,609 --> 00:19:08,930
Tienen la posibilidad de poner el perfil tanto en público como en privado, simplemente al pulsar ahí se cambiaría,

221
00:19:09,509 --> 00:19:13,329
y también puedes cerrar sesión y eliminar la cuenta desde aquí para que sea más intuitivo para el usuario.

222
00:19:14,690 --> 00:19:20,369
Ahora os vamos a hablar de las conclusiones de cada una a raíz de haber hecho este proyecto.

223
00:19:20,369 --> 00:19:29,450
y bueno, en mi opinión personal lo que más me ha gustado es la capacidad de haber desarrollado un proyecto tan grande como es este

224
00:19:29,450 --> 00:19:35,309
no habíamos hecho algo de esta magnitud hasta ahora y luego toda la parte de producción

225
00:19:35,309 --> 00:19:42,430
nosotros habíamos trabajado en el proceso anterior que es todo el proceso de desarrollo y tal

226
00:19:42,430 --> 00:19:49,609
pero ponerse en la situación real de despliegue de una aplicación, variables de entorno

227
00:19:49,609 --> 00:19:56,589
tener cuidado con qué es lo que se sube al GitHub, que no hardcodear claves o keys

228
00:19:56,589 --> 00:20:02,509
y el poder tener una aplicación con un backend corriendo en la nube

229
00:20:02,509 --> 00:20:07,410
y poder tenerla desde el dispositivo y compartirla con amigos y compañeros.

230
00:20:10,250 --> 00:20:18,009
En mi caso, a mí, lo que me llevo de este proyecto es poder haber trabajado con un equipo real,

231
00:20:18,009 --> 00:20:26,750
poder haber trabajado con ellos dos, el hecho de haber tenido que aprender tantas cosas nuevas,

232
00:20:27,630 --> 00:20:37,630
tener unos estándares a nuestro parecer altos y que todo fluya de manera adecuada.

233
00:20:40,490 --> 00:20:47,869
El hecho también de eso, poder, como ha dicho Jason, tener un trabajo de esta magnitud que no nos habíamos encontrado antes,

234
00:20:48,009 --> 00:20:51,150
y la resolución

235
00:20:51,150 --> 00:20:52,269
de problemas es lo que me llevo

236
00:20:52,269 --> 00:20:55,109
la capacidad que tenemos cada uno de resolver

237
00:20:55,109 --> 00:20:56,210
los problemas a nuestra manera

238
00:20:56,210 --> 00:20:58,289
y hacerlo

239
00:20:58,289 --> 00:21:00,829
de manera, o sea, en tiempo

240
00:21:00,829 --> 00:21:04,049
En mi caso

241
00:21:04,049 --> 00:21:06,490
lo más principal sería

242
00:21:06,490 --> 00:21:08,390
evidentemente el reto de programar

243
00:21:08,390 --> 00:21:10,269
el frontend desde un lenguaje nuevo como es Dart

244
00:21:10,269 --> 00:21:12,690
porque al inicio es algo que evidentemente supone muchos problemas

245
00:21:12,690 --> 00:21:14,529
al no saber cómo funciona

246
00:21:14,529 --> 00:21:16,410
cómo estructurar el código

247
00:21:16,410 --> 00:21:17,509
y una larga lista, etc.

248
00:21:17,509 --> 00:21:28,210
Y más allá de eso me quedo con haber aprendido mucho acerca de GitHub, sobre las ramas, la develop, la main, el pull request y haber aprendido de esta metodología.

249
00:21:28,829 --> 00:21:40,849
También he aprendido mucho acerca de la metodología Scrum y cómo se distribuye el trabajo, todo el tema de las tareas, del desarrollo, el lista para testear, todo el tema de los sprints.

250
00:21:40,849 --> 00:21:43,130
y creo que es con lo que me quedaría

251
00:21:43,130 --> 00:21:45,329
que es con haber aprendido cómo gestionar

252
00:21:45,329 --> 00:21:47,710
de forma profesional este tipo de trabajos

253
00:21:47,710 --> 00:21:49,549
Bueno, pues nada

254
00:21:49,549 --> 00:21:51,269
este ha sido nuestro TFG

255
00:21:51,269 --> 00:21:53,329
espero que os haya gustado tanto corregirlo

256
00:21:53,329 --> 00:21:55,089
como a nosotros hacerlo

257
00:21:55,089 --> 00:21:57,109
y nada, ha sido un proyecto enorme

258
00:21:57,109 --> 00:21:58,750
y súper enriquecedor para nosotros

259
00:21:58,750 --> 00:22:01,430
con esto nos podemos despedir

260
00:22:01,430 --> 00:22:02,349
¡Te busco un bote!

261
00:22:02,950 --> 00:22:03,450
¡Muchas gracias!