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

الكل سمع بـ Notion واعتقد ان البعض يستخدمه

فيديو رائع يشرح لك طريقه عمل البرنامج وكيف يتعامل مع DB واشياء كثيرة... يستحق المشاهده:
http://youtube.com/watch?v=NwZ26lxl8wU

الصدق شكرا لـ Lewis ومحتواه التعليمي رائع جداً واحترافي.. ينصح بمتابعه حساباته في السوشل ميديا

(بلهجة أستاذ جامعي مهمل وخيبان)

"شوفوا يا شباب، المادة هذه مش تخصصي، لكن الجامعة فجأة كلفتني إني أدرسها، وأنا ما كان عندي وقت أحضّر كويس... بس خلاص، ركزوا معايا، بنبدأ بالجداول، أهم شي تفهموا كيف تسووا CREATE TABLE و SELECT * FROM، والباقي ما هو مهم كثير، أهم حاجة تحلّوا الأسئلة في الامتحان زي ما هي في الكتاب!"

(بعد مرور شهرين)
"طيب يا شباب، الحين خلاص تعلمتوا الجداول والاستعلامات، باقي المنهج طويل بس ما عندنا وقت، فبنختصر ونمشي بسرعة... اللي يذاكر الكتاب بينجح، واللي يسأل أسئلة كثيرة ما عندي له إجابة، أنا هنا بس عشان أخلص المنهج وأروح!"

(في آخر المحاضرة قبل الامتحان)
"امتحانكم كله من اللي كتبناه في السبورة، لا تسألوني ليش المادة مملة، أنا كمان طفشان زيكم!"

ما عاد بش داعي لكتابة الـ Jobs بملفات وفولدرات والتعب حق التنقل بينها!
الآن تقدر تكتب الـ Jobs داخل الكود نفسه، جوه المكان اللي تحتاجه بالضبط، بدون ما تضطر تكتب كلاس مستقل أو ترث من IJob.
والأحلى من كذا، الكود ينحفظ في قاعدة البيانات، ولما تحتاجه يشتغل مباشرة من الذاكرة!
استخدم أي Func أو Delegate أو حتى استدعي أي ميثود من أي Service بسهولة.
الكود يكون مرتب أكثر بدون ما تتعبك الملفات والفولدرات.
تنفيذ سريع وذكي عبر Proxy مخصص.
قد عرفت ليش معظم مكتبات الـ Job Scheduling تتهرب من تخزين الـ Delegates في قاعدة البيانات؟
لأنها تواجه مشاكل في الـ Dependency Injection واستعادة السياق عند التنفيذ، لكن مع Quartz.Extend، الوضع مختلف تمامًا!
✨ قريبًا... Quartz.Extend Package!
#DotNet #QuartzScheduler #BackgroundJobs #CleanCode

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

تحسين أداء API باستخدام Data Shaping في ASP.NET Core
عملت أمس على تحسين أداء الـ API باستخدام Data Shaping، دون الحاجة إلى GraphQL، مما يتيح للمستهلك تحديد البيانات التي يريدها فقط بدلاً من استرجاع جميع الحقول في كل طلب.
الهدف من هذا التحسين هو تقليل حجم البيانات المسترجعة، مما يحسن سرعة الاستجابة، يقلل استهلاك الموارد، ويساعد على بناء API أكثر كفاءة. الآن، يمكن لأي طلب تحديد الحقول المطلوبة من خلال Query Parameters، مما يجعل الـ API أكثر مرونة دون الحاجة إلى تغيير الهيكلة أو استخدام تقنيات إضافية.
بهذه الطريقة، تمكنت من تحقيق تحسين ملحوظ في الأداء مع الحفاظ على البساطة وسهولة الاستخدام!

تبسيط تجربة العميل باستخدام HATEOAS في RESTful API
أمس عملت على تحسين الـ API باستخدام HATEOAS، وهو مبدأ يجعل الـ API أكثر ذكاءً وسهولة في الاستخدام من قبل العميل. الفكرة ببساطة هي أن كل استجابة لا تكتفي بإرجاع البيانات فقط، بل تضيف روابط (Hyperlinks) تساعد العميل على معرفة العمليات المتاحة دون الحاجة إلى معرفة مسارات الـ API مسبقًا.
هذا التحسين جعل الـ API أكثر ديناميكية ومرونة، حيث يمكن للعميل التنقل بين الموارد بسهولة دون الحاجة إلى الاعتماد على توثيق خارجي. النتيجة؟ تجربة استخدام أسهل، أخطاء أقل، وتفاعل أكثر ذكاءً بين العميل والخادم! 🚀

🛑نتائج نهاية العام 🛑







أكيد قد سمعت كثير عن End-to-End Encryption واللي أغلب تطبيقات المحادثة الخاصة مثل واتساب سيجنال وتيليجرام يذكروا أنها واحدة من أهم وسائل حماية خصوصية المحادثات بين طرفين💁‍♂️
طيب ايش المقصود بها بالضبط🙆؟
بكل بساطة 😊 هي تقنية تشفير تضمن أن بس الشخصين اللي بيتواصلوا يقدروا يقرؤوا الرسائل ولا أحد ثاني حتى الشركة المطورة للتطبيق نفسها لا الهاكرز ولا الحكومات ولا حتى السيرفرات اللي تمر منها البيانات يقدروا يفكوا التشفير نظريًا وبتعرف ليش بعد شويه.
كيف يتم هذا الشيء؟
الموضوع يعتمد على التشفير غير المتماثل واللي يستخدم زوج من المفاتيح لكل شخص.
المفتاح العام Public Key يستخدم لتشفير البيانات. المفتاح الخاص Private Key يستخدم لفك التشفير.
لما تبدأ محادثة مع شخص كل طرف يولد مفتاحين وبعدها يتم تبادل المفاتيح العامة بحيث كل شخص عنده المفتاح العام للطرف الثاني.
لما تكتب رسالة التطبيق يقوم بتشفيرها باستخدام المفتاح العام للمستلم ولما توصل يقدر يفك تشفيرها باستخدام المفتاح الخاص حقه وهذا يضمن أن ما حد غيره يقدر يفهم محتوى الرسالة حتى لو تم اعتراضها.
الآن السؤال اللي ممكن يجي في بالك طيب كيف نقدر نشوف المحادثات القديمة هل معناه أن المفاتيح محفوظة في مكان معين؟
بالضبط المفاتيح لازم تكون مخزنة بطريقة ما حتى تقدر ترجع للدردشات السابقة بعض التطبيقات مثل واتساب تخزنها محليًا على جهازك بينما بعض التطبيقات الأخرى تخزنها على سيرفرات الشركة وهنا تبدأ الخطورة لأنه إذا السيرفرات ما كانت مؤمنة بشكل قوي فيه احتمال نظري أن الشركة أو أي جهة تقدر توصل للمحادثات لو حصلوا على المفاتيح.
مع ذلك بعض التطبيقات تضيف طبقات أمان إضافية مثل تشفير المفاتيح نفسها بكلمة سر رئيسية بحيث حتى لو أحد حصل عليها ما يقدر يستخدمها بدون معرفة كلمة السر.
في النهاية End-to-End Encryption تقنية قوية جدًا لكنها تعتمد على طريقة التنفيذ ولو ما تم تطبيقها بشكل صحيح تظل فيه ثغرات ممكن تستغل 🙂.
فكرة Key pair منتشرة جدًا خاصة فى برامج الإتصال بالخوادم ssh servers .
وفي النهاية قد لاتكون هي الحلول المثاليه وقد تخترق لكنها عقدت عملية الاختراق على الهاكرز والله المستعان.

#أنا_وأنت_والISP_ثالثنا 📶👀

المبرمجين مستمرين

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

الوضع الحالي

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

الفريق هذا مش عبيط ولا متشائم الفريق هذا شايف وظائف ثانية تم استبدالها فليش ما نستبدل إحنا كذلك؟ اللي يمنع لحد الآن إن السوفتوير مش مجرد كود نكتبه ونطلع release لا السوفتوير عملية لا نهائية ولا في مشروع سوفتوير يخلص دايمًا محتاج صيانة وتطوير. ومهما كانت قوة أدوات الـ AI لها حد وما بتسد في كل شيء ولو حتى أصبحت جامدة بيكون في شخص مسؤول عنها يشغلها.

الفريق الثاني

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

رأيي؟

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

هل يساعدنا؟ أكيد ومش بننكر إن له تطبيقات تفيد البشرية أنا شخصيًا أستخدم أكثر من أداة بشكل يومي وطريقة شغلي تتغير وحدة وحدة. لكن مش أستخدمه علشان اللي يعتمد عليه يكون أحسن مني لا مستحيل. ولا ألف شخص من الجيل الجديد اللي يعتمد على AI tools بيكونوا أفضل من شخص قديم فاهم الأساسيات.
الجيل الجديد من المبرمجين؟ سيكون جيل بدون تفكير جيل مجرد منفذ والمجال هذا قائم على التفكير وأي حد يحب البرمجة يحبها علشان التفكير اللي فيها.

هل الأدوات هذه بتساعد المبرمج يركز على الـ architecture؟

لا ولا بتساعده يركز على أي شيء نفس الأدوات هذه تفكر بالـ architecture بنفسها.

المبرمج بيظل موجود لكن المبرمج الحديث ما بيكون مركز على شيء مجرد يلحق ورا الـ AI بيكون صبي عند الـ AI وهو اللي عمل بنفسه هكذا.

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

المستقبل؟

بعد فترة طويلة كثير من السوفتوير بيكون معتمد على الـ AI في كتابته والمنتجات بتكون مليانة مشاكل أكثر من اليوم والمشاكل هذه بتكون integration issues معقدة توقف أنت والـ AI تناظروا بعض وما تعرفوا إيش الحل.

الـ AI بيحل مشاكل؟ نعم جربته في أكثر من مشكلة وكان يعطي سببها لكن له حد ولو وقعت في مشكلة معقدة ما بيسد معك.
طيب ما هو بيتطور؟
نعم بيتطور بس المشاكل تتعقد أكثر ونظل ندور بنفس الدائرة لحد ما السوق يقرر شيء من اثنين:

نستخدم الأدوات بعقل والهدف يكون تقليل وقت العمل مش تقليل عدد الفريق إلى شخص واحد. نتقبل الجودة المنخفضة للسوفتوير كأمر واقع مثل ما إحنا متقبلينها من قبل الـ AI. الحل النهائي؟
إما يكون في building blocks جاهزة لكل شيء، بحيث تقدر تبني تطبيق مثل Uber بسهولة بقطع جاهزة تربطها ببعض مثل WordPress بس على مستوى أكبر.

وقتها المبرمجين بينقسموا لنوعين:

مبرمجين فاهمين كل شيء كويس وهؤلاء اللي بيكتبوا building blocks. مبرمجين فاهمين حاجات سطحية وهؤلاء اللي يستخدموا blocks لبناء التطبيقات.
أي احتمال بيكون الأقوى؟ الله أعلم لهذا بتوقف هنا وأكتفي بالمشاهدة.


#المبرمج_بين_AI_والبقاء_وأنت_حر

رأيت في الصعاب فرص للنجاح و لم ترهبني مهما عظم أمرها و حدها "القسمة المطولة " كانت و لا تزال كابوس مظلم

عيدكم مبارك وكل عام وأنتم بألف خير 🤍🤍

الحمد للّه الذي أعاننا على هذا الشهر الفضيل وعلى أتمامه بمايرضيه عنا

واسأل اللّه القادر أن أراكم جميعاً في رمضان القادم مبرمجين ومهندسين في أعظم الشركات العالمية🔥🔥

افترض أنني أقوم بسحب مبلغ من حسابي البنكي، وفي نفس اللحظة هناك شخص آخر يقوم أيضًا بسحب مبلغ من نفس الحساب. على سبيل المثال، لدي في حسابي 6000 ريال يمني، قمت بالاستعلام عن رصيدي، فظهر لي 6000 ريال، ثم قمت بسحب 1000 ريال، فقام النظام بخصم المبلغ (account.amount -= 1000) وتحديث البيانات في قاعدة البيانات.
لكن الشخص الآخر استعلم عن رصيدي في نفس اللحظة قبل أن أقوم بالسحب، فظهر له أيضًا 6000 ريال. بعد ذلك، قام بسحب 2000 ريال، فقام النظام بتحديث الحساب وخصم 2000 ريال، مما جعله 4000 ريال في قاعدة البيانات. وهنا تكمن المشكلة!
المشكلة ليست فقط في استخدام Transaction كما قد يظن البعض، بل في كيفية التعامل مع البيانات المتزامنة التي يتم تعديلها من أكثر من عملية في نفس الوقت.

مثال آخر

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

المشكلة والحل

هذه إحدى المشاكل التي لا ينتبه لها الكثيرون، ولا تُكتشف إلا بعد تشغيل النظام لفترة طويلة. والسبب أن كل Request يتم تنفيذه باستخدام DbContext جديد لكل مستخدم، مما يعني أن كل شخص يحصل على نسخة مستقلة من البيانات لحظة تنفيذ العملية، دون معرفة ما إذا كانت البيانات قد تغيرت لاحقًا قبل تحديثها.
ملاحظة مهمة:
لا تقل لي "اجعل DbContext Singleton"، فهذا حل خاطئ تمامًا وسيؤدي إلى مشاكل أكبر. العامل المشترك بيني وبين المستخدم الآخر هو قاعدة البيانات فقط، لذلك الحل يكمن في:

استخدام قفل السجلات (Locking): مثل SELECT ... FOR UPDATE عند تنفيذ العمليات الحساسة.

استخدام آلية التحكم في التواقيت (Timestamps): بحيث يتم التحقق مما إذا كانت البيانات قد تغيرت منذ آخر استعلام.

التحقق من البيانات قبل التحديث: وعدم الاعتماد على القيم القديمة التي تم جلبها في بداية العملية.

معلومة إضافية

DbContext هو الطبقة التي تتواصل مع قاعدة البيانات، وكان يتم إنشاؤها سابقًا يدويًا باستخدام ADO.NET ضمن Data Access Layer. سواء كنت تعمل في .NET أو أي إطار عمل آخر يستخدم ORM، فالمشكلة نفسها ستحدث إذا لم يتم التعامل مع تحديث البيانات المتزامنة بشكل صحيح.

عيدكم مبارك وكل عام وأنتم بخير!

#Concurrency_Master
#system_Issues

السلام عليكم ي شباب 👋،
اصحاب التطبيقات المرفوعة في ال stores. في حاجه ضخمه لتوفير الوقت الذي تاخذه عشان التحديث. يعني بدل ما تعمل build و bundling ك apk و رفعه على ال store و تنتظر لصاحب ال store انه يراجع التحديثات الذي فعلتهم. في tool اسمها Shorebird Code Push. يعني الان تعرف تحدث تطبيقك بدون ما تعيد نشرة(رفعة) على ال store.

رابط الفيديو يشرح هذا الشيء كامل 👍

https://youtu.be/LX65WcrwtQc

تقبل الله منا ومنكم صالح الأعمال وكل عام وانتم بخير و بصحة وسلامة اعزائى 🤍.

إلى كل UI/UX Designer وأي واحد يشتغل في المجال السوفتوير...
الـ AI مش جاي ياخذ مكانك، الـ AI جاي يفضحك! أيوه والله، الـ AI بيورّي الناس كلها إن أي حد يقدر يسوي اللي تسويه إذا كان شغلك بس تنفيذ وأدوات.
يعني لما تجي تصمّم لعيادة أسنان، مش تفكر كيف تخلي شكل السِنة حلو وبس، لا، تفكر في إحساس الشخص اللي خايف يروح للدكتور، تفكر كيف تطمّنه من أول ما يشوف التصميم.
شغلتك مش صورة وبس، شغلتك توصّل إحساس! تحرّك قرار، مش مجرد شكل. وهذا شيء الـ AI ما يقدر عليه.
الشطارة اليوم مش إنك تعرف تستخدم الأدوات! الشطارة إنك تكون مفكّر بصري، تفهم كيف تحل مشاكل حقيقية في السوق، تكون فاهم سيكولوجية المستخدم، تكون دارس تسويق، تقرأ، تسأل، تفكّر، تجرّب، تغلط، وتقوم تشتغل من جديد.
اللي الـ AI مستحيل يسويه هو طريقة تفكيرك… كيف تفكّك المشكلة؟ كيف تربط بين فكرة العميل واحتياج الناس؟ كيف تعرف متى تستخدم الأحمر… ومتى لا؟ كيف تخلي تجربة المستخدم سلسة من أول ما يشوف التصميم لحد ما يضغط على الزرار؟
هذا شغلك، وهذا الفرق بينك وبين AI.
#التصميم_مش_أدوات #فكر_قبل_ما_تصمّم #AI_مايقدر_يفكر_مكانك

https://www.shadcn-vue.com/

من أعظم مكاتب ui component على الاطلاق....
الاصل رياكت... وهذا الرابط مشروع port منه خاص بـ vue
وموجود لـ angular طبعاً وفي كثير...

اذا مافي port للفريمورك الي تشتغل عليه هذه فرصه رهيبه تسوي انت المشروع وتشاركه open source
بيكون شي قوي في cv

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

ما هي الـ Anti-Patterns؟ 🤔

الـ Anti-Patterns هي الممارسات السيئة في التصميم أو التطوير التي تبدو في البداية كحلول جيدة، لكنها تؤدي إلى مشاكل معقدة مع مرور الوقت. هي عكس الـ Design Patterns التي تساعد على تحسين جودة الكود.

أشهر أنواع الـ Anti-Patterns:

1️⃣ Spaghetti Code 🍝

كود متداخل ومعقد، بدون تنظيم واضح أو طبقات.

من الصعب قراءته أو صيانته، وكل تعديل قد يسبب مشاكل غير متوقعة.

يحدث غالبًا بسبب غياب التصميم الجيد من البداية.

2️⃣ God Object / Big Ball of Mud 🏀

كائن أو فئة تحتوي على وظائف أكثر من اللازم وتتحكم في كل شيء.

يجعل الكود غير مرن، وكل تعديل قد يؤثر على أجزاء متعددة.

3️⃣ Hard Coding 🔢

وضع القيم مباشرة داخل الكود بدلًا من استخدام إعدادات قابلة للتغيير.

مثل كتابة "localhost:1433" داخل الكود بدلًا من قراءته من ملف إعدادات.

4️⃣ Magic Numbers and Strings 🎩

استخدام أرقام أو نصوص بدون تفسير، مما يجعل الكود غير مفهوم.

الحل: استبدالها بالثوابت (const) أو القيم المعرفّة (enum).

5️⃣ Copy-Paste Programming 📄📄

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

يؤدي إلى صعوبة في الصيانة، حيث يجب تعديل كل نسخة يدويًا.

6️⃣ Singleton Overuse 🏛

استخدام Singleton في كل مكان، مما يجعل الكود معتمدًا على حالة واحدة يصعب التحكم بها.

الحل: استخدم Dependency Injection بدلًا من ذلك.

7️⃣ Lava Flow 🌋

كود غير مستخدم أو موروث من مراحل تطوير سابقة لكنه لا يزال موجودًا بدون داعٍ.

يزيد تعقيد المشروع، ويجعل التعديلات أكثر خطورة.

8️⃣ Golden Hammer 🔨

محاولة استخدام نفس الأداة لحل كل مشكلة، مثل استخدام Design Pattern معين في كل موقف حتى لو لم يكن مناسبًا.

كيف تتجنب الـ Anti-Patterns؟

✅ استخدم مبادئ SOLID لتصميم الكود.
✅ ركّز على نظافة الكود بدلًا من الحلول السريعة.
✅ قم بالمراجعة الدورية للكود (Code Reviews).
✅ تعلم متى ولماذا تستخدم كل نمط تصميم، وليس فقط كيف تطبقه.
النتيجة؟ لا تقع في فخ الـ Anti-Patterns، فمعظمها يبدأ كحل سريع لكنه ينتهي بكود كارثي على المدى الطويل! 🚀