DevGuide

مفهوم الـ Dependency Inversion Principle 💡 . . فيه مبدأ من مبادئ SOLID بيغيّر طريقة تفكيرك في تصميم الكود بشكل كبير جدًا... مبدأ أول ما تفهمه كويس وتطبّقه صح، هتحس إن المشروع بقى modular أكتر، والـ testing بقى أسهل، والـ bugs بقت قليلة إلى حد ما... تعال ندردش شوية عن مبدأ الـ Dependency Inversion... ——— 📌 يعني إيه Dependency Inversion Principle؟ المبدأ ده بيقول: "High-level modules should not depend on low-level modules. Both should depend on abstractions." و "Abstractions should not depend on details. Details should depend on abstractions." يعني لما تيجي تبني جزء كبير من السيستم (زي مثلاً order service في تطبيق تجارة إلكترونية)، المفروض ميكنش الـ high-level logic (زي إزاي الـ order بيتم) بيعتمد مباشرة على الـ details زي مثلا API معين أو database معينة أو class بتبعت إيميلات. بدل كده، المفروض يكون بيعتمد على abstraction (interface أو contract)، بحيث التفاصيل دي تقدر تتغير بسهولة بعد كده من غير ما تغيّر في الـ business logic نفسه. ———

📦 مثال بسيط:

[ كل الأكواد في التعليقات 👇 ]

class EmailService {
  sendEmail(to: string, body: string) {
    // logic to send email
  }
}

class OrderService {
  private emailService = new EmailService();

  placeOrder(orderData: any) {
    // logic to place order
    this.emailService.sendEmail(orderData.customerEmail, "Order placed!");
  }
}

كده الـ OrderService معتمد بشكل مباشر على الـ EmailService. لو حبيت تغير وسيلة إرسال الإيميل أو تبعتها عبر SMS أو push notification، هتضطر تغيّر في الكود بتاع OrderService نفسه… وده ضد مبدأ open/closed principle كمان. ———

✅ الحل؟

interface Notifier {
  notify(to: string, message: string): void;
}

class EmailService implements Notifier {
  notify(to: string, message: string) {
    // send email
  }
}

class SMSService implements Notifier {
  notify(to: string, message: string) {
    // send sms
  }
}

class OrderService {
  constructor(private notifier: Notifier) {}

  placeOrder(orderData: any) {
    // logic to place order
    this.notifier.notify(orderData.customerContact, "Order placed!");
  }
}

كده الـ OrderService ميعرفش أي حاجة عن الـ implementation بتاع الـ notifier، سواء كان email أو sms. هو بس بيتعامل مع abstraction (interface اسمها Notifier). وبالتالي تقدر تغير الـ implementation في أي وقت من غير ما تلمس الـ OrderService. ———

💡 إزاي ده هيفرق معاك؟

- الكود بتاعك بقى loosely coupled. - بقى modular وأسهل في التعديل والصيانة. - الـ testing بقى أبسط لأنك تقدر تعمل mock لـ Notifier بسهولة. - بقيت تقدر تبدّل الـ implementation من غير ما تعمل refactor تقيل. ——— الـ Dependency Inversion بيخليك دايمًا تفكر في dependencies على إنها شيء ممكن يتغير… فبدل ما تبني عليها بشكل مباشر، استخدم abstraction تفصل به بين high-level logic و low-level details. ——— وفقكم الله لكل خير 🌿

Struggling with authentication bugs? ⚠️ Learn clean NextAuth.js patterns to secure your Next.js app like a pro!

System Design was HARD until I Learned these 30 Concepts 💯 https://medium.com/algomaster-io/system-design-was-hard-until-i-learned-these-30-concepts-78042ff99cae

لو بتشتغل فرونت إند أو مهتم تبني سيستم كبير ومحترم، فالمقال ده هيفيدك جدًا. 🚀 . . جمعتلك فيه أهم المفاهيم والممارسات الحديثة في تصميم معماريات الفرونت إند، زي الفرق بين MVC و Flux و Micro Frontends، وإمتى تستخدم كل واحد فيهم، وكمان أفضل الأدوات والتقنيات اللي ممكن تعتمد عليها في كل حالة. هتلاقي كمان قسم عن تحسين الأداء، وإزاي تختبر وتعمل Debug بشكل احترافي، وكمان مفاهيم مهمة زي الـ Edge Computing و WASM. 📘 المقال يعتبر دليل شامل لأي حد عاوز يبني تطبيق فرونت إند قوي، قابل للتوسّع وسهل الصيانة. ——— Modern Frontend Architecture: A Definitive Guide for Scalable Web Applications 🚀 ———

🔗 Medium:

https://medium.com/@dev.alisamir/modern-frontend-architecture-a-definitive-guide-for-scalable-web-applications-693e5bf2a932

🔗 DEV Community:

https://dev.to/alisamir/modern-frontend-architecture-a-definitive-guide-for-scalable-web-applications-2mj3

🌐 يعني إيه DNS؟ . . أول ما بتفتح المتصفح وتكتب مثلًا: www.google.com إيه اللي بيخلي الموقع ده يظهر لك؟ هل المتصفح بيبقى عارف هو فين؟ هل اسم الموقع ده لوحده كفاية؟ الإجابة طبعًا لا... اللي بيحصل ورا الكواليس أعقد من كده شوية… وده اللي بيدخلنا في موضوع اسمه DNS – Domain Name System، وده واحد من أهم أساسيات مجال الويب... ———

🔗 LinkedIn:

https://www.linkedin.com/posts/mentoor-io_webdevelopment-webdeveloper-mentoor-activity-7355991093995286528-VyVX

🔗 Facebook:

https://www.facebook.com/mentoor.io/posts/pfbid04kpidgbkXsH44S6A9YsAprDVdQZwvzG6ZKQqj2nzBa5STmCV8rqsZ4rtMXibWXRhl

🔗 Qabilah:

https://qabilah.com/posts/R0dGIj7iNKg

🔅 Figma Oversimplified (2025)

Learn Figma in 13 minutes by covering all the core concepts you need to get started.

⏰ Timestamps: 00:00 - Intro 01:20 - Getting started 01:58 - Interface & Tools 03:54 - Frames 04:22 - Plugins 04:41 - Layouts 07:36 - Components 08:51 - Variants & Prototypes 09:59 - Design to product 11:09 - Low-code plugins

🔰 Working with URLs in JavaScript!!

Key JavaScript URL operations to simplify building, parsing, and dynamically managing web resources efficiently.

React Native Bootcamp in 30 HOURS for FREE 💯 https://youtu.be/q3HE1dFiJBI

No more loading states all over your code!

React Suspense in React 19 makes data fetching clean, declarative, and responsive.

سنوات الخبرة 🔻 . . هو أنا عندي كام سنة خبرة في مجال البرمجة؟ سؤال بسيط.. بس أغلبنا بيحسبه غلط، وغلط بسيط زي ده ممكن يبوظ الـ CV كله، ويقلل فرصك في الشغل. زمان أول ما بدأت أتعلم برمجة، كنت فاكر إني لما أذاكر كام شهر في البرمجة هيكون عندي خبرة وهقدر أقول عندي 6 شهور خبرة مثلًا 😅 ولكن الكلام ده غير صحيح أبدًا... ——— 📌 إزاي نحسب سنوات الخبرة؟ 1- هل كل اللي تعلمته يحتسب خبرة؟ لا، الخبرة الفعلية = الوقت اللي كنت بتشتغل فيه بشكل منتظم على مشاريع حقيقية وقابلت فيها تحديات وقدرت تحلها. يعني مثلًا: - اشتغلت في شركة؟ تمام. ده خبرة. - عملت شغل فريلانسنج لمدة 6 شهور وكنت بتسلم شغل لعميل؟ ده كمان خبرة. - اشتغلت على مشروع شخصي كبير، وكنت بتحل فيه مشاكل زي اللي بتحصل في أغلب المشاريع في الشركات؟ ده ممكن يتحسب، بس بشروط. لكن: - ذاكرت كورسات بس؟ - شوفت فيديوهات يوتيوب وطبقت معاها شوية أكواد؟ - عملت مشاريع بسيطة ملهاش علاقة بأرض الواقع؟ ده يُعتبر "تعلم"، مش خبرة حقيقية. ——— 💡 إيه شروط إن المشروع الشخصي يتحسب كخبرة؟ مش أي side project تحطه كـ proof إن عندك 3 سنين خبرة في React. فيه شوية شروط لو تحققت، تقدر تحسبه: - كان مشروع ليه هدف واضح (مش مجرد تجارب). - اشتغلت عليه لفترة طويلة وبشكل منتظم. - استخدمت فيه تقنيات بتستخدمها الشركات فعلًا (مش مجرد HTML و CSS). - قابلت فيه مشاكل performance و optimization و architecture و state management… إلخ. - المشروع deployed والناس تقدر تشوفه وتستخدمه. ——— لو كتبت في CV إن عندك 5 سنين خبرة، بس لما تيجي وقت الـ interview أو وقت الشغل ويتضح إن مستواك junior، ده بيضرك أنت قبل ما يضر الشركة ومش بعيد جدًا تبقى blocked بالنسبة للشركة دي ومتعرفش تشتغل فيها تاني حتى لو عندك 10 سنوات خبرة. لو حصل فجوة في شغلك لأي سبب حاول تذكرها في الـ CV بطريقة كويسة وخليك صريح...واشرح إزاي الفترة دي ساعدتك تتعلم بعض المهارات وتحسن من نفسك وهكذا... ——— وفقكم الله لكل خير 🌿

كل ما تحتاج معرفته عن الـ SSL || تأمين المواقع على الإنترنت https://youtu.be/9EOdDUmAErQ

Useful CSS Properties You Should Know 💯

يعني إيه Sitemap؟ وإزاي بتأثر على SEO؟ 🚀 . . فيه حاجات في الويب لو فهمتها بدري، هتوفر على نفسك مشاكل كتير قدام… واحدة من الحاجات دي هي الـ Sitemap. وهي دي إجابة سؤال: "ليه جوجل مش بيأرشف كل صفحات الموقع؟" أو "ليه الصفحات الجديدة مش بتظهر في السيرش؟" وده لأنك مش عامل Sitemap صح، أو مش عاملها أصلًا. تعال ندردش شوية ونعرف يعني إيه Sitemap، وإزاي ممكن تساعد موقعك... ——— 📌 يعني إيه Sitemap؟ تقدر تعتبرها خريطة الموقع بتاعك. زي خريطة مول كبير، فيها كل المحلات والمداخل والمخارج… بس هنا الخريطة معمولة عشان Google و Bing وكل محركات البحث. يعني sitemap.xml دي عبارة عن فايل بيقول لمحركات البحث: "الموقع بتاعي فيه الصفحات دي كلها، ودي أهمها، ودي اللي تم تحديثها قريب، ودي اللي محتاج تدخلها بسرعة." فالـ Sitemap بتسهّل جدًا على الـ Crawlers إنها تـفهم موقعك وتمشي فيه من غير توهان. ——— 💡ليه الـ Sitemap مهمة؟ خليني أقولك على شوية سيناريوهات واقعية: - لو موقعك لسه جديد ومفيهوش لينكات كتير، فغالبًا الـ Google مش هيعرف يوصل لكل الصفحات بسهولة. هنا sitemap بتساعده يوصل أسرع. - لو عندك صفحات كتير مش مربوطة ببعض (يعني مفيش internal links كفاية)، فـ محركات البحث ممكن تفوّت صفحات مهمة جدًا. - لو بتحدّث محتوى باستمرار، الـ sitemap بتقول لـ Google إن فيه تحديثات حصلت، فيعيد عملية الـ crawl على الصفحات دي بسرعة. ——— 🛠 أنواع الـ Sitemap؟ 1- الـ XML Sitemap: وده اللي بنبعته لمحركات البحث. - بيكون فايل اسمه غالبًا sitemap.xml. - بيحتوي على لينكات الصفحات، وتواريخ آخر تحديث، وأحيانًا priority. 2- الـ HTML Sitemap: وده بيكون معمول للمستخدم العادي. - صفحة فيها كل اللينكات المهمة في الموقع. - بتساعد الناس يتنقلوا بسهولة. لكن اللي يهمنا في الـ SEO هو الـ XML Sitemap. ——— 🤔 إزاي تعمل Sitemap؟ فيه أدوات بتعمل ده تلقائي: - لو بتستخدم WordPress: إضافة زي Yoast SEO أو Rank Math بتعمل sitemap تلقائي. - لو بتشتغل بـ Next.js أو أي framework تاني: تقدر تستخدم حاجة زي next-sitemap، أو تعمل generate يدوي. - لو عندك static site: استخدم أدوات زي sitemap-generator أو screaming frog. ——— ✅ بعد ما تجهز sitemap.xml: ارفعها على root بتاع الموقع، زي: https://example.com/sitemap.xml ✅ روح على Google Search Console: - اختار الموقع - اختار Sitemaps - ضيف اللينك بتاع الـ sitemap ده بيقول لجوجل: "إن الموقع جاهز وادخل بص على الصفحات دي." ——— وفقكم الله لكل خير 🌿

تعلم n8n من الصفر - طريقك للبداية في عالم الأوتوميشن! https://youtu.be/rtaEw-wSg20

The Hidden SEO Superpower: Mastering Sitemaps & Site Structure for Explosive Organic Growth 🧭

What if I told you that your website could be brilliant, beautiful — and invisible to Google? That’s the harsh reality for many site owners who ignore the quiet powerhouse of SEO: the sitemap. ——— 🔗 https://dev.to/alisamir/the-hidden-seo-superpower-mastering-sitemaps-site-structure-for-explosive-organic-growth-18pn

يعني إيه Canary Testing؟ 🤔 . . تخيل معايا إنك بتشتغل في شركة Tech كبيرة، وعندك Feature جديدة اشتغلت عليها أكتر من أسبوع، اختبرتها على الـ dev environment، وعدّت الـ QA، وكل حاجة تمام… بس قبل ما تطلعها لكل الناس على الـ production، في سؤال بيخطر في بالك: "يا ترى الفيتشر دي هتشتغل فعلًا كويس لما تنزل؟ ولا ممكن تعمل مشاكل للمستخدمين؟" وهنا ييجي دور الـ Canary Testing... ——-— الكلمة دي أصلها لما كانوا عمّال المناجم بياخدوا طيور الكناري معاهم تحت الأرض. الطيور دي كانت بتحذرهم لو فيه غاز سام قبل ما هم نفسهم يتأثروا. لو الكناري ماتت، يبقى فيه خطر، ولازم يطلعوا فورًا نفس الفكرة بالضبط في البرمجة قبل ما نـ rollout feature أو update لكل الناس، بنطلّعها لعدد صغير جدًا من المستخدمين الحقيقيين — الكناري بتاعنا — ونراقب سلوك السيستم كويس. لو كل حاجة ماشية تمام، نكمّل التحديث لباقي الناس. لو حصلت مشاكل؟ نوقف الدنيا بسرعة ونرجّعها زي ما كانت. ——— 📌 إمتى نستخدم الـ Canary Testing؟ - لو الـ Feature حساسة شويتين وممكن تعمل impact كبير لو فيها bug. - لو بتشتغل على Microservices وعايز تتأكد إن الـ service الجديدة مش هتبوّظ الـsystem كله. - لو شغال في بيئة فيها ملايين الـusers ومينفعش تخاطر. ——— 💡 إيه الفرق بين Canary Testing و A/B Testing؟ ناس كتير بتتلخبط بينهم، بس الفرق واضح: الـ Canary Testing: إحنا بنجرب نفس الـ feature على نسبة صغيرة من الناس ونشوف هل فيها مشاكل ولا لا. الـ A/B Testing: إحنا بنجرب نسختين مختلفين (Version A و Version B) ونشوف أنهي فيهم هيكون أحسن. يعني الـCanary هدفه الأساسي الأمان، والـA/B هدفه الأساسي التحسين والتطوير. ——— ⚙️ إزاي بنطبّق Canary Testing؟ فيه كذا طريقة، على حسب الـ Infra اللي شغال بها: 1- الـ Feature Flags: بتكون مشغل الـ feature الجديدة بس لناس معينة أو نسبة صغيرة. 2- الـ Traffic Splitting: ممكن تستخدم أدوات زي Kubernetes أو Load Balancers علشان توزّع الـ traffic بشكل كويس. 3- الـ Monitoring Tools: أهم حاجة تتابع الـ logs والـ metrics والـ errors أول بأول، سواء بـ Datadog أو New Relic أو أي أداة بترتاح فيها. 4- الـ Rollback Plan: لو حصلت مشكلة؟ تكون محضّر خطة rollback سريعة. ——— وفقكم الله لكل خير 🌿