Como pasé la certificación Certified Kubernetes Administrator

Esta es una experiencia de la certificación CKA por si alguien tiene dudas del proceso.

¿Que certificaciones para Kubernetes existen?

Partamos del hecho que Kubernetes en este momento es un proyecto Open Source donado por Google hacia la Cloud Native Computing Foundation. Al ser un producto Open Source pueden existir no una sino varias ofertas comerciales (que las hay) y en esa línea también diversas certificaciones, por lo que encontramos dos tipos:

Certificaciones de la implementación neutral (evaluadas por The Linux Foundation):

Certificaciones de una implementación en especifico, por ejemplo:

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.

¿Porqué obtener la certificación?

Las certificaciones son una eterna polémica en TI, siendo así establezcamos que para desempeñar un trabajo bien se necesitan dos cosas:

  • Experiencia (que viene con el tiempo y la práctica)
  • Conocimiento (que viene con el estudio)

Y el conocimiento en TI generalmente se demuestra en tres formas:

  • Diploma universitario
  • Certificaciones
  • Ejecución de pruebas técnicas

Tanto las certificaciones como los diplomas universitarios son a larga la validación de un tercero sobre el conocimiento, o sea una prueba técnica anticipada. Estas evaluaciones se realizan sobre una serie de tópicos generales (Universidad) o de una tecnología especifica (Certificaciones), la certificación o diploma universitario tendrá mas prestigio de acuerdo a quien la emite. Para poner un ejemplo no es lo mismo obtener la certificación Java de Oracle que de un proveedor de Mooc.

En otras palabras al obtener la certificación obtienes el sello de aprobación de The Linux Foundation de que sabes Kubernetes.

¿Porqué obtuve yo la certificación?

TL;DR Ver si me perdía de algo, también pereza de estar demostrando a cada rato que si se y pasé con 10 matemáticas, y es una forma monetaria de contribuir con The Linux Foundation obteniendo un beneficio, casi una teleton computina.

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

Dificultad

Para mi la certificación más difícil que he tomado ha sido la certificación Oracle Certified Professional, Java SE 8 Programmer y sigue ahí. Si esa certificación es un 10, ubicaria CKA en un 7.

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
  • Hay que saber usar bien vi o nano

¿Como me preparé para el test?

Esta sección es un poco difícil porque muchos recursos los fui usando durante el transcurso de los años pero me parecen útiles.

Antes de tomar la prueba el candidato debe de tener buena experiencia en Linux, no a nivel de compilar tu propio Kernel pero si un buen manejo de la terminal, sed, grep, awk, more, less, find, en otras palabras ser un buen Linuxero terminalero, en su momento hace muchos años en una galaxia muy muy lejana yo aprendí Linux por mi cuenta leyendo Linux Bible y también en la Universida’ de la Vida.

Para aprender Kubernetes en su momento compré el libro The Kubernetes Book de Nigel Poulton, es un buen libro introductorio y a excepción de la sección de seguridad (bastante incompleta) es un buen recurso que siempre recomiendo.

Aprovechando que tengo acceso a Oracle Cloud via Oracle Grounbreakers Ambassadors, me armé «a mano» via kubeadm un Cluster con dos nodos en OCI, esto lo pueden hacer también con Oracle Cloud Free Tier, con el objetivo de tener un entorno de pruebas. Muchas personas también recomiendan el tutorial Kubernetes the Hard Way de Kelsey HIghtower pero sinceramente eso solo lo hice una vez cuando empezaba a aprender Kubernetes, ante ese tutorial instalar Gentoo es fácil.

Si sumo los ratos libres donde iba haciendo mis pruebas probablemente ejecuté unas 20 horas de pruebas desperdigadas en 37 dias, la edad de mi clustercito de pruebas:

Al inicio de mi jornada compré el examen para tener una fecha límite y la oferta tenia acceso a Killer Shell con dos intentos. El primero sinceramente lo ejecuté sin humildad y lo perdí, pero me sirvió para identificar cosas no hago tan a menudo para reforzar esos conceptos, siendo en mi caso:

  • Definición de políticas de red
  • Backups de etcd
  • RBAC
  • Sidecars manuales
  • Edits de despliegues en línea de comandos

Al buscar recursos recordé que como Java Champion tengo acceso a Pluralsight VIP Subscription y durante esas 20 horas además de hacer mis pruebas, tomé el MOOC Configuring and Managing Kubernetes Security de Anthony Nocentino para ponerme a punto, y al intentar de nuevo pasé en killer.sh y posteriormente pasé el examen al primer intento (el examen trae dos intentos). La verdad por conocimiento hubiera querido tomar más MOOCs porqué pluralsight tiene un path completo de Kubernetes, pero soy una persona muy ocupada actualmente y:

Al final te dan este diploma:

Creando herramientas de lineas de comandos con Kotlin y GraalVM Native

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.

Iniciando microservicios Java con JakartaEE/MicroProfile y arquetipos de Maven

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

No se pierdan en octubre el curso «desarrollo de aplicaciones empresariales y microservicios con Java«, avalado por el Colegio de Ingenieros de Guatemala y la Facultad de Ingeniería de la Universidad de San Carlos de Guatemala.

Desde Java 8 hasta Java 17

En esta charla conjunta con el Colegio de Ingenieros de Guatemala exploramos muchas de las evoluciones que ha tenido Java desde Java 8 hasta Java 17, discutiendo porqué seria interesante actualizar tus versiones de Java.


Índice

Como de costumbre los slides se encuentran disponibles en Slideshare

El uso de Java(JVM) en Guatemala (2021)

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.

Continue reading →

Probando Windows 11 para desarrollo Java durante 2 semanas

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.

Team red

Con la pandemía evitando seguir mi vida nomada, decidí que era momento de rearmar un gaming rig y entre otras cosas aproveché una licencia educativa para instalar la versión Beta de Windows 11 como miembro del programa insider. Imaginé que en algún momento iba a necesitar compilar programas, conectarme a ssh, y otras cosas típicas de mi trabajo por lo que preparé mi instalación de Windows 11 con lo básico para trabajar, incluyendo:

  • Java Developer Kit 11
  • Node JS 16
  • Git
  • IDE (IntelliJ IDEA) y editor de texto (Visual Studio Code)
  • Docker (Desktop)
  • Kubernetes (Minikube)
  • Navegador web (Firefox)

En este post no comentaré algunos errores que he encontrado en Windows 11, porqué estaba advertido que seria Beta, al contrario les puedo confirmar al 100% que todo driver de Windows 10, funciona bien en Windows 11.

Winget vs Chocolatey

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

Microsoft Store es la ideal para instalar aplicaciones con interfaz gráfica pero su mayor inconveniente es que si o si se necesita tener una sesión de Microsoft iniciada, y era demasiado tardado buscar paquetes, asi que la descarté.

Winget es al día de hoy un canal oficial de Microsoft para herramientas en línea de comandos, en el pasado este universo era totalmente comunitario con aplicaciones como Chocolatey, Scoop y AppGet. Este último de acuerdo a su creador murió porqué Microsoft le «morfó» la idea, lo contrató y luego tiró todo su esfuerzo.

Mi principal problema con Winget fue que al ser el más nuevo, aun padece la falta de paquetes importantes, por ejemplo al día de la escritura de este post, no tiene una versión moderna de Maven, por lo que lo descarté desde el inicio.

Consecuentemente exploré Chocolatey y Scoop, la principal diferencia es que Chocolatey necesita privilegios de administrador para instalar los paquetes (como la mayoría de instaladores oficiales) mientras que Scoop trata que en su mayoría estos paquetes sean instalables por un usuario normal. Imagino que Scoop es más convenientes para entornos corporativos con usuarios restringidos pero dado que este no era mi problema, la colección de paquetes de Chocolatey terminó siendo la ganadora. Al día de hoy estos son los paquetes que he instalado.

Configurando Java 11 y Maven en Windows 11

Si les interesa conocer el proceso a detalle, preparé un pequeño tutorial para mi canal de Youtube

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 varios errores reportados, 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

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:

Neovim

posh-git y Git Credential Manager Core para trabajar con llaves ssh y no con usuario y contraseña

Un detalle menor con Neovim es que no puedo utilizar la tecla Esc en IntelliJ Idea, lo cual debe corregirse manualmente.

El panorama general en Windows 11

Como bien notara el amigo Cajas, mi principal problema con Windows es que estaba encarándolo como usuario UNIX porque «¿que usuario Windows normal se quejaría porqué no puede usar Vim?», y creo que tiene un punto valido. En otras palabras estaba reaccionando como un usuario de Windows la primera vez que usa Ubuntu y no le funciona la impresora.

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.

Todos los drivers que instalé son Drivers de Windows 10 y hasta el momento todos funcionan, incluyendo:

  • Receptor bluetooth
  • Wifi
  • Webcam
  • GPU Radeon RX 6600 XT
  • Impresora Canon en red con SMB (Samba)

De las aplicaciones que instalé ninguna presentó algún fallo (a excepción de WSL 2), en su momento reporté un bug en twitter con Java pero resultó ser un problema con la codificación de mi nombre (problemas de usuario hispano). Otros usuarios me han comentado que lo sienten más pesado que Windows 10, pero como no tengo punto de comparación solo les dire que a mi Linux si me va más fluido pero Windows 11 tampoco me pareció lento.

Me sorprendió lo fácil que me adapté a Windows a pesar de no usarlo frecuentemente, una vez has usado un Windows, cualquier otro Windows va a ser más o menos lo mismo y eso es bueno para la productividad. Incluso pude usar Steamlink hacia mi computadora en la sala (Raspberry Pi 4) sin inconvenientes.

Un punto negativo que no ha cambiado en Windows es que cada dispositivo de hardware por muy pequeño que sea tiene su propia aplicación para hacer tunning, terminé con un monton de bloatware con tal de deshabilitar varias cosas RGB.

Bloatware

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.

Instalación de Gentoo Linux con Mate Desktop sobre VirtualBox

En este video tutorial explico paso a paso una instalación tradicional de Gentoo Linux con las siguientes características:

  • Paquetes estables al 9 de agosto de 2021
  • Sobre VirtualBox
  • Mate Desktop como entorno de escritorio
  • OpenRC como sistema de arranque
  • Tabla de particiones GPT

El vídeo está pensado para curiosos así como personas buscando una ayuda durante la instalación.

Índice:

  • 00:00 – Inicio
  • 01:42 – Descargando Gentoo Linux
  • 02:33 – Creando la máquina virtual para la instalación
  • 04:45 – Obteniendo dirección ip de la «red cableada»
  • 06:00 – Preparando disco y particiones GPT
  • 09:02 – Instalando el sistema Gentoo Base
  • 13:01 – Preparando chroot
  • 14:01 – Seleccionando y actualizando un perfil de sistema
  • 17:01 – Ajustando las USE flags y licencias en make.conf
  • 18:25 – Ajustando zona horaria y locales para español, inglés y portugués
  • 20:04 – Instalando el kernel Linux precompilado
  • 22:25 – Ajustando sistemas de archivos en /etc/fstab y paquetes base finales
  • 26:04 – Instalación de GRUB con soporte a EFI y GPT
  • 28:17 – Primer reinicio
  • 29:39 – Instalando MATE desktop
  • 32:03 – Instalando lightdm
  • 34:33 – Instalando VirtualBox Guest Additions
  • 36:51 – Resultado final

El estado actual de Java EE, Jakarta EE y MicroProfile

En esta charla conjunta con el Colegio de Ingenieros de Guatemala exploramos el estado de Java EE, Jakarta EE, MicroProfile y como las especificaciones impactan a todo el ecosistema Java.

Iniciamos evaluando el estado actual de Java EE, y respondiendo la pregunta más importante ¿Java EE está muerto?

Acá hablamos de

  • 00:00 – Que es Java EE
  • 02:02 – Java Community Process
  • 02:38 – ¿Cuales son las partes de Java EE?
  • 06:18 – Especificaciones de Java EE 8
  • 07:38 – Implementaciones de Java EE
  • 09:08 – Porqué murió Java EE
  • 11:32 – MicroProfile
  • 12:13 – Liberación de Java EE y nacimiento de Jakarta EE

Posteriormente hablamos del estado actual de Jakarta EE, sus diferencias con Java EE y porqué su liberación fue fundamental para el ecosistema de Java empresarial

Acá hablamos de

  • 00:00 – Reseña historica de Jakarta EE
  • 00:23 – Principales diferencias entre Java EE y Jakarta EE
  • 04:42 – Implementaciones de Jakarta EE
  • 06:11 – Herramientas para migración
  • 06:52 – Pregunta de la audiencia

Por último hablamos de MicroProfile, sus especificaciones e implementaciones, con algunos comentarios finales del futuro de Java en entornos Cloud Native

Acá hablamos de

  • 00:00 – Reseña histórica
  • 00:42 – Similitudes con Jakarta EE y MicroProfile
  • 02:38 – Diferencias entre Jakarta EE y MicroProfile
  • 03:44 – Especificaciones de MicroProfile
  • 05:58 – Implementaciones de MicroProfile

Despliegue continuo de aplicaciones Java mediante Bitbucket Pipelines y Oracle Kubernetes Engine

En esta charla conjunta con el Colegio de Ingenieros de Guatemala exploramos de principio a fin la creación de un pipeline de entrega continua con Bitbucket Pipelines para la publicación de microservicios sobre Oracle Cloud.

Iniciamos con un pequeño vídeo acerca de las diferencias entre DevOps, Integración Continua, Despliegue Continuo, Agile y relacionados.

Continuamos con la demostración, para lo cual creamos un microservicio basado en MicroProfile, Payara Micro y cuyo testing está implementado con JUnit y Arquillian. Todo esto a través del arquetipo Kukulkan-EE.

Una vez listo nuestro microservicio, creamos un pipeline declarativo con Bitbucket Pipelines mediante el cual automatizamos la ejecución de pruebas con Maven.

Si las pruebas son exitosas, ¡Es el momento de llevarlo a la nube!. La nube de Oracle. Continuando con Bitbucket Pipelines demostramos la publicación de una imagen Docker sobre Oracle Container Registry.

Todo listo, ahora procedemos a desplegar nuestro microservicio mediante Oracle Kubernetes Engine

Desde la TV hasta la nube, el presente, pasado y futuro de Java en 26 años

En esta charla conjunta con el Colegio de Ingenieros de Guatemala conmemoramos los 26 años de Java, recorriendo sus éxitos pasados, su estado actual y sus retos para el futuro. Analizamos de forma crítica la plataforma y con las preguntas de la audiencia se logró uno de los webinars más activos que he tenido en 2021.

Arrancamos con el pasado:

Acá hablamos de:

  • ¿Como nace Java? – 00:45
  • El primer éxito de Java – 02:35
  • Momentos importantes de Java – 04:25
  • La evolución en resumen – 06:00

Posteriormente viajamos a 2021, donde la pandemia sigue siendo un desmadre:

Acá hablamos de:

  • El presente de Java – 00:05
  • La Java Virtual Machine – 01:42
  • Java en backend – 03:32
  • Ingeniería de datos – 04:22
  • ¿Java es de Oracle y ya no es libre? – 05:55
  • Popularidad de Java – 11:37
  • Grupos de usuarios Java en Latinoamerica – 12:30
  • El tamaño del ecosistema de Java – 14:50
  • ¿Porqué Twitter usa Java? – 16:49
  • ¿Porqué Spotify usa Java? – 18:15
  • ¿Porqué Nubank usa Java? – 23:15

Por último hablamos del futuro de Java, sus retos y que nos espera si queremos que sea relevante durante los próximos 26 años:

Acá hablamos de:

  • Los retos de Java en el futuro – 01:00
  • El mundo políglota – 02:30
  • ¿Que lenguajes deberla aprender? – 07:58
  • Java Cloud Native – 11:45
  • Microservicios en Java, puntos fuertes y puntos débiles – 15:32
  • ¿Como aprender Java? – 21:12
  • Comunidades Java en Centro América – 25:16
  • Estilos de programación en Java – 27:10
  • Lenguajes emergentes en la JVM- 31:41
  • MicroProfile – 35:37
  • Los retos del futuro de Java – 39:12
  • Java en la ingeniería de datos – 40:02
  • Java en IoT – 41:42

Como de costumbre los slides se encuentran disponibles en Slideshare: