Кейс-стади автора плагина-любителя

В 2024 году я искал работу. Я решил предложить свои услуги в качестве консультанта по сообществам. Однако чаще всего люди интересовались технической помощью в исправлении или обновлении своих сайтов на Discourse. Один потенциальный клиент спросил, могу ли я добавить форму обратной связи для пользователей без аккаунта. Я изучил вопрос и пришёл к выводу, что это невозможно. Но у меня было много свободного времени, и я последовал руководству для разработчиков плагинов, чтобы посмотреть, что я могу сделать. В конце концов я разработал плагин формы обратной связи и подписал клиента.[1]

Давайте сразу проясним: я не фронтенд-программист! Прошло 13 лет с тех пор, как я работал профессиональным программистом любого рода. Я умею создавать HTML-формы, и это практически предел моих знаний. Поэтому я с трудом справлялся с разделом про Ember и Handlebars в руководстве и собрал кое-как работающее решение. К счастью, я был знаком с системами шаблонов, так как использовал их на предыдущей работе.

Я устроился на работу в Фонд OpenSSL[2] и в основном отказался от своих клиентов. Но клиент, для которого я написал плагин, оставил меня на ретейнере, потому что очень ценил мою работу. (Я выполнил для него несколько не связанных друг с другом проектов.) Чтобы оправдать ретейнер, я решил обновить его сервер Discourse. Вот что я увидел:

Это отображалось только на сайте моего клиента, потому что я был глуп и установил, но не активировал плагин обратной связи на моем тестовом сайте. Поэтому я быстро перешел в безопасный режим и отключил плагин. В прошлые выходные я потратил время на то, чтобы разобраться, что пошло не так, и как я могу это исправить для своего клиента.

После некоторых поисков я нашел тему Устаревание расширения файлов .hbs в темах и плагинах:

В последней версии Discourse использование файлов .hbs в темах и плагинах устарело. Поддержка этого формата файлов будет удалена после следующего релиза ESR.

Это было в марте, и это означало, что у меня было время до конца сентября, чтобы исправить это, если бы я использовал релиз ESR. Но моя конфигурация Discourse использует “tests-passed”[3], поэтому, видимо, я получил ошибку на несколько месяцев раньше.

Поскольку мне все равно придется это исправить (или подвести клиента), я приступил к инструкциям: Автоматическое обновление тем и плагинов до формата файлов .gjs. Первым шагом было установка среды разработки, так как я сменил ноутбук с тех пор, как в последний раз пробовал это сделать.[4] Когда я наконец запустил Discourse и убедился, что мой плагин сломан локально, я запустил процесс линтинга[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)

Хотя менять плагин раздражает, по крайней мере процесс линтинга помог мне очистить и модернизировать код. Однако автоматический скрипт не справился с конвертацией в .gjs. Поэтому я решил попробовать https://ask.discourse.com/

У меня там 12 вопросов. Я бы не поделился ими с человеком, потому что это просто отчаянные попытки все более разочарованного программиста. В какой-то момент бот предложил «более надежный современный подход» к одной из моих подзадач, который включал… .js файл и .hbs файл.

Кадр из фильма 8½, в котором режиссер выбрасывает негативный отзыв критика на 8½.

Я понимаю, почему это происходит. Он обучен на обсуждениях Meta Discourse, и там до сих пор много постов с кодом на Handlebars, включая вторую часть официального руководства для разработчиков плагинов. Это со временем обновится, но я беспокоюсь, что это займет немного больше времени, потому что официальный совет по получению помощи при обновлении — обращаться к чат-боту, а не задавать вопросы на Meta Discourse.

Думаю, мне не стоит жаловаться; это помогло мне разобраться в коде, вероятно, с меньшими трудностями, чем если бы я обращался к людям.

Стабильность платформы

Итак, я теперь работаю в Фонде OpenSSL. Вы, наверное, знаете об OpenSSL из-за Heartbleed. Он используется повсеместно. Самая популярная версия для скачивания — 1.1.1, которая достигла конца срока поддержки в 2023 году. Следующая по популярности — 3.0, выпущенная в 2021 году, но все еще поддерживаемая как релиз с долгосрочной поддержкой (LTS). Далее идет 3.5 — наш последний LTS. Эти три версии составляют почти 2/3 загрузок с GitHub.

Это немного разочаровывает, потому что в 3.5 есть несколько крутых новых функций. Но в конечном итоге функции, которые людям важнее всего, — это какая-то комбинация SSL/TLS и криптографических примитивов. Если вас не волнуют постквантовые криптографические алгоритмы, вы будете откладывать болезненное обновление как можно дольше.

Конечно, OpenSSL находится намного ниже в стеке, чем Discourse. Но принцип тот же. Если нет новой функции, людям не интересны разрушительные обновления. Я знаю, что вы рады новым функциям, добавленным в Discourse. Я понимаю желание изменить API ради последующей оптимизации. Я просто беспокоюсь, что слишком быстрое движение навредит Discourse как платформе, на которой строятся сообщества.

Кстати, есть очень полезная презентация под названием Gardening Platforms, написанная Алексом Комороске. Слайд 90 начинает раздел под названием «Платформа + Экосистема», который объясняет, как платформы должны совместно развиваться со своими экосистемами. В данном случае Discourse — это платформа, поддерживающая экосистему разработчиков плагинов и тем, хостинг-сервисов, сообщества Meta Discourse и даже самих сообществ, созданных на Discourse. Важное замечание в заметках спикера к слайду 98:

Но они не независимы; они связаны симбиотически.

Действия, происходящие в одной, влияют на другую, и наоборот. Представьте это как петли обратной связи, связывающие их в обоих направлениях.

Они не жестко связаны, это скорее как резинка, связывающая их. Это гравитационное притяжение.

Если платформа и экосистема движутся слишком быстро друг относительно друга, связь разрывается с катастрофическими последствиями. Я доверяю Discourse поступать правильно по отношению к экосистеме. Просто в прошлые выходные мне показалось, что это доверие пошатнулось.}


  1. Я довольно горжусь своей работой, даже несмотря на то, что в итоге это оказался довольно статичный сайт. ↩︎

  2. Намеки! ↩︎

  3. Это тоже нужно обновить ↩︎

  4. Установка Redis и Rails оказалась сложнее, чем я помнил. ↩︎

  5. Не без того, чтобы потратить много времени на неудачные попытки скачать eslint.config.mjs, однако ↩︎

Думаю, ошибка возникла из-за этой уязвимости, а не потому, что вашему плагину прямо сейчас нужно обновление:

Я проходил через то же самое со многими плагинами, которые написал. У меня не было ресурсов, чтобы привести их в соответствие со стандартами Discourse. Я работаю в сфере, близкой к науке о данных, поэтому, хотя мне знакомы концепции разработки программного обеспечения, я не слежу за деталями веб-разработки. В итоге я не обновлял свой сайт в течение 8 месяцев, потому что он зависел от этих устаревших плагинов.

Я не хочу преуменьшать ваши трудности, но в целом я считаю, что с появлением агентов-кодеров такая скорость разработки перестала быть проблемой. То, что раньше занимало у меня неделю или две на написание и отладку, теперь требовало подписки на Claude Code за 20 долларов и нескольких минут на каждый плагин. Более того, мне удалось оптимизировать их для повышения производительности. После того как я использовал агентов-кодеров для нескольких рабочих и хобби-проектов, я больше никогда не буду писать код с нуля. Это похоже на технологическую разницу между написанием и доставкой письма от руки и отправкой электронного письма. Это немного грустно, но в то же время кажется, будто тебе дарованы божественные силы.

Действительно, похоже на правду. Переход на последнюю ESR-версию (и более тщательное тестирование) кажется хорошим планом на будущее.

Я не думаю, что сама по себе скорость разработки является проблемой. Проблема в темпах всего. Почему, например, не обновлен урок по плагинам? Это мина замедленного действия, готовая взорваться в лицо какому-нибудь бедолаге, который захочет создать плагин. Пока всё будет работать, но рано или поздно он столкнётся с той же проблемой, что и я. Решение не в том, чтобы использовать ИИ для исправления плагина позже, а в том, чтобы прямо сейчас исправить инструкции по созданию плагинов. Я имею в виду, нет же причин продолжать учить старому способу, верно?

Потому что мы — довольно небольшая команда, поддерживающая огромную кодовую базу, внедряющая новые функции для платных клиентов и одновременно оказывающая поддержку и обеспечивающая стабильную работу для нашего сообщества с открытым исходным кодом.

В сутках есть только так много времени, и документация часто отстаёт.

Я очень хорошо понимаю ваше разочарование, но считаю, что этот момент тоже стоит упомянуть.

Спасибо за подробную информацию, @jericson. Как вы и отметили, Discourse находится в совершенно иной позиции по сравнению с OpenSSL как с точки зрения использования, так и с точки зрения своего положения в стеке. Это постоянный баланс между прогрессом, настраиваемостью и стабильностью. Не существует идеального решения, которое устроило бы всех, но мы всегда учитываем отзывы наших клиентов и сообщества с открытым исходным кодом. Мне очень нравится цитата, которую вы привели:

:chefs_kiss:

Как упомянул @moin, проблема, с которой вы столкнулись в связи с устареванием .hbs, была ошибкой в версии latest в течение примерно недели. Приносим извинения за это! Хотя использование .hbs устарело, оно всё ещё поддерживается. Ваш код .hbs должен снова работать корректно.

Спасибо, что обратили на это внимание. Я провёл работу по удалению оставшихся упоминаний .hbs в документации:

Полностью понимаю.[1] Мне действительно нравится Discourse, и я написал этот пост, потому что хочу, чтобы у Discourse был дальнейший успех.

Я усвоил одну вещь: сообщества не любят перемены, но они гораздо более открыты к ним, если чувствуют, что у них есть возможность влиять на процесс. Существует множество способов предоставить людям такую возможность. Например, руководство можно превратить в вики-посты, чтобы такие люди, как я, могли их обновлять. Внедрение плана ESR также помогает, поскольку даёт людям возможность не вносить изменения сразу.[2] Возможность описать свой опыт и донести его до людей, управляющих проектом с открытым исходным кодом, тоже помогает. Особенно учитывая, что то, на что я жаловался, было исправлено за одну ночь. :wink:

В статье «Слушать пользователей — это вредно?»[3] Кэти Сиерра написала:

Большинство из нас осознаёт, что фокус-группы во многих случаях крайне неэффективны, но мы всё ещё полагаем, что слушать реальные отзывы реальных пользователей — лучший способ создавать новые продукты и услуги, а также улучшать существующие. Но в этом есть огромная проблема — люди не всегда знают, как попросить о том, о чём они даже не задумывались! Большинство людей предлагают улучшения, основываясь исключительно на пошаговых изменениях, глядя на то, что уже существует, и размышляя, как это можно улучшить. Но это совершенно не то же самое, что иметь видение чего-то принципиально нового.

Истинные инновации редко возникают из того, что пользователи говорят напрямую.

Как я уже сказал, я не фронтенд-разработчик. Я не до конца понимаю, почему были внесены эти изменения и как они пойдут мне на пользу.[4] И это нормально, если в конечном итоге это сделает Discourse лучше.

Тем не менее, людям вроде меня будет проще принять изменения, если я смогу чуть яснее увидеть общую картину. Для этого изменения аргументация звучит так:

  1. значительно улучшенный опыт разработки;
  2. это позволит в будущих версиях Discourse добиться существенного повышения производительности.

Звучит неплохо, я полагаю? Я не особо заметил пункт 1, а пункт 2 может означать множество вещей. Для меня было бы гораздо полезнее что-то вроде (я полностью выдумываю):

  1. При конвертации официальных плагинов Discourse мы обнаружили, что это сократило количество строк кода на X%. Размещение шаблона в одном файле с JavaScript делает код более понятным и упрощает его модификацию в будущем.
  2. Мы создали ветку для тестирования полного удаления Handlebars и обнаружили, что это изменение ускорило загрузку страниц на X%. Более того, мы увидели возможность оптимизации, которая могла бы устранить [проблему, на которую жаловались пользователи].

Немного больше деталей с акцентом на просвещение неэкспертов имеет большое значение для поддержания доверия. Мне могут не понравиться изменения, но как можно спорить с исправлением реальных проблем, с которыми сталкивались другие пользователи?


  1. У OpenSSL схожая ситуация. У нас есть Корпорация (~15 человек), продающая контракты на поддержку, и Фонд (10 человек, включая меня), отвечающий за некоммерческие интересы. Наша документация тоже отстаёт. Когда я писал этот пост, я заметил, что у нас всё ещё есть ссылки на функции, которые были удалены в прошлом месяце. Я работаю над PR для исправления этого. Кроме того, мы внесли некоторые изменения, которые проекты-потребители оценили критически. ↩︎

  2. Менее полезно для авторов плагинов, которые хотят поддерживать сообщества, желающие оставаться на острие технологий. Но для меня это будет отлично, поскольку, насколько я знаю, я единственный, кто использует мой плагин. ↩︎

  3. Её блог больше недоступен в интернете, но существует архив в формате PDF. ↩︎

  4. Не то чтобы я имел большое значение в глобальном масштабе. Я говорю о себе как о представителе других людей, зависящих от Discourse. В конце концов, я знаю себя лучше, чем большинство! ↩︎

Почему для этого должна быть вики? Документация для разработчиков управляется через GitHub. Мне нравится процесс, при котором изменения проверяются, даже больше, чем вики.

Я согласен, что документацию по плагинам необходимо обновить на данном этапе. Цель периода «депрекации», когда плагины всё ещё работают, но сайт выводит предупреждение о том, что они скоро перестанут функционировать, — дать авторам плагинов достаточно времени для их исправления. Однако в этот период даже команда штатных разработчиков не смогла обновить основную документацию по разработке плагинов. Это странное требование предъявлять к отдельным разработчикам, если команда не может полностью справиться с этим за тот же срок.

Для меня это сигнал о том, что скорость разработки слишком высока и/или авторы плагинов не являются приоритетом для Discourse. Лично я считаю, что дело скорее во втором. Я понимаю, что чем-то приходится жертвовать, поэтому это моё наблюдение, а не критика. Discourse по-прежнему полностью настраивается через плагины, и я ценю непрерывные улучшения.

Тем не менее, я считаю, что мы достигли момента, когда пошаговое руководство по созданию базового плагина устарело. Теперь для начинающего автора плагина достаточно одного контекстного документа для ИИ-агента, который сможет прочитать его и создать скелет плагина. Более того, для открытой кодовой базы, такой как Discourse, документация вообще не нужна, поскольку агенты получают контекст напрямую из самой кодовой базы. Когда я работал над своими плагинами, я видел, как Claude изучал существующие плагины, чтобы понять шаблоны проектирования. Мне даже удалось найти ошибку в основном коде: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time

В общем, для любого, кто читает это и стремится стать начинающим автором плагина: документация может быть устаревшей, но создавать плагины сейчас в 1000 раз проще, чем когда-либо прежде.

Просто уточню этот момент: график устаревания hbs был запущен совсем недавно. Самое раннее, когда мы рассмотрим возможность прекращения поддержки, — после следующего ESR (конец июля). Да, мы должны были обновить документацию раньше, но это не случай «прекращения поддержки без достаточного предупреждения». .hbs всё ещё поддерживается, и у вас достаточно времени, чтобы внести необходимые изменения.

Мы поддерживаем более 600 тем и плагинов, поэтому могу заверить вас, что мы тоже «чувствуем боль» этих миграций. Мы делаем всё возможное, чтобы сделать изменения максимально плавными для всех и продолжаем извлекать уроки из каждого внесённого изменения.

:100: Точно

У нас пока этого нет. Но мы начинаем формировать каталог навыков в основном репозитории. Кроме того, вся документация для разработчиков в формате Markdown была перенесена в основной репозиторий, отчасти для того, чтобы агентам ИИ было проще обращаться к ней.

Возможно, я смешал в голове несколько вещей, так как одновременно исправил свои плагины для обновления до Ember 6 (это было главным препятствием для меня) и перешёл с hbs. Извините, если я был слишком категоричен!

Но мне кажется, что если Discourse действительно хочет развивать экосистему плагинов, создаваемых пользователями, то полезным был бы современный обучающий материал по «vibecoding». Хотя, с другой стороны, стоит ли открывать шлюзы для потока плагинов, созданных с помощью vibecoding? Сложно сказать :smile:

Ах! Это помогает. PR отправлен.

Я сторонник размещения документации на GitHub. Это требует значительно больше усилий для внесения изменений, чем редактирование поста в вики, но этап ревью полезен. (И для документации авторов плагинов требование знания Git не является слишком высоким барьером.)