Probando /e/, la distro Android del creador de Mandrake Linux

El Linux que instalaron en mi colegio porque el director no quería pagar licencias

Como parte de mi política trimestral de actualizar todos mis dispositivos me vi en la necesidad de actualizar mi teléfono «para ejercicio». En Guatemala (mi ciudad actual) es bastante común que las personas tengan dos teléfonos por las tazas criminales, uno para robos y uno real; o como en mi caso, uno para llevar ejercitarme en la calle y uno real.

Mi teléfono para ejercicios es un Nexus 5 que quedó hace tiempo sin soporte oficial -i.e. sin actualizaciones de seguridad-, pero es una bestia hackeable como telefono Android. Asi, ha sobrevivido al paso del tiempo utilizando ROMs comunitarias como CyanogenMod, Replicant, AOKP y LineageOS. Dada la reciente batalla entre Huawei y Google quise aprovechar la actualización para preguntarme:

¿Que tan dificil es hoy en día utilizar un teléfono con Android sin soporte de Google?

Yo merengues

Y así me tope con el proyecto /e/, liderado por Gaël Duval, conocido principalmente por ser uno de los creadores de Mandrake Linux.

La idea de /e/ es crear un ecosistema de smartphone basado en Android bajo 3 principios:

  • Ser libre de Google -i.e. No Google Location, Play, Gmail, Maps y Users Tracking-
  • Respetar la privacidad del usuario
  • Ser atractivo incluso para padres y madres

Esto ultimo, es lo que lo diferencia de Replicant cuyo principal objetivo es ser libre como Frozen.

La instalación es bastante promedio para teléfonos como el Nexus 5 que son fáciles de liberar, basta con descargar la ROM, iniciar algún tipo de recovery como TWRP y hacer flash del zip file descargado, con esto oficialmente el teléfono ejecuta /e/. Se espera que en un futuro no muy lejano sea posible adquirir teléfonos que traigan /e/ de serie.


Cada rajadura es una aventura

Al inicio /e/ presenta la opción de acceder a servicios avanzados mediante una cuenta de /e/, aun no estoy muy seguro del alcance de esta cuenta por lo cual me la he saltado simplemente y el telefono es usable. Luego, se presenta una interfaz bastante copia de iPhone/Samsung/Huawei

La propuesta de valor de /e/ es que la mayoria de apps «vitales» son reemplazadas en el teléfono por forks/nuevas aplicaciones Open Source (en su mayoría), sin embargo su «App Store» brinda acceso a aplicaciones populares tanto de código abierto como propietario.

La interfaz no es la octava maravilla del mundo, pero si es más amigable que F-Droid. Durante mis pruebas pude instalar varias aplicaciones propietarias pero vitales para mi, como:

  • Dropbox
  • Keepass2Android
  • Runkeeper
  • Facebook

Al instalar aplicaciones es posible ver los resultados de privacidad de cada app de acuerdo a Exodus Privacy en un conveniente candado bajo el boton install.

Sin embargo el proyecto aun está en sus inicios, lo cual se nota al abrir aplicaciones «vitales» como Mail

Hasta el momento es una de las distros Android más pragmáticas que he utilizado, sinceramente espero que este u otro proyecto logre masa critica, es demasiado peligroso que la tecnología dependa arbitrariamente de las decisiones de un solo gobierno.

Deshabilitar unidades de systemd en GRUB (o como reviví una PC de 2010 con Sabayon Linux)

Pingüinos Gentoo, los más rapidos de la tierra

Actualmente mi computadora principal es una Macbook Pro 15 luego del fiasco Wayland vs Nvidia y la incapacidad de hacer scaling HiDPI con resoluciones mixtas -i.e. no puedo utilizar pantallas HiDPI y proyectores a la vez-.

Sin embargo, tradicionalmente suelo utilizar una computadora de 2010 para mis labores como docente universitario, específicamente una Dell Mini 1012 la cual se «arrastraba» con Linux Mint Rosa(2016) que llegó al final del camino durante abril de 2019, obligándome a actualizarla con un dist-upgrade y obteniendo como resultado una computadora incapaz de bootear.

Dado que nunca he sido fanático de distribuciones basadas en Debian, decidí aprovechar este fracaso para probar algunas distribuciones y revivir nuevamente al muerto, obteniendo una y otra vez el mismo resultado con todos los pendrive que preparaba, incluyendo:

  • Sabayon
  • Fedora Workstation
  • CentOS 7
  • Manjaro
  • Calculate Linux

Aunque inicialmente daba por muerto el computador, mi viejo corazón de *NIX hacker me decía que no todo estaba perdido; luego, probé instalar una versión muy vieja de Gentoo Linux (Gentoo 2012 «End of World») y fui capaz de iniciar, por lo que el error era probablemente una regresión en versiones actuales del kernel.

Luego de un par de horas en el bugzilla de kernel.org descubrí que existe un error reportado para ciertos modelos Dell desde el año 2015 y que ha sido también reportado en Arch Linux y Red Hat, el cual solo se activa bajo una serie de eventos desafortunados:

  1. La computadora debe ser una Dell antigua sin teclado retroiluminado
  2. systemd intenta restaurar el nivel de iluminación previo (o nivel por defecto en instaladores)
  3. El kernel se congela por una interrupción y una versión especifica de BIOS, básicamente intenta restaurar el nivel de iluminación . . . en un teclado sin iluminación

Mi vieja versión de Linux Mint Rosa no presentaba este problema ya que fue uno de los ultimos Linux Mint en resistir ante systemd. Sin embargo y como sugieren varios workarrounds, el camino más lógico es enmascarar el servicio demoníaco con un simple:

systemctl mask systemd-backlight@leds:dell::kbd_backlight.service

Lo que en mi caso era imposible ya que había arruinado la instalación antigua de Linux Mint y los instaladores de nuevas distros eran incapaces de arrancar.

Afortunadamente una de las capacidades de systemd es recibir parámetros desde el Kernel mediante kernel-command-line. Asi, es posible alterar ligeramente los instaladores ya que la mayoría (si no todos) los instaladores de Linux siempre tienen como primer pantalla un Grub glorificado, por lo que basta con agregar el siguiente parametro a la linea de arranque:

systemd.mask=systemd-backlight@leds:dell::kbd_backlight.service

Como resultado final decidí quedarme con Sabayon Linux, la variante binaria más popular de Gentoo (mi distro de todos los tiempos) luego de Chrome OS, sin embargo para poder iniciar el instalador en computadoras tan viejas es necesario hacer un pequeño hack en el instalador Calamares para que acepte menos de 1GB de memoria RAM.

Para preservar el sentimiento a vejestorio, decidí utilizar Fluxbox con apariencia de HP-UX (Motif/CDE), tal vez en algún momento intente compilar OpenCDE.


Hands on Lab: Jakarta EE 8, MicroProfile y Oracle Cloud

Recientemente tuve la oportunidad de dictar dos conferencias en Es-Conference, uno de los mayores eventos JVM en México (y uno de mis favoritos en el circuito JVM en general).

Una de ellas fue un Live Coding/Hands on lab acerca de Java EE 8 y Eclipse MicroProfile. En esta conferencia se cubren los siguientes aspectos con un Hands on Lab simple:

  • Creación de un proyecto con Jakarta EE 8
  • Implementación de MicroProfile en un proyecto Jakarta EE
  • Implementación de servicios REST mediante JAX-RS
  • Externalización de la configuración via MicroProfile Config
  • Creación de clientes REST Typesafe con MicroProfile Rest Client
  • Creación de metricas con MicroProfile Metrics
  • Tolerancia a fallas con MicroProfile Fault Tolerance
  • Ejecución de microservicios con Payara Micro, Docker y Docker Compose/Swarm
  • Despliegue de aplicaciones docker en Oracle Container Registry y Oracle Cloud

Los slides utilizados como referencia estan disponibles en SlideShare

Y el código (bastante simple en realidad) se encuentra disponible en mi GitHub: https://github.com/tuxtor/MP-Workshop

Introducción a pruebas con Java EE 8, Arquillian y Payara 5

@Inject all the things

Continuando con el post anterior en Nabenik decidimos compartir nuestra capacitación interna de introducción a pruebas con Java EE 8, Arquillian y Payara 5.

Como de costumbre en este tipo de capacitaciones, iniciamos con la creación de un CRUD simple con Java EE 8 vanilla.

Posteriormente preparamos el proyecto para soportar Arquillian, JUnit y Payara 5.

Posteriormente escribimos nuestra prueba con ShrinkWrap.

Y finalmente lo que toda Latinoamerica unida esperaba, la creación de un test sobre un EJB.

Introducción a pruebas con JUnit y Mockito

Cuando tu mvn verify da 0 errores

Uno de los puntos más importantes y a la vez más descuidados en la educación superior en Guatemala en TI (al menos desde mi punto de vista), es la correcta implementación de pruebas de software.

Como parte de nuestras capacitaciones internas, en Nabenik decidimos compartir nuestra capacitación de introducción a JUnit y Mockito. La capacitación está enfocada a ser útil para cualquier framework de integración basado en JUnit, incluyendo Arquillian y Spring Testing, por lo que se utiliza JUnit 4, pero los conceptos son útiles para JUnit 5 por igual.

Comenzamos con la parte teórica y las motivaciones de las pruebas de software automáticas:

Posteriormente exploramos el uso de JUnit con IntelliJ IDEA (pero aplicable a cualquier IDE).

Luego controlamos las pruebas utilizando las anotaciones Before, BeforeClass, After y AfterClass

Y finalizamos con creación de Mocks utilizando Mockito

Nuevo esquema de licenciamiento y versiones de Java

El día 22 de febrero de 2019 GuateJUG llevó a cabo su reunión mensual. Diferente de otras reuniones en la desconferencia nuestra intención fue realizar un dialogo honesto acerca de lo que está pasando con Java, especialmente por la nueva licencia a partir de Oracle JDK 8u202 con todos los miembros del JUG.

La presentación utilizada durante la discusión fue una traducción de la original de Volker Simonis del equipo de la JVM en SAP.

Así mismo grabamos el audio de ambiente para los interesados (nótese que estuvimos acompañados de Dua Lipa):

Algunos puntos importantes que todos piensan que vale la pena comunicar:

  • El cambio de licencia afectara a versiones superiores a Java 8u202
  • Si se quiere utilizar Oracle JDK para Java 8 (superior a 8u202) o Java 11 en producción, es obligatorio pagar un soporte de $25 al mes
  • Si se quiere utilizar Oracle JDK para Java 8 o Java 11 en desarrollo, no se paga nada
  • En muchos casos -i.e. WebLogic- el soporte de la JVM ya está incluido en el contrato comercial
  • Si no se quiere utilizar Oracle JDK las JVM son intercambiables con Open JDK ya que Oracle JDK es en si una compilación de Open JDK con soporte comercial de Oracle. Adicionalmente Oracle ya liberó sus características «premium» y están disponibles para todo el mundo
  • La mejor analogía para entender los nuevos esquemas de soporte: Oracle JDK = Red Hat, Open JDK = Fedora, OpenJDK LTS de terceros = CentOS
  • Entre las ofertas de OpenJDK con soporte comercial (gratuito y pagado) encontramos a Oracle, Red Hat, AdoptOpenJDK/IBM, Azul Systems, Amazon, Liberica JDK, entre otros.

Como de costumbre vale la pena resaltar que todos estos datos están sujetos a cambios y la ultima palabra la tendrá su representante de ventas autorizado de Oracle :).

Adicionalmente varios usuarios actuales comentaron software que ya probaron o utilizan en producción con alguna de las variantes de OpenJDK.

  • Payara Application Server
  • IntelliJ IDEA
  • Android Studio
  • Apache TomEE
  • Eclipse IDE
  • Netbeans IDE
  • Spring Boot

Uso de Java(JVM) en Guatemala (2019)

En línea con el cambio y las nuevas políticas de licenciamiento de Oracle el grupo de usuarios Java de Guatemala se propuso realizar un primer censo del uso de Java (como JVM en Guatemala).

Los resultados fueron recolectados durante un periodo de tiempo de 10 días desde 01-02-2019 hasta 10-02-2019.

Datos generales de la encuesta:

  • Días de entrevista: 10
  • Estimativa de confianza para un grupo de 1000 desarrolladores: 95% con un margen de error de 8%
  • Personas participantes: 136

Los datos están disponibles en un ZEPL público para que cualquier persona pueda auditarlos/utilizarlos/encontrar curiosidades, los mismos fueron analizados en Spark/Scala porque . . . JVM :).

TL:DR La JVM más utilizada es Java 8 de Oracle, la cual está sujeta a cambios en el licenciamiento a partir de versiones posteriores a Java 8u202.

¿Que tanto saben las personas que existen otras JVM alternativas?

Respuesta: 3 de cada 4 sabe de la existencia de otras JVM.

¿Cual es la versión de JVM más utilizada en Guatemala?

Respuesta: Java 8 seguido de Java 7, cuyo ultimo lanzamiento público fue realizado en 2015 :O.

¿Cual es el proveedor de JDK que más se utiliza en Guatemala (producción)?

Respuesta: Oracle JDK

Disponible Eclipse Glassfish 5.1.0

Originalmente este post iba a ser más serio y ser contribuido al site de Jakarta EE, pero recordé que las contribuciones solo pueden ser en inglés.

Así que le agregué algo música a la versión en español. ¡Larga vida al pez!

Un poco de historia

Comencemos . . .

Glassfish es uno de esos proyectos que demuestra la verdadera naturaleza del software Open Source, con una premisa simple:

Siempre que exista una comunidad, el proyecto Open Source sobrevivirá a su «fabricante»

Tuxtor

Como bien relata Wikipedia, Glassfish originalmente fue un proyecto de Sun Microsystems para proporcionar un servidor de aplicaciones Java Open Source, liberando el código de lo que entonces conocíamos como Sun Java System Application Server que horrible era ese nombre.

Dato curioso: Fue acá que inicié mi carrera como desarrollador Java.

Sun Java System Application Server

Una de las razones por las cuales Glassfish fue ganando terreno es que luego de la liberación recibió un lavado de cara, fue el servidor de aplicaciones de referencia, viviendo su época dorada implementando OSGi, liberándose de algunos módulos y convirtiéndose en uno de los servidores de aplicaciones más utilizados incluso después de su «primer muerte».

Hoy en día pocas personas lo recuerdan, pero la aparición de Glassfish hizo que muchos de nosotros por fin pensáramos en el servidor de referencia como un ciudadano de primer nivel y no solo un recurso para aprendizaje.

Implementación de referencia

Y a todo esto, ¿Que significa que Glassfish fuera la implementación de referencia?

Cuando Sun Microsystems lanzó al mundo Java, una de sus primeras acciones para popularizar el lenguaje fue permitir que otros lo utilizaran y que pudieran crear sus propias implementaciones, existiendo tres estándares:

  • Java 2 ME – Para aplicaciones móviles (y luego micro)
  • Java 2 SE – Para cualquier tipo de aplicación de escritorio
  • Java 2 EE – Para aplicaciones enterprise, enfocadas a la naciente internet

A partir de acá el raciocinio es simple. Para desarrollar/evolucionar un standard de código, se necesita . . . código. Por lo que Glassfish siempre fue el primer servidor de aplicaciones sobre el cual se probaban/mejoraban/pulían e implementaban los cambios al standard que se convertiría en Java EE a secas (sin el dos). La primer resurrección

La transición

Luego de que varios proyectos Open Source perecieran ante la venta de Sun Microsystems a Oracle (Open Office, Hudson, Open Solaris), Glassfish se mantuvo en aguas firmes y sobrevivió a la transición. En su momento y a pesar de la existencia de WebLogic, Oracle aprovechó la fama de Glassfish ofreciendo paquetes de soporte comercial.

Y luego en 2013 todo se derrumbó.

Oracle anunció que a pesar de que seguiría siendo la implementación de referencia, Glassfish no contaría más con soporte comercial (lo cual dio nacimiento eventualmente a Payara).

En la época (2013), escribí un articulo denominado «la paradoja de Glassfish» que tiene más detalles al respecto.

Y nos vamos . . . a Eclipse

https://www.youtube.com/watch?v=i68sHKXnGuM

Luego de la publicación de Java EE 8 en 2017 y varios llamados de atención entre Oracle y la comunidad, Oracle anunció en Java One que donaría Java EE a la fundación Eclipse, cediendo por tanto el liderazgo de los estándares, incluyendo:

  • Las implementaciones de referencia (las bibliotecas que conforman Glassfish)
  • Los TCK (que hasta el momento eran de código cerrado)
  • La propiedad intelectual de los estandares ya existentes (y el derecho a utilizar el paquete javax.*).

El año de la transición

Transferir un proyecto de la magnitud de Java EE es algo que ha pasado pocas veces en la historia de la computación, para ponerlos en perspectiva, Java EE sin los test tiene más lineas de código que Firefox, 13.5 millones de líneas de código en 95 mil archivos.

Como relatá Dmitry Kornilov en Oracle Developers, transferir un proyecto de este tipo fue un esfuerzo sin precedentes. Y he de decir, Oracle ha sido vital para que este proceso sea posible, como bien se demuestra en las contribuciones.

¿Que significa realmente Eclipse Glassfish 5.1.0?

Durante la transición hay varios factores implicados pero a nivel de código la nueva versión significa lo siguiente:

  • El código ha sido transferido a Eclipse (39 proyectos y 88 repositorios)
  • Se han creado diversos sub-proyectos para cada componente
  • Se ha aplicado la licencia obligatoria de todos los proyectos en la fundación Eclipse, la Eclipse Public License
  • Se tienen nuevas coordenadas de Maven
  • Ya es posible compilar Glassfish y sus componentes mediante la estructura de integración continua de Eclipse

Además de algunos bugs mayores este lanzamiento no cambia mucho respecto a la version original de Glassfish 5. La idea de este release es demostrar que Eclipse es capaz de dar un nuevo acuario al pez. Y que el proyecto sobrevivirá bajo Jakarta EE.

¿Puedo utilizar Eclipse Glassfish 5.1.0?

Por supuesto, tanto el pom con las nuevas coordenadas como la distribución en zip ya estan disponibles para su uso en:

https://projects.eclipse.org/projects/ee4j.glassfish/downloads

Como no tenia una demo preparada sin MicroProfile, decidí hacer algo más divertido, conectar Apache Netbeans 10 con Glassfish 5.1.0 sobre OpenJDK 8 de AdoptOpenJDK y probar que el mundo no es el mismo de antes



Tips para mejorar tu carrera como desarrollador

Gracias a una invitación de CUNOC, tuve la oportunidad de preparar una charla diferente de todas las que doy. En esta oportunidad hablé de como «mejorar tu carrera como desarrollador».

En su momento estuve a punto de declinar esta charla ya que no me sentía con autoridad para impartirla ni se me hace muy comodo impartirla, especialmente porqué no me considero un desarrollador élite ni mucho menos un Tycoon. Sin embargo la invitación era específicamente para figurar como «role-model» de futuras generaciones de ingenieros en sistemas.

Por este motivo decidí enfocar la charla en que cosas he hecho mal y que cosas me hubiera gustado saber al momento de estar y salir de la universidad. También un par de comentarios acerca de como pueden convertirse en Java Champion.

La grabación es de la misma charla en Java Day Guatemala 2018, probablemente sea la ultima vez que la de, espero que sea útil o al menos se diviertan 😁.

Habilitar el repositorio Maven de Oracle para realizar conexiónes via JDBC

En estos mini tutoriales «de vuelta a clases» demostraremos como preparar nuestra instalación de Maven para descargar dependencias desde el repositorio Maven de Oracle. Posteriormente, realizaremos un proyecto simple para demostrar una conexión con Oracle y nuestra nueva dependencia de Maven.