DevGuide

#css

دردشة سريعة عن الـ React Server Components ⚡️ . . لو بتشتغل React بقالك فترة، أكيد عارف إن واحد من أكبر التحديات هو إن الأداء ساعات بيتأثر، والـ bundle size بيكبر، وبتلاقي نفسك بتجري ورا الـ optimization يمين وشمال: تضيف memo هنا، و useCallback هناك، و Server-Side Rendering عشان السرعة… بس لسه حاسس إن فيه حاجة ناقصة. علشان كده React طلعوا بحاجة اسمها React Server Components (RSC)… الـ React Server Components بتنقل React إلى مستوى تاني خالص. بتخلّي جزء كبير من الكود يشتغل على الـ Server بدل ما ينزل كله للـ Client، وبالتالي: ✅ الـ performance أعلى ✅ الـ bundle size أقل ✅ الـ data fetching أسهل وأبسط ✅ هيكون عندك zero client-side overhead لحاجات مش محتاجة تكون Client components أصلًا يعني تخيّل تعمل Component كاملة تتنفذ على السيرفر من غير ما تنزل للمتصفح… وتقدر تدخل فيها مباشرة DB queries أو تستخدم APIs من غير ما تفكر في security ولا hooks زي useEffect… ——— الـ RSC هي Components بيحصل لها render بالكامل على الـ Server، ومش بتوصل للـ Browser كـ JavaScript code. هي بتبعت الـ UI final result للـ Client بشكل lightweight، من غير ما يبقى محتاج hydrate زي الـ SSR. ——— 📌 الفرق بينها وبين SSR (Server-Side Rendering)؟ 📍 الـ SSR: - السيرفر بيعمل render، بس بيبعت HTML + hydration scripts - بيبعت JS كتير للـ Client - الهدف: تحسين الـ First Paint 📍 الـ Server Components: - السيرفر بيبعت UI بدون hydration، ومش كل حاجة بتحتاج تكون interactive - ممكن تمنع تحميل JS أصلًا لبعض الـ Components - الهدف: تقليل الـ bundle size + handling logic على السيرفر ——— 💡 الـ RSC بتشتغل ازاي؟ ✅ الـ Server Components: بتتكتب بنفس شكل الـ Components العادية، بس بيحصل لها render على السيرفر فقط، ومينفعش تستخدم فيها useState أو useEffect. ✅ الـ Client Components: دي اللي بتشتغل على الـ Browser، وبتحتاج تكتب في أولها "use client" عشان React تفهم إنها لازم تنزل للـ Client. ——— وفقكم الله لكل خير 🌿 ——— #react

12 نصيحـة لحمـاية الـ APIs! 🛡 . . في عالم البرمجة، تعتبر الـ APIs هي الأعصاب في جسم التطبيقات، لو حصل فيها مشكلة، الدنيا كلها بتخرب. عشان كده، حماية الـ APIs مهم جدًا وحاجة أساسية في التطبيق. 💡 تعال ندردش شوية عن طرق حماية الـ APIs... ———

1- استخدم الـ HTTPS:

دي أول حاجة لازم تعملها، أي حاجة بتتبعت أو بتستقبلها لازم تكون مشفّرة، عشان تحمي بياناتك.

2- اعتمد على الـ OAuth2:

ده المعيار الأساسي عشان تحمي التطبيقات اللي بتتصل بـ APIs، وبيضمن إن الـ Token اللي بيتبعت آمن ومحدود الصلاحيات.

3- جرب الـ WebAuthn:

لو شغلك فيه حساسية عالية، فكر في WebAuthn عشان تضيف طبقة أمان من خلال المصادقة البيومترية (زي البصمة أو التعرف على الوجه).

4- قسّم المفاتيح حسب الصلاحيات (Leveled API Keys):

مينفعش نفس المفتاح يقدر يعمل كل حاجة! قسّم المفاتيح بناءً على صلاحيات المستخدم أو التطبيق.

5- ركز على الـ Authorization مش بس الـ Authentication:

مجرد إن المستخدم سجل الدخول مش معناه إنه مسموح له يعمل كل حاجة. تأكد إن كل طلب معمول له تفويض.

6- طبّق الـ Rate Limiting:

متخليش أي حد يقدر يضرب الـ API بتاعتك بمئات الطلبات في الثانية. كده هتحمي نفسك من الـ DDoS attacks.

7- اعمل API Versioning:

تغيير صغير في الـ API ممكن يبوّظ تطبيقات كتير لو مش مأمن نسخة قديمة لها. حافظ على الإصدارات المختلفة.

8- استخدم Whitelisting:

اسمح بس لطلبات جايه من IPs معينة، وده بيقلل احتمالية الاختراق من جهات غير معروفة.

9- افحص OWASP API Security Risks:

قائمة OWASP دي زي الكتالوج للمخاطر الشائعة في الـ APIs. تأكد إنك عارفهم وعالجتهم.

10- خلي فيه API Gateway:

ده زي الحارس الشخصي للـ APIs. بيعمل فلترة للطلبات، مصادقة، وتحكم شامل في الأمان.

11- تعامل بحرص مع الأخطاء (Error Handling):

متطلعش معلومات حساسة لما يحصل خطأ، زي الـ stack traces أو البيانات الداخلية.

12- فعّل Input Validation:

بلاش تدي الأمان للبيانات اللي جايه من الـ client بشكل عشوائي. افحص كل المدخلات وتأكد إنها سليمة. ——— وفقكم الله لكل خير ☘️

One line of CSS. Smooth page transitions. No JavaScript. 💯

@view-transition {
  navigation: auto;
}

The 🆕 CSS View Transitions bring native animations to multi-page apps, no SPA setup needed! ——— Explore now 👇 https://developer.mozilla.org/en-US/blog/view-transitions-beginner-guide

إزاي تتجنب الـ Memory Leaks في JavaScript؟ 🤔 . . خلال رحلتك في عالم الـ JavaScript، سواء في فرونت اند أو باك اند، ممكن تكون سمعت عن مصطلح الـ "Memory Leaks". وده موضوع ممكن يتسبب في كوارث زي إن التطبيق بتاعك يبقى بطيء جدًا أو حتى ينهار خالص...⚠️ تعال ندردش شوية عن الـ Memory Leaks وإزاي تتجنبها في الكود... ——— Memory Leaks in JavaScript: A Simple Guide 💯 في المقال ده تكلمنا عن أهم المواضيع اللي تخص الـ Memory Leaks: 📍 What is a Memory Leak? 📍 How JavaScript Manages Memory 📍 Common Causes of Memory Leaks 📍 How to Detect Memory Leaks 📍 Tips to Prevent Memory Leaks ——— 📌 رابط المقال: ⚡️ Dev Community https://dev.to/alisamir/memory-leaks-in-javascript-a-simple-guide-31e8 ⚡️ Medium https://medium.com/@dev.alisamir/memory-leaks-in-javascript-a-simple-guide-e274d44f169c ——— وفقكم الله لكل خير ☘️

من أفضل القنوات على يوتيوب لتعلم React The best React content on YouTube! 💯 https://www.youtube.com/@cosdensolutions

Flexbox in CSS 🔥💯

JavaScript Code Security #javascript

إزاي تعرض شغلك كـ Backend Developer؟ . . بتقعد ساعات تكتب في code، تبني APIs، تظبط الـ Auth، تتعامل مع Databases و Logging و Queues، وكمان ممكن تكون بتشتغل على Microservices و Event-driven architecture… بس لما تيجي تقدم على شغل أو تعرض شغلك لحد، بتقف ومش عارف تقول إيه... المشكلة مش إن شغلك قليل، المشكلة إنك مش عارف "تعرضه" بشكل يخلي اللي قدامك يعرف خبرتك والمعلومات اللي عندك. الـ Backend أصعب شوية في النقطة دي عن الـ Frontend، لأن الناس مش بتشوف شغلك بعنيهم، فأنت اللي لازم "تخليهم يشوفوه". تعال أقولك إزاي تعرض شغلك كـ Backend Developer بطريقة محترمة... ——— ✨ أول حاجة: أنت بتشتغل على إيه؟ اكتب الكلام ده في شكل نقاط واضحة، وبلغة بسيطة. حاول تجاوب على الأسئلة دي: - إيه نوع الـ systems اللي اشتغلت عليها؟ (E-commerce, CMS, Booking system…) - كان فيها كام user؟ أو traffic عامل إزاي؟ - هل كانت Monolith ولا Microservices؟ - هل اشتغلت على حاجات زي Authentication, Payments, Notifications؟ - هل فيه Challenges معينة حليتها؟ (scalability, performance, data integrity…) ✅ مثال: اشتغلت على نظام E-commerce بيخدم 200K user شهريًا، بنيت فيه REST APIs بـ Node.js وExpress، وعملت Integration مع Stripe للـ payments. ساهمت في refactor من Monolith لـ Microservices، واشتغلت على Service خاصة بالـ Orders باستخدام MongoDB وRabbitMQ. ——— ✨ ثاني حاجة: تكلم عن قراراتك التقنية بلاش تقول "اشتغلت بـ Node.js وخلاص"، ولكن احكي ليه استخدمتها؟ إزاي اختارت Database معينة؟ ليه استخدمت Redis أو Kafka؟ اللي بيفرق أي حد شاطر مش بس إنه بيعرف يستخدم tools…إنما بيعرف إمتى يستخدم إيه، وليه، وإيه البدائل اللي كانت متاحة؟ ✅ مثال: استخدمنا Redis علشان نعمل caching لبيانات المنتجات عشان نحل مشكلة الـ latency العالية في الـ product listing. ده قلل الـ response time بنسبة 60%. ——— ✨ ثالث حاجة: تكلم بلغة الـ Impact بلاش تقول "اشتغلت على كذا…"، الناس بتحب تسمع التأثير - "بسبب شغلي، حصل كذا وكذا…" تتكلم عن النتائج: - الـ API response time قل بنسبة كام؟ - كم bug اتصلحت؟ - الـ revenue زاد؟ retention اتحسن؟ - الـ system بقى يستحمل كام request في الثانية؟ ✅ مثال: عملت تحسين للـ queries في MySQL خلّى الـ checkout process أسرع بنسبة 40%، وقلل الـ cart abandonment بنسبة ملحوظة. ——— ✨ رابع حاجة: الـ Showcase  الحقيقي - اعمل repos على GitHub فيها مشاريع حقيقية (مش مشاريع الـ Hello World) - اعرض Postman Collection أو OpenAPI Spec - لو اشتغلت على حاجات Open Source أو عندك Blog بيشرح اللي بتعمله ممكن تضيفه. ——— ✨ خامس حاجة: خلي شغلك "مفهوم" للناس اللي مش في نفس التخصص خلي دايمًا الطريقة اللي بتتكلم بها سهلة، وفيها أرقام. بدل ما تقول: “Built scalable APIs using Node.js.” ممكن تقول: “Built RESTful APIs using Node.js to handle 20K+ daily requests, with response time under 200ms.” تكلم عن الفائدة، مش بس التفاصيل التقنية. بدل ما تقول: “اشتغلت على تحسين الـ indexing strategy في MongoDB باستخدام compound indexes.” ممكن تقول: “قللت وقت تحميل صفحة المنتجات من 5 ثواني لأقل من ثانية بعد تحسين الـ indexing في MongoDB.” ——— وفقكم الله لكل خير 🌿

دردشة سريعة عن الـ Buffer في Node.js 💯 . . أغلب الوقت وإحنا بنكتب كود في Node.js، بنتعامل مع البيانات اللي راجعه من الـ APIs أو من الـ Database أو من الـ Files على هيئة Strings أو JSON. تمام كده؟ لكن، لو هنتعامل مع حاجات زي الصور، الملفات الصوتية، الفيديو، أو أي Data غير نصيّة (non-text)، وقتها الـ JavaScript ما تعرف تتعامل مع النوع ده بشكل مباشر. وهنا ييجي دور الـ Buffer. ——— 📌 إيه هو الـ Buffer؟ الـ Buffer هو ببساطة طريقة Node.js للتعامل مع البيانات الخام (Raw Binary Data) اللي راجعة من أو رايحة لمصدر خارجي، زي مثلًا File System أو TCP Stream، أو حتى من HTTP Response. يعني لو عندك فايل MP3، أنت مش هتقرأه كـ "نص"، أنت هتقرأه كـ سلسلة من الأرقام (bytes). والـ Buffer بيسمحلك تمسك السلسلة دي، وتتعامل معاها في الذاكرة. ——— 📦 ليه Node.js بتستخدم Buffers؟ علشان Node.js مبنية حول الـ Streams. والـ Streams في الغالب مش بتديلك البيانات كلها مرة واحدة، بتبعتها لك جزء جزء. مثال بسيط: لو بتقرأ فايل كبير من على الهارد، الـ Node.js مش هتحمّل الفايل كله في RAM مرة واحدة (عشان ده مش عملي وممكن يموت السيستم لو الفايل كبير جدًا)، هي بتقرأ Chunk بـ Chunk. كل Chunk من دول هو عبارة عن Buffer. ——— 💡 مثال عملي

const fs = require('fs');

const readableStream = fs.createReadStream('video.mp4');

readableStream.on('data', (chunk) => {
  console.log('Received chunk:', chunk);
  console.log('Chunk is a buffer?',    

  Buffer.isBuffer(chunk)); // true
});

في المثال ده، كل مرة الـ Stream بيبعت Data، بنستقبلها على هيئة Buffer. تقدر تتعامل معاها، تخزنها، تبعتها، أو حتى تعدّل فيها. ——— ✨ شوية حاجات مهمة عن Buffer: - الـ Buffer.from: بيحوّل أي String أو Array أو حتى ArrayBuffer لـ Buffer. - الـ Buffer.alloc(size): بيعمل Buffer فاضي بالحجم اللي تحدده. - الـ buffer.toString: لو عايز ترجّع الـ Buffer لصيغة String (لو أصلًا كانت Text). ——— لازم تكون فاهم يعني إيه Buffer في الحالات دي: - لو بتتعامل مع الملفات الكبيرة. - لو شغال على تطبيق بيستقبل صور أو فيديوهات أو أصوات. - لو شغال مع Streams (زي HTTP Requests أو TCP Connections). - لو بتبعت أو بتستقبل Binary Data من API أو جهاز تاني. ——— الـ Buffers بتشتغل على مستوى الـ Memory مباشرة، يعني لو معرفتش تتعامل معاهم صح، ممكن تقع في مشاكل زي memory leaks أو inefficient data handling. ——— وفقكم الله لكل خير 🌿

هل الـ Bundle Size بيأثر على أداء الموقع؟ 🚀 . . لو اشتغلت قبل كده على أي مشروع Front-End كبير، أكيد عدى عليك مصطلح "Bundle Size" سواء في PR review، أو وأنت بتعمل debugging، أو وأنت بتعمل optimization للـ Core Web Vitals… السؤال هنا: ⚠️ هل فعلًا حجم الـ Bundle بيفرق في الأداء؟ ولا مجرد رقم وخلاص؟ تعال ندردش شوية عن الـ Bundle Size... ——— 🎯 يعني إيه Bundle Size؟ ببساطة، لما بتكتب كود JavaScript (أو TypeScript أو JSX…)، الكود ده بيتحول لملف واحد (أو أكثر) اسمه Bundle. الملف ده بيحتوي كل حاجة: - الكود بتاعك - المكتبات اللي مستخدمها (زي lodash أو moment أو axios) - وأحيانًا حتى CSS modules أو images/inline SVGs الـ Bundle Size هو ببساطة حجم الملف ده اللي الـ browser بيحمله عشان يشغل الموقع. ——— 🤔 طب إزاي ده بيأثر على الأداء؟ هقولك بـ 5 نقاط بس، كل نقطة منهم كفيلة إنها تبوظ تجربة المستخدم: 1. وقت التحميل (Load Time) كل ما الـ Bundle بقى أكبر، كل ما المتصفح أخد وقت أطول في تحميله من السيرفر. يعني المستخدم هيقعد مستني، وده بيزود الـ Time To Interactive (TTI) و First Contentful Paint (FCP). 2. الـ Blocking الـ JavaScript ملفاتها Render-Blocking بطبعها. يعني الصفحة مش هتعرف تكمل تحميل غير لما تخلص تحميل وتنفيذ الـ JavaScript. 3. الـ Parsing والـ Execution المتصفح مش بس بيحمل الملف... ده كمان لازم يفكه ويفهمه ويشغّله. وده بياخد وقت ومعالجة (CPU)، وخصوصًا على الموبايلات الضعيفة. 4. تأثير مباشر على SEO و Core Web Vitals جوجل بتقيس سرعة الموقع، ولو الـ bundle تقيل = الموقع بطيء = ترتيبك في البحث بيقل. 5. الـ Data Cost لو فيه ناس بتزور موقعك من موبايلات أو باقات إنترنت محدودة، فكل ميجا زيادة في الـ Bundle بتكلفهم أكتر وبتزود احتمالية إنهم يسيبوا الموقع قبل ما يحمّل. ——— 📌 طيب نحل الموضوع ده إزاي؟ فيه أكثر من طريقة... 1. الـ Code Splitting بلاش تحمل كل الكود مرة واحدة، خليه على حسب الصفحة أو الـ component. استخدم React.lazy و Suspense أو dynamic imports في Next.js. 2. الـ Tree Shaking لو بتستخدم مكتبة زي lodash، بلاش تستورد كل حاجة: import _ from 'lodash' ❌ import debounce from 'lodash/debounce' ✅ 3. حذف الكود غير المستخدم (Unused Code) شوف إيه اللي مش مستخدم في الكود وشيله. استخدم أدوات زي PurgeCSS أو Unused Export Detection في Webpack أو Vite. 4. استخدم مكتبات خفيفة (Lighter Libraries) مثلًا: بلاش تستخدم moment.js واستخدم date-fns أو dayjs. عايز تعمل HTTP requests؟ بلاش تستخدم axios لو مش محتاج كل اللي فيه، الـ fetch كفاية. 5. الـ Compress & Minify سواء باستخدام Terser أو Brotli أو Gzip… كل ما تضغط الكود أكتر، كل ما الـ bundle حجمه بيقل. ——— فيه Tools كتير تقدر تديك رؤية واضحة عن الـ Bundle: - Webpack Bundle Analyzer - source-map-explorer - Bundlephobia ——— الـ Bundle Size بيفرق جدًا، وأي optimization في حجمه ممكن يعمل فرق ضخم في: - سرعة تحميل الموقع - تجربة المستخدم - ترتيبك في SEO - أداء الموبايلات الضعيفة ——— وفقكم الله لكل خير 🌿

Slow server components?

Don’t let users stare at a blank screen. React Suspense lets you load content progressively with smart fallbacks for a faster-feeling UI.

دردشة سريعة عن الـ ACID في الـ Database ⚡️ . . تخيل إنك شغال على 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. ——— الـ ACID هو اللي بيخلي الأنظمة البنكية، الـ e-commerce systems، والـ booking platforms تشتغل بثقة بدون ما يحصل فيها chaos. ——— وفقكم الله لكل خير 🌿

Top 5 JavaScript Testing Frameworks of 2025 ✅

مفهوم الـ Atomicity 💯 . . تخيل إنك شغال على سيستم تحويل فلوس. العميل حول 1000 جنيه من حسابه، السيستم خصم الفلوس… وقبل ما يضيفهم في حساب الشخص التاني، الكهرباء قطعت. كده الفلوس طارت؟ ولا هترجع؟ ولا هتتحول؟ السؤال ده بيجاوب عليه مفهوم مهم جدًا في البرمجة والـ Databasese وهو الـ Atomicity يا إما كل الخطوات تتم بالكامل...يا مفيش ولا خطوة تتم. ——— 🤔 يعني إيه Atomicity؟ تخيل إنك بتسحب فلوس من الـ ATM. العملية دي فيها خطوتين: 1- البنك يخصم المبلغ من حسابك. 2- الماكينة تطلع لك الفلوس. لو حصل إن السيستم عمل الخطوة الأولى بس، ووقف فجأة قبل ما يوصلك الفلوس… أنت كده خسرت فلوسك؟ هنا بقى ييجي دور الـ Atomicity. الـ Atomicity معناها إن العملية كلها تتنفذ بالكامل من أولها لآخرها، أو ما تتنفذ خالص. يعني All or Nothing. في مثال الـ ATM: يا البنك يخصم وتاخد الفلوس، يا ميحصلش أي حاجة أصلًا. مفيش نص عملية. ——— 💡 إزاي ده بيتم؟ الـ Atomicity هي واحدة من الـ ACID Properties اللي بتضمن سلامة البيانات خصوصًا في الـ Databases. علشان تحقق الـ Atomicity، السيستم بيستخدم حاجة اسمها Transactions. كل Transaction بتتكون من مجموعة عمليات (زي insert، update، delete)، والمفروض إن كل العمليات دي يحصلها commit في نفس الوقت، أو يحصلها rollback لو حصل أي خطأ. مثال:

BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;

لو أي واحدة من الـ 2 updates فشلت، الـ transaction كلها هتتفك، والداتا ترجع زي ما كانت كأن مفيش حاجة حصلت. ——— ⚠️ إيه اللي ممكن يبوّظ الـ Atomicity؟ - الـ Exceptions أو الـ Errors في جزء من الـ transaction. - إنك تنفذ queries من غير transaction أصلًا ولو السيستم مش بيطبق الـ Atomicity صح، الداتا ممكن تبقى corrupted، وساعتها ربنا يستر. ——— 📌 إيه الفرق بين الـ Atomicity وبين الـ Consistency؟ الـ Atomicity بتتكلم عن هل العملية كلها تمت أو لا؟ الـ Consistency بتسأل هل الداتا بعد العملية في حالة صحيحة؟ يعني: - الـ Atomicity = حصل commit كامل ولا لا؟ - الـ Consistency = لو حصل، الداتا بقت consistent ولا لا؟ الاتنين مكملين بعض، بس مش نفس الحاجة. ——— وفقكم الله لكل خير 🌿

SQL Aggregate Functions 💯

24 Good Resources to Learn Software Architecture in 2025 ✅

TypeScript Generics in React ⚡️