الثلاثاء، 25 ديسمبر، 2012

عن فائدة كتاب الدليل و أسلوبه المُنفِّر

علَّق أحد الفضلاء علي مقالي "(وَيْلَكُم) و (دليل كارهي اليُنِكْس)" المنشور علي موقع (وادي التقنية) بقوله:
كيف يكون مثل هذا الكتاب مفيدا لنا ؟
لا سيما مع قلة مستخدمي الأنظمة المفتوحة وندرتهم في عالمانا العربي ؟!

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

فكتبتُ رداً:


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

بالطبع سيشعر من يتعلق قلبياً أو مهنياً بنظام اليُنِكْس بالكثير أو القليل من الغيظ حينما يقرأ السخرية الصارخة التي في الكتاب، و لكن يبقي القول الفصل أن الكتاب لا يفتري علي اليُنِكْس كذباً، بل ينقل حوادثاً فعليةً حدثت من قبل و تحليل الـunix-haters لها. قد تختلفُ معهم في وجهة نظرهم و في طريقة نقدهم، و لكن يبقي الأصل أنهم يتحدثون من مُنطلَقٍ عملي.
و علينا أن نفصل بين لقمة العيش و الحب القلبي و الحقائق العلمية، أنا علي سبيل المثال أعشق تجميعة "GNU + linux + KDE" الخاصة بتوزيعة kubuntu مع إضافة "java + netbeans" إليها، لكني في نفس الوقت أُقِر أن هناك عيوباً و نقائصاً كثيرةً توجد في كل مكوِّنٍ من تلك المكوِِّنات، و لو قابلتُ أحدهم ينتقد الـkde التي أعتبرها أفضل الواجهات التي تعاملتُ معها علي الإطلاق بسخريةٍ فسأعترف بالحقائق التي يُورِدها، و ربما أضحك علي النكات التي سيستعملها لتوضيح مساويء الـkde، و من يدري: فربما أغضب، و لكن يظل الأمر المهم أنني سأعترف بالحقائق أياً كان قائلها ما دامت لا تنال مني شخصياً بشكلٍ يُفقدني تعقلي. و قد قمتُ أنا نفسي بانتقاد كثيرٍ من الأمور في لغة الـjava في كتاب الرسالة (و إن كان هذا بشكلٍ أقل حدة من كتاب الدليل)، رغم ميلي و استخدامي الدائم لها.

كما أنهم لا يسخرون من "علم" أنظمة التشغيل و إنما من مُنتَجٍ يُسمَّي (يُنِكْس) الذي لا يمثل كل أنظمة التشغيل التي تم بناؤها.

السبت، 22 ديسمبر، 2012

عن تعصب unix haters و لهجة كتابهم الساخرة

عقَّب أحد الفضلاء علي مقالي "(وَيْلَكُم) و (دليل كارهي اليُنِكْس)" الذي نشرتُه علي موقع (وادي التقنية) بقوله (بتصرُّفٍ يسير):

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

و كان ردي عليه:

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

أما كونهم متحيزين و متعصبين فأمرٌ فيه نظر؛ فما قرأتُه في الكتاب يؤكد لي أنهم يتحدثون من منطلقاتٍ عمليةٍ واضحة، فكيف يكون في هذا تعصب ؟!
لو كنتَ تدري عنهم ما لا نعلمه فأرجو التوضيح.

الخميس، 20 ديسمبر، 2012

(ويْلَكُم) و (دليل كارهي اليُنِكْس) !

واحدٌ من أجمل الكتب العلمية التي قرأتُها هو كتاب (unix haters handbook)، و ترجمة عنوانه الحرفية هي (كتاب يد كارهي اليُنِكْس) و لكني أُفضِّل ترجمته كـ(دليل كارهي اليُنِكْس).

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

الحكاية و ما فيها أن هناك نظام تشغيلٍ غاية في الشهرة يُسمَّي بالـ(يُنِكْس unix) انتشر منذ فترة السبعينات من القرن العشرين بشكلٍ كبيرٍ جداً، بالطبع كان للنظام محبوه و كارهوه، أما محبوه فقد التحقوا بالدورات التي تُعلِّم كيفية التعامل معه و/أو البرمجة له، أما كارهوه فقد أنشأ بعضهم المجموعة البريدية سالفة الذِكر لشرح المشاكل التي قابلوها في تعاملهم معه و جعلتهم يكرهونه كالطاعون.
و بعد سنواتٍ من السباب العلمي الأنيق و غير الأنيق أصبح بالإمكان جمع أهم رسائل تلك المجموعة البريدية في كتابٍ واحدٍ بحيث تتسق مع بعضها البعض و تُكوِّن كتاباً شاملاً جامعاً، و قد فعلها (Simson Garfinkel) و (Daniel Weise) و (Steven Strassmann) مع آخرين و أصبح بين أيدينا كتاب (دليل كارهي اليُنِكْس).

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

يقع كتاب (دليل كارهي اليُنِكْس) في  أربعة أجزاء يتكون كلٌ منها من عددٍ من الفصول، و تلخيص الفهرست كما يلي:


* Foreword
    By Donald A. Norman
* Preface
    Things Are Going to Get a Lot Worse Before Things Get Worse
* Who We Are
* The UNIX-HATERS History
* Contributors and Acknowledgments
* Typographical Conventions
* The UNIX-HATERS Disclaimer
* Anti-Foreword
    By Dennis Ritchie
* Part 1: User Friendly ?
    - 1: Unix
    The World’s First Computer Virus

    - 2: Welcome, New User!
    Like Russian Roulette with Six Bullets Loaded

    - 3: Documentation?
    What Documentation?

    - 4: Mail
    Don’t Talk to Me, I’m Not a Typewriter!

    - 5: Snoozenet
    I Post, Therefore I Am

    - 6: Terminal Insanity
    Curses! Foiled Again!

    - 7: The X-Windows Disaster
    How to Make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC
   
* Part 2: Programmer’s System?
    - 8: csh, pipes, and find
    Power Tools for Power Fools

    - 9: Programming
    Hold Still, This Won’t Hurt a Bit
   
    - 10: C++
    The COBOL of the 90s

* Part 3: Sysadmin’s Nightmare
    - 11: System Administration
    Unix’s Hidden Cost
   
    - 12: Security
    Oh, I’m Sorry, Sir, Go Ahead, I Didn’t Realize You Were Root
   
    - 13: The File System
    Sure It Corrupts Your Files, But Look How Fast It Is!
   
    - 14: NFS
    Nightmare File System

* Part 4: Et Cetera
    -A: Epilogue
    Enlightenment Through Unix
   
    - B: Creators Admit C, Unix Were Hoax
    FOR IMMEDIATE RELEASE
   
    - C: The Rise of Worse Is Better
    By Richard P. Gabriel
   
    - D: Bibliography
    Just When You Thought You Were Out of the Woods
   
    - Index


و لو لاحظتم: فحتي لهجة العناوين في قمة السخرية و التهكم، و هو ما لم أجرؤ علي فعله في كتاب الرسالة، و قد قرأتُ في الكتاب كثيراً (لكني لم أُنْهِ الجزء الأكبر منه حتي الآن)، و كلما قرأتُ فيه ازدادت قناعتي بأن نظام اليُنِكْس أذاق هؤلاء الشاكين الويل ألواناً و أشكالاً ففاضت به ألسنتهم بذلك التهكم الصارخ.
عامَّةً لو أردتم فائدةً علميةً فستجدونها في ذلك الكتاب، و لو أردتم سخريةً علميةً صارخةً فستجدونها فيه أيضاً.
و كنتُ أفكر في ترجمة الجزء الخاص بنقد لغة الـ++C (أو إن شئتم الدقة: نَقْضِها !) لكني لا أجد الوقت الكافي لهذا، و ربما أفعله متي وجدتُ فراغاً زمنياً و ذهنياً يكفيان لإتمام هذا الأمر كما أحب بإذن الله عز و جل. 

و قد أوحي هذا الكتاب لي بفكرةٍ أجدها جميلةً و تستحق العمل عليها عند من يجد وقتاً كافياً لها، الفكرة هي: جمع كل المشاكل التي تقابلنا أثناء العمل علي مختلف أنظمة التشغيل و تنظيمها و وضعها في كتابٍ خاصٍ بها، و أقترح تسمية الكتاب (ويْلَكم) و هو تحريفٌ لنطق كلمة (وِيلْكَم welcome) التي تكون عادةً الشاشةَ الافتتاحية لأنظمة التشغيل المختلفة (أو علي الأقل لنظام الـwindows الذي أظن أنه سيكون له نصيب الأسد من الكتاب المُقترَح)، و هو التحريف ذو المعني الواضح :)
أُكرِّر أن ذلك الكتاب لن يكون خاصاً بنظام تشغيلٍ واحد، بل سيكون مشتملاً علي كل المشاكل التي نواجهها علي مختلف أنظمة التشغيل، و هكذا يحكي مستخدموا اليُنِكْس و مستخدموا القنو/لينُكْس GNU/linux و مستخدموا الـwindows و غيرهن من الأنظمة عمَّا أَقََضَّ مضاجعهم في تلك الأنظمة. و يتم ترتيب الشكاوي علي أبوابٍ يختص كل واحدٍ منها بجانبٍ مُعيَّنٍ من تلك المشاكل كما في (دليل كارهي اليُنِكْس).

أجدها فكرةً حلوة: و لكن هل من مُتفرِّغٍ لها ؟

الجمعة، 7 ديسمبر، 2012

نبذةٌ عن مكتبتَيْ الـawt و الـswing

هذه نبذةٌ مُختصَرةٌ عن مكتبتَيْ الـawt و الـswing البرمجيَّتَيْن، كتبتُها كَرَدٍ علي سؤالٍ في المنتدي العلمي الوحيد الذي أُتابِعه، و رأيتُ أن  أُنقِّحها بعض الشيء ثم أضعها في المدونة للاستفادة العامة.
 ***
الـawt و الـswing باختصارٍ هما مكتبتان برمجيتان تُتيحان إنشاء واجهاتٍ رسوميةٍ GUI للبرامج، مثل النوافذ windows و الأزرار buttons و صناديق النصوص text boxes و غيرهن من المُكوِّنات الرسومية الأخري، و تُعتبَران جزءاً مما يُسمَّي بإطار الـJava Foundation Classes أو الـJFC اختصاراً، و هو إطارٌ برمجيٌ يُوفِّر واجهاتٍ برمجيةٍ قياسيةٍ لإنشاء الواجهات الرسومية للغة الـjava بغض النظر عن نظام التشغيل الذي يعمل عليه البرنامج.



الـawt :
هي مواصفاتٌ يتم بناؤها بشكلٍ مختلفٍ لكل نظام تشغيل يتم دعمه فيها، يعني: حينما يتم تنفيذ  البرنامج الذي يستخدم مكتبة الـawt علي نظام تشغيل الـwindows فإن نسخة مكتبة الـawt التي ستعمل ستكون في هذه الحالة مبنيةً علي مكتبات الـwindows نفسه، و لو تم تنفيذ ذات البرنامج علي نظام القنو/لينوكس GNU/linux فستكون نسخة الـawt التي ستعمل في هذه الحالة مبنيةً علي إحدي المكتبات المتوافرة له.

و لأنها تستخدم مكتبات أنظمة التشغيل فإن شكل الأزرار و بقية المُكوِّنات في القنو/لينوكس يشبه شكلها في بقية البرامج، و شكل الأزرار و المكونات الأخري في
الـwindows مشابهٌ لشكل بقية البرامج، أي أن البرنامج يختلف مظهره باختلاف نظام التشغيل الذي يعمل عليه، 

مثالٌ لشكل برامج الـawt علي الـwindows (من صفحة الـawt علي الويكيبيديا)

بعض الناس يرون هذا ميزةً و بعضهم يراه عيباً، أنا عن نفسي أري أنه ميزة.
و لكن نتيجةً لكونها تعتمد علي مكتبات أنظمة التشغيل فقد ورثَتْ منها مشاكلها التي توجد بها، و بالتالي اشتُهِرت بأنها غير مستقرةٍ بما فيه الكفاية و ينتج عنها أغلاط زمن تشغيلٍ runtime errors كثيرة (و قد جرَّبتُ هذا بنفسي)، و أظن أن هذه المشاكل زادت بشكلٍ كبيرٍ بعد أن تم استبدالها بمكتبة الـswing و تم إهمال الـawt ربما حتي علي مستوي إصلاح العِلل !
 

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


مثالٌ لشكل برامج الـswing علي مُختَلف أنظمة التشغيل (من صفحة الـswing علي الويكيبيديا)

و من جديد: فبعض الناس يري هذا عيباً و بعضهم يراه ميزة، و أنا عن نفسي أعتبره عيباً لأنه يجعل برامجها في الـwindows مختلفة المظهر عن بقية البرامج بشكلٍ واضح، و كذلك نفس الأمر علي القنو/لينوكس، مما يسبب بعض النفور من اختلاف المظهر (علي الأقل عندي)، و لكني أُقِرُّ أن هذا الشعور يتلاشي مع مرور الزمن و يعتاد المستخدِم علي الشكل المختلف للبرنامج، و قد جَرَّبْتُ هذا مع برنامج الـnetbeans الذي له نفس الشكل المختلف و أصبحتُ لا أحسُّ بأي نفورٍ من هذه الناحية.
 
بالنسبة للأفضلية: 
فالـawt أفضل من حيث السرعة في التنفيذ،
و من حيث قلة المشاكل و التطور و الإصلاح الدوري للعِلل فالـswing أفضل،
أما من حيث السهولة فمن خلال استخدامي البسيط لهما فكلاهما له نفس الدرجة من السهولة.


التكوين العام للمكتبتَيْن (من صفحة مكتبة الـswing علي ويكيبيديا)

للمزيد من التفاصيل التقنية و الأمثلة العملية يمكن زيارة صفحتَيْ الويكيبيديا الخاصتين بالمكتبتين:
http://en.wikipedia.org/wiki/Abstract_Window_Toolkit
http://en.wikipedia.org/wiki/Swing_%28Java%29

بالمناسبة: هناك مكتبةٌ ثالثةٌ تُحاوِل دمج ميزات المكتبتَيْن السابقتين و تلافي عيوبهما، و هي مكتبة الـswt التي يمكن قراءة المزيد عنها علي صفحة الويكيبيديا الخاصة بها:
http://en.wikipedia.org/wiki/Standard_Widget_Toolkit

و قد كانت لي تجربةٌ مع الـawt و الـswing و انتقلتُ من استخدام الأولي إلي استخدام الثانية، و يمكن قراءة المزيد عن هذا علي الرابط التالي:
http://afkar-abo-eyas.blogspot.com/2012/08/awt-swing.html

الجمعة، 30 نوفمبر، 2012

الإطلاق الرسمي لمشروع (البرمجة بإبداع)

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

و في الرابط التالي تقديمٌ لفكرة المشروع في مقال الإعلان عن المشروع علي الموقع الرسمي له:
http://ebda3lang.blogspot.com/2012/11/blog-post_29.html

أرجو مد يد المساعدة للمشروع بنشر ذلك المقال، و كذلك بالحديث عن المشروع بين الناس سواءٌ في مدوناتكم أو علي حساباتكم علي مواقع التواصل الإجتماعي :)

الخميس، 29 نوفمبر، 2012

ملفٌ كاملٌ لكل مشروع

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

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

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

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

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

الثلاثاء، 27 نوفمبر، 2012

لا تحتفل مبكراً

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

لذا فقبل أن تدخل في تلك الدوائر الجهمنية من الإحباط و الضيق و ضياع الوقت و التشتت الذهني: تأكد قبل إقرارك لزعم أنك قد حللتَ علةً ما مِن أنك قد غطيت كافة الاحتمالات التي قد تظهر فيها تلك العلة. و هكذا يمكنك أن تستمر في مسيرة عملك بذات الفكر اليقظ و النفسية المستقرة.

السبت، 24 نوفمبر، 2012

إنه يعمل، و لكنه لا يعمل !


حتى حينما حاولتُ جعل windows7 أفضل قليلاً و يُشبِه الـKDE فى إمكانيةٍ واحدةٍ لم يُجْد ذلك نفعاً؛ هذه الصورة التقطتُها لقائمة SendTo بعد أن جعلتُ برنامج الفهرست 3.0 يدعم windows7 و جربتُه علي جهازٍ به ذلك النظام:





ستُلاحِظون أن في القائمة المُنبثِقة هناك مجلدٌ اسمه "D"، هذا المجلد كان من المفترَض أن داخله تفرعاتٌ أخري كما فى صورة الـXP :

  
لكنها غير موجودة في حالة windows7 لأن النظام يمنع هذه الإمكانية ! كما أن قائمة المُفضَّلة Favourites أيضاً لا يستطيع الفهرست أن يغيرها كما يفعل مع الـXP. يعني أن الفهرست يؤدي عمله بشكلٍ صحيح و لا يمنعه نظام التشغيل من ذلك، و لكن نظام التشغيل يعود ليمنع نتائج هذا الفعل عن طريق تغيير القواعد التي كان يعتمد عليها الفهرست في عمله !
 بالطبع ليست هذه مشكلةً بالنسبة لي لأني لم أعد أستخدم أي نظام تشغيلٍ من microsoft إطلاقاً، و بالتالي لا يهمني هل ستعمل برامجي علي الأنظمة الجديدة منها أم لا. و أيضاً ليست هذه مشكلةً بالنسبة لغيري؛ فليس برنامج الفهرست من البرمجيات الضخمة التي يحتاجها الناس في حياتهم اليومية ولا يستطيعون الاستغناء عنها، بل كان بنسبةٍ كبيرةٍ مجرد مشروعٍ لتعلم لغة الـ#C و بيئة الـvisual studio. 

لكن المشكلة هي: ماذا سيحدث للبرامج الضخمة التي تعتمد علي كثيرٍ من المواصفات في الأنظمة القديمة من إنتاج microsoft حينما يتم تغيير تلك المواصفات في الأنظمة الأحدث بدون تقديم بديلٍ عنها ؟! بصراحة: لا أحب أن أضع نفسي محل من يُبرمِج حصرياً و خصيصاً لمنصات سلسلة الـ windows حينما يواجِه ذلك الموقف.

الخميس، 15 نوفمبر، 2012

خدمة النسخ الاحتياطي الذكي

 خدمة النسخ الاحتياطي الذكي

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


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

الاثنين، 5 نوفمبر، 2012

lazarus في أي مكان !

حينما رأيتُ الصور الموجودة علي موقع الويكي الخاص ببيئة التطوير المُتكامِلة lazarus (هي بيئةٌ خاصةٌ بِلُغة البرمجة object pascal) فوجئْتُ بكمية الأرضيات التى تدعمها البيئة؛
فهي تدعم تقريباً كل إصدارات الـwindows، و تدعم القنو/لينوكس GNU/linux و الماك mac و كثيراً من أجهزة الهاتف المحمولة الذكية.  
و بذلك تكون قد حَققت نجاحاً باهراً فى مسألة الشمولية للبيئات التى تعمل عليها. و ما دامت تستطيع أن تُنتِج ملفاتٍ تنفيذيةٍ executables لكل هذه البيئات المُختلِفة فهذا معناه أنها أيضاً قد حققت نجاحاً باهراً في مسألة الشمولية في البيئات التي تُنتِج لها.
من وجهة نظري: لا يعيبها أنها خاصةٌ بِلُغةٍ واحدةٍ فقط؛ فمن الممكِن إضافة دعم المزيد من اللغات البرمجية الأخري إليها فيما بعد، و قد كان الهدف الأساسي من ورائها هو أن تكون البديل الحر مفتوح المصدر لبيئة delphi التجارية، و قد نجحتْ في امتلاك إمكانياتٍ أظنها فاقت إمكانيات الـdelphi (علي الأقل في مسألة العمل و الإنتاج للبيئات المُختلِفة).

الخميس، 1 نوفمبر، 2012

مصابيحٌ ودودة

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

الاثنين، 29 أكتوبر، 2012

ثلاثة أعوامٍ بدون قاريء أسطوانات !

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

هل تظنون أن مثل هذه التقنيات القديمة لها مكانٌ في عالم اليوم حيث يوجد ما هو أفضل و أرخص و أكثر تطوراً منها ؟

الخميس، 25 أكتوبر، 2012

asimo

أفلام الخيال العلمى يتم تحقيقها شيئاً فشيئاً: كل فترةٍ تزداد قدرة الروبوتات علي مُحاكاة البشر و تفاعلُهم شبه الطبعى معهم و مع العالم المحيط، و تزداد تحركاتهم سلاسةً و مرونة، ليس بعيداً أن يأتى اليوم الذى نجد فيه روبوت مرورٍ يركب دراجة نارية و يُطارِد سيارةً بسبب سرعتها الزائدة عن الحد المسموح به !
 

الثلاثاء، 23 أكتوبر، 2012

نظرية (المُبرمِج المُحتال)! جـ1

نظرية (المُبرمِج المُحتال)! جـ1

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

حسنٌ: اليوم أريد أن أجعلكم تُلقون بهذه النظرية وراء ظهوركم و تنتبهوا لنظريةٍ أهم و أجمل منها و أكثر تفسيراً لما يجب أن يفعله المُبرمِجون كلهم بدون استثناء، 
أيها السادة إنها نظرية (المُبرمِج المُحتال) ^_^


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

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

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

هل رأيتم ؟


يُتبَع

السبت، 20 أكتوبر، 2012

مكتبة الـOpenCV قمة الذكاء قمة الخيبة !

س: ما هي قمة الذكاء ؟
جـ: أن تُبرمِج مكتبةً قويةً جداً مثل مكتبة الـOpenCV، فى مجالٍ شديد التعقيد كمُعالَجة الصور الرقمية، ثم تَنشرَها للعالم كله مجاناً و تجعلها مفتوحة المصدر أيضاً.
س: و ما هي قمة الخيبة ؟
جـ: أن تكتب الكود بِلُغتَي الـC و الـ++C من غير سَطْر تعليقاتٍ واحدٍ يُوحِّد الله، و أن تترك الناس يُحاوِلون فهم أكوادك كلٌ حسب جهده و قدرته !

السبت، 15 سبتمبر، 2012

الـcaptcha من أفضل طرق التعذيب النازي

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

الأربعاء، 29 أغسطس، 2012

المقدمة المُختصرة للبرمجة الكائنية oop كملف pdf

قمتُ بفضل الله تعالي بتحويل مقال المقدمة المُختصرة للبرمجة الكائنية oop إلي ملف pdf و رفعتُه علي حسابي علي موقع 4shared لإتاحة تحميله و تداوله و قراءته لمن يرغب في ذلك.

يمكنكم تحميل الملف من هــــنــــا.

تعقيبٌ علي مقال: بين الـawt و الـswing

تعقيبٌ علي مقال: بين الـawt و الـswing

عَلَّق أخٌ فاضلٌ علي مقالي بين الـawt و الـswing علي موقع وادي التقنية بقوله (بِتَصَرُّف):
ياه، أنت ما زلت تستخدم awt ! ظننتُ لا أحد يستخدمها الآن، ما رأيك في أن تستخدم مكتبة SWT؛ على الأقل هي أسرع من swing ومظهرها أفضل بدرجات، وهي في تطور مستمر.
بالمناسبة: هل السرعة مطلوبةٌ في التطبيق الذي تُطوره؛ لأنه من المعروف أن جافا في تطبيقات سطح المكتب بطيئةٌ بشكلٍ عام ؟ وكذلك من المعروف أن قوة جافا تظهر في المُخَدِّمات و الأجهزة المحمولة.
فقلتُ:

أنا لم أتعمق من قبل في دراسة الجافا و العمل الاحترافي بها، و كنتُ أستخدمُ الـ#C و الـ.NET في كل شيءٍ يخصني. و لذلك نسيتُ مسألة قِدَم الـawt و المشاكل التي تظهر حين استخدامها، و تذكرتُ هذا بعد ما حدث :)
بالنسة لسرعة التطبيق فلم تتأثر ببطء الواجهة الرسومية بشكلٍ كبير؛ لأنها لا تستخدمها إلا في الدخل و الخرج، و يمكن للبرنامج أن يستخدم سطر الأوامر العادي لأداء هذه المهمة إذا رغب مُستخدمه في ذلك، و مُحاكي سطر الأوامر الخاص له بعض الحالات الخاصة التي تجعله الأفضل (كما أنني بصراحة كنتُ أريد تعلم كيفية صنع مُحاكيات سطر الاوامر فقلتُ: وافق شِنٌ طبقه ^_^)

الثلاثاء، 28 أغسطس، 2012

البرمجة الكائنية بدون وراثةٍ متعددة

البرمجة الكائنية oop بدون وراثةٍ متعددة multiple inheritance تماماً كزوجةٍ مُتدينةٍ جميلةٍ و لكنها لا تُنجب؛ بالتأكيد وجودها أفضل بكثيرٍ جداً من عدم وجودها، و لكن لا يُمكنك أن تُنكر أنه لا أحد يرغب في البقاء بلا أبناء.

السبت، 25 أغسطس، 2012

مقدمة عن البرمجة الكائنية object oriented programming OOP


مقدمةٌ عن البرمجة الكائنية
 object oriented programming 
OOP


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

ماهية البرمجة الكائنية:

لكي نفهم ماهية و خصائص نمط البرمجة الكائنية oop paradigm يجب علينا أن نتفهم المثال التالي:
فلنفترض أننا نريد كتابة برنامجٍ يقوم بإنشاء خَمس حساباتٍ لخمسة أشخاصٍ في خمسة شركاتٍ مختلفة، و يقوم بحساب مستحقاتهم المالية لدي الشركة بعد مرور ثلاث سنوات بمعرفة نسبة الربح السنوي المعتادة من رأس المال. مع ملاحظة أن الكود سيكون بنمط البرمجة العادي (أي بدون استخدام الأصناف classes و الكائنات objects).

double account1 = 100, profit1 = 0.1;
double account2 = 150, profit2 = 0.15;
double account3 = 200, profit3 = 0.20;
double account4 = 175, profit4 = 0.25;
double account5 = 200, profit5 = 0.30;


double after_years(double old_account, double profit, int years){
for(int i = 1; i <= years; i++){
old_account = old_account * profit + old_account;
}
return old_account;
}

void main(){
account1 = after_years(account1, profit1, 3);
account2 = after_years(account2, profit2, 3);
account3 = after_years(account3, profit3, 3);
account4 = after_years(account4, profit4, 3);
account5 = after_years(account5, profit5, 3);
}


بملاحظة البرنامج السابق سوف نري أننا لتمثيل كل حسابٍ من الحسابات  المالية استخدمنا متغيرين من نوع double: 
  • الأول لتمثيل النقود التي يحتويها الحساب  account
  • الثاني لتمثيل نسبة الربح profit
و تم  تكرار هذا مع كل حسابٍ من الحسابات المالية، بالطبع مع تغيير أسماء المتغيرات للتمييز بينها.
إذاً فالسؤال المنطقي الآن: هل يمكنني كمبرمجٍ أن أختصر كل ذلك الكود ما دام الكثير منه مكرراً بالفعل ؟

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

و بالتطبيق علي المثال السابق نري أن التقسيم الأَوَّلي لما سنحصل عليه سيكون كالتالي:
double account, profit;
double after_years(double old_account, double profit, int years){
for(int i = 1; i <= years; i++){
old_account = old_account * profit + old_account;
}
return old_account;
}

يمكن أن نُطلق علي الكود السابق إسم caccount اختصاراً لـcompany account و هو اسمٌ معبرٌ جداً عن وظيفته.
و في البرنامج الأساسي سنكتفي بطلب نسخ الكود caccount خمس مرات من مترجم اللغة بأسماء account1  account2   account3   account4   account5.
caccount account1;
caccount account2;
caccount account3;
caccount account4;
caccount account5;

فماذا سيفعل الحاسوب بعد حجز أماكن لتلك الكائنات في الذاكرة ؟
سوف يقوم بعمل ما يلي تقريباً:



و بداخل كل وحدةٍ من الوحدات المحجوزة تُوجد المتغيرات الموجودة في الكود المُكرر الذي كتبناه من قبل و وضعناه جانباً.
فلو كتبنا في البرنامج:
 account1.account
فإننا نعني المتغير account الذي هو من نوع double و المحجوز للنسخة المُسماة account1.
و هكذا مع:
account2.account

و غيرها.

و لو أردنا أن ننفذ دالة علي النسخة account1 بحيث تعملُ باستخدام متغيراتها الخاصة فإننا نكتب الكود التالي:
account1.methodname();

مثال:
account1.newaccount();


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

لا.
فماذا لو أنني أردتُ إعطاء قيم ابتدائية للمتغيرات الموجودة داخل النسخ الجديدة في نفس سطر تعريف كل نسخةٍ منها، كيف يمكنني فعل هذا ؟
و ماذا لو أنني أردتُ منع الوصول المباشر للمتغيرات داخل النسخ، مثل الأمر:
account1.account = 1000;

و أردتُ أن تكون هذه المتغيرات متاحةً فقط للدوال الموجودة معها في الكود المُكرر فقط ؟
إلي آخر تلك الأسئلة التي تُوضح إجاباتُها خصائصَ نمط البرمجة الكائني.

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



التوصيف المُصطلح العلمي العربي المُصطلح العلمي الإنقليزي
كود مكرر صِنْف class
نُسخة نسخة، كائن Object, instance
متغير داخل صنف حقل بيانات Data field
دالة داخل صنف دالة حالة Instance method

و لنجب الآن عن الأسئلة التي سبق و طرحناها.
أما كيفية إعطاء حقول البيانات قيماً ابتدائية في نفس جملة التعريف فيتم عن طريق ما يُسمي بالمُشَيِّد constructor، و هو دالةٌ لها نفس اسم الصنف class بدون أي نوعٍ من المُخرجات (ليس حتي void).
و ينقسم المُشَيِّد إلي نوعين:
  • المُشَيِّد الافتراضي default constructor
  • المُشَيِّد ذو المُدخَلات parameterized constructor

و هذا هو المثال السابق بالكامل (مع إضافة مُشَيِّداتٍ من ذوات المُدخَلات):
public class caccount {
double account, profit;

public caccount(double account, double profit){
this.account = account;
this.profit = profit;
}
public static void main(String[] args){
caccount account1 = new caccount(100, 0.1);
caccount account2 = new caccount(150, 0.15);
caccount account3 = new caccount(175, 0.20);
caccount account4 = new caccount(200, 0.25);
caccount account5 = new caccount(250, 0.3);
}

double after_years(double old_account, double profit, int years){
for(int i = 1; i <= years; i++){
old_account = old_account * profit + old_account;
}
return old_account;
}
}

و يقوم البرنامج بحجز مكانٍ في الذاكرة للكائن الجديد ثم تنفيذ المُشَيِّد الافتراضي لو كتبنا ما يلي:

caccount  account1 = new  caccount();

و لاحظ عدم وجود قيم بين قوسي المُشَيِّد المُستدعَي.
بينما يقوم البرنامج بحجز مكان الذاكرة ثم تنفيذ المُشَيِّد ذي المُدخلات لو كتبنا ما يلي:
caccount  account1 = new  caccount(100, 1.0);

و لاحظ وجود قيمٍ بين قوسي المُشَيِّد المُستدعَي. و في هذه الحالة يكون:
account2.account = 100
account2.profit = 0.1

أما منع الوصول المٌباشر لحقول البيانات فيكون ببساطة بإعطائها الخاصية private عند تعريفها، مثل:
private double account;

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

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

أين تتم كتابة الأكواد:

في هذه المرحلة نكون قد وصلنا إلي تصورٍ جيدٍ لمفهوم البرمجة الكائنية oop و كيفية الاستفادة منها في تصغير حجم البرنامج و حماية حقول البيانات من تدخل المستخدم النهائي، و لكننا حتي الآن لا ندري أين تتم كتابة كود الصنف الفرعي و أين سنكتب الكود الذي سيستخدم هذا الصنف ؟
و هذه نقطةٌ هامةٌ للغاية تختلف فيها لغات البرمجة؛ ففي لغة الـ++C مثلاً سوف نجد أننا سوف نستخدم ملفات الـheader files (أو ملفات التَرْويسَة ) لكي نكتب فيها كود الـصنف و يكون لها الامتداد (h.)، و سيكون علينا أن نكتب الكود بنفس طريقة الـ++C التي تشترط كتابة مُلخص الصنف specification ثم بعد ذلك يأتي كوده التفصيلي (أو ما يُسمي بالبناء implementation).
و كذلك فإنه يمكننا أن نكتب التلخيص في ملف ترويسة و البناء داخل ملف آخر له الامتداد cpp. مع كتابة الجملة التالية في بداية هذا الملف الجديد:
#include "caccount.h";

لجعل المُترجم يفهم أن الملفين مرتبطان ببعضهما البعض.
هذا بالنسبة للـ++C، أما في حالة الـjava فيمكننا كتابة كود الصنف في نفس ملف البرنامج الأصلي، أو في ملفٍ مستقل لكن بحيث:
  • يشتمل كل ملفٍ مستقلٍ علي صنفٍ واحدٍ فقط يماثله في الاسم، و بإمكاننا كتابة أصنافٍ أخري داخل ذلك الصنف الواحد.
  • يكون امتداد الملف المستقل(java.)

مفهوم الوراثة inheritance و علاقته بمبدأ إعادة الاستخدام:

بعد الانتهاء من كتابة برنامجٍ ضخم بنمط البرمجة الكائنية سوف نجد أنه قد تم كتابة عددٍ كبيرٍ من الأصناف المُستقلة التي سهلت علينا العمل و أسرعته بمعدلاتٍ فائقة.
لكن السؤال الحيوي هنا: هل يمكنني الاستفادة منها بصورةٍ أكبر ؟

بالطبع نعم؛ حيث يمكنني إعادة استخدام reuse هذه التصنيفات الموجودة عندي في كتابة برامجي الجديدة دون الحاجة إلي إعادة كتابة كودها مرةً أخري أي أنني أصنع مكتبتي الخاصة بي، تماماً كالمكتبات القياسية للغات البرمجة، حيث أن الأصناف التي نستخدمها في برامجنا التي نكتبها بتلك اللغات ليست إلا أكواداً قام بكتابتها متخصصون في شركة البرمجيات و أراحونا من عناء كتابتها منذ البداية.
و علي سبيل المثال لو أنني احتجتُ للصنف caccount أثناء كتابتي لبرنامجٍ جديدٍ بلغة الـ++C فسوف أقوم فقط بضمه للبرنامج بالعبارة:
#include "caccount.h";

 و بذلك يمكنني استخدامه بمنتهي الحرية.

لكن ماذا لو أردتُ استعمال هذا الصنف مع إحداث بعض التغييرات فيه (كتابة حقول بياناتٍ إضافية، أو كتابة دوالٍ إضافية، أو حتي تعديل أكواد دوالٍ موجودةٍ من قبل) مع الاحتفاظ بهيكل و مكونات الصنف الأساسي كما هي، فما العمل ؟
 الحل هنا يكمنُ في مفهوم الوراثة؛ فحينما أُخبر اللغة أنني أريد كتابة تصنيفٍ جديدٍ فلنفترض أنه new_caccount يرث الصنف caccount فإنه يكون مفهوماً لديها أن الصنف الجديد يحتوي علي كل حقول البيانات و الدوال التي يحتويها الصنف القديم مع وجود إمكانية التعديل كما سبق و شرحنا.
و تختلف اللغات فيما بينها في مدي و كيفية الوراثة: أهي وراثة متعددة multiple inheritance بما يعني أن الصنف الواحد يمكنه وراثة عددٍ غير محدودٍ من التصنيفات الأخري كما في الـ++C و الـeiffel، أم هي وراثة أُحادية أي أن الصنف لا يمكنه وراثة أكثر من صنفٍ واحدٍ فقط كما في لغات الـjava و الـ#C. و ربما نتحدث عن هذا بالتفصيل في شروحاتٍ قادمةٍ بإذن الله تعالي.

إلي هنا نكون قد أنهينا المفاهيم الأساسية في عالم البرمجة الكائنية، و لكن أشياء كثيرة للغاية ما زالت تنتظر و لكنها تتأثر بماهية اللغة التي سنبرمج بها، لذلك ستكون هذه الأشياء في الـ++C مختلفة الشكل و الخصائص عنها في الـjava و عنهما في الـ#C.
و منها:
  • الواجهات interfaces
  • الهياكل structs
  • التعدادات enumerations
  • الوسائط delegates
  • الاحداث و تعهد الأحداث events and events handling
و غيرهن.