الجمعة، 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

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

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