كيف تزيد من قوتك و إنتاجيتك ؟ (المجال البرمجي كتطبيقٍ عملي)

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

كيف يمكن إدارة المشاريع البرمجية الجماعية ؟

علي موقع Arabia I/O كان هناك تساؤلٌ تحت عنوان: "كيف يمكن إدارة المشاريع البرمجية الجماعية ؟"، يقول فيه صاحبه:

السلام عليكم :)

آمل أن الجميع بخير .. لدي سؤال، و هو "كيف يقوم فريق من المطورين بالعمل على مشروع معين بشكل مرتب و منظم؟، هل هناك أي طرق مفضلة يجب إتباعها؟، على سبيل المثال المشروع عبارة عن منتدى سيتم تطويره بـ استخدام PHP وربطه مع قاعدة بيانات MySql."

آمل أن يحدثنا أحد الخبراء ليستفيد الجميع، حتى نبدأ بعمل مشروع مع فريقنا الخاص بشكل منظم ومرتب. لو هناك نصائح لا تبخل علينا بها :)

تحياتي،،

فكانت إجابتي عليه كما يلي:

ما هي أفضل لغة برمجة ؟

علي موقع Arabia I/O كان هناك تساؤلٌ يقول فيه صاحبه: "ما هي أفضل لغة لبرمجة تطبيقات سطح المكتب ؟"، فكتبتُ إجابةً مُختصَرةً علي سؤاله تصلح للإجابة عن كل الأسئلة التي من عينة: "ما هي أفضل لغة برمجة لفعل كذا و كذا ؟"، أو حتي للإجابة علي السؤال الأعم و الأشمل: "ما هي أفضل لغة برمجة ؟".

و كان ردي كما يلي (مع تصرُّف بسيط للغاية):

المأساة الـNexusيـة !

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

تخصيص صفحتين لمدونة "أفكار علمية" علي فيسبوك و تويتر

كخطوة جديدة للفصل بين مدونتَيْ "أفكار" و "أفكار علمية" قمتُ اليوم بإنشاء صفحة خاصة بالمدونة العلمية علي الـfacebook:

و كذلك صفحة خاصة بها علي twitter:

Follow @sci_thoughts

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

و الفصل بين المدونتين كان (و لا يزال) أمراً هاماً للغاية بالنسبة لي؛ حتي لا أُجبِر أحداً علي قراءة مقالاتي الفكرية إن كان يختلف معي في الدين أو المذهب أو المنهج و يريد متابعة مقالاتي العلمية فقط، و بالتالي يجد القدرة علي متابعة المقالات العلمية علي المدونة الخاصة بها بدون تصديع رأسه بالبقية التي يختلف معي فيها. أو تكون له القدرة علي متابعة مقالاتي الفكرية دون المقالات العلمية إن لم يكن يرغب في متابعة تلك الأخيرة؛ لعدم ميله إلي مجال تخصصي أو لأي سببٍ آخر.

نشأة البرمجيات الحرة مفتوحة المصدر (6)

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

الجزء الأول:

http://abo-eyas.blogspot.com/2013/02/1.html

الجزء الثاني:

http://abo-eyas.blogspot.com/2013/03/2.html

الجزء الثالث:

http://abo-eyas.blogspot.com/2013/03/3.html

الجزء الرابع:

http://abo-eyas.blogspot.com/2013/07/4.html

الجزء الخامس:

http://abo-eyas.blogspot.com/2013/08/5.html

و أنصحكم بشدةٍ بقراءة تلك الأجزاء قبل قراءة هذا الجزء.

***

كيفية رفع مشاركاتك إلى مشروع مفتوح المصدر

في موقع Arabia i/o كان هناك تساؤلٌ تحت عنوان "كيف أستطيع رفع تغييراتي إلى مشروع مفتوح المصدر؟"، يقول فيه صاحبه:

الكثير من المشاريع المفتوحة المصدر توفر لك إمكانية الإطلاع على الشفرة و تنزيلها، و لكن سؤالي هو عن كيفية رفع التغييرات ؟

لنفترض أنني قمتُ بتعديلٍ على شفرة لينكس مثلاً: كيف أرفع التعديلات و أعرف أنه تم الموافقة عليها ؟ هل من برامج معينة أستخدمها ؟

فكانت إجابتي المُختصَرة عليه كما يلي:

عن إهمال google لـblogger

إهمال شركة google لتطوير منصة تدوين blogger أمرٌ مرعبٌ لي كمستخدمٍ نشطٍ لها؛ فربما يكون دليلاً علي أنها تمهد لقتلها كما فعلت مع خدماتٍ أخريات !، 

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

الإثبات عملياً

شاهدتُ منذ فترةٍ فيديو أعجبني للغاية عن تحدٍ أجرته شركة NeXT (التي أسسها "ستيف جوبز steve jobs" بعد أن ترك شركة apple في فترةٍ من الفترات)، التحدي الذي أقيم في أكتوبر من عام 1991م كان مسابقةً بين مبرمجٍ يعمل علي جهاز "NeXTstation color" من شركة NeXT و يستخدم بيئة البرمجة NeXTstep الخاصة بها، و مبرمجٍ يعمل علي جهاز "SPARC station 2GX" و يستخدم برمجيات OPEN WINDOW و DEV-GUIDE (و كل ذلك من إنتاج شركة sun). و تم تكليف الاثنين بعمل برنامجٍ تجاريٍ صغير نوعاً ما، مع إعطائهما مهلةً لمدة ثلاثة أيام لفعل ذلك.

دعايات خاطئة لـGNU/Linux

أنا من المستخدمين المحبين جداً لتوليفة "قِنو/لِينُكْس GNU/linux"، و أعتبر نفسي واحداً من المتحمسين له إلي حدٍ كبيرٍ جداً، خاصةً و أن العقلية العلمية لـ "لِينُوس تُرْفالدز linus torvalds" و هو مؤسس مشروع "نواة اللينُكْس linux kernel" تعجبني و تحيرني إلي حدٍ كبيرٍ جداً (أنا أعتبره أكبر شخصيةٍ تقنيةٍ تأثرتُ بها).

لكن كل ما فات لا يمنع من وجود الكثير من الملاحظات لديَّ حول الآلية التي يتم بها بناء كل عناصر النظام المختلفة، و كذلك الطريقة التي يتم بها جمعها و دعمها، و تتعدي انتقاداتي تلك الأمور لتصل إلي الدعايات الخاطئة التي تُتناقَل في العادة بين أوساط المتحمسين للـGNU/linux (سأشير لهذه التوليفة فيما يلي من كلامٍ باسم "لِينُكْس" فقط) بشكلٍ عامٍ و يُحاوِلون بها استمالة مستخدمي الـwindows و الـmac لعالم البرمجيات الحرة free software بالكامل.

و سأتحدث هنا عن اثنتين من تلك الدعايات الخاطئة التي ينشرها محبو اللينُكْس سواءاً أكانوا يعلمون أنها غير حقيقيةٍ أو كانوا لا ينتبهون إلي ما فيها من مُجافاة الواقع:

الترجمة الجزئية

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

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

الشكل الأقدم للأحداث و متعهداتهن events and events handling في إبداع و أسباب تغييره

مقدمة

هذا المقال يُعتبَر تكملةً لمقالٍ سابقٍ كتبتُه عن الطرق المُختلفة لدعم "الأحداث events" و "مُتعهِّداتها events handlers" في بعض لغات البرمجة (أعني بهن الـ: java و visual basic.net و #C)، ثم قارنتُ حينها بين كل تلك الطرق و بين الطريقة التي يتم بها الدعم حالياً في إبداع؛ بغرض البرهنة علي قوة و بساطة قواعد الأخيرة التي قد لا تظهر عند التأمل البسيط.

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

الوراثة الجزئية partial inheritance

الوراثة الجزئية partial inheritance

المفهوم، المميزات، العيوب

المفهوم و المميزات

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

و أثناء تلك الفترات التي كانت تتغير فيها قَناعاتي وجدتُ أن هناك بعض المُكوِّنات (أعني: قواعد و تعبيرات) كنتُ مقتنعاً بأهميتها في الأشكال القديمة من إبداع، و لكن بعد التفكير الجيد فيها وجدتُ أنه من الأفضل ألا يتم ضمها إلي اللغة في نسختها النهائية.

و كان من بين تلك المُكوِّنات التي تم التخلي عنها ما أطلقتُ عليه اسم "الوراثة الجزئية partial inheritance" أو "الوراثة الناقصة incomplete inheritance"، و هو نوعٌ من أنواع الوراثة في البرمجة الكائنية object oriented يبدو غريباً للغاية عند شرحه (كما سترون فيما يلي من توضيح بمشيئة الله تعالي).

نشأة البرمجيات الحرة مفتوحة المصدر (5)

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

الجزء الأول:

http://abo-eyas.blogspot.com/2013/02/1.html

الجزء الثاني:

http://abo-eyas.blogspot.com/2013/03/2.html

الجزء الثالث:

http://abo-eyas.blogspot.com/2013/03/3.html

الجزء الرابع:

http://abo-eyas.blogspot.com/2013/07/4.html

و أنصحكم بشدةٍ بقراءة الأجزاء السابقة قبل قراءة هذا الجزء؛ حتي تستطيعوا استيعاب الأمور كما يجب، و حتي تعتادوا علي طريقتي في الحكي و الترجمات التي أقدمها للمصطلحات التقنية الإنقليزية :)

نشأة البرمجيات مفتوحة المصدر (4)

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

التعلم بالتجريب

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

أيهما أنسب للمبتدئين: #C أم java ؟

سألني أحد الإخوة الأفاضل السؤال التالي (ببعض التصرف):

السلام عليكم، 

هناك شئٌ يُحيرني بشدة: فقد اشتركتُ في دورة microsoft الخاصة بالمدارس الثانوية، و هذه الدورة في لغة #C و بعض تقنيات الـNET. الخاصة بـmicrosoft، و لا أعرف هل أُكمِل هذه الدورة أم لا؛ أقصد هل أتعلَّم لغةً مغلقة المصدر من microsoft أم أتحول الي لغةٍ مفتوحة المصدر كـjava.

و كان ردي المُختصَر عليه كما يلي (ببعض التصرف):

طرقٌ مختلفةٌ لدعم الأحداث events و مُتعهِّداتها events handlers

في لغات البرمجة هناك مفهومان هامان للغاية هما: الأحداث events و مُتعهِّدات الأحداث events handlers؛ و يُقصَد بالحدث "وقوع أمرٍ ما يحتاج لاتخاذ رد فعلٍ مناسبٍ تجاهه"، و مُتعهِّد الحدث هو "رد الفعل الذي يرغب المبرمج في تنفيذه عند وقوع حدثٍ معين"، 
و تزداد أهمية الأحداث و مُتعهِّداتها أضعافاً مُضاعفةً حينما يأتي ذِكر برمجة الواجهات الرسومية graphical user interfaces لما تلعبانه من دورٍ مِحوريٍ في تسهيل بنائها؛ فالحاجة إليهن ماسَّةٌ نظراً لأن الفكرة الرئيسة من وراء الواجهات الرسومية هي القدرة علي اتخاذ ردود أفعالٍ معينةٍ عند حدوث شيءٍ معين، مثل عرض رسالةٍ حينما يضغط المستخدم علي زرٍ معين، أو إغلاق البرنامج حينما يضغط المستخدم علي زر x الموجود في الواجهة الرئيسة لذلك البرنامج.

و عملياً فإن هناك طرقٌ عديدةٌ لبناء مفهومَيْ الأحداث و مُتعهِّداتها في لغات البرمجة، و هنا سأقدم مجموعةً صغيرةً للغاية منهن، ثم سأتحدث عن الطريقة التي تم بها الاستغناء عنهن في إبداع بشكلٍ بسيطٍ جداً و قوي للغاية. 
إلا أنه ينبغي التنبه إلي كون الشرح الموجود هنا مُختصَرٌ بشكلٍ كبير، و يحتاج كذلك لمعرفةٍ جيدةٍ ببعض قواعد لغات الـ: java و #C و visual basic .NET و إبداع. و ربما يتسبب هذا في غموض بعض النقاط و الحاجة إلي القراءة المستفيضة فيهن حتي يتم استيعابهن. و لم أستطع الإسهاب في الشرح حتي لا يزداد حجم المقال إلي ما لا يُطاق.

أنظمة تشغيل قوية، و لكن غير مشهورة

يظن كثيرٌ من مستخدمي الحواسيب أن أنظمة التشغيل القوية للحواسيب الشخصية لا تتعدي الأنظمة الشهيرة المتمثلة في الـwindows و الـmac و الـGNU/linux (يُختصَر إلي linux)، بل و ربما لا يعلم أغلب الناس شيئاً عن نظام الـGNU/linux و/أو نظام الـmac شيئاً !، و في عالم أنظمة تشغيل الأجهزة الذكية (كالهواتف الذكية smart phones و الأجهزة اللوحية tablets) فإن معرفة الأغلبية لا تتعدي نظامَيْ الـandroid (إذا ما اعتبرناه نظاماً قائماً بذاته و ليس مجرد توزيعة من الـlinux) و الـios.

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

نشأة البرمجيات مفتوحة المصدر (3)

في البداية دعونا نتفق علي شيءٍ شديد الأهمية: لو لم يستطع محبو البرمجيات الحرة اختراق عالم المال و التجارة عن طريق البرمجيات الحرة فما كانوا ليستطيعوا الصمود طويلاً في وجه منافسيهم؛ فالعالم التجاري معناه تدفق الأموال التي ستدعم المشاريع الحرة، و بالتالي يستطيع المُشارِكون فيها أن يتفرغوا تماماً لعملية التطوير، و كذلك تعني القدرة علي عمل الدعاية الكافية لجمع المزيد من أهل الخبرة للاشتراك في بناء برمجياتهم الحرة و تطويرها (سواءً كهوايةٍ أو كعملٍ ينالون عليه أجراً).

هنا نتساءل: هل تنبه ستولمان لهذه النقطة حينما بدأ الدعوة لحركته الجديدة ؟
و الجواب أن ستولمان كان "حويطاً" بالفعل، و تنبه لهذه النقطة و تحدث عنها و عن كيفية الاستفادة من البرمجيات الحرة في المجال التجاري، حيث أنه في خاتمة "بيان قِنُو  GNU manifesto" كان هناك فصلٌ يتحدث عن هذه المسألة بالتحديد، و قد استرعي هذا الأمر انتباه البعض من محبي البرمجيات الحرة و دفعهم إلي أن يُمحِّصوا الأمر جيداً، ثم تركَّز فكرهم علي أمرٍ معينٍ يمكن به الاستفادة من التمدد المتسع لها (و علي رأسها توليفة "قنو/لينوكس")، لذا قام John Gilmore  و Michael Tiemann  و David Henkel-Wallace في عام 1989م ببناء شركةٍ تقوم بأعمال الصيانة و الاستشارة فيما يخص البرمجيات الحرة، لخدمة الشركات التي ترغب في الحصول علي مثل تلك الخدمات (و كان اسم شركتهم الجديدة "cygnus"، و يحتوي علي كلمة gnu داخله لأنهم حرصوا علي هذا عند اختيار الاسم)،

فحيث أن البرمجيات الحرة ليس لها مالكٌ بالمعني المُتعارف عليه في العالم التجاري، و حيث أنه في الشركات التي تستخدم البرمجيات الحرة سيكون تخصيص قِسمٍ للصيانة و المُتابعة لكل البرمجيات غير ممكنٍ عملياً: فقد أدي هذا إلي سهولة وجود منافسةٍ في خدمات الصيانة و الاستشارة، علي العكس من عالم البرمجيات المغلقة المصدر؛ حيث أنه في الحالة الأخيرة لا يمكن الحصول علي دعمٍ فنيٍ قويٍ إلا من الشركة المالكة، و من السخرية أن الشركات المالكة للبرمجيات الشهيرة قد تكون خدمة العملاء و الصيانة بها سيئةً للغاية؛ نظراً لعدم قدرتها علي تلبية احتياجات القاعدة الواسعة جداً من مستخدمي برمجياتها !
المهم أنه بوجود شركة cygnus علي الساحة أصبح من الممكن لكثيرٍ من الشركات أن تعتمد علي البرمجيات الحرة في عملها، مطمئنةً إلي وجود من يمكنه تقديم الدعم الفني لها إذا رغبت في ذلك. و كانت هذه خطوةً هامةً للغاية في تاريخ البرمجيات الحرة.

كانت الدفعة العملاقة الأخري لتوليفة القِنُو/لِينُوكس هي ظهور شبكة الإنترنت للعامة و انتشارها الواسع، و ظهور برنامج "خادم إنترنت أباتشي apache web server" لنظام اليُنِكس و شبيهاته (أعني الأنظمة التي تُوصف بأنها unix-like و من ضمنها القِنُو/لِينُكْس)؛ فنظراً لتفوق خادم الأباتشي علي منافسيه و احتلاله لعرش فئته من البرمجيات: فقد أصبح استخدام توليفة "أباتشي/قِنُو/لِينُكْس" هو الخيار المفضل لمن يرغب في بناء شركة استضافةٍ علي الإنترنت بدلاً من توليفة "IIS/windows"؛ و ذلك بسبب الفرق في القوة و الاستقرار و الأمن بين التوليفتين، بالإضافة إلي فارق السعر بطبيعة الحال. 

 

و ظهرت توليفةٌ جديدةٌ من البرمجيات تُسمَّي LAMP، و هي حزمةٌ لتطوير التطبيقات للشبكة تحتوي علي:

• توليفة برمجيات قِنُو/ لِينُكْس،

• خادم أباتشي،

• قاعدة البيانات MySQL،

• لغات البرمجة PHP و perl و python،

و هكذا وجدنا أن اللينُكْس ينتشر في سوق خوادم الإنترنت مثل انتشار النار في الهشيم. 

 

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

(معني كلمة "توزيعة": أي نظام تشغيلٍ يتكون من نواة اللينُكْس + أدوات مشروع قِنُو + واجهة مرئية للمستخدم (النوافذ و الأزرار و ما يشبههن) + بعض الأدوات و البرمجيات الخاصة بالتوزيعة لتنصيبها و التحكم في إعداداتها. أي أنها تجميعةٌ من البرمجيات الحرة التي تُكون مع بعضها البعض نظام تشغيلٍ متكامل).

 

و بالفعل قام كلٌ من  Bob Young و Marc Ewing ببناء شركة رِدْهات redhat  في عام 1993م لتصبح من أوائل الشركات التي تستثمر في مجال تقديم توزيعاتٍ متكاملةٍ متناغمةٍ من البرمجيات الحرة و من أكبرها حجماً و قوة.
و في 15 نوفمبر من عام 1999 قامت رِدْهات بالاستحواذ علي شركة cygnus سالفة الذِكر، و أصبح Michael Tiemann يشغل منصب chief technical officer في شركة Red Hat، و في عام 2008  أصبح يشغل منصب "نائب الرئيس لشؤون المصادر المفتوحة the vice president of open source affairs".

كل تلك الخطوات الضخمة علي الطريق التجاري لتوليفة الـGNU/linux كانت رداً عملياً قاسياً علي انتقادات "بِلْ قِيتس bill gates" لمن يُهاجِم النموذج التجاري للبرمجيات الذي يمكن رؤيته في شركة مايكروسوفت علي سبيل المثال؛ ففي 31 يناير من عام 1976 وجَّه بِلْ خطاباً مفتوحاً لـ homebrew computer club (و هو تجمعٌ لمحبي الحواسيب في وادي السيليكون بالولايات المتحدة، و قد أُنشِيء في منتصف سبعينيات القرن الماضي)، و تحدث بِلْ في ذلك الخطاب عن أفضلية البرمجيات المغلقة علي الحرة، و  استنكر إمكانية وجود فريقٍ من المبرمجين يعمل لعدة سنواتٍ علي مشروعٍ برمجيٍ، ثم يقوم يتوثيقه بعناية، ثم يقوم بطرحه للاستخدام العام مجاناً.
و بذلك قدم النتيجة النهائية التي أراد الوصول لها، و هي أن البرمجيات الحرة "ضارةٌ بالمجتمع البرمجي"، و أن البرمجيات المغلقة هي الأمل في وجود برمجياتٍ متميزةٍ تلبي حاجة المستخدمين الذين يحتاجون إلي برمجياتٍ قويةٍ و كفؤة.

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

نشأة البرمجيات مفتوحة المصدر (2)

هناك معلومةٌ لا بُد مِن ذِكرها ما دمنا أردنا أن نتحدث عن علاقة الأستاذ الجامعي الأمريكي "أَنْدرُو تانِنْبُوم" بحركة البرمجيات الحرة، فقد طلب ستولمان أن يستخدم مُترجِم الـC الذي كتبه تانِنْبُوم (مع  Ceriel Jacobs) من قبل لنظام التشغيل الخفيف "مِنِكْس minix"، و لكن تانِنْبُوم أخبره أن المُترجِم ليس حراً (في عام 2003 أصبح ذلك المُترجِم حراً تحت ترخيص BSD). 
و هكذا لم يجد ستولمان مهرباً من بناء مُترجِمٍ خاصٍ بالـC من الصفر، صحيحٌ أنه قبل قراره هذا حاول كتابة نهايةٍ أماميةِ front end للغة الـC في المُترجِم الخاص بمعمل "Lawrence Livermore" إلا أنه فوجئ أن تشغيلها يتطلب ذاكرةً أكبر مما كان مُتاحاً في حواسيب ذلك الزمن، لذا فقد نحَّاها جانباً و بدأ بناء الـgcc من الصفر كما أسلفنا القول. و فيما بعد صار بالإمكان استخدام تلك الواجهة الأمامية المهجورة بعدما تطورت إمكانيات الحواسيب عمَّا كانت عليه قبلاً.

الآن تعالوا نقفز في الزمن من بداية الثمانينيات إلي بداية التسعينيات؛ ففي تلك السنوات دخل إلي المباراة لاعبٌ شديد الأهمية هو الطالب الفنلندي "لينُوس تُرْفالدز linus torvalds"، الذي كان حينها قد انتقل إلي العام الثاني في جامعة هلسنكي. كان لينوس طالباً عادياً جداً في كل شيء و هو من الأقلية السويدية التي تعيش في فنلندا، إلا أنه كان يتميز بميزةٍ شديدة الأهمية هي حب التعلم عن طريق التجربة باليد، فمثلاً حينما كان يريد تعلم صنع محرك رسوميات graphics engine قام بعمل لعبةٍ خاصةٍ به (رغم أنه سيءٌ في اللعب !). و حينما كان يستهويه تعلم جزئيةٍ معينةٍ في العتاد الخاص بحاسوبه: كان يكتب برنامجاً يجرب به تلك الخاصية و يتعامل معها باستخدامه.

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

لذلك فحينما أحس لِينُوس بأنه يحتاج نظام تشغيلٍ جديداً يشبه اليُنِكْس علي حاسوبه الشخصي، و حينما لم يستطع شراء نسخةٍ من اليُنِكْس، و حينما وجد أن نظام المِنِكْس minix لا يلبي كافة احتياجاته، و حينما قام (بالخطأ) بإزالة المِنِكْس من حاسوبه: حينها قرر إكمال العمل علي بناء نواة نظام تشغيلٍ يستنسخ اليُنِكْس من الصفر !
الأمر بالطبع أكثر تعقيداً من مجرد "حاجته لنظام تشغيل ثم تقريره أنه سيبنيه بنفسه"، فالحق أنه كان قد بدأ العمل علي أساسيات النواة kernel منذ فترةٍ سابقة، لكن يمكنك دوماً أن تقول هذا و لن تكون مخطئاً بنسبةٍ كبيرة.

في نفس التوقيت كانت مؤسسة الـfsf قد بَنَت كثيراً من البرمجيات التي تحتاجها، فقد أصبح لديهم مُترجِم الـgcc، و مُحرر الـgnu emacs الشهير، و مجموعةٌ أخري من البرمجيات، و بما أنها كانت ذات عددٍ كبيرٍ فقد أدي ذلك إلي أنهم لم يستطيعوا بناء النواة الخاصة بنظام تشغيل gnu في نفس الوقت، و هي النواة المُسمَّاة hurd.

و علي الرغم من ذلك اعتاد عددٌ كبيرٌ من الناس علي تحميل برمجياتهم تلك (و علي الأخص مُترجِم الـgcc) و استعمالها علي عددٍ من أنظمة التشغيل، و حينما احتاج عددٌ من هؤلاء المستخدمين لنظام تشغيلٍ حرٍ بالكامل: قاموا ببساطةٍ بتنصيب نواة اللينُكْس و فوقها أدوات مشروع قِنُو علي حواسيبهم، و هكذا صار لديهم نظام تشغيلٍ متكاملٍ قبل أن تعرف مؤسسة الـfsf شيئاً عن نواة اللينُكْس من الأساس.

كان من الممكن ألا يشتهر اللينُكْس و ينضم إلي تطويره كل من انضم إليه لو أن نظام الـBSD كان حراً بالمثل، ففي تلك الفترة كان نظام التشغيل المُسمَّي Berkeley Software Distribution  أو اختصاراً "BSD" مثل الجمل الأجرب؛ فقد كانت هناك منازعاتٌ قانوينةٌ عليه جعلت الجميع يفر من المشاركة في تطويره أو الاعتماد عليه بالكامل لأنه لا أحد يدري ماذا ستؤول إليه حكايته، و ماذا سيكون مصيره فيما بعد و هو الأمر الذي يخضع لقرار المحكمة أولاً، ثم لقرار من ستحكم له المحكمة بالأحقية في التحكم في مصير الـBSD.

و هكذا كانت الساحة مهيأةً مئةً في المئة للفنلندي الواثق، الواقع يقول أنه في البداية واجه لِينُوس مصاعباً كبيرة، فمثلاً دخل البروفيسور أَنْدرُو تانِنْبُوم للساحة مرةً أخري ليؤكد أنك لو نظرتَ في كوب الشاي الذي تشربه لرأيته هناك!، و قد كان دخوله هذه المرة عنيفاً كثيراً؛ فقد نشر مقالاً علمياً علي مجموعة الأخبار comp.os.minix تحت عنوان "لِينُكْس عفا عليه الزمن Linux is obsolete"، و الذي قام فيه (بمنتهي الروح الأبوية) باتهام تصميم اللينُكْس بكل التهم التي استطاع التوصل إليها؛ فقد قال أن:النواة من نوع  monolithic و بالتالي فهي من الطراز القديم، بينما يري أن التصميم الأفضل هو النُواة المُصغَّرة microkernel كما في نظام المِنِكْس،

• ضعف المحمولية portability، و هو ما نتج عن استعمال خصائص خاصة بمُعالِج Intel 386 في أكواد نواة اللينُكْس، 
• ليس هناك تحكمٌ قويٌ لشخصٍ واحدٍ في الكود المصدري،
• هناك خصائصٌ موجودةٌ في اللينُكْس لا لازمة لها مطلقاً (من وجهة نظر تانِنْبُوم) مثل الـmultithreaded file systems.

 و أدي هذا إلي نشوب صراعٍ محتدمٍ شهيرٍ بين لِينُوس و تانِنْبُوم دافع فيه كلٌ منها عن وجهة نظره (و أنا أثق انها كانت حرباً ضروسا؛ لأن لِينُوس لا ينقصه لا الثقة في النفس و لا اللسان الطويل، كما أن تانِنْبُوم أطلق كل ما وجده في يده من رصاصٍ علميٍ علي اللينُكْس!)، لكن الواقع يقول أن اعتراضات تانِنْبُوم سالفة الذِكر إما ثبت عملياً أنها غير قوية أو أنها أكاديميةٌ متحذلقةٌ بعض الشيء، أو تم التغلب عليها بالتدريج بعد نضج نواة اللينُكْس، أو ثبت أنها كانت خاطئةً علي طول الخط. و الواقع أن مشروع اللينُكْس كان مُصادِماً لكثيرٍ من القواعد البرمجية حتي في علم هندسة البرمجيات و كيفية بناء المشاريع البرمجية الضخمة !

 ***

 بعد فترةٍ من انتشار فكرة البرمجيات الحرة و انتشار استخدام توليفة الـGNU/linux، و بعد ازدياد أعداد المعتمدين عليها من المستخدمين بما يبشر بإمكانية فتح أسواقٍ جديدةٍ للاستثمار فيها: بدأ بعض أنصار البرمجيات الحرة في التنبه إلي أن كلمة free في اللغة الإنقليزية تحمل معني "حر" و معني "مجاني"، و هو ما قد يؤدي إلي نفور المستثمرين في مجال البرمجيات من استثمار أموالهم فيما يخص البرمجيات الحرة. 
لهذا السبب فكروا في استخدام الاسم "البرمجيات مفتوحة المصدر open source software"  بدلاً من الاسم القديم "البرمجيات الحرة free software"، مع الإبقاء علي المقومات الأساسية كما هي، أي أن الأمر (كما كان يبدو) لا يعدو مجرد إعادة تسمية.

 لكن هذا الأمر لم يُعجِب ستولمان بطبيعة الحال؛ حيث رأي أن مشكلة الاسم يمكن حلها عن طريق كتابة جملة "free as in freedom" لكي تشرح أن كلمة free مأخوذةٌ من  "الحرية" و ليس "المجانية"، و رأي ستولمان أن حركة المصادر المفتوحة تركز علي الجانب المادي و تُغفِل الجانب الاجتماعي و الأخلاقي لحركة البرمجيات الحرة.

و بصراحةٍ شديدةٍ فإنني شخصياً أجد أن هناك بالفعل اختلافاً بين حركتَيْ البرمجيات الحرة و المصادر المفتوحة أكبر من مجرد الاهتمام بالجذب الاستثماري؛ فنشطاء المصادر المفتوحة يرون أنه بالإمكان أن يكون هناك نوعٌ من التعايش بين البرمجيات الحرة أو "مفتوحة المصدر" و بين البرمجيات المُغلََقة المصدر أو "الاحتكارية" أو "الاستئثارية" (سمِّها كما تشاء)، بينما تصب مباديء و كلمات أنصار البرمجيات الحرة في خانة أن النوع الاستئثاري من البرمجيات هو "نِتاجٌ شيطاني" يجب التخلص منه لصالح البشرية و لكي يسترد البشر آدميتهم (و قد رأينا هذا في حملاتهم ضد نظام تشغيل microsoft windows 7).

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

أنا مشهورٌ بأنني لستُ عاشقاًً للـfsf و ريتشارد ستولمان، علي الرغم من أن الواضح أنني أحب الـGPLv2 و أستخدمها كرخصةٍ لكل مشاريعي التي أهتم بشأنها.
السبب كان دوماً أنني لا أحب رجال "الفكرة الواحدة"، و لا أظن الأشخاص الذين يُحوِّلون العالم إلي "أبيض و أسود" لطفاء جداً أو شديدي الفائدة. الحقيقة أنه ليس هناك وجهان فقط لكل قضية؛ فتقريباً هناك دائماً تدرج، و غالباً فإن الإجابة الصحيحة لأي سؤالٍ عميقٍ هي "عَلَي حسب"، و ليس حتي أن تأمل في اتخاذ الطرف الآخر لقراراتٍ خاطئة.
لا تفهموني خطأً: أنا أحب أن أري أناساً شغوفين بما يفعلونه، و كثيرٌ من الناس لديهم شيءٌ ما يهتمون بأمره جداً. لكن فقط حينما يتحول هذا إلي منهجٍ إقصائيٍ فإنه غالباً ما يصبح قبيحاً. لا يكون الأمر "حباً لشيءٍ ما" بل يصبح "كرهاًً لشيءٍ ما".
كمثالٍ: فإن هذا واحداً من أسباب محاولتي لتلافي التحدث عن مايكروسوفت كثيراً؛ أنا شغوفٌ باللينُكْس جداً (كما هو واضح)، لكن بصراحةٍ شديدةٍ فإنني أجد أن التفكير في اللينُكْس علي أنه "ضد مايكروسوفت" سخيفاً و خطأً في التوجه؛ نعم ربما أُلقِي طُرفةً أو اثنتين بـ"لسان زالف"، لكن حقاً هل هناك أحدٌ يفكر بجديةٍ أنه من الممكن أن تنفق 17 عاماً من عمرك و تأخذ قراراتٍ صحيحةً بناءاً علي الكره و الخوف ؟!
كان هذا أيضاً (و لا يزال) سبب كرهي للـGPLv3، أظن أن العديد من التغييرات لم تكن نتيجةً لـ"تأييد البرمجيات الحرة"، لكن بشكلٍ أكبر كرد فعلٍ طائشٍ ضد أشياء مثل TIVO، و منهجية "أبيض-أسود" و "خير-شر".

 

يُتبَع
--------------------------------------
* http://torvalds-family.blogspot.com/2008/11/black-and-white.html



نُشِر هذا المقال علي موقع (صدي التقنية) علي الرابط:
http://tech-echo.com/2013/03/beginning-of-open-source-software-2/

مُلخَّص ندوة "البرمجيات الحرة: توضيحٌ، تأريخٌ، أمثلة"

البارحة كنتُ في هندسة أسوان و ألقيتُ المحاضرة التي كانت تحت عنوان "البرمجيات الحرة: توضيحٌ، تأريخٌ، أمثلة". و رغم أن عدد الحضور كان للأسف قليلاً جداً (من عشرة إلي خمسة عشر) إلا أنني أُفضِّل العدد القليل المُنتبِه المُتفاعِل علي العدد الكبير الذي لا يسره شيءٌ قدر الانتهاء من الملل الذي يُسببه لهم المُحاضِر.

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

و ها هو ذا العرض البسيط الذي استعنتُ به يومها لتحميله إذا رغبتم في هذا (مع تعديلاتٍ طفيفةٍ جداً):

  

 

أهم ما أنصح به "فرع الـIEEE للطلاب في أسوان" هو ألا يستسلموا لليأس مطلقاً، و أن يحاولوا قدر الاستطاعة؛ فالصبر كفيلٌ بإيصالهم إلي مبتغاهم بإذن الله تعالي. صحيحٌ أن الجو المحيط سيءٌ للغاية من حيث عدم الإقبال من جانب الطلبة، و كذلك عدم التعاون الكافي من المسؤولين، إلا أن القاعدة التي تُرِيح دائماً في مثل تلك المواقف تقول "عليك بالعمل و ليس عليك النتائج".

و أرجو الله عز و جل أن يوفقهم و من هو مثلهم.

نشأة البرمجيات مفتوحة المصدر (1)

هذا هو أول مقالٍ لي في سلسلة مقالاتٍ تتحدث عن (نشأة البرمجيات مفتوحة المصدر)، و قد تم نشره في موقع (صدي التقنية) علي الرابط:
http://tech-echo.com/2013/02/beginning-of-open-source-software/

 ***

 
في الآونة الأخيرة ازدادت شهرة ما يُعرف بالبرمجيات الحرة free software و البرمجيات المفتوحة المصدر open source software في العالم العربي، تزايد الشهرة في هذه الأيام لا يعني أن هذين النوعين من البرمجيات لم ينشآ إلا في الفترة الحالية، و لا يعني كذلك أنهما لم يكونا معروفين للمهتمين بالتقنيات الحاسوبية منذ فترةٍ طويلة، بل يعني فقط أن انتشار الاهتمام بهما بين القاعدة العريضة من التقنيين العرب ازداد مؤخراً، و نري هذا واضحاً في ازدياد المتابعين للمواقع التي تقدم أخبار تلك التقنيات، و كذلك في اهتمام الذين لا يستخدمونهما من الأصل؛ بسبب رغبتهم في زيادة ثقافتهم الحاسوبية، أو حتي فتح آفاقٍ جديدةٍ في العمل.

السؤال هنا: ما هي المصادر المفتوحة، و ما هي البرمجيات الحرة، و هل هناك فارقٌ فعليٌ بينهما ؟

للإجابة عن هذا السؤال يجب علينا أن نفهم كثيراً من الأمور في نشأة عالم البرمجيات، و لذا سنعود بالزمن للوراء حتي بدايات تاريخ الحوسبة computing history نفسه، حينها كانت برمجيات الحاسوب عبارة عن برمجياتٍ صغيرةٍ وظيفتها الأساسية هي "خدمة الآلة باهظة الثمن"، أي أن الشيء الأكثر أهميةً كان هو جهاز الحاسوب مرتفع الثمن، أما البرمجيات فقد كانت شيئاً ثانوياً عند حساب الربح و الخسارة. لذلك لم يكن هناك من يفكر في "بيع" البرمجيات، إنما كان الكل يبيع "أجهزة حاسوبٍ بها برمجياتٌ سابقة التنصيب".
و نظراً لأن البرمجيات لم تكن ذات أهميةٍ كبري من الناحية المادية لذا كان يتم التعامل معها بمنتهي الحرية، فكان المبرمجون ينشرون أكواد برمجياتهم بكل أريحية، و يستطيع المبرمج أن يغير الأكواد التي علي آلته إذا ما توافرت له القدرة العملية علي ذلك و الرغبة فيه.

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

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

و لكن قبل أن نتحدث عن تلك الخطوة الفارقة تعالوا نتحدث عن شخصٍ يسمَّي ريتشارد ماثيو ستولمان richard matthew stallman أولاً؛ فهو من أكثر الشخصيات تأثيراً علي عالم البرمجيات الحرة ذي الصبغة القانونية و الفلسفية، كما أنه من أكثر الشخصيات إثارةً للجدل سواءٌ في عالم البرمجيات الحرة أو في عالم البرمجيات المُغلَقة المصدر (الاستئثارية-الاحتكارية) !

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

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

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

الصدمة التي حدثت لستولمان مع عددٍ كبيرٍ من التقنيين الآخرين كانت ما حدث مع نظام اليُنِكْس؛ و اليُنِكْس هو نظام تشغيلٍ متطورٍ كانت له قصة النشوء التالية:
فى منتصف الستينيات تعاونت (جنرال إليكتريك general electric) و (معامل بِلْ bell laboratories التي تغيَّر اسمها فيما بعد ليصبح AT&T) و (معهد MIT للتقنية) لإنتاج نظام تشغيلٍ يُسمَّي MULTICS، و هو  اختصارٌ لاسم (multiplexed Information Computing System). و يتميز بالعديد من القدرات القوية مثل تعدد المهام multi-tasking و تعدد المستخدمين multi-users و إداره ملفاتٍ متعددة المستويات multi-level file management  و غيرهن من القدرات. لكن AT&T انسحبت من المشروع في نهاية الأمر.
إلا أنه في عام 1969 قام كِنْ ثومبسون Ken Thompson  مع دِنِس رِتْشى Dennis Ritchie  و عددٍ آخرٍ من المبرمجين الذين كانوا قد عملوا فى مشروع MULTICS باستئناف العمل فى AT&T لإنتاج نظام تشغيل مماثلٍ خاصٍ بهم، بحيث يعمل على أجهزةٍ من نوع minicomputer، وفي 1 يناير 1970 تم تشغيل أول إصدارات اليُنِكْس.

و في بداية الأمر كانت AT&T قد جعلت اليُنِكْس منتجاً بحثياً research product بإمكان الجميع أن يستخدموه فى أبحاثهم و يطوروا فيه على أن تظل الملكيه لـAT&T،  و منذ ساعتها انتشر يُنِكْس انتشار النار في الهشيم بين الجامعات و الشركات المختلفة، إلا أن تغير نظرة الشركات للبرمجيات جعل الأمور تتغير تماماً فيما بعد. و في عام 1983 و حينما وصلت نسخةٌ من إصدارة system3 إلي ستولمان لم يجد الكود المصدري الخاص بها معها، رغم أنه كما قلنا أن المعتاد كان العكس تماماً، و الأغرب أنه حينما حاول أن يحصل عليه فوجيء أنه لا يمكن ذلك إلا إذا وقَّع على اتفاقية عدم الكشف (Non-Disclosure Agreement) أو (NDA)  اختصاراً،  و هو الأمر الذى يجعل من حصوله على الكود عديم القيمة. كأنك تضع أحدهم في معركةٍ طاحنة مع مسدسٍ سريع الطلقات و لكن في نفس الوقت تشترط عليه أن يعيد لك المسدس و الطلقات بنفس عددها الأول !

المصيبة الكبري كانت أن نظام اليُنِكْس كما ذكرتُ من قبل رغم أن علامته التجارية كانت ساعتها ملكاً لشركة AT&T إلا أن الواقع أن الجامعات المختلفة و المبرمجين في الشركات و في المعاهد التقنية المتنوعة كانوا قد أسهموا بشكلٍ كبيرٍ في تطويره، و هكذا لم تكن الخطوة الأخيرة التي قامت بها AT&T إلا ضربةً تحت الحزام ! و في النهاية لا يمكنك الاعتراض بشكلٍ قانونيٍ لأن "العلامة التجارية كانت ملكاً لـAT&T فقط".

هنا و بعد كل لتلك الصدمات المتواليات قرر ستولمان أنه "ما حك جلدك مثل ظفرك ... فتولَّ أنت جميع أمرك".
أنا عن نفسي كنتُ سأقضي ربع ساعةٍ من الصراخ و ركل الأرض بقدمي و ربما أُطلِق بعض السباب كذلك، و من الممكن أن أكتب رسالةً بذيئةً لقيادات AT&T و أوقعها باسمٍ زائف، لكني في كل الأحوال بعد فعل ذلك كنتُ سأخرس كأفراس النهر تماماً.

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

و بما أن أول البرمجيات التي يحتاجها الحاسوب لكي يعمل هو نظام التشغيل operating system، فقد قرر ستولمان أنه سيكتب نظام تشغيلٍ حر يستطيع الناس استخدامه كبديلٍ لأنظمة التشغيل الاحتكارية.
اختار ستولمان أن يكون نظامه الجديد مشابهاً لنظام اليُنِكْس unix لأسبابٍ لا أعلمها جيداً، ربما كان السر في ذلك هو انه كتب برامجاً لليُنِكْس و يريد تشغيلها علي نظامه الجديد دون التغيير في أكوادها، أو ربما لأنه هو و المبرمجين الآخرين يعلمون الكثير بالفعل عن اليُنِكْس من خلال احتكاكهم السابق به، و بالتالي يصير من السهل تعاملهم مع المشروع الجديد كمطورين أو مستخدمين، أو ربما لأنه رأي أن تصميم اليُنِكْس تصميمٌ رائعٌ و سهل البناء، و ربما كان كل ما فات صحيحاً.

المهم أنه اختار أن يكون نظامه الجديد مشابهاً لليُنِكْس unix-like و أن يكون له الاسم "قِنُو GNU"  (يُُكتَب "جِنُو" في الترجمات المصرية)، و هو اختصارٌ لجملة "GNU's Not Unix" و يصف ستولمان هذا الاختصار بأنه إبداع hack في حد ذاته.
كانت طريقة ستولمان في بناء نظامه هي استبدال الأجزاء جزءاً تلو الآخر، فنظام اليُنِكْس يعمل كمجموعةٍ من التطبيقات تتخاطب فيما بينها و تتعاون لإنجاز العمل الكلي، و بالتالي من الممكن أن تستغن عن البرنامج غير الحر الأول و تكتب بديلاً له، ثم تستغن عن البرنامج غير الحر الثاني و تكتب بديلاً له، و هكذا إلي أن تجد أنك قد استبدلتَ كل مكونات النظام القديم بأخري جديدة حرة.
لكن المشكلة أن هذا كان معناه الحاجة في البداية إلي مكتباتٍ برمجيةٍ حرة، و تلك المكتبات البرمجية الحرة لا بد من بنائها من الصفر،
ثم بناء مترجمٍ compiler للغة الـc من الصفر !،
و مُحرِّر أكوادٍ code editor حر !
و مُنقِّحٍ debugger حر !

و علي هذا فقِسْ !!!

الخلاصة أن شخصاً آخر كان سـ"يضع ذيله في أسنانه" و يهرب من هذا الموضوع كما تهرب الغزلان من الأسود، إلا أن ستولمان كان (و لا يزال) متحجر الرأس جداً، لذا أصر علي الاستمرار و تجميع الآخرين لمساعدته في هذه الأعمال. لذا قام بالإعلان عن مشروع GNU عام 1984و نشر ما يُسمَّي "بيان قنو GNU manifesto" و الذي حث الآخرين فيه علي الانضمام إليه في مشروعه و مساعدته علي إنجاحه، و لرعاية المشروع و كل ما يتعلق به أسس ستولمان مؤسسة "البرمجيات الحرة Free Software Foundation" لترعي الجوانب القانونية و التنظيمية من العمل و تُصبح الشخصية الاعتبارية التي تتحدث بلسان حركة المصادر الحرة.

يُتبَع

استبدال الإجراءات متعددة الخرج بالإجراءات الداخلية

هناك لغات برمجةٍ تسمح بتفريع الإجراءات functions nesting، أي أنها تسمح بتعريف إجراءٍ أو أكثر داخل إجراءٍ آخر، و من تلك اللغات لغة الـpython علي سبيل المثال. و في أمثال تِلكم اللغات نري أننا نحصل علي فائدةٍ جميلةٍ من تفريع الإجراءات، حيث أن الإجراءات الداخلية يمكن أن تكون قادرةً علي التعامل مع المتغيرات و الثوابت و ما يشبههن اللاتي تم تعريفهن في الإجراءات الخارجية قبل تعريف الإجراء الداخلي، و كذلك التغيير في قِيم تلكم العناصر بحرية.
كما في المثال التالي المكتوب بالـpython:

def  func1():
    x = [10]
    y = [20]
   
    def  func2():
         x[0] = x[0]+ 1
         y[0] = y[0] + 1
   
    func2()
   
    print x[0],"    ", y[0]
   
func1()

الذي يعطي عند تنفيذه الخرج التالي:
11         21

و لو حاولنا إعادة صياغة البرنامج السابق بلغة لا تدعم تفريع الإجراءات مثل الـjava لوجدنا أننا سنضطر لكتابة كودٍ يشبه ما يلي:

public class Test {
    public static void main(String[] args) {
        Test t = new Test();
        t.func1();
    }
   
    void func1() {
        int x = 10, y = 20;
        result res = func2(new result(x, y));
        System.out.println("" + res.x + "    " + res.y);
    }

    result  func2(result res){
        res.x = res.x +1;
        res.y = res.y +1;
        return res;
    }

    class result {
        int x, y;
        public result(int x, int y){
            this.x = x;
            this.y = y;
        }
    }
}

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


إجراء1()

إجراء  إجراء1 :
    رقم س = 10
    رقم ص = 20
   
    س ، ص = إجراء2(س    ص)
   
    أكتب.نص.سطر(إلي.نص(س) +"       " + إلي.نص(ص))
   
إجراء  (رقم س2  رقم ص2)  إجراء2(رقم س1  رقم ص1):
    س2 = س1 +1
    ص2 = ص1 +1
   
   
و له تقريباً نفس عدد أوامر البرنامج المكتوب بالـpython، بل و يمكن اختصار البرنامج السابق أكثر من ذلك بجعل كود الإجراء إجراء2 كما يلي:

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

كما أنه يمكن الاستغناء عن الإجراءات الداخلية عن طريق التمرير بالمرجع passing by reference، و هو الأمر الموجود في لغاتٍ كثيرةٍ منها الـC  و الـ++C و الـ object pascal و الـD و غيرهن من اللغات الأخري. و يمكننا كتابة المثال السابق بلغة object pascal كما يلي*:

function func2(var x, y :integer);
begin
    x = x+1
    y = y+1
end;

function func1();
begin
    x :integer = 10;
    y :integer = 20;
   
    func2(x,y);
   
    writeln(x +"    " +y);
end;

begin
    func1();
End.

و بالطبع يمكنكم ملاحظة أنه تم الاستغناء عن الإجراءات الداخلية هنا أيضاً بكفاءة، لكن أيضاً يمكنكم ملاحظة أن تعقيد قواعد الـobject pascal جعل الأمر أقل سهولةً من حالتَيْ الـpython و إبداع.

كما أن هناك نقطةً أخري تتعلق بإمكانية حدوث ارتباكاتٍ و مشاكلٍ منطقيةٍ في اللغات التي تدعم الإجراءات الداخلية، حينما تكون تلك اللغات من نوع اللغات استنتاجية الأنواع Type inference، فمثلاً لو نظرنا إلي البرنامج الأول المكتوب بلغة الـpython لوجدنا أنه يستخدم الـlists و ليس المتغيرات الرقمية البسيطة، فلماذا لم أكتبه كما يلي:

def  func1():
    x = 10
    y = 20
   
    def  func2():
         x = x + 1
         y = y + 1
   
    func2()
   
    print x,"    ", y
   
func1()

علي الرغم من أن هذا هو الأمر الأقرب للمنطق ؟!
الجواب أنني حينما فعلتُ ذلك أَخرجَ لي مُفسِّر الـpython الخطأ التالي:

x = x + 1                                                                                                            

UnboundLocalError: local variable 'x' referenced before assignment

و السبب في هذا أنه اعتبر أن المتغيرين x و y داخل الإجراء func2 يختلفان عن المتغيرين x و y اللذين في func1 ! و بالتالي أصبح من الخطأ كتابة الأمرين:

x = x + 1
y = y + 1

لأننا بهذا نكون قد استخدمنا المتغيرين x و y قبل إعطائهما أي قيمة، رغم أن المبرمج يقصد أن يستخدم x و y الخاصين بالإجراء func1 و اللذان تم إعطاؤهما قيماً ابتدائيةً هن 10 و 20 علي الترتيب !

و الغريب أنك لو عرَّفتَ list داخل func1 فيمكنك استخدام عناصرها الداخلية بشكلٍ عاديٍ في func2، و هو ما لجأتُ إليه فعلاً في المثال الأول. و لكنك لو أسندتَ قيمةً لاسم تلك الـlist في الإجراء الداخلي func2 فإنه سيعتبر أنك تقوم بتعريف list جديدة داخل func2 تُغطِّي تلك التي تحمل نفس الاسم في func1 !
أي أنهً عند تنفيذ المثال التالي:

def  func1():
    x = [10]
    y = [20]
   
    def  func2():
         x = [11]
         y = [21]
   
    func2()
   
    print x[0],"  ",  y[0]
   
func1()

تكون النتيجة:

10    20

لأن القِيم [11] و [21] أُسنِدت إلي x و y  الخاصَّيْن بـfunc2، بينما بقي x و y الخاصَّيْن بـfunc1 كما هما، و هذا يعني معضلةً عند محاولة المبرمج التعديل في قيمة x أو y  في func1 من داخل func2؛ حيث أنني حينما حاولتُ إيجاد طريقةٍ لفعل ذلك تختلف عن استخدام خاصية الخرج المتعدد: لم أجد، و هو ما يؤيد عدم الحاجة الضرورية لتفريع الإجراءات، و أن كل الفوائد التي يمكن جنيها من ورائه يمكن الحصول عليها بشكلٍ أبسط و أسهل عن طريق الإجراءات متعددة الخرج. 

كما أن هذا الأمر يؤكد أيضاً ما ذهبتُ إليه من أفضلية فرض التعريف اليدوي للأنواع علي المبرمج و عدم جعل اللغة من النوع الذي يستنتج الأنواع بدون تدخل المبرمج**.

----------------------------------

* كل البرامج المكتوبة في هذا المقال تم تنفيذها عملياً و التأكد من خلوها من الأخطاء، ما عدا البرنامج المكتوب بالـobject pascal.

** تجدون كلامي عن هذه الجزئية في فصل (فائدة تعريف الحاويات يدوياً) الموجود في باب (أين الإبداع فيها؟) في نهاية كتاب (رسالة البرمجة بإبداع).

حَبِّر الورقة !

الحكمة المأثورة لدي الطلبة في أيام الإمتحانات هي:"إذا لم تكن تعلم الإجابة الصحيحة فـ(حَبِّر الورقة)"، و معني  "حَبِّر الورقة" أن يقوم الطالب بإجابة السؤال (الذي لا يعرف إجابته الصحيحة) بأي شيءٍ يخطر بباله أنه يخص تلك المسألة !؛ لأن ترك السؤال بدون الإجابة عليه يعني أنه سيخسر الدرجة الخاصة به لا محالة، أما كتابة أي شيءٍ يخص الموضوع و لو من بعيدٍ فإنه يعني احتمالاً (حتي و إن كان ضئيلاً) في أن يجد مُصحِّح الامتحان ما يعطيه عليه أي درجة، و هذا يندرج أيضاً تحت المثل الشعبي "العِيار اللي ميصيبشي يِدْوِش" أي أن طلقة الرصاص إن لم تُصِب الخصم فهي قادرةٌ علي إرباكه و بلبلته !

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

الإجابة هينةٌ و بسيطة و يمكن اشتفافها من قاعدة "حَبِّر الورقة"، لا أعني أن يقوم المبرمج بكتابة أي شيءٍ في أكواده حتي لو كان خطأً؛ فهذه مصيبةٌ قد تجعله يحس بالمزيد من الملل و تؤخر العمل إلي أن يتم التخلص من الخُرافات التي كتبها. بل أقصد أن يقوم المبرمج بكتابة الأكواد التي لا تحتاج إلي تفكيرٍ عميق، و لا ابتكار خوارزماتٍ مُعقَّدةٍ لا يستطيع ذهنه المُتعَبُ التفكيرَ فيها، مثل تعديل الوراثة بين العديد من الأصناف classes inheritance في مشروعه، أو إضافة تعليقاتٍ comments لأجزاء من الكود لم يتم التعليق عليها كما يجب، أو تكملة عمل التوثيقات documentations للمشروع، او ما شابَههن من أمور.
فائدة هذا الأسلوب أنه لن يكون هناك وقتٌ ضائعٌ لم تتم الاستفادة منه، بل كل ما هنالك أن جدول الأعمال قد اختلف بعض الشيء، و تم إنجاز أشياءٍ كانت موجودةً في ترتيبٍ متأخر. و في نفس الوقت لم يكن هناك الضغط النفسي الذي يسببه الجهد العقلي علي المُرهَقين من المبرمجين.

لكن هذا الأسلوب لا يصلح في كل الأحوال؛ فقد تكون هناك ظروفٌ تمنع من استخدامه، مثل:

• أن يكون العمل علي المشروع في نهاياته، و قد تم الانتهاء من الأجزاء التقليدية من قبل، و لم تعد هناك أجزاءٌ أخري يمكن العمل عليها خِلاف التكويد المُرهِق.

• أن تكون هناك أجزاءٌ أخري غير مرهقة يمكن العمل عليها، و لكن الإدارة و/أو شركاء العمل يرفضون الانتقال من جزئيةٍ إلي جزئيةٍٍ أخري، أو تبادل الأدوار، لسببٍ من الأسباب (أو حتي من باب التعسف و الغباء البشري)،

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

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

بسيطٌ و مُعقَّد

أمرٌ مدهشٌ جداً أن تَري أن خاصيتَيْن أساسيتَيْن في مُحررات النصوص مثل خاصية (تراجع undo) و خاصية (كرِّر redo) رغم بساطة مبدأيهما: إلا أنهما يحتاجان لانتباهٍ شديدٍ و تجريبٍ كثيرٍ حيت يتم بناؤهما بشكلٍ صحيح !