Hello!
We are looking for an experienced Senior Backend Developer / Onsite Damascus to join an online E-commerce Company Based in Syria.
You will be responsible for designing, developing, and maintaining high-quality backend solutions that power our applications. You should have a deep understanding of backend technologies, and architecture patterns.

Key Responsibilities:
-Design & Development: Architect, design, and develop scalable, secure, and high-performance backend systems.
-API Integration: Develop RESTful APIs and integrate third-party services.
Database Management: Design and optimize database schemas, queries, and indexes for performance and scalability.
-Code Quality: Write clean, maintainable, and testable code. Conduct code reviews and ensure best practices.
-DevOps & CI/CD: Implement and maintain CI/CD pipelines, automate deployment processes, and manage cloud infrastructure.
-Security: Implement security best practices, ensuring data protection and compliance with relevant standards.
-Collaboration: Work closely with front-end developers, product managers, and other stakeholders to deliver high-quality products.
-Problem-Solving: Troubleshoot and debug complex issues in production environments.
-Mentorship: Provide guidance and mentorship to junior developers, fostering a culture of continuous learning.


Required Skills & Qualifications:
-Experience: 4+ years of experience in backend development, with a strong portfolio of successful projects.
-Programming Languages: Proficiency in [Insert relevant languages, e.g., Python, Java, Node.js, Ruby, PHP, etc.].
-Frameworks: Experience with backend frameworks like [Django, Laravel, etc.].
-Databases: Expertise in relational databases (e.g., MySQL,) and NoSQL databases (e.g., MongoDB, Redis).
-APIs: Extensive experience in building and consuming RESTful APIs, and understanding of GraphQL is a plus.
-DevOps: Familiarity with Docker, Kubernetes, CI/CD tools).
-Testing: Experience with automated testing frameworks and methodologies (e.g., unit tests, integration tests).
-Version Control: Proficient in Git.
-Agile Methodologies: Experience working in Agile/Scrum environments.
Communication: Excellent verbal and written communication skills.

Additional Information:
Location: Based in Damascus, Syria (Onsite Work)
Competitive compensation package with attractive benefits.
To apply, please send your resume to Rawan@wonderbeauties.com

WebSocket و WebRTC من أهم التقنيات اللي منستخدمها لبناء تطبيقات ويب حديثة بتتميز بزمن استجابة سريع (أو وصول سريع).

اليوم رح نحكي عن هالتقنيتين ونشوف شو الفرق بيناتن.

أولاً: WebRTC
WebRTC هو إطار عمل (framework) بيسمح للتطبيقات الويب والموبايل إنها تتصل ببعض بشكل مباشر وبالوقت الفعلي، وكمان بيتيح نقل بيانات متنوعة (مثل الفيديو، الصوت، أو أي نوع بيانات تاني) بطريقة peer-to-peer.

تقريباً كل المتصفحات الحديثة بتدعم WebRTC، وفي كمان مكتبات تطوير موجهة لأنظمة التشغيل مثل iOS و Android.

WebRTC بيجي كـ مجموعة APIs، وأهمهن:

RTCPeerConnection: هاد الـ API مسؤول عن الاتصال مع الطرف التاني (الـ peer) البعيد، وبيظل محافظ على الاتصال وبيراقب حالته، ولما نكون خلصنا منه بيقوم بإنهاء الاتصال.

RTCDataChannel: بيوفر قناة اتصال ثنائية الاتجاه لنقل البيانات بأي نوع (data) بين الطرفين.

MediaStream: هي الـ API اللي بتساعدنا ندير تدفقات الوسائط، مثل لما بدنا نتعامل مع كميرات أو مايكروفونات، ونقدر نتحكم بهي البيانات مثل الإرسال، التسجيل، التغيير بالحجم، أو عرض المحتوى.

ثانياً: WebSocket
WebSocket هي تقنية بتسمح بالاتصال ثنائي الاتجاه بين متصفح الويب والخادم، يعني اتصال مستمر بالوقت الفعلي.

الاتصال ببلش بمصافحة HTTP (HTTP handshake) وبعد ما يتفق الطرفين (الخادم والمتصفح) على استخدام اتصال TCP، هاد الاتصال بيظل شغال لفترة طويلة (ممكن يكون دايم إذا بدنا).

WebSocket بتتكون من شغلتين أساسيات:

WebSocket protocol: هو البروتوكول اللي بيسمح للمتصفح والخادم يتواصلوا بالوقت الفعلي، وبدعم نقل البيانات بشكل ثنائي أو كسلاسل نصية.

WebSocket API: هاد الـ API بيدير الاتصال، وبيرسل وبيستقبل الرسائل، وكمان بيستمع للأحداث اللي بتوصل من الخادم.

كل المتصفحات الحديثة تقريباً بتدعم WebSocket API.

شو الفرق بين WebRTC و WebSocket؟
WebSocket بيشتغل كبروتوكول اتصال بين المتصفح والخادم، أما WebRTC بيشتغل كبروتوكول peer-to-peer للاتصال بين المتصفحات أو تطبيقات الموبايل.

WebSocket بيشتغل مع بروتوكول TCP بس، بينما WebRTC بيستخدم بروتوكول UDP بشكل أساسي (لكن كمان بيدعم TCP).

إذا كان هدفنا الأمان التام للبيانات، WebSocket بيكون الخيار الأفضل. أما إذا كنا بدنا سرعة كبيرة حتى لو ضيعنا بعض البيانات (loss of packets)، فـ WebRTC مع UDP بيكون خيار أفضل.

WebRTC معمول بشكل رئيسي لبث الصوت والفيديو (لهيك بنشوفه كتير بمكالمات الفيديو والدردشة المرئية). بينما WebSocket ممكن نستخدمه لبث الوسائط، لكنه أكتر ملائم لنقل بيانات نصية مثل JSON (مثل تطبيقات الدردشة، الاختبارات، والتنبيهات).


Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Ayham Ibrahim على المساعدة في إعداد هذا المحتوى.

3 نصائح لتأمين موقعك خليهم ببالك

أولاً الـ MFA (Multi-Factor Authentication: كلمة المرور لحالها ما بتكفي، لازم يكون في خطوة إضافية للأمان مثل رمز يوصلك على موبايلك أو كود على الايميل او غيره! هالشي بيحمي حسابات المستخدمين من الهجمات اللي بتعتمد على سرقة كلمات المرور. متل لما بتسجل دخول على فيسبوك أو غوغل وبيطلبوا منك كود أمان!

الـ Input Validation and Santization: بما معناه "لا تثق بمدخلات المستخدم" و اللي هو مبدأ أساسي في أمن مواقع الويب، لازم تتحقق من كل شي عم يدخله المستخدم للتأكد إنه نظيف وما فيه أكواد خبيثة. مثلاً، تأكد إنه الإيميل مكتوب بصيغة صحيحة وما في محاولات إدخال ضارة. هاد الشي بيمنع سرقة البيانات وبيحمي التطبيق.

مبدأ الـ RBAC (Role-Based Access Control): يعني انه مو كل شخص لازم يشوف كلشي! مبدأ التحكم في الوصول على أساس الدور هو مبدأ بقلل صلاحيات المستخدمين إلى أقل حد ممكن ولذلك لتقليل صلاحيات الهجوم. مثلاً، في موقع ويب قد يكون فيه أدمن ومستخدم، يسمح لعدد محدد جداً من الأدمن للوصول إلى كل البيانات وتعديلها، بينما المستخدمين يسمح لهم فقط برؤية البيانات. يسمح هالمبدأ بتقليل الوصول غير المصرح به وتسريب البيانات.



Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـSana Atrsh على المساعدة في إعداد هذا المحتوى.

بما انه الكل هلا يفترض خلص امتحانات شو رايكم نساوي جلسة متل الجلسات السابقة؟؟

اعطونا اقتراحاتكم شو حابين تكون الجلسة القادمة 📝

إذا حابين تعرفوا آراء الناس اللي كانت معنا بالجلسة السابقة بإمكانكم من خلال التعليقات هنا

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

بكل مكان بتدور فيه على فرصة عمل، أول شي رح تلاحظه هو طلبهم لمهارة استخدام الـ Git!

بتسأل ليش؟ ببساطة لأن الـ Git هو المفتاح الأساسي لإدارة الكود والتعاون بفريق، سواء كنت عم تشتغل لحالك أو ضمن شركة كبيرة.

و منشان هيك رح يكون عنا جلسة تدريبية خلال الأيام الجايّة تعلمك كل شي عن الـ Git:

📌 أساسيات الـ Git
📌 الفرق بين Git، GitHub، وGitLab
📌 العمل مع الـ Branches و دمج التغييرات
📌 إصلاح الـ Merge Conflicts
📌 الـ Git Strategy
📌 شرح الـ Working Tree بالـ Git
📌 شوية Tips and Tricks رح تخليكم تتعاملوا باحترافية مع ال git.
📌 كيفية إدارة الكود على Git بشكل صحيح


🎯 شو رح تستفيد من الحضور؟
رح تعرف تشتغل مع الـ Git باحترافية عالية بكل تفاصيله إذا كنت بتشتغل لحالك او ضمن فريق بشركة.

⚠️ ما بتحتاج أي معرفة سابقة حتى تشارك!

⚡️ كالعادة انا مابفتح مقاعد كتير كرمال اضمن اني كون قادر ركز بالجلسة بشكل منيح و جاوب على الاسئلة!

🎯 تكلفة الجلسة: 150,000 ل.س تدفع عن طريق:
1️⃣ حوالة هرم
2️⃣ حوالة من بنك بيمو
3️⃣ للمتواجدين خارج سوريا التواصل معي في حال الرغبة بالتسجيل

- الأصدقاء اللي كنتوا معي بجلسات مدفوعة سابقة في خصم خاص الكم في حال حبيتوا تسجلوا معي بهي الجلسة كمان.

⚠️ عندك أي مشكلة بخصوص التكاليف؟
إذا كنت بحاجة لأي مساعدة أو عندك استفسار بخصوص التكاليف، تواصل معي، ورح نحاول نلاقي حل مناسب لحتى ما تفوت هالفرصة و اللي كان معي بالجلسة السابقة تبع لارافيل بيعرف انه الهدف ليس مادي ابداً.

✨ للتسجيل أو الحصول على مزيد من التفاصيل يرجى تعبئة الـ form التالي: هنا

📢 تأكد إنك رح تطلع من الجلسة محترف Git جاهز للعمل ضمن أي فريق! 👨‍💻

خلونا نتخيل فريق من 5 مبرمجين عم يشتغلوا على تطوير تطبيق ويب كبير. واحد من المبرمجين عم يشتغل على ميزة جديدة، بينما الآخرين عم يشتغلوا على إصلاحات للأخطاء.

و طلعت معكم المشاكل التالية:
1- المشكلة الأولى: الـ Conflict المبرمج الأول عم يشتغل على ميزة جديدة لصفحة "تسجيل الدخول"، بنفس الوقت المبرمج التاني عم يصلح خطأ بنفس الملف. لما حاولوا يدمجوا الشغل تبعهم، صار Conflict بين التعديلات!

2- المشكلة الثانية: حذف ملف مهم بالغلط واحد من المبرمجين كان عم يشتغل على تعديل مشروعه الشخصي وحذف ملف كتير مهم بخص قاعدة البيانات بالغلط. المشكلة إنه نسي يضيف تعديلاته إلى Staging Area قبل الحذف.

3- المشكلة الثالثة: التراجع عن Commit معيب بسبب انه واحد من المبرمجين عمل Commit في كود فيه أخطاء، و رفعه على (Main) على GitHub، وهالشي سبب مشاكل بالموقع و هو Production. بس ما بدنا نحذف أي تعديلات جاية بعد هالـ Commit لانها مهمة.

كيف ممكن تتصرف بهيك حالات؟

هي وحدة من الـ Case Study اللي رح نحكي عنها بجلسة الـ Git like a PRO اللي بعد ما نتعلم الأوامر رح نعرف كيف ننسق هي الاوامر لحل هيك نوع من الحالات مع العلم انه بالجلسة في 5 Case Study رح نحكي عنهم.

التسجيل مازال متاح على الجلسة بإمكانكم تتواصلوا معي لتعرفوا تفاصيل اكتر.

وقت نحكي عن الطرق المختلفة لتواصل تطبيقات الويب مع بعضها، أكيد رح نسمع بـ API والـ Webhooks.

الـ API والـ Webhooks هن أدوات أساسية بتسمح لتطبيقات الويب تتواصل مع بعضها من خلال إرسال البيانات من تطبيق للتاني لمعالجة طلبات أو إرسال إشعارات، أو حتى للوصول للموارد.

خلينا نحكي عن الفرق بين الـ API والـ Webhooks:

1 - Webhooks:
هون النظام بيكون قائم على الأحداث. يعني الـ Webhooks بتسمح لتطبيق يرسل بيانات لتطبيق تاني استجابة لحدث معين. والشي الرائع بالـ Webhooks إنها بتوفر اتصال لحظي (Real Time).

مثال: إذا مستخدم سجل دخول على الخدمة اللي بتقدمها، فيك تستخدم الـ Webhook لترسله إشعار ترحيبي أو إيميل ترحيبي.

2 - API:
الـ API هي اختصار لـ Application Programming Interface. هي عبارة عن مجموعة بروتوكولات بيستخدمها تطبيقين ليتواصلوا مع بعض. بتسمح باستيراد البيانات من تطبيق واستخدامها بتطبيق آخر.

مثال: عن طريق الـ API، فينا نحصل على معلومات المستخدم من تطبيق ونستخدمها بتطبيقنا، مثل عملية تسجيل الدخول عبر Facebook أو Google. منحصل على بيانات المستخدم من Facebook باستخدام الـ API وبنسمح له يدخل على موقعنا.

الفرق الأساسي بين الـ Webhooks والـ API:
الـ Webhooks بتوفر اتصال أحادي الاتجاه (يعني البيانات بتنتقل من تطبيق للتاني استجابة لحدث معين).
بينما الـ API بتوفر اتصال ثنائي الاتجاه بين التطبيقين.
أمثلة على استخدامات الـ API والـ Webhooks:
الـ Webhooks:

منستخدمها بتطبيقات التجارة الإلكترونية ومنصات التواصل الاجتماعي، مثلاً إرسال إشعار للمستخدم لما يضيف منتج لسلة الشراء أو رسالة ترحيبية للي تابع صفحتك.
شركات بتستخدم الـ Webhooks: Twitter، Dropbox، Stripe، Slack، Shopify.
الـ API:

منستخدمها بعمليات الدفع، الـ Chatbots، Ride-sharing، وعمليات تسجيل الدخول باستخدام تطبيقات تانية.
شركات بتستخدم الـ API: Google Maps، Amazon Web Services (AWS)، Instagram، Facebook.
طيب متى منستخدم الـ API ومتى منستخدم الـ Webhooks؟
هاد بيعتمد على التطبيق اللي عم نشتغل عليه ونوع البيانات المطلوبة. إذا كنا بحاجة لجلب بيانات نتيجة حدث معين أو بشكل لحظي، الـ Webhooks هو الحل المثالي. أما إذا بدنا اتصال ثنائي الاتجاه مع إمكانية الوصول البرمجي لموارد بتطبيق خارجي واستخدامها، فالحل هو الـ API.



Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Ayham Ibrahim على المساعدة في إعداد هذا المحتوى.

عم تشتغل على ميزة الدفع الالكتروني بالمشروع عندكم بالشركة و بالغلط رفعت ملفات الـ credentials او الـ Secret Key على الـ Repo اللي صار كل اللي موجودين هنيك بيعرفوهم ( Run ) لان الـ Team Leader إذا شافك مو من مصلحتك.

ممكن تفكر اوك انا بحذف الملف او بحذف السطر و برجع بساوي Push جديدة بتنحل المشكلة، الجواب هو لاء لان ضلت موجودة الـ Commit القديمة و اي شخص قادر يرجع الها.

طيب، شو الحل كرمال هيك مشكلة؟

حتى تعرف تحل هيك مشاكل ممكن تطلع معك كون معنا بجلسة الـ Git Like a PRO اللي رح نتعلم فيها كيف نتعامل مع الـ git باحترافية و ندرس مجموعة من الـ Case Study اللي بتغطي معظم الحالات اللي رح تواجهوها بشغلكم.

—————————————————————-

⚠️ خصم 20% من رسوم الجلسة لمستخدم الكود : TELE_OFFER_001 الكود صالح لشخص واحد فقط و يجب تأكيد الحجز اليوم. ⚠️

بإمكانكم تتواصلوا معي من خلال :

Facebook | Linkedin |Instgram | Telegram | YouTube

حتى تعرفوا تفاصيل اكتر حول الجلسة و طرف الدفع المتاحة

أزمة WordPress و WP Engine إلى أين؟

للي ما بيعرف شو صاير بين هالـ العمالقة فالقصة كالتالي:
بخطوة عملت ضجة كبيرة، ووردبريس قررت تحظر آلاف العملاء اللي بيستخدموا منصة WP Engine، واحدة من أشهر خدمات الاستضافة المدارة لمواقع ووردبريس. هالقرار خلى العملاء ما عاد يقدروا يعملوا تحديثات أو ينزلوا إضافات أو قوالب من خلال لوحة التحكم تبعهم، وهاد الشي أثار غضب كبير بين مجتمع ووردبريس.

القصة بلشت لما "مات مولنوغ"، مؤسس ووردبريس، اتهم WP Engine إنها انتهكت حقوق العلامة التجارية لووردبريس، وطلب منهم يدفعوا تعويضات كبيرة بالملايين. ولما المفاوضات فشلت، مولنوغ قرر يحظر WP Engine من مستودع ووردبريس الرسمي للإضافات والقوالب.

بمعنى تاني، أي حدا عنده موقع مستضاف على WP Engine ما رح يقدر يعمل تحديث أو يثبت أي إضافة أو قالب من خلال لوحة التحكم (WP Admin). وهالشي عمل مشكلة كبيرة للمطورين، الفريلانسرز، والشركات اللي بيعتمدوا على ووردبريس بشغلهم اليومي.

ردًا على الحظر، WP Engine نزلت بيان على موقعها وقالت فيه إن أداء المواقع وأمانها ما رح يتأثروا، وإنهم عم يشتغلوا على حل سريع. كمان وفروا تعليمات للزبائن عن كيف يثبتوا ويحدثوا القوالب والإضافات بشكل يدوي لحد ما تنحل الأزمة.



هالحكي كان خلال الأيام القليلة الماضية و لكن اليوم صرحت WordPress انه زعلت على المستخدمين اللي تأثروا سلباً بقرارات Silver Lake التجارية و قالوا أنه على الصفحة الرئيسية تبع WP Engine، بيعدوا بـ"أداء لا مثيل له، تحديثات تلقائية، وأمان محكم بيضمن نجاح مواقعك." WP Engine كانوا بيعرفوا تماماً إنه فينا نلغي الوصول وقت قرروا يتجاهلوا محاولاتنا لحل الخلافات والدخول باتفاقية ترخيص تجاري وفق ما قالت Word Press

و نتيجة لهاد الكلام Word Press رفعت الحظر عن المستخدمين حتى تاريخ الاول من تشرين الأول كرمال يراجعوا حالهم و يشوفوا قديش كانوا عم يستهلكوا من موارد الـ WordPress org ببلاش بينما ما كانوا عم يدفعوا وعم يهددوهم قانونياً.

البيان الخاص بوردبريس موجود عندهم على الموقع بإمكانكم تشوفوه.

و هي قصة المعركة باختصار و لنشوف الايام الجاية شو مخبية بيناتهم.

خبروني شي مرة استخدمتوا WP Engine و شو رايكم باللي عم يصير بيناتهم؟


Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

عمرك فكرت ليش أحياناً بتراجع كود قديم بتكون إنت كاتبه و بتحس بالندم؟ 😅 هالحالة مو غريبة بين المبرمجين، بس في حلول بتخليك تكتب كود مرتب وسهل تصليحه قدامك وقدام أي حدا تاني.

DRY (Don’t Repeat Yourself):
مبدأ "لا تكرر حالك" بيقول إنو أي قطعة كود لازم تكون موجودة بمكان واحد بس، وما نكررها. مثلاً، بلارافل، بدل ما نكرر قواعد validation بكل controller، منعملها بـ form request وحده ومنستدعيها كل ما احتجناها. هيك بتسهل الصيانة، بتعدل من مكان واحد بس بدل ما تلف عالكود كله.

KISS (Keep It Simple, Stupid!):
حاول دايماً تكتب الكود ببساطة. أي حدا بيرجع لهالكود قدام، سواءً إنت أو غيرك، بيكون أسهل يفهمه ويعدل عليه بدون تعقيدات. مرات الحل البسيط ممكن يكون أصعب بالتنفيذ من الحل المعقد، بس بيسهّل عليك وعلى اللي بيشتغل معك.

YAGNI (You Aren't Gonna Need It):
لا تضيف شغلات إضافية بالكود إلا إذا كنت فعلاً بحاجة إلها. توقعات المستقبل غالباً بتعمل تعقيد وبتزيد الأخطاء. ركز على المتطلبات الأساسية لحد ما يصير في حاجة فعلية لإضافة جديدة.

فكر فيها، كل ما كان الكود أبسط وأوضح، كل ما رح يكون شغلك أسرع وأخف وجع راس لقدام! جرب هالأساليب وشاركنا شو لاحظت بالفرق! 😉


Facebook | Linkedin |Instgram | Telegram | YouTube

===================

أنا Somar Kesen أعمل كـ Full Stack Developer أنشر بشكل شبه يومي منشورات تحتوي على العديد من المعلومات عن تطوير البرمجيات و سوق العمل مستخلصة من خبرة سنين في العمل مع العديد من الشركات في الشرق الأوسط و أوروبا ضمن هذا المجال

شكراً لـ Sana Atrash على المساعدة في إعداد هذا المحتوى.


—————————————————-
مازال التسجيل متاح على جلسة Git like a Pro بإمكانكم تتواصلوا معي حتى تعرفوا تفاصيل اكتر حول الجلسة و طرف الدفع المتاحة

Happy 16th birthday, Chrome! 🥳

Chrome celebrates its 16th anniversary this month!