Code With Somar

يمكن تكون عم تستخدم 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؟

يمكن أكتر Principle اسمه بخوف بالبداية 😂 L — Liskov Substitution Principle (LSP) بس فكرته أبسط من الاسم بكتير: إذا عندك Parent Type، لازم تقدر تستبدله بأي Subtype منه بدون ما يتغير السلوك المتوقع أو ينكسر البرنامج. المثال الشهير: عندك: Bird وفيه: fly() بعدين: Sparrow extends Bird ✅ بس شو منعمل مع: Penguin extends Bird؟ 🐧 الـ Penguin هو Bird فعلاً… بس ما بيطير. إذا اضطرينا نخلي Penguin::fly() يرمي Exception أو يعمل شي غير منطقي، فالمشكلة مو بالـ Penguin. المشكلة بالـ abstraction نفسه. ممكن يكون التصميم الأفضل: Bird وعنا Interface منفصل: Flyable فالـ Sparrow: Sparrow implements Flyable والـ Penguin بيضل Bird بدون ما نجبره يكون Flyable. الفكرة المهمة: Inheritance مو بس “X is a Y”. لازم كمان الـ subtype يحافظ على الـ Contract والسلوك المتوقع من الـ parent type. إذا الـ Child مجبور يكسر توقعات الـ Parent، راجع الـ design. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🐳 Docker ولا Kubernetes؟ وشو الفرق بيناتهم؟ من أكتر الأسئلة اللي بتتكرر عند أي حدا عم يفوت بعالم الـ DevOps: إذا تعلمت Docker، ليش بدي Kubernetes؟ وهل الاتنين بيعملوا نفس الشغلة؟ الجواب: لا، بس في علاقة قوية جداً بيناتهم. خلينا ناخد مثال بسيط 👇 تخيل عندك تطبيق فيه: Laravel Backend React Frontend MySQL Redis Queue Worker باستخدام Docker، فيك تحط كل Service ضمن Container خاص فيها، وتضمن إن التطبيق رح يشتغل تقريباً بنفس البيئة على جهازك، على جهاز زميلك، وعلى الـ Production Server. ومع Docker Compose فيك تعرّف وتشغّل كل هالـ Services مع بعض من ملف واحد. طيب وين بيجي Kubernetes؟ الموضوع بيبلش لما تكبر البنية التحتية. بدل ما يكون عندك Server واحد وعليه كم Container، تخيل صار عندك عشرات أو مئات الـ Containers موزعين على عدة Servers. هون بيطلع سؤال جديد: مين رح يدير كل هالـ Containers؟ إذا Container وقعت، مين بيرجع يشغلها؟ إذا زاد الـ Traffic، مين بيعمل Scaling؟ كيف منوزع الـ Traffic؟ كيف منعمل Deploy بدون ما نوقف الـ Service؟ وكيف مندير كل هالشي على أكتر من Server؟ هون بيجي دور Kubernetes. بشكل مبسط جداً: 🐳 Docker → Containerization ☸️ Kubernetes → Container Orchestration يعني Kubernetes مو بديل عن فكرة Docker، وإنما بيحل مشكلة أكبر: إدارة وتشغيل الـ Containers على نطاق واسع. والنقطة المهمة لأي حدا عم يتعلم DevOps: ❌ لا تبدأ بـ Kubernetes لأن اسمه مطلوب بالـ Job Posts. إذا ما كنت فاهم منيح: Linux → Networking → Docker → Docker Compose → Nginx → Deployment → CI/CD رح تدخل بـ Kubernetes وتحفظ kubectl وملفات YAML بدون ما تفهم فعلياً المشكلة اللي Kubernetes إجت لتحلها. لهيك ضمن DevOps Fundamentals Bootcamp رح نركز على Docker وDocker Compose بشكل عملي، ورح نبني باستخدامهم Production Environment حقيقية فيها Laravel وReact وMySQL وRedis وQueue Workers وغيرها. Kubernetes مو ضمن محتوى هالدورة، والسبب مقصود: الهدف مو نحشي أكبر عدد ممكن من الأدوات ضمن Bootcamp واحد، الهدف إنك تطلع فاهم الأساس اللي لازم تكون متمكن منه قبل ما تنتقل للمرحلة التالية. لأن قبل ما تتعلم كيف تدير 100 Container… لازم بالأول تعرف كيف تبني وتشغّل وتدير وحدة بشكل صح. 🚀 ⚠️ متبقي مقعدان فقط لإغلاق التسجيل.

🚀 متبقي مقعدان فقط في DevOps Fundamentals Bootcamp إذا كنت مبرمج وترغب بالانتقال من مرحلة كتابة الكود إلى فهم كيفية تشغيل وإدارة التطبيقات ضمن بيئات Production حقيقية، فهذا الـ Bootcamp مصمم ليمنحك تجربة عملية متكاملة في عالم الـ DevOps. خلال التدريب سنتناول: ✅ Linux & Server Administration ✅ Docker & Containerization ✅ Docker Compose ✅ Nginx & Reverse Proxy ✅ GitLab CI/CD Pipelines ✅ Pipeline Optimization ✅ Production Deployments ✅ Troubleshooting ✅ DevOps Best Practices الـ Bootcamp لن يعتمد على الجانب النظري فقط، بل سنعمل بشكل عملي على بناء Production Environment متكاملة مشابهة للبيئات المستخدمة فعلياً في الشركات. بنهاية التدريب، ستكون قد بنيت بيئة تضم: • Laravel Backend • React Frontend • Docker • Nginx • MySQL • Redis • Queue Workers • Scheduler • Monitoring • GitLab CI/CD وسنعمل على دورة حياة التطبيق كاملة، بدءاً من تجهيز السيرفر وبناء الـ Containers، مروراً بإعداد الـ CI/CD Pipeline، وصولاً إلى الـ Deployment، Monitoring، Troubleshooting، Rollbacks وBackups. ماذا ستتمكن من القيام به بعد انتهاء الـ Bootcamp؟ ✔️ إدارة Linux Servers والتعامل معها بثقة. ✔️ بناء Docker Images وتجهيز Production Environments. ✔️ إعداد Nginx وتشغيل تطبيقات Laravel وReact. ✔️ بناء وتحسين GitLab CI/CD Pipelines. ✔️ تنفيذ Deployments وRollbacks وإدارة Backups. ✔️ مراقبة التطبيقات وتشخيص المشاكل والأعطال. ✔️ فهم الرحلة الكاملة للتطبيق من الكود وحتى تشغيله في Production. 📅 موعد البداية: الشهر القادم 🌙 المواعيد: جلسات مسائية تبدأ بعد الساعة 7:00 مساءً 💻 التدريب: Online 🎥 جميع الجلسات مسجلة ويمكن الرجوع إليها في أي وقت. ⚠️ متبقي مقعدان فقط لإغلاق التسجيل. للحجز أو الاستفسار، يمكنكم التواصل معي عبر Instagram: 📩 @code.with.somar إذا كنت ترغب ببناء خبرة DevOps عملية، وليس فقط معرفة مجموعة من الأدوات، أهلاً وسهلاً بك في الـ Bootcamp.

SQL Interview Question: شو بتعمل هي الكويري؟ A) الموظف صاحب أعلى راتب فقط B) الموظفون الذين رواتبهم أعلى من متوسط الرواتب C) الموظفون الذين لديهم نفس الراتب D) جميع الموظفين شاركنا رايك بالتعليقات 👇

تخيل عندك E-Commerce وبتدعم Stripe. بتكتب: PaymentService وبعدين الشركة بتطلب PayPal. بتضيف: if ($provider === 'paypal') بعد فترة بدهم Apple Pay. بتضيف if جديد. بعدين Provider رابع وخامس… وفجأة PaymentService صار عبارة عن مهرجان if / else. 😂 هون بيجي: O — Open/Closed Principle (OCP) الفكرة: Open for extension, closed for modification. يعني لما بدك تضيف Behavior جديد، قدر الإمكان تضيف implementation جديد بدل ما ترجع تعدل بالـ core logic كل مرة. مثلاً: PaymentGateway Interface وعندك: StripePayment implements PaymentGateway PaypalPayment implements PaymentGateway ApplePayPayment implements PaymentGateway الـ Checkout ما بهمّه مين Provider الموجود. هو بيتعامل مع: PaymentGateway بدك تضيف Provider جديد؟ اعمل Class جديد بيطبق نفس الـ Contract. بدل ما تعدل Checkout بكل مرة. OCP مو معناه “ممنوع تعدل الـ code”. معناه صمم الأماكن يلي بتتوقع تتوسع بحيث إضافة Behavior جديد ما تجبرك تفكك وتعدل الـ existing logic كل مرة. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

أول مبدأ من SOLID: S — Single Responsibility Principle (SRP) فكرته: A class should have only one reason to change. يعني الـ Class ما لازم يكون مسؤول عن كل شي. مثلاً عندك: UserService وعم يعمل: Create User Send Welcome Email Upload Profile Image Generate PDF Send Notification هون UserService صار عنده أكتر من سبب ليتغير. تغير Email Provider؟ بدك تعدله. تغير PDF generation؟ بدك تعدله. تغير طريقة رفع الصور؟ كمان بدك تعدله. الأفضل نفصل المسؤوليات: UserService → User logic EmailService → Emails ImageService → Images ReportService → Reports NotificationService → Notifications ونفس الفكرة بـ Laravel Controller. ❌ مو المفروض الـ Controller يعمل Validation + Business Logic + DB Queries + Emails + Notifications. خليه يستقبل الـ Request ويوجه العملية للمكان المسؤول عنها. SRP باختصار: إذا الـ Class عنده 5 أسباب مختلفة ليتغير، غالباً عنده 5 Responsibilities لازم تفكر تفصلهم. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

إذا مشروعك بالبداية كان مرتب وسهل، وبعد كم شهر صار أي تعديل صغير بيكسر 3 شغلات تانية… غالباً المشكلة مو بحجم المشروع، المشكلة بطريقة تنظيم الـ code. 😅 هون بيجي دور SOLID Principles. SOLID هي 5 مبادئ بالـ Object-Oriented Design: S — Single Responsibility Principle O — Open/Closed Principle L — Liskov Substitution Principle I — Interface Segregation Principle D — Dependency Inversion Principle الهدف منها مو إنك تكتب code “أكاديمي” أو تعمل Architecture معقدة. الهدف أبسط: تكتب code يكون: أسهل بالتعديل أسهل بالـ Testing أقل Coupling أسهل بالتوسعة ومفهوم أكتر لأي Developer بيجي بعدك بالمنشورات الجاية رح ناخد كل Principle لحاله مع أمثلة PHP و Laravel. 👨‍💻 ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

سؤال دسم هالمرة: زمن الـ Response عم يطلع كل يوم من 35ms إلى 2.8 ثانية في تمام الساعة 2:47 ظهراً لا يوجد أي Deployment. لا توجد زيادة في الـ Traffic. لا توجد تغييرات على قاعدة البيانات. شو الخطوات اللي رح تعملها لتعرف السبب

🐘 ليش عم ينحكى عن PostgreSQL كثير مع الـ AI؟ لما نضيف AI لمشروع، ممكن نفكر مباشرة إننا بحاجة لأدوات وقواعد بيانات جديدة. بس PostgreSQL صار قادر يعمل جزء كبير من هالشغل لحاله. مثلاً 👇 تخيل عندك متجر فيه آلاف المنتجات، والمستخدم كتب: “بدي لابتوب خفيف ومناسب للبرمجة وسعره مو غالي” البحث العادي غالباً بيدور على نفس الكلمات الموجودة بالنص. أما مع AI Search، البحث ممكن يفهم المعنى ويجيب منتجات مناسبة حتى لو وصف المنتج ما فيه نفس الكلمات تماماً. وهون بيجي دور pgvector، وهي إضافة لـ PostgreSQL بتسمح نخزن معلومات تساعدنا نعمل هالنوع من البحث الذكي. بدل ما يكون عندك: Database للمنتجات والطلبات Database ثانية للـ AI Search ممكن بالبداية تستخدم PostgreSQL للاثنين. وكمان إذا عندك AI Agent، مثلاً Agent لخدمة العملاء، فيك تحدد شو مسموحله يشوف ويعمل: يشوف الطلبات ✅ يشوف حالة الشحن ✅ يعدل أسعار المنتجات ❌ يحذف طلبات ❌ يعني PostgreSQL ممكن يكون جزء مهم من النظام اللي الـAI عم يتعامل معه.

اذا رح تعمل مقابلة و خصوصاً بمقابلات الـ backend developers اكيد رح تنسال هالسؤال: شو الفرق بين 401 Unauthorized vs 403 Forbidden

الكل بعلمك كيف تكتب كود سواءً laravel node reactjs او غيره بس مو الكل بعلمك كيف ترفعه صح عالسيرفر !! كم واحد تخرج من الجامعة او طلع من كورس وهو يعرف: كيف يعمل ssh على سيرفر؟ كيف يقرأ Logs عندما يتوقف الموقع؟ كيف يعمل Deploy بدون Downtime؟ كيف يبني Docker Image؟ كيف يكتب CI/CD Pipeline؟ كيف يكتشف سبب خطأ 502 Bad Gateway؟ كيف يرجّع المشروع إلى الإصدار السابق إذا فشل آخر Deploy؟ للأسف… أغلب المبرمجين بيطلعوا منها و هنن ممتازين في كتابة الكود، لكن أول مرة بيدخلوا فيها إلى سيرفر حقيقي بتكون بعد توظيفهم. و هون بتبدأ رحلة التعلم الحقيقية . هالسبب شركات كثيرة بتدور على مبرمج ما بس بيعرف يكتب الـ Features بس بيعرف كمان كيف التطبيق بيشتغل بعد ما يصير Production و هاد بالضبط هو الهدف من DevOps Fundamentals Bootcamp. مارح نتعلم كيف نكتب Laravel أو React… لكن رح نتعلم عن كل شي بصير بعد الانتهاء من كتابة الكود: من تشغيل التطبيق داخل Docker… إلى نشره باستخدام GitLab CI/CD… ومراقبته، وتشخيص أعطاله، وإدارته في بيئة Production حقيقية. 🚀 باب التسجيل الآن متاح الان و العدد محدود بـ ١٠ مقاعد فقط !!! لمعلومات اكثر عن الكورس و التسجيل بإمكانكم التواصل معي عبر: الرابط هنا

كتير بتسمع حكي انه الذكاء الاصطناعي رح يقضي على وظائف الـ DevOps متلها متل باقي الوظائف و للاسف هون في خطأ بقراءة الصورة الكبيرة الـ Vibe Coding رح يعبّي السوق بتطبيقات ناقصة، منتجات مستعجلة، ونماذج أولية معمولة عالسريع. الشركات صارت تطلق أسرع من أي وقت، لأن برومبت واحد ممكن يطلع كود خلال دقائق. بس إطلاق المنتج هو الجزء السهل لكن تشغيله على نطاق كبير؟ هون اللعبة بتكون. تابع قراءة المنشور من خلال الرابط: هنا

🚨 تنبيه لمستخدمي واتساب بيتا على أندرويد بحسب الأخبار المتداولة، إذا كنت مشترك بنسخة WhatsApp Beta 2.26.31.2 فمن الأفضل ما تحدّث للتحديث الحالي. في تقارير من المستخدمين بتقول إن التحديث فيه مشكلة بتمنع إرسال ملفات الوسائط مثل الصور والفيديوهات والمستندات، بينما الرسائل النصية بتشتغل بشكل طبيعي. المتوقع إنه واتساب يطرح تحديث جديد خلال وقت قريب لإصلاح المشكلة. إذا ما حدّثت لسا، الأفضل تنتظر النسخة اللي بعدها. أما إذا حدّثت وواجهت المشكلة، فغالباً الحل رح يكون مع التحديث القادم.

طالما المشروع يشتغل عندي، فهو جاهز يكون (Production) أكبر عبارة غلط ممكن تسمعها بشغلك بعالم البرمجة لان تشغيل المشروع على جهازك مستحيل يعني انه رح يشتغل على السيرفر او على جهاز زميلك بدون مشاكل اتخيل انه بعد الـ Deploy الموقع ما اشتغل !! بدك تفتح السيرفر و تبلش تدور و رح تلاحظ غالباً امور مثل: إصدار PHP على السيرفر هو 8.2، بينما أنت كنت تطور على 8.4. Extension مثل intl أو bcmath غير مثبتة. قاعدة البيانات على السيرفر إصدارها مختلف، وMigration لم تعد تعمل كما توقعت. ملف .env ناقص فيه متغير واحد فقط، لكن التطبيق كله توقف. مجلد storage لا يملك صلاحيات الكتابة. Queue Worker لم يتم تشغيلها أصلًا، لذلك الطلبات والإشعارات لا تصل. بعد آخر تعديل نسيت تنفيذ php artisan config:cache أو العكس، وبقيت إعدادات قديمة تعمل. لهاد السبب صارت ادوات متل Linux وDocker وNginx وCI/CD أساسية لاي مبرمج لانها بتوفر عالشركة وقت و مشاكل كتير —————————————- اذا حابب تعرف اكتر عن مجال الـ DevOps و تتعلم عنه التسجيل حالياً متاح على DevOps Fundamentals Bootcamp ليعطيك الفرصة تتعلم و تشتغل بايدك على هي التقنيات لمعلومات اكثر عن الكورس و التسجيل بإمكانكم التواصل معي عبر: الرابط هنا