DevGuide

🔰 How to Use Rem Units in CSS

Rem units in CSS can be used for setting font sizes, margins, padding, widths, and heights relative to the root element's font-size. 💯

أكيد تعرف npm install أو npm i . . لكن هل تعرف npm ci؟ لما تكتب npm install، هو بيبص على الـ package.json ويشوف إيه الـ packages المطلوبة، وبعدين: - لو فيه package-lock.json بيحاول يطابقه. - ولو مش موجود، بيبدأ يركّب اللي محتاجه ويعمل واحد جديد. - وكمان ممكن يحدث بعض الـ packages لو شاف إن فيه إصدار أحدث متوافق مع الشروط. وطبعًا ده كويس لكن ممكن يحصل اختلافات من جهاز للتاني... ——— الـ ci معناها "continuous integration"، والأمر ده معمول مخصوص عشان الـ automation وبيشتغل بشكل أسرع وأسهل. - بيمسح فولدر node_modules تمامًا. - وبعدين يركّب الـ packages بالضبط زي ما هي مكتوبة في package-lock.json. - لو فيه فرق بين package.json و package-lock.json بيقف ويعمل Error. ✅ ده معناه إن npm ci: - أسرع من install. - بيعمل نفس النتائج كل مرة. - ممتاز في الـ CI/CD pipelines أو في الشركات الكبيرة. ——— لو شغال لوحدك ولسه بتضيف/تحدث packages: استخدم npm install. لو بتشتغل في تيم أو بتعمل Deploy على سيرفر: استخدم npm ci عشان تضمن ثبات البيئة.

إزاي نضمن إن المشروع شغّال زي ما العميل متوقع؟ 💯 . . الـ Testing مش مجرد خطوة بنعملها في الآخر "علشان نطمن"، ولا هو شوية Test Cases بنكتبهم والسلام. الموضوع أعمق من كده بكتير... واللي بيحدد شكله وتوقيته وطريقته هو نوع الـ Software Development Methodology اللي المشروع شغال بها. ——— 📌 أولًا.. يعني إيه Software Testing؟ باختصار، الـ Testing هو الطريقة اللي بنكتشف بها الـ bugs قبل ما توصل للمستخدم. وكمان بنقيس هل الـ software بيحقق الـ requirements ولا لا؟ هل قابل للاستخدام؟ هل بيشتغل كويس تحت الضغط؟ هل الـ UI سهل وواضح؟ كل دي أنواع مختلفة من الـ Testing... ——— 📌 إزاي الـ Methodology بتأثر على الـ Testing؟ تعال نعرف الفرق... 1. الـ Waterfall Model: في الـ Waterfall، الـ Testing بييجي في الآخر بعد ما كل حاجة تخلص. يعني: Requirements ➡️ Design ➡️ Development ➡️ Testing 📌 ده معناه إنك مش هتبدأ تختبر غير لما المشروع كله يكون جاهز. وده بيخلي الـ Testing عبارة عن Quality Gate: لو الكود فيه مشاكل، بنرجع خطوة ورا، ونصلح. ⚠️ العيب هنا؟ لو فيه bug في البداية، هتكتشفه متأخر جدًا، وهتكلفك كتير. ——— 2. الـ Agile Methodology: موجود في معظم الشركات دلوقتي. هنا بنشتغل في Sprints قصيرة، والـ Testing بيكون جزء من كل Sprint. 📌 الـ Testing بيحصل مع كل ميزة جديدة. والـ QA بقى جزء من التيم من أول يوم. 🎯 النتيجة؟ - بتقدر تكتشف الـ Bugs بدري - كمان تقدر تاخد Feedback من العميل بشكل مستمر علشان لو فيه تعديل - وطبعًا التكلفة هتكون أقل ——— 3. الـ DevOps / Continuous Integration: هنا الـ testing بيكون جزء من الـ pipeline نفسها. 📌 هنا بنستخدم Tools زي Jest أو Cypress أو Selenium، وغيرها، نكتب بها Automated Tests وأول ما الـ developer يعمل Push، الـ Tests بتشتغل أوتوماتيك. 🔥 ده بيخلي الـ Testing جزء من حياة الكود، مش خطوة منفصلة. ——— ✅ لازم تبقى فاهم نوع الـ methodology اللي المشروع ماشي بها، علشان تعرف إمتى وإزاي تختبر. ✅ بلاش تعتمد بس على الـ QA، أنت كـ Developer مسؤول عن كتابة Unit Tests على الأقل. ✅ كل ما تكتب Tests أكتر، كل ما الكود بتاعك هيبقى أسهل في الـ Refactor، وأقل Bugs.

How Node.js Handles Async Code 💯

System Design was HARD until I Learned these 30 Concepts 💯 https://blog.algomaster.io/p/30-system-design-concepts

دورة مجانية: مقدمة في Laravel تهدف الدورة إلى التعرف على بنية MVC (Model-View-Controller) ودورها الأساسي في تنظيم وتطوير تطبيقات الويب، وفهم كيفية تقسيم البرنامج إلى مكوناته الرئيسية لضمان كتابة كود منظم وقابل للتطوير، بالإضافة إلى التعرف على كيفية استخدام Laravel لتسهيل العمل مع كل من النماذج (Models)، الواجهات (Views)، ووحدات التحكم (Controllers). https://satr.tuwaiq.edu.sa/course/lgdjP05YC9/view

Most Used Linux Commands 💯

git fetch vs. git pull vs. git pull --rebase

لو شغال على أي مشروع TypeScript/JavaScript، وعايز الـ VS Code يشيل الـ imports غير المستخدمة تلقائيًا أول ما تعمل Save، كل اللي عليك تضيف الجزء ده في إعدادات VS Code 👇🏻

The Critical Rendering Path is one of the most important browser concepts every front end engineer should understand. 💯

إزاي تعرض شغلك كـ 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 فيها مشاريع حقيقية - اعرض 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.” ——— بالتوفيق 🌹

كل عام وأنتم بخير، تقبل الله منا ومنكم صالح الأعمال. 🤍🌹

7 Tips to Improve CTR (Click-Through Rate) ⚡️ Crucial for driving traffic and maximizing the impact of your content.

دردشة سريعة عن الـ OAuth 2.0 💡 . . تخيل إنك داخل تسجّل في تطبيق جديد علشان تتابع كورسات، ولما جيت تسجّل، التطبيق قالك: "تقدر تسجّل بحساب Google أو GitHub بدل ما تعمل أكونت جديد" ضغطت على زرار "Continue with Google"، وGoogle طلبت منك تختار الإيميل وتوافق على شوية صلاحيات. بعدها التطبيق فتح واشتغل وكأنك عملت sign up فعلًا... إيه اللي حصل هنا؟ 🤔 اللي حصل بالضبط هو إن Google استخدمت حاجة اسمها OAuth 2.0. ———

📌 يعني إيه OAuth 2.0؟

ببساطة، الـ OAuth 2.0 هو بروتوكول authorization (مش authentication)، بيخلّي التطبيقات تقدر تاخد إذن من المستخدم عشان تدخل على جزء من معلوماته في service تانية (زي Google, Facebook, GitHub) من غير ما يعرفوا الباسورد بتاعتك. يعني التطبيق اللي بتستخدمه مش بيشوف الباسورد بتاعتك، بس بياخد توكن مؤقت يقدر يستخدمه يدخل على الـ APIs اللي أنت وافقت عليها. وده بيخلي العملية آمنة، وبيحافظ على الخصوصية بتاعتك. ———

📌 إزاي الـ OAuth 2.0 بيشتغل؟

تعال نمشي خطوة بخطوة في الـ flow المشهور بتاع Authorization Code Grant Flow، واللي بيستخدم في web apps 1- الـ User Requests Login التطبيق (Client) يقولك: "سجّل بحساب Google مثلًا"، والمستخدم يضغط على الزرار، ويتم توجيهه على authorization server (زي Google). 2- الـ User Grants Permission جوجل يطلب منك تسجّل دخول وتوافق على الـ permissions اللي التطبيق طالبها (زي الإيميل، الاسم، إلخ). 3- الـ Authorization Code لو وافقت، Google هيبعت authorization code للتطبيق (أو تحديدًا للـ redirect URL اللي التطبيق حدده قبل كده). 4- الـ Token Exchange التطبيق ياخد الـ authorization code ده ويبعت request لـ token endpoint علشان يبدله بـ  access token (وساعات كمان refresh token). 5- الـ Access Protected APIs بمجرد ما التطبيق ياخد الـ access token، يقدر يستخدمه يطلب بيانات من Google APIs، بس في حدود الـ scope اللي وافقت عليه. ———

إزاي بيأمن الـ APIs؟ 🔐

لو عندك API وعايز تأمنها، ممكن تستخدم OAuth 2.0 بحيث: - أي Client مش هيقدر يوصل لـ API غير لما يقدّم Access Token صالح. - الـ Backend بتاعك يقدر يتحقّق من التوكن (مثلًا JWT أو عن طريق introspection endpoint). - تقدر تتحكّم في الصلاحيات عن طريق الـ scope (يعني مثلًا توكن معين يقدر يقرأ بس، وتوكن تاني يقدر يكتب ويعدّل). - تقدر تسحب صلاحيات التوكن في أي وقت (Revoke). بالتالي، OAuth 2.0 بيأمّن الـ APIs عن طريق إنه: ✅ بيقلل الاعتماد على كلمات المرور ✅ بيسمح بالـ delegation (تطبيق ياخد إذن من مستخدم يوصل لحاجة مش بتاعته) ✅ بيخلي الـ tokens مؤقتة، وممكن تتحكم في صلاحياتها ومدّتها ———

📌 أنواع الـGrant Types المشهورة:

- الـ Authorization Code (with PKCE): للموبايل والويب. - الـ Client Credentials: للـ machine-to-machine apps. - الـ Password (deprecated): كان بيستخدم لما المستخدم يكتب الـ username والباسورد في نفس التطبيق (غير آمن). - الـ Implicit (deprecated): زمان كان بيتستخدم للـ SPA apps لكنه غير موصى به. ——— لو كنت بتستخدم OAuth 2.0 في موبايل أو SPA app، لازم تستخدم حاجة اسمها PKCE (Proof Key for Code Exchange) علشان تمنع الـ authorization code من إنه يتسرق.

دردشة سريعة عن الـ Cron Job ⚡️ . . تخيل معايا كده… أنت عندك تطبيق بيبعت Reminder للمستخدمين كل يوم الساعة 9 الصبح. أو متجر إلكتروني محتاج كل يوم بالليل يعمل تحديث للأسعار أو ينضف الـ expired data. أو حتى نظام بيطلع تقارير آخر كل شهر بشكل أوتوماتيك... هل كل شوية هنقف مستنيين الوقت ييجي ونشغل الحاجة بإيدينا؟ أكيد لا.. وهنا يظهر مفهوم مهم جدًا في حتة الـ automation… الـ Cron Job. --- 📌 يعني إيه Cron Job؟ ببساطة جدًا… الـ Cron Job هو Task أو Process بتتحدد إنها تشتغل بشكل تلقائي في وقت معين أو كل فترة معينة. يعني بدل ما حد يشغل Script بإيده، الـ System نفسه بيشغلها أوتوماتيك حسب Schedule أنت محدده. وده بيتم غالبًا عن طريق حاجة اسمها cron أو scheduler حسب الـ OS أو الـ Framework المستخدم. --- 📌 أشهر استخدامات الـ Cron Jobs الـ Cron Jobs حرفيًا موجودة في أي System كبير تقريبًا. ومن أشهر استخداماتها: 1. إرسال الإيميلات زي: - Welcome emails - Daily reminders - OTP cleanup - Newsletter --- 2. تنظيف الـ Database زي: - حذف الـ expired sessions - حذف الـ temp files - عمل archive للـ old data --- 3. تشغيل Background Tasks زي: - Generate reports - Export files - Sync data between systems --- 4. Monitoring & Health Checks زي: - التأكد إن Service شغالة - إرسال Alert لو حصل Crash - مراقبة الـ CPU أو Memory usage --- 5. Scheduled Business Logic ودي مهمة جدًا. مثلاً: - خصومات تشتغل الجمعة الساعة 12 - اشتراك ينتهي تلقائي - تجديد باقات - قفل حجز بعد وقت معين --- 📌 إزاي الـ Cron Job بتشتغل؟ أنت ببساطة بتقول للـ System: "شغّل الـ Task دي كل قد إيه؟" مثلًا: - كل دقيقة - كل ساعة - كل يوم الساعة 12 - كل يوم جمعة - أول يوم في الشهر وهكذا. في Linux مثلًا بيكون عندك Syntax مشهور كده: * * * * * command الخمس نجوم دول بيمثلوا: - minute - hour - day of month - month - day of week --- 📌 مشاكل ممكن تحصل مع الـ Cron Jobs 1. التاسك تشتغل مرتين وده بيحصل أحيانًا في الـ distributed systems. خصوصًا لو عندك أكتر من Server وكلهم شغلوا نفس الـ job. 2. التاسك تاخد وقت أطول من المتوقع يعني Job لسه شغالة، والـ scheduler يشغل واحدة جديدة... وده ممكن يعمل: - duplicate processing - race conditions - problems in data 3. Silent Failures ودي من أخطر الحاجات. الـ Job ممكن تقع وأنت أصلًا مش عارف إنها وقعت. عشان كده لازم يكون عندك : - logging - monitoring - alerts --- الـ Cron Job مش المفروض تعمل Heavy Work لو عندك Processing ضخم، الأفضل تستخدم: - Queues - Workers - Message Brokers زي: - RabbitMQ - Kafka - BullMQ - Sidekiq والـ Cron Job يبقى مجرد Trigger للحاجة دي.