Forwarded from DevJobs
🚀 المعهد القومي للاتصالات (NTI) يفتح باب التقديم لاستقبال دفعة جديدة من مبادرة "شباب مصر الرقمية – الجاهز للتوظيف" لتأهيل الكفاءات الرقمية لسوق العمل.
✅ برنامج تدريبي مجاني لمدة 4 أشهر يجمع بين التأهيل التقني والتدريب العملي في 6 تخصصات تكنولوجية متقدمة.
✅ شراكات استراتيجية مع أكثر من 90 شركة محلية وعالمية متخصصة.
✅ نسبة توظيف لخريجي الدفعات السابقة تجاوزت 91%.
القاهرة في 29 يونيو 2026
في إطار استراتيجية وزارة الاتصالات وتكنولوجيا المعلومات لبناء القدرات الرقمية، أعلن المعهد القومي للاتصالات عن فتح باب التقديم لدفعة جديدة من المبادرة، والتي تستهدف خريجي الجامعات خلال السنوات الخمس الأخيرة، بهدف إعداد كوادر مؤهلة تمتلك المهارات اللازمة لتلبية احتياجات سوق العمل المحلي والعالمي.
يجمع البرنامج بين التدريب التقني المتخصص، وتنمية المهارات الشخصية واللغوية، والتدريب العملي داخل الشركات، بما يعزز جاهزية المتدربين للالتحاق بوظائف المستقبل.
يشمل البرنامج التدريب في 6 مسارات تكنولوجية متقدمة:
• Network Infrastructure and Enablers
• Cybersecurity
• DevOps Engineering
• Telecom Engineering
• Software Engineering
• Electronics and Embedded Systems
كما توفر المبادرة وسائل انتقال من عدد من النقاط الرئيسية؛ لتيسير مشاركة المتدربين.
📅 آخر موعد للتقديم: 11 يوليو 2026
📅 بداية البرنامج: 25 يوليو 2026
🔗 للتقديم:
https://nti.sci.eg/dey/HireReady.html
📩 للاستفسار:
d4m@nti.sci.eg
✅ برنامج تدريبي مجاني لمدة 4 أشهر يجمع بين التأهيل التقني والتدريب العملي في 6 تخصصات تكنولوجية متقدمة.
✅ شراكات استراتيجية مع أكثر من 90 شركة محلية وعالمية متخصصة.
✅ نسبة توظيف لخريجي الدفعات السابقة تجاوزت 91%.
القاهرة في 29 يونيو 2026
في إطار استراتيجية وزارة الاتصالات وتكنولوجيا المعلومات لبناء القدرات الرقمية، أعلن المعهد القومي للاتصالات عن فتح باب التقديم لدفعة جديدة من المبادرة، والتي تستهدف خريجي الجامعات خلال السنوات الخمس الأخيرة، بهدف إعداد كوادر مؤهلة تمتلك المهارات اللازمة لتلبية احتياجات سوق العمل المحلي والعالمي.
يجمع البرنامج بين التدريب التقني المتخصص، وتنمية المهارات الشخصية واللغوية، والتدريب العملي داخل الشركات، بما يعزز جاهزية المتدربين للالتحاق بوظائف المستقبل.
يشمل البرنامج التدريب في 6 مسارات تكنولوجية متقدمة:
• Network Infrastructure and Enablers
• Cybersecurity
• DevOps Engineering
• Telecom Engineering
• Software Engineering
• Electronics and Embedded Systems
كما توفر المبادرة وسائل انتقال من عدد من النقاط الرئيسية؛ لتيسير مشاركة المتدربين.
📅 آخر موعد للتقديم: 11 يوليو 2026
📅 بداية البرنامج: 25 يوليو 2026
🔗 للتقديم:
https://nti.sci.eg/dey/HireReady.html
📩 للاستفسار:
d4m@nti.sci.eg
❤1
NestJS Full Course for Beginners in 2026 | Build a Production-Ready API 💯
https://youtu.be/Q6NpiIp-6WM
#backend
https://youtu.be/Q6NpiIp-6WM
#backend
YouTube
NestJS Full Course for Beginners in 2026 | Build a Production-Ready API
Express is great for simple APIs, but large teams need the unshakeable structure of NestJS to keep codebases from turning into chaos. In this video, you'll turn your existing backend knowledge into a resume-ready asset by building a production-style Hackathon…
❤2
مصطلحات مهمة في عالم الـ System Design 💯 (١)
.
.
الـ System Design من أكثر المواضيع اللي ممكن تحس إنها كبيرة ومخيفة في البداية.
كل شوية تسمع مصطلحات غريبة زي Load Balancer وSharding وCaching وMessage Queue، ومش عارف إزاي كل المفاهيم دي مرتبطة ببعض.
سواء كان هدفك تحضر لـ System Design Interviews، أو تبني أنظمة تستحمل ملايين المستخدمين، إن شاء الله في السلسلة دي هنشرح 30 مفهوم في عالم الـ System Design بطريقة بسيطة وعملية، والأهم إننا هنربط كل مفهوم باللي بعده، بحيث في النهاية تكون الصورة الكبيرة بقت واضحة.
يلا نبدأ بأول 3 مفاهيم. 🚀
---
1- Client-Server Architecture
خلينا نبدأ بسؤال بسيط.
دلوقتي لو فتحت LinkedIn، أو دخلت على YouTube، أو حتى عملت Search على Google... إيه أول حاجة بتحصل؟
اللي بيحصل إن التطبيق أو المتصفح عندك بيبعت Request لجهاز تاني موجود في مكان ما على الإنترنت، والجهاز ده بنسميه Server. السيرفر يستقبل الطلب، ينفذه، وبعدها يرجعلك Response فيه البيانات اللي طلبتها.
ببساطة، جهازك هو الـ Client لأنه بيطلب الخدمة، والسيرفر هو اللي بيقدمها.
الفكرة دي اسمها Client-Server Architecture، وهي تعتبر الأساس اللي معظم تطبيقات ومواقع الإنترنت مبنية عليه.
لكن هنا يجي سؤال منطقي...
إحنا عرفنا إن فيه Server، لكن جهازك عرف يوصل للسيرفر ده إزاي؟
---
2- IP Address
كل جهاز متصل بالشبكة بيكون له IP Address على الشبكة اللي متصل بها، وممكن يتغير (Dynamic IP) أو يكون ثابت (Static IP).
العنوان ده هو اللي بيميز كل جهاز عن غيره، ومن خلاله الأجهزة تعرف تبعت Requests لبعض.
يعني قبل ما جهازك يبعت أي Request للسيرفر، لازم يكون عارف عنوانه.
لكن هنا ظهرت مشكلة كبيرة...
مستحيل نحفظ IP Address لكل موقع بندخله.
تخيل إن بدل ما تكتب google.com، كل مرة تكتب رقم طويل زي:
142.250.190.78
أكيد محدش هيقدر يحفظ كل الأرقام دي.
طيب إحنا ليه بنكتب أسماء مواقع سهلة، وفي الآخر الطلب بيوصل للمكان الصح؟
---
3- DNS
هنا ييجي دور الـ DNS.
ممكن تعتبره دليل الأسماء على الإنترنت.
زي ما عندك في الموبايل اسم "محمد"، لكن الموبايل في الحقيقة مخزن رقم تليفونه، الـ DNS بيعمل نفس الفكرة.
أنت بتكتب اسم سهل زي google.com، والـ DNS بيعمل Name Resolution (تحويل اسم الدومين إلى IP)، وغالبًا النتيجة بتكون موجودة في DNS Cache، فمش كل مرة بيبحث من الصفر.
بعدها جهازك يعرف يبعت الـ Request للسيرفر الصح.
كل الخطوات دي بتحصل في أجزاء من الثانية، وأنت غالبًا مش بتحس إن فيه حاجة حصلت.
وده واحد من الأسباب اللي بيخلي استخدام الإنترنت سهل بالنسبة لينا، لأننا بنتعامل مع أسماء سهلة بدل أرقام معقدة.
---
💡 الخلاصة
رحلة أي Request على الإنترنت بتبدأ بـ 3 مفاهيم أساسية:
- الـ Client-Server Architecture: جهازك (Client) بيبعت Request، والسيرفر (Server) بينفذه ويرجع Response.
- الـ IP Address: هو العنوان اللي بيميز كل جهاز على الإنترنت، وبدونه الأجهزة مش هتعرف تتواصل مع بعض.
- الـ DNS: بيحوّل أسماء المواقع اللي إحنا بنكتبها إلى IP Address، عشان جهازك يعرف يوصل للسيرفر الصح.
---
دلوقتي عرفنا إزاي الـ Request خرج من جهازك، وإزاي عرف يوصل للسيرفر.
لكن... هل كل Request بيروح للسيرفر مباشرة؟
ولا ممكن يعدي على جهاز تاني في النص قبل ما يوصل؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Proxy، وLatency، وHTTP/HTTPS.
---
#system_design
.
.
الـ System Design من أكثر المواضيع اللي ممكن تحس إنها كبيرة ومخيفة في البداية.
كل شوية تسمع مصطلحات غريبة زي Load Balancer وSharding وCaching وMessage Queue، ومش عارف إزاي كل المفاهيم دي مرتبطة ببعض.
سواء كان هدفك تحضر لـ System Design Interviews، أو تبني أنظمة تستحمل ملايين المستخدمين، إن شاء الله في السلسلة دي هنشرح 30 مفهوم في عالم الـ System Design بطريقة بسيطة وعملية، والأهم إننا هنربط كل مفهوم باللي بعده، بحيث في النهاية تكون الصورة الكبيرة بقت واضحة.
يلا نبدأ بأول 3 مفاهيم. 🚀
---
1- Client-Server Architecture
خلينا نبدأ بسؤال بسيط.
دلوقتي لو فتحت LinkedIn، أو دخلت على YouTube، أو حتى عملت Search على Google... إيه أول حاجة بتحصل؟
اللي بيحصل إن التطبيق أو المتصفح عندك بيبعت Request لجهاز تاني موجود في مكان ما على الإنترنت، والجهاز ده بنسميه Server. السيرفر يستقبل الطلب، ينفذه، وبعدها يرجعلك Response فيه البيانات اللي طلبتها.
ببساطة، جهازك هو الـ Client لأنه بيطلب الخدمة، والسيرفر هو اللي بيقدمها.
الفكرة دي اسمها Client-Server Architecture، وهي تعتبر الأساس اللي معظم تطبيقات ومواقع الإنترنت مبنية عليه.
لكن هنا يجي سؤال منطقي...
إحنا عرفنا إن فيه Server، لكن جهازك عرف يوصل للسيرفر ده إزاي؟
---
2- IP Address
كل جهاز متصل بالشبكة بيكون له IP Address على الشبكة اللي متصل بها، وممكن يتغير (Dynamic IP) أو يكون ثابت (Static IP).
العنوان ده هو اللي بيميز كل جهاز عن غيره، ومن خلاله الأجهزة تعرف تبعت Requests لبعض.
يعني قبل ما جهازك يبعت أي Request للسيرفر، لازم يكون عارف عنوانه.
لكن هنا ظهرت مشكلة كبيرة...
مستحيل نحفظ IP Address لكل موقع بندخله.
تخيل إن بدل ما تكتب google.com، كل مرة تكتب رقم طويل زي:
142.250.190.78
أكيد محدش هيقدر يحفظ كل الأرقام دي.
طيب إحنا ليه بنكتب أسماء مواقع سهلة، وفي الآخر الطلب بيوصل للمكان الصح؟
---
3- DNS
هنا ييجي دور الـ DNS.
ممكن تعتبره دليل الأسماء على الإنترنت.
زي ما عندك في الموبايل اسم "محمد"، لكن الموبايل في الحقيقة مخزن رقم تليفونه، الـ DNS بيعمل نفس الفكرة.
أنت بتكتب اسم سهل زي google.com، والـ DNS بيعمل Name Resolution (تحويل اسم الدومين إلى IP)، وغالبًا النتيجة بتكون موجودة في DNS Cache، فمش كل مرة بيبحث من الصفر.
بعدها جهازك يعرف يبعت الـ Request للسيرفر الصح.
كل الخطوات دي بتحصل في أجزاء من الثانية، وأنت غالبًا مش بتحس إن فيه حاجة حصلت.
وده واحد من الأسباب اللي بيخلي استخدام الإنترنت سهل بالنسبة لينا، لأننا بنتعامل مع أسماء سهلة بدل أرقام معقدة.
---
💡 الخلاصة
رحلة أي Request على الإنترنت بتبدأ بـ 3 مفاهيم أساسية:
- الـ Client-Server Architecture: جهازك (Client) بيبعت Request، والسيرفر (Server) بينفذه ويرجع Response.
- الـ IP Address: هو العنوان اللي بيميز كل جهاز على الإنترنت، وبدونه الأجهزة مش هتعرف تتواصل مع بعض.
- الـ DNS: بيحوّل أسماء المواقع اللي إحنا بنكتبها إلى IP Address، عشان جهازك يعرف يوصل للسيرفر الصح.
---
دلوقتي عرفنا إزاي الـ Request خرج من جهازك، وإزاي عرف يوصل للسيرفر.
لكن... هل كل Request بيروح للسيرفر مباشرة؟
ولا ممكن يعدي على جهاز تاني في النص قبل ما يوصل؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Proxy، وLatency، وHTTP/HTTPS.
---
#system_design
❤13👍1
مصطلحات مهمة في عالم الـ System Design 💯 (٢)
.
.
في البوست اللي فات بدأنا رحلة الـ Request، وتكلمنا عن الـ Client-Server Architecture، وإزاي الـ Client بيبعت الـ Request، ودور الـ DNS في تحويل اسم الموقع إلى IP Address علشان يوصله للسيرفر الصحيح.
لكن هل معنى كده إن كل Request بيروح مباشرة للسيرفر؟
الإجابة في أغلب الأنظمة الكبيرة هي: غالبًا لا.
قبل ما الـ Request يوصل للسيرفر، غالبًا بيعدي على محطة في النص. والمحطة دي ممكن يكون لها أكتر من وظيفة، زي إنها تحمي السيرفر، أو توزع الضغط، أو حتى تسرّع الاستجابة.
وده ياخدنا لأول مفهوم النهارده...
---
4- Proxy
الـ Proxy ببساطة هو وسيط بينك وبين السيرفر.
بدل ما جهازك يتواصل مع السيرفر بشكل مباشر، بيبعت الـ Request للـ Proxy الأول، وهو اللي يتعامل مع السيرفر نيابة عنك.
طب ليه نعمل كده؟
تخيل إنك في شركة، وكل الموظفين اللي فيها بيستخدموا الإنترنت من خلال شبكة الشركة. بدل ما كل جهاز يظهر على الإنترنت مباشرة، كل الطلبات بتعدي على Proxy Server. كده الشركة تقدر تراقب الترافيك، تمنع مواقع معينة، أو حتى تخزن بعض البيانات لتسريع الوصول ليها.
وده مجرد استخدام واحد. فيه استخدامات تانية كتير للـ Proxy حسب نوعه، وهنقابل نوع مهم جدًا قدام وهو Reverse Proxy.
لكن حتى لو فيه Proxy، أو مفيش، يفضل فيه سؤال مهم...
ليه بعض المواقع بتفتح في ثانية، ومواقع تانية بتحس إنها بطيئة؟
---
5- Latency
كتير بنربط بطء الموقع بسرعة الإنترنت، لكن ده مش السبب الوحيد.
فيه حاجة اسمها Latency، وهي الوقت اللي بيستغرقه الـ Request علشان يروح للسيرفر، والـ Response يرجع تاني.
كل ما المسافة بينك وبين السيرفر كانت أكبر، أو كان فيه عدد كبير من الأجهزة في الطريق، أو الشبكة نفسها بطيئة، كل ما الـ Latency تزيد.
عشان كده ممكن يكون عندك إنترنت سريع، لكن موقع معين لسه بيفتح ببطء، لأن المشكلة مش في سرعة التحميل، المشكلة في الوقت اللي البيانات بتستغرقه علشان توصل وترجع.
وده واحد من أكبر التحديات في الـ System Design، لأن تحسين الـ Latency بيأثر بشكل مباشر على تجربة المستخدم.
طيب... بعد ما الـ Request وصل للسيرفر، هو بيتكلم معاه إزاي أصلًا؟
---
6- HTTP / HTTPS
لما شخصين بيتكلموا مع بعض، لازم يكون فيه لغة مشتركة بينهم.
ونفس الفكرة بتحصل بين الـ Client والـ Server.
اللغة أو البروتوكول الأشهر اللي بيتواصلوا بيه هو HTTP.
هو اللي بيحدد شكل الـ Request، وشكل الـ Response، وإزاي البيانات تتبعت وتترجع.
لكن مع الوقت، بقى مهم إن البيانات تكون محمية أثناء انتقالها، خصوصًا لما تبعت Password أو بيانات بطاقة بنكية.
ومن هنا ظهر HTTPS.
هو ببساطة نفس HTTP، لكن مع إضافة طبقة تشفير بتحافظ على البيانات أثناء انتقالها، بحيث لو حد اعترضها، ميقدرش يفهم محتواها.
علشان كده هتلاقي معظم المواقع دلوقتي بتستخدم HTTPS، وهتشوف علامة القفل جنب اسم الموقع في المتصفح.
---
💡 الخلاصة
- الـ Proxy: وسيط بين الـ Client والـ Server، وله استخدامات كتير زي الأمان، والتحكم، وتحسين الأداء.
- الـ Latency: الوقت اللي الـ Request والـ Response بيستغرقوه في الرحلة، وكل ما قل، تجربة المستخدم كانت أفضل.
- الـ HTTP / HTTPS: البروتوكول اللي بيتواصل بيه الـ Client مع الـ Server، وHTTPS بيضيف طبقة تشفير لحماية البيانات.
دلوقتي بقينا عارفين إزاي الـ Client بيتواصل مع الـ Server.
لكن... لما السيرفر يستقبل الـ Request، إزاي بيعرف المطلوب منه؟ وإزاي التطبيقات بتتواصل مع بعضها؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على APIs و REST و GraphQL.
---
#system_design
.
.
في البوست اللي فات بدأنا رحلة الـ Request، وتكلمنا عن الـ Client-Server Architecture، وإزاي الـ Client بيبعت الـ Request، ودور الـ DNS في تحويل اسم الموقع إلى IP Address علشان يوصله للسيرفر الصحيح.
لكن هل معنى كده إن كل Request بيروح مباشرة للسيرفر؟
الإجابة في أغلب الأنظمة الكبيرة هي: غالبًا لا.
قبل ما الـ Request يوصل للسيرفر، غالبًا بيعدي على محطة في النص. والمحطة دي ممكن يكون لها أكتر من وظيفة، زي إنها تحمي السيرفر، أو توزع الضغط، أو حتى تسرّع الاستجابة.
وده ياخدنا لأول مفهوم النهارده...
---
4- Proxy
الـ Proxy ببساطة هو وسيط بينك وبين السيرفر.
بدل ما جهازك يتواصل مع السيرفر بشكل مباشر، بيبعت الـ Request للـ Proxy الأول، وهو اللي يتعامل مع السيرفر نيابة عنك.
طب ليه نعمل كده؟
تخيل إنك في شركة، وكل الموظفين اللي فيها بيستخدموا الإنترنت من خلال شبكة الشركة. بدل ما كل جهاز يظهر على الإنترنت مباشرة، كل الطلبات بتعدي على Proxy Server. كده الشركة تقدر تراقب الترافيك، تمنع مواقع معينة، أو حتى تخزن بعض البيانات لتسريع الوصول ليها.
وده مجرد استخدام واحد. فيه استخدامات تانية كتير للـ Proxy حسب نوعه، وهنقابل نوع مهم جدًا قدام وهو Reverse Proxy.
لكن حتى لو فيه Proxy، أو مفيش، يفضل فيه سؤال مهم...
ليه بعض المواقع بتفتح في ثانية، ومواقع تانية بتحس إنها بطيئة؟
---
5- Latency
كتير بنربط بطء الموقع بسرعة الإنترنت، لكن ده مش السبب الوحيد.
فيه حاجة اسمها Latency، وهي الوقت اللي بيستغرقه الـ Request علشان يروح للسيرفر، والـ Response يرجع تاني.
كل ما المسافة بينك وبين السيرفر كانت أكبر، أو كان فيه عدد كبير من الأجهزة في الطريق، أو الشبكة نفسها بطيئة، كل ما الـ Latency تزيد.
عشان كده ممكن يكون عندك إنترنت سريع، لكن موقع معين لسه بيفتح ببطء، لأن المشكلة مش في سرعة التحميل، المشكلة في الوقت اللي البيانات بتستغرقه علشان توصل وترجع.
وده واحد من أكبر التحديات في الـ System Design، لأن تحسين الـ Latency بيأثر بشكل مباشر على تجربة المستخدم.
طيب... بعد ما الـ Request وصل للسيرفر، هو بيتكلم معاه إزاي أصلًا؟
---
6- HTTP / HTTPS
لما شخصين بيتكلموا مع بعض، لازم يكون فيه لغة مشتركة بينهم.
ونفس الفكرة بتحصل بين الـ Client والـ Server.
اللغة أو البروتوكول الأشهر اللي بيتواصلوا بيه هو HTTP.
هو اللي بيحدد شكل الـ Request، وشكل الـ Response، وإزاي البيانات تتبعت وتترجع.
لكن مع الوقت، بقى مهم إن البيانات تكون محمية أثناء انتقالها، خصوصًا لما تبعت Password أو بيانات بطاقة بنكية.
ومن هنا ظهر HTTPS.
هو ببساطة نفس HTTP، لكن مع إضافة طبقة تشفير بتحافظ على البيانات أثناء انتقالها، بحيث لو حد اعترضها، ميقدرش يفهم محتواها.
علشان كده هتلاقي معظم المواقع دلوقتي بتستخدم HTTPS، وهتشوف علامة القفل جنب اسم الموقع في المتصفح.
---
💡 الخلاصة
- الـ Proxy: وسيط بين الـ Client والـ Server، وله استخدامات كتير زي الأمان، والتحكم، وتحسين الأداء.
- الـ Latency: الوقت اللي الـ Request والـ Response بيستغرقوه في الرحلة، وكل ما قل، تجربة المستخدم كانت أفضل.
- الـ HTTP / HTTPS: البروتوكول اللي بيتواصل بيه الـ Client مع الـ Server، وHTTPS بيضيف طبقة تشفير لحماية البيانات.
دلوقتي بقينا عارفين إزاي الـ Client بيتواصل مع الـ Server.
لكن... لما السيرفر يستقبل الـ Request، إزاي بيعرف المطلوب منه؟ وإزاي التطبيقات بتتواصل مع بعضها؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على APIs و REST و GraphQL.
---
#system_design
❤10
مفهوم الـ End-to-End Test 💯
.
.
خلال رحلتك في عالم البرمجة، ممكن تكون اشتغلت على Feature كبيرة، وكنت متأكد إن الـ code شغال زي الفل. وكتبت Unit Tests، وكل الـ functions بتـرجّع اللي المفروض ترجعه. بعد كده جربت الـ app بإيدك، كل حاجة ماشية حلو… بس لما رفعت الكود على الـ staging أو الـ production، فجأة فيه حاجات وقعت ومش شغاله...
المشكلة هنا إن اللي أنت اختبرته مش كفاية... أنت اختبرت أجزاء صغيرة، لكن معملتش اختبار للرحلة كاملة من أول ما الـ user يفتح الـ app لحد ما يوصل لهدفه.
وهنا بييجي دور الـ End-to-End Testing (E2E)...
———
🎯 يعني إيه End-to-End Test؟
الـ End-to-End Test ببساطة هو نوع من أنواع الـ Testing اللي بيحاكي تصرفات الـ user الحقيقية.
بنختبر الـ system كـ “صندوق أسود” من غير ما نهتم بالتفاصيل الداخلية، إحنا بس عاوزين نتأكد إن الـ app بيشتغل زي ما الـ user متوقع بالضبط، من أول خطوة لآخر خطوة.
يعني بنبدأ من الـ UI، ونتفاعل مع الـ buttons والـ forms والـ links، وبنشوف هل الـ backend بيرد زي ما المفروض؟ هل الـ database اتحدثت؟ هل النتيجة اللي ظهرت للمستخدم منطقية؟
———
📌 إمتى تستخدم الـ E2E؟
- لو بتسلم Feature مهمة جدًا، زي عملية دفع أو تسجيل دخول.
- لو الـ app فيه flows معقدة أو steps كتير وبتعتمد على بعض.
- لو عاوز تتأكد إن الـ integration بين الـ frontend والـ backend شغال تمام.
- وقت الـ release، علشان تطمن إن الـ system ككل شغال سليم من الأول للآخر.
———
🛠 أشهر أدوات الـ End-to-End Testing
- الـ Cypress: سهل، واضح، بيشتغل على المتصفح، وبيخليك تـ debug بسهولة.
- الـ Playwright: سريع وبيدعم browsers كتير، وممتاز للـ automation.
- الـ Selenium: قديم وتقيل شوية، بس لسه ناس بتستخدمه عشان مرن وبيشتغل بلغات مختلفة.
———
⚙️ أمثلة على Scenarios ممكن نعملها E2E Test
- مستخدم بيسجل في الموقع، بيرجعله confirmation message.
- مستخدم بيدخل بيانات كريدت كارد وبتتم عملية الدفع.
- مستخدم بيعمل login وبيتنقل على الـ dashboard.
- مستخدم بيبعت فورم contact us وتوصله رسالة تأكيد.
———
💡 ليه الـ E2E Tests مهمة؟
- بتمنع الـ regressions اللي ممكن تحصل بعد تغييرات كبيرة.
- بتكشف bugs مش ممكن تكتشفها بالـ Unit أو الـ Integration tests.
- بتديك confidence إن الـ system ككل شغال زي ما المفروض.
- بتساعد الفريق كله (frontend, backend, QA) يكونوا مطمنين قبل أي release.
———
⚠️ بس خلي بالك...
الـ E2E Tests تقيلة في الـ execution، وبطيئة مقارنةً بالأنواع التانية.
فعشان كده بنكتب منها بس الـ critical flows، مش كل حاجة.
كمان أي تغيير بسيط في UI ممكن يكسرها… فلازم تكتبها بشكل كويس وقابل للصيانة.
———
💡 نصائح لو هتبدأ تكتب E2E Tests:
- ابني test لكل user journey مهمة.
- حاول تعزل الـ data اللي بتستخدمه في التست (استخدم mocks أو test accounts).
- حافظ على naming واضح وسهل في الـ tests.
- شغّلها في CI/CD pipeline عشان تمسك المشاكل قبل ما توصل للناس.
———
الـ E2E Testing هو خط الدفاع الأخير، اللي بيأكد إن كل حاجة ماشية تمام من منظور المستخدم.
وكمان هو اللي بيخليك ضامن إن الـ feature اللي تعبت فيها مش هتبوظ لما تطلع production.
———
#software_development
.
.
خلال رحلتك في عالم البرمجة، ممكن تكون اشتغلت على Feature كبيرة، وكنت متأكد إن الـ code شغال زي الفل. وكتبت Unit Tests، وكل الـ functions بتـرجّع اللي المفروض ترجعه. بعد كده جربت الـ app بإيدك، كل حاجة ماشية حلو… بس لما رفعت الكود على الـ staging أو الـ production، فجأة فيه حاجات وقعت ومش شغاله...
المشكلة هنا إن اللي أنت اختبرته مش كفاية... أنت اختبرت أجزاء صغيرة، لكن معملتش اختبار للرحلة كاملة من أول ما الـ user يفتح الـ app لحد ما يوصل لهدفه.
وهنا بييجي دور الـ End-to-End Testing (E2E)...
———
🎯 يعني إيه End-to-End Test؟
الـ End-to-End Test ببساطة هو نوع من أنواع الـ Testing اللي بيحاكي تصرفات الـ user الحقيقية.
بنختبر الـ system كـ “صندوق أسود” من غير ما نهتم بالتفاصيل الداخلية، إحنا بس عاوزين نتأكد إن الـ app بيشتغل زي ما الـ user متوقع بالضبط، من أول خطوة لآخر خطوة.
يعني بنبدأ من الـ UI، ونتفاعل مع الـ buttons والـ forms والـ links، وبنشوف هل الـ backend بيرد زي ما المفروض؟ هل الـ database اتحدثت؟ هل النتيجة اللي ظهرت للمستخدم منطقية؟
———
📌 إمتى تستخدم الـ E2E؟
- لو بتسلم Feature مهمة جدًا، زي عملية دفع أو تسجيل دخول.
- لو الـ app فيه flows معقدة أو steps كتير وبتعتمد على بعض.
- لو عاوز تتأكد إن الـ integration بين الـ frontend والـ backend شغال تمام.
- وقت الـ release، علشان تطمن إن الـ system ككل شغال سليم من الأول للآخر.
———
🛠 أشهر أدوات الـ End-to-End Testing
- الـ Cypress: سهل، واضح، بيشتغل على المتصفح، وبيخليك تـ debug بسهولة.
- الـ Playwright: سريع وبيدعم browsers كتير، وممتاز للـ automation.
- الـ Selenium: قديم وتقيل شوية، بس لسه ناس بتستخدمه عشان مرن وبيشتغل بلغات مختلفة.
———
⚙️ أمثلة على Scenarios ممكن نعملها E2E Test
- مستخدم بيسجل في الموقع، بيرجعله confirmation message.
- مستخدم بيدخل بيانات كريدت كارد وبتتم عملية الدفع.
- مستخدم بيعمل login وبيتنقل على الـ dashboard.
- مستخدم بيبعت فورم contact us وتوصله رسالة تأكيد.
———
💡 ليه الـ E2E Tests مهمة؟
- بتمنع الـ regressions اللي ممكن تحصل بعد تغييرات كبيرة.
- بتكشف bugs مش ممكن تكتشفها بالـ Unit أو الـ Integration tests.
- بتديك confidence إن الـ system ككل شغال زي ما المفروض.
- بتساعد الفريق كله (frontend, backend, QA) يكونوا مطمنين قبل أي release.
———
⚠️ بس خلي بالك...
الـ E2E Tests تقيلة في الـ execution، وبطيئة مقارنةً بالأنواع التانية.
فعشان كده بنكتب منها بس الـ critical flows، مش كل حاجة.
كمان أي تغيير بسيط في UI ممكن يكسرها… فلازم تكتبها بشكل كويس وقابل للصيانة.
———
💡 نصائح لو هتبدأ تكتب E2E Tests:
- ابني test لكل user journey مهمة.
- حاول تعزل الـ data اللي بتستخدمه في التست (استخدم mocks أو test accounts).
- حافظ على naming واضح وسهل في الـ tests.
- شغّلها في CI/CD pipeline عشان تمسك المشاكل قبل ما توصل للناس.
———
الـ E2E Testing هو خط الدفاع الأخير، اللي بيأكد إن كل حاجة ماشية تمام من منظور المستخدم.
وكمان هو اللي بيخليك ضامن إن الـ feature اللي تعبت فيها مش هتبوظ لما تطلع production.
———
#software_development
❤6
مصطلحات مهمة في عالم الـ System Design 💯 (٣)
.
.
في البوست اللي فات عرفنا إن الـ Client بعت الـ Request، والـ Server استقبله، وتكلموا مع بعض باستخدام HTTP/HTTPS.
لكن بمجرد ما الـ Request يوصل للسيرفر، ييجي سؤال مهم...
إزاي السيرفر يعرف المطلوب منه؟
يعني لما تضغط على زرار Login، أو تعمل Search، أو تفتح قائمة المنتجات... إيه اللي بيخلي كل Request يروح للمكان الصح؟
الإجابة هي إن كل وظيفة في التطبيق بيكون لها API.
———
📌 API
الـ API اختصار لـ Application Programming Interface.
الاسم ممكن يخض شوية، لكن الفكرة أبسط من كده بكتير.
تخيل إنك في مطعم.
أنت مش بتدخل المطبخ بنفسك علشان تطلب الأكل، فيه ويتر بياخد منك الطلب، يوصله للمطبخ، وبعدها يرجعلك بالأكل.
الويتر ده هو الـ API.
هو الوسيط بين الـ Client والـ Server.
الـ Client يبعت Request، والـ API يستقبله، يوصله للجزء المناسب في السيرفر، وبعدها يرجع Response.
علشان كده لما تسمع حد بيقول:
"اعمل API للـ Login"
فهو يقصد نقطة دخول يقدر الـ Client يبعتلها بيانات تسجيل الدخول، والسيرفر يتعامل معاها ويرجع النتيجة.
لكن...
هل كل الـ APIs بتشتغل بنفس الطريقة؟
الإجابة لا.
وأشهر طريقة موجودة حاليًا اسمها REST.
———
📌 REST
الـ REST مش لغة برمجة، ولا Framework.
ولكن هي مجموعة قواعد بتنظم شكل الـ APIs.
يعني بدل ما كل Backend Developer يخترع طريقة مختلفة، بقى فيه أسلوب متفق عليه يخلي أي Developer يفهم الـ API بسهولة.
مثلًا...
لو عايز تجيب كل المنتجات، غالبًا هتلاقي Endpoint زي:
ولو عايز تضيف منتج جديد:
ولو عايز تعدل منتج:
الفكرة إن كل حاجة بقت ماشية بنمط معروف.
وده السبب إن أغلب الـ APIs اللي بنتعامل معاها النهارده هي REST APIs.
لكن مع الوقت، بدأت تظهر مشكلة.
أوقات الـ Client بيحتاج جزء صغير من البيانات، والسيرفر يرجع بيانات أكتر بكتير من اللي محتاجها.
وأوقات تانية يحتاج بيانات من أكتر من API علشان يقدر يعرض شاشة واحدة.
ومن هنا ظهر مفهوم جديد.
———
📌 GraphQL
الـ GraphQL جه يحل المشكلة دي.
بدل ما السيرفر يقرر إيه البيانات اللي هترجع، الـ Client هو اللي يحدد بالضبط هو محتاج إيه.
يعني لو شاشة فيها اسم المستخدم وصورته بس.
مش لازم السيرفر يرجع الإيميل، ورقم التليفون، والعنوان، وتاريخ الميلاد، وباقي البيانات.
الـ Client يطلب الاسم والصورة فقط.
والسيرفر يرجع الاسم والصورة فقط.
وده بيقلل حجم البيانات اللي بتتنقل، وبيخلي بعض الشاشات أسرع، خصوصًا في التطبيقات الكبيرة.
لكن ده مش معناه إن GraphQL أحسن من REST في كل الحالات.
كل واحد له استخداماته، واختيار واحد منهم بيعتمد على طبيعة النظام اللي بتبنيه.
———
💡 الخلاصة
النهارده عرفنا إزاي السيرفر بيفهم المطلوب منه.
- الـ API: هي نقطة التواصل بين الـ Client والـ Server، وكل Feature في التطبيق غالبًا بيكون لها API.
- الـ REST: أسلوب شائع لبناء الـ APIs باستخدام قواعد وأنماط متفق عليها.
- الـ GraphQL: بيدي الـ Client حرية يحدد البيانات اللي محتاجها بالظبط، بدل ما يستقبل بيانات زيادة.
دلوقتي بقينا عارفين إزاي الـ Client يطلب البيانات من السيرفر.
لكن... السيرفر بيجيب البيانات دي منين أصلًا؟
وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Databases، وSQL vs NoSQL، وVertical Scaling.
———
#system_design
.
.
في البوست اللي فات عرفنا إن الـ Client بعت الـ Request، والـ Server استقبله، وتكلموا مع بعض باستخدام HTTP/HTTPS.
لكن بمجرد ما الـ Request يوصل للسيرفر، ييجي سؤال مهم...
إزاي السيرفر يعرف المطلوب منه؟
يعني لما تضغط على زرار Login، أو تعمل Search، أو تفتح قائمة المنتجات... إيه اللي بيخلي كل Request يروح للمكان الصح؟
الإجابة هي إن كل وظيفة في التطبيق بيكون لها API.
———
📌 API
الـ API اختصار لـ Application Programming Interface.
الاسم ممكن يخض شوية، لكن الفكرة أبسط من كده بكتير.
تخيل إنك في مطعم.
أنت مش بتدخل المطبخ بنفسك علشان تطلب الأكل، فيه ويتر بياخد منك الطلب، يوصله للمطبخ، وبعدها يرجعلك بالأكل.
الويتر ده هو الـ API.
هو الوسيط بين الـ Client والـ Server.
الـ Client يبعت Request، والـ API يستقبله، يوصله للجزء المناسب في السيرفر، وبعدها يرجع Response.
علشان كده لما تسمع حد بيقول:
"اعمل API للـ Login"
فهو يقصد نقطة دخول يقدر الـ Client يبعتلها بيانات تسجيل الدخول، والسيرفر يتعامل معاها ويرجع النتيجة.
لكن...
هل كل الـ APIs بتشتغل بنفس الطريقة؟
الإجابة لا.
وأشهر طريقة موجودة حاليًا اسمها REST.
———
📌 REST
الـ REST مش لغة برمجة، ولا Framework.
ولكن هي مجموعة قواعد بتنظم شكل الـ APIs.
يعني بدل ما كل Backend Developer يخترع طريقة مختلفة، بقى فيه أسلوب متفق عليه يخلي أي Developer يفهم الـ API بسهولة.
مثلًا...
لو عايز تجيب كل المنتجات، غالبًا هتلاقي Endpoint زي:
GET /productsولو عايز تضيف منتج جديد:
POST /productsولو عايز تعدل منتج:
PUT /products/1الفكرة إن كل حاجة بقت ماشية بنمط معروف.
وده السبب إن أغلب الـ APIs اللي بنتعامل معاها النهارده هي REST APIs.
لكن مع الوقت، بدأت تظهر مشكلة.
أوقات الـ Client بيحتاج جزء صغير من البيانات، والسيرفر يرجع بيانات أكتر بكتير من اللي محتاجها.
وأوقات تانية يحتاج بيانات من أكتر من API علشان يقدر يعرض شاشة واحدة.
ومن هنا ظهر مفهوم جديد.
———
📌 GraphQL
الـ GraphQL جه يحل المشكلة دي.
بدل ما السيرفر يقرر إيه البيانات اللي هترجع، الـ Client هو اللي يحدد بالضبط هو محتاج إيه.
يعني لو شاشة فيها اسم المستخدم وصورته بس.
مش لازم السيرفر يرجع الإيميل، ورقم التليفون، والعنوان، وتاريخ الميلاد، وباقي البيانات.
الـ Client يطلب الاسم والصورة فقط.
والسيرفر يرجع الاسم والصورة فقط.
وده بيقلل حجم البيانات اللي بتتنقل، وبيخلي بعض الشاشات أسرع، خصوصًا في التطبيقات الكبيرة.
لكن ده مش معناه إن GraphQL أحسن من REST في كل الحالات.
كل واحد له استخداماته، واختيار واحد منهم بيعتمد على طبيعة النظام اللي بتبنيه.
———
💡 الخلاصة
النهارده عرفنا إزاي السيرفر بيفهم المطلوب منه.
- الـ API: هي نقطة التواصل بين الـ Client والـ Server، وكل Feature في التطبيق غالبًا بيكون لها API.
- الـ REST: أسلوب شائع لبناء الـ APIs باستخدام قواعد وأنماط متفق عليها.
- الـ GraphQL: بيدي الـ Client حرية يحدد البيانات اللي محتاجها بالظبط، بدل ما يستقبل بيانات زيادة.
دلوقتي بقينا عارفين إزاي الـ Client يطلب البيانات من السيرفر.
لكن... السيرفر بيجيب البيانات دي منين أصلًا؟
وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Databases، وSQL vs NoSQL، وVertical Scaling.
———
#system_design
❤6