دراسة حالة لمؤلف إضافة هاوٍ

مطور
1

في عام 2024، كنت أبحث عن عمل. قررت تقديم خدماتي كـ مستشار مجتمعي. ومع ذلك، كان معظم الناس مهتمين بالمساعدة التقنية لإصلاح أو تحديث مواقع Discourse الخاصة بهم. سألني عميل محتمل عما إذا كان بإمكاني إضافة نموذج اتصال للأشخاص الذين لا يملكون حسابًا لإرسال ملاحظاتهم. بحثت حولي واستنتجت أن الأمر لم يكن ممكنًا. لكنني كنت أملك وقتًا فراغًا كافيًا، فاتبعت دليل مطوري الإضافات لأرى ما يمكنني فعله. في النهاية، طورت إضافة نموذج اتصال ووقّعت العقد مع العميل.[1]

فقط للتوضيح للجميع: لست مبرمج واجهات أمامية! لقد مرّ 13 عامًا منذ أن كنت مبرمجًا محترفًا بأي نوع. أعرف كيفية إنشاء نموذج HTML، وهذا هو تقريبًا كل ما أعرفه. لذا، كافحت من خلال قسم Ember وHandlebars في الدليل وجمعت حلًا مؤقتًا عمل بشكل كافٍ. لحسن الحظ، كنت مرتاحًا لأنظمة القوالب بعد أن استخدمتها في وظيفة سابقة.

وجدت وظيفة في مؤسسة OpenSSL[2] وتخلّيت معظمًا عن عملائي. لكن العميل الذي بنيت له الإضافة احتفظ بي في عقد احتياطي لأنه كان يقدر عملي حقًا. (لقد قمت بعدة مشاريع غير مرتبطة له.) لكي أستحق عقد الاحتياطي هذا، قررت ترقية خادم Discourse الخاص به. وهذا ما رأيته:

فشل تحميل الإضافة discourse-contact-plugin من http://localhost:4200/assets/js/plugins/discourse-contact-plugin_main-r9hlw1h8.digested.js خطأ: لم يمكن العثور على الوحدة المستوردة من
فشل تحميل الإضافة discourse-contact-plugin من http://localhost:4200/assets/js/plugins/discourse-contact-plugin_main-r9hlw1h8.digested.js خطأ: لم يمكن العثور على الوحدة المستوردة من1233×236 34.6 KB

كان هذا فقط على موقع عميلي لأنني كنت غبيًا وقمت بتثبيت، لكن لم أفعّل، إضافة الاتصال على موقعي التجريبي. لذا، دخلت بسرعة في الوضع الآمن وقمت بتعطيل الإضافة. قضيت نهاية الأسبوع الماضي بعض الوقت في فهم ما حدث خطأ وكيف يمكنني إصلاحه لعميلي.

بعد بعض البحث، وجدت إلغاء دعم امتداد الملف .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 كمنصة تُبنى عليها المجتمعات.

بمناسبة الحديث عن ذلك، هناك عرض شرائح مفيد جدًا بعنوان رعاية المنصات كتبه أليكس كوموروسكي. الشريحة 90 تبدأ قسمًا يسمى “المنصة + النظام البيئي” يشرح كيف يجب أن تتطور المنصات مع نظمها البيئية. في هذه الحالة، Discourse هي المنصة التي تدعم نظامًا بيئيًا من مصممي الإضافات والقوالب، وخدمات الاستضافة، ومجتمع Meta Discourse، وحتى المجتمعات المبنية على Discourse. رؤى مهمة في ملاحظات المتحدث من الشريحة 98:

لكنهم ليسوا مستقلين؛ بل يرتبطون تبادليًا.

الأحداث التي تحدث في أحدهما تؤثر على الآخر، والعكس صحيح. فكر فيها كحلقات تغذية راجعة تربطهم في كلا الاتجاهين.

ليسوا مرتبطين بشكل جامد، بل يشبهون شريطًا مطاطيًا يربطهم. إنه جاذبية.

إذا تحركت منصة ونظامها البيئي بسرعة كبيرة نسبيًا لبعضهما البعض، فإن الرابطة تنكسر بتأثير كارثي. أنا أثق بـ Discourse في فعل الصواب تجاه النظام البيئي. إنه فقط بالنسبة لي، أشبه بأسابيع الماضي أن هذا الثقة قد ضعفت.

  1. أنا فخور بعض الشيء بعملتي رغم أنها انتهت بأن تكون موقعًا ثابتًا إلى حد كبير. ↩︎

  2. تلميح! ↩︎

  3. وهذا يحتاج أيضًا إلى تحديث ↩︎

  4. كان تثبيت Redis و Rails أصعب مما تذكرت. ↩︎

  5. ليس قبل قضاء وقت طويل في فشل استحواذ eslint.config.mjs، على أي حال ↩︎

2

أعتقد أنك حصلت على الخطأ بسبب هذا العيب، وليس لأن إضافتك تحتاج إلى تحديث في الوقت الحالي

3

مررت بنفس الأمر مع العديد من الإضافات التي كتبتها. لم أكن أملك الوقت الكافي لتحديثها لتتوافق مع معايير Discourse. أعمل في مجال يشبه علم البيانات، لذا ورغم معرفتي بمفاهيم هندسة البرمجيات، إلا أنني لا أواكب تفاصيل تطوير الويب الدقيقة. في النهاية، لم أقم بتحديث موقعي لمدة ثمانية أشهر لأنه كان يعتمد على هذه الإضافات القديمة.

لا أريد التقليل من معاناتك، لكنني أعتقد عمومًا أنه مع ظهور البرمجة الوكيلية (agentic coding)، أصبحت هذه السرعة في التطوير مشكلة غير جوهرية. فبدلاً من أن يستغرق مني الأمر أسبوعًا أو أسبوعين لكتابة الكود وضبطه بشكل صحيح، اكتفيت باشتراك بقيمة 20 دولارًا في Claude Code وبضع دقائق لكل إضافة. وعلاوة على ذلك، تمكنت من تحسين أدائها. وبعد استخدام البرمجة الوكيلية في بعض المشاريع المهنية والهواية، لا أعتقد أنني سأكتب شيئًا من الصفر مرة أخرى في حياتي. الأمر يشبه الفرق التكنولوجي بين كتابة رسالة بخط اليد وتوصيلها يدويًا مقابل إرسال بريد إلكتروني. إنه أمر محزن بعض الشيء، وفي الوقت نفسه أشعر وكأنك مُنحت قوى على مستوى الآلهة.

4

يبدو ذلك محتملاً. الانتقال إلى إصدار ESR الأحدث (وكوننا أكثر يقظة في الاختبار) يبدو خطة جيدة من الآن فصاعدًا.

لا أعتقد أن سرعة التطور بحد ذاتها هي المشكلة. المشكلة هي سرعة كل شيء. لماذا لم يتم تحديث دليل الإضافة على سبيل المثال؟ إنه منجم قنبلة ينتظر أن ينفجر في وجه شخص مسكين يريد بناء إضافة. سيعمل في الوقت الحالي، لكن في النهاية سيواجهون نفس المشكلة التي واجهتها. الحل ليس استخدام الذكاء الاصطناعي لإصلاح الإضافة لاحقًا، بل إصلاح التعليمات حول إنشاء الإضافة الآن. أعني، لا يوجد سبب لتعليم الطريقة القديمة للقيام بالأشياء، أليس كذلك؟

5

لأننا فريق صغير نسبيًا يُعنى بصيانة قاعدة كود ضخمة، مع ضرورة تنفيذ ميزات جديدة للعملاء المدفوعين، وفي الوقت نفسه تقديم الدعم والحفاظ على عمل الأمور لمجتمعنا مفتوح المصدر.

هناك حد لما يمكننا إنجازه في يوم واحد، وغالبًا ما يتأخر التوثيق عن الواقع.

أتفهم إحباطك جيدًا، لكنني أعتقد أن هذه النقطة تستحق الذكر أيضًا.

6

شكرًا لك على المعلومات المفصلة @jericson. كما تقول، فإن Discourse في وضع مختلف تمامًا عن OpenSSL من حيث الاستخدام وموقعه في المكدس. إنه توازن مستمر بين التقدم والتخصيص والاستقرار. لا يوجد حل مثالي سيرضي الجميع، لكننا نأخذ دائمًا في الاعتبار التعليقات من عملائنا والمجتمع مفتوح المصدر. أعجبني حقًا الاقتباس الذي شاركتَه:

:chefs_kiss:

كما ذكر @moin، كانت التجربة التي مررتَ بها مع إهمال .hbs خطأً في إصدار latest استمر لمدة أسبوع تقريبًا. آسفون جدًا لذلك! بينما يُعتبر استخدام .hbs مُهمَلًا، إلا أنه لا يزال مدعومًا. يجب أن يكون كود .hbs الخاص بك يعمل مرة أخرى الآن.

شكرًا لك على لفت الانتباه إلى هذا. قمتُ بمراجعة وتنظيف باقي إشارات .hbs في الوثائق:

7

أتفهم ذلك تمامًا.[1] أنا أعشق Discourse حقًا، وكتبت هذا المنشور لأنني أريد استمرار نجاح Discourse.

شيء تعلمته هو أن المجتمعات لا تهتم بالتغيير، لكنها تكون أكثر انفتاحًا عليه إذا شعرت بأنها تملك القدرة على التأثير. هناك طرق لا حصر لها لمنح الناس هذه القدرة. على سبيل المثال، يمكن تحويل الدليل إلى منشورات ويكي حتى يتمكن أشخاص مثلي من تحديثها. كما أن تنفيذ خطة الإصدار المدعوم طويل الأمد (ESR) يساعد أيضًا لأنه يمنح الناس خيار عدم إجراء تغييرات على الفور.[2] كما أن قدرتي على كتابة تجربتي ورؤيتها من قبل الأشخاص الذين يديرون مشروع المصادر المفتوحة تساعد أيضًا. خاصة أن الأشياء التي اشتكيت منها تم إصلاحها بين عشية وضحاها. :wink:

في مقالة “هل الاستماع إلى المستخدمين ضار؟”،[3] كتبت كاثي سييرا:

يدرك معظمنا أن مجموعات التركيز غير فعالة بشكل سيء للعديد من الأمور، لكننا ما زلنا نفترض أن الاستماع إلى ملاحظات حقيقية من مستخدمين حقيقيين هو أفضل طريقة لدفع المنتجات والخدمات الجديدة، وكذلك تحسين ما لدينا. لكن هناك مشكلة كبيرة في ذلك – لا يعرف الناس بالضرورة كيف يطلبون شيئًا لم يتخيلوه من قبل! يقترح معظم الناس تحسينات بناءً بالكامل على تحسينات تدريجية، ينظرون إلى ما موجود ويفكرون في كيفية تحسينه. لكن هذا يختلف تمامًا عن امتلاك رؤية لشيء جديد بشكل عميق.

نادرًا ما تأتي الابتكارات الحقيقية مما يقوله المستخدمون مباشرة.

كما قلت، لست مطور واجهات أمامية. لا أفهم حقًا سبب إجراء هذه التغييرات أو كيف ستفيدني.[4] وهذا مقبول إذا كانت هذه التغييرات ستجعل Discourse أفضل في النهاية.

ومع ذلك، يمكن أن يساعد الأشخاص مثلي على الاندماج إذا تمكنت من رؤية الرؤية بشكل أوضح قليلاً. بالنسبة لـ هذا التغيير، الحجة هي:

  1. تجربة تطوير أفضل بكثير
  2. ستمكن من تحسينات كبيرة في الأداء في إصدارات Discourse المستقبلية

يبدو جيدًا، أعتقد؟ لم ألاحظ #1 بشكل خاص، و #2 يمكن أن تعني أشياء كثيرة. سيكون أكثر فاعلية بالنسبة لي شيئًا مثل (وأنا أختلق هذا تمامًا):

  1. عندما حولنا إضافات Discourse الرسمية، وجدنا أن ذلك قلل من X% من أسطر الكود. بوضع القالب في نفس الملف مع جافا سكريبت، يصبح الكود أسهل في الفهم والتعديل في المستقبل.
  2. قمنا بإعداد فرع لاختبار إزالة Handlebars تمامًا واكتشفنا أن هذا التغيير جعل تحميل الصفحة أسرع بنسبة X%. ليس هذا فحسب، بل رأينا تحسينًا محتملًا يمكنه القضاء على [مشكلة معينة أثارها المستخدمون].

بعض التفاصيل الإضافية مع التركيز على تعليم غير الخبراء يقطع شوطًا طويلاً في الحفاظ على الثقة. قد لا أحب التغييرات، لكن كيف يمكنني الجدال مع إصلاح مشاكل حقيقية واجهها مستخدمون آخرون؟

  1. لدى OpenSSL ديناميكية مماثلة. لدينا شركة (حوالي 15 شخصًا) تبيع عقود دعم، ومؤسسة (10 أشخاص، بما في ذلك أنا) تهتم بالمصالح غير التجارية. تتأخر وثائقنا أيضًا. أثناء كتابة المنشور الأصلي، لاحظت أننا ما زلنا نشير إلى ميزات تم إزالتها الشهر الماضي. أعمل على طلب سحب (PR) لذلك. وقمنا أيضًا بإجراء بعض التغييرات التي انتقدها بشدة مشاريع تالية. ↩︎

  2. أقل فائدة لمطوري الإضافات الذين يريدون دعم مجتمعات ترغب في البقاء على حافة التطور. لكنه سيكون رائعًا بالنسبة لي لأنني أعتقد أنني الشخص الوحيد الذي يستخدم إضافتي. ↩︎

  3. موقعها الإلكتروني لم يعد موجودًا على الإنترنت، لكن هناك أرشيف PDF. ↩︎

  4. ليس لأنني مهم جدًا في المخطط الكبير للأمور. أنا أتحدث عن نفسي كبديل لأشخاص آخرين يعتمدون على Discourse. أعرف نفسي أفضل من معظم الناس، بعد كل شيء! ↩︎

8

لماذا يجب أن يكون ويكيًا لذلك؟ يتم إدارة توثيق المطورين عبر GitHub. أنا أفضل العملية التي يتم فيها مراجعة التغييرات أكثر من الويكي.

9

أتفق على أن توثيق الإضافات يجب تحديثه في هذه المرحلة. الهدف من فترة “الإيقاف التدريجي” التي تعمل فيها الإضافات لكن الموقع يعرض تحذيرًا بأنها ستتعطل قريبًا هو منح مطوري الإضافات وقتًا كافيًا لإصلاحها. ومع ذلك، خلال هذه الفترة، لم يتمكن فريق من المطورين المدفوعين على أساس كامل من تحديث توثيق تطوير الإضافات الأساسية. إنه توقع غريب يُفرض على المطورين الأفراد عندما لا يتمكن فريق من إدارته بالكامل في نفس الفترة الزمنية.

ما يشير إليّ هو أن سرعة التطوير سريعة جدًا و/أو أن مطوري الإضافات ليسوا أولوية كبيرة لمنصة Discourse. شخصيًا، أشعر أن الأمر يتعلق أكثر بالأخير. أفهم أن شيئًا ما يجب أن يُهمل، لذا هذه ملاحظة مني وليست نقدًا. تظل منصة Discourse قابلة للتخصيص بالكامل عبر الإضافات، وأقدر التحسينات المستمرة.

مع كل ما سبق، أعتقد أننا وصلنا إلى نقطة حيث إن دليل التوثيق خطوة بخطوة لبناء إضافة أساسية أصبح فكرة عفا عليها الزمن. وثيقة سياق واحدة ليعتني بها الذكاء الاصطناعي ويبني هيكل إضافة هو كل ما يحتاجه الآن مطور إضافات هاوٍ. في الواقع، بالنسبة لقاعدة كود مفتوحة المصدر مثل Discourse، لا حاجة للتوثيق على الإطلاق لأن الوكلاء يحصلون على السياق مباشرة من قاعدة الكود نفسها. عندما كنت أعمل على إضافاتي، رأيت أن نموذج Claude يقرأ الإضافات الموجودة كطريقة لتعلم أنماط التصميم. وتمكنت حتى من اكتشاف عيب في الكود الأساسي Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time

بشكل أساسي، لأي شخص يقرأ هذا ويطمح لأن يكون مطور إضافات هاوٍ، قد يكون التوثيق قديمًا، لكن بناء إضافة أسهل الآن بمقدار 1000 مرة مما كان عليه في أي وقت مضى.

10

فقط لتوضيح هذه النقطة: فقد بدأ جدول زمني للاستغناء التدريجي عن امتداد hbs مؤخرًا فقط. وأول موعد سننظر فيه لإسقاط الدعم هو بعد إصدار ESR القادم (أواخر يوليو). لذا نعم، كان ينبغي علينا تحديث التوثيق في وقت أبكر، لكن هذا ليس حالةً لـ “إسقاط الدعم دون تحذير كافٍ”. فلا يزال .hbs مدعومًا، وهناك وقت كافٍ لإجراء التغييرات اللازمة.

نحن ندير أكثر من 600 سمة وإضافة، لذا يمكنني أن أضمن لك أننا “نشعر بالألم” الناجم عن هذه الهجرات أيضًا. نبذل قصارى جهدنا لجعل التغييرات سلسة قدر الإمكان للجميع، وسنستمر في التعلم من كل تغيير نقوم به.

:100: نعم تمامًا

ليس لدينا هذا تمامًا بعد. لكننا نبدأ في بناء دليل للمهارات skills في المستودع الأساسي. بالإضافة إلى ذلك، تم نقل جميع مستندات المطورين بصيغة Markdown إلى المستودع الأساسي، جزئيًا لتسهيل الرجوع إليها من قبل وكلاء الذكاء الاصطناعي.

11

قد أكون أخلط بين الأمور في ذهني لأنني أصلحت برامجي الإضافية لكل من ترقية Ember 6 (العائق الكبير للتحديث بالنسبة لي) ورحلت من hbs في نفس الوقت. آسف إذا بالغت في تأكيداتي!

لكنني أعتقد أنه إذا أرادت Discourse تنمية نظام الإضافات الذي ينشئه المستخدمون، فسيكون دليل “التبرمج القائم على الجو” (vibecoding) الحديث مفيدًا. لكن مرة أخرى، هل من المرغوب فيه فتح السدود أمام موجة من الإضافات المبرمجة بهذه الطريقة؟ من الصعب القول :smile:

12

آه! هذا مفيد. تم تقديم طلب السحب (PR).

أنا من معجبي نشر الوثائق على GitHub. إن تقديم التغييرات يتطلب جهدًا أكبر بكثير من تحرير منشور في الويكي، لكن خطوة المراجعة مفيدة. (وبالنسبة لوثائق مطوري الإضافات، فإن اشتراط معرفة Git ليس عائقًا كبيرًا.)