ما هو مخرج الكود؟

interface V { int SL = 80; }
class Car implements V { int SL = 120; }
// تشغيل الكود التالي:
V myCar = new Car();
System.out.print(myCar.SL);

أين الخطأ في الكود؟

abstract class Device {
    // خطأ كود هنا، ما هو السبب؟
    abstract final void boot(); 
}

أين الخطأ في الكود؟

interface Printable { void print(); }
class Document implements Printable {
    // خطأ كود في هذا السطر، لماذا؟
    void print() { System.out.print("Doc"); } 
}

أين الخطأ في الكود؟

interface MathConfig {
    // خطأ كود في هذا السطر، لماذا؟
    double PI; 
}

أين الخطأ في الكود؟

interface Flyable { void fly(); }
// خطأ كود في السطر التالي، ما هو؟
interface Swimmable implements Flyable {

}

​🚀 استضافة مشاريعكم مجاناً وبثواني!

​يا جماعة، بما إن كثير منكم يسألني وين أفضل
وأسهل مكان ترفعون فيه مشاريعكم ومواقعكم عشان تشاركوها مع الناس أو تحطوها في معرض أعمالكم (Portfolio)، جبت لكم الحل المختصر والسريع:
​🌐 موقع Netlify
🔗 netlify.app

​الموقع هذا رهيب لرفع مشاريع الـ Front-end،
ومن أهم مميزاته:
​سهل وسريع: حرفياً بس تسحب مجلد مشروعك وترميه في الموقع (Drag & Drop) ويصير موقعك شغال برابط رسمي بثواني.
​يربط مع GitHub: إذا تعدل الكود عندك، يتحدث الموقع تلقائياً بدون ما تعيد رفعه.

​ابدأوا ارفعوا أعمالكم الحين، وشاركوني روابط مواقعكم في التعليقات خلونا نشوف إبداعاتكم ونتعلم من بعض! 🔥👇

واجهة المستخدم (UI) مقابل تجربة المستخدم (UX): التوأم الملتصق في عالم التصميم 🎨💻

كثير من الناس (وحتى بعض المطورين المبتدئين) يخلطون بين المصطلحين، ويعتقدون أن UI و UX هما شيء واحد. لكن الحقيقة؟ هما تخصصان مختلفان تماماً، لكن لا يمكن لأحدهما النجاح بدون الآخر!
​دعونا نلخص الفرق بذكاء واختصار، بأسلوب "IT Code" المعتاد:

💎 اولاً: ما هي تجربة المستخدم (UX - User Experience)؟ 🤔
​الـ UX يركز على "كيف يعمل المنتج؟" وكيف يشعر المستخدم أثناء التعامل معه. هو الجانب التحليلي والنفسي والهندسي للتصميم.

📌 ​الهدف الأساسي: جعل رحلة المستخدم داخل الموقع أو التطبيق سهلة، منطقية، وسريعة بدون أي تعقيد.

ماذا يفعل مصمم الـ UX؟

• ​ دراسة سلوك المستخدمين وبناء شخصياتهم (User Personas).
• ​ رسم الهيكلية السلكية (Wireframes) والمخططات الانسيابية (User Flows).
•​ اختبار سهولة الاستخدام وتعديل الأخطاء قبل كتابة كود واحد.

💡 ​بالمختصر: الـ UX هو العقل والمنطق خلف أي نظام.
--------------------------------------------------------------------------------

💎 ثانياً: ما هي واجهة المستخدم (UI - User Interface)؟ 🎨
اما بالنسبة ​الـ UI فهو يركز على "كيف يبدو المنتج؟" وهو الجانب البصري والجمالي الذي يتفاعل معه المستخدم بشكل مباشر.

📌 الهدف الأساسي: جذب عين المستخدم وجعل الواجهة مريحة بصرياً ومتناسقة مع الهوية الرقمية.

​

ماذا يفعل مصمم الـ UI؟🌟

• ​ اختيار الألوان المتناسقة (Color Palettes) وتنسيق الخطوط (Typography).
•​ تصميم الأزرار، الأيقونات، الحقول، وتأثيرات الحركة (Animations).
• ​ تطبيق صيحات التصميم الحديثة (مثل: Dark Mode, Glassmorphism).

💡 ​بالمختصر: الـ UI هو الجسد والمظهر الخارجي للنظام.

تشبيه هندسي لتقريب الصورة 🏗️

تخيل ان بناء الصفحة مثل بناء المنزل :
​الـ UX: هو المهندس المعماري الذي يحدد مكان الغرف، مساحة المطبخ، ومكان الأبواب لضمان حركة مريحة وسهلة داخل البيت.
​الـ UI: هو مصمم الديكور الداخلي الذي يختار ألوان الجدران، نوع الإضاءة، والسجاد ليصبح البيت جميلاً ومريحاً للعين.

من الأهم؟ 🤝
​لا يوجد رابح هنا!
• ​ إذا صممت تطبيقاً بـ UI أسطوري ولكن UX سيء، سينبهر المستخدم بالمظهر أول 5 ثوانٍ، ثم يغلق التطبيق فوراً لأنه لم يعرف كيف يستفيد منه!
• ​وإذا صممت تطبيقاً بـ UX عبقري ولكن UI بدائي، فلن يقترب أحد لتجربته لأن المظهر منفر.


🖇 ​الخلاصة للـ Developers:
الـ UX يجعل المنتج ناجحاً ومريحاً، والـ UI يجعله محبوباً وجذاباً. كلاهما يكملان بعضهما ليخرجا لنا بمنتج رقمي متكامل ورائع!

@ITCode #UX_UI

اجابة على سؤال المنشور السابق سوف ناخذ اليوم نبذه بسيطة عن React

ماهي React:

هي أشهر مكتبة برمجية بلغة JavaScript وتستخدم لبناء واجهات المستخدم وتحديداً لتطبيقات ويب الجوال والمواقع الإلكترونية
طورتها شركة Meta او فيسبوك سابقاً.

لماذا يفضلها المبرمجون؟

1-​ بناء المكونات (Components): تقسم الصفحة إلى أجزاء صغيرة ومستقلة (مثل زر، قائمة، أو نموذج)، مما يسهل اعادة استخدامه وصيانته.
2-​ السرعة والأداء: تعتمد على تقنية تدعى Virtual DOM مما يجعل تحديث الصفحة فائق السرعة دون الحاجة لإعادة تحميلها كاملة.
3- ​المرونة: تدعمها شركة Meta و مجتمع ضخم جدا من المطورين حول العالم

@ITCode_0
#React #meta

قبل فترة بدات رحلة تعلم React، وكما عودتكم ان اشارككم كل خطوة في مرحلتي التعليمية، واتمنى ان نتعلم معا كل جديد ونستفيد سوياً خطوة بخطوة.

​وهذا اول مشروع أعمل عليه وهو شبه مكتمل، يسعدني جدًا مشاركته معكم!

عند استنساخ مستودع جيت، يُنزَّل كامل سجل التعديلات (Commits) منذ إنشاء المشروع، وقد يكون ضخمًا ويستهلك وقتًا وحجمًا دون حاجة.

هنا يبرز خيار
--depth 1
يجعل جيت ينزّل آخر نسخة فقط من المشروع متجاهلًا السجل القديم، فيكون الاستنساخ أسرع ويستهلك مساحة وبيانات أقل.

مثال:
git clone --depth 1 https://github.com/username/repo

#git #جيت

لا تنتظر أن تفهم كل شيء لتبدأ..

من خلال عدة مشاريع برمجية كنت فيها، كانت بداياتي في فهم المشاريع تجعلني أخشى من النتائج، وأتساءل؛ هل سأتمكن من إنجاز ما هو مطلوب مني؟

لكن مع الوقت، تبدأ بفهم المشروع أكثر، وتفهم ال codebase بشكل أعمق، وتصبح مخرجاتك فيه أفضل، وهكذا تتطور مع تطور المشروع.

لا تنتظر أن تفهم كل شيء حتى تبدأ، ابدأ، تعلّم، أخطئ، وحسّن مخرجاتك مع الوقت..

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

اللهم إنا نسألك هذا.

🚦 ما هو Rate Limiting في الـ API؟

تخيل أن عندك API بسيطة، والمستخدم الطبيعي يرسل Request أو اثنتين فقط.

لكن فجأة Client واحد بدأ يرسل 1000 Request في الثانية! 😵

قد يكون:

- Bot
- محاولة Brute Force
- Bug في الـ Frontend
- أو حتى استخدام سيئ للـ API

كل Request تستهلك من موارد الـ Server، لذلك السماح لأي Client بإرسال عدد غير محدود من Requests قد يؤثر على جميع المستخدمين.

وهنا يأتي دور Rate Limiting.

🔒 ما هو Rate Limiting؟

هو وضع حد لعدد الـ Requests التي يستطيع Client تنفيذها خلال فترة زمنية معينة.

مثلاً:

100 Requests / Minute

أول 100 Request يتم قبولها، أما الـ Request رقم 101 فيتم رفضها غالباً بـ:

HTTP 429 — Too Many Requests

⏱️ أشهر طرق Rate Limiting

1️⃣ Fixed Window

نقسم الوقت إلى فترات ثابتة:

12:00 → 12:01

مثلاً 100 Request لكل دقيقة.

سهلة وبسيطة، لكن لديها مشكلة: يمكن للمستخدم إرسال 100 Request في آخر ثانية من الدقيقة و100 أخرى في أول ثانية من الدقيقة التالية.


2️⃣ Sliding Window

بدلاً من الاعتماد على دقائق ثابتة، نحسب دائماً آخر دقيقة من اللحظة الحالية.

أدق من Fixed Window، لكن يحتاج Tracking وResources أكثر.


3️⃣ Token Bucket 🪣

لكل Client Bucket تحتوي على Tokens.

كل Request تستهلك Token، والـ Tokens تتجدد تدريجياً مع الوقت.

مثلاً Bucket تحتوي على 10 Tokens ويمكن إضافة Token كل ثانية.

وهذا يسمح بـ Burst صغير من Requests، لكن يمنع الاستمرار في إرسال عدد ضخم من Requests.

🎯 على ماذا نطبق الـ Limit؟

ليس بالضرورة على User فقط.

يمكن أن يكون حسب:

- IP Address
- User ID
- API Key
- Account
- Organization
- Endpoint

ويمكن أن تختلف الحدود حسب الـ Endpoint.

مثلاً:

"GET /products" → 1000 Request/minute

"POST /login" → 10 Requests/minute

لأن الـ Login أكثر حساسية ويحتاج حماية أكبر.

🌐 ماذا يحدث عند وجود عدة Servers؟

لو عندك:

Client → Load Balancer → Server A / B / C

ووضع كل Server Counter خاص به، فلن تكون الصورة كاملة؛ لأن كل Server يرى جزءاً من Requests فقط.

لذلك في الأنظمة الموزعة نحتاج غالباً إلى Shared State مثل Redis، بحيث تشترك جميع الـ Servers في نفس بيانات الـ Rate Limiting.

وهنا يجب الانتباه أيضاً إلى Race Conditions، لذلك يجب أن تكون عمليات تحديث الـ Counter أو الـ Tokens Atomic.

🏗️ وأين نضع Rate Limiting؟

يمكن وضعه داخل الـ Application، لكن في الأنظمة الكبيرة قد يكون من الأفضل وضعه أمام التطبيق:

Client → API Gateway → Rate Limiter → Application → Database

بهذه الطريقة يتم رفض الـ Traffic الزائد مبكراً، قبل أن يستهلك موارد الـ Application.

💡 الخلاصة

Rate Limiting ليس مجرد:

"if requests > 100 → reject"

بل هو قرار Architecture كامل:

من نحدّه؟
IP أم User أم API Key؟

كيف نحسبه؟
Fixed Window أم Sliding Window أم Token Bucket؟

أين نخزن الحالة؟
وخصوصاً عند وجود عدة Servers.

كيف نتعامل مع التزامن؟
حتى لا تحدث Race Conditions.

وفي النهاية، الـ 429 Too Many Requests مجرد Response بسيطة، لكن خلفها نظام كامل هدفه حماية الـ API وضمان توزيع موارد الـ Server بشكل عادل. 🚀