عبدالرحيم فاخوري

الأعضاء
  • المساهمات

    22
  • تاريخ الانضمام

  • تاريخ آخر زيارة

السُّمعة بالموقع

20 Excellent

2 متابعين

  1. هذا الجزء الثاني من سلسلة من جزأين تتحدث عن الحوسبة السحابيّة. نرجو أن تكون قرأت موضوع تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة قبل قراءة هذا المقال، إذ يحوي المقال السابق معلومات مهمة، وشرحًا للمصطلحات المستخدمة في هذا الموضوع. ينقسم هذا المقال إلى قسمين، يناقش القسم الأول عيوب الحوسبة السحابيّة والمشكلات التي يمكن أن تواجهها، ويعدّ مقدّمة للقسم الثاني. أما القسم الثاني، فيتحّدث عن الانتقال إلى الحوسبة السحابيّة والمزايا والعيوب وسيساعدك على تجهيز خطّة للانتقال الأمثل، بحيث تستفيد من المزايا وتتجنب المساوئ في الانتقال. مقدمة إذا كنت ترغب في تقديم خدمات رقميّة أيًّا كان نوعها، فعليك تقدير كلّ أنواع الموارد، بما في ذلك المعالج والذاكرة والتخزين والشبكة. إن اختيار أيّ الموارد ستستخدم لتقديم تلك الخدمات - سواء سحابيّة أو محليّة - عائد لك. ولكنّك ستحتاج بكل تأكيد للبحث والتخطيط. ستحتاج إلى فهم مزايا وعيوب الحوسبة السحابيّة وكيف تأخذ نقاط ضعفها في الحسبان. لقد أفادت الخدمات السحابية العديد من المؤسسات، وذلك بتقليل التكاليف، وتمكينها من التركيز على الجانب المتعلّق بالأعمال الخاصّة بها، بدلًا من القضايا المتعلّقة بتقنيّة المعلومات والبنية التحتيّة لها. وعلى الرغم من الكثرة الحديث عن أهميتها في الأوساط التقنيّة، إلّا أنّها قد لا تخلو من العيوب، وخاصّة في الأعمال الصغيرة. لدى معظم الشركات حمل واحد على الأقل يعمل في نظام حوسبة سحابية. رغم هذا، فالانتقال إلى الحوسبة السحابيّة قد لا يكون الخيار الصحيح للجميع. وعلى الرغم من أنّ البيئات السحابيّة عامّة تكون قابلة للتوسعة، ويعتمد عليها، ومتاحة دائمًا، يجب أن لا تدع هذه النواحي وحدها تقود قراراتك. بالنسبة للشركات التي تبحث في الانتقال إلى الحوسبة السحابيّة لأوّل مرّة، فهناك الكثير من النواحي التي يجب أخذها بعين الاعتبار؛ مثل الفوائد والمخاطر التي يتضمّنها كل نوع من أنواع الحوسبة السحابيّة المناسبة لشركتك. سنناقش هنا العناصر الأساسيّة التي عليك أخذها بعين الاعتبار عندما تفكّر بالانتقال إلى الحوسبة السحابيّة. سنتحدث عن بعض العيوب الرئيسيّة، وسنعرض بعض النصائح والطرق السليمة لاستخدامها والتي من الممكن أن تستخدمها الفرق التقنية للتعامل مع تلك العيوب. يمكنك صياغة نمط محدّد لهذه العمليّة، وذلك باستخدام توجُّه مُفصَّل ومجهًَز مُسبقًا لفهم أمن الحوسبة السحابيّة. بالنسبة للشركات التي تبحث في الانتقال إلى الحوسبة السحابيّة لأوّل مرّة، فهناك الكثير من النواحي التي يجب أخذها بعين الاعتبار؛ كالفوائد والمخاطر التي يتضمّنها كل نوع من أنواع الحوسبة السحابيّة المناسبة لشركتك. سنناقش في هذا المقال العناصر الأساسيّة التي عليك أخذها بعين الاعتبار عندما تفكّر بالانتقال إلى الحوسبة السحابيّة. توضيح عيوب الحوسبة السحابيّة 1. انقطاع الخِدمة يُعدّ انقطاع الخدمة (downtime) أحد أهمّ عيوب الحوسبة السحابيّة. بما أن أنظمة الحوسبة السحابيّة تعتمد على الإنترنت، فيحتمل حدوث انقطاع في الخدمة في أيّ وقت، ويمكن أن يحدث لأيّ سبب كان. هل يمكن لشركتك أن تتحمل انقطاع الخدمة أو بطئها؟ لقد كلّف انقطاع خدمة الحوسبة السحابيّة التابعة لأمازون (AWS) عام 2017 شركات مساهمة عامّة أكثر من 150 مليون دولار أمريكيّ. للأسف، لا توجد شركة آمنة من هذا، وخاصّة بالنسبة للأعمال الحسّاسة التي لا تتحمل أن تنقطع. في شهري حزيران وتمّوز (5 و6) من عام 2019، تعرّض عدد كبير من الشركات لانقطاع في الخدمة، بما في ذلك Cloudflare (وهو مزوّد خدمة مهمّ لمواقع الإنترنت)، وGoogle، وAmazon، وShopify، وReddit، وVerizon، وSpectrum. أفضل الممارسات لتقليل انقطاع الخدمة المخطط له في بيئة الحوسبة السحابيّة تصميم خدمات متاحة باستمرار مع أخذ الاسترجاع من الكوارث بعين الاعتبار. استفِد من ميزة تعدّد المناطق (multi-availability zones) التي يتيحها مزودو الخدمة السحابيّة في البنية التحتيّة لديك. إذا كانت خدماتك لا تتحمّل انقطاع الخدمة، فخذ بعين الاعتبار نشر خدمتك في عدّة مناطق، مع تدارك آليّ للانقطاعات لتتجنّب انقطاع الخِدمة قدر الإمكان. حدِّد ونفِّذ خطّة للاسترجاع من الكوارث تتوافق مع أهداف مؤسستك لتقليل وقت الاسترجاع من الكوارث قدر الإمكان (RTO) وأهداف نقطة الاستعادة (RPO). خذ بعين الاعتبار تنفيذ خدمة اتصال مخصّصة مثل AWS Direct Connect أو Azure ExpressRoute أو Dedicated Interconnect أو Partner Interconnect. تقدّم هذه الخدمات اتصال شبكة مخصّص بينك وبين مكان وجود الخدمة السحابيّة. يمكن أن يقلِّل هذا من العرضة إلى خطر انقطاع الخدمة المؤقت الذي قد تسببه الإنترنت. اقرأ تفاصيل اتفاقيّة الخدمة (Service Level Agreement - SLA). هل تضمن لك أن تكون الخدمة متاحة 99.9% من الوقت أو حتى أكثر من ذلك؟ هذا الانقطاع الذي يشكِّل 0.1% يساوي 45 دقيقة شهريًّا أو حوالي ثماني ساعات في العام. 2. الأمن والخصوصيّة على الرغم من إنّ مزودي الخدمة ينفذون أفضل معايير الأمن والإجراءات التي يتطلّبها المجال، إلّا أنّ تخزين البيانات والملفات المهمّة عند مزوّدي خدمة خارجيّين يفتح دائمًا المجال للمخاطرة. يجب أن تغطّي أيّ محادثة تتعلّق بالبياناتِ الأمنَ والخصوصيّةَ، وخاصّة عندما يتعلّق الأمر بإدارة البيانات الحسّاسة. يجب أن لاننسى ما حدث لـCode Space واختراق لوحة تحكّمهم على AWS، والذي أدى إلى حذف بياناتهم مما تسبب في أغلاق الشركة. إن اعتمادهم على بنية تحتيّة بعيدة معتمدة على الخدمات السحابيّة يعني المخاطرة بجعل كلّ ما يتعلّق بهم لدى شركة أخرى. إن كلّ مزود خدمة سحابيّة يتوقّع منه إدارة وتأمين البنية التحتيّة العتاديّة التي تقوم عليها الخدمة. وعلى الرغم من ذلك، تقع على عاتقك مسؤوليّة إدارة وصول المستخدمين، ولهذا عليك أن توازن بحذر كلّ حالات الخطر المحتملة. وعلى الرغم من أن الاختراقات التي كشفت معلومات بطاقات بنكيّة ومعلومات الدخول إلى حسابات على الإنترنت لا تزال جليّة في أذهان العامّة، إلّا أنه قد تم اتخاذ إجراءات لتأمين البيانات؟ ومن الأمثلة على هذه الإجراءات القانون العامّ لتأمين البيانات ( General Data Protection Rule - DGPR )، والذي تم سنّه في الاتحاد الأوروبيّ لإعطاء المستخدمين قدرة اكبر على التحكّم ببياناتهم. وعلى الرغم من ذلك، ما زلت بحاجة إلى معرفة المسؤوليات التي تقع على عاتقك، وأن تتّبع أفضل الممارسات المتعلّقة بهذا الشأن. أفضل الممارسات لتقليل مخاطر الأمن والخصوصيّة هذه النقطة مهمّة: افهم نموذج التشارك في المسؤوليّة لدى مزوّد خدمة الحوسبة السحابية الذي تتعامل معه. ستتحمل أنت مسؤولية ما يحدث في داخل شبكتك ومنتجك. نفّذ الإجراءات الأمنيّة في كلّ مستوى من مستويات خدمتك. اعرف من المفترض أن يكون لديه وصول لكل مورِد وخدمة، وقيّد الوصول قدر الإمكان. إذا خان أحد الموظفين الأمانة (أو أخطأ في أمر ما) وكان لديه وصول إلى الخدمة التي تقدّمها، فسترغب بأن تكون الأضرار في أضيق إطار ممكن. تأكّد من أنّ مهارات فريقك ترقى إلى المستوى المطلوب. إن مقال أهم عشرة أشياء يجب على المختصّين في الأمن الإلكترونيّ معرفتها ممتاز لفهم طريقة تجنب المشكلات المتعلّقة بالأمن والخصوصيّة في الحوسبة السحابيّة. اعتمد توجّها مبنيًّا على تقييم المخاطر من أجل تأمين الموارد التي في النظام السحابيّ واجعل سياسة الأمن تشمل الأجهزة. استخدم نظام استيثاق متعدد الجوانب لكل الحسابات التي تصل إلى البيانات الهامّة في النظام. عليك بالتشفير والتعميّة، ثم عليك بالتشفير والتعمية. فعّل التشفير أينما استطعت. الأهداف السهلة للّصوص هي أماكن تخزين الأشياء، وهذا ينطبق على الحوسبة السحابيّة؛ مكان تخزين البيانات مثل Amazon S3 أو Azure Blob Storage هي أماكن تخزين معلومات الزبائن، وهي هدف مهم للمخترقين. إنّ مجرّد تفعيل التشفير على S3 كان سيكفي لمنع الاختراق الذي حصل في شهر تمّوز عام 2019 - لو أنه استُخدِم - والذي كشف بيانات مئة مليون شخص. 3. التعرّض للهجوم إنّ جميع مكونات الحوسبة السحابيّة متّصلة بالإنترنت، مما يجعلها معرّضة للاختراق في حال وجود ثغرات لم يعرف عنها الفريق المسؤول عن النظام أو لم يغلقها؛ بل إنّ أفضل الفرق تعاني من هجمات واختراقات أمنيّة من وقت لآخر. وبما أنّ الحوسبة السحابيّة مبنيّة كخدمة عامّة، فستجد البعض بدأ الركض قبل أن يتعلّم المشي، إذا صحّ التعبير. فعلى أيّ حال، لا أحد من مزودي الخدمات السحابيّة يختبر مدى براعتك في إدارة النظام قبل أن يعطيك خادمًا لتديره: كل ما يُطلب منك هو أن تدفع لاستخدام الخدمة وحسب. أفضل الممارسات للمساعدة في تقليل الهجمات الإلكترونيّة على الخدمة السحابيّة اجعل الأمن محورًا مهمًا لجميع العمليات التقنيّة. ابقِ جميع الفرق التي تعمل معك على اطّلاع على كلّ ما يتعلّق بأفضل الممارسات لأمن الحوسبة السحابية أولًا بأوّل. تأكّد من تفقُّد ومراجعة السياسات والإجراءات الأمنيّة باستمرار. أمِّن سرّيّة المعلومات وقيّد الوصول إليها لتتجنب المشكلة قبل حدوثها. استخدم الخدمات السحابيّة مثل AWS Inspector، وAWS CloudWatch، وAWS CloudTrail، وAWS Config لجعل التحكّم بالالتزام تلقائيًّا. اكتشف المشاريع والاختبارات الخارجة عن أهداف المؤسسة. امنع الدخول باستخدام كلمة المرور عن الحسابات التي لا تحتاج الولوج إلى النظام. غيِّر مفاتيح الوصول وكلمات المرور باستمرار. تابع المدونات والمواقع المتعلّقة بأمن المعلومات وما تعلن عنه لتكون على دراية بالهجمات المعروفة. طبّق أفضل ممارسات الأمن للبرمجيات مفتوحة المصدر التي تستخدمها. نكرر، استخدم التشفير كلّما أمكن وأينما أمكن. ستساعد هذه الممارساتِ المؤسّسةَ على مراقبة حركة البيانات الهامّة ومدى عرضتها للمشكلات الأمنيّة، وستساعدها كذلك على حماية الأنظمة الهامّة من الهجمات والاختراقات، وعلى استيثاق الوصول إلى البنية التحتيّة والبيانات، وذلك من أجل الحماية من المخاطر الإضافيّة المحتملة. 4. الوصول المحدود والمرونة بما أنّ البنية التحتيّة المعتمدة على الحوسبة السحابيّة بأكملها مملوكة ومدارة ومراقبة من مزوّد خدمة الحوسبة السحابيّة، فهي تبقي القليل فقط من التحكّم في يد الزبون. قد يجد مستخدمو الحوسبة السحابيّة أنّ التحكمَ الذي لديهم في الوظائف والتنفيذ للخدمات في البنية التحتية المستضافة سحابيًّا محدودٌ، وذلك بدرجات متفاوتة، حسب الخدمة التي يقدّمونها. قد تقيّد اتفاقية استخدام الخدمة السحابيّة والسياسات الإداريّة ما يمكن للزبائن فعله بتطبيقاتهم. يحتفظ الزبائن بحقّ التحكّم بتطبيقاتهم وبياناتهم وخدماتهم، ولكن قد لا يكون لديهم نفس القدر من التحكم فيما يتعلّق بالبنية التحتيّة للنظام الخلفيّ وبما يجري خلف الكواليس. أفضل الممارسات لضمان قدرٍ من التحكّم والمرونة خذ بعين الاعتبار الاستفادة من شريك يقدّم خدمة الحوسبة السحابيّة ليساعدك على تنفيذ وتشغيل ودعم خدمات الحوسبة السحابيّة. افهم مسؤوليّاتك ومسؤوليّات مقدّم الخدمة السحابيّة في نموذج المسؤوليّة المشتركة، وذلك من أجل الحدّ من التنصّل من المسؤوليّة وكذلك للحدّ من الأخطاء المحتملة. خذ الوقت الكافي لفهم مستوى الدّعم الأساسيّ الذي يقدّمه مزوّد الخدمات السحابيّة الذي تتعامل معه. هل يفي هذا المستوى من الخدمة بمتطلّباتك؟ يقدّم مزودو خدمة الحوسبة السحابيّة دعمًا إضافيًّا فوق الدعم الأساسيّ مقابل تكلفة إضافيّة. تأكّد من فهمك لاتفاقيّة مستوى الخدمة (Service Level Agreement - SLA) المتعلّقة بالبنية التحتيّة والخدمات التي ستستخدمها وكيف ستؤثّر الاتفاقيّة على زبائنك. 5. البقاء عالقًا عند مزوّد معيّن من العيوب التي تُأخذ بالحُسبان عند التعامل مع الحوسبة السحابيّة هي احتمال أن تبقى عالقًا عند مزوّد خدمة سحابيّة معيّن. إن الانتقال بسهولة بين مزودي الخدمة السحابيّة لم يصل إلى المستوى المطلوب من التطور، وقد تجد المؤسسات صعوبة في نقل خدماتها من مزوّد خدمة إلى آخَر.قد تنشأ صعوبات نتيجة للاختلاف بين مزودي الخدمة مما قد يتسبب بتكاليف إضافيّة وتعقيدات في الإعداد. إنّ الفجوات التي يمكن أن يتسبب بها الانتقال من مزوّد إلى آخر من شأنها أن تؤدي إلى تعريض أمن وخصوصيّة البيانات إلى الخطر. أفضل الممارسات لتقليل الاعتماد على مزوّد الخدمة صمِّم نظامك بما يتوافق مع أفضل ممارسات هندسة الحوسبة السحابيّة. تتيح كلّ خدمات الحوسبة السحابيّة فرصًا لتحسين الإتاحة والأداء، وفصل الطبقات المختلفة، والحدّ من عنق الزجاجة في الأداء. إذا بنيت خدماتك بما يتوافق مع أفضل ممارسات هندسة الحوسبة السحابيّة، فسيقل احتمال أن تواجه مشكلات تتعلق بالانتقال من منصّة حوسبة سحابيّة إلى أخرى. افهم جيدًا ما يسوّقه لك مزودو الخدمة لتتجنّب أن تعلق عندهم. طبّق استراتيجيّة تعدد السحابات لتجنب أن تعلق عند مزود خدمة معيّن. على الرغم من أن هذا قد يتسبب بتعقيدات في كلّ من التطوير والتشغيل، إلّا أنها لن تكون بالضرورة معقدة لدرجة أن تثنيك عن ذلك. يمكن تدريب الفرق لتكون مستعدّة لهندسة واختيار أكثر التقنيات والخدمات اتساقًا مع احتياجاتك. اتبع سياسة المرونة المضمّنة عندما تصمِّم تطبيقات، وذلك من أجل جعلها قابلة للنقل في أيّ وقت. ابن تطبيقاتك مستخدمًا الخدمات التي تقدّم ميزة الاستفادة من مزايا الحوسبة السحابيّة كإحدى أولويّاتها، كأن تتكون من برمجيّات وخدمات مصغّرة ومجزّأة وقابلة للنقل. فكّر باستخدام الحاويات وKubernetes. 6. القلق من ارتفاع الكلفة يمكن أن يُنظَر إلى اعتماد حلول الحوسبة السحابيّة على نطاق ضيّق ولمشاريع قصيرة الأمد على أنّها مكلفة. رغم هذا، تنبع أهمّ فوائد الحوسبة السحابيّة من إمكانيّة خفض التكلفة. يمكن أن تقدِّم خدمات الدفع حسب الاستخدام مرونة أكثر وتكلفة عتاد أقلّ، ولكن قد ينتهي المطاف بفاتورة عليها رقم أكبر من المتوقّع. إلى أن تتأكّد من ما يناسبك، يُنصَح بأن تجرّب عددًا من العروض. يمكنك أيضًا استخدام حاسبة التكلفة التي يقدّمها مزودو الخدمة، مثل AWS و Google Cloud Platform. أفضل الممارسات لخفض التكلفة حاول أن لا تحدّد مدى استخدام خدماتك، بل ابحث عن الخدمات المتغيّرة ذاتيًّا حسب الاستخدام. تأكّد من إمكانيّة تقليل مواصفات الخدمة بقدر إمكانيّة زيادتها. ادفع مسبقًا واستفد من الخدمات المحجوزة إذا كنت تعلم الحدّ الأدنى لاستخدامك. اضبط خدماتك لتبدأ وتتوقّف آليًّا لتوفير المال عندما لا تستخدمها. أنشئ تنبيهات لتتبّع نفقات الحوسبة السحابيّة. الفوائد المحتملة للانتقال إلى الحوسبة السحابيّة العديد من المشاكل يمكن حلّها بالانتقال إلى الحوسبة السحابيّة. فيما يلي بعض الحالات التي يمكن أن تستفيد فيها من الانتقال. يواجه تطبيقك ازديادًا في كميّة البيانات المارّة فيه، مما يصعّب زيادة الموارد لحظيًّا لتناسب الطلب. تحتاج إلى تقليل التكلفة التشغيليّة بينما تزيد كفاءة تقنية المعلومات. يتطلب زبونك تنفيذًا ونشرًا سريعين للتطبيق، ولهذا يريد تطويرًا أكثر وتقليلًا للتأخير الذي قد ينشأ من البنية التحتيّة. يريد زبائنك توسيع أعمالهم جغرافيًّا، ولكنك تعتقد بأن تجهيز بنية تحتيّة متعدّدة الأقاليم سيكون تحدّيًا كبيرًا، وذلك لما فيه من مجهود متعلّق بالإدارة والوقت والكوادر البشريّة والسيطرة على الأخطاء. مواكبة النمو المتزايد للاحتياج إلى تخزين البيانات صارت أكثر صعوبة وتكلفة. تحتاج إلى بناء فريق تطوير موزّع جغافيًّا. تسمح بيئة الحوسبة السحابيّة للموظفين البعيدين الوصول إلى التطبيقات واستخدامها عبر الإنترنت. تحتاج إلى تأسيس نظام استرجاع من الكوارث ولكن تجهيزه لمركز بيانات بأكمله قد يضاعف التكلفة، وسيحتاج أيضًا إلى خطة معقّدة للاسترجاع من الكوارث. يمكن تطبيق أنظمة الاسترجاع من الكوارث المعتمدة على الحوسبة السحابيّة أسرع، وستعطيك تحكّمًا أفضل بكثير بالموارد التي لديك. تتبُّع وتطوير البرمجيات التي يحويها الخادم يأخذ وقتًا، ولكنه مهم، ويحتاج إلى تطوير دوريّ وأحيانًا فوريّ, سيهتم مزود خدمة الحوسبة السحابيّة بهذا الأمر في بعض الأحيان تلقائيًّا. وكذلك، تهتم بعض نماذج الحوسبة السحابية ببعض الأمور الإدارية كالنسخ الاحتياطيّ لقواعد البيانات وتحديث البرمجيّات والصيانة الدوريّة. تكلفة رأس المال والتكاليف التشغيليّة: تحوِّل الحوسبةُ السحابيّةُ تقنيةَ المعلوماتِ إلى نموذج الدفع مقابل الاستخدام، وهي ميزة مغريةٌ وخاصّةً للشركات الناشئة. المخاطر المحتملة نتيجة الانتقال إلى الحوسبة السحابيّة رغم أن المخاطر التي تنطبق على كلّ حالة تعتمد كثيرًا على طبيعة البيئة المراد نقلها، إلّا انّ هناك عيوب عامّة تتعلق بالانتقال إلى الحوسبة السحابيّة التي عليك أخذها بعين الاعتبار. إذا كان تطبيقك يخزّن ويسترجع بيانات حسّاسة جدًّا، فقد لا تتمكن من إبقائها في النظام السحابيّ. وكذلك قد تحُدّ متطلّبات التوافق خياراتك. إذا كان الإعداد الموجود لديك من قبل يفي باحتياجاتك، ولا يحتاج الكثير من الصيانة والتحجيم والإتاحة، وكان جميع زبائنك راضين عنه، فلِمَ تعبث به؟ إذا كانت بعض التقنيات التي تعتمد عليها حاليًّا مملوكة، فقد لا يُسمَح لك قانونًا بنشرها على نظام سحابيّ. قد تعاني بعض العمليات من تأخير إضافيّ عند استخدام تطبيقات سحابيّة عبر الإنترنت. إذا كان العتاد بين يدي شخص آخر أو جهة أخرى، فقد تخسر الشفافية والتحكم اللازمين لتتبع مشاكل الأداء. قد يسبب "الجيران" في بعض الأحيان "إزعاجًا" عبر الموارد المشتركة (الإنترنت). قد لا يتبع تتصميم ومعمارية تطبيقك معمارية الحوسبة السحابيّة الموزّعة، ولهذا قد يتطلّب بعض التعديلات قبل نقلها إلى الحوسبة السحابيّة. البقاء عالقًا عند مزود خدمة سحابيّة معيّن: قد يكون من الصعب المغادرة أو الانتقال إلى منصّة سحابيّة أخرى بمجرد أن تبدأ باستخدام بيئة سحابيّة معيّنة. انقطاع الخدمة: يحدث هذا للجميع، ولكنك قد لا ترغب بأن تكون الأمور بيد شخص آخر. باتّباع هذا الأسلوب في التفكير، إذا كنت تفكّر بنقل أعمالك إلى الحوسبة السحابيّة، فقد تسأل نفسك عن العثرات الشائعة التي يمكن أن تواجهها عند النقل. ما نموذج الحوسبة السحابيّة الذي تحتاجه؟ إذا كنت قررت تجربة الحوسبة السحابيّة، فسيكون عليك اختيار نموذج الحوسبة السحابيّة الذي من الممكن ان تستخدمه. فيما يلي أكثر هذه النماذج شيوعًا: البنية التحتيّة كخدمة: Infrastructure as a Service (مثل AWS، وAzure، وGoogle Cloud، و Alibaba Cloud). المنصّة كخدمة: Platform as a Service (مثل AWS Elastic، وBeanstalk، وHeroku، وGoogle App Engine، وEngine Yard). البرنامج كخدمة: Software as a Service (مثل Google G Suite، وOffice 365، وSalesforce، وNetSuite). وهنا يكمن قرار مهمّ عليك اتّخاذه. النوع الأول هو الأفضل للشركات التي لا مانع لديها من استضافة تطبيقاتها في مراكز بيانات شركة أخرى، وتفضِّل أن يهتم غيرها بالبنية التحتيّة العتاديّة لتركّز بالكامل على تطوير ونشر ومتابعة تطبيقها. رغم هذا، إذا كنت تفضّل أن تكون تطبيقاتك قابلة للنقل، فقد ترغب في أن تضع البرمجية في منصّة PaaS متينة تقدّم بيئة بنية تحتيّة كاملة (وواضحة). إنّ تبّني PaaS سيقلّل أيضًا الوقت الذي تحتاجه لتكون جاهزًا للسوق - وذلك لأنها ستكون مجهّزة مسبقًا بمعظم المتطلّبات اللازمة لتشغيل برمجيّاتك. ستحتاج إلى نشر أعلى طبقة في تطبيقك فقط، وفي بعض الأحيان التطبيق نفسه وحسب. أمّا عن SaaS، فهو نموذج توصيل محتوى تكون البرمجيات الانتاجيّة فيه مستضافة مركزيًّا ومرخّصة حسب الاشتراك. فيما يلي جدول يوضّح ما توفّره كلّ من النماذج الثلاثة المذكورة أعلاه. IaaS PaaS SaaS تخزين البيانات منصّة التطبيق برنامج إدارة الزبائن الأجهزة الظاهريّة قاعدة البيانات إدارة الأعمال نظام توصيل محتوى التطوير الأمن الشبكة التكامل الأدوات الحوسبة table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } خاصّة أم عامّة أم هجينة؟ لنفترض أنّك اخترت نموذجًا سحابيًّا، وقد حان الوقت لاختيار النوع. لديك ثلاثُ خيارات أساسيّة: عامّ: جميع الموارد التي لديك مستضافة بالكامل لدى واحد أو أكثر من مزودي خدمة الحوسبة السحابيّة، مثل AWS، Azure، GCP، Alibaba، DigitalOcean، …إلخ. خاصّ: تُنشئ نظام الحوسبة السحابيّة الخاصّ بك بنفسك باستخدام منصّة مثل OpenStack أو VMWare vCloud. هجين: مواردك موزّعة على منصات خاصّة وعامّة، مع اتصالات بينها تتابعها أنت. يمكن أن يكون الخيار الهجين جذّابًا بسبب مزجه الجيد لكل من الاستخدام عند الطلب والاستقرار والإتاحة الدائمة والأمن والتكلفة التشغيلية القليلة. باستخدام هذا النوع يمكنك أن تجمع بين مزايا النوعين. سنشرح فيما يلي كيف تعمل الحوسبة السحابيّة الهجينة في شركة معيّنة. لنتخيّل أنّ تطبيقك المبنيّ للإنترنت يزدهر من ناحية الشعبية وعدد المستخدمين. ستحتاج إلى الموارد اللازمة للتوسعة باستمرار، وذلك من أجل أن تواكب الطلب المتزايد عليه. يجب أن تتمكن من زيادة الموارد المستخدمة إلى أقصى حدّ عندما يصل الاستخدام حدّه الأقصى، وأن تقلل تلك الموارد عندما لا تحتاجها وذلك لخفض التكلفة. يمكن فعل ذلك في الحوسبة السحابيّة العامّة. افترض بأن البيانات التي يجعمها تطبيقك سرّيّة جدًّا، ولا يمكن تخزينها خارج نطاق المؤسّسة. وهنا يمكن أن نستفيد من النوع الهجين. يمكنك في هذه الحالة أن تختار الأجزاء التي يمكنها أن تسكن السحابة العامّة، والأجزاء التي ستبقى في مركز البيانات عندك. يقول موقع RightScale في تقرير له أنّ الشركات تتبنى استراتيجيّة تعدد مزودي الخدمة 84%، وأنّ 58% منها تخطط لاستخدام حوسبة سحابيّة هجينة. تقييم التطبيقات للنقل إلى الحوسبة السحابيّة ما إن تختار النموذج والنوع، يبدأ التحدّي الحقيقيّ. لقد حان الوقت لنرى إذا كانت التطبيقات التي لديك جاهزة للنقل إلى الحوسبة السحابيّة. فيما يلي بعض العوامل التي عليك أخذها بعين الاعتبار: تعقيد تصميم التطبيق بعض التطبيقات القديمة معقدة جدًا ومترابطة داخليًّا إلى حد بعيد، مما يجعل مستخدميها غير راغبين في إعادة برمجتها. رغم هذا، فالمتطلب الرئيسيّ لأي انتقال ناجح هو أن تتبع التطبيقات معمارية موزعة، ويجب أن تكون من أساسها قابلة للتحجيم. يمكن لأدوات مثل PaaSLane و Cloudamize أن تساعدك على تقييم إلى أيّ مدى تطبيقاتك جاهزة لنقلها إلى منصّة سحابيّة. إنّ خدمة AWS’s Migration Hub تحوي كلّما تحتاجه من أدوات لاكتشاف وتقييم ذلك. تعقيدات التكامل لكل تطبيق نقاط تكامل، كبوابات الدفع، وخوادم البريد، وخدمات الويب، والتخزين الخارجي، والمزودين الخارجيين. من الضروريّ جدًّا تحليل أثر الانتقال إلى الحوسبة السحابية على هذه الاعتماديات. ستواجه في بعض الأحيان تحديات غير متوقعة تتعلق بالاتصال والاستيثاق، وعليك تحديدها وحلّها قبل حدوثها. أكثر المهام أهميّة (ومللًا) تحديد كلّ نقاط التكامل هذه. وبما أن التطبيقات القديمة قد يكون توثيقها ضعيفًا، وقد يكون المطورون الملمّون بتفاصيلها غير متاحين، فقد تحتاج إلى تفقّد أجزائها كلّها يدويًّا. تزداد المهمّة تعقيدًا إذا كنت تفكّر بترحيل مئات التطبيقات التي تعمل حاليًّا في مركز البيانات لديك. يمكن مواجهة العديد من هذه التحديات بالاعتماد على معرفة فريقك للتطبيقات، وعلى أداة اكتشاف الموارد (سواء مفتوحة المصدر أو تجارية). يمكن لأداة اكتشاف الموارد مساعدتك على تحديد كلّ إعدادات الخوادم في شبكتك، بما في ذلك تفاصيل الاتصال. على سبيل المثال، لنقل أن لديك مركز بيانات فيه شبكة تستضيف مئة تطبيق. يمكن لأداة الاكتشاف تلك أن تقدم لك نظرة عامّة للنظام بأكمله. ويمكنها أيضًا أن تعطيك تفاصيل متفرقة يمكنها مساعدتك في تقييم إدارة السعة العامّة (general capacity management، مصطلح إداريّ). من أدوات اكتشاف الموارد المعروفة BMC Atrium و HP DDMA. تقدّم Cloudamize أداة يمكنها اكتشاف التطبيقات والأجهزة آليًّا، ويمكنها أيضًا عمل خرائط باعتماديات التطبيقات آليًّا، وذلك من أجل اكتشاف الاعتماديات بين التطبيقات. نظام التشغيل المضيف ما إن تقرّر الانتقال إلى الحوسبة السحابيّة، من الضروريّ أن تعلم إذا كان باستطاعتك نشر تطبيقك على نفس نظام التشغيل. يمكن أن يعمل تطبيقك على نظام تشغيل محدّد (أو إصدار محدّد من نظام التشغيل). إذا لم يكن هذا النظام متوافقًا مع مزود الخدمات السحابيّة، فسيكون عليك أن تجد نظام تشغيل بديل يمكن استخدامه، أو مزود خدمات سحابيّة آخر، أو أن تلغي مشروع النقل من أساسه. على سبيل المثال، لا يتيح معظم مزودي الخدمات السحابيّة خيارات لأنظمة تشغيل 32بت، وقد يكون لدى البقيّة متطلّبات اشتراك غير متوقّعة. من الضروريّ أن تجري بحثًا في هذا الأمر قبل التخطيط للنقل. قاعدة بيانات التطبيق من المعروف أن قاعدة البيانات جزء هامّ من أيّ تطبيق. يستثمر الزبائن كثيرًا في خوادم قواعد البيانات، وغالبًا في تراخيصها أيضًا. إضافة إلى ذلك، قد لا ترغب في نقل قواعد البيانات الآن، وذلك بسبب تعقيدها وحساسيّة البيانات التي فيها، كما أن نقل كميات ضخمة من البيانات ليست بالأمر السهل. في جميع الأحول، عليك أن تتأكد من أن طرق النقل التي ستستخدمها يمكن الاعتماد عليها إلى حدّ بعيد، ويمكن كذلك عكسها في حال حصول مشكلة كبيرة غير متوقّعة. يوفّر معظم مزودي الخدمات السحابيّة أدوات نقل خاصّة بهم. ولهذا من الضروريّ أن تقيّم هذه الخدمات قبل أن تضغط زرّ البدء. فمثلًا، تقدم AWS خدمة Migration Hub، والتي - على حد تعبيرهم - "تسهّل وتسرّع الاكتشاف والنقل من مراكز بياناتك إلى AWS Cloud". وهناك العديد من من مزودي خدمة نقل البيانات كطرف ثالث، مثل Attunity CloudBeam، وATADATA ATAmotion، وCloudEndure Live Migration، وRacemi DynaCenter. الشبكة لا تدعم معظم بيئات الحوسبة السحابيّة ميزة multicasting، ولهذا إذا كان تطبيقك يعتمد على هذه الميزة، فعليك أن تفكّر جيدًا قبل أن تخطو أيّ خطوة. موازنة الأسعار لدى العديد من مزودي الخدمات السحابيّة حاسبات تكلفة من شأنها أن تساعدك على تقدير التكاليف الحقيقيّة التي ستواجهها عند الانتقال إلى الحوسبة السحابية، ومقارنتها بالتكلفة الحاليّة، ومنها AWS TCO (Total Cost of Ownership) calculator و Azure Pricing Calculator. يسمح لك موقع Cloudamize بمقارنة التكاليف لدى كلّ من AWS وAzure و Google Cloud Platform (GCP)، بحيث يمكنك من الاختيار بينها بما يتوافق مع مدى الحمل الذي يقوم به تطبيقك. إثبات المفاهيم (Proof of Concept) من الأفكار الرائعة دائمًا بناء "إثبات للمفاهيم" (أي تجربة الأمر عمليًّا على نظام بديل ومنفصل عن النظام الحقيقيّ الذي تستخدمه، وذلك للتأكد من أن كل شيء يعمل كما يجب) على نطاق صغير قبل نقل التطبيق الحقيقيّ إلى الحوسبة السحابيّة. لن تتوقع هذه النماذج كل المشاكل التي يمكن أن تحصل، ولكنها ستوضّح التحديات التي يمكن أن تواجهها بوضوح أكثر، وستساعدك على فهمها. من الأمور التي عليك البحث فيها أثناء تنفيذ هذه الخطوة: مقارنة الأداء مع التطبيق الموجود فعليًّا. مستويات التعقيد أثناء ترحيل التطبيق. التحديات المتعلقة بالشبكة والتي يجب العمل على حلّها. إمكانيّة الاعتماد عليها. تقييم دعم مزود الخدمة. خُلاصة القول تستفيد العديد من المؤسسات من المرونة التي تقدّمها خدمات الحوسبة السحابيّة، فيما يتعلّق بإمكانية تشغيلها وإيقافها وتغيير حجمها ومزاياها والدفع حسب الاستخدام. رغم هذا، وكما في أيّ خدمة بنية تحتيّة، يجب عليك تقييم مدى ملاءمة الحوسبة السحابيّة لحالة الاستخدام لديك تحديدًا، وذلك لعمل تقييم مبني على المخاطر المحتملة (risk-based evaluation). خصِّص وقتًا للبحث والتخطيط لتفهم كيف ستؤثِّر الحوسبة السحابيّة في أعمالك. لا يمكن حصر كلّ التحديات التي يمكن أن تواجهها عند النقل في مقال واحد، ولكننا حاولنا هنا الوقوف على بعض المشاكل الشائعة التي يجب أن تأخذها بعين الاعتبار قبل بدء هذا العمل. شاركنا تجربتك في نقل عملك إلى الحوسبة السحابية في التعليقات. ترجمة -وبتصرف- للمقالين: Disadvantages of Cloud Computing لصاحبه Andrew Larkin. Cloud Migration Risks & Benefits لصاحبه Jeremy Cook.
  2. هذا المقال هو الجزء الأول من جزأين يشرحان موضوع الحوسبة السحابيّة. يناقش هذا المقال المتطلبات المسبقة وما تحتاج إلى معرفته قبل بدء رحلتك في الحوسبة السحابية. ويناقش كذلك بعض الافتراضات الخاطئة المتعلقة بالحوسبة السحابية، ويعمل على تصحيح المفاهيم المتعلقة بها، كما ويوضح مفهومي الأجهزة الافتراضيّة (الأجهزة الظاهريّة)، والحوسبة السحابيّة العامّة والخاصّة. ومن ثمّ يناقش أحد المفاهيم المتعلّقة بالحوسبة السحابية والتي تتردّد كثيرًا، وهو مفهوم "مهندس حوسبة سحابية" (Cloud Architect)؛ سنناقش في هذا المقال ما يقوم به مهندس الحوسبة السحابية، وسنحلّل المهارات والشهادات اللازمة لتصبح مهندس حوسبة سحابيّة. وسنذكر كذلك بعض أنواع الوظائف المتاحة إذا قرّرت جعل هذا المجال حرفتك. المتطلبات المسبقة لتعلم الحوسبة السحابية يسأل العديد من المهتمين: "ما المتطلبات والمعرفة المسبقة اللازمة لبدء تعلم الحوسبة السحابية؟" سنعطي - في هذا المقال - المعلومات اللازمة للإجابة على هذا السؤال، لتكون جاهزًا لبدء تعلم الحوسبة السحابية دون قلق. يشير مفهوم الحوسبة السحابية إلى مجال واسع من تقنية المعلومات تشمل: البنية التحتية العتادية، والبنية التحتية البرمجية، ومنشآت مراكز البيانات (data centers)، وتقنيات الأجهزة الافتراضية (أو الأجهزة الظاهرية - Virtualization)، ومفاهيم هندسة البرمجيات. كلّ هذه المجالات متصلة ببعضها وتوفر لك معرفة أولية جيدة تسهّل عليك رحلتك في استكشاف وتعلّم استخدام منصات الحوسبة السحابية والعمل فيها؛ ولكننا سنركّز في هذا المقال على مزودي خدمة البنية التحتية السحابية (Infrastructure as a Service - IaaS)، مثل خدمات أمازون (Amazon Web Services - AWS)، و Microsoft Azure، و Google Compute Engine و Rackspace Cloud، وكذلك على مزودي خدمة المنصة السحابية (Platform as a Service - PaaS)، مثل Salesforce.com، و Microsoft Azure، و Google App Engine. يمكننا البدء بافتراض أنّك لن تحتاج شهادة جامعية في أحد مجالات الحاسوب لتعلم الحوسبة السحابية. يمكنك بدء تعلم الحوسبة السحابية من الصفر حتى وإن كانت مهاراتك في تقنية المعلومات بسيطة جدًّا. افتراضات مغلوطة عن الحوسبة السحابية 1. لتعلم الحوسبة السحابية يجب أن تجيد البرمجة يمكنك أن تبدأ تعلم الحوسبة السحابية باستخدام خدمة حوسبة سحابية - عامّة أو خاصّة - حتّى وإن لم تكن مطوّر برمجيات. 2. يجب أن تكون لديك خبرة سابقة في عالم تقنية المعلومات الحوسبة السحابية تقنية مستخدمة في كل المجالات وحول العالم، ومن شأن فهمها أن يساعد الجميع، وليس فقط ذوي الاهتمامات التقنيّة؛ بل غالب الظنّ أنك تعمل في مؤسّسة تستخدم الحوسبة السحابية بالفعل. 3. الحوسبة السحابية فقط للتقنيين ومطوري البرمجيات إنّ الحوسبة السحابيّة تغيّر طريقة بناء الشركات لأنظمة المعلومات لديها، وكيفية استخدامها لها، بما في ذلك كلّ برمجياتها، ويجب على المدراء، والمسوّقين، ومدراء الأنظمة، والمطورين تعلّمها؛ ولكن - بالطبع- بتوجّهات مختلفة، مركّزين على الجوانب المتعلّقة بأدوارهم ومسؤوليّاتهم. أنظمة التشغيل والأجهزة الافتراضيّة والشبكة بما أنّ الحوسبة السحابية مجالها واسع، لكي تتعلّم الحوسبة السحابية تحتاج لبعض المهارات تتعلق بالمفاهيم الأساسيّة لأنظمة التشغيل وكيف تعمل (دون الخوض في تفاصيلها الدقيقة)، مثل Windows ولينُكس ومفاهيم بسيطة تتعلّق بهما. إذا كانت معرفتك جيدة في هذه الأمور، فأنت تعرف أنّ التقنيات المتعلّقة باستخدام الأجهزة الافتراضيّة (أو الأجهزة الظاهريّة Virtualization) لها دورً مهمّ عندما نتحدّث عن الحوسبة السحابيّة. لا توجد تجربة تضاهي تشغيل جهاز افتراضيّ بنفسك (يمكنك فعل ذلك باستخدام VirtualBox) لتفهم كيف تعمل بيئة الأجهزة الافتراضيّة. تمكّنك هذه التقنيّات من إنشاء بيئة ظاهريّة تحدّد فيها عدد وسرعة المعالجات المركزية (CPU) والذاكرة الرئيسيّة (RAM) ومساحة التخزين، وكذلك نظام التشغيل الذي يعمل عليها مثل Windows أو Linux. تتشارك الأجهزة الافتراضيّة في العتاد الحقيقيّ وأجهزة الشبكة ولكنّها منفصلة عن بعضها. من أوائل الشركات الرائدة في هذا المجال شركة تُدعى VMWare. لقد كانت الحوسبة الظاهريّة (أو الأجهزة الافتراضيّة) معروفة جيّدًا قبل VMWare، ولكنّ هذه الشركة غيّرت السوق المتعلّق بها، حيث حوّلت هذه التقنيّة إلى حزمة برمجيّة جاهزة للاستخدام ممّا جعلها شائعة في الشركات صغيرة كانت أم كبيرة. لقد قدّمت هذه التقنيّة مفهومًا اقتصاديًّا واستراتيجيًّا جديدًا، وهو Consolidation، ويعني حرفيًّا الدمج أو الجَمع، ويشير إلى جمع أكثر من خدمة وأكثر من جهاز افتراضيّ على جهاز حقيقيّ واحد. ويعني هذا أن الشركات حول العالم لم يعد واجبًا عليها توفير خادم حقيقيّ لكل نوع من التطبيقات أو الأحمال التي يشغّلونها، بل صار بإمكانهم مشاركة الموارد وتقسيمها بين عدد من الأجهزة الافتراضيّة. مفاهيم أساسيّة عليك معرفتها عن الأجهزة الافتراضيّة Hypervisor: هو قلب نظام الأجهزة الافتراضيّة والذي يشغّل كلّ الأجهزة الافتراضيّة. ومن الأمثلة عليه VMWare وKVM وXen و OpenVZ. تستخدم كلّ بيئات الحوسبة السحابيّة hypervisor معدّل. أمازون مثلًا تستخدم Xen. الجهاز الافتراضيّ (أو الجهاز الظاهريّ، وبالإنجليزيّة: Virtual Machine): وهو العنصر الأساسيّ في هذه التقنيّة. اعلَم أنّ للجهاز الافتراضيّ نظام تشغيل ومعالج وذاكرة وقرص تخزين والعديد من الإعدادات المتعلّقة بالشبكة. مزايا استخدام الأجهزة الافتراضيّة: الجَمع (جمع أكثر من جهاز على عتاد واحد)، وإمكانيّة نقل الأجهزة الافتراضيّة بين الخوادم الحقيقيّة (والتي تسمّى أيضًا بالعُقَد physical nodes)، والمرونة في إضافة موارد جديدة إلى جهاز افتراضيّ موجود. ما إن تصبِح ملمًّا بأساسيّات تقنيّات الحوسبة الظاهريّة (الأجهزة الافتراضيّة) وأنظمة التشغيل، فعليك بأخذ مساق مقدمة في الشبكات، ومن ثمّ ستتعلّم الحوسبة السحابية بسهولة. يمكن أن يكون مجال الشبكات صعبًا، وسيحتاج حتّى ذوو المهارات العالية بعض الوقت لفهمه بالكامل. راجع القسم المتعلّق بالشبكات في هذا المقال لفهم المتطلبات اللازمة للخوض في هذا المجال. وفي النهاية، نريد تكوين فكرة واضحة عن معنى كلّ من الحوسبة السحابيّة العامّة والخاصّة. السحابة العامّة: تشير إلى البنية التحتية التي من الممكن للعموم الوصول إليها وتخزين بيانات وأجهزة افتراضيّة وأيّ نوع من الموارد السحابيّة. يمكنك استخدامها بنفسك، ولست بحاجة إلى الاستثمار في العتاد والبنية التحتيّة من أجل ذلك. يمكنك استخدام السحابات العامّة والدفع حسب الاستخدام. وهذا يشبه استئجار السيّارة لمدّة معينة من الوقت بدلًا من شرائها وامتلاكها. السحابة الخاصّة: تحتاج الشركات إلى كلّ المرونة والمزايا التي تقدمها الحوسبة السحابيّة، ولكن قد تكون لديها بنيتها التحتيّة ومركز البيانات (data center) الخاصّ بها. في هذه الحالة، تكون الشركة مسؤولة عن إدارة كلّ شيء فيها. ما هي هندسة الحوسبة السحابيّة يشير مفهوم معمارية الحوسبة السحابيّة (أو هندسة الحوسبة السحابيّة) إلى المكوّنات الرئيسيّة والفرعيّة التي تحتاجها الحوسبة السحابيّة. وتتكون هذه المكوّنات عادة من منصّة الواجهة، والمنصّة الخلفيّة، ونظام التوصيل السحابيّ للمحتوى (cloud-based delivery) والشبكة. وتشكّل هذه المكوّنات مجتمعة معماريّة الحوسبة السحابيّة. ويعتمد تصميم حلول الحوسبة السحابيّة على أساليب وإجراءات هندسيّة تمّ تطويرها على مدى العقدين الماضيين. مهندس الحوسبة السحابية مسؤول عن تحويل المتطلبات التقنيّة للمشروع إلى معماريّة وتصميم يوجّهان سير العمل للوصول إلى المنتج النهائيّ. وغالبًا يكون مهندس الحوسبة السحابية مسؤولًا أيضًا عن رأبِ الصدعِ بين المشكلات المركّبة المتعلّقة بالأعمال وبين الحلول المعتمدة على الحوسبة السحابيّة. ويعمل الأعضاء الآخرون في الفريق التقنيّ - بما فيهم مهندس دعم المطورين DevOps والمطورون - مع مهندس الحوسبة السحابيّة للتأكد من بناء الحلّ أو الحلول التقنيّة المناسبة. ما المهارات المطلوبة في البداية؟ إذا كنت تفكر بأن تغدو مهندس حوسبة سحابية، فيفترض بأن لديك بالفعل معرفة مسبقة قويّة في الحوسبة السحابيّة أو مجال تقنيّ مشابه. إذا كنت ترى المفاهيم التالية مفهومة بالنسبة لك، أو على الأقل بعضها، فغالبًا أنت على الطريق الصحيح. أمّا إذا لم تكن كذلك، فأنصحك أوّلًا بدراسة أو العمل في مجال قريب قبل أن تسعى إلى أن تغدو مهندس حوسبة سحابيّة. معرفة جيّدة في واحد من أنظمة التشغيل على الأقل: لينُكس، يونكس، سولاريس، أو ويندوز. ما أنصحك به هو نظام التشغيل لينُكس بأيّ من توزيعاته (سواء بتوزيعة دبيانيّة أو ردهاتيّة أو غيرها). وجود خبرة مسبقة كمدير نظام أو مهندس نظم لأيّ من أنظمة التشغيل المعروفة قد يفيدك أيضًا. فهم جيّد في الشبكات: TCP/IP و HTTP و DNS. أقترح أن تتعرف على المفاهيم المتعلقة بها قبل السعي لأن تصبح مهندس حوسبة سحابية. لغة برمجة: ستحتاج على الأقل إلى فهم بسيط للغة برمجة مفسّرة (scripting language). غالبًا هذا ليس إلزاميًّا، ولكنه بكل تأكيد سيفيدك. الأمن: أمن المعلومات مهم في الحوسبة السحابيّة، ولهذا، يجب أن يكون لديك فهم جيّد للمفاهيم الأساسيّة في مجال أمن المعلومات، كجدران الحماية مثلًا. إن القائمة المذكورة أعلاه ليست كاملة أبدًا. إن العبرة من ذكرها هو ضرورة أن تكون لديك معرفة تقنيّة قويّة إذا كنت تفكّر بدخول مجال هندسة الحوسبة السحابيّة. يقدّم موقع Could Roster قائمة محدّثة بالمهارات التقنيّة الدارجة، ويشرح ما تقوم به هندسة الحوسبة السحابيّة، ويوضّح الخصائص والتوقّعات اليوميّة، ويعرض قائمة بالمهارات التي يحتاجها السوق. يتم تحديث القائمة شهريًّا، لذا تأكّد من مراجعتها قُبَيلَ بدئك في السعي نحو الحصول على شهادة في المجال. [001-Cloud-Roster-Features.gif] ما الخطوة التالية؟ لنفترض بأنّك تحقّق بعض المتطلّبات المذكورة أعلاه؛ ماذا تفعل الآن لتغدو مهندس حوسبة سحابيّة مؤهّلًا؟ يعتمد هذا على المنصّة التي تفضّلها: خدمات أمازون السحابيّة - AWS مهندس معتمد لحلول خدمات أمازون السحابيّة (AWS Certified Solutions Architect – Associate) - تحقِّق هذه الشهادة الخبرات التقنيّة في تصميم ونشر نظام قابل للتوسعة، ومتاح دائمًا، ومقاوم للأخطاء على منصّة AWS التابعة لأمازون. يوضّح هذا المقال كيفيّة التحضير للاختبار بالتفصيل، ويتعمّق أكثر فيما يتعلّق بالمصادر المتاحة على Cloud Academy التي من شأنها مساعدتك على النجاح في الاختبار. Microsoft Azure مهندس حلول حوسبة سحابية لمنصّة Microsoft Azure (بالإنجليزيّة Microsoft Azure Solutions Architect - إنّ منصّة Microsoft Azure رياديّةٌ في هذا السوق الصاعِد، وتتطلّب شهادتها خبرة في الحوسبة، والشبكات، والتخزين، والأمن، وذلك من أجل تصميم حلول تعمل على Azure. للحصول على شهادة مهندس حلول Azure، ستحتاج إلى النجاح في اختبارين، وهما: AZ-300 و AZ-301. لا تحتاج إلى اجتياز أيّ امتحانات أقلّ درجة من أجل التقدم إلى هذين الامتحانين. يركّز اختبار AZ-300 على تقنيات Azure، بينما يركّز اختبار AZ-301 على التصميم. خدمات Google السحابيّة - Google Cloud Platform مهندس مختصّ في الحوسبة السحابيّ: يمكّن المهندسُ المختصّ في الحوسبة السحابيّة (Profestional Cloud Architect) المؤسساتِ من الاستفادة من التقنيات التي تتيحها خدمات Google السحابية. يمكن لهذا المهندس - بفهمه العميق لمعمارية الحوسبة السحابية ومنصّة Google للخدمات السحابيّة - أن يصمّم ويطوّر ويدير حلول تقنيّة متينة وآمنة وقابلة للتوسعة ومتاحة دائمًا ومرنة وذلك لتحقيق أهداف المؤسسة. لقد غدوتُ مهندس حوسبة سحابية مؤهَّلًا - ماذا أفعل الآن؟ ما إن تتخطى اختبار التأهيل، ستُفتَح أمامك العديد من فُرَص العمل التي ربما لم تفكِّر فيها حتّى. إنّ بعض الشركات الأكثر ابتكارًا في مجال البيانات الضخمة (big data) ليس بوسعها تحقيق أيّ شيء دون مهندس حوسبة سحابيّة مؤهّل لإحدى منصّات الحوسبة السحابية المذكورة. تُقدِّم AWS المرونة وإمكانيّة التوسعة والرزانة المطلوبة لأكثر من مليون زبون. من الشركات التي تستفيد من خدمات AWS في مجال البيانات الضخمة كلّ من General Motors، وIBM، وSplunk، وWeather Company. قد تجد نفسك يومًا ما تعمل لدى شركة طبيّة لبناء نظام لتحليل الحمض النووي (الجينات) لتوقع الأمراض من خلالها. إذا كنت تحب السّفر، فقد تعمل في يوم ما لدى شركة Expedia، التي تستخدم AWS لاستضافة خدمتها (Expedia Service)، وهي خدمة متخصّصة بتقديم الاقتراحات المتعلّقة بالسياحة. ولكي لا ننسى أحد أكبر زبائن AWS، وهي Netflix، تستخدم منصة AWS في نظام توصيل محتوى متاح دائمًا ومقاوم للأخطاء لخدمة بثّ الأفلام والبرامج التلفازيّة التي تقدّمها. تعتمد Netflix على إمكانات البنية التحتيّة لأمازون في التوسّع السريع والخوادم وتخزين البيانات، وذلك بسبب الكمّ الهائل ونمط الاستخدام المتأرجح لزبائنها. لا يسعنا إلا أن نتخيّل أنّهم يوظّفون مئات إن لم يكن آلاف مهندسي حلول الحوسبة السحابيّة لمنصّة AWS. إنّ منصّة Microsoft Azure أسرع مزوّدي الخدمات السحابيّة نموًّا لبناء واختبار ونشر وإدارة التطبيقات والخدمات عبر مراكز بيانات تديرها Microsoft. من الشركات التي تستخدم Azure كلّ من Adobe، وApple، وiCloud، وEbay، وTravelocity، وSamsung، وXerox، وNFL، وNBC. ما إن تصبح مهندس حوسبة سحابيّة مؤهًلًا لمنصّة Microsoft Azure، فسيكون باستطاعتك التقدّم لأيّ من آلاف الشواغر المتاحة لـمهندسي الحوسبة السحابيّة لمنصّة Azure. إنّ منصّة Google للحوسبة السحابيّة هي حقيبة كاملة من خدمات الحوسبة السحابيّة التي تعمل على نفس البنية التحتيّة التي تستخدمها Google من أجل خدماتها التي تقدّمها للمستخدمين الأفراد، وتستخدمها كذلك كلّ من Target، وPayPal، و20th Century Fox، وTwitter. إذا صرت مؤهلًا في هندسة الحوسبة السحابية لمنصة Google، فبإمكانك التقدّم للوظائف ذات العلاقة. إنّ مهندس الحوسبة السحابيّة لَذو دور هامّ، وهناك حاجة ماسّة في السوق لهذا التخصّص، والإمكانات فيه غير محدودة. وتشير التوقعات أيضًا إلى نموّ هائل في هذا المجال في السنوات القليلة القادمة، ولهذا نعتقد بأنّ الحصول على مؤهّل في هندسة الحوسبة السحابية خطوة في الاتجاه الصحيح، سواء للعمل في المجال، أو للتعرف على أيّ تقنيات حديثة ومذهلة تنشأ في حلبة الحوسبة السحابيّة. ترجمة -وبتصرف- للمقالين: What Exactly Is a Cloud Architect and How Do You Become One?‎ لصاحبه Michael Sheehy Prerequisites to Learn Cloud Computing – Introduction لصاحبه Stefano Bellasio
  3. ما الفرق بين دوكر (Docker) والأجهزة الافتراضية (والمسماة أيضًا بالأجهزة الظاهرية Virtual Machines)؟ سنشرح في هذا المقال الاختلافات بينهما، وسنذكر وجهة نظرنا لمساعدتك على الاختيار. ما هو دوكر؟ تسعى المؤسسات هذه الأيام إلى تحويل أعمالها إلى أعمال إلكترونية، ولكن يعيقها التنوع الكبير في البنية التحتية في داخل المؤسسة نفسها وفي الحوسبة السحابية والتطبيقات. يحل دوكر هذه المشكلة بتوفير منصة حاويات تساعد على تحويل الخدمات الصغيرة والتطبيقات التقليدية المبنية لويندوز ولينكس والخوادم الكبيرة إلى سلسلة إمداد مؤتمتة وآمنة. إنّ دوكر أداة تطوير برمجيات وتقنية حوسبة ظاهرية تسهِّل تطوير ونشر وإدارة التطبيقات باستخدام حاويات. والحاويات هي حزم تنفيذية خفيفة وقائمة بذاتها لتطبيق ما، تحوي كل المكتبات وملفات الإمداد والاعتماديات والأجزاء الأخرى الضرورية ليعمل التطبيق. وبعبارة أخرى، فإنّ التطبيقات تعمل بنفس الطريقة بغضّ النظر عن مكانها أو نوع الجهاز الذي تعمل عليه، وذلك لأن الحاوية توفّر بيئة التطبيق طوال دورة حياة البرنامج. وبما أنّ الحاويات معزولة، فأنها توفر أمنًا إضافيًّا، مما يسمح لتشغيل أكثر من حاوية على نفس الجهاز في نفس الوقت. إضافة إلى ذلك، فهذه الحاويات خفيفة لأنها لا تتطلّب حملًا إضافيًّا كالأجهزة الافتراضية. تشغّل الأجهزة الافتراضية أنظمة مستضافة (كما في حالة VMWare و VirtualBox)، أما الحاويات فتعمل ضمن نواة النظام المضيف مباشرة دون الحاجة إلى نظام ضيف. تتميّز الحاويات عن الأجهزة الافتراضية بما يلي: تحتاج موارد أقل لإدارتها. حجم نسخ احتياطيّة فوريّة (snapshots) أصغر. أسرع في عمل نسخ معدّلة للتطبيقات. تحديثات أمنية أقل وأبسط. كتابة شيفرات أقلّ لنقل وترحيل ورفع العمل. ما هي الأجهزة الافتراضية؟ أما عن الأجهزة الافتراضية، فتُستَخدَم لتنفيذ مهام قد تكون خطرة لو تم تنفيذها على النظام المضيف. الأجهزة الافتراضية معزولة عن بقية النظام، ولا يمكن للنظام الضيف أن يعبث بالجهاز المضيف. ولهذا، فبعض المهام - كالوصول إلى ملفات مصابة بفيروسات، واختبار أنظمة التشغيل - تُستخدَم معها الأجهزة الافتراضية. يمكننا تعريف الجهاز الافتراضيّ كما يلي: الجهاز الافتراضيّ هو ملف أو برمجيّة حاسوب يُشار إليها عادة بـ"الضيف" (guest) تُنشَأ في داخل بيئة حاسوبيّة أخرى تُسمّى "المضيف". باستطاعة الجهاز الافتراضيّ تنفيذ مهام كتشغيل التطبيقات أو البرامج كحاسوبٍ مستقِلّ، مما يجعله بيئة مثاليّة لتجربة أنظمة تشغيل أخرى، كالإصدارات التجريبيّة، وعمل نسخ احتياطيّة لأنظمة التشغيل، وتشغيل تطبيقات وبرمجيات. ويمكن للنظام المضيف أن يحوي عددًا من الأجهزة الافتراضية، وأن تعمل كلّها أو بعضها في نفس الوقت. ومن الملفات التي يتكوّن منها الجهاز الافتراضيّ: ملفات التقارير، وإعدادات الذاكرة، وملف القرص الصلب الافتراضيّ، وملف الإعدادات. ومن المجالات الأخرى التي تحتاج إلى أجهزة افتراضيّة الخوادم؛ حيث يمكن تقسيم خادم حقيقيّ إلى عدد من الخوادم الافتراضيّة المنفصلة والمعزولة عن بعضها، ممّا يسمح لهذه الخوادم الافتراضيّة أن تعمل بأنظمة تشغيل خاصة بها. ويوفِّر كلّ جهاز افتراضيّ عتاده الافتراضيّ، كالمُعالِج، والذاكرة، وواجهات الشبكة، والأقراص الصلبة، وأجهزة أخرى. عمومًا، تقسَّم الأجهزة الافتراضيّة إلى فئتين حسب استخدامها: أجهزة افتراضيّة على مستوى النظام: وهي منصّات تسمح بوجود عدد من الأجهزة الافتراضيّة يعمل كلّ منها بنسخة نظام تشغيل خاصّة به وتتشارك كلها في موارد الجهاز المضيف. وتوفِّر الطبقة البرمجيّة التي تشغّل الأجهزة الافتراضيّة من هذا النوع (والمسماة Hypervisor) التقنيات المتعلقة بتنفيذ الأجهزة الافتراضيّة. وتُنفَّذ هذه الطبقة فوق نظام التشغيل المضيف أو على العتاد مباشرة. أجهزة افتراضية على مستوى الخدمات: تتيح هذه الأجهزة بيئة برمجة مستقلّة. وتُصمَّم خدمة الجهاز الافتراضيّ لإخفاء المعلومات المتعلّقة بالعتاد ونظام التشغيل وتسمح للبرنامج بالعمل بنفس الطريقة في كلّ منصّة من هذا النوع. وعلى الرغم من أن تشغيل عدد من الأجهزة الافتراضيّة يبدو للوهلة الأولى استغلالًا جيّدًا للموارد، إلّا أنّه يؤدي إلى أداء سيء؛ إذ سيكون لكلّ نظام ضيف نواته ومجموعة مكتباته واعتمادياته، مما سيشغل قدرًا كبيرًا من موارد النظام. ومن العيوب الأخرى للأجهزة الافتراضيّة قلّة أداء برمجية مشرف الجهاز الافتراضيّ (Hypervisor) موازنة بالعتاج الحقيقيّ، وكذلك المدة الطويلة التي يحتاجها ليقلع النظام ويكون جاهزًا للعمل. يتغلّب مفهوم الحاويات -بما في ذلك منصّة دوكر- على هذه العقبات. الموازنة فيما يلي الاختلافات المهمّة بين دوكر والأجهزة الافتراضيّة. 1. المعمارية ودعم أنظمة التشغيل الاختلاف الرئيسي بين دوكر والأجهزة الافتراضيّة يكمن في المعمارية، كما هو موضّح في ما يلي. في حال الأجهزة الافتراضيّة، لدينا نظام تشغيل مضيف، ولدينا نظام تشغيل ضيف في كلّ جهاز افتراضيّ، ويمكن ان يكون نظام التشغيل الضيف أيّ نظام تشغيل - مثل ويندوز أو لينكس - بغض النظر عن النظام المضيف. أما دوكر فيستضيف البرمجيات على نفس النظام المضيف. مشاركة النظام المضيف بين الحاويات يجعلها خفيفة وسريعة عند تشغيلها. وتعدّ حاويات دوكر مناسبة لتشغيل عدد من التطبيقات على نواة نظام تشغيل واحدة؛ أما الأجهزة الافتراضية فهي ضروريّة إذا كان التطبيق أو الخدمة بحاجة إلى نظام تشغيل مختلف. 2. الأمن الأجهزة الافتراضيّة قائمة بذاتها، ولها نواتها وخصائصها المتعلقة بالأمن. ولهذا، تُستخدَم الأجهزة الافتراضيّة لتشغيل التطبيقات التي تحتاج إلى صلاحيات وأمان أكثر. أما بالنسبة لدوكر، فلا يُنصح بإعطاء صلاحيات عُليا للتطبيقات أو تشغيلها بصلاحيات المسؤول أو الجذر، وذلك لأنّ هذه الحاويات تتشارك مع النظام المضيف نواته؛ حيث يمكن لتقنية الحاويات الوصول إلى الأنظمة التابعة للنواة؛ مما يعني أن وجود تطبيق واحد مُصاب ببرمجية خبيثة يمكن أن يؤدّي إلى اختراق النظام المستضيف بأكمله. 3. إمكانية النقل الأجهزة الافتراضيّة معزولة عن النظام الذي تعمل عليه، ولهذا فهي لا تنتقل إلى أنظمة أخرى بدون حدوث مشكلات تتعلق بالتوافقيّة. ولهذا، إذا كان من الضروريّ اختبار التطبيق على منصات مختلفة في مرحلة التطوير، فيجب أخذ دوكر بالحسبان في هذه الحالة. إنّ حزم حاويات دوكر تحوي كل ما تحتاجه، ويمكنها تشغيل التطبيقات في أيّ بيئة، وبما أنها لا تحتاج إلى نظام تشغيل ضيف، فيمكن نقلها بسهولة إلى منصات مختلفة. كذلك، يمكن نشر حاويات دوكر في الخوادم، وذلك لأنها خفيفة، ويمكن تشغيلها وإيقافها في وقت أقلّ بكثير من الأجهزة الافتراضيّة. 4. الأداء تحتاج الأجهزة الافتراضيّة إلى موارد أكثر من حاويات دوكر، فهي بحاجة إلى تحميل نظام تشغيل بأكمله عند بدئها. أما حاويات دوكر فهي ذات معمارية خفيفة ولا تحتاج موارد كثيرة كما في الأجهزة الافتراضيّة. في حال الأجهزة الافتراضيّة تكون الموارد - بما فيها المعالج والذاكرة والدخل/الخرج - ثابتة لا تتغير، على خلاف الحاويات، والتي يزداد استخدام الموارد فيها حسب الحمل أو كمية البيانات المارّة. توسعة واستنساخ الحاويات بسيط وسهل مقارنة بالأجهزة الافتراضيّة، حيث لا تحتاج هذه الحاويات إلى تثبيت أنظمة تشغيل فيها. في ما يلي بعض الاختلافات الأخرى بين الاثنين، عدا عن الاختلافات الرئيسيّة: ... دوكر الأجهزة الافتراضيّة وقت الإقلاع تُقلِع في ثوانٍ قليلة يستغرق تشغيل الجهاز الافتراضي بضع دقائق تعمل على يستفيد دوكر من محرّك التنفيذ (excution engine) تستخدم مشرف الأجهزة الافتراضيّة (hypervisor) كفاءتها في استخدام الذاكرة تحتاج ذاكرة قليلة وذلك لعدم حاجتها إلى جهاز افتراضيّ تحتاج إلى تحميل نظام تشغيل كامل قبل أن تبدأ التطبيق، ولهذا فهي أقل كفاءة من هذه الناحية. العزل معرّضة لاستغلالها بطريقة سيئة، وذلك لعدم وجود احتياطات لأنظمة العزل إمكانيّة التعارض بينها منخفضة بسبب كفاءة آليّة العزل فيها النشر نشرها سهل، حيث يمكن استخدام نسخة واحدة في حاوية على كل المنصات النشر يأخذ وقتًا أطول، وذلك لوجود نماذج منفصلة مسؤولة عن التنفيذ الاستخدام لدى دوكر آليّة استخدام مركّبة تتكون من أدوات تديرها دوكر وأخرى من أطراف خارجيّة الأدوات سهلة وأبسط في الاستخدام table { width: 100%; } thead { vertical-align: middle; text-align: center; } td, th { border: 1px solid #dddddd; text-align: right; padding: 8px; text-align: inherit; } tr:nth-child(even) { background-color: #dddddd; } أيّ الخيارين أفضل؟ لا يمكن موازنة دوكر بالأجهزة الافتراضيّة بعدالة، إذ صُمِّمت كلّ منها لاستخدامات مختلفة. لا شكّ بأنّ دوكر ينتشر بقوّة هذه الأيّام، ولكن لا يمكنه أن يحلّ محلّ الأجهزة الافتراضيّة. وعلى الرغم من أنّ دوكر يزداد شعبيّة، إلّا انّ الأجهزة الافتراضيّة خيار أفضل في حالات معيّنة. تُعدّ الأجهزة الافتراضيّة خيارًا مناسبًا في الإصدارات النهائيّة، وهي أفضل من حاويات دوكر في هذه الحالة، حيث تعمل هذه الأجهزة الافتراضيّة بنظام تشغيلها الخاص دون أن تشكّل خطرًا على الحاسوب المضيف. ولكن إذا كانت التطبيقات بحاجة إلى اختبار، فالخيار الأفضل هو دوكر، إذ يقدّم منصات أنظمة تشغيل مختلفة يمكن استخدامها لعمل اختبارات كثيرة للتطبيق أو البرنامج. إضافة إلى ذلك، تستخدم حاويات دوكر محرّك دوكر (docker-engine) بدلًا من استخدام مشرف (hypervisor) كالذي تستخدمه الأجهزة الافتراضيّة. وبما أنّ النواة المضيفة مشتركة، فإنّ استخدام محرك دوكر يجعل الحاويات صغيرة ومعزولة ومتوافقة وعالية الأداء وسريعة الاستجابة. لحاويات دوكر عبء اقلّ، حيث أنها متوافقة بتشارك نفس النواة ومكتبات تطبيقات. تستفيد المؤسسات من خليط من الاثنين غالبًا، حيث يعتمد الاختيار في كلّ حالة على نوع الحمل الذي تحتاجه المؤسسة. لا تعتمد كثير من المؤسسات على الأجهزة الافتراضيّة كخيارها الرئيسيّ، وتفضّل الانتقال إلى استخدام الحاويات، حيث انّ عمليّة النشر تكون طويلة وتأخذ وقتًا، وتشغيل خدمات مصغّرة من التحديات الكبيرة التي تنشأ منها. على الرغم من هذا، ما زالت هناك شركات تفضّل الأجهزة الافتراضيّة على دوكر، أما الشركات التي تستخدم خدمات أمن مخصصة للشركات لبنيتها التحتيّة تفضل الاستفادة من دوكر. خلاصة القول أن الحاويات ودوكر ليست في صراع مع الأجهزة الافتراضيّة، حيث تكمل كلّ منهما الأخرى في أعمال واستخدامات مختلفة. تُنشأ الأجهزة الافتراضيّة للتطبيقات التي عادة تكون ثابتة ولا تتغير كثيرًا، أمّا منصّة دوكر فهي مصمّمة لتكون مرنة أكثر بحيث يمكن تحديث هذه الحاويات بسهولة وباستمرار. هل دوكر مجرد "موضة"؟ أم أنّه سيحلّ محلّ الأجهزة الافتراضيّة؟ هل لديك ما تشاركنا به؟ شاركنا برأيك في التعليقات. ترجمة -وبتصرف- للمقال Docker vs. Virtual Machines: Differences You Should Know لصاحبه Simran Arora
  4. أفضل طريقة لتعلم البرمجة من الآن فصاعدا هي أن تبدأ بكتابة برامج. ستكتب برنامجاً، ثم تواجه مشاكل وتصلحها، ثم تبحث عن حلول بديلة، ثم تتعرف على طرق أفضل، ثم تعدل برنامجك وهكذا. حاول أن تطبق ما تتعلمه أولا بأول على مشروعك الخاص. لا تتنقل بين لغات البرمجة، بل اثبت على لغة واحدة حتى تتقنها تماما وتبني بها مشاريع جيدة، ثم يمكنك بعدها ان تنتقل إلى غيرها إذا كان لديك سبب قوي لذلك.
  5. موضوع DevOps ليس مجرد برنامج تتعلم استخدامه، بل هي مجموعة مواضيع ذات علاقة تحتاج لتعلمها، وهناك تفرعات عديدة له. ألق نظرة على هذا المخطط لأخذ فكرة عامة: ، ثم اقرأ المقالات ذات العلاقة في أكاديمية حسوب والمواقع ذات الاهتمام، ثم ابحث عن ما تحتاج لمعرفته وتعلمه.
  6. بالطبع، فالحركة البسيطة غير المبالغ فيها تضفي جمالية وحياة لصفحة الويب، أما الحركات المبالغ فيها فتعكر صفو الهدوء الذي يعيشه القارئ وتشتته ع الغرض الأساسي الذي وجدت لأجله الصفحة. وشكرًا لمرورك
  7. الناس ليسوا مهتمين بشراء سرير؛ إنّ ما يريدونه هو أن يناموا في الليل قريري العَين ومُرتاحين. قد لا يمانع البعض في النوم على لوح من الخشب إذا كان هذا يعني أنهم سيفيقون نشيطين. هذا ما يجعلنا (كمسوقين) في مشكلة حقيقيّة نحتاج لحلّها. على الرياديين أن يذهبوا إلى أبعد من مجرد بناء منتج؛ عليهم أن يسوّقوا لما سيسمح مُنتجهم للزبائن بفعلَه. إذا لم يفعلوا هذا، فمن الواضح أنهم ليسوا من ذوي الخبرة. وهذا ما لخّصته المستثمرة Dina Routhier في قولها: لننظر إلى بعض الأمثلة عن كيف تساعد الفوائد في التسويق للمنتَج. "افقد 15 كيلوجراما في ثلاثين يوما!"من السهل على من هو جالس على أريكته يتابع التلفاز أن يستهزئ بأفضل البرامج التسويقيّة (infomercials) التي تعرضها قنوات التلفاز في وقت متأخر من الليل. ورغم هذا، تُحقِّق هذه الإعلانات مبيعات عادة تتخطّى بكثيرٍ تطبيقَ الوّب فائق الأناقة التي يتحدّث عنه الجميع ولكن لا أحد يرغب بأن يدفع مقابل استخدامه. حقيقة الأمر أنّ صناعة البرامج التسويقيّة تلك ما زالت تتزايد. حتى أنّها وصلت إلى درجة التغطية على الإعلام التلفازي ذاته. لماذا نذكر هذا الأمر؟ إذا كان هناك ما تتميز به هذه البرامج، فهو أنها تسوّق للفائدة المرجوة من المنتَج. وأحد أسباب ذلك هو أنّهم يعلمون أن بالإمكان استمالة الناس وليس دفعهم إلى شراء المُنتَج. سبق لـClaude C. Hopkins أن قال: بيع ما له علاقة برغبات موجودة أسهل من إنشاء رغبات جديدة. قد تبدو البرامج التسويقيّة كلها متشابهة، ولكنها ناجحة، لأنّها تسوّق لحلول مطلوبة دائمًا. الأمر شبيه بالطريقة التي تأتي بها أكثر الشركات الناشئة نجاحًا لتعمل على مشكلة موجودة بالفعل أو موجودة منذ زمن، وتجعل حلّها أسهل وأسرع وأرخص وفي متناول اليد أكثر من غيره. هناك أيضًا استخدام فعّال لنظام التسويق. "15 كيلوجرامًا في 30 يومًا" عبارة جدّابة لأنك تعلم ما ستحصل عليه. تستغل أقراص التخسيس السحرية هذا الأمر للخداع، ولكن اللغة نفسها بالنسبة للبرامج الرياضية الحقيقية، مثل P90X و Insanity. لا أحد يرغب بشراء برامج رياضيّة لذاتها، إنّ ما يريده المشتري هو عضلات مشدودة وتقوية أفضل ضمن نطاق زمني معقول. ما الذي سأحصل عليه؟لندع البرامج التسويقيّة جانبًا ونلاحظ فعالية التسويق للفائدة في عالم الأعمال "الحقيقيّ". هذه الطريقة تعمل بشكل جيّد. لقد فهمت Apple هذا الأمر عندما أطلقت أول إصدار من iPod. لم تكن مشغلات MP3 شيئًا جديدًا، فقد تفوّقت هذه المُشغّلات على الأقراصَ المضغوطة. لقد كانت المشكلة في التسويق؛ لم تُستخدَم الطريقة الصحيحة في توضيح كم ستكون حياة الزبائن أفضل عندما يملكون يستخدمون جهازًا مُماثلًا. كيف تظن Apple أبدعت في خلق أسطورة iPod ؟ هل بنَتها على القوة التقنيّة، أم على ما يمكن للمستخدم عمله بجهاز iPod ؟ لقد كانت الرسالة مقنعة لأنّها –على حدّ تعبير Seth Godin–: إن ما يدعو للسخرية هو أنّ أولئك المعجبين بشركة Apple ومديرها التنفيذي الراحل ستيف جوبز –وخاصة من في مجتمع الشركات الناشئة منهم– يعانون مشاكل جمّة في مجال التسويق. تمتلئ الكثير من مواضيع HackerNews بمعلقين ذوي انتقادات لاذعة يصرّون على أنّ من يذكر أكثر المزايا التقنيّة قوّة هو من يفوز. لقد وصلت هذه المشكلة إلى جعل Justin Jackson يكتب مقالًا مشهورًا جدًّا يذكّر فيه مطوري البرمجيات بأنّهم "ليسوا "عاديين" بالنسبة للزبائن. قد يفاجئك ذلك، لكن زيادة التحدّي التقنيّ عند بناء منتَج لن يضمن لك إمكانيّة بيع كميّة أكبر منه. بمُجرّد أن تخطر على بالك فكرة لمُنتج جديد، نشرع في التّفكير بالتقنيات التي قد نستخدمها لبنائه، وننجرف في هذا الاتجاه."يمكني أن أبني هذا على واجهة برمجة تطبيقات Twilio!". "يمكنني أن أتعلم الإطار البرمجيّ الجديد لـCSS!". "يمكنني استخدام هذه الأداة الجديدة التي اشتريتها للتو!"المشكلة هي أنّ كلّ هذا يدور حولنا نحن، المُؤسّسين، وليس حول الزبائن، المستهلكين. هناك ميل طبيعي لدى الحرفي لأن يتحدّث عن حرفته. لكن تذكّر أنّ الزبائن غالبًا لن يهتموا بالتروس الداخليّة التي تحرّك المنتَج. إن ما يهمهم معرفته هو "ما الذي سأستفيده من هذا المنتَج؟" نسخة محسنة منك إنّ الناس لا يشترون منتجات؛ إنّهم يشترون نسخة محسنة من أنفسهم. وكما قال Jason Fried: وكما هو الأمر بالنسبة للعديد من نواحي التسويق، يعود الأمر دائمًا إلى الحصول على عرض قويّ للقيمة. هذا ما يغقل عنه الكثيرون، وهذا ما يدفع بعض المُعلّقين لكتابة تعليقات مثل هذا التّعليق الذي يدّل على محدودية اطّلاع كاتبه: وكأن لسان حال هذا المُعلّق يقول: يجب أن عليك الجلوس في قبو منزلك وبناء أشياء دون أن تحاول أبدًا تسويقها للناس الذين هم بأشدّ الحاجة إليها. وكما هو واضح فإنّ هذا الأمر غير معقول. ألقِ نظرة على صفحة البداية لشركة عظيمة مثل Bidsketch: عندما تقرأها تجدها متخمة بـ"التسويق للفائدة" (benefit selling) الذي ناقشناه خلال هذا المقال. "التسويق" هنا مفيد لي كزبون: أفهم جيّدًا ما تقدّمه، وما يمكنني فعله به، دون الخوض في تفاصيل لا أحتاجها. وكمثال على ما عليك أن لا تفعله، مررت مرّة بتطبيق SaaS (لم يكنّ مصممًا للمطورين) ذُكِرَ تحت العنوان الرئيسيّ مباشرة "صُنِعَ بِفَخر باستخدام Ruby on Rails". "ماذا تعني Ruby on Rails؟ هل هي مرحلة في لعبة Mario Kart؟". 99 بالمئة من المستخدمين لن يعرفوا ولن يهتموا بالأمر. هذا أشبه بعرض مخطّطات الكهرباء والماء لشخص يزور شقّتك بغرض شرائها حتّى قبل أن يبدي اهتمامًا بالأمر. إليك أمثلة لشركات تميل لأن تفهم بعمق قيمة التسويق للفوائد (لأنهم يفهمون جيّدًا كيف يُجنى المال). لا يذكر Freckle حتى مجرّد ذكر لكلمة "برمجيّة" قبل أن يذكرك بمشكلتك الأكبر عند استخدامك لتطبيق تتبّع الوقت. و تعلم SerpIQ أن المستقبل سيجيب بنعم على أسئلتهم. بمجرد أنّ تكون الفوائد واضحة، سيعلمون كيف ولماذا هي أداة أسرع وأكثر دقّة. المزايا ما زالت مهمةمن الواضح أنّ المزايا تصف المنتَج. فبمجرّد أن تسوّق للآفاق التي يمكن أن تفعلها باستخدام تلك الفوائد، ستسهّل هذه التفاصيل اتخاذ القرار. خذ شراء سيّارة على سبيل المثال؛ ما تحتاجه هو سيارة واسعة وآمنة لعائلتك، ولكن عندما يتعلق الأمر بالقرار النهائيّ، فقد تختار تلك التي فيها تدفئة في المقاعِد. إلى أن تكون الفوائد واضحة، فهذه الأمور (التفاصيل الفنيّة المتعلّقة بالمزايا) هي مجرّد جماليّات. يمكن للمزايا في غالب الأوقات أن تضع النقاط على الحروف وتضع الفوائد ضمن سياق أكبر. هناك طريقتان لعمل هذا: التعليل: تستخدم شركات التأمين مقارنة الأسعار لتوضيح سبب كون تأمينهم أرخص (عبر المزايا). بمجرد أن يتم التسويق للفوائد، تُستخدَم المزايا لتوضّح لك كيف سيتم الأمر. إذا قالت شركة استضافة بأنّ موقعك آمن بالكامل. ستريك المزايا كيف أنّ هذا الادعاء صحيح ومضمون. سوّق للفوائد أولًا، ثم وضّح المزايا التي تقدّمها لإتمام الأمر.التمييز: وصف نقاطك المتعلقة بالوسائل وتفصيلها بتوضيح المزايا التي لديك. كثيرًا ما نخبر زبائن Help Scout كيف أن أغلب خدمات الدّعم الفنّي بوكلاء خارجيين لمساعدتهم في مراجعة رسائل البريد الإلكترونيّ. أما نحن فنقوم بذلك داخليًّا مما يسمح لنا بإضفاء تكامل بين البريد الإلكترونيّ ودعم البريد الصوتيّ وهو أمرٌ لا يستطيع الآخرون عمله (تغدو هذه الميزة مهمّة فقط بعد الحديث عن مشكلة "المشاكل التي تُسببها خدمات الدّعم الفني").لدى Claude Hopkins طريقة مفيدة تتعلق بكيفيّة عرض المزايا والفوائد بطريقة صحيحة: هناك طريقة واحدة وبسيطة للإجابة عن تساؤلات كثيرة حول الإعلانات. اسأل نفسك "هل سيساعد هذا مندوبَ المبيعات في بيع المُنتجات التي لديه؟ هل ستساعدني على بيعها إذا قابلت المشتري وجهًا لوجه؟" هل ستقوم –عند قيامك بالبيع بنفسك– بالخواص التّقنية للمُنتج التي ترغب في بيعه قبل أن تُخبره بفوائده؟ تذكّر أن قيامك بالتسويق غير المبني على الفوائد لا يخدم الزبائن. أعطهم ما يريدونه بأن تظهر لهم لماذا منتجك هو "الشيء الوحيد" الذي كانوا يبحثون عنه. أخيرًا ولكن –بالتأكيد– ليس آخرًا، احذر أن تبيع "فوائد مزيّفة"، أو أن تخفي المزايا التي لديك تمامًا، وخاصّة عندما تتحدّث إلى جمهور من الشركات أو التقنيين المتقدمين. المزايا هامّة، وهي ضروريّة لدعم الحلّ الذي تسوّق له والذي يجعل الفئة المستهدفة مهتمّة في المقام الأول. ترجمة -وبتصرّف- للمقال Features Tell, but Benefits Sell لكتابه Gregory Ciotti. حقوق الصورة البارزة: Designed by Freepik.
  8. يكثر الحديث هذه الأيام عن أنماط تصميم البرمجيات، ومن الأسئلة الأكثر شيوعًا "كيف يمكنني استخدام النمط الفلاني مع التقنية (التكنولوجيا) الفلانيّة؟". أما في حالة Laravel ونمط المستودع (Repository pattern)، فكثيرًا أرى أسئلة من قبيل "كيف يمكنني أن أستخدم نمط المستودع في Laravel 4؟" أو في هذه الأيام "مع Laravel 5؟". من المهم أن تتذكر أنّ أنماط التصميم لا تعتمد على تقنيّة محدّدة، أو إطار برمجي محدد، أو لغة برمجة محددة. إذا كنت قد فهمت نمط المستودع بالفعل، فلا يهم الإطار البرمجي أو اللغة البرمجة التي ستستخدمها. المهم أن تفهم المبدأ الذي يقف خلف نمط المستودع، ومن ثم يمكنك استخدامه في أيّ تقنية تريد. آخذين هذا بعين الاعتبار، لنبدأ بتعريف نمط المستودع: يفصل نمط المستودع منطق الوصول إلى البيانات (data access logic) ويربطه مكانيًّا بكيانات الأعمال (business entities) في المنطق الأعمال (business logic). ويتم التواصل بين منطق الوصول إلى البيانات ومنطق الأعمال باستخدام واجهات (interfaces). ولتبسيط ذلك، فإن نمط المستودع نوع من الحاويات يخزّن فيه منطق الوصول إلى البيانات، بحيث يخفي منطق الوصول إلى البيانات عن منطق الأعمال. وبعبارة أخرى، نسمح لمنطق الأعمال أن يصل إلى كائن البيانات دون معرفة هيكلية الوصول إلى البيانات التي تتم خلف الكواليس. ولفصل الوصول إلى البيانات عن منطق الأعمال فوائد عدّة، منها: مركزية منطق الوصول إلى البيانات تجعل النصوص البرمجية أسهل في الصيانة.يمكن فحص منطق الأعمال ومنطق الوصول إلى البيانات كلًّا على حدة.تقليل تكرار الأكواد البرمجية.فرصة أقل للوقوع في أخطاء برمجية.الأمر كلّه يتعلق بالواجهاتكلّ ما في نمط المستودع ذو علاقة بالواجهات. تعمل الواجهة كاتفاقية تحدّد ما على فئة concrete تنفيذه.لنفكّر قليلًا. إذا كان لدينا كائني بيانات، الممثل والفلم، فما هي مجموعة العمليات الشائعة التي يمكن تطبيقها على هذين العنصرين؟ سنرغب في غالب الأحيان بالقيام بالعمليات التالية: الحصول على جميع السجلات.الحصول على مجموعة السجلّات مرقّمة.إنشاء سجلّ جديد.الحصول على سجل باستخدام المفتاح الرئيسيّ.الحصول على سجل باستخدام خواص (attributes) أخرى.تحديث سجلّ.حذف سجلّ.هل يمكنك الآن أن ترى كميّة النصوص البرمجيّة المكررة التي ستكون لدينا إذا قمنا بذلك مع كلّ كائن بيانات؟ حسنًا، هذه ليست مشكلة كبيرة بالنسبة للمشاريع الصغيرة، ولكنها أمر سيّء بالنسبة للمشاريع الكبيرة. الآن، وبعد أن عرّفنا العمليات الشائعة، يمكننا إنشاء واجهة: interface RepositoryInterface { public function all($columns = array('*')); public function paginate($perPage = 15, $columns = array('*')); public function create(array $data); public function update(array $data, $id); public function delete($id); public function find($id, $columns = array('*')); public function findBy($field, $value, $columns = array('*')); }هيكليّة الدليل Directory Structureقبل أن نتابع إنشاء فئة مستودع concrete التي ستنفّذ هذه الواجهة، لنفكّر قليلًا كيف نريد أن ننظّم النصوص البرمجيّة لدينا. عادة، عندما أنشئ شيئًا ما، أفضّل أن أفكر بطريقة تقسيمه إلى مكوّنات، حيث أرغب بأن أكون قادرًا على إعادة استخدام ذاك النصّ البرمجيّ لمشاريع أخرى. إن هيكليّة الدليل البسيطة التي أتبعها لمكونات المستودع تبدو كما يلي: ولكنها يمكن أن تكون مختلفة، كأن يكون للمكونات خيارات ضبط مثلًا. لدي في داخل الدليل src ثلاثة أدلّة أخرى، هي: Contracts وEloquent وexceptions. كما ترى، أسماء المجلدات مناسبة للغاية لما نريد وضعه فيها. ففي Contracts نضع الواجهات، أو الاتفاقيات – كما سميناها أعلاه - . ويحوي مجلد Eloquent مستودعي abstract و concrete تنفّذ الاتفاقات. ونضع في المجيد Exceptions فئات الاستثناءات. وحيث أننا ننشئ حزم، فعلينا أن ننشئ ملف composer.json، حيث نجد فيه ربطًا مكانيًّا لنطاق الأسماء (namespaces) لأدلّة معيّنة، واعتماديات حزم، وبيانات وصفيّة أخرى للحزم. فيما يلي محتوى composer.json لهذه الحزمة: { "name": "bosnadev/repositories", "description": "Laravel Repositories", "keywords": [ "laravel", "repository", "repositories", "eloquent", "database" ], "licence": "MIT", "authors": [ { "name": "Mirza Pasic", "email": "mirza.pasic@edu.fit.ba" } ], "require": { "php": ">=5.4.0", "illuminate/support": "5.*", "illuminate/database": "5.*" }, "autoload": { "psr-4": { "Bosnadev\\Repositories\\": "src/" } }, "autoload-dev": { "psr-4": { "Bosnadev\\Tests\\Repositories\\": "tests/" } }, "extra": { "branch-alias": { "dev-master": "0.x-dev" } }, "minimum-stability": "dev", "prefer-stable": true } كما ترى، فقد ربطنا Bosnadev\Repository إلى الدليل src. وهناك شيء آخر علينا أخذه بعين الاعتبار قبل البدء بتنفيذ RepositoryInterface، فحيث أنها موجودة في المجلد Contracts، فعلينا أن نحدّد نطاق الاسم لها: <?php namespace Bosnadev\Repositories\Contracts; interface RepositoryInterface {...}نحن الآن مستعدون لبدء تنفيذ المحتوى. تنفيذ المستودععلى كل مستودع فرعيّ في concrete أن يزيد من مستودع abstract لدينا، مما يعني تنفيذ اتفاقية RepositoryInterface. أما الآن، فكيف تنفّذ هذه الاتفاقيّة؟ ألقِ نظرة على method الأولى. ما الذي يمكنك قوله عنها بمجرد النظر إليها؟ تُسمى method الأولى في اتفاقيتنا بالاسم ()all للتوضيح. مهمتها هي جلب كلّ السجلات لهيئة concrete. تستقبل معامِلاً واحدًا، وهو columns$ الذي يجب أن يكون مصفوفة (array). يُستخدّم هذا المعامِل – كما هو واضح من اسمه – لتحديد الأعمدة التي ترغب بجلبها من مصدر البيانات، ومبدئيًّا نقوم بجلبها كلّها. لهئيات محدّدة، يمكن أن تبدو كالتالي: <?php namespace Bosnadev\Repositories\Contracts; interface RepositoryInterface {...}لكننا نريدها أن تكون عامّة أكثر لكي نتمكن من استخدامها متى أردنا: public function all($columns = array('*')) { return $this->model->get($columns); } في هذه الحالة this->model$ هي نسخة من Bosnadev\Models\Actor، ولهذا، فعلينا إنشاء نسخة جديدة للنموذج الموجود في مكان ما في المستودع. هنا أحد الحلول التي يمكنك استخدامها لتنفيذ هذا الأمر: <?php namespace Bosnadev\Repositories\Eloquent; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Exceptions\RepositoryException; use Illuminate\Database\Eloquent\Model; use Illuminate\Container\Container as App; /** * Class Repository * @package Bosnadev\Repositories\Eloquent */ abstract class Repository implements RepositoryInterface { /** * @var App */ private $app; /** * @var */ protected $model; /** * @param App $app * @throws \Bosnadev\Repositories\Exceptions\RepositoryException */ public function __construct(App $app) { $this->app = $app; $this->makeModel(); } /** * Specify Model class name * * @return mixed */ abstract function model(); /** * @return Model * @throws RepositoryException */ public function makeModel() { $model = $this->app->make($this->model()); if (!$model instanceof Model) throw new RepositoryException("Class {$this->model()} must be an instance of Illuminate\\Database\\Eloquent\\Model"); return $this->model = $model; } } وحيث أننا عرفنا الفئة كـ abstract، فهذا يعني أن علينا زيادتها باستخدام فئة متفرّعة عن concrete. فعند تعريف method المسمّى ()model كـ abstract، فإننا نجبر المستخدم على تنفيذ هذه الطريقة (method) في فئة متفرعة عن concrete. فمثلًا: <?php namespace App\Repositories; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Eloquent\Repository; class ActorRepository extends Repository { /** * Specify Model class name * * @return mixed */ function model(){ return 'Bosnadev\Models\Actor'; } }يمكننا الآن أن ننفذ بقية طرق (methods) الاتفاقات: <?php namespace Bosnadev\Repositories\Eloquent; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Exceptions\RepositoryException; use Illuminate\Database\Eloquent\Model; use Illuminate\Container\Container as App; /** * Class Repository * @package Bosnadev\Repositories\Eloquent */ abstract class Repository implements RepositoryInterface { /** * @var App */ private $app; /** * @var */ protected $model; /** * @param App $app * @throws \Bosnadev\Repositories\Exceptions\RepositoryException */ public function __construct(App $app) { $this->app = $app; $this->makeModel(); } /** * Specify Model class name * * @return mixed */ abstract function model(); /** * @param array $columns * @return mixed */ public function all($columns = array('*')) { return $this->model->get($columns); } /** * @param int $perPage * @param array $columns * @return mixed */ public function paginate($perPage = 15, $columns = array('*')) { return $this->model->paginate($perPage, $columns); } /** * @param array $data * @return mixed */ public function create(array $data) { return $this->model->create($data); } /** * @param array $data * @param $id * @param string $attribute * @return mixed */ public function update(array $data, $id, $attribute="id") { return $this->model->where($attribute, '=', $id)->update($data); } /** * @param $id * @return mixed */ public function delete($id) { return $this->model->destroy($id); } /** * @param $id * @param array $columns * @return mixed */ public function find($id, $columns = array('*')) { return $this->model->find($id, $columns); } /** * @param $attribute * @param $value * @param array $columns * @return mixed */ public function findBy($attribute, $value, $columns = array('*')) { return $this->model->where($attribute, '=', $value)->first($columns); } /** * @return \Illuminate\Database\Eloquent\Builder * @throws RepositoryException */ public function makeModel() { $model = $this->app->make($this->model()); if (!$model instanceof Model) throw new RepositoryException("Class {$this->model()} must be an instance of Illuminate\\Database\\Eloquent\\Model"); return $this->model = $model->newQuery(); } } الأمر سهل للغاية، صح؟ الشيء الوحيد المتبقي الآن هو حقن ActorRepository في ActorsController، أو الجزء المتعلق بالأعمال (business logic) من تطبيقنا. <?php namespace App\Http\Controllers; use App\Repositories\ActorRepository as Actor; class ActorsController extends Controller { /** * @var Actor */ private $actor; public function __construct(Actor $actor) { $this->actor = $actor; } public function index() { return \Response::json($this->actor->all()); } }استعلامات المعايير Criteria Queriesكما يمكنك أن تتخيل، فهذه الأعمال البسيطة كافية فقط لاستعلامات البسيطة. أما بالنسبة للتطبيقات الكبيرة، فستحتاج بالتأكيد لعمل بعض الاستعلامات الخاصّة لاستدعاء مجموعة بيانات محدّدة أكثر باستخدام معايير محدّدة. للقيام بذلك، نبدأ بتحديد ما على معايير الفروع (child ، أو العميل client) القيام به. وبعبارة أخرى، سننشئ فئة abstract non-instantiable باستخدام method واحدة فقط : <?php namespace Bosnadev\Repositories\Criteria; use Bosnadev\Repositories\Contracts\RepositoryInterface as Repository; use Bosnadev\Repositories\Contracts\RepositoryInterface; abstract class Criteria { /** * @param $model * @param RepositoryInterface $repository * @return mixed */ public abstract function apply($model, Repository $repository); }ستحوي هذه الطريقة (method) استعلام معايير يتم تطبيقه في فئة Repository ضمن هيئة concrete. علينا أيضًا أن نزيد على فئة Repository قليلًا لتغطية استعلامات المعايير. لكن قبل ذلك، هيّا ننشئ اتفاقية أخرى لفئة Repository. <?php namespace Bosnadev\Repositories\Contracts; use Bosnadev\Repositories\Criteria\Criteria; /** * Interface CriteriaInterface * @package Bosnadev\Repositories\Contracts */ interface CriteriaInterface { /*** @param bool $status * @return $this */ public function skipCriteria($status = true); /*** @return mixed*/public function getCriteria(); /*** @param Criteria $criteria* @return $this*/public function getByCriteria(Criteria $criteria); /*** @param Criteria $criteria* @return $this*/public function pushCriteria(Criteria $criteria); /*** @return $this*/public function applyCriteria(); }يمكننا أن نزيد فاعلية فئة Repository بتنفيذ اتفاقية CriteriaInterface: <?php namespace Bosnadev\Repositories\Eloquent; use Bosnadev\Repositories\Contracts\CriteriaInterface; use Bosnadev\Repositories\Criteria\Criteria; use Bosnadev\Repositories\Contracts\RepositoryInterface; use Bosnadev\Repositories\Exceptions\RepositoryException; use Illuminate\Database\Eloquent\Model; use Illuminate\Support\Collection; use Illuminate\Container\Container as App; /** * Class Repository * @package Bosnadev\Repositories\Eloquent */ abstract class Repository implements RepositoryInterface, CriteriaInterface { /** * @var App */ private $app; /** * @var */ protected $model; /** * @var Collection */ protected $criteria; /** * @var bool */ protected $skipCriteria = false; /** * @param App $app * @param Collection $collection * @throws \Bosnadev\Repositories\Exceptions\RepositoryException */ public function __construct(App $app, Collection $collection) { $this->app = $app; $this->criteria = $collection; $this->resetScope(); $this->makeModel(); } /** * Specify Model class name * * @return mixed */ public abstract function model(); /** * @param array $columns * @return mixed */ public function all($columns = array('*')) { $this->applyCriteria(); return $this->model->get($columns); } /** * @param int $perPage * @param array $columns * @return mixed */ public function paginate($perPage = 1, $columns = array('*')) { $this->applyCriteria(); return $this->model->paginate($perPage, $columns); } /** * @param array $data * @return mixed */ public function create(array $data) { return $this->model->create($data); } /** * @param array $data * @param $id * @param string $attribute * @return mixed */ public function update(array $data, $id, $attribute="id") { return $this->model->where($attribute, '=', $id)->update($data); } /** * @param $id * @return mixed */ public function delete($id) { return $this->model->destroy($id); } /** * @param $id * @param array $columns * @return mixed */ public function find($id, $columns = array('*')) { $this->applyCriteria(); return $this->model->find($id, $columns); } /** * @param $attribute * @param $value * @param array $columns * @return mixed */ public function findBy($attribute, $value, $columns = array('*')) { $this->applyCriteria(); return $this->model->where($attribute, '=', $value)->first($columns); } /** * @return \Illuminate\Database\Eloquent\Builder * @throws RepositoryException */ public function makeModel() { $model = $this->app->make($this->model()); if (!$model instanceof Model) throw new RepositoryException("Class {$this->model()} must be an instance of Illuminate\\Database\\Eloquent\\Model"); return $this->model = $model->newQuery(); } /** * @return $this */ public function resetScope() { $this->skipCriteria(false); return $this; } /** * @param bool $status * @return $this */ public function skipCriteria($status = true){ $this->skipCriteria = $status; return $this; } /** * @return mixed */ public function getCriteria() { return $this->criteria; } /** * @param Criteria $criteria * @return $this */ public function getByCriteria(Criteria $criteria) { $this->model = $criteria->apply($this->model, $this); return $this; } /** * @param Criteria $criteria * @return $this */ public function pushCriteria(Criteria $criteria) { $this->criteria->push($criteria); return $this; } /** * @return $this */ public function applyCriteria() { if($this->skipCriteria === true) return $this; foreach($this->getCriteria() as $criteria) { if($criteria instanceof Criteria) $this->model = $criteria->apply($this->model, $this); } return $this; } } إنشاء معايير جديدة، حيث يمكنك الآن أن ترتب مستودعاتك بسهولة أكبر. لست بحاجة لأن تكون مستودعاتك مكونة من آلاف الأسطر. يمكن أن تبدو فئة المعايير لديك كالآتي: <?php namespace App\Repositories\Criteria\Films; use Bosnadev\Repositories\Contracts\CriteriaInterface; use Bosnadev\Repositories\Contracts\RepositoryInterface as Repository; use Bosnadev\Repositories\Contracts\RepositoryInterface; class LengthOverTwoHours implements CriteriaInterface { /** * @param $model * @param RepositoryInterface $repository * @return mixed */ public function apply($model, Repository $repository){ $query = $model->where('length', '>', 120); return $query; } }استخدام للمعايير (Criteria) في المتحكّمات (Controllers)الآن وقد صارت لدينا معايير بسيطة، لنرَ كيف يمكننا استخدامها. هناك طريقتان يمكنك اتباعهما لتطبيق المعايير على مستودع. الأولى باستخدام طريقة ()pushCriteria: <?php namespace App\Http\Controllers; use App\Repositories\Criteria\Films\LengthOverTwoHours; use App\Repositories\FilmRepository as Film; class FilmsController extends Controller { /*** @var Film*/private $film; public function __construct(Film $film) { $this->film = $film; } public function index() { $this->film->pushCriteria(new LengthOverTwoHours()); return \Response::json($this->film->all()); } }هذه الطريقة مفيدة إذا كنت ترغب بتطبيق أكثر من معيار في نفس الوقت، حيث يمكنك رصّها معًا كما تشاء، ولكن إذا رغب بتطبيق معيار واحد فقط، فيمكنك استخدام طريقة ()getByCriteria: <?php namespace App\Http\Controllers; use App\Repositories\Criteria\Films\LengthOverTwoHours; use App\Repositories\FilmRepository as Film; class FilmsController extends Controller { /** * @var Film */ private $film; public function __construct(Film $film) { $this->film = $film; } public function index() { $criteria = new LengthOverTwoHours(); return \Response::json($this->film->getByCriteria($criteria)->all()); } }تثبيت الحزميمكنك تثبيت هذه الحزمة بإضافة الاعتمادية التالية إلى قسم require في ملف composer لديك: "bosnadev/repositories": "0.*"وتنفيذ composer update بعد ذلك، الخلاصةلاستخدام المستودعات في تطبيقك العديد من الفوائد. من أشياء بسيطة كتقليل تكرار الأكواد ومنعك من ارتكاب أخطاء برمجيّة وجعل تطبيقك أسهل في التكبير والتوسعة، والاختبار، والصيانة. من وجهة نظر هندسيّة، فقد تمكنت من عزل الاهتمامات. المتحكّم (controller) لديك ليس بحاجة لأن يعرف كيف وأين تخزَّن البيانات. بسيط وجميل. تجريديّ (Abstract). ترجمة وبتصرف للمقال: Using Repository Pattern in Laravel 5.
  9. قبل أن نذهب إلى الموضوع الرئيسيّ للمقال، سأعطيك لمحة قصيرة عن مشاكل التصميم التي قد تواجهها. لقد اشتكى لي أحد زبائني بأن بعض الصفحات تفتح ببطء شديد. وعندما أقول ببطء شديد، فإنني أعني ذلك! فقررت أن أصحح تلك الصفحة (بعمل debugging)، وما رأيته قد صدمني. لقد أظهر لي قسم الاستعلامات (queries) أن تلك الصفحة كانت تنفَّذ بعد القيام بكم هائل من الاستعلامات تعدّى 16500 استعلامًا!! لقد وجدت أن جزءًا من النصّ البرمجي هو سبب تلك المشكلة. لقد كانت هناك ثلاث حلقات foreach تستعلم عن خاصيّة والخواص الفرعيّة التابعة لها. لقد كانت تعمل جيدًا إلى أن صار في قاعدة البيانات 5500 عنصرًا. وفيما يلي ما كان يحدث: $main_object = MainObject::all(); foreach($main_object as $object) { echo $object->some_property; foreach($object->related_object as $related) { echo $related->some_property; echo $related->another_property; } foreach($object->another_related as $another) { echo $another->some_property; echo $another->another_property; } }إذا كان الاستعلام ;()main_object = MainObject::all$ يعيد 5500 نتيجة، فستعيد حلقة foreach الأولى ذلك القدر أيضًا، وكذلك بالنسبة للثانية والثالثة. باستخدام ORM، كثيرًا ما يقع المبرمجون في فخّ كتابة استعلامات قواعد بيانات غير كفؤة، وتجعلها ORM أكثر صعوبة في الاكتشاف. تُسمّى هذه المشكلة بمشكلة N+1 (بالإنجليزيّة N+1 problem). وأظن المطور السابق لم يكن على علم بذلك. ولتفادي هذه المشكلة، نستخدم التحميل الحثيث (eager loading). ما هو التحميل الحثيث؟لتبسيط الأمر، التحميل الحثيث طريقة تُعنى بعمل كل شيء عند الطلب. وهذه الطريقة أيضًا على العكس تمامًا من التحميل الكسول (lazy loading) عندما ننفذ المهام عند الحاجة. يساعدنا التحميل الحثيث على تجنب مشكلات الأداء، كما رأيت في مثالي أعلاه. ستفهم الأمر أكثر من خلال مثال، لذا لنتخيل الوضع التالي: لدينا نموذج علاقة هيئة محسّنة (بالإنجليزيّة: Enhanced Entity Relationship، واختصارًا EER)، بثلاث هيئات، كلّ منها مرتبطة بالأخرى. يمكنك أن تقرأ EER كما يلي: يمكن لكل عضو أن يملك العديد من المحلات، ولكن المحل الواحد ملك لعضو واحد فقط. يمكن للمحل الواحد أن يحوي العديد من المنتجات، ولكن المنتج الواحد لا يكون إلّا في محل واحد. الخطوة التالية هي إنشاء نماذج Eloquent لهذه الهيئات: العضو: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Member extends Model { protected $fillable = ['username', 'email', 'first_name', 'last_name']; public function stores() { return $this->hasMany('App\\Store'); } }المحلّ: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Store extends Model { protected $fillable = ['name', 'slug', 'site', 'member_id']; public function member() { return $this->belongsTo('App\\Member'); } public function products() { return $this->hasMany('App\\Product'); } }المُنتَج: <?php namespace App; use Illuminate\Database\Eloquent\Model; class Product extends Model { protected $fillable = ['name', 'short_desc', 'long_desc', 'price', 'store_id', 'member_id']; public function store() { return $this->belongsTo('App\\Store'); } }تخيّل أنك تبني تطبيقًا يسمح لمستخدميك أن يُنشئوا محالّهم التجاريّة الخاصّة. يمكن للمستخدمين –كما هو الحال بالنسبة للمحال الأخرى كلها طبعًا– أن يُنشئوا منتَجات عديدة. وأيضًا، يمكننا أن ننشئ صفحة واحدة تعرض كل المحلات وأفضل المنتجات لكل محلّ. شيء من قبيل هذا: يمكن أن ينتهي بك المطاف إلى الحصول على شيء كهذا في المتحكّم لديك: <?php namespace App\Http\Controllers; use App\Repositories\StoreRepository; class StoresController extends Controller { protected $stores; function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->all(); return \View::make('stores.index')->with('stores', $stores); } }وفي العرض الذي ستقدم فيه تلك البيانات: @foreach($stores as $store) <h1>{{ $store->name }}</h1> <span>Owner: {{ $store->member->first_name . ' ' . $store->member->last_name }}</span><br> <h2>Products:</h2> @foreach($store->products as $product) <h3>{{$product->name}}</h3> <span>{{$product->short_desc}}</span><br/><br/> <span>Price: {{$product->price}}</span><br/> <?php Debugbar::info('Product displayed'); ?> @endforeach <br/>========================<br/> @endforeachوالنتيجة كالتالي: ومن اجل هذا المثال، زوّدت قاعدة البيانات بخمس مستخدمين، وثلاثة محالّ، وأربعة منتَجات. يقوم الاستعلام الأول باستدعاء كل المحال من قاعدة البيانات، وهذا هو الجزء +1 من مشكلة N+1. في هذا المثال تحديدًا، حرف N يمثّل عدد المحلات التي أرجعها لنا الاستعلام الأول، حيث أنها تمثل عدد المرات التي سنقوم فيها بالاستعلام select * from على جدولي products و members. وبما أن لدينا 3 محلات، فسنستعلم 3 مرات على جدول المستخدمين، وثلاث مرات على جدول المنتجات. وفي النهاية، قمنا بتنفيذ الاستعلامات بعدد مرات قدره 3+3+1. تخيل الآن ما الذي يمكن أن يحدث لو كان لديك 5000 أو 10000 محل؟ سيكون لديك في تلك الحالة عشرة آلاف إلى عشرين ألف استعلام في كل مرة يقوم فيها أحد المستخدمين بزيارة الصفحة. وماذا لو كانت لديك عشرة آلاف أو مئة ألف زيارة كلّ أربع وعشرين ساعة؟ هذا كابوس! من الواضح الآن أن هذا التوجّه مدمّر للأداء. وبغض النظر عن نوع قاعدة البيانات التي تستخدمها، وعن مدى قوة الخادم الذي لديك، فستصل دائمًا إل تلك النقطة التي يقف فيها العتاد القوي لديك عاجزًا. يمكنك أن تحسّن الأداء بعمل cache لهذه الاستعلامات، باستخدام Redis على سبيل المثال. سيؤدي هذا الغرض، ولكن لبعض الوقت فقط. وبتلك الطريقة، أنت فقط تؤجل النهاية الحتميّة التي ستكلّفك الكثير من المال والوقت، وفي الغالب ستفقد بعض الزبائن، أو أنّ قاعدة بياناتك ستضعف كثيرًا. وهنا يأتي التحميل الحثيث لينقذك من هذه الورطة. استخدام التحميل الحثيث في Laravel بسيط للغاية. العلاقات التي ترغب أن يتم تحميلها بشكل حثيث تحددها في طريقة with كما يلي: $stores = Store::with('member','products')->get();الآن، بدل استخدام 7 استعلامات، قلّلنا باستخدام التحميل الحثيث عدد الاستعلامات إلى 3 فقط: وستكون ثلاثة استعلامات حتى ولو كانت لديك عشرة آلاف مدخلة في جدول المحلات. وكما ترى، فإن الاستخدام السليم للتحميل الحثيث يمكن أن يؤدي إلى تحسين أداء تطبيقك بقدر هائل. ولكي نحصل على تحسن للأداء بالفعل، فعلينا أن نوجد فهرسًا لحقل الهويّة id في جدولي members و products. ومع وجود كمّ هائل من السجلات، فإن تنفيذ (... ,'in( '1', '2 على حقل غير مفهرس سيأخذ وقتًا طويلًا. وبعد هذه المقدمة عن التحميل الحثيث، هيا بنا نرى كيف يمكننا أن نستخدم العلاقات مع المستودعات. تمديد فئة المستودعسأريك طريقة واحدة يمكنك فيها أن تستخدم العلاقات في فئات مستودعات concrete. وهنا مثال عن النتيجة النهائيّة: function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->with('member', 'products')->all(); .... }وكما ترى هنا، لدينا طريقة with يمكنك أن تسلسل فيها نموذج العلاقات. ستكون هذه الطريقة شبيهة بطريقة with في Laravel’s Query Builder. public function with($relations) { if (is_string($relations)) $relations = func_get_args(); $this->with = $relations; return $this; }نحتاج الآن لأن نربط كلّ علاقة من العلاقات التي قمنا بتقديمها بالنموذج: protected function eagerLoadRelations() { if(!is_null($this->with)) { foreach ($this->with as $relation) { $this->model->with($relation); } } return $this; }وها هو ذا، والشيء الوحيد الذي تبقّى هو أن نحدّث طريقة مستودع ()all (وأي شيء آخر ترغب بتحديثه) لاستخدام التحميل الحثيث: public function all($columns = array('*')) { $this->applyCriteria(); $this->newQuery()->eagerLoadRelations(); return $this->model->get($columns); }وكما سبق وذكرت، فيمكنك أن تضيف عدّة علاقات ضمن طريقة ()with. وفيما يلي مثال على StoresControler: <?php namespace App\Http\Controllers; use App\Repositories\StoreRepository; class StoresController extends Controller { protected $stores; function __construct(StoreRepository $stores) { $this->stores = $stores; } public function index() { $stores = $this->stores->with('member', 'products')->all(); return \View::make('stores.index')->with('stores', $stores); } }وفي العرض يمكنك أن تعرض البيانات بالطريقة التي تريدها، ولغرض التجربة يكفي هذا: @foreach($stores as $store) <h1>{{ $store->name }}</h1> <span>Owner: {{ $store->member->first_name . ' ' . $store->member->last_name }}</span><br> <h2>Products:</h2> @foreach($store->products as $product) <h3>{{$product->name}}</h3> <span>{{$product->short_desc}}</span><br/><br/> <span>Price: {{$product->price}}</span><br/> <?php Debugbar::info('Product displayed'); ?> @endforeach <br/>========================<br/> @endforeachوكما هو متوقع، لدينا الآن هذه الاستعلامات الثلاثة فقط: الخلاصةيمكنك باستخدام التحميل الحثيث أن تحسّن أداء تطبيقك. وأحيانًا، عندما يكبر التطبيق، حتى التحميل الحثيث ليس كافيًا للحفاظ على أعلى أداء. في الدرس التالي سأريك كيف يمكنك تجميل مستودعاتك لتقوم بعمل cache للاستعلامات من أجل أداء أفضل. ترجمة -وبتصرف- للمقال: Using Repository Pattern in Laravel 5 - Eloquent Relations and Eager Loading.
  10. عمل أطر مفرغة -أو تصاميم مبدئيّة- أثناء التصميم لا يكلف شيئًا تقريبًا، ولكن يمكنه أن يحقق عائدًا ممتازًا. ورغم أن العديد من المصممين يبدؤون برسم "سكِتش" في ذهنهم، ومن ثمّ يضعونه في برنامج فوتوشوب أو حتى يبدؤون بكتابة الأكواد مباشرة، بينما يبدأ آخرون على الورق. نعم، هو الورق العادي الذي تعرفه، والذي تكتب عليه بالقلم. يبدو هذا كتقنية عمرها عشر سنوات، ولكن حتى الآن ما زال أفضل المصممين في هذا العالم يستخدمونه لصالحهم. سيوفر عليك عمل تصميم مبدئيّ الكثيرَ من الإحباط في المراحل اللاحقة من تطوير المشروع، حيث يؤكّد بأنه ليس هناك أشياء عليك التراجع عنها أو إعادة تصميمها. إذا قمت بعمل تصميم أوليّ بطريقة سليمة، فبإمكانك أن تبيت مرتاح البال بأنك لن تضطر مستقبلًا لإعادة التصميم من البداية. إن ما تعنيه الأطر المفرغة هو وضع أفكار التصميم على الورق لكلّ من صفحات الموقع. في الغالب ستتشارك كل الصفحات ببعض العناصر، ولهذا فستكون الصفحة الأولى أكثر صعوبة في التصميم، بينما ستكون بقيتها أقل صعوبة، حيث تكون قد حصلت على فكرة مبدئيّة عن النمط العام للتصميم. أبق في بالك أن هذه العناصر مهمّة لأيّ تصميم. عندما تقلّب بين الصفحات، سيكون على المستخدم أن يقدر على التعرف على الصفحة وأن يعلم أنه لم يغادر الموقع ويذهب إلى موقع آخَر. أبق دائمًا على التنقلات والأقسام المهمة (المحتوى، الشريط الجانبي، ذيل الصفحة) في نفس المكان، ولكن هذا صار شائعًا كما لو أنه دليل للمبتدئين في التصميم، لذا لننتقل إلى أمور متقدمة أكثر. الأطر المفرغة – نظرة عامةلكي تكون قادرًا على استخدام إطار مفرغ، فأنت بحاجة إلى معرفة كيف يعمل. ما يفعله الإطار المفرغ بسيط، فهو يُظهِر الشكل العام للوقع والمكونات الرئيسيّة على الورق. يمكنك أن تستخدم أشكال مختلفة كصناديق وحاويات لرسم المحتوى فيها، وتنقلات، وعناصر وظيفيّة أخرى. قد تسأل نفسك، لم نستخدم الأشكال؟ الإجابة بسيطة: لأنها تسمح لنا بأن نركّز على التصميم أكثر وان ننسى الأكواد والتوافقية بين المتصفحات والصور وما إلى ذلك. إنه تصميم بسيط ونقيّ. الصورة من Zach Hoeken. الأطر المفرغة أم تصاميم فوتوشوب؟وكبديل عن التصاميم الأوليّة للمواقع على الورق، يمكن إنشاء التصميم المرئيّ على برنامج فوتوشوب أولًا. ورغم أن لها مزايا إلى حدّ ما، فإن إنشاء الشكل العام في فوتوشوب غير عمليّ، وذلك لأنه لا يسمح لك بالتركيز على العناصر الأساسيّة للتصميم. ولهذا، إذا أردت البدء بالتصميم في فوتوشوب، فقد تبدأ أيضًا بالتفكير في الألوان والصور والخطوط. لا حاجة لهذا الأمر إذا بدأت العمل على الورق. والعمل على الورق أسرع بكثير أيضًا، ولذا لِمَ لا تقوم بها بهذه الطريقة؟ ولهذا، يمكنك أن تبدأ التصميم في فوتوشوب في مرحلة لاحقة، ولكن لا أنصح بعمل ذلك قبل أن تكون لديك فكرة واضحة عن ما ترغب بالحصول عليه من المشروع. الطريقة الوحيدة لتحقيق ذلك هي البدء على الورق. يمكنك أن تدعو الإطار المُفرَغ بأنه "سكِتش" إذا أردت ذلك. وفي الحقيقة أن الأطر المفرغة هي سكتش بسيط للموقع. توصل الأطر المفرغة بعض الأفكار للزبون، حيث يمكنه أن يقبلها أو يرفضها. إذا رفضها، فسيكون من السهل بالنسبة لك أن تأخذ ورقة أخرى وترسم عليها أفكار أخرى من البداية. الهدف الأساسيّ من الأطر المفرغة هو أن تسمح لك بالتركيز على الأشياء المهمة في الموقع، وهي: كيف تبدو كل صفحة، وأين تقع أهم العناصر فيها، وكيف تحقق التوازن الإيجابيّ الذي تريده بشكل عام. وبعد أن تكون قد حصلت على فكرة عن ما يريده الزبون، ويقبل هو التقسيم الأساسي للموقع، يمكنك حينها أن تطوّر السكتش البسيط إلى شيء أكثر تفصيلاً. قد يكون الآن الوقت المناسب لبدء التفكير في الخطوط والألوان والصور. الصورة من Denkbeelhouwer. مرحلة عمل التصاميم الأوليةمن الضروريّ بالنسبة للمصممين والزبائن أن يعملوا معًا أثناء هذه المرحلة من المشروع. وحيث أنّه ليس لدى الزبون الكثير ليقوله أثناء مرحلة كتابة الأكواد، فهذه هي المرحلة التي يمكنه فيها تقديم الكثير من المدخلات التي عليك أن تأخذها بعين الاعتبار. تذكر أنه بمجرد موافقته على التصميم، فسيعطيك وهو راض حرية أكثر في الأفكار الأخرى؛ في هذه المرحلة يثق فيك وفي خبراتك. سيكون هذا مشروعًا طويلًا وصعبًا إذا لم تحصل منه على الموافقة على الإطار المفرغ الأساسيّ. إذا كنت زبونًا فتذكر أن لا تركز كثيرًا على عدم وجود ألوان وصور وخطوط وأمور أخرى تتعلق بالنمط. إن وظيفة المصمم في هذه المرحلة هي أن يعطيك فكرة بسيطة عن ما يراه بأنه جيد لك. إذا طلبت منه أطر مفرغة مفصلة أكثر ورفضتها ثلاثة أو أربعة مرات، فسيكلفك ذلك الكثير من المال. ومن ناحية أخرى، إذا طلبت أطر مفرغة بسيطة ورفضتها، فلن تكلفك بذلك القدر، وذلك لأن رسمها والتفكير فيها أسهل. أدوات لعمل تصاميم أولية للمواقعفيما يلي قائمة بالأدوات التي اختبرتها حديثًا لأرى إلى أيّ حد يمكن للمصممين الاعتماد عليها لبناء أطر مفرغة. إذا لم يكن الورق مناسبًا لك، فهناك خيارات أخرى ممكنة (دون ترتيب معين): 1. iPlotzتسمح ك هذه الأداة بأن تصنع أطر مفرغة يمكنك أن تنقر عليها وتتنقل خلالها. يسمح لك هذا بإنشاء تجربة مشابهة للموقع الحقيقيّ. ورغم أن بإمكانك الحصول على حساب مجانيّ، إلا أنني أنصحك بالحصول على واحد من حسابات Premium إذا كنت جادًّا في أن تبدأ بعمل التصاميم الأولية للمواقع واتخاذها كمهنة من الآن. 2. Balsamiqإذا كنت تحب الرسم، فستعطيك هذه الأداة شعورًا مشابهًا لذلك، إلا أنه رقميّ هذه المرة. يمكن تضبيط وإعادة ترتيب هذه الأدوات بسهولة، والتحكم بها سهل أيضًا. النتائج نظيفة، ومن المزايا الأخرى لها هو أنّ كل شيء يمكن تكرارها في الوقت الحقيقيّ. 3. Pencil Projectيمكن استخدام هذه الأداة لعمل مخططات انسيابية وتصاميم أوليّة للواجهات بسهولة. 4. templatrرغم أنه لن يسمح لك برسم أيّ شيء، إلى أن هذه الأداة تمكنك من إنشاء تصاميم لموقعك أثناء العمل. لست بحاجة لمعرفة HTML ويمكنك تنزيل القالب في النهاية بنقرة زر واحدة. 5. Flair Builderيمكن لهذه الأداة التفاعل مع الأطر المفرغة بسرعة عالية جدًّا. هذه الأداة سهلة الاستخدام وتأتي مع لوحة من العناصر الفعالة التي ستسهل مهمة إنشاء تصاميم أوليّة. هذه الأداة تفاعليّة، وستحسن تجربتك كثيرًا. صورة من Michael Lancaster. خلاصة القولالأطر المفرغة، أو التصاميم الأوليّة للمواقع، هي عملية يعرفها الكثير من المصممين، رغم أن القليل منهم فقط من يستخدمونها. ورغم أنها تبدو بأنها تأخذ الكثير من الوقت، إلا أنها -على المدى البعيد- ستساعدك كثيرًا. إذا كنت تعرف كيف تتواصل بطريقة سليمة وأن تعمل عن قرب مع الزبون، أثناء مرحلة عمل التصاميم الأولية، فستتم بقية العمل بسلاسة أكبر مما تتوقع. أنصحك كثيرًا أن تقوم بعمل تصميم أوليّ لعملك قبل البدء في كتابة الأكواد، أو أن تُنشئ التصميم الأولي بأكمله في فوتوشوب. هذا سيجعل المهمة كلها أسهل لك، وسيوفر عليك الكثير من الإحباط طوال مدة العمل. وإلى المرة القادمة، تواصل معنا في الردود، وأخبرنا برأيك. هل تقوم بعمل تصاميم أوليّة للتصاميم التي تعمل عليها؟ وما مدى جدوى ذلك بالنسبة لك؟ وإذا لم تكن تفعل ذلك، فلماذا؟ ترجمة -وبتصرف- للمقال: Beginner's Guide to Wireframes and Tools to Create Them.
  11. تتطور أدوات التصميم المبدئي (prototype) للواجهات الرسومية UI بسرعة. لقد أتى إصدار فوتوشوب 2015 محمّلًا بمزايا جيدة تتعلق بـPreview CC الذي يسمح للمصممين بعرض ألواح التصميم الخاصة بهم وكذلك تراكيب الطبقات (layer comps) على الأجهزة. إن رؤية العمل ضمن سياقه على الأجهزة طريقة ثمينة لتقييم وتحسين المفهوم المتعلق بالتصميم. الوصول بالعمل إلى شاشات الأجهزة ذات العلاقة لهو مفتاح الوصول إلى توجهات تقديم المحتوى (content first approaches). التصميم الأولي الرقمي هام للمراحل اللاحقة، حيث يتم تحسين العمل وتطبيق التصميم المرئيّ عليه. سنناقش في هذا المقال الطرق المتبعة في المراحل الأولى للتصاميم الأولية الأقل دقّة التي يمكنك أن تطبقها قبل استخدام الأدوات الرقميّة، إضافة إلى ما عليك أن تبقيه في بالك عند عمل تصميم أولي لواجهة مستجيبة وواجهة تطبيق للأجهزة الكفيّة. ما هو التصميم الأولي (prototype)؟التعريف المفضل لدي لكلمة prototype تأتي من المصمم Adam St. John Lawrence: يعدّ المصممون مهارة التصميم الأوليّ مهارة أساسيّة، حيث يسمح التصميم الأولي باستكشاف أفكار عديدة بسرعة لعرض المفاهيم على زبائننا بدلًا من أن نصفها لهم، وأن نختبر التصاميم في مراحلها الأولى. الدقّة العالية والمنخفضةإن عملية التصميم التي تشمل حلقة من التصميم الأولي، والاختبار، ومعاودة الكرّة، تتيح أفضل فرصة ممكنة للحصول على منتج نهائي جيّد. دقّة التصميم الأولي ستزداد تدريجيًّا مع الوقت في المشروع، حيث تتضح الأفكار أكثر ويقترب الفريق أكثر نحو شيء جاهز للاستخدام. الطرق الأسرع والأرخص والأسهل في التنفيذ هي الأفضل في بداية المشروع. يجب أن تتطور دقة التصميم الأولي مع الوقت. لقد تم اقتباس المخطط أعلاه من Scott Klemmer. عمل سكتش على الورق سكِتشات المراحل الأولى تستعرض تجربة المستخدِم لتطبيق جهاز محمول. إن عمل سكتشات لهو من تقنيات التصميم الأولي الأكثر بساطة. السكتش (sketch، وجمعه سكِتشات) لا يُنتج بالضرورة تصميمًا أوليًّا، ولكن السكتشات هي لبنات البناء الأولى، وهي النسخة الأولى ومرحلة البداية للشيء الذي تعمل عليه. ليس من الضروري أن تجيد الرسم، ولا يتعلق الأمر بجعل الشيء يبدو جميلًا. إن المربعات والمستطيلات البسيطة ممتازة لرسم سكتشات غير دقيقة. يتعلق رسم السكتش في هذه المرحلة بالعمل على أفكار كثيرة بسرعة. ورسم السكِتشات (sketches) أداة تسمح بمشاركة الرؤية مع المعاونين (شركاء، زبائن، زملاء، ...). نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: يمكن أن تساعدك الرسومات البسيطة للواجهة (UI stencils) بأن ترسم سكِتشًا لعناصر الواجهة الشائعة الخاصة بمنصة معينة بسرعة.سيساعدك رسم عدة أحجام للشاشات بجانب بعضها بعضًا للمقارنة على التفكير في التصميم عبر أحجام شاشات متعددة. ارسم سكِتشاتك بحجم صغير ومتوسط وكبير بجانب بعضها، ولا تنتقل إلى صفحة أخرى قبل أن تأخذ جميع أحجام الصفحة التي تعمل عليها بعين الاعتبار.رسم سكِتش في نطاق العالم الحقيقي طريقة ممتازة لتكون واقعيًا فيما يتعلق بتناسب الحجم، وخاصة على الشاشات الصغيرة.القوالب الموجهة لشاشات اللمس على الأجهزة المحمولة رائعة للتأكد من أنها تناسب الفئة المستهدفة من مستخدمي الأجهزة ذات شاشات اللمس، حيث تكون أجهزتهم كبيرة بما يكفي لتناسب التصميم عند الاستمرار في العمل عليه. رسم سكِتشات على اللوح يسمح رسم السكِتش على اللوح بجعل العمل مرئيًّا لفريق أكبر. رسم سكِتشات على اللوح طريقة رائعة للعمل. هذا الوسيط (اللوح) على وجه الخصوص مناسب لجلسات رسم السكِتشات التعاونية. تشجّع المساحة الكبيرة والأقلام كبيرةُ الحجمِ على القيام بعمل أكبر وأقرب إلى مفهوم "سكِتش"، ويمكن أن يساعد أعضاء الفريق الخجولين أو المترددين على أن يشاركوا. إن العمل على لوح يعني أن أكثر من شخص يمكن أن يعملوا على نفس السكِتش أو الفكرة. يسهُل مسح السكِتشات المرسومة على لوح والإضافة إليها والعمل عليها، مما يعني أن أعضاء الفريق سيتمكنون من أن يعملوا على التفاصيل معاً وبسرعة. نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: أبقِ في بالك أن العمل على لوح بحجم كبير لا يعبر عن القيود التي تواجهك على شاشات أصغر. بمجرد أن يتم تطوير فكرة، حاول التبديل إلى رسم سكتشات بمقياس رسم 1:1 على الورق أو باستخدام مناطق محجوزة مسبقًا على اللوح لتقييد العمل.لا تنسَ أن توثِّق السكتشات! خذ صورًا للتقدم قبل أن تنتقل إلى شيء آخَر.للعمل على تصاميم مستجيبة، ارسم سكتشات لإصدارات صغيرة ومتوسطة وكبيرة لنفس الصفحة جنبًا إلى جنب.عمل تصاميم أوليّة على الورق: تصميم أولي بسيط على الورق في بداية العمل. يمكن للتصميم الأولي على الورق أن يتراوح مستويات مختلفة من الدقّة، من مجموعة سكتشات على أوراق منفصلة، إلى عمل تفصيليّ على الورق، إلى أُطُر مفرغة يمكن تصميمها حاسوبيًّا ثم طباعتها. اختبار التصاميم الأولية على الورق طريقة سهلة وغير مكلفة للتحقق من الأفكار. يمكنك أن تسأل المستخدمين أن يعبروا ببساطة عن ما يرونه، أو أن يقوموا بعمل اختبار يتعلق بالوظيفة. يمكن للإنسان أن يعمل كحاسوب وأن يُبدِل الصفحات أو يخرج نوافذ منبثقة وأن يتفاعل مع المستخدم بشكل عام. هذه طريقة فعَالة للغاية، ويتفاعل معها المشاركون بجدية. تُدعى هذه الطريقة من التصاميم الأولية لـ"ساحر أوز" (بالإنجليزية: “Wizard of Oz prototyping”، كما في الرواية الأمريكيّة). نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: يُمكِن للودجات (جمع وِدجَة، بالإنجليزية widget) أن تُمثَّل بورقة أو بطاقة.يُفضَّل العمل على التحجيم في هذه المرحلة، وخاصة إذا كنت تنوي اختبار الواجهة باستخدام النماذج الورقية.أنشئ إطارات أجهزة بالورق أو الورق المقوّى لعرض الصفحات بداخلها.أنشئ قوائم منسدلة وعناصر تفاعلية أخرى بقصّ وطيّ قطع الورق، حيث يمكن إلصاقها باستخدام اللاصق أو تمريرها عبر فتحات في الصفحة.الصق شاشات النموذج الأوليّ الورقيّة بأجهزة حقيقية لأخذ فكرة عن كيفيّة استخدام الناس للجهاز في سياق الواقع، وإلى أيّ حدّ يمكنهم أن يصلوا في الشاشة عند إمساكهم للجهاز في وضعيات مختلفة.التفاعل بلعب الأدوارالتفاعل جزء مهم من تجربة المستخدم (UX). تطوير هذه النماذج الأولية رقميًّا سيأخذ كثيرًا من الوقت ولن يكون واقعيًّا في المراحل الأولى من المشروع. من الطرق السريعة والمجدية اقتصاديًّا وممتعة لتجربة سلاسة التصميم والتفاعل معه: تمثيل الأدوار. أحد الأشخاص يمثل دور الصفحة أو التطبيق، والآخَر يلعب دور المستخدِم. يُساعد التفكير في تجربة المستخدم كمحادثة أو تفاعل ثنائيّ الاتجاه على التأكد من أنّ التجربة تتبع تسلسلًا منطقيًّا بشريًّا. يمكن أيضًا أن تكشف التعبيرات المتخصّصة أو التي يحتمل أن تكون مُبهمَة. نصائح للتصاميم الأولية للواجهات المستجيبة وواجهات الموبايل: فكّر بالرسائل أو لغة التفاعل الخاصّة بالمنصة (البيئة، نظام التشغيل، الجهاز ...) عند تصميم واجهات الموبايل.خذ بعين الاعتبار الاختلاف في الشكل العام بين الأحجام المختلفة للشاشات، وكيف يمكن له أن يؤثر على المسار المحادثة/التفاعل.خلاصةها قد عرفت! ارسم سكتش، اختبر التصميم على الورق، وقم بتمثيل الأدوار التي تتعلق بطريقة التفاعل لتقفز إلى بداية متقدمة في إنشاء تجربة مستخدم ممتازة. ترجمة -وبتصرف- للمقال: Early Stage UX Prototyping: Tips for Mobile and Responsive Design لصاحبه: Linn Vizard. حقوق الصورة البارزة: Designed by Freepik.
  12. استكشف الأفكار باستخدام ورقة وقلمإنّ استخدام الورقة والقلم طريقة جيدة لبدء عمل سير الاستخدام ورسم السكتشات (جمع سكِتش sketch) غير الدقيقة للتصميم. ويتيح الورق -كوسيط للتصميم- مرونة كبيرة ويسمح لك باستكشاف الأفكار وتجربة المفاهيم. قم بحل المشاكل بحرية على الورق دون الاضطرار لأن تفكر بكيفية حل هذه المشكلة باستخدام التطبيقات أو النصوص البرمجية. يضمن لك رسم السكتشات بأن تنشئ عددًا كبيرًا من الأفكار في وقت قصير. لا تبدِ اهتماما كبيرًا لعدم دقة أو ترتيب سكتشاتـك. عليك ببساطة أن تحدد أفكارك المبدئية وأن تحدد المفاهيم. يمكنك لاحقًا أن تأخذ أفضل العناصر وترتب أفكارك. إحدى التقنيات المفضلة لدي هي أن أنسخ بعض سكتشاتـي على آلة تصوير الأوراق، وأن أقطعها إلى أجزاء أساسية -بما يتسق مع شرح Brad Frost في Atomic Design-، ومن ثم أبدأ بإثراء مفهوم التصميم وذلك بتجميع وإعادة ترتيب العناصر. شخصيًّا، أجد أن تَحْريك قصاصات الورق يسمح لي بتحديد النمط والتفكير بكيفية تفاعل المستخدم مع حلول التصميم وتفسيره لرسائلي. لقد بدأت حديثًا باستخدام حاسوب محمول متصل بـCreative Cloude لتوريد الـسكتشات بسرعة إلى التطبيقات لتحسينها أكثر ولعمل تصاميم أولية سريعة. تعتمد إعادتك وتقييمك لحلول التصميم الخاصة بك على التدريب. ارسم سكتشات يوميًا وبتكرار ونفّذ تصاميم أولية. اتبع نمط ABC والذي يعني (Always Be Creating). هرم التصميميساعدك رسم سكتشات وتكرارها مراراً على التقدم في هرم التصميم. يسمح لك هذا أن تسير بأفكارك وتصميمك من حلول غير تفصيلية إلى تفصيلية، وأن تفصل التصميم بما يتناسب مع رسالة التواصل أو المنتج الرقمي. يعتمد هرم التصميم على مفهوم التصميم المتكامل Total Design لـ Stuart Pugh الذي يقسم الأنشطة إلى ست مراحل. أما بالنسبة للتصاميم الرقمية، فقد بسطتها إلى: رسم سكتشات، عمل أطر مفرغة، تمثيل، عمل تصاميم أولية. تذكر أن السكتش لا يساوي الإطار المفرغ. تخط النصوص الحافظة للمكان. استخدم محتوى حقيقيايجب أن يبدأ تصميم أيّ حل رقمي بمحتوى نابع من الحقيقة. النصوص الحافظة للمكان مجرد تقدير لأي تصميم ممكن. يجب أن يشمل تصميمك سياقًا للمحتوى المقدم للمستخدمين (وللزبائن). يمكن أن يُفضي استخدام المحتوى الحافظ للمكان إلى اتخاذ قرارات تصميم خاطئة يمكن أن تؤثر على التصميم وعلى التطوير في المستقبل. لقد رأيت ما لا يعد من النماذج والتصاميم الأولية التي فيها عبارة "Bob Smith, job title here". استخدم محتوى حقيقيًّا لتعرف كيف سيبدو تصميمك متى تمّ إكماله. ستساعدك النسخة الحقيقية من المحتوى على تحديد طول مستطيلات الإدخال في نماذج الوِب، وطول الأقسام وأشرطة التمرير الجانبية. ستعطيك النصوص الحافظة للمكان (lorem ipsum) شعورًا مزيفًا بالأمن وستؤدي إلى افتراضات غير واقعية عن عمل التصميم الخاص بك. ستصمم لتصل إلى مقدار مثالي من النسخ أو المحتوى، والتي لا تحدث أيّ منها في العالم الحقيقيّ. قم باتخاذ قرارات التصميم التي تدعم المحتوى. التصميم يحدد كيفية العملإن البساطة هي الهدف عند تصميم الواجهات وتجربة المستخدم. إن مراجعة حالات الاستخدام وقصص العمل يمكن أن تساعد على تشكيل الواجهة والتخلص من النقاط غير السلسة في طريقة التفاعل بين المستخدم والتصميم. ولكننا ما زلنا لا نعرف بالضبط من سيكون المستخدم النهائيّ أو كيف سيتفاعل مع الواجهة. من المهم لنا كمختصين في تصميم الواجهات وتجربة المستخدم أن ننشئ واجهات ترضي احتياجات كلّ من المستخدمين المبتدئين والخبراء؛ واجهات يسهل تعلمها دون أن تكون متعالية على المستخدم. يتطلب منا الانتقال من النقطة أ إلى النقطة ب أن نصل جسرًا في الهوة بين المستخدم المبتدئ والمتقدم، وذلك باستخدام تلميحات بصرية وتغذية راجعة للمستخدمين المبتدئين، وإتاحة مزايا متقدمة يمكن أن يتعلمها ويستكشفها المستخدمون المتقدمون. اختبر الافتراضات في المتصفحاختبر مبكرًا. اختبر بكثرة. قدم سياقًا للاستخدام. ابن تصميمًا أوليًّا يمكن أن يستخدَم في المتصفحات أو الأجهزة المحمولة وذلك لاختبار افتراضات التصميم التي لديك عبر التصاميم الأولية وذلك للتحقق من أفكارك وحلولك. صمم -باستخدام التصاميم الأولية- تجربة استخدام لا تحتاج لتعلم مسبق، وإنشاء أدوات وواجهات لا يلاحظ المستخدمون أنهم يستخدمونه، الأدوات والتفاعلات التي تتحول إلى جزء من المستخدم. جهّز البيئة للتفاعل مع المستخدم، وللإبقاء على تفاعل مستمر بسيط وسريع وطبيعي. وبالتأكيد، عليك أن تصمم لشاشات اللمس. قائمة التحقق من أدوات تصميم تجربة المستخدم:قلم رصاص وممحاة.أقلام حبر شبه سائلة (جِل)، وهي المفضلة لدي.مسطرة.دفتر رسم سكتشات (إما بورق غير مسطور أو ورق مربعات).أقلام بتدرجات رمادية.شبلونة رسم مفرغة.قصاصات ورقية ملونة.أقلام (ماركَر).هل هناك شيء آخَر ترغب بإضافته إلى هذه القائمة؟ أخبرنا في التعليقات. رحلة تصميم موفقة! ترجمة -وبتصرف- للمقال: Sketch, Iterate, Repeat: Prototyping Your Website Design لصاحبه: Andrew Smyk. حقوق الصورة البارزة: Designed by Freepik.
  13. إن آخر ما تريد سماعه من المستخدم لديك عند دخوله إلى موقعك لأول مرة هو "لحظة، ما الذي علي أن أفعله هنا بالضبط؟!" يمكن أن يكون تصميم عناصر الانتقالات أمرًا شائكًا، وخاصة إذا تركته للأخير بجعلها العنصر الأخير الذي ستقوم بتحسينه عند الاقتراب من الانتهاء من المشروع بأكمله. إنّ توجّهًا كهذا لا يمكن أن ينتهي نهاية حيدة، وهو بالتأكيد ليس الطريق السليم لتصميم عناصر التنقلات. إن التحدي هنا هو أنّ تصميم عناصر التنقلات لا يتعلق فقط بالقوائم التي ستستخدمها وأين ستضع تلك القوائم. يجب أن يبدأ هذا التوجه قبل ذلك بكثير. في الواقع، يفترض أن تعمل عليها منذ اليوم الأول في الوقت الذي تخطط فيه لتصميمك التالي. ولهذا، فما ستقرأه هنا هو دليل موجز: أساسيّات تصميم عناصر التنقلات. أول ما سنركز عليه هنا هو فصل الأشياء الضرورية للتنقل السليم عن غير الهامّة. ونبدأ بما يلي: إن الانطباع الأول هو ما يحدد النجاح أو الخسارةلدى كل منا موقع في العلامات (bookmarks) نستمتع بزيارته رغم سوء تصميم عناصر التنقلات فيه، أليس كذلك؟ لقد تعلمنا بطريقة ما أن نتنقل فيه وأن نحصل على محتواه، رغم صعوبة التنقلات. ما أحاول قوله هنا هو أن الزائر العادي لديك سيتعلم كيف يتعامل مع موقعك مع الوقت، بغض النظر عن مدى سوء تصميم عناصر التنقلات. أما عن زوارك الجدد، فهم فئة أخرى مختلفة تمامًا، ومن شبه المؤكد أنهم لن يتمتعوا بهذا القدر من التفاني والدافعية لتخطي هذه العقبات. ولهذا، فعند العمل على تصميم عناصر التنقلات لديك، عليك أن تركّز على التجربة الأولى للمستخدم قبل أيّ شيء آخَر. إن الانطباع الأول هو ما سيدعو المستخدم لأن يرجع، أو سيخيفه ويبعده بعيدًا عن الموقع. يبدأ التنقل الجيد بهيكلية جيدة للمحتوىفي الواقع الأمر سهل: المحتوى أولًا، ثم القوائم. يجب ان لا يكون تصميم عناصر التنقلات فكرة متأخرة، بل أن يكون نتيجة مباشرة لهيكلية المعلومات التي على الموقع. وبعبارة أخرى فإن الطريقة التي تصمم بها هيكلية المحتوى للموقع ستؤثر على الطريقة التي ستصمم بها عناصر التنقلات، وليس العكس. إن أحد الاحتمالات طريقة فرز البطاقات وهي طريقة لبدء تصميم هيكلية المعلومات وفرزها حسب الأولوية. إن طريقة فرز البطاقات طريقة يتم عملها دون استخدام الحاسوب، ويستخدم فيها المشاركون بطاقات حقيقيّة (قطع من الورق) لترتيب الموضوعات في مجموعات. دائما فكر بأهدافك أنتتُعلمُنا إحدى مدارس تصميم عناصر التنقلات أن نركز دائمًا على ما يريد المستخدم عمله أولًا: اهتم بأهداف المستخدمين أولًا. قد تكون هذه استراتيجية حكيمة في بعض الحالات، ولكنها ليست دائمًا الأفضل من وجهة نظر تجارية. يتعلق الأمر بعلاقته بأهدافك (أو أهداف عميلك) التجارية للموقع. بدلًا من ذلك، رتب تنقلاتك اعتمادًا على المكان الذي ترغب أن يذهب مستخدموك إليه، وليس بالضرورة أن يكون هذا هو ما يريدون هم الذهاب إليه. ربما علي أن أعيد صياغة ذلك. لا يتعلق الأمر بعمل الأشياء بما يخالف نيّة المستخدِم، بل بربط أهداف المستخدم بأهدافك أنت. فمثلًا، قد يرغب مستخدموك بترشيح (فلترة) قائمة التنزيلات لديك ليروا العروض المجانية فقط، ولكن هل الخيار الأفضل من وجهة نظر تجارية أن تسمح لهم بعمل ذلك؟ بدلًا من ذلك، يمكنك أن تجد حلًّا وسطًا بعرض قائمة كاملًا للتنزيلات، مع إعطاء التنزيلات المجانية تركيزًا إضافيًّا (بحيث يتمكن المستخدم من تمييز الأشياء المجانية، ولكن ستُعرض عليهم عروض أخرى مدفوعة). خمن طريقة تفكير المستخدميتعلق هذا القسم من المقال بتخمين طريقة تفكير المستخدِم عند زيارته لموقعك. بشكل عام، هل يعرف الزوار ما يبحثون عنه؟ أم عليك أن تساعدهم في ذلك؟ دعني أعرض عليك مثالين هنا: المثال الأول: جوجل. كل من يذهب إلى موقع جوجل يعرف تمامًا ما يبحث عنه. كل ما يحتاجه الزائر هو حقل إدخال للبحث يمكنه أن يضع فيه الموضوع الذي يبحث عنه وحسب. المثال الثاني: المدونات العاديّة. الزائر العاديّ للمدونة قد لا يعرف ما يبحث عنه بالتحديد. يعرف الزائر أنه يرغب بتلقي محتوىً جيّد، لكن عندما يتعلق الأمر بمقال معين سيقدم إليه، فهنا يأتي دورك بأن تقدم إليه المقال المناسب. ستحتاج في هذه الحالة إلى هيكلية تنقلات أكثر تطورًا من مجرد شريط بحث. تحتاج إلى قوائم، وإلى تصنيفات، وربما تحتاج إلى أرشيف، وما إلى ذلك. ولهذا، فعليك أن تصمم عناصر التنقلات في موقعك بناءً على توقعاتك لطريقة تفكير الزائر. إذا كان هناك انفصال (أيّ، لم تكن هناك تنقلات وروابط مناسبة)، فلن تكون لدى الزائر أدنى فكرة عن ما عليه فعله في موقعك، أو لن يكون بإمكانه تلقي أيّ من المحتوى. يجب أن تكون التنقلات مألوفةمن أكثر الأخطاء التي يقع فيها المصممون شيوعًا عند بنائهم لموقع هو أن يكونوا مبدعين أكثر من اللازم في توجهاتهم المتعلقة بالتنقلات. رغم صعوبة مقاومة الإبداع -خاصة أنّ أغلب أجزاء بناء الموقع تتطلبه- إلّا أنه من الأفضل العمل بأساليب مجرّبة عندما يتعلق الأمر بتصميم التنقلات. وفوق كل شيء، يجب أن لا يكون التنقل مُربكًا. يجب أن يتمكن جميع المستخدمين من تمييز القوائم بمجرد رؤيتها، دون أن يضطروا للبحث عنها. وبمناسبة الحديث عن ذلك، فهذا ليس رأيي وحدي. لقد طلبت من Robert Hapiuc -وهو مصمم في CodeinWP blog- أن يشاركني رأيه فيما يراها الأخطاء الأكثر شيوعًا التي يقع فيها مصممو المواقع عندما يتعلق الأمر بتصميم التنقلات. وفيما يلي ما قال: باختصار، اجعل بنية التنقلات لديك سهلة الفهم، ولا تحاول أن تذهب بعيدًا بإبداعك. اجعل القوائم وعناصر الموقع التي تشكّل التنقلات واضحة قدر الإمكان. إضافة إلى ذلك، لا تبدع أكثر من اللازم في إبراز التنقلات في موقعك. فمثلًا، لا بأس بحركات لتصاميم المسطحة، لكن جعلها متقدّمة ومعقدة جدًّا سيبعد المستخدمين وسيقلل من قابلية الاستخدام. والأهم من هذا كلّه: لا تتجاهل الأعراف المتبعة في الشبكة العنكبوتيةالعديد من أعراف الشبكة العنكبوتية قد رافقتنا لسنوات لسبب. ومن هذه الأشياء سلّة أو عربة التسوق في الزاوية اليمنى العليا للصفحة، أو روابط الولوج/الملف الشخصي في نفس المكان. لقد اعتاد المستخدمون على أن يروها في ذلك المكان، ومحاولة الخروج بمفهوم مختلف لن ينتج عنه إلا إرباك المستخدم. لذا، فالقاعدة الرئيسيّة هي الالتزام بالأعراف الموجودة، وجعلها توافق تصميمك، ولا تعد اختراع العجلة دون داعٍ. أظهر المحتوى الرئيسي بما يكفيبناء تنقلاتك حول المحتوى الرئيسيّ للموقع بداية جيدة. إن تجربة فرز البطاقات المذكورة أعلاه ستعطيك لمحة عامة عن تصنيفات المحتوى الرئيسيّ ومدى أهمية الدور الذي تلعبه في الموقع بأكمله. ستحتاج أيضًا لأن تنظر في أجزاء المحتوى الرئيسيّة المتعلقة بما يقدمه الموقع. فمثلًا، ليس عيبًا أن تضع رابطًا لجزئيّة معينة من المحتوى في القائمة العليا للموقع إذا كان هذا المحتوى هامًّا بما يكفي. لا تقع في فخّ بناء تنقلاتك حول القطاعات أو التصنيفات الرئيسيّة للمحتوى. قد يكون توجه كهذا قد يكون جيدًا لموقع دليل (مثل Alltop)، ولكنه لن يكون فعالًا على المدى البعيد لمواقع من نوع آخر. وهذا لأن تصميم عناصر التنقلات بناء على التصنيفات وحدها يتطلب أن يكون الزائر على اطلاع على ما يُتوقَّع أن يجد في كل تصنيف. (هناك مشكلة مشابهة في القوائم المنسدلة، والتي سنأتي على ذكرها لاحقًا في هذا المقال). أي نوع من عناصر التنقلات أستخدم؟هل نوع عناصر التنقلات التي تستخدمها مهم؟ هل هناك ميزة هامّة لاستخدام شريط التنقل العلوي (top nav. menus) بدلًا من القوائم المنسدلة الكبيرة (mega menus)؟ هل القوائم المنسدلة هي الطريقة السليمة؟ كالعادة -وكم أكره أن أقولها- هذا يعتمد على عدة أمور. الأنواع المختلفة لعناصر التنقلات مناسبة لحالات مختلفة، ولكن عليك أن تعرف خصائصها لتتمكن من اختيار النموذج المناسب لك بدقة. أشرطة التنقل العلوية (top nav bars)هي أداة التنقل الأكثر شيوعًا وربما الأكثر عمليّة. وأما عن عيبها الوحيد، فهو أنها تتسع فقط لقدر محدّد من العناصر. ولكن لا يشترط أن يكون هذا عيبًا. يتطلب استخدامك لشريط الانتقال العلويّ أن تراجع أولوياتك، بحيث تختار فقط أهم العناصر لتعرضها في الشريط العلويّ. كما وتجعل هذه الأشرطة اختيارات المستخدم أسهل. وفي النهاية، يذكرني هذا الكلام بالمثل العربيّ القائل "خير الكلام ما قلّ ودلّ"، والمثل الأجنبي القائل "less is more”. ويشير Dragos Bubu -وهو مصمم في ThemeIsle- أيضًا إلى قضية وجود أشياء أكثر من اللازم ضمن عناصر التنقلات الأساسيّة في حديثه عن الأخطاء الأساسيّة التي يقع فيها مصممو المواقع عند العمل على عناصر التنقلات في المواقع، إذ يقول: القوائم الجانبيةمن خيارات التنقلات الأقرب للموضة هذه الأيام وضع قائمة على الجانب. وبشكل عام، قد يكون هذا حلًّا جيدًا لبعض المواقع، ولكن هذا بشكل رئيسيّ للمواقع التي فيها تصنيفات كثيرة للمحتوى بحيث تتحول هذه التصنيفات نفسها إلى محتوى. وينطبق هذا أيضًا على المواقع التي فيها مرشّحات (فلاتر) يمكن للمستخدم ضبطها باستمرار أثناء تصفّح الجزء الخاص بالمحتوى الرئيسيّ. إن موقعًا صغيرًا يُدعى eBay مثال جيد على هذا. الجانب السلبي لهذه القوائم هو أنها يمكن أن تجذب قدرًا كبيرًا من اهتمام الزائر وتحدّ من ظهور وجاذبيّة الجزء الخاصّ بالمحتوى الرئيسيّ. وفي النهاية، لدينا نوع القوائم الأكثر إثارة للجدل، وهو القوائم المنسدلة (drop-down)مبدئيًّا، لا يوجد ما يعيب القوائم المنسدلة كأداة انتقال. المشكلة هي أن العديد من مصممي المواقع يلجؤون إليها عندما تنفد المساحة في شريط التنقل الرئيسيّ. هذا ليس الحلّ الأنسب. هذا يقلل قابليّة الاستخدام للموقع بأكمله لأن المستخدم لا يستطيع تخمين ما سيجد في هذه القوائم، ولهذا فلن يكون لديه دافع لينقر عليها. وكقاعدة رئيسيّة، القوائم المنسدلة بشكل عام جيدة فقط للقوائم التي يستطيع المستخدم أن يتنبأ بما في داخلها 100% دون أخطاء. فمثلًا، إذا كنت تريد من المستخدم أن يختار المحافظة أو المدينة أو الدولة التي يسكن فيها، فالقوائم المنسدلة خيار مثاليّ. ولكن عندما ترغب بعرض مجموعة قياسية من عناصر القائمة، فلن تكون خيارًا جيدًا. إضافة إلى هذا، ضمِّن تلميحات بصريّة إضافية عند استخدامك قوائم منسدلة، فمثلًا استخدم رمز المثلث الذي يوحي للمستخدم بوجود المزيد عند تمريره مؤشر الفأرة فوق القائمة. اسع إلى النجاح على المدى البعيدكما بالنسبة لمعظم نواحي تصميم المواقع، فمن المرجح أنك لن تصمم هيكلية التنقل الصحيحة في تجربتك الأولى مقارنة بما ستحققه عند رجوعك إلى التصميم والعمل على تحسينه. باختصار، تحقق من الأنماط، وتتبّع سلوك المستخدمين في موقعك والطريق الذي يتبعونه. ستتمكن مع الوقت من تحسين كفاءة التنقلات بجعل العناصر الأكثر استخدامًا مرئيّة أكثر، وبنقل الأقل استخدامًا إلى مكان أقل بروزًا. ما التالي؟تصميم عناصر التنقلات موضوع واسع إذا كنت ترغب باحترافه. وما تزال هناك الكثير من الأشياء التي لم نناقشها في هذا الدليل، ومنها: طريقة التعامل مع تنظيم المعلومات في صفحات المحتوى كلًّا على حدة (أين تضع الصور والنصوص والروابط)، واستخدام آليّات متقدمة للتنقلات، كالصفحات المنفصلة، وخرائط المواقع، والوسوم، والتنقلات الثابتة، وما إلى ذلك. أرى أن ندع الباقي إلى يوم آخَر، ونتوقف هنا لنسمح لعقلنا أن يتشرّب هذه المعلومات. ما رأيك؟ وما هي استراتيجيتك في تصميم عناصر تنقلات فعالة تقوم بمهمتها على أكمل وجه؟ ترجمة -وبتصرف- للمقال: Navigation Design 101 لصاحبته Karol K.
  14. تُستخدَم قواعد البيانات العلاقيّة منذ وقت طويل. لقد اكتسبت قواعد البيانات من هذا النوع شُهرة بفضل أنظمة إدارتها التي تستخدم النموذج العلاقيّ بشكل جيّد للغاية، وهو النموذج الذي أثبت نفسه كطريقة رائعة للتعامل مع البيانات وخاصة في التطبيقات ذات المهام الحرجة. سنحاول في هذا المقال شرح الفروقات الرئيسيّة في بعض أكثر أنظمة إدارة قواعد البيانات العلاقيّة (RDBMS) شُهرة واستخدامًا. سنستكشف الفروقات الرئيسيّة بينها من حيث المزايا والأداء الوظيفيّ، وكيفية عملها، ومتى تتفوق إحداها على الأخرى، وذلك من أجل مساعدة المطورين على اختيار نظام إدارة قواعد بيانات علاقية (RDBMS). أنظمة إدارة قواعد البياناتقواعد البيانات هي مساحات تخزين مرتبة منطقيًّا لكل الأنواع المختلفة من المعلومات (البيانات). لكل نوع من قواعد البيانات –باستثناء عديمة المخطط– نموذج يقدم هيكلة للبيانات التي يتم التعامل معها. أنظمة إدارة قواعد البيانات هي تطبيقات (أو مكتبات) تدير قواعد البيانات بأشكالها وأحجامها وأنواعها المختلفة. أنظمة إدارة قواعد البيانات العلاقيةتستخدم أنظمة قواعد البيانات العلاقيّة النموذج العلاقيّ للعمل على البيانات. يشكّل النموذج العلاقيّ المعلومات التي ستُخَزَّن مهما كان نوعها، وذلك بتعريفها ككيانات مترابطة ذات خصائص تتعدى الجداول (أي مخططات). تتطلب أنظمة إدارة قواعد البيانات من هذا النوع أن تكون البُنى (كالجداول مثلًا) معرّفة لتحوي بيانات وتتعامل معها. لكلّ عمود (مثل الخصائص) في الجداول نوعٌ مختلف من المعلومات (نوع البيانات). يُترجَم كلّ سجلّ في قاعدة البيانات –مُعرّف بمفتاح فريد– إلى صفّ ينتمي إلى جدول، وتكون مجموعة خصائص كل سجل معروضة كأعمدة للجدول. وتكون كلها مرتبطة ببعضها كما هو محدد في النموذج العلاقيّ. العلاقات وأنواع البياناتيمكن اعتبار العلاقات مجموعات حسابية تحوي مجموعة من الخصائص التي تشكّل معًا قاعدة البيانات والمعلومات المحفوظة فيها. تسمح هذه الطريقة في التعريف والتجميع لقواعد البيانات العلاقيّة بالعمل بالطريقة التي تعمل بها. عند تعريف جدول لإدخال سجلات، يجب أن يطابق كلّ عنصر يشكل سجلًّا (كالصفة attribute مثلًا) نوع البيانات المحدّد له (كأن يكون عددًا صحيحًا أو تاريخًا مثلًا). تستخدم أنظمة إدارة قواعد البيانات العلاقيّة أنواعًا مختلفة من البيانات ولا يمكن في العادة تبديل واحدة من هذه الأنواع مكان الأخرى. التعامل مع وعبر قيود –كالتي ذكرناها قبل قليل– شائع مع قواعد البيانات العلاقيّة. في الحقيقة، تشكّل القيودُ مركزَ العلاقات. ملاحظة: إذا كنت تحتاج للتعامل مع معلومات غير مترابطة إطلاقًا وممثلة عشوائيًّا (كالمستندات مثلًا)، فقد تكون مهتمًّا باستخدام NoSQL (قواعد البيانات عديمة المخططات schema-less). قواعد بيانات علاقية شائعة وهامةسنتعرف في هذا المقال على ثلاثة أنواع رئيسيّة وهامّة من أنظمة إدارة قواعد البيانات العلاقيّة مفتوحة المصدر التي ساهمت في تكوين عالم تطوير البرمجيات: SQLite: نظام إدارة قواعد بيانات علاقيّة مضمّن وقويّ جدًّا.MySQL: نظام إدارة قواعد البيانات العلاقيّة الأشهر والأكثر استخدامًا.PostgreSQL: نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر المتوافق مع SQL الأكثر تقدّمًا.ملاحظة: تقريبًا دائمًا تتيح التطبيقات مفتوحة المصدر حريّة استخدام الطريقة التي تريدها. وفي غالب الأحيان تسمح لك أيضًا إنشاء تفرّع (fork) عن المشروع (وبالتالي استخدام نصوصه البرمجيّة) لإنشاء شيء جديد. إذا كنت مهتمًّا بأنظمة إدارة قواعد البيانات، فقد ترغب بالاطلاع على بعض المشاريع المتفرّعة المبنية على هذه المشاريع الشهيرة، مثل MariaDB. SQLite إنّ SQLite مكتبة رائعة تُضمَّن في التطبيقات التي تستخدمها. وكونها قاعدة بيانات قائمة بذاتها ومعتمدة على الملفات. تقدّم SQLite مجموعة رائعة من الأدوات للتعامل مع كل أنواع البيانات بقيود أقلّ بكثير وسهولة مقارنة بقواعد البيانات المستضافة المعتمدة على العمليات (خواديم قواعد البيانات). عندما يستخدم برنامج ما SQLite، يعمل هذا التكامل بنداءات (calls) مباشرة ومؤدية للغرض موجهة لملف يحوي البيانات (كقاعدة بيانات SQLite) بدلًا من التواصل عبر واجهة من نوع ما (كالمنافذ ports والمقابس sockets). هذا يجعل SQLite كفؤة وسريعة للغاية، وقويّة كذلك، وهذا بفضل التقنية التي بنيت عليها هذه المكتبة. أنواع البيانات التي تدعمها SQLite:NULL: قيمة فارغة NULL.INTEGER: عدد صحيح ذو إشارة (موجب أو سالب) محفوظ في بايت واحد، 2، 3، 4، 6، أو 8 بايت، وهذا يعتمد على حجم القيمة.REAL: قيمة النقطة العائمة (floating point)، مخزنة كرقم نقطة IEEE عائمة ذي 8-بايت.TEXT: سلسلة نصيّة مخزنة باستخدام ترميز قاعدة البيانات (UTF-8, UTF-16BE or UTF-16LE).BLOB: فقاعة من البيانات، تخزّن كما أدخِلَت تمامًا.ملاحظة: لمعرفة المزيد عن أنواع بيانات SQLite والعلاقات بين أنواع SQLite، ألقِ نظرة على التوثيق الرسميّ حول الموضوع. مزايا SQLite:معتمدة على الملفات: تتكون قاعدة البيانات بأكملها من ملف واحد على القرص، مما يجعلها محمولة تمامًا.مدركة للمعايير: رغم أنها قد تبدو كتطبيق قواعد بيانات "بسيط"، إلّا أن SQLite تستخدم SQL. ورغم أنّها أزالت بعض المزايا ( RIGHT OUTER JOIN أو FOR EACH STATEMENT) إلّا أنها تحوي بداخلها مزايا أخرى إضافيّة.ممتازة للتطوير، بل وحتى للاختبار: أثناء مرحلة تطوير التطبيقات، في الغالب يحتاج أغلب الناس لحلّ يمكن تطويعه للطلبات المتعدّدة. لدى SQLite قاعدة مزايا غنيّة، ويمكنها تقديم أكثر مما تحتاجه للتطوير، وبسهولة العمل مع ملف وحيد ومكتبة مرتبطة مبنية على C.عيوب SQLite:لا توفّر إدارة للمستخدمين: تأتي قواعد البيانات المتقدّمة بإدارة للمستخدمين –فمثلًا، فيها اتصالات مُدارة بصلاحيات الوصول إلى قواعد البيانات والجداول–. وبأخذ هدف وطبيعة SQLite بعين الاعتبار (عدم وجود مستوىً عالٍ من تعدّد المستخدمين في ذات الوقت)، لا وجود لهذه الميزة.عدم توفر إمكانية التلاعب بها للحصول على أداء أفضل: ونظرًا لطبيعة تصميمها أيضًا، لا يمكن التلاعب بـ SQLite للحصول على قدر كبير من الأداء. المكتبة سهلة الضبط والاستخدام. وبما أنها ليست معقّدة، فلا يمكن تقنيًّا جعلها أكثر أداءًا مما هي عليه، وبشكل يفوق أداءها الحاليّ الرائع.متى تستخدم SQLite:التطبيقات المضمّنة: كلّ التطبيقات التي تحتاج لقابليّة النقل، والتي لا تحتاج لتحجيم، كتطبيقات المستخدم المحلي والوحيد، وتطبيقات الهاتف النقّال أو الألعاب.كبديل عن الوصول إلى القرص: في العديد من الحالات، يمكن أن تستفيد التطبيقات التي تحتاج للقراءة من والكتابة إلى الملفات على القرص مباشرة من الانتقال إلى SQLite من أجل المزيد من الوظائف والسهولة اللتان تأتيان من استخدام لغة الاستعلام البنيويّة (Structured Query Language – SQL).الاختبار: من التبذير أن تستخدم نسبة كبيرة من التطبيقات عمليّة إضافيّة لاختبار منطقيّة العمل (أي الهدف الرئيسيّ للتطبيق: الوظيفيّة).متى لا تستخدم SQLite:في التطبيقات متعدّدة المستخدمين: إذا كنت تعمل على تطبيق يحتاج فيه العديد من المستخدمين الوصول إلى نفس قاعدة البيانات واستخدامها، فالغالب أنّ مدير قواعد بيانات علاقيّ كامل المزايا (مثل MySQL) خيار أفضل من SQLite.في التطبيقات التي تحتاج لقدر كبير من الكتابة: من محدوديّات SQLite عمليات الكتابة. يسمح نظام إدارة قواعد البيانات هذا عملية كتابة واحدة وحيدة أن تتم في وقت محدّد، مما يسمح بقدر محدود من الدفق.MySQL تعد MySQL أشهر خوادم قواعد البيانات الكبيرة. وهو منتج مفتوح المصدر غنيّ بالمزايا، ويشغّل الكثير من المواقع والتطبيقات على الإنترنت. من السهل البدء باستخدام MySQL، ولدى المطورين وصول إلى كمّ هائل من المعلومات المتعلقة بقواعد البيانات على الإنترنت. ملاحظة: يجب أن نذكر أنّه نتيجة لشيوع المُنتَج، فإنّ هناك الكثير من تطبيقات الشركات الأخرى وأدواتها ومكتباتها المضمّنة التي تساعد كثيرًا في الهديد من نواحي العمل مع نظام إدارة قواعد البيانات العلاقيّة هذا. ورغم عدم محاولتها تطبيق معيار SQL كامل، إلّا أنّ MySQL تقدّم الكثير من الوظائف للمستخدمين. وكخادم SQL قائم بذاته، تتصل التطبيقات بعملية مراقب MySQL (وهو تطبيق يعمل في الخلفية بعيدًا عن مرأى المستخدم، ويشار إليه أحيانًا بعبارة جنيّ أو عفريت) للوصول إلى قواعد البيانات ذاتها على خلاف SQLite. أنواع البيانات التي تدعمها MySQL:TINYINT: عدد صحيح متناهي الصغر.SMALLINT: عدد صحيح صغير.MEDIUMINT: عدد صحيح متوسّط الحجم.INT or INTEGER: عدد صحيح بحجم عاديّ.BIGINT: عدد صحيح كبير.FLOAT: عدد بفاصلة عائمة صغير أحاديّ الدقّة (single-precision floating-point). لا يمكن إلغاؤه.DOUBLE, DOUBLE PRECISION, REAL: عدد بفاصلة عائمة متوسط الحجم مزدوج الدقّة (normal-size/double-precision floating-point). لا يمكن إلغاؤه.DECIMAL, NUMERIC: عدد بفاصلة عائمة غير مُحتوىً. لا يمكن إلغاؤه.DATE: تاريخ.DATETIME: تجميعة من الوقت والتاريخTIMESTAMP: ختم زمني (وقت وتاريخ حدوث حدث ما).TIME: وقت.YEAR: سنة بهيئة منزلتين أو أربعة منازل (المبدئيّ 4 منازل).CHAR: سلسلة نصّيّة ذات طول محدّد يتم دائمًا إكمالها من ناحية اليمين بفراغات إلى الطول المحدّد عند تخزينها.VARCHAR: سلسلة نصيّة ذات طول متغيّر.TINYBLOB, TINYTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 255 (أي 2^8 – 1) محرفًا.BLOB, TEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 65535 (أي 2^16 – 1) محرفًا.MEDIUMBLOB, MEDIUMTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 16777215 (أي 2^24 - 1) محرفًا.LONGBLOB, LONGTEXT: عمود نصّ أو فقاعة (blob) بحدّ أقصى للطول قدره 4294967295 (أي 2^32 - 1) محرفًا.ENUM: تِعداد.SET: مجموعة.مزايا MySQLسهلة الاستخدام: يمكن تثبيت MySQL بسهولة شديدة. أدوات الأطراف الخارجية (third-party)، بما فيها المرئيّة (أي الواجهات الرسوميّة) تجعل البدء مع قواعد البيانات سهلًا للغاية. غنيّة بالمزايا: تدعم MySQL الكثير من وظائف SQL المتوقّع وجودها في أنظمة إدارة قواعد البيانات العلاقيّة، سواء بطريقة مباشرة أو غير مباشرة. آمنة: الكثير من مزايا الأمن وبعضها متقدّم مبنيّة في MySQL. قويّة وقابلة للتحجيم: يمكن لـMySQL التعامل مع الكثير من البيانات، ويمكنها أيضًا استخدامها على نطاق واسع إذا احتاج الأمر. سريعة: التخليّ عن بعض المعايير سمح لـ MySQL بالعمل بكفاءة عالية وبطريقة سلسة، مما أكسبها سرعة عالية. عيوب MySQLالمحدوديّات المعروفة: من حيث التصميم، لا تنوي MySQL عمل كلّ شيء، وتأتي بمحدوديّات وظيفيّة قد تتطلبها بعض التطبيقات المتقدّمة جدًّا من الناحية الفنيّة. القضايا المتعلّقة بالمتانة: الطريقة التي يتم التعامل فيها مع بعض الوظائف في MySQL (كالمراجع، والتبادلات، والتدقيق، وغيرها) تجعلها أقل متانة بقليل من بعض أنظمة إدارة قواعد البيانات العلاقيّة الأخرى. بطء تطويرها: رغم أنّ MySQL ما زالت من الناحية الفنيّة منتجًا مفتوح المصدر، إلّا أنّ هناك انتقادات تتعلق بعمليّة تطويرها منذ الاستحواذ عليها. ولكن علينا التنويه إلى أنّ هناك قواعد بيانات مبنيّة على MySQL ومتكاملة معها تمامًا تضيف مزايا على تثبيت MySQL القياسيّ (مثل MariaDB). متى تستخدم MySQLالعمليّات الموزّعة: عندما تحتاج لأكثر مما تتيحه SQLite، فإنّ تضمين MySQL في قائمة التطوير لديك – كذلك بالأمر بالنسبة لتضمين أيّ خادم قواعد بيانات مستقل – يقدّم لك الكثير من الحريّة في العمل إلى جانب بعض المزايا المتقدّمة. الأمان العالي: مزايا MySQL الأمنيّة تقدّم حماية يُعتمد عليها للوصول إلى البيانات (واستخدامها) بطريقة بسيطة. المواقع وتطبيقات الوِب: يمكن للأغلبية العُظمى من المواقع (وتطبيقات الوِب) العمل ببساطة مع MySQL رغم القيود. هذه الأداة المرنة والتي يمكن تحجيمها إلى حدّ ما سهلةُ الاستخدام والإدارة؛ وهذا مفيدٌ جدًّا على المدى البعيد. الحلول الخاصّة: إذا كنت تعمل على حلول محدّدة جدًّا ومخصّصة للغاية، يمكن لـMySQL العمل ضمن احتياجاتك بسهولة، وذلك بفضل إعدادات الضبط الغنيّة فيها وأوضاع العمل. متى لا تستخدم MySQLالتوافقيّة مع SQL: بما أنّ MySQL لا تطبّق (ولا تسعى لتطبيق) معيار SQL بأكمله، فإنّ هذه الأداة ليست متوافقة بالكامل مع SQL. إذا كنت قد تحتاج التكامل مع أنظمة إدارة قواعد بيانات علاقيّة كهذه، فإنّ الانتقال من MySQL لن يكون سهلًا. التعدّدية Concurrency: رغم أنّ MySQL وبعض محرّكات الحفظ تعمل بأداء جيّد جدًّا في عمليات القراءة، إلا أنّ عمليات القراءة والكتابة متزامنتين قد تكون سيئة. نقص المزايا: مجدّدًا نقول، اعتمادًا على اختيار محرّك قواعد البيانات، يمكن أن لا تحوي MySQL على بعض المزايا، كالبحث في النصوص الكاملة. PostgreSQL إنّ PostgreSQL هي نظام إدارة قواعد البيانات العلاقيّة الكيانيّ مفتوح المصدر الأكثر تقدّمًا، والتي هدفها الرئيسيّ أن تكون موافقة للمعايير ويمكن الزيادة عليها. تسعى PostgreSQL (أو Postgres) إلى تبني معايير ANSI/ISO SQL مع مراجعاتها. تتميّز PostgreSQL عن أنظمة إدارة المحتوى الأخرى بدعمها للتوجه الكيانيّ (object-oriented) المتكامل والمطلوب بشدّة و/أو وظائف قواعد البيانات العلاقيّة، كدعمها الكامل للتبادلات (القيود transactions) التي يعتمد عليها، أي أن تكون مكونة من عناصر غير قابلة للتجزئة، وأن تكون متّسقة ومعزولة وذات قدرات تحمل عالية (Atomicity, Consistency, Isolation, Durability – ACID). وبسبب التقنية القوية التي تقف خلفها، لدى Postgres قدرات عالية جدًّا في التعامل مع العديد من المهام بكفاءة عالية. يتم الوصول إلى التعدّدية (concurrency) دون قفل قراءة، وذلك بفضل تطبيق تحكم التعدّديّة متعدد الإصدارات (Multiversion Concurrency Control – MVCC). يمكن برمجة الكثير في PostgreSQL، وبالتالي يمكن توسعتها، وذلك باستخدام إجراءات مخصّصة تُدعى "إجراءات التخزين" (store procesures). يُمكن إنشاء هذه الإجراءات لتسهيل تنفيذ عمليات قاعدة البيانات المكررة والمعقدة والتي تكثر الحاجة إليها. رغم أنّ نظام إدارة قواعد البيانات هذا لا يحظى بشعبيّة MySQL، إلّا أنّ هناك الكثير من أدوات الأطراف الأخرى ومكتباتهم مصمّمة لجعل العمل مع PostgreSQL سهلًا، رغم طبيعته القويّة. يمكن الحصول على PostgreSQL هذه الأيام كحزمة تطبيقات من خلال مدير الحزم المبدئيّ للعديد من أنظمة التشغيل بسهولة. أنواع البيانات التي تدعمها PostgreSQLbigint: عدد صحيح من 8-بايت ذو إشارة bigserial: عدد صحيح من 8-بايت يزداد تلقائيًّا [(bit [(n: سلسلة ثنائيّة ذات طول محدّد [(bit varying [(n: سلسلة ثنائيّة متغيرة الأطوال boolean: متغيّر منطقي (صواب/خطأ) box: صندوق مستطيل في سطح مستوٍ bytea: بيانات ثنائيّة ("مصفوفة بايت") [(character varying [(n: سلسلة محارف (character string) ذات طول متغير [(character [(n: سلسلة محارف ذات طول ثابت cidr: عنوان شبكة IPv4 أو IPv6 circle: دائرة في سطح مستوٍ date: تاريخ في تقويم (السنة، الشهر، اليوم) double precision: عدد فاصلة عائمة ذو دقّة مزدوجة (8 بايت) inet: عنوان مضيف IPv4 أو IPv6 integer: عدد صحيح من 4 بايت ذو إشارة [(interval [fields] [(p: مدة زمنية line: خط لا نهائيّ في مستوى lseg: جزء من خطّ مستقيم في مستوى macaddr: عنوان تحكم بالوصول إلى الوسيط (Media Access Control – MAC) money: مقدار من المال [(numeric [(p, s: دقّة رقميّة محدّدة أو يمكن اختيارها path: مسار هندسيّ على سطح point: نقطة هندسيّة على سطح polygon: شكل هندسيّ مغلق على سطح real: عدد فاصلة عائمة ذي دقّة أحاديّة (4 بايت) smallint: عدد صحيح من 2-بايت ذو إشارة serial: عدد صحيح من 4 بايت يزداد تلقائيًّا text: سلسلة محارف ذات طول متغيّر [time [(p)] [without time zone: وقت في اليوم (دون منطقة زمنية) time [(p)] with time zone: الوقت من اليوم (مع منطقة زمنية) [timestamp [(p)] [without time zone: تاريخ ووقت (دون منطقة زمنية) timestamp [(p)] with time zone: تاريخ ووقت يشمل المنطقة الزمنيّة tsquery: استعلام بحث نصّيّ tsvector: مستند بحث نصيّ txid_snapshot: لَقطَة (transaction) لهويّة التبادل على مستوى المستخدم uuid: معرّف فريد عالميًّا xml: بيانات XML مزايا PostgreSQLنظام إدارة قواعد بيانات مفتوح المصدر موافق لمعايير SQL: PostgreSQL مفتوح المصدر ومجانيّ، ولكنه نظام إدارة قواعد بيانات علاقيّة قويّ جدًّا. مجتمع قويّ: PostgreSQL مدعوم من مجتمع خبيرٍ ومخلص يمكن الوصول إليه عبر مواقع الأسئلة والإجابات والقاعدة المعرفيّة طوال الوقت ومجانًا. دعم قويّ من الأطراف الأخرى: بغض النظر عن المزايا المتقدّمة جدًّا، تُزيّن PostgreSQL العديدُ من الأدوات الجيّدة ومفتوحة المصدر من أطراف أخرى لتصميم وإدارة واستخدام نظام الإدارة هذا. إمكانية التوسعة: يمكن توسعة PostgreSQL برمجيًّا باستخدام إجراءات مخزّنة، كما يفترض أن يكون الوضع في نظام إدارة قواعد بيانات علاقيّة متقدّم. كيانيّ: ليس PostgreSQL مجرّد نظام إدارة قواعد بيانات علاقيّة، ولكنه كيانيّ (objective) أيضًا – ويدعم التضمين (nesting)، ومزايا أخرى. عيوب PostgreSQLالأداء: للعمليات البسيطة كثيفة القراءة، يمكن أن تكون PostgreSQL مبالغًا فيها، ويمكن أن تبدو أقلّ أداءً من منافساتها، مثل MySQL. الشعبيّة: نظرًا لطبيعة هذه الأداة، فإنها تقبع في الخلف فيما يتعلق بشعبيتها، رغم كثرة من استخدامها – مما قد يؤثر على سهولة الحصول على دعم. الاستضافة: نتيجة للعوامل المذكورة أعلاه، يصعب إيجاد مستضيفين أو مقدمي خدمة يعرضون خدمات PostgreSQL مُدارة. متى تستخدم PostgreSQLصحّة البيانات: عندما تكون صحّة البيانات وإمكانية التعويل عليها ضرورة حتميّة، ولا يكون هناك عذر إذا حدث خطب ما، فستكون PostgreSQL الخيار الأفضل. الإجراءات المخصّصة المعقّدة: إذا كنت تتطلّب من قاعدة بياناتك أداء إجراءات مخصّصة، فـPostgreSQL هي الخيار الأفضل، كونه يمكن توسعتها. التكامل: إذا كان يُحتمل في المستقبل أن تكون هناك حاجة لنقل نظام قاعدة البيانات بأكمله إلى حلّ مملوك (مثل أوراكل)، فستكون PostgreSQL الأكثر توافقًا والأسهل في التعامل معها عند الانتقال. التصاميم المعقّدة: مقارنة بتطبيقات أنظمة إدارة قواعد البيانات العلاقيّة المجانية ومفتوحة المصدر الأخرى، تقدّم PostgreSQL لتصاميم قواعد البيانات المعقّدة أكبر قدر من الوظائف والإمكانات دون التفريط بالأمور الأخرى. متى لا تستخدم PostgreSQLالسرعة: إذا كان كلّ ما تطلبه عمليات قراءة سريعة، فليست PostgreSQL الأداة التي عليك استخدامها. سهولة الإعداد: إذا لم تكن تحتاج لصحّة مطلقة للبيانات، أو للتوافق مع ACID أو التصاميم المعقّدة، فقد تكون PostgreSQL مبالغًا فيها للإعدادات البسيطة. التكرار: إذا لم تكن مستعدًّا لقضاء الوقت، وبذل الجهد والموارد، فالحصول على التكرار (أو تعدّد النُسَخ) في MySQL قد يكون أسهل لمن ليست لديهم خبرة في إدارة الأنظمة وقواعد البيانات. ترجمة -وبتصرّف- للمقال: SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems لصاحبه O.S. Tezer.
  15. لطالما اعتُبِر تصميم صفحة البداية فنا في ذاته، كما تعتبر الأنشطة الأخرى التي تؤدي إلى بناء تصميم موقع كامل. وبطريقة ما، يجب أن يكون بالإمكان جعل واجهة البداية عملًا قائمًا بذاته، عملًا يحقق أهدافه الخاصّة. رغم أن هذه الأهداف لها ارتباط مباشر للهدف العام للموقع ككل، إلّا أنه يفترض بها أن تكون مركّزة أكثر. أعلم أن هذا قد يبدو مُبهمًا نوعًا ما، ولذا -لأوضح الأمور- لنلقِ نظرة على ثماني خرافات تتعلق بتصميم صفحة البداية يفترض على الجميع أن يعرفها. الخرافة الأولى: يجب أن تبدو صفحة البداية جميلةبالتأكيد لا أحد يستمتع بالنظر إلى صفحة بداية قبيحة، ولكن مع هذا، فجمال صفحة البداية ليس نهاية الحكاية. وبعبارة أخرى، تركيزك على عمل صفحة تسرّ الناظرين لهو أمر غير كافٍ للوصول بك إلى إسعاد زبونك (على المدى البعيد على الأقل). هناك أمر واحد يهمّ أكثر بكثير من المنظر الجذاب لصفحة البداية، وهو قدرة هذه الصفحة على تحقيق هدفها الرئيسيّ. يجب أن يكون لكل صفحة هدفها الخاص بها، وهو الهدف الرئيسيّ الذي من أجله وُجِدَت هذه الصفحة، لذا من أهم مهامك الرئيسيّة عند العمل على تصميم أن تحدد هذا الغرض. يمكنك أن تجرب الإجابة على السؤال التالي لجعل عملك أسهل: ما الأمر الرئيسيّ الذي ترغب أن يقوم به زوارك عند رؤيتهم لصفحة البداية لديك؟ فمثلًا، هل الهدف هو التسجيل قائمة بريدية أو نظام اشتراكات معين؟ أو قد يكون الهدف هو الذهاب إلى المدونة والتفاعل مع المقالات هناك؟ قد يكون الهدف هو الاطلاع على المنتجات أو الخدمات التي يوفرها الموقع؟ مهما كان هذا الهدف، ضعه نصب عينيك عند العمل على تصميم صفحة البداية. إذا كانت النتيجة جميلة (تسرّ الناظرين)، فهذه ميزة تكميليّة. إن أحد أفضل الأمثلة على تصميم الواجهة الرئيسيّة بالتركيز على الأهداف على الإنترنت هو موقع Craigslist. الواجهة قبيحة، لكنها تفي بالغرض: الخرافة الثانية: يجب أن تكون صفحة البداية مناسبة للجميعوبعبارة أخرى، تقول الخرافة أنه بغض النظر عن من يأتي لزيارة صفحة البداية، فعليه أن يُعجَب بها وأن يسعد بما يجده. ولكن مساوئ هذا الأمر أكثر من نفعه. رغم أن الموقع قد يبدو غير عمليّ، مما يُبعِد بعض الزوار مباشرة، إلا أنه قد يكون ذا أثر إيجابيّ على الزوار الذين يقررون البقاء. لأنهم -في تلك المرحلة- يعلمون أن ما يمكن للموقع أن يقدمه لهم سيتم بطريقة مفصلة خصيصًا لهم. دعني أعطيك مثالًا من مجال عمل مختلف كليًّا، وهو المطاعم. من الأخطاء الشائعة لدى العديد من أصحاب المطاعم (وهو ما أقوله على الأقل نتيجة لمشاهدتي لفلم Kitchen Nightmares) هو أن يوفروا كمًا هائلًا من أنواع الوجبات وأن يظنوا أنهم بهذه الطريقة سيوفرون لكل شخص شيئًا يناسبه. ولكن -عمليًّا- كانت النتيجة عكسيّة، حيث لم تكن هناك إشارة واضحة للزبون العاديّ أن هذا المطعم مناسب له. فعلى سبيل المثال، إذا كنت تحب البيتزا، فستذهب إلى محلّ لبيع البيتزا في كلّ مرة، ولن تذهب إلى مطعم يقدم العشرات من الأطباق المختلفة والتي تكون البيتزا واحدًا من عناصر قائمتها. هل تُبعد محلات البيتزا بعض الزبائن لمجرد أنها تقول بوضوح ان وجبتها الرئيسيّة هي البيتزا؟ نعم، بالتأكيد. ولكن هل تخسر هذه المحلات شيئًا على المدى البعيد؟ كلّا. ولهذا، فاجعل صفحة البداية لموقعك كمحل بيع البيتزا. بيّن أن ما يقدمه موقعك هو البيتزا، وبين بوضوح أنه إذا لم يكن شخص ما يحب البيتزا، فيفترض به أن لا يأتي إلى هنا. الخرافة الثالثة: يجب أن تعرض صفحة البداية الكثير من المعلوماتيمكننا أن نقول ونحن واثقون أن عصر صفحات البداية ذات التفاصيل الكثيرة قد ولّت أيامه. لا تحتاج صفحات البداية أن تكون ضخمة لتحقق أهدافها. وكما كنا نقول: خير الكلام ما قلّ ودلّ. الأمر هنا نفسه تقريبًا. كما ناقشنا أعلاه، فإن الوظيفة الأساسيّة لصفحة البداية هي أن تعطي الزائر دفعة باتجاه تنفيذ أشياء معينة. وكما يبدو، فإن عرضك لكمية أكبر من اللازم من المعلومات سيؤدي إلى نتيجة عكس ما تتمنى. ولقد أكدت مجموعة Nielsen Normal Group هذا الأمر في دراساتها. تقول هذه المجموعة أنّ 79% من المستخدمين يتفحصون كلّ صفحة جديدة يرونها بسرعة، بينما 16% فقط يقرؤونها كلمة بكلمة. ولهذا، فخلاصة الكلام أن جعل صفحة ما موجزة يؤدي إلى زيادة في قابلية الاستخدام قدرها 124%. لنلق نظرة على صفحة البداية لـ Contently.com على سبيل المثال: هناك فقط ثلاثة سطور من المعلومات، يتبعها طلبان لاتخاذ إجراء، وهما: "اعرف المزيد" و "تحدّث معنا". بعد قراءة سطور النص الثلاثة هذه، سيعرف الزائر إن كان مهتمًا كفاية لأن يضغط أحد هذين الزرين، وهذا كل ما تحتاج عند عمل صفحة بداية. الخرافة الرابعة: تحتاج صفحة البداية لشريط تمريراستخدام أشرطة التمرير في التصميم توجه كسول جدًّا. في نهاية الأمر، من السهل وضع شريط تمرير تحت الترويسة مباشرة ووضع بعض الرسوميات الشبيهة بالـ "بانر" فيه. الأكثر شيوعًا هو أن تقوم بعمل 3 - 4 شرائح وأن تجعلها تتبدل تلقائيًّا. هذا أسلوب شائع جدًّا وتتبعه آلاف صفحات البداية. ولكن، كما تؤكد المعلومات، فإن هذه الشرائح غير مجدية عندما يتعلق الأمر ببدء حوار، أو جذب انتباه المستخدم، أو عمل أيّ شيء آخَر يمكن أن ينتُج عنه نتائج إيجابيّة. وعلى سبيل المثال، هذا ما قاله عنها Chris Goward من WiderFunnel في إحدى أوراقه البحثيّة: في نهاية المطاف، المعلومات التي لدينا هذه الأيام تقترح حلًّا جيدًا لهذا الأمر: لا تستخدم أبدأ شرائح عرض الصور في صفحة البداية أبداً. الخرافة الخامسة: يجب أن تتحدث صفحة البداية عنك أنتحيث أعني بكلمة "أنت" الشخص أو الشركة صاحبة هذا الموقع. فمثلًا، تعني كلمة "أنت" أن تتحدث عن المنتجات التي تقدمها الشركة. بداية، أن تتحدث الصفحة عنك ليست بالفكرة السيئة أبدًا. عليك أن تقوم بها إلى حدّ ما، وإلّا فلن تبني أيّ علاقة مع الزائر. ولكن ما يهم هنا هو الطريقة التي تستخدمها للتعبير عن الأمر. فمثلًا، استخدام تعبير مثل "نقدم خدماتنا من عام 2004. انقر هنا لمعرفة عرضنا." لا يحقق أيّ شيء فيما يتعلق بالتواصل مع الزائر. إن ما سيحقق نتيجة هو أن تبني صفحة البداية لديك حول مفهوم: ما الذي سأحققه للزائر؟ لنلق نظرة مثلًا على صفحة البداية لموقع Due.com: الصفحة لا تقول: "نحن نعمل في مجال تتبع الوقت منذ 'س' من السنوات". بل تقول: "يساعدك Due.com على تتبع وقتك باستمرار وإخراج فاتورة احترافية". يرتكز النصّ حول الزائر تمامًا تقريبًا. وباختصار، اجعل صفحة البداية تتعلق بـهم -أي الزوار- وليس بك أنت. الخرافة السادسة: يجب أن تعرض الصفحة الرئيسيّة أخبار الشركةلا تفعل هذا، رجاءً! لا يولي الناس -عمومًا- اهتمامًا بما يحدث داخل الشركة. لماذا؟ سأقولها مرة أخرى، لأن هذا الأمر لا يعنيهم هم. من ناحية المبدأ، أيّ نوع من أخبار الشركة لا يعد ذا علاقة بالزائر واحتياجاته، إلا إن كان الزائر مستثمرًا أو كان الموقع للاستخدام الداخلي في الشركة، ففي هذه الحالة لك الحرية الكاملة لأن تعرض أخبار الشركة على الصفحة الرئيسيّة. الخرافة السابعة: يجب أن تبدو صفحة البداية بنفس الشكل على كلّ الأجهزةإن فكرة تصميم المواقع لأكثر من جهاز لَهُوَ فصل جديد في تاريخ تصميم المواقع. قبل زمن ليس ببعيد، كان كل ما علينا أخذه بعين الاعتبار هو ما إذا كان سيبدو الموقع جيدًا على دقة 800×600 كما هو جيد على دقة عرض 1024×768. لكن الزمان تغيّر، ولدينا الآن عدد كبير من أحجام ودقة الشاشات لنتعامل معها. ولكن التفكير بأن موقعك يجب أن يبدو بنفس الشكل عليها كلها فهذا مسار خطير يفترض تجنبه. المشكلة الرئيسيّة في التفكير بهذه الطريقة هو أنّ من يزور موقعك من هاتف محمول لن يفكر بنفس الطريقة التي يفكر بها الشخص الذي يزور الموقع من الحاسوب الشخصيّ. على سبيل المثال، إذا زار شخص ما موقع مطعم من الحاسوب الشخصيّ، فغالب الظنّ أنه يرغب بالتعرف على المطعم وما يقدّمه والأطعمة التي يوفرها، إلخ. ولكن عند زيارته من الهاتف المحمول فإن أول ما يفكر فيه هو العنوان وساعات الدوام. يجب على تصميم صفحة الواجهة الجيد أن يقدم فائدة لمجموعات مختلفة من الزوار بناء على الجهاز الذي يستخدمونه. يمكن تحقيق هذا باستخدام تصميم مستجيب إلى حدّ ما. يمكنك باستخدام فئات CSS (أي classes) أن تبرز أجزاء معينة من صفحة HTML أو أن تخفيها بالكامل. باختصار، ليس من الضروري أن تبدو صفحة البداية بنفس الشكل في كلّ مكان، ولكنها تحتاج لأن تساعد الزائر على تلبية احتياجاته من الموقع. الخرافة الثامنة: بعد أن تنتهي من بنائها، ستبقى كما هييجب أن لا يكون تصميم صفحة البداية مهمة تنفذ لمرة واحدة. لسوء الحظ، لن تكون محاولتك الأولى لتصميم صفحة البداية لأي موقع (أيًّا كان) ذات نتيجة مثاليّة. هذا لأنك لن تتمكن من التنبؤ بطريقة أداء هذه الصفحة في العالم الحقيقيّ. يمكنك فقط أن تفترض كيف سيتعامل الزائر مع صفحة البداية، ولكنك لن تعلم بدقة. تأتي هذه المعرفة مع الوقت وبتجربة مفاهيم مختلفة. ولهذا، بدلًا من أن تفترض أن تصميمك سيكون رائعًا بمجرد أن تنتهي منه أول مرة، أنشئ على الأقل تصميمين مختلفين واختبرهما وقارن النتائج. ما مدى الاختلاف الذي يجب أن يكون بين التصميمين؟ القرار يعود إليك. يمكنك أن تبدأ بنسخة ذات تعديلات طفيفة، أو تغييرات كبيرة في الشكل العام. المهم أن يكون هناك اختلاف بين التصميمين، وعليك أن تضع مقياسًا تعتمد عليه في تقييم الإصدارين وتحديد أيهما أفضل (يتم هذا عادة بتتبع النقرات على روابط محددة أو بوجود زوار يملؤون نماذج معينة). بمجرد أن تكون لديك بيانات خام، يمكنك تفتيت النسخة الأقل أداءً من صفحة البداية وإنشاء صفحة جديدة تمامًا ومن ثم مقارنتها مع الصفحة التي نجحت في المقارنة السابقة. إن طريقة عمل صفحة بداية جيدة يكون بتنفيذ هذا الأمر على الأقل عدّة مرات. الخلاصةهناك أكثر مما يمكن حصره فيما يتعلق بأخطاء تصميم الصفحة الرئيسيّة، ونحن لم ندخل في القضايا التقنية حتى (كاستخدام صور لم يتم تضبيطها لتناسب الموقع، أو خطوط صغيرة جدًّا). أظننا سنترك هذه المواضيع للمرة القادمة. هل كنت ضحية إحدى الخرافات المذكورة أعلاه؟ شاركنا برأيك! ترجمة -وبتصرف- للمقال 8Homepage Design Myths Debunked لصاحبه: Karol K. حقوق الصورة البارزة: Designed by Freepik.