هل تدري إن الجذور الحقيقية لشركة DeepSeek بدأت في وقت الأزمة الاقتصادية العالمية في سنة 2007؟

في ذاك الوقت كان هناك 3 مهندسين صينيين يدرسون في جامعة حكومية في الصين اسمها Zhejiang University.

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

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

وفعلاً هؤلاء المهندسين اشتغلوا على فكرتهم، وسووا أبحاث عميقة في هذا المجال، وفي سنة 2015 أسسوا شركة في الصين اسمها High-Flyer وكان هدفها استخدام الكمبيوتر وalgorithmic trading حتى يساعدوا الناس يشتروا ويبيعوا أسهم في البورصة ويكسبوا.

وبعد سنة 2016 و 2017، بدأت الشركة تستخدم تعلم الآلة (Machine Learning) و الذكاء الصناعي (AI) حتى تاخذ قرارات البيع والشراء واختيار الأسهم.

وفي سنة 2019 أسسوا High-Flyer AI وكان هدفها عمل أبحاث في مجال الذكاء الصناعي.

وفي سنة 2020 بنوا Supercomputer بهدف استخدام Deep Learning، وهو أسلوب متطور من الذكاء الصناعي، واتكلف بناؤه وقتها 200 مليون يوان.

وفي 2021 بنوا Supercomputer جديد متطور تكلف مليار يوان وكان يحتوي على 10 آلاف معالج من فئة Nvidia A100 GPUs.

وفي إبريل 2023، أعلنت شركة High-Flyer عن إنشاء فريق بحثي جديد يهدف للوصول إلى الذكاء الصناعي بالمستوى البشري (AGI)، وقالوا إنه مش بيكون هدفه شراء وبيع أسهم في البورصة، وسموا هذا الكيان بـ DeepSeek.

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

مافيش شيء يجي بالساهل.

اعمل شير حتى نكسر الجهل والأوهام.

الحمد لله.
#للمعرفة

الاختبارات النهائية قبل رمضان 🚦🔭






هناك مثل أجنبي يقول: "إذا كانت الأداة التي في يدك مطرقة، فسترى كل شيء مسامير!"

لكن هنا الفكرة ليست في أن ترى كل شيء مطرقة! لا تتعامل مع الـDesign Patterns كأنها مطرقة، ولا مع المشاكل البرمجية كأنها مسامير! 🌟

أفضل الممارسات تكون فعلاً الأفضل في سياق معين، ولكنها ليست كذلك في كل وقت ومكان! إذا استخدمتها في سياق آخر، قد تصبح جيدة، أو سيئة، أو حتى أسوأ ممارسات! 😅

كما قال الشاعر أبو الطيب المتنبي: "ووضع الندى في موضع السيف بالعُلا... مُضِرٌ، كوضع السيف في موضع الندى!" الندى يشير إلى العطاء، والسيف إلى الشدة. وهذا يعني أن لكل مقام مقال!

💡 إذا كان لديك if condition يتيمة، لماذا تعقد الأمور وتستخدم Strategy Pattern؟ فقط دعها كما هي، ولا تضيع الوقت في تعقيد الأشياء! 😌

إذا كنت قد خرجت جزءًا من المنطق في Method داخل الـclass، لماذا تعذب نفسك وتفصل هذه الـmethod في Class مستقلة ثم تضيف لها Interface وFactory**، وكأنك تسعى إلى أن تكون متميزًا؟! وأخيرًا، تبدأ بتقسيم الinterface إلى عدة Interfaces وفقًا لمفهوم Interface Segregation؟! 😜

هل من الممكن أن يتغير الـClass هذا يومًا ما دون الحاجة لتغيير الكود في الكلاسات الأخرى؟!

هل Interface Segregation فعلاً ضروري في هذه الحالة؟ 🤔

لماذا تعذب أخاك المبرمج الذي سيعمل على الكود بعدك؟! 🥲

👀 لماذا تصنع Interfaces لكلاسات ليس لها سوى تنفيذ واحد؟! وكأنك تريد أن تكون West Coast Gangster! نحن جميعًا نعلم أنه ربما لن تكتب unit tests، على الأقل اجعل الأمور أبسط!

ما الحل؟ 🤔 لماذا تعقد الأمور وتفكر في المستقبل البعيد، بينما النظام نفسه يظل خدمًا لـ ٥٠ أو ١٠٠ مستخدم، يقدم ٣٠ طلبًا في الشهر؟! النظام ببساطة يقوم بعمليات CRUD، وبالتالي لا حاجة لتلك التعقيدات! لماذا تضيع وقتك في تعقيد الأمور؟

🌟 الرسالة: ليس المقصد هنا أن تكتب dirty code أو تهمل جودة الشيفرة! لا، بل عليك أن تركز على كتابة حلول جيدة كفاية، تؤدي الغرض بكفاءة ووضوح، دون تعقيد أو over engineering!


📝 ملاحظة أخيرة، لا تظنوا أنني أنتقد بالعكس.

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

الجميع يستخدم لكن لا يسأل كيف؟ هل تعلم إن أول مجرد انك تتصل بالإنترنت أول إشعارات توصلك هي من التليجرام أنا منذهل جدا من قوة نظام الرسائل عندهم أسرع من باقي التطبيقات، تيليجرام يستخدم عدة آليات وخوارزميات لمعرفة عدد المستخدمين الذين قرأوا الرسالة، خاصة في المجموعات والقنوات، وأبرزها: 1. آلية قراءة الرسائل في الدردشات الفردية في المحادثات الخاصة (1:1)، عند إرسال رسالة، يظهر: علامة واحدة (✓): تعني أن الرسالة وصلت إلى جهاز المستلم. علامتان (✓✓): تعني أن المستلم فتح التطبيق وقرأ الرسالة. تيليجرام يحدد ذلك عبر آلية تأكيد القراءة، حيث يرسل التطبيق عند فتح الرسالة إشعارًا (Acknowledgment) إلى خوادم تيليجرام بأن المستخدم شاهدها. 2. آلية قراءة الرسائل في المجموعات في المجموعات الصغيرة، يمكن الضغط على الرسالة لمعرفة من قرأها. في المجموعات الكبيرة، تيليجرام لا يعرض من قرأ الرسالة ولكنه يحتفظ بمؤشر زمني يحدد آخر مرة كان فيها المستخدم نشطًا، مما يمكن استخدامه لتقدير عدد الأشخاص الذين قرأوها. الآلية هنا تعتمد على التخزين المؤقت (Cache) وتحليل بيانات التفاعل، حيث يتم تحديث حالة الرسالة بناءً على نشاط المستخدمين. 3. آلية قراءة الرسائل في القنوات في القنوات، يظهر عدد المشاهدات بجانب كل رسالة، ولكن هذا الرقم لا يمثل المستخدمين الفريدين فقط، بل يشمل: عدد المرات التي تم فيها عرض الرسالة (حتى لو كان من نفس المستخدم). إعادة التوجيهات (Forwarding) تُحتسب أيضًا كمشاهدات جديدة. تيليجرام يستخدم آلية تعقب على مستوى الخادم تقوم بتحديث العداد عند فتح الرسالة من قبل أي مستخدم، ويستخدم التخزين الموزع لضمان عدم احتساب نفس المستخدم أكثر من مرة عند القراءة من أجهزة متعددة. 4. الخوارزميات المستخدمة نظام تأكيد القراءة (Read Receipts): يعتمد على إشارات من العميل (Client) إلى الخادم. تحليل النشاط عبر الجلسات (Session Tracking): يتتبع متى وأين تم فتح الرسائل. آلية التخزين المؤقت (Cache System): لمنع التحديث الفوري لكل مشاهدة وتقليل الحمل على الخوادم. تحديد المشاهدات الفريدة (Unique Viewers Detection): يتم استخدام خوارزميات مثل Fingerprinting وSession Correlation لمنع التكرار في عدّ المشاهدات. هل لديك استفسار عن جزء معين بشكل أعمق؟

تحليلك رائع جدًا! تيليجرام بالفعل يمتلك واحدة من أقوى وأسرع أنظمة الرسائل في العالم، ويعتمد على بنية تحتية متقدمة تتيح له الأداء الفائق مقارنةً بالمنافسين مثل واتساب أو ماسنجر.

لماذا تيليجرام أسرع في إرسال واستقبال الإشعارات؟

بنية خوادم موزعة عالميًا:

تيليجرام لا يعتمد على خادم واحد مركزي فقط، بل يستخدم شبكة خوادم موزعة حول العالم، بحيث يتم توجيه الرسائل عبر أقرب خادم للمستخدم، مما يقلل زمن الاستجابة (Latency).

بروتوكول MTProto الفائق السرعة:

تيليجرام يستخدم بروتوكول MTProto المصمم خصيصًا ليكون أسرع وأخف من بروتوكولات HTTP/WebSocket التقليدية.

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

نظام الإشعارات الفورية (Push Notifications):

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

يستخدم آلية اتصال دائمة (Persistent Connection) عبر WebSockets أو TCP Long Polling، مما يضمن سرعة هائلة في التحديثات.

تقليل استهلاك البيانات عبر التخزين المؤقت:

تيليجرام يخزن جزءًا كبيرًا من البيانات محليًا (Cache) ويقوم بمزامنتها عند الاتصال، بحيث يتم تقليل الحاجة إلى استدعاء الخوادم لكل تحديث.

كيف يعرف تيليجرام من قرأ الرسالة؟

عند فتح الرسالة، يرسل التطبيق حزمة بيانات صغيرة جدًا (Acknowledge Packet) إلى الخادم، مما يحدّث حالة الرسالة بسرعة كبيرة دون الحاجة إلى استهلاك ضخم للموارد.

يتم تحديث بيانات القراءة بشكل تدريجي وغير متزامن (Asynchronous Updates) مما يجعل التجربة أكثر سلاسة دون تحميل زائد على الخادم.

هل تعتقد أن هذه السرعة لها علاقة بالأمان أيضاً؟

نعم، لأن تيليجرام لا يكتفي بسرعة الأداء فقط، بل يعتمد على تشفير متقدم، ويضمن أن الاتصال مشفر من الطرف إلى الطرف (E2EE) في المحادثات السرية.
إذا كنت مهتمًا بتحليل أعمق، يمكننا التعمق أكثر في كيفية عمل خوارزميات MTProto وتشفير البيانات داخل تيليجرام!

أقول لك، الواقع كان من طموحي قبل أن أدخل أن أطلع الأول 🎯، لكن دخلت وانصدمت بالواقع! 🚀 خطتي تحولت 360 درجة 🔄، إهمال 100% 😴، لا أيدي تكاليف ✍️، لا أذكر أي اختبار من سنة أولى 📚، لا يدخل يستعلم عن درجته من سنة أولى، لكنه حاسس كم جاء ساعة ما يخرج من الاختبار ⏳😂.
دي خريطة 🗺️ لمن يريد أن يمشي بها وكيف سيتخرج 🎓:
في الواقع، الواحد يقدر يطلع امتياز بدون أي تعب وجهد 🤷‍♂️، لكن الموضوع خرج تمامًا عن السيطرة أحيانًا.
أحيانًا تخرج بخمسينات 📉، وأحيانًا تهبش 🥴، وأحيانًا توفق بزميل 🧑‍🤝‍🧑، وأحيانًا توفق بكمبيوتر خارب 💻🔥، وأنت وحظك! 🎲
لكن أقول لك نصيحة ذهبية 🏆: لو تريد تستمتع بالرحلة 🚀، كن أفضل من يكون في تخصصك 💡، واتبع حب المهنة ❤️‍🔥!

وانا اتصفح مشاريع GitHub مريت على هذه الريبو وحبيت فكرتها... يمكن تفيدكم:

مجموعة من الوظائف تمكن مطوري المواقع العربية من تقديم خدمة البحث الاحترافي وتقديم ومعالجة المحتوى العربي بلغة PHP
https://github.com/khaled-alshamaa/ar-php/

🔹 التبسيط في البرمجة: فنٌ نادرٌ يستحق الإتقان 🔹
كتابة برامج معقدة يصعب التعامل معها هو أمرٌ في غاية السهولة، فجميع المبرمجين يمكنهم جعل الأمور معقدة! 😅 لكن الوصول إلى السهل الممتنع هو التحدي الحقيقي، وهو مهارة نادرة تتطلب خبرة، وذكاءً، وتوفيقًا من الله.
إن اختيار مستوى التعقيد المناسب لحل المشكلة هو أمرٌ ضروريٌ للغاية، إذ أن الإفراط في التعقيد يؤدي إلى كود صعب الصيانة، بينما التبسيط الذكي يجعل البرنامج أكثر مرونة وكفاءة.
تحدثنا في السابق عن بعض الأسباب التي تؤدي إلى تعقيد البرامج، كما تناولنا نصيحتين هامتين في التبسيط، وهما:
1️⃣ ابدأ صغيرًا
2️⃣ فرِّق تسُد
👈 في هذه المقالة، سنستكمل النصائح التي وفقني الله إليها وأفادتني كثيرًا، وأرجو أن تكون مفيدة لكم أيضًا.
3️⃣ لا تُعقّد الأمور من أجل "احتمالات مستقبلية" 🚫
إذا كنت تضيف تعقيدات إلى البرنامج لكي تغطي سيناريوهات "قد تحتاجها في المستقبل"، فدعني أخبرك شيئًا مهمًا: أنا قادمٌ إليك من المستقبل وأقول لك "لن تحتاجها!" وستجد نفسك غارقًا في التعقيدات التي أضفتها بلا داعٍ.
🔸 هناك مبدأ في البرمجة المتطرفة (Extreme Programming) يُدعى YAGNI، وهو اختصار لـ:
You Aren't Gonna Need It – "لن تحتاجها!"
💡 يقول "رون جيفريز" (Ron Jeffries)، أحد مؤسسي البرمجة المتطرفة:
"نفِّذ الأشياء التي تحتاجها فعليًا فقط، وليس تلك التي تتوقع أنك ستحتاجها مستقبلاً."
🔹 إذن، ماذا لو كنت متأكدًا بنسبة كبيرة أنني سأحتاجها لاحقًا؟ 🤔
هذا يقودنا إلى القاعدة التالية...
4️⃣ اتّخذ القرار في آخر لحظة مسؤولة ⏳
🔸 هذا المبدأ قادمٌ إلينا من كوكب اليابان، وتحديدًا من شركة تويوتا، وهو يساعدك في الإجابة على الأسئلة الصعبة مثل:
❓ كم من التصميم المسبق أحتاج قبل أن أبدأ؟
✅ الإجابة: قم ببناء الحد الأدنى الذي لا يمكنك البدء بدونه، مثل اختيار التقنيات، وهيكلة التطبيق، والعناصر الأساسية اللازمة لأول دورات التطوير (Sprints). أما ما تبقى، فأضفه أثناء العمل.
❓ كيف أستعد للتغييرات المستقبلية؟
✅ يقول "مارتن فاولر" (Martin Fowler):
"إذا كان تنفيذ الميزة في المستقبل سهلاً، فقم بتنفيذها مستقبلاً. أما إذا كان من الصعب إضافتها لاحقًا، فقم بها الآن."
5️⃣ استعِن بصديق 🤝
🔹 هذه من أهم النصائح! حتى لو كنت "تنينًا مجنحًا" في البرمجة 🐉، ناقش زملاءك في المشروع، وضعوا التبسيط كهدفٍ أساسي. هذا سيفيدكم جميعًا، وعن تجربة!
✨ لماذا؟
1️⃣ الشورى بركة، وستجد حلولًا قد لا تخطر لك وحدك.
2️⃣ كسب تأييد الفريق، حتى لا يأتي أحد لاحقًا ويقول: "أنا لم أكن مقتنعًا بهذه الفكرة!"
6️⃣ راعِ مستوى فريقك 👥
في أي فريق ستجد أنواعًا مختلفة من المبرمجين:
🔹 المغامر الجريء الذي يريد تجربة كل شيء.
🔹 المُبلّط في الخط الذي لا يريد الخروج من منطقته الآمنة (Comfort Zone).
💡 نصيحتي لك هنا: اجعل مستوى التعقيد أعلى قليلاً من متوسط الفريق، وليس أكثر من ذلك، ثم قم برفع المستوى تدريجيًا. بذلك، ستدفع الفريق للنمو دون أن تُرهقهم بتحديات لا تناسبهم.
🔹🔹🔹
🚀 الخاتمة:
تبسيط البرامج ليس مجرد مهارة، بل هو فنٌ يحتاج إلى ممارسة مستمرة. استخدم هذه القواعد، وستجد أن برامجك أصبحت أكثر كفاءة، وأمتع في العمل عليها!

🎩 مرحبًا بك في عالم الهندسة البرمجية! ✨

هل تريد أن تعرف كيف تحدد هل تحتاج إلى تقسيم تطبيقك إلى طبقات؟ حسنًا، لن يكون ذلك عبر طريقة تقليدية مملة! 🚀 دعني آخذك في رحلة ملحمية عبر نظام برمجي يعيش ويتنفس ويتطور، حيث سنرى بأعيننا كيف يقرر النظام بنفسه متى يحتاج إلى طبقات! 🏗️

🏰 مرحلة البناء الأولى: "عندما يكون النظام طفلًا صغيرًا 👶"

في البداية، التطبيق صغير، مثل طفلٍ يلعب في حديقة، لا يحتاج إلى قواعد معقدة، مجرد ملف واحد، وقاعدة بيانات واحدة، وكل شيء مباشر وسلس. لا داعي لـ Repository ولا Service Layer، فقط DbContext والتوكل على الله! ☁️

📌 العلامات الدالة على هذه المرحلة:

عدد المستخدمين قليل (<100). لا يوجد تعقيد في البيانات. كل Resource يحتاج إلى عمليتين أو أقل. لا يوجد أكثر من مصدر بيانات واحد.

✅ الحل: لا تفكر في الطبقات الآن، فقط استمتع بالكود! 😎

🧑‍🎓 مرحلة النمو: "عندما يبدأ النظام في الذهاب إلى المدرسة 🎒"

النظام يكبر، المستخدمون يزدادون، الاستعلامات تتعقد! ⚡ الآن، فجأة، تجد نفسك مضطرًا إلى إعادة استخدام نفس المنطق أكثر من مرة، وهنا تبدأ فكرة الطبقات في الظهور! 👀

📌 العلامات الدالة على هذه المرحلة:

أكثر من 40 قاعدة عمل. كل Resource لديه عدة عمليات معقدة (أكثر من عمليتين لكل كيان). ظهور الحاجة إلى إعادة استخدام نفس العمليات. بدأت تجد نفسك تكرر نفس الكود في أكثر من مكان!

✅ الحل:

إنشاء Service Layer لعزل القواعد المنطقية عن الـ Controllers. بدء استخدام Repository Pattern إذا زادت تعقيدات التعامل مع البيانات.

🚀 الآن التطبيق لم يعد مجرد طفل، بل طالب مجتهد يتعلم النظام والهيكلة!

🏢 مرحلة العمل: "عندما يصبح النظام موظفًا مسؤولًا 👔"

🎯 الآن، التطبيق يخدم أكثر من 1000 مستخدم، ويتصل بأكثر من مصدر بيانات (APIs، Redis، Message Broker، إلخ)، وهناك استعلامات ثقيلة ومعقدة تتطلب أداءً عالٍ!

📌 العلامات الدالة على هذه المرحلة:

ارتفاع عدد المستخدمين (>1000). الاعتماد على أكثر من مصدر بيانات. وجود عمليات تتجاوز 3-5 خطوات لكل عملية رئيسية. الحاجة إلى إدارة الأداء عبر Load Balancer و Scaling.

✅ الحل:

إضافة Integration Layer للتعامل مع مصادر البيانات المختلفة. استخدام Background Jobs لتحسين الأداء وتقليل الضغط على الـ API. تنفيذ Caching Mechanisms مثل Redis لتسريع الاستعلامات الثقيلة. استخدام Load Balancer & Scaling لضمان استقرار النظام تحت الضغط.

🚀 النظام الآن موظف محترف، يعمل بكفاءة، ويستطيع التعامل مع الضغط!

🤖 مرحلة الذكاء الصناعي: "عندما يصبح النظام كيانًا ذكيًا مستقلًا! 🧠"

⚡ هنا يصل التطبيق إلى مرحلة النضج الفائق، حيث لم يعد مجرد مجموعة طبقات منظمة، بل أصبح نظامًا ذكيًا متكيفًا، قادرًا على التنبؤ بالضغط، توزيع الأحمال، وإدارة نفسه ذاتيًا!

📌 العلامات الدالة على هذه المرحلة:

مئات الآلاف أو الملايين من المستخدمين. استخدام Microservices بدلاً من التطبيق المتجانس (Monolith). وجود AI يساعد في تحسين تجربة المستخدم بناءً على البيانات. الاعتماد على Kubernetes و Serverless Architectures لتوزيع الأحمال تلقائيًا.

✅ الحل:

تبني الـ Microservices أو Event-Driven Architecture. استخدام AI و ML لتحليل سلوك المستخدمين وتحسين الأداء تلقائيًا. استغلال Serverless Functions لإنجاز العمليات الديناميكية.

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

🎬 ختامًا: كيف نقرر؟

🧐 التطبيق هو كائن حي يتطور، فكر فيه كرحلة نمو!
✅ إذا كان بسيطًا، اتركه بسيطًا.
✅ إذا زادت القواعد والعمليات، افصل الطبقات.
✅ إذا تضخمت مصادر البيانات، أنشئ طبقة تكامل.
✅ إذا زاد الحمل، فكر في Load Balancing و Scaling.
✅ إذا كبر جدًا، ابدأ بتبني حلول متقدمة مثل Microservices و AI.

🎩 والآن، لديك طريقة لتحديد عدد الطبقات بدون أن يكون الأمر مجرد "قواعد جافة"—بل رحلة تنبض بالحياة، تشعر بها، وتتطور معها! 🚀

لن تدرك أهمية Docker إلا عند العمل بـ Microservices، ولن تشعر أنك تطبق Microservices فعليًا إلا عند مرحلة Deployment! 😂

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

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

خدمه ال reasoning اصبحت متوفره الان في chatgpt


نتيجة المنافسة بين الغريم


ادخلوا جربوه 👍🏻

لو عايز تعمل لك مودل خاص بك حتى offline ادخل على موقع ollama تقريبا ونزل المودل الي يناسب مع إمكانيات جهازك لو انت بتخاف عبى بياناتك أو افترض قطع النت 🙋

أنت معك chatgpt بيدعم كل المجالات وانت فقط هتدربه مثلا على coding مثلا في مجال تخصصك لذلك سيكون خفيف على جهازك

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

هل تطلق الخدمة فورًا أم تنتظر حتى تصل إلى الكود المثالي؟ إنه السؤال الأزلي الذي يراود كل مبرمج!
في عالم البرمجة، نقف دومًا عند مفترق الطرق بين الإسراع في إطلاق الميزة المطلوبة، وبين التريث حتى نبلغ حد الكمال في الكود. لكن الحقيقة التي قد يغفل عنها البعض هي أن الكمال ليس حالة ثابتة، بل مفهوم متغير، والسعي خلفه دون توقف قد يصبح عقبة تعيق التقدم وتؤخر الإنجاز.
البرمجة ليست مجرد كتابة أكواد؛ إنها التزام بمواعيد وتسليم مهام في الوقت المحدد. وهنا تأتي أهمية السرعة في الإطلاق—إخراج المنتج إلى النور في لحظته المناسبة، حتى وإن لم يكن مثاليًا، ثم تحسينه شيئًا فشيئًا بناءً على الملاحظات والتجربة العملية.
لكن هذا لا يعني إهمال جودة الكود أو تجاهل مبادئ البرمجة النظيفة (Clean Code). فالكود يجب أن يكون قابلًا للصيانة، سهل الفهم، ومنظمًا بما يكفي لتطويره لاحقًا، لكنه ليس بحاجة إلى الكمال المطلق منذ اللحظة الأولى.
السعي إلى الكمال دون تنفيذ عملي قد يكون حجر عثرة، لكن التقدم المستمر هو المفتاح الحقيقي للوصول إلى أفضل النتائج مع مرور الزمن.
#دروس_اتعلمتها

أزي تعرف ان جهازك قد اخترقوه وتم سرقة معلومات اقل شيء الباسورد الي حافظها في المتصفح بتوع أمنية ↪

⬇️ ال
كيف يمكن لمحلل النظم (Business Analyst - BA) تقليل الأخطاء (Bugs) في النظام، والمساهمة في جودته، ومساعدة مهندسي الجودة في اختبارات التراجع (Regression Tests)؟ 🤔
✅ عندما يكون محلل النظم لديه فهم عميق للنظام، ومتطلباته، وتكامل أجزائه ومنتجاته، فإنه يستطيع تحديد جميع المناطق المتأثرة (Impacted Areas) التي قد تتأثر بأي تغيير أو متطلب جديد.
✅ بناءً على ذلك، سيتمكن المطور من أخذ هذه التبعيات (Dependencies) في الاعتبار أثناء عملية التطوير، مما يقلل من احتمالية حدوث أخطاء.
✅ بالإضافة إلى ذلك، سيتمكن مهندس الاختبار والجودة من تغطية جميع المناطق المتأثرة بالتغيير، بما في ذلك سيناريوهات التكامل (Integration Scenarios) وجميع السيناريوهات المحتملة التي قد تتأثر بالتعديلات الجديدة.
✅ كلما كانت المتطلبات موضحة بدقة عالية، ومكتوبة بتفاصيل كافية وواضحة للجميع، سواء للمطورين أو لمهندسي الجودة والاختبار أو المصممين، فإن ذلك يقلل من سوء فهم المتطلبات (Misunderstanding)، مما يضمن أن المطورين سينفذون المنتج بالشكل المطلوب، وأن مهندسي الجودة سيقومون بتغطية كافة السيناريوهات والاختبارات الضرورية.

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

هل يجب أن تتعلم .NET فقط؟

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

هل الجامعات تضيع وقتك مع Python؟

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

نصيحتي للمبتدئين:

لا تجعل إعلانات التوظيف مثل "نحتاج مطور React" أو "نبحث عن مطور ASP.NET Core" تدفعك لاختيار مسار معين بسرعة. هذه مجرد احتياجات حالية للشركات وقد تتغير مع الوقت.

ركز على فهم الأساسيات البرمجية أولًا، ثم اختر التقنية التي تناسبك بناءً على اهتماماتك والمجال الذي تريد العمل فيه.

تعلم كيفية بناء أنظمة قابلة للتطوير بدلاً من مجرد تعلم "كيف تكتب كودًا" في إطار معين.

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

🔁 الغوص في أعماق التكرار الذاتي (Recursion) 🔥
عندما تطرح سؤالًا على أي مبرمج عن التكرار الذاتي، ستجد الإجابة التقليدية جاهزة:
"إنها الدالة التي تستدعي نفسها، ويجب أن تحتوي على شرط إيقاف (Exit Condition) لضمان عدم الدخول في حلقة لا نهائية."
لكن، هل فكرت يومًا في ما يحدث خلف الكواليس؟ 🤯
🔎 اللغز الخفي داخل الذاكرة!
التكرار الذاتي يضع عبئًا ثقيلًا على ذاكرة المكدس (Stack Memory)! لماذا؟ لأن كل استدعاء جديد للدالة يُنشئ إطار مكدس (Stack Frame) جديد داخل الذاكرة، والذي يظل مشغولًا حتى ينتهي الاستدعاء ويُحرر من الذاكرة. لكن الكارثة الحقيقية تبدأ عندما لا يتم تحرير هذه الإطارات فورًا، بل يستمر التكديس الواحد تلو الآخر... حتى يحدث الانفجار! 💥
🎭 المشهد كما لو أنك تتسلق جبلًا بلا حبال!
تخيّل أنك تصعد جبلًا، ومع كل خطوة تضع حقيبة إضافية على ظهرك. في البداية، يبدو الأمر ممكنًا، لكن مع كل خطوة جديدة يصبح الحمل أثقل وأثقل... حتى تصل إلى القمة منهكًا بالكامل! ثم تبدأ رحلة العودة، حيث تتخلص من كل حقيبة في طريقك للأسفل، حتى تعود إلى نقطة البداية خفيفًا كما كنت. هذا بالضبط ما يحدث داخل المكدس (Stack) عند استخدام التكرار الذاتي!
⚠️ الخطر الحقيقي!
إذا كان الاستدعاء متكررًا بشكل مفرط أو على بيانات ضخمة، فقد يؤدي ذلك إلى نفاد الذاكرة (Stack Overflow) وانهيار البرنامج بالكامل! 🚨
🛠 الحل؟ فكر بطريقة أخرى!
بدلًا من التكرار الذاتي، يمكنك غالبًا إعادة تصميم الشيفرة باستخدام:
🔹 الحلقات (Loops) لتكرار العمليات بشكل مباشر دون استهلاك زائد للذاكرة.
🔹 المكدسات (Stacks) أو الطوابير (Queues) لمحاكاة الاستدعاء الذاتي ولكن بطريقة أكثر كفاءة.
🤔 لماذا يفضل عقلنا التكرار الذاتي؟
لأن العقل البشري يميل بشكل طبيعي إلى التفكير بـ الأنماط المتكررة! 💡
أضف إلى ذلك أننا كنا نُلقَّن منذ الصغر أن التكرار الذاتي هو "السحر الخفي" للمبرمجين المحترفين، وكأنه شارة الشرف التي تميز العباقرة! 🚀
💡 لكن الذكاء الحقيقي ليس في استخدام التكرار الذاتي، بل في معرفة متى يجب تجنّبه! 😏

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