アマチュアプラグイン作者の事例研究

2024 年、私は仕事を探していました。コミュニティコンサルタント としてサービスを提供することを決めました。しかし、主に人々が関心を持っていたのは、Discourse サイトの修復や更新に関する技術的なサポートでした。ある潜在的なクライアントは、アカウントを持たない人々がフィードバックを送信するための連絡フォームを追加できるか尋ねました。調べてみたところ、それは 不可能だ と結論づけました。しかし、私は十分な余暇があり、プラグイン開発者チュートリアル に従って何ができるか試してみました。最終的に、連絡フォームプラグイン を開発し、そのクライアントと契約を結びました。[1]

ここで皆さんに明確にしておきたいのは、私はフロントエンドプログラマーではありませんということです。私がどんな種類のプロフェッショナルなプログラマーだったのは 13 年前のことです。HTML フォームの作り方は知っていますが、それが私の知識のほぼ全てです。そのため、チュートリアルの Ember と Handlebars のセクション で苦労し、なんとか機能するハックを組み立てました。幸いなことに、私はテンプレートシステムに慣れていたため、以前の職場でそれらを使用していました

私は OpenSSL Foundation で仕事を見つけ[2]、ほとんどクライアントを諦めました。しかし、私がプラグインを作成したクライアントは、私の仕事を高く評価してくれたため、リテイナー契約を続けてくれました(彼のためにいくつかの無関係なプロジェクトも手掛けました)。リテイナーを得るために、彼の Discourse サーバーをアップグレードすることにしました。そこで私が目にしたのは以下のエラーでした:

実は、これはクライアントのサイトには表示されていませんでした。なぜなら、私は愚かにも連絡プラグインを ステージングサイト にインストールはしたものの、有効化していなかったからです。そのため、すぐに セーフモード を起動し、プラグインを無効化しました。先週末、何が間違っていたのか、そしてクライアントのためにどう修正できるのかを調べるのに時間を費やしました。

いくつか検索した結果、テーマとプラグインにおける .hbs ファイル拡張子の非推奨化 という記事を見つけました:

Discourse の最新バージョンでは、テーマやプラグインで .hbs ファイルを使用することは非推奨となっています。このファイル形式のサポートは、次の ESR リリース後に削除されます。

これは 3 月のことでした。つまり、私が ESR リリース を使用していた場合、基本的には 9 月末まで修正する時間があったはずです。しかし、私の Discourse 設定は「tests-passed」[3] を使用しているため、数ヶ月早くエラーが発生したようです。

いずれにせよ、修正しなければならない(そうでなければクライアントを失望させることになる)ため、テーマとプラグインを .gjs ファイル形式に自動的に更新する という手順に従って飛び込みました。最初のステップは、開発環境をインストール することでした。なぜなら、最後にこれを試したとき 以来、ラップトップを変更していたからです。[4] ついに Discourse を起動し、プラグインがローカルで壊れていることを確認した後、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)

プラグインを変更しなければならないのは面倒ですが、少なくとも lint プロセスによってコードを整理し、現代的な形にすることができました。しかし、.gjs への変換を試みると自動スクリプトが失敗しました。そこで、https://ask.discourse.com/ を試してみることにしました。

そこでは 12 件の質問を投稿しました。これらは人間には共有したくないほど、次第に苛立つプログラマーのあがきのようなものです。ある時点で、ボットは私のサブ問題のうちの 1 つに対して「より堅牢で現代的なアプローチ」を提案しましたが、それには . . . .js ファイルと .hbs ファイルが含まれていました。

8½ の一場面。監督が批評家の 8½ に対する否定的なレビューを投げ捨てているシーン。

なぜこれが起こるのか理解しています。これは Meta Discourse の議論に基づいてトレーニングされており、まだ多くの投稿に Handlebars コードが含まれています。その中には 公式のプラグイン開発者チュートリアルの第 2 部 も含まれています。その内容は時間とともに更新されるでしょうが、アップグレードに関する 公式のアドバイス が Meta Discourse で質問するのではなくチャットボットに尋ねるようになっているため、もう少し時間がかかるのではないかと心配しています。

文句を言うべきではないかもしれません。それは私のコードを整理するのに役立ち、人間に尋ねるよりもおそらく摩擦は少なかったでしょう。

プラットフォームの安定性

私は現在 OpenSSL Foundation で働いています。Heartbleed のことで OpenSSL についてご存知かもしれません。それは至る所で使われています。最も人気のあるダウンロードバージョンは 1.1.1 で、2023 年にライフサイクル終了 (EOL) に達しました。次に人気があるのは 3.0 で、2021 年にリリースされましたが、Long Term Support (LTS) リリースとしてまだサポートされています。次は 3.5 で、最新の LTS です。これら 3 つのリリースは、GitHub からのダウンロード のほぼ 3 分の 2 を占めています。

これは少しがっかりです。なぜなら、3.5 にはいくつかの新しい機能 があるからです。しかし、結局のところ、人々が最も気にする機能は SSL/TLS暗号プリミティブ の組み合わせです。量子耐性暗号アルゴリズムに興奮しない限り、アップグレードの痛みをできるだけ先送りするでしょう。

もちろん、OpenSSL は Discourse よりもはるかに下位のスタックにあります。しかし、原則は同じです。新しい機能がない限り、人々は破壊的なアップグレードに興味を持ちません。皆さん が Discourse に追加された新しい機能に興奮していることは理解しています。後で最適化を得るために API を変更したい という気持ちもわかります。ただ、動きが速すぎると、コミュニティが構築されるプラットフォームとしての Discourse に悪影響を与えるのではないかと心配しています。

そういえば、Gardening Platforms という非常に有用なスライドデッキがあります。これは Alex Komoroske によって作成されました。スライド 90 は「プラットフォーム+エコシステム」というセクションの始まりで、プラットフォームがそのエコシステムと共進化しなければならない方法を説明しています。この場合、Discourse は、プラグインやテーマのデザイナー、ホスティングサービス、Meta Discourse コミュニティ、そして Discourse 上に構築されたコミュニティを支えるプラットフォームです。スライド 98 のスピーカーノートからの重要な洞察:

しかし、それらは独立しているわけではありません。相補的に関係しています。

一方で行われる行動は他方に影響を与え、その逆もまた同様です。両方向にそれらを結びつけるフィードバックループと考えてください。

彼らは厳密に結びついているわけではなく、それらを結びつけるゴムバンドのようなものです。重力のような引力です。

プラットフォームとエコシステムが互いに対して速すぎると、その絆は破れ、壊滅的な結果を招きます。私は Discourse がエコシステムに対して正しく行動すると信じています。ただ、先週末のような週末には、その信頼が揺らいでいるように感じられます。


  1. 私は、それが最終的に 比較的静的なサイト になってしまったにもかかわらず、自分の仕事にほどほどに誇りを持っています。 ↩︎

  2. 伏線! ↩︎

  3. これも 更新される必要があります ↩︎

  4. Redis と Rails のインストールは、私が覚えているよりも難しかったです。 ↩︎

  5. ただし、その前に eslint.config.mjs取得することに失敗して多くの時間を費やしました けども: ↩︎

このエラーは、プラグインを今すぐ更新する必要があるからではなく、このバグが原因で発生したのだと思います。

私も以前、自分が作成した多くのプラグインで同じような経験をしました。Discourse の基準に合わせてそれらを近代化するためのリソースが不足していたのです。私はデータサイエンス系の仕事をしており、ソフトウェアエンジニアリングの概念は理解していても、ウェブ開発の具体的な技術については最新情報を追えていませんでした。その結果、これらの非推奨プラグインに依存していたため、8 ヶ月間サイトを更新できませんでした。

あなたの苦労を軽視するつもりはありませんが、基本的には「エージェント型コーディング」の登場により、この開発ペースの問題はもはや解決済みだと考えています。以前ならコードを書き、正しく動作させるまでに1〜2週間かかっていた作業が、20ドルのClaude Code へのサブスクリプションと、プラグインごとに数分あれば済むようになりました。それだけでなく、パフォーマンスの最適化も同時に行うことができました。

仕事や趣味のプロジェクトでエージェント型コーディングを数回使った後、私はもう二度とゼロから何かをコーディングすることはないだろうと思います。それは、手書きで手紙を書いて配達するのと、メールを送るのとを比較したような技術的な差です。少し寂しい気もしますが、同時にまるで神レベルの力を授かったような感覚も味わえます。

確かにそうですね。最新のESRにアップグレードし、テストにもっと注意を払うことが、今後は良い方針のようです。

開発スピードそのものが問題だとは思いません。問題は「すべて」のスピードです。例えば、なぜプラグインチュートリアルが更新されていないのでしょうか?プラグインを作ろうとする不運な人々の顔を吹き飛ばすための地雷が待ち構えている状態です。当面は機能するかもしれませんが、最終的には私が直面したのと同じ問題に直面することになります。解決策は、後でAIを使ってプラグインを修正することではなく、今すぐプラグイン作成の指示を修正することです。つまり、昔ながらの方法を教える理由がもうないはずです。そうでしょう?

私たちは、巨大なコードベースを維持し、課金クライアント向けに新機能を実装しつつ、オープンソースコミュニティへのサポートを提供し、システムを稼働させ続ける、比較的少人数のチームだからです。

1 日にできることには限りがあり、ドキュメントは往々にして開発に追いついていません。

あなたのフラストレーションはよく理解できますが、この点にも触れる価値があると感じています。

@jericson さん、詳細な情報をありがとうございます。おっしゃる通り、Discourse は OpenSSL とは利用状況やスタック内の位置づけにおいて非常に異なる立場にあります。進歩、カスタマイズ性、安定性のバランスを取り続けることは常に課題です。誰もが満足する完璧な解決策はありませんが、私たちは常に顧客やオープンソースコミュニティからのフィードバックを考慮しています。あなたが共有してくれたこの引用は本当に素晴らしいです:

:chefs_kiss:

@moin さんが言及した通り、.hbs の非推奨化に関連してあなたが経験した問題は、約 1 週間 latest ブランチにおけるバグでした。大変申し訳ありませんでした!.hbs の使用は非推奨となっていますが、まだサポートされています。あなたの .hbs コードは現在、正常に機能するはずです。

ご指摘ありがとうございます。ドキュメント内の残りの .hbs に関する記述を整理する作業を行いました:

完全に理解できます。[1] 私は Discourse が本当に気に入っていますし、この投稿を書いたのは Discourse が今後も成功し続けてほしいからです。

私が学んだことは、コミュニティは変化を好まないが、自分が主体性を持っていると感じれば、変化に対してはるかにオープンになるということです。人々に主体性を与える方法は無数にあります。例えば、チュートリアルをウィキ投稿に変更すれば、私のような人々が更新できるようになります。ESR(長期サポート)計画の実装も役立ちます。なぜなら、すぐに変更を加えない選択肢を提供するからです。[2] また、私の経験をまとめて、オープンソースプロジェクトを管理する人々に見てもらうことも役立ちます。特に、私が不満を言った問題が一夜で解決されたからです。:wink:

「ユーザーの意見聴取は有害か?」[3] で Kathy Sierra はこう書きました:

多くの人が、フォーカスグループが多くの点で極めて非効率的であることを理解していますが、それでもなお、実在するユーザーからの実際のフィードバックを聴くことが、新製品やサービスの開発、および既存のものの改善にとって最善の方法だと想定しています。しかし、そこには大きな問題があります。それは、_人々は自分が思いもよらなかったものをどうやって求めるべきか、必ずしも知らない!_ということです。ほとんどの人は、既存のものを見て、それをどう改善できるかを考えるだけで、完全に_漸進的_な改善に基づいて提案を行います。しかし、それは全く新しいものに対するビジョンを持つこととは大きく異なります。

真の革新は、ユーザーが_直接的に_言うことからほとんど生まれません。

私が言ったように、私はフロントエンド開発者ではありません。なぜこれらの変更が行われたのか、それが私にどう恩恵をもたらすのか、よくわかりません。[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(7 月末)以降と見なす予定です。したがって、ドキュメントの更新はもっと早く行うべきでしたが、「十分な警告なしにサポートを廃止する」というケースではありません。.hbs は現在もサポートされており、必要な変更を行うには十分な時間があります。

私たちは 600 以上のテーマとプラグインを維持管理しており、これらの移行に伴う「痛み」も同様に感じています。誰もが可能な限りスムーズに変更できるよう最善を尽くしており、今後も各変更から学び続けていきます。

:100: その通りです

現時点ではまだ完全には整っていません。しかし、コアリポジトリに スキル のディレクトリを構築し始めています。さらに、すべての開発者向けドキュメントの Markdown ファイルはコアリポジトリへ移動されました。これにより、AI エージェントが参照しやすくなるようにしています。

私の頭の中で物事が混同されているかもしれません。Ember 6 アップグレード(私にとっての大きな更新の障壁)への対応と hbs からの移行を同時に行ったためです。もし私が言い過ぎたならお詫びします。

ただ、Discourse がユーザー作成のプラグインエコシステムを成長させたいと考えているなら、モダンな「vibecoding」チュートリアルは有用だと思います。しかし一方で、vibecoded プラグインの洪水を招くことを望ましいこととみなせるでしょうか?判断が難しいところです :smile:

ああ、それでわかりました。PR を提出しました

私は ドキュメントを GitHub に置くこと を支持しています。Wiki の投稿を編集するよりも変更を提出するのはかなり手間がかかりますが、レビュー手順は役立ちます。(また、プラグイン作成者向けドキュメントの場合、Git の知識を要求することはそれほど高いハードルではありません。)