🧪 POC 1 · "Hola PHP" — una página dinámica
un servidor web con PHP ejecuta código en cada pedido y devuelve HTML ya armado. No es un archivo estático: el contenido cambia solo.
⬇️ Descargar código
3 KB
Material descargable
Acá está el código de todos los POCs y ejercicios del curso, empaquetado pieza
por pieza. Bajate solo lo que necesites: cada zip trae su README.md con
los pasos para levantarlo.
Lo único que necesitás instalar es Docker. Ni PHP, ni Composer, ni MySQL: todo corre en contenedores.
La opción cómoda
Los 24 POCs y los 11 ejercicios juntos, ordenados por clase, con un índice adentro. Pesa 301 KB: se baja una vez y te lo llevás entero.
⬇️ Descargar todo (301 KB)Si solo querés lo de una clase puntual, bajá nada más esa pieza.
un servidor web con PHP ejecuta código en cada pedido y devuelve HTML ya armado. No es un archivo estático: el contenido cambia solo.
ver la sintaxis básica de PHP funcionando: tipos, operadores, arrays, funciones y las novedades de PHP 8. Es un script de consola pensado para ir recorriendo bloque por bloque.
El liquidador calcula todos los netos en cero. Hay que encontrar por qué — y ojo con el concepto que no es ni haber ni descuento.
en Laravel todo son clases (controllers, modelos, servicios…). Antes de tocar Laravel hay que entender POO. Este POC recorre los conceptos con un ejemplo cercano al proyecto del curso: empleados que se pueden liquidar.
con un comando, Composer nos arma un proyecto Laravel completo y funcional. Este proyecto es la semilla del Liquidador de RRHH que crece todo el curso.
Falta una clase. Hay que crearla en la ruta exacta que dicta PSR-4, o el autoload no la encuentra nunca.
una ruta conecta una URL con un controller, el controller prepara los datos y se los pasa a una vista. Ese es el triángulo MVC.
un middleware es un filtro por el que pasa la petición antes de llegar al controller. Puede dejarla pasar, modificarla o cortarla.
Una petición entra y no llega al controller. El programa imprime los 8 pasos del ciclo de vida para ver dónde se corta.
con Blade, el HTML deja de repetirse. Un layout se escribe una vez y todas las páginas lo heredan; un componente es una pieza reutilizable.
un formulario envía datos (POST), Laravel los valida, y si algo está mal vuelve al formulario con los errores y lo que el usuario ya había escrito. Si está todo bien, muestra un mensaje flash de éxito.
El alta acepta cualquier cosa, y un nombre con <script> termina ejecutándose en la pantalla del que mira el listado.
los datos "a mano" desaparecen. Ahora Laravel guarda y lee de una base de datos MySQL real, con el esquema definido por migraciones y datos de prueba cargados con seeders y factories.
el Query Builder arma consultas SQL de forma fluida y legible (where, orderBy, join, groupBy, agregaciones) sin escribir SQL a mano y protegiendo contra inyección.
Migraciones que corren en el orden equivocado, una clave foránea que no protege nada y una consulta que no dice lo que pidió RRHH.
con Eloquent cada tabla es un objeto. Un CRUD (alta, baja, modificación, listado) se escribe cortito y legible, y las relaciones se navegan con $empleado->departamento->nombre (¡sin JOINs a mano!).
Eloquent modela las relaciones del mundo real. En vez de JOINs, navegamos objetos: $empleado->cuenta, $empleado->liquidaciones[0]->conceptos, $empleado->proyectos.
Las tablas están, los modelos también, pero no se conocen. Y cada corrida CUENTA LAS CONSULTAS: el N+1 se ve en números.
el controller pide un contrato (interfaz), no una clase concreta. El Service Container de Laravel, siguiendo un binding, le entrega la implementación correcta ya construida. Cambiás el binding → cambia el comportamiento, sin tocar el controller.
la lógica de negocio no va en el controller. Va en un Service, que a su vez pide los datos a un Repository. El controller solo coordina. Controller → Service → Repository → datos.
Cada corrida dibuja el árbol de dependencias que arma el contenedor. Verifica el desacople inyectando un service impostor.
el Liquidador expone sus datos en JSON para que otros sistemas los consuman. Cada verbo HTTP hace una operación y devuelve el código de estado correcto.
así como exponemos una API (POC 1), también podemos consumir APIs de otros. Con el HTTP Client de Laravel (Http::get) pedimos datos a dolarapi.com y los mostramos en nuestra app.
Una API que contesta 200 para todo, y un cliente HTTP falso al que se le puede provocar una caída, una demora o una respuesta basura.
en una API no hay "sesión" como en la web. El usuario se loguea, recibe un token, y lo manda en cada pedido. Sin token válido, las rutas protegidas responden 401.
estar logueado no alcanza. La autorización decide qué puede hacer cada usuario. Con un Gate, una ruta solo la ven los administradores; el resto recibe 403.
El verificador ATACA: se loguea como un empleado común y trata de leer el recibo de otro cambiando un número en la URL.
la validación sale del controller y va a su propia clase (Form Request). Y cuando las reglas que trae Laravel no alcanzan, escribís tu propia regla (acá, un validador real de CUIT con dígito verificador).
los errores se manejan prolijamente (no un 500 genérico) con excepciones propias, y todo lo importante queda registrado en el log para poder diagnosticar después.
El usuario ve el SQLSTATE completo y el log guarda su contraseña. El verificador LEE el archivo de log que dejó tu código.
el trabajo pesado (liquidar a miles de empleados) no se hace mientras el usuario espera. Se encola un trabajo (Job) y un worker lo procesa en segundo plano. El usuario recibe la respuesta al instante.
si un cálculo es pesado y su resultado no cambia todo el tiempo, lo guardamos en cache (Redis) y lo servimos al instante en vez de recalcularlo. Se ve clarísimo comparando tiempos.
No tiene solución: una IA te entrevista con cuatro preguntas y construís tu propio módulo de liquidación. Son 81 sistemas posibles y todos funcionan. Incluye la receta para pegarle al asistente que uses.
los tests son un "seguro" del código: verifican solo, automáticamente, que todo siga funcionando. Si algo se rompe, un test rojo te avisa antes que el usuario.
todo lo que vimos, junto y orquestado con un solo docker compose up: la app, un worker de colas, MySQL, Redis y Adminer. Es la foto final del sistema.