Entradas

HTML para el usuario, REST solo cuando hace falta

En tiempos donde todo parece girar en torno a las API REST, es fácil caer en el exceso: cargar todos los datos de un formulario HTML mediante múltiples fetch() , aunque el mismo backend podría entregarlos de una sola vez. Esta entrada no pretende demonizar REST ni JavaScript, sino promover un uso consciente: mantener el HTML limpio y funcional, y recurrir a fetch o APIs REST solo cuando realmente se necesita. Principio guía: simple por defecto, dinámico cuando sea necesario ¿Qué se puede renderizar directo en HTML? Listas estáticas o semi-estáticas: países, categorías, bancos, etc. Datos que ya vienen desde el servidor y no dependen de la interacción del usuario. ¿Cuándo usar fetch tiene sentido? Selects encadenados: región → ciudad → comuna. Formularios que requieren datos según otra selección. Interacción dinámica que mejora la UX (como autocompletar). Ejemplo híbrido: lo mejor de ambos mundos <select ...

Interfaces en Java: Abstracción y Bases de Datos

¿Qué es una interfaz en Java y por qué es tan importante? Cuando comienzas a desarrollar en Java, rápidamente te topas con el concepto de interfaces . Puede sonar abstracto (y lo es), pero entender bien qué son y cómo usarlas marca una gran diferencia en cómo estructuras tu código. ¿Qué es una interfaz? Una interfaz en Java es un contrato: define un conjunto de métodos que una clase debe implementar. No dice cómo deben funcionar esos métodos, solo que deben existir. En otras palabras, una interfaz define el comportamiento esperado de una clase, sin preocuparse de la implementación. ¿Por qué usar interfaces? Desacoplamiento: separas la definición de comportamiento de la implementación concreta. Flexibilidad: puedes cambiar la implementación sin afectar el resto del sistema. Testeo más fácil: puedes usar objetos simulados (mocks) para pruebas. Polimorfismo: puedes tratar objetos diferentes como si fueran del mismo tipo (la interfaz). Ejemplo simple public ...

Linux y los videojuegos: ¿una combinación ideal o un sueño complicado?

En el mundo de la informática, Linux siempre ha sido una opción preferida por muchos usuarios técnicos, gracias a su estabilidad, seguridad y flexibilidad. Sin embargo, cuando hablamos de videojuegos, la historia se vuelve más compleja. Aunque Linux ha avanzado muchísimo en los últimos años en cuanto a compatibilidad con juegos, todavía existen limitaciones importantes que lo alejan del usuario promedio que solo quiere sentarse y jugar. ¿Qué ha mejorado? Proton y Steam Play: permiten que muchos títulos de Windows funcionen de forma sorprendentemente buena en Linux, sin necesidad de configuraciones complicadas. Algunos juegos tienen versiones nativas para Linux. La Steam Deck , basada en Linux, ha demostrado que una buena experiencia de juego en esta plataforma es totalmente posible. Existen emuladores estables y potentes para consolas clásicas (SNES, Genesis, MAME, NeoGeo, etc.) que funcionan de maravilla. Pero también hay desafíos Juegos populares como Val...

🐘 De Payara a Jetty: Cuando entendí que estaba matando una mosca con una bazuca

  Durante mucho tiempo usé servidores como GlassFish y Payara para desplegar mis aplicaciones Java. Al principio no sabía que Tomcat no incluía ciertas dependencias del stack Jakarta EE , como CDI o JPA, así que opté por los servidores "completos", pensando que así evitaba problemas. Y sí, funcionaba. Pero con el tiempo me di cuenta de que estaba usando una solución excesiva para una necesidad básica. Era como matar una mosca con una bazuca . ¿Por qué no me quedé con Tomcat? En algún momento, me pasé a Tomcat . Es más liviano que GlassFish o Payara, y cumple bien el rol cuando solo necesitas servlets, JSP o una app sencilla con JDBC. Pero incluso así, sigue siendo algo pesado para ciertos proyectos . Su tiempo de arranque, el consumo de memoria, y su estructura de configuración a veces se sienten sobredimensionados si lo que vas a correr es una app liviana que simplemente muestra datos o responde a peticiones simples. Jetty: la expresión más minimalista Ahí fue cua...

¿De verdad necesitas una API REST para todo?

Por Esteban Guenul – Desarrollador Java que prefiere soluciones simples y claras Introducción En los últimos años, se ha vuelto común pensar que todas las aplicaciones web deben construirse con APIs REST, microservicios, React o Spring Boot. Pero no todos los proyectos lo necesitan. Estoy desarrollando una aplicación de ventas con emisión de documentos tributarios (boletas, facturas, guías, etc.) y, lejos de complicarme, opté por una solución simple y efectiva: Java puro Servlets clásicos SQL directo Thymeleaf como motor de plantillas Empaquetado como .jar y desplegado en Jetty Sin REST, sin SPA, sin sobreingeniería. Código limpio y estructurado Mi código actual se basa en una separación clara de responsabilidades . Por ejemplo, este servlet PosMovil carga los datos necesarios para emitir documentos desde un punto centralizado: package com.egga.appventas.posmovil; import com.egga.appventas.cliprov.CliProv; import com.egga.appventas.despacho.DespachoS...

Java EE o Jakarta EE, cuando ambos son los mismo

Java EE y Jakarta EE efectivamente son prácticamente lo mismo en cuanto a propósito , pero hay una diferencia histórica y de administración importante. Aquí te lo explico claramente: 🕰️ Java EE (Java Platform, Enterprise Edition) Era la plataforma oficial para aplicaciones empresariales Java. Desarrollado originalmente por Sun Microsystems , luego por Oracle . Usaba paquetes como javax.servlet , javax.persistence , javax.ejb , etc. La última versión oficial bajo el nombre Java EE fue Java EE 8 (2017) . 🔁 Transición a Jakarta EE En 2017, Oracle donó Java EE a la Eclipse Foundation . Oracle mantuvo la propiedad del nombre "Java" y del paquete javax , por lo que no se pudo seguir usando javax.* en nuevas versiones . Desde entonces, la plataforma pasó a llamarse Jakarta EE . El cambio más relevante ocurrió en Jakarta EE 9 , donde se renombró el paquete base de javax.* a jakarta.* . 📌 ¿Qué cambió técnicamente? Característica ...

Cuando la gestión no entiende la tecnología:

   ¿Por qué no siempre Ingenieros Civiles o Comerciales son los mejores para liderar proyectos de software? En muchas empresas, el liderazgo y gestión de proyectos de software queda en manos de profesionales con formación en Ingeniería Civil Industrial o Ingeniería Comercial. No es una crítica a sus carreras ni a su aporte en el mundo empresarial, que es invaluable. Sin embargo, existe una falencia común: se les asignan tareas técnicas o de gestión que requieren conocimiento profundo del desarrollo de software, y eso genera problemas . El problema no es la formación, sino la asignación inadecuada En particular, he visto casos donde: Ingenieros Civiles Industriales lideran proyectos sin un apoyo técnico adecuado , tomando decisiones sobre tecnologías sin entender las implicaciones reales. Ingenieros Comerciales son puestos a hacer consultas SQL o tareas técnicas especializadas , sin formación ni experiencia en bases de datos, lo que puede llevar a errores o consultas...