VOL:18 How GitHub Improves Reliability of Code Push Processing
أهلًا وسهلا بكم في العدد الثامن عشر من النشرة الأسبوعية لاقرأ-تِك 🎉
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الثامن عشر من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية, من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة, ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
ازاي الـ UUID بيأثر بالسلب من ناحية الـ Performance مع الـ Scaling
دليلك الشامل لفهم الفرق بين الـ HTTP والـ HTTPS
ملحوظات هامة وتلخيصات لـ EC2 Instance and Storage Types - AWS Practitioner
أهمية التفاوض على عروض العمل
ازاي GitHub حسنوا من الـ Reliability بتاعة الـ Code Push Processing
UUID Performance Nightmare at Scale
الطريقة الشائعة واللي أغلبنا اتعرضلها عشان يقدر يولد Unique IDs عشان نستعملها في الـ Database ونميز الـ Rows كانت الـ UUID أو اللي بنسميه برضو GUID في منتجات Microsoft.
ورغم انها طريقة عملية جدًا لاننا نـ Generate Unique IDs الا ان الكلام ده بيجي معاه مشاكل خطيرة لما نشتغل في Scale كبير خصوصا مع الـ Performance.
ايه هو الـ UUID ؟
هو اختصار للـ Universally Unique Identifier والفرق بينه وبين الـ GUID ان اول كلمة بس هي اختصار لـ Globally.
بيتكون من 128 Bit، وده بيخليه عنده قدرة إنه يولد أكتر من 340 سكستيليون (340 مع 36 صفر جنبها) ID مختلف. فيه أنواع مختلفة من الـ UUID، زي الـ UUIDv1 والـ UUIDv4، وكل نوع ليه طريقة معينة لتوليد الـ IDs.
لكن النوع الأكثر شيوعًا هو الـ UUIDv4 , وهنلاقي انه بيشتمل على رقم 4 في الـ UUID المتولد اصلا واللي بيشير للـ Version.
ازاي بيحصله Generation ؟
بيعتمد على العشوائية التامة على عكس بعض الـ Versions التانية اللي بتعتمد على الـ Timestamp بالاضافة للـ MAC Address على سبيل المثال.
وبالتالي ده بيديله ميزة قوية الا وهي صعوبة تكراره وانه بيتميز بانه فريد بالاضافة لانه مش بيعتمد على أي معلومات شخصية.
أول مشكلة - Write Performance
بما اننا عارفين ان في قواعد البيانات غالبًا الـ Clustered Index واللي بيكون على الـ Primary Key بيكون معموله Index بالـ B+ Tree Data Structure , فلكم ان تتخيلوا ازاي عملية الـ Re-Balancing هتحصل مع كل Write Operation أو بمعنى أدق Insertion عشان تزود Row جديد.
Full Guide Into HTTP vs. HTTPS
طول النهار هتلاقيك بتتعامل مع الـ HTTP Protocol ومش عشان أنت مبرمج ولكن لأنه البروتوكول الأكثر استخدامًا وشهرة حول العالم.
ولأنه حبيبنا بزيادة كمبرمجين فتعالوا نعرف الفرق بينه وبين ال HTTPS ومميزات وعيوب كلا منهما.
ما هو ال HTTP وما هو ال HTTPS؟
ال HTTP هو البروتوكول المسؤول عن نقل البيانات عبر الإنترنت, وقت ما تم تصميمه كان هدفنا ننقل البيانات بس وبنفترض الثقة وحسن النية في مستخدمين الانترنت ولذلك كنا بننقل البيانات عليه ك Plain Text, فلو شبهنا ال HTTP بساعي البريد والبيانات بالرسالة فلو حد قدر يسرق الرسالة من الساعي - أو يوصلها بأي شكل - هيقدر يقرأ ويستخدم المعلومات اللي فيها.
ومن هنا طلع HTTP Secure أو HTTPS Protocol وهو هو ال HTTP ولكن هيعمل Encryption للبيانات المرسلة من خلاله (تشفير الرسائل اللي مع الساعي) وبالتالي لو أي attacker قدر يحصل علي الرسالة هيقرأ كلام غير مفهوم ومش هيقدر يعمله Decryption وكدا عرفنا نحمي المعلومات الهامة اللي بقينا بنشاركها زي الايميلات وكلمات المرور و بطاقات الائتمان.
كيف يقوم ال HTTPS بعمل ال Encryption؟
ال HTTPS يستخدم TLS (SSL) Protocols اللي بتشفر البيانات عن طريق استخدام تقنية تشفير Public Key Cryptography و بتشتغل كالاتي:
ال client بيدخل المتصفح و يطلب website معين عن طريق الرابط مثل
https://eqraatech.com
المتصفح بيبعت لل website server يطلب منه ال SSL Certificate ويعملها Validation اللي بتثبت إنه سيرفر موثوق فيه وبيبعت فيها public key
المتصفح بيستخدم ال public key عشان يعمل تشفير للرسالة اللي بتحتوي علي ال session key
يقوم ال server باستخدام الـ private key عشان يفك تشفير الرسالة ويحصل علي ال session key ويبعت acknowledgment message للمتصفح
دلوقتي المتصفح والسيرفر بينهم session key خاص بيهم ومتأكدين إنه موثوق فيه ويبتدوا ينقلوا البيانات بين بعض بطريقة مشفرة وآمنة ولما توصل عند أي من الطرفين يقدر يعملها decryption باستخدام الـ session key.
EC2 Instance and Storage Types - AWS Practitioner Notes
سلسلة جديدة في الـ AWS - Practitioner , هنشارك معاكوا في السلسلة دي بعض الملحوظات والـ Notes شاملة الـ AWS EC2 Instances والمرتبطة بالـ AWS Practitioner وكمان بعض الـ Labs التطبيقية. فهنتكلم عن الآتي:
Regions
Availability Zones
EC2 Instances and Payment Plans
VPC, Security Groups and Network Interface
ENI, EC2 Placement Group
AMI
EBS Volume and EC2 Instance Storage
EFS vs. EBS
أهمية التفاوض على عروض العمل ؟
أهمية التفاوض علي عرض العمل The Job offer
معظم الناس بتسارع إنها تقبل ال Job offer بعد ما يتبعتلها و بالأخص بعد بحث طويل و انترفيوهات متعددة وبيخافوا لا تفوتهم الفرصة ولكن الموافقة بسرعة في الواقع بتخسرك Benefits مش العكس!
الأغلبية مش بتحب التفاوض علي المرتب و بالأخص السيدات في سوق العمل خوفًا من انها تفقد الفرصة ولكن دي فكرة مغلوطة. الشركة بتكون صرفت كتير علي عملية الانترفيوهات لحد ما وصلت لموظف مناسب ليها فلما تعرض عليهم مرتب اعلي هيردوا ب:
1. الإيجاب: و كدا تكون حصلت علي مرتب أعلي ✅
2. الرفض للزيادة و التمسك بالعرض الأصلي: و دا غالبًا لأن الشركات بتكون محددة budget range لكل وظيفة و ميقدروش يعطوا راتب أكبر من كدا
3. التفاوض: و في الحالة دي انت اللي كسبان دايمًا طالما المرتب الأصلي معدي المتوسط اللي انت شايفه مناسب
و 90% من الشركات بتكون عاملة حسابها أصلاً علي فقرة التفاوض فممكن تبتدي بأنها تعرض The minimum of the budget range اللي يقدروا يقدموه 🤷♀️
وهنا نأكد انك لازم تكون عامل بحث عن متوسط المرتبات ودا بيتأثر بعدة عوامل هامة زي:
1. سنين الخبرة و التخصص
2. حجم الشركة اللي رايحلها لأن أكيد مرتب ال Mid Software engineer في شركة Startup مش زي ال FAANG مثلاً.
3. متوسط المرتبات بالنسبة للبلد فلمصر تقدر تشوف دا من egytech.fyi في مصر و بالنسبة لخارج مصر تقدر تستعين ب glassdoor, blind.
معرفتك بالمتوسط الاقرب للفرصة هتخلي تفاوضك منطقي وبعيد عن المبالغات.
المرة الجاية ان شاء الله هنتكلم عن نصائح مهمة أثناء التفاوض وإزاي تحضرله
How GitHub Improves Reliability of Code Push Processing
قامت GitHub بعمل Rollout لأكتر من Technical Upgrade وده بهدف التحسين من الـ Reliability والكفاءة الخاصة بعملية الـ Code Pushes.
والـ Code Pushes هي أكيد واحدة من العمليات الشائعة والمتكررة اللي كلنا بنقوم بيها بشكل دوري. والحركة اللي عملوها دي هدفها معالجة أي مشاكل محتملة وانهم يوفروا تجربة أكثر سلاسة لأي حد بيعمل Code Push على GitHub.
فتعالوا نشوف ايه التحسينات اللي فريق مهندسين GitHub خدها عشان يحسن من كفاءة عملية الـ Code Push.
ايه اللي بيحصل لما بنعمل Code Push ؟
الاجابة المنطقية واللي كتير عارفينها ان الـ Repository بالتأكيد هيبقى فيها الـ Updates بتاعتي اللي انا عملتلها Push , ولكن رغم ان الكلام ده صحيح الان ان فيه مجموعة من العمليات اللي بتحصل كمان واحنا ممكن مانكونش على دراية كاملة بيها.
ودي بعض الأمثلة للعمليات اللي بتحصل لما بنعمل Push لأي Code على GitHub :
بيحصل مزامنة بين الـ Pull Requests وبعضها , وده معناه ان الـ Diffs والـ Commits اللي موجودين في الـ Pull Request بيتأثروا بالتغييرات اللي بتطرأ من الـ Code Push اللي عملناه
بيتم عمل Dispatching للـ Push Webhooks
بيتم عمل Triggering للـ Workflows
لو عملنا Push لـ App Configuration File , التطبيق هيتم عمل ليه Installing بشكل اوتوماتيك على الـ Repository
بيتم نشر الـ GitHub Pages
وغيرهم كتير من العمليات اللي بتحصل واحنا ممكن ما نكونش على دراية كافية بيها.
فلما بتيجي تعمل Code Push بيكون فيها ما يقرب من 60 عملية مختلفة من الـ Logic مرتبطين تقريبًا بحوالي 20 Service مختلفة وكلهم بيحصلهم Run بعد ما تعمل Code Push وده طبعا في الـ Monolith GitHub اللي هم مصممينه.
فزي ما احنا شايفين احنا عندنا Monolith Application وفيه Sequential Operations بتحصل تباعًا مع كل Code Push بيتم.
ايه هي المشاكل ؟
المشكلة ان لحد قبل ما يحصل أي تحسين في الـ System ده , كان الموضوع كله قايم على Background Job ضخمة جدًا , كل لما يحصل Notify للـ Ruby and Rails GitHub Monolith بأن حصل عملية Code Push, كان بيحصل عملية Enqueue لـ Job ضخمة اسمها RepositoryPushJob , والـ Job دي هي اللي كان فيها الـ Logic الضخم اللي اتكلمنا عنه واللي فيه أكتر من 60 Logic.
وبالتأكيد مع وجود كمية كبيرة من الـ Processing Logic اللي شايلاه وحجمها وتعقيدها , كل ده كان بيؤدي إلى مشاكل كتيرة.
وده شكل الـ Sequential Operations اللي بتتم بعد ما يحصل Code Push.
Enormous Job and Retry
حجم الـ RepositoryPushJob الضخم خلى بالتبعية ان بعض العمليات أثناء ما بيحصل Processing Logic لو فيه مشكلة حصلت ان صعب يحصلها Retry مرة تانية بشكل سليم. وبالتالي لو حصل أي مشكلة في النص في أي Processing Logic هنضطر اننا نعيد الموال ده تاني من اول وجديد من أول Processing Logic تاني.
وبالتأكيد مش هيكون ده خيار مناسب لبعض المهام زي :
كتابة الـ Push Records في الـ Database واللي هينتج عنه بالتأكيد Duplicated Entries
ارسال الـ Push Webhooks هي عملية Time Sensitive والمفترض اننا منحاولش نعيد تنفيذها لفترة طويلة بعد ما الـ Code Push يكون حصل
مش حاجة كويسة اننا نبعت برضو أكتر من مرة نفس الـ Webhook
Tightly Coupling and Catching Failures
بعض الـ Processing Logic اللي موجود قدر انه ينجو من الـ Failures اللي ممكن تحصل , ولكن احيانا كتير بسبب طبيعة الـ RepositoryPushJob فيه بعض العمليات اللي بتحصل في الأول واللي مش معمولها Handling بشكل كويس من ناحية الـ Failures وخصوصا ان زي ما وضحنا في صعوبة الـ Retries , ده بيؤدي ان في النهاية الـ Job كلها بتفشل تباعًا حتى لو فيه Error Handling في باقي الـ Processing Logic.
فبمجرد ما أول Failure يحصل مش معموله Handling بيحصل Retry للـ Job كلها مع بعض يا اما بتفشل كلها. وده لان كل الـ Steps اللي بتحصل متأخر واللي ممكن تكون مهمة جدًا هي مرتبطة ارتباط وثيق بالـ Initial Steps اللي في البداية وده طبعا بيخلي فيه اعتمادية عالية بينهم.
Bad Latency
زي ما شوفنا بسبب الاعتمادية العالية بين الـ Steps وبعضها لاننا شغالين Sequential , فأصبح دلوقتي لازم على كل الـ Steps اللي موجودة في الآخر انها تستنى كل اللي قبلها يتنفذ عشان تتنفذ , ومع الـ Scale أكيد كل ده كان بيقدم Latency بتوصل احيانا لـ ثانية وأكتر وده طبعا بيقابل المطور وهو بيعمل Push , أو مستني يحصل Pull Request Synchronization.
تقدروا دلوقتي تشتركوا في اقرأ-تِك وتنضموا لمجتمع مهتم بالقراءة في هندسة البرمجيات بـ 50 جنيه بس 🎉
وتستمتعوا بحرية كاملة في قراءة المقالات في مواضيع مختلفة بجودة عالية زي:
Data Structure & Algorithms , System Design , Distributed Systems , Micro-Services, Clean Code, Refactoring, Databases , Web Development, DevOps وغيرهم كتير باللغة العربية!
بالاضافة لمحتوى ورقة وقلم اللي بنشرح فيه مفاهيم برمجية بطريقة سهلة وباستعمال صور توضيحية 🚀
ولو فيه مشاكل في الدفع الأونلاين فمتاح دلوقتي الاشتراك من خلال InstaPay و VodafoneCash 💪
تقدروا تتواصلوا معانا من خلال الـ WhatsApp Business أو من خلال الرسايل على مواقع التواصل الاجتماعي أو من خلال البريد الالكتروني contact@eqraatech.com 😍
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
Refactoring is like dental hygiene for software engineers. Skip it, and you’ll have a lot more to worry about than just a bad smell.
