Empaquetando aplicaciones Java con Docker y Kubernetes

El siguiente vídeo es la grabación en vivo de parte del workshop denominado «Empaquetando aplicaciones Java con Docker y Kubernetes» como parte de las jornadas de actualización CEDUCA del colegio de ingenieros de Guatemala.

Durante la charla se explora el funcionamiento de Docker, Kubernetes, fundamentación teórica y su papel durante la creación de microservicios con Java.

Como de costumbre, la presentación se encuentra disponible en slideshare.

La (falta de) historia de la computación en Guatemala, un proyecto personal

Gente haciendo historia sin saberlo, quien sabe cuandos sobrevivieron

Durante un meetup de GuateJUG recuerdo que alguien se acercó a mi preguntándome por varias dudas históricas respecto a Java, en la cual para bien o para mal llevo 10 años profesionalmente (y 15 si cuento la universidad, juventud divino tesoro).

Posteriormente nuestra charla se extrapolo a la historia de Java y de la computación en Guatemala. A pesar de utilizar varias anectodas de un keynote de @marycoder (una de las personas que más conoce de Java en Guatemala), me di cuenta que la historia de la computación en Guatemala simplemente no se está documentando.

¿Porqué es importante y nadie lo hace?

Uno de los principales problemas es que el documentar historia no es tarea que atraiga a ninguna persona de computación, de hecho ninguna documentación atrae a las personas de sistemas.

En algún momento Stanford llegó a brindar un programa de estudios conjunto enfocado en historiadores para ciencias de la computación, sin embargo en el país la mayoría de programas humanos/de historia dan la impresión de enfocarse en dos áreas:

  • La revolución del 44, el inicio de la dictadura militar del 54 y el conflicto armado interno iniciado por la guerrilla dadas las malas condiciones del país(si se le pregunta a alguien de USAC o URL)
  • La entrada del comunismo en el 44, la liberación por parte de los héroes de la patria en el 54, y el conflicto armado interno iniciado por la guerrilla gracias a Rusia (si se le pregunta a alguien de UFM)

Pienso que es importante ya que el conocer la historia en cualquier área de conocimiento nos brinda la perspectiva del «porqué las cosas son así», por ejemplo en Guatemala podría responder:

  • ¿Porqué todas las academias de computación de los 90s tenían Prehistorik 2 como el juego bandera? (Esta duda la tengo desde 2001 aprox).
  • ¿Porqué los programas de computación son de 5 años si lo común es de 4?
  • ¿Porqué tenemos nula investigación en ciencias de la computación?
  • ¿Porqué los programas de computación siguen combinando ciencias de la computación e ingeniería de software cuando el mundo ya reconoció que tal vez es mejor idea separarlos?
  • ¿Porqué se ven los mismos profesores en todas las universidades?
  • ¿Donde está mi queso?

Documentos de libre acceso que he encontrado

Como proyecto personal en mis momentos de frustración/ocio y dado que decidí ya no viajar tanto mientras pasa la crisis del coronavirus, me propuse la tarea de reunir toda la documentación posible para leerla yo.

¿Porqué?, simplemente me gusta la historia. Quienes han viajado conmigo saben que soy un «ratón de museos».

Creo que este seria un buen proyecto de investigación para alguna escuela de historia/historiador que daría varias publicaciones. Pero primero deben salir del 44.

Mientras tanto lo que me queda es ir actualizando este listado conforme encuentre más datos y/o alguien amablemente me envié más fuentes.

Fuente #1: La recopilación de datos sin autor claro

Al realizar una busqueda en Google de la «historia de la computación en Guatemala» las primeras dos paginas dan una absurda cantidad de enlaces de la misma recopilación de datos.

Esta recopilación de datos de cualquier forma es interesante ya que resalta a algunos Guatemaltecos en momentos puntuales que han realizado aportes al área.

Fuente #2: Tesis de la Universidad Francisco Marroquin de 1995

Luego de buscar en fuentes de documentación más formales descubrí que hay un intento claro de documentar la historia por parte de la UFM, específicamente una tesis de ingeniería de 1995.

La tesis tiene bastantes datos interesantes y entrevistas con gente del área respecto a como se fue desarrollando la computación en Guatemala, el único detalle es que la tesis fue elaborada por alguien de Ingeniería en Sistemas y no por alguien de historia, eso se nota en la forma y redacción del texto.

Fuente #3: La historia del programa de sistemas de la universidad de San Carlos de Guatemala

Alguien amablemente (@maxein) me brindo un folleto que contiene bastante información de como nace el programa de computación y eventualmente ingeniería en sistemas en la Universidad de San Carlos que probablemente sea una de las universidades que más estudiantes de sistemas tiene (y que a la vez menos gradúa por su exigencia).

Hay datos interesantes como por ejemplo que antes había laboratorios para sistemas o que gente como la ex ministra María del Carmen Aceña fue profesora en la facultad.

Actulización: El usuario @dbillyx me compartió más contexto de este documento con sus contactos de la ADIG.

El “folleto” de la USAC, lo prepare yo. Realmente son algunos documentos que tengo y que prepare para el Director de la Carrera de Ingenieria en Ciencias y Sistemas de la USAC que este año estará cumpliendo 50 años. Su fundador fue el Ing René Woc, egresado de postgrado de Stanford de un Programa de Systems Economics. Este fue el primero en Guatemala, tuvo un periodo que se cerró (del 79 al 82) y después se reinicio el programa que actualmente funciona. En lo personal fue su Coordinador en el 75, luego fui parte del grupo que preparó el. Ir o Pensum y Director de la Carrera del año 1986 al 89. Adjunte algunas fotos de la época, en una de ellas está María del Carmen Aceña, que fue mi alumna en la UFM en 1981 y por eso, como otros me fue a ayudar dando alguna clase en esa época. Fue en el mIsmo tiempo que varios formamos ADIG en 1983, varios están ahí todavía activos, incluyendo a Fabián que fue el primer Presidente. Yo lo fui años después. En ADIG en las Convenciones entregamos algunos reconocimientos como fue al primer programador el Ing Ordóñez, quien hizo el primer sistema de nómina para la IRCA, después llamada FEGUA. Igual lo hicimos con otros, así que hay mucha historia que contar. Lo bueno es que todavía estamos varios vivos ya activos.

Sergio Silva

De Java 8 a Java 11 y 14

El culpable

En la siguiente serie de videos discutiremos los pasos para actualizar una aplicación Java de Java 8 a Java 11, los cambios significativos en el lenguaje, porqué una actualización es buena idea, y los problemas que encontraremos en el mundo real al actualizar una aplicación de Java 8 a Java 14.

Los slides están disponibles en Slideshare

Empezamos la discusión hablando un poco del proceso de creación de Java como lenguaje, plataforma y máquina virtual.

Luego de esto damos un recorrido por las principales características del lenguaje desde Java 8 hasta Java 14.

Por ultimo utilizando una demostración con MicroProfile y Jakarta EE, describimos los principales problemas al actualizar una aplicación desde Java 8 y Java 11, y actualizamos un microservicio con comunicación SOAP.

Como aprender Java para obtener trabajo (o cualquier otro lenguaje de programación)

Infografia gracias a Academik

Una de las acciones más perjudiciales que he observado en la industria, es cuando un Junior Developer le pregunta a un «Senior» acerca de lo que debería aprender para obtener trabajo en Java, siendo la respuesta más o menos así:

  • Aprende Spring Boot porqué es el framework más demandado por la industria
  • Aprende Java para Android porque lo nuevo y lo de hoy son las apps móviles
  • No aprendas Java porque Java está muerto, lo de hoy es Go

Durante los años estas frases han sido el resultado de diversas tendencias, y esas mismas frases se hubieran leído así en 2009:

  • Spring es un framework bastante útil que complementa a Java EE pero no es necesario aprenderlo, lo importante es Struts
  • Java en realidad esta bien, pero el nicho mejor pagado son las apps móviles para Blackberry, Java ME es el futuro
  • No aprendas Java porque Java está muerto, lo de hoy es Ruby

Y solo les puedo decir que todos estos consejos estaban mal, estuvieron mal y estarán mal.

¿A que se debe estos malos consejos?

Luego de algunos años participando en cursos tanto como profesor y como asistente, les puedo decir los 5 errores más comunes que yo cometí y que veo cometer a la mayoría de desarrolladores:

  1. Aprender lo mínimo de un lenguaje de programación o asumir que todos son iguales
  2. Enfocarse en aprender un framework antes que el lenguaje
  3. Seguir tutoriales específicos de un IDE
  4. Ignorar la existencia de las herramientas de compilación
  5. Omitir la documentación oficial y preferir solo tutoriales cortos

Y todos tienen más o menos la misma motivación: El tiempo.

¿Quien se tomaría 2 días en leer la documentación cuando puede desperdiciar semanas en prueba y error?

¿Entonces como debería aprender?

Como sugiere la infografia que acompaña el post, al utilizar cualquier software «comercial» o de moda, a la larga siempre trae mejores resultados aprender primero los fundamentos. Con los años esto se vuelve más importante ya que esto permite saltar al siguiente framework de moda (antes fue J2EE, luego fue Struts, luego Spring, ahora MicroProfile y mañana quien sabe). Entonces mi secuencia lógica seria:

1- Aprende programación orientada a objetos y programación funcional con Java

La mayoría de frameworks en Java utiliza tres estilos básicos de programación:

  1. Programación orientada a objetos para definir comportamiento y funcionalidad
  2. Programación reflectiva en estilo AOP (anotaciones), para darle «pistas» al framework de cual es el comportamiento que esperamos
  3. Programación funcional con expresiones lambda para completar «bloques» de funciones, especialmente en programación de sistemas escalables/reactivos

Esta situación es similar en otros lenguajes/plataformas, todos los frameworks presuponen un conocimiento general y bueno del lenguaje de programación. De lo contrario programar sera un acto de escribir software imperativo, agregar anotaciones que copiamos de un blog y culpar a Java porque se cayó el servidor.

Y este es el error #1 que veo en las universidades, en mi experiencia por ejemplo recuerdo que me metieron de cabeza en Swing a hacer una calculadora cuando ni siquiera entendía que era un compilador hacia Bytecode, aun no entiendo como no desistí de ser ingeniero de software.

2- Aprende los fundamentos de la JVM

Conceptos básicos como:

  • Saber diferenciar entre las APIs de la JVM
  • Entender el papel del bytecode en la ejecución
  • Y probablemente el más importante, entender como funciona el modelo stack-heap de la memoria RAM y el recolector de basura
  • Entender que existe no una sino varias JVM

Con el simple hecho de conocer como funciona la memoria eliminaras el mito de que Java siempre limpia la memoria. Hay programadores que se esfuerzan demasiado en hacerle la vida dificil a la JVM.

3- Seleccionar tus herramientas

No hay carpintero sin martillo y hoy en día es dificil ser un programador unicamente con un IDE, pero al pretender realizar programación comercial con Java uno suele necesitar:

  • Un IDE: De hecho lo reescribiría a ser capaz de utilizar cualquier IDE, hoy en día casi todos los proyectos Java son compatibles con todos los IDEs, tanto NetBeans, como IntelliJ como Eclipse son compatibles con Maven y Gradle
  • Un sistema de construcción: Para entender como se crea un proyecto y poder usar cualquier IDE nunca está de mas conocimiento en Maven o Gradle :).
  • Principios basicos de shell scripting: Hasta Windows ya aceptó que el Shell scripting es necesario para los programadores
  • Versionamiento de código: Hoy sera Git, mañana no lo se y pasado no se si estaremos vivos

En resumen saber una herramienta NO es igual que saber programar, pero saber una herramienta si te hará más productivo.

4- Aprende los frameworks de la industria

¿Llegaste hasta acá? Que bien, muchos empiezan por aquí y vuelven el desarrollo de software una experiencia frustrante.

Una buena forma de saber cuales son los frameworks demandados por la industria es realizar búsqueda de trabajos en LinkedIn o acudir a tu Java User Group más cercano, la buena noticia es que a la larga los frameworks en Java se parecen porque muchos de ellos usan cosas que se estandarizaron en el Java community process.

Y la mejor noticia es que si sabes Java con buen nivel de detalle, ya estas listo para saltar al siguiente gran framework, que saldrá en el futuro.

Probablemente estos sean los stacks más populares hoy en día (2019):

  • Spring Framework: (Pivotal)
  • Jakarta EE: Payara, Wildfly/JBoss (Red Hat), TomEE (Apache/Tomitribe), WebSphere (IBM), WebLogic (Oracle)
  • MicroProfile: Payara, Quarkus (Red Hat), TomEE (Apache), OpenLiberty (IBM), Helidon (Oracle)

5- Continua aprendiendo

Java lleva 25 años en la industria y continua evolucionando cada 6 meses. Probablemente le queden otros 25 más por los entornos donde se utiliza, pero la única constante en TI es el cambio.

Razor crest – El PC de $111 armado de «chatarra» que corre microservicios en Java y Gentoo Linux experimental

Uno de mis proyectos de fin de semana ha sido irle dando vida a una PC que ha estado rondando en mi casa desde hace tiempo, una laptop Compaq 610.

El proyecto aunque parcialmente útil, tuvo tres fines:

  • Comprobar como hardware de 10 años se comporta en el mundo actual
  • Evaluar si puedo obtener una PC usable x86_64 por menos de $150
  • Tener una PC antirobos/robable que sea totalmente utilizable (considerando que vivo en Guatemala)

Mi presupuesto fue invertido de la siguiente forma:

  • Batería nueva $25
  • Transmisor Bluetooth $5
  • SSD Samsung Evo 250 GB $45 (segunda mano)
  • 2 GB de memoria RAM DDR2 $6 (segunda mano)

Aunque no pagué absolutamente nada por la computadora, de acuerdo a Ebay una pc como esta se encuentra fácilmente por $30, llegando a un total de $111 🙂. Si consideramos que una OLPC valia $100 y no servia para tareas practicas, creo que estamos ante el nacimiento de One Laptop Per Tuxtor.

One Laptop Per Tuxtor

Siendo su configuración final:

  • CPU Intel Core 2 Duo T5870
  • 4 GB RAM DDR 2 800 Mhz
  • SSD 256 GB
  • Más puertos y medios que cualquier MacBook moderna (CD-ROM, Lector SD, Wifi, RJ-45, Bluetooth, USB).

Un dato curioso del proyecto es que me llevó aproximadamente 6 meses, lo financié a partir de cambios en estacionamientos, restaurantes y tiendas donde iba juntando el cambio para sentir que «no gasté nada», de otra forma no seria divertido.

Mi alcancía de Spiderman para financiar el proyecto

¿Que se puede hacer con una pc de $111?

Para considerarla usable, la computadora debe correr un sistema operativo real por lo que su primer reto fue soportar la instalación de Gentoo Linux, el Linux de escritorio más usado a nivel mundial si se toman en cuenta sus derivados.

A pesar de ser un procesador viejo fui capaz de compilar e instalar en un día (completo) un escritorio cifrado y utilizable, especificamente Mate Desktop y el siguiente stack:

  • Compiladores y lenguajes: GCC 9, Java 11, Python 3.7, NodeJS 12
  • Internet: Firefox Current (binario)
  • Ofimatica: LibreOffice 6 (binario)
  • Otros: TexLive 2019, Spotify, Visual Studio Code, NetBeans 11, Docker
Gentoo Linux, el Linux de escritorio más usado si consideramos sus derivados

Siendo sinceros la computadora se siente absurdamente bien a excepción de dos tareas:

  • Iniciar un IDE completo Java
  • Navegar en portales interactivos como Facebook o Yahoo

Aunque ya sospechaba que un IDE moderno seria demasiado para esta computadora, es increíble la cantidad de CPU que JavaScript gasta en un portal moderno, si los lenguajes de programación fueran empresas, JavaScript seria Exxon Mobile, de hecho ya hay un articulo académico que lo comprueba.

Greta viendote hacer npm install

Otro «reto» que tenia para esta computadora era evaluar el impacto de un servicio en Java. Utilizando Java , Docker y Quarkus fue posible correr 25 JVMs de un servicio rest sin que la computadora transpire, que bien le hizo a Java backend la era de los microservicios. Probablemente puedo duplicar ese número y quien sabe si cuatruplicarlo GraalVM native.

MicroProfile en una PC de 10 años

Por ultimo y dada la época original, la computadora no incluía Bluetooth de serie y al preguntar en tiendas de computación me fue relativamente dificil conseguir un adaptador USB-Bluetooth, al final encontré uno en una tienda de hardware chino que vendía hasta cigarros electrónicos, increíble como algo pasa de ser novedad a ubicuo y luego a obsoleto. 

Adaptador BT Chino

¿Porqué Razor Crest?

Es el nombre de la nave que utiliza Din Djarin, protagonista de El Mandaloriano, la cual tuvo que re construir luego de que los Jawas le afanaran todo.

¡A un lado hipsters con máquinas de escribir, ahí les voy con mi laptop de 5 libras!.

Que esperar/aprender de Java en 2020

Yo, en una foto donde me veo bien profético

Inicio el año con seis predicciones para Java en 2020. A diferencia del difunto Walter Mercado la mayoría no son resultado de ver las estrellas. Más bien son el resultado de patrones que observé en 2019 en la industria, clientes, conferencias y creo que se consolidaran en este año.

1. Java 11 finalmente se masificara

Uno de los mayores problemas con la aparición de Java 9 fue la introducción de JPMS o «Java modules». Diferente de otras versiones de Java esto creó un mar de bugs porque entre otras cosas ocultó el paquete sun.misc.unsafe utilizado por varias bibliotecas importantes.

Aunque pareciera poco importante que una biblioteca no tenga acceso a un paquete o a una característica, impacta en cascada a los usuarios de la biblioteca, que eventualmente impacta a los frameworks, que eventualmente impacta a los runtimes, que eventualmente impactan a los «developers callejeros» que utilizan estos frameworks. Toda una pesadilla.

En 2019 observé sin embargo que los grandes runtimes Java empezaron a dar soporte oficial a Java 11 ya sea como primicia o como consolidación de lo presentado durante 2018, algunos de los más importantes de los que uso en mi día a día:

  1. Tomcat
  2. Jetty
  3. JavaFX
  4. Spring Boot
  5. Wildfly
  6. Payara (ex. Glassfish)
  7. Open Liberty

Probablemente el ultimo en unirse al grupo sera WebLogic que ya tiene una versión beta con Java 11, más vale tarde que nunca :).

2. La pelea en el Java moderno se dará en el campo AOT

Uno de los mayores deseos de las bibliotecas Java hoy en día es declararse «compatible con GraalVM AOT» lo que significa que la biblioteca es compatible con la generación de binarios nativos para Linux (y Mac).

Aunque los binarios AOT son relativamente más lentos que la ejecución de bytecode sobre una JVM con JIT, en el mundo de los microservicios y sobre todo en serverless suele quedar en segundo plano frente a la velocidad de «cold start».

En esta linea Quarkus, Helidon y Micronaut lideran indiscutiblemente. Curiosamente 2 de estos 3 son compatibles con MicroProfile, ¿quien lo diría hace unos años?.

En Latinoamérica probablemente seguirá la tendencia de Spring, pero en el resto del mundo creo que su dominio finalmente se ve amenazado. Sin contar que la recompra por parte de VMWare puede traer efectos a mediano plazo sobre Spring.

3. Kotlin pasara 2020 sin brillar en el espacio backend JVM

Uno de los problemas fundamentales de Kotlin en el backend es su relativa dependencia de IntelliJ IDEA, lo cual no es un problema en desarrollo móvil, pero es un problema en desarrollo backend.

El desarrollador backend Java tradicionalmente:

  1. Trabaja en una institución financiera, startup consolidada o empresa de telecomunicaciones
  2. Soporta proyectos desde Java 6 hasta Java 11
  3. Pertenece a grupos ligeramente grandes de desarrolladores (+10 devs)
  4. Despliega sus aplicaciones en un applicaton server con soporte comercial -e.g. WebLogic, WebSphere, TomEE-.
  5. Utiliza algun IDE basado en NetBeans o Eclipse

Aunque es viable programar utilizando IntelliJ IDEA community en fatjars y microservicios, lo cierto es que se necesita IntelliJ IDEA completo para interactuar con application servers desde el IDE, lo cual limita el nivel de adopción que puede tener el lenguaje en entornos tradicionales.

Dificilmente un CTO va a decidir dar el salto de IDEs gratuitos y de calidad como NetBeans o Eclipse hacia IntelliJ donde cada copia arranca en aprox. $500. En esta linea, el soporte para Kotlin en NetBeans está muerto y el soporte en Eclipse no es el mejor.

4. JakartaEE renacerá o morirá

Luego del tumultoso traspaso de Java EE desde Oracle hasta la fundación Eclipse, se estan resolviendo finalmente las novelas alrededor del proceso, entre las más importantes:

  • La imposibilidad de utilizar el paquéte javax.*
  • La propiedad intelectual sobre la documentación
  • La propiedad intelectual sobre estandares como CDI
  • El nuevo proceso de certificación y TCK

Por lo que he leído en las listas, la tendencia en JakartaEE 9 sera remover APIs poco utilizadas en Java EE 8, pero el veredicto final si esto sera sostenible a largo plazo sera la comunidad.

Uno de los primeros pasos en la linea correcta fue el contar con implementaciónes compatibles con JakartaEE 8 lo que demuestra la solidez del proceso, pero 2020 sera crucial para la supervivencia de los estandares empresariales en Java. Creo que Eclipse ha hecho todo lo que está en su poder para involucrar fabricantes, pero sobre todo a la comunidad.

Como «lobo viejo» que cree en los estandares y la independencia de proveedores, espero que esto sea exitoso, a nivel personal lo que me ha mantenido en Java todo este tiempo no es el lenguaje, es el ecosistema y la independencia de proveedor.

5. Java 14 sera para muchos la primera beta de Java 17

Con cada nueva versión de Java, la mayoría de características nuevas suelen encajar en 3 grandes categorías:

  • Mejoras al lenguaje de programación
  • Mejoras a la JVM (entorno de ejecución)
  • Mejoras a las herramientas del Java Developer Kit

Por alguna razón las mejoras que suelen interesar a más desarrolladores siempre son las mejoras en el lenguaje y Java 14 sera un lanzamiento prometedor en esta categoría, el cual incluye algunas de las novedades más esperadas en el lenguaje:

¿Porqué la beta de Java 17?. De acuerdo al nuevo esquema de lanzamientos predecibles de Java, el siguiente LTS de Java es Java 17, donde la mayoría de personas se suben al vagón de la innovación.

6. Finalmente se estabilizara la gran batalla de las distros Java

Luego de que Oracle decidiera cambiar la licencia de su Java Virtual Machine, vimos el nacimiento de la gran batalla de las distros Java.

TL;DR: Java sigue siendo libre y gratis. Casi todas las distros se basan en código del proyecto OpenJDK.

Mi predicción es que algunas distros moriran por falta de interés o masa critica, pero seguramente las siguientes serán las sobrevivientes:

  1. AdoptOpenJDK: Fue la que pegó primero, presentó un website más bonito y es la preferida del sector hipster por no depender de un único proveedor.
  2. Oracle HotSpot: Porqué es obligatoria para cualquier cliente con productos Oracle
  3. SAP JVM: Porqué es obligatoria para cualquier cliente con productos de SAP
  4. OpenJDK de RedHat: Porqué es obligatoria para cualquier cliente con soporte comercial de Red Hat
  5. OpenJDK de tu distro Linux favorita: Si no usas Red Hat, probablemente usas una compilación propia de la distro que vivira mientras viva la distro. Son demasiados links para cada distro Linux «raiz».
  6. Azul Zing: Encontró su nicho en alianzas con proveedores importantes como Payara o Microsoft. Además de la experiencia de Azul Systems en la creación de JVMs.
  7. OpenJ9: Porqué es la JVM oficial de IBM.

No dudo en que alguien más decidirá sacar su propia distro de OpenJDK, pero como bien ha demostrado Linux, pueden existir 100 o más distros pelotudas pero todas al final derivan de 2 o 3 proyectos realmente importantes.

Eclipse MicroProfile para aplicações monolíticas

PT-BR Esses videos aqui foram o resultado da versão em português da palestra «Eclipse Microprofile for monolitic applications» apresentada em português no TDC Porto Alegre 2019. Os vídeos apresentam alguns use cases nos quais mesmo sendo deployments monolíticos as APIs do MicroProfile podem ser uteis.

ES: Estos videos son el resultado de una presentación en TDC Porto Alegre 2019, están todos en portugues pero no tengo blog en portugues para compartirlos :).

Algunas conclusiones aleatorias de la educación para programación con Java en Guatemala

Durante el meetup 2019.07 el grupo de usuarios Java de Guatemala tuvo a bien realizar una discusión con el tema enseñanza de Java en la academia.

Para esta reunión nos acompañó personal docente y académico de la Universidad de Costa Rica (sede pacifico) específicamente de la carrera de informática empresarial -i.e. desarrollo de software comercial-.

Diferente de muchas reuniones de GuateJUG, en esta ocasión logramos juntar un grupo heterogéneo de actores en el sector educativo, incluyendo profesores de enseñanza media, Universidad Mariano Galvez, Universidad Rafael Landivar, Oracle Workforce Development, Oracle University y personas de la industria bajo la misma pregunta.

¿Como y porqué es fácil/dificil enseñar programación con Java a nivel universitario?

En linea con el debate, comparto mis notas de la discusión:

  • Todos coinciden que las clases a nivel universitario en Centro América aun se dan con Java 6/7 porqué ningún programa de estudios incluye programación funcional. Esto es especialmente problemático en programación asíncrona, sistemas escalables y micro servicios, la industria NECESITA programadores con capacidades funcionales y no los encuentra.
  • Un problema aun vigente en Guatemala es que durante los años 90 la industria se desarrolló en base a tecnologías propietarias. De los asistentes alguien que se había formado en los años 90s dio su «testimonio» de como eso limitó su carrera profesional.
  • Todos los asistentes coinciden que el peor de los factores para desistir de aprender Java fue/es un mal profesor que no tiene buenos fundamentos de POO, algunos de los síntomas comunes:
    • No sabe utilizar interfaces
    • Codifica todo con métodos estáticos
  • El mejor IDE para aprender fundamentos de POO es BlueJ
  • El mejor IDE profesional para principiantes en Java es NetBeans
  • De todos los asistentes por lo menos el 30% aprendió a programar utilizando Java como primer lenguaje, el resto recibió formación previa en Pascal, C y Scratch. Al parecer es el patrón común en Centro América.
  • De las personas que aprendieron con Java como primer lenguaje, todos coincidieron que eso les abrió las puertas a dominar cualquier otro lenguaje ya que es el lenguaje más fácil para aprender programación orientada a objetos.
  • Todos los asistentes coincidieron en que el proceso de enseñanza de programación es el siguiente y es malo por un motivo:
    • Se aprende algoritmos básicos (precisos, finitos y determinados)
    • Se elaboran ejemplos en pseudocodigo de estos algoritmos
    • Se elabora un programa de computadora a partir del pseudocódigo con sentencias 0- secuenciales, 1- condicionales, 2- repetitivas, 3- invocación
  • El motivo por el cual es «malo» es porque traducir pseudocódigo hacia un lenguaje POO (Java/C#) es un proceso antinatural ya que el pseudocódigo es en esencia programación estructurada
  • Las opciones planteadas al problema anterior son:
    • Live coding en clase
    • Java REPL
    • Uso de otro lenguaje como Groovy que soporta ambos paradigmas y puede ser un buen paso intermedio hacia Java/C#
  • Uno de los principales problemas de empatar con las necesidades de la industria, es que la industria solicita dominio de frameworks. En su afan de entregar gente capaz a la industria la academia introduce estos frameworks sin mucho éxito o metodología.
  • Un problema poco visible es que los frameworks modernos y sobre todo su documentación presuponen que el lector sabe:
    • Meta-programación (anotaciones)
    • Patrones de diseño
    • Domain Driven Development
  • El JavaScript moderno es un desmadre, ES6 tuvo avances pero para alguien que ya sabe Java . . . es un desmadre
  • Aprender Kotlin como primer lenguaje podría ser un suicidio . . . pero es fácil para alguien que ya sabe Java

Espero que estas conclusiones le sirvan a alguien con el poder adecuado para cambiar la educación en el país.

Gentoo Linux Unstable + Common Desktop Environment (CDE)

Es un sistema Unix, lo conozco

He cruzado la ultima frontera hipster . . .

Luego de revivir una de mis PCs desechables con Sabayon Linux y apariencia CDE, me pregunte a mi mismo

¿Que tal dificil sera tener el CDE real?

Yo mientras migraba un proyecto de Parcel a Webpack

Aunque tengo bastante experiencia con Linux (casi 15 años si lo pienso bien), durante mi carrera profesional he tenido muy pocas oportunidades de utilizar escritorios Unix reales. Muy a lo lejos recuerdo haber utilizado una Sun Ultra con Solaris 8 en una consultoria Java 1.4 y una vez utilicé una estación de trabajo con HP-UX cuando era niño. En su momento con la estación HP-UX quedé fascinado y recuerdo a lo lejos que alguien me mencionó que era el sistema que utilizaban en Jurassic Park.

CDE en su momento fue EL ESCRITORIO para Unix y OpenVMS. Nacido como una iniciativa de HP, IBM, Sun y USL (AT&T), teniendo como objetivo en común estandarizar el escritorio utilizado en las diferentes versiones comerciales de UNIX.

Hoy en día prácticamente solo AIX y Solaris continúan el legado UNIX que fue totalmente aplastado por Linux, pero siempre estuve maravillado por CDE.

¿Que tal dificil es instalar CDE?

Originalmente CDE era posible de utilizar en algunas variantes de Unix y Linux bajo una licencia carisima. Luego llegaron GNOME, KDE y otros para cambiar el panorama con lo que CDE quedó en el olvido, aunque aun como propiedad intelectual de The Open Group, el cual a solicitud de una petición online decidió liberar en 2012.

Comparado a los entornos de hoy en día, compilar CDE es una tarea relativamente rápida, especialmente si se usan distribuciones basadas en compilación como Gentoo Linux.

La wiki establece varios pasos y dependencias requeridas para la compilación, aunque no está oficialmente soportado, utilizando como base las dependencias de OpenSUSE no tuve inconvenientes para compilarlo en Gentoo, el resultado final es hermoso.

Cuando estaba en la universidad siempre me pregunté porque Java swing trae el tema Motif . . . y hasta hace pocos años supe que Motif, era el toolkit y widgets utilizado por CDE, por lo que NetBeans no se ve fuera de lugar en su nuevo escritorio 🙂.

Microservicios con MicroProfile y Kotlin

Este es un Raw recording de la presentación dictada en Google I/O Extended Guatemala 2019, donde exploramos el uso y motivaciones de utilizar Kotlin en conjunto con MicroProfile, asi como algunos comentarios generales de construcciones utiles de Kotlin para lograr código conciso.


El enfoque de la camara no estaba bien, pero dejando eso a un lado la demo con Docker funcionó sin inconvenientes :).

Los slides estan disponibles en speakerdeck: https://speakerdeck.com/tuxtor/microservicios-con-kotlin-y-microprofile