دردشة سريعة عن الـ Interface Segregation Principle 💯
.
.
تخيل أنك في شغلانة معينة وكل شوية حد يطلب منك تاسكات ملهاش علاقة ببعض ولا ليها علاقة بالشغلانة...طبيعي هتلاقي نفسك مشتت بين التاسكات كلها ومفيش فرصة تركز في الشغلانة الأساسية اللي جاي علشانها وكمان مش هتعملها بأفضل شكل.

نفس السيناريو ده بالضبط ممكن يحصل في البرمجة لما الكود يبقى مضطر يلتزم بحاجات هو مش محتاجها.

وهنا هتلاقي دور الـ Interface Segregation Principle، واحد من أهم المبادئ الخمسة لمفهوم SOLID، عشان يحل المشكلة دي.

———

يعني إيه Interface Segregation Principle؟ 🤔

الـ ISP بيقول ببساطة: "مينفعش تخلي الكود يلتزم بحاجات هو مش محتاجها."

لو عندك Interface فيه مليون وظيفة (methods) لكن الكائن (object) اللي هيستخدم الـ Interface ده هيحتاج كام حاجة بس، يبقى كده أنت بتحمّله شغل ملوش لازمة، وده هيعمل مشاكل في الكود بعدين.

———

مثال بسيط 👇

لو عندك Interface اسمه Bird

interface Bird {
  fly(): void;
  swim(): void;
}

لو عملت كائن (object) زي Duck هيبقى منطقي جدًا إنه يقدر يطير (fly) ويعوم (swim).
لكن لو عندك كائن زي Penguin؟ البطريق بيعوم بس، ومش بيعرف يطير!

في الحالة دي الـ Penguin هيضطر يطبق (implement) وظيفة ملوش علاقة بيها وهي fly، حتى لو مش هيستخدمها.

———

✅ الحل؟

افصل الوظائف بتاعت الـ Interface على حسب الاحتياج الفعلي:

interface FlyingBird {
  fly(): void;
}

interface SwimmingBird {
  swim(): void;
}

وكده لما تيجي تعمل Duck، هيطبق الاتنين:

class Duck implements FlyingBird, SwimmingBird {
  fly() {
    console.log('Duck is flying');
  }
  
  swim() {
    console.log('Duck is swimming');
  }
}

أما الـ Penguin، هيطبّق بس اللي له علاقة به:

class Penguin implements SwimmingBird {
  swim() {
    console.log('Penguin is swimming');
  }
}

———

📌 ليه المبدأ ده مهم؟

- لما كل كائن يكون مرتبط بالوظائف اللي فعلًا محتاجها، بيبقى أسهل تعمل تغييرات من غير ما تسبب مشاكل لباقي الكود.
- الكود بتاعك هيبقى منظم "Organized" أكتر ومفهوم لأي حد يشتغل عليه بعدك.
- مش هتضطر تضيف دوال (methods) مش مستخدمة، وده بيقلل الـ Bugs اللي ممكن تظهر.

———

📍 دائمًا خليك حريص إن أي Interface يكون متخصص ومحدد الوظائف.
📍 لو لقيت Interface كبير ومعقد، افصله لعدة Interfaces أصغر.
📍 فكر كويس قبل ما تعمل أي implements، واسأل نفسك: الكائن ده فعلًا محتاج كل اللي موجود في الـ Interface؟

———

وفقكم الله لكل خير 🌿

أكيد سمعت عن Docker في عالم البرمجة 💡
.
.
تعال ندردش شوية عن Docker بطريقة بسيطة ونفهم هو ليه شيء أساسي في تطوير التطبيقات. 💯

———

📌 إيه هو Docker؟

ببساطة، Docker هو منصة بتسمح لك تبني، تختبر، وتشغل تطبيقاتك في حاجة اسمها Container.

طيب يعني إيه Container؟

فكر فيها زي علبة بتحط فيها التطبيق بتاعك بكل المكونات اللي محتاجها عشان يشتغل: الـ Code، الـ Libraries، والـ Dependencies اللي مستخدمها، والـ System Configurations.

الفكرة الأساسية إن الـ Container ده بيشتغل زي ما هو على أي جهاز أو سيرفر، بغض النظر عن الـ Operating System أو الـ Environment اللي عليه. يعني لو التطبيق شغال عندك على جهازك الشخصي، هيشتغل بالضبط بنفس الطريقة على أي سيرفر تاني من غير مشاكل.

———

📌 ليه Docker مهم في مجال البرمجة؟

⚡️ التوافق بين البيئات المختلفة:

من أكتر المشاكل اللي معظمنا بيقابلها إنك تشتغل على مشروع على جهازك وكل حاجة تبقى تمام، لكن أول ما تيجي ترفعه على السيرفر، تبدأ المشاكل!

ممكن الـ Libraries أو الـ Environment اللي على السيرفر تكون مختلفة عن جهازك، وده يخلي حاجات كتير تبطل تشتغل.

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

———

⚡️ سرعة الانتقال من مرحلة التطوير للإنتاج:

العادي في أي مشروع إنك بتبدأ بـ Development Environment، وبعد كده تنقل المشروع لـ Production Environment.

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

———

⚡️ مرونة في التوسع (Scalability):

لو بتشتغل على مشروع كبير أو بتبني تطبيق بيسمح بعدد كبير من المستخدمين، هتحتاج تعمل Scale للتطبيق بسرعة.

تقدر تعمل نسخ متعددة من الـ Containers وتشغلهم على أي عدد من السيرفرات بسهولة وفي وقت قليل، وبالتالي تقدر تتعامل مع زيادة الأحمال بدون مشاكل.

———

⚡️ سهولة التجربة والاختبار:

ميزة Docker إنه بيوفر لك بيئة معزولة لتجربة أفكار جديدة أو تعديل كود معين بدون التأثير على التطبيق الرئيسي. يعني، لو عايز تجرب Framework جديد أو تضيف Feature للتطبيق، تقدر تعمل Container جديد وتجرب براحتك من غير ما تأثر على البيئة اللي شغال عليها باقي الفريق أو المشروع الأساسي.

———

⚡️ الحفاظ على استمرارية العمل:

من خلال Docker تقدر تتأكد إن نفس الـ Setup شغال عندك، عند باقي الفريق، وعلى السيرفرات اللي بتشغل التطبيق. ده معناه إن مفيش مشاكل هتحصل بسبب فرق في الـ Configuration أو الـ Environment.

———

لو تعرف مصادر كويسة بتشرح Docker ياريت تضيفها في التعليقات وتفيد غيرك ✅

بالتوفيق 🌿

إزاي تكون مهندس برمجيات شاطر؟
.
.
How To Be A Good Software Engineer

———

📌 الجزء الأول:

Master the Fundamentals: The Bedrock of Becoming a Good Software Engineer
https://dev.to/alisamir/master-the-fundamentals-the-bedrock-of-becoming-a-good-software-engineer-2823

———

📌 الجزء الثاني:

Write Clean, Maintainable Code: A Guide for Software Engineers
https://dev.to/alisamir/write-clean-maintainable-code-a-guide-for-software-engineers-2834

———

📌 الجزء الثالث:

Mastering Testing and Continuous Learning: Steps to Become a Better Software Engineer
https://dev.to/alisamir/mastering-testing-and-continuous-learning-steps-to-become-a-better-software-engineer-an1

———

📌 الجزء الرابع:

How to Excel in Problem-Solving and Collaboration as a Software Engineer
https://dev.to/alisamir/how-to-excel-in-problem-solving-and-collaboration-as-a-software-engineer-2ih8

———

📌 الجزء الخامس:

Becoming a Good Software Engineer: Business Alignment and Performance Optimization
https://dev.to/alisamir/becoming-a-good-software-engineer-business-alignment-and-performance-optimization-3bd0

———

📌 الجزء السادس:

How Embracing Tools and Cultivating Soft Skills Can Make You a Better Software Engineer
https://dev.to/alisamir/how-embracing-tools-and-cultivating-soft-skills-can-make-you-a-better-software-engineer-37c4

———

📌 الجزء السابع:

Building a Personal Brand and Embracing Adaptability as a Software Engineer
https://dev.to/alisamir/building-a-personal-brand-and-embracing-adaptability-as-a-software-engineer-5ke

تعال ندردش شوية عن الـ Load Balancing 🔻
.
.
الـ Load Balancing حاجة مهمة جدًا بتأثر في سرعة وثبات أي تطبيق، وخصوصًا لو التطبيق ده عليه عدد ضخم من المستخدمين.

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

———

📌 إزاي الـ Load Balancing بيشتغل؟

تخيل معايا أنك عندك تطبيق عليه عدد كبير من المستخدمين اللي بيدخلوا ويعملوا طلبات في نفس الوقت، زي متجر إلكتروني كبير أو موقع تواصل اجتماعي.

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

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

الـ Load Balancer بيدخل هنا وبيبقى هو اللي بيحدد الطلبات تروح لمين، بحيث مفيش سيرفر يكون عليه ضغط أكتر من التاني.

———

📍 أنواع الـ Load Balancing:

- الـ Round Robin: الطريقة دي ببساطة بتوزع الطلبات بالتساوي على كل السيرفرات. أول طلب يروح لأول سيرفر، والتاني للتاني، وهكذا لحد ما يوصل لآخر سيرفر ويرجع تاني من الأول.

- الـ Least Connections: الطريقة دي بتركز على عدد الاتصالات اللي كل سيرفر شغال عليها، بمعنى إنها بتبعت الطلب للسيرفر اللي عليه عدد أقل من الطلبات حاليًا، وده بيكون مفيد لما يكون فيه اختلاف كبير في الحمل بين الطلبات.

- الـ IP Hash: هنا التوزيع بيكون بناءً على عنوان IP بتاع العميل اللي بيعمل الطلب، يعني كل عميل دايمًا هيتم توجيهه لنفس السيرفر بناءً على عنوان الـ IP بتاعه، ودي بتنفع في حالات معينة زي لما يكون فيه بيانات كاش محتاجة تتوزع.

- الـ Weighted Load Balancing: في الحالة دي بنعمل أحمال مختلفة للسيرفرات بناءً على قدرتهم. يعني لو عندك سيرفر أقوى من الباقيين، تقدر تخليه ياخد حمل أكبر.

———

📍 ليه الـ Load Balancing مهم؟

الهدف الأساسي من الـ Load Balancing هو إنه يخلي التطبيق بتاعك مستقر وسريع للمستخدمين مهما زاد عددهم.

يعني بدل ما الموقع يعلق أو يقع، الطلبات هتفضل تتوزع بشكل مرن على كل السيرفرات.

———

وفقكم الله لكل خير 🌿

دردشة سريعة عن الـ Hydration 🔻
.
.
عمرك فكرت إزاي React أو Next.js بيقدروا يحولوا كود الـ HTML اللي تم إنشاؤه في السيرفر لموقع شغال بالكامل في المتصفح؟ 🤔

العملية دي اسمها Hydration ... تعال نعرف إزاي الموضوع بيتم...

———

📌 إيه هو الـ Hydration؟

ببساطة كده، الـ Hydration هو العملية اللي React بتعملها عشان "تربط" الكود اللي اتعمل على السيرفر (SSR - Server-Side Rendering) مع الكود اللي بيشتغل على المتصفح (Client-Side Rendering).

يعني لما تفتح صفحة جايه من السيرفر، React مش بتبدأ من الصفر، هي بتلاقي كود HTML جاهز ومحتاج تزود عليه الـ React Components وتبدأ تتعامل معاها.

———

📌 ليه الـ Hydration مهم؟

📍 تحسين الـ Performance:
بما إن السيرفر بيبعت HTML جاهز، المتصفح يعرض الصفحة أسرع. المستخدم يشوف المحتوى أسرع حتى لو الـ JavaScript لسه بيحمل.

📍 الـ SEO Optimization:
عشان محركات البحث زي Google تقدر تقرأ محتوى الصفحة بسهولة، لازم الـ HTML يكون موجود وجاهز. ده بيخلي موقعك يظهر في ترتيب أعلى.

📍 الـ Smooth User Interaction:
بعد الـ Hydration، الصفحة تبقى interactive بالكامل. المستخدم يقدر يتفاعل مع الـ buttons، forms، والـ links بشكل طبيعي.

———

📌 إزاي الـ Hydration بيشتغل؟

العملية بتحصل كالتالي:

1- السيرفر بيعمل Server-Side Rendering (SSR)، ويبعت HTML جاهز للمتصفح.
2- لما يوصل الـ HTML، المتصفح يعرض الصفحة مباشرة.
3- بعد ما الـ JavaScript يخلص تحميل، React بيبدأ الـ Hydration، وبيربط الكود الجاهز مع الـ DOM.
4- من اللحظة دي، الصفحة بتتحول لـ interactive.

———

📌 مشاكل ممكن تواجهك مع الـ Hydration:

⚡️ الـ Mismatch بين الـ HTML والـ React State:

لو السيرفر بعت HTML معين والـ React حاول يرندر حاجة مختلفة، ممكن تظهر أخطاء زي Hydration failed.


⚡️الـ Render Blocking JavaScript:

لو فيه ملفات JavaScript كبيرة أو معقدة بتتأخر في التحميل، الـ Hydration هيبقى بطيء.


⚡️ الـ Heavy Components في الـ Client:

لو عندك Components معقدة جدًا، العملية هتستهلك وقت أطول.

———

📌 إزاي تحسن تجربة الـ Hydration؟

✅ استخدم Dynamic Imports:
في Next.js، ممكن تستخدم ()dynamic عشان تأخر تحميل بعض الـ components غير الضرورية.

✅ خلي فيه أهمية للـ Critical Content:
اعمل رندر للمحتوى الأساسي الأول، وبعدها خلي باقي الصفحة تتفاعل.

✅ تجنب الـ Client-Only Rendering لو مش ضروري:
حاول تخلي معظم الـ Components بتشتغل مع الـ SSR، إلا لو عندك حاجة لازم تتعمل في الـ client.

———

📌 الفرق بين React و Next.js في الـ Hydration؟

في React، لو بتعمل Client-Side Rendering (CSR) بس، مفيش Hydration. لكن لما تستخدم ()ReactDOM.hydrate، بتبدأ العملية.

أما في Next.js، الـ Hydration بيشتغل أوتوماتيك لما تستخدم ميزات زي الـ SSR أو الـ Static Site Generation (SSG).

———

وفقكم الله لكل خير 🌿

سؤال فرونت إند لذيذ ممكن يقابلك في الانترڤيو 💯
.
.
📌 إيه الفرق بين الـ async والـ defer في الـ noscript tag؟

———

📍 تعال نفهم المشكلة الأول

لما بتستخدم <noscript> عشان تضيف JavaScript في الصفحة، المتصفح بيبدأ يقرأ الكود (HTML parsing)، لكن لما يوصل لـ noscript مش محدد له async ولا defer، هيعمل إيه؟

- هيوقف قراءة الـ HTML.
- هيحمّل الـ noscript بالكامل.
- بعدين يشغّل الكود.
- وبعدين يكمل قراءة الـ HTML.

ده معناه إن الصفحة هتقف شوية (render blocking) لحد ما التحميل والتشغيل يخلصوا. النتيجة؟ تجربة مستخدم أبطأ والموقع هيكون تقيل.

———

وهنا دور الـ async والـ defer علشان يحلوا المشكلة:

📌 أولًا: async

لما تستخدم async في الـ noscript tag بالشكل ده:

<noscript src="main.js" async></noscript>

المتصفح هيعمل الخطوات دي:

1- يكمل قراءة الـ HTML
2- يحمّل الـ noscript في الخلفية.
3- بمجرد ما التحميل يخلص، هيوقف قراءة الـ HTML ويشغّل الـ noscript علطول.


📍 تشغيل الـ noscript مش مرتبط بانتهاء تحميل باقي الصفحة.
📍 لو عندك أكتر من async noscript، مفيش ضمان إنهم هيشتغلوا بنفس ترتيب الكتابة.

———

📌 ثانيًا: defer

لما تستخدم defer في الـ noscript tag بالشكل ده:

<noscript src="main.js" defer></noscript>

المتصفح هيعمل الآتي:

1- يكمل قراءة الـ HTML
2- يحمّل الـ noscript في الخلفية (زي async).
3- لكن مش هيشغّل الـ noscript غير لما الـ HTML كله يخلص تحميل بالكامل.


📍 الـ noscripts اللي بـ defer بتتنفذ بنفس ترتيب كتابتها في الـ HTML.
📍 ده بيكون مفيد جدًا لو عندك noscripts معتمدة على بعضها أو محتاجة ترتيب معين.

———

طيب.. أستخدم مين فين؟ 🤔

✅ الـ async: لو الـ noscript مستقل ومش معتمد على حاجة تانية، زي noscript لتتبع الزوار (Analytics).

✅ الـ defer: لو الـ noscript بيعتمد على ترتيب معين أو محتاج يستنى تحميل الصفحة بالكامل قبل التنفيذ، زي الكود الأساسي للـ application بتاعك.

———

📌 مثال توضيحي

لو عندك كود بالشكل ده:

<noscript src="noscript1.js" async></noscript>
<noscript src="noscript2.js" async></noscript>

ممكن noscript2.js يشتغل قبل noscript1.js لأن async ملوش علاقة بالترتيب.


📍 لكن لو استخدمت defer

<noscript src="noscript1.js" defer></noscript>
<noscript src="noscript2.js" defer></noscript>

هنا noscript1.js دائمًا هيشتغل قبل noscript2.js، مهما حصل.

———

⚡️ خلاصة القول:

- الـ async: سريع بس عشوائي.
- الـ defer: منظم وبيشتغل بالترتيب.

———

وفقكم الله لكل خير 🌿