Code With Somar

اللي عنده موقع أو سيرفر شغّال على PHP ينتبه! في ثغرتين خطيرات بتقييم 9.2/10، وبحسب الباحثين ممكن يسمحوا للمهاجم يشغّل أوامر عن بُعد على السيرفر. 📌 بحسب الإعلان، التحديث الأمني موعده اليوم 21 أكتوبر الساعة 5 المسا بتوقيت سوريا. وقت نشر الخبر، لسا ما كانت تفاصيل النسخ المتأثرة مؤكّدة. ✅ شيّكوا على إعلان PHP الرسمي، وحدّثوا للنسخة المصحّحة أول ما تتوفر، خصوصي السيرفرات المكشوفة عالإنترنت. ⚠️ واللي لسا شغّال على PHP 8.1 أو أقدم، هالنسخ انتهى دعمها من مشروع PHP ولازم يخطّط لترقيتها. لوقت نشر الخبر ما كان في استغلال مُبلّغ عنه، بس هالشي مو ضمان إنو الوضع آمن.

Apple حدّثت الـ App Review Guidelines ⚠️ إذا عندك Feature مخفيها أثناء الـ App Review وبتفعّلها لاحقاً عبر Remote Config أو Feature Flags، ممكن تواجه مشكلة. استخدام هالأدوات مو ممنوع، بس إخفاء الميزات عن Apple ممكن يسبب رفض تطبيقك.

يا صباح الـ internal server error

فيديو ممتع و قادر يسلط الضوء على تفتاصيل حلوة و بيعطيك لمحة عامل عن الـ Backend Ecosystem https://youtu.be/mZ27vUoOEB0?si=McXXFmTfdkteDkTZ

مطلوب Senior Flutter Developer نوع الدوام: Full-Time نمط العمل: In-Office الموقع: Iraq - Erbil نبحث عن Senior Flutter Developer للانضمام إلى فريقنا المهارات المطلوبة خبرة قوية وعملية في Flutter وDart ضمن تطبيقات Production حقيقية. فهم عميق لـ Flutter Architecture وWidget Lifecycle وRendering وAsynchronous Programming وState Management. خبرة قوية في BLoC / flutter_bloc. خبرة في التكامل مع REST APIs باستخدام Dio أو حلول Networking مشابهة. خبرة عملية مباشرة في نشر وصيانة التطبيقات على Google Play وApple App Store. القدرة على تشخيص وحل مشاكل Native الخاصة بـ Android وiOS. خبرة عملية في Gradle وCocoaPods وXcode وSigning وMobile Build Configuration. خبرة في Firebase، وخصوصًا FCM وCrashlytics وRemote Config. خبرة في تطبيق Deep Links وApp Links وUniversal Links. مهارات قوية في Debugging وProfiling وPerformance Optimization. القدرة على العمل بأمان ضمن Production Codebase كبير وإجراء Refactoring تدريجي دون التأثير على استقرار التطبيق. خبرة جيدة في Git وCode Review Workflows. يفضل وجود خبرة في: خبرة في Mobile Payment Gateway Integrations. خبرة في WebView-based وApp-to-App Payment Flows. خبرة في Flutter Performance Profiling باستخدام DevTools. معرفة جيدة بـ Mobile Application Security Best Practices. خبرة في Mobile CI/CD Pipelines. معرفة عملية بـ Kotlin و/أو Swift. خبرة في Mixpanel أو منصات Product Analytics مشابهة. خبرة في Google Maps وLocation-based Features. معرفة بـ Fragment Shaders أو Custom Rendering في Flutter. نبحث عن شخص سبق له أن تحمّل مسؤولية Production Flutter Application حقيقي، وليس فقط تطوير Screens أو Features منفصلة. يجب أن يكون قادراً على تحمل مسؤولية الـ Feature من Architecture وImplementation، مروراً بـ Testing وNative Configuration، وحتى Release وMonitoring ومعالجة المشاكل التي تظهر في Production. سيتم تقييم مستوى الخبرة بشكل أساسي بناءً على Technical Depth وProduction Ownership والقدرة العملية المثبتة، وليس فقط على عدد سنوات الخبرة. للمهتمين بإمكانكم إرسال ال CV مع روابط التطبيقات التي عملتم عليها إلى البريد التالي: kesen.somar.99@gmail.com مع تحديد الموضوع بـ FL-PRO سوف يتم تجاهل اي بريد لا يحتوي على الموضوع المحدد سابقاً

باقي يومين فقط لانتهاء التسجيل

من الميزات الجديدة بـ PHP 8.6 هي Partial Function Application. الفكرة ببساطة: فيك تاخد function وتحدد جزء من الـ parameters مسبقاً، وتترك الباقي لوقت الاستخدام. مثلاً:

$makeSlug = str_replace(' ', '-', ?);


$makeSlug('Hello World');
// Hello-World

هون حددنا مسبقاً إنو أي space تتحول لـ -، وتركنا النص نفسه كـ parameter لوقت التنفيذ. الميزة بتبين قوتها أكتر مع Pipe Operator:

$output = 'Hello World'
    |> str_replace(' ', '-', ?)
    |> strtolower(...);

// hello-world

بدل ما نكتب functions متداخلة ببعض، صار فينا نبني transformation pipeline أوضح وأسهل بالقراءة. ميزة صغيرة، بس ممكن نشوف استخدامها كتير بالـ modern PHP code. 🔥

بتعرف انه قبل PHP 8.6 ما كان مسموح تعمل هيك:

public readonly string $name = 'create_books_table';

السبب إنو readonly property بقيمة ثابتة كان قريب جداً من فكرة الـ constant. بس بعد إضافة Property Hooks وإمكانية تعريفها ضمن interfaces، صار وجود immutable default value مفيد ببعض الـ contracts. مثلاً:

interface MigratesUp
{
    public string $name { get; }

    public function up(): QueryStatement;
}

ومع PHP 8.6 صار implementation مثل هاد مسموح:

final class CreateBooksTable implements MigratesUp
{
    public readonly string $name =
        '2026-01-01_create_books_table';

    public function up(): QueryStatement
    {
        // ...
    }
}

يعني الـ property إلها قيمة جاهزة، وبتضل readonly وما بتتحول لشي قابل للتعديل. تغيير بسيط، بس بيخلي بعض الـ immutable objects والـ contracts أنظف بكتير.

اسمع مني و انتبه على هي النقاط لما بتشتغل بـ Laravel: ✅ استخدم $fillable كـ allowlist ✅ استخدم $request->validated() أو $request->only() ❌ تجنّب $request->all() مع create() و update() ❌ انتبه من $guarded = [] ❌ لا تستخدم forceFill() مع User Input

🚨 Google أطلقت تحديث Spam جديد… وإذا عندك موقع، راقب الـ SEO هالأيام Google أعلنت رسمياً عن إطلاق August 2026 Spam Update بتاريخ 18 أغسطس. التحديث: • 🌍 عالمي ويشمل كل الدول • 🌐 يشمل جميع اللغات • 📊 ممكن يأثر بشكل مباشر على ترتيب المواقع في نتائج البحث • ⏳ طرحه رح يستغرق عدة أيام حتى يكتمل شو يعني هالشي لأصحاب المواقع؟ خلال الأيام الجاية ممكن تلاحظ تغييرات واضحة بالـ Rankings والـ Organic Traffic، سواء صعود أو نزول، بينما Google عم تعيد تقييم المواقع وفق أنظمة مكافحة الـ Spam. والـ Spam بالنسبة لـ Google مو شرط يكون موقع مليان إعلانات وروابط مزعجة فقط، وإنما ممكن يشمل أساليب هدفها التلاعب بنتائج البحث وتحسين الترتيب بشكل غير طبيعي. ⚠️ لذلك إذا لاحظت هبوط مفاجئ بالـ Traffic هالفترة، لا تبدأ مباشرة بتغييرات عشوائية على الموقع. الأفضل تراقب: Google Search Console → Performance → Search results وقارن الـ Impressions والـ Clicks والـ Average Position قبل وبعد 18 أغسطس. وبعد ما يكتمل الـ Rollout وتستقر النتائج، وقتها بيكون تقييم تأثير التحديث على موقعك أدق.

🔐 إذا عم تستخدم Cloudflare، لا تترك الـ VPS مكشوف مباشرة للإنترنت خطوة بسيطة ومفيدة بالحماية هي إنك تمنع الوصول المباشر للـ HTTP/HTTPS على السيرفر، وتسمح به فقط من IP Ranges الخاصة بـ Cloudflare. بهالطريقة أي طلب مباشر على الـ Origin IP بينرفض، والترافيك لازم يمر أولاً عبر Cloudflare. الفائدة؟ تقليل الـ direct traffic على السيرفر توفير bandwidth غير ضروري منع تجاوز Cloudflare والوصول المباشر للـ Origin الاستفادة بشكل أفضل من WAF وRate Limiting والحماية الموجودة على Cloudflare لكن في نقطة مهمة 👇 السماح لـ Cloudflare IPs فقط مو Authentication حقيقي للطلبات، لذلك للحماية الأقوى فينا نستخدم Authenticated Origin Pulls (AOP). مع AOP السيرفر ما بيكتفي بأن الاتصال جاي من شبكة Cloudflare، وإنما بيتحقق كمان من شهادة TLS مقدمة من Cloudflare قبل ما يقبل الاتصال. الأفضل عملياً: Firewall → اسمح فقط لـ Cloudflare IPs على 80/443 + Authenticated Origin Pulls → تأكد أن الطلب فعلاً جاي عبر Cloudflare هيك الـ Origin Server بيصير أصعب بكثير للوصول إله مباشرة، وCloudflare بيكون فعلياً البوابة بين الإنترنت والسيرفر. 🔒

📢 Anthropic تمدّد زيادة حدود استخدام Claude Code بنسبة 50% أعلنت Anthropic عن تمديد الزيادة المؤقتة على حدود الاستخدام الأسبوعية لـ Claude Code بنسبة 50% لغاية 31 آب. الشركة قالت إنها بتأمل تخلي هالزيادة دائمة ضمن الخطط، لكن بسبب الطلب الكبير على نماذج Claude، ممكن نشوف بعض القيود على السعة خلال الأسابيع الجاية. يعني باختصار: مستخدمي Claude Code رح يضل عندهم 50% استخدام أسبوعي إضافي لنهاية الشهر. 🚀

أصدقائي المهتمين بتدريب لارافيل المتقدم في اكاديمية focal x و اللي لربما الموضوع المادي او تكاليف التدريب هيي عائق بالنسبة الكم لا تترددوا بالتواصل مع الشركة من خلال الواتس اب عالرقم التالي: 00963953666052 عند تواصلكم مع الشركة سيتم تزويدكم بملف يحتوي على كافة التفاصيل.

خلف كل تطبيق يوجد عالم سري من الأكواد. هذا هو عالم الـ Back-end! لتتعلم كيف تبنيه بنفسك وتتحكم بالبيانات، وتضمن السرعة والأمان.🧡💪 انضم الآن لتدريب دفعة V.11 في اختصاص: تطوير المواقع Back-end | مبتدئ + متقدم🧡 التدريب أونلاين ومُتاح لكل الدول، مع توافر ميزة التقسيط. 🔸 محاور التدريب | مستوى مبتدئ: 1. فهم آلية عمل الويب والمصطلحات في المجال: - التعرف على كيفية تفاعل المستخدم مع التطبيقات من خلال الخوادم والمتصفحات. 2. لغة PHP: - لغة برمجة نصية تُستخدم لبناء مواقع تفاعلية وديناميكية (قوية الأداء، متكاملة مع قواعد البيانات). 3. مفاهيم البرمجة الكائنية (OOP): - أسلوب برمجي يعتمد على الكائنات (Objects) لتنظيم الأكواد وزيادة قابليتها لإعادة الاستخدام وتحسين هيكلية المشروع وتقليل التكرار. 4. قاعدة بيانات MySQL: - نظام إدارة قواعد بيانات علائقية شائع الاستخدام. 5. نظام التحكم بالإصدارات Git: - أداة لإدارة أكواد المصدر وتتبع التعديلات عليها لتسهيل التعاون بين الفرق وحفظ تاريخ التعديلات. 6. إطار العمل Laravel: - إطار عمل PHP متكامل ومفتوح المصدر لتطوير تطبيقات ويب ديناميكية. - أدوات مدمجة مثل التحقق من البيانات، التوجيه (Routing)، والترحيلات (Migrations). 7. نمط MVC: - نموذج تصميم لتحسين تنظيم الأكواد وسهولة الصيانة، يقسّم التطبيق إلى ثلاثة أقسام: - ا Model للتعامل مع البيانات. - ا View لعرض واجهة المستخدم. -ا Controller: لتنظيم التفاعل بين البيانات والواجهة. 8. أدوات إدارة قواعد البيانات والتحقق من صحة البيانات: -ا Migration: إنشاء الجداول وتعديلها بمرونة. -ا Validation: التحقق من صحة المدخلات والتأكد من مطابقتها للقواعد. -ا Request: التعامل مع البيانات الواردة من المستخدم بطرق منظمة. 9. التحكم في الوصول والصلاحيات: -ا Authentication: بناء نظام لتسجيل الدخول والخروج. -ا Middleware: تنفيذ مهام إضافية مثل حماية الصفحات بناءً على الصلاحيات. 10. واجهة برمجة التطبيقات (API): - وسيلة لتمكين التطبيقات من التواصل مع بعضها عبر إرسال واستقبال البيانات، تكمن أهميها في: - التكامل: ربط الأنظمة المختلفة مثل بوابات الدفع. - إعادة الاستخدام: بناء خدمات مشتركة للتطبيقات المختلفة. - المرونة: سهولة توسيع التطبيقات دون تعديل كبير. 11. مقدمة حول أساسيات Front-End: - فهم العناصر الأساسية لدمج الواجهة الأمامية مع الخلفية (HTML، CSS، JavaScript). 🔸 شهادات التدريب: مناهجنا الأكاديمية تحت إشراف المنظمة الأوربية لإدارة الجودة بالإضافة لشهادات مهنية من المعهد الامريكي المهني. وشهادات خبرة من شركة فوكال اكس. 🔸 للتسجيل ومعرفة المزيد من التفاصيل: - التواصل حصراً عبر تطبيق واتس آب على الرقم: 00963953666052 وسيرسل لك فريق التدريب ملفاً يحتوي على كل التفاصيل، الدفعات، المحاور، الأوقات، المدربين، وأعمال المتدربين. بالإضافة لمحاور التدريب المتقدم في الـ Back-end 🔸 التدريب أونلاين ومُتاح لكل الدول، يتم تسجيل جميع الجلسات للمراجعة. 🔸أوقات مسائية مناسبة للأفراد (طلاب وموظفين) والشركات. 🔸 أوقات الدوام الرسمية للاستفسار: من السبت حتى الخميس 🔸 يغلق باب التسجيل في نهاية الشهر الثامن لا تتردد، احجز الآن، المقاعد محدودة 🧡

لما Request بتصير أبطأ من الطبيعي، أول شي ممكن يخطر ببالك هو الـ code. بس بكتير حالات المشكلة بتكون أبسط وأوضح: Queries عم تتكرر بدون داعي N+1 Queries عم تجيب columns أو records أكتر من المطلوب Dataset كبيرة عم تتحمل دفعة وحدة لهيك أول خطوة لازم تكون Measurement مو التخمين. مثلاً في Laravel فيك تراقب الـ Queries: DB::enableQueryLog(); $queries = DB::getQueryLog(); وكمان Laravel Debugbar مفيد جداً بالـ development حتى تشوف عدد الـ Queries ووقت تنفيذها. من أشهر المشاكل هي N+1 Query Problem. بدل ما تجيب Users وبعدين تعمل Query لكل User حتى تجيب Orders: $users = User::with('orders')->get(); استخدم Eager Loading وخفف عدد الـ Queries. نفس الشي بالنسبة للداتا نفسها. إذا محتاج id و name فقط: $users = User::select('id', 'name')->get(); وإذا عندك آلاف records، لا تحملهم كلهم: ``` $users = User::paginate(25); ``` بالجزء الجاي: رح احكيلكم كيف منعرف إذا الـ Query نفسها بطيئة، وشو دور Indexes و EXPLAIN بالموضوع.

يمكن تكون عم تستخدم SOLID بـ Laravel بدون ما تنتبه. 👀 Laravel نفسه بيعطيك Tools بتساعدك تبني Architecture أنظف. مثلاً: Dependency Injection بدل ما تعمل new لكل Dependency، Laravel بيقدر Inject dependencies إلك. Service Container بتقدر تربط Interface مع Implementation. Form Requests بتطلع Validation من الـ Controller. Policies بتفصل Authorization logic. Events & Listeners بتضيف Reactions جديدة على Event بدون ما تحشر كل شي بمكان واحد. Jobs & Queues بتفصل الـ background work عن الـ request lifecycle. بس انتبه: استخدام Laravel ما بيعني تلقائياً إن مشروعك SOLID. 😅 ممكن تستخدم Service Container ويضل عندك OrderService فيه 3000 سطر. وممكن تعمل 40 Interface بدون أي داعي ويصير المشروع أعقد. Framework بيعطيك الأدوات، بس الـ Architecture بالنهاية مسؤوليتك. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

هاد المبدأ رح تشوفه كتير بـ Laravel: D — Dependency Inversion Principle (DIP) تخيل: OrderService جواته: new StripePayment() هيك OrderService صار مربوط مباشرة بـ Stripe. إذا بكرا بدك PayPal، أو بدك تعمل Fake Payment Gateway بالـ Tests، رح تبلش المشاكل. الأفضل يكون: OrderService يعتمد على: PaymentGateway مو على: StripePayment وبعدين Laravel Service Container بيحدد مين الـ implementation: PaymentGateway → StripePayment وببيئة أو حالة تانية ممكن يصير: PaymentGateway → PaypalPayment والـ OrderService نفسه ما تغير عليه شي. هون الفرق المهم: ❌ Depend on concrete implementation ✅ Depend on abstraction وهاد واحد من الأسباب يلي بيخلي Dependency Injection + Service Container مهمين جداً بـ Laravel. مو بس لأن شكل الـ code أحلى. لأنهم بيساعدوك تفصل الـ Business Logic عن تفاصيل الـ implementation. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

مو كل Interface كبير هو Interface منيح. هون بيجي المبدأ الرابع: I — Interface Segregation Principle (ISP) تخيل عندك: WorkerInterface وفيه: work() eat() sleep() بالنسبة لـ Human Worker ممكن تمشي. بس بعدين بدك تعمل: Robot implements WorkerInterface صار لازم الـ Robot يعمل implementation لـ: eat() 🤨 sleep() 🤨 مع إنه ما بيحتاجهم أصلاً. المشكلة إن الـ Interface عم يجبر الـ Class يعتمد على Methods ما إله علاقة فيها. الأفضل نقسمه: Workable Eatable Sleepable فالـ Human ممكن يطبق التلاتة. والـ Robot يطبق: Workable وبس. ISP باختصار: بدل Interface ضخم بيحاول يخدم الجميع، اعمل Interfaces صغيرة ومركزة. الـ Class لازم يعتمد فقط على الـ Contract يلي فعلاً محتاجه. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

نزل Laravel 13.25 — تحديث صغير بالرقم، بس فيه شغلات مهمة للـ Production نزل Laravel 13.25 بتاريخ 11 آب، وفيه مجموعة Updates حلوة، أكتر شي لفتني منها متعلق بالـ Queues أول وأهم إضافة: صار فينا نوقف كل الـ Queues دفعة وحدة: php artisan queue:pause --all ونرجع نشغلهم: php artisan queue:resume --all قبل هالتحديث، إذا عندك أكتر من Queue موزعة على Workers مختلفة، كنت بحاجة تتعامل معها بشكل منفصل. هلق صار في Global Pause بيوقف الـ Workers عن حجز Jobs جديدة بدون ما تضطر توقف التطبيق كله. والموضوع مو مجرد Artisan Commands، صار متوفر برمجياً كمان: Queue::pauseAll(); Queue::resumeAll(); والأحلى إن الـ Global Pause مستقل عن الـ Queues اللي موقفها يدوياً. يعني resumeAll() ما رح يشغّل Queue كنت موقفها بشكل منفصل قبل الـ Deployment. ⸻ artisan dev كمان تغير بشكل كبير الـ Laravel كان يستخدم concurrently لتشغيل عدة Processes بنفس الوقت. المشكلة؟ الـ Vite عم يكتب Logs، والـ Queue Worker عم يكتب Logs، وPail عم يكتب Logs… وكلهم بنفس الـ Terminal 😅 من Laravel 13.25 صار artisan dev يستخدم @laravel/multiplex. صار عندك Terminal UI فيها: • Tabs لكل Process • Search بالـ Logs • Restart لكل Process بشكل منفصل • Clear Logs • Auto Restart إذا Process وقعت وفي 3 Modes: tabs stream inline ⸻ كمان صار التعامل مع Images أبسط. Image صار implements Responsable، يعني صار فيك ترجع الصورة مباشرة من الـ Route: return Image::fromStorage(...)->cover(200, 200)->toWebp()->quality(80); وانضاف: Image::fromStream() وصارت: toFormat() Public. ⸻ وفي Updates أصغر بس مهمة: 🔹 UniqueJobSkipped event للـ ShouldBeUnique Jobs. 🔹 JobTimedOut صار يحتوي قيمة الـ timeout اللي تم تجاوزها. 🔹 دعم #[FailOnTimeout] للـ queued Notifications. 🔹 withoutCookies() لحذف أكتر من Cookie. 🔹 foreignUlidFor() للـ Migrations. 🔹 تعديل Request::all() بحيث الـ Input ياخد الأولوية على File إذا كان عندهم نفس الـ Key. ⸻ بس بالنسبة إلي، أكتر Update مثير للاهتمام هو Global Queue Pause. لأنه بيحل مشكلة ما بتحس فيها أصلاً وأنت عم تطور التطبيق Local. بتبلش أهميته لما يصير عندك: Production Server + Redis + Multiple Queues + Workers + Deployments وساعتها بتكتشف إن معرفة Laravel لحالها جزء من الصورة فقط. كيف الـ Worker شغال؟ مين عم يديره؟ شو بصير فيه أثناء الـ Deployment؟ كيف منعمل Restart بدون ما نخسر Jobs؟ وين Redis داخل بالقصة؟ وكيف كل هالـ Processes عايشة أصلاً على الـ Server؟ هاي تحديداً نوعية التفاصيل اللي بحب ركز عليها لما نحكي عن DevOps للمطورين، وهي من المواضيع اللي رح نشوفها عملياً ضمن DevOps Fundamentals Bootcamp لما نبني ونشغّل Laravel Production Environment حقيقية. لأن أسهل شي نكتب: php artisan queue:work بس السؤال الأهم: مين رح يضل مشغّله بالـ Production؟