El siguiente vídeo es la grabación en vivo de parte del workshop denominado «Introducción a Kotlin para Desarrolladores Java» como parte de los meetups del grupo de usuarios Java de Nicaragua
Durante la charla se explora Kotlin como un lenguaje de programación desde el punto de vista del desarrollador Java, ventajas, desventajas asi como bloques y expresiones propias del lenguaje.
Como de costumbre, la presentación se encuentra disponible en slideshare.
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.
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.
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.
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:
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 ENCARECIDAMENTE como en cualquier otra App de Android, por ejemplo en Android 9:
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:
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.
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».
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:
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:
La infografia es gracias a Academik.
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.
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
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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
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.
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í:
Durante los años estas frases han sido el resultado de diversas tendencias, y esas mismas frases se hubieran leído así en 2009:
Y solo les puedo decir que todos estos consejos estaban mal, estuvieron mal y estarán mal.
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:
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?
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:
La mayoría de frameworks en Java utiliza tres estilos básicos de programación:
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.
Conceptos básicos como:
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.
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:
En resumen saber una herramienta NO es igual que saber programar, pero saber una herramienta si te hará más productivo.
¿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.