مساعدة في تصميم مكوّن تكامل مخصص

مرحباً بالجميع! أقوم بالبحث عن منصات منتديات مختلفة لبناء مجتمع للمبرمجين التنافسيين (CP) البرازيليين، ويبدو أنني وجدت الحل!

أود أن تكون إحدى الميزات في هذا المنتدى تكاملاً مع Codeforces - منصة عبر الإنترنت تستضيف مسابقات ومناقشات حول البرمجة التنافسية. داخل Codeforces، يمتلك المتسابقون تقييماً (rating) يتغير وفقاً لأدائهم في المسابقات المصنفة. أود منح مستخدمينا القدرة على عرض تقييماتهم التي كسبوها بشق الأنفس في ملفاتهم الشخصية على المنتدى.

أول ما يجب أن يفعله هذا الإضافة (plugin) الذي أود تطويره هو السماح للمستخدم بإدخال معرفه (handle) على Codeforces، ثم التحقق من أن هذا المعرف ينتمي فعلياً إلى مستخدم المنتدى. للقيام بذلك، أفكر في استخدام إضافة Custom Wizard لطلب معرفهم، ثم إرسال سلسلة عشوائية عبر Codeforces Talks API، والذي سيتعين على المستخدم إدخالها بشكل صحيح. إذا كانت كل شيء على ما يرام، سيتم تخزين معرفهم في حقل مخصص للمستخدم. هل يبدو هذا مقبولاً؟ هل كنت ستفعل ذلك بطريقة مختلفة؟

الآن، أنا أعرف مستخدميني [المستقبليين]، فبعد كل شيء أنا مبرمج تنافسي (CPer) بنفسي! سيجدون متعة في عرض تقييمهم من خلال لون معرفهم على المنتدى. أي أنه إذا كان التقييم أعلى من 1400، يكون المعرف بلون سماوي، وإذا كان أعلى من 1600، يكون بلون أزرق، وهكذا.

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

لذا، عندما يربط المستخدم حسابه على Codeforces بملفه الشخصي لأول مرة، يمكنني استرجاع تقييمه وتعيينه إلى المجموعة الصحيحة (specialist، expert، candidate master، …، international grandmaster). ومع ذلك، قد يتغير التقييم قريباً، وأود تحديث مجموعة المستخدم تلقائياً عند تغير تقييمه.

الآن، فكرت في بعض الطرق لتحقيق ذلك وأود اقتراحات حول أيها يجب اتباعه، وإذا أمكن، بعض التوجيهات الخاصة بـ Discourse:

  • تشغيل مهمة (Job) بشكل دوري لتحديث تقييم ومجموعة كل مستخدم (كثير من الطلبات الخارجية الموجهة إلى واجهة برمجة تطبيقات Codeforces).
  • تشغيل مهمة (Job) بشكل دوري لمعالجة المسابقات كما تحدث. بما أن التقييمات لا يمكن أن تتغير إلا أثناء المسابقة، إذا كانت تقييمات المستخدمين متسقة في البداية، فبمعالجة تغيرات التقييم كما تحدث، يمكنني تحديث التقييمات التي تغيرت فقط والحفاظ على الاتساق مع طلب خارجي واحد إلى واجهة برمجة التطبيقات.
  • وجود محلل مخصص للتقييم والمجموعة. لذا سأحتاج إلى تخزين آخر استرجاع للتقييم، وعند طلب GET rating/groups التالي، إذا كان التقييم قديماً، سأقوم بالاتصال بواجهة برمجة تطبيقات Codeforces وتحديث تقييم/مجموعات المستخدم. هذا هو الحل المفضل لدي لأنه يبدو سهلاً وسيكون متسقاً في النهاية دائماً. ومع ذلك، لست متأكداً تماماً من كيفية تنفيذ ذلك أو عواقب إزالة وإضافة مجموعة لمستخدم بشكل ديناميكي. أو حتى إذا كان هذا ممكناً على الإطلاق كإضافة (plugin).

حسناً، أعتذر عن هذا النص الطويل! سأكون سعيداً جداً بأي نوع من المدخلات حول كل هذا. شكراً لاهتمامكم.

بمجرد حصولك على معرف المستخدم في Codeforces في حقل مخصص (user_custom_field)، سيكون من السهل تحديث أي بيانات تريدها من ملفهم الشخصي (مثل تعيين المجموعات، أو تخزين أي بيانات ملف شخصي من Codeforces في الحقول المخصصة للمستخدم، وما إلى ذلك) عند تسجيل دخولهم.

شيء مثل:

after_initialize do
  DiscourseEvent.on(:user_logged_in) do |user|
    # الحصول على البيانات من Codeforces
      if codeforce_rating > 1400
          group = Group.find_by(name: group_1400)
          if group
            gu = GroupUser.find_by(group_id: group.id, user_id: user.id)
            GroupUser.create(group_id: group.id, user_id: user.id) unless gu
          end
        end
      end

  end

end

هذه الطريقة سهلة جداً وستقوم بتحديث البيانات فقط للأشخاص النشطين فعلياً في المجتمع.

هذا رائع! أنا سعيد لأنني استشرت قبل تنفيذ أي شيء.

شكرًا جزيلاً لك!

إذا كان جميع مستخدميك من مستخدمي Codeforces، فإنني أنصح بتنفيذ تسجيل الدخول الموحد (حيث يكون Codeforces هو مزود المصادقة). بهذه الطريقة لن تكون هناك حاجة لخطوة مصادقة إضافية، وسيحصل مستخدموك على تجربة تسجيل دخول/تسجيل دخول أفضل. يمكنك حتى مزامنة المجموعات بهذه الطريقة!

أقترح القيام بذلك من المصدر، أي من حيث يعرف Codeforces أن التصنيف قد تغير، أن يقوم بإجراء استدعاء واجهة برمجة تطبيقات (API) نحو Discourse لتحديث التصنيف (أو أي خاصية مستخدم أخرى تتأثر بهذا التصنيف). بهذه الطريقة ستبقى جميع البيانات محدثة دائمًا. عندما تحتاج إلى مزامنة الأشياء، فإن الاستطلاع (polling) يؤدي دائمًا إلى مشاكل بطريقة أو بأخرى، لذا تجنبه حيثما أمكن واستخدم نهجًا قائمًا على الأحداث.

لقد افترضت أن استخدام Codeforces كسيد للمصادقة الموحدة (SSO) غير ممكن. إذا كان ذلك ممكنًا، فأنت بالتأكيد تريد القيام بذلك بهذه الطريقة!

كان افتراض @pfaffman بأن استخدام Codeforces كمزود مصادقة غير ممكن صحيحًا. يُدار Codeforces تقريبًا بواسطة شخص واحد، وأتساءل عما إذا كان سيقوم بتنفيذ أي شيء لشيء لا يزال في مرحلة التخطيط أو التمويل.

أتفق بأن الاستقصاء المستمر (polling) ليس الحل الأمثل! لذا فإن الحل المقترح بالاستعلام عند تسجيل دخول المستخدم يبدو توازنًا جيدًا بين [رغبة المستخدم في] الاتساق وتجنب تحميل خوادم Codeforces بشكل قد يجذب الانتباه ويؤدي إلى حظرنا.

إذا نجح حالتنا الخاصة للمجتمع البرازيلي وحاولت مجتمعات أخرى فعل الشيء نفسه، فقد يقوم مايك (الشخص المسؤول عن Codeforces) بتنفيذ شيء من هذا القبيل.

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