¡Únete a nuestra comunidad de voluntarios y marca la diferencia! Descubre cómo puedes contribuir a un mundo inclusivo.

Presentación de Polaris - Polaris, fue creado con la firme convicción de promover un mundo inclusivo y colaborativo.

Reconocemos que muchas personas enfrentan dificultades y barreras en su día a día debido a diversas discapacidades. El problema que este proyecto resuelve es la falta de acceso a apoyo especializado y personalizado para estas personas.

Polaris conecta a voluntarios apasionados con instituciones educativas que atienden a individuos con diversas dificultades y discapacidades, logrando que reciban la atención y el apoyo que merecen.

Al unir fuerzas, creamos una comunidad donde cada voluntario puede contribuir con sus habilidades únicas y donde cada persona con discapacidad puede recibir un cuidado más integral y compasivo. De esta manera, Polaris abre puertas y derriba barreras.

Puedes visitar nuestra página web aquí:

🌟 Polaris ♿

✔ BackEnd

👉🏻 Lista de Tareas ✅

• Desarrollo de una API REST con Java y Spring-Boot.
• Crear una base de datos Postgre en Render.
• Desplegar la API en Render.
• Validación de usuarios con JWT construido y firmado en la aplicación.
• Crear filtros con expresiones regulares y reglas JPA/Hibernate.
• Documentación de la API en Swagger3.
• Puntos finales (endpoints) y servicios completamente probados.
• Contenerización en Docker para ejecutar localmente.

👉🏻 Normas de código 📜

• Ten en cuenta las reglas del Google Java Style Guide.
• El código debe estar escrito en inglés.
• Los controladores deben terminar con el sufijo "Controller". Ejemplo: UserController.
• Los servicios deben terminar con el sufijo "Service". Ejemplo: UserService.
• Los repositorios deben terminar con el sufijo "Repository". Ejemplo: UserRepository.
• Las implementaciones de interfaces deben terminar con el sufijo "Impl". Ejemplo: UserServiceImpl.
• Los objetos de transferencia de datos (DTOs) deben terminar con el sufijo "Dto". Ejemplo: UserDto, UserRequestDto.
• El uso de DTOs es obligatorio. Pueden existir DTOs para las solicitudes y respuestas.
• Los nombres de paquetes están en singular.
• Los nombres de atributos/campos de las clases de Java deben estar escritos utilizando notación camel case. Ejemplo: firstName.
• Los nombres de columnas en las entidades deben estar escritos utilizando guiones bajos y en mayúsculas. Ejemplo: FIRST_NAME. El nombre de las tablas siempre debe estar en plural, pero el nombre de la entidad debe estar en singular.
• Las excepciones deben ser manejadas por una implementación de ControllerAdvice.
• Los mensajes para el usuario no deben estar codificados directamente, sino que deben ser manejados a través de un recurso externo. Algunas referencias útiles aquí y aquí.
• Si agregas un nuevo endpoint, asegúrate de establecer el acceso de roles para él en la clase WebSecurity.

👉🏻 Documentación 📜

• Puedes leer la documentación de la API: Aqui.

👉🏻 Construida con 🛠️

👉🏻 Desarrolladores 👨🏻‍💻

Liliana Gallego	Dmitry Borovskikh	Eder Romero

Johana Elizabeth	Brayan Rodallega	Gonzalo Cocchetto

✔ FrontEnd

👉🏻 Lista de Tareas ✅

• Desarrollo de una aplicación front-end con Angular.
• Implementación de arquitectura de seguridad con interceptores JWT.
• Conexión con una API REST.
• Despliegue de front-end en Vercel.

👉🏻 Normas de código 📜

• El código debe estar escrito en inglés.
• Los nombres de los Componentes,Servicios,Modelos,Interfaces deben estan escritos utilizando la notacion Pascal case
• Los nombres de los Funcional Guard, Variables, Metodos y Propiedades deben estar escritos en la notacion Camel case
• Los componentes deben ser reutilizables, para que puedan ser utilizados en diferentes partes del proyecto. fomentando la modularidad y facilitando el mantenimiento.
• Cada componente o servicio debe tener una responsabilidad única y estar bien definido. Evita colocar demasiada lógica o estilos innecesarios en un solo componente.
• Para mantener un codigo limpio y desacoplado se debe utilizar la inyeccion de dependencias, para proporcionar instancias de servicios a los componentes que los necesitan.

👉🏻 Construido con 🛠️

👉🏻 Desarrolladores 👨🏻‍💻

Jafet Vazquez	Jose Armando Ccama Cruz	Federico Di Cillo

Juan Martin Cubells

✔ Testing

👉🏻 Lista de Tareas ✅

• Pruebas de diseño e integración.
• Pruebas de los endpoints de la API REST.
• Pruebas de los componentes del front-end e integración con el back-end.

👉🏻 Testeado con 🛠️

👉🏻 Testers 👨🏻‍💻

Johana Martinez

✔ UX/UI Design

👉🏻 Lista de Tareas ✅

• Diseño de la identidad de marca y logotipos.
• Creación de prototipos y mockups de baja calidad.
• Definición de colores, fuentes y estilos.
• Avanzar hacia prototipos de calidad media y desarrollo de componentes.
• Redacción de textos y copywriting.

👉🏻 Construido con 🛠️

👉🏻 Diseñador 👨🏻‍💻

Emmauel Aratto

✔ Flujo de Trabajo

👉🏻 Formato de Commits 📜

• Siempre crear la rama desde develop.
• El formato del nombre de la rama es: feature/{númeroDeTicketJira}.
• El formato del título de la solicitud de extracción (pull request) es: {númeroDeTicketJira}: {títuloDelTicketJira}.
• El formato de los commits es: {númeroDeTicketJira}: {descripciónDelCommit}. Los commits pequeños son un buen hábito.
• La solicitud de extracción (pull request) debe contener solo los cambios relacionados con el alcance definido en el ticket.
• Las solicitudes de extracción (pull requests) deben realizarse siempre desde tu rama actual hacia develop.

👉🏻 Formato de Ramas 📜

En el repositorio actual, encontrarás tres ramas diferentes:

• main -> esta rama es exclusivamente para versiones productivas, y contiene el historial oficial de lanzamientos.
• develop -> esta rama sirve como rama de integración para las características. Todas las características deben iniciar desde esta rama y, una vez finalizadas, se fusionan de vuelta en "develop".

Para comprender más sobre Git y cómo trabajar con diferentes ramas, te recomiendo leer sobre el flujo de trabajo Gitflow. Aquí tienes una breve explicación que puede servir como introducción.

👉🏻 Metodología de Desarrollo 🤝

• La duración de cada sprint es de una semana.
• Se realizan dos reuniones obligatorias con el líder del equipo por cada sprint.
• La reunión diaria tiene una duración máxima de 15 minutos.
• No se permiten tareas sin una épica asociada.
• Las épicas deben estar respaldadas por historias de usuario.
• Las tareas se asignan de acuerdo a su estimación.

👉🏻 Herramientas utilizadas 🛠️

👉🏻 Team Leader 👨🏻‍💻

Michael Liendo

---