مقالات حسن عارف عبد الرحمن

ادارة مشروع برمجي بكفائة من دون ان يجن جنونك!

Sun, 29 Aug 2010 16:58:00 -0400

هناك امور يتعلمها المرء من التعامل مع مشروع برمجي حقيقي لاول مرة، امور لم يكن يدركها من قبل ولا كانت تخطر له على بال!

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

هناك احتمال من اثنين: إما ان تقوم بتطوير المشروع بشكل سريع و متواصل، و بالتالي تحتاج لاصدار التحديثات باستمرار، او ان يكون المشروع بسيط نوعا ما و لا يحتاج تحديثا باستمرار، و انما تقوم بتطويره لعدة اشهر قبل اصدار اي تحديث جديد.

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

لنتفق اولا على بعض المصطلحات:

‏deploy: عند الحديث عن تطبيقات الويب، فإن هذا المصطلح يعني اطلاق المشروع (او تحديثه) على الموقع. يمكن ان نترجمها “إطلاق”.

‏productivity: كفائة المبرمج و سرعته في التطوير و التحديث و ادارة المشروع. عادة يسمونها “الانتاجية”، و لكني ساسميها “كفائة”، لان الفكرة تتمحور حول ان تكون كفوءا في التطوير و الادارة.

‏automation: اتمتة. اي تحويل المهام المضنية و المملة (العمليات الرتيبة الميكانيكية اللتي تشتت فكرك لانها تسترعي انتباهك) الى عملية سهلة يقوم بها الكومبيوتر باقل عدد ممكن من الخطوات، و يفضل ان تتم بخطوة واحدة، اي يكفي ان تكتب امرا واحدا (او تضغط زرا) ليقوم الكومبيوتر نيابة عنك بتنفيذ كل المهام المطلوبة لاتمام تلك العملية.

كيف تصاب بالجنون

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

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

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

تخيل لو كنت في خضم العمل على خاصية جديدة و اكتشفت علة خطيرة في الموقع، ماذا تفعل؟

لكي تدير المشروع بكفائة يجب ان تكون قادرا على:

اصلاح العلة في الموقع و اطلاقها باقصر وقت ممكن
من دون ان يؤثر هذا على ما نفذته من عمل لاضافة الخاصية الجديدة

هناك امور ستجعل منك مبرمجيا غير كفوء:

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

لنفرض انك تغلبت على هذه النقطة و انك تطور المشروع في اتجاهين متوازيين او انك تستخدم git و بالتالي يمكن اصلاح علة في نسخة سابقة من دون لخبطة النسخة الحالية.

هذا وحده لا يكفي، يجب ان تكون ايضا قادرا على اطلاق اي تحديث الى الموقع بسرعة و كفائة، و الا اصبت بالجنون! هل يمكنك ان تتخيل انك كلما اردت اطلاق اخر تحديث للموقع، يجب ان تقوم بعشرين خطوة ليس لاي منها علاقة بالاخرى؟ و كل خطوة قد تستغرق دقيقة الى خمس دقائق؟

مثلا، الخطوة الاولى: عمل compile
الخطوة الثانية: اعداد بعض الـ configurations
الخطوة الثالثة: اغلاق السرفر و وضع اشعار صيانة
الخطوة الرابعة: حذف الملفات السابقة من الموقع - يدويا - مع الاحتفاظ بالـ configurations
الخطوة الخامسة: مقارنة الـ configuration القديمة بالـ configuration الجديدة و التأكد من انك لم تنسى شيئا
الخطوة السادسة: رفع الملفات الجديدة الى السرفر و التأكد من وضع ملفات الـ configurations في مكانها الصحيح
الخطوة السابعة: القيام بتحديث قاعدة البيانات لكي تقوم بعمل الـ migrations المطلوبة
الخطوة الثامنة: تشغيل السرفر من جديد و ازالة اشعار الصيانة

هذا مثال فقط و ليس بالضرورة انه مثال واقعي، و لكنه قد يحدث كثيرا في الكثير من الشركات ذات الادارة العقيمة.

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

ان لم يكن لديك هذا الامر فستصاب بالجنون و ستكره عملية اطلاق الموقع و ربما تكره عملية التطوير كلها من الاساس. تخيل، اااخ جائني bug report و يجب ان اصلح الموقع باسرع وقت!! يا للمصيبة، لا يكفي ان امضي ساعتين في محاولة اكتشاف العلة و اصلاحها بل يجب ان اقضي نصف ساعة لاعاني من كابوس اطلاق الموقع! تعرف شنو .. اصلاح العلة ليس مهما جدا .. خليهم ينتظروا للشهر الجاي حين اطلق النسخة الجديدة.

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

اطلاق الموقع هو احدى العمليات المكررة اللتي ستواجهك كثيرا في عملك اليومي. هناك اعمال اخرى من هذا الصنف و قد تجد نفسك مضطرا للقيام بها عدة مرات في اليوم.

الطريق نحو الهاوية

و لهذا و لكي تحافظ على قدراتك العقلية من الجنون، ستتخذ قرارا بعدم اطلاق اي تحدث الا مرة كل شهر، او كل شهرين .. او ربما كل اربعة اشهر!!

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

و زيادة في العقم .. لنتخيل انك لا تستخدم git ولا اي اداة لادارة نسخ متعددة من المشروع بشكل متوازي.

تخيل كيف ستكون عملية الادارة الان: كل خاصية جديدة تحمل معها مخاطرة باضافة علل جديدة الى البرنامج، و لنفرض انك تقوم باصدار جديد كل شهرين، فإنك لن تقوم بتطوير اي خاصية جديدة تستغرق اكثر من شهر، لانك ستمضي شهرا للتطوير و شهرا لاصلاح العلل و التاكد من ان البرنامج خالي من العلل الفادحة.

سياسات عقيمة من هذا النوع لها اسم عند الشركات الكبيرة: Quality Assurance

و ستكون في قاع الهاوية حينما تقنع نفسك ان هذه السياسات العقيمة هي اللتي تجعل منك مبرمجا “محترفا”

الطريق الى النور

ماذا لو كنت تمتلك الادوات اللازمة لاتمتة كل الاعمال المضنية؟ سيكون بامكان ان تركز 100% (او 98%) من جهودك في تطوير المشروع بدلا من ان تشتت ذهنك في امور ثانوية.

سيكون بامكانك اطلاق تحديثات بشكل يومي، بل ربما عدة مرات في اليوم.

لن تخاف من وجود بعض العلل لانك تعرف ان تستطيع اطلاق تحديث يصلحها بسرعة فائقة!

تستطيع تطوير خواص جديدة بشكل سريع من دون ان تشعر بلخبطة بين النسخ المختلفة من المشروع.

منافسيك قد يستغرقون شهورا (!!!) في اطلاق خاصية بسيطة بينما يمكنك ان تقوم انت بتطويرها في غضون اسبوع.

يتحدث ‏Paul Graham عن انه عندما كان يدير موقع viaweb كان يقوم باصلاح العلل و اطلاق التحديث للموقع اثناء الحديث مع الزبون على الهاتف! تخيل نفسك مكان الزبون، صادفت مشكلة في الموقع و قمت بالاتصال بالشركة و اخذت تشرح لهم المشكلة اللتي صادفتها و تطلب منهم ان يرشدوك الى حل او طريقة للالتفاف حول المشكلة. و بينما انت على الهاتف معهم يقولون لك “جرب ان تفعل ذلك الان مرة ثانية” .. و اذا بالمشكلة قد اختفت!!!

بينما شركة اخرى تواجه مشكلة مع منتجهم، فتتصل بالشركة و تطلب منهم حلا .. فيخبرونك انهم “يعملون” عليها و انهم سيصدرون حلا لها “قريبا”، و هذا القريبا يعني في الحقيقة “خلال شهرين او ثلاثة”.

يتحدث Paul Graham ايضا عن ان بعض منافسيهم كانوا يقومون ببهرجة دعائية كبيرة حول خاصية جديدة اضافوها لمنتجهم و يقومون باطلاق بيانات صحفية و عقد مؤتمرات و ارسال ايميلات .. و و .. و مع ان الخاصية الجديدة سخيفة و غير مهمة، و لكنه قد يقرر ان يضيفها هو ايضا الى موقعه .. على الاقل فقط لاغاضة منافسيه! و ذكر انه (هو و شريكه في المشروع) كانوا يقومون باضافة الخاصية نفسها الى منتجهم في غضون يوم او يومين!

معادلة الكفائة

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

كل شيء في النهاية يدور حول الاتمتة. و كل الادوات اللتي تستخدمها هدفها النهائي هو اتمتة المهام المضنية، حتى و ان لم يكن ذلك واضحا لك.

محرر النصوص ماهو في الحقيقة الا اداة لاتمتة تحرير الملفات النصية. في السابق لم يكن هناك مثل هذه الادوات بل كان عليك ان تستخدم punch cards، اي تقوم بتخطيط البرنامج على الورق و من ثم ترجمته يدويا الى لغة الالة و كتابته بعد ذلك على punch card

الـ compiler ما هو الا اداة تقوم باتمتة عملية التحويل من لغة برمجية معينة الى لغة الالة.

الـ IDE ما هو الا اداة تقوم باتمتة عملية تجميع عدة ملفات نصية تكون مشروعا واحدا.

البعض لا يفهم الامور بهذا الشكل! البعض يظن ان Visual Studio هو مترجم للسي بلص بلص! و هذا بعيد عن الحقيقة تماما. Visual Studio هو اداة لادارة المشاريع و ليس compiler.

يمكنك ادارة المشاريع من دون VS، و لكنها عملية مضنية، اذ سيكون عليك ان تقوم بترجمة كل ملف على حدة و من ثم تجميع الناتج من العملية و تحويله الى ملف تنفيذي. VS مهمته هي اتمتة هذه العملية لكي يكون بامكانك التركيز على البرنامج بدلا من الانشغال بكيفية تجميع عدة ملفات الى برنامج واحد.

و العملية في الحقيقة تتطلب عدة خطوات لو كنت تريد القيام بها يدويا:

ترجمة compile كل ملف على حدة و انتاج object files
ربط linking للملفات الناتجة

و لكن هذه العملية قد تستغرق وقتا طويلا، فلماذا تقوم بترجمة ملفات لم تقم بتغييرها اصلا؟ تحتاج فقط الى ترجمة الملفات اللتي تغيرت، فلهذا تصبح الخطوات:

ابحث عن الملفات اللتي تغيرت
قم بعمل compile لها
قم بعملية linking

لماذا تدوخ نفسك بهذه الاعمال اذا كان الكومبيوتر يستطيع ان يقوم بها نيابة عنك؟

اداة make على يونكس لها نفس المهمة، فلكي تقوم بتجميع البرنامج بخطوة واحدة (من دون الاستعانة بـ IDE) تقوم باعداد ملف Makefile بسيط يشرح علاقة الملفات ببعضها و من ثم تقوم بترجمة و تجميع البرنامج عن طريق امر واحد .. و هو make و عن طريقه يقوم الكومبيوتر بالبحث عن الملفات اللتي تغيرت ليعيد ترجمتها و من ثم يعيد عملية الربط linking بين الـ object files الناتجة عن عملية الـ compile

و هنا يظهر الفرق بين المبرمج الماهر — الهاكر، و بين مهندس البرمجيات.

مهندس البرمجيات ليس لديه هذا المفهوم لفكرة الـ automation، كل ما يعرفه انه تعلم عن شيء اسمه compiler و شيء اسمه IDE و لكنه لا يقوم بالربط بين وجود هذه الادوات و بين اتمتة عمليات مضنية. من وجهة نظهره ان هذه الادوات تقوم بشيء جديد كان مستحيلا في السابق!! وهو في الحقيقة واهم.

الـ compiler لا يقوم بشيء كان مستحيلا في السابق. الناس من قبل كانوا يخططون البرنامج على الورق ثم يقومون بترجمته الى لغة الالة يدويا، و ما يقوم به الـ compiler هو اتمتة هذه المهمة، فبدلا من ان تقوم بالتفكير في كيفية التعبير عن البرنامج بلغة الالة، يقوم الكومبايلر بهذه العملية نيابة عنك.

و كذلك الـ IDE لا يقوم بعمل شيء جديد كان مستحيلا في السابق، بل هو اداة تقوم باتمتة بعض العمليات المتعلقة بادارة المشاريع، و خصوصا عملية ربط ملفات المشروع مع بعضها لانتاج ملف تنفيذي في النهاية. و هو ليس امر مستحيل، بل يمكن القيام به بدون اي IDE على الاطلاق، كل ما تحتاجه هو عمل compile لكل ملف قمت بتغييره و من ثم عمل linking لكي تحصل على ملف تنفيذي (في العادة المشاريع الحقيقية تتطلب اكثر من ذلك و لهذا للـ IDE حدود، و هو في الحقيقة ليس بيئة تطوير متكاملة كما يوحي اسمه).

صحيح ان هذه الادوات لا تقوم بشيء جديد في حد ذاتها، و لكن وجودها و قيامها باتمتة المهام المضنية يفتح لك ابوابا جديدة لم تكن موجودة من قبل. فبدلا من ان تمضي نصف الوقت في تحويل البرنامج الى لغة الالة، يقوم الكومبايلر بالمهمة نيابة عنك لتركز انت في كتابة البرنامج.

و لكن الكثير من الناس لا يقومون ذهنيا بالربط بين الاتمتة و بين زيادة الكفائة، فيتوهمون ان هذه الاداة او تلك قامت باختراع جديد لم يكن ممكنا في السابق.

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

بينما في عالم الوندوز، لا تجد مثل هذه الادوات، بل تجد برامج ضخمة معقدة، مثل Visual Studio، يسمونها IDE، و هو اداة كبيرة من اصدار شركة تجارية، انتج بهدف بيعه الى شركات تجارية اخرى و التربح منه ماديا. صحيح ان اللذي نفذ هذه الاداة الضخمة هم في النهاية مبرمجون، و لكن السياقات اللتي قادت لانتاج هذه الاداة و الاهداف المرادة منها بعيدة كل البعد عن المبرمج. فجول ستوديو اداة للبيع و الاستهلاك: قبل ان تباع تقام لها حملة ترويج و بهرجة دعائية، قد يصاحبها كم من المصطلحات غير المفهومة لكي تشعرك بانك جاهل .. و في النهاية يراد منها ان تباع الى مستهلكين.

فالمبرمج هنا لا يقوم بعملية الاتمتة بنفسه .. فهي “معقدة جدا” بالنسبة له، بل ينتظر من يقوم بها نيابة عنه. و هذا يتم من دون وعي مباشر منه، لانه لا يفكر بطريقة “كيف اسرع عملي”، بل يفكر بطريقة “كيف اقوم بعملية كانت غير ممكنة من قبل”. مثلا، كيف اقوم بكتابة برنامج بلغة دوت نت؟ اكيد انا بحاجة الى “البرنامج العملاق” فجول ستوديو. فهو يعرف الكومبايلر، و يعرف الـ IDE، و ينظر اليها على انها اختراعات عظيمة لا يستطيع من دونها ان يعمل اي شيء! (كيف اذن كان الناس يبرمجون قبل اختراع هذه الادوات؟)

و لكن ماذا لو واجه عقبة بعد ذلك، و لم يجد لها برنامجا عملاقا لكي يحلها؟ سيضطر الى القيام بكل شي بشكل يدوي، و قد لا يخطر بباله ان يكتب سكربت صغير يقوم بالمهمة نيابة عنه. فهو حين يواجه مشكلة تتطلب منه القيام بمهمة “مملة”، فإن طريقة تفكيره لن تقوده الى اتمتة هذه العملية. لانه يفكر في الامور من ناحية الامكانية او عدم الامكانية! فإذن كان يستطيع القيام بمهمته عن طريق فتح برنامج رسومي و القيام بعشر خطوات من داخله، فإن هذا بالنسبة له كافي جدا، لانه يرى انه “يستطيع” القيام بالمهمة، و هو راضي جدا بهذا الامر، و لن يتململ من ان العملية مضنية او عقيمة، لانه “محترف” و عنده حس المسئولية، و يعرف ان لديه عملا و يجب ان ينجز، و يعرف ايضا ان التململ من صفات “الهواة” و هو لا يريد ان ينزل الى مستواهم. و لعله ايضا يرى ان الصبر على هذه الاعمال العقيمة امر ضروري لا مفر منه. (لاحظ ان هذه الصفات قد تبدو صفات حميدة: المسئولية، الصبر، الرضا!)

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

و لهذا تجد الشركات الكبيرة مليئة بسياسات عقيمة، لان “المهندسين” فيها لا يفهمون انهم يجب ان يقوموا باتمتة الخطوات المطلوبة للقيام بالعمليات المهمة (مثل اطلاق الموقع) و اللتي تتسبب في تاخير المشروع اذا لم تدر بشكل جيد. فبدلا من ان يقوموا بتطوير ادوات تساعدهم على العمل بكفائة، يقومون بالتناقش مع الادارة و يخرجون بسياسات ادارية تقوم بوضع “خطط” لكي تتم العمليات المضنية على وجه سليم و باقل كمية ممكنة من المشاكل!!

و ربما اذا حالفهم الحظ سيجدون احدى الشركات اخرجت منتجا “عملاقا” ذو “واجهة رسومية جذابة” و قامت بحملة “دعائية” لترويج هذا المنتج. و قامت باختراع مصطلحات جديدة لكي تضفي هالة من القدسية على منتهجم. و طبعا ستجد انه مكلف و باهض الثمن! و رغم ان هناك بدائل عنه مفتوحة المصدر و مجانية، الا ان الشركة الكبيرة ستذهب مع المنتج ذو الواجهة الرسومية و المكلف الثمن، لان العاملين فيها لا يفهمون ان ما يحتاجونه هو مجرد اداة لاتمتة العمليات المضنية — بل يظنون انهم بحاجة الى برنامج ضخم و معقد، يظنون انهم بحاجة الى منتج يمكنهم من عمل شيء كان مستحيلا في السابق.

الامر ابسط مما يتخيلون بكثير.

كل ما يحتاجونه هي ادوات تقوم باتمتة المعليات المضنية لكي يستطيعوا ان يركزوا على تنفيذ عملهم بدلا من ان يجن جنونهم في تنفيذ تلك العمليات المضنية كل يوم.

What's missing from desktop linux

Thu, 19 Aug 2010 03:31:00 -0400

I’m a Linux user, I use Xubuntu on my laptop (Ubuntu, with the Xfce desktop), I like it quite a lot, it might lack some visual appeal, but it’s easily the best workstation I’ve ever used. Not only do the tools make you super productive, but the availability of these tools in the ubuntu/debian repositories is the best feature of ubuntu (and all debian derivatives); they are full of development tools and libraries for all kinds of things you can imagine. Truly, the programmer’s heaven! I can’t understand how anyone can get anything done without access to such repositories.

Alas, while it’s the best workstation for development, it’s not necessarily the best desktop experience out there. The best desktop experience is, without doubt, the one provided by OS X.

People say many things about why they think desktop Linux sucks. For many people, it’s the lack of integration, the feeling that it’s just a bunch of different apps lumped together without any coherence. But for me, that’s not much of a problem, because my Windows setup was pretty much the same: I almost never used the standard windows tools; instead I always relied on other tools (usually open source, but not always) that do the job better and faster.

So that’s not really an issue for advanced users. Even for novice users it’s usually not an issue. If we’re talking about Ubuntu, it ships with a decent set of default programs and the user doesn’t care (and has no clue) whether or not they’re third party apps.

I use Xfce instead of Gnome. That might sound a bit weird, given that Xfce is not so mainstream. Most people would think the only advantage of Xfce is performance, but that’s not true at all. Xfce is just better than gnome; it provides a better desktop experience in my opinion.

Mac OS X is a great example of a well designed desktop on top of Unix. I might consider using it sometimes, but ultimately, there’s a reason I don’t want to slide down the slope of the Apple fanboyism: Apple’s products are aimed at consumers; if you’re a consumer, you are, by definition, not a hacker. I’m not suggesting that real hackers don’t use OS X; in fact, many do so. I may do so myself, but all I’m saying is, there are reasons out there to not use Apple products.

There’s a reason, a very good reason, for Apple’s products to be the way they are. Consider how the iPhone is jailed: you can’t even put songs or videos on it without iTunes, the music database is not a folder with mp3 files; it’s effectively a locked, proprietary database. Similarly, the only way you can install apps on your iPhone is through the app store. There’s no such thing as going to another site and downloading an app then installing it. It’s not just that iPhone doesn’t provide support for that; it purposely prevents you from doing that.

This model makes it so that the only way (and the easiest way) to install apps on the iPhone is to buy them from the app store. It works to make you get used to the idea that the only way to install applications is to pay for them. I consider this a dangerous habit, and I’m consciously trying to avoid being a part of that culture. I’m not opposed to making money from developing software; I’m opposed to enforcing artificial restrictions on your freedom to use your own device, dammit!

None the less, this model makes it almost guaranteed that you can sell apps for the iPhone without having to worry about “piracy”. Unfortunately, it also makes it so that you can’t start developing anything without Apple’s permission.

I tried OS X in a virtual machine, and while it’s stunningly beautiful and well designed, I noticed that it fosters a similar kind of experience. To get the full OS X experience, you have to “buy” all your apps, otherwise your OS won’t be really functional. Installing applications any other way could easily ruin the desktop experience, the same way that jail-breaking gives a crappy iPhone experience.

If you didn’t know Unix before hand, would you ever learn to become a hacker by using OS X? I would say: probably not. ِApple products tend to discourage tinkering. Today’s hackers might like OS X because they already know Unix and they know there’s a Unix (FreeBSD) underneath Aqua, but tomorrow’s OS X users may never know what tinkering/hacking is. They might even think that tinkering is illegal!!

So while I’m not all that excited about actually using OS X, I am interested in what we can learn from Aqua about making great desktops.

People often miss the mark when they try to copy apple’s products. They try to copy individual elements, without giving thought to what value it adds. They copy the end result without thinking about why it was done that way. What good does it do if you have a blue button widget like the one from Aqua? It’s not the specific color or shape of the button that matters.

I think there are simple principles that can lead to a great desktop experience, and if we keep them in mind, we can create a great desktop experience; they are:

Simplicity, elegance, and beauty.

Other (inferior) desktops always lack one or more of these elements. Some people might point out another important factor: “attention to details”; but this really just means dedication to beauty and elegance, so it’s implicit in the sense that hackers tend to always be dedicated anyway; this is not in itself a problem with Linux; the problem is what to dedicate yourself to.

Here’s the problem: none of the Linux desktops I tried combine these elements well enough.

Gnome is simple, but not so elegant, and definitely not beautiful.

Xfce is simple and quite elegant, but unfortunately, not so beautiful.

KDE is beautiful, but not so elegant and definitely not simple.

Well, at least KDE4; I don’t know about KDE3, people say it’s better, but I tried KDE4 for a while and I just couldn’t stand the experience. Nice flashy effects and everything, but overall it is just a big mess.

I’m sticking with Xfce, it has 2 of the 3 qualities that make a great desktop, while gnome and kde each has only one.

So in short, using Xfce as the ideal desktop, I can say that the only thing I see missing from the Linux desktop is beauty.

What do I mean by beauty? Why am I separating it from elegance? How can something be beautiful without being elegant?

What I mean by “beauty” in this context is visual appeal and wow effect. When you look at a picture of the desktop, does it make you say “wow, look at it, so shiny and beautiful!!”? That’s beauty. By this definition, there can be something that’s beautiful but not elegant.

Windows 7 is an example of beauty, in terms of visual appeal. I do think that Windows 7 (like KDE 4) lacks the element of elegance (although KDE 4 lacks it more). Elegance in this context means to me that everything is in the right place, the visual elements are neatly placed and have good proportions and spacing between them.

Here’s an example of something elegant that isn’t quite visually appealing (no “wow” effect): Google Chrome. It’s not visually appealing too much, but it’s simple and very, very elegant. Over all, most of Google products are simple and elegant, but not very appealing visually. I think this is a quality you can find in most hackers: they can spend a lot of time to make sure the product is simple and elegant, but making it visually appealing usually requires graphic designers.

And yes, things can be simple but not elegant: by having fewer UI elements, you make things simple, but by giving them the wrong size and proportions, you make it clunky. When this happens, the UI will look messy and ugly; it will feel awkward, like an incomplete hack. This is a quality you can find in most Gtk+ applications.

The beautiful apps on Linux are often clones of Mac apps: gnome-do is a clone of quick-silver, and Docky is a clone of the OS X Dock. Also, notice how these apps don’t really use any of the standard widgets provided by the toolkit. They’re both based on gtk, but they never use any of its widgets.

Let’s face it: Gtk cannot produce beautiful apps, not in its current form. Unless you completely ignore its widget set and write your own.

Chrome (on Linux) also uses Gtk, but none of its widgets.

There’s something fundamentally wrong with the way Gtk thinks about the user interface. If you think about a few Gtk apps you’ll find they all have similar traits: the proportion and placement of widgets don’t make any sense, you have big toolbars, thick status bar, everything that is click-able is created as a button, and a whole bunch of UI details that are just wrong. Everything about Gtk is designed for simplicity, but almost none of it is designed for elegance or beauty. Just compare “Nautilus” in Gnome to the “Finder” in OS X.

No amount of themeing can hide the inherent ugliness in gtk. You can mask it and present a screenshot that makes you go “hmm .. not bad”, but if you use it for two minutes, you’ll see a total lack of elegance and aesthetics.

Qt is a lot better in this regard. UIs produced with Qt tend to be much more elegant, and with a bit of themeing, the result can be stunningly beautiful. Unfortunately, this elegance gets lost in KDE4 apps, for some reason!

I think gtk can be fixed; I don’t know how, but I’m sure if some effort is put into designing it for beauty and elegance (and not just simplicity) then it can get a lot better.

Qt is already good, I use it anytime I want to create a desktop app. I don’t see any inherent flaw in Qt itself; only in the way KDE (and its themes and apps) use it.

Other random details

The Xfce panel lacks one thing: sane backgrounds. This is a defect that xfce shares with gnome: the only way to give the panel a nice bevel background is with a static image, and the panel size has to be exactly the same pixel height as the image, if you make it bigger by one pixel, things become ugly (Aqua panel is probably not so different, Apple just hides it by making the panel non-resizable). This also makes it impossible to get a decent looking vertical panel.

There’s something to learn here from the kde plasma panels.

The other thing to learn from the kde panel is how to represent the task list: why use the standard button widget for them? it doesn’t make any sense! This is an instance of gtk being too simple and asking you to use button widgets for everything.

Another thing to learn from KDE are the window effects: kwin produces some really nice visual effects like wobbly windows (when moving) and magic lamp minimization. Most other effects can be discarded, in my opinion.

Yet another awesome thing from kwin is the ability to hide borders and show a resize handle on the lower left corner.

I know compiz had the wobbly windows thingy first, but compiz’s configuration dialogs are a horrible mess, plus compiz’s magic lamp effect is ugly.

My point is that these effects should be embedded into the mainstream window managers, or well, at least the xfce window manager.

My real beef is the default firefox theme in Linux; it embodies (almost) everything that’s ugly about gtk.

So, fix gtk, add some tweaks here and there, design with beauty in mind, and we’ll be able to stick our tongues out to Apple and their fanboys; I mean, we’ll have a great Linux desktop.

خبرة "العمل"

Sun, 04 Jul 2010 20:09:58 -0400

الفكرة الشائعة انك حين تحصل على وظيفة فإن هذا سيفيدك في المستقبل لانه “خبرة”، و قد يكون هذا صحيحا في الكثير من المجالات .. لكن ليس في البرمجة.

بل على العكس، قد يكون الحصول على “وظيفة” قاتلا للخبرة و مضرا (ان لم نقل مفسدا) لقدراتك البرمجية (و لصحتك العقلية ايضا).

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

هل يمكن ان تحصل على هذه الخبرة في العمل؟ كلا!

ماللذي تحصل عليه في العمل؟ الشركات عادة تفضل ان تقوم بتنظيم العمل على طريقة “الاحوط”، اي ستجد ان هناك العديد من الـ processes العقيمة اللتي وضعها المدير او المدراء من اجل “تقييد” حركة المبرمجين و احكام “السيطرة” على النشاطات البرمجية اللتي يقوم بها الموظفين.

حين تبدأ العمل، خصوصا اذا كنت حديث التخرج، سيضعونك في خانة الـ junior developer، بمعنى انهم يعتبرون قدراتك و خبرتك “محدودة” و لهذا سيوكلون اليك مهام “بسيطة”، على قدك يعني، و لا تتوقع انك ستشارك في تطوير برامج حقيقية! هل تعتقد انهم يثقون بك لدرجة ان يسلموك جزء مهم من المشروع بهذا الشكل؟

و حتى لو “ترقيت” بعد ثلاث او اربع سنين مثلا و اصبحت senior او intermediate، فلن تكون على درجة عالية من التحكم: لست انت من يتخذ القرارات بخصوص تطوير البرنامج، و لا تستطيع تصميم اي شيء فيه، بل هناك شخص اخر يسمى product manager هو اللذي يحدد لك هذه الاشياء، و انت ما عليك سوى “التنفيذ”.

و الانكى من كل هذا انك على الاغلب ستقتنع في اللاوعي ان هذه هي الطريقة “الصحيحة” لتطوير البرامج!

فالعمل في الوظيفة يفسد العقل من عدة نواحي:

باجبارك على القيام باعمل مملة بسبب سياسات الشركة العقيمة
تقييد حركتك و بالتالي عدم اكتسابك لخبرة برمجية جيدة
اقتناعك بشكل غير مباشر ان السياسات العقيمة هذه طريقة صحيحة لادارة المشاريع
اقتناعك انك تحتاج الى product manager لكي يخبرك اللذي عليك فعله

المحصلة النهائية هي قتل روح الابداع فيك و تحويلك من شخص فنان يهوى عمله … الى مجرد موظف عادي مثل غيره

بالمحصلة لن تحصل على اي “خبرة” برمجية لان سياسات الشركة تقضي ان الموظفين الجدد لا يقومون بمهام برمجية حقيقية.

البنية التحتية لمجتمعات المبرمجين و المهاويس العربية (بالذات تجمعات المصادر المفتوحة)

Wed, 26 May 2010 15:14:00 -0400

في مقالة “كيف تصبح هكرا”، يقول ايرك ريمند تحت عنوان Status in the Hacker Culture

Help keep the infrastructure working

The hacker culture (and the engineering development of the Internet, for that matter) is run by volunteers. There’s a lot of necessary but unglamorous work that needs done to keep it going — administering mailing lists, moderating newsgroups, maintaining large software archive sites, developing RFCs and other technical standards.

People who do this sort of thing well get a lot of respect, because everybody knows these jobs are huge time sinks and not as much fun as playing with code. Doing them shows dedication.

باعتقادي اننا ينقصنا بالفعل قدر كبير من البنية التحتية اللذي نحتاجه للرقي بالتجمعات التقنية العربية على الانترنت .. و اعني بهذا بالذات مجتمعات الهواة و المهاويس و مشجعي طرح المصادر المفتوحة و الحرة.

قبل قليل كنت اتصفح موقع الفريق العربي للبرمجة و وقعت عيني على موضوع الاخ skeleton_eel الخاص بدليل البرمجيات الحرة و المفتوحة

و لفت انتباهي ان الملف مستضاف على موقع archive!!

لماذا لا توجد جهات توفر خدمة محترمة لاستضافة مثل هذه الاعمال؟

و تذكرت اكثر من مرة رايت مواضيع في مجتمع الفريق العربي للبرمجة و كانت الملفات مستضافة على مواقع استضافة “مؤقتة” مثل rapidshare و اخواتها

اي باختصار .. ليس لدينا البنية التحتية المناسبة

من ضمن ذلك عدم وجود استضافة جيدة للملفات يعتمد عليها، و إن وجدت فلعلها محدودة و لا يستطيع الكثيرون ان يصلوا اليها

ليس هذا فقط، بل لا يوجد نموذج ناجح لنشر المواضيع المهمة اللتي يجب ان تبقى في مكان ثابت بحيث تصلح ان تكون مرجع يعتمد عليه.

اغلبنا ينشر مقالاته او مواضيعه عن طريق المنتديات، و لنراجع ما لهذه الطريقة من سلبيات:

المنتديات لا تبقى، قد تختفي او تتغير عناوينها او يتم تحديث نسخة المنتدى، و بالتالي جميع العناوين URLs السابقة للمواضيع تتغير!
تنسيق الموضوع يعتمد على نوع المنتدى، فاذا احتفظت بنسخة من النص الخام للموضوع (لليوم الاسود) و اردت نشرها فيما بعد في مكان آخر اكثر ثباتاـ ستواجه مشكلة عويصة و هي تحويل التنسيق من المنتدى السابق الى المنتدى الجديد او الى البلوك اللذي تريد النشر فيه.
اذا كان الموضوع يحتوي على صور فعلى الاغلب سيكون مستضافا على خدمة استضافة صور مجانية، و هي كلها خدمات غير مضمونة على المدى البعيد و لا تصلح ان تعتمد عليها اي وثيقة تريد ان تصبح مرجعا.

لاحظ الوثيقة المذكورة اعلاه (كيف تصبح هكرا) .. لاحظ رابطها، هل تشاهد شيئا غريبا؟؟ انه ليس منتدى و لا مدونة ولا اي شيء من هذه التقنيات “الحديثة”، بل هو تقنية بسيطة جدا، مجرد صفحة هتمل ثابتة! المهم انها مستضافة في مكان مأمون يصلح ان يعتمد عليها لاستضافة وثيقة مرجعية كهذه الوثيقة.

و اذا عدنا الى تجمعات المبرمجين العرب، هناك بالفعل بعض البنى التحتية، لكنها متفرقة و مبعثرة. هناك مشروع عرب آيز، و لديهم بنية تحتية متميزة (بحسب ما اظن)، و لكنهم تقريبا في عالم اخر و وادي اخر بعيد تماما عن منتدى الفريق العربي للبرمجة مثلا، او منتدى “مجتمع لينوكس العربي”. هناك ايضا مشروع اعجوبة (توزيعة لينوكس مبنية على فدورا)، و لقد شاهدت الموقع و الويكي و البوتقة (مستودع البرامج) و هو جهد متميز بالفعل، و يحتوي بنية تحتية متميزة ايضا.

اي ان هناك بعض البوادر الجيدة، و لكنها قليلة، و لا توجد نقاط وصل بينها و بعض.

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

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

فهل الحل ان نعتمد نحن ايضا على القوائم البريدية مثل لينوكس مثلا؟؟

في الحقيقة انا رأيي انه لا! و بالمناسبة، المضحك في الامر ان القوائم البريدية، ان وجدت في عالمنا العربي، فاغلبها هي مجموعات ياهو، و اغلبها (ان لم نقل كلها) هي مجموعات سبام بكل معنى الكلمة! نكت و صور و اخبار فنانين و ايميلات من نوع “امانة في عنقك لازم تمررها الى كل اصدقائك”.

ما نحتاجه بحسب رأيي هي تقنيات بسيطة تحتوي على خصائص معينة:

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

و كمثال على تقنية حديثة (غربية المنشأ) تحتوي هذه الصفات (باستثناء دعم اللغة العربية): موقع stackoverflow

و جميعنا يعرف مقدار نجاح هذا الموقع.

البرمجيات الحرة و تطوير التكنلوجيا في العالم العربي -- نسخة منقحة (كثيرا)

Tue, 08 Dec 2009 13:15:00 -0500

هناك فكرة او زعم يطرح دائما في بعض الاروقة التقنية العربية، هذه الفكرة تتمحور حول انه بدون ثقافة احترام الملكية الفكرية و رخص الاستخدام, لن تكون هناك صناعة برمجيات محترمة في الوطن العربي لان البرامج سوف “تسرق” (يقصدون تستنسخ) و يتم تداولها بالمجان و تفلس الشركة المنتجة.

بداية، هذا الكلام فيه نسبة من الصحة، و لكنه ليس صحيح تماما، فهو يركز على نقطة معينة و لكنه يغفل الكثير من النقاط.

ما نحتاجه هو وسيلة لانشاء شركات (ربحية) تقوم بتطوير البرمجيات و الربح عن طريقها.

هذا لا يعني بالضرورة اننا نحتاج ثقافة احترام الملكية الفكرية، و لا يعني اننا يجب ان نخرج فتاوى تحرم نسخ البرامج.

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

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

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

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

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

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

لننظر الى بعض الامثلة و نرى كيف يمكن جني ربح من خدمة او منتج مجاني.

لننظر الى صناعة المسلسلات العربية.

اولا المسلسلات تذاع بالمجان على التلفزيون، و كل الناس يمكن ان يتشاركو فيما بينهم .. هل سمعت يوما باحد رفض اعارة فيديو لجاره او صديقه لانه “ممنوع”؟

القنوات التلفزيونة العربية تقوم الان بوضع المسلسلات على مواقعها, كمثال على ذلك: http://shahed.mbc.net

الية الربح في هذا المجال تعتمد على بيع المادة للتلفزيون، و ليس للافراد. بالطبع لا بد من وجود نوع من الحماية للملكية الفكرية لكي تكون هذه الالية مجدية، و الا لكان يمكن للقنوات التلفزيونية ايضا ان “تتشارك” المسلسلات فيما بينها و لا تحصل الشركة المنتجة على شيء يذكر.

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

و بمناسبة الحديث عن التلفزيون، فالقنوات التلفزيونة في حد ذاتها مثال جيد على خدمة مجانية تحصل على الارباح عن طريق الاعلانات و ليس عن طريق اجبار الافراد العاديين على الدفع مقابل المشاهدة.

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

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

فرض الملكية الفكرية على الافراد في الوطن العربي معناه نقل الاموال من جيوب الشعوب العربية الى جيوب الشركات الغربية.

انا اعتقد ان ما نحتاج المزيد منه هو ثقافة البرمجيات الحرة (على مستوى الافراد و الشركات).

كيف؟

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

النموذج الناجح لا يعتمد فقط على “بيع” سيديهات كما يباع البطيخ في سوق الخضرة. لكي يكون المنتج ناجحا و مفيدا لا بد ان يكون مدعوم بشكل جيد و لا بد ان تاتي معه مجموعة من الخدمات و الا اصبح بدون قيمة حقيقية.

البرنامج ليس خضرة تاكلها لمدة ربع ساعة ثم تذهب، البرنامج قيمته ليست في انه برنامج بل قيمته بحسب الخدمة اللتي يقدمها للمستخدم. برنامج بدون دعم لا يقدم اي قيمة حقيقية بل يقدم مجموعة من المشاكل.

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

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

نحتاج ثقافة تنتج مبرمجين متحمسن مندفعين .. يفكرون خارج الصندوق و يغردون خارج السرب. سمهم ما شئت: geeks, hackers, nerds ..

ثقافة البرمجيات الحرة: هي ثقافة مشاركة العلم, ثقافة المساهمة في التقنية و البرمجيات من قبل الجميع, ثقافة الانتاج (اذا كنت تريد خاصية جديدة في البرنامج, اضفها انت, او جمع فريقا يقوم بذلك, او وظف مجموعة مبرمجين ليقوموا بذلك)

ثقافة الملكية الفكرية: هي ثقافة احتكار العلم, ثقافة ملكية الافكار من قبل الاغنياء و الشركات العملاقة, ثقافة الاستهلاك (اعطنا نقودك و خذ منتجاتنا, و لا تشارك بها مع احد, و لا تحاول تقليد البرنامج او هندسته عكسيا)

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

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

المنصات المفتوحة توفر بنية تحتية رائعة يمكن الانطلاق منها لتطوير الكثير من التقنيات. الرائج حاليا في عالم شركات البرمجة هو انشاء تطبيقات ويب، اي برمجة “مواقع” توفر خدمات مهمة و معقدة بحيث ان الموقع ليس مجرد صفحة بها نصوص و صور بل هو تطبيق بكل ما للكلمة من معنى. و المنصات المفتوحة هنا تقدم ميزة كبيرة لمطوري تطبيقات الويب، ليس فقط لانها مفتوحة و مجانية، بل لانها تتفوق على المنصات المغلقة بمراحل هائلة من ناحية الجودة و القوة و تقديم الفائدة للمبرمج في تسهيل عمله.

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

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

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

لاحظ مثلا لعبة تحت الرماد, وجدتها الصيف الماضي تباع في احد المحلات في دمشق و اشتريتها (نسخة اصلية) ليس لاني اؤمن بالملكية الفكرية و لكن رغبة في المساهمة في دعم هذا المشروع. شغلت اللعبة و اذا بها متواضعة الى ابعد الحدود, ربما تصلح كاصدار alpha و لكن لا تصلح في صيغتها الحالية كمنتج نهائي يعرض للبيع!! و لا اريد الانتقاص من جهود الفريق بل احييهم و احترمهم جدا جدا, و لكن ربما يحتاج الفريق خمس سنوات اخرى حتى ينتج لعبة بمستوى quake II مثلا, و ربما 10 سنوات اخرى قبل انتاج لعبة بمستوى الالعاب الحالية مثل half-life2, و طبعا في ذلك الحين ستكون الالعاب الغربية وصلت الى مراحل اكثر تطورا بكثير و لن يشتري احد الالعاب العربية بل سيتجهون الى الالعاب الغربية.

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

طبعا هناك سؤال و هو، لنفرض انهم اعتمدوا منصحة حرة مرخصة بالـ GPL، كيف سيبيعون اللعبة و كيف سيربحون؟

و هذا سؤال لا اعرف اجابته. و لكن يمكن مثلا اخذ محرك Quake III و المرخص تحت GPL v2 و يمكن دراسته و تطوير لعبة عليه. اذا طورت لعبة عليه يجب ان تكون حرة و لهذا ربما لا يمكن ان تكون مجانية (يمكن ان تباع و لكن يجب ان تكون حرة). و لكن العمل على مثل هذا المشروع لفترة معينة اكيد سيكون دفعة تقنية كبيرة لكل من عمل عليه و سيكسبهم خبرة ربما تمكنهم من تطوير محرك جديد بطريقة افضل بعشرات المرات من المحرك الحالي.

هذه الادوات متوفرة ليس من اليوم و البارحة، بل من زمان، فاين العرب منها؟

انها مسألة ثقافة، فالكثير من التقنيين و المبرمجين يتوق لنموذج ميكروسوفت و يراه كتعريف للنموذج الناجح، ثم ينظر الى حال الدول العربية فيرى استحالة تطبيق هذا النموذج، فيشعر بخيبة امل و يرى بأنه لا فائدة. نفس الثقافة اللتي تنتج هذه النظرة، تنتج ايضا نظرة سلبية الى كل ما هو حر و مفتوح، فالبعض يظن ان المنصات المفتوحة هي لعب عيال و لا تصلح للاستخدام الحقيقي!! و هذه قمة السخافة فاي شخص عمل على هذه المنصات لفترة من الزمن يعرف انها متفوقة على نظيراتها المغلقة بمراحل — هذه اذا صح ان نعتبر الوندوز “نظير” لليونكس.

How do I choose a class?

Wed, 02 Dec 2009 12:44:05 -0500

Originally I wrote this as an answer to this question on stackoverflow:

OOP - How to choose a possible object candidate?

However, It was a bit long, so I stripped it of the talking points and just kept the basics.

So the short answer to the question of “How do I write good OOP code?” is:

Just write something that gets the job done, even if it’s ugly, then refactor continuously:

eliminate duplicate code (don’t repeat yourself)
increase cohesion
reduce coupling

But:

don’t over-engineer; keep it simple
don’t write stuff you ain’t gonna need

It’s not a precise recipe, just some general guidelines. Keep practicing.

Now, here’s the problem: lots of people learn OOP from Java books or Java schools, and most of what they learn is BS.

Don’t believe what the Java books/schools teach about objects; they’re lying.

Code objects are not related to tangible real-life objects; they are just constructs that hold related information together. Don’t think in terms of verbs and nouns; that’s a bunch of BS.

OOP is not an end, it’s just the means. If you follow the above mentioned guidelines, and your code doesn’t end up as a massive class hierarchy, don’t be sad, but be glad: for you have produced elegant code.

Classes don’t exist “out there”, you write them, as practical tools to solve your problem.

I think practical is the keyword here. Don’t try to come up with text-book abstractions.

مدخل الى git

Sun, 29 Nov 2009 19:40:00 -0500

هذا مقال اصله موضوع في منتديات الفريق العربي للبرمجة و كان عبارة عن نقاش, و احب الان ان احوله الى موضوع مستقل احاول تجميع نقاط النقاش كلها على شكل موضوع مترابط الاطراف

لسبب ما, لا اعرفه بالضبط, لم اجد مقالات كثيرة باللغة العربية عن انظمة الـ source code management, و لم الحظ اي تشجيع لاستخدام هذه الادوات, بعكس ما وجدت مثلا في المواقع الاجنبية مثل stackoverflow

حتى svn لا احد تقريبا يعرف ما هو بالضبط, سوى انه الاداة المستخدمة في مواقع استضافة الكود! و ربما اغلب من يستخدمه يكون مجبرا على ذلك فقط لارضاء موقع استضافة الكود, و على الاغلب يستخدمه باستخدام ادوات رسومية GUI و بالتالي لا يفهم شيئا عن النظام نفسه ولا عن اي من فوائده, ناهيك عن اهميته.

ما هو السورس كونترول هذا اصلا؟ “source control”

اي شخص يطور مشروعا لمدة تزيد عن اسبوعين سيجد نفسه يعاني من بعض المشاكل في تنظيم الكود و الاصدارات. اغلب الناس يبدأ باخذ نسخة من مجلد الكود بالكامل و ارشفته على شكل ملف zip و يسميه باسم المشروع مع اضافة رقم, مثلا:

my_project_1.zip
my_project_2.zip
my_project_3.zip
...
...
my_project_20.zip
my_project_21.zip
...
...
الخ

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

هذه المشكلة (اي اللخبطة الكبيرة) قد تحدث عندما تحاول تطبيق فكرة جديدة و ثورية, و لكن في منتصف الطريق تكتشف ان الفكرة غير قابلة للتطبيق, او انها معقدة جدا و ستاخذ وقت طويل …. او غير ذلك, فتضطر الى ترك الفكرة و العودة الى اخر اصدار عادي, او ربما تؤرشف الكود الملخبط هو الاخر في مكان آخر و تعود للعمل عليه فيما بعد, فيصبح عندك فرعين من المشروع: الخط الرئيسي (العادي) و الخط الجديد اللذي تحاول ان تبرمج فيه بعض الافكار الجديدة “الثورية”.

المشكلة في هذا النوع من العمليات, اي الافكار الجديدة, او التطويرات الكبيرة اللتي قد تستغرق وقتا, هي ان المشروع سيكون “غير صالح للاستخدام” لفترة من الزمن, اي الى ان يتم الانتهاء من اضافة التطوير, و هذا طبعا لو نجح التطوير, حيث ان المشكلة الاخرى هي احتمال ان الفكرة قد تفشل و يجب التخلص منها و العودة بالمشروع الى ما كان عليه.

هذه المشكلة قد تكون عائقا نفسيا امام المبرمج تمنعه من اضافة افكار ثورية او تطويرات نوعية للمشروع, لانه لا يريد ان يدوخ نفسه بالتعامل مع كل المشاكل المحتملة, فالتعامل مع المشاكل الناتجة بشكل يدوي سوف يسبب وجع راس كبير, و المبرمج يعرف ذلك لان له خبرات مريرة سابقة مع هذه الامور, و لا يريد تكرار الكابوس مرة أخرى, لذلك يقرر ان “يمشي الحيط الحيط و يقول يا ربي السترة”, كما يقول اخوتنا السوريون.

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

من هنا كان لا بد من ادوات تقوم بأتمتة “automation” هذه العمليات المضنية:

حفظ نسخ من المشروع في اوقات معينة
انشاء تفرع في خط التطوير بحيث يكون هناك اكثر من نسخة من المشروع بشكل متوازي
مع امكانية دمج الفرع مرة اخرى الى الاصل عند الانتهاء من التطوير او حين يصل الفرع “الثوري” الى حالة جيدة من الاتزان

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

فـ git يقوم لك بهذه المهام, و على اكمل وجه.

اذا اعجبك هذا الكلام لحد الان, فما رأيك ان تقفز من فورك لقراءة الدرس الرسمي git tutorial

تستطيع ايضا ان تواصل قرائة المقال, حيث سنقوم بعمل مشروع تجريبي صغير .. لكن يفضل قراءة الـ tutorial قبل ذلك, اذا كنت تنوي المتابعة بجد.

و بالمناسبة, فنظام git في حد ذاته يعد نقلة ثورية في عالم الـ source management, لان الادوات الاخرى في السابق كانت تقوم فقط بمهمة واحدة: و هي حفظ نسخ من المشروع في اوقات معينة. اما ادارة التفرعات المتوازية و اعادة دمجها مع بعض, فكان يعد كابوسا في الادوات القديمة مثل cvs,

و للامانة فـ git ليس اول نظام يقوم بهذه الاشياء, و لكنه اول نظام حر و مفتوح المصدر, هو و merculiar حيث سبقهما الى ذلك نظام اخر لكنه غير مجاني و غير حر, و اسمه bitkeeper, و اصلا نظام git و نظام merculiar تم تطويرهما كبدائل حرة لذلك النظام, حيث ان الموضوع له تاريخ مليء بالمشاكل مع مطوري لينوكس.

ما يهمني في git هو كما قلت: الاحتفاظ بتاريخ تطوير المشروع, و السماح للمبرمج بكل سهولة ان يقوم بعمل فروع تطوير متوازية مع امكانية دمجها فيما بعد.

هناك فوائد اخرى هامة مثل التعاون بين عدة اشخاص على مشروع واحد, و لكن هذا الامر خارج نطاق هذا المقال, و على من يريد تعلم ذلك ان يقرأ الدروس و الـ manual

لنتفق على ترجمة بعض المصطلحات:

repository: مستودع
commit: إيداع
branch: فرع؛ فرع تطوير
branching: تفريع؛ القيام بعمل فرع
merge: دمج
log: سجل؛ سجل الايداعات

حين كنت اناقش الموضوع في منتديات الفريق العربي للبرمجة, طلبت من المشاركين ان يقترحو مشروعا برمجيا ما يمكن ان نطوره باستخدام git, فقام الاخ خالد بطرح مشروع بسيط encat هو عبارة عن تشفير و فك تشفير ملفات.

في حينها كنت استخدم وندوز .. لهذا سطور الاوامر القادمة ستكون من وندوز:

اولا فكيت المشروع عندي الى مجلد C:\code\encat

بعدين نفذت هذه الاوامر

C:\code\encat>git init
Initialized empty Git repository in C:/code/encat/.git/

C:\code\encat>git add *.cpp

C:\code\encat>git add *.h

C:\code\encat>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." to unstage)
#
#          new file:   Console.h
#          new file:   EncAT.h
#          new file:   Random.cpp
#          new file:   Random.h
#          new file:   main.cpp
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#          Debug/
#          EncAT.ncb
#          EncAT.sln
#          EncAT.vcproj
#          EncAT.vcproj.Toshiba.aljudy.user
#          random.atp
#          random.dec
#          random.enc

C:\code\encat>git commit -m"Initial commit"
[master (root-commit) 618b61a] Initial commit
 5 files changed, 712 insertions(+), 0 deletions(-)
 create mode 100644 Console.h
 create mode 100644 EncAT.h
 create mode 100644 Random.cpp
 create mode 100644 Random.h
 create mode 100644 main.cpp

C:\code\encat>

المهم في البداية: git init لانشاء repository في المجلد الحالي, بعد تنفيذ هذا الامر سيكون هناك مجلد اسمه .git و هو يحتوي بداخله على الـ repository

ثم git add لاضافة الملفات اللتي نريد اضافتها الى الـ repository: هذا الامر لا يفعل شيئا سوى اخبار git اننا نريد ان نضيف هذه الملفات الى الـ repo, اي انه خطوة تحضيرية, تقوم بتحضير الملف للايداع, و لكن لا تودعه على الفور.

ثم git commit من اجل عمل commit (إيداع) لهذه الملفات داخل الـ repository مع اضافة رسالة commit message

الان:

C:\code\encat>git log
commit 618b61a4c1f0d67c8cb7949ea15fd86ef794b582
Author: hasen j 
Date:   Thu Jun 4 22:17:15 2009 -0600

        Initial commit

C:\code\encat>

شغلت البرنامج و جربته, و كما قلت انه لا توجد مراجعة للاخطاء المحتملة, فمثلا اذا كتبت اسم ملف غير موجود, فالبرنامج سوف “يزوع”

لهذا يمكن اضافة check قبل فتح الملف و قرائته. بعد ان نضيف هذا نعمل commit من جديد

قبل ان نواصل, لا بد من بعض الملاحظات:

حين نفذت هذه العملية كنت على وندوز و استخدم msysgit

msys هي عبارة عن بيئة لينكس مصغرة تعمل على الوندوز, طبعا ليست مزعجة مثل cygwin ابدا

فـ git مصمم اصلا للعمل على linux, و العديد من الاوامر اللتي تصدرها الى git تمرر الجواب عبر برنامج less

بمعنى: اذا كان الـ output طويل, ستراه صفحة صفحة, و حتى اذا كان الـ output قصير فايضا سيخرج عن طريق less

مما قد يسبب بعض الارباك لمن هم غير متعود عليه. تعليمات سريعة لاستخدام less:

التعامل بالكيبورد
q للخروج
j, k او الاسهم للتصفح للاعلى و الاسفل
space مسافة لتقليب الصفحات للاسفل
esc لا يفعل شيئا (في الحقيقة يفعل, و لكن هذا موضوع آخر)

الملاحظة الاخرى, ان كل commit يجب ان يكون معها message قصيرة تبين فيها مثلا ما هي التغييرات اللتي حدثت بين هذا الايداع و الايداع (الـ commit) السابق.

عودة للمشروع التجريبي, حيث كنت قد نويت ان اضيف error checking للتأكد من وجود او عدم وجود الملفات المطلوبة.

محاولتي الاولية لاضافة check فشلت نوعا ما, و لكن مع ذلك يمكننا ان نتعامل مع git لحفظ ما توصلنا له لحد الآن.

قمت بتحرير بعض الملفات و اضافة بعض الاكواد, لكي اريكم هذه الاكواد, انفذ الامر git diff و سيخرج لي مقارنة diff بين الكود الحالي و بين اخر ايداع commit

C:\code\encat>git diff
diff --git a/EncAT.h b/EncAT.h
index cac09a5..57acbbd 100644
--- a/EncAT.h
+++ b/EncAT.h
@@ -11,6 +11,10 @@

 namespace EncAT{

+       class IOFail
+       {
+       };
+
         inline void EncDec( char* memBlock, size_t blockSize, char* password, size_t passSize ){

                 for( size_t C = 0; C < blockSize; C++ )
@@ -33,6 +37,10 @@ namespace EncAT{
                 passFile.open( passPath, std::ios::binary );
                 encFile.open( encFilePath, std::ios::binary );

+               if (srcFile.fail()) throw new IOFail();
+               if (passFile.fail()) throw new IOFail();
+               if (encFile.fail()) throw new IOFail();
+
                 //
                 srcFile.seekg( 0, std::ios::end );
                 srcSize = srcFile.tellg();
diff --git a/main.cpp b/main.cpp
index 0fdd7d2..ed4cfec 100644
--- a/main.cpp
+++ b/main.cpp
@@ -126,8 +126,10 @@ int main()
                                desPath = srcPath;
                                replaceExt( desPath, "dec" );

+                          try
+                          {
                                // Start; Decryption Process
-                          EncAT::EncDecFile( srcPath.c_str(), passPath.c_str(), desPath.c_str() );
+                                          EncAT::EncDecFile( srcPath.c_str(), passPath.c_str(), desPath.c_str() );
                                // End;

                                                std::cout << con::clr; // Clear the Intro Screen
@@ -137,9 +139,17 @@ int main()

                                                << con::fg_yellow
                                                << " EncAT has created one file in the same folder of the encrypte file :" << std::endl << std::endl
-                                          << "\t.dec = Decrypted file" << std::endl << std::endl
+                                          << "\t.dec = Decrypted file" << std::endl << std::endl;

-                                          << con::fg_gray
+                          }
+                          catch(EncAT::IOFail ex)
+                          {
+                                          std::cout << std::endl << con::fg_red << "\t ---- I/O Error ---- \t" << std::endl
+                               << con::fg_yellow
+                               << " EncAt could not read the file(s) specified" << std::endl << std::endl;
+                          }
+
+               std::cout << con::fg_gray
                                                << "press any key to continue...";

                                // Pause
@@ -165,4 +175,4 @@ int main()
                                std::cin.get();

         return 0;
-}
\ No newline at end of file
+}

C:\code\encat>

طبعا الـ output يمرر عن طريق less, و قد يكون غير مفهوم تماما لغير اللينكسيين (!!) لكنه بسيط:

الاسطر اللي عليها - هي الاسطر اللتي حذفت, و الاسطر اللي عليها + هي الاسطر اللتي اضيفت.
لو تم نقل سطر من مكان الى اخر سيظهر انه حذف من مكان و اضيف الى مكان.

الان, الكود لا يعمل بشكل مضبوط, و لكني مع ذلك ساعمل commit

لكن قبل ذلك:

C:\code\encat>git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#          modified:   EncAT.h
#          modified:   main.cpp
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#          Debug/
#          EncAT.ncb
#          EncAT.sln
#          EncAT.vcproj
#          EncAT.vcproj.Toshiba.aljudy.user
#          hello.atp
#          hello.enc
#          mop.dec
#          random.atp
#          random.dec
#          random.enc
no changes added to commit (use "git add" and/or "git commit -a")

C:\code\encat>

احيانا اقوم بامر status من حين لاخر فقط لأتاكد ما هي الملفات اللتي تغيرت

و الان لعمل commit يجب اولا ان اضيف الملفات اللتي تم تغييرها

يمكن ان يتم ذلك عن طريق:

git add main.cpp
git add encat.h

و لكن يمكن ايضا اضافة الخيار -a الى الامر commit لكي يقوم بهذا العملية تلقائيا للملفات اللتي اضفناها في وقت سابق

C:\code\encat>git commit -a -m"Trying to handle case where files don't exist, doesn't work yet (compiles but fails to catch the error)"
[master 9c0f45f] Trying to handle case where files don't exist, doesn't work yet (compiles but fails to catch the error)
 2 files changed, 22 insertions(+), 4 deletions(-)

C:\code\encat>

يمكن الان ان انظر الى الـ log

C:\code\encat>git log
commit 9c0f45fe70916d328acf16d50ff02a5240fab3f5
Author: hasen j 
Date:   Thu Jun 4 23:50:07 2009 -0600

        Trying to handle case where files don't exist, doesn't work yet (compiles but fails to catch the error)

commit 618b61a4c1f0d67c8cb7949ea15fd86ef794b582
Author: hasen j 
Date:   Thu Jun 4 22:17:15 2009 -0600

        Initial commit

C:\code\encat>

بعد ذلك بفترة قليلة عرفت المشكلة: الـ exception اللذي كنت ارميه كان بصيغة ()new IOFail يعني مؤشر, و لكن حين امسكه استخدم IOFail ex بدون مؤشر :P

قمت بتغيير بسيط, و الان اذا قمت بادخال ملف غير موجود في حوار الـ Decrypt سوف يخرج لي رسالة خطأ

C:\code\encat>git diff
diff --git a/EncAT.h b/EncAT.h
index 57acbbd..5ba57c2 100644
--- a/EncAT.h
+++ b/EncAT.h
@@ -37,9 +37,9 @@ namespace EncAT{
                 passFile.open( passPath, std::ios::binary );
                 encFile.open( encFilePath, std::ios::binary );

-               if (srcFile.fail()) throw new IOFail();
-               if (passFile.fail()) throw new IOFail();
-               if (encFile.fail()) throw new IOFail();
+               if (srcFile.fail()) throw IOFail();
+               if (passFile.fail()) throw IOFail();
+               if (encFile.fail()) throw IOFail();

                 //
                 srcFile.seekg( 0, std::ios::end );

بعدها قمت بايداع الكود:

C:\code\encat>git commit -a -m"IOCheck works now for Decrypt dialoge"

الـ log الان شكله هكذا:

C:\code\encat>git log
commit 1b21f0ac570ed2098736cec709e78f217b04f898
Author: hasen j 
Date:   Thu Jun 4 23:57:53 2009 -0600

        IOCheck works now for Decrypt dialoge

commit 9c0f45fe70916d328acf16d50ff02a5240fab3f5
Author: hasen j 
Date:   Thu Jun 4 23:50:07 2009 -0600

        Trying to handle case where files don't exist, doesn't work yet (compiles but fails to catch the error)

commit 618b61a4c1f0d67c8cb7949ea15fd86ef794b582
Author: hasen j 
Date:   Thu Jun 4 22:17:15 2009 -0600

        Initial commit

C:\code\encat>

بعد ذلك قمت بتغليف كود الـ Encryption بنفس الـ try .. catch

C:\code\encat>git diff
diff --git a/main.cpp b/main.cpp
index ed4cfec..538a101 100644
--- a/main.cpp
+++ b/main.cpp
@@ -83,26 +83,37 @@ int main()
                                replaceExt( passPath, "atp" );
                                replaceExt( desPath, "enc" );

-                          // Start; Encrytion Process
-                          passUnits = fileSize( srcPath.c_str() );
-                          passUnits = (passUnits / sizeof(size_t)) + 1;
-                          EncAT::GeneratePass( passPath.c_str(), passUnits );
-
-                          EncAT::EncDecFile( srcPath.c_str(), passPath.c_str(), desPath.c_str() );
-                          // End;
+               try
+               {
+                       // Start; Encrytion Process
+                       passUnits = fileSize( srcPath.c_str() );
+                       passUnits = (passUnits / sizeof(size_t)) + 1;
+                       EncAT::GeneratePass( passPath.c_str(), passUnits );
+
+                       EncAT::EncDecFile( srcPath.c_str(), passPath.c_str(), desPath.c_str() );
+                       // End;
+
+                               std::cout << con::clr; // Clear the Intro Screen
+
+                       std::cout << std::endl << std::endl << con::fg_green
+                               << "\t\tFile Encrypted!" << std::endl << std::endl << std::endl << std::endl
+
+                               << con::fg_yellow
+                               << " EncAT has created two files in the same folder of the original file :" << std::endl << std::endl
+                               << "\t.enc = Encrypted file" << std::endl
+                               << "\t.atp = key file (don't lose it!)" << std::endl << std::endl;

-                                          std::cout << con::clr; // Clear the Intro Screen
+               }
+               catch( EncAT::IOFail ex )
+               {
+                                          std::cout << std::endl << con::fg_red << "\t ---- I/O Error ---- \t" << std::endl
+                               << con::fg_yellow
+                               << " EncAt could not read the file(s) specified" << std::endl << std::endl;
+               }

-                          std::cout << std::endl << std::endl << con::fg_green
-                                          << "\t\tFile Encrypted!" << std::endl << std::endl << std::endl << std::endl
-
-                                          << con::fg_yellow
-                                          << " EncAT has created two files in the same folder of the original file :" << std::endl << std::endl
-                                          << "\t.enc = Encrypted file" << std::endl
-                                          << "\t.atp = key file (don't lose it!)" << std::endl <<
std::endl
+               std::cout << con::fg_gray
+                               << "press any key to continue...";

-                                          << con::fg_gray
-                                          << "press any key to continue...";

                                // Pause
                                std::cin >> pause;

C:\code\encat>

و من ثم نقوم بايداع التغييرات:

C:\code\encat>git commit -a -m"Added IOChecking to the Encrypt dialoge as well"
[master 6c05b2e] Added IOChecking to the Encrypt dialoge as well
 1 files changed, 30 insertions(+), 19 deletions(-)

الان هناك مشكلة, حين اقوم بادخال ملف غير موجود في حوار التشفير, صحيح انه يظهر لي رسالة خطأ, لكنه في نفس الوقت يقوم بانشاء ملفات .enc و .atp فارغة تحمل نفس اسم الملف الغير الموجود اللذي قمت بادخاله.

الى هنا تنتهي تجربتنا التفاعلية مع git, , و قد وضعت المشروع على github من هنا

يمكنك سحب المشروع لمراجعة تاريخه او حتى اضافة تطويرات اليه .. او لمجرد التجربة:

git clone git://github.com/hasenj/encat.git

فقط نفذ ذلك الامر في اي مكان, و سيقوم git بسحب المشروع و وضعه في مجلد اسمه encat

اخيرا, بعض الروابط:

فديو لمدة ساعة يتحدث فيه لينوس تورفالدس عن نظامه git
http://www.youtube.com/watch?v=4XpnKHJAok8

موقع يقارن بين git و بقية انظمة ادارة الكود
http://whygitisbetterthanx.com

الموضوع الاصلي في منتديات الفريق العربي للبرمجة
http://www.arabteam2000-forum.com/index.php?showtopic=196339

الدرس الرسمي official git tutorial
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

الموقع الرسمي لـ git
http://git-scm.com

نسخة من git مخصصة لنظام وندوز
http://code.google.com/p/msysgit