Sherif Aboghazala

وعليكم السلام ورحمة الله وبركاته من الصورة يظهر أن المشكلة ليست في XAMPP نفسه، بل في Apache تحديدًا. الخطأ الأساسي هو: Port 80 in use Apache WILL NOT start without the configured ports free أي أن المنفذ 80 مستخدم من برنامج آخر، لذلك Apache يفشل في التشغيل. سبب المشكلة غالبًا أحد الأمور التالية: وجود برنامج آخر يعمل على المنفذ 80 مثل: IIS (خدمة الويب الخاصة بويندوز) Skype VMware Docker أي سيرفر محلي آخر أو أن Apache يعمل مسبقًا في الخلفية أو أن الخدمة محجوزة من النظام الحل الأول (الأسهل): تغيير منفذ Apache افتح XAMPP اضغط Config بجانب Apache اختر Apache (httpd.conf) ابحث عن السطر: Listen 80 وغيّره إلى: Listen 8080 ثم ابحث عن: ServerName localhost:80 وغيّره إلى: ServerName localhost:8080 احفظ الملف وأعد تشغيل XAMPP ثم شغّل Apache بعدها افتح المتصفح واكتب: http://localhost:8080 الحل الثاني: إيقاف البرنامج الذي يستخدم المنفذ 80 اضغط Win + R اكتب services.msc ابحث عن: World Wide Web Publishing Service إن وجدته، أوقفه واجعل Startup type = Disabled أعد تشغيل XAMPP وجرب تشغيل Apache. الحل الثالث: معرفة من يستخدم المنفذ افتح CMD كمسؤول واكتب: netstat -ano | findstr :80 سيظهر رقم PID بعدها افتح Task Manager وابحث عن نفس PID لمعرفة البرنامج.

يمكنك الحصول على Redis بشكل عالمي ومجاني (أو بخطة مجانية قوية) من عدة منصات موثوقة، وهذه أشهرها للمبتدئين: أولًا: Redis Cloud (الرسمي) تقدمه شركة Redis نفسها. يوفر خطة مجانية بحجم صغير مناسبة للتجربة والتعلم، مع اتصال عالمي ومستقر. مميز لأنه رسمي، لكن السعة محدودة. ثانيًا: Upstash من أفضل الخيارات حاليًا. يوفر Redis عالمي (Serverless) مع خطة مجانية جيدة جدًا. سهل الربط مع Web و Node.js و Python و Cloud Functions. مناسب للمشاريع الصغيرة وReal-Time. ثالثًا: Railway يمكنك تشغيل Redis بنقرة واحدة. الخطة المجانية تعتمد على الرصيد الشهري، وغالبًا تكفي للتجارب. جيد إذا كنت تستخدم Railway لبقية المشروع. رابعًا: Render يدعم Redis ضمن خدماته. الخطة المجانية محدودة لكنها كافية للتعلم. مناسب إذا كنت تستضيف الـ Backend على Render. خامسًا: تشغيل Redis محليًا (للتعلم فقط) على جهازك باستخدام Docker أو WSL. ليس عالميًا، لكنه ممتاز للتجارب والتطوير. ملاحظة مهمة: لا يوجد Redis “غير محدود 100% مجاني” للإنتاج الحقيقي، لكن Upstash هو الأقرب لفكرة المجاني العالمي للمبتدئين والمشاريع الصغيرة.

وعليكم السلام ورحمة الله وبركاته، سؤالك مهم جداً، لأن اختيار المسار الصحيح في البداية يوفّر عليك وقتاً وجهداً كبيرين. نعم، هناك وظائف تقنية أخرى مناسبة للمبتدئين غير Web Developer و SOC Analyst Tier 1، وبعضها أسهل دخولاً وأسرع من حيث فرص العمل. من أفضل الخيارات للمبتدئين حالياً: Web Developer (Front-end أو Back-end أو Full-stack) من أكثر المسارات طلباً. يمكن البدء بـ HTML و CSS و JavaScript ثم إطار عمل واحد مثل React أو Laravel. مناسب للعمل الحر والوظائف التقليدية. SOC Analyst Tier 1 مناسب لمن يميل للأمن السيبراني. لا يحتاج برمجة قوية في البداية، بل فهم الشبكات، أنظمة التشغيل، SIEM، ومفاهيم الهجمات. غالباً متاح للمبتدئين في الشركات الكبيرة. IT Support / Help Desk مدخل ممتاز للمجال التقني. يعلّمك أنظمة التشغيل، الشبكات، حل المشاكل، والتعامل مع المستخدمين. كثير من المحترفين بدأوا منه ثم انتقلوا لمسارات أقوى. QA / Software Tester اختبار البرمجيات يركز على التفكير المنطقي وتحليل السلوك وليس البرمجة العميقة في البداية. يمكن البدء بالاختبار اليدوي ثم الانتقال إلى Automation لاحقاً. Junior Data Analyst مناسب لمن يحب الأرقام. يتطلب Excel، SQL، وأساسيات Python أو Power BI. أسهل من الذكاء الاصطناعي وأسرع دخولاً لسوق العمل. No-Code / Low-Code Developer مثل استخدام أدوات Bubble، Webflow، n8n، Zapier. مطلوب حالياً في الشركات الصغيرة والناشئة، ولا يحتاج برمجة عميقة. Cloud Support Associate مبتدئ في مجال السحابة (AWS / Azure / GCP). يركز على الإعدادات، المراقبة، والدعم الفني، وليس التصميم المعقد. WordPress Developer ليس مجرد تركيب قوالب فقط، بل تخصيص مواقع، متاجر، وتحسين الأداء. مناسب للعمل الحر والدخول السريع للسوق. نصيحة مهمة: اختر المسار بناءً على ميولك، وليس فقط على “ما هو الرائج”. لو تحب البرمجة اختر Web أو Back-end، لو تحب التحليل اختر Data أو SOC، ولو تحب الحلول السريعة اختر No-Code أو QA.

إذا أردت مشاريع أقل تعقيدًا من Social Media Developers Hub ولكن ما زالت تحدّي حقيقي وتعمل بالزمن الحقيقي (Real-Time) فهذه أمثلة مناسبة جدًا للتدرّب وبناء خبرة فعلية، دون أن تكون سطحية أو “لعب أطفال”: أولًا: نظام دردشة بسيط لغرفة واحدة تطبيق محادثة حيّة (Chat Room) يسمح لعدة مستخدمين بالدخول والتحدث في نفس الغرفة. ستتدرّب فيه على: التعامل مع WebSocket أو Firebase Realtime / Firestore إدارة المستخدمين المتصلين تحديث الواجهة فورًا بدون إعادة تحميل التعامل مع الرسائل والوقت (timestamps) هذا المشروع أساس ممتاز قبل أي منصة اجتماعية كبيرة. ثانيًا: نظام تتبع الطلبات (Order Tracking System) مثل نظام مطعم أو توصيل. المستخدم يطلب، والإدارة تغيّر حالة الطلب، والمستخدم يرى التحديث لحظيًا. تحدّيه الحقيقي: Real-time updates لحالة الطلب فصل الصلاحيات (مستخدم / مشرف) لوحة تحكم بسيطة هذا قريب جدًا من تطبيقات حقيقية في السوق. ثالثًا: لوحة إعلانات حيّة (Live Notice Board) تطبيق يسمح بنشر إعلانات أو تنبيهات تظهر فورًا لجميع المستخدمين. تتعلّم فيه: Real-time broadcasting إدارة المحتوى تحديث الواجهة لجميع المستخدمين بنفس اللحظة مفيد جدًا لفهم كيف تعمل الأنظمة الجماعية. رابعًا: نظام حجز مواعيد مع تحديث لحظي مثل حجز طبيب أو صالون. المواعيد المحجوزة تختفي فورًا من باقي المستخدمين. التحدي هنا: منع التعارض (Race Conditions) التحديث الفوري التعامل مع الوقت والتاريخ هذا مشروع قوي ومحبوب في المقابلات. خامسًا: نظام أسئلة وأجوبة مباشر (Mini Q&A Platform) المستخدم يطرح سؤال، الآخرون يجيبون، والتصويت يحدث لحظيًا. ستتدرّب على: Real-time voting ترتيب المحتوى ديناميكيًا التعامل مع البيانات المتغيرة باستمرار نسخة مصغّرة جدًا من StackOverflow. سادسًا: لوحة مهام جماعية (Real-Time Task Board) مثل Trello لكن بشكل مبسّط. عدة مستخدمين يضيفون ويعدّلون المهام وتظهر التغييرات فورًا. تحدياته: التزامن إدارة الحالة التعامل مع تعدد المستخدمين مشروع ممتاز لفهم التطبيقات التعاونية. لماذا هذه المشاريع أفضل لك الآن؟ لأنها: أصغر من منصة اجتماعية كاملة لكن تحتوي مشاكل حقيقية من الواقع وتجعلك تفهم Real-Time بعمق وتبني عقلية مهندس وليس مجرد كاتب كود

استعمال Bootstrap أو أي إطار عمل آخر لا يُضعف مستوى المبرمج بحد ذاته، لكن طريقة الاستعمال هي التي قد تؤثر سلبًا أو إيجابًا. إطارات العمل وُجدت لتسريع العمل، وتنظيم الواجهات، وتوحيد الأسلوب، خاصة في المشاريع الحقيقية التي يُهم فيها الوقت والجودة أكثر من إعادة اختراع كل شيء من الصفر. المبرمج المحترف في الواقع العملي يستخدم الأطر باستمرار، ولا يُنظر إلى ذلك على أنه ضعف أبدًا. المشكلة تظهر فقط في حالة واحدة، وهي أن يعتمد المتعلم على الإطار دون أن يفهم الأساسيات التي يقوم عليها. فإذا كان الشخص لا يفهم كيف يعمل flexbox أو grid، ولا يعرف أساسيات CSS مثل box model أو positioning، ثم يستخدم Bootstrap فقط عن طريق نسخ الأصناف الجاهزة، هنا فعلاً سيتكوّن اعتماد زائد، وسيشعر بالعجز عند العمل بدون إطار. أما إذا تعلم الأساسيات أولًا، وفهم HTML وCSS جيدًا، ثم استخدم Bootstrap كأداة لتوفير الوقت، فلن يفقد قدرته أبدًا على كتابة كود يدويًا. بل العكس، سيصبح قادرًا على تخصيص الإطار، وتعديل سلوكه، بل وحتى الاستغناء عنه عند الحاجة. بمعنى آخر، Bootstrap لا يُعلّمك، لكنه أيضًا لا يمنعك من التعلّم. أنت من يحدد كيف تستخدمه. من العلامات الجيدة أنك ما زلت على المسار الصحيح: أن تستطيع بناء صفحة بسيطة بدون أي إطار. أن تفهم ماذا يفعل كل class تستخدمه، ولو بشكل عام. أن تعرف كيف تحقق نفس النتيجة بـ CSS خام حتى لو لم تفعلها دائمًا. وفي الحياة العملية، كثير من المطورين الأكفاء جدًا يستخدمون Bootstrap أو Tailwind أو غيرها يوميًا، ومع ذلك يستطيعون كتابة كود نظيف بدون أي إطار عند الحاجة.

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

اولًا يجب أن تفهم طبيعة العمل أنت لا تكتب بيانات جاهزة فقط، بل ستقوم بجرد فعلي للمتجر. هذا يعني أنك ستتعامل مع عدد كبير من الأصناف، وستحسب الكميات، وتدوّن الأسعار، وربما تصحّح أخطاء أو تسأل عن منتجات متشابهة. هذا عمل يتطلب وقتًا وتركيزًا ومسؤولية. ثانيًا ما الذي يحدد السعر؟ السعر لا يُحسب هكذا مباشرة، بل يعتمد على عدة أمور، أهمها عدد المنتجات، حجم المتجر، هل الأسعار واضحة أم تحتاج سؤال صاحب المتجر، وهل ستعمل في مكان المتجر أم ستأخذ البيانات وتعمل عليها لاحقًا. لكن أبسط طريقة عادلة للتسعير هي الاعتماد على الوقت، لأنك لا تعرف مسبقًا كم صنف بالضبط. ثالثًا تسعير تقريبي عملي في العادة، إدخال بيانات منتج واحد في إكسل مع الكمية والسعر قد يأخذ من نصف دقيقة إلى دقيقة إذا كان كل شيء واضحًا. لو افترضنا أن المتجر فيه 500 منتج، فهذا يعني من 6 إلى 8 ساعات عمل تقريبًا، وربما أكثر إذا كان العمل مرهقًا. تسعير منطقي في هذه الحالة يكون بالأجر اليومي أو بالساعة، وليس بالمشروع ككل. كم تطلب؟ إن كنت في بلد عربي، فطلب أجر يوم عمل كامل يتراوح عادة بين 20 إلى 40 دولارًا حسب بلدك ومستوى الخبرة. إن حسبتها بالساعة، فبين 3 إلى 7 دولارات للساعة يعد رقمًا مقبولًا لهذا النوع من العمل. لو كان المتجر كبيرًا جدًا (ألف صنف أو أكثر)، من حقك أن تطلب أكثر أو تقسّم العمل على أيام. رابعًا كيف تتفق معه بذكاء؟ قبل أن تبدأ، قل له بوضوح إن السعر يعتمد على عدد الأصناف والوقت، واقترح أحد حلّين: إما أجر بالساعة أو أجر يومي محدد ولا تبدأ العمل قبل الاتفاق حتى لا تجد نفسك تعمل ساعات طويلة بأجر قليل. خامسًا نصيحة مهمة لا تُقلّل من قيمة عملك، فصاحب المتجر سيبني قراراته التجارية لاحقًا على هذه البيانات، وهي أساس إدارة المخزون والمحاسبة. عملك ليس مجرد كتابة، بل تنظيم معلومات مهمة.

وعليكم السلام ورحمة الله وبركاته فكرة التطبيق ممتازة ومناسبة جدًا لطبيعة الخدمات المحلية، ووجود غرف دردشة لكل قرية سيزيد التفاعل ويجعل التطبيق حيًّا فعليًا. بما أنك تستخدم Firebase فاختيارك موفق، لأنه مناسب جدًا لهذا النوع من التطبيقات. سأشرح لك الفكرة بشكل متكامل من ناحية التصميم، قاعدة البيانات، وآلية العمل، دون الدخول في تعقيد غير ضروري. أولًا: الفكرة العامة للنظام أنت لا تحتاج إلى “غرفة دردشة” بالمعنى المعقد، بل نظام رسائل بسيط مرتبط بكل قرية. كل قرية يكون لها Chat خاص بها، وأي مستخدم يدخل القرية يستطيع القراءة والكتابة ضمن هذا الشات حسب الصلاحيات. ثانيًا: أي خدمة من Firebase تختار؟ Firebase يوفر حلّين مناسبين: Cloud Firestore و Realtime Database للتطبيقات التي تعتمد على الدردشة، Realtime Database أبسط وأسرع في التنفيذ، بينما Firestore أنظم وأفضل للتوسع مستقبلاً. إن كنت في البداية، أنصحك بـ Firestore لأنه أكثر مرونة وأسهل في التحكم بالصلاحيات. ثالثًا: تصميم قاعدة البيانات (Firestore) فكرة التصميم تكون هكذا منطقيًا: collection اسمها villages داخلها documents تمثل القرى كل document يحتوي معلومات القرية (الاسم، المعرف، إلخ) داخل كل قرية، collection اسمها chatMessages كل رسالة تكون document مستقل محتوى الرسالة عادة يكون: معرّف المستخدم اسم المستخدم نص الرسالة تاريخ الإرسال (Timestamp) اختياري: نوع الرسالة (نص، صورة لاحقًا) بهذا الشكل، كل قرية لها سجل دردشة منفصل وواضح. رابعًا: ربط المستخدمين بالدردشة أي مستخدم مسجّل دخول (باستخدام Firebase Authentication) يستطيع: الدخول إلى صفحة القرية تحميل آخر الرسائل إرسال رسالة جديدة من المهم أن تعتمد دائمًا على userId القادم من Firebase Auth، ولا تسمح للمستخدم بتمرير اسمه أو هويته يدويًا حتى لا يتم التلاعب. خامسًا: عرض الرسائل في الواجهة تستخدم Listener من Firestore للاستماع للتغييرات اللحظية. عند إضافة رسالة جديدة: تظهر فورًا لكل المستخدمين داخل نفس القرية دون تحديث الصفحة. تقوم بترتيب الرسائل حسب التاريخ من الأقدم إلى الأحدث، أو العكس حسب التصميم الذي تريده. سادسًا: الحماية ومنع الفوضى هذه نقطة مهمة جدًا. يجب ضبط Firebase Security Rules بحيث: لا يسمح بالقراءة والكتابة إلا للمستخدمين المسجلين لا يسمح بتعديل أو حذف الرسائل يسمح فقط بإضافة رسالة جديدة يتم التحقق أن userId في الرسالة يساوي المستخدم الحالي بهذا تحمي النظام من التخريب أو التلاعب. سابعًا: التبليغ والإشراف بما أن الشات مفتوح للعامة، من الأفضل: إضافة زر “إبلاغ عن رسالة” تخزين البلاغات في collection منفصل أو على الأقل تسجيل الرسائل المسيئة لمراجعتها لاحقًا ويمكنك لاحقًا إضافة مشرف لكل قرية. ثامنًا: الأداء وعدد الرسائل حتى لا يبطئ التطبيق: لا تحمل كل الرسائل دفعة واحدة حمّل آخر 50 أو 100 رسالة فقط وعند التمرير للأعلى، حمّل رسائل أقدم Firebase يدعم هذا الأسلوب بسهولة. تاسعًا: التوسّع مستقبلاً بعد نجاح النظام، يمكنك إضافة: إرسال صور رد على رسالة إشعارات عند وصول رسالة جديدة غرف دردشة حسب نوع الخدمة (نقل، كهرباء، مياه، إلخ) لكن في البداية ركّز على النص فقط.

وعليكم السلام ورحمة الله وبركاته، مساء النور. عدم ظهور خيار Auto Save في قائمة File لا يعني وجود مشكلة لديك بالضرورة، وغالبًا لا يتعلق بخلل في برنامج VS Code. في بعض الإصدارات أو حسب اللغة المختارة للواجهة، قد لا يظهر خيار الحفظ التلقائي بشكل واضح داخل قائمة File، لكنه يكون موجودًا ويمكن التحكم به من الإعدادات مباشرة. يمكنك التأكد من تفعيل الحفظ التلقائي بطريقتين بسيطتين: الأولى عبر الإعدادات، حيث تفتح Settings ثم تكتب في خانة البحث Auto Save، وستجد خيارًا باسم Files: Auto Save، ومن هناك تستطيع تفعيله واختيار متى يتم الحفظ، مثل عند فقدان التركيز أو بعد تأخير زمني بسيط. الطريقة الثانية باستخدام لوحة الأوامر، وذلك بالضغط على Ctrl + Shift + P ثم كتابة Auto Save، وستظهر لك أوامر تفعيل أو تعطيل الحفظ التلقائي مباشرة. أما بخصوص التحديث، فليس من الضروري أن يكون السبب هو إصدار قديم، لأن ميزة Auto Save موجودة منذ فترة طويلة في VS Code. لكن يفضل دائمًا استخدام إصدار حديث لتفادي أي اختلافات في الواجهة أو الإعدادات. باختصار، الميزة موجودة لديك على الأغلب، لكنها مخفية داخل الإعدادات أو لوحة الأوامر وليست مشكلة تحديث.

ما قمتَ به في الصورة صحيح من حيث المبدأ، وطريقتك في التفكير سليمة تمامًا. عند كتابة: name = "Mohamad Amin" فقد قمتَ بتخزين نص (سلسلة نصية) داخل متغير. عند استخدام: name[0] فهذا يعني الوصول إلى أول حرف في السلسلة، وهو الحرف M. لكن يجب كتابة القوس بالشكل الصحيح [ ]، لأن استخدام } يؤدي إلى خطأ نحوي (SyntaxError)، وهذا ما حدث لديك في أحد الأسطر. عند كتابة: name[-3] فأنت تطلب من بايثون إرجاع ثالث حرف من نهاية الكلمة، وكانت النتيجة صحيحة. أما بخصوص تغيير حرف أو جزء من الكلمة، فهنا نقطة مهمة: السلاسل النصية في بايثون غير قابلة للتعديل مباشرة، أي لا يمكنك تغيير حرف داخل النص نفسه. لذلك الحل الصحيح هو إنشاء نص جديد باستخدام القص (slicing). عندما كتبت: name[:-3] فهذا يعني: خذ النص من البداية وحتى قبل آخر ثلاثة أحرف. وعند دمجها مع: name[:-3] + "min" فأنت أنشأت سلسلة جديدة، وكانت النتيجة: "Mohamad Armin" وهذا هو الأسلوب الصحيح لتغيير جزء من الكلمة في بايثون.

بشكل عام، الفرق بين هذه الرموز مرتبط بالغرض البرمجي منها وليس بشكلها. الأقواس الدائرية () تُستخدم غالبًا عند استدعاء الدوال أو تعريفها، وكذلك في الشروط والعمليات الحسابية لتحديد أولوية التنفيذ. عندما ترى أقواسًا دائرية فهذا يعني عادةً “نفّذ شيئًا” أو “قيّم تعبيرًا”. مثلًا عند استدعاء دالة، أو عند كتابة شرط if، أو عند تجميع عملية حسابية. الأقواس المربعة [] تُستخدم غالبًا مع البيانات المتسلسلة. ستجدها عند التعامل مع المصفوفات أو القوائم أو عند الوصول إلى عنصر معيّن باستخدام الفهرس. في بعض اللغات تُستخدم أيضًا لتعريف مصفوفة أو للوصول إلى قيمة داخل كائن باستخدام مفتاح. وجودها غالبًا يدل على “عنصر داخل مجموعة”. الأقواس المعقوفة {} لها استخدامات أوسع وتختلف قليلًا حسب اللغة، لكنها غالبًا تعبّر عن كتلة من الكود أو بنية بيانات. تُستخدم لتعريف جسم الدالة أو الشرط أو الحلقة، وتُستخدم أيضًا لتعريف الكائنات أو القواميس. عندما ترى {} فهذا يعني أنك أمام مجموعة تعليمات أو مجموعة قيم مرتبطة ببعضها. الفكرة الأساسية التي تساعدك على التمييز هي أن: () مرتبطة بالتنفيذ والتقييم [] مرتبطة بالوصول إلى عناصر {} مرتبطة ببنية أو كتلة أو تجميع منطقي مع الوقت وكثرة التطبيق سيصبح استخدام هذه الرموز بديهيًا ولن تحتاج للتفكير فيها. ملاحظة: لو كان السؤال متعلقًا بمحتوى درس معيّن أو كود داخل دورة، فنحن لا نجيب عليه هنا بهذه الطريقة. في هذه الحالة ستجد أسفل فيديو الدرس صندوق التعليقات كما هنا، ويُرجى طرح سؤالك أسفل الدرس نفسه، وليس في قسم الأسئلة العامة، وذلك حتى نعرف الدرس الذي توجد به مشكلتك ونستطيع مساعدتك بدقة

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

وعليكم السلام ورحمة الله استضافة dzsecurity هي استضافة تقليدية (Shared Hosting)، وهذا النوع من الاستضافات لا يشغّل React مباشرة لأنه لا يدعم Node.js لتشغيل السيرفر، لكن يمكن رفع موقع React عليها بعد تحويله إلى ملفات ثابتة. الفكرة ببساطة أن React أثناء التطوير يعمل كسيرفر، أما عند النشر فنحن لا نرفع المشروع كاملًا، بل نرفع الناتج النهائي فقط. أول خطوة على جهازك هي بناء نسخة الإنتاج من المشروع. تدخل إلى مجلد مشروع React وتنفّذ أمر البناء. هذا الأمر يقوم بتحويل المشروع إلى HTML وCSS وJavaScript جاهزة للتشغيل على أي استضافة عادية. بعد الانتهاء سيظهر لديك مجلد جديد غالبًا اسمه build أو dist حسب الأداة المستخدمة. بعد ذلك تدخل إلى لوحة التحكم في استضافة dzsecurity، وغالبًا ستكون cPanel. من هناك تفتح مدير الملفات وتدخل إلى مجلد public_html، لأن هذا هو المجلد الذي تُعرض منه الملفات على المتصفح. إذا كان داخله ملفات قديمة يمكنك حذفها أو نقلها. الآن تقوم برفع محتويات مجلد build نفسه إلى داخل public_html، وليس المجلد كاملًا. المهم أن يكون ملف index.html موجودًا مباشرة داخل public_html. بعد رفع الملفات، افتح موقعك من المتصفح. في أغلب الحالات سيعمل مباشرة. إذا وجدت أن التنقل بين الصفحات لا يعمل ويظهر لك خطأ 404 عند تحديث الصفحة، فهذا بسبب أن React يعتمد على routing داخلي، والاستضافة لا تعرف ذلك. لحل هذه المشكلة تحتاج إلى إضافة ملف بسيط اسمه .htaccess داخل public_html. هذا الملف يخبر السيرفر أن أي رابط غير معروف يجب أن يعود إلى index.html، وبهذا يعمل الموقع بشكل طبيعي. أيضًا انتبه قبل البناء أن تضبط المسار الصحيح للموقع. إذا كان الموقع على الدومين الرئيسي فالأمر طبيعي، أما إذا كان داخل مجلد فرعي فيجب تعديل إعدادات React قبل البناء حتى لا تتكسر المسارات. باختصار، React لا يُرفع ككود تشغيل، بل يُرفع كناتج جاهز. طالما حصلت على ملفات HTML وJS النهائية، فهذه الاستضافة كافية تمامًا. إذا أردت لاحقًا موقع React مع Backend أو API، فستحتاج إما إلى استضافة تدعم Node.js أو فصل الواجهة الأمامية عن الخلفية كل واحد على استضافة مختلفة.

العملية تتكون من 3 خطوات رئيسية داخل ملف الـ HTML الأساسي (الذي يحتوي على وسم <head>): 1. تعديل وسم الصفحة (HTML Tag) أول سطر في ملف القالب يجب أن يخبر المتصفح أن الاتجاه من اليمين لليسار. ابحث عن: <html lang="en"> واستبدله بـ: <html lang="ar" dir="rtl"> 2. استبدال ملفات CSS (الخطوة الأهم) في AdminLTE، لا يكفي مجرد تغيير الاتجاه، بل يجب استدعاء ملفات التصميم المخصصة للعربية. داخل وسم <head>، احذف أو عطل الروابط الخاصة بـ adminlte.min.css العادي، وضع بدلاً منها الروابط التالية بالترتيب: <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Cairo:400,600&display=swap"> <link rel="stylesheet" href="{% static 'plugins/fontawesome-free/css/all.min.css' %}"> <link rel="stylesheet" href="https://cdn.rtlcss.com/bootstrap/v4.2.1/css/bootstrap.min.css"> <link rel="stylesheet" href="{% static 'dist/css/adminlte.rtl.min.css' %}"> ملاحظة: إذا لم تجد ملف adminlte.rtl.min.css في مجلدات مشروعك، يمكنك استخدام رابط الـ CDN المباشر مؤقتاً للتجربة: <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/admin-lte@3.1/dist/css/adminlte.rtl.min.css"> 3. ضبط الخط (Font) لجعل النصوص تظهر بخط "القاهرة" (Cairo) الذي أضفناه، أضف هذا التنسيق البسيط في الـ <head> أو في ملف الـ CSS الخاص بك: <style> body, h1, h2, h3, h4, h5, h6, .btn, .sidebar { font-family: 'Cairo', sans-serif !important; } </style> ملخص التغييرات في ملف base.html: بعد التعديل، يجب أن يبدو الجزء العلوي من ملفك بهذا الشكل تقريباً: {% load static %} <!DOCTYPE html> <html lang="ar" dir="rtl"> <head> <meta charset="utf-8"> <title>لوحة التحكم</title> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Cairo:400,600&display=swap"> <link rel="stylesheet" href="https://cdn.rtlcss.com/bootstrap/v4.2.1/css/bootstrap.min.css"> <link rel="stylesheet" href="{% static 'dist/css/adminlte.rtl.min.css' %}"> <style> body { font-family: 'Cairo', sans-serif !important; } </style> </head> <body class="hold-transition sidebar-mini"> ... طبق هذه الخطوات واعمل Refresh للصفحة (يفضل مسح الكاش بـ Ctrl + F5)، وستجد القائمة الجانبية انتقلت لليمين والنصوص تظهر بشكل عربي سليم.

المشكلة التي تواجهها طبيعية جداً وتحدث معنا جميعاً عند الانتقال من بيئة التطوير (Development) إلى الإنتاج (Production) أو عند تجربة DEBUG = False. الخطأ (500) يعني أن "الكود الخاص بصفحة 404 نفسه فيه مشكلة" أو أن جانغو لا يستطيع الوصول إليه بشكل صحيح. إليك الحل من واقع خبرتي في هذه النقطة تحديداً: 1. مكان handler404 (السبب الأرجح) أنت ذكرت أنك وضعت الكود في main_app/urls.py. جانغو يبحث عن handler404 في ملف urls.py الرئيسي للمشروع (Project Level) وليس داخل التطبيقات الفرعية (App Level). الملف الذي يحتوي عادةً على path('admin/', admin.site.urls). الحل: انقل سطر handler404 = 'main_app.views.error404' إلى ملف urls.py الرئيسي للمشروع. 2. مشكلة الملفات الثابتة (Static Files) عندما تضبط DEBUG = False، جانغو يتوقف فوراً عن تقديم الملفات الثابتة (CSS, JS, Images). هو مصمم هكذا لأنه يفترض أنك الآن تستخدم خادم مثل Nginx أو Apache للقيام بهذه المهمة. لهذا السبب لا تظهر التنسيقات، وربما هذا هو سبب الخطأ 500 إذا كان قالب 404.html يحاول استدعاء ملفات غير موجودة بطريقة خاطئة. الحل المؤقت للمعاينة: لكي ترى الصفحة وتتأكد أن كل شيء يعمل وأنت على جهازك (Localhost) مع DEBUG = False، شغل السيرفر بهذا الأمر: python manage.py runserver --insecure هذا الأمر يجبر جانغو على تقديم الملفات الثابتة حتى لو كان الديبرج مغلقاً. 3. التحقق من الخطأ الحقيقي الخطأ 500 هو خطأ عام يخفي المشكلة الحقيقية. بما أن DEBUG = False، أنت لا ترى "Log" الخطأ في المتصفح. الحل: انظر إلى التيرمينال (شاشة الأوامر) التي يعمل فيها السيرفر، ستجد سبب الـ 500 مكتوباً هناك (غالباً سيكون TemplateSyntaxError أو مشكلة في الاستيراد Import Error بسبب نقل الـ Handler).