randomSeating-Challenge — توزيع شبه عشوائي لمقاعد الامتحانات

حلّ لتحدّي واجهات البرمجة في 42 أبوظبي — لم يُقدّم رسمياً للتحكيم، ونُشر للمشاركة فقط.

نظرة عامة

خدمة REST مكتوبة بـ TypeScript تجيب عن سؤال واحد: أين يجلس كل طالب في الامتحان؟ تقرأ الخدمة من واجهة 42 Intranet مواقع الجلوس الأخيرة للطلاب، ثم تسند مقعداً جديداً مختلفاً عن تلك المواقع.

التحدّي لم يكن خوارزمياً فحسب؛ معايير التحكيم المعلنة كانت: مدى الصلة بالموضوع، والإبداع، وسهولة الاستخدام، وسهولة النشر، وسهولة التحديث والصيانة — أي أن جودة الهندسة تزن بقدر دقة النتيجة.

المشكلة

توزيع المقاعد يبدو مسألة خلط عشوائي، وهو ليس كذلك:

• العشوائية الخالصة تفشل. توزيع عشوائي تماماً قد يعيد الطالب إلى المقعد ذاته الذي اعتاده، وهذا ينقض الغرض من التوزيع أصلاً. لذا المطلوب "شبه عشوائي": عشوائي داخل ما تسمح به القيود.
• التاريخ ليس عندنا. مواقع الجلوس السابقة تعيش في إنترانت 42، فالنظام يقرأ من مصدر خارجي لا يملك شكله.
• قيود تتراكم. اختيار المسار (مثل piscine)، واختيار المختبر، والتباعد بين الجالسين — كل قيد يقلّص فضاء الحلول قبل القيد التالي.

التخطيط

قُسّم العمل إلى أربع مهمّات متسلسلة، وحالتها معلنة في المستودع كما هي:

المهمة	الحالة
خوارزمية إسناد المقاعد (src/utils/campus.ts)	مكتملة
قراءة المقاعد الأخيرة من واجهة 42	مكتملة
إرجاع النتيجة عبر الواجهة	مكتملة
خدمة بريد لإبلاغ الطلاب	قيد العمل

وضع الخوارزمية أولاً — قبل الواجهة وقبل البريد — مقصود: إن لم يكن الإسناد نفسه سليماً، فلا قيمة لتغليفه بـ API أنيقة.

القرارات المعمارية

الخوارزمية وحدة معزولة. منطق الإسناد موضوع في src/utils/campus.ts لا داخل معالج المسار. البديل — كتابة المنطق داخل المتحكم — يجعل أي تجربة لقاعة أو قاعدة تباعد جديدة تمرّ عبر طلب HTTP كامل، وهذا يقتل سرعة التكرار.

واجهة REST بدل سكربت يعمل مرة واحدة. معيار التحكيم ذكر "سهولة الاستخدام" و"سهولة التحديث" صراحةً. السكربت يخدم من يملك طرفية؛ الواجهة تجعل التوزيع خدمة يستدعيها الإداريون أو تربطها أداة أخرى لاحقاً.

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

الإشعار منفصل عن الإسناد. خدمة البريد مهمّة رابعة مستقلة وليست جزءاً من حساب المقاعد، فتبقى النتيجة صالحة حتى لو لم تُرسل رسالة واحدة.

التنفيذ

المسار الكامل ثلاث خطوات: يستدعي النظام واجهة 42 لجلب مواقع الطلاب الأخيرة، ثم تستبعد الخوارزمية تلك المواقع من الخيارات المتاحة لكل طالب مع مراعاة المختبر والتباعد، ثم تُعاد الخريطة الناتجة في استجابة الواجهة.

خدمة إبلاغ الطلاب بالبريد لا تزال قيد العمل، وهذا مدوّن في المستودع دون ادّعاء غير ذلك.

النتيجة والدروس

المستودع يقدّم ثلاثة أرباع الحلّ عاملاً — الخوارزمية والقراءة والاستجابة — ويذكر صراحةً أن صاحبه لم يقدّمه للتحكيم، وإنما نشره لمن يريد أن يتعلم بناء واجهة RESTful من مثال حقيقي.

1. "شبه عشوائي" مصطلح هندسي لا لغوي. المطلوب توزيع يبدو عشوائياً للطالب ويحترم قيوداً صارمة في الوقت نفسه.
2. فصل المنطق عن النقل يوفّر الوقت مبكراً. ملف خوارزمية مستقل يُجرّب مباشرةً، ويبقى قابلاً للإبدال إن تغيّرت قواعد القاعة.
3. معايير التحكيم تحدّد التصميم. حين يُقيّم العمل بسهولة النشر والصيانة، تصبح بنية الملفات ووضوح الواجهة جزءاً من الحلّ لا زينة فوقه.

الروابط

• المستودع: github.com/i99dev/randomSeating-Challenge
• توثيق واجهة 42: api.intra.42.fr/apidoc