Lakhasly

شرحنا ثلاث أنواع من الموديلي بيو كونترولر، بعدين عملوا فيرجن حديث منه للويب، وبعدها بسموها موديلي بيو كونترولر ويب، وبعدها انتقلنا لأحدث إشي اللي هو الـsingle-page-application، js، هدول بيستخدموا الـprocessing أو الـbusiness logic بصفحة الـclient-side أو بصفحة البراوزر، بيكون عندك server-side وclient-side، الـspring-boot، الـspring-java، هدول كلهم بيشتغلوا على الـstyle الثاني للموديلي بيو كونترولر، اللي اسمه موديلي بيو كونترولر ويب. وشفنا أنه الـeffort البرمجي اللي الـdeveloper بيعمله أصعب من التطبيق نفسه، وصمم للـweb-applications اللي فيها complexity عليه. هذا الحكي كله حكينا ويمكن شرحنا الـexample كامل، هذا الـexample بس عشان تعرف أنه الـeffort اللي بتحطه بالـapplication البسيطة في الموديلي بيو كونترولر، رح يكون غير مناسب أنك تستخدم له هاي الـapplications البسيطة، Shutterstock طبعاً حكينا الـmonolithic-application كل أجزاء التطبيق العملي أو كل الموديولز اللي بتبنيها، بنعملها aggregation تجميع أو بتنحط في بروسس واحدة على الـoperating-system طبعاً في الـrun-mode، يعني لما تشغل التطبيق العملي جميع أجزاء التطبيق اللي هما عبارة عن موديولز بيكونوا، كلها بنعملها encapsulation، يعني هاد التطبيق كامل بيشتغل في الـrun-time على بروسس واحدة في نظامك التشغيل. بمعنى آخر إنه هاد التطبيق فيه dependency عالي بين الموديولز اللي موجودة عنه، فيه عنا خيارين حكينا، وفيه خيار تاني الhorizontal scaling إللي هي تزيد عدد الأجهزة اللي موجودة عنا. لكن بالنسبة لمشاكل المونولوتو تيك أبليكيشن، بيعاني من مشكلة من ناحية الscalability، ليش؟ لأنه ببساطة هاد التطبيق اللي بيشتغلوا كل الأجزاء الموديولز الموجودة فيه في بروسس واحدة، متطرة أجيب جهاز جديد وأنقل كل الموديولز الموجودة بالتطبيق على الجهاز الجديد، زاد عدد المستخدمين عليه، ما بقدر أعمل scaling لموديول 6 في المونولوتو تيك أبليكيشن، لازم أعمل scaling لكل التطبيق العملي اللي موجود على جهاز آخر، وهذا الحكي مش efficient، ليه؟ لأنك إنت عم تستهلك resources زي سيرفرات، عشان بس تعمل scaling لسيرفرات معينة من هذا التطبيق الموجود، فهذا تعتبر من المشاكل الأساسية الموجودة في المونولوتو تيك أبليكيشن. اللي هي تحرير نسخ من هذا الابليكيشن بطيئة جداً، ليه؟ لأنهم التيم اللي بيشتغلوا على هذا الابليكيشن، ما عندهم يعني بمعنى آخر ال-permission، السبب إنه أي تغيير في أي موديول من هاي الموديولز، لازم يكون جميع الموديولز عارفين عنها. ببساطة اللي بيصير كالتالي، ممكن يكون عدة developer بيشتغلوا في الابليكيشن، وباقي الموديول جاهزين، لهاي الموديولز الجاهزة، لحد ما ينتهوا شميع الموديولز من ال-development، وبعدين ينعمل testing لكل الموديولز مع بعضها، وبعدين ينعمل releases لهم مرة واحدة، كل الموديولز الموجودة في ال-monolithic application موجودة في بروسس واحدة، ك-micro service موجود على بروسس، هذا الموديولز موجود على بروسس، وكل-micro، زي ما حكينا من الموديولز، كل شق منهم يعتبر-micro service بحد ذاتها، يعني هم بيحكوا مع بعض، لكن هم بشكل عام self-contained. ليه؟ لأنه ببساطة، اللي فيها module رقم 5، أو عملية installation لهاي ال-service لحالها، أو يعني ضغط من قبل اليوزر، لأنه independent عن ال-services الأخرى، وتنقله على سيرفر آخر، مش بالضرورة تعمل عملية installation لكل ال-application، مقارنة بال-monolithic أسهل، ليه؟ لأنه ببساطة كل process، كل process بتشتغل بشكل منفصل، طبعاً، فمباشرة ال-developer بيقدر يعملها installation، ويعمل release من هاي ال-micro service اللي موجودة، على ال-production side، يعني على سيرفرات رئيسية وتكون شغالة، أو كل ال-micro services تنتظر بعضها. مقارنة بال-monolithic، إنه ممكن يتبرمج كل-micro service على تكنولوجيا معينة، وأبرمجها على جزء منها على ال-angular JS، فممكن تدعم multi-technologies فيهم. والشغلة كمان المهمة إنه الفيليارز اللي بيصير في التطبيق العملي بارشالي، لأنهم أصلاً هدول ال-services كل واحدة كأنها application بحد ذاتها، فهذا الإشي جاي مميز فعلياً بال-micro service architecture. بيطلبوا requests من بعض، فممكن يعمل لك communication عالي أو latency عن network أو congestion عن network، فبيبطئ لك التطبيق العملي بشكل عام، والمشكلة الثالثة الموجودة عنا إنه ممكن يكون لأنها هاي ال-micro services distributed على عدة-devices أو عدة-servers، فعملية نقل ال-data بين هاي ال-services، اللي هو المسج queuing، فيه خلل، بتضل preserve، يعني بتضل محفوظة عندك بالqueue، النظام scalable، على سيرفر واحد، كيف لي priority queue، وتوزحها عدد سيرفرات موجودة عندك، هلا، الاشي المهم كمان اللي موجود بهذا الdesign، asynchronous، شو يعني asynchronous؟ يعني الclient ما بيهتم، بيرمد المسجات، المسجات كلها بتتخزن بالqueue، والسيرفر بيعملها عملية processing براحته، بين الclient والسيرفر، هذا بيسمح لك إنه الclient والسيرفر يشتغلوا، كل واحد بيشتغل بشكل منفصل، وهذا بيعمل لك كمان time decoupling، ببساطة، حتى لو صار فيه اختلاف في البودرات، ففيه كتير تطبيقات بتشتغل، بتنبنى على شكل message queuing، اللي هو الobserver pattern، ببساطة، لهذا الdesign. الآن شوف فكرةه ببساطة، فكرةه ببساطة إنه، لازم يكون عندي publisher، تمام، لازم يكون هدول الlisteners، تمام، أو extension له. بس هون بشكل عام بيحكي لك المسجات، بيسموها event، فهو نفس design حرفياً، message queuing in addition، إنه listener أو subscriber، أو بالنظام، اللي هو بيعمل receive للnotification، أو الobserver، لevents معين، لمجموعة من الevents، بيكونوا مسجلين already، عند مين؟ عند البublisher، فببساطة هو بيشبه نظام الobserver، أو لخلينا نحكي اللي بيعمل notification، بيكونوا عاملين registration عندهم، وأي event بيصير عند البublisher، مباشرة بنعمل notification للsubsystems اللي موجودين عندهم، طبعاً هدول الevents بتخزنوا داخل queue، عشان إذا صار فيه اختلاف البودرات بين السيستيم الأول، بتتخزن المعلومات كلها، فهو شبيه بالdesign الأول، أو بمعنى آخر extension إلو. هي اسمه pipe and filter architecture، الآن المطلوب منك عشان تكون عارف كيف طبيعة الماتريال هاي، على الأغلب بجيب لك نظام، طبعاً؟ ممكن أجي أحكي لك عندي airline system، وعندك sales system، sales system بدو يعمل notification، بكون حكيت لك description، برسم معين، على شكل على سبيل المثال publisher subscriber، أن الpublisher هو اللي بعمل publish لل event، والsubscriber هو اللي بستقبل notification، وترسم للdiagram الكورسبوند إلو، الabstract level تبعه كيف بيشتغل، ما أكيد تعرف كل واحد شو الفوائد، تمام؟ ونتيجة هذا الفلتر، بتعمل communication مع بعضها عن طريق الpipes، تمام؟ في كتير تطبيقات عملية بنيت على هذا الdesign، أشهر التطبيقات العملية اليونيكس كومند، احنا لما نكتب على اليونيكس كومند معين، عن طريق الكومند لاين، تمام؟ بتم ترجمته، وبعدين ترتبها، أو ترتب الcontents اللي داخلها، بتفلترها حسب. هذا فلوت، فتدخل على موضوع السيمانتيك أناليسيز، كل بلوك من هذه البلوكات أو كل فلتر عبارة عن برنامج كامل متكامل برمجياً، ستبرمج لغزيكال أناليسيز، برنامج يعمل التوكينيزيشن، برنامج يعمل السينتاكس أناليسيز، ستفهم برمجياً كيف فعلياً الابليكيشن اللي بتكتب وبنعمله كومبيليشن بشكل عام بأي لغة برمجي، بتطلع منها انستركشن جديد، اللي هي تطلع الانترمديت لانجويج، الانترمديت لانجويج اللي هي أسيمبلي لانجويج، قبل ما تحولها لماشين لانجويج اللي موجودة علينا، طبعاً فدول كل بلوك منهم عبارة عن أبليكيشن كامل متكامل، كتير كتير كبير بس أنا بحكي، ممكن تعمل كومبايلر بسيط مكون من كم جملة برمجية طبعاً، لكن بشكل عام الكومبايلرات بتكون فيها كومبليكسيتي عالية في بناء. يعني ما راح بكورس تبني كومبايلر لانسي ولا جافا، ما راح تبني لبرنامج بسيط دوميني سبيسيفيك لانجويج. اللي مطلوب منك انك تعرف انه هاي بعض التطبيقات العملية اللي بتستخدم مبدأ البيب اند فلتر. شو فيه أخرى تطبيقات ممكن تستخدم مبدأ البيب اند فلتر عندك الانتر برايس البزنس، ويركي فلو، ويركي فلو كيف بدك تدفع فاتورة معينة، بتأول إشي بتتم إصدار الفاتورة تقرأها، تحدد قديش مقدار البيمنت، يا إما بتشوف امتى آخر موعد لتدفع، وبعدين بتحط ريمايندر انك رح تدفع باليوم لفلاني، أو مباشرة بتدفع تاخد وصل نتيجة انك دفعت، يعني أمامك خيارين يا بتدفع بشكل مباشر يا بتأجل الدفع بمعنى أخر، كل بلوك فيهم فلتر بعملك أكشن معين، هلا بشكل عام، شو بتشوف فوائد ولميتيشن في هذا الديزاين؟ أول شغلة، أو في حدا عامل كومبايلر، وأكيد الليجزيكال أناليسيز ما رح يختلف، وين ما تحطه بأي لغة برمجينة، رح يكون البرنامج اللي بيعمل توكينيزيشن نفسه، يعني منفصل لهاي الفلترات عن بعضها، بس بتستخدم السيربيسز من بعضها، ففيري إيزي تعمل ريوز للابليكيشن. كتير مناسب بالويركي فلو، يعني أي اشي بتلاقي فيه ويركي فلو، هذا فيك ببساطة تروح تبنيه على شكل بايب أنت فلتر. لأي فلتر سهل جداً، انك تعمل وتضيف تعمله انتجريشن بالسيستم، ممكن يشتغل سيكوانشالي وممكن يشتغل كونكرانتلي، هذا سيكوانشالي وراء بعض بس هذا كونكرانتلي، لأنه انا ممكن اعمل فورك امشي بهذا الفلو، what the same moment امشي بهذا الفلو، فبشتغل على كل مبادئ الفوركينج ديزاين، ليه ببساطة سيكوانشالي او كونكرانتلي. هلا وين المشكلة في هذا الديزاين؟ المشكلة انه اذا زادت عدد البلوكات او الفلاتر، بزيد الoverhead عالسيستم، طبعاً يعني انت تخيل هذا النظام، ويبعطه للي بعده انت، هاي مشكلة من المشاكل الموجودة. المشكلة التاني في الديزاين انه، اذا كان الفلتر الاول مش على علم بال data format، رح يصير في عنا خلال في النظام ليه؟ لانه تخيل ال output اللي بيطلع من هذا البلوك عبارة عن json file، واللي بيستقبلوا البلوك التاني او الفلتر التاني عبارة عن xml file اذا اختلف الفورمات ال data طريقة وصف المعلومات بين الاطراف بصير عنا خلال بالنظام. فلازم يكون الطرفين agreed، اللي بتنتقل من طرف الى طرف اخر، لازم يكون متفق عليه مسبقاً، واقل بصير عنا خلال في عملية transformation، فمعناها انه انا اذا بدي اعمل reusing، لاي مقطع منهم لازم اكون على علم بنوع ال data structure و نوع ال data structure اللي طلع فورمات ال data، يعني تخيل معي هذا ال design، بتطلع لك data عشاكل tree، نوع ال data structure اللي طلع فورمات ال data فيه عشاكل tree، وهذا بيستقبل لكها عشاكل linked list، طبعاً هاي من اكتر ال limitation اللي ممكن الواحد يشوفها في ال pipe and filter architecture design. ليه لانه بتاخد ال data من excel sheet من csv file، تنظف ال data، مرات بيكون فيها corruption data، مرات بيكون فيها outliers، مثلاً تبها 40، فش درجة حرارة بتوصل 200 سلسيوس عصابين المدالة، فبدك تعمل cleaning لل data تشيل outliers، بعدين بتعمل data engineering، او بيسموها feature engineering، شو feature engineering معناها، في عندك عصابين للمثال، ال price لل بيوت، يعتمد على كم غرفة موجود فيه، او يعني قديش هو close من الفacilities، هلق فيه مجموعة من المعلومات موجودة، وانا اللي بدي اعمله prediction على سبيل المثال ال price based على input هذي الاربعة والخمسة، بدي اشوف سعر البيت هذي، بس فيه معلومة مش كتير مهمة او مش related لسعر البيت، فهذا الfeature engineering شو معناها، الفeature engineering معناها انه بدي اشوف من هاي الفيتشارز اعمل reduction او اعمل remove للفيتشارز اللي مش مهمة، اعمل reduction او اعمل remove للفيتشارز اللي مش مهمة، لانه اذا بدي استخدم كل ال data ممكن كون حجمها ضخم جداً او الcolumns كلها، فبالتالي ممكن يتأثر على performance الموديل، فمنعمل اشي منسميه feature engineering، بعدين بتروح النتيجة بعد ما تعمل feature engineering لتريننج للموديل، وبعدين بتروح لعملية validation الموديل، وبعدين بتروح للdeployment. فهدول كلهم style بنسميهم او اي machine learning approach بتشتغل على مبدأ اللي هو pipe and filter style، Shutterstock نيجي لاخر style عندنا اللي هو الbeer to beer architecture، اللي اخدوا نتويرك اكيد سمعوا بهذا اللي هو الbeer to beer او الpoint to point بسموه، بس انا بحكي هلأ عن الversion اللي بسموها mesh، المشة اللي معناها انت بتشبك الاجهزة بعض بعض بدون ما يكون عندك اي هيكلية داخلية infrastructure-less، ملهاش infrastructure معين، ملهاش structure معين. لكن ان وجد سيرفر في الdesign تخيل هذا السيرفر، for monitoring للapplication، اللي هو احنا كنا نسميه زمان semi-centralized architecture، لكن هذا distributed architecture بالعادة الclients بيحكوا بشكل مباشر مع بعض، يعني هذا كتير مستخدم في wireless networks فعليا، من الفوائد الكبيرة انه الاجهزة بتصير تستفيد من computational power والstorage الموجود عند الاجهزة والاخرى في الشبكات. هدول الwireless sensors مزروعين في بيئة معينة، تمام وبيستقبلوا هدول الsensors بيقرؤوا الenvironment، وبيدهم يعملوا computation based على الenvironment الموجود. يعني خلصت البطارية او صارت في low level، الفكرة من الdesign هذا الbeer to beer انه بيقدر يعمل عملية transfer للcomputation للاجهزة الاخرى، عشان يستفيد من الباور والstorage الموجود عند الاجهزة الاخرى فبتصير الاجهزة تتنقل عملية الcomputation بين بعضها. فهاي فائدة الbeer to beer بشكل عام، الاستفادة من الresources الموجود resources المقصود فيها الcomputation power زي البطاريات الstorage الhard disks and so on، عشان تعمل تكمل الcomputation كامل في الشبكة الموجودة. تمام كل node من هاي قد تكون server وقد تكون clients، وكل طبعا لاحظ الresources الموجودة في حدا بعمل consuming، في حدا بزودك بالresources، يعني ممكن هذا يكون جهاز ماعمل computation فممكن يعطي لهذا الجهاز power او يعني يطلب جهاز 13 من جهاز 12 يعمل الcomputation عند node رقم 12 على سبيل المثال ممكن هذا يخزن عند node رقم 12، فبصيروا يستفيدوا من الresources اللي موجودة عندنا وهذا بعمل collaboration في الapplication. زي هيك كتير بيستخدم الbit torrent اللي هو file sharing، عملية الdownload في الfile sharing ليه لانه ببساطة انت لما تيجي تسايب على جهاز ممكن هذا الجهاز تكون resources تبعته storage استهلكت، فممكن تستغل الstorage اللي عند node 8 تخزن عليها وتعمل sharing لهاي الملفات عليها، فهاي ببساطة مبدأ الpeer to peer architecture كتير مستخدم للnetworking، هذا من اكتر الarchitecture style اللي راح تشوفه في موضوع الnetwork بين الاجهزة، يعني اذا طبيعة التطبيق العامل يتبعك networking ببساطة راح تشتغل على هذا. هاي يا جماعة كل الاجهزة كل الأحوال مبلع يا علي مبلع، بس ما هو شو الفكرة كانوا عشان هيك كنت احكي لك عن الsemi-centralized السيرفر الرئيسي اللي بيكون كل المستخدمين هدول عاملين registration عندهم بهدف حفظ السيكوريتي اللي موجود، لكن فيه بروتوكولات بتضبط هذا الحكي. هاي جميع الarchitecture styles اللي ممكن انت تستغلها لبناء انواع مختلفة من التطبيقات العملية، starting من الlayered والmodel view controller المخصصين للweb، وانطلاقا باي نوع اخر من التطبيقات العملية زي compiler زي networking system، يعني فيه كتير يعني هون الlayered والmodel حكينا web microservice اذا بدك تبني التطبيق وتستغل فكرة scalability، الpeer to peer متخصص اكتر في التطبيقات الnetworking اللي فيها networking. فهاي معظم الarchitecture styles very common المستخدمة جدا في بناء التطبيقات العملية up to date يعني لحد ايامنا هاي كلها بتستخدم في بناء التطبيقات العملية. بيركز على الdesign principles الsolid principles، الcoupling الdecoupling الproperties الخاصة في الdesign. يعني we assume اننا جمعنا requirements، we assume عملنا الdesign عملنا الimplementation وهلأ بنروح لمرحلة التستين. طبعا في كتير شغلات انا رح اعمل skip عليها ان شاء الله لحق اخلصها خلال الفصل بس رح اروح هيلا جنب على الشغلات الاساسية عشان نضبط الماتريال تكون اخدت كل الافكار الاساسية بالمدى طبعا. فهلأ رح نروح لموضوع اللي بيركز بشكل عام اللي بيركز على the quality للكود اللي انت كتبه، احنا بلشنا وشرحنا شق معين يعني انا هلأ اللي بهمني how to improve the quality للكود اللي عنده، Shutterstock اليوم بدي احكي عن موضوع اخر بالتستنج اسمه test-driven development هذا موضوع جدا مهم وموضوع الstatic analysis رح يكون بفيز رقم 2 بالمشروع، خلينا نروح لموضوع test-driven development تقريبا سهل جدا هذا الموضوع قريبا انت عامله بس بطريقة عكسية، مفهوم test-driven development ببساطة كيف تكتب التست كيسز قبل ما تبني اي سطر كود قبل ما تعمل الproduction code طبعا، احنا رح نرجع نستغل الجاي unit نفسها لتطبيق هذا المبدأ اللي هو اسمه test-driven development.

شرحنا ثلاث أنواع من الموديلي بيو كونترولر، وهو الستاندرد الأساسي اللي كان يستخدم للدسكتوب أبليكيشن، بعدين عملوا فيرجن حديث منه للويب، وبعدها بسموها موديلي بيو كونترولر ويب، وبعدها انتقلنا لأحدث إشي اللي هو الـsingle-page-application، اللي هو معظم الفريمويركس اللي تشتغل الـfront-end زي الـreact والـvue.js، هدول بيستخدموا الـprocessing أو الـbusiness logic بصفحة الـclient-side أو بصفحة البراوزر، فبيكون الـapplication حكينا responsive أكتر من الموديلي بيو كونترولر ويب، اللي هو بيشتغل full-stack، بيكون عندك server-side وclient-side، الـprocessing بتكون موجودة عند جهة السيرفر. في كتير الفريمويرك بتدعم هذا الـstyle، الـdjango، الـlaravel، الـ.net-asp، الـspring-boot، هدول كلهم فيريمويركس بيشتغلوا بعدة لغات، يعني الـlaravel-php، الـdjango-python، الـspring-java، هدول كلهم بيشتغلوا على الـstyle الثاني للموديلي بيو كونترولر، اللي اسمه موديلي بيو كونترولر ويب. وعملنا example اسمه الموديلي بيو كونترولر للـsymbol-application بسيط جداً اللي هو الـcounter، وشفنا أنه الـeffort البرمجي اللي الـdeveloper بيعمله أصعب من التطبيق نفسه، فلهيك حكينا أنه الموديلي بيو كونترولر لا يناسب التطبيقات البسيطة، وصمم للـweb-applications اللي فيها complexity عليه. هذا الحكي كله حكينا ويمكن شرحنا الـexample كامل، أعتقد أننا شرحنا هذا الـexample، هذا الـexample بس عشان تعرف أنه الـeffort اللي بتحطه بالـapplication البسيطة في الموديلي بيو كونترولر، رح يكون غير مناسب أنك تستخدم له هاي الـapplications البسيطة، غير مناسب تستخدم من هاي الموديلي بيو كونترولر.

Shutterstock
وبلشنا يمكن أو بدنا نحكي اليوم إن شاء الله تكملة الـstyles الموجودة، شرحنا إحنا جزء من هالـmicro-services أو حتى شرحناها كلها مقارنة مع الـmonolithic-application، طبعاً حكينا الـmonolithic-application كل أجزاء التطبيق العملي أو كل الموديولز اللي بتبنيها، بنعملها aggregation تجميع أو بتنحط في بروسس واحدة على الـoperating-system طبعاً في الـrun-mode، يعني لما تشغل التطبيق العملي جميع أجزاء التطبيق اللي هما عبارة عن موديولز بيكونوا، مجموعة من الموديولز والبكيجز، كلها بنعملها encapsulation، يعني هاد التطبيق كامل بيشتغل في الـrun-time على بروسس واحدة في نظامك التشغيل. بمعنى آخر إنه هاد التطبيق فيه dependency عالي بين الموديولز اللي موجودة عنه، فلو بدنا نيجي نعمل scaling لهاد التطبيق إذا زاد load عليه، فيه عنا خيارين حكينا، فيه خيار الvertical scaling إنك تزيد الresources على الجهاز، وفيه خيار تاني الhorizontal scaling إللي هي تزيد عدد الأجهزة اللي موجودة عنا.

لكن بالنسبة لمشاكل المونولوتو تيك أبليكيشن، بيعاني من مشكلة من ناحية الscalability، ليش؟ لأنه ببساطة هاد التطبيق اللي بيشتغلوا كل الأجزاء الموديولز الموجودة فيه في بروسس واحدة، لو بدي أجي أعمل له scaling horizontally على سبيل المثال، متطرة أجيب جهاز جديد وأنقل كل الموديولز الموجودة بالتطبيق على الجهاز الجديد، يعني لو صار load على موديول رقم 6، زاد عدد المستخدمين عليه، ما بقدر أعمل scaling لموديول 6 في المونولوتو تيك أبليكيشن، لازم أعمل scaling لكل التطبيق العملي اللي موجود على جهاز آخر، وهذا الحكي مش efficient، ليه؟ لأنك إنت عم تستهلك resources زي سيرفرات، عشان بس تعمل scaling لسيرفرات معينة من هذا التطبيق الموجود، فهذا تعتبر من المشاكل الأساسية الموجودة في المونولوتو تيك أبليكيشن. المشكلة الثانية الموجودة في المونولوتو تيك أبليكيشن، إنه عملية releases، اللي هي تحرير نسخ من هذا الابليكيشن بطيئة جداً، ليه؟ لأنهم التيم اللي بيشتغلوا على هذا الابليكيشن، ما عندهم يعني بمعنى آخر ال-permission، إنهم يعملوا release على ال-production side، السبب إنه أي تغيير في أي موديول من هاي الموديولز، لازم يكون جميع الموديولز عارفين عنها. ببساطة اللي بيصير كالتالي، ممكن يكون عدة developer بيشتغلوا في الابليكيشن، افرد إنه developer الرقم اللي بيشتغل على موديول 6 وموديول 4 وموديول 3، على سبيل المثال، it is still in the progress، وباقي الموديول جاهزين، ما فيهم يعملوا release على ال-production side، يعني على السيرفر الرئيسي، لهاي الموديولز الجاهزة، ليه؟ لأنها ممكن هاي الموديولز الجاهزة تكون أي تغيير في موديول 3 أو 6 أو 4 ينعكس عليها، فببساطة ال-releases بطيئة جداً في ال-monolithic application، ليه؟ لأنهم لازم كلهم ينتظروا بعض، لحد ما ينتهوا شميع الموديولز من ال-development، وبعدين ينعمل testing لكل الموديولز مع بعضها، وبعدين ينعمل releases لهم مرة واحدة، فعشان هيك عملية تحرير نسخ من التطبيق العملي بتكون بطيئة.

مقارنة بال-micro service architecture، لو نيجي نقارن ال-monolithic مع ال-micro service architecture، بتتطلع على ال-design، كل الموديولز الموجودة في ال-monolithic application موجودة في بروسس واحدة، على ال-operating system، لكن في ال-micro services، ممكن تكون هذا الموديولز، ك-micro service موجود على بروسس، هذا الموديولز موجود على بروسس، هدول التينين مع بعض موجودين على بروسس ثاني، فهم independent، طبعاً كل شق لحاله في بروسس معينة. يعني نلاحظ ال-micro service، هي عبارة عن بروسس كاملة، موجود فيها module or more than one module في ال-runtime، وكل-micro، ممكن يكون عندك مجموعة من، زي ما حكينا من الموديولز، يعني زي هذا بروسس كامل فيها two modules، كل شق منهم يعتبر-micro service بحد ذاتها، وهدول ال-micro services أو ال-processes independent، يعني هم بيحكوا مع بعض، لكن هم بشكل عام self-contained. فلاحظ هلأ بخيارنا هذا ال-micro service، مقارنة مع ال-monolithic application، ال-scalability فيه عالية، ليه؟ لأنه ببساطة، لو صار عندي load على هاي ال-process، اللي فيها module رقم 5، انت ببساطة بتقدر تعمل فقط عملية migration، أو عملية installation لهاي ال-service لحالها، على جهاز منفصل، تمام؟ فأي وحدة منهم، أو أي-parts أو أي-collection منهم، بيصير عليهم bottleneck، أو يعني ضغط من قبل اليوزر، فيك تمسكه بحد ذاته، لأنه independent عن ال-services الأخرى، وتنقله على سيرفر آخر، مش بالضرورة تعمل عملية installation لكل ال-application، فهيك بتكون ال-scalability في ال-micro services عالية جداً، وهذا إحدى ال-advantages الموجودة في ال-micro service.

الشيء الثاني، ال-advantage الثاني، أنه فيه سرعة في ال-releases، يعني تحرير نسخ منه، مقارنة بال-monolithic أسهل، ليه؟ لأنه ببساطة كل process، إلها address space معينة في ال-operating system، كل process بتشتغل بشكل منفصل، فال-developer بيكون هاي self-contained، خلصت ما إلها علاقة بمدير رقم 2، موجود في process معينة، طبعاً، فمباشرة ال-developer بيقدر يعملها installation، ويعمل release من هاي ال-micro service اللي موجودة، فعندهم القدرة ال-team إنهم، أو أولوية إنهم يروحوا ينزلوا هاي ال-micro services، على ال-production side، يعني على سيرفرات رئيسية وتكون شغالة، فما في داعي إنك كل ال-components تنتظر بعضها، أو كل ال-micro services تنتظر بعضها. الشغلة الثانية كمان من الفوائد لل-micro services، مقارنة بال-monolithic، إنه ممكن يتبرمج كل-micro service على تكنولوجيا معينة، يعني ممكن أمسك هاي ال-micro service، اللي موجودة في مدير رقم 6، وأبرمجها على جزء منها على ال-angular JS، هاي مثلاً على ال-react، هاي على كل، لأنهم independent، فممكن تدعم multi-technologies فيهم. والشغلة كمان المهمة إنه الفيليارز اللي بيصير في التطبيق العملي بارشالي، بمعنى آخر إنه إذا هذا ال-service صار فيها خلل، باقي أجزاء التطبيق بتشتغل بشكل طبيعي، لأنهم أصلاً هدول ال-services كل واحدة كأنها application بحد ذاتها، فهذا الإشي جاي مميز فعلياً بال-micro service architecture.

لكن إذا جيت تحكي شوي عن disadvantages ل-micro service architecture، تلاحظ إنه إدارة عشرات أو مئات processes بتكون شوي صعبة، لأنك إنت بدك تضبط عدة-services في ال-application. الشغلة الثانية ال-communication، أيوة مية في المية حلق، ال-communication ال-performance سيء السبب إنه هدول ال-micro services بيحكوا كتير مع بعض، بيطلبوا requests من بعض، فممكن يعمل لك communication عالي أو latency عن network أو congestion عن network، فبيبطئ لك التطبيق العملي بشكل عام، والمشكلة الثالثة الموجودة عنا إنه ممكن يكون لأنها هاي ال-micro services distributed على عدة-devices أو عدة-servers، فعملية نقل ال-data بين هاي ال-services، كمان ممكن يكون فيه خلل بال-format أو بمعنى آخر.

Getty Images
استكشاف
advantage لهذا الstyle، اللي هو المسج queuing، ببساطة الفولت توليرنس عالي جداً فيه، ليه؟ لأنه إذا صار عندي أي خلل، في النظام، المسجات بتضل preserve، بتضل محفوظة، وين موجودة؟ موجودة في الqueue system، طبعاً، فحتى لو كان السيرفر عندك فيه خلل، أو الclient side، فيه خلل، كل المسجات اللي أرسلها لclient side، بتضل preserve، يعني بتضل محفوظة عندك بالqueue، فعشان هيك من الadvantages تبع، إنه النظام reliable، اللي بنبنع هذا الstyle، بيكون موثوق فيه. الشغل الثاني، النظام scalable، ليه؟ لأنك إذا بده زيد load، على سيرفر واحد، بتقدر تزيد عدد السيرفرات اللي موجودة، والمسج queuing، يعني هذا الاشي اللي بيصير عندك، المسج هاي بيصير تتوزع، كيف لي priority queue، بتقدر تعمل priority queue، وتوزحها عدد سيرفرات موجودة عندك، فهذا الdesign بشكل عام scalable، يعتبر.

هلا، الاشي المهم كمان اللي موجود بهذا الdesign، إنه الcommunication بين الclient والسيرفر، asynchronous، شو يعني asynchronous؟ يعني الclient ما بيهتم، يستنى جواب من السيرفر، بيرمد المسجات، المسجات كلها بتتخزن بالqueue، والسيرفر بيعملها عملية processing براحته، فهذا بيسمح لك بالloosely coupled، بين الclient والسيرفر، هذا بيسمح لك إنه الclient والسيرفر يشتغلوا، بدون ما يعملوا acknowledgement لبعض، بدون ما يعرفوا عن بعض، نهائياً، كل واحد بيشتغل بشكل منفصل، وهذا بيعمل لك كمان time decoupling، يعني هذا بيشتغل بأي وقت بدويا، ببساطة، ما همش ضروري يكون الشيء يعني synchronous، بيشتغلوا بشكل asynchronous مع بعض، لأنه فيه وسيط، الbroker، اللي هي الmessage queuing، اللي بتحفظك كل المسجات، حتى لو صار فيه اختلاف في البودرات، حتى لو صار فيه اختلاف في الtiming، في الapplication هذا، ففيه كتير تطبيقات بتشتغل، بتنبنى على شكل message queuing، وأغلبها distributed applications.

another architecture، يعني ببساطة، فيه كتير تطبيقات تبنى على هذا الdesign، اللي هو الmessage queuing، الآن الdesign اللي بعده، أو الarchitecture هذا، قد شرحنا، بس رح نرجع كمان مرة، اللي هو الobserver pattern، بيشبه مبدأ الobserver pattern، ببساطة، بيسمو publish subscriber pattern، تمام، هذا عملياً هو extension، للmessage queuing، extension لللي قبله، تمام، هذا publish subscriber architecture extension، لهذا الdesign. الآن شوف فكرةه ببساطة، فكرةه ببساطة إنه، لازم يكون عندي publisher، ولازم يكون عندي subscriber، أو speaker وlistener، تمام، لازم يكون هدول الlisteners، مسجنين عند البublisher، بالضبط زي الobserver pattern، بس الفكرة إنه بالوسط، في queue system، تمام، يعني هو إضافة على الqueuing system، أو extension له. بس هون بشكل عام بيحكي لك المسجات، اللي بتكون موجودة بين sender والreceiver، بيسموها event، بس إذا بدك تسميها message queuing the same، مش راح تفرق، تفرق ما، فهو نفس design حرفياً، message queuing in addition، إنه listener أو subscriber، لازم يكون مسجن عند البublisher، فبيكون كيف لي flow في الapplication، أو بالنظام، البublisher بيعمل publishing لmessages، أو events، subscriber بيعمل subscription لهاي الevents، receiver، اللي هو بيعمل receive للnotification، يعني بمعنى آخر مبدأ notification، أو الobserver، بترمس على مستوى إيش؟ على مستوى، كل subscriber، وكل publisher بيكون subsystem بحد ذاته.

يعني نعطي example بسيط هنا، الairline system، نظام الطيران، كيف بيشتغل؟ بيكون عندك، لنفترض sales system، اللي هم المسؤولين المبيعات، أو نظام المبيعات، طبعاً؟ نظام المبيعات بيعمل publishing، لevents معين، طبعاً؟ عندك marketing system، accounting system، mileage system، كل هدول أنظمة في الairline system، هدول sales، لما يعمل publishing، لمجموعة من الevents، لازم يتم عملية notification لجميع هدول الأنظمة الموجودة في الapplication، طبعاً؟ فبنعمل notification، بس هدول كلهم الأنظمة، بيكونوا مسجلين already، عند مين؟ عند البublisher، فببساطة هو بيشبه نظام الobserver، بس على مبدأ أنظمة في التطبيق كامل، فمجموعة من الأنظمة بتكون هي listener، للpublisher، أو لخلينا نحكي اللي بيعمل notification، بيكونوا عاملين registration عندهم، وأي event بيصير عند البublisher، مباشرة بنعمل notification للsubsystems اللي موجودين عندهم، طبعاً؟ فهذا هو النظام اللي احنا بنسميه، طبعاً هدول الevents بتخزنوا داخل queue، عشان إذا صار فيه اختلاف البودرات بين السيستيم الأول، اللي هي sales system على سبيل المثال، والother systems، بتتخزن المعلومات كلها، أو الevents كلها بmessage queuing system، فهو شبيه بالdesign الأول، أو بمعنى آخر extension إلو.

عندنا another type من الarchitecture styles، هي اسمه pipe and filter architecture، الآن المطلوب منك عشان تكون عارف كيف طبيعة الماتريال هاي، على الأغلب بجيب لك نظام، طبعاً؟ ممكن أجي أحكي لك عندي airline system، تفاصيل فيه ثلاثة أنظمة كذا كذا، وعندك sales system، sales system بدو يعمل notification، بكون حكيت لك description، وقالت لك صمم للتطبيق، طبعاً؟ بالرسم هاد، برسم معين، على شكل على سبيل المثال publisher subscriber، فأنت بدك تكون فاهم، أن الpublisher هو اللي بعمل publish لل event، والsubscriber هو اللي بستقبل notification، تمام؟ وبدو يكون مسجل قد في النظام، عشان يقدر يوصلوا أي notification، وترسم للdiagram الكورسبوند إلو، فيعني ضروري تكون عارف الsystem نفسه، الabstract level تبعه كيف بيشتغل، ما أكيد تعرف كل واحد شو الفوائد، أو شو الlimitation اللي علي وشو الadvantage.

الpipe and filter architecture، other types من الarchitectures، موضوعه سهل جداً، تمام؟ التطبيق بيكون عبارة عن مجموعة من الpipes، تمام؟ ومجموعة من الفلاتر، filters، كل filter بيعمل computation معين، تمام؟ ونتيجة هذا الفلتر، بتدخل على الفلتر اللي بعده، عن طريق الpipe اللي موجود، فهاي فكرة الpipe and filter architecture، مجموعة من الفلاتر، بتعمل communication مع بعضها عن طريق الpipes، تمام؟ في كتير تطبيقات عملية بنيت على هذا الdesign، أشهر التطبيقات العملية اليونيكس كومند، احنا لما نكتب على اليونيكس كومند معين، عن طريق الكومند لاين، بالعادي هذا الكومند لاين اللي منكتبه باليونيكس، هذا مثال، تمام؟ بتم ترجمته، يعني العملية البارسينج إلو، بيكون مبدأ البارسينج فيه pipe و filter، ليه؟ لأنه كل أمر بتكتبه، في اليونيكس كومند، عبارة عن فلتر، يعني هون مثلاً list، تاك تعمل ليستة، من الcsv files، وبعدين ترتبها، على سبيل المثال حسب ascending order، أو ترتب الcontents اللي داخلها، it depends على معنى الأمر هذا، تمام؟ وكل سهم هون، شايفينه هذا، هذا pipe، أول إشي بتعمل ليستة، بالملفات، بعدين تدخل ليستة، بتشوف، بتفلترها حسب.

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

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

هلا بشكل عام، شو بتشوف فوائد ولميتيشن في هذا الديزاين؟ أول شغلة، فري إيزي انك تعمل ريوز للديزاين، هاي من الشغلات المهم ليه؟ لأنه تخيل حالك عامل كومبايلر، أو في حدا عامل كومبايلر، وأكيد الليجزيكال أناليسيز ما رح يختلف، وين ما تحطه بأي لغة برمجينة، رح يكون البرنامج اللي بيعمل توكينيزيشن نفسه، طبعاً فهيك تعمل ريوز لأي مقطع بتشوف انه مناسب، ليه لأنه أصلاً التطبيق انبنى بشكل ديكابلينج، يعني منفصل لهاي الفلترات عن بعضها، بس بتستخدم السيربيسز من بعضها، ففيري إيزي تعمل ريوز للابليكيشن. كتير مناسب بالويركي فلو، يعني أي اشي بتلاقي فيه ويركي فلو، هذا فيك ببساطة تروح تبنيه على شكل بايب أنت فلتر. فيري إيزي انك تعمل آدينج لأي بلوك، لأي فلتر سهل جداً، انك تعمل وتضيف تعمله انتجريشن بالسيستم، ممكن يشتغل سيكوانشالي وممكن يشتغل كونكرانتلي، بمعنى آخر زي هذا الديزاين، هذا سيكوانشالي وراء بعض بس هذا كونكرانتلي، لأنه انا ممكن اعمل فورك امشي بهذا الفلو، what the same moment امشي بهذا الفلو، what the same moment امشي بهذا الفلو، فبشتغل على كل مبادئ الفوركينج ديزاين، ليه ببساطة سيكوانشالي او كونكرانتلي.

هلا وين المشكلة في هذا الديزاين؟ المشكلة انه اذا زادت عدد البلوكات او الفلاتر، بزيد الoverhead عالسيستم، بمعنى اخر بيبطئلك التطبيق العملي، طبعاً يعني انت تخيل هذا النظام، كل فلتر بده يعمل processing وparsing، ويبعطه للي بعده انت، لتطلع معك النتيجة كل ما زاد عدد الفلاتر، كل ما زاد الcomputation، كل ما صار overhead على السيستم، كل ما قل الperformance، هاي مشكلة من المشاكل الموجودة. المشكلة التاني طبعاً انا ما بعتبرهم مشكلة هاي، اللي بدي احكي فيها بعتبرها limitation طبعاً، المشكلة التاني في الديزاين انه، اذا كان الفلتر الاول مش على علم بال data format، او يعني بمعنى اخر ما في اتفاق بين الطرفين مع ال data format، رح يصير في عنا خلال في النظام ليه؟ لانه تخيل ال output اللي بيطلع من هذا البلوك عبارة عن json file، واللي بيستقبلوا البلوك التاني او الفلتر التاني عبارة عن xml file اذا اختلف الفورمات ال data طريقة وصف المعلومات بين الاطراف بصير عنا خلال بالنظام. فلازم يكون الطرفين agreed، agreed على ايش على ال data transfer فورمات ال data، اللي بتنتقل من طرف الى طرف اخر، لازم يكون متفق عليه مسبقاً، واقل بصير عنا خلال في عملية transformation، فمعناها انه انا اذا بدي اعمل reusing، لاي مقطع منهم لازم اكون على علم بنوع ال data structure و نوع ال data structure اللي طلع فورمات ال data، عشان اقدر ببساطة اعمل reusing لل component. يعني تخيل معي هذا ال design، بتطلع لك data عشاكل tree، نوع ال data structure اللي طلع فورمات ال data فيه عشاكل tree، وهذا بيستقبل لكها عشاكل linked list، كمان لازم يكون agreement على فورمات ال data وtype ال data structure اللي مستخدم بين الاطراف، طبعاً هاي من اكتر ال limitation اللي ممكن الواحد يشوفها في ال pipe and filter architecture design.

معظم ال machine learning تطبيقات ال machine learning الحالية معظمها بتشتغل على مبدأ pipe and filter، ليه لانه بتاخد ال data من excel sheet من csv file، بتدخلها على اول filter اسمه data cleaning، تنظف ال data، هاي ال data شو بيكون فيها مرات بتكون missing data، مرات بيكون فيها corruption data، مرات بيكون فيها outliers، يعني مرات انت تخيل درجة الحرارة بفلسطين، مثلاً تبها 40، لقيت لك data قيمتها 200، فش درجة حرارة بتوصل 200 سلسيوس عصابين المدالة، فبدك تعمل cleaning لل data تشيل outliers، بعدين بتعمل data engineering، او بيسموها feature engineering، شو feature engineering معناها، مش كل المعلومات ال data بتكون على شكل excel sheet اللي مبترد، في عندك عصابين للمثال، هنعطي مثال بسيط على اسعار مثلاً سعر البيت، ال price لل بيوت، سعر البيت يعتمد على موقعه، يعتمد على كم غرفة موجود فيه، يعتمد على بعده، او يعني قديش هو close من الفacilities، وفيه هون مثلاً اشي يعني feature مش related لل price، هلق فيه مجموعة من المعلومات موجودة، وانا اللي بدي اعمله prediction على سبيل المثال ال price based على input هذي الاربعة والخمسة، بدي اشوف سعر البيت هذي، بس فيه معلومة مش كتير مهمة او مش related لسعر البيت، فهذا الfeature engineering شو معناها، الفeature engineering معناها انه بدي اشوف من هاي الفيتشارز اعمل reduction او اعمل remove للفيتشارز اللي مش مهمة، اعمل reduction او اعمل remove للفيتشارز اللي مش مهمة، لانه اذا بدي استخدم كل ال data ممكن كون حجمها ضخم جداً او الcolumns كلها، فبالتالي ممكن يتأثر على performance الموديل، فمنعمل اشي منسميه feature engineering، بعدين بتروح النتيجة بعد ما تعمل feature engineering لتريننج للموديل، وبعدين بتروح لعملية validation الموديل، وبعدين بتروح للdeployment. فهدول كلهم style بنسميهم او اي machine learning approach بتشتغل على مبدأ اللي هو pipe and filter style، فهاي مجموعة من التطبيقات العملية اللي على الاغلب بتشتغل بهذا المبدأ.

Shutterstock
نيجي لاخر style عندنا اللي هو الbeer to beer architecture، اللي اخدوا نتويرك اكيد سمعوا بهذا اللي هو الbeer to beer او الpoint to point بسموه، هذا الbeer to beer architecture اكتر تطبيقات عملية مبنية عليه البيت تورنت البلوكت شين السكايب هدول التطبيقات العملية اللي بنت على مبدأ الbeer to beer. شو مبدأ الbeer to beer؟ انا رح احكي عن الversion اللي بسموها infrastructure-less، في كتير versions منه، في version قديمة كانت بسموها semi-centralized، بس انا بحكي هلأ عن الversion اللي بسموها mesh، المشة اللي معناها انت بتشبك الاجهزة بعض بعض بدون ما يكون عندك اي هيكلية داخلية infrastructure-less، ملهاش infrastructure معين، بسموها ad-hoc يعني اي حدا بيجي عالشبك بيقدر يشبك ملوش style معين، فبسموها mesh او بسموها ad-hoc او بسموها infrastructure-less، ملهاش structure معين. هلأ شو الفكرة بالموضوع؟ الفكرة بالموضوع انه الclients بيعملوا exchange لل data بشكل لوكالي، تمام، السيرفر يعني انا هون بحكي without وجود سيرفر، لكن ان وجد سيرفر في الdesign تخيل هذا السيرفر، هذا السيرفر بس بيكون عشان security level عشان هدول الclients يسجلوا عندو على اساس انهم جزء من التطبيق for registration، for monitoring للapplication، اللي هو احنا كنا نسميه زمان semi-centralized architecture، لكن هذا distributed architecture بالعادة الclients بيحكوا بشكل مباشر مع بعض، لهيك بتسمع بالskype انه ليش الصوت فيه واضح جدا لانه فعليا الclients بيحكوا بشكل مباشر مع بعض عشان هيك very clear الvoice فيه وهذا decentralized system.

تمام من اهم الفوائد الموجودة في design هذا انه، يعني هذا كتير مستخدم في wireless networks فعليا، من الفوائد الكبيرة انه الاجهزة بتصير تستفيد من computational power والstorage الموجود عند الاجهزة والاخرى في الشبكات. يعني تخيل هدول كومبيوترات او wireless sensors، هدول الwireless sensors مزروعين في بيئة معينة، تمام وبيستقبلوا هدول الsensors بيقرؤوا الenvironment، وبيدهم يعملوا computation based على الenvironment الموجود. فاللي بيصير انه اذا هذا الwireless sensor ما هو جهاز منه، تمام فيه عليه computation power، فيه عليه power معين اذا نفترض بطارية، وعنده storage معين، هو بيعمل computation، هاي الباور عنده صارت down، يعني خلصت البطارية او صارت في low level، الفكرة من الdesign هذا الbeer to beer انه بيقدر يعمل عملية transfer للcomputation للاجهزة الاخرى، عشان يستفيد من الباور والstorage الموجود عند الاجهزة الاخرى فبتصير الاجهزة تتنقل عملية الcomputation بين بعضها. فهاي فائدة الbeer to beer بشكل عام، الاستفادة من الresources الموجود resources المقصود فيها الcomputation power زي البطاريات الstorage الhard disks and so on، عشان تعمل تكمل الcomputation كامل في الشبكة الموجودة. تمام كل node من هاي قد تكون server وقد تكون clients، وكل طبعا لاحظ الresources الموجودة في حدا بعمل consuming، في حدا بزودك بالresources، يعني ممكن هذا يكون جهاز ماعمل computation فممكن يعطي لهذا الجهاز power او يعني يطلب جهاز 13 من جهاز 12 يعمل الcomputation عند node رقم 12 على سبيل المثال ممكن هذا يخزن عند node رقم 12، فبصيروا يستفيدوا من الresources اللي موجودة عندنا وهذا بعمل collaboration في الapplication. زي هيك كتير بيستخدم الbit torrent اللي هو file sharing، عملية الdownload في الfile sharing ليه لانه ببساطة انت لما تيجي تسايب على جهاز ممكن هذا الجهاز تكون resources تبعته storage استهلكت، فممكن تستغل الstorage اللي عند node 8 تخزن عليها وتعمل sharing لهاي الملفات عليها، فهاي ببساطة مبدأ الpeer to peer architecture كتير مستخدم للnetworking، هذا من اكتر الarchitecture style اللي راح تشوفه في موضوع الnetwork بين الاجهزة، يعني اذا طبيعة التطبيق العامل يتبعك networking ببساطة راح تشتغل على هذا.

هاي يا جماعة كل الاجهزة كل الأحوال مبلع يا علي مبلع، بس ما هو شو الفكرة كانوا عشان هيك كنت احكي لك عن الsemi-centralized السيرفر الرئيسي اللي بيكون كل المستخدمين هدول عاملين registration عندهم بهدف حفظ السيكوريتي اللي موجود، هذا الاشي اللي بيسمو add hook network بالعادة بيعاني من مشكلة السيكوريتي بشكل عام، لكن فيه بروتوكولات بتضبط هذا الحكي. هاي جميع الarchitecture styles اللي ممكن انت تستغلها لبناء انواع مختلفة من التطبيقات العملية، starting من الlayered والmodel view controller المخصصين للweb، وانطلاقا باي نوع اخر من التطبيقات العملية زي compiler زي networking system، يعني فيه كتير يعني هون الlayered والmodel حكينا web microservice اذا بدك تبني التطبيق وتستغل فكرة scalability، messaging والpublishing بالعادة كتير بيستخدموها اذا النظام فيه notification من subsystems، الpipe والfilter شوفنا انظمة متخصصة زي الlinux زي الmachine learning زي الcompiler، الpeer to peer متخصص اكتر في التطبيقات الnetworking اللي فيها networking. فهاي معظم الarchitecture styles very common المستخدمة جدا في بناء التطبيقات العملية up to date يعني لحد ايامنا هاي كلها بتستخدم في بناء التطبيقات العملية.

هيك احنا منكون انهينا يا جماعة موضوع الdesign اللي هو الstep رقم 2 اللي هو بيركز على الobject oriented design من خلال الUNL، بيركز على الarchitecture styles، بيركز على الdesign principles الsolid principles، الcoupling الdecoupling الproperties الخاصة في الdesign. الشق اللي بعده اللي هو رح يكون موضوع التستين، يعني we assume اننا جمعنا requirements، we assume عملنا الdesign عملنا الimplementation وهلأ بنروح لمرحلة التستين. طبعا في كتير شغلات انا رح اعمل skip عليها ان شاء الله لحق اخلصها خلال الفصل بس رح اروح هيلا جنب على الشغلات الاساسية عشان نضبط الماتريال تكون اخدت كل الافكار الاساسية بالمدى طبعا. فهلأ رح نروح لموضوع اللي بيركز بشكل عام اللي بيركز على the quality للكود اللي انت كتبه، احنا بلشنا وشرحنا شق معين يعني انا هلأ اللي بهمني how to improve the quality للكود اللي عنده، شرحنا شق وبلشتوا تشتغلوا عليه اللي هو dynamic testing اللي هو عن طريق الunit testing وحكينا في كل لغة من اللغات في الها الفريمورك بالجافا اسمه unit testing.

Shutterstock
اليوم بدي احكي عن موضوع اخر بالتستنج اسمه test-driven development هذا موضوع جدا مهم وموضوع الstatic analysis رح يكون بفيز رقم 2 بالمشروع، طبعا ان شاء الله المحاضرة الجاي رح يكون موضوعنا عشان تقدر تبني المشروع بشكل متكامل هو refactoring هدول مواضيع جدا مهمة طبعا رح نركز عليه بالquality للكود. خلينا نروح لموضوع test-driven development تقريبا سهل جدا هذا الموضوع قريبا انت عامله بس بطريقة عكسية، مفهوم test-driven development ببساطة كيف تكتب التست كيسز قبل ما تبني اي سطر كود قبل ما تعمل الproduction code طبعا، وبمعنى اخر كيف تنتج الproduction code من التست كيسز، احنا رح نرجع نستغل الجاي unit نفسها لتطبيق هذا المبدأ اللي هو اسمه test-driven development. طبعا هون حكينا شوي عن موضوع الdesign اللي هو الsolid principle واتوقع اني هذا السلايد انا كاملا اني شرحته، بدنا نروح لموضوع طبعا هذا كله شرحنا لحد اتوقع 192 هذا اوريدي احنا شرحينه طبعا اللي بدنا نروح عليه موضوع test-driven development هذا احنا ما نلحق نحكي فيه بس ان شاء الله نقدر نوصل.

رح نروح لموضوع اسمه test-driven development بسموه ready-green-yellow style، بسموه test-driven لانه عبارة عن ثلاثة فيزز اساسيين، ليش سموه ready-green-yellow؟ الرد معناها انه test-case fail، الجرين معناها انها test-case pass، والييلو معناها انه كودك بحاجة لاعادة تصنيع طبعا يعني كود.