مخاطر العمل مع الـ Soft Delete لازم تعرفها:

خلينا نشرحلك ياها بالاول هي عبارة عن ميزة بـ Laravel بتسمحلك "تحذف" البيانات بدون ما تنحذف فعلياً من الـ database. البيانات بتضل موجودة، بس بينضاف timestamp بعمود deleted_at ليدل إنه البيانات محذوفة. هالميزة مفيدة إذا كنت بحاجة لاسترجاع البيانات أو لمراجعتها لاحقاً.

طيب شكلها مفيدة و حلوة ليش لازم انتبه بالشغل معها؟

1. مشاكل الأداء مع الجداول الكبيرة
   كل query بـ Laravel مع Soft Deletes بيضيف شرط WHERE deleted_at IS NULL افتراضياً، وهذا ممكن يأثر على الأداء مع ازدياد حجم البيانات.

2. التناقض بين Eloquent و Query Builder
   Eloquent تلقائياً بيستثني الـ records المحذوفة، بس إذا استخدمت Query Builder، الشرط ما بينضاف تلقائياً، وبتضطر تضيفه يدوياً، مما قد يسبب أخطاء إذا تم نسيانه.

3. عدم وجود Cascading Deletes
   الـ Soft Delete ما بينفذ عمليات الحذف التلقائي على البيانات المرتبطة، مثل حذف الـ posts أو الـ comments المرتبطة بالمستخدم، مما يتطلب تنفيذها يدويًا.

4. مشاكل مع الـ Unique Constraints
   لما تسوي Soft Delete، الـ record المحذوف بيضل موجود، وهاد ممكن يسبب مشاكل مع الأعمدة اللي عليها قيود فريدة (Unique Constraints) مثل البريد الإلكتروني.

طيب شو الحل؟
إذا كانت مشروعك كبير أو حساس، فكر باستخدام حزمة مثل Spatie Laravel Deleted Models. هالحزمة بتنقل البيانات المحذوفة لجدول منفصل، بتحسن الأداء، وبتجنب مشاكل الـ unique constraints، وبتسهل إدارة العلاقات المرتبطة.

إذا عندك تجربة أو حل مشابه، شاركنا رأيك بالتعليقات

مشكلة و حل :

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

كل شي واضح وبسيط، وعرفت العلاقة بين المهام والمستخدمين في الـ Model الخاص بـ SharedTask، و بتتوقع أنه يرجع لك بيانات المستخدم المدعو بشكل Object.

لكن بدل ما ترجع العلاقة Object المستخدم (User)، بيرجعلك رقم فقط من الجدول، وإذا حاولت الوصول لأي prorite مثل $sharedTask->invitee->id، بتظهر رسالة خطأ مثل:
"Attempt to read property 'id' on int"

شو سبب هي المشكلة طيب؟

Laravel بيختار الأعمدة اللي بتتطابق أسماؤها مع أسماء العلاقات قبل ما يرجع العلاقة نفسها.
بمعنى، إذا عندك عمود اسمه invitee، وعلاقة بنفس الاسم، Laravel بيفترض إنك بدك العمود مش العلاقة.

اوك و الحل؟
الحل بسيط جدًا: غير اسم العلاقة لتجنب هذا التضارب.
بدل ما تكون العلاقة اسمها invitee (مثل العمود)، غيرها لشي واضح أكتر، مثل: inviteeUser.

هلا لما تستدعي العلاقة باستخدام $sharedTask->inviteeUser، Laravel رح يفهم إنك تقصد العلاقة ويعيد كائن المستخدم بالشكل الصحيح.

و خلي ببالك دوماً انه اسم العلاقة يكون مختلف عن اسم اي عمود بنفس الجدول

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

إذا مر عليك خطأ مشابه، شاركنا تجربتك وكيف حلّيته! ?

كتير منسمع عن مصطلح الـ Self-Relationships و اليوم جاي احكيلك عن هاد المفهوم

شو يعني Self-Relationships بالاول؟
الـ Self-Relationships بتعني لما يكون عندك Object لازم يرتبط بـ Object تاني من نفس النوع مثلاً:

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

ليش منحتاج الـ Self-Relationships ؟
اهم ميزة فيها انها بتحل مشاكل هيكلية كتيرة مثل:
الهيكل التنظيمي للشركات: لمّا الموظفين يكونوا تابعين لمدراء ضمن نفس الهيكل.
التصنيفات والفئات الفرعية: لتنظيم المنتجات أو المواضيع بشكل هرمي.
الصداقة في الشبكات الاجتماعية: لإنشاء علاقات متبادلة بين المستخدمين.

و هيك لما تنسال بمقابلة العمل عن الـ Self-Relationships صرت بتعرف تشرح عنها و هلا خبرني اشتغلت فيها بمشاريعك سابقاً؟

? Docker مكتوب بـ Go
☸️ Kubernetes مكتوب بـ Go
? Terraform مكتوب بـ Go
? Prometheus مكتوب بـ Go
? Grafana مكتوب بـ TypeScript
⚙️ Jenkins مكتوب بـ Java
? Ansible مكتوب بـ Python
? Chef مكتوب بـ Ruby
? Puppet مكتوب بـ Ruby
? ELK Stack (Elasticsearch, Logstash, Kibana) مكتوب بـ Java و Ruby
? Nagios مكتوب بـ C
? Splunk مكتوب بـ C++
☁️ AWS CLI مكتوب بـ Python
? Azure CLI مكتوب بـ Python
? GitLab مكتوب بـ Ruby و Go
? CircleCI مكتوب بـ Clojure
? HashiCorp Vault مكتوب بـ Go
? ArgoCD مكتوب بـ Go
? Istio مكتوب بـ Go

يعني كل هالأدوات يلي بتحرك عالم DevOps مبنية بلغات مثل Go، Python، Ruby، و Java.

ما صار وقت تضيف Go لخططك لسنة 2025؟ ?

شاركونا حساباتكم على Linkedin مع لمحة عنكم و عن خبراتكم حتى نساوي Connection لبعض.

رابط حسابي: هنا

أصدقائي الاعزاء تمنياتي لكم ببداية اسبوع عمل موفقة لكم جميعاً

كما هي العادة نبدأ اسبوعنا بفقرة سؤال و جواب على الـ story في حسابي على instgram من هنا

??❤️

تحذير أمني مهم حول Apache Tomcat

Apache Tomcat هو خادم ويب مفتوح المصدر مخصص لتشغيل تطبيقات الويب المكتوبة بلغة Java. بيستخدموه المطورين لتشغيل التطبيقات الديناميكية اللي بتعتمد على Servlets وJSP (JavaServer Pages).

إذا كنت مشغّل Tomcat على نظام ملفات غير حساس لحالة الأحرف (Case Insensitive) وعدّلت إعداد readonly الافتراضي للـ servlet بحيث صار false بدل true، ممكن تكون معرض لهجوم خطر يسمح للهاكرز ينفذوا أوامر مباشرة على السيرفر (RCE).

الإصدارات المتأثرة:
Tomcat 11: من الإصدار 11.0.0-M1 لـ 11.0.1.
Tomcat 10: من الإصدار 10.1.0-M1 لـ 10.1.33.
Tomcat 9: من الإصدار 9.0.0-M1 لـ 9.0.97.
الحل موجود في الإصدارات:

Tomcat 11.0.2 وما فوق.
Tomcat 10.1.34 وما فوق.
Tomcat 9.0.98 وما فوق.

شو لازم تعمل؟ ?
الخيار الأفضل: تحديث Tomcat

حدّث لإصدار آمن حسب الإصدار اللي عندك.
إذا التحديث مو خيار:

عدّل خاصية النظام sun.io.useCanonCaches بناءً على إصدار Java يلي عم تستخدمه:
Java 8 أو Java 11:
حط الخاصية على false (لأن الافتراضي هو true).
Java 17:
إذا الخاصية موجودة، لازم تكون false.
Java 21 وما فوق:
ما في داعي لأي تعديل لأن المشكلة انحلت.

ملاحظات:
الإعداد الافتراضي للـ readonly هو true، فإذا ما عدّلت عليه، غالباً ما في داعي للقلق.
بس إذا كان الإعداد false، فالنظام معرض للاستغلال.
? لازم تتحرك بسرعة لتحمي السيرفر تبعك! ?

شو يعني Caching؟ ?

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

طيب شو أنواع Caching وكيف بيشتغل؟ خلونا نفصل أكتر:

1. Browser Caching
   هون الفكرة إنو المتصفح عند المستخدم بيخزن نسخة من الملفات تبع التطبيق (مثل الصور، الأكواد، أو البيانات) ليقدر يفتح الموقع أسرع لما يرجع يزوره. في عدة تقنيات لهذا النوع، مثل:

Service Worker Cache: تخزين البيانات لتطبيقات الويب التفاعلية.
Back-Forward Cache: تسريع التنقل بين الصفحات اللي زارها المستخدم.
Cache Storage API: طريقة متقدمة للتعامل مع الكاش بشكل مباشر.
2. CDN Caching
هون بيجي دور شبكات توزيع المحتوى (Content Delivery Networks). الفكرة إنو الملفات تبع التطبيق بتتخزن على سيرفرات موزعة حول العالم، ولما المستخدم يطلب البيانات، بيخدموه من أقرب سيرفر إلو جغرافيًا. هاد الشي بيساعد بتقليل وقت التحميل وتحسين التجربة للمستخدم.

1. Application Caching
   هاد النوع بيشتغل ضمن التطبيق نفسه. بنخزن بيانات معينة داخل التطبيق مثل بيانات المستخدم أو معلومات بتحتاجها الصفحات بشكل متكرر. مثال: لما نخزن معلومات المستخدم (User Info) بدل ما نطلبها كل مرة من السيرفر.

Caching مو بس بيساعد بتحسين الأداء، كمان بيوفر موارد السيرفر وبيحسن تجربة المستخدم بشكل ملحوظ. فدائمًا خلي الكاش ضمن خططك إذا بدك تطبيق سريع وفعّال! ?

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

Facebook | Linkedin |Instgram | Telegram | YouTube

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

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

النادل هون صار اسمه: مدير حالة او متل ما نحنا المبرمجين منعرفه بـ State Management خلوني اشرحلكم هاد المفهوم بشكل افضل

الطلبات اللي جمعها النادل هي "الحالة" (State):
قائمة الطلبات لكل طاولة (البيانات).

الأصدقاء اللي طلبوا الطعام يمثلون "الإجراءات" (Actions):
طلب كل شخص يؤدي إلى تحديث الحالة (إضافة أو تعديل طلب في القائمة).

النادل مسؤول عن إرسال الطلبات للطباخ (Updating the State):
يقوم بمعالجة الطلبات وتحديث الحالة بناءً عليها.

الطباخ (البرنامج) يعتمد على القائمة الحالية (Current State):
ليعرف شو لازم يطبخ.

عندما تنتهي الأطباق، يقوم النادل بتحديث الحالة في الواجهة (Re-rendering):
يعرض الطلبات النهائية على الطاولة.

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

مع إدارة حالة جيدة:
الطلبات منظمة في مكان مركزي.
النادل والطباخ يتبعان دورة واضحة ومنظمة.
الجميع يحصل على طعامه بطريقة صحيحة وسلسة.

إدارة الحالة في البرمجة تشبه هذا النادل تمامًا. عندما تكون الحالة موزعة بين المكونات (أو الطاولات)، فإن وجود نظام مركزي مثل Redux أو Bloc بيساعدنا على الحفاظ على كل شيء تحت السيطرة.

خبرني كيف خبراتك مع الـ State Management و كنت فهمانها قبل هاد البوست ؟؟؟

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

Facebook | Linkedin |Instgram | Telegram | YouTube

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

احياناً نقوم بتشغيل المشروع بكامل تفاصيل باستخدام Docker containers حتى الـ Web Server مثل Nginx او Apache و اللي متعامل مع الاستضافات بيعرف انه بكون احيانا في نسخة افتراضية بتكون موجودة اساساً مع السيرفر.

و لنفترض المثال التالي:
انه انت مشغل المشروع باستخدام Docker containers و الـ VPS عمل reboot ؟؟

هون رح تخبرني عاااادي ولا على بالي لان الـ Docker containers بيعمل restart تلقائي

كلام صحيح نسبياً لكن وجب التنويه انه ممكن إذا كنت عامل Nginx container عم يشتغل على Port مثل 80 ممكن ما يقدر يشتغل لان ممكن النسخة الافتراضية من السيرفر حجزت الـ port قبل منها

لهيك دوماً اتاكد من تعطيلك لاي خدمات مانك عم تستخدمها على السيرفر تبعك.

هل كنت بتعرف هي المعلومة سابقاً؟

شاركني بتجاربك مع Docker و الاستضافات بالتعليقات

ولا تنسوا اني معكم على instgram بالـ story و الـ reels احكي بشكل موسع عن هي الامور lمن خلال حسابي على الرابط: هنا

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

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