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

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

فرق الهندسة في Stripe و Tempo بيقدموا open protocol جديد علشان الـ Agents تقدر تشتري ساندوتشات فول وطعمية بطريقة سهلة وبدون تدخل بشري. فيا ترى ايه اللي هيحصل لما الـ Agents يبدأ يبقى معاهم محفافظ ؟ وهل يا ترى هنوصل لمرحلة إن ممكن الـ Agents تشتري الحاجات اللي احنا عاوزينها بسهولة وبدون تدخل بشري فعلًا؟

تخيّل إنك مدي الـ coding agent عندك task: “حلّل الـ logs، ولو محتاج dataset مدفوعة اشتريها، وشغّل الـ browser session، واستخدم أفضل model للمهمة دي، وابعتلي النتيجة لما تخلص”.

الطبيعي واللي بنشوفه هو إن الـ agent عارف يخطط، وعارف يستدعي الـ APIs، ويستخدم كمان الـ tools، ولكن أول ما بيقابل خدمة مدفوعة، كل ده بيقف: فانت محتاج تعمل account، تختار plan، تدخل card، تعدّي الـ 3DS، وتنسخ الـ API key.

دي مش مشكلة intelligence؛ ولكن دي مشكلة إن الـ payment infrastructure اتبنت للبشر.

في مارس 2026، Stripe وTempo قدّموا Machine Payments Protocol — MPP: open protocol يخلي أي client آلي يطلب resource، يعرف سعره، يقدّم payment credential، وياخد النتيجة والـ receipt جوه نفس HTTP flow.

الفكرة شكلها صغيرة: HTTP 402 Payment Required بدل pricing page. لكن لو نجحت، هي ممكن تغيّر شكل الـ APIs، الـ SaaS، والـ internet economy نفسها.

الخلاصة قبل الدخول في التفاصيل

الـ MPP مش wallet، ومش blockchain، ومش payment processor جديد، ولكن هو لغة تفاوض موحّدة بين machine عايزة تشتري وservice عايزة تبيع.

الـ flow الأساسي:

1. الـ agent يطلب resource أو ينادي tool.

2. الـ service ترد بـ 402 ومعاها Challenge: السعر، العملة، والـ payment methods المقبولة.

3. الـ agent يطبّق spending policy، وممكن يطلب human approval.

4. الـ agent يبعت Credential تثبت إنه authorizes الدفع.

5. الـ service تتحقق وتعمل settlement على rail مناسب.

6. الـ service ترجع الـ resource ومعاه Receipt.

أهم نقطة: الـ protocol منفصلة عن طريقة تحريك الفلوس .. فنفس الـ handshake ممكن يشتغل فوق stablecoins، أو cards وLink عن طريق Shared Payment Tokens — SPTs، ومع methods تانية مستقبلًا.

المشكلة اللي MPP بتحاول تحلها فعلًا

الـ agent النهارده يقدر يكتشف tool عن طريق MCP، يفهم الـ schema، ويبعت request صح، ولكن الـ discovery والـ execution مش للدفع. والـ billing التقليدي بيفترض إن فيه إنسان هيعمل onboarding مرة واحدة:

Read more

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

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

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

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

• الـ AI في سطور: Opus 5 is Here 🔥

• شروحات رسومية بالورقة والقلم: Context Rot 🚀

• مقالات: الجزء الثاني من سلسةDevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series علي اقرأ تك ✏️

Opus 5 is Here 🔥

نشرة جديدة وموديل جديد و كل أسبوع وأنتم طيبين أعزائنا المبرمجين كوباية شاي و تعالوا نشوف ماذا يقدم لنا الموديل الجديد 🤷‍♀️

الخبر بيقول إيه؟

Anthropic أطلقت Claude Opus 5 يوم 24 يوليو 2026، وبتقدمه باعتباره الموديل العملي الأقوى عندها للاستخدام اليومي: قريب جدًا من مستوى موديلها الأعلى Claude Fable 5 في البرمجة والمهام المعقدة، لكن بتكلفة أقل تقريبًا للنصف في بعض اختبارات الـcoding agents. وفي نفس الوقت سعر الـAPI الأساسي لم يتغير عن Opus 4.8.

الفكرة الأساسية مش إن الموديل «بيكتب كود أسرع» فقط، لكن إنه أصبح أفضل في:

• فهم مشاكل أكبر وأكثر غموضًا.

• الاستمرار في مهام طويلة متعددة الخطوات.

• التحقق من شغله بدل تسليم أول حل يعمل.

• اكتشاف السبب الجذري للـbugs.

• استخدام الأدوات وبناء وسائل اختبار لنفسه عند الحاجة.

• الحفاظ على جودة أكثر ثباتًا بين تشغيل وآخر

كل دي بالطبع مشاكل بنقابلها حاليًا في استخدامنا لمعظم ال Models و لكن شوفنا تحسن كبير في Fable 5 بالأخص في جزء ال Long Tasks اللي ممكن ينفذها ال Agents ولكن لأن الحياة لا تحلو بلا ثمن ف Fable 5 جه فبتسعير غالي بالفعل!

الشركة هنا بتحاول تنافس نفسها بإنها تنزل موديل “بيحاول يقرب من نفس الكفاءة” ولكن بنصف الثمن,لأن السعر حاليًا هيفرق بشكل كبير في تبني موديلات الشركة ولا لاء وبالأخص بعد ما الموديلات مفتوحة المصدر أو الموديلات الصينية بالتحديد كفاءتها عليت جدًا بسعر قليل وابتدت تلحق بال Flagship Models.

طبعًا المشاكل اللي فوق ممكن نقلل تأثيرها في معظم الموديلات لو المستخدم بيقسم ال Prompts بدل ما يدي ال Agent مهام طويلة وأنه يكون مبرمج واعي وبيراجع ورا ال Model بشكل ناقد وفعال ودا اللي بنكسل نعمله فخلونا نشوف مميزات الموديل في الأجزاء دي.

ما يهم المبرمجين بالتفصيل

1. تحسن واضح في الـdebugging والـroot-cause analysis

أهم مثال عرضته Anthropic كان bug حقيقي في package manager مفتوح المصدر. Opus 5 لم يصلح الـsymptom الظاهر فقط، لكنه وصل للسبب الأساسي واكتشف edge case كان ناقصًا من الـpatch الذي اقترحه المجتمع.

ودي نقطة مهمة جدًا؛ لأن مشكلة موديلات البرمجة عادةً مش إنها لا تستطيع إنتاج fix، بل إنها تنتج fix يجعل الاختبار ينجح بينما يترك المشكلة الأساسية أو حالات أخرى غير مغطاة.

عمليًا استخدمه في:

• التحقيق في production incidents.

• تحليل race conditions والمشاكل المتقطعة.

• تتبع bug عبر أكثر من service.

• مراجعة fix والتأكد أنه لا يعالج الحالة الظاهرة فقط.

  ---

  2. أفضل في المهام الكبيرة التي كنا نقسمها يدويًا

  الـearly users ذكروا أنه تعامل مع تغييرات واسعة داخل codebases، واستمر في المهمة مع feedback متكرر، ونفذ أعمالًا كانوا عادةً سيقسمونها إلى tickets أو prompts أصغر.

  وده معناه أن الـagent يمكن أن يأخذ feature أكبر نسبيًا:

  افهم المتطلبات → استكشف الـcodebase → اقترح التصميم → نفذ → اختبر → راجع الـdiff.

  لكن ده مش معناه أنك تديله Jira ticket وتعمل merge مباشرة. الأفضل أنه يكون عندك checkpoints واضحة بعد الـplan، وبعد التنفيذ، وقبل الـmerge.

  ---

  3. الـdiffs أنظف والـcode review أقوى

  عدة شركات في الإعلان أشارت إلى أن Opus 5 بينتج diffs أصغر، dead code أقل، وبيكتشف Bugs دقيقة مرتبطة بالـcodebase نفسه. كمان وقت مراجعة الـ PR لا يقفز مباشرة للتنفيذ، بل يتحقق من الـbranches والـPR template وتأثير التغيير على الاختبارات.

  بالنسبة للمطور، قد تكون أقوى استخداماته:

  • independent review بعد أن ينفذ Agent آخر التغيير.

  • البحث عن missing acceptance criteria.

  • مراجعة backward compatibility.

  • اكتشاف تغييرات جانبية غير مطلوبة.

  • فحص error handling والـobservability والـtest coverage.

  وده في رأيي أهم من زيادة سرعة كتابة الكود نفسها؛ لأن القيمة الحقيقية بتظهر لما يقل عدد الـrounds بين «الكود خلص» و«التغيير خلاص مناسب للـproduction».

  ---

  4. مستوى الجهد أصبح قرار تكلفة وهندسة

  Opus 5 يدعم مستويات مختلفة من effort، بحيث تختار بين استدلال أكبر وجودة أعلى، أو استهلاك tokens أقل ونتيجة أسرع وأرخص. Anthropic تقول إن الموديل يتفوق من ناحية الأداء مقابل التكلفة على مستويات high وxhigh وmax في اختبارات البرمجة التي عرضتها.

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

  • Low effort: تعديلات صغيرة، شرح كود، boilerplate، tests بسيطة.

  • High effort: feature متوسطة، review، debugging معروف النطاق.

  • Max effort: incident معقد، architecture، migration، refactoring واسع أو bug غامض.

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

  ---

  5. السعر لم يرتفع عن Opus 4.8

  السعر المعلن للـAPI هو:

  • $5 لكل مليون input tokens

  • $25 لكل مليون output tokens

  وهو نفس سعر Opus 4.8. ويوجد Fast mode بسرعة تقارب 2.5 مرة السرعة الافتراضية، لكنه بسعر مضاعف على Claude Platform.

• النقطة المهمة هنا أن التكلفة الحقيقية لا تُقاس بسعر الـtoken فقط. لو الموديل بينجز المهمة من محاولات أقل، tool calls أقل، وبدون إعادة شرح مستمرة، فقد يكون أرخص لكل task حتى لو كان أغلى من موديل صغير لكل token.

تحديثان مهمان لبناء الـ Agents

تغيير الأدوات أثناء المحادثة دون كسر الـprompt cache

أصبح ممكنًا تغيير الأدوات المتاحة للموديل أثناء نفس المحادثة من غير invalidation للـprompt cache.

مثلًا:

1. تبدأ بأدوات قراءة الـrepository فقط.

2. بعد اعتماد الـplan تسمح بأداة تعديل الملفات.

3. بعد التنفيذ تضيف test runner.

4. قبل النشر تسمح بأداة deployment محدودة.

ده أفضل أمنيًا وأقل تكلفة من إعطاء الـagent كل الصلاحيات من البداية. الخاصية ما زالت beta.

Automatic fallbacks

تستطيع إعداد الـAPI بحيث لو طلب تم إيقافه بواسطة safety classifier في Opus 5، يتم توجيهه تلقائيًا لموديل آخر بدل فشل الطلب بالكامل.

ده مفيد للـproduction reliability، لكن يجب تسجيل اسم الموديل الذي نفذ الطلب فعليًا؛ لأن جودة وسلوك النتيجة قد يتغيران عند الـfallback.

الخلاصة للمبرمجين

زي ما تعودنا بناخد الأرقام في اعلانات النماذج مع شوية ملح من عندنا لأن بعضها مبني على internal evaluations أو شهادات early-access customers ويعني كل هذه الأشياء لا تخلو من حبة ال Marketing!

عشان كدا لا تعتبر الـbenchmarks ضمان للأداء على الـ repository الخاص بك. والأفضل قبل اعتماده أن تعمل eval صغيرة من مهامكم الحقيقية:

• 10 bugs قديمة معروفة الأسباب.

• 5 features متوسطة.

• 10 PR reviews.

• مهمة refactoring كبيرة.

• مهمة frontend مع visual verification.

وقارن بين نسبة النجاح من أول مرة، جودة الـdiff، عدد الـturns، إجمالي التكلفة، وعدد المشاكل التي اكتشفها البشر بعده.

ولو الأرقام انعكست فعلًا على المشاريع الحقيقية، فأفضل مكان له مش autocomplete أو سؤال برمجي صغير، ولكن الـagentic software engineering workflows: تنفيذ feature كاملة، debugging معقد، code review مستقل، refactoring واسع، والتحقق من أن التغيير جاهز فعلًا للشحن.

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉


أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

LLMs Context Rot 🚀

ممكن تدي الـ LLM عشرات الآلاف من الـ tokens، وتحط قدامه كل الـ documentation والـ code والـ requirements ولكن برضه يطلعلك بإجابة مختلفة من غير أهم شرط في التاسك اصلًا.

المشكلة هنا مش إن المعلومة مش موجودة، لكن إن الموديل ماعرفش يستخدمها بكفاءة وسط كل كمية الـContext ده. وده اللي بيتسمى Context Rot أو “تدهور السياق”.

يعني إيه Context Rot؟

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

فتخيل إنك قلت للـCoding Agent في بداية التاسك:

ممنوع نعمل retry للـdeclined payments.

وبعدها دخلت له:

• ملفات Code كتير

• Logs طويلة

• Documentation قديمة

• محاولات تنفيذ فشلت

• Comments من الـCode Review

• Requirements اتغيرت أثناء الشغل

في الآخر ممكن يعمل retry فعلًا، رغم إن الشرط الأصلي ما زال موجودًا داخل الـContext.

فالمعلومة موجودة… ولكن تأثيرها ضاع وسط الزحمة.

المشكلة بتظهر إزاي؟

أشهر شكل من أشكال الـ Context Rot هو Lost in the Middle: المعلومة المهمة بتكون مدفونة في نص Context طويل، فيركز الموديل على المعلومات الموجودة في البداية أو القريبة من الطلب الحالي.

وممكن كمان تحصل بسبب:

Noise: تفاصيل كتير مالهاش علاقة مباشرة بالقرار الحالي.

Conflicts: تعليمات أو Documents بتقول حاجات متعارضة.

الـ Stale Context زي : Plan أو Assumption قديم ما زال موجودًا رغم إنه اتغير.

Error Accumulation: افتراض صغير غلط بيتكرر في الخطوات التالية، لحد ما الموديل يبدأ يتعامل معاه كأنه Fact مؤكدة.

وده بيفسر ليه أحيانًا الـAgent يبدأ التاسك بشكل كويس، وبعد محادثة طويلة تلاقيه:

• نسي Acceptance Criterion.

• رجع نفذ Requirement قديم.

• كرر Bug كان صلحه قبل كدا .

• كتب Tests تثبت الـImplementation بتاعه، مش السلوك المطلوب.

• بدأ يناقش قرار الفريق حسمه من فترة.

إيه اللي يهمك كمبرمج؟

أهم نقطة: متتعاملش مع الـContext كأنه Database.

كون الموديل يقدر يستقبل 100 ألف أو مليون token مش معناه إن أفضل حل إنك تبعتله كل حاجة عندك، فبدل ما تسأل:

إزاي أحط أكبر كمية معلومات في الـContext؟

اسأل:

إيه أقل كمية معلومات صحيحة يحتاجها الموديل عشان ينفذ الخطوة الحالية؟

الخلاصة

الـContext الكبير مش بالضرورة Context جيد ولكن الـContext الجيد لازم يكون:

Relevant + Current + Structured

في تطبيقات الـLLMs والـAI Agents، شغلك مش مجرد إنك “تحط المعلومات قدام الموديل”، لكن إنك تدير انتباهه وتحدد له إيه المهم في كل خطوة.

سؤال: هل لاحظتم قبل كده إن الـ Coding Agent بدأ التاسك بشكل ممتاز، لكن كل ما المحادثة طولت بدأ ينسى Requirements أو يكرر أخطاء قديمة؟ اكتبولنا في التعليقات حصل معاكم ايه؟

DevOps Beyond the Tools

نزلنا ٣ مقالات جديدة في سلسلة DevOps & Cloud Computing Series، السلسلة موجهة للمبتدئين هتساعدك تبني فهم حقيقي لمجال ال DevOps. هنسأل بنستخدم كل أداة ليه بلغة بسيطة، ونوضح أهميتها وإزاي بتسهّل شغلنا، قبل ما نتكلم عن طريقة استخدامها. ☁️⚙️

ودا لأن كتير من الناس بتبدأ تتعلم DevOps و Cloud Computing على إنه أدوات زي Docker وKubernetes وTerraform، لكن من غير ما تفهم ليه الأدوات دي موجودة أصلًا، وإيه المشكلة اللي بتحلها، وإمتى نستخدمها. 🤔

المقالات الأربعة الأولى:

• DevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series

• Why Cloud Computing Appeared?

• Why Docker Appeared?

• Why Kubernetes Appeared?

المقالات الثلاث الجديدة:

• Why Terraform Appeared?

• Why CI/CD Appeared?

• Monitoring vs. Observability

  نتمنى السلسلة تكون بداية سهلة لأي حد عايز يدخل مجال الـ DevOps والـ Cloud Computing ويكون فاهم كل أداة ابتدأت منين قبل ما يستخدمها 💪

السلسلة من كتابة : Alaa Nassar🌟

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

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

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

• الـ AI في سطور: Kimi K3 Outperforms Claude Fable 5 in Frontend Coding 🔥

• شروحات رسومية بالورقة والقلم: Batch API In LLMs Explained 🚀

• مقالات: سلسلة جديدة للمبتدأين علي اقرأ تك بعنوان DevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series ✏️

Kimi- K3 Outperforms Claude Fable 5 in Frontend Coding 🔥

أعلنت Moonshot AI عن إطلاق Kimi K3، أحدث نماذجها مفتوحة الأوزان (Open Weight)، بحجم 2.8 تريليون بارامتر، مع Context Window تصل إلى 1M Token ، ودعم مدمج لفهم الصور (Native Vision).

لكن الإعلان مكنش بس إطلاق نموذج جديد، ولكن جه بنتائج لافتة.

ففي تصنيف LLM Arena، قدر Kimi K3 ينتقل من المركز الثامن عشر إلى المركز الأول في فئة Frontend Code، متفوقًا على Claude Fable 5.

أبرز ما جاء مع Kimi K3

• أداء تنافسي مع أفضل النماذج لأنه قرب بالفعل من أداء Claude Fable 5 وGPT-5.6 Sol

• عرض عملي مثير للإعجاب
  في تجربة مباشرة، استخدم فريق Moonshot مجموعة من وكلاء الذكاء الاصطناعي (Agent Swarm)، واستغرقوا حوالي 3 ساعات لبناء نسخة تعمل بالكامل داخل المتصفح من ل macOS 27! و مش بس كدا دا فيها :تصميم Liquid Glass, تطبيقات تحاكي تطبيقات النظام الأصلية ولعبة شطرنج تعمل بشكل كامل

• الإتاحة
  النموذج متوفر حاليًا عبر Kimi.com وواجهة Kimi API، بينما تخطط Moonshot لإتاحة الأوزان الكاملة للنموذج كمصدر مفتوح في 27 يوليو 2026.

• التسعير
  تبدأ تكلفة استخدام الـ API من:

• 3 دولارات لكل مليون توكن إدخال غير مخزنة مؤقتًا (Uncached Input Tokens)

• 15 دولارًا لكل مليون توكن إخراج

وهي نفس الأسعار المعلنة لنموذج Claude Sonnet.

ليه إعلان النموذج دا مهم؟

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

تسعير Kimi K3 بمستوى قريب من Claude Sonnet بيعكس ثقة Moonshot في قدرات النموذج، وبيأكد أن المنافسة لم تعد تعتمد على انخفاض التكلفة، بل على جودة النتائج الفعلية.

والأهم أن تفوق Kimi K3 في مهام ال Frontend بهذا الشكل بيشير إلى تحول واضح في السوق؛ فلم يعد هناك الفارق الكبير اللي كان يفصل بين النماذج مفتوحة الأوزان والنماذج المغلقة. واليوم أصبحت النماذج المفتوحة قادرة على المنافسة، بل والتفوق، في بعض أكثر المهام تعقيدًا.

وقت واعد جدًا للنماذج مفتوحة المصدر، هل ممكن الفترات اللي جاية تتبناها الشركات بشكل رسمي؟! قولولنا رأيكم🤔

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉


أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

Batch API in LLM Explained ⚙️

Batch API معناه إنك تجمع عدد كبير من الطلبات المستقلة وتبعتها كدفعة واحدة، بدل ما تبعت كل request وتستنى الرد لحظيًا. مزود الخدمة يعالجها في الخلفية خلال فترة زمنية محددة، غالبًا ساعات أو حتى 24 ساعة، مقابل سعر أقل من الـAPI العادي. فعند مزود زي OpenAI Batch API بيخلي التكلفة 50% أقل!

تخيّل عندك 50,000 ticket من Jira / Zendesk / Intercom، وعاوز تصنّفهم مثلًا إلى:

Billing, Bug, Feature Request, Account, Technical Support, Refund, Other

بدل ما تبعت كل ticket للـ API وتستنى الرد فورًا، بتجهّزهم كلهم كـ batch job وتبعته مرة واحدة، والنتيجة ترجعلك لاحقًا.

الفكرة ببساطة بدل الشكل ده:

Ticket 1 → API → wait → result
Ticket 2 → API → wait → result
Ticket 3 → API → wait → result

يبقى الشكل كده:

Tickets file:
- Ticket 1
- Ticket 2
- Ticket 3
- ...
- Ticket 50,000

        ↓

Batch API

        ↓

Results file لاحقًا

في المثال اللي ذكرته، السعر ينزل للنصف من $10 input / $50 output لكل مليون token إلى $5 input / $25 output عند استخدام الـBatch API. طبعًا دا قلل التكلفة ولم تخسر شيئاَ لأن المهمة ممكن تخلص بشكل Asynch.

امتى استخدم الـ Batch API ؟

الـBatch API مناسب للمهام اللي مش محتاجة رد فوري، أي حاجة تقدر تعملها بشكل Asynch زي:

• تلخيص آلاف الملفات

• تصنيف tickets

• تحليل logs علي مدار اليوم

• إنشاء embeddings أو metadata

• مراجعة كمية كبيرة من PRs القديمة

• تشغيل evaluations على prompts وموديلات مختلفة.

  لكنه غير مناسب لواجهة chatbot مباشرة أو coding assistant أثناء ما أنت بتكتب كود، لأن المهام دي بطبيعتها Synchronous وبتحتاج رد فوري وتفاعل و مش هينفع تنتظر نتيجة الدفعة بدل الاستجابة اللحظية.

  ما الفرق بينه وبين ال Prompt Caching ؟

  الاثنين بيوفروا في فاتورة استخدامك لل LLMs ولكن كل واحد ليه دوره وشرحنا ال Prompt Caching في ورقة وقلم من قبل تقدروا تشوفوه من هنا.

• باختصار: استخدم prompt caching لما نفس السياق الطويل بيتكرر في requests كثيرة واستخدم Batch API لما عندك requests كثيرة لكن مش محتاج نتائجها فورًا.

DevOps Beyond the Tools

كتير من الناس بتبدأ تتعلم DevOps و Cloud Computing على إنه أدوات زي Docker وKubernetes وTerraform، لكن من غير ما تفهم ليه الأدوات دي موجودة أصلًا، وإيه المشكلة اللي بتحلها، وإمتى نستخدمها. 🤔

علشان كده بدأت سلسلة DevOps & Cloud Computing Series، سلسلة موجهة للمبتدئين هتساعدك تبني فهم حقيقي لمجال ال DevOps. هنسأل بنستخدم كل أداة ليه بلغة بسيطة، ونوضح أهميتها وإزاي بتسهّل شغلنا، قبل ما نتكلم عن طريقة استخدامها. ☁️⚙️

هدفنا إنك تخرج من كل مقال فاهم الفكرة قبل الأداة، وتكون قادر تربط بين التقنيات المختلفة بدل ما تحفظها بشكل منفصل. 🚀

نزل إلي الآن ٤ مقالات من السلسلة:

• DevOps Beyond the Tools: Intro of DevOps and Cloud Computing Series

• Why Cloud Computing Appeared?

• Why Docker Appeared?

• Why Kubernetes Appeared?

نتمنى السلسلة تكون بداية سهلة لأي حد عايز يدخل مجال الـ DevOps والـ Cloud Computing ويكون فاهم كل أداة ابتدأت منين قبل ما يستخدمها 💪

سلسلة جديدة مميزة بالعربي من كتابة : Alaa Nassar🌟

تقدروا تشوفوا أول مقال كامل من هنا وقراءة ممتعة 🎉

قراءة المقال الأول

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

فريق الـ Engineering في Slack، بدأ يجرب حاجة اسمها Agentic Testing — بمعنى تاني تسيب الـ AI agent يعمل الـ testing بدل ما تكتبه بإيدك. والسؤال المهم هنا: هل ده هيحل محل الـ tests التقليدية؟ ولا مكانه مختلف خالص؟ وايه المميزات اللي بيقدمها؟

مصطلحات مهمة — Terminologies

قبل ما ندخل في التجربة علطول، خلونا نتكلم عن بعض المصطلحات عشان الكلام كله يكون واضح:

• الـ E2E Testing (End-to-End): ده اختبار بيتأكد إن التطبيق شغال من أوله لآخره زي ما المستخدم الحقيقي هيستخدمه، يعني بدل ما تختبر function صغيرة لوحدها، إنت بتمثّل رحلة كاملة: افتح الصفحة → اضغط زرار → اكتب حاجة → اتأكد إن النتيجة ظهرت صحيحة.

• الـ Deterministic Test: هو عبارة عن test “محدد سلفًا” — بيعمل نفس الخطوات بالظبط في كل مرة، ولو الظروف اتغيرت بيفشل .. بمعنى تاني هو بيكون test متوقّع ومكرر.

• الـ Playwright: من أشهر الـ frameworks لكتابة الـ E2E tests للمواقع ، وبيتحكم في المتصفح بالكود (يفتح صفحات، يضغط، يكتب... إلخ).

• الـ MCP (Model Context Protocol): بروتوكول بيسمح للـ agent إنه يتكلم مع أدوات خارجية بطريقة منظّمة (structured)، فهنا Playwright MCP بيدّي الـ agent أوامر جاهزة للمتصفح.

الانتقال من اختبار “الرحلة” لـ “الهدف” — الفرق الجوهري

الفكرة كلها بتبدأ من هنا: الـ test التقليدي بيختبر رحلة محددة جوه الـ UI:

click → click → type → assert

يعني إنت بتقوله بالظبط: دوس هنا، بعدين هنا، اكتب كده، وبعدين اتأكد إن كذا حصل .. ولو أي حاجة اتحركت من مكانها، الـ test طبعًا بيقع.

بينما الـ agent بيشتغل بطريقة تانية ومختلفة خالص: إنت بتديله هدف (goal)، وهو اللي بيدبّر نفسه:

goal → agent adapts → verify result

فمثلًا بنقوله: “ابعت رسالة في thread” — وهو بقى يشوف إزاي يعملها .. الجملة اللي ممكن تلخّص الفكرة كلها هي إن:

الـ Tests بتفرض رحلة محددة بينما الـ Agents بتتحقق من الهدف (Tests enforce journeys. Agents verify goals.)

الـ Diagram ده بيوضّح الفرق:

في تجارب Slack، الـ workflow العام فضل ثابت (مثلًا: login → search → result → clear)، لكن الخطوات بالتفصيل اتغيرت من run للتاني، فالـ agent كان بياخد طرق مختلفة يوصل بيها لنفس النتيجة:

• طرق إدخال مختلفة (يدوس على اقتراح في الـ search vs يدوس Enter)

• أنماط navigation مختلفة (يفتح الـ search من جديد vs يستخدم الـ state الموجود)

• خطوات زيادة أو ناقصة (ضغطات زيادة، snapshots، أو خطوات وسيطة)

المشكلة الحقيقية

الـ agentic testing شكله حلو وجميل، بس فيه سؤال محرج شوية لازم نسأله:

حاجة بتكلّف من 15 لـ 30 دولار في الـ run الواحد وبتاخد أكتر من 10 دقايق — هل ممكن تدخل فعلًا في workflow حقيقي؟

من أول نظرة الإجابة تبان إن بكل تأكيد “لأ”... بس بعد أكتر من 200 run، هنلاقي Slack اكتشفت إنها حاجة مختلفة جوهريًا عن الـ tests التقليدية، وممكن تبقى reliable جدًا، وليها مكان واضح في الـ testing stack.

السبب في كل ده هو التطور اللي حصل في الـ LLMs مؤخرًا، واللي خلّى الـ agents تقدر تكتب كود، وتعمل debug للـ failures، وتتفاعل مع الـ UI مباشرة بسهولة وسلاسة.

التجربة نفسها

عشان يفهموا الـ agent-driven tests ازاي تقدر تـ Fit وتكون جزء أساسي وضمن هيكلة الـ Testing Stack، فـ Slack شغّلت أكتر من 200 execution عن طريق إعدادات مختلفة، وكانوا هدفهم إنهم يقيسوا من خلالها 3 حاجات: الـ reliability، السرعة، والتكلفة.

نماذج التنفيذ — Execution Models

جرّبوا ٣ طرق مختلفة:

1. الـ Agent + Playwright MCP: الـ agent بيتعامل مع المتصفح من خلال الـ Playwright MCP، بيستخدم أوامر جاهزة (دوس على element، اكتب input، اقرا الـ DOM state...) مع الاحتفاظ بالـ context (snapshots و logs).

2. الـ Generated Playwright Tests: هنا الـ agent بياخد وصف بلغة عادية جدًا، ويكتب كود Playwright حقيقي (deterministic)، يشغّله كـ E2E test عادي، ويظبطه شوية بشوية لحد ما ينجح.

3. الـ Agent + Playwright CLI: الـ agent بيشغّل أوامر Playwright من الـ shell، وبينفّذ خطوة واحدة كل مرة، ويقرر اللي بعدها بناءً على حالة الـ UI الجديدة.

إعدادات التجربة — Setup

• الـ Model للـ MCP/CLI كان: Claude Sonnet 4.5

• الـ Model للـ Generated Tests كان : Claude Opus 4.6

• التنفيذ: Claude Code بوضع non-interactive (claude -p)

• كل التجارب اتعملت في test workspaces ببيانات مش حقيقية (non-production data) — ودي نقطة مهمة جدًا للأمان.

الـ Flows اللي اتجربت

استخدموا 2 flows بس بمستويات تعقيد مختلفة، وثبّتوهم في كل التجارب عشان المقارنة تبقى عادلة:

• الـ Thread Reply (بسيط): ~15–20 خطوة — يعمل channel، يبعت رسالة، يرد في thread، ويتأكد من حالة الـ thread.

• الـ Search Discovery (متوسط): ~25–30 خطوة — يكتب search queries، يتنقّل في النتايج، يتحرك بين الـ views المختلفة (search, channels, threads)، ويتأكد من النتايج.

شكل الـ Input

للطرق اللي فيها agent، جرّبوا نوعين من الـ Inputs:

• الـ Natural Language (NL): تعليمات مكتوبة بلغة بشرية عادية بالتفصيل (مثلًا: “رد في thread، واتأكد إنه ظهر في All Threads”).

• الـ Structured YAML: نفس الـ workflow بس بصيغة منظّمة، بخطوات و actions و targets و expected outcomes واضحة.

والفرق هنا مكنش في كمية التفاصيل، ولكن الفرق في إزاي التفاصيل متمثّلة: الـ NL بيحتاج الـ agent يفسّر ويترجم الكلام لأفعال، أما الـ YAML فبيحدد الربط ده بشكل صريح أكتر وبشكل مباشر.

Experiment Matrix

كل Configuration اشتغل تقريبًا 20 مرة:

النتايج — اللي لاحظوها

خلونا نفصّص النقاط دي واحدة واحدة.

1) الاعتمادية — Reliability

أكتر pattern واضح شافوه: هو إن الـ reliability بتتغير كل ما الـ flow يبقى أعقد.

• الـ Playwright MCP كان الأكثر ثباتًا — failure قريب من الصفر في السيناريوهات البسيطة، وبين 0–12% في الأعقد.

• الـ Playwright CLI كان failure أعلى (تقريبًا 12–20%)، ومعظم المشاكل كانت من حاجات تنفيذية زي الـ authentication، توقيت الـ navigation، وعدم استقرار الـ session — مش من تفكير الـ model نفسه.

• الـ Generated Tests كانت كويسة في البسيط (~8%)، بس اتدهورت بشكل كبير في الأعقد (~48%). الحلو إنها مكانتش غلط تمامًا — كانت بتكمّل 70–80% من الـ flow وبعدين تقع في آخر تفاعل أو assertion.

ليه الفرق ده؟ السبب الأرجح هو إزاي كل طريقة بتتعامل مع الـ state:

Read more

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

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

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

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

• إنطلاق إستبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

• الـ AI في سطور: OpenAI Launches GPT-5.6 🔥

• شروحات رسومية بالورقة والقلم: Prompt Caching Explained 🚀

• أدوات وتقنيات ومشاريع عربية: ملتقى إتقان لتقنيات القرآن ✨

إنطلاق استبيان مجرة | أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

أخر 3 سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

مجرة بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

الاستبيان مفتوح وتقدروا تشاركوه فيه الآن , وقت ملأ الاستبيان لا يتعدي ال ١٠ دقائق ولكنه فعلًا هيعكس صورة الوضع الحالي في الوطن العربي ، شاركوا كمان الاستبيان مع كل اللي تعرفوه وساعدوا في نشره علشان كل ما العدد زاد كل ما البيانات كانت أدق وأوقع ✨

ابدأ الاستبيان

OpenAI Launches GPT-5.6 🔥

الموديلات مبقتش بتجاوبك بس… بقت بتقسّم الشغل على نفسها! 🌞

أعلنت OpenAI عن عائلة GPT-5.6 الجديدة، والمكوّنة من 3 موديلات:

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

• Terra لتحقيق توازن بين الجودة والتكلفة.

• Luna للمهام السريعة والـ workloads الكبيرة.

بس بعيدًا عن أرقام الـ benchmarks المعتادة، أكتر حاجة مثيرة للاهتمام في GPT-5.6 مش إنه «أذكى شوية» من الجيل اللي قبله ، ولكن الفكرة إن OpenAI بتحاول تغيّر المقياس اللي بنحكم بيه على الموديلات أصلًا.

بدل ما تسأل: الموديل عرف يحل كام سؤال؟

السؤال بقى: قدر يكمّل كام مهمة حقيقية؟ استخدم كام Tool Call؟ استهلك كام Token؟ واحتاج منك تدخل كام مرة؟

OpenAI بتقول إن GPT-5.6 بقى أفضل في المهام الطويلة اللي محتاجة تخطيط، استخدام أدوات، مراجعة النتيجة والاستمرار لحد ما المهمة تخلص، مع استهلاك Tokens ووقت أقل في عدد من الاختبارات. وفي تجارب Lovable مثلًا، الموديل احتاج خطوات وTool Calls أقل، وقلّل عدد المهام اللي بتقف في النص.

وده مهم لأن تكلفة الـ AI Agent مش سعر الـ Token بس، ولكن التكلفة الحقيقية هي:

عدد المحاولات + الوقت الضايع + تدخل الإنسان + المهام اللي فشلت واضطريت تبدأها من الأول.

من وكيل واحد — لفريق من الوكلاء

GPT-5.6 بيقدّم كمان وضع جديد اسمه Ultra، بيشغّل 4 Agents بالتوازي بشكل افتراضي، وكل Agent يشتغل على جزء مختلف من المشكلة قبل ما النتائج تتجمع في إجابة أو تنفيذ واحد.

يعني بدل ما الـ Agent يعمل:

بحث → انتظار → تحليل → انتظار → مراجعة

يقدر يقسّم البحث والتحليل والمراجعة على أكتر من Agent في نفس الوقت.

وده تقريبًا نفس اللي بنعمله في فرق البرمجيات: مش بنحاول نخلي مهندس واحد يعمل كل حاجة أسرع، لكن بنقسّم المشكلة لمسارات شغل مستقلة. وده بقى الاتجاه السائد نوعًا ما من كل الـ Agentic Workflows اللي موجودة وازاي يخلوا الـ SDLC موجود من خلال الـ Agents.

لكن الاستقلالية الأعلى محتاجة رقابة أعلى

القوة دي ليها جانب تاني مهم.

في الـ System Card هنلاقي إن OpenAI قالت إن GPT-5.6 أحيانًا بيكون أكثر إصرارًا على إكمال المهمة لدرجة إنه ممكن يتجاوز نية المستخدم أو ينفذ تصرفات لم تُطلب منه بوضوح، رغم إن المعدلات المطلقة ما زالت منخفضة.

ولكن ده معناه إن كل ما الـ Agents تبقى أقدر على التنفيذ، تصميم الصلاحيات والـ approvals والـ audit logs والـ rollback mechanisms هيبقى أهم من كتابة الـ Prompt ذات نفسه.

الخلاصة:
GPT-5.6 مش مجرد موديل قوي؛ بل هو خطوة إضافية مهمة في تصميم أنظمة الـ AI اللي بقت بتستلم هدف كبير، تقسّمه لمهام أصغر، وتستخدم الأدوات المتاحة، وتراجع نفسها، وتسلّم نتيجة شبه جاهزة للمستخدم.

وكالعادة علشان كده المرحلة الجاية مش هتكون منافسة بين الـ Models وبس… وده اللي شايفينه من بعد Claude Opus للـ Fable وكذلك من باقي الشركات .. ولكن المنافسة الحقيقية بقت بين الـ Agent Harnesses والأنظمة اللي بتعرف توظّف الموديلات دي بأمان وكفاءة أفضل.

Prompt Caching Explained 🚀

الـ Prompt Caching معناه إنك بتخلي مزود الـAPI يحتفظ مؤقتًا بجزء ثابت ومتكرر من الـprompt، بدل ما تبعته ويتحسب عليك بالكامل مع كل request. مثلًا لو عندك system prompt طويل فيه قواعد المشروع، أو documentation، أو أجزاء ثابتة من الـcodebase، وتستخدمهم مع كل سؤال جديد؛ أول مرة بتبعتهم عادي، وبعد كده الطلبات التالية بتشير لنفس المحتوى المخزّن. النتيجة إن تكلفة الـinput tokens المتكررة بتقل، وأحيانًا ال latency كمان يتحسن.

مثال بسيط: لو عندك prompt ثابت حجمه 100 ألف token، وكل مرة بتضيف له سؤال جديد حجمه 500 token. من غير caching، هتدفع تكلفة الـ100,500 token في كل طلب. مع caching، بتدفع تكلفة إنشاء الـcache في البداية، وبعدها تدفع سعر أقل بكثير على الـ100 ألف token المخزنين، بالإضافة لتكلفة السؤال الجديد.

فرتّب دايمًا الـ prompts بحيث المحتوى الثابت ييجي الأول، والمحتوى المتغيّر ييجي في الآخر. لو أكتر من 50% من الـ input tokens بتتكرر بين الطلبات، يبقى الأفضل تفعّل الـ caching.

و كمان حاليًا كل الشركات الكبيرة بقت بتدعمه بشكل تلقائي لأنه ممكن يوفر لحد 50% من التكلفة و يسرع وقت الاستجابة بنسبة 80%.

• OpenAI تدعمه بشكل تلقائي

• Anthropic بشكل صريح

• Google Gemini بشكل ضمني أو صريح

• DeepSeek بشكل تلقائي.

ليه الـ Prompt Caching مهم؟

في حاجتين بيأثروا على مشاريع الـ LLM في بيئة الإنتاج: التكلفة ووقت الاستجابة. والـ Prompt Caching بيعالج الاتنين.

معظم الفرق بتكتشف ده بالطريقة الصعبة. الـ proof of concept بيشتغل بشكل ممتاز، وبعد كده الترافيك بيزيد، والفاتورة بتوصل وبنُصدم بالأرقام!

والأصعب إن أغلب تطبيقات الـ LLM في ال Production بتعيد معالجة نفس الـ context آلاف المرات يوميًا: نفس الـ system prompt، ونفس تعريفات الأدوات، ونفس المستندات المرجعية. وكل طلب بيدفع التكلفة الكاملة على tokens النموذج شافها قبل كده.

كيف يعمل الـ Prompt Caching؟

خلينا متفقين إن الـ Prompt Caching مش بيخزن إجابات النموذج ولا بيعمل Semantic Caching هو بيخزن (حسابات ال Key-Value Pairs) للأجزاء الثابتة من ال Prompt بتاعك وبيعيد النموذج استخدامها وقت ما يجد تشابه بين جزء من الطلب الجديد والقيم المتخزنة عنده بالفعل فيقسم ال Prompt لجزءين:

• جزء ثابت (Static): بيحصل علي قيمته من ال Cache بدون استخدام.

• جزء متغير (Dynamic): بيقوم بحسابه واستخدام tokens جديدة في هذه العملية.

اكمل القراءة

ملتقى إتقان لتقنيات القرآن ✨

يوم الجمعة 10 يوليو كان بداية لأكبر تجمع للتقنيات القرآنية في القاهرة في موسمه الثاني واللي كان بيضم فعاليات مثمرة واللي نتمنى تكرار مثل هذه الفعاليات الجميلة في الوطن العربي والمشاركة فيها .. الملتقى كان بيضم:

• عروض لـ 10 مشاريع قرآنية مشاركة

• جلسات تعارف ونقاش مفتوح بين الحضور

• استعراض أبرز إنجازات المجتمع في التقنيات القرآنية

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

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

أخبار الـ AI كترت علينا أخر 10 أيام فقولنا نميز العدد ده بأهم الأخبار ونشوف ازاي نستفيد منها كمبرمجين, فيلا بينا!

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

• OpenAI Previews GPT-5.6 Sol 🌞

• Claude Fable 5 has Returned 🚀

• GLM-5.2 :The Open Source Finally in the Frontier 🔥

OpenAI Previews GPT-5.6 Sol

أعلنت OpenAI عن إطلاق نسخة تجريبية محدودة من نموذجها الجديد GPT-5.6 Sol، تحت إشراف الحكومة الأمريكية.

الشركة كمان نزلت نموذجين أقل سعرًا:

• Terra: بسعر يقارب نصف سعر GPT-5.5 مع أداء متقارب.

• Luna: كخيار اقتصادي منخفض التكلفة.

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

من ناحية الأداء، GPT-5.6 Sol حقق 88.8% على اختبار TerminalBench 2.1 الخاص بال Coding Agents ، متفوقًا بشكل طفيف على Claude Mythos 5 اللي سجل 88%. أما وضع “Ultra” متعدد الوكلاء فوصل إلى 91.9%

ومن المتوقع إن التكامل مع Cerebras خلال يوليو يرفع السرعة إلى 750 توكن في الثانية. ورغم إن سعره مماثل لـ GPT-5.5، تحسين كفاءة استهلاك التوكنز ممكن يقلل تكلفة تنفيذ المهام الفعلية بشكل ملحوظ.

قدرات سيبرانية أقوى مع ضوابط حماية أشد

الأهم إن النماذج الثلاثة الجديدة OpenAI صنفتها High Cybersecurity Risk. وده معناه إن أقوى النماذج المتاحة حاليًا، مثل Anthropic Fable 5 وMythos 5، بالإضافة إلى Sol وTerra وLuna من OpenAI، مش هتكون متاحة لعامة المستخدمين قبل مراجعات الأمن السيبراني الحكومية الأمريكية.فالسؤال دلوقتي مبقاش: مين عنده أفضل نموذج؟ لكنه بقى: أي نموذج مسموح لنا فعلًا نستخدمه؟

تم تطوير GPT-5.6 Sol وTerra وLuna مع أقوى إجراءات حماية طبقتها الشركة حتى الآن، بحيث تتناسب ال safeguards مع مستوى قدرات كل نموذج. الهدف هو أن تظل الحماية فعّالة أمام محاولات إساءة الاستخدام الواقعية، من غير ما تعطل الاستخدامات المشروعة مثل مراجعة الكود، البحث عن الثغرات، تطوير التحديثات الأمنية، الـdebugging، التعليم الأمني، والاختبارات الدفاعية.

النموذج GPT-5.6 Sol أفضل في مساعدة فرق الأمن على اكتشاف الثغرات وإصلاحها، لكنه لا يستطيع بشكل موثوق تنفيذ هجوم سيبراني كامل من البداية للنهاية. في اختبارات على Chromium وFirefox، قدر يحدد bugs وعناصر أساسية قد تدخل في بناء exploit، لكنه لم ينجح بشكل مستقل في إنتاج exploit كامل وفعّال ضمن ظروف الاختبار.

النموذج لا يتجاوز مستوى “Cyber Critical” حسب إطار التقييم الخاص بالشركة، لكن بسبب تطور قدراته بشكل ملحوظ واحتمال دمجه مع أدوات أخرى. الفكرة هي زيادة فائدته للمطورين وفرق الـdefensive security، مع جعل الاستخدام الهجومي المحظور أصعب وأقل قابلية للتنفيذ وأسهل في الاكتشاف.

اللي يهمنا كمبرمجين

هل أرقام ال Benchmarks فعلاً مفيدة؟

قراءة أخبار ال Models الجديدة من الشركات وأرقام ال Benchmark المبهرة دايمًا محتاجين ناخدها بإن عليها رشة ملح من المبالغة عشان التسويق.

بالفعل أرقام الـbenchmarking بتديك إشارة مفيدة، لكن نادرًا ما تكون حكمًا نهائيًا على جودة الموديل في شغلك. اعتبرها مؤشر اتجاه وليس ضمان أداء.

السبب إن كل Benchmark بيقيس شريحة ضيقة من القدرات تحت ظروف ثابتة: prompt محدد، بيانات تقييم معينة، أدوات محددة، وعدد محاولات أو budget معين. بينما شغلك الحقيقي فيه codebase خاص، conventions داخل الفريق، dependencies، أخطاء غير متوقعة، صلاحيات، واحتياج لفهم سياق طويل. موديل متفوق بـ3% في benchmark ممكن ما يفرقش معاك إطلاقًا، وموديل أقل في الرقم لكنه أسرع وأرخص وأكثر ثباتًا قد يكون أفضل في الإنتاج.

بنركّز كمان على نوع الـbenchmark نفسه. Benchmark مثل TerminalBench بيقيس قدرة الـagent على تنفيذ مهام في terminal، وبالتالي أقرب لسيناريوهات مثل تصليح bug، تشغيل tests، التعامل مع Git، أو تعديل ملفات متعددة. لكنه لا يثبت بالضرورة أن الموديل هيكتب architecture مناسب لمشروعك أو هيفهم business logic صح.

بالمقابل، benchmarks من نوع SWE-bench مفيدة أكثر في إصلاح issues داخل repositories حقيقية، لكنها برضه ممكن تتأثر بطريقة إعداد الـagent والأدوات المتاحة له.

الخطط البديلة ضرورية

زي ما وضحنا في أكثر من نشرة قبل كدا خطورة ال Vendor lock-in وبما إن الإتاحة العامة (طول الوقت) للنماذج دي غير مضمونة، ابنِ الـworkflow بحيث لا يرتبط بموديل واحد أو مورد واحد. استخدم abstraction layer للـLLM provider، وثبّت prompts و evaluation suite خاصة بمشروعك، واحتفظ بخيارات بديلة من OpenAI وAnthropic أو نماذج مفتوحة المصدر حسب متطلبات الخصوصية. ولو بتبني منتج معتمد على الذكاء الاصطناعي، متوعدش العملاء بميزة مبنية على موديل غير متاح للعامة. صمّم المنتج بحيث يعمل بمستوى جودة مقبول على الموديلات المتاحة حاليًا، ثم حسّنه تدريجيًا عند توفر موديلات أقوى.

Claude Fable 5 has Returned 🚀

تحت شعار “عاد إليكم من جديد!”

بعد 19 يوم من المنع، نموذج Claude Fable 5 رجع متاح عالميًا من خلال Claude.ai وClaude Code وClaude Cowork.

التعليق بدأ في يونيو بعد ما باحثين من Amazon وثّقوا طريقة Jailbreak خلت النموذج يقدر يحدد ثغرات في برمجيات مختلفة، وده أدى لتوجيه أمريكي خاص بضوابط التصدير فاضطرت الشركة تمنعه من كل المستخدمين وسحبته بالفعل.

خلال الفترة دي Anthropic درّبت Safety Classifier جديد يقدر يمنع الطريقة دي بشكل موثوق، وبعدها الحكومة رفعت القيود يوم 30 يونيو.

Anthropic رجّعت النموذج مع Classifiers جديدة هدفها منع إساءة الاستخدام في الأمن السيبراني. لكن خلال مرحلة الضبط وتقليل الـfalse positives، ممكن بعض من مهام البرمجة والـdebugging تتحول مؤقتًا إلى Opus 4.8 بدل Fable 5.

وفي نفس الوقت، نموذج Mythos 5 بيرجع بشكل محدود لمجموعة من المؤسسات الأمريكية ضمن برنامج Glasswing. بالنسبة للمطورين، رجوع Fable 5 إلى Claude Code يعتبر أهم حدث لمستخدمين Claude الفترة دي لأنه قبل المنع كان بالفعل سايب انطباع كويس عن كفاءته!

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

هل هيكون دا التسلسل الطبيعي بعد كدا لكل ال Frontier AI Labs بأنها لازم تعدي علي فقرة مفاوضات مع الحكومة عشان تتأكد من عدم إساءة استخدام النماذج في الهجمات الأمنية؟ دا وارد جدًا لأننا شايفين دلوقتي OpenAI داخلة ب GPT-5.6 Sol في نفس العملية مع اعتراضها الشديد عليها.

الجدير بالذكر إن شركة Anthropic، بالتعاون مع Amazon وMicrosoft وGoogle، بتشتغل على معيار موحّد على مستوى الصناعة لتقييم مدى خطورة محاولات كسر حماية نماذج الذكاء الاصطناعي (AI jailbreaks).

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

اللي يهمنا كمبرمجين

• النموذج أصبح متاح ومستخدمين Claude Code في مجتمعنا العربي كتير فابعتولنا تقييماتكم علي استخدامه وهنضيفها للنشرة باذن الله!

• النموذج بيوفر Context Window بتوصل إلى مليون توكن، ودي ميزة عملية كبيرة في الشغل داخل Codebases كبيرة أو Agentic Tasks طويلة؟

• من الناحية المالية، سعره بالفعل عالي، يأتي Fable 5 بـ 10$/Input و50$/Output ودا ضعف سعر Opus 4.8 وضعف سعر GPT-5.5 تقريبًا على المدخلات بس استخدام ال Prompt Caching و ال Batch API بيقلل التكلفة للنص, على كل حال لازم ناخذ بالنا من الفواتير!

  ---

GLM-5.2 :The Open Source Finally in the Frontier 🔥

شركة Z.ai أطلقت نموذج GLM-5.2، وهو نموذج مفتوح الأوزان بحجم 744B Parameter وبيعتمد على بنية Mixture-of-Experts. النموذج بيدعم ContextWindow لحد مليون token، ومرخّص برخصة MIT.

حاليًا بيُقال إنه أقوى نموذج مفتوح الأوزان في اختبارات الأداء، وبيتفوق على GPT-5.5 في عدد من اختبارات هندسة البرمجيات، مع أسعار API أقل بكتير من النماذج المغلقة أو المملوكة.

لكن لازم نقرأ الأرقام دي بحذر: الـbenchmarks بتوضح اتجاه الأداء، لكنها مش ضمان إن النموذج هيكون الأفضل على مشروعك. التجربة الحقيقية بتعتمد على الـstack، حجم الـrepository، جودة الـtests، طريقة بناء الـagent، والـtools اللي بتسمح له يستخدمها.

التركيز الأساسي في GLM-5.2 هو إنه ينجز مهام هندسة برمجيات فعلية، مش مجرد يولّد snippets أو يشرح كود. المفروض يقدر يفهم المشكلة، يخطط للحل، يعدّل ملفات متعددة، يشغّل أدوات واختبارات، ويراجع النتيجة.

أهم تفاصيل النموذج

• حقق أعلى نتيجة بين النماذج مفتوحة الأوزان على مؤشر Artificial Analysis Intelligence Index.

• بيستخدم رخصة MIT، وده معناه إنك تقدر تستخدمه تجاريًا من غير قيود كبيرة، تستضيفه محليًا، وتعمل له fine-tuning من غير قيود استخدام أو حدود جغرافية. ده بيخليه اختيار مناسب لو عندك متطلبات خصوصية، أو بيانات حساسة، أو عايز تقلل اعتمادك على APIs مغلقة.

• تشغيله محليًا يحتاج على الأقل 256GB RAM للنسخ المضغوطة أو الـquantized، بالإضافة إلى 24GB VRAM لو هتستخدم MoE offloading. فعمليًا النموذج مناسب أكثر لسيرفرات قوية، cloud instances، أو فرق عندها بنية تحتية مخصصة، مش لجهاز مطور عادي.

• حاليًا النموذج لا يدعم الرؤية، يعني لا يقدر يفهم أو يحلل الصور اللي بتبعتهاله بالتالي، لو شغلك بيعتمد على تحليل واجهات من صور، debugging من screenshots، أو multimodal workflows، هتحتاج موديل تاني أو pipeline إضافي.

الفجوة بين النماذج مفتوحة الأوزان والنماذج المملوكة كانت تاريخيًا بتتقاس بالشهور، لكن GLM-5.2 بيشير إن الفجوة في مهام البرمجة ممكن تكون قربت جدًا من الصفر.

النقطة اللي لسه محتاجة تقييم هي كفاءة الـreasoning: النموذج بيستهلك في المتوسط حوالي 43 ألف output token لكل مهمة، وده يقارب 3 أضعاف استهلاك GPT-5.5. عمليًا، ده ممكن يخلي تنفيذ المهام أبطأ وأكثر تكلفة من ناحية وقت المعالجة داخل production pipelines، حتى لو سعر الـAPI نفسه

الكفاءة والتكلفة

رغم إن النموذج مفتوح الأوزان وأسعار الـAPI بتاعته أقل من نماذج مغلقة كتير، فيه نقطة مهمة تخص كفاءة الـreasoning. النموذج بيستخدم في المتوسط حوالي 43 ألف output token لكل مهمة، وده قريب من 3 أضعاف استهلاك GPT-5.5 حسب المقال. عمليًا، ده ممكن يزود وقت تنفيذ المهمة ويأثر على throughput في الـproduction pipelines، حتى لو تكلفة الـtoken نفسها أقل.

بمعنى آخر: سعر الـAPI الأقل مش بالضرورة معناه إن تكلفة المهمة النهائية أقل. لو النموذج بيحتاج tokens أكتر ووقت أطول علشان يوصل لنفس النتيجة، لازم تقارن على أساس تكلفة المهمة الناجحة، مش سعر المليون token فقط.

الخلاصة للمبرمجين

GLM-5.2 بيقرب جدًا من مستوى النماذج المغلقة في مهام البرمجة، مع ميزة كبيرة وهي حرية التشغيل والتعديل تحت رخصة MIT. ده يخليه خيار قوي للفرق اللي عايزة self-hosting، خصوصية أعلى، وتحكم كامل في الـdeployment.

لكن قبل ما تعتمد عليه في الإنتاج، اختبره على مهام من مشروعك: bugs، refactoring، كتابة tests، code review، وتشغيل الـagents داخل الـCI. قارن بينه وبين البدائل في نسبة نجاح الـtests، وقت التنفيذ، عدد الـtokens، وعدد التدخلات البشرية المطلوبة. النموذج الأفضل مش بالضرورة الأعلى في الـbenchmark، لكنه اللي ينجز شغلك بدقة وبأقل تكلفة تشغيل فعلية.

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

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

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

• ال AI في سطور: OpenCode - A Look on the AI Code Agent with 8M Monthly users 🔥

• شروحات رسومية بالورقة والقلم: SLOs Explained 🚀

• أدوات وتقنيات عربية: ApexYard - SDLC-as-code 🧰

هذا الأسبوع في أخبار جديدة احنا مش هنتكلم عنها زي إطلاق Anthropic لـ ClaudeTag وهو ببساطة إضافة claude كزميل عمل Always-on في slack لأنها بالفعل ميزة جديدة هنستني نشوف في الاستخدام عاملة ايه!

هنتكلم المرة دي عن Opencode فيلا بينا!

OpenCode – وكيل البرمجة مفتوح المصدر 🔥

ما هو Opencode ؟

OpenCode هو عبارة عن (AI Coding Agent) مفتوح المصدر، مصمم إنه يساعدك تكتب وتطوّر الكود بيقوم بنفس مهمة Claude Code الفرق إنه مفتوح المصدر وبيتيح لك استخدام 75+ LLM Model من جهات مختلفة بينما كلود بيستخدم فقط Anthropic Models.

بنتكلم عن Opencode ليه هذه النشرة؟

• المشروع بيستخدمه ٨ مليون مبرمج شهريًا وعليه أكثر من 160 ألف نجمة على GitHub وأكثر من حوالي 900 مساهم فدعونا نلقى نظره عن سر تبنيهم واستخدامهم ليه من وسط معركة ال Coding Agents اللي حوالينا!

• المشروع بيقدم أداء كويس فعلاً و مع دا هو مفتوح المصدر، فبيحمي من مشكلة الـ Vendor lock-in

OpenCode بيقدم إيه؟

• تقدر تستخدم نماذج مجانية جاهزة، أو توصل أي موديل AI من أي مزود خدمة, زي Anthropic و OpenAI و Google وغيرهم كتير. وتقدر تعتمد على أكثر من موديل خلال المشروع الواحد فكمثال ممكن تستخدم GPT للكود و Gemini للبحث و Claude للـ Refactoring.

• متاح كتطبيق:

  • Terminal

  • Desktop App لا يزال BETA

  • Extension للـ IDEs المختلفة.

دعم ذكي للـ LSP

ال Language Server Protocol ببساطة بروتوكول بيخلي محرر الكود (VS Code مثلًا) يتواصل مع “سيرفر” فاهم لغة البرمجة علشان يوفر مميزات ذكية أثناء الكتابة زي ال Auto-completion و Go to Definition و ال Error Detection و غيرها

الـ AI لو اعتمد على قراءة الملفات فقط هيكون فهمه محدود, لكن لما OpenCode يوصل للـ LSP بتاع المشروع يقدر يسأل أسئلة زي: مين بيستخدم الكلاس ده؟ إيه نوع المتغير ده؟

ف Opencode بيستخدم ال LSP المناسب مع لغة البرمجة المستخدمة في المشروع و يحمّل تلقائيًا أدوات تحليل الكود المناسبة للمشروع، بحيث ال LLM Model يبقى فاهم هيكل الكود بشكل أدق و يشتغل كأنه مطور فاتح المشروع في VS Code فعلًا، مش مجرد موديل بيقرأ نصوص.

تشغيل أكتر من Agent في نفس الوقت

ممكن تشغّل أكتر من جلسة أو Agent بالتوازي على نفس المشروع علشان تنجز مهام متعددة بشكل أسرع.

فكمثال ممكن تعمل Frontend Agent و Backend Agent و Security Agent و Testing Agent وكلهم يشتغلوا علي المشروع في نفس الوقت!

مشاركة الجلسات

تقدر تشارك لينك لأي Session مع زميل أو فريق العمل للمراجعة أو ال Debugging.

حرية اختيار الموديل

طبعًا حرية اختيار الموديل بتخليك تختبر LLMs مختلفة لمهام مختلفة في الكود و دا بيفرق بالطبع في التكلفة والأداء وبتحمينا من الـ Vendor lock-in وهنا عندنا أكثر من ميزة لأنه:

• بيدعم أكتر من 75 مزود نماذج ذكاء اصطناعي، وكمان بيدعم النماذج المحلية (Local Models)

• بيدعم GitHub Copilot فممكن تسجل دخول بحساب GitHub وتستخدم اشتراك Copilot الحالي بتاعك.

• دعم ChatGPT Plus و Pro فممكن تربط حساب OpenAI وتستفيد من اشتراك ChatGPT Plus أو Pro مباشرة من داخل OpenCode.

ما الفرق بينه وبين Claude Code

الفرق في الأداء بين الاثنين بيأتي من مكانين:

• النموذج المُستخدم

  ودا السبب اللي لاحظ معظم المطورين إنه بيعمل فرق في تجربتهم في الاتنين و بالأخص مع OC استخدامه مع نماذج قوية بيدي بالفعل نتائج قوية.

• ال Harness

  الأداتين ال Harness بتاعهم مختلف وكل لما كان ال Harness أحسن دا بيساعد بشكل كبير في تحسين النتائج و تقليل التكاليف.

شوفنا Feedback من مطورين كثير بيستخدموا الاثنين والتعليقات كلها بتشير إلى إن الأداء متقارب ولكن CC يتفوق ف المهام الأكثر تعقيدًا ولكن OpenCode أكثر مرونة بكثير وبيسمحلك ب customisation عالي. الاختيار بينهم بيعتمد بشكل كبير علي احتياجتك والمقارنة هنا ممكن تساعد لكن شوفنا كذلك كثير من المطورين بيستخدموا الاثنين فلم لا؟! قولونا رأيكم في التعليقات لو استخدمتم الاثنين أو عندكم خبرة مع Opencode ورأيكم عنه.

SLOs Explained 🚀

في أي نظام حقيقي، السؤال مش بيكون: “هل السيستم شغال؟”
لأن غالبًا الإجابة آه… بس السؤال الأهم هو: شغال قد إيه بشكل يعتمد عليه؟

هنا بتيجي فكرة الـ SLO — Service Level Objective.

ما هي الـ SLOs؟ وليه تهمك كمهندس؟

ببساطة، الـ SLO هو هدف واضح للموثوقية.
يعني بدل ما نقول: “عايزين السيستم يبقى stable”، بنقول حاجة قابلة للقياس:

99.9% من طلبات الدفع لازم تنجح خلال آخر 30 يوم.

أو:

95% من صفحات البحث لازم تفتح في أقل من 500ms.

الفكرة هنا إننا بنحوّل الإحساس العام إلى رقم واضح الفريق كله فاهمه.

الـ SLO غالبًا بيتكوّن من 3 حاجات أساسية:

SLI: الحاجة اللي بنقيسها فعلًا، زي نسبة النجاح، latency، أو availability.
Target: الهدف المطلوب، زي 99.9%.
Time Window: الفترة اللي بنقيس عليها، زي أسبوع، شهر، أو آخر 30 يوم.

وفيه مفهوم مهم جدًا اسمه Error Budget.

لو هدفك إن 99.9% من الطلبات تنجح، فده معناه ضمنيًا إنك سامح بـ 0.1% فشل. النسبة الصغيرة دي هي الـ Error Budget: المساحة اللي تقدر “تغلط” فيها من غير ما المستخدمين يتأثروا بشكل كبير.

وده بيخلي القرارات أوضح جدًا.

لو عندك Error Budget كفاية، ممكن تتحرك بسرعة، تعمل releases، وتجرب features جديدة. لكن لو قربت تخلصه، يبقى لازم تهدي شوية وتركّز على إصلاح الاستقرار بدل إضافة حاجات جديدة.

مثال عملي:

تخيل عندك خدمة تسجيل دخول، والـ SLO بتاعها:

99.95% من login requests لازم تنجح خلال 30 يوم.

لو حصلت مشاكل متكررة، بدل ما الفريق يدخل في نقاشات عامة زي: “السيستم بقى وحش؟” أو “المشكلة كبيرة؟”

يبقى عندك رقم واضح يقولك: هل لسه جوه الـ margin والهدف بتاعنا ؟ ولا بدأنا نكسر الوعد اللي بيننا وبين المستخدمين؟

علشان كده الـ SLOs مش مجرد monitoring زيادة ولكن هي طريقة تخلي الفريق يوازن بين حاجتين مهمين جدًا: السرعة و الموثوقية.

وده لأن النظام مش لازم يكون مثالي طول الوقت، بس لازم يكون موثوق للمستخدمين اللي بيعتمدوا عليه.

ApexYard: لما الـ AI يكتب كود — مين بيراجع وراه؟

مع انتشار أدوات زي Claude Code وCursor، بقى سهل جدًا إنك تطلب من الـ AI يبني feature كاملة.
بس المشكلة الحقيقية مش في كتابة الكود… المشكلة في كل الحاجات اللي بتحصل حوالين الكود.

• مين كتب الـ spec؟

• مين راجع القرار التقني؟

• هل فيه tests؟

• هل تغيير قاعدة البيانات له rollback plan؟

• هل الكود جاهز للإطلاق فعلًا؟

هنا بيظهر مشروع ApexYard.

الفكرة ببساطة إنه بيحاول يحوّل عملية تطوير البرمجيات إلى SDLC-as-code: يعني مش مجرد prompts عشوائية للـ AI، لكن workflows واضحة، roles، skills، وguardrails تساعدك تطلع softwares كأن وراك فريق هندسي حقيقي.

المشروع معمول خصوصًا للـ solo founders، أو الفرق الصغيرة، أو أي حد بيستخدم AI agents في بناء منتجات حقيقية، وعايز يقلل مساحة إن “الـ AI كتب حاجة شكلها شغالة بس ناقصها أساسيات هندسية”.

ApexYard بيضيف طبقات زي:

• مراجعة تلقائية للتغييرات

• launch-readiness checks

• workflows للأفكار، الـ specs، القرارات، والـ handover

• guardrails تمنع تغييرات خطيرة من غير plan، خصوصًا في حاجات زي database migrations

• أدوار مختلفة للمراجعة بدل ما يبقى كل شيء “AI واحد بيرد على كل حاجة”

الجزء المهم هنا مش الأداة نفسها بس، لكن الاتجاه اللي بتمثله.

إحنا داخلين مرحلة إن قيمة المهندس مش هتبقى في إنه “يكتب كل سطر كود بإيده”، لكن في إنه يبني نظام حوالين الـ AI:
process واضح، مراجعة حقيقية، حدود أمان، وقرارات موثقة وزي ماتكلمنا قبل كده عن أهمية الـ Harness Engineering.

بمعنى آخر: الـ AI ممكن يسرّع التنفيذ، لكن الهندسة هي اللي بتحدد هل اللي اتبنى ينفع يعيش في production environment ولا لأ.

Try it now

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

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

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

• أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

• ال AI في سطور: WebMCP - W3C Standard for Agents to use Websites 👨‍💻

• شروحات رسومية بالورقة والقلم: Latency vs. Throughput ✍️

• أدوات وتقنيات عربية: DevLite - Developer Utility Hub 🧰

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉
أخر ٣ سنين المجتمع العربي في مجال البرمجيات عامل شغل رائع وبيتطور وبينمو بسرعة كبيرة و المبرمجين بيقدموا سواء بشكل فردي أو في شركات منتجات عظيمة ومفيدة وبيتم تبنيها واستخدامها في الحياة اليومية ولكن!

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

بالفعل ظهرت مبادرات جميلة خلال السنين ولكن مش بتكمل, مجرة المرة دي بتقدم الاستبيان كمبادرة سنوية بإذن الله تساعدنا دايمًا كمبرمجين نفهم المجال كتقنية بيستعمل إيه ورايح فين و كسوق ووظائف وضعه عامل إزاي ورايح فين.

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

شاركوا في بناء الاستبيان

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

WebMCP - W3C Standard for Agents to use Websites

الأسبوع دا لا يوجد أي Models جديدة أو أخبار نازلة علينا بعد سحب Fable 5 و Mythos 5 العالم بيحاول يتعلم الدرس وأنه دايمًا يكون ليه Fallbacks وميعتمدش بشكل مغلق علي AI Vendor واحد. وأظن بشكل فردي كمطورين محتاجين يكون عندنا Fallbacks في حالة الأدوات اللي بنعتمد عليها بشكل يومي حاليًا لم تصبح متاحة غدًا 😅

فحبينا نستغل الفرصة ونتكلم عن ال WebMCP وهو Standard جديد بيخلي المواقع تتعامل مع وكلاء الذكاء الاصطناعي (AI Agents) بشكل مباشر ومنظم، بدل ما الـ AI يحاول يفهم الموقع عن طريق قراءة الـ HTML أو تصوير الشاشة ومحاكاة ضغطات الماوس. الفكرة إن الموقع نفسه بيقول للـ AI: "دي الخدمات اللي أقدر أقدمها، ودي البيانات اللي محتاجها علشان أنفذها."

المشكلة اللي بيحلها

النهارده معظم الـ AI Agents بيتعاملوا مع المواقع بطريقة غير فعالة:

• بيحللوا واجهة المستخدم.

• بيحاولوا يخمنوا وظيفة الأزرار والفورمات.

• أي تغيير بسيط في تصميم الموقع ممكن يبوظ العملية كلها.

• العملية كلها non-deterministic ممكن نفس الAgent ونفس المهمة ويطلعلك نتائج مختلفة.

WebMCP بيحول تفاعل ال Agents مع المواقع من “تخمين” إلى “استدعاء أدوات (Tools) منظمة” بشكل مباشر

بيشتغل إزاي؟

الموقع بيسجل مجموعة من الأدوات أو الوظائف (Tools) داخل المتصفح باستخدام واجهة جديدة اسمها navigator.modelContext.

أمثلة: البحث عن منتج أو إضافة عنصر للسلة أو إرسال نموذج طلب.

بدل ما الـ AI يدور على زر “Search”، يقدر يستدعي أداة اسمها searchProducts مباشرة بالبيانات المطلوبة.

الفرق بين MCP و WebMCP

• MCP التقليدي: شغال على مستوى السيرفرات والـ APIs الخلفية.

• WebMCP: شغال جوه المتصفح نفسه وعلى الموقع مباشرة.

يعني MCP بيربط الـ AI بالأنظمة والخدمات الخلفية، بينما WebMCP بيربطه بواجهة الموقع اللي المستخدم فاتحها بالفعل. الاتنين مكملين لبعض ومش بدائل لبعض.

ليه الموضوع مهم؟

لو WebMCP انتشر:

• الـ AI Agents هتبقى أسرع وأدق.

• استهلاك التوكنز والتكلفة هيقلوا بشكل كبير.

• المواقع هتبقى “AI-ready” من غير الحاجة لبناء API منفصل في كل حالة.

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

  الوضع الحالي للمشروع

  الWebMCP بدأ يظهر في إصدارات تجريبية من متصفح Chrome بدعم من فرق من Google وMicrosoft تحت مظلة W3C. لسه مش معيار نهائي، لكن فيه اهتمام كبير بيه باعتباره خطوة مهمة نحو “الويب المخصص للـ AI Agents.

Latency vs. Throughput

في أنظمة البرمجيات ال Latency و Throughput هما من أهم مقاييس الأداء وغالبًا بنشوفهم جنبًا لجنب في نفس ال Dashboards، لكن كل واحد بيقيس حاجة مختلفة.

1. Latency (زمن الاستجابة)

التعريف: هو الوقت الذي يستغرقه النظام لإنجاز طلب واحد من لحظة إرساله حتى استلام النتيجة.

بمعنى تاني: “هستني قد إيه عشان يجيلي الرد؟”

مثال: إذا أرسلت طلب API الساعة 10:00:00 ووصل الرد الساعة 10:00:00.200 » فالـ Latency = 200 ms

أمثلة على Latency

• وقت تحميل صفحة ويب.

• زمن استجابة قاعدة البيانات لاستعلام معين.

• الوقت بين الضغط على زر وإظهار النتيجة للمستخدم.

كلما كان أقل كان أفضل

2. Throughput (معدل الإنتاجية)

التعريف: هو عدد العمليات أو الطلبات التي يستطيع النظام معالجتها خلال فترة زمنية معينة.

و دايمًا بنسأل: “كم كمية الشغل اللي يقدر النظام ينجزها في وقت معين؟”

مثال: إذا كان السيرفر يعالج: 10,000 Request في الثانية فالـ Throughput = 10,000 Requests/sec

أمثلة على Throughput

• عدد الطلبات في الثانية (RPS).

• عدد الرسائل التي يعالجها Queue في الدقيقة.

• عدد المعاملات البنكية في الثانية.

• عدد الملفات التي تتم معالجتها في الساعة.

كلما كان أعلى كان أفضل

العلاقة بينهما

وفقًا لـ Little’s Law في أنظمة الطوابير:

Latency = Concurrency / Throughput

Continue Reading

DevLite - Developer Utility Hub

كلنا بنحتاج tools تخلصلنا خطوات صغيرة في الشغل JSON Formatter هنا أو Cron Expression Generator أو حتي ID Generator ولكن دايمًا بنكون قلقانين لو بنتعامل مع بيانات مهمة وهنا بتيجي منصة DevLite!

المنصة بتقدم أكثر من 28 أداة مختلفة لكل المهام دي في مكان واحد مغطية أقسام كثيرة والمميز فعلاً:

• إن كل الأدوات دي بتشتغل عندك في المتصفح فمفيش أي remote servers ودا بيضمنلك الخصوصية.

• الأدوات بتشتغل بدون إنترنت.

• والأدوات كلها سريعة الأداء و خفيفة.

• واجهة استخدام سهلة ومنظمة لأن الأدوات بتندرج تحت أقسام أساسية

الأدوات منها

• أدوات للتنسيق JSON & SQL Formatters.

• أدوات لل Generation سواء ID Generators أو بيانات وهمية للاختبارات.

• أدوات لقواعد البيانات و ال Devops

• أدوات Encoders & Decoders مختلفة

وأدوات غيرها كتير متنوعة زي Regex Tester و HTTP / API Request Tester.

الخلاصة: الأداة تستحق إن يتعملها Pin في المتصفح عندك لأي مهمة بسيطة هتزود إنتجايتك وأنت متطمن علي بياناتك!

جرب الأداة الآن

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

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

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

• أول استبيان سنوي يرسم صورة المجتمع التقني 🎉

• Anthropic Launches Claude Fable 5 🔥

• Harness Explained in Agentic AI 🤖

بالتعاون مع مجرّة — أول استبيان سنوي يرسم صورة المجتمع التقني 🎉
أكتر من مرة بتظهر مبادرات جميلة علشان ترسم صورة حقيقية لمجتمع المطورين في العالم ولكنها مش بتكمل ، وحيث إن مجرّة هدفها بناء مجتمع خاص بالمطورين لتبادل المهارات والخبرات وكمان متابعة مستجدات التقنية .. فقرروا يستعينوا بالله ويبدأوا .. ولعلها تكون مبادرة سنوية جميلة!

الاستبيان هيغطي جوانب كتير على سبيل المثال زي:
🔸 الرواتب الحقيقية علشان يبقى فيه صورة سنوية بتوضح ده
🔸 التقنيات اللي بنستخدمها فعلًا في الشغل وبجانب الشغل
🔸 إزاي بنستخدم الـ AI في شغلنا اليومي
🔸 العمل عن بُعد لشركات خارج الوطن العربي
🔸 ومنين بنتعلّم فعلًا وبنتابع المستجدات

بس قبل ما يفتحوا الاستبيان .. عايزين يسمعوا منكم انتوا الأول 👇
الأسئلة بتاعتكم هي اللي هتشكّل النسخة الأولى — اقترحوا، وهم فعلًا هيراجعوها ويضيفوها باذن الله.

شاركوا في بناء الاستبيان

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

Anthropic Launches Claude Fable 5 🔥

الأسبوع ده Anthropic أعلنت عن Claude Fable 5، وده مش مجرد موديل جديد في سباق “مين أعلى Benchmark”. الفكرة هنا أعمق شوية: Anthropic بتقول إن Fable 5 هو أقوى موديل عام عندهم لحد دلوقتي، خصوصًا في الشغل الطويل والمعقد: كتابة كود، migration كبيرة، تحليل مستندات، شغل research، أو حتى tasks محتاجة agent يفضل شغال على مراحل ويختبر نفسه.

بس اللي لافت للنظر مش القوة بس… اللي لافت هو طريقة الإطلاق نفسها.

Fable 5 مبني على نفس الخط بتاع Mythos 5، لكن Mythos متاح لمجموعة صغيرة موثوقة عشان استخدامات حساسة زي cybersecurity وbiology. أما Fable فهو النسخة اللي متاحة للناس والشركات بشكل أوسع، بس مع safeguards. يعني لو الطلب دخل في منطقة Anthropic شايفاها خطيرة، السيستم ممكن يرجّعلك إجابة من Opus 4.8 بدل Fable 5.

وده يخلينا نفكر في حاجة مهمة عن المرحلة اللي داخلين عليها: إحنا مبقيناش بنتكلم بس عن “موديل بيعرف يجاوب أحسن”. إحنا بنتكلم عن موديلات قدرتها بقت عالية لدرجة إن الشركة نفسها محتاجة تحط حدود على استخداماتها.

بالنسبة للمطورين، Fable 5 مهم لأنه بيزق فكرة الـ AI Agent خطوة لقدّام. بدل ما تستخدم الموديل في prompt ورد، أو task صغيرة، Anthropic بتسوقه على إنه يقدر يمسك شغل طويل: يخطط، ينفذ، يراجع، يكتب tests، ويصحح نفسه. وده بالظبط المكان اللي معظم الفرق لسه بتحاول تفهمه: إمتى أثق في agent؟ وإمتى أخليه يشتغل لوحده؟ وإمتى لازم أفضل أنا في النص؟

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

فدلوقتي كل ما الموديلات بقت أقوى، قيمة المطور مش هتبقى في إنه “يكتب الكود بإيده” بس، لكن في إنه يعرف يصمم الـ harness اللي حوالين الموديل: بحيث يحدد له السياق، ويديله constraints واضحة، ويراجعه، ويقيس جودة شغله، ويمنعه من إنه ياخد قرارات غلط بثقة عالية.

والسؤال الحقيقي لينا كمطورين مش: “هل Fable 5 هيكتب كود أحسن مننا؟”

السؤال الأهم مفروض يكون: “هل احنا بنعرف نبني workflow تخلي موديل بالقوة دي يشتغل بأمان وجودة داخل نظام حقيقي؟”

Harness Explained in Agentic AI 🤖

لما بنتكلم عن الـ AI Agents، الفكرة غالبًا بتتباع لنا بشكل بسيط جدًا: ادّي للـ Agent هدف، وهو يخطط، يستخدم الأدوات، ينفّذ، ويرجعلك بالنتيجة.

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

الـ Agent لوحده ممكن يكون “ذكي”، لكنه مش بالضرورة يكون موثوق. وده لإنه ممكن يستخدم أداة غلط، أو ينسى خطوة، أو يكرر نفس العملية أكتر من مرة ويفضل في حلقة لانهائية، أو يطلع نتيجة مش دقيقة، أو ياخد قرار محتاج مراجعة بشرية.

لما بنتكلم عن AI Agent قوي زي Claude Fable 5، السؤال الطبيعي بيبقى:
هل القوة كلها جوه الموديل؟ ولا في النظام اللي حوالين الموديل؟ وهنا بيظهر دور الـ Harness!

الـ Harness هو الطبقة اللي بتتحط حوالين الـ Agent علشان تخليه قابل للاستخدام في نظام حقيقي، مش مجرد Demo لطيف .. تقدر تتخيله كأنه Wrapper حوالين الـ Agent، فهو مش العقل نفسه، ولكنه البيئة اللي بتنظّم شغله، وتحدد له الأدوات، وتتابع حالته، وتراقب نتائجه.

فببساطة هو “الإطار” أو “النظام” اللي بيشغّل الـ Agent ويسيطر على طريقة شغله. مش شرط يكون جزء من الموديل نفسه، لكنه كل حاجة بتخلي الموديل يشتغل في اتجاه واضح بدل ما يفضل مجرد عقل ذكي بيرد على prompts.

ممكن تتخيله زي البيئة اللي بتحاوط موظف جديد في شركة. الموظف ممكن يكون شاطر جدًا، بس من غير access واضح، rules، review process، tools، logs، وحدود صلاحيات… هيغلط، أو هيشتغل بعشوائية، أو ياخد قرارات أكبر من حجمه.

مكونات الـ Harness

1. Instructions و System Prompts
دي القواعد الأساسية: أنت مين؟ شغلك إيه؟ متعملش إيه؟ إمتى تسأل؟ وإمتى ترفض؟

2. Tools
زي إن الـ Agent يعرف يقرأ ملفات، يشغّل tests، يفتح issue، يعمل search، يكتب كود، أو يتعامل مع API. من غير tools، الموديل ذكي بس محبوس في الكلام بس.

3. Memory و Context
الـ Agent محتاج يعرف هو شغال على إيه، المشروع شكله إيه، القرارات القديمة كانت إيه، وإيه اللي اتجرب قبل كده. بس هنا لازم نفرّق بين context مفيد و context زيادة يخليه يتوه ويحصله Hallucination.

4. Permissions و Boundaries
مينفعش كل Agent يبقى معاه كل الصلاحيات. في فرق بين Agent يقترح كود، وAgent يعمل merge، وAgent يعدل production config. كل مستوى بيحتاج حدود واضحة من الصلاحيات.

5. Feedback Loop
الـ Agent لازم يراجع نفسه أو يتراجع من أدوات تانية: tests، linters، static analysis، human review، أو حتى Agent تاني ناقد. من غير feedback loop، احنا هنكون بنثق في أول إجابة بترجعلنا وخلاص.

6. Observability
وده جزء مهم جدًا غالبًا الناس بتنساه .. لازم تعرف الـ Agent عمل إيه، استخدم أنهي tool، قرر بناءً على إيه، فشل فين، وهل النتيجة اتحسنت ولا لأ ، لإن من غير logs وmetrics، مفيش طريقة نعرف هل فعلاً بيساعد ولا بيعمل noise.

والنقطة الجميلة في الموضوع هنا إن الناس مش متفقة 100٪ على ماهية الـ Harness لسه

Continue Reading

Repomix OpenSource - AI Friendly Repos

لو جرّبت قبل كده تدي AI Agent مشروع كامل وتقول له “راجعلي الكود” أو “ساعدني أعمل refactor”، غالبًا هتقابل نفس المشكلة: إزاي أدي للموديل context كبير وكافي من غير ما نفضل ننسخ الملفات يدويًا؟ او من غير ما نضطر كل مرة نحددله الاماكن اللي يشوف فيها الفايلات اللي يقراها ؟ او من غير ما نسيبه يدور بنفسه ويحرق tokens كتير؟

هنا بتيجي أداة اسمها Repomix.

Repomix ببساطة بتاخد الـ repository بتاعك وتحوّله لملف واحد منظم وAI-friendly، تقدر ترفعه أو تبعته لموديلات زي Claude أو ChatGPT أو Gemini عشان يفهموا شكل المشروع بشكل أوسع. الأداة معمولة تحديدًا لسيناريوهات زي code review، refactoring، documentation، أو إنك تطلب من الموديل يفهم architecture المشروع قبل ما يساعدك في تعديل معين.

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

Repomix مثال صغير لكنه مهم على فكرة الـ Harness اللي اتكلمنا عنها فوق ، لأن جزء كبير من نجاح الـ AI في البرمجة مش بس إن الموديل يكون قوي، لكن إنك تعرف تجهز له الـ context الصح بالشكل الصح.

بس برضو لازم ناخد بالنا: مش معنى إنك قدرت تحط المشروع كله في ملف واحد إنك تبعته وخلاص .. لازم تراجع إيه اللي داخل في الملف، وتشيل الـ secrets، والـ keys، وأي معلومات داخلية حساسة وده لإن الـ AI محتاج context، ولكه مش محتاج يعرف كل حاجة.

الخلاصة: Repomix مش أداة “سحرية”، لكنها بتحل مشكلة عملية جدًا “إزاي تدي الموديل context مرتب عن مشروعك” ومع الموديلات الكبيرة والـ Agents، النوع ده من الأدوات هيبقى جزء أساسي من workflow أي مطور.

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

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

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

Join Us

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

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

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

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

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

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

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

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

Write With Us

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

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

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

حكاية 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