Code With Somar

🧯 من مشاكل الـ Production #2 كيف صورة واحدة ممكن تعمل OOM وتضرب تطبيقك؟ عندك صورة حجمها على السيرفر: 500 KB بتقول: ممتاز، خفيفة جداً. بس حجم الملف مو هو نفسه حجم الصورة بالـ Memory. مثلاً صورة أبعادها: 4000 × 3000 لما التطبيق يفك ضغطها حتى يعرضها، ممكن تحتاج تقريباً: 4000 × 3000 × 4 bytes يعني حوالي: 48 MB بالـ RAM 😅 طيب تخيل عندك Product Grid فيه 10 صور مشابهة… نظرياً ممكن توصل لمئات الـ MB من الـ Memory. وهون ممكن يظهر: Out Of Memory (OOM) والتطبيق يضرب 💥 المشكلة إن المطور ممكن يروح يضغط الصور أكثر: 500 KB → 200 KB لكن الصورة لسا أبعادها: 4000 × 3000 يعني خففت الـ Network Size… بس بعد فك الصورة، استهلاك الـ Memory ممكن يضل ضخم. 📌 File Size ≠ Decoded Image Size إذا الصورة رح تنعرض داخل Card بحجم صغير، ما في سبب تفك صورة بدقة 4K كاملة بالـ Memory. بـ Flutter مثلاً، لازم تنتبه لأشياء مثل: cacheWidth cacheHeight وكمان الأفضل يكون عندك Image CDN يولد أحجام مناسبة حسب مكان عرض الصورة. الصورة اللي بالـ Product Card مو لازم تكون نفس الصورة اللي بالـ Product Details. أحياناً مشكلة الـ OOM مو Memory Leak… أحياناً أنت بكل بساطة عم تطلب من الموبايل يفك صور أكبر بكتير من اللي الشاشة محتاجتها. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

✅ UPDATE: Telegram's t.me Domain Has Been Restored

🧯 من مشاكل الـ Production #1 إذا اشتغلت Flutter، غالباً مرقت عليك هالمشكلة: عندك ListView أو GridView داخل SingleChildScrollView. Flutter بيعطيك مشكلة بالـ layout… فبتضيف: shrinkWrap: true و: NeverScrollableScrollPhysics() المشكلة بتنحل ✅ بس ممكن تكون خلقت مشكلة أكبر بدون ما تنتبه. الـ ListView بطبيعته Lazy. يعني إذا عندك 500 منتج، Flutter ما بيبني الـ 500 كلهم مباشرة. بيبني العناصر اللي ظاهرة عالشاشة، والعناصر القريبة منها. لكن لما تستخدم shrinkWrap: true، الـ List لازم تعرف حجمها الكامل حتى تحدد ارتفاعها. يعني Flutter ممكن يضطر يعمل Build و Layout لعدد ضخم من العناصر من البداية. 500 Product Cards؟ صور، أسعار، Discounts، Badges، Widgets… كلهم ممكن يدخلوا بعملية الـ Layout قبل ما المستخدم يوصل لعندهم أصلاً. والنتيجة: 🐌 فتح الصفحة بطيء 🧊 Scroll Jank 📈 استهلاك Memory أعلى 🔥 ضغط أكبر على الـ CPU والغريب إن الكود بيكون “شغال”. ما في Crash. ما في Exception. بس المستخدم بيقلك: “التطبيق تقيل.” الحل الأفضل بالقوائم الطويلة؟ استخدم: CustomScrollView مع: SliverList أو: SliverGrid وخلي Flutter يبني العناصر وقت الحاجة. 📌 مو كل كود حل مشكلة Layout يعني إنه حل صحيح للـ Production. أحياناً shrinkWrap: true بيحل المشكلة اللي قدامك… وبيخلق مشكلة Performance ما رح تشوفها إلا عند المستخدم. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

إذا لاحظت إن روابط t.me ما عم تفتح، فالمشكلة مو من موبايلك ولا من الإنترنت عندك. المشكلة صارت على مستوى الـ Domain Registry نفسه 👀 نطاق t.me دخل بحالة اسمها serverHold. طيب شو يعني هالحكي؟ 🤔 ببساطة، لما تحط الـ Registry دومين بحالة serverHold، الدومين بينشال من الـ Global DNS Resolution. يعني لما تكتب: t.me/channel الـ DNS أساساً ما عاد قادر يوصلك للسيرفر المرتبط بـ t.me. والنتيجة؟ كل روابط t.me Short Links ممكن تتعطل حول العالم 🌍 المثير للاهتمام إن المشكلة مو بسبب إن Telegram نسي يجدد الدومين 😅 حسب بيانات WHOIS: الدومين معمول من سنة 2010، ومسجل عن طريق GoDaddy، وصلاحيته ممتدة لحد سنة 2035. كمان الـ Name Servers لسا موجودين وعم يشيروا لبنية Google: ns-cloud-b1 → ns-cloud-b4.googledomains.com يعني إعدادات الـ DNS Delegation موجودة. بس هون النقطة المهمة 👇 الـ Registry عنده صلاحية أعلى من الـ DNS Provider. يعني حتى لو سيرفراتك شغالة، والـ Name Servers صحيحة، والـ Domain مدفوع لـ 9 سنين لقدام… الـ Registry بيقدر يقول: وقفوا هالدومين عن الـ Resolution. وهذا تقريباً اللي بتعمله حالة serverHold.

آكبر غلط منوقع فيه كلنا هو ضعف Observability ما فيك تصلح مشكلة أنت مو شايفها. إذا التطبيق بطيء، بس ما عندك أرقام واضحة، رح ترجع للتخمين: أي Query بطيئة؟ كم مرة اشتغلت؟ كم متوسط وقتها؟ هل في Locks؟ هل في Queries عم تفحص ملايين الصفوف؟ هل المشكلة من Query وحدة ولا من ضغط عام؟ بدون Monitoring، أنت فعلياً عم تشتغل بالعتمة. 💡 أهم شيء لازم تفعله: pg_stat_statements هاي الإضافة بتعطيك إحصائيات مهمة عن الاستعلامات، مثل: كم مرة اشتغل كل Query متوسط وقت التنفيذ إجمالي الوقت المستهلك عدد الصفوف المقروءة أو الراجعة أي Queries عم تستهلك أكبر وقت وكمان لازم تراقب: Slow Query Logs Locks عدد Connections استهلاك CPU/RAM حجم الجداول والـ Indexes Autovacuum activity ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بـ PostgreSQL، لما تعمل UPDATE أو DELETE لسطر معين، الداتا بيز فعلياً ما بتحذفه فوراً من الهارد ديسك! هاد السطر القديم بيتحول لشي منسميه Dead Tuple (سطر ميت). مع الوقت وكترة التعديلات، هدول الأسطر الميتة بيتراكموا وبيعملوا مشكلة اسمها Bloat (تضخم وهمي). يعني حجم الجداول والـ Indexes بيكبر بشكل مبالغ فيه عالفاضي. شو نتيجة هالـ Bloat؟ 📉 الاستعلامات (Queries) بتصير أبطأ بكتير. 📉 الـ Indexes بتكبر بلا طعمة. 📉 استهلاك مساحة التخزين بيزيد. 📉 قراءة البيانات بتصير أثقل والأداء العام بينزل. هون بيجي دور الـ Vacuum . هاد الأمر بينظف الـ Dead Tuples وبيساعد PostgreSQL يحافظ على أداء مستقر. ولحسن الحظ، في نظام تلقائي اسمه Autovacuum بيعمل هالشي بالخلفية بدون ما تتدخل. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

😭😭

بما انه Google عم تجهز لإطلاق Android 17 كمبرمج موبايل و خصوصاً flutter في كم شغلة لازم تبلش تشتغل عليها و تخليها ببالك لتضمن مايطلعلك اي crash بالتطبيق تبعك 1- اختبر تطبيقك على Android 17 emulator: نزل نسخة أندرويد 17 وجرب تمشي بكل شاشات التطبيق. ركزوا كتير على الـ large screen layouts (الشاشات الكبيرة)، وضع الـ split-screen mode (تقسيم الشاشة)، والـ freeform windowing. جوجل عم تركز كتير على التابلت والأجهزة القابلة للطي، فمشان هيك لازم الـ UI تبعك يكون مرن وما يضرب. 2- شيك على الـ native plugins: إذا تطبيقك بيعتمد على بكجات بتستخدم reflection لتوصل لملفات نظام مخفية بالأندرويد، أو بتسحب native libraries بشكل ديناميكي.. لازم تنتبه! أندرويد 17 رح يفرض قيود أمنية صارمة، وأي بكج قديم أو ما عم يتحدث ممكن يوقفلك التطبيق فجأة. 3- حطوا الـ AppFunctions ببالكم: إذا تطبيقكم فيه أكشنز واضحة للمستخدم (متل إنشاء طلب، بحث، أو حجز)، صار الوقت تفكروا تبنوا Platform Channel لتربطوا كود Kotlin مميز بـ @AppFunction. ليش؟ لأنو لما جوجل تطلق ميزات Gemini الجديدة، رح يصير الذكاء الاصطناعي قادر ينفذ أوامر جوا تطبيقك مباشرة. هاد الشي بيعطيك ميزة تنافسية خرافية! 4- راجعوا استخدام الصلاحيات بتطبيقاتكم: إذا تطبيقك بيطلب صلاحية READ_CONTACTS (قراءة جهات الاتصال)، أو بيقرا رسائل الـ SMS مشان يتحقق من كود الـ OTP (وهي حركة كتير منعملها بتطبيقات المحاسبة والمتاجر)، لازم توقفوا هالحكي وتدوروا على بدائل. جوجل ما عاد تسمحلك تسحب كل رسائل المستخدم أو كل أرقامه. كبديل للـ OTP، استخدموا الـ SMS Retriever API اللي بيجيب الكود لحاله بدون ما ينتهك خصوصية المستخدم. ولجهات الاتصال، استخدموا الـ Contact Picker. أي مخالفة لهي الأمور ممكن تعرض تطبيقك للرفض على Google Play! 🚨 ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شركة Anthropic أعلنت إنها مددت فترة الوصول لنموذج الذكاء الاصطناعي Claude Fable 5 لكل المستخدمين المشتركين بالخطط المدفوعة (Paid plans). التمديد رح يكون مستمر لغاية 12 تموز (يوليو). فرصة ممتازة لتستفيدوا من قدرات المودل وتجربوه بمشاريعكم وتختبروا أداءه بكتابة الأكواد خلال هالكم يوم الإضافيين! 🔥 #AI #Anthropic #ClaudeFable5 #TechNews

تخيل Query علقت. أو Query ناطرة Lock على جدول، والجدول محجوز من عملية ثانية. إذا ما عندك Timeout، ممكن تضل العملية معلقة لفترة طويلة جداً. المشكلة إنها مو بس معلقة وخلاص. هي كمان ممكن تكون: حاجزة Connection مستهلكة موارد مانعة عمليات ثانية مسببة تراكم بالطلبات وراها مشاكل أكبر بالتطبيق لذلك لازم تحط حدود زمنية واضحة. أهم إعدادين: statement_timeout بيوقف أي استعلام إذا أخذ أكثر من مدة معينة. lock_timeout بيوقف الاستعلام إذا ظل ينتظر Lock أكثر من مدة معينة. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

أحياناً قاعدة البيانات تتأخر أو تتعطل لثواني. المشكلة مو هون. المشكلة لما التطبيق يكون مبرمج يعمل Retry فوراً وبلا حدود. يعني الطلب يفشل، فيعيد المحاولة مباشرة. يفشل مرة ثانية، يعيد مباشرة. ويضل يعيد بدون توقف. شو بيصير؟ بدل ما تساعد النظام يرجع، أنت بتزيد الضغط عليه. ولما PostgreSQL يبدأ يتعافى، بتوصله دفعة ضخمة من الطلبات المتراكمة بنفس اللحظة. وهون ممكن يرجع ينهار من جديد. هاي الحالة اسمها Thundering Herd. لهيك استخدم Exponential Backoff. يعني لا تعيد المحاولة فوراً. خلي في وقت انتظار بين كل محاولة ومحاولة. مثلاً: المحاولة الثانية بعد 1 ثانية الثالثة بعد 3 ثواني الرابعة بعد 10 ثواني وبعد عدد معين من المحاولات، توقف وارجع Error واضح. الأفضل كمان تضيف Jitter، يعني تأخير عشوائي بسيط، حتى ما كل الطلبات تعيد المحاولة بنفس اللحظة. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

في PostgreSQL، كل Connection جديد مو مجاني. كل اتصال بياخد جزء من الذاكرة وموارد من السيرفر. المشكلة بتكبر لما يكون عندك تطبيق شغال على أكثر من Instance أو Pod. مثلاً: عندك 100 Pod وكل Pod فاتح 20 Connection يعني عندك 2000 اتصال مع PostgreSQL حتى لو أغلبهم Idle، بيضلوا حاجزين موارد من السيرفر. النتيجة؟ استهلاك RAM عالي ضغط على PostgreSQL بطء بالاستعلامات احتمال توصل لحد max_connections النظام يصير يرفض اتصالات جديدة لهيك لازم تستخدم Connection Pooler مثل pgBouncer. فكرته بسيطة: بدل ما كل طلب يفتح Connection مباشر مع PostgreSQL، pgBouncer بيقف بالنص، ويدير عدد قليل وفعال من الاتصالات الحقيقية. يعني التطبيق ممكن يرسل عدد كبير من الطلبات، لكن قاعدة البيانات ما تنضغط بعدد اتصالات ضخم. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

اكتر شي رح يواجهك مع PostgreSQL هو الـ Query البطيئة اللي ما بتعرف سببها ليش؟ اكبر غلط ممكن توقع فيه هو انك تحاول تحزر او تخمن شو السبب فممكن يخطر عبالك: • يمكن المشكلة بالـ index • يمكن الجدول كبير • يمكن الـ join غلط !! بس الحلو انه بدال كل هالتخمين هاد فيك بكل بساطة تستخدم:

EXPLAIN (ANALYZE, BUFFERS)

لانه بشغلك الاستعلام و بيعطيك معلومات واضحة مثل: كم أخذ وقت حقيقي هل استخدم Index أو عمل Sequential Scan أي جزء من الاستعلام هو الأبطأ كم قرأ من الذاكرة RAM كم اضطر يقرأ من الهارد هل المشكلة بالـ Join، Sorting، Filtering، أو غيرها ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بما انه شعبية PostgreSQL عم تكبر كل يوم اكتر رح نززلكم سلسلة منشورات بتحكي عن أشهر الأخطاء اللي ممكن تواجهك معها و نصائح مهمة كتير تتبعها لما مشروعك رح يصير Production ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

الـ Git 2.55 نزل، وأهم شي فيه إنه مركز على تحسين تجربة المطورين مع الـ repos الكبيرة وتنظيف الـ commits. كمبرمج، شو ممكن يفرق معك؟ git status أسرع على Linux صار في دعم لـ fsmonitor باستخدام inotify، يعني Git ما بيفحص كل الملفات كل مرة، وهاد بيساعد كتير بالمشاريع الكبيرة. تنظيف commits صار أسهل في أمر تجريبي جديد: git history fixup <commit> بيساعدك تدخل تعديل على commit قديم بدون rebase يدوي طويل، مفيد قبل فتح PR. Hooks أسرع بعض الـ Git hooks صار ممكن تشتغل parallel، يعني lint و checks قبل الـ commit ممكن يخلصوا أسرع. git log أوضح خيار جديد: --graph-lane-limit بيخلي عرض branches بـ git log --graph أرتب وأقل فوضى. بتحبوا نعمل فيديو يوتيوب عنه؟ ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

Next.js 16.3 صار متاح للتجربة، وأكبر تركيز فيه كان على تحسين Turbopack. طيب كمبرمج Frontend، شو رح يفرق معي فعلياً؟ أول شي، تجربة التطوير رح تصير أخف وأسرع. يعني لما تشغل المشروع بـ dev mode، المفروض استهلاك الذاكرة يكون أقل بكثير، وخصوصاً بالمشاريع الكبيرة أو الـ monorepos اللي عادة بتصير تقيلة مع الوقت. كمان في تحسينات على HMR، يعني التعديلات اللي بتعملها بالكود المفروض تظهر أسرع بالمتصفح بدون reload كامل أو تأخير مزعج. بالـ build كمان في فرق مهم، لأنه تمت إضافة Persistent File System Cache، وهاد بيساعد next build يصير أسرع لأنه ما يعيد كل الشغل من الصفر بكل مرة. في كمان دعم تجريبي لـ Rust React Compiler بدل نسخة Babel، وهاد ممكن يعطي أداء أفضل بالمشاريع الكبيرة، خصوصاً لما يكون عندك components كتيرة وتعقيد عالي. ومن الإضافات المفيدة دعم import.meta.glob، وهي بتفيدك لو عندك ملفات كثيرة بدك تستوردها تلقائياً، مثل blog posts، MDX files، أو صفحات محتوى، بدون ما تكتب import لكل ملف بإيدك. كمان Turbopack صار أذكى بحجم الـ runtime code، يعني ما بيشحن features غير مستخدمة، وهاد بيساعد على تحسين الأداء وتقليل الزوائد. شو رايك بالتحديث الجديد؟ ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

إذا عم تفعّل WhatsApp Username، لا تترك خيار Username Key مطفّى. الفكرة إنه الـ username لحاله بيخلي أي شخص بيعرفه يقدر يراسلك لأول مرة. أما Username Key فبيضيف طبقة خصوصية زيادة: الشخص لازم يعرف الـ username ومعه كمان كود من 4 أرقام قبل ما يقدر يبعتلك أول رسالة. يعني بدل ما يكون الوصول إلك عن طريق username بس، بيصير في خطوة حماية إضافية بتقلل الرسائل العشوائية والناس الغريبة. نصيحة: فعّل Username Key من البداية، خصوصاً إذا ناوي تستخدم username بدل رقم الموبايل.

واتساب عم يجهّز لواحدة من أكبر تحديثات الخصوصية بالتطبيق: Username Feature. الفكرة ببساطة إنك تقدر تتواصل مع الناس عن طريق username بدل ما تعطيهم رقم موبايلك، يعني رقمك بيضل مخفي عن الأشخاص الجدد. الميزة اختيارية، واللي بدو يضل يستخدم واتساب بالطريقة القديمة عن طريق رقم الهاتف بيقدر عادي. شروط الـ username: بين 3 و 35 حرف بيدعم lowercase letters، أرقام، dot و underscore لازم يحتوي على حرف واحد على الأقل ما بيقبل أسماء تشبه الدومينات مثل .com وفي كمان خيار اسمه username key، وهو كود من 4 أرقام بيشتغل كطبقة حماية إضافية، يعني حتى لو حدا عرف الـ username تبعك، ما بيقدر يبعتلك إلا إذا معه هالكود. المهم كمان إنه ما في public directory ولا بحث عشوائي عن usernames، لازم الشخص يعرف الـ username بشكل دقيق حتى يقدر يتواصل معك. الميزة بتخلي واتساب أقرب لـ Telegram و Signal من ناحية الخصوصية، وبتخفف مشاركة أرقام الهاتف خصوصاً بالجروبات، الشغل، أو التواصل مع ناس جداد.

لارافيل أضافت ميزة جديدة اسمها Route Metadata. الميزة بتسمح نربط إعدادات ومعلومات ثابتة مباشرة مع كل Route، ونقرأها لاحقاً داخل Middleware أو Controller بدل ما نعتمد على اسم الـ Route أو نكرر نفس الإعدادات في أكثر من مكان. مثال:

Route::post('/payments', PaymentController::class)
    ->metadata([
        'module' => 'finance',
        'audit' => true,
        'sensitive' => true,
    ]);

وبعدين داخل Middleware:

$route = $request->route();

$route->getMetadata('module');    // finance
$route->getMetadata('audit');     // true
$route->getMetadata('sensitive'); // true

بناءً على هالمعلومات ممكن نعمل Middleware موحد يقوم مثلاً بـ: تسجيل العمليات التي تحتاج Audit Log. تطبيق حماية إضافية على العمليات الحساسة. تحديد إعدادات الـ cache أو rate limit لكل Route. تصنيف الـ APIs حسب الموديول لأغراض التوثيق والمراقبة. كمان ممكن نضيف Metadata على Route Group، وLaravel رح تورثها تلقائياً لكل Routes الموجودة داخل المجموعة. الميزة ما بتنفذ المنطق لحالها، لكنها بتعطي كل Route وصف وإعدادات منظمة نقدر نبني عليها سلوك موحد، وبتكون مفيدة خصوصاً بالمشاريع الكبيرة التي فيها عدد كبير من الـ APIs والـ Middlewares. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بالإصدارات الجديدة من Laravel، صار فيكن تشغّلوا بيئة التطوير كاملة من خلال أمر واحد:

php artisan dev

الأمر بيشغّل عدة Development Processes بنفس الوقت، مثل: Laravel development server Queue worker Log tailing Vite يعني تقريباً نفس وظيفة composer dev الموجودة حالياً، بس الفرق إنو إعدادات الـ processes ما عادت محصورة ضمن composer.json، وصار فينا نتحكم فيها من داخل Application Code. التغيير بسيط، لكن بيساعد كتير بتنظيم Development Environment و بخلي تشغيل خدمات المشروع المحلية أوضح وأسهل، خصوصاً بالمشاريع اللي بتستخدم Queue، Reverb، Vite أو أدوات مثل Stripe CLI. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال