Estudo de caso de um autor amador de plugins

Em 2024, eu estava em busca de trabalho. Decidi oferecer meus serviços como consultor de comunidades. No entanto, a maioria das pessoas estava mais interessada em ajuda técnica para corrigir ou atualizar seus sites Discourse. Um cliente em potencial perguntou se eu poderia adicionar um formulário de contato para que pessoas sem conta pudessem enviar feedback. Pesquisei e concluí que isso não era possível. Mas eu tinha bastante tempo livre e segui o tutorial de desenvolvedor de plugins para ver o que eu poderia fazer. Eventualmente, desenvolvi um plugin de formulário de contato e fechei o contrato com o cliente.[1]

Apenas para deixar claro para todos: eu não sou um programador de front-end! Faz 13 anos que não trabalho como programador profissional de qualquer tipo. Sei como criar um formulário HTML e isso é praticamente tudo o que sei. Então, lutei para entender a seção sobre Ember e Handlebars do tutorial e montei uma solução improvisada que funcionou bem o suficiente. Felizmente, eu estava familiarizado com sistemas de template, tendo os usado em um emprego anterior.

Consegui um emprego na Fundação OpenSSL[2] e praticamente abandonei meus clientes. Mas o cliente para quem criei o plugin me manteve em regime de retenção porque realmente apreciava meu trabalho. (Já fiz vários projetos sem relação para ele.) Para justificar minha retenção, decidi atualizar o servidor Discourse dele. Foi isso que encontrei:

Isso só apareceu no site do meu cliente porque fui burro e instalei, mas não ativei, o plugin de contato no meu site de staging. Então, rapidamente entrei no modo seguro e desativei o plugin. No último fim de semana, passei algum tempo descobrindo o que deu errado e como poderia corrigir isso para meu cliente.

Após algumas buscas, encontrei o tópico Descontinuando a extensão de arquivo .hbs em temas e plugins:

Na versão mais recente do Discourse, o uso de arquivos .hbs em temas e plugins está descontinuado. O suporte a esse formato de arquivo será removido após o próximo lançamento ESR.

Isso foi em março, o que significa que eu deveria ter tido até basicamente o final de setembro para corrigir, se estivesse na versão ESR. Mas minha configuração do Discourse usa “tests-passed”[3], então recebi o erro alguns meses antes, imagino.

Como vou ter que corrigir de qualquer forma (ou decepcionar meu cliente), mergulhei nas instruções: Atualização automática de temas e plugins para o formato de arquivo .gjs. A primeira etapa foi instalar um ambiente de desenvolvimento, já que troquei de laptop desde a última vez que tentei isso.[4] Quando finalmente consegui executar o Discourse e verifiquei que meu plugin estava quebrado localmente, executei o processo de lint[5]:

$ pnpm eslint --fix .

/Users/jericson/src/discourse-contact-plugin/assets/javascripts/discourse/components/contact-form.js
   1:8   error  Use Glimmer components(@glimmer/component) instead of classic components(@ember/component)          ember/no-classic-components
   3:16  error  Native JS classes should be used instead of classic classes                                         ember/no-classic-classes
   3:16  error  Please switch to a tagless component by setting `tagName: ''` or converting to a Glimmer component  ember/require-tagless-components
  20:3   error  Use the @action decorator instead of declaring an actions hash                                      ember/no-actions-hash

✖ 4 problems (4 errors, 0 warnings)

Embora seja irritante ter que alterar meu plugin, pelo menos o processo de lint me ajudou a limpar e modernizar meu código. No entanto, o script automatizado falhou ao tentar converter para .gjs. Então, decidi experimentar https://ask.discourse.com/

Tenho 12 perguntas lá. Eu não compartilharia com um humano porque são apenas as lamentações de um programador cada vez mais frustrado. Em um momento, o bot sugeriu uma “abordagem moderna mais robusta” para um dos meus subproblemas que incluía… um arquivo .js e um arquivo .hbs.

Frame de 8½ em que o diretor joga fora a crítica negativa do crítico sobre 8½.

Sei por que isso acontece. O bot é treinado em discussões do Meta Discourse e ainda há muitos posts com código Handlebars, incluindo a parte dois do tutorial oficial de desenvolvedor de plugins. Isso será atualizado com o tempo, mas me preocupa que leve um pouco mais de tempo porque o conselho oficial para obter ajuda com a atualização é perguntar ao chatbot em vez de perguntar no Meta Discourse.

Acho que não deveria reclamar; ele me ajudou a organizar meu código e provavelmente com menos atrito do que perguntar a humanos.

Estabilidade da plataforma

Então, agora trabalho para a Fundação OpenSSL. Você provavelmente conhece a OpenSSL por causa do Heartbleed. É usada em todo lugar. A versão mais popular para baixar é a 1.1.1, que atingiu o fim da vida útil em 2023. A próxima mais popular é a 3.0, lançada em 2021, mas ainda é suportada como uma versão de Suporte de Longo Prazo (LTS). Em seguida, temos a 3.5, nossa mais recente LTS. Essas três versões representam quase 2/3 dos downloads do GitHub.

Isso é um pouco decepcionante porque a 3.5 tem alguns recursos novos legais. Mas, no final, os recursos que as pessoas mais se importam são uma combinação de SSL/TLS e primitivas criptográficas. A menos que você esteja animado com algoritmos criptográficos pós-quânticos, você vai adiar a dor de atualizar o máximo possível.

O OpenSSL está muito mais abaixo na pilha do que o Discourse, claro. Mas o princípio é o mesmo. A menos que haja um novo recurso, as pessoas não estão interessadas em atualizações que quebram funcionalidades. Sei que vocês estão animados com os novos recursos que foram adicionados ao Discourse. Entendo querer alterar uma API para obter algumas otimizações depois. Só me preocupo que mudar muito rápido prejudique o Discourse como plataforma na qual comunidades são construídas.

Falando nisso, há um slide deck muito útil chamado Gardening Platforms, escrito por Alex Komoroske. O slide 90 inicia uma seção chamada “Plataforma + Ecossistema” que explica como as plataformas devem coevoluir com seus ecossistemas. Neste caso, o Discourse é a plataforma que suporta um ecossistema de designers de plugins e temas, serviços de hospedagem, a comunidade Meta Discourse e até mesmo as comunidades construídas no Discourse. Uma percepção importante nas anotações do palestrante do slide 98:

Mas eles não são independentes; eles estão relacionados simbioticamente.

Ações que acontecem em um influenciam o outro, e vice-versa. Pense nisso como loops de feedback conectando-os em ambas as direções.

Eles não estão rigidamente ligados; é mais como um elástico ligando-os. É uma atração gravitacional.

Se uma plataforma e um ecossistema se movem muito rápido em relação um ao outro, o vínculo se rompe com efeitos desastrosos. Confio que o Discourse fará o certo pelo ecossistema. É só que, para mim, fins de semana como o último enfraqueceram essa confiança.


  1. Estou moderadamente orgulhoso do meu trabalho, mesmo que tenha acabado sendo um site bastante estático. ↩︎

  2. Presságio! ↩︎

  3. Isso também precisa ser atualizado ↩︎

  4. Redis e Rails foram mais difíceis de instalar do que eu lembrava. ↩︎

  5. Não antes de gastar muito tempo tentando baixar eslint.config.mjs, no entanto ↩︎

Acho que você recebeu o erro por causa desse bug, e não porque seu plugin precisava de uma atualização agora.

Eu passei pela mesma coisa com muitos plugins que havia desenvolvido. Não tinha disponibilidade para modernizá-los ao padrão do Discourse. Tenho um trabalho na área de ciência de dados, então, embora conheça conceitos de engenharia de software, não acompanho os detalhes específicos do desenvolvimento web. No final, não atualizei meu site por 8 meses porque ele dependia desses plugins desatualizados.

Não quero minimizar sua dificuldade, mas basicamente acho que, com o surgimento da programação agêntica, esse ritmo de desenvolvimento se tornou um problema irrelevante. O que levaria uma ou duas semanas para eu codificar e ajustar corretamente agora exige apenas uma assinatura de US$ 20 do Claude Code e alguns minutos por plugin. Além disso, também consegui otimizá-los em termos de desempenho. Depois de usar programação agêntica em alguns projetos profissionais e pessoais, não acho que voltarei a codificar algo do zero novamente na minha vida. É como a diferença tecnológica entre escrever e entregar uma carta à mão versus enviar um e-mail. É um pouco triste, mas, ao mesmo tempo, parece que você recebeu poderes de nível divino.

Parece bem provável. Migrar para a versão mais recente do ESR (e ser um pouco mais vigilante nos testes) parece um bom plano a partir de agora.

Não acho que o ritmo de desenvolvimento seja um problema per se. É o ritmo de tudo. Por que, por exemplo, o tutorial do plugin não foi atualizado? É uma mina prestes a explodir na cara de algum coitado que queira criar um plugin. Funcionará por enquanto, mas eventualmente eles enfrentarão o mesmo problema que eu. A solução não é usar IA para corrigir o plugin depois, mas corrigir as instruções sobre como criar um plugin agora. Quero dizer, não há motivo para continuar ensinando a maneira antiga de fazer as coisas, há?

porque somos uma equipe bastante pequena mantendo uma base de código enorme e tendo que implementar novos recursos para clientes pagantes, ao mesmo tempo em que fornecemos suporte e mantemos tudo funcionando para nossa comunidade de código aberto.

Há um limite do que podemos fazer em um dia, e a documentação frequentemente fica para trás.

Compreendo muito bem suas frustrações, mas acho que esse ponto merece ser mencionado também.

Obrigado pelas informações detalhadas, @jericson. Como você disse, o Discourse está em uma posição muito diferente do OpenSSL, tanto em termos de uso quanto de posição na pilha. É um equilíbrio constante entre progresso, personalização e estabilidade. Não existe uma solução perfeita que deixe todos satisfeitos, mas sempre levamos em consideração o feedback de nossos clientes e da comunidade de código aberto. Gosto muito da citação que você compartilhou:

:chefs_kiss:

Como @moin mencionou, a experiência que você teve com a descontinuação do .hbs foi um bug na versão latest por cerca de uma semana. Muito desculpas por isso! Embora o uso do .hbs esteja descontinuado, ele ainda é suportado. Seu código .hbs deve estar funcional novamente agora.

Obrigado por destacar isso. Fiz uma revisão para limpar as menções restantes do .hbs na documentação:

Entendo perfeitamente.[1] Eu realmente gosto do Discourse e escrevi este post porque quero que o Discourse tenha sucesso contínuo.

Uma coisa que aprendi é que as comunidades não gostam de mudanças, mas estão muito mais abertas a elas se sentirem que têm agência. Existem inúmeras maneiras de dar agência às pessoas. Por exemplo, o tutorial poderia ser transformado em posts de wiki para que pessoas como eu possam atualizá-los. Implementar o plano ESR também ajuda, pois dá às pessoas a opção de não fazer mudanças imediatamente.^[Menos útil para autores de plugins que desejam apoiar comunidades que querem permanecer na vanguarda. Mas será ótimo para mim, já que acredito que sou a única pessoa usando meu plugin.) Poder registrar minha experiência e ter isso visto por pessoas que gerenciam o projeto de código aberto também ajuda. Especialmente porque as coisas das quais reclamei foram corrigidas durante a noite. :wink:

Em “Escutar usuários é prejudicial?”,[2] Kathy Sierra escreveu:

A maioria de nós percebe que grupos de foco são notoriamente ineficazes para muitas coisas, mas ainda assumimos que ouvir feedback real de usuários reais é a melhor maneira de impulsionar novos produtos e serviços, bem como melhorar o que já temos. Mas há um grande problema nisso – as pessoas não necessariamente sabem como pedir algo que nunca conceberam! A maioria das pessoas faz sugestões baseadas inteiramente em melhorias incrementais, olhando para o que existe e pensando em como poderia ser melhor. Mas isso é bastante diferente de ter uma visão para algo profundamente novo.

A verdadeira inovação raramente virá do que os usuários dizem diretamente.

Como disse, não sou desenvolvedor frontend. Não entendo muito bem por que essas mudanças foram feitas ou como elas me beneficiarão.[3] E isso é ok se, eventualmente, elas tornarem o Discourse melhor.

Ainda assim, pode ajudar pessoas como eu a ficarem a bordo se eu puder ver a visão um pouco mais claramente. Para essa mudança, a proposta é:

  1. uma experiência de desenvolvimento muito melhor
  2. permitirá grandes melhorias de desempenho em futuras versões do Discourse

Parece bom, suponho? Eu não percebi particularmente o #1 e o #2 poderiam significar muitas coisas. Seria mais eficaz para mim algo como (e estou totalmente inventando isso):

  1. Quando convertemos os plugins oficiais do Discourse, descobrimos que isso reduziu X% das linhas de código. Ao colocar o template no mesmo arquivo que o JavaScript, o código fica mais fácil de entender e modificar no futuro.
  2. Criamos uma branch testando a remoção completa do Handlebars e descobrimos que essa mudança tornou o carregamento das páginas X% mais rápido. Além disso, identificamos uma otimização potencial que poderia eliminar [algum problema que os usuários levantaram].

Um pouco mais de detalhes com foco em educar não especialistas vai longe para manter a confiança. Eu posso não gostar das mudanças, mas como posso argumentar contra a correção de problemas reais que outros usuários enfrentaram?


  1. O OpenSSL tem uma dinâmica similar. Temos uma Corporação (~15 pessoas) que vende contratos de suporte e uma Fundação (10 pessoas, incluindo eu) que cuida dos interesses não comerciais. Nossa documentação também fica defasada. Enquanto escrevia o post original, notei que ainda temos referências a recursos que foram removidos no mês passado. Estou trabalhando em um PR para isso. E fizemos algumas mudanças que projetos downstream foram altamente críticos. ↩︎

  2. O blog dela sumiu da internet, mas há um arquivo PDF. ↩︎

  3. Não que eu realmente importe tanto assim na grande esquema das coisas. Estou falando de mim como representante de outras pessoas que dependem do Discourse. Afinal, conheço a mim mesmo melhor do que a maioria! ↩︎

Por que precisa ser um wiki para isso? A documentação para desenvolvedores é gerenciada via GitHub. Gosto ainda mais do processo onde as alterações são revisadas do que em um wiki.

Concordo que a documentação do plugin deve ser atualizada neste momento. O objetivo do período de “descontinuação”, onde os plugins ainda funcionam, mas o site exibe um aviso de que eles deixarão de funcionar em breve, é dar tempo suficiente aos autores dos plugins para corrigi-los. No entanto, nesse mesmo período, uma equipe de desenvolvedores remunerados em tempo integral não conseguiu atualizar a documentação central de desenvolvimento de plugins. É uma expectativa estranha impor isso a desenvolvedores individuais quando uma equipe não consegue gerenciar totalmente a mesma tarefa no mesmo período.

Isso me sinaliza que a velocidade de desenvolvimento é muito alta e/ou que os autores de plugins não são uma prioridade significativa para o Discourse. Pessoalmente, sinto que é mais o segundo caso. Entendo que algo precisa ser deixado de lado, então isso é uma observação minha, e não uma crítica. O Discourse permanece totalmente personalizável por meio de plugins, e agradeço pelas melhorias contínuas.

Dito tudo isso, acho que chegamos a um momento em que um guia de documentação passo a passo para criar um plugin boilerplate é uma ideia obsoleta. Um único documento de contexto para um agente ler e construir um esqueleto de plugin é tudo o que é necessário agora para um autor de plugins amador. Na verdade, para uma base de código de código aberto como o Discourse, a documentação nem é necessária, já que os agentes obtêm contexto diretamente da própria base de código. Quando estava trabalhando nos meus plugins, vi o Claude lendo os plugins existentes como uma forma de aprender os padrões de design. E até consegui identificar um bug no código principal: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time

Basicamente, para qualquer pessoa que esteja lendo isso e aspire a ser um autor de plugins amador, a documentação pode estar desatualizada, mas criar um plugin é 1000 vezes mais fácil do que nunca foi antes.

Apenas para esclarecer esse ponto: a cronograma de depreciação para hbs começou recentemente. A data mais cedo em que consideraremos remover o suporte é após o próximo ESR (final de julho). Então, sim, deveríamos ter atualizado a documentação antes, mas isso não é um caso de “remover o suporte sem aviso suficiente”. .hbs ainda é suportado, e há tempo suficiente para fazer as alterações necessárias.

Mantemos mais de 600 temas e plugins, então posso garantir que também “sentimos a dor” dessas migrações. Fazemos o nosso melhor para tornar as alterações o mais suaves possível para todos e continuaremos aprendendo com cada mudança que fizermos.

:100: Exato

Ainda não temos exatamente isso. Mas estamos começando a construir um diretório de habilidades no repositório principal. Além disso, toda a documentação de desenvolvimento em markdown foi movida para o repositório principal, em parte para facilitar a referência por agentes de IA.

Pode ser que eu esteja confundindo as coisas na minha cabeça, já que corrigi meus plugins tanto para a atualização do Ember 6 (o grande bloqueio de atualização para mim) quanto migrei do hbs ao mesmo tempo. Desculpe se eu fui muito assertivo!

Mas acho que, se o Discourse quisesse expandir o ecossistema de plugins feitos por usuários, um tutorial moderno de “vibecoding” seria útil. Mas, por outro lado, seria desejável abrir as comportas para uma onda de plugins feitos com vibecoding? Difícil dizer :smile:

Ah! Isso ajuda. PR enviado.

Sou fã de colocar documentação no GitHub. Enviar alterações dá bastante mais trabalho do que editar uma postagem de wiki, mas a etapa de revisão é útil. (E, para a documentação de autores de plugins, exigir conhecimento de Git não é um obstáculo tão alto.)