لما تلاقي نفسك تكتب كود كثير لحل مشكلة بسيطة، غالبًا في شيء غلط في طريقة تعاملك مع المشروع!
دعونا نأخذ مثالًا:
تخيل أنك تعمل على برنامج ويب أو تطبيق موبايل بسيط لتنفيذ CRUD operations، مع شوية قواعد أعمال (business logic) بسيطة: مجرد شوية if conditions بدون أي تعقيدات أو تداخلات!
المشاكل اللي ممكن تواجهك أو شفتها شخصيًا (وقعت فيها قبل ما أتعلم من أخطائي):
1️⃣ تطبيق كل التصميمات المعروفة (design patterns):
وكأن المشروع البسيط هذا يحتاج كل الأنماط اللي درستها!
2️⃣ إنشاء مشاريع ووحدات قابلة لإعادة الاستخدام بشكل مبالغ فيه:
بعض الأحيان تحاول بناء شيء عام (generic) يُستخدم في خمسين سيناريو مختلف، رغم أن المطلوب بسيط جدًا.
3️⃣ تطوير كل شيء من الصفر:
بدل استخدام مكتبات جاهزة موثوقة أو ممارسات مجربة.
4️⃣ إضافة طبقات Layers كثيرة في النظام بدون داعٍ:
مع أن النظام بسيط جدًا، لكن تجد نفسك تضيف طبقة لكل شيء!
5️⃣ إعادة كتابة الخوارزميات المشهورة مثل search وsort:
على سبيل المثال، التعامل مع المصفوفات (arrays) والقوائم المرتبطة (linked lists)، بدل الاعتماد على الدوال الجاهزة.
6️⃣ الاعتماد على ORM فقط، حتى لو بطيء:
قد تكتب استعلام SQL واحد أسرع بكثير، لكنك تفضل ORM حتى لو جعل التطبيق يذهب إلى قاعدة البيانات مئات المرات!
(كثير من المبرمجين لا يحبون SQL أو حتى لا يفهمونها جيدًا 🫠).
الأسباب التي تؤدي لهذه الأخطاء:
1️⃣ عدم فهمك العميق للمشكلة أو النظام (Business):
لو كنت مش عارف المشكلة اللي تحاول حلها، طبيعي تدخل في تعقيدات ما لها داعي.
2️⃣ ضعف الإلمام بالتكنولوجيا المستخدمة:
إذا كنت لا تعرف استخدام الأداة جيدًا، غالبًا ستتعقد الأمور.
3️⃣ السعي للكمال (perfectionism):
تريد كل شيء مثالي لدرجة أنك تضيف تعقيدًا على حساب البساطة.
4️⃣ التجريب لأجل CV:
ترغب في استخدام تقنيات جديدة لتضيفها لسيرتك الذاتية بدل التركيز على الهدف.
5️⃣ التعرض للكود السيء مسبقًا:
لو كنت تعمل مع كود قديم ومليء بالمشاكل، ستبالغ في جعل مشروعك الجديد مثاليًا.
6️⃣ التشتت وعدم الوضوح:
عندما تكون مش عارف تعمل ايش، ستقوم بتجربة كل شيء مما يعقد الأمور أكثر.
7️⃣ جميع ما سبق:
هنا، الوضع يصبح كارثيًا! 💣
النصائح للتغلب على هذه المشاكل:
1️⃣ افهم المشكلة بعمق:
قبل أن تبدأ بالحل، تأكد أنك فهمت المشكلة تمامًا. هذا سيوفر عليك الكثير من الوقت والجهد.
2️⃣ راجع الوثائق الرسمية:
بدل الاعتماد على الفيديوهات أو المقالات القديمة، اقرأ الوثائق الرسمية للأداة التي تعمل بها. ستجد فيها أفضل الممارسات التي يوصي بها أصحاب التكنولوجيا أنفسهم.
3️⃣ استخدم قاعدة YAGNI:
"You Aren’t Gonna Need It"
بمعنى: لا تضف أي ميزة أو طبقة غير ضرورية إلا إذا كنت متأكدًا أنك ستحتاجها. الأمور البسيطة غالبًا لا تحتاج تعقيدًا.
4️⃣ خفف التعقيد قدر الإمكان:
اجعل الأمور سهلة وبسيطة على نفسك وزملائك. المستقبل غير مضمون، وما تحاول أن تحميه الآن قد لا يحدث أبدًا.
وأخيرًا، لا تنسى:
البساطة هي المفتاح، لا تصعب الأمور على نفسك! 🚀
دعونا نأخذ مثالًا:
تخيل أنك تعمل على برنامج ويب أو تطبيق موبايل بسيط لتنفيذ CRUD operations، مع شوية قواعد أعمال (business logic) بسيطة: مجرد شوية if conditions بدون أي تعقيدات أو تداخلات!
المشاكل اللي ممكن تواجهك أو شفتها شخصيًا (وقعت فيها قبل ما أتعلم من أخطائي):
1️⃣ تطبيق كل التصميمات المعروفة (design patterns):
وكأن المشروع البسيط هذا يحتاج كل الأنماط اللي درستها!
2️⃣ إنشاء مشاريع ووحدات قابلة لإعادة الاستخدام بشكل مبالغ فيه:
بعض الأحيان تحاول بناء شيء عام (generic) يُستخدم في خمسين سيناريو مختلف، رغم أن المطلوب بسيط جدًا.
3️⃣ تطوير كل شيء من الصفر:
بدل استخدام مكتبات جاهزة موثوقة أو ممارسات مجربة.
4️⃣ إضافة طبقات Layers كثيرة في النظام بدون داعٍ:
مع أن النظام بسيط جدًا، لكن تجد نفسك تضيف طبقة لكل شيء!
5️⃣ إعادة كتابة الخوارزميات المشهورة مثل search وsort:
على سبيل المثال، التعامل مع المصفوفات (arrays) والقوائم المرتبطة (linked lists)، بدل الاعتماد على الدوال الجاهزة.
6️⃣ الاعتماد على ORM فقط، حتى لو بطيء:
قد تكتب استعلام SQL واحد أسرع بكثير، لكنك تفضل ORM حتى لو جعل التطبيق يذهب إلى قاعدة البيانات مئات المرات!
(كثير من المبرمجين لا يحبون SQL أو حتى لا يفهمونها جيدًا 🫠).
الأسباب التي تؤدي لهذه الأخطاء:
1️⃣ عدم فهمك العميق للمشكلة أو النظام (Business):
لو كنت مش عارف المشكلة اللي تحاول حلها، طبيعي تدخل في تعقيدات ما لها داعي.
2️⃣ ضعف الإلمام بالتكنولوجيا المستخدمة:
إذا كنت لا تعرف استخدام الأداة جيدًا، غالبًا ستتعقد الأمور.
3️⃣ السعي للكمال (perfectionism):
تريد كل شيء مثالي لدرجة أنك تضيف تعقيدًا على حساب البساطة.
4️⃣ التجريب لأجل CV:
ترغب في استخدام تقنيات جديدة لتضيفها لسيرتك الذاتية بدل التركيز على الهدف.
5️⃣ التعرض للكود السيء مسبقًا:
لو كنت تعمل مع كود قديم ومليء بالمشاكل، ستبالغ في جعل مشروعك الجديد مثاليًا.
6️⃣ التشتت وعدم الوضوح:
عندما تكون مش عارف تعمل ايش، ستقوم بتجربة كل شيء مما يعقد الأمور أكثر.
7️⃣ جميع ما سبق:
هنا، الوضع يصبح كارثيًا! 💣
النصائح للتغلب على هذه المشاكل:
1️⃣ افهم المشكلة بعمق:
قبل أن تبدأ بالحل، تأكد أنك فهمت المشكلة تمامًا. هذا سيوفر عليك الكثير من الوقت والجهد.
2️⃣ راجع الوثائق الرسمية:
بدل الاعتماد على الفيديوهات أو المقالات القديمة، اقرأ الوثائق الرسمية للأداة التي تعمل بها. ستجد فيها أفضل الممارسات التي يوصي بها أصحاب التكنولوجيا أنفسهم.
3️⃣ استخدم قاعدة YAGNI:
"You Aren’t Gonna Need It"
بمعنى: لا تضف أي ميزة أو طبقة غير ضرورية إلا إذا كنت متأكدًا أنك ستحتاجها. الأمور البسيطة غالبًا لا تحتاج تعقيدًا.
4️⃣ خفف التعقيد قدر الإمكان:
اجعل الأمور سهلة وبسيطة على نفسك وزملائك. المستقبل غير مضمون، وما تحاول أن تحميه الآن قد لا يحدث أبدًا.
وأخيرًا، لا تنسى:
البساطة هي المفتاح، لا تصعب الأمور على نفسك! 🚀
👍1
من لديه مصادر قوية فعلا لتعلم اللغة الإنجليزية، سواء كانت مجانية أو مدفوعة، يرسلها. المطلوب مصادر تعلم اللغة بشكل صحيح ومتكامل، وليس مجرد تعلم اللهجة العامية مخارجة .
اتخيل تكون طلقه في الانجليزي ومعك شويت خبره برمجيه ستكون اللغة الي تحد أي مطور لو عايز تنخرط في العالم الخارجي
اتخيل تكون طلقه في الانجليزي ومعك شويت خبره برمجيه ستكون اللغة الي تحد أي مطور لو عايز تنخرط في العالم الخارجي
👍2
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
يا محترف البرمجة والإتقان 🧑💻✨،
تتذكر أول ما بدأت تتعلّم السواقة وكانوا يقولوا لك: "دير بالك على أخطاء غيرك"؟
طيب إيش علاقة هذا الكلام بالبرمجة؟ هل إحنا المبرمجين مظلومين؟! 🤨
لا تستعجل يا ذكي 🤌، خليني أوضح لك الرابط بين السواقة والبرمجة بطريقة عملية.
الموضوع بكل بساطة: لما تعمل تكامل (Integration) مع نظام ثاني، لازم تحمي نفسك بـ Anti-Corruption Layer! ⚠️
يعني بكل وضوح، لازم تستخدم Adaptor لما تتعامل مع أي نظام خارجي.
ليش؟ تعال أفصّل لك المزايا وأقنعك بأهمية الـ Adaptor:
1️⃣ النظام الخارجي مش جاهز؟ ولا يهمك!
إذا اتفقتوا على العقد (Contract)، الـ Adaptor يلفّ (Wrap) الـ Service ويرجع لك بيانات افتراضية (Mock Data)، وتكمل شغلك عادي جدًا.
بعدين لما يكون النظام جاهز، كل اللي تحتاج تغيّره هو الـ Adaptor من الداخل، وما أحد بيلاحظ شيء.
2️⃣ تغييرات فجائية في الـ Contract؟!
لو النظام الثاني غير العقد، لا تقلق! تعدل الـ Adaptor من الداخل، والباقي كله يظل ثابت مثل الجبل 🏔️.
3️⃣ أسامي غريبة؟ كود متناقض؟
إذا كان النظام الخارجي يستخدم أسماء غير متناسقة مع معاييرك، الـ Adaptor يسوي عملية Mapping حتى يكون الشغل نظيف ومتناسق.
4️⃣ "الـ Contract مليان زحمة!"
إذا العقد فيه Noise كثيرة (زي بيانات ثابتة ما تتغير)، حطها في الـ Adaptor وخلي الشغل عندك واضح ومرتب 🧹.
5️⃣ "تريد تبسيط أكثر؟"
تقدر تخفي أمور زي:
Authentication
Retry Policy
Logging
Exception Handling
كلها تتخبّى جوّا الـ Adaptor، وتقدر تضيف أكثر من عملية في Method واحدة وتستخدمها بسهولة.
🔥 تحوّل الـ Adaptor إلى Facade؟!
بالضبط يا محترف ⭐! الـ Design Patterns ما تحل كل شيء دفعة واحدة. بعض المشاكل الكبيرة تحتاج دمج أكثر من نمط.
لاحظ الفكرة الجوهرية:
الـ Adaptor يلفّ (Wrap) العقد حتى يتوافق مع متطلباتك.
الـ Facade يلفّ العقد حتى يبسّط الأمور لك.
وأكمل لك الفوائد الباقية:
6️⃣ استخدام موحّد:
لو أكثر من مكان يحتاج يكلم النظام الخارجي، يخاطب الـ Adaptor. لو تغيّر النظام، فقط الـ Adaptor بيتأثر.
7️⃣ بديل لنظام جديد؟
لو قررت تربط مع نظام مختلف بنفس المهمة، تغيّر الـ Implementation داخل الـ Adaptor بدون ما تغيّر شيء برة.
(ممكن تضيف هنا الـ Strategy Pattern حتى تنوّع التنفيذ).
8️⃣ Unit Testing بدون صداع:
بكل سهولة تعمل Mock للـ Adaptor في اختباراتك.
9️⃣ كود أنيق باستخدام Null Object:
لو عندك حالات خاصة وما تريد تكتب شروط (Conditions) كثيرة، ممكن تضيف Null Object للـ Adaptor، ويصير كودك أنظف وأبسط.
الخلاصة:
يا محترف البرمجة، استخدم الـ Adaptors خاصة مع التكاملات (Integrations)، راح توفر عليك مشاكل الحاضر والمستقبل.
وفي الأخير، أهم شيء لا تنسى تستمتع بالشغل! 😎
والله أعلم 😌
تتذكر أول ما بدأت تتعلّم السواقة وكانوا يقولوا لك: "دير بالك على أخطاء غيرك"؟
طيب إيش علاقة هذا الكلام بالبرمجة؟ هل إحنا المبرمجين مظلومين؟! 🤨
لا تستعجل يا ذكي 🤌، خليني أوضح لك الرابط بين السواقة والبرمجة بطريقة عملية.
الموضوع بكل بساطة: لما تعمل تكامل (Integration) مع نظام ثاني، لازم تحمي نفسك بـ Anti-Corruption Layer! ⚠️
يعني بكل وضوح، لازم تستخدم Adaptor لما تتعامل مع أي نظام خارجي.
ليش؟ تعال أفصّل لك المزايا وأقنعك بأهمية الـ Adaptor:
1️⃣ النظام الخارجي مش جاهز؟ ولا يهمك!
إذا اتفقتوا على العقد (Contract)، الـ Adaptor يلفّ (Wrap) الـ Service ويرجع لك بيانات افتراضية (Mock Data)، وتكمل شغلك عادي جدًا.
بعدين لما يكون النظام جاهز، كل اللي تحتاج تغيّره هو الـ Adaptor من الداخل، وما أحد بيلاحظ شيء.
2️⃣ تغييرات فجائية في الـ Contract؟!
لو النظام الثاني غير العقد، لا تقلق! تعدل الـ Adaptor من الداخل، والباقي كله يظل ثابت مثل الجبل 🏔️.
3️⃣ أسامي غريبة؟ كود متناقض؟
إذا كان النظام الخارجي يستخدم أسماء غير متناسقة مع معاييرك، الـ Adaptor يسوي عملية Mapping حتى يكون الشغل نظيف ومتناسق.
4️⃣ "الـ Contract مليان زحمة!"
إذا العقد فيه Noise كثيرة (زي بيانات ثابتة ما تتغير)، حطها في الـ Adaptor وخلي الشغل عندك واضح ومرتب 🧹.
5️⃣ "تريد تبسيط أكثر؟"
تقدر تخفي أمور زي:
Authentication
Retry Policy
Logging
Exception Handling
كلها تتخبّى جوّا الـ Adaptor، وتقدر تضيف أكثر من عملية في Method واحدة وتستخدمها بسهولة.
🔥 تحوّل الـ Adaptor إلى Facade؟!
بالضبط يا محترف ⭐! الـ Design Patterns ما تحل كل شيء دفعة واحدة. بعض المشاكل الكبيرة تحتاج دمج أكثر من نمط.
لاحظ الفكرة الجوهرية:
الـ Adaptor يلفّ (Wrap) العقد حتى يتوافق مع متطلباتك.
الـ Facade يلفّ العقد حتى يبسّط الأمور لك.
وأكمل لك الفوائد الباقية:
6️⃣ استخدام موحّد:
لو أكثر من مكان يحتاج يكلم النظام الخارجي، يخاطب الـ Adaptor. لو تغيّر النظام، فقط الـ Adaptor بيتأثر.
7️⃣ بديل لنظام جديد؟
لو قررت تربط مع نظام مختلف بنفس المهمة، تغيّر الـ Implementation داخل الـ Adaptor بدون ما تغيّر شيء برة.
(ممكن تضيف هنا الـ Strategy Pattern حتى تنوّع التنفيذ).
8️⃣ Unit Testing بدون صداع:
بكل سهولة تعمل Mock للـ Adaptor في اختباراتك.
9️⃣ كود أنيق باستخدام Null Object:
لو عندك حالات خاصة وما تريد تكتب شروط (Conditions) كثيرة، ممكن تضيف Null Object للـ Adaptor، ويصير كودك أنظف وأبسط.
الخلاصة:
يا محترف البرمجة، استخدم الـ Adaptors خاصة مع التكاملات (Integrations)، راح توفر عليك مشاكل الحاضر والمستقبل.
وفي الأخير، أهم شيء لا تنسى تستمتع بالشغل! 😎
والله أعلم 😌
أكبر مشكلة أشوفها في التعليم اللي يعتمد على الحفظ بدون فهم هي إنه يضيّع قيمة العلم والتعلم في نفوس الطلاب.
يتخرج الطالب من الجامعة وهو ما يشوف إن التعلم نفسه شيء مفيد، ويفكر إنه يكفي يأخذ له كورسين عشان يشتغل وخلاص.
وهذا أسوأ من إنه ما تعلم من البداية، لأنه بيخليه ما ينوي يتعلم بعدين.
جرب شوف الفرق بين شغل واحد ركّز على الفريموركس وهو ما درس خوارزميات ولا الـOOP وما عنده أساس قوي، وبين شغل واحد فاهم صح وعنده معرفة بالساينس.
بتلاحظ فرق كبير جدًا!
بتلقى اللي ركز على الفريموركس فقط، كوده سباغيتي، مليان لف ودوران، ومكرر في أماكن كثيرة. أداؤه بيكون متواضع، ولو جيت تشتغل على شغله بعده، بتتعذب لأن مافي إطار تفكير واضح أو Consistency في شغله.
التعلم مهم جدًا، والقراءة في كتب الساينس أهم.
الانطباع اللي وصلك إنه هذا الكلام نظري وما له فايدة، انطباع غلط، لأنك أخذته من تجربة تعلم مع ناس ما عندها خبرة كافية في الصناعة أو في ربط النظريات بالتطبيق.
اتعلم كويس ساينس الله يحفظك. 🌟
اتعلم كويس ساينس الله يحفظك. 📚
اتعلم كويس ساينس الله يحفظك. 💡
يتخرج الطالب من الجامعة وهو ما يشوف إن التعلم نفسه شيء مفيد، ويفكر إنه يكفي يأخذ له كورسين عشان يشتغل وخلاص.
وهذا أسوأ من إنه ما تعلم من البداية، لأنه بيخليه ما ينوي يتعلم بعدين.
جرب شوف الفرق بين شغل واحد ركّز على الفريموركس وهو ما درس خوارزميات ولا الـOOP وما عنده أساس قوي، وبين شغل واحد فاهم صح وعنده معرفة بالساينس.
بتلاحظ فرق كبير جدًا!
بتلقى اللي ركز على الفريموركس فقط، كوده سباغيتي، مليان لف ودوران، ومكرر في أماكن كثيرة. أداؤه بيكون متواضع، ولو جيت تشتغل على شغله بعده، بتتعذب لأن مافي إطار تفكير واضح أو Consistency في شغله.
التعلم مهم جدًا، والقراءة في كتب الساينس أهم.
الانطباع اللي وصلك إنه هذا الكلام نظري وما له فايدة، انطباع غلط، لأنك أخذته من تجربة تعلم مع ناس ما عندها خبرة كافية في الصناعة أو في ربط النظريات بالتطبيق.
اتعلم كويس ساينس الله يحفظك. 🌟
اتعلم كويس ساينس الله يحفظك. 📚
اتعلم كويس ساينس الله يحفظك. 💡
👏1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
احيانًا هتدخل على نظام شغال
من وين أبدأ حتى اعرف ماسبب بطئ النظام ايش عرفك السرعة يقابلها الوقت تخيل انت في نظام عليه ملايين
تعرف مقولة اشتغل على نفسك حتى تنسى الكلية الي درست فيها وأحيانا هذا نوع من ال interview
انبهك 🌝
من وين أبدأ حتى اعرف ماسبب بطئ النظام ايش عرفك السرعة يقابلها الوقت تخيل انت في نظام عليه ملايين
تعرف مقولة اشتغل على نفسك حتى تنسى الكلية الي درست فيها وأحيانا هذا نوع من ال interview
انبهك 🌝
🤝2
InfoTechnology (IT4_2024)
احيانًا هتدخل على نظام شغال من وين أبدأ حتى اعرف ماسبب بطئ النظام ايش عرفك السرعة يقابلها الوقت تخيل انت في نظام عليه ملايين تعرف مقولة اشتغل على نفسك حتى تنسى الكلية الي درست فيها وأحيانا هذا نوع من ال interview انبهك 🌝
لو كنت مسؤول عن نظام بيستقبل بيانات من فرق مختلفة عن طريق الـ APIs وبدأت تحس أن الأداء مش زي ما هو مطلوب مع زيادة الضغط، خلي أشارك معكم الخطوات
1. حلل الوضع الحالي بدقة 🕵️♂️
أول شيء سويه، استخدمت أدوات مثل Application Insights وELK Stack (Elasticsearch، Logstash، Kibana) عشان أراقب الأداء وأفهم وين النقاط اللي تسبب المشاكل.
حتى قست سرعة استجابة كل API باستخدام أدوات مثل Postman، وبدأت أحدد الاختناقات.
2. راقب أوقات الضغط ⏱️
عرفت أوقات الذروة (Peak Hours) اللي فيها الضغط يكون في أعلى مستوى، وركزت عليها لأشوف كيف النظام يشتغل وقتها.
3. راجع الكود بذكاء 🧑💻
مشيت على الكود كامل وتأكدت إنه مكتوب بطريقة نظيفة وواضحة.
الاستدعاءات اللي كانت متزامنة (Synchronous Calls) حولتها إلى غير متزامنة (Asynchronous Calls) في الأماكن اللي يناسبها.
4. ركز على قاعدة البيانات 🗄️
بدأت أحلل الاستعلامات الثقيلة باستخدام أدوات مثل SQL Profiler.
أضفت فهارس (Indexes) للاستعلامات اللي عليها ضغط كبير، وراجعت تصميم الجداول إذا محتاجة Normalization أو حتى Denormalization.
5. سرّع الـ APIs 🚀 فعلت الـ Caching (زي Redis) بحيث البيانات اللي تتكرر كثير تتخزن مؤقتًا. ضغطت البيانات باستخدام Gzip Compression عشان حجم الاستجابة يكون أصغر وأسرع. ركزت على إرسال البيانات الضرورية فقط بدل ما أرسل كل شيء في الـ Response. 6. وزّع الحمل ⚖️
إذا السيرفرات عندك تعاني من الضغط، الحل كان بسيط: استخدمت Load Balancer لتوزيع الطلبات بشكل متساوي.
7. فكر في المهام الثقيلة 🌀
بدل ما المهام الكبيرة تستهلك النظام، نقلتها إلى Queues مثل RabbitMQ أو Azure Service Bus، وهكذا خففت الضغط عن النظام الرئيسي.
8. طبّق Rate Limiting 🚦
عشان أحمي النظام من الضغط الزائد، استخدمت تقنيات تحدد عدد الطلبات لكل مستخدم أو فريق.
9. تأكد من تصميم الـ APIs 📐 صممت APIs مخصصة للبيانات اللي تتكرر طلبها بكثرة. اعتمدت على ممارسات مثل RESTful Design لضمان الجودة. 10. اختبر النظام تحت الضغط 🛠️
في النهاية، استخدمت أدوات مثل JMeter وk6 عشان أختبر النظام تحت حمل ثقيل وأعرف حدوده.
🙋
1. حلل الوضع الحالي بدقة 🕵️♂️
أول شيء سويه، استخدمت أدوات مثل Application Insights وELK Stack (Elasticsearch، Logstash، Kibana) عشان أراقب الأداء وأفهم وين النقاط اللي تسبب المشاكل.
حتى قست سرعة استجابة كل API باستخدام أدوات مثل Postman، وبدأت أحدد الاختناقات.
2. راقب أوقات الضغط ⏱️
عرفت أوقات الذروة (Peak Hours) اللي فيها الضغط يكون في أعلى مستوى، وركزت عليها لأشوف كيف النظام يشتغل وقتها.
3. راجع الكود بذكاء 🧑💻
مشيت على الكود كامل وتأكدت إنه مكتوب بطريقة نظيفة وواضحة.
الاستدعاءات اللي كانت متزامنة (Synchronous Calls) حولتها إلى غير متزامنة (Asynchronous Calls) في الأماكن اللي يناسبها.
4. ركز على قاعدة البيانات 🗄️
بدأت أحلل الاستعلامات الثقيلة باستخدام أدوات مثل SQL Profiler.
أضفت فهارس (Indexes) للاستعلامات اللي عليها ضغط كبير، وراجعت تصميم الجداول إذا محتاجة Normalization أو حتى Denormalization.
5. سرّع الـ APIs 🚀 فعلت الـ Caching (زي Redis) بحيث البيانات اللي تتكرر كثير تتخزن مؤقتًا. ضغطت البيانات باستخدام Gzip Compression عشان حجم الاستجابة يكون أصغر وأسرع. ركزت على إرسال البيانات الضرورية فقط بدل ما أرسل كل شيء في الـ Response. 6. وزّع الحمل ⚖️
إذا السيرفرات عندك تعاني من الضغط، الحل كان بسيط: استخدمت Load Balancer لتوزيع الطلبات بشكل متساوي.
7. فكر في المهام الثقيلة 🌀
بدل ما المهام الكبيرة تستهلك النظام، نقلتها إلى Queues مثل RabbitMQ أو Azure Service Bus، وهكذا خففت الضغط عن النظام الرئيسي.
8. طبّق Rate Limiting 🚦
عشان أحمي النظام من الضغط الزائد، استخدمت تقنيات تحدد عدد الطلبات لكل مستخدم أو فريق.
9. تأكد من تصميم الـ APIs 📐 صممت APIs مخصصة للبيانات اللي تتكرر طلبها بكثرة. اعتمدت على ممارسات مثل RESTful Design لضمان الجودة. 10. اختبر النظام تحت الضغط 🛠️
في النهاية، استخدمت أدوات مثل JMeter وk6 عشان أختبر النظام تحت حمل ثقيل وأعرف حدوده.
🙋
لمحة 👀 برمجية
لو كنت مسؤول عن نظام بيستقبل بيانات من فرق مختلفة عن طريق الـ APIs وبدأت تحس أن الأداء مش زي ما هو مطلوب مع زيادة الضغط، خلي أشارك معكم الخطوات 1. حلل الوضع الحالي بدقة 🕵️♂️ أول شيء سويه، استخدمت أدوات مثل Application Insights وELK Stack (Elasticsearch،…
وأنت بتتعلم، جرب تطبق أفكار عملية بدل ما تكتفي بعمليات CRUDs فقط. مثلاً، جرب تعمل seed data بملايين أو مليارات السجلات وشوف كيف أداء النظام. مش هيكون في خسارة إذا جربت وتعلمت من التجربة. ما تخليش تركيزك فقط على تنفيذ الكود بشكل سريع وإنهاء المهمة وكأنها مجرد "snippets" جاهزة. خد وقتك لتفهم وتطور من شغلك. مافيش ضغط، مش عندك مليون عميل يطالبك بالسرعة. استخدم أدوات زي ChatGPT كوسيلة للتعلم والتطوير، مش بس للخروج من المشاكل أو إنجاز المهام بسرعة.
👍1
قبل أيام كنت أشتغل على فرع معين (برانش)، واحتجت أطلع منه فرع جديد. بكل بساطة، عملت البرانش الجديد وبدأت أشتغل عليه. لكن عندما رجعت للبرانش القديم، قررت أمسح أيضا شوية commits باستخدام git reset.
بعدها عندما رجعت للبرانش الجديد، تفاجأت أن الذي مسحته من البرانش القديم اختفى كذلك من الجديد! 😲
ما الذي حدث؟
عندما تقوم بإنشاء برانش جديد في Git من برانش موجود، البرانش الجديد يشارك نفس النقطة (shared history). يعني إذا عدلت أو مسحت أشياء في البرانش القديم باستخدام أوامر مثل git reset أو git rebase، البرانش الجديد قد يتأثر لأنه يتشارك نفس الـ commits.
طيب، إذا حدثت معك نفس المشكلة، ما الحل؟
المنقذ: git reflog
Git يسجل كل خطوة، حتى إذا مسحتها! باستخدام git reflog يمكنك أن تعيد كل شيء تم مسحه بسهولة. 🔄
استخدام الأوامر بحذر
بدلاً من git reset، جرب استخدام git revert إذا كنت تريد إلغاء تغييرات بدون أن تخرب الـ history. 🛡️
خطط قبل إنشاء البرانش الجديد
تأكد أن البرانش الأساسي ثابت، ولن تقوم عليه تغييرات جذرية. 📋
فكر بتأثير شغلك على بقية البرانشات
خصوصا إذا كنت تعمل ضمن فريق كبير. 🤝
رمضان كريم مقدماً، وكل عام وأنتم بخير! 🌙✨
بعدها عندما رجعت للبرانش الجديد، تفاجأت أن الذي مسحته من البرانش القديم اختفى كذلك من الجديد! 😲
ما الذي حدث؟
عندما تقوم بإنشاء برانش جديد في Git من برانش موجود، البرانش الجديد يشارك نفس النقطة (shared history). يعني إذا عدلت أو مسحت أشياء في البرانش القديم باستخدام أوامر مثل git reset أو git rebase، البرانش الجديد قد يتأثر لأنه يتشارك نفس الـ commits.
طيب، إذا حدثت معك نفس المشكلة، ما الحل؟
المنقذ: git reflog
Git يسجل كل خطوة، حتى إذا مسحتها! باستخدام git reflog يمكنك أن تعيد كل شيء تم مسحه بسهولة. 🔄
استخدام الأوامر بحذر
بدلاً من git reset، جرب استخدام git revert إذا كنت تريد إلغاء تغييرات بدون أن تخرب الـ history. 🛡️
خطط قبل إنشاء البرانش الجديد
تأكد أن البرانش الأساسي ثابت، ولن تقوم عليه تغييرات جذرية. 📋
فكر بتأثير شغلك على بقية البرانشات
خصوصا إذا كنت تعمل ضمن فريق كبير. 🤝
رمضان كريم مقدماً، وكل عام وأنتم بخير! 🌙✨
👍3
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
المشروع 🛑🏃♂️
أنت لك فترة تكتب كود، وكل يوم تحس إنك تكبر، وتبدأ تسأل نفسك: وبعدين؟! 🤔
جلست مع أصحابك المبرمجين في أماكن عده والشباب على النار، ولقيت إن الجميع عندهم نفس القلق والهواجس.
أحمد البزي قال: "أنا ضابح من الشغل هذا، أفكر أشتري لي جملين وأربيهم فوق الجبل." 🐪 خاله واسع رد عليه: "لا يا رجال! أنا بفكر أفتح لي كافتيريا، القهوة والشاهي كفيلة تغطي المصاريف." ☕ مسفر انطلق وقال: "يا جماعة، لو زرعنا مانجو عويسي في أرض خطبه ، بنصير أغنى من أي مشروع!" 🥭 حازم قاطعهم: "ما فيش أحسن من ستارتب! اسمعوا نصيحتي، المشاريع التقنية تربح أسرع." 💻
لحظة صمت تعم الجلسة، وكل واحد يغوص في أفكاره...
ثم فجأة، تذكرتم الحقيقة المؤلمة: أنتم مفلسين وما معكم حتى قيمة جالون ديزل 🫠.
قدامكم الآن خيارين: تبدأوا مسار الأركتكتشر 🏗️. تمسكوا مسار الإدارة 🗂️. عزيزي المبرمج،
قبل ما تختار أي مسار، فيه شيئين لازم تغيرهم في طريقة تفكيرك (أهم من الكود اللي تكتبه):
1. فكر استراتيجيًا: شوف الصورة الكبيرة 📊 في مسار الأركتكتشر:
بتقرر كيف يكون تصميم النظام مرن وقوي، تأخذ قرارات تقنية صعبة التغيير، وتضمن استمرارية السيستم لفترة طويلة، وكأنه سفينة عابرة للمحيطات. 🚢 في مسار الإدارة:
تركز على الفريق، تبني معنوياتهم، تضمن أن المشروع يسلم في وقته، بميزانية مناسبة، وبجودة تخلي العميل يبتسم مثل شروق شمس عدن. 🌅 2. فكر بـ"هدف البزنس" مش "الكود" فقط: 💼 في الأركتكتشر:
لما تختار تقنية أو إطار عمل، لا تختار عشان تلمّع السي في أو تجرب حاجة جديدة! اسأل نفسك: هل هذا يخدم أهداف المشروع؟ في الإدارة:
ما تشوف الفريق كأنهم عمال يومية تشتغلهم بدون فائدة. خليهم يشتغلوا على حاجة تفيد الشركة، ولو مافيش، استثمر وقتهم في تطويرهم بما يخدم المشروع.
أسمع 👇
مهما كان الطريق اللي تختاره، خذ وقتك، فكر بـ"بكرة" بدل ما تغرق في "اليوم".
وتذكر دائمًا: المستقبل ملك اللي عنده رؤية... وشوية طموح. 🌟
والآن، ايش رأيك؟ بتكمل برمجة؟ بتفتح مزرعة؟ أو... بتقرر تخوض مسار جديد؟
أنت لك فترة تكتب كود، وكل يوم تحس إنك تكبر، وتبدأ تسأل نفسك: وبعدين؟! 🤔
جلست مع أصحابك المبرمجين في أماكن عده والشباب على النار، ولقيت إن الجميع عندهم نفس القلق والهواجس.
أحمد البزي قال: "أنا ضابح من الشغل هذا، أفكر أشتري لي جملين وأربيهم فوق الجبل." 🐪 خاله واسع رد عليه: "لا يا رجال! أنا بفكر أفتح لي كافتيريا، القهوة والشاهي كفيلة تغطي المصاريف." ☕ مسفر انطلق وقال: "يا جماعة، لو زرعنا مانجو عويسي في أرض خطبه ، بنصير أغنى من أي مشروع!" 🥭 حازم قاطعهم: "ما فيش أحسن من ستارتب! اسمعوا نصيحتي، المشاريع التقنية تربح أسرع." 💻
لحظة صمت تعم الجلسة، وكل واحد يغوص في أفكاره...
ثم فجأة، تذكرتم الحقيقة المؤلمة: أنتم مفلسين وما معكم حتى قيمة جالون ديزل 🫠.
قدامكم الآن خيارين: تبدأوا مسار الأركتكتشر 🏗️. تمسكوا مسار الإدارة 🗂️. عزيزي المبرمج،
قبل ما تختار أي مسار، فيه شيئين لازم تغيرهم في طريقة تفكيرك (أهم من الكود اللي تكتبه):
1. فكر استراتيجيًا: شوف الصورة الكبيرة 📊 في مسار الأركتكتشر:
بتقرر كيف يكون تصميم النظام مرن وقوي، تأخذ قرارات تقنية صعبة التغيير، وتضمن استمرارية السيستم لفترة طويلة، وكأنه سفينة عابرة للمحيطات. 🚢 في مسار الإدارة:
تركز على الفريق، تبني معنوياتهم، تضمن أن المشروع يسلم في وقته، بميزانية مناسبة، وبجودة تخلي العميل يبتسم مثل شروق شمس عدن. 🌅 2. فكر بـ"هدف البزنس" مش "الكود" فقط: 💼 في الأركتكتشر:
لما تختار تقنية أو إطار عمل، لا تختار عشان تلمّع السي في أو تجرب حاجة جديدة! اسأل نفسك: هل هذا يخدم أهداف المشروع؟ في الإدارة:
ما تشوف الفريق كأنهم عمال يومية تشتغلهم بدون فائدة. خليهم يشتغلوا على حاجة تفيد الشركة، ولو مافيش، استثمر وقتهم في تطويرهم بما يخدم المشروع.
أسمع 👇
مهما كان الطريق اللي تختاره، خذ وقتك، فكر بـ"بكرة" بدل ما تغرق في "اليوم".
وتذكر دائمًا: المستقبل ملك اللي عنده رؤية... وشوية طموح. 🌟
والآن، ايش رأيك؟ بتكمل برمجة؟ بتفتح مزرعة؟ أو... بتقرر تخوض مسار جديد؟
👏1
خلاااااص .. كفاية! الموضوع أصبح مرعب فعلا! 🫣
منذ قليل أطلقت DeepSeek نموذج أكثر تطورآ ومختلف كليآ عن السابق، هنا DeepSeek عاملة موديل أكثر تطورآ فقط، لآ هذا مقدمة معمارية جديدة مختلفة كليا عن الـ VAE التقليدية تعطي كفاءة أقوى بمراحل وبتكلفة أقل!
السورس : https://github.com/deepseek-ai/Janus
منذ قليل أطلقت DeepSeek نموذج أكثر تطورآ ومختلف كليآ عن السابق، هنا DeepSeek عاملة موديل أكثر تطورآ فقط، لآ هذا مقدمة معمارية جديدة مختلفة كليا عن الـ VAE التقليدية تعطي كفاءة أقوى بمراحل وبتكلفة أقل!
السورس : https://github.com/deepseek-ai/Janus
GitHub
GitHub - deepseek-ai/Janus: Janus-Series: Unified Multimodal Understanding and Generation Models
Janus-Series: Unified Multimodal Understanding and Generation Models - deepseek-ai/Janus
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
لما تسمع عن تطبيق جديد دخل السوق واحتل الصدارة في قائمة التطبيقات الأكثر تحميلًا على "آبل ستور" و"جوجل بلاي" بسرعة خيالية، أكيد بتسأل نفسك: "من هذا؟ ومن أين جاء؟"، والجواب بكل بساطة: "DeepSeek". هذا التطبيق الصيني قلب الطاولة تمامًا وخلق حالة من الجدل، مش بس في الصين، بل حتى في الأسواق العالمية مثل أمريكا وأوروبا، بعد إطلاقه من قِبل شركة ناشئة بنفس الاسم "DeepSeek".
التطبيق مش مجرد منصة ذكاء اصطناعي عادية، بل هو حالة جديدة تمامًا غيّرت مفهوم المنافسة. قدر "DeepSeek" يتصدر قائمة التطبيقات الأكثر تحميلًا في دول مثل أمريكا، أستراليا، كندا، وسنغافورة، خلال وقت قياسي من إطلاقه. حتى الشركة المطورة عانت من انقطاعات في موقعها بسبب الضغط الكبير من المستخدمين، وهذا دليل إنه مش مجرد نجاح عابر، بل حالة هوس حقيقية.
الميزة الأبرز في "DeepSeek" هي إنه مجاني تمامًا، بعكس اشتراكات ChatGPT اللي تصل لـ200 دولار شهريًا في باقة "ChatGPT Pro". وهذا خلاه يدخل منافسة مباشرة مع التطبيقات العملاقة مثل ChatGPT من OpenAI و"Llama" من Meta. الشركة كمان أطلقت نموذج الذكاء الاصطناعي الخاص بها R1 باستخدام طرق تدريب مبتكرة وتكاليف أقل بكثير من المنافسين.
الشركة الصينية أعلنت إن تكلفة تدريب نموذج R1 بلغت فقط 5.6 مليون دولار، وهو مبلغ بسيط جدًا مقارنة بمئات الملايين اللي تصرفها شركات مثل OpenAI. السر مش بس في التكاليف، بل في طريقة التدريب نفسها. "DeepSeek" استخدمت تقنيات مش محتاجة قوة معالجة ضخمة، وبهذا قللت التكلفة بشكل كبير. حتى الشركات المنافسة مثل Meta بدأت تتساءل: "كيف هذا النموذج يحقق الأداء هذا بالتكلفة البسيطة؟"، وبدأوا يعملوا فرق مختصة لتحليل البيانات اللي استخدمتها "DeepSeek".
الميزة اللي خطفت الأنظار في "DeepSeek" هي خاصية "DeepThink"، اللي تخليك تشوف كيف النموذج يفكر قبل ما يعطيك الجواب. كأنك تشوف روبوت يناقشك بصوت عالي. المستخدم مش بس يأخذ الإجابة، لكنه يتابع خطوات التحليل، وبهذا يخلق تجربة تفاعلية ما لها مثيل. كمان التطبيق يتميز بواجهة بسيطة وسهلة، سواء كنت تستخدمه على الهاتف أو الكمبيوتر، وبهذا صار مناسب لأي شخص.
رغم هذا النجاح، "DeepSeek" يواجه بعض التحديات. مثلًا، ما وصل لمستوى ChatGPT في تحليل الصور أو تقديم إجابات عن المحتوى البصري. صحيح تقدر ترفع صورة وتنسخ النصوص منها، لكن لو سألت التطبيق عن دلالة الصورة أو محتواها، ما بتلاقي الإجابة اللي تبحث عنها. في المقابل، ChatGPT متفوق في هذا الجانب، وكمان في التفاعل الصوتي وتصميم الصور.
لكن هل كل الناس تحتاج هذه الميزات المتقدمة؟ أغلب المستخدمين يدوروا على منصة تساعدهم في كتابة النصوص، البرمجة، والبحث السريع. وهذا بالضبط اللي يقدمه "DeepSeek"، وببلاش كمان، وهذا السبب الرئيسي في نجاحه السريع.
نجاح "DeepSeek" مش بس كان إنجاز تقني، لكنه زعزع السوق العالمي، خاصة سوق البورصة الأمريكي. بمجرد ما بدأ التطبيق الصيني يسيطر على المشهد، أسهم التكنولوجيا في أمريكا تأثرت بشكل كبير. حتى شركات تصنيع الرقائق مثل Nvidia خسرت أكثر من 13% من قيمة أسهمها. كان هذا صدمة للسوق، خاصة إن Nvidia تعتبر العمود الفقري لصناعة الذكاء الاصطناعي.
رغم القيود اللي فرضتها أمريكا على الشركات الصينية، الصين حولت هذه العقبات إلى فرص. لما حرمت أمريكا الشركات الصينية من شراء رقائق متطورة مثل Nvidia A100 وH100، كان يبدو هذا ضربة قوية. لكن الصين بدل ما تستسلم، طورت تقنيات جديدة تعتمد على رقائق أقل قوة، لكنها أكثر كفاءة وتستهلك طاقة أقل. النتيجة؟ تدريب نموذج R1 بتكلفة 5.6 مليون دولار فقط، مقارنة بمئات الملايين اللي تصرفها OpenAI.
هذه الخطوة كانت ضربة موجعة لأمريكا، اللي كانت تراهن على إن القيود هذه راح تضعف المنافسة الصينية. لكن العكس صار، والصين أثبتت إنها مش محتاجة رقائق متطورة لتحقيق نفس النتائج.
في الأخير، "DeepSeek" مش مجرد تطبيق ذكاء اصطناعي، بل مثال حي على كيف الابتكار والكفاءة ممكن يعيدوا تشكيل السوق. النجاح هذا يثبت إن الصين مش بس تنافس، لكنها تصنع قواعد جديدة للعبة. الشركات العملاقة مثل ChatGPT لازم تعيد حساباتها: هل تقدر تبقى في المقدمة لما المنافس يقدم نفس الإمكانيات وببلاش؟ يبدو إن المستقبل صيني!
التطبيق مش مجرد منصة ذكاء اصطناعي عادية، بل هو حالة جديدة تمامًا غيّرت مفهوم المنافسة. قدر "DeepSeek" يتصدر قائمة التطبيقات الأكثر تحميلًا في دول مثل أمريكا، أستراليا، كندا، وسنغافورة، خلال وقت قياسي من إطلاقه. حتى الشركة المطورة عانت من انقطاعات في موقعها بسبب الضغط الكبير من المستخدمين، وهذا دليل إنه مش مجرد نجاح عابر، بل حالة هوس حقيقية.
الميزة الأبرز في "DeepSeek" هي إنه مجاني تمامًا، بعكس اشتراكات ChatGPT اللي تصل لـ200 دولار شهريًا في باقة "ChatGPT Pro". وهذا خلاه يدخل منافسة مباشرة مع التطبيقات العملاقة مثل ChatGPT من OpenAI و"Llama" من Meta. الشركة كمان أطلقت نموذج الذكاء الاصطناعي الخاص بها R1 باستخدام طرق تدريب مبتكرة وتكاليف أقل بكثير من المنافسين.
الشركة الصينية أعلنت إن تكلفة تدريب نموذج R1 بلغت فقط 5.6 مليون دولار، وهو مبلغ بسيط جدًا مقارنة بمئات الملايين اللي تصرفها شركات مثل OpenAI. السر مش بس في التكاليف، بل في طريقة التدريب نفسها. "DeepSeek" استخدمت تقنيات مش محتاجة قوة معالجة ضخمة، وبهذا قللت التكلفة بشكل كبير. حتى الشركات المنافسة مثل Meta بدأت تتساءل: "كيف هذا النموذج يحقق الأداء هذا بالتكلفة البسيطة؟"، وبدأوا يعملوا فرق مختصة لتحليل البيانات اللي استخدمتها "DeepSeek".
الميزة اللي خطفت الأنظار في "DeepSeek" هي خاصية "DeepThink"، اللي تخليك تشوف كيف النموذج يفكر قبل ما يعطيك الجواب. كأنك تشوف روبوت يناقشك بصوت عالي. المستخدم مش بس يأخذ الإجابة، لكنه يتابع خطوات التحليل، وبهذا يخلق تجربة تفاعلية ما لها مثيل. كمان التطبيق يتميز بواجهة بسيطة وسهلة، سواء كنت تستخدمه على الهاتف أو الكمبيوتر، وبهذا صار مناسب لأي شخص.
رغم هذا النجاح، "DeepSeek" يواجه بعض التحديات. مثلًا، ما وصل لمستوى ChatGPT في تحليل الصور أو تقديم إجابات عن المحتوى البصري. صحيح تقدر ترفع صورة وتنسخ النصوص منها، لكن لو سألت التطبيق عن دلالة الصورة أو محتواها، ما بتلاقي الإجابة اللي تبحث عنها. في المقابل، ChatGPT متفوق في هذا الجانب، وكمان في التفاعل الصوتي وتصميم الصور.
لكن هل كل الناس تحتاج هذه الميزات المتقدمة؟ أغلب المستخدمين يدوروا على منصة تساعدهم في كتابة النصوص، البرمجة، والبحث السريع. وهذا بالضبط اللي يقدمه "DeepSeek"، وببلاش كمان، وهذا السبب الرئيسي في نجاحه السريع.
نجاح "DeepSeek" مش بس كان إنجاز تقني، لكنه زعزع السوق العالمي، خاصة سوق البورصة الأمريكي. بمجرد ما بدأ التطبيق الصيني يسيطر على المشهد، أسهم التكنولوجيا في أمريكا تأثرت بشكل كبير. حتى شركات تصنيع الرقائق مثل Nvidia خسرت أكثر من 13% من قيمة أسهمها. كان هذا صدمة للسوق، خاصة إن Nvidia تعتبر العمود الفقري لصناعة الذكاء الاصطناعي.
رغم القيود اللي فرضتها أمريكا على الشركات الصينية، الصين حولت هذه العقبات إلى فرص. لما حرمت أمريكا الشركات الصينية من شراء رقائق متطورة مثل Nvidia A100 وH100، كان يبدو هذا ضربة قوية. لكن الصين بدل ما تستسلم، طورت تقنيات جديدة تعتمد على رقائق أقل قوة، لكنها أكثر كفاءة وتستهلك طاقة أقل. النتيجة؟ تدريب نموذج R1 بتكلفة 5.6 مليون دولار فقط، مقارنة بمئات الملايين اللي تصرفها OpenAI.
هذه الخطوة كانت ضربة موجعة لأمريكا، اللي كانت تراهن على إن القيود هذه راح تضعف المنافسة الصينية. لكن العكس صار، والصين أثبتت إنها مش محتاجة رقائق متطورة لتحقيق نفس النتائج.
في الأخير، "DeepSeek" مش مجرد تطبيق ذكاء اصطناعي، بل مثال حي على كيف الابتكار والكفاءة ممكن يعيدوا تشكيل السوق. النجاح هذا يثبت إن الصين مش بس تنافس، لكنها تصنع قواعد جديدة للعبة. الشركات العملاقة مثل ChatGPT لازم تعيد حساباتها: هل تقدر تبقى في المقدمة لما المنافس يقدم نفس الإمكانيات وببلاش؟ يبدو إن المستقبل صيني!
Forwarded from InfoTechnology (IT4_2024) (Ahmed_Askar)
الناس اللي مهتمة ب SQL هذي Cheat sheet بتوضحلنا الفرق بين انواع الJOINS في SQL
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
شوف يا صاحبي، لما نقول "تصميم السيستم" للتاسك اللي عندك، فاحنا بنتكلم عن كيف بتنظم وتنفذ الأمور الفنية عشان تحقق المطلوب بأفضل طريقة ممكنة! ⚡🎯
في تحليل النظام، بتفكر كيف المستخدم بيتعامل مع الفيتشر وكيف السيستم بيخدمه، لكن هنا الموضوع أعمق، انت بتنزل على الأرض وتشوف كيف بتنفذ الشغل فعليًا. 🛠️💻
لو التاسك تخص ويب أبليكيشن:
🔹 الشاشة: هل تحتاج popup أو drop-down list؟ هل الإدخال بيكون سطر واحد ولا أكثر؟
🔹 الفرونت إند: هل نعملها كمكون واحد أو عدة مكونات؟ هل نستخدم State Management؟ وكيف نربطها بالـ API؟
وإذا كنت بتسلم التاسك لحد ثاني، ممكن تستخدم أدوات زي Figma أو Adobe XD عشان ترسم الشاشة وتوضح فكرتك بصريًا! 🎨📐
الـ Backend & Database
🔸 الـ Database: كيف شكل الجداول؟ إيش العلاقات بينها؟ إيش أنواع البيانات المناسبة؟
🔸 الخوارزميات: لو فيها تعقيد، يفضل تكتب Pseudo Code عشان تسهل الفهم للمبرمج قبل ما يبدأ الشغل! 📝
الـ API
✅ كيف بيكون شكل الـ API؟
✅ إيش اسم الـ Endpoint؟
✅ إيش البيانات اللي بيستقبلها وبيرجعها؟
الموضوع ما يكون عشوائي! لازم كل تاسك تتبع التصميم العام للسيستم (Architecture)، لأنه فيه أشياء تم تحديدها مسبقًا، مثل:
🔹 نوع قواعد البيانات المستخدمة (Relational or NoSQL).
🔹 هل الباك إند مبني على REST API ولا Web Services؟
🔹 كيف معماريته؟ (مثلاً Microservices أو Monolith).
🔹 كيف بيتم التعامل مع Logging, Authentication, Background Jobs؟
🔹 التكنولوجيا المستخدمة في الفرونت إند وكيف هيكلتها؟
🔹 كيف بيتم التكامل مع جهات خارجية (Integration)؟
🔹 كيف نحسن الأداء؟ هل نستخدم Caching, Message Queue؟
🔹 هل الاستضافة على سيرفرات داخلية، خارجية، ولا كلاود؟ 🌍☁️
بصراحة، أنا واثق إنك بتعمل كل هذا بدون ما تحس، وبتطبق تحليل النظام وتصميمه يوميًا، بس الفرق إنك ما كنت مسميه بـ "System Design"! 😉🔥
في تحليل النظام، بتفكر كيف المستخدم بيتعامل مع الفيتشر وكيف السيستم بيخدمه، لكن هنا الموضوع أعمق، انت بتنزل على الأرض وتشوف كيف بتنفذ الشغل فعليًا. 🛠️💻
لو التاسك تخص ويب أبليكيشن:
🔹 الشاشة: هل تحتاج popup أو drop-down list؟ هل الإدخال بيكون سطر واحد ولا أكثر؟
🔹 الفرونت إند: هل نعملها كمكون واحد أو عدة مكونات؟ هل نستخدم State Management؟ وكيف نربطها بالـ API؟
وإذا كنت بتسلم التاسك لحد ثاني، ممكن تستخدم أدوات زي Figma أو Adobe XD عشان ترسم الشاشة وتوضح فكرتك بصريًا! 🎨📐
الـ Backend & Database
🔸 الـ Database: كيف شكل الجداول؟ إيش العلاقات بينها؟ إيش أنواع البيانات المناسبة؟
🔸 الخوارزميات: لو فيها تعقيد، يفضل تكتب Pseudo Code عشان تسهل الفهم للمبرمج قبل ما يبدأ الشغل! 📝
الـ API
✅ كيف بيكون شكل الـ API؟
✅ إيش اسم الـ Endpoint؟
✅ إيش البيانات اللي بيستقبلها وبيرجعها؟
الموضوع ما يكون عشوائي! لازم كل تاسك تتبع التصميم العام للسيستم (Architecture)، لأنه فيه أشياء تم تحديدها مسبقًا، مثل:
🔹 نوع قواعد البيانات المستخدمة (Relational or NoSQL).
🔹 هل الباك إند مبني على REST API ولا Web Services؟
🔹 كيف معماريته؟ (مثلاً Microservices أو Monolith).
🔹 كيف بيتم التعامل مع Logging, Authentication, Background Jobs؟
🔹 التكنولوجيا المستخدمة في الفرونت إند وكيف هيكلتها؟
🔹 كيف بيتم التكامل مع جهات خارجية (Integration)؟
🔹 كيف نحسن الأداء؟ هل نستخدم Caching, Message Queue؟
🔹 هل الاستضافة على سيرفرات داخلية، خارجية، ولا كلاود؟ 🌍☁️
بصراحة، أنا واثق إنك بتعمل كل هذا بدون ما تحس، وبتطبق تحليل النظام وتصميمه يوميًا، بس الفرق إنك ما كنت مسميه بـ "System Design"! 😉🔥
عايز اقلك الأيام دي ال microservices بقى ترند بس بص لا يحقق مبدأ ال microservices الا قله فموضوعه ليس فصل كل bounded context في micro ولا اتصال بين micros عن طريق http فهذا لا يعتبر microservices
كلامك صحيح 100%! 💯 الناس فاهمة الـ Microservices غلط، ويعتقدوا إنه مجرد تقسيم السيستم إلى خدمات صغيرة (Micro) وربطها ببعض عن طريق HTTP APIs، لكن الحقيقة إنه فيه فرق كبير بين Microservices كترند وبين Microservices كمفهوم معماري حقيقي. 🚀
أخطاء شائعة في فهم الـ Microservices
1️⃣ أي حد يفصل Bounded Context في Service يعتقد أنه Microservices!
→ الفصل لوحده مش كفاية، لازم يكون فيه استقلالية حقيقية لكل خدمة.
2️⃣ التواصل بين الخدمات عن طريق HTTP فقط
→ هذا يخلي السيستم أقرب إلى Distributed Monolith مش Microservices! لأن الخدمات بتعتمد على بعضها بشكل قوي وبتسبب Bottlenecks في الأداء.
3️⃣ عدم التفكير في الاستقلالية التامة لكل Microservice
→ إذا كانت الخدمات تحتاج تحدث نفس الداتابيز، أو تعتمد على بعضها بشكل متكرر، فأنت رجعت لـ Monolith لكن بشكل معقد أكتر! 😅
المفهوم الحقيقي للـ Microservices
✅ كل خدمة مستقلة ذاتيًا: عندها قاعدة بيانات خاصة وما تحتاج تسأل خدمة ثانية مباشرة عبر HTTP عشان تشتغل.
✅ التواصل يكون Event-driven: بدل ما الخدمات تتصل ببعض بشكل مباشر، تستخدم Message Queue (Kafka, RabbitMQ, SQS, etc.) بحيث تكون Loosely Coupled.
✅ كل خدمة تقدر تتطور وتنشر لوحدها: بدون ما تأثر على باقي النظام.
✅ إدارة الخدمات تحتاج أدوات قوية: زي Service Discovery, API Gateway, Circuit Breakers عشان تتجنب الفشل في خدمة وحدة يوقف السيستم كله.
الحقيقة اللي قليل اللي يفهمها
🔹 أغلب المشاريع ما تحتاج Microservices من الأساس، لأن تطبيقها صح مكلف جدًا ومعقد، ولو السيستم مش ضخم، ممكن يكون الـ Modular Monolith حل أفضل بكثير.
🔹 أغلب المشاريع اللي بتسمي نفسها Microservices، هي في الحقيقة Distributed Monolith، لأن الخدمات معتمدة على بعض بقوة وما فيها استقلالية فعلية.
يعني لو السيستم يحتاج كل الخدمات تشتغل مع بعض في نفس اللحظة عشان أي Feature يشتغل، فأنت ما عندك Microservices، عندك Monolith موزع بس! 💣😆
أخطاء شائعة في فهم الـ Microservices
1️⃣ أي حد يفصل Bounded Context في Service يعتقد أنه Microservices!
→ الفصل لوحده مش كفاية، لازم يكون فيه استقلالية حقيقية لكل خدمة.
2️⃣ التواصل بين الخدمات عن طريق HTTP فقط
→ هذا يخلي السيستم أقرب إلى Distributed Monolith مش Microservices! لأن الخدمات بتعتمد على بعضها بشكل قوي وبتسبب Bottlenecks في الأداء.
3️⃣ عدم التفكير في الاستقلالية التامة لكل Microservice
→ إذا كانت الخدمات تحتاج تحدث نفس الداتابيز، أو تعتمد على بعضها بشكل متكرر، فأنت رجعت لـ Monolith لكن بشكل معقد أكتر! 😅
المفهوم الحقيقي للـ Microservices
✅ كل خدمة مستقلة ذاتيًا: عندها قاعدة بيانات خاصة وما تحتاج تسأل خدمة ثانية مباشرة عبر HTTP عشان تشتغل.
✅ التواصل يكون Event-driven: بدل ما الخدمات تتصل ببعض بشكل مباشر، تستخدم Message Queue (Kafka, RabbitMQ, SQS, etc.) بحيث تكون Loosely Coupled.
✅ كل خدمة تقدر تتطور وتنشر لوحدها: بدون ما تأثر على باقي النظام.
✅ إدارة الخدمات تحتاج أدوات قوية: زي Service Discovery, API Gateway, Circuit Breakers عشان تتجنب الفشل في خدمة وحدة يوقف السيستم كله.
الحقيقة اللي قليل اللي يفهمها
🔹 أغلب المشاريع ما تحتاج Microservices من الأساس، لأن تطبيقها صح مكلف جدًا ومعقد، ولو السيستم مش ضخم، ممكن يكون الـ Modular Monolith حل أفضل بكثير.
🔹 أغلب المشاريع اللي بتسمي نفسها Microservices، هي في الحقيقة Distributed Monolith، لأن الخدمات معتمدة على بعض بقوة وما فيها استقلالية فعلية.
يعني لو السيستم يحتاج كل الخدمات تشتغل مع بعض في نفس اللحظة عشان أي Feature يشتغل، فأنت ما عندك Microservices، عندك Monolith موزع بس! 💣😆
بالضبط! 🔥 gRPC هو واحد من أفضل الحلول للتواصل بين Microservices بدل HTTP التقليدي، خاصة إذا كنت مضطر تستخدم Synchronous Communication بين الخدمات. 🚀
لماذا gRPC أفضل من REST في Microservices؟
✅ أداء عالي جدًا: لأنه يعتمد على HTTP/2، مما يسمح بضغط البيانات وتحسين الاتصال، عكس REST اللي يستخدم HTTP/1.1.
✅ إرسال واستقبال البيانات بسرعة أكبر: يستخدم Protocol Buffers (Protobuf) بدل JSON، مما يجعله أسرع وأخف في نقل البيانات.
✅ اتصال ثنائي الاتجاه (Bi-directional Streaming): يقدر يرسل ويستقبل بيانات في نفس الوقت، عكس REST اللي يعتمد على Request-Response فقط.
✅ أفضل دعم للـ Strong Typing: لأن الـ Protobuf يحدد Schema قوي للبيانات، مما يقلل الأخطاء في التواصل.
✅ استهلاك موارد أقل: بسبب تقليل الـ Overhead في الاتصال، مما يجعله أخف على الشبكة وأسرع في الأداء.
متى تستخدم gRPC؟
🔹 لما يكون عندك Microservices تحتاج تتواصل ببعض بشكل سريع وفعال.
🔹 لما يكون عندك High Throughput System يحتاج سرعة استجابة عالية جدًا.
🔹 لما تحتاج Streaming أو Real-time Communication.
🔹 لما يكون عندك بيئة Polyglot (لغات مختلفة)، لأن gRPC مدعوم في C#, Java, Go, Python وغيرها.
متى لا تستخدم gRPC؟
❌ لو كنت بتعمل API للـ Frontend (Web أو Mobile)، لأن المتصفحات ما تدعم gRPC بالكامل حتى الآن.
❌ لو كنت تتعامل مع بيئات ضعيفة في الاتصال (زي شبكات الموبايل) لأن HTTP/2 ممكن يكون أكثر استهلاكًا في بعض الحالات.
الخلاصة
لو عندك Microservices وتحتاج بروتوكول سريع وكفؤ؟ gRPC هو الحل الأمثل! 🚀
لكن لو API موجه للـ Frontend، يفضل REST أو GraphQL حسب الحاجة. 😉
بالتوفيق
لماذا gRPC أفضل من REST في Microservices؟
✅ أداء عالي جدًا: لأنه يعتمد على HTTP/2، مما يسمح بضغط البيانات وتحسين الاتصال، عكس REST اللي يستخدم HTTP/1.1.
✅ إرسال واستقبال البيانات بسرعة أكبر: يستخدم Protocol Buffers (Protobuf) بدل JSON، مما يجعله أسرع وأخف في نقل البيانات.
✅ اتصال ثنائي الاتجاه (Bi-directional Streaming): يقدر يرسل ويستقبل بيانات في نفس الوقت، عكس REST اللي يعتمد على Request-Response فقط.
✅ أفضل دعم للـ Strong Typing: لأن الـ Protobuf يحدد Schema قوي للبيانات، مما يقلل الأخطاء في التواصل.
✅ استهلاك موارد أقل: بسبب تقليل الـ Overhead في الاتصال، مما يجعله أخف على الشبكة وأسرع في الأداء.
متى تستخدم gRPC؟
🔹 لما يكون عندك Microservices تحتاج تتواصل ببعض بشكل سريع وفعال.
🔹 لما يكون عندك High Throughput System يحتاج سرعة استجابة عالية جدًا.
🔹 لما تحتاج Streaming أو Real-time Communication.
🔹 لما يكون عندك بيئة Polyglot (لغات مختلفة)، لأن gRPC مدعوم في C#, Java, Go, Python وغيرها.
متى لا تستخدم gRPC؟
❌ لو كنت بتعمل API للـ Frontend (Web أو Mobile)، لأن المتصفحات ما تدعم gRPC بالكامل حتى الآن.
❌ لو كنت تتعامل مع بيئات ضعيفة في الاتصال (زي شبكات الموبايل) لأن HTTP/2 ممكن يكون أكثر استهلاكًا في بعض الحالات.
الخلاصة
لو عندك Microservices وتحتاج بروتوكول سريع وكفؤ؟ gRPC هو الحل الأمثل! 🚀
لكن لو API موجه للـ Frontend، يفضل REST أو GraphQL حسب الحاجة. 😉
بالتوفيق
عندما تفكر في أن تصبح معيدًا أو معيدة في الجامعة أو أي مؤسسة أكاديمية، خاصة هنا في اليمن، تذكر الوضع الذي تعاني منه اليوم كطالب. عندما يحين دورك لتوزيع الدرجات، كن عادلاً، منصفًا، وراعِ ظروف الطلاب. لا تكن متحجرًا أكاديميًا بلا داعٍ، ولا تجعل المادة مجرد عقبة في طريقهم. ساعدهم على الفهم الحقيقي بدلًا من التركيز على التعقيد والدرجات فقط.
لا تكتفِ بشرح الشرائح والعروض النظرية التي قد لا تفيدهم في واقعهم العملي، بل قدم لهم ما ينفعهم فعلًا، وما يمكن أن يساعدهم في مسيرتهم المستقبلية. إذا كنت تمتلك معرفة أو خبرة يمكن أن تختصر عليهم الطريق، فلا تبخل بها، بل كن مرشدًا ودليلًا حقيقيًا لهم.
ولا تأتِ لتقول: "أنا ملتزم بالستاند الأكاديمي" وكأنك مجرد ناقل للمقرر! هناك أساتذة أكفاء لا يلتزمون حرفيًا بهذه القواعد الجامدة، ومع ذلك يتركون بصمة إيجابية في حياة طلابهم. وأنت تعلم جيدًا أن بعض الطلاب يضطرون للبحث عن دكتور يسهل عليهم الأمور، ليس لأنهم لا يريدون التعلم، بل لأن البعض يجعل النجاح صعبًا بلا سبب!
في اليمن، نعلم جميعًا أن توزيع الدرجات قد يكون ظالمًا في بعض الأحيان، وبعض الأساتذة يضعون العراقيل أمام الطلاب دون مراعاة للظروف التي يعيشونها. لا تكن واحدًا منهم! كن ذلك المعيد الذي يتذكر كيف كان يعاني كطالب، ويساعد الطلاب كما كان يتمنى أن يساعده أحدهم يومًا ما.
تذكر دائمًا: الجامعة ليست مجرد مقررات ومحاضرات، بل هي بيئة لبناء العقول وصناعة الفرق. بعض الدكاترة يسعون إلى "تخريج الطلاب"، بينما آخرون يركزون فقط على "تكديس المعلومات" وتعقيد الأمور بلا فائدة. فكن من النوع الأول، كن ممن يسهل العلم، ويمهد الطريق للطلاب، لأن العلم رسالة، وليس مجرد وظيفة!
لا تكتفِ بشرح الشرائح والعروض النظرية التي قد لا تفيدهم في واقعهم العملي، بل قدم لهم ما ينفعهم فعلًا، وما يمكن أن يساعدهم في مسيرتهم المستقبلية. إذا كنت تمتلك معرفة أو خبرة يمكن أن تختصر عليهم الطريق، فلا تبخل بها، بل كن مرشدًا ودليلًا حقيقيًا لهم.
ولا تأتِ لتقول: "أنا ملتزم بالستاند الأكاديمي" وكأنك مجرد ناقل للمقرر! هناك أساتذة أكفاء لا يلتزمون حرفيًا بهذه القواعد الجامدة، ومع ذلك يتركون بصمة إيجابية في حياة طلابهم. وأنت تعلم جيدًا أن بعض الطلاب يضطرون للبحث عن دكتور يسهل عليهم الأمور، ليس لأنهم لا يريدون التعلم، بل لأن البعض يجعل النجاح صعبًا بلا سبب!
في اليمن، نعلم جميعًا أن توزيع الدرجات قد يكون ظالمًا في بعض الأحيان، وبعض الأساتذة يضعون العراقيل أمام الطلاب دون مراعاة للظروف التي يعيشونها. لا تكن واحدًا منهم! كن ذلك المعيد الذي يتذكر كيف كان يعاني كطالب، ويساعد الطلاب كما كان يتمنى أن يساعده أحدهم يومًا ما.
تذكر دائمًا: الجامعة ليست مجرد مقررات ومحاضرات، بل هي بيئة لبناء العقول وصناعة الفرق. بعض الدكاترة يسعون إلى "تخريج الطلاب"، بينما آخرون يركزون فقط على "تكديس المعلومات" وتعقيد الأمور بلا فائدة. فكن من النوع الأول، كن ممن يسهل العلم، ويمهد الطريق للطلاب، لأن العلم رسالة، وليس مجرد وظيفة!
❤4
هل تدري إن الجذور الحقيقية لشركة 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 اللي مهيمنة اليومين هذه هي مجرد شركة جديدة، أحب أقولك إن جذورها أقدم من كذا، وهي مبنية على أبحاث وتجارب سنوات طويلة وعقول فاهـمة ومعافرة في عالم البيزنس الحقيقي ومرت بتحديات كبيرة.
مافيش شيء يجي بالساهل.
اعمل شير حتى نكسر الجهل والأوهام.
الحمد لله.
#للمعرفة
في ذاك الوقت كان هناك 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 اللي مهيمنة اليومين هذه هي مجرد شركة جديدة، أحب أقولك إن جذورها أقدم من كذا، وهي مبنية على أبحاث وتجارب سنوات طويلة وعقول فاهـمة ومعافرة في عالم البيزنس الحقيقي ومرت بتحديات كبيرة.
مافيش شيء يجي بالساهل.
اعمل شير حتى نكسر الجهل والأوهام.
الحمد لله.
#للمعرفة
🔥1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
الاختبارات النهائية قبل رمضان 🚦🔭
هناك مثل أجنبي يقول: "إذا كانت الأداة التي في يدك مطرقة، فسترى كل شيء مسامير!"
لكن هنا الفكرة ليست في أن ترى كل شيء مطرقة! لا تتعامل مع الـ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!
📝 ملاحظة أخيرة، لا تظنوا أنني أنتقد بالعكس.
الرسالة: حافظ على بساطة الكود وتجنب التعقيد الزائد، فهذا هو الذي سيخدم المستخدمين بشكل أفضل. 💥
هناك مثل أجنبي يقول: "إذا كانت الأداة التي في يدك مطرقة، فسترى كل شيء مسامير!"
لكن هنا الفكرة ليست في أن ترى كل شيء مطرقة! لا تتعامل مع الـ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:1)، عند إرسال رسالة، يظهر: علامة واحدة (✓): تعني أن الرسالة وصلت إلى جهاز المستلم. علامتان (✓✓): تعني أن المستلم فتح التطبيق وقرأ الرسالة. تيليجرام يحدد ذلك عبر آلية تأكيد القراءة، حيث يرسل التطبيق عند فتح الرسالة إشعارًا (Acknowledgment) إلى خوادم تيليجرام بأن المستخدم شاهدها. 2. آلية قراءة الرسائل في المجموعات في المجموعات الصغيرة، يمكن الضغط على الرسالة لمعرفة من قرأها. في المجموعات الكبيرة، تيليجرام لا يعرض من قرأ الرسالة ولكنه يحتفظ بمؤشر زمني يحدد آخر مرة كان فيها المستخدم نشطًا، مما يمكن استخدامه لتقدير عدد الأشخاص الذين قرأوها. الآلية هنا تعتمد على التخزين المؤقت (Cache) وتحليل بيانات التفاعل، حيث يتم تحديث حالة الرسالة بناءً على نشاط المستخدمين. 3. آلية قراءة الرسائل في القنوات في القنوات، يظهر عدد المشاهدات بجانب كل رسالة، ولكن هذا الرقم لا يمثل المستخدمين الفريدين فقط، بل يشمل: عدد المرات التي تم فيها عرض الرسالة (حتى لو كان من نفس المستخدم). إعادة التوجيهات (Forwarding) تُحتسب أيضًا كمشاهدات جديدة. تيليجرام يستخدم آلية تعقب على مستوى الخادم تقوم بتحديث العداد عند فتح الرسالة من قبل أي مستخدم، ويستخدم التخزين الموزع لضمان عدم احتساب نفس المستخدم أكثر من مرة عند القراءة من أجهزة متعددة. 4. الخوارزميات المستخدمة نظام تأكيد القراءة (Read Receipts): يعتمد على إشارات من العميل (Client) إلى الخادم. تحليل النشاط عبر الجلسات (Session Tracking): يتتبع متى وأين تم فتح الرسائل. آلية التخزين المؤقت (Cache System): لمنع التحديث الفوري لكل مشاهدة وتقليل الحمل على الخوادم. تحديد المشاهدات الفريدة (Unique Viewers Detection): يتم استخدام خوارزميات مثل Fingerprinting وSession Correlation لمنع التكرار في عدّ المشاهدات. هل لديك استفسار عن جزء معين بشكل أعمق؟
👍1