DevGuide

مراجعة سريعة عن الـ OOP 💯 https://youtu.be/dZh68SpsgoI . . #software_engineering

AWS Cloud Training Full Course for Beginners (Better Than Any Bootcamp) . . - AWS First Principles - Cloud Architecture Fundamentals - Cloud Infrastructure Fundamentals - AWS Case Studies - Cursor & AI Agents AWS - Cloud Security Q&A - Jobs & Careers with Gaz - Interviews & Career Q&A ——— 📌 Course Link: https://youtu.be/EHUCb92gUg0 ——— #devops

The Complete Backend Developer Roadmap [2026] 🚀 https://substack.com/@arslanah/note/p-179838506 . . #backend

أهم 10 مهارات لمهندس DevOps في 2026 https://cloudnativebasecamp.com/feed/devops-engineer-skills-2026

أتفق 💯

Top 5 System Design Algorithms 💯 . . #system_design

📌 FTP Server ده سيرفر بيدعم بروتوكول FTP (File Transfer Protocol)، اللي بيُستخدم لنقل الملفات بين الأجهزة والسيرفرات. ممكن تستخدمه لرفع أو تحميل ملفات، ولسه موجود في بعض الأنظمة والشركات، رغم إن بروتوكولات أحدث وأكثر أمانًا بقت شائعة. أمثلة: - vsftpd - FileZilla Server ملحوظة: FTP التقليدي مش بيشفّر البيانات، بما فيها بيانات تسجيل الدخول، علشان كده SFTP أو FTPS بيكونوا أنسب لما تحتاج نقل ملفات بشكل آمن. ——— 📌 Virtual Servers & Cloud Servers بدل ما تشتري أجهزة فعلية وتديرها بنفسك، تقدر تستخدم Virtual Machines أو تستأجر موارد حوسبة من Cloud Providers زي: - AWS - Microsoft Azure - Google Cloud الـ Virtual Server بيكون بيئة افتراضية بتشتغل على موارد جهاز فعلي، أما الـ Cloud Server فهو سيرفر متاح من خلال منصة سحابية، وغالبًا بيكون مبني على تقنيات الـ Virtualization. الميزة إنك تقدر تزود أو تقلل الموارد حسب احتياجك، وفي بعض الأنظمة تقدر تفعّل Auto Scaling علشان الموارد تزيد أو تقل تلقائيًا حسب الترافيك. لكن الـ Scaling مش دايمًا تلقائي أو سهل؛ ده بيعتمد على تصميم التطبيق وإعدادات البنية التحتية والتكلفة. والأهم إن الأنواع دي مش بديلة للأنواع اللي فوق؛ لأن السيرفر السحابي نفسه ممكن يكون Web Server أو Database Server أو Application Server أو غيره. ——— #backend

دردشة سريعة عن أنواع السيرفرات 💯 . . أغلبنا أول ما بيسمع كلمة Server بييجي في باله جهاز كبير في غرفة مكيفة، شغال 24 ساعة ومليان لمبات بتنور... بس الحقيقة إن السيرفر مش لازم يكون جهاز ضخم… ممكن يكون مجرد Software أو Virtual Machine بيقدّم خدمة معينة. الـ Server ببساطة هو جهاز (أو برنامج) بيستقبل Requests من أجهزة تانية اسمها Clients، وبيرد عليها بـ Responses. زي ما الـ Browser بيبعت Request لموقع معين، والسيرفر بيرد عليه بالصفحة المطلوبة. لكن السيرفرات مش كلها زي بعض… كل نوع له وظيفة مختلفة حسب الـ Use Case بتاعته. ——— 📌 Web Server ده من أشهر أنواع السيرفرات، وهو اللي بيستقبل HTTP Requests، وبيقدّم ملفات زي HTML, CSS, JavaScript، أو بيمرّر Requests للـ Application Server اللي ممكن يرجّع Responses بصيغة JSON للـ APIs. أشهر الأمثلة: - Apache - Nginx - Microsoft IIS باختصار: الـ Web Server مسؤول عن استقبال طلبات HTTP والتعامل معاها، سواء بتقديم المحتوى مباشرة أو بتمرير الطلبات لخدمات تانية. ——— 📌 Database Server ده السيرفر المسؤول عن تخزين البيانات وإدارتها وإتاحتها للتطبيقات عند الحاجة. سواء عندك Web App أو Mobile App، غالبًا هتحتاج Database تحفظ فيها البيانات وتسترجعها وقت الطلب. أشهر الأمثلة: - MySQL Server - PostgreSQL - MongoDB - Microsoft SQL Server الـ App بيبعت Query، والـ Database Server بينفّذها ويرجّع النتيجة حسب نوع قاعدة البيانات والعملية المطلوبة. ——— 📌 File Server دوره تخزين الملفات وتنظيمها ومشاركتها بين المستخدمين والأجهزة، مع إمكانية تحديد Access Control وPermissions علشان كل مستخدم يوصل للملفات المسموح له بيها فقط. زي إنك ترفع صور أو ملفات PDF أو Videos وتسمح لمستخدمين معينين بالوصول ليها. أمثلة: - Windows File Server - Samba - خدمات تخزين ومشاركة الملفات زي Google Drive وDropbox، واللي بتعتمد على بنية تخزين وخدمات متعددة، مش مجرد File Server تقليدي. ——— 📌 Mail Server ده المسؤول عن إرسال واستقبال الإيميلات وتوجيهها بين أنظمة البريد الإلكتروني. لو بعت إيميل من Gmail أو من دومين شركتك، فالعملية بتتم من خلال Mail Servers وبروتوكولات مختلفة. أهم البروتوكولات: - الـ SMTP: لإرسال الإيميلات ونقلها بين خوادم البريد. - الـ IMAP: للوصول للإيميلات ومزامنتها مع السيرفر. - الـ POP3: لاسترجاع الإيميلات من السيرفر. أمثلة: - Microsoft Exchange Server - Postfix - Exim ——— 📌 Application Server ده اللي بيشغّل الـ Business Logic الخاصة بالتطبيق، وبيعالج الطلبات وينفّذ العمليات المطلوبة، وممكن يتواصل مع Database أو خدمات خارجية. لو عندك React Frontend وNode.js Backend، فالـ Backend ممكن يشتغل كـ Application Server، وينفّذ الـ Business Logic ويرجّع البيانات للـ Frontend. أمثلة وتقنيات ممكن تُستخدم في بناء Application Servers: - Node.js - Java with Apache Tomcat - Python with Django - ASP.NET Core ملحوظة: Express.js وDjango Frameworks بتساعدك تبني تطبيقات Backend، لكنها مش سيرفرات مستقلة بحد ذاتها. ——— 📌 DNS Server ده المسؤول عن التعامل مع استفسارات DNS، اللي بتساعد في تحويل أسماء الدومينات (زي google.com) إلى IP Addresses، علشان الأجهزة تقدر توصل للخدمات المطلوبة. من أشهر الخدمات: - Google Public DNS - Cloudflare DNS - OpenDNS الخدمات دي بتعمل دور DNS Resolvers، يعني بتساعد جهازك في الوصول للـ IP المرتبط بالدومين عن طريق الاستعلام عن سجلات DNS. وفيه كمان Authoritative DNS Servers، ودي المسؤولة عن تقديم سجلات الدومين الأصلية، زي سجلات الـ A وMX. من غير DNS، كان هيبقى الوصول للمواقع أصعب بكتير، لأنك هتحتاج تعرف عناوين IP بدل أسماء الدومينات في الحالات اللي بتعتمد على DNS. ——— 📌 Proxy Server ده سيرفر وسيط بين الـ Client والوجهة اللي بيحاول يوصل ليها. فيه نوعين أساسيين: - الـ Forward Proxy: بيشتغل نيابةً عن الـ Clients، وممكن يُستخدم للتحكم في الوصول للإنترنت أو تطبيق سياسات الأمان. - الـ Reverse Proxy: بيستقبل الطلبات نيابةً عن الـ Backend Servers، وممكن يوزّع الترافيك بينها، ويعمل Caching، وينفّذ بعض وظائف الحماية. ومن أشهر استخداماته تحسين الأمان والأداء وإدارة حركة المرور. ——— #backend [ بقية المنشور 👇🏻 ]

https://designgurus.substack.com/p/15-system-design-principles-to-remember #system_design

دردشة سريعة عن الـ RFC 💯 . . لو عندك تغيير كبير في الـArchitecture، أو تحسين في الأداء، أو Refactoring، أو Feature جديدة، القرار مش بيبدأ بالتنفيذ وكتابة الكود علطول. الموضوع بيبدأ بفهم المشكلة، مناقشة الحلول الممكنة، ومراجعة الـTrade-offs مع التيم. وهنا بييجي دور الـRFC. ——— 📌 يعني إيه RFC؟ الـRFC عبارة عن مستند مكتوب بيشرح فيه صاحب الفكرة كل حاجة عن الـFeature أو التغيير اللي عايز يعمله: من الـContext، والـProblem اللي بيحاول يحلها، لحد الـProposed Solution، والـAlternatives، والـTrade-offs. الهدف إنك تشارك طريقة تفكيرك مع التيم، علشان الكل يقدر يراجع الفكرة ويناقشها من وجهات نظر مختلفة قبل اتخاذ القرار. ——— 📌 ليه مهم نكتب RFC؟ فيه 3 أسباب رئيسية بتخلي الـRFCs مهمة جدًا: 1- بتقلل القرارات الفردية غير المدروسة: بدل ما يتاخد قرار تقني مهم بشكل فردي، الـRFC بتوفر مساحة منظمة لمراجعة الفكرة ومناقشة الـApproach قبل التنفيذ. 2- بتوثّق القرارات التقنية: بعد 6 شهور لما حد يسأل: “ليه اخترنا نستخدم Redis هنا؟” تقدر ترجع للـRFC وتشوف الـReasoning والـTrade-offs اللي أدت للقرار، بدل ما تعتمد على الذاكرة. 3- بتحسّن التعاون بين الفرق: الـFrontend و Backend و DevOps، وغيرهم يقدروا يفهموا التغيير المقترح، ويشاركوا بالـفيدباك قبل التنفيذ، خصوصًا لما القرار يكون له تأثير على أكتر من جزء في النظام. ——— 📌 إزاي تكتب 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. ——— 📌 نصائح مهمة وأنت بتكتب RFC: - خليك واضح وبسيط، بلاش مصطلحات تقيلة من غير داعي. - استخدم Bullet Points علشان الناس تقرأ بسهولة. - لو فيه Diagrams أو Code Snippets، ضيفهم علشان تسهّل الفهم. - خليك مرن في النقاش... الهدف مش إن فكرتك تتنفذ، الهدف إن التيم يوصل لأفضل قرار ممكن. ——— مش مهم تكتب RFC مثالية من أول مرة، المهم إنك تبدأ، ومع الوقت هتتعلم إزاي توصل فكرتك بأوضح وأقوى طريقة ممكنة.

https://youtu.be/nqK3oJ682mQ?si=gl-NPGGHA4o3Yxk_ #kotlin

دردشة سريعة عن الـ WebRTC ⚡️ . . إزاي مكالمة فيديو بين شخصين في بلدين مختلفين بتحصل في أجزاء من الثانية، بالصوت والصورة في نفس اللحظة، رغم تعقيدات الإنترنت؟ إزاي الـ browser يقدر يلتقط الصوت والفيديو، ينقلهم للطرف الآخر، ويحافظ على تجربة Real-Time بأقل قدر ممكن من الـ latency؟ هنا بييجي دور الـ WebRTC. تقنية مكّنت تطبيقات الويب من التواصل المباشر لحظيًا بالصوت والفيديو والبيانات، وخلّت الـ browser نفسه قادر يبني تجارب Real-Time من غير الحاجة لبنية تقليدية معقدة لكل حالة استخدام. تعال ندردش شوية عن الـ WebRTC ونتعرف على أهم المكونات والآليات اللي بتخلي الـ Real-Time Communication ممكنة... ——— الـ WebRTC (Web Real-Time Communication) هي مجموعة من المعايير والـ APIs مفتوحة المصدر بتسمح لمتصفحات الويب والتطبيقات إنها تعمل مشاركة الصوت والصورة والبيانات بشكل Real-Time، وغالبًا بشكل Peer-to-Peer، من غير ما تحتاج سيرفر وسيط لنقل الـ media والـ data في الحالات اللي يكون فيها الاتصال المباشر ممكن. لكن في بعض الحالات، زي وجود NAT أو Firewall يمنع الاتصال المباشر، ممكن نحتاج TURN Server يعمل كـ Relay وينقل البيانات بين الطرفين. يعني ببساطة: المتصفح بتاعك يقدر يكلم متصفح شخص تاني بشكل مباشر كأنهم في مكالمة تليفون، لكن عن طريق الإنترنت. ——— 📌 إزاي الـ WebRTC بيشتغل؟ الموضوع فيه شوية تفاصيل تقنية مهمة: 1- الـ Signaling - قبل ما يحصل أي اتصال، المتصفحين لازم يتبادلوا المعلومات المطلوبة لإنشاء الاتصال، زي الـ SDP Offer/Answer وICE Candidates. - وده بيتم من خلال أي وسيلة اتصال زي WebSocket أو HTTP. - الـ WebRTC نفسه مش بيحدد أو يوفر طريقة الـ Signaling، أنت اللي بتبني الـ Signaling Layer. دور الـ Signaling ببساطة هو مساعدة الطرفين على اكتشاف بعضهم وتبادل معلومات الـ negotiation قبل إنشاء الاتصال الفعلي. 2- الـ NAT Traversal علشان فيه راوترات وFirewalls وNAT، فالـ Peer-to-Peer connection مش دايمًا بيكون ممكن بشكل مباشر. وهنا بييجي دور STUN وTURN: - الـ STUN: بيساعد الـ browser في معرفة الـ public IP/port الظاهرين له من خارج شبكة الـ NAT، واكتشاف إمكانية إنشاء اتصال مباشر. - الـ TURN: لو الاتصال المباشر فشل، بيعمل Relay للـ traffic بين الطرفين. والـ ICE هو اللي بيجمع ويفاضل بين طرق الاتصال المختلفة ويحاول اختيار الـ candidate pair المناسب لإنشاء الاتصال. 3- الـ Media & Data Channels الـ WebRTC بيوفر طريقتين أساسيتين للتواصل: - الـ MediaStream: بيمثل الـ audio/video tracks اللي بيتم التقاطها وإضافتها للـ "RTCPeerConnection" علشان يتم إرسالها واستقبالها. - الـ RTCDataChannel: لنقل أي نوع من الـ real-time data بين الطرفين، زي الشات، الـ game state، أو الملفات. 4- الـ Protocols الـ WebRTC بيعتمد على مجموعة من البروتوكولات والآليات المهمة، منها: - الـ SRTP: لتأمين ونقل الـ audio/video. - الـ DTLS: لتأمين الـ transport، وبيُستخدم مع الـ Data Channels. - الـ ICE: لاكتشاف واختيار أفضل مسار ممكن للاتصال بين الطرفين، باستخدام STUN وTURN عند الحاجة. ——— واحدة من أقوى مميزات WebRTC إنه Secure by Default: - الـ WebRTC components بتستخدم التشفير، والـ Data Channels مؤمّنة باستخدام DTLS. - الـ Media يتم نقله باستخدام SRTP، وبالتالي الاتصالات مش بتعتمد على إرسال الـ audio/video كـ plain text عبر الشبكة. ——— 📌 أمثلة عملية بتستخدم WebRTC - مكالمات فيديو وصوت (Zoom, Google Meet, WhatsApp, Messenger). - الـ P2P File Sharing ونقل الملفات مباشرة بين المستخدمين. - الـ Online Gaming لتبادل الـ game state والـ real-time data بين اللاعبين. - الـ Screen Sharing وRemote Collaboration. - الـ Remote Desktop Applications. ——— 📌 مميزات WebRTC ✅ تواصل Real-Time بزمن استجابة منخفض، حسب جودة الشبكة وظروف الاتصال. ✅ مفتوح المصدر ومدعوم على نطاق واسع في المتصفحات الحديثة مثل Chrome وFirefox وSafari وEdge. ✅ مناسب لمجموعة كبيرة من التطبيقات اللي محتاجة Real-Time Communication، سواء Audio/Video أو Data Sharing. ——— #frontend

Viewport units in CSS They are relative units that measure as a percentage of the browser's viewport dimensions. --- #frontend

مصطلحات مهمة في عالم الـ System Design 💯 (١٣) . . إزاي نتعامل مع ملايين أو مليارات الـRecords؟ وإزاي نحتفظ بتاريخ كل تغيير حصل على الـData؟ وإيه اللي بيحصل لما الـApplication نفسه يتوزع على أكتر من Server؟ ——— 📌 Data Partitioning تخيل عندك Database فيها مليارات الـUsers. لو كل الـData موجودة في مكان واحد، مع الوقت الـDatabase ممكن تبقى كبيرة جدًا، والـQueries عليها تبقى تقيلة، وحتى الـScaling يبقى أصعب. هنا بييجي Data Partitioning. الفكرة ببساطة إننا نقسم الـData لأجزاء أصغر، بحيث يمكن إدارتها أو تخزينها بشكل منفصل. مثلًا، ممكن نقسم الـUsers حسب الـCountry: Egypt → Partition 1 Saudi Arabia → Partition 2 UAE → Partition 3 أو نقسم الـOrders حسب السنة: 2024 → Partition 1 2025 → Partition 2 2026 → Partition 3 المهم إن اختيار طريقة التقسيم يكون مبني على طريقة استخدام الـData والـQueries اللي بننفذها عليها. لأن اختيار الـPartition Key بشكل غير مناسب ممكن يؤدي إلى توزيع غير متوازن للـData والـLoad، وظهور مشاكل زي Hot Partitions. وده ممكن يساعدنا في توزيع الـLoad، وتحسين بعض الـQueries، وإدارة الـData على نطاق أكبر. لكن فيه نقطة مهمة: الـData Partitioning هو مفهوم عام لتقسيم الـData إلى أجزاء أصغر. أما Sharding اللي تكلمنا عنه قبل كده، فهو شكل من أشكال الـPartitioning، وغالبًا بيستخدم لتوزيع الـData على أكثر من Shard، وغالبًا على Nodes أو Databases مختلفة. طيب، إحنا قسمنا الـData واتخزنت بشكل أفضل. لكن فيه سؤال مختلف: هل لازم الـDatabase تحتفظ فقط بالـCurrent State للـData؟ ولا ممكن نخزن كل التغييرات اللي حصلت عليها من البداية؟ ——— 📌 Event Sourcing في الـSystems العادية، غالبًا بنخزن الـCurrent State. مثلًا عندنا Account رصيده: Balance = $500 إحنا بنخزن إن الرصيد الحالي هو $500. لكن في Event Sourcing، بنفكر بطريقة مختلفة. بدل ما نخزن النتيجة النهائية فقط، بنخزن كل الـEvents اللي أدت للنتيجة دي. مثلًا: Deposit $1000 Withdraw $300 Withdraw $200 ومن الـEvents دي نقدر نعرف إن الـCurrent Balance هو $500. الميزة هنا إننا مش بس عارفين الحالة الحالية، لكن عندنا تاريخ كامل للتغييرات اللي حصلت. وده مفيد جدًا في أنظمة محتاجة Audit Trail أو محتاجة نعرف إزاي الـData وصلت للحالة الحالية. لكن طبعًا فيه Trade-offs. تخزين كل الـEvents ممكن يخلي الـData تكبر جدًا، وكمان قراءة الـCurrent State ممكن تحتاج إعادة بناء الحالة من عدد كبير من الـEvents، لذلك الأنظمة اللي بتستخدم Event Sourcing ممكن تستخدم حلول إضافية زي Snapshots لتقليل تكلفة إعادة بناء الـState. طيب، لحد هنا بنتكلم عن تقسيم الـData وتخزين التغييرات. لكن إيه اللي هيحصل لو النظام نفسه بقى متوزع على أكتر من Server؟ ——— 📌 Distributed Systems تخيل إن عندك Application شغال على Server واحد. كل حاجة موجودة في مكان واحد: Client → Server → Database الموضوع بسيط نسبيًا. لكن لما الـApplication يكبر، ممكن نبدأ نوزع أجزاء النظام على Servers مختلفة. كل Service ممكن تكون شغالة على أكتر من Server، وممكن الـServers تكون موجودة في أماكن مختلفة. هنا بقى عندنا Distributed System. ببساطة، هو System مكوّن من أكتر من Computer أو Node، بيتعاونوا مع بعض علشان يقدّموا وظيفة واحدة للمستخدم. وده ممكن يساعدنا في تحقيق Scalability و Availability بشكل أفضل، حسب تصميم النظام، لأننا مش بالضرورة معتمدين على Server واحد فقط. لكن في المقابل، النظام بيبقى أصعب بكتير. في النظام البسيط، لو Function استدعت Function تانية، أنت عارف إنها هترجعلك نتيجة. لكن في الـDistributed System، ممكن الـRequest يتبعت لـService تانية، والـNetwork يحصل فيه مشكلة، أو الـServer يقع، أو الـResponse يتأخر. وفوق ده كله، ممكن يكون عندك أكتر من Server وكل واحد عنده نسخة مختلفة من الـData في نفس اللحظة. وده بيخلينا نواجه مشاكل جديدة زي: - Consistency - Failures - Network Partitions - Latency - الـCoordination بين الـNodes وده بالضبط اللي بيخلي Distributed Systems مجال مختلف وأصعب من مجرد تشغيل Application على أكتر من Server. ——— 💡 الخلاصة • الـData Partitioning: تقسيم الـData لأجزاء أصغر علشان نقدر نديرها ونخزنها ونوزعها بشكل أفضل. • الـEvent Sourcing: تخزين الـEvents اللي حصلت بدل الاعتماد على الـCurrent State فقط. • الـDistributed Systems: نظام مكوّن من Nodes متعددة بتتعاون مع بعض لتقديم وظيفة واحدة. ——— #system_design