Forwarded from الزَّنَاد
أنهيت مشروعك البرمجي؟
لم تعد بحاجة إلى تسجيل الشاشة أو قضاء ساعات في إعداد مرئية تعريفية بمشروعك.
مشروع "brag" يحلل مشروعك تلقائيًا، ثم يُنشئ مرئية ترويجية قصيرة تتضمن الحركة والمؤثرات والنصوص الجاهزة للنشر بأمر واحد فقط. كما يستخرج أبرز مزايا المشروع ويحولها إلى مادة قابلة للمشاركة.
من اللافت في عصر الاستذكاء أن الانتقال من بناء المنتج إلى التعريف به أصبح أسرع من أي وقت مضى.
رابط المشروع:
https://github.com/latent-spaces/brag
#الاستذكاء #البرمجة #التوليف #المهارات
لم تعد بحاجة إلى تسجيل الشاشة أو قضاء ساعات في إعداد مرئية تعريفية بمشروعك.
مشروع "brag" يحلل مشروعك تلقائيًا، ثم يُنشئ مرئية ترويجية قصيرة تتضمن الحركة والمؤثرات والنصوص الجاهزة للنشر بأمر واحد فقط. كما يستخرج أبرز مزايا المشروع ويحولها إلى مادة قابلة للمشاركة.
من اللافت في عصر الاستذكاء أن الانتقال من بناء المنتج إلى التعريف به أصبح أسرع من أي وقت مضى.
رابط المشروع:
https://github.com/latent-spaces/brag
#الاستذكاء #البرمجة #التوليف #المهارات
😢2
الاداة مش طبيعية
تقدر فيها تخلي كلام
تشيل الموسيقى و تسوي زي narration يعني ال agent يصير يحكي
شي قوي جدا جدااا
تقدر فيها تخلي كلام
تشيل الموسيقى و تسوي زي narration يعني ال agent يصير يحكي
شي قوي جدا جدااا
😢2😁1
Forwarded from Mohcin Bounouara's Space (Mohcin)
أحد كبيري مبرمجي Laravel و هو من ال core development team.
- أنا مع كلامه، بالمناسبة.
- أنا مع كلامه، بالمناسبة.
😁1
Mohcin Bounouara's Space
أحد كبيري مبرمجي Laravel و هو من ال core development team. - أنا مع كلامه، بالمناسبة.
باختصار تعلم المهارة الي ال AI ضعيف فيها
Forwarded from مدارسة الكتب الأثرية الحنبلية
تأمين المستقبل 💯
{ يَقُولُ يَالَيْتَنِي قَدَّمْتُ لِحَيَاتِي }
[سُورَةُ الفَجْرِ: ٢٤]
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1😢1
.كان عندنا مشكلة في Maweed وقت إنشاء الموعد
إنشاء الموعد نفسه ما كان بطيء، المشكلة كانت بالأشياء الي عم تصير معه بنفس الـ request.
يعني المستخدم ينشئ موعد، والنظام ينشئ الـ appointment، بعدها يتواصل مع WhatsApp API ويرسل الرسالة، وينتظر الرد، وبعدها يرجع response للمستخدم.
المشكلة هون إنه صار عندي جزء أساسي بالنظام معتمد على External API أنا أصلاً ما بتحكم فيه.
لو WhatsApp API تأخر ثانيتين، المستخدم ينتظر ثانيتين زيادة.
ولو صار فيه مشكلة أو timeout، ممكن يأثر على تجربة إنشاء الموعد كلها، مع إنه الموعد نفسه ما عنده أي مشكلة.
فالحل كان نفصل الشغلتين عن بعض ونخلي العملية Asynchronous.
صار الـ flow تقريباً:
Request → Create Appointment → Add Job to Queue → Response
وخلاص المستخدم انتهى دوره هون.
بالخلفية في Worker يأخذ الـ Job من الـ Queue ويعالج إرسال رسالة الواتساب بشكل مستقل:
Queue → Worker → WhatsApp API → Update Status
ولو فشل الإرسال، نقدر نعمل Retry للـ Job بدون ما المستخدم يعيد إنشاء الموعد أو حتى يحس بالمشكلة.
الفرق بالأداء كان واضح، لكن بالنسبة إلي الأهم من السرعة كان الـ Failure Isolation.
لو WhatsApp وقع، الـ appointments تضل شغالة.
وهون الفكرة الي فعلاً طلعت فيها من الموضوع:
مش كل مرة عندك API بطيء الحل إنك تحاول تخلي الكود أسرع
إنشاء الموعد نفسه ما كان بطيء، المشكلة كانت بالأشياء الي عم تصير معه بنفس الـ request.
يعني المستخدم ينشئ موعد، والنظام ينشئ الـ appointment، بعدها يتواصل مع WhatsApp API ويرسل الرسالة، وينتظر الرد، وبعدها يرجع response للمستخدم.
المشكلة هون إنه صار عندي جزء أساسي بالنظام معتمد على External API أنا أصلاً ما بتحكم فيه.
لو WhatsApp API تأخر ثانيتين، المستخدم ينتظر ثانيتين زيادة.
ولو صار فيه مشكلة أو timeout، ممكن يأثر على تجربة إنشاء الموعد كلها، مع إنه الموعد نفسه ما عنده أي مشكلة.
فالحل كان نفصل الشغلتين عن بعض ونخلي العملية Asynchronous.
صار الـ flow تقريباً:
Request → Create Appointment → Add Job to Queue → Response
وخلاص المستخدم انتهى دوره هون.
بالخلفية في Worker يأخذ الـ Job من الـ Queue ويعالج إرسال رسالة الواتساب بشكل مستقل:
Queue → Worker → WhatsApp API → Update Status
ولو فشل الإرسال، نقدر نعمل Retry للـ Job بدون ما المستخدم يعيد إنشاء الموعد أو حتى يحس بالمشكلة.
الفرق بالأداء كان واضح، لكن بالنسبة إلي الأهم من السرعة كان الـ Failure Isolation.
لو WhatsApp وقع، الـ appointments تضل شغالة.
وهون الفكرة الي فعلاً طلعت فيها من الموضوع:
مش كل مرة عندك API بطيء الحل إنك تحاول تخلي الكود أسرع
👍2🔥1
حَامِد | tech
Zero downtime deployment
من فترة لاحظت مشكلة في أحد المشاريع اللي أشتغل عليها، وهي إنه كل ما نعمل Deployment لتحديث جديد، الموقع أحياناً يرجع 502 Bad Gateway لفترة قصيرة، وبعدها يرجع يشتغل بشكل طبيعي.
المشكلة ما كانت من Laravel أو من أداء السيرفر، وإنما من طريقة الـ Deployment نفسها.
خليني أوضح لكم.
المشروع عندنا شغال باستخدام Docker Compose، وعندنا Traefik كـ Reverse Proxy، وNGINX مع PHP-FPM لتشغيل Laravel.
لما نعمل Push لتحديث جديد، الـ CI/CD Pipeline بتعمل الاختبارات، وتبني Docker Images جديدة، وبعدها تنشرها على السيرفر.
المشكلة بتصير لما Docker Compose تبدأ تستبدل الـ Containers القديمة بالجديدة.
الـ Container القديمة بتتوقف، والجديدة بتحتاج وقت حتى تشتغل وتكون جاهزة لاستقبال الطلبات.
وخلال هالفترة، Traefik ما بيلاقي Backend جاهز يوجه له الطلبات، وبالتالي المستخدم ممكن يشوف 502.
يعني المشكلة ببساطة إنه عم نستبدل النسخة الوحيدة اللي تخدم المستخدمين، قبل ما تكون النسخة الجديدة جاهزة.
هون بدأت أبحث عن موضوع الـ Zero-Downtime Deployment.
درست أكثر من طريقة، وأبرزها كانت:
Blue-Green Deployment
و
Rolling Deployment
الـ Rolling Deployment فكرتها إنه يكون عندك أكثر من Replica للتطبيق، وتبدأ تحدثهم وحدة وراء الثانية، مع المحافظة على نسخ شغالة تستقبل الطلبات.
حل ممتاز، خصوصاً مع أدوات Orchestration مثل Kubernetes، لكن بالنسبة لبنيتنا الحالية باستخدام Docker Compose، رح نحتاج نبني منطق إضافي لإدارة الـ Replicas والـ Health Checks والـ Traffic.
أما الـ Blue-Green Deployment ففكرتها أبسط بالنسبة لحالتنا.
بدل ما يكون عندنا نسخة واحدة من التطبيق، بيكون عندنا نسختين:
Blue: النسخة الحالية اللي تخدم المستخدمين.
Green: النسخة الجديدة اللي بدنا ننشرها.
لما نعمل Deployment، ما منوقف Blue.
بنشغل Green بالـ Docker Images الجديدة، وبنتأكد إنه التطبيق شغال، وقادر يتصل بالـ Database وRedis، وإنه الـ Health Checks والـ Readiness Checks ناجحة.
وبعدها منغير الـ Routing من خلال Traefik حتى الطلبات الجديدة تصير تروح لـ Green بدل Blue.
والنسخة القديمة منخليها شغالة لفترة، حتى لو صار أي خلل بالنسخة الجديدة نقدر نعمل Rollback بسرعة، بدون ما نحتاج نعيد بناء التطبيق.
لكن هون في نقطة مهمة جداً.
الـ Zero-Downtime مش مجرد تشغيل نسختين من التطبيق.
عندك مثلاً الـ Database Migrations.
تخيل النسخة الجديدة حذفت Column من قاعدة البيانات، والنسخة القديمة بعدها تعتمد عليه.
حتى لو رجعنا الـ Traffic للنسخة القديمة، التطبيق ممكن ما يشتغل!
لهيك لازم نعتمد مبدأ Expand-Contract Migrations، بحيث تغييرات قاعدة البيانات تكون متوافقة مع النسختين خلال عملية الانتقال والـ Rollback.
وعندك كمان الـ Queue Workers والـ Scheduler والـ WebSockets.
ما بصير نكرر كل الخدمات بشكل عشوائي، لأنه ممكن يصير عندنا تنفيذ مكرر لبعض المهام، أو تنقطع اتصالات موجودة.
لهيك القرار كان إنه نبدأ بتطبيق Blue-Green على خدمات الـ HTTP الأساسية:
NGINX وPHP-FPM وInertia SSR.
ونخلي MySQL وRedis والخدمات الخلفية مستقرة، ونعالج طريقة تحديثها بشكل منفصل.
طيب ليش اخترت Blue-Green بدل Rolling؟
لأنه أنسب للبنية الحالية، وأسهل بالتحكم والـ Rollback، وما بيحتاج ندخل Kubernetes أو نضيف تعقيد تشغيلي ما عندنا حاجة فعلية إله حالياً.
طبعاً في Trade-offs.
أولها استهلاك موارد إضافية، لأنه خلال الـ Deployment رح يكون عندنا نسختين من التطبيق شغالتين بنفس الوقت.
وثانيها إنه لازم نهتم بموضوع توافق قاعدة البيانات، والـ Sessions، والـ Frontend Assets، والاتصالات الموجودة قبل ما نوقف النسخة القديمة.
وكمان Blue-Green ما بيعني High Availability.
لو السيرفر نفسه وقع، النسختين رح يوقعوا معه، لأنه حالياً كلشي على نفس الـ VPS.
يعني الحل بيعالج الانقطاع الناتج عن نشر التحديثات، مش كل أنواع الأعطال الممكنة.
حالياً خلصت مرحلة الـ Infrastructure Audit، وحددنا سبب المشكلة، ودرسنا استهلاك الموارد وطريقة الـ Deployment الحالية، واستقرينا على تصميم Blue-Green كاتجاه للتنفيذ.
والخطوة القادمة هي تطبيق الحل واختباره، خصوصاً سيناريوهات فشل النسخة الجديدة والـ Rollback، قبل ما نعتمد إنه صار عندنا Zero-Downtime فعلياً.
الدرس اللي طلعته من هالموضوع إنه نجاح الـ CI/CD Pipeline ما بيعني بالضرورة نجاح تجربة المستخدم أثناء النشر.
ممكن كل الاختبارات تنجح، والـ Deployment يطلع Successful، لكن خلال العملية نفسها يكون الموقع انقطع عن المستخدمين.
وهون الفرق بين إنك تعمل Deployment ناجح تقنياً، وإنك تبني Release Process موثوق وقابل للاسترجاع بدون ما تأثر على المستخدم.
المشكلة ما كانت من Laravel أو من أداء السيرفر، وإنما من طريقة الـ Deployment نفسها.
خليني أوضح لكم.
المشروع عندنا شغال باستخدام Docker Compose، وعندنا Traefik كـ Reverse Proxy، وNGINX مع PHP-FPM لتشغيل Laravel.
لما نعمل Push لتحديث جديد، الـ CI/CD Pipeline بتعمل الاختبارات، وتبني Docker Images جديدة، وبعدها تنشرها على السيرفر.
المشكلة بتصير لما Docker Compose تبدأ تستبدل الـ Containers القديمة بالجديدة.
الـ Container القديمة بتتوقف، والجديدة بتحتاج وقت حتى تشتغل وتكون جاهزة لاستقبال الطلبات.
وخلال هالفترة، Traefik ما بيلاقي Backend جاهز يوجه له الطلبات، وبالتالي المستخدم ممكن يشوف 502.
يعني المشكلة ببساطة إنه عم نستبدل النسخة الوحيدة اللي تخدم المستخدمين، قبل ما تكون النسخة الجديدة جاهزة.
هون بدأت أبحث عن موضوع الـ Zero-Downtime Deployment.
درست أكثر من طريقة، وأبرزها كانت:
Blue-Green Deployment
و
Rolling Deployment
الـ Rolling Deployment فكرتها إنه يكون عندك أكثر من Replica للتطبيق، وتبدأ تحدثهم وحدة وراء الثانية، مع المحافظة على نسخ شغالة تستقبل الطلبات.
حل ممتاز، خصوصاً مع أدوات Orchestration مثل Kubernetes، لكن بالنسبة لبنيتنا الحالية باستخدام Docker Compose، رح نحتاج نبني منطق إضافي لإدارة الـ Replicas والـ Health Checks والـ Traffic.
أما الـ Blue-Green Deployment ففكرتها أبسط بالنسبة لحالتنا.
بدل ما يكون عندنا نسخة واحدة من التطبيق، بيكون عندنا نسختين:
Blue: النسخة الحالية اللي تخدم المستخدمين.
Green: النسخة الجديدة اللي بدنا ننشرها.
لما نعمل Deployment، ما منوقف Blue.
بنشغل Green بالـ Docker Images الجديدة، وبنتأكد إنه التطبيق شغال، وقادر يتصل بالـ Database وRedis، وإنه الـ Health Checks والـ Readiness Checks ناجحة.
وبعدها منغير الـ Routing من خلال Traefik حتى الطلبات الجديدة تصير تروح لـ Green بدل Blue.
والنسخة القديمة منخليها شغالة لفترة، حتى لو صار أي خلل بالنسخة الجديدة نقدر نعمل Rollback بسرعة، بدون ما نحتاج نعيد بناء التطبيق.
لكن هون في نقطة مهمة جداً.
الـ Zero-Downtime مش مجرد تشغيل نسختين من التطبيق.
عندك مثلاً الـ Database Migrations.
تخيل النسخة الجديدة حذفت Column من قاعدة البيانات، والنسخة القديمة بعدها تعتمد عليه.
حتى لو رجعنا الـ Traffic للنسخة القديمة، التطبيق ممكن ما يشتغل!
لهيك لازم نعتمد مبدأ Expand-Contract Migrations، بحيث تغييرات قاعدة البيانات تكون متوافقة مع النسختين خلال عملية الانتقال والـ Rollback.
وعندك كمان الـ Queue Workers والـ Scheduler والـ WebSockets.
ما بصير نكرر كل الخدمات بشكل عشوائي، لأنه ممكن يصير عندنا تنفيذ مكرر لبعض المهام، أو تنقطع اتصالات موجودة.
لهيك القرار كان إنه نبدأ بتطبيق Blue-Green على خدمات الـ HTTP الأساسية:
NGINX وPHP-FPM وInertia SSR.
ونخلي MySQL وRedis والخدمات الخلفية مستقرة، ونعالج طريقة تحديثها بشكل منفصل.
طيب ليش اخترت Blue-Green بدل Rolling؟
لأنه أنسب للبنية الحالية، وأسهل بالتحكم والـ Rollback، وما بيحتاج ندخل Kubernetes أو نضيف تعقيد تشغيلي ما عندنا حاجة فعلية إله حالياً.
طبعاً في Trade-offs.
أولها استهلاك موارد إضافية، لأنه خلال الـ Deployment رح يكون عندنا نسختين من التطبيق شغالتين بنفس الوقت.
وثانيها إنه لازم نهتم بموضوع توافق قاعدة البيانات، والـ Sessions، والـ Frontend Assets، والاتصالات الموجودة قبل ما نوقف النسخة القديمة.
وكمان Blue-Green ما بيعني High Availability.
لو السيرفر نفسه وقع، النسختين رح يوقعوا معه، لأنه حالياً كلشي على نفس الـ VPS.
يعني الحل بيعالج الانقطاع الناتج عن نشر التحديثات، مش كل أنواع الأعطال الممكنة.
حالياً خلصت مرحلة الـ Infrastructure Audit، وحددنا سبب المشكلة، ودرسنا استهلاك الموارد وطريقة الـ Deployment الحالية، واستقرينا على تصميم Blue-Green كاتجاه للتنفيذ.
والخطوة القادمة هي تطبيق الحل واختباره، خصوصاً سيناريوهات فشل النسخة الجديدة والـ Rollback، قبل ما نعتمد إنه صار عندنا Zero-Downtime فعلياً.
الدرس اللي طلعته من هالموضوع إنه نجاح الـ CI/CD Pipeline ما بيعني بالضرورة نجاح تجربة المستخدم أثناء النشر.
ممكن كل الاختبارات تنجح، والـ Deployment يطلع Successful، لكن خلال العملية نفسها يكون الموقع انقطع عن المستخدمين.
وهون الفرق بين إنك تعمل Deployment ناجح تقنياً، وإنك تبني Release Process موثوق وقابل للاسترجاع بدون ما تأثر على المستخدم.
❤1