![\"Pipeta,](\"/assets/img/notes/pipeta-alpine-linux.webp\")
\n Estos días me encontré con una situación bastante buena: tener una Raspberry Pi Zero 2 W prendida en Buenos Aires, corriendo Alpine Linux, mientras yo estoy lejos de casa y sin necesitar nada urgente de esa máquina. En otras palabras, el contexto ideal para empezar a probar cosas sin culpa.
\nLa máquina se llama Pipeta y el nombre le queda bien, porque la idea es usarla justamente como eso: un sandbox puro para experimentar, aprender y equivocarme sin convertir cada intento en un servicio, una obligación o una nueva pieza de infraestructura para mantener.
\n\n Muchas veces uno aprende tecnología queriendo resolver algo grande demasiado rápido. Montar un servidor, exponer un subdominio, automatizar medio planeta o transformar un script en un sistema antes de tiempo. Esta vez quise hacer lo contrario.
\nLa consigna fue bastante simple: nada de producción, nada de disponibilidad y nada de dejar cosas corriendo porque sí. Solo cositas chicas, manuales, locales y lo suficientemente inofensivas como para poder jugar sin presión.
\nEmpecé por dos scripts muy simples en Python. Uno para comparar el clima entre ciudades y otro para leer titulares desde feeds RSS. No eran herramientas especialmente sofisticadas, pero justamente ahí estuvo la gracia.
\nLo interesante fue entender mejor qué hace cada capa: Python como lenguaje, requests para traer datos, feedparser para leer RSS, una API para el clima y después un poco de lógica propia para ordenar todo y mostrarlo de una forma más legible. No había ninguna magia rara detrás, solo datos, reglas simples y algo de criterio para presentarlos.
Dicho así parece bastante obvio, pero verlo funcionar en una terminal remota, en una maquinita tan chica, tuvo bastante encanto.
\nDespués vino el siguiente paso, que fue juntar esas piezas en una especie de mini laboratorio interactivo. Así apareció Pipeta Lab, un script con menú en terminal que permite comparar ciudades, leer titulares y combinar ambas cosas en una vista simple tipo observatorio.
\nTodo sigue siendo chico, manual y bastante liviano. Y eso es justamente lo que más me interesaba: no armar una app, ni un dashboard, ni una plataforma, sino un programita lo bastante vivo como para ayudarme a entender mejor cómo encajan las cosas.
\nEl salto más interesante por ahora fue sumar SQLite. No por una necesidad urgente, sino porque me pareció una buena forma de tocar una base de datos sin meter demasiada complejidad.
\nHasta ese momento, los datos aparecían en pantalla y desaparecían ahí mismo. Con SQLite apareció algo distinto: persistencia. El programa ya no solo consultaba y mostraba, sino que además podía guardar una corrida y volver a leerla después. Ahí empezó a hacerse más clara una estructura que siempre está, aunque a veces uno no la vea tanto: entrada, procesamiento, persistencia y salida.
\nDicho de otra manera, el script dejó de ser solo una consulta en vivo y empezó a parecerse un poco más a un sistema, aunque siguiera siendo un experimento muy chico.
\nCreo que lo mejor de esta pequeña aventura no fue Alpine, ni Python, ni SQLite por separado. Lo mejor fue volver a algo bastante básico y bastante sano: aprender sin la presión de publicar, automatizar o convertir todo en “infraestructura” enseguida.
\nAbrir una terminal, escribir algo, romper una indentación, pelearse con una API caprichosa, entender por qué una ciudad no aparece y guardar tres filas en una base de datos puede sonar mínimo, pero justamente en esa escala es donde se vuelve más fácil entender qué está pasando.
\nPor ahora quiero mantener a Pipeta en ese lugar: sandbox puro, laboratorio y caja de pruebas. Capaz más adelante alguna de estas cositas migra a otra máquina o termina colgada en la web, pero prefiero que eso llegue después, si tiene sentido, y no como punto de partida.
\nEstá bueno recordar que no todo proyecto tiene que nacer como infraestructura. A veces alcanza con una idea mínima, una terminal y un rato libre para aprender un poco más.
", "summary": "Estos días me encontré con una situación bastante buena: tener una Raspberry Pi Zero 2 W prendida en Buenos Aires, corriendo Alpine Linux, mientras yo estoy lejos de casa y sin necesitar nada urgente de esa máquina. En otras palabras, el contexto ideal para empezar…", "date_published": "2026-04-05T00:00:00+00:00", "tags": [ "alpine-linux", "raspberry-pi-zero-2w", "python", "sqlite", "rss", "weather", "argensonix-labs" ] }, { "id": "https://www.nico.com.ar/notes/nico-run-training-interpreted/", "url": "https://www.nico.com.ar/notes/nico-run-training-interpreted/", "title": "nico://run: una herramienta para leer mis entrenamientos", "content_html": "Después de Pacer apareció bastante rápido la siguiente necesidad. No solo quería pasarle mejores datos a ChatGPT, sino también tener un lugar mío para leer mejor lo que vengo haciendo. No estaba buscando una app de running, ni otro dashboard lleno de widgets, ni una copia casera de Strava. Lo que quería era algo más simple: poder ver la última sesión, entender cómo viene la semana, tener una idea de lo que sigue y leer todo eso con un poco más de claridad. Así nació nico://run.
\nPacer resolvió bastante bien la parte de preparar datos. Trae actividades desde Strava, las resume, arma un brief más limpio y me deja conversar mejor con ChatGPT. Pero faltaba una capa intermedia, porque una cosa es tener el dato y otra bastante distinta es verlo acomodado con criterio. Ahí fue donde empezó a tomar forma la idea de un portal personal de running: uno que no intentara registrar todo, sino ayudarme a interpretar un poco mejor lo importante.
\nnico://run es, básicamente, una capa de lectura arriba de Pacer. Se puede ver en run.nico.ar, y lo que hace es tomar el snapshot que ya preparo del lado de Pacer para convertirlo en algo más legible: la última salida como bloque principal, el próximo entrenamiento como sugerencia breve, un resumen semanal y algunos links para seguir leyendo cosas interesantes de running y bienestar. La lógica, en el fondo, es bastante sencilla: Pacer prepara, nico://run ordena y ChatGPT interpreta. Cada pieza hace una cosa distinta, y eso por ahora viene funcionando mejor que intentar meter todo en un solo lugar.
\nLa idea sigue siendo mantenerlo liviano. Está armado como build estático, trabaja con datos locales y evita complejidad innecesaria. También está pensado para servir cómodo incluso en hardware chico, que es parte importante de la gracia del proyecto. Me interesa bastante esa idea de poder mostrar algo útil sin depender de una infraestructura exagerada para resolver un problema bastante simple.
\nHoy nico://run ya me sirve para algo concreto. Me permite mirar la última sesión sin entrar a mil pantallas, ubicar rápido el contexto de la semana y tener una capa más amable entre el entrenamiento bruto y la decisión del día siguiente. No reemplaza a Garmin ni a Strava, y tampoco intenta hacerlo. Más bien se mete en ese hueco raro que queda después del reloj, pero antes del próximo entrenamiento.
\nTodavía hay margen para seguir puliéndolo. Me gustaría mejorar el archivo histórico, darle más personalidad a algunas vistas, armar una capa más prolija para el calendario de carreras y encontrar mejores formas de conectar el plan base con lo que realmente termino haciendo. Pero lo importante ya está: nico://run dejó de ser una idea linda y empezó a convertirse en una herramienta propia.
", "summary": "Después de Pacer apareció bastante rápido la siguiente necesidad. No solo quería pasarle mejores datos a ChatGPT, sino también tener un lugar mío para leer mejor lo que vengo haciendo. No estaba buscando una app de running, ni otro dashboard lleno de widgets, ni una…", "date_published": "2026-03-16T00:00:00+00:00", "tags": [ "nico-run", "pacer", "running", "astro", "raspberry-pi", "argensonix-labs" ] }, { "id": "https://www.nico.com.ar/notes/pacer-strava-brief-builder/", "url": "https://www.nico.com.ar/notes/pacer-strava-brief-builder/", "title": "Pacer: de las capturas eternas a un brief limpio para ChatGPT", "content_html": "Hoy nació Pacer, una mini app pensada para algo bastante concreto: dejar de pasarle capturas de pantalla al ChatGPT y empezar a darle contexto útil.
\nLa idea salió de una necesidad muy simple. Cuando quiero revisar cómo vengo entrenando y decidir qué hacer al día siguiente, no necesito nueve screenshots, ni una novela explicando todo, ni depender de recordar de memoria qué hice hace tres días.
\nNecesito esto:
\nY listo.
\nDurante bastante tiempo el flujo fue más artesanal que otra cosa.
\nMirar Garmin.
\nMirar Strava.
\nSacar capturas.
\nMandarlas.
\nExplicar sensaciones.
\nVolver a resumir a mano.
Funcionaba, sí. Pero tenía demasiada fricción.
\nLo interesante fue que al intentar automatizarlo aparecieron varias verdades bastante rápido:
\nPacer quedó como una herramienta simple y bastante más sensata:
\nEse texto después se lo paso a ChatGPT y el ida y vuelta queda mucho más limpio.
\nPor ahora Pacer ya resume varias cosas útiles:
\nY además tiene un bloque manual bien corto para completar:
\nEso solo ya baja muchísimo la fricción.
\nEl punto no era hacer una app “fitness” más.
\nEl punto era armar un puente entre mis datos y una conversación útil, que el sistema me ayude a responder algo concreto:
\nqué conviene hacer mañana.
\nEn ese sentido, Pacer ya cumple.
\nVarias cosas terminaron acomodándose mejor de lo esperado:
\nPulirlo sin volverlo complicado:
\nPero lo importante ya pasó.
\nPacer dejó de ser una idea y empezó a servir.
", "summary": "Hoy nació Pacer, una mini app pensada para algo bastante concreto: dejar de pasarle capturas de pantalla al ChatGPT y empezar a darle contexto útil. La idea salió de una necesidad muy simple. Cuando quiero revisar cómo vengo entrenando y decidir qué hacer al día…", "date_published": "2026-03-09T00:00:00+00:00", "tags": [ "pacer", "strava", "running", "raspberry-pi", "nodejs", "automation", "argensonix-labs" ] }, { "id": "https://www.nico.com.ar/notes/aura-production-deploy/", "url": "https://www.nico.com.ar/notes/aura-production-deploy/", "title": "Aura: una experiencia minimalista, inmersiva y atmosférica", "content_html": "Hoy salió a producción Aura, el nuevo player standalone de Blur FM, disponible en play.blurfm.com.
\nLa idea es dejar de pensar el player como “una parte medio colgada de la web” y empezar a tratarlo como una experiencia propia, más cercana a una app musical que a una página tradicional.
\nEl sitio principal de Blur FM sigue siendo la web “institucional”, por decirlo de alguna manera.
\nAura, en cambio, arranca como una experiencia enfocada 100% en escuchar.
Eso me gusta porque ordena bastante el panorama:
\nMás adelante se podrá integrar algo más liviano en la web principal, pero arrancar separado me parece muchísimo más sano.
\nAura no salió de la nada. Toma referencias visuales del repo principal de Blur FM:
\nTodo esto sin arrastrar la estructura anterior. Era importante no mezclar arquitecturas.
\nLa parte linda fue dejarlo con el mismo enfoque general que ya venía usando en Blur FM:
\nEl proyecto nació en un mockup low fi hecho en Excalidraw y pasó rápidamente a una URL real. Se transformó bastante rápido en un producto.
\nNo está terminadísimo ni cerca, pero ya tiene lo más importante: base propia, identidad clara y deploy resuelto.
\nPulir el player con calma:
\nPero lo más importante ya sucedió: Aura existe.
", "summary": "Hoy salió a producción Aura, el nuevo player standalone de Blur FM, disponible en play.blurfm.com. La idea es dejar de pensar el player como “una parte medio colgada de la web” y empezar a tratarlo como una experiencia propia, más cercana a una app musical…", "date_published": "2026-03-07T00:00:00+00:00", "tags": [ "blurfm", "astro", "github-actions", "apache", "pwa", "radio", "automation" ] }, { "id": "https://www.nico.com.ar/notes/locale-splitter/", "url": "https://www.nico.com.ar/notes/locale-splitter/", "title": "Splitter tool hosteada en Heroku en 30 min", "content_html": "En dos iteraciones (media hora como mucho) armé locale-splitter: una mini herramienta web para recortar el TXT master de traducciones y bajarlo como ZIP, ya corriendo en Heroku.
\nEl TXT trae HTML concatenado y el splitter corta cuando encuentra separadores tipo: |- (EN-PH) faq-contact-us. Sin ese formato exacto, no hay corte ni renombre.
.txt|- (LOCALE) slug(EN-US) faq-common-concerns.htmlCodex no solo generó la app (Node/Express), también la empujó a GitHub y la publicó en Heroku. Se embaló creando un repo nuevo al principio aunque yo ya tenía uno definido, pero con un redeploy apuntando al repo correcto quedó listo.
\nSumar un report.txt en caso de que hubiera warnings detectados (por ejemplo marcadores sin contenido).
Con intención de optimizar el funcionamiento de Blur FM, la idea fue: cuatro calidades desde SAM (320, 128, 64 y 32 kbps), Icecast en Argentina como base, un relay en Europa para balancear la demanda, y Cloudflare para que las URLs públicas deriven al endpoint más conveniente (AR o EU).
\nEn la práctica esto termina siendo un fanout: el Icecast “madre” publica los streams, y uno (o más) Icecast en Europa se enganchan como relay y vuelven a servir esas mismas calidades localmente.
\nLo mejor es que no solo viaja el audio: también viaja la metadata (título, artista, etc.).
\nEntonces el relay europeo termina mostrando el mismo “Now Playing” que el origen.
Esto sirve porque:\n- El web player muestra el tema actual sin inventar nada.\n- Muchas apps leen esa info directo del stream.\n- Cloudflare puede redirigir al usuario al endpoint más conveniente (AR o EU).\n- Todo queda consistente y no hace falta mantener sistemas paralelos.
\nLos streams se replican en Europa, se reparte la carga y la experiencia mejora, manteniendo todo consistente. Y encima quedan URLs públicas listas para crecer a futuro (routing más fino, stats separadas, lo que pinte) sin convertir la infra en un Frankenstein.
", "summary": "Con intención de optimizar el funcionamiento de Blur FM, la idea fue: cuatro calidades desde SAM (320, 128, 64 y 32 kbps), Icecast en Argentina como base, un relay en Europa para balancear la demanda, y Cloudflare para que las URLs públicas deriven al endpoint…", "date_published": "2026-02-28T00:00:00+00:00", "tags": [ "blurfm", "icecast", "streaming", "infra" ] }, { "id": "https://www.nico.com.ar/notes/bienvenidos-a-nico-log/", "url": "https://www.nico.com.ar/notes/bienvenidos-a-nico-log/", "title": "Bienvenidos a nico://log", "content_html": "El sitio de Slackware es conocido en el mundo Linux por correr en un Pentium III, 600 MHz, con 512 megabytes de RAM.
\nDespués de unas cuantas iteraciones con GitHub Copilot y Codex, esta es la primera prueba para publicar una nota liviana.
", "summary": "El sitio de Slackware es conocido en el mundo Linux por correr en un Pentium III, 600 MHz, con 512 megabytes de RAM. Después de unas cuantas iteraciones con GitHub Copilot y Codex, esta es la primera prueba para publicar una nota liviana.", "date_published": "2026-02-26T23:36:00-03:00", "tags": [ "infra", "low tech" ] } ] }