Java, Jetty y Algo Más.

  En los últimos años han aparecido innumerables cursos para aprender Full Stack Java . Muchos comienzan directamente con tecnologías como: Spring Boot React Docker Kubernetes Al finalizar el curso, el estudiante logra construir una aplicación. Sin embargo, muchas veces no comprende realmente qué ocurre detrás de cada componente. Personalmente, creo que el problema no está en los frameworks. El problema es el orden en que se enseñan. El primer paso no es Spring Boot Antes de construir una aplicación Full Stack existe algo mucho más importante. Aprender el lenguaje de programación. En mi caso, esa ruta debería comenzar así. 1. Comprender el lenguaje Antes de hablar de aplicaciones web es necesario dominar Java. Variables. Tipos de datos. Operadores. Métodos. Condicionales. Ciclos. En esta etapa todavía no existe ninguna aplicación. Solo se aprende a resolver problemas mediante código. 2. Aprender a pensar en objetos Después aparece la Programac...

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