Meeting 16 03 2023
March 16th, 2023
- Iván Menéndez Mosegui
- David Martínez Castañón
- Guillermo Dylan Carvajal Aza
- Pelayo Reguera García
- Carlos Triana Fernández
- We presented a prototype version of the project.
- Notes with the prototype's feedback are in the teams of the group.
- We talked about the colors of the app and the visuals. We agreed on a rounded edges for the app tabs.
- We have to consider implementing a parser and a class that will convert our app objects into things before uploading to the POD and vice-versa.
- We have to look for information about changing permissions of the PODs from the app.
- We checked a functionality about creating symbolic links between PODs.
- We have talked about how to design the Maps in the app. The first steps leads us to implement maps that will be "created" in runtime with the points from the public places, from the friends places or from the personal places. The other approach is by making collections of places. This approach is more complex, more versatile but may not be possible.
Technical debt of improving permissions, what we want to share. What happens if I enter in your application what do I can do?
This is what he expected. We have a package and a package.json on the root. The proper flow of the pull request should not have been approved if there are bugs in master or develop branches.
Use the repository more. If he tells us to create issues is not creating, doing and closing it. It should evolve. With some kind of functionality or thing should have a discussion. Do not do that discussion on Whatsapp. Do it in the repository. If there is research, it should be on the issue. The solution of the issue should also be there. The process, the problems. In order to someone to look for it in the repository. The pull requests should prevent code not good not to go to master. Not I approved because some told me so. In serious companies, programmers spend more time reviewing code than creating it. It is an example. More in depth checks. Even tough someone is writing code isolated, issues and discussions are useful in the future.
He doesn’t see any difference.
Interoperability, not discussed yet, but will be soon.
Corre el riesgo de que intentemos implementar una funcionalidad que no es posible. Pablo dijo que cómo grupo no debieramos dedicar todos los recursos a algo que puede que no sea posible. Todo ello por el desconocimiento de la tecnología.
Colores de la app. Efectos y diseño, redondeado de las pestañas. Things y parser: Estamos consideramos hacer un assembler para pasar diferentes objetos a Pod. Guardar las imágenes en el POD. Buscar informacion si desde nuestra aplicación se puede cambiar los permisos de privacidad de un archivo.
La presentación (La preparación, no tardar en empezar, la profesionalidad ). Como se trabaja en el git. El depliege. Como se ve (Que sea usable) sino es un 5. La calidad del código. Y documentación. Tests.
Tenemos mapas públicos con lugares privados
