Code With Somar
описание
🚀 ريادي أعمال ومطوّر ويب بخبرة واسعة 💻 متخصص بتطوير حلول ويب متكاملة باستخدام Laravel، Django، React، Vue، و Node.js. 🏆 ضمن أفضل 4 صناع محتوى في سوريا وأفضل 3 في المحتوى التقني. 🌟 ناشط في مجتمع برمجة الأطفال، ومساهم في تطوير المحتوى التقني عربياً.
2 715
подписчиков
Охват к подписчикам
18,9%
ERR
Реакции к просмотрам
1,17%
273 на 34 постов
Пересылки к просмотрам
0,53%
125
Постов в день
1,1
всего 35
Где отзываются чаще
доля реакций к просмотрам- 14 авг.يمكن تكون عم تستخدم 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال3,53%
- 14 апр. 2025 г.без подписи3,48%
- 14 авг.هاد المبدأ رح تشوفه كتير بـ 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال3,42%
- 9 авг.أول مبدأ من 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,38%
- 12 авг.يمكن أكتر 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال2,83%
- 13 авг.مو كل 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال2,68%
- 9 авг.إذا مشروعك بالبداية كان مرتب وسهل، وبعد كم شهر صار أي تعديل صغير بيكسر 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال2,56%
- 13 февр. 2025 г.без подписи2,52%
- 10 авг.تخيل عندك 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال2,44%
- 12 авг.🐳 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… لازم بالأول تعرف كيف تبني وتشغّل وتدير وحدة بشكل صح. 🚀 ⚠️ متبقي مقعدان فقط لإغلاق التسجيل.2,41%
- 8 авг.🐘 ليش عم ينحكى عن PostgreSQL كثير مع الـ AI؟ لما نضيف AI لمشروع، ممكن نفكر مباشرة إننا بحاجة لأدوات وقواعد بيانات جديدة. بس PostgreSQL صار قادر يعمل جزء كبير من هالشغل لحاله. مثلاً 👇 تخيل عندك متجر فيه آلاف المنتجات، والمستخدم كتب: “بدي لابتوب خفيف ومناسب للبرمجة وسعره مو غالي” البحث العادي غالباً بيدور على نفس الكلمات الموجودة بالنص. أما مع AI Search، البحث ممكن يفهم المعنى ويجيب منتجات مناسبة حتى لو وصف المنتج ما فيه نفس الكلمات تماماً. وهون بيجي دور pgvector، وهي إضافة لـ PostgreSQL بتسمح نخزن معلومات تساعدنا نعمل هالنوع من البحث الذكي. بدل ما يكون عندك: Database للمنتجات والطلبات Database ثانية للـ AI Search ممكن بالبداية تستخدم PostgreSQL للاثنين. وكمان إذا عندك AI Agent، مثلاً Agent لخدمة العملاء، فيك تحدد شو مسموحله يشوف ويعمل: يشوف الطلبات ✅ يشوف حالة الشحن ✅ يعدل أسعار المنتجات ❌ يحذف طلبات ❌ يعني PostgreSQL ممكن يكون جزء مهم من النظام اللي الـAI عم يتعامل معه.1,86%
- 11 авг.SQL Interview Question: شو بتعمل هي الكويري؟ A) الموظف صاحب أعلى راتب فقط B) الموظفون الذين رواتبهم أعلى من متوسط الرواتب C) الموظفون الذين لديهم نفس الراتب D) جميع الموظفين شاركنا رايك بالتعليقات 👇1,68%