Soy estudiante de Ingeniería Informática en la Universidad de Buenos Aires (UBA), tengo 24 años y actualmente me quedan 5 materias y el trabajo profesional para terminar la carrera.
Destacó como proyecto principal un juego multijugador que se desarrolló de forma colaborativa como parte de un trabajo universitario, el cual consiste en una remake del Worms 2D.
El proyecto fue desarrollado en C++, tiene una simulación física usando el framework Box2D y la interfaz se creó usando las librerías de QT y SDL2pp. Como metodología de trabajo utilizamos Scrum. Se utiliza programación concurrente orientada a objetos y sockets TCP/IPv4 bloqueantes como protocolo de comunicación.
El proyecto tiene su propia página web donde se puede encontrar más información acerca del proyecto, acceder a su repositorio de GitHub y ver un tráiler del mismo.
Por ultimo, antes de comenzar el desarrollo de este proyecto se realizaron dos pruebas de concepto individuales. Una primer prueba de concepto sobre Sockets y una segunda prueba de concepto sobre Threads.
Destacó como proyecto la resolucion de una problematica de negocio real mediante la implementación de una solución basada en software. A diferencia de otros proyectos académicos, no existía un enunciado ni una lista de funcionalidades predefinidas. Tuvimos un "cliente" cuyo rol fue ocupado por uno de los miembros del equipo docente con un problema de negocio. A partir de esto, nosotros tuvimos que relevar el problema y plantear un proyecto para solucionarlo. Es decir, nosotros tuvimos que identificar las funcionalidades, darles forma de User Stories, validarlas con el cliente, diseñar, codear, testear e implementar.
La problemática de negocio consistía en la automatización de los turnos médicos en un hospital. Nuestra solución fue desarrollar un sistema compuesto por dos elementos principales: una API REST, responsable de la gestión de usuarios, médicos y turnos, y un BOT de Telegram, que funcionó como interfaz directa para los pacientes. De este modo, los pacientes podían solicitar, cancelar y consultar turnos médicos de manera sencilla, mientras que la API garantizaba la correcta administración de la información.
Más detalles acerca del proyecto
Utilizamos la técnica de User Story Mapping para relevar las funcionalidades.
El proyecto se desarrolló en el transcurso de tres semanas, trabajando con iteraciones semanales bajo el estilo de Extreme Programming (XP). Esto implicó planificar tanto a alto nivel, mediante un release plan inicial, como semana a semana, dando visibilidad en un esquema de entrega continua y al final de la semana revisar lo realizado tanto a nivel producto como a nivel proceso.
El flujo de trabajo fue el siguiente: primero relevamos las funcionalidades y presentamos un release plan a nuestro Product Owner (PO), quien definió cuál sería el MVP. A partir de allí, en cada iteración (con excepción de la primera, que tuvo solo Planning), los jueves realizábamos Review, Planning y Retrospective, y durante la semana trabajábamos en un esquema de entrega continua. Esto significaba que cada funcionalidad (User Story) debía estar validada en producción antes de llegar a la Review, para lo cual definimos un proceso claro: Al comienzo de cada iteracion le comunicabamos a nuestro PO el alcance de la iteracion (es decir, que US entraban en la iteracion donde cada US tenia su estimacion relativa). Antes de comenzar con el desarrollo de cada User Story debíamos enviar al PO los Gherkin correspondientes, que él validaba y autorizaba. Una vez que la funcionalidad estaba completa, se desplegaba en el ambiente de test para que el PO pudiera testearla y, tras su aprobación, se realizaba el deploy a producción. De esta manera, siempre llegábamos a la Review con todas las funcionalidades ya disponibles en producción y validadas por el cliente.
En cuanto a las metodologías aplicadas, trabajamos con BDD y TDD. La forma de trabajo se basó en integración continua, desarrollo en un único branch con trunk-based development, pair y mob programming, y un esquema de entrega continua. La colaboración y el versionado del código se gestionaron en GitLab, lo que nos permitió organizar el trabajo de manera centralizada y garantizar la integración continua. También gestionamos el despliegue en dos ambientes cloud diferenciados: uno de prueba y otro de producción.
En cuanto a diseño e implementación, aplicamos arquitectura hexagonal para desacoplar las capas de dominio de las de infraestructura, el patrón Repository para manejar el acceso a datos y los principios de 12-Factor App.
La implementación técnica se realizó íntegramente en Ruby, tanto para la API REST como para el BOT de Telegram. La API fue desarrollada con Sinatra como microframework web, apoyándose en la gema Faraday para realizar solicitudes HTTP, y utilizando Sequel como ORM para la interacción con la base de datos. Como base de datos relacional utilizamos PostgreSQL. En cuanto a herramientas de desarrollo, empleamos Cucumber y Gherkin para las pruebas de aceptación, RSpec para las pruebas unitarias, SimpleCov para medir la cobertura del código, Rubocop para análisis estático y estilo, y Rake para la automatización de tareas comunes.
En el aspecto de infraestructura, el proyecto utilizó Neon como proveedor de base de datos, Sumologic para la gestión de logs y Kubernetes para el despliegue en la nube.
La arquitectura general del proyecto puede consultarse aquí.
En relación con las funcionalidades, identificamos y desarrollamos una serie de User Stories que abarcaban tanto las necesidades del hospital como las de los pacientes.
| ID | Descripción |
|---|---|
| US19 | Como hospital quiero dar de alta una especialidad |
| US18 | Como hospital quiero dar de alta a un médico |
| US7 | Como hospital quiero consultar los turnos que tiene un paciente |
| US3 | Como paciente quiero poder reservar un turno en un horario disponible |
| US17 | Como paciente quiero poder registrarme utilizando mi email |
| US30 | Como hospital quiero consultar los turnos que tiene un médico |
| US6 | Como paciente quiero ver mi historial de turnos |
| US14 | Como hospital quiero que el sistema respete feriados |
| US5 | Como paciente quiero ver mis próximos turnos |
| US26 | Como hospital quiero modificar el estado de un turno |
| US31 | Como paciente no puedo seleccionar más de 1 turno en un mismo listado |
| US2 | Como paciente quiero poder reservar un turno por especialidad |
| US22 | Como hospital quiero dar de baja un paciente |
| US20 | Como hospital quiero dar de baja a un médico |
| US15 | Como hospital quiero evitar superposición de turnos |
| US11 | Como hospital quiero penalizar acceso a turnos según historial de asistencia |
| US12 | Como hospital quiero que los turnos solo sean visibles a personal autorizado |
| US16 | Como hospital quiero restringir cantidad de turnos por especialidad |
| US24 | Como hospital quiero modificar una especialidad |
| US4 | Como paciente quiero cancelar un turno reservado |
| US21 | Como hospital quiero dar de baja una especialidad |
Cada una de estas funcionalidades fue pensada, validada, desarrollada y puesta en producción siguiendo el esquema de trabajo descrito anteriormente.
Se puede acceder a sus dos repositorios de GitHub. Por un lado tenemos el repositorio de la API y por otro el repositorio del BOT de Telegram
Mencionamos que los repositorios del proyecto fueron copiados en GitHub para su difusion, pero el desarrollo estuvo originalmente en GitLab.
Destacó como proyecto la implementación de un compilador de Lox en Rust teniendo como referencia la segunda parte del libro Crafting Interpreters de Robert Nystrom.
¿Que es Lox?. Es un lenguaje de programación creado por Robert Nystrom para el libro. Es un lenguaje específicamente diseñado para enseñar cómo construir intérpretes y máquinas virtuales. Lox es un lenguaje dinamico, tipado dinamicamente de alto nivel con sintaxis parecida a JavaScript.
A diferencia del libro (donde se implementa en C y con un compilador de una sola pasada) se implemento en Rust y con una separación de las fases de parseo y compilacion.
El compilador tiene su repositorio de GitHub y también se puede acceder a las slides que fueron usadas para su presentación.
Adicionalmente, pude contribuir en mejoras a Plox agregando el operador ++ en los PR #5 y #9. Plox es un interprete de Lox en Python utilizado en las clases y esta basado en la primera parte del libro Crafting Interpreters de Robert Nystrom
Destacó como proyecto la implementación de un File Transfer que se desarrolló de forma colaborativa como parte de un trabajo universitario para la materia Redes, teniendo como objetivo la comprensión y la puesta en práctica de los conceptos y herramientas necesarias para la implementación de un protocolo RDT.
En este proyecto se desarrollo una aplicación de arquitectura cliente-servidor que implementa la funcionalidad de transferencia de archivos mediante las operaciones upload (Transferencia de un archivo del cliente hacia el servidor) y download (Transferencia de un archivo del servidor hacia el cliente). La aplicacion fue desarrollada en Python utilizando la libreria estandar de sockets, donde la comunicacion entre procesos fue implementada utilizando UDP como protoclo de capa de transporte. Además, para lograr una transferencia confiable al utilizar el protocolo UDP, se implemento una versión utilizando el protocolo Stop & Wait y otra versión utilizando el protocolo Go-Back-N. Por último, el servidor es capaz de procesar de manera concurrente la transferencia de archivos con múltiples clientes.
Se puede acceder a su repositorio de GitHub, donde se encuentra la implementacion de la aplicacion, el enunciado con mas detalles y el informe del mismo.
Destacó como proyecto un modelo de Machine Learning sobre la predicción de si un hongo es comestible o no. El objetivo es explicar y predecir la variable class, que vale p, si el hongo es venenoso (poisonous), o e, si el hongo es comestible (edible).
El proyecto se divide en 4 partes. La primer parte es un Analisis Exploratorio de los datos, la segunda parte es un modelo de Machine Learning Baseline, la tercer parte es un clasificador basado en Random Forest y por ultimo un modelo de Machine Learning que no se haya utilizado anteriormente, con busqueda de hiper-parametros.
Se puede acceder a su repositorio de GitHub, donde se encuentra la implementacion de estos modelos, el enunciado con mas detalles y el dataset del mismo.
Destacó como proyecto la implementación de un Ahorcado que se desarrolló de forma colaborativa como parte de un trabajo universitario para la materia Ingenieria de Software I, teniendo como objetivo la comprensión y la puesta en práctica de los conceptos y herramientas vistas en la materia.
La aplicacion fue desarrollada en Python, utilizando como metodologia de trabajo Scrum. Se tuvieron reuniones semanales, donde se aplico el concepto de Daily y Retrospectiva. Además, se crearon issues por semana para cada integrante del equipo, las cuales estaban estimadas mediante Story Points para definir la prioridad y el tamaño de estas. Por otro lado, se hicieron prototipos para trasmitirle la idea del diseño al cliente.
Se puede acceder a su repositorio de GitHub, donde se encuentra la implementacion de la aplicacion.
Destacó la realización de trabajos prácticos correspondientes a la materia Teoría de Algoritmos, donde se estudiaron los siguientes temas:
| 1 | División y Conquista avanzada |
| 2 | Algoritmos Greedy |
| 3 | Programación Dinámica |
| 4 | Backtracking |
| 5 | Programación Lineal |
| 6 | Redes de Flujo |
| 7 | Reducción de problemas |
| 8 | Clases de Complejidad |
Se realizaron 3 trabajos prácticos grupales que evaluaron el desarrollo y análisis de los distintos algoritmos.
Se puede acceder a su repositorio de GitHub, donde se encuentra el desarrollo y análisis de cada algoritmo.
También se puede acceder a otro repositorio de GitHub, donde se encuentran los ejercicios que realice para el estudio y práctica de la materia.
Desarrollo de los trabajos prácticos y tipos de datos abstractos de la materia
Algoritmos y Programación II.
Implementado íntegramente en C, con fuerte énfasis en memoria dinámica, complejidad y diseño de TDAs.
| 1 | Punteros y memoria dinámica |
| 2 | Complejidad algorítmica y recursividad |
| 3 | Tipos de datos abstractos (Pila, Cola, Lista) |
| 4 | Algoritmos de ordenamiento |
| 5 | Hashing y diccionarios |
| 6 | Árboles binarios de búsqueda |
| 7 | Heaps y colas de prioridad |
| 8 | Grafos (BFS, DFS, componentes conexas) |
| 9 | Algoritmos sobre grafos (Dijkstra, Prim, Kruskal, Backtracking) |
| Trabajos practicos / Tipos de datos abstractos | Descripción |
|---|---|
| Pila | Implementación de una pila dinámica (LIFO) basada en arreglo redimensionable. |
| Cola enlazada | Implementación de una cola (FIFO) mediante lista simplemente enlazada. |
| TP1: fixcol | Utilidad de línea de comandos para procesamiento de archivos sin cargar el archivo completo en memoria. |
| Lista enlazada | Implementación de lista simplemente enlazada con iterador externo e interno. |
| Hash | Tabla de hash con direccionamiento abierto, exploración lineal y redimensionamiento dinámico. |
| ABB | Árbol binario de búsqueda con iteradores in-order y manejo de borrado en los tres casos. |
| Heap | Heap binario máximo con heapify y heap_sort. |
| TP2: AlgoGram | Red social de consola con sistema de login, publicaciones, feed personalizado y likes utilizando TDAs propios. |
| TP3: NetStats | Modelado de Wikipedia como grafo dirigido con implementación de TDA Grafo y algoritmos sobre grafos. |
Se puede acceder a su repositorio de GitHub, donde se encuentra el codigo de cada trabajo practico y TDA implementado.
Este proyecto implementa en Rust una herramienta concurrente para procesar grandes volúmenes de datos extraídos de partidas del videojuego PUBG. El objetivo principal es aplicar el modelo de concurrencia Fork‑Join, un patrón de paralelización donde las tareas se dividen en subtareas independientes que se ejecutan en paralelo y luego se fusionan para producir el resultado final.
La aplicación toma como entrada un directorio con múltiples archivos .csv correspondientes a registros de muertes en partidas, y, utilizando una cantidad configurable de threads, procesa cada línea de forma concurrente. Cada línea representa un evento de muerte de jugador, y el código extrae información clave como el arma usada (killed_by) y el nombre del jugador que realizó la acción (killer_name).
El resultado final se serializa en un formato JSON bien definido, que incluye las métricas solicitadas como top de jugadores y top de armas, con porcentajes y promedios calculados según las reglas del trabajo práctico.
Se puede acceder a su repositorio de GitHub.
Proyecto grupal en Rust simulando un sistema de transporte compartido, implementando concurrencia para procesar múltiples solicitudes de viajes simultáneamente.
El sistema está diseñado para representar un conjunto de entidades conectadas por red: pasajeros que solicitan viajes desde una ubicación de origen hasta un destino, conductores que reciben y aceptan o rechazan ofertas de viaje basándose en su proximidad, y un módulo de pago (gateway) que autoriza y registra transacciones de forma concurrente.
La arquitectura del proyecto contempla servidores réplicas y un servidor líder, que actúan como intermediarios para coordinar y compartir información entre los pasajeros y los conductores. Las réplicas se comunican entre sí para garantizar resiliencia ante fallas y disponibles de red, utilizando protocolos y algoritmos de elección de líder para mantener continuidad de servicio si el servidor principal cae.
Cada componente del sistema está implementado siguiendo un modelo de actores concurrentes y comunicación por sockets TCP/UDP. El servidor actúa como intermediario y gestor de estado global, informando sobre conductores disponibles y distribuyendo actualizaciones de red. Pasajeros y conductores se conectan al servidor para iniciar sesión, obtener listados de oferta/demanda y coordinar viajes de manera distribuida. La comunicación entre réplicas y la detección de fallas (por ejemplo, elección de nuevo líder) usa mecanismos como mensajes de Ping/Pong y algoritmos de consenso tipo ring.
Se puede acceder a su repositorio de GitHub.
Implementación de un intérprete del lenguaje Monkey en Go, basado en el libro Writing an Interpreter in Go de Thorsten Ball. El objetivo es profundizar en la comprensión de cómo funcionan los lenguajes de programación, los intérpretes y la evaluación de expresiones teniendo en cuenta que ya participe en la implementación de un compilador.
Se puede acceder a su repositorio de GitHub.
Aplicación web desarrollada en Python utilizando FastAPI como framework principal, basada en el libro Building Python Web APIs with FastAPI. El proyecto consiste en una aplicación tipo planner donde usuarios registrados pueden crear, actualizar y eliminar eventos.
Se puede acceder a su repositorio de GitHub.
Se trata de una prueba de concepto (PoC) que tiene como objetivo explorar cómo integrar un modelo de Machine Learning dentro de una API.
Actualmente el proyecto está compuesto por un backend en Python y FastAPI, desplegado en Render, y un frontend desarrollado con Vite y React, desplegado en Vercel.
En el estado actual, el sistema expone únicamente el endpoint /version, el cual consulta la versión del backend y la muestra junto con la versión del frontend, validando así la correcta integración entre el backend y el frontend.
El objetivo a futuro es incorporar progresivamente un modelo de clasificación de emociones sobre tweets.
