دردشة سريعة عن مفهوم الـ 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.
———
#دقيقة_برمجة
❤4
Container Queries Explained ⚡️
Container queries make components truly smart. They adapt to their space, not the screen.
❤1
مليون خبير لأوامر الذكاء الاصطناعي
مبادرة طموحة تهدف إلى تمكين مليون فرد بمهارات الذكاء الاصطناعي وهندسة الأوامر على مدار السنوات الثلاث المقبلة انطلاقاً من دبي.
توفر هذه الدورة أساساً متيناً لفهم الذكاء الاصطناعي والذكاء الاصطناعي التوليدي وهندسة الأوامر لتطبيقات وأدوات الذكاء الاصطناعي، بما يمكّن المنتسبين من الاستخدام الفعال لأدوات الذكاء الاصطناعي في عملهم وحياتهم اليومية. وسوف يتقن المشاركون من خلال المناهج التفاعلية والعملية لغة مخاطبة الذكاء الاصطناعي، وصياغة أوامره، بما يعزز الاستفادة من تقنياته المصممة لتعزيز الإنتاجية والأعمال الإبداعية، ومن ثمّ تحقيق النجاح في سوق العمل وتطوراته المتسارعة.
https://dub.ai/ar/omp-ar
❤2
Software Engineering for Undergrads 💯
———
Software Engineering CS391 Course at Faculty of Computers an Information, Assiut University
https://youtube.com/playlist?list=PLtk4ylDqiyiZxnwWGP-AsA8S5UYYsXp5U&si=K7b004cFY7yhH1GH
———
Software Engineering CS391 - 2024
Software Engineering CS391 Course at Faculty of Computers an Information, Assiut University
https://youtube.com/playlist?list=PLtk4ylDqiyiZxnwWGP-AsA8S5UYYsXp5U&si=K7b004cFY7yhH1GH
❤2
System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra 🚀
https://youtu.be/C842vFY5kRo
https://youtu.be/C842vFY5kRo
YouTube
System Design Course – APIs, Databases, Caching, CDNs, Load Balancing & Production Infra
Level up your system design skills! This course progresses from foundational concepts to production-ready systems, covering databases, scaling, and load balancing. Learn practical techniques for building and securing APIs, including RESTful and GraphQL.
…
…
❤4
انضم إلى #مجرة — مجتمع المطوّرين ومستجدّات التقنية!
اكتشف أحدث المقالات والأدوات وشارك خبراتك مع مطوّرين من كل مكان.
https://majara.dev/register?ref=alisamir
اكتشف أحدث المقالات والأدوات وشارك خبراتك مع مطوّرين من كل مكان.
https://majara.dev/register?ref=alisamir
❤4
دردشة سريعة عن الـ Temporal Dead Zone في JavaScript ⚡️
.
.
لو اشتغلت بـ let أو const في JavaScript، يبقى مهم جدًا تبقى فاهم الموضوع ده كويس جدًا… عشان هو واحد من الحاجات اللي ممكن تخلي الكود بتاعك يضرب وأنت مش فاهم ليه، وتفضل تلف حول نفسك بالساعات تحاول تحل error شكله غريب جدًا...
تعال ندردش شوية عن الـ Temporal Dead Zone أو الـ TDZ
———
🎯 الأول: يعني إيه Temporal Dead Zone؟
ببساطة كده، الـ Temporal Dead Zone هي الفترة الزمنية اللي بتبدأ من أول ما الـ scope بتاع المتغير بيتنفذ، لحد اللحظة اللي المتغير نفسه بيتعرف فيها (يعني بيتعمله declaration).
خلال الفترة دي، المتغير موجود "في دماغ JavaScript" بس مش مسموح توصل له، ولو حاولت تستخدمه... JavaScript هتقولك ReferenceError.
———
✅ مثال سريع يوضح الموضوع:
تفتكر ليه الكود ده بيطلع Error؟
ده لأن myVar دخل في الـ Temporal Dead Zone من أول ما الـ scope بدأ، ومش خارج منها غير بعد ما نوصل لسطر
يعني المتغير موجود بس مش جاهز لسه للاستخدام.
———
🤔 طب ليه ده بيحصل؟
الـ JavaScript بتعمل حاجة اسمها Hoisting لكل المتغيرات، سواء var أو let أو const.
بس فيه فرق:
- الـ var: بيتعمله hoisting وتبقى الـ default value = undefined، فممكن تستخدمها قبل ما تُعلن عنها.
- الـ let و const: بيتعملهم hoisting بردو، لكن ملهمش value، وبيكونوا في منطقة اسمها الـ TDZ لحد ما يوصل السطر اللي بيعملهم declaration.
———
مجموعة أمثلة توضح الفرق بين var و let:
مثال بـ var:
نفس المثال بـ let:
الاتنين اتعملهم hoisting… بس var أخذ value undefined، إنما let من غير value، فدخل في الـ TDZ...
———
📌 معلومات مهمة عن الـ TDZ:
1- الـ TDZ مش بس بتأثر على المتغيرات… كمان بتأثر على function parameters اللي متعرف لها default values
2- المتغير بيفضل في TDZ لحد ما توصل لسطر التعريف بتاعه.
3- الـ const كمان لها TDZ زي let بالضبط، لكن الفرق إنك لازم تعطيها قيمة وقت التعريف.
4- الـ TDZ بتمنعك من استخدام المتغير قبل ما تجهزه، وده هيحميك من مشاكل كتيرة.
———
🧠 كده نفهم إن:
الـ let و const أحسن من var في إنهم بيخلوا الكود predictable.
بس في نفس الوقت لازم تكون فاهم TDZ كويس جدًا علشان متغلطش غلطة بسيطة تكسرلك الكود.
كل ما تستخدم let أو const فوق في الكود، تأكد إنك مش بتستدعيهم قبل ما يتعرفوا.
.
.
لو اشتغلت بـ let أو const في JavaScript، يبقى مهم جدًا تبقى فاهم الموضوع ده كويس جدًا… عشان هو واحد من الحاجات اللي ممكن تخلي الكود بتاعك يضرب وأنت مش فاهم ليه، وتفضل تلف حول نفسك بالساعات تحاول تحل error شكله غريب جدًا...
تعال ندردش شوية عن الـ Temporal Dead Zone أو الـ TDZ
———
🎯 الأول: يعني إيه Temporal Dead Zone؟
ببساطة كده، الـ Temporal Dead Zone هي الفترة الزمنية اللي بتبدأ من أول ما الـ scope بتاع المتغير بيتنفذ، لحد اللحظة اللي المتغير نفسه بيتعرف فيها (يعني بيتعمله declaration).
خلال الفترة دي، المتغير موجود "في دماغ JavaScript" بس مش مسموح توصل له، ولو حاولت تستخدمه... JavaScript هتقولك ReferenceError.
———
✅ مثال سريع يوضح الموضوع:
console.log(myVar); // ReferenceError: Cannot access 'myVar' before initialization
let myVar = 10;
تفتكر ليه الكود ده بيطلع Error؟
ده لأن myVar دخل في الـ Temporal Dead Zone من أول ما الـ scope بدأ، ومش خارج منها غير بعد ما نوصل لسطر
let myVar = 10
يعني المتغير موجود بس مش جاهز لسه للاستخدام.
———
🤔 طب ليه ده بيحصل؟
الـ JavaScript بتعمل حاجة اسمها Hoisting لكل المتغيرات، سواء var أو let أو const.
بس فيه فرق:
- الـ var: بيتعمله hoisting وتبقى الـ default value = undefined، فممكن تستخدمها قبل ما تُعلن عنها.
- الـ let و const: بيتعملهم hoisting بردو، لكن ملهمش value، وبيكونوا في منطقة اسمها الـ TDZ لحد ما يوصل السطر اللي بيعملهم declaration.
———
مجموعة أمثلة توضح الفرق بين var و let:
مثال بـ var:
console.log(a); // undefined
var a = 5;
نفس المثال بـ let:
console.log(b); // ReferenceError
let b = 5;
الاتنين اتعملهم hoisting… بس var أخذ value undefined، إنما let من غير value، فدخل في الـ TDZ...
———
📌 معلومات مهمة عن الـ TDZ:
1- الـ TDZ مش بس بتأثر على المتغيرات… كمان بتأثر على function parameters اللي متعرف لها default values
2- المتغير بيفضل في TDZ لحد ما توصل لسطر التعريف بتاعه.
3- الـ const كمان لها TDZ زي let بالضبط، لكن الفرق إنك لازم تعطيها قيمة وقت التعريف.
4- الـ TDZ بتمنعك من استخدام المتغير قبل ما تجهزه، وده هيحميك من مشاكل كتيرة.
———
🧠 كده نفهم إن:
الـ let و const أحسن من var في إنهم بيخلوا الكود predictable.
بس في نفس الوقت لازم تكون فاهم TDZ كويس جدًا علشان متغلطش غلطة بسيطة تكسرلك الكود.
كل ما تستخدم let أو const فوق في الكود، تأكد إنك مش بتستدعيهم قبل ما يتعرفوا.
❤5🔥1
يعني إيه API Gateway؟
.
.
تخيل معايا إنك داخل مطعم كبير جدًا، والمطبخ فيه أكتر من شيف:
واحد مسؤول عن البيتزا 🍕، والتاني عن الحلويات 🍰، والتالت عن المشروبات ☕️.
وأنت كـ زبون، مش هتروح لكل شيف وتطلب منه، صح؟
فيه جرسون (الـ waiter) بياخد طلبك ويوصّله للمطبخ، ويجيبلك الأكل كله مرّة واحدة.
الجرسون ده في عالم البرمجة اسمه: API Gateway.
———
💡 يعني إيه API Gateway؟
ببساطة، الـ API Gateway هو حارس البوابة أو نقطة الدخول الوحيدة لكل الـ APIs اللي السيرفر أو النظام بيقدّمها.
لو عندك نظام ضخم (زي موقع تجارة إلكترونية مثلًا)، هتلاقي كل جزء فيه شغّال كـ Microservice:
- جزء لطلب الأوردرات
- جزء لحسابات المستخدمين
- جزء للمنتجات
- جزء للدفع الإلكتروني
الـ API Gateway بيجمع كل الخدمات دي وبيخلي الـ Frontend أو الموبايل يتعامل مع نقطة واحدة بس، بدل ما يبعت طلبات متفرقة لكل خدمة.
———
🤔 ليه نستخدم API Gateway؟
✅ توحيد نقطة الاتصال
بدل ما الـ Frontend يتعامل مع 5 أو 10 APIs، بيتعامل مع gateway واحدة.
🔐 الأمان
الـ Gateway تقدر تضيف layer للأمان: JWT, API keys, Rate limiting... إلخ.
📊 المراقبة والتحليل
تقدر تعرف مين بيطلب إيه، وإمتى، وتراقب كل حاجة من مكان واحد.
📦 الـ Caching و Load Balancing
ممكن يخزّن الردود (Cache) ويوزّع الأحمال بشكل ذكي.
🔁 تحويل البيانات
لو خدمة بترد بـ XML وانت محتاج JSON، الـ Gateway ممكن يتصرف.
———
🛠 أمثلة حقيقية لـ API Gateways:
- Kong
- AWS API Gateway
- Nginx
- Apigee
- Zuul
———
#دقيقة_برمجة
.
.
تخيل معايا إنك داخل مطعم كبير جدًا، والمطبخ فيه أكتر من شيف:
واحد مسؤول عن البيتزا 🍕، والتاني عن الحلويات 🍰، والتالت عن المشروبات ☕️.
وأنت كـ زبون، مش هتروح لكل شيف وتطلب منه، صح؟
فيه جرسون (الـ waiter) بياخد طلبك ويوصّله للمطبخ، ويجيبلك الأكل كله مرّة واحدة.
الجرسون ده في عالم البرمجة اسمه: API Gateway.
———
💡 يعني إيه API Gateway؟
ببساطة، الـ API Gateway هو حارس البوابة أو نقطة الدخول الوحيدة لكل الـ APIs اللي السيرفر أو النظام بيقدّمها.
لو عندك نظام ضخم (زي موقع تجارة إلكترونية مثلًا)، هتلاقي كل جزء فيه شغّال كـ Microservice:
- جزء لطلب الأوردرات
- جزء لحسابات المستخدمين
- جزء للمنتجات
- جزء للدفع الإلكتروني
الـ API Gateway بيجمع كل الخدمات دي وبيخلي الـ Frontend أو الموبايل يتعامل مع نقطة واحدة بس، بدل ما يبعت طلبات متفرقة لكل خدمة.
———
🤔 ليه نستخدم API Gateway؟
✅ توحيد نقطة الاتصال
بدل ما الـ Frontend يتعامل مع 5 أو 10 APIs، بيتعامل مع gateway واحدة.
🔐 الأمان
الـ Gateway تقدر تضيف layer للأمان: JWT, API keys, Rate limiting... إلخ.
📊 المراقبة والتحليل
تقدر تعرف مين بيطلب إيه، وإمتى، وتراقب كل حاجة من مكان واحد.
📦 الـ Caching و Load Balancing
ممكن يخزّن الردود (Cache) ويوزّع الأحمال بشكل ذكي.
🔁 تحويل البيانات
لو خدمة بترد بـ XML وانت محتاج JSON، الـ Gateway ممكن يتصرف.
———
🛠 أمثلة حقيقية لـ API Gateways:
- Kong
- AWS API Gateway
- Nginx
- Apigee
- Zuul
———
#دقيقة_برمجة
❤9