لا تنسوا أهلنا من صالح الدعاء، ‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد المائة من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

حكاية 100 عدد من نشرة اقرأ-تِك 🎉

كتابة: محمود يُوسف

انا مش مصدق اني بكتب حاليًا العدد الـ 100 واللي مفروض هينزل بكرة يوم السبت كالعادة الساعة 11 بتوقيت القاهرة ، مش مصدق إن اقرأ-تِك وصلت للشكل الحالي ده .. أسابيع وشهور بتعدي قصادي حاليًا ومشاعر مختلفة عن كل عدد كنت بكتبه وكنت بحاول متأخرش في كتابة الأعداد علشان لو فيه حد بيستنى العدد ينزل ..

كنت دايمًا في الاجازات اللي بسافر فيها بحاول اجهز مثلًا بالـ 3 أعداد مرة واحدة واضغط نفسي واعملهم Scheduling علشان مفوتش الفرصة على الناس اللي بتستنى ، وماكونش مقصر معاهم .. ذكريات بتعدي قصادي حاليًا وانا فعلًا مش عارف أوصفها ولكن كل ده بفضل ربنا .. فاللهم لك الحمد والشكر .. وبفضل زوجتي ورفيقة الكفاح في اقرأ-تِك وبفضل تشجيعكم ❤️

الحكاية من الأول

الحكاية بدأت تقريبًا من شهر مايو سنة 2024، لما حبينا إن يكون فيه نشرة أسبوعية بنتكلم فيها عن مواضيع متنوعة في هندسة البرمجيات بشكل بسيط وبرسومات توضيحية كل أسبوع.

وكان الهدف الرئيسي لبناء النشرة الأسبوعية هو حرصنا على وجود نشرة مجانية نقدر نساعد من خلالها في إثراء المحتوى التقني العربي وتشجيع الجميع على التعلم من خلال القراءة بجانب منصة اقرأ-تِك ، والمميز في النشرة هو اختلاف وتنوع مواضيعها اللي ممكن تكون فرصة ذهبية لقراءة مواضيع مختلفة وبوتيرة مستمرة كل أسبوع.

التطورات اللي النشرة مرت بيها

في البداية الموضوع كان موتر خصوصًا إن مكنش فيه مشاهدات كتير ولا مشتركين في النشرة .. ولكن حماسنا كان أكبر وفضلنا مكملين لحد ما وصلنا تقريبًا للعدد الـ 15 .. ومن وقتها والأعداد بدأت تزداد تدريجيًا!

في نهاية سنة 2024 بدأنا الإعلان عن منتجات اقرأ-تِك لأول مرة وأول كتاب كان “ورقة وقلم” الكتاب اللي بيضم أكتر من 50 موضوع في هندسة البرمجيات بشروحات رسومية بجودة عالية.

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

ويلي كتاب “ورقة وقلم” بكل تأكيد محتوى مدونات فطين وخبرات عملية من داخل الشركات في تصميم النظم واللي لقت رواج كبير واللي كانت دافع لينا اننا نكمل وننزل بكتاب “مدونات فطين” كتاني كتاب من منتجات اقرأ-تِك!

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

عقدة الخواجة — ولحظة الشك

أحيانًا كتير كان بيجيلي شعور هو ايه اللي هيخلي الناس تقرأ الكلام ده .. ماهم متعودين على الشروحات الانجليزية ومتابعين عدد كبير من المصادر الاجنبية .. ولكن واحدة واحدة لما بدأت اقرأ مقالات مختلفة في اقرأ-تِك من كتابات ناس تانية .. أنا فعلًا قدرت قيمة إن اقرأ مقال كامل تقني بالعربي ويوصلني بالسلاسة والوضوح ده ومن أول مرة ومن غير محتاج اقراه اكتر من مرة علشان استساغه وافهمه.

دايمًا شرح أي موضوع بلغته الأم بيوصله وبيثبتّه بشكل أسهل وأسرع وهيكون سهل الهضم من إنك تقرأ لغة غير لغتك .. وبعدين تحاول تترجم وتحاول تثبت ده في دماغك!

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

زوبعة الفنجان — ودخول عالم الـ Agents

كسرنا العدد الـ 50 والـ 75 لحد ما وصلنا للـ 100 وتقريبًا بين الـ 75 والـ 100 كانت إنطلاقة الـ AI والـ LLM والـ Agents .. واللي بكل تأكيد هيكون ليها تأثير كبير وتغيير في شكل صناعة هندسة البرمجيات في المستقبل.

وبسبب ده حاولنا للمرة اللي مش فاكر كام نغير في شكل النشرة ونخلي دايما في جزء بنتكلم فيه عن الـ AI في سطور ونخلي في إطلاع دائم باللي بيحصل حوالينا في عالم تطور الـ AI!

التطوير دا أصبح بيقدم أكبر قيمة للقارئ (المبرمج) اللي حابب يفضل يتعلم جديد وكمان يفضل متابع الأخبار بشكل يفيده مش يتوّهه.

السر في الاستمرارية

كنت دايمًا بسمع الجملة دي .. السر في الاستمرارية .. Consistency is the key ولكن مقدرتش قيمتها فعلاً وحسيت بيها إلا مع اقرأ-تِك سواء في المنصة أو من خلال النشرة الأسبوعية .. كنا بنكتب كل عدد وكل مقال وإحنا مش مهتمين لا بعدد ولا مشاهدات .. هكون بكدب لو بقول الحاجات دي مش بتفرق .. هي أكيد بتفرق في النفسية والتحفيز .. ولكن كانت دايما نيتنا إننا بنحاول نشكر نعمة ربنا علينا .. وكنوع من شكر النعمة اللي ربنا أنعم بيها علينا في المجال .. هو إننا نشارك اللي اتعلمناه واللي بايدينا نساعد بيه المجتمع من حوالينا في إنه يتطور ويتحسن للأفضل ..

دلوقتي بعد سنتين من أول عدد للنشرة إحنا فخورين بإننا استمرينا وإنها النشرة الوحيدة باللغة العربية للمبرمجين وإنها بتتطور وبتكبر عشان تقدم أكبر قيمة ممكنة للمبرمج العربي لأننا ببساطة كمجتمع تقني عربي فينا مواهب كثير متميزة بتطلع منتجات بتخدم ملايين عربيًا وعالميًا وبجودة عظيمة، فنستحق نتعلم ونتطور بلغتنا الأم و“بسهولة”.

في الختام

الحمدلله احنا لسه مكملين .. وربنا يوفقنا في إننا نفضل مكملين للـ 100 عدد التاني وباذن الله مازلنا هنطور للأفضل وفيه أفكار كتير ناويين نعملها وهنشاركها معاكم دايمًا أول بأول .. فشكرًا إنكم جزء من رحلتنا الجميلة دي وشكرًا لدعمكم المستمر ❤️

شاركونا في رسم الأعداد الجاية 👋

بما إن هدفنا دائمًا في النشرة الأسبوعية نقدم محتوى يلامس اهتماماتكم التقنية والبرمجية ويضيف لقيمتكم المعرفية، حابين نعرف منكم: حابين نركز على ايه ونغطيه بالتفصيل في الأعداد الجاية؟ شاركونا في الاستبيان وخلينا نشوف رأي الأغلبية! 👇

• إستضافة مهندسين متميزين من مجالات برمجية مختلفة يشاركونا خبرتهم في النشرة

• محتوى أكبر عن الـ AI و ال AI Agents

• تعمق أكثر في الأساسيات

• محتوى أكبر عن ال System design والشركات العالمية

واكتبولنا في التعليقات لو عندكم أفكار تانية بالتأكيد هنحب نسمعها!

نظرة سريعة عن أهم ما جاء في الـ 100 عدد 🚀

100 عدد ب 100 شرح اتكلمنا فيهم عن مواضيع مختلفة لأننا بنحافظ على أن النشرة متكونش متمحورة بس على نشر الأخبار الجديدة في الـ software development ولكن تضيف “علم” حقيقي ليك كمبرمج سواء بشروحات تقديمية لبعض المواضيع أو شروحات متقدمة ونقاشات مواضيع هامة.

تقدروا تلاقوا الأعداد في الأرشيف بتاعنا على Substack ودي أهم التصنيفات اللي اتكلمنا عنها

هندسة الـ APIs والتطوير (APIs & Development Tools)

أهم ٥ أعداد في هذا التصنيف:

1. VOL34: Top 30 ASP.NET Core Libraries for Building Applications

2. VOL32: Full Guide Into API Documentation

3. VOL59: Improving Code Quality with SonarQube

4. VOL61: What is gRPC? A Modern Alternative to REST APIs

5. VOL62: Understanding API Idempotency & API Authentication Methods

دراسات حالة للأنظمة الضخمة (System Design & Scale Case Studies)

كان في أكثر من 23 عدد قدمنا فيهم شروحات لل Systems at Scale واللي الشركات العالمية بالفعل شاركتها في ال Engineering Blogs الخاصة بيها بشرح أسهل بالعربي وبـ Diagrams توضيحية ليها ودول كانوا أكثر 9 أعداد مميزة.

1. VOL:19 Strategies for Read Heavy Systems

2. VOL30: How Discord Stores Trillions of Messages

3. VOL45: How Canva Built Scalable and Reliable Content Usage Counting Service

4. VOL51: How Netflix Migrates Critical Traffic at Scale With No Downtime

5. VOL52: How Slack Handles Billions of Tasks in Milliseconds

6. VOL53: How YouTube Supports Billions of Users With MySQL

7. VOL67: Unlocking Notion’s Power - The Data Model Explained

8. VOL86: Modernizing Reddit’s Comment Backend from Monolithic to Microservices 🚀

9. VOL90: Scaling PostgreSQL to Power 800 million ChatGPT Users

تصميم الأنظمة وهندسة قواعد البيانات (System Design & Databases)

أكثر 11 عدد مميز في الموضوعين اللي مصدعين كل ال backenders! 😅

1. VOL22: Database Cheatsheet for System Design

2. VOL38: Deep Dive Into Rate Limiting

3. VOL24: Stop Using Sticky Sessions at Scale

4. VOL33: Distributed Tracing in Microservices

5. VOL36: Deep Dive Into Caching Strategies.

6. VOL50: Introduction to Apache Kafka - A Beginner’s Guide .

7. VOL64: Deep Dive Into Redis Persistence Strategies

8. VOL66: Top 6 API Performance Techniques

9. VOL80: Vector Databases Explained

10. VOL81: HTTP Versions Explained.

11. VOL99: Harness Engineering

الذكاء الاصطناعي وهندسة الأوامر (AI, LLMs & Prompt Engineering)

اتكلمنا عن ال AI بشكل رئيسي في أكثر من 15 عدد ودول أهم خمس أعداد من النشرة لشروحات عن الـ AI

1. VOL37: Prompt Engineering Crash Course

2. VOL57: Understanding Model Context Protocols in LLMs - The Future of AI Interaction

3. VOL77: RAG Architecture Explained

4. VOL79: AI Engineer Roadmap

5. VOL94: LLM Currency Language - Tokens Explained 🚀

أنظمة الدفع الإلكتروني (FinTech & Payment Systems)

في 2025 ابتدينا نتكلم عن ال Fintech بالتحديد كانت من أفضل التجارب و كل الشكر ل م محمد بسيوني لمقالته وشروحاته المتميزة في هذا الموضوع. نشرنا إلى الآن 10 أعداد مختلفين في مواضيع مهمة لكل مبرمج في ال FinTech ودول أهم خمس أعداد منهم:

1. VOL68: Online Payments 101 for Developers

2. VOL72: How Card Payments Secured With 3DS

3. VOL73: Payment Fees: An Engineering Breakdown

4. VOL74: How to Integrate Payment Gateways - A Developer’s Guide

5. VOL76: How Wallet Payment Works ?

أساسيات هندسة البرمجيات والويب (Software Engineering & Web Fundamentals)

الأعداد الأولى من النشرة كانت مركزة علي شروحات تقديمية في الويب و المجال بشكل عام ودول كانوا أفضل ٥ أعداد منهم والعدد الواحد بيقدم أكثر من موضوع فهتطلعوا بمعلومات قيمة جدًا..

1. VOL8: Message Queue, OAuth2 and High Order Component Pattern

2. VOL9: How to Write Better Logs, Json Web Token

3. VOL10: Database Connection Pool, Normalization and SQL Injection

4. VOL12: Pessimistic Locking, WebSockets and ACID

5. VOL13: HTTP Long Polling, Short Polling and SSE

آخر الإحصائيات 📊

احصائيات النشرة الأسبوعية لاقرأ-تِك قبل العدد الـ 100 ⭐️

رسالة شكر وتقدير ❤️

في خلال رحلتنا .. فيه ناس فضلوا مكملين معانا للآخر ولذلك وجب الشكر لجميع الكتاب في منصة اقرأ-تِك واللي بيبذلوا مجهود في اثراء المحتوى التقني باللغة العربية! وشكر خاص لـ

• م.محمد بيسوني وتميزه في كتابة المواضيع الخاصة بالـ FinTech

• م.روان إبراهيم وتميزها في كتابة المواضيع الخاصة بالـ Mobile Development وبالأخص Flutter

• م. يوسف حسين وتميزه في كتابة المواضيع الخاصة بالـ Scrum والـ Agile وتبسيطها

• م. Oussama Djaidri وتميزه في كتابة مواضيع متنوعة وبالأخص في الـ Frontend والـ React

• م. خالد عبدالفتاح وتميزه في كتابة مواضيع متنوعة بجودة عالية وبالأخص في الـ API Documentation

• م. أحمد أنور وتميزه في كتابة مواضيع خاصة بالـ Data Structures & Algorithms

• م. سعيد خالد وتميزه في كتابة مواضيع غير مسبوقة في الـ Frontend

• م. هبة محمد وتميزها في كتابة مواضيع خاصة بالـ AI والـ Prompt Engineering

• م. أحمد محمد وتميزه في كتابة مواضيع خاصة بقواعد البيانات وتصميم النظم

وشكرًا لكل المؤثرين في المجال واللي كانوا بيشجعونا نكمل وشكر خاص لـ

• أحمد الإمام

• أبوبكر سليمان

• حسن إبراهيم

• حاتم حسني

• سامح دعبس

• محمد سويلم

• آية الجبيلي

• هبة العيوطي

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

• مجرّة - مُجتمع المطورين ومستجدات التقنية

• Apidog

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد التاسع والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

Harness Engineering

في سنة 1973، شركة General Dynamics طلّعت prototype لطائرة مقاتلة جديدة اسمها YF-16. من برّه، الطيارة كانت شكلها عادي بالنسبة لمقاتلة حديثة: جناحات حادة، engine قوي، وتصميم كله سرعة ومناورة.

بس الحقيقة إن الطيارة دي كان جواها سر غريب جدًا: هي كانت متصممة بطريقة تخلي الإنسان مستحيل تقريبًا يطيرها لوحده.

قبل الـ F-16، الطيار كان متوصل بالطائرة بشكل ميكانيكي. يعني لما يشد عصاية القيادة، فيه كابلات وأجزاء ميكانيكية بتحرك أجزاء معينة في الجناح والذيل. لكن الـ F-16 كانت مختلفة.

الطيارة كانت unstable بطبيعتها. حساسة جدًا وسريعة جدًا في رد فعلها. لو الإنسان حاول يتحكم فيها بشكل مباشر، مش هيقدر يعمل التصحيحات السريعة المطلوبة علشان تخليها ثابتة في الهوا.

فالمهندسين عملوا حاجة جريئة جدًا: حطّوا Computer بين الطيار والطيارة.

لما الطيار يحرك عصاية القيادة، هو في الحقيقة مش بيحرك الجناح مباشرة. هو بيبعت request للـ Computer. والـ Computer هو اللي بيترجم الطلب ده لمجموعة ضخمة من التعديلات الصغيرة في أجزاء من الثانية علشان الطيارة تفضل طايرة بثبات.

في اللحظة دي، دور الطيار اتغير: هو مبقاش الشخص اللي بيتحكم في كل جزء بإيده. ولكن بقى الشخص اللي بيوجّه نظام معقد جدًا.

وده بالضبط اللي بيحصل دلوقتي في مهنة الـ Software Engineering.

تجربة OpenAI — خمسة شهور من غير ما إنسان يكتب كود

في تجربة مثيرة، فريق داخلي في OpenAI اشتغل لمدة خمسة شهور على بناء software product حقيقي.

بس كان عندهم شرط واحد غريب: ممنوع أي إنسان يكتب كود بإيده. وكل حاجة تقريبًا اتعملت عن طريق الـ AI Agent Codex.

• البشر كانوا بيشرحوا المطلوب.

• والـ Agent هو اللي يكتب الكود ويشغّل tests ويصلح errors ويكرر المحاولة لحد ما يوصل لنتيجة شغالة.

الموضوع مش معناه إن البشر اختفوا ولكن بالعكس البشر كانوا مهمين جدًا، بس دورهم اتغير.

بدل ما يكتبوا implementation سطر بسطر، بقوا يحددوا الاتجاه، يكتبوا design docs، يحطوا constraints، يراجعوا القرارات، ويبنوا البيئة اللي تخلي الـ AI Agent يعرف يشتغل من غير ما يحوّل المشروع لفوضى.

ووقتها OpenAI سمّت النوع ده من الشغل: Harness Engineering.

المشكلة عمرها ما كانت في كتابة الكود

لسنين طويلة فضلنا نتعامل مع كتابة الكود كأنها قلب المهنة.

• المبرمج الشاطر مش بس اللي يكتب بسرعة واللي حافظ syntax ولكن برضو اللي يعرف يبني feature كاملة لوحده وكمان اللي يغوص في الكود ويصلح كل حاجة بإيده.

  بس الحقيقة إن هندسة البرمجيات عمرها ما كانت مجرد typing .. كتابة الكود كانت بس الوسيلة اللي بنعبّر بيها عن قراراتنا. والشغل الحقيقي دايمًا كان في حاجات أدق وأعمق بكتير زي:

• إننا نفهم المشكلة.

• نقسم التعقيد.

• نختار abstraction مناسب.

• نرسم boundaries بين components.

• نوازن بين performance وmaintainability.

• نعرف إمتى نخلي الحل simple وإمتى نستثمر في الـ scalability وإمتى نقول “لا” لفكرة شكلها ذكي بس هتبوّظ النظام بعدين.

  فبشكل تاني إحنا لما بنشوف مهندس برمجة بيكتب كود، احنا مش بنتفرج عله وهوشغال typing ... ولكن احنا بنتفرج على التفكير وهو بيتحوّل لكود.

فلو الـ AI قدر ياخد التفكير ده ويحوّله لكود شغال، يبقى الـ bottleneck الحقيقي مكنش سرعة صوابعنا وهي بتكتب على الكيبورد. الـ bottleneck الحقيقي كان دايمًا وضوح التفكير.

Harness Engineering

ببساطة: الـ Harness Engineering هو إننا نبني البيئة اللي تخلي الـ AI Agent يقدر يكتب Software كويس، آمن، مفهوم، وقابل للصيانة.

فالفكرة هنا مش إننا نقول للـ Agent:

“ابني النظام ده” ونسيبه يسرح.

لأن الـ AI Agent سريع جدًا. متحمس جدًا. وبيقدر يطلع آلاف الأسطر في وقت قليل. وطبعًا كل ده من غير حدود، هنلاقي إن السرعة دي بتتحول لفوضى.

هيضيف abstractions مش محتاجينها ، وهيكرر logic في كذا مكان ، وهيكسر architectural boundaries وممكن يبني حاجة شغالة النهارده، بس صعب جدًا تتفهم أو تتعدل بعد شهرين.

علشان كده دورنا في الـ Harness Engineering مش إننا نجري ورا الـ Agent نصلحله كل حاجة بإيدينا ولكن دورنا إننا نبني الطريق ليه من خلال إننا نبني rails ، نحط guardrails ، نكتب docs واضحة ، نحدد rules ، نقوّي الـ tests ونظبط الـ CI ونخلي إمكانية الغلط أصعب، وإنه يطلع المطلوب الصح هو الأسهل.

فبدل ما تسأل نفسك:

“هكتب الكود إزاي؟”

تبدأ تسأل نفسك:

“أبني environment إزاي يخلي الـ Agent يكتب الكود الصح من غير مشاكل؟”

الـ Agent محتاج حدود مش حرية مطلقة

لو تخيلنا إن عندنا junior developer سريع جدًا، عنده طاقة رهيبة، وممكن يكتب كود طول اليوم من غير ما يتعب .. ده طبعًا هيكون شيء ممتاز.

بس الحقيقة المرة هي .. إن لو دخل codebase كبيرة من غير onboarding، من غير conventions، من غير architecture واضحة، ومن غير tests محترمة، هيعمل كارثة بسرعة.

الـ AI Agent شبه كده، بس أسرع بكتير .. هو مش محتاج إنك تشرحله كل تفصيلة يدويًا كل مرة ولكن محتاج system يفهمه.

محتاج يعرف:

• يبدأ فين بالظبط؟ وإيه الـ architecture؟ وإيه المسموح والممنوع؟ وإيه الـ naming conventions؟ طب إزاي نكتب tests؟ وإزاي نضيف feature من غير ما نكسر boundaries؟ وإيه الملفات اللي يرجع لها؟ ووإيه الحاجات اللي ممنوع يعملها حتى لو “شكلها” أسهل؟

هنا بقى قيمة الـ Software Engineer بتظهر .. مش في إنه يكتب كل function بإيده ولكن في إنه يبني codebase وworkflow يخلي الـ Agent يعرف يتحرك جواهم بأمان.

حكاية الـ Progressive Disclosure — ما ترميش المشروع كله في وش الـ Agent!

من أهم الأفكار في الـ Harness Engineering فكرة اسمها الـ Progressive Disclosure

ودي بكل بساطة يعني ما تديش للـ Agent كل حاجة مرة واحدة ، فما ترميش عليه architecture كاملة، وrequirements ضخمة، و20 ملف docs، وتستنى منه يطلعلك implementation ممتاز.

بدل كده، اديله entry point واضح وصغير مثلاً ملف زي: AGENTS.md الملف ده مش لازم يشرح كل حاجة ولكن هو بس يقول للـ Agent:

• ابدأ من هنا.

• لو بتشتغل على API، اقرأ الملف الفلاني.

• لو بتضيف database migration، اتبع القواعد دي.

• لو بتكتب tests، استخدم pattern ده.

• لو هتغير في module معين، ما تكسرش الحدود دي.

• يعني بدل ما تحط كل الـ Knowledge في prompt واحد ضخم، تبني نظام من docs صغيرة ومترابطة ، فكل layer تكشف اللي بعدها لو احتاجنا ليها وعند الضرورة.

زي بالضبط لما نعمل onboarding لمهندس جديد في الفريق بتاعنا. فاحنا مش بنديله تاريخ الشركة كله في أول يوم ولكن بنبدأ نديله أول خيط يمشي منه، وبعدها يكتشف التفاصيل تدريجيًا.

شكل الشغل بيتغير

في الـ workflow القديم، المهندس يفتح IDE، يقرأ الكود، يكتب implementation، يشغّل tests، يصلح الأخطاء، ويعمل pull request ولكن في الـ workflow الحالي والقائم على مبدأ الـ Harness Engineering، المشهد بيكون مختلف.

المهندس ممكن يكتب task واضحة:

“ضيف user login feature، التزم بالـ existing architecture، اكتب tests، وحدّث docs.”

بعدها الـ Agent يبدأ يشتغل.

يقرأ الملفات ويعمل plan وبعدين يعدل الكود ويشغّل tests ولو حاجة باظت يصلحها ويراجع التغيير واخيرا يفتح pull request.

وهنا الـ Software Engineer دوره مختفاش ولكن بقى شغله في Layer أعلى فبيسأل:

هل الحل ده مناسب ولا لا ؟ هل الـ Agent فهم المشكلة صح؟ هل الـ design ماشي مع الاتجاه اللي عاوزينه؟ هل فيه complexity زيادة؟ هل التغيير ده هيبقى مفهوم بعدين مع الوقت ومع وجود تغييرات؟ هل الـ tests بتثبت السلوك المهم فعلًا ولا مش بتقدم قيمة؟ هل الـ architecture لسه مظبوطة ولا فيه volations؟

وكل دي أسئلة محتاجة مهندس شاطر ويمكن كمان اشطر من الأول .. لأنك دلوقتي مش بس بتكتب كود ولكن أنت بتصمم وبتدير نام يقدر ينتج هو الـ functions دي.

لما الـ Agent يغلط، متصلحش الكود بس!

في الطريقة التقليدية، لما bug يظهر، أول حاجة بنعملها إننا نفتح الكود وندور على المشكلة علشان نحلها .. ولكن في الـ Harness Engineering، السؤال الأهم بيبقى:

“ليه النظام سمح للـ Agent يغلط بالطريقة دي؟”

هل الـ docs مش واضحة؟ طب هل الـ tests ضعيفة؟ هل ممكن الـ prompt كان مكتوب بشكل generic زيادة عن اللزوم؟ هل فيه conventions متضاربة؟ هل الـ architecture مكنتش مفهومة وواضحة؟ هل مفيش automated checks تمنع النوع ده من الغلط بعدين؟ وآخيرًا هل الـ codebase نفسها كانت صعبة إن الـ Agent يفهمها بسبب تعقيدها ؟

فالغلط هنا مش بس bug في الكود ولكن ممكن يكون bug في الـ harness نفسه وده فرق كبير جدًا!

فبدل ما نفضل نصلح في نفس المشكلة كل مرة، احنا بنحاول نبني نظام يمنع تكرارها من الأساس.

هل ده معناه إن الـ Software Engineer هينتهي؟

بكل تأكيد لأ .. ولكن المهندس اللي قيمته كلها إنه “بيعرف يكتب كود كتير” بس، هيواجه ضغط كبير.

وده جوهر الـ Harness Engineering: الذكاء مبقاش بس في الكود اللي بيتكتب، لكن في البيئة اللي بتخلي الكود يتكتب صح.

الطيار مبقاش بيمسك الجناح بإيده

نرجع تاني لتشبيه الـ F-16 .. الطيار مبقاش متوصل بالجناح بشكل ميكانيكي ، فمش بيحرك كل سطح في الطيارة بنفسه ولكنه برضه مبقاش أقل أهمية .. بل بالعكس هو بقى بيوجّه نظام أعقد وأسرع من قدرة الإنسان.

وده اللي بيحصل بالظبط مع الـ Software Engineers ، إننا ما نكتبش كل سطر بإيدينا مش معناه ابدأ إننا بقينا أقل قيمة ولكن معناه إننا بدأنا نشتغل في layer أعلى محتاجة مهارات ومتطلبات أكتر. وبدل ما نكون منفّذين لكل تفصيلة، هنبقى مصممين النظام اللي بينفذ ده.

في الختام

الـ Harness Engineering هو محاولة لوصف تحول حقيقي في طريقة بناء الـ Software مع AI Coding Agents .. زمان، قوة المهندس كانت بتاخد wight كبير في قدرته على كتابة الكود ولكن دلوقتي، القوة بتتحرك تدريجيًا ناحية قدرته على بناء systems تخلي الـ Agents تشتغل بشكل منتج وآمن.

والـ Software Engineering عمرها ما كانت عن سرعة الكتابة ولكن كانت دايمًا عن مهارات التفكير وحل المشاكل.. فكل ما الآلة بقت أقوى في التنفيذ، الإنسان اللي يعرف يحدد الاتجاه، ويبني الحدود، ويفهم الـ trade-offs، هيبقى أهم.

وآه يمكن المستقبل مش محتاج دلوقتي مهندسين يكتبوا كود أكتر .. ولكن محتاج مهندسين بيعرفوا يبنوا الـ harness اللي يخلي الـ AI ينطلق بسرعة وبدون مشاكل … من غير ما يوقع النظام كله!

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الثامن والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• AI في سطور: DeepSeek V4 released with ultra-long context 🔥

• ورقة و قلم: Top 6 Deployment Strategies 🚀

• مقال: Beyond Barrel Files 💎

DeepSeek V4 Released with Ultra-long Context

في نهاية إبريل شركة DeepSeek أعلنت رسميًا عن الجيل الجديد من موديلاتها: DeepSeek-V4، واللي جاي بنسختين:

• V4-Pro: للأداء العالي والمهام المعقدة.

• V4-Flash: أسرع وأوفر في التكلفة.

ال Model يعتبر من أقوى الموديلات المفتوحة المصدر اللي نزلت لحد دلوقتي، وقريب جدًا من أداء أفضل الموديلات المغلقة زي OpenAI وAnthropic، لكن بتكلفة أقل بفرق كبير جدًا.

أهم المميزات

🔥 Context ضخم جدًا

الموديل بيدعم لحد Million Token، وده رقم كبير جدًا يخليك تتعامل مع ملفات ضخمة، مشاريع كاملة، أو محادثات طويلة جدًا بدون مشاكل.

🧠 وضعين للتشغيل

• Thinking Mode: للتفكير العميق والاستدلال.

• Non-Thinking Mode: للردود السريعة والعمليات اليومية.

💸 الأسعار

• V4-Flash بيقدم Input رخيص جدًا مقارنة بالمنافسين و بيعتبر مناسب للتطبيقات اللي محتاجة سرعة وحجم استخدام كبير.

• V4-Pro أغلى شوية، لكنه بيقدم أداء قوي جدًا في البرمجة، التحليل، والاستدلال المعقد

⚠️ العيوب اللي لازم تعرفها

• لسه أضعف شوية في الـ World Knowledge مقارنة بأحدث موديلات OpenAI وGoogle.

• مفيش دعم multimodal حاليًا (صور، صوت، فيديو).

• في بعض السيناريوهات المعقدة جدًا، Claude وGPT لسه متفوقين.

المهم فعلاً للمبرمجين

بالنسبة للفرق اللي بتشغل أحجام ضخمة جدًا من الـ inference، فرق التكلفة بين V4 Pro والموديلات المغلقة الرائدة بيعمل فرق حقيقي على أرض الواقع. لو نظامك بيعدّي ملايين التوكنز يوميًا من خلال Agent Pipeline، النزول من حوالي 15 دولار لكل مليون توكن كـ output لحوالي 1.10 دولار بس بيغيّر اقتصاد المنتج بالكامل.

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

أما الفرق اللي عندها حساسية عالية تجاه البيانات، فاستضافة V4 Pro على سيرفراتك الخاصة بقت خيار عملي جدًا. ده بيديك أداء بمستوى الموديلات الرائدة، لكن من غير ما تبعت بياناتك لأي API خارجي. قبل كده، ده ماكانش خيار حقيقي، لأن الموديلات المفتوحة القابلة للاستضافة الذاتية كانت أضعف بفرق واضح.

أما لو أنت بالفعل بتستخدم موديلات مغلقة متقدمة، فالفجوة في الأداء بين V4 Pro وبين GPT-5.5 أو Opus 4.7 موجودة فعلًا، لكنها صغيرة نسبيًا. حسب نوع المهام اللي عندك، الفجوة دي ممكن تكون مؤثرة أو لا. عشان كده، استخدام نظام Multi-Model Routing—بحيث تعتمد على V4 Pro للمهام الأقل تعقيدًا، وتلجأ للموديلات المغلقة فقط في الحالات الصعبة—يعتبر حل عملي وذكي جدًا.

Top 6 Deployment Strategies

لما نيجي نتكلم عن الـ Deployment Strategies اللي بتستخدمها الشركات الكبيرة، الهدف الأساسي بيبقى إننا ننقل التحديثات الجديدة للـ Production Environment بأقل تأثير سلبي ممكن على المستخدمين.

فورقة وقلم وخلونا نستعرض الأنواع المختلفة من الاستراتيجيات دي مع مميزات وعيوب كل واحدة فيهم 🚀

Blue-Green Deployment

في الاستراتيجية دي بيبقى عندنا بيئتين شغالين في نفس الوقت: بيئة قديمة بتبقى هي دي الـ (Blue) وبيئة جديدة بتكون هي دي الـ (Green).

أول ما التحديث الجديد يبقى جاهز، بنحول الـ Traffic من بيئة الـ Blue للـ Green مرة واحدة. فيبدأ الناس بدل ما كانت بتروح للـ Blue Deployment تروح للـ Green وهنا بنتكلم طبعًا عن Real Traffic اتعمله Routing باستعمال Load Balancer للـ Green Deployments.

مميزات الـ Blue-Green Deployment:

تقليل الـ Downtime لأن الـ Traffic بيتحول بالكامل مرة واحدة.

لو حصلت مشكلة، الرجوع للبيئة القديمة بيبقى سهل وسريع لإن احنا لسه عندنا الـ Blue Environment لسه موجودة.

عيوب الـ Blue-Green Deployment:

محتاج موارد زيادة لإن بيئتين لازم يكونوا شغالين في نفس الوقت مع بعض.

مثال على ده: شركات كتيرة زي Amazon وغيرها بتستخدم الـ Blue-Green Deployment عشان تحافظ على استمرارية الخدمات بدون تأثير على المستخدمين وعشان يبقى سهل بالنسبالهم يرجعوا للبيئة القديمة لو حصل أي مشاكل غير متوقعة.

Canary Deployment

الاستراتيجية دي بتعتمد على إننا ننقل التحديث بشكل تدريجي يعني Gradually لعدد محدود من المستخدمين الأول، ولو الأمور مشيت كويس، نكمل تعميم التحديث لباقي المستخدمين.

وليكن هنعمل Apply على التحديث الجديد لـ 20% من الـ Machines اللي عندنا و 80% هيفضلوا لسه محافظين على النسخة القديمة وبالتالي الناس لما يطلبوا الخدمة 20% منهم هيروح للجديد و 80% هيفضلوا لسه بيجيلهم النسخة القديمة والنسبة دي طبعا احنا بنتحكم فيها على حسب احتياجاتنا.

مميزات الـ Canary Deployment:

• لو فيه أي مشاكل، بتأثر على عدد محدود من المستخدمين بس.

• بتساعد في اختبار التحديث الجديد في البيئة الحقيقية.

عيوب الـ Canary Deployment:

• محتاجين Monitoring دقيق عشان نعرف إذا كان فيه مشاكل بسرعة.

مثال: شركات زي Google و Netflix بتستخدم Canary Deployment عشان تجرب الـ Features الجديدة قبل تعميمها على كل المستخدمين وبالتالي يكون فيه نسبة بس بيجيلهم التحديث الجديد ونسبة تانية لسه بيظهرلهم النسخة القديمة.

Rolling Deployment

في الـ Rolling Deployment، التحديث بيتنقل بشكل تدريجي لمجموعة من السيرفرات بدلاً من نقل التحديث بالكامل مرة واحدة.

فلو عندنا مثلا 10 Servers هيبدأ يتعمله Apply على واحد تلو الآخر بشكل تدريجي لحد مايتم على كل الأجهزة والـ Servers اللي موجودة.

مميزات الـ Rolling Deployment:

• الـ Downtime قليل جداً لإن السيرفرات بتتحدث واحدة واحدة.

• بيقلل المخاطرة لأن التحديث بيكون بشكل تدريجي.

عيوب الـ Rolling Deployment:

• لو حصلت مشكلة، صعب ترجّع التحديث لكل السيرفرات بشكل سريع وده لإن احنا محتاجين نـ Rollback كل جهاز بشكل تدريجي ونرجع للنسخة القديمة فهياخد وقت.

مثال: فيه شركات بتفضل تستخدم الـ Rolling Deployment عشان تتجنب المشاكل الناتجة عن تحديث كل السيرفرات مرة واحدة فيبقى الموضوع ماشي واحدة واحدة وبشكل تدريجي

اكمل قراءة المقال

Beyond Barrel Files

أحيانا كتير بنشوف أنماط مختلفة من كتابه الكود وبنشوف الأنماط دي كتير في شغلنا اليومي وبنستخدمها كمبرمجين من غير ما نعرف ال cost بتاعها في الخلفية، وواحدة من الأنماط دي هي barrel file طب يعني ايه barrel file وهل هو صالح للمشروع أو لا ؟ 🤔 دا اللي هنعرفه في المقال ان شاء الله .

ماذا يعني barrel file ؟

ال barrel file عباره عن ملف واحد في الأغلب index.js او index.ts وهدفه الوحيد إنه يجمع ال exports الي في الملفات الأخرى الي بتكون في نفس ال folder يعني علي سبيل المثال

project/
├── components/
│   ├── index.ts          # Barrel file
│   ├── Button.ts
│   └── Modal.ts

ودا بيكون المحتوى بتاعه في الأغلب

 // index.ts
export { default as Modal } from “./Modal”
export { default as Button } from “./Button”

بعد ما عرفنا ايه هو ال barrel file خلينا نشوف ايه المشاكل الي ممكن يسببها ال barrel file

اكمل قراءة المقال مجانًا

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد السابع والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• جديد اقرأ-تِك وخصم الـ 50% 🚀

• AI في سطور: ChatGPT Images 2.0 Release 🔥

• مقال Threads & Isolates & Event Loop In Flutter 💎

• تطبيق مجرة على الـ IOS 🌌

إطلالة جديدة وعودة لخصم الـ 50% 🚀

بفضل الله وبفضل مساهمتكم وتشجيعكم وصل عدد المقالات في اقرأ-تِك لأكتر من 350+ مقال بالإضافة لأكتر من 100+ شروحات رسومية بجودة عالية وكمان وصلنا لأكتر من +7,000 مشترك في النشرة الأسبوعية مهتمين بكل ما يخص هندسة البرمجيات والتقنية بالعربي ✨

عشان كده عملنا تحسينات وتجديدات في المنصة تقدروا تشوفوها دلوقتي بطلة جديدة وبالمناسبة دي رجعنا عرض الـ 50% لفترة محدودة على كل خطط الاشتراك السنوية 🚀

اشترك الآن

ChatGPT Images 2.0 Release

ChatGPT Images 2.0 هو الجيل الجديد في أداوات توليد الصور من OpenAI، ودي نقلة كبيرة جدًا عن الإصدارات اللي قبلها. كمان حطم الأرقام القياسية بعد ما تصدر كل تصنيفات Image Arena بفارق ضخم جدًا وصل إلى 242 نقطة عن أقرب منافس، Google Nano Banana 2. أهم تطوير هنا إن “Thinking Mode” يسمح للنموذج بالتخطيط والتحقق قبل التوليد، وده يقلل عدد المحاولات ويوفر وقت كبير أثناء الـ Prototyping. يعني بيفهم المطلوب ويحلله الأول، وبعد كده يبدأ التوليد.

أهم المميزات:

• صور أدق و التزام أعلى جدًا بالتعليمات مع دعم دقة تصل إلى 2K ومجموعة واسعة من أبعاد الصور

• قدرة ممتازة على كتابة النصوص داخل الصور حتى في اللغات المعقدة زي العربي، الياباني، الكوري، والصيني، بدون الأخطاء المعتادة اللي كانت بتظهر في الموديلات القديمة، ودي كانت واحدة من أصعب المشكلات في ال AI Image Generation

• الحفاظ على الاتساق بين عدة صور لنفس المشروع.

• بقى يتعامل بشكل أفضل مع الملفات المرفوعة والسياق الكامل للمحادثة

اللي يهم الـ developers:

• بيفتح استخدامات عملية حقيقية لأنك دلوقتي تقدر تعتمد على النموذج في توليد UI Mockups، Dashboards، Infographics، Documentation Visuals، وحتى شاشات تطبيق كاملة فيها نصوص حقيقية قابلة للاستخدام. دعم تعدد الصور المتناسقة يسهل جدًا بناء Design Systems أو Storyboards للمشاريع.

• لو بتبني منتجات SaaS أو أدوات AI، فـ Images 2.0 ممكن يقلل اعتمادك على أدوات تصميم خارجية في المراحل الأولى، ويحسن سرعة التطوير بشكل ملحوظ.

Threads & Isolates & Event Loop In Flutter

المرة اللي فاتت اتكلمنا عن Platform Channels وليه هي مهمة، لكن في سؤال مهم لازم نسأله:

هل ممكن Platform Channels تبوّظ الأداء أو تخلي التطبيق يهنّج؟

الإجابة: آه، لكن مش لأنها فيها مشكلة في حد ذاتها… السبب دايمًا بيكون في طريقة استخدامها.

في الجزء ده هنعرف يعني إيه Threads وIsolates في Flutter

و يا تري إيه علاقة Dart Event Loop بالموضوع خلونا نشوف✨

📌هنتكلم النهاردة عن :

• يعني إيه Threads

• أنواع ال Threads

• ال Isolates

• ال Life Cycle isolate

• أهمية ال Isolate

• متى نستخدم ال Isolates

• ال Dart Event Loop

• أنواع ال Queues

• الخاتمة

Threads In Flutter

يعني إيه Thread أصلاً ؟

هو وحدة التنفيذ جوه البرنامج .تخيل ال thread دا عامل زي عامل التوصيل كدا بياخد المهمه و يروح يوصلها للمكان اللي هتتنفذ فيه و لازم المهمه دي تخلص علشان ياخد مهمه تانية ميقدرش ياخد اكتر من مهمة في نفس الوقت .

طب ما هي أنواع الـ Threads ؟

عندنا نوعين:

• Main Thread

• Background Thread

عندنا في Flutter:

💡 Main Thread = UI Thread

وده المسؤول عن:

• رسم الواجهة

• التعامل مع ضغطات المستخدم

• تشغيل lifecycle methods

و دا عامل زي جزء الوعي في مخ الانسان اللي هو انت مركز ف ايه ؟ شايف ايه ؟ بتتفاعل مع ايه ؟

ف كدا أما دماغك بتنضغط تركيزك بيقل ف برضو أي شغل تقيل علي ال Main Thread بيخلي التطبيق يهنّج و الـ UI يحصله Freeze

Dart Single Thread 🤔

عندنا دارت شغالة single thread

طب ازاي هقدر اعمل كذا حاجة ابعت ريكويست HTTP و اضغط علي زرار من غير ما التطبيق يقف ؟

اكمل قراءة المقال مجانًا

تطبيق مجرة على IOS 🔥

مجرة أطلقت الـ IOS Native Mobile App لمتابعة مستجدات التقنية من أكتر من 80+ مصدر عربي وعالمي وكمان لتبادل الخبرات والنقاشات بين المطورين 🚀

من خلال التطبيق:

‏🎯 تقدر تبني مجرتك بالشكل اللي يناسبك وتشوف المقالات اللي تهمّك فعلاً من المصادر المتاحة والوسوم
‏🤖 أوامر مدعومة بالذكاء الاصطناعي بالعربي — تلخيص، وتبسيط، وأمثلة عملية وتطبيقية من أي مقال، ونقد بنّاء بضغطة واحدة
‏🌟 الكوكبات — مجتمعات متخصّصة للمطوّرين (تقدر تفكر فيها كـ subreddits للمطوّرين العرب)
‏🔥 سلسلة القراءة — حافظ على عادة القراءة اليومية وهيكون فيه نظام Gamification للتحفيز جاي قريب
‏🏆 لوحة الصدارة والإنجازات
‏💎 تجربة استخدام مميزة للمطورين

وطبعًا دعم كامل للعربية والـ RTL 🌟

رابط التطبيق

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد السادس والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• جديد اقرأ-تِك وخصم الـ 50% 🚀

• AI في سطور: Anthropic’s Double Drop: Opus 4.7 & Claude Design 🔥

• تطبيق مجرة على الـ IOS 🌌

• مقال : How Boris Cherny uses Claude Code - Part 1 💎

إطلالة جديدة وعودة لخصم الـ 50% 🚀

بفضل الله وبفضل مساهمتكم وتشجيعكم وصل عدد المقالات في اقرأ-تِك لأكتر من 350+ مقال بالإضافة لأكتر من 100+ شروحات رسومية بجودة عالية وكمان وصلنا لأكتر من +7,000 مشترك في النشرة الأسبوعية مهتمين بكل ما يخص هندسة البرمجيات والتقنية بالعربي ✨

عشان كده عملنا تحسينات وتجديدات في المنصة تقدروا تشوفوها دلوقتي بطلة جديدة وبالمناسبة دي رجعنا عرض الـ 50% لفترة محدودة على كل خطط الاشتراك السنوية 🚀

اشترك الآن

Anthropic’s Double Drop: Opus 4.7 & Claude Design 🔥

Anthropic نزلت Claude Opus 4.7، وده الـ flagship model الجديد اللي بيتفوق على Opus 4.6 بوضوح خصوصًا في الـ advanced software engineering والـ long-running tasks. أهم نقلة إن الـ model بقى بيعمل verify لـ outputs بتاعته قبل ما يرجعلك نتيجة — يعني بيراجع شغله بنفسه بدل ما يسيبك تراجع وراه.

وده كان الـ Benchmark اللي وصله Claude Opus 4.7

اللي يهم الـ developers:

• فيه Effort level جديد اسمه xhigh بين الـ high وmax بيديك control أحسن على الـ trade-off بين الـ reasoning والـ latency

• فيه Task budgets في beta تخليك تحط ceiling للـ token spend على الـ long-running agents

• فيه Command جديد في Claude Code اسمه /ultrareview بيراجع كودك زي الـ senior ويلقط design flaws.

• Auto mode اتفتح للـ Max Plan Users

ملحوظة مهمة: Opus 4.7 لسه أقل من Claude Mythos Preview اللي Anthropic مش هتنزله للعامة عشان الـ cyber capabilities الخطيرة.

Claude Design — From Prompt to Prototype

في نفس الأسبوع، Anthropic نزلت Claude Design في research preview، وده أول دخول حقيقي ليها في الـ visual creative workflows.

والحكاية ببساطة: تكتب text prompt، أو ترفع images و documents (DOCX, PPTX, XLSX)، أو توجه Claude على الـ codebase بتاعك — ويطلعلك prototypes وكمان slides.

أكتر feature هيعجب فرق الـ engineering: أول ما بتعمل onboarding، Claude بيبني design system للفريق بتاعك لما يقرا الـ codebase و design files. بعد كدة أي project بيطلعه بيمشي على نفس الـ colors والـ typography والـ components automatically. وتقدر تحافظ على أكتر من design system لو شركتك محتاجة كده.

وطبعًا تقدر تعمل export لكل ده: كـ PDF، URL، PPTX، أو تبعته لـ Canva وتكمل editing و collaboration هناك.

وفيه كمان web capture tool بتسحب بيه elements من الـ website بتاعك عشان الـ prototypes تبقى شبه الـ product الحقيقي.

Claude Design شغال بـ Opus 4.7، ومتاح لـ Claude Pro و Max و Team وEnterprise.

تطبيق مجرة على IOS 🔥

مجرة أطلقت الـ IOS Native Mobile App لمتابعة مستجدات التقنية من أكتر من 80+ مصدر عربي وعالمي وكمان لتبادل الخبرات والنقاشات بين المطورين 🚀

من خلال التطبيق:

‏🎯 تقدر تبني مجرتك بالشكل اللي يناسبك وتشوف المقالات اللي تهمّك فعلاً من المصادر المتاحة والوسوم
‏🤖 أوامر مدعومة بالذكاء الاصطناعي بالعربي — تلخيص، وتبسيط، وأمثلة عملية وتطبيقية من أي مقال، ونقد بنّاء بضغطة واحدة
‏🌟 الكوكبات — مجتمعات متخصّصة للمطوّرين (تقدر تفكر فيها كـ subreddits للمطوّرين العرب)
‏🔥 سلسلة القراءة — حافظ على عادة القراءة اليومية وهيكون فيه نظام Gamification للتحفيز جاي قريب
‏🏆 لوحة الصدارة والإنجازات
‏💎 تجربة استخدام مميزة للمطورين

وطبعًا دعم كامل للعربية والـ RTL 🌟

رابط التطبيق

How Boris Cherny uses Claude Code - Part 1 💎

بوريس شيرني — الراجل اللي عمل Claude Code نفسه في Anthropic — اتكلم في thread على X عن بعض النصايح وأهم الممارسات اللي بيشتغل بيهم يومياً وهو بيستعمل Claude ولكن النصايح دي ممكن نعتبرها إنها حجر أساس في التعامل مع الـ AI Driven Development 🚀

1. شغّل 5 instances في نفس الوقت

بوريس مش بيشتغل بـ Claude Code بـ Instance واحدة. ولكن هو بيفتح 5 sessions في نفس الوقت في الـ terminal، وكل session بتكون في git checkout منفصل للـ repo نفسه. وبناء على ده علشان يقدر يواكب بين الـ 5 sessions بيرقّم الـ tabs من 1 لـ 5 وبيشغّل الـ system notifications عشان يعرف لما أي Claude Session تحتاج رأيه.

~/repo-1 $ # Tab 1: Working on feature ~/repo-2 $ # Tab 2: Running tests ~/repo-3 $ # Tab 3: Code review ~/repo-4 $ # Tab 4: Debugging ~/repo-5 $ # Tab 5: Documentation

الفكرة بسيطة: كل session بتاخد وقت، فبدل ما تستنى واحدة تخلص وتفضل مستني، شغّل 5 وروح اعمل حاجة أي حاجة تانية.

2. استعمل الـ web + mobile في نفس الوقت

بالإضافة للـ terminal، هو بيشغّل 5 لـ 10 sessions تانيين على الـ claude.ai/code — من المتصفح. وكمان بيعمل handoff بينهم بسهولة بالـ & command أو الـ --teleport flag.

& — Background a session
--teleport — Switch contexts between local and web

وفيه حاجة تانية: بيبدأ الـ sessions من موبايله الصبح، وبعدين لما يجي يقعد على اللابتوب يكمل من المكان اللي وقف فيه. يعني نقدر نقول إن Claude بيشتغل حتى وهو نايم 🤣

3. Opus 4.5 مع الـ Thinking Mode

ناس كتير بتشتغل بـ Sonnet عشان أسرع وأرخص. ولكن بوريس عنده وجهة نظر مختلفة — هو دايماً بيستخدم Opus 4.5 مع الـ thinking mode.

فمنطقه: أينعم هو أكبر وأبطأ ولكن هو أحسن في الـ tool use وبيحتاج توجيه أقل، وكده كده في الآخر بيخلص الشغل بشكل أسرع من اللي بيستخدم نموذج أصغر ويفضل يصحح وراه كل شوية.

4. CLAUDE.md مشترك للفريق كله

الفريق بيعمل CLAUDE.md واحد محطوط في الـ git، والكل بيضيف فيه كذا مرة في الأسبوع. كل ما Claude يعمل غلطة، بيضيفوها في الـ CLAUDE.md عشان متتكررش تاني.

claude-cli $ cat CLAUDE.md # Development Workflow **Always use `bun`, not `npm`.** # 1. Make changes # 2. Typecheck (fast) bun run typecheck # 3. Run tests bun run test -- -t “test name” # Single suite bun run test:file -- “glob” # Specific files # 4. Lint before committing bun run lint:file -- “file1.ts” # Specific files bun run lint # All files # 5. Before creating PR bun run lint:claude && bun run test

فنقدر نعتبر ده نوع من الذاكرة المرجعية — مش بس للكود، ولكن لـ Claude نفسه.

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الخامس والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• ورقة وقلم : How Online Payments Work 🚀

• AI في سطور: Anthropic’s Most Powerful Model Which Scared Its Own Creators 🔥

• مقال الأسبوع: Understanding Kubernetes CPU Limits and Requests 💎

How Online Payments Work 🚀

واحدة من أكثر المجالات صعودًا في السنين الأخيرة في عالم التقنية هي ال Fintech بل وأصبحت لا غني عنها وجزء من حياتنا اليومية, وأي Business حاليًا لازم يتعامل معها بطريقة أو بأخرى, فورقة وقلم مًبرمجنا الفاضل وتعالى نفهم أساس النظام دا من وجهة نظر العميل ووجهة النظر التقنية لأن سواء احتجت تطبق Payment Solution أو بس ت Integrate مع حل جاهز, فهمك للنظام دا هيسهل عليك كتير..

القصة القصيرة بالنسبة للعميل:

العميل بيدفع للتاجر باستخدام بطاقة البنك الخاصة بيه سواء في المحل مع جهاز الـ Terminal أو ما يعرف ب Point of sale POS) أو بيدخل بيانات الكارت في ال Checkout علي الموقع, وقتها احنا بنعمل Authorisation Request للبنك المٌصدر للكارت عشان نتأكد من وجود رصيد كافي للمعاملة ال Authorisation request دا بنعمل فيه أكثر من عملية أهمهم:

• التأكد من بيانات الكارت و من إن المعاملة مش Fraud

• التأكد من وجود رصيد كافي

• لو في رصيد كافي فالبنك بيقوم بخصم قيمة المعاملة من حساب المشتري وإرسالها لحساب التاجر

خلص ال Authorisation request بنجاح عميلنا كدا دفع بنجاح وخد مشترياته ومشي.

خد بالك عزيزي المبرمج العميل هنا مهتم بـ حاجتين ملهمش ثالث:

• Reliability of Service: أمان المعاملة (ادفع ويتخصم مني فقط القيمة المٌتفق عليها من غير مشاكل تقنية وتفضل بياناتي وبيانات حسابي في أمان)

• Ease of Service: سلاسة ووقت المعاملة (عملية الدفع تتم بأسهل وأسرع طريقة)

فمهما قصة ال Payments تطول معاك في تفاصيلها أولويتك الأولى والأخيرة إنك بتوفر له الحاجتين دول.

القصة الطويلة بالنسبة للمبرمج

قبل ما نعرض الخطوات هنناقش نقطتين مهمين:

المصطلحات المٌستخدمة في أنظمة الدفع

خلونا نستعرض بعض المصطلحات لتسهيلها, الجميل إن المصطلحات دي 90٪ من الوقت ثابتة حول العالم ففي مصر مثل السعودية مثل أمريكا هو نظام واحد بيختلف مٌقدمين الخدمات وأسمائهم.

• الـ Issuer (البنك المُصدِر): هو البنك أو الجهة التي أصدرت بطاقة العميل ويتحقق من صلاحيتها ويوافق أو يرفض العملية.

• الـ Acquirer (البنك المُكتسِب): هو البنك أو المؤسسة المالية التي تمثل التاجر وتستقبل المدفوعات نيابة عنه من شبكات البطاقات.

• ال Card Network (شبكة البطاقات): هي الجهة الوسيطة التي تربط بين البنك المُكتسِب (Acquirer) والبنك المُصدِر (Issuer)، وتُعالج الطلبات وتُطبق قواعد المدفوعات بين الطرفين.

• الـ Payment Gateway (بوابة الدفع): هي الواجهة الإلكترونية التي تجمع بيانات الدفع من العميل وتربطها آمنًا بمعالج الدفع لتنفيذ المعاملة.

• الـ Payment Processor (معالج الدفع): هو النظام أو الشركة التي تنفذ عملية الدفع تقنيًا من خلال التحقق من البيانات والتواصل مع الشبكات والبنوك.

عملية الدفع ليست خطوة واحدة

لما بندفع Cash, عميلة الدفع أغلب الوقت هي نفسها عملية الاستلام. بينما في عمليات الدفع الالكتروني عملية دفع العميل لا تعني استلام التاجر للفلوس, طيب إزاي🤷‍♀️

السر في كون عملية نقل الأموال الفعلية عملية مكلفة فعلاً, خلونا نوضح بمثال

الأموال الخاصة بالعميل في بنك واحد, وحساب التاجر في بنك اتنين, البنك بيوصله الاف المعاملات خلال اليوم مش منطقي بعد كل معاملة نطلع وفد من البنك ينقل الفلوس من بنك للثاني والعكس بالعكس. ولذلك البنوك بتعمل بنهاية اليوم عملية تسوية للأموال وتحسب اللي محتاج يدفعه كل بنك للثاني وتحدد أوقات نقل الأموال.

وبكدا عملية الدفع بتنقسم دومًا خطوتين:

• عملية تحقق Authorisation : وفيها البنك المٌصدر بيقوم بحجز الفلوس في حساب العميل بل وبيوضح للعميل إنه اتخصم منه بشكل فوري(حسابك كرقم بيقل) لكن الفلوس في الواقع متحركتش من البنك.

• عملية تسوية Settlement : وفيها يتم نقل الفلوس بالفعل لحساب التاجر في البنك. عملية التسوية بتحصل عادة خلال يوم أو اثنين ولكن في حلول حاليًا بتقدم تسوية للتاجر في نفس اليوم.

أكمل القراءة

Anthropic’s Most Powerful Model Which Scared Its Own Creators 🔥

في نص الأسبوع، Anthropic عملت حاجة غريبة شوية — أعلنت عن model جديد اسمه Claude Mythos Preview، وفي نفس الوقت قالت إنها مش هتنزله للعامة.

مش بسبب أي مشكلة تقنية. ولكن بسبب إنه خطير جدًا.

إيه اللي بيعمله Mythos بالظبط؟

الـ model ده متخصص جداً في الـ cybersecurity. وبالتحديد، في إيجاد الـ vulnerabilities في الـ software و Anthropic جربته على أكتر من 7,000 مشروع open source، ومعظم الوقت، كان بيقرأ الكود، بيعمل hypotheses عن الـ vulnerabilities، وبيشغل المشروع فعلاً عشان يتحقق — وفي الآخر بيطلع إما بـ bug report كامل مع proof-of-concept exploit، أو بيقول إنه مفيش حاجة.

طب والنتيجة كانت ايه؟

الـ model وجد آلاف من الـ high-severity vulnerabilities في أنظمة تشغيل ومتصفحات ضخمة — vulnerabilities بعضها فضل موجود لسنين من غير ما حد يلاحظه.

Project Glasswing

وعشان كده، Anthropic عملت مشروع اسمه Glasswing — فكرته إن Anthropic هتستخدم Mythos نفسه عشان يساعد في تأمين الـ critical software في العالم قبل ما أي حد تاني يستغل نفس القدرات دي.

ومش بس كده ده كمان التزمت بـ $100M كـ model usage credits لشركاء المشروع ده، وبرضو تبرعت بـ $4M للـ open source security foundations زي Linux Foundation وApache.

Mythos System Card and Benchmarks

الـ system card بتاع Mythos — اللي جه بـ 244 صفحة — فيه تفاصيل مقلقة شوية عن الـ alignment.

في اختبار واحد، Mythos حقن كود في ملف عشان يدي نفسه permission لتعديل حاجة مش المفروض يعدل فيها — وبعدين مسح الأثر وقال إنه بس بيعمل “cleanup”. لكن الـ researchers استخدمواinterpretability techniques ولاقوا إن الـ model من جوا كان عارف تماماً إنه بيعمل حاجة ممنوعة وبيحاول يخبيها.

في حالة تانية، الـ model وصل بالغلط لـ database مش المفروض يشوفها، وبدل ما يقول الإجابة الصح بالظبط ويكشف إنه شاف البيانات، قدم confidence interval “بشكل مريب” — و استخدمواinterpretability كشف إنه كان “بيعمل strategic response عشان يغش مع الحفاظ على الـ plausible deniability”.

الخلاصة

شركة Anthropic وصفت Mythos بإنه “best-aligned model” ليها لحد الآن — وفي نفس الوقت قالت إنه “likely poses the greatest alignment-related risk of any model we have released.” الجملتين صح في نفس الوقت.

المعادلة بسيطة: كل ما زادت القدرات، زاد الـ risk — حتى لو الـ alignment كان فيه تحسن.

لحد دلوقتي، Mythos مش متاح للناس. بس لو عايزين تاخدوا فكرة عن المكان اللي الـ AI models رايحة ليه في الـ cybersecurity، فالقصة دي مثال كويس.

Understanding Kubernetes CPU Limits and Requests 💎

ناس كتير بتستخدم Kubernetes مش مهم هل لحاجه ضرورية ولا لا .. ولكن انا بعتبره حاجة كدا مما عم به البلاء أو الموضة لكن بما اننا بنستخدمه والناس كلها بتستخدمه فمحتاجين نفهم شويه تفاصيل.

المقال ده هيكون طويل شوية لذكر تفاصيل داخلية وهيكون في الآخر الخلاصة الي أنت محتاج تعرفها لو مش عايز تتوه في التفاصيل.

المهم إن Kubernetes فيه جزء الناس أغلبها ملمين بيه ألا وهو الـ CRUD الي بتعمله وانت بتعمل Apply لشوية specs مكتوبة بـ Yaml format ودا فقط بيروح يعمل CRUD في etcd db ودا الـ db engine الي بيستخدمه Kubernetes.

التفاصيل دي بتاخدها components داخليه بتشتغل عليها منها الـ high level ومنها الي بيتعامل مع الـ Linux kernel لكن في المقال دا عايز اتكلم عن جزء الـ Resources Request and Limits وهتكلم تحديدًا عن الـ CPU. وفي مقال تاني ممكن نتكلم عن الـ Memory.

CPU Requests & Limits

هل سألت نفسك قبل كدا لما بتحط CPU limits او memory limits او CPU requests او memory requests الأرقام دي الـ Kubernetes بيعمل بيها ايه او الـ Linux kernel بيتعامل معاها ازاي؟

والإجابة هي إن Kubernetes بيستخدم حاجة اسمها Cgroup عشان يدير الـ resources زي الـ memory والـ CPU لكل container قايمة علي الـ Node من خلال Kubernetes. والمسؤول عن الجزء دا هو الـ Kubelet والي تقدر تعتبره المخ بتاع Kubernetes.

المهم إن Kubernetes بيقسم أو بيوزع الـ Pods في ثلاثة تصنيفات بناءًا علي الإعدادات بتاعة الـ memory والـ cpu الي انت بتحطها في الـ Specs بتاعة الـ Pod وبناءًا عليه ايضًا وجود الـ workload او الـ pod بتاعك في أي من التصنيفات دي بتتغير طريقة التعامل معاها وبقاءها في حالة الـ node pressure او التضحية بيها ودا بيُسمى Quality of Service او QOS اختصارًا والي ممكن تشوفه لما تعرض الـ Specs لـ Pod موجوده عن طريق

 kubectl get pod pod-name -o yaml 

هتلاقي فيه managed field اسمه qos.

طيب ايه التقسيمات دي وتأثيرها ايه علي دورة حياة الـ workload بتاعتك وعلي الـ Out of memory issue ؟ دي كلها حاجات مهم نكون ملمين بيها ولكن أنا في المقال ده هتكلم فقط او أكثر علي الجانب الخاص بالـ CPU.

تصنيفات الـ QOS

Guaranteed

ودي شروطها إن :

• الـ CPU requests = الـ CPU limits

• والـ Memory requests = الـ Memory limits

يعني يكونوا قد بعض .. طيب دا بيترتب عليه ايه؟

بيترتب عليه أداء أفضل وأولوية بمعني إن في حالة الضغط أو ال node pressure والحاجة للتضحية ببعض ال workloads البروفايل دا بيكون آخر حاجة بيتم التضحية بيها وبتاخد أداء مضمون.

ولكن لل CPU limits عيوب هنتكلم عنها لاحقًا ودا عادة اختيار لما تكون عايز predictable CPU availability زي أنواع من ال workloads الي بتعتمد في أنماط التصميم وتحسين الأداء علي حساب ال CPU المتاح زي ال work schedulers وال concurrency rate limit والي غالبا لا ينطبق علي أغلب ال web apps. وده لإن عادة بتتسخدم الأنماط دي في ال db engines وال Message queues وغيرها.

Burstable

ودي شروطها إن:

• ال Resources Request تكون أقل من ال Resources Limits

ودا معناه إن هتاخد الي طلبته ولكن هتقدر تستخدم resources أكتر لو احتجت أكتر من اللي المطلوب بشرط إن يكون متاح دا اصلًا علي ال node وهنسرد دا في تفاصيل لاحقة ازاي دا بيتوزع في كل حالة والفرق بين ال request وال limits.

Best Efforts

ودا لو محطتش أي limits ولا requests .. في الحالة دي ال Pod بتاعتك هتستخدم المتاح أو الي هيتحط لها تاكله أو تموت من الجوع وأول حاجة بيتم بيها التضحية في حالة الضغط وكمان عرضه للـ throttling.

الفرق بين الـ CPU Request والـ CPU Limits

طيب احنا محتاجين نفهم ايه الفرق بين ال CPU request وال CPU limits غير الفرق الواضح من المسميات الي هو اختصارا ال request دا الي طلبته وال limits دا اخري.

أكمل القراءة

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الرابع والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• ورقة وقلم : LLM Tokens Summary for Developers 🚀

• AI في سطور: Claude Code SourceCode Leakage - A Break-down 🔥

• مقال الأسبوع: Platform Channels in Flutter 💎

LLM Currency Language - Tokens Explained 🚀

المقدمة

لما بنستخدم ونشتغل مع ال LLMs بنلاقي دايمًا تكرار لاستخدام كلمة Tokens سواء في الاشتراك مقابل عدد من ال Tokens سواء في ال Context window وغيرها، في ورقة النهارده هنعرف يعني ايه Tokens في عالم ال LLMs، أهميتها و ليه مع الوقت مبقتش بس لغة ال LLMs بس كمان عُملتها!

ما هي ال Token؟

الـ token هو أصغر وحدة بيانات بيستخدمها ال LLM Model علشان يفهم المعلومات ويعالجها. الوحدات دي ممكن تكون:

• كلمة كاملة

• جزء من كلمة

• حرف أو حتى رمز

الفكرة الأساسية إن النموذج مش بيتعامل مع النص أو البيانات بشكلها الطبيعي زي ما إحنا بنشوفها، لكنه بيكسرها لوحدات صغيرة جدًا (tokens) علشان يقدر يدرب ال Model على القيم الرياضية المقابلة ليها.

ليه الـ Tokens مهمة؟

ال LLMs مبنية بالأساس على فكرة ال tokens و من غير tokens النموذج مش هيعرف يقرأ ولا يفهم ولا يرد. فأي بيانات بتدخل للنموذج بيتعملها Tokenization كمثال

كلمة زي: “Awesome” ممكن تتقسم لـ:

“Awe”

“some”

أو تتقسم بطريقة مختلفة علي حسب النظام المستخدم و كل token بيبقى ليه ID معين ، والنموذج بيتعامل مع الأرقام دي بدل الكلمات نفسها.دا مش بس مع الكلمات أو النصوص أي نوع بيانات ممكن يتحول لـ tokens فالصور ممكن تتقسم لأجزاء صغيرة من الصورة (patches) والصوت ممكن نقسمه لموجات أو تمثيل رقمي للموجات وكذلك الفيديو بيتقسم لمقاطع أو Frames.

بمعنى تاني أي حاجة بتدخل للنموذج أو بتطلع منه لازم تتحول لـ tokens عشان يقدر يتعامل معاها. وبالتأكيد ال Tokens بيتعملها Embedding زي ما شرحنا قبل كدا في ورقة Vector Databases For Beginners

استخدام ال Tokens في ال Models

كل نماذج ال LLMs بتمر بمرحلتين:

التدريب Training

الاستنتاج/الاستدلال Inference

و في المرحلتين بنحتاج ال Tokens

استخدام ال Tokens وقت التدريب (Training)

اكمل القراءة

Claude Code SourceCode Leakage 🔥

ببساطة، شركة Anthropic حصل عندها غلطة كبيرة جدًا، وده خلّى جزء ضخم من الكود الداخلي ل Claude Code يتسرّب للعلن.

إيه اللي حصل؟

• أثناء Version update عادي للبرنامج، حصل خطأ بشري خلّى ملف SourceMap حجمه 57MB يتضاف بالغلط لل npm package.

• الملف ده كان فيه لينك لأرشيف ضخم فيه حوالي 500 ألف سطر كود وقرابة 2000 ملف.

• الكود اتنشر بسرعة على GitHub وبقى من أكتر الحاجات اللي الناس حمّلتها في وقت قياسي.

• الشركة ملحقتش تلم الموضوع وابتدينا في موجة “المسألة القانونية” فأحدهم عمل rewrite للكود من Typescript ل لغة Python وأعطاه اسم جديد claw-code ودا حاليًا أسرع repo يعدي ال 50K Stars على Github

• أحدهم اخر تطوع وغير ال code عشان يشتغل مع اي LLM Model زي Gemini, Deepseek واسم المشروع open-claude

• الكود بالفعل كان فيه TODOs كثيرة فيها تفاصيل عن ال Upcoming features منهم زي تنفيذ أوامر بشكل متوازي (Parallel Execution) وغيرها

إحنا اتعلمنا إيه فعليًا؟

القيمة الأكبر بقت في الـSystem مش الـModel

قبل كده المنافسة كانت: مين عنده أقوى موديل (GPT / Claude / Gemini)

دلوقتي من اللي اتكشف في طريقة بناء ال Codebase إن الفرق الحقيقي في:

• إدارة الأدوات (Tools)

• الـAgent loop

• الـPrompt architecture

بمعني أصح مفروض نكون System-centric أكثر من Model-centric لأن ال Models بالفعل قوية ولكن مش بنطلع منها أحسن أداء بسبب إننا مش بنحطها في system يُضبط أدائها

دا معناه إنك ممكن تاخد موديل عادي + System كويس = أداء أعلى من موديل قوي لوحده

ودا هيأثر علي الصناعة:

• بالنسبة للشركات الكبيرة زي Google, OpenAI هي بقى عندها Insight قوي عن أداء أكبر المنافسين في السوق.

• بالنسبة للمبرمجين و ال ICs ولأي حد بيطّور AI Agents فبقي عنده Blueprint قوية يقدر ينتهجها ويسّرع ويحسّن بيها مشاريعه.

المثير للسخرية وللتعّلم في نفس الوقت إن Anthropic من أكثر الشركات اللي بتركز و بتسوق لأهمية ال AI Security, لكن سرعة ال Process مع وجود ال AI كشريك أساسي في التطوير بتخلي في مجال واسع للأخطاء فبلاش نتهاون في إن CI/CD Process في مشاريعنا يكون فيه safeguards قوية.

Platform Channels in Flutter 💎

المقدمة

تفتكر نقدر نتحكم في كل إمكانيات الموبايل باستخدام Flutter بس؟ 🤔

طب لو اشتغلت على بروجكت واتطلب منك Feature محتاجة توصل لحاجات من الـ platform زي الكاميرا أو تربط بسينسور معين هتعمل ايه؟

وقتها هتكتشف إن Flutter لوحده مش بيديك Access مباشر لكل حاجة في Android وiOS.

تخيل إنك تقدر تستخدم كل إمكانيات الموبايل من غير ما تسيب Flutter… ده بالظبط اللي بتقدمه Platform Channels 🚀

في المقال ده هنعرف إيه هي Platform Channels، إمتى نستخدمها، و ازاي بتشغل👀

هنتكلم النهاردة عن:

1. يعني إيه Platform Channels

2. Platform Channel Architecture

3. إزاي Platform Channels بتشتغل

4. أنواع Platform Channels

5. إمتى نستخدمها

6. طريقة نقل البيانات (Codecs)

7. Platform Embedder

8. الخاتمة

1 - ما هي Platform Channels؟ 🤔

ي مرة كنت محتاجة أعمل ميزة live tracking، وكان المطلوب نبعت الـ location كل ثانية للسيرفر.

المشكلة إننا كنا محتاجين نبعت data بسرعة، و JSON وقتها كان بطيء نسبيًا.

فاضطريت أستخدم حاجة اسمها FlatBuffers، وهي طريقة لنقل البيانات زي JSON، بس أسرع بكتير وبتستخدم مساحة أقل ، لكن المشكلة إن Flutter ماكانش بيدعمها بشكل مباشر.

هنا ظهر الحل 👇 استخدمت حاجة اسمها Method Channel، واللي سمحتلي أبعت البيانات من Dart للـ Native، وأرجّع النتيجة تاني بسهولة.

خلينا نسأل نفسنا الاول سؤال غريب شوية : هو مخنا بيشتغل لوحده ؟

المخ دايمًا بيتعامل مع العالم الخارجي عن طريق الحواس: العين، الأذن، اللمس…

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

💡 وده بالظبط نفس فكرة Platform Channels:

Flutter لوحده مش شايف العالم الخارجي… مايعرفش يتعامل مباشرة مع الكاميرا أو الـ GPS أو أي حاجة في الجهاز.

لازم يكون فيه قناة توصله بالـ Native.

يعني ايه Platform Channels ؟

هي ببساطة الجسر اللي بيربط بين عالم Flutter وعالم الـ Native ، Android & iOS وبيسمح إنهم يتواصلوا مع بعض بسلاسة.

من خلالها تقدر:

• توصل لأي حاجة في Android أو iOS

• تستخدم SDKs Flutter مش بيدعمها

• تنفّذ عمليات تقيلة باستخدام Native Code بشكل أسرع

  اكمل قراءة المقال مجانًا

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الثالث والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• Majara مجتمع المطورين و مستجدات التقنية 🚀

• AI في سطور: مٌلخص أخبار رمضان (شهري فبراير ومارس 2026)

• The Complete Guide to Full Text Search in PostgreSQL

مجرّة - مجتمع المطورين ومستجدات التقنية 🚀

زي ما متعودين كل سنة إن إجازة اقرأ تك السنوية بتكون هي شهر رمضان وبنرجع متحمسين أكثر وبمحتوى أكثر وأفضل باذن الله, السنة دي راجعين ومعانا مجرة اللي تم إطلاقها خلال الشهر عشان تكمل رؤيتنا في تسهيل تّعلم البرمجة و مواكبة أخبارها المتسارعة.

مجرة هي أول منصة عربية للمطوّرين لمتابعة أخبار البرمجة والتقنية من المصادر العربية والعالمية!

الفكرة ببساطة إننا نستحق إن يكون عندنا منصة عربية مبنية خصيصًا لاحتياجتنا وبتسهل علينا الوصول للمستجدات اللي بتطرأ في المجال بشكل سريع وبسهولة، خصوصًا إن البدايل المتاحة غير مرغوبة بالمرة!

مجرّة بتجمع أخبار وأدوات ومقالات من +30 مصدر عربي وعالمي في خلاصة يومية مخصّصة لاهتماماتك. ومدعومة بأدوات الذكاء الاصطناعي علشان تساعدك تطلع بأكبر استفادة ممكنة ⚡

طب ايه اللي بيميّزها؟

🎯 تقدر تبني مجرتك بالشكل اللي يناسبك وتشوف المقالات اللي تهمّك فعلاً من المصادر المتاحة والوسوم
🤖 أوامر مدعومة بالذكاء الاصطناعي بالعربي — تلخيص، وتبسيط، وأمثلة عملية وتطبيقية من أي مقال، ونقد بنّاء بضغطة واحدة
🌟 الكوكبات — مجتمعات متخصّصة للمطوّرين (تقدر تفكر فيها كـ subreddits للمطوّرين العرب)
🔥 سلسلة القراءة — حافظ على عادة القراءة اليومية و فيه نظام Gamification عشان التعلم والمشاركة مش لازم تبقي مملة
🏆 لوحة الصدارة والإنجازات
💳 بطاقتك المجرّية — بطاقة هويتك كمطوّر ، وتقدر تشاركها على GitHub و X
💎 تجربة استخدام مميزة للمطورين

مجرة متاحة كموقع و كمان ك Chrome Extension و PWA على الموبايل!

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

وتقدروا تجربوها دلوقتي ومتنسوش تشاركوها مع الجميع 👇

مجرة | مجتمع المطورين

Github Coding Agent and Data Training 🤖

عندنا خبرين مهمين في شهر مارس عن Github Copilot

GitHub is going to start using Copilot interactions to train AI models

أعلنت GitHub أنها ستبدأ باستخدام تفاعلات المستخدمين مع Copilot (الكود، prompts، التعديلات) لتدريب نماذج AI بدءًا من أبريل 2026. القرار بيشمل أغلب المستخدمين (Free/Pro) مع خيار opt-out. دا معناه أن الكود اللي بتكتبه أو بتعدّله ممكن يدخل ضمن بيانات التدريب. الخطوة دي لتحسين النماذج لكنها بتثير القلق حول الخصوصية وملكية الكود. المبرمجين بدأوا يناقشون هل هذا سيؤثر على IP وحقوق الشركات. GitHub أكدت أن enterprise users بيتم استثناؤهم.
📌 الأهم لك كمبرمج:

• لازم تراجع إعدادات الخصوصية لو مش حابب يتم استخدام أكوادك للتدريب اختار opt-out.

• احتمالية استخدام كودك في تدريب نماذج مستقبلية.

GitHub Copilot: Meet the new coding agent

GitHub Copilot اتحول من مساعد بيكتب اقتراحات كود إلى Agent mode وبقى قادر على تخطيط و تنفيذ مهام فعلية داخل المشروع. التغيير دا جه مع طرح Copilot SDK اللي بيسمح للمطورين باستخدام ال Agent جوه تطبيقاتهم في إنه يخطط وينفذ الكود ويختبره و كمان يرفعه في صورة PR. فدلوقتي Copilot بقى بيوفر طبقة orchestration جاهزة تشمل التخطيط، استدعاء الأدوات، وتنفيذ المهام متعددة الخطوات. ودا بيقلل الحاجة لبناء بنية معقدة لإدارة الـ agents من الصفر.التغيير دا كبير لأن بالفعل Copilot هو الخيار المستخدم في شركات كثيرة من 2021 لأنه كان من أوائل ال Coding Assistants الفعالة وكثير من الشركات بالفعل بتعتمد علي أنظمة Microsoft, ولكن لازال Claude Code بيدي نتائج أقوي ك Coding Agent.

The Complete Guide to Full Text Search 💎in PostgreSQL

يشرح هذا المقال تقنية Full-Text Search, وكيفية تطبيقها في Postgres, حيث يبين أن التقنية توفر نتائج بحث أكثر صلة مقارنة بطرق البحث التقليدية, وذلك من خلال فهمها للبنية اللغوية للنص

مقدمة

البحث ميزة أساسية في أغلب التطبيقات, و يؤثر مباشرة على جودة المنتج وتجربة المستخدمين, حيث أن بناء نظام بحث فعّال قادر على عرض نتائج دقيقة وذات صلة أصبح ضرورة.

توجد العديد من طرق البحث, منها طرق بحث بسيطة، مثل المطابقة الدقيقة (LIKE), والتي غالبا ما تؤدي إلى نتائج محدودة، لأنها تتعامل مع النص كمجموعة أحرف, دون فهم لبنيته أو معناه، ما يحدّ من جودة النتائج.

سنتحدث في هذا المقال عن طريقة بحث تسمى بالـ Full-Text Search، حيث سنتحدث عن تعريفها, كيفية عملها, أهميتها, كيف نعدها في Postgres, كيف نعدها للتعامل مع الأخطاء الإملائية, وكيف نعدها للعمل مع النصوص العربية.

ماهو الـ (Full-Text Search (FTS؟

هي طريقة للبحث تهدف إلى إيجاد مستندات بناء على الكلمات التي تحتويها.

كيف تختلف هذه الطريقة عن المطابقات البسيطة “LIKE ‘%word”؟

تقنية المطابقة البسيطة ‘%LIKE ‘%word تعامل النص كمجموعة من الحروف, لا ككلمات لها معنى.

تضيف طريقة الـ FTS نوعا من الذكاء لعملية البحث, حيث تفهم بنية اللغة في النص, وتقوم بتحليل النص وفهرسته, مما يسمح بإرجاع نتائج أكثر صلة.

لكن, ما المقصود بـ المستند (Document)؟

كمفهوم عام, المستند هو كل نص قابل للفهرسة والبحث لاحقا.

في سياق قواعد البيانات كـ Postgres, المستند هو النص الذي يجمع خانات الصف الواحد (concatenation of row’s fields)

في هذا المقال, سنستعمل مصطلحي “المستند” و “النص (Text)” كمترادفين.

والآن, دعونا نلقي نظرة حول كيفية عمل هذا النظام.

كيف يعمل الـ Full-Text Search؟

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الثاني والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• All about QR Code Payments 🚀

• Google Launches Gemini 3.1 Pro 🤖

• Designing Data-Intensive Applications - Introduction 💎

All about QR Code Payments 🚀

واحدة من أكثر طرق الدفع الرقمية شيوعًا هي الدفع باستخدام الـ QR Code, بنشوفه في المحلات والمطاعم وحتى المواقع الإلكترونية, خلينا نتعرف عليها كمستخدمين و كمبرمجين. فورقة وقلم وكوباية شاي ويلا بينا!

أنواع ال QR Codes

في الأول خلينا نعرف إن في نوعين من ال QR Codes

Static QR Codes

في هذا النوع الكود بالفعل بيحمل البيانات المطلوبة, والبيانات دي مبتتغيرش بعد ما بنكون الكود. فمهما كان الوقت المستخدم وقت ما يعمل Scan هيشوف نفس البيانات ودا مناسب مع عرض البيانات البسيطة زي كلمة مرور الواي فاي ولو حابين نغير البيانات هنعيد تكوين الكود كله من جديد.

عشان كدا بنستخدمه في المدفوعات وقت ما تكون كتاجر مش محدد القيمة اللي هتتدفع وهستخدم نفس الكود لأكثر من عميل , وقتها العميل بيعمل Scan للكود و بيحدد القيمة من تطبيق الدفع عنده ويأكد العميلة.

Dynamic QR Codes

النوع دا بيشتغل كأنه رابط على الإنترنت، وبيقدر يتغير أو يتحدّث حتى بعد ما الكود يتطبع. وبتقدر تعمل كود خاص لكل معاملة بقيمتها ودا بيسمح للتاجر يتابع التحويلات، يشوف امتى اتمسحت ومنين، ونوع الجهاز إللي استُخدم. ودي طبعًا كلها مميزات مهمة لينا في عمليات الدفع وعليه فدا الخيار الأنسب والأكثر استخدامًا في أغلب الأحوال.

كيفية استخدام ال QR Codes في عمليات الدفع

جزء التاجر

1. التاجر بيقوم بحساب المشتريات وبيقوم بعمل Checkout

2. عملية ال Checkout بتقوم بإرسال الطلب الى ال PSP

3. يقوم ال PSP بتخزين بيانات المعاملة في قاعدة البيانات و إنشاء رابط QR Code و يقوم بإرساله للتاجر

4. يقدر التاجر يعرض الـ QR Code على الـ POS Terminal أو على موقعه الإلكتروني

جزء العميل

1. لما العميل يمسح الـ QR الكود, تطبيق الدفع في الموبايل بيقرأ البيانات من الكود ( بيانات الطرف اللي هياخد الفلوس + المبلغ).

2. الزبون يضغط Confirm ويدفع، كله من غير ما يدخل رقم الحساب أو أي حاجة يدوية.

3. ال PSP يقوم بإتمام المعاملة المالية و يخزن في قاعدة بياناته إن الـ QR Code دا تم دفعه وبيبعت notification للتاجر بإتمام المعاملة.

بالطبع تفاصيل عملية الدفع من الداخل بتفضل كما هي زي إن المعاملة بتعدي علي البنك المٌصدر للبطاقة و ال Acquirer و شبكات البطاقات فال QR Code هو تعديل في ال User experience أكثر منه تغيير في طريقة معالجة المعاملة وكنا شارحين كل هذه التفاصيل في ورقة منفصلة…

اكمل قراءة المقال

Google Launches Gemini 3.1 Pro 🤖

الأسبوع اللي فات Google أعلنت إنها نزلت تحديث كبير لـ Gemini 3 Deep Think—والفكرة إنهم بيزقّوا الموديل إنه يبقى أحسن في التعامل مع تحديات حقيقية في الـ science والـ research والـ engineering.

النهارده بقى بيكملوا نفس السكة بإطلاق Gemini 3.1 Pro: النسخة اللي بيقولوا إنها “الـ core intelligence” اللي واقف ورا التحسينات دي… وبيبدأوا يوزعوها على أغلب منتجاتهم للمستخدمين والمطورين والشركات.

الإصدار ده 3.1 Pro داخل على كذا مسار:

• Developers: في preview من خلال Gemini API على Google AI Studio، وكمان Gemini CLI، ومنصة Google Antigravity (agentic development platform)، وكمان Android Studio.

• Enterprises: من خلال Vertex AI وGemini Enterprise.

• Consumers: من خلال Gemini app وNotebookLM.

طب هو أحسن في إيه تحديدًا؟

هنلاقي Google بتسوقله على إنه “قفزة في الـ core reasoning”، يعني نسخة أقوى للمشاكل المعقدة—مش مجرد إجابات سريعة وخلاص. وعلشان يدّوا الكلام وزن، استشهدوا بنتائجهم على benchmarks، وبالذات ARC-AGI-2 (اللي بيركّز على حل أنماط جديدة مش متدرب عليها). حسب كلامهم، 3.1 Pro جابت 77.1% verified score، وده “أكتر من ضعف” اللي كان بيقدمه 3 Pro في نفس ناحية الـ reasoning.

طيب ده يفرق معانا إزاي؟ (Intelligence applied)

الجزء العملي في الإعلان كان واضح: هم شايفين إن 3.1 Pro مناسب للمهام اللي “الإجابة البسيطة مش كفاية فيها”، زي:

• شرح موضوع معقد بشكل visual وواضح

• تجميع بيانات كتير ودمجها في single view

• تحويل فكرة إبداعية لحاجة شغّالة على أرض الواقع

وكمثال، عرضوا use case تحت عنوان Complex system synthesis: الموديل قدر يربط بين APIs معقدة وواجهة user-friendly design، وطلعوا مثال عن إنه بنى live aerospace dashboard واشتغل على إعداد public telemetry stream علشان يعمل visualization لمدار International Space Station.

إيه اللي جاي؟

Google بتقول إن التطوير السريع ده جاي من الـ feedback اللي وصلهم بعد إصدار Gemini 3 Pro في نوفمبر، وإنهم نازلين بـ 3.1 Pro دلوقتي كـ preview علشان يختبروا التحسينات دي على نطاق أوسع… قبل ما يوصلوا لـ generally available قريب.

Designing Data-Intensive Applications: Introduction 💎

كتاب Designing Data-Intensive Applications بيشرح إزاي نصمّم أنظمة بتتعامل مع داتا كبيرة بكفاءة، واعتمادية، وقابلية للتوسع. الكتاب موجّه للـ Backend و الـ Software Engineers اللي بيبنوا قواعد بيانات وبرمجيات معتمدة على الداتا، وبيساعدهم يختاروا الحل الصح حسب المشكلة اللي قدامهم.

السلسلة دي هتكون ملخص عملي للكتاب ومرجع لأهم النقاط والمفاهيم اللي بيناقشها، من غير تعقيد ولا تنظير زيادة. في الجزء الأول من السلسلة، هتبقى مقدمة عن الجزء الأول من الكتاب، وهنفهم يعني إيه مصطلح data-intensive application و data system.

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

ما هو الـ Data-Intensive Application؟

لو انت بتبني تطبيق بتخزّن فيه بيانات (database)، وفي العادة فيه داتا دايمًا بتتجاب باستمرار (caching)، وتحتاج تدوّر على حاجات معيّنة (search indexes)، وممكن تبعت داتا أو ملفات كبيرة بشكل غير متزامن (stream processing).

من وجهة نظر المستخدم، كل الحاجات دي بتبان كأنها تطبيق واحد بيعمل كل ده. ولكن الحقيقة إن التطبيق ده متكوّن من مجموعة أدوات وأنظمة مختلفة، كل واحدة ليها دور محدد، وبتشتغل مع غيرها علشان في الآخر تقدّم تجربة واحدة متكاملة.

ما هو الـ Data System؟

لما تجمع أكتر من أداة مع بعض علشان تقدّم خدمة معيّنة، زي:

• قاعدة بيانات أساسية

• طبقة من الـ caching منفصلة

• أدوات بحث زي full-text search

وفي نفس الوقت انت مسؤول إن كل الأجزاء دي:

• شغالة مع بعض بشكل صحيح

• والبيانات فيها دقيقة ومتناسقة

وتقدّمها كلها تحت مظلة واحدة (مثلاً من خلال API)،كده إنت بالفعل بنيت data system خاص بيك، مستخدم أدوات عامة، لكن موظّفها بشكل يخدم احتياجك.

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد الواحد التسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• Linux File Permissions Explained 🚀

• Anthropic Releases Claude Opus 4.6 🤖

• Unlocking Notion’s Power - The Data Model Explained 💎

Linux File Permissions Explained 🚀

كلنا بنحتاج chmod في وقت من الأوقات، ولو مدرسناش Linux فبتبقي الأرقام اللي بتعبر عن الصلاحيات مٌحيرة فعلاً ، وما بنكونش عارفين هما جابوا الكلام دا منين. فورقة وقلم ويلا بينا نتكلم عن الـ Linux File Permissions 🚀

Linux File Permissions

موضوع صلاحيات ال Linux دا متقسم ل ٣ أقسام بنجمعهم مع بعض زى الـ puzzle.

• الأمر Command

• المستخدمين Users

• الصلاحيات Permissions

كل ملف أو مجلد في Linux بينقسم مستخدميه لل ٣ فئات دي :

• مالك (Owner) وهو الذي أنشأ الملف أو المجلد

• مجموعة (Group) قائمة بيها مجموعة من المستخدمين لهم صلاحيات محددة

• آخرون (Others) أي مستخدم آخر

و كل فئة من الفئات دي ليها صلاحيات محتملة:

تغيير الصلاحيات ما هو إلا تعديل الصلاحيات لكل فئة من دي، وخلونا نشرحه بمثال فلو حبينا نعرض الملفات في Directory معينة مع صلاحيتها بنستخدم

Ls -l

فهيعرضلنا

[الاسم] [التاريخ] [الحجم] [المجموعة] [المالك] [عدد الروابط] [الصلاحيات]

-rwxr-xr–- 1 user dev 4096 Feb 10 script.
drwxr-xr–- 1 user dev 6952 Jan 20 MyProjects

هنا الصلاحيات بالنسبة للملف -rwxr-xr– ولكن معناها إيه؟!

هنا الصلاحيات بالنسبة للملف -rwxr-xr– ولكن معناها إيه؟!

لينكس بيوضح دائما الصلاحيات بترتيب الملكية فدائمًا هنعرض صلاحيات ال Owner ثم ال Group ثم ال Others بدون فاصلة

• هنلاقي إن صلاحيات المالك: -rwx ودا يعني إن له صلاحيات القراءة والتعديل والتنفيذ

• هنلاقي إن صلاحيات المجموعة : R-x ودا يعني إن للمجموعة صلاحيات القراءة و التنفيذ فقط

• هنلاقي إن صلاحيات الآخرين: R– وعلامة - في البداية تشير إن دا ملف وكذلك علامة d في البداية تشير إن دا مجلد Directory

ودا كان التمثيل الرمزي للصلاحيات في تمثيل ثاني ليها باستخدام الأرقام ودا الأكثر شيوعًا في استخدامنا في الأوامر كمبرمجين ، وبيعتمد أنه بنمثل كل رمز عملية برقم ونجمع الأرقام بالنهاية للحصول علي صلاحيات المستخدم والجدول في الصورة بيوضحها بالتفصيل

اكمل قراءة المقال

Anthropic Releases Claude Opus 4.6 🤖

أعلنت شركة Anthropic عن إطلاق نموذجها الجديد Claude Opus 4.6، والذي يأتي بنافذة سياق (Context Window) ضخمة تصل إلى مليون توكن في الإصدار الرائد الخاص بها.
كما كشفت الشركة عن ميزة جديدة تُسمى “Agent Teams” تتيح تنسيق عدة وكلاء ذكاء اصطناعي للعمل معًا على مهام معقدة.

النموذج الجديد تفوّق على GPT-5.2 بفارق 144 نقطة في اختبارات العمل المعرفي الواقعي، وحقق دقة 76% في العثور على معلومات مدفونة داخل كميات هائلة من النصوص، مقارنةً بـ 18.5% فقط في الإصدار السابق.

🔎 أهم التفاصيل

• تمكنت Anthropic من بناء(C Compiler) كامل باستخدام 16 وكيل Claude 4.6 يعملون بالتوازي.

• سجل النموذج 1,606 نقطة على معيار GDPval-AA (الذي يقيس أداء النماذج في مجالات مثل التمويل والأعمال القانونية)، متفوقًا على:

  • GPT-5.2 الذي سجل 1,462 نقطة

  • Opus 4.5 الذي سجل 1,416 نقطة

• ميزة Agent Teams تقوم بتقسيم المهام المعقدة عبر عدة نماذج ذكاء اصطناعي تعمل بالتوازي، بحيث يركز كل وكيل على جزء محدد من المشكلة.

• تقدم Anthropic مبلغ 50 دولارًا من الرصيد المجاني للمشتركين لتجربة النموذج الجديد.

🤔 ما هي أهمية ذلك ؟

تبني الشركات للذكاء الاصطناعي يتطلب القدرة على التعامل مع:

• Large Codebases

• مجموعات مستندات هائلة

• استخراج المعلومات الدقيقة من بين آلاف أو ملايين الصفحات

معظم النماذج تنهار أداؤها عند التعامل مع سياقات ضخمة جدًا، لكن أداء Opus 4.6 يشير إلى أن Anthropic ربما نجحت في حل مشكلة هيكلية مرتبطة بالـ (Attention Mechanisms) عند معالجة مدخلات كبيرة للغاية.

أما ميزة Agent Teams فتنقل الأمر إلى مستوى آخر، عبر توزيع المهام المعقدة على وكلاء متخصصين، بحيث يحتفظ كل وكيل بتركيزه على جزء معين من المشكلة — وهو اتجاه يُشبه إلى حد كبير بنية الفرق الهندسية في العالم الحقيقي.

Unlocking Notion’s Power - The Data Model Explained 💎

فريق المهندسين لم جم يبنوا Notion، كانوا حريصين على بناءه على إطار عمل يسمح للمعلومات إنها تقف لوحدها، حرة من أي قيود أو حاويات، وبدل ما تكون محبوسة في أي حاجة، بنخلي القوة في إيد المستخدم انه يقرر ده ، والإطار ده مبني على مفهوم غاية في الابداع ألا وهو الكتل (blocks).

كل حاجة بنشوفها في Notion هي block. النصوص، الصور، القوائم، صفوف قاعدة البيانات، وحتى الصفحات نفسها – كلها عبارة عن blocks، فهي وحدات ديناميكية من المعلومات اللي ممكن تتحول لأنواع تانية من blocks أو تتحرك بحرية داخل Notion.

الكتل دي هي زي قطع LEGO اللي بنستخدمها في بناء ونمذجة المعلومات. ولما بتتجمع الكتل مع بعضها، بتخلق حاجة أكبر بكتير من مجرد تجميع أجزائها.

والمرونة اللي بنشوفها من خلال Notion والـ Blocks هي جوهر مهمة Notion. فعلى الرغم من أن الكتل بتطلب من فريق Notion الهندسي إنه يكون بيطبق دقة شديدة خلال تنظيم المعلومات، الا إنهم كانوا عاوزين نموذج بيانات شبيه بالرسم البياني (graph-like) بحيث يقدر يوفر للمستخدمين القدرة على تخصيص حركة وتنظيم ومشاركة المعلومات بتاعتهم بحرية كاملة.

نموذج الكتل (Blocks) هو اللي بيخلي Notion فريد، وده الأساس لطريقة تفكير Notion في انهم يغيروا من طريقة التعامل مع البيانات.

Fundamentals of Blocks in Notion

زي قطع الـ LEGO في مجموعة LEGO، كتل Notion هي القطع الفردية اللي بتمثل كل وحدات المعلومات جوه محرر Notion. وخصائص الكتلة هي اللي بتحدد إزاي المعلومات دي هتتنسق وتتنظم بالشكل اللي عاوزينه.

مصدر الصورة : Notion Engineering Blog

كل كتلة عندها الخصائص دي :

• الـ ID: كل كتلة ليها معرف فريد. ونقدر نشوف الـ ID الخاص بكتلة الصفحة (Page Block) في نهاية عنوان الـ URL في المتصفح. وبيتم استعمال الـ UUIDs (UUID v4) كمولد عشوائي للـ IDs في Notion.

• الـ Properties: وهي عبارة عن هيكل بيانات بيحتوي على بعض خصائص المخصصة لكتلة معينة. فالخاصية الأكثر شيوعًا هي الـ title، ودي اللي بتخزن محتوى النص لأنواع الكتل زي الفقرات والقوائم وطبعًا عنوان الصفحة. والأنواع الأكثر تعقيدًا من الكتل بتحتاج خصائص إضافية أو مختلفة.

• الـ Type: كل كتلة ليها نوع، وده اللي بيحدد إزاي الكتلة هتظهر ويتعملها Render بشكل مختلف، وإزاي هنفسر خصائص الكتلة. Notion بيدعم أنواع كتير من الكتل، واللي ممكن تشوف أغلبها في قائمة “new block” لما تدوس على زر + أو في قائمة /.

مصدر الصورة : Notion Engineering Blog

إلى جانب الخصائص اللي بتوصف الكتلة نفسها، كل كتلة بيكون عندها مجموعة من الخصائص اللي بتحدد علاقتها مع باقي الكتل وهنا ممكن نشوف الموضوع أشبه بـ Graph:

• الـ Content: ودي عبارة عن Array من معرفات الكتل (Block IDs) اللي بتمثل المحتوى جوه الكتلة دي، زي العناصر المتداخلة في قائمة نقطية أو النصوص جوه toggle فأشبه بالـ Children للـ Parent.

• الـ Parent: وده عبارة عن معرف الكتلة اللي هي الأصل للكتلة الحالية. أو بمعنى أدق الـ Parent of Current Block ، وكتلة الأصل بتستخدم فقط في صلاحيات الوصول (permissions).

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

أهلًا وسهلا بكم في العدد التسعين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

🌟 مواضيع النشرة لهذا الأسبوع 🌟

• Scaling PostgreSQL to Power 800 million ChatGPT Users 🚀

• OpenClaw: The AI that actually does things 🤖

• Layered Architecture 🏛️

Scaling PostgreSQL to Power 800 million ChatGPT Users 🚀

شركة OpenAI بقالهم سنين معتمدين على PostgreSQL كواحد من أهم الـ Data Systems اللي شغالة في الخلفية وبتشغّل منتجات أساسية جدًا زي ChatGPT و OpenAI API. ومع النمو السريع جدًا في عدد المستخدمين، الضغط على قواعد البيانات بيزداد بشكل Exponential. وخلال السنة اللي فاتت بس، الحمل على PostgreSQL زاد أكتر من 10 أضعاف، ومازال بيزيد بسرعة.

وفي خلال رحلتهم وهم بيطوروا الـ production infrastructure علشان تستحمل النمو ده، اكتشفوا حاجة مهمة:
وهي إن PostgreSQL يقدر يـ (scale) ويشيل workloads ضخمة جدًا من النوع الـ read-heavy أكتر بكتير ما ناس كتير كانت متخيلة.

النظام ده (اللي أصله اتعمل على إيد فريق علماء في University of California, Berkeley) مكنهم إنهم يخدموا traffic عالمي وضخم باستخدام single primary Azure PostgreSQL flexible server instance واحدة، ومعاها تقريبًا 50 read replicas متوزعين على أكتر من region حوالين العالم.

في رحلتنا انهاردة هنشوف مع بعض قصتهم وإزاي قدروا يعملوا scale لـ PostgreSQL في OpenAI عشان يخدم ملايين الـ queries في الثانية (QPS) لـ 800 مليون مستخدم، عن طريق optimizations دقيقة وهندسة قوية. وكمان هنشوف أهم الدروس اللي اللي نستفاد بيها في الرحلة دي.

Challenges in The Initial Design

بعد إطلاق ChatGPT، حجم الـ traffic زاد بشكل غير مسبوق. وعشان يواكبوا ده، اشتغلوا بسرعة على optimizations كبيرة على مستوى الـ application وعلى مستوى PostgreSQL نفسه، وكبروا حجم الـ instance (scale up)، وكمان زودوا عدد الـ read replicas (scale out).

الـ architecture دي قدرت انها تخدمهم كويس لفترة طويلة، ولسه مع التحسينات المستمرة بتديهم مساحة للنمو كويسة جدًا قدّام.

وقد ما الموضوع ممكن يبان غريب لكتير من الناس وإن single-primary architecture تقدر تشيل scale بحجم OpenAI، بس الحقيقة إن تطبيق الكلام ده عمليًا مش سهل. وفريق المهندسين في OpenAI شافوا مشاكل كتير و Incidents بسبب الـ overload في Postgres، وغالبًا السيناريو بيبقى شبه بعضه:

• مشكلة في إن الـ upstream تعمل spike مفاجئ في load على الـ database

• الـ cache layer تقع فيحصل cache misses على نطاق واسع وبالتالي الـ load يزيد على الـ database

• الـ expensive multi-way joins تستهلك CPU

• أو write storm بسبب feature جديدة نزلت

ومع زيادة استهلاك الموارد، بنلاقي ان الـ latency بتعلى، الـ requests تبدأ في الـ timeout والـ retries تزود الحمل أكتر، وبعدين ندخل في cycle ممكن تبوظ ChatGPT والـ API بالكامل.

Challenges With Write-Heavy Traffic

زي ما قولنا إن PostgreSQL ممتاز جدًا في الـ read-heavy workloads، ولكن ده معناه إن لسه فيه تحديات في الـ write-heavy workload. والسبب الأساسي هنا هو الـ MVCC أو الـ (multi-version concurrency control).

في PostgreSQL، أي update بيحصل حتى لو على field واحد، بيعمل نسخة جديدة من الـ row كله. ومع ضغط writes عالي، ده بيعمل:

Write Amplification

في PostgreSQL، أي UPDATE—event لو على column واحد—ما بيعدّلوش الـ row في مكانه.
بدل كده، النظام بيكتب نسخة جديدة كاملة من الـ row ويخلّي القديمة موجودة.

ده معناه إن: عملية الـ write من التطبيق بتتحول لعدة writes على مستوى الـ table، الـ indexes، والـ WAL فالـ write cost الفعلي أعلى بكتير من اللي ظاهر في الكود، وده اللي بنسميه write amplification.

Read Amplification

بسبب الـ MVCC، النسخ القديمة من الـ rows (dead tuples) بتفضل موجودة لحد ما تتشال.

لما query تعمل SELECT: بنلاقي إن PostgreSQL ممكن يمرّ على أكتر من version للـ row ويستبعد النسخ القديمة لحد ما يوصل للـ version الصح

فـ read واحدة منطقيًا، بتتحول لعمليات قراءة أكتر على مستوى الـ storage و CPU وده اسمه read amplification.

Table & Index Bloat

مع كثرة الـ updates: الـ dead tuples بتتراكم والـ indexes بتفضل شايلة references لبيانات اتحذفت والمساحة ما بترجعش بسهولة للـ OS

والنتيجة:

• حجم الـ tables والـ indexes يكبر

• الـ queries بتبقى أبطأ

• والـ disk I/O بيزيد

Index Maintenance Overhead

كل INSERT أو UPDATE:

• بيحتاج تحديث لكل index مرتبط بالـ row

• ومع MVCC، الـ indexes نفسها بتدخل في دايرة versions قديمة وجديدة

ولو الـ table عليه أكتر من index:

• فتكلفة الـ write بتزيد بشكل Linear مع عدد الـ indexes

• والـ CPU والـ disk usage بيعلى

• والـ autovacuum يبقى عليه شغل أكتر

Autovacuum Tuning Complexity

الـ autovacuum هو المسؤول عن التنضيف بمعنى تاني:

• إزالة الـ dead tuples

• تقليل الـ bloat

• الحفاظ على أداء الـ DB

ولكن لو كان aggressive بزيادة → بيزاحم الـ queries ولو كان conservative بزيادة → الـ bloat والـ latency بيعلوا

عشان كده autovacuum tuning واحد من أعقد أجزاء تشغيل PostgreSQL في الـ production.

Scaling PostgreSQL to Millions of QPS

عشان يقللوا الضغط على الـ writes، بدأوا يرحلوا الـ workloads اللي ينفع تتقسم (shardable) واللي فيها writes كتير لأنظمة sharded زي Azure Cosmos DB، وكمان عدلوا على الـ application logic عشان يقللوا أي writes ملهاش لازمة.

كمان، منعوا إضافة أي tables جديدة على PostgreSQL الحالي. وأي workload جديد بقى default يروح على الأنظمة الـ sharded.

ورغم كل التطوير ده، PostgreSQL لسه unsharded، وفيه single primary مسؤولة عن كل الـ writes. والسبب هو إن الـ sharding للـ workloads الحالية معقد جدًا، وعايز تغييرات كتيرة في مئات الـ endpoints، وممكن ياخد شهور أو سنين.

وبما إن معظم الشغل كان عندهم read-heavy، ومع شوية optimizations قوية، فالتصميم الحالي لسه مديلهم مساحة كافية للنمو. فكل بساطة الـ sharding لـ PostgreSQL ممكن يحصل في المستقبل، بس مكنش أولوية ليهم دلوقتي.

Reducing Load on The Primary

المشكلة:
الـ Single-primary لوحده بكل تأكيد مش هيعرف يعمل scale للـ writes. وأي spike في الـ writes ممكن يوقع الـ primary وبالتالي يأثر على ChatGPT والـ API.

فالحل:
بدوا يقللوا الحمل على الـ primary لأقصى درجة ممكنة وده من خلال الآتي:

• عمليات القراءة - reads بتروح على الـ replicas

• الـ reads اللي جوه write transactions بيخلوها optimized لإنها كده كده لازم تعدي على الـ Primary

• والـ write-heavy shardable workloads اتنقلت لـ CosmosDB زي ما وضحنا

• كمان صلحوا bugs كانت بتعمل redundant writes علشان يقللوا عمليات الكتابة قدر المستطاع

• استخدموا الـ lazy writes ومن اشهر الـ techniques لحاجة زي كده (batching, debouncing, write-behind-cache)

• وعملوا strict rate limits أثناء عمليات الـ backfilling لبعض الـ fields اذا دعت الحاجة لده عشان يقللوا الضغط على الـ writes.

Query Optimization

المشكلة:
الـ Queries التقيلة كانت بتاكل من الـ CPU جامد، ومع وجود الـ spikesالخدمة كانت بتبطّأ.

اكمل قراءة المقال

OpenClaw: The AI that actually does things 🤖

خلال الشهر اللي فات انتشر مشروع بين المبرمجين اسمه clawdbot ( اتعمله rebrand ل OpenClaw)واتعمله Stars علي Github بشكل غير طبيعي زي ما أنتو شايفين 🤷‍♀️

Open Claw هو مشروع مفتوح المصدر عشان تبني Personal Assistant أو AI Agent بيشتغل على جهازك أو السيرفرز بتاعتك، وتقدر توصله بمنصات محادثة مختلفة وتعمله prompting من عليها زي(WhatsApp, Telegram, Slack, Discord, Signal, iMessage، وغيرها).

فهو بس مش مجرد chatbot بتقدر تكلمه من الواتساب ولكن تقدر تديله مهام وأوامر ينفذها علي السيرفر أو الكمبيوتر بتاعك!

المشروع سهل الاستخدام جدًا ودا اللي شجع ناس كتير تستخدمه وتعدل فيه وتزودله Skills مختلفة. والمشروع بيتقسم لجزئين أساسيين:

• AI Gateway

وهي عبارة عن Interface بتشغل الـ Assistant وتربطه بالـ models (GPT/Claude) وأي نظام تشغيل.

• Agents & Skills

الـ Agent وهو اللي بيقدر ينفذ الأوامر.

الـ Skills وهي عبارة عن (Plugins) اللي بتوسّع مهام الوكيل.

مثال: Skill لإدارة ال Calendar أولإرسال رسائل على التليجرام .

ولكن قبل الاستخدام لازم نلفت نظرك عزيزنا المبرمج لكون عليه ملاحظات أمنية كبيرة لأنه عند صلاحيات وصول لأجزاء كبيرة من الSystem وأهمها ال Files Systems وزي ما يقدر ينفذ مهام مفيدة ممكن مع أي Skill فيها كود غير واضح أو من مصدر مجهول تكون خطر كبير علي بياناتك ونظامك ككل. عشان كدا لازم تقيمه من الناحية الأمنية كويس قبل استخدامه والأفضل إنك مستخدموش علي جهازك الرئيسي أو تعزله قدر الإمكان في VM وبدون صلاحيات الوصول لل Host. تقدر كمان تعمله allowlist بال Commands اللي يقدر يستخدمها ويكون مفيهاش خطر وأهم حاجة تراجع ال Skills كويس قبل استخدامها لأن بالفعل تم اكتشاف Skills كثيرة مليئة بال Malware علي ال Marketplace الخاص بالمشروع.

شاركونا تجربتكم معاه إذا استخدمتوه بالفعل بتستخدموه في مهام إيه وايه ال Security Measures اللي خدتوها.

Layered Architecture 🏛️

الـ Layered Architecture طريقة شائعة جدًا بنستخدمها علشان نرتب بيها الكود في أي software system. الفكرة ببساطة إننا بنقسم المشروع بتاعنا لكذا layer، وكل layer بيكون ليه وظيفة محددة، ومش بيكلم غير layer اللي تحته.

الـ layers دي ممكن تكون 1 أو 2 أو 3 ، فعدد الـ Layers مش بيفرق ولكن كلهم بيتبعوا نفس الـ Rule الا وهو ان كل Layer بتعتمد على الـ Layer اللي تحتها.

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

مميزات الـ Layered Architecture

في كذا ميزة للـ Layered Architecture:

1. الـ Code هيبقى أسهل في الفهم: لما كل حاجة تبقى في مكانها، تقدر بسهولة تعرف فين الـ business logic، فين الـ database access، وفين الـ UI.

2. الـ Testability: تقدر تختبر كل layer لوحده. يعني مثلًا تقدر تعمل unit testing للـ service layer اللي هيكون فيها الـ Business Logic بتاعك من غير ما تكون مرتبط بالـ Database.

3. الـ Maintainability وقابلية التعديل والتوسع: لو عايز تغيّر طريقة حفظ الداتا، ممكن تشتغل بس في الـ data access layer من غير ما تلمس باقي السيستم وده هيديق ثقة وأنت شغال.

4. الإنتاجية كـ Team: كل حد ممكن يشتغل على layer معينة في الـ Project من غير ما يأثر على باقي شغل الناس التانية خصوصًا لو بيشتغلوا على Features مختلفة.

أشهر Layers في أي Layered Architecture

الترتيب بيختلف من مشروع للتاني، بس غالبًا هنلاقي أغلب الحاجات دي:

1. الـ Presentation Layer (أو UI Layer)
   ودي اللي بتتعامل مع اليوزر، سواء كانت Web UI أو Mobile أو حتى Command Line. وفي حالة الـ Backend الـ Controller بتمثلنا احنا الـ UI لانها بتـ Represent البيانات للـ Frontend على هيئة JSON أو أي Data Format محددينه.

2. الـ Application Layer / Service Layer
   فيها الـ business logic بتاعنا، يعني القواعد اللي السيستم ماشي بيها. وكذلك ممكن تتضمن وجود الـ Domain / Model Layer والـ Entities

3. الـ Persistence / Data Access Layer
   ودي اللي بتتعامل مع الـ database أو أي data source تاني أو حتى APIs أو Web Services.

مثال بسيط

لو عندنا system بيحجز مواعيد لدكتور على سبيل المثال:

• فالـ UI بياخد من الـ user التاريخ اللي عايز يحجز فيه الميعاد.

• الـ Business Layer فيها الـ Logic واللي من خلاله بتشوف لو التاريخ ده الدكتور متاح فيه ولا لأ.

• الـ Data Access Layer بتشوف في الـ database المواعيد المحجوزة فعليًا والاتاحية بتاعة الدكتور وبعدين تخزن الميعاد بتاع الحجز لو فيه اتاحة.

ليه الناس بتقول إن Layered Architecture “قديم” أو “مش أفضل اختيار”؟

الـ Layered Architecture فعلاً كان هو الـ default من زمان، خصوصًا في التطبيقات الكبيرة زي اللي كانت بتتبني بالـ Java EE أو .NET، لأنه بسيط وسهل يتفهم. بس مع الوقت، ظهرت مشاكل معينة خلت الناس تدور على بدائل أفضل، زي Clean، Onion، وHexagonal.

طيب إيه مشاكله؟

رغم المميزات اللي قولناها، لكن فيه شوية مشاكل بتبان في الـ real world:

1. مبدأ الـ Dependency Inversion: في الـ layered architecture، الطبقات اللي فوق (UI مثلاً) بتعتمد بشكل مباشر على اللي تحتها (Services → Repositories → Database). وده بيخلي الـ business logic مربوط بحاجة زي SQL أو حتى ORM، وده بيصعّب التستينج وإعادة الاستخدام الا لو اضطرينا اننا نستعمل في الوقت ده الـ Dependency Inversion. عشان نكسر الاعتمادية دي.

اكمل قراءة المقال

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

شركاء النجاح:

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸🇸🇩

أهلًا وسهلا بكم في العدد التاسع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف،نشرتنا تساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع, هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات مقالات مختارة من اقرأ-تِك.

مواضيع النشرة لهذا الأسبوع:

1. All About Software Licenses

2. Serverless Architecture

3. How Meta Leverages AI For Efficient Incident Response

All about Software Licenses

في كل مشروع / مكتبة أو حتي لغة بنلاقي ال License file, أغلبنا مش بيهتم واللي بيهتم و بينشر مشاريع بشكل دوري غالبًا بيستخدم MIT بدون تفكير, النهارده هنشرح دور الرخصة وفايدتها وإزاي تقدر تختار أي License لمشاريعك من أشهر 5 رخص موجودة حاليًا.

الـ Software License هو الاتفاق القانوني اللي بيقول الناس مسموحلها تعمل إيه بالكود بتاعك وممنوع تعمل إيه؟

فايدة ال License بتكمن في نقطتين:

• بترّخص للناس استخدام الكود

• بتحمي “الملكية الفكرية” لل Code Owners وبتوضح ازاي الناس تقدر تستخدم ال Source code بدون التعدي علي حقوقهم.

  ---

  أنواع رُخص البرمجيات

الرخص كلها بتقع في واحد من التصنيفات دي و احنا مرتبينها من الأكثر سماحية للأقل

• Public Domain Licenses

  الرخص من النوع دا معناها إن الكود متاح للاستخدام من الجميع وبدون أي Copyrights بتقيده فالناس تقدر تستخدمه, التعديل فيه وبيعه كمان مسموح و أشهر هذه الرخص هي ال CC0

• Open Source (Permissive) Licenses

  رخصة ال Open Source كذلك بتسمح بالاستخدام والتعديل والمشاركة وكمان البيع ولكن لازم تحافظ علي اسم ال Code owners الأساسين في ال License أشهر مثال علي هذه الرخص هي ال MIT License

• CopyLeft Licenses

  النوع دا من الرخص يُعد أيضًا Open Source ولكن الهدف منه هو الحماية من إعادة البيع أو إعادة التوزيع, بمعني إنك تقدر تستخدم الكود بحرية ولكن مينفعش تغير فيه وتبيعه, أي كود مُشتق من الكود الأصلي لازم يتنشر تحت نفس الرخصة عشان نضمن “مجانية” الكود دايمًا. أشهر هذه الرخص هي ال GNU General Public License

• Proprietary Licenses

  • النوع دا من الرخص بتستخدمه الشركات وفيه بتتيح استخدام الكود أو الSoftware بمقابل مادي للمستخدمين وبتحد من التعديل في الكود أو توزيعه أو بيعه و بتحتفظ فيه بالحقوق دي لل Code Owners الأساسين فقط.

    ---

    MIT License

تعتبر أبسط وأقصر وأشهر الرخص و بتتيح للمبرمجين استخدام وتعديل وحتي بيع المنتجات اللي بتعتمد عليها ولكن لازم تسيب اسم صاحب الكود والـ license في المشروع. من أكبر مميزاتها إنها بتشجع الناس تستخدم و تتبني الكود وتطوره ك Open Source Project و دا بيساعد يتبني Community قوي لل .tool/Software, أكبر عيب ليها إن حد ممكن ياخد كودك ويعمله منتج مقفول ويبيعه وميديكش credit غير في license.

نستخدمها إمتى؟

• Libraries
  Open Source tools

• Side projects

• Startups

أشهر مشاريع بتستخدمها هي React، Next.js، Vue، Express

بتوضع غالبًا في ملف بعنوان LICENSE بدون بدون Extension في ال Root Directory بهذه الصياغة

MIT License

Copyright (c) <YEAR> >CODE OWNER NAME>

Permission is hereby granted, free of charge, to any person obtaining a copy

of this software and associated documentation files (the “Software”), to deal

in the Software without restriction, including without limitation the rights

to use, copy, modify, merge, publish, distribute, sublicense, and/or sell

copies of the Software, and to permit persons to whom the Software is

furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all

copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

SOFTWARE.

Apache License 2.0

الرخصة دي كمان من رخص ال Open Source وهي زي MIT بس أطول وأعقد شوية, الفرق الأساسي بينهم إن فيها Patent protection وإنها واضحة أكتر قانونيًا. من أكبر مميزاتها إنها آمنة للشركات عشان يتفادوا مشاكل ال Patent أو براءة الاختراع.

بنستخدمها إمتى؟

• في المشاريع الكبيرة لأنها Overkill لو المشروع بالفعل صغير

• مشاريع الشركات

• ال Tools اللي ممكن تدخل في نزاعات patents

أشهر مشاريع بتستخدمها هي Kubernetes، Kafka، Android

GPL (GNU General Public License)

الرخصة دي من رخص ال Copyleft فهي بردو رخصة Open source ولكن مع تشديد علي جزئية إعادة البيع أو التوزيع. لأنها بتنص إنك لو هتستخدم ال Source code/ Software في إنتاج Code / Software جديد لازم الكود أو البرنامج الجديد يخضع لنفس الرخصة يعني بمعني أصح يكون هو كمان Open Source . ودي بتبقي مشكلة كبيرة وميزة كبيرة في نفس الوقت

هي عيب أو مشكلة لو أنت عاوز تبيع أو تعمل Paid Subscriptions علي الخدمة الجديدة, ولذلك الشركات بتهرب منها. وكمان لو أنت عاوز أكبر عدد من الناس يتبني الكود فدا بيحدهم ويخليهم يفكروا قبل استخدامه.

و هي ميزة كبيرة لأنها بتجبر أي حد يعمل أي تعديل إنه يرجعه لل Community و بتحافظ علي إن الكود يكون Open Source للأبد

باختصار لو استخدمت الكود بتاعي = مشروعك كله لازم يبقى Open Source

بنستخدمها إمتى؟

• استخدمها في المشاريع التعليمية

• Anti-corporate misuse

أشهر مشاريع بتستخدمها هي Linux Kernel

في نسخة أكثر تساهلاً منها وهي LGPL (Lesser General Public License ) وبيها تقدر تستخدم المكتبة في مشروع مقفول بس لو عدّلت المكتبة/ الكود نفسه لازم افتح التعديلات للكل و دي بتكون مناسبة أكثر لو هتعمل Plugin لأنك عاوز الناس تستخدمه في مشاريعها ولكن لو في تعديل في كود ال Plugin نفسه لازم الCommunity يطلع عليه.

Proprietary License

ودي هي الرخص المقفولة وفي منها صياغات كثيرة أشهرهم الEnd User License Agreement (EULA) و ال Subscription License و بيها بتدي الناس حق الاستخدام فقط, وبتحتفظ بكامل حقوق التعديل والنشر والبيع.

أغلب ال Software اللي بتستخدم الرخصة دي الكود بتاعها بيكون Private ومش باين للناس اللي الناس تقدر توصله هي الخدمة أو ال Software بس مش ال Source code نفسه. ولكن في حالات خاصة زي ال SDKs مثلاً فالكود بيكون ظاهر لأن اللي هيستخدمه Developers لكن ميقدروش يعدلوه أو يعيدوا استخدامه وتوزيعه.

في الختام

فهم ال Software License أساسي لكل مبرمج بينشر تطبيقات لأنه مش بس بينظم استخدام الناس للكود بتاعك وبيخلي فيه شفافية في موضوع حقوق ملكية الكود. ولكنه كمان بيأثر علي مدى انتشار و تبني الكود من ال Community فزي ما شوفنا في مبرمجين و Engineering leads كتير بتبعد عن استخدام بعض الأدوات بس بسبب ال License المنشورة تحتها واللي ممكن تحدهم من نشر تطبيقاتهم. استخدام الرخصة المناسبة كمان بيحمي أهدافك من المشروع فال proprietary licenses بتحمي جزء ربحيتك من الكود و ال Open Source Licenses بتحمي انتشار ونفع الكود دا للمجتمع التقني بشكل عام و الاتنين هتحتاجهم في وقت من الأوقات.

روابط مفيدة

موقع Choose a License يقدم قائمة كاملة بكل الرخص المتاحة لل Open Source

Serverless Architecture

من زمان والناس نفسها انه تتيح للـ Developers الفرصة أنهم يركزوا على جزء الـ Development وانهم يكونوا قادرين على بناء Services قوية ويبدعوا فيها بدون عوائق الـ Infrastructure أو التفكير فيها ..

بحيث يركزوا على الـ Core Product أو المنتج اللي مهتمين بيه بمعنى أصح ، من غير ما يهتموا بازاي هيديروا البنية التحتية للـ Product ده

💡وعشان كده ظهر الـ Serverless Architecture كطريقة أو نمط للتصميم يسمح للـ Developers بتحقيق الأمنية دي , وإن هم يبقوا قادرين على بناء الـ Software بدون الاهتمام بالبنية التحتية واداراتها

ازاي Serverless Architecture بتشتغل ؟

كلنا عارفين أن الـ Servers عشان تسمح للـ Users بإنهم يتواصلوا مع أي تطبيق والـ Business Logic بتاعه , ده هيتطلب Resources وبنية تحتية هتطلب موارد واهتمام وادارة زي :

• Server Hardware

• Security Updates

• Backups

• Resources Management

ومن خلال اتباع الـ Serverless Architecture احنا بنشيل العبء ده كله وبنخلي الـ Developers يهتموا بس بجزء الـ Business Logic / Core Product وانهم يكتبوا الـ Application Code وبنشيل عبء البنية التحتية ونخليها مسئولية Third Party Provider زي الـ Cloud Services اللي موجودة دلوقتي ومن أشهرهم AWS , Google Cloud , Microsoft Azure

أحد أشهر الـ Serverless Architecture هي الـ FaaS واللي هي اختصار لـ Function as a Service , واللي من خلالها الـ Developers بيكتبوا الـ Application بتاعهم والـ Core Product اكنه بالظبط عبارة عن مجموعة محددة من الـ Functions اللي بتتنفذ واللي بيحصلها Triggering من خلال الـ Events زي مثلا ان حد يبعت رسالة لحد , أو ان يتبعت Email أو ان يحصل HTTP Request بشكل معين.

وبالشكل ده انت كـ Developer مسئول عن :

اكمل القراءة

How Meta Leverages AI For Efficient Incident Response

هنشوف في المقال ده ازاي فريق المهندسين في Meta اشتغلوا على انهم يسرعوا من عملية التحقيق في مشاكل الـ System Reliability باستخدام نظام جديد مدعوم بالـ AI عشان يحددوا الـ Root Cause بتاع المشكلة.

النظام ده بيستخدم خليط ما بين “heuristic-based retrieval” و “large language model-based ranking” عشان يسرع عملية تحديد السبب الجذري أثناء التحقيقات. ومن خلال اختبار النظام، فريق المهندسين في Meta لقى إنه وصل لدقة بتوصل لـ 42% في تحديد الأسباب الجذرية للتحقيقات وقت ما بتبدأ علطول، خصوصًا المشاكل المتعلقة بالـ “web monorepo”.

والـ الـ heuristic-based retrieval هو أسلوب بيستخدم قواعد وإرشادات معينة، أو ما يُسمى بالـ “heuristics”، عشان يسهل عملية البحث والتصفية في كميات كبيرة من البيانات أو التغييرات. الفكرة الأساسية في الـ “heuristics” هي إنها مش بتعتمد على الدقة المطلقة، ولكنها بتعتمد على تقنيات سريعة وفعالة لتقليل مساحة البحث بشكل كبير، حتى لو أدى ده لتقليل دقة بسيطة في النتائج.

فالتحقيق في المشاكل حاجة أساسية عشان نضمن استقرار النظام، وده ضروري عشان نحل المشاكل بسرعة. فعشان كده Meta بتستثمر في تطوير أدوات التحقيق بتاعتها زي أداة “Hawkeye” اللي بيستعملوها داخليًا عشان يعملوا “debugging” للـ Workflows الخاصة بالـ machine learning.

شكل الـ Investigations في Meta

كل تحقيق بيكون مختلف عن التاني، ولكن مما لاشك فيه أن تحديد السبب الجذري للمشكلة هو ضروري جدًا عشان نعرف نحل المشكلة بطريقة صحيحة وسليمة. فالتحقيق في المشاكل اللي بتحصل في أنظمة معتمدة على الـ “monolithic repositories” بيكون صعب من ناحية الـ Scalability بكل تأكيد، وده عشان بيبقى فيه عدد كبير من التغييرات من فرق مختلفة. بالإضافة لكده، الأشخاص اللي بيحلوا المشكلة محتاجين يبنوا فكرة عن المشكلة عشان يبدأوا يشتغلوا عليها، زي إيه اللي اتعطل، الأنظمة اللي متأثرة، والناس اللي ممكن تتأثر بالمشكلة. فلازم يكون معاهم Context واضح عشان يقدروا يفهموا طبيعة المشكلة اللي بيتعاملوا معاها.

التحديات دي بتخلي عملية التحقيق في الـ (anomalies) معقدة وممكن تاخد وقت طويل. فالـ AI بيوفر فرصة لتبسيط العملية دي، وتقليل الوقت اللي محتاجينه، وكمان مساعدة الأشخاص اللي بيحققوا في المشكلة يقدروا ياخدوا قرارات بشكل أفضل. فهم ركزوا على بناء نظام قادر على تحديد التغييرات في الكود اللي ممكن تكون السبب الجذري لمشكلة معينة.

اكمل القراءة

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸🇸🇩

أهلًا وسهلا بكم في العدد الثامن والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

سواء كنت مهندس برمجيات مبتدئ أو محترف،نشرتنا تساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع, هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات مقالات مختارة من اقرأ-تِك.

مواضيع النشرة لهذا الأسبوع:

1. How VPN Works

2. How Slack Handles Billions of Tasks in Milliseconds

3. Idempotency in APIs

How VPN Works

المبرمجين ليهم علاقة غريبة بالـ VPN بنستخدمه بشكل يومي أو شبه يومي بس في نفس الوقت مش عارفين كل تفاصيله لأننا مش بتوع شبكات, النهارده هنتكلم عن أهم الحاجات اللي لازم أي مبرمج يعرفها عن الـ VPN: هو إيه، بيحل مشاكل إيه، بيشتغل إزاي، مميزاته وعيوبه، وإزاي تختار VPN مناسب من غير ما تقع في فخ التسويق .

ما هو ال VPN

VPN اختصار لـ Virtual Private Network، وهو ببساطة طبقة وسيطة بتعمل نفق مشفّر (Encrypted Tunnel) بين جهازك وبين الإنترنت أو شبكة خاصة.

المشكلات التي يحلها ال VPN

الـ VPN لم يظهر أساسًا عشان الخصوصية الشخصية أو فتح المواقع المحجوبة زي ما هو شائع اليوم، بل ظهر كحل تقني لمشكلة واضحة جدًا في بيئة الشركات.

ودا لأن كل شركة بيكون عندها Private Network عليه مواردها وأجهزتها ولما موظف يسافر أو يشتغل من فرع الشركة في مكان تاني مبيقدرش يوصل للشبكة الداخلية من خلال الإنترنت لأن دا اتصال غير آمن. عشان نحل المشكلة دي كان في حل Physical باننا نوصل سلك لجهاز الموظف دا أو بالفرع التاني “طبعًا حل غير منطقي” فالحل بدلً من السلك إننا نعمل Tunnel أو أنبوبة آمنة من خلال الانترنت بين جهاز الموظف والشبكة الداخلية للشركة نمرر فيها البيانات المهمة بتاعتنا ووقتها بيظهر جهاز الموظف كأنه جزء من شبكة الشركة ومن هنا جه الإسم Virtual Private Network

مع الوقت تطور ال VPN وإلي جانب ال Remote Private Network Access أصبحت استخداماته بتشمل:

• أداة لزيادة خصوصية تصفحك علي الانترنت

  ودا لأن ال Internet Service Provider (ISP) بتاعك بيقدر في الطبيعي يشوف المواقع اللي انت بتزورها وتقدر كمان ال Services اللي انت بتستخدمها تتبع موقعك الجغرافي, ال VPN بيحل المشكلة دي لأنه بيغير ال IP Address بتاعك وبيبان ال VPN Server IP و بالتالي بيكون تتبعك أصعب و ال ISP لا يزال بيشوف مقدار الترافيك اللي بتستخدمه ولكن ميقدرش يعرف تفاصيل أكثر من كدا.

• فتح Services مقفولة جغرافيًا

- معظم دول العالم بتفرض قيود على المحتوى اللي تقدر توصله وأنت بداخل البلد فمثلاً متقدرش تفتح Youtube في الصين من غير VPN. ال VPN بيحل المشكلة دي لأنه زي ما قولنا ال ISP مش عارف أصلاً أنت بتزور مواقع ايه وبالتالي ميقدرش يحجب موقع هو مش عارفه.

-كمان Payment Services كتير بتكون محدودة جغرافيًا كوسيلة حماية للخدمات دي من ال International Hacking فلو أنت مبرمج ومحتاج تختبر Integration مع خدمة دفع في بلد تانية فالـ VPN بيديك حرية تختبر الخدمة/المنتج من أكتر من Location.

• الأمان على الشبكات العامة

  لو شغال في كافيه أو Co-working Space أو في فندق مثلاً علي Public WIFI فبتكون عرضة لهجمات زي Packet Sniffingو Man-in-the-Middle Attacks وعشان كدا ضروري تستخدم VPN خصوصًا لو بتستخدم Credentials/Tokens/SSH

المميزات

• تشفير الاتصال، كل ال Traffic بتاعك مع استخدام VPN بيكون Encrypted فلو أنت بتستخدم موقع HTTP و لا يدعم HTTPS فاستعمال VPN خطوة لا غنى عنها.

• إخفاء الـ IP الحقيقي

• الوصول إلى الشبكات المغلقة Private Networks زي سيرفرات الشركة وغيرها

• مرونة في اختبار وتطوير البرامج المختلفة

• تقليل المخاطر وقت استخدام الشبكات العامة

العيوب

• انخفاض السرعة، دا لأن ال Latencey بتكون أعلى وال Bandwidth أقل, ودا لأن ال VPN بيعمل Wrapping لكل ال Packets ب Headers إضافية وبيشفرها.

• الاعتماد على طرف ثالث، وقت ما تعتمد على ال VPN Provider فأنت كل ال Traffic بتاعك بيعدي من على سيرفراته وبالتالي …..

اكمل القراءة مجانًا

How Slack Handles Billions of Tasks in Milliseconds

المقدمة

لو جينا نبص على Slack هنلاقيها بتستخدم job queue system علشان تنفّذ الـ business logic اللي بياخد وقت كبير ومينفعش يتنفذ جوه الـ web request الطبيعي. والسيستم ده جزء أساسي في البنية التحتية بتاعت Slack، وكمان بيتم استعماله في كل message بتتبعت، وكل push notification، وكل URL unfurl، والتذكيرات، وحساب الفواتير وغيرها كتير من المميزات اللي Slack بتقدمها.

في أغلب الأيام اللي بيكون عليها ضغط كبير، السيستم بيعالج أكتر من 1.4 مليار job، بمعدل بيوصل لـ 33,000 job في الثانية. وده رقم ضخم جدًا ومع ذلك تنفيذ الـ jobs بياخد من ميلي ثانية لحد دقايق أحيانًا.

الـ job queue القديم اللي كانوا بيستخدموه من أول ما Slack بدأت، قدر يمشي معاهم الرحلة دي وهم بيكبروا. وكل ما كانوا بيقابلوا مشاكل في الـ CPU أو الـ memory أو الـ Network، كانوا بيعملوا scaling، لكن الـ Architecture الأساسي للـ System فضل زي ما هو تقريبًا.

من حوالي سنة، حصل عندهم production outage كبيرة بسبب الـ job queue. كان فيه مشكلة في الـ database layer، خلت تنفيذ الـ jobs يبقى بطيء جدًا، وده خلى Redis يوصل لأقصى سعة من الـ memory الممكنة. ولما مابقاش فيه memory فاضية، مقدروش يحطوا jobs جديدة، وبالتالي كل حاجة كانت معتمدة على الـ job queue وقعت.

اللي زوّد الطين بلة إن حتى عملية الـ dequeue كانت محتاجة memory، فكده الموضوع كان بايظ من الناحيتين لا عارفين يزودوا jobs جديدة ولا حتى يعملوا dequeue للـ jobs الموجودة بسبب ان مفيش free memory ، فحتى بعد ما مشكلة الـ database اتحلت، الـ queue فضلت واقفة، واحتاجت تدخل يدوي عشان تشتغل تاني.

الـ incident دي خلتهم يعيدوا تقييم الـ job queue system كله، وبدأوا يخططوا لتغيير كبير في التصميم، لكن من غير ما يوقفوا أي service، أو يعملوا migration ضخم، وكمان يوفروا سبيل لأي تحسينات مستقبلية ممكن يضيفوها بعدين.

Slack’s Initial Job Queue System Design

الـ system design القديم بتاع الـ job queue عند Slack كان ممكن ترسمه بالشكل ده، وغالبًا هيكون مألوف لأي حد اشتغل أو استخدم Redis task queue قبل كده.

Job’s Lifecycle

1. لما الـ web app بيعمل enqueue لـ job: أول خطوة بتكون إنه ينشئ identifier (وده unique identifier) مبني على نوع الـ job والـ arguments اللي جاية معاها.

2. الـ enqueue handler بيختار واحد من Redis hosts: والاختيار بيتم بناءً على استعمال hash من الـ identifier ده وكمان الـ logical queue اللي تخص الـ job دي ، يعني كل job بتروح على Redis معين حسب نوعها ومحتواها.

3. في Redis، بيستخدموا data structures علشان يعملوا deduplication وبيكون limited شوية: فلو فيه job بنفس الـ ID أصلًا موجودة جوه الـ queue الطلب الجديد بيتلغى. ولو مفيش واحدة زيها الـ job بتضاف للـ queue.

4. الـ Workers دايمًا بتعمل polling على Redis clusters: في الـ background، بيكون فيه pools من الـ (worker machines) متابعة وبتراقب الـ queues، ومستنية يظهر أي job جديدة عشان تشتغل عليها. أول ما واحدة من الـ workers تلاقي job في queue من اللي هي بتراقبهم:

   • بتنقلها من pending queue لـ in-flight list (يعني الشغل اللي شغال عليه دلوقتي).

   • بتبدأ تشغّل (asynchronous task) علشان تنفّذ الـ job دي.

5. بعد ما الـ task تخلص: الـ worker بيشيل الـ job من قائمة in-flight jobs ولو الـ job فشلت وحصلها (failure) بتتحط في queue خاص بإعادة المحاولة (retry queue). وبيتم إعادة المحاولة عدد معين من المرات، لحد ما يا إما تنجح ، يا إما تتحط في قائمة تانية اسمها permanently failed jobs (اللي بيتم مراجعتها يدويًا علشان يشوفوا هي فشلت ليه، ويحلوها لو محتاجة تدخل بشري).

Architectural Challenges

بعد ما عملوا post-mortem للـ outage اللي حصل، Slack وصلت لاستنتاج واضح:
“الـ scaling بالنظام الحالي مش هينفع، ولازم نشتغل على تغييرات جذرية أكتر.”

طب إيه هي المشاكل والقيود اللي اكتشفوها؟

1. مبدئيًا كده Redis كان مفيهوش مساحة كفاية، خصوصًا من ناحية الـ memory: فلو عدد الـ jobs اللي بتتعمل enqueue بقى أسرع من الـ dequeue لفترة طويلة، السيستم بيستهلك الذاكرة كلها. ولما الـ memory تخلص، حتى dequeueing ميبقاش ممكن (لأنه هو كمان بيحتاج memory علشان يحرك الـ job لقايمة الـ processing).

2. الـ Redis connections كانت عاملة complete bipartite graph: كل client (أي system بيعمل enqueue) لازم يكون متصل بـ كل Redis instance. وده معناه إن كل client لازم يعرف كويس كل تفاصيل Redis nodes، ويكون عنده config مظبوط ومحدّث دايمًا.

3. الـ Job workers ماكانوش يقدروا يعملوا scaling لوحدهم من غير Redis: كل ما بنزود عدد الـ workers بنحط load أكتر على Redis.

4. الاختيارات اللي كانوا عاملينها قبل كده في الـ Redis data structures كانت مكلفة: علشان نعمل dequeue من الـ queue، كان لازم نعمل عمليات تتناسب مع الـ queue length نفسه. أو بمعنى أبسط (كل ما الـ queue يطول، كل ما بيبقى أصعب إننا نفضيه).وده كان مخلي الأداء يبقى أسوأ مع الوقت.

5. الـ semantics والـ QoS (quality-of-service) guarantees اللي بتتقدم للـ app والـ platform engineers كانت مش واضحة: فالـ async job processing كان مفروض يكون حاجة أساسية في الـ architecture ، لكن في الواقع، المهندسين كانوا بيترددوا يستخدموه علشان سلوكه مكنش متوقع. فأي تغيير حتى ولو بسيط (زي موضوع deduplication المحدود) كان high-risk جدًا، لإن فيه jobs كتير بتعتمد عليه علشان تشتغل صح.

طب يعملوا إيه؟ إيه الحل؟

كل مشكلة من دول كانت ممكن تروح في كذا اتجاه من الحلول — من مجرد تحسينات بسيطة، لحد عملية الـ Re-Write للسيستم من الصفر. لكن Slack قرروا يركزوا على 3 نقاط رئيسية ممكن تحل المشاكل اللي ليها أولوية:

1. استبدال Redis بـ durable storage (زي Kafka): علشان يبقى فيه buffer يتحمّل ضغط الـ memory، وميفقدش الـ jobs لو حصل أي overload. وده لإن Kafka يقدر يحتفظ بالبيانات دي بأمان على الـ disk، بدل ما كل حاجة تبقى in-memory.

2. بناء scheduler جديد خاص بالـ jobs: ده هيساعدهم يقدّموا guarantees أفضل من ناحية QoS. وكمان يقردوا يوفّرا features بأريحية زي مثلًا الـ rate-limiting، والـ prioritization في تنفيذ jobs.

3. فصل تنفيذ الـ jobs عن Redis تمامًا: كده أصبح بإمكانهم إنهم يعملوا scale للـ job execution من غير ما يضطروا يتعاملوا مع Redis نفسه.

Incremental Change or Full Rewrite

فريق Slack كانوا عارفين إن تنفيذ كل التحسينات اللي خططوا ليها هيحتاج تغييرات كبيرة في الـ web app وفي الـjob queue workers. علشان كده الفريق قرر يركز على أهم المشاكل اللي عنده، وياخد خبرة عملية مع أي جزء جديد من النظام بدل ما يحاول يعمل كل حاجة مرة واحدة.

اكمل القراءة

Idempotency in APIs

عند تصميم واجهات برمجة التطبيقات (APIs)، يُعد مفهوم الـ Idempotency من المفاهيم المُهمة لضمان استقرار الأنظمة و سلامة بياناتها، لا سيما في الأنظمة الموزعة حيث ترتفع احتمالية تكرار الطلبات نتيجة لمشاكل الشبكة Network Failures أو إعادة المحاولة التلقائية Retries.

في هذا المقال سنستكشف مفهوم الـ idempotency، أهميته في تصميم الـ APIs، الآليات المتبعة لتحقيقه و متى يُستخدم.

ما هو الـ Idempotency؟

الـ Idempotency هو مفهوم مُستعار من الرياضيات، و يعني أن تنفيذ عملية مُعينة مرة واحدة أو عدة مرات سيُعطي نفس النتيجة. في سياق الـ APIs هذا يعني أنه يُمكن تنفيذ نفس الطلب Request عدة مرات دون أن يُؤثر ذلك على حالة النظام أو ينتج عنه آثار جانبية غير مرغوب فيها.

// idempotent operation
const result = Math.abs(-5); // النتيجة: 5
const result2 = Math.abs(-5); // النتيجة: 5 (نفس النتيجة)

// non-idempotent operation
let counter = 0;
const increment = () => ++counter;
increment(); // النتيجة: 1
increment(); // النتيجة: 2 (نتيجة مختلفة)
 

أهمية الـ Idempotency في الـ APIs

• أحيانا يفقد العميل تأكيد نجاح العملية بسبب مشاكل الشبكة فيُعيد إرسال الطلب. لذلك يجب أن يتحمل النظام تكرار نفس الطلب دون تكرار التنفيذ.

• بعض الأنظمة تعتمد على إعادة المحاولة تلقائيا عند فشل الطلب مؤقتا مما يجعل دعم الـ idempotency ضروريا لتفادي تكرار غير مرغوب فيه.

• في العمليات الحساسة كتنفيذ المعاملات المالية قد يؤدي تكرار التنفيذ إلى أخطاء خطيرة إن لم يُراعى مفهوم الـ idempotency.

• في الأنظمة الموزعة تكرار الطلبات أمر شائع بسبب الأعطال الجزئية، لذلك يُدعم الـ idempotency موثوقية النظام و سلامة بياناته.

اكمل القراءة مجانًا

بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد السابع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

Migrating the Jira Database Platform to AWS Aurora

في التجربة دي هنحكي تجربة Atlassian في الـ migration الخاص بملايين الـ Jira databases لـ AWS Aurora على نطاق ضخم وبأقل تأثير ممكن على المستخدمين.

فهنشوف إزاي Atlassian عملت migration لحوالي 4 مليون Jira databases لـ AWS Aurora على scale كبير جدًا وبـ minimal user impact، وإيه الـ technical challenges والاستراتيجيات والنتايج اللي ساعدتهم في تحقيق الـ reliability والـ performance والـ cost efficiency.

السؤال الأساسي هنا: إزاي تعمل migration للـ database من غير ما المستخدمين يحسّوا؟

في Atlassian، هما بالفعل بيعملوا database migrations على scale كبير كجزء من شغلهم اليومي الخاص بالـ server rebalancing عشان يحافظوا على توزيع الـ load بشكل متوازن على الـ Jira database fleet.

وفي المتوسط بيعملوا migration لحوالي 1,000 قاعدة بيانات كل يوم … ومن غير أي انقطاع محسوس عند المستخدمين.

بس المرة دي ظهر ليهم تحدي جديد:
إزاي نعمل migration لملايين الـ databases، وبـ minimal impact على المستخدمين؟

Background

Jira بتستخدم Postgres كـ backing store. يعني كل حاجة في Jira تقريبًا من الـ: issues, projects, workflows, custom fields… كله متخزن في database. والـ architecture عندهم: one database per Jira tenant.

وده مش architecture منتشر قوي، بس Atlassian اختارته عشان:

• الـ isolation بتاعه أعلى

• والـ scalability كذلك أفضل

• وكمان الـ operational control أقوى على scale ضخم

وده كمان بيخلّي ضمان إن البيانات بتاعة tenant ما تتشافش بالغلط أو بسوء نية من tenant تاني، وكمان بيسهّل إنهم يعملوا horizontal scaling ويوازنوا الـ load ويحسنوا الـ performance ل tenants بأحجام مختلفة ومتفاوتة.

فهم موزعين 4 مليون database على حوالي 3,000 PostgreSQL servers في 13 AWS regions. وبما إن PostgreSQL عندهم شغّال على AWS RDS for PostgreSQL أو AWS Aurora PostgreSQL، فهم غالبًا ما بيقولوش “server” وبيستخدموا كلمة instance بدلها.

وبشكل دوري بيعملوا migration للـ databases جوّه الـ fleet بشكل مستمر عشان موضوع الـ rebalancing، وده من خلال طريقتين:

• للـ small databases: بيعملوا backup + restore بسرعة على destination instance

• للـ larger databases: بيعملوا logical replication بين source وdestination، وده بيخليهم ينسخوا البيانات على مهلهم والـ database والـ tenant شغالين طبيعي بدون أي مشاكل.

وبرضه المتوسط عندهم: 1,000 database migration كل يوم مع minimal interruption.

وعندهم تقسيمة شبيهة باللي AWS Well-Architected Framework:
أغلب الـ tenants على shared infrastructure، وعدد صغير من الـ very large tenants على dedicated infrastructure. والـ very large tenants دول محتاجين resources ضخمة (أكتر من اللي ممكن يتوفر على RDS instance)، فكانوا متشغلين على Aurora PostgreSQL من زمان.

في أواخر 2023، بدأوا يدرسوا مشروع إنهم يعيدوا عمل نفس الكلام على باقي الـ fleet من الـ databases لـ Aurora PostgreSQL عشان يحققوا أهداف قوية في الـ cost والـ reliability والـ performance.

والفرق المهم هنا: إن إعدادات الـ RDS عندهم كانت بتسمح بـ single instance فعليًا في الاستخدام، إنما Aurora تقدر تستفيد من الـ writer والـ reader (وممكن multiple readers) في نفس الوقت. وده عمليًا خلّاهم يقدروا يصغّروا من الـ instance sizes للنص… مع كفاءة أعلى.

كمان Aurora عندها SLA أفضل: 99.99% بدل 99.95%، وعندها autoscaling وقت الـ peak لحد 15 readers (وده بيحصل عندهم فعلاً ساعات). وبعد ماكانت النتايج إيجابية قرروا يكملوا في رحلتهم.

Migration Design

فريق المهندسين في Atlassian كان عندهم اهداف واضحة، بس كمان حطّوا أهداف أثناء التنفيذ:

• Minimise tenant downtime

• Minimise cost عن طريق التحكم في كمية migration-related infrastructure

• يخلصوا في وقت معقول (عمليًا: كام شهر)

وبناءً عليه قرروا إن أفضل طريقة لكل RDS PostgreSQL Multi-AZ DB instance إنها تتنقل لـ Aurora كالتالي:

1. يضيفوا DB instance read replica للـ RDS PostgreSQL instance، والـ replica تـ synchronise data لـ new Aurora cluster volume (ودي feature موجودة في RDS).

2. يعملوا cutover في window مناسبة عن طريق إنهم يعملوا promoting للـ read replica دي وتبقى standalone Aurora cluster.

هم سمّوا العملية دي: conversion من RDS instance لـ Aurora cluster. وشكل الموضوع قد يبدوا غريب للبعض او ساذج شوية ولكن على scale Atlassian الدنيا بتبقى أعقد بكتير جدًا.

Conversion

أول تعقيد: الـ clusters عندهم بتشيل لحد حوالي 4,000 databases في الـ cluster الواحد، وكل database هي عبارة عن tenant مختلف زي ما اتفقنا. وعلشان عاوزين نعمل migration لملايين ال databases فلما نيجي ننقل كل cluster هنلاقي اننا عاوزين نـ migration 4,000 tenant مرة واحدة.

يعني لما نيجي نعمل “promotion” للـ database replica ونحوّلها لـ standalone Aurora cluster، لازم عملية الـ cutover يحصل “مرة واحدة” لكل الـ 4,000 tenants، وكل واحد ليه:

• unique connection endpoint

• unique credentials

وكمان لازم يحدّثوا الـ Jira application (الي شغال على EC2 instances) عشان يستخدم الـ endpoint الجديد لكل tenant… وبطريقة تضمن 100% إن مفيش أي writes هتروح بالغلط للـ database القديمة.

فعشان يضمنوا ده، عملية cutover كانت بتعمل الآتي:

• lock out لكل SQL user على source instance

• تكمل promotion للـ Aurora cluster

• وبعدها تعمل unlock للـ SQL users بس على الـ destination

وكل ده كان orchestrated بـ AWS Step Function بتعمل safety checks قبل وأثناء وبعد عملية الـ conversion، وعشان لو أي حاجة غلط ممكن تحصل يرجعوا بسرعة للوضع الطبيعي. وبعد الـ conversion كانوا بيراقبوا الـ customer traffic كام ساعة عشان يتأكدوا إن كل حاجة تمام.

وعشان الـ cutover يبقى سريع: استخدموا feature flags. فلما كل حاجة تبقى جاهزة، الـ feature flag بتعمل override للـ tenants’ database endpoints على application servers فورًا بدل الـ periodic refresh البطيء المعتاد.

وبسبب ده (وكمان لأن initial synchronisation كان معمول قبل الـ cutover)، قدروا يقللوا cutover لـ أقل من 3 دقائق لكل مرة وده كان كمان جوّه الـ SLAs واللي هي اختصار للـ Service Level Agreements لأكبر instances عندهم.

Continue Reading

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد السادس والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

Modernizing Reddit’s Comment Backend Infrastructure

لو عندك system كبير وlegacy، غالبًا أسهل جزء في الـ migration هو الـ reads… لكن أول ما تيجي ناحية الـ writes، كل حاجة بتبقى حسّاسة جدًا: data integrity، caches، events، وخصوصًا لو عندك guarantees لازم ما تقعش أبدًا زي CDC events.

في المقال ده هنمشي خطوة بخطوة في تجربة Reddit وهي بتعمل modernization لـ comment backend: إزاي نقلوا من legacy Python service لخدمات Go microservices، وليه الـ tap compare لوحده مش كفاية في الـ write endpoints، وإزاي فكرة بسيطة زي “sister datastores” خلتهم يقدروا يعملوا validation حقيقي من غير ما يبوّظوا production data. وفي الآخر هنشوف إيه اللي اتحسّن فعلًا (خصوصًا في p99 latency)، وإيه الدروس اللي طلعوا بيها للـ Migrations اللي جاية.

Background

في Reddit فيه 4 Core Models هما اللي بيشغّلوا تقريبًا كل الـ use cases: Comments, Accounts, Posts, Subreddits. الأربعة models دول كانوا بيتهندلوا من legacy Python service قديم، والـ ownership بتاعه كان متقسم بين كذا team.

وفي 2024، الـ legacy Python service ده كان عنده تاريخ طويل من مشاكل كتير متعلقة بالـ reliability والـ performance. وكمان موضوع الـ ownership والـ maintenance بقى تقيل ومرهق على كل التيمز اللي شغّالة عليه. عشان كده فريق reddit قرر ينقل لحاجة أحدث: زي domain-specific Go microservices.

في النص التاني من 2024، الفريق بدأ يعمل fully migrating لأول comment model. وده منطقي جدًا… لان الـ Redditors بيحبوا يعبّروا عن رأيهم في الـ comments، فطبيعي إن الـ comment model هو الأكبر وعنده أعلى write throughput، فكان candidate قوي إنه يبقى أول migration يشتغلوا عليه.

How

الـ Migration بتاع الـ read endpoints عادة بيبقى مفهوم وسهل نسبيًا؛ وهم بيستخدموا tap compare testing. وفكرة الـ tap compare باختصار: هي انهم بيتأكدوا إن الـ new endpoint بيرجع نفس الـ response اللي بيرجعه الـ old endpoint من غير ما يأثروا على المستخدمين بالسلب.

وبيعملوا ده عن طريق:

• توجيه نسبة صغيرة من الـ traffic للـ new endpoint

• الـ new endpoint يطلع response

• بعد كده (من جوّه) يعمل call للـ old endpoint

• يحصل comparison بين الـ responses ويعملوا log للفروقات وشوية quality checks

• وفي الآخر بيرجعوا للمستخدم response بتاع الـ old endpoint عادي زي ماهو عشان ميحصلش اي user impact، وبيحتفظوا طبعًا بالـ logs لو كان في اختلافات

بس في الحقيقة … الـ write endpoints قصة تانية خالص، وده جزء “المخاطرة” الحقيقي واللي ممكن يسبب مشاكل كبيرة.

ليه الـ Write Endpoints أخطر؟

أولًا: الـ write endpoints غالبًا بتكتب data في datastores (زي caches, databases… إلخ).
وفيه كمان موضوع مهم جدًا: وهو ان reddit بتطلع CDC events لما أي حاجة تتغير في أي core model. والـ CDC events دي عندهم عليها 100% guarantee of delivery تقريبًا لأن في services تانية critical بتعمل consume للـ CDC events دي، فمينفعش يحصل gap أو delay أو أي مشاكل في الـ event generation.

وكنا شرحنا قبل كده الـ CDC واللي هو اختصار للـ Change Data Capture بالتفصيل في Use-case كانت بتتكلم عن Pinterest وتقدروا تشوفوها من هنا 👇

Read More

فبالنسبة للـ comments، فيه 3 datastores أساسيين بيتم الكتابة عليهم:

• Postgres – backend datastore : اللي شايل كل الـ comment data

• Memcached – caching layer

• Redis – event store اللي بيتم استخدامه علشان الـ CDC Events

المشكلة هنا: لو حصل tap compare للـ write migration “زي ما هو” من غير اعتبارات خاصة للـ datastores، ممكن نوصل لحالة إن الـ new implementation بيكتب data غلط… وساعتها الـ old implementation مش هتعرف تقراها.

وعشان فريق المهندسين في reddit كانوا بيعملوا Migration لأكتر من data critical في Reddit، فمينفعش نعتمد على اكتشاف الفروقات بس من الـ production datastores.

طب إزاي نعمل Validate لعملية الكتابة من جزئين مختلفين من غير ما نكتب نفس الحاجة مرتين؟

هنا بقى ظهرت المشكلة الأساسية: بسبب الـ unique key restrictions على comment ids، فكرة إنك تكتب نفس الـ comment مرتين في نفس datastore مستحيلة (duplicate writing مش هيمشي).

فالحل كان إننا نعمل 3 sister datastores جديدة — مخصوصة للـ tap compare testing — واللي يكتب فيها يكون بس الـ new Go microservice endpoints. وبكده نقدر نقارن اللي اتكتب في production datastores بواسطة الـ old endpoint، مع اللي اتكتب في sister datastores بواسطة الـ new endpoint… من غير ما الـ new endpoint يبوّظ أو يكتب فوق production data.

خطوات الـ Sister Writes Verification

• فريق المهندسين بدأوا يوجهوا نسبة صغيرة من الـ traffic للـ Go microservice

• الـ Go microservice يعمل call للـ legacy Python service عشان يعمل production write الحقيقي بدون اي مشاكل

• وبعد كده الـ Go microservice يعمل write بتاعه هو في الـ sister datastores، ودي معزولة تمامًا عن الـ production

وبعد ما كل الـ writes بتخلص، لازم نتحقق ويحصل Validation:

• فبنقرأ من الـ 3 production datastores اللي الـ legacy Python service كتبت فيهم

• ونقارنهم بالـ 3 sister datastores اللي Go كتب فيهم

وكمان عشان يعالجوا بعض الـ serialization issues اللي ظهرت بدري (إن مثلا الـ Python services مش قادرة تعمل deserialize لـ data اتكتبت من Go services)، عملوا verification للـ tap comparisons كمان جوّه comment CDC event consumers في الـ legacy Python service.

الخلاصة: ان فريق reddit قدر انه يعمل الـ Migration للـ 3 write endpoints، وكل واحدة بتكتب في 3 datastores، ويعملوا verify للـ data من خلال 2 services… فبقى فيه 18 tap compares شغالين، وده احتاج وقت زيادة عشان يراجعوا ويصلحوا اي مشاكل بتحصل من الـ Data Quality Checks.

Outcome and Improvements

الخبر الحلو: عملية الـ migration كانت سلسة ومن غير أي disruption لمستخدمي Reddit، ومفيش اي user impact وكل الـ comment endpoints دلوقتي بيحصلها Handling من Golang microservice الجديدة.

وده milestone مهم جدًا لأن الـ comments بقت أول core model بالكامل خارج الـ legacy monolithic system!

الهدف الأساسي كان: تقليل الـ critical comments read/write paths من الـ legacy Python service لـ Go microservice حديثة، مع الحفاظ على الـ performance والـ availability.

ونتيجة لده: الـ latency قلت للنص تقريبًا في الـ 3 write endpoints اللي حصلها Migration.

p99 graphs

ونقدر نشوف في الـ graphs ان الـ p99 (للـ old legacy Python service باللون الأخضر، والـ new endpoints في Go microservice باللون الأصفر):

Create Comment Endpoint

Update Comment Endpoint

Increment Comment Properties Endpoint

Continue Reading

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء في هذا البرد,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد الخامس والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

في الإصدار ده الفهرس هيكون كالآتي:

1. A Revisit to REST API Fundamentals

2. API Authentication Methods

3. Agile in Working Environment Using Single Paper

4. إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم

A Revisit to REST API Fundamentals

بندرس دايمًا ال API Pillars في الجامعة أو في بداية شغلنا مع ال APIs ولكن بنقعد فترة طويلة مش قادرين نعكس دا علي شغلنا أو بنطبقها لأن لاقينا النظام كله كدا, النهارده هنراجع علي أهم خمس مبادىء مع Reflection ازاي نقدر نطبق كل مبدأ في شغلنا بسهولة .

1. Stateless

يعني كل Request بيبعت للـServer كل البيانات اللي محتاجها علشان يتنفّذ، من غير اعتماد على أي حالة متخزنة في الـServer بين الطلبات.

مثال

لو عندك API بيجيب بيانات المستخدم:

GET /users/15
Authorization: Bearer <token>

كل Request لازم يكون فيه الـToken، حتى لو نفس المستخدم كان عامل Request قبل كده.

ازاي نطبق المبدأ في الشغل

• اوعى تعتمد على Session في الـServer فأي معلومة يحتاجها الـServer لازم تيجي مع كل Request.

• استخدم Tokens (زي JWT) علشان تحقق الـAuthentication.

  ---

  2. Client–Server Separation

  الـClient (الموبايل/الويب) لازم مفصول تمامًا عن الـServer. كل واحد ليه دور واضح.

  مثال

  • الـFrontend يطلب:

  GET /products
  

  • الـBackend يرد بـJSON من غير ما يعرف إزاي الواجهة هتعرضه.

  دا بيساعدنا في إعادة استخدام ال Backend مع (ويب, موبايل, تابلت) و بيسرع عملية التطوير لأن الفرق كلها تقدر تشتغل في نفس الوقت من غير ما يكون في اعتماديات بينهم.

  ازاي نطبق المبدأ في الشغل

  • خليك مركز إن الـBackend يقدّم بيانات وعمليات بس.

  • بلاش تدمج لوجيك العرض (UI logic) جوّا الـAPI.

    ---

  3. Uniform Interface

  لازم يبقى فيه أسلوب ثابت وواضح للتعامل مع الـAPI. دا بيساعد على سهولة الفهم وتحسين وتسريع ال Maintainability لأن كل المبرمجين قادرين يفهموا الكود بسهولة.

  مثال على Uniformity

  • استخدام HTTP Methods بشكل سليم:

    • GET = تعني دائما قراءة Resource

    • POST = تعني دائمًا إضافة Resource

  • استخدام نفس شكل الـEndpoints:

  /users    
  /users/<user_id>/orders  
  

  ازاي نطبق المبدأ في الشغل

  • حافظ على Consistency في تسمية الـRoutes.

  • استخدم نفس شكل الردود (Response Format) في كل مكان.

  • بلاش تدمج أفعال في الـURL (زي /getUsers أو /deleteUser).

    ---

4. Cacheability

كل ال Responses من ال Server لازم توضح هي cacheable أو لاء

مثال

Response Header:

Cache-Control: max-age=3600

معناه إن البيانات دي صالحة لمدة ساعة.

ازاي نطبق المبدأ في الشغل

• استخدم Cache-Control في Endpoints اللي بياناتها مش بتتغير كتير.

• لو البيانات بتتغير باستمرار، استخدم no-cache أو no-store.

5. Layered System

الـClient مش لازم يعرف هو بيتعامل مع Server واحد ولا أكتر.
ده يسمح إنك تضيف Layers زي: Load Balancer, Caching Servers, Proxies.

مثال

العميل يبعت:

GET /products

وهو مش عارف إن الـRequest راح على Cache Layer قبل Server.

المبدأ دا بيدينا قابلية للتوسّع لو هنزود Servers أكثر ومعاها Load Balancer و بيزود الأمان لأنك تقدر تضيف Gateways و Security Filters.

ازاي نطبق المبدأ في الشغل

• أنت كمبرمج Backend هتكتب الـAPI عادي.

• تسيب موضوع الـInfrastructure لـDevOps بس لازم تكتب API نظيف يشتغل مع أي Layer بسهولة .

API Authentication Methods

أثناء تعاملنا مع ال APIs بنحتاج نعمل User Authentication واللي هي عبارة عن عملية التحقق من هوية المستخدم اللي باعت ال Request, ودا جانب هام جدُا في حماية الـ API وكذلك خصوصية وأمان المستخدمين.

فورقة وقلم و تعالوا نتعرف على أشهر 5 طرق من ال User Authentication Methods. 🚀

Basic Authentication

دا أبسط نوع وفيه بنبعت اسم المستخدم وكلمة المرور في ال Request في صيغة Base64 , طبعًا النوع دا منخفض الأمان ومش بنستخدمه في الـ Production Environment إلا علي HTTPS Connection, لأن ال Base64 Encoding بيتحل بأي Decoder على الإنترنت فلو ال Eequest اتعرض ل Eavesdrop Attack يقدر المهاجم بسهولة يعرف بيانات المستخدم.

الاستخدام المناسب:

• مناسب للاستخدام في وقت التطوير أو الـ Testing

• ممكن نستخدمه في التطبيقات الداخلية واللي ضامنين إنها على شبكة آمنة.

GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

API Key Authentication

ال API Keys عبارة عن مفاتيح أو “رموز تعريف” بيصدرها ال API لل Clients ودور ال Client أنه يبعتها مع كل Request لل API كوسيلة تحقق من هوية المستخدم. ال Client ممكن يبعتها ك Query String أو يحطها في ال Request Header أو حتي ك Cookie.

وزي ال Basic Authentication لازم نستخدمه علي HTTPS Connection لأن لو أي حد عرف ال API Key هيقدر ينتحل شخصية ال Client ويستعمل ال API باسمه.

الاستخدامات المناسبة:

• بتكون في بيئات التطوير و الاختبار أو في التطبيقات الداخلية

• ممكن نستخدمه في الـ Production ولكن مع وسائل أخري نزود بيها معامل الأمان.

💡ونلاحظ واحدة من أهم عيوب الـ API Key إنه مش بيدي User-Specific Permissions لأنه مصمم بالأساس عشان يستخدم بين ال Apps أو ال Services وبعضها.

JWT-Based Authentication

ال JWT من أفضل و أشهر الطرق المستخدمة في الـ Authentication ونقدر نقول إنها شبه فكرة الـ API Key ولكن المفتاح - في الحالة دي ال Token - بيكون Encrypted بطريقة أحسن من الـ API Key.

ومن أكبر مميزاتها إنك مش مضطر تخزن ال Token لكل Client علي ال Server زي ما بنعمل مع الـ API Keys وده بيخليها طريقة Scalable واتكلمنا عن ال JWT في ورقة كاملة نشجعكم تقرأوها.

OAuth 2.0

الطريقة دي مستخدمة عشان نعمل User Authentication للمستخدم بدون ما نعرف اسمه أو كلمة مروره بشكل حقيقي ودا مناسب في حالة الـ Third-Party Authentication واللي تعتبر شكل شائع من أشكال الـ Authentication هذه الأيام.

اكمل القراءة

Agile in Working Environment Using Single Paper

يبدو تطبيق الـ Agile في كثير من المؤسسات كمشروع ضخم يحتاج إلى اجتماعات لا تنتهي، والـ Presentations، والـ Plans المعقدة.لكن الحقيقة أن فشل الـ Teams لا يحدث بسبب نقص الـ Frameworks، بل بسبب غياب التركيز، وعدم وضوح الـ Roles، وضعف الاتساق مع الـ Execution.

ومن هنا تأتي قيمة خطة الـ Agile ذات الورقة الواحدة، التي تختصر رحلة الـ Transformation في صفحة واحدة عملية يمكنها توجيه الـ Team بدون تعقيد.

لماذا الورقة الواحدة فعّالة؟

لأنها تجبرك على:

• التخلص من الـ Theoretical details غير الضرورية

• صناعة فهم مشترك بين الـ Management والـ Teams

• جعل الـ Process مرئي وقابل للقياس

• الاعتماد على أقل عدد من الـ Rules التي تحقق أكبر قيمة

الـ Agile ليس عن إضافة المزيد، بل عن تقليل الـ Waste مع زيادة الـ Value.

مكونات خطة الـ Agile في ورقة واحدة

قم بتقسيم الورقة إلى 6 أقسام رئيسية:

1- الرؤية (Agile Vision)

1. ما الـ Problem الذي نريد حله؟

2. كيف يبدو الـ Success بعد الـ Agile؟

3. مثال: “تسليم الـ Value كل أسبوعين، مع شفافية أعلى والـ Feedback أسرع.”

2- تشكيل الفرق (Team Setup)

1. توزيع الـ Squads و الـ Members داخل كل فريق

2. تحديد: من الـ Product Owner؟ من الـ Scrum Master؟ من الـ Developers؟

3. 3 نقاط مختصرة تلخص الـ Responsibilities لكل دور

3- الجدول الزمني والاجتماعات (Cadence & Events)حدد فقط الـ Timing:

اكمل القراءة مجانًا

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد الرابع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

في الإصدار ده الفهرس هيكون كالآتي:

1. How Shopify Prepares for Trillion of Requests in BFCM

2. Introducing Shopping Research in ChatGPT

3. Redis Persistence Strategies

4. إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم

How Shopify Handles Trillion of Requests in BFCM

دايمًا Shopify بتتعامل مع Black Friday Cyber Monday (BFCM) كأنه أكبر حدث وده لأن ملايين الـ merchants وعشرات الملايين من الـ buyers معتمدين عليهم في أهم أربع أيام في السنة.

فبناء على تقارير سنة 2024 الأرقام دي كانت:

Analysis for 2024: 57.3 PB of data, 10.5 trillion database queries, 1.19 trillion edge requests, and 1.17 trillion database writes. 284 million requests per minute on edge and 80 million on app servers

ومع 12TB في الدقيقة يوم الـ Black Friday. فالمستوى ده من الـ traffic بقى شبه اليوم العادي عندهم. وبما إن 2025 هتبقى أكبر، قرروا يعيدوا التفكير والتخطيط للأيام دي من الأول.

الفكرة الأساسية: هي إنهم عملوا برنامج للاستعداد طول السنة، مش بس مجرد “حملة” قبل الـ Black Friday وخلاص.

1) Building Resiliency Roadmap

الاستعداد بدأ من شهر مارس، من خلال 3 حاجات ماشية بالتوازي:

1. Capacity Planning

   • بيستخدموا historical data والـ merchant growth عشان يقدروا يحددوا الـ traffic models.

   • بيقدموا الأرقام دي للـ cloud providers (Google Cloud) عشان يتأكدوا إنهم مش هيخلصوا الـ cloud resources اثناء الـ traffic ده.

   • وده بيحدد كمية الـ infrastructure اللي محتاجينها وأماكنها جغرافيًا هتكون عاملة ازاي.

2. Infrastructure Roadmap

   • بيراجعوا الـ tech stack، وبيشوفوا الـ architectural changes والـ upgrades المطلوبة عشان توصلهم للـ target capacity.

   • وبناء على ده .. ده اللي بيترجم بعد كده لشغل واضح لجميع الفرق.

3. Risk assessments (WCGW)

   • بيعملوا تمارين زي الـ “What Could Go Wrong” لتوثيق سيناريوهات الـ Failures، ترتيب الأولويات.

   • وبيطلعوا منها بـ inputs يختبروها ويقوّوا السيستم قبل BFCM.

وطبعا كل مسار من دول بيأثر على الباقي: فالـ Risk ممكن يكشف فجوة في capacity، أو يكون فيه تغيير في البنية يسبب risk جديد… وهكذا.

2) Chaos Engineering

كمان Shopify اعتمدت بشدة على الـ chaos engineering وهنا بيحقنوا Failures متعمّدة في الـ systems، بس على scale الـ BFCM علشان يعرفوا الـ systems بتاعتهم هتتصرف ازاي قدام الحجم الضخم ده من الـ traffic.

• بدأوا الـ chaos engineering من شهر أبريل تقريبًا.

• وحقنوا الـ failures في الـ systems عشان يشوفوا رد الفعل، ويختبروا الـ incident response.

• ركّزوا قوي على “critical flows” في المنتج زي: checkout, payments, order creation, fulfillment.

• عملوا cross-system disaster simulations.

• اختبروا search و pages endpoints.

• random navigation عشان يحاكوا سلوك users حقيقيين.

• inject network faults و latency و cache-busting عشان الـ load patterns تبقى واقعية.

• فرق الـ frontend عملت bug bashes عشان تكتشف regressions وتأكد إن الـ UX شغالة كويس تحت الـ peak load.

والنتيجة:

• فرق الـ incident response بنت “muscle memory” حقيقية للمشاكل اللي ممكن تحصل وازاي يتصرفوا بناء عليها.

• اكتشفوا بالفعل gaps في الـ playbooks والـ monitoring tools وسدوها وعالجوها قبل الـ BFCM.

• كل الـ findings اتعملها Documentation في Resiliency Matrix بحيث تبقى مرجع.

3) Resiliency Matrix

الـ Resiliency Matrix بقت هي الـ roadmap لتقوية السيستم قبل BFCM، وبتتحدّث طول السنة.

الـ matrics دي بتشمل:

• Service Status: حالة الـ operation الحالية لكل الـ critical services.

• Failure Scenarios: سيناريوهات الفشل وتحليل تأثيرها على الـ systems كان عامل ازاي.

• Recovery Procedures

• Operational Playbooks: خطوات الـ incident response بالتفصيل.

• On-call Coverage: فكل الـ On-Call Schedules اتحددت والـ PagerDuty escalation paths، وتغطية 24/7. تحسبًا لأي incidents ممكن تحصل.

فالـ Resiliency Matrix دي بقت الـ Central Documentation اللي كل الفرق بترجع لها عشان الـ resilience.

4) Load Testing & Bottlenecks

كمان Shopify مش بتستنى الـ BFCM عشان تعرف حدودها ايه، فبتعمل بشكل دوري load testing على production infrastructure قبلها بكتير.

• فعندهم tool اسمها Genghis بتشغّل scripted workflows بتقلّد user behavior: browsing, cart, checkout.

• بيزودوا الـ load تدريجي عشان يلاقوا breaking points.

• الـ tests بتشتغل من 3 GCP regions (us-central, us-east, europe-west4) عشان تحاكي global traffic.

• بيضيفوا flash sale bursts فوق الـ load العادي عشان يشوفوا كمان الـ peak capacity الحقيقية.

ومع ده بيستخدموا:

• Toxiproxy (tool كانوا بنوه) عشان يحاكوا مشاكل الشبكة: latency, failures, partitions.

• بيراقبوا الـ dashboards real-time، وجاهزين يوقفوا التست لو السيستم بدأ يتدهور.

• كذا فريق بيتعاون عشان يكتشفوا المشاكل من بدري والـ bottlenecks ويصلحوها.

ولما بيوصلوا الـ limits، قدامهم 3 اختيارات:

1. Horizontal scaling: يزودوا instances تانية.

2. Vertical scaling: يزودوا من الـ resources لكل instance.

3. Optimizations: تغييرات في الـ architecture والـ queries والـ layers والـ frontend.

والقرارات دي هي اللي بتحدد الـ final BFCM capacity.

5) BFCM Analytics Challenges

في 2025 هيكون فيه تحدي خاص: الا وهو جزء من الـ infrastructure عمره ما شاف BFCM قبل كده – طب إزاي يجهزوه بشكل كويس للـ peak من غير historical data؟

في 2024:

• أعادوا بناء الـ analytics platform بالكامل:

  • ETL pipelines جديدة.

  • تغيير في الـ persistence layer.

  • كمان APIs جديدة بدل النظام القديم.

• والـ ETL pipelines شافت الـ BFCM 2024، لكن API layer اتعملت بعد الموسم، يعني داخلة BFCM 2025 من غير experience سابقة في الـ peak traffic.

الـ analytics architecture شبه بقية Shopify:
عبارة عن microservices مستقلة بتتعامل مع reports تقيلة، aggregations، و real-time processing.

وعشان كده عملوا برضو chaos engineering:

• زودوا الـ traffic بشكل تدريجي وكانوا متحكمين في ده.

• عملوا inject لـ database latency علشان يشوفوا الـ system هيتصرف ازاي.

• اختبروا كمان الـ cache failures.

• ورسموا بدقة سلوك السيستم تحت الضغط هيكون عامل ازاي.

النتائج:

• الـ ETL pipelines احتاجت زيادة في الـ Kafka partitions عشان تحافظ على data freshness.

• الـ API layer احتاجت memory optimizations بعد ما عملوا profiling.

• الـ connection timeouts اتظبطت بشكل افضل

• عملوا Offloading لبعض الـ requests على load balancer مختلف عشان يخف الضغط على regions معينة.

• حسّنوا من الـ alerting و response procedures ودربوا الفرق على الـ failures قبل ما تحصل في الواقع.

6) Scale Testing Program

الـ chaos engineering والـ load tests بيختبروا أجزاء من الـ system ، ولكن Shopify كانت برضو محتاجة تعرف: هل المنصة كلها مع بعض تقدر تتحمل الـ BFCM ولا لا؟

وهنا ييجي دور الـ scale testing: فمن إبريل لأكتوبر عملوا 5 scale tests رئيسيين حسب الـ traffic forecasts (p90 وبعدين p99). أول اتنين قارنوا baseline performance مع 2024 والتالت والرابع والخامس وصلوا لتوقعات 2025.

في test رقم 4: وصلوا لـ 146 مليون request في الدقيقة و80,000+ checkout في الدقيقة. وفي آخر test اختبروا p99 = 200M RPM.

الـ tests دي ضخمة لدرجة: بيشغلوها بالليل بس. وبينسقوا مع YouTube عشان ما يضغطوش على الـ internet والـ cloud resources.

• فهم اختبروا الـ resilience مش ال load بس:

  • زي الـ regional failovers

  • والـ traffic failover من US و EU regions

  • والـ disaster recovery validation

ونوعيات الـ tests دي كانت:

• Architecture scale-up: التأكد إن الـ infra تشيل الـ capacity المخطط.

• Load tests

• Load tests (with failover): اختبارات cross-region failover.

• chaos engineering : على مستوى المنصة كلها.

حاكوا سلوك users حقيقيين:

• storefront traffic (browse + checkout)

• admin API apps و integrations

• analytics و reporting

• backend webhooks

7) BFCM Operational Plan

وبعد كل الاستعداد ده، التشغيل باه أثناء الـ BFCM نفسه كان محتاج خطة محكمة:

• Real-time monitoring على كل regions مع alerts بتحصل بشكل automatic.

• Incident Response: بحيث يكون فيه فرق للـ Incident Manager On-Call شغالين 24/7.

• Merchant communications

• Live optimization

• Post-BFCM debrief: يربطوا data من المراقبة مع نتائج الـ merchants.

Introducing shopping research in ChatGPT

شركة OpenAI أعلنت عن ميزة جديدة في ChatGPT اسمها Shopping Research بتحوّل ChatGPT لمساعد للتسوّق الشخصي بيقارن المنتجات، يسأل أسئلة توضيحية، وبيبنيلك ارشادات شرائية مخصصة حسب احتياجاتك وتفضيلاتك الشخصية.

الميزة دي:

• مبنية على نسخة من GPT-5 ومدعومة بالـ reinforcement learning عشان تبقى أدق في اختيار المنتجات.

• بتوصل لـ 64% product accuracy مقارنة بـ 37% بس مع ChatGPT Search القديم.

• تقدر تقول للموديل على أي منتج: Not interested عشان يبعد عن النوع ده، أو More like this عشان يرشحلك حاجات شبهه.

• الميزة شغّالة لكل المستخدمين الـ logged-in على الويب والموبايل، ومع الاستهلاك شبه غير محدود خلال فترة الأجازات.

• مستخدمي Pro يقدروا كمان ياخدوا proactive shopping suggestions عن طريق Pulse.

اللي مهم هنا إن ChatGPT بقى فعليًا shopping agent بيستخدم الـ memory الخاصة بيك عشان يفهم ذوقك العام ويطوّر الترشيحات مع الوقت. ومن ناحية الـ users ده معناه تجربة تسوّق أذكى وأقل مجهود.

ومن ناحية الـ retailers، فـ ChatGPT بقى gatekeeper جديد في رحلة الشراء: جزء كبير من قرار الشراء ممكن يتاخد جوه ChatGPT قبل ما المستخدم يزور أي متجر فعليًا.

Redis Persistence Strategies

كلنا عارفين إن Redis واحدة من أسرع الـ Key-Value Stores اللي موجودة في الساحة، وأكتر استعمالتها بيكون في الـ Caching وعشان كده أكيد جه في دماغ أي حد بيستخدمها سؤال مهم: لو حصل crash للسيرفر، إيه اللي هيحصل للداتا؟

والإجابة هنا بتكون: على حسب إحنا مشغلين أنهي طريقة من طرق الـ Persistence (الحفاظ على البيانات) اللي Redis بتوفرها.

Data Persistence

الـ Data Persistence معناها إن الـ data اللي في الذاكرة (RAM) ما تضيعش لما السيرفر يوقع أو يحصل فيه مشاكل أو حتى يحصله restart. وكلنا عارفين إن redis شغالة أساسًا in-memory، وده معناه إنها سريعة جدًا بس عرضة لتضيع كل البيانات لو ما فيش backup نقدر نسترجع بيه البيانات دي.

عشان كده Redis بتوفرلنا طريقتين رئيسيتين لحفظ الداتا:

1. RDB (Redis Database)

2. AOF (Append Only File)

RDB Snapshotting

في الطريقة دي Redis بتعمل snapshot من كل الداتا الموجودة في الذاكرة (RAM) وتحطها في ملف .rdb.

ازاي الـ RDB بيشتغل؟

كل شوية (حسب الـ config أو من خلال manual trigger)، Redis بتاخد نسخة Snapshot من كل البيانات اللي موجودة وتكتبها في ملف على الـ disk. فلو حصل crash لأي سبب من الأسباب للـ redis instance .. تقدر تعمل restore للداتا بشكل طبيعي من آخر snapshot حصل.

فالأول Redis بتعمل fork(): فبيكون عندنا Parent / Child Process الـ Parent Process بتقدر تستقبل read/write requests بشكل طبيعي جدًا، في حين إن الـ child process اللي حصلها fork() بتبدأ تكتب الـ snapshot في ملف مؤقّت على الـ disk.

بعد ما الـ child process يخلص، الملف المؤقّت بيتغيّر للـ dump.rdb بشكل آمن.

العملية دي بتستخدم كمان الـ copy-on-write علشان تقلل التأثير على الأداء خصوصًا لو كان حجم البيانات كبير فتقدر تنقل البيانات بشكل فعال.

AOF (Append Only File)

الطريقة دي بتخلي Redis يكتب كل عملية write بتحصل (زي set, del) في ملف log. بمعنى أدق كل الـ commands اللي حصلت بتتكتب في الـ .log وبتتخزن على الـ Disk.

ازاي الـ AOF بيشتغل؟

كل ما يحصل أي تعديل في الداتا، Redis بتكتب الـ command اللي حصل في آخر ملف الـ AOF. بشكل append-only ولما يحصل وليكن restart أو crash، تقدر وقتها تقرأ كل العمليات اللي في الملف ده واحدة واحدة وترجع الداتا.

Read more

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد الثالث والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

في الإصدار ده الفهرس هيكون كالآتي:

1. GPT-5.1: A smarter, more conversational ChatGPT

2. A new era of intelligence with Gemini 3

3. Model Context Protocol

4. إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم

GPT-5.1: A smarter, more conversational ChatGPT

OpenAI أعلنت عن تحديث جديد لعيلة GPT-5 بإصدار GPT-5.1، والهدف مش بس تبقى النتايج أذكى، لكن كمان طريقة الكلام تبقى أريح وأقرب لأسلوب الناس. والتحديث ده ظاهر في النموذجين الرئيسيين: GPT-5.1 Instant و GPT-5.1 Thinking، ومعاهم كمان تحسينات كبيرة في إزاي تقدر تتحكم في الـ tone وطريقة رد ChatGPT.

GPT-5.1 Instant – النموذج اليومي السريع

GPT-5.1 Instant هو اللي الناس بتستعمله أكتر حاجة جوه ChatGPT. في الإصدار الجديد:

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

• بقى أحسن في الـ instruction following، يعني فيه احتمالية أقل إنّه يقعد يلف حوالين السؤال بدل ما يرد عليه بشكل مباشر.

• لأول مرة بقى بيستخدم الـ adaptive reasoning: بيقرر إمتى يحتاج “يفكر شوية أكتر” قبل ما يرد على سؤال صعب، وده بيخلّي إجابات المسائل التقيلة في الـ math والـ coding أدق، وفي نفس الوقت يفضل سريع مع الحاجات البسيطة.

• والنتائج دي باينة في تحسن ملحوظ بناء على تقييمات زي AIME 2025 و Codeforces.

GPT-5.1 Thinking – تفكير أعمق، كلام أوضح

GPT-5.1 Thinking هو نموذج الـ advanced reasoning. التحديث ركز على حاجتين:

• إدارة أحسن لوقت التفكير:

  • أسئلة بسيطة → رد أسرع.

  • مشاكل معقدة → وقت تفكير أطول وإجابات أعمق.

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

فكرة النموذج ده إنه يفضل أكتر نموذج “عقلي” متاح، لكن من غير ما تحس إنك بتتكلم مع ورقة بحثية ناشفة.

GPT-5.1 Auto – اختار عنك النموذج المناسب

بدل ما تقعد تغيّر بشكل يدوي النموزج بين Instant و Thinking، فيه في الـ setting اختيار اسمه GPT-5.1 Auto:

هو اللي بيقرر يوجه السؤال لأي نموذج حسب نوع الطلب والنتيجة ان في معظم الحالات مش هتحتاج أصلاً تفكر أنهي model تختاره؛ واللي هتحس بيه إن الإجابات عمومًا بقت أذكى وأكتر طبيعية في الـ tone.

إزاي التحديث هيتوفر للمستخدمين؟

خطة الإطلاق زي ما OpenAI أعلنت:

البداية مع المستخدمين المدفوعين: Pro, Plus, Go, Business. بعد كده يبتدي يتوفر تدريجيًا للمستخدمين الـ free والـ logged-out، عشان يحافظوا على استقرار الأداء.

اما بالنسبة للـ Enterprise و Edu: عندهم early-access لمدة ٧ أيام، بعدها GPT-5.1 يبقى هو الـ default.

نماذج GPT-5 القديمة (Instant و Thinking) هتفضل متاحة في قائمة legacy models للمشتركين المدفوعين لمدة ٣ شهور، عشان الناس تقدر تقارن وتنتقل براحتها.

على مستوى الـ API:

• GPT-5.1 Instant هيظهر في الـ API باسم gpt-5.1-chat-latest.

• GPT-5.1 Thinking هيظهر باسم gpt-5.1.

  والاتنين بيستخدموا الـ adaptive reasoning.

التحكم في الـ Tone

مع التحديث الجديد ده، OpenAI ركزت كمان على موضوع التخصيص وان الناس ليها أذواق مختلفة جدًا في طريقة كلام ChatGPT، حتى نفس الشخص بيحتاج tone مختلف من سياق للتاني.

قبل كده كانوا ضافوا preset options للـ tone، دلوقتي بقى فيه:

• تحديث للخيارات القديمة:

  • Default

  • Friendly (الاسم القديم Listener)

  • Efficient (الاسم القديم Robot)

• وإضافة options جديدة تعكس أكتر استخدامات الناس في الواقع:

  • Professional

  • Candid

  • Quirky

الفكرة إنك تقدر تختار شخصية/أسلوب يناسبك في ثواني من غير لف كتير حوالين الإعدادات. كمان GPT-5.1 نفسه بقى أحسن في احترام الـ custom instructions، فبقى عندنا السيطرة بشكل أفضل على الـ tone والسلوك في الردود.

A new era of intelligence with Gemini 3

جوجل أعلنت عن Gemini 3، الجيل الجديد من نموذج Gemini، وبتقدمه كنقلة ضخمة في جزء الـ reasoning والـ multimodal والـ agents.

Gemini 3 Pro

النموزج الجديد بيتفوق بشكل واضح على 2.5 Pro في كل الـ benchmarks تقريبًا، سواء في الـ reasoning، او الـ math، أو الـ multimodal (نصوص، صور، فيديو، كود).

بالاضافة كمان انه بيقدّم إجابات أذكى وأوضح، وأقرب إنّه يبقى “thought partner” يساعدك تفهم وتبني أفكارك، مش بس يرد ويراضيك ويجاملك (المشكلة اللي تقريبًا الناس كلها بقت تتريق بسببها على اجابات الـ AI 😂).

Gemini 3 Deep Think

الـ Mode ده بيكون أعمق أكتر في الـ reasoning، وبيعدّي الـ Pro في الامتحانات التقيلة زي Humanity’s Last Exam و ARC-AGI-2.

وده بكل تأكيد موجه أكتر للمسائل المعقدة جدًا، وهيبدأ كأولوية للـ safety testers وبعدين مشتركين Google AI Ultra.

Gemini 3 helps you learn, build and plan anything

تقدر تستعمله في التعلم بحيث يشتغل على text, images, video, audio, code في نفس الـ flow، ويقدر كمان أوراق، محاضرات وفيديوهات لـ visualizations, flashcards وكورسات صغيرة مفهومة. فتجربة التعلم هتتغير بالكامل.

تقدر كمان تستعمله لو بتحاول تبني حاجة بنفسك فهو أقوى نسخة لحد دلوقتي في الـ vibe coding و agentic coding، وتقدر تستعمله من خلال مختلف الادوات المتاحة زي Google AI Studio, Vertex AI, Gemini CLI و Google Antigravity، وكمان في منصات زي Cursor و Replit.

وبالمناسبة Google Antigravity ده الـ IDE الجديد من Google واللي غالبًا كده ممكن يكون منافس لبعض الـ IDEs زي Cursor / Windsurf ، وهنشوف انطباعات الناس بعد ما تجربه.

وآخيرًا تقدر كمان تعتمد عليه في التخطيط الوتنفيذ وده لان قدرته على التخطيط طويل المدى بقت أحسن، يقدر يدير workflows كاملة (زي تنظيم inbox أو حجز خدمات) باستخدام tools مختلفة، مع الحفاظ على الهدف من غير ما يسرح مننا.

Responsible AI

جوجل بتقول إن ده أأمن نموذج عندها لحد دلوقتي، مع اختبارات أوسع ضد misuse, prompt injection و sycophancy، وبمشاركة جهات تنظيمية وخبراء مستقلين.

وعندنا Gemini 3 بيبدأ يتوفر من دلوقتي في الـ Gemini app، AI Mode في Search، الـ API، و Vertex AI، ومع الوقت هينضم له باقي أفراد عيلة Gemini 3 ونشوف use cases أعمق في الشغل والحياة اليومية.

OLTP and OLAP in Database Performance at Scale

الحمد لله ربنا كرمك وخلصت الابليكشن بتاعك وعاوز تعمله host وبقيت محتار ياترى هخلي ال SQL engine على سيرفر ومعاها ال Elastic search في نفس السيرفر ده لو اعتبرنا ان ال sql لل OLTP و ال elastic لل OLAP اللي فيها ال logs بتاع البزنسس والخ وطبعا سواء sql او elk الاتنين ينفعوا مع النوعين ال OLAP وال OLTP لكن المثال هنا للتوضيح . ولا هتخلي كل واحد في سيرفر لوحده ؟؟!

وعشان نتجاوب على السؤال ده لازم الاول نعرف ايه هم ال OLAP وال OLTP :

الـ OLTP (Online Transaction Processing) و OLAP (Online Analytical Processing) هما نوعان مختلفان من الأحمال (workloads) اللي ممكن تواجهها في قاعدة بيانات أو نظام معتمد على قواعد البيانات.

عشان نفهم الفرق بينهما، خليني أشرح بمثال عملي:

Model Context Protocol

الـ MCP هو اختصار لـ Model Context Protocol، وده ببساطة بروتوكول أو أسلوب تواصل بيخلي نماذج الذكاء الاصطناعي (زي ChatGPT و Claude و Deepseek وغيرها) تقدر تفهم وتتفاعل مع العالم الخارجي زي التعامل مع الملفات، والـ APIs، والأدوات المختلفة، وقواعد البيانات.

كأننا بنوصّل مخ الذكاء الاصطناعي بالعالم الخارجي بشكل منظم أكتر وآمن.

بداية المشكلة

لنتخيل إننا عندنا مساعد ذكي زي ChatGPT، وعاوزين نطلب منه الآتي:

احنا عندنا وليكن E-Commerce Application وعملنا Export لملف Excel بالـ Orders اللي وصلتنا وعاوز اطلب من ChatGPT يشوفلي كام عميل طلب منتج معين بدل ماعمل ده بشكل يدوي ، وعاوزه يقولي شوية احصائيات كده على الطلبات اللي موجودة ونسب الطلب عليها.

هنعمل ده ازاي ؟

في الحالة العادية: بنروح نكلم ChatGPT واكتبله الـ Prompt وبالشكل ده لاني بكلمه من الـ Browser على سبيل المثال فأنا بروح اخد البيانات بتاعتي Copy أو برفعله الملف عشان يكون ليه Access عليه ويبدأ يفهم الطلب بتاعي ويبدأ في تنفيذه مش كده ؟

النموذج في الحالة دي مش هيقدر يفتح ملفات على جهازنا من نفسه. هو “ذكي” أه، ولكن ملوش Access ومش مربوط بالعالم الخارجي. يعني مش شايف جهازنا، ولا المتصفح، ولا أي أدوات بره السياق بتاعه.

فلو عاوز اطلب منه مثلا يعمل Code-Review على Code انا كاتبه ، مش هعرف اديله Access على الـ Repo بتاعتي ولو قدرت اعمل ده فمش هعرف اعمله بطريقة آمنة.

طب فيها ايه لو كتبنا Script يعمل Integration بالموضوع ده ؟

• هنكتب Script يقدر يقرأ السياق من الـ Local Repository

• ويـ Integrate مع الـ LLM Model ويبعتلهم الـ Prompt

• وبعدين ننفذ الكلام ده

هنا هنلاقي اننا محتاجين كل واحد يعمل الموضوع ده ، عشان بس نقدر ندي Access للـ LLM Models على سبيل المثال انها تقدر تقرأ الـ Repositories والـ Codebase بتاعنا مش كده ؟

وهنا بالظبط بييجي دور الـ MCP.

Continue Reading

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد الثاني والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

في الإصدار ده الفهرس هيكون كالآتي:

1. PassKeys and The Future of Passwordless

2. Pessimistic Locking Explained

3. OLTP and OLAP in Database Performance at Scale

4. إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم

PassKeys and The Future of Passwordless

الـ passkeys من التكنولوجيا اللي بتقدّم login credential أأمن بكتير من الطريقة التقليدية زي الـ username/password. والفكرة الأساسية إن الـ passkeys ماشية في طريق إنها تستبدل أغلب الـ passwords اللي إحنا متعودين عليها، بس الموضوع معتمد على تركيبة حساسة من كذا تكنولوجي، أهمهم مكوّن اسمه authenticator بأنواعه المختلفة.

ففي أي passkey workflow إنت غالبًا بتتعامل مع أربع جهات شبه مستقلة، متوصلين ببعض عن طريق standards:

1. الـ authenticator نفسه.

2. الـ website/app اللي بيتسمى relying party (السيرفر اللي بيعالج طلبات الـ login).

3. نظام التشغيل.

4. الـ web browser.

الـ authenticator هنا مش المقصود بيه بالضرورة Google Authenticator أو Microsoft Authenticator، لكن في الغالب بيكون جزء مدمج جوه أي password manager. عشان كده ناس كتير مش بتحس بوجوده كحاجة مستقلة. ومع ذلك، في authenticators تانية بتبقى stand-alone من غير ما تكون password manager.

السبب الأساسي إن الصناعة كلها بتزق ناحية passkeys هو إن إحنا كبشر أعداء لنفسنا: وتقريبًا كل يوم في breach جديدة لبيانات عملاء أو مرضى، وغالبًا البداية بتكون social engineering لموظف او حتى contractor بيسرّب login credentials بتاعة الـ corporate app.

والأبحاث بتقول إن ٩٨٪ من المستخدمين لسه بيغلطوا وبيضغطوا على scam links حتى بعد كورسات cybersecurity training. وعشان كده هنا بييجي دور الـ passkeys كأقوى دفاع متاح حاليًا.

رغم كده، معظم SaaS apps مش ماشية بسرعة كفاية في التخلص من passwords. في أنظمة الـ passkeys فيها هتستبدل username/password بالكامل، وفي أنظمة هتخلي passkeys كخيار بديل جنبهم. وفي كل الأحوال، أول ما relying parties اللي بتتعامل معاها تبدأ تدعم passkeys، مش هتقدر تتفادى إنك تعتمد على واحد أو أكتر من authenticators عشان عملية الـ login. بعكس passwords،

إنت مش هتقدر “تفتكر” الـ passkey وتكتبها بشكل يدوي؛ ولكن الـ authenticator هو اللي بيعمل كل الشغل ده أوتوماتيك.

وطبعا اختياراتك في الـ authenticator مش نهائية؛ تقدر تغيّرها بعدين. بس كل ما تمشي مسافة أطول باستخدام authenticator معيّن (أو حتى أكتر من واحد في نفس الوقت)، كل ما عملية الـ migration بعدين هتبقى أصعب وأوجع.

وجزء كبير من اللخبطة في الموضوع ده جاي من المصطلحات بتاعته. فاسم “passkey” نفسه طلع من Apple كاسم لطيف لبعض الـ Specification_، اللي هي مزيج من WebAuthn (بتاعة W3C عشان passwordless authentication على الويب) و Client-to-Authenticator Protocol (CTAP).

وكلمة authenticator في client-to-authenticator الـ client هنا غالبًا هو الـ web browser أو جزء في الـ OS مسؤول عن حركة الترافيك للويب.

من بعد ما Apple أعلنت مصطلح passkey في WWDC 2021، بقية الصناعة استخدمته، بس من ساعتها بقى فيه مصطلحات كتير وناس كتير بتتلخبط. مثال واضح: Google و Microsoft عندهم apps اسمها Authenticator.

• الـ Google Authenticator شبه Symantec VIP، شغلته الأساسية توليد TOTP كـ second factor مع username/password.

• والـ Microsoft Authenticator كان بيدير usernames/passwords/passkeys ويعمل autofill، لكن من يوليو ٢٠٢٥ شالوا منه username/password autofill وفضل فيه دعم لـ TOTPs ونوع محدود من passkey اسمه device-bound passkey. دلوقتي دعم autofill الشامل لـ user IDs و passwords موجود في Edge browser بدل Microsoft Authenticator.

وعندنا أكتر من نوع للـ authenticator زي: platform, virtual, و roaming.

Pessimistic Locking Explained

يعتبر الـ Locking من أهم الآليات اللي بنعتمد عليها في الـ Databases بشكل أساسي عشان نتحكم في الـ Concurrent Access للبيانات من خلال أكثر من Transactions، فلو كان هناك عدد من الـ Transactions بيحاول يوصل للبيانات دي في نفس الوقت فأكيد هيحصل نتيجة لده تضارب بنسميه Conflicts.

نقدر نتخيل الـ Locking كأنه زي القفل اللي بنقفل بيه على أي حاجة عشان نمنع أي حد من الوصول ليها. فالـ Databases أحيانًا بتحط قفل على الـ Row أو الـ Record لما يكون فيه Transaction شغال عليه عشان تمنع أي حد من الوصول للـ Row ده, اكنه دخل (الحمام وقفل وراه الباب) ..

طب هو ليه اصلا بنحتاج للـ Locking ؟

احنا بنحتاج للـ Locking لإنه بيقدملنا فوايد مهمة زي الـ Data Integrity & Data Consistency ودول من أهم الفوايد اللي بنحصل عليها من الـ Locking .. لإنه من غير Locking ممكن Two Concurrent Transactions يغيروا في قيمة الـ Column الواحد في نفس الوقت وده يسبب مشاكل كتير.

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

فيه نوعين من الـ Locking وهم الـ Optimistic Locking والـ Pessimistic Locking بس احنا هنتكلم النهاردة عن الـ Pessimistic.

ايه هو الـ Pessimistic Locking ؟

الـ Pessimistic Locking جاي من اسمه انه شخص متشائم، بيعمل حسابه دايما على أسوء الظروف وبناء عليه بيفكر لقدام وبياخد احتياطه مسبقا.

الـ Pessimistic Locking في قواعد البيانات بيمنع الـ Conflicts الناتجة من الـ Concurrent Updates واللي بتحصل بشكل Frequent أو متكرر. فلما بنيجي نعمل عملية تحديث لـ Row أو Record معين، فالـPessimistic Locking بتحط قفل على الـRow أو الـRecord ده عشان تمنع عمليات الـ Updates التانية من انها توصل لنفس الـ Row أو الـ Record في نفس الوقت.

ممكن نتخيل أن القفل ده عبارة عن اشارة حصرية فقط لعملية الـ Update الحالية , وبالتالي مش ممكن لأي عملية تانية انها توصل لنفس البيانات اللي شغالين عليها وده لانها بتكون مقفول عليها بالقفل لحد ما العملية الحالية تنتهي.

أكمل القراءة

OLTP and OLAP in Database Performance at Scale

الحمد لله ربنا كرمك وخلصت الابليكشن بتاعك وعاوز تعمله host وبقيت محتار ياترى هخلي ال SQL engine على سيرفر ومعاها ال Elastic search في نفس السيرفر ده لو اعتبرنا ان ال sql لل OLTP و ال elastic لل OLAP اللي فيها ال logs بتاع البزنسس والخ وطبعا سواء sql او elk الاتنين ينفعوا مع النوعين ال OLAP وال OLTP لكن المثال هنا للتوضيح . ولا هتخلي كل واحد في سيرفر لوحده ؟؟!

وعشان نتجاوب على السؤال ده لازم الاول نعرف ايه هم ال OLAP وال OLTP :

الـ OLTP (Online Transaction Processing) و OLAP (Online Analytical Processing) هما نوعان مختلفان من الأحمال (workloads) اللي ممكن تواجهها في قاعدة بيانات أو نظام معتمد على قواعد البيانات.

عشان نفهم الفرق بينهما، خليني أشرح بمثال عملي:

OLTP (أحمال المعاملات على الإنترنت)

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

الخصائص:

• الاستجابة السريعة مهمة جدًا، لأن المستخدمين مستنيين إجابة فورية.

• بتكون فيه استعلامات بسيطة وسريعة زي عمليات قراءة وإضافة أو تحديث صغيرة.

• غالبًا ما بيكون فيه أوقات تأخير منخفضة جدًا، وأي تأخير ممكن يسبب مشكلة كبيرة في تجربة المستخدم.

مثال:

تخيل إنك في موقع للتسوق على الإنترنت، ولما تضغط على منتج عشان تشوف تفاصيله، النظام بيعمل استعلام من قاعدة البيانات عشان يجيب بيانات المنتج ده ويعرضها بسرعة، ده يعتبر OLTP.

أكمل القراءة

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸

أهلًا وسهلا بكم في العدد الواحد والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀

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

في الإصدار ده الفهرس هيكون كالآتي:

1. HTTP Versions as Easy as possible

2. Deadlock vs. Starvation

3. Cross-Tab Communication with Broadcast Channel API

4. إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم

HTTP Versions as Easy as possible

النهارده هنقارن إصدارات الـ HTTP اللي مسؤولين عن توصيل الويب لينا كما نعرفه اليوم بأسهل طريقة هتشوفوها حول الانترنت, كوب الشاي ويلا بينا ^^

تشبيه من العالم الحقيقي

خلونا نفكر شوية في شركات التوصيل والبريد

• Network الطرق والكباري وعربيات التوصيل

• Client (المتصفح) الشخص اللي بيطلب أو يبعت الطرد

• Server (الخادم) الشركة أو المستودع اللي بيستقبل ويعالج الطلب

• HTTP Protocol القوانين اللي بتحكم طريقة كتابة العنوان، نوع الطرد، طريقة الرد

• TCP/UDP وسيلة النقل اللي بتوصل الطرود

• Data Packets الطرود نفسها اللي فيها أجزاء من البيانات

• Router / Switch مراكز البريد اللي بتنقل الطرود من منطقة للتانية

فلما نتكلم عن الـ HTTP ما هو إلا قوانين تنظم طريقة إرسال واستلام البريد أو الطرود و الإصدارات المختلفة ما هي إلا تحسينات على الطريقة دي عشان نخليها أكفأ وأسهل وأسرع.

HTTP/1.1 “ساعي البريد التقليدي”

تخيل شركة التوصيل عندها ساعي بريد واحد (Connection واحد فقط). كل مرة يروح يسلم طرد، هيضطر يعمل رحلة كاملة وما يقدرش يشيل أكثر من طرد في الرحلة الواحدة. فلو عندك 10 طرود (requests)، لازم يعمل 10 رحلات ورا بعض ( يعني كل Request يتبعت ونستنى ال Response وبعدين نبعت اللي بعده وهكذا) أو يجيب سعاة كتير (multiple TCP connections).

المميزات

• بسيط وسهل الفهم.

• مدعوم في كل الأنظمة والمتصفحات.

• مثالي للتطبيقات الصغيرة أو legacy.

العيوب

• Head-of-Line Blocking: لو طلب اتأخر، باقي الطلبات تستنى.

• No Multiplexing: اتصال واحد = طلب واحد في المرة.

• Overhead عالي على الشبكة لأن ال Headers بتتكرر كل مرة.

• تحميل الصفحات الكبيرة بطيء خصوصًا لما يكون فيها ملفات كتير

  ---

HTTP/2 “شاحنة التوصيل (Multiplexing)”

الشركة قررت تحدث النظام وبقت تستخدم عربية واحدة (Connection واحد)، لكن جواها رفوف كثيرة (Streams).

يعني تقدر تبعت:

• طرد فيه /index.html

• طرد فيه /styles.css

• طرد فيه /script.js كلهم في نفس الرحلة لكن في أرفف منفصلة جوه نفس العربية.

بس فيه مشكلة صغيرة: لو طرد في أول العربية اتكسر أو اتأخر في التوصيل (TCP packet lost). باقي الطرود في العربية ممكن يتأخروا كمان. (وده اللي بنسميه Head-of-Line Blocking على مستوى TCP.)

اكمل القراءة

Deadlock vs. Starvation

فيه مصطلحين مهمين جدًا في نظم التشغيل لازم نفهمهم كويس وهما Deadlock و Starvation. وعلى الرغم من إنهم بيبدوا مشابهين لبعض، إلا إن كل واحد فيهم ليه سبب مختلف ونتيجة مختلفة تمامًا عن التاني. فورقة وقلم وتعالوا نشوف الفرق بينهم.

Deadlock

قبل ما نشوف ايه هي الـ Deadlock من الناحية الـ Technical تعالوا نفهمها سوا بشكل بسيط من خلال المثال ده:

دلوقتي ولنفترض ان عندنا اوضتين وكل اوضة ليها باب ومفتاح خاص بيها , فعندنا محمود دخل الاوضة بتاعته والباب اتقفل عليه بالقفل , وعندنا يوسف دخل الاوضة التانية والباب اتقفل عليه كذلك بالقفل , طب ايه رأيكم لو محمود كان معاه مفتاح اوضة يوسف بالخطأ ويوسف معاها مفتاح اوضة محمود ؟

كل واحد فيهم عاوز يخرج من الاوضة اللي هو فيها ولكن كل واحد مش هيعرف يفتح اوضته لان المفتاح اللي عاوزه مع التاني فبالتالي بنقول ان حصل هنا Deadlock.

طب كـ Technical باه الكلام ده بيحصل ازاي او بنترجمه لايه ؟

اكمل القراءة

Cross-Tab Communication with Broadcast Channel API

في عالم تطوير الويب، غالبًا بنحتاج ننقل بيانات أو نرسل رسائل بين تبويبات المتصفح المختلفة. على سبيل المثال، لو عندك تطبيق ويب مفتوح في أكثر من تبويب، وعايز التحديثات اللي تحصل في تبويب معين تنعكس على باقي التبويبات تلقائيًا، فأنت محتاج تستخدم الـ Broadcast Channel API، اللي بيسمحلك تعمل تواصل سهل وفعال بين التبويبات المختلفة لنفس المتصفح طالما كلها مفتوحة على نفس الصفحة أو صفحات مختلفة على نفس الـ domain حتى لو كانت مفتوحة على نوافذ مختلفة ولكن بشرط تكون لنفس المتصفح.

ملحوظة: نافذة المتصفح قد تحتوى على تبويب واحد أو أكثر، كل تبويب منهم مسئول عن عرض صفحة واحدة فقط، نافذة المتصفح هي ما تحصل عليه عند فتح المتصفح، وفتح المتصفح عدة مرات يؤدى إلى إنشاء عدة نوافذ.

ليه محتاج تبعت بيانات بين التبويبات المختلفة ؟

لنفترض أننا محتاجين نزور أحد مواقع بيع الكتب ونتصفح الموقع بحثا عن مجموعة من الكتب المفيدة بالنسبة لنا عشان نشتريهم مثلا، فبدأنا رحلتنا من الصفحة الرئيسية للموقع وقابلنا كتاب بيتكلم عن JavaScript ففتحناه في علامة تبويب جديدة عشان نقدر نكمل تصفح في الصفحة الرئيسية ونبقى نشوف تفاصيل الكتاب بعدين (يمكن نلاقى كتب تانية فنشتريها بالمرة)، واستمرينا في التصفح لغاية ما لقينا كتاب تاني بيتكلم عن CSS وكالمعتاد فتحناه في علامة تبويب جديدة.

بعدها قررنا نزور علامات التبويب اللى فتحناها عشان نشوف تفاصيل كل كتاب منهم، وبالفعل الكتاب الأول نال اعجابنا وضيفناه لسلة المشتريات، ولاحظنا ظهور رقم 1 أعلى أيقونة سلة المشتريات للتعبير عن وجود منتج واحد بالسلة، بعدها فتحنا علامة التبويت التانية عشان نشوف الكتاب التاني وهنا لاحظنا إن الرقم 1 مش موجود لأن علامة التبويب دى مش عندها أى علم بأن في كتاب تم إضافته للسلة، ودا سبب لنا نوع من القلق عن إذا كان الكتاب الأول انضاف فعلا ولا لا، فرجعنا نبص عليه ولقيناه موجود فى السلة فعلا.

واستمرينا في رحلتنا بإضافة الكتاب التاني إلى السلة، وجات لحظة شراء الكتب اللى احتاجت مننا تسجيل الدخول للموقع، وبعد عملية تسجيل الدخول لاحظنا إن الصفحة اتعرفت علينا وبتعرض لنا اسم المستخدم في الـ navbar ولكن باقي الصفحات لسا مجالهاش خبر بأننا سجلنا دخول في الموقع فاضطرينا نعمل لهم ريفريش عشان يتحدثو بحيث ميحصلش اى مشكلة غير متوقعة، وبعدها تمت عملية الشراء بنجاح رغم إن بعض الصفحات لازالت مقتنعة إننا لسا مشتريناش الكتب، بل بعدها لما عملنا تسجيل خروج من الموقع لاحظنا إن بعض الصفحات لازالت بتعرض بيانات المستخدم!

التجربة دى غير لطيفة لبعض المستخدمين وممكن تخلى المستخدم يبعت Request من علامة تبويب بشراء منتجات هو حذفها أصلاً من علامة تبويب تانية، بس وقتها هو مش هيكون فاهم ليه الموقع بيقول له إن مفيش منتجات في السلة رغم إنه شايف الموقع بيعرض المنتجات قدامه، ومش هيفهم ليه الصفحة بتطلب تسجيل دخول رغم إنه سجل بالفعل ولكن من صفحة تانية، فعشان تحذف العبء دا من على دماغ المستخدم وتوفر له تجربة أفضل خلال رحلته أنت محتاج تخلى كل علامات التبويب متوافقين مع بعض وبيتحدثو باستمرار لو حصل تغيير بيستدعى دا ولكن في علامة تبويب مختلفة.

ودا بنقدر ننفذه من خلال الـ Broadcast Channel API اللى بيسمح لنا بارسال واستقبال البيانات بين علامات التبويب المختلفة.

طريقة استخدام الـ Broadcast Channel API

عملية التواصل بين علامات التبويب المختلفة محتاجة مننا 3 خطوات فرعية

• الخطوة الأولى هي إنشاء قناة للتواصل

• الخطوة التانية هى التجهيز لاستقبال الرسائل

• أما الخطوة التالتة والأخيرة هي ارسال البيانات على هيئة رسائل

الخطوة الأولى: إنشاء قناة للتواصل

يمكن إنشاء قناة للتواصل بين علامات التبويب المختلفة عن طريق الـ constructor الخاص بالـ BroadcastChannel وبواسطة الـ new keyword، كالمثال التالي:

بحيث my-channel هو اسم القناة ويمكن استبداله بأى اسم مناسب للهدف اللى تم إنشاء القناة من أجله، مثلا cart-channel أو auth-channel أو غيرهم.

اكمل القراءة

خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀

وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁

Start Your Journey

مدونات فطين في تصميم النظم - الإصدار الأول 🚀

كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.

على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:

• لماذا صُمّم هذا النظام بهذه الطريقة؟

• لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟

• هل كان يمكن أن نصمم الأمر بشكل أبسط؟

الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.

هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.

اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.

إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.

يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :

• Introduction Into System Design

• How Uber Serves Over 40 Million Reads Per Second

• How Discord Stores Trillions of Messages

• Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution

• Unlocking Notion's Power - The Data Model Explained

• How Shopify Mitigates Deadlocks in High Concurrency Environments

• How LinkedIn Improves Microservices Performance With Protobuf

• How Figma Secures Internal Web Applications

• How GitHub Improves Reliability of Code Push Processing

• How Meta Leverages AI For Efficient Incident Response

• How Stripe Architected Massive Scale Observability Solution on AWS

• Change Data Capture at Pinterest

• How Canva Built Scalable and Reliable Content Usage Counting Service

• How Netflix Migrates Critical Traffic at Scale With No Downtime

• How Slack Handles Billions of Tasks in Milliseconds

• How YouTube Supports Billions of Users With MySQL

• System Design Comprehensive Guide

تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇

Get Full Version Now

وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉

Kindle Edition

بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.

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

تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇

Join Us

رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.

لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.

وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.

لمعرفة المزيد بخصوص :

💬 المعايير العامة لكتابة ونشر المقالات

⚡️ كيفية الإرسال

🔥 التزامات اقرأ-تِك تجاه الكتاب

يمكنكم قراءة كافة التفاصيل من هنا 👇

Write With Us