الخميس، 19 فبراير 2009
الجمعة، 16 يناير 2009
We can do Web applications
Watching a new homegrown language grow up and generate its first dynamic Web page. Seeing the result of months of work. It feels good, الحمد لله.
If you know Lisp, you probably can understand how the code works in the (simplistic) example below. Click on the picture for better viewing.
To the team members who contributed valuable code to this project*, if you're reading this, thank you :)
[*] Haytham Alaa, Mosapha Ateya Sakr, Mostapha M. El-Maasarawy, Mohamed M. Moussa, Mohamed Abdul-Aziz El-Morsy & Kamal El-Din Mohammed.
الأربعاء، 14 يناير 2009
من اخترع المتغيرات؟ (الجزء الأول)
لم يعرف الخوازمي- العالم المسلم مؤسس علم الجبر- المتغيرات الرياضية بالصورة التي نعرفها.
في كتابه" الجبر و المقابلة" تجده يتحدث عن "الجذر" و "المال" في معادلاته. فيعرف الجذر بأنه "كل شيء مضروب في نفسه" و المال بأنه "كل ما اجتمع من الجذر المضروب في نفسه".
يقول المؤرخون أن الجذر في هذا الكتاب يرمز إلى المجهول
و المال هو مربع المجهول 
. و لكن لماذا كانت الأمور بهذه الطريقة؟ و لماذا كلمة "مال" بالذات؟
أخمّن أنا رأيا آخر, و لا أعلم إن كان رأيي صحيحا أم لا (وليس معي الكتاب الآن لأراجع الحقائق, للأسف!).
المهم..تخميني هو أن العلماء في ذلك الزمن لم يكونوا يستخدمون الأسس بل كانوا يستخدمون الجذور. فبينما نحن نقول:
كانو يفكرون هم في:
فالمجهول الأصلي بالنسبة لهم هو مربع المجهول بالنسبة لنا.
و لكن عموما مشكلتهم كانت أكبر من ذلك, لم يكن لديهم أصلاً فكرة حرف مثل x يعبّر عن قيمة عددية. فماذا يفعل الخوارزمي؟
بدلا من المتغير كان يتكلم عن الشيء الحقيقي المراد معرفة قيمته, و لما كان كتابه يهدف لمساعدة الناس في حسابات التجارة و المواريث ففي كثير من الأحيان يكون المطلوب معرفته هو مقدار من المال. وهذه هي نظريتي في سبب التسمية.
و نتيجة لهذه التسميات فأنه لو نظرت في كتاب الجبر و المقابلة تجد أنه حيث نقول نحن:
كان يقول هو:
ثم تطورت الأمور فبعد أن صارت كلمة "مال" تعني الرقم مضروبا في نفسه بشكل عام, صار مثلا "مال المال" هو نتيجة رفع العدد للأس أربعة, و بدأت اصطلاحات جديدة تظهر. بالمناسبة قام الدكتور مصطفى مشرفه وعالم مصري آخر سنة 1937 بتأليف شرح كتاب الجبر و المقابلة. شرح النص الأصلي كان في الهامش متضمنا "ترجمة" للمعادلات من الصياغة القديمة إلى المعادلات بالصورة التي نعرفها.
لك طبعا أن تتخيل الجهد العقلي الجبار الذي كان الخوارزمي و أمثاله يبذلونه في وضع القوانين. هذا الرجل اخترع علم الجبر بدون أن يكون لديه رموز رياضية و لا حتى متغيرات! رحم الله اساتذتنا علماء المسلمين.
كيف إذن ظهرت المتغيرات بالطريقة التي نعرفها؟ البقية في الجزء الثاني.
يقول المؤرخون أن الجذر في هذا الكتاب يرمز إلى المجهول
و المال هو مربع المجهول 
. و لكن لماذا كانت الأمور بهذه الطريقة؟ و لماذا كلمة "مال" بالذات؟أخمّن أنا رأيا آخر, و لا أعلم إن كان رأيي صحيحا أم لا (وليس معي الكتاب الآن لأراجع الحقائق, للأسف!).
المهم..تخميني هو أن العلماء في ذلك الزمن لم يكونوا يستخدمون الأسس بل كانوا يستخدمون الجذور. فبينما نحن نقول:
و لكن عموما مشكلتهم كانت أكبر من ذلك, لم يكن لديهم أصلاً فكرة حرف مثل x يعبّر عن قيمة عددية. فماذا يفعل الخوارزمي؟
بدلا من المتغير كان يتكلم عن الشيء الحقيقي المراد معرفة قيمته, و لما كان كتابه يهدف لمساعدة الناس في حسابات التجارة و المواريث ففي كثير من الأحيان يكون المطلوب معرفته هو مقدار من المال. وهذه هي نظريتي في سبب التسمية.
و نتيجة لهذه التسميات فأنه لو نظرت في كتاب الجبر و المقابلة تجد أنه حيث نقول نحن:
"مال وخمسة أجذار يعدل 24 درهماً".
ثم تطورت الأمور فبعد أن صارت كلمة "مال" تعني الرقم مضروبا في نفسه بشكل عام, صار مثلا "مال المال" هو نتيجة رفع العدد للأس أربعة, و بدأت اصطلاحات جديدة تظهر. بالمناسبة قام الدكتور مصطفى مشرفه وعالم مصري آخر سنة 1937 بتأليف شرح كتاب الجبر و المقابلة. شرح النص الأصلي كان في الهامش متضمنا "ترجمة" للمعادلات من الصياغة القديمة إلى المعادلات بالصورة التي نعرفها.
لك طبعا أن تتخيل الجهد العقلي الجبار الذي كان الخوارزمي و أمثاله يبذلونه في وضع القوانين. هذا الرجل اخترع علم الجبر بدون أن يكون لديه رموز رياضية و لا حتى متغيرات! رحم الله اساتذتنا علماء المسلمين.
كيف إذن ظهرت المتغيرات بالطريقة التي نعرفها؟ البقية في الجزء الثاني.
الأربعاء، 5 نوفمبر 2008
أين تضع الغضب
أحتلّوا أفغانستان و العراق و أقاموا فيهما سنوات. يقتلون و ينهبون. في كل مكان تجد الذي فقد اباه و أخاه و ابنه. أنت غاضب, فأين تضع الغضب؟
حمّل paper و اقرأها. خطط لمشاريع. طوّر نفسك باستمرار.
كم مرة حطموا فيها لبنان؟ لم أعد استطيع العد. و كم فلسطينيا قتلوا؟ و كم أسروا؟ و على كم اعتدوا؟
أين تضع الغضب؟
أكثر من قراءة القرآن. اذهب للمسجد و احضر درساً. تعلّم دينك. ألم يحن الوقت؟
تعالي. إهانة. قمع. تشريد. إذلال. و مع ذلك لديهم أطماع و يتمنون التوسّع في أراضينا و يرغبون في المزيد. أين تضع الغضب؟
لا تقاطع فحسب. بل ادّخر المال الذي لم تدفعه لهم. ستحتاج كلّ مليم و أنت تفتح شركتك.
تلك الأمم المعتدية, كانوا محظوظين فظفروا بالتفوق العلمي و الاقتصادي.
تلك الأمم المعتدية. كانوا محظوظين فماذا فعلوا بحظهم؟ قتلوا و سرقوا و دمّروا.
و لكن الأمور تتغير. و بينما هم في أزماتهم الاقتصادية التي صنعوها لأنفسهم,علينا نحن أن نعمل.
فلينتشر العلم حرفا حرفا. و لنصنع مشاريعا خطوة بخطوة. و لينتشر الإصلاح فردا فردا. و لنعد إلى الله.
قد يحتاج الأمر وقتا أوّل الأمر, لا بأس, سنصبر. فقد صبرنا كثيرًا من قبل.
و كلما هجموا علينا, زاد الغضب.
و كلما زاد الغضب, زدنا إصرارا على العمل.
في الجامعات, في الشركات, في البيت: العلم, السعي, الإصلاح. و قريبا بأذن الله نسبقهم.
تلك الأمم المعتدية. كانوا محظوظين. و قريبا..يوشك حظهم أن ينتهي.
حمّل paper و اقرأها. خطط لمشاريع. طوّر نفسك باستمرار.
كم مرة حطموا فيها لبنان؟ لم أعد استطيع العد. و كم فلسطينيا قتلوا؟ و كم أسروا؟ و على كم اعتدوا؟
أين تضع الغضب؟
أكثر من قراءة القرآن. اذهب للمسجد و احضر درساً. تعلّم دينك. ألم يحن الوقت؟
تعالي. إهانة. قمع. تشريد. إذلال. و مع ذلك لديهم أطماع و يتمنون التوسّع في أراضينا و يرغبون في المزيد. أين تضع الغضب؟
لا تقاطع فحسب. بل ادّخر المال الذي لم تدفعه لهم. ستحتاج كلّ مليم و أنت تفتح شركتك.
تلك الأمم المعتدية, كانوا محظوظين فظفروا بالتفوق العلمي و الاقتصادي.
تلك الأمم المعتدية. كانوا محظوظين فماذا فعلوا بحظهم؟ قتلوا و سرقوا و دمّروا.
و لكن الأمور تتغير. و بينما هم في أزماتهم الاقتصادية التي صنعوها لأنفسهم,علينا نحن أن نعمل.
فلينتشر العلم حرفا حرفا. و لنصنع مشاريعا خطوة بخطوة. و لينتشر الإصلاح فردا فردا. و لنعد إلى الله.
قد يحتاج الأمر وقتا أوّل الأمر, لا بأس, سنصبر. فقد صبرنا كثيرًا من قبل.
و كلما هجموا علينا, زاد الغضب.
و كلما زاد الغضب, زدنا إصرارا على العمل.
في الجامعات, في الشركات, في البيت: العلم, السعي, الإصلاح. و قريبا بأذن الله نسبقهم.
تلك الأمم المعتدية. كانوا محظوظين. و قريبا..يوشك حظهم أن ينتهي.
الجمعة، 26 سبتمبر 2008
سي شارب - الجزء الأول - طريقة جديدة للتفكير
"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis
أيّ لغة برمجة ليست مجرّد syntax, بل هي تقدّم وسيلة جديدة للتفكير في البرنامج الذي تكتبه. #C هي لغة في سلسلة من اللغات المبنيّة على مباديء البرمجة المعتمدة على الأشياء Object Oriented Programming. و بدون تمكّن من هذه المباديء فلن يستفيد المبرمج حقاً من الـ#C. لذلك يجب أن نتحدث عن الOOP أولاً.
الأشياء و الفصائل
كثير من البرامج يسهل وصفها لو قسّمناها إلى أشياء.
مثلا في Word الأشياء هي شريط الأدوات و القوائم, الكلام الذي تكتبه و الصفحات و الفقرات, اللغات التي يعمل معها المدقق الأملائي, و سائر مكونات البرنامج. و في لعبة مثل ألعاب الحروب فالأشياء التي تكوّن البرنامج هي الوحدات و المباني و الخريطة و عوامل البيئة مثل الحيوانات أو الأنهار.
من كثرة انتشار البرامج التي يتيسّر وصفها لو قسّمناها لأشياء ظهرت طريقة للبرمجة مبنية على فكرة "الشيء" أو الobject. فما معنى "شيء" هنا؟
الشيء هو كائن له "حالة" و له "سلوك". An object has a state and behavior. أما الحالة فهي الوضع الذي عليه الشيء, مثل لون الكلمة في الWord أو مكان الجندي في لعبة الحرب أو عدد العناصر في الArray.و أمّا السلوك فهو التأثيرات التي يحدثها الشيء. مثلا السلوك في Word هو الطريقة التي يُرسم بها الجدول على الشاشة أو الطريقة التي يعمل بها المدقق الأملائي. و في اللعبة فسلوك الوحدة هو الطريقة التي تهاجم بها أو ردّ فعلها عندما تقترب منها وحدة معادية.
يمكن لو أخترنا أن نعبر عن حالة الشيء عن طريق مجموعة من الصفات Attributes و أن نعبر عن سلوكه بواسطة حصر الطُرُق methods التي يتصرّف بها. فلو كنت أصمم برنامج لشئون العاملين مثلا فقد أقول أن البرنامج فيه نوع من الأشياء هم الموظفون, و أن حالتهم تحددها صفات مثل تاريخ التعيين, السن, هل يقومون بالعمل حاليا أم لا, و هكذا. بينما يمكن أن أصف سلوكهم بأنهم يمكنهم أن يعملوا, أن يأخذوا عطلة, أن يترقّوا, أن يغيروا الفرع أو أن يستقيلوا.
نلاحظ أنّ كل "شيء" له عموماً حالته المستقلّة. فكل جندي في اللعبة له صحته و مكانه بغضّ النظر عن أي وحدة أخرى. و لكن تأتي أحيان كثيرة يكون السلوك فيها مشترك بين فئة كبيرة من الوحدات. فجنود المشاة مثلا في اللعبة يهجمون كلهم بنفس الطريقة و يردون على اقتراب الأعداء بنفس الطريقة. طبعاً قد يختلف السلوك باختلاف الحالة (فمثلا الجندي ذو الصحة القليلة قد لا يهاجم) و لكن الخطة العامّة أو "البرنامج" الذي يحرك جندي المشاة قد تكون هي هي لكلّ الجنود.
من أجل هذا فإن بعض لغات البرمجة التي تتعامل مع الobjects (و لكن ليس كلها) قد اختارت أن تقدم مبدءاً جديداً لوصف مجموعة من الأشياء لها سلوك موحّد, و ذلك المبدأ هو الفصيلة class.
الفصيلة هي طريقة لوصف فئة من الأشياء يجمع بينها مجموعة مشتركة من الصفات و سلوك مشترك.
مجموعة مشتركة من الصفات أي أنّ السيّارة في لعبة سباق مثلا لها لون و سرعة و مكان. نعم كل سيّارة منهم لها لون و سرعة و مكان مختلفين لكن يجمع بينهم أن الكل يجب أن تكون هذه الصفات فيه. و سلوك مشترك أي أن كل ال checkboxes في الWindows مثلا تتصرف بنفس الطريقة بأن ترسم علامة حين تختارها و تلغي هذه العلامة حين تلغي اختيارك.
لتوضيح العلاقة بين الشيء و فصيلته انظر هذا المثال:
تخيّل أنه هناك قطة اسمها نميرة. يمكننا أن نقول
اذن كلمة instance معناها العلاقة بين الشيء و فصيلته.
أنواع الـattributes و الـmethods
مع أن كل شيء من الـ"أشياء" له حالة مختلفة إلا أنه يكون أحيانا هناك حالة مشتركة بين كل الأشياء من فصيلة معيّنة. مثلا لو كان في السيارة صفة هي "سعر قطعة الغيار" و كان هذا السعر موحدا فإنه لا معني أن يكون هناك نسخة مستقلة من هذا السعر لكل سيّارة على حدىً. و أيضا لو تغيّر هذا السعر فأنه من المتوقع أن ينعكس هذا التغيير على السيّارات كلها. في هذه الحالة فإن الصفة تظهر و كأنها خاصة بالclass كله و ليس بكل instance على انفراد. حين تكون الصفة خاصة بكل instance منفردة تكون تلك الصفة instance attribute و أمّا حين تكون خاصة بالـclass و مشتركة بين كل الـinstances فهي class attribute.
نفس الموقف بالنسبة للـmethods: فلو كانت الـmethod تصف سلوكا خاصا بالكائن (مثل طريقة هجوم الجندي) فهي instance method و لكن لو كانت تصف سلوكاً لا يرتبط بكائن معين فهي class method. مثال على الclass method أن أكتب code تقوم بحصر عدد الجنود الذين ماتوا في اللعبة. هذا شيء لا يرتبط بجندي معيّن و لكن يشمل فئة الجنود عموماً لهذا هو class method.
الهويّة
لكي نميّز بين "شيء" و آخر فاننا نحتاج أن يكون للأشياء هويّة identity وهي صفة قيمتها متفردة لكل شيء منفصل. في ال#C نستخدم الreference و هو قيمة تعبر (عادةً) عن مكان الـobject في الذاكرة فهي شبيهة بالpointers نوعاً ما. هذه القيمة تحدد أيضا الidentity بمعني أنه لو تساوى اثنان من الـreferences فمعنى هذا أنهما يدلّان على نفس الـobject و لو اختلفا فهما بالتأكيد يدلّان على objects مختلفة.
إعرف هذه المباديء جيداً. سنحتاجها المرة القادمة إن شاء الله حين نبدأ بكتابة code حقيقيّة!
الأشياء و الفصائل
كثير من البرامج يسهل وصفها لو قسّمناها إلى أشياء.
مثلا في Word الأشياء هي شريط الأدوات و القوائم, الكلام الذي تكتبه و الصفحات و الفقرات, اللغات التي يعمل معها المدقق الأملائي, و سائر مكونات البرنامج. و في لعبة مثل ألعاب الحروب فالأشياء التي تكوّن البرنامج هي الوحدات و المباني و الخريطة و عوامل البيئة مثل الحيوانات أو الأنهار.
من كثرة انتشار البرامج التي يتيسّر وصفها لو قسّمناها لأشياء ظهرت طريقة للبرمجة مبنية على فكرة "الشيء" أو الobject. فما معنى "شيء" هنا؟
الشيء هو كائن له "حالة" و له "سلوك". An object has a state and behavior. أما الحالة فهي الوضع الذي عليه الشيء, مثل لون الكلمة في الWord أو مكان الجندي في لعبة الحرب أو عدد العناصر في الArray.و أمّا السلوك فهو التأثيرات التي يحدثها الشيء. مثلا السلوك في Word هو الطريقة التي يُرسم بها الجدول على الشاشة أو الطريقة التي يعمل بها المدقق الأملائي. و في اللعبة فسلوك الوحدة هو الطريقة التي تهاجم بها أو ردّ فعلها عندما تقترب منها وحدة معادية.
يمكن لو أخترنا أن نعبر عن حالة الشيء عن طريق مجموعة من الصفات Attributes و أن نعبر عن سلوكه بواسطة حصر الطُرُق methods التي يتصرّف بها. فلو كنت أصمم برنامج لشئون العاملين مثلا فقد أقول أن البرنامج فيه نوع من الأشياء هم الموظفون, و أن حالتهم تحددها صفات مثل تاريخ التعيين, السن, هل يقومون بالعمل حاليا أم لا, و هكذا. بينما يمكن أن أصف سلوكهم بأنهم يمكنهم أن يعملوا, أن يأخذوا عطلة, أن يترقّوا, أن يغيروا الفرع أو أن يستقيلوا.
نلاحظ أنّ كل "شيء" له عموماً حالته المستقلّة. فكل جندي في اللعبة له صحته و مكانه بغضّ النظر عن أي وحدة أخرى. و لكن تأتي أحيان كثيرة يكون السلوك فيها مشترك بين فئة كبيرة من الوحدات. فجنود المشاة مثلا في اللعبة يهجمون كلهم بنفس الطريقة و يردون على اقتراب الأعداء بنفس الطريقة. طبعاً قد يختلف السلوك باختلاف الحالة (فمثلا الجندي ذو الصحة القليلة قد لا يهاجم) و لكن الخطة العامّة أو "البرنامج" الذي يحرك جندي المشاة قد تكون هي هي لكلّ الجنود.
من أجل هذا فإن بعض لغات البرمجة التي تتعامل مع الobjects (و لكن ليس كلها) قد اختارت أن تقدم مبدءاً جديداً لوصف مجموعة من الأشياء لها سلوك موحّد, و ذلك المبدأ هو الفصيلة class.
الفصيلة هي طريقة لوصف فئة من الأشياء يجمع بينها مجموعة مشتركة من الصفات و سلوك مشترك.
مجموعة مشتركة من الصفات أي أنّ السيّارة في لعبة سباق مثلا لها لون و سرعة و مكان. نعم كل سيّارة منهم لها لون و سرعة و مكان مختلفين لكن يجمع بينهم أن الكل يجب أن تكون هذه الصفات فيه. و سلوك مشترك أي أن كل ال checkboxes في الWindows مثلا تتصرف بنفس الطريقة بأن ترسم علامة حين تختارها و تلغي هذه العلامة حين تلغي اختيارك.
لتوضيح العلاقة بين الشيء و فصيلته انظر هذا المثال:
تخيّل أنه هناك قطة اسمها نميرة. يمكننا أن نقول
Cat is the class of Numaira
القطط هي فصيلة نميرة
و لكن كيف يمكن أن نقول نفس الجملة مع تبديل المبتدأ و الخبر؟القطط هي فصيلة نميرة
Numaira is an instance of Cat
نميرة هي تجسيد لفصيلة القطط
نميرة هي تجسيد لفصيلة القطط
اذن كلمة instance معناها العلاقة بين الشيء و فصيلته.
أنواع الـattributes و الـmethods
مع أن كل شيء من الـ"أشياء" له حالة مختلفة إلا أنه يكون أحيانا هناك حالة مشتركة بين كل الأشياء من فصيلة معيّنة. مثلا لو كان في السيارة صفة هي "سعر قطعة الغيار" و كان هذا السعر موحدا فإنه لا معني أن يكون هناك نسخة مستقلة من هذا السعر لكل سيّارة على حدىً. و أيضا لو تغيّر هذا السعر فأنه من المتوقع أن ينعكس هذا التغيير على السيّارات كلها. في هذه الحالة فإن الصفة تظهر و كأنها خاصة بالclass كله و ليس بكل instance على انفراد. حين تكون الصفة خاصة بكل instance منفردة تكون تلك الصفة instance attribute و أمّا حين تكون خاصة بالـclass و مشتركة بين كل الـinstances فهي class attribute.
نفس الموقف بالنسبة للـmethods: فلو كانت الـmethod تصف سلوكا خاصا بالكائن (مثل طريقة هجوم الجندي) فهي instance method و لكن لو كانت تصف سلوكاً لا يرتبط بكائن معين فهي class method. مثال على الclass method أن أكتب code تقوم بحصر عدد الجنود الذين ماتوا في اللعبة. هذا شيء لا يرتبط بجندي معيّن و لكن يشمل فئة الجنود عموماً لهذا هو class method.
الهويّة
لكي نميّز بين "شيء" و آخر فاننا نحتاج أن يكون للأشياء هويّة identity وهي صفة قيمتها متفردة لكل شيء منفصل. في ال#C نستخدم الreference و هو قيمة تعبر (عادةً) عن مكان الـobject في الذاكرة فهي شبيهة بالpointers نوعاً ما. هذه القيمة تحدد أيضا الidentity بمعني أنه لو تساوى اثنان من الـreferences فمعنى هذا أنهما يدلّان على نفس الـobject و لو اختلفا فهما بالتأكيد يدلّان على objects مختلفة.
إعرف هذه المباديء جيداً. سنحتاجها المرة القادمة إن شاء الله حين نبدأ بكتابة code حقيقيّة!
Summary
- Applications can be composed of objects.
- An object has state (attributes) and behavior (methods).
- Objects of common attributes and behavior can be grouped into classes.
- If C is the class of and object O, then O is an instance of C.
- Instance attributes have a different value for each object, while a class attribute has only one value for the whole class, and does not belong to any particular instance.
- Similarly, an instance method works on a particular object each time it's invoked, but a class method does not work on any particular object but is related to the class as a whole.
- An object reference can be used to determine its identity and uniquely distinguish it from other objects.
الثلاثاء، 26 أغسطس 2008
سدّ الفجوة التكنولوجية
سؤال
لماذا لم نصنع نظام تشغيل خاص بنا؟ أو لغة برمجة؟ أو برنامج مثل Office؟
فيكون الرد:
نعم, نعم. هذا هو التفكير السائد الآن. و أيضاً لمَ نصنع سيارة محليّة بينما يمكننا تجميع التويوتا و الهيونداي؟ و لمَ ننشيء إقتصادا قويا بأنفسنا و يمكننا بدلا من هذا جذب الأستثمارات الأجنبية؟ أليس كذلك؟
كلّا! حان وقت تغيير هذا الرأي و السعي لإحداث نهضة علمية حقيقية. دع أفكارك تكبر عن الأنشغالات التقليدية. نحن لا نتحدث عن كشف الأرباح و الخسائر لسنة مالية بل عن المائة سنة القادمة. هل تظن أنه بعد مائة سنة سيستخدم الناس نظام تشغيل يشبه الWindows أو ستكون لغة برمجتهم تشبه الC# أو يبحثون عن المعلومات بكتابة بضع كلمات في Google؟ و هل سنصنع نحن هذه الأدوات المستقبلية أم سننتظر مرةً أخرى حتى تُصنع لنا؟
احتياج
و ما علاقة المائة سنة القادمة بإنتاج نظام تشغيل جديد أو Office Application؟ الجواب أنّك لن تستطيع سد الفجوة التكنولوجية إلا لو قمت بإعادة إنتاج قمة التكنولوجيا الحالية بنفسك. طالما أنّك تستخدم المكونات الجاهزة أو تستعين بالخبراء الأجانب فلن تصل لشيء بل ستظل تنتظر الخطوة القادمة التي يخطوها غيرك ثم تطلب ما صنعوا. تستوي هذه الجملة أن تكون عن الصناعة أو البرامج.
و لم لا نأخذ نظاما مفتوح المصدر مثل Linux أو الJava Virtual Machine و ندرس الSource code و نطوّر عليها؟ هذه ستكون خطوة مهمة و رائعة و لكنها لن تكفي. نعم سنكون مشاركين في صنع التكنولوجيا و ليس مجرد مستهلكين و لكننا يجب ألا نتأخر عن هدفنا الحقيقي: أن نصبح صانعين و مبدعين. المشكلة في برنامج مثل Linux أن معظم المشاكل الصعبة قد حلّت و معظم القرارات الشيقة قد اتخذت فتعلم طريقة كتابة الLinux kernel سيكون اكتساب معرفة أكثر منها اكتساب خبرة.
نعم ستكون معرفة عملية على منتج حقيقي و لكنها مازالت معرفة أسرار برنامج جاهز و ليست كتابة برنامج من الصفر بنفسك بينما هذا هو ما نحتاجه الآن: لن تتعلم كيف تتفوق على التكنولوجيا الحالية إلا لو تعلمت كيف تبدأ من لا شيء, لأن التكنولوجيا الحالية هي لا شيء من التكنولوجيا القادمة.
و كيف تكون إعادة اختراع للعجلة و أنت لم تخترعها أصلا بعد؟
خطة
علينا في رأيي أن نعيد إنتاج الأدوات الأساسية كي يكون لنا فئة من الناس قد بدأت من البداية و تقدر أن تواصل للمستقبل. بشكل عام التطبيقات الآن طبقات مبني بعضها على بعض:
هدفنا أن نقوم تدريجيا بغزو هذه الطبقات فنقدر إن شاء الله خلال عشر سنوات مثلا أن يكون لدينا القدرة على عمل "برج تكنولوجي" مستقل يشمل كلّ شيء من البرامج حتى الHardware. فكيف نفعل هذا؟
كن مشاركا تكنولوجيا: نحن الآن في عصر الوفرة التكنولوجية و الحمد لله. أنظر إلى أيّ مشروع يعجبك: Linux أو Python أو Java أو Abiword أو أي برنامج تحب و حمّل الsource code و تعلمها و شارك فيها. يمكنك أن تبدأ بتطوير صغير: صلّح bug أو زود menu item جديد. شيء يفتح شهيتك. مع الوقت ستجد نفسك تتمنى إمكانية معينة في البرنامج و لديك القدرة على إضافتها فافعل.
إبدأ بمنتج صغير و مختلف: ما لم تكن بمؤسسة كبيرة فلا أنصحك أن تحاول عمل منتج تكنولوجي ضخم لأسباب قومية بحتة. ستجد الحماس يفتر بعد بضعة أسابيع من العمل لتكتشف أنك تحاول أن تعمل Windows آخر وحدك بلا سبب واضح. إبدأ صغيرا و في نفس الوقت اصنع شيئا أفضل من الموجود. حين بدأت الشركات الجديدة في إعادة صنع Office لم تحاول عمل نسخة طبق الأصل من برنامج Microsoft بل صنعت برامج مثل Google Docs: بها عُشر إمكانات Excel و Word و مع ذلك تميّز نفسها بأنها تعمل من على الWeb و تدار مركزيا و لا تحتاج Installation. و هكذا فعلوا شيئا حكيما: لم يقوموا بالمهمة المستحيلة و هي الإنتاج الفوري لبديل لMS Office و في نفس الوقت ميزوا أنفسهم عنه بأمكانات قوية. و مع الوقت ستجدهم يضيفون الأمكانات شيئا فشيئا حتّى يلحقوا بالExcel و الWord و يتفوقوا عليهما. يساعدهم في ذلك أنهم يطورون أدواتهم و يخرجون لنا بcompilers تحول البرامج العادية إلى Ajax و يطورون نظم التشغيل لتحتمل عبء تشغيل البرامج من على الWeb لكلّ المستخدمين. أي أنهم يقومون بغزو طبقات النظام كلها إما بالأنتاج أو بتطوير الموجود (أنظر كيف أفادهم إعادة أختراع العجلة).
أنت أيضا يمكنك أن تفعل مثل ذلك: ربما يمكن أن تبني لغتك على ال JVM أو ال.net أو الParrot في البداية و مع الوقت اجعلها كيانا مستقلا بذاته و حتى يأتي وقت استقلالها ميزها بقدرات أكبر عن اللغات الشائعة أو بملائمتها لنوع معين من التطبيقات مثل تطبيقات الweb أو الimaging.أو يمكنك عمل برنامج مثل الOffice و لكنه يعمل على الmobile. في البداية سيكون برنامج الكتابة أقرب للNotepad منه للWord و برنامج الحسابات يشبه الcalculator و لكنه تدريجيا سيزداد فائدة مع تطور التكنولوجيا. أو ربما تميز منتجك عن الموجود بطريقة استخدامه المبدعة كما فعل الiPhone : كانت إمكاناته أقل بكثير من الWindows Mobile ولكنه قدم طريقة جديدة مذهله للتعامل مع الجهاز ثم بدأ يسدّ الثغرات في الأمكانيات.
كن صبوراً: لو توقعت نجاحا مبهرا سريعا فسيفتر حماسك و تجد نفسك تعود للمكونات الجاهزة كما عاد آخرون للخبرة الأجنبية. تذكر أننا نتحدث عن نهضة علمية للمدى الطويل. المشاريع الكبيرة دوما تأخذ سنوات. Google أخذت سنوات طويلة حتى نجحت. لغة الRuby موجودة منذ 1995 و حققت شهرتها الفائقة منذ حوالى 2004. أنظر إلى منتج مثل Linux بدأ عام 1991 و مازال يتطور إلى الآن: كان على صانعه أن يحقق توازنا بين عمل برنامج يسد احتاجاته الحالية و بين الصبر و التخطيط للمدى البعيد. لو حاول أن يصنع نظاما عظيما منذ الخطوة الأولى لفشل, و لو أخذ يخطط للمدى الطويل بدون أن يصنع منتجا حقيقيا يمكن استخدامه فورا لانصرف الناس و تركوه يطارد حلما ليس له وجود مادي. المشاريع لا تنجح بانفجار كانفجار البركان و لكن بسلسلة مستمرة من الخطوات الصغيرة. حسّن و طوّر و صلح الأخطاء و لا تتوقف تأتي لحظة على المدى الطويل يكون نجاحك فيها واضحا كبيرا.
لماذا لم نصنع نظام تشغيل خاص بنا؟ أو لغة برمجة؟ أو برنامج مثل Office؟
فيكون الرد:
و لمَ نعيد اختراع العجلة؟ أليست أمامك لغات مثل ال#C و ال++C و برامج مثل Microsoft Office؟ كل ما ستفعله لو أعدت إنتاج مثل تلك البرامج أن تضيع الوقت و الجهد لتنتهي في نفس النقطة التي بدأت بها, بل أقل لأن برامجك لن تكون على مستوى البرامج الموجودة.
نعم, نعم. هذا هو التفكير السائد الآن. و أيضاً لمَ نصنع سيارة محليّة بينما يمكننا تجميع التويوتا و الهيونداي؟ و لمَ ننشيء إقتصادا قويا بأنفسنا و يمكننا بدلا من هذا جذب الأستثمارات الأجنبية؟ أليس كذلك؟
كلّا! حان وقت تغيير هذا الرأي و السعي لإحداث نهضة علمية حقيقية. دع أفكارك تكبر عن الأنشغالات التقليدية. نحن لا نتحدث عن كشف الأرباح و الخسائر لسنة مالية بل عن المائة سنة القادمة. هل تظن أنه بعد مائة سنة سيستخدم الناس نظام تشغيل يشبه الWindows أو ستكون لغة برمجتهم تشبه الC# أو يبحثون عن المعلومات بكتابة بضع كلمات في Google؟ و هل سنصنع نحن هذه الأدوات المستقبلية أم سننتظر مرةً أخرى حتى تُصنع لنا؟
احتياج
و ما علاقة المائة سنة القادمة بإنتاج نظام تشغيل جديد أو Office Application؟ الجواب أنّك لن تستطيع سد الفجوة التكنولوجية إلا لو قمت بإعادة إنتاج قمة التكنولوجيا الحالية بنفسك. طالما أنّك تستخدم المكونات الجاهزة أو تستعين بالخبراء الأجانب فلن تصل لشيء بل ستظل تنتظر الخطوة القادمة التي يخطوها غيرك ثم تطلب ما صنعوا. تستوي هذه الجملة أن تكون عن الصناعة أو البرامج.
و لم لا نأخذ نظاما مفتوح المصدر مثل Linux أو الJava Virtual Machine و ندرس الSource code و نطوّر عليها؟ هذه ستكون خطوة مهمة و رائعة و لكنها لن تكفي. نعم سنكون مشاركين في صنع التكنولوجيا و ليس مجرد مستهلكين و لكننا يجب ألا نتأخر عن هدفنا الحقيقي: أن نصبح صانعين و مبدعين. المشكلة في برنامج مثل Linux أن معظم المشاكل الصعبة قد حلّت و معظم القرارات الشيقة قد اتخذت فتعلم طريقة كتابة الLinux kernel سيكون اكتساب معرفة أكثر منها اكتساب خبرة.
نعم ستكون معرفة عملية على منتج حقيقي و لكنها مازالت معرفة أسرار برنامج جاهز و ليست كتابة برنامج من الصفر بنفسك بينما هذا هو ما نحتاجه الآن: لن تتعلم كيف تتفوق على التكنولوجيا الحالية إلا لو تعلمت كيف تبدأ من لا شيء, لأن التكنولوجيا الحالية هي لا شيء من التكنولوجيا القادمة.
و كيف تكون إعادة اختراع للعجلة و أنت لم تخترعها أصلا بعد؟
خطة
علينا في رأيي أن نعيد إنتاج الأدوات الأساسية كي يكون لنا فئة من الناس قد بدأت من البداية و تقدر أن تواصل للمستقبل. بشكل عام التطبيقات الآن طبقات مبني بعضها على بعض:
| Applications |
| Compilers, Interpreters, Virtual Machines |
| Operating Systems |
| Hardware - CPU's, Boards, Communications...etc |
هدفنا أن نقوم تدريجيا بغزو هذه الطبقات فنقدر إن شاء الله خلال عشر سنوات مثلا أن يكون لدينا القدرة على عمل "برج تكنولوجي" مستقل يشمل كلّ شيء من البرامج حتى الHardware. فكيف نفعل هذا؟
كن مشاركا تكنولوجيا: نحن الآن في عصر الوفرة التكنولوجية و الحمد لله. أنظر إلى أيّ مشروع يعجبك: Linux أو Python أو Java أو Abiword أو أي برنامج تحب و حمّل الsource code و تعلمها و شارك فيها. يمكنك أن تبدأ بتطوير صغير: صلّح bug أو زود menu item جديد. شيء يفتح شهيتك. مع الوقت ستجد نفسك تتمنى إمكانية معينة في البرنامج و لديك القدرة على إضافتها فافعل.
إبدأ بمنتج صغير و مختلف: ما لم تكن بمؤسسة كبيرة فلا أنصحك أن تحاول عمل منتج تكنولوجي ضخم لأسباب قومية بحتة. ستجد الحماس يفتر بعد بضعة أسابيع من العمل لتكتشف أنك تحاول أن تعمل Windows آخر وحدك بلا سبب واضح. إبدأ صغيرا و في نفس الوقت اصنع شيئا أفضل من الموجود. حين بدأت الشركات الجديدة في إعادة صنع Office لم تحاول عمل نسخة طبق الأصل من برنامج Microsoft بل صنعت برامج مثل Google Docs: بها عُشر إمكانات Excel و Word و مع ذلك تميّز نفسها بأنها تعمل من على الWeb و تدار مركزيا و لا تحتاج Installation. و هكذا فعلوا شيئا حكيما: لم يقوموا بالمهمة المستحيلة و هي الإنتاج الفوري لبديل لMS Office و في نفس الوقت ميزوا أنفسهم عنه بأمكانات قوية. و مع الوقت ستجدهم يضيفون الأمكانات شيئا فشيئا حتّى يلحقوا بالExcel و الWord و يتفوقوا عليهما. يساعدهم في ذلك أنهم يطورون أدواتهم و يخرجون لنا بcompilers تحول البرامج العادية إلى Ajax و يطورون نظم التشغيل لتحتمل عبء تشغيل البرامج من على الWeb لكلّ المستخدمين. أي أنهم يقومون بغزو طبقات النظام كلها إما بالأنتاج أو بتطوير الموجود (أنظر كيف أفادهم إعادة أختراع العجلة).
أنت أيضا يمكنك أن تفعل مثل ذلك: ربما يمكن أن تبني لغتك على ال JVM أو ال.net أو الParrot في البداية و مع الوقت اجعلها كيانا مستقلا بذاته و حتى يأتي وقت استقلالها ميزها بقدرات أكبر عن اللغات الشائعة أو بملائمتها لنوع معين من التطبيقات مثل تطبيقات الweb أو الimaging.أو يمكنك عمل برنامج مثل الOffice و لكنه يعمل على الmobile. في البداية سيكون برنامج الكتابة أقرب للNotepad منه للWord و برنامج الحسابات يشبه الcalculator و لكنه تدريجيا سيزداد فائدة مع تطور التكنولوجيا. أو ربما تميز منتجك عن الموجود بطريقة استخدامه المبدعة كما فعل الiPhone : كانت إمكاناته أقل بكثير من الWindows Mobile ولكنه قدم طريقة جديدة مذهله للتعامل مع الجهاز ثم بدأ يسدّ الثغرات في الأمكانيات.
كن صبوراً: لو توقعت نجاحا مبهرا سريعا فسيفتر حماسك و تجد نفسك تعود للمكونات الجاهزة كما عاد آخرون للخبرة الأجنبية. تذكر أننا نتحدث عن نهضة علمية للمدى الطويل. المشاريع الكبيرة دوما تأخذ سنوات. Google أخذت سنوات طويلة حتى نجحت. لغة الRuby موجودة منذ 1995 و حققت شهرتها الفائقة منذ حوالى 2004. أنظر إلى منتج مثل Linux بدأ عام 1991 و مازال يتطور إلى الآن: كان على صانعه أن يحقق توازنا بين عمل برنامج يسد احتاجاته الحالية و بين الصبر و التخطيط للمدى البعيد. لو حاول أن يصنع نظاما عظيما منذ الخطوة الأولى لفشل, و لو أخذ يخطط للمدى الطويل بدون أن يصنع منتجا حقيقيا يمكن استخدامه فورا لانصرف الناس و تركوه يطارد حلما ليس له وجود مادي. المشاريع لا تنجح بانفجار كانفجار البركان و لكن بسلسلة مستمرة من الخطوات الصغيرة. حسّن و طوّر و صلح الأخطاء و لا تتوقف تأتي لحظة على المدى الطويل يكون نجاحك فيها واضحا كبيرا.
الاثنين، 23 يونيو 2008
حول مشاريع التخرج - الجزء الثاني - أفكار المشاريع
( الجزء الأول هنا )
نصائح للعثور على أفكار لمشاريع التخرج:
- وسّع مداركك.
- لا تخشَ إعادة استكشاف الأفكار السابقة.
- فكر في احتياجاتك أنت.
-اعرض الأفكار على الآخرين.
- قَيِّم مشروعك عملياً.
وسّع مداركك
كلما تنوعت معرفتك و زاد إلمامك بأمور البرمجة, كلما وجدت وفرة في أفكار المشاريع. من تتخيل سيأتي بأفكار أفضل: الذي لا يعرف سوى ال #C و ال SQL أم الذي قرأ عن ال Ajax أو ال Virtual Machines أو ال Distributed Computing؟
اذهب إلى مواقع أبحاث الشركات التي تهتم بالعلم مثل Microsoft أو Sun أو Google أو IBM أو Intel. لا تذهب فقط بنيّة البحث عن فكرة مشروع فالتعجُّل قد يحرمك من رؤية الأفكار الجميلة حقا. بل اذهب بنيّة الأطّلاع و كأنك تأخذ جولة سياحية في علوم الكمبيوتر. أنظر إلى المشاريع. زُر بعض الصفحات الشخصية للباحثين هناك. أنظر الى ما نشروا. تابع ال blogs. أبحث ببعض الكلمات المهمة في مواقع نشر ال Papers مثل Citeseer أو Google Scholar. أو اذهب لمراكز البحث في الجامعات الشهيرة
ربما تجد فكرة مفتوحة تأخذها جاهزةً و ربما لا, ليس هذا المهم و لكن المهم أن يتسع مجال تفكيرك و تجد تطبيقات كثيرة لل Software و ال Hardware كانت غائبة عنك, و هكذا يمكنك الهروب من المشاريع النمطية التي يكاد يقوم بها الجميع.
حتى لو شعرت أنه لم يبق متسع من الوقت للمعرفة فأقرأ. ربما ينفعك ولو يوم واحد من القراءة لتعرف مجالاً جديدا غنياً بالأفكار.
لا تخشَ إعادة استكشاف الأفكار السابقة
كثيرا ما تكون النتائج أهم من الفكرة نفسها. كان العالَم مليء بمحركات البحث من قبل Google ولم يمنعهم هذا من الأبتكار في نفس المجال. لم يكن ال iPhone أول هاتف محمول ذكي و لم تكن ال #C صادرة قبل ال Java، ومع ذلك كل من هؤلاء قدم تطويرات كبيرة على ما سبق وصار إنجازا في حد ذاته.
لا تخف من الأفكار القديمة و انظر الى مشروع سابق أو برنامج تستخدمه. و سل نفسك كيف أطوره. كيف أتحاشى أخطاء من صممه. كيف أعيد اختراعه. معظم التكنولوجيا التي نستخدمها من GUI أو لغات برمجة أو Office Applications مبنية على نفس المباديء الموجودة منذ السبعينات أو الثمانينات، وبها مجال واسع للتطور. ربما يفيدك أن تلقي نظرة على الأبحاث المنشورة في تلك المجالات لتعلم الأفكار الجديدة التي بُحثت و لم تطبق بعد أو لم تطبق بصورة كلية.
فكر في احتياجاتك أنت
ما احتياجاتك كمبرمج؟ كمستخدم للإنترنت؟ كمستخدم عربي؟ كطالب؟ في حياتك؟
أمثلة للاحتياجات:
اعرض الأفكار على الآخرين
اجتمع مع افراد الفريق في جلسات brainstorming وناقشوا كل الأفكار المتاحة (حتى لو بدت في حينها سخيفة أو غير عملية). اعرضوا الأفكار على أصدقائكم و على المعيدين. اطلبوا الأقتراحات لتحسينها. لو انتقد أحدٌ الأفكار اسألوا كيف يمكنه أن يتلافى العيوب التي ذكرها. جرب أن تخلط أفكارا ببعضها (مثلا برنامج Resolver خَلَط لغة ال IronPython بفكرة الجداول الألكترونية مثل ال Excel).
قَيِّم مشروعك عملياً
لا تكتف بفكرة مجرّدة فتقول "سأقوم بمشروع عن كذا" فحسب. ارسم رسما تخطيطياً للمشروع على ورق. تخيل أنه تم تنفيذ مشروعك و مثل انك تستخدمه بعد تنفيذه. ارسم screenshots. افعل مثلما فعل Jeff Hawkins مصمم جهاز ال Palm حين كان يمسك بلوح خشبي صغير كأنه كمبيوتر محمول ليجرب الطرق المخلفة للتعامل مع الأجهز-- كان حينا يكتب عليه بقلم و حينا يتحدث إليه صوتيا و هكذ، ليعلم أي من تلك الوسائل تبدو تلقائية و مريحة للمستخدم).
إذا كان مشروعك Compiler أو أداة برمجة فجرّب أن تكتب على الورق نماذج للcode باللغة الجديدة التي تصممها. إذا كان ال GUI جزءا أساسيا في المشروع فلعله يفيدك أن تكتب Prototype يرسم GUI كروكية ليراها باقي أفراد الفريق أو المشرفين.
لا تكتف بتقييم فكرة المشروع "سَمَاعيّا" بأن تتكلم عنه فقط! بل قيِّمها عملياً بأن تصنع رسومات وبرامج تجريبية تكون آثارا حقيقية لتفكيرك.
نصائح للعثور على أفكار لمشاريع التخرج:
- وسّع مداركك.
- لا تخشَ إعادة استكشاف الأفكار السابقة.
- فكر في احتياجاتك أنت.
-اعرض الأفكار على الآخرين.
- قَيِّم مشروعك عملياً.
وسّع مداركك
كلما تنوعت معرفتك و زاد إلمامك بأمور البرمجة, كلما وجدت وفرة في أفكار المشاريع. من تتخيل سيأتي بأفكار أفضل: الذي لا يعرف سوى ال #C و ال SQL أم الذي قرأ عن ال Ajax أو ال Virtual Machines أو ال Distributed Computing؟
اذهب إلى مواقع أبحاث الشركات التي تهتم بالعلم مثل Microsoft أو Sun أو Google أو IBM أو Intel. لا تذهب فقط بنيّة البحث عن فكرة مشروع فالتعجُّل قد يحرمك من رؤية الأفكار الجميلة حقا. بل اذهب بنيّة الأطّلاع و كأنك تأخذ جولة سياحية في علوم الكمبيوتر. أنظر إلى المشاريع. زُر بعض الصفحات الشخصية للباحثين هناك. أنظر الى ما نشروا. تابع ال blogs. أبحث ببعض الكلمات المهمة في مواقع نشر ال Papers مثل Citeseer أو Google Scholar. أو اذهب لمراكز البحث في الجامعات الشهيرة
ربما تجد فكرة مفتوحة تأخذها جاهزةً و ربما لا, ليس هذا المهم و لكن المهم أن يتسع مجال تفكيرك و تجد تطبيقات كثيرة لل Software و ال Hardware كانت غائبة عنك, و هكذا يمكنك الهروب من المشاريع النمطية التي يكاد يقوم بها الجميع.
حتى لو شعرت أنه لم يبق متسع من الوقت للمعرفة فأقرأ. ربما ينفعك ولو يوم واحد من القراءة لتعرف مجالاً جديدا غنياً بالأفكار.
لا تخشَ إعادة استكشاف الأفكار السابقة
كثيرا ما تكون النتائج أهم من الفكرة نفسها. كان العالَم مليء بمحركات البحث من قبل Google ولم يمنعهم هذا من الأبتكار في نفس المجال. لم يكن ال iPhone أول هاتف محمول ذكي و لم تكن ال #C صادرة قبل ال Java، ومع ذلك كل من هؤلاء قدم تطويرات كبيرة على ما سبق وصار إنجازا في حد ذاته.
لا تخف من الأفكار القديمة و انظر الى مشروع سابق أو برنامج تستخدمه. و سل نفسك كيف أطوره. كيف أتحاشى أخطاء من صممه. كيف أعيد اختراعه. معظم التكنولوجيا التي نستخدمها من GUI أو لغات برمجة أو Office Applications مبنية على نفس المباديء الموجودة منذ السبعينات أو الثمانينات، وبها مجال واسع للتطور. ربما يفيدك أن تلقي نظرة على الأبحاث المنشورة في تلك المجالات لتعلم الأفكار الجديدة التي بُحثت و لم تطبق بعد أو لم تطبق بصورة كلية.
فكر في احتياجاتك أنت
ما احتياجاتك كمبرمج؟ كمستخدم للإنترنت؟ كمستخدم عربي؟ كطالب؟ في حياتك؟
أمثلة للاحتياجات:
- كيف تنظم أفكارك
- كيف تدير نسخ مختلفة من ال code عبر اعضاء الفريق الواحد
- كيف تبحث عن المعلومات
اعرض الأفكار على الآخرين
اجتمع مع افراد الفريق في جلسات brainstorming وناقشوا كل الأفكار المتاحة (حتى لو بدت في حينها سخيفة أو غير عملية). اعرضوا الأفكار على أصدقائكم و على المعيدين. اطلبوا الأقتراحات لتحسينها. لو انتقد أحدٌ الأفكار اسألوا كيف يمكنه أن يتلافى العيوب التي ذكرها. جرب أن تخلط أفكارا ببعضها (مثلا برنامج Resolver خَلَط لغة ال IronPython بفكرة الجداول الألكترونية مثل ال Excel).
قَيِّم مشروعك عملياً
لا تكتف بفكرة مجرّدة فتقول "سأقوم بمشروع عن كذا" فحسب. ارسم رسما تخطيطياً للمشروع على ورق. تخيل أنه تم تنفيذ مشروعك و مثل انك تستخدمه بعد تنفيذه. ارسم screenshots. افعل مثلما فعل Jeff Hawkins مصمم جهاز ال Palm حين كان يمسك بلوح خشبي صغير كأنه كمبيوتر محمول ليجرب الطرق المخلفة للتعامل مع الأجهز-- كان حينا يكتب عليه بقلم و حينا يتحدث إليه صوتيا و هكذ، ليعلم أي من تلك الوسائل تبدو تلقائية و مريحة للمستخدم).
إذا كان مشروعك Compiler أو أداة برمجة فجرّب أن تكتب على الورق نماذج للcode باللغة الجديدة التي تصممها. إذا كان ال GUI جزءا أساسيا في المشروع فلعله يفيدك أن تكتب Prototype يرسم GUI كروكية ليراها باقي أفراد الفريق أو المشرفين.
لا تكتف بتقييم فكرة المشروع "سَمَاعيّا" بأن تتكلم عنه فقط! بل قيِّمها عملياً بأن تصنع رسومات وبرامج تجريبية تكون آثارا حقيقية لتفكيرك.
الجمعة، 13 يونيو 2008
أنت و الصيف : للطلاب خاصة الفرقة الثانية
جاءني سؤال بالبريد الإلكتروني من أحد طلبة الفرقة الثانية عن الطريقة المثلى لتطوير نفسه برمجيا في الصيف, مع وجود اختيارات أمامه مثل التدريب الصيفي, الدورات التدريبية أو تعليم النفس
ربما تكون اجابتي له مفيدة للآخرين, ها هي مع بعض التعديلات و الأضافات
I don't really recommend taking training courses unless they're teaching something that's not possible to learn yourself. The only way a person can succeed in the programming world is through self study, in my opinion.
As for the summer training, well I think college would make students attend anyway. If the summer training is high quality it would be good to participate highly in it and follow it. Ahmed Safwat/Alaa Shaker are planning to give training in design patterns [1][2] in sha2 Allah. I highly recommend that course. Don't miss it!
Regardless of the training, try to expand your own knowledge beyond what you took in college. Try learning Java[1][2], web programming, or a new language like Python[1][2][3] or Ruby. Or maybe learn graphics programming with DirectX or OpenGL.
You need to try to improve your programming techniques (computer science instead of computer technology). Are you good with data structures[1][2]? can you write a linked list or binary search tree without help? These things are very very important. Microsoft interviews for example are all about this stuff. You should learn about advanced data structures like graphs or balanced trees and improve your problem solving abilities. Try reading about algorithms. Maybe even solve some ACM problems[1].
Finally, find a good Object Oriented Programming book and make sure you understand OOP concepts/implementation because your dof3a had problems due to the issue with Dr Roshdy leaving. OOP is essential for any work you'll do in the future. Unfortunately, I don't currently know good OOP books for C# but I might find one and post about it. If you want to improve your object oriented skills with C++ this might be useful to you. Take a special look at the chapters on inheritance, virtual functions and templates.
Summary
1- It's usually better to self study.
2- Don't miss the design patterns summer training. If it's canceled look online and try to learn design patterns yourself.
3- Try to learn a new language and expand into new technologies like Web development or graphics. Some examples are Java, ASP.net, Python, Ruby, Javascript/Ajax, Silverlight, ActionScript/Flex, DirectX, OpenGL...etc).
4- Learn to implement the data structures. Read about algorithms, solve interesting problems.
5- make sure you don't lose OOP concepts.
Obviously, no one is expecting you to do all this at once :)
Just choose one or more of them and do it well, there will be time for the others in sha2 Allah.
ربما تكون اجابتي له مفيدة للآخرين, ها هي مع بعض التعديلات و الأضافات
I don't really recommend taking training courses unless they're teaching something that's not possible to learn yourself. The only way a person can succeed in the programming world is through self study, in my opinion.
As for the summer training, well I think college would make students attend anyway. If the summer training is high quality it would be good to participate highly in it and follow it. Ahmed Safwat/Alaa Shaker are planning to give training in design patterns [1][2] in sha2 Allah. I highly recommend that course. Don't miss it!
Regardless of the training, try to expand your own knowledge beyond what you took in college. Try learning Java[1][2], web programming, or a new language like Python[1][2][3] or Ruby. Or maybe learn graphics programming with DirectX or OpenGL.
You need to try to improve your programming techniques (computer science instead of computer technology). Are you good with data structures[1][2]? can you write a linked list or binary search tree without help? These things are very very important. Microsoft interviews for example are all about this stuff. You should learn about advanced data structures like graphs or balanced trees and improve your problem solving abilities. Try reading about algorithms. Maybe even solve some ACM problems[1].
Finally, find a good Object Oriented Programming book and make sure you understand OOP concepts/implementation because your dof3a had problems due to the issue with Dr Roshdy leaving. OOP is essential for any work you'll do in the future. Unfortunately, I don't currently know good OOP books for C# but I might find one and post about it. If you want to improve your object oriented skills with C++ this might be useful to you. Take a special look at the chapters on inheritance, virtual functions and templates.
Summary
1- It's usually better to self study.
2- Don't miss the design patterns summer training. If it's canceled look online and try to learn design patterns yourself.
3- Try to learn a new language and expand into new technologies like Web development or graphics. Some examples are Java, ASP.net, Python, Ruby, Javascript/Ajax, Silverlight, ActionScript/Flex, DirectX, OpenGL...etc).
4- Learn to implement the data structures. Read about algorithms, solve interesting problems.
5- make sure you don't lose OOP concepts.
Obviously, no one is expecting you to do all this at once :)
Just choose one or more of them and do it well, there will be time for the others in sha2 Allah.
الخميس، 5 يونيو 2008
Lisp's IDE problem - and a proposed solution
Update on 07/06/2008 Edited the paragraph on LispWorks and Allegro to clarify that my criticism is directed at the limitations of the free editions, not the full versions
Lisp is an amazing programming language, with no other single language that I know of combining all of its capabilities. It is a surprise, then, that Lisp isn't as widespread and successful as expected of a language of such power. Many have written about the reasons for the language's lack of adoption, citing a lot of explanations from lack of libraries or parenthesis-heavy syntax to the attitudes of some Lisp advocates.
It is ironic how so many geniuses miss the point!
Here's my (highly personal, insufficiently researched) opinion as to the main reason of this lack of adoption, and a proposed solution to this problem.
While the aforementioned factors certainly contribute to Lisp's lack of adoption, I think they are all solvable problems. Lisp's syntax is unfamiliar but actually easy to learn. Lack of libraries becomes an obstacle later in the Lisp adoption cycle so while they are indeed a problem they are not currently the most significant problem, in my opinion.
As for the community issue: I don't have a lot of experience with the Lisp community but it's hard to believe they're the main obstacle to Lisp's adoption. Linux, for example, survived many years of zealous fans who answer any question by blaming new users for not reading the manual or trying to convince them they don't need any feature that Linux doesn't provide. This did slow down the adoption of Linux but it didn't stop it from having an increasingly growing user base.
It's the IDE!
Lisp needs a good IDE. Almost all Lisp users suggest using Emacs+SLIME for this purpose. That might do the job for a seasoned Lisper, but these tools get in the way of converting new users.
I know Emacs is really, really powerful. I know that SLIME is a very innovative tool that has the potential to lead the way to how all future IDEs are designed. Still, convincing a programmer to use Emacs is a totally separate task from convincing him to use Lisp. Both are not easy tasks and forcing them together doubles the burden of the Lisp advocate and provides a barrier to entry that would chop off a significant portion of potential future Lisp programmers.
Commercial tools
If you don't want to use Emacs, you have commercial IDEs like Allegro and LispWorks. Another barrier to entry: these tools cost too much. The cheapest edition of LispWorks costs $1500 and Allegro costs $599 for academic use (I tried to find the cost of a commercial Allegro license but didn't find a quote on their pricing website).
Both have free starter editions but they don't solve the problem.
I tried the free editions of both of them in mid-2007 while giving a series of Lisp teaching sessions in my faculty. Allegro was a frustration because installing the 'free express edition' required online activation and it wasn't practical to distribute it to students to put on their computers on the first session day since we didn't have a reliable internet connection in the session hall.
I abandoned Allegro and used LispWorks. It's actually a good IDE. Not good by Microsoft or Borland standards, but good in the sense that if you ignore the outdated interface and the lack of features in the personal edition, you could actually write and demonstrate Lisp programs with it. It wasn't frustration free, though.
In the end, while the students liked Lisp as a language and understood its power, many of them didn't want to write Lisp code themselves. I got the feeling that they think the IDE would get in the way and that they would have a bad experience trying to get the programs to run. To encourage them to work in Lisp projects I threw away all the commercial tools and hacked together a toy IDE with C# combining bits from Cusp, SBCL, IKVM and Scintilla.
The tools disappointed me. I don't think that Franz or LispWorks are bad companies or that their tools are inadequate. Their IDE's are very advanced tools on the forefront of compiler and language processing technology. The full versions come complete with libraries for GUI design, web servers, databases and so on. They probably pay for themselves multi-fold and they have lots of customers to prove it.
My problem isn't with the general quality of the tools, but in the fact that they cost too much and that the freeware personal editions are intentionally crippled and give the wrong image to new users. This means that those commercial tools fail to remove the 'lack of free/cheap IDE' as a barrier to entry for programmers who want to use Lisp.
Why did these companies surround the free editions of their tools with the software equivalent of barbed wire? Are they afraid of people actually being interested in their products?
Compare that to Microsoft's freeware Visual Studio Express: It's a very high quality piece of software. It's licensed for both commercial and non-commercial use and they promote the life out of it. Yet it doesn't seem to cannibalize on the sales of the many professional editions sold by MS.
Approaching a solution
One of the best approaches to creating a Lisp IDE is Cusp, the Eclipse plugin for Lisp. It provides an editor with color syntax highlighting and function parameter tips, a debugger, and project management capabilities. More importantly it installs with a few clicks using Eclipse's auto update facility. It's based on SBCL and the Swank part of SLIME so it doesn't sacrifice power either.
Still, it doesn't go far enough in my opinion. For a start, it's heavy since it requires the Eclipse platform to run. Also, creating a "hello world" project with it isn't trivial. The new project wizard creates a package and an assortment of files with no clear indicator of where to begin typing your code. Finally, when you outgrow the REPL and the simple examples you still have to manually install libraries using ASDF (and suffer for it).
The solution
We need a good, intuitive and capable Lisp IDE that is on the same level with professional IDEs like Delphi or Visual Studio. It doesn't need to have the same power as these tools right away, but could initially be simpler and lighter. Still its developers need to have the strategic goal of eventually competing with the aforementioned tools in both power and usability. Here's my personal sketch of such a tool, in detail:
* It needs to be open source or at least freeware. Basing it on something like SBCL wouldn't hurt, either.
* It needs to adopt traditional IDE sensibilities. Users should be able to copy and paste with the familiar Windows/Macintosh keyboard shortcuts. It should have a visual debugger with breakpoints and watches. It should have a REPL but not force developers' workflow through it and instead offer a traditional edit/run cycle. A tool like DrScheme is a good starting point for such a design.
* It needs to have a simple and authoritative name. I suggest OpenLisp, LispDevelop or Lisp Kit. (LispDevelop was the name for the toy IDE I created and which I intend to develop further, but I would happily drop the name from my program if someone wants to use it and I like the direction of his or her IDE).
* It needs to be readily installed on any platform simply by extracting files from an archive. It must avoid all need for compilation, pulling dependencies or using system definition tools like ASDF or cl-build. Installation should include a variety of useful libraries, possibly cherry-picked from existing open source projects.
* Autoupdating libraries should not be a concern for the normal user: upgrading libraries would be done as part of releasing new versions of the IDE itself. These libraries would be tested, packaged and supported by the person/organization that's developing the IDE.
If a user likes to use the bleeding edge version of some favorite library, it's his or her own responsibility to install it; Normal users should not be forced to follow that path. Library developers whose libraries are included as standard with the IDE would need to make their libraries as complete and stable as possible, and not rely on users regularly updating to the latest version to resolve bugs.
If a library is half complete, it should not be included. If a library is half complete but really cool and worthy of inclusion, the entity developing the IDE would offer a nice, big donation to the library developer if he releases a finished version of the library within a specified deadline, complete with documentation, test cases, and easy integration with the IDE.
* The IDE should come with an excellent GUI library and (possibly in a later version) a visual GUI designer. It could be developed from scratch or be based on an existing library. It should showcase Lisp's declarative power and not intimidate the user.
A lot of Lisp GUI libraries like to force the programmer to create lots of abstract objects just to make a simple program and this hides the real power of Lisp. It's certainly a good thing if the GUI toolkit could include layout managers and other powerful abstractions, but the programmer doesn't have to be forced to use them. Instead, something like that should be perfectly doable by the library:
;;
(setf form1
(Form :text "Test Form"
(Button
:x 100 :y 100
:text "Click Me"
:onclick (lambda (ev) (ShowMsg "Hello World")))))
(Show form1)
;;
* The people developing the new IDE have to be persistent! The web is full of half done attempts to "save" Lisp and very few of them worked out.
While I think the project would be best served by being open source and free, if lack of money prevents people from working on the project a business plan could be formed to bring money from the IDE (while not commercializing things too much; such a company should be similar in spirit to Redhat or Mozilla Corp).
* Company or no company, in no way should the IDE be designed by committee. It needs standardization, responsiveness and decisions made based on utility and not consensus. It wouldn't hurt to have a benevolent dictator who's a good leader and has a strong sense of design.
* Usability doesn't mean weak or dumbed down tools. To succeed such an IDE needs to appeal to both beginners and power users and to be suitable for real world projects. Also it should be customizable (yes, even supporting emacs and vi keybindings). It should also be extensible, preferably with Common Lisp itself to avoid forcing users to learn a new language to customize their IDEs. If many users want Emacs Lisp support then perhaps we could go all the way and design a unified extension API to extend the IDE with any language including Emacs Lisp, JavaScript...etc.
This doesn't need to be done all at once, of course. A basic IDE with a focus on productivity would be the first priority, and after a few iterations the real power of the project would show up. We could take a hint from the Firefox or Gnome teams who focused on throwing away all the clutter and bloat from their codebases then built up power on top of a simple and lightweight foundation.
There is no contradiction between having an powerful IDE that's also easy. A large chunk of Visual Studio users don't know the real power of the tool they're using or how really modular, versatile or extensible it is. A lot of Eclipse users probably don't know that the whole Eclipse IDE is exposed as a set of objects for all plugins to see. They simply see Eclipse as good editor/compiler/refactoring tool, while the power users go crazy developing add-ins.
* Finally, the HyperSpec is outdated and looks ugly. From what I understand, there are copyright restrictions that prevent people from freely modifying it and publishing their modifications. An open Lisp documentation project needs to be created and released either in the public domain or with a sufficiently open license. This documentation needs a standard format and a way for plugging additional documentation for libraries...etc, with the ability to index or manipulate the aggregated documentation as a whole with any external tool, including of course our proposed IDE.
If such an IDE were developed, I believe it would be a large step forward in making Lisp more attractive to new developers. It might not make Lisp replace (say) Java or C# overnight and there are still numerous unsolved problems in the language itself, the libraries and so on but a powerful IDE would, in my opinion, give Lisp a fighting chance alongside the Pythons and Rubies of the development world.
الأربعاء، 14 مايو 2008
قوة الCommand Line
منذ بضع سنوات كنت اقوم بمشروع برمجي لأحد الأشخاص. و لكي يظل متابعا للعمل كنت أرسل له البرنامج أولا بأول.
و هكذا تجدني أكرر هذه الخطوات:
1- خذ نسخة من البرنامج
2- أمسح الملفات المؤقتة التي يصنعها ال Visual Studio
5- أرسل الملف بالبريد الألكتروني.
6- إمسح النسخة التي أخذتها.
لو كنت ساعتها أستخدم Linux, لكانت حياتي أسهل بكثير. كنت وقتها يمكنني أن أشغل script مثل هذا:
بمجرد تشغيل هذا البرنامج, سيقوم بعمل الخطوات السابقة وحده و ستجد لديك ملفاً بإسم مثل Program12May08.zip.
طبعا لو أردت تسهيل الأمور أكثر, لكنت أضفت أسطر قليله تجعله يرسل الملف أيضا بواسطة برنامج مثل mailx.
و لو أردت المزيد من السهولة, لكنت أعددت برنامج التنفيذ الآلي cron ليقوم هو بتشغيل الscript يوميا بدلاً من أن أرهق نفسي بتشغيله, وهكذا يمكنني أن أنسى أصلا موضوع إرسال ال code و أترك الكمبيوتر يقوم بالمهمة بدلاً مني!
إضرب هذا في مئات المهام الصغيرة من هذا النوع, و ستعلم لماذا يقوم مشرفو النظم المعتمدين على ال GUI بالتكتكة بالفأرة طوال النهار ليقوموا بعملهم بينما خبراء ال Unix لا يقومون بأي عمل تقريبا و يدعون جهاز الكمبيوتر يتولى الأمور هو.
إذا كنت تنوي استخدام الكمبيوتر استخداماً جادا, فستقدم خدمة كبيرة لنفسك لو تعلمت أدوات ال Command Line و ال Shell Scripting.
و هكذا تجدني أكرر هذه الخطوات:
1- خذ نسخة من البرنامج
2- أمسح الملفات المؤقتة التي يصنعها ال Visual Studio
3- ضع الملفات في ملف من نوع .zip
4- سم الملف بإسم يحمل تاريخ اليوم5- أرسل الملف بالبريد الألكتروني.
6- إمسح النسخة التي أخذتها.
لو كنت ساعتها أستخدم Linux, لكانت حياتي أسهل بكثير. كنت وقتها يمكنني أن أشغل script مثل هذا:
#!/bin/bash
cp -R Program ProgramCopy
cd ProgramCopy
find . -name bin -exec rm -rf '{}' \;
find . -name obj -exec rm -rf '{}' \;
zip -r ../Program`date +%d%B%y`.zip * -x \*~
cd ..
rm -rf ProgramCopy
cp -R Program ProgramCopy
cd ProgramCopy
find . -name bin -exec rm -rf '{}' \;
find . -name obj -exec rm -rf '{}' \;
zip -r ../Program`date +%d%B%y`.zip * -x \*~
cd ..
rm -rf ProgramCopy
بمجرد تشغيل هذا البرنامج, سيقوم بعمل الخطوات السابقة وحده و ستجد لديك ملفاً بإسم مثل Program12May08.zip.
طبعا لو أردت تسهيل الأمور أكثر, لكنت أضفت أسطر قليله تجعله يرسل الملف أيضا بواسطة برنامج مثل mailx.
و لو أردت المزيد من السهولة, لكنت أعددت برنامج التنفيذ الآلي cron ليقوم هو بتشغيل الscript يوميا بدلاً من أن أرهق نفسي بتشغيله, وهكذا يمكنني أن أنسى أصلا موضوع إرسال ال code و أترك الكمبيوتر يقوم بالمهمة بدلاً مني!
إضرب هذا في مئات المهام الصغيرة من هذا النوع, و ستعلم لماذا يقوم مشرفو النظم المعتمدين على ال GUI بالتكتكة بالفأرة طوال النهار ليقوموا بعملهم بينما خبراء ال Unix لا يقومون بأي عمل تقريبا و يدعون جهاز الكمبيوتر يتولى الأمور هو.
إذا كنت تنوي استخدام الكمبيوتر استخداماً جادا, فستقدم خدمة كبيرة لنفسك لو تعلمت أدوات ال Command Line و ال Shell Scripting.
الاشتراك في:
الرسائل (Atom)