Saltar al contenido
Franco Treboux
GitHub

Franco Treboux

Productos comerciales

Productos entregados a clientes. El código fuente es privado; podés consultar capturas seleccionadas.

Proyecto privado

SaasComercio

Sistema de gestión comercial para comercios minoristas, diseñado para centralizar productos, ventas, stock y operaciones diarias en una sola herramienta.

  • Electron
  • React
  • TypeScript
  • Supabase
  • PostgreSQL
  • Producto comercial vendido y entregado a un negocio en funcionamiento
  • Flujos de venta de mostrador y mesa con control de stock
  • Panel operativo para administrar productos, clientes y proveedores

Proyectos

Fezlink

Plataforma SaaS para creadores que convierte una biolink tradicional en una herramienta de análisis y optimización de conversión, construida sobre una arquitectura distribuida orientada a eventos.

  • Next.js
  • TypeScript
  • React
  • Node.js
  • Rust
  • RabbitMQ
  • MongoDB
  • Cloudflare Edge
  • Vercel
  • Railway
Ver
  • Arquitectura event-driven con procesamiento asincrónico mediante colas y workers en Rust
  • Pipeline de ingestión de eventos con batching en memoria y bulk writes en base de datos
  • Frontend público optimizado para SEO y performance en el edge

Problema

Una plataforma de biolink necesitaba convertir las interacciones públicas en señales útiles para analizar y optimizar la conversión.

Contexto y restricciones

El producto separa el frontend público, el dashboard y la API, y necesita procesar eventos sin acoplar la experiencia pública al trabajo de fondo.

Arquitectura

La solución combina un frontend público con Next.js en el edge, una API en Node.js y procesamiento asincrónico mediante RabbitMQ y workers en Rust. MongoDB recibe escrituras en bulk después de agrupar eventos en memoria; los despliegues usan Vercel y Railway.

Decisiones clave de ingeniería

  • Separar frontend público, dashboard y API para mantener responsabilidades claras.
  • Usar colas y workers para desacoplar la ingestión de eventos del procesamiento asincrónico.
  • Agrupar eventos en memoria y usar bulk writes para reducir operaciones individuales sobre la base de datos.

Desafíos

  • Coordinar el recorrido de eventos entre componentes con responsabilidades y tiempos de procesamiento distintos.

Enfoque de desarrollo

El desarrollo se enfocó en dividir el sistema por responsabilidades y en diseñar un pipeline explícito desde la ingestión hasta la persistencia.

Tecnologías

  • Next.js
  • TypeScript
  • Node.js
  • Rust workers
  • RabbitMQ
  • MongoDB
  • Cloudflare Edge
  • Vercel
  • Railway

FezTime

SaaS para gestión de turnos orientado a pequeños y medianos comercios, con foco en automatización operativa y reducción de fricción en reservas.

  • Next.js
  • TypeScript
  • React
  • Tailwind
  • Node.js
  • MongoDB
  • Sistema de reservas con gestión de disponibilidad en tiempo real
  • Panel administrativo para control de agenda y clientes
  • Arquitectura preparada para multi-tenant

FormulaWheelBridge

Convierte los controles de un volante casero en un gamepad inalámbrico para Windows.

  • C#
  • .NET 8
  • WinForms
  • ESP32-S3
  • Arduino/C++
  • Wi-Fi/UDP
  • vJoy
Repositorio

FormulaWheelBridge: Caso de estudio

Problema

Los controles físicos de un volante casero necesitaban convertirse en entradas reconocibles por juegos de Windows.

Contexto y restricciones

Como proyecto técnico personal, integra hardware real con software de escritorio y mantiene el repositorio público junto con una captura del panel de control.

Arquitectura

El ESP32-S3 lee los controles mediante Arduino/C++, envía los datos por Wi-Fi usando UDP y una aplicación C#/.NET 8 los recibe para exponerlos a Windows a través de vJoy.

Decisiones clave de ingeniería

  • Usar Wi-Fi/UDP como enlace entre el microcontrolador y la aplicación de escritorio.
  • Mantener separadas la lectura del hardware, el transporte de datos y la emulación del gamepad mediante vJoy.

Desafíos

  • Traducir señales de controles físicos a un formato que una aplicación de Windows y los juegos puedan consumir como gamepad.

Enfoque de desarrollo

El desarrollo conectó firmware Arduino/C++, transporte UDP y una interfaz WinForms en C#/.NET 8 alrededor de un dispositivo físico.

Validación y pruebas

La validación se realizó con hardware real y con la visualización de entradas y conexión vJoy disponible en la captura del proyecto.

Resultado

El proyecto ofrece un puente funcional entre controles de volante DIY y un gamepad inalámbrico para Windows, con repositorio público.

Tecnologías

  • C#
  • .NET 8
  • ESP32
  • Arduino/C++
  • Wi-Fi
  • UDP
  • vJoy

AC3Bridge

Lleva sonido envolvente 5.1 por salida óptica en Windows, codificando a AC-3 en tiempo real para equipos que no traen esa función por hardware.

  • C++
  • Windows Driver Kit
  • KMDF/ACX
  • WASAPI
  • FFmpeg
  • Win32
  • CMake
Repositorio
  • Driver de kernel en KMDF/ACX que expone un dispositivo virtual de 5.1 a Windows
  • Captura de la mezcla en user mode con WASAPI loopback y codificación AC-3 en tiempo real
  • Entrega como bitstream IEC 61937 al dispositivo digital en modo exclusivo

AC3Bridge: Caso de estudio

Problema

El S/PDIF óptico transporta solo dos canales de PCM, así que enviar 5.1 requiere comprimir el audio a AC-3. Windows no lo hace por software, y las placas que lo resuelven por hardware son minoría: en el resto, cualquier programa que reproduzca 5.1 termina mezclado a estéreo al elegir la salida digital.

Contexto y restricciones

El proyecto cubre desde un driver de modo kernel hasta una aplicación de escritorio, sobre hardware de audio real y una salida digital conectada a un receiver.

Arquitectura

Un driver KMDF/ACX expone un endpoint de reproducción 5.1 que Windows materializa como un dispositivo más; el driver descarta las muestras y existe únicamente para que ese endpoint sea real, ya que no puede crearse desde una aplicación. La mezcla se captura después en user mode con WASAPI loopback, se aplica ganancia por canal, se codifica a AC-3 con FFmpeg, se enmarca como IEC 61937 y se entrega al dispositivo digital en modo exclusivo.

Decisiones clave de ingeniería

  • Mantener el driver como un sumidero sin procesamiento y capturar el audio en user mode, dejando la lógica de riesgo fuera del kernel.
  • Elegir el dispositivo de salida sondeando cuáles aceptan un portador IEC 61937 AC-3, en lugar de confiar en el orden de enumeración.
  • Registrar cada estado del ciclo de vida del driver en el registro de Windows, porque la salida de depuración del kernel no es utilizable en ejecuciones desatendidas.

Desafíos

  • El endpoint se enumeraba correctamente pero no podía abrirse en modo compartido hasta implementar el stream de tiempo real y declarar el soporte de notificaciones de buffer.
  • Sostener un reloj de presentación estable en el driver sin bloquear el camino de tiempo real.

Enfoque de desarrollo

El desarrollo separó el driver, el motor de puente reutilizable y la interfaz, de modo que la aplicación de escritorio y la versión de línea de comandos comparten un único motor.

Validación y pruebas

El repositorio incluye pruebas unitarias y cuatro compuertas de verificación en tiempo de ejecución contra el driver instalado: estado del dispositivo, contrato del endpoint, reproducción real de seis canales y captura por loopback comparando la energía por canal contra amplitudes conocidas. También hay una prueba de remoción del dispositivo durante la reproducción. No se publican mediciones de latencia extremo a extremo.

Resultado

El resultado es una cadena funcional entre software que reproduce 5.1 y un receiver conectado por óptico, publicada como código abierto. El driver está firmado con un certificado de prueba, por lo que requiere el modo de prueba de Windows.

Tecnologías

  • C++
  • Windows Driver Kit
  • KMDF
  • ACX
  • WASAPI
  • FFmpeg
  • IEC 61937
  • Win32
  • CMake