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

قد تتساءل لماذ يجب عليّ أن أستخدم ووردبريس؟ لكي تكون الأكثر فاعلية في عملك، من المهم جدًا أن يتعلم مصممو الويب والمطورون المحترفون الأدوات المناسبة ويستخدمونها. أردنا اليوم توضيح فكرة لماذا استخدام ووردبريس هو الخيار الأفضل لمعظم المستقلين (freelancers) -مرّة واحدة وللأبد-. سنغطي أيضًا كفية جعل سير عملك فائق الإنتاجية باستخدام إطار عمل قالب (theme framework). هناك الكثير من الأشياء المهمة التي تحتاج القيام بها عند إنشاء موقع ويب، إذ تحتاج إلى التأكد من أن الموقع يبدو رائعًا، وسريعًا، ومتجاوبًا (responsive)، ويظهر ظهورًا مرتبًا في جميع الأجهزة مختلفة الأحجام. يعدّ ووردبريس حقًا أفضل حلٍّ يمكنك استخدامه عند إنشاء معظم مواقع العملاء. بعض الاستثناءات ستكون تطبيقات ويب (web application) لأنك تحتاج حينها إلى بناء كل شيء من الصفر. مثلًا، في بناء موقع البحث عن الوظائف المُسمّى "AwesomeWeb" استخدم مطورو الموقع إطار عمل Ruby on Rails. بدأوا باستخدام مزيج من ووردبريس وإطار عمل CodeIgniter، ولكن لم يكن ووردبريس مرنًا كفاية لمثل هذه الحلول البرمجية عالية التخصيص. ومع ذلك، لن يحتاج معظم العملاء إلى حلول مخصصة. في ‎%98‎ من الحالات، سيحتاج العملاء إلى شيء شائع، مثل متجر على الإنترنت، أو علامة تجارية أو معرض أعمال (portfolio)، أو عضوية (membership)، أو مدونة للحصول على موقع تجاري بسيط. يمكنك بناء كل ذلك بسهولة باستخدام ووردبريس ومعرفة برمجية أساسية. هناك سبب وجيه لاستخدام ووردبريس من قبل الشركات الكبرى. السرعة والبساطة لماذا ووردبريس؟ ووردبريس هو نظام إدارة المحتوى (CMS) الأشهر، لسبب وجيه. صُمّمت %22 من جميع المواقع على الإنترنت باستخدام ووردبريس، وهي تشكّل حوالي 80 مليون موقع. إليك بعض الأسباب الرئيسية وراء شعبية ووردبريس: يسير التعلّم، ووردبريس برنامجٌ مفتوح المصدر. سهل وموثَّق (documented) توقيقًا شاملًا كذلك، بالإضافة إلى توفّر العديد من مقاطع الفيديو التدريبية المجانية. يحتوي العديد من الإضافات (plugins) والقوالب (themes)، أي لست بحاجة إلى خبرةٍ كبيرةٍ حتى تبدأ إنشاء مواقع باستخدام ووردبريس. في بعض الحالات، لا تحتاج إلى كتابة أي شيفرة برمجية لتحقيق النتائج التي تريدها. إنه قوي، يمكنك بناء الكثير عبره، مثل: متجر إلكتروني، ومدونة، وعضوية (membership)، ونماذج اتصال (contact forms)، بسهولة وسرعة فائقة من خلال استخدام القوالب (theme)، والإضافات المميزة. هناك آلاف من القوالب المجانية والمدفوعة متاحة على الإنترنت. قد يكون من المغري استخدام قالب مجاني، ولكن قبل اتخاذ هذا القرار، واصل القراءة.. الاستثمار مقابل أن تكون مكرّسًا وباحثًا عن المجانيّات. أقول ذلك لا يستحق المغامرة، ليس هنا لماذا استخدام قالب مدفوع أفضل من استخدام قالب مجاني؟ فوائد استخدام قالب مدفوع (premium theme)، مقابل القالب المجاني (free theme) كثيرة. السبب الأكثر أهمية لعدم استخدام قالب ووردبريس مجاني هو افتقارها للدعم والتوثيق (documentation) والتحديثات. فكّر في الأمر، إذا أنشأ المطوّر قالبًا مجانيًا، فهو لا يكسب أمولًا منها. لكنه لا يزال بحاجة إلى كسب لقمة العيش بطريقة أو بأخرى. لا يمكن أن يكون قالب ووردبريس المجاني خيارًا طويل الأمد، لأن المطوّر ليس لديه الحافز لدعم القالب مجانًا وتقديم التوثيق (documentation) وتحديثه خلال السنوات. هل ستقوم بكل هذا العمل مجانًا لو كنت في مكانه؟ لا يمكن توقّع مصادر التدريب (training resources) والوثائق (documentation) والدعم المجاني والتحديثات، عندما لا يكسب المطوّر منه أي مال. حتى لو كان أكثر الناس طيبة على وجه البسيطة، فإن كسب رزقه سيكون له الأولويّة دائمًا، علاوة على ذلك، ستكون القوالب (themes) المجانية أقل جودةً من تلك المدفوعة (premium) دائمًا. أنت تحصل على ما تدفع ثمنه. تتميز القوالب المدفوعة (premium themes) بشيفرة برمجية أنظف ووظائف أفضل. يقدّم جميع مزودي القوالب المدفوعة (premium themes) تصميمًا عالي الجودة وتوثيقًا معمّقًا (in-depth documentation) ودعمًا على مستوى عالمي. الدعم مهمٌّ للغاية، لأن هناك خطأٌ ما دائمًا أو شيء ما لا يعمل كما هو متوقّع. إذا اخترت قالبًا مجانيًا، فأنت تعتمد على حسن نية الآخرين لمساعدتك في المنتديات. أما عندما تختار شراء قالب ووردبريس مدفوع، فأنت تدفع مقابل الدعم ويكون مقدمو القوالب مسئولين عن مساعدتك. أفضل ما في الأمر أنّ قوالب ووردبريس المدفوعة تأتي بأسعار ميسورة جدًا بسبب المنافسة الشديد في السوق. هذه أخبار جيّدة لك! يمكنك شراء قالب مدفوع واحد مقابل 50 دولارًا أو الوصول لجميع قوالب المتجر مع الدعم مقابل 100 – 300 دولار/سنويًا. يمكنك استعادة هذه الأموال بسهولة من عميل واحد! لقد بدأوا في موقع ‎1stWebDesigner‎‎‎‎‎ منذ 7 سنوات بقالب ووردبريس مجاني، لكن الآن، لا ينظرون حتى النظر في القوالب المجانية. لأنها لا تستحق العناء ببساطة. أقترح عليك دفع 50 دولارًا مقابل قالب ووردبريس جميل وقابل للتخصيص الذي تريده مع التأكد من تضمين التوثيق (documentation) والدعم، مما سيوفّر لك الكثير من الوقت. هذا يعني أنك ستقضي الكثير من وقتك في محاولة معرفة الأشياء بنفسك. قوالب ووردبريس المدفوعة أم أطر عمل القوالب (Theme Framework) أم تطوير ووردبريس مخصص؟ عندما تنوي إنشاء تصميم ووردبريس مخصص، فهناك فقط طرق قليلة تبدأ بها. يتبّع الكثير من مصممي الويب المحترفين هذه الخطوات: العصف الذهني (brainstorm)، والحصول على فكرة عما يجب بناؤه، وكيف ينبغي أن يبدو التصميم. تصميم إطارات تخطيطية (wireframe) وتصميم موقع الويب ببرنامج فوتوشوب (Photoshop). تحويل ملف بصيغة PSD الناتجة من برنامج الفوتوشوب إلى قالب HTML / CSS. إضافة HTML / CSS إلى ووردبريس المثّبت. إضافة الوظائف (functionality) وعناصر ديناميكية (dynamic elements) مثل المدونة، والمتجر الإلكتروني. يبدأ بعض مصممو الويب مباشرةً بـ HTML / CSS ثم ينتقلون إلى ووردبريس، بينما ينتقل آخرون مباشرةً من صيغة ملف الفوتوشوب PSD إلى ووردبريس، وهي طريقة فعّالة بالفعل للعمل! ومع ذلك، يبدأ مصممو الويب الأذكياء وذوي الخبرة بقالب (theme) أو إطار عمل (framework) منذ البداية، واختيار التصميم (layout) والوظائف (functionality)، وتصميم الموقع بناءً على ذلك. يمكن القول أنّ هذه هي الطريقة هي الأكثر إنتاجية وفعالية لإنشاء المواقع. يؤمنون وبشدّة في ‏1stWebDesigner بهذا النهج. مثلًا، استغرق تصميم 1stWebDesigner السابق منهم أكثر من عام حتى الاكتمال عندما فعلوا ذلك بطريقة "تقليدية" بدءًا من الرسومات الأوليّة (sketching)، وتصميم الرسوم التخطيطية (wire framing)، وكتابة الشيفرة البرمجية المخصصة إلى ووردبريس. ومع ذلك، فإعادة تصميم موقع 1stWebDesigner حديث العهد لم يستغرق منهم سوى أسبوعين حتى الجهوز. بدأوا باستخدام إطار عمل Genesis، المخصص لقوالب ووردبريس، واختاروا قالبًا فرعيًا (child theme) بالتخطيط (layout) الذي أرادوه، وخصّصوا التصميم وأضافوا الوظائف (functionality)، وانتهوا من إعادة التصميم. هذا ما تعنيه الفعالية. يعد إنشاء قالب ووردبريس المخصص خيارًا جيدًا إذا كنت تعمل مع عملاء ذوي رواتب عالية، ومستعدين لدفع تكاليف الحلول المخصصة. تعدّ الشيفرة البرمجية المخصصة (custom code) ضرورية لبناء التطبيقات، وبرامج الويب، ومواقع العلامات التجارية الكبيرة جدًا. في هذه الحالات، لن تستخدم ووردبريس نهائيًا، ومع ذلك، فمعظم العملاء لا يحتاجون إلى ذلك. ما يحتاجونه هو موقع أعمال بسيط يحقق أهدافهم. لن يقدّروا شيفرتك النظيفة جدا (clean code) بقدر ما يقدّرون تسليم المشاريع السريع، وموقع الويب الذي ساعدهم في كسب المزيد من المال. ماذا يوجد خلف الكواليس؟ ما اطار عمل قوالب ووردبريس (WordPress theme framework)؟ قبل البدء في اختيار إطار عمل (framework) أو استخدامه مباشرةً، من المهم أن تفهم بالضبط ما هو إطار العمل وما يمكن أن يفعله لك. إطار عمل ووردبريس هو عبارة عن قالب ووردبريس متقدم مع بعض الإمكانيات، بكل بساطة. كلما طوّرت موقع ويب، فغالبًا ما تستخدم نفس المكونات (components). ستبدأ بالأساسيات، ثم تختار التصميم والتخطيط (layout) لـ (الترويسة [header]، والتذييل [footer]، صفحة ذات عمود واحد [single column]، وصفحة ذات عمودين). بعد ذلك، تبدأ بالعمل على الوظائف الرئيسية، مثل: المتجر الإلكتروني، وصفحة المبيعات، وصفحة العضوية (membership)، والمدونة. أخيرًا، عليك التفكير في إنشاء وظائف إضافية، مثل نماذج الاتصال (contact form) والحماية (security) وتحسين موقعك لمحركات البحث (SEO) وتجاوب موقعك لجميع الأجهزة (responsiveness). أطر عمل ووردبريس هي قوالب مبدئية (starter themes) تستخدمها أساسًا لإنشاء تصميماتك المخصصة. تسرّع أطر العمل عملية تطوير الموقع تسريعًا ملحوظًا. باعتبارك مطور ويب يعمل باستمرار على إنشاء قوالب ووردبريس مخصصة، فربما تكون قد سئمت من كل هذه المهام المتكررة، مثل كتابة نفس الشيفرة البرمجية مرارًا وتكرارًا، والتحقق من منها تحققًا مستمرًا. توفّر أطر عمل القوالب الكثير من الوظائف الجاهزة (built-in) وخيارات التخصيص، لذلك لا تحتاج إلى كتابة الشيفرة البرمجية لكل شيء من الصفر. صُمّمت أطر العمل بقوالب من نوع "أب" (parent theme) تستخدم هذه القوالب نقطة انطلاق لإكمال التصميم. هذه القوالب (قوالب الأب) هي الأساس الذي لا يُمس. يمكنك استخدام قالب الابن لإنشاء تصميماتٍ فريدةٍ ووظائفٍ إضافية. لماذا يستخدم مصممو الويب والمطوّرون أطر عمل ووردبريس؟ السبب الأكبر لاستخدام المصممين لإطار العمل هو تسريع عملية التطوير. تقلِّل أطر عمل القوالب على وقت التطوير تقليلًا عظيمًا؛ لأنك لست بحاجة إلى البدء من الصفر. يمكنك استخدام إطار العمل نقطة انطلاقة لتصميم قالبك النهائي، ثم يمكنك إضافة وظائف باستخدام وحدات (modules) مختلفة، مثل وظيفة السحب والإفلات (drag and drop)، وشريط التمرير (sliders)، والمتاجر الإلكترونية. يمكنك غالبًا الوصول إلى الوظيفة عن طريق تفعيل شيفرات برمجية قصيرة جاهزة (built-in) في إطار عمل ووردبريس. بدلاً من إنشاء قالب وكتابة شيفرته البرمجية من الصفر، يمكن أن يكون إنشاء موقع ووردبريس بسيطًا كإنشاء ملف تنسيقات style.css جديد، وتخصيص بعض الوظائف، وإضافة عناصر مرئية (visuals) يحتاجها عميلك. ثم، هأنتَ ذا انتهيت من الموقع! سيكون عميلك راضيًا بسبب التسليم السريع! من ناحية أخرى، ستكون سعيدًا لأنك اخترقت طريقك للتوّ من خلال عملية التطوير، وأنشأت موقع الويب الذي يريده العميل بسرعة فائقة! يمكنك الآن استثمار وقت إضافي في العمل مع عميلك والتأكد من أنّ موقع الويب هذا يحقق أهداف عميلك ويأتي بالنتائج الصحيحة. فوائد وعيوب استخدام إطار عمل ووردبريس إنها حقيقة أنه سيكون هناك دائما إيجابيات وسلبيات لقرارك. إيجابيات استخدام إطار عمل ووردبريس: توفير الوقت، وفعالية التطوير، والسرعة، وسهولة التطوير. كما ذُكر سابقًا أنه باستخدام إطار عمل القالب يمكن أن يقلّل وقت التطوير تقليلًا عظيمًا، ويسمح لك بتسليم العمل بسرعة. دعم قوي، ومجتمع من مطوري ووردبريس ذوي الخبرة. تحتوي أطر عمل ووردبريس الأكثر شهرةً على مجتمع ضخم ورائها، مما يساعدك على إصلاح الأخطاء وإيجاد الحلول بسرعة. الوظائف الجاهزة (built-in functionality). إضافة وظيفة فعالّة سهل للغاية مع التكامل الذي توفرّه متاجر القوالب الكبيرة. جودة الشيفرة البرمجية. تًكتب الشيفرات البرمجية باستخدام أفضل ممارسات ومعايير ووردبريس. وتكون شيفرات HTML و CSS و PHP محسّنة، كما أنها مُحسنة بأكبر قدر لمحركات البحث. الترقيات. سهولة التحديثات للإصدارات المستقبلية من ووردبريس ولا داعي للقلق بشأن ذلك. سلبيات استخدام إطار عمل ووردبريس: منحنى التعلم، سيستغرق الأمر بعض الوقت لإتقان أيٍّ من هذه الأطر. التكلفة، إطار العمل أغلى قليلاً من القالب المدفوع، لكنه يستحق ذلك. القيّود، تحدّد أطر العمل ما تستطيع وما لا تستطيع فعله. لا يمكنك كسر هذه الحواجز. يمكن أن يكون هذا عيبًا بالنسبة للمصممين المبتكرين الفائقين، لكن في معظم الحالات، يكون إيجابيًا وليس سلبيًا. شيفرات برمجية لا داعي لها، تأتي أطر العمل مع الكثير من الوظائف الجاهزة (built-in) التي قد لا تحتاجها. قد يؤدي هذا إلى إبطاء موقعك إذا لم تكن حريصًا على التخلّص من الخصائص التي لا تحتاجها. هل يجب عليّ استخدام إطار عمل ووردبريس؟ على الرغم من وجود منحنى تعليمي إضافي وتكلفة إضافية مأخوذة في الحسبان، يجب عليك حتمًا استخدام إطار عمل القوالب إذا كنت جادًا في تطوير مواقع ووردبريس. ستزداد سرعتك وسيتحسّن أداؤك تحسنًا كبيرًا قد يصل إلى عشرة أضعاف! ستكون قادرًا على التعامل مع عملاء أكثر وأفضل. علاوة على ذلك، سوف تكون قادرة على تلبية احتياجات عملائك وقضاء المزيد من الوقت في فهم أهدافهم، ستستطيع تنمية عملك من خلال القيام بذلك (استخدام أطر عمل القوالب). بناء موقع من الصفر يشبه بناء منزل دون مُخطّط (blueprint). في المقابل فالبدء بإطار عمل يشبه استخدام مُخطّط. سأل كاتب المقال نيكولاس تارت، وهو مصمّم يتمتع بخبرة 5 سنوات، عن رأيه في "وجوب استخدام إطار عمل" فأجاب نيكولاس: إنها حقيقةٌ لا تحتاج إلى كثير من التفكير في وجوب استخدام ووردبريس ووجوب تعلّم إطار عمل أو قالب مبدئي (starter theme) لخدمة عملائك خدمة جيدة. يركّزون في موقع ‎1stWebDesigner‎‎‎‎‎ بشِدّة على التوصية بووردبريس لمساعدتك أن تكون مستقلًّا ناجحًا. بالنسبة لمعظم المصممين المستقلّين، فمشكلتهم ليست في ضعف معرفة البرمجة والتصميم، ولكنها في ضعف مهاراتهم التجارية. سيدفع لك العملاء مقابل النتائج التي ستريهم إياها على هيئة موقع ويب. للقيام بذلك، تحتاج إلى تقليل التركيز قليلًا على التقنية وعليك بتعلم بعض مهارات التسويق. ترجمة -وبتصرف- للمقال Why You Should Choose WordPress من كتابة فريق التحرير بالموقع

يحتار المطورون في اختيار أفضل إطار لمشاريعهم وسيكون هذا تحديًا حقيقيًا للمبتدئين في الأطر الحديثة. بعد العمل على الأطر الثلاثة (Django، Laravel و Rails – والذي يُعرف باسم Ruby On -rails)، سأقارن بين هذه الأطر الرائعة على أساس شعارها، سهولة تعلمها، أدائها، قوة وضعف مكتباتها وقوالبها، دعمها، آفاقها المستقبلية، فرص العمل، التكلفة والصيانة. ملاحظة: ينتقد بعض المعجبين عند التحدث عن نقاط ضعف أطرهم، ولا أستطيع فعل أي شيء لأنه لا يمكن إخفاء الحقيقة، كل إطار لديه بعض المزايا مع بعض العيوب. المقدمة لغة البرمجة أهم فرق بين هذه الأطر هي أن Django بلغة بايثون، Laravel بلغة PHP وRails بلغة الروبي، لذا إذا كنت تنوي استخدام أي من هذه الأطر فيجب عليك تعلم لغتها أولاً، وبسبب هذا، العديد من المطورين يختارون الإطار الذي يتطابق مع اللغة التي يعرفونها. إن التحول من لغة إلى أخرى ليس صعبًا بل يحتاج إلى بعض الوقت، وإذا احترت في اختيار لغة البرمجة، فهذه مقارنة بين لغات بايثون و PHP وروبي. الشعار جميع هذه الأطر من نوع MVC وشعارها ‘لا تكرر نفسك’ أي تدعم إعادة الاستخدام وقابلية النقل، وجميعها مشاريع مجانية ومفتوحة المصدر. المواقع بعض المواقع المعروفة تستخدم Django مثل Pinterest، Instagram، Mozilla، The Washington Times، Disqus، the Public Broadcasting Service و Bitbucket. في حين أن Laravel هو إطار جديد، حيث صدر في يونيو عام 2011، لكنه أصبح مشهورا جدا، ومن بين المواقع التي تستخدمه هي Deltanet Travel، Sublimity، Neighborhood Lender، Sendity و MyRank. يعتبر Rails من الأطر الرائعة فمن المواقع التي تستخدمه Twitter، Shopify، SoundCloud، Heroku، Github، Bloomberg و Hulu. سهولة التعلم على الرغم من أن الأطر الثلاثة لديها مجتمعات كبيرة وتوثيق رسمي، إلا أن تعلم Django وLaravel أسهل بكثير من تعلم Rails، فالتوثيق الحالي ل Django يجعلها الأسهل، وإذا كنت تملك خلفية PHP فيمكنك تعلم Laravel في غضون أسبوعين أو ثلاثة أسابيع، وهذه هي الوثائق الرسمية: وثائق Django ووثائق Laravel وثائق Rails. الأداء الأمن جميع هذه الأطر آمنة جدا إذا لم يرتكب المبرمج أخطاء، فيمتلك Django برمجيات وسيطة ويمتلك Rails Active Records وأما Laravel فيمتلك برمجيات HTTP وسيطة، وتوفر كل هذه الأطر رموز csrf للنماذج. لا يوجد فرق أمني كبير بين هذه الأطر، وكل هذا يعتمد على خبرة المبرمج. تحديث:أشار بعض القراء أن المبرمجين هم بشر وسيخطئون، لذا سأقول في هذه الحالة أن Django هو الأكثر أمانا وLaravel هو الأقل أمانًا، اطلع على هذا التوثيق عن أمن Django وهذا دليل أمن Rails و هذا دليل أمن Laravel، وسأقول أيضا أنه لا يوجد إطار آمن بشكل كامل لأن المطورين هم أيضا بشر، ويمكنك زيادة الأمن لكنك لا تستطيع جعله آمن بنسبة 100%، لكن إذا كتبت التعليمات البرمجية بعناية وحذر فإن جميع الأطر متساوية من ناحية الأمن. السرعة جميع الأطر مكتوبة بشكل صحيح، لذلك سرعتها تعتمد على اللغة البرمجة المستخدمة، فDjango هو الأسرع بسبب البايثون و Laravel هي الأبطأ بسبب PHP. الوقت المطلوب لإنشاء تطبيق إذا كنت تفهم الإطار بشكل كامل فإن إنشاء تطبيق Rails هو الأسرع لأنه يوفر لك الكثير من الاختصارات وبهذا ستكتب أقل عدد من الأسطر البرمجية. ومن جهة أخرى، Laravel هو الأبطأ ولا يوفر مكتبة قوية. إذا كان المشروع معقد فإن الفرق الزمني بين تطبيقات Django وRails سيكون صغيرًا بسبب صياغة بايثون المريحة للمتابعة وأقل أرباك، أما بالنسبة لـ Laravel فيجب عليك كتابة الكثير من الأسطر البرمجية وهذا قد يسبب لك بعض الإرباك وسترتفع نسبة الأخطاء. قوة وضعف المكتبة الأشياء المشتركة في جميع الأطر: جميعها MVC (يسمى Django MTV أيضا لكن على الرغم من أن الاسم مختلف إلا أن المفهوم هو نفسه). تركز جميع الأطر على قابلية القراءة وبساطة الشيفرة البرمجية وتوزيع الملفات. جميعها تستعلم تلقائيًا من قاعدة البيانات، فلا يجب عليك كتابة استعلامات قاعدة البيانات بشكل مباشر. تبنى الجداول تلقائيا في قاعدة البيانات من النماذج (models). جميع الأطر تملك نظام توجيه سهل وآمن، وتعرض صفحات الويب بشكل حيوي. تملك جميعها أنظمة قوالب خاصة بها وكل نظام قوالب غني بالمرشحات والدوال المعرّفة مسبقًا، الفرق الوحيد في الصياغة. جميعها مرنة ومحمولة مع تقنيات حديثة أخرى. Django يمتلك Django مكتبة قوية مع المميزات التالية: يعتبر قسم الإدارة المدمجة، المزخرف (decorator)، وأصناف المناظر نقاط قوة ل Django. الاستمارات المولدة تلقائيا للنماذج مع عملية التحقيق تجعلها سهلة للغاية. يدعم الإطار خاصية التخزين المؤقت وستتمكن من استخدام أي من أساليب التخزين المؤقت المتاحة. يدعم الأصناف البرمجيات الوسطيّة والتي يمكن أن تتدخّل في مراحل مختلفة من معالجة الطلب وتُنفّذ دوال مخصصة. يسمح لك نظام مرسل (dispatcher) داخلي لمكونات التطبيق اتصال الأحداث مع بعضها البعض عبر إشارات محددة مسبقا. يملك نظام تدويل يتضمن ترجمات لمكونات Django إلى لغات مختلفة. يملك نظام تسلسل الذي يمكنك من إنتاج وقراءة تمثيل XML و/أو JSON لمثيلات نموذج Django. واجهة بايثون مدمجة في إطار اختبار الوحدة. نظام مصادقة (authentication) موسّع. واجهة إدارة حيوية. أدوات لتوليد RSS وتغذيات (feed) خلاصات Atom. إطار مواقع تسمح ل Django واحد بتشغيل مواقع متعددة، ولكل منها المحتوى والتطبيقات الخاصة به. يملك أدوات لتوليد Google Sitemap. يملك تقنيات مدمجة للتخفيف من التزوير عبر الموقع، ثغرات XSS، ثغرات حقن SQL، تكسير كلمات المرور وهجمات الويب النموذجية، ومعظمها يعمل افتراضيا. إطار لإنشاء تطبيقات GIS. Laravel على الرغم من أن مكتبات Laravel ليست قوية مثل Django وRails إلا أنها كافية لإنشاء أي نوع من المواقع. يوفر Bundles و composer عدد من حزم نظام وحدات التحزيم والاعتماديات. التوجيه (Routing) – يوّفر طريقة سهلة وبسيطة لإدارة وتوجيه الروابط إلى متحكم أو دالة تُنفَّذ عند زيارة رابط محدَّد. دعم Eloquent ORM – خدمة أخرى مقدمة لتجريد وأتمتة جزء النموذج، حيث سنطبق التقنيات المتعارف عليها على الإعدادات. التهجيرات – طريقة لإصدار سكربتات قواعد البيانات بطريقة أنيقة للغاية، فلا حاجة للحفاظ على جميع التحققات على التهجيرات، يمكن لفريق عمل المشروع سحب الهجرة المقدمة وستعيّن جميعها وستكون جاهزة للعمل. إدارة قائمة الانتظار (Queue management) – لتجريد المهام غير الضرورية ووضعهم في قائمة الانتظار وجعل وقت استجابة المستخدم أسرع بكثير. دعم Redis، ويمكن توسيعها إلى memcached. حقن الإعتماديّة – اختبار سهل وأتمتة تحميل الإعتماديّة. Artisan – لإنشاء تطبيقات سطر الأوامر في لحظة. تعلم استخدام Laravel عن طريق هذه الدروس. Rails يتضمن Rails أدوات لجعل مهام التطوير الشائعة أسهل (خارج الصندوق)، مثل scaffolding الذي يستطيع إنشاء بعض النماذج تلقائيًا والمناظر اللازمة لموقع ويب الأساسي، بالإضافة إلى WEBrick وهو خادم ويب روبي بسيط الموزع مع روبي و Rake والذي هو نظام بناء موزع كـ gem. وتوفر هذه الأدوات جنبا إلى جنب مع Rails بيئة تطوير أساسية. Active record: يلعب دورا رئيسيا في تطبيقات Rails، وهو أفضل من Eloquent ORM في Laravel ومن النماذج في Django. اختصارات: يعبر الكثير من الناس الذين يأتون من لغات برمجة أو إطارات أخرى أن هذا الإطار سحري بسبب الاختصارات الكثيرة، فأغلب الأشياء معرّفة مسبقًا ويجب عليك كتابة بعض الأسطر البرمجية لإنشاء تطبيقات معقدة. التوجيه التلقائي: بعض الدوال الشائع في جدول قاعدة البيانات مثل الإنشاء ، التعديل والعرض مُعرّفة تلقائيًا، وهذا يعني أننا لا نحتاج إلى تضييع الوقت في المهام البسيطة ويمكننا قضاء وقت أطول على الأجزاء المعقدة من المشروع. سطر الأوامر: الكثير من الأشياء يمكن إنجازها عن طريق سطر الأوامر مثل استخدام rake وهي Ruby Make، أداة روبي مستقلة تستبدل أداة يونكس 'make' وتستخدم 'Rakefile' وملفات .rake لبناء قائمة مهام. في Rails، يُستخدم Rake لمهام الإدارة الشائعة، خاصة المعقدة منها التي تبني من بعضها البعض. تحتوي وحدة ActiveModelHelper على أساليب المساعدة لإنشاء النماذج من الكائنات بسرعة التي تتبع اتفاقيات Active Model، بداية من Active Record. خدمات الاستضافة يمكنك تشغيل أي تطبيق على VPS أو على خدمة استضافة مخصصة، وهذه مجموعة من الروابط لمواقع تسمح لك باستضافة مشروعك مجانا أو على خطط الاستضافة المشتركة. Django: بعض من المواقع التي تستضيف مشاريع Django هي: WebFaction، PythonAnywhere ، Heroku ، Digital Ocean ، Bulehost ، Dreamhost ، Arvixe و Google App Engine. Laravel: يمكنك الاستضافة على Heroku ، Bulehost ، Inmotion Hosting ، Site5 ، Dreamhost ، Digital Ocean و Arvixe. Rails: مواقع لتطبيقات Rails هي: Heroku ، Bulehost ، Dreamhost ، Arvixe ، Hosting24 و Digital Ocean. معايير أخرى كل هذه الأطر جيّدة في المستقبل، ففرص العمل، التكلفة والصيانة هي تقريبا نفسها ويمتاز Rails على Django وLaravel في شروط العمل، على الرغم من سرعة نمو Laravel. خاتمة يمكنك أن تختار أي واحدة من هذه الأطر حسب لغة البرمجة والخبرة، وإذا كنت هنا لتقرر أي واحدة يجب عليك تعلمها فأنا أفضل Rails، فعلى الرغم من صعوبة تعلمها إلا أنها مريحة أثناء إنشاء التطبيقات، إذا أردت أشياء سهلة مع الكثير من المميزات فاختر Django، فصياغة بايثون ونماذجه تجعله خيار جيدا، وعلى الرغم من أن تعلم Django قد يستغرق بعض الوقت إلا أنه ليس أصعب من Rails.إذا كانت لدي خبرة في PHP أو إذا أردت التعلم بسرعة فاختر Laravel. ترجمة -وبتصرّف- للمقال Django vs Laravel vs Rails لصاحبه Harish Kumar

أقدّم بين أيديكم هذه السلسلة التي استلهمت فكرتها من كتب برمجة صغيرة مجّانيّة ومحبّبة، مثل كتاب The Little Book on CoffeeScript لمؤلّفه Alex MacCaw. لقد ألّفت هذه السلسلة لتعليم Angular بالطّريقة التي تمنّيت أن أتعلمها بها، ولذلك فهذه السلسلة معينك للانطلاق السريع مع Angular واستخدام هذه المكتبة الرائعة في عملك كمطوّر ويب. أسلوب هذه السلسلة مستلهم من مبدأ باريتو Pareto فهي تعلّمك جزءًا كبيرًا من نقاط قوّة Angular دون أن تثقل كاهلك بالكثير من تعقيداتها، وستتمكّن بعد إنهائك لهذه السلسلة من كتابة تطبيقات واجهة front-end قويّة، وستدهشك سهولة ذلك، بالرّغم من أنّ السلسلة لا تقدّم إلا جزءًا محدودًا ممّا عليك تعلّمه لاحتراف Angular بشكل كامل، لكنها ستمنحك الثّقة الكافية للقيام بذلك لأنّ خبرتك ستكون مبنيّة على التّجربة العمليّة أثناء قراءتك لدروسها، فهي بحدّ ذاتها صفحات ويب ديناميكيّة تحوي آخر نسخة من Angular وتستخدمها لتنفيذ جميع الأمثلة بشكل مباشر، وجميع الشّيفرات البرمجيّة تتيح التّعديل المباشر عليها ممّا يغيّر المخرجات مباشرة، وأتمنّى لو تقوم بكلّ التّجارب والتّعديلات التي تخطر على بالك عند كل مثال. إذا كنت ترغب في معرفة سبب كتابتي لهذه السلسلة يمكنك قراءة هذه المقدّمة إلى نهايتها فهي تتضمّن بعضًا من ذكرياتي مع Angular، ثم سنناقش أفضليّة استخدام Angular في مشاريعك. هل هي صعبة أم سهلة؟لقد عملت من قبل على تطبيقات معتمدة على Web MVC لما يزيد عن عشر سنوات، واستعملت الكثير من الأدوات بدءًا من Struts وانتهاءً بـSpring MVC مرورًا بـRuby on Rails وBackbone، حتّى أنّني قمت بكتابة كتاب Backbone and CoffeeScript لذا كان من الطّبيعي بالنّسبة لي أن أفترض أنّ تعلّم ِAngular سيكون بسيطًا بالنسبة لي، إلّا أنّ تقدّمي في تعلّمها واجه سدًّا كبيرًا من المصطلحات غير المألوفة بعد غوصي في توثيق هذه المكتبة، مصطلحاتٌ مثل transclusion، توجيه directive والمجال المعزول isolate scope، وكلّما قرأت أكثر في التّوثيق الرّسمي للّغة ودروسها تأكّدت أكثر بأنّني كنت أتوهّم عندما ظننت بأنّ Angular أداةٌ سهلة، وأتذكّر بشكل خاصّ مروري على العبارة التّالية: لن تجد العبارة السابقة هذه الأيام داخل توثيق اللّغة، والشّكر يعود للجهود الجادّة التي بذلها فريق ِAngluar لتحسين التّوثيق، وعلى أيّ حال فالاقتباس السّابق جعلني أشعر بالجهل وبدأت الشّكوك تراودني والقلق يساورني: هل هذه المكتبة مجال جديد كلّيّا عليّ؟ كانت الإجابة تأتيني من كلّ الجهات تقريبًا: إنّ ِAngular تقنيّة معقدّة، ولا مجال للعبث معها، ففي ملتقيات المبرمجين على Stack Overflow ومجموعة AngularJS على Google وفي كلّ مكان آخر، كانت تفاصيل هذه المكتبة محلّ النّقاشات المطوّلة، مع توثيقات مرعبة للمشاكل والأفخاخ والحيل فيها، فشمّرت عن ساعد الجد كأي محترف يحترم نفسه وقبلت هذا التّحدّي، ومع مرور الوقت أصبحت أكثر ألفة مع هذه المفاهيم والمصطلحات، وتقبّلت أنّ تعلّمي هذه الأداة سيكون بطيئًا، إلى أن جاء ذلك اليوم الذي شاهدت فيه مقابلة مع Miško Hevery مخترع Angular، وبعد ذلك اكتشفت حقيقة بسيطةً إلّا أنّها كانت شديدة الأهمّيّة: الهدف الأصليّ من Angular هو سهولة الاستخدام. لقد بيّن Hevery بأنّه أراد أن تكون Angular أداة ليستخدمها غير المبرمجين، ليتمكّنوا من بناء صفحات ويب ديناميكيّة باستخدامهم لنصوص تصريحية بسيطة، لقد اكتشفت بأنّني قد تعمّقت في الكثير من تفاصيل Angular دون أن أجني منها فائدة مكافئة للوقت والجهد المبذول، ورغم أنّ مشروع Angular ومجتمع Angular أصبحا معتمدين على بعضهما بشكل وثيق حيث تقدّم المكتبة التّحديات والتّعقيدات التي تشبع شغف هؤلاء، إلّا أنّه كان هناك طريق أفضل لاستخدام المكتبة كما أراد مخترعها، بعيدا عن مبدأ عملها المصنوع بعناية، وقد كان الصّواب بالنسبة إليّ الابتعاد عن هذه الأمور الدّاخليّة الدّقيقة وتركها آمنة لتقود كلّ شيء دون المساس بها، وبعد أن اعتمدت هذا المبدأ في التعامل معها وبالرّغم من وجود العديد من الأدوات الأخرى إلّا أنّ شمس Angular صارت تشرق لي عند مواجهة العديد من الحالات. هل تناسبك؟تعتمد إجابة هذا السّؤال على معرفتك لمشروعك بدقّة، فعليك معرفة فيما إن كان يحتاج بالفعل لمعالجة البيانات وإخراج HTML في طرف الزّبون، أم أنّك تخدع نفسك ببعض المتطلّبات الإضافيّة لتعطيها دافعًا لتعلّم أداة جميلة وجذّابة، فقد لا تلزمك Angular إن كان بإمكانك الاعتماد على بعض المعالجة من طرف الخادوم مع "رشّةٍ" من التّفاعل المعتمد على jQuery. ضع في حسابك أنّ Angular واسعة وتدعو للتشبّث بها، فبالرّغم من أنّنا ندعوها "مكتبة" إلا أنّ دعمها الذّاتي للـوحدات modules ولـحقن التّبعيّة dependency injection سيفرض على المطوّر طريقة إدارة مشروعه، وقد يُفضّل حلًّا آخر على Angular، ربّما سيختار أداة أقدم منها ومتميزةً بكونها الأفضل في وقتها، لكنّه قد يجد أنّه من الصّعب أو المستحيل أن تحلّ محلّ Angular، أضف إلى ذلك أنّك لن تحتاج إلى الدّعم الفنّي من فريق تطوير Angular إن لم تكن تنوي أن يصبح مشروعك كبيرًا بالقدر الّذي يعتبره مهندسو Google مثاليًّا. هناك مشكلة أخرى تظهر عندما تحاول دمج شيفرات Angular مع شيفرات غير Angular وتريدها أن تعمل إلى جانب تغليف Angular للبيانات أو آلية إخراج الصفحة فيها، سيكون عليك عندها الغوص في تفاصيل غامضة في Angular غوصًا عميقا، قارن ذلك مع Backbone التي تعد طبقة رقيقة فوق jQuery فهي أصغر وأقرب للفهم، وإن كان تطبيقك معتمدًا بشكل كبير على ملحقات jQuery فسيكون عليك استخدام Backbone لتزيد من التّحسين في تصميم تطبيقك. أخيرًا، إنّ لطريقة Angular الأساسيّة للرّبط ثنائي الاتجاه بين عناصر واجهة المستخدم وكائنات النمذجة حدودًا تعتمد على مدى تعقيد التّطبيق، وقد تشارك المطوّرون في Facebook خيبة أملهم بربط البيانات ثنائيّ الاتجاه فقالوا: وبالرّغم من كون مكتبة React الخاصة بـFacebook بالكاد تهتمّ بالإخراج ومن ثمّ فهي تعدّ حلّا جزئيًّا بالمقارنة مع Angular، إلّا أنّ تطبيقات طرف الزّبون التي تعتمد عليها تستحقّ التقدير حقًّا. أسباب هامة تدفعك لاستخدام Angularلا شك أنّ Angular هي أشهر مكتبات JavaScript المختصّة بحلول النّمذجة والعرض عالميًّا في هذه الأيام، فقد حصلت على أكثر من 33000 نجمة على GitHub، وربّما ازدادت أكثر من ذلك بكثير منذ وقت كتابة هذه السلسلة إلى اليوم، فقد تربّعت على قمّة قائمة الحلول المطروحة التي تمّت دراستها ومقارنتها بواسطة مشروع TodoMVC وسنناقش الآن بعض أسباب نجاح Angular. الإنتاجية الآنيةإذا كان مشروعك بحاجة إلى واجهة مستخدم معقّدة إلى حدّ ما لتقوم بعمليات إدارة البيانات CRUD على البيانات من طرف الزّبون، فإنّ Angular ستفي بوعدها لك بتحقيق إنتاجيّة شبه آنيّة، فبإضافتك لرشّةٍ من بعض الخصائص المميّزة غلى نصّ HTML الأصلي، والقليل من شيفرات Javascript، ستتمكّن من جعل صفحتك تتفاعل مع المستخدم، في حين كنت ستحتاج إلى الكثير من المهارات وبذل الجهود لتقوم بذلك باستخدام مكتبة أدنى مستوى. الألفةتعتمد Angular على كتابة شيفرات JavaScript السّهلة ونصوص مطابقة تقريبًا لتعليمات HTML، لقد قلت "تقريبًا" لأنّ Angular تقدّم عناصر وخصائص جديدة وبعض الشيفرات المستغربة، إلّا أنها بالمقارنة مع أنظمة القوالب الأخرى تبقى قريبةً جدًّا إلى HTML النّقيّة، وهذا يجعلها سهلة الفهم لأغلبية مطوري الويب. المرونةتتبنّى Angular التّوجّه الحالي نحو التكيف مع واجهات المستخدم في أطر عمل JavaScript، دون الكثير من التّضحية بإنتاجيّتها، فإن كنت تحبّ العمل مع أحد أطر العمل الشهيرة المختصة بواجهة المستخدم مثل Bootstrap فستتمكّن من الاستفادة من الإضافة المقدّمة من مشاريع طرف ثالث مثل AngularUI لتقوم بتكامل سهل. لذا سواء كنت تريد زخرفة صفحة ويب تقليديّة ببعض التّطبيقات التفاعلية هنا وهناك، أو كنت تريد تطوير تطبيقٍ كاملٍ وحيد الصّفحة فإن Angular ستكون الأفضل للعمل ضمن شروطك ومحدداتك. المعايير المستقبليةلا أدري أيّهما أكثر صحّة، إن كانت Angular متبصّرة بالمستقبل أو أنّ Google والدةَ Angular ستصنع المستقبل، إلا أنّه من الواضح أنّ استخدامك لـAngular سيكون طريقة ناجحة لتألف المعايير المقترحة مثل Web Components وأضف إلى ذلك أنّني أتوقّع بقاء Angular واستمرارها لأنّها تواكب ميزات JavaScript المرتقبة مثل Object.observe. مجتمع Angularلابدّ أنّ أحد أقوى الأسباب لاختيار Angular بدلًا من منافساتها هو أنّها الأكثر شيوعًا، فهي تُستخدم الآن في عدد غير محدود من مواقع الويب كثيرة الزيارة، ولكن تذكّر بأنّ الجري وراء الأغلبية ليس الصّواب دومًا وليس لكلّ النّاس ولا في كلّ الأحيان، وعليك أن تدرس متطلّبات مشروعك الحقيقيّة بعناية. عن هذه السلسلةلقد جاءتني فكرة الكتب التفاعلية منذ عدّة سنوات أثناء قراءتي لكتاب إلكترونيّ عن البرمجة باستخدام JavaScript على حاسوبي المحمول، فقد توجّب عليّ لتجربة أحد أمثلة الكتاب أن أقوم بتحميله من موقع النّاشر، ثم البحث عن موضع الملفّ الذي تم تحميله وإيجاد مكان لفكّ ضغطه، ثم الإبحار عبر الكثير من الملفّات إلى أن أعثر على الشّيفرة المطلوبة، وأفتحها أخيرًا في أحد المحرّرات، ثمّ أكتشف بأنّ عليّ إنشاء ملف HTML ليُشغّل السكربت، وبعد كلّ هذا لا تعمل الشيفرة وأكون قد ضيّعت وقتي في مطاردة أماكن الملفّات والارتباطات. لم كلّ هذا؟ إن كنت أقرأ كتابًا عن تقنية front-end على الحاسوب فهل عليّ أن أعاني كلّ تلك المعاناة لأشغّل المثال؟ لقد اكتشفت بعد مدّة قصيرة من ذلك النّسخةَ الأولى لكتاب Marijn Haverbeke المسمّى Eloquent JavaScript واكتشفت بأنّه بإمكاني استخدام مشروعه CodeMirror لأنشر رؤيتي الخاصّة: كتاب إلكترونيّ رائع المظهر، أنيق الحروف وجميل التّصميم، ولكن مع أمثلة حية قابلة للتّعديل والتّشغيل مباشرة من الدّرس ذاته، ولهذا ستجد جميع أمثلة السلسلة داخل محرّرات حيّة تفاعليّة، وستجد مخرجات هذه الشيفرات مباشرة تحت المثال داخل صندوق iframe. <div ng-app=""> <strong>The lucky number {{11+12}}</strong> </div> See the Pen angular-intro by Hsoub Academy (@HsoubAcademy) on CodePen. هيّا حاول تغيير المثال أعلاه الآن، رغم أنك لم تتعلم شيئًا بعد عن Angular، قم ببعض التغييرات على المثال وراقب التّغييرات. ماذا بعد؟سيأخذك الفصل الأوّل من هذه السلسلة في رحلة لطيفة للتّعرف على مبادئ Angular في القولبة templating من طرف الزّبون وفي الرّبط ثنائيّ الاتّجاه، وقد أقرّ العديد من المطوّرين المحترفين في ِAngular بأنهم استفادوا من هذا الفصل رغم أنّ جميع أمثلته بسيطة ويمكن فهمها بلمحة سريعة. ترجمة وبتصرّف للجزء الأول من كتاب: Angular Basics لصاحبه: Chris Smith.