IEEE CS Zagazig Student Chapter

30/10/2026

⏳ 12 HOURS LEFT… THE CLOCK IS TICKING!

Every big journey starts with one decision, and yours could start right here.

Still thinking about joining IEEE ZSB? Consider this your sign to stop overthinking and take the leap!

The countdown has begun… will you make it in time?

🔗 Apply NOW: https://forms.gle/8iW9LEJVUxNLXEoDA

28/10/2026

BEHIND EVERY DOOR, THERE'S A NEW WORLD TO BUILD
WHICH ONE IS YOURS? 💻💙

At IEEE CS ZSB, technology isn't just something you learn... it's something you build

Explore different fields, turn concepts into real projects, solve problems, and discover where your passion for technology can take you

SIX DOORS
SIX PATHS TO EXPLORE

1) Frontend Development — Build interactive interfaces using HTML, CSS, JavaScript, React & Next.js

2) Backend Development — Work with programming, databases, API design & server-side applications

3) Mobile Development — Create mobile applications using Dart, Flutter & API integration

4) Data Science — Explore Python, NumPy, Pandas, statistics, data visualization & machine learning

5) Artificial Intelligence — Dive into machine learning, deep learning, Generative AI, computer vision & NLP

6) Cybersecurity — Explore networking, Linux, cryptography, ethical hacking & pe*******on testing.

Through roadmaps, technical sessions, hands-on tasks, and real-world projects.
you'll strengthen your technical foundation, sharpen your problem-solving skills, and collaborate with a community that grows together

THE NEXT DOOR WON'T OPEN ITSELF
TAKE THE FIRST STEP ⚙️

Choose your track, Build your skills
Turn your ideas into reality with IEEE CS ZSB

join us for IEEE ZSB Season'27: https://forms.gle/8iW9LEJVUxNLXEoDA

28/10/2026

Four doors
Four paths
One choice to make

CS, RAS, PES, or WIE ...each chapter opens a different door to your next step with IEEE ZSB

The question is… which door will you choose?
join us for IEEE ZSB Season'27: https://forms.gle/8iW9LEJVUxNLXEoDA

25/10/2026

Your next big move starts here

IEEE ZSB is opening the door to a new season of ideas, challenges, and opportunities to make your mark

The question is:
Are you in?

Apply now and ignite the legacy 🚀: https://forms.gle/8iW9LEJVUxNLXEoDA

20/10/2026

The flame has been taken, and Season ’27 needs its crew. 🔥🕹️
Think you have what it takes to join IEEE ZSB? Put your skills to the test in our recruitment mini-game, The Torch Heist.
Find your track.
Discover your potential.
Make your contribution.
Scan the QR code on the screen, clear the challenge, and secure

Play & Apply: games.ieee-zsb.org

19/10/2026

26/08/2026

READY TO KICK-START YOUR IEEE XTREME JOURNEY?

Think you’re ready to take on the challenge?

Join our IEEE Xtreme Info Session and get everything you need to know before the competition.

During the session, we’ll cover:
• Rules & Eligibility
• Prizes
• Competition Timeline
• Important Details
• Q&A — Bring all your questions!

Location: Online — Google Meet
Date: Thursday, August 27
Time: 9:30 PM

Meeting Link:
[https://meet.google.com/xus-pbjz-jhe]

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؟

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.

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، وإمتى لازم ترجع للمصدر الأساسي للبيانات.