SyntaxHighlighter

الخميس، 22 سبتمبر 2011

نظرة أولى على Windows 8 وتأثيره على سوق البرمجيات العربية

أماطت مايكروسوفت اللثام عن أحدث إصداراتها لنظام التشغيل Windows 8 بعد أشهر من تكتم مخابراتي منع فيه حتى موظفي الشركة من معرفة تفاصيل مستقبل القلب النابض للشركة. يأتي هذا الإعلان في خضم منافسة شرسة من Apple و Google على سوق Client OS وإعادة تعريف تعاملنا اليومي مع الحواسب كما فعل Windows 95 من قبل. ولكن التحديات التي تواجهها مايكروسوفت في ذلك الوقت مختلفة تماما عن تحديات اليوم فالمنافسة كانت بالأساس مع IBM ومشروعهما المشترك OS/2 الذي نجحت مايكروسوفت في قتله باستخدام Windows NT و Apple بلا رؤية أو قيادة بعد طرد Steve Jobs في 1986 أما اليوم فالتحدي قادم من خليط خطير من أفكار مبدعة وقوة مالية فهل تستطيع مايكروسوفت المحافظة على سيطرتها على السوق في واقع معقد

  • سوق نظم تشغيل Microsoft نمى 8.8% بينما سوق Apple نمى 15.8%
  • إزداد نصيب مايكروسوفت في سوق نظم التشغيل إلى 78.6% من 77.9% بينما ازداد نصيب Apple إلى 1.6% من 1.7% http://www.gartner.com/it/page.jsp?id=1654914
  • نمى سوق الحاسبات اللوحية 303% في 2011 مع توقعات ببيع 62 مليون وحدة تسيطر Apple فيه على 68% من السوق http://www.idc.com/getdoc.jsp?containerId=prUS23034011
  • عدد التطبيقات على Apple App Store وصل إلى 500,000 تطبيق مع 15,000,000 عملية تحميل
  • باعت مايكروسوفت 450,000,000 نسخة من WIndows 7
  • نظام Windows 7 هو الأسرع مبيعا في تاريخ Microsoft متخطيا في إسبوعين فقط بعد إصداره جميع مبيعات Mac OSX Snow Leopard

توضح الأرقام السابقة قوة مركز مايكروسوفت في سوق نظم التشغيل إلا هناك تهديد قوي وسوق متنامي للحاسبات اللوحية مثل IPad و Android Tablets. تقوم هذه الحاسبات اللوحية على نسخ معدلة من نظم تشغيل الهواتف الذكية التي لا توفر نفس المرونة والقوة المتوفرة لنظم التشغيل التقليدية إلا أنها على الوجة الآخر توفر المميزات التالية

  • تتطلب تجهيزات بسيطة فعلى سبيل المثال يحتوي IPad على 256 MB فقط من الذاكرة
  • مصممة لاستهلاك طافة منخفض لحياة أطول للبطاريات
  • مصصمة للعمل باللمس
  • توفر بيئة آمنة ومستقرة عن طريق تقييد التطبيقات للعمل داخل SandBox يحمي النظام من التأثر من تطبيق سئ سواء عرضيا أو عمدا
  • لا تحتاج إلى مضادات فيروسات أو صيانة مستمرة
  • تبدأ العمل بشكل سريع وتعمل بشكل متواصل

لذا كانت تنادي العديد من الأصوات بأن تتبع Microsoft نفس الطريق وتطور نسخة لوحية من نظم تشغيل الهواتف النقالة الخاص بها نظرا للفشل الذي واجهه Windows 7 في توفير تجربة مماثلة لحواسب IPad أو Android. إلا أن قرار Microsoft كان المغامرة والخلط ما بين المرونة والقوة التي توفرها النظم التقليدية مع السلاسة التي تقدمها النظم اللوحية الحديثة. كان لدي شكوك قوية في قدرة Microsoft على تحقيق هذه المعادلة الصعبة إلا أني بعد ما استخدمت Windows 8 أستطيع القول بأنه فاق كل توقعاتي على عدة مستويات منها

  • الكفاءة: فعلى الرغم من الميزات الجديدة في نظام التشغيل فإن استهلاكه للذاكرة أقل من Windows 7 مع وجود مضاد للفيروسات مدمج في نظام التشغيل يعمل طول الوقت
  • سرعة التحميل: أسرع من Windows 7 بثلاث مرات على الأقل في بدء التشغيل فبإمكاني بدء استخدام الحاسب بعد 8-10 ثوان فقط
  • الطاقة: توفير ملحوظ في استهلاك الطاقة وعمر أطول للبطارية وصل لأكثر من الضعف
  • الأمان: مضاد للفيروسات مدمج مع نظام التشغيل بالإضافة إلى واجهة تطبيقات جديدة تحمي المستخدم. من المبكر الحكم على مدى الأمان ولكن النظام يبدو واعدا
  • واجهة الاستخدام: أقل ما يقال عنها إنها مبهرة فيمكن الانتقال السلس بين الواجهة التقليدية وواجهة جديدة مبنية على تصميم Metro المستخدم في نظام التشغيل للهواتف النقالة من Microsoft والذي يتطلب مقالة غزل منفصلة
  • منصات العمل: دعم للعمل على معمارية ARM مما يفتح الطريق لحواسب أرخص وأصغر
  • منصة التطوير: شهدت أكبر تغيير منذ إصدار Windows فبالرغم من إصدار .NET منذ ما يقرب من عشر سنوات فإنها كانت دائما عضوا من الدرجة الثانية حتى أن معظم إصدارات Linux تأتي محملة ببرامج تستخدم تقنيات .NET مكتوبة لمنصة Mono مفتوحة المصدر أكثر مما يأتي مع Windows.
    التغيير الأكثر درامية هو اعتماد HTML5 و JavaScript كأدوات أساسية لتطوير التطبيقاتز تهدف هذه الخطوة لجذب ملايين المطوريين الذين يستخدمون هذه التقنيات لتطوير تطبيقات Windows التي بالطبع ستعمل فقط على Windows ولن تدعم منصات أخرى. التغيير الآخر هو اعتماد XAML كاختيار آخر لتطوير واجهة الاستخدام مع الاختيار بين C++ أو لغات Managed مثل C# لكتابة التطبيق.
    الهدف هنا هو الوصول إلى أكبر عدد من المطورين للتشجيع على كتابة تطبيقات التي ستباع من خلال Marketplace ستقتطع Microsoft من مبيعات التطبيقات نسبة كما تفعل Apple وبالتالي كان الهدف ألا تقف لغة التطوير عائقا وتمكين المطور من استخدام تقنيات مألوفة. الغوص في تفاصيل منصة التطوير الجديدة مقالات منفصلة لا يتسع لها المقام الآن

تأثير الإصدار الجديد على سوق البرمجيات العربية

سيعطي وجود Marketplace كمكان أساسي لشراء وتحميل التطبيقات قدرة أكبر ل Microsoft على التحكم في النسخ المقرصنة وإن لم تقدم حلول عملية سواء في تخفيض السعر في الدول الفقيرة أو بحلول أكثر إبداعا مثل تقديم نظام التشغيل مجانا أو بثمن مخفض بشرط شراء تطبيقات بمبلغ معين في فترة زمنية محددة من السوق. ستسفيد Microsoft استفادة مباشرة في هذه الحالة من المبالغ المستقطعة من ثمن التطبيقات ولكن الفائدة الأكبر ستتمثل في تنشيط سوق التطبيقات وبالتالي ولاء أكبر من المستخدمين وإقبال أكبر على تبني نظام التشغيل الجديد لوجود تطبيقات مصممة للمنطقة العربية. ستستفيد أيضا من بيع أدوات التطوير للشركات التي ستقبل على بناء التطبيقات كما سيشجع زيادة عدد المطورين للمنصة الجديدة في المنطقة المؤسسات والحكومات على تبني النظام الجديد.
ولكن إذا لم تفعل Microsoft ذلك مع تصعيب عملية القرصنة فإن الأغلب من المستخدمين لن يلجأوا إلى شراء النسخ الأصلية بل إما العمل على إصدارات أقدم أو الهجرة تماما من منصة Windows. لا أرى ذلك مستبعدا خاصة مع التغييرات السياسية في المنطقة وظهور شباب واعد قد يؤسس توزيعات من Linux مناسبة لمتطلبات المنطقة ومهاجمة احتكار Microsoft لنظم التشغيل المكتبية.
التحدي الآخر أمام نجاح نظام التشغيل في المنطقة العربية هو الدفع الإلكتروني. فإن أغلبية المستخدمين في المنطقة لا يتعاملون ببطاقات الإئتمان وإن اقتصر الدفع في السوق الجديد بهذه الوسيلة فقط سيحد بشكل كبير من نجاح النظام. ولكن إذا قامت Microsoft بشراكة مع شركات محلية لتقديم طرق دفع بديلة مثل بطاقات الاتصالات فلن تستفيد فقط Microsoft بل سيوضع أساس تقوم عليه صناعة برمجيات عربية واعدة. فعلى سبيل المثال في مصر كانت الشركات المقدمة لنتيجة الثانوية العامة إلكترونيا تلجأ إلى حجب الموقع إلا من أرقام Dialup مخصصة لتستطيع تحصيل العائد من شركة الاتصالات. ولكن بوجود سوق واسع الانتشار وقابل للاستخدام تستطيع إنشاء تطبيق وبيعه في السوق ونتيجة للمنافسة ستلجأ الشركات المختلفة في تقديم ميزات للمستخدم مثل المساعدة في اختيار الجامعات مما يعود بالفائدة على المستخدم أيضا.
أتمنى أن تقدم Microsoft حلولا خاصة بالمنطقة تعود عليها بالنجاح ولكن أيضا تعمل على تكوين صناعة برمجيات عربية قوية. لكن التاريخ لا يدعو للتفاؤل فعادة لا تستجيب Microsoft إلا بعد ظهور تهديد مباشر لها وبغياب البديل القوي في السوق العربي فلا يوجد دافع قوي للشركة للإبداع والاستثمار في المنطقة بشكل خاص. ولكن بظهور بدائل خاصة مفتوحة المصدر والضغط على الحكومات لاعتماد هذه البدائل في مناهج التعليم والمدارس وداخل المؤسسات الحكومية سيغير الوضع كليا ويعود بالفائدة على صناعة البرمجيات العربية.

الثلاثاء، 5 يوليو 2011

احتقار اللغة العربية من المبرمجين العرب



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

الثلاثاء، 21 يونيو 2011

مايكروسوفت والمصادر المفتوحة Open Source في مصر. عدو أم شريك!

كنت أتمنى حضور مناقشات ملتقى الاستراتيجية المصرية للمصادر المفتوحة لولا وجودي خارج مصر فهدف انتقالنا من خانة مستهلكي التكنولوجيا إلى مقاعد القيادة والإنتاج المعرفي هو أمل يقترب إلى التحقق يوما بعد يوم واستراتيجية واضحة للمصادر المفتوحة خطوة مهمة في هذا الطريق. لاحظت من متابعتي للمشاركين لهجة عدائية لمايكروسوفت باعتبارها نقيض لمبادئ المصادر المفتوحة ورمز للشر. قبل الدخول في مناقشات واستنتاجات سواء تأييدا أو دفاعا عن وجهة النظر هذه أود سرد لبعض الوقائع
- مايكروسوفت بدأت بكتابة بول ألان وبيل جيتس لمترجم للغة البيزيك عام 1975 وهي لغة طورها جون كيميني وتوماس كورتز وعلى حد علمي لم تشتري مايكروسوفت حقوقا للملكية بل استفادت من كونها مشاعا.
- كانت الطفرة والانطلاقة لمايكروسوفت هي شراكتها مع IBM ولكن كعملاق يتعامل مع شركة متناهية في الصغر لم تحصل مايكروسوفت على الكثير من صفقتها مع IBM ولكن أرباحها جاءت مع ظهور سوق الأجهزة المتوافقة التي ظهرت بحيلة قانونية قامت بها شركة كومباك Compaq حيث أن جميع مكونات الحاسب الشخصي كانت متاحة في الأسواق فيما عدا BIOS فاستأجرت فريق قام بهندسة عكسية له وكتابة مواصفة كاملة له وفريق آخر منفصل بإنتاج BIOS متوافق بناء على هذه المواصفات وهنا ظهر هذا السوق بالتحايل على حقوق الملكية الفكرية واستفادت مايكروسوفت ببيع نظام تشغيلها على هذه الأجهزة.
- كانت الحواسيب الشخصية بمثابة لعبة للهواة إلى أن كتب دان بريكلين تطبيق VisiCalc أول تطبيقات الجداول الممتدة Spreadsheets والذي أظهر قدرة هذه الأجهزة في مجال الأعمال. ولم يقم دان بتسجيل براءة للاختراع وظهرت برامج كثيرة معتمدة على فكرته منها تطبيق إكسيل Excel الأشهر من مايكروسوفت. وحاليا لا يزال دان يكتب التطبيقات وخاصة لأجهزة iPad.
- شعرت شركة زيروكس بتهديد من التقنيات الإلكترونية الجديدة على سوقها المعتمد أساسا على التعاملات الورقية فاستقدمت مجموعة من أمهر الباحثين في مختبرها في بالو ألتو لتصور ما ستكون عليه مكاتب المستقبل. من هذا المختبر خرج كم هائل من التقنيات التي تؤثر في حياتنا ومن أهمها تقنية واجهات الاستخدام الرسومية GUI. حيث دعا القائمين على هذا المختبر ستيف جوبز مؤسس شركة أبل للتجول وإلقاء نظرة على الأبحاث وخرج جوبز من هذه الجولة بفكرة واحدة هي تطوير نظام تشغيل يعتمد على الواجهات الرسومية وبالطبع دون دفع ثمن حقوق ملكية لزيروكس وتلته مايكروسوفت في تطوير نظام تشغيلها الأشهر ويندوز.
هناك العديد من الأمثلة التاريخية ولكن سأكتفي بما ذكرته فمما سبق يمكن استنتاج أن الشركات الكبيرة ومنها مايكروسوفت استفادت بشكل كبير من حرية تداول المعلومات ومن أفكار الآخرين وأننا لم نكن لنصل لما نحن عليه الآن بدون هذا التداول. إلا أن الشركات كانت تستفيد من هذه الحرية ثم تغلق الباب على ما تضيفه من أفكار وكان هذا جليا في حالة نظام التشغيل يونكس مما حفز ريتشارد ستالمان على تكوين نظام آخر يعتمد على حرية تداول الأفكار كأساس ومن هذا المنطلق ولدت فكرة البرمجيات الحرة و GPL. وسطع نجم البرمجيات الحرة مع ظهور لينوكس كبديل قوي وفعال لأنظمة التشغيل التجارية خاصة كمنصة للخوادم. وكان موقف مايكروسوفت حاد مع فكرة المصادر المفتوحة وظهر هذا في التصريحات التالية
- بيل جيتس يصف مطوري المصادر المفتوحة بالشيوعيين الجدد في عام 2005 ,ان كل من يحاول وضع قيود على حقوق الملكية الفكرية هو شيوعي
- في عام 2001 وصف ستيف بالمر لينوكس وترخيص GPL كالسرطان الذي يتغذى على الملكية الفكرية ويقضى على حرية الاختيار بين البرمجيات الحرة المجانية والتجارية.
يتضح بجلاء موقف مايكروسوفت منذ مدة ليست بالبعيدة من البرمجيات الحرة والتي بجانب التصريحات كانت تتمثل بممارسات أخرى منها قيود مشددة بمنع أي من مطوري مايكروسوفت بالعمل على تطبيقات مفتوحة المصدر حتى خارج أوقات العمل. ولكن تدريجيا بدأت ثقافة جديدة بالظهور تتضح بالأمثلة التالية
- في عام 2004 روب مانشينج ينشر مشروع Wix على SourceForge كأول مشروع مفتوح المصدر يخرج من مايكروسوفت على الرغم أنه كان يعمل عليه في أوقات فراغه إلا أن دافعه كان اعتقاده بأن الكثير ممن داخل مايكروسوفت لا يفهمون المصادر المفتوحة مما شجعه على أن يعمل على نشر هذه الثقافة بمثال عملي.
- عام 2006 افتتحت مايكروسوفت موقع CodePlex لاستضافة التطبيقات المفتوحة المصدر سواء لمشاريع من مايكروسوفت أو من مجتمع المطورين.
- أنشأت مايكروسوفت مؤسسة OutCurve لمساعدة المؤسسات على تبني التقنيات المفتوحة المصدر حيث تتبنى المؤسسة بعض المشاريع وتضمن عدم التوقف عن العمل فيها ودعمها بالإضافة للتمحيص القانوني لحماية مستخدمي التقنيات.
- تبرعت مايكروسوفت ببعض الكود لنواة لينوكس وعلى الرغم أن هذا الكود يهدف إلى تحسين أداء لينوكس عند العمل على نظام Hyper-V إلا أنها كانت المرة الأولى التي تقوم بها مايكروسوفت بالدخول في منظومة البرمجيات الحرة التقليدية وعالم اللينوكس.
- أصدرت مايكروسوفت مشروع NuGet لتسهيل عملية استيراد واستخدام المكونات المفتوحة المصدر بالإضافة أنه أول مشروع تقبل فيه مايكروسوفت بمشاركات من خارج موظفيها.
- أصدرت مايكروسوفت مشروع WebMatrix كتطبيق مجاني والذي يسهل بشكل كبير تطوير تطبيقات ويب معتمدة على نظم مفتوحة المصدر ويدعم بشكل قوي التطبيقات المكتوبة بلغة PHP.
هناك أمثلة أخرى كثيرة لتغير استراتيجية مايكروسوفت تجاه البرمجيات الحرة ولكن لن أذهب بالاستنتاج بأن مايكروسوفت قد تحولت إلى الملاك البريء المحب للحرية فهي في النهاية شركة رأسمالية ولائها الأساسي للربح والمستثمرين فعلى سبيل المثال أوقفت تمويل مشاريع IronPython و IronRuby لأنهم يمثلوا مدخل سهل للانتقال من منصة ويندوز إلى منصة لينوكس. إلا أن رأيي الشخصي أن هناك مساحة كبيرة للتفاوض والضغط لتكون مايكروسوفت شريكا فاعلا في الاستراتيجية المصرية للمصادر المفتوحة. ولكن ما الفائدة التي يمكن أن تقدمها مايكروسوفت وما الضامن لأن تصب العلاقة في صالح مجتمع المعلومات المصري؟
استثمرت مايكروسوفت بشكل كبير في العلاقة مع المؤسسات التعليمية ولديها شبكة قوية من الطلاب تحت برنامج MSP ومسابقة كأس التخيل Imagine Cup إلا أن غياب المنافسة أدى إلى سيادة الولاء للشركة أكثر من الجودة والانفتاح على التقنيات المختلفة سواء من داخل منظومة مايكروسوفت أو خارجها. ولكن بتكوين شراكة بين مايكروسوفت ومجتمع البرمجيات الحرة سيستفيد المجتمع من شبكة العلاقات وإمكانيات الوصول الأسهل لقاعدة الطلاب وتستفيد مايكروسوفت من تحسين جودة المطورين وبالرغم من أنها قد تخسر بعض المطورين لمنصات أخرى إلا أنها ستكسب مصداقية وجودة من عدد أكبر يعوض هذه الهجرة بدلا من المخاطرة بالعداء لمجتمع البرمجيات الحرة والذي قد ينتج عنه خسارة أكبر. ينطبق هذا المبدأ أيضا على مجتمع المحترفين ففي مصر تمتلك مايكروسوفت العدد الأكبر من المطورين ومن المصلحة المتبادلة تحسين جودة هذا المجتمع وتشجيعه ليس فقط أن يكون مستهلك ومساهم فعال ف البرمجيات الحرة سواء داخل منظومة مايكروسوفت أو لينوكس أو غيرها.
وجهة نظري أن مايكروسوفت يمكن أن تصبح شريكا فاعلا ولكن ذلك يتطلب منها تغيير النظرة إلى مصر والمنطقة العربية عامة كسوق لتصريف المنتجات ولن يأتي هذا إلا بالضغط من مجتمع قوي يستطيع التفاوض والاستفادة من الظروف الجديدة التي نأمل أن تغيير من البيئة الاحتكارية التي كانت سائدة.
أود أن أنوه أني أرتبط بمصالح مباشرة مع شركة مايكروسوفت وقد ينتج عن هذا بعض التحيزات في أرائي إلا أني حاولت بقدر الإمكان التغلب على هذه التحيزات.

الأحد، 12 يونيو 2011

اختبار الوحدات Unit Testing

اختبار الوحدة هو مجموعة من التعليمات البرمجية التي تتأكد من صحة بعض الافتراضات المسبقة عن وحدة من التطبيق. الوحدة هنا هي أصغر جزء من التطبيق يمكن اختبارها وهي غالبا ما تكون method. على الرغم من وجود كلمة اختبار في العنوان فإن Unit Tests لا تهدف في الأساس إلى ضمان جودة التطبيقات أو استبدال مرحلة الاختبار للتطبيق ولكن العمل كمظلة أمان للحماية من مشاكل إجراء تعديلات خاصة في الهيكل الداخلي للتطبيق.

وازدادت أهمية Unit Testing كجزء أساسي من عملية التصميم الارتقائي Evolutionary Design حيث يقوم على البداية بأبسط الحلول للمشكلة الذي قد يكون ذو كفاءة أقل ثم تحسين التصميم تدريجيا عن طريق تقنيات Refactoring والتي تعتمد على تحسين الهيكل الداخلي لوظيفة معينة من دون تغيير النتائج. ولضمان عدم فشل الوظيفة أثناء التعديلات الهيكلية تكون اختبارات الوحدات هي المرجعية التي تسمح بالمغامرة تجربة أفكار عديدة دون العبث بالنتائج المنطقية للتطبيق.

لنأخذ مثالا لتطبيق بسيط للجمع بين رقمين حيث يدخل المستخدم رقمين وعند الضغط على زر يعرض ناتج الجمع

protected void btnAdd_Click(object sender, EventArgs e)

{

    double a, b;

 

    a = Convert.ToDouble(TextBox1.Text);

    b = Convert.ToDouble(TextBox2.Text);

    Label1.Text = Convert.ToString(a + b);

}

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

public class Calculator
{
    public double Add(string a, string b)
    {
        var ad = Convert.ToDouble(a);
        var bd = Convert.ToDouble(b);
 
        return Add(ad, bd);
    }
 
    public double Add(double a, double b)
    {
        return a + b;
    }
 }

وعندها يمكن كتابة الاختبار كالتالي

[TestFixture]
public class CalculatorTest
{
    [Test]
    public void AddOneAndOneShouldReturnTwo()
    {
        var calc = new Calculator();
 
        Assert.AreEqual(calc.Add("1", "1"), 2);
    }
}

هذا المثال يستخدم C# و NUnit ولكن الفكرة مشتركة بين المكتبات واللغات المختلفة ولكن الانطباع الأول قد يكون تم تحويل 5 أسطر من الكود إلى 20 فكيف الادعاء بأن Unit Testing تساعد في زيادة الإنتاجية. يعتمد هذا الافتراض على أن الوقت الأكبر في تطوير البرمجيات يكون في طباعة الأحرف بينما أي شخص قضى أكثر من عدة ساعات مطورا يعلم أن المشكلة تكمن في تقصي وتصحيح الأخطاء Debugging أو إدخال تعديلات وعندها تظهر فوائد الاختبارات الأوتوماتيكية. وكلما زاد تعقيد التطبيق والمزايا الملحقة به كلما زادت باضطراد فائدة الاختبارات. وحتى مع هذا الشكل من المنطق نستطيع ملاحظة فائدتان.

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

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

على الرغم من بساطة المثال الذي كتبناه ولكنه يمثل الهيكل العام لاختبارات الوحدات والتي تتكون عادة من ثلاث مراحل يشار لها باختصار AAA أو Arrange Act Assert

في المرحلة الأولى مرحلة الترتيب Arrange يتم التجهيز للاختبار وفي حالتنا لم يعدو التجهيز انشاء نسخة جديدة من Class. في مرحلة الفعل Act يتم تنفيذ المنطق المراد اختباره وفي المرحلة الأخيرة المسماة التأكد Assert يتم مقارنة نتيجة الفعل بنتائج معرفة مسبقا.

هناك مجموعة من القواعد العامة لكتابة اختبار وحدة جيد لتكوين مظلة الأمان المنشودة لتحقق الاختبارات غرضها.

§ تأكد Assert وحيد لكل اختبار لأنه إذا تعددت فقد يكون دليل على تعقيد الاختبار وأنه يختبر العديد من السيناريوهات في نفس الوقت. المشكلة في هذه الحالة أنه عند فشل الاختبار لا يوجد مؤشر على المسبب لفشل الاختبار.

§ الدقة ، فالاختبارات يفترض فيها أن تكون المرجعية فإذا كانت غير دقيقة فإنها تفقد معناها.

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

نظرا لأهمية اختبارات الوحدات في نظم تطوير التطبيقات الحديثة فإن Frameworks أصبحت تصمم لتسهيل الاختبار كما أصبح ذلك من معايير جودتها فعلى سبيل المثال ASP.NET WebForms يعتبر مشكلة عند الاختبار وخاصة عند الاعتماد على HTTPContext أو Session عامة حيث أنها Sealed Classes وغير معتمدة على Interfaces وذلك يصعب من عملية Mocking لفصل الاعتمادات الخارجية ، كما أنه لا يشجع على الفصل بين المنطق وواجهة التطبيق وذلك يمنع الاختبار كما رأينا في بداية المقال. ولذا فإن ASP.NET MVC راعى ذلك في تصميمه لتسهيل الاختبار والتشجيع على الفصل بين الواجهة والمنطق باستخدام MVC Pattern.

أهمية الاختبارات تتضاعف مع لغات البرمجة الديناميكية مثل Ruby أو Python حيث إنها تكون بمقام الCompiler في التأكد من صحة العمليات وبالتالي يمكن الجمع بين الإنتاجية العالية في Dynamic Languages وأمان Static Languages.

لبدء كتابة الاختبارات يمكنك البحث عن مكتبة ال Unit Testing المستخدمة في اللغة التي تستخدمها والمتاحة تقريبا لكل اللغات تحت مظلة xUnit Frameworks والتي تتبع مكتبة JUnit التي كتبها Kent Beck الأب الروحي لاختبارات الوحدات.

الاثنين، 6 يونيو 2011

مقدمة عن الأجايل Agile كأداة لتخطيط وتنفيذ برمجيات ناجحة

سمعت وشاركت في الحوار التالي كثيرا وربما يدور الآن في مكان ما في هذا العالم بين مجموعة من المطورين المتحمسين وهم يتداولون:

"هنعمل المشروع ده صح المره دي. هانلم اللي عايزه ال User بالظبط ومش هاتتغير في النص ، ونعمل design document ما تخرش المية وهانسلم في الميعاد".

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

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

مشكلة أخرى تنتج عن هذا الأسلوب في التخطيط أن المصمم تكون مهمته هي وضع هيكل يناسب أي متطلبات مستقبلية ورغبة في اتباع الطرق المثلى (Best Practices) وفي غياب أي محددات فينطلق العنان للخيال ويتم وضع هيكل للتطبيق ولا هيكل سليمان وكثير من الكلمات الرنانة التي تنتهي بمقطع ity مثل Scalability, Customizability, Maintainability والنتيجة غالبا تصميم معقد يسقط مع بداية الضغوط لزيادة الإنتاجية واقتراب مواعيد التسليم فيبدأ التجاهل التدريجي لقواعد التصميم حتى يصبح في النهاية حبرا على ورق.

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

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

التخطيط

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

هناك أساليب أخرى للتخطيط تحت مظلة الأجايل مثل Kan-Ban والتي تتبنى عملية مستمرة التدفق مخالفة لأسلوب الدورات المغلقة في Scrum تستمد هذه الطريقة مبادئها من نظريات Lean في التصنيع والتي تعتمد على تقليل الإهدار والفاقد في الموارد وفي هذه العملية يتم تقسيم التطبيق إلى مجموعة من الميزات Features والتي يتم ترتيب أولوياتها ثم تعريف مجموعة منها كوحدة أقل قابلة للتسويق Minimum Marketable Features وتباعا يبدأ فريق التطوير العمل في البناء ولكن مع تحديد حد أقصى للمهمات المتوازية لتقليل الفاقد الناتج عن النقل ما بين المهمات والحفاظ على تركيز الفريق.

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

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

التصميم

قضيت جزءا معتبرا من حيات العملية في دور المعماري وبشكل أدق no-coding Architect أعمل على برامج الورد والفيزيو وبرامج تصميم UML لوضع تصورات لما يجب أن يتبعه المطورون في كتابة التطبيقات ومانت هذه الفترة بلا منافس الفترة الأقل إنتاجية في حياتي وأزعم أنها كانت كذلك ليس لأني معماري فاشل ولكن لأن أفضل المعماريات لاتوضع ولكن تنمو من خلال من خلال التصميم المستمر الذي يستجيب لمتطلبات المستخدمين فعند وضع المعمارية Architecture للتطبيق في المراحل الأولى للتطوير حيث هناك حالة من الضبابية يحاول المصمم توقع العديد من السيناريوهات المحتملة بلا أساس واقعي للأولويات. ولكن مع التقدم في مراحل التطوير تبدأ المتطلبات الحقيقية في الوضوح والتي إما أن تكون مختلفة عن تصورات المصمم أو يكون التصميم معقد بدرجة تعوق الإنتاج فيبدأ التجاهل التدريجي له حتى النسيان التام بلا مردود واضح للتصميم على جودة أو كفاءة العمل.

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

ترتبط البساطة بمبدأ مهم عند التصميم هو YAGNI أو You Ain't Gonna Need It وهو أحد المبادئ الرئيسية لمنظومة XP او eXtreme Programming وهو مبدأ يقضي بأنه لا يجب بناء شيء على افتراض الحاجة المستقبلية له فإنه في الغالب لن تحتاجه أو ستحتاج شيء مغاير. لذلك فإن القرارات المعمارية يتم تأجيلها حتى الحظة المسؤولة الأخيرة Last Responsible Moment ولا بد من التفريق هنا بين اللحظة المسؤولة الأخيرة والوقت الضائع فالفارق يتمثل أن في الأولى يتم تأجيل القرار حتى وضوح العوامل المؤثرة فيه والتأكد من الاحتياج لهذا القرار مما يؤدي إلى زيادة احتماليات جودة القرار ودقته بينما الثانية مجرد إهمال.

التنفيذ

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

دفعت هذه الاحتياجات لابتكار عدد من الحلول التي تساعد الفرق في الاستجابة السريعة ومن أهمها عمليات الميكنة في الاختبارات Test Automation على عدة مستويات.

اختبار الوحدات Unit Testing:

والتي تهتم باختبار الوحدات الأصغر من البرنامج وهي غالبا method وحتى تكون فعالة فإنه يتم تشغيلها باستمرار من قبل المبرمج مع كل تغيير يقوم به ولذا فلا بد من أن تكون سريعة التنفيذ. وحتى تكون نتائجها دقيقة يجب فصل الوحدة عن المؤثرات الخارجية مثل قواعد البيانات لذا تأتي تقنية Mocking كجزء أساسي من التقنيات المساعدة وهي تعنى بتكوين Fake Objects تحاكي الاعتمادات الخارجية External Dependencies وتفصله عن الجزء الواقع تحت الاختبار مما يضمن أنه إذا فشل الاختبار فإنه ناتج عن مشكلة في هذه الوحدة ومما أيضا يسرع في عملية تنفيذ الاختبارات بإزالة التفاعل مع الموارد البطيئة مثل قواعد البيانات والاتصال عبر الشبكات.

اختبارات التكامل Integration Testing:

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

التكامل المستمر Continuous Integration:

عادة ما يتكون فريق العمل من مجموعة من المطورين يعملون بشكل متوازي لتنفيذ مهمات معينة يتم التكامل بينها لتكوين المنتج النهائي وهذا يشكل تحدي كبير حيث أنه كما أسلفنا فإن عملية التطوير تعتمد على الابتكار وحل مشكلات صعب التنبؤ بها مسبقا لذا فإن الاتفاق المسبق على شكل التكامل يمثل تحديا مما يؤدي إلى أن تكون عملية التكامل مستهلكة للوقت ويتجنب المطورين تنفيذها بشكل مستمر مما يفاقم المشكلة حيث تتراكم التغيرات وبالتالي صعوبة الربط بينها. تأتي تقنية التكامل المستمر كحل لهذه المشكلة لحث المطورين على الدمج المستمر لأي تغييرات يقومون بها وميكنة التأكد من نجاح التكامل عن طريق Build Scripts تنفذ في أوقات مختلفة فعادة يكون هناك Script يعمل مع كل تعديل يتم دفعه Check-in إلى مخزن المصدر الخاص بالفريق Source Control Repository وبالتالي لا بد أن يكون سريعا فعادة مايتأكد من صحة عملية الترجمة Compilation ونجاح اختبارات الوحدات وإذا فشلت عملية البناء يخطر فريق العمل حتى يتم إصلاح المشكلة والمحافظة على المصدر المشترك سليما باستمرار. وهناك عملية بناء ليلية Nightly Builds تنفذ يوميا ويزيد فيها عادة تشغيل اختبارات التكامل وتجهيز نسخة لفريق مراقبة الجودة للتأكد من صحة ما تم تطويره وأحيانا كتابة اختبارات تكامل جديدة.

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

الأحد، 1 مايو 2011

صنعة البرمجة – Software Craftsmanship

شرفت بإلقاء بعض المحاضرات في ITI لمجموعة من الطلبة المتحمسين. كان البرنامج مصمم للحديث عن تقنية Silverlight ولكن اقتضى السياق التحدث عن فرص التوظيف في مصر. من أهم النقاط التي ناقشناها هي التفاؤل على المستوى المتوسط بتطور الصناعة وتوفر أكبر لفرص العمل ولكن على المستوى القريب نواجه بعض التباطؤ في التوظيف بل وتسريح للعمالة. في مثل هذه الظروف تكون الضغوط أشد لتحسين الكفاءة الشخصية لتعظيم فرصة الحصول على عمل في ظل تنافسية شديدة. ودفعتني رسالة من أروى أسامة تطلب فيها بعض من المصادر للمعلومات التقنية لكتابة هذه التدوينة عسى أن تعم الفائدة.

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

لذلك اجتاح عالم تطوير البرمجيات أساليب جديدة للإدارة تتحدى نظم الثورة الصناعية وتعيد للعامل البشري مركزيته. وكان هذا جليا في إعلان المبادئ للأجايل Agile Manifesto والذي قدم أفكرا ثورية لطرق تنظيم العمل إلا أن نجاحه الهائل في تقديم برمجيات بجودة أعلى أجبر شركات عريقة في الإدارة التقليدية إلى تبنى هذه الأساليب. ويقوم الأجايل على أربعة مبادي أساسية توضح الفلسفة العامة للإدارة والتطوير. هذه المبادئ هي http://agilemanifesto.org/iso/ar:

إننا نكشف النقاب عن طرق أفضل لتطوير البرمجيات
وذلك من خلال تطبيقها ومساعدة الآخرين على ذلك.
وعبر هذا العمل توصلنا إلى اعتبار:

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

ويعني ذلك أنه على الرغم من كون العناصر على الجانب الأيسر ذات قيمة،
فإننا نعطي قيمة أكبر للعناصر على الجانب الأيمن.

تفرع من هذه المبادئ العديد من منظومات العمل مثل Scrum و XP و KanBan والتي تختلف فيما بينها في عدد القواعد التي تحددها والأدوار التي تتطلبها إلا أنها تتفق فيما بينها على تعظيم التواصل والعمل في إطار يكون الفريق وحدة واحدة تتحدد أدوار الأفراد فيه على حسب الكفاءة وليس المسميات الوظيفية.

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

اختبار الوحدات Unit Testing وتعتبر هذه التقنية أساس لكتابة برامج قابلة للتعديل والارتقاء. تعتمد هذه التقنية على كتابة اختبارات أوتوماتيكية للوحدات المكونة للتطبيق. هذه الوحدات من الممكن أن تكون Class أو Method على سبيل المثال ويشترط أن يتم اختبار الوحدة معزولة عن الوحدات المرتبطة بها ، فعلى سبيل المثال في حال تطوير تطبيق للتجارة الإلكترونية فلا بد من تطوير الاختبارات بمعزل عن قاعدة البيانات وذلك لضمان سرعة التنفيذ وأيضا لضمان أن فشل الاختبار يدل على مشكلة في هذه الوحدة وليس في الوحدات المرتبطة. لا تهدف هذه الاختبارات لاستبدال مديري الجودة ولكنها تهدف في الأساس إلى العمل كمظلة أمان لضمان أن أي تغيير في هيكل البرنامج لا يؤثر على العمل المنطقي للوحدات. مما يشجع على التحسين المستمر لتصميم التطبيق الداخلي دون الخوف من أن التغييرات ستؤدي إلى فشل في أجزاء أخرى من التطبيق.
توجد العديد من المكتبات التي تساعد في كتابة هذه الاختبارات لكل منصة عمل فللدوت نت على سبيل المثال يوجد NUnit والتي تعتبر الأشهر ولكن يوجد أيضا مكتبات واعدة مثل xUnit و MBUnit وللجافا هناك المكتبة الأشهر JUnit

اختبارات التكامل الأوتوماتيكية Automated Integration Testing وتعتبر هذه الاختبارات المستوى الثاني من مظلة الأمان المطلوبة لتطبيق سريع للتغيرات وقد تستخدم فيها نفس الأدوات المستخدمة في اختبار الوحدات إلا أنه في الغالب يتم استخدام أدوات متخصصة مثل Selenium و WatiR و WatiN وهي كلها أدوات مفتوحة المصدر كما أن هناك حلول تجارية من مايكروسوفت وغيرها.

التكامل المستمر Continous Integration وهذه الممارسة في غاية الأهمية لتسهيل التعامل بين فرق العمل وتشجيع التكامل المستمر بين الأفراد. يعتمد نجاح هذه التقنية على وجود اختبارات وحدات وتكامل قوية تضمن جودة التطبيق ككل متكامل في كل الأوقات. إلا أنه يمكن استخدام هذه التقنية بدون اختبارات إلا أنها لن تكون بنفس الفاعلية. من الأدوات المهمة والمفتوحة المصدر للتكامل المستمر CruiseControl و CruiseControl.NET كما توجد أدوات تجارية مثل TeamCity و Team Foundation Server

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

الاثنين، 25 أبريل 2011

مقدمة عن Silverlight –الجزء الأول

ينتمي السيلفرلايت Silverlight لعائلة من الإمتدادات الخاصة غير القياسية Proprietary plug-ins التي تحاول حل مشكلات تعاني منها الحلول القياسية للويب مثل عدم التوافق بين المتصفحات وبطء عملية الاتفاق على المواصفات القياسية وتحولها إلى نموذج قابل للاستخدام في المتصفحات.

تلقت هذه الإمتدادات ضربة موجعة برفض شركة أبل Apple لتقديم أدوب فلاش أو جافا أو أي إمتداد آخر على منصاتها الناجحة للهواتف الذكية والحواسب اللوحية مما نفى طرح هذه المنصات كبديل محتمل للمواصفات القياسية خاصة بعد التقدم الملحوظ لسرعة وكفاءة الجافا سكريبت JavaScript في المتصفحات وظهور مكتبات مثل جي كويري JQuery التي قدمت حلولا سهلة وناجعة لمشاكل التوافق وسهلت عملية التفاعل مع الدوم DOM مما جعل بناء تطبيقات غنية وتفاعلية تقترب من التطبيقات المكتبية Desktop Applications أمرا في متناول اليد ولو ببعض الصعوبة. وازداد الزخم وراء تطبيقات الويب القياسية مع الاصدارات الإبتدائية للمواصفة الخامسة من إتش تي إم إل HTML5 وبداية ظهورها في المتصفحات الحديثة.

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

من أهم هذه المجالات هو تطبيقات الأعمال داخل المؤسسات وخاصة التي تستخدم منصة الدوت نت .NET أو الشير بوينت SharePoint. في هذا النوع من التطبيقات يمكن التحكم في منصة التشغيل والامتدادات المنصبة على الحواسيب كما أن استخدام سيلفرلايت للغات الدوت النت القياسية مثل سي شارب c# يعطي ميزة مهمة للمطورين بعدم الاحتياج للانتقال بين السي شارب والجافا سكريبت مما يؤدي إلى زيادة الإنتاجية وتلبية إحتياجات الأعمال بشكل أفضل. أدركت مايكروسوفت Microsoft لهذه الميزة النسبية فأصدرت فيجوال ستوديو لايت سويتش Visual Studio LightSwitch والذي يستخدم سيلفرلايت كمنصة لبناء تطبيقات سريعة وغنية تعتمد على قواعد البيانات أو تتكامل مع شير بوينت أو حلول الحوسبة السحابية من مايكروسوفت. للمزيد من المعلومات عن لايت سويتش يمكنك زيارة هذا الرابط http://www.microsoft.com/visualstudio/en-us/lightswitch. يمكنك أيضا مشاهدة القدرات الغنية الممكن تقديمها لتطبيقات الأعمال باستخدام سيلفرلايت على هذا الرابط http://pjd.mscui.net/default.htm

مع الإصدارة الثالثة من السيلفرلايت تم إضافة تم إضافة ميزة العمل من خارج المتصفح مما طرحه كمنصة منافسة للتطبيقات المبنية بواجهات التطبيقات الأصلية native APIs والتي يتم تنصيبها على حواسيب المستخدم وتعمل بشكل مشابة للتطبيقات المكتبية. فتحت هذه التقنية الباب لاستخدام سيلفرلايت لبناء واجهات غنية للخدمات الشهيرة للويب مثل الفيسبوك وتويتر. هذا التطبيق من شركة تيليريك Telerik يعرض إمكانيات استخدام سيلفرلايت في بناء واجهات غنية بديلة للواجهات المبنية بالأدوات القياسية للتطوير لفيسبوك ، يمكن تجربة هذا التطبيق من على الرابط التالي http://demos.telerik.com/fdec. تطبيق آخر يبين هذه الإمكانيات هو سوبيس ويب Sobees Web والذي يتيح التعامل مع خدمات تويتر وفيسبوك وغيرها من الخدمات من خلال تطبيق واحد. يمكن الوصول لهذا التطبيق من الرابط التالي http://www.sobees.com/web

تعاني المواصفات القياسية للويب من ضعف شديد في مجال تشغيل الفيديو وهنا يلمع نجم سيلفرلايت كالمنصة الأقوى في هذا المجال حتى بالمقارنة بمنصات لها تاريخ أطول كمنصة فلاش. سيلفرلايت هو المنصة الوحيدة التي تدعم كودك H.264 بجانب VC-1 كما أنه يقدم دعم لتطوير كودك مخصوص في حالة الاحتياج. يدعم سيلفرلايت تقنية حماية المحتوى بلاي ريدي PlayReady والذي يشفر المحتويات ويمنع تشغيلها إلا بعد الحصول على ترخيص بتشغيلها مما يحمي حقوق أصحاب المحتوى الرقمي. إلا أنه يجب التنوية للتكلفة العالية لهذه التقنية والتي تبلغ خمسة عشر آلاف دولار للخادم. يقدم سيلفرلايت تقنية يتميز بها هي السموث ستريمنج Smooth Streaming والمبنية على بروتوكل HTTP القياسي والتي تتيح ترميز الفيديو بأكثر من جودة وقياس سرعة المتصفح باستمرار وتحميل الجودة المناسبة لسرعة المستخدم مما يمنع مشكلة تشغيل الفيديو المتقطع. يستخدم موقع شوفها من شركة لينك هذه التقنية لتقديم خدمة مميزة لمشاهدة الأفلام العربية على الويب. يمكن الوصول للموقع على هذا الرابط http://www.shofha.com.

واحد من الميزات التي ينفرد بها سيلفرلايت هي تقنية الديب زووم DeepZoom والتي تتيح التفاعل مع صور عالية الجودة بكفاءة وسرعة عن طريق تقسيم الصور بشكل هرمي بمستويات مختلفة من الجودة وتحميل فقط النقط المطلوبة للرؤية في المتصفح. كان لي الشرف أن أقدم الاستشارات وأساهم في بناء الجزء الخاص بديب زووم مع مركز الأهرام للإدارة والحسابات الإلكترونية أماك في بناء أرشيف كامل للأهرام خلال مائة وخمس وثلاثون عاما استخدام هذه التقنية. يمكن الوصول لهذه الخدمة على هذا الرابط http://digital.ahram.org.eg/youmy

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

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

الثلاثاء، 12 أبريل 2011

مقدمة عن Sketchflow الجزء الثاني

الجزء الثاني من المقدمة عن SketchFlow

إستكمالا للجزء الأول نعرض كيفية استخدام SketchFlow لبناء نماذج أولية تفاعلية للتطبيقات. سترى تغطية للميزات التالية في هذا الفيديو:

· ربط المتغيرات بعناصر التحكم عن طريق DataBinding

· بناء التفاعل باستخدام متغيرات مخزنة في DataStore

· استخدام SetDataStoreValueAction لتخصيص قيمة المتغير طبقا لشروط معينة

· استخدام DataStoreChangedTrigger

· عرض تفاعل التطبيق عن طريق SketchFlow Animation

· استقبال ملاحظات المستخدم

· تصدير التطبيق

الاثنين، 28 مارس 2011

مقدمة عن Sketchflow


الجزء الأول من مقدمة عن Sketchflow
نظرا لمشكلة في برنامج التسجيل فإن بعض الشاشات لم تظهر. مرفق صور للشاشات التي لم تظهر.
NewProject
Binding