قبل عشرين عامًا، كان المبرمج الجيّد هو ذلك الذي يكون قادرًا على أن يحشر تطبيقًا كاملًا في ملف بامتداد .COM وبحجم 64 كيلوبايت، أما من كان قادرًا على الإتيان بأفضل أداء مع معالج Intel 80386 الضعيف فكان يعدّ واحدًا من أساطين عالم البرمجة.

سبب ذلك أنّ الحواسيب كانت في تلك الفترة غالية ومكلفة في حين أن أجور المبرمجين كانت زهيدة، وكانت تلك فترة “عقلية المخترق Hacker mentality”، وقد ولّى ذلك الزمن من غير رجعة، ولم تعد هذه العقلية تلقى أي قبول أو احترام في وقتنا الحاضر، ذلك لأنّ حالة السوق اليوم على النقيض تمامًا.

فاليوم أصبحت الحواسيب رخيصة الثمن وأجور المبرمجين مرتفعة، ودخلنا في عصر جديد تسود فيه “عقلية المصمم Designer Mentality” حيث تكون مقروئية الشفرة البرمجية أهمّ بكثير من أدائها.

الأسعار مقابل المرتّبات

انظر إلى هذا الرسم البياني.

يمثّل هذا الرسم البياني مقارنة بين نوعين من التوجهات خلال العقدين الماضيين (1994-2014). ويمكنك أن تلاحظ أن التوجّه الأوّل في تضاؤل تدريجي حيث تصبح ذواكر الحواسيب وأقراص التخزين الصلبة أرخص ثمنًا مع تقدم الزمن.

أما التوجّه الثاني فيبين كيف أنّ مرتّبات مطوري البرمجيات في تصاعد مستمر خلال الفترة ذاتها - تضاعفت ثلاث مرّات إن توخّينا الدقة -. ومع أنّي لم أعثر على تقرير رسمي حول هذا الموضوع، إلا أنّي متأكّد بأنّه ليس خافيًا على أحد أنّ مرتّبات المبرمجين في تصاعد مستمر، إذ لم تعد وظيفة مطوّر رئيسي براتب 200,000 دولار في السنة وظيفة الأحلام، في حين أنّ أفضل العروض كانت تصل إلى 60,000 دولار قبل عشرين عامًا.

هذا يعني أنّ نفقات إنشاء موقع إلكتروني بلغة PHP سنة 1994 أكثر بـ 1000 مرة من نفقات شراء الأجهزة سنة 2014، وأقلّ بثلاث مرات من نفقات المبرمجين، مع الأخذ بالاعتبار أنّنا نستخدم التكنولوجيا ذاتها، إذ لا نزال نستخدم نظام Linux مع خادوم Apache.

الفرق هنا أنّه في سنة 1994 إن كان تطبيقك يواجه مشاكل في الأداء بسبب محدودية الأجهزة، فإنّك ستدفع 35,000 دولار مقابل كل غيغابايت من الذاكرة العشوائية، أما في 2014 فستدفع 10$ فقط.

في سنة 1994 كان توظيف المزيد من المبرمجين بهدف تحسين الشفرة البرمجية أو حتى إعادة كتابتها أفضل وأجدى من شراء أجهزة ومعدّات جديدة، أمّا في سنة 2014 فقد انعكست الأمور تمامًا، فقد أصبحت مضاعفة حجم الخادوم أرخص بمرتين (خصوصًا إن كان الخادوم عبارة عن سحابة افتراضية) من أجور تحسين الشفرة البرمجية.

في سنة 1994 كان أفضل المبرمجين والمهندسين هم أولئك الذين يمتلكون “عقلية المخترق” أما في 2014 فالتقدير أصبح من نصيب كل من يملك “عقلية المصمم”.

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

لو سألت صاحب عقلية المخترق عن رأيه في دالة توليد متسلسلة فابيوناتشي هذه والمكتوبة بلغة Java لأجابك بأنّها “شفرة أنيقة” (هل تظنّ ذلك؟):

public int f(int n) { return n>2?f(n-1)+f(n-2):n; }

عادة ما يتّصف المخترق الجيّد بالصفات التالية:

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

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

وعندما أتوجه بالسؤال التالي إلى أحد أصدقائي المخترقين: “من سيفهم العمل الذي ستؤدّيه هذه الشفرة؟” يكون الجواب الذي أسمعه بصورة شبه دائمة: “سيسألونني!” - عادة ما ترافق الإجابة نبرة استعلاء مصحوبة بابتسامة صادقة.

عقلية المصمّم

أما صاحب عقلية المصمّم فسيعيد ترتيب الشفرة السابقة لجعلها سهلة القراءة، وستكون “الشفرة الأنيقة” في نظره بالصورة التالية (ما رأيك أنت؟):

public int fibo(final int pos) {
  final int num;
  if (pos > 2) {
    num = fibo(pos - 1) + fibo(pos - 2);
  } else {
    num = pos;
  }
  return num;
}

أعتقد أن المصمّم الجيّد يمتاز بالصفات التالية:

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

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

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

المستقبل

إن كنت تعتبر نفسك مخترقًا، فأعتقد أنّه قد حان وقت التغيير، فعصر المخترقين في أفول.

قد نتوقّف عن التفكير في المستقبل القريب بمنطق “الأجهزة” وستعمل تطبيقاتنا على منصّات حاسوبية مرنة تتمتع بذاكرة وقوة معالجة وسعة تخزينية غير محدودة. وبكل بساطة، سننفق أموالنا في الاستفادة من الموارد وستكلّف أي مشكلة في الأداء القليل من الدوﻻرات الإضافية في فواتيرنا الشهرية، ولن نعبأ بمسألة تحسين الشفرة على الإطلاق.

وفي الوقت نفسه، سيتطلّب التعامل مع مهندس للبرمجيات أموالًا أكثر، وقد يطلب 500$ أو أكثر للساعة الواحدة مقابل تفحّص البرنامج وتشخيص المشكلة، كما هو الحال مع المحامين وأطباء الأسنان.

هذا هو السبب الذي يدفع المستثمرين في بناء برنامج جديد إلى وضع جلّ اهتمامهم في مسألة قابلية المنتج للصيانة Maintainability. وسيدرك مموّلو المشاريع أن أفضل منتج يمكن الحصول عليه مقابل أموالهم هو ذلك المنتج الذي يتمتع بأعلى قدر من المقروئية وقابلية الصيانة والأتمتة، وليس أعلى قدر من السرعة.

ترجمة - وبتصرّف - للمقال Are You a Hacker or a Designer? لصاحبه Yegor Bugayenko.
حقوق الصورة البارزة محفوظة لـ Freepik

يشبه أداء المواقع كثيرًا قاعدة 80/20، حيث إن إجراء تحسينات بنسبة 20% ستزيد سرعة الموقع الإلكتروني بنسبة 80%. فاتّخاذ خطوات بسيطة مثل تنظيم شفرة CSS يأتي بثمار طيّبة.

يشرح هذا المقال خطوات بسيطة يمكن أن يؤدّي تطبيقها - إلى جانب تنظيم شفرة CSS - إلى تحسّن ملحوظ في أداء الموقع.

تصغير الملفات وضغطها

تعدّ إزالة الشفرة المتكررة وغير الضرروية من أبسط الطرق وأفضلها في تقليل حجم ملف CSS، ولكن هناك بعض الطرق الأخرى. تتمثّل إحدى هذه الطرق في تصغير minify وضغط ملفات HTML و CSS و JavaScript. كذلك يمكن ضغط الصور وإزالة التعليقات و مواصفات الألوان Color Profiles غير الضرورية.

آلية gzip للضغط

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

ليست تهيئة gzip بالأمر الصعب، وقد أبلى فريق HTML5 Boilerplate بلاءً حسنًا في هذا المجال. ولضغط الملفات بآلية gzip ستحتاج إلى إضافة ملف .htaccess إلى المجلد الرئيسي في خادوم الويب ثم تدرج في هذا الملف أنواع الملفات التي ترغب في ضغطها. لا تنسَ إضافة النقطة إلى بداية اسم الملف، لأنّ هذا الملف هو من الملفات المخفية.

يمكنك أن تجد في إعدادات خادوم Apache في HTML5 Boilerplate أنواع الملفات التي يُنصح بضغطها، ولا بأس بالتذكير مرة أخرى أنّ شفرة ضغط هذه الملفات يجب أن تكون في ملف .htaccess في المجلد الرئيسي لخادوم الويب. وجدير بالذكر أن هذا الملف لا يعمل إلا مع خواديم Apache والتي تتطلب تفعيل الوحدات التالية.

• mod_setenvif.c
• mod_headers.c
• mod_deflate.c
• mod_filter.c
• mod_expires.c
• mod_rewrite.c

لا تقلق إن وجدت صعوبة في هذا الأمر، فهناك بعض الخواديم التي تهيّئ لك هذه الأمور نيابة عنك، فبطبيعة الحال، ضغط الملفات وتصغير حجمها يكون دائمًا في مصلحة خادوم الويب.

قياس نسبة الضغط

تقدّم أداة الفحص Inspector في متصفح Google Chrome عددًا كبيرًا من المعلومات حول أداء الصفحة، ويمكن الوصول إليها من خلال التبويب Network. إضافة إلى ذلك، هناك عدد من المواقع الإلكترونية التي تساعد على معرفة ما إذا كانت خاصية الضغط gzip مفعّلة أم لا.

في تبويب Network يتم التعرّف على جميع الملفات المحمّلة بواسطة المتصفح وعرض أحجام تلك الملفات والمدة التي استغرقتها عملية التحميل. لاحظ كيف أن ضغط الملفات قد قلّل من حجمها بنسبة 60% تقريبًا.

يمكن التعرّف على أنواع وسائل الضغط التي يدعمها المتصفح من خلال اختيار أحد الملفات. في الصورة أعلاه نلاحظ أنّ المتصفح يدعم gzip، deflate و sdch كما هو مبيّن في ترويسة الطلب المرسل من المتصفح.

أما ترويسة Header الإجابة الواردة من الخادوم فتبيّن أن الملف مضغوط بواسطة gzip.

ضغط الصور

قد يكون تقليل حجم الملفات النصّية مفيدًا، ولكن يمكن الحصول على نتائج أفضل من خلال ضغط ملفات الصور. يمكن لحجم ملفات الصور المستخدمة في الموقع الإلكتروني أن يصبح كبيرًا جدًّا، وضغط الصور يمكن أن يساعد على إبقاء حجم الملفات الكلي تحت السيطرة.

يتجنّب الكثيرون مسألة ضغط الصور وذلك خوفًا من أن يتسبب الضغط في تقليل جودة الصورة، ولكن هذا غير صحيح في أغلب الأحيان، إذ يمكن ضغط الصورة دون المساس بجودتها، وذلك من خلال التخلص من مواصفات الألوان والتعليقات غير الضرورية.

تتوفّر العديد من الأدوات التي تساعد على ضغط الصور، من أفضلها ImageOptim لنظام Mac و PNGGauntlet لنظام Window، و Trimage لنظام لينكس. تقوم هذه الخدمات بضغط صيغ الصور الأكثر شيوعًا مثل JPG و PNG.

نموذج لضغط الصور

غير مضغوطة، 455kb

مضغوطة، 401kb

باستخدام ImageOptim فإنّ حجم الصورة أعلاه قد انخفض بمقدار 14% دون المساس بدقّة الصورة أو جودتها.

من الجدير بالذكر هنا أن اختيار أبعاد الصورة في HTML باستخدام خاصيتي height و width يساعد على تصيير الصورة بسرعة أكبر وذلك بتحديد الحجم المناسب للصورة. ولكن يجب الانتباه إلى أن هاتين الخاصيتين تستخدمان في تحديد أبعاد الصورة الحقيقية لا لتصغير حجمها، فمن الممارسات السيئة في هذا الصدد استخدام صورة ذات حجم كبير ثم تصغيرها باستخدام خاصية height و width، والنتيجة تحميل بيانات فائضة عن الحاجة.

    <img src="ocean.jpg" height="440" width="660" alt="Oceanview">

تقليل طلبات HTTP

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

دمج الملفات المتشابهة

إحدى الطرق المتّبعة في تقليل طلبات HTTP - وربّما أسهلها - تتمثّل في دمج الملفات المتشابهة، بمعنى دمج جميع ملفات CSS في ملف واحد وجميع ملفات JavaScript في ملف واحد كذلك. يؤدي دمج هذه الملفات ثم ضغطها إلى إنشاء طلب HTTP واحد صغير نسبيًا.

    <!-- سيء -->
    <link href="css/reset.css" rel="stylesheet">
    <link href="css/base.css" rel="stylesheet">
    <link href="css/site.css" rel="stylesheet">

    <!-- جيد -->
    <link href="css/styles.css" rel="stylesheet">

يجب تحميل ملفات CSS في بداية صفحة الوِب ضمن الوسم head، أما ملفات JavaScript فيجب تحميلها في نهاية الصفحة ضمن الوسم body. والسبب هو أنّه يمكن استكمال تحميل ملفات CSS أثناء تحميل بقية أجزاء الصفحة، في حين أنّه لا يمكن تصيير ملفات JavaScript متعددة في نفس الوقت، لذا فإن هذه الملفات تمنع تحميل بقية عناصر الصفحة. يجب الانتباه هنا إلى ملفات JavaScript تُحمّل لا تزامنيًا Asynchronously بعد اكتمال تصيير الصفحة، وكذلك يجب الانتباه إلى أن JavaScript قد تكون مطلوبة في تصيير عناصر الصفحة كما هو الحال عند اسخدام HTML5 shiv.

شرائح الصور Image Sprites

المقصود بشرائح الصور في CSS هو استخدام صورة خلفية واحدة في مجموعة من العناصر، والهدف هنا هو تقليل عدد طلبات HTTP الناشئة من استخدام مجموعة من الصور.

ولإنشاء شريحة اختر مجموعة من صور الخلفية الأكثر استخدامًا ورتّبها إلى جانب بعضها البعض في صورة واحدة، ثم باستخدام CSS أضف الشريحة كصورة خلفية إلى عنصر معين، ثم استخدم خاصّية background-position لعرض الصورة المطلوبة.

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

هذا مثال عن شريحة تضم صورًا لأيقونات قائمة محرر النصوص، وقد أحيطت كل صورة بخطوط إرشادية لتوضيح أماكن تغيّر موقع الخلفية.

يمكن إنشاء قائمة باستخدام شريحة الصور السابقة وذلك بجعلها خلفية للعنصر span، ثم يمكن تغيير موضع الشريحة بواسطة الأصناف، وبذلك يمكن عرض الأيقونة المناسبة في كل مرة.

HTML

    <ul>
      <li><a href="#"><span class="bold">Bold Text</span></a></li>
      <li><a href="#"><span class="italic">Italicize Text</span></a></li>
      <li><a href="#"><span class="underline">Underline Text</span></a></li>
      <li><a href="#"><span class="size">Size Text</span></a></li>
      <li><a href="#"><span class="bullet">Bullet Text</span></a></li>
      <li><a href="#"><span class="number">Number Text</span></a></li>
      <li><a href="#"><span class="quote">Quote Text</span></a></li>
      <li><a href="#"><span class="left">Left Align Text</span></a></li>
      <li><a href="#"><span class="center">Center Align Text</span></a></li>
      <li><a href="#"><span class="right">Right Align Text</span></a></li>
    </ul>

CSS

    ul {
      margin: 0;
      padding: 0;
    }
    li {
      float: left;
      list-style: none;
      margin: 2px;
    }
    li a {
      background: linear-gradient(#fff, #eee);
      border: 1px solid #ccc;
      border-radius: 3px;
      display: block;
      padding: 3px;
    }
    li a:hover {
      border-color: #999;
    }
    li span {
      background: url("sprite.png") 0 0 no-repeat;
      color: transparent;
      display: block;
      font: 0/0 a;
      height: 16px;
      width: 16px;
    }
    .italic {
      background-position: -16px 0;
    }
    .underline {
      background-position: -32px 0;
    }
    .size {
      background-position: -48px 0;
    }
    .bullet {
      background-position: -64px 0;
    }
    .number {
      background-position: -80px 0;
    }
    .quote {
      background-position: -96px 0;
    }
    .left {
      background-position: -112px 0;
    }
    .center {
      background-position: -128px 0;
    }
    .right {
      background-position: -144px 0;
    }

(تجربة حيّة)

معرّف الموارد الموحّد URI الخاص ببيانات الصورة

إضافة إلى استخدام شرائح الصور، يمكن الاستفادة من البيانات المُرمَّزة Encoded للصورة وتضمينها مباشرة في HTML و CSS وذلك من خلال معرّف الموارد الموحّد الخاص بالبيانات Data URI، وبهذا لن يُرسَل أي طلب HTTP إلى الخادوم. هذه الطريقة مفيدة للصور الصغيرة والتي لا تكون عرضة للتغيير، وعندما يكون بالإمكان نقل ملفات HTML و CSS إلى ذاكرة التخبئة Cach. ولكن لا يخلو الأمر من مشاكل، إذ يصعب أحيانا تبديل هذه المعرّفات ومتابعتها وقد تحتاج إلى توليد المعرّف مرة أخرى، إضافة إلى أنّها لا تعمل مع المتصفحات القديمة وخصوصًا Internet Explorer 7 وما قبله.

إن كان بالإمكان تقليل عدد طلبات HTTP باستخدام هذه الطريقة، وإن كان بالإمكان تخزين ملفات HTML و CSS في ذاكرة التخبئة فإن الفوائد التي ستجينها باستخدام هذه الطريقة تفوق المشاكل المترتبة عنها. هناك عدد من الأدوات التي تساعد في توليد معرّف البيانات مثل هذا المحوّل وأداة Patternify. ومع ذلك تأكّد دائمًا من أنّ حجم البيانات في معرّف البيانات الخاصّ بالصورة أقل حجمًا من ملفّ الصورة الأصلية.

HTML

    <img height="100" width="660" alt="Rigged Pattern" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAICAYAAADA+m62AAAAPUlEQVQYV2NkQAO6m73+X/bdxogujiIAU4RNMVwhuiQ6H6wQl3XI4oy4FMHcCJPHcDS6J2A2EqUQpJhohQAyIyYy0nBAGgAAAABJRU5ErkJggg==">

CSS

    div {
      background: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAICAYAAADA+m62AAAAPUlEQVQYV2NkQAO6m73+X/bdxogujiIAU4RNMVwhuiQ6H6wQl3XI4oy4FMHcCJPHcDS6J2A2EqUQpJhohQAyIyYy0nBAGgAAAABJRU5ErkJggg==") repeat;
    }

(تجربة حيّة)

خزّن الملفات الشائعة في ذاكرة التخبئة

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

وكما هو الحال مع ضغط الملفات، فإنّ تعيين مدّة بقاء الملفات في ذاكرة التخبئة يكون من خلال ملف .htaccess. ومرة أخرى فقد أعدّ فريق HTML5 Boilerplate ملفًّا خاصًّا لتعيين تاريخ انتهاء صلاحية الملفات في ذاكرة التخبئة وذلك في إعدادات خادوم Apache الخاصّ بهم.

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

    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"

إن كانت ملفات CSS و JavaScript تتغيّر في كل أسبوع ولا يُتحكَّم في إصداراتها باستخدام ملفات منفصلة فمن الأفضل تغيير قيمة "access plus 1 year" إلى "access plus 1 week". ويمكن مراجعة صفحة صيغة mod_expires للتعرّف على القيم المتاحة.

ترجمة - وبتصرّف - للمقال Performance & Organization لصاحبه Shay Howe.

حقوق الصورة البارزة محفوظة لـ Freepik

دفع عجلة تطوير الويب تعني جعله أفضل للمستخدمين والمطورين على حدٍ سواء، وهذا يعني محاولة حلّ المشكلات التي تواجه الويب في الوقت الراهن؛ وهذا ينطبق أيضًا على جعل المواقع متوافقة مع اتجاه RTL بسهولة ويسر.

قبل أن نكمل مشوارنا في الحديث عن المواضيع المتقدمة عن RTL، لنبدأ درسنا بمثالٍ عمليٍ بسيط لتتذكر فيه كيف نقلب الاتجاه إلى RTL بطريقةٍ صحيحة:

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

التقنيات الحديثة

الأساس الذي تستند عليه الواجهات ذات الاتجاه من اليمين إلى اليسار (RTL) هو خاصيات CSS، وهذه الخاصيات تتطور مع الوقت كما هو حال بقية مكوّنات الويب.
سأذكر هنا بعض خاصيات CSS التي يمكنك تجربتها على الفور في النسخ الحديثة من المتصفحات (من المحتمل أن تتغير هذه المعلومات بعد صدور تحديثات جديدة للمتصفحات).
محاذاة النص: تعودنا في الماضي على تحديد المحاذاة الأفقية للنص عبر text-align: left أو right؛ أما الآن، فلدينا القيمتان start و end. فعلى سبيل المثال text-align: start ستعطي نتيجةً مختلفةً بناءً عمّا إذا كان اتجاه المحتوى من اليمين إلى اليسار أم من اليسار إلى اليمين. القيمة start تُشير إلى اليسار في اتجاه LTR وإلى اليمين في اتجاه RTL، والعكس صحيح للقيمة end.
مثالٌ يستخدم left|right:

#content {
  text-align: left:
}
html[dir="rtl"] #content {
  text-align: right;
}

أما لو استعملنا start|end:

#content {
  text-align: start;
}

لا حاجة إلى استعمال قاعدة خاصة باتجاه RTL باستخدامنا للقيمتين start|end.
دعم المتصفح: Chrome 1.0+‎، و Safari 3.1+‎، و Firefox 3.6+‎، وأندرويد، و iOS، غير مدعومة في متصفح Internet Explorer في الوقت الراهن.
خاصيات padding و margin و border: هنالك تحسيناتٌ أُدخِلَت على تلك الخاصيات.
أصبحت كل واحدة منها تقبل لاحقةً إضافيةً هي ‎-inline-start أو ‎-inline-end، فمثلًا يمكننا أن نكتب padding-inline-end أو margin-inline-start. تعطي هذه الكلمات المحجوزة الجديدة نفس تأثير start و end في محاذاة النص: الخاصية padding-inline-start تماثِل padding-left في اتجاه LTR وتماثِل padding-right في اتجاه RTL. أما margin-inline-end تعطي نفس تأثير margin-right في اتجاه LTR و margin-left في اتجاه RTL.
مثالٌ يستعمل left|right:

#content {
  padding-left: 12px:
  margin-right: 20px;
}
html[dir="rtl"] #content {
  padding-left: 0;
  padding-right: 12px;
  margin-left: 20px;
  margin-right: 0px;
}

نفس المثال لكن باستعمال start|end:

#content {
  padding-inline-start: 12px:
  margin-inline-end: 20px;
}

أكرِّر أنَّه لا حاجة إلى قاعدة خاصة باتجاه RTL؛ فستصبح خاصية margin-inline-end وكأنها margin-right في اتجاه LTR و margin-left في اتجاه RTL.
دعم المتصفحات: Firefox 41+‎ فقط.
تحديد الموقع المطلق (absolute position) للعناصر: الخاصيتان left وright أساسيتان لتحديد الموقع المطلق، لكن قريبًا سترى استخدامًا لخاصياتٍ أذكى، ألا وهي offset-inline-startوoffset-inline-end.
يجدر بالذكر أنَّك تستطيع استعمال offset-block-startوoffset-block-end بدلًا من top و bottom على التوالي وبالترتيب.
مثالٌ يستعمل left|right:

#content {
  position: absolute;
  left: 5rem;
}
html[dir="rtl"] #content {
  left: auto;
  right: 5rem;
}

نفس المثال لكن باستعمال start|end:

#content {
  offset-inline-start: 5rem;
}

أكرر مرةً أخرى أنَّ مفهوم start|end وفَّر علينا كتابة بعض الشيفرات في ملف CSS.
دعم المتصفحات: Firefox 41+‎ فقط.
تحديد موقع العناصر باستخدام float: استعملنا float: left و float: right لوقتٍ طويل، لكنك ستتمكن قريبًا من استعمال float: inline-start و float: inline-end. خاصية inline-start ترتِّب عنصرك إلى اليسار في اتجاه LTR وإلى اليمين في اتجاه RTL.
مثالٌ يستعمل left|right:

#content {
  float: left;
}
html[dir="rtl"] #content {
  float: right;
}

نفس المثال لكن باستعمال start|end:

#content {
  float: inline-start;
}

دعم المتصفحات: Firefox 44.
Web Components (مكوِّنات الويب): وهي عناصر الواجهة الرسومية القابلة لإعادة الاستخدام. إذا تعاملت مع web components من قبل فستعلم أنَّ أنماط CSS الخاصة بها موجودة ضمن شجرة DOM فرعية (shadow DOM)، لذا لن تتمكن افتراضيًا من الحصول على اتجاه الصفحة التي تستعمل تلك المكوِّنة عبر html[dir="rtl"]، لكن شجرة DOM الفرعية (shadow DOM) تتضمن محدِّدًا جديدًا اسمه ‎:host-context()‎ الذي تستطيع استخدامه لتحديد عنصر في شجرة DOM الأساسية (host DOM).
لنحاول تبسيط الأمر عبر مثال. لنقل أنَّ لديك عنصرًا داخل شجرة DOM فرعية اسمه back. كنت ستستخدم html[dir="rtl"] .back {}‎ في حال لم تكن داخل شجرة DOM فرعية، لكنك لا تستطيع استخدام هذا المُحدِّد من داخل مكوِّن (component). المُحدِّد المكافئ للمحدِّد السابق الذي تستطيع استخدامه داخل مكوِّن هو:

.back:host-context(html[dir="rtl"]) { }

ليس من الواضح ما مدى دعم هذا النوع من المُحدِّدات، لكن يمكنك استخدام هذه الطريقة الالتفافية.
لا ترغب باستخدام الطرق الالتفافية لكنك تريد أن تجرِّب اتجاه RTL في web component في المتصفحات التي تدعمها مثل فيرفكس (بعد تفعيل الراية dom.webcomponents.enabled) ومتصفح Google Chrome؟ يمكنك فعل ذلك عبر Mutation Observers بمراقبة الخاصية document.documentElement.dir. ستبدو شيفرة المراقبة شبيهةً بالمثال الآتي:

var dirObserver = new MutationObserver(updateShadowDir);
dirObserver.observe(document.documentElement, {
  attributeFilter: ['dir'],
  attributes: true
});

لا تنسَ أن تُهيّئ دالتك لأول مرة بعد تحميل الصفحة، بعد شيفرة المراقبة مباشرةً:

updateShadowDir();

ستبدو دالة updateShadowDir()‎ كالآتي:

function updateShadowDir() {
  var internal = myInnerElement.shadowRoot.firstElementChild;
  if (document.documentElement.dir === 'rtl') {
    internal.setAttribute('dir', 'rtl');
  } else {
    internal.removeAttribute('dir');
  }
};

كل ذلك عبر JavaScript. سيملك أول «ابن» (first child) في المكوِّنة خاصية dir قابلة للتغيير، وستعتمد أنماط CSS عليه كمُحدِّد بدلًا من عنصر html. ولنقل أنَّ ذاك العنصر هو span، لذا سيكون مُحدِّدك شبيهًا بما يلي:

span[dir="rtl"] rest-of-the-selectors-chain { … }

أعلم أنَّ الأمر يبدو معقدًا، لكن –لحسن الحظ– المستقبل مشرق، لذا لنلقِ نظرةً على ما تُخبّؤه W3C لنا في المستقبل بما يخص اتجاه RTL.

مستقبل اتجاه RTL في الويب

إعلام الخادوم باتجاه النص: في الوقت الراهن نفقد قيمة اتجاه الصفحة (أو اتجاه عناصر النموذج) عند إرسال نموذج يحتوي على حقول إدخال نصية. أتت الخواديم بطرقٍ خاصةٍ بها لكي تُحدِّد اتجاه النص الُمرسَل إليها.
لحل هذه المشكلة ولإضافة معلومات حول اتجاه النص المُرسَل، ابتكرت W3C خاصيةً جديدةً ووضعتها في مواصفة نماذج HTML5 اسمها dirname، التي ستُضيفها المتصفحات في المستقبل القريب.
وكما ذَكَرَ المعيار، «تضمين خاصية dirname في حقول النموذج يُفعِّل إرسال اتجاه العنصر، ويعطي اسم الحقل الذي يحتوي على هذه القيمة أثناء عملية الإرسال. إذا حُدِّدت هذه الخاصية، فيجب ألّا تكون قيمتها فارغةً».
بعبارة أخرى: إضافة هذه الخاصية إلى حقول <input> أو <textarea> يؤدي إلى تمرير اتجاهها مع معلومات GET أو POST التي ستُرسَل إلى الخادوم. لننظر إلى مثالٍ عملي. ليكن لدينا هذا النموذج:

<form action="result.php" method="post">
<input name="comment" type="text" dirname="comment.dir"/>
<button type=submit>Send!</button>
</form>

ستحتوي عبارة POST التي ستُرسَل إلى الخادوم على حقلٍ اسمه comment، وحقلٍ آخر اسمه comment.dir. وإذا كتب المستخدم الكلمة «Hello» في الحقل النصي وأرسل النموذج، فستكون النتيجة هي:

comment=Hello&comment.dir=ltr

أما إذا كتب «مرحبا» فستكون النتيجة هكذا:

comment=%D9%85%D8%B1%D8%AD%D8%A8%D8%A7&comment.dir=rtl

يمكنك قراءة المواصفة من هنا.
ملاحظة: لكي تُعرَض المحارف العربية عرضًا صحيحًا في عناوين URL في متصفحك، فيجب أن تُرمَّز المحارف بترميز UTF-8، وكل حرف عربي يستعمل 4 محارف مفصولة فيما بينهما برمز %.
على سبيل المثال، لو كان لديك هذا الرابط؛ فسيحوله متصفحك عندما تزوره إلى هذه الصّفحة

طرق أفضل لكيفية التعامل مع الخلفيات والصور في RTL

هل سئمتَ من استخدام transform: scaleX(-1) لعكس صور الخلفية؟ قدّمَت W3C كلمةً محجوزةً جديدةً في CSS اسمها rtlflip التي تُستعمل كما يلي:

background-image: url(backbutton.png) rtlflip;

ستقلل عليك هذه الكلمة المحجوزة من عبء قلب جميع صورك عبر خاصية transform: scaleX(-1) يدويًا. من الممكن استعمالها أيضًا في قاعدة صور القوائم كما يلي:

list-style-image:url('sprite.png#xywh=10,30,60,20') rtlflip;

تقول صفحة المواصفة أيضًا أنَّ هذه الكلمة المحجوزة يمكن أن تستعمل في جميع الطرق الممكنة لتحديد الصور في CSS3. على سبيل المثال: url و sprite و image-list و linear-gradient و radial-gradient.

الواجهة البرمجية للتدويل

إليكم بعض الأجزاء غير المشهورة المتعلقة باتجاه RTL في الواجهة البرمجية للتدويل (Internationalization APIs) في JavaScript
تدعم الواجهة البرمجية للتدويل عددًا كبيرًا من اللغات مع مشتقاتها؛ فمثلًا لا تدعم هذه الواجهة البرمجية اللغة العربية فحسب، وإنما تدعم «العربية-مصر» و «العربية-تونس» وقائمة طويلة بالاشتقاقات الأخرى.
استخدام الأرقام العربية المشرقية بدلًا من الأرقام العربية الغربية: تُستخدم الأرقام العربية المشرقية (١٢٣) في بعض البلدان بدلًا من الأرقام العربية الغربية (123). تسمح لنا واجهة التدويل البرمجية بتحديد متى نريد إظهار ١٢٣ ومتى نظهر 123.

console.log(new Intl.NumberFormat('ar-EG').format(1234567890));

السطر السابق يقول أنَّنا نريد تنسيق الرقم 1234567890 بصيغة الأرقام التي تستعملها مصر (ar-EG). الناتج: ١٬٢٣٤٬٥٦٧٬٨٩٠

console.log(new Intl.NumberFormat('ar-TN').format(1234567890));

نقول هنا أننا نريد إظهار الرقم بالصيغة المعتمدة في تونس؛ ولمّا كانت تونس تستعمل الأرقام العربية الغربية، فسيكون الناتج: 1234567890
إظهار التواريخ بالتقويم الهجري بدلًا من الميلادي: هناك صفحة google.com/ramadan خاصة بإظهار معلومات حول شهر رمضان. وأحد أهم المعلومات الموجودة هي رقم اليوم في الشهر الهجري (القمري). تستخدم Google طريقة التفافية للحصول على هذه المعلومات. لكنك تستطيع الحصول على نفس المعلومات عبر الواجهة البرمجية للتدويل بسطرٍ وحيد بدلًا من مكتبة JavaScript كاملة.
هذا مثال:

console.log(new Intl.DateTimeFormat("fr-FR-u-ca-islamicc").format(new Date()));

السطر السابق يعني أنَّنا نريد أن يكون التاريخ الحالي بالتقويم الهجري وأن يُعرَض بالأرقام العربية الغربية (fr-FR). الناتج هو: 16/12/1436

console.log(new Intl.DateTimeFormat("ar-SA-u-ca-islamicc").format(new Date()));

نفس الأمر هنا، لكن التنسيق لمحليّة (locale) الخاصة بالسعودية التي تستعمل الأرقام العربية المشرقية. الناتج: ١٦‏/١٢‏/١٤٣٦

الخلاصة

رأينا في هذا الدرس بعض التقنيات المتقدمة لدعم اتجاه RTL، وأخذنا فكرةً عن مستقبل دعم RTL من معايير الويب.
ترجمة -وبتصرّف- للمقال Building RTL-Aware Web Apps & Websites: Part 2 لصاحبه أحمد نفزاوي

هذا هو الدرس الأول من درسين يشرحان لك كيف تطوِّر مواقع الويب ذات الاتجاه من اليمين إلى اليسار (RTL)، وهذا يعني جعل موقع الويب متوافقًا مع اللغات التي تُكتَب من اليمين إلى اليسار مثل العربية والفارسية والأردو.

ماذا يعني اتجاه الكتابة من اليمين إلى اليسار؟

لتوضيح الأمور، هنالك فرقٌ بين اللغة (التي هي الشكل المحكي) والمخطوطة (script، أي طريقة الكتابة). أي تقنيًا، الاتجاه من اليمين إلى اليسار يكون للمخطوطات التي تُكتَب بها اللغات، وذلك مقارنةً مع الاتجاه من اليسار إلى اليمين في لغاتٍ مثل الإنكليزية أو الفرنسية.

مصطلح «اليمين-إلى-اليسار» (Right-to-Left) أو RTL اختصارًا، يُشير إلى أكثر من مجرد المخطوطة المستعملة للكتابة؛ حيث يُشير إلى جميع الأمور المتعلقة بتطوير مواقع وتطبيقات الويب لكي تظهر بشكل سليم عند استخدام اللغة العربية أو غيرها من اللغات التي تُكتَب من اليمين إلى اليسار.
قبل المتابعة، لنوضِّح بعض الالتباسات حول RTL.
أولًا، RTL لا تعني ترجمة النص إلى العربية: فالأمر أكثر من مجرد ترجمة واجهة موقعك إلى العربية، وإنما جعل كل جزء من الواجهة الرسومية ملائمًا لاتجاه RTL؛ وأنصحك أن تفعل ذلك بشكلٍ صحيح، فعدم إكمالك لدعم اتجاه RTL سيفقدك زوارك ومصداقيتك.
ثانيًا، اتجاه RTL لا يعني «قلب كل شيء»: لستُ متأكدًا إن أُصلِحتَ هذه العلة أم لا، لكن ضبط «المحلية» (locale) إلى العربية في واجهة Gnome سيؤدي إلى إظهار الوقت بالشكل «PM 33:12» بدلًا من «‏12:33‎ PM‏‏».
هذا ليس صحيحًا، نحن لا نذكر الوقت بالمقلوب بالعربية. أي أنَّ هنالك استثناءات وأشياء يجب الانتباه إليها مثل الأرقام، وسنشرح ذلك لاحقًا.
لماذا عليك أن تهتم بدعم موقعك لاتجاه RTL؟
ربما تطور مواقع عالمية بلغاتٍ مثل الإنكليزية أو الفرنسية، وأنت متخوفٌ من RTL وتحسبها صعبةً ومرعبةً وستُضيف كمًا كبيرًا من العمل على مشروعك. حسنًا، الأمر ليس كما تظن، فبعد أن تستوعب المبادئ الأساسية، فلن تحتاج إلا لبذل جهدٍ قليلٍ.
من البدهي أن تهتم –كمطور ويب عربي– بدعم الموقع التي تطوره للغة العربية (أو لبقية اللغات التي تُكتَب من اليمين إلى اليسار)؛ فلا حاجة لتذكيرك أنَّ هنالك أكثر من 410 مليون شخص حول العالم يتحدث لغةً تُكتَب من اليمين إلى اليسار (وهذا عددٌ ضخمٌ جدًا. لاحظ أنَّ الرقم التقديري السابق مبنيٌ على قائمة اللغات في ويكيبيديا). أصبحت أغلبية الشركات تُضيف دعمًا للغات المكتوب من اليمين إلى اليسار في برمجياتها (مثل ويندوز، و iOS، وأندرويد) وكذلك الأمر للعديد من المواقع العالمية؛ لذا سيتوقع زوار موقعك مِمَن يتحدثون العربية (وغيرها من اللغات المكتوبة من اليمين إلى اليسار) أن يحقق موقعك هذه التوقعات بما يخص دعم RTL. فبدون هذا الدعم قد لا يتحول زوار موقعك إلى زوارٍ دائمين.

دورة تطوير واجهات المستخدم

ابدأ عملك الحر بتطوير واجهات المواقع والمتاجر الإلكترونية فور انتهائك من الدورة

اشترك الآن

نصائح عامة لدعم اتجاه RTL

هذه بعض القواعد العامة التي أحببت أن أذكرك بها والتي عليك أن تبقيها ببالك عند تطوير تطبيقات ومواقع ويب تدعم RTL:

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

• لا تظن أنَّ مستخدمي RTL هم أشخاصٌ يستعملون أياديهم اليسرى. فأغلبية مَن يتحدث بالعربية يكتبها بيده اليمنى، كما هو الحال في بقية أنحاء العالم. لذا لا تقلب أيّ شيءٍ ليس متعلقًا بكيفية قراءة المستخدم لمحتوى الصفحة. مثالٌ على هذا هو شريط التمرير «أ-ي A-Z» (الموجود على يمين الصورة السابقة) في تطبيق «جهات الاتصال» في أغلبية الهواتف الذكية. هذا الشريط موضوعٌ على الجهة اليمنى لأنه من الأسهل استخدامه باليد اليمنى، لذا لا حاجة إلى قلب اتجاهه وجعله في الجزء الأيسر في نمط RTL.

كيفية جعل المحتوى RTL

أول خطوة نحو جعل اتجاه صفحة الويب من اليمين إلى اليسار هي إضافة dir="rtl"‎ إلى وسم <html>:

<html dir="rtl">

الخاصية dir هي اختصارٌ لكلمة «direction»، وضبط قيمتها إلى rtl تجعل نقطة البداية الأفقية لعناصر صفحة الويب من اليمين بدلًا من اليسار.
لكي تضع نمط CSS لعنصرٍ معيّن إذا كانت الصفحة RTL فقط:

1. أنشِئ نسخةً من أيّة أنماط CSS اعتيادية التي ستُطبَّق على العنصر الهدف.
2. أضف المُحدِّد html[dir="rtl"] قبل سلسلة المُحدِدات (selector chain).
3. كلما وجدت خاصيةً أو قيمة تُمثِّل التموضع الأفقي للعنصر، فاستعمل القاعدة المُعاكسة لها. على سبيل المثال، إذا وجدتَ float: left فبدِّلها إلى float: right.
   كمثالٍ عمليٍ على كلامنا السابق، إذا كان أحد أنماط CSS كالآتي:

.someClass {
    text-align: left;
    padding: 0 10px 0 0;
    text-decoration: underline;
}

فسنأخذ نسخةً منه ونحدِّثها كالآتي:

html[dir="rtl"] .someClass {
    text-align: right;
    padding: 0 0 0 10px;
}

لاحظ أننا حذفنا القاعدة text-decoration: underline;‎، فلسنا بحاجة إلى إعادة تعريف هذه القيمة لنسخة RTL لأنها لا تؤثر على اتجاه أي عنصر. وبالتالي ستُطبَّق القاعدة الأصلية.
هذا مثالٌ أكثر تفصيلًا. يمكنك أن تجربه مباشرةً على متصفحك.
شيفرة HTML:

<html dir="ltr">
  <body>
    <input type="button" id="directionSwitch" value="Switch LTR/RTL"/>
    <hr/>
    <div class="boxOne"></div>
    <div class="boxTwo"></div>
  </body>

</html>

شيفرة CSS:

.boxOne {
  width: 170px;
  height: 170px;
  background-color: #0072C6;
  margin: 0 0 0 20px;
}

.boxTwo {
  width: 120px;
  height: 120px;
  background-color: #C3191E;
  margin: 0 0 0 70px;
}

html[dir="rtl"] .boxOne {
  margin: 0 20px 0 0;
}

html[dir="rtl"] .boxTwo {
  margin: 0 70px 0 0;
}

شيفرة JavaScript:

document.getElementById('directionSwitch').addEventListener('click', function() {
  var docDirection = document.documentElement.dir;  
  var isRTL = (docDirection === 'rtl');
  document.documentElement.dir = isRTL ? 'ltr' : 'rtl';

});

لن تكون الحالات العملية بهذه البساطة؛ فهنالك تطبيقاتٌ فيها عددٌ كبيرٌ جدًا من قواعد CSS ومن المحددات، ولديك عدِّة استراتيجيات يمكنك اتباعها. وهذه إحداها:

1. انسخ القواعد واحذف ما ليس لازمًا: أولًا، انسخ محتوى صفحة الأنماط إلى ملفٍ آخر، وأضف html[dir="rtl"] إلى جميع القواعد، ثم احذف أيّة خاصيات لا تتعلق بالاتجاه الأفقي للعناصر. وسينتهي بك المطاف بملفٍ صغيرٍ هدفه هو التعامل مع اتجاه RTL فقط.
2. اقلب الاتجاهات: عدِّل كل الخاصية التي تُشير إلى اليسار (left) في الملف الجديد إلى معاكسها: أي padding-left ستصبح padding-right، و float: right ستصبح float: left …إلخ. لاحظ أنَّه إذا كان عندك خاصية padding-left في الملف الأصلي ثم عدَّلتها إلى padding-right فستبقى الخاصية الأصلية padding-left مطبقةً. لذا عليك إضافة الخاصية padding-left: unset بالإضافة إلى خاصية padding-right، وإلا فسيُطبِّق المتصفح كلا القاعدتين: خاصية padding-left من ملف CSS الأصلي وخاصية padding-right من الملف المعدَّل لاتجاه RTL. والأمر مشابهٌ لبقية الخاصيات مثل margin-left|right و border-left|right …
3. أعد لصق المحتويات في الملف الأصلي: بعد أن تنتهي من إكمال الخطوتين السابقتين، فالصق القواعد الجديدة في الملف الملف الأصلي بعد القواعد الأصلية. أفضِّل شخصيًا أن أضيف تعليقًا صغيرًا مثل /* **** RTL Content **** */ لكي أستطيع التفريق بسهولة بين الأنماط الأصلية والأنماط المُعدَّلة لاتجاه RTL.

طريقة أفضل: فصل أنماط RTL و LTR عن بعضهما

قد تواجه في بعض الأحيان حالاتٍ غريبة التي يحدث فيها تضاربٌ بين الأنماط. وهذا يتضمن وراثة قيم بعض الخاصيات من خاصياتٍ أخرى، مما يعني أنَّك في بعض الأحيان لا تعرف تمامًا ما هي القاعدة التي عليك تجاوزها. وربما أضفتَ margin-right إلى قواعد RTL لكنك لستَ متأكدًا ما هي القيمة التي عليك ضبطها إلى خاصية margin-left الأصلية.
أرى أنَّه من المستحسن أن تتبع منهجية أخرى، والتي هي أفضل في الحالات العملية لكنها أطول بعض الشّيء. سنفصل الخاصيات التابعة لكل اتجاه (RTL و LTR) عن بعضها بعضًا تمامًا. هذا مثالٌ عنها: لنقل أنَّنا لدينا قاعدة تتضمن ‎.wrapper .boxContainer .fancyBox كالآتية:

.wrapper .boxContainer .fancyBox {
    text-align: left;
    padding-left: 10px;
    text-decoration: underline;
    color: #4A8CF7;
}

بدلًا من إضافة خاصيات أخرى لاتجاه RTL فيها padding-left و padding-right، فيمكنك أن تكتب:

.wrapper .boxContainer .fancyBox {
    text-decoration: underline;
    color: #4A8CF7;
}

html[dir="ltr"] .wrapper .boxContainer .fancyBox {
    text-align: left;
    padding-left: 10px;
}

html[dir="rtl"] .wrapper .boxContainer .fancyBox {
    text-align: right;
    padding-right: 10px;
}

هذا الحل يتضمن ثلاثة أجزاء:

1. القاعدة (أو المُحدِّد) الأصلية وفيها خاصياتٌ ليست متعلقة بالاتجاه، لأنها مشتركة بين الاتجاهين RTL و LTR.
2. محدد يُعالج الاتجاه من اليسار إلى اليمين –html[dir="ltr"]– لا يوجد فيه سوى خاصيات لها علاقة بالاتجاه والتي تتوافق قيمها مع التخطيط (layout) الذي لديك لاتجاه LTR.
3. مُحدِّد يعالج الاتجاه من اليمين إلى اليسار –html[dir="rtl"]– بنفس خاصيات حالة LTR، لكن قيمها مضبوطة لكي تتوافق مع التخطيط الذي لديك لاتجاه RTL.
   لاحظ كيف أنَّ القاعدة الثانية تملك خاصية padding-left فقط، بينما القاعدة الثالثة تملك خاصية padding-right فقط. وهذا لأنَّ كل واحد منها خاصة بالاتجاه المُحدَّد في خاصية dir.
   هذه الطريقة جيدة وجميلة ويسهل التعامل معها، ولا تحتاج فيها إلى حذف قيم بعض الخاصيات (لاحظ أنَّ الكلمة المحجوزة unset غير مدعومة في جميع المتصفحات. لأكبر قدر من التوافقية، عليك أن تُعيد تعريف القيمة التي ترغب بها لأي خاصية تريد حذف قيمتها).

كيفية ضبط اتجاه الصفحة باستخدام JavaScript؟

هذا سهلٌ جدًا، ويتطلب سطرًا وحيدًا فقط: document.documentElement.dir
يمكنك طباعة هذه القيمة إلى console كما يلي:

var direction = document.documentElement.dir; console.log(direction);

أو تستطيع تجربة المثال الحي.
استعمل السطر الآتي لضبط اتجاه الصفحة: document.documentElement.dir = "rtl"
هذا مثالٌ متكاملٌ حول الحصول على قيمة اتجاه الصفحة وضبطها:
شيفرة HTML:

<html dir="ltr">
  <body>
    <input type="button" value="Set document direction to RTL" id="setDirection"/>
    <div id="directionStatus"></div>
  </body>
</html>

شيفرة JavaScript:

function getDirection() {
  var direction = document.documentElement.dir;
  document.getElementById('directionStatus').textContent = 'This document\'s direction is: ' + direction;
}
var dirButton = document.getElementById('setDirection');
dirButton.addEventListener('click', function(evt) {
  var isRTL = (document.documentElement.dir === 'rtl');
  document.documentElement.dir = isRTL ? 'ltr' : 'rtl';
  dirButton.value = isRTL ? 'Set document direction to RTL' : 'Set document direction to LTR';
  getDirection();
});

حلول مؤتمتة

تحدثنا بما فيه الكفاية عن الطرق اليدوية لقلب الاتجاه إلى RTL. لننظر الآن إلى بعض الحلول المؤتمتة.

css-flip

طوَّرت تويتر حلًا لأتمتة كامل العملية وجعل قلب الاتجاه إلى RTL أسهل للمشاريع الكبيرة. هذا المشروع مفتوح المصدر ويمكنك أن تجده على Github.
إضافة NPM هذه تغطي جميع الحالات التي قد تواجهها عندما تعمل على قلب الاتجاه إلى RTL، بما في ذلك الحالات الغريبة. بعض ميزاتها:

• no-flip: لإخبار مُحرِّك القلب أنَّك لا تريد أن تُقلَب هذه الخاصية وذلك بإضافة /* @noflip*/ في بداية الخاصية. على سبيل المثال، إذا كتبتَ ‎/* @noflip*/ float: left فستبقى الخاصية float: left عند تشغيل css-flip.
• replace: عندما تكون لديك صور خلفية تختلف بين RTL و LTR، فيمكنك أن تُحدِّد صورةً بديلةً بتضمين ‎/*@replace: url(my/image/path) */‎ قبل الخاصية الأصلية. فلنقل أنَّ لديك الخاصية background-image: url(arrow-left.png) وإذا حدثت السطر إلى ‎/*@replace: url(arrow-rightish.png) */ background-image: url(arrow-left.png);‎ فستصبح الخاصية النهائية في اتجاه RTL كالآتية: background-image: url(arrow-rightish.png);‎.

يمكنك استعمال css-flip عبر سطر الأوامر بتنفيذ css-flip path/to/file.css > path/to/file.rtl.css أو عبر تضمين css-flip في صفحتك. للمزيد من المعلومات راجع مستودع github. يجدر بالذكر أنَّ css-flip يُستعمَل في برمجيات تويتر.

rtlcss

أداةٌ أخرى لأتمتة العملية برمجها «محمد يونس» تدعى rtlcss التي تتوفر على github وتوفر ميزاتٍ رائعة. يمكنك باستخدام هذه الأداة أن:

• تعيد تسمية القواعد (مثلًا، إعادة تسمية ‎#boxLeft إلى ‎#boxRightSide).
• تتجاهل بعض القواعد من عملية القلب.
• تتجاهل خاصياتٍ معينة.
• تضيف قيمًا جديدة.
• تضيف قيم خاصيات جديدة بين قيم الخاصيات الأخرى.
  يمكنك استخدام هذه الأداة عبر سطر الأوامر؛ ويمكنك إنشاء ملف أنماط RTL بتنفيذ الأمر الآتي في نفس المجلد الذي يتوفر فيه ملف CSS الأصلي:

rtlcss input.css output.rtl.css

أو يمكنك أن تضمنه في صفحتك. للمزيد من المعلومات راجع صفحة المشروع على github.
هذا المشروع مشهور جدًا ويستعمل من عدِّة مشاريع بما فيها ووردبريس.

خاتمة

ما يزال هنالك الكثير لنغطيه، لكن هذه المقالة أمدتك بالمعلومات اللازمة لبدء مشوارك مع RTL. سنشرح في المقالة القادمة مواضيع متقدمة عن RTL.
إذا كانت لديك أيّة أسئلة حول RTL، فاطرحها في التعليقات.
ترجمة -وبتصرّف- للمقال Building RTL-Aware Web Apps & Websites: Part 1 لصاحبه أحمد نفزاوي

يوجد لدى كثيرين خلط بين مصطلحات متقاربة هي التعميّة Encryption، الترميز Encoding، التجزئة Hashing والتشويش Obfuscation. سيتناول هذا المقال ماهية كلّ واحد من هذه المصطلحات.

الترميز

يهدف الترميز إلى تحويل بياناتٍ ليصبح بإمكان أنظمة مختلفة التعامل معها بطريقة صحيحة وآمنة. على سبيل المثال: إرسال ملفات تنفيذية في بريد إلكتروني أو عرض محارف Characters خاصّة على صفحة ويب. ليس الغرض هنا إبقاءَ المعلومة سريّة بل التأكد من أن التعامل معها سيكون على النحو الأمثل.

يحوّل الترميز البيانات من صيغة إلى أخرى بآلية متاحة للعموم ويمكن بالتالي عكسُ التحويل بسهولة. لا تحتاج البيانات بعد ترميزها لمفتاح سري حتى يمكن التعامل معها، إذ أن المطلوب الوحيد ليمكنَ فك الترميز هو الخوارزمية Algorithm المستخدمة فيه.

أمثلة: ASCII ،Unicode، ترميز روابط URL و Base64.

التعمية

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

تحوّل التعميّة البيانات إلى صيغة أخرى لا يمكن سوى لأشخاص محدّدين فهمُها. يُستخدَم لتنفيذ التعمية مفتاح تعمية إضافة إلى خوارزمية والنص المراد تحويله. يتطلب نزعُ التعمية الحصولَ على النص المعمَّى، خوارزمية التعميّة والمفتاح السري (نفس مفتاح التعمية أو مفتاح سري آخر).

أمثلة: AES ،Blowfish و RSA.

التجزئة

تعمل التجزئة على التأكد من سلامة البيانات Integrity، بمعنى إن حدث تعديل عليها فستستطيع معرفة ذلك. تأخذ عمليّة التجزئة مُدخَلا عشوائيا وتُنتِج سلسلة محارف ثابتة الطول لديها الخصائص التالية:

• نحصُل دائما على نفس النتيجة بتنفيذ العمليّة على نفس المُدخَل.
• لا يجوز أن تُنتج العملية نفس المُخرَج لمُدخلات متعدّدة.
• يجب ألا يكون بالإمكان استنتاج المُدخَل من المُخرَج.
• يؤدي أي تعديل على مُدخَل مّا إلى تغييرات كبيرة في نتيجة تطبيق العملية عليه.

تُستخدَم التجزئة مع الاستيثاق Authentication للحصول على دليل قوي أن رسالة مّا لم يُعدَّل عليها. تتم العملية بأخذ مُدخَل معيَّن، تعميّته بمفتاح محدَّد، تجزئته بنفس المفتاح، ثم تعميّة المفتاح بالمفتاح العمومي Public key الخاص بالمرسَل إليه ثم توقيع التجزئة بالمفتاح السريّ الخاص بالمرسِل. يفتح المرسَل إليه الرسالة ثم يفكّ تعمية المفتاح المستخدَم لتعميّة الرسالة باستخدام مفتاحه السّري مما يمكّنه من الحصول على النص الأصلي للرسالة. يمكنها بعدها تجزئة الرسالة ومقارنة نتيجة التجزئة بالتجزئة الموقَّعة من المرسِل فإن حصل تطابق فهذا يعني أن الرسالة لم يُعدَّل عليها وأنها أرسلت من الشخص المُنتظَر.

أمثلة: SHA-3 و MD5 (أصبح قديما)

التشويش

يهدف التشويش إلى جعل المعلومة أصعب فهما، لتصعُب مهاجمتها أو نسخها. من الاستخدامات الشائعة له تشويش الشفرة المصدرية لجعل تكرار منتَج معيَّن أصعب عند تطبيق الهندسة العكسية Reverse engineering عليه.

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

يجب الانتباه أيضا إلى أنه يوجد حدّ للتشويش حسب المحتوى. عند تشويش شفرة برمجية مثلا فالحدّ هو أن نتيجة التشويش يجب أن تبقى في حدود ما يمكن للحاسوب التعامل معه وإلا فإن البرنامج سيتوقّف عن العمل.

أمثلة: مشوِّش JavaScript و ProGuard.

ملحوظة: ربما تتساءل متى يُستحسن استخدام التشويش بدلا من التعمية؛ والجواب هو أن التشويش يُستخدَم لجعل البيانات أصعب فهما على مستغِلّ محدَّد (شخص مّا) مع إبقائها في متناول مستغِلّ آخر (حاسوب). بالنسبة للتعميّة فيصعُب في جميع الأحوال الاستفادة من البيانات دون الحصول على المفتاح السّري.

خلاصة

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

ترجمة -وبتصرّف- لمقال Encoding vs. Encryption vs. Hashing vs. Obfuscation لصاحبه Daniel Miessler.

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

تنبيه: هذه هي طريقة ترخيص مشاريعي الخاصة، لكنني لست محاميًا وهذه المقالة لا تُمثِّل نصيحة قانونية.

ما هي الرخص؟

عدد الرخص التي يمكن اعتبارها "حرة" (free) أو مفتوحة المصدر (open-source) بالمئات! إذا كنت تريد قوائم طويلة، فراجع القوائم الموجودة على موقع مشروع GNU و opensoucre.org أو على ويكيبيديا، وحتى تلك القوائم الطويلة ليست شاملة لجميع الرخص.

وعلى الرغم من التعداد الكبير للرخص، لكن الفروقات بينها ليست محورية؛ والسبب وراء وجود عدد كبير منها هو أنَّ كاتبيها صعيبو المراس في اختيار الكلمات وبعض التفاصيل، لكن يمكن اعتبار شروط الكثير منها متماثلة. ادخل إلى موقع tl;drLegal لمراجعة سريعة لشروط مختلف الرخص.

الرخص المتساهلة و Copyleft

أكبر أمر يُفرِّق بين الرخص هو Copyleft، وهو مصطلحٌ أوجده مشروع غنو (GNU) لمنع الأشخاص الذين سيعيدون توزيع البرمجيات في المستقبل من تقييد الحريات التي أعطيتَها للمشروع عند إطلاقه، وهذا يعني أنَّه على أيّ شخصٍ يريد أن يُعيد توزيع نسخةٍ مُعدَّلةٍ من الشيفرة التي كتبتَها أن ينشر تعديلاته أيضًا.

تُطبِّق بعض الرخص ذاك المبدأ (مثل GPL، و LGPL، وMPL) بينما لا تُطبقه الأخرى (مثل MIT، و Apache، و BSD). قد تكون رخص "copyleft" مفيدةً جدًا لمنع إساءة استعمال مشروعك، وقد تكون في بعض الأحيان معيقةً لاستعماله من الشركات التي قد لا تقدر على استعمال شيفرات مرخصة بتلك الرخصة في برمجياتها التجارية.

مجال مشروعك

أحد أهم الأشياء التي يجب أخذها بعين الاعتبار عند اختيار رخصة لمشروعك هو "المجال"؛ هل هو مكتبة برمجية، أم أداة للمطورين، أم تطبيق كامل للمستخدم النهائي؟ إذا كان سيُستعمَل مع مكتباتٍ أخرى، فعليك أن تكون حذرًا في اختيارك للرخصة بسبب مشاكل في التوافقية بين الرخص (سنشرح ذلك بعد قليل).

أختارُ للتطبيقات الكاملة أو المنتجات، مثل تطبيقات الأندرويد أو تطبيقات سطح المكتب أو الأدوات التي تعمل من سطر الأوامر، رخصًا من نمط copyleft مثل GPLv3 التي تطمئنني أنَّ المشروع سيبقى مفتوح المصدر دومًا.

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

شخصيًا، أستعمل رخصًا متساهلة في هذه الحالة، مثل MIT أو BSD؛ وبينما تترك تلك الرخص احتمال أن تشتق الشركات مصدر المشروع الخاص بك، وتطوره ولا تعطيك التعديلات عليه، لكن ذلك غير عملي أو منطقي لكثيرٍ من الشركات؛ لأن الاختلاف من مصدر الشيفرة الأصلي سيجعلهم يتحملون عبء تكاليف الصيانة التي تتجاوز عادةً قيمة التّعديل الذي أجروه على شيفرة مشروعك.

رخصة LGPL ليست خيارًا سيئًا أيضًا، إذ تسمح للآخرين باستعمال نسخة مُصرَّفة (compiled) من المكتبة مع شيفراتهم المملوكة (proprietary أو الاحتكارية)، وفي نفس الوقت ستحافظ على حقوق مصدر المكتبة.

المشاكل في التوافقية

تحتوي بعض الرخص بنودًا تتعارض مع غيرها من الرخص؛ مما يجعلها غير متوافقة، مما يعني أنك لا تستطيع أن تدمج بين حزمتين برمجيتين أو مكتبتين مرخصتين برخصتين فيهما بنود متعارضة.

انظر إلى الحزم البرمجية التي تستعملها في مشروعك، وحاول أن تختار رخصةً لا تتعارض مع بنود تلك الحزم. هنالك مصادرٌ عدِّة تستطيع الحصول على معلومات توافقية الرخص منها، بما في ذلك ويكيبيديا. تؤثر عادةً المشاكل في التوافقية على الرخص المعقَّدة والمحدَّدة مثل GPLv3؛ فكلما ازداد طول الرخصة وتخصيصها للبنود، كما ازدادت احتمالية حدوث مشاكل في التوافقية.

تحقق من مجتمعك

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

على سبيل المثال، مجتمعَا JavaScript و Ruby يُحبذون الرخص الأكثر سماحيةً مثل MIT، بينما تُنشَر المشاريع المكتوبة بلغة C/C++‎ برخصة GPL.

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

بدون رخصة

إحصائيات الاستخدام التي نُشِرَت من Ben Balter على مدونة Github في مطلع عام 2015 تُظهِر أنَّ حوالي 80% من المستودعات على الموقع لا تُضمِّن رخصة؛ وهذا يعني أنَّ لا يُسمَح لأي شخص قانونيًا أن يستعمل الشيفرة الخاصة بهم حتى لو كانت متوفرة على الإنترنت لأنه لا يمكن اعتبارها "مفتوحة المصدر". هذا أمرٌ كارثي!

إن لم يكن هذا ما تطمح له، فخذ وقتك للتفكير برخصة مناسبة، وإلا فلن "يلمس" أي مبرمج خبير الشيفرة الخاصة بك، ويعرض سمعته للخطر بدعوى قضائية.

الخلاصة

هذه هي الطريقة التي أتبعها لاختيار رخصة لمشروعي. لا يوجد خيار صائب أو خيار خاطئ في اختيارك للرخصة إن كنت تعي ما تفعل. اختر واحدةً تناسب احتياجاتك، وتأكد أن تختار رخصةً واحدةً على الأقل.

ما هي الرخصة التي استعملتها لآخر مشروعٍ لك؟ أخبرنا في التعليقات.

ترجمة -وبتصرّف- للمقال How to pick an open source licence for your code لصاحبه Radek Pazdera.

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

تطوير سياسة تخزين مؤقت

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

1. مشاكل شائعة

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

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

2. توصيات عامة

على الرغم من أنّ الحالة هي التي تُملي علينا استراتيجيّة التخزين المؤقّت المُلائِمة، تستطيع التوصيات التالية إرشادنا نحو بعض القرارات المنطقيّة.

هناك بعض الخطوات التي نستطيع اتخاذها لزيادة نسبة استخدام التخزين المؤقّت 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.

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

أكاد أجزم أنك سمعت ورأيت تأثير parallax في عالم تصميم وتطوير المواقع، فقد أصبح هذا التأثير أحد أجمل التأثيرات وأكثرها استخدامًا، فهو يعطي للزائر تجربة مميزة وفريدة عندما يقوم بتصفح الموقع نزولًا وصعودًا (scroll up and down). في هذا الدرس سوف نستخدم عدد من إضافات jQuery الجاهزة لإنشاء هذا التأثير.

سنقوم في هذا الدرس بإنشاء موقع يحتوي على ستة أقسام، وكل قسم من هذه الأقسام يتمدد على كامل الصفحة، وسوف يحتوي كل قسم على موقع ما ومعلومات مبسطة عن الموقع.

تصفح النتيجة النهائية من هنا.

تصميم الموقع

قبل أن نبدأ بتكويد الموقع يجب علينا تصميمه باستخدام الفوتوشوب. يمكنك في الصورة بالأعلى رؤية محتويات كل قسم من الأقسام الستة، وبما أن تأثير parallex يعمل بشكل أفضل في التصاميم التي تغطي كامل الصفحة فسوف نستخدم صور صغيرة ونستخدمها كنمط متكرر (repeating pattern) في بعض الأقسام والبعض الآخر سوف يحتوي على خلفية بصورة كبيرة. وسوف يحتوي كل قسم على عنوان، شرح، صورة وزر.

ابدأ الآن باستخراج جميع الصور التي سوف تحتاجها لتصميم الموقع. وبما أنّ التصميم الذي نعمل عليه سيحتوي على الكثير من الصور فسوف نحاول الحصول على أقل حجم ممكن للصور، فبدلًا من استخدام الصيغة PNG-24 فسوف نستخدم صيغة PNG-8 للحصول على حجم أقل.

ذكرنا سابقًا بأننا سوف نستخدم صور صغيرة كنمط متكرر (repeating pattern) في بعض أقسام الموقع وذلك لأن هذه هي أسهلة طريقة للحصول على خلفية جميلة باستخدام صور ذات حجم صغير.

أمّا في الأقسام الأخرى من الموقع فسوف نستخدم صور كبيرة كخلفية. حاول أن تضغط الصور لتقليل حجمها ولكن احرص على أن تكون جودتها جيدة بعد ضغطها.

قم الآن بوضع كل الصور داخل مجلد ووضع الصور الخاصة بكل قسم في مجلد خاص بها وتسمية المجلدات بأسماء مناسبة.

بنية ملف HTML

يمكننا أن نبدأ الآن بتكويد الموقع وسوف نبدأ أولًا بكتابة أكواد HTML.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <title>My Sites</title>
  <link href="style.css" rel="stylesheet" />
</head>
<body>
  <ul class="curtains">
    <li>
      <section id="intro">
        <h1>My homes on the web</h1>
        <p>How’s it going? I'm Chris Spooner. I'm a creative Designer, avid Blogger and I'm generally crazy about pretty colours and shapes.</p>
        <p>Like most people who spend a lot of time on the Interwebs, […] a portal to all the places you can find my content on the web.</p>
        <p>Fancy visiting my homes on the net? Here you’ll find info and links to my best stuff.</p>
      </section>
    </li>
  </ul>
</body>
</html>

سوف ننشئ ملف HTML بسيط ونضيف له وسم <ul>، وسوف نستخدم لاحقًا في هذا الدرس إضافة اسمها curtains.js وهذه الإضافة تتطلب أن نعطي العنصر الأب (وسم <ul> في حالتنا هذه) class باسم curtains. لاحظ أيضًا أننا وضعنا جميع العناصر التي سوف تظهر في الصفحة داخل وسم <li>.

<li>
  <section id="spoon">
    <h2>Blog.SpoonGraphics</h2>
    <a href="http://blog.spoongraphics.co.uk" id="spoon-photo"><img src="images/spoon-photo.png" alt="Visit Blog.SpoonGraphics" /></a>
    <p>Blog.SpoonGraphics is my main design blog, […] head over there and have a browse. </p>
    <p class="btn"><a href="http://blog.spoongraphics.co.uk">Visit Blog.SpoonGraphics</a></p>
  </section>
</li>

قم الآن بإضافة عناصر كل قسم داخل عنصر <li> خاص به (ذكرنا سابقًا أن الموقع سيحتوي على ستة أقسام وبالتالي فسوف نحتاج إلى ستة عناصر من نوع <li>). ستكون إضافة IDs إلى بعض العناصر أمرًا جيدًا لأنّ ذلك سيسهل علينا تحديد تلك العناصر باستخدام jQuery وبالتالي إنشاء التأثير المطلوب.

<section id="cs">
  <h2>ChrisSpooner.com</h2>
  <p>I also post random content over on my ChrisSpooner.com personal blog. […] this is the place to go!</p>
  <ul>
    <li><a href="http://www.chrisspooner.com"><img src="images/cs-vid-1.jpg" alt="" /></a></li>
    <li><a href="http://www.chrisspooner.com"><img src="images/cs-vid-2.jpg" alt="" /></a></li>
    <li><a href="http://www.chrisspooner.com"><img src="images/cs-vid-3.jpg" alt="" /></a></li>
    <li><a href="http://www.chrisspooner.com"><img src="images/cs-vid-4.jpg" alt="" /></a></li>
    <li><a href="http://www.chrisspooner.com"><img src="images/cs-vid-5.jpg" alt="" /></a></li>
    <li><a href="http://www.chrisspooner.com"><img src="images/cs-vid-6.jpg" alt="" /></a></li>
  </ul>
</section>

كل العناصر التي ترغب بأن تكون جزءًا من التأثير ستحتاج إلى إضافتها على شكل عناصر منفردة بذاتها. فإذا نظرت إلى القسم الخامس ستلاحظ في أسفل الصفحة أن هناك ستة صور لمقاطع فيديو وكل صورة من هذه الصور موجودة في عنصر `<li>` لوحده (أنظر إلى الكود في الأعلى).

إضافة تنسيقات CSS

يمكننا الآن إضافة تنسيقات CSS إلى الموقع.

body {
  font: 18px/30px Sans-serif; color: #fff;
}

section {
  overflow: hidden; height: 993px;
}

سنبدأ أولًا بإضافة تنسيقات CSS تخص الخطوط (نوع الخط المستعمل وحجمه وهكذا) ليتم تطبيقها على الموقع، وسوف نعطي الخاصية overflow: hidden للعناصر <section> وذلك حتى لا يظهر أي أشرطة تمرير أفقية (horizontal scrollbars) في المتصفح. لاحظ أيضًا أننا أعطينا ارتفاع ثابت بقيمة 993px لجميع عناصر <section> حتى يتساوى ارتفاع جميع الأقسام.

#intro {
  background: #c3c2c1 url(images/intro-bg.jpg) left no-repeat;
}

#intro h1 {
  width: 858px; height: 161px;
  background: url(images/intro-title.png); text-indent: -9999px;
  position: relative; top: 145px; left: 0;
}

#intro p {
  position: relative; top: 200px; left: 350px;
  width: 508px; margin: 0 0 30px 0;
}

#intro p:nth-child(2) {
  font-weight: bold;
}

لاحظ أننا أعطينا خاصية background لعناصر h1 لاستبدال النصوص بالصور لتتناسب مع تصميم الموقع، كما أننا استعملنا الخصائص `position: relative`، `top` و`left` لموضعة النصوص في أماكنها الصحيحة.

#gaming {
  background: #28323c url(images/gaming-bg.jpg);
  background-size: cover;
}

#gaming h2 {
  width: 740px; height: 324px;
  background: url(images/gaming-title.png); text-indent: -9999px;
  position: relative; top: 87px; left: 90px;
}

#gaming p {
  position: relative; top: 110px; left: 100px;
}

#gaming .btn a {
  display: block; width: 728px; height: 176px;
  background: url(images/gaming-link.png); text-indent: -9999px;
  position: relative; top: 70px;
}

يمكننا القول أنّ هناك تشابه في تنسيقات CSS لجميع العناصر مع وجود بعض الاختلافات في أماكن وجود العناصر. ففي الأقسام السابقة استعملنا صورة خلفية مكررة، أمّا في الأقسام التالية فقد استعملنا صورة خلفية كبيرة واستخدمنا أيضًا الخاصية `background-size: cover` حتى نجعل الخلفية تتجاوب مع الأبعاد المختلفة للمتصفحات.

cs ul li {
  float: left; box-shadow: 0 0 20px rgba(0,0,0,0.5); line-height: 0;
  position: absolute; list-style: none;
}

#cs ul li:nth-child(1) {
  top: 640px; left: 100px;
  transform: rotate(10deg);
  -moz-transform: rotate(10deg);
  -webkit-transform: rotate(10deg);
  z-index: 1;
}

#cs ul li:nth-child(2) {
  top: 600px; left: 420px;
  transform: rotate(-5deg);
  -moz-transform: rotate(-5deg);
  -webkit-transform: rotate(-5deg);
  z-index: 3;
}

#cs ul li:nth-child(3) {
  top: 680px; left: 570px;
  transform: rotate(-2deg);
  -moz-transform: rotate(-2deg);
  -webkit-transform: rotate(-2deg);
  z-index: 2;
}

بالنسبة لصور مقاطع الفيديو الموجودة في القسم الخامس، فقد قمنا باستخدام ()transform: rotate وz-index حتى نُظهرها بالشكل الذي تراه. كما أننا استعملنا المحدد ()nth-child: لتسهيل عميلة تحديد العناصر المتتابعة من دون الحاجة إلى إعطاء class لكل عنصر.

انتهينا الآن من إضافة تنسيقات CSS وبقي علينا استخدام إضافات jQuery ليعمل كل شيء كما هو مطلوب.

إضافة بعض أكواد jQuery

حتى نحصل على التأثير المطلوب فإننا سنقوم باستخدام إضافتين جاهزتين وهما Curtain.js وScrollorama.

<link href="js/curtain.css" rel="stylesheet" />

<script src="http://code.jquery.com/jquery-1.8.2.min.js"></script>
<script src="js/curtain.js"></script>
<script src="js/jquery.scrollorama.js"></script>
<script src="js/scripts.js"></script>

سنحتاج في البداية إلى ربط مكتبة jQuery وهاتين الإضافتين بملف HTML الخاص بالموقع. قم بتحميل الإضافتين ووضعهما داخل وسم `<script>`، قم أيضًا بإنشاء ملف باسم scripts.js وقم بوضعه داخل وسم `<script>` لأننا سنحتاج هذا الملف في إضافة التأثيرات الخاصة بالإضافتين. لا تنسى أيضًا إضافة تنسيقات CSS التي تأتي مع إضافة Curtain.js.

$(document).ready(function(){
    $('.curtains').curtain();
});

أول سطر برمجي عليك أن تضعه في ملف scripts.js هو المسؤول عن تشغيل إضافة Curtain.js. سنقوم بتحديد العنصر curtains. (وهو نفس الوسم `<ul>` الذي أضفناه في ملف HTML). ستقوم عندها الإضافة بإظهار القسم المناسب عندما يقوم المستخدم بالتمرير إلى أسفل الصفحة (scroll down).

$(document).ready(function(){
  $('.curtains').curtain();
  var scrollorama = $.scrollorama({
    blocks:'.curtains'
  });

  scrollorama.animate('#intro h1',{
    duration:200, property:'left', end:-860
  });
});

وبالنسبة للإضافة الثانية (Scrollorama)، فإنها توفر تأثيرات تمرير أكثر. تحتاج اولًا إلى تطبيق الإضافة على نفس العنصر كما فعلنا مع الإضافة السابقة، يمكنك بعد ذلك أن تستخدمها لإنشاء تأثيرات التمرير لكل عنصر على حدة. وأول هذه العناصر هو `#intro h1`، بحيث نختار الخاصية التي نريدها (`left` في هذه الحالة) ومن ثم تغيير قيمة بداية أو نهاية التأثير الحركي. لاحظ أننا قمنا بإزاحة العنوان (h1) بقيمة 890 pixels إلى اليسار عند التمرير بمقدار 200 pixels.

scrollorama.animate('#spoon-photo',{
  delay:993, duration:993, property:'top', start:100, end:-300
});

المثال التالي يخص القسم الثاني من الموقع وبالأخص الصورة الموجودة على اليمين، بحيث نقوم بتحديد هذه الصورة وتحركيها بشكل مستقل عن محتوى الصفحة مما يخلق تأثير parallax جميل. وحتى نضمن أن التأثير لن يبدأ إلا عندما يصل الزائر إلى القسم الثاني فسوف نقوم بتأخير العملية بمقدار 993 pixles وهو الارتفاع الخاص بكل قسم، وبهذا فإن التأثير سوف يبدأ عندما يختفي القسم الأول بالكامل.

scrollorama.animate('#line25-photo',{
  delay:993, duration:1986, property:'rotate', start:-10, end:10
});

scrollorama.animate('#gaming .btn',{
  delay:2000, duration:993, property:'left', start:-800, easing:'easeOutBounce'
});

أي خاصية CSS ذات قيمة عددية يمكن إعطاؤها تأثيرات حركية. ففي هذين المثال تمّ تدوير الصورة الموجودة في القسم الثالث وتحريك الزر الموجود في القسم الرابع. بالنسبة لقيمة `duration: 1986` فهي ضعف الارتفاع الخاص بالاقسام (993px) ولقد استخدمت حتى يعمل التأثير الحركي حتى بعد أن يختفي القسم الثالث عن الأنظار، بينما استعملنا القيمة `duration: 993` لأننا نريد أن يتوقف التأثير عندما يختفي القسم الرابع عن الأنظار ويبدأ القسم الخامس.

scrollorama.animate('#cs ul li:nth-child(1)',{
  delay:2979, duration:993, property:'top', start:840, end: 640
});

scrollorama.animate('#cs ul li:nth-child(2)',{
  delay:2979, duration:993, property:'top', start:800, end: 640
});

scrollorama.animate('#cs ul li:nth-child(3)',{
  delay:2979, duration:993, property:'top', start:920, end: 580
});

scrollorama.animate('#cs ul li:nth-child(4)',{
  delay:2979, duration:993, property:'top', start:880, end: 620
});

scrollorama.animate('#cs ul li:nth-child(5)',{
  delay:2979, duration:993, property:'top', start:830, end: 660
});

scrollorama.animate('#cs ul li:nth-child(6)',{
  delay:2979, duration:993, property:'top', start:960, end: 600
});

قمنا بإعطاء جميع صور الفيديو في القسم الخامس تأثيرًا حركيًا للخاصية `top` وبتأخير (delay) مقداره 2979px (3*993=2979 وهو ارتفاع ثلاثة أقسام لأننا نحتاج إلى تمرير ثلاثة أقسام قبل أن يظهر هذا القسم). ومع استعمال قيم `start` و`end` مختلفة يمكننا إنشاء تأثير parallax جميل بحيث تتحرك بعض الصور أسرع من الأخرى، وكل هذا يحدث في حين تقوم إضافة Curtain.js بإظهار القسم.

جعل الموقع يعمل عندما تكون الجافاسكربت معطلة

إذا كنت تريد أن يعمل الموقع في حالة وجود الجافاسكربت معطل فإنك سوف تحتاج إلى الدخول على ملف curtain.css والبحث عن السطر التالي:

.curtains > li{
  position: fixed;
}

واجعله كالتالي:

.curtains > li{
  /*position: fixed;*/
}

سوف يسمح هذا للموقع أن يعمل حتى لو كان الجافاسكربت معطل.

وبما أنّ غالبية الزوار لديهم الجافاسكربت مفعّل، فسوف تحتاج إلى الكود التالي حتى نستعيد التأثير لهؤلاء الزوار:

$('.curtains>li').css('position', 'fixed');

خاتمة

كما رأيت فتصميم موقع بتأثيرات scrolling وparallax ليس بالأمر الصعب، فيمكن لإضافة Curtain.js لوحدها أن تعطينا تأثيرًا جميلًا ولكن إضافة التأثيرات الحركية واستخدام إضافة Scrollorama جعل الأمر أكثر جمالًا.

تصفّح النتيجة النهائية من هنا.

ترجمة -وبتصرّف- للمقال Create a Cool Website with Fancy Scrolling Effects لصاحبه Iggy.

حقوق الصورة البارزة: Designed by Freepik.

SSE اختصار لـ Server Sent Events وتسمى أيضًا EventSource تُستخدم لِبنّاء تطبيقات ويب تفاعلية. حيث يُرسل الخادوم أحداثا في الوقت الحقيقي إلى المستخدم، قد يتضمن الحدث تنبيهات للمستخدم أو بيانات يمكن استغلالها في عمل شيء ما وتحديث صفحة الويب.

في السّابق، لِعمل تحديث تلقائي للبيانات كل ثانية كانت تُستَخدم هذه الطريقة:

setInterval(function(){ // إستدعاء الدالة بشكل تكراري
    xhr = new XMLHttpRequest(); // إستخدام طلب ajax
    xhr.onreadystatechange = function(){// عند أي تغير في حالة الطلب
        if(this.readyState == 4){// تم إستقبال النص بنجاح
            // إفعل بعض الاوامر
        }
    }
    xhr.open("get","http://localhost"); // تحديد نوع الطلب ورابط الموقع
    xhr.send("mydata"); // إرسال البيانات إلى الخادم
}, 1000); // تحديد مدّة التكرار إلى ثانية

أو هذه الطريقة الأكثر تطورًا:

function getAjax(){ // تعريف الدالة التي ستدعى بشكل تكراري
    xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function(){
        if(this.readyState == 4)
            setTimeout(function(){ // استدعاء ألدالة مجددًا بعد ثانية من الإنتهاء لِتكرار طلب الajax
                getAjax();
            },1000);
    }
    xhr.open("get","http://localhost");
    xhr.send("mydata");
}
getAjax();// إستدعاء الدالة للمرة الأولى

هذه الطرق صحيحة لكنها ليست الأفضل، حيث تقوم بإرسال طلب كل ثانية للخادم مما يُسبٍّب ضغط عليه وغالبًا لا يكون التحديث في الوقت الحقيقي لظهوره. فكرة عمل SSE أن الطلب يظل مَفتوحا في إنتظار محتوى جديد والخادم هو من يُرسل المحتوى الجديد وليس المتصفح من يطلبه.

SSE ليست الطريقة الوحيدة لِبناء تطبيقات ويب تفاعلية، يوجد العديد من الطرق الأخرى من أشهرها WebSocket.

مُقارنة بين SSE و WebSocket

السهولة والتوافقية

معظم الإستضافات المشتركة لا تَدعم WebSocket وهو يعمل على بروتوكل ws أو wss (في حالة إستخدام شهادة أمان ssl) وهما مختلفان عن الذي عليه واجهة المستخدم مما يُسبِّب مشاكل في مصادفة الاثنين معًا (يوجد مكتبات لفعل ذلك) على خلاف SSE التي تُعتبر طلب عادي على نفس بروتوكول واجهة المستخدم النهائية.

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

WebSocket يُمكنها عمل تزامن بين المستخدمين بطريقة مباشرة حيث أن الإتصلات تُعالج كلها معًا. في SSE لايوجد طريقة مباشرة لِتزامن المسخدمين معًا لأن كل طلب مُنفصل عن الآخر لذا تُستخدم قاعدة بيانات وتحفظ أخر التغيرات للمستخدم الأول وعند المستخدم الآخر يَتم البحث بشكل دوري عن التغيرات في قاعدة البيانات ثم إرسالها إلى المستخدم الآخر.

إرسال وإستقبال البيانات

WebSocket و SSE يدعمان إستقبال البيانات لكن لا يُمكن إرسال البيانات إلى الخادم بإستخدام SSE، أي عند بناء تطبيق يعتمد على إرسال وإستقبال البيانات من الخادوم ستضطر إلى بناء صفحة منفصلة تقوم بإستقبال الطلبات من المستخدم بواسطة ajax مثلًا.

تطبيقات قد يكون إستخدام WebSocket فيها أفضل

• في تطبيق سيحتاج إلى تفاعل المستخدمين معًا (تطبيق تواصل مثلًا) سيكون إستخدام WebSocket أفضل من SSE لأن الأخيرة لا يُمكنها إستقبال الطلبات من الخادوم.
• إرسال إشعارات أو رسائل للمستخدم أو أي تطبيق لن يَحتاج المستخدم فيه إلى إرسال رسائل إلى الخادوم. هنا ممكن أن يكون إستخدام SSE أفضل وأسهل.

اهلًا بالعالم

قبل البدء يجب أن تَعرف المتصفحات الداعمة لـِ SSE وأن متصفح أنترنت أكسبلور لايَدعمه لكن يُمكنك إستخدام مكتبة خارجية لدعمه مثل EventSource.js (يتم تضمين ملف javascript في الصفحة) هذا مثال لنص مصدري لإستجابة طلب SSE:

http/1.1 200 OK ## الصفحة موجودة !
Content-Type: text/event-stream  ## تعريف المتصفح أن الصفحة هي محتوى لطلب SSE

event: delete## تعريف الحدث الذي سيُستقبل من javascript
data: "some data" ## البيانات التي سترسل إلى الحدث

event: add## تعريف حدث آخر
data: "some data"

data: "some data"## إرسال بيانات بدون حدث مُعرف
id: 3 ## غير مهم وغير مطلوب بشكل ضروري يُستخدم لتحديد مُعرف lastEventId للرسائل

الأمثلة مكتوبة بلغة php ويُمكنك فعلها في أي لغة ويب أخرى هذا تطبيق بسيط لجلب الساعة من الخادم لحظة بلحظة. ملف server.php ( الذي سيعالج طلبات SSE احفظه بجوار واجهة المستخدم أو أي مكان آخر مع تغير المسار في شفرة javascript ):

<?php
    set_time_limit(0);// تحديد أقصى مدة للطلب غير نهائية لان هناك خوادم تقوم بتحديدها
    $time = 1;// متغير بقيمة الوقت الذي سيرسل فيه تحديث جديد
    header("Content-Type: text/event-stream");// إرسال ترويسة أن الصفحة هي محتوى sse
    header('Cache-Control: no-cache'); // لمنع حفظ الكاش للصفحة
    while(true){// تكرار
        /*
            date("s-i-h") تُخرج الوقت على التَنسيق ساعة-دقيقة-ثانية
            PHP_EOL تعني سطر جديد يُمكن إستخدام \n لكن سَتختلف من نظام تَشغيل الى آخر
        */
        echo "data: ".date("s-i-h").PHP_EOL;
        echo PHP_EOL; // كتابة نص جديد آخر للتفريق بين التنبيهات

        // إرسال المحتوى الذي كتب دون الإنتظار إلى انتهاء الصفحة
        ob_flush();
        flush();

        // إيقاف الاسكربت إلى المدة التي تم تعريفها في المتغير time لمدة ثانية أن لم تَقف الاسكربت سَيعمل بدون توقف 
        sleep($time);
    }
?>

إن فتحت الصفحة ستجد أنها تقوم بإرسال الساعة الحالية كل ثانية. 

الآن الواجهة التي ستتعامل معها:

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="utf-8">
    </head>
    <body style="direction: rtl">
        <label>الساعة الآن : <span>.......</span></label>
        <script type="text/javascript">
            if(!EventSource)
                alert("مٌتصفحك لايَدعم SSE :(");
            else{
                SSE = new EventSource("server.php"); // انشاء الطلب
                SSE.onmessage = function(ms){ // عند وجود رسالة جديدة
                    document.querySelector("span").innerHTML = ms.data;// استبدال النص بالجديد
                }
                SSE.onerror = function(){//عند وجود خطأ
                    alert("يوجد خطأ في الاتصال ...");
                    mkcon(); // إعادة الطلب
                }
            }
        </script>
    </body>
</html>

الأحداث وطرق انشاءها

يُمكن في SSE إنشاء أحداث مخصصة لكي تَكون الشفرة أكثر ذكاءا، مثلًا إرسال حدث لحذف عنصر وحدث لإنشاء عنصر آخر.

مثال: تعريف مصفوفة بإسم الألوان أحمر أخضر أزرق.

$colors = array("red", "green", "blue");

ثم تعريف اسم الحدث بإسم عشوائي من هذه الألوان:

$colors[rand(0,2)];

ليكون النص الكامل لملف server.php:

<?php
    set_time_limit(0);// تحديد أقصى مدة للطلب غير نهائية لان هناك خوادم تقوم بتحديدها
    $time = 1;// متغير بقيمة الوقت الذي سيرسل فيه تحديث جديد
    header("Content-Type: text/event-stream");// إرسال ترويسة أن الصفحة هي محتوى sse
    $colors = array( // مصفوفة الألوان من النوع الرقمي
        "red",
        "green",
        "blue"
    );
    while(true){// تكرار
        /*
            date("s-i-h") تُخرج الوقت على التَنسيق ساعة-دقيقة-ثانية
            PHP_EOL تعني سطر جديد يُمكن إستخدام \n لكن سَتختلف من نظام تَشغيل إلى آخر
        */
        echo "data: ".date("s-i-h").PHP_EOL;
        echo "event: ".
            $colors[rand(0,2)] // توليد لون عشوائي بإسم الحدث
        .PHP_EOL;
        echo PHP_EOL; // كتابة نص جديد آخر للتفريق بين التنبيهات

        // إرسال المحتوى وعدم الإنتظار إلى إكتمال الطلب إلى النهاية
        ob_flush();
        flush();

        // إيقاف الاسكربت إلى المدة التي تم تعريفها في المتغير time لمدة ثانية أن لم تَقف الاسكربت سَيعمل بدون توقف 
        sleep($time);
    }
?>

وفي واجهة المستخدم إنشاء بعض العناوين:

<style>
.red{
    color: red
}
.blue{
    color: blue
}
.green{
    color: green
}
</style>
<label class="red">
    .......
</label>
<label class="green">
    .......
</label>
<label class="blue">
    .......
</label>

الآن إستقبال الأحداث:

SSE.addEventListener("red",function(ms){ //اللّون الأحمر red اسم الحدث الذي عرف من php
    document.querySelector(".red").innerHTML = ms.data;
});

لتصبح شفرة الواجهة الكاملة:

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="utf-8">
        <style>
            .red{
                color: red
            }
            .blue{
                color: blue
            }
            .green{
                color: green
            }
        </style>
    </head>
    <body>
        <label class="red">
            .......
        </label>
        <label class="green">
            .......
        </label>
        <label class="blue">
            .......
        </label>
        <script type="text/javascript">
            if(!EventSource)
                alert("مٌتصفحك لايَدعم SSE :(");
            else{
                function mkcon(){
                    SSE = new EventSource("server.php"); // إنشاء الطلب
                    SSE.addEventListener("red",function(ms){ //اللون الأحمر
                        document.querySelector(".red").innerHTML = ms.data;
                    });
                    SSE.addEventListener("green",function(ms){ //اللون الأخضر
                        document.querySelector(".green").innerHTML = ms.data;
                    });
                    SSE.addEventListener("blue",function(ms){ //اللون الأزرق
                        document.querySelector(".blue").innerHTML = ms.data;
                    });
                    SSE.onerror = function(){//عند وجود خطأ
                        alert("يوجد خطأ في الاتصال ...");
                        mkcon(); // اعادة الطلب
                    }
                }
                mkcon();
            }
        </script>
    </body>
</html>

ستجد أن أحدى الساعات من الثلاثة تزيد بشكل عشوائي كل ثانية لكن بالطبع هذا مثال، لن تقوم بإستخدام هذه التقنية في هذا.

إستخدام بيانات json

إن أردت إرسال مقال بإستخدام SSE فستحتاج إلى إرسال العنوان والمحتوى ولن تُرسل حدثين لذلك يُمكنك إستخدام json كما يلي:

{
    "title": "العنوان",
    "content": "المحتوى"
}

اذًا سَترسل هذه البيانات:

data: {"title": "ألعنوان","content":"ألمحتوى"}

ثم سيكون إستقبال البيانات من خلال javascript بهذا الشكل:

SSE.onmessage = function(ms){
    var JsonData = JSON.parse(ms.data); // قراءة نص json
    alert(JsonData.title + "\n" + JsonData.content);
}

مثال عملي عن إرسال بيانات json بتوقيت السيرفر المحلي:

ملف server.php

<?php
    set_time_limit(0);//تُحدد أقصى مدة للطلب غير نهائية لان هناك خوادم تقوم بتحديدها
    $time = 1;// متغير بقيمة الوقت الذي سيرسل فيه تحديث جديد
    header("Content-Type: text/event-stream");// إرسال ترويسة أن الصفحة هي محتوى sse

    while(true){// تكرار
        /*
            date("s-i-h") تُخرج الوقت على التَنسيق ساعة-دقيقة-ثانية
            PHP_EOL تعني سطر جديد يُمكن إستخدام \n لكن سَتختلف من نظام تَشغيل الى آخر
        */
        echo 'data: '.
            /**
                مصفوفة بالوقت.
                دالة json_encode تقوم بتحويل البيانات الى ترميز json
            */
            json_encode(array(
                "hour" => date("h"), // الساعة
                "minute" => date("i"), // الدقيقة
                "second" => date("s") // الثانية
            ))
        .PHP_EOL;
        echo PHP_EOL; // كتابة نص جديد آخر للتفريق بين التنبيهات

        // إرسال المحتوى وعدم الإنتظار إلى إكتمال الطلب إلى النهاية
        ob_flush();
        flush();

        // إيقاف الاسكربت إلى المدة التي تم تعريفها في ألمتغير time لمدة ثانية ان لم تَقف الاسكربت سَيعمل بدون توقف 
        sleep($time);
    }
?>

وملف الواجهة:

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="utf-8">
    </head>
    <body style="direction: rtl">
        <p>الساعة الآن <b id="hour">0</b> و <b id="minute">0</b> دقيقة و <b id="second">0</b> ثانية.</p>
        <script type="text/javascript">
            if(!EventSource)
                alert("مٌتصفحك لايَدعم SSE :(");
            else{
                function mkcon(){
                    SSE = new EventSource("server.php"); // إنشاء الطلب
                    SSE.onmessage = function(ms){
                        var JsonData = JSON.parse(ms.data); // قراءة نص json
                        document.querySelector("#hour").innerHTML = JsonData.hour; // إستبدال الساعة
                        document.querySelector("#minute").innerHTML = JsonData.minute;// إستبدال الدقائق
                        document.querySelector("#second").innerHTML = JsonData.second;// إستبدال الثواني
                    }
                    SSE.onerror = function(){//عند وجود خطأ
                        alert("يوجد خطأ في الاتصال ...");
                        mkcon(); // إعادة الطلب
                    }
                }
                mkcon();
            }
        </script>
    </body>
</html>

في هذا المثال والذي سبقه لن تَحتاج إلى إستحدام SSE ويمكن عَمل ذلك بإستخدام javascript بسهولة.

تطبيق على ما شُرح: بناء تطبيق تواصل

لم تُستخدم قاعدة بيانات لتسهيل تشغيل السكربت (لكن بالطبع إستخدام قاعدة بيانات أفضل) سيولد لون لكل مستخدم وسيحفظ في cookies للتعرف عليه في الرسائل، ستحفظ البيانات في ملف ChatData.json على هذا الشكل (كان يُمكن إستخدام قاعدة بيانات sqlite):

[// مصفوفة الرسائل
    {
        "author": "rgb(54,48,98)", // لون السمتخدم
        "message": "رسالة",
    },
    {
        "author": "rgb(54,48,98)", // لون السمتخدم
        "message": "رسالة 2",
    }// ....,...,..
]

تصميم الواجهة

هذه هيكلة الصفحة:

<!DOCTYPE html>
<html>
    <head>
    <meta charset="utf-8">
    <title>تجربة</title>
    <meta name="viewport" content="width=device-width">
    </head>
    <body>
        <div class="messages">
        </div>
        <div class="form">
            <div class="author me"></div>
            <textarea placeholder="كتابة رسالة"></textarea>
            <button id="send">أرسل</button>
        </div>
    </body>
</html>

إضافة الحيوية للصفحة:

body,html{
    width: 100%;/** جعل عرض الصفحة بكامل الشاشة **/
    direction: rtl;
    height: 100%;
    background: #f0f0f0;/** لون الخلفية **/
    padding: 0;
    margin: 0
}
/** جعل حجم بعض العناصر يحسب بالحواشي الخارجة **/
.messages,
.messages > .message,
.message > .content,
.form,
.form > textarea{
    box-sizing: border-box
}
/** الرسائل **/
.messages{
    padding: 40px; /** عمل فراغ بقيمة 40px من كل جهة **/
    height: 80%;
    overflow-y: auto/** جعل الرسائل الزائدة تتحول الى اسكرول **/
}
/** عناصر لن تكون بكامل عرض الحافظة **/
.message > .author,
.message > .content{
    display: inline-block;/** لن يأخذ العنصر كامل العرض **/
    vertical-align: top /** العنصر سيكون في محاذة الأعلى **/
}
/** هوية المستخدم **/
.message > .author{
    width: 64px;
    height: 64px;
    background: #ddd; /** اللون الافتراضي سيغير بعد ذلك **/
    border-radius: 100% /** تدوير العنصر **/
}
/** جسم الرسالة **/
.message > .content{
    background: white;
    box-shadow: 0 0 1px #ccc; /** تأثير الظل **/
    padding: 20px;
    margin-right: 30px;
    /** لجعل الصفحة أكثر إستجابة على الشاشات المختلفة **/
    width: 100%;
    max-width: 550px 
}
/** عناصرالتحكم لإرسال رسالة **/
.form{
    padding: 10px;
    height: 20%
}
/** صندوق النصوص **/
.form > textarea{
      width: 100%;
      max-width: 678px;
      height: 100%
}
/** زر الإرسال **/
.form > button{
    background: rgb(31, 158, 238);
    padding: 4px 20px;
    border: 0;
    cursor: pointer; /** مؤشر الفارة **/
    color: white;
    border-radius: 3px /** عمل بعض الحواف **/
}
.form > button:active{
    background: rgb(31, 158, 200) 
}
/** تصميم الجوال إصلاح بعض العلل **/
@media screen and (max-width:640px){
    .messages{
        padding: 0
    }
    .message > .content{
        margin: 0;
        margin-bottom: 20px
    }
}

إستقبال الرسائل

SEE لاتدعم إرسال البيانات إلى الخادوم لذا سَتستخدم ajax لذلك. هذه شفرة بسيطة لإرسال الرسائل إلى الخادوم (يُضاف بين الوسم script في أخر الصفحة قبل </body> أو إن كنت ستضيفه الى head، يجب أن يكون في دالة:

window.onload = function(){
   //هنا
}; 

document.querySelector("#send").addEventListener("click",function(){// عند الضغط على زر إرسال
    var mss = document.querySelector(".form > textarea").value; // محتوى الرسالة
    if(mss && mss.length){// التأكد من أن الرسالة مكتوبة
        var ajax = new XMLHttpRequest();
        ajax.onreadystatechange = function(){
            if(this.readyState == 4)
                alert("تم إرسال الرسالة");
        }
        ajax.open("get","server.php"); // نوع الطلب ومسار الإرسال
        ajax.send("?ms="+mss);// إرسال الرسالة
    }
});

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

messagesList = []; // مصفوفة بالرسائل
InProgress = false;// يوجد طلب يُعالج أم لا
function sendFirstMessage(){
    if(!messagesList.length || InProgress) // لايوجد رسائل أو هناك رسالة تُعالج
        return false;
    var ajax = new XMLHttpRequest();
    ajax.onreadystatechange = function(){ // الرسالة ارسلت
        if(this.readyState == 4){
            messagesList.splice(0, 1);// حذف الرسالة المرسلة اول رسالة
            InProgress = false; // تم الإنتهاء من العمل
            sendFirstMessage(); // إرسال الرسالة الأخرى
        }
    }
    ajax.onerror = function(){
        alert("خطأ في الإتصال جاري المحاولة مجددًا");
        sendFirstMessage();
    }
    InProgress = true;
    ajax.open("get","send.php?message="+messagesList[0]); // نوع الطلب ومسار الإرسال
    ajax.send();// إرسال الرسالة
}
document.querySelector("#send").addEventListener("click",function(){// عند الضغط على زر إرسال
    var mss = document.querySelector(".form > textarea").value; // محتوى الرسالة
    if(mss && mss.length){// التأكد من أن هناك رسالة مكتوبة
        messagesList.push(mss); // إضافة رسالة إلى المصفوفة
        sendFirstMessage(); // إرسال الرسالة الأولى
        document.querySelector(".form > textarea").value = "";// افراغ حقل إرسال الرسائل
    }
});

ملف الخادوم الذي سيستقبل الرسائل، لن تكتب [] في الملف لتسهيل الكتابة في نهايته دون قِرائته:

ملف send.php (الذي سيستقبل الرسائل)

<?php
    if(empty($_GET["message"]))
      die();
    /* التأكد من المستخدم */
    if(!isset($_COOKIE["author"]) || !preg_match("/^rgb\([0-9]{0,3}\,[0-9]{0,3}\,[0-9]{0,3}\)$/i",$_COOKIE["author"])){
      // توليد لون عشوائي أن لم يُعرف من قبل
      $R = rand(0,250); // اللّون الأحر
      $G = rand(0,250); // اللّون الأخضر        
      $B = rand(0,250); // اللّون الأزرق        
      setcookie("author","rgb($R,$G,$B)"); // نمط الألوان rgb
    }
    $message = str_replace(array("<",">"),array("&lt;","&gt;"),$_GET["message"]); // الوقاية من ثغرة xss
    $data = array( // البيانات التي ستكتب
        "content" => $message,
        "author" => $_COOKIE["author"]
    );
    $FILE = fopen("./ChatData.json","a"); //فتح الملف للكتابة فيه
    $star = (!filesize("./ChatData.json")) ? "" :",";// إضافة فاصلة أن تم الكتابة بالملف من قبل
    fwrite($FILE,$star.json_encode($data)); // كتابة بيانات json في الملف
    fclose($FILE);
?>

ملاحظة: سبب إستخدام الألوان هو لكي تتمكن من التعامل مع المستخدمين وحفظ البيانات في قاعدة البيانات للمستخدم.

ملف server.php (الذي سيراقب تغير الملف ويرسل التحديث)

<?php
    set_time_limit(0); // لايوجد اقصى مدة للطلب
    header("Content-Type: text/event-stream");
    $viewd = 0; // عدد الرسائل التي عرضت لمنع إرسال الرسالة اكثر من مرة
    $lastFileSize = 0; // حجم الملف عندما يتغير فان هناك رسالة ارسلت
    while(true){
        if(filesize("./ChatData.json") >= $lastFileSize){// التحديث فقط عند تغير حجم الملف
            $messages = json_decode("[".file_get_contents("./ChatData.json")."]"); // قراءة الرسائل
            for($i=$viewd;$i<=sizeof($messages)-1;$i++){ // حلقة تكرار من أخر رسالة مُرسلة
                echo "data: ".json_encode($messages[$i]).PHP_EOL;
                echo PHP_EOL;
            }
            $viewd = sizeof($messages); // تحديث عدد الرسائل المرسلة
   $lastFileSize = filesize("./ChatData.json"); // تحديث مُتغير أخر حجم للملف
        }
        ob_flush();
        flush();
        sleep(1);
    }
?>

ثم في واجهة المستخدم شفرة javascript لجلب التحديثات:

sse = new EventSource("server.php"); // انشاء الاتصال
sse.onmessage = function(ms){
    var data = JSON.parse(ms.data); // قراءة بيانات json
    var message = document.createElement("div"); // عنصر الرسائل
    message.setAttribute("class","message"); // اضافة كلاسس message 
    var author = document.createElement("div"); // عنصر مُرسل الرسائل
    author.setAttribute("class","author"); // اضافة كلاسس author 
    author.style.backgroundColor = data.author; // تغير لون الخلفية لمعرف المستخدم
    message.appendChild(author); // اضافة عنصر مُعرف مُعرف المستخدم الى عنصر الرسالة
    var content = document.createElement("p"); // محتوى الرسالة
    content.setAttribute("class","content");
    content.innerHTML = data.content;// محتوى الرسالة
    message.appendChild(content);
    messages = document.querySelector(".messages");
    messages.appendChild(message);// اضافة عنصر الرسالة الى حافظة الرسائل
    messages.scrollTop = messages.scrollHeight; // انزال الاسكرول الى الاعلى
}    

ليعمل على انترنت اكسبلور يجب تضمين ملف javscript هذا في الـ header:

<script src="https://rawgithub.com/remy/polyfills/master/EventSource.js"></script> 

يجب ان يكون العمل مُطابق لهذا:

إن لم يعمل معك بشكل صحيح يُمكنك تحميل ملفات الأمثلة وقراءتها حتى تتمكن من معرفة كيف يعمل هذا المثال .

الخاتمة

يُمكنك رؤية المزيد من المصادر لمعرفة المزيد حول SSE:

• eventsource من طرف W3C.
• Server Sent Events من طرف مدونة موزيلا للمبرمجين.

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

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

وغالبًا ما يعتقد الجميع بأن الأمر هنا اختياريًا، في الحقيقة لا.. !!

لا تُعِدْ اختراعَ العجلة !

في عالم الويب، يوجد العديد من نظم إدارة المحتوى المتنوعة، تتيح لك إمكانية إنشاء موقع بسيط، أو بناء مواقع كبيرة ومعقدة بسهولة ويسر. لمن لا يعرف نظم إدارة المحتوى، وكيف يخدم هذا النظام مشرفي المواقع وتحديد النظام المناسب لموقعك ستكون هذه المقالة دليلك المعرفي.

ما هو نظام إدارة المُحتوى ؟

نظام إدارة المحتوى أو ما يعرف بـ (CMS وهي اختصار لـContent Management System)، هو نظام مصمم لإدارة محتوى موقع على شبكة الانترنت أو غيرها من الموارد الإلكترونية التي يتم استخدامها بشكل تعاوني من قبل عددٍ من الناس، وغالبًا تُستخدم نُظم إدارة المحتوى لعمل مواقع مثل: المدونات، مواقع الأخبار، المتاجر الإلكترونية ، والعديد من المواقع للشركات ومواقع التسويق. يهدف نظام إدارة المحتوى لتجنيب الناشر أو المسؤول عن الموقع الحاجة لاستخدام الشيفرات البرمجية، أو حتى معرفته بإحدى لغات الويب مثل : Html. من خلال نظام إدارة المحتوى، بإمكانك بناء وإدارة موقعك الخاص دون الحاجة لمساعدة مصمم و مطوّر ويب، ولكن في بعض الحالات قد تحتاج لمطور إذا أردت إضافة بعض العناصر لصفحات الموقع.

مميزات و عيوب استخدام نظام إدارة محتوى مقارنة بالبرمجة الخاصة.

المواقع المتطورة والتفاعلية التي نراها اليوم مكتوبة بلغات برمجية مثل : (php / Asp.net). بناء مواقع كهذه يتطلب مهارات برمجية وتطويرية، وإذا كنت ممن يودون بناء مواقهم دون الحاجة لمعرفة الـ HTML، أو احدى لغات البرمجة، فنُظم إدارة المحتوى صُممت خصيصًا لك، فهي كل ما تحتاجُه لإنشاء موقع بتصميم احترافي، يحقق لك طموحك ويُلبي حاجتك. العديد من الشركات الناشئة والصغيرة التي تود بناء وإدارة مواقعها بنفسها عمدت إلى اختيار أحد نظم إدارة المحتوى في هذه الأيام.

ايجابيات وسلبيات استخدام نظام إدارة محتوى مقارنة بالبرمجة الخاصة

الإيجابيات : 

• سهولة الاستخدام: في المواقع ذات البرمجة الخاصة (مواقع php، asp.net)، اذا أردت عمل أي تغيير في لوحة التحكم فأنت بالتأكيد بحاجة للعودة للمبرمج أو شركة البرمجة التي قامت بتطوير الموقع. بالنسبة لنظام إدارة المحتوى، لا تحتاج لمهارات خاصة، فالأمر بسهولة برامج ميكروسوفت المكتبية، مع خاصية السحب و الإفلات. بالإضافة إلى لوحة تحكمٍ بسيطة وغير مُعقدة، كما يوفر نظام إدارة المحتوى شروحات ووثائق للمبتدئين.
• تصميم ثابت: في المواقع ذات البرمجة الخاصة، التصميم النهائي للواجهة الأمامية يصبح ثابتًا، ولو طرأ أي تغيير في نوع المحتوى المعروض في الموقع يتأثر التصميم ككل ولا يظهر بصورة سليمة، و تحتاج لمصمم أو مطوّر متخصص للقيام بالتعديل أو الإضافة، مع الأخذ بعين الإعتبار أنّ تكلفة التعديل أو التطوير في هذه الحالة أعلى بكثير مقارنة مع نظام إدارة المحتوى المُصمم خصيصًا لاستيعاب جميع أنواع المحتوى، ولو احتجت لتغيير الواجهة الأمامية لن يتطلب ذلك أي تعقيدات، فكل ما عليك هو تغيير القالب بكل بساطة.
• تكلفة أقل: العديد من نظم إدارة المحتوى المجانية، بالإضافة لإمكانية استضافة موقعك على خوادمهم، وتكلفتها المدفوعة أقل بكثير من تكلفة بناء وتطوير موقع ببرمجة خاصة.
• تفعلُها بنفسك: ربما لا يوجد لكل نظام إدارة المحتوى فريق دعم فني، لكن لديهم مجتمع مستخدمين للمساعدة في حل المشكلات الخاصة به، والمعلومات والحلول موجودة بشكل مجاني على الإنترنت. بإمكانك حل المشكلات بنفسك أو الاستعانة بمطور إذا كانت الأمر معقدًا، مع العلم أن التكلفة بالنسبةِ لك هي الوقت والجهد، إذا ما قورِنت مع دعم فني خاص.

السلبيات:

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

كيف تختار نظام إدارة محتوى مناسب لك؟

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

هناك العديد من نظم إدارة المحتوى المدفوعة والمجانية، التي لا يُمكن حصرُها في مقالة، لذلك سنناقش أكثر النظم انتشارًا، بالإضافة لإيجابيات و سلبيات كل نظام على حده، وفي نهاية المقالة ستكون قادرًا على تحديد النظام الأنسب لموقعك.

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

ووردبرس WordPress :

تُعد أكثر نظام تدوين صديق للمستخدم، وتيح له تعديلها لإنشاء موقع احترافيّ دون الحاجة لأي معرفة بالـ HTML. بإمكانك أن تضيف الصفحات والمنشورات باستخدام الإضافات ( plugins )، ويمكنك أن تُضيف العديد من الوظائف والخصائص إلى موقعك. نظام WordPress مخصص للتدوين ويمتاز بتوافقه مع محركات البحث، وبالأرشفة السريعة لمواضيعه. وإذا نظرنا للنظام من وجهة نظر تسويقية، فهو يعتبر نظام تصعب مقاومته، لواجهته الاحترافية سهلة الاستخدام، التي تستطيع التعامل معها بسلاسة بدون الحاجة إلى دليلٍ إرشادي. إذا أردت التغيير في التصميم والألوان، قد تحتاج لمعرفة مسبقة بأساسيات الـ CSS، أو بإمكانك أن تستعين بمطور لديه الخبرة في هذا النظام للقيام بالتعديلات اللازمة.

تنصيب نظام WordPress سريع بالإضافة للميزة الأساسية، وهي الأرشفة السريعة لمواضيعها في محركات البحث وعلى رأسها محرك البحث الشهير Google، مقارنة مع Joomla التي تحتاجُ وقتًا أطول في عملية الأرشفة، وسبب ذلك أن النظام يساعدك في كتابة مقالاتك وفق أحدث معايير الـ SEO .

ساعتين من التعلم عبر فيديوهات YouTube أو القراءة عن WordPress كفيلةٌ بجعلك قادرًا على خلق محتوىً رائع واحترافيّ بطريقةٍ صحيحة، بالإضافة لتعلم استخدام التصنيفات والصفحات الثانوية.

لا تحتوي Wordpress على نظام تعدد اللغات، لكن بإمكانك تنصيب إضافات معدة لذلك سهلة الإستخدام. كما تستطيع تحمل عدد كبير من الزوار، فهي لا تنهار بسهولة، حتى مع الكثير من المحتوى. تحديثات WordPress ليست كبيرة مما يجعلها منصة مستقرة إلى حد ما.

والآن سنلخص لكم أهم الإيجابيات والسلبيات للمنصة :

الايجابيات:

• مجانية .
• سهلة التنصيب و الصيانة.
• نطاق مستخدمين واسع.
• أكبر عدد من الإضافات و الملحقات متاحة.
• صديقة لمحركات البحث مع العديد من الإضافات.
• مجموعة متميزة من القوالب.

السلبيات:

• خياراتها محدودة.
• القوائم الرئيسية مرتبطة بالقالب المنصب وفي حالة اردت التعديل فانت بحاجه لمعرفة مسبقة في برمجية الـ wordpress.
• ليس كل الاضافات الخاصة بها سهلة الاستخدام و الفهم.
• مناسبة للمواقع التالية: المدونات، مواقع الشركات لصغيرة، المواقع الشخصية.

Drupal:

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

لو أخذنا على سبيل المثال : موقع إعلانات مبوبة. من خلال هذه الوحدات بإمكانك إنشاء حقول محتوى متعددة والتحكم بهذه الحقول بكل سهولة ويسر وتنيظم عرض المحتوى، فمثلاً : لو أردت أن يظهر آخر ما تم اضافته للموقع من إعلانات أو ترتيب الإعلانات حسب المدينة أو تاريخ الإضافة، وغيرها العديد من الخيارات التي تمكنك من التحكم بشكل كبير في موقعك.

من وجهة نظري، أهم ما يميز Drupal هو أن التصميم لا يتحكم بالموقع كما في WordPress، بل هي من تتحكم بالتصميم .

ايجابياتها:

• مجانية.
• حل ممتاز للمواقع التي تمتلك حركة عالية من الزوار باستمرار.
• التحكم في حجم الموقع بكل سهولة.
• تتميز باستقرار عالي.
• القدرة على تحرير المحتوى من خلال الواجهة الأمامية للموقع.
• لديها نظام مستخدمين قوي ومرن في التعامل، يمكنك من منح أذونات متعددة.
• صديقة لمحركات البحث.

سلبياتها:

• على خلاف WordPress، استخدام Drupal بحاجه لمعرفة مسبقة بتقنيات الـ HTML ، ومعرفة جيّدة بلغة البرمجة PHP.
• عدد القوالب الخاصة بها محدود.
• الإضافات المجانية قليله مقارنة بغيرها من نظم ادارة المحتوى.
• تكلفة الصيانة مرتفعة نسبيًا.
• مناسبة للمواقع التالية: الشركات الكبيرة، مواقع الإعلانات المبوبة، مواقع التجارة الإلكترونية الكبيرة.

Joomla:

إذا كنت تريد إنشاء مجتمع إلكتروني أو شبكة اجتماعية مع نظام العضويات فيها أو غُرف للأخبار، منتديات، موقع أخباري لنشر المقالات، أو استضافة كتّاب عديدين للنشر في موقعك ..الخ، ستكون Joomla الخيار الأمثل لك، لأنها مصممة لهذا الغرض.

إنشاء هيكلية وبنية الموقع سهلة، فقط تحتاج منك معرفة أساسية بكيفية عمل المنصة، ولا تحتاج منك إلى أي معرفة بلغة الـHTML . تتيح لك المنصة إمكانية الجدولة الزمنية للمقالات، وتصنيفها حسب تاريخ النشر واسم المؤلف، والكثيرمن الخصائص الأخرى.

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

ايجابياتها:

• على الرغم من أنها لا تُشبه Wordpress، إلا أنها مازالت تُعد مرنه وسهلة للاستخدام من قبل المستخدم إلى حدٍ ما.
• كما هو الحال في wordpress، Joomla   أيضًا لديها مجتمع إلكتروني كبير، وجمهور خاص بها .
• توفر عدد كبير من الملحقات والإضافات.

سلبياتها:

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

Tumblr :

البعض يعرفها كمنصة للتواصل الإجتماعي، والآخر يعتبرها منصة للتدوين المصغر. لكن القليل هم من يستخدمها بذكاء كموقع الكتروني. إذا كنت تفضل موقع بسيط بلوحة تحكم بسيطة وتواصل مباشر مع جمهورك بخيارات مرنه ف tumblr هي خيارك الأنسب.

ايجابياتها:

• تستطيع اختيار نطاق خاص مجانًا.
• بإمكانك استضافة نطاق فرعي على tumblr للمدونة الخاصة بموقعك مثل : blog.yourdomain.com .
• سهلة الإستخدام و لا تحتاج لتدريب.
• تحتوي على ميزة الأسئلة والإجابات من خلال الجمهور.
• لديها تطبيقات للهواتف الذكية، مما يعني قدرة إدارة المحتوى الخاص بك من أي جهاز.

سلبياتها:

• ليست مناسبه للمواقع ذات الوظائف المتعددة.
• غير مناسبة للمواقع ذات المحتوى الكبير.
• تفتقر للتحكم الكامل بالموقع بسبب استضافتها على خادوم Tumblr.
• مناسبة للمواقع التالية: مواقع نماذج الأعمال، موقع مدونة، موقع لمستقل (إذا كُنتَ مهندسًا أو طبيبًا، فالمنصة تُعد خيارًا مميزًا لنشر معلوماتك وخبراتك وسط جمهورٍ كبير، مع إمكانية التواصل معك وطرح الأسئلة والإستفسارات من قبل الجمهور) .

بعد أن تعرفت على نظم إدارة المحتوى، هل يعني ذلك إلغاء فكرة البرمجة الخاصة؟ بالطبع لا. نظم إدارة المحتوى وجدت لتوفر علينا الوقت والجهد حسب متطلباتنا، إلا أن إمكانياتها رغم كثرتها وكبر حجمها تبقى محدودة. إذًاً... متى أحتاج لبرمجة الموقع ببرمجة خاصة ؟

• لبناء نظام موظفين .
• في مواقع البنوك.
• في المواقع  التي تقدم خدمة معينة مثل: مواقع تصميم الإنفوجرافيك.
• أيضًا إذا كنت بحاجة لعمل لوحة تحكم تتوافق مع نظام الشركة و يتعامل معها الموظفين.

تعلمنا في الجزء السابق أن HTTP بروتوكول على مستوى التطبيقات. حان الوقت لنفهم كيفية استخدام هذا البروتوكول للتواصل بين العميل والخادوم.

جلب الأشياء من الويب

تذكر أن عميل HTTP (وهو المتصفح عادةً) هو الطرف الذي يبدأ بإرسال الطلب إلى الخادوم. يسمح بروتوكول HTTP للعميل بالتعبير عن نيّته من خلال بضعة مُكوّنات: الرابط (URI)، وأفعال HTTP، وترويساته.

تسمية الأشياء

تمثّل الروابط (URIs) حجر الأساس في الويب، لأنّها تحل مشكلة مهمّة على مستوى الإنترنت بكاملها، وهي مشكلة منح الأشياء مُعرّفًا تنفرد به على الشّبكة.

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

• بإمكانك أن تطلب من صديقك قائلًا: "اجلب لي الكتاب."
• قد يجيبك صديقك: "حاضر. ولكن أي كتاب؟".
• فتقول أنت: "الكتاب في الغرفة الأخرى."
• فيذهب صديقك إلى الغرفة ويسأل: "أي كتاب قلت؟"
• فتقول أنت وقد شعرت بالضّيق: "الأخضر!"
• ليقول صديقك: "تمهّل لحظة... هناك كتابان أخضران في الغرفة!"

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

1. قص ورقات صغيرة أو استخدم ورق الملاحظات اللّصّاق.
2. ضع هذه الأوراق على الأغراض في الغرفة المجاورة أو على الطّاولة (كالكتب مثلًا).
3. اكتب مُعرّفًا مُميِّزًا على كل ورقة.
4. كرّر العملية في غرفة مجاورة أو على طاولة مجاورة.

تذكّر أن هذا النّظام لا يقتصر على أغراضك، بل يمتد ليسمح بنوعٍ من التّواصل بين الأغراض جميعها. طبّقت هذا النّظام على أغراضي، فكتبت على كل قطعة ورق واحدًا من المُعرّفات التالية:

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

1. انسخ http://www.opera.com/ إلى قسم URL.
2. انسخ والصق طلب HTTP التّالي إلى قسم "Request body" في تبويب Network. أضفنا الترويسة Accept-Language إلى طلب HTTP السابق.
3. اضغط الزر "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.

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

نزهة في الشوارع

خرجت ذات صباح قاصدًا مقهى لأقرأ كتابًا، لكنّني وجدت المقهى مُغلقًا حينها، وقد كُتب على لوحة على الباب أنّ احتفالًا يُقام خلال هذا الأسبوع، ولذلك فإنّ المقهى سينتقل مؤقتًا ليُقدّم القهوة في شاحنة الطّعام (التي سمّوها "307") قرب النهر. ذهبت إلى ذلك المكان واستمتعت بشرب القهوة.

قرّرت بعدئذٍ التجوّل في مكتبتي المفضّلة في المدينة، فوجدتها مُغلقةً كذلك، إلّا أنّني رأيت لوحة على الباب تقول أن المكتبة ستتوسع ولذلك انتقلت بشكل دائم إلى مبنى جديد في 301 شارع برنرز-لي. لم يُزعجني ذلك، فالمكان قريب. ذهبت إلى هناك فاستقبلني الموظّفون بالتّرحاب: "200 سلامة!". حسنًا، أنا أبالغ قليلًا، لكنّك فهمتني!

في طريقي إلى البيت، وجدت متجرًا مهجورًا غطّى الغبار أبوابه في 410 شارع برنرز-لي، وقد أُلصقت ورقةٌ على الباب تقول أنّ صاحب المحلّ تقدّم بطلب إشهار الإفلاس واضطّر إلى إغلاق المتجر، إلى الأبد. وكأنّ العجائب لم تنتهِ اليوم، إذ رأيت في نهاية 500 شارع برنرز-لي مبنى من 4 طوابق وقد انهار بالكامل. ما الذي حدث هنا؟!

لم يكن يومي سيئًا بالمجمل، لذا قرّرت أن أكمل يومي بكتابة مقال عن رموز HTTP الّتي تُرسلها الخواديم إلى العملاء الّذين يرسلون الطّلبات.

صياغة جواب HTTP وسطر الحالة

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

إما إن تكون رسالة HTTP طلبًا من العميل إلى الخادوم أو جوابًا من الخادوم للعمل. من حيث الصّياغة، لا يختلف نوعا الرّسائل إلى في السّطر الأوّل، والذي إمّا أن يكون سطر طلب (للطلبات) أو سطر حالة (للإجابات)، وفي خوارزميّة تحديد طول متن الرّسالة (القسم 3.3).

يُدعى السّطر الأول في الجواب إذًا سطر الحالة. يبدأ السّطر بإصدارة بروتوكول HTTP ثمّ مسافة ثم رمز من ثلاثة أرقام، ثم مسافة ثمّ جملة تشرح الرّمز، كهذا المثال:

HTTP/1.1 200 OK

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

رموز الحالة في HTTP

200، كلّ شيء على ما يرام!

في كلّ مرّة يريد شخصٌ ما زيارة الصّفحة الرئيسيّة لموقع 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 GMT

307، انتقلتُ مؤقّتًا إلى مكان آخر

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

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 Gone

500، يا للمصيبة!

قد يتعذّر على الخادوم إجابة الطّلب لسبب مجهول. لا يتدخّل 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.

OAuth 2 هو آليّة للتّرخيص تسمح للتطبيقات بطلب وصول محدود إلى حسابات المستخدمين في خدمات HTTP، مثل Facebook وGitHub وDigitalOcean. يعمل OAuth 2 بتوكيل الخدمة المستضيفة لحساب المستخدم باستيثاق هذا الحساب، ثمّ السّماح للتطبيقات الخارجيّة بالوصول إلى حساب المستخدم هذا. يوفّر OAuth 2 مسارًا لترخيص تطبيقات الويب وتطبيقات سطح المكتب والأجهزة المحمولة.

هذا الدّرس موجّه لمطوّري التّطبيقات، وهو يُلقي الضّوء على أدوار OAuth 2 وأنواع الرُّخَص المتاحة، وكذلك يستعرض مجالات استخدامه وسير عمليّة التّرخيص.

لنبدأ بالتّعرّف على أدوار OAuth.

أدوار OAuth

يُحدِّد OAuth أربعة أدوار:

• مالك المحتوى
• العميل
• خادوم المحتوى
• خادوم التّرخيص

سنُفصّل كلًّا من هذه الأدوار في الفقرات التّالية.

مالك المحتوى: المستخدم

مالك المحتوى هو المستخدم الذي يُرخِّص لتطبيقٍ الوصول إلى حسابه. وصول التّطبيق إلى حساب المستخدم محدودٌ "بنطاق" (scope) الترخيص الممنوح (مثلاً: صلاحيّة القراءة والكتابة).

خادوم المحتوى/التّرخيص: الواجهة البرمجيّة (API)

يستضيف خادوم المحتوى حسابات المستخدمين المحميّة، ويتحرّى خادوم التّرخيص هويّة المستخدم ثمّ يمنح التّطبيق رمز وصول (access token).

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

العميل: التّطبيق

العميل هو التّطبيق الّذي يريد الوصول إلى حساب المستخدم، وقبل أن يستطيع ذلك، يجب أن يحصل على "ترخيص" المستخدم، وعلى هذا التّرخيص أن يُصادَق من الواجهة البرمجيّة.

سير البروتوكول نظريًّا

بعد أن تعرّفنا على أدوار OAuth، دعونا نلقِ نظرةً على المخطّط التالي، والذي يبيّن كيف تتفاعل هذه الأدوار فيما بينها:

وفيما يلي شرح أكثرُ تفصيلًا للخطوات المُبيّنة في المُخطّط:

1. يطلب التطبيق رخصةً للوصول إلى الخدمة من المستخدم
2. إن رخّص المستخدم الطّلب، فإنّ التطبيق يحصل على إذن بالتّرخيص
3. يطلب بعدها التطبيق رمز وصول (access token) من خادوم التّرخيص (الواجهة البرمجيّة) مُقدّمًا ما يُثبت هوّيته مع إذن التّرخيص الّذي حصل عليه.
4. إن كانت هويّة التّطبيق موثّقة وإذن التّرخيص سليمًا، أصدر خادوم التّرخيص (الواجهة البرمجيّة) رمز وصول (access token) يمنحه للتّطبيق، لتكتمل حينئذٍ عمليّة الترخيص.
5. يطلب التّطبيق من خادوم المحتوى (الواجهة البرمجيّة) المحتوى المطلوب، مُقدّمًا رمز الوصول الّذي حصل عليه.
6. إن كان رمز الوصول سليمًا، قدّم خادوم المحتوى (الواجهة البرمجيّة) المحتوى المقصود للتطبيق

قد يختلف مسار العمليّة الفعليّ بحسب نوع الرّخصة المُستخدمة، ولكن هذه هي الفكرة العامّة. سنستعرض أنواع الرُّخَص المُختلفة في فقرة لاحقة.

تسجيل التّطبيق

قبل استخدام OAuth في تطبيقاتك، عليك تسجيل التّطبيق في الخدمة المعنيّة. يجري التسجيل عادةً من خلال نموذج في قسم المُطوّرين أو الواجهة البرمجيّة في موقع الخدمة على الويب، حيث ينبغي عليك تقديم البيانات التالية (وربّما معلومات أخرى عن تطبيقك):

• اسم التّطبيق
• موقع التّطبيق
• رابط إعادة الّتوجيه (Redirect URL) أو الاستدعاء الرّاجع (Callback URL)

تُعيد الخدمة توجيه المستخدم إلى رابط إعادة التّوجيه الّذي توفّره بعد ترخيصه لتطبيق (أو رفضه)، وعليه فإنّ هذا الرابط هو المسؤول عن التّعامل مع رموز الترخيص أو رموز الوصول (access tokens).

مُعرّف العميل وكلمة سرّ العميل

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

إذن التّرخيص

في فقرة "سير البروتوكول نظريًّا"، تبيّن الخطوات الأربع الأولى كيفيّة الحصول على إذن بالتّرخيص ورمز للوصول. يعتمد نوع الإذن على طريقة طلب التّطبيق للتّرخيص، وأنواع الأذون الّتي تدعمها الواجهة البرمجيّة. يعرّف OAuth 2 أربعة أنواع من أذون التّرخيص، يمكن الاستفادة من كلّ منها في حالات مُختلفة:

• رمز التّرخيص (Authorization Code): تستخدمه التّطبيقات الّتي تعمل على الخواديم
• ضمنيّ (Implicit): تستخدمه تطبيقات الويب وتطبيقات الأجهزة المحمولة (أي التّطبيقات الّتي تعمل على جهاز المُستخدم)
• كلمة مرور مالك المحتوى: تستخدمها التّطبيقات الموثوقة، كتلك الّتي تتبع للخدمة ذاتها
• كلمة مرور العميل: تستخدم في حالة الوصول للواجهة البرمجيّة للتّطبيقات

سنشرح أنواع الأذون وحالات استخدامها بالتّفصيل في الفقرات التّالية.

الإذن من نوع "رمز الترخيص":

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

سنشرح الآن سير عمليّة التّرخيص في هذا النّوع من الأذون:

سير التّرخيص بالرّمز

الخطوة 1: رابط رمز الترخيص

يُعطى المُستخدم في البداية رابطًا لرمز التّرخيص يُشبه هذا:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

فيما يلي شرحٌ لمكوّنات الرابط:

• https://cloud.digitalocean.com/v1/oauth/authorize: نقطة الوصول إلى قسم التّرخيص في الواجهة البرمجيّة
• client_id=client_id: مُعرّف العميل للّتطبيق (كيفيّة تحديد الواجهة البرمجيّة لهويّة التّطبيق)
• redirect_uri=CALLBACK_URL: المكان الّذي تعيد الخدمة توجيه وكيل المستخدم إليه بعد منح رمز الترخيص
• response_type=code: يُبيّن أنّ تطبيقك يطلب إذنًا بالحصول على رمز ترخيص
• scope=read: يُعيّن مستوى الوصول الّذي يطلبه المُستخدم

الخطوة 2: يُرخّص المستخدم التّطبيق

عندما ينقر المُستخدم الرّابط، يجب عليه أوّلًا تسجيل الدّخول إلى الخدمة، وذلك للتّحقق من هويّة المُستخدم (ما لم يكن قد سجّل دخوله من قبل). ثم تعرض عليه الخدمة ترخيص أو رفض وصول التّطبيق إلى حسابه. فيما يلي مثال عن صفحة ترخيص التّطبيق:

هذه الصّورة مُلتقطة من صفحة ترخيص DigitalOcean، ونرى فيها التّطبيق "Thedropletbook App" يطلب إذنًا بقراءة حساب المُستخدم "manicas@digitalocean.com".

الخطوة 3: يتلقّى التطبيق رمز التّرخيص

إذا نقر المُستخدم "Authorize Application"، فإنّ الخدمة تُعيد تحويل وكيل المستخدم إلى رابط إعادة التّوجيه الّذي حدّده التّطبيق أثناء تسجيل المُطوِّر له، وتُرفق الخدمة مع الرّابط رمز التّرخيص. مثال على الرّابط (مُفترضين أنّ التّطبيق هو "dropletbook.com"):

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

الخطوة 4: يطلب التّطبيق رمز الوصول (Access Token)

يطلب التّطبيق من الخدمة رمز وصول، مُمرّرًا لها رمز التّرخيص مع تفاصيله، بما في ذلك كلمة سرّ العميل، والّتي تُرسل جميعها إلى رابط الحصول على رمز الوصول الخاصّ بالخدمة. فيما بلي مثال على طلب POST يُرسل إلى رابط رمز الوصول في DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

الخطوة 5: يتلقّى التّطبيق رمز الوصول

إن كان التّرخيص سليمًا، فإنّ الواجهة البرمجيّة تردّ على الطّلب بجواب يحوي رمز الوصول (مع رمز إعادة تجديد الرّخصة، غير إلزاميّ) إلى التّطبيق. يبدو الجواب مثل هذا:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}

أصبح التّطبيق الآن مُرخّصًا! وبإمكانه استخدام الّرمز للوصول إلى حساب المُستخدم عن طريق الواجهة البرمجيّة للخدمة، محدودًا بنطاق الوصول، إلى أن تنتهي مدّة الرّمز أو يُسحب التّرخيص. في حال أُصدر رمز إعادة تجديد الرّخصة (refresh token)، فبإمكان التّطبيق استخدامه للحصول على رمز وصول جديد في حال انتهى مدّة السّابق.

الإذن الضّمنيّ

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

لا يدعم هذا النّوع من الأذون رموز إعادة تجديد التّرخيص.

يسير التّرخيص في هذا النّوع كما يلي: يُطلب من المُستخدم ترخيص التّطبيق، ثمّ يُمرّر خادوم التّرخيص رمز الوصول إلى وكيل المُستخدم، الّذي ينقله بدوره إلى التّطبيق. إن كُنت مُهتمًّا بالتّفاصيل، فتابع القراءة.

سير التّرخيص الضّمنيّ

الخطوة 1: رابط التّرخيص الضّمني

يُعرض على المُستخدم رابط التّرخيص، الّذي يطلب رمزًا من الواجهة البرمجيّة، يبدو هذا الرّابط مُشابهًا لرابط رمز التّرخيص، باستثناء أنّه يطلب رمز token بدلًا من code (لاحظ نوع الجواب المطلوب "token"):

https://oauth.example.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص الضّمني، لذا ذكرنا رابطًا وهميًّا "oauth.example.com".

الخطوة 2: يرخّص المُستخدم التّطبيق

عندما ينقر المُستخدم الرّابط، يجب عليه أوّلًا تسجيل الدّخول إلى الخدمة، وذلك للتّحقق من هويّة المُستخدم (ما لم يكن قد سجّل دخوله من قبل). ثم تعرض عليه الخدمة ترخيص أو رفض وصول التّطبيق إلى حسابه. فيما يلي مثال عن صفحة ترخيص التّطبيق:

نرى في الصّورة التّطبيق "Thedropletbook App" يطلب إذنًا بقراءة حساب المُستخدم "manicas@digitalocean.com".

الخطوة 3: يتلقّى وكيل المُستخدم رمز الوصول مع رابط إعادة التّوجيه

إذا نقر المُستخدم "Authorize Application"، فإنّ الخدمة تُعيد تحويل وكيل المستخدم إلى رابط إعادة التّوجيه الّذي حدّده التّطبيق أثناء تسجيل المُطوِّر له، وتُرفق الخدمة مع الرّابط رمز الوصول. مثال على الرّابط:

https://dropletbook.com/callback#token=ACCESS_TOKEN

الخطوة 4: يتبع وكيل المُستخدم مسار إعادة التّوجيه

يتبع وكيل المُستخدم رابط إعادة التّوجيه مع احتفاظه برمز الوصول.

الخطوة 5: يُرسل التّطبيق نصًّا برمجيًّا لاستخراج رمز الوصول

يُعيد التّطبيق صفحة ويب تحوي نصًّا برمجيًّا بإمكانه استخراج رمز الوصول من رابط إعادة التّوجيه الكامل الّذي احتفظ به وكيل المُستخدم.

الخطوة 6: يُمرّر رمز الوصول إلى التّطبيق

يُنفّذ وكيل المستخدم النّصّ البرمجيّ ويُمرّر رمز الوصول المُستخرَج إلى التّطبيق.

أصبح التّطبيق الآن مُرخّصًا! وبإمكانه استخدام الّرمز للوصول إلى حساب المُستخدم عن طريق الواجهة البرمجيّة للخدمة، محدودًا بنطاق الوصول، إلى أن تنتهي مدّة الرّمز أو يُسحب التّرخيص.

ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص الضّمني، لذا ذكرنا رابطًا وهميًّا "oauth.example.com".

الإذن بالوصول إلى كلمة مرور مالك المُحتوى

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

سير التّرخيص بالحصول على كلمة مرور المُستخدم

بعد أن يُعطي المستخدم كلمة مروره للتّطبيق، يطلب التّطبيق رمز الوصول من خادوم التّرخيص. يُشبه طلب POST ما يلي:

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

إن كان اسم المُستخدم وكلمة المرور صحيحين، يُعيد خادوم التّرخيص رمز وصول للتّطبيق ويُصبح التّطبيق مُرخّصًا!

ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص بالحصول على كلمة المرور، لذا ذكرنا رابطًا وهميًّا "oauth.example.com".

الإذن بالوصول إلى كلمة مرور العميل

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

سير التّرخيص بالحصول على كلمة مرور العميل

يطلب التّطبيق رمز الوصول مُرسلًا مُعرَّفه وكلمة مروره إلى خادوم التّرخيص، فيما يلي مثال عن طلب POST:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

إن كان مُعرّف التّطبيق وكلمة مروره صحيحين، يُعيد خادوم التّرخيص رمز وصول للتّطبيق ويُصبح التّطبيق مُرخّصًا باستخدام حسابه الخاصّ!

ملاحظة: لا تدعم DigitalOcean حاليًا التّرخيص بالحصول على كلمة مرور العميل، لذا ذكرنا رابطًا وهميًّا "oauth.example.com".

مثال على استخدام رمز الوصول

بعد أن يحصل التّطبيق على رمز الوصول، إمكانه استخدام هذا الّرمز للوصول إلى حساب المُستخدم عن طريق الواجهة البرمجيّة للخدمة، محدودًا بنطاق الوصول، إلى أن تنتهي مدّة الرّمز أو يُسحب التّرخيص.

فيما يلي مثال عن طلب يُرسل للواجهة البرمجيّة للخدمة باستخدام curl، لاحظ أنّه يتضمّن رمز الوصول:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"

على فرض أنّ رمز الوصول سليم، فإنّ الواجهة البرمجيّة تُعالج الطّلب حسب ما صُمِّمت؛ وإلّا أعادت الواجهة خطأ "invalid_request"، كما يحدث عند انتهاء مدّة التّرخيص أو استخدام رمز خاطئ.

سير الحصول على رمز إعادة تجديد الرُخصة

يؤدّي استخدام رمز وصول بعد انتهاء مدّة صلاحيّته إلى "خطأ رمز غير سليم (Invalid Token Error)". في هذه النّقطة، يمكن استخدام رمز إعادة تجديد الرّخصة في حال أُصدَر مع رمز الوصول للحصول على رمز وصول جديد من خادوم التّرخيص.

فيما يلي مثال على طلب POST للحصول على رمز وصول جديد مُستخدمين رمز إعادة تجديد:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

الخاتمة

إلى هناك نكون قد وصلنا إلى ختام دليل OAuth. من المُفترض أن لديك الآن فكرة جيّدة عن البروتوكول وكيف يعمل، ومتى يمكن استخدام كلّ نوع من الأذون.

إذا أردت تعلّم المزيد عن OAuth 2، اطّلع على هذه المصادر القيّمة (بالإنكليزيّة):

• How To Use OAuth Authentication with DigitalOcean as a User or Developer
• How To Use the DigitalOcean API v2
• The OAuth 2.0 Authorization Framwork

ترجمة (بشيء من التّصرّف) لمقال Introduction to OAuth 2 لصاحبه Mitchell Anicas.

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

في عالم الويب، لدينا بروتوكول فعّال جدًّا على مستوى التّطبيقات يُمهّد الحواسيب حول العالم لتبادل الأحاديث النّافعة، واسمه Hypertext Transfer Protocol، أو HTTP اختصارًا؛ وهو بروتوكول يُصنّف ضمن طبقة التّطبيقات فوق TCP/IP، وهو أيضًا بروتوكول للتواصل. كثيرًا ما يغيب شرح HTTP في دروس التصميم والتطوير للويب، وهذا أمرٌ مُخزٍ: ففهمه يُعينك في تحسين تفاعل المستخدم وتحقيق أداء أفضل للموقع وإنشساء أدوات فعّالة لإدارة المعلومات على الويب.

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

ما معنى بروتوكول تواصل؟

قبل الدّخول في التفاصيل، لنتخيّل موقفًا بسيطًا يحدث فيه تواصل بين طرفين، ولكي يحدث هذا التواصل، فإن على الطّرفين (برنامجين كانا أم جهازين أم شخصين... إلخ.) أن يتّفقا على:

• الصياغة (تنسيق البيانات)
• الدلالات (معلومات التحكم والتعامل مع الأخطاء)
• التوقيت (تطابق السرعة والتتالي)

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

يتركّب بروتوكل التواصل عبر الشبكات من المكوّنات ذاتها. فأمّا الصّياغة فهي سلسلة من الحروف كالكلمات المفتاحيّة المُستخدمة في كتابة البروتوكول، وأمّا الدلالات فهي المعاني المُرتبطة بكلّ من هذه الكلمات، وأمّا التوقيت فهو ترتيب تبادل هذه الكلمات بين الطّرفين.

ما محلّ HTTP من الإنترنت؟

يقوم HTTP نفسه فوق بروتوكولات أخرى. فعند الاتصال بموقع ويب مثل www.example.org، يستخدم وكيل المستخدم (user agent) مجموعة بروتوكولات TCP/IP، والتي صُمّمت في عام 1970 مؤلّفة من 4 طبقات:

1. طبقة الوصلة (Link)، والتي تصف الوصول إلى الوسيط المادّي (كاستخدام بطاقة الشبكة مثلًا)
2. طبقة الإنترنت، والتي تصف كيفيّة تغليف البيانات وتوجيهها (IP أو Internet Protocol)
3. طبقة النقل (Transport)، والتي تصف كيفية نقل البيانات من نقطة الانطلاق إلى الوجهة (TCP وUDP)
4. طبقة التطبيقات (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>. 

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

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

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

وبأي حال، سنحاول من خلال هذا الموضوع مناقشة بعض الفروقات الهامة بين منصة وورد برس ومنصة بلوجر والإجابة على هذا التساؤل، لكن أرجو أن نلتفت إلى النقاط التالية قبل البداية:

• المقارنة التالية موجهة بشكل أساسي للراغبين باستخدام إحدى المنصتين في مجال التدوين أو ما شابه، وليست مقارنة لما يمكننا فعله باستخدام كل منصة.

• المقارنة ستكون بين منصة بلوجر و WordPress.org غير المدفوعة

• هذه المقارنة لا تشبه المقارنات بين فريقي كرة القدم "ريال مدريد" و"برشلونة" أو بين شركتي Apple وSamsung، فهي لا تهدف إلى نسف منصة ما وتمجيد الأخرى، بل هي محاولة عملية لمساعدة القارئ للوصول إلى استخدام منصة معينة وفق معايير محددة.

دعونا نبدأ

أولاً: الملكية

بلوجر هي منصة نشر محتوى تمتلكها شركة Google العملاقة وبالتالي يمكنك الوثوق بها دون تردد كغيرها من منتجات شركة Google الرائعة، بينما منصة وورد برس هي نظام مفتوح المصدر لإدارة المواقع تمتلكه شركة Automattic ويعود حق ملكية المدونة إلى المدون نفسه.

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

بينما مع مدونة وورد برس ستكون أنت المالك الفعلي للمدونة ويمكنك إغلاقها كيفما تريد، ولا يمكن لجهة معينة إغلاق أو حذف المدونة لسبب أو لآخر حيث ستكون لديك سيطرة كاملة على محتويات وملفات مدونتك من خلال استضافة خاصة.

المسألة الثانية المترتبة على موضوع الملكية هي إمكانية بيع المدونة، فمع مدونات بلوجر هناك صعوبة بالغة في بيع المدونة مع عدم حقك أصلاً في بيعها، بينما مع مدونات وورد برس فلك الأحقية الكاملة في بيع المدونة متى شئت وبكل سهولة.

الخلاصة: من الواضح أن استخدام وورد برس لديه أفضلية في هذه النقطة، لكن من الإنصاف القول بأن شركة Google لا تلجأ إلى إغلاق المدونة بسبب انتهاك بسيط وهي غير متعسفة إطلاقاً في استخدام هذا الحق. وبالتالي فإن الالتزام بسياسة بلوجر يضمن لك عدم المساس بالمدونة من طرف Google.

ثانياً: التصميم

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

وقد تتجه فعلاً لاختيار أحد المختصين في تطوير قوالب بلوجر وتدفع له مقابل ذلك للحصول على قالب يناسبك، لكنك في الغالب ستُصطدم بالخيارات المحدودة جداً التي تسمح بها منصة بلوجر من حيث التصميم والقالب.

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

الخلاصة: الأفضلية من حيث القوالب والتصميم هي لمدونات وورد برس.

ثالثاً: التعامل مع المنصة

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

بينما تحتاج مدونات وورد برس إلى معرفة ببعض الأشياء الفنية والبرمجية بشكل مسبق حتى تتمكن من تنصيب المدونة والبدء في نشر المواضيع، وبالتالي قد يجد بعض المدونين صعوبة في التعامل مع وورد برس في البداية.

الخلاصة: مدونات بلوجر لها الأفضلية من حيث التعامل وسهولة الاستخدام ولا تتطلب معرفة مسبقة بالأمور الفنية.

رابعاً: التحكم في المنصة

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

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

الخلاصة: الأفضلية من حيث التحكم في المنصة هي لمدونات وورد برس.

خامساً: تحسين الظهور في محركات البحث "SEO"

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

دعونا نحتج برأي المهندس في شركة جوجل Matt Cutts، فهو يعمل لدى الشركة المالكة والداعمة لبلوجر بينما تعمل مدونته الشخصية عبر منصة وورد برس.

يرى Matt أن كل من المنصتين تعمل بشكل مناسب مع SEO وكل منصة لها إيجابيات وسلبيات، لكن في نفس الوقت فإن منصة وورد برس تعطي خيارات وإمكانية تخصيص أكبر في هذه المسألة.

ويضيف Matt بأنه إذا كنت تمتلك محتوى جيد وعددًا معقولًا من الروابط المؤدية لمدونتك وبالتالي زوارًا أكثر، فإن المسألة لن تشكل أي فارق بين استخدام وورد برس أو بلوجر.

يمكننا القول بأن مسألة SEO تعتمد في الأساس على المدون نفسه، فكل من وورد برس وبلوجر لا تقدم أي مميزات في هذا الخصوص ابتداءً، وبالتالي على المدون معرفة بعض الاستراتيجيات المتعلقة بالسيو للحصول على ظهور أفضل.

لكن يمكن لمستخدمي منصة وورد برس الاستعانة لاحقاً ببعض الإضافات المتعلقة بـ SEO مثل إضافة Yoast والتي توفر العديد من المميزات والاحتياجات المتعلقة بالسيو، وهذا الأمر غير متوفر في مدونات بلوجر.

الخلاصة: وورد برس يتيح خيارات أوسع من ناحية تحسين محركات البحث "SEO" من خلال توفير العديد من الإضافات والقدرة على تهيئة المدونة لمحركات البحث بشكل أفضل، لكن في نفس الوقت يجب الالتفات إلى أن جودة المحتوى هي النقطة المركزية في المدونة، بمعنى لو أنك تمتلك محتوى ضعيف وسيء مع أفضل استراتيجية سيو في العالم فلا تتوقع أن تحقق مدونتك أي نجاح حقيقي على صعيد الشبكة العنكبوتية. بينما المحتوى الجيد سواء كان عبر منصة بلوجر أو وورد برس هو المفتاح الحقيقي للنجاح.

سادساً: التكاليف

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

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

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

الخلاصة: مدونات بلوجر لها الأفضلية من حيث التكاليف، بينما يجب أن يتوفر لك مبلغ مادي لإنشاء مدونة وورد برس.

سابعاً: الأمان

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

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

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

ثامناً: الدعم

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

أما بالنسبة لمدونات وورد برس فهي تتمتع بدعم فني كامل، مع وجود العديد من المساهمين والمطورين المستعدين لتقديم المساعدة عبر قسم المساعدة أو المنتدى الرسمي الخاص بالمنصة، وبالتالي ستجد حلاً لأغلب المشاكل التي قد تواجهك عند استخدامك للمنصة بكل سهولة.

الخلاصة: تمتلك مدونات وورد برس أفضلية كاملة من حيث الدعم الفني وإيجاد الحلول لأي مشكلة تواجه المدون.

تاسعاً: مستقبل المنصّتين

دعونا نعود إلى الوراء قليلاً ونتذكر الخطوة التي قامت بها شركة ياهو بإغلاق منتديات مكتوب والصدمة التي تلقتها شريحة واسعة من المستخدمين في العالم العربي حينها.

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

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

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

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

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

الخلاصة: تمتلك مدونات وورد برس أفضلية واضحة من ناحية مستقبل المنصة، سواء من حيث الملكية أو التطوير والتحديث، في نفس الوقت لا يوجد أي نهوض حقيقي لغاية الآن لمنصة بلوجر بالإضافة إلى المخاوف الخاصة بإغلاق الخدمة من طرف جوجل.

بعد هذه المناقشة المفصلة لأوجه الفرق بين المنصتين دعونا نلخص أبرز مميزات وعيوب كل منصة على هيئة نقاط سريعة.

مميزات بلوجر

• منصة بسيطة جداً وسهلة الاستخدام.
• التكامل مع خدمات شركة جوجل وأهمها جوجل أدسنس.
• مجانية تماماً، مع إمكانية دفع مبالغ بسيطة بحسب رغبة المدون مثل امتلاك دومين مدفوع أو الحصول على قالب خاص وأكثر احترافية من القوالب المجانية.
• توفر مستوى عالي من الحماية والأمان
• تساعد المدون بالتركيز على تقديم المحتوى بعيداً عن الأمور الفنية الأخرى.

عيوب بلوجر

• عدم وجود إضافات
• خيارات محدودة بالنسبة للتصميم والقالب
• لست المالك الحقيقي للموقع
• عدم وجود دعم فني
• خيارات محدودة جداً لتخصيص المدونة والتحكم بها

مميزات وورد برس

• منصة مرنة تمتلك العديد من الوظائف والخيارات المختلفة
• وجود مجموعة كبيرة جداً من التصاميم والقوالب التي يمكنك الاختيار بينها.
• إمكانية تخصيص المدونة بشكل كامل، بالإضافة إلى وجود العديد من الإضافات
• إمكانية التحكم الكامل بالمدونة بالإضافة إلى حق الملكية.
• دعم فني شامل والحصول على حل لأي مشكلة قد تواجهك

عيوب وورد برس

• تحتاج بعض الوقت للتعلم والتعامل مع المنصة
• تحتاج إلى صيانة ومتابعة دورية
• تحتاج إلى دفع تكاليف أكبر وتوفير ميزانية محددة منذ البداية لبناء المدونة.
• الصعوبة في التعامل مع المنصة والتكيف معها في البداية، خصوصاً للمدونين الجدد.

والآن وصلنا إلى الإجابة النهائية عن التساؤل الأساسي لهذا الموضوع، ماذا أستخدم بلوجر أم وورد برس؟

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

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

لذلك أرجو أن تساعدك النقاط التالية بالإضافة إلى المقارنة الفائتة في تحديد اختيارك بصورة ملائمة

الحالات التي يُفضل فيها استخدام بلوجر

• التدوين بشكل منقطع أو غير نظامي، بحيث تقوم بالتدوين بصورة غير رسمية وعلى فترات متباعدة.

• عدم الحاجة للعديد من المميزات والخصائص والتحكم داخل المدونة، أي أن ما يهمك هو نشر محتوى معين بعيداً عن خيارات التحكم الخاصة بالمدونة.

• خوض تجربة جديدة وشبه تجريبية في مجال التدوين، وبالتالي يمكنك استخدام منصة بلوجر لفترة معينة وتحديد خطواتك المقبلة اعتماداً على نتائج هذه الفترة.

• عدم امتلاك المعرفة اللازمة في الأمور التقنية والفنية المتعلقة بإدارة المدونة، ولا تريد تخصيص بعض الوقت للتعلم

• عدم الرغبة في إنفاق أي مبالغ مادية على المدونة

• اقتصار المدونة على مجال واحد فقط من مجالات التدوين.

الحالات التي يُفضل فيها استخدام وورد برس

• إنشاء مدونة شاملة ومتكاملة وتحتاج إلى العديد من إمكانيات التخصيص

• الرغبة في التحكم الكامل بالمدونة، والاحتفاظ بملكية محتويات المدونة بصورة تامة.

• العمل على المدونة بشكل تجاري، أي وجود نية لبيعها في مرحلة معينة

• المقدرة على التعامل الفعال مع منصة وورد برس ومعرفة بالأمور الفنية.

• المقدرة على دفع التكاليف الخاصة بالمدونة

• الحاجة لوجود خيارات واسعة لقالب المدونة والتصميم الخاص بها.

• التدوين المتواصل وطويل المدى ووجود رؤية مستقبلية لدى المدون.

الغالب أنّ البرامج المفتوحة المصادر تتطلّب شيئًا من التّهيئة المُملّة عند أوّل استعمال، وقد يبدو للوهلة الأولى أنّ تلك التّهيئة تؤخّرك عن غايتك، التي هي حلّ المشكلة باستخدام الأداة المعنيّة، إلّا أنّ عمليّة التّهيئة فرصةٌ حسنةٌ للتّعوّد على استخدام واحدةٍ من أهمّ أدوات المهنة: سطر الأوامر.

يصيب سطر الأوامر بطبيعته الرّهبة في قلوب كثير من النّاس، إذ يرونه (في عُرف المجتمع) تقنيّة غامضةً يمارسها سحرةُ الحاسوب و"المُخترقون". الحقيقة أنّه سطر الأوامر ليس بهذه الرّوعة، فما هو إلا مجموعة من الأدوات شديدة البساطة أنشأها موظّفو Bell (الّتي تُعرف الآن بالاسم AT&T) لإنجاز مهامّ معظمها بسيط في السّبعينيّات من القرن الماضي، وليس فيها من التّطوّر التّقنيّ أكثر ممّا في فرن المايكروويف في مطبخك!

ولكنّ سطر الأوامر مفيد جدًّا، وفائدته تُشبه استخدام الأدوات الكهربائيّة في العمارة بدلًا من استخدام الأيدي. يمكننا تعلّم أدقّ تفاصيله بالاستعانة ببعض المفاهيم والاستعارات اللّفظية.

ولعلّ واحدًا من أهمّ تلك المفاهيم هو مفهوم المسار (Path).

تعتمد أدوات التّطوير للمتصفّح ومُعالجات CSS ومكتبات JavaScript وأدوات أخرى كثيرة على وجود Ruby أو Node.js مثبّتتين على جهازك. من هذه الأدوات Bower. يجمع بين هذه الأدوات كلّها أنّها ستُضطرّك إلى التّعامل مع المسار عاجلًا أو آجلًا، والسّبب أنّ يجب على المسار أن يعلم بوجود الأدوات الّتي تثبّتها في بيئة التّطوير على جهازك حتّى يستطيع سطر الأوامر أن يعمل بصورة صحيحةٍ.

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

مُتغيّر صغير ومتواضع

‏‎$PATH‎، كما تُفصح إشارة الدولار في أوّله والحروف الكبيرة الّتي تتلوها، مُتغيّر في بيئة Unix. القيمة المحفوظة في هذا المتغيّر هي قائمةً بمسارات إلى أدلّة (مُجلّدات)، مفصولةٍ بنقطتين (:)، كهذه القائمة:

/root/directory/binary:/root/other_directory/other_binary

إن كنت من أولئك المهووسين بتسمية المُتغيّرات، فقد تتساءل لما لم يُسمَّ المُتغيّر ‎$PATHS‎ (بصيغة الجمع)، كونه يحوي عدّة مسارات. اسمحوا لي بأن أخمّن السبب تخمينًا، فلربّما يُشير الاسم المُفرد إلى "مسار التّحميل المُكوّن من عدّة مسارات منفردة"، يبدو تخمينًا معقولًا!

لو قادك فضولك إلى تحرّي أنواعٍ أخرى من متغيّرات البيئة في نظامك، فاكتب env في سطر الأوامر ثمّ اضغط Enter وسترى قائمة بكلّ متغيّرات البيئة الموجودة حاليًّا.

بما أنّ ‏‎$PATH‎ مُتغيّر، يمكننا تغييره كما نشاء، وفي أيّ وقت. يمكنك مثلًا كتابة هذا الأمر في الصّدفة (shell) لديك:

export PATH=banana

ما نتيجة هذا الأمر؟ جرّب تشغيله في نافذة جديدة داخل الطّرفيّة لديك أو في أي تطبيق صدفة تستخدمه، كبرنامج Terminal في OS X.

ثمّ جرّب بعد ذلك تنفيذ أي أمر Unix مثل ls (الّذي يطبع قائمة بمحتويات دليل/مُجلّد). ستكون النّتيجة: 

 ‎-bash: ls: command not found

‎ مع أنّ الأمر كان يعمل بلا مشكلات من قبل!

هذه الحيلة الشقيّة علّمتنا أنّ محتويات ‏‎$PATH‎ ضروريّة جدًّا، وإلّا اختلط الحابل بالنّابل!

ولكن لماذا؟ لأنّ المسار يُحدّد ما يمكن تنفيذه في الصّدفة، فإن لم تعثر الصّدفة على شيءٍ يطابق اسمه ما كتبته، فلن تستطيع تنفيذه، والفكرة نفسها مُطبّقة في عدّة لغات برمجة وأطر عمل للويب مثل Rails.

كدت أنسى! لتصحيح هذه المشكلة، أغلق برنامج الطّرفية وأعد فتحه، فالعطل مؤقّتٌ في حالتنا، ولكن إيّاك أن تحفظ القيمة الخاطئة في ملفّ ‎~/.bash_profile‎، فعندها سيكون الوضع سيئًا للغاية!

حكاية عن البرامج الثّنائيّة

تُدعى بعض البرامج القابلة للتنفيذ في Unix "ملفّات ثنائيّة (binaries)". لأكون صادقًا معك، هذا الاسم غير مناسب على الإطلاق، لأنّه يهتمّ بصيغة البرامج بدلًا من وظيفتها. عندما تكتب برنامج Unix يؤدّي مهمّة مُحدَّدة، فإنّك قد تحتاج إلى تجميعه (compile) قبل أن تتمكّن من تنفيذه، عمليّة التجميع هذه تُنتج ملفًّا ثنائيًّا (binary). تعتمد هذه الملفّات الصّيغة الثنائيّة لتمثيل التّعليمات بصورة يسهل تنفيذها على الحاسوب بدلًا من الملفّات النّصيّة البسيطة (كملفّات مصدر البرنامج source code).

في Unix مُجلّدات عديدة تُحفظ فيها هذه الملفّات الثّنائيّة، وبإمكانك معرفة المُجلّد الذي يُستخدم بصورة مبدئيّة لتحميل الملفّات الثّنائيّة في الملف ‎/etc/paths‎:

 # الأمر cat يطبع محتويات ملفّ
$ cat /etc/paths 
/usr/bin 
/bin 
/usr/sbin 
/sbin 
/usr/local/bin

في كلّ سطر من الملف دليل واحدٌ. وقد رُتّبت المسارات بأسلوب مدروس، فإذا وجد ملفّ ثنائيّ في مسارٍ منها، حُمِّل، وإن وجد ملفّ آخر بالاسم نفسه في مسار آخر، لم يُنظر إليه. أي إنّ المسارات المُرتّبة في أعلى القائمة ذات أولويّة أكبر من تلك الّتي تقع أدناها.

هذا هو سبب المشكلات الّتي تواجهها عندما تُحاول تثبيت برنامجٍ جديد موجودٍ مسبقًا على نظامك، كما في حالة تثبيت إصدارة جديدةٍ من Git على OS X بدل تلك المُرفقة مع النّظام. هذا أمرٌ سيّئ لأنّ Git 2.0 ممتاز!

عندما أستعمل cd (الّذي يُغيّر الدّليل الحاليّ) للانتقال إلى ‎/usr/bin‎ (وهو مُجلّد يشيع تخزين البرامج فيه) ثمّ أستعمل ls، فإنّنى أرى أكثر من ألف نتيجة! وهذا أمرٌ غير مُفيد، ولذا أستعمل grep ضمن الأمر ls | grep git لأُصفِّيَ النّتائج بحيث تقتصر على البرامج تحوي الكلمة "git":

$ ls | grep git 
git
git-cvsserver
git-receive-pack
git-shell 
git-upload-archive 
git-upload-pack

كما ترى، هناك نسخة من Git في ‎/usr/bin‎، وعند تثبيت نسخة نظيفة من OS X فستكون هذه النّسخة هي المُعتمدة، كما يُبيّن تنفيذ الأمر which git.

$ which git 
/usr/local/bin/git

مهلًا! لماذا تُخالف النّتيجة لديّ ما توقّعته؟ لنفحص الأمر بدقّة بإرفاق which بالخيار ‎-a‎:

$ which -a git
/usr/bin/git
/usr/local/bin/git

هذا يؤكّد وجود نسختين من Git مثبّتتين على نظامي، ولكنّ الأولى هي المُعتمدة عندما أُنفّذ أوامر git في سطر الأوامر.

تغيير المسارات

قرّرت تثبيت إصدارٍ مُختلف من Git على نظامي مُستخدمًا مُدير حزم اسمه Homebrew لأنّني أحبّ أن أُسيطر على الأدوات الّتي أستخدمها كلّ يوم وأحدّثها وقتما أشاء. كان بإمكاني تحديث نسخة Git المُرفقَة مع النّظام، لكنّني لا أعلم إن كان هذا سيُعطِب البرامج الّتي تعتمد على وجودها.

نعلم إذن أنّ البحث عن البرامج يتبع ترتيب القائمة في الملفّ ‎/etc/paths‎، فلم لا نُغيّر هذا التّرتيب؟

أرى أن المُجلّد ‎/usr/local/bin‎ الّذي يحوي إصدار Git الّذي ثبّته Homebrew يقع في نهاية الملفّ ‎/etc/paths‎، وهذا يعني أن برنامج git في ‎/usr/bin‎ يطغى على الإصدار الّذي أريده.

بالطّبع لا شيء يمنعك من تغيير التّرتيب في الملفّ ‎/etc/paths‎ بحيث تضع ‎/usr/local/bin‎ في أعلى القائمة لتُعتمد نسخة Git من Homebrew، وستصادف هذه النّصيحة كثيرًا على Stack Overflow، لكن صدّقني... هذا أمرٌ بالغ السوء، لا تفعله! لم يُقصد من هذه الملفّات أن يُعدّلها مستخدمٌ منفردٌ لأنّه تؤثّر على كلّ النظام (حتّى وإن كنت الوحيد الّذي تستعمل الحاسوب)، وقد يسبب هذا التّغيير مشكلات لن تُدرك أسبابها في المستقبل، فقد تعتمد إحدى الأدوات في OS X على التّرتيب الأصليّ للملفّ ‎/etc/paths‎.

بدلًا من ذلك، عدّل المُتغيّر ‏‎$PATH‎ في بيئتك أنت، في نسختك أنت من الملفّ ‎.bash_profile‎، الموجودة في ‎/Users/yourusername/.bash_profile‎.

ما عليك إلّا أن تجعل البحث يُجرى في ‎/usr/local/bin‎ أوّلًا في الملفّ ‎.bash_profile‎:

# في الملفّ /Users/olivierlacan/.bash_profile
export PATH=/usr/local/bin:$PATH

وهذا يؤدّي إلى تصدير مُتغيّر البيئة ‎$PATH‎ الجديد وذلك بطباعة المُتغيّر الحاليّ وإسباقه بـ ‎/usr/local/bin‎ على يسار كلّ المسارات الأخرى. بعد حفظ الملفّ ‎~/.bash_profile‎، وإعادة تشغيل الصّدفة، يُفترض أن ترى هذه النّتيجة عند استدعاء echo على المُتغيّر:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

لاحظ أنّ ‎/usr/local/bin‎ مذكور مرّتين في المتغيّر ‎$PATH‎ ولا بأس في هذا. ولأنّه ذُكر أوّلًا، فكلّ البرامج الّتي تُحمّل منه في المّرة الأولى ستُتجاهَل عند الوصول إليه ثانيةً. كنت أتمنّى وجود طريقة آمنة وبسيطة لتغيير ترتيب المسارات، ولكنّ الحلول الّتي أعرفها شديدة التّعقيد. بإمكانك دومًا تجاوز القيمة المبدئيّة لـ‎$PATH‎ بالكامل، ولكن فقط عندما تُدرك تمامًا ما الّذي تفعله وأيّ المسارات يجب تضمينها.

على مفترق المسارات

بعد أن عدّلت المسار ‎$PATH‎ كما يحلو لك، بإمكانك التأكّد من أنّ البرنامج المرغوب يُستدعى عندما تُنفّذ الأمر git:

$ which git 
/usr/local/bin/git 

$ git --version 
git version 2.0.0
/usr/bin/git --version git version 1.8.5.2 (Apple Git-48)

عظيم! الإصدارة 2.0.0 من Git هي الّذي يتلقّى أوامر git (وهي الإصدارة الّتي ثبّتها Homebrew)، بينما تغيب الإصدارة 1.8.5.2 المُرفقة مع النّظام. إن قرّرت ألّا تستخدم الإصدارة 2.0.0 بعد الآن، ليس عليك سوى إزالتها وستعود الإصدارة الأقدم للعمل بصورة انسيابيّة.

احمِ مسارك

تُضيف أدوات تطوير (وتصميم) كثيرة أوامر برمجيّة إلى الملفّ ‎.bash_profile‎ بعد تثبيتها، والغالب أنّها لا تخبرك بذلك، فإن وجدت مسارات غريبة مُدرجةً في الملفّ، فقد يُفسّر ذلك بطء تحميل جلسة جديدة كلّ مرّة (الأمر الّذي يحدث عند فتح صدفة جديدة أو لسان جديد في الطّرفيّة): مُتغيّر ‎$PATH‎ طويل، يتطلّب وقتًا طويلًا لتحميله.

إليكم مساري اليوم:

/Users/olivierlacan/.rbenv/shims:/Users/olivierlacan/.rbenv/bin:/usr/local/bin:/usr/local/heroku/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/MacGPG2/bin

تصعب قراءته قليلًا، لذا أُفضّل تجزئته على سطور باستخدام الأمر tr (الّذي يستبدل حروفًا مُحدّدة):

$ echo $PATH | tr ':' '\n'
/Users/olivierlacan/.rbenv/shims
/Users/olivierlacan/.rbenv/bin
/usr/local/bin
/usr/local/heroku/bin
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
/opt/X11/bin
/usr/local/MacGPG2/bin

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

قد لا تبدو فائدة تعلّم ‎$PATH‎ وكيفيّة عمله عظيمةً. ولكن لأنك مُطوِّر ويب، فستحتاج إلى التّعامل مع سطر الأوامر، وقد تتعطّل إحدى أدواتك يومًا، والآن وقد تعلّمت مسارك وكيف يبدو وهو نظيف، والأسلوب الصّحيح لتعديله، وكيف تتأكّد من أنّه يعلم بوجود برامجك، فإنّ عودتك إلى "مسارك" المهنيّ ستستغرق دقائق بدلًا من ساعات!

ترجمة (بتصرّف) لمقال The $PATH to Enlightement لصاحبه Oliver Lacan

حين يسألني أحدهم عن كيف يصبح مبرمجا وما هي المصادر التي يجب أن يعتمد عليها وما الخطوات التي يجب إتباعها، فإن الجواب المناسب الوحيد، والذي لم أقله بعد لأحد، هو ”إذا كنت تملك ما يؤهلك لأن تكون مبرمجا فإنك ستعرف طريقك بنفسك“. السبب هو أن البرمجة فن كما أنها علم. من منطلق أنها فن فهي تتطلب حدا أدنى من الموهبة وليس فقط الاكتفاء بحفظ القواعد، ومن حيث أنها علم فهي مبنية أساسا على المنطق وبصفة عامة على الرياضيات، التي تعتبر كابوسا لدى الطالب العربي. حين تملك الموهبة لتبدع بالبرمجة وحين تملك الإستعداد العقلي للتعامل مع النصوص البرمجية المجردة، فإنك آنذاك لن تحتاج لطرح السؤال السابق.

الخلاصة.. إذا لم تكن قادرا على: الاستمتاع بالبرمجة وتذوقها كتذوق الشعر، التفكير المنطقي المجرد، وإيجاد الإبرة المناسبة بين كومة من الإبر، فلا تضيع وقتك في تعلم البرمجة، لأنك لن تتعلمها ولأنها لا تناسبك.

إذا كنت ترى نفسك صالحا لتكون مبرمجا فلدي لك نصيحتان لا غير: (1) ابحث بنفسك، ستجد الكثير من المصادر المتنوعة وكثيرا من الآراء المتناقضة، وحدك ستكون قادرا على اختيار ما يناسبك. (2) النصيحة الثانية هي تمرن دائما. أول خطوة لكي تنطلق في تعلم البرمجة هي البدء فورا في البرمجة. لا يهم ماذا ستبرمج ولا كم الأخطاء التي سترتكب. المران المتواصل هو وحده الكفيل بتحسين قدراتك. سيكون من الجيد أيضا ألا تكتفي بالتمرن وحيدا، ثمة آلاف البرامج الحرة المتاحة للتطوير لمن يشاء. جرب أن تدلي بدلوك وأضف تعديلاتك على تلك البرامج. ستُرفض بعض التعديلات وستواجه الكثير من الانتقادات اللاذعة، لكنك تباعا ستحسن من جودة النصوص البرمجية التي تكتب، إلى أن تصبح محترفا فخبيرا.

كيف تعلمت أنا البرمجة؟

ملاحظة أولية: لا أعتبر نفسي مبرمجا بعد، لكني على الأقل أعرف الأساسيات التي تتيح لي برمجة مشاريعي الخاصة.

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

أول ما تعلمته كان HTML&CSS، (أعتقد سنة 2000). الطريف أنني تعلمتهما بالإسبانية خلال ورشة نظمها طلبة إسبان في المدينة (هناك سمعت أول مرة بجوجل). لم أكن أعرف من الإسبانية إلا بضع كلمات مما دخل العامية المغربية ومما تشابه مع كلمات فرنسية. لكني قبل ذلك كنت قرأت بعض المعلومات المتفرقة حول HTML في مجلات عربية وفرنسية.

بعد ذلك كانت لي بضع محاولات مع جافاسكريبت، لكن المشكلة آنذاك أن جافاسكريبت لم تكن تستخدم كلغة حقيقية كما الآن، بل فقط بغرض تزيين الصفحات ببعض الحركات الديناميكية، لذلك لم أتعلم منها الكثير.

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

أفضل المصادر التي صادفتها خلال مسيرتي البطيئة في تعلم البرمجة:

• جوجل: محرك بحث لا غنى عنه في أي مرحلة. دائما عد إليه لتجد حلول المشاكل التي تصادفها.
• stackoverflow: موقع مهم جدا للمبرمجين. يمكنك أن تجد فيه حلولا تقريبا لكل المشاكل التي قد تصادفها، ويمكنك أن تطرح أسئلتك وتتواصل مع المبرمجين المحترفين.
• تعلم لغة PHP: مرجع عربي شامل لكل ما تحتاجه لتعلم php من الصفر. أفضل الدروس والمقالات والنصائح والكتب والعديد من المصادر المتنوعة لتعلم لغة php تجدها في مكان واحد.
• PHP 5 Power Programming: كتاب مهم جدا، لا يعيبه سوى أنه لم يحدث منذ سنة 2004، وهي فترة طويلة عرفت خلالها اللغة الكثير من التحديثات.
• smashingmagazine: موقع شهير لا غنى عنه لأي مصمم. يتابع أيضا الجديد في HTML&CSS وجافاسكريبت.
• Beginning Ruby: أفضل كتاب لشرح أساسيات روبي. هو صالح أيضا حتى لمستخدمي اللغات الأخرى بحكم أساسيات البرمجة التي يتطرق لها. في نفس السياق، وجدت أن الإطلاع على إطار العمل RubyOnRails مهم جدا للحصول على أفكار جديدة وأساليب مختلفة في البرمجة يمكن الاستفادة منها عند استخدام لغات برمجة أخرى. شخصيا تغير أسلوب استخدامي لـ PHP تماما بعد أن بدأت في استخدام ريلز.