Entradas

Mostrando entradas de julio, 2025

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...

Jakarta EE vs Spring Boot: WAR, JAR, Docker y Jetty ¿quién dijo que no se puede?

Siempre hay dudas sobre qué es Jakarta EE y qué es Spring Boot , si una es más moderna que la otra, o si solo una permite microservicios o desplegar como JAR. La realidad es que ambas tecnologías pueden hacer prácticamente lo mismo , con enfoques y filosofías distintas. En esta entrada te lo explico sin vueltas. 🧱 ¿Qué son Jakarta EE y Spring Boot? Jakarta EE (ex Java EE): es el estándar para construir aplicaciones empresariales en Java. Define especificaciones como Servlets, JPA, CDI, JAX-RS, etc. Es mantenido por la Eclipse Foundation . Spring Boot : es un framework de productividad basado en el ecosistema Spring. Permite levantar aplicaciones listas para producción de forma muy rápida, con configuración automática, servidor embebido y mucha integración. ⚙️ WAR o JAR: ambas lo permiten Tecnología WAR tradicional JAR ejecutable Spring Boot ✅ Sí, si excluyes servido...

🧩 Por qué Java permite y convive con código legacy (y la mezcla de frameworks que eso implica)

Java es un lenguaje con más de dos décadas de historia, usado en millones de aplicaciones empresariales. Aunque existen frameworks modernos y enfoques nuevos, Java sigue permitiendo que conviva código legacy y que se mezclen frameworks como Struts, Spring y Hibernate dentro de una misma aplicación. 1. La filosofía de Java: compatibilidad y evolución gradual Una de las piedras angulares de Java es la retrocompatibilidad. Desde sus inicios, la plataforma JVM se ha esforzado en garantizar que el código antiguo siga funcionando en versiones nuevas sin necesidad de modificaciones drásticas. Esto permite que proyectos de gran tamaño mantengan y evolucionen sus aplicaciones sin reescribir todo desde cero. Así, el código legacy sigue presente y funcional. 2. La mezcla de frameworks: un legado histórico y técnico En la práctica, no es raro encontrar aplicaciones que usen Struts para la capa web, Spring para la gestión de dependencias y lógica de negocio, y Hibernate para la persis...

❤️ Es increíble que a un lenguaje que no pensaba programar, le terminé tomando aprecio

La verdad… ni siquiera pensaba programar. En los trabajos que me llegaban, hacía lo que podía: Escribía una función en PHP, otra parte en Python, y otra en Java. Todo mezclado, sin estructura ni plan. Java aparecía, pero lo que hacía no tenía ni pies ni cabeza. Solo buscaba que funcionara, sin importar la coherencia o la calidad. Hasta que Java me obligó a cambiar. ☕ Java me hizo frenar y pensar Venía de un mundo de código improvisado y fragmentado. Java me preguntaba: ¿Dónde está la organización? ¿Quién podrá entender este código mañana? ¿Cómo mantendrás todo esto cuando crezca? Y no tenía respuestas claras. Java me obligó a ver que el código no es solo para funcionar hoy, sino para sostenerse en el tiempo. 🧱 Java no enamora rápido, pero enseña disciplina PHP y Python me daban libertad; Java me puso reglas. Me enseñó a pensar en estructura, modularidad y claridad. Al principio frustró, pero luego comprendí que esa firmeza es lo que permite...

Spring Boot recuerda el pasado: por eso los Servlets aún funcionan

🔄 Spring Boot: Moderno, pero Retrocompatible (Sí, los Servlets funcionan) Spring Boot se presenta como un framework moderno, opinado y productivo para construir aplicaciones web y microservicios en Java. Y lo es. Pero lo que muchos no esperan es que aún puedas hacer esto: @Bean public ServletRegistrationBean<MiServlet> miServlet() { return new ServletRegistrationBean<>(new MiServlet(), "/legacy"); } Y funcione. Sin web.xml , sin configuraciones extra. ¿Cómo es posible que un Servlet tradicional se ejecute dentro de un entorno que se supone moderno? ☕ Porque Java es retrocompatible por naturaleza La clave está en la plataforma: Java nunca rompe con el pasado. Desde hace décadas, Java garantiza que el código antiguo siga funcionando. Y frameworks como Spring Boot heredan esa filosofía . Por eso, aunque Spring Boot promueva anotaciones como @RestController , inyección de dependencias y arquitectura REST, no bloquea el uso de un HttpS...

Mi problema con el Internet de las Cosas: lo ridículamente fuera de la realidad

Desde hace un tiempo se habla mucho del “Internet de las Cosas” (IoT) como la gran revolución tecnológica que cambiará nuestra vida diaria. Refrigeradores inteligentes que hacen la compra por ti, luces que se prenden con la voz, sensores para todo tipo de cosas… la lista es larga. Pero siendo honesto, mi experiencia personal y mi percepción es que muchas de esas soluciones están ridículamente fuera de la realidad . No tengo un refrigerador que me organice el pedido de la despensa, ni una cocina automatizada, ni siquiera una casa “inteligente” que funcione sin fallos. De hecho, no tengo portón automatizado para el auto, porque donde vivo se genera un gran problema: el barro que produce la lluvia. Y si el smartphone que tienes es de los económicos, créeme que no te va a funcionar. En el sur de Chile, donde vivo, dependemos mayormente de la leña para calefaccionar nuestros hogares. Esto implica un ritmo y una realidad muy distinta a la que muchos de esos dispositivos Io...

Vendieron humo y me echaron por decirlo

  Entre junio de 2022 y junio de 2023 estuve en una sola startup joven. Pero bastó con esa experiencia para entender cómo funcionan muchas empresas que parecen “innovadoras”, pero que en realidad están construidas sobre promesas vacías. El gerente general no tenía idea de lo que estábamos haciendo. No sabía tomar decisiones, no entendía nada del proceso técnico y, lo peor, ponía las manos al fuego por su amigo, el gerente comercial: un tipo charlatán y prepotente, sin estudios formales que yo supiera, que se dedicaba a vender la marca y hacer promesas imposibles. Y eso era exactamente lo que hacían: vendían sin tener producto. Mostraban maquetas bonitas y videos publicitarios, mientras que el software real —el POS de ventas— era solo un esqueleto sin backend ni lógica funcional. Gastaban más en vender la marca que en construir lo que prometían. Mientras todo eso ocurría, yo soportaba la parte de los Documentos Tributarios Electrónicos. No era un tema menor, porque una falla ahí...

El problema no fue el código. Fui yo.

  No todo son líneas de código: también fallé comunicándome En 2005 me despidieron. Técnicamente, yo podía programar. Sabía HTML, algo de ASP, PHP y empezaba con JavaScript. Pero mi problema no era el código. Mi verdadero problema era otro: no sabía comunicarme bien en el trabajo. No sabía cuándo pedir ayuda. No sabía explicar lo que hacía. Y a veces, ni siquiera sabía decir “no sé hacerlo”. No fué un tema técnico. Fue un tema de personalidad. No me aguantaron. No es que anduviera insultando gente ni nada así. Simplemente era muy cerrado. No hablaba mucho. Me costaba integrarme. No sabía cómo manejar la presión o dar señales claras de avance. Y eso, en un equipo, pesa. No lo cuento por victimismo. Lo cuento porque muchos desarrolladores creen que ser bueno técnicamente basta. Pero también hay que saber hablar, escuchar, explicar y colaborar.