- Después de cansarse de la industria del software y de las redes sociales tradicionales, probó Mastodon, pero lo que realmente necesitaba no era una línea de tiempo centrada en personas, sino un lector de feeds personal para reunir textos y notificaciones de la web
- El objetivo no era una lista atrasada estilo bandeja de entrada de un lector RSS, sino una interfaz tipo stream donde, cada vez que se abriera, fluyera contenido interesante como en el feed de inicio de Twitter o Mastodon
- El criterio de diseño fue experiencia de usuario > facilidad de operación > facilidad de desarrollo, priorizando opciones simples de operar como htmx·hyperscript, una app web monolítica, SQLite, Python y extensiones como gevent y Huey
- En el uso real se fueron agregando funciones como leer artículos dentro de la app, fijar elementos para leer después, bookmark, ordenar por frecuencia de publicación de la fuente y marcar automáticamente como “ya visto” al hacer scroll
- Tras unos 3 meses de trabajo relajado creó feedi, y al usarlo durante varios meses como la “portada de internet”, recuperó una sensación de control sobre la información que consume
Una nueva forma de usar la web después del burnout
- Pasó por un burnout profesional tras una serie de malos proyectos y el desencanto con la industria del software
- Redujo su carga de trabajo, renunció y empezó terapia, además de corregir hábitos como la alimentación, el ejercicio y la meditación
- Durante un tiempo se alejó de la programación y de leer sobre software, y también dejó Twitter, la última red social que seguía usando
- Mientras leía How to Do Nothing, volvió a mirar Mastodon como una comunidad alternativa en línea
Los límites que encontró en Mastodon
- Mastodon ofrecía un feed cronológico sin intermediación algorítmica, lo que devolvía la sensación de controlar el feed
- Personas con incomodidades similares respecto a la industria del software y la web estaban revisitando elementos de la vieja web como RSS, BBS, digital gardens y webrings, o imaginando una web más abierta e independiente
- En la práctica, su objetivo de uso estaba más cerca de un hub de información que del microblogging
- Seguía a personas para recibir notificaciones cuando publicaban algo en sus sitios web
- Seguía bots para recibir contenido de agregadores de enlaces
- Después de conocer el concepto de social readers del IndieWeb, concluyó que la herramienta que necesitaba no era Mastodon, sino un lector de feeds que pudiera ajustar por su cuenta
Objetivos de usuario para un lector personal
- Quería un stream de contenido interesante cada vez que abriera la app, no una lista acumulada tipo bandeja de entrada como en un lector RSS tradicional
- El feed debía mezclar varias fuentes
- Blogs, revistas, sitios de noticias y agregadores de enlaces
- Notificaciones de cuentas personales como Mastodon, Goodreads y GitHub
- Como cada fuente tenía formatos de datos distintos, necesitaba personalización del parsing para darles una apariencia y sensación consistentes
- Las funciones sociales de un lector IndieWeb completo no estaban dentro del alcance
- No era problema abrir otra pestaña para comentar
- No importaba que el contenido estuviera disperso en sitios de terceros
- El objetivo de corto plazo era comprobar rápido si esta herramienta podía convertirse en su fuente principal, o incluso única, de información web; si no, pensaba abandonar el proyecto de inmediato
Principios de desarrollo y alcance
- El principio de desarrollo era
user > ops > dev- En prioridades y concesiones de diseño, prefería la facilidad de operación por encima de la comodidad de desarrollo
- Y por encima de eso estaba la experiencia de usuario
- Como era una app personal, “prioridad al usuario” significaba usarla directamente (dogfooding) y satisfacer primero sus propias necesidades
- Consideraba más útil crear una herramienta ergonómicamente adaptada a sí mismo que intentar imaginar a un usuario ideal
- Este proyecto no debía ser un proyecto de aprendizaje ni de portafolio
- La meta no era la productividad, sino reconectar con el disfrute del desarrollo de software
- Y ese disfrute debía venir no tanto de “hacer algo” como de “usar algo hecho por uno mismo”
- Al asumir un solo usuario objetivo, pudo posponer muchas decisiones
- La autenticación, que no era necesaria de inmediato, se dejó para después
- Funciones muy específicas, como enviar a Kindle, podían abordarse desde el inicio
- Se podía dar por hecho conocimiento de programación para cosas como personalizar el parser de feeds o iniciar sesión en Mastodon
Elecciones de UI y arquitectura
- Para que fuera accesible no solo en laptop sino también en teléfono, tenía que ser una aplicación web
- Era una forma rentable de dar soporte a ambos dispositivos con una sola interfaz
- Permitía usar HTML y CSS familiares
- Guardar el estado en el servidor resolvía la sincronización entre dispositivos
- La UI web debía ser dinámica hasta cierto punto, pero no quería una app frontend separada ni aprender un framework nuevo
- Siguiendo los consejos de boring tech y radical simplicity, buscó librerías de renderizado del lado del servidor y terminó usando htmx junto con hyperscript
- Para facilitar la operación, el despliegue y la configuración local debían ser sencillos, sin depender de infraestructura como Docker o Nix
- El lector IndieWeb formal que describe Aaron Parecki se divide en múltiples componentes por protocolo, como Micropub, Microsub y Webmentions, pero para uso personal eso solo complicaba el desarrollo y la operación sin aportar demasiadas ventajas
- Como resultado, eligió una aplicación web monolítica y usó SQLite como base de datos para reducir la cantidad de componentes a instalar y configurar
Lenguaje y tareas en segundo plano
- Go parecía encajar bien en este proyecto por ser simple, generalista, tener garbage collection, suficiente velocidad, un buen modelo de concurrencia y binarios fáciles de desplegar
- Pero no había escrito ni una sola línea de Go, y no quería que el proyecto se convirtiera en uno de aprendizaje
- Eligió Python, el lenguaje conocido con el que podía hacer un prototipo más rápido
- Python seguía teniendo desventajas en cuanto a entorno y dependencias, especialmente las del sistema operativo anfitrión
- No quería sumar más componentes para el polling periódico de feeds, y tras investigar decidió usar gevent y la extensión mini-huey de Huey para ejecutar tareas en segundo plano dentro del proceso de la aplicación
- A cambio, Python contaba con buenas librerías para HTTP, parsing de feeds y scraping
Por qué dejó de lado las pruebas
- Al principio decidió no escribir pruebas
- Como planeaba experimentar agregando, quitando y reorganizando funciones, pensó que el costo de mantener pruebas unitarias sería mayor que su valor
- Podía tolerar errores pequeños de lógica y, como usaba la app personalmente todos los días, esperaba que los bugs importantes salieran a la luz con el tiempo
- Consideraba que las pruebas de integración daban más confianza, pero muchos bugs de este proyecto surgían en la integración con fuentes externas y en la UI
- Las pruebas de integración quizá habrían detectado antes algunos bugs y regresiones, pero juzgó que no valía la pena asumir ese costo inicial
Cómo el uso real fue guiando las funciones
- Al usarla todos los días como usuario final, las ideas, experimentos y prioridades se fueron definiendo solas
- Tras probar varios layouts y funciones de UI, se asentó un patrón de uso
- Abrir la app
- Hacer scroll en el feed principal
- Fijar elementos para leer después
- Abrir elementos para leer ahora
- Guardar con bookmark los elementos para consultar después
- Quería poder leer los artículos sin salir de la app, entre otras cosas para evitar paywalls y pop-ups de consentimiento
- Probó varias librerías de Python para extraer contenido HTML, pero ninguna funcionó tan bien como readability, la que usa Firefox
- Como readability es un paquete de JavaScript, terminó agregando Node.js como dependencia opcional
Orden del feed y marcado de “ya visto”
- Incluso después de tener las funciones básicas, ordenar solo por fecha de publicación hacía difícil encontrar contenido interesante
- Entradas raras de blogs quedaban enterradas detrás de toots de Mastodon
- Artículos largos de revistas quedaban enterrados detrás de noticias diarias
- Como todas las fuentes seguidas eran de interés, asumió que quería ver antes el contenido de fuentes con menor frecuencia de publicación
- Si un newsletter mensual había salido en los últimos días, debía aparecer por encima del microblogging o de las noticias diarias
- Clasificó las fuentes en “frequency buckets” y ordenó el feed para que los buckets de menor frecuencia aparecieran primero
- Para evitar que ese contenido poco frecuente se quedara pegado arriba cada vez que abría la app, agregó una función que marca los elementos automáticamente como “already seen” al hacer scroll
- Con este método, siempre veía contenido nuevo sin perderse las actualizaciones infrecuentes
De local a VPS
- Al principio ejecutaba la app en una pestaña de terminal de su laptop, desarrollando y usándola al mismo tiempo
- Cuando el contenido que aparecía en el feed empezó a gustarle, la subió a un servidor Raspberry Pi en su red local para tenerla siempre disponible
- Al usarla de forma permanente en la Raspberry Pi, mejoró el renderizado móvil para acceder desde el teléfono
- Cuando llegó a extrañarla incluso estando fuera de casa, la desplegó en un VPS
- El despliegue en VPS lo obligó a agregar autenticación y soporte multiusuario, que había venido posponiendo, y le permitió dar acceso de beta testing a algunos amigos
- La configuración del VPS llevó también a comprar un dominio y crear este sitio web, acercándose más al ideal IndieWeb que lo había inspirado al principio
El resultado de feedi
- Después de unos 3 meses de trabajo relajado, creó el lector de feeds personal feedi
- Más que un producto terminado, feedi se parece a una configuración de Emacs: una herramienta siempre medio rota, pero que uno termina incorporando al cuerpo
- Desde una perspectiva de productividad es difícil de justificar, pero da satisfacción por ser una herramienta hecha a la medida de sus propias condiciones
- Durante varios meses usó feedi como la “front page of the internet”
- Al usar un lector personal, recuperó el control sobre la información que consume, buscó activamente blogs y revistas interesantes, y quedó más expuesto al descubrimiento y la sorpresa
1 comentarios
Comentarios de Hacker News
Fue bastante divertido configurar urlwatch(https://urlwatch.readthedocs.io/en/latest/). Sobre todo cuando pasas del boilerplate de Puppeteer y puedes scrapear sitios con JavaScript usando una instancia de Chrome; se siente como tomar el control haciendo que la web te llegue, en vez de ir a buscarla
Es muy potente poder monitorear sitios web sin mucho esfuerzo y revisarlos por la mañana. Se pueden seguir ofertas de empleo de empresas que te gustan, vacantes/cierres en tu empresa actual, productos en oferta, reposición o reacondicionados que estás esperando, estadísticas de aguas residuales de COVID, departamentos en renta, releases de GitHub que te interesan e incluso cambios en los términos de sitios web importantes
Personalmente uso un Droplet de DigitalOcean de $5 porque también self-hosteo un lector RSS y un bot de Telegram, y suelo crear pequeños sitios HTTP experimentales, pero como no necesita ejecutarse todos los días a la misma hora, también se podría hacer desde una laptop
Como es para uso personal, solo recibo resúmenes de actualizaciones de Twitter sobre temas que me interesan, y puedo evitar el sitio en sí, las discusiones tóxicas y los anuncios molestos
Me cuesta ordenar bien las ideas porque el estado actual de la TI me enoja demasiado, pero a veces imagino el concepto de “mi persona de TI”. Alguien que se encargue de una parte de tu vida digital, como el barbero del barrio, el médico de cabecera, el sastre o el panadero
Tendría una pequeña infraestructura local, crearía feeds personalizados, cuidaría la privacidad y la salud digital, y te conectaría con lectores de feeds mediante interfaces simples o protocolos abiertos. Cubriría películas, textos, memes y videos divertidos, pero lo central sería que hay un ser humano con quien conversar, no un algoritmo de optimización de ingresos
También se me ocurren ideas como centros de datos operados por la comunidad local, como si fueran bibliotecas, o servicios de contenido simple servidos desde la conexión de internet de casa. Por eso me gustaron ideas como Veilid(https://gitlab.com/veilid/veilid)
No es la primera vez que escucho que alguien se volvió más saludable después de mudarse al Fediverse. Yo mismo estoy montando scripts y miniapps encima de Puppeteer, y usando llamacpp local para resúmenes y recomendaciones; quiero pulirlo más y recomendárselo a amigos y familia
A estos scripts les puse el nombre “not a browser”. Quiero una web que no sirva HTML/CSS/JS junto con los datos, sino que entregue solo los datos y deje al usuario decidir cómo mostrarlos
No hay algoritmos hostiles al usuario ni sistemas basados en publicidad; en general es software que pone al usuario primero y habla de protocolos abiertos. Si estás en la industria de TI y puedes operar tu propio servidor, es posible; el problema es qué hacen quienes no pueden
La idea de una “persona de TI” personal me parece interesante. Me pregunto si se podría ofrecer este tipo de servicio a personas que quieren alejarse de las grandes tecnológicas y sus algoritmos, y usar algo más personal, pero no tienen los medios técnicos
Con los datos médicos pasa algo parecido. No me gusta que mis expedientes médicos estén guardados en MyChart y varios sistemas propietarios, sin que yo tenga control. Tengo una supercomputadora en el bolsillo; no entiendo por qué no puedo conservar yo una copia de mis registros y compartirla selectivamente con el médico durante una consulta
También es raro que los hospitales todavía tengan que mandarse faxes entre sí. Debería poder compartir mis datos con un botón. Apple Health es lo más cercano en algunos aspectos, pero la adopción en EE. UU. parece casi nula, y aun así favorece solo a usuarios de Apple. Los datos de salud no deberían quedar encerrados en sistemas propietarios, aunque sea algo tipo Apple Health que corre localmente; hacen falta protocolos abiertos y un ecosistema de implementaciones
Hubo un breve periodo bastante bueno antes de que el marketing y la codicia se apoderaran de internet. Algo como un Synology NAS con apps beneficiosas para el usuario final, acompañado por “mi persona de TI”, podría funcionar bien
Si no estuviera diseñado para extraer datos personales y dinero, para el usuario sería casi una utopía, pero la viabilidad económica probablemente sería la de un negocio de márgenes bajos y alto riesgo. Por ejemplo, la responsabilidad por pérdida de archivos sería un problema grande
La estructura es escribir el código una vez y ejecutarlo un millón de veces con casi ningún costo adicional. Todas las fuerzas estructurales parecen empujar en sentido contrario. Quizá sea más posible cuando la IA reemplace todos nuestros trabajos
How to Do Nothing, de Jenny Odell, es un libro realmente excelente. Puede que no coincida del todo con el público típico de Hacker News, pero lo recomiendo mucho a cualquiera que esté empezando a sentir la presión de la falsa “productividad” impuesta por la economía de la atención
También vale la pena ver otros proyectos de Jenny Odell. Por ejemplo, The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)
En la misma línea, también recomiendo Saving Time, de Jenny Odell. Es un libro tranquilo pero muy radical, y personalmente me pareció mejor que el otro. La narrativa estaba más enfocada
Más allá de un simple feed personal, quisiera un feed con límite de tiempo y sin distracciones
Me gustaría reunir todo el contenido escrito de las personas que sigo y que el sistema elija una combinación de elementos para tener unos 30 minutos de lectura al día. Debería incluir de todo: posts de blogs, artículos, tuits, etc.
Usando ChatGPT u otra herramienta, debería filtrar el contenido más “nutritivo” y priorizar lo que tenga valor por encima de las discusiones. Luego quisiera enviarlo a un Kindle o a una tablet reMarkable para leer lejos de los colores, los destellos y el internet rápido.
Como siguiente paso, me gustaría suscribirme al feed de un amigo y recibir de vez en cuando contenido “invitado” de ese feed.
Me gusta la idea de agregar resúmenes con GPT y, si a otras personas también les interesa, podría ordenarlo y compartirlo. Por ahora es una app sencilla en JavaScript que uso localmente, pero esta idea se ve más interesante de lo que pensaba al principio.
Creo que era Douglas Engelbart, pero no encuentro material sobre agentes. También pudo haber sido otra persona experta en tecnología.
Me llamó la atención, y me identifiqué, con la decisión consciente de no hacer pruebas automatizadas al principio. Me tomó bastante tiempo superar esa sensación incómoda de no escribir tests, pero en proyectos personales de juguete ahora adopto un enfoque parecido.
Demasiados proyectos murieron más o menos el primer día. Justo cuando debería haber estado ganando impulso, perdía las ganas armando infraestructura de pruebas y pipelines de CI.
Ahora trabajo con el criterio de agregar tests cuando la falta de tests se convierta en un problema real.
Lo que es indispensable en un proyecto maduro, con muchos desarrolladores y una base de código grande, puede ser una carga en un proyecto pequeño de una sola persona.
Después me enfoco en agregar tests puntuales cada vez que surge un problema.
Hace unos años, como proyecto personal, construí un analizador de gases respiratorios y escribí software para conectarlo por Bluetooth y mostrar los datos en tiempo real. Los tests unitarios fueron muy útiles para las funciones que debían hacer cálculos científicos con precisión, pero, viéndolo en retrospectiva, probar otras partes de la interfaz fue casi una pérdida de tiempo.
Cuando tuve la certeza de que esas funciones ya no iban a cambiar, eliminé todos los tests. Cuando desarrollas solo, las pruebas manuales pueden ser suficientes.
Creé una nueva cuenta anónima para hablar con honestidad sobre el futuro.
Me sorprendió porque este texto parecía escrito por mi yo del futuro. Tenía tantas cosas en común con el autor que costaba creerlo.
Me había dado cuenta de mi burnout y estaba planeando dejar el trabajo a comienzos del próximo año. Esa es también la razón por la que creé una cuenta anónima. Probablemente haya muchas personas que se sienten de forma parecida.
Lo más sorprendente es que lo que hizo el autor es casi lo mismo con lo que yo fantaseaba hacer durante mi descanso. Estuve pensando en cómo participar en la web abierta/IndieWeb y tenía planes de crear una app para experimentar en ese ámbito.
Incluso se parecen las preocupaciones técnicas, como el problema de evitar que las publicaciones poco frecuentes queden enterradas en medio de la avalancha, o qué lenguaje y tecnologías usar. En desarrollo web estoy atrasado como 10 años, pero también pensé en hacer algo con tecnologías web modernas.
Por un lado, me alegra sentir que mis pensamientos y emociones recientes quedan validados. Siento que voy por el camino correcto. Por otro lado, me duele que el autor lo haya hecho primero y todavía me queda algo de envidia.
En ese entonces quería mi propio lector RSS. No me gustaban los lectores existentes; quería un lector que no se viera como una bandeja de entrada, sino como un blog normal, y que pudiera diseñar como quisiera. Así que hice un parser de feeds RSS y lo diseñé para que se viera como mi blog normal.
Después lo cambié para que, si un feed RSS solo tenía un resumen, trajera el artículo completo. No quería hacer clic fuera del lector para ver el texto completo; quería tenerlo todo dentro del lector de feeds. Cuando ya tuve un scraper básico de páginas, también lo usé con sitios sin RSS, y eso fue especialmente útil cuando se popularizaron las redes sociales.
Podía ver en mi feed solo el contenido que quería, sin necesidad de ir al sitio social real. Como es algo de hace 20 años, está hecho con tecnologías viejas como PHP y XSLT, y sigue igual.
En cualquier caso, recomiendo mucho hacerlo uno mismo. Es un proyecto divertido. Es viejo, tosco y el scraping no es perfecto, así que a veces no aparece el contenido que quiero, pero es mío y me gusta porque es un lector que uso todos los días desde hace 20 años.
No hay razón para que un intento parecido no tenga efecto. Tampoco fui la primera persona en implementar un lector personal.
Lo interesante es que, al volver a revisar el texto de IndieWeb que había enlazado, sentí que prácticamente repetía sus ideas: algo como “no intentes crear software para todo el mundo; créalo para ti”.
Si intentas hacerlo de propósito general y fácil de usar para otras personas, puedes terminar haciendo concesiones que perjudican tu propia usabilidad o diseñando para usuarios imaginarios que ni siquiera existen. La idea es hacerlo de forma egoísta para que te resulte más útil a ti.
Me pareció realmente refrescante. Durante el último año atravesé una ruta muy similar de burnout/recuperación, y crear software personal útil me permitió volver a disfrutar el trabajo.
Otra gran ventaja es poder probar libremente las tecnologías “poco ortodoxas” que quieras. Cosas como crear ejecutables PHP modernos en un solo binario, usar SQLite en producción o desplegar sin Docker me resultan entretenidas.
Este tipo de trabajo también tuvo efectos indirectos en mi empleo principal. A menudo descubro nuevas técnicas y optimizaciones en mis repositorios personales y luego las llevo al trabajo.
Es interesante cómo las personas técnicas suelen experimentar con cosas aparte y luego llevan lo aprendido a su trabajo de una forma útil y, a veces, valiosa. Pero a veces los empleadores menosprecian ese esfuerzo o frenan ese entusiasmo.
Tal vez he trabajado en el tipo equivocado de organizaciones. Aun así, me alegra que hayas obtenido beneficios de esos efectos indirectos.
Prefiero la mentalidad de feeds a una checklist de cosas por leer/consumir. Durante años probé varios lectores RSS, pero nunca me quedé con ninguno por mucho tiempo.
Me preguntaba si realmente necesitaba gestionar otra bandeja de entrada. Aun así, pienso echarle un vistazo a feedi (https://github.com/facundoolano/feedi)
Antes de configurarlo, solía andar haciendo clic sin rumbo por todos lados, pensando si habría alguna publicación nueva en HN o en Reuters. Mi experiencia coincide con https://news.ycombinator.com/item?id=38642092
Mi correo personal, las listas de correo y los feeds RSS quedan todos en un solo lugar. Si los filtras en spools separados y los usas junto con un cliente de correo potente como mutt, se vuelve una experiencia integrada bastante cómoda.
Parece que el autor agregó autenticación para poder acceder a la app desde cualquier lugar.
Me pregunto si, en cambio, sería posible o más fácil ponerla detrás de una VPN y hacer que esa VPN sea accesible desde cualquier lugar.
Quiero acceder de forma segura a una webapp personal, pero estoy buscando el enfoque más sencillo. Cada vez que veo autenticación, me parece un laberinto de conceptos, protocolos y bibliotecas, y no quiero tener que mantener eso.
Alojo algunas apps como Home Assistant en una Raspberry Pi en casa, instalé Tailscale en esa Pi y en mi teléfono, y funciona muy bien. La única autenticación que hay que hacer es “iniciar sesión en Tailscale en cada dispositivo”.
Recomiendo muchísimo Tailscale por lo fácil que hace armar una red segura con tus propios dispositivos.
Es suficiente para “proteger” mi aplicación, que solo aloja fragmentos de texto que recorto de otros sitios web.
Hay muchas formas de hacerlo, pero la idea es poner el endpoint de la VPN y la webapp en el mismo lugar, por ejemplo en la misma máquina o en la misma red, y restringir el acceso a la webapp desde cualquier otro lugar.
Caddy está configurado para hacer reverse proxy solo a las solicitudes que vienen de la red interna o de la VPN; si no, devuelve 404. Así que, si no estás en la VPN o en la red de casa, no ves nada.
Dependiendo de si les das acceso a la red a invitados y de qué servicios ejecutes, quizá necesites VLAN o una red de invitados separada. Muchos de los servicios que corro en casa también tienen su propia autenticación con contraseña, y la uso junto con la restricción por VPN.
Esta configuración fue la primera que se me ocurrió, así que podría no ser segura por razones fuera de mi área de experiencia. La ventaja es que también corro Pi-hole en el mismo archivo compose, así que cuando el teléfono se conecta a la VPN, también obtengo bloqueo remoto de anuncios “gratis”.
Tailscale es más fácil de configurar y tiene mejor UI, pero dejé de usarlo porque consumía mucha batería en iOS. También está el problema de tener que “confiar en servidores de terceros”, aunque si no hubiera sido por la batería, probablemente habría aceptado el riesgo adicional por la comodidad.
La app de WireGuard también tiene funciones útiles. Puedes indicarle que no se ejecute en ciertas redes, como cuando estás en casa, de modo que se active automáticamente al salir y se desactive al volver.
Esto se parece sorprendentemente a algo que pensaba que haría falta en un yate de crucero. Sobre todo en mar abierto, donde la conectividad es intermitente; con dos cosas más sería exactamente lo que se necesita.
Debería permitir tocar sincronizar ahora en esos momentos breves de conexión, como cuando pasas por una isla con señal LTE. Además, por defecto debería aplicar Readability y caché local para que todo el contenido, incluidas las imágenes, se pueda leer sin conexión.