DevGuide

بفضل الله، تم نشر أول مقال في In Plain English 🔥 المقال بيتكلم عن أهم 10 أخطاء في الفرونت إند ممكن تقع فيها لو لسه مبتدئ، وكمان فيه حلول عملية لكل خطأ علشان تتجنبه. 💡 ———

The 10 Front-End Mistakes I Wish I Knew as a Beginner With Fixes 💡

Front-end development is an exciting yet challenging field. When I started, I stumbled through countless pitfalls that slowed my progress and left me frustrated. https://differ.blog/p/the-10-front-end-mistakes-i-wish-i-knew-as-a-beginner-with-fixes-dc17e6 ——— متنساش تشاركه مع صاحبك الفرونت إند 🚀

Software Engineer Roadmap 2025: The Complete Guide 🚀

https://miro.com/app/board/uXjVLk4BHas=

لو لسه بادئ في البرمجة، أكيد سمعت عن Git، وأكيد كمان حسيت إنه معقد ومليان أوامر! 🤯 لكن الحقيقة إنه من أقوى الأدوات اللي هتساعدك تحفظ الكود بتاعك، تشتغل مع فريقك بسهولة، وترجع لأي نسخة من مشروعك في أي وقت! 💡 في المقال ده، هنتكلم عن أهم مفاهيم Git اللي لازم أي مبرمج جديد يفهمها، وهتلاقيها قدامك في كل مشروع تشتغل عليه. هتعرف يعني إيه commit، branch، merge، rebase، وغيرهم، وإزاي تستخدمهم بطريقة احترافية! 🚀 ———

Git Concepts Every New Developer Must Know: Your Roadmap to Version Control Mastery 💯

This article simplifies essential Git concepts for new developers. Whether you're working on your first project or contributing to a team, mastering these fundamentals will boost your confidence and make you a Git pro quickly. https://medium.com/@dev.alisamir/git-concepts-every-new-developer-must-know-your-roadmap-to-version-control-mastery-6740ac0f763a

الـ Feature Toggles (Feature Flags) 💡 تخيل أنك شغال على مشروع ضخم، وعايز تضيف خاصية جديدة أو تجرب فكرة معينة، بس من غير ما تخاطر إن حاجة تبوظ في الكود أو بدون ما تأثر على المستخدمين... أفضل حل هنا إنك تستخدم الـ Feature Toggles أو زي ما بنسميها أحيانًا الـ Feature Flags... ———

📌 إيه هي الـ Feature Toggles؟

ببساطة عبارة عن (أداة أو تقنية) بتخليك تتحكم في تفعيل أو تعطيل أجزاء معينة من الكود بتاعك من غير ما تضطر تعيد نشر (Deploy) التطبيق بالكامل. بمعنى تاني، بتقدر تخلّي خاصية معينة "On" أو "Off" بناءً على شروط معينة أو حتى بشكل ديناميكي. ———

📌 أنواع الـ Feature Toggles:

📍 الـ Release Toggles دي بنستخدمها لما نكون عايزين نطلع ميزة لجزء معين من المستخدمين ونسيب الباقي زي ما هو. مثال: تجربة خاصية جديدة على مستخدمين معينين بس. 📍 الـ Experiment Toggles النوع ده بيُستخدم في الـ A/B Testing، وده لما تحب تقارن بين نسختين من نفس الميزة وتشوف أي نسخة بتأدي أداء أفضل. 📍 الـ Ops Toggles دي لها علاقة بالـ DevOps. مثلا لو عندك خاصية بتستهلك موارد كتير من السيرفر، تقدر توقفها مؤقتًا من غير ما تدخل على الكود. 📍 الـ Permission Toggles النوع ده بيتحكم في إتاحة ميزات معينة بناءً على المستخدم نفسه، زي لما تطبق خاصية Premium متاحة بس للمستخدمين اللي دفعوا. ———

📌 ليه نستخدم الـ Feature Toggles؟

✅ تسريع الشغل بدل ما تأجل نشر التطبيق بالكامل لغاية ما كل الميزات تجهز، ممكن تضيف الـ Feature Toggles عندك وتفعّل الميزات تدريجيًا. ✅ تقليل المخاطر لو حصلت مشكلة في الميزة الجديدة، تقدر تقفلها فورًا من غير ما ترجع تعمل Rollback للـ Deploy ✅ تسهيل التعاون بين الفرق الفرق المختلفة في المشروع (Frontend, Backend, DevOps) يقدروا يشتغلوا مع بعض على نفس الكود بسهولة. ✅ تجربة المستخدم (User Testing) بسهولة تقدر تجرب ميزات جديدة مع مجموعة صغيرة من المستخدمين وتشوف رأيهم قبل ما تنشرها بشكل عام. ———

📌 إزاي نطبق الـ Feature Toggles؟

حدد إيه الميزة اللي محتاجة Toggle وهدفك من وراها. فيه مكتبات كتير بتساعدك زي: - LaunchDarkly - Unleash - Optimizely ولو بتشتغل بـ React أو Node.js، ممكن تلاقي مكتبات خفيفة وسهلة زي Feature Toggle أو تعمل Toggle بسيط بنفسك. دائمًا خلي الـ Toggles مربوطة بـ Configuration File أو API تقدر تعدلها بسهولة. تأكد من اختبار الميزة بشكل كويس في مرحلة الـ Dev أو الـ Staging ——— وفقكم الله لكل خير 🌿

Looking For a Job in Tech? Start With These Job Boards 🚀

📍 Indeed

https://www.indeed.com

📍 LinkedIn

https://www.linkedin.com/jobs

📍 Built In

https://builtin.com

📍 Dice

https://www.dice.com

📍 Wellfound

https://wellfound.com

📍 CrunchBoard

https://www.crunchboard.com

📍 Remote co

https://remote.co

الـ CORS - من المصطلحات المهمة في مجال الويب 💯 خلال رحلتك في مجال الويب أكيد مر عليك مصطلح الـ CORS، أو واجهتك مشكلة بسبب موضوع الـ CORS. خلينا ندردش شوية... ببساطة الـ CORS اختصار لـ Cross-Origin Resource Sharing ———

📌 في الأول كده خلينا نعرف يعني إيه Origin؟

الـ "Origin" هو الدومين (domain) أو النطاق اللي الموقع أو السيرفر بتاعك شغال عليه. بيبقى عبارة عن الـ "Protocol" (زي HTTP أو HTTPS) + اسم الدومين (زي example.com) + البورت (لو مختلف عن الـ 80 لـ HTTP أو 443 لـ HTTPS).

⚡️ طيب المشكلة فين؟

لو أنت شغال على موقع معين وعاوز الموقع بتاعك يطلب بيانات أو resources (زي JSON أو ملفات) من سيرفر تاني، السيرفر التاني ده لازم يبقى من نفس الـ origin بتاعك، يعني نفس الدومين، نفس البروتوكول، ونفس البورت. ودي حاجة اسمها Same-Origin Policy، السياسة دي معمولة أساسًا علشان تحمي المستخدمين من أي طلبات ضارة ممكن تجي من مواقع تانية مش موثوقة. بس في بعض الحالات، أنت كـ Developer بتبقى محتاج تعمل طلبات للسيرفرات اللي مش من نفس الـ origin بتاعك، زي لما يكون عندك Frontend شغال على دومين معين و API أو Backend شغالين على دومين أو بورت مختلف. ———

هنا بقى ييجي دور الـ CORS 👇

الـ Cross-Origin Resource Sharing (CORS) هو الحل اللي بيسمح للمواقع إنهم يطلبوا بيانات أو ملفات من سيرفرات تانية بمختلف الـ origins بشكل آمن ومأمن، بمعنى إنك تقدر تتخطى الـ Same-Origin Policy وتعمل طلبات لسيرفرات تانية طالما السيرفر ده بيقبل إنه يتعامل مع الموقع بتاعك. ———

📌 طيب إزاي الـ CORS بيشتغل؟

لما موقعك بيطلب بيانات من سيرفر تاني مختلف عن الـ origin بتاعه، السيرفر اللي عليه الـ resource اللي أنت بتطلبها هو اللي بيقرر إذا كان الطلب ده مسموح أو لا. السيرفر بيرد على الطلب من خلال الـ (headers) اللي بيرجعها مع الـ response. واحد من أهم الـ headers دي هو:

Access-Control-Allow-Origin

اللي بيحدد الـ origins اللي مسموح ليها تطلب بيانات من السيرفر ده. لو الـ origin بتاع موقعك موجود في القيمة بتاعت الـ header ده، السيرفر هيسمح بتنفيذ الطلب وهيرجعلك الـ response. ولو لل، الطلب هيتمنع وهيجيلك error من نوع CORS في المتصفح. ———

📍 كمان فيه Headers تانية زي:

- الـ Access-Control-Allow-Methods: اللي بتحدد أنواع الطلبات اللي مسموح ليك تعملها (GET, POST, PUT, DELETE...). - الـ Access-Control-Allow-Headers: اللي بتحدد الـ headers اللي مسموح ليك تبعتها في الطلبات. - الـ Access-Control-Allow-Credentials: لو الطلب محتاج يبعت Cookies أو بيانات معينة، لازم الـ header ده يبقى موجود ومظبوط على true. ———

طب إيه هي المشاكل اللي ممكن تواجهنا مع CORS؟ 🤔

أحيانًا الـ CORS بيبقى مزعج، وبتظهر لك أخطاء في المتصفح من نوع "CORS error" لما السيرفر مش بيدعم الطلبات من الـ origin بتاعك. الحل هنا بيبقى إنك تتأكد إن السيرفر اللي أنت بتطلب منه مظبط إعدادات الـ CORS صح. بالتوفيق يا بطل ⚡️

خصم 100% لمدة 3 أيام على كل الكتب الالكترونية المنشورة من خلال To Data & Beyond: ➡ Efficient Python for Data Scientists youssefhosni.gumroad.com/l/cbousj ➡ Hands-On Prompt Engineering: Building LLM Applications with Prompt Engineering youssefhosni.gumroad.com/l/xsmguv ➡ LLM Roadmap from Beginner to Advanced Level youssefhosni.gumroad.com/l/qigmtg ➡ Top Large Language Models Interview Questions and Answers youssefhosni.gumroad.com/l/rrzgu ➡ Data Science Portfolio for Success E-Book youssefhosni.gumroad.com/l/ltjno تقدر تستخدم الكوبون عشان تاخد الخصم: 5AOPHJC

How to start learning JAVA IN 2025

1. Core Java Basics

- Learn about basic syntax, variables, data types, and operators. - Control flow: if-else, loops (for, while, do-while). - Arrays and Strings. - Methods and Functions.

2. Object-Oriented Programming (OOP)

- Classes and Objects. - Encapsulation, Inheritance, Polymorphism, and Abstraction. - Interfaces and Abstract Classes.

3. Core Java Utilities

- Collections Framework (Lists, Sets, Maps, Queues).- - Generics. - Exception Handling. - Input/Output Streams (I/O).

4. Advanced Java Concepts

- Multithreading and Concurrency. - Java 8+ Features: Streams, Lambdas, Optional, Date and Time API. - Functional Programming.

5. Database Connectivity

- JDBC (Java Database Connectivity). - Connect Java applications with relational databases like MySQL or PostgreSQL.

6. Build Tools and Version Control

- Maven or Gradle for dependency management and building projects. - Git for version control.

7. Frameworks and Tools

- Spring Framework: Learn Spring Boot for building enterprise applications. - Hibernate: For ORM (Object-Relational Mapping). - REST APIs: Learn how to create and consume RESTful web services.

8. Front-end Integration (Optional)

- Integrate Java with front-end technologies like HTML, CSS, JavaScript. - Learn about JSP/Servlets or modern frameworks like Thymeleaf.

9. Testing

- Unit Testing with JUnit. - Integration Testing.

10. Build Projects

- Create simple projects like a library management system, e-commerce website, or chat application. - Gradually move to more complex projects using frameworks like Spring Boot.

11. Deployment

- Learn how to deploy Java applications on servers like Apache Tomcat. - Explore cloud platforms like AWS or Azure for deployment.

أنـواع قواعـد البيانات 💯 قواعد البيانات (Databases) تعتبر حجر الأساس لأي تطبيق أو نظام برمجي. ببساطة هي المكان اللي بنخزن فيه البيانات (Data) ونقدر نسترجعها وقت ما نحتاجها. قواعد البيانات لها أنواع كتير وكل نوع بيختلف في طريقة تخزين البيانات والتعامل معاها. ———

📌 الـ Relational Databases (قواعد البيانات العلائقية)

ده يعتبر أشهر نوع وأكثرهم استخدامًا. قواعد البيانات العلائقية بتعتمد على الجداول (Tables) في تخزين البيانات، كل جدول بيكون عبارة عن مجموعة من الأعمدة (Columns) والصفوف (Rows). البيانات في الجداول دي بتكون مرتبطة ببعض عن طريق العلاقات (Relationships)، وده بيخلي التعامل مع البيانات وتنظيمها أكتر كفاءة. ⚡️ أمثلة: - الـ MySQL: قاعدة بيانات مفتوحة المصدر وبتستخدم في معظم التطبيات. - الـ PostgreSQL: قاعدة بيانات مفتوحة المصدر بس بتتميز بمرونة كبيرة في التعامل مع البيانات والعلاقات المعقدة. - الـ SQL Server: قاعدة بيانات من مايكروسوفت، وغالبًا بتستخدم في التطبيقات اللي بتعتمد على منتجات مايكروسوفت. ———

📌 الـ NoSQL Databases (قواعد البيانات غير العلائقية)

قواعد البيانات NoSQL مصممة للتعامل مع البيانات غير المنظمة أو البيانات اللي بتكون بأشكال مختلفة. النوع ده مش بيعتمد على الجداول زي الـ Relational Databases وبيكون مرن أكتر في التعامل مع البيانات اللي حجمها بيكبر بسرعة. ⚡️ أمثلة: - الـ MongoDB: قاعدة بيانات NoSQL مشهورة جدًا وبتعتمد على الـ Documents، وبتستخدم JSON-like structure علشان تخزن البيانات. - الـ Cassandra: قاعدة بيانات موزعة (Distributed) بتستخدم في التطبيقات اللي بتحتاج تتعامل مع كميات ضخمة من البيانات بسرعة وبتحافظ على الأداء العالي. - الـ Firebase Realtime Database: قاعدة بيانات تابعة لجوجل، بتستخدم كتير في تطبيقات الموبايل اللي محتاجة تحديث البيانات بشكل لحظي (Real-time). ———

📌 الـ Graph Databases (قواعد البيانات البيانية)

النوع ده من قواعد البيانات بيعتمد على الرسوم البيانية (Graphs) في تخزين البيانات. الفكرة هنا إن البيانات بتتخزن على شكل نقاط (Nodes) والعلاقات بين النقاط دي بتكون على شكل خطوط (Edges). النوع ده مناسب أكتر للتطبيقات اللي فيها بيانات مترابطة بشكل معقد زي شبكات التواصل الاجتماعي. ⚡️ أمثلة: - الـ Neo4j: واحدة من أشهر قواعد البيانات البيانية، وبتستخدم في تحليل الشبكات الاجتماعية أو أي نوع من البيانات اللي فيها علاقات معقدة. - الـ Amazon Neptune: قاعدة بيانات من أمازون بتتعامل مع الرسوم البيانية وبتساعد في التطبيقات اللي بتحتاج بيانات مترابطة بشكل كبير. ———

📌 الـ Key-Value Databases

في النوع ده من قواعد البيانات، البيانات بتتخزن على شكل أزواج (Key-Value). الـ Key هو العنصر اللي بنستخدمه للبحث عن القيمة (Value) المرتبطة بيه. النوع ده من قواعد البيانات بيكون بسيط وسريع جدًا في الاستعلام عن البيانات. ⚡️ أمثلة: - الـ Redis: قاعدة بيانات مشهورة جدًا وبتستخدم في الكاش (Caching) وفي التطبيقات اللي محتاجة سرعة عالية في التعامل مع البيانات. - الـ DynamoDB: قاعدة بيانات من أمازون بتدعم الـ Key-Value وبتستخدم في التطبيقات السحابية اللي بتحتاج أداء عالي. ———

📌 الـ Document Databases (قواعد البيانات الوثائقية)

النوع ده بيخزن البيانات على شكل وثائق (Documents)، والوثيقة بتكون غالبًا في شكل JSON أو BSON. قواعد البيانات الوثائقية بتدي مرونة أكتر في التعامل مع البيانات غير المنظمة. ⚡️ أمثلة: - الـ Couchbase: قاعدة بيانات وثائقية بتمزج بين الأداء العالي والمرونة في التخزين. - الـ MongoDB: زي ما ذكرنا قبل كده، بتدعم الـ Document-based structure وبتستخدم كتير في التطبيقات اللي بتحتاج تعامل سريع مع البيانات. ———

📌 الـ Column-Family Databases (قواعد البيانات العمودية)

في النوع ده، البيانات بتتخزن على شكل أعمدة بدل الصفوف، وده بيدي كفاءة أعلى في قراءة وكتابة البيانات اللي حجمها كبير. ⚡️ أمثلة: - الـ Apache HBase: قاعدة بيانات مفتوحة المصدر بتشتغل فوق Hadoop وبتستخدم في التعامل مع البيانات الكبيرة. - الـ Google Bigtable: قاعدة بيانات سحابية من جوجل بتتعامل مع كميات هائلة من البيانات بشكل عمودي. ——— اختيار النوع المناسب من قواعد البيانات بيعتمد على احتياجات التطبيق بتاعك. لازم تختار على حسب حجم البيانات، طريقة التعامل معاها، والسرعة اللي محتاجها.

All CSS Functions 💡

20 NEW CSS Features You Need To Know In 2025

https://youtu.be/VA975GOUFmM

Our Digital Hubs 🌐

DevGuide | Telegram

https://t.me/the_developer_guide

DevGuide | YouTube

https://www.youtube.com/@The_Dev_Guide

DevGuide | LinkedIn

https://www.linkedin.com/company/dev-guide

DevGuide | Discord

https://discord.gg/nTgfYng5q2

DevGuide | Facebook

https://www.facebook.com/TheDeveloperGuide

DevJobs | Telegram

https://t.me/devsjobs

DevJobs | WhatsApp

https://whatsapp.com/channel/0029Va5wYTe1noz1SKCNcv45

DevJobs | LinkedIn

https://www.linkedin.com/showcase/developersjobs

الفرق بين Dependency Injection و Inversion of Control 💡 لما تتعمق شوية في مجال السوفتوير هتسمع عن مصطلحات زي Dependency Injection و Inversion of Control، وفيه ناس بتتلخبط بينهم وبتفكر إنهم حاجة واحدة. خلينا نوضح الفرق بطريقة بسيطة تفهمك الفكرة كويس... ———

📍 إيه هو Inversion of Control (IoC)؟

خلينا نبدأ بـ Inversion of Control أو زي ما بنختصرها IoC. المفهوم ده ببساطة بيقول إن بدل ما الكود بتاعك هو اللي يتحكم في كل حاجة بنفسه (يعني هو اللي بيعمل الكائنات (Objects) اللي هيشتغل بيها ويعتمد عليها)، بيكون فيه جهة تانية هي اللي بتعمل ده وتدير الموضوع. يعني الكود بتاعك مش بيهتم بأنه "ينشئ" الـ dependencies (الكائنات اللي بيعتمد عليها)، بل بيستقبلها جاهزة. تقدر تتخيل الموضوع كأنك مش بتروح تجيب مكونات أكلك بنفسك من السوبر ماركت، أنت بتخلي حد يجيبهم لك ويجهزهم، وأنت بس تطبخ الحاجات اللي وصلتك. ———

📍 إيه حكاية Dependency Injection؟

هنا بقى ييجي دور الـ Dependency Injection. ده ببساطة أسلوب أو طريقة لتطبيق مفهوم الـ Inversion of Control. بدل ما الكود بتاعك هو اللي يقول "أنا محتاج الكائن ده أو المكون ده عشان أشتغل"، حاجة تانية (زي الـ framework أو الـ container) بتكون مسؤولة عن إنها "تضخ" الكائنات دي لك في الوقت المناسب. ———

📌 مثال يوضح الفرق:

تخيل أنك عندك عربية، لو أنت بنفسك اللي بتروح لمحطة البنزين وتملاها، ده يعتبر إن العربية معتمدة على البنزين اللي أنت بتجيبه. لكن لو في نظام ذكي في العربية هو اللي بيتحكم ويوصل لها البنزين من غير ما أنت تتدخل، يبقى ده Inversion of Control، لأنك سبت السيطرة للنظام إنه يدير الموضوع. أما Dependency Injection، فهو الآلية اللي بيتم بيها توصيل البنزين للعربية. يعني هي دي الطريقة اللي البنزين بيوصل بيها لعربيتك عشان تمشي. ———

📌 طب ليه بنهتم بالحاجات دي في البرمجة؟

الفكرة ببساطة إن الطريقة دي بتخلينا نكتب كود مرن وسهل التطوير. لو كل كائن في الكود بتاعك بيعتمد على كائنات تانية وبيعملها بنفسه، ده هيخلي الكود معقد وصعب تختبره أو تعدل عليه. لكن لما تخلي Dependency Injection مسؤول عن توصيل الـ dependencies، هتقدر تعدل على الكود أو تستبدل أي جزء بسهولة من غير ما تبقى محتاج تغييرات كبيرة. ———

الخـلاصـة ✅

الـ Inversion of Control: هو المفهوم اللي بيقول إنك تسيب التحكم في الـ dependencies لجهة خارجية. الـ Dependency Injection: هو طريقة لتطبيق المفهوم ده عن طريق توصيل الـ dependencies للكود بتاعك بشكل أوتوماتيكي. بالتالي، IoC هو الفكرة الكبيرة اللي بتحكم الموضوع، وDependency Injection هو الأداة اللي بتطبق الفكرة دي. بالتوفيق يا بطل ⚡️

الفرق بين AOT Compiler و JIT Compiler في Angular 💡 . . طبعًا أنت عارف إن المتصفح مبيفهمش غير لغة واحدة في الآخر، وهي الـ JavaScript. يعني مهما كتبت كود بلغة زي TypeScript أو حتى HTML وCSS، لازم في النهاية الكلام ده كله يتحول لـ JavaScript عشان المتصفح ينفذه ويطلع الموقع على الشاشة. وده بيحصل عن طريق حاجة اسمها الـ Compiler (أو الـ Transpiler في بعض الحالات زي TypeScript). ولكن في Angular، الـ compilation ده ممكن يحصل بطريقتين مختلفتين، وكل طريقة لها مميزات وعيوب. ——— https://www.linkedin.com/posts/dev-alisamir_angular-devabrguide-typescript-activity-7305272573439713280-pq-Q

الـ MVC

نمط الـ MVC، أو Model-View-Controller، يعتبر من أشهر الأنماط المستخدمة في هندسة البرمجيات، وبيساعد على تنظيم الكود بشكل يخلي عملية تطوير وصيانة البرامج أبسط وأسهل. ———

طيب يعني إيه MVC؟ 🤔

الـ MVC بيتكون من 3 مكونات أساسية: ✅ الـ Model: الجزء ده هو اللي بيتعامل مع البيانات. الـ Model بيقوم بتخزين البيانات، معالجة البيانات، والتواصل مع قواعد البيانات. ممكن تعتبره زي المسئول عن "المنطق" أو "الشغل" اللي بيحصل في التطبيق. مثلًا لو عندك تطبيق بيعرض قائمة بالمنتجات، فالـ Model هو اللي هيجيب البيانات دي من قاعدة البيانات ويجهزها. ✅ الـ View: وده المسئول عن كل اللي المستخدم بيشوفه قدامه على الشاشة. هو المسئول عن عرض البيانات اللي جهزها الـ Model. يعني مثلًا لو عندك صفحة بتعرض المنتجات، فالـ View هو اللي بيحدد إزاي المنتجات هتظهر (الألوان، الشكل، الترتيب... إلخ). ✅ الـ Controller: وده الوسيط اللي بيعمل التنسيق بين الـ Model والـ View. بمعنى تاني، هو اللي بيستقبل طلبات المستخدمين، زي لما تضغط على زرار أو تدخل بيانات في فورم، وبعدين يوجه الطلب للـ Model علشان يعالج البيانات، وفي الآخر يرجع البيانات دي للـ View علشان يعرضها. ———

مثال بسيط 🛠

تخيل إنك فاتح موقع للتسوق وعايز تشوف قائمة المنتجات: ⚡️ أول حاجة بتضغط على زرار "عرض المنتجات" – هنا الـ Controller بيستقبل الطلب ده. ⚡️ بعد كده، الـ Controller بيروح للـ Model علشان يجيب البيانات من قاعدة البيانات (قائمة المنتجات). ⚡️ الـ Model بيدور في قاعدة البيانات ويجيب المنتجات. ⚡️ بعد ما الـ Model يجهز البيانات، بيرجّعها للـ Controller اللي بدوره يبعتها للـ View. ⚡️ وأخيرًا، الـ View بيعرض المنتجات على الشاشة بالشكل المناسب اللي المستخدم يقدر يشوفه ويتفاعل معاه. ———

ليه تستخدم الـ MVC؟ 🤷‍♂️

📌 تنظيم الكود: بيخلي الكود منظم أكتر، بحيث تقدر تفصل منطق العمل (الـ Model) عن العرض (الـ View) وعن التحكم (الـ Controller)، وبالتالي لو عايز تعدل في جزء معين، بتعدل عليه من غير ما تأثر على الأجزاء التانية. 📌 سهولة التطوير والصيانة: كل مكون في الـ MVC بيشتغل بشكل مستقل، فلو في مشكلة في العرض (الـ View) مش لازم تلمس الكود الخاص بالبيانات (الـ Model) أو التحكم (الـ Controller). 📌 إعادة استخدام الكود: بما إن الكود متقسم ومنظم، ممكن تعيد استخدام أجزاء معينة منه في مشاريع تانية. ——— نمط الـ MVC هيسهل عليك الدنيا خصوصًا لو شغال على مشاريع كبيرة ومعقدة لأنه بيفصل بشكل واضح بين الأدوار المختلفة لكل مكون في التطبيق. ده هيوفر عليك وقت ومجهود وهتقدر تعمل تعديل في التطبيق بتاعك بكل سهولة. بالتوفيق يا بطل 💪🏻

دورة مجانية بعنوان: Power BI 101 تهدف هذه الدورة إلى التعرف على أساسيات Power BI، بدءًا من استيراد البيانات، إلى تمثيل البيانات وإنشاء التقارير وdashboard. ستساعدك الدورة على اكتساب المهارات اللازمة لتمثيل البيانات وإنشاء تقارير فعّالة باستخدام Power BI. https://satr.codes/course/OC6sfVMdl9/view

Keys In SQL With Tables Well Explained 💯

الفرق بين الـ Monorepo والـ Multirepo 💯 . . تخيل أنك شغال على مشروع ضخم، عندك أكتر من فريق، وكل فريق بيشتغل على جزء مختلف. فجأة، تبدأ المشاكل تظهر: كود مكرر، صعوبة في التعديلات، تعارض بين الفرق، وأوقات ضايعة على الـ builds والـ pipelines. المشكلة هنا ممكن تكون في الطريقة اللي بتنظم بها الكود بتاعك. 💡 هنا تبدأ تسأل نفسك: تختار Monorepo ولا Multirepo؟ كل طريقة لها ميزاتها وعيوبها، واختيارك ممكن يحسن شغلك بنسبة كبيرة أو يعقد حياتك لو اختارت الغلط. تعال نوضح الفرق بينهم وامتى تختار الطريقة المناسبة... ———

📌 أولًا: يعني إيه Monorepo؟

الـ Monorepo ببساطة هي إنك تحط كل الكود الخاص بالمشروع بتاعك، بكل الـ components أو الـ modules اللي فيه، داخل Repository واحد. يعني حتى لو عندك أكتر من خدمة (microservices) أو أكتر من مكتبة أو أكتر من تطبيق مرتبطين ببعض، كله بيكون في مكان واحد. ———

📍 مميزات الـ Monorepo:

- سهولة إدارة الكود: كل حاجة في مكان واحد، فلو عايز تعمل تغييرات على أكتر من جزء، هتبقى شايف الصورة الكبيرة بسهولة. - إعادة استخدام الكود (Code Reusability): لو في مكتبة أو جزء معين من الكود محتاج تستخدمه في أكتر من موديول، تقدر تعمله بسهولة من غير duplication. - تنسيق أفضل بين الفرق: كل فريق شايف الكود بتاع باقي الفرق، فده بيسهل التعاون بينهم وبيقلل تعارض التعديلات (conflicts). - تكامل أفضل بين الأدوات: زي الـ CI/CD (Continuous Integration/Continuous Deployment) اللي بيشتغل بسهولة على مشروع واحد بدل ما يتقسم على أكتر من repository. ———

📍 عيوب الـ Monorepo:

- الحجم الكبير للـ repo: مع مرور الوقت وعدد المساهمين الكبير، حجم الـ repo بيكبر وده ممكن يبطّأ العمليات زي cloning أو حتى الـ builds. - التعقيد في إدارة الصلاحيات: صعب تقول إن فلان يقدر يشتغل على جزء معين بس من غير ما يشوف الباقي. - مشاكل مع الـ Tools: لو مش عندك أدوات قوية لإدارة الـ monorepo، ممكن تواجه مشاكل في التنظيم وعملية الـ build. ———

📌 ثانيًا: يعني إيه Multirepo؟

على العكس تمامًا، الـ Multirepo معناها إن كل جزء أو موديول من المشروع يكون في Repository خاص به. يعني كل موديول بيبقى مستقل بذاته وكأنه مشروع لوحده. ———

📍 مميزات الـ Multirepo:

- كل موديول ليه حياته الخاصة، وده بيخلي إدارة كل جزء مستقلة وأسهل لبعض الفرق. - تقدر تحدد مين يشتغل على إيه بناءً على الـ repo اللي عندهم أكسس عليه. - لو فيه موديول أو خدمة مش مرتبط بشكل مباشر، مش محتاج تبني كل المشروع، بس تبني الجزء اللي محتاجه. - كل جزء بيكون صغير ومستقل، فده بيخلي العمليات زي cloning أسرع وأسهل. ———

📍 عيوب الـ Multirepo:

- تكرار الكود: لو فيه أكتر من موديول بيحتاج نفس الكود، ممكن تضطر تكرره أو تحط مكتبة منفصلة ليه. - تعقيد في التنسيق بين الفرق: التعاون بين الفرق بيبقى أصعب، وخصوصًا لما يكون فيه dependencies كتير بين الـ modules. - تكامل معقد للـ CI/CD: عشان كل جزء في Repository مختلف، هتحتاج إعدادات أكتر للـ pipelines عشان كل حاجة تشتغل مع بعض. - صعوبة في إدارة التغييرات الكبيرة: لو عندك تغيير ضخم بيأثر على أكتر من موديول، هتحتاج تدخل على كذا repo وتعدل في كل واحد لوحده. ———

📌 امتى تختار مين؟

✅ اختر Monorepo لو: 1- مشروعك عبارة عن مجموعة modules مرتبطة ببعضها. 2- عندك فريق صغير أو متوسط. 3- بتحتاج تعمل تغييرات بشكل متكرر على أكتر من موديول في نفس الوقت. 4- الأدوات اللي بتستخدمها بتدعم إدارة monorepos بشكل كويس. ✅ اختر Multirepo لو: 1- مشروعك كبير جدًا ومعقد، وكل جزء فيه مستقل تمامًا. 2- بتحتاج تتحكم في الصلاحيات على مستوى كل موديول. 3- عندك فرق مختلفة كل فريق شغال على موديول خاص به. 4- عايز تتجنب المشاكل اللي بتسببها أحجام الـ repos الكبيرة. ——— القرار في الآخر بيرجع لطبيعة مشروعك واحتياجات فريقك. مفيش طريقة "صح" وطريقة "غلط"، لكن فيه طريقة مناسبة أكتر حسب ظروفك. أهم حاجة إنك تكون فاهم كل طريقة بتقدم إيه وعيوبها إيه. 💡 وفقكم الله لكل خير 🌿

💡 الحل هو التطبيق العملي

في الـ Front-End، ممكن تبدأ بمشاريع بسيطة زي صفحة ويب شخصية أو آلة حاسبة، وبعدين تطور نفسك بمشاريع زي تطبيق إدارة مهام أو موقع إخباري بواجهة احترافية. أما في الـ Back-End، ابدأ بمشاريع زي API بسيطة، ومع الوقت اشتغل على حاجات زي نظام إدارة مستخدمين أو تطبيق شات متكامل. المهم تفضل تطبق عملي عشان المهارات اللي بتتعلمها تبقى ثابتة، وكل مشروع هتعمله هيرفع من مستواك واحدة واحدة لحد ما تبقى محترف. دي مجموعة مشاريع في مجال الـ Front-End ومجال الـ Back-End هتنقلك من المستوى المبتدئ للمستوى الاحترافي

⚡️ مشاريع الـ Front-End

https://roadmap.sh/frontend/projects

⚡️ مشاريع الـ Back-End

https://roadmap.sh/backend/projects