Las pruebas unitarias y de integración son la base de una buena cultura TDD para la implementación de automation testing, las cuales no son siempre utilizadas por su relativa dificultad en configuración de las herramientas.
En esta serie exploramos la creación de pruebas utilizando Java (11) como lenguaje de programación y Jakarta EE (9) sobre Payara para explorar su correcta implementación.
Como primer capitulo discutimos que es la gestión de calidad del software:
Y posteriormente discutimos que tipos de pruebas de software existen:
Adentrados en Java, discutimos como implementar correctamente pruebas unitarias con JUnit 5 y Java 11:
Y discutimos la importancia o utilidad de los mocks via Mockito:
Iniciamos la cuesta final creando tests de integración con Arquillian, Jakarta EE 9 y JUnit 5:
Incrementamos la dificultad creando una API REST (CRUD) sobre MySQL:
La cual probamos posteriormente en tres tipos de bases de datos: 1- Real, 2- En memoria (H2), 3- Real sobre Docker via Testcontainers (MySQL):
Recientemente alguien me hizo esta pregunta via Twitter. Y la verdad es que me la han hecho varias veces y me di cuenta que no está documentado el proceso, al menos no en español.
¿Que es un Java Champion?
Primero debemos establecer que es un Java Champion. De acuerdo a una traducción liberal desde el sitio oficial de Java, un Java Champion es:
El programa Java Champions consta de un grupo único de expertos en tecnologÃa Java y lÃderes comunitarios patrocinados por Oracle. Los Campeones de Java provienen de una amplia muestra representativa de la comunidad de Java. Son lÃderes, personas influyentes y habilitadores que ayudan a aumentar el tamaño de la comunidad Java. Los campeones de Java están activos de muchas maneras, como participar activamente en proyectos de Java, interactuar con las comunidades de grupos de usuarios de Java, hablar en conferencias, crear contenido, enseñar a otros desarrolladores, fomentar la participación inclusiva y mucho más.
De este párrafo podemos extraer al menos cinco criterios que son evaluados:
Los Java Champions tienen experiencia en Java y liderazgo en comunidades Java
Los Java Champions crean proyectos importantes y/o contribuyen a proyectos Open Source
Los Java Champions son independientes y NO pueden trabajar para Oracle
Los Java Champions enseñan a otros Java
Los Java Champions deben ser buenas personas
Segun me han comentado «los fundadores» el programa originalmente pertenencia a Sun Microsystems, fue creado con el objetivo de establecer una mejor comunicación entre Sun y la comunidad Java, con esto Sun pretendia conocer mejor las necesidades de los desarrolladores y sobre todo hacerlo de forma más transparente.
El programa funciona como un premio al cual accedes luego de demostrar esos criterios, es decir, una vez dado solo lo puedes perder por tres razones:
Decides retirarte voluntariamente
Vas a trabajar para Oracle
Hiciste algo muy malo
Al ser un premio y luego de ver varios procesos de selección, puedo decir que el programa es bastante estricto en los criterios.
¿Que NO es un Java Champion?
Un Java Champion no es lo siguiente:
Una certificación: Para esto Oracle tiene sus propios programas de certificación Java
Una prueba de que eres el mejor en Java: Probablemente la mayorÃa de los Java Champions sean buenos en Java pero no necesariamente «el mejor»
Un trabajo: El programa es 100% comunitario y a excepción de algunos regalos que recibes, no tienes una asignación monetaria de Oracle
¿Como alguien se convierte en Java Champion?
Por lo general y con el pasar de los años, la actividad que un desarrollador Java tenga en pro de la comunidad se nota y este es el primer paso para convertirse en JC, contribuir genuinamente con la comunidad Java.
Personalmente el ser Java Champion me ha dado cinco beneficios directos:
Tener un mejor contacto con las personas que hacen Java y contribuir con opiniones independientes a las plataformas que me han dado de comer por tantos años
Oportunidades laborales diversas
De tanto en tanto Oracle envÃa algunos «perks» como ropa personalizada con el logo de Java
En su momento varios amigos que conocà en la comunidad de Java en Español se acercaron a mi para preguntarme si tenia interes en participar, sinceramente nunca fue mi intención convertirme en Java Champion porque yo ya creaba contenido comunitario por diversión desde el inicio de este blog.
Sin embargo algunos criterios que creo que pesaron en el programa fueron las siguientes:
¿Vale la pena dedicar tanto trabajo para ser Java Champion?
La verdad es que depende de cada quien, yo conozco bastantes profesionales que son excelentes en Java y probablemente nunca expongan su trabajo al exterior o simplemente no les interese la comunidad Java, es algo común y sobre todo respetable.
Continuando con una tradición que he ejecutado en 2020 y 2021, iniciare el año con mis predicciones acerca del ecosistema de la Java Virtual Machine. He visto que los post de años anteriores fueron bastante certeros entonces espero que este año no sea la excepción.
Si aún no han experimentado con GraalVM Native, seguramente lo haran con Spring.
El fiasco de log4j se convertirá en FUD a Java
A menos que vivan bajo una piedra, si viven dentro del ecosistema de Java ya saben que hubo un gran agujero de seguridad en la biblioteca log4j, la cual permitió entre otras cosas ejecución remota de código, obteniendo asà la mayor calificación de riesgo.
Me parece impresionante como la gente declara a Java muerto, cuando al mismo tiempo un error en una biblioteca afectó a medio mundo. Incluyendo lugares donde uno no lo imagina como en el hardware de Cisco, básicamente la carretera de Internet.
Este error pudo pasar (y ya pasó) en otros ecosistemas, pero por lo extendido que está el uso de Java ha servido para propagar FUD al respecto de la plataforma y el lenguaje, sorprendente si se considera que el error fue parchado en tiempo record.
The log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure. https://t.co/GMkEozKdmD
El ecosistema DevOps Java girara alrededor de Testcontainers, Docker y extensiones basadas en JUnit
Hemos recorrido un largo camino y sin miedo a equivocarme Java (junto a Maven) tienen uno de los mejores ecosistemas para flujos de trabajo DevOps.
Muchos de los conceptos inventados por JUnit (y TestNG) ahora son ubicuos en varios ecosistemas de software. Si han estado lo suficiente en Java probablemente han visto la siguiente evolución
Uno de los temas pendientes en todos estos frameworks y bibliotecas siempre han sido las bases de datos, a principios de la decada pasada se popularizó el uso de bases de datos en memoria como H2 o Apache Derby, al punto de que en JakartaEE aún es requerido que se incluya una base de datos en memoria en los servidores de aplicaciones.
Aunque en principio los tests sobre H2/Derby son los suficientemente buenos para software creado con JPA, los problemas empiezan cuando queremos validar particularidades de cada base de datos, por ejemplo:
SQL Nativo
Ãndices (o la falta de)
Diferencias entre mayúsculas y minusculas
Comportamiento de pool de conexiones
Reactividad y drivers reactivos (o pseudo-reactivos)
Esta revolución a mi parecer inició con Arquillian Cube, pero Testcontainers ejecutó de forma más simple y funciona en cualquier entorno, no solo entornos basados en CDI.
Se detendrá la proliferación de Java Virtual Machines
Aunque siempre vale la pena leer la letra pequeña, lo cierto es que Oracle brinda más opciones para utilizar HotSpot de forma gratuita y para mucha gente esto es suficientemente bueno como para ya no plantearse una alternativa, siendo asà deberÃamos ver la muerte de algunas «distros Java».
¿No sabias que existen otras distros Java?, siempre es buena idea consultar la tabla de foojay, a mi parecer la más completa
MicroProfile se alineara más a CNCF
La «otra» gran alternativa a Spring es MicroProfile, aunque su adopción seguramente es menor, ha sido fuertemente impulsado por la popularidad de Quarkus.
Esto la verdad no es necesariamente malo y en esta lÃnea vemos como la apuesta de Jakarta EE es cada vez más Cloud Native y cada vez menos a lo que estábamos acostumbrados (app servers tradicionales, instalaciones on premise).
Las «emociones» de la JVM se centraran en Loom, Panama y un poco menos en Valhalla
El cambio a Java modular fue por decirlo de una forma amable «doloroso», pero los que seguimos el carrito de lanzamientos hemos visto como las innovaciones llegan de forma más rápida a Java.
Luego de superar la velocidad de lanzamiento, migraciones de Java 8 a 11 y de 11 a 17 en algunos casos, lo que nos queda a los desarrolladores Java es aprovechar este flujo constante de actualizaciones, en esta lÃnea veo que lo más emocionante viene de tres frentes:
En el caso de las certificaciones neutrales se recomienda tomar CKS y CKA si su principal rol es SRE/sysadmin y CKAD si lo que pretenden hacer es desplegar aplicaciones Cloud Native.
Siempre me he descrito como un desarrollador de software que se sabe uno que otro tango en Linux porque lo aprendió en la Universida’ de la Vida. Actualmente me dedico a consultorÃas con instituciones de banca, industria y gobierno, y en su mayorÃa mi equipo y/o yo participamos en desarrollo, implementaciones y acompañamiento en definición y arquitecturas de software tradicionales, Cloud Native y cualquier otro termino de marketing que surja en el futuro.
En el corto plazo y como ya he comprobado con otras certificaciones, son un atajo para conseguir contratos y brindar respaldo a los clientes, pero lo más importante evaluar si mi conocimiento está al nivel adecuado de mi experiencia, en Kubernetes en este caso (+/- 4 años).
El examen de certificación tiene una duración total de 2 horas donde se realizan 17 tareas prácticas en al menos 6 clusters diferentes de Kubernetes, con una nota mÃnima de aprobación de 66%. La ejecución de estas tareas se utiliza una terminal dentro de un navegador Web (Chrome) la cual es bastante incomoda. Como estamos en COVIS toda prueba es remota con la camara encendida todo el tiempo y haciendo screensharing.
Durante el examen te permiten ver la documentación oficial de Kubernetes y Helm porque es imposible memorizar cada uno de los aspectos, pero al ser contra-reloj si no sabes que buscar estas frito (en esta lÃnea recomiendo tener bookmarks).
Las tareas incluidas en mi examen fueron actualizaciones de clusters, troubleshooting, apertura de servicios al exterior mediante NodePorts e Ingress, backup de etcd, definición de polÃticas de seguridad y red, creación de volumenes de almacenamiento e instalación de un operador, pero puede variar.
Diria que el examen es bastante justo y refleja tareas básicas del dÃa a dÃa de un administrador Kubernetes, pero por mi experiencia creo que las personas lo fallan por los siguientes motivos:
No tienen buenas nociones de Linux
Hay que leer bien las instrucciones
Hay que darse cuenta en que cluster se está trabajado en cada pregunta, si no Ixcamic
Es contra reloj y a cada rato te dan advertencias que ya se te va ir la moto
Solo está permitida la consulta de recursos en dominios de internet aprobados (documentación de Kubernetes, Helm) y si no haces caso te anulan el test
GraalVM es una de las innovaciones que más ha impactado el ecosistema de la JVM, incluidos lenguajes como Kotlin, Scala, Clojure o Groovy. Su modulo Native Image permite la creación ejecutables «self-contained», «AOT» y dependientes de sistema operativo que presentan menor velocidad de arranque y consumo de memoria.
En esta charla exploramos la creación de herramientas de lÃnea de comandos con Kotlin y GraalVM Native, comparamos la herramienta con Kotlin Native y vemos la creación de una herramienta en lÃnea de comandos, con Kotlin, PicoCLI, Maven y GraalVM Native.
Primero exploramos las diferencias entre Kotlin Native y Kotlin con GraalVM Native
Posteriormente hablamos más a fondo de GraalVM y su relación con Kotlin.
Luego, hablamos a detalle de las implicaciones de una Native Image
Por último creamos una herramienta CLI con PicoCLI y Kotlin, comparando el desempeño de la versión JVM versus la versión AOT.
Como de costumbre los slides se encuentran disponibles en slideshare.
Los microservicios del mundo real utilizan muchas tecnologÃas además del chasis, como la persistencia de datos e IoC, lo que obliga a los arquitectos de Java a repetir los proyectos de ensamblaje. Desde la experiencia de campo, esta charla expone los beneficios de combinar proyectos como Eclipse JKube, Deltaspike en arquetipos convenientes.
Como de costumbre los slides se encuentran disponibles en slideshare
Considerando la salida de Java 17, el grupo de usuarios Java de Guatemala aprovechó a diagnosticar cual es el estado del ecosistema en el año 2021.
Abajo se detallan todas las respuestas brindadas por la comunidad guatemalteca pero en resumen:
Java 8 sigue reinando en Guatemala
Windows sigue siendo el sistema operativo #1 para programar en Guatemala
La JVM de Oracle sigue siendo la más usada
Gracias a todos los participantes. los datos se encuentran a disposición en csv y fueron analizados con un notebook de Apache Zeppelin, por si desean realizar sus propios análisis todo esto lo pueden encontrar en GitHub, asi como una página compilada con los mismos datos mostrados acá por si necesitan en algún momento usar una referencia.
Escribo esta bitácora luego de utilizar Windows 11 durante dos semanas como mi sistema operativo principal. Busco relatar la experiencia desde el punto de vista de un usuario «UNIX» de la no tan vieja guardia, las cosas me parecieron interesantes, que recomendaciones puedo dar a las personas y en general lo que creo que aun le falta a Windows para ser atractivo hacia usuarios Linux, especialmente programadores.
Antecedentes
Me considero un usuario de sistemas *NIX. Utilizo Linux casi a tiempo completo desde el año 2006 y MacOS aproximadamente desde el año 2015. A partir del año 2006, a excepción de una que otra consultorÃa, he utilizado Windows únicamente como un sistema operativo para juegos.
Una de las cosas que nunca me gustó de Windows es la necesidad de buscar y descargar los paquetes de software desde la tienda de cada uno de los fabricantes, gracias a esto nacieron tiendas tan infames como Softonic o Mocosoft, o los discos de PC Magazine que traian un metainstalador junto a varios tantos troyanos.
Luego de usar tantos años gestores como Homebrew o Portage hacer esto es algo arcaico, por lo que decidà configurar el sistema utilizando un gestor de paquetes. Al dÃa de hoy existen al menos cuatro formas principales de instalar aplicaciones en Windows (sin contar las tiendas/launchers de juegos que son otro mundo por si solo).
WSL2 el año de Linux en el escritorio . . . que aun no llega
Mi siguiente tarea durante la preparación de Docker fue instalar WSL 2, que en pocas palabras es un sistema Linux dentro de Windows, especialmente útil para la linea de comandos. Esta fue a su vez mi mayor decepción.
WSL2 es una capa de compatiblidad en donde las llamadas son traducidas desde los ejecutables Linux hacia el Kernel NT los ejecutables ELF corren sobre un kernel Linux real bajo la estructura de virtualización de Windows. Junto con el sistema, Microsoft ha estado promoviendo una terminal denominada Windows Terminal que permite ejecutar CMD Clasico, Powershell y WSL.
La terminal sinceramente está muy bien acabada y supera por mucho a todas las terminales de Windows anteriores, para un usuario Linux sin embargo la experiencia seria similar en Gnome Terminal y para un usuario MacOS es bastante parecido a iTerm sin tantas posibilidades de personalización.
Mi principal problema con WSL es que diferente de lo que pasa con una terminal con MacOS o Linux, WSL aún es un sistema «alienÃgena», y tiene varias cosas que vale la pena destacar.
Primero, su sistema de archivos es un universo aparte, y se integra en sus propias unidades de red virtuales en Windows Explorer.
El hecho que sean unidades de red presenta bastantes inconvenientes, especialmente bajo desempeño. Entre los que me ocurrieron en esta aventura puedo mencionar dos:
IntelliJ tiene varioserroresreportados, colocar un proyecto «dentro de Linux» implicaba que IntelliJ no funcionara más. Al dÃa de hoy usar el sistema de archivos de WSL causa más problemas que soluciones a usuarios de IntelliJ como es mi caso.
Se supone que esto es IntelliJ sobre WSL pero yo veia un cuadro gris
En Visual Studio Code existe la necesidad de abrir el editor en un «modo especial» para WSL 2, el cual requiere la ejecución de un cliente-servidor en WSL 2. Esto hace más lenta la experiencia que de otra forma seria transparente para los usuarios acostumbrados a MacOS o Linux.
Adicionalmente si se desea tener Java, Node o cualquier otro compilador en Powershell y WSL, es necesario instalarlo dos veces. Y en casos como Maven o Node esto significa mantener dos inventarios de dependencias descargadas, una para la instalación en Windows y otra para la instalación en WSL.
Aunque las soluciones están en desarrollo y espero que en un futuro mejoren, sinceramente es más fácil instalar un Ubuntu en dual boot o comprar una Macbook. Sin embargo, creo que WSL si es ventajoso bajo los siguientes casos de uso:
Terminales SSH
Docker Desktop
Como un entorno de compilación cruzada
Como un entorno de pruebas/certificación en Linux
Mi recomendación al dÃa de hoy es seguir utilizando Powershell.
Powershell, Cygwin y otros IDE Java
Dado mi estrepitoso fracaso con WSL 2 como terminal principal, decidà que lo más sano era utilizar directamente Powershell y Cygwin.
Antes de la existencia de WSL 2, lo más parecido a una terminal bash en Windows fue Cygwin, en el cual se compilan y adaptan binarios tÃpicos de un userland POSIX para ejecutarse sobre Windows.
Mi principal motivación para utilizar Cygwin fue que para una consultorÃa debÃa validar entornos de desarrollo basados en NetBeans, y al querer utilizar la terminal en NetBeans obtuve el siguiente resultado:
Y ya en la experimentación, decidà probar Eclipse, el cual parece trabajar mejor con cualquier terminal en Windows.
Mi único inconveniente con Powershell es que estoy demasiado acostumbrado a hacer tareas simples en zsh, por ejemplo hacer commits en git, realizar busquedas con find, o editar directamente un archivo de texto.
Mi solución en el mediano plazo fue agregarle algunos complementos a Powershell, incluyendo:
Mi experiencia previa con Windows ha sido la siguiente:
Windows 3.11 (Cyrix 686)
Windows 95 (Pentium 2)
Windows 98
Windows ME (Pentium 4)
Windows XP (acá me despedà de Windows a nivel domestico)
Windows 7 como videoconsola (Core i7)
Windows Server 2000
Windows Server 2003
Con un equipo no tan modesto fue relativamente fácil instalar Windows 11, a pesar de las restricciones artificiales es posible instalarlo sin Secure Boot y TPM utilizando un par de hacks en el registro. Eso si, las personas que quieran actualizar desde Windows 10 y tengan dual boot con Linux la van a pasar mal.
Aunque suene gracioso, lo mejor de este Windows para mi fue la herramienta de captura de pantalla. Eso es lo más revolucionario hasta el momento, fue absurdamente facil producir todas las imagenes para este post.
El objetivo de esta instalación sera juegos y conservo un dual boot con Gentoo Linux para trabajo serio. Pero con todo y los inconvenientes, creo que este Windows es un Windows 10 con tacuche nuevo y sera un buen Windows.
Edit 15 de septiembre: En el post original afirmaba que WSL es una capa de traducción, eso es verdad para WSL 1 pero no para WSL 2, WSL 2 ya es un sistema independiente.
