دردشة سريعة عن الـ RFC 💡
.
.
في أوقات كتير بيكون عندك فكرة حلوة — ممكن تكون تحسين في الأداء، refactor، أو feature جديدة —
بس أول ما تحاول تشرحها للتيم، الحوار بيبقى عشوائي، والناس بتفهم نص الفكرة أو ترفضها قبل ما تستوعبها أصلًا...

علشان كده التيمات في الشركات الكبيرة والمتوسطة بتستخدم حاجة اسمها RFC – Request For Comments،
ودي ببساطة طريقة منظمة بتخليك تشرح فكرتك بالتفصيل، وتخلي الكل يشارك رأيه قبل التنفيذ.

———

📌 يعني إيه RFC؟

الـ RFC عبارة عن مستند مكتوب بيشرح فيه صاحب الفكرة كل حاجة عن الـ feature أو التغيير اللي عايز يعمله:
من الـ context، والـ problem اللي بيحاول يحلها، لحد الـ proposed solution، والـ alternatives، والـ trade-offs.

الهدف إنك تشارك التفكير بتاعك مع التيم علشان الكل يقدر يناقش الفكرة من وجهات نظر مختلفة — هندسية، product، أو حتى business.

———

🎯 ليه مهم نكتب RFC؟

فيه 3 أسباب رئيسية بتخلي الـ RFCs مهمة جدًا في أي تيم:

1- بتمنع القرارات الفردية العشوائية:
بدل ما أي حد يغيّر في الـ codebase أو الـ system architecture بمزاجه، الـ RFC بتخلي القرار جماعي ومدروس.

2- بتوثّق القرارات التقنية:
بعد 6 شهور لما حد يسأل “ليه اخترنا نستخدم Redis هنا؟”، تقدر ترجع لـ RFC وتشوف reasoning واضح بدل ما تعتمد على الذاكرة.

3- بتحسّن التعاون بين الفرق:
الـ frontend، backend، DevOps... الكل بيبقى عارف الاتجاه العام للـ system وبيشارك في القرار.

———

إزاي تكتب RFC محترم؟ 🤔

الـ structure مش ثابت، بس فيه فورمات متعارف عليه وبيخلي الـ RFC واضح ومنطقي.

📍 الـ Title + Summary
ابدأ بعنوان بسيط وواضح يشرح هدف الـ RFC.

مثلًا:

RFC: Introduce caching layer for product API

وبعدها اعمل Summary صغير بيشرح في جملة أو اتنين الفكرة العامة:

We propose adding a Redis-based caching layer to reduce response time for frequently accessed endpoints.

📍 الـ Context / Background
احكي باختصار الـ situation الحالي وليه محتاجين التغيير.

مثلًا:

Currently, our product endpoints are hitting the database directly, leading to high latency during peak hours.

الفكرة إنك تدي القارئ صورة كاملة عن المشكلة قبل ما يدخل في الحل.


📍 الـ Problem Statement
وضح المشكلة الأساسية اللي بتحاول تحلها بالأرقام لو أمكن.

مثلًا:

Average response time increased from 300ms to 900ms under load.

دي بتخلي الـ RFC منطقي ومبني على data.


📍 الـ Proposed Solution
اشرح الـ approach اللي ناوي تستخدمه، ليه اخترته، وإزاي هيشتغل.

مثلًا:

We'll use Redis to cache product data for 5 minutes. The cache will be invalidated on product update events.

ممكن كمان تضيف diagram بسيط أو pseudo code لو محتاج توضح flow معين.


📍 الـ Alternatives Considered
بيوضح إنك مش اخترت الحل عشوائي.

مثلًا:

Considered using in-memory cache, but it doesn’t scale horizontally. Redis fits better for distributed systems.

📍 الـ Trade-offs
قول بصراحة إيه العيوب اللي ممكن تحصل.

Cache invalidation adds complexity and increases operational overhead.

📍 الـ Impact / Risks
قول إيه اللي ممكن يتأثر في الـ system.

Adding caching could lead to stale data if invalidation fails.

📍 الـ Open Questions
ممكن تسيب في الآخر شوية أسئلة مفتوحة علشان التيم يناقشها:

Should we cache all products or only top 100 requested ones?

📍 الـ Next Steps
اختصر إيه اللي هيحصل بعد الموافقة.

If approved, implementation will start in sprint 25, and metrics will be collected after deployment.

———

💡 نصائح مهمة وأنت بتكتب RFC:

- خليك واضح وبسيط، بلاش مصطلحات تقيلة من غير داعي.
- استخدم bullet points علشان الناس تقرأ بسهولة.
- لو فيه diagrams أو code snippets، ضيفهم علشان تسهل الفهم.
- خليك مرن في النقاش... الهدف مش إن فكرتك تتنفذ، الهدف إن نختار أفضل حل.

———

مش مهم تكتب RFC مثالية من أول مرة، المهم إنك تبدأ، ومع الوقت هتتعلم إزاي توصل فكرتك بأوضح وأقوى طريقة ممكنة 🔥

———

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

Harvard's "Advanced Algorithms"

📽 Videos: https://youtube.com/playlist?list=PL2SOU6wwxB0uP4rJgf5ayhHWgw7akUWSf

📷 Notes: https://people.seas.harvard.edu/~cs224/fall14/lec.html

🚀 C# Mastery Learning Path

A comprehensive guide to mastering C#, .NET, and related technologies from beginner to advanced level.

https://github.com/Metigator

دردشة سريعة عن الـ 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: إزاي نضمن إن النظام يفضل شغال حتى لو حصلت أعطال في بعض الأجهزة.

———

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

دردشة سريعة عن وظيفة 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 ممتازة.

———

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

Types of keys in SQL 💯