أنا بن مكموران ، طالبة صاعدة تدرس علوم الكمبيوتر في معهد ورسستر للفنون التطبيقية. لقد أمضيت الاثني عشر أسبوعًا الماضية كمتدرب في هندسة البرمجيات في فريق التدريس والتعلم (TNL). هذا هو الصيف الثاني لي كمتدرب هنا في edX. على الرغم من وجود العديد من المهام التي عملت عليها خلال فترة وجودي هنا ، إلا أن هناك مشروعين رئيسيين أود إبرازهما.
API وتطوير الواجهة الأمامية للفرق
كان المشروع الأول الذي عملت فيه هو ميزة Teams لـ LMS ، والتي لا تزال قيد التطوير. ستسهل هذه الميزة على الطلاب التواصل والتحدث مع بعضهم البعض في مجموعات صغيرة وتزيد من انتشار دورات edX. شمل تطوير هذه الميزة استخدام الواجهة الأمامية العمود الفقري وتنفيذ API مع إطار عمل Django Rest (DRF). بينما كنت على دراية بـ Backbone من تحسين سير عمل نشر الدورة في الصيف الماضي ، كان عمل API جديدًا بالنسبة لي.
كان هناك تركيز قوي خلال التطوير على إنشاء مكونات منفصلة وقابلة لإعادة الاستخدام. أحد الأمثلة على ذلك هو الطريقة التي صممنا بها عناصر تحكم ترقيم الصفحات لقوائم الفريق والموضوعات. قمنا بتطوير عدة ضوابط الترحيل العامة والقابلة لإعادة الاستخدام متوافق مع معلومات الصفحة التي تعرضها DRF:
سيكون من السهل دمج عناصر التحكم ، كما هو موضح أعلاه ، مع نقاط نهاية واجهة برمجة تطبيقات edX الأخرى في التطوير المستقبلي.
استخدم حقول قابلة للتوسيع لقد قمت بإنشائه لدعم Team API وهي مثال آخر على التعليمات البرمجية القابلة لإعادة الاستخدام. يمكن للعملاء تحديد الحقول التي يرغبون في الحصول على مزيد من المعلومات عنها كجزء من الطلب الأولي. على سبيل المثال ، يمكن أن يحدد طلب معلومات الفريق أنه يجب توسيع حقل المستخدمين. بدلاً من تقديم أسماء المستخدمين فقط ، ستشمل الاستجابة عندئذٍ تفاصيل حول كل مستخدم في الفريق. يؤدي ذلك إلى تقليل عدد الطلبات التي يجب على العميل إجراؤها ، أو تقليل حجم الاستجابة عندما تكون الحقول غير ضرورية. من السهل دمج الحقول القابلة للتوسيع مع أي واجهة برمجة تطبيقات DRF عن طريق تحديد الحقل كملف توسيع وتوفير متسلسل للحالة المنهارة والموسعة. مع نمو منصة edX ، سيصبح هذا التركيز على المكونات القابلة لإعادة الاستخدام أكثر أهمية فقط.
تحسينات أداء منتديات المناقشة
كما قضيت عدة أسابيع في تحسين أداء منتديات المناقشة الخاصة بنا. نحن نستخدم New Relic لمراقبة الخوادم التي تقوم بتشغيل edx.org. في وقت سابق من هذا الصيف ، التقطت المراقبة أثرًا أظهر أن الأمر استغرق أكثر من 40 ثانية لنشر تعليق في دورة واحدة محددة ، مما دفع إلى مزيد من التحقيق.
لقد حملت الدورة التدريبية الإشكالية في بيئة التطوير المحلية الخاصة بي وحاولت نشر تعليق. كشف التنميط أن الخادم كان يقضي الغالبية العظمى من الوقت في إصدار حدث تحليلي ، والذي يتضمن موضوع المناقشة ، إن أمكن. يوفر موضوع مكون المناقشة طريقة لتصفية سلاسل المناقشة وتجميعها. على سبيل المثال ، كل سلاسل الرسائل في مكون مناقشة مضمن لها نفس الموضوع.
في تطبيق المناقشة ، يتم إنشاء التعليقات بناءً على معرف المناقشة المستخدم بواسطة خدمة التعليقات. ومع ذلك ، يتم تخزين موضوع المناقشة لتعليق معين في وحدة المناقشة كجزء من الدورة التدريبية. تعرف وحدات المناقشة معرف المناقشة المرتبط بها ، ولكن لا توجد طريقة فعالة للحصول على موضوع المناقشة إذا كنت تعرف معرف المناقشة فقط. تضمنت الدورة التدريبية الإشكالية ما يقرب من 1000 وحدة مناقشة. إنشاء حدث التحليلات تم تحميله كل واحد على حده لاكتشاف موضوع المناقشة!
كانت فكرتي الأولى هي إضافة فهرس على معرف المناقشة. ثبت أن هذا يمثل مشكلة نظرًا لوجود العديد من آليات الاستمرار للدورات التدريبية في منصة edX (دورات mongo القديمة و Split mongo و XML). قد يتطلب استخدام فهرس جديد تغييرات جذرية. بدلاً من ذلك ، قمت بإنشاء ملف تعيين معرفات المناقشة للوحدات النمطية المرتبطة. يتم تخزين هذا التعيين مؤقتًا في قاعدة بيانات MySQL عند نشر الدورة التدريبية. نظرًا لأن بيانات الدورة التدريبية نادرًا ما تتغير ولكن غالبًا ما يتم الوصول إليها ، فإن التكلفة المرتفعة نسبيًا لبناء الخرائط من خلال اجتياز الدورة التدريبية بأكملها مقبولة ، نظرًا لأنه نادر الحدوث.
مع تطبيق الإصلاح الخاص بي ، كنت بحاجة إلى التحقق من ذلك من خلال اختبار التحميل. كانت هذه العملية جديدة بالنسبة لي. على الرغم من أن الأمر لم يكن يمثل تحديًا في حد ذاته ، فقد استغرق الأمر بعض الوقت لأصل إلى السرعة. قمت بتشغيل المنتديات الموجودة جراد اختبارات ضد المسار الإشكالي قبل وبعد تطبيق الإصلاح الخاص بي.
قبل الإصلاح ، استغرق الأمر حوالي 20 ثانية لإنشاء تعليق على مدار نصف ساعة من اختبار التحميل. لاحظ العدد الهائل من استعلامات MongoDB ، 1320 ، في جدول التفصيل حيث يتم تحميل كل وحدة مناقشة في الدورة.
بعد الإصلاح ، استغرق الأمر حوالي أربع ثوان لإنشاء تعليق على مدار نصف ساعة من اختبار التحميل. لاحظ كيف أن عدد استعلامات MongoDB الآن هو 6.75 فقط.
كانت أوقات الاستجابة أسرع بنحو خمس مرات وتم تقليل عدد استفسارات MongoDB بشكل كبير مع الإصلاح. إنه الآن في الفرع الرئيسي لـ edx-platform ويجب نشره في edx.org قريبًا.
باختصار…
تجربتي كمتدرب في edX كانت رائعة. كنت جزءًا من فريق TNL ، شعرت وكأنني موظف بدوام كامل. تمكنت من الحصول على تذاكر حقيقية ورؤية تأثير عملي على المنصة. تطوير مشروع مفتوح المصدر رائع. أود أن أشكر آندي أرمسترونج وكريستينا روبرتس وفريق TNL بأكمله و edX لجعل هذا الصيف رائعًا!
