Line Clamp in CSS 🚀

AI Python for Beginners

- Learn Python programming fundamentals and how to integrate AI tools for data manipulation, analysis, and visualization.

- Discover how Python can be applied in various domains such as business, marketing, and journalism to solve real-world problems and enhance efficiency through practical applications.

- Leverage AI assistants to debug code, explain concepts, and enhance your learning, mirroring real-world software development practices.

———

🔗 https://www.deeplearning.ai/short-courses/ai-python-for-beginners

مفهوم الـ JavaScript Proxy 💯
.
.
عمرك دخلت على أوضة فيها مرايا في كل حتة؟
كل حركة بتعملها بتتشاف في المرايات من كذا زاوية، بس أنت في الآخر لسه بتتحرك في نفس الأوضة.

تخيل بقى إن في الـ JavaScript فيه ميكانيزم بيعمل نفس الفكرة دي، بس مش لمراقبة حركتك، لمراقبة الـ object نفسه اللي بتتعامل معاه.
الميكانيزم ده اسمه Proxy، واحد من أقوى الأدوات اللي ممكن تخلّي شغلك في الـ JavaScript فيه مرونة وتحكم عالي.

———

🔗 LinkedIn:
https://www.linkedin.com/posts/dev-alisamir_javanoscript-javanoscriptdeveloper-webdevelopment-activity-7349710022563479554-Z_MG

🔗 Qabilah:
https://qabilah.com/posts/odUcoaVZ2jU

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

هو ده بالضبط الفرق بين HTTP و HTTPS.

الـ HTTP = الجواب العادي.
الـ HTTPS = الجواب المشفر.

تعال ندردش شوية ونشوف إزاي الـ HTTPS بيشتغل وبيأمّن الداتا بينك وبين أي موقع...

———

🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_webdevelopment-mentoor-softwaredevelopment-activity-7349830368893530112-HK-4

🔗 Qabilah:
https://qabilah.com/posts/Y2HAs0OpQUg

🔗 Facebook:
https://www.facebook.com/share/p/1Aur2dq9Bw

يعني إيه 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 سريعة.

———

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