أنا أحاول تثبيت إصدار التطوير من Discourse على خادم Ubuntu 20.04 في DigitalOcean لغرض وحيد هو نقل منتدى FluxBB إلى Discourse، وتصديره، ثم استيراده إلى نسخة الإنتاج من Discourse.
لم أواجه أي مشكلة في تثبيت نسخة Docker الإنتاجية كاختبار (بدون نقل من FluxBB).
ومع ذلك، عندما أحاول تثبيت إصدار التطوير من Discourse باستخدام هذا الدليل:
أجد أن العملية لا تكتمل أبدًا عند تشغيل الأمر التالي:
bundle exec rake autospec
بعد انتظار حوالي 30 دقيقة حتى تنتهي العملية، يتم إنهاء جلستي عن بُعد بسبب انتهاء المهلة.
أيضًا، تظهر لي أخطاء كثيرة، للأسف ليس لدي نسخ منها الآن، لكنها جميعًا من النوع الذي يشير إلى أن بعض الدوال تُرجع دائمًا “nil”.
وبما أنني لا أعرف ما الذي يفعله هذا الأمر أو ما إذا كان ضروريًا (التعليمات تقول فقط “جرب تشغيل الاختبارات” دون توضيح ما يفعله الأمر أو سبب تنفيذه)، فقد انتقلت مباشرة إلى الأمر التالي:
bundle exec rails server --binding=0.0.0.0
وأجد أن هذا الأمر يستغرق وقتًا طويلاً أيضًا، ويظهر في الطرفية الكثير من المخرجات التي لا أفهمها، ربما تكون أخطاءً أو ربما لا.
لذا، سؤالي هو: هل هذا السلوك متوقع أم أنني أفعل شيئًا خاطئًا؟ تقريبًا، كم من الوقت يُتوقع أن تستغرق هذه الأوامر حتى تكتمل؟
وهل من الممكن ببساطة نقل منتدى FluxBB باستخدام نسخة Docker/الإنتاج من Discourse دون الحاجة إلى استخدام إصدار التطوير؟ حاليًا، ليس لدي موقع إنتاجي بعد، لذا لا أقلق بشأن إتلافه، يمكنني تدميره وإعادة إنشائه متى شئت.
لا أرى أي شيء في المتصفح. أرى عملية Ruby تعمل إذا قمت بتشغيل الأمر ‘top’ من طرفية الأوامر.
إذا كان مخرج الطرفية يستمر في العمل إلى ما لا نهاية بعد تشغيل
bundle exec rails server --binding=0.0.0.0
ألا ينبغي توضيح ذلك في الوثائق؟ عادةً، عندما أقرأ دليلًا تعليميًا، أتوقع أن يقوم الأمر بتنفيذ مهمة ما ثم ينتهي ويعرض معلومات تؤكد اكتمال التثبيت وأنني جاهز للاستخدام.
هناك عدة مواضيع تعليمية حول تشغيل عمليات الاستيراد على خوادم الإنتاج. أين يمكن العثور عليها؟ الوحيد الذي أراه مخصصًا لـ FluxBB ينص صراحةً على إجراء ذلك على تثبيت تجريبي: Migrate a FluxBB forum to Discourse
أعتقد أنه يُعتبر من البديهي أنه إذا قمت بتشغيل خادم ويب، فلا يُقصد به التوقف إلا إذا أراد المسؤول ذلك. عادةً ما تكون خوادم الويب مخصصة لتقديم الصفحات يومًا بعد يوم بعد يوم… ولكن بالتأكيد يمكن لشخص ما إضافة هذا التوضيح. يمكن لأي شخص تقديم مقترحات تحسين الدليل عبر طلب السحب (PR).
ولكن هل من البديهي أن هذا الأمر يشغّل خادم ويب؟ فهو يقول فقط rails server، وهو ما لا يجب بالضرورة أن يكون خادم ويب. فعند بدء تشغيل خادم ويب Apache، تعود فورًا إلى موجه الأوامر، ولا يطبع خادم Apache نصوصًا بشكل لا نهائي في Terminal…
Rails هو إطار عمل لتطبيقات الويب. لا أعتقد أنه من المنصف مقارنته مباشرةً بـ Apache.
أنا شخصياً أحب أن تتمكن من رؤية النظام يعمل بنشاط. فعند توقفه، عادةً ما يكون هناك خطأ ما! ويمكن أن يكون المخرجات مفيداً في بعض الظروف، خاصةً في بيئة التطوير. يمكنك تغيير كمية المعلومات المعروضة باستخدام إعدادات البيئة.
بالمناسبة، وفقاً للوثائق، يمكن تشغيل Rails كخدمة خلفية (daemonized) باستخدام المفتاح -d. لا تتردد في البحث في سبب عدم عمل هذه الميزة في التثبيت الافتراضي، فقد يكون هناك قيد يفرضه. فريق التطوير هو الأفضل للإجابة على هذا السؤال.
عندما تعتاد على تطوير Rails، ستكتشف، إذا كنت مثلي، أن ما تصفه بـ “طباعة معلومات لا حصر لها في الـ Terminal” يصبح أحد أفضل أصدقائك.
على سبيل المثال، أنا أطور حاليًا تطبيق Rails لعميل نقوم فيه بتحويل منطق أعمالهم القديم (من عقود مضت) إلى Rails. لقد اشتريت شاشة جديدة فقط لأتمكن من رؤية تلك “المعلومات التي لا تنتهي في الـ Terminal” (بعبارةك)، لأن هذه المعلومات تُعد كنزًا ذهبيًا للمطور.
إلى جانب سجل خادم Rails المذهل الذي يقدم تفاصيل دقيقة عن ما يحدث، هناك أيضًا “أفضل صديق للمطور”، وهو Rails console!
عند كتابة كود لـ Rails، أكتب المسودة أساسًا في VSC ثم أنسخ وألصق أجزاء صغيرة في Rails console للتأكد من أن كل شيء يعمل كما هو متوقع.
عند التصحيح، أكتب عبارات طباعة بلغة Ruby (مثل p و puts) داخل الكود وأراقب ما يحدث في “تدفق المعلومات الذهبي اللامتناهي لسجل خادم Rails” على الشاشة. يتم إصلاح معظم أخطائي بهذه الطريقة! كما قلت، لقد اشتريت مؤخرًا شاشة ألعاب منحنية مستقلة جديدة فقط لرؤية معلومات سجل خادم Rails التي تزعجك
يبدو من قراءتي لمنشوراتك أنك تشبهني في بداية هذا العام، حيث كنت أنتقل إلى تطبيق Rails دون خبرة سابقة في تطوير Rails. في البداية، شعرت أيضًا بالإزعاج تجاه Rails (ربما أكثر قليلاً)؛ والآن بعد مرور 9 أشهر، أطور حصريًا في Rails يوميًا للعملاء (حدودي هي العمل مع العملاء بنصف الوقت فقط لأنني متقاعد جزئيًا) وتوقفت عن جميع أعمال تطوير PHP السابقة. بصراحة، لدي شغف جديد بـ Rails (و Ruby) جدًا. كما يقول المثل: الأوان لم يفت بعد!
بخصوص Apache2، لا يوفر Apache التفاصيل الدقيقة لما يحدث خلف الكواليس في تطبيق مثل Rails. أقوم بتشغيل Apache2 كوكيل عكسي أمام جميع تطبيقات Rails الخاصة بي، وبصراحة، لا أستطيع تذكر آخر مرة نظرت فيها إلى ملف سجل Apache؛ لأنني أقوم بكل عمليات التصحيح باستخدام سجل خادم Rails الذي تزعجك منه حاليًا
في الختام، آمل بصدق أن تساعدك وجهة نظر مختلفة من شخص قام سابقًا بـ “نقل منتدى إلى Rails” بطريقة ما. بالنسبة لي، كان الإلزام بالتخلي عن تطبيقات الويب LAMP والانتقال إلى تطبيقات الويب Rails أحد أفضل “الأشياء التقنية” التي حدثت لي (شخصيًا) في عام 2020.
لقد كنت قلقًا بعض الشيء بشأن هذا الأمر مؤخرًا أيضًا. إليك ما أدركته اليوم:
سيُظهر الإخراج في طرفية rails s الكثير من الاستعلامات عند بدء التشغيل، ولكنه يشمل أيضًاإخراجًا من وظائف sidekiq الخاصة بـ discourse (على الأقل في إعدادات تطوير docker). لذلك، إذا كنت تقوم باستيراد كبير جدًا، فستحصل على قائمة انتظار sidekiq كبيرة جدًا من وظائف المعالجة اللاحقة التي قد تستمر لفترة طويلة بعد ذلك. أعتقد أن هذه وظائف غير ضرورية، مثل تحميل ذاكرة التخزين المؤقت، والتي لا يبدو أنها تمنعك من تصفح الموقع قبل انتهائها.
لقد كان هذا مربكًا للغاية بالنسبة لي لأنني أجريت استيرادًا كبيرًا، ثم تراجعت عن ذلك وأعدت تهيئة قاعدة البيانات لإجراء استيراد تجريبي صغير، ومع ذلك كان لا يزال يعمل بلا نهاية ويقوم بالاستعلام المتعلق بقاعدة البيانات الكبيرة التي لم تعد موجودة! كان الحل هو إفراغ قوائم انتظار sidekiq باستخدام وحدة تحكم rails.
