المحتوى عن 'ويب'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • مقالات عامة
  • التجارة الإلكترونية

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 25 نتائج

  1. يشهد الوِب أزهى فتراته هذه الأيام، وأعتقد أنه قد يشهد إعادة هيكلة كلية على امتداد العقد القادم لينقلب من النموذج المبني على رد فعل المستخدم - أي أننا نحن من نزور المواقع ونبحث عن التطبيقات ونثبتّها - إلى نموذج قائم على الحثّ، -أي أن الوِب هو من سيأتي إلينا ليدفعنا إلى اتخاذ إجراء-، وقد يتراجع الوِب إلى الخلفية مثل الخدمات الأساسية كالكهرباء والماء. سيكون الاتجاه العام للمحتوى والخدمات والمنتجات أن تبحث هي عنك وتجدك حين تحتاج إليها وليس العكس، فتنبهك شركة مثل Puma بميعاد شراء حذاء جديد، وتعرض عليك Mariott خيارات للغرف المتاحة حين تفوتك رحلتك، وهكذا سترسل إليك المواقع إشعارات بما يهمك وتطلب منك اتخاذ إجراء. قد تكون شركات مثل فيس بوك وFlipboard أمثلة على بوادر هذا التحول، فهي تخبرك بما تريد أن تعرفه بدلًا من محاولتها تخمين ذلك، ففيس بوك يدفع إليك سيلًا من المعلومات المفصّلة لك خاصةً، تخبرك بما يحدث مع أصدقائك وعائلتك كي تظلّ على اتصال بهم. ويجعلك Flipboard تتصفح المحتوى مرشّحًا في مكان واحد، بدلًا من بحثك أنت في مصادر متعددة بطريقة يدوية. كذلك فإن التبني المتزايد لتجارب الاستخدام المرتكزة على الإشعارات هو أحد الأمثلة على بوادر ذلك الانقلاب في نموذج الوِب الجديد، فمركز الإشعارات في هاتفك يزوّدك بسيل من المعلومات التي تهمّك، وقد صارت تفاعلية مؤخرًا بحيث قد تحجز تذكرة طائرة دون الدخول إلى تطبيق السفر، أو تشتري منتجًا دون زيارة الموقع. إن ما يحتاجه الناس في الواقع هو أن يتلقوا المعلومات بدلًا من البحث عنها بأنفسهم، فهذا يوفر عليهم وقتًا وجهدًا، وبهذا تنجح تجربة الاستخدام المحسّنة على المدى الطويل، فإن “أرني ما أحتاج إلى رؤيته” أفضل من “دعني أبحث كي أرى ما يمكنني إيجاده”، بل وأكثر فائدة أيضًا. ليس من الصعب تخيّل كيف ستمتد إلى مناطق أخرى في الوِب، فطريقة عمل التجارة الإلكترونية لا تختلف هذه الأيام عن زيارة متاجر حقيقية أو استعراض مئات المنتجات في أحد أقسام المتاجر، فليس الافتراضي أن يكون علينا البحث طويلًا عما نريد، بل سيكون الأمر أشبه بمشاهدة عرض أزياء، باستثناء أن هذا العرض كل شيء فيه مفصّل على مقاسنا وتفضيلاتنا الشخصية. أريدك أن تراقب خدمات تجارية مثل Trunk Club أو Stitch Fix، فقد تكون نهاية مراكز التسوق والمتاجر التقليدية على يد الانقلاب الذي أتوقعه للوِب. فقد تمضي بنا عشر سنين ثم ننظر إلى هذا اليوم وندرك أن اكتشاف المحتوى عن طريق البحث قد توقف، وقد لا تختفي تجارب الاستخدام المبنيّة على ترقّب فعل المستخدم على نحو كامل، لكن تجارب الاستخدام الجديدة المبنية على الحثّ ستثبت كفاءتها. إني أعلم أن البعض لن يعجبه الأمر في البداية، لكن اعلم أن مجالات مثل الرعاية الصّحية تخوض تحوّلًا مشابهًا إلى الحثّ، فبدلًا من الذهاب إلى الطبيب ستكون لدينا أنظمة متصلة بالشبكة وقادرة على التشخيص الذاتي، وما التطبيقات التي تتابع بها نشاط جسدك في ساعتك الذكية إلا بوادر هذا التحوّل الذي سيفتح فرصًا للإبداع في الرعاية الصحية. وكذلك فإن التعليم قد خطا أشواطًا واسعة في التحوّل إلى نموذج الحثّ، فلم تبحث بنفسك عن مدرسة وعن فصل دراسي في حين أن التدريب والعلم يأتيان إليك؟ فما أراه الآن هو بداية تحول يصل بين نوعين من الاقتصاد، الأول هو اقتصاد يحاول توقّع طلبات المستهلك ويبني منتجات عامة أو وفق معايير محددة، وبكميات كبيرة، ويدفع تلك المنتجات إلى السوق عبر قنوات توزيع عالمية. بينما يبني الاقتصاد الثاني منتجات عالية التخصص بناء على طلب المستهلك، وتُسَلَّم إلى المستهلكين من خلال علاقات ثنائية وتجارب شخصية حقيقية. إن هذا النموذج الجديد تحول كبير يشوّش على نماذج ربحية قائمة في الإعلانات ومحركات البحث ومتاجر التطبيقات، إضافة إلى المتاجر الحقيقية أو الافتراضية، أولئك الذين يواجهون خطر التخلّي عنهم كوسطاء في ظلة انحسار جدوى سلسلة التوزيع الحالية، وهذا مؤشر على تحوّل قوي قد يُخرج الكثيرين من ساحة الوِب قريبًا إن لم يتكيفوا مع الجديد. ترجمة - بتصرف - للمقال The Big Reverse of the Web لصاحبه Dries Buytaert. حقوق الصورة البارزة محفوظة لـ Freepik
  2. مقدّمة بعد أن ألقينا نظرة على كيفيّة استخدام إطار العمل Flask لإنشاء تطبيقات ويب بسيطة بالاستعانة بقاعدة بيانات SQLite، سنبدأ هذه السّلسلة بالدّخول إلى عالم إضافات Flask التّي ستسهّل علينا الكثير من المهام كإعداد نظام لتسجيل الدّخول والخروج، والتّعامل مع نظام قاعدة بيانات، وكذلك التّحكم في تطوير التّطبيق عن طريق سطر الأوامر؛ وكذلك استعمال أدوات لتطوير تطبيق أكثر أمانا. سنتطرّق أيضا إلى بعض المفاهيم المتقدّمة كتشفير كلمات المرور وتهجير قواعد البيانات وغير ذلك. صحيح بأنّ هذه السّلسلة مطولة نوعا ما إلا أنّها ستكون شاملة لمُساعدتك على تطوير أي تطبيق يمر على خاطرك أو يطلبه منك أحد عملائك. وإن كنت جديدا إلى عالم تطوير الويب فستتعلّم من هذه السّلسلة ما يكفي لتبدأ مشوار العمل كمطوّر تطبيقات ويب سواء عن طريق إنجاز مشاريع لعملاء على منصّات العمل الحر كمنصّة مُستقل أو بناء مشاريعك الخاصّة. سنقوم في هذا الدّرس بالتّعرف على فكرة وبنية التّطبيق الذي سنبنيه في رحلتنا هذه. المُتطلّبات بالإضافة إلى أساسيّات إطار العمل Flask، ستحتاج كذلك إلى معرفة كيفيّة التّعامل مع نماذج HTML عبر مكتبة WTForms وإضافة Flask-WTF ويُمكنك الاطّلاع على سلسلة دروس خاصّة بهذا الموضوع على الأكاديميّة. سلاسل الدّروس التّي يجب عليك أن تطّلع عليها لفهم أفضل لهذه السّلسلة من الدّروس المُتقدّمة نوعا ما، عليك أن تطّلع وتطبّق سلاسل الدّروس التّاليّة: سلسلة مدخل إلى إطار العمل Flask درس إنشاء تطبيق لاختصار الرّوابط باستخدام إطار العمل Flask بجزئيه الأول و الثاني. سلسلة التّحقق من مُدخلات المُستخدم باستخدام مكتبة WTForms وإضافة Flask-WTF ستكون لغة جافاسكربت مُفيدة كذلك، ولا مفرّ من إتقانها إن كنت ترغب بأن تُصبح مُطور ويب أفضل، كما أنّني لن أشرح كل كبيرة وصغيرة عند التّعامل معها في التّطبيق، وهذا لأنّ الهدف من السّلسلة هو تعليمك كيفيّة إتقان التّعامل مع إطار العمل فلاسك وهذا بالطّبع لا يشمل شيفرة جافاسكربت. ستحتاج كذلك إلى تعلّم أداة Git لإدارة نُسَخ التّطبيق والتّعامل مع التّطبيق بعد نشره على منصّة Heroku. ما الذي ستتعلّمه من هذه السّلسلة؟ ستتعلم في هذه السّلسلة تقنيات متقدّمة لإدارة مشاريع تطبيقات الويب، وكيفيّة التّعامل مع قاعدة بيانات PostgreSQL وأداة SQLAlchemy لإدارة الجداول (إضافة، قراءة، تعديل وحذف البيانات)، وكذلك الطرق البسيطة لتهجير قواعد البيانات Database Migration وستتعرّف كذلك على طرق توزيع ملفّات التّطبيق على شكل وحدات وحزم لتنظيم أكثر. سنستخدم كذلك مكتبة WTForms لإدارة نماذج HTML وجعلها أكثر أمانًا للحماية من هجمات مُحتملة من المُخرّبين والمُخترقين. وسنعد كذلك نظامًا أكثر أمانًا لتسجيل الدّخول واستيثاق المُستخدمين، وسنتطرّق كذلك إلى كيفيّة نشر التّطبيق إلى منصّة Heroku لتربطه بعد ذلك باسم نطاق خاصّ إن أردت ذلك. ستتعلّم كذلك طريقة حماية كلمات المرور عن طريق تشفيرها في قاعدة البيانات باستعمال خوارزميّة Bcrypt للتّشفير، وذلك لتجنّب حفظها كنصّ مجرّد يسهل استخدامه من طرف المُخترق إذا وصل إلى قاعدة البيانات. وقد تعرّفنا سابقًا على كيفيّة استعمال الجلسات Sessions لإنشاء نظام تسجيل دخول وخروج بسيط، صحيح بأنّ ذلك النّظام يعمل بشكل جيّد، إلّا أنّه لا يعد آمنًا، ويُمكن أن يتعرّض تطبيقنا لهجمات كثيرة من قبل المُخترقين، ولحماية العضويات والبيانات في الموقع، سيتوجّب علينا أن نُدير الجلسات بطريقة أكثر تعقيدًا، لكنّ هناك إضافة لإطار العمل فلاسك لتبسيط هذا الأمر ولن نحتاج إلى العمل على ذلك بأنفسنا، وبالتّالي فسيُصبح تطبيقنا أكثر أمانًا دون عناء كبير، وكلّ هذا وأكثر سنتعلّمه بتفصيل أكبر في الدّروس القادمة. بنية التّطبيق التّطبيق الذي سنعمل عليه في هذه السّلسلة من الدّروس عبارة عن نظام إدارة محتوى ومنصّة للتّدوين الجماعي، ستكون هناك بعض الميّزات الفريدة وستكون هناك ميّزات أخرى مفقودة، إذا سبق لك وأن تعاملت مع أحد أنظمة التّدوين الأخرى كمنصّة ووردبريس WordPress، Blogger أو Tumblr أو حتى منصّة medium فستتمكّن بنهاية هذه السّلسلة من التّخلي عن هذه المنصّات وإنشاء منصّة بسيطة خاصّة بك لتكتب عليها، أو تستطيع تعديل المشروع بعد الانتهاء منه لتُضيف ميّزات أخرى أو تُطبّق فكرة فريدة لتطرح مشروعًا على أرض الواقع لتتمكّن من الاستفادة منه ماديّا إن أردت ذلك. سيتمكّن مُستخدمو المنصّة من إنشاء حساب خاصّ بهم لينشروا مقالاتهم التّي يكتبونها، إضافة المقالات ستتمّ عن طريق كتابتها بتنسيق الماركداون Markdown ومن ثمّ نشرها، سيتمكّن كلّ مُستخدم من الحصول على رابط خاصّ بمقالاته لنشرها للآخرين، سيتمكّن الكاتب من إضافة وسوم لمقالاته، وكذلك إدراجها ضمن قسم معيّن، لكل مقالة قسم للتّعليقات ليتمكّن المُستخدمون الآخرون من التّعليق على مقال معيّن. سيكون للتّطبيق نكهة اجتماعيّة، بحيث سيتمكن المُستخدمون من مُتابعة بعضهم البعض، وكذلك إضافة مقالات إلى المُفضّلة والإعجاب بها لنتمكّن من فرزها وترتيبها حسب الأكثر إعجابًا، الأكثر نشاطًا (أكبر عدد من التعليقات) وبعدها ستتمكّن من إضافة خاصيّات أخرى بنفسك باتّباع نفس الطّريقة، مثلًا بعد الانتهاء من التّطبيق ستتمكّن من تطبيق فكرة ترتيب المقالات حسب الأكثر إعجابًا لإضافة خاصيّات أخرى (الأكثر شعبيّة حسب عدد التّعليقات، الأكثر زيارة...). صحيح بأنّنا سنبني تطبيقًا مُعقّدا وكبيرًا، إلّا أنّني لن أشرح كلّ شيء بتفصيل ممل، سأشرح بالتّفصيل فقط الأفكار الجديدة وما تراه لأوّل مرّة حتى لا تكون هذه السّلسلة أطول من اللازم، خاصّة وأنّ بعض الأساليب ستكون مُشابهة جدّا لبعضها البعض، فمثلاً طريقة السّماح للمُستخدم بإضافة مقال خاص به مُشابهة جدّا لطريقة فرز المقالات حسب قسم مُعيّن (لكل مُستخدم مقالاته ولكلّ قسم مقالاته كذلك). سنضع للتّطبيق بعض الميّزات المُفيدة كنظام أرشفة لتأريخ كلّ مقال حسب تاريخ إضافته، كما سيكون لتعليقات المقال نظام مُشابه، وسنستغل نفس الطّريقة لتخصيص تاريخ انضمام للمُستخدم. في النّهاية، تذكّر بأنّ هذه السّلسلة من الدّروس ستكون تطبيقيّة بالدّرجة الأولى، وستتعلّم فيها كيفيّة بدء مشاريعك التّطويريّة الخاصّة بك بلغة بايثون وإطار فلاسك، أمّا كيفيّة الاستفادة القصوى منها فمعروفة، عليك تطبيق ما تعلّمته وتختبر مع إضافة ميّزات ولو لم أذكرها، وإن أردت معرفة معمّقة عن أي شيء تحدّثت عنه دون أن أفصّل، يُمكنك دائما العودة إلى التّوثيق الرّسمي للأدوات والمكتبات والإضافات المعنيّة بالأمر، وإن كان لك سؤال معيّن فلا تتردّد في طرحه على قسم الأسئلة والأجوبة على الأكاديميّة. هناك المزيد الدّروس التّي ستندرج تحت هذه السّلسلة لن تُغطي فقط ما قرَأتَهُ للتّو، بل أكثر من ذلك، فهدفي من كتابة سلسلة الدّروس هذه هو تغطيّة الفراغ الموجود في الويب العربي، إذ أنّ التّوثيقات الرّسميّة للمكتبات وأطر العمل المُستعملة حاليّا عادة ما تكون مكتوبة باللغة الانجليزيّة فقط، لذا بتوفير سلسلة دروس كهذه ستمتلك أكبر قدر مُمكن من المُساعدة لتتمكّن من العمل على تطبيقاتك الخاصّة دون أن تضطر إلى اتّباع سلسلة دروس أخرى أو الاطّلاع على التّوثيقات الرّسميّة التّي عادة ما تكون مُفيدة أكثر إذا ما أردت أن تُنجز شيئًا بسيطًا، وعلى العكس من ذلك، فكتابة تطبيق كامل (كما في هذه السّلسلة) طريقة أفضل للتّعلم. ختاما هذا المقال عبارة عن مُقدّمة بسيطة لما سنخوضه في قادم الدّروس، في الدّرس القادم، ستبدأ المُتعة مع استكشاف كيفيّة التّعامل مع ملفّات ومُجلّدات التّطبيقات الكبيرة والمُعقّدة بطريقة بسيطة.
  3. مقدّمة بعد أن تعرّفنا على بنية التّطبيق الذي سنبنيه سويا، سنبدأ بتهيئة وتنصيب بعض الحزم التّي سنعتمد عليها، وسنرى كيف يُمكننا تنظيم الملفّات لمرونة أكثر في التّعامل مع المشاريع الكبيرة، فعوضا عن وضع الشيفرة كاملة في ملفّ أو ملفّين، سنقوم باستعمال مبدأ المُخطّطات Blueprints الذي يوفّره لنا إطار العمل فلاسك لتنظيم التّطبيقات الأكثر تعقيدا. بنية التّطبيق المُعتادة سابقا، كنّا نستعمل ملفّا رئيسيّا واحدا ونقوم بتشغيله ليعمل الخادوم ونتمكّن من الوصول إلى التّطبيق عبر المُتصفّح من العنوان المُعتاد، وهكذا تكون جميع الموجّهات في ملفّ واحد، والملفّات السّاكنة في مجلّد واحد، وملفّات القوالب (ملفّات HTML) تكون جميعها في نفس المُجلّد. ملفّات التّطبيق المعتادة تكون على الشّكل التّالي: ├── app.py # ملفّ التّطبيق الرّئيسي ├── config.py # ملفّ الإعدادات ├── static # مجلّد الملفّات السّاكنة │ ├── css │ │ └── style.css │ ├── img │ │ └── logo.png │ └── js │ └── main.js ├── templates # مجلّد القوالب │ ├── index.html │ ├── posts.html مادام التّطبيق بسيطا فكلّ شيء سيكون على ما يرام، لكن ماذا لو كان التّطبيق يمتلك قسما لتسجيل المُستخدمين، عرض صفحاتهم الشّخصيّة، عرض المقالات، صفحات الأخطاء (مثل عدم تواجد صفحة أو خطأ بالخادوم …)، لوحة تحكّم للمُدير، لوحات التّحكم بأجزاء التّطبيق، واجهة برمجيّة للمُطوّرين API وغير ذلك من الخصائص التّي يتمتّع بها كل تطبيق كبير ذو وظائف مُتعدّدة. إن استعملت البنية المُشار إليها سابقا، ستواجه العديد من المشاكل، أولا سيكون الملفّ الرّئيسي مليئا بالموجّهات والدّوال، وقد يصل إلى آلاف الأسطر البرمجيّة ما سيجعل مهمّة الصّيانة وإضافة خصائص جديدة أمرا صعبا، كما أنّ ملفّات القوالب ستكون مجتمعة في مجلّد واحد، وإن كنت تعمل على تطوير التّطبيق مع فريق من المُطوّرين فسيجد كل شخص نفسك أمام ملفّات وشيفرات لا علاقة له بها، مثلا لو قُسّمت المهام بحيث يعمل كلّ مطوّر على قسم معيّن من التّطبيق، زيد هنا يعمل على نظام تسجيل للمُستخدمين، وعامر يعمل على إضافة قسم لعرض آخر التّعليقات المُضافة، وسعيد، مُصمّم الويب يعمل على تصميم صفحات أخطاء جميلة، وعبد القادر يعمل على لوحة تحكّم الإدارة، فكيف يُمكن لزيد أن يُعدّل الشيفرة التّي تقوم بتسجيل المُستخدمين دون المساس بالشّيفرة التّي تقوم بإعداد المقالات لعرضها على صفحة المقالات؟ المُخطّطات Blueprints المُخطّطات في فلاسك نظام لتجميع الموجّهات المُخصّصة لوظيفة مُعيّنة بعيدا عن المُوجّهات الأخرى، يُمكن كذلك تقسيم ملفّات القوالب والملفّات السّاكنة كذلك مع إتاحة خيار مُشاركة ملفّات مُحدّدة إن أردت ذلك. في هذا المشروع سنضع مجلّد قوالب لكلّ وظيفة، أمّا مُجلّد الملفّات السّاكنة فسيكون مُشتركا بين جميع القوالب، وهذا لأنّنا لن نحتاج إلى الكثير من ملفّات جافاسكريبت وملفّات css، وستكون الصّور مُشتركة كذلك. هناك نوعان معروفان من المُخطّطات، النّوع الأول يُقسّم ملفّات القوالب مع كلّ وظيفة ليكون كالتّالي: . ├── run.py ├── config.py ├── project │ ├── __init__.py │ ├── posts │ │ ├── __init__.py │ │ ├── templates │ │ │ ├── index.html │ │ │ ├── post.html │ │ │ ├── posts_by_category.html │ │ ├── views.py │ ├── static │ │ └── css │ │ └── style.css │ ├── templates │ │ ├── base.html │ └── users │ ├── __init__.py │ ├── templates │ │ ├── login.html │ │ └── register.html │ ├── views.py أمّا النّوع الثّاني فتجتمع فيه جميع ملفّات HTML في مُجلّد واحد كما يلي: . ├── run.py ├── config.py ├── project │ ├── __init__.py │ ├── posts │ │ ├── __init__.py │ │ ├── views.py │ └── users │ ├── __init__.py │ ├── views.py │ ├── templates │ │ ├── base.html │ │ ├── posts/ │ │ ├── users/ │ ├── static │ │ └── css │ │ └── style.css في المثالين السّابقين، لدينا مُخطّطان، مُخطّط خاصّ بالمقالات تحت مجلّد posts، وآخر خاصّ بالمُستخدمين في مجلّد users، ملفّ run.py مسؤول عن تشغيل التّطبيق وأمّا ملفّات __ini__.py فهي لجعل بايثون يفهم بأنّ كلّا من مجلّد المشروع project ومجلّدي المقالات والمُستخدمين عبارة عن حزم. أمّا ملفّا views.py فسيحتويان على الموجّهات المعنيّة بكلّ وظيفة، فمثلا مُوجّه عرض المقالات “/posts” سيكون في ملفّ posts/views.py أمّا موجّه تسجيل دخول المُستخدمين /login فسيكون في ملفّ users/views.py. لإخبار فلاسك بأنّ مجلّدي posts و users عبارة عن مُخطّطات، سنعرّف أولا كائنًا من صنف Blueprint في كل من ملفّات __init__.py في المُجلّدين، وبعدها سنقوم بتسجيلهما مع تطبيقنا الذي نُعرّفه في ملفّ __init__.py الأساسي -وهو المُتواجد في مجلّد project-. لك حريّة استخدام أي نمط تُريده، ففي النّهاية إطار فلاسك مُصمّم ليُوفّر لك كامل الحريّة في طريقة تنظيمك لملفّات التّطبيق، لكن اتّباع نمط مُتعارف عليه أفضل في مُعظم الحالات. سنستخدم في مشروعنا النّمط الأول، أي أنّ ملفّات HTML ستكون منفصلة حسب الوظيفة. بايثون 3 سنستعمل في إنشائنا لهذا التّطبيق النّسخة 3 من لغة بايثون، لن يتغيّر الكثير، فالاختلاف بين Python 2 و Python 3 بسيط جدا، وسأقوم بذكر أهم الاختلافات أثناء بناء التّطبيق في الدّروس القادمة. إذا كنت لا تزال تعتمد على بايثون 2 فأنصحك بأن تنتقل إلى بايثون 3 لأنّ الدّعم لهذه الأخيرة قد أصبح كبيرا ومُعظم مُطوري بايثون يستعملونها الآن، كما أنّها أحدث نُسخة. إذا أردت أن تتعلم كيفيّة تجهيز بايثون 3 على نظامك، يُمكنك اتّباع هذا الدّرس. تطبيق كلمة بما أنّ مشروعنا عبارة عن نظام لإدارة المُحتوى، قرّرت تسميّته “كلمة”، جميع الملفّات والمجلّدات الخاصّة بالتّطبيق ستكون بداخل مجلّد باسمkalima، لذا عليك إنشاؤه الآن في المكان المُفضّل لديك، المهم أن تعرف كيفيّة الوصول إليه عن طريق سطر الأوامر. في البداية، سننشئ الملفّات التّاليّة: . ├── run.py ├── project │ ├── __init__.py │ ├── posts │ │ ├── __init__.py │ │ ├── templates │ │ │ ├── posts.html │ │ ├── views.py │ ├── static │ │ └── css │ │ └── style.css │ ├── templates │ │ ├── base.html │ └── users │ ├── __init__.py │ ├── templates │ │ ├── users.html │ │ ├── login.html │ ├── views.py يُمكنك إمّا إنشاء المُجلّدات والملفّات يدويّا أو عبر نسخ الشيفرة التّالية وحفظها في ملفّ باسم create_app.py لإنشاء الملفّات والمُجلّدات باستعمال لغة بايثون تلقائيّا. import os import sys def mkapp(app_name, blueprints): dirs = ['{}', '{}/static', '{}/static/css', '{}/templates'] static_files = ['{s}/css/style.css'] templates_files = ['{t}/index.html', '{t}/base.html'] for d in dirs: os.mkdir(d.format(app_name)) open(app_name + '/' + "__init__.py", "w").close() # project/__init__.py for b in blueprints: os.mkdir(app_name + '/' + b) # project/posts os.mkdir(app_name + '/' + b + '/templates') # project/posts/templates open(app_name + '/' + b + '/' + "views.py", "w").close() # project/posts/views.py open(app_name + '/' + b + '/' + "__init__.py", "w").close() #project/posts/__init__.py open(app_name + '/' + b + '/templates/' + b + ".html", "w").close() # project/posts/templates/index.html for sf in static_files: static_file = app_name + '/' + sf.format(s='static') # project/static open(static_file, 'w').close() for tf in templates_files: templates_file = app_name + '/' + tf.format(t='templates') # project/templates open(templates_file, 'w').close() if __name__ == '__main__': app = sys.argv[1] blueprints = sys.argv[2:] mkapp(app, blueprints) يُمكنك تنفيذ السكربت بالأمر التّالي: $ python3 create_app.py project posts users بعدها أنشئ ملفّ login.html في مجلّد project/users/templates لأنّ السكربت لن يقوم بإنشائه. عليك كذلك إنشاء ملفّي run.py وconfig.py داخل مُجلّد kalima، الملفّ الأول مسؤول عن تشغيل الخادوم/ أمّا الملفّ الثّاني فمسؤول عن إعدادات التّطبيق. خاتمة تعرّفنا في هذا الدّرس على بنية التّطبيق الذي سنبنيه وكيفيّة توزيع ملفّاته إذ أنشأنا المُجلّدات والملفّات التّي ستكون مسؤولة عن الجانب العملي للتّطبيق، في الدّرس القادم، سنبدأ بتجهيز البيئة البرمجيّة وتنصيب أهم الحزم التّي سنحتاج إليها للبدء بتطوير التّطبيق.
  4. flask_cms

    مُقدّمة بعد أن تعرّفنا على بنية التّطبيق الذي سنبنيه سويًّا باستخدام إطار العمل Flask ولغة Python، سننتقل الآن إلى العمل على تجهيز بيئة وهميّة لبايثون 3 لنقوم بتنصيب إطار Flask عليها ونبدأ بتطوير التّطبيق بمعزل عن النّظام المتواجد في الحاسوب، بعد تهيئة البيئة البرمجيّة، سنتعرّف على كيفيّة استغلال مبدأ المُخطّطات Blueprints التّي يُوفرّها لنا إطار العمل Flask لتوزيع أفضل لملفّات ومُوجّهات التّطبيق لعزل كل جزء وظيفيّ عن الأجزاء الأخرى وبالتّالي تسهيل تطوير خصائص وميّزات وكذلك تقسيم المُهمّات على أفراد الفريق البرمجي في حالة كنت تعمل على تطبيق مع أكثر من مُطوّر. إنشاء بيئة وهميّة بأداة Pyvenv أولا، سنحتاج إلى إنشاء بيئة وهميّة لعزل اعتماديات التّطبيق عن اعتماديات النّظام، وبما أنّ لديك خبرة في لغة بايثون، فلا بد بأنّك تُفكّر في استخدام أداة virtualenv، يُمكنك استخدامها إن أردت، لكنّنا سنستعمل بايثون 3 في تطويرنا لهذا التّطبيق، وإذا اتّبعت الدّرس الذي أشرت إليه في الدّرس السّابق، فستعلم بأنّه من المُفضّل استعمال أداة pyvenv للتأكّد من أنّ البيئة الوهميّة ستكون خاصّة بلغة بايثون 3 وليس بايثون 2. اتّبع الطّريقة التّقليديّة لإنشاء بيئة وهميّة باستعمال أداة pyvenv عبر السّطر التّالي: pyvenv venv إذا كنت تستخدم نظام Windows فقد لا يعمل السّطر أعلاه، لكن يُمكنك استخدام الأمر التّالي عوضا عنه: python -m venv فقط تأكّد من أنّ الأمر python يوصلك إلى مُفسّر بايثون 3 وليس مُفسّر بايثون 2. بعد انتهاء الأمر من التّنفيذ، قم بتفعيل البيئة الوهميّة بالسّطر التّالي: source venv/bin/activate بعد تفعيل البيئة الوهميّة، قم بتنصيب إطار العمل Flask باستخدام أداة pip بالسّطر التّالي: pip install Flask إذا كان السّطر ما قبل الأخير من المُخرجات كما يلي، فهذا يعني بأنّ كل شيء بخير: Successfully installed Flask itsdangerous Jinja2 Werkzeug click MarkupSafe طريقة العمل بما أنّنا أصبحنا نتعامل مع الكثير من الملفّات، عليك أن تعرف أي شيفرة ستكون في أي ملف، ولهذا سأقوم بوضع مسار الملف في أعلى الشّيفرة على شكل تعليق. وفي معظم الأحيان، لن أضع محتويات الملف كاملًا، بل سأضع الشيفرة الجديدة مُحاطة بسطرين قديمين من الأعلى والأسفل لتُدرك أي مكان يجب عليك أن تضع به الشّيفرة. مثال على الشّيفرة سيكون كالآتي: # project/users/views.py @users.route('/login') def login(): . . . login_user(user) return redirect(url_for('users.posts_by_author')) لا تقلق إن لم تفهم الأجزاء الجديدة عليك من الشّيفرة، فهي مُجرّد مثال بسيط على كيفيّة استخدام مُوجّه لمُخطّط وكيفيّة الرّبط بين الموجّهات. إنشاء المُخطّطات لدينا الآن مُخطّطان في تطبيقنا، واحد في مجلد المُستخدمين والآخر في مُجلّد المقالات. سنقوم أولا بإنشاء المُخطّط الخاصّ بالمُستخدمين في ملفّ views.py المتواجد داخل المُجلّد users كما يلي: # project/users/views.py from flask import Blueprint users = Blueprint('users', __name__, template_folder='templates', url_prefix='/users') في السّطر الأول، نستدعي Blueprint من حزمة flask، ونقوم بإنشاء كائن منها كما كنّا نقوم بإنشاء كائن app من الصّنف Flask في الماضي. المعامل الأول عبارة عن اسم المُخطّط، والمعامل الثّالث هدفه إخبار فلاسك بأنّ مُجلّد القوالب سيكون في نفس مُجلّد المُخطّط، وسيكون باسم templates ويُمكنك تغيير هذا الاسم إلى ما تشاء، لكنّنا لن نقوم بذلك، ومن المُفضّل اتّباع المُمارسات الشّائعة في مثل هذه الأمور. أمّا مُعامل url_prefix فالهدف منه وضع موجّه رئيسي قبل الموجّه المعرّف. مثلًا لتعريف الموجّه الرّئيسي / سيكون كالآتي: @users.route('/') # /users ولتعريف موجّه التّسجيل: @users.route('/register') # /users/register وكما تُلاحظ، لا أحتاج إلى تعريف /users في بداية كل مُوجّه. لو لم نُخصّص مُجلّدًا للقوالب، لكان علينا جمع جميع ملفّات HTML في مجلّد project/templates. هناك كذلك خيار لتفريق مجلّد الملفّات السّاكنة بنفس الطّريقة: users = Blueprint('users', __name__, template_folder='templates', static_folder='static', url_prefix='/users') ولأنّنا سنجمع جميع الملفّات السّاكنة في مُجلّد project/static فهذا الخيار لن يكون مُفيدًا لنا. يُمكنك الآن إنشاء المُخطّط الخاصّ بالمقالات بنفس الطّريقة. # project/posts/views.py from flask import Blueprint posts = Blueprint('posts', __name__, template_folder='templates', url_prefix='/posts') تسجيل المُخطّطات مع التّطبيق الرّئيسي بعد أن قُمنا بإنشاء مُخطّطات، حان الوقت لإخبار إطار فلاسك بأنّ هذه المُخّططات تابعة للتّطبيق، وطريقة القيام بذلك بسيطة. افتح الملف project/__init__.py وضع به ما يلي: # project/__init__.py from flask import Flask app = Flask(__name__) from project.posts.views import posts from project.users.views import users app.register_blueprint(posts) app.register_blueprint(users) @app.route('/') def index(): return 'Project Index' السّطران الأولان معروف بأنّهما لإنشاء التّطبيق، أمّا الاستدعاءات فهي لاستدعاء المُتغيّرين اللذين يحملان المُخطّطان، أمّا الأسطر الأخيرة فهي لتسجيل المُخطّطات التّي استدعيناها. أمّا الموجّه الذي عرّفته في الأسفل فهو ليتمكّن المُستخدم من الوصول إلى الصّفحة الرّئيسية دون الحصول على خطأ من نوع 404. ذلك لأنّ الموجّهات التّي سنعرّفها في المُخطّطات ستكون كما يلي: /posts /posts/new /users /users/register . . . لذا إن دخل المُستخدم إلى العنوان 127.0.0.1:5000 فلن يجد شيئا لأنّنا لم نُحدّد الموجّه الرّئيسي /، وهذا هو السّبب الذي جعلنا نُضيف المُوجّه بملفّ __init__.py في مجلّد المشروع project. إنشاء مُوجّهين رئيسيّين قلنا سابقًا بأنّ المُوجّهات ستكون داخل ملفّات views.py فإن أردنا أن نعرّف مثلًا موجّهًا للمقالات الرّئيسية، فسنقوم بذلك في ملّف posts/views.py أمّا الخاص بالمُستخدمين فسيكون في ملفّ users/views.py وهكذا. سنقوم الآن بإنشاء مُوجّه رئيسي لكل مُخطّط. أولا موجّه /posts/ سيكون كما يلي (ضعه مُباشرة بعد سطر تعريف المُتغيّر posts): # project/posts/views.py @posts.route('/') # 127.0.0.1:5000/posts def index(): return 'Posts Index' أمّا المُوجّه الخاصّ بالمُستخدمين فسيكون كما يلي: # project/users/views.py @users.route('/') # 127.0.0.1:5000/users def index(): return 'Users Index' وبهذه التّغييرات سيُصبح الملفّ views.py الخاصّ بالمُستخدمين كما يلي: from flask import Blueprint users = Blueprint('users', __name__, template_folder='templates', url_prefix='/users') @users.route('/') # 127.0.0.1:5000/users def index(): return 'Users Index' وملفّ views.py الخاص بالمقالات سيكون كالآتي: from flask import Blueprint posts = Blueprint('posts', __name__, template_folder='templates', url_prefix='/posts') @posts.route('/') # 127.0.0.1:5000/posts def index(): return 'Posts Index' تشغيل الخادوم بعد أن قمنا بتسجيل المُخطّطات وأنهينا أساسيّات التّطبيق، علينا أن نقوم بتشغيل الخادوم لنتمكّن من مُعاينة ما قُمنا به، ولتشغيل التّطبيق، سنضع السّطر المسؤول عن الأمر في ملفّ باسم run.py في مجلّد kalima. محتويات الملفّ ستكون كالتّالي: # run.py from project import app app.run(debug=True) كما تُلاحظ، استدعينا الكائن app الذي سبق وأن عرّفناه في ملفّ project/__init__.py بعدها نقوم بتشغيل الخادوم بالطّريقة المُعتادة مع خيار تصحيح الأخطاء. بعد حفظ ملفّ run.py يُمكنك تشغيله عبر سطر الأوامر: $ python run.py ستُلاحظ بأنّ الخادوم قد بدأ بالاشتغال كما العادة، لكنّ طريقة تشغيل الخادوم بهذه الطّريقة غير منصوح بها لأنّ النّسخة رقم 0.11 من Flask التّي أطلقت في أواخر عام 2016 جاءت بطريقة جديدة لتشغيل الخادوم عبر تنفيذ الأمر flask run. لكن الأمر flask run لن يعمل إلّا بعد تحديد اسم الحزمة أو الوحدة التّي يتواجد بها تطبيق Flask، وذلك عبر تعريف مُتغيّر بيئة باسم FLASK_APP وإعطائه القيمة حسب مكان تواجد تطبيق Flask الخاص بك. لتعريف مُتغيّر البيئة يُمكنك تنفيذ الأمر التّالي من الطّرفيّة بعد التّأكد من أنّ البيئة الوهميّة لديك مُفعّلة: $ export FLASK_APP=app.py في نظام Windows يجب عليك استخدام الكلمة المفتاحيّة set عوضا عن export: > set FLASK_APP=app.py في المثال أعلاه، نفترض بأنّ شيفرة تطبيق Flask مُتواجدة في الملفّ app.py. بعد تعريف مُتغيّر البيئة يُمكنك تشغيل الخادوم عبر تنفيذ الأمر التّالي: flask run عوضًا عن الأمر: python app.py في مشروعنا، تطبيق Flask مُتواجد داخل ملفّ __init__.py في مُجلّد project لذا فطريقة تعيين مُتغيّر البيئة سيكون كالتّالي: $ export FLASK_APP=project/__init__.py بعد تحديد مُتغيّر البيئة، يُمكنك تجربة تشغيل الخادوم: flask run بعد تنفيذك للأمر أعلاه، يجب أن تحصل على مُخرج كما يلي: * Serving Flask app "project" * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) لتفعيل مُصحّح الأخطاء، كل ما عليك فعله هو تعريف مُتغيّر البيئة FLASK_DEBUG وتعيين القيمة 1 له: export FLASK_DEBUG=1 مُلاحظة: أذكّر بأنّ تفعيل مُصحّح الأخطاء في بيئة الإنتاج أمر خطير، ولا يجب عليك أبدًا أن تقوم بذلك حتى ولو كنت مُتأكّدًا من أنّ تطبيقك خال من الأخطاء، وعليك أن تُدرك بأنّ مُصحّح الأخطاء مصمّم لمُساعدتك على تطوير واختبار التّطبيق وليس لتفعيله بعد نشر التّطبيق على الأنترنت. ومُجدّدًا، استبدل export بالكلمة set إذا كنت تستخدم نظام Windows. بعد تشغيل الخادوم مع وضع تصحيح الأخطاء، فسيكون المُخرج مُشابها لما يلي: * Serving Flask app "project" * Forcing debug mode on * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) * Restarting with stat * Debugger is active! * Debugger pin code: 573-756-626 وإن أردت أن يصل الآخرون في شبكتك إلى موقعك، تستطيع إضافة --host=0.0.0.0 إلى أمر تشغيل الخادوم كما يلي: flask run --host=0.0.0.0 بعد تشغيل الخادوم ستتمكّن من الوصول إلى الموجّهات الثلاثة التّي سبق وأن عرّفناها. 127.0.0.1:5000/ 127.0.0.1:5000/posts 127.0.0.1:5000/users وستُلاحظ النّتائج: Project Index Posts Index Users Index خاتمة تعرّفنا في الدّرس على كيفيّة إنشاء مُخطّطات وتسجيلها لمرونة أكثر في التّطوير ولإدارة أفضل للتّطبيقات الكبيرة، وتعرّفنا كذلك على كيفيّة تشغيله وكيفيّة إضافة مُوجّه لكل مُخطّط، في الدّرس القادم سنتعرّف على كيفيّة التّعامل مع قوالب HTML وكيفيّة الرّبط بين مُختلف موجّهات التّطبيق.
  5. مُقدّمة: بعد أن قمنا بتنظيم ملفّات التّطبيق على حسب الوظيفة باستعمال خاصيّة المُخطّطات، أصبح لدينا اختلاف بسيط في كيفيّة التّعامل مع ملفّات العرض التّي تحتوي على شيفرات HTML وشيفرات مُحرّك القوالب Jinja، وسيكون هناك اختلاف بسيط أيضا في طريقة استخدام الدّالة url_for للرّبط بين المُوجّهات. إنشاء صفحات HTML بما أنّنا أنشأنا ثلاثة مجلّدات باسم templates لتعدّد أغراضها، فسيتوجّب علينا أن نفهم أولا كل مجلّد ووظيفته. مسارات المُجلّدات التّي أنشأناها سابقا هي كالآتي: project/templates/ project/posts/templates/ project/users/templates/ المسار الأول عبارة عن مجلّد رئيسي للقوالب، يُمكنك أن تعتبره مُشتركا مع القوالب الأخرى، فمثلا يُمكن لكل من ملفّات المقالات والمُستخدمين أن يرثوا من ملفّ base.html كما سنوضّح بعد قليل، كما أنّ أي موجّه يُعرّف داخل الملفّ الرّئيسي project/__init__.py له الحق في تقديم الملفّات المُتواجدة في مجلّد القوالب الرّئيسي مُباشرة. أي أنّك تستطيع تعديل الموجّه الرّئيسي ليُقدّم القالب index.html المتواجد داخل مجلّد project/templates كالآتي: # project/__init__.py from flask import Flask, render_template #... #... @app.route('/') # 127.0.0.1:5000/ def index(): return render_template('index.html') # render project/templates/index.html لا تنس بأنّنا استردنا أولا الدّالة render_template ثمّ استدعيناها في المُوجّه لتقديم الملفّ index.html. بنفس الطّريقة سنقوم بتقديم كلّ من ملفّي posts.html الخاصّ بالمقالات و users.html الخاص بالمُستخدمين. حدّث المُوجّه في مُخطّط المقالات ليُصبح كما يلي: # project/posts/views.py from flask import Blueprint, render_template @posts.route('/') # 127.0.0.1:5000/posts def index(): return render_template('posts.html') # render project/posts/templates/posts.html وهكذا سيكون الموجّه الجديد في المُخطّطات الخاصّة بالمُستخدمين: # project/users/views.py from flask import Blueprint, render_template @users.route('/') # 127.0.0.1:5000/users def index(): return render_template('users.html') # render project/users/templates/users.html هكذا إن طلب الزّائر أي صفحة من الصّفحات الثّلاث فسيُقدّمُ ملفّ HTML المُناسب. استخدام إطار Bootsrap لتنسيق الصّفحات الهدف من هذه السّلسلة هو التّعريف بكيفيّة إنشاء تطبيقات ويب ديناميكيّة بلغة بايثون وإطار فلاسك ولن أتطرّق إلى لغات أساسيّة مثل HTML و css وJavascript، ولأنّ تطبيقات الويب في يومنا هذا أصبحت تعتمد كثيرا على المظهر الجميل والاستخدام المرن باستعمال كل من لغتي css وjavascript، فمن الضّروري أن نستعمل إطار عمل لسد هذا الفراغ وإتاحة تصميم أنيق لتطبيقنا. سنستخدم في هذا المشروع إطار bootsrap 3 الذي يُمكنك تحميله من الموقع الرّسمي وفك الضّغط عن ملفّ zip داخل مجلّد project/static، سأعتمد كذلك على مشروع Bootsrap-rtl لتعريب وتوجيه التّنسيق من اليمين إلى اليسار وسأضعه في مجلّد project/static/css كما سأضع مكتبة jquery داخل مجلّد project/static/css/bootstrap لذا تأكّد من أنّك قد جهّزت كلّ شيء قبل أن تبدأ في استدعاء الملفّات السّاكنة. بعد تجهيز مُجلّد static ستكون المُجلّدات والملفّات بداخله كما يلي: project/static/ ├── bootstrap │ ├── css │ │ └── bootstrap.min.css │ └── js │ ├── bootstrap.min.js │ └── jquery.js └── css ├── bootstrap-rtl.min.css └── style.css قد تكون هناك ملفّات إضافيّة حسب ما قُمت بتنزيله عندما نزّلت إطار العمل Bootstrap، لكنّ الملفّات أعلاه هي الأهم وهي التّي سنحتاج إليها حاليّا. إذا أردت إضافة ملفّات Javascript أخرى، فيُمكنك إمّا أن تضعها داخل مُجلّد js المُتواجد داخل المُجلّد bootstrap أو أن تُنشئ مُجلّدا جديدا باسم js داخل مُجلّد الملفّات السّاكنة static. الوراثة في قوالب Jinja2 لنقل بأنّنا نُريد عرض جملة واحدة في كل ملف من ملفات HTML الثلاثة. يُمكن أن أقوم بما يلي في كل ملفّ: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title></title> </head> <body> Hello </body> </html> مع تعويض Hello بالجملة التّي ارغب في عرضها عند طلب كل موجّه. هذه الطّريقة تعمل بشكل جيّد، لكن ألا تُلاحظ بأنّنا سنُكرّر نفس الأسطر في كلّ ملف؟ عوضا عن تكرار الأسطر في كلّ ملف يُمكننا استعمال مبدأ الوراثة في مجرّك القوالب Jinja. وللاستفادة من هذا المبدأ في المثال السّابق، يُمكن أن نكتب الأسطر التّي تتكرّر في كل ملف في ملفّ رئيسي واحد يُعتبر القاعدة لجميع الملفّات الأخرى، وهذا هو دور ملفّ project/templates/base.html الذي أنشأناه سابقا، ففيه يُمكننا وضع الأسطر السّابقة مع تخصيص المكان الذي سنستطيع كتابة الجملة الخاصّة بكل ملف فيه. افتح ملفّ base.html وضع فيه ما يلي: {# project/templates/base.html #} <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>{% block title %} {% endblock %}</title> <script src="{{ url_for("static", filename="bootstrap/js/jquery.js") }}"></script> <script src="{{ url_for("static", filename="bootstrap/js/bootstrap.min.js") }}"></script> <link rel="stylesheet" href="{{ url_for("static", filename="bootstrap/css/bootstrap.min.css") }}"> <link rel="stylesheet" href="{{ url_for("static", filename="css/style.css") }}"> <link rel="stylesheet" href="{{ url_for("static", filename="css/bootstrap-rtl.min.css") }}"> </head> <body> {% block content %} {% endblock %} </body> </html> احفظ الملف وأغلقه. لاحظ بأنّنا قمنا باستدعاء جميع الملفّات التّي سنحتاج إليها للتّنسيق وإضافة ميّزات أخرى بلغة Javascript، وقُمنا كذلك بوضع كتلة Block باسم title لتعويضها بالعنوان في كل ملفّ، أمّا كتلة content فهي التّي ستُعوّضُ بالمحتوى (كلمة Hello في مثالنا السّابق). يُمكنك إضافة ملفّات أخرى إلى مُجلّد static، لكن لا تنس أن تقوم باستيرادها في ملفّ base.html لكي تعمل في جميع الصّفحات. بعد تجهيز الملفّ base.html الذي سيُشكّل قاعدة للملفّات الأخرى، سنُنشئ الآن ثلاثة ملفّات HTML رئيسيّة، وهي كما يلي: ملفّ HTML للصّفحة الرّئيسية (مساره project/templates/index.html ). ملفّ HTML للصّفحة الرّئيسية للمُستخدمين (مساره project/users/templates/users.html). ملفّ المقالات الرّئيسي (مساره project/posts/templates/posts.html). لملء الملفّات، ضع الشّيفرة التّاليّة في كلّ ملفّ يُمكنك الاستعانة بالمسار المُشار إليه في التّعليق أعلى الشّيفرة للوصول إلى الملفّ بشكل أسرع. ملفّ الصّفحة الرّئيسية: {# project/templates/index.html #} {% extends 'base.html' %} {% block title %} كلمة – الصّفحة الرّئيسية {% endblock %} {% block content %} <h1> مرحبا بك في تطبيق كلمة </h1> {% endblock %} ملفّ الصّفحة الرّئيسية للمُستخدمين: {# project/users/templates/users.html #} {% extends 'base.html' %} {% block title %} كلمة – المُستخدمون {% endblock %} {% block content %} <h1> الصّفحة الرّئيسية للمُستخدمين </h1> {% endblock %} ملفّ الصّفحة الرّئيسية للمقالات: {# project/posts/templates/posts.html #} {% extends 'base.html' %} {% block title %} كلمة – المقالات {% endblock %} {% block content %} <h1> الصّفحة الرّئيسية للمقالات </h1> {% endblock %} كما ترى عوضا عن تكرار الكثير من شيفرات HTML قمنا ببساطة بإنشاء ملفّ واحد والوراثة منه باستخدام الجملة extends 'base.html' وفي كلّ مكان نضع المحتوى المناسب، وبهذه الطّريقة سنمتلك طريقة ديناميكية لتحديد عنوان ومحتوى كلّ موجّه مرتبط بقالب معيّن، بالإضافة إلى أنّ الملفّات السّاكنة مثل ملفّاتcss و js ستكون مُتاحة في جميع الملفّات التّي ترث من الملّف الرّئيسي base.html. مُلاحظة: في بعض المشاريع المكتوبة بلغة بايثون وإطار العمل فلاسك، يُمكن أن يُسمّى الملفّ المُشترك باسم layout.html عوضا عن base.html، لكنّ المبدأ هو نفسه. الآن إن عدت إلى الموجّهات السّابقة، فستُلاحظ بأنّ التّنسيق ومكوّنات كلّ صفحة قد تغيّرت. الرّبط بين المُوجّهات باستخدام الدّالة url_for بعد أن تعرّفنا على كيفيّة تقديم قوالب HTML، أصبح بإمكاننا عرض صفحات للمُستخدم حسب المُوجّه المطلوب، وبقي لنا التّعرف على كيفيّة الرّبط بين هذه الموجّهات. للرّبط بين موجّهات المُخطّطات باستخدام الدّالة url_for، نقوم أولا بوضع اسم المُخطّط ثمّ اسم الدّالة التّي يتم استدعاؤها عند الوصول إلى المُوجّه، وبما أنّنا سمينا هذه الدّوال باسم index فللرّبط بينها يُمكنك أن تقوم بشيء مُشابه لما يلي: url_for('index') # / url_for('posts.index') # /posts url_for('users.index') # /users لو كانت الدّالة تقبل مُعاملا لتوجّب علينا تمرير قيمته كالآتي: url_for('posts.post_by_id', post_id = 1) للرّبط بين الموجّهات الثّلاثة التّي سبق وأن أنشأناها سنُضيف ما يلي مُباشرة بعد وسم h1 في كل ملفّ من ملفّات HTML حسب المسار في بداية الشّيفرة. الرّوابط في الصّفحة الرّئيسية: {# project/templates/index.html #} <a href="{{ url_for("posts.index") }}"> اضغط هنا للوصول إلى صفحة المقالات </a> <br> <a href="{{ url_for("users.index") }}">اضغط هنا للوصول إلى صفحة المُستخدمين</a> رابط العودة إلى الصّفحة الرّئيسية في صفحة المقالات: {# project/posts/templates/posts.html #} <a href="{{ url_for("index") }}">اضغط هنا للعودة إلى الصّفحة الرّئيسيّة</a> رابط العودة إلى الصّفحة الرّئيسية في صفحة المُستخدمين: {# project/users/templates/users.html #} <a href="{{ url_for("index") }}">اضغط هنا للعودة إلى الصّفحة الرّئيسيّة</a> بعد حفظ الملفّات، ستجد بأنّ الصّفحة الرّئيسية أصبحت تحتوي على رابط لكلّ من صفحتي المقالات والمُستخدمين مع رابط للعودة إلى الصّفحة الرّئيسية في كل صفحة من الصّفحتين. الرّبط بين المُوجّهات مع تمرير مُعاملات للدالّة التّابعة لكل موجّه. لفهم مبدأ المعاملات أكثر، سنقوم بإضافة موجّه للوصول إلى مقال برقم مُعرّفه في ملفّ project/posts/views.py كما يلي: # project/posts/views.py #.. #.. @posts.route('/<int:id>') def post_by_id(id): return render_template('post.html', id = id) لاحظ بأنّنا خصّصنا المعامل id من نوع int أي عدد صحيح، فإن لم تكن قيمة المُعامل عند الوصول إلى الرّابط عددا صحيحا فإنّ ذلك سيُسبّب خطأ من نوع 404. بمعنى أدق، الرّابط /posts/1 صحيح، أمّا /posts/abc فسيرجع الخطأ ذو الرّقم 404. سنتعرّف على كيفيّة التّعامل مع هذه الأخطاء في درس قادم. سنضع ما يلي في ملفّ post.html الذي قدّمناه: {% extends 'base.html' %} {% block title %} كلمة – المقال ذو المُعرّف {{ id }} {% endblock %} {% block content %} <h1> صفحة المقال الواحد ذو رقم المُعرّف {{id}} </h1> <a href="{{ url_for("index") }}">اضغط هنا للعودة إلى الصّفحة الرّئيسيّة</a> {% endblock %} لنستخدم الآن الدّالة url_for داخل ملفّ posts.html لضرب مثال على كيفيّة تمرير مُعاملات إلى الدّالة. أضف ما يلي إلى ملفّ posts.html مُباشرة بعد الوسم <h1>: <a href="{{url_for("posts.post_by_id", id=1)}}"> <h2> رابط المقال الأول </h2> </a> <a href="{{url_for("posts.post_by_id", id=2)}}"> <h2> رابط المقال الثّاني </h2> </a> الآن، إن دخلت إلى صفحة المقالات فستلاحظ رابطين لمقالين وهميّين، الأول رقم معرّفه 1 والآخر رقم مُعرّفه 2، ورابط المقالين كالتّالي: http://127.0.0.1:5000/posts/1 http://127.0.0.1:5000/posts/2 يُمكنك كذلك زيارة صفحات أخرى عبر تغيير قيمة رقم المُعرّف إلى أي عدد صحيح، والتّالي بعض الأمثلة: http://127.0.0.1:5000/posts/99 http://127.0.0.1:5000/posts/232 في المقالات القادمة سوف نعوّض جملة “صفحة المقال ذي المُعرّف رقم * ” بعنوان المقال وسنعرض محتواه وقسمه أسفل العنوان مع الوسوم الخاصّة بالمقال، وذلك بجلب كل مقال حسب رقم مُعرّفه في قاعدة البيانات. خاتمة تعرّفنا في هذا الدّرس على جزء آخر من أساسيّات تطوير تطبيقات ويب أكثر تعقيدا وذات مهام مُتعدّدة، هذا الدّرس يُمثّل قسما صغيرا فقط ممّا يجب عليك معرفته حول كيفيّة التّعامل مع قوالب HTML ومحرّكها Jinja الذي يُرافق إطار العمل Flask افتراضيّا، لكنّك ستجده في مشاريع بايثون أخرى تتعلّق بتطوير الويب وبعض المجالات الأخرى ولو لم يكن إطار Flask حاضرا، لذا فتعلّم أساسيّات Jinja سيُخوّلك لتعلّم أساسيّات أطر عمل أخرى ومُختلف الأدوات التّي تعتمد عليه بشكل أسرع.
  6. مُقدّمة تعلّمنا في الدّروس السّابقة كيفيّة إدارة مشروع مكتوب بإطار العمل فلاسك، وقد تعرّفنا في الدّرس السّابق على كيفيّة التّعامل مع قوالب HTML، في هذا الدّرس سنُكمل هذا الجزء من تطوير الويب بتعلّم أساسيّات مُحرّك القوالب Jinja الذي يأتي مُرفقا مع إطار العمل فلاسك افتراضيّا، والذّي تُعتبر أساسيّاته أمرا مُهمّا لكونه يُستعمل في العديد من مشاريع بايثون أخرى بالإضافة إلى إطار العمل فلاسك. الدّوال في Jinja يُمكننا تعريف دوال لتحمل شيفرة معيّنة مع معاملات على Jinja لإعادة استعمالها وتحقيق مبدأ DRY أو Don’t Repeat Yourself وترجمته إلى اللغة العربيّة هي “لا تكرّر نفسك” ويعني بأنّه لا يجب عليك تكرار كتابة نفس الشّيفرة، وكلّما وجدت نفسك تُكرّرها توقّف وفكّر في إيجاد حل لتجنّب هذا التّكرار، إما بوضعها في دالّة أو شيء من هذا القبيل لتسهل عليك إعادة استعمالها. في Jinja مبدأ الدّوال موجود في ما يُسمى بالماكرو macro ويُمكن تعريف واحدة كما يلي: {% macro name(param1, param2) %} . . . {% endmacro %} كما تُلاحظ، الأمر شبيه بكيفيّة إنشاء الدّوال في لغة بايثون، لاحظ فقط كيف نُنهي الجزء الخاص بالدّالة بكلمة endmacro. يُمكننا استدعاء الماكرو في مكان آخر من القالب كما نعرض قيمة مُتغيّر معيّن: {{ name('pram1_value', 'pram2_value' }} يُمكننا كذلك تعريف الماكرو دون أية مُعاملات. ومن الشّائع أن توضع في ملف باسم _helpers.html في مجلّد templates الرّئيسي، وبعدها لاستخدامه يجب استيراده في أعلى الملف كما يلي: {% from "_helpers.html" import macro_name %} مع استبدال macro_name باسم الماكرو، تأكّد فقط بأنّك تستدعيه في أعلى الملفّ عوضا عن أي مكان آخر. بعد الاستدعاء ستتمكّن من استخدامه كالمُعتاد. مثال على ماكرو هناك العديد من الاستخدامات لهذه الخاصيّة، وسنتعرّف على بعض منها أثناء تطويرنا للتّطبيق، وهذا ما جعلني أشرح الفكرة هنا لتُفهم أكثر. في هذا المثال سنقوم بإنشاء ماكرو لتحويل قائمة بايثون إلى قائمة HTML. فمثلا لو كانت لدينا القائمة التّالية: list = ['Abdelhadi', 'Ayman', 'Ibrahim'] فسنستطيع تحويلها إلى التّالي بسطر واحد: <ul> <li>Abdelhadi</li> <li>Ayman</li> <li>Ibrahim</li> </ul> أولا سنُنشئ الماكرو كما يلي: {% macro py_to_html(list) %} <ul> {% for item in list %} <li>{{ item }}</li> {% endfor %} </ul> {% endmacro %} ثمّ نستدعيه كما يلي (على فرض أنّ list عبارة عن قائمة بايثون عاديّة): {{ py_to_html(list) }} ما ستُلاحظه هو أنّ النّتيجة ستكون عبارة عن قائمة HTML تحتوي على عناصر القائمة list، وهذا طبيعي لأنّ ما يفعله الماكرو ببساطة هو الدّوران حول المُعامل list الذي يستقبله ويعرض كل عنصر من القائمة داخل وسمي <li></li>. وهذه هي ببساطة طريقة عمل الماكرو، ويُمكنك إعادة استعماله أكثر من مرّة مع تمرير مُعاملات أخرى دون الحاجة إلى إعادة الشّيفرة مرارا وتكرارا. يُمكنك كذلك إنشاء ماكرو بدون أيّة مُعاملات، فمثلا الماكرو التّالي سيقوم بعرض الجملة “مرحبا بالعالم” في كل مرّة يتمّ استدعاؤه فيه: {% macro hello_world() %} مرحبا بالعالم {% endmacro %} وطريقة استدعائه في قالب HTML ستكون كالتّالي: {{ hello_world() }} سنتعرّف أثناء تطويرنا لتطبيق “كلمة” على المزيد من الأمثلة لكيفيّة استعمال ميّزة الماكرو في مُحرّك القوالب Jinja، وإن تابعت سلسلة استعمال مكتبة WTForms مع إطار العمل Flask فلا شك بأنّك ستأخذ فكرة واضحة عن كيفيّة عمل الماكرو كما ستحصل على مثال واقعي لاستخدامه. المُرشّحات (filters) في Jinja2 المُرشّحات مبدأ جديد يتوجّب عليك فهمه لكتابة تطبيقات ويب أفضل. يُطبّق المُرشّح في مُحرّك القوالب Jinja على مُتغيّر لتغيير قيمته من حالة إلى أخرى. التّالي مثال على كيفيّة عرض قيمة المُتغيّر name في مُحرّك القوالب Jinja: {{ name }} إذا ما طبّقنا على هذا المتغيّر مُرشّحا فسيتوجّب علينا أن نقسم بين المُتغيّر والمُرشّح بعلامة |. المثال التّالي يُوضّح كيفيّة تطبيق مُرشّح وهمي سنُسمّيه filter على المُتغيّر name: {{ name | filter }} نستعمل المُرشّحات كما نستعمل في لغة Python دوال تأخذ قيمة وتقوم بعمليّة أو عدّة عمليّات على هذه القيمة وتُرجع القيمة النّهائيّة التّي تُمثّل النّتيجة. إذا ما طبقت مُرشّحا على مُتغيّر ما، فقيمة المُتغيّر يجب أن تتغيّر، وسنرى بعض أهم المُرشّحات التّي يُوفرّها مُحرّك القوالب Jinja فيما بعد. يُمكنك كذلك أن تُمرّر مُعاملات إلى مُرشّح عبر تحديد القيم داخل قوسين كما يلي: {{ name | filter(argument1, argument2, argument3) }} المُعاملات التّي تُمرّر تُحدّد نوعيّة العمليّات التّي ستخضع لها القيمة قبل أن تُرجع النّتيجة. يُمكن كذلك استخدام أكثر من مُرشّح عبر تقسيمها بالرمز | كما في المثال التّالي: {{ name | filter1() | filter2() | filter3() }} كل مُرشّح يجري عمليّة على القيمة التّي تسبقه، لذا فطريقة عمل المثال أعلاه هو كالتّالي: يأخذ المُرشّح filter1 قيمة المُتغيّر name ويُرجع نتيجة تُعتبر مُجرّد قيمة أخرى. تمرّ النّتيجة السّابقة على المُرشّح filter2 لنحصل على قيمة جديدة تُعتبر نتيجة لعمل المُرشّح filter2 على ما أرجعه المرشّح filter1. يأخذ المُرشّح filter3 القيمة التّي نحصل عليها في النّتيجة السّابقة ويُجري عليها عمليّة ثمّ يُرجع قيمة جديدة. وبما أنّ آخر قيمة حصلنا عليها هي ما أنتجه المُرشّح filter3 على ما سبقه من قيمة، فما سيظهر للمُستخدم الذي يزور صفحة HTML التّي حدث بها ما حدث هو القيمة الأخيرة. ما فائدة المُرشّحات؟ رغم أنّ المُرشّحات في Jinja يُمكن أن تُستبدل بعمليّات على المُتغيّرات قبل تقديم قالب HTML عند العمل مع إطار العمل Flask، إلّا أنّ استعمال المُرشّحات حل أفضل وأكثر مرونة، وفي بعض الحالات يُمكن أن تحفظ نفسك من تكرار الكثير من الشّيفرة إن استعملت مُرشّحا يُوفّره مُحرّك القوالب Jinja عوضا عن كتابة الشّيفرة باستعمال لغة Python في كل مرّة تحتاج فيها إلى تغيير قيمة إلى قيمة أخرى. بالإضافة إلى أنّك تستطيع إنشاء مُرشّحات خاصّة بك لتستعملها مع إطار العمل Flask وقوالب Jinja إن أردت ذلك، فمثلا يُمكنك أن تكتب مُرشّحا لتحويل تاريخ مُعيّن من الصّيغة العاديّة (1-1-2017) إلى صيغة (قبل كذا يوم/ قبل كذا شهر/ منذ X أشهر …). سنرى كذلك بعض الاستعمالات للمُرشّحات فيما بعد، فمثلا، سنرى كيفيّة استعمال مُرشّح تُوفّره لنا إضافة Flask-Gravatar (سنرى المزيد عن إضافات Flask فيما بعد) لتحويل بريد إلكتروني إلى الصّورة المُرتبطة به على خدمة Gravatar. مثال على استخدام مُرشّح لتحويل نصّ إلى أحرف كبيرة كمثال على كيفيّة استخدام مُرشّح مُتوفّر مُسبقا بحيث يُمكنك استخدامه في أي قالب HTML في مشروع Flask الخاصّ بك، سننظرُ إلى كيفيّة استخدام المُرشّح upper الذي يعمل بنفس طريقة عمل التّابع upper() في لغة بايثون، والذي يُمكنك استخدامه لتحويل نصّ عادي إلى أحرف كبيرة Uppercase. أولا، سنُضيف مُوجّها جديدا إلى ملفّ __init__.py داخل مُجلّد المشروع project، يُمكنك اعتبار هذا المُوجّه حقل تجارب لتختبر به مُختلف المُرشّحات التّي سأسردها فيما بعد ومن المُفضّل حذفه إذا انتهيت منه. سيكون المُوجّه كالتّالي: @app.route('/filters') def filters(): return render_template('filters.html') المُوجّه بسيط جدّا، والعمل الحقيقي سيكون داخل الملفّ filters.html الذي قدّمناه كجواب في الموجّه. أنشئ الملفّ filters.html داخل المُجلّد templates المُتواجد في مُجلّد المشروع project. داخل الملفّ filters.html، أضف ما يلي: {% extends 'base.html' %} {% block title %} كلمة – المُرشّحات {% endblock %} {% block content %} <h1> {{ "Hello World!" | upper() }} </h1> {% endblock %} لاحظ الجزء {{ "Hello World!" | upper() }}، إن تابعت ما سبق جيّدا، فستفهم بأنّنا قُمنا في هذا الجزء بتطبيق المُرشّح upper على السّلسلة النّصيّة Hello World ، وبالطّبع، فإنّك تستطيع أن تُعوّض السّلسلة النّصيّة بمُتغيّر يحمل نفس القيمة أو قيمة أخرى. إن زرت العنوان http://127.0.0.1:5000/filters فستُلاحظ النّص HELLO WORLD!، ما يعني بأنّ المُرشّح upper قد أدّى مهمّته. استعمال المُرشّحات مع نصّ مُتعدّد الأسطر في الأمثلة السّابقة، تعرّفنا على كيفيّة استعمال مُرشّح في سطر واحد كما يلي: {{ "Hello World!" | upper() }} لكن ماذا لو أردنا استعمال المُرشّح في جزء أكبر من الشّيفرة؟ كاستعمال المُرشّح upper مع فقرة كاملة أو نص متعدّد الفقرات. يُمكننا استخدام المُرشّح كما نستعمل الجملة الشّرطية if أو حلقة for في Jinja، وذلك عبر إحاطة ما نُريد تطبيق المُرشّح عليه بكل من {% filter upper %} و {% endfilter %}، مع تغيير upper بالمُرشّح الذي تُريد استعماله. المثال التّالي يُمثّل كيفيّة استعمال المُرشّح upper مع نصّ مُتعدّد الأسطر: {% filter upper() %} Hello World! {% endfilter %} خاتمة تعرّفنا في هذا الدّرس كيفيّة استعمال خاصيّة الماكرو في مُحرّك القوالب Jinja لتفادي تكرار شيفرة عدّة مرّات، كما تعرّفنا على ماهيّة مُرشّحات Jinja وكيفيّة استعمالها والهدف منها، في الدّرس التّالي، سنلقي نظرة على بعض من أهمّ المُرشّحات التّي تأتي مبنيّة مُسبقا في مُحرّك القوالب Jinja والتّي يُمكنك استعمالها مُباشرة مع تطبيقات فلاسك الخاصّة بك.
  7. ما هي تطبيقات الويب التي تعمل دون اتصال؟ يبدو الأمر من الوهلة الأولى كأنَّ هنالك تضاربًا في المفاهيم. فهل هي صفحات الويب التي تنزِّلها ثم تفتحها بعد ذلك؟ لكن التنزيل يتطلب اتصالًا شبكيًا، فكيف ستستطيع تنزيل الصفحة عندما لا تكون متصلًا؟ لن تستطيع فعل ذلك بكل تأكيد، لكنك تستطيع تنزيل الصفحة عندما تكون متصلًا بالشبكة، وهذه هي آلية عمل تطبيقات HTML5 التي تعمل دون اتصال (offline web applications). بأبسط الكلمات: تطبيق الويب الذي يعمل دون اتصال هو قائمةٌ بروابط URL التي تُشير إلى ملفات HTML أو CSS أو JavaScript أو الصور أو أيّ موردٍ آخر. تُشير الصفحة الرئيسية إلى تلك القائمة التي تُسمى «ملف manifest» الذي هو ملفٌ نصيٌ موجودٌ في مكانٍ ما على خادوم الويب، وسيقرأ متصفح الويب الذي يدعم تشغيل تطبيقات الويب دون اتصال قائمةَ روابطِ URL الموجودةَ في ملف manifest، ثم يُنزِّل تلك الموارد (resources)، ثم يُخزِّنها تخزينًا مؤقتًا محليًا (local cache)، ثم سيُحدِّث النسخ المحلية منها تلقائيًا في حال تغيرت. وعندما يحين وقت محاولتك الوصول إلى تطبيق الويب دون اتصالٍ شبكي، فسيحاول متصفحك عرض النسخة المُخزَّنة محليًا تلقائيًا. ومن هذه النقطة، سيُلقى الحِمل على عاتِقِكَ تمامًا –كمطوِّر ويب–؛ فهنالك رايةٌ (flag) في DOM تخبرك إذا كان المتصفح متصلًا بالشبكة أم لا، وهنالك أحداث (events) تُفعَّل عندما تتغير حالة الوصول إلى الشبكة (أي لو كنتَ تعمل دون اتصال، ثم توفَّر لديك بعد دقيقةٍ اتصالٌ شبكي؛ أو بالعكس). لكن إن كان تطبيقُك يولِّد بياناتٍ أو يحفظها، فالأمر متروكٌ لك لتخزين البيانات محليًا عندما لا تكون متصلًا بالشبكة ثم تزامنها مع الخادوم البعيد بعد أن تستعيد اتصالك به. بعبارةٍ أخرى، تمكّنك HTML من جعل تطبيقك يعمل دون اتصال، لكن ما يفعله تطبيقك في هذه المرحلة عائدٌ إليك تمامًا. المتصفحات التي تدعم هذه الخاصية IE Firefox Safari Chrome Opera iPhone Android 10+ 3.5+ 4.0+ 5.0+ 10.6+ 2.1+ 2.0+ ملف Manifest يتمحور تطبيق الويب الذي يعمل دون اتصال حول ملف manifest للتخزين المؤقت. إذًا ما هو ملف manifest؟ هو قائمة بكل الموارد (resources) التي يحتاج لها تطبيق الويب لكي يستطيع المستخدم الوصول إليه وهو غير متصلٍ بالشبكة. وعليك أن تُشير إلى ملف manifest باستعمالك لخاصية manifest في عنصر <html> لتمهيد الطريق لعملية تنزيل وتخزين تلك الموارد تخزينًا مؤقتًا. <!DOCTYPE HTML> <html manifest="/cache.manifest"> <body> ... </body> </html> يمكن أن يتواجد ملف manifest للتخزين المؤقت في أي مكان في خادوم الويب عندك، لكن يجب أن يُخدَّم بنوع text/cache-manifest؛ إذا كنتَ تستعمل خادوم ويب يعتمد على أباتشي (Apache)، فمكن المرجَّح أنَّ كل ما عليك فعله هو إضافة تعليمة AddType في ملف ‎.htaccess في المجلد الجذر الذي يُخدَّم منه تطبيق الويب: AddType text/cache-manifest .manifest تأكَّد أنَّ اسم ملف manifest للتخزين المؤقت ينتهي باللاحقة ‎.manifest؛ إن كنتَ تستعمل خادوم ويب آخر أو ضبطًا مختلفًا لأباتشي، فراجع التوثيق الخاص بالخادوم لمزيدٍ من المعلومات حول التحكم في ترويسة Content-Type. حسنًا، على كل صفحة من صفحات HTML أن تُشير إلى ملف manifest للتخزين المؤقت، ويجب أن يُخدَّم ملف manifest بترويسة Content-Type مناسبة. لكن ماذا يوجد داخل ملف manifest؟ ها قد بدأت الإثارة. أول سطر من أي ملف manifest هو: CACHE MANIFEST وبعد هذا السطر، ستُقسَّم جميع ملفات manifest إلى ثلاثة أقسام: قسم «explicit»، وقسم «fallback» وقسم «online whitelist». لدى كل قسم ترويسةٌ مذكورةٌ في سطرٍ خاصٍ بها؛ وإن لم يحتوي ملف manifest على أيّة ترويسات، فهذا يعني ضمنيًا أنَّ كل الموارد المذكورة في الملف موجودةٌ في القسم «explicit». لا تحاول أن تطيل التفكير في الاصطلاحات السابقة، خشية أن ينفجر رأسك من الصداع. هذا ملف manifest سليمُ البنية، ويحتوي على ثلاثة موارد: ملف CSS، وملف JavaScript، وصورة JPEG. CACHE MANIFEST /clock.css /clock.js /clock-face.jpg لا يحتوي ملف manifest السابق على ترويسات للأقسام، لذا ستكون جميع الموارد المذكورة فيه موجودة في قسم «explicit» افتراضيًا. ستُنزَّل الموارد المذكورة في قسم «explicit» وتُخزَّن تخزينًا مؤقتًا محليًا، وستُستعمَل مكان نظيراتها الموجودة على الشبكة في حال كان المستخدمُ غيرَ متصلٍ. وبهذا –وعند تحميل ملف manifest للتخزين المؤقت– سينُزِّل متصفح الويب الملفات clock.css و clock.js و clock-face.jpg من المجلد الجذر لخادوم الويب، ثم إذا أزلتَ مقبس الشبكة وأعدتَ تحديث الصفحة، فستبقى كل تلك الموارد متوفرةً دون اتصال. قسم NETWORK هذا مثالٌ أكثر تعقيدًا. لنقل أنَّك تريد من تطبيق الساعة الذي أنشأته أن يتتبع الزوار باستخدام سكربت tracking.cgi الذي سيُحمَّل ديناميكيًا في خاصية <img src>، إلا أنَّ تخزين هذا الملف تخزينًا مؤقتًا سيؤثر سلبًا على غرض ذاك السكربت (الذي هو تتبع المستخدمين آنيًا)، لذا لا يجب أبدًا تخزين هذا المورد مؤقتًا ولا يجوز أن يُتاح دون اتصال. هذه هي طريقة فعل ذلك: CACHE MANIFEST NETWORK: /tracking.cgi CACHE: /clock.css /clock.js /clock-face.jpg ملف manifest السابق يحتوي على ترويسات للأقسام، فالسطر الذي يحتوي على NETWORK:‎ هو بداية قسم «online whitelist»، والموارد المذكورة في هذا القسم لن تُخزَّن محليًا ولن تتوفر دون اتصال (محاولة تحميلها عند عدم توفر اتصال ستؤدي إلى خطأ). أما السطر CACHE:‎ فهو بداية قسم «explicit»، وبقية ملف manifest مماثلة للمثال السابق، حيث سيُنزَّل وسيُخزَّن كل مورد من الموارد المذكورة محليًا وسيُتاح للاستعمال دون اتصال. قسم FALLBACK هنالك نوعٌ آخر من الأقسام في ملف manifest: قسمfallback، الذي تُعرِّف فيه البدائل عن الموارد الموجودة على الشبكة التي –لسببٍ من الأسباب– لا يمكن تخزينها مؤقتًا أو لم يتم ذلك بنجاح. توفِّر مواصفة HTML5 حلًا ذكيًا لطريقة استخدام قسم fallback: CACHE MANIFEST FALLBACK: / /offline.html NETWORK: * ماذا يفعل المثال السابق؟ أولًا، لنأخذ مثالًا موقعًا يحتوي ملايين الصفحات مثل ويكيبيديا؛ لا تستطيع تنزيل كامل الموقع، ومن المؤكد أنَّك لا ترغب بذلك. لكن لنقل أنَّك تريد أن تأخذ جزءًا منه وتجعله متوفرًا دون اتصال؛ لكن كيف ستقرر ما هي الصفحات التي تحتاج إلى تخزينها مؤقتًا؟ ماذا عن: كل صفحة زرتها في موقع ويكيبيديا –الذي افترضنا جدلًا أنَّه يدعم التشغيل دون اتصال– ستُنزَّل وستخزَّن مؤقتًا. وهذا يتضمن كل مُدخَلة من مدخلات الموسوعة التي زرتها، وكل صفحة نقاش (أي المكان الذي تتناقش فيه عن مُدخَلة معيّنة)، وكل صفحة تحرير (أي تلك الصفحة التي تُجري فيها تعديلاتٍ إلى مُدخلةٍ ما). هذا ما سيفعله ملف manifest السابق: لنفترض أنَّ كل صفحة HTML (صفحة المُدخلة أو النقاش أو التعديل أو تأريخ الصفحة) في ويكيبيديا تُشير إلى ملف manifest السابق؛ فعندما تزور أي صفحة تُشير إلى ملف manifest فسيقول متصفحك: «مهلًا، هذه الصفحة جزءٌ من تطبيق الويب يعمل دون اتصال، لكن هل أعرف شيئًا عن هذا التطبيق؟» إن لم يُنزِّل متصفحك ملف manifest المُحدَّد من قبل قط، فسيهِّيء «مخزن جديد للتطبيق» (appcache، اختصار للعبارة «application cache»)، وسيُنزِّل جميع الموارد المذكورة في ملف manifest، ثم سيُضيف الصفحة الحالية إلى مخزن التطبيق (appcache). إن كان يعرف متصفحك ملف manifest من قبل، فسيُضيف الصفحة الحالية إلى مخزن التطبيق (appcache) الموجود مسبقًا. وفي كلا الحالتين ستُضاف الصفحة التي زرتها إلى مخزن التطبيق. وهذا مهمٌ لأنَّه يعني أنَّك تستطيع بناء تطبيق ويب يُضيف الصفحات التي يزورها المستخدم تلقائيًا إلى مخزنه. فلستَ بحاجةٍ إلى وضع كل صفحة من صفحات HTML في ملف manifest للتخزين المؤقت. انظر الآن إلى قسم fallback في ملف manifest السابق، الذي يحتوي على سطرٍ وحيدٍ. القسم الأول من السطر (الذي يقع قبل الفراغ) ليس عنوان URL، وإنما نمط URL‏ (URL pattern)، حيث سيُطابِق المحرف / أي صفحة في موقعك وليس الصفحة الرئيسية فقط. فعندما تحاول زيارة صفحة ما عندما تكون غيرَ متصلٍ بالشبكة، فسيبحث متصفحك عنها في مخزن التطبيق (appcache)، فإن وجد المتصفحُ الصفحةَ في مخزن التطبيق (ﻷنك زُرتَها عندما كنتَ متصلًا بالشبكة، ومن ثم أُضيفَت الصفحة إلى مخزن التطبيق [appcache] في ذات الوقت)، فسيعرض المتصفح النسخة المُخزَّنة من الصفحة محليًا؛ إما إذا لم يجد متصفحك الصفحة في مخزن التطبيق، فبدلًا من عرض رسالة الخطأ، فسيعرض الصفحة ‎/offline.html التي تُمثِّل القسم الثاني في السطر المذكور في قسم fallback. في النهاية، لننظر إلى قسم الشبكة (network). يحتوي قسم الشبكة في ملف manifest السابق على سطرٍ فيه محرف وحيد (*)، هذا المحرف له معنىً خاص في قسم الشبكة. وهو يُدعى «online whitelist wildcard flag» وهي طريقة منمّقة لقول أنَّ كل شيءٍ غير موجودٍ في مخزن التطبيق (appcache) سيُنزَّل من عنوان الويب الأصلي لطالما هنالك اتصالٌ شبكيٌ بالإنترنت. هذا مهمٌ لتطبيقات الويب التي تعمل دون اتصال التي لا نريد تنزيلها كل صفحاتها ومواردها، وهذا يعني أنَّه أثناء تصفحك لموقع ويكيبيديا –الذي افترضنا جدلًا أنَّه يدعم العمل دون اتصال– مع اتصالٍ بالإنترنت، فسيحمِّل المتصفح الصور ومقاطع الفيديو والموارد الأخرى المضمَّنة بشكلٍ اعتيادي، حتى ولو كانت في نطاقٍ (domain) مختلف (هذا الأمر شائعٌ في المواقع الكبرى حتى لو لم تكن جزءًا من تطبيق ويب يعملُ دونَ اتصالٍ. صفحات HTML تولَّد وتُخدَّم محليًا في تلك الخواديم، لكن الصور والفيديو تُخدَّم عبر CDN في نطاقٍ آخر). لكن دون هذا المحرف البديل (wildcard)، فسيتصرّف تطبيق ويكيبيديا الذي افترضنا أنَّه يعمل دون اتصال تصرفاتٍ غريبة عندما تكون متصلًا بالشبكة. بشكلٍ خاص: لن يستطيع تنزيل أي صور أو مقاطع فيديو مخزَّنة على نطاقٍ خارجي. هل هذا المثال كاملٌ؟ لا، لأنَّ ويكيبيديا أكثر من مجرد صفحات HTML. فهي تستعمل موارد CSS و JavaScript وصور مشتركة في كل صفحة. فيجب أن تُذكَر تلك الموارد بشكلٍ صريحٍ في قسم CACHE:‎ من ملف manifest، لكي تُعرَض الصفحات عرضًا صحيحًا وتسلك سلوكًا سليمًا عندما تُشغَّل دون اتصال. لكن الغاية من قسم fallback تكمن عندما لا تنزِّل كامل صفحات تطبيق الويب الذي يحتوي على موارد لم تذكرها بصراحة في ملف manifest. ترجمة -وبتصرّف- لفصل Offline Web Applications من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim
  8. تحدثنا في الجزء الأول من هذا الدرس عن أساسيات التخزين المحلي، وسنستمر في مشوارنا مع تطبيقات الويب التي تعمل دون اتصال، وسننشِئ مثالًا عمليًا عليها. تسلسل الأحداث تحدثنا إلى الآن عن تطبيقات الويب التي تعمل دون اتصال، وعن ملف manifest للتخزين المؤقت، وعن مخزن التطبيق (appcache) بشكلٍ مبهم، وكأن الأمر يجري بطريقةٍ سحريةٍ. حيث تُنزَّل الملفات، وتقوم المتصفحات بمهامها على أتمِّ وجه، وكل شيء يعمل عملًا سليمًا! لكننا نتحدث هنا عن تطوير تطبيقات الويب، فلا يعمل أيّ شيءٍ من تلقاء نفسه. بدايةً، لنتكلم عن تسلسل الأحداث، تحديدًا أحداث DOM. عندما يزور متصفحك صفحةً تُشير إلى ملف manifest، فسيُطلِق سلسلةً من الأحداث في كائن window.applicationCache؛ أعلم أنَّ هذا قد يبدو معقدًا، لكن ثق بي، هذه أبسط نسخة تمكنت من كتابتها والتي لا تهمل أيّة معلومةٍ مهمةٍ. 1. بعد أن يلاحظ المتصفح خاصية manifest في عنصر <html>، فسيُطلِق الحدث checking مباشرةً (جميع الأحداث المذكورة هنا ستُفعَّل في الكائن window.applicationCache)، سيُفعَّل الحدث checking دومًا، حتى لو زرتَ هذه الصفحة من قبل أو كانت هنالك صفحاتٌ أخرى تشير إلى نفس ملف manifest. 2. إن لم يتعامل متصفحك مع ملف manifest المُحدَّد من قبل… سيُطلِق الحدث downloading، ثم سيبدأ بتنزيل الموارد المذكورة في ملف manifest للتخزين المؤقت. أثناء التنزيل، سيُطلِق متصفحك الحدث progress بين الحين والآخر، الذي يحتوي على معلوماتٍ عن عدد الملفات التي نُزِّلَت. بعد إكمال تنزيل جميع الموارد المذكورة في ملف manifest بنجاح، سيُطلِق المتصفح الحدث النهائي cached الذي يُشير إلى أنَّ تطبيق الويب قد خُزِّن مؤقتًا بشكلٍ كامل، وهو جاهز لكي يُستخدم دون اتصال. 3. في المقابل، إن زرتَ هذه الصفحة أو أي صفحة أخرى تُشير إلى إلى نفس ملف manifest من قبل، فسيعلم متصفحك عن ملف manifest؛ فربما خزَّن بعض الموارد في مخزن التطبيق (appcache)، وربما خزَّن كامل التطبيق. إذًا السؤال الآن هو: هل تغيّر ملف manifest منذ آخر مرة تحقق فيها المتصفح من ذلك؟ إذا كان الجواب: لا، لم يتغير ملف manifest؛ فسيُطلِق متصفحك الحدث noupdate، ولن يحتاج إلى اتخاذ خطواتٍ إضافية. إذا كان الجواب: نعم، تغيّر ملف manifest؛ فسيطلِق متصفحك الحدث downloading ويُعيد تنزيل كلُ موردٍ موجودٍ في ملف manifest. أثناء التنزيل، سيُطلِق متصفحك الحدث progress بين الحين والآخر، الذي يحتوي على معلومات عن عدد الملفات التي نُزِّلَت. بعد إعادة تنزيل كل الموارد الموجودة في ملف manifest بنجاح، سيُطلِق المتصفح الحدث النهائي updateready الذي يُشير إلى أنَّ النسخة الجديدة من تطبيق الويب قد خُزِّنت مؤقتًا بشكلٍ كامل، وهي جاهزة لكي تُستخدم دون اتصال. لكن انتبه إلى أنَّ النسخة الحديثة لن تُستعمَل فورًا، فلا تُبدَّل النسخة القديمة آنيًا، لكنك تستطيع استخدام النسخة الجديدة دون إجبار المستخدم على إعادة تحميل الصفحة باستدعاء الدالة window.applicationCache.swapCache()‎ يدويًا. إذا حدث أي شيء بشكلٍ خاطئ في أي نقطة في هذه المرحلة، فسيُطلِق متصفحك الحدث error وسيتوقف. هذه هي قائمة مختصرة بالأشياء التي قد تُسبِّب المشكلة: أعاد ملف manifest رسالة الخطأ HTTP 404 ‏(أي Page Not Found) أو 410 ‏(أي Permanently Gone). عُثِرَ على ملف manifest ولم يتغيّر، لكن فشل تنزيل صفحة HTML التي تُشير إلى الملف. تغيّر ملف manifest أثناء التحديث. عُثِرَ على ملف manifest وقد تغيّر، لكن المتصفح قد فشل بتنزيل أحد الموارد المذكورة فيه. تنقيح الأخطاء أريد أن أشير إلى نقطتين مهمتين هنا، أولهما هو شيءٌ قرأتَه لتوِّك لكنني متأكدٌ تمامًا أنَّك لم تعره اهتمامك، لذا دعني أكرره: إذا فشل تنزيل أحد الموارد الموجودة في ملف manifest تنزيلًا سليمًا، فستفشل عملية التخزين المؤقت لتطبيق الويب الذي يعمل دون اتصال بالكليّة، وسيُطلِق المتصفح الحدث error، لكن ليس هنالك أيّة إشارات إلى ماهية المشكلة. وهذا ما يجعل تنقيح (debugging) تطبيقات الويب التي تعمل دون اتصال معقدةً ومزعجةً أكثر من المعتاد. النقطة الثانية هي ليست –إذا ابتغينا الدقة التقنية– خطأً، لكنها ستبدو وكأنها علِّةٌ خطيرةٌ في المتصفح إلى أن تعلم ما الذي يجري. لهذه النقطة علاقةٌ بآليةِ تحققِ متصفحكَ فيما إذا تغيّر ملف manifest. وهي عمليةٌ تتألف من ثلاثِ خطواتٍ. هذه العملية مملةٌ لكنها مهمةٌ، لذا انتبه جيدًا لما سأتلوه عليك. سيسأل متصفحك –عبر البنى الهيكلية الاعتيادية في HTTP– إذا انتهت صلاحية التخزين المؤقت لملف manifest. وكما في بقية الملفات التي تُخدَّم عبر HTTP، سيُضمِّن خادوم الويب عندك بشكلٍ اعتيادي بعض المعلومات حول الملف في ترويسات HTTP. بعض تلك الترويسات (Expires و Cache-Control) تخبِر متصفحك كيف يُسمَح له بتخزين الملف مؤقتًا دون سؤال الخادوم إذا تغيِّر أم لا. لا علاقة لهذه النوع من التخزين بتطبيقات الويب التي تعمل دون اتصال؛ وهو يحدث تقريبًا لكل صفحة HTML أو صفحة أنماط CSS أو سكربتٍ ما أو صورةٍ أو أي موردٍ آخر على الويب. إذا انتهت صلاحية ملف manifest المؤقت (وفقًا لترويسات HTTP الخاصة به)، فسيسأل متصفحُك الخادومَ إذا كانت هنالك نسخةٌ جديدةٌ من الملف؛ فإن وجِدَت، فسيُنزِّلها المتصفح. وللقيام بهذا، سيُرسِل متصفحك طلبية HTTP التي تتضمَّن تاريخ آخر تعديل لملف manifest المُخزَّن مؤقتًا، وهو نفسه الذي أرسله الخادوم في جواب HTTP ‏(HTTP response) في آخر مرّة نزَّل فيها متصفحك ملف manifest. إذا قال خادوم الويب أنَّ ملف manifest لم يتغير منذ ذاك الوقت، فسيُعيد الخادوم حالة 304 (أي Not Modified). أكرِّر أنَّ هذا لا علاقة له بتطبيقات الويب التي تعمل دون اتصال، وهو يحدث لكل نوع من أنواع الموارد الموجودة في الويب. إذا ظنَّ خادوم الويب أنَّ ملف manifest قد تغيّر منذ ذاك التاريخ، فسيُعيد الحالة HTTP 200 (أي OK) متبوعةً بمحتويات الملف الجديد بالإضافة إلى ترويسات Cache-Control جديدة وتاريخ جديد لآخر تعديل، لذا ستعمل الخطوتان 1 و 2 بشكلٍ سليم في المرة القادمة (بروتوكول HTTP جميل جدًا؛ إذ تُخطِّط خواديم الويب للمستقبل دائمًا، فإن كان على خادوم الويب إرسال ملفٍ إليك، فسيفعل ما بوسعه لكي يتأكَّد أنَّه لن يحتاج إلى إرساله لك مرتين دون داعٍ). بعد تنزيل ملف manifest الجديد، سيقارن المتصفح المحتويات مع النسخة التي نزَّلها آخر مرة. إذا كانت محتويات ملف manifest مماثلةً لمحتويات آخر نسخة، فلن يُعيد متصفحك تنزيل أيٌّ من الموارد المذكورة في الملف. قد تعترض إحدى الخطوات السابقة طريقك أثناء تطويرك واختبارك لتطبيق الويب الذي يعمل دون اتصال، على سبيل المثال، لنقل أنَّك أنشأتَ نسخةٌ من ملف manifest، ثم بعد 10 دقائق أدركت أنَّك تحتاج إلى إضافة مورد آخر إلى الملف. لا توجد مشكلة، صحيح؟ أضفت سطرًا جديدًا وجربت التطبيق، لكنه لم يعمل! إليك ما حدث: عندما أعدت تحميل الصفحة، لاحظ المتصفح خاصية manifest، وأطلق الحدث checking، لكنه لم يفعل شيئًا… أصرَّ متصفحك بعنادٍ أنَّ ملف manifest لم يتغير. لماذا؟ لأنَّ خادوم الويب –افتراضيًا– مضبوطٌ للطلب من المتصفحات أن تُخزِّن الملفات الثابتة مؤقتًا لعدِّة ساعات (وذلك عبر ترويسات Cache-Control في بروتوكول HTTP). وهذا يعني أنَّ متصفحك سيبقى عالقًا في الخطوة رقم 1 من الخطوات الثلاث السابقة. من المؤكَّد أنَّ خادوم الويب يعرف أنَّ الملف قد تغيّر، لكن متصفحك لن يحاول سؤال خادوم الويب. لماذا؟ لأنَّه في آخر مرة نزَّل متصفحك فيها ملف manifest، طلب الخادوم منه أن يُخزِّن الملف مؤقتًا لعدِّة ساعات، لكن متصفحك حاول إعادة طلب ذاك الملف بعد 10 دقائق. دعني أوضِّح لك أنَّ هذه ليست علّة وإنما ميزة. إذ يعمل كل شيءٍ كما يجب. إن لم تكن هنالك طريقة لخواديم الويب (وللخواديم الوسيطة [proxies]) لتخزين الملفات مؤقتًا، فسينهار الويب بين ليلةٍ وضحاها. لكن هذا ليس عزاءً لك بعد أن قضيت عدِّة ساعات محاولًا معرفة لماذا لم يلاحظ متصفحك أنَّ ملف manifest قد تعدَّل (من الطريف إن كنت قد انتظرت فترةً كافيةً ثم أعدتَ تحميل الصفحة فسيعمل الملف بشكلٍ سحري! ذلك لأنَّ فترة صلاحية الملف قد انتهت، كما قد حُدِّدَ لها تمامًا). هذا ما عليك فعله فوريًا: إعادة ضبط خادوم الويب عندك لكي لا يُخزَّن ملف manifest مؤقتًا عبر بروتوكول HTTP. إذا كنتَ تستعمل خادوم ويب مبني على أباتشي، فكل ما عليك فعله هو إضافة السطرين الآتيين إلى ملف ‎.htaccess: ExpiresActive On ExpiresDefault "access" التعليمات السابقة ستُعطِّل التخزين المؤقت لكل ملف في ذاك المجلد وفي جميع المجلدات الفرعية، ومن المُرجَّح أنَّك لا تريد فعل هذا في خادومٍ إنتاجي؛ لذا عليك إما أن تضع التعليمات السابقة ضمن تعليمة <Files> لكي تؤثِّر على ملف manifest فقط، أو تُنشِئ مجلدًا فرعيًا لا يحتوي إلا على ملف manifest وملف ‎.htaccess فقط. وكالمعتاد، تختلف تفاصيل الضبط من خادومٍ إلى آخر، لذا راجع توثيق خادوم الويب الذي تستعمله لتفاصيلٍ حول كيفية التحكم بترويسات التخزين المؤقت لبروتوكول HTTP. بعد أن تُعطِّل التخزين المؤقت الخاص ببروتوكول HTTP على ملف manifest، ربما تواجهك مشكلة أخرى في أنَّك قد عدَّلت في أحد الموارد التي ستُخزَّن في مخزن التطبيق (appcache) لتُستعمَل دون اتصال، لكنها بقيت تملك نفس عنوان URL في خادومك. هنا ستعترض الخطوة رقم 2 من الخطوات الثلاث السابقة طريقك. إذا لم يتغير محتوى ملف manifest، فلن يلاحظ المتصفح أنَّ أحد الموارد المُخزَّنة مسبقًا قد تغيّر. ألقِ نظرةً إلى المثال الآتي: CACHE MANIFEST # rev 42 clock.js clock.css إذا عدِّلتَ ملف الأنماط clock.css وجربت التطبيق، فلن تلاحظ وجود التعديلات التي أجريتها، وذلك لأنَّ ملف manifest نفسه لم يُعدَّل. في كل مرة تُجري فيها تعديلًا لموردٍ ما في تطبيق الويب الذي يعمل دون اتصال، فعليك أن تُعدِّل ملف manifest نفسه. وهذا بسيطٌ جدًا، فلا يلزمك إلا تغييرُ حرفٍ وحيد. أسهل طريقة وجدتها لفعل هذا هو تضمين تعليق فيه رقم النسخة أو المراجعة (revision). غيّر رقم النسخة الموجود في التعليق، ثم سيلاحظ متصفحك أنَّ محتوى الملف قد تغيّر وسيعيد تنزيل كل الموارد المذكورة فيه. CACHE MANIFEST # rev 43 clock.js clock.css لننشِئ واحدًا! هل تتذكر لعبة الضامة التي برمجناها في درس canvas ثم حسّنّاها لاحقًا بحفظنا للتحركات عبر التخزين المحلي؟ ما رأيك أن نجعل اللعبة تعمل دون اتصال. علينا أن نُنشِئ ملف manifest يحتوي على قائمة بجميع الموارد التي تحتاج لها اللعبة. حسنًا، هنالك صفحة HTML رئيسية، وملف JavaScript وحيد الذي يحتوي على شيفرة اللعبة. لا توجد صور، لأننا رسمنا كل شيءٍ برمجيًا عبر الواجهة البرمجية لعنصر canvas. وجميع أنماط CSS موجودة في عنصر <style> في أعلى صفحة HTML. ها هو ذا ملف manifest الخاص باللعبة: CACHE MANIFEST halma.html ../halma-localstorage.js كلمة عن المسارات: أنشأتُ مجلدًا فرعيًا باسم offline/‎ في مجلد examples/‎، وملف manifest السابق موجودٌ هناك في المجلد الفرعي. ولأنَّ صفحة HTML ستحتاج إلى تعديلٍ بسيطٍ لكي تعمل دون اتصال (سآتيك به بعد دقيقة)، فأنشأتُ نسخةً منفصلةً من ملف HTML، الموجودةُ أيضًا في المجلد الفرعي offline/‎، ولعدم وجود أيّة تعديلات على شيفرة JavaScript منذ أن أضفنا دعمًا للتخزين المحلي، فسأستعمل ملفات ‎.js نفسها، الموجودة في المجلد الأب (examples/‎). ستبدو المسارات كالآتي: /examples/localstorage-halma.html /examples/halma-localstorage.js /examples/offline/halma.manifest /examples/offline/halma.html نريد الإشارة إلى ملفين في ملف manifest للتخزين المحلي (‎/examples/offline/halma.manifest)، أولهما هو النسخة التي تعمل دون اتصال لملف HTML (/examples/offline/halma.html) ولأن كلا الملفين في نفس المجلد، فمن الممكن ذكره في ملف manifest دون وجود سابقة للمسار. أما ثانيهما، فهو ملف JavaScript الموجود في المجلد الأب (‎/examples/halma-localstorage.js‎)، ويجب استخدام المسارات النسبية في ملف manifest:‏ ‎../halma-localstorage.js، وهذا مشابهٌ لاستعمالك لعنوان URL نسبي في خاصية <img src>. يمكنك أيضًا استعمال المسارات المطلقة (absolute paths، تلك التي تبدأ من المجلد الجذر للموقع) أو حتى عناوين URL المطلقة (التي تُشير إلى موارد موجودة على نطاقات أخرى). علينا إضافة خاصية manifest في ملف HTML لكي تُشير إلى ملف manifest للتخزين المؤقت: <!DOCTYPE html> <html lang="en" manifest="halma.manifest"> هذا كل ما عليك فعله! عندما تزور صفحة اللعبة التي تعمل دون اتصال بمتصفح حديث، فسينزِّل ملف manifest المُشار إليه في خاصية manifest ثم سيبدأ بتنزيل جميع الموارد الموجودة فيه ويضعها في مخزن التطبيق (appcache). ومن هنا ستتولى شيفرة الصفحة الأمر في كل مرة تزور فيها الصفحة. يمكنك اللعب دون اتصال وستُخزَّن بيانات اللعبة محليًا، لذا ستستطيع أن تُغلِق اللعبة ثم تعود إليها متى شئت. كلمة أخيرة أعلنت W3C أخيرًا أنَّها ستزيل هذه الميزة من معيار HTML5، إلا أنَّ هذه العملية ستستغرق وقتًا طويلًا. ونصحت W3C باستخدام Service Workers بدلًا منها. المشكلة أنَّ ميزة Service Workers غير مدعومة من الغالبية العظمى من المتصفحات، والمتصفحات التي تتواجد فيها ميزة Service Workers تدعمها دعمًا جزئيًا فقط. تركت W3C المطورين بين المطرقة والسندان، لكنني أرى أنَّ عليك الاستمرار في استخدام هذه الميزة، مع متابعة أخبار دعم Service Workers لتنتقل إليها في المستقبل. مصادر إضافية المعايير: Offline web applications في مواصفة HTML5 توثيقٌ من صانعي المتصفحات: Offline resources in Firefox HTML5 offline application cache، التي هي جزءٌ من Safari client-side storage and offline applications programming guide الدروس التعليمية: Gmail for mobile HTML5 series: using appcache to launch offline - part 1 Gmail for mobile HTML5 series: using appcache to launch offline - part 2 Gmail for mobile HTML5 series: using appcache to launch offline - part 3 Debugging HTML5 offline application cache an HTML5 offline image editor and uploader application ترجمة -وبتصرّف- لفصل Offline Web Applications من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim
  9. في مواقع الإنترنت عوامل أساسية لا يمكن التغاضي عنها، تؤثر على ترتيب الموقع وأرشفته في محركات البحث. سنتطرق لها اليوم من زاوية تهمك كمطور، فالعديد من المطورين يقعون في هذه الأخطاء التي تؤدي إلى غرقِ الموقع في بحر الانترنت، فحياة الموقع تكمن في جلب الزوار له -و هذا لا يحدث صدفة-، فلا شك بأن المحتوى الجيد مهم، لكن ما الفائدة من قصرٍ لا باب و لا منافذ له! القصر هو برمجيتك، فإن لم تُحسن بناءَها مواكبًا للتطورات لإثراءِ معارفِكَ بالأساليب التقنية الحديثة التي تؤثر على عَملك، الذي ستسدّ بها احتياجات عملائك، وتلبيتها لهم على أكمل وجه. اليوم سنتطرّق لأهم العوامل المؤثرة في تهيئة المواقع لمحركات البحث (SEO) ببساطة وإيجاز، التي يراها المستخدم دون الحاجه لعرض الشيفرة المصدرية للصفحة، وهي كالتالي: الروابطأو ما يعرف بـ URL، والتي نتعامل معها بشكل يومي. رابط الموقع هو وسيلة الدخول إليه، وهو عبارة عن نصٍ مقروء مُصمم ليظهرعوضاً عن الأرقام في عنوان IP الذي يستخدمه الحاسوب للإتصال بالخواديم، بالإضافة إلى توضح تركيب الملفات في الموقع المطلوب. عند البدء في بناء البرمجية يجب أن نراعي (كمطوّر) التالي في عملية إنشاء الروابط: استخدام (-) لفصل الكلمات عند الضرورة، حتى تَسهُلَ قراءتها، ولا ينبغي استخدام الرمز( _ ) ، المسافة أو أي رمز آخر لفصل الكلمات. الاستخدام المفرط للفواصل في عناوين الروابط مزعج ويمكن أن تعتبرها محركات البحث (spam) – أي مُزعجة -، لذلك يجب الحذر قدر الإمكان عند استخدامها.أن لا يحتوي على أكثر من 2,048 حرف ورمز، و إلا فإن مستعرض الإنترنت لن يكون قادرًا على تحميل الصفحة.تجنب استخدام المعلمات (parameters) قدر الإمكان، وفي حال اضطررت لاستخدامها فيجب ان تقتصر على اثنين أو أقل. باختصار: الرابط الصحيح هو الذي يصف الموقع أو الصفحة للمستخدمين و محركات البحث. للحصول على ترتيب أفضل في محركات البحث، يفضل أن يحتوي عنوان الرابط على الكلمات المفتاحية ذات الصلة بمحتوى الصفحة، وإذا كان الموقع يحتوي على أقسامٍ عدة وأنواعٍ مختلفة من المحتوى، يفضل تجزئته إلى مجلدات ومجلدات فرعية، بأسماءٍ تعبر عن طبيعة المحتوى الموجود في كل مجلد. لو افترضنا أنك تعمل على إنشاء متجرٍ إلكتروني يحوي عدة أقسامٍ رئيسية وبداخله أقسامًا فرعية، يُفضل أن يتم تسمية المجلدات بناءً على محتواها. في الرابط السابق يمكننا بوضوح الإستنتاج بأنّ محتوى الصفحة متعلّق بالساعات في قسم accessories، وهو الرابطُ المثاليّ المقصود. أما الرابط السيء، يكونُ طويلاً ولا يَدل على محتوى الصفحة كما في المثالِ التالي: وهذا يشرح الفرق بين الروابط المقروءة عن غيرها، كمطور عليك مراعاة هذا. خلاصة القول، هناك خصائص و ميزات أساسية يجب توافرها في كلّ رابط، نؤكّد عليها: الدلالة: بناء الرابط بشكلٍ جيد كما في المثال السابق، يُعطي الزائر خلفية مُسبقة عن ماهية محتوى الصفحة قبلَ تحميلها، و يُسهّل تعرّفَ عناكبِ محركات البحثِ على محتواه، ومقارنته مع عملية البحث التي يُجريها المستخدم، والمساهمة مباشرةً في ظهوره في الصفحات الأولى لنتائج البحث .الكلمات الدلالية: الرابط الصحيح يجب أن يحتوي على الكلمة المفتاحية الدّالة على محتواه ، ويُستحسن أن تكونَ هي نفس الكلمة المفتاحية في عنوان الموضوع ، وفي الوصفِ الخاصّ به ، لأرشفة سريعة في محركات البحث.النشر عبر مواقع التواصل الاجتماعي: مواقع التواصل الاجتماعي من أهم المصادر لجلبِ زوارٍ لموقعك ، وأهمية الروابط تكمن بنشرها من خلال هذه المواقع ، فالرابط الطويل غير المفهوم مزعج ومنفر لمستخدمي تلكَ المواقع، ويجعلهم مترددين في زيارته لكونِهِ يعثُ الريبة في نفوسهم. بناءً على ذلك ، يجب أن يكونَ الرابطُ واضحًا ومنظمًا ، إضافةً إلى أن نشر الروابط بجانبِ الوسوم التي المعبّرة عن الكلمة المفتاحية المُضمّنة في الرابط، تزيدُ من إمكانية ظهورها في محركات البحث .اعلم بأنّ محركات البحث تعطي الوسوم الخاصة بمواقع التواصل الإجتماعي مثل: Twitter/Facebook/Google+، أهميةً كبيرة في أرشفة المنشورات، خصوصاً إذا كان التفاعُل مع منشورٍ ما كبيراً ، أنّ شبكة Google Plus ، تؤرشَف منشوراتُها فوراً في محرك البحث Google إذا ما تمّ استخدام الوسوم المناسبة ، والمشهورة باسم Hashtag#.وسم العنوان (Title tag) هو الوسم الذي يتم كتابة عنوان صفحة معينة داخله، و يعتبر من أهم عوامل نجاح تهيئة المواقع لمحركات البحث (SEO) وذلك لأي موقع، لأن هذا العنصر يحوي وصفاً دقيقاً ومختصراً لمحتوى الصفحة، والخطأ الذي يقع فيه العديد من المطورين هو وضع عناوين صفحاتٍ ثابته للموقع، وعدم ترك هذا الخيارِ قابلاً للتغير من لوحة التحكم، فعنوان الصفحة يؤثر على تجربة المستخدم كما له تأثيرعلى تهيئة الموقع لمحركات البحث. يفضل وضع العنوان على الشكل التالي: الكلمة الرئيسية - الكلمة الثانوية | العلامة التجارية. الطول الأمثل لعنوان الصفحة: Google في العادة تظهر أول 50-60 حرف من عنوان الصفحة أو حسب عدد الأحرف التي تظهر ضمن عرض 512 بيكسل، فإذا جعلت عنوان الصفحة أقل من 55 حرف ستضمن ظهور 59% من نَص العنوان، مع العلم أنه ربما يظهر نص آخر من ضمن محتوى الصفحة بناءً على عملية البحث التي قام بها المستخدم. مثال على عنوان مثالي: مثال على عنوان طويل: وسم العنوان هو النص الرئيسي الذي يصف محتوى صفحة الويب، ويعتبر واحدًا من أهمّ عناصر On Page SEO ويظهر في ثلاث أماكن رئيسية: المتصفح: صفحة نتائج البحث: مواقع التواصل الاجتماعي: الوصف التعريفي (Meta Description)سمة من سمات HTML تتيح إضافة وصف موجز عن محتوى الصفحة يظهر ضمن صفحة نتائج البحث. هذه الفقرة القصيرة هي فرصة ثمينة لكل مدير موقع لجذبِ الباحثين، وكتابةِ وصفٍ دقيق عن محتوى الصفحة، لتؤكدَ لهم ما إذا كانت هذه الصفحة هي المقصودة أم لا. لذلك يجب اختيار الكلمات الرئيسية ضمن الوصف بذكاء وعدم حشو الوصف بكلمات لا تمت للمحتوى بصلة، ومن الأفضل أن لا يتجاوز طول الوصف 160 حرفًا، لأنه وبعد هذا العدد من الحروف ستظهر على شكر نقاط هكذا ( ........... )، أي سيُخفي مُحرّكُ البحث باقي النص، للدلالة على تجاوز الحد المسموح به. مثال (عن عدم ظهور كامل الوصف، بسبب زيادة عدد الأحرف عن الحد المسموح به وهو 160 حرف ): وبالتالي في شفرة HTML الخاصة بالصفحة، تأكد من وضع الوصف التعريفي ضمن وسم <head> على النحو التالي: <head> <meta name="description" content="ضع هنا وصفا لا يتجاوز 160 حرفا"> </head> أوسمة العناوين (Heading Tags) العديد من المطورين يقعون في خطأ فادح، وهو استخدام H1 tag في غير محلّه. مثلاً: وضع شعار الموقع ضمنه، أو استخدامه في الأسماء الخاصة بالأقسام الثابتة. هناك من يظن بأن هذه الوسوم ليست ذات قيمة لدى محركات البحث، ولا يعرف مدى عِظمِ أهميتها في إشهارِ الموقع، فالباحث يبحث باستخدام كلمة مفتاحية بمحرك البحث، وأنت عليك أن تضعها له بطريقةٍ مدروسة وفق معايير محركاتِ البحث. كل ما يهم أن المنافسة بين مواقع الويب اشتدت وليست كسابق عهدها، فتلك التعديلات والإجراءات والإضافات التي تراها بسيطة، من الممُكنِ تجعلَ موقعك في الصدارة، أو أن يضيعَ بين ملايين الصفحات المنشورة على شبكة الإنترنت، فالكلمات التي تقعُ ضمن هذه الوسوم تعتبر مهمة كثيراً، وأهم من النص العادي، لذلك يفضل دائمًا وضع الكلمات الدلالية داخلها، أو العناوين المهمة للمحتوى وترتيبها حسب الأولوية. خاصية ALT للصور عناكب محركات البحث لا تستطيع التعرف على الصور، هذه الخاصية تتيح لك تسمية الصورة الخاصة بالمحتوى، وتمكنك من وضع كلماتك الرئيسية بذكاء ضمن هذه الخاصية، فتساعد في أرشفة موقعك، وظهورها عند البحث عن الكلمة المضمنة في هذه الخاصية في نتائج البحث بشكلٍ منفصل عن النتائج النصيّة، فاحرص على أن تكون الصور المستخدمة مميزة لتجذب الباحث إليها. الخلاصةبعد تعرّفكَ على أهم أساسيات تهيئة المواقع لمحركاتِ البحث، بإمكانك بناء برمجية مرنة تتوافق مع احتياجات العميل، من خلال إنشاء لوحةِ تحكمٍ أكثر مرونة وتوافقية مع SEO. من خلالِ ما سبق، استعرضنا مع التوضيح أهم عناصر SEO التي يراها المستخدم ويتفاعل معها، والإرشادات الصحيحة في كيفية تطبيقها في موقعك، وتسهيل المهمة على العُملاء ، لتحظى بثقتهم ورضاهم.
  10. تمهيد كلما كانت صفحات الموقع أسرع تحميلًا كلما ازداد احتمال بقاء الزائر متصفحًا للموقع، وعندما تمتلئ صفحات مواقع الويب بالصور والمحتوى التفاعلي الظاهر عبر سكربتات تُحمَّل في الخلفية، فلن تكون عملية فتح «صفحة» ويب أمرًا هينًا، إذ تتضمن طلب ملفاتٍ عدِّة من خادوم الويب ملفًا ملفًا، وعملية تقليل تلك الطلبيات هي إحدى سُبُل تسريع موقعك. يمكن فعل ذلك بطرائق عدِّة، لكن إحدى أهم الخطوات التي يجب إجراؤها هي ضبط التخزين المؤقت في المتصفح (browser caching)؛ وهذا يعني إخبار المتصفح بإمكانية استخدام نسخ محلية من الملفات التي حُمِّلَت في إحدى المرات بدلًا من طلبها من الخادوم مرارًا وتكرارًا؛ ولفعل ذلك يجب إضافة ترويسات لرد HTTP ‏(HTTP response headers) تخبر المتصفح بما عليك فعله. هذا هو دور وحدة header (‏header module) في خادوم Nginx، التي يمكن استعمالها لإضافة الترويسات إلى رد HTTP، لكن دورها الأساسي يمكن في ضبط الترويسات المسؤولة عن التخزين المؤقت. سننظر في هذا الدرس إلى كيفية استخدام وحدة header لتطبيق الفكرة السابقة. المتطلبات المسبقة ستحتاج قبل إكمال قراءة هذا الدرس إلى ما يلي: خادوم أوبنتو 16.04 (أو 14.04) مضبوطٌ كما في درس «الإعداد الابتدائي لخادوم أوبنتو 14.04»، بما في ذلك إعداد حساب مستخدم عادي لكنه يملك امتيازات الجذر (root) عبر الأداة sudo. خدمة Nginx مثبّتة على خادومك باتباعك لهذا الدرس «تنصيب، إعداد واستخدام nginx كخادوم ويب». سنحتاج بالإضافة إلى وحدة header إلى وحدة map التابعة لخادوم Nginx؛ لمزيدٍ من المعلومات حول وحدة map، فاقرأ درس كيفية استخدام وحدة map على خادوم أوبنتو 16.04. الخطوة الأولى: إنشاء ملفات للتجربة سنُنشِئ في هذه الخطوة عدِّة ملفات في مجلد Nginx، إذ سنستخدم هذه الملفات لاحقًا للتحقق من سلوك خادوم Nginx الافتراضي لاختبار أنَّ التخزين المؤقت في المتصفح يعمل عملًا صحيحًا. لتقرير ما هو نوع الملفات المُخدَّمة عبر الشبكة، فلن يُحلِّل Nginx محتويات الملف لأن ذلك يستهلك وقتًا كثيرًا؛ وإنما سينظر إلى لاحقة (أو امتداد) الملف لتحديد ما هو نوع MIME التابع له، والذي سيُصرِّح عن الهدف أو الغاية من الملف. ونتيجةً لهذا السلوك، فلن يكون لمحتوى الملفات الاختبارية أيّة أهمية؛ إذ سنستطيع خداع خادوم Nginx بتسمية الملفات تسميةً صحيحةً، فقد يظن خادوم Nginx أنَّ ملفًا فارغًا يُمثِّل صورةً وآخر يُمثِّل سكربت JavaScript. لنُنشِئ ملفًا باسم test.html في مجلد Nginx الافتراضي عبر الأداة truncate (يمكنك استخدام أيّة أداة أو أمر آخر وليكن touch مثلًا). لاحقة الملف تُشير إلى أنَّه مستند HTML: sudo truncate -s 1k /var/www/html/test.html لنُنشِئ المزيد من الملفات الاختبارية بنفس الطريقة السابقة: صورة jpg وملف css وسكربت js: sudo truncate -s 1k /var/www/html/test.jpg sudo truncate -s 1k /var/www/html/test.css sudo truncate -s 1k /var/www/html/test.js الخطوة التالية هي التحقق من سلوك خادوم Nginx فيما يتعلق بإرسال ترويسات للتحكم بالتخزين المؤقت للمتصفح وذلك بتخديم الملفات التي أنشأناها أخيرًا مع الضبط الافتراضي له. الخطوة الثانية: التحقق من السلوك الافتراضي لخادوم Nginx يكون لجميع الملفات نفس سلوك التخزين المؤقت افتراضيًا. ولرؤية ذلك سنستخدم ملف HTML الذي أنشأناه في الخطوة الأولى، إلا أنَّك تستطيع إجراء هذا الاختبار على أيّ ملف من الملفات التي أنشأناها سابقًا. لنتحقق من أنَّ الملف test.html يُخدَّم ومعه المعلومات التي لها علاقة بالمدة الواجب تخزين المتصفح للملف فيها مؤقتًا. سيؤدي الأمر الآتي إلى طلب الملف من خادوم Nginx المحلي ويُظهِر ترويسات رد HTTP: curl -I http://localhost/test.html يجب أن ترى عدِّة ترويسات HTTP: HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:12:26 GMT Content-Type: text/html Content-Length: 1024 Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT Connection: keep-alive ETag: "57d40685-400" Accept-Ranges: bytes يمكنك أن تلاحظ السطر قبل الأخير الذي يبدأ بالكلمة ETag الذي يتضمن مُعرِّفًا فريدًا للنسخة الحالية من الملف المطلوب. فإذا حاولت تنفيذ أمر curl السابق أكثر من مرة فستجد نفس قيمة ETag. أما عند استخدام متصفح ويب، فستُخزَّن قيمة ETag ثم تُرسَل إلى الخادوم عبر ترويسة If-None-Match عندما يريد المتصفح أن يطلب نفس الملف مرةً أخرى (عند تحديث الصفحة على سبيل المثال). يمكنك محاكاة ذلك في سطر الأوامر بالأمر الآتي. احرص على تغيير قيمة الترويسة If-None-Match في الأمر لتُطابِق قيمة ETag في ناتج الأمر السابق: curl -I -H 'If-None-Match: "57d40685-400"' http://localhost/test.html ستجد أنَّ الرد أصبح مختلفًا الآن: HTTP/1.1 304 Not Modified Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:20:31 GMT Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT Connection: keep-alive ETag: "57d40685-400" ردّ خادوم Nginx بحالة «‎304 Not Modified»، ولن يُرسِل الملف عبر الشبكة مجددًا، وإنما يخبر المتصفح أنَّه يستطيع إعادة استخدام الملف المُخزَّن محليًا والذي نزَّله سابقًا. ما سبق مفيدٌ لأنه يُقلِّل من التراسل الشبكي، لكنه ليس مثاليًا لتحقيق أداءٍ عالٍ نتيجةٍ للتخزين المؤقت. المشكلة مع ترويسة ETag أنَّ المتصفح سيرسل الطلبية إلى الخادوم دائمًا ويسأله إن كان بإمكانه استخدام الملف المُخزَّن مؤقتًا، وحتى لو ردّ الخادوم على المتصفح بالإيجاب بحالة 304 بدلًا من إعادة إرسال الملف مجددًا، إلا أنَّ إرسال الطلبية واستلام الرد سيستهلك وقتًا. سنستخدم في الخطوة التالية وحدة headers لإضافة معلومات للتحكم بالتخزين المؤقت. وهذا سيجعل المتصفح يُخزِّن الملفات محليًا دون أخذ إذن الخادوم أولًا. الخطوة الثالثة: ضبط ترويستَي Cache-Control و Expires إضافةً إلى ترويسة التحقق من تغيّر الملف (ETag)، هنالك ترويستان للتحكم بالتخزين المؤقت هما Cache-Control و Expires. ترويسة Cache-Control هي نسخةٌ أحدث، وفيها خياراتٌ أكثر مقارنةً بترويسة Expires وهي أفيد إن شئت التحكم بسلوك التخزين المؤقت تحكمًا دقيقًا. إذا ضُبِطَت تلك الترويسات، فهي تخبر المتصفح أنَّ الملف المطلوب يمكن أن يُخزَّن محليًا لفترةٍ زمنيةٍ معيّنة (تستطيع أن تجعل صلاحيته «للأبد»!) دون طلبه مرةً أخرى. أما إن لم تُضبَط تلك الترويسات، فسيطلب المتصفحُ الملفَ دومًا من الخادوم، متوقعًا أن يحصل على الحالة «‎200 OK» أو «‎304 Not Modified». يمكننا استخدام وحدة header لإرسال ترويسات HTTP آنفة الذكر. وحدة header هي وحدةٌ من أساس خادوم Nginx لذا لن تحتاج إلى تثبيت أيّ شيءٍ لاستخدامها. لإضافة وحدة header، افتح ملف ضبط Nginx في محرر nano أو أيّ محررٍ نصيٍ تشاء: sudo nano /etc/nginx/sites-available/default اعثر على القسم المُعَنوَنَ server، والذي يبدو كما يلي: . . . # Default server configuration # server { listen 80 default_server; listen [::]:80 default_server; . . . أضف القسمَين الآتيين: أولهما قبل قسم server لتعريف المدة الزمنية لتخزين مختلف أنواع الملفات مؤقتًا، وثانيهما داخل كتلة server الذي يضبط ترويسات التخزين المؤقت ضبطًا سليمًا: . . . # Default server configuration # # Expires map map $sent_http_content_type $expires { default off; text/html epoch; text/css max; application/javascript max; ~image/ max; } server { listen 80 default_server; listen [::]:80 default_server; expires $expires; . . . القسم الموجود قبل قسم server هو قسم map الذي يربط بين أنواع الملفات ومدة التخزين المؤقت لهذا النوع من الملفات. استعملنا عدِّة خيارات ضبط فيه: القيمة الافتراضية هي off، والتي لن تُضيف أيّة ترويسات للتحكم بالتخزين المؤقت، وهذا خيارٌ جيدٌ للمحتوى الذي لا يتطلب تخزينًا مؤقتًا. لنوع text/html سنضبط القيمة إلى epoch وهي قيمةٌ خاصةٌ التي تعني عدم التخزين المؤقت نهائيًا، مما يجبر المتصفح على السؤال إن كانت الصفحة مُحدَّثة. لنوع text/css و application/javascript -والتي هي ملفات الأنماط CSS وسكربتات JavaScript- سنضبط القيمة إلى max وهذا يعني أنَّ المتصفح سيُخزِّن هذه الملفات مؤقتًا أطول مدة يستطيعها، مما يُقلِّل عدد الطلبيات لوجود عدد كبير من هذه الملفات التي ترتبط بصفحة HTML. آخر خيار لنوع ‎~image/‎ وهو تعبيرٌ نمطيٌ (regular expression) الذي يُطابِق جميع الملفات ذات النوع الذي يحتوي على العبارة image/‎ فيه (مثل image/jpg و image/png). وكما في ملفات CSS و JS، تتواجد عادةً صورٌ كثير في مواقع الويب، ومن الجيد تخزينها محليًا، لذا ضبطنا القيمة إلى max أيضًا. التعليمة expires داخل قسم server (التي هي جزءٌ من وحدة headers) تضبط ترويسات التحكم بالتخزين المؤقت؛ حيث تستخدم القيمة المأخوذة من المتغير ‎$expires الذي يربط بين أنواع الملفات ومدة صلاحيتها. وبهذه الطريقة ستختلف الترويسات المُرسَلة اعتمادًا على نوع الملف. احفظ الملف واخرج من المُحرِّر النصي، وأعد تشغيل خادوم Nginx لتفعيل الضبط الجديد: sudo systemctl restart nginx سنتحقق في الخطوة التالية من أنَّ الضبط الجديد يعمل عملًا سليمًا. الخطوة الرابعة: اختبار التخزين المؤقت في المتصفح لنُنفِّذ نفس الأمر الذي طلبنا فيه ملف HTML في القسم السابق: curl -I http://localhost/test.html سيكون الرد مختلفًا هذه المرة، إذ يجب أن ترى ترويستين جديدتين: HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:48:53 GMT Content-Type: text/html Content-Length: 1024 Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT Connection: keep-alive ETag: "57d40685-400" Expires: Thu, 01 Jan 1970 00:00:01 GMT Cache-Control: no-cache Accept-Ranges: bytes ترويسة Expires مرتبطة بتاريخٍ في الماضي وترويسة Cache-Control مضبوطةٌ إلى no-cache، مما يجعل المتصفح يسأل الخادوم إن توفرت نسخةٌ جديدةٌ من الملف (باستخدام ترويسة ETag كما سبق). ستجد ردًا مختلفًا عندما تُجرِّب على صورة: curl -I http://localhost/test.jpg ناتج الأمر السابق: HTTP/1.1 200 OK Server: nginx/1.10.0 (Ubuntu) Date: Sat, 10 Sep 2016 13:50:41 GMT Content-Type: image/jpeg Content-Length: 1024 Last-Modified: Sat, 10 Sep 2016 13:11:36 GMT Connection: keep-alive ETag: "57d40688-400" Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Accept-Ranges: bytes ارتبطت الترويسة Expires في هذه المرة بتاريخٍ في المستقبل البعيد، واحتوت ترويسة Cache-Control على max-age التي تخبر المتصفح كم ثانية يجب أن يُبقي على الملف. وهذا يُخبِر المتصفح أن يُخزِّن الصورة المُنزَّلة مؤقتًا لأطول مدة ممكنة، وبالتالي إذا ظهرت الصورة مرةً أخرى فستُستعمَل النسخة المحلية ولن تُرسَل الطلبية إلى الخادوم بتاتًا. يجب أن تكون النتيجة مشابهةً لملفَي test.js و test.css لأنهما ملفا JavaScript و CSS ويُضبَط لهما ترويسات التخزين المؤقت أيضًا، مَثَلُهُما كَمَثل الصور. إن ظهر عندك مثلما عرضنا في أمثلتنا، فاعلم أنَّ ترويسات التحكم بالتخزين المؤقت قد ضُبِطَت ضبطًا صحيحًا وسيستفيد موقعك من ناحية الأداء، وسيقل الحِمل على خادومك نتيجةً لتخزين المتصفح للملفات محليًا وعدم طلبها من الخادوم. عليك الآن أن تُخصِّص إعدادات التخزين المؤقت اعتمادًا على محتوى موقعك، لكن قد تجد أنَّ الضبط الذي وفرناه في هذا الدرس مناسبًا لتبدأ منه. الخلاصة يمكن أن تُستعمَل وحدة headers لإضافة أي نوع من الترويسات إلى رد HTTP، لكن من أفضل تطبيقات هذه الوحدة هو ضبط ترويسات التحكم بالتخزين المؤقت. إذ سيساعد ذلك في تحسين أداء مواقع الويب المُستضافة على خادومك، خصوصًا في الشبكات ذات زمن التأخير المرتفع (نسبيًا) مثل شبكات الهواتف المحمولة. يمكن أن يؤدي ذلك إلى تحسين ظهور موقعك في محركات البحث التي تأخذ عامل سرعة الموقع بالحسبان. حيث يُعتَبَر ضبط ترويسات التخزين المؤقت من أبزر نصائح أدوات اختبار سرعة الصفحات من Google (أقصد Google PageSpeed). لمزيدٍ من المعلومات التفصيلية عن وحدة headers، فارجع إلى توثيق Nginx الرسمي. ترجمة -وبتصرّف- للمقال How to Implement Browser Caching with Nginx’s header Module on Ubuntu 16.04 لصاحبه Mateusz Papiernik.
  11. سنتعلّم مبادئ HTML و CSS لإنشاء مشاريع ويب خاصة بنا. سيتميّز هذا الدرس بتركيزه على الجانب العملي بشكل كبير، حيث سنبدأ فورًا بإنشاء مشروع خاص بنا. أمّا بالنسبة للنواحي النظرية فسنشرحها عند الحاجة أثناء تقدّمنا ببناء المشروع. بهذه الطريقة سنكتسب أساسًا متينًا وسريعًا في مجال تطوير الويب. سأوجّهك خلال هذا المشروع إلى روابط خارجية تُشير إلى مصادر أخرى للتوسُّع في نقاط معيّنة إن أحببت ذلك. المشروع سيكون المشروع عبارة عن بناء ملف شخصي portfolio على الويب. سيضم صفحة بداية Home ومدوّنة Blog وصفحة تُظهر مشاريع ويب المستقبلية التي تنوي إنشائها Projects، بالإضافة إلى صفحة للتواصل Contact. الهدف من المشروع الهدف منه هو جعلك تدخل عالم برمجة الويب ومساعدتك كي تتعلّم كيفية إيجاد المزيد من المعلومات حول أي موضوع لوحدك. ستصبح قادرًا بعد ذلك على معالجة مشاريع ويب أكثر تعقيدًا. ما هو HTML و CSS؟ لغة الرُماز المعلَّم Hypertext Markup Language والتي ندعوها اختصاراً HTML هي لغة مسؤولة عن بُنية structure صفحة الويب. فمثلًا يمكنك تعريف عناوين headings وفقرات paragraphs ونصوص texts وصور images في HTML. أمّا بالنسبة لأوراق الأنماط المتتالية Cascading Style Sheet وندعوها اختصاراً CSS فهي مسؤولة عن تنسيق (تنميط) style وتخطيط layout صفحة الويب. يمكنك تعريف تنسيقات جديدة خاصة بالألوان والخطوط وطرق المحاذاة وحتى يمكنك إنشاء بعض التحريكات animations البسيطة في CSS. تذكّر: تزوّدنا HTML بالمحتوى في حين تُنسّق CSS هذا المحتوى. موقع ويب أم تطبيق ويب يمكننا بناء مواقع ويب websites معقّدة جدًّا باستخدام HTML و CSS فحسب. لكن ستكون مواقع الويب هذه ساكنة static، ويعني ذلك أنّ زوّار الموقع يمكنهم استعراض الصفحات لكنّهم لا يمكنهم التفاعل مع هذه الصفحات (باستثناء النقر على الروابط الموجودة في الصفحات). لبرمجة مواقع ويب ديناميكية dynamic تكون تفاعلية مع المستخدم، سنحتاج إلى لغة برمجة إضافية مثل JavaScript أو Dart. ويمكننا باستخدامهما تطوير (هو مفهوم أوسع من البرمجة) تطبيقات ويب Web Applications كاملة مثل التطبيقات التي تهتم بإجراء الحسابات المختلفة أو تطبيقات الألعاب أو تطبيقات المحادثة وغيرها الكثير. تعمل هذه التطبيقات في الواقع ضمن متصفّح الويب. كما توجد لغات برمجة وتقنيات أخرى مثل PHP وRuby وASP.NET تسمح ببناء تطبيقات ويب ديناميكية أيضًا ولكن تعمل هذه التطبيقات ضمن مزوّد خدمة الاستضافة (على المخدّم). كما يمكن المزج بين هذين الأسلوبين لإنشاء مواقع ويب فعّالة للغاية. يمكنك بعد الانتهاء من هذه الدروس، البدء بتعلّم مثل هذه اللغات والتقنيات وإنشاء تطبيقات ويب ديناميكية. الأجهزة المحمولة يُشكّل الوصول إلى مواقع الويب عن طريق الأجهزة المحمولة كالهواتف الذكيّة أو الأجهزة اللوحية نسبة كبيرة من عمليات الوصول العامة. وهكذا فإنّه من الضروري أن يظهر موقعنا بشكل جيّد على الشاشات الصغيرة. على العموم سنولي هذا الأمر اهتمامًا خلال هذه السلسلة التعليمية. الأدوات المستخدمة نحتاج إلى تطبيقين للدخول في عالم تطوير وبرمجة الويب، محرّر نصوص لإنشاء الملفات الخاصة بموقع الويب، ومتصفّح ويب لعرض وتجربة الموقع. 1- المحرر Editor سيكون كافيًا استخدام محرّر نصوص عادي (كبرنامج المفكرة Notepad في ويندوز مثلًا). ولكن من الأفضل استخدام محرّر نصوص يسهّل عملنا إلى حدٍّ كبير. لهذا الغرض أنصح باستخدام محرّر نصوص عصري ومخصّص لتحرير HTML. محرّر النصوص الذي أنصح به حاليًا هو Brackets (مجّاني من شركة أدوبي Adobe). يمكنك أن تستخدم أي محرّر تريده، ولكنّني في هذه السلسلة سأُشير أحيانًا إلى بعض وظائف تطبيق Brackets. يوجد محرّر نصوص جيّد أيضاً ويمكنك استخدامه وهو Atom، ويوجد محرّر نصوص آخر أيضًا، قديم قليلًا لكنّه جيّد وهو ++Notepad. حمّل ونصّب المحرّر Brackets إذا أردت ذلك. 2- المتصفح Browser يتوجّب على موقعنا أن يعمل على جميع المتصفحات الرئيسية بالطبع (Internet Explorer و Firefox و Chrome و Safari). على أية حال، أنصح باستخدام المتصفح Chrome لأغراض التطوير والبرمجة. يضم Chrome أدوات مفيدة للغاية لمطوّر الويب والتي سيستخدمها على نحو متكرّر. بالإضافة إلى ذلك، يدعم المحرّر Brackets المتصفّح Chrome بشكل جيّد، بحيث أنّ التغييرات التي تحدث في النص ستظهر مباشرةً ضمن Chrome (عن طريق ميزة اسمها Live Reload). حمّل ونصّب المتصفح Chrome الآن من هنا. إنشاء مستند HTML لنبدأ الآن بإنشاء مستند HTML الأوّل لنا من أجل موقع الويب: أنشئ مجلّدًا من أجل المشروع. سمّ المجلّد بالاسم Portfolio (أو أي اسم آخر ترغبه). افتح برنامج Brackets. من القائمة File اختر الأمر …Open Folder لتحديد وفتح المجلّد الذي أنشأناه قبل قليل. انقر بزر الفأرة الأيمن أسفل اسم المجلّد واختر New File لإنشاء ملف جديد، سمّه index.html. لديك الآن ملف نصّي فارغ اسمه index.html لماذا الملف index.html؟ في الواقع للملف index.html معنى خاص، فعندما نطلب من المتصفّح عنوان موقع ويب ما، وليكن مثلًا http://code.makery.ch، فعند ذلك سيُعرَض الملف index.html أولاً بشكل تلقائي، أي كأنّنا طلبنا العنوان http://code.makery.ch/index.html. بالنسبة إلينا، سيمثّل الملف index.html الصفحة الرئيسية. عمليتا العرض والتحديث يمكننا الآن تعبئة مستند HTML (الملف index.html) بالمحتوى. اكتب الأسطر التالية ضمن مستند HTML. لعرض الصفحة ضمن المتصفّح، انقر الأيقونة التي تُشبه البرق في الطرف الأيمن من البرنامج (المعاينة الحية Live Preview). سيُفتَح المتصفّح Chrome وسيُعرض المستند ضمنه، وفي حال أجريت أي تغيير جديد على مستند HTML فسترى نتيجة ذلك على المتصفّح مباشرةً، وهي في الحقيقة ميزة هامة وفعّالة. إذا لم تظهر الصفحة، اذهب إلى المكان الذي يوجد فيه الملف index.html وافتحه مباشرةً باستخدام Chrome أو أي متصفّح آخر. أمّا لم تُحدّث الصفحة تلقائياً، فاحفظ جميع الملفات المفتوحة (سننشئ ملفات أخرى تباعاً) ثم من نافذة المتصفح اضغط F5 على لوحة المفاتيح. تهانينا، لقد أنشأت موقع ويب الأوّل الخاص بك. التحييد Indentation لكي نُبقي الشيفرة نظيفة وواضحة، من المهم أن تعمل على تحييد النص بشكل صحيح باستخدام مفتاح الجدولة Tab من لوحة المفاتيح. يأخذ مفتاح Tab في برنامج Brackets أربعة فراغات بشكل افتراضي. بالنسبة لي أجد ذلك كثيراً بعض الشيء، لذلك أنصح أن تغيّر هذا لتصبح الفراغات spaces التي يأخذها المفتاح Tab تساوي 2، وذلك من أسفل نافذة Brackets. من المهم جدًّا أن ننتبه إلى تحييد الشيفرة من البداية، لكي نكتب شيفرة نظيفة وواضحة من بداية تعلّمنا للبرمجة عموماً. تلميح 1: استخدام Shift+Tab لكي تنقل المحاذاة إلى اليسار بدلاً من اليمين. تلميح 2: يمكنك محاذاة عدة أسطر بنفس الوقت إذا اخترتهم وضغطت Tab أو حتى Shift+Tab. عناصر HTML 1- الوسوم Tags في المثال السابق رأيت رموزًا مكتوبة ضمن رمزي <> تشكل هذه الرموز كلمات نُسميها الوسوم Tags. تتألف عناصر HTML عادةً (ولكن ليس دائماً) من وسمين، وسم للفتح opening tag ووسم للإغلاق closing tag. في مثالنا السابق كان <html> هو وسم للفتح، أمّا <html/> هو وسم للإغلاق حيث نلاحظ وجود محرف slash قبل اسم الوسم. أي نص موجود بين وسمي الفتح والإغلاق يُعتبر محتوى لعنصر HTML هذا. فمثلاً بالنسبة للوسمين <html> و <html/> نُخبر متصفّح الويب عن بداية ونهاية مستند HTML لصفحة الويب الخاصة بنا. أمّا الوسم الثاني الذي صادفناه هو الوسم <body>. يُحدّد هذا الوسم أنّ جميع المحتوى الواقع بين وسم الفتح <body> والإغلاق <body/> سيظهر بشكل مرئي للمستخدم في المنطقة الرئيسية من نافذة المتصفّح. 2- السمات Attributes تُعرّف السمات معلومات إضافية لعنصر HTML. وتقع هذه السمات ضمن وسم الفتح لعنصر HTML، ويكون لها دائماً اسم name وقيمة value. كمثال على السمات، دعنا ننظر إلى عنصر HTML الخاص بالروابط. وهو ربما من أهم العناصر على الإطلاق. يضم عنصر الروابط <a> السمة href (وهي اختصار للكلمتين hypertext reference) التي تحمل القيمة في هذا المثال http://code.makery.ch.ولكن سيعرض المتصفّح هذا الرابط على شكل النص التالي: My Website. البنية الأساسية لصفحة HTML لقد رأينا قبل قليل عنصري HTML وهما <html> و <body>. ولكن بنية صفحة (مستند) HTML تتكوّن عادةً من المزيد من العناصر. استبدل محتويات الملف index.html بالشيفرة التالية، بعد ذلك سنناقش كل عنصر HTML موجود فيها. بنية ملف (مستند) HTML <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Web Portfolio of Marco</title> </head> <body> <h1>Web Portfolio of Marco</h1> <p>Write anything you want to tell the world.</p> </body> </html> الشرح نضع في السطر الأوّل <DOCTYPE html!> دوماً. فهي تخبر المتصفّح عن نوع المستند. يشير الوسم <html> إلى بداية المستند والوسم <html/> إلى نهايته. يحتوي العنصر <head> (بين وسمي الفتح والإغلاق له) على معلومات إضافية حول الصفحة. وبشكل مختلف عن العنصر <body>، لا تظهر هذه المعلومات في نافذة المتصفح الرئيسية. يجب أن تكون هناك إشارة ضمن العنصر <head> حول الترميز character set المستَخدَم في هذا المستند: <"meta charset="utf-8>. إذا لم تحدّد الترميز المستَخدَم فإنّ بعض الرموز قد لا تظهر بصورة صحيحة. ربما قد لاحظت أنّ العنصر <meta> لا يمتلك وسم إغلاق. توجد بعض عناصر HTML التي لا تمتلك أيضًا وسوم إغلاق، ولكنها تعتبر استثناءً. نرى بعد ذلك الوسم <title> الذي يضم عنوان المستند والذي سيظهر على شريط العنوان لنافذة المتصفّح. كل شيء ضمن الوسم <body> سيظهر ضمن نافذة المتصفّح الرئيسية. يُعرّف العنصر <h1> العنوان الرئيسي الذي سيظهر للمستخدم ضمن صفحة الويب. ويمكن إنشاء عناوين فرعية أيضاً باستخدام العناصر <h2> <h3> <h4> <h5> <h6>. النص الموجود بين الوسمين <p> و <p/> يُعتبر فقرة مستقلة، وهذا ما يُعبّر عنه العنصر <p>. بعد كل وسم فتح لعنصر ما، يجب أن نحاذي العنصر التالي (بمفتاح الجدولة Tab) لتحسين عرض الشيفرة. ورغم أنّ ذلك ليس ضرورياً ولا يؤثّر أصلاً في عرض المستند، ولكن تأكّد من امتلاكك لهذه العادة الجيّدة. تلميح 1: يمكنك استخدام بنية HTML السابقة لأي صفحة HTML جديدة. تلميح 2: استخدم الاختصار Ctrl+S من لوحة المفاتيح لحفظ الملف الحالي. تلميح 3: استخدم الاختصار Ctrl+Z من لوحة المفاتيح للتراجع عن العمليات التي أجريتها. نحن مستعدّون الآن وبعناصر HTML البسيطة هذه، أن نرتقي بموقعنا إلى مستوى أعلى. في البداية لنُضِف صورة بحيث تبدو الصفحة الرئيسية لمشروعنا أكثر جمالًا. إدراج صورة لإدراج صورة نستخدم العنصر <img>. المثال التالي سيُدرج صورة موجودة ضمن ملف اسمه marco.jpg: <img src="marco.jpg" alt="Picture of me"> للعنصر <img> وسم فتح فقط ولا يوجد له وسم إغلاق. وهو يحتوي على سمتين src و alt. السمة src تُحدّد عنوان URL الذي يُعبّر عن اسم ملف الصورة ومساره. أمّا السمة alt فتمثّل النص البديل، وهو النص الذي يصف محتويات الصورة. يُستخدم هذا النص من قِبل محرّكات البحث، وفي حال تعذّر عرض الصورة ضمن الصفحة سيُعرض هذا النص بدلاً عنها. 1- عناوين URL النسبية والمطلقة تُستخدم عناوين URL من أجل السمة src الخاصة بعنصر الصورة، وأيضاً من أجل السمة href الخاصة بعنصر الارتباط. يُحدّد عنوان URL عنوان (مسار) ملف، وبصورة عامة العنوان هو مصدر resource قد يكون صورة أو صفحة ويب من موقع آخر. بالاعتماد على موقع الملف نستخدم إمّا العنوان النسبي relative أو العنوان المطلق absolute. فإذا كان الملف موجودًا ضمن نفس موقع الويب، عندها يمكن استخدام عنوان نسبي. فكما رأينا في المثال السابق اسم الملف وحده موجود دون عنوانه الفعلي (المطلق). يكون عنوان URL من النوع النسبي، نسبيًا دومًا إلى صفحة HTML الحالية، فإذا كان الملف المستهدف وصفحة HTML التي ستستخدمه موجودان ضمن نفس المجلّد فعندها يكفي الإشارة إلى اسم الملف فقط، أمّا إذا كانا ضمن مجلّدين مختلفين فعندها يحب أن يؤخذ ذلك بعين الاعتبار. فإذا فرضنا مثلًا أنّ ملف الصورة من المثال السابق موجودة ضمن مجلّد فرعي اسمه images سيكون عنوان URL النسبي لملف الصورة images/marco.jpg. أمّا إذا كان ملف الصورة موجود ضمن المجلّد الأب، فيمكنك عندئذ الوصول إليه باستخدام البادئة ( /.. ) أي سيصبح عنوان الملف في هذه الحالة marco.jpg/.. أمّا إذا كان الملف موجوداً ضمن موقع ويب آخر، فعندها يجب استخدام عنوان URL مطلق. تحتوي عناوين URL المطلقة على الاسم والمسار الكاملين للملف. حقائق عن عناوين URL: عنوان URL الذي يبدأ بـ //:http هو عنوان URL مطلق. عنوان URL بدون //:http هو عنوان URL نسبي بالنسبة إلى صفحة ويب الحالية. تُشير النقطة ( . ) إلى المجلّد الحالي. تُشير النقطتان ( .. ) إلى المجلّد الأب. أمثلة عن عناوين ويب النسبية والمطلقة: <!-- عناوين نسبية --> <a href="image-gallery.html">Image Gallery</a> <a href="blog/first-blog-entry.html">My First Blog Entry</a> <a href="../image-gallery.html">Back to Image Gallery</a> <!-- عناوين مُطلقة --> <a href="http://www.my-colleague.com/blog.html">Blog of a Colleague</a> 2- إضافة صورة إلى موقعنا لندرج صورة ضمن الصفحة، ينبغي نسخ ملف الصورة إلى المجلّد Portfolio. من الممكن أن تستخدم نفس الصورة الموجودة مع هذا الدرس، أو أن تستخدم صورة من عندك، ولكن احرص في جميع الأحوال على أنّك ستُحدّد اسم الملف مع الامتداد بدقّة. يجب أن تحصل على شيفرة شبيهة بما يلي (لاحظ أنّني أضفت عناوين فرعية بالإضافة إلى مزيد النصوص): الملف index.html مع الشيفرة اللازمة: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Web Portfolio of Marco</title> </head> <body> <h1>Web Portfolio of Marco</h1> <h2>Welcome!</h2> <p>Thanks for stopping by.</p> <p>Please have a look around. In the blog section I document my experiences in programming. You may also look at my web projects. Have Fun.</p> <img src="marco.jpg" alt="Picture of me"> <p>Marco :-)</p> </body> </html> والصورة التالية لما ستبدو عليه الصفحة في متصفّح الويب: سنتعلّم في الدرس الثاني كيف ننشر موقعنا على الانترنت. ترجمة -وبتصرّف- للدّرس HTML & CSS Tutorial - Part 1: Your First Website لصاحبه Marco Jakob.
  12. في الدرس السابق قمنا باستخدام برنامج فوتوشوب لتصميم واجهة موقع لغابة افتراضية باسم "Pinewood Forest". أمّا في هذا الدرس فسوف نقوم بتكويد ذلك التصميم باستخدام لغتي HTML وCSS وتحويله إلى صفحة ويب كاملة. كما سنقوم أيضًا باستخراج الصور الموجودة في التصميم لاستعمالها في الموقع. في حال أنك لم تقرأ الدرس السابق، أنظر إلى الصورة في الأعلى لترى التصميم الذي سوف نقوم بتكويده. يحتوي الموقع على صورة خلفية كبيرة وثابتة لتسمح لمحتوى الموقع بالتمرير(scroll) فوقها، والمحتوى نفسه مجزأ إلى عدة أجزاء، وتم استخدام مجموعة من الصور لجذب انتباه الزائر. استخراج الصور الموجودة في التصميم ستكون الخطوة الأولى قبل البدء بتكويد التصميم هي استخراج الصور من التصميم. بعض أجزاء التصميم يمكن عملها باستخدام CSS فقط ولكن أجزاء أخرى من التصميم سنحتاج فيها إلى الصور. يحتوي الجزء الرئيسي للموقع على صورة خلفية كبيرة، وسوف نحتاج إلى ضغط هذه الصورة لتقليل حجمها الكبير وذلك عن طريق اللجوء إلى خيار Save for web. كما قلنا سابقًا، سيحتوي الموقع على خلفية ثابتة وسوف يظهر المحتوى فوق هذه الصورة، وبالتالي فإن العناصر مثل الشّعار سنحتاج إلى استخراجها بصيغة PNG-24 لأن هذه الصيغة تدعم الشفافية (transparency). ستكون خلفية المحتوى الرئيسي للموقع ذات طابع شفاف أيضًا وبالتالي سوف نحتاج إلى استخراجها بصيغة PNG، وهذه الخلفية سيتم تقسمها إلى ثلاثة أقسام؛ قسم علوي وقسم سفلي وقسم مكرر في المنتصف. المجموعة النهائية للصور سوف تحتوي على صور بصيغة PNG وأخرى بصيغة JPEG. بعض الصور ستكون بحجم صغير، وهذه الصور سيتم تكريرها (باستخدام CSS) لإنشاء خلفيات مزخرفة، أمّا الصور الأخرى فسوف تكون صورًا بديلة عن النصوص لاستخدامها كعناوين. بنية ملف HTML <!doctype html> <html> <head> <meta charset="UTF-8"> <title>Visit Pinewood Forest</title> <link href="styles.css" rel="stylesheet" /> </head> <body> <div id="container"> </div> </body> </html> سيحتوي الملف الرئيسي (index file) على أكواد HTML. يُستخدم <doctype html!> لتعريف المتصفح بإصدار HTML المُستخدم ويعتبر أيضًا من الممارسات الجيدة في عالم تصميم الويب، لذلك احرص على أن يكون موجودًا في كل موقع تقوم بتصميمه. يتبع ذلك وسم <head> ويحتوي هذا الوسم على عنوان الصفحة وعلى رابط لملف CSS. وأخيرًا يوجد وسم <div> وسيحتوي هذا الوسم على بقية عناصر/وسوم الصفحة. <body> <div id="container"> <div id="header"> <p id="logo"> <a href="#" title="Return to the homepage"> <img src="images/pinewood-forest-logo.png" alt="Pinewood Forest logo" /> </a> </p> <ul> <li><a href="#">Visit</a></li> <li><a href="#">Discover</a></li> <li><a href="#">Trails</a></li> <li><a href="#">Maps</a></li> </ul> </div> </div> </body> </html> يبدأ التصميم بوسم div مع إعطائه id بقيمة "header" وسيحتوي هذا الوسم على الشّعار وعلى عناصر القائمة الرئيسية (navigation items)، وسيكون الشعار عبارة عن صورة داخل وسم <img> موضوعة في وسم <a>. تُستخدم title الموجودة في وسم <a> لتعريف المستخدم بالوجهة التي سيصل إليها حال نقره على الرابط، أمّا alt في وسم <img> فإنها تُستخدم لإعطاء المستخدم وصفًا عن الصورة في حالة عدم ظهور الصورة. يُعتبر وسم <ul> هو الوسم الشائع عند عمل القوائم الرئيسية لأنّه يُصوّر لنا وبدقة تلك القائمة على هيئة HTML حتى لو لم يكن هناك تنسيقات CSS. وبالرجوع إلى التصميم يمكنك ملاحظة أن الشعار موجود في الوسط بين قوائم العناصر الرئيسية، ولكننا سنبقي كلا العنصرين (الشعار والقائمة الرئيسية) مفصولين عن بعضهما حتى نحصل على هئية وملف HTML نظيف ومُرتّب، وسنلجأ لاحقًا إلى استخدام CSS لتحريك تلك العناصر حتى نحصل على نتيجة مرضية ومطابقة للتصميم. <div id="content"> <div id="feature"> <div id="feature-content"> <h1>Explore the forest</h1> <p>Find everything you need to explore and discover the mysteries of the forest, from maps and trail guides to must see attractions</p> <p class="btn"><a href="#">Begin your journey</a></p> </div> </div> </div> بعد الترويسة (header) تأتي منطقة المحتوى الرئيسي (main content)، ولجعل هيكل ملف HTML نظيفًا فسوف يتم وضع جميع العناصر في وسم <div> واحد، كما وستظهر منطقة الـfeature في بداية الصفحة وداخل وسم <div> ليتم تموضعها بشكل دقيق ومناسب. أمّا بالنسبة للعنوان الرئيسي في الصفحة (الذي يحتوي على النص "Explore the forest") فسوف يتم وضعه داخل وسم <h1>. لاحظ أيضًا أنه تم إضافة "class="btn إلى العنصر <p> ليمكننا تحويل هذا العنصر إلى زر باستخدام CSS. المستوى الثاني من العناوين سيكون موجودًا داخل وسم <h2>، وسيكون المحتوى الرئيسي منقسمًا إلى عمودين، بحيث يكون العمود الأكبر عبارة عن div مع id بقيمة "main" وبداخل هذا العمود توجد النصوص (عناصر <p>). لا تنسى تحويل الروابط إلى عناصر <a> وأي رموز خاصة (characters) إلى ما يقابلها من HTML entities (مثل رمز "&" يتم تحويله إلى "&"). وفي الأسفل من نفس العمود يوجد قسم "upcoming events"، ويمكننا استخدام عناصر <dl> ،<dt> و<dd> (اختصار للكلمات "Definition List"، "Definition Term" و"Definition Description" على التوالي) بحيث تحتوي عناصر dt على تاريخ الحدث وعناصر <dd> على وصف بسيط للحدث. لاحظ أننا استعملنا وسوم <span> داخل عناصر <dt> وذلك لإعطائها تنسيقات مميزة باستخدام CSS. <div id="side"> <div class="aside"> <a href="#"><img src="images/tracks-and-trails.jpg" alt="Tracks and Trails" /></a> <p>Pinewood Forest has a vast selection of walking and hiking trails to suit every visitor<a href="#">Find out more</a></p> </div> <div class="aside"> <a href="#"><img src="images/mountain-biking.jpg" alt="Mountain Biking" /></a> <p>Pinewood Forest is home to some of the most demanding XC and Freeride Mountain Biking routes<a href="#">Find out more</a></p> </div> <div class="aside"> <a href="#"><img src="images/christmas-events.jpg" alt="Christmas Events" /></a> <p>Pinewood Forest has a vast selection of walking and hiking trails to suit every visitor<a href="#">Find out more</a></p> </div> </div> </div> <div id="footer"> <p id="back-to-top"><a href="#">Back to top</a></p> </div> </div> بالنسبة للعمود الأصغر فسوف يكون موجودًا داخل عنصر div آخر مع id بقيمة "side". تتكون القائمة الجانبية (sidebar) من ثلاثة أقسام رئيسية وكل قسم يحتوي عنوان على شكل صورة وعلى وصف بسيط لكل قسم، ولأن كل صورة تحتوي على نص بداخلها فقد قمنا باستخدام alt لكل صورة حتى نحافظ على ما يسمى بالـaccessibility. وفي نهائية الصفحة قمنا بإغلاق وسم <div> الخاص بالمحتوى وتحتها يوجد div خاص بالـfooter وبادخله نص "Back to top" ليأخذنا إلى أعلى الصفحة عند الضغط عليه. انتهينا إلى الآن من هيكلة ملف HTML ويمكنك إلقاء نظرة إلى الصورة في الأعلى لترى كيف يجب أن يظهر بدون CSS. لاحظ أنه يمكن قراءة الملف حتى بدون تنسيق الملف باستخدام CSS. تنسيق الصفحة باستخدام CSS body, div, h1, h2, h3, h4, h5, h6, p, ul, ol, li, dl, dt, dd, img, form, fieldset, input, textarea, blockquote { margin: 0; padding: 0; border: 0; } body { font: 14px/26px Georgia, Serif; color: #444a54; background: #2d3237 url(images/bg-photo.jpg) center top no-repeat fixed; } #container { width: 960px; margin: 50px auto; } لنبدأ الآن بتنسيق الموقع باستخدام CSS. يُستخدم السطر الأول من أجل إزالة أي تنسيقات افتراضية للمتصفحات (يسمى هذا "CSS reset")، وبعد ذلك يوجد داخل المحدد body الخصائص العامة للخطوط في الموقع وصورة خلفية، ولأننا نريد هذه الصورة أن تكون ثابتة لا تتحرك مع باقي الصفحة عند التمرير(scrolling) فقد قمنا بإعطائها القيم "fixed" ،"top" و"center". وقد قمنا بإضافة لون أزرق (2d3237) حتى تظهر الخلفية بشكل أفضل لمن لا يمكنه رؤية الصورة لسبب أو لآخر وكذلك لمن يمتلك شاشات بدقة وأبعاد ضخمة. أمّا بالنسبة للحاوي الرئيسي (main container) فقد تم إعطاؤه عرض ثابت بقيمة 960px وتم توسيطه باستخدام الطريقة الشائعة margin: 0 auto. header { background: url(images/content-top.jpg) center bottom no-repeat; overflow: hidden; } header p#logo { position: relative; width: 295px; margin: 0 auto -74px auto; } header ul { width: 916px; margin: 0 auto 110px auto; overflow: hidden; list-style: none; } header li { float: left; } header li:nth-child(1) { margin: 0 70px 0 0; } header li:nth-child(2) { margin: 0 325px 0 0; } header li:nth-child(3), header li:nth-child(4) { margin: 0 0 0 70px; } header li a { font-size: 16px; letter-spacing: 9px; color: #4e5761; text-decoration: none; } header li a:hover { color: #7c8896; } يمكنك ملاحظة أنه تم إضافة صورة كخلفية للقسم العلوي من جزء المحتوى إلى الأسفل من الترويسة. ولموضعة الشعار وعناصر القائمة الرئيسية كما هو موجود في التصميم، فقد استخدمنا الخاصية margin بقيم سالبة. ولأن عناصر القائمة موجودة في كلا الجانبين من الشعار فقد تم استخدام nth-child لتحديد كل عنصر من العناصر الأربعة وإعطائه قيمة margin مناسبة، وعن طريق استخدام letter-spacing استطعنا تنفيذ التباعد بين الحروف(tracking) الموجود في التصميم. content { padding: 0 52px; overflow: hidden; background: url(images/content-repeat.png) center top repeat-y; } content #feature { width: 916px; height: 420px; position: relative; margin: 0 0 30px -30px; background: url(images/feature-bg.jpg); } content #feature #feature-content { position: relative; width: 384px; top: 92px; left: 460px; } content #feature #feature-content h1 { widht: 384px; height: 91px; margin: 0 0 5px 0; background: url(images/explore-the-forest.png); text-indent: -9999px; } content #feature #feature-content p { color: #fff; margin: 0 0 15px 8px; } content #feature #feature-content p.btn a { display: block; widows: 163px; height: 39px; background: url(images/begin-your-journey.png); text-indent: -9999px; } content #feature #feature-content p.btn a:hover { margin: -1px 0 0 0; } بما أنّ ارتفاع div الخاص بالمحتوى سيختلف من صفحة لأخرى، فقد قمنا باستخدام صورة ليتم تكريرها حتى نسمح لجزء المحتوى أن يتمدد بدون قيود، واستخدمنا padding على اليمين واليسار حتى نُبعد محتوى الصفحة عن الحواف. ولأنّ منطقة المحتوى ستحتوي على عمودين وكل منهما يحتوي على الخاصية float، فسوف نحتاج إلى استخدام overflow: hidden حتى يظهر كل شيء بشكل جيد. إعطاء قسم الـfeature الخاصية position: relative سيسمح للمحتوى بالتحرك في مكانه، كما أنّ القيمة السالبة للخاصية margin ستعوّض عن قيمة padding التي تم إعطاؤها لـdiv المحتوى وذلك لنسمح لذلك القسم بالتمدد إلى أقصى أطراف الصفحة. كما أنه تمّ استخدام صورة في وسم h1، ولكن تم تنسيق الفقرة باستخدام خصائص font في CSS. وبالنسبة للزر، فقد تم استخدام صورة وإعطائه بعض التنسيقات حتى يظهر بشكل جيد. content #main { width: 536px; float: left; margin: 0 20px 0 0; } content h2 { font-size: 20px; font-weight: normal; margin: 0 0 20px 0; } content p { margin: 0 0 20px 0; } content a { color: #3f6489; } content a:hover { color: #0d3965; } content dl { } content dt { float: left; width: 40px; height: 50px; margin: 0 15px 0 0; background: #a1a3a5 url(images/date-bg.png); font-size: 30px; color: #fff; text-align: center; } content dt span { display: block; font-size: 12px; font-weight: bold; text-transform: uppercase; } content dd { float: left; width: 480px; } content dd h3 { float: left; font-size: 20px; font-weight: normal; } content dd span { float: left; margin: 4px 0 0 10px; visibility: hidden; } content dd p { clear: left; } content dd:hover span { visibility: visible; } سيكون الـdiv الرئيسي هو الأعرض بين العمودين؛ بعرض 536px. وسيكون العرض لكل من main وside بالإضافة إلى الـmargin بينهما هو العرض الخاص بـdiv الأب منقوصًا منه قيمة padding اليسار واليمين. تم تحويل عناصر dt إلى أيقونة التاريخ عن طريق إعطائها عرض وطول ولون خلفية رمادي. وباستخدام تنسيقات font مناسبة أمكننا جعل نص التاريخ كبيرًا وبلون أبيض، كما أنّه تم جعل الخط الخاص بالعنصر span أصغر بقليل حتى يظهر الشهر أسفل رقم اليوم بشكل جميل. وحتى تظهر عناصر dt وdd بجانب بعضها فقد تم إعطاؤها الخاصية float: left. لاحظ أننا استخدمنا visibility: hidden على العنصر span وذلك حتى نخفيه عن أنظار الزائر إلى أن يضع مؤشر الفأرة فوق عنصر dd لنقوم عندها بإظهار رابط "View more info". content #side { width: 300px; float: left; } content .aside { padding: 17px 0 0 17px; margin: 0 0 30px 0; background: url(images/aside-bg.png) center top no-repeat; } content .aside img { margin: 0 0 15px 0; } footer { padding: 70px 22px; background: url(images/content-bottom.png) center top no-repeat; } footer p#back-to-top { float: right; font-size: 11px; } footer p#back-to-top a { color: #fff; text-decoration: none; } footer p#back-to-top a:hover { color: #d7d9d8; } كل عنصر aside. تم إعطاؤه خلفية مزخرفة، وبالنسبة للخطوط فإنها ستأخد التنسيقات الخاصة بـ div المحتوى بسبب ما يسمى بالتوريث (inheritance). أمّا بالنسبة لرابط "back to top" فسوف نضطر إلى إعطائه تنسيقات جديدة لأنه موجود خارج div المحتوى، ولأنّ هذا الرابط موجود ضمن خلفية داكنة وخارج المحتوى الرئيسي فإننا سنحتاج لتعديل الألوان وجعلها مختلفة عن البقية الموجودة في باقي الصفحة. بقي شيء واحد قبل أن ننتهي من هذا الدرس وهو أنّه يجب عليك أن تعرف أن خاصية nth-child غير مدعومة في بعض إصدارات متصفح Internet Explorer، لذلك إذا أردت أن تدعم تلك المتصفحات فيجب عليك استخدام jQuery: $(document).ready(fucntion() { $("#header ul li:nth-child(1)").css("margin-right", "70px"); $("#header ul li:nth-child(2)").css("margin-right", "325px"); $("#header ul li:nth-child(3)").css("margin-left", "70px"); $("#header ul li:nth-child(4)").css("margin-left", "70px"); }); إلى هنا نكون قد أنهينا درسنا وحصلنا على صفحة كاملة وجاهزة. يمكنك أيضًا تصفح الموقع بشكله النهائي إذا أحببت ذلك. أو تصفح الملفات المصدرية. ترجمة -وبتصرف- للمقال: Design a Textured Outdoors Website in Photoshop لصاحبه: Iggy.
  13. يُدرك كل مصمّم جرافيك أنّ مهمّة اختيار تركيب ومزج الألوان وتناسقها هي واحدة من أهم أجزاء عمليّة التّصميم، سواء أكان ذلك التّصميم موجّه للطّباعة أم للعرض على شبكة الويب. لا يوجد أي تركيبة ألوان عالميّة وموحّدة بإمكانها أن ترضي جميع العملاء. بالنّسبة لبعض المصمّمين فإنّ عمليّة تركيب الألوان هي مسألة التّجربة وتحديد الأخطاء ثم التجربة مجدّدًا وهكذا، إلى غاية الحصول على التّركيبة المناسبة، ولكن اعتماد هذه الطّريقة يعني إهدار الكثير من الوقت الثمين. الوقت الذي يُعتبر سلعةً هامة في عالم تصميم الجرافيك والذي يسير بخطوات متسارعة. إلاّ أنّه يُمكن التّقليل من ذلك الوقت عن طريق الاعتماد على بحوث ودراسات متخصّصة ومناسبة، وكذلك من خلال استخدام الذّوق الذي تتمتّع به كمصمّم أو حدسك السّليم تجاه الأنماط. كيف تفهم أساسيات عجلة الألوان Color Wheelقبل كلّ شيء، من المهم أن تعرف أساسيّات عجلة الألوان، ويجب على كلّ مصمّم أن يطّلع عليها عن ظهر قلب. الضّوء الأبيض هو مزيج من كل ألوان الطّيف، والتي تنقسم إلى ثلاث مجموعات أساسيّة هي: الأحمر، الأزرق والأصفر، ومن خلال المزج بين تلك الألوان الثلاثة بإمكانك أن تركّب أي لون تتخيّله ويمكن للعين البشرية أن تراه. وحتّى تكون قادرا على خلق تركيبات ألوان جميلة وجذّابة يجب عليك أوّلا أن تعرف عجلة الألوان Color Wheel، حيث سأحاول شرحها لك بطريقة سهلة خالية من التّعقيدات. الألوان الأحادية monochromatic colorsتجعلك تستخدم لون واحد من مجموعة ألوان مختلفة، على سبيل المثال: بإمكانك استخدام تركيبة هذه الألوان لتصميم موقع معيّن : الّلون الأساسي الذي قمنا باستخدامه في الصورة السابقة هو الّلون الأخضر، الأخضر الفاتح (50% أبيض) والأخضر الغامق (50% أسود). واستخدام الألوان الأحادية monochromatic colors في التصاميم يضيف لها رونقًا واحترافية، فيكون التصميم بسيطًا لا تعقيد فيه (خاصة إذا كان التصميم يستخدم قليلا من الإضافات والتأثيرات إلا أن ذلك قد يجعل منه تصميما مملًا ومنفرًا. الألوان المكملة Complementary colors من أكثر تركيبات الألوان جاذبيّة هي تلك التي تُظهر التّناقض وتلفت الانتباه. وتنتج تلك النّوعية من خلال المزج بين الألوان التي تكون متقابلة في الدّائرة اللّونيّة، حيث تتميز بكونها ألوانا جريئة، مثيرة للاهتمام وجذّابة بصريا. تأكّد خلال تركيبك للألوان الخاصة بتصاميم عملائك أن تختار تلك التي تظهر بشكل جميل حين تقوم بمزجها، بعض التّركيبات سينتج عنها ألوانا جدّ صارخة، حاول أن تتجنّبها. الألوان التماثلية Analogous colors الألوان التّماثلية Analogous colors هي الألوان التي تصطف بجانب بعضها البعض علي عجلة الألوان الأساسية، وهي شبيهة بالألوان الأحادية monochromatic colors في كونها مناسبة جدا للتّصاميم المهنية والتّجارية، كما أنّها ملفتة للانتباه باعتبارها تضيف نوعا من التباين والجاذبية على التّصميم. الألوان التّماثلية سهلة الاستخدام ودائما تظهر بشكل جميل. الألوان المثلثية Triadic colors الألوان المثلّثية Triadic colorsهي ألوان مستقلة موجودة على العجلة والتي تشكل مثلّثا بمجرد الربط فيما بينها، ويتميز هذا النمط من الألوان في كونه يخلق نوعا من الجماليّة والتوازن. إرضاء العملاء باستخدام تركيبات لونية صحيحة ومناسبة كما ذكرنا سابقا فإنّه لا يمكننا إقناع جميع العملاء باستخدام نموذج ألوان معيّن، يجب أن تعرف أولا مؤسّسة عميلك (إذا كان التصميم مثلا خاص بمؤسّسته)، وقبل أي شيء آخر يجب أن تعرف ما تقوم به الشركة والمنتجات أو الخدمات التي تقدّمها، ذلك سيعطيك فكرة أولية حول نوعيّة الألوان التي ستختارها، وأيضا لا تنسى أن تطلع على مجموعة من تصاميم لشعارات ناجحة. المطاعم، الوجبات السريعة والمنتجات الغذائيةبالنّسبة للشّركات التي تركّز على الغذاء والطعام، حاول أن تستخدم اللّونين الأحمر والأصفر بكثرة، لأنها تعتبر ألوانًا جذّابة وسهلة الالتصاق بذهن المتلقي (الشخص الذي يراه)، بالإضافة إلى أنه يُنصح باستخدام الألوان الحارة والصّلبة، لأن اللونين الأصفر والأحمر يحفزان على الشعور بالجوع من خلال تسريع عمليّة الأيض، الأمر الذي يؤدّي إلى فتح الشهية ورفع من نسبة الطلب على الأكل أكثر مما ينبغي، تجنب استخدام اللون الأزرق والأرجواني للمطاعم نهائيا، لأنها تعمل على التخفيف من شهية الأكل لا شعوريا. أجسامنا تتفاعل سلبيا مع اللون الأزرق والأرجواني، أما الأخضر والبني فهما لونين مناسبين للاسترخاء و الأطعمة غير الرسمية (casual) كالمقاهي مثلا، كذلك جرّب أن تستخدم الألوان المكمّلة والألوان المثلثية. هذه مجموعة من لوحات الألوان الجذابة والتي يمكن استخدامها للمطاعم، الوجبات السريعة والمنتجات الغذائية: مساحيق التجميل ومواد التنظيفهنا نختار الألوان التي تعبر عن الأنوثة، النعومة والنّظافة. ألوان الباستيل مثل الأبيض، الأرجواني، الأزرق الفاتح، والزهري الفاتح هي اختيار رائع يمكنك استخدامه. تجنّب الألوان الحارّة وغير الناعمة، كما بإمكانك استخدام الألوان الأحادية والألوان الحيادية لأنها تدل على النظافة والبساطة. هذه مجموعة من لوحات الألوان الجذابة والتي يمكن استخدامها لمساحيق التّجميل ومواد التّنظيف: المؤسسات الحكومية، المؤسسات العامة، المنظمات الحكومية وغير الحكوميةعند قيامك بتصميم لإحدى المؤسّسات الحكومية، أو المؤسسات العامة أو لإحدى المنظمات، عليك أن تأخذ بعين الاعتبار أنها يجب أن تظهر كمؤسسات محترمة، جديرة بالثقة وذات كرامة. لذا اختر ألوانا تكون إيجابية وجميلة في نفس الوقت، كاللون الأخضر والأزرق. تمنح هذه الألوان الجميلة نوعا من الإيجابية وتعطي صورة عن المؤسسة أنها صلبة، قوية وجديرة بالثقة. المنظّمات الحكومية وغير الحكومية تفضل أن تستخدم الأحمر، الأبيض والأزرق في تصاميم شعاراتها مثل ما هو مستخدم في العلم الأمريكي وهي أيضا علامة على القومية والنزاهة. حاول استخدام الألوان الأحادية والتماثلية وقلل من استخدام الألوان المتباينة (الألوان المكملة). هذه مجموعة من لوحات الألوان الجذابة والتي يمكن استخدامها للمؤسّسات الحكومية، المؤسسات العامّة، المنظّمات الحكومية وغير الحكومية: الشّعارات أو التّصاميم الجرافيكية الخاصّة بالمؤسّسات التّعليمية، شركات التّأمين والمستشفيات أيضا تتبنّى ذات القاعدة. الفنادق، المنتجعات ومنشآت الضيافة الأخرىعند قيّامك بتصاميم تخص الفنادق والمنتجعات ركز على الشعور بالراحة، الاسترخاء والضيافة واختر الألوان الترابية والطبيعية. اللون البني، الأخضر والأزرق هي من أكثر الألوان التي توحي بالاسترخاء والهدوء، تجنب الألوان الصّارخة كما بإمكانك استخدام الألوان الأحادية monochromatic colors. لكن حاول أن تستخدم الألوان بحد أدنى. الأسود، الأبيض، الفضي والذهبي هي الأخرى اختيارات رائعة لتصاميم الفنادق والمنتجعات، خاصة إذا كانت من تصنيف خمس نجوم وكانوا يرغبون في الاستفادة من الترف والرقي. الخلاصةتعتبر الألوان طريقة جيدة لجذب انتباه المشاهدين، إلا أن استخدام الكثير منها سيصرف القرّاء، لذلك حاول التقليل قدر الإمكان من استخدامها واكتف فقط باستخدام من 2-4 ألوان. عمليّة مزج وتركيب الألوان ليست مجرّد عملية تتم حسب مزاج المصمم، وإنما تتم من خلال البحث والدراسة المتأنية، وكذلك من خلال معرفة أساسيات عجلة الألوان والتركيب، كلّ ذلك سيمكنك من إنشاء الآلاف من تركيبات الألوان الرّائعة والمبهرة. ترجمة -وبتصرّف- للدّرس Guide to Choosing Color Combinations When Building Sites For Clients لصاحبه James Richman. حقوق الصورة البارزة: Designed by Freepik.
  14. css 101

    لكتابة تنسيقات CSS يمكن قراءتها بسهولة بإمكانك إضافة مسافات فارغة وتعليقات في ورقة الأنماط لجعلها أسهل قراءة. بالإمكان أيضًا جمع المُحدّدات معًا، عندما تريد تطبيق نفس القاعدة على أكثر من هدف. هذا الدرس جزء من سلسلة تعلم CSS: مدخل إلى أوراق الأنماط المتتالية (CSS). آلية عمل تعليمات CSS داخل المتصفحات. المحددات (Selectors) في CSS. كيفية كتابة تعليمات CSS يسهل قراءتها. (هذا الدرس) تنسيق نصوص صفحات الويب باستخدام CSS. التعامل مع الألوان في CSS. إضافة محتوى إلى صفحة ويب باستخدام CSS. تنسيق القوائم (Lists) في CSS. تعرف على الصناديق (Boxes) في CSS. رصف العناصر (Layout) في CSS. الجداول (Tables) في CSS. التعامل مع أجهزة العرض المختلفة والمطبوعات في CSS. المسافات الفارغة (Whitespace) مصطلح مسافة فارغة (whitespace) يعني المسافة المعروفة وعلامات الجدولة (Tab) ومحرف السّطر الجديد. بإمكانك استخدام هذه المحارف لتسهيل قراءة ورقة الأنماط. لاحظ أن مصطلح المسافة الفارغة قد يستخدم في سياق تخطيط الواجهات للإشارة إلى الجزء من الصفحة الّذي يُترك دون عناصر: كالحواف (margins) والحشوات (gutters) والمسافات بين الأعمدة والسّطور. الملف الّذي تتدرّب عليه يحوي قاعدة واحدة في كلّ سطر، وأقل ما يمكن من المسافات الفارغة، وعندما تصبح ورقة الأنماط أكبر، فإنّ هذا الأسلوب سيجعل قراءة الورقة (ومن ثمّ صيانتها) أصعب. لك كامل الحرّيّة في اختيار أسلوب تنسيق الورقة الّذي ترغب فيه، ولكن قد يكون لبعض المشاريع الّتي يعمل عليها أكثر من شخص أسلوب مُتّفق عليه. أمثلة يُفضّل بعض المُصمّمين أسلوبًا وجيزًا في الكتابة، بحيث لا يفصلون السّطر إلا عندما يصبح طويًلا للغاية: .carrot {color: orange; text-decoration: underline; font-style: italic;} ويُفضّل آخرون جعل كل زوج من الخواص وقيمها في سطر منفرد: .carrot { color: orange; text-decoration: underline; font-style: italic; } وبعضهم يحاذي هذه السطور بمسافتين أو أربع أو بمحرف Tab: .carrot { color: orange; text-decoration: underline; font-style: italic; } والبعض يحبّ محاذاة كلّ شيء شاقوليًّا (ولكن هذا صعب الصّيانة): .carrot { color : orange; text-decoration : underline; font-style : italic; } والبعض يفضّل استخدام عدد مختلف من المسافات في كلّ مرّة لتسهيل القراءة: .vegetable { color: green; min-height: 5px; min-width: 5px } .vegetable.carrot { color: orange; height: 90px; width: 10px } .vegetable.spinach { color: darkgreen; height: 30px; width: 30px } البعض يستخدم محارف Tab، والبعض يستخدم المسافات فقط. التعليقات (Comments) تبدأ التعليقات في CSS بـ‎/*‎ وتنتهي بـ‎*/‎. بإمكانك استخدام التعليقات للشرح أو توضيح جزء معيّن في ورقة الأنماط، وأيضًا لحجب (comment out) أجزاء من الورقة مؤقّتًا بغاية تجريب التغيّرات. لحجب جزء من الورقة، أحِط هذا الجزء بتعليق بحيث يتجاهله المتصفّح. توخَّ الحذر في موضعي بداية التّعليق ونهايته، إذ يجب أن تكون بقيّة الورقة سليمة الصّياغة: /* style for initial letter C in first paragraph */ .carrot { color: orange; text-decoration: underline; font-style: italic; } تجميع المحددات عندما تتشارك عدّة عناصر بقاعدة واحدة، يمكن تحديد مجموعة من المحدّدات مفصولة بفاصلة لاتينية ","، وعندها فإنّ القاعدة ستُطبّق على كلّ العناصر المعنيّة. لتطبيق قواعد لكلّ عنصر من العناصر السّابقة على حدة، يمكن تعريف قاعدة منفصلة في موضع آخر من ورقة الأنماط تستهدف العناصر المنفردة. مثال تجعل هذه القاعدة لون <h1> و<h2> و<h3> واحدًا. وهذا يجعل من السّهل تغيير اللون من مكان واحد لكلّ العناصر مرّة واحدة: /* color for headings */ h1, h2, h3 {color: navy;} تمرين: إضافة التعليقات وتحسين هيئة ورقة الأنماط حرّر ملف CSS الّذي تتدرّب عليه، وتأكد من احتوائه على هذه القواعد (بغضّ النظر عن الترتيب): strong {color: red;} .carrot {color: orange;} .spinach {color: green;} #first {font-style: italic;} p {color: blue;} اجعل قراءته أسهل بإعادة ترتيبه بطريقة تراها منطقيّة، وبإضافة مسافات فارغة وتعليقات في أماكن مناسبة. احفظ الملفّ وحدّث الصّفحة في المتصفّح لتتأكّد من أن تعديلاتك لم تؤثّر على النّتيجة: تمرين احجب جزءًا من ورقة أنماطك، دون تعديل أيّ شيء آخر، بحيث تجعل الحرف الأوّل من المستند أحمر اللّون: (هناك أكثر من طريقة لتحقيق هذه النّتيجة) شاهد الحل إحدى طرق فعل ذلك هي احتواء قاعدة .carrot بتعليق: /* .carrot { color: orange; } */ ما التالي؟ استخدمنا تنسيقي الخطّ المائل والمُسطّر في ورقة أنماطنا. سنتعرّف على كيفية إضافة تنسيقات أخرى للنّصوص في الدرس القادم: تنسيق نصوص صفحات الويب باستخدام CSS ترجمة -وبتصرف- للمقال Readable CSS من سلسلة Getting started with CSS على شبكة مطوّري Mozilla.
  15. أنشأنا في الدرس السابق موقع الويب الأوّل لنا، سنتعلّم الآن كيف سننشر موقع الويب هذا بشكل فعليّ على الانترنت. ملاحظة: لن يكون هناك الكثير من الزوار لموقعك في البداية، مالم تعط الناس عنوان الموقع على الانترنت. الاستضافة لكي يستطيع الجميع الوصول إلى موقعنا على الانترنت، نحتاج إلى مُخدّم Server يُخزّن موقعنا عليه، بالإضافة إلى عنوان URL يُشير إلى الموقع. هناك عدد هائل من الشركات التي يمكن أن تقدّم لك خدمة تأجير مساحة على المُخدّم لهذا الغرض. تُسمّى هذه الخدمة عادةً باستضافة ويب Webhosting. نستعرض بعض الاستضافات المجّانية المُتاحة. أنصح أن تبدأ بخدمة BitBalloon إذا كانت هذه هي التجربة الأولى لك. 1- الاستضافة على BitBallon خدمة BitBallon بسيطة ورائعة وأنصح بها. إليك الخطوات اللازمة للتسجيل: 1. اشترك ضمن موقع BitBalloon. وذلك بالنقر على زر التسجيل Sign Up ثم اختر Sign in Using Persona. بعد ذلك أدخل بريدك الإلكتروني وكلمة المرور. 2. عندما تسجّل الدخول، يمكنك ببساطة سحب كامل مجلّد موقع الويب (المجلّد Portfolio) إلى المكان المخصّص في صفحة الخدمة. 3. ربما تستغرب هذه البساطة، ولكن بمجرّد تحميل الموقع سيُولّد عنوان URL يُشير إلى موقعك الذي حمّلته قبل قليل. انقر هذا العنوان واختبر ظهور الموقع بشكل صحيح. 4. لتبسيط عنوان URL المولّد بشكل آلي، يمكننا النقر على Edit name وإدخال اسم مناسب. 5. من أجل التحديثات التي من الممكن أن تجريها على الموقع، اسحب مجلّد الموقع من جديد إلى الصندوق المسمّى Drag & Drop to Update your Site. 2- الاستضافة على Google Drive يمكن استخدام خدمة Google Drive كخدمة استضافة. الأمر السلبي الوحيد هنا، هو أنّك ستحصل على عنوان URL طويل جدًّا. لنجري الخطوات التالية للاستضافة: حمّل مجلّد الموقع إلى Google Drive. حدّد المجلّد المُحمّل ثم اختر مشاركة Share. انقر فوق خيارات متقدّمة Advanced وغيّر مستوى الوصول إلى Public on the web أي متاح للعموم على الانترنت. افتح المجلّد في Google Drive وتأكّد من أنّ جميع ملفّات الموقع قد حمّلت (index.html والصور …الخ). انسخ الرموز التي تأتي بعد الكلمة ( /folders#) ضمن شريط العنوان للمتصفّح. ستكون هذه الرموز هي المُعرّف الخاص بالمجلّد المُحمّل. أدخل في شريط العنوان للمتصفّح العنوان التالي http://googledrive.com/host متبوعًا بالرموز التي نسختها من الخطوة السابقة. يمكن الآن لأي شخص لديه هذا العنوان الوصول إلى موقعنا. 3- الاستضافة على Dropbox يمكن استخدام Dropbox كخدمة استضافة. ولكي نتمكّن من ذلك نحتاج إلى خدمة إضافية لتوجيه الطلبات إلى الموقع المُستضاف. توجد خدمتان يمكن استخدامهما وهما Pancake و DropPages. 4- الاستضافة على GitHub إذا كان لديك بعض الخبرة البرمجية فعندها يُعتبر GitHub طريقةً رائعة لاستضافة مواقع الويب. تُعتبر GitHub منصّة لتسهيل التشاركية بين المبرمجين، كما تُتيح هذه المنصة استضافة مجّانيّة لصفحات الويب وذلك على صفحات GitHub. تؤمّن صفحات GitHub المزيد من الخيارات (فمثلاً تستطيع استخدام النطاق domain الخاص بك)، لكنها تتطلّب بعض المهارات في التعامل مع نظام التحكم بالإصدارات البرمجية Git. تصغير عناوين URL يمكن أن يكون عنوان موقعك طويلًا جدًّا وذلك بحسب الاستضافة التي اخترتها. توجد بعض الخدمات البسيطة لتصغير عنوان URL الخاص بموقعك. لتصغير العناوين فائدة كبيرة، حيث يمكن إدخالها يدويًا بسهولة ضمن متصفح الويب في هاتفك الذكي مثلًا، كما توجد بعض الخدمات التي تزوّدك بكود QR للوصول السريع من هاتفك الذكي إلى الموقع مباشرة باستخدام كاميرا الهاتف فحسب. إليك قائمة من بعض خدمات تصغير العناوين: خدمة Goo.gl (تتضمن توليد كود QR). خدمة bit.ly. خدمة Tiny.cc. النطاق الخاص بنا ربما يأتي يوم نرغب فيه بأن نحصل على اسم نطاق خاص بنا مثل http://www.my-super-website.com. يمكنك في بعض الحالات تسجيل اسم نطاق ضمن مزوّد خدمة الاستضافة نفسه (كما هو الحال مع خدمة الاستضافة BitBallon). أو يمكنك الوصول إلى عدد كبير جدًّا من خدمات تسجيل النطاقات الخاصة، تقدّم بعضها عروضًا مختلفةً عن بعضها الآخر، يمكنك البحث في Google لتصل إلى عدد كبير منها. سنُضفي على الموقع في الدرس الثالث بعض تأثيرات التنسيق المختلفة عن طريق CSS. ترجمة -وبتصرف- للمقال HTML & CSS Tutorial - Part 2: Publishing Your Website لصاحبه Marco Jakob.
  16. إن القدرة على البرمجة هي مهارة رائعة حيث تعطيك شعورًا بالرضى على المستوى الشخصي والمهني، بالإضافة إلى أنها تمكّنك من البناء وحل المشاكل والاختراع. كما تستطيع أن تفتح لك أبوابًا لكل أنواع المهن بفوائد كبيرة، كمرتبٍ محترم أو حرية العمل من أي مكان وفي أي وقت، أو كلاهما معًا. من الطبيعي إذن أن نرى تزايد عدد الأشخاص من مختلف الخلفيات الذين يقررون أنهم يرغبون بتعلّم البرمجة. ولكنهم يصطدمون في بداية الطريق بحقيقة غير سارّة: تعلم البرمجة أمرٌ صعب. هناك الكثير من التعقيد والارتباك، وسيكون كل شيءٍ تقريبًا في البداية غير منطقي. وعلى عكس التوقعات، قد يستمر شعور "لا أفهم ذلك" لوقتٍ طويل من الرحلة تلك، دافعًا العقول المتحفزة للتعلم إلى الشعور باليأس، الضياع أو الرّغبة بالاستسلام. العبرة من القصة هي أنه عليك أن تكون مستعدًا. إن الطريق إلى فردوس البرمجة هو طريقٌ طويل، وبدون العقلية الصحيحة في البدء، سوف يفقد الطريق بريقه بسرعة. في هذا المقال، سأحاول تقديم بعض الإرشادات حول ما يجب توقعه في هذه الرحلة، وكيف تواجه ذلك، وماهي الأدوات والمصادر لتساعدك في رحلتك. ما يجب توقعهقد يبدو الأمر بديهيًّا، ولكن أول أمر عليك إدراكه هو أن البرمجة في جوهرها موضوعٌ تقني. المهارات التي ستكتسبها في البداية ستتطلب الكثير من "الدّقة" و "الصحة" ومحاولات المراوغة لن تفيدك إطلاقًا. عليك أن تتعلم قليلًا من الرياضيات، وكذلك الكثير من الأمور التي قد "تبدو" وكأنها رياضيات، مثل المنطق العمليّاتي. خلاص القول هي أن تعلم أساسيات البرمجة يتطلب الكثير من التركيز والتدريب. ولكن اعلم أن عددًا لا يحصى من الأشخاص، التقنيين وغير التقنيين، نجحوا باجتياز هذه الرحلة قبلك، فلا تشعر بالتثبيط. وكما سترى هناك كميّة هائلة من المصادر لأشخاص مثلك تمامًا للمساعدة على جعل هذه العملية أسهل ما يمكن. إن منحنى تعلم البرمجة أكثر ما يكون انحدارًا في بدايته. هناك كمية كبيرة من الأساسيّات التي عليك استيعابها، وذلك يتضمن الأجزاء المختلفة من لغة البرمجة (التعابير expressions، المُتغيّرات variables، أنماط البيانات data types، العمليات operators، الحلقات loops، الجمل الشرطيّة conditional statements، التوابع functions، الأصناف classes)، والتقنيات لفهم كم من الوقت والذاكرة سيستخدم حاسوبك لتنفيذ نصك البرمجيّ (درجة التعقيد). ستكتب الكثير من البرامج التي لن تعمل في أول مرة، وبالتالي ستتأقلم مع كابوس كل مُبرمج: التّنقيح debugging. عند تعلّمك كيفيّة كتابة البرنامج، ستصبح قادرًا على تعلم كيفيّة كتابة برنامج جيّد. إن كتابة برنامجٍ فعّال، سهل الفهم والقراءة ومن السهل تطويره، هو فنّ، وهذا أمر يتطوّر بشكلٍ مستمر. سوف تتمكن من البدء باستكشاف فلسفات برمجيّة وتنتقل من مجرد كونك "مُبرمج" إلى "مهندس برمجيّات". وهذه عملية تتطلب أيضًا الكثير من الوقت والتدريب، ولكن كلما تفوّقت في ذلك، فُتحت أمامك فرصٌ أكثر. كيف تتعلم البرمجةتختلف الرحلة إلى فردوس البرمجة من شخصٍ لآخر، ولكن هناك مبادئٌ مشتركة يمكن أن يستفيد منها جميع المسافرون. هذه العملية البسيطة التي أوصي بها إن كنت تبدأ بتعلم البرمجة الآن: 1. قم باختيار وجهتك: اختر لغة، أية لغةإن كنت جديًا في موضوع تعلم البرمجة، فلن يُهم كثيرًا أية لغة تختار، حيث تحمل معظم لغات البرمجة الرائجة نفس المفاهيم الأساسية، وعندما تتمكن من البرمجة في اللغة التي تعلمتها في البداية، سيكون من السهل أن تتعلم لغة أخرى بسهولةٍ أكبر. إن كنت تتعلم البرمجة ضمن برنامج جامعي، أو ما شابه، فمن المرجح أن يتم اختيار اللغة بالنيابة عنك. بكل الأحوال، إن لم تكن تعلم تمامًا ماذا تريد القيام به على المدى البعيد، هناك خمسة لغات فقط أنصح بالتفكير بها، وهي تحقّق توازنًا بين سهولة التعلم، تعدد استخدامات المعرفة التي ستكتسبها، والمجال الواسع من فرص العمل على المدى الطويل: Ruby، JavaScript، Python، C و Java. وهذه ملاحظاتٌ عامّة عن كل لغة لتساعدك على الاختيار: اللغات المفسرةمن الأسهل البدء باللغات المفسّرة Interpreted Languages، وهذا لأنه يمكن تنفيذ النص البرمجي بمجرّد أن تتم كتابته، بينما تتطلب اللغات المجمّعة compiled languages، خطوة إضافية بين كتابة وتنفيذ البرنامج. كنتيجة، تسمح اللغات المفسرة ببرمجةٍ أسرع، ولكنها لا تستخدم موارد الحاسوب بالشكل الأمثل، ومن السهولة أن تمر الأخطاء دون الانتباه إليها. فهي مناسبة للتطبيقات التي لا يكون للأداء فيها أولوية. هذه اللغات رائجة في مجال تطوير الويب، حتى أن أحدها، JavaScript، هي اللغة الوحيدة التي يمكن تنفيذها مباشرة من متصفح إنترنت، مما ساهم بانتشارها كأحد أكثر اللغات المُربحة حتى الآن. تستخدم عادة من أجل المساوئ الميزات اللغة تطبيقات الواجهة الخلفية Backend ألق نظرة على Ruby on Rails - قد تؤدي المرونة الزائدة إلى كثير من الغموض حول ما يتم فعليًا - الأداء البطيء يجعلها غير مناسبة للتطبيقات المتقدمة. - قواعد كتابة شديدة المرونة. - سهلة البدء بها. - الطلب العالي عليها يؤمن الكثير من الوظائف. Ruby - تطبيقات الواجهة الأمامية، انظر React,Angular, Ember, jQuery . - تطبيقات الخلفية الخلفية، انظر Node.js . - قواعد الكتابة المعقدة قد تجعلها مُربكة أحيانًا. - تشكل تحدي للمبتدئين أكثر من Ruby و Python. - الخيار الوحيد لتطبيق مُضمّن في المتصفح. - ضرورية لكل موقع حديث. - الطلب العالي جدًا يؤمن وظائف كثيرة بمرتبات JavaScript - تطبيقات الواجهة الخلفية، انظر Django. - البحث العلمي والأكاديمي، انظر . SciPy. - الأداء البطيء يجعلها غير مناسبة للتطبيقات المتقدمة. - قابلية منخفضة للتوّسّع Scalling، تصميم اللغة يجعلها غير مناسبة للبرامج الضخمة. - أنيقة، قواعد الكتابة فيها محبوبة من طرف ممارسيها. - سهل البدء فيها. Python اللغات المجمعة Compiled Languagesبعد أن يتم تجميع النص البرمجي، يتم تحويله من نصٍ برمجي يمكن قراءته من قبل البشر إلى نصٍ أمثل للآلة، قبل أن يتم تنفيذه. وتكون النتيجة أسرع وأكثر فعاليّة من اللغات المفسرة. والمجمّع (compiler) الذي يقوم بذلك، عليه كجزء من وظيفته أن يتأكد من أن كل ما في النص البرمجي "منطقي"، وبالتالي يستطيع أن يتعرف ويمنع أنماطًا عديدة من الأخطاء التي تكون اللغات المفسرة عُرضة لها. ولهذا السبب من الصعب اللوذ بالأخطاء أو البرامج السيئة مع هذه اللغات. كما ستُجبرك على اكتساب فهمٍ أعمق لما يجري فعلًا "تحت الغطاء"، وستتعلم أكثر بكثير عن كيفيّة عمل الحاسوب. والثمن، هو أن هذه اللغات تتطلب الكثير من الجهد، وتشكل تحديًا أكبر للمبتدئين. تستخدم اللغات المجمعة في التطبيقات التي تتطلب أداءًا وموثوقية، ويتضمن ذلك التطبيقات المضمنة، التي تعمل على عتادٍ ذو قدرات محدودة وتطبيقاتٍ ضخمة ومعقدة، حيث يؤدي خطأٌ صغير إلى كوارث ضخمة. تستخدم عادة من أجل المساوئ الميزات اللغة - أنظمة التشغيل. - ألعاب الفيديو المتطورة. - النظم المضمنة. - علم الروبوت والذكاء الصنعي. غالبًا الأكثر صعوبة للتّعلم في هذه القائمة. - بإمكانها توفير أداء أفضل أي من اللغات عالية المُستوى. - أكثر اللغات التي ستعلمك كيفية عمل الحاسوب. C - تطبيقات المشاريع الضخمة. - تطوير الويب. - تطوير تطبيقات الأندرويد. - قواعد الكتابة المعقدة قد تكون مرهقة للقراءة والعمل. - يعتبرها الكثيرون قديمة الطراز، غير مرنة وشعبيتها آخذة بالانخفاض. - بشكل عام، اللغة الأكثر استخدامًا. - صرامة الكتابة تفرض طريقة تفكير واضحة وفعّالة. Java HTML و CSS ليست لغات برمجةيجب الإشارة إلى أن HTML و CSS المستخدمة في كل صفحات الويب التي سبقت لك زيارتها ليست بلغات برمجة. إنما هي لغاتٌ وصفية presentational languages، تستخدم لتحديد كيف يجب أن تبدو الأشياء وماذا يجب أن تتضمن، ولكن لا تحدد كيف يجب أن تتصرف. ولكنها قد تكون مكانًا جيدًا للبدء لأنها سهلة التعلم، وستعلمك كيف تقوم بطباعة الأشياء بشكلٍ صحيح. وإذا كنت تنوي الخوض في مجال تطوير الويب عليك تعلمهما بأي حال من الأحوال. 2. ابدأ بشكل صغيرالتعلم سيأخذ وقتًا، وهنالك الكثير ليتم استيعابه. إذا حاولت بناء تطبيقٍ كامل في يومك الأول، لن تصل إلى نتيجة. كي تجنب نفسك الإحباط، ابدأ بحل مشاكل صغيرة وبسيطة، وتدرّج صعودًا من ذلك. على سبيل المثال، إن أول برنامج يتم كتابته عند تعلم أي لغةٍ جديدة هو برنامج "Hello, World !" (مرحبا بالعالم) والذي يقوم ببساطة بطباعة عبارة "Hello, World !" على الشاشة. وفي معظم لغات البرمجة من المستحيل كتابة برنامجٍ أبسطَ من ذلك. ووضوحًا لا يقدم هذا البرنامج الكثير من الفائدة، ولكنه يستلزم العديد من أساسيات اللغة لكتابته، فهو مثاليٌ لتتعرف على كيفية الكتابة في هذه اللغة. من هنا يمكنك البدء بكتابة برامج تطرح أو تضيف بعض الأرقام، ومن ثم شيئا تطبيقا يقرأ ما يكتبه المستخدم. بعد ذلك يمكنك تعلّم الجمل الشرطية، التي هي طريقة لاتخاذ قرارٍ ما، والحلقات التي تقوم بإعادة تنفيذ مهام معينة. وسرعان ما يصبح بإمكانك كتابة أول كائن Object، ومن هناك تستطيع تجريب بناء تطبيقاتٍ كاملة. 3. كن صبوراقد تشكل المفاهيم الجوهرية للبرمجة تحديًا حقيقيًا. ومعظمها لا يكون بديهيًا إن لم تكن تعلم كيف يعمل الحاسوب بشكلٍ مُعمّق. على سبيل المثال، عندما بدأت بالتعلم وجدت عملية التّنقيح debugging مثيرة للحنق، ولم أشعر أنها برمجة حتى. فعوضًا عن كتابة نصٍ برمجي جديد يقوم بأشياء جديدة ظريفة، كنت أمضي يومًا كاملًا في قراءة نصي البرمجي في محاولة لفهم أين أخطأت هذه المرة. في النهاية أكتشف أنني نسيت أن أضع فاصلةً منقوطة في مكانٍ ما، أو أني استخدمت عدة فراغاتٍ عوضًا عن فراغٍ واحد، وحين يصبح برنامجي جاهزًا للعمل يكون قد انتهى اليوم، وأشعر أني غبيٌ جدًا، وأن ما أقوم به هو إضاعة للوقت. سيحصل هذا الأمر معك، ويدفعك إلى الجنون. ولهذا فإن أحد عوامل النجاح هي أن تكون صبورًا، ولا تقسُ على نفسك. وتوصي بعض أفضل النصائح في هذا الموضوع أن تركز على العملية وليس الأهداف. فإن قمت بالتركيز على الهدف النهائي ("أريد بناء موقع في نهاية الشّهر القادم") سوف تشعر بالإحباط، وبأنك فاشل. بينما من خلال السماح لنفسك أن تأخذ كل الوقت اللازم لتحرزَ تقدمًا، سوف تحقق نجاحًا أكبر. 4. تدرب تدرب تدربومثل أية مهارة، سوف يتحسّن مستواك من خلال التدريب. لا يوجد شيء مماثل للجهد المبذول في شيء في سبيل تعلم القيام به. حتى لو خصصت بضعة ساعات أسبوعيًا، إن استمريت بالتدرب بانتظام، سوف تتمكن، يومًا ما، من كتابة البرامج. في النهاية سوف تكتسب حدسًا للأمور، وسيصبح أمرٌ تطلب منك يومًا كاملًا في البدء (مثل البحث عن خطأ ما)، يأخذ فقط بضع ثواني. حين تشعر أنك تمكنت تقريبًا من أساسيات البرمجة، فإن البدء بمشروعك الأول هو طريقةٌ رائعة للتدريب. فكر بتطبيقٍ بسيط ترغب ببنائه، مثل قائمة مهام، أو برنامج آلة حاسبة (مجددًا، ابدأ بشكل صغير)، وجرب القيام به. سيعلمك ذلك كيف تحل مشاكل هيكلية وتصميمية، وبناء أجزاء مختلفة تعمل معًا بشكل جيد. هذه هي المهارات الأساسية التي ستخولك أن تعتبر نفسك مبرمجًا. المراجعوفقًا لأهدافك، أسلوب التعلم الذي ستختاره وأساليبه قد ترغب باستخدام مصادر مختلفة خلال رحلتك. لمساعدتك على اختيار الأساليب المناسبة لك، هذا ملخص لبعض الأدوات التي تستطيع استخدامها، مُرتبة تقريبًا من التعلم الأكثر هيكلية إلى الأقل هيكلية. التعليم المنظم (ذو هيكلية)هذه هي الفئة التي تقدم مدربين، وظائف، اختبارات، درجات، مواعيد نهائية، وعواقب حقيقية في حال لم تضع دراستك في قمة أولوياتك. هذه الخيارات التي ستُجبرك على الذهاب إلى الدرس أو الرسوب في البرنامج. شهادة جامعة رسميةهي الخيار الأكثر كلفة، ولكن بالنسبة لكثيرين، الخيار الأكثر قيمة، ستقدم لك شهادة جامعية رسمية أفضل أساسٍ لحياة مهنية مزدهرة في البرمجية وتقنية الحاسوب. ستتلقى اعترافًا بإنجازاتك على شكل شهادة (أفضلية كبيرة عند دخول سوق العمل). ولكن الأهم من ذلك هو أنك ستتخرج ولديك فهمٌ عميق لكل ما يتعلق بالحاسوب، وقدراتك على كتابة برمجياتٍ فعّالة ومتطوّرة حقيقة، ستعكس ذلك. هذه الأمور التي ستتعلمها غالبًا بشكلٍ معمّق خلال أي برنامج جامعيّ محترم، والذي قد يصعب العثور عليه في أي مكان آخر للتدريب. الدارات الكهربائية – الأساس الفيزيائي لتقريبًا كل عتاديات الحاسوب.الدارات المنطقية الرقمية – كيف يمكن تمثيل الحقيقة والبنى المنطقية باستخدام الدارات.المعالجات الصغرية والأنظمة الحاسوبية – كيف تتحول الدارات المنطقية عند جمعها إلى آلة حاسوبية قابلة للبرمجة. وماذا يحصل على كل تلك الرؤوس المعدنية الصغيرة والأسلاك المطبوعة.أنظمة التشغيل – كيف تبرمج حاسوبًا ليدير، ينظم، يحمي نفسه ويمكّن أكثر من تطبيق من العمل جنبا إلى جنب بشكل آمن.قواعد البيانات – كيف تخزّن وتنسخ كميات كبيرة من البيانات دون خسارتها، إضرارها، أو جعل الوصول إليها مستحيلا.الشبكات – كيف تقوم حواسيب مختلفة وغير مرتبطة بالتحدث مع بعضها البعض.رياضيات متقدمة – متضمنةً الحساب والجبر الخطي. الأمر الأساسي لأي مهنة في المجالات المتطورة والمتقدمة.معالجة الإشارة – كيف تتخطى الحدود بين العالم التماثلي والعالم الرقمي وبالعكس.الأساليب العددية – عندما لا تتوافق مشاكل العالم الحقيقي كليًا مع الحاسوب.سوف ترهقك كلية الهندسة وعلوم الحاسوب، وعليك أن تضحي وتتفانى كي تكملها. ولكن الجائزة تستحق ذلك. جاهدتُ كثيرًا للحصول على شهادتي، ولكن ما يزال يوم قمت بتلقّي شهادتي أحد أكثر الأيام فخرًا في حياتي. الورشات المكثفة Bootcampsظهر مؤخرًا ما يدعى بـ "الورشات المكثفة" لتلبية حاجات أولئك الذين لا يملكون الوقت أو الموارد للحصول على شهادات جامعية، ولكنهم مستعدون للعمل بجدّ والحصول على الحد الأدنى للبدء بحياة مهنية في تطوير البرمجيات. ومن حيث الكلفة والالتزام المطلوب، تقع الورشات المكثفة بين الشهادة الجامعية وخيارات التعليم الذاتي التي سنتحدث عنها بعد قليل. تمتد هذه الورشات بين 8-12 أسابيع من الدراسة المكثّفة وتكلّف حوالي 10،000 US$. يتم تغطية كمية كبيرة من المواد خلال وقت قصير، ستُضطر خلاله بالتضحية بكل التزاماتك الأخرى. ولكنها تعدك بتحضيرك لتصبح قادرًا على تطوير برمجيات بما يناسب العالم الحقيقي، ووضعك على طريق سريع لحياة مهنية في البرمجة. معظم الورشات تحاول تأمين وظيفة لك فور تخرجّك. وهي ظاهرة حديثة. بالتالي من الصعب قياس معدل نجاحهم، وما زال على العديد منهم تطوير سجلٍ مُثبت لتأمين وظائف لخرّيجيهم. وبعد قول ذلك، لا يمكن أن نتوقع إلا أن تتحسن البرامج المتوافرة حاليًا في ظل نمو هذه الظاهرة. طالما تقوم بالبحث بحذر، قد تجد أن هذا الخيار مثاليٌّ بالنسبة لك. معظم الورشات المكثفة هي برامجٌ محليّة، فعليك البحث عن ما هو متوافرٌ في منطقتك. التعلم شبه المهيكلتتزايد المصادر المتوافرة يوميًا لأولئك الذين يعملون بالشكل الأفضل مع عنصر من التنظيم، والإرشاد، ولكن لا يملكون الوقت أو الموارد للالتزام في برنامج جامعيّ، أو ورشة مكثّفة. تتوافر هذه الخيارات عادة كليًا على الإنترنت، والعديد منها هو مجانيٌّ بشكلٍ كامل. ونظرًا لتزايد الطلب على هذه الخدمات، فقد تطورت هذه الأدوات بشكل كبير من حيث التعقيد والقيمة المُقدمة. قادت معظم هذا التطور طبعًا مساقاتٍ MOOCs في تطوير البرمجيات، حيث يقدم تعلّم وتعليم البرمجيات من خلال برمجيات فوائدَ واضحة. مساقات على الإنترنت مفتوحة وضخمة MOOCsإن هذه المساقات هي مصادرٌ هائلة، وتقدم خطواتٍ كبيرة في مجال المساواة وكلفة التعليم. فهي تقدم معظم هيكلية وإرشاد صفوف أعرق جامعات العالم، بشكل مفتوح، في أي مكان، لأي شخص يملك اتصالًا بالإنترنت. والعديد من هذه المساقات مجانيٌّ كليًا، بالرغم من أنه مع مبلغٍ إضافي (وتعهد بالدراسة)، يمكن الحصول على شهادة مُكتسبة للعديد من الصفوف، بشكل مكافئ لشهادة الجامعة. هناك العديد من منصات متوافرة على الإنترنت مع مساقاتٍ يقوم بتدريسها أساتذة من أعرق جامعات العالم، ومنصات اجتماعية بحيث تقوم أنت وزملاؤك حول العالم بمساعدة بعضكم البعض على التعلم. هذه بعض أفضل المصادر: CourseraEdXUdacityيجب أن تعلم، أن هذه المساقات تجري متابعة مكافئة لتلك التي تجدها في الجامعة، لذا كن مستعدًا للعمل بجد لاجتيازها. مواقع تعليمية مرشدةإن كنت تحب الهيكلة والإرشاد ولكنك لا تحبذ المواعيد النهائية، هنالك العديد من المنصات التي تقدم تدريب "خطوة بخطوة" مؤتمت، باستخدام عدة طرق للإيصال. بعضها يستخدم الفيديوهات التعليمية، وأخرى النصوص. يتضمن العديد منها محررات تفاعلية للنصوص البرمجية كي تتدرب ضمن متصفحك. تعطيك هذه مرونة للعمل وفق السرعة التي تختارها، سواءٌ كان ذلك بمعدل نصف ساعة يوميًا، أو عشر ساعات في عطلة نهاية الأسبوع. في حين تطلب العديد من هذه المنصات رسمًا اشتراكيًا للوصول إلى محتواها، تقدم معظمها فترةً تجريبية بحيث يمكن البدء بها فورًا، وتقرر بعد ذلك إن كانت تناسبك أم لا. Kahn AcademyUdemyCodecademyCode AvengersCode SchoolTreehouseLyndaPluralsightهذه قائمة قصيرة فقط، أجر بعض البحث واستكشف ماذا يوجد هنالك أيضًا. التعليم غير المهيكللأولئك الذين يرغبون بالبحث عن طريقهم الخاص، أو تطوير معرفتهم في أوقات فراغهم، دون ضغط الدروس المُهيكلة، تقدم الأدوات التالية مقاربة ذاتية التوجيه. وحتى لو قمت باعتماد أحد المقاربات السابقة، ستجد العديد من هذه المصادر مساعد في تقوية عملية التعلم الخاصة بك، أو منصّة لتتدرب من خلالها. مواقع للتدريبإذا كان هدفك فقط هو حل مشاكل برمجية، فإن الإنترنت ستقدم لك ذلك. تقدم المواقع التالية مجموعات متزايدة باستمرار من تحديات البرمجة، إلى جانب واجهة تفاعلية لكتابة النصوص البرمجية، لحل المشاكل، لتقييم حلولك بشكل آني، وكيف تبدو مقارنةً مع حلول مستخدمين آخرين. Exercism.ioCheckiOCodeChefCodeEvalCodewarsCodilityHackerRankالفيديوهاتأظن أنه من غير العملي تعلم البرمجة بشكل خامل/غير تطبيقي، ولكن إن أردت استيعاب بعض المفاهيم العميقة، بين الاجتماعات ربما، فإن سلاسل المحاضرات هذه هي من أفضل الموجود. إن كنت تحب مثل هذه الأمور ابحث عن مصادر أخرى مشابهة على YouTube والويب. MIT OpenCourseWareStanford University Lecture Seriesالكتبحتى مع كل الروائع التي تقدمها التكنولوجيا، مازال البعض يفضل الاستغراق في قراءة كتاب للوصول إلى فهم أعمق للموضوع. إن كنت تحب التعلم بهذه الطريقة، فهناك الكثير من الكُتب المجّانية المتوفرة على الإنترنت مثل هذه القائمة List of Free Learning Resources. في الختام تعلم البرمجة هو رحلة شخصية جدًا، يبدأ الجميع من مصادر وأهداف مختلفة، ويواجهون تحديات وفرص مختلفة كذلك خلال الطريق. لا تقلق حول ما يقوم به الآخرون أو كيف وصلوا إليه. حتى بالنسبة لبعض المبرمجين ذوي الخبرة، فإن هذه الرحلة لا تنتهي حقًا، فهنالك دائمًا أشياء جديدة يمكن تعلّمها. ترجمة -وبتصرف- للمقال: Learn To Code: Tips and Tools لصاحبه: Nick McCrea. حقوق الصورة البارزة: Designed by Freepik.
  17. كما هو موضح في العنوان فإنّك في هذا الدرس سوف تتعلم كيفية إنشاء تأثير وكأنّك تتصفح كتابًا ما. وسوف نستخدم في هذا الدرس إضافة تدعى BookBlock، والفكرة من هذا الدرس هو أنّك سوف تقوم بإنشاء تأثير يُمكّن الزوار من تصفح موقع ما وكأنهم يتصفحون أحد الكتب. الفكرة هي أنّك سوف تتصفح صفحات الموقع باستخدام سهمين سوف يكونان موجودين في أعلى الصفحة أو أزرار لوحة المفاتيح أو حتى بالسحب باستخدام الفأرة وأيضًا سيكون هناك قائمة جانبية سوف تظهر عندما تقوم بالضغط على أيقونة ما. وسوف تحتوي القائمة الجانبية على روابط لصفحات الموقع وعندما تقوم بالضغط على أحد هذه الروابط فإنّها سوف تنقلك إلى الصفحة المطلوبة. سوف نستخدم أيضًا إضافة اسمها jScrollPane وذلك للحصول على شريط تمرير (scrollbar) يظهر عندما يكون المحتوى أطول من ارتفاع المتصفح. وهذه قائمة بإضافات jQuery التي سوف نستخدمها: BookBlockCustom jQuery++jScrollPanejQuery Mouse Wheel PluginCustom Mdernizerيمكنك معاينة المثال الموضح في هذا الدرس من هنا. كما يمكنك تحميل الملفات المصدرية. بنية ملف HTMLفي البداية يجب أن يكون لدينا حاوٍ رئيسي لاحتواء جميع العناصر، وداخل هذا الحاوي سوف يكون هناك عنصر <div> للقائمة الجانبية وسوف نعطيه فئة (class) بالاسم "menu-panel" وسوف يكون هناك عنصر <div> آخر يحتوي على المحتوى الرئيسي للموقع وسوف نعطيه فئة بالاسم "bb-custom-wrapper". وفي داخل كل قسم سوف يكون هناك حاوٍ للمحتوى وعنصر <div> سوف نحتاجه من أجل شريط التمرير الذي ذكرناه سابقًا. <div id="container" class="container"> <div class="menu-panel"> <h3>Table of Contents</h3> <ul id="menu-toc" class="menu-toc"> <li class="menu-toc-current"><a href="#item1">Self-destruction</a></li> <li><a href="#item2">Why we die</a></li> <li><a href="#item3">The honeymoon</a></li> <li><a href="#item4">A drawing joke</a></li> <li><a href="#item5">Commencing practice</a></li> </ul> </div> <div class="bb-custom-wrapper"> <div id="bb-bookblock" class="bb-bookblock"> <div class="bb-item" id="item1"> <div class="content"> <div class="scroller"> <h2>Self-destruction</h2> <p>...</p> </div> </div><!-- /content --> </div><!-- /bb-item --> <div class="bb-item" id="item2"><!-- ... --></div> <div class="bb-item" id="item3"><!-- ... --></div> <div class="bb-item" id="item4"><!-- ... --></div> <div class="bb-item" id="item5"><!-- ... --></div> </div><!-- /bb-bookblock --> <nav> <a id="bb-nav-prev" href="#">←</a> <a id="bb-nav-next" href="#">→</a> </nav> <span id="tblcontents" class="menu-button">Table of Contents</span> </div><!-- /bb-custom-wrapper --> </div><!-- /container -->سوف نقوم بربط عناصر القائمة الجانبية بصفحات الموقع (التي تحمل الفئة "bb-item)، وسوف نُضيف أيضًا سهمين في أعلى الصفحة من أجل التنقل بين الصفحات وزر يقوم بفتح وإغلاق القائمة الجانبية. لنقم الآن بإضافة تنسيقات CSS. تنسيقات CSSلن نتحدث هنا عن التنسيقات التي تأتي مع إضافة BookBlock لأنك سوف تجدها داخل ملف bookblock.css، وإنّما سوف نُركّز على التنسيقات الأخرى المهمة. لنبدأ التنسيقات بإضافة سطر يقوم بجلب الخط المسمى "Lato" من خدمة Google web fonts: @import url(http://fonts.googleapis.com/css?family=Lato:300,400,700);سوف نقوم بإعطاء الوسم <html> الخاصية height: 100% وذلك لأننا سوف نحتاج أن نجعل بعض العناصر تتمدد على ارتفاع المتصفح كاملًا: html { height: 100%; }سوف نستخدم أيضًا الخاصية box-sizing: border-box وذلك حتى نستخدم قيم مئوية لكل من العرض والإرتفاع أثناء استخدام padding دون القلق حول أبعاد العناصر والقيام بعمليات حسابية نحن بغنىً عنها: *, *:after, *:before { -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; padding: 0; margin: 0; }لنقم الآن بتعريف الخط الذي سوف نستخدمه في الموقع (العنصر body) ونُعطيه ارتفاع بقيمة 100% (تذكّر أننا نريد ارتفاع بهذه القيمة لأنه سوف يكون هناك عناصر تتموضع بشكل مطلق (absolute positioning) وسوف تحتاج أن تتمدد على ارتفاع المتصفح كاملًا): body { font-family: 'Lato', Calibri, Arial, sans-serif; font-weight: 400; font-size: 100%; color: #333; height: 100%; }سوف نستعمل أيضًا إضافة Modernizr وسوف نُضيف الفئة "no-js" إلى وسم <html>، فإذا كانت الجافاسكربت مفعّلة فإنّ Modernizr سوف يستبدل تلك الفئة بالفئة "js". وهذا سوف يساعدنا على إعطاء خصائص CSS معينة لبعض العناصر التي لا نريدها إذا كانت الجافاسكربت معطّلة. لاحظ أيضًا أننا نحتاج أن يكون عرض الصفحة وارتفاعها بقيمة 100% فقط إذا كانت الجافاسكربت مفعّلة وعندها فقط نريد من العنصر body أن يكون له خاصية overflow: hidden: .js body { overflow: hidden; }وهذه بعض التنسيقات الخاصة بالروابط: a { color: #555; text-decoration: none; } a:hover { color: #000; }نريد من الحاوي الرئيسي أن يكون بعرض وارتفاع المتصفح كاملًا، وسوف نقوم بموضعة القائمة الجانبية خارج هذا الحاوي باستعمال الخاصية left وإعطائها قيمة سالبة تكون بنفس قيمة العرض الخاص بالقائمة الجانبية. والفكرة هي أنّه عند النقر على أيقونة القائمة الجانبية فإنّ الحاوي سوف يتحرك إلى اليمين مما يؤدي إلى ظهور القائمة الجانبية. دعونا إذًا نقوم بإعطاء الحاوي الرئيسي عرضًا وارتفاعًا بقيمة 100% وأن نُضيف الخاصية transition إلى الحاوي container: .container, .bb-custom-wrapper, .bb-bookblock { width: 100%; height: 100%; } .container { position: relative; left: 0px; transition: left 0.3s ease-in-out; }عند النقر على أيقونة القائمة الجانبية فإن فئة (class) أخرى سوف يتم إضافتها إلى الحاوي container والتي سوف تحتوي على الخاصية left: 240px (نفس العرض الخاص بالقائمة الجانبية) وبالتالي فإنّ الصفحة كاملة سوف تتحرك إلى اليمين بمقدار 240px وبالتالي ظهور القائمة الجانبية: .slideRight { left: 240px; }ولكن بدون الجافاسكربت لن نكون قادرين على القيام بما سبق لذلك سوف نقوم بإضافة الخاصية padding-left: 240px: .no-js .container { padding-left: 240px; }ونريد أن تكون القائمة الجانبية ثابتة في الجانب الأيسر بشكل افتراضي: .menu-panel { background: #f1103a; width: 240px; height: 100%; position: fixed; z-index: 1000; top: 0; left: 0; text-shadow: 0 1px 1px rgba(0,0,0,0.1); }وإذا كانت الجافاسكربت مفعلة فسوف نقوم بموضعة القائمة الجانبية بشكل مطلق وإلى اليسار بقيمة -240px: .js .menu-panel { position: absolute; left: -240px; }وهذه هي التنسيقات الخاصة بعناصر القائمة الجانبية: .menu-panel h3 { font-size: 1.8em; padding: 20px; font-weight: 300; color: #fff; box-shadow: inset 0 -1px 0 rgba(0,0,0,0.05); } .menu-toc { list-style: none; } .menu-toc li a { display: block; color: #fff; font-size: 1.1em; line-height: 3.5; padding: 0 20px; cursor: pointer; background: #f1103a; border-bottom: 1px solid #dd1338; } .menu-toc li a:hover, .menu-toc li.menu-toc-current a{ background: #dd1338; }وأمّا بالنسبة للقائمة الرئيسية التي سوف تحتوي على السهمين فإننا سوف نقوم بموضعتها بشكل مطلق وفوق جميع العناصر الأخرى: .bb-custom-wrapper nav { top: 20px; left: 60px; position: absolute; z-index: 1000; }كما أنّ روابط السهمين وزر القائمة الجانبية سوف يتموضعان بشكل مطلق (position: absolute) وسوف نعطيها الخاصية border-radius: 50% لنجعلها تظهر كالدائرة: .bb-custom-wrapper nav span, .menu-button { position: absolute; width: 32px; height: 32px; top: 0; left: 0; background: #f1103a; border-radius: 50%; color: #fff; line-height: 30px; text-align: center; speak: none; font-weight: bold; cursor: pointer; } .bb-custom-wrapper nav span:last-child { left: 40px; } .bb-custom-wrapper nav span:hover, .menu-button:hover { background: #000; }سوف يكون الزر الذي يفتح ويغلق القائمة الجانبية موجودًا في أعلى يسار الصفحة وسوف نقوم بإخفاء النص الموجود بداخله (نريد أن تظهر الأيقونة فقط): .menu-button { z-index: 1000; left: 20px; top: 20px; text-indent: -9000px; }لنقم الآن بإنشاء أيقونة بسيطة بدون استعمال أي صور وذلك باستعمال العنصر الزائف :after واستعمال الخاصية box-shadow والتي سوف تعمل على إنشاء الخطين العلوي والسفلي للأيقونة: .menu-button:after { position: absolute; content: ''; width: 50%; height: 2px; background: #fff; top: 50%; margin-top: -1px; left: 25%; box-shadow: 0 -4px #fff, 0 4px #fff; }وفي حالة كان الجافاسكربت معطلًا فإننا نريد أن نخفي هذه العناصر: .no-js .bb-custom-wrapper nav span, .no-js .menu-button { display: none; }لننتقل الآن إلى تنسيق الأجزاء الداخلية لكل قسم من أقسام الصفحة (bb-item). نريد أن يتم موضعة المحتوى (content) بشكل مطلق ونريد ان نستعمل الخاصية overflow: hidden، وهذا مهم لأننا نريد تطبيق شريط التمرير هنا ونريد أن نفعل ذلك فقط عند قلب/تغيير الصفحة. فإذا لم نستخدم الخاصية overflow: hidden فإنّك سوف ترى المحتوى يتداخل ببعضه. وأعيد وأكرر مرة أخرى بأنّ هذا سوف يحدث فقط إذا كان الجافاسكربت مفعلًا ولذلك سوف نستخدم الفئة "js": .js .content { position: absolute; top: 60px; left: 0; bottom: 50px; width: 100%; overflow: hidden; }العنصر <div class="scroller"> هو الذي سوف ينمو مع المحتوى لذلك سوف نعطيه الخاصية padding: .scroller { padding: 10px 5% 10px 5%; }لاحظ أننا استعملنا قيم مئوية للجوانب وذلك حتى نجعل الصفحة تتجاوب مع حجم الشاشة. دعونا نتخلص من الحواف الحادة عندما نقوم بالتمرير (scroll) وذلك باستخدام العناصر الزائفة إلى أعلى وأسفل عنصر المحتوى مع استخدام تدرج بين اللون الأبيض والشّفّاف: .js .content:before, .js .content:after { content: ''; position: absolute; top: 0; left: 0; width: 100%; height: 20px; z-index: 100; pointer-events: none; background: linear-gradient( to bottom, rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100% ); } .js .content:after { top: auto; bottom: 0; background: linear-gradient( to top, rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100% ); }هذا سوف يجعل النص يظهر بشكل باهت. لنقم الآن بتنسيق عناصر النصوص: .content h2 { font-weight: 300; font-size: 4em; padding: 0 0 10px; color: #333; margin: 0 1% 40px; text-align: left; box-shadow: 0 10px 0 rgba(0,0,0,0.02); text-shadow: 0 0 2px #fff; } .no-js .content h2 { padding: 40px 1% 20px; } .content p { font-size: 1.2em; line-height: 1.6; font-weight: 300; padding: 5px 8%; text-align: justify; }كل ما تبقى علينا الآن من تنسيقات CSS هو استخدام الـmedia queries. فإذا كانت الجافاسكربت معطلة فإننا لا نريد أن تظهر القائمة الجانبية إذا كان العرض أقل من 800px. كان هذا فقط مثالًا بسيطًا على كيفية التحكم بالعناصر تحت ظروف وشروط معينة. الـmedia query الأخيرة سوف تعمل على تكبير الخط قليلًا من أجل الأجهزة صغيرة الحجم كالهواتف. @media screen and (max-width: 800px){ .no-js .menu-panel { display: none; } .no-js .container { padding: 0; } } @media screen and (max-width: 400px){ .menu-panel, .content { font-size: 75%; } }كان هذا كل ما يتعلق بتنسيقات CSS ويتبقى علينا استخدام بعض الجافاسكربت. بعض الجافاسكربتسوف نبدأ اولًا بتخزين (caching) بعض العناصر حتى لا نضطر إلى استدعائها في كل مرة وسوف نقوم أيضًا بتهئية/مناداة إضافة BookBlock. نُريد أيضًا أن نقوم بضبط بعض الأمور بعد كل قلب/تغيير للصفحة وهذه الأمور هي رقم الصفحة الحالية والسلوك الخاص بإضافة jScrollPane. وهذا محدد في الاستدعاء الخلفي (callback) المسمى onEndFlip والممرر إلى إضافة BookBlock. var $container = $( '#container' ), // the element we will apply the BookBlock plugin to $bookBlock = $( '#bb-bookblock' ), // the BookBlock items (bb-item) $items = $bookBlock.children(), // index of the current item current = 0, // initialize the BookBlock bb = $( '#bb-bookblock' ).bookblock( { speed : 800, perspective : 2000, shadowSides : 0.8, shadowFlip : 0.4, // after each flip... onEndFlip : function(old, page, isLimit) { // update the current value current = page; // update the selected item of the table of contents (TOC) updateTOC(); // show and/or hide the navigation arrows updateNavigation( isLimit ); // initialize the jScrollPane on the content div for the new item setJSP( 'init' ); // destroy jScrollPane on the content div for the old item setJSP( 'destroy', old ); } } ), // the navigation arrows $navNext = $( '#bb-nav-next' ), $navPrev = $( '#bb-nav-prev' ).hide(), // the table of content items $menuItems = $container.find( 'ul.menu-toc > li' ), // button to open the TOC $tblcontents = $( '#tblcontents' ), transEndEventNames = { 'WebkitTransition': 'webkitTransitionEnd', 'MozTransition': 'transitionend', 'OTransition': 'oTransitionEnd', 'msTransition': 'MSTransitionEnd', 'transition': 'transitionend' }, // transition event name transEndEventName = transEndEventNames[Modernizr.prefixed('transition')], // check if transitions are supported supportTransitions = Modernizr.csstransitions;لنقم أولًا بربط الأحداث ببعض العناصر التي تم تهيئتها سابقًا، كما أننا نريد أن نقوم بتهيئة jScrollPane لأول عنصر (العنصر الحالي). function init() { // initialize jScrollPane on the content div of the first item setJSP( 'init' ); initEvents(); }بما أننا سوف نقوم بتهيئة وإعادة تهيئة وتدمير jScrollPane فلنقم بتعريف دالة لذلك: function setJSP( action, idx ) { var idx = idx === undefined ? current : idx, $content = $items.eq( idx ).children( 'div.content' ), apiJSP = $content.data( 'jsp' ); if( action === 'init' && apiJSP === undefined ) { $content.jScrollPane({verticalGutter : 0, hideFocus : true }); } else if( action === 'reinit' && apiJSP !== undefined ) { apiJSP.reinitialise(); } else if( action === 'destroy' && apiJSP !== undefined ) { apiJSP.destroy(); } }سوف نحتاج إلى ربط العديد من الأحداث كالتالي: سوف يتم استدعاء الدالتين ()next و()prev الخاصتين بإضافة BookBlock وذلك عند النقر على أزرار التنقل أو السحب باستخدام الفأرة.سوف يظهر جدول المحتويات أو يختفي عند النقر على زر القائمة (tblcontents$).سوف يتم استدعاء الدالة ()jump الخاصة بإضافة BookBlock وذلك عند النقر على أي عنصر من عناصر جدول المحتويات.سوف يتم تهيئة jScrollPane عند القيام بتغيير حجم النافذة (window resize).function initEvents() { // add navigation events $navNext.on( 'click', function() { bb.next(); return false; } ); $navPrev.on( 'click', function() { bb.prev(); return false; } ); // add swipe events $items.on( { 'swipeleft' : function( event ) { if( $container.data( 'opened' ) ) { return false; } bb.next(); return false; }, 'swiperight' : function( event ) { if( $container.data( 'opened' ) ) { return false; } bb.prev(); return false; } } ); // show TOC $tblcontents.on( 'click', toggleTOC ); // click a menu item $menuItems.on( 'click', function() { var $el = $( this ), idx = $el.index(), jump = function() { bb.jump( idx + 1 ); }; current !== idx ? closeTOC( jump ) : closeTOC(); return false; } ); // reinit jScrollPane on window resize $( window ).on( 'debouncedresize', function() { // reinitialise jScrollPane on the content div setJSP( 'reinit' ); } ); } ظهور أزرار التنقل من عدمه سوف يعتمد على الصفحة الحالية، فإذا كُنّا في الصفحة الأولى فإننا سوف نرى فقط زر "التالي" وإذا كُنّا في الصفحة الأخيرة فإننا سوف نرى فقط زر "السابق": function updateNavigation( isLastPage ) { if( current === 0 ) { $navNext.show(); $navPrev.hide(); } else if( isLastPage ) { $navNext.hide(); $navPrev.show(); } else { $navNext.show(); $navPrev.show(); } }عندما نفتح جدول المحتويات (القائمة الجانبية) فإننا نريد أن تختفي عناصر التنقل وأن تظهر مرة أخرى عندما نقوم بإغلاق القائمة الجانبية. سوف نقوم بتحريك القائمة الجانبية باستخدام خاصية transition، وإذا لم تكن هذه الخاصية مدعومة من المتصفح فإننا سوف نستخدم fallback بسيط: function toggleTOC() { var opened = $container.data( 'opened' ); opened ? closeTOC() : openTOC(); } function openTOC() { $navNext.hide(); $navPrev.hide(); $container.addClass( 'slideRight' ).data( 'opened', true ); } function closeTOC( callback ) { $navNext.show(); $navPrev.show(); $container.removeClass( 'slideRight' ).data( 'opened', false ); if( callback ) { if( supportTransitions ) { $container.on( transEndEventName, function() { $( this ).off( transEndEventName ); callback.call(); } ); } else { callback.call(); } } } خاتمةهذا كان كل شيء يخص هذا الدرس أتمنى أن يكون قد أعجبك وأن تكون قد وجدته مفيدًا. ترجمة -وبتصرّف- للدرس Fullscreen Pageflip Layout لصاحبته Mary Lou.
  18. إنّ التخزين المؤقّت Caching للمحتوى بشكل ذكي هو واحد من أكثر الطرق فعاليّة لتحسين التجربة لزوّار أي موقع. إنّ التخزين المؤقّت Caching، أو تخزين المحتوى بشكل مؤقّت من الطلبات السّابقة، هو جزء من لُب استراتيجيّة توصيل المحتوى المُنفَّذة ضمن ميفاق HTTP protocol، تستطيع المُكوِّنات عبر مسار توصيل المحتوى أن تقوم بالتخزين المؤقّت للعناصر لتسريع الطلبات اللاحقة، والتي تكون خاضعة لسياسات التخزين المؤقّت المُصرَّح عنها بالنسبة للمحتوى. سنناقش في هذا الدّرس بعض المفاهيم الأساسيّة للتخزين المؤقّت لمحتوى الويب، وسنتحدّث عن الفوائد التي يتيح لنا التخزين المؤقّت الحصول عليها والأماكن التي يتم فيها هذا التخزين. ما هو التخزين المؤقت Caching؟التخزين المؤقّت Caching هو مصطلح يُعبِّر عن تخزين الاستجابات القابلة لإعادة استخدامها لجعل الطلبات اللاحقة تتم بشكل أسرع، تُوجد العديد من الأنواع المختلفة المُتاحة للتخزين المؤقّت، وكل منها له خصائصه الفريدة، فالتخزين المؤقّت للتطبيقات والتخزين المؤقّت للذاكرة شائعان لقدرتهما على تسريع بعض الاستجابات. إنّ التخزين المؤقّت للويب Web Caching -وهو محور درسنا هذا- هو نوع مختلف من التخزين المؤقّت، وهو ميزة التصميم الأساسيّة في ميفاق HTTP protocol والتي تهدف لتصغير حركة مرور البيانات عبر الشبكة network traffic مع تحسين الاستجابة التي يتلقّاها النظام ككل، تُوجد التخزينات المؤقّتة Caches في كل مستوى من مستويات رحلتنا مع المحتوى، ابتداءً من الخادوم الأصلي وحتى المتصفّح. يعمل التخزين المؤقّت للويب عن طريق التخزين المؤقّت لاستجابات HTTP للطلبات وفق قواعد معيّنة، ويتم بعدها تلبية الطلبات اللاحقة للمحتوى المُخزّن بشكل مؤقّت من التخزين المؤقّت القريب من المستخدم بدلًا من إعادة إرسال الطلبات إلى خادوم الويب. الفوائديُساعد التخزين المؤقّت الفعّال مستهلكي المحتوى ومزوّدي المحتوى، ومن الفوائد التي يقدّمها لتوصيل المحتوى نجد: تقليل تكاليف الشبكة: يُمكن التخزين المؤقّت للمحتوى في عدّة نقاط على مسار الشبكة بين مُستهلِك المحتوى ومصدر المحتوى، وعندما يتم تخزين المحتوى بشكل مؤقّت في مكان أقرب للمستهلك فلن تُحدِث الطلبات نشاطًا إضافيًّا للشبكة ما وراء نقطة التخزين المؤقّت.تحسين الاستجابة: يُمكِّننا التخزين المؤقّت من استرجاع المحتوى بشكل أسرع لأنّه ليس من الضروري القيام بدورة كاملة عبر الشبكة من أجل استرجاعه، يستطيع التخزين المؤقّت القريب من المستخدم، مثل التخزين المؤقّت للمتصفّح browser cache، أن يجعل هذا الاسترجاع للمحتوى لحظيًّا.تحسين الأداء على نفس العتاد: بالنسبة للخادوم الذي هو منشأ المحتوى فبإمكاننا الحصول على المزيد من الأداء من نفس العتاد عن طريق السماح بالتخزين المؤقّت العنيف aggressive caching، فيتمكّن مالك المحتوى من الاستفادة من الخواديم القويّة على مسار التوصيل لتتحمّل شدّة بعض تحميلات المحتوى.توافر المحتوى أثناء انقطاعات الشبكة: يُمكِن استخدام التخزين المؤقّت ضمن سياسات مُحدّدة لتخديم المحتوى للمستخدمين النهائيين عندما لا يكون هذا المحتوى متوفّرًا لفترة قصيرة من الوقت من الخواديم الأصل.مصطلحاتقد نصادف عند التعامل مع التخزين المؤقّت بعض المصطلحات غير المألوفة، ومن أشيعها ما يلي: الخادوم الأصل Origin server: إنّ الخادوم الأصل هو المكان الأصلي للمحتوى، فإن كنت تلعب دور مُدير خادوم الويب فهو الجهاز الذي تتحكّم به، وهو مسؤول عن تخديم أي محتوى لم نتمكّن من استرجاعه من التخزين المؤقّت على طول مسار الطلب، وإعداد سياسة التخزين المؤقّت لكافّة المحتويات.نسبة استخدام التخزين المؤقّت Cache hit ratio: تُقاس فعاليّة التخزين المؤقّت وفق نسبة استخدام التخزين المؤقّت cache hit ratio أو معدل الاستخدام hit rate، وهي نسبة الطلبات التي يُمكن استرجاعها من التخزين المؤقّت على العدد الكلّي للطلبات، وعندما تكون مرتفعة تدل على أنّنا استطعنا استرجاع نسبة عالية من الطلبات من التخزين المؤقّت، وهو عادةً النتيجة المرجوّة لمعظم مُديري النُظُم.الحداثة Freshness: وهو مصطلح يُستخدم ليصف إذا ما كان العنصر في التخزين المؤقّت لا يزال يُعد مُرشَّحًا لتخديمه إلى العميل، يُستخدَم المحتوى الموجود في التخزين المؤقّت كاستجابة فقط إذا كان ضمن الإطار الزمني للحداثة freshness المُحدَّد من قبل سياسة التخزين المؤقّت.المحتوى القديم Stale content: تنتهي صلاحيّة العناصر الموجودة في التخزين المؤقّت وفق إعدادات freshness المُحدَّدة من قبل سياسته الخاصة، يُوصف المحتوى مُنتهي الصلاحيّة بأنّه قديم "stale"، وبشكل عام لا يُمكن استخدام هذا المحتوى للإجابة على طلبات العملاء، ويجب هنا إعادة الاتصال مع الخادوم الأصل لاسترجاع المحتوى الجديد أو للتحقّق على الأقل من أنّ المحتوى المُخزَّن مؤقّتًا لا يزال دقيقًا.التحقّق Validation: يُمكِن التحقّق من العناصر الموجودة في التخزين المؤقّت من أجل تحديث مُدّة صلاحيتها، ويتضمّن هذا التواصل مع الخادوم الأصل لنعرف إذا ما كان المحتوى المُخزَّن مؤقّتًا لا يزال يُمثِّل أحدث إصدار من هذه العناصر.الإبطال Invalidation: الإبطال هو عمليّة إزالة المحتوى من التخزين المؤقّت قبل الوقت المُحدّد لانتهاء صلاحيّته، وهو ضروري إن تمّ تغيير المحتوى على الخادوم الأصل، فامتلاك محتوى قديم في التخزين المؤقّت سيسبب مشاكل هامّة للعميل.يُوجد المزيد من مصطلحات التخزين المؤقّت، ولكن ينبغي أن تُساعدك المصطلحات السّابقة في البدء. ما هو المحتوى الذي يمكن تخزينه بشكل مؤقت؟يجعل بعض المحتوى من نفسه أكثر سهولة للتخزين المؤقّت من محتوى آخر، فمن المحتوى القابل بشدّة للتخزين المؤقّت لمعظم المواقع نجد: صور الشعارات والعلامات التجاريّةالصور غير المتناوبة Non-rotating images (مثل أيقونات التصفّح navigation)ملفّات التنسيق Style sheetsملفّات Javascript العامّةالمحتوى القابل للتنزيلملفّات الوسائط Media Filesتميل هذه المحتويات إلى عدم تغيّرها بشكل متكرّر، لذا نستفيد من تخزينها بشكل مؤقّت لفترات طويلة. ومن بعض العناصر التي يجب أن نحذر عند تخزينها بشكل مؤقّت نجد: صفحات HTMLالصور المتناوبة Rotating imagesملفّات CSS و Javascript المُعدَّلة بشكل متكرّرالمحتوى الذي يتم طلبه من خلال كعكات الاستيثاق authentication cookiesومن العناصر التي لا ينبغي إطلاقًا تخزينها بشكل مؤقّت تقريبًا: البيانات الحسّاسة (معلومات البنك، إلخ ..)المحتوى المرتبط بالمستخدم والمتغيّر بشكل متكرّروبالإضافة للقواعد العامّة السّابقة من الممكن تحديد سياسات تسمح لنا بالتخزين المؤقّت لأنواع مختلفة من المحتوى بشكل مناسب، على سبيل المثال إن كانت تظهر نفس شاشة العرض من موقعنا للمستخدمين الذين قاموا بالاستيثاق فمن الممكن التخزين المؤقّت لها في أي مكان، وإن كانت تظهر شاشة تعرض معلومات حسّاسة عن المستخدم في موقعنا فمن الممكن أن تكون صالحة للتخزين المؤقّت لبعض الوقت، وربّما نخبر متصفّح المستخدم أن يقوم بالتخزين المؤقّت ولكن من دون إخبار أي أماكن وسيطة أخرى للتخزين المؤقّت أن تقوم بتخزين شاشة العرض هذه. أماكن التخزين المؤقت لمحتوى الويبيُمكِن التخزين المؤقّت للمحتوى في العديد من النقاط المختلفة على طول سلسلة التوصيل: التخزين المؤقّت للمتصفّح Browser cache: تحتفظ متصفّحات الإنترنت لنفسها بمكان صغير للتخزين المؤقّت، يقوم المتصفّح نموذجيًّا بتعيين سياسة تنص على أهم العناصر التي يجب تخزينها مؤقّتًا، والتي قد تكون محتوى خاص بالمستخدم أو محتوى يُعتبَر من المُكلِف تنزيله ومن المرجّح أن يُطلَب مرّة أخرى.وسطاء التخزين المؤقّت البيني Intermediary caching proxies: يستطيع أي خادوم بين العميل وبنيتنا التحتيّة أن يقوم بالتخزين المؤقّت كما يرغب، يتم الحفاظ على هذه التخزينات المؤقّتة من قبل مزوّدات خدمة الإنترنت ISPs أو أطراف مستقلّة أخرى.التخزين المؤقّت العكسي Reverse Cache: بإمكان البنية التحتيّة لخادومنا تنفيذ التخزين المؤقّت الخاص بها لخدمات المنتهى الخلفي backend services، وبهذه الطريقة يُمكِن تخديم المحتوى من نقطة الاتصال بدلًا من الوصول لخواديم المنتهى الخلفي backend عند كل طلب.تقوم هذه المواقع عادةً بعمل تخزين مؤقّت للعناصر وفق سياسات التخزين المؤقّت لديها والسياسات المُحدَّدة على الخادوم الأصل. الخاتمةتحدّثنا في هذا الدّرس عن مفهوم التخزين المؤقّت وشرحنا بعض المصطلحات الأساسيّة فيه، وشاهدنا الفوائد التي نحصل عليها من استخدامه، والأماكن التي يتم فيها هذا التخزين. تكلمنا أيضًا عن أنواع المحتوى التي يُمكِن تخزينها بشكل مؤقّت والأنواع التي لا يجب إطلاقًا تخزينها. ترجمة -وبتصرّف- لـ Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.
  19. يُعد إنجن إكس NginX خادوم ويب Web Server ذو أداء عالي وهو مسؤول عن معالجة العبء الواقع على بعض أكبر المواقع الإلكترونية Web Sites على الإنترنت Internet. وهو جيد خصوصًا في معالجة الكثير من الاتصالات المتزامنة concurrent ويتفوق في تخديم المحتوى الثابت static content. مع أنّ الكثير من المستخدمين يدركون قدرات Nginx، إلا أنه عادةً ما يحتار المستخدمين الجدد ببعض المصطلحات التي يجدونها في ملف إعدادات configuration خادوم Nginx. سنركّز في هذا الدليل على شرح البنية الأساسية لملف إعدادات Nginx بالإضافة لاستعراض بعض المبادئ guidelines في كيفية تصميم ملف الإعدادات. فهم سياقات الإعدادات في Nginxسيُغطي هذا الدليل البنية الأساسية الموجودة في ملف الإعدادات الرئيسي Nginx. قد يختلف مكان هذا الملف وفقًا للطريقة التي اتبعتها عند تثبيت البرمجية Software على الخادوم. إلا أنَّك سوف تجده في العديد من التوزيعات distributions على المسار التالي: /etc/nginx/nginx.confإنّ لم يكن موجودًا فقد تجده على المسار: /usr/local/nginx/conf/nginx.confأو المسار: /usr/local/etc/nginx/nginx.confإنّ أحد أول الأمور التي ينبغي عليك ملاحظتها عندما تنظر إلى ملف الإعدادات الرئيسي هي أنَّه منظَّم في بنيةٍ من ثلاثة أقسام تعرّف بداية ونهاية كلٍ منها بالقوسين } و {. تسمى الأقسام المعرّفة باستخدام القوسين سياقات contexts وفقًا للغة Nginx، وذلك لأنها تحوي على إعداداتٍ مُفَصَّلة وموزعة بين تلك الأقسام وفقًا للمجال الذي يُعنى به كل قسم. يقدم هذا التقسيم بشكل أساسي بنيةً منظّمة وفق بعض الشروط المنطقية التي تقرّر فيما إن كان ينبغي تطبيق الإعدادات التي يحويها القسم أو لا. وباعتبار أنه يمكن للسياقات أن تتداخل فيما بينها فإنNginx يقدم مستوًا من وراثة التعليمات directive inheritance. كقاعدةٍ عامة، إن كانت التعليمة صالحةً في عدّة مجالات scopes متدخلة فإنّ التصريح عنها في سياق أعلى boarder context سيُمرّر لأي سياقٍ أدنى (سياق ابن child context) كقيم افتراضية. يمكن للسياقات الأدنى أن يعيد تعريف override تلك القيم لاحقًا. جدير بالذكر أنّ عملية إعادة التعريف إلى أي مصفوفة-نوع array-type سينتج عنها استبدال القيم السابقة وليس إضافة append القيم الجديدة لها. يمكن أن تستخدم التعليمات Directives ضمن السياقات المصمّمة لها فقط، إذ أنّ Nginx سيُصدر خطأ عند قراءته لملف إعدادات يحوي على تعليمات مصرّح عنها في السياق الخاطئ. يحوي توثيق Nginx على معلومات حول كلّ تعليمة والسياقات التي تكون صالحة ضمنها لذلك يُعد مرجع رائع إن لم تكن متأكدًا من معلوماتك. سنناقش فيما يلي أكثر السياقات شيوعًا والتي قد تصادفها عند استخدامك Nginx. السياقات الأساسيةأول مجموعة سياقات سنشرحها هي السياقات الأساسية core contexts التي يستخدمها Nginx لإنشاء شجرة هرمية hierarchical tree وتوزيع الإعدادات - بحسب مهمّتها - في كتل Blocks منفصلة. تشكّل تلك السياقات البنية الأساسية لإعدادات Nginx. السياق الأساسيإن أكثر سياق عام هو السياق الأساسي Main Context، والذي يدعى أيضًا بالسياق العام Global Context. إذ أنه السياق الوحيد غير المحتوى ضمن كتل السياق القياسية والتي تبدو كما يلي: # السياق الأساسي يوجد هنا، السياقات الأخرى تكون خارجا . . . context { . . . }يمكن القول عن أيّة تعليمة موجودة خارج كل تلك الكتل بأنها تقع في السياق الأساسي. ضع في الحسبان أنه إن كانت إعدادات Nginx مضبوطةً على شكل وحدات modular فستحوي بعض الملفات على تعليماتٍ instructions تبدو وكأنها تقع خارج أقواس السياق إلا أنها ستُضمّن داخله عندما يتم دمج الإعدادات معًا. يمثّل السياق الأساسي أوسع بيئة حاضنة لإعدادات Nginx، وهي مستخدمة لضبط التفاصيل التي تؤثر على كامل التطبيق application في مستوى أساسي. وفي الوقت الذي تؤثر فيه التعليمات الموجودة في هذا القسم على السياقات الأدنى فإن العديد من تلك التعليمات لا توّرث، إذ أنه من غير الممكن إعادة تعريفها في مستوياتٍ أدنى. إن بعض التفاصيل الشائعة والتي تُهيّئ في السياق الرئيسي هي المستخدم user والمجموعة group التي ستُشغّل العمليات العاملة worker processes باسمهما، بالإضافة لعدد العمليات العاملة والملف الذي سيحتفظ بمعرّف العملية الرئيسية PID. يمكن أيضًا أن يُضبط ملف الأخطاء الافتراضي لكامل التطبيق ضمن هذا المستوى (كما يمكن أن يُعاد تعريف الملف ضمن سياقات مخصّصة أكثر). سياق الأحداثإنَّ سياق الأحداث Events Context يقع ضمن السياق الأساسي. وهو يستخدم لضبط الخيارات العامة التي تؤثّر على كيفية معالجة Nginx للاتصالات في مستوى عام. يمكن أن يُعرّف سياق أحداث واحد فقط ضمن إعدادات Nginx. سوف يبدو هذا السياق ضمن ملف الإعدادات كما يلي، خارج أقواس أي سياقٍ آخر: # السياق الأساسي events { # سياق الأحداث . . . }يستخدم Nginx وحدة معالجة اتصال مقادة بالأحداث event-based connection processing model لذلك فإن التعليمات المعرّفة داخل هذا السياق تحدّد كيف ينبغي على العمليات العاملة worker processes معالجة الاتصالات connections. تُستخدم التعليمات الموجودة هنا بشكل أساسي إما في اختيار الطريقة المستخدمة في معالجة الاتصال أو لتغيير كيفية تحقيق implement تلك الطرق methods. عادةً ما تُختار طريقة معالجة الاتصال تلقائيًا بالاعتماد على أكثر الخيارات - التي توفّرها منصّة العمل platform - فاعليةً. بالنسبة لأنظمة لينكس Linux، فعادةً ما تكون طريقة epoll هي الخيار الأفضل. هنالك عناصر أخرى يمكن ضبطها، كعدد الاتصالات التي يمكن لكل عملية عاملة أن تعالجها، وفيما إن كان على العملية أن تأخذ اتصالًا تلو الآخر أو أن تأخذ كل الاتصالات المنتظرة بعد أن يتم إعلامها بوجودها. وأيضًا فيما إن كان على العمليات العاملة أن تتناوب في الرد على الأحداث. سياق HTTPعند إعداد Nginx كخادوم ويب أو خادوم وكيل معكوس reverse proxy، فسيحتفظ سياق HTTP بغالبية الإعدادات. سيحتوي السياق على كل التعليمات والسياقات الأخرى الضرورية لتعريف كيفية معالجة البرنامج لاتصالات HTTP أو HTTPS. يُعد سياق HTTP أخًا لسياق الأحداث - أي أنهما يقعان في نفس المستوى - إذ أن كلاهما يُعد ابنًا للسياق الرئيسي، لذلك ينبغي أن يُدرجا جنبًا إلى جنب بدلًا من أن يتداخلا: # السياق الأساسي events { # سياق الأحداث . . . } http { # سياق HTPP . . . }فيما تختص السياقات الدنيا lower contexts في كيفية معالجات الطلبات، فإن التعليمات في هذا المستوى تتحكم بالقيم الافتراضية لكل الخواديم الافتراضية المعرّفة داخله. هنالك عدد كبير من التعليمات القابلة للضبط configurable ضمن هذا السياق والسياقات المحتواة ضمنه، يعتمد ذلك على طريقة التوريث inheritance التي ترغب أن يتم العمل وفقها. فيما يلي مجموعة من التعليمات التي يمكن أن تصادفها خلال ضبط إعدادات Nginx: تعليمات تتحكم بالمواقع الافتراضية لسجلات الوصول والأخطاء مثل (access_log و error_log).تعليمات تضبط عمليات القراءة والكتابة I/O غير المتزامنة asynchronous من وإلى الملفات مثل (aio و sendfile و directio)،تعليمات تضبط حالات الخادوم عندما تحدث الأخطاء مثل (error_page).تعليمات تضبط عملية الضغط compression مثل (gzip و gzip_disable).عمليات تحسّن fine-tune إعدادات اتصال TCP الحي TCP keep alive مثل (keepalive_disable و keepalive_requests و keepalive_timeout).القواعد rules التي يتبعها Nginx عندما يحاول تحسين optimize الحزم packets واستدعاءات النظام system calls مثل (sendfile و tcp_nodelay و tcp_nopush).تعليمات تضبط جذر المستندات document root وفهرس الملفات index files على مستوى التطبيق application-level مثل (root و index).تعليمات تهيّئ العديد من جداول المقابلة hash tables المستخدمة لتخزين أتماط مختلفة من البيانات مثل (*_hash_bucket_size و *_hash_max_size المستخدمتين مع server_names بالإضافة لـ types و variables).سياق الخادوميُعرّف سياق الخادوم Server Context ضمن سياق HTTP، ويُعد ذلك أوّل مثال لنا عن السياقات المتداخلة. كما أنّه أوّل سياق مرّ معنا يمكن تعريفه عدّة مرات. قد يبدو التنسيق العام لسياق الخادوم مشابهًا لما يأتي، تذكّر أنّ هذا السياق سيقع ضمن سياق HTTP: # السياق الأساسي http: { # سياق HTTP server { # سياق خادوم أول } server { # سياق خادوم ثاني } }يعود سبب السماح بوجود أكثر من تعريف لسياق الخادوم إلى أن كل غرض instance يعرّف خادومًا افتراضيًا لمعالجة طلبات المستخدم client. بإمكانك تعريف كتل الخادوم server blocks بقدر حاجتك، إذ أنّه بإمكان كل منها أن يعالج مجموعة فرعية محدّدة من الاتصالات. وبسبب امكانية وترجيح وجود عدة كتل خواديم، فإن هذا أوّل نوع من السياقات يحتّم على Nginx استخدام خوارزمية algorithm انتقاء لاتخاذ القرارات. إنّ كلّ طلب مستخدم سيُعالَج وفقًا للإعدادات المعرّفة في سياق خادوم وحيد، لذلك فإن على Nginx أن يقرّر أي سياق خادوم هو الأنسب وفقًا لتفاصيل الطلب. إنّ التعليمات التي تقرّر فيما إذا كانت كتلة الخادوم ستُستخدم أم لا هي: تعليمة التنصت listen: تُصمَّم كتلة الخادوم للرد على الطلبات الواردة من مصدر معرّف بثنائية عنوان الإنترنت IP / المنفذ Port. فإن ورد طلب request من مستخدم يطابق ذلك المصدر فمن المحتمل أن يتم اختيار تلك الكتلة لمعالجة الاتصال.تعليمة اسم الخادم server_name: هذه التعليمة هي المكوّن الآخر المستخدم في اختيار كتلة الخادوم التي ستقوم بالمعالجة. إن كان هنالك العديد من كتل الخادوم مزوّدةً بتعليمات تنصت مضبوطة بنفس القيم ويمكنها أن تعالج الطلب، فسيحلّل إنجن إكس ترويسة المُضيف Host header الخاصة بالطلب ويطابقها مع التعليمة.يمكن للتعليمات الموجودة ضمن هذا السياق أن تعيد تعريف العديد من التعليمات المعرّفة في سياق HTTP بما فيها تعليمات التسجيل logging، وجذر المستندات، والضغط، وإلى ما هنالك. وبالإضافة إلى التعليمات المأخوذة من سياق HTTP، فبإمكاننا أيضًا إعداد ملفات لمحاولة الرد على الطلبات عبر تعليمة (try_files)، وإصدار أمر لإعادة التوجيه وإعادة الكتابة (return و rewrite)، وضبط المتحولات عبر تعليمة (set). سياق الموقعالسياق التالي الذي ستتعرف عليه هو سياق الموقع location context وهو سياقٌ ستتعامل معه بشكل متكرّر. تتشارك سياقات الموقع العديد من الصفات مع سياقات الخادوم. فمثلًا، يمكن تعريف أكثر من سياق موقع، ويُستخدم كل منها لمعالجة نوع محدّد من طلبات المستخدم، ويتم اختيار كل موقع بناءًا على مطابقة تعريف الموقع مع طلب المستخدم باستخدام خوارزمية انتقاء. في الوقت الذي تُعرّف فيه التعليمات - التي تحدّد فيما إن كان سيتم اختيار كتلة خادوم - ضمن السياق الخادوم ذاته، فإن المكوّن component الذي يقرّر مدى قدرة الموقع على معالجة الطلب يقع ضمن تعريف الموقع نفسه. تبدو الصيغة العامة كما يلي: location match_modifier location_match { . . . }تقع كتل الموقع ضمن سياقات الخواديم، وعلى عكس كتل الخادوم، يمكن لكتل الموقع أن تتداخل فيما بينها. قد يفيد ذلك في إنشاء سياق موقع أعم ليلتقط مجموعة فرعية محدّدة من الطلبات المتناقلة traffic، لتكمل السياقات الإضافية الداخلية معالجتها بإسهاب أكبر وفقًا لمعايير أدق. # السياق الأساسي server { # سياق الخادوم location /match/criteria { # سياق موقع أول } location /other/criteria { # سياق موقع ثاني location nested_match { # موقع أول } location other_nested { # موقع ثاني } } }بينما يتم اختيار سياقات الخواديم وفقًا لثنائية عنوان IP / المنفذ المطلوبة ولاسم المضيف الموجود ضمن ترويسة المضيف، فإن كتل الموقع تقسّم معالجة الطلب ضمن كتلة الخادوم بالنظر إلى معرّف الموارد الموّحد URI الخاص بالطلب. إن معرّف URI الخاص بالطلب هو جزءٌ من الطلب يأتي بعد اسم النطاق domain name وثنائية عنوان IP / المنفذ. لذلك فإن طلب المستخدم http://www.example.com/blog على المنفذ 80، يستخدم العنوان http www.example.com والمنفذ 80 لتحديد كتلة الخادوم التي سيتم اختيارها. بعد اختيار الخادوم، سيُطابق الجزء /blog (المُمثّل لمعرّف URI الخاص بالطلب) مع المواقع المعرّفة لتحديد السياق الإضافي الذي ينبغي استخدامه ليرد على الطلب. إنّ العديد من التعليمات التي يمكن أن تراها في سياق الموقع متوفّرةٌ أيضًا في مستويات الآباء (المستويات الأعلى) parent levels. فيما يلي مجموعة جديدة من التعليمات المستخدمة ضمن هذا المستوى تسمح لك بالوصول إلى المواقع الواقعة خارج جذر المستندات (تعليمة alias)، وتحديد الموقع كموقع يمكن الوصول له من الداخل فقط (تعليمة internal)، وكوكيل لخواديم أو مواقع أخرى (باستخدام برتوكولات http، fastcgi، scgi، uwsgi) سياقات أخرىمع أنّ الأمثلة السابقة تمثّل السياقات الأساسية التي ستصادفها في Nginx، إلا أنه يوجد سياقات أخرى أيضًا. هنالك عدّة أسباب دعتنا لفصل السياقات التالية، فإما أنها تعتمد على الكثير من الوحدات الاختيارية، أو أنها تستخدم ضمن ظروف خاصة فقط، أو أنها تستخدم لوظائف لن يستخدمها معظم الأشخاص. لكننا لن نناقش كل السياقات المتوفّرة، ولن نخوض بشرح السياقات الآتية بالتفصيل: split_clients أُعد هذا السياق لتقسيم المستخدمين اللذين يستقبلهم الخادوم إلى فئات categories عبر عنونتهم بمتحولات تعتمد على النسبة المئوية. يمكن أن يُستخدم ذلك لاحقًا للقيام باختبار A/B عبر توفير محتويات content مختلفة لمُضيفين hosts مختلفين.perl / perl_set يُهيّئ هذين السياقين معالجات بيرل Perl للموقع الذي تتواجد ضمنه. تستخدم هذه السياقات للمعالجة باستخدام بيرل فقط.map يُستخدم هذا السياق لضبط قيمة متحول بالاعتماد على قيمة متحول آخر. إذ أنه يوفّر جدول مقابلة mapping لقيم المتحوّل الأول حتى يحدّد القيمة التي ينبغي ضبط المتحول الثاني بها.geo يُستخدم هذا السياق - مثل السياق السابق - في تحديد جدول مقابلة. إلا أنّ هذا الجدول يستخدم خصيصًا لتصنيف عناوين IP. يضبط هذا السياق قيمة متحول وفقًا لعنوان IP المتّصل.types يُستخدم هذا السياق أيضًا لجداول المقابلة. إذ أنه يُستخدم لمقابلة أنماط وسائط الإنترنت MIME بامتدادات (لواحق) extensions الملفات التي ينبغي ربطهم بها. يوفّر Nginx ذلك عادةً عبر ملف يُضمّن محتواه داخل ملف الإعدادات nginx.conf.charset_map يمثّل هذا السياق مثالًا آخر عن سياقات المقابلة، إذ أنه يُستخدم لإنشاء جدول مقابلة للتحويل conversion table من مجموعة محارف إلى مجموعة أُخرى. تضمّن كلا المجموعتين في ترويسة هذا السياق، ويضمّن جدول المقابلة في بنيته body.إنّ السياق التالي ليس شائعًا بقدر السياقات التي شرحناها حتى الآن، إلا أنّ التعرّف عليه يبقى مفيدًا. سياق مجموعة الخواديم العليايُستخدم سياق مجموعة الخواديم العليا upstream context لتعريف وإعداد الخواديم العليا upstream. يعرّف هذا السياق بشكل أساسي حوضًا pool معرّفًا باسم يحتوي على مجموعة الخواديم التي يستطيع Nginx أن يعمل كوكيل proxy عنها للطلبات. ستستخدم هذا السياق على الأرجح عندما تُعد وكلاءًا من مختلف الأنواع. يجب وضع سياق مجموعة الخواديم العليا ضمن سياق HTTP، وخارج كلِّ سياقات الخواديم. تبدو الصيغة العامة له كما يلي: # السياق الأساسي http { # سياق HTTP upstream upstream_name { # سياق مجموعة الخواديم العليا server proxy_server1; server proxy_server2; . . . } server { # سياق خادوم } }يمكن فيما بعد أن تتم الإشارة إلى سياق مجموعة الخواديم العليا باسمه ضمن الخادوم أو كتل الموقع لتمرير طلبات ذات نوع محدّد لحوض الخواديم الذي تمّ تعريفه. ستستخدم عندها مجموعة الخواديم خوارزميةً لتحديد الخادوم الذي ينبغي أن يسلم الطلب له، تستخدم خوارزمية راوند روبن round-robin بشكل افتراضي. يسمح هذا السياق لـNginx أن يعمل على موازنة الحمل load balancing عندما يعمل كوكيل للطلبات. سياق البريدبالرغم من أن Nginx يُستخدم عادةً كخادوم ويب أو خادوم وكيل معكوس، إلا أنه يعمل كخادوم وكيل للبريد mail proxy server بأداءٍ عالي جدًا. يسمّى السياق المستخدم لهذا النوع من التعليمات بالبريد mail. يعرّف سياق البريد The mail context ضمن السياق العام، أو السياق الأساسي (خارج سياق HTTP). الوظيفة الأساسية لسياق البريد هي توفير مجال لإعداد وكيل للبريد على الخادوم. يمكن لـNginx أن يعيد توجيه redirect طلبات المصادقة authentication لخادوم مصادقة خارجي authentication server. ويمكنه بعد ذلك أن يوفّر الوصول إلى خواديم البريد العاملة ببرتوكولات POP3 و IMAP لجلب بيانات البريد الفعلية. يمكن لسياق البريد أن يُعد أيضًا للاتصال بخادوم الترحيل العامل ببرتوكول SMTP (SMTP Relayhost) إن دعت الحاجة. عمومًا، قد يبدو شكل سياق البريد مشابهًا لما يلي: # السياق الأساسي events { # سياق الأحداث } mail { # سياق البريد }السياق الشرطييمكن أن يُنشئ السياق الشرطي if لتوفير معالجة شرطية للتعليمات المعرّفة بداخله. وكما هو حال عبارات الشرط if في لغات البرمجة التقليدية، فإن تعليمة if في Nginx ستنفذ التعليمات المتحواة ضمنها إن كان الشرط محقّقًا وأعاد القيمة الصحيحة True. يُقدَّم السياق if في Nginx من قِبل وحدة إعادة الكتابة rewrite module وهي الغاية الأساسية من استخدام هذا السياق. باعتبار أنّ Nginx سيختبر حالات الطلب باستخدام العديد من التعليمات الأخرى المعمولة لهذا الغرض، فلا ينبغي استخدام تعليمة if في أغلب حالات التنفيذ الشرطي. تُعد هذه الملاحظة هامةً لدرجة أنّ مجتمع Nginx أنشأ صفحةً وسمّاها if الشريرة. إنّ المشكلة الأساسية هي أنّ ترتيب المعالجة لدى Nginx قد يؤدي في كثير من الأحيان إلى نتائج غير متوقعة تظهر وكأنها تقلب معنى كتلة if رأسًا على عقب. تُعد تعليمتي إعادة التوجيه return وإعادة الكتابة rewrite التعليمتين الوحيدتين اللتين يعتبر استخدامهما آمنًا داخل هذه السياقات، إذ أنها أُنشئت لأجلهما. ضع في الحسبان أيضًا أنّه عند استخدام سياق if فإنّه يقدّم تعليمة try_files داخل نفس السياق بلا فائدة. غالبًا ما يتم استخدام if لتحديد فيما إنّ كان هنالك حاجة لتعليمة return أو تعلمية rewrite. وستقع غالبًا داخل كتل الموقع، لذلك فستبدو الصيغة العامة مشابهةً لما يلي: # السياق الأساسي http { # سياق HTTP server { # سياق خادوم location location_match { # سياق موقع if (test_condition) { # سياق شرطي if } } } }سياق تحديد الاستثناءاتيُستخدم سياق تحديد الاستثناءات Limit_except Context لتحديد استخدام طرق HTTP Methods محدّدة داخل سياق الموقع. فمثلًا، إن كان ينبغي لمجموعة محدّدة فقط من المستخدمين أن يصلوا إلى محتوى طريقة POST Method، أما البقيّة فينبغي أن يتمكّنوا من قراءة المحتوى، فيمكنك استخدام كتلة limit_except لتعريف تلك المتطلّبات. سيبدو المثال السابق مشابهًا لما يلي: . . . # سياق موقع أو خادوم location /restricted-write { # سياق موقع limit_except GET HEAD { # سياق تحديد الاستثناءات allow 192.168.1.1/24; deny all; } }ستطبق التعليمات الموجودة داخل السياق - والتي يقصد منها تقييد الوصول - عند مصادفة أيٍ من طرق HTTP باستثناء تلك المدرجة ضمن ترويسة السياق. إنّ نتيجة المثال السابق هي أنّه بإمكان أي مستخدم استخدام أفعال GET و HEAD، إلا أنّه يسمح فقط للمستخدمين المتصلين من الشبكة الفرعية subnet ذات العنوان 192.168.1.1/24 باستخدام طرق أخرى. قواعد عامة حول السياقات ينبغي اتباعهاالآن وبعد أن أصبح لديك فكرة عن السياقات الشائعة التي يمكن أن تصادفها أثناء استعراضك لإعدادات إنجن إكس، فبإمكاننا شرح بعض القواعد المُثلى التي يمكن اتباعها عند التعامل مع سياقات Nginx. تطبيق التعليمات في أعلى سياق متوفرإنّ العديد من التعليمات تكون صالحةً داخل أكثر من سياق واحد. فمثلًا، هنالك بضعة تعليمات يمكن وضعها داخل كل من سياقات HTTP والخادوم والموقع. يمنحنا ذلك مرونةً عند ضبط تك التعليمات. ولكن كقاعدة عامة، عادةً ما يكون من الأفضل تعريف التعليمات في أعلى سياق تقبل التعريف ضمنه، وإعادة تعريفها ضمن السياقات الأدنى عند الحاجة. يمكن ذلك بسبب وحدة الوراثة inheritance model التي تحقّقها إنجن إكس. هنالك العديد من الأسباب لاستخدام هذه الاستراتيجية. أولًا، إنّ التعريف ضمن أعلى مستوى يجنّبك تكرار نفس التعريف ضمن السياقات الأخوة. فمثلًا، في المثال التالي يعرّف كل موقع نفس جذر المستندات. http { server { location / { root /var/www/html; . . . } location /another { root /var/www/html; . . . } } }يمكنك نقل الجذر خارج كتلة الخادوم، أو حتى لكتلة HTTP كما يلي: http { root /var/www/html; server { location / { . . . } location /another { . . . } } }أغلب الأحيان، سيكون مستوى الخادوم ملائمًا أكثر، إلا أنّ التصريح declaring في مستوىً أعلى له محاسنه. إنّ ذلك لا يسمح بضبط التعليمة في أماكن أقل فحسب، وإنما سيسمح لك بتمرير القيمة الافتراضية لكل الأبناء، ما يمنع ظهور الحالات التي تصادف فيها خطأً لأنك نسيت تعليمةً ضمن مستوىً أدنى. يمكن أن يكون ذلك مشكلةً كبيرةً في الإعدادات الطويلة. إن التصريح في مستوىً عالي يوفّر لك قيمةً افتراضيةً صحيحة. استخدام عدة سياقات أشقاء عوضا عن المنطق الشرطي If في المعالجةعندما تريد معالجة الطلبات كل بشكل مختلف، اعتمادًا على بعض المعلومات التي يمكنك ايجادها ضمن طلب المستخدم، فعادةً ما يلجئ المستخدمون إلى سياق if ليحاولوا معالجتها شرطيًا. هنالك بعض المشاكل المترافقة مع ذلك كنا قد ذكرناها سابقًا بإيجاز. أول مشكلة هي أنّ تعليمة if عادةً ما تعيد نتائج لا تتوافق مع توقعات مدير النظام administrator. مع أنّ المعالجة ستُؤدي دائمًا إلى نفس النتائج عند توفير نفس المُدخلات، إلا أنّ الطريقة التي يتبعها Nginx في تفسير البيئة يمكن أن تختلف كثيرًا عما هو متوقع ما ام تخضع لاختبارات مكثّفة. السبب الثاني هو أنّ هنالك تعليمات معدّة لهذا الغرض بالتحديد، وهي مستخدمةٌ للعديد من تلك الأغراض. يستخدم Nginx خوارزمية انتقاء - ذات توثيق جيد - لاختيار كتل الخادوم وكتل الموقع. لذلك، يفضّل نقل الإعدادات المختلفة إلى الكتل المخصّصة لها إن كان ذلك ممكنًا، ما يسمح لتلك الخوارزمية بمعالجة منطق عملية الاختيار. فمثلًا، عوضًا عن الاعتماد على إعادة الكتابة rewrites للحصول على طلب المستخدم بالشكل format الذي ترغب بالعمل به، فعليك أن تجرّب إعداد كتلتين للطلب، أحدهما تمثّل الطريقة المرغوب بها، والأخرى تلتقط الطلبات العشوائية وتعيد توجيهها - وقد تعيد كتابتها - للكتلة الصحيحة. عادةً ما تكون النتائج أسهل للقراءة كما أنها تمتلك محاسن كونها ذات أداء عالي. لا تخضع الطلبات الصحيحة لأي معالجة إضافية وفي العديد من الحالات يمكن تجاوز الطلبات غير الصحيحة عبر تعليمة إعادة التوجيه عوضًا عن تعليمة إعادة الكتابة والتي ينبغي أنّ يكون عبء تنفيذها أقل. الخلاصةإلى هنا، ينبغي أن تكون قد حصلت على فهم جيّد لأكثر سياقات Nginx شيوعًا وللتعليمات التي تُنشئ الكتل التي تعرّف تلك السياقات. تحقّق دائمًا من توثيق Nginx للحصول على معلومات حول أي السياقات هو الأنسب لوضع تعليمة ما بداخله ولتقييم الموقع الأكثر فاعلية. إنّ الحرص أثناء إنشاء الإعدادات لن يسهل من عملية الصيانة فحسب، بل أنه سيرفع الأداء أيضًا في أغلب الآحيان. ترجمة -بتصرف- للمقال Understanding the Nginx Configuration File Structure and Configuration Contexts لكاتبه Justin Ellingwood.
  20. كُنّا في درس سابق قد تحدثنا عن كيفية تخطيط صفحات الويب باستعمال CSS2 وكيف أنّ ذلك لم يكن بالأمر السهل، لذلك في هذا الدرس سوف نقوم بنفس التخطيط ولكن باستعمال تقنيات CSS3 الجديدة. تٌقدّم لنا CSS3 مجموعة من التقنيات والتحسينات لتساعدنا على تخطيط صفحات الويب بشكل أفضل وأسهل ودون الحاجة إلى الكثير من الأكواد كما كان الحال في CSS2. كما أنها مُصممة لتدعم السلوكات المتغيرة/الديناميكية وبالتالي يمكننا القول بأنها " لغة قابلة للبرمجة". دعونا إذًا نرى بعض الخصائص والتقنيات الجديدة التي توفرها هذه اللغة ونحاول استخدامها لدعم حالة الاستخدام التي كنّا قد بدأنا بها في الدرس السابق. دالة ()calc الخاصة بلغة CSS3تُستخدم دالة ()calc الجديدة لحساب القيم بشكل ديناميكي (ضع في الحسبان أن دعم هذه الدالة يختلف من متصفح لآخر). وفي داخل هذه الدالة يمكنك كتابة أي معادلة/تعبير (expression) باستخدام المعاملات الحسابية المعروفة (+، -، *، /). سوف يساعدنا استخدام هذه الدالة على التخلص من الكثير من الأكواد التي كان لا بد منها في CSS2، وفي حالتنا هذه فإنها سوف تساعدنا في تمدد العناصر بشكل أفضل (سوف يصبح استخدام تقنية CSS Expansion التي ذكرناها سابقًا أكثر سهولة). أنظر للكود الموجود في الأسفل: #nav, #subnan { position: fixed; height: calc(100% - 10em); /* replaces */ z-index: 20; }لاحظ أننا استخدمنا الدالة ()calc في الخاصية height وهذا سوف يساعدنا بالحصول على نفس النتيجة التي حصلنا عليها باستخدام CSS2 عندما استخدمنا الخاصيتين top: 6em و bottom: 4em، وبهذا يمكن للأمور أن تصبح أكثر مرونة وسوف نحتاج إلى خاصية واحدة (height مع ()calc) بدل اثنتين (top وbottom). استخدام CSS3 Flexbox في تخطيط الصفحاتتُعتبر Flexbox من الخصائص والتقنيات الجديدة التي ظهرت في CSS3 وهي تجعل من تخطيط الصفحات وترتيب عناصرها أمرًا سهلًا ومتشابهًا في مختلف أحجام الشاشات والأجهزة، وبالتالي فهي مفيدة جدًا عند القيام بتصميم مواقع متجاوبة. وهذه بعض الخصائص والميزات التي تتمع بها Flexbox: تمكننا من موضعة العناصر الأبناء (child elements) بشكل أسهل ويصبح تخطيط الصفحات المعقدة أبسط وأسهل ودون الحاجة إلى الكثير من الأكواد فيصبح لدينا كود أنظف وقابل للقراءة بشكل أفضل.يمكن وضع العناصر الأبناء بأي إتجاه نريده وتصبح أبعاد تلك العناصر مرنة أكثر بحيث يمكنها التجاوب مع مساحة العرض.تستطيع العناصر الأبناء أن تتمدد وتتقلص تلقائيًا لتشغل المساحة الفارغة.كما أنّ Flexbox يقدم مجموعة خاصة به من المفاهيم والمصطلحات، ونذكر بعض منها: Flex container: العنصر الذي يحتوي على الخاصية display بالقيمة flex أو inline-flex بحيث يصبح هذا العنصر هو العنصر الحاوي (الأب) للعناصر التي نريد التعامل معها.Flex item: هو أي عنصر موجود في الـFlex container. (ملاحظة: أي نص موجود بشكل مباشر داخل الـFlex container سيتم احتواؤه داخل anonymous flex item).Axes: أي flexbox يجب أن يحتوي على الخاصية flex-direction بحيث تُحدد هذه الخاصية المحور الرئيسي (main axis) الذي سوف تتموضع حوله الـflex items. ويوجد أيضًا المحور العرضي (cross axis) ويكون هذا المحور عموديًا على المحور الرئيسي.Lines: يمكن للـflex items أن تصطف/تتموضع في خط واحد أو خطوط متعددة وذلك ما تحدده الخاصية flex-wrap.Dimensions: يحتوي flexbox على main size و cross size كبديل عن height وwidth بحيث تُحدد هاتين القيمتين حجم المحور الرئيسي (main axis) والعرضي (cross axis) على التوالي.بعد هذه المقدمة القصيرة عن flexbox يمكننا الآن استخدامها في تخطيط الصفحات. <body class="layout-flexbox"> <header id="header"></header> <div class="content-area"> <nav id="nav"></nav> <aside id="subnav"></aside> <main id="main"></main> </div> <footer id="footer"></footer> </body>نريد في حالة الاستخدام التي نعمل عليها أن تكون العناصر الرئيسية (header ،content ،footer) مصفوفة بشكل عمودي، وبالتالي سوف نستخدم القيمة column في الخاصية flex-direction كما يلي: .layout-flexbox { display: flex; flex-direction: column; }ومع أنّ العناصر الرئيسية يجب أن تكون مصفوفة بشكل عمودي إلّا أنّ العناصر في منطقة المحتوى (nav ،subnav ،main) نريدها مصفوفة بشكل أفقي. وبما أنّ كل flex container يمكن أن يحتوي على خاصية flex-direction واحدة فقط فإننا سنقوم بتعريف العديد من flex containers داخل بعضها البعض حتى يمكننا التحكم في تخطيط الصفحة كما نشاء (أي حتى يصبح بإمكاننا أن نجعل العناصر تصطف كما نريد وألّا نصبح مقيدين باتجاه واحد فقط). ولهذا السبب قمنا بإضافة حاوي (container) آخر (<div class="content-area">) ليحتوي على عناصر nav ،#subnav# و main#. وبهذا يمكن للعناصر الرئيسية أن تصطف بشكل عمودي بينما تصطف عناصر منطقة المحتوى بشكل أفقي. نريد الآن أن نقوم بموضعة الـflex items لذلك سوف نستخدم الخاصية flex وهي اختصار(shorthand) للخصائص flex-grow ،flex-shrink وflex-basis. وهذه الخصائص تُحدد كيف تقوم الـflex items بتوزيع المساحة الفارغة المتبقية بينها، وهذا تعريف بسيط بهذه الخصائص: flex-grow: تُحدد كم يمكن للعنصر (flex item) أن ينمو/يتمدد نسبة للعناصر الأخرى في نفس الحاوي.flex-shrink: تُحدد كم يمكن للعنصر (flex item) أن يتقلص نسبة للعناصر الأخرى في نفس الحاوي.flex-basis: يُحدد الحجم الافتراضي للعنصر (أي حجمه قبل أن ينمو أو يتقلص). عندما نقوم بإعطاء الخاصيتين flex-grow وflex-shrink القيمة "صفر" فإننا نقوم بمنع العنصر من أن يتقلص أو ينمو حتى لو كان هناك مساحة فارغة (أي أنّ حجم العنصر يبقى ثابتًا). وهذا ما سوف نقوم به للترويسة (header) والتذييل (footer) لأننا نريد أن يبقى حجمهما ثابتًا: #header { flex: 0 0 5em; } #footer { flex: 0 0 3em; }وإذا أردنا لعنصر أن يستغل أي مساحة ثابتة فإننا نعطي الخاصيتين flex-grow وflex-shrink القيمة "1" ونعطي الخاصية flex-basis القيمة auto. وهذا ما نريده بالنسبة لمنطقة المحتوى (نريدها أن تستغل أي مساحة فارغة). وكما ذكرنا سابقًا فإننا نريد للعناصر الموجودة داخل <div class="content-area"> أن تصطف بشكل أفقي، لذلك سوف نعطيها الخاصية display: flex حتى يصبح هذا العنصر عبارة عن flex container وسوف نعطيها أيضًا الخاصية flex-direction: row حتى نجعل العناصر الموجودة في داخله (nav ،#subnav# و main#) تصطف بشكل أفقي، وبالتالي نحصل على تنسيقات CSS التالية: .content-area { display: flex; flex-direction: row; flex: 1 1 auto; margin: 1em 0; min-height: 0; }في منطقة المحتوى نريد أن يكون حجم كلا العنصرين nav# وsubnav# ثابت وبالتالي سوف نعطيها الخاصية flex بقيم مناسبة: #nav { flex: 0 0 5em; margin-right: 1em; overflow-y: auto; } #subnav { flex: 0 0 13em; overflow-y: auto; margin-right: 1em; }لاحظ أنني استعملت الخاصية overflow-y: auto وذلك حتى نتعامل مع المحتوى إذا ما تجاوز ارتفاع الحاوي. متصفح Firefox هو من يحتاج لهذه الخاصية. سوف يأخذ العنصر main# المساحة الفارغة المتبقية: #main { flex: 1 1 auto; overflow-y: auto; }كل شيء يبدو جيدًا إلى الآن، لذلك دعونا نقوم بإضافة السلوك المتغير/الديناميكي ونرى ما يحصل. سوف تكون أكواد الجافاسكربت مشابهة لما استخدمناه سابقًا باستثناء أن اسم الـclass للعنصر الحاوي سيكون layout-flexbox بدلًا من layout-classic: $('.layout-flexbox #nav’).on('click', 'li.nav-toggle', function() { $('#nav').toggleClass('expanded'); });سوف نضيف "class expanded" إلى تنسيقات CSS كما يلي: #nav { flex: 0 0 5em; /* collapsed size */ margin-right: 1em; overflow-y: auto; &.expanded { flex: 0 0 10em; /* expanded size */ } }لاحظ أننا هذه المرة لم نحتج إلى أن ندع العناصر الأخرى تعلم بشأن تغير العرض وذلك لأنّ flexbox تعالج الأمر دون تدخل منا. الشيء الوحيد المتبقي هو إخفاء القائمة الفرعية، ولكن احزر ماذا؟ لن نحتاج لكتابة أي أكواد إضافية لأن flexbox سيعلم بشأن المساحة الفارغة وسوف يتكفل بجعل كل شيء يعمل كما هو مطلوب. يوفر لنا flexbox أيضًا مجموعة من الطرق التي تمكننا من توسيط العناصر في الاتجاهين العمودي والأفقي. يمكننا الآن معرفة أهمية وجود مثل هذه التقنية في لغة CSS وكيف أنّها تساعد على جعل الكود أفضل وله القابلية للتطور والتوسع. ولكن على الناحية الأخرى فإنّ هذه التقنيات تحتاج إلى وقت أكثر لإتقانها مقارنة بخصائص CSS الأخرى. تخطيط الصفحات باستخدام CSS3 Gridإذا كنت تعتقد أن flexbox شيء جديد فأنت حتمًا لم تسمع عن CSS3 Grid، فهي ما زالت في مرحلة مبكرة (مرحلة draft) ودعم المتصفحات لها شبه معدوم (يمكنك تفعيلها في متصفح Google Chrome عن طريق الدخول إلى chrome://flags واختيار "experimental Web Platform features"). وفائدتها هي أنها تعمل في طبقة العرض (presentation layer) وبالتالي لن نحتاج إلى معرفة كيفية ظهور العناصر في التوصيف (markup) الخاص بملفات HTML (أي أنّ كل شيء سيتم باستخدام CSS بعض النظر عن ترتيب العناصر في HTML). الفكرة العامة هي أن يكون هناك شبكة تخطيط (grid) مرنة ومُعرّفة بشكل مسبق يمكن أن نستخدمها لموضعة العناصر بداخلها. وكما هو الحال في flexbox فإنها تعمل على مفهوم المساحات الفارغة وتسمح لنا بتعريف إتجاهين (عمودي وأفقي) في نفس العنصر مما يؤدي إلى تقليل حجم الكود وزيادة مرونته. يُقدّم لنا Grid Layout نوعين من الـgrids وهما explicit وimplicit، ولجعل الأمور بسيطة سوف نركز على explicit فقط. وكما هو الحال مع flexbox فإنّ Grid يقدم مجموعة خاصة به من المفاهيم والمصطلحات، ونذكر بعض منها: Grid container: هو أي عنصر يملك الخاصية display بالقيمة "grid" أو "inline-grid" بحيث تتموضع العناصر داخله ويتم محاذاتها بناءً على grid مُعرّف مسبقًا (explicit mode). والـgrid هو عبارة عن مجموعة من الخطوط العمودية والأفقية المتقاطعة والتي تفصل الـGrid container إلى مجموعة من الخلايا (cells). وهناك مجموعتين من الخطوط؛ الأولى لتعريف الأعمدة (columns) والثانية تكون عمودية على هذه الأعمدة لتعريف الصفوف (rows).Grid track: هي المسافة بين خطّين متجاورين، وكل Grid track يتم إعطاؤه دالة تحجيم (sizing function) للتحكم بكيفية نمو كل عمود أو صف وبالتالي التحكم في البعد بين الخطوط المحيطة بكل خط.Grid cell: هي المسافة بين صفّين متجاورين وعمودين متجاورين من خطوط الـgrid، وهو أصغر وحدة من الـgrid يمكن الرجوع والاستناد إليها عندما نقوم بموضعة عناصر الـgrid.Flexible length: هو بُعد يتم تحديده بوحدة fr وهو يُمثّل جزء من المساحة الفارغة في الـGrid container. إليك عناصر HTML التي سوف نستخدمها: <body class="layout-grid"> <header id="header"></header> <nav id="nav"></nav> <aside id="subnav"></aside> <main id="main"></main> <footer id="footer"></footer> </body>لاحظ بأننا في تخطيط الصفحة هذا لن نحتاج إلى عنصر إضافي يعمل كحاوٍ لمنطقة المحتوى كما كان الحال مع flexbox، وذلك لأنّ هذا النوع من تخطيط الصفحات (Grid layout) يسمح لنا بتعريف مساحة كل عنصر في كلا الإتجاهين وبنفس الـGrid container. لنبدأ الآن بإضافة تنسيقات CSS: .layout-grid { display: grid; grid-template-columns: auto 0 auto 1em 1fr; grid-template-rows: 5em 1em 1fr 1em 3em; }قمنا باستخدام الخاصية display: grid على الحاوي (Grid container)، وكذلك استخدمنا الخاصيتين grid-template-columns وgrid-template-rows وهما تمثلان المساحة بين الـGrid tracks. بمعنى آخر، فإنّ هاتين القيمتين لا تمثلان مكان تواجد خطوط الـgrid وإنّما تمثلان مقدار المساحة بين الـGrid tracks. ضع في الحسبان أنّ وحدات القياس يمكن أن تكون أي واحدة من التالية: وحدة طول (length).نسبة مئوية معينة من حجم الحاوي (Grid container).مساحة من المحتوى الذي يحتله العمود أو الصف.جزء من المساحة الفارغة في الـgrid.فعلى سبيل المثال، في الخاصية grid-template-column: auto 0 auto 1em 1fr سيكون لدينا التالي: track واحد لتعريف عمودين بعرض auto (مساحة القائمة الرئيسية nav#).gutter واحد بقيمة "صفر" (الـmargin الخاص بالعنصر subnav# موجود في مستوى العنصر، ويمكن أن يكون موجودًا أو لا وبهذه الطريقة نضمن أن لا يكون هناك gutter مزدوج).track واحد لتعريف عمودين بعرض auto (مساحة القائمة الفرعية subnav#).gutter واحد بقيمة 1em.track واحد بقيمة 1fr للعنصر main# (سوف يأخذ المساحة المتبقية).لاحظ أننا استخدمنا القيمة auto في الـtrack، وهذا يسمح لنا بالحصول على أعمدة ديناميكية بحيث يتم تعريف مكان وحجم خطوط الـgrid بناءً على المحتوى الخاص بها. (سوف نحتاج أيضًا إلى تعريف حجم العنصرين nav# وsubnav# وهذا ما سنفعله بعد قليل). وبطريقة مشابهة، سوف تملك الصفوف الخاصية grid-template-row: 5em 1em 1fr 1em 3em مما يجعل العنصرين header# و footer# ثابتين ويؤدي أيضًا إلى أنّ العناصر الموجودة بين هذين العنصرين سوف تستخدم المساحة الفارغة المتبقية في حين تكون قيمة الـgutters بقيمة 1em. لنرى الآن كيف سنقوم بموضعة العناصر داخل الـgrid الذي قمنا بتعريفه: #header { grid-column: 1 / 6; grid-row: 1 / 2; } #footer { grid-column: 1 / 6; grid-row: 5 / 6; } #main { grid-column: 5 / 6; grid-row: 3 / 4; overflow-y: auto; }إنّ تنسيقات CSS الخاصة بالعنصر header# تُخبرنا بأننا نريد أن تكون الترويسة موجودة بين الخطين 1 و6 (أي العرض كامل) بالنسبة للأعمدة وبين الخطين 1 و2 بالنسبة للصفوف. ونفس الشيء بالنسبة للعنصر footer# فنريده أن يكون موجودًا بين الخطين 1 و6 (أي العرض كامل) بالنسبة للأعمدة وبين الخطين 5 و6 بالنسبة للصفوف. أمّا بالنسبة لمنطقة المحتوى فقد تمّ إعطاؤها الخصائص المناسبة حتى تشغل المساحة التي يفترض بها أن تشغلها. لاحظ أنّ الخاصية grid-column هي اختصار (shorthand) للخاصيتين grid-column-start وgrid-column-end و أنّ الخاصية grid-row هي اختصار للخاصيتين grid-row-start وgrid-row-end. لنعد الآن إلى العنصرين nav# وsubnav#. بما أننا قمنا مسبقًا بوضع هذين العنصرين داخل الـtrack بقيم auto فسوف نحتاج إلى تحديد مساحتهما (نفس الشيء سيكون بالنسبة لـ"expanded" فسوف نقوم فقط بتغيير عرضها وسوف يتكفل Grid بالباقي). #nav { width: 5em; grid-column: 1 / 2; grid-row: 3 / 4; &.expanded { width: 10em; } } #subnav { grid-column: 3 / 4; grid-row: 3 / 4; width: 13em; margin-left: 1em; }يمكننا الآن أن نقوم بتغيير وضع القائمة الرئيسية nav# وإخفاء أو إظهار القائمة الفرعية subnav# وكل شيء سيعمل بشكل جيد وملائم. كما أنّ Grid Layout تسمح لنا باستعمال أسماء مستعارة لتسمية الخطوط حتى نستطيع أن نُغير في الـgrid كما نريد دون أن يؤدي ذلك إلى خلل في الأكواد لأنّها ستكون مربوطة باسم معين وليس بأحد خطوط الـgrid. خاتمةحتى باستخدام تقنيات CSS القديمة فإنّ هناك الكثير مما يستطيع مطورو الويب فعله واستغلاله. ومع ذلك فقد يكون ذلك مهمة ليست سهلة وتحتاج إلى الكثير من الأكواد والتي قد تكون مكررة في كثير من الأحيان. ولكن كما شاهدنا فإنّ CSS3 بدأت تقدم طرق وتقنيات أفضل لتخطيط صفحات الويب والتي بدورها تُسهّل العمل على مطوري الويب. لذلك أعتقد أنه يجب على أي مطور ويب أن يتقن ويتعلم هذه التقنيات حتى يُحسّن من تجربة المستخدم وحتى يقوم بكتابة كود أنظف وأفضل. وهذه المقالة قدمت جزءًا صغيرًا فقط مما يمكن فعله باستخدام تقنيات CSS3 وهناك الكثير مما يجب عليك تعلمه. ترجمة -وبتصرّف- للمقال CSS Layout Tutorial: From Classic Approaches to the Latest Techniques لصاحبه Laureano Martin Arcanio.
  21. إنّ إتقان تخطيط صفحات الويب بدون إتقان لغة CSS سيكون كمن يحاول السباحة على أرضٍ جافة، ولكن على عكس السباحة التي عندما تتقنها تبقى معك طول الحياة فإنّه لا يوجد مرحلة يمكنك عندها التوقف عن التعلم وتقول أنّك أتقنت CSS فهذه اللغة تتطور بسرعة يومًا بعد يوم. كما أنّ تعلم وإتقان هذه اللغة سيكون أكثر تحديًا بسبب وجود إختلافات في كيفية تطبيق ودعم هذه اللغة من قبل المتصفحات (حتى بين الإصدارات المختلفة للمتصفح نفسه). ولمدة تناهز العشر سنوات كان مطوّرو الويب يتصارعون ويعانون من الدعم المتشتت وغير المتناسق لخصائص CSS3 في كل إصدار جديد للمتصفحات. ولكن لنتفق على شيء ما وهو أنّ إتقان CSS شيء لا بد منه لأي مطور ويب جيد. وفي هذا المقال سوف نأخذكم في جولة لنتعرف على مبادئ CSS في تخطيط الصفحات وسوف نبدأ من التقنيات التي ظهرت في CSS2 وانتهاءً بآخر ما ظهر في CSS3. ملاحظة: سوف نستخدم HTML5 وSass في هذا المقال. ويمكنك الحصول على الشيفرات البرمجية كاملة من هنا. إحدى حالات الاستخدامإنّ من أفضل الطرق لتعلم أي تقنية هو أن يكون هناك حالة استخدام محددة تحاول دعمها أو أنّك تبحث عن حل لمشكلة ما. وحتى نهاية هذا المقال سنركز على حالة استخدام بمجموعة من المتطلبات. ستكون حالة الاستخدام التي سنعمل عليها عبارة عن تخطيط لتطبيق ويب (Web App) مع بعض السلوكيات المتغيرة/الديناميكية (dynamic)، بحيث سيكون هناك عناصر ثابتة في الصفحة مثل الترويسة (header) والتذييل (footer) وقائمة رئيسية (navigation) وقائمة فرعية (sub-navigation) وقسم محتوى قابل للتمرير(scrollable content). ستكون المتطلبات الخاصة بتخطيط الصفحة كما يلي: التخطيط الأساسي:الترويسة، التذييل، قائمة رئيسية وقائمة فرعية وهذه العناصر ستبقى ثابتة عند التمرير (scroll).سوف تشغل القائمة الرئيسية والقائمة الفرعية أي مساحة عمودية فارغة.سوف يشغل قسم المحتوى المساحة المتبقية في الصفحة وسوف يحتوي على منطقة قابلة للتمرير.السلوكيات المتغيرة/الديناميكية:سوف تحتوي القائمة الرئيسية على أيقونات فقط بشكل افتراضي، ولكن يمكن لها أن تتمدد لتحتوي على بعض النصوص (وأيضًا تتقلص/تنطوي لتظهر الأيقونات فقط مرة أخرى). اختلافات في تخطيط الصفحة:ستحتوي بعض الصفحات على قائمة فرعية بجانب القائمة الرئيسية والبعض الآخر لا. استخدام تقنيات CSS2 هذا هو تخطيط HTML5 الذي سوف نستخدمه: <body class="layout-classic"> <header id="header"></header> <nav id="nav"></nav> <aside id="subnav"></aside> <main id="main"></main> <footer id="footer"></footer> </body> 1. الموضعة الثابتة (position: fixed)في CSS2 يمكنك الحصول على عناصر ثابتة في الصفحة (مثل الترويسة، التذييل...الخ) عن طريق توظيف نموذج تخطيط يَستخدم الموضعة الثابتة (يستخدم position: fixed). سوف نستخدم أيضًا الخاصية z-index لنتأكد بأنّ العناصر الثابتة سوف تظهر فوق جميع العناصر الأخرى في الصفحة، بحيث تقوم هذه الخاصية بتحديد مكان العنصر إمّا أعلى أو أسفل عنصر آخر، فالعناصر التي تحتوي على قيمة z-index كبيرة سوف تظهر فوق العناصر التي تحتوي على قيمة z-index أقل. هناك شيء مهم يجب عليك تذكره وهو أنّ خاصية z-index لن تعمل إلا بوجود خاصية position، أي أنّك إذا استخدمت خاصية z-index على أحد العناصر ولكنك لم تستخدم خاصية position على نفس العنصر فإنّ خاصية z-index لن تعمل. وبالنسبة لنا، فسوف نستخدم القيمة 20 (وهي أعلى من القيمة الافتراضية) حتى نُبقي العناصر الثابتة فوق العناصر الأخرى في الصفحة. وسوف نستخدم خاصية width ونعطيها القيمة 100% وهذا سيسمح للعناصر بالتمدد أفقيًا بالقدر الذي تستطيعه. #header, #footer { position: fixed; width: 100%; z-index: 20; } #header { top: 0; height: 5em; } #footer { bottom: 0; height: 3em; }هذا بالنسبة للترويسة والتذييل، ولكن ماذا بالنسبة للقائمة الرئيسية (nav#) والفرعية (subnav#)؟ 2. تقنية التوسع/التمدد في CSSبالنسبة للقائمة الرئيسية (nav#) والفرعية (subnav#)، سوف نستخدم تقنية تسمى بتقنية التمدد (CSS Expantion) بحيث تُستخدم هذه التقنية على العناصر التي تحتوي على الخاصية position: fixed (بحيث يبقى العنصر ثابت في الصفحة) أو الخاصية position: absolute (بحيث يتم موضعة العنصر بناءً على أقرب عنصر حاوي يحتوي على الخاصية position بقيمة غير القيمة static). يمكن الحصول على تمدد رأسي/عمودي (vertical) باستخدام الخاصيتين top و bottom وإعطائها قيم محددة بحيث يتمدد العنصر عموديًا ليستخدم المساحة العمودية المتبقية وفقًا لتلك القيم، أي أنّ ما نقوم به هو ربط الجزء العلوي للعنصر بمسافة محددة من الجزء العلوي للصفحة وكذلك ربط الجزء السفلي للعنصر بمسافة محددة من الجزء السفلي للصفحة مما سيؤدي إلى تمدد العنصر ليشغل المساحة العمودية بين هاتين النقطتين (العلوية والسفلية). ونفس الأمر ينطبق على التمدد الأفقي بحيث نستخدم الخاصيتين left و right ونعطيها قيم محددة بحيث يتمدد العنصر أفقيًا ليشغل المساحة الأفقية المتبقية وفقًا لتلك القيم. وبالنسبة لنا في هذه الحالة فإننا نريد أن نستخدم التمدد العمودي: #nav, #subnav { position: fixed; top: 6em; /* ترك مسافة فوق الترويسة */ bottom: 4em; /* ترك مسافة تحت التذييلة */ z-index: 20; } #nav { left: 0; width: 5em; } #subnav { left: 6em; /* leave 1em margin to right of nav */ width: 13em; }3. الموضعة الإفتراضية/الساكنة (static)سوف نستخدم الموضعة الساكنة لموضعة منطقة المحتوى القابلة للتمرير، بحيث تظهر العناصر وتتموضع بالترتيب كما تظهر بالتدفق الطبيعي للمستند (كما تظهر في ملف HTML)، وبما أنّ جميع العناصر الأخرى في الصفحة متموضعة بشكل ثابت فإنّ هذا العنصر سيكون هو العنصر الوحيد الذي يظهر وفقًا للتدفق الطبيعي للمستند. ونتيجة لذلك فكل ما نحتاجه لموضعة العنصر بشكل مناسب هو استخدام الخاصية margin حتى لا يحصل تداخل بينه وبين العناصر الأخرى الثابتة (الترويسة، التذييل والقائمتين الرئيسية والفرعية): #main { margin: 6em 0 4em 20em; }وبهذا نكون قد أتممنا متطلبات التخطيط الأساسي باستخدام CSS2 وبقي علينا أن نهتم بأمر المتطلبات الإضافية الخاصة بالسلوكيات المتغيرة/الديناميكية. 4. السلوكيات المتغيرة/الديناميكية باستخدام تقنيات CSS2ذكرنا سابقًا بأنّ القائمة الرئيسية سوف تحتوي على أيقونات فقط بشكل افتراضي، ولكن يمكن لها أن تتمدد لتحتوي على بعض النصوص (وأيضًا تتقلص/تنطوي لتظهر الأيقوانات فقط مرة أخرى). لنبدأ أولًا بإعطاء القائمة الرئيسية عندما تكون متمددة عرضًا (width) بقيمة 5em زيادة على عرضها الرئيسي (أي يصبح عرضها عندما تتمدد 10em)، وسوف نقوم بذلك عن طريق إنشاء class باسم "expanded" بحيث يمكننا ديناميكيًا (باستخدام الجافاسكربت) إضافته أو إزالته من القائمة الرئيسية: #nan { left: 0; width: 5em; &.expanded { /* Sass notation */ width: 10em; } } يمكنك بالأسفل رؤية كود الجافاسكربت (jQuery في حالتنا هذه) الذي سوف نستخدمه لإضافة أو إزالة الـclass الذي يحمل الاسم "expanded" عندما يقوم المستخدم بالنقر على أيقونة القائمة: $('.layout-classic #nav').on('click', 'li.nav-toggle', function() { $('#nav').toggleClass('expanded'); });يمكن الآن للقائمة الرئيسية أن تتمدد أو تتقلص بكل سهولة. ولكن هناك مشكلة صغيرة وهو أنه عندما تتمدد القائمة الرئيسية فإنها سوف تتداخل مع القائمة الفرعية وهو ما لا نريده بكل تأكيد، ولذلك سوف نحتاج إلى تعديل الأمور قليلًا. يمكنك الآن رؤية واحدة من المشاكل/القيود في CSS2، فسوف نحتاج الآن إلى كتابة العديد من الأكواد الخاصة بقيم العناصر المتموضعة بشكل ثابت، ونتيجة لذلك فسوف نحتاج إلى تعريف classes باسم "expanded" إضافية حتى نسمح للعناصر الأخرى بأن تتموضع لاستيعاب القائمة الرئيسية عندما تتمدد، وبذلك سوف نحتاج إلى كتابة المزيد والمزيد من الأكواد الإضافية. #subnav { left: 6em; width: 13em; &.expanded { left: 11em; /* تحريكها لليمين */ } } #main { margin: 6em 0 4em 20; z-index: 10; &.expanded { margin-left: 25em; /* تحريكها لليمين */ } }سوف نحتاج أيضًا إلى إضافة أكواد جافاسكربت إضافية لإضافة أو إزالة الـclass "expanded" لتلك العناصر عندما يقوم المستخدم بالنقر على القائمة الرئيسية. $('.layout-classic #nav').on('click', 'li.nav-toggle', function() { $('#nav, #subnav, #main').toggleClass('expanded'); });سيكون كل شيء أفضل الآن. 5. اختلافات تخطيط الصفحة باستخدام تقنيات CSS2كنا قد ذكرنا مسبقًا بأنّ بعض الصفحات لن تحتوي على قائمة فرعية. ولنكون أكثر دقة فإننا نريد للقائمة الفرعية أن تختفي عندما يضغط المستخدم على أيقونة "المستخدمين" (users) الموجودة في القائمة الرئيسية. سوف نبدأ أولًا بإنشاء class بالاسم "hidden" وفيه الخاصية display: none: hidden { display: none; }كما أننا سنستخدم الجافاسكربت لإخفاء القائمة الفرعية وذلك عن طريق تطبيق الفئة "hidden" على هذه القائمة عندما يقوم المستخدم بالنقر على أيقونة "المستخدمين" (users): $('#nav.fa-user').on('click', function() { $('#subnav').toggleClass('hidden'); });وبهذا يمكن للعناصر أن تختفي عند النقر على أيقونة "المستخدمين" ولكن المساحة التي كانت تحتلها سوف تبقى غير مستخدمة بدلًا من أن تقوم العناصر الأخرى باستخدام تلك المساحة. وحتى نحصل على السلوك المطلوب عندما نقوم بإخفاء القائمة الفرعية فإننا سوف نستخدم المحدد المجاور(adjacent sibling selector) وهو يأتي على شكل إشارة الجمع +. 6. المحدد المجاوريُستخدم المحدد المجاور لتحديد عنصرين واختيار العنصر الثاني الذي يأتي مباشرة بعد العنصر الأول. فعلى سبيل المثال، سيقوم الكود التالي باختيار العنصر الذي يحمل ID بقيمة main والذي يأتي مباشرة بعد العنصر الذي يحمل ID بقيمة subnav: #subnav + #main { margin-left: 20em; }استخدمنا الكود في الأعلى لإعطاء العنصر main# الخاصية margin-left: 20em فقط إذا كان هذا العنصر يأتي مباشرة بعد العنصر subnav#. ولكن عندما يتمدد العنصر nav# (بحيث يتم إضافة الفئة expanded إلى العنصر main# بناءً على الكود الذي كتبناه سابقًا) فإننا نريد للخاصية margin-left أن تحتوي على القيمة 25em. #subnav + #main.expanded { margin-left: 25em; }وأمّا إذا كانت القائمة الفرعية subnav# مخفية فإننا نريد للخاصية margin-left الخاصة بالعنصر main# أن تحتوي على القيمة 6em: #subnav.hidden + #main { margin-left: 6em; }ملاحظة: واحدة من مساوئ استخدام المحدد المجاور هو أن الـDOM سوف يحتوي دائمًا على العنصر subnav# حتى لو كان غير ظاهر في الصفحة. وأخيرًا، إذا كان العنصر subnav# مخفيًا وnav# متمددًا فإننا نريد الخاصية margin-left للعنصر main# بأن تكون بالقيمة 11em: #subnav.hidden + #main.expanded { margin-left: 11em; }خاتمةكل شيء إلى الآن يظهر في مكانه الصحيح من دون الحاجة إلى استخدام أكواد جافاسكربت كثيرة، ولكن يمكنك ملاحظة أن الكود يمكن أن يكون كبيرًا ومعقدًا إذا ما أردنا إضافة المزيد من العناصر إلى الصفحة. لاحظ أيضًا أنّه باستخدام CSS2 سيكون هناك الكثير من الأكواد لموضعة كل شيء في مكانه المناسب. لذلك سوف نقوم في الدرس القادم باستخدام بعض تقنيات CSS3 الجديدة وإعادة تخطيط الصفحة باستخدام تلك التقنيات. ترجمة -وبتصرّف- للمقال CSS Layout Tutorial: From Class+ic Approaches to the Latest Techniques لصاحبه Laureano Martin Arcanio.
  22. إن الهدف من إعداد وتجهيز المخططات الهيكلية (Wireframes) لمواقع الإنترنت هو حلّ مشاكل التصميم المُرتبطة بتخطيط وتصميم الصّفحة، وترتيب عناصرها، وذلك عبر ابتداع تصوّر للموقع قبل تطويره، وذلك باستخدام جملة من المُمارسات والمبادئ. إن تطبيق مبادئ جشطلت (Gestalt) على العناصر، سيُساعد على تحضير الأفكار بسرعة، فالفكرة من الأساس من العمل على هذا المُستوى من الجودة هو السرعة الّتي تُمكن المُصمّم من اكتشاف الأفكار بدرجة معقولة من الدقّة. تعلّمتُ بعض الطُرق المُفيدة في السنوات الأخيرة، جعلت مني أعمل بإنتاجيّة أكبر مع الحفاظ على الجودة، وبطبعي أكره كتابة عناوين من نوع" أفضل الحيل مع تصاميم المخططات الهيكلية" ولكن بعد عملي مع مُصممين قليلي الخبرة، وجدت أنّ بعض هذه المواضيع تحدث بشكل متكرّر ومن الضروري الإشارة إليها. 1. كل شيء مهم وذو معنى كل تلوين، كل خطّ، كل ظل، كل تدرّج لوني، كل شيء يَهم وله معنى، فاستخدام حواف وإطارات غير متقطّعة (solid)، وخلفيّة ملوّنة، وظلالًا، قد يكون أمرًا لا لزوم لها، خاصّة أنّ هذه العناصر يُمكن أنّ تنتقل إلى مرحلة التصميم والتطوير، وبدون أنّ يُفكّر بها مليًّا، فيجب على كل شيء أنّ يكون له معنى، وأنّ لا تُدرج العناصر والرسومات هنا وهناك اعتباطيًّا. الانسجام يُساعد يجدر الانتباه عند استخدام الرسم التمهيدي (sketching) هو أنّ التلوين والخطّ موحد في كامل الرسم (يعني، وجوب تبديل القلم المُستخدم، أو تغيير خطّ اليد من أجل إبراز الاختلاف)، بالإضافة إلى تتكرّر مُشكلة مع المخططات الهيكلية وهي الاختلاف في تدرجات الألوان وعمق السطور والخطّ المُستخدم، جميعها يُدرج ويُستخدم بدون تفكير، الأمر الّذي يجعل من المخطط الهيكلي صعب الفهم والقراءة، ويجعل مني أتساءل في معظم الأحيان: هل التغيير من الخط المُستخدم هنا متعمّد؟ هل هذه الرقعة (label) هي أكبر حجمًا لأنّها أكثر أهميّة؟ وغيره من هذه الأسئلة، ولتجنب هذه المشكلة، من المُستحسن استخدام مجموعة محدّدة من الألوان، (ربّما من 3-5 من اللون الرمادي) ونوعين من الخطوط، واستخدام عناصر HTML الافتراضيّة، مع العلم أنّ هذا قد يؤدي إلى مخططات هيكلية باهتة، ولكن يجب أنّ يُعلم أنّ جميع المخططات الهيكلية ينتهي الأمر بها إلى سهلة المهملات، فليس الغرض منها إبهار الزوّار، إنما الغرض هو تصميم برمجيّة قابلة للاستخدام، أمّا المخطط الهيكلي الخلّاب فهو مضيعة للوقت. إن من الأمور المُهمّة الّتي يجب التركيز عليها هي نقطة الانطلاق، فالبدء مع خطّ أسود، يعني إمكانيّة تكبير وتعريض الخط فقط، الأمر الّذي قد يؤدي إلى جعل المخطط الهيكلي صارخ وحاد بالنسبة لبقيّة الأجزاء، ولكن البدء مع خطّ رمادي، يسمح للمُصمّم بزيادة العمق اللوني وتخفيفه بطبيعة الحال. السرعة والاستكشاف إن الغرض من التصميم ذو الدقّة المُنخفضة ليس التلوين والتحسين، ولكن الغرض هو استكشاف الحلّ الأنسب، حيثُ سيظهر العديد من الحلول، وفقط عن طريق استكشاف بعضها، وصفهم أمام الأعين سيمكّن المُصمّم من التقرير أيها سيَعمل بالشكل الأمثل للمشروع، لقد شرح كانيد بولز كيف يواجه لاعبي الشطرنج تحديًّا مُشابهًا، حيثُ في بداية اللعب، يوجد الكثير من الخيارات، بعضها يُمكن استبعاده عن طريق الغريزة أو عبر الخبرة والممارسة، وتُستكشف باقي الحلول ذهنيًّا، ولذلك سيُعجب المُصمّمون المبتدؤون بفكرتهم الأولى، ويتعلّقون بها ويبذلون جهدًا كبيرًا في تنفيذها مهما تتطلّب الأمر، ولقد وصفَ آندي روتلدج هذه الظاهرة بظاهرة "ملك الخواتم" وذلك في مقالة أكثر من رائعة بعنوان "كنزي العزيز". إن لم يكن بالإمكان تنفيذ التصوّر بسرعة، إذًا فإن التنفيذ يتمّ على الدقّة الخاطئة، فإن كان المخطط الهيكلي يعمل على تقديم نسخة ذات التدرّج الرمادي (grayscale) فقط مما قد تقرّر بناؤه بالفعل، فذلك مضيعة للوقت. النسخة المُطابقة تعطي نتائج أكثر واقعيّة تصدر الأخطاء عادةً من المُصممين الذين ليس لديهم تصوّر مُسبق للمحتوى، فإن كان المشروع يتضمّن معرضًا للصور، فمن المفترض رؤية الصور قبل اتخاذ القرار في إدراجها، والاهتمام بها كميّزة رئيسيّة أو عدم إبرازها لعدم أهميتها، وبشكل مُشابه، إن كان التصميم مبني بالأساس لعرض البيانات، فيجب معرفة ماهيّة هذه البيانات، مع العلم أنّ استخدام البيانات الوهميّة في التصميم الأوّلي تَدفع بالمُصمّم إلى تصاميم مخططات هيكلية تكون فيها العناوين والنصوص مُتناسقة بمثاليّة كبيرة، والصور مُتجاوبة مع التصميم ككل، والأرقام مُلائمة داخل صناديق صغيرة لا تتخطاها، طبعًا هذا أبعد ما يكون عن الواقع، بعبارة أخرى، إن هلاك واجهة المُستخدم يبدأ بالعنوان "لوريم أيبسزم". يجب إتقان التقنيّة المُستخدمة يُمكن للتصميم الخلّاب أنّ يُقدّم حلًّا سيّئًا للمشروع، فإن كان التصميم يتضمّن عناصر HTML مخصّصة، وأزرارًا جذّابة وقوائم مُنسدلة، وحقل بحث ديناميكي بتقنيّة أجاكس، فمن الضروري على المُصمّم أنّ يدرك أنّ لكل مشروع ميزانيّة مُختلفة عن الآخر، وخاصّة إن كان المُصمّم يعرف أساسيّات HTML و CSS و جافا سكريبت، فهو بالتأكيد يعرف ما يُتطلّب لاختبار هذه العناصر على المُتصفحات، وبالتالي على المُصمم أنّ يفكّر مليًّا فيما يُدرج في المخطط الهيكلي، طبعًا قد لا يكون هذا العنصر بذلك التعقيد، وقد يكون متوفّرًا في مكتبة jQuery، ولكن على المصمم أنّ يدرك أنّه لا يوجد شيء يدعى "مجرّد تعديل بسيط"، طبعًا هذا لا يعني عدم إدراج عناصر تفاعليّة في المخطط الهيكلي، ولكن يجب على المُصمم دائمًا معرفة تكلفة كل عنصر يُدرج في التصميم، فبعض المواقع قد تتطلّب هذا النوع من التعقيد، فمثلًا الاهتمام في عنصر اختيار التاريخ قد يكون أمرًا جوهريًا ومطلب أساسي في بعض المواقع، ومن المنطقي جدًا التركيز عليه، ولكن عندما يكون عنصر اختيار التاريخ من أجل "تاريخ الميلاد"، فمن الأفضل استغلال هذا الوقت على أمرٍ أكثر أهميّة فليعمل ما يعمل إن الهدف الرئيسي هو تقديم شيء عمليّ، وليس شيء مثالي، فلا يُبهر بالجماليّات سوء مُصمّمي تجربة المُستخدم UI، بمعنى إن تمّ الرسم والتخطيط باستخدام الورق فقط وبخط اليد، وكان المُصمّم واثقًا من تقديم الحلّ المطلوب، وذلك بتوافق تصميمه مع البيانات المعُطاة من قبل العميل، وكان هذا الرسم رسمًا واضحًا لجميع فريق العمل، فإذًا لا قيمة من إعادة تمثيل هذا الرسم باستخدام المخطط الهيكلي، بمعنى آخر على المُصمّم أنّ يكون عمليًّا، وأن يهتم بتقديم المطلوب وأن يَبتعد عن تصميم تصميمات مثاليّة . مصادر إضافيّةإن جميع المواضيع السابقة هي من واقع الخبرة ونتاج طويل من والتجربة والخطأ، ولتكتمل الصورة، هذه بعض المقالات الهامّة، والّتي ترتبط بالموضوع بشكل مُباشر وغير مُباشر: هيكلة وتوزيع محتوى صفحات الويب.ما هو النّظام اللّوني.أساسيات الوزن البصري في التّصميم الجرافيكي.الاختلافات ما بين التصاميم المسطّحة (flat design) و التصاميم المادية (material design).مدخل إلى عالم الخُطوط.مصادر أجنبية: Gestalt Principles – Andy Rutledge.Good design faster – Leah Buley.Sketching User Experiences – Bill Buxton.ترجمة وبتصرّف للمقال Wireframing for Web Apps.
  23. لقد أصبح Nginx أحد أكثر التطبيقات البرمجية المتوفرة لخواديم الويب Web Servers مرونةً وقوة. ولكن إذا ما نظرنا إليه من الناحية التصميمية فإنه يعد أولًا وقبل كل شيء خادومًا وسيطا Proxy Server. إن التركيز على أداء Nginx كوسيط يعني أنه ذو أداء عالي عندما يعمل على معالجة الطلبات بالتعاون مع خواديم أخرى. يمكن لـ Nginx أن يلعب دور الوسيط باستخدام بروتوكولات Protocols http ,FastCGI ,uwsgi ,SCGI ,memcached. سنناقش في هذه المقالة استخدام FastCGI للقيام بالوساطة proxying، فهو يعد واحدًا من أكثر البرتوكولات التي تُستخدم لذلك الغرض. لماذا نستخدم FastCGI للقيام بالوساطة؟يستخدم FastCGI للقيام بالوساطة ضمن Nginx كي يترجم طلبات المستخدمين Clients لخادوم التطبيقات Application Server الذي لا يقوم بمعالجة طلبات المستخدمين مباشرةً أو الذي لا ينبغي له ذلك. إنّ FastCGI هو برتوكول مبني على برتوكول Common Gateway Interface الأقدم والذي يشار إليه اختصارًا CGI، وقد أُريد من بروتوكول FastCGI أن يحسّن أداء البروتوكول السابق عبر عدم معالجة كل طلب في عملية Process خاصة به. يُستخدم البرتوكول ليمثّل واجهة interface ذات فعالية أكبر مع الخواديم التي تعالج طلبات المحتوى الديناميكي. إن معالجة PHP هي أحد حالات الاستخدام use-case الرئيسية لبرتوكول FastCGI ضمن Nginx. وعلى عكس أباتشي Apache، الذي يستطيع معالجة PHP مباشرةً باستخدام وحدة mod_php، فإنه ينبغي على Nginx الاعتماد على معالج PHP منفصل لمعالجة طلبات PHP. غالبًا ما تُنجز تلك المعالجة باستخدام php_fpm وهو معالج PHP قد اختبر بشكل كبير للعمل مع Nginx. يمكن أن يُستخدم Nginx مع FastCGI للعمل مع تطبيقات تستخدم لغاتٍ أخرى طالما أنه يتوفر مكونات مهيّأة للاستجابة لطلبات FastCGI. أسياسيات قيام FastCGI بالوساطةعادةً ما تتضمن طلبات الوساطة proxying requests عنوان الخادوم الوسيط- Nginx في حالتنا- الذي يوجّه الطلبات من قبل المستخدمين إلى الخادوم الوسيط بينه (الخلفي) Backend Server. يستخدم Nginx التعليمة fastcgi_pass للتعريف عن الخادوم الفعلي الذي ستوجّه إليه الطلبات باستخدام برتوكول FastCGI. فمثلًا، لتوجيه أي طلب موافق للغة PHP إلى الخادوم الخلفي المخصص لمعالجة PHP باستخدام برتوكول FastCGI، فقد يبدو المقطع البرمجي للموقع Location Block مشابهًا لما يلي: # server context location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; } . . . في الواقع، لن يعمل المقطع السابق إذا ما تم تنفيذه على حاله لأنه يقدّم معلوماتٍ قليلةً جدًا. في كل مرّة يتم فيها إنشاء اتصال وسيط Proxy Connection فإنه يجب ترجمة الطلب الأصلي لضمان أن يتمكن الخادوم الخلفي من فهم الطلب المُدار Proxied request. وباعتبار أننا نغيّر البرتوكولات بتمرير الطلب عبر FastCGI فإن ذلك يتطلب بعض العمل الإضافي، سنصطلح في هذه المقالة على عملية تمرير الطلبات عبر FastCGI بتمرير FastCGI أي FastCGI pass. إنّ القيام بالوساطة من بروتوكول Http وإليه http-to-http Proxying ينطوي بشكل رئيسي على زيادة حجم الترويسة Header ليضمن أن يمتلك الخادوم الخلفي المعلومات التي يحتاجها للرد على الخادوم الوسيط والذي ينوب بدوره عن المستخدم Client، أما FastCGI فهو برتوكول منفصل لا يستطيع قراءة ترويسات Http. مع أخذ ذلك بالحسبان فإن أية معلومات ذات صلة يجب أن تمرّر للخادوم الخلفي عبر وسيلة أخرى. إن الطريقة الأساسية لتمرير المعلومات الإضافية عند استخدام برتوكول FastCGI هي باستخدام الإعدادات Parameters. حيث يجب أن يُهيّئ الخادوم الخلفي لقراءة تلك الإعدادات ومعالجتها والتصرّف وفقًا لقيمها. يستطيع Nginx أن يحدّد إعدادات FastCGI باستخدام التعليمة fastcgi_param. إن الحد الأدنى للإعدادات الواجب ضبطها حتى يعمل FastCGI كوكيل PHP مشابهة لما يلي: # server context location ~ \.php$ { fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; } . . . لقد قمنا في الإعدادات السابقة بضبط إعدادات FastCGI وهما REQUEST_METHOD و SCRIPT_FILENAME. إن كل من الإعدادات السابقة ضرورية للخادوم الخلفي حتى يتمكن من فهم طبيعة الطلب. إذ أن الإعداد الأول يخبره بنوع العملية التي يجب أن يقوم بإنجازها، أما الإعداد الثاني فيخبر مجموعة الخواديم Upstream - التي تعالج طلبات الخادوم الوسيط- بالملف الذي يجب أن ينفّذه. استخدمنا في المثال بعض المتغيرات variables في Nginx لضبط قيم تلك الإعدادات. سيحوي المتغير request_method$ على نوع الوظيفة http method التي طلبها المستخدم. من ناحية أخرى فإن قيمة الإعداد SCRIPT_FILENAME هي عبارة عن دمج قيمتي المتغيرين document_root$ و fastcgi_script_name$. أما المتغير document_root$ فسيحوي على مسار المجلد الرئيسي والذي ضبط عبر التعليمة root. سيضبط المتغير fastcgi_script_name$ بمعرف الموارد الموحد URI المطلوب. إن انتهى معرف URI للطلب request URI بالرمز (/)، فستلحق قيمة التعليمة fastcgi_index في النهاية. إن هذا النوع من المرجعية الذاتية self-referential في تعريف الموقع ممكن لأننا نشغّل معالج FastCGI على نفس الجهاز الذي يشغّل Nginx. فلنلقي نظرة على مثال آخر: # server context root /var/www/html; location /scripts { fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_index index.php; fastcgi_pass unix:/var/run/php5-fpm.sock; } . . .إن اختير الموقع location في المثال السابق ليعالج طلبًا في المسار: /scripts/test/ فإن قيمة المسار الوسيط SCRIPT_FILENAME ستنتج عن دمج قيم تعليمة root ومعرّف URI للطلب بالإضافة للتعليمة fastcgi_index. وبالتالي ستكون قيمة الإعداد في مثالنا هذا هي: var/www/html/scripts/test/index.php/ هنالك تعديل هام آخر قمنا به في الإعدادات السابقة، إذ أننا ضبطنا خادوم FastCGI الخلفي FastCGI backend ليستخدم مقبس يونيكس Unix Socket عوضًا عن مقبس شبكة Network socket. يمكن لـ Nginx أن يستخدم أيًا من الواجهتين Interface ليتصل مع مجموعة خواديم FastCGI Upstream. إن كان معالج FastCGI يعمل على نفس الخادوم فعادةً ما يُستحسن استخدام مقبس يونيكس من أجل الأمان. شرح إعدادات FastCGIهنالك قاعدة أساسية لكتابة نص برمجي (كود) Code قابل للصيانة وهي محاولة اتباع مبدأ DRY أي لا تكرر نفسك "Don’t Repeat Yourself". يساعد ذلك في تقليل الأخطاء بالإضافة لجعل الكود قابلًا لإعادة الاستخدام كما أنها تتيح تنظيمًا أفضل. إنّ أحد أكثر التوصيات الأساسية لإدارة Nginx هي أن تُضبط كل الأوامر في أوسع مجال ممكن لها، تطبّق تلك الأهداف الأساسية على إعداداتNginx أيضًا. عند التعامل مع إعدادات الوسيط لـ FastCGI فسيتم تشارك الغالبية العظمى للإعدادات في معظم حالات الاستخدام. بسبب ذلك وبسبب الطريقة التي تعمل بها وحدة الوراثة inheritance التابعة لـ Nginx فإنه دائمًا ما يستحسن تعريف الوسطاء في مجال عام. التصريح عن تفاصيل إعدادات FastCGI في السياقات الأم Parent Contextsإن أحد الطرق لتقليل التكرار هو التصريح عن تفاصيل الإعدادات في السياق الأم، أي سياق أعلى. يمكن لكل الإعدادات الموجودة خارج التعليمة fastcgi_pass أن تُضبط في مستويات أعلى. إذ أنها ستتدفق للأسفل نحو الموقع الذي تم منه تمرير الإعداد. وذلك يعني أنّه يمكن لعدّة أماكن أن تستخدم نفس الإعدادات. فمثلًا، يمكننا أن نعدّل على القسم العلوي من المقطع البرمجي السابق لجعله مفيدًا في عدة مواقع: # server context root /var/www/html; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_index index.php; location /scripts { fastcgi_pass unix:/var/run/php5-fpm.sock; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; } . . .إنّ كلًا من تصاريح fastcgi_param والتعليمة fastcgi_index في المثال السابق متوفرين لدى مقطعي الموقع location block الواردين لاحقًا. تلك هي إحدى الطرق لإزالة التكرار. بكل الأحوال، إن للإعدادات السابقة مساوئ كبيرة، إن صُرّح عن أية fastcgi_param ضمن سياق أدنى فلن تتم وراثة أيٍّ من قيم fastcgi_param ضمن السياقات العليا (السياقات الأم). أي إما أن تستخدم القيم الموروثة فقط أو لا تستخدم أيًا منها. تُعد التعليمة fastcgi_param مصفوفةً array من التعليمات في لغةNginx. من منظور المستخدمين فإن أي مصفوفة تعليمات هي بشكل أساسي تعليمة يمكن استخدامها أكثر من مرة ضمن سياق واحد. وأي تصريح لاحق سيضيف معلومات جديدة إلى ما يعرفه Nginx من التصريح السابق. لقد صمّمت التعليمة fastcgi_param كمصفوفة من التعليمات حتى تسمح للمستخدمين بضبط عدّة إعدادات. تورّث أي مصفوفة تعليمات إلى سياق أدنى، أو سياق ابن child context، بطريقة مختلفة عن بعض التعليمات الأخرى. ستورّث معلومات مصفوفة التعليمات إلى سياقات الأبناء فقط إن لم تكن موجودة في أي مكان ضمن سياق الابن. وذلك يعني أنك إن استخدمت تعليمة fastcgi_param ضمن موقعك فإنها ستمحي القيم الموروثة من السياق الأعلى تمامًا. فمثلًا، يمكننا التعديل قليلًا على الإعدادات السابقة كما يلي: # server context root /var/www/html; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_index index.php; location /scripts { fastcgi_pass unix:/var/run/php5-fpm.sock; } location ~ \.php$ { fastcgi_param QUERY_STRING $query_string; fastcgi_pass 127.0.0.1:9000; } . . .قد تعتقد للوهلة الأولى أنه ستتم وراثة الإعدادات REQUEST_METHOD و SCRIPT_FILENAME في مقطع لموقع ثانٍ، بالإضافة لتوفير الإعداد QUERY_STRING ضمن ذلك السياق المحدّد. لكن ما يحدث في الحقيقة هو أنّ كل قيم fastcgi_param التابعة للأب ستُمحى ضمن السياق الثاني، وسيضبط الإعداد QUERY_STRING فقط. بينما ستبقى الإعدادات REQUEST_METHOD و SCRIPT_FILE دون ضبط. ملاحظة حول القيم المتعدّدة للوسطاء ضمن نفس السياقيجدر بالذكر هنا أثار ضبط قيم متعدّدة لنفس الإعدادات ضمن سياق واحد. فلنأخذ المثال التالي لمناقشة ذلك: # server context location ~ \.php$ { fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $request_uri; fastcgi_param DOCUMENT_ROOT initial; fastcgi_param DOCUMENT_ROOT override; fastcgi_param TEST one; fastcgi_param TEST two; fastcgi_param TEST three; fastcgi_pass 127.0.0.1:9000; } . . .في المثال السابق، قمنا بضبط الإعدادات TEST و DOCUMENT_ROOT عدّة مرات ضمن سياقٍ واحد. باعتبار أن fastcgi_param مصفوفة تعليمات فإن كلّ تصريح لاحق سيُضاف إلى سجلات Nginx الداخلية. سيحظى الإعداد TEST بعدة تصاريح ضمن المصفوفة يضبط من خلالها بالقيم one و two و three. من المهم أن ندرك هنا أنّ كلّ ذلك سيمرّر إلى خادوم FastCGI الخلفي دون أي معالجة إضافية من Nginx. يعني ذلك أنّ القرار حول كيفية معالجة تلك القيم يعود بشكل كامل إلى معالج Nginx المختار. للأسف، على اختلاف معالجات FastCGI فإن كلًا منها يعالج القيم الممرّرة بطريقة تختلف تمامًا عن الأخرى. فمثلًا، إن استقبلت PHP-FPM الإعدادات السابقة فستفسر القيم النهائية لتحل محل أي قيم سابقة. بهذه الحالة سيُضبط الإعداد TEST بالقيمة three. وبالمثل سيضبط الإعداد DOCUMENT_ROOT بالقيمة override. ولكن إن مُرّرت القيم السابقة لخادومٍ مثل FsgiWrap، فستفسَّر القيم بشكل مختلف كثيرًا. ففي البداية سيقوم بتمرير تمهيدي ليقرر أي القيم ينبغي استخدامها لتشغيل البريمج script. وسيستخدم القيمة initial للإعداد DOCUMENT_ROOT ليبحث عن البريمج. إلا أنه عندما سيمرّر القيم الفعلية للبريمج فسيمرر القيم الأخيرة كما يفعل PHP-FPM تمامًا. إن التضارب inconsistency وعدم إمكانية التنبؤ unpredictability يعني أنك لا تستطيع، بل أنه لا ينبغي لك، أن تعتمد على الخادوم الخلفي لتفسير نيّتك بشكل صحيح إذا ما ضبطّت الإعدادات أكثر من مرّة واحدة. فالطريقة الوحيدة الآمنة هي بالتصريح عن كل إعداد مرّةً واحدة. يعني ذلك أيضًا أنه لا يوجد طريقة آمنة لإعادة تعريف overriding القيمة الافتراضية باستخدام تعليمة fastcgi_param. طريقة تضمين إعدادات مكتوبة بملف منفصل ضمن ملف إعدادات FastCGI الأساسييوجد طريقة أخرى لتفصل بنود إعداداتك الشائعة، أي التي تقوم بها بشكل متكرّر. بإمكاننا استخدام تعليمة include لقراءة محتوى ملف منفصل وتضمينها في الموقع الذي تم فيه التصريح عن التعليمة. يعني ذلك أنه بإمكاننا الاحتفاظ بكل الإعدادات الشائعة في ملف واحد ومن ثمّ تضمينه في أي مكان ضمن إعداداتنا إن اقتضى الأمر. وباعتبار أن Nginx سيضع محتوى الملف حيثما وجدت تعليمة include فلن نكون قد ورثنا من سياق الأم إلى سياق الابن. سيمنع ذلك قيم fastcgi_param من أن تُمحى وسيمنحنا القدرة على ضبط إعدادات إضافية عند الحاجة. يمكننا في البداية أن نضبط قيم إعدادات FastCGI الشائعة لدينا في ملف منفصل وتخزينه ضمن المسار الحاوي على ملف الإعدادات الأصلي، سنقوم بتسمية ذلك الملف fastcgi_common: fastcgi_param REQUEST_METHOD $request_method; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;يمكننا الآن أن نستورد محتوى الملف حيثما نريد استخدام قيم تلك الإعدادات: # server context root /var/www/html; location /scripts { include fastcgi_common; fastcgi_index index.php; fastcgi_pass unix:/var/run/php5-fpm.sock; } location ~ \.php$ { include fastcgi_common; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_index index.php; fastcgi_pass 127.0.0.1:9000; } . . . لقد قمنا هنا بنقل قيم بعض الإعدادات الشائعة إلى ملف اسمه fastcgi_common والموجود في المسار الافتراضي الحاوي على إعدادات NGINX. ثمّ نستورد القيم المصرّح عنها في الملف عندما نحتاج لإدخالها. هنالك العديد من الأمور التي يجب ملاحظتها حول هذه الإعدادات: أولًا، لم نضع في الملف الذي ننوي استيراده أي قيم قد نرغب بتخصيصها وفقًا لموقعه، بسبب مشكلة التفسير التي ذكرناها سابقًا والتي تحدث عندما نضبط عدة قيم لنفس الإعداد، ولأنه لا يمكن ضبط التعليمات التي ليست على شكل مصفوفة non-array directives إلا مرّةً واحدة خلال السياق، لذا نضع العناصر التي لن نرغب بتغييرها فقط في الملف المشترك. إنّ كلّ تعليمة (أو إعداد أساسي) قد نرغب بتخصيصه وفقًا لموقعه يجب ألا يضمّن في الملف المشترك. الأمر الآخر الذي ربما قد لاحظته أننا قد ضبطنا بعض إعدادات FastCGI الإضافية في المقطع البرمجي للموقع الثاني. وتلك هي الإمكانية التي كنا نأمل الوصول إليها. تمكّنا من إضافة إعدادات fastcgi_param إضافية كلما اقتضت الحاجة ومن دون أن تُمسح القيم المشتركة. استخدام الملف fastcgi_params أو الملف fastcgi.confبأخذ الاستراتيجية السابقة بالحسبان فإن مطوري Nginx والعديد من فرق تحزيم التوزيعات distribution packaging teams قد عملوا على توفير مجموعة من الإعدادات شائعة الاستخدام والتي يمكن أن تضمنها في مواقع تمرير FastCGI أي FastCGI pass location. تدعى تلك الإعدادات fastcgi_params أو fastcgi.conf. إنّ هذين الملفين متشابهين كثيرًا ولكن مع وجود اختلاف وحيد ممثّل في تمرير قيم متعدّدة لإعداد واحد، وهي المشكلة التي ناقشناها سابقًا، لا يحتوي fastcgi_params على تصريح عن الإعداد SCRIPT_FILENAME على عكس الملف fastcgi.conf. لقد أوجِد الملف fastcgi_params منذ وقتٍ أبعد. ثم ظهرت الحاجة لإنشاء ملف جديد عندما اتُّخذ قرارٌ لتوفير قيمةٍ افتراضية للإعداد SCRIPT_FILENAME وذلك حتى نتجنب تجزئة الإعدادات التي تعتمد على fastcgi_params، إن عدم فعل ذلك قد يؤدي إلى ضبط ذلك الإعداد في كل من الملف المشترك وموقع تمرير FastCGI. العديد من مشرفي تحزيم التوزيعات الشهيرة قد صوّتوا لتضمين إحدى هذين الملفين فقط أو لتطابق محتواهما تمامًا. إن توفّر لديك أحد هذين الملفين فقط فاستخدمه وعدّل عليه كما تشاء ليناسب احتياجاتك. إن كان كلا الملفين متوفرين لك، فقد يكون من الأفضل أن تضمّن الملف fastcgi.conf في معظم مواقع تمرير FastCGI، وذلك لأنه يتضمّن تصريحًا عن الإعداد SCRIPT_FILENAME. عادةً ما يُرغب بذلك إلا أنّ هنالك بعض الحالات التي قد ترغب فيها بتخصص هذه القيمة. يمكن تضمين هذين الملفين عبر الإشارة إلى موقعهما بالنسبة إلى المجلد الجذر root الحاوي على إعدادات Nginx. إن مسار المجلد الجذر لإعداداتNginx يكون مشابهًا لما يلي: etc/nginx/ وذلك إن تم تثبيته باستخدام مدير الحزم package manager. يمكنك تضمين الملفين كما يلي: # server context location ~ \.php$ { include fastcgi_params; # You would use "fastcgi_param SCRIPT_FILENAME . . ." here afterwards . . . }أو كما يلي: # server context location ~ \.php$ { include fastcgi.conf; . . . }تعليمات وإعدادات ومتغيرات FastCGI المهمّةلقد قمنا في القسم السابق بضبط عدد لا بأس به من الإعدادات بهدف شرح مفاهيمٍ أخرى، وعادةً ما كنا نضبطها بمتغيرات Nginx. كما أننا قدمنا بعض تعليمات FastCGI من دون شرحٍ وفير. سنناقش في هذا القسم بعض التعليمات شائعة الضبط، وبعض الإعدادات التي قد تحتاج لتعديلها، بالإضافة لبعض المتغيرات التي قد تحوي معلوماتٍ تحتاجها. تعليمات FastCGI الشائعة:سنستعرض فيما يلي بعض أكثر التعليمات المفيدة للعمل مع تمريرات FastCGI: fastcgi_pass: هي التعليمة التي تقوم بعملية تمرير الطلبات الموجودة ضمن السياق الحالي إلى الخادوم الخلفي. تعرٍّف هذه التعليمة الموقع الذي يمكن الوصول عبره إلى معالج FastCGI.fastcgi_param: وهي مصفوفة التعليمات التي يمكن استخدامها لضبط قيم الإعدادات. غالبًا ما يقترن استخدام هذه التعليمة مع متغيرات Nginx لضبط وسطاء FastCGI بالقيم المحدّدة في الطلب.try_files: ليست تعليمةً خاصة بـ FastCGI، إلا أنها استخدامها شائع في موقع تمرير FastCGI، عادةً ما تستخدم كجزء من إجراء الطلب الوقائي للتأكد من وجود الملف المطلوب قبل تمريره إلى معالج FastCGI.include: مجدّدًا، ليست تعليمةً خاصة بـ FastCGI، إلا أنها تستخدم بكثافة عالية في سياقات تمرير FastCGI أي FastCGI pass contexts. غالبًا ما تستخدم لتضمين تفاصيل الإعدادات الشائعة والمشتركة بين عدّة مواقع.fastcgi_split_path_info: تستخدم هذه التعليمة لتعريف التعابير النمطية regular expression مع مجموعتي التقاط captured groups. تُستخدم المجموعة الأولى كقيمة للمتغير fastcgi_script_name$ بينما تستخدم المجموعة الثانية كقيمة للمتغير fastcgi_path_info$. عادةً ما تستخدم كلا المجموعتين لتحليل parse الطلب بشكل صحيح حتى يعرف المعالج أي الأجزاء المشكّلة للطلب تمثل الملفات الواجب تشغيلها وأي الأجزاء تمثل المعلومات الإضافية الواجب تمريرها إلى السكربت.fastcgi_index: تعرّف هذه التعليمة ملف الفهرسة index file الذي ينبغي الحاقه بقيمة الإعداد fastcgi_script_name$ والتي تنتهي بـ (/.عادةً ما يكون ذلك مفيدًا إن كان الإعداد SCRIPT_FILENAME مضبوطًا بقيمة document_root$fastcgi_script_name$ وكان مقطع الموقع معدّا لقبول الطلبات الحاوية على معلومات المسار الإضافية.fastcgi_intercept_errors: تعرّف هذه التعليمة فيما إذا كان ينبغي معالجة الأخطاء المتلقاة من خادوم FastCGI أو تمريرها مباشرةً إلى المستخدم.تمثّل التعليمات السابقة أكثر التعليمات التي ستستخدمها عندما تصمّم تمرير FastCGI نموذجي. ومع أنك قد لا تستخدمها كلها بنفس الوقت، إلا أنك ستلاحظ أنها تتفاعل بشكل وثيق جدًا مع إعدادات ومتغيرات FastCGI التي سنتحدث عنها فيما يلي. المتغيرات شائعة الاستخدام مع FastCGI:قبل أن نتمكن من الكلام عن الإعدادات التي ستستخدمها على الأرجح مع تمريرات FastCGI، علينا الكلام قليلًا عن بعض نتغيرات Nginx الشائعة والتي ستستفيد منها في ضبط تلك الإعدادات. تعرّف وحدة FastCGI الخاصة بـ Nginx بـ Nginx’s FastCGI module بعض تلك المتغيرات، إلا أن معظمها من الوحدة الأساسية Core module. query_string$ أو args$: هي القيم الممرّرة arguments في الطلب الأصلي للمستخدم. is_args$: ستساوي قيمتها “?” إن حوى الطلب على قيم ممرّرة وإلا فستُضبط قيمتها بسلسلة نصية فارغة. يفيد ذلك عند إنشاء إعدادات قد تأخذ قيمًا أو لا تأخذ. request_method$: يشير هذا المتغير إلى نوع الطلب request method المستخدم الأصلي. يمكن أن يفيد ذلك بتحديد فيما إذا كان ينبغي السماح لعملية operation ما في السياق الحالي أم لا. content_type$: يضبط هذا المتغير بقيمة الحقل content-type الموجود في ترويسة الطلب. يحتاج الوسيط إلى هذه المعلومات إن كان نوع الطلب المستخدم هو POST وذلك حتى يتمكن من معالجة المحتويات اللاحقة بشكل صحيح. content_length$: يضبط هذا المتغير قيمة الحقل Content-Length الموجود في ترويسة المستخدم. هذه المعلومات لازمة لأي طلب للمستخدم من النوع POST. fastcgi_script_name$: يحتوي هذا المتغير على ملف السكربت الذي يجب تشغيله. إن انتهى الطلب بـ (/) فستحلق قيمة التعليمة fastcgi_index إلى النهاية. وبحال استخدام التعليمة fast_split_path_info فستضبط قيمة هذا المتحول بالمجموعة اللاقطة الأولى المعرّفة من قبل التعليمة. ينبغي على قيمة هذا المتغير أن تشير إلى الملف الفعلي الذي يجب تشغيله. request_filename$: يحتوي هذا المتغير على مسار الملف المطلوب. يحصل المتغير على هذه القيمة بأخذ المسار الحالي لمجلد المستندات الأساسي document root، مع أخذ كل من التعليمتين root و alias بعين الاعتبار. بالإضافة لأخذ قيمة المتغير fastcgi_script_name$. تعد هذه الطريقة مرنةً للغاية لإسناد قيمة للإعداد SCRIPT_FILENAME. request_uri$: يحتوي هذا المتغير على الطلب كاملًا كما استُقبل من المستخدم، يتضمّن ذلك السكربت، أية معلومات مسار إضافية، بالإضافة إلى أي عبارة استعلام query string. fastcgi_path_info$: يحتوي هذا المتغير على معلومات المسار الإضافية التي قد تتوفّر بعد اسم السكربت في الطلب. وقد تحوي قيمته أحيانًا على موقعٍ آخر ينبغي على السكربت أن يعلم به حتى يتم تنفيذه. يحصل هذا المتغير على قيمته من مجموعة التعابير النمطية regex الثانية عند استخدام تعليمة fastcgi_split_path_info. document_root$: يحتوي هذا المتغير على المسار الحالي لمجلد المستندات الأساسي. وسيتم ضبطه تبعًا لتعليمتي root و alias. uri$: يحتوي هذا المتغير على قيمة URI الحالية بعد تسويتها normalization. وبما أن تعليمات معينة تقوم بإعادة الكتابة rewrite أو بإعادة التوجيه الداخلي internallly redirect يمكن أن تترك أثرًا على معرّف URI فإن هذا المتغير سيستخلّص تلك التعديلات. كما ترى، يوجد العديد من المتغيرات المتوفّرة لك عندما تقرّر كيف تضبط إعدادات FastCGI. العديد منها متشابه إلا أنها تملك بعض الفوارق الصغيرة والتي ستنعكس على تنفيذ بريمجك. إعدادات FastCGI الشائعة:تمثّل إعدادات FastCGI المعلومات التي نرغب بجعلها متاحةً لمعالج FastCGI - الذي نرسل إليه الطلبات- على شكل أزواج مفتاح-قيمة key-value. لن تحتاج كلّ التطبيقات إلى نفس الإعدادات لذلك غالبًا ما ستحتاج لمراجعة توثيق التطبيق. تُعد بعض تلك الإعدادات ضروريةً للمعالج حتى يتمكن من تحديد السكربت - الذي ينبغي تشغيله- بشكل صحيح. بينما أُتيح البعض الآخر للسكربت، إذ أنها قد تغيّر سلوكه إن كان معدًّا ليعتمد على مجموعةٍ من الإعدادات. QUERY_STRING: ينبغي أن يُضبط هذا الإعداد بأي عبارة استعلام مقدّمة من قِبل المستخدم. عادةً ما تكون على شكل أزواج مفتاح-قيمة مزوّدةً بعد إشارة "?" في معرّف URI. عادةً ما يُضبط هذا الإعداد بقيمة أحد المتحولين query_string$ أو args$، إذ ينبغي عليهما أن يحويا على نفس البيانات. REQUEST_METHOD: يدّل هذا الإعداد معالجَ FastCGI على نوع الإجراء الذي طلبه المستخدم. وهو أحد الإعدادات القلائل التي يجب ضبطها حتى يتم التمرير بشكل صحيح. CONTENT_TYPE: إن ضُبط نوع الطلب في الإعداد السابق ليكون POST فيجب أن يُضبط هذا الإعداد. يشير هذا الإعداد إلى نوع البيانات التي ينبغي على معالج FastCGI توقعها. غالبًا ما يضبط هذا الإعداد بالمتغير content_type$ فقط، والذي يضبط بدوره وفقًا للمعلومات المأخودة من الطلب الأصلي. CONTENT_LENGTH: يجب أن يضبط هذا الإعداد إن كان نوع الطلب هو POST. يشير هذا الإعداد إلى طول المحتوى، وغالبًا ما يضبط بالمتغير content_length$ والذي يأخذ قيمته من المعلومات المتوفّرة في طلب المستخدم الأصلي. SCRIPT_NAME: يستخدم هذا الإعداد ليُشير إلى اسم السركبت الأساسي الذي يجب تشغيله. وهو إعداد هامٌ للغاية يمكن ضبطه بعدّة طرق وفقًا لاحتياجاتك. عادةً ما يُضبط بالمتغير fastcgi_script_name$ والذي يجب أن يكون معرّف URI للطلب، أو معرف URI للطلب متبوعًا بـ fastcgi_index إن انتهى المعرّف بـ (/)، أو المجموعة اللاقطة الأولى إن استُخدم fastcgi_fix_path_info. SCRIPT_FILENAME: يحدّد هذا الإعداد الموقع الفعلي على القرص للسكربت الذي يجب تشغيله. وبسبب ارتباطه مع الإعداد SCRIPT_NAME، تقترح بعض أدلة الاستخدام Guides أن تستعيض عن استخدامه بالمتغيرين document_root$fastcgi_script_name$. يتوفر بديلٌ آخر يملك العديد من المحاسن وهو استخدام request_filename$. REQUEST_URI: ينبغي أن تحوي على معرّف URI للطلب كاملًا ومن من دون تعديل، بالإضافة إلى السكربت الذي يجب تشغيله، ومعلومات المسار الإضافية، وأي قيمٍ ممرّرة. تفضّل بعض التطبيقات أن تحلّل تلك المعلومات بنفسها، ويقدم هذا الإعداد المعلومات اللازمة لهم للقيام بذلك. PATH_INFO: إن ضُبط cgi.fix_pathinfo بالقيمة “1” في ملف إعدادات PHP، فسيحوي هذا الإعداد على أية معلومات مسار إضافية additional path information مذكورة بعد اسم السكربت. عادةً ما يُستخدم هذا الإعداد لتعريف الملف الممرّر file argument والذي سيحدّد تصرُّف السكربت. قد يترتّب على ضبط cgi.fix_pathinfo بالقيمة "1" آثارٌ أمنية إن لم تكن طلبات السكربت قد فُحصت بوسائل أخرى (سنناقش ذلك لاحقًا). قد يُضبط هذا الإعداد أحيانًا بالمتغير fastcgi_path_info$ والذي يحوي على المجموعة اللاقطة لثانية من التعليمة fastcgi_split_path_info. وفي حالاتٍ أخرى، سيكون هنالك حاجةٌ لاستخدام متغير مؤقت، إذ أنه يمكن لمعالجةٍ أخرى أن تمسح تلك القيمة أحيانًا. PATH_TRANSLATED: يربط هذا الإعداد بين معلومات المسار المحتواة ضمن PATH_INFO والمسار الفعلي على نظام الملفات filesysem path. عادةً ما يُضبط هذا الإعداد بـ document_root$fastcgi_path_info$، ولكن أحيانًا يجب استبدال المتغير الأخير بالمتغير المؤقت الذي أشرنا إليه سابقًا. التحقق من الطلبات قبل تمريرها إلى FastCGI إنّ أحد المواضيع بالغة الأهمية التي لم نغطها حتى الآن هو كيفية تمرير الطلبات الديناميكية للخادوم بشكلٍ آمن. إن تمرير كلّ الطلبات للخادوم الخلفي بغض النظر عن صحتها لا يسبب خفض فاعلية الخادوم فحسب، بل إنه خَطِرٌ أيضًا. إذ أنه من الممكن للمهاجمين إنشاء طلباتٍ خبيثة في محاولةٍ منهم لتشغيل نص برمجي ما. في الواقع، حتى نعالج هذا الخطأ علينا أن نضمن إرسال الطلبات الصالحة فقط لمعالج FastCGI، يمكننا القيام بذلك بعدة طرق وذلك تبعًا لاحتياجات إعدادنا الخاص وفيما إن كان معالج FastCGI يعمل على نفس النظام المشغِّل لـ Nginx أم لا. إحدى القواعد الأساسية التي يجب أن تحدد لنا كيفية ضبط الإعدادات، هي أنه علينا ألا نسمح بأي معالجة أو تفسير لملفات المستخدم. إذ أنه من السهل نسبيًا على المستخدمين المخادعين malicious users أن يضمّنوا نصًا برمجيًا صالحًا valid code في ملفاتٍ تبدو في الظاهر أنها ملفاتٍ غيرُ مؤذيةٍ كالصور. حالما يُرفع ملفٌ كهذا إلى الخادوم علينا أن نضمن ألا يجد طريقًا للوصول إلى معالج FastCGI. إنّ المشكلة الأساسية التي نحاول حلها هنا هي في الواقع محدّدةٌ في مواصفات CGI specification. تتيح لك تلك المواصفات تحديد ملف السكربت الذي ترغب بتشغيله متبوعًا بمعلومات المسار الإضافية التي يمكن للسكربت أن يستخدمها. إن نموذج التنفيذ هذا يسمح للمستخدمين بطلب معرف URI قد يبدو كسكربت صالح legitimate، إلا أن الجزء الذي سيتم تنفيذه سيكون مذكورًا قبله في المسار. فالنأخذ مثلًا طلبًا لـ: test.jpg/index.php/ إن كانت إعداداتك تمرّر ببساطة كل الطلبات التي تنتهي بـ .php إلى المعالج دون التحقق من مدى صحتها فسيتحقق المعالج، إن كان يحقّق المواصفات، من وجود ذلك الموقع وسينفذّه إن أمكن. أما إذا لم يجد الملف فسيتّبع المواصفات وسيحاول تنفيذ الملف test.jpg/ وسيعتبر أن index.php/ تمثّل معلومات المسار الإضافية الخاصة بالسكربت. كما ترى يمكن لذلك أن يسمح ببعض النتائج غير المرغوب بها إطلاقًا عندما يجتمع مع فكرة رفع المستخدم للملفات. هنالك مجموعة من الطرق المختلفة لحل تلك المشكلة. أسهل تلك الطرق هو ببساطة تعطيل خاصية معالجة معلومات المسار من قِبَل المعالج، وذلك إن كان تطبيقك لا يعتمد على تلك المعلومات الإضافية. يمكن تعطيل تلك الخاصية لدى PHP-FPM من خلال الملف php.ini، فمثلًا إن كنت تستخدم نظام أوبونتو Ubuntu فيمكن تحرير الملف التالي: sudo nano /etc/php5/fpm/php.iniببساطة، ابحث عن الخيار cgi.fix_pathinfo وألغِ تعليقه ثم اضبطه بالقيمة “0” لتعطّل هذه “الميزة” كما يلي: cgi.fix_pathinfo=0أعد تشغيل عملية PHP-FPM حتى تأخذ التعديلات حيّز التنفيذ: sudo service php5-fpm restartسيدفع ذلك PHP لتنفيذ الجزء الأخير من المسار فقط، وبالتالي ففي المثال السابق إن لم يكن الملف test.jpg/index.php/ موجودًا فسيصدر PHP خطأ عوضًا عن محاولة تنفيذ الملف test.jpg/ إذا كان معالج FastCGI يعمل على نفس الخادوم الذي يُشغل Nginx فلدينا خيارٌ آخر وهو ببساطةٍ التحقق من وجود الملفات على القرص قبل تمريرها إلى المعالج. فإذا لم يكن الملف التالي موجودًا test.jpg/index.php/ فسيصدر خطأ. أما إن كان موجودًا فسيُرسل إلى الخادوم الخلفي لتتم معالجته. سينتج عن ذلك عمليًا سلوكٌ يشبه إلى حد بعيد ما رأيناه سابقًا. location ~ \.php$ { try_files $uri =404; . . . }إن كان تطبيقك يعتمد في سلوكه على معلومات المسار حتى يقوم بعملية التفسير بشكل صحيح فما زال بإمكانك السماح بتطبيق ذلك السلوك بأمان عبر القيام بالاختبارات قبل اتخاذ قرارٍ بإرسال الطلب إلى الخادوم الخلفي. فمثلًا، بإمكاننا مطابقة المجلدات التي نخرن فيها الملفات المرفوعة غير الموثوقة تحديدًا وضمان ألا تمرّر إلى المعالج. مثلًا، إن كان مجلد الملفات المرفوعة على المسار: /uploads/ فعلينا إنشاء مقطع موقع يتم مطابقته قبل أن يتم تقييم أي عبارة منتظمة: location ^~ /uploads { }بإمكاننا إضافة أي نوع من معالجة ملفات PHP داخل المقطع البرمجي: location ^~ /uploads { location ~* \.php$ { return 403; } }سيعمل الموقع الأم parent location على مطابقة أي طلب يبدأ بـ uploads/ وأيُّ طلب يتعامل مع ملفات PHP سيُرد عليه بالخطأ 403 عوضًا عن إرساله إلى الخادوم الخلفي. يمكنك أيضًا استخدام التعليمة fastcgi_splite_path_info للتعريف يدويًا عن الجزء من الطلب، الذي يجب تفسيره كسكربت والجزء الدي يجب تعريفه على أنه معلومات المسار الإضافية باستخدام التعابير النمطية. يسمح لك ذلك بأن تستمر في الاعتماد على وظيفة معلومات المسار، على أن تعرّف بدقة ما تعتبره بريمجًا وما تعتبره مسارًا. فمثلًا، بإمكاننا إعداد مقطع لموقع يقوم باعتبار أن أول جزء مكون للمسار ينتهي ب .php هو السكربت الذي ينبغي تشغيله. ويعتبر الباقي معلومات المسار الإضافية. وذلك يعني أنه من أجل الطلب: test.jpg/index.php/ فسيتم إرسال كامل المسار إلى المعالج باعتباره اسم السكربت ولا يحوي معلومات مسار إضافية. يمكن أن يكون الموقع كالآتي: location ~ [^/]\.php(/|$) { fastcgi_split_path_info ^(.+?\.php)(.*)$; set $orig_path $fastcgi_path_info; try_files $fastcgi_script_name =404; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $request_filename; fastcgi_param PATH_INFO $orig_path; fastcgi_param PATH_TRANSLATED $document_root$orig_path; }ينبغي أن يعمل المقطع السابق عندما تكون قيمة cgi.fix_pathinfo في إعداد PHP مضبوطةً بالقيمة "1" حتى تسمح بمعلومات المسار الإضافية. وهنا، إن مقطع الموقع السابق لا يطابق الطلبات التي تنتهي بـ .php وحسب، بل تلك التي تنتهي بـ .php قبل إشارة "/" مباشرةً والتي تدل على مكون إضافي يتبع مسار المجلد directory. تعرّف التعليمة fastcgi_split_path_info داخل المقطع مجموعتين لاقطتين captured group باستخدام التعابير النمطية. تطابق المجموعة الأولى الجزء الممتد من بداية عنوان URI وحتى أول ورود لـ .php ويضعه في المتغير fastcgi_script_name$. ومن ثم يضع أي معلومة مذكورة في الجزء الباقي، والممتد بدءًا من النقطة التي انتهى عندها الجزء الأول وحتى نهاية العنوان، في المجموعة اللاقطة الثانية والتي تخزّن في متغير يدعى fastcgi_path_info$. نستخدم التعليمة set لنخزن القيمة المحفوظة في fastcgi_path_info$، حتى هذه النقطة، في متغير يدعى orig_path$. وذلك لأن قيمة المتغير fastcgi_path_info$ ستُمحى في لحظة عبر التعليمة try_files. بإمكاننا التحقق من اسم السكربت الذي التقطناه سابقًا باستخدام التعليمة try_files. وهي عبارة عن عملية تطبّق على ملف file operation تتأكد من أنّ السكربت الذي نحاول تشغيله مخزن على القرص. ولكن لذلك تأثيرًا جانبيًا يتمثل في مسح قيمة المتحول fastcgi_path_info$. بعد القيام بالتمرير التقليدي عبر FastCGI فإننا نضبط SCRIPT_FILENAME كما العادة. نضبط أيضًا الإعداد PATH_INFO بالقيمة التي المخزّنة في المتغير orig_path$. فبالرغم من أن قيمة fastcgi_path_info$ قد مُسحت، إلا أن قيمته الأصلية محفوظة في ذلك المتغير. كما أننا نضبط الوسيط PATH_TRANSLATED ليربط map بين معلومات المسار الإضافية والموقع الذي تُحفظ فيه على القرص، نقوم بذلك عبر دمج قيمتي المتغيرين document_root$ و orig_path$. يسمح لنا ذلك ببناء طلباتٍ مثل: index.php/users/view/ بحيث يتمكن الملف: index.php/ من معالجة المعلومات المتعلقة بالمجلد: users/view/ وبنفس الوقت نتجنب المواقف التي سيُشغّل بها الطلب: test.jpg/index.php/ سيُضبط البريمج دائمًا بأقصر مكوّن ينتهي بـ .php، وبالتالي سنتجنب تلك المشكلة. يمكننا أيضًا تحقيق ذلك باستخدام تعليمة alias إن احتجنا إلى تغيير موقع ملفات السكربتات. علينا فقط أن نأخذ ذلك بالحسبان في كل من ترويسة الموقع وتعريف fastcgi_split_path_info. location ~ /test/.+[^/]\.php(/|$) { alias /var/www/html; fastcgi_split_path_info ^/test(.+?\.php)(.*)$; set $orig_path $fastcgi_path_info; try_files $fastcgi_script_name =404; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $request_filename; fastcgi_param PATH_INFO $orig_path; fastcgi_param PATH_TRANSLATED $document_root$orig_path; }سوف يسمح لك ذلك لتشغيل تطبيقاتك التي تستخدم الإعداد PATH_INFO بأمان. تذكّر أنه عليك تعديل الخيار cgi.fix_pathinfo في ملف php.ini وضبطه بالقيمة "1" حتى يعمل بشكل صحيح. قد يترتب عليك أيضًا أن تعطّل security.limit_extensions في الملف php-fpm.conf. الخلاصةنأمل أنك تملك الآن فهمًا أفضل لإمكانية قيام FastCGI بالوساطة عنNginx. تسمح هذه الإمكانية لـ Nginx باستخدام قوته في معالجة الاتصالات بسرعة وتحضير المحتوى الثابت static content، بينما تُحمّل مسؤولية المحتوى الديناميكي dynamic content لبرمجيات مناسبة لذلك. يسمح FastCGI لـ Nginx بالعمل مع عدد كبير من التطبيقات، عبر إعدادات آمنة وذات أداء. ترجمة – وبتصرّف– للمقال Understanding and Implementing FastCGI Proxying in Nginx لمؤلفه Justin Ellingwood.
  24. سنتعلم في هذا الدرس كيفية تصميم موقع بطريقة Parallax Scrolling من الصفر حتى النهاية، وذلك باستعمال برنامج Photoshop. في درسنا هذ سيكون القالب بخصوص وكالة مختصة في الويب (Web Agency). وهذه هي النتيجة النهائية: قبل البدء أدعوكم لتحميل هذه الحزمة. نفتح مشروع جديد على Photoshop بالإعدادات التالية: 1800x4850pixelsResolution 720DpiColor Mode RVB8bitللحصول على الدقة أثناء التحويل من PSD على HTML علينا استعمال الأسطر الدلالية (Guides Lines) ليسهل التعامل بـ CSS. نضيف العلامات الافقية الذهاب إلى: Menu > View > New Guide نختار Horizontal ثم ندخل القيم التالية: 59px ،651px ،1431px ،2237px ،2613px ،3154px ،3939px ،4767px نبدأ بالقائمة في الأعلى – يسمى الجزء العلوي: header-. نأخذ أداة النص (T) ونكتب مختلف عناصر القائمة باستعمال "Open sans" كنوع للخط و13pt في حجمه (تجده في حزمة هذا الدرس). بعدة ذلك اجلب أيقونة الموقع خاصتك، في هذا الدرس سنستعمل كلمة Awesome Agency ملونة باللون الأزرق 00b3e3#. الآن نضيف للمشروع صورة من الحجم الكبير بين العلامتين الأولى والثانية. نضيف مستطيل أسود اللون باستعمال أداة الشكل الرباعي (U). نخفض قيمة الشفافية الخاصة بالمربع إلى قيمة %71. بعد ذلك نرسم مستطيل آخر بمحتوى شفاف وإطار باللون # 617b9b. ننشئ طبقة جديدة New Layer بالضغط على Ctr+Shift+N، وبأداة القلم (P) بقيمة 1px في عرض الخط، نرسم زوايا كما تبين الصورة-للحصول على خط مستقسم يكفي النقر بالفأرة في مكان بدأ الخط ثم في مكان نهاية الخط مع النقر على زر Shift في لوحة المفاتيح وبهذا يرسم خط مستقسم الشكل بين النقطتين -: ثم نرسم مستطيل أبيض اللون كهذا. نطبق عليه – المستطيل الأبيض-Filter Motion Blur وذلك بالذهاب إلى: Menu > Filter > Blur > Motion Blur نرسم مستطيل آخر ونطبق عليه نفس الفلتر، ثم نرسم دوائر بأداة الدائرة Ellipse Tool (U) للحصول على الشكل التالي: أضف الآن النص الخاص بك (النص المستعمل في الدرس مجرد مثال بسيط، والذي سيعوض بمحتوى في HTML) بالنسبة الجزء الثالث، اجلب الأيقونات المحملة في الحزمة أول الدرس كما تبين الصورة: بالطريقة ذاتها أضف النص الخاص بك باستعمال نفس الخط «Open Sans» -ينصح الويب عدم استعمال كثرة الخطوط لتفادي بطء الخوادم Servers- نمر للجزء الرابع، نأخذ أداة المستطيل ونرسم مستطيل أزرق اللون # 32bcef باتباع العلامات -Guides-. بعد ذلك نتجه إلى خصائص الدمج Blending Options: ثم نرسم مستطيل آخر بشعاع ذو قيمة 5px ولون أزرق غامق #0c1a2d. أضف أيقونة الموقع أو أي شيء تريد، في الدرس أضفنا نفس الأيقونة السابقة وشكل المتجاوب للموقع. ثم نضي فنص رمادي فاتح وغامق للعناوين كما تبين الصورة. سنصمم الآن معرض للأعمال-Portfolio – المندرج في صفحتنا هاته، أضف الصور الخاصة بك. أرسم على صورة معية مستطيل أزرق #32bcef . بعد ذلك نرسم مستطيل آخر أبيض اللون بنفس مقاس الصورة، ثم نخفض قيمة الشفافية -opacity-خاصته إلى قيمة 65% . وللانتهاء من هذا الجزء، أضف نصا كما في الصورة: في الجزء الخامس، وبنفس الطريقة نرسم مستطيل أبيض اللون بإطار رماديcacaca #. دائما بأداة الشكل المربع نرسم في الأسفل مستطيل أزرق اللون #36caf4. بعد ذلك نتجه إلى خصائص الدمج Blending Options: نغير من طول المستطيل الأزرق حتى يتناسب مع طول المستطيل الأبيض: أضف أيقونات المواقع الاجتماعية: بعد ذلك أضف النص الخاص بك وصورة –في هذا المثال وضعنا صور العاملين في وكالتنا-: بنفس الطريقة نضيف مستطيلات ونصوص أخرى حتى نتوصل إلى النتيجة المحصل عليها: الآن، قم بجلب صورة وضعها في الأسفل –هذا الجزء من الصفحة يسمى ب footer – ونطبق عليه نفس خطوات الجزء الثاني للحصول على صورة ذات إضاءة خفيفة. ونضيف بعض الكلمات وبعض الأيقونات بالشكل التالي: لرسم استمارة -Form-للتواصل بالموقع نرسم أربع مستطيلات بمحتوى شفاف وإطار أبيض ذو عرض 1-2 pixels: ثم نضيف مربع أزرق #3ec1f1 ذو زوايا دائرية مع بعض الكلمات التي تشير إلى الحقول وزر الإرسال: وفي الأخير نضيق في الأسف مستطيل باللون #1e1e1e، بغرض الصفحة يحتوي على نص وأيقونة تشير لحقوق الملكية. لنحصل في الأخير على الصورة النهائية: ترجمة -وبتصرّف- للمقال: Tutoriel comment faire un Design Responsive en Parallaxe Scrolling.
  25. يُعتبر خادوما الويب Apache و Nginx الأكثر شهرةً من بين الخواديم المفتوحة المصدر في عالم الشبكة العنكبوتيّة، على اعتبار أنّهما مسؤولان عن خدمة وتأمين نصف تدفّق البيانات على الإنترنت، وعلى مَقدرة على تولّي مُختلف حجوم الأحمال، والعمل مع برمجيات أخرى في سبيل توفير حزمة من خدمات الويب الشاملة والكاملة لتلبية مُختلف الاحتياجات. بينما يَتشارك الخادومان Apache و Ngnix العديد من الميّزات والخاصيّات، فلا يُمكن اعتبارهما مُتشابهان، أو التفكير بأن أحدهما هو بديل عن الآخر، فكل منهما يتفّوق عن الآخر بشيءٍ ما، وعلى مُدير النظام فهم وإدراك لماذا يجب اختيار أحدهما دون الآخر، فهذا الدليل يَهدف إلى مُناقشة كيف أنّ كُل خادوم يَتميّز ويَبرز في شيء ويُخفق في آخر. مقدّمة عامّةسيتمّ أخذ نظرة سريعة عن تاريخ وبداية المشروعين وخواصّهم العامّة قبل التعمّق في الاختلاف بينهما. تاريخ خادوم الويب Apacheأَنْشَأَ “روبت ماك كول” (Robert McCool) “خادم الـ HTTP أباتشي” (Apache HTTP Server) في عام 1995، وتمّ مُتابعة تطويره تحت مظلّة “مُنشأةُ برمجيات أباتشي” (Apache Software Foundation) مُنذ العام 1999، وكان هذا الخادم هو المشروع الأساسي للمُنشأة والأكثر شهرةً عن باقي البرمجيات، فأصبح ببساطة يُشار إليه بالاسم “Apache”. يُعتبر خادم الويب أباتشي الخادم الأكثر استخدامًا على الإنترنت منذ العام 1996، وبسبب هذه الشهرة، استفاد أباتشي من توثيق ودعم باقي مشاريع البرمجيات الأُخرى. يَختار مُدراء الأنظمة الخادم أباتشي غالبًا بسبب مرونته، وقُدرته على التحمّل، وتوفّر دعمه العالي والمُنتشر، كما يُحسب له قابليته على التوسّع عبر نظام الوحدات (modules) الديناميكيّة، واستطاعته على مُعالجة عدد كبير من اللغات المُفسّرة (interpreted languages) من دون الحاجة إلى برمجيّة مٌستقلّة وسيطة. تاريخ خادوم الويب Nginxبَدأ “ايجور سيسيوﭫ” في عام 2002 العمل Nginx للإجابة وحلّ المُشكلة المعروفة بالاسم C10K، والّتي كانت تُشكّل تحدّيًا كبيرًا لخوادم الويب لتُصبح قادرة على تولّي عشرة آلاف اتصال مُتزامن (concurrent) وذلك في تلبية حاجة الويب الحديث، وأُنتجت الإصدارة الأوليّة والمُتاحة للعُموم في عام 2004 مُقدمةً حلًا لهذه المُشكلة، وذلك بالاعتماد على معماريّة مدفوعة بالحالة (event-driven) ولا مُتزامنة. انتشر Nginx كالنار في الهشيم مُنذ إصداره، بمُقتضى خفته واستخدامه الخفيف للمَوارد، وقدرته على التوسّع وتحمّل الضغط العالي وبأقل عتاد مُمكن، وتفوّق Nginx بتأمين المُحتوى الثّابت (static content) بسرعة، وبتصميمه لتمرير الطلبات الديناميكيّة (المُتغيّرة) إلى برمجيات أُخرى قادرة على مُعالجة هذا النوع من المُحتوى. يختار مُدراء الأنظمة الخادم Nginx غالبًا بسبب استهلاكه الأمثل للمَوارد، واستجابته العالية مع الضغط المتزايد. معماريّة مُعالجة الاتصال (Connection Handling Architecture)يَكمن الاختلاف الواضح بين أباتشي و Nginx في طريقة كلٍ منهما في مُعالجة الاتصالات وتدفّق البيانات (traffic)، وربّما هذا السبب وراء الاختلاف في طريقة كل من الخادمين في الاستجابة إلى حالة تدفّق البيانات المُختلفة. وحدات أباتشي (Apache Modules)يقدّم أباتشي تشكيلةً من وحدات المُعالجة المُتعدّدة (multi-processing)، والّتي يُطلق عليها بـ MPMs، والغرض منها تحديد آليّة مُعالجة طلبات العميل، ويَسمح ذلك مُدراء الأنظمة عامّةً بالتبديل بين معماريّة مُعالجة الاتصال بسهولة، والوحدات هي: mpm_prefork: تَستنسخ وتُوالد هذه الوحدة الخاصّة بالمُعالجة عمليّات (processes) باستخدام سلسلة وحيدة (single thread)، على أنّ تكون كل عمليّة لمُعالجة طلب، ويستطيع كل ابن مُعالجة اتصال واحد في نفس الوقت، وطالما أنّ عدد الطلبات أقل من عدد العمليّات، فستكون هذه الوحدة سريعةً جدًا، ولكن يَنخفض الأداء بسرعة بعد تخطّي الطلبات عدد العمليّات، ولذلك لا يُعتبر هذا النمط بالخيار الجيّد للعديد من السيناريوهات، فكل عمليّة لها تأثير بليغ على استهلاك الذاكرة (RAM)، ولهذا السبب تُصعّب هذه الوحدة من عمليّة التوسّع بطريقة مُلائمة، ومع هذا تبقى هذه الوحدة خيارًا جيّدًا إن تمّ استخدامها مقترنةً مع مُقوّمات (components) أُخرى لم تُبنى بالأساس آخذةً بعين الاعتبار السلاسل (threads)، فلغة PHP ليست سلسلة آمنة (thread-safe)، ولذلك يُنصح بهذه الوحدة باعتبارها الطريقة الوحيدة الآمنة للعمل مع mod_php والّتي هي وحدة من وحدات أباتشي لمُعالجة هذا النوع من الملفّات. mpm_worker: تستنسخ وتُوالد هذه الوحدة عمليّات (processes) كل منها ذات قُدرة على إدارة سلاسل مُتعدّدة (multiple threads)، تستطيع كل واحدة من هذه السلاسل مُعالجة اتصال وحيد، تُعتبر هذه السلاسل أكثر كفاءة من العمليّات، بسبب أنّ هذه الوحدة تتوسّع (scales)، وتتحمّل المزيد من الضغط أفضل من الوحدة prefork MPM، وباعتبار أنّه يوجد سلاسل أكثر من العمليّات، فهذا يعني أيضًا أنّ الاتصالات الجديدة تستطيع مُباشرةً استهلاك واستخدام سلسلةبدلًا من اضطرارها إلى الانتظار لتوفّر عمليّة مُتاحة. mpm_event: تَعمل هذه الوحدة بشكل مُشابه إلى الوحدة worker، ولكنها مُحسّنة لتتولّى اتصالات keep-alive، فعند استخدام الوحدة worker فإن الاتصال سيَحتفظ بالسلسلة (thread) بصرف النظر فيما إذا كان الطلب نشطًا فيما صُنع من أجله ما دام الاتصال محفوظًا نشطًا، فالوحدة mpm_event تتولّى الاتصالات keep-alive بالاحتفاظ جانبًا بسلاسل مكرّسة لمُعالجتها، وبتمرير الطلبات النشطة إلى سلاسل أُخرى، وهذا من شأنه أنّ يُبعد الوحدة من الغوص بطلبات keep-alive، الأمر الّذي يُجيز بتنفيذ الطلبات (execution) بشكل أسرع، وهذا الأسلوب أصبح يعمل بشكل مُستقر مع الإصدار Apache 2.4. أصبح الأمر أكثر وضوحًا، حيث تقدّم خوادم أباتشي بنية معماريّة مرنة للاختيار بين مُختلف الاتصالات وخوارزمية مُعيّنة في مُعالجة الطلبات، وبُنيت هذه الخيارات في الدرجة الأولى من تطوّر الخادم والحاجة المُتزايدة للاتصالات المُتزامنة لتواكب طبيعة الإنترنت بعد تغيرها وتطوّرها. آليّة مُعالجة الاتصال في خادوم Nginxقَدِم Nginx إلى عالم خوادم الويب بعد قدوم أباتشي، مَبنيًّا ومُعدًّا لمشاكل الاتصالات المُتزامنة (concurrency) الّتي تواجه المواقع عند التوسّع، مُحمّلًا بهذه المعرفة، صُمّمَ Nginx من جذوره ليستخدم خوارزميّة في مُعالجة اتصالات مدفوعة بالحالة (event-driven)، غير مُستوقفة (non-blocking)، ولا مُتزامِنة. يستنسخ ويُوالد Nginx من العمليّات العاملة (worker processes)، ويستطيع كلٍ مِنها مُعالجة آلاف الاتصالات، وتُنجذ العمليّات العاملة ذلك عن طريق تطبيق/تنفيذ آلية حلقيّة سريعة، والّتي تفحص بشكل مُستمر حالات العمليّات (processes events)، وإن فصل المُهمّة الفعليّة عن الاتصالات يسمح لكلعامل بالاهتمام بنفسه باتصال فقط عند بدء حالة جديدة. يتموضع كل اتصال مُعالج من قبل العامل ضمن حلقة الحالة (event loop) في مكان تواجد بقية الاتصالات، وتُعالج الأحداث بشكل لا مُتزامن ضمن الحلقة، ليتمّ إنجاز المُهمّة بطريقة غير مُستوقفة (non-blocking)، وعندما يُغلق الاتصال سيتمّ نزعه من الحلقة. يَسمح هذا الأسلوب من مُعالجة الاتصال Nginx بتحمّل الضغط العالي بشكل لا يُصدّق وبأقل المَوارد المُتاحة، وباعتبار أنّ الخادم ذو سلسلة وحيدة (single-threaded) ولا تتوالد العمليّات لتُعالج كل اتصال جديد، فإن استهلاك المُعالج (CPU)، والذّاكرة يبقى ثابتًا نسبيّا، حتّى في أوقات الذروة. كيف يُعالج أباتشي و Nginx المُحتوى الثّابت والمحتوى الديناميكي (المُتغيّر)إن أبرز ما يتمّ النظر إليه عند المُقارنة بين الخادمين هي طريقة كلٍ منهما في التعامل مع طلبات المُحتوى الثّابت (static)، والمُحتوى المُتغيّر (dynamic). كيف يتعامل أباتشي مع المُحتوى الثّابت والمُتغيّرتستطيع خوادم أباتشي التعامل مع المُحتوى الثّابت باستخدام الطريقة التقليديّة المُعتمدة على الملفّات، ويعود أداء هذه الإجراءات (operations) في الدرجة الأولى على دور ووظيفة أساليب الوحدات (MPM) المشروحة سابقًا. يستطيع أباتشي أيضًا مُعالجة المُحتوى الديناميكي (المُتغيّر) بدمج مُعالج اللغة المُراد مُعالجتها داخل كل من نماذجه العاملة (worker instances)، وهذا يَسمح له بتنفيذ المُحتوى الديناميكي داخل خادم الويب نفسه بدون الحاجة إلى الاعتماد على مُقوّمات خارجيّة، ومن المُمكن تفعيل هذه المُعالجات الديناميكيّة (المُتغيّرة) من خلال استخدام وحدات قابلة للتحميل بشكل ديناميكي. إن قدرة أباتشي على مُعالجة المُحتوى الديناميكي بشكل داخلي تعني أنّ الإعداد يُصبح أسهل لمُعالجة هذا النوع من المُحتوى، فليس من الضروري تنسيق عمليّة الربط مع برمجيات إضافيّة، وتستطيع الوحدات وبسهولة أنّ تقوم بالتبديل عندما تتغيّر مُتطلّبات المُحتوى. كيف يتعامل Nginx مع المُحتوى الثّابت والمُتغيّرلا يَملك Nginx بطبيعته أي قدرة على مُعالجة المُحتوى الديناميكي، ولمُعالجة شيفرة PHP وطلبات المُحتوى الديناميكي، فإن على Nginx تمرير الطلبات إلى مُعالج خارجي من أجل التنفيذ (execution) والانتظار ريثما يتم الانتهاء من مُعالجة هذا المُحتوى ليتمّ إعادة إعادته، ومن ثم عرض النتائج على العميل. يَنبغي على مُدراء الأنظمة الانتباه إلى أنّ الأسلوب الّذي ينتهجه Nginx يستوجب إعدادًا بينه وبين المُعالج وباستخدام واحدًا من البرتوكولات الّتي يفهمها Nginx أمثال: HTTP, FastCGI, SCGI,uWSGI, memcache، وهذا من شأنه أنّ يُعقّد الأمور بعض الشيء، خصوصًا عند مُحاولة توقّع عدد الاتصالات اللازم السماح بها، حيثُ أنّه سيتمّ استخدام اتصالًا إضافيًا لكل مُعالج يتمّ استدعاؤه. من ناحية أخرى، إن هذا الأسلوب يقدّم بعضًا من الأفضليّة، عندما نعلم أنّ مُفسّر المُحتوى الديناميكي غير مُدمج في عمليّة العامل، وتكلفة هذه الطريقة ستُدفع للمُحتوى الديناميكي فقط، وعلى أنّ يُقدّم المُحتوى الثّابت بطريقة مُباشرة، ولا يتمّ الاتصال بالمُفسر إلا عند الحاجة، والجدير بالذكر أنّ أباتشي يستطيع العمل بهذا الأسلوب، ولكن بعمله ذلك سيتخلّى عندها عن بعض ميزاته. الاختلاف بين الإعداد الموزّع (Distributed) والإعداد المركزي (Centralized)يَعتبر مُدراء الأنظمة الاختلاف الأكبر والبارز بين هذين الخادمين هو فيما إذا كان الإعداد والتخصيص على مُستوى المسار مسموحًا أو لا ضمن مسارات (directories)المُحتوى. فلسفة Apache في الإعداديُضمّن أباتشي خيارًا للسماح بالإعداد لكل مسار عن طريق تَفحُّص (inspecting) وتفسير (interpreting) التعليمات أو التوجيهات الموجودة في الملفات المخفيّة داخل مسارات المُحتوى نفسها، وهذه الملفّات معروفة بملفات .htaccess. باعتبار أنّ هذه الملفّات تَقطن داخل مسارات المُحتوى نفسها، فعند مُعالجة طلبٍ ما، فإن أباتشي يَفحص كل جزء من مسار الملفّ المطلوب باحثًا عن ملفّ .htaccess ليُطبّق التوجيهات الّتي بداخله، وهذا من شأنه أنّ يسمح للإعداد اللامركزي لخادم الويب، والذي غالبًا ما يُستخدم لإنجاز: إعادة كتابة عنوان الموقع (URL rewrites)تقييد الوصول (access restrictions)التفويض والمُصادقة (authorization and authentication)سياسات التخبئة (caching policies)بالطبع يُمكن للأمثلة السابقة إعدادها عن طريق ملفّ إعدادات أباتشي الرئيسي، ولكن استخدام ملفات.htaccess يَملك بعض الميزات: أوّلًا، باعتبار أنّها تُفسّر في كل مرّة توجد بها مع المسار المطلوب، فهي تُنفّذ مُباشرةً بدون إعادة تحميل الخادم.ثانيًا، تجعل من المُمكن السماح للمُستخدِمين غير المصرّح لهم بالتحكم بجانب معيّن من المُحتوى الخاصّة بهم بدون إعطائهم تحكم كامل لملفّ الإعدادات.يُقدّم هذا النمط من الإعداد طريقة سهلة ونموذجيّة، وخاصّة لبعض برمجيات الويب، مثل أنظمة إدارة المُحتوى (CMS)، لغرض إعداد بيئتها بدون مَنح إذن وصول إلى ملفّ إعدادات مركزيّ، وكما هو معروف يُستخدم هذا الأسلوب مع مزودات الاستضافة المُشتركة (shared hosting providers) لصون والحفاظ على الإعدادات الرئيسية مع إمكانيّة منح العُملاء أفضليّة التحكّم بمسارات مُعيّنة. فلسفة Nginx في الإعدادلا يُفسّر Nginx ملفّات .htaccess، ولا يُقدّم أي آليّة للتعامل مع كل مسار من دون استخدام ملفّ إعدادات رئيسي، قد يبدو هذا الأسلوب أقل مرونةً من أسلوب أباتشي، ولكن من ناحية أُخرى فلهذا الأسلوب أفضليته. إن عدم الاعتماد على نظام ملفّات .htaccess الخاصّ بالإعداد على مستوى المسارات يُقدّم سرعةً في الأداءً، فخادم أباتشي عليه القيام بتفحّص المسار الجذر لكل طلب يصله، وعند وجود ملفّ أو أكثر خلال عمليّة البحث، يتم قراءة محتوياته وتفسيرها، ولكن Nginx لا يفعل ذلك، فهو يخدم الطلبات بسرعة أكبر بالاعتماد على مكان وحيد للبحث عنه. أفضليّة أُخرى مُتعلّقة بالحماية، فإن توزيع ملفّات الإعدادات على مستوى المسارات يوزّع مسؤوليّة الحماية على كل المُستخدِمين، الّذين قد يكونوا في معظم الأحوال غير موثوقون لتولّي هذه المُهمّة بالشكل الأمثل، فعندما يقوم مُدير النظام بتولّي مُهمة التحكم بالخادم ككل، يمنع ذلك من حدوث أخطاء، والتي قد تحدث في حال منح صلاحيات وصول لأطراف أُخرى. يجدر الذكر أنّه من المُمكن تعطيل تفسير ملفّات .htaccess’ فيأباتشي`، في حال أنها تُشكل نوعًا من القلق لمُدير النّظام. الاختلاف بين تفسير الملفّات وتفسير URIلا يقتصر الاختلاف بين الخادومين على ما سبق فقط، فيظهر الاختلاف الآخر في كيفيّة تفسير كلٍ منهما للطلبات (requests) وربطها مع المَوارد المُتواجدة على النّظام. كيف يُفسر Apache الطلباتيقدّم أباتشي القدرة على تفسير الطلب إما كمَورد فيزيائي (حقيقي) على نظام الملفّات (filesystem) أو عنوان URI الّذي قد يحتاج أسلوب أكثر تجرّد، ويستخدم أباتشي بشكلٍ عام للأسلوب الأول كتل (blocks) وهي إما <Directory> أو <Files>، بينما يستخدم كتل <Location>للمَوارد الأكثر تجرّدًا. صُمّم أباتشي من الأساس كخادم ويب، لذلك في مُعظم الأحيان فإن السلوك الافتراضيّ هو تفسير الطلبات كمَوارد نظام ملفّات (filesystem)، حيثُ يبدأ بتتبّع جذر المُستند وإلحاقه بجزئية الطلب متبوعًا باسم المُضيف (host) ورقم المنفذ في مُحاولة لإيجاد الملفّ المطلوب، بمعنى آخر وببساطة، تتمثّل هرميّة نظام الملفّات على الويب كشجرة مُستند. يُقدّم أباتشي عددًا من البدائل عندما لا يتوافق الطلب مع نظام الملفّات المقصود، فمثلًا من المُمكن استخدام الموجّه Alias لربط عنوان البديل، مع العلم أنّ استخدام الكتل <Location> هو طريقة للتعامل مع URI نفسها بدلًا من نظام الملفّات، كما يُمكن استخدام التعابير النمطيّة (regular expression)، والّتي من المُمكن استخدامها لتطبيق الإعداد بسهولة أكبر في كامل نظام الملفّات. يُعوّل أباتشي على نظام الملفّات بشكل كبير، يظهر ذلك جليًا في اعتماده على ملفّات .htaccessلإعداد كل مسار، حتّى أنّ التوثيق الرسميّ الخاصّ به يحذر من استخدام كتل مُعتمدة على URI في تقييد الوصول عندما يكون الطلب يَعتمد بشكل أو بآخر على نظام الملفّات. كيف يُفسّر Nginx الطلباتأُنشِأ Nginx ليكون خادمًا للويب وخادمًا وكيلًا/وسيطًا (proxy server)، ونظرًا إلى المعماريّة المطلوبة للعمل بهذه الأدوار، فإنه يعمل بشكل رئيسي مع URIs، والتحويل إلى نظام الملفّات عند الضرورة. يُمكن رؤية ذلك في بعض جوانب بناء وتفسير ملفّات إعدادات Nginx، فلا يوفّر Nginx آليّة لتحديد إعدادًا لمسار نظام الملفّات، بل يَستعيض عنها بتحليل URI نفسه. يُمكن توضيح ذلك بالمثال، كتل الإعداد الأوليّ لـ Nginx هي: server و location، الكتلة serverتُفسّر المُضيف الجاري طلبه، بينما الكتل مسؤولة عن مُطابقة أجزاء من URI التي تأتي بعد المُضيف والمنفذ، في هذه المرحلة يتمّ تفسير الطلب كـ URI، وليس كعنوان على نظام الملفّات. يتوجّب في نهاية المطاف على جميع الطلبات أنّ تُربط مع عنوان على نظام الملفّات وذلك للملفّات الثّابتة، فأولًا، سيَختار Nginx كتل server و location الّتي سوف تتولّى الطلب، ومن ثم ضم جزر المُستند مع الـ URI. إن تحليل ومُعالجة الطلب قبل كل شيء على شكل URIs بدلًا من عناوين نظام الملفّات يَسمح لـ Nginxالعمل بسهولة وعلى حدٍّ سواء كخادم وسيط (بروكسي)، وكخادم بريد، وخادم ويب، فقد تمّ إعداده ليُلائم كيف له أنّ يستجيب لأنماط الطلبات المُختلفة، ولا يفحص Nginx نظام الملفّات حتّى يكون جاهزًا ليَخدم الطلب، وهذا يُفسّر لماذا هو لا يُطبّق نمط ملفّات .htaccess. الوحداتيتوسع كلا الخادومان عن طريق نظام الوحدات، ولكن طريقة عملهما تختلف عن الآخر بشكل كبير. كيف يستخدم أباتشي نظام الوحدات (Modules)؟يَسمح نظام وحدات أباتشي بطريقة آليّة وديناميكيّة بتركيب ونزع الوحدات ليتناسب مع مُتطلّبات مُدير النظام خلال عمليّة تشغيل الخادم، وتتواجد نواة أباتشي دائمًا بكل جاهزية، بينما يُمكن تشغيل أو تعطيل الوحدات، أو حتّى حذفها أو إضافة ما يلزم إلى الخادم. يستخدم أباتشي الوحدات في العديد من المهام، ونظرًا للباع الطويل لمنصة أباتشي، فيتوفّر عدد هائل من مكتبات الوحدات، والّتي من المُمكن استخدامها في تعديل بعض الوظائف الداخليّة في بنية خادم أباتشي، فمثلًا الوحدة mod_php تقوم بدمج مُفسّر PHP داخل كل عامل (worker). لا تنحصر الوحدات لمُعالجة المُحتوى الديناميكي (المُتغيّر) فقط، فيُمكن استخدامها في العديد من الوظائف، فيُمكن استخدامها في: rewriting URLs: إعادة كتابة العناوينauthenticating: المُصادقةlogging: التّتبّعcaching: التخبئةcompression: الضغطproxying: الوساطةencrypting: التشفيركيف يتعامل Nginx مع نظام الوحدات (Modules)يُطبّق ويتعامل Nginx مع نظام الوحدات، ولكن يختلف الأمر عما هو في نظام أباتشي، فلا تُحمّل الوحدات بشكل ديناميكي في نظام Nginx، لذلك يجب على هذه الوحدات أنّ تُختار وتُترجم (compiled) إلى النواة. قد يبدو الأمر صعبًا للعديد من المُستخدمين وخاصّة لهؤلاء الذين لا يُحبذون صيانة برمجياتهم المُترجمة (compiled) بدون الاستعانة بنظام حزم تقليدي، وعلى الرغم من أنّ حزم الموزّع تتضمّن الوحدات الأكثر استخدامًا، ولكن عند الحاجة إلى وحدة غير شائعة، سيتوجب على مُدير النظام بناء الخادم من المصدر بنفسه. تَبقى وحدات Nginx مع ذلك ذات فائدة، وتسمح لمُدير النّظام بتحديد ماذا يجب على الخادم أنّ يحتوي من وظائف، أيضًا بعض المُدراء ينظر إلى الأمر من منظور الحماية، حيثُ أنّ المُكوّنات الاعتباطيّة لا يُمكن أن تُدرج داخل الخادم. تُقدّم وحدات Nginx مقدرات مُماثلة للوحدات الّتي المُقدّمة من أباتشي، على سبيل المثال، توفّر وحدات Nginx: proxying support: الوساطةcompression: الضغطlogging: التّتبّعrewriting: إعادة كتابة العنوانauthentication: المُصادقةencryption: التشفيرالدعم والتوافُقيّة والتوثيقيجب دائمًا التأكد من آليّة بناء الخادم ومُتطلباتها، وما الّذي على مُدير النّظام عمله لبناء خادم يعمل بأبسط الإمكانيات، وما هو حجم الدعم والمُساعدة المتوفّر لهذه البرمجية. الدعم في أباتشييُعرف الخادم أباتشي بباعه الطويل في هذا المجال، ولذلك فإن الدعم الخاصّ به متواجد وبقوّة، حيثُ يتوفّر توثيق مُمتاز لمكتباته الخاصّة به ومكتبات الطرف الثالث (الخارجيّة)، وعلى كافّة المُستويات، سواء كان لنواة الخادم أو للجزئيات المُرتبطة ببرمجيات أُخرى. يتوفّر بجانب التوثيق، العديد من الأدوات ومشاريع الويب لتسريع بدء العمل مع بيئة الخادم، وهي موجودة ضمن المشاريع نفسها أو مُتوفّرة ضمن برمجيات الحزم المعروفة. يَملك أباتشي بشكلٍ عام دعمًا قويًا من قِبل مشاريع الطرف الثالث، وذلك بسبب حصته السوقيّة، وقِدَمه، كما يَملك مُعظم مُدراء الأنظمة بشكل أو بآخر معرفة جيّدة بخادم أباتشي، ليس فقط بسبب انتشاره، ولكن أيضًا بسبب أنّ معظمهم بشكل أو بآخر يستخدم الاستضافة المُشتركة (shared-hosting)، والّتي تعتمد على خادم أباتشي بشكل حصري، لمقدرته الإدارية الموزّعة باستخدام ملفّ .htaccess. الدعم في Nginxيكسب Nginx المزيد من الدعم مع ازدياد المُستخدِمين بسبب أدائه العالي، ولكن يبقى عليه التطوير من نفسه في بعض الجزئيات. قد كان من الصعب إيجاد توثيق مفهوم وواضح بالغة الإنكليزية للخادم Nginx في البداية، نظرًا إلى أنّ تطويره وتوثيقه تمّ بالغة الروسية، ومع ازدياد الاهتمام بالمشروع، أصبح هناك وفرة من المصادر على الموقع الرسميّ وغيره من الدعم الخارجي. أصبح الدعم متوفّرًا أكثر من ذي قبل فيما يخص تطبيقات الطرف الثالث، وبدأت بعض الحزم بتقدم خيارات الإعداد التلقائي سواءً لـ أباتشي أو Nginx، وعند عدم توفّر الدعم، فإن إعداد Nginx مع البرمجيات البديلة عادةً ما يكون واضحًا ومُيسرًا طالما أنّ برمجية الطرف الثالث تملك توثيقًا جيّدًا لمُتطلّباتها. استخدام Apache و Nginx معًاتمّ عرض فوائد وقصور كلا الخادومين، ويجب على مُدير النّظام في هذه المرحلة أنّ يُحدّد أيًا منهما يُناسب احتياجاته، ولكن يجد العديد من المُستخدِمين أنّه من المُمكن تقوية خادوم الويب عند استخدام كلٍ من أباتشي و Nginx جنبًا إلى جنب. إن إتمام هذه الشراكة يتمّ عن طريق تَمَوْضُع Nginx أمام أباتشي كوكيل/وسيط عكسي (reverse proxy)، وهذه يسمح لـ Nginx بمُعالجة جميع الطلبات من العُملاء، الأمر الّذي يَسمح بالاستفادة من سرعة Nginx وقدرته على تولّي عدد كبير من الاتصال في وقتٍ واحد. إن خدمة الملفّات الثّابتة بسرعة كبيرة ومباشرةً إلى العُملاء، هو الأمر الّذي يتفوّق به Nginx، ولكن وللمُحتوى الديناميكي، ملفات PHP مثلًا، سيُوكل Nginx الطلبات إلى أباتشي لمُعالجتها والعودة بصفحة بالنتيجة النهائيّة، ليستطيع Nginx عندها تمرير المُحتوى إلى العميل. يعمل هذا الإعداد بشكل جيّد للعديد من مُدراء الأنظمة، وذلك بسبب أنّه يسمح لـ Nginx ليعمل كآلة فرز وتصنيف، بمعنى أنّه سيتولّى مُعالجة جميع الطلبات طالما أنّه يستطيع ذلك، وتمرير ما لا يستطيع التعامل معه، وبتخفيض الطلبات المطلوب من خادم أباتشي تولّيها، سيُخفف بعضًا من الاستيقاف (blocking) الّذي قد يحدث عندما يستهلك أباتشي المزيد من المُعالج. يَسمح هذا الإعداد أيضًا لمُدراء الأنظمة بالتوسّع عن طريق إضافة خادم خلفي (backend) على حسب الحاجة والضرورة، ومن المُمكن إعداد Nginx لتمرير الطلبات إلى تجمّع (pool) من الخوادم بسهولة، الأمر الّذي يزيد من الأداء والفعاليّة. الختاميُقدّم كلًا من أباتشي و Nginx مُرونة في الاستخدام، وقوّةً في الأداء، والتفضيل بينهما هو لأمرٌ يَعتمد على تقدير مُتطلبات ووظائف الخادم، وعلى مُدير النّظام أنّ لا يسأل: هو أفضل خادم ويب؟، بل السؤال الّذي يجب سؤاله هو، ما هو أفضل خادم ويب لمشروعي الّذي يتطلّب كذا وكذا؟ يوجد بالفعل اختلافات بين المشروعين، هذه الاختلافات من شأنها أن تأثر على الأداء، والقدرات، والوقت المُستغرق في إتمام أي منهما للعمل بالجاهزيّة الكاملة، ولكي يتمّ اختيار الأفضل يُنصح بعمل تسوية أو مقايضة بين المحاسن والمساوئ، ففي نهاية المطاف لا يوجد خادم يُلبي كافة الاحتياجات، ويَكمن الحلّ في ترتيب الأولويات. ترجمة –وبتصرّف– للمقال Apache vs Nginx: Practical Considerations لصاحبه Justin Ellingwood.