🚀 C# Mastery Learning Path
A comprehensive guide to mastering C#, .NET, and related technologies from beginner to advanced level.
https://github.com/Metigator
GitHub
metigator - Overview
Microsoft MVP. metigator has 122 repositories available. Follow their code on GitHub.
❤3
دردشة سريعة عن الـ Distributed Systems 🔻
———
📌 يعني إيه Distributed Systems؟
ببساطة، الـ Distributed Systems هي نظام بيتكون من مجموعة أجهزة كمبيوتر (أو سيرفرات) شغالة مع بعض كأنهم جهاز واحد.
الهدف الأساسي إننا نوزع الشغل (processing) أو تخزين البيانات (storage) على أكتر من جهاز عشان نحقق حاجات زي:
📍 الـ Scalability:
لو النظام محتاج يشتغل مع عدد مستخدمين أكبر أو بيانات أكتر، نقدر نزود أجهزة جديدة بسهولة بدل ما نضغط على جهاز واحد.
📍 الـ Fault Tolerance:
لو جهاز وقع أو حصلت مشكلة في مكان معين، النظام يكمل شغله عادي بدون توقف.
📍 الـ Performance:
توزيع الحمل على أكتر من جهاز بيخلي العمليات أسرع وأكثر كفاءة.
———
إزاي الأنظمة دي بتشتغل؟ 🤔
الفكرة الأساسية في أي Distributed System هي وجود أجهزة بتتواصل مع بعضها (Networking). الأجهزة دي بتبعت لبعض رسائل (Messages) عن طريق الشبكة عشان تنجز المهام. خليني أشرحلك 3 مكونات أساسية:
⚙️ الـ Nodes (العُقد): دي الأجهزة نفسها اللي بتشيل الداتا أو بتعمل عمليات معينة. كل جهاز بنسميه "Node".
⚙️ الـ Communication: العقد دي لازم تتواصل مع بعض باستخدام بروتوكولات زي HTTP أو gRPC.
⚙️ الـ Consensus (التوافق): لما أكتر من جهاز يشتغلوا مع بعض، لازم يتفقوا على حالة معينة، خصوصًا لو أكتر من جهاز بيعدل على نفس الداتا.
———
🛠 أمثلة حقيقية على الـ Distributed Systems
📍 الـ Google Search: عملية البحث بتتوزع على آلاف السيرفرات عشان تلاقي الإجابة في جزء من الثانية.
📍 منصة Facebook: لما تفتح صفحتك، البيانات بتجيلك من أكتر من سيرفر، وكل سيرفر مسؤول عن جزء معين زي المنشورات أو الصور، عشان التحميل يكون أسرع.
📍 الـ Blockchain: كل الأجهزة (Nodes) اللي في الشبكة بتشتغل مع بعض عشان تحقق التوافق (Consensus) على المعاملات.
———
⚠️ التحديات في الـ Distributed Systems
مع إن الفكرة عبقرية، لكن فيها شوية تحديات مهم تخلي بالك منها:
- الـ Latency (زمن الاستجابة): التواصل بين الأجهزة بيحتاج وقت، وده ممكن يأثر على سرعة النظام.
- الـ Data Consistency (توافق البيانات): لما أكتر من جهاز يشتغلوا على نفس الداتا، لازم نضمن إنهم ما يدخلوا في تعارض (Conflict).
- الـ Fault Tolerance: إزاي نضمن إن النظام يفضل شغال حتى لو حصلت أعطال في بعض الأجهزة.
———
وفقكم الله لكل خير 🌿
———
📌 يعني إيه Distributed Systems؟
ببساطة، الـ Distributed Systems هي نظام بيتكون من مجموعة أجهزة كمبيوتر (أو سيرفرات) شغالة مع بعض كأنهم جهاز واحد.
الهدف الأساسي إننا نوزع الشغل (processing) أو تخزين البيانات (storage) على أكتر من جهاز عشان نحقق حاجات زي:
📍 الـ Scalability:
لو النظام محتاج يشتغل مع عدد مستخدمين أكبر أو بيانات أكتر، نقدر نزود أجهزة جديدة بسهولة بدل ما نضغط على جهاز واحد.
📍 الـ Fault Tolerance:
لو جهاز وقع أو حصلت مشكلة في مكان معين، النظام يكمل شغله عادي بدون توقف.
📍 الـ Performance:
توزيع الحمل على أكتر من جهاز بيخلي العمليات أسرع وأكثر كفاءة.
———
إزاي الأنظمة دي بتشتغل؟ 🤔
الفكرة الأساسية في أي Distributed System هي وجود أجهزة بتتواصل مع بعضها (Networking). الأجهزة دي بتبعت لبعض رسائل (Messages) عن طريق الشبكة عشان تنجز المهام. خليني أشرحلك 3 مكونات أساسية:
⚙️ الـ Nodes (العُقد): دي الأجهزة نفسها اللي بتشيل الداتا أو بتعمل عمليات معينة. كل جهاز بنسميه "Node".
⚙️ الـ Communication: العقد دي لازم تتواصل مع بعض باستخدام بروتوكولات زي HTTP أو gRPC.
⚙️ الـ Consensus (التوافق): لما أكتر من جهاز يشتغلوا مع بعض، لازم يتفقوا على حالة معينة، خصوصًا لو أكتر من جهاز بيعدل على نفس الداتا.
———
🛠 أمثلة حقيقية على الـ Distributed Systems
📍 الـ Google Search: عملية البحث بتتوزع على آلاف السيرفرات عشان تلاقي الإجابة في جزء من الثانية.
📍 منصة Facebook: لما تفتح صفحتك، البيانات بتجيلك من أكتر من سيرفر، وكل سيرفر مسؤول عن جزء معين زي المنشورات أو الصور، عشان التحميل يكون أسرع.
📍 الـ Blockchain: كل الأجهزة (Nodes) اللي في الشبكة بتشتغل مع بعض عشان تحقق التوافق (Consensus) على المعاملات.
———
⚠️ التحديات في الـ Distributed Systems
مع إن الفكرة عبقرية، لكن فيها شوية تحديات مهم تخلي بالك منها:
- الـ Latency (زمن الاستجابة): التواصل بين الأجهزة بيحتاج وقت، وده ممكن يأثر على سرعة النظام.
- الـ Data Consistency (توافق البيانات): لما أكتر من جهاز يشتغلوا على نفس الداتا، لازم نضمن إنهم ما يدخلوا في تعارض (Conflict).
- الـ Fault Tolerance: إزاي نضمن إن النظام يفضل شغال حتى لو حصلت أعطال في بعض الأجهزة.
———
وفقكم الله لكل خير 🌿
❤7
دردشة سريعة عن وظيفة Site Reliability Engineer ⚡️
.
.
زمان (قبل ما يظهر مصطلح SRE)، لما أي شركة كانت تبني سيستم كبير – مثلًا web app أو service فيها ملايين الـ Users – كان فيه دايمًا فصل واضح بين فريقين:
1- الـ Developers: الناس اللي بتكتب الكود وتضيف Features جديدة.
2- الـ Operations / SysAdmins: الناس اللي مسؤولة عن تشغيل السيستم، الـ monitering، الـ servers، الـ uptime، إلخ.
والفريقين دول كانوا في حرب مستمرة دايمًا، الـ Developer عايز يـ release features بسرعة ويريح دماغه، والـ Ops عايز السيستم يفضل ثابت، علشان كده بيكره أي تغييرات مفاجئة.
وطبعًا ده هيأثر على البيزنس بشكل عام وعلى طبيعة الشغل في الشركة وهنا تدخلت جوجل وعملت وظيفة جديدة اسمها Site Reliability Engineer
———
📌 يعني إيه SRE؟
ببساطة، الـ Site Reliability Engineering هو طريقة لتطبيق مبادئ الـ Software Engineering على مشاكل الـ Operations.
يعني بدل ما تعتمد على manual work، نخلي كل حاجة automated، measured، ومبنية على data واقعية.
الـ SRE Engineer بيكون في النص بين الـ Developers والـ Ops. هو مهندس فاهم المنظومة كلها من أول الكود لحد الـ production.
———
⚙️ شغل الـ SRE مقسم لحاجتين أساسيتين:
1- الـ Reliability: يتأكد إن السيستم شغال بثبات، مفيش downtime، وكل حاجة monitored.
2- الـ Velocity: يتأكد إن الـ teams تقدر تـ deploy بسرعة وآمان بدون ما النظام يبوظ.
———
💡 بعض المفاهيم الأساسية في عالم الـ SRE:
1. SLI / SLO / SLA
- الـ SLI (Service Level Indicator): مقياس لأداء السيستم، زي مثلًا latency أو availability.
- الـ SLO (Service Level Objective): الهدف اللي عايزين نحافظ عليه، زي إن الـ uptime يكون 99.9%.
- الـ SLA (Service Level Agreement): الاتفاق اللي الشركة بتديه للعملاء، ولو كسرته ممكن يحصل penalties.
الـ SRE بيتابع الـ SLI عشان يتأكد إننا داخل الـ SLO، ولو قربنا نكسره بيوقف أي تغييرات لحد ما الدنيا تستقر.
——
2. Error Budget
بدل ما تمنع التغيير تمامًا، خلي فيه ميزانية للأخطاء عن فريق الـ Development. مثلًا، لو الـ SLO بتاعك 99.9%، يبقى عندك 0.1% downtime مسموح بيه.
لو لسه الميزانية دي موجودة: ممكن تـ deploy features.
لو خلصت: توقف كل حاجة لحد ما النظام يستقر.
——
3. Monitoring & Alerting
الـ SRE بيبني أنظمة monitoring ذكية تـ detect المشاكل قبل ما المستخدم يحس بيها. وبيعمل alerts مبنية على الـ SLO مش على noise. يعني مش كل Warning تبقى Alert.
——
4. Incident Management
لما الدنيا تقع، الـ SRE بيقود عملية الـ incident response ويحدد المشكلة، ويصلحها، وبعدها يعمل حاجة اسمها Postmortem — تحليل بعد المشكلة عشان يتفادى تكرارها.
——
5. Automation
كل حاجة ممكن يتعملها automation:
- deployment
- scaling
- recovery
- testing
- monitoring
———
💯 المهارات اللي لازم تكون عند أي SRE محترم:
- فهم عميق للـ Linux systems
- خبرة في Cloud platforms (AWS / GCP / Azure)
- معرفة قوية بـ Networking و Load Balancing
- أدوات زي Prometheus, Grafana, Kubernetes, Terraform, Jenkins
- مهارات في Scripting (Python / Bash / Go)
- وأهم حاجة: problem-solving و communication skills ممتازة.
———
وفقكم الله لكل خير 🌿
.
.
زمان (قبل ما يظهر مصطلح SRE)، لما أي شركة كانت تبني سيستم كبير – مثلًا web app أو service فيها ملايين الـ Users – كان فيه دايمًا فصل واضح بين فريقين:
1- الـ Developers: الناس اللي بتكتب الكود وتضيف Features جديدة.
2- الـ Operations / SysAdmins: الناس اللي مسؤولة عن تشغيل السيستم، الـ monitering، الـ servers، الـ uptime، إلخ.
والفريقين دول كانوا في حرب مستمرة دايمًا، الـ Developer عايز يـ release features بسرعة ويريح دماغه، والـ Ops عايز السيستم يفضل ثابت، علشان كده بيكره أي تغييرات مفاجئة.
وطبعًا ده هيأثر على البيزنس بشكل عام وعلى طبيعة الشغل في الشركة وهنا تدخلت جوجل وعملت وظيفة جديدة اسمها Site Reliability Engineer
———
📌 يعني إيه SRE؟
ببساطة، الـ Site Reliability Engineering هو طريقة لتطبيق مبادئ الـ Software Engineering على مشاكل الـ Operations.
يعني بدل ما تعتمد على manual work، نخلي كل حاجة automated، measured، ومبنية على data واقعية.
الـ SRE Engineer بيكون في النص بين الـ Developers والـ Ops. هو مهندس فاهم المنظومة كلها من أول الكود لحد الـ production.
———
⚙️ شغل الـ SRE مقسم لحاجتين أساسيتين:
1- الـ Reliability: يتأكد إن السيستم شغال بثبات، مفيش downtime، وكل حاجة monitored.
2- الـ Velocity: يتأكد إن الـ teams تقدر تـ deploy بسرعة وآمان بدون ما النظام يبوظ.
———
💡 بعض المفاهيم الأساسية في عالم الـ SRE:
1. SLI / SLO / SLA
- الـ SLI (Service Level Indicator): مقياس لأداء السيستم، زي مثلًا latency أو availability.
- الـ SLO (Service Level Objective): الهدف اللي عايزين نحافظ عليه، زي إن الـ uptime يكون 99.9%.
- الـ SLA (Service Level Agreement): الاتفاق اللي الشركة بتديه للعملاء، ولو كسرته ممكن يحصل penalties.
الـ SRE بيتابع الـ SLI عشان يتأكد إننا داخل الـ SLO، ولو قربنا نكسره بيوقف أي تغييرات لحد ما الدنيا تستقر.
——
2. Error Budget
بدل ما تمنع التغيير تمامًا، خلي فيه ميزانية للأخطاء عن فريق الـ Development. مثلًا، لو الـ SLO بتاعك 99.9%، يبقى عندك 0.1% downtime مسموح بيه.
لو لسه الميزانية دي موجودة: ممكن تـ deploy features.
لو خلصت: توقف كل حاجة لحد ما النظام يستقر.
——
3. Monitoring & Alerting
الـ SRE بيبني أنظمة monitoring ذكية تـ detect المشاكل قبل ما المستخدم يحس بيها. وبيعمل alerts مبنية على الـ SLO مش على noise. يعني مش كل Warning تبقى Alert.
——
4. Incident Management
لما الدنيا تقع، الـ SRE بيقود عملية الـ incident response ويحدد المشكلة، ويصلحها، وبعدها يعمل حاجة اسمها Postmortem — تحليل بعد المشكلة عشان يتفادى تكرارها.
——
5. Automation
كل حاجة ممكن يتعملها automation:
- deployment
- scaling
- recovery
- testing
- monitoring
———
💯 المهارات اللي لازم تكون عند أي SRE محترم:
- فهم عميق للـ Linux systems
- خبرة في Cloud platforms (AWS / GCP / Azure)
- معرفة قوية بـ Networking و Load Balancing
- أدوات زي Prometheus, Grafana, Kubernetes, Terraform, Jenkins
- مهارات في Scripting (Python / Bash / Go)
- وأهم حاجة: problem-solving و communication skills ممتازة.
———
وفقكم الله لكل خير 🌿
❤8
دردرشة سريعة عن أنواع السيرفرات 💯
.
.
أغلبنا أول ما بيسمع كلمة Server بييجي في باله جهاز كبير في غرفة مكيفة، شغال 24 ساعة ومليان لمبات بتنور...
بس الحقيقة السيرفر مش لازم يكون جهاز ضخم… ممكن يكون مجرد Software أو Virtual Machine بيقدّم خدمة معينة.
الـ Server ببساطة هو جهاز (أو برنامج) بيستقبل Requests من أجهزة تانية اسمها Clients، وبيرد عليهم بـ Responses.
زي ما الـ Browser بيبعت طلب لموقع معين، والسيرفر بيرد عليه بالصفحة المطلوبة.
لكن السيرفرات مش كلها زي بعض… كل نوع له وظيفة مختلفة حسب الـ Use Case بتاعته...
———
📌 الـ Web Server
ده الأشهر، وهو اللي بيستقبل الـ HTTP Requests من المستخدم، وبيرد عليهم بـ HTML, CSS, JavaScript files، أو حتى JSON لو عندك API.
أشهر الأمثلة:
- Apache
- Nginx
- Microsoft IIS
باختصار: أي حاجة لها علاقة بعرض مواقع أو APIs… الـ Web Server هو اللي وراها.
———
📌 الـ Database Server
السيرفر اللي شايل كل الداتا اللي التطبيق محتاجها. سواء عندك Web App أو Mobile App، أكيد فيه Data بتتحفظ وتتعرض وقت الطلب…
أشهر الأمثلة:
- MySQL Server
- PostgreSQL Server
- MongoDB Server
- Microsoft SQL Server
الـ App بيبعت Query والسيرفر ينفذها ويرجعلك الـ Result.
———
📌 الـ File Server
دوره إدارة وتخزين الملفات ومشاركتها بين الأجهزة. زي إنك ترفع صور أو ملفات PDF أو Videos والناس التانية تقدر توصلها.
بيوفر Access Control وPermissions، علشان تضمن إن كل مستخدم له صلاحيات معينة.
الأمثلة: Google Drive, Dropbox, أو أي internal file system في الشركات.
———
📌 الـ Mail Server
ده مسؤول عن إرسال واستقبال الإيميلات. لو جربت تبعت إيميل من Gmail أو من دومين شركتك، فالموضوع ماشي من خلال Mail Servers.
أنواع البروتوكولات اللي بيستخدمها:
- الـ SMTP (للإرسال)
- الـ IMAP / POP3 (للاستقبال)
الأمثلة:
- Microsoft Exchange Server
- Postfix
- Exim
———
📌 الـ Application Server
السيرفر اللي بيشغّل الـ Business Logic بتاعة التطبيق.
يعني مش بيخزن بيانات زي Database Server، ولا بيقدّم HTML زي Web Server، لكنه بينفّذ الكود خلف الكواليس.
لو عندك React Frontend مثلًا و Node.js Backend، فالـ Node Server هو Application Server.
أمثلة تانية:
- Tomcat
- Express.js
- Django
- .NET Core
———
📌 الـ DNS Server
ده السيرفر اللي بيحوّل أسماء الدومينات (زي google.com) إلى IP Addresses.
أشهرهم:
- Cloudflare DNS
- Google DNS (8.8.8.8)
- OpenDNS
من غير DNS Server، كان زمانك بتدخل IP كامل عشان تفتح موقع جوجل أو لينكدإن
———
📌 الـ Proxy Server
السيرفر الوسيط بينك وبين الإنترنت.
لما تبعت Request، هو اللي يستقبلها ويقرر يبعتهالك ولا لا، أو يعدلها أو يخبي الـ IP الحقيقي بتاعك.
مفيد جدًا في الـ Security والـ Caching.
أنواعه:
- Forward Proxy
- Reverse Proxy
———
📌 الـ FTP Server
بيستخدم بروتوكول اسمه File Transfer Protocol لنقل الملفات بين جهازك والسيرفر.
قديم شوية لكنه لسه مستخدم في بعض الشركات. تقدر تستخدمه لرفع أو تحميل ملفات بسهولة.
أمثلة:
- vsftpd
- FileZilla Server
———
📌 الـ Virtual / Cloud Servers
الجيل الجديد من السيرفرات… بدل ما تشتري أجهزة غالية، بتأجر Resources على Cloud Provider زي AWS, Azure, أو Google Cloud.
الجميل في الموضوع إنك بتقدر تعمل Scaling بسهولة جدًا. يعني لو الترافيك زاد، تزود الـ CPU أو الـ RAM وأنت مرتاح.
أنواع السيرفرات دي ممكن تكون Web أو Database أو أي نوع من اللي فوق، بس بتشتغل في بيئة Cloud بدل الـ On-premise.
———
وفقكم الله لكل خير 🌿
.
.
أغلبنا أول ما بيسمع كلمة Server بييجي في باله جهاز كبير في غرفة مكيفة، شغال 24 ساعة ومليان لمبات بتنور...
بس الحقيقة السيرفر مش لازم يكون جهاز ضخم… ممكن يكون مجرد Software أو Virtual Machine بيقدّم خدمة معينة.
الـ Server ببساطة هو جهاز (أو برنامج) بيستقبل Requests من أجهزة تانية اسمها Clients، وبيرد عليهم بـ Responses.
زي ما الـ Browser بيبعت طلب لموقع معين، والسيرفر بيرد عليه بالصفحة المطلوبة.
لكن السيرفرات مش كلها زي بعض… كل نوع له وظيفة مختلفة حسب الـ Use Case بتاعته...
———
📌 الـ Web Server
ده الأشهر، وهو اللي بيستقبل الـ HTTP Requests من المستخدم، وبيرد عليهم بـ HTML, CSS, JavaScript files، أو حتى JSON لو عندك API.
أشهر الأمثلة:
- Apache
- Nginx
- Microsoft IIS
باختصار: أي حاجة لها علاقة بعرض مواقع أو APIs… الـ Web Server هو اللي وراها.
———
📌 الـ Database Server
السيرفر اللي شايل كل الداتا اللي التطبيق محتاجها. سواء عندك Web App أو Mobile App، أكيد فيه Data بتتحفظ وتتعرض وقت الطلب…
أشهر الأمثلة:
- MySQL Server
- PostgreSQL Server
- MongoDB Server
- Microsoft SQL Server
الـ App بيبعت Query والسيرفر ينفذها ويرجعلك الـ Result.
———
📌 الـ File Server
دوره إدارة وتخزين الملفات ومشاركتها بين الأجهزة. زي إنك ترفع صور أو ملفات PDF أو Videos والناس التانية تقدر توصلها.
بيوفر Access Control وPermissions، علشان تضمن إن كل مستخدم له صلاحيات معينة.
الأمثلة: Google Drive, Dropbox, أو أي internal file system في الشركات.
———
📌 الـ Mail Server
ده مسؤول عن إرسال واستقبال الإيميلات. لو جربت تبعت إيميل من Gmail أو من دومين شركتك، فالموضوع ماشي من خلال Mail Servers.
أنواع البروتوكولات اللي بيستخدمها:
- الـ SMTP (للإرسال)
- الـ IMAP / POP3 (للاستقبال)
الأمثلة:
- Microsoft Exchange Server
- Postfix
- Exim
———
📌 الـ Application Server
السيرفر اللي بيشغّل الـ Business Logic بتاعة التطبيق.
يعني مش بيخزن بيانات زي Database Server، ولا بيقدّم HTML زي Web Server، لكنه بينفّذ الكود خلف الكواليس.
لو عندك React Frontend مثلًا و Node.js Backend، فالـ Node Server هو Application Server.
أمثلة تانية:
- Tomcat
- Express.js
- Django
- .NET Core
———
📌 الـ DNS Server
ده السيرفر اللي بيحوّل أسماء الدومينات (زي google.com) إلى IP Addresses.
أشهرهم:
- Cloudflare DNS
- Google DNS (8.8.8.8)
- OpenDNS
من غير DNS Server، كان زمانك بتدخل IP كامل عشان تفتح موقع جوجل أو لينكدإن
———
📌 الـ Proxy Server
السيرفر الوسيط بينك وبين الإنترنت.
لما تبعت Request، هو اللي يستقبلها ويقرر يبعتهالك ولا لا، أو يعدلها أو يخبي الـ IP الحقيقي بتاعك.
مفيد جدًا في الـ Security والـ Caching.
أنواعه:
- Forward Proxy
- Reverse Proxy
———
📌 الـ FTP Server
بيستخدم بروتوكول اسمه File Transfer Protocol لنقل الملفات بين جهازك والسيرفر.
قديم شوية لكنه لسه مستخدم في بعض الشركات. تقدر تستخدمه لرفع أو تحميل ملفات بسهولة.
أمثلة:
- vsftpd
- FileZilla Server
———
📌 الـ Virtual / Cloud Servers
الجيل الجديد من السيرفرات… بدل ما تشتري أجهزة غالية، بتأجر Resources على Cloud Provider زي AWS, Azure, أو Google Cloud.
الجميل في الموضوع إنك بتقدر تعمل Scaling بسهولة جدًا. يعني لو الترافيك زاد، تزود الـ CPU أو الـ RAM وأنت مرتاح.
أنواع السيرفرات دي ممكن تكون Web أو Database أو أي نوع من اللي فوق، بس بتشتغل في بيئة Cloud بدل الـ On-premise.
———
وفقكم الله لكل خير 🌿
❤7👏2💯2