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

تحسين أداء API باستخدام Data Shaping في ASP.NET Core
عملت أمس على تحسين أداء الـ API باستخدام Data Shaping، دون الحاجة إلى GraphQL، مما يتيح للمستهلك تحديد البيانات التي يريدها فقط بدلاً من استرجاع جميع الحقول في كل طلب.
الهدف من هذا التحسين هو تقليل حجم البيانات المسترجعة، مما يحسن سرعة الاستجابة، يقلل استهلاك الموارد، ويساعد على بناء API أكثر كفاءة. الآن، يمكن لأي طلب تحديد الحقول المطلوبة من خلال Query Parameters، مما يجعل الـ API أكثر مرونة دون الحاجة إلى تغيير الهيكلة أو استخدام تقنيات إضافية.
بهذه الطريقة، تمكنت من تحقيق تحسين ملحوظ في الأداء مع الحفاظ على البساطة وسهولة الاستخدام!

تبسيط تجربة العميل باستخدام HATEOAS في RESTful API
أمس عملت على تحسين الـ API باستخدام HATEOAS، وهو مبدأ يجعل الـ API أكثر ذكاءً وسهولة في الاستخدام من قبل العميل. الفكرة ببساطة هي أن كل استجابة لا تكتفي بإرجاع البيانات فقط، بل تضيف روابط (Hyperlinks) تساعد العميل على معرفة العمليات المتاحة دون الحاجة إلى معرفة مسارات الـ API مسبقًا.
هذا التحسين جعل الـ API أكثر ديناميكية ومرونة، حيث يمكن للعميل التنقل بين الموارد بسهولة دون الحاجة إلى الاعتماد على توثيق خارجي. النتيجة؟ تجربة استخدام أسهل، أخطاء أقل، وتفاعل أكثر ذكاءً بين العميل والخادم! 🚀

🛑نتائج نهاية العام 🛑







أكيد قد سمعت كثير عن End-to-End Encryption واللي أغلب تطبيقات المحادثة الخاصة مثل واتساب سيجنال وتيليجرام يذكروا أنها واحدة من أهم وسائل حماية خصوصية المحادثات بين طرفين💁‍♂️
طيب ايش المقصود بها بالضبط🙆؟
بكل بساطة 😊 هي تقنية تشفير تضمن أن بس الشخصين اللي بيتواصلوا يقدروا يقرؤوا الرسائل ولا أحد ثاني حتى الشركة المطورة للتطبيق نفسها لا الهاكرز ولا الحكومات ولا حتى السيرفرات اللي تمر منها البيانات يقدروا يفكوا التشفير نظريًا وبتعرف ليش بعد شويه.
كيف يتم هذا الشيء؟
الموضوع يعتمد على التشفير غير المتماثل واللي يستخدم زوج من المفاتيح لكل شخص.
المفتاح العام Public Key يستخدم لتشفير البيانات. المفتاح الخاص Private Key يستخدم لفك التشفير.
لما تبدأ محادثة مع شخص كل طرف يولد مفتاحين وبعدها يتم تبادل المفاتيح العامة بحيث كل شخص عنده المفتاح العام للطرف الثاني.
لما تكتب رسالة التطبيق يقوم بتشفيرها باستخدام المفتاح العام للمستلم ولما توصل يقدر يفك تشفيرها باستخدام المفتاح الخاص حقه وهذا يضمن أن ما حد غيره يقدر يفهم محتوى الرسالة حتى لو تم اعتراضها.
الآن السؤال اللي ممكن يجي في بالك طيب كيف نقدر نشوف المحادثات القديمة هل معناه أن المفاتيح محفوظة في مكان معين؟
بالضبط المفاتيح لازم تكون مخزنة بطريقة ما حتى تقدر ترجع للدردشات السابقة بعض التطبيقات مثل واتساب تخزنها محليًا على جهازك بينما بعض التطبيقات الأخرى تخزنها على سيرفرات الشركة وهنا تبدأ الخطورة لأنه إذا السيرفرات ما كانت مؤمنة بشكل قوي فيه احتمال نظري أن الشركة أو أي جهة تقدر توصل للمحادثات لو حصلوا على المفاتيح.
مع ذلك بعض التطبيقات تضيف طبقات أمان إضافية مثل تشفير المفاتيح نفسها بكلمة سر رئيسية بحيث حتى لو أحد حصل عليها ما يقدر يستخدمها بدون معرفة كلمة السر.
في النهاية End-to-End Encryption تقنية قوية جدًا لكنها تعتمد على طريقة التنفيذ ولو ما تم تطبيقها بشكل صحيح تظل فيه ثغرات ممكن تستغل 🙂.
فكرة Key pair منتشرة جدًا خاصة فى برامج الإتصال بالخوادم ssh servers .
وفي النهاية قد لاتكون هي الحلول المثاليه وقد تخترق لكنها عقدت عملية الاختراق على الهاكرز والله المستعان.

#أنا_وأنت_والISP_ثالثنا 📶👀

المبرمجين مستمرين

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

الوضع الحالي

ما زال في فريقين كبار: فريق شايف إن الـ AI بيستبدل المبرمجين ورغم إن كل واحد حر برأيه بس اللي يقول هكذا غالبًا ما دخل المجال أو عاده بأوله. أي حد اشتغل سنوات في السوفتوير بيعرف إن الاستبدال التام هذا صعب هو المفروض أقول مستحيل بس الغباء البشري يفاجئنا كل يوم فخليها صعبة.

الفريق هذا مش عبيط ولا متشائم الفريق هذا شايف وظائف ثانية تم استبدالها فليش ما نستبدل إحنا كذلك؟ اللي يمنع لحد الآن إن السوفتوير مش مجرد كود نكتبه ونطلع release لا السوفتوير عملية لا نهائية ولا في مشروع سوفتوير يخلص دايمًا محتاج صيانة وتطوير. ومهما كانت قوة أدوات الـ AI لها حد وما بتسد في كل شيء ولو حتى أصبحت جامدة بيكون في شخص مسؤول عنها يشغلها.

الفريق الثاني

هذا الفريق متحمس للـ AI بشكل مبالغ فيه ونازلين تشجيع إن الناس كلها تتعلمه وإنه الثورة الصناعية العاشرة واللي ما يلحق بيتأخر ومن ذا القبيل. بس لو ذهبنا في ستين داهية بيكون بسبب هذا الفريق.

رأيي؟

أنا مش مع أي فريق من هؤلاء أنا أشوف إن الـ AI بيقرفنا وهو فعلًا قرفنا في السنوات الأخيرة داخل وخارج السوفتوير. نص مواقع الإنترنت صارت محتوى AI واليوتيوب كل مرة تفتحه بيظهر لك فيديو معمول بالـ AI حتى الإيميلات صرنا نخليه يكتبها لنا وكل شيء اعتقد.

هل يساعدنا؟ أكيد ومش بننكر إن له تطبيقات تفيد البشرية أنا شخصيًا أستخدم أكثر من أداة بشكل يومي وطريقة شغلي تتغير وحدة وحدة. لكن مش أستخدمه علشان اللي يعتمد عليه يكون أحسن مني لا مستحيل. ولا ألف شخص من الجيل الجديد اللي يعتمد على AI tools بيكونوا أفضل من شخص قديم فاهم الأساسيات.
الجيل الجديد من المبرمجين؟ سيكون جيل بدون تفكير جيل مجرد منفذ والمجال هذا قائم على التفكير وأي حد يحب البرمجة يحبها علشان التفكير اللي فيها.

هل الأدوات هذه بتساعد المبرمج يركز على الـ architecture؟

لا ولا بتساعده يركز على أي شيء نفس الأدوات هذه تفكر بالـ architecture بنفسها.

المبرمج بيظل موجود لكن المبرمج الحديث ما بيكون مركز على شيء مجرد يلحق ورا الـ AI بيكون صبي عند الـ AI وهو اللي عمل بنفسه هكذا.

المشكلة الكبيرة؟
حتى لو إحنا انتبهنا واستخدمناه بحذر الشركات بتفرض عليك العمل بالـ AI لأن أصحاب الشركات الكبيرة قالوا إن أغلب الكود عندهم صار يكتب بالـ AI. كيف تقنع الـ co-founder بشيء غير هذا؟ مستحيل يصدقك إلا لما أصحاب الشركات الكبيرة يعترفوا إنهم كانوا غلطانين وهذا الشيء لازال بعيد جدًا.

المستقبل؟

بعد فترة طويلة كثير من السوفتوير بيكون معتمد على الـ AI في كتابته والمنتجات بتكون مليانة مشاكل أكثر من اليوم والمشاكل هذه بتكون integration issues معقدة توقف أنت والـ AI تناظروا بعض وما تعرفوا إيش الحل.

الـ AI بيحل مشاكل؟ نعم جربته في أكثر من مشكلة وكان يعطي سببها لكن له حد ولو وقعت في مشكلة معقدة ما بيسد معك.
طيب ما هو بيتطور؟
نعم بيتطور بس المشاكل تتعقد أكثر ونظل ندور بنفس الدائرة لحد ما السوق يقرر شيء من اثنين:

نستخدم الأدوات بعقل والهدف يكون تقليل وقت العمل مش تقليل عدد الفريق إلى شخص واحد. نتقبل الجودة المنخفضة للسوفتوير كأمر واقع مثل ما إحنا متقبلينها من قبل الـ AI. الحل النهائي؟
إما يكون في building blocks جاهزة لكل شيء، بحيث تقدر تبني تطبيق مثل Uber بسهولة بقطع جاهزة تربطها ببعض مثل WordPress بس على مستوى أكبر.

وقتها المبرمجين بينقسموا لنوعين:

مبرمجين فاهمين كل شيء كويس وهؤلاء اللي بيكتبوا building blocks. مبرمجين فاهمين حاجات سطحية وهؤلاء اللي يستخدموا blocks لبناء التطبيقات.
أي احتمال بيكون الأقوى؟ الله أعلم لهذا بتوقف هنا وأكتفي بالمشاهدة.


#المبرمج_بين_AI_والبقاء_وأنت_حر

رأيت في الصعاب فرص للنجاح و لم ترهبني مهما عظم أمرها و حدها "القسمة المطولة " كانت و لا تزال كابوس مظلم

عيدكم مبارك وكل عام وأنتم بألف خير 🤍🤍

الحمد للّه الذي أعاننا على هذا الشهر الفضيل وعلى أتمامه بمايرضيه عنا

واسأل اللّه القادر أن أراكم جميعاً في رمضان القادم مبرمجين ومهندسين في أعظم الشركات العالمية🔥🔥

افترض أنني أقوم بسحب مبلغ من حسابي البنكي، وفي نفس اللحظة هناك شخص آخر يقوم أيضًا بسحب مبلغ من نفس الحساب. على سبيل المثال، لدي في حسابي 6000 ريال يمني، قمت بالاستعلام عن رصيدي، فظهر لي 6000 ريال، ثم قمت بسحب 1000 ريال، فقام النظام بخصم المبلغ (account.amount -= 1000) وتحديث البيانات في قاعدة البيانات.
لكن الشخص الآخر استعلم عن رصيدي في نفس اللحظة قبل أن أقوم بالسحب، فظهر له أيضًا 6000 ريال. بعد ذلك، قام بسحب 2000 ريال، فقام النظام بتحديث الحساب وخصم 2000 ريال، مما جعله 4000 ريال في قاعدة البيانات. وهنا تكمن المشكلة!
المشكلة ليست فقط في استخدام Transaction كما قد يظن البعض، بل في كيفية التعامل مع البيانات المتزامنة التي يتم تعديلها من أكثر من عملية في نفس الوقت.

مثال آخر

في نظام حجز التذاكر، لنفترض أنني دخلت إلى النظام وأردت حجز تذكرة، وهناك شخص آخر دخل أيضًا في نفس اللحظة. كل واحد منا استعلم عن التذاكر غير المحجوزة، فقام النظام بإرجاع نفس التذاكر لكلينا.
أنا قمت بحجز التذكرة، وفي نفس اللحظة الشخص الآخر كان قد استعلم قبل أن أقوم بالحجز لكنه لم يحجز بعد. بعد ذلك، قام بحجز نفس التذكرة التي حجزتها أنا. والنتيجة؟ تذكرة واحدة تم حجزها لشخصين! قد تعتقد أن هذا مستحيل، لكنه يحصل في الأنظمة التي تتعامل مع عدد كبير من المستخدمين إذا لم يتم التعامل مع المشكلة بشكل صحيح.

المشكلة والحل

هذه إحدى المشاكل التي لا ينتبه لها الكثيرون، ولا تُكتشف إلا بعد تشغيل النظام لفترة طويلة. والسبب أن كل Request يتم تنفيذه باستخدام DbContext جديد لكل مستخدم، مما يعني أن كل شخص يحصل على نسخة مستقلة من البيانات لحظة تنفيذ العملية، دون معرفة ما إذا كانت البيانات قد تغيرت لاحقًا قبل تحديثها.
ملاحظة مهمة:
لا تقل لي "اجعل DbContext Singleton"، فهذا حل خاطئ تمامًا وسيؤدي إلى مشاكل أكبر. العامل المشترك بيني وبين المستخدم الآخر هو قاعدة البيانات فقط، لذلك الحل يكمن في:

استخدام قفل السجلات (Locking): مثل SELECT ... FOR UPDATE عند تنفيذ العمليات الحساسة.

استخدام آلية التحكم في التواقيت (Timestamps): بحيث يتم التحقق مما إذا كانت البيانات قد تغيرت منذ آخر استعلام.

التحقق من البيانات قبل التحديث: وعدم الاعتماد على القيم القديمة التي تم جلبها في بداية العملية.

معلومة إضافية

DbContext هو الطبقة التي تتواصل مع قاعدة البيانات، وكان يتم إنشاؤها سابقًا يدويًا باستخدام ADO.NET ضمن Data Access Layer. سواء كنت تعمل في .NET أو أي إطار عمل آخر يستخدم ORM، فالمشكلة نفسها ستحدث إذا لم يتم التعامل مع تحديث البيانات المتزامنة بشكل صحيح.

عيدكم مبارك وكل عام وأنتم بخير!

#Concurrency_Master
#system_Issues

السلام عليكم ي شباب 👋،
اصحاب التطبيقات المرفوعة في ال stores. في حاجه ضخمه لتوفير الوقت الذي تاخذه عشان التحديث. يعني بدل ما تعمل build و bundling ك apk و رفعه على ال store و تنتظر لصاحب ال store انه يراجع التحديثات الذي فعلتهم. في tool اسمها Shorebird Code Push. يعني الان تعرف تحدث تطبيقك بدون ما تعيد نشرة(رفعة) على ال store.

رابط الفيديو يشرح هذا الشيء كامل 👍

https://youtu.be/LX65WcrwtQc

تقبل الله منا ومنكم صالح الأعمال وكل عام وانتم بخير و بصحة وسلامة اعزائى 🤍.

إلى كل UI/UX Designer وأي واحد يشتغل في المجال السوفتوير...
الـ AI مش جاي ياخذ مكانك، الـ AI جاي يفضحك! أيوه والله، الـ AI بيورّي الناس كلها إن أي حد يقدر يسوي اللي تسويه إذا كان شغلك بس تنفيذ وأدوات.
يعني لما تجي تصمّم لعيادة أسنان، مش تفكر كيف تخلي شكل السِنة حلو وبس، لا، تفكر في إحساس الشخص اللي خايف يروح للدكتور، تفكر كيف تطمّنه من أول ما يشوف التصميم.
شغلتك مش صورة وبس، شغلتك توصّل إحساس! تحرّك قرار، مش مجرد شكل. وهذا شيء الـ AI ما يقدر عليه.
الشطارة اليوم مش إنك تعرف تستخدم الأدوات! الشطارة إنك تكون مفكّر بصري، تفهم كيف تحل مشاكل حقيقية في السوق، تكون فاهم سيكولوجية المستخدم، تكون دارس تسويق، تقرأ، تسأل، تفكّر، تجرّب، تغلط، وتقوم تشتغل من جديد.
اللي الـ AI مستحيل يسويه هو طريقة تفكيرك… كيف تفكّك المشكلة؟ كيف تربط بين فكرة العميل واحتياج الناس؟ كيف تعرف متى تستخدم الأحمر… ومتى لا؟ كيف تخلي تجربة المستخدم سلسة من أول ما يشوف التصميم لحد ما يضغط على الزرار؟
هذا شغلك، وهذا الفرق بينك وبين AI.
#التصميم_مش_أدوات #فكر_قبل_ما_تصمّم #AI_مايقدر_يفكر_مكانك

https://www.shadcn-vue.com/

من أعظم مكاتب ui component على الاطلاق....
الاصل رياكت... وهذا الرابط مشروع port منه خاص بـ vue
وموجود لـ angular طبعاً وفي كثير...

اذا مافي port للفريمورك الي تشتغل عليه هذه فرصه رهيبه تسوي انت المشروع وتشاركه open source
بيكون شي قوي في cv

هل يجب استخدام Clean Architecture في مشروع التخرج؟
مشروع التخرج ليس مجرد عرض تقديمي أو استعراض لمصطلحات معمارية، بل هو إثبات عملي لما تعلمته طوال سنوات دراستك. الفكرة ليست في الالتزام الأعمى بمفاهيم مثل Clean Architecture لمجرد تطبيقها، بل في تقديم منتج نهائي قوي وفعّال يعكس فهمك العميق للمبادئ البرمجية، بغض النظر عن المسميات.
إذا بدأت منذ البداية بتطبيق Clean Architecture وفق أصولها، فهذا رائع، لكنه يتطلب وقتًا وجهدًا كبيرين في التخطيط والتفصيل. أما إن كنت في مرحلة متأخرة من المشروع، فلا يجب أن تستهلك وقتك في تفاصيل قد تؤخرك دون فائدة جوهرية، بل ركّز على جودة الكود، أفضل الممارسات، وتحقيق الأهداف الوظيفية للنظام.
الهدف من مشروع التخرج ليس مجرد استخدام تقنيات متقدمة أو إدخال الذكاء الاصطناعي بلا فهم، بل تقديم نظام يعمل بكفاءة ويمثل مستواك الحقيقي كمبرمج. لو قدّم الطالب نظامًا بسيطًا، لكنه مكتوب بأفضل الممارسات ويمثل فهمًا عميقًا للمفاهيم البرمجية، فهذا إنجاز حقيقي.
النتيجة؟
✔ ركّز على المنتج النهائي
✔ طبق ما يخدم مشروعك فعلًا
✔ لا تضيّع وقتك في تفاصيل لا تضيف قيمة حقيقية

ما هي الـ Anti-Patterns؟ 🤔

الـ Anti-Patterns هي الممارسات السيئة في التصميم أو التطوير التي تبدو في البداية كحلول جيدة، لكنها تؤدي إلى مشاكل معقدة مع مرور الوقت. هي عكس الـ Design Patterns التي تساعد على تحسين جودة الكود.

أشهر أنواع الـ Anti-Patterns:

1️⃣ Spaghetti Code 🍝

كود متداخل ومعقد، بدون تنظيم واضح أو طبقات.

من الصعب قراءته أو صيانته، وكل تعديل قد يسبب مشاكل غير متوقعة.

يحدث غالبًا بسبب غياب التصميم الجيد من البداية.

2️⃣ God Object / Big Ball of Mud 🏀

كائن أو فئة تحتوي على وظائف أكثر من اللازم وتتحكم في كل شيء.

يجعل الكود غير مرن، وكل تعديل قد يؤثر على أجزاء متعددة.

3️⃣ Hard Coding 🔢

وضع القيم مباشرة داخل الكود بدلًا من استخدام إعدادات قابلة للتغيير.

مثل كتابة "localhost:1433" داخل الكود بدلًا من قراءته من ملف إعدادات.

4️⃣ Magic Numbers and Strings 🎩

استخدام أرقام أو نصوص بدون تفسير، مما يجعل الكود غير مفهوم.

الحل: استبدالها بالثوابت (const) أو القيم المعرفّة (enum).

5️⃣ Copy-Paste Programming 📄📄

تكرار نفس الكود في أكثر من مكان بدلًا من إعادة استخدامه بطريقة صحيحة.

يؤدي إلى صعوبة في الصيانة، حيث يجب تعديل كل نسخة يدويًا.

6️⃣ Singleton Overuse 🏛

استخدام Singleton في كل مكان، مما يجعل الكود معتمدًا على حالة واحدة يصعب التحكم بها.

الحل: استخدم Dependency Injection بدلًا من ذلك.

7️⃣ Lava Flow 🌋

كود غير مستخدم أو موروث من مراحل تطوير سابقة لكنه لا يزال موجودًا بدون داعٍ.

يزيد تعقيد المشروع، ويجعل التعديلات أكثر خطورة.

8️⃣ Golden Hammer 🔨

محاولة استخدام نفس الأداة لحل كل مشكلة، مثل استخدام Design Pattern معين في كل موقف حتى لو لم يكن مناسبًا.

كيف تتجنب الـ Anti-Patterns؟

✅ استخدم مبادئ SOLID لتصميم الكود.
✅ ركّز على نظافة الكود بدلًا من الحلول السريعة.
✅ قم بالمراجعة الدورية للكود (Code Reviews).
✅ تعلم متى ولماذا تستخدم كل نمط تصميم، وليس فقط كيف تطبقه.
النتيجة؟ لا تقع في فخ الـ Anti-Patterns، فمعظمها يبدأ كحل سريع لكنه ينتهي بكود كارثي على المدى الطويل! 🚀

Hexagonal و Onion و Clean Architecture: هل نحن في سوق "تشليح" البرمجيات؟

في عالم البرمجيات، كثيرًا ما نسمع عن Clean Architecture، ثم نجد Hexagonal Architecture وOnion Architecture تتصدر المشهد، مما يجعل البعض يتساءل: هل هذه مجرد إعادة تغليف لنفس الفكرة، أم أن هناك فروقًا حقيقية؟ 🤔
الحقيقة؟ هذه المعماريات ليست سوى تفكيك وإعادة ترتيب لنفس المفاهيم، وكأننا في سوق "تشليح" البرمجيات، حيث يأخذ كل منهج جزءًا من الآخر، يغير بعض الأسماء، ثم يقدّمه كمفهوم جديد. لكن الفرق الحقيقي يكمن في التفاصيل:
1️⃣ Clean Architecture (المفهوم الأصلي)

يُركز على المرونة العالية، قابلية التغيير، وفصل الطبقات بطريقة تجعل النظام غير معتمد على أي إطار عمل أو قاعدة بيانات.

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

2️⃣ Hexagonal Architecture (Ports and Adapters)

الفكرة الأساسية هي أن النظام يجب أن يكون مستقلاً تمامًا عن العالم الخارجي (مثل قواعد البيانات، الـ APIs، وواجهات المستخدم).

يتم تحقيق ذلك باستخدام المنافذ (Ports) والمهايئات (Adapters)، بحيث يتواصل النظام مع الخارج عبر واجهات مجرّدة.

3️⃣ Onion Architecture

يشبه Clean Architecture لكنه يؤكد أكثر على عدم الاعتماد على أي طبقة خارجية.

البنية هنا حرفيًا مثل البصلة 🧅، حيث تكون القواعد التجارية في الطبقة الأعمق، وتلتف حولها الطبقات الأخرى بشكل محكم.

إذًا، هل هناك فرق جوهري؟

✅ Clean Architecture هو الأصل، والاثنان الآخران مجرد تفصيلات مختلفة لنفس المفهوم.
✅ Hexagonal يركز على العزل بين النظام والعالم الخارجي عبر المنافذ والمهايئات.
✅ Onion يأخذ نفس المبدأ لكنه يضع القواعد التجارية في المركز، مع طبقات منظمة بشكل دائري.
النتيجة؟
🔹 هذه ليست مدارس مختلفة، بل مجرد "تشليح" لنفس الفكرة بأساليب متنوعة.
🔹 لا تهتم بالأسماء، ركّز على المبدأ الأساسي: جعل النظام نظيفًا، مستقلاً، وسهل التغيير.
🔹 إذا فهمت واحدة منها، فأنت عمليًا فهمتها كلها!

#الواقع

طيب، اليوم لما نجي نتكلم في أي موضوع، لازم نحدد حاجة مهمة: من اللي بيتكلم؟ ومن اللي بيسمع؟ تمام؟ يعني، ممكن تكون بتتكلم مع شخص مبتدئ، أو شخص فاهم ومتخصص. وكذلك اللي بيتكلم نفسه، ممكن يكون فاهم، وممكن يكون مش فاهم. فالكلام اللي بتقوله بيختلف حسب المجتمع اللي بتخاطبه.
خلونا ناخذ مثال من الواقع:
أنت ساكن في بيت، ومقفل بقفل تمام. مقتنع إن القفل هذا بيحمي بيتك من أي حد يدخل؟ طيب، لو المفتاح حق القفل يقدر أي حد يعمله عند الحداد اللي تحت البيت ب ٣٠٠ ريال؟
لو جيت تقول "أنا مركب قفل بيحمي البيت"، هذا كلام ينفع تقوله لأطفال في أولى ابتدائي. لكن لو بتكلم مندوب شركة تأمين، لازم تقوله بطريقة ثانية: "أنا عندي قفل بيحمي بيتي من أي حد ما مابش معه ٣٠٠ ريال يشتري المفتاح من الحداد اللي تحت". لكن لو المفتاح مرمي قدام الباب، فأنت ساعتها بتقول: "القفل بيحمي البيت من أي سارق أعمى"، لأنه أي سارق عادي بيشوف المفتاح ويفتح الباب.
طيب، لو ما فيش حداد، وأنت ساكن في الدور الأرضي وشباكك مفتوح؟ هل القفل بيحمي البيت؟ لا، لأن الشخص مش محتاج يدخل من الباب أصلاً، يدخل من الشباك. لكن لو الشباك صغير وما يقدر يدخل منه إلا الأطفال، ساعتها بتقول: "بيتي محمي من أي حد وزنه أكثر من ٢٥ كيلو".
كل هذا نفس الفكرة، نفس القفل، بس طريقة الكلام تختلف حسب اللي بيسمع. وهذا هو اللي يربطنا بالموضوع الأساسي: الناس اللي تتكلم عن الأمان (Security) والحماية (Protection)، وما تفهم الفرق بينهم.
في بعض الناس لما تستخدم "const" أو تعدل في بعض الفيلدات، تقول: "إحنا كذا أمنّا البيانات عشان ما حدش يعدلها". طيب، هل فعلاً هذا يمنع أي حد من التعديل؟ خلونا نشوف.

عندك ثلاث أنواع من الناس يتعاملوا مع الكود حقك:

زملاؤك في الفريق: عندهم وصول مباشر للكود، ولو عايزين يعدلوا حاجة، بيعدلوها. مش لأنك عملتها "const"، بل لأن الشركة عندها سياسة مراجعة للكود، واللي ما يوافق عليه الـ Code Review ما يتم.

الأطراف الخارجية: بغض النظر عن أي حماية تسويها، كل لغة برمجة تقدم طرق للوصول للبيانات والتعديل عليها. مثلاً، في C++ ممكن يرمي الكائن كله داخل Pointer ويعدل فيه، وفي C# و Java عندك Reflection.

المستخدم النهائي: التطبيق لما يشتغل، النظام يشوف البيانات كأنها بيانات في الذاكرة، أي شخص معه Debugger أو Memory Viewer يقدر يعدل عليها.

بالتالي، لو كان هدفك تمنع أي تعديل، فشلت فشل ذريع، لأن أي حد يتعامل مع السيستم حقك يقدر يغيره.

وهنا نرجع للفرق بين الأمان والحماية:

Security (الأمان): أنك تمنع حد ما تريده يغير البيانات.

Protection (الحماية): أنك تمنع التغييرات غير المقصودة.

مثال:

عندك متغير يخزن درجة الطالب، والدرجة تكون بين 0 و 100. ما تريد أحد يدخل درجة أكثر من 100 أو أقل من 0. مش لأنك تبغى تتحكم فيهم، بل لأن المنطق حق البرنامج كذا. فتسوي دالة (Setter) تتأكد إن الدرجة في النطاق الصحيح، ولو في خطأ، ترمي Exception.
هنا، أنت حميت البيانات، لكن ما أمنتها. الحماية كانت على البيانات نفسها، مش على من يقدر يعدلها.



الفرق بين Data Protection و Data Security كبير جداً، وللأسف بعض الناس اللي يقولوا عن نفسهم متخصصين ما يفرقوا بينهم. كل اللي يعرفوه هو إنهم "بيمنعوا الناس من التعديل"، وهذا كلام ممكن يجي من شخص ما يعرف برمجة أصلاً.
فالنهاية: إذا كانت الكبسولة (Encapsulation) ما قدرت تمنع التعديل تماماً فهي فشلت من أول مبدأ في الـ OOP وانتهى الحوار!

#عيد_انتبه_لمنزلك
#رسالها_100_معيد_ودكتور

الحقيقة ان Encapsulation هو وسيلة لتنظيم الكود والتحكم في كيفية الوصول إلى البيانات، لكنه ليس وسيلة لحمايتها من التهديدات الأمنية
أي ان
Encapsulation يساعد في الحفاظ على سلامة البيانات (Data Integrity) لأنه يمنع التعديلات العشوائية أو غير المنطقية من داخل الكود نفسه

تعلم كيف تتعلم ! لو صببت الحليب قبل الشاهي أو العكس هل في فرق ؟

شغل Github Actions في الـ local

بس ليش نشغله في local؟
1 - نحصل Feedback بشكل أسؤع بدل ما نسوي git push كل شويه وننتظر الرد من github
2 - ليش لا... 😁👍🏻

https://nektosact.com
https://github.com/nektos/act

موضوع الأمن السيبراني مش قصة tools مدري ايش عندما حتى تدخل المجتمعات هذا أو أي جانب منهم حتى عندما تدخل معهم تفقد الثقه الموضوع ليس هذا والامن والحماية مبني على أساس قوي وبلاش تضيع وقتك في اختراق شبكة جارك أو أين كان طبعا هذا ليس اختراق والا تتعب في ال social engineering و الويب dark هم من عمل التكنلوجيا وفر الكل واحد سوق ومستفيد من الكل المتهبشين والي لا يعرف القانون فتح له سوق والي ماشي بالقوانين وفر له كذلك تعلم برمجة صح وكل خطوة فكر ازي تحميها .
#ازي_وضع_الأمن_السيبراني