El abismo de tux

Mi #MovedbyJava con fotos hasta 2020

Posted on by tuxtor

En 2020 Java cumple 25 años, para celebrar el equipo de Oracle promovió el hashtag #MovedbyJava, mediante el cual las personas puedan compartir como Java ha impactado sus carreras e incluso sus vidas.

Mi jornada va más o menos así:

2006 – ¿Como aprendí Java?

Como estudiante de la Universidad de San Carlos llegué a la universidad en un periodo de cambio, donde el Ingeniero Armin Mazariegos reformó el pensum y cambió los lenguajes con los que se enseñaba en los cursos, promoviendo Java y .net como plataformas.

Los labs de la India, en su forma actual y con las compus de cuando aprendi Java 😅

Aunque la decisión le valió muchas criticas, lo cierto es que también consiguió un acuerdo con la embajada de India en Guatemala, específicamente para instalar el India-Guatemala IT Centre of Excellence conocidos como los laboratorios de la India.

En estos laboratorios tuve la oportunidad de recibir aproximadamente un año de capacitación con Java 5 y J2EE, las capacitaciones fueron exigentes a nivel de certificación. Con 18 años no sabia para que me serviría todo eso pero era divertido.

Hasta la fecha opino que el proyecto a nivel de números fue un fracaso, ya que a pesar de que la universidad es la más grande del país, los cursos originales (con instructores de India) los llevábamos en grupos pequeños de no más de 15 personas porque eran en ingles y fuera de horarios de clases. Una pena.

2006-2009 La comunidad de software libre

Mi tiempo libre durante la universidad lo invertía en comunidades de software libre, específicamente de Linux, en esta época Sun Microsystems era vista como una empresa benévola, y amiga del software libre, por lo que todos nos alegramos cuando liberaron el código de Java bajo GPL.

Entre otras cosas, varias personas iniciamos el Open Source University Meetup, una especie de grupo donde se promovían tecnologías abiertas como Java, Open Solaris y MySQL, todas en ese entonces bajo el brazo de Sun MicroSystems.

En esa época nos enviaban freebies:

2009-2011 – Mis primeros trabajos en Java

Aunque en la universidad experimenté muchos más lenguajes y plataformas (especialmente QT, Python y Ruby) lo cierto es que difícilmente hubiera encontrado trabajo con herramientas libres de no ser por Java.

El mundo de TI hoy en día no es el mismo que hace algunos años. Antes de la revolución de lenguajes y la apertura de transnacionales, en Guatemala era raro encontrar trabajo en algún lenguaje que no fuera parte de .net, de hecho solo conocí a una persona en la universidad que trabajaba en Java, mis tres primeros trabajos en Java fueron

  • Desarrollador freelance: Para la procuradoria de derechos humanos en Guatemala, acá tenían un sistema que era una mezcla de JSP, Struts y Faces
  • Desarrollador freelance: Para OpenTraining. Aca hice mucho desarrollo usando Struts, Faces y Linux :).
  • Desarrollador (y posteriormente Arquitecto) Java en Mobilges: En su tiempo la empresa se llamaba Soluciones Estrategicas, fue acá donde conocí Java en todas sus variantes ya que realizamos proyectos con J2ME (sobre BlackBerry), Java EE 5, Java SE 6 y 7. Hasta la fecha recuerdo con mucha estima este trabajo porque me permitió desarrollar mi potencial y NO ME OBLIGARON JAMAS A USAR TRAJE o camisa formal.
Frente del Case
Teletran 1, mi primer PC comprada con Java

2010 – GuateJUG

El grupo de usuarios Java de Guatemala -GuateJUG- es probablemente uno de los más antiguos en Centro América que aun siguen vigentes, a pesar de que inició en el 2007 en 2010 tuvo su «reinicio» al cual me uní para colaborar. Originalmente colaboraba solo como administración de sistemas, paginas y repositorios, pero el involucrarme en sus actividades cambió el rumbo de mi carrera:

Logo hecho por informaticos en 2010

2012-2014 – Mi beca en Brasil

El involucrarme en Open Source y difusión de conocimiento me abrió las puertas para vivir en Brasil. En este periodo de tiempo me dediqué a la investigación pura en ciencias de la computación y me aleje de Java para caer en . . . Scala, realmente nunca salí de la JVM.

Entre otras cosas pude presentar y asistir al Forum Internacional de Software Livre que en ese entonces era la segunda mayor conferencia de Software Libre en America Latina, acá entendí cual era el valor del networking y de las comunidades de software:

También acá conocí personas importantes de la comunidad Java que me ayudarían en los años venideros.

2014-2020 La comunidad Java Global

Luego de regresar a Guatemala y conocer a la comunidad global Java, poco antes del mundial de Brasil inicie a trabajar en Nabenik, originalmente nació como una empresa para brindar consultorías puntuales y ha ido creciendo a su propio ritmo.

Acá, también tuve la oportunidad de ir a mi primer Java One en Estados Unidos 2015. Recibí sponsorship de Oracle para el ingreso al evento en un programa de apoyo a los Java User Groups.

Lo más importante de conferencias como Java One no son las charlas (que de igual forma son de alto nivel) sino la calidad de networking que uno puede hacer en estos eventos. Por mi parte recibí apoyo de Nabenik para los costos del viaje y yo pagué algunos costos adicionales, la mejor inversión que he hecho en mi carrera hasta este momento.

En este punto conocí también a los integrantes de jespañol, con los cuales hemos hecho varias actividades en conjunto para promover Java en América Latina.

Luego de muchas actividades, certificaciones, viajes, clientes y un proyecto junto a GuateJUG con el cual recorrimos Guatemala enseñando Java, el vino a casa:

Mr, Duke, el mejor porta audifonos

Y eventualmente también esto pasó:

¿Fue mala idea aprender Java?, ni por un instante.

Le debo mucho a la comunidad Java por lo que ¡Vamos por los proximos 25 años!

Protegiendo aplicaciones con Payara Fish, MicroProfile JWT y OWASP Top 10

Posted on by tuxtor

Esta es la grabación de una charla cuyo titulo original es «Seguridad en aplicaciones Java 101» aunque su enfoque (al menos en demo) es como proteger aplicaciones utilizando el OWASP Top 10

Durante la charla se explora la fundamentación teórica de la seguridad en Java y nos enfocamos en el OWASP Top Ten para Jakarta EE

Posteriormente hacemos una demostración de MicroProfile JWT con Payara Application Server

Por último explicamos como funciona un generador de Tokens JWT con acceso a los realms de usuarios en Payara Application Server

Como de costumbre, los slides se encuentran disponibles en Slideshare

El código fuente se encuentra disponible en GitHub

Introducción a Kotlin para Desarrolladores Java

Posted on by tuxtor

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.

De Java 8 para Java 14 PT-BR

Posted on by tuxtor

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.

OpenSolaris 2008.11, como era programar/aprender Java poco antes de la muerte de Sun MicroSystems

Posted on by tuxtor

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.

Continue reading →

Desarrollando aplicaciones empresariales y web con ECMA 6 y TypeScript

Posted on by tuxtor

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.

Una auditoria rápida al app Alerta Guate

Posted on by tuxtor

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.

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 ENCARECIDAMENTE como 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

  1. Como en cualquier otra aplicación Android, el usuario que decida utilizar el app deberá estar consciente de los permisos que otorga
  2. Seria interesante analizar el código del app pero estoy 100% seguro que eso es ilegal y no lo intentare 😁
  3. 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.
  4. 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.
  5. 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.
  6. Tampoco tengo los elementos suficientes para confirmar que es una app Israelí, al menos no en la información publica disponible en internet.

Discutiendo las diferencias entre programador Junior, Mid, Senior y Arquitecto de Software

Posted on by tuxtor
Un programador Junior con 50 años de experiencia

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:

  • Junior Developer
  • Mid/Regular Developer
  • Senior Developer
  • Software Architect
Versión TL:DR

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.

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.

Empaquetando aplicaciones Java con Docker y Kubernetes

Posted on by tuxtor

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

Posted on by tuxtor
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.

Tesis historia de la computación en GuatemalaDescarga

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).

Historia ECYS USACDescarga

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