مقالات عملية مرتبة حسب المجال والمستوى، اختر المجال المناسب واقرأ من مستوى مبتدئ إلى محترف.
دليل تنفيذي للمتوسط لإعداد Cloudflare Tunnel على Raspberry Pi أو لاب توب — افتح خدمتك للإنترنت بدون port forwarding ولا VPN ولا IP عام مكشوف، مع أرقام مقاسة من 60 يوم إنتاج، 4 trade-offs خفية، ومتى الطريقة دي مش الحل أصلاً.
صندوق البحث اللي بيبعت طلب مع كل حرف بيهدر 90% من طلباته على الفاضي. Debounce و Throttle بيحلّوا ده بسطرين JavaScript. شرح للمتوسط بمثال المصعد والأتوبيس، كود جاهز للنسخ، أرقام توفير حقيقية، 4 trade-offs، ومتى الاتنين يكونوا اختيار غلط.
لو كتبت setTimeout(fn, 0) وفاكرها هتشتغل حالًا، في عندك bug صامت مستنّي وقته. المقال يشرح الـ Event Loop للمتوسط: الفرق بين microtask و macrotask، ليه Promise بيسبق setTimeout، كود يثبت الترتيب، سيناريو واجهة بتتجمد بسبب microtask starvation، 4 trade-offs، ومتى ميهمكش الموضوع أصلًا.
لو الـ API بتاعك بيرجّع FATAL: too many clients already وقت الذروة، PostgreSQL مش ضعيف — انت بتفتح 1,200 connection على DB قابل لـ 100 فقط. PgBouncer 1.23 في transaction mode بيخلّي 1,000 طلب متزامن يشتغلوا على 25 connection حقيقي، وبيقلّل connection errors من 8,420 في الدقيقة لـ صفر، مع نزول P95 من 480ms لـ 28ms. مقال للمتوسط بمثال المطعم للمبتدئ، شرح علمي للـ 3 modes من توثيق PgBouncer 1.23 الرسمي، إعداد كامل قابل للنسخ، كود Node.js شغّال على pg 8.x، أرقام مقاسة من إنتاج 1,240 req/sec، 4 trade-offs خفية بما فيهم prepared statements و LISTEN/NOTIFY، ومتى Transaction Pooling بيكون مضيعة وقت.
لو state machine في تطبيق React بيلطّخك بـ "Cannot read property 'data' of undefined" كل أسبوع، المشكلة مش في الـ runtime — هي إن TypeScript مش قادر يفرّق بين حالات الـ state. Discriminated Union بـ tag واحد بيخلّي الـ compiler يضمنلك إن state.data بس متاحة لما الحالة تكون success. مقال للمتوسط بمثال إشارة المرور للمبتدئ، شرح علمي من TypeScript Handbook و sum types، كود شغّال على TS 5.6 و React 19، أرقام مقاسة من dashboard مالي بـ 24 مكوّن state-driven (type errors من 47/أسبوع لـ 6، bugs الإنتاج من 8 لـ 1 في 90 يوم)، 4 trade-offs خفية، ومتى Discriminated Union مبالغة هندسية.
دليل تنفيذي للمتوسط لاستبدال كلمة المرور بـ Passkey واحدة باستخدام WebAuthn. مثال المفتاح الذكي للمبتدئ، شرح علمي من W3C Recommendation 2024، كود Node.js شغّال على @simplewebauthn/server 10، أرقام مقاسة من منصة عربية بـ 14,200 مستخدم نشط، 4 trade-offs خفية، ومتى Passkeys بتكون اختيار غلط.
لو خدمتك بتعمل 12,400 SET/ثانية على Redis و CPU الـ client على 92%، المشكلة في round-trips مش في Redis. Pipelining بسطر بايثون واحد بيرفع الرقم لـ 290,300 SET/ثانية على نفس السيرفر. شرح للمتوسط بمثال موظف الدليفري للمبتدئ، تعريف علمي من توثيق Redis 7.4 الرسمي، كود Python شغّال على redis-py 5.0.8، أرقام إنتاج من خدمة authentication، 4 trade-offs خفية، ومتى Pipelining بيكون كارثة.
لو الـ API بياخد 380ms كل ما الـ cache يخلص ويستنى refresh، Cache-Control: stale-while-revalidate بـ سطرين بيخلّي 99% من الطلبات ترجع في 4ms والـ refresh في الخلفية. مقال للمتوسط بمثال المخبز للمبتدئ، شرح علمي من RFC 5861، إعداد Nginx و Cloudflare Workers قابل للنسخ، أرقام من API بـ 1.2 مليون طلب يوميًا، 4 trade-offs خفية، ومتى الـ stale-while-revalidate يكون مضيعة وقت.
لو خدمتك بتفتح SELECT كل ثانيتين علشان تلحق آخر تعديل في الجدول، انت بتدفع 3 تكاليف خفية على نفس الـ DB. LISTEN/NOTIFY في PostgreSQL بترسل event من الـ DB للتطبيق في 12 مللي ثانية بدون Redis ولا RabbitMQ. مقال للمتوسط بمثال جرس الباب للمبتدئ، تعريف علمي من توثيق PostgreSQL 16 الرسمي، كود SQL و Node.js شغّال على pg 8.x، أرقام مقاسة من خدمة تتبع شحنات بـ 4,200 سائق نشط (1,400 query/ثانية → 14، latency 1.6 ثانية → 38ms)، 4 trade-offs خفية، ومتى LISTEN/NOTIFY بيكون الاختيار الغلط.
لو الكود فيه 14 دالة API call ومحتاج كل واحدة retry + log + caching، الكوبي-بيست هيخلّيك تعيد 280 سطر. Decorator واحد بـ 22 سطر بيغطّيهم كلهم بسطر @retry فوق التوقيع. مقال للمتوسط بمثال موظف الاستقبال للمبتدئ، تعريف علمي من PEP 318 و Python Language Reference، كود شغّال على Python 3.12، أرقام مقاسة من خدمة fintech عربية بـ 8,200 webhook يومياً (الفشل من 4.2% لـ 0.18%)، 4 trade-offs خفية تشمل ParamSpec و overhead 0.6μs، ومتى الـ decorator يكون مبالغة هندسية.