البحث في الموقع

إذا التقى شخصان في قرى الهيمالايا، حيِّا أحدهما الآخر قائلًا: "هل جسدك معافى؟" وأما في اليابان فقد ينحنيان أحيانًا، وفي عُمان يطبع كلّ منهما قبلة على أنف الآخر بعد التصافح، في كمبوديا وتايلاند، يضمّ كلّ منهما يديه وكأنّه يدعو. كل هذه الوسائل هي "بروتوكولات" للتواصل، أي سلسلة بسيطة من الرموز ذات المعنى والّتي تمهّد لتبادل حديث مُفيد. في عالم الويب، لدينا بروتوكول فعّال جدًّا على مستوى التّطبيقات يُمهّد الحواسيب حول العالم لتبادل الأحاديث النّافعة، واسمه Hypertext Transfer Protocol، أو HTTP اختصارًا؛ وهو بروتوكول يُصنّف ضمن طبقة التّطبيقات فوق TCP/IP، وهو أيضًا بروتوكول للتواصل. كثيرًا ما يغيب شرح HTTP في دروس التصميم والتطوير للويب، وهذا أمرٌ مُخزٍ: ففهمه يُعينك في تحسين تفاعل المستخدم وتحقيق أداء أفضل للموقع وإنشساء أدوات فعّالة لإدارة المعلومات على الويب. هذا المقال هو الجزء الأول من سلسلة تهدف إلى تعليم أساسيّات HTTP، وكيف يمكن استخدامه بفعّاليّة أكبر. سنطّلع في هذا الدّرس على محلّ HTTP من الإنترنت. ما معنى بروتوكول تواصل؟ قبل الدّخول في التفاصيل، لنتخيّل موقفًا بسيطًا يحدث فيه تواصل بين طرفين، ولكي يحدث هذا التواصل، فإن على الطّرفين (برنامجين كانا أم جهازين أم شخصين... إلخ.) أن يتّفقا على: الصياغة (تنسيق البيانات) الدلالات (معلومات التحكم والتعامل مع الأخطاء) التوقيت (تطابق السرعة والتتالي) عندما يلتقى اثنان، فإنّهما يتفاهمان من خلال بروتوكل تواصل: ففي اليابان مثلًا، يؤدي أحدهما حركة جسدية، كأن يحني ظهره. وهذه هي الصياغة المعتمدة في التواصل. وفي عادات اليابان، تدل حركة الانحناء هذه (وحركات أخرى مشابهة) على التّحيّة. وبحركة انحناء أحد الشخصين للآخر تنطلق سلسلة من الأحداث بينهما مرتبة بتوقيت معيّن. يتركّب بروتوكل التواصل عبر الشبكات من المكوّنات ذاتها. فأمّا الصّياغة فهي سلسلة من الحروف كالكلمات المفتاحيّة المُستخدمة في كتابة البروتوكول، وأمّا الدلالات فهي المعاني المُرتبطة بكلّ من هذه الكلمات، وأمّا التوقيت فهو ترتيب تبادل هذه الكلمات بين الطّرفين. ما محلّ HTTP من الإنترنت؟ يقوم HTTP نفسه فوق بروتوكولات أخرى. فعند الاتصال بموقع ويب مثل www.example.org، يستخدم وكيل المستخدم (user agent) مجموعة بروتوكولات TCP/IP، والتي صُمّمت في عام 1970 مؤلّفة من 4 طبقات: طبقة الوصلة (Link)، والتي تصف الوصول إلى الوسيط المادّي (كاستخدام بطاقة الشبكة مثلًا) طبقة الإنترنت، والتي تصف كيفيّة تغليف البيانات وتوجيهها (IP أو Internet Protocol) طبقة النقل (Transport)، والتي تصف كيفية نقل البيانات من نقطة الانطلاق إلى الوجهة (TCP وUDP) طبقة التطبيقات (Application)، والتي تصف معنى وصياغة الرسائل المنقولة (HTTP) فـ HTTP إذًا هو بروتوكول على مستوى التطبيقات يقوم على الطبقات السابقة، لا تنسَ هذه الفكرة. يُساعد فصل هذا النّموذج في طبقات على تطوير أجزاءه بصورة منفصلة دون الحاجة لإعادة تصميمها جميعًا. فمثلًا، يمكن تطوير TCP، باعتباره بروتوكولًا في طبقة النّقل، دون الحاجة لتعديل HTTP كونه برتوكولًا في طبقة التّطبيقات. لكن الواقع العمليّ يجعل التفاصيل أكثر تعقيدًا عند الحاجة للوصول إلى تواصل ذي أداء عالٍ. سنركّز في الأجزاء الأولى من هذه السّلسلة على فصل الطّبقات كما هو مُعرَّف في نموذج TCP/IP. صُمِّم HTTP بغرض تبادل المعلومات بين برنامجين من خلال رسائل تُسمّى رسائل HTTP، وتؤثّر طريقة تشكيل هذه الرسائل في العميل (client) والخادوم (server) والأطراف الوسيطة (كالخواديم الوكيلة proxies). لنتواصل مع خادوم! يُعتبر المنفذ رقم 80 المنفذ المبدئيّ للاتّصال بخواديم الويب، ويمكن التأكّد من ذلك بتجربة نُجريها من الطّرفيّة. افتح الطّرفية (أو سطر الأوامر) وجرّب الاتصال بـ www.opera.com على المنفذ 80 مُستخدمًا الأمر التالي: telnet www.opera.com 80 من المُفترض أن يكون الناتج: Trying 195.189.143.147... Connected to front.opera.com. Escape character is '^]'. Connection closed by foreign host. كما نرى فإن الطرفيّة تحاول الاتصال بالخادوم ذي عنوان IP‏ 195.189.143.147. إن لم نفعل شيئًا آخر سيغلق الخادوم الاتصال بنفسه. من الممكن بالطّبع استخدام منفذ آخر بل وحتّى بروتوكول تواصل آخر، ولكن هذه هي الإعدادات الشّائعة. لنتحدّث بلغة HTTP! لنحاول ثانية التواصل مع الخادوم. أدخل الرسالة التالية في الطرفية (أو سطر الأوامر): telnet www.opera.com 80 ما إن يُؤسّس الاتصال، اكتب رسالة HTTP التالية بسرعة (قبل أن يُغلق الخادوم الاتصال بنفسه)، ثم اضغط Enter مرّتين: GET / HTTP/1.1 Host: www.opera.com تُحدّد هذه الرسالة: GET: أي أننا نريد "الحصول على" تمثيل البيانات. /: أي أنّ المعلومات التي نريدها مخزنة في جذر الموقع. HTTP/1.1: أي أننا نتحدث ببروتوكول HTTP ذي الإصدارة 1.1. Host:: أي أننا نريد الوصول إلى الموقع المُحدّد. www.opera.com: اسم الموقع هو www.opera.com. على الخادوم الآن أن يُجيب طلبنا. من المفترض أن تمتلئ نافذة الطرفية بمحتوى مشابه لما يلي: HTTP/1.1 200 OK Date: Wed, 23 Nov 2011 19:41:37 GMT Server: Apache Content-Type: text/html; charset=utf-8 Set-Cookie: language=none; path=/; domain=www.opera.com; expires=Thu, 25-Aug-2011 19:41:38 GMT Set-Cookie: language=en; path=/; domain=.opera.com; expires=Sat, 20-Nov-2021 19:41:38 GMT Vary: Accept-Encoding Transfer-Encoding: chunked <!DOCTYPE html> <html lang="en"> ... يقول الخادوم هنا: "أنا أتحدث HTTP الإصدارة 1.1. نجحَ طلبك، لذا أجبت بالرمز 200." الكلمة OK ليست إلزامية والهدف منها شرح معنى الرمز للبشر - وهي تُشير في حالتنا إلى أن الأمور تسير على ما يرام وأن رسالتنا قُبلت. يلي ذلك سلسلة من "ترويسات HTTP" التي تُرسل لتصف الرسالة، وكيف يجب أن تُفهم. أخيرًا نجد محتويات الصفحة المُستضافة على جذر الموقع، والّتي تبدأ بـ <!DOCTYPE html>.

يشرح هذا الفيديو كيفية استخدام GitHub Pages لاستضافة الصفحات. وسنشرح فيه صفحات المشاريع، وصفحات المستخدم أو المنظمة. لتتعرف أكثر على نظام Git وكيفية استخدامه، ننصحك بمشاهدة فيديو أساسيات Git في أكاديمية حسوب. قسم Git في أكاديمية حسوب غني بالمقالات المفيدة حوله.

كان ختام المقالة السّابقة قولُنا أن بروتوكول HTTP يدير التّفاعل بين عميل وخادوم، وقد شرحنا فكرة ترويسات HTTP. سيكون لدينا الكثير مما يُقال عن هذه الترويسات في أجزاء تالية من هذه السّلسلة، فهذه الترويسات تؤثّر في التّفاعل بين الطّرفين وفي أداء الموقع. أمّا اليوم، فسنطّلع على جانب لا يقلّ أهمّيّة عن التّرويسات، وهو رموز إجابات HTTP. نزهة في الشوارع خرجت ذات صباح قاصدًا مقهى لأقرأ كتابًا، لكنّني وجدت المقهى مُغلقًا حينها، وقد كُتب على لوحة على الباب أنّ احتفالًا يُقام خلال هذا الأسبوع، ولذلك فإنّ المقهى سينتقل مؤقتًا ليُقدّم القهوة في شاحنة الطّعام (التي سمّوها "307") قرب النهر. ذهبت إلى ذلك المكان واستمتعت بشرب القهوة. قرّرت بعدئذٍ التجوّل في مكتبتي المفضّلة في المدينة، فوجدتها مُغلقةً كذلك، إلّا أنّني رأيت لوحة على الباب تقول أن المكتبة ستتوسع ولذلك انتقلت بشكل دائم إلى مبنى جديد في 301 شارع برنرز-لي. لم يُزعجني ذلك، فالمكان قريب. ذهبت إلى هناك فاستقبلني الموظّفون بالتّرحاب: "200 سلامة!". حسنًا، أنا أبالغ قليلًا، لكنّك فهمتني! في طريقي إلى البيت، وجدت متجرًا مهجورًا غطّى الغبار أبوابه في 410 شارع برنرز-لي، وقد أُلصقت ورقةٌ على الباب تقول أنّ صاحب المحلّ تقدّم بطلب إشهار الإفلاس واضطّر إلى إغلاق المتجر، إلى الأبد. وكأنّ العجائب لم تنتهِ اليوم، إذ رأيت في نهاية 500 شارع برنرز-لي مبنى من 4 طوابق وقد انهار بالكامل. ما الذي حدث هنا؟! لم يكن يومي سيئًا بالمجمل، لذا قرّرت أن أكمل يومي بكتابة مقال عن رموز HTTP الّتي تُرسلها الخواديم إلى العملاء الّذين يرسلون الطّلبات. صياغة جواب HTTP وسطر الحالةتطرّقنا في المقال السّابق إلى السّطر الأول من صيغة الطّلبات الّتي يُرسلها العميل (بما في ذلك أفعال HTTP). وسنركّز الآن على السّطر الأول من رسالة الجواب الّتي تصل من الخادوم، ومعاني الرّموز المختلفة الّتي تظهر في هذا السّطر. لاحظ التّشابه بين نوعي الرّسائل (الطّلبات والإجابات). فكما ينصّ توثيق الإصدارة 1.1 من HTTP: إما إن تكون رسالة HTTP طلبًا من العميل إلى الخادوم أو جوابًا من الخادوم للعمل. من حيث الصّياغة، لا يختلف نوعا الرّسائل إلى في السّطر الأوّل، والذي إمّا أن يكون سطر طلب (للطلبات) أو سطر حالة (للإجابات)، وفي خوارزميّة تحديد طول متن الرّسالة (القسم 3.3). يُدعى السّطر الأول في الجواب إذًا سطر الحالة. يبدأ السّطر بإصدارة بروتوكول HTTP ثمّ مسافة ثم رمز من ثلاثة أرقام، ثم مسافة ثمّ جملة تشرح الرّمز، كهذا المثال: HTTP/1.1 200 OKالجملة القصيرة الأخيرة غير إلزامية وعلى العملاء تجاهلها، ولا ينبغي أن يستخدمها برنامج بغرض تفسير الجواب. لنطّلع الآن على بعض أكثر رموز الحالة شيوعًا وما يعنيه كلّ رمز منها. رموز الحالة في HTTP200، كلّ شيء على ما يرام! في كلّ مرّة يريد شخصٌ ما زيارة الصّفحة الرئيسيّة لموقع Opera، يُرسل العميل طلبًا إلى http://www.opera.com/ برسالة مثل هذه: GET / HTTP/1.1 Host: www.opera.com Accept-Language: fr User-Agent: BrowseAndDream/1.0يُحلّل الخادوم الرّسالة الّتي وصلته من العميل ويُرسل جوابًا بناء على ما فهمه من الرابط والترويسات. وكما ذكرنا في المقالتين السّابقتين، يكون الهدف الأهمّ هو إدارة التّواصل بين الطّرفين بما يحقّق أقصى فائدة لكليهما. إن فهم الخادوم الرّسالة، فإنّه يرسل رسالة تبدأ بـ200 OK، أي أنّ كلّ شيء على ما يُرام. تحوي الرسالة بضع ترويسات إجابة ثمّ محتوى الصّفحة، والّذي قد يختلف بناءً على ترويسات الطّلب، فلا إجابة مُطلقة. فكما في كل تفاوض، يجري حوارٌ بين الطّرفين للوصول إلى أفضل تسوية. فيما يلي مثالٌ عن إجابة على الطّلب السّابق: HTTP/1.1 200 OK Date: Fri, 24 Aug 2012, 13:56:44 GMT307، انتقلتُ مؤقّتًا إلى مكان آخر يمكن للخادوم أن يجيب العميل برسالة تبيّن أنّ المحتو قد انتقل مؤقتًا إلى مكان آخر. ويفيد هذا عندما تريد إعادة توجيه العميل إلى صفحة مُعيّنة لفترة قصيرة. افترض مثلًا موقعًا يُعطي توقّعات الطقس لتاييبي، وقد شبّ إعصار هائل مؤخّرًا فيها. سيكون من المفيد إعلام المُستخدمين بوقوع هذا الإعصار حتى هدوئه. قد يكون الطّلب مثل هذا: GET /taiwan/weather/today HTTP/1.1 Host: meteo.example.orgقد يرغب الخادوم بإجابة العميل قائلًا: "سأنقلك إلى صفحة أخرى تُعطيك معلومات مفصّلة عن الأزمة الحاليّة في تاييبي". قد تبدو الإجابة مثل هذه: HTTP/1.1 307 Temporary Redirect Date: Fri, 24 Aug 2012, 13:56:44 GMT Location: http://meteo.example.org/taiwan/weather/crisisيتبع المتصفح عادةً الوجهة الجديدة المذكورة في سطر Location. يمكن أن يطلب الخادوم إعادة التّوجّه إلى نطاق آخر على الويب. وحالما تنتهي الأزمة، يمكن للخادوم إزالة إعادة التّوجيه. ينبغي ألّا يتذكّر العميل إعادة التّوجيه للأبد. فهذا مُهمّ في حالة الإشارات المرجعيّة وسجل التصفّح. من الممكن تصميم برنامج يُدير عمليّات إعادة التّوجيه هذه بطريقة مُفيدة. لا يرى المُستخدم إعادة التّوجيه في معظم المتصفّحات، ولكن من الممكن إرسال متن مع جواب إعادة التّوجيه يعرض على المستخدم رسالة تحوي رابطًا للمكان الجديد يُسمح للمُستخدم بنقره. 301، تغيّر العنوان بشكل دائم عند إدارة المعلومات على موقع ويب، قد نحتاج إلى إعلام العميل (ومستخدميه) أن الصّفحة المطلوبة قد انتقلت بشكل دائم. ففي الشّركات، يُعاد تنظيم الأقسام أحيانًا بعد الاتّحاد مع شركة أخرى أو عند تغيّر الأولويّات. لنفترض مثلًا أن وحدة الآلات الكهربائيّة في شركة تقنية قد ضُمَّت إلى قسم الإلكترونيّات. وعندها يمكن إعادة توجيه عميل يطلب: GET /section/electromech/about HTTP/1.1 Host: inc.example.comإلى: HTTP/1.1 301 Moved Permanently Date: Fri, 24 Aug 2012, 13:56:44 GMT Location: http://inc.example.com/section/electronic/aboutالفرق بين الرمز 307 الّذي شرحناه في الفقرة السّابقة، والرّمز 301، أنّ التّغيّر في العنوان دائم في حالة الرّمز الثّاني، وهي رسالة واضحة من الخادوم للعميل تطلب منه أن يُغيّر الإشارات المرجعيّة المحفوظة لديه إلى العناوين الجديدة. يمكن للمتصفّح تنفيذ ذلك من تلقاء نفسه أو بعد استشارة المستخدم. لإعادة توجيه الروابط القديمة فائدتان مُباشرتان. الأولى هي كسب ثقة المستخدمين بموقعك، بأن تُبدي اهتمامك بالمُحافظة على المعلومات الّتي تستضيفها. والثّانية هي استقرار الموارد، فالمواقع الّتي تُعرف بمحافظتها على الرّوابط تكون أكثر احتمالًا لأن تُشير إليها مواقع أخرى على المدى البعيد، ممّا يزيد ترتيب الموقع في مُحرّكات البحث. 410، وداعًا يا صديقي العزيز! تحتاج بعض المواقع أحيانًا إلى إبلاغ العميل باختفاء المعلومات الّتي كانت موجودة على رابط مُعيّن للأبد. وقد يكون لهذا مُبرّراته. نحن نعلم أن الروابط الجيّدة لا تتعطّل؛ ولكنّ الرّمز 410 Gone هو الوسيلة الوحيدة المناسبة لتعطيلها. لنكن أكثر دقّة: هذا الرّمز هة طريقة لإخبار المستخدمين أن المحتوى الّذي كان موجودًا من قبل على هذا الرابط قد حُذِفَ عمدًا. وهذا معناه أن الخادوم يطلب من العُملاء الّذي يقصدون هذا الرّابط ألّا يتذكّروه. ففي متصفّح يستخدم الإشارات المرجعيّة وسجّلات التّصفّح، يُعتبر هذا الرّمز إبلاغًا للمتصفّح بسلامة حذف هذا الرّابط. افترض شبكة اجتماعيّة يُطلب فيها الوصول إلى صفحة مُستخدم: GET /people/jeanpaulsartres HTTP/1.1 Host: socialnetwork.example.comقرّر المستخدم أن يُغادر شبكتك الاجتماعيّة ويُغلق حسابه، قد تُريد أن تُبلغ غيره من المستخدمين الّذين يطلبون صفحته من سجلّ المتصفّح أو إشاراته المرجعيّة: HTTP/1.1 410 Gone500، يا للمصيبة! قد يتعذّر على الخادوم إجابة الطّلب لسبب مجهول. لا يتدخّل HTTP على الإطلاق في تفاصيل عمل الموقع، مثل طريقة تخزين قواعد البيانات على الخادوم، أو كيف يجلب الخادوم البيانات ويُعالجها. ربّما توقّف الطّلب عند برنامج مُعيّن على الخادوم ولم يصل الجواب، وعندها يُبلغ الخادوم العميل ومستخدمه عن وقوع خطأ ما غير معروف بجواب مثل هذا: HTTP/1.1 500 Internal Server Errorاستخدام سطور الحالة في الإجابات الّتي تُرسلها الخواديمعند تصميم نظام لإدارة المحتوى، يكون من الضّروري فصل الطّبقات بصورة موارد وروابط إلى هذه الموارد، فهذا مُفيد عند إجابة طلبات العملاء بالمعلومات الصّحيحة، وتقديم المحتوى للبرامج أو للبشر هو شيء جوهريّ في صفة الخواديم. ولأنّ المعلومات تتغيّر وتتطوّر،فإنّ تصميم الخواديم بما يراعي هذه النّقطة يُعطيها مرونة أكبر. لا تهدف هذه السّلسلة إلى شرح تفاصيل تطبيق إجابات الخواديم من النّاحية البرمجيّة، ولكنّنا سنستعرض مثالين يُفيدان كنقطتي انطلاق، على الرّغم من أنّهما قد لا يُفيدان في حالة المواقع الضّخمة الّتي تضمّ آلاف الرّوابط. إعادة التّوجيه في Apacheفي حال أردت إعادة توجيه http://inc.example.com/section/electromech/about إلى http://inc.example.com/section/electronic/about، يمكن إضافة ملف .htaccess في جذر الموقع يحوي التّعليمات التّالية: RewriteEngine On RewriteBase / RewriteRule ^/section/electromech/about /section/electronic/about [L,R=301]مُلاحظة: هنالك طرق أخرى لتنفيذ هذا الغرض، كاستخدام httpd.conf أو قواعد البيانات أو من خلال النّصوص البرمجيّة... إلخ. واختيار الطّريقة المناسبة يعتمد على تصميم النّظام. إعادة التّوجيه في nginxخادوم Nginx هو الآخر شائع الاستخدام، وخصوصًا على شبكات توفير المحتوى (CDNs). يمكن إعادة كتابة المثال السّابق لاستخدامه مع nginx: server { listen 80; server_name inc.example.com; rewrite ^/section/electromech/about http://inc.example.com/section/electronic/about permanent; }تصنيف رموز HTTPتعرّفنا على بضع رموز HTTP فيما سبق، ولكنّها أكثر من ذلك، وبعض هذه الرّموز ذائع الصّيت مثل 404 Not Found، وبعضها مغمور لا يُرى كثيرًا. وفي كلا الحالتين يمكن الاستعانة بالرّقم الأوّل للرّمز لأخذ فكرة عن معناه، كون هذا الرقم يُشير إلى العائلة الّتي ينتمي إليها الرّمز: 1xx (بيان): وصل الطّلب، وتجري مُعالجته.2xx (نجاح): وصل الطّلب وفُهم وقُبل.3xx (إعادة توجيه): يُطلب إجراء تالٍ لإكمال الطّلب.4xx (خطأ من جهة العميل): صياغة الطّلب خاطئة أو يتعذّر تحقيقه.5xx (خطأ من جهة الخادوم): فشل الخادوم في تحقيق طلب يبدو سليمًا.الخلاصةإلى هنا نكون قد وصلنا إلى نهاية دراستنا لرموز حالة HTTP. أحثّك على الاطّلاع على كلّ رمز والتّعرّف على فائدته. لبعض هذه الرموز تأثيرات خاصّة على التّخزين المؤقّت وعلى متن رسالة HTTP؛ سنُلقي نظرةً على التّخزين المؤقت لاحقًا. تذكّرتُرسل الخواديم رموز حالة HTTP لتزويد العميل بمعلومات سريعة عن الجواب.تؤثّر رموز HTTP في التّخزين المؤقّت ومُعالجة الرّوابط من جهة العميل.تُصنّف رموز HTTP ضمن عدّة مجموعات.ترجمة (بشيء من التّصرّف) لمقال HTTP: Response Codes لصاحبه Karl Dubosy.

تعلمنا في الجزء السابق أن HTTP بروتوكول على مستوى التطبيقات. حان الوقت لنفهم كيفية استخدام هذا البروتوكول للتواصل بين العميل والخادوم. جلب الأشياء من الويب تذكر أن عميل HTTP (وهو المتصفح عادةً) هو الطرف الذي يبدأ بإرسال الطلب إلى الخادوم. يسمح بروتوكول HTTP للعميل بالتعبير عن نيّته من خلال بضعة مُكوّنات: الرابط (URI)، وأفعال HTTP، وترويساته. تسمية الأشياء تمثّل الروابط (URIs) حجر الأساس في الويب، لأنّها تحل مشكلة مهمّة على مستوى الإنترنت بكاملها، وهي مشكلة منح الأشياء مُعرّفًا تنفرد به على الشّبكة. افترض أنّك سألت شخصًا أن يجلب لك شيئًا ويُحضره إليك، يمكن عدّ الطرق الممكنة للطلب على الأصابع. فعادةً ما تُعرّف الكلمات الّتي تستخدمها الشيء الّذي تريده. بإمكانك أن تطلب من صديقك قائلًا: "اجلب لي الكتاب." قد يجيبك صديقك: "حاضر. ولكن أي كتاب؟". فتقول أنت: "الكتاب في الغرفة الأخرى." فيذهب صديقك إلى الغرفة ويسأل: "أي كتاب قلت؟" فتقول أنت وقد شعرت بالضّيق: "الأخضر!" ليقول صديقك: "تمهّل لحظة... هناك كتابان أخضران في الغرفة!" وعندها تنهض لتحضر الكتاب بنفسك. كان الأمر ليكون أكثر بساطة لو أننا وحدنا طريقة نُحدّد فيها الأشياء بطريقة مميّزة للوصول إليها لاحقًا. إحدى الوسائل الممكنة هي الاعتماد على الذاكرة. كيف نعطي الأوامر لشخص ما ليحضر إلينا الغرض المطلوب؟ لنُنشئ نظامًا لذلك: قص ورقات صغيرة أو استخدم ورق الملاحظات اللّصّاق. ضع هذه الأوراق على الأغراض في الغرفة المجاورة أو على الطّاولة (كالكتب مثلًا). اكتب مُعرّفًا مُميِّزًا على كل ورقة. كرّر العملية في غرفة مجاورة أو على طاولة مجاورة. تذكّر أن هذا النّظام لا يقتصر على أغراضك، بل يمتد ليسمح بنوعٍ من التّواصل بين الأغراض جميعها. طبّقت هذا النّظام على أغراضي، فكتبت على كل قطعة ورق واحدًا من المُعرّفات التالية: myRoom.org/table/book/001 myRoom.org/shelf/book/002 otherRoom.org/cup/001 otherRoom.org/flower/001 otherRoom.org/book/001 أعتقد أنك الآن فهمت ما أقصد. لدينا الآن نظام من اللصاقات الّتي تستخدم لتحديد كل شيء في المكان بدقة. في الويب، نحن نتعامل مع فضاء معلومات واللصاقات المُستخدمة ليست سوى الروابط (URIs). الوصول إلى الأشياء المُسمَّاة شرحنا كيف يُبنى طلب HTTP في المقال السابق من خلال الطرفية. استخدمنا بناءً بسيطًا مع فعل HTTP المُسمّى GET مع ترويسة واحدة: Host. GET / HTTP/1.1 Host: www.opera.com القائمة الكاملة لأفعال HTTP الحالية هي: OPTIONS، GET، HEAD، POST، PUT، DELETE، TRACE، CONNECT. لكل فعل دورٌ مختلف عن الأفعال الأخرى وسنشرح ذلك في المقالات التالية. أكثر الأفعال استخدامًا هو GET، ففي كلّ مرة نُدخل عنوان HTTP في شريط العناوين في المتصفح، فإنّنا نرسل طلب GET إلى خادوم. في عالم الويب يُرسل العميل معلومات أكثر (المزيد من ترويسات HTTP) إلى الخادوم للتفاهم على المطلوب. يستغل الخادوم هذه المعلومات ليُعدّل الجواب بما يناسب الترويسات. تتوفّر أداة عمليّة جدًا في Opera Dragonfly لإنشاء طلبات HTTP مُخصّصة وفحص إجابة الخادوم. يمكنك إيجادها في قسم Network في تبويب "Make Request". هنالك ثلاث مناطق في تبويب Make Request: الرابط (URL): مُعرّف المُحتوى (أو عنوان الويب) متن الطّلب (Request body): ما سيُرسله العميل إلى الخادوم (يُرسل الزّر "Send request" الطّلب إلى الخادوم عبر الشّبكة) الجواب (Response): جواب الخادوم بعد إرسال الطّلب تخصيص طلب HTTP انسخ http://www.opera.com/ إلى قسم URL. انسخ والصق طلب HTTP التّالي إلى قسم "Request body" في تبويب Network. أضفنا الترويسة Accept-Language إلى طلب HTTP السابق. اضغط الزر "Send request". GET / HTTP/1.1 Host: www.opera.com Accept-Language: en سيُجيب خادوم Opera بجواب HTTP مؤلّف من بضع ترويسات يليها محتوى المستند. قد تحتاج إلى تمرير النافذة، لأن الجواب قد يكون طويلًا. لاحظ أن المُستند باللغة الإنكليزيّة، ليس فقط من حيث اللغة الّتي كتب بها، بل أيضًا يُنصّ على ذلك صراحةً في خاصّة lang على ال عنصر html: <!DOCTYPE html> <html lang="en"> لنُجرّب الفرنسيّة: GET / HTTP/1.1 Host: www.opera.com Accept-Language: fr سُيجيب الخادم هذه المرة بالفرنسيّة، ويتبيّن ذلك في نص المستند وفي مصدره: <!DOCTYPE html> <html lang="fr"> لاحظ أنّنا استخدمنا الرابط نفسه بالضّبط (http://www.opera.com/) ولكنّنا تلقّينا إجابتين مُختلفتين لا لشيء إلا لأننا غيّرنا الترويسة Accept-Language. لاحظ أيضًا أنّ الخادوم أجاب بترويسات كثيرة تُعطينا معلوماتٍ عن حالة المحتوى ونوعه... إلخ. يسمح هذا للعميل بتعديل أسلوب معالجة المستند. يمكنك تجربة لغات مُختلفة مثل اليابانية (ja) والألمانية (de)... إلخ. ما الذي يحدث إن طلبنا لغة غير موجودة على الخادوم؟ جرّب مثلًا الصّينيّة (zh): GET / HTTP/1.1 Host: www.opera.com Accept-Language: zh ستتلقى النسخة الإنكليزية من الموقع. هل هذا مُحيّر؟ الحقيقة أنّ هذا الأمر يعتمد على تصميم الموقع ذاته. فقد يُصمم جواب HTTP بأسلوب آخر، كأن يُجيب الخادوم "لا، ما من نسخة صينية من الموقع لدينا"، أو "ليست لدينا نسخة صينية، ولكن لدينا اللغات التالية: ...). ولكن فريق تجربة المستخدمين في Opera قرر إرسال النسخة الإنكليزية من الموقع عند طلب لغة غير مُتوفّرة. المسألة مسألة اختيار، فلا قاعدة تُفرض على المواقع بهذا الشأن. ولهذا السّبب أقوم عادةً بتعليم مُصمّمي تجربة الاستخدام ومُطوّري الواجهات بعض أساسيّات HTTP، فهو بروتوكول يتوسّط التفاعل بين العميل والخادوم، وعليه فإنّ فهمه يُساعد في تصميم تفاعلات ذات معنى عند بناء المواقع، وذلك للبشر والآلات معًا (كالبرامج الّتي تستخدم الواجهات البرمجيّة (APIs) وما شابهها... إلخ). تذكّر URI: نظام لتعريف المعلومات على الشبكة. أفعال HTTP: يتضمّن البروتوكول حاليًا الأفعال التّالية: OPTIONS، GET، HEAD، POST، PUT، DELETE، TRACE، CONNECT. وقد تعرّفنا في هذه المقالة على أكثرها استخدامًا وهو GET. ترويسات HTTP:** الترويسات هي بيانات إضافية يُرسلها العميل لإعطاء معلومات أكثر عن البيانات المُتبادلة بين العميل والخادوم. تُفيد بعض هذه الترويسات الخادوم بحيث يختار الأسلوب الأفضل للإجابة. ترجمة (بشيء من التّصرّف) لمقال HTTP: Let’s GET It On! لصاحبه Karl Dubosy.

تظهر لنا الإحصاءات أن أكثر من 80٪ من تطبيقات الويب ومواقع الويب مدعومة بخوادم الويب مفتوحة المصدر. في هذه المقالة، سألقي نظرة على خوادم الويب المفتوحة المصدر الأكثر شعبية، وأراجع تاريخها وتقنياتها وميزاتها وغير ذلك. وسوف أقدم أيضًا بعض النصائح حتى تتمكن من النشر بسهولة على واحد من خوادم الويب هذه بنفسك. وفقًا لويكيبيديا ، فإن خادوم الويب هو "نظام حاسوبي يعمل على معالجة الطلبات عبر بروتوكول HTTP، وهو بروتوكول الشبكة الأساسي المستخدم لتوزيع المعلومات على الشبكة العالمية، ويمكن أن يشير المصطلح إلى النظام بأكمله، أو تحديدًا إلى البرنامج الذي يشرف على الطلبات" ، في هذه المقالة سنتعامل مع البرامج التي تعالج طلبات الويب من المستخدمين النهائيين. Apache HTTP تم إطلاق خادوم Apache HTTP - والذي غالبا ما يشار إليه باسم httpd أو Apache- في عام 1995، واحتُفل بعيد ميلاده العشرين في فبراير 2015. يشغل Apache 52٪ من جميع المواقع على مستوى العالم، وهو خادوم الويب الأكثر شعبية في العالم. يغلب أن يكون Apache مشغلا على لينكس ، ولكن يمكنك أيضا تشغيله على OS X و ويندوز. ليس غريبا أن Apacheمرخص بموجب رخصة Apache الإصدار 2. وهو يستخدم معمارية الوحدات، والتي يمكن بها إضافة وحدات جديدة لتمديد عمل الخادوم وزيادة ميزات أخرى . على سبيل المثال سيؤدي تحميل الوحدة mod_proxy إلى السماح للبروكسي على الخادوم الخاص بك، وسيعمل mod_proxy_balancer على تمكين موازنة التحميل لجميع البروتوكولات المدعومة. اعتبارا من الإصدار 2.4 صار Apache يدعم HTTP/2 من خلال الوحدة الجديدةmod_http2. وبما أن خادوم Apache HTTP هو خادوم الويب الأكثر شعبية منذ عام 1996، فإنه "يستفيد من الوثائق الكبيرة والدعم المتكامل من مشاريع البرامج الأخرى ." يمكنك العثور على مزيد من المعلومات حول Apache في صفحة مشروع. NGINX بدأ Igor Sysoev تطوير NGINX مرة أخرى في عام 2002. وقد طوّر NGINX جوابًا على ما يسمى مشكلة C10K ، وهو اختصار لــ "كيف يمكنك تصميم خادوم الويب الذي يمكنه التعامل مع عشرة آلاف اتصال متزامن ؟ " . NGINX يحل هذا المشكل وهو الثاني على قائمة خوادم الويب المفتوحة المصدر حسب الاستخدام، فهو يشغل ما يزيد عن 30٪ من المواقع. يعتمد NGINX على معمارية الأحداث الموجهة (event-driven) غير المتزامنة ، وذلك ما يساعده في تحقيق هدفه ، ألا وهو التعامل مع أكبر عدد ممكن من الاتصالات ، وبسبب ذلك أصبح خادوم الويب الأكثر شعبية جدًا بين مديري الأنظمة بسبب استخدامه لموارد خفيفة وقدرته على التوسع بسهولة. يتم إصدار NGINX تحت رخصة BSD-like ، ولا يقتصر استخدامه على خدمة الويب فحسب، بل أيضًا كخادوم وكيل proxy أو موازن التحميل load-balancer ، يمكنك العثور على مزيد من المعلومات حول NGINX في موقع المجتمع. Apache Tomcat Apache Tomcat هو حاوية جافا (اسمها الكامل Java servlet) مفتوح المصدر. وهو برنامج جافا بقدرات ملقمات الويب، على الرغم من أن servlet يمكن أن تستجيب لأي أنواع من الطلبات، فإنها استخدامها شائع فقط في تنفيذ التطبيقات المستضافة على خوادم الويب. servlet هي نظير تقنيات الويب الديناميكية الأخرى مثل PHP و ASP.NET، تم التبرع بالشيفرة المصدرية لــ Apache Tomcat من قبل شركة Sun Microsystems إلى مؤسسة Apache للبرمجيات في عام 1999، وأصبحت مشروع Apache الأعلى قيمة في عام 2005. وهي حاليًا تحتل 1٪ فقط من جميع المواقع. يستخدم Apache Tomcat -والذي يصدر تحت رخصة Apache الإصدار 2- عادة لتشغيل تطبيقات الجافا . ومع ذلك، فإنه يمكن تمديده بـ Coyote لأداء دور خادوم الويب العادي لكي يخدم الملفات المحلية كوثائق HTTP ، يمكنك الإطلاع على مزيد من المعلومات على موقع المشروع. غالبًا ما يتم ذكر Apache Tomcat مع خوادم تطبيقات الجافا المفتوحة المصدر الأخرى. مثل JBoss و Wildfly و Glassfish Node.js Node.js هي بيئة جافا سكريبت من جانب الخادوم ، وهي تعمل لتشغيل تطبيقات الشبكة، لا تحتل Node.js إلا مكانة منخفضة في السوق ، فنسبة تشغيلها لا تتجاوز 0.2٪ من المواقع . طور هذه البيئة في الأصل Ryan Dahl في عام 2009 ، وتسيرها الآن مؤسسة Node.js وبمساعدة مؤسسة لينكس. الفرق بين Node.js وغيرها من خوادم الويب الشعبية الأخرى هو أنها بيئة تشغيل عابرة للمنصات لتشغيل تطبيقات الشبكة، تطبّق Node.js معمارية الأحداث الموجهة event-driven القادرة على الإدخال والإخراج غير المتزامن. هذه الخيارات في التصميم هي الأمثل إنتاجية وقابلية للتوسع في تطبيقات الويب مما يسمح بتشغيل الاتصالات وألعاب المتصفح في الوقت الحقيقي، يظهر الفرق أيضًا في أن Node.js هو في الحقيقة جزء من مراحل تطوير الويب (HTML, CSS, and JavaScript)، على عكس Apache أو NGINX التي هي جزء من العديد من البرامج المختلفة. يتم إصدار Node.js تحت مزيج من التراخيص . يمكن الحصول على مزيد من المعلومات على الموقع الإلكتروني للمشروع . Lighttpd أطلق Lighttpd في أول إصدار له في مارس 2003. وهو حاليًا يشغل 0.1٪ من المواقع ويتم توزيعه تحت رخصة BSD. يميز Lighttpd أنه يعمل بموارد أقل مقارنة بالخوادم الأخرى (من حيث الذاكرة ، والمعالج) وهذا يجعله أسرع أداء واستجابة ، وهو يستخدم معمارية الأحداث الموجهة event-driven architecture ، ويعتبر الخيار الأمثل في حال كثرة الاتصالات المتزامنة وموارد أقل من العتاد، يدعم Lighttpd الكثير من التقنيات مثل : FastCGI, SCGI, Auth, Output-compression, URL-rewriting. كثيرًا ما يستعمل Lighttpd مع إطار العمل Ruby on Rails وإطار العمل Catalyst. لمزيد من المعلومات حوله قم بزيارة الصفحة الرئيسية للمشروع . نصائح إذا كنت ترغب أن تجرب واحدا من خوادم الويب الأكثر شعبية فأنا أوصي بشدة بتحميل التجميعية LAMP (Linux, Apache, MySQL, PHP) أو التجميعية LEMP (Linux, NGINX, MySQL, PHP) ، هناك الكثير من هذه التجميعيات المتاحة التي توفير نكهات مختلفة ، وعادة ما يتم توفيرها كمثبتات بنقرة واحدة، أو متوفرة كحزمة في مدير برامجك على لينوكس. بعد الانتهاء بنجاح من عملية التثبيت يمكنك بدء تشغيل خادوم الويب الخاص بك، ومحاولة إخراج المثال المشهور مرحبا بالعالم . انها طريقة رائعة للبدء في اكتشاف مداخل ومخارج خادوم الويب الخاص بك، وكيف تعمل خوادم الويب في الحياة التقنية الحقيقية. ترجمة -وبتصرّف- للمقال Top 5 open source web servers لصاحبه Robin Muilwijk حقوق الصورة البارزة محفوظة لـ Freepik

إنّ التخزين المؤقّت 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.

تملك المتصفحات الحديثة أدوات تطوير مبينة فيها للتعامل مع لغة JavaScript وتقنيات الويب الأخرى، وهذه الأدوات تتضمن سطر الأوامر (Console) الذي يشبه سطر الأوامر الخاص بأنظمة يونكس، إضافةً إلى أدواتٍ لتفحص (inspect) شجرة DOM، وأدوات للتنقيح (debugging)، وتحليل نشاط الشبكة. يمكن استخدام سطر الأوامر (Console) لإنشاء سجل من المعلومات كجزءٍ من عملية تطوير تطبيقات JavaScript، ويسمح لك بالتفاعل مع صفحة الويب بتنفيذ تعليمات JavaScript على عناصر الصفحة. وهذا يعني أنَّ سطر الأوامر يسمح لك بكتابة وإدارة ومراقبة شيفرات JavaScript عند الحاجة. سنشرح في هذا الدرس كيفية التعامل مع سطر الأوامر باستعمال JavaScript في المتصفحات، وسنعطي لمحة عن أدوات التطوير الأخرى المبنية في المتصفحات والتي يمكنك استعمالها في عملية تطوير تطبيقات الويب. العمل مع سطر الأوامر (Console) في المتصفح أغلبية متصفحات الويب الحديثة التي تدعم لغة HTML و XHTML القياسية ستوفِّر لك وصولًا إلى سطر أوامر الذي يمكنك استخدامه (عبر لغة JavaScript) بما يشبه طريقة استخدام الطرفية (terminal) في أنظمة يونكس. سنشرح الآن كيفية الوصول إلى سطر الأوامر في متصفحَي Firefox و Chrome. متصفح Firefox لفتح Web Console في متصفح Firefox، فاضغط على زر القائمة ☰ في الزاوية العليا اليمنى بجوار شريط العنوان. ثم اضغط على زر Developer الذي يقع تحت أيقونة المفك، والذي سيفتح قائمة Web Developer، ومن ثم اضغط على خيار Web Console. وهذا سيفتح لوحةً في أسفل نافذة المتصفح: يمكنك أيضًا الدخول إلى سطر الأوامر عبر اختصار لوحة المفاتيح Ctrl+Shift+K على نظامَي لينكس وويندوز، أو Command+Option+K على ماك. يمكننا التفاعل مع سطر الأوامر باستخدام JavaScript بعد أن استطعنا فتحه. متصفح Chrome لفتح JavaScript Console في متصفح Chrome فيمكنك النقر على القائمة في الزاوية العليا اليمنى من نافذة المتصفح (التي يُرمَز لها بثلاث نقط عمودية) ومن ثم اختيار More Tools ثم Developer Tools. ستُفتح لوحةٌ جديدة فيها اللسان Console في الشريط العلوي الذي عليك أن تضغط عليه للوصول إلى سطر الأوامر (هذا إن لم يكن هذا اللسان مفعّلًا من البداية): يمكنك أيضًا الوصول إلى سطر الأوامر بالضغط على اختصار لوحة المفاتيح Ctrl+Shif+J في نظامَي لينكس وويندوز، أو Command+Option+J في نظام ماك، وهذا سيؤدي إلى فتح لسان Console مباشرةً. يمكننا التفاعل مع سطر الأوامر باستخدام JavaScript بعد أن استطعنا فتحه. التعامل مع سطر الأوامر يمكنك كتابة شيفرات JavaScript داخل سطر الأوامر. لنبدأ بإظهار تحذير يحتوي على السلسلة النصية Hello, World!‎: alert("Hello, World!"); بعد أن تضغط على زر Enter بعد كتابة سطر JavaScript السابق، فيمكن أن تشاهد نافذة التحذير الآتية في متصفحك: ملاحظة: سيُظهِر سطر الأوامر نتيجة تنفيذ التعابير البرمجية، وسيُظهِر undefined إذا لم تتم إعادة (return) قيمة من التعبير المُنفَّذ. بدلًا من عرض نوافذ تحذير التي علينا الضغط على زر OK للخروج منها، يمكننا معرفة ناتج تعابير JavaScript بطباعتها إلى سطر الأوامر عبر الدالة console.log. فلو أردنا طباعة السلسلة النصية Hello, World!‎ سنكتب التعبير البرمجي الآتي في سطر الأوامر: console.log("Hello, World!"); وسيُطبَع السطر الآتي في نافذة سطر الأوامر: Hello, World!‎ يمكننا استخدام JavaScript لإجراء حسابات رياضية في سطر الأوامر: console.log(2 + 6); الناتج: 8 وسيستطيع المتصفح إجراء حسابات على أرقام أكبر: console.log(34348.2342343403285953845 * 4310.23409128534); الناتج: 148048930.17230788 لا تغفل عن إمكانية إجراء عمليات مُقسَّمة على أكثر من سطر عبر استعمال المتغيرات: let d = new Date(); console.log("Today's date is " + d); الناتج: Today's date is Wed Jun 21 2017 15:49:47 GMT-0400 (EDT) إذا أردتَ تعديل التعبير الذي كتبته في سطر الأوامر، فاضغط على زر السهم العلوي ↑ في لوحة مفاتيحك للحصول على السطر السابق، وهذا ما يسمح لك بتعديله ثم تنفيذه مجددًا. يوفر لك سطر أوامر المتصفح القدرة على تجربة شيفرات JavaScript في الوقت الحقيقي بما يشبه واجهة سطر الأوامر في أنظمة يونكس. التعامل مع ملف HTML يمكنك أيضًا إجراء عمليات على ملف HTML موجود مسبقًا أو على مستند مولّد ديناميكيًا عبر سطر الأوامر؛ وهذا يسمح لنا بتجربة كيفية تعامل شيفرات JavaScript مع عناصر HTML وقواعد CSS وسكربتات JavaScript الموجودة في صفحة الويب. أبقِ في ذهنك أنّك إذا أعدتَ تحميل الصفحة بعد تعديلها في سطر الأوامر فستعود إلى حالتها الأصلية قبل التعديل، ولذا احرص على حفظ أيّة تعديلات تريد الإبقاء عليها. لنحفظ مستند HTML الآتي باسم index.html لكي نجِّرب تعديلها عبر سطر الأوامر: <!DOCTYPE html> <html lang="en-US"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Today's Date</title> </head> <body> </body> </html> إذا حفظتَ مستند HTML السابق في ملفٍ ما وفتحتَه باستخدام متصفحك المفضّل فيجب أن تشاهد صفحةً فارغةً عنوانها «Today’s Date». يمكنك الآن فتح سطر الأوامر لاستعمال JavaScript لتعديل الصفحة، وسنبدأ بكتابة شيفرة JavaScript لإضافة ترويسة في الصفحة: let d = new Date(); document.body.innerHTML = "<h1>Today's date is " + d + "</h1>" ستحصل على الناتج الآتي في سطر الأوامر: "<h1>Today's date is Sat Jun 24 2017 12:16:14 GMT-0400 (EDT)</h1>" يجب أن تبدو الصفحة الآن كما يلي: يمكنك أيضًا تعديل أنماط الصفحة، مثل لون الخلفية: document.body.style.backgroundColor = "lightblue"; الناتج: "lightblue" وكذلك الأمر مع لون النص في الصفحة: document.body.style.color = "white"; الناتج: "white" يجب أن تبدو الصفحة الآن كما يلي: يمكنك أيضًا إنشاء فقرة جديدة عبر العنصر <p>: let p = document.createElement("P"); بعد إنشاء العنصر، حان الوقت لإضافة عقدة نصية (text node) التي يمكننا إضافتها إلى الفقرة الجديدة: let t = document.createTextNode("Paragraph text."); سنضيفها الآن إلى الفقرة المُعرَّفة عبر المتغير p: p.appendChild(t); وأخيرًا سنضيف الفقرة المُخزَّنة في المتغير p والنص الموجود فيها إلى المستند: document.body.appendChild(p); إذا أكملتَ الخطوات السابقة، فيجب أن تبدو صفحة HTML السابقة كما يلي: يوفِّر لنا سطر الأوامر البيئة المناسبة لإجراء تجرب على صفحات HTML، لكن من المهم أن نبقي في ذهننا أنَّنا لا نعدل مستند HTML فعليًا عندما ننفذ التعليمات البرمجية في سطر الأوامر، وإنما ستذهب جميع تعديلاتنا إذا أعدنا تحديث الصفحة. لمحة عن أدوات التطوير الأخرى اعتمادًا على أدوات المطوِّر التي يوفرها متصفحك، فستقدر على استخدام أدوات أخرى لمساعدتك في عملية تطوير الويب، لنطلع على تلك الأدوات. عرض شجرة DOM في كل مرة يتم فيها تحميل صفحة الويب، فسيُنشِئ المتصفح ما يسمى شجرة DOM (اختصار للعبارة Document Object Model) للصفحة. شجرة DOM تتألف من كائنات التي تُمثِّل عناصر HTML ضمن البنية الهرمية للعناصر. وشجرة DOM متاحة ضمن لسان Inspector في متصفح Firefox أو لسان Elements في متصفح Chrome. تسمح لك هذه الأدوات بعرض وتعديل عناصر DOM وتسمح لك بمعرفة ما هي وسوم HTML المسؤولة عن عرض جزء معيّن من الصفحة. ويمكن أيضًا من هذا اللسان معرفة ما هي قيمة المعرِّف ID لصورةٍ معيّنةٍ على سبيل المثال. ستكون بنية الصفحة التي عدلناها (وقبل إعادة تحميل الصفحة) في لسان DOM كما يلي: يمكنك أيضًا رؤية ما هي قواعد CSS المطبقة في لوحة جانبية بجوار اللسان الذي يعرض بنية شجرة DOM، مما يسمح لك بمعرفة ما هي الأنماط المُطبّقة على عنصر DOM داخل مستند HTML أو عبر ملف أنماط CSS خارجي. هذه صورةٌ تظهر أنماط العنصر body في أدوات المطوِّر في Firefox: لتعديل عقدة من عقد DOM فانقر نقرًا مزدوجًا فوق العنصر المُحدَّد وأجرِ التعديلات اللازمة، فحاول مثلًا أن تحوِّل العنصر <h1> إلى <h2>. تذكَّر أنَّ الصفحة ستعود إلى حالتها الأصلية المحفوظة إذا أعدت تحميلها. لسان الشبكة يمكن في لسان الشبكة Network في أدوات المطوِّر الموجودة في متصفحك أن تراقب وتسجِّل الطلبيات الشبكية، إذ يُظهِر هذا اللسان جميع الطلبيات الشبكية التي يجريها المتصفح بما في ذلك ما طَلَبَهُ عند تحميل الصفحة، وكم استغرقت كل طلبية من الوقت، وسيوفِّر تفاصيل عن كل طلبية؛ وهذا سيساعد كثيرًا في معرفة سبل تحسين أداء الصفحة وتسريع تحميلها وتنقيح مشاكل الشبكة. يمكنك استخدام لسان الشبكة جنبًا إلى جنب مع سطر الأوامر، أي يمكنك بدء عملية تنقيح (debug) الصفحة في سطر الأوامر ثم الانتقال إلى لسان الشبكة لرؤية النشاطات الشبكية دون إعادة تحميل الصفحة. لتعلّم المزيد حول لسان الشبكة، فأنصحك بقراء working with Firefox’s Network Monitor أو getting started with analyzing Network performance with Chrome’s DevTools. التصميم المتجاوب عندما يكون موقع الويب متجاوبًا (responsive)، فهذا يعني أنَّه صُمِّمَ وطوِّرَ لكي يظهر ويعمل بشكل مناسب على مجال واسع من الأجهزة المختلفة مثل الهواتف المحمولة والحواسيب اللوحية والحواسيب المكتبة والمحمولة. قياس الشاشة وكثافة البكسلات ودعم اللمس هي عوامل مهمة يجب أخذها بالحسبان عند تطوير مواقع متجاوبة، ويجب عليك –كمطور ويب– أن تفكر في مبادئ التصميم المتجاوب عند إنشاء المواقع لإتاحتها للآخرين بغض النظر عن الجهاز الذي يصلون إلى موقعك عبره. يوفر لك متصفح Firefox و Chrome أدواتٍ للتأكد من تطبيقك لمبادئ التصميم المتجاوب أثناء إنشائك وتطويرك لمواقع وتطبيقات الويب. وستتمكن بوساطة تلك الأدوات أن تحاكي مختلف الأجهزة لكي تختبر تطبيقك وتحلّل مشاكله أثناء التطوير. اقرأ المزيد عن Responsive Design Mode في متصفح Firefox أو Device Mode في Chrome لتعلم طريقة الاستفادة من تلك الأدوات لإنشاء مواقع ويب تلبي احتياجات جميع المستخدمين. الخلاصة أخذنا في هذا الدرس لمحةً عن طريقة التعامل مع سطر الأوامر الموجود في المتصفحات الحديثة، بالإضافة إلى بعض المعلومات عن أدوات التطوير التي يمكنك الاستفادة منها في عملك. لتعلّم المزيد عن JavaScript فاقرأ كتاب تعلم JavaScript، وإذا كنتَ مهتمًا بمكتبة jQuery فأنصحك بالاطلاع على كتاب تعلم jQuery. ترجمة –وبتصرّف– للمقال How To Use the JavaScript Developer Console لصاحبته Lisa Tagliaferri

يمكن أن يكون العمل مع مصممي الويب عملًا يشوبه بعض التعقيد، خاصة إن لم يتمّ التعامل مع مصمم ويب من قَبل، وعليه ستقدّم لك هذه القائمة من النصائح أفضل السُبل في بناء علاقة مثاليّة بينك كعميل وبين مصمم الويب. كنت أفكّر مطوّلًا مؤخرًا حول طبيعة العلاقة مع العملاء الذين أتعامل معهم في أحد شركات التصميم، محاولًا تحديد السبب الذي يجعل بعض المشاريع تعمل بسلاسة ويسر على خلاف أخرى، الأمر الذي يُنتج مواقع أكثر احترافية بطبيعة الحال، وتوصلت في نهاية الأمر إلى أن سبب الاختلاف يعود غالبًا إلى طبيعة العلاقة والتواصل بين المصمم والعميل. يوجد من دون شك مهارة في الحصول على أفضل النتائج من مصممي الويب، وعليه فكّرت في مشاركة بعض الأفكار والحيل من خلال هذا المقال وعلى شكل قائمة من عشرة نصائح مستخلصة من واقع التجربة والخبرة. 1. لا تستعجل التصميم أصبحت مشاريع الويب بشكل متزايد مقيّدة إما بالميزانية المحدودة أو بالمهلة المحدّدة لإتمام المشروع، وهذا الأمر من شأنه أن يؤثّر على جودة العمل التي ستحصل عليها من مصمم الويب، فالمنتج عالي الجودة يتطلّب وقتًا، ولا يُحصر هذا الوقت في العمل الفعلي الإجرائي على المشروع، حيث يحتاج مصمم الويب وقتًا للتفكير حول الطرق المختلفة المتاحة، واختيار أنسبها بما في ذلك الأدوات المطلوبة، بمعنى آخر كلما أفسحت المجال للمصمم، كلما زادت جودة العمل. أنا لا أقلّل من العمل الإجرائي الخاص بالتصميم، فلن يخرج التصميم بأبهى حلّة بدونه، والشيفرة التي خلف الستار ستفشل ولن تدوم طويلًا قبل أن تظهر المشاكل والعلل البرمجيّة فيها. 1. تابع سير عملية التصميم على مراحل يميل مصممو الويب إلى العمل بنوع من الكتمان عند يتعلّق الأمر بتصميم الموقع، حيث يحبّذون العمل على التصميم إلى حين الانتهاء منه، ولا يتحدّثون عن التصميم وحيثياته مع عملائهم حتى هذه المرحلة، للأسف يقود هذا الأسلوب إلى مشاكل لا يُحمد عقباها في الأغلب. إن لم يفهم مصمم الويب لأي سبب كان الاتفاق الأوّلي الذي أجراه مع عميله، فمن الممكن جدًا أن يقضي أيامًا إن لم أقل أسابيع يغرّد خارج السرب ويعمل على تصميم غير ملائم بالمرّة للمتطلّبات العميل، وما يزيد الطين بلّة أن المصمم سيكون راضيًا عن التصميم عند هذه النقطة ومقتنع بإتمامه المهمة الموكلة إليه على أكمل وجه، فمن وجهة نظره هذا هو الحلّ والتصميم المطلوب، وهو لا يستطيع ولن يرضى بإضاعة وقته في التعديل أو التنقيح، وسيقود هذا الأمر الطرفين إلى خلاف. يوجد أسلوب أفضل للتعامل، وهو عبر متابعة العمل مع مصمم الويب من البداية ومنذ اللحظة الأولى، يجب عليك رؤية المسودة الأولى التصميم، والإطارات الهيكليّة، وسيؤكّد هذا الأمر أن التصميم النهائي قد تمت الموافقة عليك من قِبل الطرفين، لأن كلا الطرفين ساهما في خروج هذا التصميم ليرى النور، ومنذ المراحل الأولى في إنشائه. 3. قم بالاختبار عند الحيرة أو الشك ستختلف أنت ومصمم الويب على بعض الجزئيات لا مناص من ذلك، وعلى الرغم أن مصممي الويب هم الخبراء هنا وأصحاب النظرة التصميمية الأقوى إلا أنهم ليسوا معصومين عن الخطأ، خاصة وأنه عليك أن تكون واثقًا من التصميم بالقدر الكافي لتعتمده تصميمًا للموقع. إن كان الشك يعتريك فيما إذا كان المصمم على حق في نصحه أم لا، فمن المستحسن اختبار التصميم، فمن غير المناسب تجاهل وجهة نظر المصمم، فمن المحتمل جدًا أن تكون وجهة نظرك هي الخاطئة، بدلًا من ذلك اختبر التصميم مع مستخدمين حقيقيين لتحصل على رأيٍ حياديٍ وموضوعي. 4. لا تطلب أكثر من نموذج للتصميم يصرّ بعض العملاء على الحصول عل أكثر من نموذج للتصميم في بداية المشروع، بهدف أن يكون لديهم أكثر من خيار لتصميم الموقع النهائي، وبجانب ما أسلفت حول وجوب متابعة التصميم أوّل بأوّل، فإن فكرة العمل على أكثر من تصميم من الأساس تشوبها شائبة ولا تعطي نتائج مرضية لكلا الطرفين. تكمن المشكلة مع التصّورات المتعدّدة للتصميم أنها حتمًا ستقود إلى تصميم مقيت، بمعنى آخر، عندما يتمّ عرض أكثر من تصميم عليك كعميل صاحب القرار النهائي، فسترى حتمًا عناصر تعجبك من كل تصميم، وفي معظم الأحيان يقود هذا الأمر إلى اختيار أجزاء من التصميمين لتكون في التصميم النهائي، ولكن وكما سيخبرك أي مصمم أنّه لا يمكنك جمع عناصر أو أجزاء من تصميمين مختلفين بسهولة ويُسر، وما سيؤول إليه الأمر في النهاية الخروج بتصميم هو أبعد ما يكون عن الإبداعية والجمالية التي كنت تتمناها. اتبع بدلًا من ذلك نصيحتي السابقة وذلك بالعمل جنبًا إلى جنب مع المصمم للوصول بالتصميم إلى بر الأمان. 5. وضح رؤية التصميم قبل عرضه على أحدهم يمكن أن يكون التقرير في الشكل النهائي للموقع أمرًا ليس بالهين خاصّة إن كانت هذه تجربتك الأولى، فغالبًا ستقوم باستشارة أحد الزملاء أو ربما صديق ما أو فرد من أفراد العائلة لتحصل على الرضا التام حول التصميم. على الرغم من أن الرغبة في عرض التصميم على عديد الأشخاص هو أمرٌ يمكنني تفهمه، ولكنه ليس من باب الحكمة فعل ذلك، فقدرتنا على الحكم على التصميم السيء أو الجيّد ستكون عبارة عن رأي شخصي لا غير، وتختلف هذه الآراء بين الآخرين بطبيعة الحال، وبدلًا من طمأنة نفسك في عرض التصميم على هذا وذاك سينتهي بك المطاف حيرانًا في التصميم أكثر من ذي قَبل. لا أنكر وجوب عرض التصميم على البعض، لا بأس في ذلك، ولكن على الأقل لا ترسل لهم التصميم وتطلب آراءهم فحسب، فلكي يستطيعوا تقديم رأيهم الموضوعي، عليهم أوّلًا فهم خلفية المشروع وكيف تمّ اتخاذ القرار وعلى أي أساس، فبدون هذه المعلومات كل ما يستطيعون تقديمه هو آرائهم الشخصية لا أكثر ولا أقل، وبطبيعة الحال هو مجرّد آراء شخصية لا تسمن ولا تغني من جوع. 6. تأكد من تحديد أهداف ومهمة الموقع التي سيمثلها التصميم مع المصمم قد تسوء الأمور حتى عند العمل بشكل متواصل وتعاوني مع المصمم، خاصة عندما يكون لكلٍ منكما وجهة نظر مختلفة عن الآخر بما يخص الهدف المنشود للتصميم النهائي، لهذا من المهم على جميع الأطراف أن تمتلك نظرة واضحة عن أهداف ومهمّة الموقع، وهذه الأهداف ستكون بمثابة الموجّه والمساعد في اتخاذ القرارات خلال مسيرة تطوير الموقع. 7. تأكد من أن الفئة المستهدفة محددة ومتفق عليها بين الطرفين حاول جاهدًا نقل الصورة الصحيحة عن مستخدمي الموقع المستهدفين إلى المصمم، وهنا يأتي دور المصمم في إجرائه اختبارات قابلية الاستخدام usability testing، لا بل الأفضل حضّ مصمم الويب على تطبيق اختبار قابلية الاستخدام على الفئة المستهدفة مباشرةً، وبهذه الطريقة سيعرف المصمم بالضَّبط ما هو المناسب وغير المناسب للفئة المستهدفة. سيقدّم مصمم الويب تصميمًا لا يمت بصلة بهدف ومهمّة الموقع عند عدم فهمه الفئة المستهدفة بالشكل الصحيح. يجب ملاحظة أمر مهمً مع ذلك، ليس فقط المصمم من هو بحاجة إلى فهم الفئة المستهدفة، أنت أيضًا، قد تعتقد أنك تعرف ذلك، ولكن إلا إذا كنت على تواصل مستمر ويومي مع المستخدمين، فمن الجدير الاطلاع على أي اختبار لقابلية استخدام usability testing ينفذه مصمم الويب، وقد تتفاجأ كيف يختلف المستخدمين عن الفكرة المبلورة والمتصوّرة عنهم. 8. لا تبالغ في العمل على التصميم توجد مشكلة شائعة في العديد من مشاريع التصميم وهي إفراط أصحابها في بذل أقصى ما في جهدهم على التصميم، وهذا شيء قد تعلّم أغلب مصممي الويب أن يتجنبوه بناءً على تجاربهم السابقة، ولكن ولأن معظم أصحاب المواقع ليس لديهم هذه المعرفة والخبرة ستجدهم يقعون في هذه الحفرة. نتّفق جميعًا أن التصميم هو أمر عائد للآراء الشخصيّة، بمعنى لن تستطيع بأي حالٍ من الأحوال الحصول على التصميم المثالي، ولكن رغبتك في تحقيق الكماليّة ستقودك من تحسين إلى تحسين آخر، ومن تعديل إلى تعديل آخر بغرض الحصول على أفضل تصميم، وهنا المشكلة، أنت لن تحصل على أفضل تصميم مهما حاولت، ربما تحصل على تصميم يعجبك أنت شخصيًا، ولكن لن تحصل على تصميم كامل متكامل ومُرضي للجميع فهذا هو المحال بعينه. توجد مشكلة أخرى مرتبطة بسابقتها، وهي اعتقاد أصحاب المواقع أن لديهم فرصة وحيدة للحصول على أفضل تصميم، وهذا ليس بالصحيح، بل في الواقع وفي معظم الأحيان إن أفضل طريقة لإيجاد ذلك التصميم المنشود هو عبر وضع التصميم تحت الاختبار الفعلي ليتفاعل معه المستخدمين مباشرةً، عندها يُمكن التنقيح والتحسين اعتمادًا على ردود فعل وآراء حقيقة بدلًا من الآراء الشخصيّة. 9. احرص على بناء علاقة مستمرة مع المصمم يكلّف معظم أصحاب المواقع مصممين لإعادة تصميم مواقعهم، ومن ثم يتوارون عن الأنظار، سيمنع هذا الأسلوب من تطوير الموقع بناءً على متطلّبات المستخدم، بدلًا من ذلك، يجب على أصحاب المواقع العمل على تحسين مواقعهم شهريًا، للحصول على جملة من التعديلات والتحسينات المتواترة والمتتابعة لتجنّب التعديلات الكبيرة والمكلفة. 10. ركز على المشكلة واترك الحل للمصمم أعتقد أنّه من المهم معرفة كل شخص دوره والتزام به بالضبط، فمهمّة أصحاب المواقع هي تحديد المشكلة، وحلّها يقع على عاتق المصممين. ولكن وفي العديد من الحالات الأمر ليس بهذه البساطة، حيث يُلاحظ صاحب الموقع مشكلة ما في الموقع (مثلًا عدم ملائمة لون الموقع مع الفئة المستهدفة) فيخبر العميل المصمم بضرورة التغيير (لنقل تغيير اللون من الوردي/الزهري إلى الأزرق)، ولكن مصمم الويب هنا غير مدرك لحقيقة المشكلة أو دواعيها، فكل ما يعرفه أن العميل يرغب باللون الأزرق، وبالتالي سيكون من شبه المستحيل على المصمم أن يقترح حلولًا بديلة، والتي قد تكون أفضل من تلك التي طلبها العميل، بمعنى آخر، أصبح صاحب الموقع المصمم، وأصبح المصمم مجرّد تقني يطبّق التصميم. يُقيّد هذا الأسلوب من موهبة المصمم من جهة، ويتلف العلاقة بين المصمم والعميل من جهة أخرى، فأصبح المصمم لا يلعب في أرض ملعبه التي يبرع فيها، وقد جُرّد من حقّه في الإبداع، وربما قد فقد الاهتمام في المشروع من الأساس. خاتمة ستزيد تطبيق هذه المقترحات بشكل ملحوظ من فعاليّة موقعك من خلال تحسين العلاقة بينك وبين المصمم، طبعًا هذه المقترحات ليست شاملة بطبيعة الحال، لذلك تنس مشاركة ما في جعبتك حول هذا الموضوع لتغطية ما غفل عنه المقال. ترجمة وبتصرّف للمقال 10tips for working with web designers لصاحبه Paul Boag.

إنّ Bacula-web هو عبارة عن تطبيق ويب مكتوب بلغة PHP يُزوِّدنا بطريقة سهلة لعرض ملخصات ومخططات بيانية لوظائف النسخ الاحتياطي backup jobs التي تم تشغيلها مسبقًا، وبالرغم من أنّه لا يسمح لنا بالتحكم بـ Bacula بأي طريقة فهو يُزوِّدنا بواجهة رسوميّة بديلة لطريقة عرض الوظائف من الـ console، إنّ Bacula-web مفيد خاصّة للمستخدمين الجديدين على Bacula، حيث تُسهِّل علينا تقاريره فهم آلية عمل Bacula. سنشرح في هذا الدّرس كيفيّة تثبيت Bacula-web على خادوم Ubuntu الذي تعمل عليه برمجيّة خادوم Bacula. المتطلبات الأساسيةيجب أن تمتلك من أجل متابعة الدّرس برمجيّة خادوم Bacula للنسخ الاحتياطي مُثبَّتة على خادوم Ubuntu لديك، تستطيع إيجاد تعليمات تثبيت Bacula هنا: كيفيّة تثبيت خادوم Bacula على Ubuntu. يفترض هذا الدّرس أنّ خادوم Bacula لديك يستخدم قاعدة بيانات MySQL، إن كنت تستخدم قاعدة بيانات أخرى مثل PostgreSQL فتأكّد من أن تقوم بالضبط المناسب من أجل هذا الدّرس، ستحتاج إلى تثبيت وحدة PHP مناسبة والقيام بضبط أمثلة معلومات اتصال قاعدة البيانات. فلنبدأ الآن. تثبيت Nginx و PHPإنّ Bacula-web هو عبارة عن تطبيق PHP لذا نحتاج لتثبيت PHP وخادوم ويب، سنستخدم Nginx، إن أردت تعلم المزيد حول إعداد هذه البرمجيّة فتحقّق من هذا الدّرس LEMP tutorial. نقوم بتحديث قوائم apt-get لدينا: sudo apt-get updateنُثبِّت بعدها Nginx، PHP-fpm، وبعض الحِزَم الأخرى باستخدام apt-get: sudo apt-get install nginx apache2-utils php5-fpm php5-mysql php5-gdنحن الآن جاهزون لإعداد PHP وNginx. إعداد PHP-FPMنفتح ملف إعدادات PHP-FPM باستخدام مُحرِّر النصوص الذي نفضّله، سنستخدم vi: sudo vi /etc/php5/fpm/php.iniنبحث عن السطر الذي يُحدِّد cgi.fix_pathinfo، نزيل التعليق عنه ونستبدل قيمته بـ 0، يجب أن يبدو كما يلي بعد أن ننتهي من ذلك: cgi.fix_pathinfo=0نبحث الآن عن الإعداد date.timezone، نزيل التعليق عنه ونستبدل قيمته بقيمة المنطقة الزمنية لدينا، سنضع New York على سبيل المثال: date.timezone = America/New_Yorkإن أردت الحصول على قائمة بكافّة المناطق الزمنية timezones فتحقّق من وثائق PHP. نحفظ الملف ونخرج منه. الآن وقد أصبح PHP-FPM مُعدًّا بشكل صحيح فلنقم بإعادة تشغيله لتطبيق التغييرات: sudo service php5-fpm restartإعداد Nginxحان الوقت الآن لإعداد Nginx ليُخدِّم تطبيقات PHP. في البداية نقوم بإنشاء ملف htpasswd لكي لا نسمح بالأشخاص غير المُصرَّح لهم بالنفاذ إلى Bacula-web، نستخدم الأمر htpasswd لإنشاء مستخدم مُدير admin، يُدعى "admin" (يجب أن تستخدم اسمًا آخر)، والذي يستطيع النفاذ إلى واجهة Bacula-web: sudo htpasswd -c /etc/nginx/htpasswd.users adminندخل كلمة السّر في المُحِث prompt، ونقوم بتحديد تذكر تسجيل الدخول هذا لأنّنا سنحتاجه للنفاذ إلى Bacula-web. نفتح الآن ملف إعدادات كتلة block الخادوم الافتراضيّة في Nginx من خلال مُحرِّر نصوص، سنستخدم vi: sudo vi /etc/nginx/sites-available/defaultنستبدل محتويات الملف بكتلة الشيفرة code التالية، احرص على تبديل القيمة server_name باسم نطاق خادومك أو عنوان IP الخاص به: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.php index.html index.htm; server_name server_domain_name_or_IP; auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/htpasswd.users; location / { try_files $uri $uri/ =404; } error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }نقوم بحفظ الملف والخروج منه، يقوم هذا بإعداد Nginx لتخديم تطبيقات PHP وليستخدم ملف htpasswd الذي أنشأناه سابقًا من أجل الاستيثاق authentication. ولتطبيق التغييرات نعيد تشغيل Nginx: sudo service nginx restartنحن الآن جاهزون لتنزيل Bacula-web. تنزيل وإعداد Bacula-webنقوم بالانتقال إلى الدليل الرئيسي home لدينا وتنزيل إصدار Bacula-web الأخير على شكل ملف أرشيف، الإصدار الأخير في وقت كتابة هذا الدّرس هو 7.0.3: cd ~ wget --content-disposition http://www.bacula-web.org/download.html?file=files/bacula-web.org/downloads/bacula-web-7.0.3.tgzنُنشِئ الآن دليلًا جديدًا اسمه bacula-web، وننتقل إليه، ثمّ نستخرج محتويات الأرشيف Bacula-web إليه: mkdir bacula-web cd bacula-web tar xvf ../bacula-web-*.tgzينبغي قبل نسخ الملفّات إلى جذر المستند document root لخادوم الويب لدينا أن نقوم بإعداده أولًا. نقوم بالانتقال إلى دليل الإعدادات كما يلي: cd application/configيُزوِّدنا Bacula-web بعيّنة sample من الإعدادات، ننسخها كما يلي: cp config.php.sample config.phpنقوم الآن بتحرير ملف الإعدادات ضمن مُحرِّر نصوص، سنستخدم vi: vi config.phpنبحث بداخله عن: MySQL bacula catalog //ونزيل التعليق عن تفاصيل الاتصال، نضع أيضًا كلمة سر قاعدة بيانات Bacula الخاصّة بنا بدلًا من القيمة password (والتي يُمكِن إيجادها في المسار etc/bacula/bacula-dir.conf/ ضمن الإعداد "dbpassword"): // MySQL bacula catalog $config[0]['label'] = 'Backup Server'; $config[0]['host'] = 'localhost'; $config[0]['login'] = 'bacula'; $config[0]['password'] = 'bacula-db-pass'; $config[0]['db_name'] = 'bacula'; $config[0]['db_type'] = 'mysql'; $config[0]['db_port'] = '3306';نحفظ الملف ونخرج منه. أصبح الآن Bacula-web مُعدًّا كما يجب، الخطوة الأخيرة هي وضع ملفّات التطبيق في المكان المناسب. نسخ تطبيق Bacula-web إلى جذر المستند Document Rootقمنا بإعداد Nginx ليستخدم usr/share/nginx/html/ كجذر المستند، ننتقل إلى هذا المسار ونحذف الملف index.html الافتراضي باستخدام الأوامر التالية: cd /usr/share/nginx/html sudo rm index.htmlننقل الآن ملفّات Bacula-web إلى الموقع الحالي، وهو جذر مستند Nginx: sudo mv ~/bacula-web/* .نقوم بتغيير ملكيّة الملفّات إلى www-data، وهو المستخدم العفريت (بالإنجليزية Daemon وهو برنامج يعمل في خلفيّة النظام) الذي يقوم بتشغيل Nginx: sudo chown -R www-data: *الآن تمّ تثبيت Bacula-web بشكل كامل. النفاذ إلى Bacula-web من خلال المتصفحأصبح الآن Bacula-web قابلًا للنفاذ على اسم نطاق خادومنا أو من خلال عنوان IP العام له. ربّما ترغب الآن أن تختبر أنّ كل شيء مُعَد بشكل صحيح، ولحسن الحظ يُزوّدنا Bacula-web بصفحة اختبار test، نستطيع الوصول إليها بفتح الرابط التالي في متصفّح الإنترنت (مع وضع عنوان خادومنا بدلًا من server_public_IP): http://server_public_IP/test.phpينبغي أن نرى الآن جدول يُظهِر الحالة لمختلف عناصر Bacula-web، ويجب أن تملك كافّة العناصر علامة صح خضراء بجانبها، ما عدا وحدات قواعد البيانات التي لا نريدها، على سبيل المثال نحن نستخدم هنا MySQL لذا لا نحتاج لوحدات قواعد البيانات الأخرى: إن سار كل شيء على ما يرام فنحن الآن جاهزون لاستخدام الصفحة الرئيسيّة dashboard، نستطيع الوصول إليها عن طريق النقر على النص "Bacula-web" الموجود في الأعلى والأيسر، أو عن طريق زيارة خادومنا من خلال متصفّح الإنترنت: http://server_public_IP/يجب أن تبدو مماثلة لما يلي: الخاتمةأصبحنا مستعدين الآن لاستخدام Bacula-web لمراقبة مُختلَف وظائف Bacula وحالاتها بسهولة. ترجمة -وبتصرّف- لـ How To Install Bacula-web on Ubuntu 14.04 لصاحبه Mitchell Anicas.

إنّ التخزين المؤقّت Caching للمحتوى بشكل ذكي هو واحد من أكثر الطرق فعاليّة لتحسين التجربة لزوّار موقعنا، إنّ التخزين المؤقّت Caching، أو تخزين المحتوى بشكل مؤقّت من الطلبات السّابقة، هو جزء من لُب استراتيجيّة توصيل المحتوى المُنفَّذة ضمن ميفاق HTTP protocol، تستطيع المُكوِّنات عبر مسار توصيل المحتوى أن تقوم بالتخزين المؤقّت للعناصر لتسريع الطلبات اللاحقة، والتي تكون خاضعة لسياسات التخزين المؤقّت المُصرَّح عنها بالنسبة للمحتوى. سنناقش في هذا الدّرس كيفيّة اختيار سياسات التخزين المؤقّت لنضمن أن يتمكّن التخزين المؤقّت في جميع أنحاء شبكة الإنترنت من معالجة محتوانا بشكل صحيح، وسنتحدّث عن استخدام ترويسات التخزين المؤقّت، وتوظيف الاستراتيجيات المختلفة للحصول على أفضل مزيج من الأداء والمرونة. ترويسات التخزين المؤقت Caching Headersتعتمد سياسة التخزين المؤقّت على عاملين مختلفين، كيان التخزين المؤقّت والذي يُقرِّر بنفسه أن يقوم بالتخزين المؤقّت للمحتوى المقبول أم لا، فيستطيع أن يُقرِّر أن يُخزِّن بشكل مؤقّت أقل مما هو مسموح له ولا أكثر من ذلك. يتم تحديد مُعظم سلوك التخزين المؤقّت عن طريق سياسة التخزين المؤقّت، والتي تُوضَع من قبل مالك المحتوى. تتمحور هذه السياسات بشكل أساسي حول استخدام ترويسات HTTP مُحدّدة. ومع تحديثات ميفاق HTTP protocol ظهرت بعض الترويسات المختلفة التي تُركِّز على التخزين المؤقّت مع مستويات مختلفة من التعقيد، ولكنّ الترويسات التالية هي التي لا نزال بحاجة إلى الانتباه لها: Expires: إنّ الترويسة Expires واضحة جدًّا، على الرغم من أنّها محدودة المجال، فتقوم بشكل أساسي بتعيين وقت في المستقبل تنتهي فيه صلاحيّة المحتوى، وعند هذه النقطة يجب على أي طلب لهذا المحتوى أن يعود إلى الخادوم الأصل، تُستخدَم هذه الترويسة أفضل ما يُمكن كاحتياط فقط.Cache-Control: وهي البديل الأكثر حداثة للترويسة Expires ومدعومة بشكل جيّد وتقوم بتطبيق تصميم أكثر مرونة، وهي مُفضّلة تقريبًا في كل الحالات على Expires، ولكن لن يضرّنا تعيين قيمة لهما معًا، سنناقش تفاصيل الخيارات التي بإمكاننا تعيينها مع Cache-Control لاحقًا.Etag: تُستخدَم الترويسة Etag في التحقّق من التخزين المؤقّت، حيث يُزوّدنا الخادوم الأصل بترويسة Etag فريدة لأجل العناصر حينما يقوم بتخديم المحتوى في البداية، فعندما يُريد التخزين المؤقّت التحقق من المحتوى الذي يملكه عند انتهاء الصلاحيّة يستطيع إرسال الترويسة Etag التي يملكها من أجل المحتوى إلى الخادوم الأصل والذي إمّا أن يُخبر التخزين المؤقّت بأنّه يملك نفس المحتوى أو يقوم بإرسال المحتوى الجديد (مع ترويسة Etag جديدة).Last-Modified: تُحدِّد هذه الترويسة المرّة الأخيرة التي تمّ فيها تعديل العنصر، ويُمكن استخدامها كجزء من استراتيجيّة التحقّق لضمان محتوى حديث.Content-Length: بالرغم من أنّها لا تُشارِك تحديدًا في التخزين المؤقّت فإنّه من الهام تعيين قيمة لهذه الترويسة عند تعريف سياسات التخزين المؤقّت، حيث ترفض بعض البرمجيّات التخزين المؤقّت للمحتوى إن لم تكن تعلم مُسبقًا حجم هذا المحتوى الذي تحتاج لحجز مساحة له.Vary: يستخدم التخزين المؤقّت بشكل نموذجي المُضيف host المطلوب والمسار إلى الموارد كمفتاح يُخزَّن بواسطته العنصر المطلوب، يُمكِن استخدام الترويسة Vary لنخبر التخزين المؤقّت أن ينتبه إلى ترويسة إضافيّة عندما يُقرّر إذا ما كان الطلب لنفس هذا العنصر، وهي أكثر ما تستخدم لإخبار التخزين الاحتياطي أن تستخدم الترويسة Accept-Encoding كمفتاح أيضًا، بحيث يعلم التخزين المؤقّت كيف يُفرِّق بين المحتوى المضغوط compressed وغير المضغوط.نظرة جانبية على الترويسة Varyتزوّدنا الترويسة Vary بالقدرة على تخزين إصدارات مختلفة من نفس المحتوى على حساب تمييع diluting المُدخلات في التخزين المؤقّت. ففي حالة Accept-Encoding يسمح لنا إعداد الترويسة Vary بالتمييز بشكل قاطع بين المحتوى المضغوط وغير المضغوط، حيث نحتاج لهذا لتخديم هذه العناصر بشكل صحيح للمتصفّحات التي لا تستطيع التعامل مع المحتوى المضغوط، وهو ضروري من أجل توفير سهولة الاستخدام الأساسيّة، ومن إحدى السمات التي تُخبرنا بأنّ الترويسة Accept-Encoding قد تكون مُرشّحًا جيّدًا من أجل الترويسة Vary هي أنّها تمتلك فقط قيمتان أو ثلاث قيم ممكنة. يبدو عنصر مثل User-Agent للوهلة الأولى طريقة جيّدة للتمييز بين متصفّحات الحواسيب ومتصفّحات الهواتف النقّالة لتخديم إصدارات مختلفة لموقعنا، ومع ذلك وبما أنّ السلاسل النصيّة لـ User-Agent ليست معياريّة فستكون النتيجة غالبًا عدّة إصدارات من نفس المحتوى في التخزينات المؤقّتة الوسيطة مع نسبة استخدام تخزين مؤقّت Cache hit ratio ضئيلة، ينبغي استخدام الترويسة Vary باعتدال، خاصّة إن لم نكن نملك القدرة على تقليل تكرار الطلبات في التخزينات المؤقّتة الوسيطة التي نتحكّم بها (والذي قد يكون ممكنًا إن استفدنا من شبكة توصيل محتوى content delivery network على سبيل المثال). كيف تؤثر أعلام الترويسة Cache-Control على التخزين المؤقتأشرنا سابقًا إلى كيفيّة استخدام الترويسة Cache-Control من أجل مواصفات سياسة التخزين المؤقّت الحديثة، يُمكن تعيين عدد من التعليمات المختلفة لهذه السياسة باستخدام هذه الترويسة، مع فصل التعليمات المتعدّدة بواسطة الفواصل. ومن بعض خيارات Cache-Control التي نستطيع استخدامها للنص على سياسة التخزين المؤقّت للمحتوى لدينا نجد: no-cache: تُحدِّد هذه التعليمة أنّه يجب التحقّق من أي محتوى مُخزَّن مؤقّتًا عند كل طلب قبل تخديمه إلى العميل، وتقوم فعليًّا بتحديد المحتوى بأنّه قديم stale فورًا، ولكن تتيح له استخدام تقنيات إعادة التحقّق لتجنّب إعادة تنزيل كامل العنصر مرّة أخرى.no-store: تشير هذه التعليمة إلى أنّه لا يُمكن التخزين المؤقّت للمحتوى بأي طريقة، وهي ملائمة لتعيينها إن كانت الاستجابة تمثّل بيانات حسّاسة.public: تقوم بتحديد المحتوى بأنّه عام ممّا يعني أنّه يمكن التخزين المؤقّت له من قبل المتصفّح أو من قبل أي تخزينات مؤقّتة وسيطة، يتم تحديد الاستجابات بالنسبة للطلبات التي تستخدم استيثاق HTTP بأنّها خاصّة private افتراضيًّا، وتستطيع هذه الترويسة تجاوز ذلك الإعداد.private: تقوم بتحديد المحتوى بأنّه خاص private، والذي يُمكن تخزينه من قبل متصفّح المستخدم ويُمنَع تخزينه بشكل مؤقّت من قبل أي أطراف وسيطة، تستخدم هذه التعليمة غالبًا للبيانات الخاصّة بالمستخدم.max-age: يضبط هذا الإعداد الفترة العظمى التي يُمكن خلالها تخزين المحتوى بشكل مؤقّت قبل أن تجب إعادة التحقّق منه أو إعادة تحميله من الخادوم الأصل، وهو يستبدل الترويسة Expires من أجل المتصفّحات الحديثة وهو الأساس لتحديد حداثة جزء من المحتوى، تُحدَّد قيمة هذا الخيار بالثواني ووقت الحداثة الأعظمي المقبول هو سنة واحدة (31536000 ثانية).s-maxage: وهو مشابه كثيرًا للإعداد max-age بأنّه يشير للفترة الزمنيّة التي يُمكِن خلالها التخزين المؤقّت للمحتوى، ويكمن الفرق في أنّ هذا الخيار يُطبَّق فقط على التخزينات المؤقّتة الوسيطة، يسمح جمعه مع الخيار السابق ببناء سياسة أكثر مرونة.must-revalidate: يُشير هذا الخيار إلى أنّه يجب إطاعة معلومات الحداثة المنصوص عليها من خلال max-age، s-maxage، أو الترويسة Expires بشكل صارم، فلا يُمكِن تخديم المحتوى القديم تحت أي ظروف، ويمنع هذا استخدام المحتوى المُخزَّن مؤقّتًا في حالة انقطاعات الشبكة والسيناريوهات المشابهة لها.proxy-revalidate: يقوم هذا الإعداد بنفس ما يقوم به الإعداد السابق ولكن ينطبق فقط على وسطاء التخزين المؤقّت البيني intermediary proxies، ويبقى متصفّح المستخدم في هذه الحالة قادرًا على تخديم المحتوى القديم في حالة انقطاعات الشبكة، ولكن لا يُمكن استخدام التخزينات المؤقّتة الوسيطة لهذا الغرض.no-transform: يمنع هذا الخيار التخزينات المؤقّتة من تعديل المحتوى الذي تلقّته لأسباب تتعلّق بالأداء تحت أي ظروف، يعني هذا على سبيل المثال أنّ التخزين المؤقّت غير قادر على إرسال إصدارات مضغوطة من محتوى لم يتلقّاه بشكل مضغوط وغير مسموح له بهذا أصلًا.نستطيع الجمع بين كل ما سبق بطرق مختلفة للحصول على سلوك متعدّد للتخزين المؤقّت، بعض القيم التبادليّة هي: no-cache ،no-store، وسلوك التخزين المؤقّت الطبيعي الذي نشير إليه بغياب أحدهماpublic و privateيحل الخيار no-store محل no-cache إن كان كلاهما موجودًا، ومن أجل الاستجابة على الطلبات التي لا تتعلق بالاستيثاق يتم تطبيق الخيار public، ومن أجل الاستجابة على الطلبات التي تحتوي استيثاق يتم تطبيق الخيار private، ويُمكِن تجاوزها بتضمين الخيار المعاكس في الترويسة Cache-Control. تطوير سياسة تخزين مؤقتيُمكِن في العالم المثالي التخزين المؤقّت لكل شيء بقوّة والتواصل مع الخواديم فقط للتحقّق من المحتوى بين حين وآخر، ولكن على الرغم من ذلك لا يحدث هذا في الممارسة العمليّة، لذا ينبغي أن نحاول تعيين سياسات تخزين مؤقّت عاقلة تطمح إلى الموازنة بين تنفيذ تخزين مؤقّت طويل المدى والاستجابة لاحتياجات الموقع المتغيّر. مشاكل شائعةهنالك العديد من الحالات التي لا يُمكِن أو لا ينبغي فيها تنفيذ التخزين المؤقّت نظرًا لكيفيّة إنتاج هذا المحتوى (توليده بشكل مُتغيّر بحسب المستخدم) أو طبيعة هذا المحتوى (معلومات بنكيّة حساسة على سبيل المثال)، ومن المشاكل الأخرى التي تُواجِه العديد من مديري النّظم عند إعداد التخزين المؤقّت هي الحالة التي تكون فيها إصدارات أقدم ومنتشرة من محتوانا ليست قديمة بعد على الرغم من نشر إصدارات أجدد منها. تتم مصادفة هاتين المشكلتين بشكل متكرّر وتمتلكان أثرًا هامًّا على أداء التخزين المؤقّت ودقّة المحتوى الذي نقوم بتخديمه، ومع ذلك نستطيع الحد من هذه المشاكل عن طريق تطوير سياسات تخزين مؤقّت تتوقّع هذه المشاكل. توصيات عامةعلى الرغم من أنّ الحالة هي التي تُملي علينا استراتيجيّة التخزين المؤقّت المُلائِمة، تستطيع التوصيات التالية إرشادنا نحو بعض القرارات المنطقيّة. هناك بعض الخطوات التي نستطيع اتخاذها لزيادة نسبة استخدام التخزين المؤقّت Cache hit ratio قبل الانتقال لاستخدام ترويسات محدّدة، ومن بعض الأفكار نجد: إنشاء أدلّة directories مُخصّصة للصور، ملفات css، والمحتوى المُشترَك: يسمح وضع المحتوى في أدلّة مُخصّصة بالرجوع بسهولة إليها من أي صفحة على موقعنا.استخدام نفس الرابط URL للإشارة إلى نفس العناصر: بما أنّ التخزينات المؤقّتة تستخدم مفتاح مُكوَّن من المُضيف والمسار للمحتوى المطلوب فيجب أن نتأكّد من أن نشير إلى محتوانا بنفس الطريقة على كافّة صفحات موقعنا، وتجعل النصيحة السابقة من هذا أسهل.استخدام الأشكال الشبحية sprites لصور CSS حيثما أمكن ذلك: تُقلِّل الأشكال الشبحية لصور CSS من أجل عناصر مثل الأيقونات والتصفّح navigation من عدد الجولات المطلوبة لتصيير render موقعنا وتسمح لنا بالتخزين المؤقّت لذلك الشكل الشبحي لوقت طويل.استضافة الـ scripts والموارد الخارجيّة بشكل محلّي بقدر الإمكان: إن كُنّا نستخدم scripts خاصة بلغة javascript وموارد خارجيّة أخرى فيجب أن نأخذ بعين الاعتبار استضافة هذه الموارد على خواديمنا الخاصّة، نلاحظ أنّه يجب علينا الانتباه لأي تحديثات جديدة لهذه الموارد لكي نقوم بتحديث نسختنا المحليّة منها.وضع بصمة خاصّة لعناصر التخزين المؤقّت: من المناسب أن نقوم بوضع بصمة خاصّة بالنسبة للمحتوى الثابت مثل ملفّات CSS وJavascript، ويعني هذا إضافة مُعرِّف فريد unique identifier إلى اسم الملف (عادةً تلبيد hash للملف) بحيث إن تمّ تعديل المورد يُمكِن طلب الاسم الجديد للمورد مما يجعل الطلبات تجتاز التخزين المؤقّت بشكل صحيح، توجد العديد من الأدوات التي تساعد في إنشاء بصمات وتعديل المراجع إليها في ملفّات HTML.ومن ناحية اختيار الترويسات الصحيحة للعناصر المختلفة، فيمكن اعتبار ما يلي كمرجع عام: السماح لكافّة التخزينات المؤقتة بتخزين الممتلكات العامّة general assets: ينبغي أن يتم التخزين المؤقّت للمحتوى الثابت وغير المتعلّق بالمستخدم في كافّة النقاط على سلسلة التوصيل، ممّا يسمح للتخزينات المؤقّتة الوسيطة بالاستجابة بالمحتوى للعديد من المستخدمين.السماح للمتصفّحات بالتخزين المؤقّت للممتلكات الخاصّة بالمستخدم: من المقبول والمفيد بالنسبة للمحتوى الخاص بالمستخدم أن نسمح بالتخزين المؤقّت داخل متصفّح المستخدم، وبينما يكون من غير الملائم فعل هذا على التخزينات المؤقّتة الوسيطة يسمح التخزين المؤقّت في المتصفّح بالاستعادة الآنيّة للمحتوى من أجل المستخدمين خلال الزيارات اللاحقة.عمل استثناءات للمحتوى الأساسي الحساس بالنسبة للوقت: إن كنّا نملك محتوى حساس بالنسبة للوقت نقوم بعمل استثناء للقواعد السابقة بحيث لا يتم تخديم المحتوى القديم في الحالات الحرجة، على سبيل المثال إن كان موقعنا يمتلك عربة تسوّق shopping cart فينبغي أن تعكس العناصر الموجودة فيها فورًا، واعتمادًا على طبيعة المحتوى يُمكِن تعيين الخيار no-cache أو no-store في الترويسة Cache-Control لتحقيق هذا.توفير خيارات للتحقّق دومًا: تسمح لنا خيارات التحقّق بتحديث المحتوى القديم بدون أن يتوجّب علينا تنزيل كامل الموارد مرّة أخرى، يسمح تعيين الترويسات Etag وLast-Modified للتخزينات المؤقّتة بأن تتحقّق من محتواها وتعيد تخديمه إن لم يتم تعديله على الخادوم الأصل، مما يؤدي إلى إنقاص الحمل load.تعيين أوقات حداثة freshness times طويلة للمحتوى الداعم: من أجل الاستفادة من التخزين المؤقّت بشكل فعّال فإنّ العناصر المطلوبة كمحتوى داعم لملء الطلب ينبغي عادة أن تملك وقت حداثة طويل، وهو مناسب بشكل عام من أجل لعناصر مثل الصور وملفّات CSS والتي يتم سحبها لتصيير صفحة HTML المطلوبة من قبل المستخدم، يسمح تعيين وقت حداثة طويل مع جمعه بوضع بصمة بأن تقوم التخزينات المؤقّتة بتخزين هذه الموارد لفترات طويلة، فإن تمّ تغيير الممتلكات فستقوم البصمة المُعدّلة بإبطال العنصر المُخزَّن مؤقّتًا وستقوم بتحفيز تنزيل المحتوى الجديد، وحتى ذلك الحين يُمكِن أن يتم تخزين العناصر الداعمة بشكل مؤقّت لوقت طويل في المستقبل.تعيين أوقات حداثة freshness times قصيرة للمحتوى الأب: يجب أن يملك عنصر الاحتواء وقت حداثة قصير نسبيًّا أو حتى لا يتم تخزينه بشكل مؤقّت نهائيًّا وذلك من أجل تطبيق المخطّط السّابق، وهو بشكل نموذجي صفحة HTML التي تستدعي العناصر المساعدة الأخرى، فيتم تنزيل ملفّات HTML بشكل متكرّر ممّا يسمح لها بالاستجابة للتغيرات بسرعة، ومن ثمّ بعدها يُمكِن التخزين المؤقّت للمحتوى الداعم بشدّة.المفتاح الأساسي لتحقيق هذا هو خلق موازنة تُفضِّل التخزين المؤقّت بشدّة حيثما أمكن مع ترك فُرَص لإبطال المُدخلات مُستقبلًا عندما يتم حدوث تغييرات، من المرجّح أن يملك موقعنا تركيبة من: عناصر مُخزَّنة مؤقّتًا بشدّةعناصر مُخزّنة مؤقّتًا مع وقت حداثة قصير والقدرة على إعادة التحقّقعناصر لا ينبغي تخزينها بشكل مؤقّت إطلاقًاوالهدف هو نقل المحتوى إلى الفئة الأولى إن أمكن مع الحفاظ على مستوى مقبول من الدقة. الخاتمةإنّ أخذ الوقت للتأكّد من أنّ موقعنا يملك سياسات تخزين مؤقّت مناسبة في مكانها له تأثير هام عليه، حيث يسمح التخزين المؤقّت بالتقليل من نفقات عرض النطاق bandwidth المترافقة مع تخديم نفس المحتوى بشكل متكرّر، سيكون خادومنا أيضًا قادر على التعامل مع كميّة كبيرة من حركة مرور البيانات traffic باستخدام نفس العتاد، وربّما الأهم من كل ذلك أنّ العملاء سيملكون تجربة أسرع على موقعنا ممّا يقود بهم إلى العودة إليه بشكل متكرّر، وفي حين أنّ التخزين المؤقّت بشكل فعّال ليس حلًّا سحريًّا فإنّ إعداد سياسات تخزين مؤقّت مناسبة يعطينا مكاسب ملموسة بجهد قليل. ترجمة -وبتصرّف- لـ Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies لصاحبه Justin Ellingwood.

يُواجه كلّ شخص في وقتٍ ما مشاكل مع خادوم الوِيب Web Server، سيُساعدك تَعلّمك أين تبحث عندما تواجه مشكلة ما وأيّ العناصر هي التي من المحتمل تمّ تخريبها على إصلاح هذه المشاكل (troubleshoot) بسرعة وبإحباط أقل. سنناقش في هذا الدرس كيف نقوم باستكشاف هذه المشاكل بحيث تستطيع الإبقاء على موقعك يعمل بشكل طبيعي. ما هي أنواع المشاكل النموذجية التي من المحتمل أن تواجهها ؟قد تنشأ في بعض الأحيان بعض المشاكل غير النموذجية إلّا أنّ الغالبية العظمى من المشاكل التي ستصادفها أثناء محاولتك لجعل موقعك يعمل بشكل صحيح تقع ضمن مجموعة يُمكن التنبُّؤ بها كثيرًا. سنقوم بالمرور على هذا بشكلٍ مُفصّل في الأقسام اللاحقة ولكن حاليًّا هذه قائمة من الأشياء التي يجب تفحّصها: هل تمّ تنصيب خادوم الوِيب لديك؟هل خادوم الوِيب قيد التشغيل الآن؟هل الصياغة في ملفات ضبط خادوم الوِيب configuration files صحيحة؟هل المنافذ ports التي قمت بضبطها مفتوحة (لم يتم حجبها من الجدار الناري)؟هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟هل يشير جذر المستند document root إلى موقع ملفاتك؟هل يقوم خادوم الوِيب بتخديم ملفات الفهرس index files الصحيحة؟هل أذونات permissions وملكية الملف ownership وبُنى المجلد صحيحة؟هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟إن كنتَ تملك قاعدة بيانات database في الخلفيّة backend فهل هي تعمل؟هل يستطيع موقعك الاتصال مع قاعدة البيانات بنجاح؟هذه هي بعض أشيع المشاكل التي يُصادفها مُدراء النُّظم عندما لا يعمل الموقع بشكلٍ صحيح، يُمكن عادةً تضييق المشكلة المحددة بإلقاء نظرة على ملفات السّجل Log Files للمكونات المختلفة وعن طريق الرجوع إلى صفحات الخطأ التي تظهر في متصفحك. سنقوم بالمرور في الأسفل على كل من هذه الحالات لكي تستطيع التحقق من أنّ الخدمات مضبوطة بشكلٍ صحيح. التحقق من السّجلات Logsقبل أن تقوم بتعقُّب مشكلة ما بشكلٍ عشوائي حاول أن تتحقق من سجلات خادوم الوِيب Logs لديك ومن أيّة عناصر مرتبطة بذلك، ستجد هذه السّجلات عادةً في المسار var/log/ في مجلّد فرعي مخصّص للخدمة التي تريدها. فعلى سبيل المثال إن كنتَ تملك خادوم Apache يعمل على توزيعة Ubuntu فستجد بشكل افتراضي أنّ السّجلات يتمّ الاحتفاظ بها في المسار var/log/apache2/، قُم بالتحقق من الملفات في هذا المجلد لكي ترى ما نوع رسائل الخطأ التي تمّ توليدها، إن كنت تملك قاعدة بيانات تعمل في الخلفيّة وتسبب لك المشاكل فهي على الأغلب تحتفظ بسجلاتها في المسار var/log/ أيضًا. من الأشياء التي يجب التحقق منها أيضًا أن تتأكد إذا ما كانت العمليّات نفسها تصدر رسائل خطأ عندما تقوم بتشغيل الخدمات، إن كنت تحاول زيارة صفحة وِيب وتلقّيت خطأ فإنّ صفحة الخطأ قد تحتوي على تلميحات عن الخطأ أيضًا (بالرغم من أنّها ليست دقيقة كالسطور في ملفات السّجلات). استخدم محرّك بحث Search Engine لتحاول إيجاد معلومات متعلقة بالموضوع والتي من الممكن أن تقودك في الاتجاه الصحيح، تساعدك الخطوات القادمة في استكشاف الأخطاء أكثر. هل تمّ تنصيب خادوم الوِيب لديك؟إنّ أول شيء تحتاج له لكي تُخدِّم مواقعك بشكل صحيح هو خادوم وِيب. ربّما قام مُعظم الأشخاص فعلًا بتنصيب خادوم قبل الوصول لهذه المرحلة، ولكن في بعض الحالات ربّما تكون أزلت الخادوم عن طريق الخطأ عند تنفيذك لعمليّات على الحزم Packages الأخرى. إذا كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Apache تستطيع كتابة ما يلي: sudo apt-get update sudo apt-get install apache2تُدعى عمليّة Apache على هذه الأنظمة بـ apache2. إن كنت تعمل على نظام تشغيل Ubuntu أو Debian وترغب بتنصيب خادوم وِيب Nginx تستطيع بدلًا من ذلك كتابة: sudo apt-get update sudo apt-get install nginxتُدعى عمليّة Nginx على هذه الأنظمة بـ nginx. إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Apache فقُم بكتابة التالي وبإمكانك إزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root: sudo yum install httpdتُدعى عمليّة Apache على هذه الأنظمة بـ httpd. إن كنت تعمل على أنظمة تشغيل CentOS أو Fedora وترغب باستخدام خادوم وِيب Nginx تستطيع كتابة الأمر التالي، ومرّة أخرى قم بإزالة الأمر "sudo" إن كُنت قد سجّلت الدخول كـ root: sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm sudo yum install nginxتُدعى عمليّة Nginx على هذه الأنظمة بـ nginx. هل خادوم الوِيب قيد التشغيل الآن؟بعد أن قمت بالتأكد من أنّ خادومك مُنَصّب بالفعل، فهل هو قيد التشغيل؟ تُوجَد العديد من الطّرق لكي تكتشف إذا ما كانت الخدمة قيد التشغيل أم لا، واحدة من هذه الطرق والتي تعمل على منصّات متعدّدة cross-platform هي استخدام الأمر netstat. سيُخبِرك هذا الأمر عن جميع العمليّات التي تستخدم منافذ على الخادوم، بإمكاننا بعد ذلك كتابة الأمر grep لإيجاد اسم العملية التي نبحث عنها: sudo netstat -plunt | grep apache2 tcp6 0 0 :::80 :::* LISTEN 2000/apache2يجب عليك تغيير كلمة "apache2" إلى اسم عمليّة خادوم الوِيب الذي لديك، إن ظهر لك سطر كالموجود بالأعلى فهذا يعني أنّ العمليّة قيد التشغيل، أمّا إن لم تحصل على أيّة خَرج فهذا يعني إمّا أنّك قُمت بالاستعلام عن العمليّة الخطأ أو أنّ خادوم الوِيب لديك لا يعمل. يُمكنك في هذه الحالة بدء تشغيله باستخدام الطريقة المفضّلة لتوزيعتك، فعلى سبيل المثال على Ubuntu تستطيع بدء تشغيل خدمة Apache2 بكتابة: sudo service apache2 startوعلى توزيعة CentOS نكتب هذا الأمر: sudo /etc/init.d/httpd startإذا تمّ بدء تشغيل خادومك فعندها تستطيع التحقق باستخدام الأمر netstat مرّة أخرى لكي تتأكد من انّ كل شيء يعمل بشكل صحيح. هل الصّياغة Syntax في ملفات ضبط خادوم الوِيب صحيحة؟ إذا رفض خادوم الوِيب لديك أن يبدأ التشغيل فهذا يشير عادةً إلى أنّ ملفات الضبط تحتاج إلى بعض الانتباه، يتطلّب Apache و Nginx التزامًا صارمًا بتعليمات الصّياغة syntax لكي يتمّ قراءة الملفات بنجاح. تتواجد ملفات إعدادات الضبط لهذه الخدمات عادةً في المسار etc/ في مجلّد فرعي مُسمّى على اسم العمليّة نفسها. وبهذا نستطيع الوصول إلى المجلّد الرئيسي لإعدادات ضبط Apache على Ubuntu بكتابة: cd /etc/apache2ويمكننا الوصول بطريقة مشابهة إلى مجلّد إعدادات ضبط Apache على CentOS والمُسمّى على اسم تلك العمليّة: cd /etc/httpdتكون إعدادت الضبط مُوزّعة على عدّة ملفات، وعندما يفشل بدء الخدمة فإنها ستشير عادةً إلى ملف إعدادات الضبط وإلى السّطر الذي حدثت فيه المشكلة، قُم بالتحقق من هذا الملف بحثًا عن الأخطاء. يُزوّدك كل واحد من خواديم الوِيب هذه بالقدرة على التحقق من صياغة إعدادات الضبط في ملفاتك. إن كُنتَ تستخدم Apache فبإمكانك استخدام الأمر apache2ctl أو apachectl للتحقق من ملفات إعدادات الضبط بحثاً عن أخطاء الصياغة: apache2ctl configtest AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message Syntax OK لقد تلقيّنا كما ترى في الأعلى رسالة معلومات حول تفاصيل إعدادت الضبط لدينا ولم يكن هناك أيّة أخطاء، هذا جيّد. وإن كنتَ تملك خادوم وِيب Nginx تستطيع البدء باختبار مماثل بكتابة: sudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successfulتتحقق هذه العمليّة من صياغتك كما ترى، فإن أزلنا الفاصلة من المنقوطة من نهاية أحد الأسطر في ملف الإعدادات (وهو خطأ شائع بالنسبة لإعدادت ضبط Nginx) فسنحصل على رسالة مماثلة للآتي: sudo nginx -t nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18 nginx: configuration file /etc/nginx/nginx.conf test failedيُوجد عدد خاطئ من المُعطيات arguments لأنّ Nginx يقوم بالبحث عن الفاصلة المنقوطة لإنهاء الجُمَل، فإن لم يجدها ينتقل للسطر التالي ويفسّر ذلك على أنها مُعطيات إضافية للسطر السابق. بإمكانك إجراء هذه الاختبارات لكي تجد أخطاء الصياغة في ملفاتك، قُم بإصلاح هذه المشاكل التي يُشير إليها إلى أن تستطيع ملفاتك تجاوز الاختبار بنجاح. هل المنافذ الذي قمت بضبطها مفتوحة؟تعمل خواديم الوِيب بشكلٍ عام على المنفذ 80 لاتصالات الوِيب الطبيعية normal web traffic وتستخدم المنفذ 443 للاتصالات المشفّرة باستخدام TLS/SSL، ولكي تصل بشكل صحيح إلى الموقع يجب أن تكون هذه المنافذ قابلة للوصول. تستطيع اختبار إذا ما كان الخادوم لديك يملك منفذًا مفتوحًا باستخدام الأداة netcat على حاسوبك المحلّي Local Machine. تحتاج فقط لاستخدام عنوان الـ IP لخادومك وتخبرها عن رقم المنفذ الذي تريد التحقق منه كما يلي: sudo nc -z 111.111.111.111 80سيقوم هذا الأمر بالتحقق من المنفذ 80 على الخادوم الذي يملك عنوان 111.111.111.111، إن كان مفتوحًا سيخبرك الأمر فورًا بالنتيجة، أمّا إن لم يكن مفتوحًا فسيحاول الأمر باستمرار لإنشاء اتصال مع الخادوم دون جدوى، بإمكانك إيقاف هذه العمليّة بضغط على CTRL-C في واجهة الأوامر. إن لم تكن منافذ الوِيب قابلة للوصول لديك فيجب أن تبحث في إعدادات الجدار الناري لديك، حيث قد تحتاج أن تفتح المنفذ 80 أو المنفذ 443. هل تقودك إعدادات الـ DNS إلى المكان الصحيح؟إن كان بإمكانك الوصول إلى موقعك باستخدام عنوان الـ IP ولا تستطيع ذلك عبر اسم المجال domain name فربّما يجب عليك إلقاء نظرة على إعدادت الـ DNS. لكي يتمكّن زوّار موقعك من الوصول إليه عبر استخدام اسم المجال فيجب أن يكون لديك سِجِل "A" أو "AAAA" يشير إلى عنوان الـ IP الخاص بخادومك في إعدادات الـ DNS، تستطيع الاستعلام عن سِجِل “A” لمجالك باستخدام هذا الأمر: host -t A example.com example.com has address 93.184.216.119يجب أن يتطابق السطر الذي يعود لك مع عنوان الـ IP لخادومك، إن كنتَ تريد التحقق من سِجِل "AAAA" (للاتصالات التي تستخدم IPv6) بإمكانك كتابة: host -t AAAA example.com example.com has IPv6 address 2606:2800:220:6d:26bf:1447:1097:aa7يجب أن تبقي في ذهنك أنّ أيّة تغييرات تقوم بها على سِجِل الـ DNS تأخذ وقتًا طويلًا ليتم تعميمها، ربّما تتلقى نتائج متضاربة بعد التغيير حيث أنّ طلبك يتمّ تلقيه من قبل خواديم مختلفة ليست جميعها مُحدّثة إلى آخر إصدار حتى الآن. إن كنتَ تستخدم موقع DigitalOcean فبإمكانك أن تتعلم أساسيات DNS وأسماء النطاقات. قم بالتأكد من أن ملفات إعدادات الضبط تقوم بالتعامل مع مجالك بشكل صحيح. يبدو المقطع الخاص بملف المضيف الوهمي virtual host file لديك في Apache كما يلي: <VirtualHost *:80> ServerName example.com ServerAlias www.example.com ServerAdmin admin@example.com DocumentRoot /var/www/html ٠٠٠يتم إعداد المضيف الوهمي virtual host لكي يستجيب مع أيّة طلبات على المنفذ 80 من أجل المجال example.com. تبدو القطعة المشابهة لهذا في Nginx كما يلي: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name example.com www.example.com; ٠٠٠يتم إعداد هذه الكتلة Block لكي تستجيب إلى النوع المماثل من الطلبات التي تحدثنا عنها في الأعلى. هل يشير جذر المستند Document Root إلى موقع ملفاتك؟من الاعتبارات الأخرى التي يجب أن نأخذ بها هي إذا ما كان خادوم الويب لديك يشير إلى الموقع الصحيح للملف. يتم إعداد كل خادوم وهمي في Apache أو كتلة خادوم Server Block في Nginx لكي تشير إلى مجلّد محدد، فإن كان مُعدًّا بشكل غير صحيح سيرمي الخادوم رسالة خطأ عندما تحاول الوصول إلى الصفحة. يتم إعداد جذر المستند Document Root في Apache باستخدام التوجيه DocumentRoot : <VirtualHost *:80> ServerName example.com ServerAlias www.example.com ServerAdmin admin@example.com DocumentRoot /var/www/html ...يُخبر هذا السطر Apache أنّه يجب عليه البحث عن الملفات لهذا المجال في المسار var/www/html/، فإن كنت تحتفظ بملفاتك في مكانٍ آخر يجب عليك تعديل هذا السطر لكي يشير إلى الموقع الصحيح. يقوم التوجيه root في Nginx بإعداد نفس الشيء: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name example.com www.example.com; ... يبحث Nginx في إعداد الضبط هذا عن الملفات لهذا المجال في المسار usr/share/nginx/html/ هل يقوم خادوم الوِيب بتخديم ملفات الفهرس Index files الصحيحة؟إذا كان جذر المستند لديك صحيحًا ولا يتم تخديم صفحات الفهرس Index Pages بشكلٍ صحيح عندما تذهب إلى موقعك أو إلى مكان المجلد على موقعك فربّما تم ضبط إعدادات الفهارس بشكل غير صحيح. عندما يقوم زائر ما بطلب مجلد يقوم خادومك نموذجيًا بإعطائه ملف فهرسة، عادةً ما يكون هذا ملف index.html أو ملف index.php وذلك اعتمادًا على على إعدادات الضبط لديك. ربّما تجد في Apache سطرًا في ملف المضيف الافتراضي الذي يقوم بضبط إعدادات ترتيب الفهرس التي سيتم استخدامها لمجلدات معيّنة بشكلٍ صريح كما يلي: <Directory /var/www/html> DirectoryIndex index.html index.php </Directory>هذا يعني أنّه عندما يتم تخديم مجلد فإنّ Apache سيقوم بالبحث أولًا عن ملف يدعى index.html، ويحاول تخديم ملف index.php كاحتياط في حال لم يتم إيجاد الملف الأول. بإمكانك تعيين الترتيب الذي سيتم استخدامه لتخديم ملفات الفهرس لكامل الخادوم عن طريق تعديل ملف mods-enabled/dir.conf والذي يقوم بتعيين الإعدادات الافتراضية للخادوم، إن كان الخادوم لديك لا يُخدّم ملف فهرس فقم بالتأكد أنّك تملك ملف فهرس في مجلّدك الذي يُوافق أحد الخيارات في ملفك. يُدعى التوجيه الذي يقوم بذلك في Nginx بـ “index” ويتمّ استخدامه كما يلي: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.html index.htm; server_name example.com www.example.com; ...هل تمّ تعيين الأذونات والملكية بشكل صحيح؟حتى يتمكن خادوم الوِيب من تخديم الملفات الصحيحة يجب أن يكون قادرًا على قراءة الملفات وأن يمتلك صلاحية الوصول للمجلدات حيث يتم حفظ هذه الملفات، بالإمكان التحكم بهذا عبر أذونات وملكية الملفات والمجلدات. لكي تقرأ الملفات يجب أن تكون المجلدات التي تحتوي المحتوى قابلة للقراءة والتنفيذ من قبل عمليّة خادوم الوِيب، تختلف أسماء المستخدمين والمجموعات التي يتم استخدامها لتشغيل خادوم الوِيب من توزيعة لأخرى. على Ubuntu و Debian يعمل كلًّا من Apache و Nginx كالمستخدم www-data والذي هو عضو من المجموعة www-data. على CentOS و Fedora يعمل Apache تحت مستخدم يُدعى apache والذي ينتمي لمجموعة apache، يعمل Nginx تحت مستخدم يُدعى nginx والذي هو جزء من مجموعة nginx. تستطيع باستخدام هذه المعلومات النظر إلى المجلدات والملفات التي يتألف منها محتوى موقعك: ls -l /path/to/web/rootيجب أن تكون المجلدات قابلة للقراءة والتنفيذ من قبل المستخدم web أو مجموعته، أمّا الملفات فيجب أن تكون قابلة للقراءة لكي يتم قراءة محتواها، وبالإضافة لذلك إن أردنا تحميل، كتابة أو التعديل على المحتوى يجب أن تكون المجلدات والملفات قابلة للكتابة، ولكن احذر عند تعيينك للمجلدات لكي تكون قابلة للكتابة لأنّ هذا يُمكن أن يكون أحد المخاطر الأمنية. لتعديل ملكية ملف ما تستطيع فعل ما يلي: sudo chown user_owner:group_owner /path/to/file تستطيع فعل هذا أيضًا للمجلد، فبإمكانك تغيير ملكية المجلد وكل ما بداخله من ملفات عبر تمرير العَلَم –R: sudo chown -R user_owner:group_owner /path/to/file تستطيع التعلم أكثر عن أذونات لينِكس هنا. هل قُمتَ بمنع الوصول عن طريق ملفات الضبط؟من المحتمل أنّه تم تعيين إعدادات الضبط لديك لكي تمنع الوصول إلى الملفات التي تحاول تخديمها. يتم إعداد هذا الضبط في Apache في ملف المضيف الافتراضي لهذا الموقع أو عبر ملف htaccess. الموجود في المجلد نفسه. من الممكن من خلال هذه الملفات أن تقوم بمنع الوصول بعدّة طرق ، يُمكن منع الوصول للمجلدات في إصدار Apache 2.4 بهذه الطريقة: <Directory /usr/share> AllowOverride None Require all denied </Directory>يقوم هذا السطر بإخبار خادوم الوِيب بألّا يسمح لأي شخص بالوصول لمحتويات هذا المجلد، أمّا في إصدار Apache 2.2 والإصدارات الأقدم منه يمكننا كتابة ذلك كما يلي: <Directory /usr/share> AllowOverride None Require all denied </Directory>إن وجدت توجيهًا كهذا للمجلد المُحتوي للمحتوى الذي تحاول الوصول إليه فإنّ هذا هو ما يمنع نجاحك. تأخذ هذه القيود في Nginx شكل توجيهات deny وتتواجد في كتل خادومك أو في ملفات إعدادات الضبط الرئيسية: location /usr/share { deny all; }إن كنتَ تملك قاعدة بيانات database في الخلفية فهل هي تعمل؟إذا كان موقعك يعتمد على قاعدة بيانات في الخلفية مثل MySQL, PostreSQL, MongoDB, etc فستحتاج أن تتأكد من أنّها قيد التشغيل. بإمكانك فعل هذا بنفس الطريقة التي تأكدت منها بأنّ خادوم الوِيب يعمل، مرّة أخرى نستطيع البحث عن العمليات قيد التشغيل ومن ثم انتقاء اسم العملية التي نبحث عنها كما يلي: sudo netstat -plunt | grep mysql tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356/mysqldكما ترى فإن الخدمة قيد التشغيل على هذا الحاسوب، عندما تبحث عن خدمة قُم بالتأكد من أنّك تعرف الاسم الذي تعمل تحته هذه الخدمة. وكبديل لهذا ابحث عن المنفذ الذي تعمل الخدمة عليه إن كنتَ تعلم هذا، ابحث في توثيق documentation قاعدة بياناتك لكي تجد المنفذ الافتراضي الذي تعمل عليه أو تحقق من ملفات إعدادات الضبط. إن كنتَ تملك قاعدة بيانات في الخلفية، فهل يستطيع موقعك الاتصال بنجاح إليها؟الخطوة التالية التي يجب أن تأخذها إن كنت تحاول استكشاف الأخطاء مع وجود قاعدة بيانات في الخلفية هي أن ترى إن كان بإمكانك الاتصال بها بشكلٍ صحيح، يعني هذا عادةً التحقق من الملفات التي يقرؤها موقعك لكي يجد معلومات قاعدة البيانات. على سبيل المثال في موقع WordPress يتم تخزين إعدادات اتصال قاعدة البيانات في ملف يُدعى wp-config.php ، تحتاج للتحقق من أنّ DB_NAME ، DB_USER و DB_PASSWORD صحيحة لكي يتمكن موقعك من الاتصال بقاعدة البيانات. بإمكانك اختبار إذا ما كان الملف يملك المعلومات الصحيحة بمحاولة الاتصال إلى قاعدة البيانات يدويًّا باستخدام ما يلي: mysql -u DB_USER_value -pDB_PASSWORD_value DB_NAME_valueإن لم تتمكّن من الاتصال باستخدام القيم التي وجدتها في الملف فربّما تحتاج إلى إنشاء الحسابات وقواعد البيانات أو تعديل أذونات الوصول لقاعدة بياناتك. هل تمّ ضبط خادوم الوِيب لديك لكي يمرر محتوىً ديناميكيًا إلى معالج نصوص Script Processor؟إن كنت تستخدم قاعدة بيانات في الخلفية، فأنت بكل تأكيد تستخدم لغة برمجة مثل PHP لكي تعالج طلبات للمحتوى الديناميكي، تجلب المحتويات من قاعدة البيانات وتقديم النتائج. إن كانت هذه هي الحالة تحتاج للتأكد من أن خادوم الوِيب لديك مُعَد بشكل صحيح لكي يمرر الطلبات إلى معالج النصوص. يعني هذا بشكل عام في Apache التأكد من تنصيب وتمكين mod_php5، بإمكانك فعل هذا على Ubuntu أو Debian بكتابة: sudo apt-get update sudo apt-get install php5 libapache2-mod-php5 sudo a2enmod php5وفي أنظمة CentOS و Fedora يجب كتابة ما يلي: sudo yum install php php-mysql sudo service httpd restartولكنّ هذا معقّد أكثر قليلًا في Nginx، حيث أنّه لا يملك وحدة PHP ليتمّ تمكينها، لذلك نحتاج أن نتأكد من تنصيب وتمكين php-fpm في إعدادات الضبط. على خادوم Ubuntu أو Debian تأكد أنّه تم تنزيل العناصر بكتابة: sudo apt-get update sudo apt-get install php5-fpm php5-mysqlتستطيع فعل هذا على CentOS أو Fedora بكتابة: sudo yum install php-fpm php-mysql بما أنّ معالج PHP ليس جزءًا من Nginx تحتاج أن تذكر له صراحةً أن يمرر ملفات PHP، اتبع الخطوات الأربعة من هذا الدليل لتتعلم كيف تضبط إعدادات Nginx لكي يمرر ملفات PHP إلى php-fpm، يجب عليك أيضًا أن تلقي نظرة على المقطع من الخطوة الثالثة الذي يتعامل مع إعداد معالج PHP، يجب أن يكون هذا مماثلًا إلى حدٍّ كبير بغض النظر عن توزيعتك. إن فشل كل هذا تحقق من السّجلات مرّة أخرىيجب أن يكون التحقق من السّجلات خطوتك الأولى، ولكنّه من الجيد أن يكون أيضًا خطوتك الأخيرة قبل أن تطلب المزيد من المساعدة. إن بذلت قصارى جهدك في استكشاف الأخطاء بنفسك وتحتاج بعض المساعدة (من صديق، بفتح تذكرة مساعدة، إلخ...) ستحصل على مساعدة بشكل أسرع بتزويد ملفات السجل ورسائل الأخطاء، حيث سيجد مدراء النظم الخبيرون غالبًا فكرة جيّدة عمّا يحصل إن أعطيتهم هذه القطع من المعلومات التي يحتاجونها. الخاتمةآمل أن تكون نصائح استكشاف الأخطاء هذه قد ساعدتك في تعقب وإصلاح بعضًا من أشيع المشاكل التي يواجهها مدراء النظم عند محاولتهم في تشغيل مواقعهم. إن كنت تملك نصائح إضافية عن أشياء يجب التحقق منها وطرق لحل المشاكل قم بمشاركتهم مع المستخدمين الآخرين في التعليقات. ترجمة -وبتصرّف- للمقال How To Troubleshoot Common Site Issues on a Linux Server لصاحبه Justin Ellingwood.

سنتعلم في هذا الدرس كيفية تصميم موقع بطريقة 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.