Code With Somar

كتير من الاحيان بكون في تاسك معتمد على نظام تشغيل المستخدم يعني لو اندرويد لازم يروح عرابط معين او ايفون بروح عرابط مختلف و المتعارف عليه انه لما منحتاج هيك معلوماة منروح فورا باتجاه الـ User-Agent و لكن منتفاجئ بوجود نسبة من مستخدمي الأندرويد والـ iOS بتضيع منك و بتتصنف على انها Desktop وين المشكلة اصلاً؟ الـ User-Agent القديم صار "بياع حكي" وما عاد يعطينا الحقيقة كاملة لسببين: طلب موقع سطح المكتب (Request Desktop Site): لما مستخدم الأندرويد يفعل هاد الخيار بمتصفح Chrome، المتصفح بيمسح كلمة "Android" عمداً وبغير النص ليبين كأنه جهاز كمبيوتر Linux! المتصفحات الداخلية للتطبيقات (In-App WebViews): لما حدا يفتح رابط موقعك من قلب الواتساب، التيليغرام، أو الإنستغرام، هالمتصفحات أحياناً بتقشّ الـ UA وبتطير منه المعرّفات الأساسية للنظام. الحل الصح يلي بيخلي الكود تبعك فاهم صح هو انك تدمج الـ User-Agent القديم مع الميزة الجديدة sec-ch-ua-platform. اللي هو عبارة عن HTTP Header حديث يُرسله المتصفح إلى السيرفر لإعلامه بنوع نظام التشغيل (Operating System) الذي يعمل عليه جهاز المستخدم. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

مشروعك فيه Authentication. ومشروعك فيه Authorization. ومشروعك فيه Encryption. ومع هيك، مستخدم قدر يوصل لبيانات مستخدم تاني. شو الشي اللي ناقصك أو نسيته؟ ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

من الشغلات الظريفة اللي نزلت مع laravel 13 هيي: Queue-Wide Inspection Methods قبل إذا بدك تفحص الـ jobs الموجودة بـ queues مختلفة، كان لازم تعمل check لكل queue لحالها: reservedJobs('queue1') reservedJobs('queue2') reservedJobs('queue3') هلأ صار فيك تجيب كل الـ jobs من كل الـ queues بنداء واحد:

Queue::allReservedJobs();
Queue::allDelayedJobs();
Queue::allPendingJobs();

هاد الشي مفيد جداً وقت الـ deployments، خصوصاً إذا بدك تتأكد إنه ما في jobs عم تشتغل قبل ما توقف الـ workers. كل method بترجع Collection من InspectedJob فيها معلومات مثل: uuid name attempts createdAt وفي كمان إضافات حلوة بالإصدار: ✅ WorkerPausing و WorkerResuming events صار في events بتنطلق لما الـ queue worker يعمل pause أو resume، مفيدة للـ logging والـ monitoring وقت النشر. ✅ assertSessionMissingInput() Assertion جديد بالـ tests، عكس assertSessionHasInput(). ✅ دعم SortDirection enum بالـ Query Builder صار فيك تستخدم enum مع orderBy() بدل strings. ✅ فلترة schedule:list حسب البيئة مثلاً:

php artisan schedule:list --environment=production

مفيدة لتشوف بس الـ scheduled commands اللي فعلاً رح تشتغل على production. ✅ تحسينات على foreign keys صار onDelete() و onUpdate() يدعموا custom actions، مفيد خصوصاً مع PostgreSQL. ✅ Attribute middleware صار يندمج مع Route middleware يعني إذا عندك #[Middleware] على controller أو method، ما عاد يتم تجاهله إذا route عنده middleware من مكان تاني. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

Laravel Tip: Str::squish() أحياناً الـ user input بيوصل مليان spaces زيادة، tabs، أو new lines، وهاد الشي بيخلي النص شكله مو نظيف بقاعدة البيانات أو بالواجهة. بدل ما تعملها بـ trim() و preg_replace:

$clean = trim(preg_replace('/(?:\s| )+/u', ' ', $input));

استخدم ببساطة:

use Illuminate\Support\Str;

$clean = Str::squish($input);

شو بتعمل؟ بتشيل المسافات من البداية والنهاية، وبتحوّل أي whitespace متكرر داخل النص لمسافة وحدة مفيدة جداً مع: bio, address, comments, search input, product description كود أنظف، data أرتب، و intent أوضح. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

صباح الخير تمنياتي لكم بأسبوع عمل موفق و خالٍ من ال Bugs و ال meetings بانتظار اسئلتكم و استفساراتكم على انستغرام كالعادة من خلال الرابط: هنا

حتى لو تطبيقك ما بيستخدم Server Actions بشكل مباشر، ممكن يكون معرض للخطر إذا كان مبني على Framework يدعم React Server Components مثل: Next.js React Router RSC Waku Parcel RSC Vite RSC Plugin Redwood SDK بالنسبة لـ Next.js، لازم تحدث فورًا للنسخ المرقعة حسب إصدارك: npm install next@14.2.35 # for Next 13.3+ / 14.x npm install next@15.0.8 npm install next@15.1.12 npm install next@15.2.9 npm install next@15.3.9 npm install next@15.4.11 npm install next@15.5.10 npm install next@16.0.11 npm install next@16.1.5 إذا تطبيقك كان Online وهو على نسخة غير محدثة، لا تكتفي بالتحديث فقط. يفضل تعمل التالي: 1. تحديث Next.js / React RSC packages فورًا. 2. إعادة بناء ونشر التطبيق. 3. تدوير الأسرار الحساسة مثل: * API Keys * JWT Secrets * Auth Secrets * Database Credentials * Third-party Tokens 4. مراجعة Logs السيرفر لأي Requests مشبوهة. 5. التأكد من نسخة Next.js داخل السيرفر بعد النشر: npm list next --depth=0 إذا عندك مشروع Next.js App Router أو أي تطبيق يستخدم React Server Components، تعامل مع الموضوع كحالة طارئة وحدث فورًا. هاي مو ثغرة عادية، هاي Pre-auth RCE وتصنيفها أعلى درجة خطورة.

🚨 تنبيه أمني خطير لمطوري Next.js / React Server Components تم الإعلان عن ثغرة خطيرة جدًا في React Server Components تحت الرقم: CVE-2025-55182 الثغرة مصنفة: CVSS 10.0 — Critical وهي عبارة عن Remote Code Execution RCE بدون تسجيل دخول، يعني المهاجم ممكن ينفذ أوامر على السيرفر إذا كان التطبيق يستخدم React Server Components أو Framework مبني عليها. المشكلة موجودة في الإصدارات التالية: react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack ضمن نسخ React: 19.0 19.1.0 19.1.1 19.2.0

🚨 ثغرة خطيرة جداً تم اكتشافها في NGINX تحت الرقم CVE-2026-42945 الثغرة عبارة عن Remote Code Execution (RCE) داخل ngx_http_rewrite_module، ويقال أنها موجودة منذ عام 2008 😶 المهاجم يمكنه تنفيذ أوامر على السيرفر عن بعد بدون Authentication في بعض الحالات، خصوصاً عند استخدام: - rewrite - set 📌 النسخ المتأثرة: NGINX Open Source: 0.6.27 → 1.30.0 ✅ النسخ التي تحتوي على الإصلاح: - 1.30.1 - 1.31.0 تم نشر PoC علني على GitHub، لذلك يُفضل اعتبار الموضوع High Risk والتحديث فوراً.

المهم قبل أي release للـ mobile app إنو يكون كل شي شغال، متفقين على هي النقطة أكيد. بس السؤال اللي لازم نسأله: هل إنو التطبيق “شغال” بيكفي؟ ولا لازم يكون سريع كمان؟ لأن المستخدم ما بيهتم إذا الكود نظيف أو الـ architecture ممتازة. هو بيحس بتجربة الاستخدام: تقطيع بالـ scroll تأخير بعد الضغط animation مو سلسة تنقّل بطيء بين الصفحات قبل الـ release راجع بسرعة: خفف Widget Rebuilds لا تحط شغل ثقيل داخل build() خلي الـ state يأثر بس على الجزء اللي محتاجه راقب الـ layout والـ paint حسّن الصور والـ assets جرّب على جهاز حقيقي مو بس emulator وشغّل التطبيق بـ release mode ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

اكيد شي مرة لما عم تطلب من ال ai انه يعملك مراجعة عالكود تبعك سمعته عم ينبهك عن Race Conditions عندك بالكود و غالباً مافهمت عليه خليني فهمك ياها: تخيل عندك Coupon لازم يُستخدم مرة وحدة بس. الكود بيعمل هيك: يتأكد إنو الكوبون مو مستخدم يطبق الخصم يحدّث الكوبون ويخليه مستخدم منطقي صح؟ المشكلة بتصير لما يجي طلبين بنفس الوقت تقريباً. الطلبين بيقرؤوا إنو الكوبون لسا مو مستخدم، والطلبين بيطبقوا الخصم. هون الكود مو غلط شكلياً، بس غلط تحت الضغط والـ concurrency. الحل غالباً يكون باستخدام: DB::transaction() مع lockForUpdate() حتى نضمن إنو طلب واحد بس يقدر يتعامل مع نفس السجل بنفس اللحظة. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

أكيد سمعتوا عن Laravel 13 والتغيير الكبير اللي جابه بطريقة كتابة الكود؟ خلوني اشرحها بـ Laravel قبل كنا نكتب إعدادات الـ Model جوّا الكلاس باستخدام properties مثل:

$fillable
$hidden
$casts

بس مع Laravel 13 صار في توجه أكبر لاستخدام PHP Attributes. يعني بدل ما يكون الكلاس مليان إعدادات، منكتب الإعدادات فوق الكلاس بهالشكل:

#[Fillable]
#[Hidden]
#[Casts]

الفكرة مو بس شكل أجمل، الفكرة إنو الكود بصير أوضح: الإعدادات لحال، والـ methods والـ relationships لحال. كمان Laravel 13 وسّع استخدام الـ Attributes بأماكن تانية مثل: Queue Jobs لتحديد tries, timeout, و backoff Artisan Commands لتعريف signature, description, و schedule Controllers لتطبيق middleware أو authorization وفي كمان تحسينات مهمة مثل: JSON:API Resources لتوحيد شكل API responses Laravel AI SDK كـ first-party package Vector Search للتعامل مع semantic search Passkeys لتسجيل دخول بدون password Cache::touch() لتمديد عمر cache key بدون جلب البيانات يعني laravel 13 ماكان تحديث عادي ابداً كان خطوة كتير مهمة و صحيحة لتنظيم المشاريع ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

أكيد سمعتوا عن ثغرة CVE-2026-41940 اللي عم تسبب مشاكل ضد cPanel و WHM. خلوني وضحها الكم ببساطة 👇 cPanel و WHM هنن لوحات تحكم لإدارة الاستضافة، يعني من خلالن فيك تدير المواقع، الملفات، قواعد البيانات، الإيميلات، والـ DNS. المشكلة بهالثغرة إنها ممكن تسمح للمهاجم يعمل authentication bypass، يعني يدخل على لوحة التحكم بدون تسجيل دخول صحيح، وكأنه عنده صلاحيات. بعد ما يفوت، بيقدر يعمل أشياء خطيرة مثل: يزرع backdoor حتى يرجع يدخل لاحقاً يضيف SSH public key غريب على السيرفر يرفع PHP web shell للتحكم بالملفات ينفذ أوامر عن بعد remote command execution يسرق كلمات مرور أو بيانات حساسة يستخدم السيرفر بـ crypto mining أو ransomware في الهجمات الأخيرة ظهر Backdoor اسمه Filemanager، ووظيفته إنه يعطي المهاجم قدرة على إدارة الملفات وتنفيذ الأوامر وكأنه داخل على السيرفر. إذا عندك سيرفر عليه cPanel أو WHM، لا تكتفي إنه الموقع شغال. لازم تتأكد إن النسخة محدثة، وتراجع مفاتيح SSH، والملفات الغريبة، وأي نشاط غير طبيعي بالسيرفر. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

ليش بعض Laravel APIs بتصير صعبة الصيانة مع الوقت؟ كتير مشاريع Laravel بتبدأ بسيطة، بس مع توسّع المشروع بيصير الـ Controller مليان Validation و Business Logic و Database Queries و Response formatting بنفس المكان. هون بتبدأ المشاكل: الكود بيتكرر، التعديل بيصير أصعب، والـ Testing بياخد وقت أكتر. الحل الأفضل هو بناء الـ API على طبقات واضحة: Form Request للـ Validation Controller للتنسيق فقط Service للـ Business Logic Repository للتعامل مع قاعدة البيانات API Resource لتوحيد شكل الـ Response ومع هيك بنضيف شغلات مهمة متل API Versioning و Rate Limiting و Queues و Caching. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

اخيراً صار عندي شوية وقت و رح ارجع اشتغل على فيديوهات جديدة عالقناة مجهزلكم اكتر من فكرة كتير مهمين و مفيدين رح تنزل الفيديوهات على قناة اليوتيوب: هنا لا تنسوا الاشتراك بالقناة و تفعيل زر الجرس ليوصلكم اشعار

مايكروسوفت حالياً عم تشتغل على نقل TypeScript compiler أو tsc من JavaScript لـ Go. الفكرة إنو مشاريع TypeScript الكبيرة دائماً بتعاني من شغلات متل: بطء بالـ compilation بطء بالـ type-checking واستهلاك عالي للـ memory بسبب الاعتماد على V8 الحل الجديد هو native compiler مكتوب بـ Go، والنتائج الأولية قوية جداً. على مشروع ضخم متل VS Code، وقت الـ build نزل تقريباً من 77 ثانية لـ 7.5 ثانية، يعني حوالي 10x أسرع.

اذلا كلاوي كود مو شغال عندك فانت مو لحالك للاسف مشكلة من طرفهم

سؤال مقابلة عن Git: بالغلط حذفت branch مهم، وكان هالـ branch لسا ما اندمج، وما حدا عنده نسخة محلية منه. كيف ممكن تسترجعه؟

رابع نتيجة لازم الكل ينتبهلها: أي فريق كان تارك الاعتماد على latest أو upgrades التلقائية، أو كان يستخدم npm audit fix بدون مراجعة دقيقة، صار معرض أكثر من غيره. لأن جزء كبير من أثر هالنوع من الهجمات بيجي من الأتمتة: جهاز جديد، build جديد، pipeline جديدة، reinstall عادي… وكل هاد ممكن يسحب نسخة مسمومة بدون ما ينتبه الفريق إلا بعد فوات الأوان. شو المفروض نفهم من هالقصة؟ المشكلة الأساسية مو بس “لا تستخدم النسخة الفلانية”. المشكلة الحقيقية هي: • جهاز التثبيت نفسه ممكن يكون انصاب • الأسرار الموجودة عليه ممكن تكون انسرقت • الـ CI/CD ممكن يكون تلوّث • أي artifacts أو images انبنت بهالفترة ممكن تكون غير موثوقة • وقد تضطر تعتبر البيئة كلها compromised وتعيد بنائها من الصفر بعض التحليلات ربطت النشاط ببنية خارجية للتواصل والتحكم، وهذا يرفع مستوى الحادثة من package tampering إلى اختراق تشغيلي فعلي لازم يتعامل معه بجدية كاملة. الخلاصة العملية: إذا عندك Axios بمشروعك، لا تتعامل مع الموضوع كأنه تحذير عابر. راجع فورًا: • نسخة Axios الموجودة بالمشروع والـ lockfile • إذا تم تثبيت plain-crypto-js • إذا صار install أو build أو deploy خلال فترة نشر النسخ المصابة • إذا في مفاتيح أو credentials كانت موجودة على نفس البيئة وإذا تأكدت إن النسخ المصابة انثبتت عندك، فالتصرف الصحيح مو بس rollback. التصرف الصحيح هو اعتبار الحادثة اختراق محتمل كامل للبيئة إلى أن يثبت العكس، ثم تدوير كل الأسرار الحساسة، ومراجعة الـ logs، والاتصالات الخارجة، وإعادة بناء البيئة الحساسة عند الحاجة.

ثاني نتيجة مباشرة: أي secrets كانت موجودة وقت التثبيت لازم تُعتبر معرّضة للتسريب. وهذا يشمل مثلًا: • API keys • database credentials • GitHub / GitLab tokens • cloud credentials • environment variables • deployment secrets • private registries tokens بمعنى أوضح: إذا جهاز developer أو CI runner نزل هالنسخة، فالخطر مو فقط على مشروع واحد، بل ممكن يمتد للمستودعات، السيرفرات، قواعد البيانات، وحتى البنية السحابية كاملة إذا كانت المفاتيح متاحة بالبيئة وقتها. لهذا السبب كثير من الجهات الأمنية أوصت بالتعامل مع أي إصابة كحادثة credential compromise مو مجرد dependency issue. ثالث نتيجة مهمة جدًا: الهجوم أصاب مكتبة ضخمة ومشهورة جدًا، وهذا بحد ذاته رسالة خطيرة: الثقة باسم المكتبة أو شهرتها ما عادت كافية. يعني حتى لو الحزمة مستخدمة على نطاق هائل، وحتى لو معروفة من سنين، هذا ما بيمنع استغلال حساب maintainer أو التلاعب بسلسلة النشر. اللي صار مع Axios بيأكد إنه أكبر خطر أحيانًا ما بيكون من كودك أنت، بل من dependency مشهورة جدًا بتنزلها بشكل تلقائي بدون تدقيق.