Ranking de Estudiantes¶

Spring Boot + Hibernate — De Java a Docker

Ultima actualizacion: 2026-04-03 20:45 | Evaluacion automatica

Estadisticas del Curso

13

Estudiantes

12

Aprobados

7.6

Promedio

9

Destacados

Leaderboard

#2

@gacastroo

9.1↑ +1.1⚠ -5%

E

3

A

24

⚙ Docker + Compose

Docker ProCI/CDPipeline Verde3 Entidades

Ver Proyecto 🚀 Live Demo

Ver sugerencias (2)

No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Tienes una URL de deploy pero no responde. Verifica que tu app este corriendo en Railway/Render y que el puerto este bien configurado.

#1

@jcherrerasan

9.5↑ +1.0⚠ -5%

E

6

A

28

⚙ Docker + Compose

Docker ProCI/CDPipeline Verde6 Entidades

Ver Proyecto

Ver sugerencias (1)

No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#3

@RafaelLibrero

8.9↑ +1.8⚠ -5%

E

4

A

16

⚙ Docker + Compose

Docker ProCI/CDPipeline Verde4 Entidades

Ver Proyecto 🚀 Live Demo

Ver sugerencias (2)

No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Tienes una URL de deploy pero no responde. Verifica que tu app este corriendo en Railway/Render y que el puerto este bien configurado.

Clasificados

#4

@LilitKhach

E

3

A

13

8.1

Ver Proyecto

Ver sugerencias (7)

Tienes mas controllers (7) que services (3). Cada controller deberia delegar en su service.
No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales.
Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar.
Tu README le faltan secciones clave: Capturas de pantalla
Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona.
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#5

@fdezgj

E

5

A

17

7.8

Ver Proyecto

Ver sugerencias (6)

Tienes mas controllers (7) que services (5). Cada controller deberia delegar en su service.
Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales.
No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push.
Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar, Endpoints / API, Capturas de pantalla
Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona.
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#6

@miguelitomola

E

5

A

19

7.8

Ver Proyecto

Ver sugerencias (7)

No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response.
No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Tienes Dockerfile pero no .dockerignore. Anadelo para excluir target/, .git/, .env y que la imagen sea mas ligera.
No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push.
Tu README le faltan secciones clave: Tecnologias usadas, Capturas de pantalla
Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona.
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#7

@javierfajardo01

E

4

A

14

7.6

Ver Proyecto

Ver sugerencias (7)

Tienes mas controllers (6) que services (4). Cada controller deberia delegar en su service.
No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response.
No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales.
No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push.
Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#8

@M4RCOSARDID

E

4

A

14

7.5

Ver Proyecto

Ver sugerencias (8)

Tienes mas controllers (6) que services (4). Cada controller deberia delegar en su service.
No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response.
Solo tienes 2 archivo(s) de test. Intenta cubrir al menos los services principales.
Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar.
No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push.
Tu README le faltan secciones clave: Capturas de pantalla
Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona.
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#9

@Fraile256

E

4

A

14

7.2

Ver Proyecto

Ver sugerencias (9)

Tienes mas controllers (6) que services (4). Cada controller deberia delegar en su service.
Tienes relaciones basicas pero no usas cascade, fetch strategies ni @ManyToMany. Anade complejidad a tus relaciones.
No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response.
No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales.
Tienes Dockerfile pero no .dockerignore. Anadelo para excluir target/, .git/, .env y que la imagen sea mas ligera.
Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar.
No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push.
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

#10

@MauGlezGar

E

4

A

11

6.2

Ver Proyecto

Ver sugerencias (10)

Tienes 4 entidades pero solo 2 controllers. Idealmente cada entidad tiene su controller.
No tienes GlobalExceptionHandler (@RestControllerAdvice). Sin el, los errores devuelven un stack trace feo al cliente. Crea uno.
No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario).
Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales.
Tienes Dockerfile pero no .dockerignore. Anadelo para excluir target/, .git/, .env y que la imagen sea mas ligera.
Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar.
No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push.
Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar, Endpoints / API, Capturas de pantalla
Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona.
No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

Ranking Completo

Pos	Estudiante	Nota	Delta	Estado	Proyecto	Enlace	Demo
#1	@jcherrerasan	9.5 ⚠-5%	↑ +1.0	★ Destacado	`Domus_Asesores`	Ver	—
Ver sugerencias (1) No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#2	@gacastroo	9.1 ⚠-5%	↑ +1.1	★ Destacado	`Escape_Room`	Ver	Live
Ver sugerencias (2) No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Tienes una URL de deploy pero no responde. Verifica que tu app este corriendo en Railway/Render y que el puerto este bien configurado.
#3	@RafaelLibrero	8.9 ⚠-5%	↑ +1.8	★ Destacado	`BoxBoxApi-Spring`	Ver	Live
Ver sugerencias (2) No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Tienes una URL de deploy pero no responde. Verifica que tu app este corriendo en Railway/Render y que el puerto este bien configurado.
#4	@LilitKhach	8.1	—	★ Destacado	`analizador-de-contratos`	Ver	—
Ver sugerencias (7) Tienes mas controllers (7) que services (3). Cada controller deberia delegar en su service. No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar. Tu README le faltan secciones clave: Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#5	@fdezgj	7.8	—	★ Destacado	`Biblioteca`	Ver	—
Ver sugerencias (6) Tienes mas controllers (7) que services (5). Cada controller deberia delegar en su service. Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar, Endpoints / API, Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#6	@miguelitomola	7.8	—	★ Destacado	`centro-de-dia-api`	Ver	—
Ver sugerencias (7) No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response. No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Tienes Dockerfile pero no .dockerignore. Anadelo para excluir target/, .git/, .env y que la imagen sea mas ligera. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Tecnologias usadas, Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#7	@javierfajardo01	7.6	—	★ Destacado	`cine-estrella`	Ver	—
Ver sugerencias (7) Tienes mas controllers (6) que services (4). Cada controller deberia delegar en su service. No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response. No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#8	@M4RCOSARDID	7.5	—	★ Destacado	`sala-conciertos`	Ver	—
Ver sugerencias (8) Tienes mas controllers (6) que services (4). Cada controller deberia delegar en su service. No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response. Solo tienes 2 archivo(s) de test. Intenta cubrir al menos los services principales. Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#9	@Fraile256	7.2	—	★ Destacado	`brisca`	Ver	—
Ver sugerencias (9) Tienes mas controllers (6) que services (4). Cada controller deberia delegar en su service. Tienes relaciones basicas pero no usas cascade, fetch strategies ni @ManyToMany. Anade complejidad a tus relaciones. No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response. No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. Tienes Dockerfile pero no .dockerignore. Anadelo para excluir target/, .git/, .env y que la imagen sea mas ligera. Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#10	@MauGlezGar	6.2	—	✓ Aprobado	`Basket-Nba`	Ver	—
Ver sugerencias (10) Tienes 4 entidades pero solo 2 controllers. Idealmente cada entidad tiene su controller. No tienes GlobalExceptionHandler (@RestControllerAdvice). Sin el, los errores devuelven un stack trace feo al cliente. Crea uno. No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. Tienes Dockerfile pero no .dockerignore. Anadelo para excluir target/, .git/, .env y que la imagen sea mas ligera. Tienes docker-compose pero no .env.example. Crea uno para que otros sepan que variables de entorno necesitan configurar. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar, Endpoints / API, Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

▼ Mostrar ranking completo (2 estudiantes mas)

Pos	Estudiante	Nota	Delta	Estado	Proyecto	Enlace	Demo
#11	@blnfern	6.0 ⚠-5%	↑ +0.9	✓ Aprobado	`paqueteria-spring`	Ver	—
Ver sugerencias (10) Tienes mas controllers (10) que services (8). Cada controller deberia delegar en su service. No usas Bean Validation (@Valid, @NotNull, @NotBlank...). Anade validaciones a tus entidades o DTOs para evitar datos basura. No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response. Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. No tienes Dockerfile. Es imprescindible para desplegar. Crea un Dockerfile multi-stage para tu app Spring Boot. No tienes docker-compose.yml. Con el puedes levantar tu app + base de datos con un solo comando. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar, Endpoints / API, Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.
#12	@RaulVelasco21	5.2	—	✓ Aprobado	`futbol-primera`	Ver	—
Ver sugerencias (11) Tienes relaciones basicas pero no usas cascade, fetch strategies ni @ManyToMany. Anade complejidad a tus relaciones. No tienes GlobalExceptionHandler (@RestControllerAdvice). Sin el, los errores devuelven un stack trace feo al cliente. Crea uno. No usas DTOs. Exponer las entidades JPA directamente en la API es mala practica — crea clases DTO para request/response. No tienes enums. Usa enums para estados, tipos, categorias... en vez de Strings sueltos (ej: EstadoPedido, TipoUsuario). Solo tienes 1 archivo(s) de test. Intenta cubrir al menos los services principales. No tienes Dockerfile. Es imprescindible para desplegar. Crea un Dockerfile multi-stage para tu app Spring Boot. No tienes docker-compose.yml. Con el puedes levantar tu app + base de datos con un solo comando. No tienes CI/CD (GitHub Actions). Crea .github/workflows/ci.yml para que tu proyecto se construya automaticamente en cada push. Tu README le faltan secciones clave: Descripcion del proyecto, Tecnologias usadas, Como ejecutar, Capturas de pantalla Anade capturas de Swagger UI en tu README (docs/screenshots/). Demuestra visualmente que tu API funciona. No tienes deploy en vivo. Despliega en Railway (gratis) para que cualquiera pueda probar tu API sin instalar nada.

Distribucion de Notas

9-10 Excelente

2

7-8 Notable

7

5-6 Aprobado

3

<5 Insuficiente

λ Guia de lectura

E

E (Entidades) — Numero de entidades JPA (@Entity) con relaciones.

A

A (API) — Capas Spring Boot: Controllers + Services + Repositories.

8.3

Nota — Nota final (0-10). Combina entidades JPA (17%) + calidad de codigo (17%) + API REST (15%) + estructura Spring Boot (12%) + Docker (10%) + documentacion (8%) + CI/CD (7%) + dependencias (5%) + tests (5%) + deploy en vivo (4%).

↑ +1.0

Delta — Cambio respecto a la evaluacion anterior. Flecha verde hacia arriba = mejora. Flecha roja hacia abajo = la nota bajo (por ejemplo, si el alumno borro codigo de su repo).

⚠ -5%

Penalizacion tardia — Solo aparece si el alumno mejoro su proyecto despues del periodo de gracia (fin de semana post Demo Day). El porcentaje se aplica unicamente sobre la mejora, no sobre la nota base. Ejemplo: si la nota base fue 8.5 y la mejora bruta da 9.6, con -5% la mejora de +1.1 se reduce a +1.0, quedando 9.5 final.

⚙ Criterios de Evaluacion

Δ Promocion 2026 (11 alumnos)

Curso IFCD0014 — Spring Boot + Hibernate (75h). Cada alumno elige 1 de 16 blueprints y construye una API REST completa con Spring Boot, JPA, Docker y CI/CD. Demo Day: 19 marzo 2026.

Σ Desglose de la Nota

Entidades JPA (17%) + Calidad de codigo (17%) + API REST (15%) + Estructura Spring Boot (12%) + Docker (10%) + Documentacion (8%) + CI/CD (7%) + Dependencias (5%) + Tests (5%) + Deploy en vivo (4%). Proyectos copiados del ejemplo del profesor reciben penalizacion.

∞ Comunidad

Cualquiera puede hacer fork del repositorio, completar el curso y aparecer en el ranking. Mismos criterios de evaluacion.

El ranking se actualiza con cada evaluacion. Sube tu proyecto para aparecer!
Generado por: QUASAR (Quality Unified Automated Student Assessment & Ranking) | 2026-04-03 20:45

Curso: IFCD0014 — Spring Boot + Hibernate (75h) — De Java a Docker Profesor: Juan Marcelo Gutierrez Miranda | @TodoEconometria Metodologia: 16 blueprints de proyectos reales, evaluacion automatica, CI/CD con GitHub Actions

Referencias: - Walls, C. (2022). Spring in Action, 6th Ed. Manning Publications. - Bauer, C. & King, G. (2015). Java Persistence with Hibernate, 2nd Ed. Manning. - Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.