Init.js: دليل إلى سبب وكيفية استخدام JavaScript كامل المكدس

القصة

إذن ، لديك أنت وشريكك المؤسس هذه الفكرة الرائعة للعمل ، أليس كذلك؟

لقد كنت تضيف ميزات في عقلك.

كثيرًا ما تسأل العملاء المحتملين عن آرائهم ، ويحبونها جميعًا.

حسنًا ، لذلك يريدها الناس. حتى أن هناك بعض الأموال التي يجب جنيها. والسبب الوحيد لعدم تمكنهم من الحصول عليها هو أنك لم تنفذها - حتى الآن.

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

"منجز! إنها تعمل!" قول انت. إثبات المفهوم الخاص بك هو نجاح! كل ما تبقى هو تجميعها في تطبيق ويب.

أنت تقول "حسنًا ، لنقم بإنشاء الموقع".

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

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

تقولون ، "أنا مرتبك" ، لأنك تشعر بالإرهاق. طاقتك ليست هي نفسها كما كانت من قبل. تحاول تجميع الأشياء معًا ، لكن هذا يتطلب الكثير من العمل.

دليلك على المفهوم يذبل ببطء ويموت.

الإقتراح أو العرض

بعد تخلي عن الكثير من الأفكار بنفسي بهذه الطريقة ، قررت تصميم حل. أسميها مشروع "التهيئة" (أو init.js).

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

لتحقيق هذا الهدف على أفضل وجه ، علينا أن نضع بعض الأفكار الرئيسية في الاعتبار. عند تطوير Init ، فكرت في:

• عناصر

  يعد المكون سمة أساسية لأي نظام لأنه يسمح لك بإعادة استخدام مكونات البرامج عبر مشاريع مختلفة - وهو الهدف الرئيسي لـ Init. لكن المكونات تأتي أيضًا مع منتج ثانوي ، "قابلية الاستبدال" ، والذي سيكون أفضل حليف لنا في مهاجمة العديد من المشكلات المختلفة باستخدام نفس الحل "تقريبًا".

• سهولة التطوير

  بعض المشاكل ، في مكان ما لديه حل أفضل مكتوب في Brainf * ck. لكن تنفيذ هذا الحل (في Brainfuck) سيكون شبه مستحيل الكتابة ، ناهيك عن القراءة. سيكلفك وقتًا وقدرًا هائلاً من الجهد. بشكل عام ، يجب عليك استخدام اللغات والنظام الأساسي الذي يجعل التطوير أسهل ، وليس أصعب عليك (أو أي شخص قد يعمل عليه لاحقًا).

• تواصل اجتماعي

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

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

في جوهرها ، تستفيد Init من نموذج "مكدس JavaScript كامل المكدس" (يشير بعض الأشخاص إليه ، أو مجموعة فرعية منه ، باسم MEAN Stack). من خلال العمل مع مثل هذا المكدس ، يمكن لـ Init استخدام لغة واحدة فقط أثناء إنشاء بيئة مرنة ومميزة بالكامل لتطوير تطبيقات الويب. باختصار ، يتيح لك Init استخدام JavaScript ليس فقط لتطوير العميل والخادم ، ولكن أيضًا للبناء والاختبار والقوالب والمزيد.

لكن دعنا نبطئ للحظة ونسأل أنفسنا: هل من الجيد حقًا استخدام JavaScript؟

لماذا اخترت JavaScript

أنا مطور ويب منذ عام 1998. في ذلك الوقت ، استخدمنا لغة Perl في معظم عمليات تطوير جانب الخادم ، ولكن منذ ذلك الحين لدينا JavaScript في جانب العميل. لقد تغيرت تقنيات خادم الويب بشكل كبير منذ ذلك الحين: لقد مررنا بموجة تلو الأخرى من اللغات والتقنيات مثل PHP و AP و JSP و .NET و Ruby و Python ، على سبيل المثال لا الحصر. بدأ المطورون يدركون أن استخدام لغتين مختلفتين لبيئات العميل والخادم كان يعقد الأمور. حاولت المحاولات الأولية للتوحيد تحت لغة واحدة إنشاء مكونات العميل على الخادم وترجمتها إلى JavaScript. لم ينجح هذا كما هو متوقع وفشلت معظم هذه المشاريع (على سبيل المثال: حل ASP MVC محل نماذج ويب ASP.NET ، ويمكن القول إن GWT تم استبداله في المستقبل القريب بواسطة Polymer). لكنها كانت فكرة رائعة ، في جوهرها: لغة واحدة على العميل والخادم ، مما يسمح لنا بإعادة استخدام المكونات والموارد (هذه هي الكلمة الأساسية: الموارد ).

كانت الإجابة بسيطة: ضع JavaScript على الخادم.

ولدت JavaScript بالفعل مع JavaScript Server Side في Netscape Enterprise Server ، ولكن اللغة ببساطة لم تكن جاهزة في ذلك الوقت. بعد سنوات من التجربة والخطأ ، ظهر Node.js أخيرًا والذي لم يضع JavaScript على الخادم فحسب ، بل روج أيضًا لفكرة البرمجة غير المحظورة ، وتغيير الطريقة التي نكتب بها "fread" (I / O) إلى الأبد (اقرأ هنا للمزيد من).

لكن هذه الأفكار لم تكن جديدة - فلماذا أصبحت ذائعة الصيت مع Node.js؟ يمكن تحقيق البرمجة البسيطة غير المحظورة بعدة طرق. ربما يكون الأسهل هو استخدام عمليات الاسترجاعات وحلقة الحدث. في معظم اللغات ، هذه ليست مهمة سهلة: في حين أن "الاسترجاعات" ميزة شائعة في بعض اللغات الأخرى ، فإن حلقة الحدث ليست كذلك ، وغالبًا ما تجد نفسك تتصارع مع مكتبات خارجية (على سبيل المثال: Python ، مع Tornado). ولكن في JavaScript ، يتم تضمين عمليات الاسترجاعات في اللغة ، كما هو الحال في حلقة الحدث ، وتقريبًا كل مبرمج شارك في JavaScript على دراية بها (أو استخدمها على الأقل ، حتى لو لم يفهم تمامًا ماهية الحدث الحلقة). فجأة ، يمكن لكل شركة ناشئة على الأرض إعادة استخدام المطورين (أي الموارد) على جانب العميل والخادم ، مما يحل مشكلة نشر الوظيفة "Python Guru Needed".

إذن لدينا الآن نظام أساسي سريع للغاية (بفضل البرمجة غير المحظورة) مع لغة برمجة سهلة الاستخدام بشكل لا يصدق (بفضل JavaScript). لكن هل هذا كاف؟ هل ستستمر؟ أنا متأكد من أن JavaScript سيكون لها مكانة مهمة في المستقبل. دعني أخبرك لماذا:

• البرمجة الوظيفية

  كانت JavaScript هي أول لغة برمجة تجلب النموذج الوظيفي إلى الجماهير (بالطبع ، جاءت Lisp أولاً ، لكن معظم المبرمجين لم يبنوا أبدًا تطبيقًا جاهزًا للإنتاج باستخدام Lisp). Lisp and Self ، التأثيرات الرئيسية لجافا سكريبت ، مليئة بالأفكار المبتكرة. يمكن لهذه الأفكار أن تحرر عقولنا لاستكشاف تقنيات وأنماط ونماذج جديدة. وجميعهم ينتقلون إلى JavaScript. ألقِ نظرة على monads أو أرقام الكنيسة أو حتى (للحصول على مثال عملي أكثر) وظائف مجموعات Underscore.js ، والتي يمكن أن توفر لك سطورًا وسطورًا من التعليمات البرمجية.

• الكائنات الديناميكية والوراثة النموذجية

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

• جافا سكريبت هي الإنترنت

  تم تصميم JavaScript للإنترنت ، وهي موجودة منذ البداية ، ولن تختفي. لقد فشلت جميع محاولات تدميرها: انظر ، على سبيل المثال ، سقوط تطبيقات Java الصغيرة ، واستبدال VBScript بـ Microsoft TypeScript (الذي يتم تجميعه إلى JavaScript) ، وزوال Flash على أيدي سوق الأجهزة المحمولة و HTML5. من المستحيل استبدال Javascript دون كسر ملايين صفحات الويب ، لذلك يجب أن تكون أهدافنا في المضي قدمًا هي تحسينها. وليس هناك من هو أفضل من اللجنة الفنية 39 من ECMA.

  حسنًا ، تظهر بدائل JavaScript يوميًا ، مثل CoffeeScript و TypeScript وملايين اللغات التي يتم تجميعها في JavaScript. قد تكون هذه البدائل مفيدة لمراحل التطوير (عبر خرائط المصدر) ، لكنها ستفشل في استبدال JavaScript على المدى الطويل لسببين: لن تكون مجتمعاتهم أكبر من أي وقت مضى ، وسيتم اعتماد أفضل ميزاتها بواسطة برنامج ECMA النصي (على سبيل المثال ، JavaScript ). جافا سكريبت ليست كلغة تجميع: إنها لغة برمجة عالية المستوى مع شفرة مصدر يمكنك فهمها - لذا يجب أن تفهمها.

جافا سكريبت من طرف إلى طرف: Node.js و MongoDB

إذن ، هذه هي أسباب استخدام JavaScript. الآن ، سأستخدم JavaScript كسبب لاستخدام Node.js و MongoDB.

• Node.js

  Node.js عبارة عن نظام أساسي لإنشاء تطبيقات شبكة سريعة وقابلة للتطوير - وهذا إلى حد كبير ما يقوله موقع Node.js. لكن Node.js أكثر من ذلك: إنها بيئة وقت التشغيل المفضلة لأي تطبيق JavaScript مع إمكانية الوصول إلى الإدخال / الإخراج. حتى إذا كنت لا تخطط لكتابة تطبيق الخادم الرئيسي الخاص بك باستخدام Node.js ، يمكنك استخدام الأدوات المبنية أعلى Node.js لتحسين عملية التطوير الخاصة بك. على سبيل المثال: Mocha.js لاختبار الوحدة ، Grunt.js لمهام الإنشاء الآلية ، أو حتى بين قوسين لتحرير النص الكامل للكود.

  لذلك ، إذا كنت ستكتب تطبيقات JavaScript للخادم أو العميل ، فيجب عليك إلقاء نظرة على بعض أمثلة Node.js ، لأنك ستحتاج إليها واستخدامها بشكل يومي. هناك بعض البدائل المثيرة للاهتمام ، ولكن لا يوجد أي منها حتى 10٪ من مجتمع Node.js.

• MongoDB

  MongoDB هي قاعدة بيانات قائمة على مستندات NoSQL تستخدم JavaScript كلغة استعلام ، مما يسمح لي بإكمال منصة JavaScript من طرف إلى طرف. لكن هذا ليس السبب الرئيسي لاختيار قاعدة البيانات هذه.

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

مكونات الخادم مع Express.js

المكونات من جانب الخادم ليست سهلة أبدًا. ولكن مع Express.js (و Connect.js) جاءت فكرة "البرامج الوسيطة". في رأيي ، الوسيطة هي أفضل طريقة لتعريف المكونات على الخادم. إذا كنت تريد مقارنته بنمط معروف ، فهو قريب جدًا من الأنابيب والمرشحات.

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

نشير إلى هذه "أجزاء من خط الأنابيب" على أنها "برمجيات وسيطة". من الواضح أنه يمكننا إنشاء نوعين من البرامج الوسيطة:

• الوسطاء : أولئك الذين يعالجون الطلب والاستجابة ، لكنهم ليسوا مسؤولين بالكامل عن الاستجابة نفسها ، لذا فهم يفوضون البرنامج الوسيط التالي.

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

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

تطبيقات الصفحة الواحدة

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

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

العميل MV * مع Backbone.js و Marionette.js و Twitter Bootstrap

لقد قيل الكثير عن أطر MVC * لـ SPAs. إنه خيار صعب ، لكنني أقول إن المراكز الثلاثة الأولى هي Backbone.js و Ember.js و Angular.js.

الثلاثة جميعهم يحظون بتقدير جيد للغاية. ولكن أيهما أفضل بالنسبة لك؟

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

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

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

في حالة Init ، أردت تغطية معظم السيناريوهات ، لذلك اخترت Backbone.js لإنشاء SPA سهل ، باستخدام Backbone.Marionette.View للتكوين. بهذه الطريقة ، يكون كل مكون تطبيقًا بسيطًا ، ويمكن أن يكون التطبيق النهائي معقدًا بالقدر الذي نريده أن يكون.

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

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

أفضل الممارسات: Grunt.js و Mocha.js و Chai.js و RequireJS و CoverJS

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

• Mocha.js و Chai.js :

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

  هناك الآلاف من أطر عمل اختبار الوحدات لجافا سكريبت. فلماذا تستخدم Mocha.js؟ الجواب المختصر: إنه مرن وكامل.

  الإجابة الطويلة: لها ميزتان مهمتان (واجهات ، مراسلين) وغياب واحد مهم (تأكيدات). دعني أوضح.

  • الواجهات : ربما تكون معتادًا على مفاهيم TDD للأجنحة واختبارات الوحدة ، أو ربما تفضل أفكار BDD لمواصفات السلوك مع "وصف" و "ينبغي". يتيح لك Mocha.js استخدام كلا الأسلوبين.

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

  • عدم وجود مكتبة تأكيد : بعيدًا عن كونه مشكلة ، تم تصميم Mocha.js للسماح لك باستخدام مكتبة التأكيد التي تختارها ، مما يمنحك المزيد من المرونة. هناك الكثير من الخيارات ، ولكن هنا يأتي دور Chai.js.

  Chai.js هي مكتبة تأكيدات مرنة تتيح لك استخدام أي من أنماط التأكيد الثلاثة الرئيسية:

  • التأكيد : أسلوب التأكيد الكلاسيكي من المدرسة القديمة TDD. على سبيل المثال:

     assert.equal(variable, ”value”);

  • توقع : أسلوب التأكيد القابل للتسلسل ، الأكثر استخدامًا في BDD. على سبيل المثال:

     expect(variable).to.equal(“value”);

  • يجب : يُستخدم أيضًا في BDD ، لكنني أفضل توقع لأنه يجب أن يبدو متكررًا مع مواصفات السلوك "هو (" يجب أن يفعل شيئًا .. ")". على سبيل المثال:

     variable.should.equal(“value”);

  يتحد Chai.js بشكل مثالي مع Mocha.js. باستخدام هاتين المكتبتين فقط ، يمكنك كتابة اختباراتك في TDD أو BDD أو أي نمط يمكن تخيله.

• Grunt.js :

  يسمح لك Grunt.js بأتمتة مهام الإنشاء ، أي شيء بدءًا من لصق النسخ البسيط وتسلسل الملفات ، إلى التجميع المسبق للقالب ، وتجميع لغة النمط (على سبيل المثال ، SASS و LESS) ، واختبار الوحدة (باستخدام mocha.js) ، والتفحص و تصغير الكود (على سبيل المثال ، مع UglifyJS أو Closure Compiler). يمكنك إضافة مهمتك الآلية الخاصة إلى Grunt ، أو البحث في سجل Grunt ، حيث يوجد المئات والمئات من المكونات الإضافية المتاحة (مرة أخرى ، باستخدام الأدوات مع المجتمعات الرائعة التي تقف وراءها يؤتي ثماره). يمكن لـ Grunt أيضًا مراقبة ملفاتك وتشغيل الإجراءات عند تعديلها.

• يتطلب JS :

  قد تبدو RequireJS مجرد طريقة أخرى لتحميل الوحدات باستخدام AMD ، لكن يمكنني التأكد من أنها أكثر من ذلك بكثير. لفهم السبب ، نحتاج أولاً إلى ذكر فكرة تباعد أسماء الوحدات (على سبيل المثال ، demo.views.hello) ، والتي تتجنب تلويث مساحة الاسم العالمية من خلال لف كل وحدة في مساحة الاسم الخاصة بها. تكمن المشكلة في أن هذه الوحدات غير قابلة لإعادة الاستخدام: إذا قمت بتعديل مساحة الاسم لـ "مثيل" واحد ، فأنت تقوم بتعديل مساحة الاسم لجميع "المثيلات". على عكس ذلك ، يتيح لك RequireJS تحديد الوحدات القابلة لإعادة الاستخدام منذ البداية. (بالإضافة إلى ذلك ، ستساعدك على تبني حقن التبعية لتجنب وصول وحداتك إلى المتغيرات العالمية.)

• CoverJS :

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

استخدام الفروع لتبديل الميزات

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

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

في الوقت الحالي ، لا يمكن استخدام فكرة الدمج هذه لإضافة وظائف إلا لقوالب التكنولوجيا (مثل Backbone و Node و Express). ولكن في المستقبل ، ستتمكن من التبديل بين تطبيقات العميل (على سبيل المثال ، من MongoDB إلى Postgres).

ابدأ مشروعًا باستخدام Init وانشر في Heroku اليوم

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

1. أنشئ دليلًا لمشروعك (أو استخدم دليلًا موجودًا).
2. أنشئ مستودعك باستخدام "git init" (أو استخدم المستودع الحالي).

3. إضافة جهاز تحكم عن بعد مع الحرف الأول

    git remote add init git://github.com/picanteverde/init.git

4. احصل على الفرع الذي تريده

    git pull init usermanager

5. احصل على ملف عملية Heroku

    git pull init heroku-webprocess

6. مع تثبيت Heroku Toolbelt ، قم بإنشاء تطبيق Heroku

    heroku create

7. ادفع فرعك الرئيسي إلى Heroku

    git push heroku master

8. قم بزيارة تطبيقك ، وقم بتشغيله على Heroku!

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

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