Code With Somar

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

مايكروسوفت حالياً عم تشتغل على نقل 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 مشهورة جدًا بتنزلها بشكل تلقائي بدون تدقيق.

تحذير أمني مهم جدًا لكل المطورين والشركات اللي شغالة بـ Node.js اليوم، 31 آذار 2026، انكشف هجوم خطير جدًا على سلسلة التوريد استهدف مكتبة Axios، وهي من أشهر وأكثر مكتبات JavaScript استخدامًا. النسختين المصابتين اللي تم نشرهم هنن: • axios@1.14.1 • axios@0.30.4 والسبب مو bug عادي ولا vulnerability تقليدية داخل كود المشروع، بل تم نشر نسخ خبيثة عبر حساب maintainer مخترق على npm، وانحقنت تبعية خبيثة اسمها plain-crypto-js@4.2.1. التقارير الأمنية بتقول إن هالنسخ اتشالت من npm لاحقًا، لكن أي جهاز أو pipeline سحبها خلال فترة النشر لازم يعتبر نفسه محتمل يكون تعرّض لاختراق فعلي. خطورة الموضوع الحقيقية مو بس باسم المكتبة أو عدد تنزيلاتها، بل بالنتيجة المباشرة للاختراق. النسخ الخبيثة ما كانت بحاجة إنك تشغّل التطبيق أو تستخدم Axios داخل الكود. مجرد npm install أو أي عملية تثبيت جديدة كانت كفاية حتى ينزل payload خبيث ويشتغل على الجهاز أو على بيئة البناء. وهذا يعني إن جهاز المطور نفسه، أو سيرفر CI/CD، أو أي build agent عمل install بهاي الفترة، ممكن يكون صار نقطة اختراق كاملة. شو نتائج هالاختراق فعليًا؟ أول نتيجة وأخطر نتيجة: الموضوع ممكن يتحول من “اعتمدت package مصابة” إلى سيطرة على البيئة اللي ثبتت الحزمة. لأن التحليلات المنشورة بتحكي عن RAT / dropper متعدد المنصات يستهدف macOS وWindows وLinux، مع إمكانية تنفيذ أوامر على النظام، تنزيل ملفات إضافية، والتواصل مع بنية تحكم خارجية. يعني الخطر مو محصور بالمشروع نفسه؛ الخطر ممكن يوصل للنظام، الملفات، الأسرار، ومفاتيح الوصول الموجودة على نفس الجهاز أو نفس الـ pipeline.

تم التواصل مع المقبولين في المنحة. يرجى ممن تلقى بريد الكتروني بالتفاصيل التواصل مع الشركة من اجل استكمال معلوماته و الاستعداد لحضور الجلسة الأولى المقررة اليوم الساعة ٨ مساءً تمنياتي لكم بالتوفيق و حظ أوفر في المرات القادمة لغير المقبولين

انتبه !! لما يصير عندك Fat Controller فيه validation + business logic + emails + payment + inventory هون لازم تنقل المنطق إلى Service Class. هيك: • Controller بيضل خفيف • business logic بيصير منظم • testing بيصير أسهل ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🚨 تحديث أمني مهم لمستخدمي WordPress: إصدار 6.9.4 صار متاح فريق WordPress أعلن عن إصدار WordPress 6.9.4، وهاد التحديث أمني ومهم جدًا، لذلك يُنصح أي حدا عنده موقع ووردبريس إنه يحدث فورًا. اللي صار إنو مبارح نزلت النسختين 6.9.2 و 6.9.3 وكان الهدف منهن معالجة 10 مشاكل أمنية، بالإضافة لمشكلة كانت عم تأثر على تحميل ملفات القوالب ببعض المواقع. لكن بعد المراجعة، اكتشف فريق الأمان إنو مو كل الإصلاحات الأمنية انطبقت بشكل كامل، ولهيك نزل إصدار جديد هو 6.9.4 حتى يكمل التصحيحات المطلوبة ويسكر الثغرات بشكل صحيح. شو الثغرات يلي تم إصلاحها؟ من أبرز المشاكل الأمنية يلي انحلت بهالإصدار: • Path Traversal في PclZip يعني في احتمال استغلال متعلق بالوصول لملفات أو مسارات ما لازم ينوصَل إلها. • Authorization Bypass ضمن ميزة Notes يعني في مشكلة ممكن تسمح بتجاوز بعض الصلاحيات. • XXE ضمن مكتبة getID3 الخارجية وهاي من الثغرات المعروفة يلي ممكن تُستغل للوصول لبيانات أو تنفيذ معالجة غير آمنة لملفات XML. ليش لازم تحدث بسرعة؟ لأنو هاد Security Release، يعني تحديث أمني مباشر، وتأجيله مو فكرة منيحة، خاصة إذا موقعك شغال بشكل فعلي، أو عليه زوار، أو متجر، أو موقع عميل. كيف تحدث؟ فيك تحدث بإحدى الطرق التالية: • من لوحة التحكم: Dashboard > Updates > Update Now • أو تنزّل النسخة من WordPress.org • وإذا التحديثات التلقائية مفعلة عندك، فغالبًا رح يبلش التحديث لحاله الخلاصة إذا عندك موقع WordPress ولسا مو محدث، الأفضل تنتقل مباشرة إلى 6.9.4 لأنو النسخة هاي نزلت تحديدًا لتكمل إصلاحات أمنية ما كانت مكتملة بالإصدارات السابقة. #WordPress #ووردبريس #SecurityUpdate #WebSecurity #CyberSecurity #WebDevelopment

هل صحيح إنو Node.js بيتعامل مع request وحدة فقط بنفس الوقت؟ الجواب: خطأ السبب إنو في خلط شائع بين مفهومين: single thread و single request الـ Node.js فعلًا بيشغّل كود JavaScript الأساسي على single thread، لكن هاد ما يعني أبدًا إنو ما بيقدر يخدم إلا request وحدة. اللي بصير فعليًا إنو Node.js بيعتمد على: • Event Loop • Non-blocking I/O • Asynchronous architecture يعني لما توصله request وهاد الطلب يحتاج: • قراءة من database • طلب من API • قراءة file • أي عملية network / I/O فهو ما بيوقف وبيستنّى النتيجة. بدل هيك، بيبعث العملية للـ system أو للـ thread pool إذا لزم، وبيكمل مباشرة بمعالجة requests تانية. ولما ترجع النتيجة، الـ event loop بيرجع يكمل التنفيذ المناسب إلها. لهيك منقول إنو Node.js ممتاز جدًا بموضوع concurrent requests، وبيقدر يتعامل مع عدد كبير من الطلبات طالما أغلب الشغل I/O-bound. لكن لازم ننتبه لنقطة مهمة: Node.js مو قوي بنفس الدرجة مع CPU-intensive tasks على نفس الـ main thread. مثل: • heavy calculations • image/video processing • large synchronous loops هاد النوع من الشغل ممكن يعمل blocking للـ event loop، وساعتها التطبيق بصير أبطأ باستقبال أو معالجة باقي requests. إذن الفكرة الصحيحة هي: Node.js is single-threaded in executing JavaScript, but not single-requested in handling traffic. فلما حدا يقول: “Node.js can only handle one request at a time” فهاد الكلام غلط. الأصح نقول: Node.js runs JavaScript on a single thread, but can handle many concurrent requests efficiently using non-blocking I/O and the event loop.

فرصة عمل كـ QA مطلوب QA للعمل عن بُعد (Remote) المتطلبات: • يفضّل وجود خبرة سابقة في المتاجر الإلكترونية. • القدرة على إعداد تقارير الاختبار بشكل واضح ومنظم. • خبرة في كتابة Test Cases و Test Scenarios. • القدرة على اختبار المواقع الإلكترونية والتطبيقات والتأكد من جودة الأداء وسلامة الوظائف. • الانتباه للتفاصيل والقدرة على اكتشاف المشاكل ومتابعتها مع الفريق. يفضّل توفر المهارات التالية: • فهم جيد لتجربة المستخدم وسيناريوهات الاستخدام. • القدرة على توثيق الأخطاء بشكل واضح ودقيق. • مهارات تواصل جيدة والعمل ضمن فريق. رابط التقديم: https://forms.gle/Pe5yMMetsgAxi7iU6

أصدقائي الأعزاء، حابب أعلن إني هالسنة موجود كمدرّب ضمن أكاديمية Focal X، ومتل ما عودتكم بكل سنة، دائماً الهدف بالنسبة إلي مو بس التدريب، بل كمان المساهمة بنشر المعرفة ومساعدة الناس الجدية اللي عندها رغبة حقيقية بالتعلّم والتطوّر. ولهالسبب، عم نقدم مجموعة منح تدريبية للراغبين بالدخول إلى تدريب Laravel Advanced. التفاصيل الخاصة بالتدريب موجودة على صفحة الشركة على فيسبوك والتقديم على المنح يتم عبر الفورم التالي: https://forms.gle/qqGceFGpQ2EgiP1d6 بالتوفيق للجميع، وإن شاء الله تكون فرصة جميلة للناس اللي فعلاً حابة تتقدم وتشتغل على حالها.

في مشكلة بتطلعلنا باغلب الوقت انه الكود بصير كله عبارة عن try catch و هالشي ماني منيح لهيك بإمكانك تستخدم retry() لحتى يعيد تنفيذ العملية تلقائياً إذا فشلت مؤقتاً (timeout / connection drop / flaky API). بتعمل retry()؟ بتشغّل callback ✅ إذا نجح → بترجع النتيجة ❌ إذا رمى Exception → بتجرب مرة تانية لحد عدد محاولات محدد. مثال: return retry(5, function () { $response = Http::get('https://api.example.com/data'); if ($response->failed()) { throw new Exception('Request failed'); } return $response->json(); }, 200); يعني 5 محاولات، وبين كل محاولة 200ms delay. ✅ وين بتستخدم retry()؟ • Flaky API requests • Remote service / DB connection بيقطع لحظياً • Queue jobs تعتمد على external resources • أي عملية “بتستاهل محاولة إضافية” قبل ما تفشل نهائياً ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

في مشكلة بتطلعلنا باغلب الوقت انه الكود بصير كله عبارة عن try catch و هالشي ماني منيح لهيك بإمكانك تستخدم retry() لحتى يعيد تنفيذ العملية تلقائياً إذا فشلت مؤقتاً (timeout / connection drop / flaky API). بتعمل retry()؟ بتشغّل callback ✅ إذا نجح → بترجع النتيجة ❌ إذا رمى Exception → بتجرب مرة تانية لحد عدد محاولات محدد. مثال:

return retry(5, function () {
    $response = Http::get('https://api.example.com/data');

    if ($response->failed()) {
        throw new Exception('Request failed');
    }

    return $response->json();
}, 200);

يعني 5 محاولات، وبين كل محاولة 200ms delay. ✅ وين بتستخدم retry()؟ • Flaky API requests • Remote service / DB connection بيقطع لحظياً • Queue jobs تعتمد على external resources • أي عملية “بتستاهل محاولة إضافية” قبل ما تفشل نهائياً ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

تحياتي جميعاً إن شاء الله يكون أسبوعكم جميل وموفّق، وبلا bugs وبلا meetings 😁 وكالعادة، فقرة الأسئلة موجودة على الستوري بحساب الإنستغرام، لكن هالأسبوع في مفاجأة مميزة كمان 👀 قريباً رح أعلن عن منحة تدريبية ضمن Focal X V10 بـ اختصاص Laravel Advanced، واللي رح تكون فرصة قوية لأي شخص حابب يطوّر مهاراته وينقل مستواه لمرحلة أقوى بهالمجال. ورح احكي عن كل التفاصيل بشكل واضح بفيديو قريب جدًا رح ينزل على الإنستغرام إن شاء الله. فـ لا تنسوا تعملوا متابعة للحساب وتضلوا جاهزين للتفاصيل 🔥 بتمنالكم كل التوفيق يا رب ❤️

سابقاً شرحتلكم عن مصطلح Race Condition و هلا خلونا نعرف شو الحل تبعه: أفضل حل ممكن تعمله هو DB transaction + lockForUpdate() لما الموضوع “critical” (stock / vouchers / money): بتعمل DB::transaction() + lockForUpdate() هيك بتقفل الـ row لحد ما تخلص المعاملة، والطلبات التانية بتستنى. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

الـ Race Condition مصطلح منسمعه كتير بس شو بيعني؟ طلبين بيوصلوا سوا، بيقروا نفس القيمة، وبعدين بيكتبوا فوق بعض. مثال: Voucher quota 50 و used=49 طلبين شافوا 49 → الاتنين قبلوا → الاتنين خزّنوا 50… والمفروض واحد ينرفض. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

إذا مهتم تحضر النسخة اللايف وتشاركنا بالفيدباك بإمكانك تتواصل معي بخصوص التسجيل عالكورس او اذا بتحب تحضر الجلسة التعريفية اللي رح تكون يوم السبت الساعة 5 مساءً