Code With Somar
Открыть в Telegram
🚀 ريادي أعمال ومطوّر ويب بخبرة واسعة 💻 متخصص بتطوير حلول ويب متكاملة باستخدام Laravel، Django، React، Vue، و Node.js. 🏆 ضمن أفضل 4 صناع محتوى في سوريا وأفضل 3 في المحتوى التقني. 🌟 ناشط في مجتمع برمجة الأطفال، ومساهم في تطوير المحتوى التقني عربياً.
Больше2 733
Подписчики
-224 часа
+177 дней
+1830 день
Загрузка данных...
Похожие каналы
Облако тегов
Входящие и исходящие упоминания
---
---
---
---
---
---
Привлечение подписчиков
август '26
август '26
+67
в 1 каналах
июль '26
+62
в 2 каналах
Get PRO
июнь '26
+34
в 1 каналах
Get PRO
май '26
+28
в 1 каналах
Get PRO
апрель '26
+28
в 1 каналах
Get PRO
март '26
+27
в 1 каналах
Get PRO
февраль '26
+37
в 0 каналах
Get PRO
январь '26
+32
в 0 каналах
Get PRO
декабрь '25
+38
в 0 каналах
Get PRO
ноябрь '25
+76
в 1 каналах
Get PRO
октябрь '25
+61
в 1 каналах
Get PRO
сентябрь '25
+91
в 1 каналах
Get PRO
август '25
+67
в 0 каналах
Get PRO
июль '25
+75
в 1 каналах
Get PRO
июнь '25
+45
в 1 каналах
Get PRO
май '25
+91
в 1 каналах
Get PRO
апрель '25
+108
в 3 каналах
Get PRO
март '25
+89
в 3 каналах
Get PRO
февраль '25
+172
в 5 каналах
Get PRO
январь '25
+110
в 2 каналах
Get PRO
декабрь '24
+45
в 1 каналах
Get PRO
ноябрь '24
+141
в 1 каналах
Get PRO
октябрь '24
+339
в 3 каналах
Get PRO
сентябрь '24
+183
в 0 каналах
Get PRO
август '24
+205
в 0 каналах
Get PRO
июль '24
+135
в 1 каналах
Get PRO
июнь '24
+173
в 2 каналах
Get PRO
май '24
+58
в 0 каналах
Get PRO
апрель '24
+62
в 0 каналах
Get PRO
март '24
+115
в 0 каналах
Get PRO
февраль '24
+322
в 1 каналах
Get PRO
январь '24
+128
в 4 каналах
Get PRO
декабрь '23
+90
в 0 каналах
Get PRO
ноябрь '23
+134
в 3 каналах
Get PRO
октябрь '23
+11
в 0 каналах
Get PRO
сентябрь '23
+8
в 0 каналах
Get PRO
август '23
+11
в 0 каналах
Get PRO
июль '23
+9
в 0 каналах
Get PRO
июнь '23
+7
в 0 каналах
Get PRO
май '23
+21
в 0 каналах
Get PRO
апрель '23
+6
в 0 каналах
Get PRO
март '23
+4
в 0 каналах
Get PRO
февраль '23
+24
в 0 каналах
Get PRO
январь '23
+258
в 0 каналах
| Дата | Привлечение подписчиков | Упоминания | Каналы | |
| 26 августа | +2 | |||
| 25 августа | +1 | |||
| 24 августа | +2 | |||
| 23 августа | +5 | |||
| 22 августа | +3 | |||
| 21 августа | +7 | |||
| 20 августа | +3 | |||
| 19 августа | +4 | |||
| 18 августа | +3 | |||
| 17 августа | +2 | |||
| 16 августа | +1 | |||
| 15 августа | +2 | |||
| 14 августа | +1 | |||
| 13 августа | +2 | |||
| 12 августа | +1 | |||
| 11 августа | +2 | |||
| 10 августа | +1 | |||
| 09 августа | +2 | |||
| 08 августа | +1 | |||
| 07 августа | +3 | |||
| 06 августа | +1 | |||
| 05 августа | +2 | |||
| 04 августа | +1 | |||
| 03 августа | +12 | |||
| 02 августа | +2 | |||
| 01 августа | +1 |
Посты канала
بتعرف انه قبل 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 أنظف بكتير.| 2 | اسمع مني و انتبه على هي النقاط لما بتشتغل بـ Laravel:
✅ استخدم $fillable كـ allowlist
✅ استخدم $request->validated() أو $request->only()
❌ تجنّب $request->all() مع create() و update()
❌ انتبه من $guarded = []
❌ لا تستخدم forceFill() مع User Input | 198 |
| 3 | 🚨 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 وتستقر النتائج، وقتها بيكون تقييم تأثير التحديث على موقعك أدق. | 323 |
| 4 | 🔐 إذا عم تستخدم 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 بيكون فعلياً البوابة بين الإنترنت والسيرفر. 🔒 | 291 |
| 5 | 📢 Anthropic تمدّد زيادة حدود استخدام Claude Code بنسبة 50%
أعلنت Anthropic عن تمديد الزيادة المؤقتة على حدود الاستخدام الأسبوعية لـ Claude Code بنسبة 50% لغاية 31 آب.
الشركة قالت إنها بتأمل تخلي هالزيادة دائمة ضمن الخطط، لكن بسبب الطلب الكبير على نماذج Claude، ممكن نشوف بعض القيود على السعة خلال الأسابيع الجاية.
يعني باختصار: مستخدمي Claude Code رح يضل عندهم 50% استخدام أسبوعي إضافي لنهاية الشهر. 🚀 | 367 |
| 6 | أصدقائي المهتمين بتدريب لارافيل المتقدم في اكاديمية focal x و اللي لربما الموضوع المادي او تكاليف التدريب هيي عائق بالنسبة الكم
لا تترددوا بالتواصل مع الشركة من خلال الواتس اب عالرقم التالي:
00963953666052
عند تواصلكم مع الشركة سيتم تزويدكم بملف يحتوي على كافة التفاصيل. | 395 |
| 7 | Нет текста... | 413 |
| 8 | خلف كل تطبيق يوجد عالم سري من الأكواد.
هذا هو عالم الـ 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
🔸 التدريب أونلاين ومُتاح لكل الدول،
يتم تسجيل جميع الجلسات للمراجعة.
🔸أوقات مسائية مناسبة للأفراد (طلاب وموظفين) والشركات.
🔸 أوقات الدوام الرسمية للاستفسار:
من السبت حتى الخميس
🔸 يغلق باب التسجيل في نهاية الشهر الثامن
لا تتردد، احجز الآن، المقاعد محدودة 🧡 | 382 |
| 9 | لما 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 بالموضوع. | 396 |
| 10 | يمكن تكون عم تستخدم 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال | 531 |
| 11 | هاد المبدأ رح تشوفه كتير بـ 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال | 535 |
| 12 | مو كل 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال | 497 |
| 13 | نزل 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؟ | 438 |
| 14 | يمكن أكتر 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال | 406 |
| 15 | 🐳 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…
لازم بالأول تعرف كيف تبني وتشغّل وتدير وحدة بشكل صح. 🚀
⚠️ متبقي مقعدان فقط لإغلاق التسجيل. | 506 |
| 16 | 🚀 متبقي مقعدان فقط في 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. | 576 |
| 17 | SQL Interview Question:
شو بتعمل هي الكويري؟
A) الموظف صاحب أعلى راتب فقط
B) الموظفون الذين رواتبهم أعلى من متوسط الرواتب
C) الموظفون الذين لديهم نفس الراتب
D) جميع الموظفين
شاركنا رايك بالتعليقات 👇 | 566 |
| 18 | Нет текста... | 571 |
| 19 | تخيل عندك 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال | 617 |
| 20 | أول مبدأ من 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال | 614 |
