PT-BR: O vídeo é uma gravação raw da palestra apresentada no meetup online do SouJava. Na conversa a gente percorre algumas das mudanças mais importantes na linguagem Java desde Java 8 ate Java 14. Fazendo uma discussão de como diversos aplicativos Java podem ser atualizados e as vantagens da atualização.
Java 14 en acción
ES: Este video es el resultado de una presentación en SouJava acerca de las actualizaciones en el lenguaje de programación Java desde Java 8 hasta Java 14, el vídeo como tal está en portugues pero no tengo blog en portugues para compartirlos :). De cualquier forma esta charla cuenta con una versión en español.
Como probablemente han notado en otros post, tengo una pequeña colección de computadoras antiguas que mantengo como hobbie, dándole uso ocasional a alguna de ellas y otras que solo las mantengo como reto.
Mi laptop más antigua es una computadora single core Celeron M de 32 bits con 1GB de RAM y 60 GB de disco duro. Para la época que mi papá me la regaló era una computadora de mediano porte (ya que las laptops no eran tan ubicuas), pero complementaba bien mi computadora Pentium 4 de 32 bits single core. Con estas dos computadoras inicié y finalicé la universidad.
El siguiente vídeo es la grabación en vivo de parte del workshop denominado «Desarrollando aplicaciones empresariales con ECMA 6 y TypeScript» como parte de las jornadas de actualización CEDUCA del colegio de ingenieros de Guatemala.
Durante la charla se explora el funcionamiento de JavaScript, ECMAScript 6 y TypeScript
Como de costumbre, la presentación se encuentra disponible en slideshare.
El día de hoy noté en redes sociales que varias personas le tenían miedo al app de Alerta Guate, la cual el Gobierno de Guatemala designó como la app oficial de comunicaciones con la población de Guatemala en tiempo de COVID-19, argumentando que era un app Israelí y tuvo apoyo de Google.
El gobierno les ofrece que instalen un APP que se llama ALERTA GUATE, desarrollada por israelíes.
NO LA INSTALEN. Eso es espionaje masivo. Repito, NO LA INSTALEN.
Al inicio creí que muchas de estas afirmaciones tenían demasiado tinte político, sin embargo lo que puedo hacer «de mi lado» es analizar los factores tecnológicos.
Mi objetivo bajo ningún motivo es demeritar o apoyar el trabajo del gobierno, ni unirme a alguna corriente ideológica. Creo firmemente que la tecnología es un medio que hay que utilizar cuando sea necesario, especialmente en crisis como las que estamos atravesando. Pero también creo que una aplicación de tipo gubernamental debe tener siempre la auditoria social mínima.
Permisos
La aplicación está diseñada para requerir los siguientes permisos:
Por si mismos la cantidad de permisos no es algo preocupante, ya que Android ha tenido la tendencia en los últimos años a volver los permisos más granulares. Lo único que me parece molesto en la aplicación es la insistencia para garantizar el permiso de «Do not disturb» lo cual en otras palabras significa que aunque coloquemos nuestro teléfono en modo no molestar, esta aplicación en particular nos dará las notificaciones. Similar a como se comporta Android Auto.
Como relata el screenshot de twitter el app efectivamente tiene acceso a:
Obtener ubicación
Grabar audio
Utilizar las apps de telefono
Acceder al almacenamiento
La única que me parece realmente preocupante es el acceso que tiene al almacenamiento ya que desconozco el objetivo para el cual tiene este permiso, de hecho en las nuevas versiones de Android ustedes mismos pueden denegar individualmente esos permisos, LO CUAL RECOMIENDO ENCARECIDAMENTEcomo en cualquier otra App de Android, por ejemplo en Android 9:
Comunicaciones
Al parecer la aplicación permitirá llamar directamente a servicios de emergencia y recibir comunicaciones mediante distintas vías, para esto utiliza como biblioteca de comunicaciones Twilio.
El gobierno anunció que la aplicación estará lista hoy por la noche (24 de marzo) por lo que aun no tiene backend, si monitoreamos los intentos de comunicación que realiza la aplicación, los mismos van hacia la API:
https://api.in-telligent.com
API a la cual se comunica Alerta Guate
La cual efectivamente coincide con el fabricante anunciado en Google Play:
La empresa que hizo el app
Si vemos los datos del fabricante, al parecer es una empresa dedicada a crear aplicaciones de alerta, pero de todos los países solo la app de Guatemala tiene un logo «diferente y oficial»:
Creería que el modelo de negocio de la empresa es brindar soluciones de uso gratuito, esperando a recibir soporte del gobierno y dar alertas con publicidad. Lo cual no es necesariamente malo, alguien tiene que pagar la infraestructura.
Creería que el único gobierno que lo ha hecho oficial es el gobierno de Guatemala. Como referencia, así se ve la aplicación en versión México, donde el banner en la parte inferior es un banner típico de apps de publicidad.
Acerca de la empresa
Luego de confirmar la empresa, traté de indagar un poco más al respecto, tanto en Crunchbase como en Twitter se presentan como una empresa estadounidense:
Si buscamos la empresa en LinkedIn, la mayoria de sus empleados están en Estados Unidos:
No encontré mayores referencias a una empresa Israelí como relatado por el presidente, tal vez fue un error de comunicación y el mensaje era «un contacto Israelí nos facilitó el uso de esta app con la empresa X».
Términos de uso (edit)
Al utilizar las apps de In-telligent, los usuarios se comprometen entre otras cosas a lo siguiente, de acuerdo a su website y en traducción libre:
Solo se encuentra disponible para mayores de 18 años
Estar de acuerdo con que la empresa recolecte información personal, identificable y vinculable con el usuario
La geolocalización tambien es identificable y vinculable al usuario
La información se utilizara para proveer información y también ofertas
La información se puede compartir con terceros para fines publicitarios
Conclusiones
Como en cualquier otra aplicación Android, el usuario que decida utilizar el app deberá estar consciente de los permisos que otorga
Seria interesante analizar el código del app pero estoy 100% seguro que eso es ilegal y no lo intentare 😁
Por si solo el modelo de negocio de la aplicación no es malo, en un mundo ideal todos los gobiernos tienen un sistema de alerta publico y tecnológico a través de apps, sms, teléfono, etc.. Pero esté momento de la historia es de lejos todo lo contrario a un mundo ideal. Me gustaría que en los hackatones que seguramente se realizaran en estos días se pudiera brindar una alternativa real, de código abierto y sobre todo que garantice que los datos se quedan en Guatemala, crítica con propuesta decía uno de mis profesores.
Sinceramente más que el App, me preocupa que digan que es una app Israelí, espero que haya sido una confusión menor al respecto.
Personalmente seguiré informándome vía Facebook con los «Giammatei Direct» y en la radio. No tengo los elementos suficientes para descartar el uso de la app de gobierno si se usa con permisos mínimos y consciente de que nuestros datos se compartirán con una API de terceros con fines comerciales.
Tampoco tengo los elementos suficientes para confirmar que es una app Israelí, al menos no en la información publica disponible en internet.
Una de mis motivaciones para escribir este post es que he visto dos tendencias tanto al contratar personas como al ser contratado por personas, la existencia de barreras artificiales, expectativas irreales por parte de desarrolladores y contratistas sin claridad en las responsabilidades, los niveles clasicos suelen ser:
Como muchas cosas en el área de TI, los criterios suelen ser subjetivos y heredados desde Estados Unidos, no están estandarizados en la industria, pero se pueden observar ciertas características y tendencias en cada nivel/oferta laboral.
En esta «clasificación» presento mis conclusiones luego de participar como interesado en plazas laborales, así como auxiliar a equipos de desarrollo y reclutamiento a contratar candidatos.
Junior Developer
Uno de los criterios primarios para identificar a un Junior Developer es su experiencia, o para ser más precisos, la falta de experiencia. Lo cual no es necesariamente malo
Características generales:
Un desarrollador recién egresado o aun estudiando en la Universidad/bootcamp/curso técnico de programación
Desde 0 a un máximo de 3 años de experiencia (ideal 1 año)
Suele tener experiencia en un lenguaje de programación, plataformas actuales aunque no necesariamente establecidas
Responsabilidades y roles ideales:
Se espera que la persona que haya sido contratada como Junior no tenga «mucha idea» de conceptos avanzados en su técnologia
Sus principales labores suelen ser dar mantenimiento a un sistema existente con lineamientos claros de arquitectura
Se espera que un desarrollador Junior eventualmente pueda ir tomando responsabilidades conforme avanza en su formación personal y profesional
Principales debilidades y consejos:
Suelen saber mucho superficialmente y poco a fondo. Aunque en TI nunca es bueno «casarse con una tecnología», si es bueno ser especialista en algo.
Aprender antes frameworks que lenguajes. Mi consejo en este caso siempre es aprender un lenguaje a fondo para entender mejor los conceptos fundamentales, mi listado siempre ha sido:
Aprender un lenguaje de tipado estático, idealmente Java
Aprender un lenguaje de típado dinámico, idealmente JavaScript
Aprender un lenguaje scripting, idealmente Bash.
«No saben que no saben». Algo conocido como el efecto Dunning Krugger. Mucho de esto se debe a la falta de enfrentamiento a proyectos reales y la única forma de acelerarlo es participar más en proyectos, participar en Open Source y rodearse de gente con más experiencia que pueda compartir sus conocimientos. Mientras más interacciones se tienen con el gremio/entorno es mejor para formarse una perspectiva amplia.
No les importa tanto el negocio. Aunque no todos nacimos para ser Project Managers, una receta para ser mal desarrollador es que no importe la generación de valor para el cliente.
No les importa tanto la arquitectura. Una de las tendencias modernas es que las herramientas suelen ser más fáciles y a la mayoría de developer Junior no les importa la arquitectura, la cual generalmente no es importante para entregar soluciones rápido pero es importante para que el código sea mantenible y escalable.
Mid developer
Uno de los criterios primarios para identificar a alguien como el Mid-developer es la experiencia en una plataforma, generalmente a un Mid developer se le pueden delegar tareas y reducir la supervisión e incluso trabajar en posiciones freelance.
Características generales
Un desarrollador que ya tuvo un contacto con educación en desarrollo de software en cualquiera de sus formas
Una persona que ya entendió que el ser autodidacta en el medio es super importante
Desde 1 a 5 años de experiencia
Responsabilidades y roles ideales
Se espera que la persona contratada como mid developer tenga familiaridad con herramientas universales en el desarrollo de software como sistemas de control de versiones, linea de comandos básica y un lenguaje de programación
Se espera que una persona contratada como Mid developer pueda utilizar jerga común en el área de sistemas
También se espera que sea un developer al cual se le pueden asignar tareas con componentes de investigación, desarrollo y sentido de responsabilidad
Se espera que sea un desarrollador con formación completa respecto a una plataforma
Principales debilidades y consejos:
Les es dificil migrar entre frameworks. Una característica «evolucionada» de ser un Junior developer en el dilema practicidad vs. fundamentación teórica, es la capacidad de evolucionar con el tiempo. Mi consejo es el mismo que para los Jr. Developers.
Sobreutilización de patrones. Aunque parezca una paradoja, una de las diferencias claras entre un developer Mid y un Sr. es saber cuando utilizar correctamente las herramientas/patrones/abstracciones, esto básicamente viene con la experiencia.
Les es fácil ser dogmáticos con la técnologia. Una vez se ha invertido una considerable cantidad de tiempo en la técnologia, es dificil aceptar que las soluciones van cambiando y lo que solía ser lo ideal, puede que ya no sea lo ideal.
No les importa tanto ayudar a otros desarrolladores en su equipo. Y esto previene muchas veces el avanzar en su carrera como desarrollador, el tomar responsabilidad de sus tareas y también del proyecto.
Senior developer
Uno de los criterios primarios para identificar a alguien como senior developer es su capacidad de trabajar en equipo, liderar equipos de desarrollo desde el punto de vista tecnologico y toma de decisiones.
Características generales
Un desarrollador que conoce a fondo varias plataformas (lenguaje, bibliotecas, entornos de ejecución)
Un desarrollador que cuenta con varios tipos de experiencia en proyectos exitosos pero sobre todo fracasados
Un desarrollador que se prepara y actualiza constantemente mediante certificaciones, cursos cortos, MOOCs, conferencias, libros, grupos de usuarios, etc.
De 5 años de experiencia en adelante
Responsabilidades y roles ideales
Se espera que la persona contratada como Senior developer tenga conocimiento avanzado en dos una plataforma y conozca dos o más plataformas para distinguir entre fortalezas y debilidades (gracias por el feedback en este criterio, parece ser un consenso común)
Se espera que un senior developer pueda participar en procesos revisión de código por pares (peer review)
Es un developer al cual se le pueden asignar tareas complejas, software de alto desempeño, software crítico y tolerante a fallos
Se espera que sea un developer que eventualmente pueda participar como líder de desarrollo (lead developer) ayudando a los demás miembros de su equipo con su experiencia
Principales debilidades y consejos:
Les es aun más fácil ser dogmáticos con la técnologia. Una vez que se es Senior no es dificil obtener trabajo en la técnologia de preferencia. Esto no es bueno ni malo pero en plataformas poco establecidas -e.g. Clojure- puede ser algo que le afecté en el futuro.
El ego. Un developer senior real no tiene problemas en reconocer que todos somos Junior en algo, un developer senior reciente suele tener mucho ego. Mi único consejo es la humildad y menos azucar. Esto a la larga suele jugar a nivel organizacional para volverse arquitecto de software.
Arquitecto de software
La linea entre un desarrollador Senior y un arquitecto de software suele ser muy delgada ya que ambos son profesionales con experiencia bajo el cinturón. Generalmente va más relacionada a la orientación de las tareas que cada uno realiza. En el caso de arquitecto, sus tareas van más enfocadas a investigación y desarrollo vs producción de software.
Debo decir que muchas veces el rol de arquitecto de software se confunde con el de gestor de proyectos pero esto depende en mayor o menor medida de las políticas de cada empresa.
Características generales
Un desarrollador que conoce a fondo varias plataformas (lenguaje, bibliotecas, entornos de ejecución)
Un desarrollador que cuenta con varios tipos de experiencia en proyectos exitosos pero sobre todo fracasados
Un desarrollador que se prepara y actualiza constantemente mediante certificaciones, cursos cortos, MOOCs, conferencias, libros, grupos de usuarios, etc.
De 5 años de experiencia en adelante
Responsabilidades y roles ideales
Se espera que la persona contratada como arquitecto de software tenga conocimiento avanzado dos una plataforma y conozca dos o más plataformas para distinguir entre fortalezas y debilidades (gracias por el feedback en este criterio, parece ser un consenso común)
Se espera que un arquitecto de software pueda tomar decisiones desde los puntos de vista técnicos, económicos y humanos en relación a la tecnológia a ser utilizada.
Es un developer que ya cometió demasiados errores y aprendió de ellos.
Se espera que sea un arquitecto de software defina lineamientos, políticas de calidad, de contratación de personal, tecnologías y proyecte la evolución de un sistema.
Se espera que un arquitecto de software pueda cargar con la responsabilidad del éxito o fracaso de sus lineamientos en proyectos de software
Principales debilidades y consejos:
Al alcanzar cierta edad es extremadamente fácil aburrirse de programar. Pero pienso que programar (incluso POCs) es la única forma real de evaluar las fortalezas de cada plataforma.
Un arquitecto real cobra caro. Y el no tener un arquitecto real puede ser incluso más caro dependiendo las características del proyecto.
El ego. Un arquitecto real no tiene problemas en reconocer que todos somos Junior en algo, un arquitecto reciente suele tener mucho ego. Mi único consejo es la humildad y menos azucar.
Una de las cosas más difíciles para un arquitecto es desarrollar la empatía. Esto es fundamental para entender las necesidades de compañeros de trabajo, clientes y mi único consejo es salir más.
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.
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?
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 absurdacantidaddeenlacesdela 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
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.
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.
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.
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 consejosestaban 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:
Aprender lo mínimo de un lenguaje de programación o asumir que todos son iguales
Enfocarse en aprender un framework antes que el lenguaje
Seguir tutoriales específicos de un IDE
Ignorar la existencia de las herramientas de compilación
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:
Programación orientada a objetos para definir comportamiento y funcionalidad
Programación reflectiva en estilo AOP (anotaciones), para darle «pistas» al framework de cual es el comportamiento que esperamos
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
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):
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.
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!.
