Roger Tito —
Desarrollador web full-stack

Mi rol

Equipo de cuatro. Participé en las cinco fases, de la exploración del reto a la presentación final.Equipo de cuatro personas. Participé en las cinco fases del programa, desde la exploración del reto hasta la presentación final ante la empresa y el jurado.

Las cinco fases

1. 01

   Retos y exploración — entender el problema real antes de proponer nada.

2. 02

   Creatividad — abrir opciones y descartar lo que no resiste al negocio.

3. 03

   Prototipaje — bajar la idea a algo que se pueda enseñar.

4. 04

   Aceleradora — afinar la propuesta con empresa y programa.

5. 05

   Presentaciones finales — defender el resultado ante el jurado.

1. 01

   Retos y exploración — entender el problema real de la empresa antes de proponer nada.

2. 02

   Creatividad — abrir opciones y descartar las que no resisten el contacto con el negocio.

3. 03

   Prototipaje — bajar la idea a algo que se pueda enseñar y probar.

4. 04

   Aceleradora — afinar la propuesta con el acompañamiento del programa y la empresa.

5. 05

   Presentaciones finales — defender el resultado ante la empresa y el jurado.

Mi rol

Uno de los cuatro desarrolladores, con 71 commits. Modelo, vista, controlador y parte de la documentación técnica.Uno de los cuatro desarrolladores, con 71 commits sobre el repositorio. Toqué modelo, vista y controlador, y me ocupé de parte de la documentación técnica del proyecto.

Decisiones técnicas

1. 01

   MVC a mano en PHP, con el acceso a MySQL centralizado en una clase Database con PDO.

2. 02

   Consultas preparadas, password_hash y control de acceso por sesión y rol.

3. 03

   API JSON de eventos con códigos HTTP reales y permisos por propietario.

1. 01

   MVC a mano en PHP: el acceso a MySQL centralizado en una clase Database con PDO, y controladores separados para usuarios y eventos.

2. 02

   Seguridad de base y no como extra: consultas preparadas contra inyección SQL, contraseñas con password_hash / password_verify y control de acceso por sesión y rol.

3. 03

   API JSON para leer y borrar eventos, respondiendo con códigos HTTP reales y comprobando que quien borra es el organizador propietario.

Mi rol

Proyecto propio: decisiones técnicas, implementación y despliegue. Cada cifra sale del propio build.Proyecto propio: las decisiones técnicas, la implementación y el despliegue. Cada cifra de este caso sale del propio build, así que se puede comprobar sin fiarse de mí.

Decisiones técnicas

1. 01

   Workers con assets estáticos en vez de Pages: deja sitio para Cron, Queues y logs sin migrar nada.

2. 02

   Shader WebGL sin librería en el hero, con una composición CSS equivalente debajo para quien no tenga WebGL o pida menos movimiento.

3. 03

   El tramado es un filtro CSS, no un paso de build.

4. 04

   Las imágenes las prepara el Chromium de la máquina, no sharp: ni una dependencia nueva.

5. 05

   i18n nativa de Astro y en.json tipado contra es.json: si falta una clave, no compila.

1. 01

   Workers con assets estáticos en vez de Pages — hoy hacen lo mismo, pero deja sitio para Cron, Queues y logs sin migrar nada.

2. 02

   El fondo del hero es un shader WebGL sin librería detrás, con una composición CSS equivalente debajo: sin WebGL, o con «reducir movimiento» activado, la página se ve igual y no descarga nada extra.

3. 03

   El tramado de las imágenes es un filtro CSS, no un paso de build: cambiar el tratamiento es editar una regla, no reprocesar los archivos.

4. 04

   Las imágenes las prepara el Chromium que ya hay en la máquina en lugar de añadir sharp: redimensionado, logos a un color, el .ico y las tarjetas para compartir, todo sin una dependencia nueva.

5. 05

   La i18n es el enrutado nativo de Astro con diccionarios JSON, y en.json está tipado contra es.json — si falta una clave, no compila.