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

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

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

سنشرح في بداية هذا الفيديو عن منصة Heroku وكيفية إنشاء حساب عليها ثم سننتقل إلى طريقة نشر التطبيقات باستخدام عميل سطر الأوامر Heroku CLI أو باستخدام مستودع GitHub ونعطي مثالًا عمليًا لنشر تطبيق React.js على Heroku. المواضيع التي يغطيها هذا الفيديو بالتفصيل هي: ما هي منصة Heroku إنشاء حساب على منصة Heroku تثبيت عميل سطر الأوامر Heroku CLI إنشاء مشروع جديد على منصة Heroku استخدام مستودع GitHub لنشر التطبيق استخدام Heroku CLI لنشر التطبيق إضافة ملفات حاوية Procfile إن أردت تعلم كيفية بناء تطبيقات React.js كاملة، فننصحك بالإطلاع على دورة تطوير التطبيقات باستخدام لغة JavaScript.

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

مقدمة إنّ azk عبارة عن أداة خفيفة مفتوحة المصدر، تستطيع استخدامها لتنسيق بيئات التطبيقات. هل سبق أن كان لديك تطبيق يعمل على محطة العمل المحليّة الخاصة بك، ووجدت أنّ الإعدادات تختلف كليًا عندما تقوم بنشر التطبيق على مخدّم إنّتاج. تُقدّم هذه المقالة أداة تنسيق، تُدعى azk، والتي يتم استخدامها حاليًا من قبل هذه التطبيقات، وهي قابلة للاستخدام لأكثر من ذلك بكثير. عندما تقوم بنشر تطبيق جاهز للعمل مع azk، فإنّه يمكنك بسهولة إنّ تشغلّه محليًا أو في مخدّم إنّتاج. لا يجعل azk تشغيل التطبيق فقط سهلًا و سريعًا بل كل تبعياته أيضًا، بما فيها نظام التشغيل المطلوب، اللغات، أطر العمل، قواعد البيانات و التبعيات الأخرى (المهام الثقيلة، الطويلة، التكرارية، الأكثر عرضة للخطأ)، سواء كنت تعمل في بيئة محلية أو على مخدم. إنّ غرض هذه المقالة، هو إظهار كيف يعمل azk كأداة تنسيق، باستخدام تطبيق Rails بسيط يُدعى Stringer كمثال. يهتم azk بالعديد من التفاصيل خلف الكواليس، لجعل عملية التنسيق أسهل. لهذا، تحوي هذه المقالة على العديد من الخطوات الاختيارية، التي ليست بضرورية لإعداد التطبيق المثال، ولكنها تشرح آلية عمل azk. سوف نقوم بتشغيل التطبيق من شفرة المصدر على جهاز حاسوب محلي، ثم نشره على مخدّم، و من ثم سنقوم ببعض التغييرات المحليّة، وبعدها نقوم بنشر هذه التغييرات، و من ثم سنقوم بعميلة الإرجاع. بعد إتمام هذه المقالة، سوق تحصل على فكرة جيدة حول كيفية عمل azk كأداة تنسيق سير عملية التطوير والنشر الخاصة بك. كيف يعمل؟ بدايةً، يُنسق azk بيئة التطبيق على جهاز الحاسب المحلي الخاص بك. حالما يعمل التطبيق لديك محليًا، سيقوم azk أيضًا بتنسيق نشره إلى المخدّم Droplet الخاص بك. طالما يُشغل azk التطبيقات من شفرة المصدر، فإنّك تستطيع أن تعمل مع التطبيق محليًا (إذا كنت ترغب بذلك)، و من ثم تقوم بنشره أو استرجاعه مرة ثانية بدون أيّة خطوات إضافية خاصة. يعزل azk البيئات التي تستخدم الحاويات، ولهذا فمن الآمن تشغيل التطبيقات على جهاز الحاسب المحلي الخاص بك. يعمل azk مع كل من المشاريع الجديدة، تلك التي تبدأ منذ الصفر، أو مع الشيفرات الموجودة سابقًا. استخدام azk مع تطبيقات مخصّصة باستخدام القائمة الحالية من التطبيقات التي تم تشكيلها مسبقًا للعمل مع azk كأمثلة، و مع قليل من العمل الإضافي ستستطيع إعداد أي مشروع للعمل مع azk. للقيام بهذا أضف الملف Azkfile إلى مشروعك. Azkfile عبارة عن ملف رئيسي manifest، يحتوي العناصر الضرورية لتشغيل التطبيق، و يقوم بتلخيص علاقاتها فيما بينها (نظام التشغيل، اللغات، قواعد البيانات، … ). فوائد إضافة الملف Azkfile إلى مشروعك: استخدام azk لأتمته إعداد البيئة لمشروعك محليًا و عند النشر. يستطيع الأشخاص الأخرين، الذين يرغبون بنشر تطبيقك، القيام بهذا باستخدام azk. المتطلبات الأساسية للمتابعة مع هذه المقالة، فإنّك ستحتاج إلى جهاز حاسوب يقوم بتشغيل أية من أنظمة التشغيل التالية(64 - بت) للبيئة المحليّة الخاصة بك: Mac OS X 10.6 (Snow Leopard) أو أي إصدار لاحق. Ubuntu 12.04، 14.04 or 15.10 Fedora 21 or 22 أيضاً ستحتاج إلى إنّ تكون قادر على تشكيل git commits. يحتاج جهاز حاسوبك إلى تثبيت Git. إنّظر إلى هذه السلسلة لاستخدام Git من أجل التعليمات الخاصة لأنظمة التشغيل Linux، أو قم بزيارة صفحة تحميل Git. تأكّد من قيامك بتشغيل الأوامر المقترحة : git config --global user.email "you@example.com" git config --global user.name "Your Name" وذلك قبل القيام بقراءة المقالة، انظر الروابط السابقة للحصول على التفاصيل حول Git. لاحظ أنّه لا يوجد ضرورة للحصول على مخدّم فعّال Droplet في هذا الدرس. سيقوم azk بتشكيل واحد باستخدام واجهة التطبيق DigitalOcean’s API. يُكلف نشر مخدم Droplet المال، ومن أجل هذا الدرس ستقوم بنشر مخدم Droplet، يحوي افتراضيًا فقط واحد جيجابايت. مستخدمي Linux : تثبيت الـ Docker: إذا كنت تستخدم نظام تشغيل ( Linux Ubuntu أو Fedora)، ستحتاج لتثبيت الـ 1.8.1 Docker أو أي اصدار لاحق، وذلك لاستخدامه كبرمجية حاويّة. إنّ تشغيل سكريبت تثبيت Docker، هي إحدى طرق تثبيته. (بشكل عام، كُن متأكد من فهمك ماذا يفعل السكريبت، وذلك قبل القيام بتشغيله): $ wget -nv https://get.docker.com/ -O- -t 2 -T 10 | bash إذا كنت ترغب بتعلّم المزيد حول تثبيت Docker في نظام التشغيل Linux، تفحّص تعليمات التثبيت المتاحة في ملفات التوثيق الرسمية. مستخدمي Mac OS X : تثبيت الـ VirtualBox: ستحتاج إلى VirtualBox 4.3.6 أو أي اصدار لاحق، وذلك لاستخدامه كبرمجيّة حاويّة. لتثبيت VirtualBox، حمّل رزمة تثبيت Virtualbox المناسبة من صفحة التحميل الرسميّة. الخطوة الأولى: تثبيت azk محليًا سنقوم بتثبيت azk، باستخدام سكريبت تثبيت المشروع. تأكد من فهمك ماذا يفعل أي سكريبت، قبل تنفيذه في نظامك. إذا كان لديك للتو نسخة قديمة مثبتة من azk، فإنّك تستطيع استخدام سكريبت التثبيت لتحديث الـ azk. وإلا قُم بتفحص إرشادات تثبيت الحزم لنظم التشغيل المدعومة. تثبيت azk على Linux: إذا كنت تستخدم نظام التشغيل (Linux Ubuntu أوFedora)، قُم بتشغيل هذا الأمر في الوحدة الطرفية، وذلك لتثبيت azk باستخدام سكريبت المشروع. نحن ننصح بتدقيق أي سكريبت قبل تشغيله على نظامك: $ wget -nv http://azk.io/install.sh -O- -t 2 -T 10 | bash بعد إتمام التثبيت، قُم بتسجيل الخروج، ومن ثم تسجيل الدخول مرة أخرى، وذلك لجعل كل التعديلات فعّالة. يتجلى سبب تسجيل الخروج، في أنّه خلال عملية التثبيت، سيتم إضافة مستخدمك إلى مجموعة الـ docker. تُعد هذه الخطوة مطلوبة، وبذلك نستطيع استخدام الـ Docker بدون أن تكون المستخدم الأساسي (root). أي عليك الخروج من الجلسة الحالية، لتحصل على كل التعديلات المضافة. إذا كنت ترغب بتعلم المزيد حول مجموعة الـ Docker، فإنّك تستطيع تفحص التوثيق الرسمي لـ Docker. تثبيت azk على Mac OS X: قُم بتشغيل الأمر التالي في الوحدة الطرفية، وذلك لتثبيت azk باستخدام سكريبت المشروع. نحن ننصح بتدقيق أي سكريبت قبل تشغيله على نظامك: $ curl -sSL http://www.azk.io/install.sh | bash الخطوة الثانية: التحقق من تثبيت azk حالما يصبح تثبيت azk كامل، قُم بتشغيل الأمر الذي في الأسفل، وذلك للتحقق من نجاح عملية التثبيت: $ azk version يتحقق هذا الأمر من نسخة الـ azk المثبّتة. إذا أعاد هذا الأمر رقم النسخة (على سبيل المثال azk 0.17.0 أو أي إصدار لاحق)، فالوضع جيد و تستطيع الانتقال إلى الخطوة التالية. تهانينا لك على تثبيت azk في البيئة المحليّة الخاصة بك. إذا لم يكن الأمر كذلك، فاقرأ أدناه أحد أقسام تحرّي الأخطاء وإصلاحها للحصول على المساعدة. استكشاف الأخطاء وإصلاحها في عملية تثبيت azk في Linux: دعونا نتفحص نسخة الـ Docker المثبّتة، وذلك عن طريق تشغيل الأمر: $ docker version ستحتاج إلى الإصدار 1.8.1 أو أحدث. على كل حال، إذا حصلت على رسالة خطأ، فهذا يعني لم تحصل حتى الآن على تثبيت Docker، تتبع إرشادات التثبيت الخاصة بنظام التشغيل في ملفات توثيق Docker. بعد قيامك من التأكد من حصولك على النسخة المثبّتة المناسبة من Docker، قُم بتشغيل الأمر التالي كمستخدم sudo و ذلك للتأكد من أنّ مستخدمك في مجموعة docker: $ id -Gn إذا كانت قائمة المجموعات تتضمن docker، هذا يعني أنه تم إعداده بشكل صحيح. و إلا، إذا لم تحصل على الكلمة docker في قائمة المجموعات، قُم بتشغيل هذا الأمر لإضافة مستخدمك إلى المجموعة: $ sudo usermod -aG docker $USER ومن ثم قُم بتسجيل الخروج، و تسجل الدخول مرة أخرى. تحقق من الأمر id –Gn مرة أخرى للتأكد من أنّه يُعيد قائمة المجموعات مع كلمة docker بينهم. إذا كانت هذه الإرشادات غير كافية لجعل الـ Docker يعمل بالشكل المناسب (على سبيل المثال، لا تزال غير قادر على تشغيل أمر docker version بشكل صحيح)، يّرجى الرجوع إلى تعليمات تثبيت Docker. استكشاف الأخطاء وإصلاحها في عملية تثبيت azk في Mac OS X: تأكّد من تثبيت VirtualBox $ which VBoxManage إذا كان هذا يُعيد مسار ملف (مثل، usr/local/bin/VboxManage/)، فنستطيع المضي قُدمًا. و إلا، إذا كان يُعيد رسالة " not found "، هذا يعني ليس لديك تثبيت VirtualBox. في هذه الحالة، قُم بتحميل و تثبيت رزمة تثبيت VirtualBox من الموقع الرسمي لهم. الخطوة الثالثة (اختيارية): التعلّم حول التطبيق التجريبي Stringer لقد قُمنا باختيار Stringer كتطبيق تجريبي لهذه المقالة، وذلك لأنه تطبيق بسيط، وتم إعداده للعمل مع azk. وهو عبارة عن تطبيق Rails مع حالة استخدام محددة جيدًا: قارئ RSS أساسي. المزيد حول Stringer تُقدم بعض مواقع الأخبار أيضًا محتواها في صيغة تغذية RSS. هذه عبارة عن صيغة ملف XML قياسية، تُمكن الناشرين من نشر المعطيات بشكل اتوماتيكي. قارئ RSS هو عبارة عن برنامج مُستخدم للاشتراك، وتقديم محتوى الـ RSS. تُزيل عملية الاشتراك في تغذية RSS لموقع ما، حاجة المستخدمين للتفحص اليدوي للموقع للحصول على المحتوى الجديد. حيث يستطيع المستخدمين تشكيل قائمة بالتغذيات المُشترك فيها، وتخصيص محتواهم على قارئ RSS (عادةً على شكل قائمة مرتبة ترتيبًا زمنيًا) الخطوة الرابعة (اختيارية): إعداد تطبيق مُخصّص لاستخدام azk طالما أنّ التركيز الأساسي لهذه المقالة هو على إظهار كيفية عمل azk للتطبيقات، التي تملك للتو تفاصيل البيئة المنصوص عليها للعمل مع azk، فعلى المدى الطويل هذه الأداة، هي أكثر فائدة عندما يمكنك استخدامها لنشر أي تطبيق. لهذا، خُذ نظرة عن كيفية مقارنة هذه النسخة من Stringer مع النسخة الأساسية من Stringer في المستودع. تملك نسخة azk فقط إضافتين اثنتين إلى نسخة Stringer الأصلية: ملف Azkfile، الذي يزّود بمعلومات البيئة لـ azk زر azk لتشغيل المشروع Run Project يمكن تعلم المزيد حول جعل azk يعمل مع تطبيقات أخرى، وذلك عن طريق ملفات توثيق azk حول ملف Azkfile و زر تشغيل المشروع Run Project. تالياً، سوف نرى كيف يبدو التطبيق الصديق لـ azk في GitHub. الخطوة الخامسة (اختيارية): استخدام زر تشغيل المشروع لـ azk على GitHub إنّ جزء الممارسات الأفضل من azk من أجل مشاريع GitHub، هو التوضيح الجيد لكيفيّة عمل هذا المشروع مع azk. لهذا، بدلاً من إظهار فقط أمر الـ azk في وسط ملف readme للمشروع، فإنّ المشروع الذي يستخدم azk يستطيع استخدام زر تشغيل المشروع، وذلك للعزل البصري لأمر الـ azk. يستخدم Stringer هذا الزر. قُم بزيارة قسم التشغيل المحلي لنسخة azk المتشعبة من Stringer. أضغط زر تشغيل المشروع Run Project. في أول مرة تضغط فيها زر تشغيل المشروع، سوف ترى شرح بسيط عن ماذا يجري. عندما تصبح جاهزا للمضي قُدماً، انقر على الزر OK، DISMISS في أسفل الشرح. بعدها سيتم توجيهك إلى صفحة مع أمر azk لمشروع Stringer. $ azk start -o run-project/stringer يمكنك دائماً أنّ تنقر على إشارة ما هذا؟ على الزاوية العليا اليُمنى، وذلك لترى الشرح مرّة أخرى. في مركز الشاشة، يوجد صندوق أوامر مع ثلاث علامات تبويب: curl، wget، azk. طالما لدينا للتو مُثبت azk فتستطيع استخدام علامة التبويب azk. هذا هو الأمر، الذي سنستخدمه في الخطوة التالية للتشغيل الفعلي لـ Stringer. الخطوة السادسة: تشغيل Stringer محليًا في هذا القسم سنستخدم azk لتشغيل Stringer على محطّة العمل المحليّة. دعونا نتأكد أنّنا في المسار الرئيسي home على جهاز حاسوبنا المحلي (إذا قمت باستخدام مجلد تثبيت مختلف، تذكر فقط تغيير الأوامر إلى مسارك المختار): $ cd ~ أمضي قُدمًا، و قم بتشغيل الأمر التالي على حاسوبك المحلي، وذلك لتشغيل Stringer: $ azk start -o run-project/stringer طالما هذه هي أول مره تقوم بها بتشغيل azk، سيطلب منك قبول بنود الخدمة. و يجب أنّ تظهر رسالة كالتالية: ? ========================================================================= Thank you for using azk! Welcome! Before we start، we need to ask: do you accept our Terms of Use? http://docs.azk.io/en/terms-of-use ========================================================================= (Y/n) اضغط على Y إذا كنت موافق أو N إذا كنت غير موافق. و من ثم اضغط على ENTER لتأكيد جوابك. في حالة عدم موافقتك، فلن تتمكن من استخدام azk. و اخيراً، سيقوم azk أوتوماتيكيًا بتحميل الشفرة المصدر لـ Stringer، إضافة إلى أنّ الملف المسند Azkfile سيقوم بتشغيل هذا الشفرة في بيئة معزولة و آمنة في حاسوبك المحلي. ومن ثم سيتم سؤالك فيما إذا كنت ترغب ببداية تشغيل عميل الـ azk. ? The agent is not running، would you like to start it? (Y/n) العميل هو عبارة عن مُركب azk، الذي يقوم بإعداد Docker (على نظام التشغيل Linux )، أو بإعداد الآلة الافتراضيّة VirtualBox (على نظام التشغيل Mac OS X). اضغط ENTER للجواب “Yes” (الخيار الافتراضي). في أول مرة تُشغل فيها العميل، سيقوم azk بتشغيل إعداداته. يقوم الإعداد بالعديد من الأشياء وراء الكواليس، بما في ذلك توليد الملف /etc/resolver/dev.azk.io، الذي يحوي إعدادات نظام أسماء النطاقات DNS، لتصميم العناوين التي تنتهي باللاحقة dev.azk.io. يستخدم azk هذه اللاحقة عند تشغيل التطبيقات لاستخدام العناوين القابلة للقراءة بدلاً من الاستخدام اليدوي للعناوين من الشكل http://localhost:PORT_NUMBER . أيضاً هذا يقوم بتجنب تعارض أرقام المنافذ بين التطبيقات المختلفة. بشكل أساسي يقوم هذا بنفس الشيء عند تحرير ملفك /etc/hosts لإعادة توجيه اسم نطاق محليًا. إذا حصلت على رسالة من الشكل التالي: ? Enter the vm ip: (192.168.50.4) فإنّك تستطيع إدخال أي عنون IP محلي، ترغب بتشغيل التطبيق عليه. يجب أن تكون الحالة الافتراضية مناسبة لجميع الحالات. للموافقة على هذا، فقط اضغط ENTER. لإتمام إعدادات عميل الـ azk، سيتم سؤالك عن كلمة المرور الخاصة بالمستخدم sudo (لمستخدمي نظام التشغيل Mac OS X، هي عبارة عن كلمة مرور المُشرف admin). الآن سيبدأ azk بالعمل. سوف ترى أنّ azk يُحمّل العناصر المُسردة في الملف Azkfile (على صيغة صور Docker ). من الممكن أن يستغرق تحميل هذه الصور أول مرة عدة دقائق (حوالي 10 دقائق أو أقل). حالما يُكمل azk الإعداد، سيقوم مُتصفحك بشكل أتوماتيكي بتحميل شاشة البدء لـ Stringer على حاسوبك المحلي. كما تستطيع إنّ ترى، أنّه يستخدم اسم نطاق محلي DNS، و هذا التطبيق مرئي على http://stringer.dev.azk.io. و تستطيع الوصول إلى التطبيق بشكل يدوي عبر الذهاب إلى http://stringer.dev.azk.io . إذا كنت ترغب بإعداد كلمة المرور و بداية التشغيل باستخدام التطبيق، فإنّك تستطيع فعل ذلك. نحن نرغب فقط برؤية أنّ azk يستطيع تشغيل Stringer محلياً. والآن طالما لديك Stringer يعمل على الحاسوب المحلي، فتستطيع نشره من جهاز الحاسوب لديك إلى المخدّم Droplet. الخطوة السابعة: الحصول على الرمز DigitalOcean API Token قبل أن نتمكن من نشر Droplet من azk، فإنّنا نحتاج إلى رمز API token. يُعطي هذا الرمز الإذن لـ azk لنشر مخدّم جديد على حسابك. في أول مرّة تقوم بها بتشغيل azk من هذه البيئة باستخدام هذا الرمز، سيتم نشر واحد جيجابايت مخدّم جديد Ubuntu 14.04 Droplet . و ستستخدم عمليات النشر اللاحقة من نفس البيئة المحليّة، نفس المخدّم المفرد Droplet. اتّبع الإرشادات من قسم المراجع المرتبطة بالمقالة حول كيفية تشكيل رمز الوصول الشخصي. و يجب أن يمتلك الرمز المُشكّل تصاريح الكتابة القراءة. قُم بنسخ المحارف الأربعة و الستين بالترميز الست عشري لرمزك، بشكل مشابه للتالي: Example API Token A17d6a72566200ad1a8f4e090209fe1841d77d7c85223f769e8c5de47475a726 سوف ترى هذا الرمز النصيّ فقط مرة واحدة، لذلك قُم بنسخه إلى مكان آمن. (تذكّر، إذا تم اختراق هذا الرمز، فإنّه يمكن استخدامه للدخول إلى حسابك، لذلك حافظ عليه خاصًا). من أجل الإرشادات أسفلا، تذكر استبدال الرمز المثال بالرمز الحقيقي الخاص بك. اذهب إلى مجلد Stringer: $ cd ~/stringer احفظ رمز الوصول الشخصي في ملف ستدعوه env. للقيام بهذا، قُم بتشغيل أمر تشكيل ملف (لا تنسى استبدال الرمز): $ echo "DEPLOY_API_TOKEN=a17d6a72566200ad1a8f4e090209fe1841d77d7c85223f769e8c5de47475a726" >> .env يجب إنّ يبدو محتوى الملف env. بالشكل التالي: DEPLOY_API_TOKEN=a17d6a72566200ad1a8f4e090209fe1841d77d7c85223f769e8c5de47475a726 الخطوة الثامنة (اختيارية): التعلم حول مفاتيح SSH ليس عليك إنّ تقوم بأي شيء لإعداد مفتاح SSH من أجل azk، ولكن من المفيد معرفة الكيفية التي يستخدم فيها azk هذا المفتاح. يستخدم azk مفتاح SSH للوصول إلى المخدّم Droplet. إذا كان لديك للتو مفتاح SSH، فإنّ azk سيستخدمه. لرؤية فيما إذا كان لديك مفتاح SSH على جهاز الحاسوب لديك، شغّل: $ ls ~/.ssh/*.pub إذا قام بإرجاع رسالة “not found”، فهذا يعني إنّه ليس لديك أيّة مفاتيح SSH على جهاز الحاسوب. في هذه الحالة، سيولّد azk بشكل أتوماتيكي مفتاح SSH جديد، ليتم استخدامه حصريًا لنشر أي تطبيق جديد من جهاز الحاسوب لديك. سيقوم azk بتوليد مفتاحه في الذاكرة المحجوزة له، ولن يقوم بأيّة تعديلات على مسارك ~/.ssh. إذا كنت ترغب بتفحص المفتاح العام المولّد، يمكنك تشغيل الأمر التالي بعد نشر التطبيق الأول: $ azk deploy shell -c "cat /azk/deploy/.config/ssh/*.pub" الخطوة التاسعة: النشر مع azk بشكل افتراضي، سيولد azk مخدّم DigitalOcean Droplet واحد جيجابايت، يُشغّل النظام Ubuntu 14.04، وذلك من أجل نشر تطبيقك. إذا كنت ترغب بنشر Droplet بمواصفات مختلفة، فيمكنك تغيير الإعدادات في خصائص envs لنظام deploy في الملف Azkfile.js . من أجل الإرشادات الإضافية أشر إلى ملفات توثيق حول نشر azk . أولاً، اذهب إلى مسار Stringer ( أو إلى مسار تطبيقك): $ cd ~/stringer ومن ثم، ابدأ عملية النشر، فقط قُم بتشغيل: $ azk deploy إنّ الأمر azk deploy، هو الأمر الذي ستقوم بتشغيله معظم الأوقات، عندما تستخدم azk لتنسيق تطبيقك. من الممكن أن تستغرق أول عملية نشر فترة معينة (حوالي عشر دقائق)، حتى يقوم azk بكل العمل. بشكل مخصص، على azk القيام بما يلي: تحميل عناصر الدعم ( صورة Docker للنشر) تشكيل و إعداد الـ Droplet رفع شفرة المصدر للتطبيق إلى المخدّم Droplet تشغيل التطبيق بعدها ستستغرق كل عملية نشر جديده لهذا التطبيق من جهاز الحاسوب لديك مدة زمنية قليلة (حوالي 30 ثانية أو أقل)، هذا لان معظم الخطوات الطويلة جاهزة للتو. إذا كان مفتاحك SSH محمي بكلمة مرور، فسيكون مطلوباً وقت أكبر لعملية النشر. فقط قُم بكتابة كلمة المرور للمفتاح SSH، و أضغط زر ENTER في كل مرة تظهر رسالة كالتالية: Output Enter passphrase for ~/.ssh/id_rsa: سيظهر خرج الوحدة الطرفية بعض الإجراءات المُتخذة على النظام البعيد، تنتهي برسالة النشر الناجحة App successfully deployed at http://your_server_ip. قُم بزيارة الموقع http://your_server_ip لعرض التطبيق المُستضاف على الخادم الخاص بك. من الآن، يُمكنك تغيير شفرة التطبيق على جهاز الحاسوب الخاص بك، و يمكنك اختباره محلياً، و يمكنك نشر التغييرات على المخدّم Droplet بواسطة الأمر azk deploy. الخطوة العاشرة: تعديل Stringer لتوضيح سهولة استخدام azk لنشر تطبيق، للتخصيص، أو للتحكم في النسخة، دعونا نقوم بعدد من التغييرات على صفحة الاشتراك Stringer، و من ثم نقوم بإعادة نشر التطبيق. تأكد من كونك على مسار Stringer: $ cd ~/stringer دعونا نقوم بتعديل الملف app/views/first_run/password.erb، الذي هو عبارة عن الصفحة الحاوية على النص لصفحة الاشتراك الأولى. استخدم nano أو محرر النصوص المفضل لديك: $ nano ~/stringer/app/views/first_run/password.erb هنا نقوم بإضافة السطر الإضافي، الذي يقول "! It’s easy with azk ": app/views/first_run/password.erb <div class="setup" id="password-setup"> <h1><%= t('first_run.password.title') %> <span class="orange"> <%= t('first_run.password.anti_social') %></span>.</h1> <h2><%= t('first_run.password.subtitle') %></h2> <h2>It's easy with azk!</h2> <hr /> . . . </div> قُم بالحفظ و الخروج من محرر النصوص. إذا كنت تستخدم nano، اضغط CTRL+O للحفظ، و CTRL+X للخروج. طالما إنّ Stringer مُعد افتراضياً للعمل في وضع الانتاج، لذلك فإنّ إعادة تحديث صفحة المتصفح ليس بكافٍ لتشغيل التغييرات. بل قُم بإعادة تشغيل التطبيق من azk: $ azk restart stringer -o يجب على علامة التبويب الجديدة للمتصفح أن تفتح النسخة الجديدة من Stringer. أسفل النص الافتراضي مباشرةً “There is only one user: you”، يجب الآن أن يكتب “!It’s easy with azk”. الخطوة الحادية عشر: إعادة نشر Stringer الآن، دعونا نُودع (commit) التغييرات داخل نسخة نظام التحكم، من أجل أن نستطيع نشرها. $ git add app/views/first_run/password.erb $ git commit . سيظهر لك محرر نصوص (على الأرجح nano أو vim). أدخل رسالة إيداع commit، مثل It is easy with azk. سيتم استخدام هذه الرسالة commit لتسمية الإصدارات من تطبيقك داخل azk، لذلك اختر الرسالة التي من شأنها تحفيز ذاكرتك، إذا كنت بحاجة إلى الرجوع إليها في وقت لاحق. احفظ و أغلق رسالة الـ commit. إذا حصلت على الخطأ : fatal: empty ident name (for <sammy@azk.(none)>) not allowed عندها قُم بتشغيل أوامر الإعدادات المقترحة من أجل Git لإعداد عنوان إيميل و اسم (المزيد من التفاصيل في قسم المتطلبات الأساسية). لنشر تغييراتك و رفع تشغيل التطبيق على Droplet، قُم بتشغيل: $ azk deploy بعد الانتهاء من ذلك، قُم بالوصول إلى عنوان IP لـ Droplet من متصفحك (مثلاً http://your_server_ip) .عندها يجب أن ترى أيضاً هنا السطر الجديد !It’s easy with azk سيقوم هذا النشر الجديد بتشكيل نسخة جديدة من التطبيق على Droplet. إنّ كل نسخ التطبيق مخزنة، لذلك يمكنك العودة إلى نسخة سابقة ومن ثم إلى الأمام مرّة أخرى. الخطوة الثانية عشر: الرجوع إلى خطوة سابقة للحصول على كل النسخ المتاحة من تطبيقنا على Droplet، شغّل الأمر التالي محليًا: $ azk deploy versions يجب إنّ تكون النتيجة بقائمة من الشكل: Output ⇲ Retrieving deployed versions... ➜ v2 It is easy with azk v1 Merge branch 'master' of https://github.com/swanson/stringer لإرجاع التطبيق إلى نسخة أقدم، فقط قوم بتشغيل: $ azk deploy rollback v1 إنّ المعامل v1 عبارة عن رقم النسخة، الذي يظهر على خرج الأمر azk deploy versions. إذا قمت بتشغيل الأمر بدون هذا المعامل (مثلاً، . azk deploy rollback )، سيرجع عندها التطبيق إلى نسخة سابقة تماماً قبل النسخة الحالية. لتفحص إتمام عملية الرجوع، فقط قُم بتحديث علامة تبويب المتصفح، التي تظهر نسخة المخدم. الآن عليك إنّ ترى التطبيق بدون النص الذي قمنا بإدخاله، أي يجب أن ترى النسخة الأصليّة من التطبيق. وإذا كنت ترغب بالرجوع للأمام، يمكنك اختيار النسخة الأحدث: $ azk deploy rollback v2 أتت التسمية لهذه النسخ من رسائل الـ git commit في الخطوة السابقة. الخاتمة في هذا الدليل التعليمي، لقد استخدمنا تطبيق Rails بسيط، لتوضيح كيف يقوم azk بأتمتة مهام إعداد بيئة تطبيقنا. يجعل هذا من السهل نشر التطبيق نفسه في عدة بيئات. إذا أعجبت بعملية النشر من azk، خُذ بعين الاعتبار استخدامه لمشروعك الخاص، أو إضافة الملف Azkfile إلى fork مشروع أخر مفتوح المصدر. يدعم azk بالإضافة إلى عملية rollback و versions، غيرها من الأوامر الفرعيّة المساعدة، التي تسمح لنا بإنّجاز بعض الإجرائيات الإضافية (مثلاً، الوصول إلى Droplet’s shell عن طريق المفتاح SSH ). ترجمة -وبتصرّف- للمقال How To Deploy a Rails App with azk لصاحبه Felipe Arenales

يوجد الكثير من المقالات التي تتحدث عن السّير الذاتية، وللتّميّز قليلًا عن تلك المقالات سأحاول أن أعطيك بعض النصائح العمليّة حول كيفية جعل السيرة الذاتية تبدو أكثر جاذبية، وكيف تضع نفسك في مرتبة النجم بدلًا من مرتبة "المبرمج الجيّد". قد تأخذ العملية عدة سنوات حتى تتمكن من زيادة زَخم سيرتك الذاتية، ولكن عندما تنتهي، ستصبح قادرًا على المطالبة بـ 100$ إضافيّة في السّاعة لقاء عملك دون أن تواجه أي تردّد من عملائك في دفع ذلك المبلغ. صفحة واحدة سيرة ذاتية واحدة فقط كان ينطبق عليها هذا الوصف من كلّ عشرة سير ذاتيّة كانت تصلني كلّ يوم، بينما كانت البقيّة تستهلك ثلاث صفحات أو أكثر، ما يجعلها تبدو أقلّ احترافيّة بكثير، فإن لم تستطع وصف نفسك في صفحة واحدة ستتولد الشكوك حول مهاراتك، وهذا أمرٌ يجب ألا يحصل لمهندسي البرمجيات software engineer خصوصًا، حيث يجعلك تبدو غير قادر على تحييد الأمور غير الهامّة والتركيز على ما يهم حقًّا، وإنّه لَمِنَ المملّ قراءة ثلاث صفحات حول نفس المُبرمج. لذا، حاول جاهدًا دون استثناءات الالتزام بهذه القاعدة، فسيرتك الذاتيّة كالملخّص التنفيذي لمنتج تحاول تسويقه، أو مُلصق دعائي، يجب أن تكون قصيرة ومباشرة، فإمّا أن يقوم أصحاب العمل بشراء المنتج أو رميه بعيدًا، فهم لا يرغبون بقراءة سيرة ذاتية; إنّهم يرغبون باتخاذ قرار حول شراء مهاراتك أو تجاهلها، وكلّما زاد عدد الصفحات قلّت معها فرصتك. لا تكذب مهما فعلت بسيرتك الذاتيّة فلا تكذب أبدًا حول أيّ كلمة فيها. تستطيع أن تخفي نصف الحقيقة أو أن تعيد صياغتها كيفما شئت، تستطيع أن تكتم معلومات عن نفسك، لكن لا تكذب أبدًا، فأنت لا تعلم من سيقرأها وفي أيّ مكتب سينتهي بها الحال. كن مستعدًّا لتوضيح كلّ كلمة ذكرتها فيها. لو قُلتَ مثلًا: أنا "خبير JavaScript"، فكن جاهزًا لشرح أهمّ الميّزات الجديدة في الإصدار 6 من ECMAScript. إن لم تستطع، فلا تستخدم كلمة "خبير". الفكرة تكمن في أن تكون جاهزًا لإثبات كلّ كلمة عند الحاجة. صورة جذابة لك في أعلى الصفحة إن رغبت بالعمل معهم فسيرغبون بمعرفة من قد يعملون معه، لذا فصورتك الشخصيّة هي عنصر أساسي من السيرة الذاتيّة، فحاول أن تجعلها تبدو احترافيّة حتى لو اضطررت للدفع مقابلها. ركّز جيّدًا على جودة صورتك فهي عنصر هامّ جدًا. لا حاجة للتّذكير بذلك، لكنه يجب عليك أن تظهر مبتسمًا في هذه الصّورة، ولتكن الصّورة عفويّة فلا داع للتكلّف وارتداء بذلة رسميّة، يكفيك مثلًا قميص مع خلفية مرحة. يجب أن تظهر سعيدًا ومرتاحًا، فليس بالضرورة أن تجاهد لجعلهم يقبلون توظيفك، عليك أن تجعلهم يشعرون بالرّغبة في توظيفك من تلقاء أنفسهم، هذه هي الرسالة التي ستحاول إرسالها لهم من خلال صورتك، تمامًا كما في مواقع التعارف الاجتماعية. لا حاجة لكل من "الهدف Objective" و "اللقب Title" "كبير مطوّر برمجيات"، "مبرمج جافا محنّك"، "اختصاصي تكنولوجيا معلومات موهوب" ... إلخ، إن هذه الألقاب مملّة ولا تسوقّك جيّدًا فهم يعلمون من أنت من خلال قراءتهم لسيرتك الذاتية. إلى جانب هذا، فإنّك تحدّ من نفسك ضمن إطار هذا اللقب، فقد يرغبون بإيجاد نائب مدير القسم الهندسي بينما تقول سيرتك "مهندس برمجيّات". إنّ عدم التطابق الواضح هذا سينقص من فرصك بالعمل لديهم. اسمك هو ما يجب أن يكون العنوان في السيرة الذاتيّة. باقة كبيرة من المهارات يبيّن هذا القسم لأصحاب الوظيفة أين يقع "ثِقَلك التقنيّ"، ويجب أن يحوي على لائحة قصيرة جدًّا من المهارات لا تتجاوز 12 بندًا. فمن غير الممكن أن تكون خبيرًا في MySQL ،PostgreSQL ،Oracle ،MS SQL في الوقت ذاته; وقد تظن لبرهة أن وجود الكثير من المهارات يُعطي الانطباع بأنّك خبير، بينما في الواقع يُفهم من ذلك بأنّك لا تُتقن أيّ شيء، وهو أمرٌ عليك تجنّبه. ولكن كيف تنتقِ المهارات التي ستذكرها؟ عليك بدون مبالغة إيجاد أفضل ما تَبرَع فيه من مهارات وتضعه في ذلك القسم، تأكّد من أنّ المهارات المذكورة على ذات المستوى في التصنيف، فعلى سبيل المثال Java و AngularJS لا يجب أن يوضعا بجانب بعضهما البعض، فـ Java على مستوى أعلى من AngularJS، وبالتالي قد تكتب "Java و SQL و HTTP" أو "AngularJS و Spring Framework و Web Sockets". نصيحتي هي ألّا تصف مهاراتك وصفًا شموليًّا قبل أن تصبح رمزًا معروفًا، فـ Java تبدو مناسبة كمهارة في السيرة الذاتية لـ Jon Skeet، لأنّه بدون شكّ يعرف كلّ شيء عن عالم Java، ومشهودٌ له بذلك. أما لو كان لديك خبرة 3 سنوات فكيف لك أن "تتقن Java"؟ ربما تعرف استخدام بضعة مئات من الصفوف فيها فحسب، لهذا السبب فإنّه من الأفضل أن تذكر الأجزاء التي تتقنها في Java تحديدًا. وكما ذكرت سابقًا، كن دقيقًا في وصف مهاراتك قدر ما أمكنك. ملفك الشخصي على StackOverflow.com بغضّ النظر عن كل ما يُقال عنه، فقد أصبح StackOverflow المنصّة الأساسية -بحكم الواقع- التي تطرح فيها الأسئلة والأجوبة التقنيّة، فتواجدك وتقييمك المرتفع هناك سيرسل رسالة واضحة لصاحب عملك -المحتمل- بأنّك نجم (أو نجم صاعد). لن تجد هناك الكثير ممن حصل على 100 ألف نقطة تقييم أو أكثر، فلم لا تصبح أحدهم. وحتّى لو لم تكن تملك حسابًا على StackOverflow بعد، أنشئ واحدًا الآن وأمضِ ساعة واحدة بالإجابة على الأسئلة الجديدة كلّ يوم لعدة أشهر، وستحصل على 1000 نقطة تقييم أو أكثر، إن اعتبرنا أنّك كنت مساهمًا لا متفرّجًا فقط. هذا كاف في البداية، ولا تنس أن تضع رابط صفحة حسابك في سيرتك الذاتية. قد لا تكون قادرًا على الإجابة مباشرة، حينها اقرأ إجابات الآخرين، قم بالتعليق عليها، حاول إثراءها، وصحّح ما أمكنك، لتكن عضوًا نشيطًا في المجتمع. ملفك الشخصي على GitHub من يستطيع إنكار أن GitHub قد أصبح المنصّة الأساسية للبرمجياّت مفتوحة المصدر. ولكونك مطوّر برمجيات من العصر الحديث، فيجب أن يكون لديك حساب عليه كي تملك أثرًا واضحًا في عالم البرمجيّات مفتوحة المصدر إن أردت التسويق لنفسك بسعر أعلى. ولكن لماذا قد تهتم بهذا الأمر؟ إن مساهمتك في عالم البرمجيّات مفتوحة المصدر، سيمكّن صاحب عملك المحتمل بأن يرى ما يظنّه السوق في برمجياتك وفيك أنت، ووجودك فيه هو ضمانة له، تزيل خوفه من أن يرتكب خطأً بتوظيفك، فلا بدّ أنّ أحدهم قد شاهد شيفراتك البرمجيّة، وربما حصلت على بعض الثناء على مشاريعك أو قام أحدهم بالتصويت لها. بالنتيجة، ستجعلهم يشعرون بارتياح لاختيارك. لن تحتاج لصرف الكثير من الوقت على المصادر المفتوحة لتكون من "النخبة"، يكفي أن تشارك في تلك البرمجيّات التي تستخدمها أنت، فإن كنت تستخدم Sinatra في عملك، ألق نظرة على شيفرتها المصدريّة وستجد الكثير من الأجزاء التي يمكن إجراء إضافات أو تحسينات عليها. اعرض مساعدتك أو قم ببساطة بإرسال طلبات الجذب pull requests الخاصة بك هنا وهناك. إلى جانب هذا، أضف منتجاتك ومشاريعك الخاصة وسوّق لها، وستذهل لمقدار المستخدمين والمتابعين الذين ستحصل عليهم خلال عدّة سنوات بهذا العمل. الشهادات يعتقد البعض بأنّ الشهادات غير مهمّة، وهذا قد يكون صحيحًا في بعض الحالات، ولكنّ سيرتك الذاتيّة يجب أن تحوي بعضًا منها، فهناك شهادات من اليسير الحصول عليها ببضعة أسابيع من الدراسة وبضع مئات الدولارات، حينها لن تبقى مجرّد مبرمج Java وإنّما مبرمجًا معتمدًا، وليس هناك الكثير منهم. نعم هناك ملايين مبرمجي Java حول العالم ولكنّ نسبة قليلة منهم فقط من يمتلكون شهادة مبرمج معتمد، وبغضّ النظر عمّا إن كنت تعتقد بأهميّة تلك الشهادات أم لا، احصل عليها. تجنّب المواقع التي تدور حول اعتمادياتها شبهات مثل BrainBench وغيره. صحيح بأنك تستطيع أن تحصل على شهادة معتمدة منها ولكن لا تذكرها في سيرتك الذاتيّة فهذا سيثبت فقط بأنّك فخور بإنجازك المشبوه، وهذه إشارة غير جيّدة. أسماء وأرقام حقيقية عليك أن تكون حذرًا مع هذه النّقطة. بداية، عليك أن تبحث في ماضيك عن أسماء مشهورة أو أرقام كبيرة. على سبيل المثال، منذ 10 سنوات كنت أساعد شركة ناشئة في كتابة برمجيّة كانت IBM أحد مستخدميها، وعلى الرغم من أنّ IBM توقّفت عن استخدام هذه البرمجيّة بعد بضعة أشهر ، إلّا أنّها استخدمتها فعلًا، وبالتالي يمكن أن أكتب في سيرتي بأنّي: "كتبت برمجيّة لـ IBM"، فهل أكون كاذبًا؟ لا. وإن سُئلت عمّا قمت به بالضبط لـ IBM، سأكون قادرًا على الشرح. في معظم الحالات لن أُسأَل، ولكنّ فرصتي بأن يتمّ وضع سيرتي الذاتيّة في أعلى الكومة ستصبح أكبر. تستطيع القيام بذات الأمر مع الأرقام، إليك قصة حقيقية أخرى. منذ بضعة سنوات، كنت أساعد شركة في إعداد Continuous Integration Pipeline، ولم يكن الأمر صعبًا، لكنّ الشركة كانت تحصل على 5 ملايين زيارة يوميًّا عبر موقعها. وعلى الرغم من أنّه لم يكن لي علاقة بالحصول على هذا الرقم، لكنّي عملت في الشركة لبضعة أشهر، وبالتالي يمكنني أن أقول في سيرتي: "قمت بإعداد Continuous Integration Pipeline لمتجر إلكتروني ذي 5 ملايين زيارة يوميّة"، وفي حال سؤالي عن التفاصيل سأتمكّن من إعطائها لهم، لأنّي لا أكذب. استخدم هذه التقنية بحذر دون أن تكذب، ولا تخشَ من ذلك، فسيرتك الذاتيّة تحتاج لأسماء وأرقام كبيرة. المدونة أنشئ مدوّنتك الخاصة وابدأ بالكتابة عن إنجازاتك اليوميّة، وعن الشيفرات البرمجيّة التي تكتبها وتقرأها، وعمّا تشاهده في المكتب، وعن أفكارك ومشاريعك، وعن الكتب التي تقرأها. إن أردت أن تتقاضى أجرًا كبيرًا فستحتاج أن تملك مدوّنة قطعًا. وليس بالضرورة أن تكون المدوّنة مشهورة، فلا تعر انتباهًا للأرقام، لكن يجب أن تكون معدّة ومصمّمة بشكل جيّد. لا تستخدم WordPress أو Blogger أو Tumblr. عوضًا عن ذلك وما أفعله شخصيًّا، أنصحك باستخدام خدمات توليد الصفحات الثابتة مثل Jekyll وقم باستضافتها على صفحات GitHub. وإلى جانب كون هذا إضافة قيّمة إلى سيرتك، فإن الكتابة المنتظمة ستساعدك في ترتيب أفكارك، مشاريعك وقراراتك. هذا ما أجنيه شخصيًّا على الأقل من مدوّنتي. التعليم سأكتفي في هذا المجال بأن أذكر مستوى شهادتي، "ماجستير" أو "بكالوريوس" يكفي، وليس هناك حاجة لأذكر متى تخرّجت أو من أي مؤسسة تعليمية، فأستطيع ذكر ذلك لاحقًا عند سؤالي، ولكنّ هناك استثناءان لهذه القاعدة. بداية، إن كنت تملك شهادة دكتوراه فاذكر هذا في سيرتك فهي مهمّة وقيّمة لعدم وجود الكثير من حملتها في وسط المبرمجين. ثانيًا، إن كنت خريج جامعة مشهورة مثل ستانفورد، معهد ماسوستش للتكنولوجيا، أو شبيه ذلك، فاذكرها أيضًا. المؤتمرات يجب عليك أن تُلقي بعض المحاضرات هنا وهناك بشكل متواصل، ولكن حتّى تغدو قادرًا على الوصول إلى المؤتمرات الكبيرة، قم بذلك في أيّ مكان آخر يقبلون بك فيه. فمثلًا تستطيع إنشاء حساب على موقع lanyrd (أو ما شابهه) وتحقق باستمرار أيّ المؤتمرات تبحث عن متحدّثين وقم بإرسال طلبك وستفاجئ بأن بعضهم سيقبلون بعض أفكارك. إن العناوين الأسهل للبدء بها هي الحديث عن خبرتك العملية مع بعض التقنيّات والأدوات الحديثة، كسبيل المثال "كيف يساعدنا Docker في تحسين الإنتاج" أو "خمسة مشاكل لدى تنصيب Apache Spark"، أو أن تصف ما قمت بإنجازه على مشروع عملت عليه مؤخّرًا، فلا يهمّنا حقًّا ما تتحدث عنه. ما يهمّنا هو أن تصبح معروفًا، فإن قبلك السوق، فصاحب العمل سيثق بك أكثر. هذا تمامًا ما تحتاجه لتتمكن من طلب أجرة أعلى. تاريخ مسيرتك المهنية كصاحب شركة، لا يهمني شخصيًّا تاريخك المهنيّ على الإطلاق. على العكس من ذلك، فلو لم تشغل من قبل وظيفة بدوام كامل، ربما أكون مهتمًا بالعمل معك أكثر، لكنّ هذا رأيي فقط، لأنّي أؤمن حقًّا بأنّ المكاتب الحديثة والوظائف بدوام كامل تحوّل المبرمجين إلى عبيد (لا مبرمجين فقط). أما باقي أصحاب الشّركات الأخرى فقد يفكّرون أو غالبًا يفكّرون بطريقة مختلفة، لهذا السبب عليك أن تذكر في أيّ الشركات أمضيت السنوات العشرة الماضية من حياتك، وأنصح بإبقاء هذه القائمة قصيرة، حتى لو عملت في 8 شركات في السنوات العشرة الأخيرة فلا تذكر هذا، 3 تكفي، هذا سيظهر لهم بأنّك عبد جيّد لديك ولاء لسيّدك السابق (لم تغيّر عملك كثيرًا). هذا ما يرغبون برؤيته، لأنهم يخطّطون لشرائك ليكونوا أسيادك الجدد. ACM, IEEE, JUG والعضويات الأخرى إن هذه العضويّات لا تعني شيئًا إطلاقًا إلّا أن تثبت بأنّك عضو في هذه المجتمعات. وكما في معظم ما ذكرناه سابقًا، سيثق بك صاحب العمل أكثر إن كان السوق يثق بك. إنّ هذه العضويّات لا تعني أبدًا أن أحدًا يعترف بك، نظرًا لأنك تحصل عليها بدفع رسوم سنويّة فقط. ولكن، طالما أنّك تدفع هذه الرسوم بخلاف كثيرين، فإنّ هذا يجعلك أكثر وثوقيّة من الآخرين. الهوايات أعتقد بأنّ المعلومات عن الهوايات مهمّة، ويجادل البعض في هذا، لكنّي أعتقد بأن لمسة شخصيّة بينك وبين صاحب العمل المحتمل لها دور هام، فلا تنس أنّ هناك شخصًا حقيقيًا على الطرف الآخر، يقرأ سيرتك الذاتيّة، وسترغب بأن تعجبه، حتّى يكون مرتاحًا عند اتخاذ قرار توظيفك. ساعده في اتخاذ القرار بسرعة. إن كنت تحبّ التزلّج، إطعام القرود في حديقة الحيوان، فاذكر ذلك. كن مبتكرًا، لا تكن مملًّا، تمامًا كمواقع التعارف الاجتماعي. التصميم كيف يجب أن تبدو سيرتك الذاتيّة ذات الصفحة الواحدة؟ يجب أن تُظهِر شخصيتك من خلال سيرتك الذاتية، تجنّب بالتالي استخدام القوالب الجاهزة التي يمكنك تحميلها مجّانًا. قم بإنشاء قالبك الخاص، وحتى لو لم تكن قادرًا على التصميم، فاطلب المساعدة من صديق يستطيع. تذكّر حقًّا بأنّ كل ما تحتاج القيام به هو اختيار نوع الخط، قياسه وبضعة ألوان خفيفة هنا أو هناك. إن سيرتك الذاتيّة هي المنتج الذي تريد تسويقه، فأنت من صَنَعَها، أنت من رعيتها واهتممت بها، فإن كانت مجرّد مستند Word بالقالب القياسيّ ستجعلهم يشعرون بأنّك لم تهتم بما يكفي بها، فإن لم تهتم بأمر صغير كهذا، فكيف ستهتم بإنشاء برمجياتهم؟ بالتالي، لا تهمل جماليّة سيرتك الذاتية، ولا تجعلها متكلّفة، يمكنك أن تجعلها بسيطة جدًا لكنها يجب أن تمثّلك، وأن تكون قد بذلت من أجلها الاهتمام الكافي. ترجمة -وبتصرّف- للمقال Pimp Up Your Resume لصاحبه Yegor Bugayenko. حقوق الصورة البارزة: Designed by Freepik.

سنتناول في هذا المقال الأسئلة العشرة الأكثر تكرارًا حول Git والحلول المتعلقة بها. ستساعد هذه الحلول في تجاوز بعض العقبات عند استخدام Git. 1. كيف أقوم بتحرير رسالة إيداع commit خاطئة في Git؟ وهو سؤال يطرح بكثرة من طرف كل من بدأ لتوّه باستخدام Git. لتحرير رسالة إيداع commit خاطئة قمنا بكتابتها، نستخدم الأوامر التالية: git commit --amend سيقوم الأمر بفتح المحرّر الذي سيسمح بتغيير أحدث إيداع. إن أردنا تحرير رسالة الإيداع مباشرة عبر سطر الأوامر، يمكننا القيام بذلك باستخدام الأمر: git commit --amend -m "الرسالة الجديدة" 2. كيف أتراجع عن آخر إيداع commit كاملا؟ للتراجع عن إيداع بعض الملفّات نقوم في البداية بإلغاء آخر إيداع باستخدام الأمر: git reset --hard HEAD~1 سيقوم هذا الأمر بنقل مؤشر الرأس HEAD إلى الإيداع قبل الأخير. بعد ذلك، نقوم بعرض حالة جميع الملفات مرّة أخرى باستخدام الأمر: git status وأخيرًا، نضيف الملفات التي نودّ إضافتها إلى الإيداع باستخدام الأمر: git add ... 3. كيف أتراجع عن إضافة ملف git add؟ للتراجع عن إضافة بعض أو كل الملفّات إلى منطقة الإدراج بالأمر المذكور، نستخدم أحد الأوامر التالية: للتراجع عن ملف وحيد: git reset <FileName> للتراجع عن جميع الملفّات: git reset 4. كيف أحذف تفرع branch (محلي أو بعيد)؟ لحذف تفرّع محلّي، نستخدم الأمر: git branch -d yourLocalBranchName ولحذف تفرّع بعيد، نستخدم الأمر: git push origin --delete yourRemoteBranchName 5. كيف أحذف ملفات محلية من التفرع الحالي لحذف جميع الملفّات المحلّية التي لا نرغب بإيداعها أو الحفاظ عليها في مجلّد العمل، نستخدم الأمر: git clean -f أو: git reset --hard 6. كيف أعيد تسمية تفرع محلي؟ لإعادة تسمية تفرّع محلّي، لدينا حالتان: إعادة تسمية لتفرّع الحالي: git branch -m newBranchName إعادة تسمية تفرّع آخر ليس التفرّع النّشط الحالي: git branch -m oldBranchName newBranchName 7. كيف أنشئ تفرعا بعيدا remote Git branch؟ لإنشاء تفرّع بعيد، نقوم أوّلًا بإنشاء تفرّع محلّي: git checkout -b newBranchName ومن ثم نقوم بدفع التفرّع الذي أنشأناه إلى الخادم البعيد: git push origin newBranchName 8. كيف أغير الرابط الخاص بمستودع بعيد remote Git repository؟ لتغيير الرابط الخاص بمستودع بعيد (لنفترض أنه التفرّع origin) نستخدم الأمر التالي: git remote set-url origin newURL 9. كيف أغير اسم من قام بالإيداع؟ يمكن تغيير اسم من قام بالإيداع في سجلّ المُستودع باستخدام السكربت التالي المأخوذ من مقالات موقع github.com: git filter-branch --env-filter ' an="$GIT_AUTHOR_NAME" am="$GIT_AUTHOR_EMAIL" cn="$GIT_COMMITER_NAME" cm="$GIT_COMMITTER_EMAIL" if[ "$GIT_COMMITTER_EMAIL" = "your@email.to.match" ] then cn="New Committer Name" cm="New Committer Email" fi if[ "$GIT_AUTHOR_EMAIL" = "your@email.to.match" ] then an="New Author Name" am="New Author Email" fi export GIT_AUTHOR_NAME="$an" export GIT_AUTHOR_EMAIL="$am" export GIT_COMMITTER_NAME="$cn" export GIT_AUTHOR_EMAIL="$cm"' 10. كيف أستنسخ مستودعا في مجلد معين؟ لاستنساخ مستودع في مجلّد معيّن، نحتاج إمّا: الانتقال بمسار سطر الأوامر إلى داخل ذلك المجلّد وتنفيذ الأمر: git clone <URL> أو ننفّذ الأمر: git clone <URL> <yourFolderName> حيث أن yourFolderName هو اسم/مسار المُجلّد المعني بالأمر. ترجمة -وبتصرّف- للمقال Top 10 frequently asked questions on Git لصاحبه Hemant Joshi.

هل تحاول متابعة آخر التحديثات لعدِّة مشاريع على GitHub؟ إذًا أنت لست حديث العهد باستقبال العديد من الإشعارات حول: التبليغ عن العلل، ونشر تعليقات، وقبول طلبات إضافة (pull requests). تتطلب بعض الأمور السابقة تدخلًا منك، وعليك أن تعلم عن بعضها الآخر، والباقي مجرد ضوضاء. هذه مُرشِّحات (filters) لبريد Gmail التي أستعملها لكي أحصل على الإشعارات المفيدة بسرعة. لدى GitHub مركز إشعارات خاص به يسمح بترشيح الإشعارات لكل مشروع، بالإضافة إلى إظهار الإشعارات للأشياء التي تُشارِك فيها فقط. وكل إشعار له أيقونة خاصة به تُحدِّد ما إن كان مشكلةً أو طلبَ دمجٍ وسواءً بقي مفتوحًا/أو لم يُدمَج بعد. هذا مفيدٌ حقًا، ويقلل الوقت اللازم لتفقد اللائحة كل يوم؛ على سبيل المثال، ربما تريد تخطي المشكلات التي تم إغلاقها أو الطلبات التي تم دمجها، وتتطلع بسرعة على المشكلات التي لم تُذكَر فيها، وتُركِّز على ما أنت مشاركٌ فيه. ماذا لو كنت تفضل التعامل مع الإشعارات عبر البريد الإلكتروني؟ أنا أفضل أن يكون كل شيءٍ موجودًا في مكانٍ واحد في صندوق الوارد. لكني سأفوت على نفسي كل الميزات الموفرة للوقت التي يعطيني إياها مركز الإشعارات. لن يكون المرور على الإشعارات واحدًا واحدًا ذا إنتاجيةٍ عالية. لكن لحسن الحظ، يمكن جلب بعض ميزات مركز الإشعارات إلى بريدك الإلكتروني باستعمال "المرشحات" (filters)، وهذه هي المرشحات التي أستعملها مع Gmail. وسم جميع الإشعارات من GitHub لأنني أستقبل عددًا كبيرًا من الرسائل من GitHub، فأحب أن أوسمها (tag) جميعًا كي أميز بينها وبين الرسائل الأخرى بسهولة؛ ومن النادر أن تكون إشعارات GitHub ذات أولويةً عالية، ووسمها كلها سيسمح لي بإخفائها بسهولة كي أتأكد أنني لم أفوِّت رسالةً مهمةً. لضبط ما سبق، رشِّح حقل "From:‎" للبريد "notifications@github.com"، يبدو هذا في Gmail كالآتي: from:(notifications@github.com) التكليفات أحاول أن أهتم بما أنا مكلفٌ به، ولهذا أعلِّم تلك الرسائل بوسم "Assignment"، وعندما أكون مشغولًا، أنظر إلى هذه القائمة فقط لكي أتأكد أنَّ كل شيءٍ أنا مسؤولٌ عن إنجازه قد أُنجِز. عندما يُسنِد أحدهم مشكلةٍ إليك، فسيُرسِل GitHub تنبيهًا، ويمكن تعليم (أو توسيم) كامل الموضوع (thread) كتكليفٍ إليك عبر مطابقة هذه الرسالة التنبيهية. سيبدو مُرشِّح Gmail كالآتي (ابحث عن معرفك@ Assigned to): from:(notifications@github.com) Assigned to @pazdera هنالك بعض المحدوديات لهذه الطريقة لسوء الحظ، فلن يُرسَل إليك إشعارٌ إن أسندتَ المشكلة إلى نفسك ولن يُوسَّم الموضوع بشكلٍ صحيح في هذه الحالة؛ وإن أعيد إسناد المشكلة إلى شخصٍ آخر، فسيبقى الموضوع موسمًا على أنك مكلّف بالمشكلة. ذكر معرفك (Mentions) ربما هذا المرشح هو أكثرهم فائدةً لأنه يسمح لك برؤية الرسائل التي ذُكِرتَ فيها دون الحاجة إلى النظر إلى جميع الرسائل غير المهمة بحثًا عن مُعرِّفك على GitHub، فستعلم تمامًا أين طُلِبَت مداخلتك. استعمل مُرشِّحًا يطابق مُعرِّفك على GitHub في جسد الرسالة كما يلي: from:(notifications@github.com) @pazdera طلب pull request تم دمجه Merged لن تكون -في أغلب الأوقات- هنالك حاجةٌ لمداخلتك عندما يُدمج طلب Pull Request ويمكنك تجاوزها في أغلب الأحيان (خصيصًا إن لم تُذكَر في النقاش في طلب Pull Request ‏[PR]). يُرسِل GitHub إشعارًا يمكِّنك من إنشاء مُرشِّح لتوسيم الموضوع (thread) على أنه Merged. from:(notifications@github.com) Merged للأسف، لا يوجد دعم للتعابير النمطية (regular expressions) في Gmail، ولهذا سيُطابِق المرشح السابق التعليقات التي يذكر فيها صاحبها الكلمة "Merged". لكن -وإن كان يبدو ذلك مشكلةً كبيرةً- من النادر حدوث ذلك حسب تجربتي. مشكلة تم إغلاقها Closed في نهاية المطاف، من المفيد -عندما تُغلق مشكلة- أن تعرف عن ذلك دون الحاجة إلى النقر على الرسالة لفتحها. أستعمل المُرشِّح الآتي لتعليم كل تلك الرسائل للحذف مباشرةً. from:(notifications@github.com) Closed \# هذه هي المرشحات الخمسة التي تساعدني في التخلص من الكم الكبير من تنبيهات GitHub في بريدي. ما الذي تستعمله كيلا تقضي ساعاتٍ في بريدك؟ شارك ذلك في التعليقات أدناه. ترجمة -وبتصرّف- للمقال ‎5 Useful Gmail Filters for GitHub Users لصاحبه Radek Pazdera.

يجعل المساهمون من المشاريع مفتوحة المصدر مرحةً، فالسماح للآخرين باستعمال، وإعادة استعمال، وتحسين الشيفرات الخاصة بك وتحويلها إلى شيءٍ جديد لم تكن تتخيله، هو أمرٌ رائع؛ لكن -كغيره من الأمور في هذه الحياة- لن يتشكل المجتمع من العدم. ونحن نمر في هذه السلسلة من المقالات بعدة استراتيجيات لمساعدتك في بناء مجتمع حول مشروعك المفتوح المصدر؛ وركَّزت آخر ثلاث مقالات على جذب المستخدمين، وسنلقِ نظرةً هذه المرة على كيفية تحويلهم إلى مساهمين. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين (هذا الدرس) كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر وضح أن تطبيقك مفتوح المصدر إن جعلت تطبيقك سهل التثبيت بإنشاء مُثبِّت أو حزمة، فهنالك احتمالٌ كبيرٌ ألّا يفتح المستخدمون صفحة الهبوط أو المستودع؛ ولا بأس في ذلك في أغلبية الأوقات، لكن عليك أن تضع أنَّ تطبيقك مفتوح المصدر في مكان ما فيه لأولائك الذين يريدون التواصل ومعرفة المزيد من المعلومات حول تطبيقك. قد تستعمل خيارًا في سطر الأوامر، أو مربع حوار "حول" أو "About" إن كان لتطبيقك واجهةٌ رسوميةٌ؛ وضع رابطًا لصفحة الهبوط وربما لمتتبع العِلل الخاص بك (المكان الذي يُبلِّغ الناس فيه عن المشكلات التي تواجههم). ومن المحتمل أنَّ نكتةً في التطبيق ستدفع المستخدم إلى زيارة الرابط الموجود فيها. مكانٌ جيدٌ لتضع فيه طرق التواصل معك هو عبر رسائل الخطأ ومربعات الحوار التي تظهر عند انهيار التطبيق؛ أخبر فيها المستخدمين كيف يبلغون عن المشكلة، وهذه هي أكثر الطرق شيوعًا للمشاركة في تطوير المشاريع؛ حيث يحاولون فعل شيءٍ ما، لكنه لا يعمل وسيمدون يد العون في إصلاح المشكلة. المزايا المرتقبة إحدى طرق دفع الآخرين للمشاركة هي استعمال الميزات غير المكتملة؛ ربما تدمج الميزات التي تود إضافتها للتطبيق في المستقبل إلى واجهة المستخدم وتُظهِر رسالة تشرح أن هذه الميزة لم تتم، وتدعو الآخرين إلى مساعدتك في إكمال العمل عليها. قد تستعمل خيارًا إضافيًا في سطر الأوامر الذي يعرض رسالةً (بدلًا من الميزة المطلوبة)، ويمكن فعل المثل بمربعات الحوار في التطبيقات الرسومية. ضع ببالك أن هذا قد يصبح مزعجًا بشكل سريع؛ ولهذا عليك استعماله مع الميزات غير الأساسية في مشروعك؛ فلن يُسعَد مستخدموك إن نزَّلوا مكتبتك الجديدة عن الفرز (sort) ليجدوا أنَّ الفرز السريع (quick sort) ليس مُبرمجًا بعد. اكتب توثيقا منفصلا للمطورين يجب أن يكون لمشروعك توثيقٌ من نوعٌ ما للمطورين مع لمحة من مكان تواجد الأجزاء الرئيسية من البرنامج، ومرجع للواجهات البرمجية (APIs) يمكن البحث فيه. من الأفضل أن يتم توليد ذاك التوثيق من الشيفرات المصدرية بأدواتٍ مثل doxygen، أو JSDoc، أو YARD. يساعدك وجود التوثيق مع الشيفرات بتسهيل التعديلات البرمجية على المشروع. وهنالك مواقع مثل RubyDoc يسمح لك بتوليد واستضافة التوثيق مجانًا. لا يوجد أبسط من هذا! إن كتبت لمحة للمطورين عن المشروع وأبقيتها مختصرة ومحددة، فليس من المحتمل أن تحتاج إلى إعادة كتابتها بين الحين والآخر، إلا إن كنت تعيد هيكلة المشروع بأكمله. وضح ما الذي يجب فعله من المحتمل أن يتمحور تطوير تطبيقك حول مُتتبع العلل، فستأتي العلل وسيحاول المساهمون تتبعها وحلها، وفي حال استمرت هذه العملية، فسيمسي من السهل أن يتحول إلى كومة مربكة من الأشياء التي لن يستطيع أحد غيرك أنت وبعض أفراد فريق المساهمين فهم طريقة تنظيمها. لكن كيف سيتمكن المساهمون الجدد من البدء في العمل؟ حاول أن يكون متتبع العلل منظمًا بشكلٍ جيد وكأنك ستتجه غدًا إلى العمل مزارعًا في الحقل، ولن تدخل إلى الإنترنت بعد ذاك اليوم أبدًا، وسيأتي أحدهم ليكمل ما بدأتَه. أبقِ قائمةً بالمهام البسيطة والمحددة للمساهمين الجدد ليفعلوها عندما يأتون لأول مرة، حتى لو كنت تستطيع تنفيذها أنت بخمس دقائق، ربما يأخذ تفصيلُ شرحِ مشكلةٍ ما في متتبع العلل وقتًا لا بأس به، لكنه سيؤتي أكله إن ساعدتْ تلك العلة بتثبيت مساهم جديد في المشروع. كن متجاوبا عندما يحصل مشروعك على أول المستخدمين أو حتى أول المساهمين، فستبدأ باستقبال أسئلة، وطلبات للميزات، وتبليغات عن العلل وحتى سيصلك حلولٌ لتلك العلل؛ حاول أن تستجيب وتساعد الآخرين بمشاكلهم في إطار زمني محدد، حتى لو كنت مشغولًا وتقوم بتطوعك في وقت فراغك. فستؤدي استجابتك لطلبات pull requests بعد شهر إلى فقدان المساهمين لحماسهم. أجب حتى وإن لم تستطع إنجاز ما طُلِبَ مباشرةً، فمن الأفضل أن تقول "لا" وتضع الطلب في قائمة الأعمال غير المنجزة من أن تتركه معلقًا في الهواء أو أن تعد بشيءٍ لا تستطيع تلبيته. لكن بدلًا من ذلك، ضع الطلب في متتبع العلل لعل أحدهم ينجزه؛ هذا هو جمال البرمجيات مفتوحة المصدر. أصبح مساهما إن كنت حديث العهد بهذا العالم المُربك من البرمجيات الحرة والمفتوحة المصدر، أو ربما كان مشروعك خارج "البيئة" التي نشأت بها واستخدمتها من قبل، فجرب المساهمة في مشاريع مشابهة وانظر إن كان من السهل البدء من التوثيق الذي كتبوه، وأين بدأت تواجه مشاكل معه. هل أجاب أحدهم عن تساؤلك أو قَبِلَ الرقعة (patch) التي أرسلتها؟ استخدم خبرتك من هذه التجربة لتقديم مشروعك بأفضل صورة ممكنة لتسهل انضمام المساهمين الجدد. ما التالي؟ لقد أرسيتَ أساسات مشروعك، وأعداد مستخدميه والمساهمين فيه تزداد باطراد، فما الخطوة الآتية؟ هذا ما سيكون موضوع آخر المقالات في هذه السلسلة. ترجمة -وبتصرّف- للمقال Turning users into contributors لصاحبه Radek Pazdera.

حتى لو لم تكن تطلب من الأشخاص مالًا لقاء استعمالهم لتطبيقك، لكن ما يزال علينا التسويق قليلًا له قبل أن يسطع نجمه. كيف إذًا سيعلم الآخرون عنه؟! الناس مشغولون هذه الأيام التي أصبحت فيها المشاريع مفتوحة المصدر لا تُعد ولا تحصى، وأصبحت المنافسة قوية جدًا على المساهمين في المشاريع. عرفنا -في آخر مقالين من هذه السلسلة- الجمهور الهدف لمشرعنا ثم تأكدنا أنه متاحٌ -وبسهولة- لمن شاء أن يستعمله؛ هذا الدرس هو القسم الثالث من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. أقسام هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر (هذا الدرس) كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر الفكرة بسيطةٌ للغاية: عليك أن تعرض المشروع على الأشخاص المناسبين في الوقت الملائم (عندما يحتاجون إلى التعرف على مشروعك)؛ كل برنامج له وظائف معيّنة تجعله مفيدًا لمجموعة بسيطة من المستخدمين. لا ترسل رسائل عشوائية لأكبر عدد تستطيعه من الأشخاص؛ لكن وجِّه جهودك إلى المجتمعات التي ستستفيد من المعرفة عن مشروعك. لنقل أنَّك برمجت إطار عملٍ مثل ExpressJS، عمومًا ستكون جهودك موجهة نحو الأشخاص الذين يطورون مواقع الويب؛ وربما تود أن تستهدف أولاءك الذين "يفكرون" في صنع موقع إلكتروني لكن لم يبدؤوا بعد، أما البقية فسيقولون "هذا رائع!" لكنهم سيواصلون استعمال Sinatra أو Flask لأن الشيفرات التي كتبوها تعتمد عليها. حل المشكلات وهذا ما يبرع المبرمجون بفعله. لِمَ لا تستعمل ذلك لصالحك؟ لقد أنشأت مشروعك لحل مشكلة واجهتك ومن المحتمل أنَّ الآخرين يحاولون حل نفس المشكلة. أنشِئ محتوى حول المشاكل التي يحلها مشروعك، وما الذي يفعله بشكلٍ جيد. وهذا يعني أنَّ عليك كتابة مقالات، أو صنع مقاطع فيديو، أو تسجيل بودكاست، أو حتى إلقاء محاضرات أو التعليم في دورات تدريبية، أيها تُفضِّل. لكن النص يبقى هو الأفضل لأنه دائم وقابل للبحث. يمكنك نشر تلك المواد في عددٍ من الأماكن، مثل مدونتك الشخصية أو أن تنشر منشورًا على مدونة خاصة بالمجتمع التقني الذي ينتمي إليه مشروعك. ثم شارك ذاك المقال مع مَن تظن أنهم سيجدونه مفيدًا. وهذا يتضمن منتديات النقاش، والمجموعات البريدية، وقنوات Gitter، و Reddit أو Hacker News. تأكد أنَّ ذاك المجتمع سيرحب بذلك (بعض الأقسام الفرعية من Reddit [يسمونها subreddits]) لا تسمح بنشر روابط)، وكن حذرًا جدًا بالتعامل مع القوائم البريدية، فراعي أنَّ رسالتك ستصل إلى البريد الوارد لكثيرٍ من الأشخاص. إن كانت هنالك العديد من قنوات التواصل لجمهورك المستهدف، فلا تُرسِل الرسائل إليها جميعًا، اختر قناتين أو أكثر منهم فقط، وإن أُعجِبَ الجمهور بمشروعك فسيتنشر تلقائيًا. اجعل تواتر نشرك للمقالات في حدود المعقول وعدِّلها بناءً على ردة فعل القراء، فإن أعجبتهم، فذاك أمرٌ حسن، وأتبعها أخرى في الأسبوع القادم؛ وإن لم يكونوا متحمسين، فحاول شيئًا جديدًا في المرة القادمة، وستكون الردود على مشروعك أفضل إن كنت تشارك في المجتمع مشاركةً فعالةً (بجانب مشاركتك لدعايتك إلى مشروعك). الإجابة عن الأسئلة إن كان مشروعك يحل مشكلة مخصصة جدًا، فربما من المفيد أن تراقب المواقع التي يسأل الناس فيها عادةً عنها، مثل StackOverflow أو Reddit، وأن تساعدهم في الأمر. وعندما تُجيب، حاول دائمًا أن تسهب في الموضوع قليلًا لإعطاء مجال لتشرح كيف يعمل حلّك للمشكلة، ولا بأس أن تُعدِّد الخيارات الأخرى المتاحة. ربما ذلك يستهلك وقتًا أكثر من إعطاء مجموعة روابط، لكن ربما تستفيد من سؤالك بتحويله إلى تدوينة لاحقًا. تلك المواقع هي مولدات أفكار رائعة؛ فإن أردت أن تعرف ما هي المشاكل التي يعاني منها الناس، فألقِ نظرةً على الأسئلة التي يسألونها. العمل مع الآخرين لا يتواجد مشروعك في الفراغ، وإنما بُنِيَ باستعمال بعض المكتبات الأخرى، وهنالك أشياءٌ أخرى يمكن أن تُدمَج أو تتعاون معه. أخبر الناس كيف يستطيعون استعمال مكتباتك وأرهم كيف يدمجون مشروعك مع الأدوات الأخرى. قدِّم ما لديك لأعضاء المجتمعات التي تلتف حول تلك المشاريع، وسينظرون إليها إن وجدوها مفيدةً؛ وعلى الرغم من أنك تعتمد على شعبية مشروع قائم، إلا أنك تساهم في نشره في نفس الوقت. وما لم يثر المحتوى الذي تقدم جدلًا، فلا يوجد سببٌ يمنع أصحاب تلك المشاريع من الترحيب لكتابتك عن مشاريعهم، وربما يشاركون ما كتبتَ أيضًا: "رائع! أحدهم أنشأت روبوتًا باستخدام مكتبتي". كن لطيفا لا تقلل من شأن عمل غيرك لكي تعلي من شأن عملك. ربما تظن أن مشروعك هو الأفضل، صحيح؟ هذا لأنك من أنشأه وقد يكون هذا صحيحًا، ولا بأس من عمل مقارنات، لكن لا تقل أشياءً مثل "على عكس مكتبة RottenWatermelon JS، هذا الإطار يحتوي على sane API" أو "اضطررت على مر السنين أن أتعامل مع الخردة المسماة ‎OMG++‎، لكنني أتيت اليوم لأفتح مصدر اللغة Gobbledygook: لغة البرمجة للقرن الحادي والعشرين". قد يلفت الجدار النظر إليك، لكنه لن يُنشِئ بيئةً صحية وودودةً لكي ينمو بها المجتمع المحيط بمشروعك؛ تذكر أنه في خمس سنين سيصبح مشروعك تقنيةً قديمةً جدًا ولن يستعملها أحد. ما التالي؟ أصبح مشروعك موجودًا وأصبح يحصل على أول مستخدميه؛ عليك الاستمرار في جهودك وسيؤتي عملك أُكله، سننظر في المقالة التالية كيف نحول المستخدمين إلى مساهمين. ترجمة -وبتصرّف- للمقال Spreading the word about your open-source project لصاحبه Radek Pazdera.

هل سبق وأن نشرتَ مشروعًا مفتوح المصدر ولم تشاهد حشدًا كبيرًا من الناس آتين لتنزيله بالآلاف، مما يعطل الخواديم في أول ليلة بعد إصداره؟ حسنًا، لا تتشكل أغلبية المجتمعات (communities) بين ليلةٍ وضحاها؛ وأصبح من الصعب جذب المساهمين -بوجود العدد الكبير من المشاريع المتوفرة في أيامنا هذه- دون القيام ببعض التسويق. لكن أغلبنا -معشرَ المبرمجين- لسنا معتادين على التسويق أو مرتاحين بفعله؛ وبذلك ستبقى الشيفرات التي نكتبها تقبع مهجورةً بالمستودعات ولا يأبه أحدٌ بأمرها، فما الحل؟ هذه السلسلة من المقالات ستأخذنا برحلةٍ عبر عددٍ من الأمور التي عليك فعلها كي تساعد باكتشاف مشروعك ولتُسهِّل على الآخرين الاشتراك به. هذا الدرس هو القسم الأول من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. الجمهور المستهدف وصفحة الهبوط (هذا الدرس) كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر يبدأ المجتمع بالمستخدمين السؤال الذي يبدأ الأشخاص بسؤاله عادةً هو "كيف أتمكن من جعل الآخرين يساهمون في مشروعي؟" وهذا السؤال -في غالب الأحيان- سابقٌ لأوانه. فقبل التفكير بالمساهمين، عليك التفكير بالمستخدمين. فدون أن يكون لديك قاعدة مستخدمين كبيرة (نسبيًا)، سيكون من الصعب جذب أيّة مساهمين على الإطلاق. فهل تساهم أنت في مشاريع لم تستعملها قط؟ ربما لا، وكذلك سيفعل البقية. سأفترض أنك أنشأت مشروعك ليحل مشكلةً واجَهتك من قبل، وربما تواجه الكثيرين غيرك، كل ما عليك فعله هو أن تجدهم. اكتشف من هم جمهورك المستهدف تعتبر أصغر المشاريع "منتجاتٍ"، فهي تحل مشكلة أو تلبي حاجة ما؛ فما هي المشكلة التي يحلها مشروعك؟ ومَن الذي سيراه مفيدًا؟ سيساعدك التفكير بهذين السؤالين على توجيه جهودك والتركيز على من يهتمون دون أن "تزعج" من لا يأبهون بمشروعك بتاتًا. هل أنشأت إضافةً لمحرر vim (محرر سطري مشهور جدًا على الأنظمة الشبيهة بيونكس)؟ ربما أنت تبحث عن الأشخاص الذين يستعملون vim، وقد لا يكون وضع تلك الإضافة في "emacs subreddit" أفضل شيءٍ تفعله. ابحث عن أولائك الأشخاص وتواصل معهم وانضم إليهم، تنجذب مجموعات من ذوي الاهتمامات المتشابهة نحو أماكن معينة أو قنوات اتصال مخصصة، وربما لديهم اجتماعات محلية أو subredits خاصة بهم. بينما مثالنا عن vim السابق بسيط، لكن الأمر ليس بهذا الوضوح خصيصًا بجمهورٍ شغوفٍ ومتحمسٍ كالمبرمجين، فيمكن أن توقع نفسك بنقاشاتٍ محتدمة (يسميها معشر المبرمجين بالمصطلح "flame wars")، وفي بعض الأحيان لا يكتفون بتجاهلك وإنما سينالون من هيبة مشروعك؛ فاستهداف الأشخاص الصحيحين يعني أيضًا أنك لن تزعج أولاءك الذين لا يشاركونك رأيك. إعداد صفحة هبوط (Landing page) قبل إخبار الناس عن مشروعك، عليك أن تهيّء مكانًا لترسلهم إليه يحتوي كل ما يحتاجونه للبدء باستعمال مشروعك؛ وهذا المكان قد يكون ملف README على Github، أو تدوينة، أو موقع مخصص لذلك. يجب على تلك الصفحة أن تلخص ماذا يفعل مشروعك، ومن أين ستحصل عليه، وكيف تجعله يعمل، وقد تنتهي (اختياريًا) بمرجع مُبسَّط وسريع حول المهام أو المشاكل الشائعة؛ فعليك تبيان الحدود القصوى لمشروعك، لكن لا تعرضها في البداية، بل ركز على ما يبرع تطبيقك بفعله ودع تلك الحالات لتكتبها في التوثيق. إن كان يعطي تطبيقك مخرجاتٍ مرئيةً من أي نوع، أو كانت له واجهةٌ رسومية، فلا تنسَ أن تضيف لقطاتٍ للشاشة، وإن لم تكن مخرجاته مرئيةً، لا بأس من أخذ لقطات للطرفية (مكان إظهار نواتج الأوامر) أو عمل صور متحركة (gifs) لها؛ ضع بعين الاعتبار أنَّ الناس سيفهمون تطبيقك أسرع "بمشاهدته" أكثر من مجرد القراءة عنه. في النهاية، يجب أن توفر صفحة الهبوط طرقًا للتواصل معك أو للمجتمع المحيط بالمشروع ليحصلوا على الدعم؛ جهّز قائمةً بريديةً، أو قناة IRC، أو غرفة على Gitter ووفرها لهم؛ أما للمشاريع الصغيرة، فقد يكفي وضع بريدك الإلكتروني. عليك أن تراعي عادات الفئة المستهدفة، فلن يُسعَد ثلةٌ من خبراء أمن المعلومات بالتسكع في مجموعتك على فيس بوك. عليك بعد أن تجهز صفحتك أن تنشرها في مختلف أماكن تواجد المبرمجين مثل موقع Hacker News و r/programming (على reddit)؛ لكن جهودك تلك ليست موجهة لفئة معيّنة، وتعتمد على الحظ كثيرًا؛ سأتحدث عن طرقٍ أفضل لنشر مشرعك في مقالاتٍ قادمة من هذه السلسلة، ابقَ معنا! عندما تصل إلى مرحلة إنشاء الصفحة، تذكر أنَّه لا يهم شكلها بقدر أهمية محتواها؛ وفي الواقع، عليك أن تقضي وقتًا أطول بالتفكير بمحتواها أكثر من بقية الأمور. هل أنت مطور واجهات محترف يتمكن من تصميم موقع مصمم تصميمًا رائعًا في ساعتين؟ هذا جميل اذهب وصمم أجمل ما تستطيع، لكن لا تنفق ثلاثة أشهر وأنت تضيع وقتك على كم يجب أن تكون قيمة الهامش لعناوين الصفحة مثلا فالأمر لا يستحق كل ذلك العناء. ملف README على GitHub سيكون كافيًا عادةً. ما التالي؟ سنتحدث في المقالة القادمة عن جعل مشروعك أكثر قابليةً للوصول للمستخدمين. فالأسوأ من عدم القدرة على فهم ما الذي يفعله المشروع هو تضييع ثلاث ساعات لمحاولة جعله يعمل! ترجمة -وبتصرّف- للمقال Marketing for open-source projects لصاحبه Radek Pazdera.

يُستخدَم Hexo، وهو إطار عمل للتدوين الثابت (Static) مبنيّ على Node.js، لنشر تدوينات مكتوبة في مستندات Markdown. تُعالَج التدوينات ثم تُحوَّل إلى HTML/CSS انطلاقا من قوالب معدَّة لهذا الغرض (تماما كما تفعل بقية مُولّدات المحتوى الثابت مثل Jekyll و Ghost). يعمل Hexo على هيئة وِحدات (Modules) يمكن ثبيتها وإعدادها حسب الحاجة. سنعدّ في هذا المقال Hexo اعتمادا على خادوم ويب Nginx ومنصة GitHub. المتطلبات في ما يلي قائمة بما ستحتاجه لإنجاز هذا الدرس: خادوم أوبنتو 14.04 مع حساب ذي صلاحيات إدارية غير المستخدم الجذر. يمكنك إعداد حساب بالمواصفات المطلوبة باتباع خطوات درس الإعداد الابتدائي لخادوم أوبنتو. تثبيت Git على خادوم أوبنتو وإعداده. يشرح درس تنصيب وإعداد Git و gitolite للتحكم في الإصدارات على أوبنتو الكيفية. تثبيت Node.js على خادوم أوبنتو. تثبيت Nginx على خادوم أوبنتو. حساب على GitHub الذي هو مستودع Git. تأكد من أن المتطلبات مثبتة ومضبوطة ثم انتقل إلى خطوات تثبيت Hexo وإعداده. الخطوة الأولى: تثبيت Hexo وبدء تشغيله تتضمن هذه الفقرة كل ما عليك فعله لتثبيت Hexo وجعله يعمل على خادومك. ابدأ أولا بتحديث الحزم: sudo apt-get update && sudo apt-get upgrade يتكوّن Hexo من الكثير من العناصر والحزم البرمجية. سنجلب اثنتين من الحزم الأكثر أهمية في Hexo باستخدام مدير الاعتمادات npm. العنصر الأول والأهم هو hexo-cli، يوفر أوامر Hexo الأساسية : npm install hexo-cli -g ثم نأتي للعنصر الثاني hexo-server وهو خادوم مضمَّن يمكن استخدامه للعرض المسبق للتدوينات واختبارها قبل النشر: npm install hexo-server -g تتوفر الكثير من الحزم الأخرى لـHexo، إلا أن الحزمتين أعلاه هما الأساس الذي لا يُستغنى عنه لإطلاق مدونة باستخدام Hexo. يمكن أن تستعرض الحزم الأخرى المكونة لإطار عمل Hexo بخاصية البحث في npm. نحتاج الآن لقاعدة ملفات لبناء مدونتنا عليها. يُوفِّر Hexo أمر init لهذا الغرض، كل ما عليك فعله هو تمرير المسار أو المجلد الذي تريد استخدامه لملفات إعداد المدونة إلى الأمر: hexo init ~/hexo_blog يستغرق اﻷمر بضع ثوان حسب سرعة الاتصال لديك: INFO Copying data to ~/hexo_blog INFO You are almost done! Don't forget to run 'npm install' before you start blogging with Hexo! . . . ننتقل إلى المجلد المستخدَم في الأمر السابق: cd ~/hexo_blog ثم ننفذ أمر التثبيت التالي: npm install يمكنك تجاهل التحذيرات الاختيارية (WARN notsup). نحصُل بعد انتهاء تنفيذ الأمر على ملفات الإعداد الأساسية. الخطوة الثانية: ضبط ملف الإعداد الأساسي في Hexo نسرُد محتويات مجلد المشروع: ls -l تظهر مخرجات على النحو التالي: -rw-rw-r-- 1 zeine77 zeine77 1483 Feb 17 15:48 _config.yml drwxrwxr-x 201 zeine77 zeine77 36864 Feb 17 15:53 node_modules -rw-rw-r-- 1 zeine77 zeine77 442 Feb 17 15:48 package.json drwxrwxr-x 2 zeine77 zeine77 4096 Feb 17 15:45 scaffolds drwxrwxr-x 3 zeine77 zeine77 4096 Feb 17 15:45 source drwxrwxr-x 3 zeine77 zeine77 4096 Feb 17 15:45 themes يعدّ الملف config.yml_ أهم هذه الملفات إذ تخزَّن به إعدادات نواة Hexo. إن احتجت مستقبلا لإجراء تعديلات على المدونة فعلى الأرجح سيكون ذلك من خلال هذا الملف. نفتح الملف لإجراء تخصيصات على البرنامج: nano _config.yml توجد في أعلى الملف فقرة معنونة بـSite (الموقع): # Site title: Hexo subtitle: description: author: John Doe language: timezone: يوجد في الأسطر الأربعة الأولى اسم المدونة، عنوان فرعي لها، وصف واسم صاحب المدونة. لديك كامل الحرية في اختيار ما يناسب لهذه الأسطر. انتبه إلى أن بعض قوالب Hexo لا تعرض كامل هذه المعلومات. يمكن اعتباره هذه الفقرة بيانات وصفية للمدونة. الخياران المواليان يمثلان اللغة والمنطقة الزمنية. تأخذ اللغة قيمة عبارة عن حرفين يرمزان للغة وفق معيار ISO-639-1. يُضبط الوقت مبدئيا على المنطقة الزمنية للخادوم ويستخدم صيغة قاعدة بيانات tz. إن قررت التعديل على إحدى المعطيين فتأكد أن القيمة وفق الصيغة المطلوبة. في ما يلي مثال على ملف الإعداد: #Site title: مدونة أكاديمية حسوب subtitle: مدونة تقنية تستخدم Hexo description: مثال على استخدام Hexo لإنشاء مدونة author: أكاديمية حسوب language: ar timezone: Africa/Nouakchott تضبط الفقرة الموالية إعدادات الروابط. يمكن استخدام عنوان IP قيمةً لمعطى url إن لم يكن لديك نطاق خاص. # URL ## If your site is put in a subdirectory, set url as 'http://yoursite.com/child' and root as '/child/' url: http://127.0.0.1 root: / permalink: :year/:month/:day/:title/ permalink_defaults: خيار آخر نودّ تغييره في ملف الإعداد وهو default_layout ضمن فقرة Writing إلى الأسفل قليلا. نحدد القيمة draft للمعطى. يعني هذا أن المنشورات الجديدة تُنشأ على هيئة مسودات يجب نشرها حتى تكون مرئية على المدونة. # Writing new_post_name: :title.md # File name of new posts default_layout: draft titlecase: false # Transform title into titlecase احفظ الملف ثم أغلقه. سنعود إليه لاحقا عندما نبدأ بالنشر. الخطوة الثالثة: كتابة تدوينة جديدة ونشرها تبدأ عملية نشر تدوينة (أو مسودة كما أسميناها في الإعداد أعلاه) بتنفيذ الأمر التالي، حيث أول-تدوينة هو اسم التدوينة التي تريد إنشاءها: hexo new أول-تدوينة تظهر الرسالة التالي في سطر الأوامر: INFO Created: ~/hexo_blog/source/_drafts/أول-تدوينة.md نفتح الملف لتحرير أول تدويناتنا: nano ~/hexo_blog/source/_drafts/أول-تدوينة.md يجب أن تحوي كل تدوينة على جبهة أمامية Front-matter، وهي كتلة تعليمات قصيرة مكتوبة بـJSON أو YAML لضبط إعدادات مثل عنوان التدوينة، تاريخ النشر، الوسوم Tags ومعلومات من هذا القبيل. تُعلَّم نهاية الجبهة الأمامية بعلامة --- أو ;;;. تمكن كتابة منشور المدونة بعد الجبهة الأمامية باستخدام صيغة Markdown. أبدل المحتوى المبدئي لملف "md.أول-تدوينة" بالمحتوى التالي: title: أول تدوينة في مدونة أكاديمية حسوب tags: - حسوب - مدونة categories: - إعلانات comments: true date: 2016-02-18 09:30:00 --- ## هنا تكتب تعليمات ماركداون **هذه هي تدوينتنا الأولى!** نص التدوينة الأولى احفظ الملف ثم أغلقه. سيبقى ملف ماركداون الذي أنشأناه للتو في مجلد hexo_blog/source/_drafts/~ إلى أن ننشره. كل الملفات الموجودة في هذا الملف غير مرئية لزوار المدونة. ننشر التدوينة لتتاح للزوار hexo publish first-post تظهر الرسالة التالية: INFO Published: ~/hexo_blog/source/_posts/أول-تدوينة.md سيصبح بالإمكان رؤية المنشور فور نشر المدونة. الخطوة الرابعة: تشغيل خادوم الاختبار أكملنا في الخطوات السابقة إعداد الخادوم، ونشرنا أول تدوينة. سنشغّل خادوم الاختبار لرؤية النتيجة: hexo server يمكن الآن رؤية المدونة بزيارة http://your_server_ip:4000 حيث your_server_ip عنوان IP الموقع. سيظهر لديك منشور Hello World المعرَّف مسبقا، إضافة للمنشور الذي كتبناه للتو. اضغط على الزرين CTRL+C لإيقاف خادوم الاختبار. يُستخدم خادوم الاختبار لعرض التغييرات والإضافات إلى المدونة، ثم يأتي وقت نشر المدونة على الشبكة بعد أن تنتهي من التعديلات. الخطو الخامسة: إعداد Git لنشر المدونة توجد وسائل عدة لنشر ما أعدنناه على Hexo. المقاربة المختارة في هذا الدرس هي استخدام Git لتخزين الملفات الثابتة، الخطافات Hooks لتوجيهها وNginx لتقديمها. تتيح حزم في Hexo الدعم لـ Heroku ،Rsync ،OpenShift وغيرها. سنحتاج لمستودع Git نخزّن فيه ملفات HTML التي يولّدها Hexo. سنستخدم مستودعا عموميا على GitHub لتسهيل الأمور. أنشئ مستودعا جديدا على GitHub باسم hexo_static أو أي اسم آخر تراه مناسبا، مع التأكد من أن المستودع عمومي (خيار Public). حدّد مربع Initialize this repository with a README لإضافة ملف README تلقائيا إلى المستودع. افتح ملف الإعداد الرئيسي لـHexo من أجل تحريره: nano _config.yml توجد في أسفل الملف فقرة معنونة بـDeployment: # Deployment ## Docs: https://hexo.io/docs/deployment.html deploy: type: حدّد خيارات النشر كما في المثال أدناه. يحيل رابط URL إلى المستودع الذي أنشأته للتو؛ لذا تأكد من وضع اسم حسابك في GitHub مكان your_github_username. أبدل كذلك اسم المستودع إن كنت اخترت اسما مغايرا. deploy: type: git repo: https://github.com/your_github_username/hexo_static.git branch: master احفظ الملف ثم أغلقه. بما أننا اخترنا النشر عن طريق Git فسنحتاج لحزمة Hexo التي ترسل الملفات الثابتة التي يولدها إلى مستودع Git. استخدم npm لتثبيتها: npm install hexo-deployer-git --save يمكنك الآن تجربة إرسال الملفات إلى مستودع hexo_static وإضافة أول إيداع بواسطة Hexo: hexo generate && hexo deploy أدخل معلومات الاستيثاق في GitHub عندما تطلب منك لبدء نقل الملفات. تبدو نتيجة تنفيذ الأمرين السابقين بعد نجاحه على النحو التالي: To https://github.com/username/hexo_static.git. * [new branch] master -> master Branch master set up to track remote branch master from https://github.com/username/hexo_static.git. INFO Deploy done: git الخطوة السادسة: إعداد Nginx يتميّز خادوم ويب Nginx في تقديم الملفات الثابتة للزوار، وهو ما يجعله اختيارا مناسبا لمدونتنا. نبدأ بإعداد Nginx لتقديم المدونة للزوار. ننشئ أولا مجلدات النظام التي سنطلب من Nginx استخدامها: sudo mkdir -p /var/www/hexo ثم نعطي للحساب الذي نستخدمه على أوبنتو ملكيةَ المجلد: sudo chown -R $USER:$USER /var/www/hexo نعدّل أذون المجلد على النحو التالي: sudo chmod -R 755 /var/www/hexo نفتح ملف الإعداد المبدئي لـNginx لتحريره: sudo nano /etc/nginx/sites-available/default نعدّل كلتة server في ملف الإعداد بحيث يصبح جذر المستند Document root يشير إلى المجلد الذي أنشأناه للتو: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /var/www/hexo; index index.html index.htm; احفظ الملف ثم أغلقه. يمكنك عند الحصول على اسم نطاق للمدونة تحرير هذا الملف وتحديد قيمة server_name بحيث تصبح اسمَ نطاقك. نعيد تشغيل Nginx لاعتماد التعديلات: sudo service nginx restart الخطوة السابعة: إنشاء خطافات Hooks في Git سنربط في هذه الخطوة مستودع hexo_static بمستودع Git آخر لنرسل عبره ملفات HTML إلى مجلد خادوم الويب. نبدأ بإنشاء مستودع Git فارغ الهدف منه توجيه محتوى المستودع hexo_static إلى مجلد خادوم الويب: git init --bare ~/hexo_bare أنشئ ملف خطاف جديدا داخل مجلد خطافات Git: nano ~/hexo_bare/hooks/post-receive أضف السطرين التاليين إلى الملف. نحدّد في الملف شجرة عمل Git التي تحوي الشفرة المصدرية ومجلد Git الذي يحوي الإعدادات، السجل وأمورا أخرى: #!/bin/bash git --work-tree=/var/www/hexo --git-dir=/home/$USER/hexo_bare checkout -f احفظ الملف ثم أغلقه. اجعل الملف post-receive قابلا للتنفيذ: chmod +x ~/hexo_bare/hooks/post-receive سنحتاج الآن لنسخ مستودع النشر hexo_static الذي أنشأناه في الخطوة الخامسة إلى الخادوم. تأكد من إبدال username في الأمر أدناه باسم حسابك في GitHub. git clone https://github.com/username/hexo_static.git ~/hexo_static انتقل إلى المجلد hexo_static: cd ~/hexo_static نضيف مستودع hexo_bare السابق على أنه مستودع بعيد باسم live: git remote add live ~/hexo_bare الخطوة الثامنة: إنشاء سكربت النشر يمكن باستخدام سكربت Shell قصير بدء كامل عملية النشر السابقة بدلا من أدائها يدويا. يعني هذا أننا لن نحتاج إلى تنفيذ أوامر Hexo الواحدة تلو الأخرى أو تشغيل خطّاف Git بأوامر متعدّدة. نعود إلى مجلد مدونة Hexo وننشء فيه ملفا للسكربت: cd ~/hexo_blog nano hexo_git_deploy.sh ألصق الشفرة التالية في الملف: #!/bin/bash hexo clean hexo generate hexo deploy ( cd ~/hexo_static ; git pull ; git push live master ) احفظ الملف ثم أغلقه. ينفذ السكربت أوامر Hexo التالية: أمر clean الذي يحذف الملفات المولَّدة سابقا من مجلد public. أمر generate الذي يولّد ملفات HTML انطلاقا من ملفات ماركداون ويضعها في مجلد public. أمر deploy الذي يُرسِل الملفات الموجودة في المجلد public إلى مستودع Git الذي عرّفناه سابقا في ملف الإعداد config.yml_. يشغّل السطر الأخير (cd ~/hexo_static ; git pull ; git push live master) خطاف Git ويحدّث مجلد المدونة على خادوم الويب بوضع ملفات HTML فيه. نجعل سكربت النشر قابلا للتنفيذ: chmod +x hexo_git_deploy.sh الخطوة التاسعة: تنفيذ سكربت النشر نفذ سكربت النشر السابق لاختبار كامل العملية: ./hexo_git_deploy.sh ستُطلب منك معلومات الاستيثاق أثناء إيداع الملفات في مستودع GitHub. انتظر اكتمال العملية ثم ألق نظرة على الملفات في المجلد var/www/hexo/: ls /var/www/hexo النتيجة: 2016 archives categories css fancybox index.html js tags تُظهر نتيجة الأمر أعلاه أن الملفات التي أنشأها Hexo نُقلت إلى مجلد خادوم الويب، يعني هذا أن بإمكانك تصفح المدونة بالذهاب إلى عنوان الخادوم http://your_server_ip/. يكفي تنفيذ السكربت hexo_git_deploy.sh مستقبلا لنشر التعديلات أو الإضافات على المدونة. تذكر أن تختبر التغييرات على خادوم Hexo الاختباري قبل نشرها. الخطوة العاشرة: اكتشاف نظام ملفات Hexo (اختيارية) يعتمد Hexo على ملفات للعمل عليها. ليس من الضروري تعديل هذه الملفات إلا أنه سيكون من الجيد معرفة دور كل واحد منها في نظام الملفات التابع لـHexo، فربما تحتاج لاستخدامه. يبدو مخطَّط الملفات والمجلدات على النحو التالي: ├── _config.yml ├── node_modules ├── package.json ├── scaffolds ├── source | └── _posts └── themes مجلد node_modules يخزّن Hexo في هذا المجلّد الوحدات التي تنزّلها بـ npm لاستخدامها في المدونة. بنهاية هذا الدرس لن توجد في هذا المجلد سوى الحزم التي نزلناها في الخطوة الأولى أو الحزم التي تأتي مضمَّنة في Hexo. على العموم لن تحتاج للتعديل على هذا المجلد. مجلد package.json يحوي ملف JSON هذا الإعدادات والإصدارات التي يستخدمها Hexo. الجأ لهذا الملف إن احتجت لتحديث الحزم يدويا، إرجاعها إلى إصدار أقدم Downgrade أو حذفها. لن تحتاج لتعديل هذا الملف على الأرجح إلا إذا حدث تعارض بين حزم Hexo وهو أمر غير شائع. مجلد scaffolds يستخدم Hexo القوالب الموجودة في هذا المجلد ليصيغ التدوينات وفقا لها. تأتي ثلاثة قوالب مبدئيا في الملف وهي draft (مسودة)، post (منشور) و page (صفحة). إن أردت استخدام قالب جديد فيجب وضعه هنا قبل الاستخدام. مجلد source توجد التدوينات المنشورة في مجلد فرعي من مجلد source، نفس الشيء ينطبق على المسودات. يوجد أغلب محتوى المدونة المكتوب بماركداون في هذا المجلد أو مجلد متفرع عنه. مجلد themes توضع قوالب المظهر Themes في هذا المجلد. تحوي أغلب القوالب على ملف config.yml_ خاص بها للاحتفاظ بإعدادات مخصّصة مثل تلك التي يعرّفها ملف الإعداد العام. استخدمنا خلال هذا الدليل القالب المبدئي في Hexo. خاتمة لم نتطرق في هذا الدرس للكثير مما يمكن تعلمه، إلا أنه يضع قاعدة متينة لإنشاء مدونة باستخدام Hexo. راجع التوثيق الرسمي لإطار العمل والذي يحوي الكثير من المعلومات الدقيقة إن أردت التعمق أكثر في البرنامج. الخطوة الموالية هي تخصيص المظهر ليناسب رغباتك في تطوير مدونة خاصة بك. ترجمة -وبتصرف- لمقال How to Create a Blog with Hexo On Ubuntu 14.04 لصاحبه C.J. Scarlett.

وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".