IEEE CS Zagazig Student Chapter

IEEE CS Zagazig Student Chapter IEEE Computer Society Zagazig Student Branch Chapter

كنت بتشتري قبل كدة حاجة من Amazon وجيت عند خطوة الدفع ولقيتها مش شغالة؟ ال application كله شغال بس فيه جزء منه حصله مشكل...
31/07/2026

كنت بتشتري قبل كدة حاجة من Amazon وجيت عند خطوة الدفع ولقيتها مش شغالة؟ ال application كله شغال بس فيه جزء منه حصله مشكلة من غير ما باقي ال application يتأثر، بس ازاي؟

الطريقة الأكثر شهرة في بناء المشاريع الصغيرة والمتوسطة هي ال Monolithic Architecture، المشروع كله في codebase واحد محطوط جوا GitHub Repository مثلاً. سهل في التواصل بين أجزاء المشروع، بسيط في ال deployment ولكن مشاكله كتيرة، قراءة ملفات المشروع بتكون أصعب كل ما المشروع يكبر، لو حصل failure في جزء معين ال application كله هيقع لحد ما المشكلة تتحل، أي تعديل ولو بسيط بيحتاج أنك تعمل test لباقي الأجزاء عشان تتأكد ان التعديل مأثرش على أي جزء تاني، ال deployment هياخد وقت طويل ومكلف ومستهلك لل resources لأن أي تعديل بيحتاج انك تعمل re-deploy لل application كله.

ومن هنا جت فكرة الـ Microservices Architecture، بكل بساطة هنقسم ال application بتاعنا ل services وكل service هتكون مستقلة عشان نحقق مبدأ ال Separation of Concerns، بمعنى ان كل service مخصصة ل job واحدة بس، نقدر نستخدم tech stack مختلف لكل service ودي حاجة صعب جدا انها تتنفذ في ال Monolithic Architecture ومن هنا نقدر ناخد نقاط القوة الخاصة بكل tech stack عشان نستخدمها في الـ service المناسبة ليها.

عشان نقدر نخلي ال services تكلم بعضها فيه طرق كتيرة أبسطها نستخدم API Calls تعمل HTTP Requests تقدر تبعت وتستقبل ال data من وإلى باقي ال services، الطرق دي بتكون بطيئة لأنها معتمدة على ال network على عكس ال Monolith اللي بتستخدم ال Memory ف بتكون أسرع بكتير.

كدة ال application بقى scalable، محتاجين نعمل feature جديدة؟ نعمل service عشان تقدم ال feature دي من غير أي تأثير على الشغل القديم، بعد ما نخلص ال development نعمل test لل service لو تمام نعمل deploy لل service دي بس ومن هنا ممكن نلاقي كل service ب version مختلف زي كدة:
Shopping-Cart:V3.2
Payment:V4.1
Reviews:V1.0
على عكس ال Monolithic Architecture اللي هيكون version لل application كله من غير ما يكون واضح التغيير حصل فين.

عشان نقدر نجمع ال Services دي في GitHub مثلا قدامنا طريقتين:
1- Monorepo:
هنعمل Repository واحدة نجمع فيها كل ال Services، ميزتها ان لو فيه كود بيتكرر كتير زي Validation Logic، سهل نقدر نستخدمه في كذا Service بس لو المشروع كبير لدرجة ان ممكن يكون فيه اكتر من تيم شغال على Service واحدة بس فصعب بعدد ال Developers الكبير ده يشتغلوا على كل ال Services دي في نفس ال Repository

2- Polyrepo:
الطريقة دي بتخلينا نعمل Repository لكل Service، نقدر نشغل عدد كبير من ال Developers على نفس ال Service من غير Conflicts كتيرة، لو فيه كود بيتكرر بين ال Services فالموضوع هيكون أصعب شوية، هنحتاج نعمله في package مثلا وبعدها تقدر باقي ال Services تستخدمه وكل تحديث هيحتاج build جديد لل package دي

وفي النهاية مفيش Architecture احسن من التاني في كل حاجة ولكن هي Trade-offs على حسب مشروعك محتاج ايه، هل مشروع صغير فهنستخدم Monolith؟ ولا المشروع ضخم وناويين يبقى Scalable فنستخدم Microservices؟






عمرك فكرت ايه اللي بيحصل جوا الـ Browser؟ أو ايه المشاكل اللي بتحصل و احنا مش شايفينها؟ده اللي هنعرفه مع مراحل الـ Rende...
26/07/2026

عمرك فكرت ايه اللي بيحصل جوا الـ Browser؟ أو ايه المشاكل اللي بتحصل و احنا مش شايفينها؟
ده اللي هنعرفه مع مراحل الـ Rendering Pipeline و ازاي بتبوظ الـ Animation

كتير مننا بيكتب كود CSS و JavaScript ويلاقي الـ Animation بيقطع أو الصفحة بتعمل Jank، و نقعد ندور في الكود و احنا مش عارفين ايه اللي بيحصل جوا الـ Browser اصلا

علشان تحل أي مشكلة performance لازم تفهم الـ browser بيمشي ازاي ورا الكود بتاعك في Browser Rendering Pipeline.

فتعالوا نحكي عن المراحل اللي بنعدي عليها من اول ما الكود بيوصل لحد ما يظهر قدامنا:

اول مرحلة هتكون الـ Decoding و الـ basics: اول ما الـ browser ياخد ملفاتك مبيشوفش صفحة Web قدامه هو بيشوف نصوص عادية، و من هنا بيجي دور الـ parsing، يبدأ يمسك الـ HTML ويبني شجرة الـ DOM عشان يفهم هيكل الصفحة، و في نفس الوقت يمسك الـ CSS ويبني شجرة الـ CSSOM عشان يفهم التنسيق، و ده بينقلنا للمرحلة اللي بعد كدا.

و هي مرحلة الترتيب و الحسابات: اول ما الـ browser يجمع الشجرتين اللي عملناهم، بيبدأ ياخد النتيجة ويدخل علي الـ Style & Layout، ويحسب كل عنصر مكانه فين بالظبط ومساحته قد ايه، وعلشان كدا المرحلة دي تعتبر القلب بتاعنا لو غيرنا فيه حاجه غلط الـ browser هيتعب جدا.

ندخل بقى على مرحلة التلوين و التركيب: بعد ما عرفنا اماكن كل element ، يجي دور الـ paint علشان نلون العناصر دي علي هيئة layers، و ده بينقلنا للخطوة الاخيرة وهي الـ composite و اللي فيها الـ browser بيركب كل الـ layers فوق بعضها زي الـ puzzle ويظهرها على الشاشة قدام الـ user.

بعد ما خلصنا المراحل بتاعتنا ندخل على الجزء الاهم، ليه الـ Animation بيقطع؟
الحكاية كلها بتتلخص في أنت بتتعامل مع أنهي مرحلة من المراحل اللي اتكلمنا عليها، يعني لو جيت تحرك element في الـ Animation ب top أو left أو width، انت كدا بتجبر الـ browser يرجع لورا ويعيد حسابات الـ layout و الـ paint من أول وجديد مع كل frame بيتحركه العنصر، وده اللي بيحرق الـ CPU وبيخلي الـ Animation يعمل Jank.

لكن لو استخدمت transform و opacity، الـ browser بيتخطى كل الدوشة دي وبيدخل على مرحلة الـ composite علي طول بمساعدة الـ GPU، و بكدا الـ Animation هيطلع بسرعة و Smooth جدا.

وبما أن الـ User Experience تهمنا جدا فلازم نحسن ال Performance بتاع ال Website وميكونش فيه أي تقطيع أو Lag يقابلوا ال User.






عمرك سألت نفسك ليه تطبيقات زي Instagram أو Facebook لسه بتعرضلك آخر المنشورات أو الرسائل حتى لو النت فصل؟ أغلب الناس ممك...
21/07/2026

عمرك سألت نفسك ليه تطبيقات زي Instagram أو Facebook لسه بتعرضلك آخر المنشورات أو الرسائل حتى لو النت فصل؟

أغلب الناس ممكن تقول ان التطبيق افتكر آخر حاجة شافها وخلاص، لكن الحقيقة إن في Concept مهم جدًا في Software Engineering شغال في الكواليس اسمه Caching.

في تطبيقات الموبايل، سواء كانت Native أو مبنية باستخدام Flutter، بدل ما التطبيق يعمل API Request كل مرة المستخدم يفتح فيها نفس الشاشة، يحتفظ بنسخة من البيانات في Local Cache.

في Flutter، المطور يقدر يستخدم حلول زي Hive أو SharedPreferences أو SQLite، أو يعتمد على مكتبات متخصصة للصور والملفات. ولما المستخدم يفتح التطبيق مرة تانية، النظام بيدور الأول في الـ Cache.

لو البيانات موجودة، ودي بنسميها Cache Hit، التطبيق يقدر يعرضها للمستخدم فورًا، وبعدها يعمل Background Refresh عشان يجيب أحدث نسخة من الـ Server لو لزم الأمر.

أما لو البيانات مش موجودة، ودي اسمها Cache Miss، ساعتها التطبيق بيعمل API Request، ويجيب البيانات من الـ Server، وبعدها يحتفظ بنسخة منها في الـ Cache عشان الاستخدامات اللي بعد كده.

اهم مميزات ال Caching ان التطبيق بيفتح أسرع، واستهلاك الإنترنت بيقل، والـ User Experience بتكون أفضل بكتير، خصوصًا في التطبيقات اللي المستخدم بيفتحها بشكل متكرر.

لكن لو الموضوع بالسهولة دي... ليه مش بنعمل Cache لكل حاجة؟ لأن التحدي الحقيقي مش في تخزين البيانات… التحدي هو إن البيانات دي تفضل Up-to-Date.

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

المشكلة دي اسمها Cache Invalidation، وبتعتبر من أصعب المشاكل في Software Engineering، لأنها بتحتاج توازن بين Performance وData Consistency.

الـ Caching مش مجرد طريقة تخلي التطبيق يفتح أسرع، ولكن هو Architecture Decision بيأثر بشكل مباشر على Performance، و Scalability، و User Experience.

وعشان كده، التطبيقات الاحترافية مش بتفكر بس في إزاي تجيب البيانات من الـ Server … ولكن بتفكر كمان إمتى تعتمد على الـ Cache، وإمتى لازم ترجع للمصدر الأساسي للبيانات.






تخيل إن معاك Dataset وبعد ما شيلت منها الاسم، ورقم الموبايل، وأي معلومة بتحدد الشخص بشكل مباشر... افتكرت إنها بقت Anonym...
16/07/2026

تخيل إن معاك Dataset وبعد ما شيلت منها الاسم، ورقم الموبايل، وأي معلومة بتحدد الشخص بشكل مباشر... افتكرت إنها بقت Anonymous، لكن الحقيقة إن لسه فيه حد يقدر يعرف مين أصحاب البيانات دي!

أغلب الناس بتفتكر إن حذف الـ Direct Identifiers كفاية لكن أحيانًا معلومات شكلها عادي، زي السن أو المدينة أو حتى مجموعة اهتمامات، بتكون كفاية إنها توصل لهوية الشخص لو تم ربطها بمجموعة بيانات تانية، وده اللي بيتعرف باسم Linkage Attack.

المشكلة إن الـ Dataset دي ممكن تتشارك مع Team تاني، أو يتم تحليلها، أو استخدامها في تدريب موديل Machine Learning وساعتها، مجرد حذف الاسم أو رقم الموبايل مبقاش كفاية لحماية خصوصية أصحاب البيانات.

وده سبب ظهور مفهوم Privacy-Preserving ML اللي هدفه إننا نستخدم البيانات من غير ما نكشف هوية أصحابها أو نعرّض خصوصيتهم للخطر.
ولأن مفيش طريقة واحدة تناسب كل الحالات، ظهرت Techniques مختلفة، كل واحدة منها بتحل جزء من المشكلة:
k-Anonymity: بتضمن إن كل مجموعة من الـ Quasi-Identifiers تتكرر عند أكتر من شخص، فيبقى صعب ربط البيانات بشخص واحد.
Differential Privacy: بتضيف Noise محسوب على ال data يحافظ على خصوصية الأفراد و من غير ما يأثر بشكل كبير على النتائج.
Federated Learning: بيدرب الـ Model على أجهزة المستخدمين، ويشارك الـ Model Updates بدل الـ Raw Data.
Synthetic Data: بينشئ Data جديدة ليها نفس الـ Statistical Patterns الموجودة في البيانات الأصلية، من غير ما تمثل بيانات أشخاص حقيقيين.

ورغم اختلاف الطرق، إلا إن الهدف منها واحد: تقليل فرص الـ Re-identification، مع الحفاظ على أكبر قدر ممكن من قيمة البيانات.






أكيد قابلتك الرسالة دي قبل كدة:" Password must contain at least 8 characters, an uppercase letter, a lowercase letter, a...
11/07/2026

أكيد قابلتك الرسالة دي قبل كدة:
" Password must contain at least 8 characters, an uppercase letter, a lowercase letter, a number, and a special character."
وأول رد فعل بيكون: "هو الموقع معقدها علينا ليه؟"
الإجابة ليها علاقة بهجوم اسمه Brute Force Attack.

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

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

بس هنا ييجي سؤال مهم، طيب لو المهاجم عنده وقت كفاية، إيه اللي يمنعه يفضل يجرب لحد ما يوصل للباسورد؟
هنا بيظهر دور Rate Limiting.
الموقع مش بيسيب أي شخص يجرب عدد لا نهائي من كلمات المرور. لا هو بيحدد عدد معين من محاولات تسجيل الدخول خلال فترة زمنية.
يعني مثلًا، بعد 5 محاولات فاشلة، ممكن يمنع أي محاولة جديدة لمدة دقيقة أو خمس دقائق، أو يطلب منك تحل CAPTCHA قبل ما تكمل.
وده معناه إن المهاجم، حتى لو كان عنده Script يقدر يجرب آلاف كلمات المرور، هيلاقي نفسه واقف بعد كام محاولة بس.
بمعنى تاني… كلمة المرور القوية بتزود عدد الاحتمالات اللي لازم المهاجم يجربها. والـ Rate Limiting بيقلل سرعة التجربة.

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






سألت AI model سؤال وجاوبك بسرعة؟ الإجابة تحسها مقنعة جداً، بس للاسف طلعت غلط!أغلب الناس بتفتكر إن ده عيب في الـ AI، أو غ...
06/07/2026

سألت AI model سؤال وجاوبك بسرعة؟ الإجابة تحسها مقنعة جداً، بس للاسف طلعت غلط!

أغلب الناس بتفتكر إن ده عيب في الـ AI، أو غلطة من الموديل. لكن في الحقيقة، المشكلة إنه مكانش عنده المعلومة أصلا.
الـ LLMs مش بتقرأ الـ PDFs اللي عندك، ولا عارفة الـ Documentation الخاصة بمشروعك.. هي بتعرف اللي اتعلمته وقت الـ Training بس.
الموضوع ممكن يكون بسيط لو بتسأل سؤال عام، ولكن لو شغالين على داتا حرجة زي بناء موديل لبيانات طبية مثلاً، الدقة فيه لازم تبقى كبيرة لإن الموديل لو بيغلط ف دي تبقى كارثة.
وده بالضبط السبب اللي ظهر علشانه الـ RAG (Retrieval-Augmented Generation)

النظام بيمشي في 3 خطوات:
1) البحث (Retrieval): بيقسم المحتوى لأجزاء صغيرة (Chunks)، ولما تسأل، بيبحث في الداتا بتاعتك عن أقرب الأجزاء المرتبطة بالسؤال.
2) الدمج (Augmentation): بياخد المعلومات الدقيقة دي ويبعتها كـ Context للـ Model.
3) التوليد (Generation): الموديل يبدأ يظبط الإجابة بناءً على الـ Context ده. بالتالي الإجابة بتبقى Grounded ومبنية على معلوماتك الحقيقية، مش على توقعات الموديل.

الفكرة بقى ان بناء RAG System في Jupyter Notebook مبياخدش وقت كبير، بس الـ Production موضوع تاني خالص!
الشطارة الحقيقية مبقتش بس في حجم الموديل، الشطارة في هندسة الـ Pipeline بالكامل. عشان تاخد المشروع للـ Deployment وتضمن إنه Scalable، لازم تعتمد على technologies زي Docker وعشان تضمن ال stability بتاعت ال environment، وت document الـ APIs بتاعتك بوضوح باستخدام tools زي Swagger.

ال engineering structure ده اللي بيضمن إن شغل team الـ AI يتعمله integration بسهولة ودون مشاكل مع شغل باقي ال teams سواء في الـ Backend أو الـ Frontend أو الـ Mobile.

المشكلة الحقيقية في الـ Production عمرها ما كانت:
How do we make the AI smarter ?

المشكلة دايماً:
How do we get it the right information, and how do we build an entire engineering pipeline to serve it ?






في مجال البرمجة وأي شيء له علاقة ببناء برنامج لتسهيل حاجة كانت صعبة، أهم حاجة عندنا بتبقى الdata، والسؤال هنا هنخزنها إز...
01/07/2026

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

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

الحل التاني وهو اللي هنتكلم عليه النهاردة: الcentralized database، يعني قاعدة بيانات مركزية لكل المستخدمين.
أبسط مثال ليها هو Google Docs، أكتر من حد يقدر يفتح نفس الملف ويعدل فيه في نفس اللحظة، والتغييرات بتسمّع عند الكل فوراً ومن غير أي تعارض.

بما إن الdatabase بتكون واحدة والكل بيعدل عليها، فإحنا مش محتاجين نفكر في الداتا اللي غيرنا عدلها أو ضافها.
في tools بتساعدنا نتعامل مع Database بواجهة سهلة بنسميها Database Management Systems (DBMS) ودي بتساعدنا في انشاء الداتابيز والتعامل معاها بشكل سهل وبتعرض البيانات بشكل مفهوم وغيرها من مميزات تانية كتير.

الداتابيز هي اللي بتحول برنامجك من مجرد أداة بتفقد البيانات لنظام متكامل يقدر يكبر بجد.






Where Logic Meets Reality! 💻Highlights from our latest CS Tracks offline sessions. Great energy, focused minds, and a lo...
10/05/2026

Where Logic Meets Reality! 💻

Highlights from our latest CS Tracks offline sessions. Great energy, focused minds, and a lot of learning.

Stay tuned for what's coming! 🩶


05/03/2026

عالم مختلف بيحصل فيه معارك يومية بين الهجوم والدفاع؟! 🔐
كل يوم في هجمات بتحاول تكسر الأنظمة وتسرق البيانات وفي نفس اللحظة فرق كاملة بتتصدى ليها وتحمي الشبكات… وده هو عالم Cybersecurity. 🛡

في النسخة دي من IEEE Nights هتدخل معانا رحلة داخل عالم السايبر تخليك فاهم الصورة الكبيرة بشكل مبسط ومشوق يخليك عارف:

● يعني إيه Cybersecurity وليه مهم دلوقتي أكتر من أي وقت فات.
● أهم التخصصات والفرص اللي المجال بيقدمها في سوق العمل.
● خطوات البداية وأهم المهارات المطلوبة عشان تبدأ رحلتك فيه.
● وكمان هنعرف الفرق بين فرق الهجوم (Red Team) والدفاع (Blue Team) وإزاي كل واحد ليه دور أساسي في حماية الأنظمة.

هيكون معانا في السيشن:
🔹Eng. Hossam Shady
◼️ Instructor at EC-Council

📌 Session Details:
📅 Date: 5-3-2026
⏰ Time: 10:00 PM
📍 Platform: Online via Google Meet
🔗 Meeting Link: meet.google.com/feh-nkdu-hvh

ادخل جروب الواتس عشان توصلك التفاصيل أول م تنزل ...
https://chat.whatsapp.com/DdyNmEbiE5PAoQ7h1IeEds?mode=gi_t

03/03/2026

عمرك سألت نفسك إزاي التطبيقات والأنظمة الكبيرة اتعملت؟ 🤔 المواقع الكبيرة زي أمازون وجوجل مش مجرد back-end و front-end لكنهم شبكة كبيرة معقدة من الخدمات والأدوات تم تصميمها ودمجها مع بعض بشكل منظم.

وهو ده الـ system designو اللي بيحدد حاجات مهمة جدا زي:
* Architecture معمارية وشكل النظام ومكوناته
* Components مكونات وأدوات النظام
* Data flow الشكل اللي البيانات هتمشي بيه
* Interactions التواصل بين مكونات النظام الداخلية وبعضها والتواصل بين الأنظمة الخارجية

عشان كدة في IEEE Nights المرة دي هنتكلم الـ system design !⚒️⚙️
هنتعرف في السيشن على مفهوم الـ system design وأهميته في عالم الـ software engineering وسوق الوظائف والإحصائيات عن المجال وأنواع الاسئلة في الـ interviews علشان تعرف ايه الحاجات اللي تركز عليها.

هينورنا في السيشن:
🔹 Ehab Terra
◼️ Senior Software engineer

📌 Session Details:
📅 Date: 4-3-2026
⏰ Time: 10:00 PM
📍 Platform: Online via Google Meet
🔗 Meeting Link: meet.google.com/mcz-ievq-uia

ادخل جروب الواتس عشان توصلك التفاصيل أول م تنزل ...
https://chat.whatsapp.com/DdyNmEbiE5PAoQ7h1IeEds?mode=gi_t

Address

Zagazig

Website

Alerts

Be the first to know and let us send you an email when IEEE CS Zagazig Student Chapter posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The University

Send a message to IEEE CS Zagazig Student Chapter:

Shortcuts

Share

Category