Recuperando a web com um leitor pessoal
(olano.dev)- Depois de se cansar da indústria de software e das redes sociais tradicionais, até experimentou o Mastodon, mas o que realmente precisava era um leitor de feeds pessoal para reunir textos e notificações da web, e não uma timeline centrada em pessoas
- O objetivo não era uma lista acumulada no estilo caixa de entrada de um leitor RSS, mas sim uma interface em fluxo em que conteúdos interessantes aparecessem sempre que fosse aberta, como no feed inicial do Twitter ou do Mastodon
- O critério de projeto era experiência do usuário > facilidade de operação > facilidade de desenvolvimento, priorizando escolhas simples de operar como htmx·hyperscript, app Web monolítico, SQLite, Python e extensões como gevent e Huey
- No uso real, foram adicionados recursos como leitura de textos dentro do app, pin para ler depois, bookmark, ordenação por frequência de publicação da fonte e marcação automática como “já visto” ao rolar a tela
- Após cerca de 3 meses de trabalho sem pressão, nasceu o feedi, e ao usá-lo por alguns meses como a “primeira página da internet”, recuperou a sensação de controle sobre as informações que consome
Redescobrindo uma forma de usar a web após o burnout
- Passou por burnout na carreira após uma sequência de projetos ruins e desilusão com a indústria de software
- Reduziu o trabalho, pediu demissão e começou tratamento, além de corrigir hábitos como alimentação, exercícios e meditação
- Ficou por um tempo longe de programação e de leituras relacionadas a software, e também deixou o Twitter, a última rede social que ainda usava
- Ao ler How to Do Nothing, voltou a olhar para o Mastodon como uma comunidade online alternativa
Os limites percebidos no Mastodon
- O Mastodon oferecia um feed cronológico sem intermediários algorítmicos, dando a sensação de retomar o controle do feed
- Pessoas que sentiam desconfortos parecidos com a indústria de software e com a web estavam revisitando elementos da web antiga como RSS, BBS, digital gardens e webrings, ou imaginando uma web mais aberta e independente
- Na prática, o objetivo de uso era mais próximo de um hub de informação do que de microblogging
- Seguia pessoas para receber notificações quando elas publicavam algo em seus sites
- Seguia bots para receber conteúdo de agregadores de links
- Depois de conhecer o conceito de social readers da IndieWeb, concluiu que a ferramenta necessária não era o Mastodon, mas sim um leitor de feeds ajustável diretamente
Objetivos de usuário para um leitor pessoal
- Queria um fluxo de conteúdo interessante sempre que abrisse o app, e não a típica lista acumulada no estilo caixa de entrada de leitores RSS
- O feed precisava misturar várias fontes
- Textos de blogs, revistas, sites de notícias e agregadores de links
- Notificações de contas pessoais em serviços como Mastodon, Goodreads e GitHub
- Era necessário customizar o parsing para criar uma aparência consistente, mesmo com formatos de dados diferentes entre as fontes
- Os recursos sociais de um leitor IndieWeb completo não faziam parte do escopo
- Abrir outra aba para comentar não era um problema
- Não havia problema em o conteúdo ficar espalhado por sites de terceiros
- O objetivo de curto prazo era verificar rapidamente se essa ferramenta poderia se tornar a principal, ou até a única, fonte de informação da web; caso contrário, o projeto seria abandonado de imediato
Princípios de desenvolvimento e escopo
- O princípio de desenvolvimento era
user > ops > dev- Na priorização do trabalho e nos compromissos de design, a facilidade de operação vinha antes da conveniência para desenvolvimento
- E acima disso vinha a experiência do usuário
- Como era um app de uso pessoal, “usuário em primeiro lugar” significava praticar dogfooding e satisfazer primeiro as próprias necessidades
- Considerava mais útil criar uma ferramenta ergonomicamente ajustada a si mesmo do que imaginar um usuário ideal
- Este projeto não deveria ser um projeto de aprendizado nem de portfólio
- O objetivo não era produtividade, mas se reconectar com o prazer de desenvolver software
- Esse prazer deveria vir menos de “construir algo” e mais de “usar algo que foi construído por si mesmo”
- Assumir um único usuário-alvo permitiu adiar várias decisões
- Autenticação, que não era necessária de imediato, ficou para depois
- Recursos muito específicos, como enviar para o Kindle, podiam ser tratados logo no início
- Era possível pressupor conhecimento de programação para coisas como customização do parser de feeds ou login no Mastodon
Escolhas de UI e arquitetura
- Para ser acessível não só no notebook, mas também no celular, precisava ser uma aplicação Web
- Era uma forma eficiente de atender os dois dispositivos com uma única interface
- Permitiria usar HTML e CSS já familiares
- O estado poderia ser salvo no servidor, resolvendo a sincronização entre dispositivos
- A UI Web precisava ser dinâmica até certo ponto, mas não havia vontade de criar um frontend separado nem aprender um framework novo
- Seguindo conselhos de boring tech e radical simplicity, procurou uma biblioteca com renderização no servidor e acabou usando htmx junto com hyperscript
- Por facilidade operacional, a implantação e a configuração local precisavam ser simples, sem pressupor infraestrutura como Docker ou Nix
- O reader IndieWeb formal descrito por Aaron Parecki é dividido em vários componentes por protocolo, como Micropub, Microsub e Webmentions, mas para uso pessoal isso só aumentaria a complexidade de desenvolvimento e operação sem grandes benefícios
- Como resultado, escolheu uma aplicação Web monolítica, usando SQLite para reduzir a quantidade de componentes a instalar e configurar
Linguagem e tarefas em segundo plano
- Go parecia combinar bem com o projeto por ser simples e geral, ter garbage collection, ser rápida o suficiente, oferecer um bom modelo de concorrência e gerar binários fáceis de implantar
- Mas nunca havia escrito uma única linha em Go, e não queria que o projeto virasse um projeto de aprendizado
- Escolheu Python, a linguagem familiar com a qual conseguiria prototipar mais rapidamente
- O ponto fraco do Python continuava sendo o ambiente e as dependências, especialmente as dependências de bibliotecas do sistema operacional hospedeiro
- Não queria aumentar o número de componentes separados apenas para fazer polling periódico dos feeds, então, depois de pesquisar, passou a executar tarefas em segundo plano dentro do próprio processo da aplicação usando gevent e a extensão mini-huey do Huey
- Em compensação, Python tinha boas bibliotecas para HTTP, parsing de feeds e scraping
Por que os testes foram adiados
- No início, decidiu não escrever testes
- Como o plano era experimentar adicionando, removendo e reorganizando funcionalidades, considerou que o custo de manutenção de testes unitários seria maior do que o valor gerado
- Pequenos bugs de lógica eram aceitáveis e, como usava o app todos os dias, esperava que bugs importantes aparecessem com o tempo
- Via mais valor em testes de integração para passar confiança, mas muitos dos bugs desse projeto vinham da integração com fontes externas e da UI
- Testes de integração até poderiam ter detectado alguns bugs e regressões mais cedo, mas concluiu que isso não justificava o custo inicial
Como o uso real guiou as funcionalidades
- O uso diário como usuário final determinava ideias, experimentos e prioridades
- Depois de testar vários layouts de UI e funcionalidades, um padrão de uso acabou se consolidando
- Abrir o app
- Rolar o feed principal
- Dar pin nos itens para ler depois
- Abrir os itens para ler agora
- Dar bookmark nos itens para consultar mais tarde
- Queria ler os textos sem sair do app, em parte para evitar paywalls e pop-ups de consentimento
- Tentou várias bibliotecas Python para extrair conteúdo HTML, mas nenhuma funcionou tão bem quanto o readability usado pelo Firefox
- Como o readability é um pacote JavaScript, Node.js acabou sendo adicionado como dependência opcional
Ordenação do feed e marcação de “já visto”
- Mesmo depois de implementar os recursos básicos, ordenar apenas por data de publicação não facilitava encontrar conteúdo interessante
- Um post raro de blog ficava enterrado atrás de toots do Mastodon
- Um texto longo de revista ficava enterrado atrás de notícias diárias
- Como todas as fontes seguidas eram de interesse, assumiu que queria ver primeiro o conteúdo de fontes com menor frequência de publicação
- Se uma newsletter mensal tivesse saído nos últimos dias, ela deveria aparecer acima de microblogging ou notícias diárias
- Classificou as fontes em “frequency buckets” e passou a ordenar o feed para mostrar primeiro os buckets menos frequentes
- Para evitar que conteúdos raros ficassem sempre grudados no topo toda vez que o app fosse aberto, adicionou uma função que marca automaticamente itens como “already seen” conforme a rolagem avança
- Assim, passou a ver sempre conteúdo novo sem perder atualizações raras
Do ambiente local ao VPS
- No começo, desenvolvia e usava o app ao mesmo tempo, executando-o em uma aba do terminal do notebook
- Quando começou a gostar do conteúdo exibido no feed, colocou a aplicação em um servidor Raspberry Pi na rede local para deixá-la sempre acessível
- O uso contínuo no Raspberry Pi levou a melhorias no rendering mobile para acesso pelo celular
- Quando começou a sentir falta do app até mesmo fora de casa, fez o deploy em um VPS
- O deploy no VPS forçou a adicionar autenticação e suporte a múltiplos usuários, que haviam sido adiados, e tornou possível dar acesso de beta test a alguns amigos
- A configuração do VPS também motivou a compra de um domínio e a criação deste site, aproximando o projeto do ideal IndieWeb que o inspirou no início
O resultado do feedi
- Após cerca de 3 meses de trabalho sem pressão, criou o leitor de feeds pessoal feedi
- O feedi está mais para uma ferramenta que vai se moldando ao uso, como uma configuração do Emacs meio quebrada para sempre, do que para um produto acabado
- Do ponto de vista da produtividade, é difícil justificá-lo, mas ele traz satisfação por ser uma ferramenta feita sob medida para as próprias condições de uso
- Durante alguns meses, usou o feedi como a “front page of the internet”
- Ao usar um leitor pessoal, voltou a controlar as informações que consome, a procurar ativamente blogs e revistas interessantes e a se expor mais à descoberta e à surpresa
1 comentários
Opiniões no Hacker News
Foi bem divertido configurar o urlwatch(https://urlwatch.readthedocs.io/en/latest/). Especialmente quando você passa do boilerplate do Puppeteer e consegue raspar sites JavaScript com uma instância do Chrome, dá a sensação de controlar a web fazendo-a vir até você, em vez de você ter que puxá-la
O poder de monitorar sites sem esforço e dar uma olhada de manhã é enorme. Dá para acompanhar vagas em empresas de que você gosta, vagas/encerramentos na empresa atual, produtos em promoção·reposição·recondicionados que você está esperando, estatísticas de esgoto sobre Covid, imóveis para alugar/comprar, releases do GitHub de interesse e até mudanças nos termos de sites importantes
Pessoalmente, também faço self-hosting de um leitor RSS e de um bot do Telegram, e costumo criar pequenos sites HTTP experimentais, então uso um DigitalOcean $5 Droplet, mas isso também poderia rodar em um notebook, já que não precisa executar todos os dias no mesmo horário
Como é para uso pessoal, só recebo resumos de atualizações do Twitter sobre temas de interesse e consigo evitar o próprio site, discussões tóxicas e anúncios irritantes
Estou tão irritado com o estado atual da TI que é difícil organizar direito, mas às vezes imagino o conceito de “meu responsável de TI”. Seria alguém que cuida de parte da sua vida digital, como o barbeiro do bairro, o médico de família, o alfaiate ou o padeiro
Teria uma pequena infraestrutura local, criaria feeds personalizados, cuidaria da privacidade e do bem-estar digital e conectaria tudo a um leitor de feeds por meio de interfaces simples ou protocolos abertos. Poderia abranger filmes, textos, memes e vídeos interessantes, mas o ponto central seria haver um ser humano com quem conversar, não um algoritmo de otimização de receita
Também penso em ideias como datacenters operados pela comunidade local, como bibliotecas, ou serviços simples de conteúdo oferecidos pela internet doméstica. Por isso gostei de propostas como o Veilid(https://gitlab.com/veilid/veilid)
Não é a primeira vez que ouço alguém dizer que ficou mais saudável depois de migrar para o Fediverse. Eu mesmo tenho colocado scripts e miniapps em cima do Puppeteer, rodando resumos e recomendações com llamacpp local, e quero refinar isso mais para recomendar a amigos e familiares
Chamei esses scripts de “not a browser”. Quero uma web que não sirva HTML/CSS/JS junto com dados, mas que forneça apenas os dados e deixe o usuário decidir como exibí-los
Não há algoritmos hostis ao usuário nem sistemas baseados em anúncios; em geral são softwares que priorizam o usuário e falam em protocolos abertos. Para quem está no setor de TI e consegue operar o próprio servidor, isso é possível, mas a questão é o que acontece com quem não consegue
A ideia de um “responsável de TI” pessoal é interessante. Fico pensando se seria possível oferecer esse tipo de serviço a pessoas que querem se afastar das big techs e dos algoritmos e usar algo mais pessoal, mas não têm os meios técnicos
Dados médicos são parecidos. Não gosto que meus prontuários estejam armazenados no MyChart e em vários sistemas proprietários, sem que eu tenha controle. Tenho um supercomputador no bolso; por que não posso guardar eu mesmo uma cópia dos meus registros e compartilhá-los seletivamente com o médico durante uma consulta?
Também é estranho que hospitais ainda precisem trocar fax entre si. Eu deveria poder compartilhar meus dados com um botão. O Apple Health é o que mais se aproxima de parte disso, mas a adoção nos EUA parece quase inexistente e, mesmo assim, só favorece usuários da Apple. Dados de saúde não deveriam ficar presos em sistemas proprietários, mesmo que assumam uma forma como o Apple Health rodando localmente; precisamos de protocolos abertos e de um ecossistema de implementações
Houve um breve período bom antes de marketing e ganância tomarem conta da internet. Algo como um Synology NAS com apps úteis para o usuário final, acompanhado por “meu responsável de TI”, talvez funcionasse bem
Se não for uma estrutura feita para extrair dados pessoais e dinheiro, para o usuário seria quase uma utopia, mas a viabilidade econômica provavelmente seria a de um negócio com margens baixas e riscos altos. Por exemplo, a responsabilidade por perda de arquivos é um grande problema
A estrutura é escrever o código uma vez e executá-lo um milhão de vezes quase sem custo adicional. Todas as forças estruturais parecem atuar na direção oposta. Talvez se torne mais possível depois que a IA substituir todos os nossos empregos
How to Do Nothing, de Jenny Odell, é um livro realmente excelente. Talvez seja um pouco diferente do público típico do Hacker News, mas recomendo muito para quem começou a sentir a pressão da falsa “produtividade” imposta pela economia da atenção
Outros projetos de Jenny Odell também valem a pena. Por exemplo, The Bureau of Suspended Objects(https://www.jennyodell.com/bso-cjm.html)
No mesmo contexto, também recomendo Saving Time, de Jenny Odell. É um livro discreto, mas muito radical, e pessoalmente achei melhor que os dois. A narrativa era mais focada
Além de um simples feed pessoal, eu queria um feed com limite de tempo e sem distrações
Seria bom reunir todo o conteúdo escrito que eu sigo e escolher uma combinação de itens que dê cerca de 30 minutos de leitura por dia. Deve incluir tudo: posts de blogs, artigos, tweets etc.
Usando ChatGPT ou outra ferramenta, gostaria de filtrar o conteúdo mais “nutritivo” e priorizar o que tem mais valor do que bate-boca. Depois, quero enviar para um Kindle ou tablet reMarkable e ler longe das cores, piscadas e da internet rápida
Como próximo passo, gostaria de assinar o feed de amigos e receber de vez em quando conteúdos “convidados” desse feed
Gosto da ideia de adicionar resumos com GPT e, se outras pessoas também tiverem interesse, posso organizar e compartilhar. Por enquanto é um app JavaScript simples que uso localmente, mas a ideia está parecendo mais interessante do que eu imaginava no começo
Acho que era Douglas Engelbart, mas não consigo encontrar material sobre agentes. Talvez tenha sido outro especialista em tecnologia
Chamou minha atenção, e me identifiquei, a decisão consciente de não fazer testes automatizados logo de início. Demorei bastante para superar a sensação incômoda de não escrever testes, mas em projetos pessoais de brincadeira hoje adoto uma abordagem parecida
Projetos demais morreram mais ou menos no primeiro dia. Era justamente quando eu deveria ganhar impulso, mas eu perdia a motivação criando infraestrutura de testes e pipelines de CI
Agora trabalho com o critério de adicionar testes só quando a falta de testes vira um problema real
O que é essencial em um projeto maduro, com muitos desenvolvedores e uma base de código grande, pode ser um estorvo em um projetinho individual
Depois, concentro-me em adicionar testes pontuais sempre que surge um problema
Alguns anos atrás, fiz como projeto pessoal um analisador de gases respiratórios e escrevi um software que se conectava por Bluetooth para exibir dados em tempo real. Testes unitários foram muito úteis para funções que precisavam fazer cálculos científicos com precisão, mas, olhando para trás, testar outras partes da interface foi quase perda de tempo
Quando fiquei confiante de que as funções não mudariam mais, removi todos os testes. Quando se desenvolve sozinho, testes manuais podem ser suficientes
Criei uma nova conta anônima para falar com sinceridade sobre o futuro
Fiquei surpreso porque este texto pareceu escrito pelo meu eu do futuro. Tenho tantas coisas em comum com o autor que foi difícil acreditar
Eu tinha percebido meu burnout e estava planejando largar o trabalho no começo do ano que vem. Foi por isso também que criei uma conta anônima. Provavelmente há muita gente se sentindo de forma parecida
O mais surpreendente é que o que o autor fez é quase igual ao que eu fantasiava fazer enquanto estivesse de pausa. Eu vinha pensando em como participar da web aberta/IndieWeb e planejava criar um app para experimentar nessa área
Até as preocupações técnicas eram parecidas, como o problema de publicações raras ficarem soterradas no meio da enxurrada, ou que linguagens e tecnologias usar. Estou uns 10 anos atrasado em desenvolvimento web, mas também pensei em criar algo com tecnologias web modernas
Por um lado, fico feliz porque sinto que meus pensamentos e emoções recentes foram validados. Parece que estou no caminho certo. Por outro, fico chateado porque o autor fez primeiro, e também sobra um pouco de inveja
Na época, eu queria meu próprio leitor de RSS. Não gostava dos leitores existentes; queria um leitor que não parecesse uma caixa de entrada, mas um blog comum, e que eu pudesse desenhar do meu jeito. Então criei um parser de feeds RSS e o desenhei para parecer meu blog normal
Depois alterei para buscar o texto completo quando o feed RSS trazia só um resumo. Eu não queria clicar para fora do leitor para ver o artigo inteiro; queria tudo dentro do leitor de feeds. Quando passei a ter um scraper básico de páginas, usei também em sites sem RSS, e isso foi especialmente útil quando as redes sociais ficaram populares
Eu podia ver no meu feed apenas o conteúdo que queria, sem precisar ir aos sites sociais de fato. Como é algo de 20 anos, usa tecnologias antigas como PHP e XSLT, e ainda continua assim
De todo modo, recomendo muito fazer o seu próprio. É um projeto divertido. É velho, tosco, e o scraping não é perfeito, então às vezes o conteúdo que eu quero não aparece, mas é meu, e gosto dele por ser o leitor que uso todos os dias há 20 anos
Não há motivo para uma tentativa parecida não funcionar. Ele também não foi a primeira pessoa a implementar um leitor pessoal
O interessante é que, ao reler rapidamente o artigo da IndieWeb que eu tinha linkado, tive a sensação de que repeti quase exatamente as ideias dele. Algo como: “não tente criar software para todo mundo; crie para você mesmo”
Se você tenta torná-lo genérico e fácil para outras pessoas usarem, pode acabar fazendo concessões que prejudicam sua própria usabilidade, ou projetando para usuários imaginários que nem existem. A ideia é criar de forma egoísta, para que seja mais útil para você
Foi realmente revigorante. Ao longo do último ano, passei por um caminho muito parecido de burnout/recuperação, e criar software pessoal útil me fez voltar a gostar do trabalho
Outro grande benefício é poder experimentar à vontade as tecnologias “não ortodoxas” que você quiser. Coisas como criar um executável PHP moderno em binário único, usar SQLite em produção, fazer deploy sem Docker me dão prazer
Esse trabalho também teve efeito indireto no meu emprego. Muitas vezes descubro novas técnicas e otimizações nos meus repositórios pessoais e as levo para o trabalho
É interessante como pessoas técnicas frequentemente mexem em coisas por fora e levam o que aprenderam para o trabalho de formas úteis e, às vezes, valiosas. Mas empregadores às vezes desvalorizam esse esforço ou bloqueiam esse entusiasmo
Talvez eu tenha trabalhado no tipo errado de organização. Ainda assim, fico feliz que você tenha colhido os benefícios desse efeito indireto
Gosto mais da mentalidade de feed do que de uma checklist do que ler/consumir. Usei alguns leitores de RSS ao longo dos anos, mas nunca fiquei com nenhum por muito tempo
Ficava pensando se eu realmente precisava gerenciar mais uma caixa de entrada. Mesmo assim, pretendo dar uma olhada no feedi (https://github.com/facundoolano/feedi)
Antes de configurar isso, eu ficava clicando sem rumo de um lado para outro pensando se havia algo novo no HN, ou na Reuters. Minha experiência bate com https://news.ycombinator.com/item?id=38642092
E-mail pessoal, listas de e-mail e feeds RSS ficam todos reunidos em um só lugar. Filtrando para spools separados e usando junto um cliente de e-mail poderoso como o mutt, vira uma experiência integrada bem agradável
O autor parece ter adicionado autenticação para acessar o app de qualquer lugar
Fico imaginando se, em vez disso, seria possível ou mais fácil colocá-lo numa VPN e tornar essa VPN acessível de qualquer lugar
Quero acessar webapps pessoais com segurança, mas estou procurando a abordagem mais simples. Toda vez que olho para autenticação, parece um labirinto de conceitos, protocolos e bibliotecas, e não quero ficar fazendo manutenção disso
Hospedei alguns apps como o Home Assistant em um Raspberry Pi em casa e instalei o Tailscale nesse Pi e no celular; funciona muito bem. A única autenticação necessária é “entrar no Tailscale em cada dispositivo”
Para montar uma rede segura com seus próprios dispositivos de forma fácil, recomendo muito o Tailscale
É suficiente para “proteger” meu aplicativo que só hospeda trechos de texto recortados de outros sites
Há várias maneiras de fazer isso, mas a ideia central é colocar o endpoint da VPN e o webapp no mesmo lugar, por exemplo na mesma máquina ou na mesma rede, e restringir o acesso ao webapp a partir de outros locais
Configurei o Caddy para fazer reverse proxy apenas de requisições vindas da rede interna ou da VPN; caso contrário, ele retorna 404. Então, se você não estiver na VPN nem na rede de casa, nada aparece
Dependendo de você deixar a rede aberta para convidados e de quais serviços roda, talvez precise de VLANs ou de uma rede de convidados separada. Muitos serviços que rodo em casa também têm autenticação própria por senha, e uso isso junto com a restrição por VPN
Essa configuração foi a primeira que me ocorreu, então pode não ser segura por motivos fora da minha área de especialidade. A vantagem é que também rodo o Pi-hole no mesmo arquivo compose; assim, quando o celular se conecta à VPN, ganho bloqueio remoto de anúncios “de graça”
O Tailscale é mais fácil de configurar e tem uma UI melhor, mas no iOS consumia muita bateria, então parei de usar. A necessidade de “confiar no servidor de outra pessoa” também é um problema, mas, se não fosse a questão da bateria, eu provavelmente aceitaria o risco adicional pela conveniência
O app do WireGuard também tem um recurso conveniente. Dá para definir que ele não rode em certas redes, como quando estou em casa; assim, ele liga automaticamente quando saio e desliga quando volto
Isto é surpreendentemente próximo do que eu achava que seria necessário em um iate de cruzeiro. Especialmente em alto-mar, onde a conexão é intermitente, acho que ficaria perfeito com mais duas coisas
Seria preciso poder tocar em sincronizar agora nos momentos de conexão breve, como ao passar por uma ilha com sinal LTE. Além disso, por padrão, deveria aplicar processamento tipo Readability e cache local para que todo o conteúdo, incluindo imagens, pudesse ser lido offline