Java, Jetty y Algo Más.

 Muchas rutas de aprendizaje pasan directamente desde Programación Orientada a Objetos al desarrollo web. Personalmente, haría un paso intermedio. Las aplicaciones de escritorio. ¿Por qué? Porque permiten comprender el concepto de evento sin agregar todavía la complejidad de HTTP, servidores, sesiones o protocolos de red. Cuando un usuario presiona un botón ocurre un evento. Usuario │ Hace clic │ Evento │ Código Java │ Actualización de la interfaz El estudiante aprende conceptos como: Eventos. Escuchadores (Listeners). Componentes gráficos. Validaciones. Separación entre la interfaz y la lógica de negocio. Todo ocurre dentro de una misma aplicación. No existe todavía la complejidad de una arquitectura cliente-servidor. El siguiente paso: HTTP Una vez comprendidos los eventos, el salto al desarrollo web resulta mucho más natural. El botón ya no ejecuta directamente un método. Ahora genera una petición HTTP. Usuario │ Hace clic │ HTT...

El código está abierto Cuando publico un proyecto Open Source, mi intención es compartir: Código. Arquitectura. Documentación. Conocimiento. Eso significa que cualquier persona puede estudiar el proyecto y, de acuerdo con su licencia, adaptarlo o reutilizarlo. Una situación que no esperaba Con el tiempo comenzaron a aparecer solicitudes diferentes. No se trataba de integrar la API. No se trataba de utilizar el proyecto. La solicitud era otra. "¿Puedes ayudarnos a reimplementar toda la lógica en otro lenguaje?" Por ejemplo: Node.js C# Python Go Ahí comprendí que existe un límite Una cosa es explicar cómo funciona un proyecto. Otra muy distinta es dedicar semanas o meses a transferir años de conocimiento para que otra organización reconstruya exactamente la misma solución utilizando otra tecnología. En una oportunidad acepté hacerlo. La experiencia me enseñó que ese tipo de trabajo consumía una enorme cantidad de tiempo. Desde mi punto de vi...

Muchas veces tendemos a pensar que un proyecto Open Source es únicamente código fuente publicado en un repositorio. Sin embargo, en mi opinión, un proyecto Open Source tiene al menos dos dimensiones. 1. Transferencia de conocimiento Cuando un desarrollador publica un proyecto Open Source está compartiendo mucho más que código. Está compartiendo: Arquitectura. Decisiones de diseño. Patrones de desarrollo. Documentación. Ejemplos. Experiencia acumulada durante años. Todo eso constituye una forma de transferencia de conocimiento. Otros desarrolladores pueden estudiar el proyecto, aprender de él, reutilizar ideas e incluso contribuir a mejorarlo. 2. Dimensión comercial Al mismo tiempo, un proyecto Open Source puede generar oportunidades profesionales. Por ejemplo: Implementación. Integración. Capacitación. Soporte. Desarrollos específicos. Consultoría. Eso no elimina su carácter Open Source. Simplemente significa que el conocimiento compartido también...

Hace algunos días publiqué AppDTE Community , un proyecto Open Source desarrollado durante varios años cuyo objetivo es facilitar la integración de la facturación electrónica chilena mediante una API desarrollada en Java. Decidí compartirlo en distintos espacios relacionados con Java y desarrollo de software. Uno de ellos fue la comunidad techs.cl . La razón era bastante simple. La comunidad se presenta como un espacio para compartir conocimiento tecnológico. Precisamente por eso pensé que era el lugar adecuado para presentar un proyecto Open Source acompañado de su código fuente, documentación técnica y arquitectura. Sin embargo, la publicación fue considerada spam y posteriormente fui expulsado de la comunidad. Mi reacción Reconozco que ver mi publicación clasificada como spam me sacó de las casillas. Después de dedicar años al desarrollo del proyecto, sentí que no se estaba evaluando el trabajo técnico que había detrás, sino únicamente el hecho de que fuera yo mismo quien lo estuvie...

  Durante los últimos años hemos visto cómo aparecen constantemente nuevas tecnologías para desarrollar aplicaciones. Frameworks, librerías y arquitecturas evolucionan a gran velocidad. Con frecuencia creemos que debemos utilizar siempre la tecnología más reciente. Sin embargo, cuando trabajamos desarrollando software empresarial, la realidad suele ser muy distinta. La pregunta no debería ser: ¿SOAP o REST? La pregunta correcta es: ¿Con qué sistemas debo integrarme? La tecnología cambia más rápido que las empresas En el mundo del desarrollo aparecen constantemente nuevas herramientas. Hoy hablamos de: Spring Boot .NET 8 Node.js React Mañana probablemente aparecerán nuevos frameworks que reemplazarán parte de las tecnologías que hoy utilizamos. Es completamente normal. La tecnología evoluciona. Pero las empresas no evolucionan al mismo ritmo. Muchas organizaciones continúan utilizando sistemas que fueron desarrollados hace diez, veinte o incluso treinta ...

 Durante los últimos años me han preguntado en varias ocasiones por qué AppDTE no fue desarrollado utilizando Spring Boot. La respuesta es bastante simple. Cuando conocí Spring Boot, AppDTE ya era un proyecto maduro. Los primeros años AppDTE no nació como una API REST. Los primeros desarrollos fueron aplicaciones de escritorio utilizando Java Swing. En aquella etapa el objetivo no era desarrollar una aplicación web, sino resolver un problema mucho más complejo: implementar correctamente la facturación electrónica chilena. Con el tiempo el proyecto evolucionó hacia una arquitectura web utilizando Jakarta Servlets y JSP. Posteriormente JSP fue reemplazado por Thymeleaf para simplificar la generación de las vistas administrativas. La interfaz cambió varias veces, pero el verdadero desafío permanecía exactamente igual. El verdadero problema nunca fue la aplicación web Cuando se desarrolla una aplicación tradicional, gran parte del esfuerzo suele concentrarse en la interfaz ...