مطالبات شرح الكود: من التعبير النمطي إلى أثر الخطأ

الدالة تحسب إجمالي الطلب بعد الخصم.1. تضرب السعر في الكمية على كل البنود وتتجاوز الملغاة: أي بند قيمة status فيه "cancelled" لا يدخل الإجمالي أبداً.2. إذا تجاوز الإجمالي 10000 يُطبَّق عليه rate: القيمة 0.1 تعني خصماً بعشرة بالمئة.3. يُقرَّب الناتج إلى منزلتين عشريتين، أي إلى القروش.التفصيل الذي لا يقوله إلا الكود نفسه: الخصم يسري على الإجمالي كله لا على الجزء الزائد عن الحد. لذلك طلب بقيمة 10001 يصير بعد الخصم أرخص من طلب بقيمة 9999.

هذا مزخرف يأخذ وسيطاً. أقرب ما تعرفه في PHP هو دالة تعيد إغلاقاً يلتف حول دالة أخرى.يُقرأ من الداخل إلى الخارج:- الاستدعاء retry(3) يعيد decorator؛- والدالة decorator تستقبل دالتك وتعيد wrapper؛- وسطر @retry(3) فوق الدالة يعني تماماً fn = retry(3)(fn) — ومنذ تلك اللحظة يشير الاسم إلى wrapper.أما wrapper فينادي الأصل ثلاث مرات على الأكثر ويبتلع TimeoutError بلا كلمة، فإذا نفدت المحاولات رمى RuntimeError. ووجود functools.wraps يحفظ للغلاف اسم الأصل وتوثيقه، ولولاه لأظهر المنقّح وكل أثر خطأ كلمة wrapper لا غير.

1. السطر totals = dict() ينشئ قاموساً فارغاً تُجمَع فيه المبالغ لكل عميل.2. الحلقة تمر على الطلبات. والاستدعاء totals.get(id, 0) يعيد المتراكم أو صفراً إذا ظهر العميل لأول مرة، ولهذا لا حاجة إلى فحص منفصل للطلب الأول.3. الدالة sorted فوق items() ترتب أزواج العميل والمبلغ. وإشارة الناقص أمام pair[1] تقلب الترتيب: تنازلياً بدل تصاعدي، فيصعد كبار العملاء إلى الأعلى.4. والقطع ranked[:n] يبقي أول n زوج فقط.إعادة الأزواج لا المعرّفات وحدها أمر مقصود: المستدعي يحتاج المبلغ لعرضه، فلا يضطر إلى جمعه مرة ثانية.

هذا نمط double-checked locking، ولكل فحص من الاثنين سبب مختلف.الأول هو الطريق السريع. فبعد تحميل الإعدادات مرة واحدة ترى كل الاستدعاءات التالية القيمة جاهزة وتعود فوراً دون أن تمس القفل. وأخذ القفل يكلف وقتاً في كل استدعاء بينما الحاجة إليه تقع مرة واحدة في عمر العملية كلها.والثاني يخص السباق. فبينما يمسك الخيط الأول القفل ويقرأ الملف يكون خيط ثانٍ قد تجاوز الفحص الخارجي وانتظر خلفه. ولولا الفحص الداخلي لحمّل الإعدادات مرة ثانية وطمس نتيجة غيره.أما سطر global فيجعل الإسناد يغيّر متغير الوحدة بدل أن ينشئ متغيراً محلياً جديداً.

الخطأ AttributeError يعني أن الكائن لا يملك خاصية باسم price.يُقرأ الأثر من أعلى إلى أسفل لتتبع مسار الاستدعاء ومن أسفل إلى أعلى لمعرفة السبب:- الدالة create_order في الملف orders.py عند السطر 42 نادت calc_total؛- والدالة calc_total في الملف pricing.py عند السطر 17 طلبت item.price فسقطت.السطر 17 هو موضع السقوط لكن المشكلة ليست فيه. فالرسالة تقول إن داخل items قواميس لا كائنات، والقاموس لا يقبل الوصول بالنقطة. أي أن المستدعي مرّر البيانات كما جاءت من JSON دون أن يبني منها نموذجاً. فالإصلاح يكون حيث تُركَّب items، أو بقراءة الحقل هكذا: item["price"].

هذه النسخة من المكتبة غير موجودة أصلاً.ذهب pip إلى فهرس الحزم فوجد pandas وعدّد النسخ المتاحة، وأحدثها 2.2.2. وأنت تطلب 2.9.1 ولا ينشرها أحد، ومن هنا جاءت عبارة «no matching distribution».وفي الغالب يكون السبب واحداً من ثلاثة: خطأ مطبعي في رقم النسخة، أو ملف requirements.txt منقول من مشروع أحدث، أو نسخة لا تصدر إلا لإصدار آخر من Python. والسطر الثاني ليس مشكلة مستقلة بل نتيجة الأول.

نفدت الاتصالات بقاعدة البيانات.السطر الأول: انتظر المجمّع اتصالاً حراً ثلاثين ثانية ثم استسلم. فقيمة active=20 تعني أن العشرين كلها مشغولة، وقيمة idle=0 تعني أنه لم يبق حر واحد، وقيمة waiting=137 تعني أن مئة وسبعة وثلاثين طلباً تقف في الصف خلفها.والسطر الثاني نتيجة للأول: بقي الطلب POST /orders معلقاً الثلاثين ثانية نفسها ثم أعاد 503.والقراءة مجتمعةً: الطلبات تصل أسرع مما تحرر قاعدة البيانات اتصالاتها. المجمّع ليس معطلاً، بل يبلّغ بصدق أنه بلغ سقفه. والخطوة التالية هي النظر في الاستعلامات الطويلة التي تحتجز اتصالاً، وفي حجم المجمّع نسبةً إلى عدد العمال.

النمط يفحص شكل العنوان لا وجوده.- الرمزان ^ و $ يشترطان تطابق السلسلة كاملةً لا جزء منها.- الجزء السابق لعلامة @: حروف وأرقام ونقطة وشرطة سفلية وعلامة نسبة وزائد وشرطة، بمقدار محرف واحد على الأقل.- العلامة @ مرة واحدة تماماً.- النطاق: حروف وأرقام ونقاط وشرطات.- وفي النهاية نقطة وامتداد من حرفين فأكثر.ما يمر بلا داعٍ: نقطتان متتاليتان، ونقطة في أول الاسم، ونطاق لا وجود له. وما يُرفض ظلماً: العناوين المدوّلة والامتدادات بغير الحروف اللاتينية. وهذا يكفي عادةً في نموذج تسجيل، لأن وجود العنوان تؤكده رسالة التفعيل على أي حال.

التعبير يفكك سطر سجل خادم الويب إلى ست مجموعات.1. عنوان IP: أربعة أعداد تفصلها نقاط. والنقطة المسبوقة بشرطة مائلة تعني نقطة حقيقية لا «أي محرف».2. الوقت بين قوسين معقوفين: يُسمح داخلهما بأي محرف عدا قوس الإغلاق، وهذا بالذات ما يمنع المجموعة من التهام بقية السطر.3. طريقة الطلب: حروف كبيرة.4. المسار: كل شيء حتى أول مسافة.5. رمز الاستجابة.6. حجم الاستجابة بالبايت.ترتيب المجموعات هو ترتيب الحقول في الناتج: الأولى هي العنوان والخامسة هي الحالة. وأي سطر يحوي مساره مسافة لن يطابق النمط كاملاً وسيُتخطى ببساطة.

الأمر ينسخ مجلد data احتياطياً إلى جهاز آخر دون أن يحفظ شيئاً على هذا الجهاز.- الأمر tar -czf - يبني الأرشيف ويضغطه لكنه يكتبه إلى المخرج القياسي بدل ملف: هذا معنى الشرطة المفردة.- والخط العمودي يسلّم ذلك التدفق إلى الأمر التالي.- والأمر ssh يتصل بالجهاز nas بالمستخدم backup ويشغّل هناك cat الذي يضع التدفق في ملف.- والتعبير $(date +%F) يضع تاريخ اليوم في اسم الملف فينتج data-2026-09-13.tar.gz.الأرشيف لا يهبط كاملاً في أي مكان: هو يسيل عبر الشبكة أثناء تكوينه، فلا حاجة إلى مساحة حرة على قرص الجهاز المصدر. وهناك حافة خطرة واحدة: إن كان ملف بهذا الاسم موجوداً فسيُكتب فوقه بلا كلمة تحذير.

الاستعلام يحسب الإيراد لكل عميل موزعاً على الأشهر خلال السنة الأخيرة.- الربط JOIN يصل الطلب بالعميل. وهو ربط عادي لا LEFT، ولهذا لا يظهر العملاء الذين لم يطلبوا قط.- والشرط WHERE يقطع كل ما هو أقدم من سنة من اللحظة الحالية.- والدالة date_trunc تقصّ التاريخ إلى أول الشهر، وبهذا تتجمع الطلبات المفردة في مجموعات شهرية.- والجملة GROUP BY 1, 2 تجمّع حسب أول تعبيرين في القائمة: اسم العميل والشهر.- والشرط HAVING يستبعد المجموعات دون 1000. وخلافاً لـ WHERE يُطبَّق هذا المرشّح بعد حساب المجموع.الصف الواحد في الناتج هو عميل في شهر واحد لا عميل بكامل تاريخه.

دالة النافذة تحسب على مجموعة دون أن تطوي الصفوف: يخرج من الاستعلام عدد الصفوف نفسه الذي دخله، وكل صف يكسب عمودين جديدين فقط.- الجملة PARTITION BY customer_id تقسم الجدول إلى أكوام حسب العميل، والكومة هي النافذة.- في العمود الأول يُحسب المجموع تراكمياً: فـ ORDER BY created_at يحدد الترتيب داخل النافذة، وافتراضياً تُحسب الصفوف من بداية النافذة حتى الصف الحالي. فعند الطلب الثالث للعميل يكون المجموع هو مجموع الطلبات الثلاثة الأولى.- وفي OVER الثانية ترتيب مختلف، تنازلياً حسب المبلغ، وتوزّع row_number المراتب: الرقم 1 لأكبر طلبات ذلك العميل.وهذا بالضبط ما يفرق النافذة عن GROUP BY: فالتجميع كان سيترك صفاً واحداً لكل عميل ويضيّع الطلبات المفردة.

الاستعلام يجلب طلبات الأول من سبتمبر مع كل بنودها. و LEFT JOIN يعني أن الطلب الخالي من البنود يخرج هو أيضاً، بأعمدة order_items فارغة.أين يتعثر على بيانات حقيقية:- التعبير DATE(o.created_at) دالة موضوعة فوق العمود، وبسببها يصير الفهرس على created_at غير قابل للاستعمال: على قاعدة البيانات أن تحسب تاريخاً لكل صف في الجدول. لا يظهر ذلك على مئة صف اختبارية، أما على الملايين فهو مسح كامل.- والاستعلام SELECT * فوق علاقة واحد إلى متعدد يعيد كل طلب بعدد بنوده. فتخرج صفوف أكثر بكثير من عدد الطلبات، ويقع على التطبيق أن يطويها بنفسه.- والجدولان يحملان أعمدة بالأسماء نفسها (id و created_at)، فتختلط في الناتج ولا يعود الاسم يدل على الجدول الذي جاء منه الحقل.

البرنامج يجمع الأعداد الزوجية في القائمة ثم يقسم الناتج على عدد الأعداد كلها.1. القائمة nums فيها ستة أعداد.2. والسطر total = 0 هو الصندوق الذي سنجمع فيه، والصفر موجود ليكون هناك ما نبدأ منه.3. والسطر for n in nums هو الحلقة: يصير n بالتناوب كل عدد من القائمة.4. والشرط n % 2 == 0 يعني أن باقي القسمة على اثنين صفر، أي أن العدد زوجي.5. والسطر total += n يضيف ما وُجد إلى ما تراكم.6. والقسمة على len(nums) هي قسمة على طول القائمة، أي على ستة.ويبدو أن هنا خطأً في الفكرة نفسها: في القائمة أربعة أعداد زوجية مجموعها 70، بينما القسمة تجري على ستة. فإن كان المطلوب متوسط الأعداد الزوجية وجب القسمة على عددها هي.

هذا بحث ثنائي في مصفوفة مرتبة، وفكرته واحدة: في كل خطوة يُطرح نصف ما تبقى.- المتغيران lo و hi هما حدا المقطع الذي قد يكون الجواب فيه.- والمتغير mid هو المنتصف، والشرطتان المائلتان قسمة صحيحة، ولهذا يخرج دليل لا كسر.- فإن كان المطلوب في المنتصف انتهى الأمر.- وإن كان المنتصف أكبر فالجواب إلى اليسار ويتحرك hi.- وإلا فالجواب إلى اليمين ويتحرك lo.- وتنتهي الحلقة حين يتقاطع الحدان: القيمة غير موجودة فيعاد -1.الكلفة لوغاريتمية: مليون عنصر تعني نحو عشرين خطوة بدل مليون. والشرط الذي لا بديل عنه أن تكون المصفوفة مرتبة سلفاً، وإلا أعادت الخوارزمية جواباً خاطئاً في صمت.والسؤال المتفرع المعتاد في المقابلات: في اللغات ذات الأعداد الصحيحة محدودة الحجم قد يفيض المجموع lo + hi، ولهذا يُكتب هناك lo + (hi - lo) // 2.

النص البرمجي يتحقق من الطلبات التي لم تُشحن بعد ويبلّغ عددها برسالة بريد.خطوة خطوة وبلا مصطلحات:1. يفتح جدول الطلبات، وهو ملف عادي يفتحه برنامج Excel أيضاً.2. ويبقي الصفوف التي يكون فيها تاريخ الشحن فارغاً، أي طلب سُجّل ولم يخرج.3. ويعد كم صفاً من هذا النوع هناك.4. ويرسل رسالة إلى عنوان القسم فيها هذا الرقم وحده.وما ينبغي أن يعرفه المدير: النص لا يغيّر شيئاً ولا يعطّل أحداً، هو يقرأ ويبلّغ فقط، فيمكن تشغيله كل ساعة إن شئت. ونقطة ضعفه واحدة: يقرأ من ملف، أي أنه يعرض الصورة عند آخر تصدير لا صورة هذه اللحظة.