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

تذكروا يا أحبتي، فجيعة الأمة بموت النبي محمد ﷺ، فهي أعظم فجيعة وأشد فراق 💔🔥.

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

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

💔🔥

🚨🔥 الصين تدخل سباق وكلاء الأتمتة بقوة!

تم إطلاق وكيل أتمتة لسطح المكتب يعمل 100٪ محليًا بدون إنترنت، بدون سيرفرات، وبدون إرسال بياناتك لأي جهة خارجية. 🤯

اسمه UI-TARS Desktop من ByteDance،
وهو جزء من مشروع Agent TARS مفتوح المصدر بالكامل.

💻 ماذا يمكنه أن يفعل؟

تشغيل أي تطبيق على جهازك

فتح الملفات وإدارتها

تصفح المواقع والتحكم في المتصفح

تنفيذ مهام كاملة باستخدام اللغة الطبيعية

تحكم دقيق بالماوس ولوحة المفاتيح

دعم Windows / macOS / المتصفح

🔐 كل المعالجة تتم محليًا على جهازك.
🧠 مدعوم بنماذج رؤية-لغة للتحكم في الواجهة الرسومية مثل الإنسان.
🌍 المشروع 100٪ Open-Source برخصة Apache 2.0

هذا ليس مجرد بوت
بل وكيل متعدد الوسائط يفهم الشاشة، يرى، وينفذ. 👀⚡

#AI #OpenSource #Automation #UI_TARS #AgentTARS #ذكاء_اصطناعي #تقنية #DesktopAutomation

بمناسبة قدوم شهر رمضان
حبينا ندلع مطورين تطبيقات الموبايل
Flutter+ React native

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

مع محاضرات شرح توضيح لكيفية عمل الإضافات وإستضافتها
الإضافة تحل مشاكل خاصة بمطوري الموبايل

لمزيد من المعلومات
انتقل المستودع
https://github.com/tareq-alomari/scrcpy-smart

Software Engineer
Tareq Al-Omari

🚀 قريبًا:
Scrcpy Smart Connect كإضافة في
Visual Studio Code!

تخيل أن هاتفك يتصل بالكمبيوتر لاسلكيًا وباحترافية مباشرة من داخل محرر الكود
Visual studio code
بدون كابل USB… كل شيء جاهز للتشغيل بسرعة وسهولة. 😎

✨ مميزات النسخة :

🔄 اتصال تلقائي بالهاتف ويحفظ جهازك للمرات القادمة مافيش داعي ربط كل مرة

⚡ سريع ومستقر، بدون تقطع

📸 لقطة شاشة سريعة مباشرة من داخل
Visual Studio Code

🎮 إعدادات جاهزة لألعاب، تسجيل شاشة، عروض تقديمية، وتوفير البطارية

🖥️ إدارة عدة أجهزة وأسماء مخصصة لكل جهاز مع التنقل بين الاجهزة


💡 مثالي لـ:

مطوري Flutter و React Native

مختبري التطبيقات
صناع المحتوى
عشاق الألعاب على الكمبيوتر


🔥 قريبًا على Visual Studio Code Marketplace
يمكنك تحميل الإضافة مباشرة من داخل VS Code بمجرد إطلاقها، وتجربتها بدون أي تعقيد!

📢 الإطلاق سيكون قريبًا عند الإنتهاء من اللمسات الاخيرة، وستتمكنون من التحكم بهواتفكم مباشرة من بيئة التطوير الخاصة بكم.
https://github.com/tareq-alomari/scrcpy-smart

مشروع: منصة “مجلتي” للمجلات الرقمية الفاخرة
MAJALATI – Luxury Digital Magazine System
👑 حول ذكرياتك إلى تجربة رقمية لا تُنسى

لم تعد الذكريات مجرد ملفات PDF تُحفظ في الهاتف…
الآن يمكنك تحويلها إلى مجلة رقمية تفاعلية فاخرة تحاكي تقليب الصفحات الحقيقية، وتُعرض بأسلوب راقٍ يليق بمناسبتك.

🎓 تخرج – 🏆 مؤتمرات – 📸 فعاليات خاصة
كل لحظة تستحق أن تُروى بأسلوب مختلف.

🚀 ماذا تقدم منصة "مجلتي"؟
🎬 نظام تصفح ثلاثي الأبعاد (3D Flipbook)
تجربة تقليب صفحات سينمائية تعتمد على تقنيات WebGL لضمان أداء سلس وسريع حتى على الهواتف.

⚡ تحويل فائق السرعة للصور
تحويل صفحات PDF إلى صور عالية الجودة مع تقليل زمن التحميل واستهلاك البيانات.

☁️ ضغط ذكي للملفات
حفاظ على الجودة + تقليل الحجم + تخزين سحابي فعال.
📱 رمز QR فوري لكل مجلة

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

إمكانية تحميل ملف PDF مباشرة لمن يرغب بالاحتفاظ بالنسخة الكلاسيكية.

💼 خدماتنا
1️⃣ خدمة الرفع فقط
لديك ملف PDF جاهز؟
نحوّله إلى مجلة رقمية فاخرة خلال دقائق.

2️⃣ خدمة التصميم والرفع
نصمم لك مجلة إبداعية من الصفر بأسلوب احترافي يعكس هوية مناسبتك، ثم نطلقها رقمياً مع QR خاص بها.

أول العملاء :
دفعة هندسة مدنية
دفعة هندسة إتصالات

لماذا “مجلتي”؟
✔ تجربة تفاعلية تحاكي المجلات الواقعية
✔ مشاركة سهلة وسريعة عبر QR
✔ هوية فاخرة تناسب المناسبات الراقية
✔ أداء عالي وسرعة تحميل ممتازة
✔ نظام حديث يجمع بين التقنية والجمال

🔥 جاهز لتبهر ضيوفك؟
لا تجعل ذكرياتك مجرد صور…
اجعلها تجربة.

📩 تواصل معنا الآن عبر الأرقام بالموقع
🌐 وتصفح أعمالنا عبر الموقع

برمجة وتصميم المهندسين :
م.عمرو شميس ، م.طارق العُمري


👑 ابدأ رحلة الفخامة الرقمية مع “مجلتي”
https://majalati1.pythonanywhere.com
#مجلتي #ذكريات_رقمية #مجلة_تفاعلية #QR

الإضافة نزلت في
Visual studio code marketplace

شوفوا حملوها من visual studio code وجربوها إذا في أخطاء بلغونا وشكراً لكم
👍

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

يسرّنا أن نهنئكم بحلول هذا الشهر الفضيل، سائلين الله أن يجعله شهر خيرٍ وبركة علينا وعليكم، وأن يعيننا فيه على الصيام والقيام وغضّ البصر وحفظ اللسان، وأن يتقبّل منا ومنكم صالح الأعمال.

نسأل الله أن يكتب لنا فيه أجر الصائمين، وقيام القائمين، وأن يجعلنا فيه من المقبولين، وأن يرزقنا الإخلاص في القول والعمل، وأن يختم لنا الشهر برضوانه والعتق من نيرانه.

🌙 شهر مبارك
✨ وكل عام وأنتم بخير
🤲 تقبّل الله منا ومنكم صالح الأعمال

منشور مهندس مصري عجبني وبيتكلم على دوامة أحنا فيها حالياً 🤣💔 :

وهم الـ Microservices.. أو إزاي تدفن نفسك بدري وأنت لسه بتقول يا هادي!

واحدة من أكبر الكوارث اللي بشوفها بتتكرر بشكل مرعب مع الشباب في أول طريقهم في الـ Software Engineering، إنهم أول ما يخلصوا الـ Syntax بتاع لغة البرمجة ويحفظوا شوية Controllers في Framework معين، بيجيلهم إحساس زائف إنهم بقوا جاهزين يقفزوا فوراً لحاجات تقيلة جداً زي الـ Microservices والـ Kubernetes.

المشكلة هنا مش إن الـ Microservices وحشة.. بالعكس، هي Architectural Style قوي جداً ومفيد في سياقات معينة وللشركات العملاقة، لكن الكارثة بتحصل لما حد لسه مش فاهم يعني إيه Separation of Concerns، ولسه مش قادر يكتب Class واحدة Clean، ويروح فجأة يقرر يقسم السيستم لـ 10 Services وهو أصلًا مش عارف يظبط Service واحدة Monolithic صح.

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

جالي واحد من الشباب المتحمسين جداً، عامل Project تخرج عبارة عن E-commerce App بسيط.
الولد داخل فخور جداً وبيقولي: "يا هندسة أنا مقسم السيستم لـ 5 Microservices: واحدة للـ User، وواحدة للـ Product، وواحدة للـ Order، وواحدة للـ Payment، وواحدة للـ Notification.. ورابط بينهم بـ RabbitMQ ومشغلهم بـ Docker Compose".

قولتله: "الله ينور.. شكلنا عاملين شغل عالي.. طب تعالى نجرب نعمل Order".
عملنا Request.. السيستم ضرب Error 500.
دخلنا نشوف الـ Logs.. قعدنا نص ساعة نلف بين الـ Logs بتاعت الـ Order Service والـ Inventory Service عشان نكتشف إن الـ Network وقعت بينهم في لحظة معينة.

المصيبة الأكبر بانت لما سألته: "طب لو الـ Payment نجح بس الـ Order فشل يتحفظ في الداتا بيز.. هتعمل إيه؟"
سكت وبصلي بذهول وقال: "ما هو أكيد لو ده نجح ده هينجح".
قولتله: "لأ يا قلب الهندسة.. في الـ Distributed Systems مفيش حاجة اسمها (أكيد).. أنت هنا خسرت الـ ACID Properties بتاعة الداتا بيز الواحدة، ودخلت في كابوس الـ Distributed Transactions والـ Eventual Consistency".

الولد اكتشف إنه بنى "وحش" مش عارف يسيطر عليه، وإنه بيقضي 90% من وقته بيصلح Configs للـ Docker والشبكة، و 10% بس بيكتب Business Logic.. وده هو الفخ.

تعالى بقى نتكلم Engineering بجد ونشوف ليه القفزة دي ممكن تدمر مستقبلك لو عملتها بدري:

١- أنت بتبني على رمل (Data Structures & Memory)
كتير من المبتدئين بيعدوا بسرعة على موضوع الـ Data Structures زي الـ Array و الـ List و الـ Map و الـ Set، فاكرينها مجرد "Containers" بنرمي فيها الداتا.. وده قصور شديد في الفهم.
في الـ Distributed Systems، اختيارك للـ Collection الغلط مش مجرد كود بطيء، دي بتكون تكلفة Memory و Performance Cost بتضرب في عدد الـ Services.
لو أنت مش فاهم الفرق بين Mutable و Immutable، ومش مستوعب يعني إيه Reference vs Value، ومش عارف إمتى الداتا بتروح للـ Stack وإمتى بتتحجز في الـ Heap Memory.. يبقى دخولك في Distributed System هو دوامة مالهاش أول من آخر، لأنك مش هتعرف تعمل Debugging لمشاكل الـ Memory Leaks اللي هتحصل.

٢- وهم الكود النضيف (The Clean Code Illusion)
ناس كتير بتفتكر إن الـ Clean Code ده حاجة رفاهية أو مرحلة Advanced.. الحقيقة إن الـ Clean Code هو "ألف باء" Engineering.
لو أنت مش بتعرف تسمي Variables صح، ومش بتعرف تقسم Functions صغيرة بـ Single Responsibility، ومش بتعرف تعمل Project Structure مفهوم.. لما تقسم "العك" ده على 5 سيرفسات، أنت مبقتش بتعمل Microservices، أنت عملت Distributed Big Ball of Mud.
أنت حولت المشكلة من "كود وحش في مكان واحد" لـ "كود وحش متوزع ومربوط ببعضه بشبكة"، وده كابوس لا يمكن صيانته.

٣- تعقيدات أنت في غنى عنها (The Complexity Beast)
الـ Microservices بتحل مشاكل زي الـ Independent Deployment والـ Scalability.. بس في المقابل بتخلق تعقيد مرعب أنت لسه مش قده:
الـ Communication: بدل ما كنت بتنادي Function في الميموري (In-process Call) بتاخد نانو ثانية، بقيت بتعمل Network Call بتاخد مللي ثانية.. عارف يعني إيه Network Latency؟ عارف يعني إيه Request Timeout؟
الـ Consistency: إزاي تضمن إن الداتا مظبوطة في 3 داتا بيز مختلفة في نفس الوقت؟
الـ Observability: لما يحصل Error، هتعرف تجيبه منين وسط مئات الـ Logs المتوزعة؟ هل عندك Infrastructure للـ Tracing؟

عشان كدة نصيحتي ليك واللي دايمًا بقولها للمتدربين عندي:

ابدأ بإتقان اللغة بعمق مرعب الأول.. افهم الـ Type System، افهم الـ Concurrency Basics، افهم الـ Runtime بتاع لغتك شغال إزاي.
اتعلم Clean Code و Refactoring بجد.. طبق مبادئ الـ SOLID في مشروع Monolithic صغير.
اشتغل على Project واحد حقيقي End to End.. فيه Authentication، Authorization، Validation، Logging، واكتبله Tests (سواء Unit أو Integration).

بعد ما تبني System Monolith نضيف، متماسك، وقابل للتطوير.. ساعتها بس اسأل نفسك: هل عندي Bottleneck؟ هل التيم كبر جداً ومحتاجين نتقسم؟
لو الإجابة لأ.. يبقى الـ Microservices مش ليك دلوقتي.

وهنا بيجي دوري في المينتور شيب.. إحنا بنحارب "هوس التريند"..
مش بنخليك تجري ورا الموضة، بنخليك تبني "أساس".. بنعلمك إزاي تعمل Modular Monolith محترم، وإزاي تفصل الـ Domain Logic عن الـ Infrastructure.. لأنك لو بنيت الأساس صح، الانتقال للـ Microservices بعد كدة هيبقى خطوة طبيعية وسهلة، مش قفزة في المجهول.

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

ماذا استفدت من المقال :
هذه كل المصطلحات التقنية والهندسية الواردة في المقال، مرتبة ومنسقة بدون شرح:




أولاً: مفاهيم عامة في هندسة البرمجيات

Software Engineering

Syntax

Framework

Controllers

Architectural Style

Separation of Concerns

Class

Clean Code

Monolithic

Business Logic

Modular Monolith

Domain Logic

Infrastructure

Bottleneck

End to End

Refactoring

SOLID

Type System

Concurrency Basics

Runtime





ثانياً: معمارية الأنظمة

Microservices

Distributed Systems

Distributed Transactions

Eventual Consistency

ACID Properties

Independent Deployment

Scalability

In-process Call

Network Call

Network Latency

Request Timeout

Observability

Tracing

Big Ball of Mud (Distributed Big Ball of Mud)





ثالثاً: أدوات وتقنيات

Kubernetes

Docker

Docker Compose

RabbitMQ





رابعاً: مكونات التطبيقات

Project

E-commerce App

User Service

Product Service

Order Service

Payment Service

Notification Service

Inventory Service

Authentication

Authorization

Validation

Logging

Unit Tests

Integration Tests

Request

Error 500

Logs

Configs

Network




خامساً: هياكل البيانات والذاكرة

Data Structures

Memory

Array

List

Map

Set

Collection

Mutable

Immutable

Reference vs Value

Stack

Heap Memory

Memory Leaks

Performance Cost





سادساً: مفاهيم تنظيم الكود

Variables

Functions

Single Responsibility

Project Structure



يالله روح ابحث ايش معنى كل واحد واين تستخدمه في المشاريع 💔😆

مقال ثاني للمصري :
كتير مننا كـ Software Engineers في بدايتنا بنقع في فخ مثالي جداً ومشهور، فخ "أنا هكتب كود مفيش زيه ومفيش سطرين شبه بعض عندي".. أول ما الـ Developer يشوف سطرين كود متكررين، إيده بتاكله ويجري فوراً يطبق مبدأ الـ DRY (Don't Repeat Yourself) ويعملهم دمج في Function واحدة عشان يحس بالانتصار الهندسي.

بس الحقيقة الصادمة اللي بنكتشفها بعدين بالدموع في الـ Production، إن مش كل كود متكرر تجري تطبق عليه الـ DRY Principle بشكل أعمى.. لأن الـ Duplication أحياناً بيكون أرحم بكتير من إنك تعمل Tight Coupling بين جزئين في السيستم ملهمش أي علاقة منطقية ببعض، ولما تحتاج تعدل Requirement في حتة فيهم تلاقي التانية ضربت منك في صمت.

المقولة دي بتلخص واحدة من أهم وأعمق المشاكل اللي بيقع فيها المبرمجين في الـ Software Design، ومبنية على قاعدة ذهبية للمهندسة Sandi Metz بتقول: "Duplication is far cheaper than the wrong abstraction" بمعنى إن التكرار أرخص وأهون بكتير من الـ Wrong Abstraction.

عشان نفهم المعنى التقني ورا الكلام ده، تعالى نتكلم Engineering بجد ونقسم المشكلة دي لأجزاء عشان نستوعب الكارثة اللي بتحصل Under the hood:

١- التكرار بالصدفة (Coincidental Duplication)
مش كل كودين شكلهم متطابق يبقوا بيعملوا نفس الحاجة أو ليهم نفس الهدف في الـ Business Logic.. أحياناً الكود بيكون متطابق "بالصدفة" في اللحظة الزمنية دي بس. لو اتسرعت وعملت ليهم دمج في Shared Function، أنت كدة ربطت مسارين ملهمش علاقة ببعض لمجرد إن الـ Syntax الحالي واحد. هنا أنت معملتش DRY لمفاهيم أو Knowledge، أنت عملت DRY لسطور كود، وده فخ مرعب اسمه Temporal Coupling.

٢- كابوس الاعتمادية (Tight Coupling)
لما تجمع الكودين دول في مكان واحد لمجرد التشابه الشكلي، أنت خلقت رابط قوي جداً بينهم.. لو جزء في السيستم طلب تعديل في الـ Shared Function دي عشان يناسب Business Requirement جديد، التعديل ده هيسمع فوراً في الجزء التاني اللي بيستخدم نفس الـ Function، وممكن يبوظه بالكامل لأن الجزء التاني مكنش متوقع ولا محتاج التعديل ده أصلاً.

٣- ولادة الوحش (The Wrong Abstraction)
لما تكتشف إن الـ Function الواحدة مبقتش نافعة للطرفين بنفس الشكل، هتبدأ "ترقع".. هتبدأ تبعت Parameters زيادة، وتحط Boolean Flags زي isUser أو isAdmin، وتعمل Nested if/else conditions جوه الـ Function عشان تفصل بين الحالتين.. مع الوقت الـ Function دي هتكبر وهتتحول لـ God Function معقدة جداً بتكسر مبدأ الـ Single Responsibility Principle، وأي محاولة للـ Debugging فيها هتبقى عبارة عن Cognitive Load رهيب على دماغ أي حد بيقرأها، وهتلاقي نفسك بتعمل Shotgun Surgery مع كل تعديل بسيط.

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

كنا بنعمل Code Review لـ Task في Project التجارة الإلكترونية بتاعه، وكان بيحسب ضريبة المبيعات.. هو لقى إن الـ Function اللي بتحسب الضريبة للمنتجات العادية، والـ Function بتاعة الخدمات، الاتنين بيضربوا السعر في 10%، فالكود متكرر بالمللي.. فقام مطبق الـ DRY وعمل Shared Function واحدة اسمها calculateTax.

السيشن اللي بعدها، اديتله Business Requirement جديد: "الضريبة على الخدمات بقت 15%، والمنتجات فضل عليها 10% بس ضفنا رسوم شحن للمنتجات اللي سعرها فوق رقم معين".

هنا الولد دخل يعدل في الـ Shared Function، وزود isService flag، وبعدين زود requiresShipping، وعمل شروط متداخلة جوه نفس الـ Function.. النتيجة؟ الكود بقى Spaghetti، ولما حب يعدل حسبة الخدمات، بقى مرعوب إنه يـ Break حسبة المنتجات.. هنا الـ Wrong Abstraction خلى الـ Maintenance بتاع الكود أصعب 100 مرة من لو كان ساب 2 Independent Functions كل واحدة بتعبر عن الـ Context بتاعها بوضوح.

في الـ Software Engineering عندنا Best Practice ممتازة اسمها Rule of Three.. لو الكود اتكرر مرتين، استنى وماتعملش حاجة وسيبه متكرر.. لو اتكرر تلات مرات بنفس الشكل ونفس المعنى، ساعتها بس ابدأ فكر تعمل Abstraction.. لأن المرة التالتة بتأكدلك إن ده Pattern حقيقي في الـ Domain مش مجرد صدفة مؤقتة.

وهنا بيجي دوري كمنتور.. لما بلاقي حد من الشباب بيعمل Pull Request وكل همه إنه يقلل عدد السطور لمجرد التقليل وإرضاء الـ IDE، بوقفه فوراً.. إحنا بنركز إننا نبني عقلية Software Engineer بيحلل الـ Context مش مجرد Coder بينفذ قواعد محفوظة.
بخليه يشوف بعينه إزاي التراجع عن الـ Wrong Abstraction وفك الـ Coupling بياخد مجهود خرافي مقارنة بدمج الكود المتكرر، وبفهمه إن الـ Readable Code المستقل أهم مليون مرة من إنك توفر كام سطر كود وتدفع تمنهم Technical Debt يخلي المشروع Unmaintainable.