دردشة سريعة عن مفهوم الـ ACID في الـ Database ⚡️
.
.
تخيل إنك شغال على system ضخم زي تطبيق بنكي أو موقع بيع أونلاين…
في اللحظة اللي المستخدم بيحوّل فيها فلوس أو بيأكد عملية شراء، لازم تكون متأكد إن البيانات دي محفوظة صح، ومفيش أي احتمال يحصل فيها خلل أو تضارب، حتى لو السيرفر وقع أو الكهرباء قطعت. ⚠️
وهنا ييجي دور الـ ACID وهو ده العمود الفقري اللي بيخلي الـ Database تكون ثابتة، موثوقة، ومتوقعة السلوك في كل الحالات، سواء كان عندك عملية واحدة بسيطة أو آلاف الـ transactions في نفس الثانية.
الـ ACID بيحط أربع قواعد أساسية بتخلي أي Database system يعرف يتصرف وقت المشاكل ويحافظ على البيانات من غير ما يحصل chaos أو data corruption.
———
يعني لو عندك transaction بتنقل فلوس من حساب لحساب:
- تسحب 1000 جنيه من حساب A
- وتضيف 1000 لحساب B
لو أول خطوة نجحت والتانية فشلت لأي سبب (مثلًا السيرفر وقع)، المفروض الـ Database ترجع كل حاجة زي الأول، كأن العملية محصلتش.
———
الـ Consistency معناها إن الـ Database تفضل دايمًا في state صحيحة ومظبوطة.
يعني كل القواعد (constraints, rules, triggers) اللي أنت محددها لازم تفضل متطبقة بعد أي عملية.
مثلًا: لو عندك rule بيقول إن الرصيد مينفعش يكون بالسالب، فـ بعد أي transaction لازم الـ DB تفضل محافظة على القاعدة دي.
لو حصل violation للقواعد دي، العملية كلها تتلغي.
———
تخيل معايا كذا transaction شغالين في نفس الوقت...
واحد بيضيف بيانات، والتاني بيعدّل، والتالت بيقرأ.
لو مفيش Isolation، الدنيا هتبقى فوضى، وكل transaction هيشوف الـ data وهي لسه بتتغير!
لكن مع وجود الـ Isolation، كل transaction بتتعامل كأنها العملية الوحيدة اللي بتتنفذ.
يعني حتى لو كذا transaction شغالين في نفس اللحظة، النتائج اللي بيشوفوها مضمونة ومفيهاش تداخل أو corruption.
وطبعًا فيه مستويات مختلفة للـ Isolation (زي Read Uncommitted, Read Committed, Repeatable Read, Serializable)، وكل واحدة لها trade-offs بين الأداء والدقة.
———
الـ Durability معناها إن بمجرد ما الـ Database تقولك "تمت العملية بنجاح"، يبقى خلاص الـ data دي محفوظة ومش هتضيع حتى لو السيرفر وقع أو الكهرباء قطعت.
إزاي؟
لأن الـ DB بتكتب التغييرات على الـ disk (أو الـ log files) قبل ما تقولك العملية نجحت، علشان تقدر تسترجعها لو حصل أي failure.
———
وفقكم الله لكل خير 🌿
.
.
تخيل إنك شغال على system ضخم زي تطبيق بنكي أو موقع بيع أونلاين…
في اللحظة اللي المستخدم بيحوّل فيها فلوس أو بيأكد عملية شراء، لازم تكون متأكد إن البيانات دي محفوظة صح، ومفيش أي احتمال يحصل فيها خلل أو تضارب، حتى لو السيرفر وقع أو الكهرباء قطعت. ⚠️
وهنا ييجي دور الـ ACID وهو ده العمود الفقري اللي بيخلي الـ Database تكون ثابتة، موثوقة، ومتوقعة السلوك في كل الحالات، سواء كان عندك عملية واحدة بسيطة أو آلاف الـ transactions في نفس الثانية.
الـ ACID بيحط أربع قواعد أساسية بتخلي أي Database system يعرف يتصرف وقت المشاكل ويحافظ على البيانات من غير ما يحصل chaos أو data corruption.
———
📌 أولًا: Atomicity
يعني لو عندك transaction بتنقل فلوس من حساب لحساب:
- تسحب 1000 جنيه من حساب A
- وتضيف 1000 لحساب B
لو أول خطوة نجحت والتانية فشلت لأي سبب (مثلًا السيرفر وقع)، المفروض الـ Database ترجع كل حاجة زي الأول، كأن العملية محصلتش.
———
📌 ثانيًا: Consistency
الـ Consistency معناها إن الـ Database تفضل دايمًا في state صحيحة ومظبوطة.
يعني كل القواعد (constraints, rules, triggers) اللي أنت محددها لازم تفضل متطبقة بعد أي عملية.
مثلًا: لو عندك rule بيقول إن الرصيد مينفعش يكون بالسالب، فـ بعد أي transaction لازم الـ DB تفضل محافظة على القاعدة دي.
لو حصل violation للقواعد دي، العملية كلها تتلغي.
———
ثالثًا: Isolation
تخيل معايا كذا transaction شغالين في نفس الوقت...
واحد بيضيف بيانات، والتاني بيعدّل، والتالت بيقرأ.
لو مفيش Isolation، الدنيا هتبقى فوضى، وكل transaction هيشوف الـ data وهي لسه بتتغير!
لكن مع وجود الـ Isolation، كل transaction بتتعامل كأنها العملية الوحيدة اللي بتتنفذ.
يعني حتى لو كذا transaction شغالين في نفس اللحظة، النتائج اللي بيشوفوها مضمونة ومفيهاش تداخل أو corruption.
وطبعًا فيه مستويات مختلفة للـ Isolation (زي Read Uncommitted, Read Committed, Repeatable Read, Serializable)، وكل واحدة لها trade-offs بين الأداء والدقة.
———
رابعًا: Durability
الـ Durability معناها إن بمجرد ما الـ Database تقولك "تمت العملية بنجاح"، يبقى خلاص الـ data دي محفوظة ومش هتضيع حتى لو السيرفر وقع أو الكهرباء قطعت.
إزاي؟
لأن الـ DB بتكتب التغييرات على الـ disk (أو الـ log files) قبل ما تقولك العملية نجحت، علشان تقدر تسترجعها لو حصل أي failure.
———
وفقكم الله لكل خير 🌿
❤5
Stop React apps from crashing with Error Boundaries. 💯
Catch errors like a pro and show friendly fallbacks instead of broken screens.
Catch errors like a pro and show friendly fallbacks instead of broken screens.
❤3
الفرق بين الـ Monorepo والـ Multirepo 🔻
.
.
تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines.
المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡
هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟
تعال نوضح الفرق بينهم وإمتى تختار الطريقة المناسبة...
———
📌 أولًا: يعني إيه Monorepo؟
الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد.
يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد.
———
📍 مميزات الـ Monorepo:
- سهولة إدارة الكود:
كل حاجة في مكان واحد، فلو عايز تعمل تغييرات على أكتر من جزء، هتبقى شايف الصورة الكبيرة بسهولة.
- إعادة استخدام الكود (Code Reusability):
لو فيه مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من module، تقدر تعمله بسهولة من غير duplication.
- تنسيق أفضل بين الفرق:
كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts).
- تكامل أفضل بين الأدوات:
زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository.
———
📍 عيوب الـ Monorepo:
- الحجم الكبير للـ repo:
مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds.
- التعقيد في إدارة الصلاحيات:
صعب تقول إن فلان يقدر يشتغل على جزء معين بس من غير ما يشوف الباقي.
- مشاكل مع الـ Tools:
لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build.
———
📌 ثانيًا: يعني إيه Multirepo؟
على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو module من المشروع يكون في Repository خاص به. يعني كل module بيبقى مستقل بذاته وكأنه مشروع لوحده.
———
📍 مميزات الـ Multirepo:
- كل module له حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق.
- تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه.
- لو فيه module أو خدمة مش مرتبط بشكل مباشر، مش محتاج تبني كل المشروع، بس تبني الجزء اللي محتاجه.
- كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل.
———
📍 عيوب الـ Multirepo:
- تكرار الكود:
لو فيه أكتر من module بيحتاج نفس الكود، ممكن تضطر تكرره أو تحط مكتبة منفصلة ليه.
- تعقيد في التنسيق بين الفرق:
التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules
- تكامل معقد للـ CI/CD:
عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض.
- لو عندك تغيير ضخم بيأثر على أكتر من module، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده.
.
.
تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines.
المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡
هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟
تعال نوضح الفرق بينهم وإمتى تختار الطريقة المناسبة...
———
📌 أولًا: يعني إيه Monorepo؟
الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد.
يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد.
———
📍 مميزات الـ Monorepo:
- سهولة إدارة الكود:
كل حاجة في مكان واحد، فلو عايز تعمل تغييرات على أكتر من جزء، هتبقى شايف الصورة الكبيرة بسهولة.
- إعادة استخدام الكود (Code Reusability):
لو فيه مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من module، تقدر تعمله بسهولة من غير duplication.
- تنسيق أفضل بين الفرق:
كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts).
- تكامل أفضل بين الأدوات:
زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository.
———
📍 عيوب الـ Monorepo:
- الحجم الكبير للـ repo:
مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds.
- التعقيد في إدارة الصلاحيات:
صعب تقول إن فلان يقدر يشتغل على جزء معين بس من غير ما يشوف الباقي.
- مشاكل مع الـ Tools:
لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build.
———
📌 ثانيًا: يعني إيه Multirepo؟
على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو module من المشروع يكون في Repository خاص به. يعني كل module بيبقى مستقل بذاته وكأنه مشروع لوحده.
———
📍 مميزات الـ Multirepo:
- كل module له حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق.
- تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه.
- لو فيه module أو خدمة مش مرتبط بشكل مباشر، مش محتاج تبني كل المشروع، بس تبني الجزء اللي محتاجه.
- كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل.
———
📍 عيوب الـ Multirepo:
- تكرار الكود:
لو فيه أكتر من module بيحتاج نفس الكود، ممكن تضطر تكرره أو تحط مكتبة منفصلة ليه.
- تعقيد في التنسيق بين الفرق:
التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules
- تكامل معقد للـ CI/CD:
عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض.
- لو عندك تغيير ضخم بيأثر على أكتر من module، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده.
❤4
Optimizing Streams in JavaScript 💯
Streams improve performance for large data processing, but require careful optimization.
❤2
كلام في البرمجة (47) | DevOps & Infrastructure | كيف تصبح ديف أوبس ناجح؟ - محمد موسى
https://youtu.be/zPKyL8mnSkA
https://youtu.be/zPKyL8mnSkA
YouTube
كلام في البرمجة (47) | DevOps & Infrastructure | كيف تصبح ديف اوبس ناجح ؟ - محمد موسى
لينك التواصل على LinkedIn مع المهندس / محمد موسى
https://www.linkedin.com/in/mohamed-moussa-mba-36a56b7a/
---
00:00 – البرومو
01:17 – المقدمة
03:31 – ايه هو الـ Infrastructure ؟
05:33 – ايه مسؤولية محمد موسى ؟
14:56 – ايه هو الـ DevOps ؟
25:08 – هل الـ DevOps…
https://www.linkedin.com/in/mohamed-moussa-mba-36a56b7a/
---
00:00 – البرومو
01:17 – المقدمة
03:31 – ايه هو الـ Infrastructure ؟
05:33 – ايه مسؤولية محمد موسى ؟
14:56 – ايه هو الـ DevOps ؟
25:08 – هل الـ DevOps…
❤2
دردشة سريعة عن الـ Semantic Versioning 🔻
.
.
لو أنت شغال على مشروع، وفجأة قررت تعمل تحديث لمكتبة بتستخدمها...كل حاجة كانت شغالة تمام، لكن بمجرد ما عملت التحديث، المشروع كله ضرب وحلف ما يشتغل.
علشان الموقف ده ميحصلش معاك لازم تكون فاهم الـ Semantic Versioning كويس، وهي دي اللي بتخلّيك تفهم التغييرات اللي حصلت في أي إصدار جديد قبل ما تعمل التحديث والدنيا تبوظ منك.
تعال نفهم الموضوع ببساطة...
———
📌 يعني إيه Semantic Versioning؟
الـ Semantic Versioning مش مجرد أرقام زي 1.2.3، لكنها طريقة منظمة لتسمية الإصدارات (versions) بتساعدك تعرف هل الإصدار الجديد آمن ولا لا، وهل التغييرات اللي حصلت بسيطة ولا جذرية.
وكمان لو حبيت تغير إصدار المشروع نفسه تبقى فاهم هل التغيرات اللي عملتها تبع أي قسم في الـ Semantic Versioning
وده شكل الـ Semantic Versioning:
MAJOR.MINOR.PATCH
———
📍 الـ MAJOR: يعني تغيير كبير بيكسر التوافق مع الإصدارات القديمة (breaking changes).
📍 الـ MINOR: يعني إضافة features جديدة بس بدون ما نكسر التوافق.
📍 الـ PATCH: يعني إصلاح bugs أو تحسينات صغيرة بدون أي تغيير في الـ features.
———
📌 تعال نفهم كل جزء بالتفصيل:
✅ الـ PATCH:
لو عندك إصدار 1.2.3 وطلع فيه bug صغير واتصلّح، الرقم هيبقى كده:
1.2.4
مثال: لو مكتبة بتحسب الضرائب وكانت بتغلط في الحسبة، التغيير هنا ما بيأثرش على حد بيستخدم المكتبة بشكل عام، ده يعتبر Patch.
———
✅ الـ MINOR:
لو أضفت feature جديدة بس من غير ما تغيّر حاجة في الـ features اللي كانت شغالة قبل كده، الرقم هيبقى:
1.3.0
مثال: لو المكتبة بتاعت الضرائب أضافت خاصية جديدة لحساب الضرائب الدولية، ده تغيير بيضيف ميزة جديدة بس مش هيكسر الكود.
———
✅ الـ MAJOR:
لو حصل تغيير كبير بيأثر على الناس اللي بيستخدموا المكتبة، الرقم هيبقى كده:
2.0.0
مثال: لو قررت تغيّر الـ API تمامًا وتطلب من الناس يكتبوا الكود بتاعهم بشكل مختلف عشان المكتبة تشتغل، ده يعتبر Breaking Change.
———
📌 ليه نستخدم الـ Semantic Versioning؟
- توضيح التغييرات: لما تشوف الإصدار الجديد، تقدر بسهولة تعرف هل التغيير بسيط ولا كبير.
- تسهيل التحديث: لو عرفت إن التحديث مجرد Patch أو Minor، هتكون مطمن إن مفيش حاجة هتتكسر لما تعمل update.
- إدارة الشغل مع فريقك: لما تلتزم بـ Semantic Versioning، بيكون سهل على كل الفريق يتابع التغييرات اللي بتحصل.
———
📌 نصائح وإرشادات مهمة:
- التزم بالقواعد: متزودش رقم MAJOR عشان تضيف ميزة صغيرة! خلي الأرقام تعبر فعلًا عن التغييرات اللي بتحصل.
- اختبر كويس: لو هتعمل تغيير MAJOR، لازم تتأكد إنك مجرب كل حاجة عشان الناس اللي هيستخدموا الكود مش يعانوا.
- اكتب changelog: خلي فيه توثيق واضح عن إيه اللي اتغير في كل إصدار.
———
وفقكم الله لكل خير 🌿
.
.
لو أنت شغال على مشروع، وفجأة قررت تعمل تحديث لمكتبة بتستخدمها...كل حاجة كانت شغالة تمام، لكن بمجرد ما عملت التحديث، المشروع كله ضرب وحلف ما يشتغل.
علشان الموقف ده ميحصلش معاك لازم تكون فاهم الـ Semantic Versioning كويس، وهي دي اللي بتخلّيك تفهم التغييرات اللي حصلت في أي إصدار جديد قبل ما تعمل التحديث والدنيا تبوظ منك.
تعال نفهم الموضوع ببساطة...
———
📌 يعني إيه Semantic Versioning؟
الـ Semantic Versioning مش مجرد أرقام زي 1.2.3، لكنها طريقة منظمة لتسمية الإصدارات (versions) بتساعدك تعرف هل الإصدار الجديد آمن ولا لا، وهل التغييرات اللي حصلت بسيطة ولا جذرية.
وكمان لو حبيت تغير إصدار المشروع نفسه تبقى فاهم هل التغيرات اللي عملتها تبع أي قسم في الـ Semantic Versioning
وده شكل الـ Semantic Versioning:
MAJOR.MINOR.PATCH
———
📍 الـ MAJOR: يعني تغيير كبير بيكسر التوافق مع الإصدارات القديمة (breaking changes).
📍 الـ MINOR: يعني إضافة features جديدة بس بدون ما نكسر التوافق.
📍 الـ PATCH: يعني إصلاح bugs أو تحسينات صغيرة بدون أي تغيير في الـ features.
———
📌 تعال نفهم كل جزء بالتفصيل:
✅ الـ PATCH:
لو عندك إصدار 1.2.3 وطلع فيه bug صغير واتصلّح، الرقم هيبقى كده:
1.2.4
مثال: لو مكتبة بتحسب الضرائب وكانت بتغلط في الحسبة، التغيير هنا ما بيأثرش على حد بيستخدم المكتبة بشكل عام، ده يعتبر Patch.
———
✅ الـ MINOR:
لو أضفت feature جديدة بس من غير ما تغيّر حاجة في الـ features اللي كانت شغالة قبل كده، الرقم هيبقى:
1.3.0
مثال: لو المكتبة بتاعت الضرائب أضافت خاصية جديدة لحساب الضرائب الدولية، ده تغيير بيضيف ميزة جديدة بس مش هيكسر الكود.
———
✅ الـ MAJOR:
لو حصل تغيير كبير بيأثر على الناس اللي بيستخدموا المكتبة، الرقم هيبقى كده:
2.0.0
مثال: لو قررت تغيّر الـ API تمامًا وتطلب من الناس يكتبوا الكود بتاعهم بشكل مختلف عشان المكتبة تشتغل، ده يعتبر Breaking Change.
———
📌 ليه نستخدم الـ Semantic Versioning؟
- توضيح التغييرات: لما تشوف الإصدار الجديد، تقدر بسهولة تعرف هل التغيير بسيط ولا كبير.
- تسهيل التحديث: لو عرفت إن التحديث مجرد Patch أو Minor، هتكون مطمن إن مفيش حاجة هتتكسر لما تعمل update.
- إدارة الشغل مع فريقك: لما تلتزم بـ Semantic Versioning، بيكون سهل على كل الفريق يتابع التغييرات اللي بتحصل.
———
📌 نصائح وإرشادات مهمة:
- التزم بالقواعد: متزودش رقم MAJOR عشان تضيف ميزة صغيرة! خلي الأرقام تعبر فعلًا عن التغييرات اللي بتحصل.
- اختبر كويس: لو هتعمل تغيير MAJOR، لازم تتأكد إنك مجرب كل حاجة عشان الناس اللي هيستخدموا الكود مش يعانوا.
- اكتب changelog: خلي فيه توثيق واضح عن إيه اللي اتغير في كل إصدار.
———
وفقكم الله لكل خير 🌿
❤9
دردشة عن مفهوم الـ ACID في الـ Database ⚡️
📌 LinkedIn:
https://www.linkedin.com/posts/dev-alisamir_database-softwaredevelopment-acid-activity-7401279151065866241-pHFo
❤2