No todo es IA & JS: mi proyecto con Oracle forms

Desde hace un par de semanas estoy ayudando a una organización a mejorar su proceso de delivery. Se trata de una organización que ofrece una plataforma de software que fue construida hace más de 20 años y que hoy en día sigue en operación, dando soporte a un negocio y resultando rentable para sus creadores.

Las tecnologías populares en aquella época (año ~2000), eran bastante distintas a las actuales. Una tecnología bastante popular por aquellos años era Oracle Forms que fue la tecnología elegida por esta empresa para desarrollar su software. Dudo mucho que en la actualidad se sigan haciendo nuevos desarrollos con Oracle Forms, pero sin duda hay varias soluciones construidas con esta tecnología que aún siguen operativas.

En el caso particular de mi cliente, el core de su plataforma está construido con tecnología Oracle pero con el correr de los años han ido generan «nuevas capas» con tecnologías más actuales como ser Java y JavaScript/TypeScript. Esta es una estrategia muchas veces utilizadas en los bancos con sus core bancarios construidos en tecnologías como COBOL.

Entre otras cuestiones lo que estamos haciendo es estandarizar el esquema de versionado y automatizar el proceso de despliegue. Venimos bien, aún me quedan unas 6 semanas de trabajo lo cual creo que es suficiente para completar la tarea.

Continuará…

Prompteala 2025

Ultimamente hay eventos de IA por todos lados, luego de asistir a un par que me resultaron muy pobres (o dicho en vocabulario técnico: «puro humo»), decidí dejar de participar. Pero cuando vi el anuncio de Promptleala y vi que era organizado por la gente ArqConf no dudé en anotarme. Es que conozco a la gente de ArqConf (Gus Brey y secuaces) y me consta que hablan desde la experiencia. Y la verdad que una vez más, no decepcionaron. Sinceramente estuvo muy bien.

El evento se realizó el pasado 8 de Octubre en las instalaciones de la Universidad de CEMA. El carismático Ulises Martins ofició de host y lo hizo muy bien.

Todas las charlas que vi me parecieron muy buenas, pero sin duda las dos que más que gustaron fueron las Tomás Bacigalupo (Product Talk : activando IA en mobile) y la de Ricardo Di Pasquale (La IA sin ingeniería no alcanza ni escala).

Las charlas están disponibles en YouTube.

Proyecto nuevo, código viejo: update

Hace un par de semanas comenté de este proyecto que estaba iniciando.

Al momento que estoy escribiendo estas líneas hemos completado 6 iteraciones.

Luego de unas 3 primeras iteraciones un poco accidentadas, ya hemos logrado equilibrio con un flujo de trabajo bastante armónico y decente. Esto puede observarse, entre otras cuestiones, en las métricas recogidas en la siguiente tabla.

Podemos observar que en las 2 primeras iteraciones no se cumplió con el objetivo de la iteración y tampoco se pudo completar la cantidad de ítems planificados. Asimismo en la tercera iteración, logramos cumplir a medias con el objetivo, pues logramos codearlo pero no llegamos a tiempo a completar el testing.

Finalmente, ya a partir de la cuarta iteración logramos cumplir con el objetivo de la iteración y también mejoramos la cantidad de ítems completados respecto de los planificados.

Algunas cuestiones que me parece relevante compartir:

  1. Al ser un equipo nuevo, es normal que el equipo necesite 4 o 5 iteraciones hasta «fluir» y lograr equilibrio.
  2. Trabajamos en iteraciones semanales y nos llevó 1 mes alcanzar el equilibrio. Es importante notar que el equilibro no está dado necesariamente por el tiempo calendario sino que es más importante la cantidad de ciclos. Lo que nos permite «estabilizar/mejorar» es la cadencia de ajuste y reflexión al final de cada ciclo. Durante las primeras semanas hicimos retrospectivas todas las semanas pues éramos conscientes que teníamos aún mucho por mejorar. Si hubiéramos trabajado con iteraciones de 2 semanas (como hacen muchos equipos), seguramente nos habría llevado mucho más tiempo calendario.
  3. Si bien puntuamos todos los ítems, mantenemos la puntuación acotada a 3 valores (1, 2 y 3) porque queremos mantener ítems chicos y de tamaño «similar». De hecho la puntuación solo la utilizamos para validar que el ítem no sea muy grande. Luego el plan lo armamos mirando la cantidad de ítems. Es así que luego de 4 iteraciones creemos que en condicionales «habituales» podemos completar unos 7 u 8 ítems por iteración.

Continuará…

Mis eventos de aquí a fin a de año

En la primera mitad de año casi no participé de académicos ni comunitarios. Sin embargo para la parte final de este 2025 ya tengo varios agendados.

De entrada la semana próxima voy a estar participando de Testear.la, evento en modalidad mixta online/presencial organizado por los amigos de Crowdar. Ahí estaré estrenando charla: «BDD: Lecciones de +10 Años en la Trinchera» (miércoles 10/9, 11:40 hs, presencial). En ese mismo contexto también estaré dando mi taller «Principios y Patrones para el diseño de Pipelines» (jueves 11/9, 11:20 hs, presencial).

Luego estaré comenzando la primera con el clásico Nerdearla @ Baires, del 23 al 27 de septiembre 2025, presencial y online. Aquí no daré charla, seré 100% expectador. Donde sí voy a dar una charla es en el Nerdearla @ Madrid, del 13 al 15 de noviembre, presencial y online. Ahí estrenaré mi charla «Patrones de Diseño: de vuelta a la bases«.

Finalmente, estaré cerrando el año en casa, Facultad de Ingeniería UBA, donde se llevará a cabo la Smalltalks 2025. No estoy seguro si presentaré alguna charla (por el momento no mandé propuesta), pero igualmente ya sé que iré de espectador.

El testing como ciudadano de primera

Sin duda Agile, y más específicamente XP, hicieron esto, pero no fueron los únicos.

En la época «pre-agile«, el testing estaba en manos de un grupo de personas «externas» al equipo de desarrollo. Agile cambio esto en varios sentidos, por un lado puso de relieve el testing como un trabajo de todos y junto con eso puso gran parte del testing en manos de los developers. Al mismo tiempo puso a los testers a trabajar codo a codo con los developers dentro del equipo de desarrollo y a la pasada cambió las tareas cotidiadas de los testers incluyéndolos en otras cuestiones como ser las plannings y los refinamientos, etc. Hasta aquí creo que no hay novedad, cualquier practicante en la actualidad sabe esto (consciente o inconscientemente).

Pero hay otro hecho que me parece ha pasado desapercibido. Resulta que estoy ayudando a un equipo de un cliente a mejorar su proceso de delivery y en ese contexto estamos agregando tests automatizados, cosa que el equipo nunca hizo. Su solución consiste en una aplicación móvil construida con Ionic y un conjunto de servicios construidos con node/loopback. Personalmente había hecho algunas cosillas con Ionic pero nunca había trabajado con Loopback. Para mi sorpresa, ambos framework traen soporte (guias, ejemplos, etc) para hacer pruebas automatizadas de distinto tipo. Más aún, el scaffolding de Ionic ya genera el esqueleto de pruebas cuando uno genera un componente. Esta sorpresa me hizo caer en la cuenta que hoy en día la gran mayoría de los frameworks de desarrollo ya traen soporte, documentación y ejemplos para hacer pruebas automatizadas. Esto que puede parecer «normal» en la actualidad pero creanme que no era así hace ~20 años cuando yo empezaba a dar mis primeros pasos con automatización de pruebas. Recuerdo varios proyectos lidiando para agregar pruebas a aplicaciones AspNet/C#.

Creo que unas de las herramientas pioneras en este sentido fue Smalltalk (¿squeak?) y luego Rails. Me parece que hoy en día todo frameworks/sdk viene con soporte para hacer pruebas automatizadas: Rails, Django, Java/Spring, NetCore, Nest.js, Next.Js, Android Sdk, por nombrar algunos populares. Es cierto que tal vez no todos los developers escriben pruebas, pero el hecho que las herramientas los habiliten representa una posición de la industria: los developers deben escribir pruebas y es de esta forma el testing se ha convertido en un ciudadano de primera categoría.

Pipelines en Testearla

El próximo mes de septiembre estaré participando en la conferencia Testearla organizada por la gente de Crowdar (JaviRe y sus colegas).

La conferencia será 9 y 10 de septiembre, el 9 online y el 10 presencial en Plaza Galicia (Ciudad de Buenos Aires). La entrada es gratuita pero requiere registración. Al margen de la agenda de sesiones, que se ve muy interesante, en el evento también habrá espacios de networking.

Adicionalmente, el 11 habrá una jornada intensiva de entrenamiento de la cual estaré participando. Habrá 4 sesiones y yo daré una de ellas. Mi sesión será «Principios y Patrones para el diseño de Pipelines», veremos la teoría y la pondremos en práctica con algunas herramientas. Será la primera vez que dicte este sesión, pues si bien parte del contenido suelo darlo en mi materia de Ingeniería de Software, para este caso agregaré algunas cuestiones nuevas surgidas de mis últimas experiencias. Esta jornada de entrenamiento tiene cupos limitados y es paga.

¡Nos vemos en Testearla!

Ingeniería de Software: de Ruby a TypeScript

Desde hace varios años en mi curso de Ingeniería de Software @ UNTreF venimos usando Ruby como lenguaje de programación. Una elección con la que estábamos muy conformes. Pero el cambio de plan de estudio del año pasado, cambió radicalmente el perfil de nuestros alumnos y ello nos llevó a replantear varias cuestiones de la forma en que dictamos la materia. Entre ellas el lenguaje de programación.

Dado el perfil de los alumnos pensamos que trabajar con un lenguaje de tipado estático podía resultar más conveniente para explicar algunas cuestiones (cuestiones que previamente no teníamos que explicar porque las estudiaban en materias anteriores). Inicialmente consideramos C# pero luego de algunas pruebas decidimos descartarlo. Finalmente la semana pasada decidimos ir con TypeScript. Yo vengo de armar un programa de entrenamiento para pasantes en uno de mis clientes y considero que TypeScript dió muy buen resultado. Mis colegas estuvieron de acuerdo así que ahí vamos.

Complementando TypeScript el stack de desarrollo que vamos usar está conformado por VScode + yarn + eslint + jest + cucumber + express (nada muy novedoso).

En un par de semanas les cuento que tal nos va.

Proyecto nuevo, código viejo

La semana pasada comencé a trabajar en un proyecto nuevo. El objetivo es hacer un «refactor» de un sistema que tiene varios años de vida y al mismo tiempo agregarle algunas capacidades nuevas basadas en IA. El sistema consta de 1 componente central construido en javascript, dos «satelites» en php y varias APIs externas algunas bajo el control de otros equipos de la misma organización y otras bajo el control de otras organizaciones.

En el equipo somos unas 10 personas: un Product Owner, cuatro devs todo terreno con dedicación full time, un dev referente técnico con dedicación parcial, un tester full-time, una persona de UX, un persona de infra con dedicación on-demand y yo con dedicación parcial en el rol de coach dev. Los miembros del equipo vienen de trabajar en distintos equipos de la organización y nunca trabajaron todos juntos como equipo.

El proyecto debería durar aproximadamente unos 3 meses.

Estamos haciendo iteraciones semanales con todas las ceremonias (review-retro-planning) de corrido los días miércoles. Estamos haciendo dailies que logramos mantener ~10 minutos.

En la primera iteración no hicimos una estimación formal, simplemente agarramos un conjunto de 17 ítems que consideramos podrían llegar a completarse en 1 semana (spoiler: a los dos días ya no dimos cuenta que llegamos a completar todo, ja!).

Continuará…

Inteligencia Artificial en la Enseñanza de la Programación: nuestro estudio formal

Hasta el momento evité escribir sobre cuestiones de Inteligencia Artificial en parte porque me pareció que había demasiada gente hablando del tema, algunos incluso hablando con muchas imprecisiones (por no decir «tirando fruta») pero también porque yo mismo no quería tirar fruta. A pesar de estar trabajando profesionalmente en iniciativas de IA desde 2023 sentí que mi conocimiento era muy superficial.

Pero ya desde un tiempo la IA comenzó a meterse en mis cursos y eso nos obligó a tomar el tema. Es por eso que a comienzos de este año junto a Diego Marcet y Gonza Cozzi (miembros de mi equipo docente en UNTreF) nos pusimos a estudiar formalmente el tema. En concreto comenzamos estudiando el uso de la IA en la enseñanza de la programación. Hicimos una revisión de papers y encuestamos a docentes de programación. Esta iniciativa quedó plasmada en un artículo que enviamos al Simposio Argentino de Educación en Informática y que estaremos presentando en Agosto en el contexto de las Jornadas Argentinas de Informática.

Algunos de los hallazgos que hicimos fueron:

  • La mayoría de los docentes (~70 %) ya utiliza herramientas basadas en IA en sus tareas docentes.
  • Al mismo tiempo (más del 70 %), la gran mayoría cree que la incorporación de IA en sus cursos requiere de un cambio significativo en la forma en que dictan sus cursos.
  • Más del 90% de los encuestados reportaron que sus alumnos ya utilizan herramientas basadas en IA

Más allá de todo lo anterior, y que en un punto era esperable, lo que más nos llamó la atención fue la diferencia de opinión cuando preguntamos si consideraban positiva o negativa la irrupción de IA en la educación, el siguiente histograma muestra la consolidación de las respuestas.

Este artículo representa el primer paso de nuestra iniciativa de estudio del uso de la IA en la enseñanza. Nuestro siguiente paso es trabajar con practicantes, con lo cual si hay algún desarrollador leyendo esto y utilizando IA (co-pilot, cursor, etc) y le interesa participar de un estudio, no deje de contactarme.

Ingeniería de Software en la UBA

La UBA es una institución muy grande, tiene 13 facultades y más de 300 mil estudiantes. Los temas de Ingeniería de Software se estudian en más de una facultad.

Al mismo tiempo se da que la Ingeniería de Software es un cuerpo de conocimiento bastante amplio y diverso, incluye cuestiones de proceso y metodología como también cuestiones de arquitectura, programación y verificación. Y en los últimos años, algunos autores, también han incluido cuestiones de despliegue y operación.

Me animo a decir que la Facultad de Ingeniería (fiuba) es la facultad de la UBA que más cuestiones de Ingeniería de Software cubre. En fiuba hay temas de Ingeniería de Software que se ven en forma transversal a lo largo de distintas materias, cuestiones de programación, verificación, versionado, etc. Al mismo tiempo hay un núcleo de 3 materias específicas de Ingeniería de Software: Ingeniería de Software 1(IS1), Ingeniería de Software 2(IS2) y Gestión del Desarrollo de Sistemas Informáticos(GDS). Finalmente hay materias electivas enfocadas en áreas específicas de la Ingeniería de Software como ser Arquitectura de Software y Estándares de Calidad y Modelos de Referencia, entre otras. En lo personal creo que esta oferta da a los estudiantes una muy buena formación de cara a su ejercicio profesional como Ingenieros de Software. Quienes gusten curiosear pueden ver los contenidos mínimos de estas tres materias en el plan de estudios.

El reciente cambio en el plan de estudio de la carrera de Ingeniería Informática generó un reordenamiento de cursos que llevó varios cuatrimestre. Finalmente, este primer cuatrimestre de 2025, las materias del área de Ingeniería de Software quedaron organizadas en 8 cursos: 3 de IS1, 3 de GDS y 2 de IS2. A continuación resumo algunos datos de cada curso que pueden resultar útiles para futuros estudiantes.

Comparto también las páginas públicas de los cursos (no todos tienen):

Una particularidad interesante es que las 3 materias del núcleo de Ingeniería de Software apuntan a cubrir (en mayor o menor medida dependiendo del curso) todo el ciclo de desarrollo de software. En cierto modo, esto queda evidenciado en que en 7 de los 8 cursos hay que programar.
Destaco este hecho porque en algunas carreras/instituciones e incluso en las versiones anteriores de los planes de fiuba, cada materia cubría solo una etapa del ciclo de desarrollo, lo cual denotaba un enfoque «secuencial» bastante distintos del ejercicio de la profesión. En el enfoque actual, más punta a punta e iterativo, se abordan las distintas etapas reiteradamente en las distintas materias pero con distinto foco y nivel de profundidad.