DevGuide

الفرق بين Hashing و Encoding و Encryption 🔐 . . وأنت بتشتغل في الباك إند، أو بتتعامل مع APIs، أو حتى بتشتغل على تطبيق بسيط فيه عملية تسجيل دخول… في الغالب قابلت مصطلحات زي Hashing و Encoding و Encryption. وممكن تفتكر إنهم شبه بعض، أو إن أي واحد فيهم "بيأمن البيانات وخلاص". لكن الحقيقة إن كل واحد له هدف مختلف تمامًا، ولو استخدمت حاجة غلط ممكن تفتح ثغرات أمنية وأنت مش واخد بالك. تعال ندردش شوية عن الفرق بينهم... ——— ✅ أولًا: الـ Hashing: تخيل إنك بتعمل بصمة لأي معلومة… مش علشان ترجع لها بعدين، لكن علشان تتأكد إنها متغيرتش. الـ Hashing بياخد قيمة (زي password مثلًا)، ويطلع منها سلسلة ثابتة الطول شكلها عشوائي – اسمها Hash – واللي بتستخدمها عشان تطابق أو تتحقق من البيانات من غير ما تحتاج تخزن الأصل. 🎯 المهم هنا: - العملية دي One Way (مفيش رجوع). - لو غيرت حرف واحد، الـ Hash كله بيتغير. - وده اللي بنستخدمه مثلًا لما نخزن الـ Passwords في قواعد البيانات. ⚠️ لو حد عرف الـ Hash، مش هيعرف يطلع منه الباسورد الأصلي (بس ممكن يعمل Brute Force ويحاول يخمنه). ——— ✅ ثانيًا: الـ Encoding: الـ Encoding هو طريقة بنحول بها البيانات لشكل تاني علشان يسهل تخزينها أو نقلها. زي Base64، اللي بتحول مثلًا صورة أو نص يحتوي رموز غريبة لشكل مفهوم لأي نظام. 🎯 المهم هنا: - العملية دي Two Way (تقدر ترجّع البيانات الأصلية). - مفيش أي حماية أو تشفير، أي حد يعرف نوع الـ encoding يقدر يفكه بسهولة. - الهدف منه بس إنك تنقل الداتا بدون ما تضيع أو تبوظ. مثال بسيط: لو عندك some text ممكن يتحول بـ Base64 إلى: c29tZSB0ZXh0 ——— ✅ ثالثًا: الـ Encryption: لو أنت عايز تبعت داتا سرية لحد، ومش عايز أي حد في النص يفهمها. هتعمل لها تشفير باستخدام مفتاح (Key)، والمستلم اللي معاه المفتاح يقدر يفكها. 🎯 المهم هنا: - العملية دي Two Way، بس لازم المفتاح. - لو المفتاح اتسرّب أو ضاع، أي حد يقدر يفك البيانات. - بتستخدمها في إرسال معلومات حساسة زي بطاقات الدفع أو بيانات المستخدمين. فيه نوعين من الـ Encryption: - الـ Symmetric: نفس المفتاح بيشفّر ويفك (زي AES). - الـ Asymmetric: مفتاحين، واحد بيشفّر (public) والتاني بيفك (private) – زي اللي بيستخدم في HTTPS.

#frontend

Software Testing with Playwright https://www.freecodecamp.org/news/software-testing-with-playwright

مصطلحات مهمة في عالم الـ System Design 💯 (٧) . . في البوست اللي فات عرفنا يعني إيه Replication و Sharding و Vertical Partitioning، وعرفنا إزاي نتعامل مع كميات ضخمة من البيانات. لكن حتى بعد كل ده، فيه سؤال مهم... هل كل Request لازم يروح للـ Database؟ تخيل إن الصفحة الرئيسية في موقعك بيدخلها مليون مستخدم في اليوم، وكلهم تقريبًا بيطلبوا نفس البيانات. هل منطقي إننا في كل مرة نروح نسأل الـ Database عن البيانات دي من أول وجديد؟ أكيد لا... لأن حتى أسرع Database لها حدود، وكل قراءة زيادة معناها ضغط أكبر، واستهلاك أعلى للموارد. ——— 📌 Caching الـ Cache عبارة عن مكان بنخزن فيه البيانات اللي بنستخدمها بشكل متكرر، بحيث لما حد يطلبها مرة تانية، نرجعها بسرعة بدل ما نروح لقاعدة البيانات. لو فيه عندك بيانات ثابتة معظم الوقت، ومبيحصلش عليها تغييرات كتير، فمش منطقي إن كل Request يروح للـ Database. أول Request لو البيانات مش موجودة في الـ Cache وده اسمه  (Cache Miss)، يجيبها من الـ Database ويحفظها في الـ Cache، وبعدها الطلبات التالية تعمل Cache Hit. وده واحد من أهم الأسباب اللي بتخلي التطبيقات تكون سريعة الاستجابة، وفي نفس الوقت بيقلل الضغط على قاعدة البيانات. لكن استخدام الـ Cache مش بيحل كل المشاكل. ——— 📌 Denormalization فاكر لما تكلمنا عن SQL Databases؟ وقتها قلنا إننا بنقسم البيانات على جداول مختلفة، علشان نقلل تكرار البيانات ونحافظ عليها منظمة. وده فعلًا أفضل تصميم في حالات كتير. لكن مع زيادة عدد المستخدمين، ممكن تلاقي إنك كل مرة تعرض صفحة واحدة، محتاج تعمل Join بين 4 أو 5 جداول. وده بيكلف قاعدة البيانات وقت ومجهود مع كل Request. هنا بعض الأنظمة بتاخد قرار مختلف. بدل ما تمنع تكرار البيانات، تسمح بتكرار جزء منها، مقابل إن القراءة تبقى أسرع. يعني مثلًا، بدل ما كل مرة تجيب اسم المستخدم من جدول Users، ممكن تخزن اسمه داخل جدول Orders نفسه. أيوه... البيانات بقت مكررة. لكن في المقابل، بقيت تقدر تجيب بيانات الأوردر في Query واحدة، من غير Joins كتير. وده اسمه Denormalization. لكن ليه تمن. لأن لو اسم المستخدم تغير، هتحتاج تحدثه في أكتر من مكان. ومن هنا تبدأ تكتشف إن الـ System Design معظمه عبارة عن Trade-offs. كل قرار بيحل مشكلة، لكنه في المقابل بيخلق تحديات جديدة. ——— 📌 CAP Theorem بعد ما بدأنا نستخدم أكتر من Database، وعملنا Replication و Sharding، كده إحنا دخلنا عالم الـ Distributed Systems. وفي العالم ده، فيه سؤال مهم جدًا... هل ينفع كل السيرفرات تشوف نفس البيانات، والنظام يفضل متاح للمستخدمين، حتى لو حصلت مشكلة في الشبكة؟ للأسف... لا. وده بالظبط اللي بتشرحه CAP Theorem. النظرية دي بتقول إن في الأنظمة الموزعة، لو حصل Network Partition، مش هتقدر تحقق كل المميزات في نفس الوقت. في الحالة دي، لازم تختار بين Consistency و Availability، لأن Partition Tolerance أصبحت مفروضة عليك. فهل الأهم إن كل المستخدمين يشوفوا نفس البيانات، حتى لو بعض الطلبات هتتأخر؟ ولا الأهم إن النظام يفضل شغال ويرد على المستخدمين، حتى لو بعض البيانات تكون لسه متحدثتش في كل السيرفرات؟ علشان كده هتلاقي إن مفيش Database أو Distributed System ينفع لكل السيناريوهات. كل واحد معمول علشان يوازن بين احتياجات مختلفة. ——— 💡 الخلاصة النهارده عرفنا 3 مفاهيم مهمين جدًا في تحسين أداء الأنظمة: • الـ Caching: تخزين البيانات المستخدمة باستمرار في مكان أسرع، لتقليل الضغط على قاعدة البيانات. • الـ Denormalization: تكرار جزء من البيانات لتقليل الـ Joins وتسريع عمليات القراءة. • الـ CAP Theorem: عند حدوث Network Partition، لازم تختار بين Consistency و Availability. ——— دلوقتي بقينا نعرف إزاي نخلي الوصول للبيانات أسرع. لكن... التطبيقات مش بتتعامل مع بيانات بس. إيه اللي بيحصل مع الصور، والفيديوهات، والملفات؟ وهل منطقي نخزنها كلها داخل قاعدة البيانات؟ ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Blob Storage و CDN وكمان هنتكلم عن الـ WebSockets

Introducing Claude Opus 5. It's a thoughtful and proactive model that comes close to the frontier intelligence of Fable 5 at half the price. https://www.anthropic.com/news/claude-opus-5 . . #ai

CSS: Tabular Numbers In CSS, tabular numbers force digits to take up the exact same horizontal width. . . #css

مصطلحات مهمة في عالم الـ System Design 💯 (٦) . . في البوست اللي فات عرفنا إزاي نزود عدد السيرفرات باستخدام الـ Horizontal Scaling، وإزاي الـ Load Balancer بيوزع الـ Requests بينهم. لكن مع الوقت، المشكلة الحقيقية غالبًا بتكون في قاعدة البيانات نفسها. تخيل إن عندك ملايين المستخدمين، ومئات الملايين من الطلبات، وكل السيرفرات بتقرأ وتكتب في نفس الـ Database. في مرحلة معينة هتلاقي إن قاعدة البيانات بقت هي المشكلة الأكبر والأهم... وقتها بنبدأ نفكر إزاي هنحل المشكلة دي... ——— 📌 Replication أول حل هو إننا نعمل نسخ متعددة من قاعدة البيانات. يبقى عندنا: • Primary Database تستقبل عمليات الكتابة (Write). • Replica Databases تستقبل عمليات القراءة (Read). تخيل إن عندك مكتبة عليها زحمة. بدل ما الناس كلها تقف على نسخة واحدة من الكتاب، بتعمل نسخ إضافية علشان عدد أكبر من الناس يقدر يقرأ في نفس الوقت. وده بالضبط اللي بيحصل مع Replication. الميزة إنك تقدر توزع عمليات القراءة على أكتر من Replica، فتخفف الضغط على الـ Primary Database. لكن إيه اللي هيحصل لو حجم البيانات نفسه بقى ضخم جدًا، حتى النسخ المتعددة مش كفاية؟ ——— 📌 Sharding هنا بنقسم البيانات نفسها. بدل ما كل المستخدمين موجودين في قاعدة بيانات واحدة، ممكن نقسمهم على عدة قواعد بيانات. كأن عندك ملف ضخم جدًا، فقسمته على عدة أدراج بدل ما تحطه كله في درج واحد. الميزة إن كل Shard يشيل جزء من البيانات فقط، وبالتالي الضغط يتوزع. لكن الـ Sharding بيضيف تعقيد أكبر، لأن التطبيق لازم يعرف البيانات المطلوبة موجودة في أي Shard. ——— 📌 Vertical Partitioning تخيل جدول مستخدمين فيه: - الاسم - الإيميل - رقم التليفون - الصورة - العنوان - إعدادات الحساب - بيانات إضافية تانية… مش كل الطلبات محتاجة كل الأعمدة دي. فممكن نفصل البيانات الأساسية في جدول، والبيانات الأقل استخدامًا في جدول تاني. وده اسمه Vertical Partitioning. يعني بدل ما كل Query تقرأ جدول ضخم، تقرأ الجزء اللي محتاجاه فقط. ——— 💡 الخلاصة النهارده عرفنا 3 طرق مختلفة علشان نكبر قاعدة البيانات: • الـ Replication: إنشاء نسخ متعددة من قاعدة البيانات لتوزيع عمليات القراءة. • الـ Sharding: تقسيم البيانات على عدة قواعد بيانات مختلفة. • الـ Vertical Partitioning: تقسيم الأعمدة داخل الجداول لتقليل حجم البيانات المقروءة في كل Query. دلوقتي نقدر نتعامل مع قواعد بيانات ضخمة جدًا. لكن… حتى مع كل التقسيم والنسخ دي، لسه فيه مشكلة ممكن تقتل الأداء: إننا نروح نكلم قاعدة البيانات في كل Request. وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Caching و Denormalization و CAP Theorem. ——— #system_design

AI Engineering from Scratch 💯 503 lessons. 20 phases. Every algorithm built from raw math before a single framework gets imported. https://aiengineeringfromscratch.com

مصطلحات مهمة في عالم الـ System Design 💯 (٥) . . في البوست اللي فات تكلمنا عن Vertical Scaling، وإن أبسط حل لزيادة الضغط هو إننا نقوّي السيرفر الحالي... لكن تخيل إن عندك تطبيق وعدد المستخدمين زاد جدًا، وكل ما تزود RAM أو CPU تلاقي الضغط بيرجع يزيد تاني. في لحظة معينة هتوصل لأقصى قدرة ممكنة للسيرفر. إيه الحل؟ ——— 📌 Horizontal Scaling بدل ما نقوّي سيرفر واحد، نضيف سيرفرات جديدة. يعني لو عندك سيرفر واحد عليه ضغط عالي، ممكن تخلي عندك 2 أو 5 أو 10 سيرفرات يشيلوا الحمل مع بعض. وده اسمه Horizontal Scaling أو Scale Out. تخيل مطعم فيه موظف واحد بيستقبل الطلبات. لما الزحمة تزيد، بدل ما نجيبله مكتب أكبر، نجيب موظفين إضافيين يساعدوه. نفس الفكرة بالضبط. الميزة هنا إنك تقدر تزود عدد السيرفرات تدريجيًا حسب عدد المستخدمين. لكن ظهر سؤال جديد… لو عندي 10 سيرفرات، الـ Request يروح لمين فيهم؟ ——— 📌 Load Balancer هنا ييجي دور الـ Load Balancer. هو جهاز أو خدمة بتقف قدام كل السيرفرات، وأي Request جديد يوصله، يقرر يبعته لأي سيرفر. يعني بدل ما المستخدم يختار بنفسه، الـ Load Balancer هو اللي يوزع الطلبات بشكل ذكي. مثلًا: - السيرفر الأول مشغول جدًا - ابعت الطلب لسيرفر تاني. - سيرفر وقع أو فيه مشكلة - متبعتلوش أي Requests. - عايز توزع الحمل بالتساوي - وزّع الطلبات على كل السيرفرات. من غير Load Balancer، ممكن سيرفر واحد ينهار من الضغط بينما باقي السيرفرات فاضية. وده سبب إن أي نظام قابل للتوسع تقريبًا بيستخدم Load Balancer بشكل أو بآخر. لكن حتى بعد توزيع الحمل، فيه مشكلة تانية ممكن تبطّأ النظام… ——— 📌 Database Indexing تخيل إن عندك كتاب فيه 1000 صفحة، وعايز تدور على موضوع معين. هل هتقرأ الكتاب كله صفحة صفحة؟ أكيد لا. هتروح للفهرس الأول. الـ Index في قاعدة البيانات بيعمل نفس الفكرة. بدل ما الـ Database تفتش في كل الصفوف علشان تلاقي مستخدم أو أوردر معين، تستخدم الـ Index علشان توصل للبيانات بسرعة. مثلًا لو بتبحث كتير باستخدام email، ممكن تعمل Index على العمود ده هيخلّي البحث أسرع بفرق كبير. لكن خلي بالك، كل Index إضافي بياخد مساحة، وبيخلّي عمليات الكتابة أبطأ شوية، علشان كده بنعمل Index للأعمدة اللي عليها عمليات بحث كتيرة. ——— 💡 الخلاصة النهارده عرفنا إزاي الأنظمة الكبيرة تتعامل مع زيادة عدد المستخدمين: • الـ Horizontal Scaling: إضافة سيرفرات جديدة بدل تقوية سيرفر واحد. • الـ Load Balancer: توزيع الـ Requests على السيرفرات بشكل ذكي. • الـ Database Indexing: تسريع البحث داخل قاعدة البيانات باستخدام Indexes. ——— دلوقتي بقينا نقدر نشغّل أكتر من سيرفر ونوزّع الحمل بينهم. لكن إيه اللي هيحصل لو قاعدة البيانات بقت كبيرة جدًا؟ ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Replication و Sharding و Vertical Partitioning. ——— #system_design

مصطلحات مهمة في عالم الـ System Design 💯 (٤) . . في البوست اللي فات عرفنا إزاي الـ Client يطلب بيانات من السيرفر باستخدام APIs، سواء كانت REST أو GraphQL. لكن فيه سؤال مهم جدًا… السيرفر بيجيب البيانات دي منين؟ لما تفتح بروفايل مستخدم، أو تشوف قائمة المنتجات، أو تبحث عن أوردر معين، أكيد البيانات دي لازم تكون متخزنة في مكان ما. وهنا يظهر دور الـ Database... ——— 📌 Databases الـ Database هي المكان اللي بنخزن فيه البيانات بشكل منظم. بدل ما التطبيق يعتمد على الذاكرة فقط، بيخزن البيانات بشكل دائم في قاعدة بيانات علشان يقدر يرجع لها في أي وقت. تخيل عندك متجر إلكتروني. فيه منتجات، ومستخدمين، وأوردرات، وعمليات دفع. كل المعلومات دي بتتخزن داخل الـ Database. ولما المستخدم يطلب حاجة، السيرفر يروح يجيب البيانات من قاعدة البيانات ويرجع النتيجة. لكن مش كل قواعد البيانات بتشتغل بنفس الطريقة. وهنا ييجي السؤال اللي بيتكرر كتير في أي Interview… SQL or NoSQL? ——— 📌 SQL vs NoSQL قواعد بيانات SQL بتكون منظمة في جداول وعلاقات واضحة بين البيانات. زي مثلًا: - جدول للمستخدمين - جدول للطلبات - جدول للمنتجات والعلاقات بينهم بتكون محددة بشكل واضح. أشهر الأمثلة: - PostgreSQL - MySQL - SQL Server أما NoSQL فبتكون أكثر مرونة. ممكن تخزن البيانات على شكل Documents أو Key-Value أو Graphs، من غير ما تكون ملتزم بنفس شكل الجداول التقليدي. أشهر الأمثلة: - MongoDB - Redis - Cassandra ——— طيب أختار إيه؟ لو عندك بيانات مترابطة وعايز معاملات تضمن سلامة البيانات، غالبًا SQL هيكون مناسب. لو شكل البيانات بيتغير باستمرار، أو محتاج مرونة أكبر في التوسع، ممكن NoSQL يكون اختيار مناسب. لكن مع الوقت، حتى لو اخترت النوع المناسب، هتواجه مشكلة تانية… المستخدمين بيزيدوا، والضغط على السيستم بيزيد... ——— 📌 Vertical Scaling تخيل إن عندك سيرفر واحد، وكل حاجة شغالة عليه. وفجأة عدد المستخدمين زاد جدًا. أبسط حل يخطر في بالك إنك تزود إمكانيات السيرفر نفسه. وده اسمه Vertical Scaling أو Scale Up. يعني بدل ما تغير النظام كله، بتقوي الجهاز الحالي. الحل ده سهل وسريع في البداية، لكنه له حدود. لأن في مرحلة معينة، مهما زودت إمكانيات السيرفر، هتوصل لأقصى قدرة ممكنة، وساعتها هتحتاج تفكر بطريقة مختلفة. ——— 💡 الخلاصة • الـ Database: المكان اللي بيتخزن فيه كل بيانات التطبيق. • الـ SQL: قواعد بيانات منظمة بعلاقات واضحة بين الجداول. • الـ NoSQL: قواعد بيانات مرنة تناسب البيانات المتغيرة والتوسع بسهولة. • الـ Vertical Scaling: تقوية السيرفر الحالي بزيادة الـ CPU أو الـ RAM أو الـ Storage. ——— دلوقتي عرفنا أول طريقة للتعامل مع زيادة الضغط على السيستم. لكن إيه اللي هيحصل لو السيرفر نفسه وصل لأقصى إمكانياته المسموح بها ومبقاش كافي لوحده؟ ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Horizontal Scaling وLoad Balancer وDatabase Indexing. ——— #system_design