DevGuide

مفهوم الـ 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.

مصطلحات مهمة في عالم الـ 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

مصطلحات لازم تكون عارفها في عالم الـ 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

Introducing Claude Sonnet 5 https://www.anthropic.com/news/claude-sonnet-5

NestJS Full Course for Beginners in 2026 | Build a Production-Ready API 💯 https://youtu.be/Q6NpiIp-6WM

🚀 المعهد القومي للاتصالات (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

DSA was HARD until I Learned these 20 Patterns 💯 https://blog.algomaster.io/p/20-dsa-patterns

دردشة سريعة عن مفهوم Non-blocking I/O 💯 . . "الـ Node.js سريعة عشان بتستخدم الـ Non-blocking I/O" لكن عمرك سألت نفسك: "إزاي الـ Node.js بتتعامل مع requests كثيرة جدًا في نفس الوقت من غير ما السيرفر ينهار أو يبقى بطيء؟" ——— 📌 الأول.. يعني إيه I/O؟ كلمة I/O معناها Input/Output، يعني أي عملية بيحصل فيها إدخال أو إخراج بيانات. زي مثلًا: - تقرأ ملف من الهارد - تبعت request لـ database - تجيب data من API خارجي العمليات دي بتاخد وقت. ممكن ثواني، وممكن ملي ثانية، بس في عالم الـ servers، كل ملي ثانية بتفرق جدًا. ——— 📌 الفرق بين Blocking و Non-blocking: خلينا نبدأ بمثال بسيط جدًا: - الـ Blocking I/O: تخيل إنك قاعد في طابور في السوبر ماركت، وكل واحد لازم يخلص حسابه بالكامل قبل ما الشخص اللي بعده يبدأ. يعني لو فيه حد بيشتري حاجات كتير أو حصلت مشكلة، كل الناس اللي وراه لازم تستنى. ده بالضبط اللي بيحصل في الـ Blocking I/O. البرنامج بيبقى مستني العملية تخلص بالكامل قبل ما يكمل باقي الكود. وده معناه إنك لو عندك ألف request، والسيرفر واقف مستني database ترد، الباقي كله متعطل. ——— - الـ Non-blocking I/O: دلوقتي تخيل نفس الطابور، بس فيه نظام ticket. كل واحد بياخد رقم، ولما ييجي دوره يتنده عليه. وفي الوقت اللي هو منتظر فيه، الكاشير بيخدم ناس تانية. ده بقى مثال لـ Non-blocking I/O. البرنامج بيقول: "هبعت request للـ database، ولغاية ما ترد هكمل شغلي عادي." ——— 🤔 طب إيه علاقة الكلام ده بـ Node.js؟ الـ Node.js مبنية على مفهوم الـ Non-blocking I/O. وده معناه إنك تقدر تتعامل مع آلاف الـ requests في نفس الوقت من غير ما تعمل multi-threading أو create new threads لكل request زي لغات تانية (زي Java أو PHP). الـ Node.js بتشتغل على event loop واحد، وبتعتمد على فكرة اسمها callback أو promises أو async/await علشان تتعامل مع العمليات اللي بتاخد وقت، زي القراءة من database أو الملفات. ——— 📌 مثال بسيط:

const fs = require("fs");

fs.readFile("data.txt", "utf8", (err, data) => {
  if (err) throw err;
  console.log(data);
});

console.log("File is being read...");

في الكود ده، الـ Node.js مش بتوقف البرنامج علشان تقرأ الملف. هي بتبعت request للـ OS علشان يقرأ الملف، وتكمل السطر اللي بعده عادي، ولما الملف يخلص، بتشغل الـ callback. ——— 📌 ليه Non-blocking I/O مهم؟ -  أداء أعلى: السيرفر يقدر يتعامل مع عدد كبير من المستخدمين في نفس الوقت. -  أسرع في المعالجة: مفيش وقت ضايع في الانتظار. -  أرخص في البنية التحتية: مش محتاجين سيرفرات ضخمة أو Threads كتير. ——— لما تستخدم الـ Non-blocking I/O، لازم تكون فاهم إن الكود بتاعك ممكن يبقى معقد لو مش ماشي بأسلوب منظم. مثلًا: - الـ Callback Hell لو مش منظم الكود. - الـ Race conditions لو حاجتين بيتعاملوا مع نفس الـ data. - الـ debugging يبقى أصعب لأن الكود مش linear. لكن مع async/await وPromise-based APIs، بقى الموضوع سهل جدًا في Node.js.

لو عندك سؤال في البرمجة، تقدر تبعته من خلال منصة قبيلة 💯 https://qabilah.com/profile/alisamir

لو عندك سؤال في البرمجة، تقدر تبعته من خلال منصة قبيلة 💯 https://qabilah.com/profile/alisamir

دردشة سريعة عن مفهوم الـ Middleware في Express.js ⚡️ . . لو بتشتغل بـ Node.js وبدأت تستخدم Express.js، أكيد قابلت مصطلح الـ "Middleware" في الكود... وممكن تكون عديت عليه من غير ما تفهم هو بيعمل إيه بالضبط... تعال ندردش شوية عن إزاي الـ Middleware بيشتغل؟ وليه هو أهم جزء تقريبًا في أي تطبيق مبني بـ Express؟ ——— 📌 تعال نبدأ من الآخر: الـ Express.js عبارة عن مجموعة Middleware functions ماشية في خط واحد... يعني الـ Request بيدخل للسيرفر، بيعدي على سلسلة Middleware functions ورا بعض، وكل واحدة فيهم تقدر: - تعدل الـ Request أو الـ Response - توقف الـ flow - تكمل للـ Middleware اللي بعده - أو حتى ترجع Response للـ Client وتقفل الموضوع خالص ——— 📌 يعني إيه Middleware؟ هو function بتستقبل 3 arguments: (req, res, next) - الـ req: الـ request اللي جاي من الـ client - الـ res: الـ response اللي هيرجع للـ client - الـ next: ودي function بتستخدمها علشان تنتقل للـ middleware اللي بعده ——— 📌 إيه اللي هيحصل لو next مش موجودة؟ الـ request هيقف عند الـ middleware ده، والـ Express مش هيكمل لباقي الـ handlers، وهيفضل الـ client مستني response مش هيوصل أبدًا... ——— 📌 أنواع الـ Middleware في Express: 1- الـ Application-level middleware - بيتكتب بـ app.use أو app.get أو app.post... إلخ - بيتطبق على كل أو بعض الـ routes 2- الـ Router-level middleware - شبه الـ application-level بس بيتطبق داخل الـ Router بس - مفيد لما يكون عندك routes كتير متقسمة 3- الـ Error-handling middleware ده لازم يبقى له 4 arguments: (err, req, res, next) بيستخدم لما يكون فيه Error وعايز تتعامل معاه بطريقة أفضل 4- الـ Built-in middleware - زي express.json أو express.static - الـ Express بيقدمه جاهز تقدر تستخدمه على طول 5- الـ Third-party middleware - زي morgan, cors, helmet, body-parser... - بتسطبه بـ npm وتستخدمه علشان تضيف مميزات معينة ——— 📌 الـ Request بيعدي إزاي؟ تخيل الموضوع كأنه خط إنتاج، وكل Middleware واقف على محطة بيشتغل شغلته: Client Request ⬇️ [ Logger Middleware ] ⬇️ [ Authentication Middleware ] ⬇️ [ Validation Middleware ] ⬇️ [ Actual Route Handler ] ⬇️ Server Response لو أي Middleware في النص قرر إنه يرجع Response بنفسه، خلاص السكة بتقف ومحدش بعده هيشتغل. ——— 📌 الـ Use-cases المشهورة للـ Middleware: - الـ Logging كل الـ requests - التحقق من صلاحيات المستخدم (Authentication/Authorization) - التعامل مع الـ Errors - الـ Parsing الـ body - الـ Setting custom headers - الـ Rate limiting