مرحبا! أنا ليندا ليو ، طالبة صاعدة في معهد ماساتشوستس للتكنولوجيا. قضيت الأشهر الثلاثة الماضية هنا في edX كمتدرب في هندسة البرمجيات في فريق Mobile ، وخلال هذه الفترة أتيحت لي الفرصة للعمل في نطاق من الخادم إلى تطوير iOS و Android. أود التحدث عن مشروعين - الأول ، إعادة تصميم إطار عمل التحكم في الوصول إلى edX ، والثاني ، استكشاف إطار عمل React وإمكانياته لـ edX.
إطار التحكم في الوصول
بدأ هذا المشروع في الواقع كإصلاح للأخطاء حول تواريخ بدء الدورة التدريبية لتطبيق الهاتف المحمول. إذا لم يحدد مؤلف الدورة التدريبية تاريخ بدء الدورة التدريبية الخاصة به ، فسيتم تعيينه افتراضيًا على 1 يناير 2030. على منصة الويب ، يتم إجراء فحص بحيث يرى المستخدم "غير مجدول" بدلاً من التاريخ الخاطئ الواضح. ومع ذلك ، لا يقوم تطبيق الأجهزة المحمولة بإجراء فحص معادل لذلك كان الطلاب يرون أن الدورات التدريبية بدأت في عام 2030.
كان أول إصلاح محتمل يتبادر إلى الذهن هو إجراء فحص من جانب الخادم في نقطة نهاية التسجيلات في الدورة التدريبية لواجهة برمجة تطبيقات الهاتف المحمول لمعرفة ما إذا كان تاريخ البدء هو الافتراضي ، وجعل واجهة برمجة التطبيقات ترسل بدون سلوفانالقيمة في هذه الحالة. كان هذا الإصلاح رائعًا لأنه لن يتطلب أي تغييرات من جانب العميل. ومع ذلك ، اكتشفت أن التطبيقات توقعت طابعًا زمنيًا من واجهة برمجة تطبيقات الجوّال ، وتعطلت عندما تم كسر هذا التوقع. وبالتالي ، لن ينجح تغيير جانب الخادم البحت.
تطور الحديث عن الإصلاحات المحتملة إلى مناقشة حول كيفية إجراء عمليات التحقق من تاريخ البدء في النظام الأساسي. المنصة لديها وظيفة كبيرة تسمى has_access لهذا الغرض. يأخذ المستخدم ، وإجراء ، وكائن ، ويتحقق مما إذا كان المستخدم لديه الأذونات المناسبة لتنفيذ الإجراء على الكائن. على سبيل المثال ، يتمثل استخدام هذه الوظيفة في التحقق مما إذا كان لدى الطالب أذونات للتسجيل في دورة تدريبية. في ذلك الوقت ، عادت هذه الوظيفة ببساطة إلى قيمة منطقية - صواب إذا تم منح الوصول ، خطأ إذا تم رفض الوصول. نظرًا لوجود العديد من الأسباب التي تجعل من الممكن رفض الوصول وأن الأسباب المختلفة قد تؤدي إلى إثارة سلوكيات مختلفة ، فقد بدا الأمر كذلك has_access يمكن أن تستفيد من نوع الإرجاع الذي يحتوي على مزيد من التفاصيل. يمكن لواجهة برمجة تطبيقات الجوّال بعد ذلك إرسال نتائج ملف has_access تحقق للعميل ، والذي يمكنه بعد ذلك استخدام المعلومات لعرض رسالة مناسبة.
كانت الخطوة التالية هي تصميم نوع الإرجاع الجديد. الكائن الجديد يسمى AccessResponse. إنه كائن بايثون يحتوي على مكافئ منطقي للقيمة الأصلية has_access قد عاد ، ورمز خطأ سلسلة ، ورسائل المستخدم والمطور. تمثل الفئات الفرعية منه الأخطاء التي نريد حاليًا التعامل معها ، وهي تاريخ_البدء_الخطأ (إذا لم تبدأ الدورة التدريبية للمستخدم) ، الرؤية خطأ (إذا لم يكن لدى المستخدم حقوق الوصول المطلوبة) ، و حدث خطأ (إذا كان لدى المستخدم مرحلة غير محققة). لقد قمت بتنفيذ التغييرات في أربعة طلبات سحب منفصلة: واحد لكل طلب "حق الوصول", واجهة برمجة تطبيقات الجوال, عميل Androidو عميل iOS. على الرغم من أنه يتجاوز النطاق الأصلي لإصلاح الخطأ ، إلا أن هذا التغيير يسمح بالتحقق من تاريخ البدء للانتقال من جانب العميل إلى جانب الخادم. كأثر جانبي ، يجعل هذا التغيير من السهل جدًا تنفيذ الميزات المستقبلية (مثل المعالم) في تطبيق الأجهزة المحمولة. من خلال هذا العمل ، تمكنت من لمس الكثير من أجزاء قاعدة بيانات edX التي كانت رائعة حقًا!
React Native لنظام التشغيل iOS و React.js
كان مشروعي التالي أكثر استكشافية بطبيعته ، مع عدد أقل من الأهداف الملموسة. في edX ، يلزم تطوير العديد من الميزات ثلاث مرات - مرة للويب ومرة لنظام iOS ومرة لنظام Android. كانت هناك مجموعة متنوعة من الأدوات عبر الأنظمة الأساسية لتطوير الأجهزة المحمولة مع شعار "اكتب مرة واحدة ، استخدم في كل مكان" لمكافحة هذه المشكلة ، لكنهم حاولوا توحيد التطوير كثيرًا - لا يمكن للتطبيقات استخدام مكونات النظام الأساسي الأصلية ، لذلك خرجوا أشعر بصفحات ويب للجوّال ممجدة. طور Facebook حلاً لهذه المشكلة: إطار عمل يسمى React Native والتي تمكن المطورين من إنشاء تطبيقات أصلية باستخدام React (إطار عمل لواجهة المستخدم للويب).
الفكرة الدافعة وراء React Native هي "التعلم مرة واحدة ، والكتابة في أي مكان". هذا يعني أن الأنظمة الأساسية لها هياكل وأنماط مختلفة ، لذا يجب على المطورين كتابة تطبيقات مختلفة لكل منها ، ولكن باستخدام React Native ، يمكن كتابة هذه التطبيقات بنفس التقنيات الأساسية. إنه يعد بأفضل ما في العالمين - التطوير الفعال والمتشابه عبر الأنظمة الأساسية ولكن لا يزال يتمتع بهذا الشعور الأصلي الجيد به. في الآونة الأخيرة ، قام Facebook بفتح إصدار إطار العمل لنظام iOS. نأمل أن تسمح React Native (بمجرد أن يتم فتحها أيضًا لنظام Android) و React.js للمطورين بإعادة استخدام التعليمات البرمجية ، وبالتالي تقليل العمل المطلوب للتطوير لجميع الأنظمة الأساسية الثلاثة.
تعد XBlocks مرشحًا جيدًا لهذا المشروع ، لأنها عبارة عن أجزاء معيارية صغيرة ولا تحتوي تطبيقات الأجهزة المحمولة حاليًا على تطبيقات أصلية لها. على وجه التحديد ، اعتدت سحب وإسقاط XBlock، لأن التفاعلات التي تستخدمها (تحديدًا حركة السحب) ستستفيد من العرض السلس الذي تعد به React. لقد بدأت بإجراء تقييم بسيط بالسحب والإفلات مثل تطبيق iOS مستقل، للتعرف على التطوير باستخدام React Native. لقد أوفت React بوعدها - كان العرض سلسًا حقًا ، وتم تنظيم المكونات والمعلومات بطريقة منطقية حقًا.
أسفرت هذه التجربة الأولية عن سؤالين للمتابعة: ما مدى سهولة تحويل الشفرة إلى تقييم السحب والإفلات لـ React.js للمتصفح؟ ثانيًا ، ما مدى سهولة دمج تقييم السحب والإفلات مع إطار عمل XBlock بحيث يمكن للتقييم التواصل مع الخادم بالطريقة الصحيحة؟
لقد أمضيت الأسابيع القليلة الماضية في العمل على الإجابة على هذين السؤالين. لقد قمت بإنشاء إصدار ويب من تطبيق iOS الخاص بي ، وعلى الرغم من عدم وجود ترجمة مباشرة من iOS إلى الويب (React Native-to-React.js) للشفرة ، يتم تمرير المعلومات وتخزينها بنفس الطريقة ، و هذا يعني أنه يمكن إعادة استخدام الكثير من الوظائف. على سبيل المثال ، تتطلب جميع الوظائف التي تتعامل مع السحب عددًا قليلاً من التعديلات الصغيرة. هذا واعد لأنه يعني أنه يمكننا تطوير XBlocks المصممة لمنصات مختلفة ولكن لا يزال بإمكاننا إعادة استخدام الهيكل وراء الكود.
عملت أيضًا على دمج التقييم مع طاولة عمل XBlock ، حيث سيكون ذلك جزءًا مهمًا من عملها مع النظام الأساسي. تضمن ذلك تعديل XBlock بالسحب والإفلات نفسه بالإضافة إلى تنفيذ مكالمات AJAX الصحيحة من مكون React بحيث يعرف الخادم متى يفتح الطالب أو يحاول حدوث مشكلة. جعلت React من السهل إجراء المكالمات المطلوبة والآن لدينا إصدار React Native و React.js من XBlock هذا! آمل أن تجعل edX مكونات React جزءًا دائمًا من النظام الأساسي في المستقبل.
لقطات من React Native Drag and Drop XBlock
اليسار: العرض الأولي للمستخدم للمشكلة. حق: إبداء الملاحظات عبر تنبيهات iOS.
ملخص
أحببت أنني عملت في مجموعة متنوعة من المشاريع هذا الصيف من حيث التقنيات التي استخدمتها والأشخاص الذين عملت معهم. لقد تعلمت الكثير من الأشياء الملموسة واكتسبت أيضًا مهارات بسيطة ، مثل كيفية التواصل بشكل فعال في فريق هندسة البرمجيات. لقد كانت هذه فرصة رائعة ، وبفضل كل من جعلها كذلك! أود أن أشكر معلمي بشكل خاص ، كريس لي ، أكيفا ليفرت ، ونيميشا أستاغيري ، وبقية الفريق المتنقل ، والمتدربين الآخرين.
