![\"Pipeta,](\"/assets/img/notes/pipeta-alpine-linux-20260407.webp\")
\n Hoy Blur FM cumple quince años.
\nEl 24 de julio de 2011 arrancó a sonar una radio por internet que, contra todo pronóstico, todavía sigue prendida. Cambiaron las computadoras, los servidores, los reproductores, el diseño. Cambió casi todo, menos la idea de fondo.
\nAntes de Blur FM estuvo Radio deUNA!, en 2009. Esa nació nomás de las ganas de tener una radio propia: internet me dejaba armar una señal, programar música y transmitirla, y con eso me alcanzaba. Todavía no tenía muy claro para qué la quería. Era una radio porque podía hacer una radio.
\nCon Blur FM apareció lo que faltaba: un propósito. Dejó de ser \"mantener algo al aire\" y pasó a ser un espacio para descubrir música. Sin publicidad, armada con artistas independientes y canciones que encontraba por ahí, cosas que difícilmente iban a sonar en una radio tradicional. Indie, ambient, electrónica, pop, temas tranquilos y otros medio raros de clasificar. Música para laburar, viajar, bajar un cambio.
\nNo era solo juntar temas que me gustaban. Había una intención en el orden, en la selección, en el clima general. Esa curaduría terminó siendo el corazón del proyecto: que alguien entre, apriete play, y se cruce con algo que no estaba buscando.
\nBlur FM nunca fue gran cosa como medio ni tuvo plata detrás. Fue siempre chica, independiente, bastante artesanal. Pero fue también mi laboratorio: ahí aprendí a administrar servidores, emitir audio, diseñar interfaces, sostener una identidad a lo largo de distintas épocas. Y aprendí algo más importante: mantener un proyecto tantos años no significa trabajar todo el tiempo en él. A veces alcanza con no apagarlo.
\nDesde 2011 cambió por completo cómo escuchamos música. Llegó el streaming, los algoritmos aprendieron nuestros gustos, tenemos cualquier canción a un click. En ese contexto, una radio chiquita por internet suena algo anacrónica. Pero sigue teniendo algo que las plataformas no dan: no elegir. Entrar a un lugar y aceptar la programación de otro. No saber qué viene después. Blur FM no compite con nada de eso, es apenas una selección posible en medio del ruido.
\nQuince años no se hacen solo. Quiero agradecer a Mike Harris, Archie Kennedy y Dave Gough, de Psand; a Diego Carlotta, de Greenlight Media; a Denis \"jaromil\" Roio y la comunidad de dyne.org; y a Nadia Zelnick, la voz de Blur FM y parte inseparable de su identidad. Cada uno aportó algo a esta historia.
\nSeguramente vendrán nuevos diseños, servidores, formas de escucharla, temporadas de mucho entusiasmo y otras en silencio. Lo importante es que el lugar sigue ahí: alguien entra, aprieta play, y encuentra una canción que no conocía.
\nLa radio sigue transmitiendo.
", "summary": "Hoy Blur FM cumple quince años. El 24 de julio de 2011 arrancó a sonar una radio por internet que, contra todo pronóstico, todavía sigue prendida. Cambiaron las computadoras, los servidores, los reproductores, el diseño. Cambió casi todo, menos la idea de fondo. Antes de…", "date_published": "2026-07-24T00:00:00+00:00", "tags": [ "blur-fm", "radio", "música", "internet", "proyectos-personales" ] }, { "id": "https://www.nico.com.ar/notes/la-odisea-de-comprar-una-hamburguesa/", "url": "https://www.nico.com.ar/notes/la-odisea-de-comprar-una-hamburguesa/", "title": "La odisea de comprar una hamburguesa", "content_html": "Hoy entré a comprar una hamburguesa y terminé atravesando una especie de circuito de obstáculos digitales que parecía diseñado para comprobar cuánto esfuerzo estaba dispuesto a hacer antes de rendirme e irme a comer a otro lado.
\nPrimero me acerqué a la caja, como hice toda la vida, pero me dijeron que solamente podía pagar en efectivo o con MODO. Nunca uso MODO, aunque tenía la aplicación instalada, así que la abrí para ver si podía resolverlo por ahí. Antes de mostrarme cualquier opción útil me pidió que la actualizara.
\nNo tenía demasiadas ganas de ponerme a actualizar la app en la caja para comprar una hamburguesa, así que decidí probar con uno de los tótems de autogestión. En teoría, esos equipos están para agilizar la compra, evitar filas y permitir que uno haga el pedido a su ritmo. En la práctica, lo primero que hizo fue pedirme que iniciara sesión.
\nYo solamente quería comprar una hamburguesa, no crear una cuenta ni comenzar una relación a largo plazo con la empresa. Tardé un rato en encontrar la opción para saltear ese paso, bastante menos visible que los botones que invitaban a registrarse o iniciar sesión.
\nUna vez adentro, el menú tampoco ayudaba demasiado. La pantalla estaba llena de fotografías gigantes, promociones, combos y productos destacados, mientras que los textos descriptivos eran mínimos. Había mucha información visual, pero poca información realmente útil para entender qué incluía cada producto o cuál era la diferencia concreta entre una alternativa y otra.
\nElegir la hamburguesa no fue especialmente complicado. Lo difícil fue pedirla en su versión regular, porque toda la interfaz, desplegada en una pantalla vertical de 32 pulgadas a menos de medio metro de distancia (formato que ya de por sí va a contramano de nuestra vista panorámica), parecía pensada para empujarme hacia la opción más grande y más cara. Los tamaños superiores, los agregados y las mejoras tenían fotos enormes y botones llamativos. La versión normal estaba disponible, pero había que encontrarla entre todas las oportunidades de gastar un poco más.
\nDespués de rechazar varios adicionales, finalmente completé el pedido y llegué al pago. El tótem mostraba dos opciones y elegí Mercado Pago, suponiendo que aparecería un código para escanear desde el teléfono, como sucede en casi cualquier comercio.
\nMe quedé esperando frente a la pantalla sin entender muy bien qué tenía que hacer. Después de unos segundos se acercó un empleado y me explicó que el proceso funcionaba al revés: no tenía que escanear un código generado por el tótem, sino abrir Mercado Pago, generar mi propio QR de pago y apuntarlo al lector de la máquina.
\nLa opción tampoco era particularmente evidente dentro de la aplicación. Terminé entrando en una sección que reconocía principalmente por haberla visto para pagar el transporte público, no para comprar comida. Después de encontrar el código, lo apunté al lector y esperé a que lo reconociera.
\nNo lo leyó.
\nProbamos otra vez, moviendo el teléfono, cambiando la distancia y acercándolo un poco más al sensor. El lector siguió sin reaccionar hasta que, de un momento a otro, el tótem canceló la operación completa y volvió a la pantalla inicial. Todo el pedido había desaparecido.
\nEl empleado terminó llevándome al tótem de al lado y cargando él mismo la hamburguesa desde cero. El sistema de autogestión había necesitado asistencia humana para completar una compra que originalmente podría haber resuelto esa misma persona desde una caja en menos de un minuto.
\nLo curioso es que cada una de las decisiones del proceso probablemente tenga una explicación por separado. La aplicación propia busca fidelizar clientes, el tótem reduce la cantidad de cajas, las fotografías grandes ayudan a vender productos y las opciones destacadas aumentan el valor promedio de cada pedido. El problema aparece cuando todas esas decisiones se acumulan y nadie parece evaluar la experiencia completa desde el lugar de quien solamente quiere comer algo.
\nEn unos pocos minutos tuve que abrir una aplicación que nunca uso, descubrir que necesitaba actualizarla, buscar la forma de evitar un inicio de sesión, navegar una interfaz diseñada para promocionar las opciones más caras, interpretar un mecanismo de pago poco habitual y repetir todo el pedido porque un lector no pudo reconocer un código.
\nLa autogestión debería eliminar pasos y hacer que una tarea cotidiana sea más rápida. Cuando está mal diseñada, solamente traslada el trabajo de la empresa al cliente y convierte una operación sencilla en una prueba de paciencia.
\nYo había entrado para comprar una hamburguesa. La tecnología mal empleada hizo todo lo posible para impedírmelo.
", "summary": "Hoy entré a comprar una hamburguesa y terminé atravesando una especie de circuito de obstáculos digitales que parecía diseñado para comprobar cuánto esfuerzo estaba dispuesto a hacer antes de rendirme e irme a comer a otro lado. Primero me acerqué a la caja, como hice…", "date_published": "2026-07-21T00:00:00+00:00", "tags": [ "ux", "diseño", "interfaces", "autogestión", "mercado-pago" ] }, { "id": "https://www.nico.com.ar/notes/migracion-heroku-docker/", "url": "https://www.nico.com.ar/notes/migracion-heroku-docker/", "title": "La migración que parecía difícil y terminó saliendo en una tarde", "content_html": "En Heroku tenía dos herramientas internas montadas para resolver cosas bastante puntuales. Andaban bien, no me daban dolores de cabeza y ya formaban parte del día a día del laburo, pero el costo mensual era difícil de justificar para lo chicas que eran.
\nEl tema es que una de las dos había crecido mucho más de lo que planeé en su momento. Ya no era una simple interfaz Node en un dyno: tenía base PostgreSQL, procesos de importación y exportación, una cola de entregas y un worker corriendo aparte, en otra VM, chequeando cada tanto si había trabajo pendiente.
\nLa segunda era mucho más simple. Recibía un archivo de texto, separaba el contenido por locale y devolvía un ZIP con varios HTML. Sin base de datos, sin almacenamiento persistente, pero curiosamente una de las que más horas consumía en toda la cuenta.
\nDecidí migrar las dos a una VM Debian nueva dentro de mi Proxmox. La idea era usar Docker para que cada aplicación quedara aislada, con sus propias dependencias y su propio contenedor, todo bien ordenado. No buscaba armar una plataforma gigante, sino dejar un host prolijo donde pudieran convivir varias herramientas sin que actualizar Node o meter una dependencia nueva rompiera algo de otra app.
\nAntes de tocar nada confirmé lo más básico: que el código que tenía en local fuera exactamente el mismo que estaba corriendo en producción. Comparé los commits locales contra los repos remotos de Heroku en las dos apps. Suena obvio, pero te salva de migrar una versión vieja pensando que es la actual.
\nLa primera app pedía más cuidado porque tenía datos reales en PostgreSQL. Saqué un backup lógico de la base, copié el proyecto y las variables a la VM nueva, levanté PostgreSQL 17 en Docker y restauré el dump entero. Después validé tablas, conté registros y chequeé que las migraciones de Prisma estuvieran al día antes de levantar la app.
\nCuando el portal arrancó por primera vez me encontré con uno de esos problemas que al principio asustan más de lo que son. La interfaz cargaba, tomaba la contraseña, pero volvía enseguida a la pantalla de login. Resulta que la app corría en modo producción y mandaba la cookie marcada como segura, mientras yo entraba por IP local con HTTP.
\nPara probarla adentro de la red la dejé un rato en modo desarrollo. Después armé Cloudflare Tunnel, le puse un dominio con HTTPS y volví a producción. La misma cookie que no funcionaba sobre la IP local empezó a portarse bien sin que tocara nada de la lógica de la app.
\nEl worker también necesitaba enterarse de dónde estaba el portal nuevo. Hasta ese momento seguía apuntando a la URL de Heroku, así que le paré el timer un rato, actualicé la variable de entorno y confirmé que se conectara bien al dominio nuevo. Cuando lo reactivé, volvió a consultar la cola con normalidad desde su VM.
\nLa segunda herramienta fue mucho más directa. Sin base de datos, sin secretos, sin procesos externos. Copié el repo, armé la imagen Node, levanté el contenedor y probé todo el flujo desde la terminal: subir un archivo de prueba, recibir el ZIP y chequear que los HTML salieran bien.
\nDespués pasé su dominio existente al mismo Cloudflare Tunnel. Para quien la usa no cambió nada: la URL siguió siendo la misma y la app siguió funcionando igual, solo que ahora corría en un contenedor en la VM nueva en vez de en Heroku.
\nUna vez que confirmé que las dos respondían bien por HTTPS y que los flujos principales andaban, borré las apps y sus recursos de Heroku. La parte que más respeto me daba terminó siendo la más mecánica: confirmar versiones, copiar, levantar en paralelo, probar y recién ahí hacer el corte.
\nCreo que salió fácil porque en ningún momento traté de resolver todo junto. En vez de pensarlo como una mudanza gigante de infraestructura, lo fui partiendo en checkpoints chicos donde podía verificar cada paso antes de seguir.
\nTambién ayudó que Docker dejara clarísimo qué necesitaba cada app. Una usa Node y PostgreSQL, la otra solo Node. Cloudflare Tunnel publica las dos sin abrir puertos en el router, y la VM quedó como un host general para herramientas chicas, no como una instalación artesanal imposible de mantener.
\nLo que arrancó como una forma de bajar un gasto terminó ordenando bastante la arquitectura. Las apps siguen separadas, los dominios no cambiaron, el worker sigue haciendo lo suyo y la infraestructura quedó lista para sumar otras herramientas más adelante.
\nLo más curioso es que durante bastante tiempo me imaginé esta migración como algo complicado y delicado. Cuando finalmente me senté a hacerla, las dos apps ya estaban funcionando en la VM nueva la misma tarde.
", "summary": "En Heroku tenía dos herramientas internas montadas para resolver cosas bastante puntuales. Andaban bien, no me daban dolores de cabeza y ya formaban parte del día a día del laburo, pero el costo mensual era difícil de justificar para lo chicas que eran. El tema…", "date_published": "2026-07-16T00:00:00+00:00", "tags": [ "heroku", "docker", "proxmox", "nodejs", "postgresql", "cloudflare", "linux", "self-hosting" ] }, { "id": "https://www.nico.com.ar/notes/pc-segunda-vida-proxmox/", "url": "https://www.nico.com.ar/notes/pc-segunda-vida-proxmox/", "title": "Una segunda vida para una PC vieja con Proxmox", "content_html": "Tenía una PC vieja juntando polvo en una caja, en un rincón de mi habitación. Durante años fue mi máquina principal: un AMD FX 8300, una mother ASUS, 16 GB de RAM, una placa de video Gigabyte de 2 GB y una fuente bastante decente. En su momento corrió Windows 10, la usé fuerte durante años y siempre respondió bien.
\nDespués armé mi PC actual, instalé Fedora, me acostumbré a trabajar todos los días en Linux y la máquina vieja quedó afuera del mapa. No estaba rota, no estaba inútil, simplemente había perdido su lugar.
\nEl otro día la saqué de la caja, la limpié, le cambié la pasta térmica, la prendí y arrancó perfecto. Tomó memoria, dio video y quedó esperando lo único que todavía no tenía: un disco para bootear.
\nAhí apareció la idea de darle una segunda vida, pero no como PC principal ni como reemplazo de ningún servidor actual. La idea es mucho más simple: convertirla en un laboratorio Proxmox para prender cuando tenga ganas de probar algo, romper una VM, instalar una distro nueva o practicar infraestructura sin tocar nada importante.
\nEsa separación me gusta. Mi servidor de producción tiene que ser aburrido y estable. No quiero usarlo para experimentos raros ni para probar cosas que pueden romperse. Para eso tiene mucho más sentido una máquina aparte, vieja pero todavía capaz, donde equivocarse no sea un problema.
\nEl hardware no es moderno, pero para laboratorio tiene bastante gracia. Un SSD SATA de 960 GB para Proxmox y las VMs principales, un disco WD Blue de 1 TB para backups de prueba o almacenamiento secundario, y un disco mecánico viejo de laptop para hacer experimentos sin miedo. Incluso tiene grabadora de DVD, algo completamente innecesario en 2026, pero justamente por eso bastante simpático para un laboratorio casero.
\nEl único punto menos prolijo es la red. En esa habitación no tengo Ethernet directo, así que la solución va a ser usar un repetidor WiFi con puerto Gigabit Ethernet. El repetidor se conecta al WiFi de casa y la PC lo ve como una conexión cableada normal. Para Proxmox eso es bastante más limpio que depender de una placa WiFi directa dentro del host.
\nTambién me interesa probar Wake on LAN. La máquina ya había funcionado antes con magic packet, así que la idea es poder encenderla remotamente desde una Raspberry Pi que queda siempre prendida con Tailscale. En la práctica sería algo bastante simple: entro desde afuera a la red de casa, mando el magic packet, la PC prende, entro al panel de Proxmox y levanto la VM que necesite.
\nLo que más me entusiasma no es la potencia bruta, sino el tipo de cosas que puedo aprender ahí. Quiero probar Fedora Server, openSUSE, Arch Linux, Omarchy, Debian limpio y algunas distros que quedaron afuera de otras máquinas más chicas. También me gustaría jugar con Proxmox Backup Server, practicar snapshots, hacer restores reales y entender mejor cómo ordenar templates de VMs.
\nOtra idea que me interesa es probar K3s, una versión liviana de Kubernetes. No porque quiera convertir mi casa en un datacenter, sino porque como diseñador y UX engineer me sirve entender mejor qué pasa después de que una interfaz deja de ser un diseño o un prototipo.
\nHay un camino que muchas veces queda medio invisible desde diseño: frontend, build, container, deploy, service, ingress, logs, rollback. Poder recorrer ese flujo en una escala chica, con una app simple o un dashboard interno, me parece una forma muy concreta de aprender. No necesito una infraestructura enorme. Necesito un lugar donde pueda probar, mirar qué pasa y volver atrás sin miedo.
\nLa máquina también puede servir para ordenar mejor mi ecosistema casero. Hoy tengo una PC principal para trabajar, un servidor que sostiene servicios reales, una Raspberry Pi para staging y acceso remoto, otra para sitios estáticos livianos, y algunas máquinas más chicas para pruebas. Lo que faltaba era un lugar claro para romper cosas sin mezclarlo con producción.
\nEse sería el rol de esta PC: laboratorio bajo demanda. Después vendrán las distros, Kubernetes, los discos viejos, los templates y todas las demás ideas.
\nMe gusta porque no estoy comprando una PC nueva ni complicando algo que ya funciona. Estoy recuperando hardware que ya tenía y dándole un rol mucho más claro que antes. La PC vieja no vuelve como máquina principal, sino como un laboratorio linuxero todo terreno.
", "summary": "Tenía una PC vieja juntando polvo en una caja, en un rincón de mi habitación. Durante años fue mi máquina principal: un AMD FX 8300, una mother ASUS, 16 GB de RAM, una placa de video Gigabyte de 2 GB y una fuente bastante decente.…", "date_published": "2026-05-27T00:00:00+00:00", "tags": [ "proxmox", "home-lab", "linux", "virtualization", "fedora", "tailscale", "kubernetes", "low-tech" ] }, { "id": "https://www.nico.com.ar/notes/aires-pulse-transaccion-pi-zeros/", "url": "https://www.nico.com.ar/notes/aires-pulse-transaccion-pi-zeros/", "title": "Aires Pulse y una transacción entre Pi Zeros", "content_html": "El otro día tenía una idea dando vueltas y era conectar dos mundos que ya existían: las Raspberry Pi Zero 2 W y mis pequeños sitios personales. La idea era que una Pi Zero generara información y otra la publicara. Una especie de transacción entre Pi Zeros.
\nLa máquina que genera los datos es Pipeta, más laboratorio que servidor. La que publica es Pipita, la Zero que ya sirve nico.com.ar, run.nico.ar y zero.nico.ar con NGINX. En el medio, apenas rsync, JSONs estáticos y un poco de paciencia.
Así empezó Aires Pulse.
\nAl principio era apenas una página oscura con un nombre lindo y una promesa: mostrar señales de Buenos Aires en el aire, el río y el clima. Pipeta ya tenía un experimento previo para mirar aviones cerca de Buenos Aires, así que lo más natural fue convertir esa información en un aircraft.json y mostrarlo en el sitio. Primero como números: cuántos aviones, países, velocidad, altitud. Después apareció el mapa.
Con Leaflet, el sitio pasó de ser una tarjeta con datos a un pequeño radar visual. Los puntos sobre Buenos Aires, el Río de la Plata, los aviones entrando y saliendo. De repente, esa idea medio de laboratorio parecía una mini consola casera de monitoreo.
\nLa segunda capa fue el clima. Pipeta empezó a generar un weather.json con condiciones actuales y una recomendación de ventana para correr. No era solo mostrar temperatura: la gracia estaba en transformar esos datos en algo útil para decidir cuándo salir.
Al principio esa información vivía en Aires Pulse. Pero después apareció una pregunta bastante obvia: si la recomendación es sobre correr, ¿por qué no usarla también en run.nico.ar?
\nAhí el experimento se volvió más interesante.
\nrun.nico.ar se genera desde Pipa, la Raspberry Pi 5. Es un sitio estático que se actualiza cuando publico una actividad o cuando corre su rutina diaria. Pero la información de clima venía de Pipeta y el sitio estaba alojado en Pipita. O sea: tres máquinas distintas, cada una con su rol, y los datos tenían que viajar entre ellas de forma coherente.
\nLa solución fue separar el build estático de los datos vivos. run.nico.ar sigue viviendo en /srv/data/www/run.nico.ar, pero el JSON de condiciones para correr se publica por fuera, en una carpeta live, y NGINX lo sirve como si fuera /data/running-conditions.json. De esa forma, Pipa puede hacer deploys con rsync --delete sin pisar los datos que Pipeta actualiza cada pocos minutos.
Curiosamente, lo más trabajoso no fue la parte técnica, sino la de producto.
\nHabía que decidir qué mostrar, cómo mostrarlo y dónde. El bloque de condiciones para correr pasó por varias formas hasta que la tarjeta empezó a responder una pregunta concreta: ¿cuál es el mejor momento para correr? Cuando la respuesta se volvió obvia de leer, el diseño dejó de molestar.
\nEn paralelo, run.nico.ar también ganó una separación entre el \"Next run\" editorial y el \"Workout\" práctico: uno explica qué conviene hacer y por qué, el otro lo traduce a bloques cargables a mano en Garmin Connect. No es una integración real. Es algo más simple y más honesto: una guía clara.
\nAl final, lo interesante no fue solo que Aires Pulse quedara online, ni que run.nico.ar pudiera consumir datos vivos. Lo interesante fue ver cómo varias máquinas muy chicas terminaron cumpliendo roles bastante definidos.
\nPipeta observa. Pipita publica. Pipa interpreta.
\nTodo con herramientas bastante básicas: NGINX, JSON, cron, rsync y un poco de Python. Me gusta esa escala. No es infraestructura grande, ni falta que hace. Es apenas un ecosistema personal donde cada pieza hace algo simple y lo hace bastante bien.
Y eso, por ahora, alcanza.
", "summary": "El otro día tenía una idea dando vueltas y era conectar dos mundos que ya existían: las Raspberry Pi Zero 2 W y mis pequeños sitios personales. La idea era que una Pi Zero generara información y otra la publicara. Una especie de transacción entre…", "date_published": "2026-05-04T00:00:00+00:00", "tags": [ "raspberry-pi-zero-2w", "aires-pulse", "run-nico-ar", "nginx", "json", "home-lab", "low-tech" ] }, { "id": "https://www.nico.com.ar/notes/este-website-se-mudo-a-alpine/", "url": "https://www.nico.com.ar/notes/este-website-se-mudo-a-alpine/", "title": "Este website se mudó a Alpine", "content_html": "Hace unos días escribí sobre Pipeta, una Raspberry Pi Zero 2 W con Alpine Linux pensada como sandbox puro. La idea era experimentar sin presión, sin producción y sin convertir cada prueba en infraestructura.
\nLo que no esperaba era que esa misma experiencia terminara empujando otra decisión más concreta: migrar también la otra Zero 2 W. Ahí viven nico.com.ar, run.nico.ar y zero.nico.ar, todo servido con NGINX detrás de Cloudflare Tunnel.
La razón del cambio fue la solidez demostrada por Alpine Linux. Mientras Pipeta, con Alpine, se venía comportando de forma impecable, Pipita seguía en Raspberry Pi OS Lite de 32 bits y cada tanto entraba en estados raros donde parecía seguir conectada al WiFi, pero en la práctica quedaba medio zombie. No siempre pasaba, pero lo suficiente como para que dejara de sentirse confiable.
\nEntonces tocó hacer lo que había que hacer: backup de los sitios, relevamiento de la configuración, limpieza de todo lo que ya había offloadeado a otras máquinas y reinstalación desde cero.
\nCuriosamente, lo más difícil no fue volver a levantar NGINX, ni restaurar Cloudflare Tunnel, ni dejar andando otra vez el flujo de deploy por rsync. Lo más trabajoso fue algo mucho más básico: el bendito WiFi headless, que permitiría luego ganar acceso por SSH y realizar la configuración.
Recién cuando eso quedó arreglado, el resto empezó a resolverse super rápido: usuario nuevo, SSH, sitios restaurados, túnel activo, deploys funcionando otra vez y todo sirviendo como antes.
\nAl final, el resultado fue muy bueno. No tanto por haber “migrado infraestructura”, sino por haber dejado esta máquina en una base bastante más coherente con su función: Alpine Linux 64 bits, 512 MB de RAM, NGINX y túnel Cloudflare saliente.
\nTambién hubo algo interesante en ver cómo una simple experiencia en una máquina de laboratorio terminó mejorando otra que sí tenía trabajo real. A veces un sandbox no solo sirve para aprender: también sirve para despejar el camino de lo que viene después.
\nEn este caso, al menos por ahora, parece que valió la pena.
", "summary": "Hace unos días escribí sobre Pipeta, una Raspberry Pi Zero 2 W con Alpine Linux pensada como sandbox puro. La idea era experimentar sin presión, sin producción y sin convertir cada prueba en infraestructura. Lo que no esperaba era que esa misma experiencia terminara empujando…", "date_published": "2026-04-15T00:00:00+00:00", "tags": [ "alpine-linux", "raspberry-pi-zero-2w", "nginx", "cloudflare-tunnel", "low-tech" ] }, { "id": "https://www.nico.com.ar/notes/alpine-linux-pipeta/", "url": "https://www.nico.com.ar/notes/alpine-linux-pipeta/", "title": "Pipeta, Alpine y el encanto de volver a las bases", "content_html": "Estos días me encontré con una situación interesante: 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 cosas 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 interesante: 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…", "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" ] } ] }