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:
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!.
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:
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:
Trabaja en una institución financiera, startup consolidada o empresa de telecomunicaciones
Soporta proyectos desde Java 6 hasta Java 11
Pertenece a grupos ligeramente grandes de desarrolladores (+10 devs)
Despliega sus aplicaciones en un applicaton server con soporte comercial -e.g. WebLogic, WebSphere, TomEE-.
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.
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:
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.
Oracle HotSpot: Porqué es obligatoria para cualquier cliente con productos Oracle
SAP JVM: Porqué es obligatoria para cualquier cliente con productos de SAP
OpenJDK de RedHat: Porqué es obligatoria para cualquier cliente con soporte comercial de Red Hat
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».
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.
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 3proyectos realmente importantes.
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 :).
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 esNetBeans
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
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.
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 🙂.
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 :).
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 5que 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.
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.
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:
La computadora debe ser una Dell antigua sin teclado retroiluminado
systemd intenta restaurar el nivel de iluminación previo (o nivel por defecto en instaladores)
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:
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:
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.
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
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.
