يعني إيه Hotfix؟ 🤔
.
.
الساعة 2 بالليل، الدنيا هادية، وفجأة يرن تليفونك أو يجيلك Slack message بيقولك:


- الناس مش عارفة تدخل على السيستم
- فيه حاجة غريبة بتحصل بعد الـ Login
- الناس مش عارفة توصل لصفحة الـ Checkout والمبيعات وقفت

في اللحظة دي، مفيش وقت تفكر في الـ Agile ولا تقول "نضيفها في الـ Sprint الجاية"
كل الكلام ده بيقف مؤقتًا، لأن دلوقتي فيه حاجة واحدة بس بتفكر فيها:

"إزاي تحل المشكلة بأسرع شكل ممكن؟"

وهو ده المقصود بالـ Hotfix...

———

📌 يعني إيه Hotfix؟

الـ Hotfix ببساطة هو تعديل سريع جدًا بيتعمل على الكود الموجود في الـ production علشان يحل مشكلة ظهرت فجأة، وبتأثر على المستخدمين أو السيستم نفسه.

يعني مثلًا، لو فجأة زرار الدفع اختفى، أو الناس مش عارفة تعمل Login، أو حصل Crash في تطبيق موبايل بعد التحديث الأخير…ده بيستدعي تدخل سريع جدًا بـ Hotfix.

———

📌 إمتى بنلجأ لـ Hotfix؟

- لو المشكلة ظهرت في الـ Production ومظهرتش في الـ Testing.
- لو المشكلة بتأثر على عدد كبير من الناس أو على Revenue الشركة.
- مش هينفع تنتظر للـ Release الجاي.

———

📌 إيه الفرق بينه وبين أي Bug Fix؟

الـ Bug Fix ممكن يتأجل ويتحط في الـ Backlog ويتحل في Sprint جاية.
إنما الـ Hotfix هو ضروري جدًا، بيتعمل بسرعة، غالبًا خارج الـ Sprint، وبيتم Testing ليه بشكل سريع بردو.

بس خد بالك...السرعة هنا مش معناها تسرّع.
الـ Hotfix لازم يتعمل بدقة، ويتراجع كويس، ويتعمله Testing على قد ما نقدر، لأن أي غلطة هتطلع في الـ Production مباشرة.

———

⚙️ خطوات التعامل مع Hotfix (من واقع التجربة):

- الـ Identify: حد بيبلغك بالمشكلة، سواء QA أو Support أو Logs أو حتى Client.
- الـ Reproduce: جرّب تشوف المشكلة بنفسك علشان تتأكد وتفهم أصلها.
- الـ Fix Quickly: اعمل تعديل سريع بس بدون ما تبهدل الكود.
- الـ Test: جرّب الحل كويس. لو فيه Automated Tests، شغّلها.
- الـ Deploy مباشرة: غالبًا بيتم Deployment منفصل عن الـ Release Cycle.
- الـ Merge للـ Main Branch: أحيانًا بيتعمل Patch للفرع الرئيسي، وبعدها لازم ترجع تدمج الـ Fix ده في الـ Develop أو Master علشان يفضل موجود.

———

⚠️ المشاكل اللي ممكن تقابلها مع Hotfix:

1- التسرّع يسبب مشاكل أكبر من الأصلية.
2- ممكن تعمل Conflict في الـ branches لو معملتش merge للتعديلات صح.
3- لو الفريق معندوش آلية CI/CD كويسة، ممكن الـ Deployment يكون صعب ورخم.
4- ممكن ناس من الفريق متبقاش Online وقت المشكلة وده هيطول فترة حلها.

———

💡 إزاي نجهّز نفسنا إننا نعمل Hotfix بشكل كويس؟

- يبقى عندك Logs قوية وسهلة البحث.
- الـ Monitoring Tools تشوف منها المشاكل بسرعة.
- يكون عندك Process واضحة للـ Hotfix: مين بيحل؟ مين بيراجع؟ مين بيعمل Deploy؟
- وثّق المشكلة والـ Fix علشان ما تتكرر.

———

بعد ما تعمل Hotfix، يفضل إنك تعمل Post-Mortem:
يعني تتناقش مع الفريق إيه اللي حصل؟ ليه المشكلة دي وصلت للـ Production؟ وإزاي نمنعها المرة الجاية؟

———

وفقكم الله لكل خير 🌿

فيه أوقات وأنت شغال على UI، بتحتاج تأخّر ظهور البيانات شوية عشان تشوف شكل الـ Skeleton أو الـ Loader أو حتى شكل الصفحة قبل ما يكون فيها أي بيانات.

يعني مثلًا بتجيب بيانات من API، لكن الـ API سريع جدًا، فـ الـ Skeleton بيظهر نص ثانية ويختفي، وما بتلحق تشوف شكله عامل إزاي.

الحل هنا إنك تعمل delay بسيط قبل الريكوست أو قبل عرض البيانات.

———

// utils.ts

/**
 * Sleep function to delay execution for a given number of milliseconds.
 * @param ms - Duration to wait in milliseconds
 */
export const sleep = (ms: number): Promise<void> => {
  return new Promise((resolve) => setTimeout(resolve, ms));
};

———

وتقدر تستخدمها في الكود بالشكل ده:

import { sleep } from './utils.ts'; 

const fetchData = async () => {
  await sleep(1000); // 1 second
  
  const res = await fetch('https://jsonplaceholder.typicode.com/users');
  const data = await res.json();

  return data;
};

———

خلي بالك لو أنت هتضيفها في مرحلة الـ Development متنساش تشيلها في الـ Production، وممكن تتحكم فيها من خلال env variable...

The Only TypeScript Course You Need in 2025 💯

https://youtu.be/K01hLNDdqg4

🔰 Top DevOps Tools

يعني إيه Hotfix؟ 🤔
.
.
الساعة 2 بالليل، الدنيا هادية، وفجأة يرن تليفونك أو يجيلك Slack message بيقولك:

- الناس مش عارفة تدخل على السيستم
- فيه حاجة غريبة بتحصل بعد الـ Login
- الناس مش عارفة توصل لصفحة الـ Checkout والمبيعات وقفت

في اللحظة دي، مفيش وقت تفكر في الـ Agile ولا تقول "نضيفها في الـ Sprint الجاية"
كل الكلام ده بيقف مؤقتًا، لأن دلوقتي فيه حاجة واحدة بس بتفكر فيها:

"إزاي تحل المشكلة بأسرع شكل ممكن؟"

وهو ده المقصود بالـ Hotfix...

———

📌 يعني إيه Hotfix؟

الـ Hotfix ببساطة هو تعديل سريع جدًا بيتعمل على الكود الموجود في الـ production علشان يحل مشكلة ظهرت فجأة، وبتأثر على المستخدمين أو السيستم نفسه.

يعني مثلًا، لو فجأة زرار الدفع اختفى، أو الناس مش عارفة تعمل Login، أو حصل Crash في تطبيق الموبايل بعد التحديث الأخير…ده بيستدعي تدخل سريع جدًا بـ Hotfix.

———

📌 إمتى بنلجأ لـ Hotfix؟

- لو المشكلة ظهرت في الـ Production ومظهرتش في الـ Testing.
- لو المشكلة بتأثر على عدد كبير من الناس أو على Revenue الشركة.
- مش هينفع تنتظر للـ Release الجاي.

———

📌 إيه الفرق بينه وبين أي Bug Fix؟

الـ Bug Fix ممكن يتأجل ويتحط في الـ Backlog ويتحل في Sprint جاية.
إنما الـ Hotfix هو ضروري جدًا، بيتعمل بسرعة، غالبًا خارج الـ Sprint، وبيتم Testing ليه بشكل سريع بردو.

بس خد بالك...السرعة هنا مش معناها تسرّع.
الـ Hotfix لازم يتعمل بدقة، ويتراجع كويس، ويتعمله Testing على قد ما نقدر، لأن أي غلطة هتطلع في الـ Production مباشرة.

———

⚙️ خطوات التعامل مع الـ Hotfix (من واقع التجربة):

- الـ Identify: حد بيبلغك بالمشكلة، سواء QA أو Support أو Logs أو حتى Client.
- الـ Reproduce: جرّب تشوف المشكلة بنفسك علشان تتأكد وتفهم أصلها.
- الـ Fix Quickly: اعمل تعديل سريع بس بدون ما تبهدل الكود.
- الـ Test: جرّب الحل كويس. لو فيه Automated Tests، شغّلها.
- الـ Deploy مباشرة: غالبًا بيتم Deployment منفصل عن الـ Release Cycle.
- الـ Merge للـ Main Branch: أحيانًا بيتعمل Patch للفرع الرئيسي، وبعدها لازم ترجع تدمج الـ Fix ده في الـ Develop أو Master علشان يفضل موجود.

———

⚠️ المشاكل اللي ممكن تقابلها مع الـ Hotfix:

1- التسرّع يسبب مشاكل أكبر من الأصلية.
2- ممكن تعمل Conflict في الـ branches لو معملتش merge للتعديلات صح.
3- لو الفريق معندوش آلية CI/CD كويسة، ممكن الـ Deployment يكون صعب ورخم.
4- ممكن ناس من الفريق متبقاش Online وقت المشكلة وده هيطول فترة حلها.

———

💡 إزاي نجهّز نفسنا إننا نعمل Hotfix بشكل كويس؟

- يبقى عندك Logs قوية وسهلة البحث.
- الـ Monitoring Tools تشوف منها المشاكل بسرعة.
- يكون عندك Process واضحة للـ Hotfix: مين بيحل؟ مين بيراجع؟ مين بيعمل Deploy؟
- وثّق المشكلة والـ Fix علشان ما تتكرر.

———

بعد ما تعمل Hotfix، يفضل إنك تعمل Post-Mortem:
يعني تتناقش مع الفريق إيه اللي حصل؟ ليه المشكلة دي وصلت للـ Production؟ وإزاي نمنعها المرة الجاية؟

———

وفقكم الله لكل خير 🌿

يعني إيه Canary Testing؟ 🤔
.
.
تخيل معايا إنك بتشتغل في شركة Tech كبيرة، وعندك Feature جديدة اشتغلت عليها أكتر من أسبوع، اختبرتها على الـ dev environment، وعدّت الـ QA، وكل حاجة تمام…
بس قبل ما تطلعها لكل الناس على الـ production، في سؤال بيخطر في بالك:

"يا ترى الفيتشر دي هتشتغل فعلًا كويس لما تنزل؟ ولا ممكن تعمل مشاكل للمستخدمين؟"

وهنا ييجي دور الـ Canary Testing...

——-—

الكلمة دي أصلها لما كانوا عمّال المناجم بياخدوا طيور الكناري معاهم تحت الأرض. الطيور دي كانت بتحذرهم لو فيه غاز سام قبل ما هم نفسهم يتأثروا.
لو الكناري ماتت، يبقى فيه خطر، ولازم يطلعوا فورًا

نفس الفكرة بالضبط في البرمجة
قبل ما نـ rollout feature أو update لكل الناس، بنطلّعها لعدد صغير جدًا من المستخدمين الحقيقيين — الكناري بتاعنا — ونراقب سلوك السيستم كويس. لو كل حاجة ماشية تمام، نكمّل التحديث لباقي الناس. لو حصلت مشاكل؟ نوقف الدنيا بسرعة ونرجّعها زي ما كانت.

———

📌 إمتى نستخدم الـ Canary Testing؟

- لو الـ Feature حساسة شويتين وممكن تعمل impact كبير لو فيها bug.
- لو بتشتغل على Microservices وعايز تتأكد إن الـ service الجديدة مش هتبوّظ الـsystem كله.
- لو شغال في بيئة فيها ملايين الـusers ومينفعش تخاطر.

———

💡 إيه الفرق بين Canary Testing و A/B Testing؟

ناس كتير بتتلخبط بينهم، بس الفرق واضح:

الـ Canary Testing: إحنا بنجرب نفس الـ feature على نسبة صغيرة من الناس ونشوف هل فيها مشاكل ولا لا.

الـ A/B Testing: إحنا بنجرب نسختين مختلفين (Version A و Version B) ونشوف أنهي فيهم هيكون أحسن.

يعني الـCanary هدفه الأساسي الأمان، والـA/B هدفه الأساسي التحسين والتطوير.

———

⚙️ إزاي بنطبّق Canary Testing؟

فيه كذا طريقة، على حسب الـ Infra اللي شغال بها:

1- الـ Feature Flags: بتكون مشغل الـ feature الجديدة بس لناس معينة أو نسبة صغيرة.

2- الـ Traffic Splitting: ممكن تستخدم أدوات زي Kubernetes أو Load Balancers علشان توزّع الـ traffic بشكل كويس.

3- الـ Monitoring Tools: أهم حاجة تتابع الـ logs والـ metrics والـ errors أول بأول، سواء بـ Datadog أو New Relic أو أي أداة بترتاح فيها.

4- الـ Rollback Plan: لو حصلت مشكلة؟ تكون محضّر خطة rollback سريعة.

———

وفقكم الله لكل خير 🌿

The Hidden SEO Superpower: Mastering Sitemaps & Site Structure for Explosive Organic Growth 🧭

What if I told you that your website could be brilliant, beautiful — and invisible to Google?

That’s the harsh reality for many site owners who ignore the quiet powerhouse of SEO: the sitemap.

———

🔗 https://dev.to/alisamir/the-hidden-seo-superpower-mastering-sitemaps-site-structure-for-explosive-organic-growth-18pn

تعلم n8n من الصفر - طريقك للبداية في عالم الأوتوميشن!

https://youtu.be/rtaEw-wSg20

يعني إيه Sitemap؟ وإزاي بتأثر على SEO؟ 🚀
.
.
فيه حاجات في الويب لو فهمتها بدري، هتوفر على نفسك مشاكل كتير قدام…
واحدة من الحاجات دي هي الـ Sitemap.

وهي دي إجابة سؤال: "ليه جوجل مش بيأرشف كل صفحات الموقع؟"
أو
"ليه الصفحات الجديدة مش بتظهر في السيرش؟"

وده لأنك مش عامل Sitemap صح، أو مش عاملها أصلًا.

تعال ندردش شوية ونعرف يعني إيه Sitemap، وإزاي ممكن تساعد موقعك...

———

📌 يعني إيه Sitemap؟

تقدر تعتبرها خريطة الموقع بتاعك.
زي خريطة مول كبير، فيها كل المحلات والمداخل والمخارج… بس هنا الخريطة معمولة عشان Google و Bing وكل محركات البحث.

يعني sitemap.xml دي عبارة عن فايل بيقول لمحركات البحث:

"الموقع بتاعي فيه الصفحات دي كلها، ودي أهمها، ودي اللي تم تحديثها قريب، ودي اللي محتاج تدخلها بسرعة."

فالـ Sitemap بتسهّل جدًا على الـ Crawlers إنها تـفهم موقعك وتمشي فيه من غير توهان.

———

💡ليه الـ Sitemap مهمة؟

خليني أقولك على شوية سيناريوهات واقعية:

- لو موقعك لسه جديد ومفيهوش لينكات كتير، فغالبًا الـ Google مش هيعرف يوصل لكل الصفحات بسهولة. هنا sitemap بتساعده يوصل أسرع.

- لو عندك صفحات كتير مش مربوطة ببعض (يعني مفيش internal links كفاية)، فـ محركات البحث ممكن تفوّت صفحات مهمة جدًا.

- لو بتحدّث محتوى باستمرار، الـ sitemap بتقول لـ Google إن فيه تحديثات حصلت، فيعيد عملية الـ crawl على الصفحات دي بسرعة.

———

🛠 أنواع الـ Sitemap؟

1- الـ XML Sitemap: وده اللي بنبعته لمحركات البحث.

- بيكون فايل اسمه غالبًا sitemap.xml.
- بيحتوي على لينكات الصفحات، وتواريخ آخر تحديث، وأحيانًا priority.


2- الـ HTML Sitemap: وده بيكون معمول للمستخدم العادي.

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

لكن اللي يهمنا في الـ SEO هو الـ XML Sitemap.

———

🤔 إزاي تعمل Sitemap؟

فيه أدوات بتعمل ده تلقائي:

- لو بتستخدم WordPress: إضافة زي Yoast SEO أو Rank Math بتعمل sitemap تلقائي.

- لو بتشتغل بـ Next.js أو أي framework تاني: تقدر تستخدم حاجة زي next-sitemap، أو تعمل generate يدوي.

- لو عندك static site: استخدم أدوات زي sitemap-generator أو screaming frog.

———

✅ بعد ما تجهز sitemap.xml:

ارفعها على root بتاع الموقع، زي:
https://example.com/sitemap.xml


✅ روح على Google Search Console:

- اختار الموقع
- اختار Sitemaps
- ضيف اللينك بتاع الـ sitemap

ده بيقول لجوجل: "إن الموقع جاهز وادخل بص على الصفحات دي."

———

وفقكم الله لكل خير 🌿