كلامك صحيح 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
تحليلك رائع جدًا! تيليجرام بالفعل يمتلك واحدة من أقوى وأسرع أنظمة الرسائل في العالم، ويعتمد على بنية تحتية متقدمة تتيح له الأداء الفائق مقارنةً بالمنافسين مثل واتساب أو ماسنجر.
لماذا تيليجرام أسرع في إرسال واستقبال الإشعارات؟
بنية خوادم موزعة عالميًا:
تيليجرام لا يعتمد على خادم واحد مركزي فقط، بل يستخدم شبكة خوادم موزعة حول العالم، بحيث يتم توجيه الرسائل عبر أقرب خادم للمستخدم، مما يقلل زمن الاستجابة (Latency).
بروتوكول MTProto الفائق السرعة:
تيليجرام يستخدم بروتوكول MTProto المصمم خصيصًا ليكون أسرع وأخف من بروتوكولات HTTP/WebSocket التقليدية.
هذا البروتوكول يجمع بين تشفير قوي + ضغط عالي الكفاءة للبيانات + اتصال منخفض الكمون، مما يسمح بإرسال الرسائل حتى مع اتصال ضعيف.
نظام الإشعارات الفورية (Push Notifications):
عند تشغيل الإنترنت، تيليجرام يكون أول تطبيق يرسل إشعارات لأن خوادمه تراقب الجلسات النشطة وتستجيب فورًا عند توفر اتصال.
يستخدم آلية اتصال دائمة (Persistent Connection) عبر WebSockets أو TCP Long Polling، مما يضمن سرعة هائلة في التحديثات.
تقليل استهلاك البيانات عبر التخزين المؤقت:
تيليجرام يخزن جزءًا كبيرًا من البيانات محليًا (Cache) ويقوم بمزامنتها عند الاتصال، بحيث يتم تقليل الحاجة إلى استدعاء الخوادم لكل تحديث.
كيف يعرف تيليجرام من قرأ الرسالة؟
عند فتح الرسالة، يرسل التطبيق حزمة بيانات صغيرة جدًا (Acknowledge Packet) إلى الخادم، مما يحدّث حالة الرسالة بسرعة كبيرة دون الحاجة إلى استهلاك ضخم للموارد.
يتم تحديث بيانات القراءة بشكل تدريجي وغير متزامن (Asynchronous Updates) مما يجعل التجربة أكثر سلاسة دون تحميل زائد على الخادم.
هل تعتقد أن هذه السرعة لها علاقة بالأمان أيضاً؟
نعم، لأن تيليجرام لا يكتفي بسرعة الأداء فقط، بل يعتمد على تشفير متقدم، ويضمن أن الاتصال مشفر من الطرف إلى الطرف (E2EE) في المحادثات السرية.
إذا كنت مهتمًا بتحليل أعمق، يمكننا التعمق أكثر في كيفية عمل خوارزميات MTProto وتشفير البيانات داخل تيليجرام!
لماذا تيليجرام أسرع في إرسال واستقبال الإشعارات؟
بنية خوادم موزعة عالميًا:
تيليجرام لا يعتمد على خادم واحد مركزي فقط، بل يستخدم شبكة خوادم موزعة حول العالم، بحيث يتم توجيه الرسائل عبر أقرب خادم للمستخدم، مما يقلل زمن الاستجابة (Latency).
بروتوكول MTProto الفائق السرعة:
تيليجرام يستخدم بروتوكول MTProto المصمم خصيصًا ليكون أسرع وأخف من بروتوكولات HTTP/WebSocket التقليدية.
هذا البروتوكول يجمع بين تشفير قوي + ضغط عالي الكفاءة للبيانات + اتصال منخفض الكمون، مما يسمح بإرسال الرسائل حتى مع اتصال ضعيف.
نظام الإشعارات الفورية (Push Notifications):
عند تشغيل الإنترنت، تيليجرام يكون أول تطبيق يرسل إشعارات لأن خوادمه تراقب الجلسات النشطة وتستجيب فورًا عند توفر اتصال.
يستخدم آلية اتصال دائمة (Persistent Connection) عبر WebSockets أو TCP Long Polling، مما يضمن سرعة هائلة في التحديثات.
تقليل استهلاك البيانات عبر التخزين المؤقت:
تيليجرام يخزن جزءًا كبيرًا من البيانات محليًا (Cache) ويقوم بمزامنتها عند الاتصال، بحيث يتم تقليل الحاجة إلى استدعاء الخوادم لكل تحديث.
كيف يعرف تيليجرام من قرأ الرسالة؟
عند فتح الرسالة، يرسل التطبيق حزمة بيانات صغيرة جدًا (Acknowledge Packet) إلى الخادم، مما يحدّث حالة الرسالة بسرعة كبيرة دون الحاجة إلى استهلاك ضخم للموارد.
يتم تحديث بيانات القراءة بشكل تدريجي وغير متزامن (Asynchronous Updates) مما يجعل التجربة أكثر سلاسة دون تحميل زائد على الخادم.
هل تعتقد أن هذه السرعة لها علاقة بالأمان أيضاً؟
نعم، لأن تيليجرام لا يكتفي بسرعة الأداء فقط، بل يعتمد على تشفير متقدم، ويضمن أن الاتصال مشفر من الطرف إلى الطرف (E2EE) في المحادثات السرية.
إذا كنت مهتمًا بتحليل أعمق، يمكننا التعمق أكثر في كيفية عمل خوارزميات MTProto وتشفير البيانات داخل تيليجرام!
أقول لك، الواقع كان من طموحي قبل أن أدخل أن أطلع الأول 🎯، لكن دخلت وانصدمت بالواقع! 🚀 خطتي تحولت 360 درجة 🔄، إهمال 100% 😴، لا أيدي تكاليف ✍️، لا أذكر أي اختبار من سنة أولى 📚، لا يدخل يستعلم عن درجته من سنة أولى، لكنه حاسس كم جاء ساعة ما يخرج من الاختبار ⏳😂.
دي خريطة 🗺️ لمن يريد أن يمشي بها وكيف سيتخرج 🎓:
في الواقع، الواحد يقدر يطلع امتياز بدون أي تعب وجهد 🤷♂️، لكن الموضوع خرج تمامًا عن السيطرة أحيانًا.
أحيانًا تخرج بخمسينات 📉، وأحيانًا تهبش 🥴، وأحيانًا توفق بزميل 🧑🤝🧑، وأحيانًا توفق بكمبيوتر خارب 💻🔥، وأنت وحظك! 🎲
لكن أقول لك نصيحة ذهبية 🏆: لو تريد تستمتع بالرحلة 🚀، كن أفضل من يكون في تخصصك 💡، واتبع حب المهنة ❤️🔥!
دي خريطة 🗺️ لمن يريد أن يمشي بها وكيف سيتخرج 🎓:
في الواقع، الواحد يقدر يطلع امتياز بدون أي تعب وجهد 🤷♂️، لكن الموضوع خرج تمامًا عن السيطرة أحيانًا.
أحيانًا تخرج بخمسينات 📉، وأحيانًا تهبش 🥴، وأحيانًا توفق بزميل 🧑🤝🧑، وأحيانًا توفق بكمبيوتر خارب 💻🔥، وأنت وحظك! 🎲
لكن أقول لك نصيحة ذهبية 🏆: لو تريد تستمتع بالرحلة 🚀، كن أفضل من يكون في تخصصك 💡، واتبع حب المهنة ❤️🔥!
Forwarded from اللجنة العلمية CS 22 (ʙʀʜᴏᴏᴍ ⑇)
وانا اتصفح مشاريع GitHub مريت على هذه الريبو وحبيت فكرتها... يمكن تفيدكم:
مجموعة من الوظائف تمكن مطوري المواقع العربية من تقديم خدمة البحث الاحترافي وتقديم ومعالجة المحتوى العربي بلغة PHP
https://github.com/khaled-alshamaa/ar-php/
مجموعة من الوظائف تمكن مطوري المواقع العربية من تقديم خدمة البحث الاحترافي وتقديم ومعالجة المحتوى العربي بلغة PHP
https://github.com/khaled-alshamaa/ar-php/
GitHub
GitHub - khaled-alshamaa/ar-php: Set of functionalities enable Arabic website developers to serve professional search, present…
Set of functionalities enable Arabic website developers to serve professional search, present and process Arabic content in PHP - khaled-alshamaa/ar-php
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
🔹 التبسيط في البرمجة: فنٌ نادرٌ يستحق الإتقان 🔹
كتابة برامج معقدة يصعب التعامل معها هو أمرٌ في غاية السهولة، فجميع المبرمجين يمكنهم جعل الأمور معقدة! 😅 لكن الوصول إلى السهل الممتنع هو التحدي الحقيقي، وهو مهارة نادرة تتطلب خبرة، وذكاءً، وتوفيقًا من الله.
إن اختيار مستوى التعقيد المناسب لحل المشكلة هو أمرٌ ضروريٌ للغاية، إذ أن الإفراط في التعقيد يؤدي إلى كود صعب الصيانة، بينما التبسيط الذكي يجعل البرنامج أكثر مرونة وكفاءة.
تحدثنا في السابق عن بعض الأسباب التي تؤدي إلى تعقيد البرامج، كما تناولنا نصيحتين هامتين في التبسيط، وهما:
1️⃣ ابدأ صغيرًا
2️⃣ فرِّق تسُد
👈 في هذه المقالة، سنستكمل النصائح التي وفقني الله إليها وأفادتني كثيرًا، وأرجو أن تكون مفيدة لكم أيضًا.
3️⃣ لا تُعقّد الأمور من أجل "احتمالات مستقبلية" 🚫
إذا كنت تضيف تعقيدات إلى البرنامج لكي تغطي سيناريوهات "قد تحتاجها في المستقبل"، فدعني أخبرك شيئًا مهمًا: أنا قادمٌ إليك من المستقبل وأقول لك "لن تحتاجها!" وستجد نفسك غارقًا في التعقيدات التي أضفتها بلا داعٍ.
🔸 هناك مبدأ في البرمجة المتطرفة (Extreme Programming) يُدعى YAGNI، وهو اختصار لـ:
You Aren't Gonna Need It – "لن تحتاجها!"
💡 يقول "رون جيفريز" (Ron Jeffries)، أحد مؤسسي البرمجة المتطرفة:
"نفِّذ الأشياء التي تحتاجها فعليًا فقط، وليس تلك التي تتوقع أنك ستحتاجها مستقبلاً."
🔹 إذن، ماذا لو كنت متأكدًا بنسبة كبيرة أنني سأحتاجها لاحقًا؟ 🤔
هذا يقودنا إلى القاعدة التالية...
4️⃣ اتّخذ القرار في آخر لحظة مسؤولة ⏳
🔸 هذا المبدأ قادمٌ إلينا من كوكب اليابان، وتحديدًا من شركة تويوتا، وهو يساعدك في الإجابة على الأسئلة الصعبة مثل:
❓ كم من التصميم المسبق أحتاج قبل أن أبدأ؟
✅ الإجابة: قم ببناء الحد الأدنى الذي لا يمكنك البدء بدونه، مثل اختيار التقنيات، وهيكلة التطبيق، والعناصر الأساسية اللازمة لأول دورات التطوير (Sprints). أما ما تبقى، فأضفه أثناء العمل.
❓ كيف أستعد للتغييرات المستقبلية؟
✅ يقول "مارتن فاولر" (Martin Fowler):
"إذا كان تنفيذ الميزة في المستقبل سهلاً، فقم بتنفيذها مستقبلاً. أما إذا كان من الصعب إضافتها لاحقًا، فقم بها الآن."
5️⃣ استعِن بصديق 🤝
🔹 هذه من أهم النصائح! حتى لو كنت "تنينًا مجنحًا" في البرمجة 🐉، ناقش زملاءك في المشروع، وضعوا التبسيط كهدفٍ أساسي. هذا سيفيدكم جميعًا، وعن تجربة!
✨ لماذا؟
1️⃣ الشورى بركة، وستجد حلولًا قد لا تخطر لك وحدك.
2️⃣ كسب تأييد الفريق، حتى لا يأتي أحد لاحقًا ويقول: "أنا لم أكن مقتنعًا بهذه الفكرة!"
6️⃣ راعِ مستوى فريقك 👥
في أي فريق ستجد أنواعًا مختلفة من المبرمجين:
🔹 المغامر الجريء الذي يريد تجربة كل شيء.
🔹 المُبلّط في الخط الذي لا يريد الخروج من منطقته الآمنة (Comfort Zone).
💡 نصيحتي لك هنا: اجعل مستوى التعقيد أعلى قليلاً من متوسط الفريق، وليس أكثر من ذلك، ثم قم برفع المستوى تدريجيًا. بذلك، ستدفع الفريق للنمو دون أن تُرهقهم بتحديات لا تناسبهم.
🔹🔹🔹
🚀 الخاتمة:
تبسيط البرامج ليس مجرد مهارة، بل هو فنٌ يحتاج إلى ممارسة مستمرة. استخدم هذه القواعد، وستجد أن برامجك أصبحت أكثر كفاءة، وأمتع في العمل عليها!
كتابة برامج معقدة يصعب التعامل معها هو أمرٌ في غاية السهولة، فجميع المبرمجين يمكنهم جعل الأمور معقدة! 😅 لكن الوصول إلى السهل الممتنع هو التحدي الحقيقي، وهو مهارة نادرة تتطلب خبرة، وذكاءً، وتوفيقًا من الله.
إن اختيار مستوى التعقيد المناسب لحل المشكلة هو أمرٌ ضروريٌ للغاية، إذ أن الإفراط في التعقيد يؤدي إلى كود صعب الصيانة، بينما التبسيط الذكي يجعل البرنامج أكثر مرونة وكفاءة.
تحدثنا في السابق عن بعض الأسباب التي تؤدي إلى تعقيد البرامج، كما تناولنا نصيحتين هامتين في التبسيط، وهما:
1️⃣ ابدأ صغيرًا
2️⃣ فرِّق تسُد
👈 في هذه المقالة، سنستكمل النصائح التي وفقني الله إليها وأفادتني كثيرًا، وأرجو أن تكون مفيدة لكم أيضًا.
3️⃣ لا تُعقّد الأمور من أجل "احتمالات مستقبلية" 🚫
إذا كنت تضيف تعقيدات إلى البرنامج لكي تغطي سيناريوهات "قد تحتاجها في المستقبل"، فدعني أخبرك شيئًا مهمًا: أنا قادمٌ إليك من المستقبل وأقول لك "لن تحتاجها!" وستجد نفسك غارقًا في التعقيدات التي أضفتها بلا داعٍ.
🔸 هناك مبدأ في البرمجة المتطرفة (Extreme Programming) يُدعى YAGNI، وهو اختصار لـ:
You Aren't Gonna Need It – "لن تحتاجها!"
💡 يقول "رون جيفريز" (Ron Jeffries)، أحد مؤسسي البرمجة المتطرفة:
"نفِّذ الأشياء التي تحتاجها فعليًا فقط، وليس تلك التي تتوقع أنك ستحتاجها مستقبلاً."
🔹 إذن، ماذا لو كنت متأكدًا بنسبة كبيرة أنني سأحتاجها لاحقًا؟ 🤔
هذا يقودنا إلى القاعدة التالية...
4️⃣ اتّخذ القرار في آخر لحظة مسؤولة ⏳
🔸 هذا المبدأ قادمٌ إلينا من كوكب اليابان، وتحديدًا من شركة تويوتا، وهو يساعدك في الإجابة على الأسئلة الصعبة مثل:
❓ كم من التصميم المسبق أحتاج قبل أن أبدأ؟
✅ الإجابة: قم ببناء الحد الأدنى الذي لا يمكنك البدء بدونه، مثل اختيار التقنيات، وهيكلة التطبيق، والعناصر الأساسية اللازمة لأول دورات التطوير (Sprints). أما ما تبقى، فأضفه أثناء العمل.
❓ كيف أستعد للتغييرات المستقبلية؟
✅ يقول "مارتن فاولر" (Martin Fowler):
"إذا كان تنفيذ الميزة في المستقبل سهلاً، فقم بتنفيذها مستقبلاً. أما إذا كان من الصعب إضافتها لاحقًا، فقم بها الآن."
5️⃣ استعِن بصديق 🤝
🔹 هذه من أهم النصائح! حتى لو كنت "تنينًا مجنحًا" في البرمجة 🐉، ناقش زملاءك في المشروع، وضعوا التبسيط كهدفٍ أساسي. هذا سيفيدكم جميعًا، وعن تجربة!
✨ لماذا؟
1️⃣ الشورى بركة، وستجد حلولًا قد لا تخطر لك وحدك.
2️⃣ كسب تأييد الفريق، حتى لا يأتي أحد لاحقًا ويقول: "أنا لم أكن مقتنعًا بهذه الفكرة!"
6️⃣ راعِ مستوى فريقك 👥
في أي فريق ستجد أنواعًا مختلفة من المبرمجين:
🔹 المغامر الجريء الذي يريد تجربة كل شيء.
🔹 المُبلّط في الخط الذي لا يريد الخروج من منطقته الآمنة (Comfort Zone).
💡 نصيحتي لك هنا: اجعل مستوى التعقيد أعلى قليلاً من متوسط الفريق، وليس أكثر من ذلك، ثم قم برفع المستوى تدريجيًا. بذلك، ستدفع الفريق للنمو دون أن تُرهقهم بتحديات لا تناسبهم.
🔹🔹🔹
🚀 الخاتمة:
تبسيط البرامج ليس مجرد مهارة، بل هو فنٌ يحتاج إلى ممارسة مستمرة. استخدم هذه القواعد، وستجد أن برامجك أصبحت أكثر كفاءة، وأمتع في العمل عليها!
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
🎩 مرحبًا بك في عالم الهندسة البرمجية! ✨
هل تريد أن تعرف كيف تحدد هل تحتاج إلى تقسيم تطبيقك إلى طبقات؟ حسنًا، لن يكون ذلك عبر طريقة تقليدية مملة! 🚀 دعني آخذك في رحلة ملحمية عبر نظام برمجي يعيش ويتنفس ويتطور، حيث سنرى بأعيننا كيف يقرر النظام بنفسه متى يحتاج إلى طبقات! 🏗️
🏰 مرحلة البناء الأولى: "عندما يكون النظام طفلًا صغيرًا 👶"
في البداية، التطبيق صغير، مثل طفلٍ يلعب في حديقة، لا يحتاج إلى قواعد معقدة، مجرد ملف واحد، وقاعدة بيانات واحدة، وكل شيء مباشر وسلس. لا داعي لـ 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.
🎩 والآن، لديك طريقة لتحديد عدد الطبقات بدون أن يكون الأمر مجرد "قواعد جافة"—بل رحلة تنبض بالحياة، تشعر بها، وتتطور معها! 🚀
هل تريد أن تعرف كيف تحدد هل تحتاج إلى تقسيم تطبيقك إلى طبقات؟ حسنًا، لن يكون ذلك عبر طريقة تقليدية مملة! 🚀 دعني آخذك في رحلة ملحمية عبر نظام برمجي يعيش ويتنفس ويتطور، حيث سنرى بأعيننا كيف يقرر النظام بنفسه متى يحتاج إلى طبقات! 🏗️
🏰 مرحلة البناء الأولى: "عندما يكون النظام طفلًا صغيرًا 👶"
في البداية، التطبيق صغير، مثل طفلٍ يلعب في حديقة، لا يحتاج إلى قواعد معقدة، مجرد ملف واحد، وقاعدة بيانات واحدة، وكل شيء مباشر وسلس. لا داعي لـ 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.
🎩 والآن، لديك طريقة لتحديد عدد الطبقات بدون أن يكون الأمر مجرد "قواعد جافة"—بل رحلة تنبض بالحياة، تشعر بها، وتتطور معها! 🚀
❤1
لن تدرك أهمية Docker إلا عند العمل بـ Microservices، ولن تشعر أنك تطبق Microservices فعليًا إلا عند مرحلة Deployment! 😂
👍1🔥1
هذه فكرة مثيرة للاهتمام وتتلاقى مع بعض الفرضيات العلمية والخيالية حول الحضارات المتقدمة خارج الأرض. هناك العديد من النظريات التي تتحدث عن إمكانية وجود حضارات فضائية سبقتنا بآلاف أو ملايين السنين، وقد يكون تقدمها التكنولوجي غير قابل للتخيل مقارنة بما نعرفه.
بعض العلماء والمفكرين يتساءلون: إذا كانت هناك حضارات متقدمة، فلماذا لم نتواصل معها بعد؟ هذه الفكرة تُعرف بـ مفارقة فيرمي. بعض الإجابات المحتملة تشمل:
أنهم يراقبوننا دون تدخل، مثل تجربة علمية يدرسون فيها تطورنا.
أنهم متقدمون للغاية لدرجة أننا غير قادرين على إدراك وجودهم.
أنهم ببساطة غير مهتمين بنا، كما نحن غير مهتمين بالنمل في الغابة مثلاً.
أنهم كانوا هنا بالفعل في الماضي، وربما ساهموا في تطورنا، وهي نظرية تثيرها بعض الكتابات القديمة والأساطير.
هل لديك تصور معين عن نوع هذا التقدم الخيالي الذي تعتقد أنهم وصلوا إليه؟
بعض العلماء والمفكرين يتساءلون: إذا كانت هناك حضارات متقدمة، فلماذا لم نتواصل معها بعد؟ هذه الفكرة تُعرف بـ مفارقة فيرمي. بعض الإجابات المحتملة تشمل:
أنهم يراقبوننا دون تدخل، مثل تجربة علمية يدرسون فيها تطورنا.
أنهم متقدمون للغاية لدرجة أننا غير قادرين على إدراك وجودهم.
أنهم ببساطة غير مهتمين بنا، كما نحن غير مهتمين بالنمل في الغابة مثلاً.
أنهم كانوا هنا بالفعل في الماضي، وربما ساهموا في تطورنا، وهي نظرية تثيرها بعض الكتابات القديمة والأساطير.
هل لديك تصور معين عن نوع هذا التقدم الخيالي الذي تعتقد أنهم وصلوا إليه؟
🔥1
Forwarded from اللجنة العلمية CS 22 (Ayham Al-Akhali)
خدمه ال reasoning اصبحت متوفره الان في chatgpt
نتيجة المنافسة بين الغريم
ادخلوا جربوه 👍🏻
نتيجة المنافسة بين الغريم
ادخلوا جربوه 👍🏻
لو عايز تعمل لك مودل خاص بك حتى offline ادخل على موقع ollama تقريبا ونزل المودل الي يناسب مع إمكانيات جهازك لو انت بتخاف عبى بياناتك أو افترض قطع النت 🙋
أنت معك chatgpt بيدعم كل المجالات وانت فقط هتدربه مثلا على coding مثلا في مجال تخصصك لذلك سيكون خفيف على جهازك
زمان كان الوضع في إمكانيات بس كان صعب مثلا انك تحصل شبكة نت مثلا برغم ان اليوم الوضع صعب لكن أصبح من السهل ان تتعلم مثلا online يعني بالمختصر هذه نعمة عظيمة نحمد الله عليها حتى ولو كانت الظروف صعبة والعالم هاي والمعنى الأشياء الي كانت زمان صعبه اليوم من السهل ان تحصل عليها وشكرا
👍1🔥1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
هل تطلق الخدمة فورًا أم تنتظر حتى تصل إلى الكود المثالي؟ إنه السؤال الأزلي الذي يراود كل مبرمج!
في عالم البرمجة، نقف دومًا عند مفترق الطرق بين الإسراع في إطلاق الميزة المطلوبة، وبين التريث حتى نبلغ حد الكمال في الكود. لكن الحقيقة التي قد يغفل عنها البعض هي أن الكمال ليس حالة ثابتة، بل مفهوم متغير، والسعي خلفه دون توقف قد يصبح عقبة تعيق التقدم وتؤخر الإنجاز.
البرمجة ليست مجرد كتابة أكواد؛ إنها التزام بمواعيد وتسليم مهام في الوقت المحدد. وهنا تأتي أهمية السرعة في الإطلاق—إخراج المنتج إلى النور في لحظته المناسبة، حتى وإن لم يكن مثاليًا، ثم تحسينه شيئًا فشيئًا بناءً على الملاحظات والتجربة العملية.
لكن هذا لا يعني إهمال جودة الكود أو تجاهل مبادئ البرمجة النظيفة (Clean Code). فالكود يجب أن يكون قابلًا للصيانة، سهل الفهم، ومنظمًا بما يكفي لتطويره لاحقًا، لكنه ليس بحاجة إلى الكمال المطلق منذ اللحظة الأولى.
السعي إلى الكمال دون تنفيذ عملي قد يكون حجر عثرة، لكن التقدم المستمر هو المفتاح الحقيقي للوصول إلى أفضل النتائج مع مرور الزمن.
#دروس_اتعلمتها
في عالم البرمجة، نقف دومًا عند مفترق الطرق بين الإسراع في إطلاق الميزة المطلوبة، وبين التريث حتى نبلغ حد الكمال في الكود. لكن الحقيقة التي قد يغفل عنها البعض هي أن الكمال ليس حالة ثابتة، بل مفهوم متغير، والسعي خلفه دون توقف قد يصبح عقبة تعيق التقدم وتؤخر الإنجاز.
البرمجة ليست مجرد كتابة أكواد؛ إنها التزام بمواعيد وتسليم مهام في الوقت المحدد. وهنا تأتي أهمية السرعة في الإطلاق—إخراج المنتج إلى النور في لحظته المناسبة، حتى وإن لم يكن مثاليًا، ثم تحسينه شيئًا فشيئًا بناءً على الملاحظات والتجربة العملية.
لكن هذا لا يعني إهمال جودة الكود أو تجاهل مبادئ البرمجة النظيفة (Clean Code). فالكود يجب أن يكون قابلًا للصيانة، سهل الفهم، ومنظمًا بما يكفي لتطويره لاحقًا، لكنه ليس بحاجة إلى الكمال المطلق منذ اللحظة الأولى.
السعي إلى الكمال دون تنفيذ عملي قد يكون حجر عثرة، لكن التقدم المستمر هو المفتاح الحقيقي للوصول إلى أفضل النتائج مع مرور الزمن.
#دروس_اتعلمتها
أزي تعرف ان جهازك قد اخترقوه وتم سرقة معلومات اقل شيء الباسورد الي حافظها في المتصفح بتوع أمنية ↪
⬇️ ال
كيف يمكن لمحلل النظم (Business Analyst - BA) تقليل الأخطاء (Bugs) في النظام، والمساهمة في جودته، ومساعدة مهندسي الجودة في اختبارات التراجع (Regression Tests)؟ 🤔
✅ عندما يكون محلل النظم لديه فهم عميق للنظام، ومتطلباته، وتكامل أجزائه ومنتجاته، فإنه يستطيع تحديد جميع المناطق المتأثرة (Impacted Areas) التي قد تتأثر بأي تغيير أو متطلب جديد.
✅ بناءً على ذلك، سيتمكن المطور من أخذ هذه التبعيات (Dependencies) في الاعتبار أثناء عملية التطوير، مما يقلل من احتمالية حدوث أخطاء.
✅ بالإضافة إلى ذلك، سيتمكن مهندس الاختبار والجودة من تغطية جميع المناطق المتأثرة بالتغيير، بما في ذلك سيناريوهات التكامل (Integration Scenarios) وجميع السيناريوهات المحتملة التي قد تتأثر بالتعديلات الجديدة.
✅ كلما كانت المتطلبات موضحة بدقة عالية، ومكتوبة بتفاصيل كافية وواضحة للجميع، سواء للمطورين أو لمهندسي الجودة والاختبار أو المصممين، فإن ذلك يقلل من سوء فهم المتطلبات (Misunderstanding)، مما يضمن أن المطورين سينفذون المنتج بالشكل المطلوب، وأن مهندسي الجودة سيقومون بتغطية كافة السيناريوهات والاختبارات الضرورية.
⬇️ ال
كيف يمكن لمحلل النظم (Business Analyst - BA) تقليل الأخطاء (Bugs) في النظام، والمساهمة في جودته، ومساعدة مهندسي الجودة في اختبارات التراجع (Regression Tests)؟ 🤔
✅ عندما يكون محلل النظم لديه فهم عميق للنظام، ومتطلباته، وتكامل أجزائه ومنتجاته، فإنه يستطيع تحديد جميع المناطق المتأثرة (Impacted Areas) التي قد تتأثر بأي تغيير أو متطلب جديد.
✅ بناءً على ذلك، سيتمكن المطور من أخذ هذه التبعيات (Dependencies) في الاعتبار أثناء عملية التطوير، مما يقلل من احتمالية حدوث أخطاء.
✅ بالإضافة إلى ذلك، سيتمكن مهندس الاختبار والجودة من تغطية جميع المناطق المتأثرة بالتغيير، بما في ذلك سيناريوهات التكامل (Integration Scenarios) وجميع السيناريوهات المحتملة التي قد تتأثر بالتعديلات الجديدة.
✅ كلما كانت المتطلبات موضحة بدقة عالية، ومكتوبة بتفاصيل كافية وواضحة للجميع، سواء للمطورين أو لمهندسي الجودة والاختبار أو المصممين، فإن ذلك يقلل من سوء فهم المتطلبات (Misunderstanding)، مما يضمن أن المطورين سينفذون المنتج بالشكل المطلوب، وأن مهندسي الجودة سيقومون بتغطية كافة السيناريوهات والاختبارات الضرورية.