Code With Somar

أسوأ شعور لما يوقف مشروعك فجأة، وتفتح الـ Terminal وتصفن بالشاشة السودا وما تعرف من وين تبلش. الاعتماد على التخمين وإعادة التشغيل العشوائي كارثة. الـ DevOps بيعطيك الأدوات لتعرف وين تدور بالضبط: 1️⃣ docker logs: لتعرف شو الأخطاء اللي عم تطلع من الكود داخل الكونتينر. 2️⃣ journalctl: لتقرأ سجلات النظام وتشوف إذا المشكلة من السيرفر نفسه (مثلاً الـ RAM تعبت أو السيرفر عمل Kill للعملية). 3️⃣ docker inspect: لتعرف تفاصيل إعدادات الشبكة والصلاحيات. التشخيص الصح هو نص الحل، والـ Logs هي عيونك عالسيرفر! ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بدال ما تعمل Deploy بالشهر مرة و انت مرعوب رغم وجود pipline جرب تضيف Quality Gates كـ DevOps مو بس بتعمل pipline لترفع الملفات بل لازم تكون دقيق و تنتبه ما يكون في غلط عم يطلع مع هي الملفات و لهالسبب لما منكتب ملف .gitlab-ci.yml، نحنا عم نبني مراحل (Stages): 1️⃣ Test: بيشغل اختباراتك. إذا فشلت؟ بيوقف كل شي. 2️⃣ Build: بيبني المشروع (مثلاً بيبني صورة Docker لمشروع Laravel). 3️⃣ Deploy: بيرفع الشغل النظيف بس على السيرفر. هي الأتمتة بتعطيك ثقة إنك تنشر باليوم 10 مرات بدل مرة بالشهر وأنت مرعوب! ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

إذا سبق واستخدمت زر Share لمشاركة أي محادثة على Claude، فمن الأفضل تعتبرها عامة حتى تتأكد من حذفها. تبين أن روابط المحادثات المشتركة كانت قابلة للأرشفة من قبل محركات البحث، ما أدى إلى ظهور عدد كبير منها في نتائج البحث، واحتوائها على معلومات حساسة مثل: • مفاتيح API وبيانات اعتماد. • محافظ عملات رقمية. • سير ذاتية تتضمن أسماء وعناوين وأرقام هواتف. • تفاصيل مشاريع داخلية للشركات. • محادثات شخصية وخاصة. • وفي بعض الحالات، بيانات شخصية شديدة الحساسية. سبب المشكلة هو أن صفحات المحادثات المشتركة لم تكن تمنع محركات البحث من أرشفتها، لذلك أصبحت قابلة للوصول عبر البحث وليس فقط عبر الرابط المباشر. شركة Anthropic بكل بساطة ما ضافت كود noindex لمنع الأرشفة لهي الصفحات. سطر كود واحد كان بيمنع هالكارثة! 🔎 إذا سبق أن شاركت محادثة على Claude: اذهب إلى: Settings → Privacy → Your Data → Shared Chats → Manage ثم احذف أي محادثة تحتوي على معلومات شخصية، مالية، أو خاصة لا ترغب بأن تكون متاحة للآخرين.

أصدقائي اللي مفعلين Telegram Premium بإمكانكم تساعدونا نصير نفتح ميزات جديدة بالقناة 🔥 https://t.me/boost/code_with_somar

🧯 من مشاكل الـ Production #8 شو يعني Snapshot بالأنظمة المالية وليش مهم؟ تخيل زبون اشترى بالتقسيط. وقت الطلب كان الحساب: السعر: 1,000,000 الفائدة: 3% الإجمالي النهائي: 1,030,000 بعد 6 أشهر غيرت Formula حساب التقسيط. إذا كل مرة فتحت الطلب القديم أعدت حسابه باستخدام الـ Formula الجديدة… ممكن فجأة يصير إجمالي الطلب: 1,050,000 😅 مع إن الزبون اشترى واتفق على رقم مختلف. هون بيجي مفهوم: Financial Snapshot وقت تثبيت العملية المالية، تحفظ النتيجة الفعلية المستخدمة. مثلاً: installment_final_total = 1,030,000 من هاللحظة… هذا الرقم تاريخ مالي. مو نتيجة لازم نعيد حسابها كل مرة. 📌 الـ Formula ممكن تتغير. الـ Business Rules ممكن تتغير. لكن العملية المالية القديمة ما لازم يتغير تاريخها لأنك عملت Deploy جديد. بالأنظمة المالية: احفظ ما حدث فعلياً، مو فقط طريقة حسابه. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🧯 من مشاكل الـ Production #7 Crash و ANR و Freeze… مو نفس المشكلة المستخدم بيقلك: “التطبيق علق.” بس تقنياً ممكن يكون عم يحكي عن 3 مشاكل مختلفة. Crash 💥 التطبيق توقف وانغلق بسبب Error أو مشكلة قاتلة. ANR 🧊 اختصار لـ: Application Not Responding التطبيق موجود… لكن الـ Main Thread مشغول لدرجة إن النظام اعتبر التطبيق غير مستجيب. Freeze 🥶 وصف عام لتجربة المستخدم. الواجهة واقفة أو ما عم تتفاعل. ممكن يكون السبب Main Thread، IO، Rendering أو حتى State غلط. ليش الفرق مهم؟ لأن البحث عن Crash Logs ما رح يساعدك كثير إذا المشكلة أصلاً ANR. ومراقبة Exceptions فقط ما رح تخبرك ليش الـ UI عم يتجمد. 📌 أول سؤال لما المستخدم يقول: “التطبيق علق” مو: شو الـ Error؟ السؤال هو: علق كيف؟ ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🧯 من مشاكل الـ Production #6 Cache Invalidation و Cache Rebuild مو نفس الشي كتير منخلط بين عمليتين: Cache Invalidation و: Cache Rebuild الـ Invalidation يعني: هاي البيانات ما عاد فينا نثق فيها. فمنحذفها أو منعتبرها Stale. أما Rebuild يعني: ابني نسخة جديدة من البيانات. مثلاً تغير سعر منتج. ممكن تعمل: Invalidate → Wait for next request → Rebuild وهذا اسمه Lazy Rebuild. أو: Invalidate → Rebuild immediately وهذا Eager Rebuild. الفرق مهم. لأنك إذا عملت Rebuild مباشر لكل تغيير، ممكن Update جماعي لـ 10,000 منتج يولد 10,000 Job. وإذا عملت Invalidation فقط، أول مستخدم ممكن يتحمل كلفة إعادة البناء. 📌 حذف الـ Cache قرار. إعادة بنائها قرار ثاني. لا تربط الاثنين ببعض تلقائياً قبل ما تفهم حجم البيانات وطبيعة الـ Traffic. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🧯 من مشاكل الـ Production #5 شو يعني Race Condition؟ مثال حقيقي من Ecommerce عندك قطعة وحدة بالمخزون: stock_quantity = 1 وصل طلبين بنفس اللحظة. Request A قرأ المخزون: 1 Request B قرأ المخزون: 1 الأول قال: متوفر ✅ والثاني قال: متوفر ✅ الاثنين كملوا الطلب. مبروك… بعت قطعة وحدة لشخصين 😅 هاي اسمها: Race Condition المشكلة مو إن شرط المخزون غلط. المشكلة إن عمليتي القراءة والتعديل ما كانوا محميين من التنفيذ المتزامن. لهيك Check مثل: stock > 0 مو كافي دائماً. ممكن تحتاج: Database Lock أو Atomic Update أو آلية مناسبة حسب الـ Flow. 📌 لما تكتب Backend Code، لا تتخيل Request واحد عم ينفذ الكود. بالـ Production ممكن عدة Requests يوصلوا لنفس السطر بنفس اللحظة. الكود الصحيح لمستخدم واحد… مو دائماً صحيح تحت الـ Concurrency. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

عطل فني في موقع فيسبوك التطبيق لسا شغال لكن الموقع واقف حاليا

🧯 من مشاكل الـ Production #4 ليش exists داخل Array Validation ممكن يصير كارثة؟ تخيل API تستقبل ترتيب 500 منتج: items.*.id وبالـ Validation كتبت: exists:products,id شكله طبيعي جداً. لكن حسب طريقة الـ Validation والـ Logic المستخدم، ممكن ينتهي فيك الموضوع بعمل Database Lookup لكل ID. 500 عنصر؟ ممكن تعمل مئات الاستعلامات فقط حتى تقول: “نعم، المنتجات موجودة.” هاي نفس روح مشكلة N+1… بس مو بالـ Eloquent Relations. بالـ Validation 😅 الحل ببعض الحالات أبسط: اجمع كل الـ IDs. اعمل Query واحد: WHERE id IN (...) جيب الـ IDs الموجودة. وبعدين قارن النتيجة مع الـ Input. 📌 لا تقيس كلفة الـ Validation بعدد أسطر الكود. Validation Rule من كلمة وحدة… ممكن يكون وراه مئات الـ Queries. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🧯 من مشاكل الـ Production #3 Redis سريع… بس ممكن تكون عم تستخدمه غلط 🚀 أول ما نحكي Redis، أول كلمة بتخطر ببالنا: Cache. Query بطيء؟ خزن النتيجة بـ Redis. API بطيء؟ Cache. صفحة ثقيلة؟ Cache 😅 بس المشكلة إن Redis مو زر اسمه: “خلّي السيستم أسرع” مثلاً تخيل إنك خزنت Product Object كامل بالـ Cache لمدة ساعة. خلال هالساعة تغير السعر. شو صار؟ الـ Database فيها: 1,000,000 IQD والـ Cache لسا فيها: 1,100,000 IQD الـ Redis هون شغال 100%. المشكلة بالـ Design. وهون بيجي السؤال الأصعب بالـ Caching: مو كيف أخزن البيانات؟ السؤال هو: متى أمسحها؟ هاي هي مشكلة: Cache Invalidation كل Data بتحطها بالـ Cache لازم تعرف شو الأحداث اللي بتخليها Stale. تغير السعر؟ تغير المخزون؟ تغير الخصم؟ تغير حالة المنتج؟ إذا نسيت Event واحد فقط، ممكن تعرض بيانات قديمة للمستخدم. والموضوع أخطر لما تحط TTL طويل وتقول: “بعد ساعة بتنحل لحالها.” لأنك عملياً عم تقول: عادي السيستم يكون غلط لمدة ساعة. 😅 📌 Redis سريع جداً. بس البيانات الغلط بسرعة عالية… لسا بيانات غلط. قبل ما تعمل Cache لأي شي، اسأل: مين مسؤول عن Invalidation؟ إذا ما عندك جواب واضح، غالباً أنت مو جاهز تعمل Cache لهاي البيانات. ———————————- Linkedin |Instgram | YouTube أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

🔥 Firebase Remote Config ما عاد مجاني بشكل غير محدود Google أعلنت عن تغيير مهم بتسعير Firebase Remote Config، وابتداءً من 1 سبتمبر 2026 رح تنتقل الخدمة إلى نموذج Pay-As-You-Go (PAYG)، يعني التسعير رح يصير حسب عدد طلبات الـ fetch اليومية. الخبر الجيد: في Free Tier بيغطي أول 100,000 fetch يومياً لكل Project مجاناً. 💰 التسعير الجديد: • من 0 إلى 100,000 fetch يومياً → مجاني • من 100,001 إلى 10,000,000 → $0.06 لكل 10,000 fetch • فوق 10,000,000 → $0.01 لكل 10,000 fetch 📅 المواعيد المهمة: • 1 سبتمبر 2026: بدء تطبيق نموذج التسعير الجديد • 1 ديسمبر 2026: انتهاء فترة السماح الأساسية وبدء احتساب الرسوم • ممكن تأجيل بدء الفوترة حتى 1 فبراير 2027 إذا تم الانتقال إلى Blaze Plan قبل 15 نوفمبر 2026 Google كمان بتنصح بربط المشروع مع Google Cloud Billing Account والانتقال إلى Blaze Plan، خصوصاً للمشاريع اللي ممكن تتجاوز الحد المجاني، لتجنب أي throttling محتمل والحصول على فترة سماح إضافية. بالنسبة لمعظم التطبيقات الصغيرة والمتوسطة، 100 ألف fetch يومياً ممكن يكون أكثر من كافي، لكن الموضوع بيعتمد بشكل كبير على طريقة إعداد fetch interval وعدد المستخدمين النشطين. إذا تطبيقك بيستخدم Remote Config، صار مهم تراجع: عدد الـ fetch requests اليومية، إعدادات الـ cache والـ minimum fetch interval، وطريقة استدعاء Remote Config داخل التطبيق. 📌 التغيير خاص بـ Firebase Remote Config Fetch Requests، ومو معناه إن كل خدمات Firebase صارت مدفوعة.

أخيرًا، Laravel صار يدعم Image Processing بشكل رسمي First-party، يعني معالجة الصور صارت جزءًا مباشرًا من الـ Framework بدل الاعتماد دائمًا على Packages خارجية. صار فيك تتعامل مع الصور المرفوعة مباشرة: $request->image('avatar') ->optimize() ->store('avatars'); وكمان معالجة صورة موجودة مسبقًا: Storage::image('avatars/avatar.png') ->cover(200, 200) ->toWebp() ->store('thumbnails'); الميزة بتدعم Configurable Drivers مثل: GD — Imagick — Cloudflare وكمان Immutable Transformations لتحويل وتعديل الصور بطريقة مرتبة وواضحة. النتيجة؟ كود أبسط، معالجة صور أسهل، وإمكانية Resize / Crop / Optimize / WebP Conversion مباشرة بأسلوب Laravel المعتاد.🔥

🧯 من مشاكل الـ 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 أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال