وسام Microsoft
للمحترفين الأكثر قيمة
Most Valuable Professional
لعام 2005

رابط RSS


المنشئ Maker والمؤكد Approver التاريخ: ‎20 Dec 2008 - نوع السجل: مدونة

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

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

ولو تخيلنا جدول الطلبات Orders في قاعدة بيانات الموقع، لكان شيئا مثل:





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

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



رائع ولكن كيف يتم ذلك؟
التصميم البرمجي "المنشيء Maker والمؤكد Approver" سخيف جدا جدا جدا، بل يتعدى مرحلة السخافة بكثير، ولا يحتاج الى شرح مفصل، حيث كل ما يطلبه هو تكوين عمليتين Two Transactions لتحقيق عملية مالية واحدة Single Financial Transaction، العملية الاولى تقوم بانشاء Makes الطلب او العملية المالية، والعملية الثانية تقوم بتأكيد Approves الطلب او العملية المالية.

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




تلاحظ في الجدول السابق ان عملية التأكيد Approving تمت على آخر سجل انشأ الطلب، وقد صممنا برنامجنا بحيث يتحقق من ان عملية التأكيد لا تتكرر بالخطأ (حتى ان تم الضغط على زر تنفيذ اكثر من مرة)، ويمكنك اضافة المزيد من الحقول كوقت التأكيد Approve Time.


لا يقتصر اسلوب "المنشئ Maker والمؤكد Approver" على العمليات المالية فقط، بل يمكنك اعتماده على أي عملية حساسة Sensitive في نظامك، ويمكنك ايضا تطبيقه ان رغبت ان يشرف على العملية اكثر من شخص مسئول في النظام لتكون بمثابة توقيع اعتماد Approve لتنفيذ العملية.


اعزائي المبرمجين، لا تنسوا تطبيق هذا الاسلوب البرمجي في مشاريعكم القادمة واحفظوا حقوق الناس، فهدفنا خدمة المستخدمين وليست تصيد اخطائهم :)

-- تركي



تعليقات (9)


سطح مكتب ثلاثي الابعاد ... رائع ولكن ليس انتاجي! التاريخ: ‎08 Dec 2008 - نوع السجل: مدونة

غالبية اهتماماتي البرمجية Interests والشغف الداخلي Passions يتمحور حول مواضيع واجهات الاستخدام User Interface، احب اقرأ عنها كثيرا وأتطلع الى أي اخبار او افكار او ابحاث جديدة حولها، وبينما كنت باحث عن افكار جديدة لسطح المكتب Desktop وجدت هذا المقطع:



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

اولا: الانتاجية ثم الانتاجية ثم الانتاجية!
تعرف الانتاجية Productivity (بشكل عام) نسبة المدخلات Inputs على المخرجات Outputs، فلو وجدت سيارة س تستهلك 10 لتر وقود لتسير مسافة 100 كلم، وسيارة ص تستهلك 10 لتر لتسير مسافة 80 كلم، فنستطيع ان نقول ان انتاجية السيارة س اعلى من انتاجية سيارة ص (من منظور استهلاك الوقود).

في سياق واجهات الاستخدام User Interface تتمحور الانتاجية حول مقدار المدخلات المطلوبة من المستخدم (عدد نقرات الفأرة، عدد احرف لوحة المفاتيح المكتوبة، عدد ضغطات الازرار، الوقت المستغرق لأداء مهمة معينة بالثواني ...الخ) على مقدار المخرجات التي تظهر امامه او لانجاز مهمة معينة، فلو كان لدينا برنامج س يحتاج 3 نقرات بالفأرة او ما مجموعه 10 ثواني لانجاز مهمة معينة، وبرنامج ص يحتاج نقرتين بالفأرة او ما مجموعه 5 ثواني لانجاز مهمة اخرى، نستطيع ان نقول ان انتاجية برنامج ص اعلى من برنامج س.

ولو تفكر في الموضوع لتكتشف انه فعلا حقيقة، فالمستخدمين يودون انجاز اكثر عدد ممكن من المهام في اقل وقت ممكن (مع العلم ان الوقت في حالات كثيرة يقاس بعدد الثواني او اقل من ثانية!)، ولننظر مثال اجهزة جوال الـ Windows Pocket PC، فبالرغم من عيوبها وكثرة تعليقاتها Suspended والمشاكل الكثيرة بها، الا ان الكثير من المستخدمين يفضلونها بسبب انها اكثر انتاجية من اجهزة الجوال العادية، من حيث تنفيذ الوظائف المختلفة، كتابة الرسائل القصيرة SMS، التنقل السريع بين التطبيقات المختلفة، الخ...

أضف الى ذلك، مزايا كثيرة تؤدي الى زيادة الانتاجية مثل الاكمال التلقائي Auto Complete، التعبئة الجاهزة للحقول Auto Fill، اشرطة ادوات Toolbars، السحب والالقاء Drag and Drop وغيرها الكثير.

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



ثانيا: سهولة الاستخدام
لو طلبت مني تعريف ساحر لعبارة "واجهة استخدام سهلة" لقلت –بكل دقة واختصار وشمولية- بان واجهة الاستخدام السهلة هي التي تمكن المستخدم في التعامل مع البرنامج والتمكن منه وفهمه (لأول مرة) دون الحاجة لقراءة ملفات التعليمات Help Files، ودون الحاجة للحصول على شرح من المطور، ودون الحاجة لأخذ كورس تدريبي حوله.

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



ثالثا: الأناقة
تتميز البرامج العربية بذوق رائع جدا في واجهات استخداماتها، ازرار كبيرة الحجم، الوان برتقالية مع كتابة خضراء، خطوط صعبة القراءة (مثل Simplified Arabic خاصة ان كان حجم الخط صغير)، خلفية لصورة (بالعادة مسروقة) ليس لها علاقة بمضمون البرنامج (لقد وجدت احد البرامج المحاسبية الذي وضع صورة لجبال خضراء في خلفيته!)، رموز Icons غير متطابقة في التصميم (نصفها من موقع س ونصفها من موقع ص وجزء اخر يأتي مع Windows وجز اخر لا يمت للعملية بأي صلة)، واكثر شيء مؤلم عدم اتباعها للمعايير القياسية Standards لغالبية البرامج التي تعمل تحت نفس بيئة نظام التشغيل او منصة العمل (لا تزال الكثير منها –مع الاسف- تعتمد اسلوب شاشات الـ DOS في توزيع وظائف البرنامج).

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




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

بالنسبة للمقطع الذي ذكرته (وبالمقارنة مع سطح المكتب الحالي)، اعتقد انه ابدع في اناقة واجهة الاستخدام 100%، وقدم سهولة الاستخدام بشكل اقل 70%، اما انتاجيته فأرى انها أخفقت الى 50%.

-- تركي

تعليقات (7)


هكذا علمتني البرمجة التاريخ: ‎29 Nov 2008 - نوع السجل: مدونة

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

1. اياك ثم اياك ان تكتب نفس الشيفرة المصدرية Source Code اكثر من مرة في برنامجك!
-- بروس مكيني


2. لا تجعل هدف برنامجك ان يسهل الامور (قدر) المستطاع، ولكن اجعل هدفه ان يسهل الامور (اكثر من) المستطاع.
-- بروس مكيني


3. من الغريب ان تكون الواجهات Interfaces [التي تستخدم مع الفئات Classes] اقل استخداما في أي مشروع، بالرغم من انها اكثر مبدأ برمجي اثبت وعوده [الكائنية التوجه Object Oriented] على مر التاريخ.
-- بروس مكيني


4. لا بأس من تدارك الاخطاء المتوقعة Handling Expected Errors في الاصدار الثاني.
-- لارس ويرزينيوس


5.ليس عيبا عليك ظهور اخطاء في المخرجات Outputs ان كانت المدخلات [من المستخدم] خاطئة.
-- لارس ويرزينيوس


6. السرعة مهمة، ولكن امكانيات برنامجك تبقى اهم.
-- لارس ويرزينيوس


7. الذي لم يلامس لغة C في حياته، من الافضل ان لا يعتبر نفسه مبرمج ابدا.
-- مارك فينيو


8. تعلم البرمجة سهل جدا ولكنها اكثر تعقيدا مما تتصور.
-- ستيف ديسبنسا


9. المبرمج الحقيقي لابد ان لا يخشى المستقبل ابدا.
-- دانيا ريد.


10. استخدامك لمولدات الشفرات Code Generators قد يجعلك تكتب شفرات أكثر مما لو لم تعتمد عليها!
-- جستن جيميس


11. صحيح انه يبدو لك ان برنامجك يعمل ما تأمره به، ولكن ذلك لا يعني انك كتبت البرنامج بشكل صحيح.
-- ك. س. ب.


12. ان لم يعمل كودك بشكل صحيح، فلا تمدحه ابدا [مهما كانت طريقة كتابته].
-- ك. س. ب.




حكم شخصية:

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


1. كلما زادت الانتاجية Productivity كلما –مع الاسف- قلت كفاءة التنفيذ Performance.


2. ان يكون المختبر Tester هو نفسه المبرمج، فهو من المحرمات في عقيدة صناعة البرمجيات.


3. قلة عدد سطور البرنامج لا تعني (دائما) ان تنفيذها اسرع!


4. عندما تبدأ بكتابة الاصدار الاول لبرنامجك، فكر دائما بالإصدار الثاني (حتى لو كان الاصدار الاول هو الاخير).


5. اكبر خطأ يعتقده الكثير من المبرمجين هو امكانية كتابة برنامج دون اخطاء.


6. عندما تضع موعد لتسليم مهمة معينة Deadline، اضرب الفترة التي وضعتها في 2.


7. البرامج Software هي المشاريع الوحيدة التي لها بداية ولكن ليس لها نهاية.


8. وهي ايضا اكثر مشاريع (على مستوى الصناعات المختلفة) يتم الغائها!


9. كتابة 1000 سطر لبرنامج جديد من الصفر خير من تنقيح وتعديل كود برنامج ذا 100 سطر.


10. كلما زادت جمل الشرط If في شفراتك المصدرية، كلما زاد ذكاء برنامجك.


11. البرمجة كائنية التوجه OOP عبارة ساحرة للمبرمجين ولكنها لا تعني شيئا للمستخدمين (فلا تهتم لكودك وتنسى برنامجك).


12. لا تثق في الاختبار الاول لبرنامجك الذي يعتمد على مسارات تنفيذ متعددة Multi-Threading، فنجاح التجربة الاولى والثانية والثالثة ليس دليلا على نجاح التجربة العاشرة!


13. الكثير منا يعرف كيف يكتب شفرات Code، ولكن القليل (جدا قليل) يعرف كيف يكتب برامج Software.


14. المضحك في كتابة التعليقات Comments انها تضيع الوقت سواء استخدمتها أم لم تستخدمها!


15. التحقق من المدخلات Validating Inputs عمل ممل ويتطلب جهد اضافي، ولكنه ساتر للكثير من الفضائح!


16. كلنا ننصح بعدم استخدام Goto، ولكن الحقيقة اننا (جميعا) نستخدمها في السر.


17. الذي يدعي ان لغته هي افضل لغة برمجة، فاعلم انه مستخدم وليس مبرمج.


18. علمتني البرمجة ان افضل طريقة لتحليل المتطلبات Analysing Requirments هي رسم الشاشات Prototyping.


19. كلما جعلت وحداتك البرمجية Programming Modules مغلفة اكثر Encapsulated، كلما زادت استقامة برنامجك.


20. برنامج ((وهمي)) لا يقوم بأي عمل ولكنه ذو واجهة استخدام جذابة، يرسم ابتسامة واندهاش ويكسب اعجاب اكثر للمستخدم من برنامج ((حقيقي)) ذو واجهة استخدام سيئة!


-- تركي





تعليقات (16)


مبروك علينا جميعا التاريخ: ‎20 Nov 2008 - نوع السجل: مدونة

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

المبرمجين الوسيمين .. المبرمجات الجميلات

اقدم لكم كتاب"خطوة خطوة مع Visual Studio 2008"



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

يعتبر هذا الكتاب من اوائل الكتب العربية التي تحدثت عن احدث نسخة من Visual Studio، كما ان مؤلفه لم يتجاهل التقنيات الجديدة مثل LINQ و WPF وغيرها. الى جانب الدقة في الشرح والأسلوب الاكثر من رائع لتتحول الامور المعقدة وكأنها كتابة برنامجك الاول "Hello World".

بالنسبة لي فقد بدأت بقراءة هذا الكتاب حتى اتعلم منه واستفيد وأسد الثغرات (الكثيرة) في معرفتي البرمجية بتقنية .NET وأتمنى منكم البدء بقراءته فهو كتاب نادر جدا!

ربط الى احد صفحات الكتاب


-- تركي


تعليقات (7)


المساعد العقاري 2009 التاريخ: ‎13 Nov 2008 - نوع السجل: مدونة

بتوفيق من الله عز وجل انتهينا من انجاز النسخة القياسية Standard Edition للمساعد العقاري 2009:




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


احصائيات سريعة:
عدد الفئات Classes: اكثر من 166 فئة.
عدد السطور للشفرات المصدرية: اكثر من 250,000 (ربع مليون) سطر.
عدد ملفات المشروع: اكثر من 320 ملف.
الوقت: اكثر من 4 شهور (متواصلة).
بيئة التطوير: Visual Studio 2008.
عدد فريق التطوير: 1.


تعرف على المساعد العقاري 2009

لانزال البرنامج (92 ميجا بايت)

لانزال البرنامج دون الـ NET Framework. من هنا (41 ميجا بايت)

ملاحظة: اطار عمل NET Framework. الاصدار 3 وما بعده لابد من ان يكون مثبت بالجهاز.


-- تركي

تحديث:
تم تحميل البرنامج دون الـ NET Framework.



تعليقات (24)

عدد السجلات: 23 |< < > >|

الرئيسية راسلني بحث سجل الزوار حول