اللي قادر يحضر هيك تدريبات يحضر لا تقلي انا اختصاصي برمجيات او انا ذكاء رح تحتاج هي المعلومات مليون بالمية

للمهندسين الخريجين و الطلاب في كليات الهندسة المعلوماتية و الاتصالات و هندسة الحاسبات و الكليات التطبيقية و تكنولوجيا المعلومات.
🛑 لطلاب معاهد الهندسية التقنية و معاهد الحاسوب.
🛑 لكل من يرغب بالدخول بمجال هندسة الشبكات و يريد ان يمتلك قاعدة صحيحة لتأسيسه.
يعلن مركز خطوات للشباب في #جبلة - #اللاذفية عن تدريب تصميم شبكات الحاسوب
200-301 CCNA
للتسجيل، يرجى تعبئة الاستمارة في التعليق:
#مجلس_الشباب_السوري

https://forms.gle/wrEpF1B1UkrrJTan8

المصدر: هنا

لما نحكي عن الـ components اللي بتتعامل مع الـ State او ما يسمى بـ (stateful components) بـ React، معناها هي الـ component بتخزن بيانات جواتها، وهاد الشي بيسمح للبيانات إنها تتغير مع مرور الوقت.

لحتى يكون الـ component stateful، في طريقتين:

- يا إما بتكون من نوع class component أو تستخدم الـ (hook) useState بالـ functional components.
الـ state هي اللي بتخلّي الـ component يتفاعل مع التغييرات، متل مدخلات المستخدم أو الأحداث اللي بتصير عالصفحة. وكل ما تغيّرت هي الـ state الـ component بيرجع بينعمله re-render لحتى يعرض البيانات الجديدة.

أما الـ components اللي ما بتحتوي الـ state او ما تسمى بـ (stateless components) فهي components بسيطة، وغالباً بتكون functional components اللي بس بتعتمد على props اللي بيجوا من خارج المكون. هالنوع من الـ components ممتاز لما بدك تعرض محتوى ثابت أو واجهة مستخدم ما بتحتاج تخزين بيانات أو تغييرها جوات المكون.

بالتالي، الفرق الأساسي هو إنو الـ stateful components بتتعامل مع البيانات اللي بتتغير، بينما الـ stateless components بتعرض بيانات ثابتة أو بتعتمد على props جاهزة وما بتتعامل مع أي تغييرات داخلية.

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

لا تنسوا تتابعوني على FaceBook

شكراً لفريق كتابة المحتوى على المساعدة في إعداد هذا المنشور.

عم تواجه مشاكل بوصول الإشعارات بتطبيقك؟ بهالفيديو رح أشرح لك كيف بتنقل إشعاراتك من الواجهة القديمة لـ Firebase لـ HTTP v1 بأسهل طريقة. الحل اللي رح يضمن وصول الإشعارات باستخدام OAuth 2.0. لا تنسى تتابع الفيديو على اليوتيوب لتعرف كل التفاصيل من خلال:
الرابط هنا

لا تنسوا الاشتراك بقناتي على YouTube حتى تشوفوا الشروحات على شكل فيديوهات

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

استكمالاً لشرح مفاهيم البرمجة الكائنية (OOP)، اليوم رح نحكي عن الـ Magic Methods. طيب، شو هي الـ magic methods؟
أكيد خلال تعاملك مع البرمجة الكائنية شفت في بعض الـ methods يلي بيبلش اسمها باثنين underscores (__). هدول هنن الـ magic methods، وهنن عبارة عن دوال محجوزة بالـ OOP بيتم استدعائها تلقائياً لما يصير ظرف معين أو حالة معينة بالكود لما تستخدم class أو Object.

من أشهر الـ magic methods اللي بتخطر عالبال هي `__construct`، يلي بنستدعيها لما نعمل Object جديد من Class. هالـ method بتنادى بشكل تلقائي وبتشتغل لحتى تهيئ الكائن الجديد.

وفي كمان `__destruct`، يلي بتنادى لما يتم تدمير Object أو خلصنا من استخدامه.

وفي عنا شوية methods تانية متل `__call` و __callStatic. هدول بيتعاملوا مع الحالات يلي فيها بنحاول نستدعي method مو معرفة بالكلاس. هدول بياخدوا باراميترين: الأول هو اسم الميثود $name`، والتاني هو المصفوفة اللي بتحتوي القيم اللي انبعتت لهال method `$parameters.

طيب، شو الفرق بين __call و `__callStatic`؟
`__call` بيتعامل مع الـ methods العادية، أما __callStatic فهو بيتعامل مع الـ methods الثابتة (static).

طيب إذا هدول الـ methods بيتعاملوا مع الـ methods اللي مو معرفة، شو رح نعمل لو بدنا نتعامل مع الخصائص (properties) اللي مو معرفة؟
هون بيجي دور __get و __set.
- __get بتنادى لما نحاول نوصل لخاصية ما موجودة أو ما بنقدر نوصلها.
- __set بتنادى لما نحاول نعدل قيمة خاصية ما موجودة أو ما بنقدر نوصلها.

وكمان في `__toString`، يلي هي method بتنادى تلقائيًا لما نحاول نطبع الأوبجكت على شكل string.

فيك تقول إنو الـ magic methods بيعطوا مرونة كبيرة بالتعامل مع الكائنات والـ classes.
طيب، شو رأيكم؟ سبق وتعاملتوا مع هالـ magic methods؟

مثال توضيحي موجود ضمن الـ Comments 👇🏻

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Yousef Saleh على المساعدة في إعداد هذا المحتوى.

*Company Name:* hashtag#BLUE_TECH
*Job Title:* Front-end Developer with React.js Experience
*Job Type:* Full Time (8 hours) - Remote work not available
*Job Location:* hashtag#Lattakia, hashtag#Syria

At hashtag#BLUE_TECH, we are seeking a skilled Front-end Developer with a strong proficiency in React.js to join our team. This role involves developing user interface components, ensuring application robustness, and fostering a culture of collaboration, innovation, and high-quality product delivery.

*Responsibilities:*
- Develop engaging user-facing features using React.js
- Create reusable components and front-end libraries for future projects
- Translate designs and wireframes into high-quality code
- Optimize components for peak performance across various devices and browsers

*Qualifications:*
- 2+ years of experience in front-end web development
- Proficient in JavaScript, DOM manipulation, and the JavaScript object model
- Thorough understanding of React.js and its core principles
- Experience with popular React.js workflows like Redux
- Familiarity with newer EcmaScript specifications
- Knowledge of Next.js is required
- Understanding of RESTful APIs and Web Sockets
- Proficiency in modern authorization mechanisms such as JSON Web Token
- Ability to translate business requirements into technical solutions
- Strong skills in benchmarking and optimization
- Experience with Git or similar versioning tools

If you are passionate about React.js development and meet these qualifications, we would love to hear from you. Please send your CV to:
*Email:* recruitment@blue-tech.ae
*Subject Line:* hashtag#ReactJs Developer

Join our team at hashtag#BLUE_TECH and contribute to a dynamic environment that values expertise, innovation, and teamwork.

hashtag#job hashtag#business hashtag#team hashtag#experience hashtag#recruitment hashtag#developer hashtag#javascript hashtag#cv hashtag#webdevelopment hashtag#reactjs hashtag#react hashtag#design

الكود القابل للصيانة (Maintainable Code)، باختصار، هو الكود اللي بتقدر ترجعله بعد فترة، سواء انت أو حدا غيرك، وتفهمه بسهولة، تعدّل عليه أو تطوره من غير ما تحس إنه معقّد أو مخربط. هاد الكود بيكون منظم بطريقة تخليك تقدر تصححه أو تضيف عليه شغلات جديدة من غير تعب.

ليش الكود القابل للصيانة مهم؟

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

كيف نقدر نخلي الكود قابل للصيانة؟

التنظيم (Organization): أهم شغلة. الكود لازم يكون منظم، وكل جزء منه يكون بمكانه الصح. يعني مثلاً، إذا عندك ملفات أو أجزاء معينة للكود بتخص الـ UI (واجهة المستخدم) أو الـ Data، حط كل شي بمكانه. كمان، ما تكتب كل شي بملف واحد ضخم، قسّم الشغل على أجزاء صغيرة مشان يصير سهل التعديل.

التسمية (Naming): سمي المتغيرات، الـ functions، أو أي جزء من الكود بأسماء واضحة ومفهومة. ما تسمي تسميات متل x أو temp إلا إذا كان ما في حل غيره. يعني إذا عندك دالة بتحسب الراتب الشهري، سميها مثلاً calculateMonthlySalary بدل ما تسميها calc1. التسميات الواضحة بتسهل فهم الكود.

التعليقات (Comments): مرات رح تكتب أكواد معقدة شوي، فهون التعليقات بتكون مفيدة. بس دير بالك، التعليقات مو معناها تشرح كل سطر. اكتب التعليقات بالأماكن اللي ممكن تكون مش مفهومة، أو بتحتاج تفسير ليش استخدمت هي الطريقة. التعليقات هي مشان توضح "ليش" الكود بيعمل هيك، مش "شو" الكود بيعمل.

تجنب التكرار (Avoid Duplication): قاعدة برمجية مهمة اسمها "DRY" (Don't Repeat Yourself). يعني، لا تكرر نفس الكود بأماكن مختلفة. إذا عندك نفس العملية تتكرر، حطها بدالة (function) واستخدمها بدل ما تعيد كتابة الكود.

الاختبارات (Testing): قبل ما تشارك أو تنشر الكود، اعمل اختبارات. جرّب الكود بمختلف الحالات لتتأكد إنه شغال تمام. الكود اللي مغطّى باختبارات منيحة بيكون أسهل للصيانة، لأنك رح تعرف بسهولة إذا صار في شي خطأ بعد التعديل.

التعامل مع الأخطاء (Error Handling): دائماً حط أكواد للتعامل مع الأخطاء. يعني إذا صار شي خطأ أثناء تشغيل الكود، المفروض تطلع رسالة واضحة تفهمك أو تفهم المستخدم شو صار، بدل ما تطلعلك رسالة Error ما تفهم شي منها.

إعادة الاستخدام (Reusability): حاول تخلي أكوادك مرنة وتقدر تعيد استخدامها بأماكن تانية. إذا كتبت جزء معين ممكن تحتاجه بمكان تاني، حاول تكتبه بشكل عام ومش مربوط بحالة معينة. هيك، لو جالك مشروع تاني أو بدك تغير شي بالمشروع الحالي، رح تقدر تستخدم هاد الكود بدون ما تعيد كتابته من الأول.

بالنهاية، الكود القابل للصيانة هو الكود اللي تقدر تفهمه وتعدل عليه بسهولة، سواء انت أو أي مبرمج تاني. التنظيم، التسمية الواضحة، التعليقات المناسبة، والاهتمام بالتفاصيل متل الـ Error Handling واختبار الكود، كل هالشغلات بتساعدك تبني كود نظيف وقابل للصيانة.

كنت عم تتبع هي الملاحظات سابقاً ولا اكتشفتها هلا؟

Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Yousef Saleh على المساعدة في إعداد هذا المحتوى.

رجع طبيعي هلا

تخيل إنك بدك تشتري هدية لصديقك بمناسبة عيد ميلاده، و فتت على متجر إلكتروني لتلاقي الهدية المناسبة. أول ما فتحت الموقع، حسيت بضياع، الصفحة الرئيسية مليانة معلومات بشكل فوضوي، الألوان مو متناسقة، والروابط مو واضحة. حاولت تبحث عن قسم الهدايا بس نظام البحث كان سيء وما لاقيت اللي بدك ياه بسهولة. بعد ما لاقيت هدية عجبتك، واجهتك مشكلة بإتمام الدفع، لأن الخطوات معقدة ومو واضحة.

بالمختصر، تجربتك بهالمتجر كانت كتير سيئة وقررت إنك ما تشتري منه.

طيب، لو أعطينا هالمتجر لمصمم UI/UX ليحسّن التجربة، شو رح يغير؟

أول شي، رح يعدل الصفحة الرئيسية ويخلّيها مرتبة أكتر، يفرز الأقسام بشكل واضح مثل "هدايا للرجال"، "هدايا للنساء"، "هدايا للأطفال"، بحيث تلاقي اللي بدك ياه بسرعة ومن دون دوخة.

تاني شي، رح يحسّن نظام البحث؛ بيضيف شريط بحث فعال يطلع اقتراحات وأنت عم تكتب، ليوصلك للي بدك ياه أسرع.

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

هالتعديلات مبنية على دراسات وتجارب كبيرة بمجال UI/UX Design، وهو علم بيهتم برضا المستخدم وكيفية تقديم تجربة ممتعة وفعالة بالمواقع والتطبيقات.

بالبوستات الجاية من سلسلة "UI/UX Design"، رح نحكي بتفاصيل أكتر عن هالأساسيات وكيف ممكن نستفيد منها بتصميم مواقع وتطبيقات أفضل.

Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Lobana Ali Balloul على المساعدة في إعداد هذا المحتوى.

سابقاً حكينالكم عن المقارنة بين Local Storage 🆚 Session Storage 🆚 Cookie و لانه هاد الموضوع مهم و حساس رح نرجع نذكركم باهم النقاط:

Cookies و Sessions من أشهر الطرق لتخزين البيانات واسترجاعها، بس قبل ما نقرر أي وحدة نستخدم، لازم نفهم الفرق بيناتهم.

Sessions:

التخزين: مخزنة على الـ server.
المدة الزمنية: عادةً بتستمر لحد ما المستخدم يقفل المتصفح أو بعد فترة من عدم النشاط.
الأمان: أكتر أماناً لأنو البيانات مخزنة على الـ server-side.
الحجم: ممكن تخزين كميات أكبر من البيانات.
آلية نقل البيانات: البيانات بتنقل بين الـ client و الـ server مع كل request.
الوصول للبيانات: ما فيك توصل للبيانات إلا على الـ server.
الاستخدام: بتستخدم عادةً لتخزين معلومات حساسة متل معلومات تسجيل الدخول (email, password).
Cookies:

التخزين: تتخزن على جهاز المستخدم (المتصفح).
المدة الزمنية: فيك تحدد مدة صلاحية الـ cookies، وبتبقى موجودة لفترة محددة حتى بعد إغلاق المتصفح.
الأمان: أقل أماناً لأنو البيانات مخزنة من جانب الـ client وممكن الوصول إلها وتعديلها.
الحجم: في قيود على الحجم، حوالي 4KB، ويمكن تخزين عدة كوكيز لكل دومين.
آلية نقل البيانات: بيانات الـ cookie بتتضمن تلقائياً في الـ Request (HTTP) للـ server.
الوصول للبيانات: ممكن الوصول للبيانات وتعديلها من قبل الـ client.
الاستخدام: تُستخدم لتخزين معلومات مفيدة بتساعد في تخصيص تجربة المستخدم، مثلاً ممكن تستخدم الـ cookies لتخزين العناصر بسلة التسوق لما المستخدم ما يكون مسجل دخول.


Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Reem Ahmad على المساعدة في إعداد هذا المحتوى.

Hello!
We are looking for an experienced Senior Backend Developer / Onsite Damascus to join an online E-commerce Company Based in Syria.
You will be responsible for designing, developing, and maintaining high-quality backend solutions that power our applications. You should have a deep understanding of backend technologies, and architecture patterns.

Key Responsibilities:
-Design & Development: Architect, design, and develop scalable, secure, and high-performance backend systems.
-API Integration: Develop RESTful APIs and integrate third-party services.
Database Management: Design and optimize database schemas, queries, and indexes for performance and scalability.
-Code Quality: Write clean, maintainable, and testable code. Conduct code reviews and ensure best practices.
-DevOps & CI/CD: Implement and maintain CI/CD pipelines, automate deployment processes, and manage cloud infrastructure.
-Security: Implement security best practices, ensuring data protection and compliance with relevant standards.
-Collaboration: Work closely with front-end developers, product managers, and other stakeholders to deliver high-quality products.
-Problem-Solving: Troubleshoot and debug complex issues in production environments.
-Mentorship: Provide guidance and mentorship to junior developers, fostering a culture of continuous learning.


Required Skills & Qualifications:
-Experience: 4+ years of experience in backend development, with a strong portfolio of successful projects.
-Programming Languages: Proficiency in [Insert relevant languages, e.g., Python, Java, Node.js, Ruby, PHP, etc.].
-Frameworks: Experience with backend frameworks like [Django, Laravel, etc.].
-Databases: Expertise in relational databases (e.g., MySQL,) and NoSQL databases (e.g., MongoDB, Redis).
-APIs: Extensive experience in building and consuming RESTful APIs, and understanding of GraphQL is a plus.
-DevOps: Familiarity with Docker, Kubernetes, CI/CD tools).
-Testing: Experience with automated testing frameworks and methodologies (e.g., unit tests, integration tests).
-Version Control: Proficient in Git.
-Agile Methodologies: Experience working in Agile/Scrum environments.
Communication: Excellent verbal and written communication skills.

Additional Information:
Location: Based in Damascus, Syria (Onsite Work)
Competitive compensation package with attractive benefits.
To apply, please send your resume to Rawan@wonderbeauties.com

WebSocket و WebRTC من أهم التقنيات اللي منستخدمها لبناء تطبيقات ويب حديثة بتتميز بزمن استجابة سريع (أو وصول سريع).

اليوم رح نحكي عن هالتقنيتين ونشوف شو الفرق بيناتن.

أولاً: WebRTC
WebRTC هو إطار عمل (framework) بيسمح للتطبيقات الويب والموبايل إنها تتصل ببعض بشكل مباشر وبالوقت الفعلي، وكمان بيتيح نقل بيانات متنوعة (مثل الفيديو، الصوت، أو أي نوع بيانات تاني) بطريقة peer-to-peer.

تقريباً كل المتصفحات الحديثة بتدعم WebRTC، وفي كمان مكتبات تطوير موجهة لأنظمة التشغيل مثل iOS و Android.

WebRTC بيجي كـ مجموعة APIs، وأهمهن:

RTCPeerConnection: هاد الـ API مسؤول عن الاتصال مع الطرف التاني (الـ peer) البعيد، وبيظل محافظ على الاتصال وبيراقب حالته، ولما نكون خلصنا منه بيقوم بإنهاء الاتصال.

RTCDataChannel: بيوفر قناة اتصال ثنائية الاتجاه لنقل البيانات بأي نوع (data) بين الطرفين.

MediaStream: هي الـ API اللي بتساعدنا ندير تدفقات الوسائط، مثل لما بدنا نتعامل مع كميرات أو مايكروفونات، ونقدر نتحكم بهي البيانات مثل الإرسال، التسجيل، التغيير بالحجم، أو عرض المحتوى.

ثانياً: WebSocket
WebSocket هي تقنية بتسمح بالاتصال ثنائي الاتجاه بين متصفح الويب والخادم، يعني اتصال مستمر بالوقت الفعلي.

الاتصال ببلش بمصافحة HTTP (HTTP handshake) وبعد ما يتفق الطرفين (الخادم والمتصفح) على استخدام اتصال TCP، هاد الاتصال بيظل شغال لفترة طويلة (ممكن يكون دايم إذا بدنا).

WebSocket بتتكون من شغلتين أساسيات:

WebSocket protocol: هو البروتوكول اللي بيسمح للمتصفح والخادم يتواصلوا بالوقت الفعلي، وبدعم نقل البيانات بشكل ثنائي أو كسلاسل نصية.

WebSocket API: هاد الـ API بيدير الاتصال، وبيرسل وبيستقبل الرسائل، وكمان بيستمع للأحداث اللي بتوصل من الخادم.

كل المتصفحات الحديثة تقريباً بتدعم WebSocket API.

شو الفرق بين WebRTC و WebSocket؟
WebSocket بيشتغل كبروتوكول اتصال بين المتصفح والخادم، أما WebRTC بيشتغل كبروتوكول peer-to-peer للاتصال بين المتصفحات أو تطبيقات الموبايل.

WebSocket بيشتغل مع بروتوكول TCP بس، بينما WebRTC بيستخدم بروتوكول UDP بشكل أساسي (لكن كمان بيدعم TCP).

إذا كان هدفنا الأمان التام للبيانات، WebSocket بيكون الخيار الأفضل. أما إذا كنا بدنا سرعة كبيرة حتى لو ضيعنا بعض البيانات (loss of packets)، فـ WebRTC مع UDP بيكون خيار أفضل.

WebRTC معمول بشكل رئيسي لبث الصوت والفيديو (لهيك بنشوفه كتير بمكالمات الفيديو والدردشة المرئية). بينما WebSocket ممكن نستخدمه لبث الوسائط، لكنه أكتر ملائم لنقل بيانات نصية مثل JSON (مثل تطبيقات الدردشة، الاختبارات، والتنبيهات).


Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Ayham Ibrahim على المساعدة في إعداد هذا المحتوى.

3 نصائح لتأمين موقعك خليهم ببالك

أولاً الـ MFA (Multi-Factor Authentication: كلمة المرور لحالها ما بتكفي، لازم يكون في خطوة إضافية للأمان مثل رمز يوصلك على موبايلك أو كود على الايميل او غيره! هالشي بيحمي حسابات المستخدمين من الهجمات اللي بتعتمد على سرقة كلمات المرور. متل لما بتسجل دخول على فيسبوك أو غوغل وبيطلبوا منك كود أمان!

الـ Input Validation and Santization: بما معناه "لا تثق بمدخلات المستخدم" و اللي هو مبدأ أساسي في أمن مواقع الويب، لازم تتحقق من كل شي عم يدخله المستخدم للتأكد إنه نظيف وما فيه أكواد خبيثة. مثلاً، تأكد إنه الإيميل مكتوب بصيغة صحيحة وما في محاولات إدخال ضارة. هاد الشي بيمنع سرقة البيانات وبيحمي التطبيق.

مبدأ الـ RBAC (Role-Based Access Control): يعني انه مو كل شخص لازم يشوف كلشي! مبدأ التحكم في الوصول على أساس الدور هو مبدأ بقلل صلاحيات المستخدمين إلى أقل حد ممكن ولذلك لتقليل صلاحيات الهجوم. مثلاً، في موقع ويب قد يكون فيه أدمن ومستخدم، يسمح لعدد محدد جداً من الأدمن للوصول إلى كل البيانات وتعديلها، بينما المستخدمين يسمح لهم فقط برؤية البيانات. يسمح هالمبدأ بتقليل الوصول غير المصرح به وتسريب البيانات.



Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـSana Atrsh على المساعدة في إعداد هذا المحتوى.

بما انه الكل هلا يفترض خلص امتحانات شو رايكم نساوي جلسة متل الجلسات السابقة؟؟

اعطونا اقتراحاتكم شو حابين تكون الجلسة القادمة 📝

إذا حابين تعرفوا آراء الناس اللي كانت معنا بالجلسة السابقة بإمكانكم من خلال التعليقات هنا

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال