Alejandro Velásquez Molina

Last night I was in a room full of people who bet on LatAm talent before it was obvious. The event was a GTM remote talent meetup in Medellín, organized by the CloudTask team. Two people I have admired from a distance for a while were there in person: Amir Reiter, CloudTask's founder, and Dave Menjura, who is probably my single biggest professional reference right now, not just for LinkedIn content, but for what he has built at the intersection of sales, data, and RevOps. Met Sebastian Gomez, a sharp professional who works in the oil and energy industry. And the conversation kept circling back to the same place: AI fluency is no longer optional for anyone in revenue. Not for SDRs. Not for BDRs. Not for AEs. If you are in GTM and you are not deepening your understanding of multichannel sequencing tools and how they connect to pipeline data, you are already behind. I left with one clear conviction: the path I am on, mixing BD, full-cycle sales, RevOps, and GTM tooling, is not a detour. It is the actual job now. Events like this do not just build your network. They recalibrate your sense of direction. Thanks to the CloudTask team for putting it together! #GTM #NearshoreLatam #RevOps #SalesEnablement #Medellin

14

8 Comments

Node.js vs. C# (.NET): ¿Por qué la diferencia de rendimiento va más allá de la sintaxis? ⚡ Es común escuchar que Node.js es "suficientemente rápido" para la mayoría de los desarrollos, y en escenarios I/O intensivos simples, lo es. Sin embargo, cuando analizamos rendimiento a escala, consumo de memoria y computación intensiva, C# sobre el runtime de .NET aventaja significativamente a Node.js. ¿A qué se debe esta diferencia técnica? 1️⃣ Modelo de ejecución (Single-threaded vs. Multi-threaded verdadero): Node.js ejecuta JavaScript en un solo hilo principal mediante el Event Loop (V8 engine). Aunque es excelente para manejar concurrencia no bloqueante, si una tarea requiere procesamiento intensivo de CPU (como procesamiento de imágenes, cifrado o algoritmos complejos), bloquea el hilo principal. C# maneja multithreading nativo a nivel de sistema operativo, permitiendo aprovechar todos los núcleos del procesador en paralelo. 2️⃣ Tipado estático vs. Dinámico (JIT Compilation): C# es un lenguaje fuertemente tipado que se compila a Código Intermedio (IL) y luego a código máquina optimizado mediante el compilador JIT (o AOT en .NET moderno). V8 en Node.js debe inferir tipos dinámicamente en tiempo de ejecución, lo que añade overhead en la gestión de memoria y CPU. 3️⃣ Gestión de memoria y Recolector de Basura (GC): El GC de .NET está altamente optimizado para entornos de servidor de alta carga, dividiendo la memoria en generaciones y minimizando las pausas (Stop-The-World). En Node.js, grandes volúmenes de objetos en memoria pueden disparar latencias inesperadas cuando el recolector de basura entra en acción. 4️⃣ Soporte nativo para tipos por valor (structs y Span<T>): En .NET podés manipular fragmentos de memoria contigua de forma segura y sin asignaciones en el Heap gracias a características como Span<T> y Memory<T>. En Node.js, casi todo es un objeto que reside en el Heap, incrementando la presión sobre la memoria. ¿Significa esto que Node.js no sirve? En absoluto. Node.js destaca por su velocidad de prototipado, un ecosistema masivo (NPM) y su simplicidad para desarrollar BFFs (Backend for Frontend). Sin embargo, para motores de cálculo, sistemas de telemetría masiva, procesadores de eventos en tiempo real o arquitecturas donde cada milisegundo de latencia cuenta, .NET demuestra por qué es una de las plataformas backend más eficientes del mercado moderno.

3

When I first began sharing my work on code complexity and developing complexipy, the goal was simply to make Python code easier for teams to maintain and understand. Now, I am incredibly glad to bring these ideas to a broader stage. I will be joining the speaker lineup at PyCon Colombia 2026 to present "Understanding Cognitive Complexity in Python." Thank you to the organizers for making this space possible. See you all there.

19

Tip de Java #50: Streaming de archivos para ahorrar RAM. 📂 streaming // ❌ Problema: Leer un archivo en un byte[] para enviarlo en el ResponseEntity. // Si el archivo pesa 500MB, el servidor reservará 500MB de RAM por cada descarga activa. // ✅ Solución: Escribir directamente en el OutputStream del cliente. @GetMapping("/documentos/{id}/descargar") public ResponseEntity<StreamingResponseBody> descargarDocumento(@PathVariable Long id) { Documento doc = repository.findById(id).orElseThrow(); File file = new File(doc.getRutaAlmacenamiento()); StreamingResponseBody responseBody = outputStream -> { try (InputStream inputStream = new FileInputStream(file)) { byte[] buffer = new byte[8192]; // Buffer de 8KB int bytesRead; while ((bytesRead = inputStream.read(buffer)) != -1) { outputStream.write(buffer, 0, bytesRead); } } }; return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=\"" + doc.getNombre() + "\"") .contentType(MediaType.APPLICATION_OCTET_STREAM) .body(responseBody); } /* 💡 ¿Por qué es una mejor opción? 1. Consumo mínimo de RAM: El servidor solo usa unos pocos KB (el tamaño del buffer) sin importar si el archivo pesa 1MB o 10GB. 2. Escalabilidad: Tu backend puede atender a cientos de usuarios descargando archivos simultáneamente sin riesgo de OutOfMemoryError. 3. Experiencia de usuario: El navegador del cliente empieza a recibir datos de inmediato, mejorando la percepción de velocidad. */ Buena práctica: Siempre define el 'Content-Length' si conoces el tamaño del archivo de antemano. Esto permitirá que la barra de progreso de Angular (que vimos ayer) funcione perfectamente, ya que el navegador sabrá exactamente cuánto falta por descargar. #Java #SpringBoot #Backend #Performance #CleanCode #SoftwareArchitecture #JavaDeveloper #TechTips #Programming #FullStack #Optimization #FileStreaming

2

Tengo un objetivo claro para los próximos 12 meses. No es un framework nuevo ni una certificación. Es comprar una casa en Medellín. Lo digo en público porque nombrar las metas las hace reales. Ese objetivo no existía hace 3 años, no era alcanzable desde donde estaba parado. Hoy sí lo es. No lo cuento como un flex. Lo cuento como evidencia de que el trabajo constante mueve cosas que parecían fijas. La casa no es el logro. Es la señal de que el camino que elegí tiene consecuencias reales para mí y para las personas que quiero. Hay engineers en Latinoamérica que subestiman lo que es posible construir desde acá. ¿Cuál es el objetivo más concreto que tienes para los próximos 12 meses?

29

2 Comments

Q1 Update — Nuevas librerías, cambios y próximos pasos A medida que estamos cerrando el primer Q1 del año, aproveché para hacer una actualización de mi perfil profesional y compartir algunos proyectos open source en los que estuve trabajando recientemente. Durante estas últimas semanas estuve lanzando algunas librerías públicas pensadas para desarrolladores que buscan construir productos más rápido dentro de nuevos ecosistemas. - ArkaCDN Un kit de desarrollo (SDK) que permite utilizar las capacidades de Arkiv (https://arkiv.network/) como una capa de distribución de contenido. La idea es simplificar la interacción con su infraestructura descentralizada desde aplicaciones y servicios. NPM: https://lnkd.in/d6wGuAbA - ASide Una librería pensada para facilitar la construcción de plataformas sociales y sistemas de interacción, permitiendo implementar rápidamente operaciones clásicas de un CRUD para redes sociales, perfiles, eventos, feed de contenido, QR y más de 70 features adicionales. Además, ASide está construido sobre ArkaCDN, aprovechando esta capa para manejar y distribuir contenido dentro del ecosistema. NPM: https://lnkd.in/d2-kpFMY Algo que me sorprendió bastante: Estas librerías superaron las 1000 descargas en solo 3 días, incluso considerando que el ecosistema de Arkiv todavía está en una etapa temprana de crecimiento. Es una señal muy positiva para todos los builders del mundo tech que están explorando nuevas infraestructuras. - Cambio importante: Decidí dar de baja MacroClickJS por lo que no podra ser accesible desde npm, la librería que muchos utilizaron para integrar la pasarela de pagos de Banco Macro y alcanzó más de 15.000 descargas en su primer semana. A partir de ahora evolucionará hacia un nuevo proyecto llamado BancaSDK, con la idea de convertirse en un wrapper unificado para integraciones financieras dentro de distintos servicios del ecosistema. Al mismo tiempo, sería muy interesante que en el futuro MacroClickJS pueda evolucionar como una librería independiente dentro del ecosistema de Banco Macro, permitiendo que más desarrolladores y empresas puedan integrarse fácilmente y ampliar la cartera de clientes que utilizan estas soluciones. También quiero agradecer especialmente al equipo de GitBook por su amabilidad al brindarme acceso a su plan de comunidad, lo que me permite publicar documentación técnica abierta para todos los desarrolladores que quieran explorar estas herramientas. Durante esta semana voy a estar publicando nuevas actualizaciones de estas librerías, mejorando su arquitectura y ampliando sus capacidades. Si te interesa el proyecto o querés explorarlas, te invito a pegarles una mirada rápida y dejar feedback. Siempre es bueno ver cómo la comunidad experimenta, construye y empuja nuevos estándares.

5