الفرق بين هياكل البيانات و OOP:
هياكل البيانات:
طريقة لتنظيم البيانات (مثل الأدراج لتخزين الأشياء).
مثال: قائمة بأسماء طلاب الصف.
OOP:
أسلوب لتصميم البرامج باستخدام كائنات تجمع البيانات والسلوك معًا.
مثال: كائن "طالب" يحتوي على الاسم (بيانات) وطريقة "يجيب على سؤال" (سلوك).
العلاقة:
OOP تستخدم هياكل البيانات لتنظيم البيانات داخل الكائنات.
هياكل البيانات:
طريقة لتنظيم البيانات (مثل الأدراج لتخزين الأشياء).
مثال: قائمة بأسماء طلاب الصف.
OOP:
أسلوب لتصميم البرامج باستخدام كائنات تجمع البيانات والسلوك معًا.
مثال: كائن "طالب" يحتوي على الاسم (بيانات) وطريقة "يجيب على سؤال" (سلوك).
العلاقة:
OOP تستخدم هياكل البيانات لتنظيم البيانات داخل الكائنات.
شرح Big O من واقع الحياة
تخيل أنك في سوق كبير وتحتاج إلى إنجاز مهمات، وسرعة إنجازك تعتمد على طريقة العمل. كل طريقة تمثل نوعًا من التعقيد الزمني في Big O.
---
1. O(1) - وقت ثابت (Instant Access)
المثال الواقعي:
لديك قائمة تسوق صغيرة على ورقة، وتعرف مكان "الطماطم" مباشرة. لا يهم حجم السوق، تذهب مباشرة إلى الرف المطلوب وتأخذ الطماطم.
الفكرة:
الزمن ثابت ولا يتأثر بحجم المشكلة.
مثل: قراءة أول عنصر في قائمة.
---
2. O(n) - خطي (Linear Time)
المثال الواقعي:
تبحث عن "أفضل تفاح" في السوق، وتفحص كل تفاحة واحدة تلو الأخرى حتى تنتهي من كل التفاح الموجود.
الفكرة:
كلما زاد عدد العناصر (تفاح أكثر)، زاد الوقت اللازم للبحث.
مثل: المرور على قائمة أسماء بالكامل.
---
3. O(n²) - تربيعي (Quadratic Time)
المثال الواقعي:
تقوم بمقارنة كل نوع من الفاكهة في السوق مع كل نوع آخر لتقرر أيهما الأفضل.
إذا كان لديك 10 أنواع فواكه، ستقوم بـ100 مقارنة! (10 × 10).
الفكرة:
كل عنصر يتفاعل مع كل عنصر آخر.
مثل: ترتيب قائمة باستخدام خوارزمية فاشلة.
---
4. O(log n) - لوغاريتمي (Logarithmic Time)
المثال الواقعي:
تبحث عن كتاب في مكتبة ضخمة، وتستخدم طريقة "ابحث في النصف":
تبدأ بالمنتصف: إذا لم يكن الكتاب هناك، تذهب إلى النصف الآخر، وهكذا.
تقلل خيارات البحث إلى النصف في كل خطوة.
الفكرة:
الوقت ينخفض بشكل كبير كلما قسّمت المشكلة.
مثل: البحث الثنائي.
---
5. O(2^n) - أُسي (Exponential Time)
المثال الواقعي:
تجرب كل الطرق الممكنة للوصول إلى منزل صديقك في مدينة غريبة.
إذا كانت هناك طريقان لكل منعطف، ستزداد الخيارات بشكل جنوني مع زيادة عدد المنعطفات.
الفكرة:
كل إضافة صغيرة للمشكلة تضاعف الزمن المطلوب بشكل هائل.
مثل: حل ألغاز معقدة جدًا.
---
الفكرة العامة:
كل نوع من Big O يصف كم يزداد الوقت مع زيادة حجم المشكلة.
O(1): سريع جدًا، دائمًا نفس الوقت.
O(n): يزداد مع زيادة عدد العناصر.
O(n²): يتضاعف بشكل كبير مع كل عنصر جديد.
O(log n): سريع جدًا، يقل الوقت مع تقسيم المشكلة.
O(2^n): بطيء جدًا، يزيد بشكل جنوني.
التشبيه: كل Big O هو "طريقة تفكير" لتنظيم وقتك حسب المهمة!
تخيل أنك في سوق كبير وتحتاج إلى إنجاز مهمات، وسرعة إنجازك تعتمد على طريقة العمل. كل طريقة تمثل نوعًا من التعقيد الزمني في Big O.
---
1. O(1) - وقت ثابت (Instant Access)
المثال الواقعي:
لديك قائمة تسوق صغيرة على ورقة، وتعرف مكان "الطماطم" مباشرة. لا يهم حجم السوق، تذهب مباشرة إلى الرف المطلوب وتأخذ الطماطم.
الفكرة:
الزمن ثابت ولا يتأثر بحجم المشكلة.
مثل: قراءة أول عنصر في قائمة.
---
2. O(n) - خطي (Linear Time)
المثال الواقعي:
تبحث عن "أفضل تفاح" في السوق، وتفحص كل تفاحة واحدة تلو الأخرى حتى تنتهي من كل التفاح الموجود.
الفكرة:
كلما زاد عدد العناصر (تفاح أكثر)، زاد الوقت اللازم للبحث.
مثل: المرور على قائمة أسماء بالكامل.
---
3. O(n²) - تربيعي (Quadratic Time)
المثال الواقعي:
تقوم بمقارنة كل نوع من الفاكهة في السوق مع كل نوع آخر لتقرر أيهما الأفضل.
إذا كان لديك 10 أنواع فواكه، ستقوم بـ100 مقارنة! (10 × 10).
الفكرة:
كل عنصر يتفاعل مع كل عنصر آخر.
مثل: ترتيب قائمة باستخدام خوارزمية فاشلة.
---
4. O(log n) - لوغاريتمي (Logarithmic Time)
المثال الواقعي:
تبحث عن كتاب في مكتبة ضخمة، وتستخدم طريقة "ابحث في النصف":
تبدأ بالمنتصف: إذا لم يكن الكتاب هناك، تذهب إلى النصف الآخر، وهكذا.
تقلل خيارات البحث إلى النصف في كل خطوة.
الفكرة:
الوقت ينخفض بشكل كبير كلما قسّمت المشكلة.
مثل: البحث الثنائي.
---
5. O(2^n) - أُسي (Exponential Time)
المثال الواقعي:
تجرب كل الطرق الممكنة للوصول إلى منزل صديقك في مدينة غريبة.
إذا كانت هناك طريقان لكل منعطف، ستزداد الخيارات بشكل جنوني مع زيادة عدد المنعطفات.
الفكرة:
كل إضافة صغيرة للمشكلة تضاعف الزمن المطلوب بشكل هائل.
مثل: حل ألغاز معقدة جدًا.
---
الفكرة العامة:
كل نوع من Big O يصف كم يزداد الوقت مع زيادة حجم المشكلة.
O(1): سريع جدًا، دائمًا نفس الوقت.
O(n): يزداد مع زيادة عدد العناصر.
O(n²): يتضاعف بشكل كبير مع كل عنصر جديد.
O(log n): سريع جدًا، يقل الوقت مع تقسيم المشكلة.
O(2^n): بطيء جدًا، يزيد بشكل جنوني.
التشبيه: كل Big O هو "طريقة تفكير" لتنظيم وقتك حسب المهمة!
👍2
الفرق بين Normalization و Denormalization:
Normalization:
هي عملية تبسيط الجدول إلى كيانات أبسط مع إزالة التكرار والاعتمادات الجزئية.
الأنواع الشائعة:
1NF: إزالة التكرار في الحقول والتأكد أن كل عمود يحتوي على قيمة واحدة.
2NF: إزالة الاعتماد الجزئي على المفتاح الأساسي.
3NF: فصل الكيانات إلى كيانات أصغر مرتبطة بالمفتاح الأساسي إذا كان هناك ارتباط بجدول آخر.
Denormalization:
هي عملية تجميع الكيانات في جدول واحد، مما قد يؤدي إلى تكرار البيانات في الحقول.
بالنسبة للتقارير:
Denormalization أفضل لأنها أسرع، خاصة مع البيانات الكبيرة أثناء البحث والاستعلام.
Normalization أفضل من حيث تقسيم التقارير لكل جدول بشكل منفصل.
Normalization:
هي عملية تبسيط الجدول إلى كيانات أبسط مع إزالة التكرار والاعتمادات الجزئية.
الأنواع الشائعة:
1NF: إزالة التكرار في الحقول والتأكد أن كل عمود يحتوي على قيمة واحدة.
2NF: إزالة الاعتماد الجزئي على المفتاح الأساسي.
3NF: فصل الكيانات إلى كيانات أصغر مرتبطة بالمفتاح الأساسي إذا كان هناك ارتباط بجدول آخر.
Denormalization:
هي عملية تجميع الكيانات في جدول واحد، مما قد يؤدي إلى تكرار البيانات في الحقول.
بالنسبة للتقارير:
Denormalization أفضل لأنها أسرع، خاصة مع البيانات الكبيرة أثناء البحث والاستعلام.
Normalization أفضل من حيث تقسيم التقارير لكل جدول بشكل منفصل.
الناس كلها بتفكر تعمل مشاريع بالAI وأنا بفكر أفتح مشروع شاي كرك في صنعاء .
شوية مكن ومكونات من الهند ولا الصين وأبيع الكوباية ب2000-3000 الف ريال وفي سوق فاضي مفيش فيه إلا كام منافس ايه رائيك 🤔😅
شوية مكن ومكونات من الهند ولا الصين وأبيع الكوباية ب2000-3000 الف ريال وفي سوق فاضي مفيش فيه إلا كام منافس ايه رائيك 🤔😅
🔥4
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
السلام عليكم ورحمة الله.
🛑يرجى التعميم🛑
في شركة تحتاج موظف React متفرغ لايوجد معه أرتباطات بأي جهة أطلاقا.
يكون فاهم React بشكل أحترافي جدا جدا.
ويفضل يكون ذو خبره سابقة وأشتغل على أنظمة محاسبية متكاملة.
العمل بيكون على نظام محاسبي كبير جدا ويحتاج شخص متقن ومحترف في React
للتقديم يرجى ارسال السيرة الذاتية واتساب على الرقم التالي.
+967772302176
🛑يرجى التعميم🛑
في شركة تحتاج موظف React متفرغ لايوجد معه أرتباطات بأي جهة أطلاقا.
يكون فاهم React بشكل أحترافي جدا جدا.
ويفضل يكون ذو خبره سابقة وأشتغل على أنظمة محاسبية متكاملة.
العمل بيكون على نظام محاسبي كبير جدا ويحتاج شخص متقن ومحترف في React
للتقديم يرجى ارسال السيرة الذاتية واتساب على الرقم التالي.
+967772302176
1. Abstract Class (الفريق المتخصص)
أنت كمدير تريد أن تجمع فريقًا متخصصًا في مجال معين (مثل فريق البرمجيات)، وكل أفراد الفريق يشاركون في قواعد وأدوات أساسية.
لكن في نفس الوقت، كل شخص لديه حرية في التفاصيل حسب دوره.
كيف تطبقها؟
توفر لهم أساسيات العمل مثل الأدوات (Laptop, IDE)، لكن تترك لكل واحد في الفريق إضافة لمساته الخاصة (مثل كتابة الكود بلغته المفضلة أو طريقته).
في البرمجة:
Abstract Class = فريق واحد متخصص بأساسيات موحدة مع حرية التفاصيل.
لماذا؟
لأنك تدير فريقًا متخصصًا وكل فرد يحتاج أدوات مشتركة مع اختلاف طريقة عمله.
2. Interface (القوانين الصارمة لكل الفرق)
هنا أنت كمدير تريد أن تضع قواعد واضحة تنطبق على كل الفرق في الشركة، سواء كانوا مبرمجين، محاسبين، أو مسوّقين.
لا يهمك التفاصيل الداخلية لكل فريق، المهم أنهم جميعًا يلتزمون بالقوانين.
كيف تطبقها؟
تقول: "كل فريق يجب أن يقدم تقريرًا أسبوعيًا". ما يهمك هو النتيجة: التقرير، وليس كيف يكتبونه.
في البرمجة:
Interface = قوانين صارمة لجميع الفرق، مهما اختلفت أدوارهم.
لماذا؟
لأنك تريد ضمان التزام جميع الفرق بالقوانين (تقرير)، لكن طريقة عملهم ليست ذات أهمية.
التفسير النهائي:
استخدم Abstract Class عندما تدير فريقًا متخصصًا وتريد أن تشاركه الأساسيات مع توفير حرية في التفاصيل.
استخدم Interface عندما تريد فرض قوانين صارمة يجب أن يلتزم بها الجميع دون الاهتمام بكيفية تنفيذ التفاصيل.
السؤال النهائي:
إذا كانت لديك شركة (مشروع برمجي)، اسأل نفسك:
هل أنا أدير فريقًا واحدًا؟ → استخدم Abstract Class.
هل أنا أدير الشركة كلها؟ → استخدم Interface.
عمالقة البرمجة دائمًا يختارون ما يناسب أهدافهم الواقعية!
#يالله كود
أنت كمدير تريد أن تجمع فريقًا متخصصًا في مجال معين (مثل فريق البرمجيات)، وكل أفراد الفريق يشاركون في قواعد وأدوات أساسية.
لكن في نفس الوقت، كل شخص لديه حرية في التفاصيل حسب دوره.
كيف تطبقها؟
توفر لهم أساسيات العمل مثل الأدوات (Laptop, IDE)، لكن تترك لكل واحد في الفريق إضافة لمساته الخاصة (مثل كتابة الكود بلغته المفضلة أو طريقته).
في البرمجة:
Abstract Class = فريق واحد متخصص بأساسيات موحدة مع حرية التفاصيل.
لماذا؟
لأنك تدير فريقًا متخصصًا وكل فرد يحتاج أدوات مشتركة مع اختلاف طريقة عمله.
2. Interface (القوانين الصارمة لكل الفرق)
هنا أنت كمدير تريد أن تضع قواعد واضحة تنطبق على كل الفرق في الشركة، سواء كانوا مبرمجين، محاسبين، أو مسوّقين.
لا يهمك التفاصيل الداخلية لكل فريق، المهم أنهم جميعًا يلتزمون بالقوانين.
كيف تطبقها؟
تقول: "كل فريق يجب أن يقدم تقريرًا أسبوعيًا". ما يهمك هو النتيجة: التقرير، وليس كيف يكتبونه.
في البرمجة:
Interface = قوانين صارمة لجميع الفرق، مهما اختلفت أدوارهم.
لماذا؟
لأنك تريد ضمان التزام جميع الفرق بالقوانين (تقرير)، لكن طريقة عملهم ليست ذات أهمية.
التفسير النهائي:
استخدم Abstract Class عندما تدير فريقًا متخصصًا وتريد أن تشاركه الأساسيات مع توفير حرية في التفاصيل.
استخدم Interface عندما تريد فرض قوانين صارمة يجب أن يلتزم بها الجميع دون الاهتمام بكيفية تنفيذ التفاصيل.
السؤال النهائي:
إذا كانت لديك شركة (مشروع برمجي)، اسأل نفسك:
هل أنا أدير فريقًا واحدًا؟ → استخدم Abstract Class.
هل أنا أدير الشركة كلها؟ → استخدم Interface.
عمالقة البرمجة دائمًا يختارون ما يناسب أهدافهم الواقعية!
#يالله كود
👍2
تحذير البرمج المكركه والله أن فيها بلاوي لجهازك ماحد بيدي حاجة ببلاش
لمحة 👀 برمجية
تحذير البرمج المكركه والله أن فيها بلاوي لجهازك ماحد بيدي حاجة ببلاش
لهذا انا استخدم
GNU/Linux 👍🏻😎
GNU/Linux 👍🏻😎
❤1👏1
Forwarded from InfoTechnology (IT4_2024)
↩🔝↪
اتخاذ القرارات في عالم البرمجيات
الهدف الأساسي هو أن البرنامج اللي تبني يقدم قيمة (Value).
فيه أساليب بتساعدك تحقق هذا الهدف. أهم شيء نفهم إنه:
ما فيه قرار صحيح 100% ولا قرار غلط 100%.
كل قرار فيه مزايا وعيوب.
طيب، كيف نحكم على القرارات؟
كل قرار نعطيه تقييم أو رقم، ومنه نقارنه بالقرارات الثانية اللي ممكن نأخذها بداله.
التقييم هذا بيتم عن طريق معادلة بسيطة:
D = V / E
D (الرغبة في التغيير - Desirability of Change).
V (القيمة اللي بيضيفها التغيير - Value Added).
E (المجهود المطلوب - Effort Needed).
الرغبة في التغيير بتتناسب طرديًا مع القيمة اللي يضيفها التغيير، وتتناسب عكسيًا مع المجهود المبذول.
مش مطلوب منك تحسب المعادلة بنفسك، بس قيم الأمور بناءً على فهمك.
أفضل سيناريو نظريًا يكون لما:
الميزة تضيف قيمة كبيرة جدًا.
وتحتاج مجهود قليل جدًا عشان تنفذها.
(لكن هذا في الأحلام 😂).
قبل ما تكتب الكود، فكّر:
إيش القيمة اللي بتضيفها الميزة؟
كم مجهود تحتاج لتحقيقها؟
كيف نحكم على قيمة الميزة (Value)؟
فيه عاملين يساعدوك:
1. Probability of Value
كيف كثير بيستخدم العميل هذه الميزة؟
2. Potential of Value
كم قيمة الميزة وقت استخدامها؟
أمثلة:
مثال 1:
Apple Watch
فيه ميزة لو قراءات ضربات القلب كانت غير طبيعية، بتوصل إشعار لأقرب 3 أشخاص من العائلة إن الشخص يعاني من أزمة قلبية.
احتمال الاستخدام (Probability):
ممكن تستخدم الميزة مرة وحدة في حياتك، أو ما تستخدمها أبدًا.
قيمة الميزة عند استخدامها (Potential):
عالي جدًا لأنها ممكن تنقذ حياة إنسان.
النتيجة: الميزة مرغوبة وأولوية عالية في التنفيذ.
مثال 2:
E-Commerce
ميزة تخلي المتجر يرسل نكتة أو اقتباس مضحك كإشعار أثناء ما العميل يتصفح المنتجات.
احتمال الاستخدام (Probability):
عالي جدًا، لأنها بتوصل لكل العملاء.
قيمة الميزة عند استخدامها (Potential):
ممكن تكون سلبية لأنها تشتت العميل وتضر بسمعة المتجر.
النتيجة: قيمة الميزة قليلة جدًا وممكن يتم إلغاؤها.
الخلاصة:
قبل ما تنفذ أي مهمة، فكر كويس في:
تأثيرها على العميل المستهدف.
القيمة اللي تضيفها.
تأثيرها على المشروع بالكامل.
اتخاذ القرارات في عالم البرمجيات
الهدف الأساسي هو أن البرنامج اللي تبني يقدم قيمة (Value).
فيه أساليب بتساعدك تحقق هذا الهدف. أهم شيء نفهم إنه:
ما فيه قرار صحيح 100% ولا قرار غلط 100%.
كل قرار فيه مزايا وعيوب.
طيب، كيف نحكم على القرارات؟
كل قرار نعطيه تقييم أو رقم، ومنه نقارنه بالقرارات الثانية اللي ممكن نأخذها بداله.
التقييم هذا بيتم عن طريق معادلة بسيطة:
D = V / E
D (الرغبة في التغيير - Desirability of Change).
V (القيمة اللي بيضيفها التغيير - Value Added).
E (المجهود المطلوب - Effort Needed).
الرغبة في التغيير بتتناسب طرديًا مع القيمة اللي يضيفها التغيير، وتتناسب عكسيًا مع المجهود المبذول.
مش مطلوب منك تحسب المعادلة بنفسك، بس قيم الأمور بناءً على فهمك.
أفضل سيناريو نظريًا يكون لما:
الميزة تضيف قيمة كبيرة جدًا.
وتحتاج مجهود قليل جدًا عشان تنفذها.
(لكن هذا في الأحلام 😂).
قبل ما تكتب الكود، فكّر:
إيش القيمة اللي بتضيفها الميزة؟
كم مجهود تحتاج لتحقيقها؟
كيف نحكم على قيمة الميزة (Value)؟
فيه عاملين يساعدوك:
1. Probability of Value
كيف كثير بيستخدم العميل هذه الميزة؟
2. Potential of Value
كم قيمة الميزة وقت استخدامها؟
أمثلة:
مثال 1:
Apple Watch
فيه ميزة لو قراءات ضربات القلب كانت غير طبيعية، بتوصل إشعار لأقرب 3 أشخاص من العائلة إن الشخص يعاني من أزمة قلبية.
احتمال الاستخدام (Probability):
ممكن تستخدم الميزة مرة وحدة في حياتك، أو ما تستخدمها أبدًا.
قيمة الميزة عند استخدامها (Potential):
عالي جدًا لأنها ممكن تنقذ حياة إنسان.
النتيجة: الميزة مرغوبة وأولوية عالية في التنفيذ.
مثال 2:
E-Commerce
ميزة تخلي المتجر يرسل نكتة أو اقتباس مضحك كإشعار أثناء ما العميل يتصفح المنتجات.
احتمال الاستخدام (Probability):
عالي جدًا، لأنها بتوصل لكل العملاء.
قيمة الميزة عند استخدامها (Potential):
ممكن تكون سلبية لأنها تشتت العميل وتضر بسمعة المتجر.
النتيجة: قيمة الميزة قليلة جدًا وممكن يتم إلغاؤها.
الخلاصة:
قبل ما تنفذ أي مهمة، فكر كويس في:
تأثيرها على العميل المستهدف.
القيمة اللي تضيفها.
تأثيرها على المشروع بالكامل.
❤1👍1
في ظل المشتتات المتزايدة بوتيرة غير مسبوقة، سيصبح من أعظم تحديات 2025 أن تتعلم كيف توزع مواردك الأساسية بذكاء: وقتك، طاقتك، ومالك. هذه هي مفاتيح النجاح في أي مجال مهني أو شخصي.
خطط بحكمة، حدد أولوياتك بوضوح، وامنح تركيزك للحاجات والأشخاص الذين يضيفون قيمة حقيقية لحياتك. لا تدع الضوضاء تحجب رؤيتك للهدف.
استعن بالله في كل خطوة، وكن واثقًا أن القرارات الصحيحة اليوم هي التي تصنع الفرق غدًا. اجعلها رحلة ممتعة، لأن النجاح لا يتعلق فقط بالوصول، بل بالاستمتاع بالطريق أيضًا.
خطط بحكمة، حدد أولوياتك بوضوح، وامنح تركيزك للحاجات والأشخاص الذين يضيفون قيمة حقيقية لحياتك. لا تدع الضوضاء تحجب رؤيتك للهدف.
استعن بالله في كل خطوة، وكن واثقًا أن القرارات الصحيحة اليوم هي التي تصنع الفرق غدًا. اجعلها رحلة ممتعة، لأن النجاح لا يتعلق فقط بالوصول، بل بالاستمتاع بالطريق أيضًا.
❤1👍1
شف ياصديقي لو قلت لك الان انت بترسل request إلى Database لجلب مثلا منتجات أي كان طيب في نفس اللحظه في عدد من requests من أكثر من client كذلك كيف ان احسن من نظامي بدل ما request على طول يرتسل إلى السيرفر يتم توجيهه إلى message queue و السيرفر ب يستهلك ويعمل listening على الطابور تعرف ايش انت الان حسنت الأداء وعملة عمليه تنظيم كذلك ايش افترض السيرفر وقف وفي requests ارسلت والسيرفر وقع هنا العميل مش هيحس بوقف السيرفر وطلبه سيظل معلق على الطابور مايضيع حتى يعاد عمل السيرفر ويكمل عمله وركز تخيل لو انت في عملية تحويل أموال
وشكرا
وشكرا
❤2
من الشات اكثر
طيب شوف، لو قلت لك الآن إنك بترسل request إلى الـ Database لجلب منتجات أو أي بيانات أخرى، وفي نفس اللحظة في عدد من الـ requests جاي من أكثر من client، كيف ممكن تحسن من نظامك؟
بدل ما كل request يروح مباشرة للسيرفر، يتم توجيهه إلى Message Queue. السيرفر هنا يكون مسؤول فقط عن استهلاك الطلبات الموجودة في الطابور ويعمل Listening عليها.
الحين، بهذا الشكل:
حسنت الأداء لأن الطلبات ما تدخل مباشرة للسيرفر بشكل عشوائي.
سويت عملية تنظيم لتدفق الطلبات، بحيث السيرفر يشتغل على قدر طاقته بدون ضغط.
طيب افترض السيرفر وقف لأي سبب، وفي requests أُرسلت خلال هذا الوقت، هنا:
العميل ما راح يحس أن السيرفر متوقف، لأن الطلبات تظل معلقة في الطابور.
الطلبات ما تضيع، وبمجرد ما يرجع السيرفر للعمل، يكمل معالجة الطلبات الموجودة.
تخيل هذا السيناريو لو كنت في عملية تحويل أموال:
توقف السيرفر هنا قد يؤدي لفقدان الطلبات أو تكرارها.
لكن مع الـ Message Queue، الطلب يظل محفوظ حتى يتم معالجته بشكل كامل، مما يضمن استمرارية العملية بدون أي خسائر.
وشكراً.
طيب شوف، لو قلت لك الآن إنك بترسل request إلى الـ Database لجلب منتجات أو أي بيانات أخرى، وفي نفس اللحظة في عدد من الـ requests جاي من أكثر من client، كيف ممكن تحسن من نظامك؟
بدل ما كل request يروح مباشرة للسيرفر، يتم توجيهه إلى Message Queue. السيرفر هنا يكون مسؤول فقط عن استهلاك الطلبات الموجودة في الطابور ويعمل Listening عليها.
الحين، بهذا الشكل:
حسنت الأداء لأن الطلبات ما تدخل مباشرة للسيرفر بشكل عشوائي.
سويت عملية تنظيم لتدفق الطلبات، بحيث السيرفر يشتغل على قدر طاقته بدون ضغط.
طيب افترض السيرفر وقف لأي سبب، وفي requests أُرسلت خلال هذا الوقت، هنا:
العميل ما راح يحس أن السيرفر متوقف، لأن الطلبات تظل معلقة في الطابور.
الطلبات ما تضيع، وبمجرد ما يرجع السيرفر للعمل، يكمل معالجة الطلبات الموجودة.
تخيل هذا السيناريو لو كنت في عملية تحويل أموال:
توقف السيرفر هنا قد يؤدي لفقدان الطلبات أو تكرارها.
لكن مع الـ Message Queue، الطلب يظل محفوظ حتى يتم معالجته بشكل كامل، مما يضمن استمرارية العملية بدون أي خسائر.
وشكراً.
تحسين أداء الأنظمة باستخدام Message Queue
لنفترض أن لديك نظامًا يتلقى طلبات (Requests) من العملاء لجلب منتجات أو تنفيذ عمليات معينة. الآن، في نفس اللحظة، هناك العديد من الطلبات الواردة من عدة عملاء، مما يسبب ضغطًا على السيرفر.
المشكلة:
كل طلب يتم إرساله مباشرة إلى السيرفر لمعالجته.
إذا كان عدد الطلبات كبيرًا جدًا، قد يؤدي ذلك إلى:
تأخير في الاستجابة.
تعطل النظام إذا فاق الطلب قدرة السيرفر.
ماذا يحدث إذا تعطل السيرفر أثناء معالجة الطلبات؟ في هذه الحالة، الطلبات قد تُفقد، مما يُحدث مشاكل كبيرة خاصة في العمليات الحساسة مثل تحويل الأموال.
الحل: Message Queue
بدلاً من إرسال الطلبات مباشرة إلى السيرفر، يتم توجيهها إلى Message Queue (طابور رسائل).
كيف يعمل؟
1. العملاء: يرسلون الطلبات إلى الطابور بدلاً من السيرفر مباشرة.
2. السيرفر: يقوم بعملية Listening على الطابور ويستهلك الطلبات واحدة تلو الأخرى بناءً على قدرته.
3. إذا تعطل السيرفر لأي سبب، تظل الطلبات موجودة في الطابور حتى يعود للعمل ويكمل معالجتها.
الفوائد:
1. تحسين الأداء:
تنظيم تدفق الطلبات بحيث لا تتجاوز قدرة السيرفر.
السيرفر يعالج الطلبات بمعدل ثابت دون ضغط مفاجئ.
2. الحفاظ على الطلبات:
إذا تعطل السيرفر، الطلبات تبقى محفوظة في الطابور ولا تضيع.
بمجرد عودة السيرفر للعمل، يكمل معالجة الطلبات.
3. زيادة الموثوقية:
العملاء لا يشعرون بتوقف النظام لأن الطلباتهم تظل معلقة في الطابور.
تطبيق حقيقي:
تخيل أن العملية هي تحويل أموال بين الحسابات.
إذا تم إرسال الطلب مباشرة إلى السيرفر وتعطل أثناء العملية، قد يتم فقدان الطلب، مما يسبب خسائر كبيرة.
باستخدام Message Queue، الطلب يتم تسجيله في الطابور ويبقى محفوظًا حتى يعالج بشكل صحيح، حتى لو تعطل النظام مؤقتًا.
---
ملخص:
Message Queue يحسن الأداء ويجعل النظام أكثر موثوقية.
يساعد على إدارة الضغط على السيرفر وتنظيم الطلبات بشكل أفضل.
يمنع فقدان الطلبات ويضمن استمرارية العمليات، خاصة في السيناريوهات الحرجة مثل تحويل الأموال.
> باستخدام هذا النهج، تكون قد بنيت نظامًا أكثر استقرارًا وفعالية.
لنفترض أن لديك نظامًا يتلقى طلبات (Requests) من العملاء لجلب منتجات أو تنفيذ عمليات معينة. الآن، في نفس اللحظة، هناك العديد من الطلبات الواردة من عدة عملاء، مما يسبب ضغطًا على السيرفر.
المشكلة:
كل طلب يتم إرساله مباشرة إلى السيرفر لمعالجته.
إذا كان عدد الطلبات كبيرًا جدًا، قد يؤدي ذلك إلى:
تأخير في الاستجابة.
تعطل النظام إذا فاق الطلب قدرة السيرفر.
ماذا يحدث إذا تعطل السيرفر أثناء معالجة الطلبات؟ في هذه الحالة، الطلبات قد تُفقد، مما يُحدث مشاكل كبيرة خاصة في العمليات الحساسة مثل تحويل الأموال.
الحل: Message Queue
بدلاً من إرسال الطلبات مباشرة إلى السيرفر، يتم توجيهها إلى Message Queue (طابور رسائل).
كيف يعمل؟
1. العملاء: يرسلون الطلبات إلى الطابور بدلاً من السيرفر مباشرة.
2. السيرفر: يقوم بعملية Listening على الطابور ويستهلك الطلبات واحدة تلو الأخرى بناءً على قدرته.
3. إذا تعطل السيرفر لأي سبب، تظل الطلبات موجودة في الطابور حتى يعود للعمل ويكمل معالجتها.
الفوائد:
1. تحسين الأداء:
تنظيم تدفق الطلبات بحيث لا تتجاوز قدرة السيرفر.
السيرفر يعالج الطلبات بمعدل ثابت دون ضغط مفاجئ.
2. الحفاظ على الطلبات:
إذا تعطل السيرفر، الطلبات تبقى محفوظة في الطابور ولا تضيع.
بمجرد عودة السيرفر للعمل، يكمل معالجة الطلبات.
3. زيادة الموثوقية:
العملاء لا يشعرون بتوقف النظام لأن الطلباتهم تظل معلقة في الطابور.
تطبيق حقيقي:
تخيل أن العملية هي تحويل أموال بين الحسابات.
إذا تم إرسال الطلب مباشرة إلى السيرفر وتعطل أثناء العملية، قد يتم فقدان الطلب، مما يسبب خسائر كبيرة.
باستخدام Message Queue، الطلب يتم تسجيله في الطابور ويبقى محفوظًا حتى يعالج بشكل صحيح، حتى لو تعطل النظام مؤقتًا.
---
ملخص:
Message Queue يحسن الأداء ويجعل النظام أكثر موثوقية.
يساعد على إدارة الضغط على السيرفر وتنظيم الطلبات بشكل أفضل.
يمنع فقدان الطلبات ويضمن استمرارية العمليات، خاصة في السيناريوهات الحرجة مثل تحويل الأموال.
> باستخدام هذا النهج، تكون قد بنيت نظامًا أكثر استقرارًا وفعالية.
الأشياء هذه لا أحد يتطرق لها لأن أي نظام لأن أي نظام شغال في بلادنا عسى الله كم مستخدمين بيستخدمه مافيش انظمه معقده
فكرة أن تكون عادلًا ومُنصفًا عند الإشراف على فريق تتطلب أن يكون لديك وعي بضرورة تحقيق التوازن بين التشجيع وتحفيز الفريق ككل. عندما يُنجز أحد أفراد الفريق شيئًا مميزًا، قد يكون من المفيد تجنب المبالغة في المدح بطريقة تُشعر الآخرين بعدم التقدير أو تُسبب إحساسًا بالتمييز غير المبرر.
بدلاً من قول عبارات مثل "أنت عبقري" أو "لا أحد يستطيع فعل ما فعلت"، من الأفضل استخدام لغة تُركز على التقدير مع الحفاظ على العدالة، مثل:
"أنا أقدّر مجهودك الكبير في هذا العمل."
"هذا إنجاز رائع، وأنا ممتن لالتزامك ودقتك."
بهذه الطريقة، تُظهر التقدير للجهد المبذول، دون أن تُسبب إحباطًا لبقية الفريق أو تُشعرهم بأن جهودهم أقل قيمة. وفي الوقت نفسه، تأكد من الاحتفال بالنجاحات الجماعية لتحفيز الجميع على تقديم الأفضل.
بدلاً من قول عبارات مثل "أنت عبقري" أو "لا أحد يستطيع فعل ما فعلت"، من الأفضل استخدام لغة تُركز على التقدير مع الحفاظ على العدالة، مثل:
"أنا أقدّر مجهودك الكبير في هذا العمل."
"هذا إنجاز رائع، وأنا ممتن لالتزامك ودقتك."
بهذه الطريقة، تُظهر التقدير للجهد المبذول، دون أن تُسبب إحباطًا لبقية الفريق أو تُشعرهم بأن جهودهم أقل قيمة. وفي الوقت نفسه، تأكد من الاحتفال بالنجاحات الجماعية لتحفيز الجميع على تقديم الأفضل.